Stretched VLAN Across Two Data Centers with an HRP Pair
A hospital group is consolidating two data centers 40 km apart into an active-active pair and has asked you to review the proposed security architecture before implementation. Each site will host one USG6000E firewall; both will be configured as an HRP active/standby pair across the DCI, with VLAN 210 stretched between sites so that 300 virtual machines can migrate without re-addressing. The core switches run VRRP with a shared virtual MAC, and the default gateway for VLAN 210 is the VRRP address. The design document states that because HRP synchronizes sessions, traffic may return through either firewall without impact. The customer also wants 12 departments separated, but the current proposal uses only trust and untrust zones with ACLs, citing operational simplicity. A pilot showed intermittent one-way audio on VoIP and dropped database connections after a planned firewall switchover.
1. Evaluate the design statement that HRP session synchronization makes the stretched VLAN safe. What failure mode explains the pilot symptoms, and what would you verify first?
Read the worked answer
The statement confuses state synchronization with symmetric forwarding. In an HRP active/standby pair, only the active device forwards; the standby holds synchronized sessions so it can take over, it does not pass return traffic. With VLAN 210 stretched and a single VRRP virtual MAC, the return path is chosen by routing and ARP at the remote site, not by which firewall saw the original flow. If a server or router resolves the VRRP MAC at the standby site, return packets reach the standby firewall and are dropped, producing exactly the observed one-way voice and failed database connections after a switchover.
Verification order: display hrp state on both devices to confirm roles and heartbeat health across the DCI; check the VRRP master and the actual MAC/ARP entries on core switches at both sites; then inspect session tables on both firewalls for the same flow to confirm asymmetry. Also measure HRP heartbeat latency and jitter over the 40 km link, because a slow or flapping heartbeat can trigger role changes that amplify the problem. The fix is not a session-sync tweak: it is removing the stretched gateway or making forwarding symmetric.
2. The customer wants 12 departments separated. Compare using zones with inter-zone policies versus virtual systems on the single firewall pair, and recommend one for this design.
Read the worked answer
Zones and inter-zone policies give policy separation but share one routing table, one administrator domain and one set of global objects. For 12 departments that do not overlap in addressing and do not need separate administrators, this is sufficient and operationally cheap: one policy set, one HA pair, clear audit trail. Virtual systems give each department its own routing table, interfaces, administrators and policy space, which is valuable if departments have overlapping addresses, distinct tenants, or regulatory separation. The cost is real: each vsys consumes CPU and memory, inter-vsys traffic must be routed and inspected explicitly, and troubleshooting spans multiple contexts.
Recommendation: use zones plus inter-zone policies for the 12 departments, with address groups and service groups to keep the policy readable, and reserve vsys for a future tenant that genuinely needs its own routing or administration. The pilot's problem was forwarding symmetry, not lack of vsys; adding vsys would not fix it and would complicate the HA design.
3. What architectural changes would let virtual machines migrate between sites while keeping firewall inspection deterministic?
Read the worked answer
The deterministic option is to stop stretching the default gateway. Give each site its own firewall pair and local gateway, and let a VM that migrates keep its address only within a stretched subnet whose gateway is anycast at both sites, with traffic always inspected by the local firewall. That requires a routing design where the host route or subnet is advertised from the site owning the VM, so return traffic follows the same path.
Concretely: replace the single cross-site VRRP pair with two independent HRP pairs, one per site; use VXLAN with distributed anycast gateways on the core so the first hop is always local; advertise the VM's /32 or move the subnet between sites on migration; and keep HRP heartbeats local so a DCI outage cannot cause a split-brain role change. If the customer insists on L2 stretch, restrict it to the mobility subnets, not the firewall gateway, and test failover with live VoIP and database flows before cutover.