No relevant resource is found in the selected language.
Enterprise
Worldwide
Search
Support Documentation
AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010 CLI-based Configuration Guide - MPLS

This document describes MPLS features on the device and provides configuration procedures and configuration examples.

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).
Configuring Basic Functions of MPLS LDP

Configuring Basic Functions of MPLS LDP

Pre-configuration Tasks

Before configuring basic functions of MPLS LDP, configure static routes or an IGP to ensure that IP routes between LSRs are reachable.

When Routing Information Protocol version 1 (RIP-1) is used, you need to enable LDP to search for routes to establish LSPs according to the longest match principle. For details, see Configuring LDP Extensions for Inter-Area LSPs.

You can build an MPLS network only after basic functions of MPLS LDP are configured.

Configuration Procedure

Configure basic functions of MPLS LDP according to the following sequence.

Configuring the LSR ID

Context

An LSR ID identifies an LSR on a network. An LSR does not have the default LSR ID, and you must configure an LSR ID for it. To enhance network reliability, you are advised to use the IP address of a loopback interface on the LSR as the LSR ID.

Perform the following steps on each node in an MPLS domain.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls lsr-id lsr-id

    The LSR ID of the local node is configured.

    By default, no LSR ID is set.

Follow-up Procedure

Before changing the configured LSP ID, run the undo mpls command in the system view.

Running the undo mpls command to delete all MPLS configurations will interrupt MPLS services, so plan the LSR ID of each LSP uniformly to prevent LSR ID change.

Enabling Global MPLS

Context

You can perform other MPLS configurations only after enabling global MPLS.

Perform the following steps on each node in an MPLS domain.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls

    MPLS is enabled globally and the MPLS view is displayed.

    By default, no node is enabled with MPLS.

Enabling Global MPLS LDP

Context

You can perform other MPLS LDP configurations only after enabling global MPLS LDP.

Perform the following steps on each node in an MPLS domain.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls ldp

    MPLS LDP is enabled globally and the MPLS LDP view is displayed.

    By default, LDP is not enabled globally.

  3. (Optional) Run lsr-id lsr-id

    The LSR ID is set for an LDP instance.

    By default, the LSR ID of the LDP instance is the LSR ID of the local node. It is recommended that the default value be used.

    In certain networking where VPN instances are used, such as BGP/MPLS IP VPN networking, if the VPN address and the LSR ID overlap, you need to configure LSR IDs for LDP instances to ensure that TCP connections can be correctly set up.

Configuring LDP Sessions

Context

The MPLS LDP session is classified into local LDP sessions and remote LDP sessions. You can choose one of the following configurations according to your requirements:

A local LDP session and a remote LDP session can coexist. That is, two LSRs can establish a local LDP session and a remote LDP session simultaneously. In this case, configurations of the local and remote LDP sessions at both ends must be the same.

Procedure

  • Configuring a local LDP session

    Perform the following steps on two directly connected LSRs.

    1. Run system-view

      The system view is displayed.

    2. Run interface interface-type interface-number

      The view of the interface on which the LDP session is to be set up is displayed.

    3. Run mpls

      MPLS is enabled on the interface.

      By default, no interface is enabled with MPLS.

    4. Run mpls ldp

      MPLS LDP is enabled on the interface.

      By default, no interface is enabled with LDP.

  • Configuring a remote MPLS LDP session

    Perform the following steps on the LSRs on both ends of a remote LDP session.

    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp remote-peer remote-peer-name

      The remote peer is created and the remote peer view is displayed.

    3. Run remote-ip ip-address

      The IP address of the remote MPLS LDP peer is configured.

      By default, the IP address of the remote LDP peer is not configured.

      This IP address must be the LSR ID of the remote MPLS LDP peer. If the LSR IDs of the LDP instance and the local node are different, use the LSR ID of the LDP instance.

      • Modifying or deleting the IP address of a remote peer leads to deletion of the remote LDP session and MPLS service interruption.

      • After the IP address of the remote peer is configured using the remote-ip ip-address command, the value of ip-address cannot be used as the IP address of the local interface. Otherwise, the remote session will be interrupted, causing MPLS service interruption.

(Optional) Configuring an LDP Transport Address

Context

