Viewing the VPN Routing Tables

2017-11-03 09:05:07

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:

Viewing the VPN Routing Tables

Problem

Solution

Discussion

See Also

Категории