"ip pim spt-threshold infinity" having no effect

[cbeswick]

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 ?

[Peter Paluch]

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