LDP sessions are established based on TCP connections. Before two LSRs establish an LDP session, they need to check the LDP transport address of each other, and then establish a TCP connection.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number

    The view of the interface on which the LDP session is to be set up is displayed.

  3. Run mpls ldp transport-address { interface-type interface-number | interface }

    An LDP transport address is specified.

    The default transport address for a node on a public network is the LSR ID of the node, and the default transport address for a node on a private network is the primary IP address of an interface on the node.

    If LDP sessions are to be established over multiple links connecting two LSRs, LDP-enabled interfaces on either LSR must use the default transport address or the same transport address. If multiple transport addresses are configured on an LSR, only one transport address can be used to establish only one LDP session.

    Changing an LDP transport address interrupts an LDP session. Exercise caution when running this command.

(Optional) Configuring Timers for LDP Session

Context

Table 3-8 describes the timers for an LDP session.

Table 3-8  Timers for an LDP session

LDP Timer

Description

Suggestion
Hello send timer:
  • Link-Hello send timer (for only local LDP sessions)
  • Target-Hello send timer (for only remote LDP sessions)

Used to send Hello messages periodically to notify a peer LSR of the local LSR's presence and establish a Hello adjacency.

On an unstable network, decrease the value of a Hello send timer, speeding up network fault detection.
Hello hold timer:
  • Link-Hello hold timer (for only local LDP sessions)
  • Target-Hello hold timer (for only remote LDP sessions)

Used to exchange Hello messages periodically between two LDP peers to maintain the Hello adjacency. If no Hello message is received after the Hello hold timer expires, the Hello adjacency is torn down.

On a network with unstable links or a large number of packets, increase the value of the Hello hold timer, preventing the LDP session from being torn down and set up frequently.

Keepalive send timer

Used to send Keepalive messages periodically, maintaining the LDP sessions.

On an unstable network, set a smaller value for a Keepalive send timer, speeding up network fault detection.

Keepalive hold timer

Used to send LDP PDUs over an LDP session, maintaining the LDP session. If no LDP PDU is received after the Keepalive hold timer expires, the TCP connection is closed and the LDP session is terminated.

On a network with unstable links, increase the value of the Keepalive hold timer, preventing the LDP session from flapping.

Exponential backoff timer

Started by an LSR that plays an active role after an LDP Initialization message sent by the LSR to another LSR that plays a passive role fails to be processed or parameters carried in the message are rejected. The LSP that plays the active role periodically resends an LDP Initialization message to initiate an LDP session before the Exponential backoff timer expires.

  • When a device is upgraded, prolong the period for the active role to retry setting up a session. In this case, you can set larger initial and maximum values for the Exponential backoff timer.

  • When a device that bears services tends to alternate between Up and Down, shorten the period for the active role to retry setting up a session. In this case, you can set smaller initial and maximum values for the Exponential backoff timer.

When local and remote LDP sessions coexist, the timeout interval of the Keepalive hold timer of the local and remote LDP sessions must be the same.

