Rob Riker/ Simplified Networking

Wednesday, April 4, 2018

Unified/Seamless MPLS on IOS and XR

Unified or Seamless MPLS is a really interesting topic and one of the last major topics I wanted to hit as I prepare for the SPv4 lab. It isn't a brand new technology nor does it introduce a new technology. Rather it uses existing features to enable scalability beyond a typical MPLS environment. There are 3 separate IGP domains, 2 IS-IS that are used to connect to the customer routers and an IGP domain of OSPF in the core. OSPF in the core is used to connect the the IS-IS "Islands". I like to refer to OSPF in the core as the backbone and IS-IS at the edge as the PoPs or Points of Presence that customers connect to.

The key thing is that the routers bordering the IGP domains, R7 and R8 on the left and R9 and XR6 on the right, for IS-IS adjacencies with each other and the PE routers in their respective domains. LDP is enabled in the domain. The ABRs and the core router, R5 and R6 form OSPF and LDP adjacencies. The core routers won't form an LDP adjacency with the ABRs until the ABRs redistribute the ABR loopbacks into OSPF via connected redistribution. At this point, IGP and LDP should be fully adjacent. The ABRs will see IGP routes to the core routers and other ABRs. The PE routers won't see the other IGP domain routes, only their local ABR routes.

BGP is then used to inter connect the environment, all routers exist in the same BGP ASN and eventually R1 and R3 will for a BGP VPNv4 unicast iBGP peerings with each other. The ABRs will be configured as BGP Route Reflectors for their local IGP domains to pass routes from the remote IGP domains. R7 and R8 will form an iBGP IPv4 peering to R1 and vice versa. During the iBGP configuration, the command "send-label" which will allocate a label used as a transport label to get traffic from R1 through R7 over to R9 and down to R3. The IOS ABRs will use the "next-hop-self all" which will update both iBGP and eBGP learned routes by the RR.

The ABRs will form iBGP IPv4 peerings with each other as well adding the "send-label" command to allocate a label for transport later on. Once the ABRs have formed iBGP peerings, the next step is to enable the VPNv4 iBGP peering between the PE routers, in this lab, only 2 PEs are used, but many may be configured. It would make sense to configure a PE router or multiple PE routers as a route reflectors to help with VPNv4 scaling, but for our testing purpose, a single iBGP VPNv4 peering is sufficient. Once this is complete, R1 and R3 will have formed an iBGP VPNv4 peering and be ready to begin forwarding labeled traffic.

Configuration in the above picture shows the addressing for both AFIs so I won't be adding in the interface level addressing but will show the IGP relevant configuration.

------------------------- Left Access configuration--------------------------------------

router isis 50693

net 49.0001.0000.0000.0001.00

is-type level-1

metric-style wide

log-adjacency-changes all

address-family ipv6

multi-topology

advertise passive-only

exit-address-family

mpls ldp autoconfig level-1

interface GigabitEthernet1.17

ip router isis 50693

interface GigabitEthernet1.18

ip router isis 50693

interface Loopback0

ip router isis 50693

router bgp 50693

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 192.0.2.3 remote-as 50693

neighbor 192.0.2.3 update-source Loopback0

neighbor 192.0.2.7 remote-as 50693

neighbor 192.0.2.7 update-source Loopback0

neighbor 192.0.2.8 remote-as 50693

neighbor 192.0.2.8 update-source Loopback0

address-family ipv4

redistribute connected route-map RM_LOOPBACK

neighbor 192.0.2.7 activate

neighbor 192.0.2.7 send-label

neighbor 192.0.2.8 activate

neighbor 192.0.2.8 send-label

exit-address-family

address-family vpnv4

neighbor 192.0.2.3 activate

neighbor 192.0.2.3 send-community extended

exit-address-family

address-family ipv4 vrf UMPLS

network 100.64.21.0 mask 255.255.255.0

neighbor 100.64.21.2 remote-as 65002

neighbor 100.64.21.2 activate

exit-address-family

route-map RM_LOOPBACK permit 10

match interface Loopback0

vrf definition UMPLS

rd 1:1

route-target export 1:1

route-target import 1:1

address-family ipv4

exit-address-family

address-family ipv6

exit-address-family

router isis 50693

net 49.0001.0000.0000.0007.00

metric-style wide

log-adjacency-changes all

address-family ipv6

multi-topology

advertise passive-only

exit-address-family

mpls ldp autoconfig

interface GigabitEthernet1.78

ip router isis 50693

interface GigabitEthernet1.17

ip router isis 50693

interface Loopback0

ip router isis 50693

router ospf 1

redistribute connected subnets route-map RM_LOOPBACK

network 100.64.71.0 0.0.0.255 area 0

network 100.64.75.0 0.0.0.255 area 0

mpls ldp autoconfig

ip prefix-list ISIS_LOOPBACK seq 5 permit 192.0.2.7/32

route-map RM_LOOPBACK permit 10

match ip address prefix-list ISIS_LOOPBACK

router bgp 50693

bgp cluster-id 192.0.2.7

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 192.0.2.1 remote-as 50693

neighbor 192.0.2.1 update-source Loopback0

neighbor 192.0.2.9 remote-as 50693

neighbor 192.0.2.9 update-source Loopback0

neighbor 192.0.2.16 remote-as 50693

