Profile 13 w/ Configuration Knobs
Load basic.startup.config.with.cpim.cfg
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
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:
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.
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.
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:
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.
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.
Last updated
