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>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

A TE CR-LSP Path Was Not the Expected One Because CSPF Was Globally Disabled

Publication Date:  2013-10-25 Views:  44 Downloads:  0
Issue Description

Network topology:

CID:/icase/servlet/download?dlType=HtmlAreaImage&imageId=20466

 

The NCT and SHM sites deployed NE40E-X8 and had TE tunnels to the sites at the opposite end. All the TE tunnels, which were established using explicit paths, were controlled by a tunnel policy to share load.

tunnel0/0/480 configured on NCT-1 was the TE tunnel from NCT-1 to SHM-1 and was specified by an explicit path to pass hop POS_1/2/2. Configurations for tunnel0/0/480 and the explicit path are as follows:

interface Tunnel0/0/480
 description TO Sharm-01-ST
 ip address unnumbered interface LoopBack0
 tunnel-protocol mpls te
 destination 10.64.1.48
 mpls te tunnel-id 480
 mpls te record-route label
 mpls te path explicit-path sharm10-pos-1/2/2
 mpls te igp shortcut
 mpls te igp metric absolute 1
 mpls te reserved-for-binding
 mpls te commit
 statistic enable
#
explicit-path sharm10-pos-1/2/2
  next hop 10.167.16.34
#

After a technician ran tracert lsp te tunnel0/0/480 on NCT-1, the following path information was displayed:

<NCT-RNC-NE40E-01>tracert lsp te Tunnel 0/0/480
  LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel0/0/480 , press CTRL_C to break.
  TTL   Replier            Time    Type      Downstream
  0                  Ingress   10.167.16.38/[65545 ]
   1     10.64.1.48         17 ms   Egress     

The command output indicates that the LSP path carried by tunnel0/0/480 passed POS_5/0/2, instead of POS_1/2/2.
Handling Process

To address the issue, Huawei performed the following operations and observed the following information:

1. Checked logs of NCT-1 and SHM-1.

On NCT-1, an alarm indicating that POS_1/2/2 was down was found. On SHM-1, no alarm indicating that a POS interface was down was found. Therefore, routes to interface 10.167.16.34 (POS_1/3/0) of SHM-1 were advertised to NCT-1 using OSPF. On NCT-1, as POS_1/2/2 of NCT-1 was down, the egress interface for routes to interface 10.167.16.34 of SHM-1 was POS_5/0/2. As such, during the TE re-establishment process, RSVP packets were forwarded through POS_5/0/2.

2. Checked configurations on NCT-1 and SHM-1.

CSPF was disabled. As a result, a CR-LSP was not set up as a strict explicit path, and the tunnel carrying the CR-LSP took POS_5/0/2. When POS_/1/2/2 on NCT-1 became up, the path did not change because the mpls te record-route label command was executed for tunnel0/0/480.
Root Cause
CSPF was disabled globally. As a result, when setting up a CR-LSP on tunnel0/0/480, NCT-1 used the egress interface of the route to the next-hop IP address as the egress interface of the next hop, instead of using the egress interface of the strict next-hop. This fault generally occurs on routers located at both ends of a transmission network. This is because in such a scenario, when the interface at one end of a transmission link is down, the interface at the other end is generally not down.
Solution

1. When the physical link is normal:

Reset the tunnel, or

Delete the mpls te record-route label command and run the mpls te commit and mpls te record-route label commands for tunnel0/0/480, so a CR-LSP is set up based on the normal routing algorithm.

2. Enable CSPF globally.
Suggestions
If an explicit path is specified to pass over a specified physical link, enable CSFP globally and configure a strict explicit path.

END