neighbor 192.0.2.16 update-source Loopback0

address-family ipv4

network 192.0.2.7 mask 255.255.255.255

neighbor 192.0.2.1 activate

neighbor 192.0.2.1 route-reflector-client

neighbor 192.0.2.1 next-hop-self all

neighbor 192.0.2.1 send-label

neighbor 192.0.2.9 activate

neighbor 192.0.2.9 next-hop-self all

neighbor 192.0.2.9 send-label

neighbor 192.0.2.16 activate

neighbor 192.0.2.16 next-hop-self all

neighbor 192.0.2.16 send-label

exit-address-family

router isis 50693

net 49.0001.0000.0000.0008.00

advertise passive-only

metric-style wide

log-adjacency-changes all

passive-interface Loopback0

address-family ipv6

multi-topology

advertise passive-only

exit-address-family

mpls ldp autoconfig

interface GigabitEthernet1.18

ip router isis 50693

interface GigabitEthernet1.78

ip router isis 50693

router ospf 1

redistribute connected subnets route-map RM_LOOPBACK

network 100.64.85.0 0.0.0.255 area 0

mpls ldp autoconfig

ip prefix-list PL_LOOPBACK seq 5 permit 192.0.2.8/32

route-map RM_LOOPBACK permit 10

match ip address prefix-list PL_LOOPBACK

router bgp 50693

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 192.0.2.1 remote-as 50693

neighbor 192.0.2.1 update-source Loopback0

neighbor 192.0.2.9 remote-as 50693

neighbor 192.0.2.9 update-source Loopback0

neighbor 192.0.2.16 remote-as 50693

neighbor 192.0.2.16 update-source Loopback0

address-family ipv4

redistribute connected route-map RM_LOOPBACK

neighbor 192.0.2.1 activate

neighbor 192.0.2.1 route-reflector-client

neighbor 192.0.2.1 next-hop-self all

neighbor 192.0.2.1 send-label

neighbor 192.0.2.9 activate

neighbor 192.0.2.9 next-hop-self all

neighbor 192.0.2.9 send-label

neighbor 192.0.2.16 activate

neighbor 192.0.2.16 next-hop-self all

neighbor 192.0.2.16 send-label

exit-address-family

----------------------Core Configuration---------------------

router ospf 1

network 100.64.0.0 0.0.255.255 area 0

mpls ldp autoconfig

interface Loopback0

ip ospf 1 area 0

router ospf 1

network 100.64.0.0 0.0.255.255 area 0

mpls ldp autoconfig

interface Loopback0

ip ospf 1 area 0

------------------------Right Access Configuration--------------

router ospf 1

redistribute connected subnets route-map RM_LOOPBACK

network 100.64.69.0 0.0.0.255 area 0

mpls ldp autoconfig

route-map RM_LOOPBACK permit 10

match ip address prefix-list PL_LOOPBACK

ip prefix-list PL_LOOPBACK seq 5 permit 192.0.2.9/32

match ip address prefix-list PL_LOOPBACK

router isis 50693

net 49.0002.0000.0000.0009.00

is-type level-2-only

metric-style wide

mpls ldp autoconfig

interface Loopback0

ip router isis 50693

interface GigabitEthernet1.39

ip router isis 50693

router bgp 50693

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 192.0.2.3 remote-as 50693

neighbor 192.0.2.3 update-source Loopback0

neighbor 192.0.2.7 remote-as 50693

neighbor 192.0.2.7 update-source Loopback0

address-family ipv4

neighbor 192.0.2.3 activate

neighbor 192.0.2.3 route-reflector-client

neighbor 192.0.2.3 next-hop-self all

neighbor 192.0.2.3 send-label

neighbor 192.0.2.7 activate

neighbor 192.0.2.7 next-hop-self all

neighbor 192.0.2.7 send-label

exit-address-family

XR6

router isis 50693

net 49.0002.0000.0000.0016.00

log adjacency changes

address-family ipv4 unicast

metric-style wide

advertise passive-only

attached-bit send never-set

mpls ldp auto-config

address-family ipv6 unicast

metric-style wide

advertise passive-only

interface Loopback0

passive

address-family ipv4 unicast

interface GigabitEthernet0/0/0/0.36

address-family ipv4 unicast

interface GigabitEthernet0/0/0/0.56

circuit-type level-2-only

point-to-point

address-family ipv4 unicast

interface GigabitEthernet0/0/0/0.63

address-family ipv4 unicast

router ospf 1

mpls ldp auto-config

redistribute connected route-policy RPL_LOOPBACK

area 0

interface GigabitEthernet0/0/0/0.66

prefix-set PS_LOOPBACK

192.0.2.16/32

end-set

route-policy RPL_LOOPBACK

if destination in PS_LOOPBACK then

pass

endif

end-policy

router bgp 50693

ibgp policy out enforce-modifications

address-family ipv4 unicast

allocate-label all

address-family vpnv4 unicast

neighbor-group VPNV4

remote-as 50693

update-source Loopback0

neighbor 192.0.2.3

remote-as 50693

update-source Loopback0

address-family ipv4 labeled-unicast

route-reflector-client

next-hop-self

neighbor 192.0.2.7

remote-as 50693

update-source Loopback0

address-family ipv4 labeled-unicast

next-hop-self

