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

ARP table flooding out issue due to third party switch was flooding STP TCN

Publication Date:  2012-07-27 Views:  45 Downloads:  0
Issue Description
NOC team find traffic Dip in WAP services for AIRCEL Delhi circles. The traffic observed was around 700mb. As per past trend it should be above 1.5G. 

Alarm Information
Traffic in the graph was very low as compare to past trends.
Handling Process
1.    First  we analyze logs of our network devices
2.    We find out that ARP table was frequently refereshing on Switch A causing switch A to block traffic from GGSN to NBG server.
3.    Then we diverted traffic from DEL-S9303-SW-A1 to DEL-S9303-SW-B1 and observed increasein traffic from 750 MB to 1GB approx.
4.    we fanalayze logs of  DEL-S9303-SW-A1  and find out that we were recieveing contineous STP TCN on port Gi2/0/6.On port Gi2/0/6 there was a third party switch connected which was sending TCN flood to our core switch.
5.    We eanble TCP protection on our switch for protecting from unwanted switch.
#                                                                                                                                  
 stp mode rstp                                                                                                                     
 stp instance 0 root primary                                                                                                       
 stp tc-protection                                                                                                                 
 stp tc-protection threshold 1                                                                                                     
 stp enable                                                                                                                        
 stp converge normal                                                                                                               
#       
 6.  we conveyed customer for replacing that partcular problematic switch

Switch logs:
 
<DEL-S9303-SW-A1>
                BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:43:26 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:43:28 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:43:30 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:43:32 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:44:25 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:44:27 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:44:29 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:44:31 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:44:33 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:45:26 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:45:28 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:45:30 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:45:31 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.
May 31 2012 15:45:33 DEL-S9303-SW-A1 %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet2/0/6.



Root Cause
 The root cause of this issue was unwanted STP TCN packets sent by 3rd party switch to Huawei L2 switch, which triggered flushing out the ARP table. The frequency of these packets was quite high which led to frequent deletion of ARP entries. As a result, Layer 3 service packets failed to be forwarded and packet loss occurred.


 
Suggestions
1. Configure “STP converge normal” command in Switches with version S9300 V100R001, S9300 V100R002, S23&33&53 V100R002, and S23&33&53 V100R003.
2. When the switch continuously receives TC packets within 10 consecutive minutes, run the following commands to configure TC protection in all the versions to limit the maximum number of TC packets to be processed in the specified period of time (2 seconds by default):
* Run the stp tc-protection command to enable an MSTP process to suppress TC BPDUs.
* Run the stp tc-protection threshold 1 command to set the maximum number of times an MSTP process parses TC BPDUs and updates forwarding entries in a certain period of time.
3. Install S9300 V100R002SPH012 or S9300 V100R001SPH018 to solve the problem that MAC address entries are deleted frequently.

END