Huawei HCIP-Datacom: Contact Centre Hairpin After a Floor Switch Cutover

Contact Centre Hairpin After a Floor Switch Cutover

HQ campus, 3,000 users. Two S12700E core switches run VRRP and MSTP in region HQ, revision 1. VLAN 30 (10.20.30.0/24) carries the contact centre. MSTP instance 2 maps VLAN 30 with core-B as root (priority 0) and core-A as secondary (4096). VRRP for VLAN 30 has core-B as master (priority 120, preempt delay 20 s) and core-A as backup (100). The cores are joined by a 2x40GE Eth-Trunk currently at 45% average load.

A new floor was cut over last night: one S5735-L48T4X with two independent 10GE uplinks, GE1/0/1 to core-A and GE1/0/2 to core-B, each a trunk permitting VLAN 30. The engineer configured VLANs, trunking and VRRP tracking but left MSTP at factory defaults.

Users report the contact-centre application is slow. Gateway RTT rose from 0.3 ms to 1.6 ms. The uplink to core-A is at 92%; the uplink to core-B is near 0%. The core-to-core Eth-Trunk now carries an extra 3 Gbps of VLAN 30 traffic. No MAC flaps or broadcast storms are reported.

1. Why does the new switch send VLAN 30 traffic to core-A when core-B is the instance-2 root? Explain the spanning-tree computation across the region boundary.

Read the worked answer

The new switch is not in region HQ. With a factory-default name and revision, it forms its own MSTP region, so both uplinks become boundary ports between two regions.

Across a region boundary, MSTP does not compare per-instance topology. Each region is collapsed into a single virtual bridge for CIST (instance 0) computation, and only the CIST root and external path cost are compared. The CIST root here is core-A at priority 4096 versus the new switch's 32768, so the new switch's root port is the boundary port facing core-A, and the port facing core-B is placed in the alternate/discarding role.

Instance 2 never crosses the boundary; core-B's priority-0 role for VLAN 30 is invisible to a switch in another region. The topology is still loop-free, but VLAN 30 frames now arrive at core-A, which is the VRRP backup. Core-A bridges them at Layer 2 to core-B using the VRRP virtual MAC, producing the hairpin: access -> core-A -> core-B -> WAN. That extra hop explains the 1.6 ms RTT and the 3 Gbps added to the core-to-core trunk. If the switch were in region HQ, instance 2 would place its root port toward core-B, matching the VRRP master and removing the hairpin.

2. Which show commands and fields would confirm the diagnosis, and what should each reveal?

Read the worked answer

Collect evidence in four layers:

display stp region-configuration on the new switch and on core-A. Expect a MAC-derived region name and revision 0 on the new switch, versus HQ and revision 1 on the cores. This is the root cause.
display stp brief and display stp instance 2 brief on the new switch. Expect GE1/0/1 in ROOT and GE1/0/2 in ALTE for the CIST, while instance 2 may not even exist locally or shows the same blocked port.
display stp interface GE1/0/2 on the new switch and display stp on core-A. Confirm the port role, the CIST root identifier (core-A's bridge MAC) and that no topology change is flapping.
display vrrp on both cores and display interface on the new uplinks. Confirm core-B is VRRP master for VLAN 30 while core-A carries the traffic, and quantify the utilization split (92% versus near 0%).

A MAC table check on core-A for the VRRP virtual MAC on the VLAN 30 interface confirms the Layer 2 hairpin. Without the region mismatch, instance 2 would put GE1/0/2 in ROOT and align traffic with the VRRP master.

3. Give the corrective configuration and discuss the alternative of deliberately keeping the floor in a separate region.

Read the worked answer

Corrective path: on the new switch, configure stp region-configuration, region-name HQ, revision-level 1 and instance 2 vlan 30 (plus the other instance mappings used in HQ), then active region-configuration. Ensure both uplinks are trunks in the region and that access ports keep stp edged-port enable. After convergence, display stp instance 2 brief should show GE1/0/2 as ROOT and GE1/0/1 as ALTE, and the uplink utilization should invert. Confirm with display vrrp that the VRRP master and the instance-2 root are the same chassis.

Alternative: if the floor belongs to a different operations domain, keep it in its own region, but accept that per-VLAN root placement cannot cross the boundary. In that case, make core-A the CIST root and the VRRP master for every VLAN on that floor, or single-home the floor to core-A with a deliberately blocked backup link. Do not attempt to solve this with a cross-device Eth-Trunk: the two cores are not stacked, and a split trunk across independent devices is not a supported design here.