neighbor 192.0.2.8

remote-as 50693

update-source Loopback0

address-family ipv4 labeled-unicast

next-hop-self

router isis 50693

net 49.0002.0000.0000.0003.00

metric-style wide

log-adjacency-changes all

address-family ipv6

multi-topology

advertise passive-only

exit-address-family

mpls ldp autoconfig level-1

interface GigabitEthernet1.39

ip router isis 50693

interface Loopback0

ip router isis 50693

vrf definition UMPLS

rd 1:1

route-target export 1:1

route-target import 1:1

address-family ipv4

exit-address-family

address-family ipv6

exit-address-family

router bgp 50693

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 192.0.2.1 remote-as 50693

neighbor 192.0.2.1 update-source Loopback0

neighbor 192.0.2.9 remote-as 50693

neighbor 192.0.2.9 update-source Loopback0

neighbor 192.0.2.13 remote-as 50693

neighbor 192.0.2.13 update-source Loopback0

neighbor 192.0.2.16 remote-as 50693

neighbor 192.0.2.16 update-source Loopback0

address-family ipv4

redistribute connected route-map RM_LOOPBACK

neighbor 192.0.2.9 activate

neighbor 192.0.2.9 send-label

neighbor 192.0.2.13 activate

neighbor 192.0.2.13 send-label

neighbor 192.0.2.16 activate

neighbor 192.0.2.16 send-label

exit-address-family

address-family vpnv4

neighbor 192.0.2.1 activate

neighbor 192.0.2.1 send-community extended

exit-address-family

address-family ipv4 vrf UMPLS

neighbor 100.64.34.4 remote-as 65004

neighbor 100.64.34.4 activate

exit-address-family

Now that we have completed the configuration, I omitted R8 as it's configuration is identical as R7 and didn't enable the IGP peering between XR6 and R3. All the other configuration is working.

R1#sh isis neighbors

Tag 50693:

System Id Type Interface IP Address State Holdtime Circuit Id

R7 L1 Gi1.17 100.64.17.7 UP 27 R1.01

R8 L1 Gi1.18 100.64.18.8 UP 29 R1.02

We're peered from R1 to R7 and R8 via IS-IS.

R1#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 Pop Label 192.0.2.7/32 0 Gi1.17 100.64.17.7

17 Pop Label 192.0.2.8/32 0 Gi1.18 100.64.18.8

18 No Label 100.64.21.0/24[V] \

10098 aggregate/UMPLS

19 No Label 192.0.2.2/32[V] 80042 Gi1.21 100.64.21.2

20 Pop Label 100.64.78.0/24 0 Gi1.17 100.64.17.7

21 No Label 10.2.4.0/24[V] 0 Gi1.21 100.64.21.2

22 No Label l2ckt(1) 1215 Gi2 point2point

We have labels allocated for R7 and R8 which are locally allocated.

R1#sh bgp vpnv4 unicast all summary | b Neighbor

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

100.64.21.2 4 65002 1690 1687 127 0 0 1d00h 3

192.0.2.3 4 50693 177 180 127 0 0 02:36:11 6

We see that R3 is advertising us 6 routes and R2 is advertising 3 routes.

R1#sh bgp vpnv4 unicast all | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf UMPLS)

*>i 10.1.1.0/24 192.0.2.3 0 100 0 65004 ?

*>i 10.1.100.0/24 192.0.2.3 0 100 0 65004 ?

* i 10.2.4.0/24 192.0.2.3 0 100 0 65004 ?

*> 100.64.21.2 0 0 65002 ?

*> 100.64.21.0/24 0.0.0.0 0 32768 i

* 100.64.21.2 0 0 65002 ?

*>i 100.64.34.0/24 192.0.2.3 0 100 0 65004 i

*>i 100.64.102.0/24 192.0.2.3 0 100 0 65004 ?

*> 192.0.2.2/32 100.64.21.2 0 0 65002 i

*>i 192.0.2.4/32 192.0.2.3 0 100 0 65004 i

We see that the next hop of 192.0.2.3 is showing us having learned R4's loopback, the connected subnet and a few other routes that R4 has advertised.

What this shows us is that the above configuration was successful in propagating routes so that R3 and R1 could see each others loopbacks which is the whole goal of this intense configuration. I am not doing is showing an extreme breakdown on a hop basis. I will do that in the next post as I want to breakdown each step.

What I want to show now is proof that the BGP labels are being used and a three label stack is seen in when R2 and R4 communicate.

R1 to R3 traceroute:

R1#traceroute 192.0.2.3 source loopback 0 num

Type escape sequence to abort.

Tracing the route to 192.0.2.3

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

1 100.64.17.7 [MPLS: Label 30 Exp 0] 8 msec 7 msec 14 msec

2 100.64.75.5 [MPLS: Labels 22/17 Exp 0] 31 msec 39 msec 31 msec

3 100.64.56.6 [MPLS: Labels 17/17 Exp 0] 26 msec 32 msec 31 msec

4 100.64.69.9 [MPLS: Label 17 Exp 0] 21 msec 20 msec 68 msec

5 100.64.39.3 17 msec * 7 msec

A 2 label stack from R7 through R9.

R2#traceroute 192.0.2.4 so lo0 num

Type escape sequence to abort.

Tracing the route to 192.0.2.4

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

