Viewing the VPN Routing Tables

Problem

You want to check the routing tables on the PE routers to determine that they contain all the expected routes.

Solution

The show route command displays the contents of all routing tables on the PE router:

	aviva@RouterG> show route
	inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[Static/5] 1w1d 21:04:56
	 > to 172.19.121.1 via fe-0/0/0.0
	10.0.0.0/24 *[Direct/0] 3d 02:34:48
	 > via t1-4/0/0.0
	 [OSPF/10] 00:40:32, metric 65
	 > via t1-4/0/0.0
	10.0.0.1/32 *[Local/0] 3d 02:40:27
	 Local via t1-4/0/0.0
	10.0.1.0/24 *[Direct/0] 00:40:32
	 > via fe-1/0/1.0
	10.0.1.2/32 *[Local/0] 00:40:32
	 Local via fe-1/0/1.0
	10.0.8.0/24 *[OSPF/10] 00:40:32, metric 66
	 > via t1-4/0/0.0
	172.19.121.0/24 *[Direct/0] 1w1d 21:04:56
	 > via fe-0/0/0.0
	172.19.121.119/32 *[Local/0] 5w1d 21:55:41
	 Local via fe-0/0/0.0
	192.168.16.1/32 *[OSPF/10] 00:40:32, metric 66
	 > via t1-4/0/0.0
	192.168.17.1/32 *[OSPF/10] 00:40:32, metric 65
	 > via t1-4/0/0.0
	192.168.19.1/32 *[Direct/0] 3d 02:40:27
	 > via lo0.0
	224.0.0.5/32 *[OSPF/10] 1d 20:46:09, metric 1
	 MultiRecv

	inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both

	192.168.16.1/32 *[RSVP/7] 1d 17:45:11, metric 66
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
	hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.0.1/32 *[Direct/0] 5w1d 21:55:41
	 > via lo0.16385
	10.0.0.16/32 *[Direct/0] 5w1d 21:55:41
	 > via lo0.16385
	VPN2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.16.0/24 *[Direct/0] 01:30:28
	 > via se-5/0/1.0
	10.0.16.2/32 *[Local/0] 01:30:30
	 Local via se-5/0/1.0
	10.0.31.0/24 *[BGP/170] 00:40:32, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	192.168.13.1/32 *[Static/5] 01:30:28
	 > via se-5/0/1.0
	192.168.14.1/32 *[BGP/170] 00:40:32, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0 *[MPLS/0] 1d 18:03:41, metric 1
	 Receive
	1 *[MPLS/0] 1d 18:03:41, metric 1
	 Receive
	2 *[MPLS/0] 1d 18:03:41, metric 1
	 Receive
	100368 *[ 
VPN/170] 01:30:28
	 > via se-5/0/1.0, Pop
	100384 *[VPN/170] 01:30:28
	 > via se-5/0/1.0, Pop

	bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	65500:3:10.0.31.0/24
	 *[BGP/170] 00:43:17, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	65500:3:192.168.14.1/32
	 *[BGP/170] 00:43:17, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE

Discussion

After Layer 3 VPNs are set up, you should check the routing tables on the PE router to make sure that the VPN is operating properly and to see which routes and MPLS labels the router has learned. The show route command in this recipe displays the contents of all the routing tables on the PE router. Lets examine the routing tables individually.

In the VPN configuration, you configured OSPF on the two PE routers and on the P router. The routes learned from OSPF are in the standard inet.0 routing table. To display just these routes on the PE router, use the show route table inet.0 command (see Recipe 8.1).

Because RSVP is running on the routers to support the MPLS LSP, the router creates the inet.3 table to store all MPLS routes learned from RSVP. Recipe 14.7 explains the routes in the inet.3 table.

Two of the routing tables are specific to the VPN. The first is the VRF table, which stores all the IPv4 routes received from the CE routers in the VPN. The JUNOS software names the VRF table using the name of the routing instance. In our recipe, the routing instance is named VPN2, so the routing table is named VPN2.inet.0:

	aviva@RouterG> show route table VPN2.inet.0
	VPN2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.16.0/24 *[Direct/0] 01:06:47
	 > via se-5/0/1.0
	10.0.16.2/32 *[Local/0] 01:06:49
	 Local via se-5/0/1.0
	10.0.31.0/24 *[BGP/170] 00:16:51, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	192.168.13.1/32 *[Static/5] 01:06:47
	 > via se-5/0/1.0
	192.168.14.1/32 *[BGP/170] 00:16:51, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE

The output shows five routes in the VRF table for VPN2. The 10.0.16.0/24 and 10.0.16.2/32 prefixes are the interface addresses between PE RouterG and its directly connected CE RouterA, and the prefix 192.168.13.1 is the loopback address of RouterA. The other two routes are received from the remote CE router, RouterF, at the other end of the LSP and have been learned from BGP as a result of the IBGP peering session between the two PE routers. The prefix 192.168.14.1 is the loopback address of the remote CE router in VPN2, RouterD, and 10.0.31.0/24 is the subnetwork between the remote PE and CE routers. Both these routes are reachable over the LSP:

	> via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE

