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

FAQ-The NE40E Cannot Generate the Public Network LSP Because of the Incorrect Path of the IGP Route

Publication Date:  2012-07-27 Views:  53 Downloads:  0
Issue Description
Q:
Two NE40Es work as PEs to connect two NE5000Es respectively on certain site. The NE5000Es are RRs.
Four devices locate in the same OSPF area.
Fault symptom: PE1 can receive the reflector route VPNv4 from RR1 but cannot write the reflector route VPNv4 in the routing tables of the VPN instance.
NE5000E(RR1)-----NE5000E(RR2)
| |
| |
NE40E(PE1)------NE40E(PE2) 
 
Alarm Information
1、<NE40E>display bgp vpnv4 all routing-table
Total number of routes from all PE: 2
Route Distinguisher: 65036:21632

Network NextHop MED LocPrf PrefVal Path/Ogn

*>i 10.150.10.0/29 60.214.156.153 0 100 0 ?
* i 10.150.10.0/29 60.214.156.153 0 100 0 ? ///

Total routes of vpn-instance cnc_signal: 4
Network NextHop MED LocPrf PrefVal Path/Ogn

i 10.150.10.0/29 60.214.156.153 0 100 0 ?
i 60.214.156.153 0 100 0 ?
*> 10.150.10.8/29 0.0.0.0 0 0 ?
*> 10.150.10.10/32 0.0.0.0 0 0 ?
Route can be learned from the MBGP routing table.
2.<NE40E>display ip routing-table vpn-instance cnc_signal //Related routes R - relay, D - download to fib cannot be seen in the VPN instance.
------------------------------------------------------------------------------
Routing Tables: cnc_signal
Destinations : 4 Routes : 4

Destination/Mask Proto Pre Cost Flags NextHop Interface

10.150.10.8/29 Direct 0 0 D 10.150.10.10 GigabitEthernet1/
0/4.2800
10.150.10.10/32 Direct 0 0 D 127.0.0.1 InLoopBack0
10.150.10.15/32 Direct 0 0 D 127.0.0.1 InLoopBack0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
3. The outgoing interface of the public network iterated by the private network route is null10
<zz_331_NE40E>display ip routing-table vpn-instance cnc_signal 10.150.10.0 29 ve
rbose
Destination: 10.150.10.0/29
Protocol: BGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 60.214.156.153 Neighbour: 221.1.252.132
State: Inactive Adv WaitQ Age: 00h03m27s
Tag: 0 Priority: 0
Label: 109568 QoSInfo: 0x0
RelayNextHop: 0.0.0.0 Interface: NULL0 ///The outgoing interface of the public network iteration is null0
TunnelID: 0x0 Flags: R

Destination: 10.150.10.0/29
Protocol: BGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 60.214.156.153 Neighbour: 221.1.252.130
State: Inactive Adv WaitQ Age: 00h03m27s
Tag: 0 Priority: 0
Label: 109568 QoSInfo: 0x0
RelayNextHop: 0.0.0.0 Interface: NULL0
TunnelID: 0x0 Flags: R 
 
Handling Process
A:
1. The MBGP routing table can learn the route of the peer PE, which indicates that the MBGP neighbor relationship is normal. Further ensure that the label allocation of the private network is normal, and then check the generation of the public network LSP and the iteration of the private route.
2. Check the detailed information about the private route.
3. Check and find that the public LDP session is normal and the LDP session between two P routers can be established.
<NE40E>dis mpls ldp session
221.1.252.130:0 Operational DU Passive 000:05:41 1366/1366
221.1.252.132:0 Operational DU Passive 000:05:41 1366/1366
4. Check the label allocation of the public LSP and find that an LDP session can be established between PE and P routers, but labels cannot be allocated.
<NE40E>display mpls ldp lsp 221.1.252.130 32
------------------------------------------------------------------------------
SN DestAddress/Mask In/OutLabel Next-Hop In/Out-Interface
------------------------------------------------------------------------------
*1 221.1.252.130/32 Liberal
*2 221.1.252.130/32 Liberal
5. Check the IGP routing of the loopback address on the P router.
<NE40E>display ip routing-table 221.1.252.130
Destination/Mask Proto Pre Cost Flags NextHop Interface
221.1.252.130/32 OSPF 10 61 D 60.214.159.153 GigabitEthernet2/0/2
The 32-bit loopback routing information of the P (RR1) router is learned from PE2 (anther NE40E device) instead of P router. The LDP neighbor relationship is not enabled on the two NE40E.
6. Check the IGP configuration and release of the device in the networking and find that on the NE5000E (RR1) side, OSPF is not enabled on the interface interconnected with the PE1. Modify the configuration of the IGP routing and then the learning path can be corrected.
<NE40E>display ip routing-table 221.1.252.130
Destination/Mask Proto Pre Cost Flags NextHop Interface
221.1.252.130/32 OSPF 10 61 D 60.214.159.165 GigabitEthernet2/0/3
After the modification, the routing information can be learned from the interface interconnecting PE and P routers.
7. The LDP allocation and the distribution of outgoing interface on the private route are recovered.
<NE40E>display ip routing-table vpn-instance cnc_signal 10.150.10.0 29 v Destination: 10.150.10.0/29
Protocol: BGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 60.214.156.153 Neighbour: 221.1.252.130
State: Active Adv GotQ Age: 00h07m17s
Tag: 0 Priority: 0
Label: 109568 QoSInfo: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet2/0/3 //The outgoing interface of the public network is correct. 
 
Root Cause
An interconnected link is configured between two NE40Es when the fault occurs. The loopback address of RR1 is learned from anther NE40E instead of the NE5000E. Therefore, although an LDP LSP session can be established, triggering the public network to allocate labels fails.
(No LDP is configured between the NE40Es. If the LDP is configured, the allocation for the labels of the public network can be triggered.) 
 
Suggestions
For the NE40E and NE80E, the writing of the private route can be achieved only if the LSP of the public network is normal. The allocation of the public network labels and the generation of the LSP should notice whether the learning path of the IGP routing can trigger the label. 

END