1 100.64.21.1 4 msec 4 msec 3 msec

2 100.64.17.7 [MPLS: Labels 30/22 Exp 0] 9 msec 9 msec 8 msec

3 100.64.75.5 [MPLS: Labels 22/17/22 Exp 0] 27 msec 32 msec 37 msec

4 100.64.56.6 [MPLS: Labels 17/17/22 Exp 0] 31 msec 32 msec 76 msec

5 100.64.69.9 [MPLS: Labels 17/22 Exp 0] 24 msec 18 msec 20 msec

6 100.64.34.3 [AS 65004] [MPLS: Label 22 Exp 0] 17 msec 20 msec 20 msec

7 100.64.34.4 [AS 65004] 20 msec * 9 msec

Thanks for stopping by!

Rob Riker, CCIE #50693

Monday, March 5, 2018

IOS and XR Multicast VPN with Profile 1 - MLDP MP2MP PIM Default MDT with BSR and AutoRP

Multipoint GRE tunnels between the PEs was the first flavor of mVPN. Since LDP is deployed in the SP core, we can leverage the LSPs that have been built in the core. The default MDT uses LDP for transport and not GRE tunnels between the PEs. The idea is to enable mLDP as the transport. Default MDT-mLDP, also referred to as Multi-Directional Inclusive - Provider Multicast Service Interface (MI-PMSI) or Profile 1. The end result is MP2MP bidirectional LDP adjacencies that allow the PEs to exchange PIM communication from the customers, instead of the traffic being forwarded over mGRE.

BSR is used in the customer network and Auto RP is used in the SP network.

This is configured on all the IOS XE routers. This is used to inform the SP routers that LDP is used for PIM transport.

ip pim mpls source Loopback0

One device in the SP core needs to be configured as the root of the MP2MP tree. This is configured under the VRF process for the address families that mLDP applies to. Specify the VPN ID at this point as well.

IOS-XE
mdt default mpls mldp x.x.x.x

IOS-XR
mdt default mldp ipv4 x.x.x.x

IOS XE PE routers
vrf definition MCAST
rd 1:1
vpn id 1:1
!
address-family ipv4
mdt default mpls mldp 172.16.100.1

*Mar 5 23:49:35.292: MLDP: Reevaluating peers for nhop: 10.1.9.1
*Mar 5 23:49:36.239: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up
*Mar 5 23:49:36.703: %PIM-5-DRCHG: VRF MCAST: DR change from neighbor 0.0.0.0 to 172.16.100.9 on interface Lspvif1
*Mar 5 23:49:56.565: %PIM-5-NBRCHG: VRF MCAST: neighbor 172.16.100.3 UP on interface Lspvif1

*Mar 5 23:50:26.520: %PIM-5-NBRCHG: VRF MCAST: neighbor 172.16.100.110 UP on interface Lspvif1

R9#sh mpls mldp neighbors

MLDP peer ID : 172.16.100.1:0, uptime 1d07h Up,
Target Adj : No
Session hndl : 1
Upstream count : 1
Branch count : 0
Path count : 1
Path(s) : 10.1.9.1 LDP GigabitEthernet1.19
Nhop count : 1
Nhop list : 10.1.9.1

R9#sh mpls mldp root

Root node : 172.16.100.1
Metric : 20
Distance : 115
Interface : GigabitEthernet1.19 (via unicast RT)
FEC count : 1
Path count : 1
Path(s) : 10.1.9.1 LDP nbr: 172.16.100.1:0 GigabitEthernet1.19

R9#sh mpls mldp bindings
System ID: 1
Type: MP2MP, Root Node: 172.16.100.1, Opaque Len: 14
Opaque value: [mdt 1:1 0]
lsr: 172.16.100.1:0, remote binding[U]: 37, local binding[D]: 44 active

R9#show mpls forwarding-table labels 44 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
44 No Label [mdt 1:1 0][V] 244 aggregate/MCAST
MAC/Encaps=0/0, MRU=0, Label Stack{}, via Ls1
VPN route: MCAST
No output feature configured
Broadcast

As you can see on R9, the label value of 44 is bound to the mLDP configuration and after pinging 224.1.1.1 from R5, we see that 244 bytes of traffic were label switched. This indicates that traffic is supported and forwarded.

IOS XR PE routers
mpls ldp
mldp
!
vrf MCAST
vpn id 1:1
address-fammily ipv4 unicast
!
route-policy MDT_mLDP
set core-tree mldp
end-policy
!
multicast-routing
vrf MCAST
address-family ipv4
mdt default mldp ipv4 172.16.100.1
!
router pim
vrf MCAST
address-family ipv4
rpf topology route-policy MDT_mLDP

RP/0/0/CPU0:XR9#sh mpls mldp root
Tue Mar 6 00:13:47.947 UTC
mLDP root database
Root node : 172.16.100.1
Metric : 30
Distance : 115
FEC count : 1
Path count : 1

Path(s) : 10.11.19.11 LDP nbr: 172.16.100.11:0

RP/0/0/CPU0:XR9#sh mpls mldp bindings
Tue Mar 6 00:14:00.916 UTC
mLDP MPLS Bindings database

