Protocols MTU Negotiation

OSPF MTU Negotiation

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

According to relevant standards, 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.

NetEngine 8000 F devices by default do not check MTU values carried in DD packets and set the MTU values to 0 bytes before sending DD packets.

NetEngine 8000 F devices allow the setting of the MTU value in DD packets to be sent over a specified interface. After the DD packets arrive at NetEngine 8000 F 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 NetEngine 8000 F 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.

NetEngine 8000 F can be disabled from padding Hello packets with zeros, which helps use network resources more efficiently.

NetEngine 8000 F allows the configuration of an interface to pad Hello packets with zeros before they are sent. By default, the following interface-specific rules for sending Hello packets on NetEngine 8000 F 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.

LDP PMTU Negotiation

As defined in relevant standards, 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 1 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.

NetEngine 8000 F 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.
• Relevant standards-compliant MTU TLV: specified by commands on NetEngine 8000 F. NetEngine 8000 F uses this MTU TLV to negotiate with non-Huawei devices.

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 process of negotiating MTU values between RSVP-TE nodes is as follows:

Figure 2 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 an Resv message that carries the PMTU value upstream to the ingress.

L2VPN MTU Negotiation

As defined in relevant standards, nodes negotiate MTU values before they establish virtual circuits (VCs) or pseudo wires (PWs) on Layer 2 virtual private networks (L2VPNs), such as Pseudowire 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.

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 NetEngine 8000 F. This allows NetEngine 8000 F to establish VCs and PWs with the non-Huawei devices.