Profile 13 w/ Configuration Knobs

Load basic.startup.config.with.cpim.cfg

#IOS-XE
config replace flash:basic.startup.config.with.cpim.cfg
Y

#IOS-XR
configure
load bootflash:basic.startup.config.with.cpim.cfg
commit replace
y

The basic IP addresses, L3VPN, and C-PIM between the PEs and CEs is pre-configured.

• Configure multicast VPN using mLDP in the core using a MP2MP default tree.

• You cannot use PIM in the core.

• CE1 is predefined as the RP in the C-PIM via BSR.

• PEs cannot form C-PIM adjacencies between each other. Instead use BGP for the overlay.

Set the following configuration knobs:

• Use S-PMSI P2MP tunnels for C-(S, G) flows, and immediately switchover to them

• A C-S ingress PE should wait 60 seconds before pruning (S, G) state after the last type 7 route is removed

• The RP’s ingress PE should wait 45 seconds before sending an RPT-bit (S, G) prune to the RP after receiving a type 5 route

See answer below (scroll down).

Answer

#PE1
router bgp 100
 add ipv4 mvpn
  neighbor 10.10.10.10 activate
!
vrf def CUSTOMER
 vpn id 100:1
 add ipv4
  mdt auto-discovery mldp
  mdt default mpls mldp 20.20.20.20
  mdt data mpls mldp 100 immediate-switch
  mdt overlay use-bgp
  mdt overlay bgp shared-tree-prune-delay 45
  mdt overlay bgp source-tree-prune-delay 60

#PE2
router bgp 100
 add ipv4 mvpn
  neighbor 10.10.10.10 activate
!
vrf def CUSTOMER
 vpn id 100:1
 add ipv4
  mdt auto-discovery mldp
  mdt default mpls mldp 20.20.20.20
  mdt data mpls mldp 100 immediate-switch
  mdt overlay use-bgp
  mdt overlay bgp shared-tree-prune-delay 45
  mdt overlay bgp source-tree-prune-delay 60

#P1
mpls ldp mldp add ipv4
!
router bgp 100
 add ipv4 mvpn
 !
 neighbor-group IBGP
  add ipv4 mvpn
   route-reflector-client

#P2
mpls ldp mldp add ipv4

#PE3
mpls ldp mldp add ipv4
!
router bgp 100
 mvpn
 add ipv4 mvpn
 neighbor 10.10.10.10
  add ipv4 mvpn
 vrf CUSTOMER
  add ipv4 mvpn
!
vrf CUSTOMER
 vpn id 100:1
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf CUSTOMER add ipv4
 mdt so lo0
 mdt default mldp ipv4 20.20.20.20
 mdt data mldp 100 immediate-switch
 bgp auto-discovery mldp
!
route-policy USE_MLDP
 set core-tree mldp-default
end-policy
!
router pim vrf CUSTOMER add ipv4
 rpf topology route-policy USE_MLDP
 mdt c-multicast-routing bgp
  shared-tree-prune-delay 45
  source-tree-prune-delay 60

Explanation

This lab tests your understanding of a few configuration knobs. By default, the S-PMSI switchover waits a few seconds to allow PEs to join the data MDT. To configure the ingress PE to immediately switchover to the data MDT we can use the following keyword:

#IOS-XE
vrf def CUSTOMER
 add ipv4
  mdt data mpls mldp 100 immediate-switch

#IOS-XR
multicast-routing vrf CUSTOMER add ipv4
 mdt data mldp 100 immediate-switch

We can test this out by joining an SSM group on C3 and pinging this from C2. This removes the PIM register and switchover process with PIM-SM.

#PE2
ip pim vrf CUSTOMER ssm default

#CE2
ip pim ssm default

#CE3
ip pim ssm default
!
int Gi3
 ip igmp ver 3

#C3
int gi0/1
 ip igmp ver 3
 ip igmp join-group 232.3.3.3 source 10.1.2.10

We see no loss of traffic with this. This appears to be because PE2 signals the S-PMSI route simply upon the (S, G) state from PIM-SSM. So when traffic begins, PE2 immediately switches to the P2MP mLDP tree, which PE3 has already joined.

For PIM-SM this process results in several lost packets. This is because the S-PMSI route cannot be pre-signaled ahead of time. The PIM Register process takes place and SPT switchover takes place. C2 doesn’t advertise the type 3 route for several seconds. During this time, packets are flowing on the default MDT. However, PE3, due to the immediate-switch keyword on its own data MDT defintion, appears to reject these packets for arriving on the default MDT instead of a data MDT. I verified that if I remove the data mdt config on PE3, then there is no packet loss.

#C3
int gi0/1
 ip igmp join-group 239.0.0.3

Prune Delays

Next we look at prune delays. By default, the PE connected to the RP will send a RPT-bit (S, G) prune towards the RP upon learning a type 5 SA route. We can delay this using the following command:

#IOS-XE
vrf def CUSTOMER
 add ipv4
  mdt overlay bgp shared-tree-prune-delay 45

#IOS-XR
router pim vrf CUSTOMER add ipv4
 mdt c-multicast-routing bgp
  shared-tree-prune-delay 45

However, this doesn’t appear to work properly on IOS-XE. When a source goes active, PE1 still immediately sends a prune towards the RP. Perhaps this is because the RPT-bit (S, G) prune is happening as a result of (S, G) state being built on the PE, because the RP itself joins a (S, G) tree.

We can also set the source-tree prune delay. This controls how long a PE will wait before sending a (S, G) prune after a type 7 route is withdrawn.

#IOS-XE
vrf def CUSTOMER
 add ipv4
  mdt overlay bgp source-tree-prune-delay 60

#IOS-XR
router pim vrf CUSTOMER add ipv4
 mdt c-multicast-routing bgp
  source-tree-prune-delay 60

We can test this by leaving an SSM group on C3 that is rooted at C2. PE2 should wait 60 seconds before sending a (S, G) Prune to CE2. However, I see that PE2 sends the prune immediately, so this also does not appear to be functional on CSR1000v.

If we do it the other way around, with C2 joining a SSM group rooted at C3, we see that IOS-XR also sends the Prune immediately to CE3.