際際滷

際際滷Share a Scribd company logo

L3 Vpn Diagnosing Common Problems

Download as DOC, PDF
Amir Malik
Amir Malik

The document provides troubleshooting steps for diagnosing common Layer 3 VPN problems by checking connectivity and routes between customer edge (CE) routers and provider edge (PE) routers at each end of the VPN. The steps include checking routing protocol peering, ping connectivity, and presence of routes from the local CE in routing tables on local and remote PEs and remote CE. Issues to examine include routing protocol, BGP, label distribution, and import/export policy configurations.

1 of 5
Download to read offline
L3 VPN 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 The following troubleshooting steps should help you diagnose common problems: 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: o 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. o The Route Distinguisher field lists the route distinguisher separately from the VPN-IPv4 address. o The label-switched-path field shows the name of the label-switched path (LSP) used to carry the VPN traffic. o 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. o The Communities field lists the target community.
o 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: o 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.) o 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. o Check that the IBGP session between the PE routers is established and configured properly. o 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. o 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.

More Related Content

L3 Vpn Diagnosing Common Problems

  • 2. 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 The following troubleshooting steps should help you diagnose common problems: 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.
  • 3. 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: o 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. o The Route Distinguisher field lists the route distinguisher separately from the VPN-IPv4 address. o The label-switched-path field shows the name of the label-switched path (LSP) used to carry the VPN traffic. o 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. o The Communities field lists the target community.
  • 4. o 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: o 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.) o 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. o Check that the IBGP session between the PE routers is established and configured properly. o 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. o 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
  • 5. 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.