Procedure

  • Configuring timers for a local LDP session
    1. Run system-view

      The system view is displayed.

    2. Run interface interface-type interface-number

      The view of an interface on which an LDP session is to be established is displayed.

    3. Run mpls ldp timer hello-send interval

      A link Hello send timer is configured.

      The default value of a link Hello send timer is one third of the value of a link Hello hold timer.

      Effective value of a link Hello send timer = Min {Configured value of the link Hello send timer, one third of the value of the link Hello hold timer}

    4. Run mpls ldp timer hello-hold interval

      A link Hello hold timer is configured.

      The default value of a link Hello hold timer is 15, in seconds.

      The smaller value between two configured link Hello hold timers on both ends of the LDP session takes effect.

    5. Run mpls ldp timer keepalive-send interval

      A Keepalive send timer is configured.

      The default value of a Keepalive send timer is one third of the value of the Keepalive hold timer.

      Effective value of a Keepalive send timer = Min { Configured value of the Keepalive send timer, one third of the value of the Keepalive hold timer }

      If more than one LDP-enabled links connect two LSRs, the values of Keepalive send timers for all links must be the same. Otherwise, LDP sessions become unstable.

      If one link connect to two LSRs and both the local and remote LDP sessions are configured between the LSRs, the values of Keepalive hold timers of the LDP sessions must be the same. Different settings cause the LDP sessions to be unstable or fail to be created.

    6. Run mpls ldp timer keepalive-hold interval

      A Keepalive hold timer is configured.

      The default value of a Keepalive hold timer is 45, in seconds.

      The smaller value between two configured Keepalive hold timers on both ends of the LDP session takes effect.

      If more than one LDP-enabled links connect two LSRs, the values of Keepalive hold timers for all links must be the same. Otherwise, LDP sessions may fail to be set up.

      If one link connect to two LSRs and both the local and remote LDP sessions are configured between the LSRs, the values of Keepalive hold timers of the LDP sessions must be the same. Different settings cause the LDP sessions to be unstable or fail to be created.

      Changing the Keepalive hold timer value in an instance will interrupt the MPLS service in the instance because the LDP session must be reestablished.

    7. Configure an Exponential backoff timer.

      1. Run quit

        The system view is displayed.

      2. Run mpls ldp

        The MPLS LDP view is displayed.

      3. Run backoff timer init max

        An Exponential backoff timer is configured.

        By default, the initial value is 15 and the maximum value is 120, in seconds. Setting the initial value of the Exponential backoff timer to be greater than or equal to 15s and the maximum value to be greater than or equal to 120s is recommended.

  • Configuring timers for a remote LDP session
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp remote-peer remote-peer-name

      The remote MPLS LDP peer view is displayed.

    3. Run mpls ldp timer hello-send interval

      The target Hello send timer is configured.

      The default value of the target Hello send timer is one third of the value of a target Hello hold timer that takes effect.

      Effective value of a target Hello send timer = Min { Configured value of the target Hello send timer, One third of the value of the target Hello hold timer }

    4. Run mpls ldp timer hello-hold interval

      The target Hello hold timer is configured.

      The default value of the target Hello hold timer is 45, in seconds.

      The smaller value between two configured target Hello hold timers on both ends of the LDP session takes effect.

    5. Run mpls ldp timer keepalive-send interval

      A Keepalive send timer is configured.

      The default value of a Keepalive send timer is one third of the value of the Keepalive hold timer.

      Effective value of a Keepalive send timer = Min { Configured value of the Keepalive send timer, one third of the value of the Keepalive hold timer }

      If more than one LDP-enabled links connect two LSRs, the values of Keepalive send timers for all links must be the same. Otherwise, LDP sessions become unstable.

      If one link connect to two LSRs and both the local and remote LDP sessions are configured between the LSRs, the values of Keepalive send timers of the LDP sessions must be the same. Different settings cause the LDP sessions to be unstable or fail to be created.

    6. Run mpls ldp timer keepalive-hold interval

      A Keepalive hold timer is configured.

      The default value of a Keepalive hold timer is 45, in seconds.

      The smaller value between two configured Keepalive hold timers on both ends of the LDP session takes effect.

      If more than one LDP-enabled links connect two LSRs, the values of Keepalive hold timers for all links must be the same. Otherwise, LDP sessions may fail to be set up.

      If one link connect to two LSRs and both the local and remote LDP sessions are configured between the LSRs, the values of Keepalive send timers of the LDP sessions must be the same. Different settings cause the LDP sessions to be unstable or fail to be created.

      Changing the Keepalive hold timer value in an instance may interrupt the MPLS service in the instance because the LDP session must be reestablished.

    7. Configure an Exponential backoff timer.

      1. Run quit

        The system view is displayed.

      2. Run mpls ldp

        The MPLS LDP view is displayed.

      3. Run backoff timer init max

        An Exponential backoff timer is configured.

        By default, the initial value is 15 and the maximum value is 120, in seconds. Setting the initial value of the Exponential backoff timer to be greater than or equal to 15s and the maximum value to be greater than or equal to 120s is recommended.

(Optional) Configuring the PHP Feature

Context

