Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Diagnosing Common Problems

Problem

To troubleshoot problems in the Layer 3 VPN configuration, start at one end of the VPN (the local customer edge [CE] router) and follow the routes to the other end of the VPN (the remote CE router).

Solution

1. If you configured a routing protocol between the local provider edge (PE) and CE routers, check that the peering and adjacency are fully operational. When you do this, be sure to specify the name of the routing instance. For example, to check OSPF adjacencies, enter the show ospf neighbor instance routing-instance-name command on the PE router.

   If the peering and adjacency are not fully operational, check the routing protocol configuration on the CE router and check the routing protocol configuration for the associated VPN routing instance on the PE router.

2. Check that the local CE and PE routers can ping each other.

   To check that the local CE router can ping the VPN interface on the local PE router, use a ping command in the following format, specifying the IP address or name of the PE router:

   user@host> ping (ip-address | host-name)

   To check that the local PE router can ping the CE router, use a ping command in the following format, specifying the IP address or name of the CE router, the name of the interface used for the VPN, and the source IP address (the local address) in outgoing echo request packets:

   user@host> ping ip-address interface interface local echo-address

   Often, the peering or adjacency between the local CE and local PE routers must come up before a ping command is successful. To check that a link is operational in a lab setting, remove the interface from the VPN routing and forwarding (VRF) by deleting the interface statement from the [edit routing-instance routing-instance-name] hierarchy level and recommitting the configuration. Doing this removes the interface from the VPN. Then try the ping command again. If the command is successful, configure the interface back into the VPN and check the routing protocol configuration on the local CE and PE routers again.

3. On the local PE router, check that the routes from the local CE router are in the VRF table (routing-instance-name.inet.0):
   user@host> show route table routing-instance-name.inet.0 <detail>

   The following example shows the routing table entries. Here, the loopback address of the CE router is 10.255.14.155/32 and the routing protocol between the PE and CE routers is BGP. The entry looks like any ordinary BGP announcement.

   10.255.14.155/32 (1 entry, 1 announced)
           *BGP    Preference: 170/-101
                   Nexthop: 192.168.197.141 via fe-1/0/0.0, selected
                   State: <Active Ext>
                   Peer AS:     1
                   Age: 45:46
                   Task: BGP_1.192.168.197.141+179
                   Announcement bits (2): 0-BGP.0.0.0.0+179 1-KRT
                   AS path: 1 I
                   Localpref: 100
                   Router ID: 10.255.14.155
   

   If the routes from the local CE router are not present in the VRF routing table, check that the CE router is advertising routes to the PE router. If static routing is used between the CE and PE routers, make sure the proper static routes are configured.

4. On a remote PE router, check that the routes from the local CE router are present in the bgp.l3vpn.0 routing table:
   user@host> show route table bgp.l3vpn.0 extensive

   10.255.14.175:3:10.255.14.155/32 (1 entry, 0 announced)
           *BGP    Preference: 170/-101
                   Route Distinguisher: 10.255.14.175:3
                   Source: 10.255.14.175
                   Nexthop: 192.168.192.1 via fe-1/1/2.0, selected
                   label-switched-path vpn07-vpn05
                   Push 100004, Push 100005(top)
                   State: <Active Int Ext>
                   Local AS:    69 Peer AS:    69
                   Age: 15:27      Metric2: 338
                   Task: BGP_69.10.255.14.175+179
                   AS path: 1 I
                   Communities: target:69:100
                   BGP next hop: 10.255.14.175
                   Localpref: 100
                   Router ID: 10.255.14.175
                   Secondary tables: VPN-A.inet.0

   The output of the show route table bgp.l3vpn.0 extensive command contains the following information specific to the VPN:

   • In the prefix name (the first line of the output), the route distinguisher is added to the route prefix of the local CE router. Because the route distinguisher is unique within the Internet, the concatenation of the route distinguisher and IP prefix provides unique VPN-IP version 4 (IPv4) routing entries.
   • The Route Distinguisher field lists the route distinguisher separately from the VPN-IPv4 address.
   • The label-switched-path field shows the name of the label-switched path (LSP) used to carry the VPN traffic.
   • The Push field shows both labels being carried in the VPN-IPv4 packet. The first label is the inner label, which is the VPN label that was assigned by the PE router. The second label is the outer label, which is an RSVP label.
   • The Communities field lists the target community.
   • The Secondary tables field lists other routing tables on this router into which this route has been installed.

   If routes from the local CE router are not present in the bgp.l3vpn.0 routing table on the remote PE router, do the following:

   • Check the VRF import filter on the remote PE router, which is configured in the vrf-import statement. (On the local PE router, you check the VRF export filter, which is configured with the vrf-export statement.)
   • Check that there is an operational LSP or an LDP path between the PE routers. To do this, check that the IBGP next-hop addresses are in the inet.3 table.
   • Check that the IBGP session between the PE routers is established and configured properly.
   • Check for “hidden” routes, which usually means that routes were not labeled properly. To do this, use the show route table bgp.l3vpn.0 hidden command.
   • Check that the inner label matches the inner VPN label that is assigned by the local PE router. To do this, use the show route table mpls command.

   The following example shows the output of this command on the remote PE router. Here, the inner label is 100004.

   ...
   Push 100004, Push 10005 (top)

   The following example shows the output of this command on the local PE router, which shows that the inner label of 100004 matches the inner label on the remote PE router:

   ...
   100004             *[VPN/7] 06:56:25, metric 1 
    > to 192.168.197.141 via fe-1/0/0.0, Pop

5. On the remote PE router, check that the routes from the local CE router are present in the VRF table (routing-instance-name.inet.0):
   user@host> show route table routing-instance-name.inet.0 detail

   10.255.14.155/32 (1 entry, 1 announced)
           *BGP    Preference: 170/-101
                   Route Distinguisher: 10.255.14.175:3
                   Source: 10.255.14.175
                   Nexthop: 192.168.192.1 via fe-1/1/2.0, selected
                   label-switched-path vpn07-vpn05
                   Push 100004, Push 100005(top)
                   State: <Secondary Active Int Ext>
                   Local AS:    69 Peer AS:    69
                   Age: 1:16:22    Metric2: 338
                   Task: BGP_69.10.255.14.175+179
                   Announcement bits (2): 1-KRT 2-VPN-A-RIP
                   AS path: 1 I
                   Communities: target:69:100
                   BGP next hop: 10.255.14.175
                   Localpref: 100
                   Router ID: 10.255.14.175
                   Primary Routing Table bgp.l3vpn.0

   In this routing table, the route distinguisher is no longer prepended to the prefix. The last line, Primary Routing Table, lists the table from which this route was learned.

   If the routes are not present in this routing table, but were present in the bgp.l3vpn.0 routing table on the local CE router, the routes might have not passed the VRF import policy on the remote PE router.

   If a VPN-IPv4 route matches no vrf-import policy, the route does not show up in the bgp.l3vpn table at all and hence is not present in the VRF table. If this occurs, it might indicate that on the PE router, you have configured another vrf-import statement on another VPN (with a common target), and the routes show up in the bgp.l3vpn.0 table, but are imported into the wrong VPN.

6. On the remote CE router, check that the routes from the local CE router are present in the routing table (inet.0):
   user@host> show route

   If the routes are not present, check the routing protocol configuration between the remote PE and CE routers, and make sure that peers and adjacencies (or static routes) between the PE and CE routers are correct.

7. If you determine that routes originated from the local CE router are correct, check the routes originated from the remote CE router by repeating this procedure.