Rob Riker/ Simplified Networking: CCIE SPv4 - MPLS L3 VPN - PE-CE Routing with BGP for IPv6 or 6VPE

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we'll be taking a look at IPv6 BGP in a VRF or 6VPE. The same can be done for 6PE where IPv6 BGP is not in a VRF, but in the global RIB. I'll do a separate post on that, slight configuration change as VPNv6 isn't supported/available yet. The idea here on both IOS and XR is that you can run IPv4 and IPv6 in a dual stack in the core as ships in the night, the two AFIs don't see any of the other's traffic. I won't do a packet walk like I did in the previous post. I do plan on showing some traces to show that each AFI is working end to end.

Since IPv4 and IPv6 will both be tested on the SPv4 exam, being comfortable with both is super important. That being said, getting IPv6 to work is as simple as adding the relevant IPv6 configuration; enabling the IPv6 AFI under the VRFs, creating RT import and export policies, enabling MP-BGP to peer to the other provider routers with IPv6. In the Core configuration post, I added in the configuration to enable the PE to P router configuration to peer via IPv6. I will only show the relevant BGP configuration to get this demo operational.

The idea here is to get R13, R14, R8, R9 and R10 to exchange IPv6 routes with the provider via BGP. Since we are dealing with BGP, redistribution between the PE BGP and VRF process isn't required, yet anyways, it will be in the IGP demos. Truth be told, I had significant issues getting this lab working for IOS XR, I mention my issues as a form of humor now, gives the reader a chuckle, (maybe) and acts as a reminder for me 😉.

I will be showing the configuration of R1 and R13 as well as XR3 and R14, the PE and CE configuration, so that as you are going through the lab, you'll be able to get the PE-CE peering working, once the 2-5 peerings are operational, you should start to see that routes are propagating.

interface GigabitEthernet1.1020

encapsulation dot1Q 120

vrf forwarding BGP

ip address 131.0.0.1 255.255.255.0

ipv6 address 2131:CC1E::1/64

vrf definition BGP

rd 20:50693

address-family ipv4

route-target export 20:50693

route-target import 20:50693

exit-address-family

address-family ipv6

route-target export 20:50693

route-target import 20:50693

exit-address-family

router bgp 50693

address-family ipv4 vrf BGP

neighbor 131.0.0.13 remote-as 134

neighbor 131.0.0.13 activate

exit-address-family

address-family ipv6 vrf BGP

neighbor 2131:CC1E::13 remote-as 134

neighbor 2131:CC1E::13 activate

exit-address-family

R13

interface GigabitEthernet1.1020

encapsulation dot1Q 120

vrf forwarding BGP

ip address 131.0.0.13 255.255.255.0

ipv6 address 2131:CC1E::13/64

vrf definition BGP

rd 20:50693

address-family ipv4

route-target export 20:50693

route-target import 20:50693

exit-address-family

address-family ipv6

route-target export 20:50693

route-target import 20:50693

exit-address-family

router bgp 134

bgp log-neighbor-changes

no bgp default ipv4-unicast

address-family ipv4

exit-address-family

address-family ipv4 vrf BGP

network 131.0.0.0 mask 255.255.255.0

redistribute connected

neighbor 131.0.0.1 remote-as 50693

neighbor 131.0.0.1 activate

exit-address-family

address-family ipv6 vrf BGP

redistribute connected

network 2131:CC1E::/64

neighbor 2131:CC1E::1 remote-as 50693

neighbor 2131:CC1E::1 activate

exit-address-family

XR3

interface GigabitEthernet0/0/0/0.1020

vrf BGP

ipv4 address 113.0.0.13 255.255.255.0

ipv6 address 2113:cc1e::13/64

encapsulation dot1q 1320

vrf BGP

address-family ipv4 unicast

import route-target

20:50693

export route-target

20:50693

address-family ipv6 unicast

import route-target

20:50693

export route-target

20:50693

router bgp 50693

vrf BGP

rd 20:50693

address-family ipv4 unicast

address-family ipv6 unicast

neighbor 113.0.0.14

remote-as 143

address-family ipv4 unicast

route-policy PASS in

route-policy PASS out

neighbor 2113:cc1e::14

remote-as 143

address-family ipv6 unicast

route-policy PASS in

route-policy PASS out

R14

interface GigabitEthernet1.1020

encapsulation dot1Q 1320

