Excessive PIM Register messages

[cbeswick]

Hi,

I am seeing excessive "PIM(0): Send v2 Register to x.x.x.x for x.x.x.x, group x.x.x.x" messages on a first hop layer 3 switch upstream from the multicast source (it is also the DR)

I have read that the DR uses the PIM register process to inform the RP about every new (S,G) state, and encapsulates all data packets within this register message and unicasts them to the RP.

The RP can then choose to continue receiving these PIM register messages, or switch to the shortest path tree, after which a source based tree will be created between the DR and the last hop which connects to the receiver.

I have checked over the backbone and it appears that the shortest path tree has been joined yet I am still receiving up to 80+ PIM register messages on the DR every second.

The multicast source is a CCTV codec streaming a video of about 700Kbps in bandwidth.

Does this look normal, or should the PIM Register messages reduce once the SPT has been joined ?

[Marcel Zehnder]

Hi

This looks to me like normal behavior - as soon as your DR sees traffic to the group x.x.x.x it sends a pim register message to the RP. Because there are no routers willing to join that group, the RP sends a register-stop back to the DR. BUT: Your source continues to send traffic, so the DR sends a register message to the RP...then the whole process starts again.

HTH

Marcel

[cbeswick]

Hi Marcel,

The thing is there are routers joining the group upstream from the RP, to which receivers are connected and are successfully receiving the CCTV video stream. I haven't seen a single "register-stop" message sent from the RP to the DR. Everything from the RP down to the receiver looks fine, I am just a little concerned that this is a new CCTV system being deployed and I am testing just one video stream from one codec.

If I am getting up to 80 PIM Register messages per second for just one stream, imagine how many I will get when hundreds more codecs get added to the network, each capable of sending 8 streams to the LAN....

I am going to do a packet capture from the Codec today to determine if there is anything strange happening from the Codec end which may be causing these excessive register messages.

[cbeswick]

Hi,

Looking at the specific mroute in question on the DR, I get the following output:

ci_t2_s2108_dist_sw1#sh ip mroute 236.16.62.130

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 236.16.62.130), 00:03:06/stopped, RP 172.16.255.252, flags: SJCF

Incoming interface: Vlan232, RPF nbr 172.16.232.250, Partial-SC

Outgoing interface list:

Vlan62, Forward/Sparse-Dense, 00:03:06/00:02:43, H

(172.16.62.130, 236.16.62.130), 00:03:06/00:03:22, flags: FT

Incoming interface: Vlan62, RPF nbr 0.0.0.0, RPF-MFD

Outgoing interface list:

Vlan232, Forward/Sparse-Dense, 00:03:06/00:03:20, H

On the (S,G) entry both the "register" and "SPT-bit" flags have been set, and remain in place for the duration of the flow. So it looks like the flow is staying in register even though the SPT has been set ??