Rob Riker/ Simplified Networking: VPNv6

Showing posts with label VPNv6. Show all posts

Sunday, January 15, 2017

CCIE SPv4 - MPLS L3 VPN - Label Modes

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will take a look at the different label allocation modes that are available. Normally when a CE advertises a route to a PE, that PE allocates a unique label per learned prefix. This is the default mechanism used. We'll take a look at R1 and XR3s label allocation techniques.

R1#sh bgp vpnv4 unicast vrf BGP labels | in 131.0.0.13

13.13.13.0/24 131.0.0.13 28/nolabel

131.0.0.0/24 131.0.0.13 35/nolabel

192.168.10.0 131.0.0.13 44/nolabel

192.168.11.0 131.0.0.13 45/nolabel

192.168.12.0 131.0.0.13 47/nolabel

131.0.0.13 nolabel/nolabel

R1#sh bgp vpnv6 unicast vrf BGP labels | in 2131:CC1E::13

2131:CC1E::/64 2131:CC1E::13 50/nolabel

FC00::13/128 2131:CC1E::13 51/nolabel

FC00:213::13/128 2131:CC1E::13 nolabel/nolabel

FC00:1013::/64 2131:CC1E::13 29/nolabel

FC00:1113::/64 2131:CC1E::13 40/nolabel

FC00:1213::/64 2131:CC1E::13 30/nolabel

RP/0/0/CPU0:XR3#sh bgp vpnv4 unicast vrf BGP labels | in 113.0.0.14

Sun Jan 15 21:14:22.264 UTC

*> 113.0.0.0/24 113.0.0.14 nolabel 24016

*> 172.16.10.0/24 113.0.0.14 nolabel 24023

*> 172.16.11.0/24 113.0.0.14 nolabel 24024

*> 172.16.12.0/24 113.0.0.14 nolabel 24025

RP/0/0/CPU0:XR3#sh bgp vpnv6 unicast vrf BGP labels | in 2113:cc1e::14

Sun Jan 15 21:17:17.882 UTC

*> 2113:cc1e::/64 2113:cc1e::14 nolabel 24015

*> fc00:10::/64 2113:cc1e::14 nolabel 24026

*> fc00:11::/64 2113:cc1e::14 nolabel 24027

*> 2113:cc1e::14 nolabel 24028

As you can see, each prefix gets its own label. For the average design, this works but if you have to scale that, you will run into scalability issues down the road. Let's take a look at optimizing this capability.

On the IOS PEs

mpls label mode vrf BGP protocol bgp-vpnv4 per-vrf

On the XR PEs

vrf BGP

address-family ipv4 unicast

label mode per-vrf

R1(config)#do sh bgp vpnv4 unicast vrf BGP labels | in 131.0.0.13

13.13.13.0/24 131.0.0.13 IPv4 VRF Aggr:57/nolabel

131.0.0.0/24 131.0.0.13 IPv4 VRF Aggr:57/nolabel

192.168.10.0 131.0.0.13 IPv4 VRF Aggr:57/nolabel

192.168.11.0 131.0.0.13 IPv4 VRF Aggr:57/nolabel

192.168.12.0 131.0.0.13 IPv4 VRF Aggr:57/nolabel

131.0.0.13 nolabel/nolabel

As you can see, each prefix now gets 1 aggregate label, Ok, cool, but now from a routing perspective, this doesn't really help us, we now have to do recursion.

R1#sh mpls forwarding-table labels 57 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

57 Pop Label IPv4 VRF[V] 0 aggregate/BGP

MAC/Encaps=0/0, MRU=0, Label Stack{}

VPN route: BGP

No output feature configured

R1#sh ip cef vrf BGP 192.168.10.0

192.168.10.0/24

nexthop 131.0.0.13 GigabitEthernet1.1020

RP/0/0/CPU0:XR3#sh bgp vpnv4 unicast vrf BGP labels | in 113.0.0.14

Sun Jan 15 21:28:53.575 UTC

*> 113.0.0.0/24 113.0.0.14 nolabel 24029

*> 172.16.10.0/24 113.0.0.14 nolabel 24029

*> 172.16.11.0/24 113.0.0.14 nolabel 24029

