Profile 11 w/ Receiver-only Sites
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 GRE tunneling over the core.
Use PIM-SSM in the core with no RP.
Use BGP ipv4/mvpn for P-PIM signaling (allowing PEs to learn of each other).
PEs are not allowed to form C-PIM adjacencies. Instead use BGP to replace these functions.
Configure the sites behind PE2 and PE3 as receiver-only sites. PE2 should not generate a BGP auto-discovery type 1 route. PE3 should also not create PIM-SSM (S, G) state rooted at itself. PE3 should not include the MVPN route import extcommunity in its unicast VPNv4 routes.
Answer
Explanation
Configuring sites that will never have multicast senders or RPs as receiver-only helps scale state in the P-PIM underlay. On IOS-XE, we configure this under the vrf defintion:
Notice that PE2 does not source a type 1 AD route:
The reason for this is that no P-PIM (S, G) distribution tree needs to be rooted at PE2, because PE2 will never send traffic to the other PEs. PE2 only needs to join P-PIM (S, G) trees rooted at PEs for which there are senders.
On IOS-XR, this is configured as follows:
IOS-XR still originates the type 1 AD route, but it omits the PMSI tunnel attribute. Notice that it is present on PE1’s route but missing on PE3’s route:
The result is that the only state in the P-PIM underlay is for PE1’s (S, G), in which both PE2 and PE3 are receivers. This can be confirmed on a core router such as P2:
Additionally, there is no need for the receiver-only PEs to add the VRF route import extcommunity to the unicast VPNv4 routes. On IOS-XE, there does not appear to be a way to disable this, but on IOS-XR we can control this using the following command:
Notice that PE1’s unicast VPNv4 route contains the VRF route import extcommunity, but PE3’s VPNv4 route does not:
Let’s join a group on C2 and C3 and ping from C1:
Both PE2 and PE3 generate type 6 (*, 239.100.1.1) routes destined for the RP, located behind PE1. PE2 and PE3 include PE1’s VRF route import value, learned from the VPNv4 route for 10.1.1.1. PE1 is still propagating BSR messages on the default MDT, so all sites still know the RP.
Next, the source starts sending, so PE1 generates a type 5 SA route. PE2 and PE3 join the (S, G) via a type 7 route. Notice that this all works without PE2 and PE3 having a P-PIM (S, G) rooted at themselves, as only PE1 will distribute multicast traffic.
Exploring MRIB State
At the receiver site for PE2, we see the flag g on the (*, G) entry, indicating a BGP C-Mroute was sent. On the (S, G) entry, we see a g and Q flag, meaning the router received a BGP S-A route for that (S, G).
On the receiver site for PE3, we see that the Joins are performed using BGP, not C-PIM. The (S, G) entry has the SAR flag indicating a BGP S-A was received.
At the sender site, PE1, we see the opposite flags from PE2. We see a G on the (*, G) entry, which was created in response to a BGP C-Mroute. We see a q flag also on the (S, G), meaning that a BGP S-A route was sent.
What happens if the RP is behind a receiver-only site?
Let’s move the source to PE2 and turn PE1 into a receiver-only site. We’ll also statically define the RP on all routers to ensure that we don’t rely on PE1 propagating BSR messages.
The P-PIM state is now just one (S, G) rooted at PE2, which PE1 and PE3 have joined:
C1 and C3 have joined (*, 239.100.1.1). However, PE3 has not originated a type 6 route for this ASM entry. Perhaps because PE3 sees that PE1 is not originating any type 1 route. I believe that PE3 needs to use the RD from PE1’s type 1 AD route as the RD on the type 6 route, so this would explain why PE3 fails to source the type 6 route. It likely also needs the source AS from this type 1 route to use for the type 6 route as well. On the RR, all we see is a type 6 route that PE2 originated for AutoRP:
On PE3, we see Join(never) on the (*, G) entry instead of Join(BGP):
C2 begins sending, and CE2 registers this with the RP via unicast. The RP only has its local receiver, C1 in the OIL, so traffic is not distributed to C3. However, PE3 learns of the source via the source-active type 5 route, and sends a type 7 (S, G) route. P3 receives the traffic through this.
But what if the RP had no (*, G) state at all? Let’s join a different group on only C3. Will C3 receive this traffic if the RP does not “pull in” the traffic after receiving the register?
There is no (*, G) BGP state for this. C2 starts sending, and CE2 registers this with the RP via unicast. The RP has no state at all, so it sends a register stop. The traffic never passes through PE2, so PE2 cannot source a type 5 SA route. C3 never receives the traffic.
So the key to this is that the sites with the RP(s) must not be set as receiver-only. Without removing this on PE1, the RP is disconnected from interested receivers in other sites, and ASM cannot work.
PE3 now sends the type 6 route intended for PE1. Then the RP joins the (S, G) rooted at C2 using a type 7 route. This causes a type 5 route to be sourced from PE2. Note that all this BGP state happened before sourcing any more traffic from C2, so this must have been prompted from cached register state on CE1 for (C2, 239.100.1.3).
Traffic is now working:
Last updated