vrf forwarding BGP

ip address 113.0.0.14 255.255.255.0

ipv6 address 2113:CC1E::14/64

vrf definition BGP

rd 20:50693

address-family ipv4

route-target export 20:50693

route-target import 20:50693

exit-address-family

address-family ipv6

route-target export 20:50693

route-target import 20:50693

exit-address-family

router bgp 143

bgp log-neighbor-changes

no bgp default ipv4-unicast

address-family ipv4 vrf BGP

network 113.0.0.0 mask 255.255.255.0

neighbor 113.0.0.13 remote-as 50693

neighbor 113.0.0.13 activate

exit-address-family

address-family ipv6 vrf BGP

network 2113:CC1E::/64

neighbor 2113:CC1E::13 remote-as 50693

neighbor 2113:CC1E::13 activate

exit-address-family

Now that we have all the configuration in place, you can just swap out the IPv4/IPv6 prefixes used in the BGP configuration as you hit each PE-CE connection. We have to look at the verification.

R1#sh bgp vpnv6 unicast vrf BGP summary | b Neighbor

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

2131:CC1E::13 4 134 1668 1637 252 0 0 1d00h 2

This ouput shows us that from the PE side, we are peered with R13 and learning 2 prefixes from R13.

R1#sh bgp vpnv6 unicast vrf BGP neighbors 2131:CC1E::13 routes | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

r> 2131:CC1E::/64 2131:CC1E::13 0 0 134 i

*> FC00::13/128 2131:CC1E::13 0 0 134 ?

Total number of prefixes 2

We've learned the "r>" which is the directly connected IPv6 prefix and the "*>" which is the loopback interface in the VRF BGP RIB that was advertised, you'll notice that the *> route has a ? at the end of it, indicating that it was redistributed. The ? means that BGP doesn't know where the route was originated from.

R1#sh bgp vpnv6 unicast vrf BGP

BGP table version is 252, local router ID is 192.168.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*>i 2038:CC1E::/64 ::FFFF:192.168.1.3

0 100 0 8 i

* i ::FFFF:192.168.1.3

0 100 0 8 i

*>i 2059:CC1E::/64 ::FFFF:192.168.1.5

0 100 0 9 i

* i ::FFFF:192.168.1.5

0 100 0 9 i

*>i 2106:CC1E::/64 ::FFFF:192.168.1.6

0 100 0 10 i

* i ::FFFF:192.168.1.6

0 100 0 10 i

* i 2113:CC1E::/64 ::FFFF:192.168.1.13

Network Next Hop Metric LocPrf Weight Path

0 100 0 143 i

*>i ::FFFF:192.168.1.13

0 100 0 143 i

r> 2131:CC1E::/64 2131:CC1E::13 0 0 134 i

* i FC00::10/128 ::FFFF:192.168.1.6

0 100 0 10 ?

*>i ::FFFF:192.168.1.6

0 100 0 10 ?

*> FC00::13/128 2131:CC1E::13 0 0 134 ?

This is the complete output from the VRF BGP table. You can see there are several routes in the RIB, all of them have the "FFFF" in front of the IPv4 remote PE loopback address used for the update-source. This is indicative of 6VPE as we are tunneling IPv6 over IPv4 currently, IPv6 is not currently running in the core. We'll take a look at enabling IPv6 in the core and showing the difference in another post.

R1#sh bgp vpnv6 unicast vrf BGP 2038:CC1E::/64

BGP routing table entry for [20:50693]2038:CC1E::/64, version 122