The VRF table shows that the route to the CE router 192.168.13.1 is a static route, which is what we configured in the recipe.

Its worth checking the VPN2.inet.0 routing table on the other PE router, RouterF, to make sure that it contains similar routing information:

	aviva@RouterF> show route table VPN2.inet.0
	VPN2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.16.0/24 *[BGP/170] 03:32:01, localpref 100, from 192.168.19.1
	 AS path: I
	 > to 10.0.8.1 via fe-0/0/1.0, label-switched-path 
RouterF-PE -to-RouterG-PE
	10.0.31.0/24 *[Direct/0] 02:44:50
	 > via t1-0/0/3.0
	10.0.31.2/32 *[Local/0] 21:37:58
	 Local via t1-0/0/3.0
	192.168.13.1/32 *[BGP/170] 03:32:01, localpref 100, from 192.168.19.1
	 AS path: I
	 > to 10.0.8.1 via fe-0/0/1.0, label-switched-path RouterF-PE
	-to-RouterG-PE
	192.168.14.1/32 *[Static/5] 02:44:50
	 > via t1-0/0/3.0

The two routes 10.0.16.0/24 and 192.168.13.1/32 use the LSP to reach the remote CE router. This is indicated in the third line of each entry, which shows to…via…label-switched-path RouterF-PR-to-RouterG-PE. The remaining three routes are for the local CE router (loopback address 192.168.14.1 and subnetwork 10.0.31.0/24).

The second VPN-specific routing table is bgp.l3vpn.0, which stores the VPN-IPv4 routes received from other PE routers. This table on PE RouterG contains the following routes:

	aviva@RouterG> show route table bgp.l3vpn.0
	bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	65500:3:10.0.31.0/24
	 *[BGP/170] 00:03:40, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE
	65500:3:192.168.14.1/32
	 *[BGP/170] 00:03:40, localpref 100, from 192.168.16.1
	 AS path: I
	 > via t1-4/0/0.0, label-switched-path RouterG-PE-to-RouterF-PE

The VPN-IPv4 routes in this table are for two routes in VPN2, which you configured with a route distinguisher of 65500:3. Looking at just the IPv4 portion of the address, 10.0.31.0/24 is the subnetwork between the remote PE and CE routers, and 192.168.14.1/32 is the loopback address of the remote CE router. To see the VRF target for the VPN-IPv4 routes, use the detail option of the show route command:

	aviva@RouterG> show route 
table bgp.l3vpn.0 detail 10.0.31.0/24
	bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
	65500:3:10.0.31.0/24 (1 entry, 0 announced)
	 *BGP Preference: 170/-101
	 Route Distinguisher: 65500:3
	 Next-hop reference count: 3
	 Source: 192.168.16.1
	 Next hop: via t1-4/0/0.0 weight 1, selected
	 Label-switched-path RouterG-PE-to-RouterF-PE
	 Label operation: Push 100032, Push 100048(top)
	 Protocol next hop: 192.168.16.1
	 Push 100032
	 Indirect next hop: 85d5b00 262142
	 State: <Active Int Ext>
	 Local AS: 65500 Peer AS: 65500
	 Age: 2:30 Metric2: 66
	 Task: BGP_65500.192.168.16.1+179
	 AS path: I
	 Communities: target:65520:100
	 VPN Label: 100032
	 Localpref: 100
	 Router ID: 192.168.16.1
	 Secondary 
Tables: VPN2.inet.0

The second line shows the VPN-IPv4 address, and further down, along with other path attributes, you see the extended community VRF target in the Communities field. The PE routers filter based on the VRF target to determine which VPN the route belongs to and hence the VRF table into which to install the route.

The mpls.0 table also stores information used by the VPN. In this table, you see the distinct label that the VPN assigns to each PE-CE interface:

	aviva@RouterG> show route table mpls protocol vpn
	mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	100048 *[VPN/170] 00:41:21
	 > via se-5/0/1.0, Pop
	100064 *[VPN/170] 00:41:21
	 > via se-5/0/1.0, Pop

This output shows two labels to the CE router, not one. This is because of a detail in how VPN assigns labels. It actually assigns one for each next hop. The configuration is this recipe has two next hops to the CE router, one through the direct interface connection and one as a result of the static route configuration. You can see these two routes in the VPN2.inet.0 table:

	aviva@RouterG> show route table VPN2.inet.0
	VPN2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.16.0/24 *[Direct/0] 01:06:47
	 > via se-5/0/1.0
	192.168.13.1/32 *[Static/5] 01:06:47
	 > via se-5/0/1.0

See Also

Recipes 8.1 and 14.7