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>Search

Reminder

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

upgrade

An NE20E-S8 Generates a Packet Loss Alarm with the Type of IPV4_MTU_EXCEED

Publication Date:  2019-03-27 Views:  105 Downloads:  0
Issue Description

Issue Description

At 10:51 on October 12, 2018, the customer provided feedback that an NE20ES8 generated a packet loss alarm with the type of IPV4_MTU_EXCEED.

[NE20-S81-diagnose]display alarm history

1:Critical  2:Major  3:Minor  4:Warning

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

Sequence   AlarmId    Level Date Time  Description                             

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

298        0xC150009  4     2018-10-12 Security cpu-defend drop packets alarmed.

                             10:51:47+  (ChassisID=1, SlotID=9, ObjectIndex=40,

                            08:00      DiscardedPackets=111834, DiscardedThresho

                                       ld=30000, ProtocolDescription=IPV4_MTU_EX

                                       CEED, Reason=The discarded rate for packe

                                       ts destined to CPU exceeded alarm thresho

                                       ld.)

Handling Process
1.Obtain packet headers of the discarded packets. The packet length is 1500, and fragmentation is not allowed.

45 00 05 dc ad d0 40 00 30 06 2b ca 2a 65 47 0b

0a 98 ef 79 00 50 cb c0 1b 9f f3 96 49 63 43 d6

80 10 00 3d 0b 19 00 00 01 01 08 0a d5 96 32 0c

35 30 9b f5 48 54 54 50 2f 31 2e 31 20 32 30 30

https://support.huawei.com/enterprise/product/images/a8eb1bba825a4adaa80848286cc8ab9b

2.Check that the outbound interface of data packets is Eth-Trunk3.14.

[NE20-S8-diagnose]display ip routing-table 10.152.239.121

Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route

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

Routing Table : _public_

Summary Count : 1

 

Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface

10.152.239.121/32  Unr     63   0             D   10.152.239.121  Eth-Trunk3.14

3.Check that the MTU value obtained through PPP LCP negotiation with the NE20E-S8 is 1492. (The MTU value obtained through negotiation from other users is 1480).

[NE20-R1]display access-user interface Eth-Trunk 3.14 verbose nop | include  (User access index|MTU)

  User access index             : 2

  MTU                           : 1492

  User access index             : 18

  MTU                           : 1480

The negotiation result is determined by the smaller MTU value between the NE20E-S8 and access user. The minimum MTU value of the data packets received by users is 1480. Therefore, the MTU value negotiated by some users is 1480.

4. Check that the interface MTU value negotiated by the NE20E-S8 and terminals is 1492 or 1480. However, the length of the reply packets sent by the server is 1500, and the DF function is enabled.

If the length of the forwarded data packets is greater than the MTU value of the outbound interface and fragmentation is not allowed, the NE20E-S8 sends the packets to the CPU. If there are lots of packets to be sent and the rate exceeds the CPU CAR value, the IPV4_MTU_EXCEED alarm is generated.

Solution

The packet header obtaining shows that the discarded packets are TCP packets. The MSS negotiation mechanism used for TCP session establishment can be used to allow the server to send packets with a smaller length. The customer uses Virtual-Template1, and TCP MSS negotiation is enabled on Virtual-Template1.

  #

interface Virtual-Template1

tcp adjust-mss 1400

 

The minimum MTU value is 1480. In consideration that the IP, TCP, PPPoE, and QinQ packet header lengths are excluded, change the minimum MTU value to 1400.

The change does not take effect immediately. It takes effect after TCP re-negotiation is implemented.

END