Management Network Overlap in an Active/Standby Pair
A regional office runs a pair of Cisco Secure Firewall 2130 appliances in active/standby HA. The inside network is 10.20.0.0/16 on Ethernet1/1, outside is 203.0.113.0/24 on Ethernet1/2, the failover link is Ethernet1/3, and the state link is Ethernet1/4. Because no separate management switch was available, both management interfaces were addressed as 10.20.10.11 and 10.20.10.12/24, on the same VLAN as the inside network. FMC at 10.20.10.5 and a syslog server at 10.20.10.20 are on that VLAN. Registration worked during the initial install. After a facility power outage, the former standby boots first and becomes active. FMC now shows the active unit as unreachable, while the standby unit is reachable. Inside users also report intermittent timeouts to the FMC GUI. The FTD default route points to 203.0.113.1. No NAT or ACL change was made.
1. What is the most likely reason the active unit became unreachable, and why did the problem not appear during the initial install?
Read the worked answer
The management interface is on the same subnet as the inside data interface, which violates a core FTD design constraint: management should be on a dedicated network, not share a Layer 2 segment or subnet with any data interface. FTD keeps management in a separate VRF from the data plane, so 10.20.0.0/16 is now a connected subnet in two routing contexts. After the power event, boot order and the active/standby role changed. ARP resolution and route selection for FMC's TCP 8305 session can resolve through the data interface instead of the management VRF, and return traffic may be sourced from the wrong interface. During the initial install, only one unit was active and the ARP/route state happened to be consistent, so the latent design error was not exposed. The fact that the standby is reachable while the active unit is not is consistent with a path/VRF selection problem rather than a dead appliance.
2. Which FTD and FMC checks would you use to confirm the overlap before changing the design?
Read the worked answer
From the FTD CLI check show interface ip brief, show route, show arp, and show running-config interface; compare the management and inside connected routes and ARP entries for 10.20.10.5. Run show managers and show failover to see registration state and which unit is active. On FMC, use the device management page and a packet capture on the management interface while pinging FMC. Also capture on the inside interface: if FMC replies or FTD replies to FMC appear on the inside capture, the overlap is proven. Check show nat only if NAT is in the path; it is not the primary suspect here. Finally, verify the failover and state links are not sharing the same VLAN as management or data. This evidence separates a management VRF problem from a hardware or HA failure.
3. Propose the corrected design and a migration approach with minimal downtime.
Read the worked answer
Move management to a dedicated VLAN and subnet, for example 192.0.2.0/24, with its own default gateway on a management switch. Re-IP both management interfaces, set the management gateway, and confirm the FMC-to-FTD path with ping and TCP 8305 before re-registering. Because FMC is currently on the overlapping VLAN, place FMC on the management network or route it to 192.0.2.0/24. Schedule a maintenance window and use the console on both units; changing the management IP disconnects FMC. After re-registration, verify HA active/standby, perform a failover, and check that FMC and syslog reachability survive failover. Do not use the inside interface as the management gateway. If a separate management switch is impossible, at minimum move management to a different VLAN and subnet and route it; same-subnet separation is not sufficient.