A New VLAN That Does Not Follow the Virtual Server
An active/standby pair has device A active and device B standby. They run a sync-failover device group with traffic-group-1 floating. A new VLAN dmz2 (172.16.50.0/24) and self IP 172.16.50.10 are added for a new application. The virtual server 172.16.50.100:443 is assigned to traffic-group-1. Testing from device A works. After a planned failover to device B, users on dmz2 cannot reach 172.16.50.100, while users on the original VLAN 10.10.10.0/24 are fine. The self IP 172.16.50.10 was created without changing its traffic group, so it remains in traffic-group 'none' and is active on both devices. The upstream router shows an ARP entry for 172.16.50.10 pointing to device A's MAC.
1. Explain why dmz2 users fail after failover, even though the virtual server is assigned to traffic-group-1.
Read the worked answer
Root cause
The virtual server moved, but its gateway did not. Objects in traffic group 'none' are active on all devices in the device group. The self IP 172.16.50.10 is therefore still active on device A, which is now standby, and it can still answer ARP. The upstream router's ARP entry points to device A's MAC.
After failover, device B owns the floating virtual address 172.16.50.100, but dmz2 traffic is still sent to device A because that is where the router believes 172.16.50.10 lives. Device A receives the packets, but the virtual server is not active there, so it does not answer for 172.16.50.100. Users see timeouts or resets. The original VLAN works because its self IP is presumably floating in traffic-group-1 and moved with the virtual server.
This is a classic split-brain at the gateway level: the virtual address floated, the self IP did not.
2. What is the correct fix, and what steps are required to apply it safely?
Read the worked answer
Fix
Change the dmz2 self IP's traffic group from 'none' to traffic-group-1, so it floats with the virtual server. Ensure only one device owns the address at a time.
Safe steps
- Confirm that 172.16.50.10 is not used for management, SNMP, or another service that must remain active on both devices. If it is, choose a different address for the floating gateway.
- On the active device, edit the self IP and set the traffic group to traffic-group-1. Sync the configuration to the peer.
- Perform a controlled failover. Verify that device B now owns 172.16.50.10 and 172.16.50.100, and that it sends gratuitous ARP for both.
- Clear or wait out the upstream router's ARP cache, or confirm that the gratuitous ARP updated it. If the router has static ARP, update the static entry.
- Test from a dmz2 client, then fail back and test again.
Do not simply add a static route or disable the standby interface. The issue is ownership of the gateway address, not routing.
3. What checklist would prevent this in future deployments?
Read the worked answer
Deployment checklist
- Every self IP used as a gateway by clients or servers should be in the same traffic group as the virtual servers that depend on it. 'none' is appropriate only for management or addresses that must exist on every device.
- After creating a VLAN and self IP, run
tmsh list net selfandtmsh show cm traffic-groupto confirm ownership and active state. Do not assume a new object inherited the right group. - Compare the traffic group of the virtual server, the floating self IP, and any SNAT address. A mismatch creates exactly this failure mode.
- Include an ARP and failover test in the change plan: fail over, test from each client subnet, fail back, and test again. Check gratuitous ARP on the upstream router.
- If MAC masquerade is used, verify it is configured consistently on both devices, because it changes how upstream devices learn the floating addresses.
A useful rule: if users reach the application through an address, that address must move with the application's traffic group.