Profile 0 with data MDTs
Load basic.profile0.cfg
Profile0 is already pre-configured. 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.
The P-PIM should use groups in range 232.1.100.0/24 for this optimization.
To verify, join 239.2.2.2 from C2, and ping this from C1 with size 1400 and timeout 1. This will create a flow that exceeds 1kbps and is only delivered to C2.
Answer
Data MDTs are used to optimize traffic in the provider core’s P-PIM underlay. By default, all customer traffic will be encapsulated using the default MDT group address, and all participating PEs will receive the traffic. This happens even if no receivers for the particular multicast stream exist at any CEs connecting to a given PE.
To optimize this, each customer traffic flow can use a unique data MDT group. When a PE sees a new multicast stream, it begins forwarding out the tunnel interface using the default group, but when the traffic rate exceeds the defined threshold, the PE advertises to all PEs the new data group it is about to switchover to. If a PE does not have any interested receivers, it doesn’t join the group. Once the ingress PE switches the traffic to the data group, only PEs with interested receivers will now receive the traffic, saving some bandwidth in the provider core.
Configuration
On IOS-XR, the default threshold is 1 kbps
The data group range does not need to match on all PEs. It is locally significant to each PE, because the PE will advertise the group it is about to switchover to, to all other PEs. Note that if more customer (S, G) streams exist than groups available in the MDT data range, the groups are simply re-used.
On XRv the data MDT switchover does not appear to actually work. It seems to join a data MDT as an egress PE but not switchover to one as an ingress PE. Instead we can test with IOS-XE.
On C2, join 239.2.2.2.
Ping this from C1
Verify that PE1 (ingress PE) picked a data MDT out of the configured group range:
PE1 sends a Data MDT Join which is just a basic UDP packet that announces the customer (S, G) and the data MDT group. This lets other routers which have (S, G) know to join the P-PIM (PE1, data-MDT) SSM group to continue receiving this traffic. This Data MDT Join is sent on the default MDT.
Three seconds after sending the data MDT Join to all PEs on the default MDT, PE1 will switch the traffic over to the data MDT. We can verify this is the case by checking the MFIB. The entry shows that traffic is forwarded out tunnel0 with a group address of 232.1.100.0. The (*, G) entry will still be forwarded on the default MDT (232.1.1.100).
Verify that PE2 joined the data MDT. An entry is shown under show ip pim vrf CUSTOMER mdt received if the PE actually has matching (S, G) state. If the router does not join the data MDT, the MDT will not be listed in this output.
On P2, we see (S, G) state in the underlay P-PIM for this new data MDT group. Only the interface towards PE2 is in the OIL, not the interface towards PE3.
However, if we join this group (239.1.2.3) from C3, PE3 will join this (S, G) data MDT tree as well.
This happens because PE3 is caching the data MDT advertisements. Once it has a PIM Join for this Customer-multicast group, it then joins itself to the data MDT.
Traffic is now encapsulated in GRE with an outer destination of the data MDT group (232.1.100.0) instead of the default MDT group (232.1.1.100):
Last updated