No label needs to be swapped on the egress node of an LSP. PHP can be configured on the egress node to allow the LSR at the penultimate hop to pop out the label from an MPLS packet and send the packet to the egress node. After receiving the packet, the egress node directly forwards the packet through an IP link or according to the next layer label. PHP helps reduce the burden on the egress node.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls

    The MPLS view is displayed.

  3. Run label advertise { explicit-null | implicit-null | non-null }

    The label allocated to the LSR at the penultimate hop is configured.

    The egress node can allocate different labels to the PHP based on the parameter setting.

    • implicit-null: default value, which indicates that PHP is supported. If this parameter is configured, the egress node allocates an implicit null label with the value of 3 to the LSR at the penultimate hop.

    • explicit-null: PHP is not supported. If this parameter is configured, the egress node allocates an explicit null label with the value of 0 to the LSR at the penultimate hop. The explicit-null parameter can be configured when MPLS QoS attributes are used.

    • non-null: PHP is not supported. If this parameter is configured, the egress allocates a common label with a value greater than or equal to 16 to the LSR at the penultimate hop.

    After the label advertise command is run to change the label distribution mode on the egress node, the modification takes effect on new LSPs but not on existing LSPs. To enable the modification to take effect on the existing LSPs, run the reset mpls ldp or lsp-trigger command.

(Optional) Configuring an LDP Label Distribution Control Mode

Context

By default, the LDP label distribution control mode is ordered. In the ordered mode, an LSR advertises the mapping between a label and an FEC to its upstream LSR only when this LSR is the outgoing node of the FEC or receives the Label Mapping message of the next hop for the FEC. If you want to quickly deploy services, you can set the LDP label distribution control mode to independent. In the independent mode, a local LSR can distribute a label bound to an FEC and then inform the upstream LSR, without waiting for the label distributed by the downstream LSR.

However, in the independent mode, an LSP cannot be established if the local LSR does not receive the label for the FEC distributed by the downstream LSR. The ingress node cannot detect an LSP establishment failure and keeps on forwarding service packets. When service packets reach the LSR, the LSR fails to forward the packets to its downstream LSR, causing service interruption. For example, services cannot be switched from the primary LSP to the backup LSP, resulting in service interruption.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls ldp

    The MPLS-LDP view is displayed.

  3. Run label distribution control-mode { independent | ordered }

    An LDP label distribution control mode is specified.

    The default LDP label distribution control mode is ordered.

(Optional) Configuring an LDP Label Advertisement Mode

Context

By default, a downstream node sends Label Mapping messages to its upstream node. When faults occur on the network, services can be fast switched to the standby path, improving network reliability. Edge devices on the MPLS network are low-end devices. To ensure network reliability, resources must be fully used. You can configure the Downstream on Demand (DoD) mode to save system resources. In DoD mode, the downstream LSR sends a Label Mapping message to the upstream LSR only when the upstream LSR sends a Label Request message to the downstream LSR.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number

    The interface view is displayed.

  3. Run mpls ldp advertisement { dod | du }

    A label advertisement mode is configured.

    By default, the label advertisement mode is downstream unsolicited (DU).

    Modifying a configured label advertisement mode leads to the reestablishment of an LDP session, resulting in MPLS service interruption.

(Optional) Configuring LDP to Automatically Trigger the Request in DoD Mode

Context

On a large-scale network, to reduce the burden on edge devices, use the DoD mode. Because edge devices cannot learn the accurate route to the remote peer, an LDP LSP cannot be set up even if LDP extensions for inter-area LSPs are configured. You can configure the DoD mode in which the local LSR requests a Label Mapping message from a specified downstream LSR or all LSRs to set up an LDP LSP.

Before configuring LDP to automatically trigger the request in DoD mode, perform the following operations:

Procedure

  • Configure automatic triggering of a request to a downstream node for a Label Mapping message associated with all remote LDP peers in DoD mode.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Run remote-peer auto-dod-request

      The LDP is configured to automatically trigger a request to the downstream node for a label mapping message associated with all remote LDP peers in DoD mode.

      By default, when the DoD is not used, the local LSR requests Label Mapping messages from all downstream LSRs.

  • Configure automatic triggering of a request to a downstream node for a Label Mapping message associated with a remote LPD peer with a specified LSR ID in DoD mode.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp remote-peer remote-peer-name

      A remote MPLS LDP peer is created and the remote MPLS-LDP peer view is displayed.

    3. Run remote-ip auto-dod-request [ block ]

      The LDP is configured to automatically trigger a request to the downstream node for a label mapping message associated with a remote LDP peer with a specified LSR ID in DoD mode.

      By default, the configuration of the remote-peer auto-dod-request command is inherited.

      If the remote-peer auto-dod-request command is used, you can specify block to disable automatic triggering of a request to a downstream node for a label mapping message associated with a remote LDP peer of a specified LSR ID in DoD mode.

