PIM-SM without Receiver IGMP Joins
Load multicast.init.cfg
Receivers R2 and R4 cannot run IGMP. You’ve been asked to forward multicast traffic for (*, 239.1.1.1) towards these receivers, despite their inability to signal interest in this group. Without using the command ip igmp join-group on any router, configure the LHRs to forward (*, 239.1.1.1) traffic towards these receivers.
Configure R9 as the PIM-SM RP using BSR.
Answer
Explanation
The IGMP static-group command works the opposite as the join-group command. The igmp join-group command configures the router to act as a client and send an IGMP Report for the given group. The static-group command configures the router to act as if it received an IGMP Report on that interface. You are statically creating an IGMP group mapping for the given interface, without dynamically receiving an IGMP report from a client. This can be useful in situations for troubleshooting or if the clients do not have the ability to run IGMP.
On IOS-XE, we can see that the group has no expiration and the last reporter is 0.0.0.0. Additionally, there is an SG flag on the entry seen using the detail keyword.
On IOS-XR, the reporter is itself. It also has no expiration.
The LHRs join the (*, G) RPT the same as if this IGMP Report was received from a receiver. On R9 we see two interfaces in the OIL for the (*, G) entry:
If we source multicast traffic to this group address, we won’t get any ICMP replies, but we can verify that traffic is indeed being distributed to the LHRs and the LHRs are forwarding this out the interface to R2 and R4.
On R5, we see 1 packets forwarded in “hardware” for the (*, G) entry, and 13 forwarded for the (S, G) entry. Gi2.525 is in the OIL, so this confirms that the traffic was delivered to R2.
We see similar output on XR3:
IPv6 MLD static-group
This same idea works for MLD using the same static-group command.
The (*, G) RP tree is created:
Traffic sent towards this group is forwarded out the interfaces where the mld static-group command was configured.
Last updated
