Profile 1 with data MDTs

Load basic.profile1.cfg

#IOS-XE
config replace flash:basic.profile1.cfg
Y

#IOS-XR
configure
load bootflash:basic.profile1.cfg
commit replace
y

Configure the core so that customer multicast traffic is only delivered to PEs that have interested receivers. In other words, PEs that have (*, G) or (S, G) state in the C-PIM for that group.

To verify, join a group on C2, and ping this from C1 with size 1400 and timeout 1. This will create a flow that exceeds 1kbps.

Answer

Just like with profile 0, we can use data MDTs to create better efficiency when delivering customer multicast traffic across the core. The ingress PE advertises the group number it will switchover to inside the default MDT. PEs with interested receivers join a P2MP mLDP tree rooted at the ingress PE. The opaque value consists of the VPN ID plus a number that the ingress PE chose to represent this data MDT.

On the PEs, define the data MDT range:

#PE1, PE2
vrf def CUSTOMER
 add ipv4
  mdt data mpls mldp 100
  mdt data threshold 1

#PE3
multicast-routing
 vrf CUSTOMER
  add ipv4
   mdt data mldp 100 threshold 1

Join 239.1.2.3 from both C1 and C3, and ping this group from C2.

PE2 will pick a MDT ID value (likely 1) and advertise this to the PEs. Both PE1 and PE3 will join the data MDT, which is a p2mp tree rooted at PE2. (As we saw on XRv data MDTs with profile 0, XRv will only join MDT data groups, not switchover to them as an ingress PE).

PE2 uses group number 1 for this (S, G) stream:

PE1 joins it:

PE3 joins it as well:

#PE3 show pim vrf CUSTOMER mdt mldp remote

P2 has a p2mp tree rooted at PE2 with VPN ID 100:1 and group number 1. Upstream clients are PE2. Downstream clients are P1 and PE3.