04-20-2011 05:15 AM - edited 03-06-2019 04:42 PM
Hi,
We have a "many-to-many" multicast CCTV deployment which generates a high number of pim register messages. In order to reduce the load on the DR and RP I configured "ip pim spt-threshold infinity" to prevent the stream from joining the SPT and remain on the shared tree.
However I have noticed that the stream still appears to be joining the SPT on the DR and RP.
This is the output from the DR closest to the receiver:
(*, 239.192.111.16), 00:01:14/stopped, RP 172.16.255.252, flags: SCF
Incoming interface: Vlan224, RPF nbr 172.16.224.250, RPF-MFD
Outgoing interface list:
Vlan68, Forward/Sparse, 00:01:14/00:02:44, H
(172.16.68.4, 239.192.111.16), 00:01:12/00:03:29, flags: FT
Incoming interface: Vlan68, RPF nbr 0.0.0.0, Registering, Partial-SC
Outgoing interface list:
Vlan224, Forward/Sparse, 00:01:12/00:03:29, H, A
This is the output from the DR closest to the source:
(*, 239.192.111.16), 01:57:40/stopped, RP 172.16.255.252, flags: SCF
Incoming interface: Vlan222, RPF nbr 172.16.222.250, RPF-MFD
Outgoing interface list:
Vlan111, Forward/Sparse, 00:49:04/00:02:22, H
(172.16.111.16, 239.192.111.16), 00:49:04/00:03:29, flags: FT
Incoming interface: Vlan111, RPF nbr 0.0.0.0, Registering, Partial-SC
Outgoing interface list:
Vlan222, Forward/Sparse, 00:49:04/00:03:29, H, A
This is the output from the RP:
(*, 239.192.111.16), 01:09:15/stopped, RP 172.16.255.252, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan224, Forward/Sparse, 00:00:39/00:02:50
Vlan222, Forward/Sparse, 00:00:39/00:02:50
(172.16.68.4, 239.192.111.16), 00:00:37/00:02:58, flags:
Incoming interface: Vlan224, RPF nbr 172.16.224.251
Outgoing interface list:
Vlan222, Forward/Sparse, 00:00:37/00:02:22
(172.16.111.16, 239.192.111.16), 00:00:39/00:02:59, flags:
Incoming interface: Vlan222, RPF nbr 172.16.222.251
Outgoing interface list:
Vlan224, Forward/Sparse, 00:00:39/00:02:20
You can see that on both the DR's the stream is stuck in "registering". We are using Cat 6500 with Sup 720s on release 12.2(33)SXH6.
Does this look like a bug ?
04-27-2011 01:54 PM
Hello,
You have mentioned that your multicast application is of the many-to-many type, so the receivers are obviously senders as well. The two multicast routing table entries shown on your DR routers refer to different sources, presumably to the sources on a directly connected network (considering the fact that the RPF field is indicated as 0.0.0.0 in both cases). Between a source and a RP, a source-based tree is always built. Seeing the (S,G) entries for locally-connected sources in the Registering state should not be considered as a bug per se. However, if the entries are indeed stuck - for the same (S,G) combination - in the Registering state for a prolonged time then I would personally suspect some problems with the PIM Join/Register-Stop messaging that should be sent from RP towards the source to create the source tree branch and stop the Register process.
Can we focus on the time necessary for a (S,G) entry for a locally connected source to lose the Registering status please?
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide