No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Congestion Occurred Due to Traffic Replication on a Dual-plane Network on Which CEs Connected to Two PEs Through VRRP

Publication Date:  2013-10-08 Views:  33 Downloads:  0
Issue Description


NE80E was the shared node of intersecting RRPP rings (ring 6 and ring 7). All BTS sites connected to CX200B on ring 7 reported alarms indicating link congestion. The BSC also reported an alarm indicating link congestion.

 

Traffic bursts occasionally occurred on ring 7, which affected the BTS services.
Handling Process

Huawei completed the following steps to diagnose the problem:

1. Captured packets of the burst traffic on ring 7.

Source IP:172.16.5.124  Source MAC:0018-825d-90e7

Destination IP:172.20.30.71  Destination MAC:286e-d437-5002

 

The destination MAC and IP addresses of the burst traffic matched the BTS (172.20.30.71) connected to ring 6, indicating that the traffic on ring 6 had been replicated and sent to ring 7.

2. Checked why A1 replicated the traffic.

I. Checked from which port MAC 0018-825d-90e7 was learned on A1. The MAC address was learned from Eth-Trunk15.

-------------------------------------------------------------------------------

MAC Address    VLAN/       PEVLAN CEVLAN Port            Type      LSP/       

               VSI/SI                                              MAC-Tunnel 

-------------------------------------------------------------------------------

0018-825d-90e7 109         -      -      Eth-Trunk15     dynamic   -          

 

II. Checked for a port with MAC 0018-825d-90e7 on A2. The MAC address belonged to the VLANIF205 interface.

III. Checked whether the MAC information of the BTSs connected to ring 6 existed on VLANIF205. No such MAC addresses existed.

Possible causes for lack of MAC information include MAC aging on an NE and MAC information cleared by TC.

A1 and A2 were not on RRPP rings and did not process TC packets. Therefore, lack of MAC information was caused by MAC aging.

IV. Checked the MAC learning and aging mechanism of LPUG boards. In practice, the actual MAC aging time is half of the preset MAC aging time, to prevent the actual aging time longer than a preset value. In this case, the actual MAC aging time was 12.5 minutes, whereas ARP aging time was 20 minutes. Therefore, within the 7.5-minute gap, MAC addresses of the BTSs did not exist, causing the traffic broadcast and replication.
Root Cause
The uplink path (green line) and downlink path (red line) for BTS (172.20.30.71) traffic were different. The downlink path passed A2 > A1. Because the MAC address of the BTS aged on the interface on A2, traffic was replicated to ring 7, causing traffic bursts and congestion.
Solution
Set the MAC aging time to 45 minutes (more than twice the ARP aging time) for the NE80E, or set the uplink path and downlink path consistently for BTS traffic.
Suggestions
None

END