LSP-ID: 0x00001 Paths: 2 Flags: Pk
0x00001 MP2MP 172.16.100.1 [mdt 1:1 0]
Local Label: 24025 Remote: 24021 NH: 10.11.19.11 Inft: GigabitEthernet0/0/0/0.1119 Active

Local Label: 24024 Remote: 1048577 Inft: LmdtMCAST RPF-ID: 3 TIDv4/v6: 0xE0000011/0xE0800011

Even though IOS XR PEs are configured, it doesn't appear that Profile 1 is supported in the data plane on IOS XRv for either XRv 5.3 or XRv 6.0. As I added the configuration to XR9 and XR8 and tested R5 multicast group pings, neither R13 or R14 interface addresses responded.

I received this message from the console after enabling "debug mpls mldp all"

RP/0/0/CPU0:Mar 6 00:28:18.084 : mpls_ldp[1049]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00001 [mdt 1:1 0] MP2MP 172.16.100.1, Add PIM MDT branch remote label no_label, local label no_label
RP/0/0/CPU0:Mar 6 00:28:20.153 : config[65738]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'Rob'. Use 'show configuration commit changes 1000000028' to view the changes.

RP/0/0/CPU0:XR8(config-pim-MCAST-ipv4)#RP/0/0/CPU0:Mar 6 00:28:28.453 : netio[312]: %PKT_INFRA-PAK-3-OWNERSHIP_PROCESS_FREE : Client with pid 434260 tried to access freed packet b0c08a0c (pak pid -434260) : pkg/bin/netio : (PID=434260) : -Traceback= e7de732 f7f6997 e7d18b4 f475f26 4225597 422265e d17d445 d17b518 42219ee d1c7050

This indicates to me either there is an issue on the device or other problem that inhibits XR from forwarding the traffic. IOSXR 9ks do this as well for L2VPN data plane forwarding. This tells me that data plane support is not available for this profile.

IOS and IOS XR Multicast VPN with the Rosen Model Default MDT and Data MDT with BSR and AutoRP

The default MDT is used for control plane communication between the PEs, this is for PIM communication, Joins, Prunes and other communication. This is the equivalent to PIM Dense mode, all PEs get the communication.
The data MDT is primarily used for bandwidth optimization and allows for multiple groups to be configured and not all PEs respond or forward the traffic. The idea is that when customer routers send a C-PIM join message into the provider network. The provider network takes that info and forwards to the RP of the provider. The customer also has an RP configured, this information is passed over the provider network. The data MDT is not a required configuration, if the network only sees low bandwidth flows, if high bandwidth flows are present, then moving from the shared tree to the shortest path tree is necessary to take the optimal path through the network.
On IOS and IOS XE, the command "ip pim ssm default" is needed. This is used to create (S, G) entries in the MRIB for optimized communication.
IOS XR by default is listening for SSM traffic already.

All the IOS routers need to be configured with updated mdt default configuration and add the mdt data capability as well as the ip pim ssm default configuration. In our case I am already using the 232.0.0.1 multicast address which is the SSM range. So we don't have to change the address, if it was the address 239.0.0.1 then we would need to change to the 232.x.x.x address block. Since the BGP IPv4 MDT is already enabled, we don't need to add that in. We will use the 232.10.10.0/24 data range for dynamically created groups.
All IOS XE routers in the SP core:

ip pim ssm default

All IOS XE routers that are PEs in the SP:

vrf definition MCAST

address-family ipv4

mdt default 232.0.0.1

mdt data 232.10.10.0 0.0.0.255

All IOS XR PEs in the SP, XR 5.3 and 6.0. XR 5.3 supports the data plane:

XR8

multicast-routing

address-family ipv4

mdt source Loopback0

interface all enable

!

vrf MCAST

address-family ipv4

mdt source Loopback0

interface all enable

mdt default ipv4 232.0.0.1

mdt data 232.18.18.0/24

!

XR9

multicast-routing

address-family ipv4

mdt source Loopback0

interface all enable

!

vrf MCAST

address-family ipv4

mdt source Loopback0

interface all enable

mdt default ipv4 232.0.0.1

mdt data 232.19.19.0/24

!

XR3

multicast-routing

address-family ipv4

mdt source Loopback0

interface all enable

!

vrf MCAST

address-family ipv4

mdt source Loopback0

interface all enable

mdt default ipv4 232.0.0.1

mdt data 232.13.13.0/24

Now that we have configure all the routers in the SP core, we need to go around and test the functionality. We'll add another multicast group, which is configured by changing the join group from 224.1.1.1 to 224.1.2.3 on a handful of routers. The idea is that PIM control plane messages are sent via the MDT Default tree and that the actual multicast flows will use the MDT Data tree. Depending on the placement of the RP, which in this case is XR9, the traffic should be moved from the shared tree to the shortest path tree. Meaning that the traffic should flow through the RP for the entire flow, rather it should be pruned off the shared tree and onto the shortest path tree.

This is accomplished by a PIM shared tree prune and PIM shortest path tree join. During the switch-over, a slight increase in latency is expected. Not all flows will be switched over, since the RP is XR9, traffic from R14 will never be switched over as it has to flow through the RP to reach R5. R5 is the source and R14 is a receiver. Because of this, when R5 pings 224.1.2.3, the ping goes out to all PEs that have joined the appropriate groups.

Typically SPT switchover happens during the second ping for each receiver, indicated by the 1, here all of the initial ping responses drop after the second ping, showing that a switch over occurred.

