Special Topic MTU (V2.0)

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU
Issue V2.0
Date 2015-7-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015-2015. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Huawei Proprietary and Confidential

Issue 2.0 (2015-7-15) i
Copyright © Huawei Technologies Co., Ltd.
NE40E/80E/5000E/CX600/ME60
Special Topic - MTU About This Document
About This Document
On carrier networks, MTU definitions and fragmentation mechanisms vary according to

vendors and models of devices. Carrier networks with MTU inconsistency problems face the
challenges to user experience. The challenges stem from network problems, such as lag in
online games, link rot, delivery failure of emails with attachments, and errors in opening
dialog boxes.
This Chapter describes the maximum transmission unit (MTU) fragmentation mechanisms
that NE40E/80E/CX600/ME60Router running various versions implement on a full spectrum
of boards.
Product Version Information

Product Version
NE40E/80E V600R001
CX600 V600R002
V600R003
V600R005
V600R006
V600R007
V600R008
V600R009
V800R005
V800R006
V800R007
V800R008
ME60 V600R002
V600R003
V600R005
V600R006
V600R007
V600R008
V600R009
Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential iii

NE40E/80E/5000E/CX600/ME60
About This Document Special Topic - MTU
Product Version
NE5000E V800R002
V800R003
V800R005
V800R006
V800R007
V800R008
NOTE
MTU fragmentation is not supported by
NE5000E V300R007 and the earlier versions.
Change History
Version Release Update Description
Date
V1.0 2013-6-19 The initial release.
V2.0 2015-7-15  Troubleshooting case "VPN site cannot Ping with jumbo
frame of DF=1" was added.
 MTU fragmentation mechanisms in NE5000E product are
added.
 Description about force-fragment function is added in the
chapter IP MTU Fragmentation.
iv Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU Contents
Contents
About This Document ................................................................................................................... iii

1 MTU Overview ...........................................................................................................................1-1
2 MTU Fragmentation ..................................................................................................................2-1
2.1 IP MTU Fragmentation ................................................................................................................................. 2-1
2.2 MPLS MTU Fragmentation .......................................................................................................................... 2-6
2.3 Protocols MTU Negotiation ........................................................................................................................ 2-12
3 MTU Configuration and Troubleshooting ...........................................................................3-1

3.1 Interface MTU Setting .................................................................................................................................. 3-1
3.2 MPLS MTU Setting ...................................................................................................................................... 3-3
3.3 MTU Problem Troubleshooting .................................................................................................................... 3-4
3.4 MTU Typical Fault Cases.............................................................................................................................. 3-5
3.4.1 L3VPN Users Fail to Access Some Websites....................................................................................... 3-5
3.4.2 VPN Site Cannot Ping with Jumbo Frame of DF=1 ............................................................................ 3-7
3.4.3 OSPF Neighbor Relationship Cannot Be Established After a Service Cutover Is Performed ............. 3-9
4 Appendix .....................................................................................................................................4-1
4.1 Quick Search Table ....................................................................................................................................... 4-1
4.1.1 Packet Structures .................................................................................................................................. 4-1
4.1.2 Number of labels carried in an MPLS packet in various scenarios ...................................................... 4-3
4.2 Standard and RFCs ........................................................................................................................................ 4-4
4.2.1 MIBs .................................................................................................................................................... 4-5
4.3 Abbreviation .................................................................................................................................................. 4-6
Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential v

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU Figures
Figures
Figure 2-1 Fragmentation in Control Plane ........................................................................................................ 2-2

Figure 2-2 Fragmentation on motherboards ....................................................................................................... 2-4
Figure 2-3 Fragmentation on integrated boards.................................................................................................. 2-5

Figure 2-4 Fragmentation on subcards ............................................................................................................... 2-6
Figure 2-5 MPLS MTU example ....................................................................................................................... 2-7
Figure 2-6 Mode A ........................................................................................................................................... 2-10
Figure 2-7 Mode B ........................................................................................................................................... 2-11
Figure 2-8 Mode C ........................................................................................................................................... 2-12
Figure 2-9 LDP PMTU Negotiation ................................................................................................................. 2-14
Figure 2-10 RSVP-TE PMTU Negotiation ...................................................................................................... 2-15
Figure 3-1 MPLS L3VPN .................................................................................................................................. 3-5
Figure 3-2 MPLS VPN network ......................................................................................................................... 3-7
Figure 3-3 OSPF networking.............................................................................................................................. 3-9
Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential vii

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU Tables
Tables
Table 2-1 Fragmentation in Forwarding Plane ................................................................................................... 2-4

Table 2-2 MPLS MTU Value Selection Rules .................................................................................................... 2-8
Table 2-3 Fragmentation implementation for IP packets entering MPLS tunnels ............................................ 2-10
Table 3-1 Interface default MTUs ...................................................................................................................... 3-1
Table 4-1 Packet Structures ................................................................................................................................ 4-1
Table 4-2 Number of VLAN tags carried in L2VPN packets ............................................................................. 4-2
Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential ix

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU 1 MTU Overview
1 MTU Overview
Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-1

NE40E/80E/5000E/CX600/ME60
1 MTU Overview Special Topic - MTU
1-2 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU 2 MTU Fragmentation
2 MTU Fragmentation
About This Chapter

2.1 IP MTU Fragmentation
2.2 MPLS MTU Fragmentation
2.3 Protocols MTU Negotiation
2.1 IP MTU Fragmentation

IP MTU Fragmentation Implementation
MTU Process Notes
Fragmentation Location
Related
Processes
Original IPv4 Control Original IPv4 packets indicates the protocol packets sent from control plane
packet sending plane of local device. The source IP address of these IPv4 packets are local device.
Border Gateway Protocol (BGP) packets, Internet Control Message Protocol
(ICMP) messages, and bidirectional forwarding detection (BFD) control
packets, belong to protocol packets.
When the ping command is run on a device, the device sends ICMP request
messages.
Original IPv6 Control Original IPv6 packets indicates the protocol packets sent from control plane
packet sending plane of local device. The source IPv6 address of these IPv6 packets are local
device.
When the ping ipv6 command is run on a device, the device sends ICMPv6
request messages.

NE40E/80E/5000E/CX600/ME60
2 MTU Fragmentation Special Topic - MTU
MTU Process Notes

Fragmentation Location
Related
Processes
IPv4 packet Forwarding IP fragmentation occurs when the device sends packet, but not when the
forwarding plane device receives packet.
For NE40E/80E/CX600/ME60/NE5000E device, the MTU configured in the
interface (also called interface MTU) is IP MTU. IP MTU is a layer 3
definition. Therefor, interface MTU only takes effect on Layer 3 traffic, but
not on Layer 2 traffic. Even when IP header + IP payload of L2 frame
exceeds interface MTU, the L2 frame will not be fragmented.
NOTE
Generally, only the source and destination nodes need to analyze the IPv6 extension headers. So fragmentation only occurs on the
source node, which is different from IPv4.
Fragmentation in Control Plane

As shown in Figure 2-1, control plane fragments IP packet and then encapsulate them with
tunnel header (such as MPLS and L2TP) if needed before sending the packet to forwarding
plane. Control plane fragmentation is implemented by software. Therefore, the fragmentation
rules are the same in different board types.
Figure 2-1 Fragmentation in Control Plane
If the size (including the IP header and payload) of non-MPLS packets sent from control
plane, is greater than the MTU value configured on an outbound interface:
 If the DF field is set to 0 in a packet, the packet is fragmented. The size of each fragment
