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>


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


BGP Neighbors Are Disconnected Because of the ARP Broadcast Storm on the Layer-2 Network Attached to the NE80E

Publication Date:  2013-07-21 Views:  94 Downloads:  0
Issue Description
Because the attached switch is not cut over as required, loops occur on the Layer 2 network, which causes a serious broadcast storm on the switched network attached to the NE80E. Slot 1 of the NE80E connects to the downstream network and receives a large number of broadcast packets and then sends these packets upstream. At the same time, the BGP neighbors established through slot 1 are disconnected.
Alarm Information
Handling Process
1. Adjust the switched network attached to the NE80E and deploy STP reasonably to avoid loops.
2. Set the timeout time of BGP neighbors to 3 minutes, which is the default value, to reduce the timeout risk of the holder timer.
3. Configure ARP packet bidirectional splitting to ensure that the ARP request messages from the normally working hosts can be received and at the same time to avoid ARP attacks.
ARP packet bidirectional splitting can be configured as follows: (supported in V300R003)
<Quidway> system-view
[Quidway] interface gigabitethernet 1/0/1
[Quidway-GigabitEthernet1/0/1] ARP-safeguard enable //Configure this command in the interface view.
After the correction, BGP neighbors are established normally and no exception occurs after the cutover and switchover.
The two-way ARP packet separation principle is summarized as follows:
For an ARP request message, as long as its IP address is valid, it is hard to distinguish whether the message is a normal message or an attack message. In actual ARP attacks, ARP request messages and response messages nearly account for 50% respectively. To avoid the large number of ARP attacks, it is important to separate ARP request messages from response messages.
(1) For ARP requests, "stateless response" is adopted. That is, no ARP entry and relevant state are generated after an ARP request message is responded. In addition, the request message is not sent to the CPU for processing. In this manner, no one can use ARP request messages to deceitfully obtain the addresses from the ARP table on the gateway device.
(2) Only responses to the ARP request messages from the CPU are sent to the CPU. The ARP responses to the ARP requests that are not from the CPU are to be discarded. In this manner, the ARP request messages from normally working hosts can be responded and processed in time. 
Root Cause
Before the cutover, the device runs normally and BGP neighbors are established normally. After the cutover, loops occur. In addition, BGP neighbors in slot 1 are disconnected, but BGP neighbors in other slots run normally.
Through analysis, it is found that a great number of ARP packets are sent through slot 1 during the broadcasting storm:
<YN-KM-ESN-CE-3.CDMA>display cpu-defend slot 1 car index 8
slot : 1
(8)ARP packet information:
passed : 26401961 packets
Dropped: 321617593 -- Lots of packets are dropped. cir : 2000kbps
cbs : 20000bytes
priority : high
min-packet-length : 128bytes
To protect the CPU, the NE80E restricts the number of packets sent from each LPU to the MPU. From the number of dropped packets, you can find that board 1 discards a great number of ARP packets randomly. The interface on which BGP neighbors are established needs to learn the ARP packets from the peer. When the ARP packets at the peer end are discarded, the NE80E cannot correctly send BGP packets. Therefore, BGP neighbors are disconnected.
ARP packets on board 2 are not discarded. Therefore, BGP neighbors of other boards run normally:
<YN-KM-ESN-CE-3.CDMA>display cpu-defend slot 2 car index 8
slot : 2
(8)ARP packet information:
passed : 18083599 packets
Dropped: 0 packets -----Normal entry
cir : 2000kbps
cbs : 20000bytes
priority : high
min-packet-length : 128bytes