(Optional) Configuring MPLS MTU

Context

The size of the maximum transmission unit (MTU) determines the maximum number of bytes that can be transmitted by the sender at a time. If the MTU exceeds the maximum number of bytes supported by the receiver or a transit device, packets are fragmented or even discarded, which increases the network transmission load. In this manner, devices have to calculate the MTU before the communication to ensure that sent packets reach the receiver successfully.

LDP MTU = Min {All MTUs advertised by all downstream devices, MTU of the local outbound interface}

A downstream LSR uses the preceding formula to calculate an MTU, adds it to the MTU TLV in a Label Mapping message, and sends the Label Mapping message to the upstream device. If an MTU value changes (such as when the local outbound interface or its configuration is changed), an LSR recalculates an MTU and sends a Label Mapping message carrying the new MTU to its upstream LSR. The relationships between the MPLS MTU and the interface MTU are as follows:

  • If an interface MTU but not an MPLS MTU is configured on an interface, the interface MTU is used.

  • If both an MPLS MTU and an interface MTU are configured on an interface, the smaller value between the MPLS MTU and the interface MTU is used.

MPLS determines the size of MPLS packets on the ingress node according to the LDP MTU to prevent the transit node from forwarding large-sized MPLS packets.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls ldp

    The MPLS LDP view is displayed.

  3. Run the following commands as required.

    • Run undo mtu-signalling

      The LSR is disabled from sending Label Mapping messages carrying MTU TLVs.

      By default, the router sends Label Mapping messages carrying the Huawei private MTU TLV.

      If a non-Huawei device does not support the MTU TLV, to implement interworking, configure the device not to encapsulate the MTU TLV in Label Mapping messages. If the LSR is disabled from sending the MTU TLV, the configured MPLS MTU does not take effect.

    • Run mtu-signalling apply-tlv

      The LSR is configured to send Label Mapping messages carrying MTU TLVs that comply with RFC 3988.

      By default, the router sends Label Mapping messages carrying Huawei proprietary MTU TLV.

      If a non-Huawei device supports the MTU TLV, to implement interworking, configure the device to send Label Mapping messages carrying MTU TLVs that comply with RFC 3988. Otherwise, the configured MPLS MTU may not take effect.

    Enabling or disabling the function to send an MTU TLV leads the reestablishment of existing LDP sessions, resulting in MPLS service interruption.

  4. Run quit

    The system view is displayed.

  5. Run interface interface-type interface-number

    The view of an MPLS-enabled interface is displayed.

  6. Run mpls mtu mtu

    An MPLS MTU is configured on the interface.

    By default, the MTU of MPLS packets is equal to the interface MTU.

    The MPLS MTU takes effect in L2VPN (VLL and PWE3) scenarios only.

(Optional) Configuring the MPLS TTL Processing Mode

Context

MPLS processes the TTL in the following modes:

  • MPLS TTL processing modes

    In MPLS VPN applications, the MPLS backbone network needs to be shielded to ensure network security. The MPLS Pipe mode on the ingress node is recommended for private network packets. To reflect the path where packets pass, use the MPLS Uniform mode on the ingress node.

  • Path where ICMP response packets are transmitted

    By default, when the received MPLS packet contains only one label, the LSR directly sends an ICMP response packet to the sender using an IP route. When the received MPLS packet contains multiple labels, the LSR sends an ICMP response packet to the sender along an LSP.

    The MPLS VPN packets may contain only one label when they arrive at an autonomous system boundary router (ASBR) on the MPLS VPN, or a superstratum PE (SPE) device in HoVPN networking. These devices have no IP routes to the sender, so they forward the ICMP response packets along an LSP.

