Troubleshooting MPLS

LDP issues

LDP session down

Symptom

The LDP session cannot go up.

Common causes

The following are the common causes of this type of issue:

·     The interface establishing the session is in a Down state.

·     The LSR ID has been configured incorrectly.

·     Related configuration for the LDP session does not exist.

·     The transport address configuration is incorrect.

·     The LDP Hello-hold timer has timed out.

·     The LDP Keepalive-hold timer has timed out.

·     Security authentication configuration is incorrect.

Troubleshooting flow

Figure 1 shows the troubleshooting flowchart.

Figure 1 Flowchart for troubleshooting LDP session down

 

Solution

To resolve the issue:

1.     Identify whether the interface for establishing an LDP session is in the up state.

Execute the display interface command to check if the interface is in the up state:

¡     If the interface is not up, identify and eliminate any physical link faults to bring the interface to an up state.

¡     If the interface is in up state, proceed to step 2.

2.     Identify whether the LSR ID configuration is correct.

The LSR ID includes Local LSR ID, LDP LSR ID, and MPLS LSR ID. The priority of LSR ID from high to low is Local LSR ID, LDP LSR ID, and MPLS LSR ID. At least one type of LSR ID should be configured on the device and this LSR ID must be reachable at Layer 3.

Execute the display mpls ldp peer verbose command to check if the LSR ID is configured.

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

 Peer LDP ID      : 100.100.100.20:0

 Local LDP ID     : 100.100.100.17:0

 TCP Connection   : 100.100.100.20:47515 -> 100.100.100.17:646

…

If no LSR ID is configured, configure the LSR ID as follows:

¡     Configure the MPLS LSR ID in system view.

Execute the mpls lsr-id command in system view.

¡     Configure the LDP LSR ID in LDP view.

Execute the lsr-id command in LDP view.

¡     If it's a direct session, configure the Local LSR ID in interface view.

Execute the mpls ldp local-lsr-id command in interface view.

¡     If it's a remote session, configure the Local LSR ID in LDP peer view.

Execute the command mpls ldp local-lsr-id interface in LDP peer view.

If at least one type of LSR ID is configured, proceed to step 3.

3.     Identify whether relevant configuration for the LDP session exists.

If it's a direct session, execute the display this command in interface view to check if there's any related configuration for the LDP session on the interface.

¡     If the configuration does not include the mpls enable, mpls ldp enable, mpls ldp ipv6 enable, or mpls ldp transport-address commands, deploy the missing commands.

¡     If the related configuration for the LDP session exists, proceed to step 4.

If it's an LDP remote session, execute the display this command in LDP view to check if there is any related configuration of the LDP session.

¡     If the configuration does not include the targeted-peer or mpls ldp transport-address command, then deploy the missing commands.

¡     If the related configuration for the LDP session exists, proceed to step 4.

4.     Identify whether the transport address configuration is correct.

If it's an LDP IPv4 session, execute the display mpls ldp discovery verbose command to check if the transport address configuration is correct.

<Sysname> display mpls ldp discovery verbose

VPN instance: public instance

Link Hellos:

  Interface GigabitEthernet0/0/2

    Local LDP ID     : 100.100.100.17:0

    Hello Interval   : 5000 ms            Hello Sent/Rcvd  : 83/160

    Transport Address: 100.100.100.17

    Peer LDP ID      : 100.100.100.18:0

      Source Address : 202.118.224.18     Transport Address: 100.100.100.18

      Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

    Peer LDP ID      : 100.100.100.20:0

      Source Address : 202.118.224.20     Transport Address: 100.100.100.20

      Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

 

Targeted Hellos:

  100.100.100.17 -> 100.100.100.18 (Active, Passive)

    Local LDP ID     : 100.100.100.17:0

    Hello Interval   : 15000 ms           Hello Sent/Rcvd  : 23/20

    Transport Address: 100.100.100.17

    Session Setup    : Config/Tunnel

    Peer LDP ID      : 100.100.100.18:0

      Source Address : 100.100.100.18     Transport Address: 100.100.100.18

      Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

If it's an LDP IPv6 session, execute the display mpls ldp discovery ipv6 verbose command to check whether the transport address configuration is correct.

<Sysname> display mpls ldp discovery ipv6 verbose

VPN instance: public instance

Link Hellos:

  Interface GigabitEthernet0/0/2

    Hello Interval   : 5000 ms            Hello Sent/Rcvd  : 83/160

    Transport Address: 2001::2

    Peer LDP ID      : 100.100.100.18:0

      Source Address : FE80:130F:20C0:29FF:FEED:9E60:876A:130B

      Transport Address: 2001::1

      Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

 

