1. Check the inter-zone policy configuration for the two carrier
networks on the USG2200. No filtering policy is configured for the 40.x.x.x
2. Check the route configuration on the USG2200. Two default
routes exist, respectively destined for CARRIER1 and CARRIER2 interfaces. When
either of the links goes Down, packets are forwarded through the other link.
Therefore, the routes are correct.
ip route-static 0.0.0.0 0.0.0.0 39.x.x.49
ip route-static 0.0.0.0 0.0.0.0 41.x.x.65
3. Shut down the link between the USG2200 and CARRIER1, and
tracert the route from the USG2200 to the server. The following figure shows
the result. According to the tracert records, packets have reached CARRIER1.
The route between CARRIER networks is reachable.
4. Based on steps 1 to 3, the public network is working properly. Check other configurations on the USG2200. The following incorrect configuration is found:
firewall mac-binding 41.x.x.69 0006-xxxx-fc97
IP address 41.x.x.69 is bound to a MAC address on the firewall (USG2200). The configuration is incorrect regardless of whether the MAC address is the next-hop MAC address of carrier1 or the server's MAC address. If the response packets are returned from the carrier2 interface, the source MAC address of the packets is the MAC address of the carrier2 interface. Once the IP address and MAC address is bound on the firewall, the source MAC address is different from the static MAC address bound to 41.x.x.69 on the firewall. Therefore, the firewall discards the packets.
5. Talk with the customer, and find that the MAC address binding is a configuration on the former network. However, the configuration is retained when the network structure is greatly changed. To rectify the fault, delete the MAC address binding configuration.