Paths: (2 available, best #1, table BGP)

Advertised to update-groups:

Refresh Epoch 1

::FFFF:192.168.1.3 (metric 4) (via default) from 192.168.1.2 (192.168.1.2)

Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.2

mpls labels in/out nolabel/43

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

::FFFF:192.168.1.3 (metric 4) (via default) from 192.168.1.14 (192.168.1.14)

Origin IGP, metric 0, localpref 100, valid, internal

Extended Community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.14

mpls labels in/out nolabel/43

rx pathid: 0, tx pathid: 0

This output expands on the route learned from R3 that is the PE-CE prefix between R3 and R8. There are 2 different paths learned, one from R2 and the other from XR4, R2 is best because R2 has a lower RID, BGP needs something to use for the tie breaker, since all the attributes are the same.

R1#sh ipv6 route vrf BGP

IPv6 Routing Table - BGP - 9 entries

Codes: C - Connected, L - Local, S - Static, U - Per-user Static route

B - BGP, R - RIP, H - NHRP, I1 - ISIS L1

I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP

EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination

NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter

OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1

ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations

ld - LISP dyn-eid, a - Application

B 2038:CC1E::/64 [200/0]

via 192.168.1.3%default, indirectly connected

B 2059:CC1E::/64 [200/0]

via 192.168.1.5%default, indirectly connected

B 2106:CC1E::/64 [200/0]

via 192.168.1.6%default, indirectly connected

B 2113:CC1E::/64 [200/0]

via 192.168.1.13%default, indirectly connected

C 2131:CC1E::/64 [0/0]

via GigabitEthernet1.1020, directly connected

L 2131:CC1E::1/128 [0/0]

via GigabitEthernet1.1020, receive

B FC00::10/128 [200/0]

via 192.168.1.6%default, indirectly connected

B FC00::13/128 [20/0]

via FE80::20C:29FF:FE44:53CF, GigabitEthernet1.1020

L FF00::/8 [0/0]

via Null0, receive

This output is of the VRF BGP IPv6 RIB, not the BGP IPV6 table, these are routes that were passed from the BGP table into the VRF BGP RIB that can be advertised down to R13.

R13
R13#sh bgp vpnv4 unicast vrf BGP | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 20:50693 (default for vrf BGP)
*> 0.0.0.0 131.0.0.1 0 50693 i
*> 10.10.10.0/24 131.0.0.1 0 50693 10 ?
*> 13.13.13.0/24 0.0.0.0 0 32768 ?
*> 59.0.0.0/24 131.0.0.1 0 50693 9 i
*> 83.0.0.0/24 131.0.0.1 0 50693 8 i
*> 106.0.0.0/24 131.0.0.1 0 50693 10 i
*> 113.0.0.0/24 131.0.0.1 0 50693 143 i
*> 131.0.0.0/24 0.0.0.0 0 32768 i

R13#sh bgp vpnv6 unicast vrf BGP | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 20:50693 (default for vrf BGP)
*> 2038:CC1E::/64 2131:CC1E::1 0 50693 8 i
*> 2059:CC1E::/64 2131:CC1E::1 0 50693 9 i
*> 2106:CC1E::/64 2131:CC1E::1 0 50693 10 i
*> 2113:CC1E::/64 2131:CC1E::1 0 50693 143 i
*> 2131:CC1E::/64 :: 0 32768 i
*> FC00::10/128 2131:CC1E::1 0 50693 10 ?
*> FC00::13/128 :: 0 32768 ?

This proves that R1 has passed the routes onto R13 and now R13 has ran the best path selection process on these routes, R13 now can inject the best routes (all of them) into the appropriate VRF based IPv4 and IPv6 RIBs.

R13#sh ip route vrf BGP bgp | b Gateway
Gateway of last resort is 131.0.0.1 to network 0.0.0.0

B* 0.0.0.0/0 [20/0] via 131.0.0.1, 20:51:46
10.0.0.0/24 is subnetted, 1 subnets
B 10.10.10.0 [20/0] via 131.0.0.1, 1d01h
59.0.0.0/24 is subnetted, 1 subnets
B 59.0.0.0 [20/0] via 131.0.0.1, 1d04h
83.0.0.0/24 is subnetted, 1 subnets
B 83.0.0.0 [20/0] via 131.0.0.1, 1d04h
106.0.0.0/24 is subnetted, 1 subnets
B 106.0.0.0 [20/0] via 131.0.0.1, 1d07h
113.0.0.0/24 is subnetted, 1 subnets
B 113.0.0.0 [20/0] via 131.0.0.1, 1d04h

R13#sh ipv6 route vrf BGP bgp
IPv6 Routing Table - BGP - 9 entries
B 2038:CC1E::/64 [20/0]
via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1020
B 2059:CC1E::/64 [20/0]
via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1020
B 2106:CC1E::/64 [20/0]
via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1020
B 2113:CC1E::/64 [20/0]
via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1020
B FC00::10/128 [20/0]
via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1020

Going based on the routes seen in the VRF aware RIBs, R13 can reach routes in either IPv4 or IPv6. I will ping/trace test that this is working from R13 to R10.

R13#ping vrf BGP 106.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 106.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/19 ms
R13#ping vrf BGP 2106:CC1E::10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2106:CC1E::10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/19/72 ms

R13#traceroute vrf BGP 106.0.0.10 num

Type escape sequence to abort.

Tracing the route to 106.0.0.10

VRF info: (vrf in name/id, vrf out name/id)

1 131.0.0.1 4 msec 1 msec 1 msec

2 10.1.15.15 [MPLS: Labels 24004/26 Exp 0] 7 msec 5 msec 5 msec

3 10.15.4.4 [MPLS: Labels 18/26 Exp 0] 6 msec 19 msec 19 msec

4 10.4.5.5 [MPLS: Labels 18/26 Exp 0] 19 msec 19 msec 27 msec

5 106.0.0.6 22 msec 10 msec 9 msec

6 106.0.0.10 9 msec

R13#traceroute vrf BGP 2106:CC1E::10

Type escape sequence to abort.

Tracing the route to 2106:CC1E::10

1 2131:CC1E::1 3 msec 1 msec 1 msec

2 FC00::112 [MPLS: Labels 24007/27 Exp 0] 20 msec 6 msec 7 msec

3 2016:12:13::13 [MPLS: Labels 24002/27 Exp 0] 9 msec 20 msec 28 msec

4 ::FFFF:10.13.2.2 [MPLS: Labels 16/27 Exp 0] 25 msec 81 msec 17 msec

5 2106:CC1E::6 [AS 10] 17 msec 9 msec 10 msec

6 2106:CC1E::10 [AS 10] 15 msec 15 msec 15 msec

As you can see, the ping trace test works as expected. One thing to point out, the 4th hop, "::FFFF:10.13.2.2" is an indication that R2 on that peering with XR3 does not have an IPv6 address configured on that interface. Due to this, IOS has to map the IPv6 traffic to an IPv4 address and use the FFFF as filler. At the time of this post, IPv6 for iGP hasn't been enabled.

interface GigabitEthernet1.132

encapsulation dot1Q 132

ip address 10.13.2.2 255.255.255.0

The configuration shown in this post is that of "the defacto" standard, meaning it is the most likely to be used in a production network. Other posts will include the Customer peering with the same AS at 2 or more sites and backdoor link with SoO. The provider really has to be ready for anything, which is why most providers will prefer a "managed CE" to prevent issues from occuring.

Let's take a look at the XR equivalent and go from there.

We've verified R1, being a PE, we'll do the same with XR3 and show that R14 is learning routes.

RP/0/0/CPU0:XR3#sh bgp vpnv4 unicast vrf BGP | b Network

Sun Jan 8 22:26:34.759 UTC

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*>i10.10.10.0/24 192.168.1.6 0 100 0 10 ?

* i 192.168.1.6 0 100 0 10 ?

*>i13.13.13.0/24 192.168.1.1 0 100 0 134 ?

* i 192.168.1.1 0 100 0 134 ?

*>i59.0.0.0/24 192.168.1.5 0 100 0 9 i

* i 192.168.1.5 0 100 0 9 i

*>i83.0.0.0/24 192.168.1.3 0 100 0 8 i

* i 192.168.1.3 0 100 0 8 i

*>i106.0.0.0/24 192.168.1.6 0 100 0 10 i

* i 192.168.1.6 0 100 0 10 i

*> 113.0.0.0/24 113.0.0.14 0 0 143 i

*>i131.0.0.0/24 192.168.1.1 0 100 0 134 i

* i 192.168.1.1 0 100 0 134 i

RP/0/0/CPU0:XR3#sh bgp vpnv6 unicast vrf BGP | b Network

Sun Jan 8 22:26:51.548 UTC

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*>i2038:cc1e::/64 192.168.1.3 0 100 0 8 i

* i 192.168.1.3 0 100 0 8 i

*>i2059:cc1e::/64 192.168.1.5 0 100 0 9 i

* i 192.168.1.5 0 100 0 9 i

*>i2106:cc1e::/64 192.168.1.6 0 100 0 10 i

* i 192.168.1.6 0 100 0 10 i

*> 2113:cc1e::/64 2113:cc1e::14 0 0 143 i

*>i2131:cc1e::/64 192.168.1.1 0 100 0 134 i

* i 192.168.1.1 0 100 0 134 i

*>ifc00::10/128 192.168.1.6 0 100 0 10 ?

* i 192.168.1.6 0 100 0 10 ?

*>ifc00::13/128 192.168.1.1 0 100 0 134 ?

* i 192.168.1.1 0 100 0 134 ?

We have 2 paths for each route except for directly connected peerings.

RP/0/0/CPU0:XR3#sh bgp vpnv4 unicast vrf BGP 13.13.13.0/24

Sun Jan 8 22:28:00.853 UTC

BGP routing table entry for 13.13.13.0/24, Route Distinguisher: 20:50693

Versions:

Process bRIB/RIB SendTblVer

Speaker 136 136

Last Modified: Jan 8 01:04:56.192 for 21:23:04

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

134

192.168.1.1 (metric 3) from 192.168.1.2 (192.168.1.1)

Received Label 33

Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 136

Extended community: RT:20:50693

Originator: 192.168.1.1, Cluster list: 192.168.1.2

Source VRF: BGP, Source Route Distinguisher: 20:50693

Path #2: Received by speaker 0

Not advertised to any peer

134

192.168.1.1 (metric 3) from 192.168.1.14 (192.168.1.1)

Received Label 33

Origin incomplete, metric 0, localpref 100, valid, internal, import-candidate, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:20:50693

Originator: 192.168.1.1, Cluster list: 192.168.1.14

Source VRF: BGP, Source Route Distinguisher: 20:50693

Like we saw with R1, we have 2 paths, since R2 is the lowest Router ID, it wins the election and is the best path. The same will be true for any of the IPv6 routes.

RP/0/0/CPU0:XR3#sh bgp vpnv6 unicast vrf BGP 2038:cc1e::/64

Sun Jan 8 22:30:13.684 UTC

BGP routing table entry for 2038:cc1e::/64, Route Distinguisher: 20:50693

Versions:

Process bRIB/RIB SendTblVer

Speaker 77 77

Last Modified: Jan 7 20:14:00.192 for 1d02h

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

192.168.1.3 (metric 6) from 192.168.1.2 (192.168.1.3)

Received Label 43

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 77

Extended community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.2

Source VRF: BGP, Source Route Distinguisher: 20:50693

Path #2: Received by speaker 0

Not advertised to any peer

192.168.1.3 (metric 6) from 192.168.1.14 (192.168.1.3)

Received Label 43

Origin IGP, metric 0, localpref 100, valid, internal, import-candidate, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.14

Source VRF: BGP, Source Route Distinguisher: 20:50693

R2 is chosen as the best path. Now that doesn't mean that R2 will be in the transit path, because it is not, R2 just happens to be a route reflector and is the router that advertised or reflected XR3 the route. Let's take a look at the VRF aware RIB for BGP, if it is populated, that will prove that the translation between VPNv4/IPv4 and VPNv6/IPv6 was successful and R14 should learning routes.

RP/0/0/CPU0:XR3#sh route vrf BGP ipv4 | b Gateway

Sun Jan 8 22:32:18.676 UTC

Gateway of last resort is not set

B 10.10.10.0/24 [200/0] via 192.168.1.6 (nexthop in vrf default), 1d01h

B 13.13.13.0/24 [200/0] via 192.168.1.1 (nexthop in vrf default), 21:27:22

B 59.0.0.0/24 [200/0] via 192.168.1.5 (nexthop in vrf default), 1d04h

B 83.0.0.0/24 [200/0] via 192.168.1.3 (nexthop in vrf default), 1d04h

B 106.0.0.0/24 [200/0] via 192.168.1.6 (nexthop in vrf default), 1d07h

C 113.0.0.0/24 is directly connected, 1d07h, GigabitEthernet0/0/0/0.1020

L 113.0.0.13/32 is directly connected, 1d07h, GigabitEthernet0/0/0/0.1020

B 131.0.0.0/24 [200/0] via 192.168.1.1 (nexthop in vrf default), 21:27:21

RP/0/0/CPU0:XR3#sh route vrf BGP ipv6 | b Gateway

Sun Jan 8 22:33:36.810 UTC

Gateway of last resort is not set

B 2038:cc1e::/64

[200/0] via ::ffff:192.168.1.3 (nexthop in vrf default), 1d02h

B 2059:cc1e::/64

[200/0] via ::ffff:192.168.1.5 (nexthop in vrf default), 1d02h

B 2106:cc1e::/64

[200/0] via ::ffff:192.168.1.6 (nexthop in vrf default), 1d02h

C 2113:cc1e::/64 is directly connected,

1d07h, GigabitEthernet0/0/0/0.1020

L 2113:cc1e::13/128 is directly connected,

1d07h, GigabitEthernet0/0/0/0.1020

B 2131:cc1e::/64

[200/0] via ::ffff:192.168.1.1 (nexthop in vrf default), 21:28:03

B fc00::10/128

[200/0] via ::ffff:192.168.1.6 (nexthop in vrf default), 1d01h

B fc00::13/128

[200/0] via ::ffff:192.168.1.1 (nexthop in vrf default), 21:28:03

We need to make sure that XR3 is actually peered with R14, since we are directly connected to R14 and no IGP routes are seen in the VRF or in the BGP tables, we won't know until we check.

RP/0/0/CPU0:XR3#sh bgp vrf BGP summary | b Neighbor

Sun Jan 8 22:34:13.018 UTC

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

113.0.0.14 0 143 1900 1731 146 0 0 1d04h 1

Excellent, we're peered and learning 1 prefix. Let's check on R14 to see what he's learning.

R14#sh bgp vpnv4 unicast vrf BGP | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*> 10.10.10.0/24 113.0.0.13 0 50693 10 ?

*> 13.13.13.0/24 113.0.0.13 0 50693 134 ?

*> 59.0.0.0/24 113.0.0.13 0 50693 9 i

*> 83.0.0.0/24 113.0.0.13 0 50693 8 i

*> 106.0.0.0/24 113.0.0.13 0 50693 10 i

*> 113.0.0.0/24 0.0.0.0 0 32768 i

*> 131.0.0.0/24 113.0.0.13 0 50693 134 i

R14#sh bgp vpnv6 unicast vrf BGP | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*> 2038:CC1E::/64 2113:CC1E::13 0 50693 8 i

*> 2059:CC1E::/64 2113:CC1E::13 0 50693 9 i

*> 2106:CC1E::/64 2113:CC1E::13 0 50693 10 i

*> 2113:CC1E::/64 :: 0 32768 i

*> 2131:CC1E::/64 2113:CC1E::13 0 50693 134 i

*> FC00::10/128 2113:CC1E::13 0 50693 10 ?

*> FC00::13/128 2113:CC1E::13 0 50693 134 ?

R14 has learned routes from XR3 and installed them in the BGP VRF aware RIB. Let's check to see if any routes are in the VRF aware RIB.

R14#sh ip route vrf BGP bgp | b Gateway

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 1 subnets

B 10.10.10.0 [20/0] via 113.0.0.13, 1d01h

13.0.0.0/24 is subnetted, 1 subnets

B 13.13.13.0 [20/0] via 113.0.0.13, 1d01h

59.0.0.0/24 is subnetted, 1 subnets

B 59.0.0.0 [20/0] via 113.0.0.13, 1d04h

83.0.0.0/24 is subnetted, 1 subnets

B 83.0.0.0 [20/0] via 113.0.0.13, 1d04h

106.0.0.0/24 is subnetted, 1 subnets

B 106.0.0.0 [20/0] via 113.0.0.13, 1d04h

131.0.0.0/24 is subnetted, 1 subnets

B 131.0.0.0 [20/0] via 113.0.0.13, 1d04h

R14#sh ipv6 route vrf BGP bgp | b App

ld - LISP dyn-eid, a - Application

B 2038:CC1E::/64 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

B 2059:CC1E::/64 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

B 2106:CC1E::/64 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

B 2131:CC1E::/64 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

B FC00::10/128 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

B FC00::13/128 [20/0]

via FE80::20C:29FF:FE29:9C4A, GigabitEthernet1.1020

So we can see that routes are in the RIB, which means we can test reachability. Let's ping the loopback of R13 to prove that.

R14#ping vrf BGP FC00::13

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FC00::13, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 7/20/70 ms

R14#ping vrf BGP 13.13.13.13

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 13.13.13.13, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 5/24/103 ms

Excellent, it works! This proves that the configuration has been successful,

Thanks for stopping by!

Rob Riker, CCIE #50693

Rob Riker/ Simplified Networking

Sunday, January 8, 2017

CCIE SPv4 - MPLS L3 VPN - PE-CE Routing with BGP for IPv6 or 6VPE

3 comments:

Blog Archive