Targeted Hellos:

  2001:0000:130F::09C0:876A:130B ->

        2005:130F::09C0:876A:130B(Active, Passive)

    Hello Interval   : 15000 ms           Hello Sent/Rcvd  : 23/22

    Transport Address: 2001:0000:130F::09C0:876A:130B

    Peer LDP ID      : 100.100.100.18:0

      Source Address : 2005:130F::09C0:876A:130B

      Destination Address : 2001:0000:130F::09C0:876A:130B

      Transport Address   : 2005:130F::09C0:876A:130B

      Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

If the transport address is incorrect, execute the mpls ldp transport-address command to configure the transport address in interface view or LDP peer view. By default, the transport address is the LSR ID of the local LSR.

If the transport address is correct, verify that the route is advertised. Execute the display ip routing-table command to check if there is a route to reach the session endpoint.

¡     If the route does not exist, configure the transport address as an IP address that exists on the local device to ensure the route can be properly advertised.

¡     If the route exists, proceed to step 5.

5.     Identify whether the LDP Hello-hold timer has timed out.

As a best practice, execute the display mpls ldp discovery command every 5 seconds to check the count of transmitted and received Hello messages. This would verify if the Hello messages are being transmitted correctly at both ends of the session. If the count of transmitted and received Hello messages does not change after several continuous command executions, it indicates an anomaly in the transmit and receive of Hello messages and the Hello-hold timing timer has timed out.

¡     If the Hello-hold timer times out, clear link faults and check the device's CPU usage. If the CPU usage is too high, disable some unnecessary features; if the CPU usage is normal, proceed to step 6.

¡     If the Hello-hold timer does not time out, proceed to step 6.

6.     Identify whether the LDP Keepalive-hold timer has timed out.

As a best practice, execute the display mpls ldp peer command every 15 seconds to check the transmit and receive counts of Keepalive messages, and identify whether the Keepalive messages are transmitted correctly at both ends of the session. If the counts do not change after several continuous command executions, it indicates an anomaly in transmitting or receiving Keepalive messages, and the Keepalive-hold timing has timed out.

¡     If the Keepalive-hold timer times out, resolve any packet forwarding issues.

¡     If the Keepalive-hold timer does not timeout, proceed to step 7.

7.     Identify whether the security authentication configuration is correct.

Execute the display mpls ldp peer command to check whether security authentication is configured on both ends of the LDP session, and whether the type of security authentication configured is consistent on both ends.

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID             State         Role     GR   Auth      KA Sent/Rcvd

2.2.2.9:0               Operational   Passive  Off  Keychain  39/39

¡     If the Auth field displays different values on both ends of the LDP session, then modify the security authentication on both ends of the LDP session to be consistent.

¡     If the Auth field displays the same value at both ends of the LDP session, then proceed to step 8.

8.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

Module Name: MPLS-LDP-STD-MIB

mplsLdpSessionDown (1.3.6.1.2.1.10.166.4.0.4)

Log messages

LDP/4/LDP_SESSION_CHG

LDP session flapping

Symptom

The LDP session state flaps frequently.

Common causes

The following are the common causes of this type of issue:

·     Interface flapping.

·     Route flapping.

·     High CPU usage.

Troubleshooting flow

Figure 2 shows the troubleshooting flowchart.

Figure 2 Flowchart for troubleshooting LDP session flapping

 

Solution

To resolve the issue:

1.     Identify whether the interface is flapping.

Execute the display interface brief command to observe the Physical and Protocol fields. If both Physical and Protocol fields are displayed as Up, it indicates that the interface state is up. Otherwise, it indicates that the interface state is down. If the interface keeps switching between the Up and Down states, it indicates interface is flapping.

¡     If the interface is flapping, resolve the interface issue.

¡     If the interface is not flapping, proceed to step 2.

2.     Identify whether the route is flapping.

Execute the display ip routing-table command to view route information. If the route information keeps switching between being displayed and not displayed, it indicates route flapping.

¡     If route flapping occurs, or the route has always been absent, resolve link issues and IGP route issues.

¡     If the route is not flapping, proceed to step 3.

3.     Identify whether the TCP packet is too large.

Execute the display tcp statistics command to view TCP connection traffic statistics. Determine if the TCP packet is excessively large by the value in the data packets retransmitted field in the Sent packets information.

¡     If the number of retransmitted packets continuously increases, it indicates that the TCP packet is too large. Execute the tcp mss command on the outgoing interface to adjust the TCP MSS value.

¡     If the number of retransmitted packets is not increased, it indicates that the TCP packet size is normal. Then, proceed to step 4.

4.     Identify whether the CPU usage is too high.

Execute the display cpu-usage command to view the statistical information of CPU usage.