Procedure

  • Configuring the MPLS TTL processing mode

    Perform the following steps on the ingress node.

    1. Run system-view

      The system view is displayed.

    2. Run undo ttl propagate

      The MPLS TTL processing mode is set to Pipe.

      Or run ttl propagate:

      The MPLS TTL processing mode is set to Uniform.

      By default, the TTL propagate function is enabled and the MPLS TTL processing mode is Uniform.

      The ttl propagate command only take effect on LSPs that are to be set up. Before using the function on LSPs that have been set up, run the reset mpls ldp command to reestablish the LSPs.

  • Configuring the path where ICMP response packets are transmitted

    Perform the following steps on the ingress and egress nodes.

    1. Run system-view

      The system view is displayed.

    2. Run mpls

      The MPLS view is displayed.

    3. Run undo ttl expiration pop

      The device is configured to transmit ICMP response packets along an LSP.

      Or run ttl expiration pop:

      The device is configured to transmit ICMP response packets using an IP route.

      By default, upon receiving an MPLS packet with one label, an LSR returns an ICMP response packet using a local IP route.

(Optional) Configuring the LDP Label Policies

Context

The LSR distributes labels to both upstream and downstream LDP peers, which increases the LDP LSP convergence speed. However, receiving and sending Label Mapping messages result in the establishments of a large number of LSPs, which wastes resources. To reduce the number of LSPs and save memory, use the following policies:

  • Configure the LSP label filtering policy.

    Configure LDP inbound policy or outbound policy to restrict the receiving and sending of Label Mapping messages.

  • Configure the LDP split horizon policy.

    Access devices on the MPLS network have low performance If LDP distributes labels to all peers, a large number of LSPs will be established, which cannot be processed by the LSR. The split horizon policy is recommended.

Procedure

  • Configure an inbound LDP policy.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Run inbound peer { peer-id | peer-group peer-group-name | all } fec { none | host | ip-prefix prefix-name }inbound peer 2.2.2.2 fec host inbound peer peer-group group1 fec noneinbound peer 2.2.2.2 fec hostinbound peer 2.2.2.2 fec host inbound peer 2.2.2.2 fec noneinbound peer 2.2.2.2 fec none

      An inbound policy for allowing the local LSR to receive Label Mapping messages from a specified LDP peer for a specified IGP route is configured.

      To apply a policy associated with a single Forwarding Equivalence Class (FEC) range to an LDP peer group or all LDP peers from which the local LSR receives Label Mapping messages, configure either the peer-group peer-group-name or all parameter in the command.

      If multiple inbound policies are configured for a specified LDP peer, the first configured one takes effect. For example, the following two inbound policies are configured:

      As group1 also contains an LDP peer with peer-id of 2.2.2.2, the following inbound policy takes effect:

      If two inbound policies are configured in sequence and the peer parameters in the two commands are the same, the second command overwrites the first one. For example, the following two inbound policies are configured:

      The second configuration overwrites the first one. This means that the following inbound policy takes effect on the LDP peer with peer-id of 2.2.2.2:

  • Configure an outbound LDP policy.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Perform either of the following steps to apply the outbound policy that allows Label Mapping messages for specified routes to be sent to a specified LDP peer:

      • To configure an outbound policy that allows Label Mapping messages for specified IGP routes to be sent to a specified LDP peer, run:

        outbound peer { peer-id | peer-group peer-group-name | all } fec { none | host | ip-prefix prefix-name }

      • To configure an outbound policy that allows Label Mapping messages for specified labeled Border Gateway Protocol (BGP) routes to be sent to a specified LDP peer, run:

        outbound peer { peer-id | peer-group peer-group-name | all } bgp-label-route { none | ip-prefix prefix-name }

      To apply a policy associated with a single Forwarding Equivalence Class (FEC) range to an LDP peer group or all LDP peers to which the local LSR sends Label Mapping messages, configure either the peer-group peer-group-name or all parameter in the command.

      If multiple outbound policies are configured for a specified LDP peer, the first configured one takes effect. For example, the following two outbound policies are configured:

      outbound peer 2.2.2.2 fec host
outbound peer peer-group group1 fec none

      As group1 also contains an LDP peer with peer-id of 2.2.2.2, the following outbound policy takes effect:

      outbound peer 2.2.2.2 fec host

      If two outbound policies are configured in sequence and the peer parameters in the two commands are the same, the second command overwrites the first one. For example, the following two outbound policies are configured:

      outbound peer 2.2.2.2 fec host
