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

Interfaces of the Next Hops of the Master&Slave Links of the NE40 MPLS VPN Are Iterated on the Same Outgoing Port

Publication Date:  2012-07-27 Views:  49 Downloads:  0
Issue Description
                  |pos 3/0/0 ldp peer ---RR (reflector)
NE40----|
                  |pos 7/0/0 ldp peer ---RR (reflector)
VPN routes need to constitute the master/slave relationship through the next hops of the two LDP peers. However, the outbound interfaces are both POS 7/0/0. If we shut down this port, the VPN routes cannot be forwarded.
<M-SR-NE40-BH-SICHUANLU>disp mpls ldp peer

LDP Peer Information in Public network
------------------------------------------------------------------------------
Peer-ID                     Transport-Address        Discovery-Source
------------------------------------------------------------------------------
222.217.182.1:0        222.217.182.1             Pos7/0/0
222.217.182.2:0         222.217.182.2            Pos3/0/0
------------------------------------------------------------------------------
<M-SR-NE40-BH-SICHUANLU>disp ip routing-table vpn-instance GXBH-ITMS-MGMT 172.113.0.0 // Only one next hop

Routing Table : GXBH-ITMS-MGMT
Summary Count : 1

Destination/Mask   Proto   Pre   Cost   NextHop                  Interface

172.113.0.0/19       BGP   255     0      222.217.182.14       Pos7/0/0
[M-SR-NE40-BH-SICHUANLU]disp ip routing-table vpn-instance GXBH-ITMS-MGMT 172.113.0.0 verbose
Routing Table : GXBH-ITMS-MGMT
Summary Count : 2

Destination: 172.113.0.0/19
Protocol: BGP          Process ID: 0
Preference: 255       Cost: 0
NextHop: 222.217.182.14     Interface: Pos7/0/0
RelayNextHop: 0.0.0.0           Neighbour: 222.217.182.1
Label: 37888            Tunnel ID: 0x1C12652
SecTunnel ID: 0x0
BkNextHop: 0.0.0.0                 BkInterface:
BkLabel: NULL                        Tunnel ID: 0x0
SecTunnel ID: 0x0
State: Active Adv GotQ             Age: 20d03h15m57s
Tag: 0

Destination: 172.113.0.0/19
Protocol: BGP                           Process ID: 0
Preference: 255                       Cost: 0
NextHop: 222.217.182.14      Interface: Pos7/0/0 // Theoretically, this port should be POS 3/0/0.
RelayNextHop: 0.0.0.0            Neighbour: 222.217.182.2
Label: 37888                             Tunnel ID: 0x1C12652
SecTunnel ID: 0x0
BkNextHop: 0.0.0.0                 BkInterface:
BkLabel: NULL                        Tunnel ID: 0x0
SecTunnel ID: 0x0
State: Inactive Adv GotQ         Age: 20d03h15m57s
NE40 version:
VRP (R) software, Version 5.30(NE40&80 V300R002C01B599) 
 
Alarm Information
Null
Handling Process
It is typical networking, with two RRs as LDP peers, forming two tunnels for iteration.
It is confirmed that this version has the following iteration features:
The iteration of outbound interfaces depends on the iterated tunnels.
The iteration of tunnels depends on the next hops of routes.
Because the two VPN routes have the same next hop, the next hop is iterated to the same tunnel and the outbound interfaces are iterated to the same port.
It is a normal thing.
For LDP load balancing, you need to add the tunnel policy.
The way to configure the policy is described as follows:
tunnel-policy 1
tunnel select-seq lsp load-balance-number 2
Access the VPN instance:
ip vpn-instance GXBH-ITMS-MGMT
tnl-policy 1
After the policy is configured, LDP load balancing can be realized. 
 
Root Cause
This version supports LDP load balancing. Therefore, the problem is probably caused by the configuration or networking. 
Suggestions
Null

END