MC-LAG Blackhole After Adding a VLAN to One Peer
Two QFX5100 switches run MC-LAG with ICCP over a 2x40G inter-chassis link (ICL). Four dual-homed servers use LACP bonds. The fabric carries 200 VLANs. A new VLAN 305 was added for a backup service on peer A, including the server-facing ae0 interface and the ICL. The server bond came up, but traffic to the server works only when it arrives through peer A; traffic through peer B is dropped. The server sends ARP requests that are answered only when the request ingresses peer A; peer B shows the ARP request arriving but no reply. ICCP is up, LACP is up on both peers, and there are no interface errors. The change window has 20 minutes left. The team wants to add VLAN 305 to peer B and move on.
1. How can LACP be up on both peers while VLAN 305 still blackholes through peer B?
Read the worked answer
LACP runs at the link level and only negotiates the bond; it does not know whether VLAN 305 is configured on the peer's bridge domain. ICCP synchronizes MC-LAG control state, not the VLAN database. So peer B can have a healthy LACP bundle and still drop VLAN 305 frames because the VLAN is not in its vlans table or not attached to the ae0 unit. Confirm with show vlans on both peers, show ethernet-switching interface ae0.305, show configuration interfaces ae0 unit 305, and show configuration vlans. If peer B lacks the VLAN, traffic arriving from the server on peer B has no bridge domain and is dropped; traffic from peer A works. That is why the symptom is directional.
2. What is the minimal fix, and what else must be verified on the ICL before declaring success?
Read the worked answer
Add VLAN 305 to peer B's VLAN database and to the ae0 unit, and allow it on the ICL if the ICL is a shared-interface. Then verify the ICL carries the VLAN with show vlans and show ethernet-switching interface ae1 or the actual ICL interface name, and confirm MC-LAG state with show multi-chassis mc-lag and show iccp. Use commit synchronize if the peers are configured for synchronized commits. Do not assume adding the VLAN on peer B is enough if the ICL is trunked with an explicit VLAN list; an omitted VLAN there causes hairpinned traffic to drop.
3. How would you prove traffic is hairpinning over the ICL, and what verification would you leave behind?
Read the worked answer
Check the MAC table for the server MAC on peer B pointing to the ICL, and watch ICL counters while generating traffic. If the server MAC is learned over the ICL, peer B is relying on peer A to reach the server. After the fix, the MAC should be local on the ae0 interface. Verify with a bidirectional ping/ARP test from the server and check that both peers show the VLAN and the LACP bundle. Leave the change with commit confirmed until the test passes, then record the before/after MAC and ICL counters in the change record.