¡     If the CPU usage is too high, disable some unnecessary features to lower the device's CPU usage.

¡     If the CPU usage is normal, proceed with step 5.

5.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

Module Name: MPLS-LDP-STD-MIB

mplsLdpSessionDown (1.3.6.1.2.1.10.166.4.0.4)

Log messages

LDP/4/LDP_SESSION_CHG

LDP LSP down

Symptom

In the LDP network, an LDP LSP cannot come up.

Common causes

The following are the common causes of this type of issue:

·     Route issue.

·     LDP session down.

·     Insufficient resources, for example, number of labels reaching the limit, or lack of memory.

·     LSP generation policy, label acceptance policy, label advertisement policy, or a label mapping propagation policy is configured.

·     The outgoing interface of the route is not the interface that establishes the LDP session.

Troubleshooting flow

Troubleshoot this type of issue in the following procedure:

1.     Identify whether the route exists.

2.     Identify whether the LDP session has been established properly.

3.     Identify whether there are issues of insufficient resources, for example, labels reaching the upper limit, or lack of memory.

4.     Identify whether an LSP generation policy has been configured.

5.     Identify whether the outgoing interface of the route is the interface used to establish the LDP session.

Figure 3 shows the troubleshooting flowchart.

Figure 3 Flowchart for troubleshooting LDP LSP down

 

Solution

To resolve the issue:

1.     Identify whether the route exists.

Execute the display ip routing-table ip-address mask verbose command to check if there is a route destined for the LSP destination address and is in active state (the State field value is Active Adv). For a public network BGP route, you also need to check if the route carries a label. If the Label field is not NULL, it indicates the BGP route carries a label.

<Sysname> display ip routing-table 1.1.1.1 32 verbose

 

Summary count : 1

 

 Destination: 1.1.1.1/32

    Protocol: O_INTRA

  Process ID: 1

   SubProtID: 0x1                       Age: 00h00m16s

  FlushedAge: 00h00m16s

        Cost: 1                  Preference: 10

       IpPre: N/A                QosLocalID: N/A

         Tag: 0                       State: Active Adv

   OrigTblID: 0x0                   OrigVrf: default-vrf

…

¡     If the route does not exist, the route exists but is not in active state, or the BGP route does not carry a label, resolve the routing failure.

¡     If the route exists and is in active state, and also carries a label when it is a BGP route, proceed to step 2.

2.     Identify whether the LDP session has been established properly.

Execute the display mpls ldp peer verbose command to check if the LDP session has been successfully established.

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

 Peer LDP ID      : 1.1.1.1:0

 Local LDP ID     : 2.2.2.2:0

 TCP Connection   : 2.2.2.2:14080 -> 1.1.1.1:646

 Session State    : Operational        Session Role     : Active

 Session Up Time  : 0000:00:14 (DD:HH:MM)

…

¡     If the Session State field is not displayed as Operational, it indicates that the LDP session was not established normally. Troubleshoot the LDP session issue as described in “LDP session down."

¡     If the Session State field displays Operational, it indicates that the LDP session has been established and come up. In this case, proceed to step 3.

3.     Identify whether an LSP acceptance or advertisement policy has been configured.

¡     In the LDP view, execute the display this command. If the following commands exist, you need to check whether the specified LSP has been filtered by an IP prefix list:

-     lsp-trigger prefix-list

-     accept-label peer prefix-list

-     advertise-label prefix-list

-     propagate mapping prefix-list

If an IP prefix list filters out the specified LSP, modify the IP prefix list to allow the destination address of the specified LSP to pass. If the IP prefix list does not filter the specified LSP, proceed to step 4.

¡     If the previous commands are not configured in the LDP view, proceed to step 4.

4.     Identify whether the outgoing interface of the route is the interface used to establish the LDP session.

Execute the display ip routing-table ip-address mask command to view the outgoing interface of the specified route.

<Sysname> display ip routing-table 1.1.1.1 32

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

1.1.1.1/32         O_INTRA 10  1           10.1.1.1        GE0/0/1

Execute the display mpls ldp peer peer-lsr-id verbose command to view the Discovery Sources information of the specified LDP peer.

<Sysname> display mpls ldp peer 1.1.1.1 verbose