R5#ping 224.1.1.1 repeat 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 172.16.100.120, 147 ms

Reply to request 0 from 10.12.9.12, 139 ms

Reply to request 0 from 10.4.7.7, 104 ms

Reply to request 0 from 10.10.11.11, 93 ms

Reply to request 1 from 10.4.7.7, 108 ms

Reply to request 1 from 10.10.11.11, 76 ms

Reply to request 1 from 10.4.7.7, 54 ms

Reply to request 1 from 172.16.100.120, 39 ms

Reply to request 1 from 10.12.9.12, 28 ms

Reply to request 2 from 10.4.7.7, 27 ms

Reply to request 2 from 10.10.11.11, 50 ms

Reply to request 2 from 172.16.100.120, 33 ms

Reply to request 2 from 10.12.9.12, 33 ms

Same thing here, the responses from R13 and R14 stay consistent due to flowing through the RP and having to flow through the router just above the RP.

R5#ping 224.1.2.3 repeat 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 224.1.2.3, timeout is 2 seconds:
Reply to request 0 from 10.4.8.8, 63 ms

Reply to request 0 from 10.18.13.13, 329 ms

Reply to request 0 from 10.14.19.14, 130 ms

Reply to request 1 from 10.4.8.8, 25 ms

Reply to request 1 from 10.18.13.13, 262 ms

Reply to request 1 from 10.14.19.14, 95 ms

Reply to request 2 from 10.18.13.13, 151 ms

Reply to request 2 from 10.14.19.14, 98 ms

Reply to request 2 from 10.4.8.8, 73 ms

IOS and IOS XR Multicast VPN with the Rosen Model Default MDT with BSR and AutoRP

Auto RP is the Cisco proprietary RP distribution mechanism. It uses the same logic as BSR, or I should say, BSR uses the same logic as Auto RP. Auto RP leverages the mapping agent and the rp candidate options like BSR. IOS XR support it as well. I have configured R1 as the Auto RP mapping agent and RP candidate and XR9 as another RP candidate. Since we are not running PIM dense mode anywhere we need to add a command "ip pim autorp listener".

Candidate RPs (C-RP):

Routers willing to be the RP
Announce themselves to the MA via 224.0.1.39

Mapping Agent (MA):

Decide who will be the RP from the Candidates RP
Will inform the rest of the network about the elected RP via 224.0.1.40

I configured Auto RP in the SP core and left BSR configured in the customer network.

R1 is a Mapping agent and a RP candidate. XR9 is a RP candidate.

ip pim autorp listener

ip pim send-rp-announce Loopback0 scope 255

ip pim send-rp-discovery Loopback0 scope 255

XR9

router pim

address-family ipv4

auto-rp candidate-rp Loopback0 scope 255 group-list 224-4 interval 60

Now we can check on R3 to see what the rp mappings info has to say.

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 172.16.100.19 (?), v2

Info source: 172.16.100.1 (?), elected via Auto-RP

Uptime: 01:36:48, expires: 00:02:35

RP/0/0/CPU0:XR8#sh pim rp mapping

Mon Mar 5 11:28:24.979 UTC

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 172.16.100.19 (?), v2

Info source: 172.16.100.1 (?), elected via autorp

Uptime: 00:47:56, expires: 00:02:40

Group(s) 224.0.0.0/4

RP 172.16.100.1 (?), v2

Info source: 0.0.0.0 (?), elected via config

Uptime: 14:53:30, expires: never

XR9 is the RP for the SP core. XR9 communicated with R1 to let R1 know XR9 is an RP candidate. R1 is the distributor of information in the SP core.

So now we'll check on R12 to see what it sees an as RP for the customer network.

R12#sh ip pim rp map

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 172.16.100.5 (?), v2

Info source: 172.16.100.5 (?), via bootstrap, priority 0, holdtime 150

Uptime: 02:19:19, expires: 00:01:41

We see that R12 sees R5 as the BSR and RP candidate. Let's make sure that reachability is still there.

R5#ping 224.1.1.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.4.8.8, 51 ms

Reply to request 0 from 10.18.13.13, 374 ms

Reply to request 0 from 10.14.19.14, 227 ms

Reply to request 0 from 10.10.11.11, 195 ms

Reply to request 0 from 10.4.7.7, 138 ms

Reply to request 0 from 172.16.100.120, 127 ms

Reply to request 0 from 10.12.9.12, 119 ms

We see that when R5 pings the multicast group 224.1.1.1 that all the customer routers respond, these are the customer include those connected to XR 5.3 PEs, not XR 6.0

IOS and IOS XR Multicast VPN with the Rosen Model Default MDT with Boot Strap Router or BSR

BSR or Bootstrap Router is the open standard, RFC 5059, for distributing RP info through out the multicast PIM enabled network. BSR messages are sent inside of PIM ver2 messages where ever PIM is enabled and flowing. PIM builds the connections per router to allow routed multicast to flow. We've already taken a look at static RP which needs to be configured on every router that will participate in multicast forwarding. This requirement makes Static RP challenging to configure. The nice thing about SP mVPN providing transport for Customer multicast is that the RP distribution method chosen by the provider is independent of the customer. The provider may choose Auto-RP and the customer could choose BSR or vice-versa. In this post we will use BSR for both the customer and provider multicast networks. For ease of migration from Static RP to BSR I have configured BSR to use the same loopback interfaces that Static RP previously used. R1's loopback 0 and R5's loopback 0 interfaces.

