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

Ping Fails Irregularly

Publication Date:  2013-01-07 Views:  51 Downloads:  0
Issue Description

NE80E-1 and NE80E-2 are connected through a Layer 2 Eth-Trunk link.

Ping the addresses of the user servers attached to NE80E-1 and NE80E-2 from the E500. The ping fails occasionally. Tens or dozens of seconds later, the ping becomes normal. NE80E-1 and NE80E-2 function as Layer 2 switches for the E500s and user servers and are connected to each other through an Eth-Trunk link.



Handling Process

Configure complex traffic classification on the port 5/0/1, through which NE80E-1 is connected to E500-1, and Layer 2 Eth-Trunk 0, through which NE80E-1 is connected to NE80E-2, to match ping packets. The count can show on which device packets are discarded so that the location scope can be narrowed. The count shows that in the case of the failed ping, ping packets enter NE80E-1 normally and the count increases but the count of ping packets entering NE80E-2 does not increase, which indicates that packets are discarded on NE80E-1.

The following is the configuration of complex traffic classification:

traffic policy PingTest

statistics enable

classifier PingTest behavior PingTest

 

traffic classifier PingTest operator or

if-match acl 3000

 

<DJT-DCN-NE80E-1>display acl 3000

Advanced ACL  3000, 9 rules

Acl's step is 5

rule 40 permit icmp source 172.19.31.252 0 destination 172.19.31.20 0

 

[DJT-DCN-NE80E-1] display current-configuration interface GigabitEthernet 5/0/1

#

interface GigabitEthernet5/0/1

portswitch

port link-type trunk

port trunk allow-pass vlan 105 110 to 111 117 121 131 137 141 152 161 163

port trunk allow-pass vlan 167 200 to 202 301

traffic-policy ceshi inbound vlan 131

After confirming that packets are discarded on NE80E-1, check the statistics on discarded packets on the upstream and downstream boards and observe whether the NP or any other component of the board discards the packets. No abnormal statistics on discarded packets of the boards are found.

Use the PQ statistics function, a mechanism for traffic management (TM), to find out whether the packets are discarded in the upstream or in the downstream. It is found that only the queue of the lowest priority (CoS 3) has packets. Then, remark the priority of ping packets to EF. Thus, the PQ statistics can show whether the packets reach the downstream board.

[DJT-DCN-NE80E-1] display port-queue statistics interface GigabitEthernet 7/0/7 ef outbound                                                                      

 ef Traffic statistics OutBound:                                               

   Last 1 second  rate(pps): 0                                                 

   Last 1 second  rate(Bps): 0                                                  

   Pass packets: 15886                                                         

   Pass bytes: 1874548                                                         

   Discard packets: 0                                                           

   Discard bytes: 0

The PQ statistics increase continuously when the ping is normal, which indicates that packets reach the downstream board. When the ping becomes abnormal, the statistics stop increasing, which indicates that packets do not reach the downstream board. There are two possible causes: One is that the upstream board discards the packets, and the other is that errors occur when packets are transmitted to the downstream board. The statistics on packets discarded by the upstream board show that the upstream board does not discard any packet. Then, it is needed to find out whether the packets are properly sent to the correct downstream board.

Layer 2 packets can be forwarded in broadcast mode or unicast mode. In broadcast mode, packets are duplicated through TM to the board in the broadcast domain. View the TM duplication list, and it is found that the contents of the list are correct. The unicast of packets is based on the learned MAC addresses. Check the MAC address entries, and it is found that certain entries are incorrect.

<DJT-DCN-NE80E-1>display mac-address 0018-fe2d-c7ba    

The MAC address table of slot 5 :                                              

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

MAC Address    VLAN/VSI  PEVLAN CEVLAN Port                     Type      LSP  

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

0018-fe2d-c7ba 131       -      -      GigabitEthernet5/0/5     

The destination port of ping packets is 5/0/5 rather than 7/0/7. Based on the MAC address entry, the packets are forwarded to the device connected to 5/0/5, which leads to packet loss.

A check shows that the device connected to port 5/0/5 has a bug that it sends certain received packets back. In addition, ports 5/0/5, 5/0/1, and 7/0/7 belong to VLAN 131. When a ping packet is broadcast to port 5/0/5, this packet is finally sent back to port 5/0/5 instead of being forwarded to other devices. Thus, the MAC address entry becomes incorrect, and packet loss occurs.

Root Cause

configuration discard the packets.

Solution

Shut down the interface 5/0/5.

Suggestions
1. The remark command and port-queue command can be used to confirm whether packets are discarded on the upstream board or the downstream board. 2. It is required to analyze the forwarding procedure if the packets are service packets, and first, it is needed to check whether the forwarding entries are correct. Apply the solution used in this case to other cases on ping failure. That is, remark the ping packets using complex traffic classification and configure HQoS. Check the statistics and locate the packet loss.

END