A large number of packet losses of 53TQX and 52TQX interconnecting test frames

16

Question:
Live network reported a large number of packet losses of test frames or failure to communicate between 53TQX and 52TQX client side when no services are transported.
Answer:
The test frame mechanism of OSN 6800/8800 are as follows: When the transmit end begins the test frame test, a GFP frame is changed to a management frame periodically at an interval of 1 second. These frames are also counted as sent frames. The test frame interruption at the receive end is always turned on, and detects whether the received frame is a management frame. If a management frame is received, it is counted as a received frame. By manually comparing whether the number of sent and received frames, it can be determined whether the link is normal. On 53TQX/53TDX/55TQX in versions earlier than V100R007C00, when configuring 10GE LAN services at the client side, if the RLOS or LOCAL_FAULT alarms are reported, a PN11 code stream will be inserted in the ingress direction, that is, the data encapsulated in the ODU2 frame is PN11 instead of GFP frames. The PN11 insertion can be transiently disabled only when a test frame is sent at the interval of 1 second. The PN11 insertion is immediately enabled when the test frame is completely sent. Due to chip defects, for 52TQX in versions earlier than V100R007C00, the test frame interruption must be disabled periodically at an interval of 1 second (the test frames from the peer end cannot be detected or counted) when the GFP frame is out of synchronization. In other situations, the test frame interruption is enabled. In this mechanism, if the transmit end is 53TQX/53TDX/55TQX and the receive end is 53TQX/53TDX/55TQX, and test frame interruption is always enabled, then each test frame sent can be counted. Therefore, the process will be normal. However, when the receive end is 52TQX, there is a high probability that test frame interruption will be disabled because GFP frames are out of synchronization (caused by PN11 code streams). As a result, a large number of test frames from the peer end cannot be counted. This means that a large number of test frames are lost. This is the reason why 53TQX/53TDX/55TQX and 52TQX in versions earlier than V100R007C00 do not support test frames when there are no services.
Suggestion and conclusion:
To test whether a link is normal, you can only judge from ODU-layer alarm performances.

Other related questions:
Why does an S series switch properly transmit small ping packets but discard large ping packets
A small MTU value on an interface of an S series switch may make the switch properly transmit small ping packets and discard large ping packets. You can run the ping -f command to measure the maximum packet length supported by the interface, and then check the MTU value on the interface. Note: The ping command uses ICMP packets. The packet size in the ping command output is the payload length of ICMP packets, excluding the length of the IP and ICMP packet headers. The length of the IP packet header is 20 bytes and that of the ICMP packet header is 8 bytes.

The E1 interface of an AR router does not communicate properly
If the E1 interface of an AR router does not communicate properly, investigate the causes as follows: If the link of E1 interface cannot be accessed, the state of the interface alternates between Up and Down, or a lot of CRC errors are found in the interface statistics displayed after the display interface Serial command is run, it may because: - The E1 card is not grounded (high probability). - Electromagnetic interference sources, such as motors, transformers, and generators, exist along the route of the E1 cable. - The cables of the E1 line are distributed outdoors, and the interface is damaged because of thunderstorms. - The impedance of the E1 interface does not match the impedance configuration of the cable (configuration problem). Run the display controller e1 or display fe1 Serial command to check the impedance of each cable type. Run the line-termination or fe1 line-termination command to modify the impedance.

How to check ping packet loss on S series switches
For S series switches (except the S1700), you can run the ping command to check ping packet loss directly. For example: [HUAWEI] ping -c 100 192.168.2.21 PING 192.168.2.21: 56 data bytes, press CTRL_C to break Reply from 192.168.2.21: bytes=56 Sequence=1 ttl=124 time=1 ms ... --- 192.168.2.21 ping statistics --- 100 packet(s) transmitted //Total number of sent packets 91 packet(s) received //Total number of received packets 9.00% packet loss //Packet loss ratio round-trip min/avg/max = 1/1/19 ms You can also perform the following steps to configure traffic statistics collection to check ping packet loss: Configure traffic statistics collection for packets received by a switch. 1. Configure an ACL rule. [HUAWEI] acl number 3000 [HUAWEI-acl-adv-3000] rule permit icmp source 192.168.2.21 0 destination 192.168.2.20 0 [HUAWEI-acl-adv-3000] quit 2. Configure a traffic classifier. [HUAWEI] traffic classifier 3000 [HUAWEI-classifier-3000] if-match acl 3000 [HUAWEI-classifier-3000] quit3. Configure a traffic behavior. [HUAWEI] traffic behavior 3000 [HUAWEI-behavior-3000] statistic enable [HUAWEI-behavior-3000] quit 4. Configure a traffic policy. [HUAWEI] traffic policy 3000 [HUAWEI-trafficpolicy-3000] classifier 3000 behavior 3000 [HUAWEI-trafficpolicy-3000] quit 5. Apply the traffic policy to an interface. [HUAWEI] interface gigabitethernet 0/0/2 [HUAWEI-GigabitEthernet0/0/2] traffic-policy 3000 inbound [HUAWEI-GigabitEthernet0/0/2] quit 6. Check traffic statistics of packets received by the switch. [HUAWEI] display traffic policy statistics interface gigabitethernet 0/0/2 inbound verbose rule-base //The output is omitted. For more information about ping packet loss, see "Ping Failure Troubleshooting" or "S Series Switches packet Loss Troubleshooting" in "Maintenance Topics" in the Huawei S Series Campus Switches Maintenance Guide.

AR router troubleshooting guide: ARP attacks and Drop alarms occur on a gateway device
For the problem that ARP attacks and Drop alarms occur on a gateway device, see the troubleshooting guide. For details, access the URL in the right column.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top