BSR and Auto-RP operate differently that Static RP, both support the RP information distributor and the RP assigner. These are terms I made up, the "ip pim bsr-candidate loopback 0" is the information distributor and the "ip pim rp-candidate loopback 0" is used to define the RP itself. This would mean that many different routers could be the RP. Typically an RP filter is used, where one RP would service the first half of the 224/4 range and the other the back half. We won't be testing that out in this post. The BSR candidate and RP candidate can both be the same router, which in our case is what I configured.

R5 - Customer RP
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

R1 - Service Provider RP
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

Not configured in our topology or scenario but worth mentioning:
IOS XR BSR Configuration
router pim
address-family ipv4
bsr candidate-bsr 172.16.100.19 hash-mask-len 30 priority 1
bsr candidate-rp 172.16.100.19 priority 192 interval 60

R4 - PE Router servicing R7 and R8
R4#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 172.16.100.1 (?), v2
Info source: 172.16.100.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:30:52, expires: 00:01:39

XR9 - PE Router servicing R14
RP/0/0/CPU0:XR9#sh pim rp mapping
Mon Mar 5 09:31:40.742 UTC
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 172.16.100.1 (?), v2
Info source: 10.11.19.11 (?), elected via bsr, priority 0, holdtime 150
Uptime: 00:31:39, expires: 00:01:56

Customer multicast receiver
R12#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 172.16.100.5 (?), v2
Info source: 172.16.100.5 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:31:41, expires: 00:02:01

Now that we have configured BSR and verified that the RP information has been distributed, we will now test multicast.

R5#ping 224.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.10.11.11, 59 ms
Reply to request 0 from 10.18.13.13, 321 ms
Reply to request 0 from 10.14.19.14, 257 ms
Reply to request 0 from 10.4.7.7, 193 ms
Reply to request 0 from 172.16.100.120, 130 ms
Reply to request 0 from 10.12.9.12, 118 ms
Reply to request 0 from 10.4.8.8, 79 ms

We can see that it does work using the BSR configuration.

Sunday, March 4, 2018

IOS and IOS XR Multicast VPN with the Rosen Model Default MDT with Static RP

In this post we will follow on from the previous post where we looked at Multicast VPN on just IOS. We'll expand on that post with this one. Just a couple of things before we get into the fun stuff. The topology has grown significantly since the last post, this was done as the original 2 IOS XR PE routers running IOS XR 6.0 code don't appear to support multicast in the data plane. I have attempted mVPN on both IOS XR 6.0 OVA and .VMDK variations. These are the same .VMDK used for VIRL, that's where I downloaded it from. I ended up using IOS XR 5.3 OVA, the OVA is the only version tested that supports the dataplane. I have not tested any other versions, so you may get lucky if you find a version that works. However, for those with an interest of the CCIE SPv4 lab exam, IOS XR 6.0 is the version listed to be used in the lab exam.

So like the previous post, the is the MDT default, which means that like PIM Dense mode, every PE gets the traffic even if the traffic isn't destined for it.

XR9 is the bottom left router connected to R14 and XR1. IOS XR uses two different constructs to enable mVPN. IOS XR supports both enterprise and service provider multicast. We'll configure multicast on IOS XR and show the configuration of R3 just to show IOS and IOS XR in the same post. R5 is the multicast source, ping 224.1.1.1 from here should get responses from 6 receivers

PIM or Protocol Independent Mutlicast is used to build PIM trees between all the routers. Without PIM enabled, routed multicast can't flow between the routers and is restricted to a TTL of 1 or link local multicast. The PIM construct is used to define the RP address, where to source PIM traffic from and define VRF specific info. The RP address of 172.16.100.1 is the RP of the SP and the VRF RP address is the RP of the customer.

The multicast construct enables multicast to be forwarded. The MDT or multicast distribution tree is used to build the PIM tunnels. To avoid an RPF issue, it is a best practice to enable multicast on all interfaces enabled for IGP. Specify the MDT source, since this is a PE router, the MDT source should be the loopback that is the LDP and BGP source. Under the VRF, specifying the MDT default multicast group address.

XR9
multicast-routing
address-family ipv4
mdt source Loopback0
interface all enable
!
vrf MCAST
address-family ipv4
mdt source Loopback0
interface all enable
mdt default ipv4 232.0.0.1
!
router pim
address-family ipv4
rp-address 172.16.100.1
interface Loopback0
!
vrf MCAST
address-family ipv4
rp-address 172.16.100.5
interface GigabitEthernet0/0/0/0.1419
!
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
address-family ipv6 unicast
!
address-family vpnv6 unicast
!
address-family ipv4 mdt
!
neighbor 172.16.100.1
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
address-family ipv4 mdt
!
!
vrf MCAST
rd 1:1
address-family ipv4 unicast
!
address-family ipv6 unicast

RP/0/0/CPU0:XR9#sh pim neighbor
Sun Mar 4 23:56:32.026 UTC

Neighbor Address Interface Uptime Expires DR pri Flags