*> 172.16.12.0/24 113.0.0.14 nolabel 24029

RP/0/0/CPU0:XR3#sh mpls forwarding labels 24029 detail

Sun Jan 15 21:30:17.019 UTC

Local Outgoing Prefix Outgoing Next Hop Bytes

Label Label or ID Interface Switched

------ ----------- ------------------ ------------ --------------- ------------

24029 Aggregate BGP: Per-VRF Aggr[V] \

BGP 0

Updated Jan 15 21:28:37.186

MAC/Encaps: 0/0, MTU: 0

Label Stack (Top -> Bottom): { }

Packets Switched: 0

RP/0/0/CPU0:XR3#sh cef vrf BGP 113.0.0.14

Sun Jan 15 21:31:17.875 UTC

113.0.0.14/32, version 0, internal 0x1020001 0x0 (ptr 0xa13bb974) [2], 0x0 (0xa139ec68), 0x0 (0x0)

Updated Jan 7 14:50:58.061

local adjacency 113.0.0.14

Prefix Len 32, traffic index 0, Adjacency-prefix, precedence n/a, priority 15

via 113.0.0.14, GigabitEthernet0/0/0/0.1020, 6 dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa1044100 0x0], Internal 0xa190e0cc, parent-ifh 0x200

next hop 113.0.0.14

local adjacency

So now we need to receive traffic in from the core, pop the label, determine the VRF the label is associated with, then figure out what interface is in that VRF. Once all that is figured out, we can then proceed to switch the packet to the outgoing interface and do the L2 header rewrite. Not a ton of extra work, but extra none the less, there is a newer solution though, Per CE. We'll test this out with IPv6.

IOS PEs

mpls label mode vrf BGP protocol bgp-vpnv6 per-ce

On the XR PEs

vrf BGP

address-family ipv4 unicast

label mode per-ce

R1#sh bgp vpnv6 unicast vrf BGP labels | in 2131:CC1E::13

2131:CC1E::/64 2131:CC1E::13 26/nolabel

FC00::13/128 2131:CC1E::13 26/nolabel

FC00:213::13/128 2131:CC1E::13 nolabel/nolabel

FC00:1013::/64 2131:CC1E::13 26/nolabel

FC00:1113::/64 2131:CC1E::13 26/nolabel

FC00:1213::/64 2131:CC1E::13 26/nolabel

R1#sh mpls forwarding-table labels 26 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

26 No Label nh-id(1) 0 Gi1.1020 FE80::20C:29FF:FE44:53CF

MAC/Encaps=0/0, MRU=1504, Label Stack{}

No output feature configured

As you can see, the LFIB outputs are different, which now indicates a label value, 26, and it shows an outgoing interface, G1.1020 and an IPv6 next hop. This is exactly the purpose of CEF.

We can also verify this at the VRF level.

R1#sh vrf detail BGP | in label|ipv4|ipv6

Address family ipv4 unicast (Table ID = 0x1):

VRF label distribution protocol: not configured

VRF label allocation mode: per-vrf (Label 57)

Address family ipv6 unicast (Table ID = 0x1E000001):

VRF label distribution protocol: not configured

VRF label allocation mode: per-ce

We can verify the next hops as well.

R1#sh bgp vpnv6 unicast vrf BGP nexthops

# Paths Nexthop Address

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

23 ::FFFF:192.168.1.3

9 ::FFFF:192.168.1.5

11 ::FFFF:192.168.1.6

18 ::FFFF:192.168.1.13

5 2131:CC1E::13 (FE80::20C:29FF:FE44:53CF) (BGP)

9 ::FFFF:192.168.1.11

2 2131:CC1E::13 (STATIC)

The drawback to these enhancements is loss of visibility in the MPLS core for counters, we could see bytes switched on the PEs for a given prefix. Now only the aggregate label has an increment.

This is before the ping/trace.

R1#sh mpls forwarding-table interface Gi1.1020

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

26 No Label nh-id(1) 0 Gi1.1020 FE80::20C:29FF:FE44:53CF

R1#sh mpls forwarding-table labels 57

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

57 Pop Label IPv4 VRF[V] 0 aggregate/BGP

