VS12 fails after failover because interface tagging differs by member
A two-member VSX cluster carries 15 Virtual Systems in active/standby mode. VS12 was added last week for a new customer. Its external interface is eth3 on member A, VLAN 212, default gateway 203.0.113.1. The cluster fails over from member A to member B during a planned test. VS1–VS11 and VS13–VS15 keep working. VS12 loses all external connectivity. On member B, vsx stat -v shows VS12 active, and the VS12 context starts. From VS12, ping to 203.0.113.1 fails with 'Destination host unreachable' and ARP for 203.0.113.1 is incomplete. The switch port for member B's eth3 is up and configured as an access port in VLAN 212. Member A's eth3 is a trunk with native VLAN 212. No changes were made to VS12's policy during the failover.
1. What is the most likely cause, and what evidence supports it?
Read the worked answer
The most likely cause is a per-member Layer 2 mismatch for VS12's external interface. VS12 is configured with VLAN tag 212, and member A's eth3 is a trunk that accepts tagged VLAN 212. Member B's eth3 is an access port in VLAN 212, which expects untagged frames; tagged frames from VS12 are therefore not delivered as VLAN 212 traffic, so ARP for 203.0.113.1 never gets a reply. The evidence fits: only VS12 fails, because only VS12 depends on the changed eth3/VLAN 212 path; the VS context starts and vsx stat -v reports it active, so this is not a VS crash; ARP is incomplete, which points below routing and policy; and no policy changed during the failover. The working VSs on other interfaces show that cluster failover itself is functioning.
2. How would you confirm whether VS12 is sending tagged or untagged frames on each member?
Read the worked answer
Capture on eth3 on both members with tcpdump -i eth3 -e -n while VS12 pings 203.0.113.1. On member A you should see 802.1Q tags with VLAN 212; on member B, compare whether the same frames are tagged or untagged. Also inspect the VS12 interface binding in SmartConsole per member and use ip -d link show in the VSX gateway to see the VLAN subinterface. Check the switch configuration for each member's eth3 port: member A should show trunk with VLAN 212 allowed, member B should show access VLAN 212. Inside VS12, check arp -a and use fw monitor to see whether the ARP request is emitted at all. This evidence distinguishes a tagging mismatch from a routing or policy problem.
3. What is the correct fix, and what check should be added to the provisioning workflow?
Read the worked answer
Make member B's eth3 match the design: configure it as a trunk that allows VLAN 212, or, if the design is intentionally untagged, remove the VLAN tag from VS12 on both members. Do not leave one member trunking and the other access unless the VS interface is also different, which defeats cluster symmetry. After the change, clear the ARP issue by testing from VS12, confirm ping and a real TCP flow, then repeat the failover in both directions. Add a provisioning gate that compares every VS interface's VLAN, tag state, and physical port across all cluster members before the VS is declared ready. A post-change failover test should be mandatory for any new VS, because a VS can look healthy on the active member while being unusable on the standby.