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

The Status of the LSP Frequently Alternated Between Up and Down on the NE40E Due to Special Networking

Publication Date:  2012-07-27 Views:  43 Downloads:  1
Issue Description
Refer to the appendix for the networking. The roles (P or PE) of devices can be known from their names.
At the site, LSP up/down was frequently printed in the log of nit-v (NE40E), but services were not affected. 

 
Alarm Information
Null
Handling Process
Checking nit_v, the engineer found the route xx.255.160.88LSP flapping constantly. Take the following as an example:
The network segment route xx.255.160.88/30 exists between tph_d and tph.p. On the existing network, all P and PE devices are configured with lsp-trigger all. Thus, an LSP is generated on tph_d. The label is sent to nit_v through sef.p. Then an ingress LSP is generated on nit_v because the label is consistent with the route (both are from POS 1/0/0).
<NIT_NE40e_V>dis mpls ldp lsp **.255.160.88 30 

                              LDP LSP Information                               
 ------------------------------------------------------------------------------ 
 SN     DestAddress/Mask   In/OutLabel   Next-Hop        In/Out-Interface       
 ------------------------------------------------------------------------------ 
 1      **.255.160.88/30   NULL/1069     **.255.160.213  -------/Pos1/0/0       
 ------------------------------------------------------------------------------ 
A ’*’ before an LSP means the LSP is not established
A ’*’ before a Label means the USCB or DSCB is stale
When nit_v advertises the labels upstream every 10s, the LSP goes Up. The route of 84.255.160.88 is in master/slave mode. Therefore, the next hop is only sef.p. Actually, tph.p also exists upstream.
The related route information is as follows:
<NIT_NE40e_V>dis ip rout 84.255.160.88 30
Routing Table: Public
Summary Count: 1
Destination/Mask    Proto  Pre  Cost       NextHop         Interface            
                                                                                
  **.255.160.88/30  OSPF   10   300        **.255.160.213  Pos1/0/0    
The interface information is as follows:
<NIT_NE40e_V>dis ip int brief pos
*down: administratively down
(l): loopback
(s): spoofing
Interface                   IP Address      Physical Protocol Description       
Pos1/0/0                    **.255.160.214  up       up       SEF_NE80e_7/0/3   
Pos1/0/1                    unassigned      *down    down     HUAWEI, Quidway   
Pos2/0/0                    **.255.160.118  up       up       TPH_NE80e_7/0/3   
Pos2/0/1                    unassigned      *down    down     HUAWEI, Quidway   
When receiving the label, tph.p deemed that the LSP is its own route. Therefore, tph.p sent the Release message downstream. After receiving this message, nit_v deleted the LSP. Then the LSP goes Down. That explained why the LSP kept alternating between Up and Down every 10s.
To sum up, the problem was caused by the special route configurations on the ring network. In this case, the engineer disabled the lsp-trigger all command on all NE40Es (PEs) where the segment LSPs were generated to solve the problem. 

 
Root Cause
Because services were not affected, the physical links and protocols must be running normally. In addition, the LSP that frequently went Up/Down must be the LSP of the network segment rather than that of the 32-bit host route. You need to check the specific flapping route entries to identify the real cause. 

 
Suggestions
On a network where the segment LSPs are unnecessary, it is recommended that you do not configure the lsp-trigger all command. 

 

END