An NE40 VRP3.10-2317 and an MXXX from J supplier are connected through two 100 Mbit/s Ethernet interfaces. All services except the MPLS services can run properly. The NE40 uses the loopback address to be bound to a VPN instance and attempts to ping the VPN instance-bound interface. However, the ping operation fails.
1. The on-site technical support personnel check the configurations on the NE40 and the MXXX and find that all configurations are correct. The routing table on each device can learn the route destined for the peer loopback address.
2. They check the NE40 and find that the route to the MXXX's loopback address is load balanced through two 100 Mbit/s interfaces. The 100 Mbit/s interface (M160-Eth2) is preferentially selected in the routing table on the MXXX to perform load balancing. In practice, both 100 Mbit/s interfaces must load balance the configured static routes and OSPF costs.
3. NE40s running VRP3.10 does not support LDP load balancing. Run the display mpls lsp include loopback address and display efu fib 1 service address 32 vpn name commands to check the Eth-Trunk interface on the LSP through which traffic is load balanced. The command outputs show that NE40-Eth1 is the interface on which load balancing is performed. Perform step 2 on the MXXX to search the routing table. NE40-Eth2 is connected to the MXXX. Therefore, the LSP cannot be established, which causes the MPLS services to be interrupted.
The possible causes on the MPLS side are as follows:
1. Check the MBGP routing table to check whether the private network routes entries to the peer end are learned and whether the next hop is correct using the display bgp vpnv4 all routing-table command. The command output shows that the routes to the peer end can be learned.
2. Check whether LDP can assign a public network label to the loopback address of the peer end using the display mpls lsp include loopback address command. The command output shows that the NE40 assigns a public network labels to the loopback address of the peer end but the MXXX does not assign an LDP label to the NE40.
The possible causes on the LDP side are as follows:
1. The NE40 and the MXXX do not learn each other's loopback address.
2. LDP may not be enabled on an interface or a device along the forwarding path to the loopback address of the peer end.
NE40E version VRP3 is not support LDP Load Balancing, cause NE40 and MXXX could not adapt on forwarding way,which causes the MPLS services to be interrupted.
Configure the OSPF route to be the primary route and the static route to be the secondary route. After the configuration is complete, the LSP can be established as expected and the services recover.
1. VRP3.10 versions running on NE40s/80s/8016s do not support LDP load balancing. Additionally, pay attention to the possible impacts of performing load balancing and deploying MPLS in versions before VRP5.30 is released officially. You are advised to prevent a problem by using an IGP and configuring a primary route and a secondary route. The MXXX does not support LDP load balancing either.
2. Tracert plays an important role in locating the problem in this case. For example, when the NE40 traces the service address of the MXXX, the messages are forwarded through two interfaces. However, when the MXXX traces the NE40, only one interface is used. Based on this information, the return routing table on the MXXX may be abnormal. The NE40 does not support MPLS tracert, so the asterisk (*) may be displayed on the cascaded devices. But this does not affect the determination of the forwarding path.