outbound peer 2.2.2.2 fec none

      The second configuration overwrites the first one. This means that the following outbound policy takes effect on the LDP peer with peer-id of 2.2.2.2:

      outbound peer 2.2.2.2 fec none

  • Configure an LDP split horizon policy.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Run outbound peer { peer-id | all } split-horizon

      A split horizon policy is configured to distribute labels to only upstream LDP peers.

      By default, split horizon is not enabled and an LSR distributes labels to both upstream and downstream LDP peers.

      The all parameter takes preference over the peer-id parameter. For example, the outbound peer all split-horizon and then outbound peer 2.2.2.2 split-horizon commands are run, the outbound peer all split-horizon command can be saved in the configuration file and take effect, not the outbound peer 2.2.2.2 split-horizon command.

Follow-up Procedure

  • To delete all inbound policies, run the undo command multiple times to delete them one by one, or run the undo inbound peer all command to delete them simultaneously. The first method takes a long time.

  • To delete all outbound policies, run the undo command multiple times to delete them one by one, or run the undo outbound peer all command to delete them simultaneously. The first method takes a long time.

(Optional) Disabling a Device from Distributing Labels to Remote Peers

Context

In MPLS L2VPN scenarios using LDP (including Martini VLL and PWE3), PEs at both ends need to establish a remote LDP session. The remote LDP session is only used to transmit Label Mapping messages, so LDP is not required. By default, LDP allocates common LDP labels to remote peers. Many useless idle labels are generated, wasting LDP labels.

To solve the preceding problem, disable a device from distributing labels to remote peers to save system resources. You can use either of the following modes:

  • In the LDP view, disable the PE from distributing labels to all remote peers.

  • In the view of a specified remote peer, disable the PE from distributing labels to the specified remote peer.

Procedure

  • Disable a device from distributing labels to a specified remote peer.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp remote-peer remote-peer-name

      The remote MPLS LDP peer view is displayed.

    3. Run remote-ip ip-address pwe3

      LDP is prevented from allocating public network labels to a specified remote peer device.

      By default, the IP address of the remote LDP peer is not configured.

  • Disable a device from distributing LDP labels to all remote peers.
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Run remote-peer pwe3

      LDP is prevented from allocating public network labels to all remote peer devices.

      By default, an LSR is permitted to distribute public network labels to all remote peers.

(Optional) Configuring a Policy for Triggering LDP LSP Establishment

Context

After MPLS LDP is enabled, LSPs are automatically established. If no policy is configured, an increasing number of LSPs are established, wasting resources.

  • Configure the lsp-trigger command on the ingress and egress nodes to trigger LSP setup based on routes. This setting controls the number of LSPs and saves network resources.

  • Configure the propagate mapping command on the transit node to allow LDP to use routes matching specified conditions to establish transit LSPs. For the routes that do not match specified conditions, the local device does not send Label Mapping messages to the upstream device, which reduces the number of LSPs and saves network resources.

By default, the lsp-trigger command is used. If policies cannot be configured on the ingress and egress nodes, configure the propagate mapping command on the transit node.

Procedure

  • Perform the following steps on the ingress and egress nodes:
    1. Run system-view

      The system view is displayed.

    2. Run mpls

      The MPLS view is displayed.

    3. Run the following commands as required.

      • Run lsp-trigger { all | host | ip-prefix ip-prefix-name | none }

        A policy for triggering LSP establishment based on static and IGP routes is configured.

        By default, the policy is host. This policy allows LDP to use 32-bit host-address routes to establish LSPs.

        LSPs can be established using exactly matching routes on LSRs. For example, an exactly matching host route to an IP address with a 32-bit mask of a loopback interface can be used to trigger LSP establishment.

      • Run lsp-trigger bgp-label-route [ ip-prefix ip-prefix-name ]

        A policy for triggering LSP establishment based on labeled public network BGP routes is configured.

        By default, LDP does not allocate labels to labeled BGP routes on the public network.

    4. Run proxy-egress disable

      The device is disabled from establishing proxy egress LSPs.

      By default, a device is enabled to establish proxy egress LSPs.

      If a policy allows a device to use all static and IGP routes to establish LSPs or use an IP address prefix list to establish LSPs, the policy also triggers proxy egress LSP establishment. However, the proxy egress LSPs may be unavailable, which wastes system resources. To prevent this problem, run the proxy-egress disable command to disable a device from establishing such proxy egress LSPs.

  • Perform the following steps on the transit nodes:
    1. Run system-view

      The system view is displayed.

    2. Run mpls ldp

      The MPLS LDP view is displayed.

    3. Run propagate mapping for ip-prefix ip-prefix-name

      A policy for triggering transit LSP establishment is configured.

      By default, LDP uses all routes without filtering them to establish transit LSPs.

