By default, all sources are allowed to register at the RP (Rendezvous Point) when using PIM sparse mode. When a new source sends traffic to a multicast group address, the PIM DR (Designated Router) on the segment connected to the source will forward a PIM register message to the RP.
This PIM register message contains the original multicast packet from the source, including the source’s IP address and the destination multicast group address. We can configure our RP to filter certain sources. If we do this, the RP will send a PIM register-stop message to the PIM DR so that it will not build the SPT toward the source.
Let’s take a look at an example topology:
Above, we have two routers, R1 and R2. We will configure R1 as a rendezvous point, and R2 will be our source. Let’s configure the basics first:
R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 192.168.12.1
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip pim sparse-modeR2(config)#ip multicast-routing
R2(config)#ip pim rp-address 192.168.12.1
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip pim sparse-mode Just a simple PIM sparse mode setup where R1 is the RP. By default, all sources and all multicast groups are allowed to register at the RP.
Let’s send some traffic to a multicast group address from R2 to see what R1 thinks of it:
R1#debug ip pim
PIM debugging is onFirst, we will enable a debug on R1. Now let’s send some traffic from R2:
R2#ping 239.1.1.1 repeat 9999
Type escape sequence to abort.
Sending 9999, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
...This is what you will see on R1:
R1#
PIM(0): Received v2 Register on FastEthernet0/0 from 192.168.12.2It receives a PIM register message from 192.168.12.2. Nobody is listening to this multicast stream, but you will find it in the multicast routing table:
Hi Rene,
I setup up lab for 4 routers to allow one router and block other router, it’s not working, but for two routers like your lab its working.
//cdn-forum.networklessons.com/uploads/default/original/1X/8209d66f9bd998792d6418964fce5d026e04f317.JPG
in this LAB I want to filter R1 as source to R4 which is configured group address 239.9.9…9, but its allowing all sources.
Configuration
R2
... Continue reading in our forumHi Rene,
I setup same LAB in VIRL, the previous LAB was GNS3, right now its showing this debug message
Aug 22 05:13:25.023: %PIM-4-INVALID_SRC_REG: Received Register from 2.2.2.2 for (12.12.12.1, 239.9.9.9), not willing to be RPfrom R2 (Which is the RP), but even though I’m receiing INVALID-Source address its still allowing to ping the group address and even setting up in multicast routing.
... Continue reading in our forumHi Rene
I changed topology this way its working without Issue
//cdn-forum.networklessons.com/uploads/default/original/1X/09d978ab3bbaf9866ef7eca7d687833f8b517f44.png
Why its accepting R1 as source and not accepting Source Router as Source ?
the difference between the Source router and R1 is that the Source router isn’t running any PIM mode, I just enabled ip multicast-routing. (and sure I modified the Access-list)
is this means that if the DR it self generates multicast traffic as source, the Pim Accept Register will not effect it?.
Regards
Jama
Hi Jama,
It’s probably because the pings are sent from the G1/0 interface on the R1 router. When R2 doesn’t accept 12.12.12.1 as a source, it sends a prune message to R1 so that it doesn’t forward this multicast traffic anymore. R1 however, is sourcing the traffic from its G1/0 interface so it’s not “multicast routed”.
If you source the multicast traffic from a loopback interface on R1 that isn’t permitted on the access-list of R2, you’ll see that R1 no longer forwards it on its G1/0 interface because of the pruning.
Rene