Profile 12 w/ PE Anycast RP

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

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

#IOS-XR
configure
load bootflash:basic.startup.config.with.cpim.and.bgp.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 only P2MP trees.

• You cannot use PIM in the core.

• Use BGP for the overlay.

• Configure every PE as an Anycast RP, and advertise this via BSR. Remove the BSR config on CE1.

• Ensure that (*, G) state is confined to each local site.

See answer below (scroll down).

Answer

#CE1
no ip pim bsr-candidate GigabitEthernet2 0
no ip pim rp-candidate GigabitEthernet2

#PE1, PE2
int lo100
 vrf forwarding CUSTOMER
 ip address 1.1.1.100 255.255.255.255
 ip pim sparse-mode
!
router bgp 100
 add ipv4 vrf CUSTOMER
  network 1.1.1.100 mask 255.255.255.255
!
ip pim vrf CUSTOMER bsr-candidate lo100
ip pim vrf CUSTOMER rp-candidate lo100
!
vrf def CUSTOMER
 add ipv4
  mdt default mpls mldp p2mp
  mdt auto-discovery mldp
  mdt overlay use-bgp spt-only

#PE3
int lo100
 vrf CUSTOMER
 ip add 1.1.1.100/32
!
route-policy USE_MLDP
  set core-tree mldp-default
end-policy
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf CUSTOMER add ipv4
 int lo100 en
 mdt so lo0
 mdt default mldp p2mp
 bgp auto-discovery mldp
  anycast-rp
!
router pim vrf CUSTOMER add ipv4
 bsr candidate-bsr 1.1.1.100
 bsr candidate-rp 1.1.1.100
 mdt c-multicast-routing bgp
  suppress-shared-tree-join
 rpf topology route-policy USE_MLDP
!
router bgp 100 vrf CUSTOMER add ipv4 unicast
 network 1.1.1.100/32

Explanation

In the previous lab, we saw that if we move the RP to a PE, we no longer need (*, G) state in the core. This gets rid of type 6 BGP routes and (*, G) entries on the RP for remote receivers. The PE, acting as RP, will source a type 5 S-A route upon learning of any new source via the PIM Register process, even if the RP does not have any (*, G) state.

We can take this a step further by implementing Anycast RP on all PEs. The benefit of this is that PIM Registers are always local to the site. The FHR simply sends a register to its closest PE, and that PE will source the S-A message. Note that we do not use MSDP as in normal IPv4 PIM Anycast RP. Instead, the BGP type 5 routes replace MSDP for announcing active sources.

On C2, join the group (*, 239.2.2.2):

#C2
int Gi0/1
 ip igmp join-group 239.2.2.2

Only PE2 will have (*, G) state for this group, as the RP.

PE1 and PE3 are not aware of interested receivers for this group. This is basic Anycast RP behavior.

Additionally, PE2 is not injecting a (*, G) type 6 route for two reasons: 1. it itself is the RP, and 2. the spt-only keyword is used on the command mdt overlay use-bgp spt-only.

C3 starts sending to this group. CE3 Registers this with the RP, PE3. PE3 sources a type 5 S-A route which announces that C3 is sending to group 239.2.2.2. PE2 finds that it has interested receivers, so it joins the (S, G) via a BGP type 7 message. PE3 adds its Lmdt interface to the OIL for this (S, G), and C2 begins receiving the traffic.

PE3 sends a BGP S-A route, indicated by the SAS flag in the PIM topology:

PE2 receives the type 5 route, and generates its own type 7 route:

On PE2, we see the entry has the g (BGP C-Mroute sent) and Q (BGP S-A received) flags:

I personally find this setup more elegant than using a customer RP. With the customer RP, you have the more complex SPT switchover process, because the RP joins a (S, G) tree, only to then get immediately pruned off of it. With this PE Anycast RP setup, only the PE that has an interested receiver ends up joining the (S, G) tree. There is also no complicated (*, G) signaling in the core either.

Update - 2/4/24

I found that IOS-XR requires the anycast-rp keyword in order to join a (S, G) that it learns about via a type 5 route:

multicast-routing
 vrf CUSTOMER
  address-family ipv4
   bgp auto-discovery mldp
    anycast-rp

I discovered a problem when a host behind the XR PE is a sender. The XR PE will source the type 5 route, but it has a strange RT, which the XE PEs are not importing.

If I remove the anycast-rp keyword, PE3 uses the VRF RT again: