VLAN tagging mismatch when adding VS5–VS8 to a VSX cluster
An integrator is deploying eight Virtual Systems on a new two-member VSX cluster (R81.20) using 25GbE bonds. VS1–VS4 use bond1 with VLANs 100–103 and have passed testing. VS5–VS8 were added later and are configured to use bond2 with VLANs 104–107. The switch team confirms that both bonds are LACP trunks and that VLANs 100–107 are allowed on both. On member A, VS5 can ping its default gateway 10.105.0.1 and reach the Internet. On member B, VS5 cannot ARP 10.105.0.1; other VSs on bond1 work. A junior engineer created VLAN interfaces 104–107 on bond2 in the VSX gateway operating system and assigned the untagged bond2 interface to VS5–VS8 in the Virtual System topology. vsx stat -v shows all eight VSs up. The change window ends in 45 minutes.
1. What is the most likely configuration error, and why does it work on member A but not member B?
Read the worked answer
The VS topology is pointing VS5–VS8 at untagged bond2 instead of the tagged subinterfaces bond2.104–bond2.107. On member A, the switch port for bond2 likely has native VLAN 104, so untagged frames from VS5 land in VLAN 104 and ARP for 10.105.0.1 succeeds. On member B, the native VLAN is probably 1, so the same untagged frames enter VLAN 1 and never reach the gateway in VLAN 104. The fact that member A works is a coincidence of the native VLAN, not proof that the VS interface is correct. The fix is to assign bond2.104 to VS5, bond2.105 to VS6, and so on, in the Virtual System topology on both members, and to stop relying on native VLAN behavior for tenant traffic. The OS-level VLAN interfaces alone do not bind a VS to a VLAN; the VS topology must reference the tagged interface.
2. What commands or GUI checks would you use to confirm the VLAN tagging and per-member interface state before changing anything?
Read the worked answer
Check the VS topology per member in SmartConsole first: VS5 should show bond2.104 on both members, not bond2. Then use vsx stat -v to confirm the VS is up and ip -d link show bond2 to see whether 802.1Q subinterfaces exist. On the wire, run tcpdump -i bond2 -e -n on each member and look for the 802.1Q tag and VLAN ID 104 in frames sourced by VS5. On the switch, verify show interfaces trunk and the native VLAN on each member's bond2 port. Use cphaprob -a if to confirm cluster interface state. Inside the VS context, check arp -a for 10.105.0.1 and use fw monitor to see whether the ARP request leaves tagged or untagged. These checks separate a VS topology error from a switch trunk error before any change is made.
3. If VS5 must remain on VLAN 104, what is the safest change and how do you avoid breaking VS6–VS8 during the window?
Read the worked answer
Treat the correction as four independent interface-binding changes, not one global trunk change. First fix VS5: assign bond2.104 on both cluster members and install policy only to VS5. Verify ARP, ping, and a real HTTPS flow, then test failover to member B and back. Only after VS5 is stable, repeat for VS6 (bond2.105), VS7 (bond2.106), and VS8 (bond2.107). Do not change the native VLAN on the switch as the primary fix, because that would affect every untagged frame on the trunk and could break VS1–VS4. Keep a rollback note that restores the prior VS interface binding. Finally, confirm that all four VSs are correctly bound on both members and that a failover test passes for each one before closing the window.