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

Feature Description - LAN Access and MAN Access 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 Feature Description - LAN Access and MAN Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Protocols MTU Negotiation

Protocols MTU Negotiation

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

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.

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

NE devices allow to set the MTU value in DD packets to be sent over a specified interface. After the DD packets arrive at NE 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 NE 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.

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

NE 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 NE 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 7-8 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.

NE 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 NE. NE 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 7-9 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 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 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
PWE3
  • Specify MTU parameter in the mpls switch-l2vc command.
  • Configure the mtu mtu-value command in the PW template view.
One of the following MTUs with priorities in descending order is selected:
  1. Mtu parameter specified in the mpls l2vc command or mpls switch-l2vc command
  2. MTU configured in PW template
  3. Interface MTU of the AC interface
  4. Default MTU value (1500 bytes)
Kompella VLL Configure the mtu mtu-value command in MPLS-L2VPN instance view. One of the following MTUs with priorities in descending order is selected:
  1. MTU configured in MPLS-L2VPN instance view
  2. Default MTU value (1500 bytes)
VPLS Configure the mtu mtu-valuecommand in VSI view. One of the following MTUs with priorities in descending order is selected:
  1. MTU configured in VSI instance view
  2. Default MTU value (1500 bytes)

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

Translation
Download
Updated: 2019-01-14

Document ID: EDOC1100058932

Views: 7280

Downloads: 11

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next