[Contents] [Prev] [Next] [Index] [Report an Error]

Diagnosing Common Problems

When problems arise in a Layer 3 VPN configuration, the best way to troubleshoot is to 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). The following troubleshooting steps should help you diagnose common problems:

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 Open Shortest Path First (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.
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.
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.
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 a Resource Reservation Protocol (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 a Label Distribution Protocol (LDP) path between the PE routers. To do this, check that the internal BGP (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
```
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 Step 4, 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.
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.
If, in Step 1 through Step 6, you have determined that routes originated from the local CE router are correct, check the routes originated from the remote CE router by repeating Step 1 through Step 6.

[Contents] [Prev] [Next] [Index] [Report an Error]