10.11.19.11 GigabitEthernet0/0/0/0.1119 01:38:18 00:01:31 1 B
10.11.19.19* GigabitEthernet0/0/0/0.1119 01:38:23 00:01:29 1 (DR) B P E
172.16.100.19* Loopback0 01:38:23 00:01:21 1 (DR) B P

This validates that there are PIM neighbors, in this case it is XR1.

RP/0/0/CPU0:XR9#sh pim vrf MCAST neighbor
Sun Mar 4 23:56:41.246 UTC

Neighbor Address Interface Uptime Expires DR pri Flags

10.14.19.14 GigabitEthernet0/0/0/0.1419 01:36:38 00:01:36 1 P
10.14.19.19* GigabitEthernet0/0/0/0.1419 01:38:32 00:01:20 1 (DR) B P E
172.16.100.3 mdtMCAST 01:29:31 00:01:18 1 P
172.16.100.9 mdtMCAST 01:29:58 00:01:19 1 P
172.16.100.18 mdtMCAST 01:29:42 00:01:31 1
172.16.100.19* mdtMCAST 01:38:28 00:01:34 1 P
172.16.100.110 mdtMCAST 01:29:57 00:01:21 1 (DR) P

There are also VRF MCAST PIM neighbors, one to R14 which is the G0/0/0/0.1419, there others are MDT peers from the PIM tunnels, which are mGRE tunnels.

RP/0/0/CPU0:XR9#sh bgp ipv4 mdt | b Network
Sun Mar 4 23:57:28.713 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1
*>i172.16.100.3/96 172.16.100.3 0 100 0 ?
*>i172.16.100.4/96 172.16.100.4 0 100 0 ?
*>i172.16.100.9/96 172.16.100.9 0 100 0 ?
*>i172.16.100.14/96 172.16.100.14 100 0 i
*>i172.16.100.18/96 172.16.100.18 100 0 i
*> 172.16.100.19/96 0.0.0.0 0 i
*>i172.16.100.110/96 172.16.100.110 0 100 0 ?

Processed 7 prefixes, 7 paths

R14#sh ip pim neighbor | b Address
Address Prio/Mode
10.14.19.19 GigabitEthernet1.1419 01:43:29/00:01:28 v2 1 / DR P G

R3
ip multicast-routing distributed
!
ip multicast-routing vrf MCAST distributed
!
interface GigabitEthernet1.13
ip pim sparse-mode
!
interface Loopback0
ip pim sparse-mode
!
interface GigabitEthernet1.35
vrf forwarding MCAST
ip pim sparse-mode
!
ip pim rp-address 172.16.100.1
!
ip pim vrf MCAST rp-address 172.16.100.5
!
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.100.1 remote-as 1
neighbor 172.16.100.1 update-source Loopback0
!
address-family ipv4 mdt
neighbor 172.16.100.1 activate
neighbor 172.16.100.1 send-community both

R3#sh bgp ipv4 mdt all
BGP table version is 25, local router ID is 172.16.100.3
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: 1:1 (default for vrf MCAST)
*> 172.16.100.3/32 0.0.0.0 0 ?
*>i 172.16.100.4/32 172.16.100.4 0 100 0 ?
* i 172.16.100.4 0 100 0 ?
* i 172.16.100.9/32 172.16.100.9 0 100 0 ?
*>i 172.16.100.9 0 100 0 ?
*>i 172.16.100.13/32 172.16.100.13 100 0 i
*>i 172.16.100.14/32 172.16.100.14 100 0 i
*>i 172.16.100.18/32 172.16.100.18 100 0 i
* i 172.16.100.18 100 0 i
*>i 172.16.100.19/32 172.16.100.19 100 0 i
*>i 172.16.100.110/32

172.16.100.110 0 100 0 ?

R1
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor MCAST peer-group
neighbor MCAST remote-as 1
neighbor MCAST update-source Loopback0
neighbor 172.16.100.19 peer-group MCAST
!
address-family ipv4 mdt
neighbor MCAST route-reflector-client
neighbor 172.16.100.19 activate

R1#sh bgp ipv4 mdt all | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1
*>i 172.16.100.3/32 172.16.100.3 0 100 0 ?
*>i 172.16.100.4/32 172.16.100.4 0 100 0 ?
*>i 172.16.100.9/32 172.16.100.9 0 100 0 ?
*>i 172.16.100.14/32 172.16.100.14 100 0 i
*>i 172.16.100.18/32 172.16.100.18 100 0 i
*>i 172.16.100.19/32 172.16.100.19 100 0 i
*>i 172.16.100.110/32
172.16.100.110 0 100 0 ?

We can see that R1, the BGP Route Reflector, has formed MDT peerings with all the PE routers.

R5
ip multicast-routing distributed
!
ip pim rp-address 172.16.100.5
!
interface GigabitEthernet1.35
ip pim dr-priority 0
ip pim sparse-mode
!
interface Loopback0
ip pim sparse-mode

R5#ping 224.1.1.1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.10.11.11, 64 ms
Reply to request 0 from 10.18.13.13, 318 ms
Reply to request 0 from 10.4.7.7, 263 ms
Reply to request 0 from 10.4.8.8, 246 ms
Reply to request 0 from 10.14.19.14, 229 ms
Reply to request 0 from 172.16.100.120, 188 ms
Reply to request 0 from 10.12.9.12, 64 ms