is less than or equal to the interface MTU.
 If the DF field is set to 1 in a packet, the packet is discarded.
 If the DF field is set to 1 in a packet and the out interface is enabled with
forcible-fragmentation, the packet is fragmented. Each fragment is forwarded with DF=0.
(By default, forcible-fragmentation is not enabled for control plane. To enable

NE40E/80E/5000E/CX600/ME60
forcible-fragmentation for control plane, run the clear ip df command in the out
interface.
For the information about the fragmentation for MPLS packet, see the chapter 2.2 MPLS
MTU Fragmentation.
Protocol packets are usually allowed to be fragmented (DF=1), that is, the protocol packets
are usually not be discarded in the original device even when they exceed the MTU. the
protocol packets are not allowed to be fragment (DF=1) only when:
 the device is implementing PMTU discover, such as IPv6 PMTU discover, or
LDP/RSVP-TE PMTU negotiation.
 the ping -f command is running on the local device.
Fragmentation in Forwarding Plane

Fragmentation in forwarding plane takes effort only on forwarding traffic. Forwarding traffic
indicates the traffic passes through the local device, without being sent to the control plane.
Forwarding traffic does not include the traffic sent from control plane.
The NE40E/80E/CX600/ME60/NE5000E device provides rich board types. Different board
types may have different MTU fragmentation rules, as shown in Table 2-1.

NE40E/80E/5000E/CX600/ME60
Table 2-1 Fragmentation in Forwarding Plane
Figure 2-2 Fragmentation on motherboards
Fragmentation on motherboards or integrated boards:

 Fragmentation occurs only in IPv4 forwarding behaviors. IPv4 forwarding behaviors take effect both received
raw IPv4 packets and decapsulated IPv4 packets.
For example, MPLS L3VPN traffic is MPLS-encapsulated before being forwarded from a network-to-network
interface (NNI) to a user-to-network interface (UNI) on a provider edge (PE) node. PE fragments the traffic after
removing MPLS labels.
For another example, in L3VPN and high-speed Internet (HSI) scenarios, if a customer premises equipment (CPE)
uses a Dot1q or QinQ termination sub-interface to access a PE, the packet sent from CPE to PE is VLAN tagged.
In these scenarios, the packet is also fragmented on the PE after the VLAN tags are removed.
 Fragmentation does not occur during L2 or MPLS forwarding behavior.
 Fragmentation does not occur during IPv6 forwarding.
 V600R001 or later supports fragmentation for IP packets that enter MPLS tunnels. For detailed information, see
2.2 MPLS MTU Fragmentation.
 Force-fragment ( ipv4 force-fragment enable command ): By default, when the IPv4 packet’s length is larger
than the interface MTU, if DF=1, the packet is not permit to fragmented, and the device drops the packet and
return a Packet-too-big message. If force-fragment is enabled, the board ignoring DF-bit all IPv4 large packets
(size> MTU) will be cut into packets and be forwarded with DF=0. Force-fragment function is enabled only for
IPv4 packets, not for other type packets.

NE40E/80E/5000E/CX600/ME60
Figure 2-3 Fragmentation on integrated boards

NE40E/80E/5000E/CX600/ME60
Figure 2-4 Fragmentation on subcards
The difference between fragmentation on motherboards/integrated boards and that on subcards is as follows,
 Subcards do not differentiate between Layer 2 and Layer 3 traffic. VLANIF interface transmits both Layer 2
and Layer 3 traffic, and the subcards implement MTU fragmentation on both, with the exception of MPLS
L2VPN traffic. MPLS L2VPN traffic can be fragmented only if a PE UNI is configured as a VLANIF interface.
When the size of the IP header and payload in a Layer 2 packet exceeds the interface MTU, the VLANIF
interface fragments the Layer 2 packets. In each fragment, the size of the IP header and payload is less than or
equal to the interface MTU.
 The versions earlier than V600R006 do not support fragmentation for IP packets that enter MPLS tunnels, but
V600R006 and the later versions support. For detailed information, see 2.2 MPLS MTU Fragmentation.
2.2 MPLS MTU Fragmentation

MPLS MTU Definition
The Multiprotocol Label Switching (MPLS) MTU defines the maximum number of bytes in a
labeled packet that an MPLS device can forward without fragmenting the packet. In

NE40E/80E/5000E/CX600/ME60
NE40E/80E/CX600/ME60/NE5000E, the MPLS MTU is the maximum length of the sum of

the following fields:
 MPLS label stack
 IP header
 IP payload
Figure 2-5 MPLS MTU example
MPLS MTU Usage Scenarios

On NE40E/80E/CX600/ME60/NE5000E, the MPLS MTU takes effect only on Layer 3 traffic
traveling from IP networks to MPLS tunnels. The MPLS packets on which a specified MPLS
MTU takes effect must contain labels next to the IP headers. MPLS MTU usage scenarios are
as follows:
 MPLS L3VPN scenario, the traffic forwarding from User-to-network interface (UNI)
Network-to-network interface (NNI).
 IP traffic on PEs or Ps is directed into LSPs using policy-based routing (PBR), the
redirection function, static routes, Interior Gateway Protocol (IGP) shortcuts, and
forwarding adjacency.
 Packets originate from the control plane and are directed to LSPs. For example, run the
ping -vpn-instance or ping lsp command is executed on the device, the device
originates ICMP Request messages. These messages are IP packets and will be sent to
MPLS tunnels.
MPLS MTU Value Selection

The basic MPLS MTU formula is:
MPLS MTU = IP MTU + Number of labels x 4 bytes
On NE40E/80E/CX600/ME60/NE5000E, the following parameters may affect MPLS MTU
selection:
 configured interface MTU on the physical out interface
 configured MPLS MTU on the physical out interface
 PMTU negotiated by LDP signalling (for details about this parameter, see chapter 2.3
Protocols MTU Negotiation)
 PMTU negotiated by RSVP-TE signalling (for details about this parameter, see chapter
2.3 Protocols MTU Negotiation)
 configured interface MTU on the tunnel interface
For detailed rules of MPLS MTU Value Selection, see Table 2-3.

NE40E/80E/5000E/CX600/ME60
Table 2-2 MPLS MTU Value Selection Rules
Scenarios Parameters which may affect MPLS MTU value selection ("Y" indicates affect, "N"
indicates no affect, the smallest value among the affecting parameters is selected
as the MPLS MTU)
interface MTU MPLS MTU on PMTU PMTU interface MTU

on the physical the physical negotiated by negotiated on the tunnel
out interface out interface LDP signalling by interface
RSVP-TE
signalling
LDP LSP Y Y Y N N
MPLS-TE Y Y N Y V600R001
version: Y
the later version:
N
Y
LDP over TE Y Y Y N Y
NOTE
In LDP over TE scenario, interface MTU on the tunnel interface affects MPLS MTU value selection,
because the LDP LSP is over TE tunnel and the TE tunnel interface is an out interface of the LDP LSP.
According to the above rules, the selected MPLS MTU on

NE40E/80E/CX600/ME60/NE5000E is impossible larger than the physical interface MTU.
Therefore, the size of the MPLS-labeled packets are less than or equal to the physical
interface MTU and will not be discarded by the local device if DF=0.
Fragmentation Implementation for IP Packets That Enter MPLS Tunnels

If the size of the IP datagram and label in MPLS packets is greater than the MPLS MTU
value,

NE40E/80E/5000E/CX600/ME60
 if DF=0, the packet is fragmented. Each fragment (including the IP header and label) is
less than or equal to the MPLS MTU value.
 if DF=1, the packet is discarded and an ICMP Datagram Too Big message is sent to the
source end.
The NE40E/80E/CX600/ME60/NE5000E device provides rich board types. In forwarding
plane, different board types may have different MPLS MTU fragmentation rules, as shown in
Table 2-4.

NE40E/80E/5000E/CX600/ME60
Table 2-3 Fragmentation implementation for IP packets entering MPLS tunnels
Fragmentation mode Fragmentati MPLS Fragmentation

on Location Rules on the Forwarding
Plane
Motherboards  Versions earlier than
Figure 2-6 Mode A or integrated V600R001: The MPLS
boards MTU does not take effect.
 V600R001 and later
versions, including V8
versions: MPLS
fragmentation is
implemented only on the
ingress for IP packets
entering an MPLS tunnel.
When the total length of the
IP datagram and label of a
packet exceeds a specified
MPLS MTU, and DF is set to
0, the IP datagram is
fragmented. Each fragment is
attached one or more MPLS
labels and then forwarded.
When the total length of the
IP datagram and label of a
packet exceeds a specified
MPLS MTU, and DF is set to
1,
− if
forcible-fragmentatio
n is disabled: the IP
datagram is attached
with one or more
MPLS labels and then
forwarded, without
being fragmented.
− if
n is enabled: the IP
datagram is
fragmented, attached
one or more MPLS
labels, and then
forwarded.

NE40E/80E/5000E/CX600/ME60

Plane
Motherboards  Versions earlier than
Figure 2-7 Mode B or integrated V600R001: The MPLS
boards MTU does not take effect.
versions, including V8
versions:
− MPLS fragmentation
is implemented only
on the ingress for IP
packets entering an
MPLS tunnel. Do not
support
n.
− When the total length
of the IP datagram
and label of a packet
exceeds a specified
MPLS MTU, if the
DF is set to 0, the IP
datagram is
fragmented, attached
with one or more
MPLS labels, and
then forwarded. If DF
is set to 1, the packet
is discarded and a
Datagram-Too-Big
message is sent to
source end.

NE40E/80E/5000E/CX600/ME60

Plane
Subcards  Versions earlier than

Figure 2-8 Mode C V600R006: The MPLS
fragmentation is not
implemented.
versions: MPLS
fragmentation is supported.
The IP datagram is
fragmented based on the
interface MTU, not the
MPLS MTU. PEs and Ps
with these boards installed
can fragment MPLS packets
if the size of packets are
greater than the maximum
size allowed by the physical
outbound interface.
The packet is fragmented after
MPLS encapsulation. If the
subcard is enbled with
L3VPN fragmentation and
used as both PE NNI and P
NNI, all MPLS labeled
packets sent to the subcard are
fragmented when the DF is set
to 0 and the size of the packet
is greater than interface MTU.
2.3 Protocols MTU Negotiation

In addition to packet forwarding, the MTU is associated with some protocols.
OSPF MTU Negotiation

Defined in RFC 2328, Open Shortest Path First (OSPF) nodes exchange Database Description
(DD) packets that carry the interface MTU fields to negotiate MTU values.

NE40E/80E/5000E/CX600/ME60
According to RFC 2328, if an OSPF node receives a DD packet with an interface MTU value
less than the MTU of the local outbound interface, the OSPF relationship remains in the
ExStart state and fails to transition to the Full state.
Devices manufactured by different vendors may use the different rules to process DD packets:
 Some devices check the MTU values carried in DD packets by default, while allowing
users to disable the MTU check.
 Some devices do not check the MTU values carried in DD packets by default, while
allowing users to enable the MTU check.
 Other devices forcibly check the MTU values carried in DD packets.
Implementation inconsistencies between vendor-specific devices are a common cause of
OSPF adjacency problems.
NE40E/80E/CX600/ME60/NE5000E devices by default do not check MTU values carried in
DD packets and set the MTU values to 0 bytes before sending DD packets.
NE40E/80E/CX600/ME60/NE5000E devices allow to set the MTU value in DD packets to be
sent over a specified interface. After the DD packets arrive at
NE40E/80E/CX600/ME60/NE5000E device, the device checks the interface MTU field and
allows an OSPF neighbor relationship to reach the Full state only if the interface MTU field in
the packets is less than or equal to the local MTU.
IS-IS MTU Negotiation

Two Intermediate System to Intermediate System (IS-IS) devices exchange Hello packets to
establish and maintain an IS-IS adjacency. As defined in ISO 10589, the size of each Hello
packet must be greater than or equal to the interface MTU. If the Hello packet size is less than
the interface MTU, the Hello packet is padded with zeros so that its size is equal to the
interface MTU. This process ensures that IS-IS adjacencies are established only between
devices that can handle the maximum sized packets.
In NE40E/80E/CX600/ME60/NE5000E implement IS-IS in compliance with ISO 10589. By
default, only IS-IS interfaces with the same MTU value can establish an IS-IS adjacency.
On live networks, all interconnected router interfaces have the same MTU, and there is no
need to pad Hello packets with zeros. If an interface has a large MTU sends Hello packets at
short intervals, the interface has to pad a large number of Hello packets with zeros, which
wastes network resources.
NE40E/80E/CX600/ME60/NE5000E can be disabled from padding Hello packets with zeros,
which helps use network resources more efficiently.
NE40E/80E/CX600/ME60/NE5000E allows to configure an interface to pad Hello packets
with zeros before they are sent. By default, the following interface-specific rules for sending
Hello packets on NE40E/80E/CX600/ME60/NE5000E devices apply:
 Point-to-point (P2P) interfaces exchange Hello packets with the Padding field before
they establish an IS-IS neighbor relationship. After the IS-IS neighbor relationship is
established, the P2P interfaces exchange Hello packets without the padding field.
 Broadcast interfaces exchange Hello packets with the Padding field before and after they
establish an IS-IS neighbor relationship.

NE40E/80E/5000E/CX600/ME60
LDP PMTU Negotiation

As defined in RFC 3988, LDP label switching routers (LSRs) can automatically discover
MTU values along LDP LSPs. Each LSR selects the smallest value among all MTU values
advertised by downstream LSRs as well as the MTU of the outbound interface mapped to the
local forwarding equivalence class (FEC) before advertising the selected MTU value to the
upstream LSR.
The default LDP MTU values vary according to types of LSRs along an LSP as follows:
 The egress LSR uses the default MTU value of 65535.
 The penultimate LSR assigned an implicit-null label uses the default LDP MTU equal to
the MTU of the local outbound interface mapped to the FEC.
 Except the preceding LSRs, each LSR selects a smaller value as the local LDP MTU.
This value ranges between the MTU of the local outbound interface mapped to the FEC
and the MTU advertised by a downstream LSR. If an LSR receives no MTU from any
downstream LSR, the LSR uses the default LDP MTU value of 65535.
A downstream LSR adds the calculated LDP MTU value to the MTU type-length-value (TLV)
in a Label Mapping message and sends the Label Mapping message upstream.
Figure 2-9 LDP PMTU Negotiation
If an MTU value changes (such as when the local outbound interface or its configuration is
changed), an LSR recalculates an MTU value and sends a Label Mapping message carrying
the new MTU value upstream. The comparison process repeats to update MTUs along the
LSP.
If an LSR receives a Label Mapping message that carries an unknown MTU TLV, the LSR
forwards this message to upstream LDP peers.
NE40E/80E/CX600/ME60/NE5000E devices exchange Label Mapping messages to negotiate
MPLS MTU values before they establish LDP LSPs. Each message carries either of the
following two MTU TLVs:
 Huawei proprietary MTU TLV: sent by Huawei routers by default. If an LDP peer cannot
recognize this Huawei proprietary MTU TLV, the LDP peer forwards the message with
this TLV so that an LDP peer relationship can still be established between the Huawei
router and its peer.
 RFC 3988-compliant MTU TLV: specified by commands on
NE40E/80E/CX600/ME60/NE5000E. NE40E/80E/CX600/ME60/NE5000E uses this
MTU TLV to negotiate with non-Huawei devices.

NE40E/80E/5000E/CX600/ME60
RSVP-TE PMTU Negotiation

Resource Reservation Protocol-Traffic Engineering (RSVP-TE) nodes negotiate MPLS MTU
values and select the smallest value as the PMTU for a TE LSP.
The preceding MTU negotiation procedure applies to NE40E/80E/CX600/ME60/NE5000E
running all versions, except for V600R001. On NE40E/80E/CX600/ME60/NE5000E running
V600R001 and functioning as the ingress, a Path message with the ADSPEC object carries the
smallest value among the following three MTUs: the MTU configured on the physical
outbound interface, the configured MPLS MTU, and the MTU configured on the tunnel
interface.
In the involed versions, except for V600R001, the process of negotiating MTU values
between RSVP-TE nodes is as follows:
Figure 2-10 RSVP-TE PMTU Negotiation
1. The ingress sends a Path message with the ADSPEC object that carries an MTU value.
The smaller MTU value between the MTU configured on the physical outbound
interface and the configured MPLS MTU is selected.
2. Upon receipt of the Path message, a transit LSR selects the smallest MTU among the
received MTU value, the MTU configured on the physical outbound interface, and the
configured MPLS MTU. The transit LSR then sends a Path message with the ADSPEC
object that carries the smallest MTU value to the downstream LSR. This process repeats
until a Path message reaches the egress.
3. The egress uses the MTU value carried in the received Path message as the PMTU. The
egress then sends a Resv message that carries the PMTU value upstream to the ingress.
L2VPN MTU Negotiation

As defined in RFC 4447, RFC 4761, and RFC 4762, nodes negotiate MTU values before they
establish virtual circuits (VCs) or pseudo wires (PWs) on Layer 2 virtual private networks
(L2VPNs), such as pseudo wire emulation edge-to-edge (PWE3), virtual leased line (VLL),
and virtual private LAN service (VPLS) networks. An MTU inconsistency will cause two
nodes to fail to establish a VC or PW.
Type MTU Configuration Methods MTU Value Selection Rules

PWE  Method 1: Specify MTU parameter One of the following MTUs with
3 in the mpls switch-l2vc command. priorities in descending order is selected:
 Method 2: Configure the 1. Mtu parameter specified in the mpls
mtumtu-value command in the PW l2vc command or mpls switch-l2vc
template view. command
2. MTU configured in PW template
3. Interface MTU of the AC interface
4. Default MTU value (1500 bytes)

NE40E/80E/5000E/CX600/ME60
Type MTU Configuration Methods MTU Value Selection Rules

Kom Configure the mtumtu-value One of the following MTUs with
pella command in MPLS-L2VPN instance priorities in descending order is selected:
VLL view. 1. MTU configured in MPLS-L2VPN
instance view
VPL Configure the One of the following MTUs with
S mtumtu-valuecommand in VSI view. priorities in descending order is selected:
1. MTU configured in VSI instance view
By default, Huawei routers implement MTU negotiation for VCs or PWs. Two nodes must
use the same MTU to ensure that a VC or PW is established successfully. L2VPN MTUs are
only used to establish VCs and PWs and do not affect packet forwarding.
To communicate with non-Huawei devices that do not verify L2VPN MTU consistency,
L2VPN MTU consistency verification can be disabled on
NE40E/80E/CX600/ME60/NE5000E. This allows NE40E/80E/CX600/ME60/NE5000E to
establish VCs and PWs with the non-Huawei devices.

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU 3 MTU Configuration and Troubleshooting
3 MTU Configuration and Troubleshooting
About This Chapter

3.1 Interface MTU Setting
3.2 MPLS MTU Setting
3.3 MTU Problem Troubleshooting
3.4 MTU Typical Fault Cases
3.1 Interface MTU Setting

When nodes are properly communicating, use the default MTU value. Two nodes on both
ends of a link must use the same MTU value so that they can properly operate protocols, such
as OSPF and IS-IS, and successfully forward packets.
To change an interface MTU, run the mtumtu-value command in the interface view. For
information about MTU settings' impact on packet transmission is up to traffic type, interface
type and board type.
Each interface on NE40E/80E/CX600/ME60/NE5000E has a default interface MTU value.
The Table 3-1 lists interface default MTUs on NE40E/80E/CX600/ME60/NE5000E.
Table 3-1 Interface default MTUs
Interface Type Default Value Description

MTU Range
Value (Bytes)
(Bytes)
Ethernet interface 1500 46 to 1500 Interface MTUs take effect only on Layer 3 traffic.
Ethernet NOTE
sub-interface An Ethernet interface and its sub-interfaces work at Layer 3 by default
and send only Layer 3 traffic. After the portswitch command is run,
the Ethernet interface and its sub-interfaces work at Layer 2 and send
only Layer 2 traffic.

NE40E/80E/5000E/CX600/ME60
3 MTU Configuration and Troubleshooting Special Topic - MTU

MTU Range
Value (Bytes)
(Bytes)
Eth-Trunk interface 1500 46 to 9600  Interface MTUs take effect only on Layer 3 traffic.
Eth-Trunk NOTE
sub-interface An Eth-Trunk interface and its sub-interfaces work at Layer 3 by
default and send only Layer 3 traffic. After the portswitch command is
run in the Eth-Trunk interface view, the Eth-Trunk interface and its
sub-interfaces work at Layer 2 and send only Layer 2 traffic.
 The interface MTU must be changed in the Eth-Trunk
interface view or sub-interface view, not the member
interface view. After a member interface is added to an
Eth-Trunk interface, the Eth-Trunk interface MTU
automatically takes effect on the member interface. When
the Eth-Trunk interface MTU changes, member interfaces
automatically synchronize their MTU values with the
Eth-Trunk interface MTU.
 The MTU values on both ends of an Eth-Trunk link must be
the same. An MTU inconsistency may cause a service
interruption.
 If IPv6 runs on an Eth-Trunk interface and its sub-interfaces,
the interface MTU must be greater than or equal to 1280
bytes. A smaller MTU value causes IPv6 errors.
GE interface 1500  LPUI-41 Interface MTUs take effect only on Layer 3 traffic.
GE sub-interface and NOTE
LPUF-10 A GE interface and its sub-interfaces work at Layer 3 by default and
0 board: send only Layer 3 traffic. After the portswitch command is run in the
161 to GE interface view, the GE interface and its sub-interfaces work at
9600 Layer 2 and send only Layer 2 traffic.
 Other
boards:
46 to
9600

NE40E/80E/5000E/CX600/ME60

MTU Range
Value (Bytes)
(Bytes)
POS interface 4470 46 to 9600 It is recommended that you retain the default value.
Using an MTU value greater than 160 bytes on POS interfaces
is recommended on an LPUI-41, LPUF-100, and LPUI-100.
MTUs on POS interfaces do not take effect on IP
fragmentation subcards, because the boards do not fragment
packets.
Tunnel interface 1500 46 to 9600 Mainly used in LDP over TE scenario.
VLANIF interface 1500 46 to 9600  For fragmentation-capable subcards, VLANIF interfaces
take effect on both Layer 2 and Layer 3 traffic.
 For fragmentation-capable motherboards/integrated boards,
MTUs on VLANIF interfaces take effect only on Layer 3 IP
traffic.
Interface MTUs take effect only on Layer 3 traffic.
Virtual-Ethernet 1500 960 to 1518 Interface MTUs take effect only on Layer 3 traffic.
interface
Virtual-Template 1500 328 to 9600 Interface MTUs configured on VT interfaces are used in the
interface Link Control Protocol (LCP) phase. Two Point-to-Point
Protocol (PPP) nodes exchange packets to negotiate and select
the smaller one between two configured MTUs as the effective
MTU.
3.2 MPLS MTU Setting

When nodes are properly communicating, use the default MTU value.
To change an MPLS MTU on a specific interface, run the mpls mtumtu-value command in
the interface view.
An MPLS MTU change on a specific interface does not affect the interface MTU, while an interface
MTU change causes the effective MPLS MTU to update.
Suggestion for MPLS MTU Setting:

 The MPLS MTU on the interface takes effect only on IP traffic that enters MPLS
networks. The MTU handling modes vary according to board types.
 A too small MPLS MTU value leads to a great number of IP fragments, which
deteriorates device performance or even causes packet loss.
 If an MPLS MTU is greater than an interface MTU, the interface MTU value takes
effect.
 The interface MTU values on core routers' NNIs must be greater than those on core
routers' UNIs so that the NNIs can forward labeled packets sent by the UNIs. The

NE40E/80E/5000E/CX600/ME60
number of labels carried in an MPLS packet are different in various scenarios (see 4.1.2
Number of labels carried in an MPLS packet in various scenarios for detailed
information).
 The MPLS MTU value must be less than or equal to the interface MTU value. To enable
core routers to support more types of labeled packets, increase interface MTU values, not
MPLS values.
3.3 MTU Problem Troubleshooting

MTU Problem Description
On carrier networks, MTU definitions and fragmentation mechanisms vary according to
vendors and models of devices. Carrier networks with MTU inconsistency problems face the
challenges to user experience. The challenges stem from network problems, such as lag in
online games, link rot, delivery failure of emails with attachments, and errors in opening
dialog boxes. The problems are usually caused by interface MTU inconsistency.
In addition, interface MTU inconsistency also causes OSPF, IS-IS, L2VPN, and VPLS
connection failures.
MTU Troubleshooting Procedure

The troubleshooting procedure is as follows:
1. Analyze the path through which data packets pass.
2. View MTU values of outbound interfaces along the path through which data packets
pass and MTU values of transmission devices between nodes.
3. Send Ping packets with sizes greater than, less than, and equal to the interface MTU to
each node along the path.
If the ping packets with sizes greater than the interface MTU fail to be forwarded and the
ping packets with sizes less than and equal to the interface MTU are successfully
forwarded, the MTU settings cause the problem.
4. Analyze the headers in the dropped ping packets. For more information about packet
headers, see4.1.1 Packet Structures.
5. Increase the interface MTU to the size of the largest dropped packet.
The interface MTU setting must be based on the board-specific MTU fragmentation
mechanisms on Huawei routers and MTU definitions on vendor-specific devices.
6. Repeat steps 3, 4, and 5 until no packets are dropped.
MTU Troubleshooting in MPLS Scenarios

The troubleshooting procedure in MPLS scenarios is similar to the typical MTU
troubleshooting procedure. In addition, note the following issues:
 In NE40E/80E/CX600/ME60/NE5000E, MPLS VPN scenario, Ps forward MPLS
packets in a best-effort way without checking MPLS packet sizes or fragmenting MPLS
packets based on specified MTU values.
A P can fragment IP data encapsulated in an MPLS packet based on an MTU value only
when the following conditions are met:
1. Fragmentation-enabled subcards running V600R006 or later.

NE40E/80E/5000E/CX600/ME60
2. Fragmentation-enabled subcards provides both P NNIs and PE NNIs.

3. The mpls l3vpn fragment enable command is run on an Fragmentation-enabled
subcards to enable L3VPN fragmentation.
 If some MPLS packets with sizes greater than the MPLS MTU are discarded by Ps,
increase the interface MTU, not the MPLS MTU, to minimize packet loss. Increasing the
MPLS MTU alone cannot resolve this problem, because if an MPLS MTU is greater
than an interface MTU, the interface MTU value takes effect.
 Although NE40E/80E/CX600/ME60/NE5000E forward MPLS packets greater than the
MPLS MTU in a best-effort way, some ohter devices may discard these packets.
Therefore, analyze the number of labels in MPLS packets during the troubleshooting
process on a network with both NE40E/80E/CX600/ME60/NE5000E and other devices.
For information about labels carried in MPLS packets, see 4.1.2 Number of labels
carried in an MPLS packet in various scenarios.
When penultimate hop popping (PHP) is enabled on an LSP within an MPLS L3VPN, the penultimate
NE40E/80E/CX600/ME60/NE5000E removes the last label from an MPLS packet and forwards an IP
packet to the egress based on the MPLS MTU, not the interface MTU.
3.4 MTU Typical Fault Cases

3.4.1 L3VPN Users Fail to Access Some Websites
3.4.2 VPN Site Cannot Ping with Jumbo Frame of DF=1
3.4.3 OSPF Neighbor Relationship Cannot Be Established After a Service Cutover Is
Performed
3.4.1 L3VPN Users Fail to Access Some Websites

Symptom
On the MPLS L3VPN shown in Figure 3-1, users attached to the customer edge (CE) cannot
access some websites.
Figure 3-1 MPLS L3VPN
Trap Information
N/A

NE40E/80E/5000E/CX600/ME60
Cause Analysis
Perform the following steps:
1. Analyze the path through which data packets pass.
The network topology shows that L3VPN user packets pass through two routers named
PE1 and PE2. PE1 is a Huawei router, and PE2 is a non-Huawei router.
2. View MTU values configured on interfaces along the path.
The interface MTUs on PE1 and PE2 are 1500 bytes.
3. Enable PE1 to send ping packets within a specific VPN to PE2.
The ping vpn is successful when the ping packet sizes are less than or equal to 1500
bytes, whereas the ping fails when the ping packet sizes are greater than 1500 bytes. The
incorrect MTU setting causes the L3VPN user access failure.
4. Analyze L3VPN user packet headers.
Each L3VPN user sends a request to a web server using the Hypertext Transfer Protocol
(HTTP) over a TCP connection.
The data packets replied by web server are large. If a 1500-byte response IP packet is
sent to PE2, PE2 adds two labels (2 bytes + 2 bytes) into the packet and sets the DF field
to 1 before forwarding the packet. The packet becomes 1508 bytes long. PE2 finds that
the packet size is greater than the interface MTU and discards the packet. Then, PE2
replies with an ICMP Datagram Too Big message to the web server.
If the web server reduces the packet size to a value less than 1500 bytes, the response
from the web server can reach the L3VPN user, and the L3VPN user can access the web
server.
If the Datagram Too Big message cannot reach the web server or the web server receives
this message but does not change the MTU value, the web server still sends 1500-byte
packets. Upon receipt, PE2 discards the packets. As a result, the L3VPN user cannot
access the website
The preceding analysis shows that the incorrect MTU setting causes the L3VPN user access
failures.
Troubleshooting Procedure
1. Increase the MTU on the NNI on each PE to 1508 bytes.
After the modification, the L3VPN user cannot access any websites.
2. Check the path through which packets pass. A transmission device resides between PE1
and PE2.
3. Check the MTU fragmentation mechanism on the transmission device.
The transmission device calculates a packet size based on the IP MTU plus 18 bytes
(DMAC + SMAC + Length/Type + CRC). An L3VPN packet (1508 bytes) and 18 bytes
are 1526 bytes, while the MTU value on the transmission device is 1524 bytes. The
transmission device discards packets with the sizes greater than 1524 bytes. As a result,
the L3VPN user device attempts to resend HTTP packets over a TCP connection but fails
to access all websites.
4. Change the MTU on the transmission device to a value greater than or equal to 1526
bytes so that the transmission device does not discard user packets.
5. Initiate a ping.
The ping packets that are 1508 bytes long can reach the destination. The L3VPN user can
access all websites, and the problem is resolved.

NE40E/80E/5000E/CX600/ME60
Suggestion
If an MTU fault occurs, check MTU settings on both network devices and transmission
devices.
Check the label size in the MTU setting because the size of an MPLS VPN packet with labels
is greater than the IP packet size.
3.4.2 VPN Site Cannot Ping with Jumbo Frame of DF=1

Symptom
As shown in Figure 3-2, the MPLS backbone has two network:
 One is an MPLS L2 aggregated network which allows jumbo frame to pass; the
maximum length of the IP datagram (IP header + IP payload) is 9000Bytes. The sites
attached to the L2 aggregated network can access each other, and can access websites in
the Internet.
 The other is an MPLS L3 IP backbone network, all the interface MTUs of the routers use
the default value.
Now, the MPLS L3 IP backbone network is connected with the MPLS L2 aggregated network.
After the connection is completed, sites spanning the L2 and L3 IP backbones cannot ping
through each other with the ping 8973 Bytes.
Figure 3-2 MPLS VPN network
Trap Information
None
Cause Analysis
The sites attached to the L2 network can access each other, and can access websites in the
Internet. So, the trouble may exist between PE2 and site2.
Do the following steps to allocate the trouble.
1. Check whether site1 can ping though site2 or not by using pingdestination-address
command.
If not, there is a route problem, please troubleshooting the route between the site 1 and
site 2.
If yes, go to the step 2.

NE40E/80E/5000E/CX600/ME60
2. Check whether PE3 can ping though PE4 or not by using the ping -f -s
packetsize-vpn-instancevpn-name destination-ip-address command. (Note:
packetsize >9000 bytes - 20 bytes IP header - 8 bytes ICMP header = 8972 bytes,
because packetsize indicates the ICMP pay load length, not including ICMP header and
IP header. The packet is originated from CPU, so the fragmentation is calculated only
including IP header and IP payload, not including Label. The L3VPN packet fragment is
based on the MTU set in Tunnel interface if the L3 VPN using TE tunnel and L3 VPN
packet is originated from CPU).
If yes, check the MTU of the CE-facing interface on PE3 and PE4, and the PE-facing
interfaces of the edge device on site2, and set all of them to 9000 bytes.
If not, go to the step 3.
3. Check the MTU and MPLS MTU values of outbound interfaces along the path through
which ping-vpn-instance packets pass, including the MTU values of transmission
devices and L2 switches between nodes.
If the L3VPN uses TE tunnel or LDP over TE, the ping -vpn-instance packets on PE are
sent through the tunnel interface, so the MTU value on tunnel interface also take effect
on the ping -vpn-instance packets.
If the L3VPN uses LDP LSP(not including LDP over TE), the ping -vpn-instance
packets on PE are not sent through the tunnel interface, the MTU value on tunnel
interface does not take effect on the ping -vpn-instance packets.
If there is transmission device or L2 switch between routers, please make the
transmission devices or L2 switches allow IP packets with 9000 Bytes to go through.
If the steps stated above are done, to allow IP packet of 9000 Bytes to pass the L3 network, do
the flowing steps:
1. Modify all the interface MTU value on UNI (User-to-Network Interface) to 9000 bytes
2. Modify the MTU & MPLS MTU value of NNI (Network-to-Network Interface) to
9000+ 4*N (the value of N indicates the number of the MPLS labels in the MPLS packet,
which depends on the L3VPN tunnel type, for detailed information, see Number of
labels carried in an MPLS packet in various scenarios and Packet Structures.
3. If the L3VPN uses TE tunnel or LDP over TE, also modify the interface MTU and
MPLS MTU value on tunnel interface to 9000 bytes + 4*N (the value of N indicates the
number of the MPLS labels in the MPLS packet).
If the PE is an NE40E and the version is the V600R001, please shutdown and then undo shutdown the
MPLS tunnel interface and also reset the tunnel LSP (using reset mpls te tunnel-interface command) in
order for configurations to take effect. For other versions, it's not need to reset the tunnel interface and
tunnel LSP.
For calculation methods of MPLS L3VPN packet length during packet fragmentation, see "MPLS MTU
Fragmentation".
Suggestion
In MPLS L3VPN network, the interface MTU and MPLS MTU values on core routers' NNIs
are recommended to be greater than those on core routers' UNIs so that the NNIs can forward
labeled packets sent by the UNIs.
To enable core routers to support more types of labeled packets, increase both the interface
MTU values and MPLS MTU values.

NE40E/80E/5000E/CX600/ME60
3.4.3 OSPF Neighbor Relationship Cannot Be Established After a

Service Cutover Is Performed
Symptom
On the network shown in Figure 3-3 routers A and C are Huawei products, and Router B and
the switch are produced by another vendor.
Figure 3-3 OSPF networking
During a service cutover, the optical fiber connecting Router C to the switch is removed from
Router C and installed on Router A. Before the cutover, Router C and Router B establishes an
OSPF neighbor relationship. After the cutover, Router A and Router B cannot establish an
OSPF neighbor relationship, and their OSPF neighbor relationship is in the Exchange state.
The interface configurations on Router C and Router A are correct.
Router C's interface configuration is as follows:
#
interface Vlanif351
description XXXX
ip address x.x.x.158 255.255.255.252
ospf cost 30
mpls
mpls ldp
#
Router A's interface configuration is as follows:

interface GigabitEthernet3/1/15.351
mtu 1560
description XXXX
control-vid 351 dot1q-termination
dot1q termination vid 351
ip address x.x.x.158 255.255.255.252
pim sm
ospf cost 30
ospf mtu-enable
mpls
mpls ldp
arp broadcast enable
#

NE40E/80E/5000E/CX600/ME60
Trap Information
N/A
Cause Analysis
If OSPF packets are dropped, the OSPF neighbor relationship to remain in the Exchange state.
Perform the following steps to analyze the cause:
1. Configure Router A to send ping packets to Router B.
The ping is successful. The route between Router A and Router B is reachable.
2. Check whether MTU negotiation is successful.
Run the display ospf error command on Router A. The MTU option mismatch field is 0,
which indicates that MTU negotiation is successful.
3. Check whether interface MTU values match.
Both interface MTU values configured on Router A and Router C are 1560 bytes.
Enable Router A to send 1560-byte ping packets to Router B. The ping fails.
Check the JumboOctets count. The outbound statistics change, but inbound statistics
remain, which indicates that ICMP messages are sent successfully but there is no reply
received.
4. Change the interface MTUs on Router A and Router B to 1500 bytes.
An OSPF neighbor relationship is successfully established between the two routers.
5. The preceding analysis shows that the switch may have a configuration error.
6. Check the MTU setting on the switch.
The MTU value on the switch is set to 1546 bytes, which is different from the MTU
values on the routers.
The preceding analysis shows that the incorrect MTU setting on the switch causes the
problem.
1. Check the MTU definition on the switch.
Revert the MTU value to 1560 bytes. Use the bisection method to enable the switch to
send ping packets with the sizes ranging from 1500 to 1560 bytes. The ping results show
that a maximum number of 1518 bytes can be sent.
As the ICMP message size specified in a ping packet is 1518 bytes, the IP packet size is
1546 bytes, which is equal to the switch MTU. The IP packet size includes the 1518-byte
ICMP message, 8-byte ICMP header, and 20-byte IP header.
In conclusion, the switch's MTU is equal to the IP MTU and has the same meaning as the
Huawei router's interface MTU.
2. Change the MTU on the switch to 1560 bytes. The OSPF neighbor relationship between
Router A and Router B is successfully established, and the problem is resolved.
Suggestion
To analyze how a vendor-specific device defines a packet size, use the bisection method to
send ping packets with various sizes to find the maximum number of bytes that can be sent
and analyze the ping packet structure.

NE40E/80E/5000E/CX600/ME60
Special Topic - MTU 4 Appendix
4 Appendix
About This Chapter

4.1 Quick Search Table
4.2 Standard and RFCs
4.3 Abbreviation
4.1 Quick Search Table

4.1.1 Packet Structures
4.1.2 Number of labels carried in an MPLS packet in various scenarios
4.1.1 Packet Structures

In some scenarios, additional information, such as VLAN tags, MPLS labels, PPPoE headers,
or L2TP headers, exists between the IP and Ethernet frame headers in packets. For more
information, see the following table.
Table 4-1 Packet Structures
Type Format
Untagged
Ethernet
frame
Single-ta
gged
Ethernet
frame

NE40E/80E/5000E/CX600/ME60
4 Appendix Special Topic - MTU
Type Format
Double-t
agged
Ethernet
frame
(also
called
QinQ
frame)
PPPoE
frame
L2TP
packet
MPLS
L3VPN
packet
For information about N's values, see 4.1.2 Number of labels carried in an MPLS packet in various
scenarios.
MPLS
L2VPN
packet
For information about M's values, see 4.1.2 Number of labels carried in an MPLS packet in various
scenarios.
The number of VLAN tags varies according to user test interface types and PW encapsulation types.
For information about N's values, see Table 4-2.
Table 4-2 Number of VLAN tags carried in L2VPN packets
PW Encapsulation Type User Packets Number of VLAN Tags Carried in

Each L2VPN Packet
VPLS VLL/PWE3
Without U-TAG 0 tags
With U-TAG 1 U-TAG
Raw Ethernet
QinQ packets for access in 1 U-TAG
symmetrical mode

NE40E/80E/5000E/CX600/ME60
PW Encapsulation Type User Packets Number of VLAN Tags Carried in

Each L2VPN Packet
VPLS VLL/PWE3
QinQ packets for access in 0 tags
asymmetrical mode
Without U-TAG 1 P-TAG
With U-TAG 1 P-tag + 1 U-tag
Tagged VLAN QinQ packets for access in 1 S-tag + 1 U-tag

symmetrical mode
QinQ packets for access in 1 P-TAG
asymmetrical mode
4.1.2 Number of labels carried in an MPLS packet in various

scenarios
MPLS VPN Number of Labels Description
Scenario
One private network label and N Value of N (Depending on the Public-Network Tunnel
Intra-AS VPN
public network labels. Type):
 N is 1 when packets are transmitted on an LDP LSP.
Inter-AS VPN  A packet transmitted within an
Option A autonomous system (AS) carries  N is 1 when packets are transmitted on a static LSP.
one private network label and N  N is 1 when packets are transmitted on a TE tunnel.
public network labels.
 N is 2 when packets are transmitted on a TE tunnel in
 A packet transmitted between the LDP over TE scenario.
ASs caries no labels.
 N is 3 when packets are transmitted on a TE fast reroute
Inter-AS VPN  A packet transmitted within an (FRR) bypass tunnel in the LDP over TE scenario.
Option B AS carries one private network NOTE
label and N public network The preceding Ns take effect when the PHP function is disabled.
labels. If PHP is enabled and performed, N minus 1 (N - 1) takes effect.
 A packet transmitted between
ASs caries one private network
label.

NE40E/80E/5000E/CX600/ME60
MPLS VPN Number of Labels Description

Scenario
Inter-AS VPN  A packet sent within an original
Option C AS carries one private network
label, one Border Gateway
Protocol (BGP) label, and N
public network labels.
 A packet transmitted from the
original AS to another AS carries
one private network label and
one BGP label.
 A packet is transmitted in
non-original ASs, the packet
carries one private network label
and N public network labels.
 A packet transmitted within the
core layer carries an inner label
and N public network labels.
HoVPN and
 A packet transmitted between a
HVPLS
user-end provider edge (UPE)
and a superstratum provider edge
(SPE) carries one inner label.
4.2 Standard and RFCs

Document Title URL
No.
RFC 894 A Standard for the Transmission of IP http://www.ietf.org/rfc/rfc894

Datagrams over Ethernet Networks
RFC 1042 A Standard for the Transmission of IP http://www.ietf.org/rfc/rfc1042
Datagrams over IEEE 802 Networks
RFC 1134 The Point-to-Point Protocol: A http://www.ietf.org/rfc/rfc1134
Proposal for Multi-Protocol
Transmission of Datagrams Over
Point-to-Point Links
RFC 1191 Path MTU Discovery http://www.ietf.org/rfc/rfc1191
RFC 2328 OSPF Version 2 http://www.ietf.org/rfc/rfc2328
RFC 2923 TCP Problems with Path MTU http://www.ietf.org/rfc/rfc2923
Discovery
RFC 3988 Maximum Transmission Unit http://www.ietf.org/rfc/rfc3988
Signalling Extensions for the Label
Distribution Protocol

NE40E/80E/5000E/CX600/ME60
Document Title URL

No.
RFC 2460 Internet Protocol, Version 6 (IPv6) http://www.ietf.org/rfc/rfc2460

Specification
RFC 2463 Internet Control Message Protocol http://www.ietf.org/rfc/rfc2463
(ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification
RFC 1981 Path MTU Discovery for IP version 6 http://www.ietf.org/rfc/rfc1981
4.2.1 MIBs
OID MIB file MIB table MIB node Description of MIB
node
1.3.6.1.2.1.2 IF-MIB ifTable ifMtu[4] The size of the largest

.2.1 packet which can be
sent on the interface,
specified in octets.
1.3.6.1.2.1.5 IPv6-MIB ipv6IfStatsTab ipv6IfStatsInTo The number of input
5.1.6.1 le oBigErrors[3] datagrams that could
not be forwarded
because their size
exceeded the link MTU
of outgoing interface.
1.3.6.1.4.1.2 HUAWEI-O hwOspfv2Nei hwOspfv2NbrIf This object indicates
011.5.25.15 SPF-MIB ghborTable Mtu[8] the MTU of the
5.6.1 interface. The MTU can
be obtained from the
DD packets received
from the neighbor. If
the MTU is 0 in the DD
packets, it indicates that
the MTU is not filled in
the DD packet when the
packet is being sent on
the interface.
1.3.6.1.4.1.2 HUAWEI-R hwRsvpTeSen hwRsvpTeSend The composed
011.5.25.14 SVPTE-MI derTable erAdspecMtu[22 maximum transmission
8.1.2.1 B ] unit, general
characterization
parameter from the
ADSPEC. A return of
zero or noSuchValue
indicates one of the
following conditions:
the invalid bit was set
the parameter was not
present.

NE40E/80E/5000E/CX600/ME60
OID MIB file MIB table MIB node Description of MIB

node
1.3.6.1.4.1.2 HUAWEI-P hwPWVcTabl hwPWVcMtu[1 This object indicates
011.5.25.11 WE3-MIB e 8] the MTU value of the
9.4.1.1.1.1 AC interface on the
local node that is
associated with the PW.
1.3.6.1.4.1.2 HUAWEI-P hwPWRemote hwPwRemoteV The value of this object
011.5.25.11 WE3-MIB VcTable cMtu[5] identifies the MTU
9.4.1.1.4.1 value of remote PW.
1.3.6.1.4.1.2 HUAWEI-V hwVplsTable hwVplsMtu[7] This object indicates
011.5.25.11 PLS-EXT- the MTU of VPLS.
9.1.1.1.1 MIB
1.3.6.1.2.1.8 DISMAN-T traceRouteCtl TraceRouteCtlD This object enables
1.1.2.1 RACEROU Table ontFragment[17 setting of the don't
TE-MIB ] fragment flag (DF) in
the IP header for a
probe. Use of this
object enables
performing a manual
PATH MTU test.
1.3.6.1.4.1.2 HUAWEI-K hwKompellaV hwKompellaVp The value of this object
011.5.25.11 OMPELLA- pnTable nMtu[5] identifies the MTU
9.2.1.1.1 MIB value of the Kompella
VC.
4.3 Abbreviation
Abbreviation Full Spelling
B
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
BRAS Broadband Remote Access Server
C
CE Customer Edge
CPU Central Processing Unit
CRC Cyclic Redundancy Check
D
DD Data Description packet

NE40E/80E/5000E/CX600/ME60

DDOS Distributed Denial of Service
DF Do not Fragment
DSLAM Digital Subscriber Line Access Multiplexer
F
FEC Forwarding Equivalence Class
FDDI Fiber Distributed Data Interface
G
GE Gigabit Ethernet
GRE Generic Routing Encapsulation
H
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
I
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IP Internet Protocol
IPSec Internet Protocol Security
IPoE Internet Protocol over Ethernet
IPTV Internet Protocol Television
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IS-IS Intermediate System to Intermediate System
ISO International Organization for Standardization
ISP Internet Service Provider
L
L2TP Layer 2 Tunneling Protocol
L3VPN Layer 3 Virtual Private Network
LCP Link Control Protocol
LDP Label Distribution Protocol

NE40E/80E/5000E/CX600/ME60

LPU Line Processing Unit
LSP Labeled Switch Path
LSR Labeled Switching Router
M
MAC Media Access Control
MPLS Multiprotocol Label Switching
MSS Maximum Segment Size
MTU Maximum Transmission Unit
N
NNI Network to Network Interface
O
OSPF Open Shortest Path First
P
P2P Point to Point
PC Personal Computer
PE Provider Edge
PHP Penultimate Hop Popping
PIC Physical Interface Card
PMTU Path Maximum Transmission Unit
PPP Point-to-Point Protocol
PPPoE PPP over Ethernet
PW Pseudo Wire
PWE3 Pseudo-Wire Emulation Edge to Edge
Q
QinQ 802.1Q in 802.1Q
R
RFC Request For Comments
RSVP-TE Resource Reservation Protocol - Tranffic Engineering
T
TCP Transmission Control Protocol
TE Tranffic Engineering

NE40E/80E/5000E/CX600/ME60

TLV Type Length Value
U
UDP User Datagram Protocol
UNI User to Network Interface
V
VC virtual Circuit
VE Virtual Ethernet
VLAN Virtual Local Area Network
VLL Virtual Leased Line
VPLS Virtual Private LAN Service
VPN Virtual Private Network
W
WWW World Wide Web


Special Topic MTU (V2.0)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Special Topic MTU (V2.0)

Uploaded by

Copyright:

Available Formats

NE40E/80E/5000E/CX600/ME60

Special Topic - MTU

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential

About This Document

On carrier networks, MTU definitions and fragmentation mechanisms vary according to

Product Version Information

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential iii

iv Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

About This Document ................................................................................................................... iii

3 MTU Configuration and Troubleshooting ...........................................................................3-1

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential v

Figure 2-1 Fragmentation in Control Plane ........................................................................................................ 2-2

Figure 2-3 Fragmentation on integrated boards.................................................................................................. 2-5

Figure 2-5 MPLS MTU example ....................................................................................................................... 2-7

Figure 2-6 Mode A ........................................................................................................................................... 2-10

Figure 2-7 Mode B ........................................................................................................................................... 2-11

Figure 2-8 Mode C ........................................................................................................................................... 2-12

Figure 2-9 LDP PMTU Negotiation ................................................................................................................. 2-14

Figure 2-10 RSVP-TE PMTU Negotiation ...................................................................................................... 2-15

Figure 3-1 MPLS L3VPN .................................................................................................................................. 3-5

Figure 3-2 MPLS VPN network ......................................................................................................................... 3-7

Figure 3-3 OSPF networking.............................................................................................................................. 3-9

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential vii

Table 2-1 Fragmentation in Forwarding Plane ................................................................................................... 2-4

Table 4-1 Packet Structures ................................................................................................................................ 4-1

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential ix

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-1

1-2 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-3

1-4 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-5

1-6 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-7

1-8 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-9

1-10 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-11

1-12 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-13

1-14 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-15

1-16 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-17

1-18 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-19

1-20 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-21

1-22 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-23

1-24 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-25

1-26 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-27

1-28 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-29

1-30 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-31

1-32 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)

Issue 2.0 (2015-7-15) Huawei Proprietary and Confidential 1-33

1-34 Huawei Proprietary and Confidential Issue 2.0 (2015-7-15)