Profile 3 with S-PMSI
Load basic.profile3.cfg
Configure the core so that customer multicast traffic is only delivered to PEs that have interested receivers. In other words, only PEs that have (*, G) or (S, G) state in the C-PIM for that group.
To verify, join group 239.20.20.20 on C2, and ping this from C1 with size 1400 and timeout 1. This will create a flow that exceeds 1kbps.
Answer
Even though we are now using BGP ipv4/mvpn with profile 3, the data MDT configuration is the same as with profile 0 in which data MDTs are advertised in the data plane (the default MDT).
Verification
Test by creating a multicast flow on either C1 or C2. Remember that XRv (PE3) won’t switchover to the data MDT or S-PMSI properly, but it will join it.
After a few seconds, PE1 will advertise the S-PMSI using a group defined in the data MDT range (232.1.100.0/24).
Above is a route type 3 which is a S-PMSI AD route. The NLRI contains the customer source and customer group, as well as the PE’s loopback. Here are the details of the route:
Notice the tunnel ID uses a group ID of 232.1.100.0
We can also see this by considering the S-PMSI as a data MDT. We can use the same show commands as with profile 0, where the data MDT was advertised in the default MDT. Now it is advertised in BGP as a S-PMSI.
The expiration is stopped on PE2, I believe because the route is learned via BGP. With profile 0 this expiration actually has a timer. But because we are advertising using BGP in profile 3, once the source stops sending, the ingress PE can just withdraw the BGP route to tear down the tree immediately.
Last updated