R13#ping vrf BGP 172.16.11.14 source 192.168.11.13

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.11.13

!!!!!

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

R13# traceroute vrf BGP ipv6

Target IPv6 address: FC00:11::14

Source address: FC00:1013::13

Insert source routing header? [no]:

Numeric display? [no]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Priority [0]:

Port Number [0]:

Type escape sequence to abort.

Tracing the route to FC00:11::14

1 2131:CC1E::1 2 msec 2 msec 1 msec

2 FC00::112 [MPLS: Labels 24009/24027 Exp 0] 9 msec 6 msec 5 msec

3 2016:12:13::13 [MPLS: Label 24027 Exp 0] 20 msec 20 msec 30 msec

4 2113:CC1E::14 [AS 143] 25 msec 14 msec 15 msec

This is after the ping/trace.

R1#sh mpls forwarding-table interface Gi1.1020

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

26 No Label nh-id(1) 1590 Gi1.1020 FE80::20C:29FF:FE44:53CF

R1#sh mpls forwarding-table labels 57

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

57 Pop Label IPv4 VRF[V] 590 aggregate/BGP

The last option for us is the all AFS on all VRFs.

IOS PEs

mpls label mode all-vrfs protocol all-afs vrf-conn-aggr

IOS XR doesn't support this variant, only the Per-VRF , per-CE and per-prefix are supported. You can apply these policies with an RPL. XR documentation states that if label mode is in use, per-vrf mode is used to allocate labels for connected, aggregate and local prefixes.

R1#sh bgp vpnv4 unicast vrf BGP labels | in /20

