Profile 13 w/ PE RP
Load basic.startup.config.with.cpim.and.bgp.cfg
BGP ipv4/mvpn and mLDP is already enabled in the core.
Using profile 13 (MP2MP tree with BGP overlay and BGP AD), configure the core to only use SPT trees. A PE should never signal a (*, G) type 6 route. Configure PE1 as the RP using BSR.
Answer
Explanation
Using the spt-only keyword on IOS-XE and suppress-shared-tree-join on IOS-XR causes the PE to never translate a (*, G) entry into a BGP type 6 route.
This can be used to help scale the mVPN. In order for this to work, one of the PEs must be the RP. This is because the RP will receive PIM Registers for active sources and must generate a type 5 SA route to allow ingress PEs to learn of new sources in order to build (S, G).
First, verify that the CEs learn of the new RP, PE1. A common mistake is to forget to redistribute the loopback into the BGP VRF on PE1. If you fail to do this, the BSR messages will be denied on all routers due to failing the RPF check. (Also note, for some reason the last time I did this, I had to wr mem and reload PE1 for the BSR propagation to work).
Join an ASM group from C3:
PE3 installs this as MRIB state, but a type 6 BGP route is not generated.
The RP, PE1, therefore has no (*, G) state. This helps for scalability, as there is no (*, G) signalling in the core. (*, G) states are confined to the receiver-site only.
But how does PE3 learn of an active source then? Let’s configure C2 as the source.
As C2 starts sending, CE2 unicasts a PIM Register to PE1. Even though PE1 has no receivers for this group, it still sources a type 5 BGP S-A message. This is analagous to MSDP SAs.
PE3 learns of the source via this type 5 route, and issues a type 7 route to join a (S, G) rooted at the source. We’ve replaced the PIM Register and SPT switchover process with BGP routes.
Unforunately we don’t see any replies. PE2 is not actually forwarding the traffic onto the default MDT, despite having the Lspvif in the OIL. This appears to be a bug. (Note 5/18/24: This appears to be working this time. The Lspvif is 2 instead of 0.)
However, if we make PE3 the ingress PE, this works correctly:
What happens if the RP is in a customer site? (Not on a PE)
If the RP is in a customer site, traffic will not work if receivers are located in a remote site. The RP will never have any (*, G) state, and will send Register Stops to the FHR of the sender. The remote site never learns of the active source.
However, if a receiver is present in the same site as the RP, then it would work. The RP in that case does have (*, G) state, so it joins a (S, G) rooted at the sender. This causes a type 5 route to be generated, which the remote site uses to learn of the active source and join the (S, G) tree.
Last updated