VPN instance: public instance

 Peer LDP ID      : 1.1.1.1:0

 Local LDP ID     : 2.2.2.2:0

 TCP Connection   : 2.2.2.2:14080 -> 1.1.1.1:646

 Session State    : Operational        Session Role     : Active

 Session Up Time  : 0000:12:55 AM (DD:HH:MM)

 Max PDU Length   : 4096 bytes (Local: 4096 bytes, Peer: 4096 bytes)

 Keepalive Time     : 45 sec (Local: 45 sec, Peer: 45 sec)

 Keepalive Interval : 15 sec

 Msgs Sent/Rcvd   : 229/228

 KA Sent/Rcvd     : 223/223

 Label Adv Mode   : DU                 Graceful Restart : Off

 Reconnect Time   : 0 sec              Recovery Time    : 0 sec

 Loop Detection   : Off                Path Vector Limit: 0

 mLDP P2MP        : Off

 Discovery Sources:

   GigabitEthernet0/0/1

     Hello Hold Time: 15 sec           Hello Interval   : 5000 ms

 Addresses received from peer:

   10.1.1.1           1.1.1.1

¡     If the interface information in Discovery Sources field does not include the outgoing interface of the specified route, check whether the corresponding LDP configuration on the outgoing interface of the specified route and on the corresponding interface of the downstream device is correct. If it is incorrect, modify the corresponding configuration; if it is correct, proceed to step 5.

¡     If the interface information in the Discovery Sources field includes the outgoing interface of the specified route, proceed to step 5.

5.     Check for insufficient resources, such as number of LSPs reaching the upper limit or lack of memory.

¡     Identify whether the system memory is insufficient.

Execute the display memory-threshold command to check if the system is running out of memory. If the memory is insufficient, delete unnecessary LSPs.

¡     Identify whether the number of labels has exceeded the upper limit.

Execute the display mpls summary command and check if the number of idle labels in the LDP label range is 0, that is, the Idle field shows 0. If the idle label count is 0, it means that all label resources of the LDP have been used up, and it is necessary to delete unnecessary LSPs.

<Sysname> display mpls summary

MPLS LSR ID      : 2.2.2.2

Egress Label Type: Implicit-null

Entropy Label    : Off

Labels:

  Range                               Used/Idle/Total         Owner

  16-2047                             0/2032/2032             StaticPW

                                                              Static

                                                              StaticCR

                                                              Static SR Adj

                                                              BSID

  2048-599999                         9129/588823/597952      LDP

                                                              RSVP

                                                              BGP

                                                              BGP SR EPE

                                                              OSPF SR Adj

                                                              ISIS SR Adj

¡     If the issue of insufficient resources does not exist, proceed to step 6.

6.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

Module name: MPLS-LSR-STD-MIB

The node name (OID) is mplsXCDown (1.3.6.1.2.1.10.166.2.0.2).

Log messages

N/A

LDP LSP flapping

Symptom

In the LDP network, an LDP LSP flaps frequently.

Common causes

The following are the common causes of this type of issue:

·     Route flapping.

·     LDP session flapping.

Troubleshooting flow

Troubleshoot this type of issue in the following procedure:

1.     Identify whether the route is flapping.

2.     Identify whether the LDP session is flapping.

Figure 4 shows the troubleshooting flowchart.

Figure 4 Flowchart for troubleshooting LDP LSP flapping

 

Solution

To resolve the issue:

1.     Identify whether the route is flapping.

It is recommended to execute the display ip routing-table command every second continuously for 5 to 10 times to check the route to the LSP destination address. If the related route information keeps switching between displaying and not displaying, it indicates route flapping.

After viewing the route information, execute the display mpls ldp fec command to verify that the State field in the Downstream Info for the LSP established with the downstream peer has a value of Established.

<Sysname> display mpls ldp fec

VPN instance: public instance

 FEC: 1.1.1.1/32

   Flags: 0x112

   In Label: 2175

   Upstream Info:

     Peer: 1.1.1.1:0               State: Established

   Downstream Info:

     Peer: 1.1.1.1:0

       Out Label: 3                State: Established

       Next Hops: 10.1.1.1                GE0/0/1

   RIB Info:

     Protocol        : OSPF        BGP As Num   : 0

     Label Proto ID  : 1           NextHopCount : 1

     VN ID           : 0x313000003

     Tunnel ID       : -

¡     If route flapping occurs OR if the route never exists, please troubleshoot the routing issue.

¡     If the route is not oscillating, proceed to step 2.

2.     Identify whether the LDP session is flapping.

As a best practice, execute the display mpls ldp peer command every second, continuously for 5 to 10 times, to check the State field in the output information. If the value of this field is switching between Operational state and other states, it indicates that the LDP session is flapping.

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID             State         Role     GR   AUT       KA Sent/Rcvd

1.1.1.1:0               Operational   Active   Off  None      298/298

¡     If the LDP session is flapping, troubleshoot the flapping issue as described in “LDP session flapping.”

¡     If the LDP session is not flapping, proceed to step 3.

3.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

Module name: MPLS-LSR-STD-MIB

The node name (OID) is mplsXCDown (1.3.6.1.2.1.10.166.2.0.2).

Log messages

N/A