Re: Multicast PIM-SM Question

j.a.m.e.s · ‎05-26-2003

I'm relatively new to multicast and we have a problem at the moment involving an application (called 'Isis') which sends a multicast keepalive every 5 minutes.

The disappointing thing about this fault is that it usually happens during the night, and 3am call-outs are not my preferred activity on a Saturday morning ;-)

My first question is, when a leaf router, near a multicast 'publisher' (aka a source) receives it's first multicast packet, does it immedaitely create an s,g state?

The reason I ask is that we often see no s,g state in the leaf router, near the publisher. Could this be because a packet is only sent every 5 minutes?

Secondly, what makes a leaf router near the 'subscriber' (aka muticast receiver) move from an s,g state back to a *,g state?

I realise that there is a threshold during SPT-switchover, but how about SPT -switchback? I have run a script throughout the night which shows that our leaf router, near the subcriber, very occassionaly moves from an s,g state into a *,g state, although I don't anticipate this causing packet loss.

My final question is that imagine there are no receivers on the network whatsoever, but there is still a publisher sending packets every 5 minutes. (This is usually the situtation I wake up to at 3am). Should PIM-register be taking place to the rendez-vous point? Which routers should I see an s,g group in?

Many thanks to anyone who can help me solve this and get some sleep!

All the best,

James.

mtorelli · ‎05-26-2003

In PIM-SM when the first hop router (the one directly connected to a source S) receives the first packet of the multicast stream it will build an (S,G) entry and a parent (*,G) if it does not already exist. If there are no receivers for group G when source S starts sending to the group, the first hop router will still go through the PIM register process. The RP will install both an (S,G) and a (*,G) entry, then send a register stop, but it will not send an (S,G) join for the group. This means that the outgoing interface list (OIL) for the both the (S,G) and the (*,G) entries will be null on this router as well as on the RP. As a result, all multicast packets received from source S to group G will be dropped by this router. Furthermore, as long as no receivers join the group, the (S,G) state will time out and this entire process will repeat every three minutes.

When an (S,G) entry is created as a result of the SPT-Switchover, the J flag is set for that (S,G) entry. When the J flag is set, the Cisco router will check the flow rate periodically and will switch back to the shared tree and prune off the traffic down the SPT.

j.a.m.e.s · ‎05-27-2003

Thanks for the info, this is really helpful!

Can I ask you two more questions on this please?

1. How often does the router check the multicast flow rate for a specific s,g entry in order to decide whether to move back to the shared tree? What are the default thresholds for A) SPT switchover and B)SPT switchback

2. Have you heard of any bugs involving Multicast Multilayer Switching? The reason I ask is that on Saturday morning, I ran "no mls ip multicast" and since then, I haven't been called out. The people running the server say they haven't seen any problems since then. Is there something unusual whihc happens when multicast mls is enabled and a packet is only sent every 5 minutes?

Many thanks,

James.

mtorelli · ‎05-27-2003

James

When joining the SPT the router will check once every second and compare the rate received to the threshold rate. By default the threshold rate is 0Kbps. If the received rate is greater than the threshold rate, then the router will set the J flag in the (*,G) entry. When the next multicast packet is received, the router will build an (S,G) entry, set the J flag on the (S,G) entry and clear the J flag on the (*,G) entry. The router then sends an (S,G) join towards source S. When the J flag is set on the (S,G) entry, the router compares the received rate with the threshold rate once every minute. If the received rate is less than the threshold rate, the router will rejoin the (*,G) by sending a (*,G) join up the shared tree towards the RP. It will also send an (S,G) prune up the SPT towards the source and delete the (S,G) entry.

There are bugs with MMLS, but without knowing exactly what's happening on your switch it would be impossible to say if you're running into one. We would need to know more details about the problem. I suggest that if this problem is reproducible by toggling mmls, you should open up a TAC case so that an engineer can get the details that we need to find the source of the problem.

Mike

j.a.m.e.s · ‎05-30-2003

Hi Mike,

Thanks for the helpful info.

We have followed your advice and opened TAC case E063538.

Can I ask you one more question on SPT-switchback please?

You mentioned above that when the J Flag is set on an (S,G) entry, "the router compares the received rate with the threshold rate once every minute."

We have not changed our thresholds and I understand the default theshold to be 0 bps. If this is the case, how does the router determine whether the rate is 0 bps? Does it divide the number of packets received in the last minute by 60?

Thanks in advance,

James.