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>Search

Reminder

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

upgrade

AR Router Troubleshooting Guide

This Product Documentation provides guidance for maintaining AR Enterprise Router, covering common information collection and fault diagnostic commands, typical fault troubleshooting guide, and troubleshooting.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
A PE Fails to Establish the Public Network LSP Because the Path of IGP Routes Is Incorrect

A PE Fails to Establish the Public Network LSP Because the Path of IGP Routes Is Incorrect

Fault Symptom

As shown in Figure 19-14, PE1 can receive VPNv4 routes reflected from RR1, but these routes cannot be installed in the routing table of the VPN instance. That is, there is associated routing information in the BGP VPNv4 routing table but not in the routing table of the IPv4 VPN instance on PE1.

Figure 19-14  Failure to establish a public network LSP on a PE

Fault Analysis

  1. Run the display bgp vpnv4 all routing-table command on PE1 to view the BGP routing table. The routing table contains the routes learned from the peer PE. This indicates that the BGP neighbor relationship is normal and that VPN labels are assigned properly.

  2. Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose command on PE1 to view detailed information about VPN routes. The Interface field is displayed as NULL0. This indicates that VPN routes do not have a correct iterated outbound interface on the public network. That is, these VPN routes are invalid and therefore are not included in the routing table of the VPN instance.

  3. Run the display mpls ldp session command on PE1 to view the LDP session on the public network. The LDP session works normally. This indicates that an LDP session can be established between the Ps.

  4. Run the display mpls ldp lsp destination-address mask-length command on PE1 to view the assignment of public network labels. The In/OutLabel field is displayed as Null and the Next-Hop field is empty. This indicates that LDP sessions can be established between the PEs and the Ps, but labels cannot be assigned.

  5. Run the display ip routing-table ip-address command on PE1 to view IGP routes to the loopback interface address of the P. The 32-bit loopback interface address is learned from PE2 instead of the P. Therefore, the assignment of public network labels cannot be triggered although the LDP LSP can be established. In addition, no LDP is configured between the two PEs. (If LDP is configured between the two PEs, public network labels can be assigned and routes of the VPN instance can be generated.)

  6. Run the display current configuration and display ip routing-table ip-address commands to view IGP configurations and IGP routes of devices. OSPF is not correctly configured on the interface that connects RR1 to PE1.

Procedure

  1. Re-configure OSPF on the interface that connects RR1 to PE1 to ensure that the path of IGP routes is correct. Then, routing information can be learned from the interfaces that connect the PEs to the Ps.
  2. Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose command on PE1 to view the assignment of MPLS labels and the iteration of the outbound interface of VPN routes. MPLS labels are assigned properly and the outbound interface of VPN routes is iterated properly. The Interface field shows a correct iterated outbound interface on the public network.
  3. Run the display mpls ldp lsp destination-address mask-length command on PE1 to check the assignment of public network labels. Public network labels are assigned properly.
  4. Run the display ip routing-table vpn-instance vpn-instance-name command on PE1 to check the routing table of the VPN instance. The routing table of the VPN instance contains the associated VPN routes. This indicates that the fault is cleared.

Summary

A public network LSP must be established to install VPN routes in the routing table of a VPN instance. If public network labels fail to be assigned and LSPs cannot be established, check whether the path of IGP routes can trigger label assignment and whether IGP routes are correct.

Translation
Download
Updated: 2019-05-10

Document ID: EDOC1000079719

Views: 452290

Downloads: 4311

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next