192.168.0.0/20 0.0.0.0 IPv4 VRF Aggr:57/aggregate(BGP

R1#sh mpls forwarding-table labels 57

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

57 Pop Label IPv4 VRF[V] 1770 aggregate/BGP

Thanks for stopping by!

Rob Riker, CCIE #50693

Saturday, January 14, 2017

CCIE SPv4 - MPLS L3 VPN - EIGRP PE-CE Routing

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will be taking a look at EIGRP as PE-CE Routing protocol. Like BGP and OSPF, both IPv4 and IPv6 are supported. This allows us to leverage EIGRP to do the same, there are a few unique details we will have to cover as we have with BGP and OSPF. EIGRP being a distance vector protocol, like RIPv2, normally would have to identify a method when redistributing routes into EIGRP, to calculate DUAL. In our case here, that isn't necessary, this is due to the "cost community" that is leveraged to copy the EIGRP metrics into BGP extended communities, carried in VPNv4/VPNv6 updates to the remote PE and then copied back into EIGRP. Very similar to how the IGP metric is copied to the BGP MED.

We will be leveraging "named mode" EIGRP in our scenario, I rarely ever use the "classic mode" EIGRP anymore. If you ask why, centralized configuration, I can do everything I need to under the Named mode process. At the same time, this is the only place where EIGRPv6 in a VRF is supported. I plan on showing you IOS and IOS XR syntax for the scenario, so we'll start with R14 and XR3, then take a look at R3 and R8.

R14

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

network 113.0.0.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

exit-address-family

XR3

router eigrp CCIE

vrf EIGRP

address-family ipv4

autonomous-system 90

redistribute bgp 50693

interface GigabitEthernet0/0/0/0.1090

address-family ipv6

autonomous-system 90

redistribute bgp 50693

interface GigabitEthernet0/0/0/0.1090

router bgp 50693

vrf EIGRP

rd 90:50693

address-family ipv4 unicast

redistribute eigrp 90

address-family ipv6 unicast

redistribute eigrp 90

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

redistribute bgp 50693

exit-af-topology

network 83.0.0.0 0.0.0.255

network 131.0.0.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute bgp 50693

exit-af-topology

exit-address-family

router bgp 50693

address-family ipv4 vrf EIGRP

redistribute eigrp 90

exit-address-family

address-family ipv6 vrf EIGRP

redistribute eigrp 90

exit-address-family

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

network 83.0.0.0 0.0.0.255

network 90.90.90.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map CONNECTED

exit-af-topology

exit-address-family

As you can see the configuration is relatively straightforward and easy to implement.

The part we need to focus on now is the PE EIGRP breakdown for the BGP VPNv4/VPNv6 info to see how that is all put together.

R3#sh bgp vpnv4 unicast vrf EIGRP 113.0.0.0/24

BGP routing table entry for 90:50693:113.0.0.0/24, version 381

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

Not advertised to any peer

Refresh Epoch 2

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.2 (192.168.1.2)

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

Extended Community: RT:90:50693 Cost:pre-bestpath:128:10240

0x8800:32768:0 0x8801:90:256 0x8802:65280:2560 0x8803:1:1500

0x8806:0:3232235789

Originator: 192.168.1.13, Cluster list: 192.168.1.2

mpls labels in/out nolabel/24017

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.14 (192.168.1.14)

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

Extended Community: RT:90:50693 Cost:pre-bestpath:128:10240

0x8800:32768:0 0x8801:90:256 0x8802:65280:2560 0x8803:1:1500

0x8806:0:3232235789

Originator: 192.168.1.13, Cluster list: 192.168.1.14

mpls labels in/out nolabel/24017

rx pathid: 0, tx pathid: 0

The majority of the above output has been covered in previous post, R2 is the best path since it has a lower Router ID. I want to focus on the Extended community information and break that down.

0x8800 is route information used for the Route Flag and tag

0x8801 is route metric and AS used for the ASN and dely

0x8802 is route metric and is used for Reliability, next-hop and bandwidth

0x8803 is route metric and is used for Reserve, load and MTU

0x8804 is external route metric and is used for Remote AS and Remote ID

0x8805 is external route metric and is used for Remote protocol and Remote metric

0x8806 is Originating Router ID

I'll add a loopback on R14 and give an IPv4 and IPv6 address, matching in it a route-map and redistributing it into IPv4/IPv6 EIGRP.

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map LO1000

exit-af-topology

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map LO1000

exit-af-topology

exit-address-family

route-map LO1000 permit 10

match interface Loopback1000

R3#sh bgp vpnv4 unicast vrf EIGRP 192.168.100.0

BGP routing table entry for 90:50693:192.168.100.0/24, version 388

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

Not advertised to any peer

Refresh Epoch 2

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.2 (192.168.1.2)

Origin incomplete, metric 10880, localpref 100, valid, internal, best

Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0

0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422

0x8805:11:0

Originator: 192.168.1.13, Cluster list: 192.168.1.2

mpls labels in/out nolabel/24020

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.14 (192.168.1.14)

Origin incomplete, metric 10880, localpref 100, valid, internal

Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0

0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422

0x8805:11:0

Originator: 192.168.1.13, Cluster list: 192.168.1.14

mpls labels in/out nolabel/24020

rx pathid: 0, tx pathid: 0

As you can see, the outputs changed a bit. We no longer see the 8806 as it is replaced with an 8805 and 8804. These metrics are received as BGP extended communities, when BGP is redistributed into EIGRP, those extended communities are copied as well, EIGRP understands what is being handed off and is able to use those values to populate metrics and run DUAL.

R8#sh ip route vrf EIGRP eigrp | b Gateway

Gateway of last resort is not set

59.0.0.0/24 is subnetted, 1 subnets

D 59.0.0.0 [90/15360] via 83.0.0.3, 00:29:57, GigabitEthernet1.1090

106.0.0.0/24 is subnetted, 1 subnets

D 106.0.0.0 [90/15360] via 83.0.0.3, 00:28:04, GigabitEthernet1.1090

113.0.0.0/24 is subnetted, 1 subnets

D 113.0.0.0 [90/15360] via 83.0.0.3, 00:37:09, GigabitEthernet1.1090

131.0.0.0/24 is subnetted, 1 subnets

D 131.0.0.0 [90/15360] via 83.0.0.3, 5d05h, GigabitEthernet1.1090

D EX 192.168.100.0/24

[170/16000] via 83.0.0.3, 00:08:37, GigabitEthernet1.1090

R8#sh ipv6 route vrf EIGRP eigrp | b App

ld - LISP dyn-eid, a - Application

D 2113:CC1E::/64 [90/15360]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D 2913:CC1E::/64 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00::9/128 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00::90/128 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00:100::/64 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

As you can see, all is well.

Thanks for stopping by!

Rob Riker, CCIE #50693

Thursday, January 12, 2017

CCIE SPv4 - MPLS L3 VPN - OSPF PE-CE Routing - Sham Links

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 sham links for OSPF as a PE-CE routing protocol. RFC 4577 defines this scenario as bridging OSPF area 0 over the MPLS backbone. With the MPLS Super Backbone, the CEs act as an ABR, injecting Type 3 LSAs into the area 0 that connects to the rest of the LAN.

We';; configure XR3 and R8 to form a "Sham Link" peering with each other over the MPLS backbone. The shamlink is a service provider "virtual link" that allows communication over the MPLS backbone enabling OSPF to run over the MPLS core. Effectively, all the CE sites that connect will look like they are part of the same area 0 domain.

R14

R14#sh ip route vrf OSPF ospf | b Gateway

Gateway of last resort is not set

10.0.0.0/32 is subnetted, 1 subnets

O E2 10.101.10.10 [110/2] via 113.0.0.13, 00:15:37, GigabitEthernet1.1110

11.0.0.0/24 is subnetted, 1 subnets

O E2 11.0.0.0 [110/1] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

16.0.0.0/32 is subnetted, 1 subnets

O E2 16.0.0.6 [110/1] via 113.0.0.13, 23:18:23, GigabitEthernet1.1110

83.0.0.0/24 is subnetted, 1 subnets

O E2 83.0.0.0 [110/1] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

106.0.0.0/24 is subnetted, 1 subnets

O E2 106.0.0.0 [110/1] via 113.0.0.13, 00:15:37, GigabitEthernet1.1110

110.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O E2 110.110.110.8/32 [110/2] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

O E2 110.110.110.13/32

[110/2] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

131.0.0.0/24 is subnetted, 1 subnets

O E2 131.0.0.0 [110/1] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

R14#sh ipv6 route vrf OSPF ospf | b App

ld - LISP dyn-eid, a - Application

OI 2001:11::/64 [110/2]

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

OI 2038:CC1E::/64 [110/2]

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

OI 2106:CC1E::/64 [110/2]

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

OI 2131:CC1E::/64 [110/2]

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

OE2 FC00:16::6/128 [110/1]

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

This is the current state of R14's OSPFv2 and OSPFv3 RIB.

Let's go ahead and configure the sham link. There are a few things that we need to have in place in order to get this scenario to work.

interface Loopback38

vrf forwarding OSPF

ip address 38.0.0.3 255.255.255.255

ipv6 address FC00:38::3/128

router bgp 50693

address-family ipv4 vrf OSPF

network 38.0.0.3 mask 255.255.255.255

redistribute ospf 110

exit-address-family

address-family ipv6 vrf OSPF

redistribute ospf 110 include-connected

network FC00:38::3/128

exit-address-family

router ospfv3 110

exit-address-family

address-family ipv6 unicast vrf OSPF

area 0 sham-link FC00:38::3 FC00:38::13

router ospf 110 vrf OSPF

area 0 sham-link 38.0.0.3 38.0.0.13

XR3

interface Loopback38

vrf OSPF

ipv4 address 38.0.0.13 255.255.255.255

ipv6 address fc00:38::13/128

rotuer bgp 50693

vrf OSPF

rd 110:50693

address-family ipv4 unicast

network 38.0.0.13/32

address-family ipv6 unicast

network fc00:38::13/128

router ospfv3 110

vrf OSPF

redistribute bgp 50693

area 0

sham-link fc00:38::13 fc00:38::3

router ospf 110

vrf OSPF

area 0

sham-link 38.0.0.13 38.0.0.3

Let's take a look at the verification.

RP/0/0/CPU0:XR3#sh ospf vrf OSPF sham-links

Thu Jan 12 21:14:49.269 UTC

Sham Links for OSPF 110, VRF OSPF

Sham Link OSPF_SL0 to address 38.0.0.3 is up

Area 0, source address 38.0.0.13

IfIndex = 2

Run as demand circuit

DoNotAge LSA allowed., Cost of using 1

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:03:684

Adjacency State FULL (Hello suppressed)

Number of DBD retrans during last exchange 0

Index 2/2, retransmission queue length 0, number of retransmission 0

First 0(0)/0(0) Next 0(0)/0(0)

Last retransmission scan length is 0, maximum is 0

Last retransmission scan time is 0 msec, maximum is 0 msec

RP/0/0/CPU0:XR3#sh ospfv3 vrf OSPF sham-links

Thu Jan 12 21:15:09.468 UTC

Sham Links for OSPFv3 110, VRF OSPF

Sham Link OSPF_SL0 to address fc00:38::3 is up

Area 0, source address fc00:38::13

IfIndex = 2

Run as demand circuit

DoNotAge LSA allowed., Cost of using 1

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:01

Adjacency State FULL (Hello suppressed)

Number of DBD retrans during last exchange 0

Index 2/2, retransmission queue length 0, number of retransmission 1

First 0(0)/0(0) Next 0(0)/0(0)

Last retransmission scan length is 1, maximum is 1

Last retransmission scan time is 0 msec, maximum is 0 msec

As you can see for both IPv4 and IPv6, the DNA bit is set as the SL runs as a demand circuit, hellos are configured to be sent every 10 seconds but since this is a P2P DC type circuit, hellos are suppressed and only used during the initial SL establishment. Demand Circuit means and the DNA or do not age bit are set which means that "paranoid" update will not happen. Like a Virtual link, a SL can have additional configuration, like authentication, if configured, the VL and SL should both be flapped to make sure the configuration took correctly.

On the CE side, R14 now has some "O" or Intra Area routes showing up.

R14#sh ipv6 route vrf OSPF ospf | b App

ld - LISP dyn-eid, a - Application

OI 2001:11::/64 [110/2]

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

O 2038:CC1E::/64 [110/3]

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

OI 2106:CC1E::/64 [110/2]

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

OI 2131:CC1E::/64 [110/2]

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

OE2 FC00:16::6/128 [110/1]

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

OE2 FC00:16::16/128 [110/1]

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

OE2 FC00:38::3/128 [110/1]

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

OE2 FC00:38::13/128 [110/1]

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

R14#sh ip route vrf OSPF ospf | b Gateway

Gateway of last resort is not set

10.0.0.0/32 is subnetted, 1 subnets

O IA 10.101.10.10 [110/4] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

11.0.0.0/24 is subnetted, 1 subnets

O IA 11.0.0.0 [110/3] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

16.0.0.0/32 is subnetted, 2 subnets

O E2 16.0.0.6 [110/1] via 113.0.0.13, 1d00h, GigabitEthernet1.1110

O E2 16.0.0.16 [110/1] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

38.0.0.0/32 is subnetted, 2 subnets

O E2 38.0.0.3 [110/1] via 113.0.0.13, 00:41:26, GigabitEthernet1.1110

O E2 38.0.0.13 [110/1] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

83.0.0.0/24 is subnetted, 1 subnets

O 83.0.0.0 [110/3] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

106.0.0.0/24 is subnetted, 1 subnets

O IA 106.0.0.0 [110/3] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

110.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O 110.110.110.8/32

[110/4] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

O IA 110.110.110.13/32

[110/4] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

131.0.0.0/24 is subnetted, 1 subnets

O IA 131.0.0.0 [110/3] via 113.0.0.13, 00:40:32, GigabitEthernet1.1110

The routes learned from R8 show up as "O" routes now. Let's go ahead and go and do a ping/trace test.

R14#ping vrf OSPF 110.110.110.8 source lo110

Type escape sequence to abort.

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

Packet sent with a source address of 110.110.110.14

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms

R14#trace vrf OSPF 110.110.110.8 source lo110

Type escape sequence to abort.

Tracing the route to 110.110.110.8

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

1 113.0.0.13 3 msec 2 msec 1 msec

2 10.13.2.2 [MPLS: Labels 20/56 Exp 0] 5 msec 6 msec 4 msec

3 83.0.0.3 [MPLS: Label 56 Exp 0] 5 msec 7 msec 4 msec

4 83.0.0.8 5 msec * 5 msec

This proves that we can reach the endpoint on the remote end.

Thanks for stopping by!

Rob Riker, CCIE #50693