(Optional) Configuring Delayed Transmission of Label Withdraw Messages

Context

An LSP on a local node flaps because an LDP session between the node and its downstream peer flaps, a route flaps, or an LDP policy is modified. The local node repeatedly sends Label Withdraw and Label Mapping messages in sequence to upstream nodes. This causes the upstream nodes to repeatedly tear down and reestablish LSPs. As a result, the entire LDP LSP flaps. The label withdraw delay function prevents the entire LDP LSP from flapping.

Perform the following steps on each node of an LDP LSP:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls ldp

    The MPLS-LDP view is displayed.

  3. Run label-withdraw-delay

    The label withdraw delay function is enabled.

    By default, the label withdraw delay function is disabled.

  4. Run label-withdraw-delay timer time

    The delay time for a Label Withdraw message to be sent is set.

    The default delay time is 5 seconds.

(Optional) Disabling LDP from Tearing Down a Session After Error Packets Are Received

Disabling LDP from tearing down a session after error packets are received is beneficial to service maintenance and can also be used for LDP fault recovery.

Context

LDP should tear down a session after error TCP packets are received. This processing mode causes the LDP session to frequently flap and L2VPN services carried on the LDP session to be frequently interrupted. To resolve these problems, disable LDP from tearing down a session after error packets are received.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mpls ldp

    The MPLS LDP view is displayed.

  3. Run maintain-session received-error-message

    LDP is disabled from tearing down a session after error packets are received.

    By default, LDP tears down a session after error packets are received.

Verifying the Configuration of Basic MPLS LDP Functions

Prerequisites

The configurations of the MPLS LDP function are complete.

Procedure

  • Run the display default-parameter mpls management command to check default configurations of the MPLS management module.
  • Run the display default-parameter mpls ldp command to check the default configurations of MPLS LDP.
  • Run the display mpls interface [ interface-type interface-number ] [ verbose ] command to check information about MPLS-enabled interfaces.
  • Run the display mpls ldp [ all ] [ verbose ] command to check LDP information.
  • Run the display mpls ldp interface [ interface-type interface-number | [ all ] [ verbose ] ] command to check information about LDP-enabled interfaces.
  • Run the display mpls ldp adjacency [ interface interface-type interface-number | remote ] [ peer peer-id ] [ verbose ] command to check information about LDP adjacencies.
  • Run the display mpls ldp adjacency statistics command to check statistics about LDP adjacencies.
  • Run the display mpls ldp session [ [ all ] [ verbose ] | peer-id ] command to check the LDP session status.
  • Run the display mpls ldp session statistics command to check statistics about sessions between LDP peers.
  • Run the display mpls ldp peer [ [ all ] [ verbose ] | peer-id ] command to check information about LDP peers.
  • Run the display mpls ldp peer statistics command to check statistics about LDP peers.
  • Run the display mpls ldp remote-peer [ remote-peer-name | peer-id lsr-id ] command to check information about the LDP remote peer.
  • Run the display mpls ldp lsp [ all ] command to check LDP LSP information.
  • Run the display mpls ldp lsp statistics command to check statistics about LDP LSPs.
  • Run the display mpls route-state [ { exclude | include } { idle | ready | settingup } * | destination-address mask-length ] [ verbose ] command to check the dynamic LSP route.
  • Run the display mpls lsp [ verbose ] command to check LSP information.
  • Run the display mpls lsp statistics command to check statistics about the LSPs that are in the Up state and the number of the LSPs that are activated on the ingress, transit, and egress nodes.
  • Run the display mpls label all summary command to check allocation information about all MPLS labels.
Translation
简体中文
Download
Updated: 2023-08-07

Document ID: EDOC1100034073

Views: 158762

Downloads: 402

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Digital Signature File

Digital Signature Authentication Mode
Share
Previous Next

Copyright © 2023 Huawei Technologies Co., Ltd. All rights reserved.

You are going to visit :