Thursday, December 21, 2017

Assistance with IGMP Snooping operation on ASR9K

Hey all. First time poster to this subreddit, so apologize if I do something out of line.

Need a bit of assistance. Working a TAC Case with Cisco involving an issue with IGMP snooping. The Cisco engineer (who is a CCIE, and seems pretty knowledgeable) and I are in disagreement with the operation of IGMP Snooping. I wanted to verify that what is occurring is not intended operation.

Here's a quick drawup of the toplogy, although some inconsequential details are changed: http://ift.tt/2Bxa8Mf

Issue: A test Set-Top Box sends a leave-group message upstream. The upstream switch receives it, and continues to forward it upstream towards the ASR9000 switch. The problem is that there is another device, on another interface of the same switch, joined to the same group. I was of the understanding that IGMP Snooping would recognize that another interface has receiver(s) for the group, and would thus not forward the IGMP Leave-Group upstream.

So, to reference the drawing. Both STBs are joined to group 225.1.1.1, and are correctly receiving the stream. The source for this multicast group is not pictured, but is transported via PIM where is hands off Layer2 at the ASR9000 Router (pictured on the far right). We leave the group (flip the channel) on STB 192.168.1.10, and a leave group is sent upstream. The ASR9000 switch (pictured left) receives the leave, and prunes the interface Gi1. At no point does it prune interface Gi2, which still has an active receiver (confirmed via show commands). Regardless, the ASR9000 switch sends a leave-group message upstream, at which point the ASR9000 Router prunes the stream completely on the LAG, thus killing the stream for the STB that was still joined on the ASR9000 switch interface. The stream eventually comes back after the ASR9000 router sends a General Query.

So it seems to me that there are 2 problems here... One is that the ASR9000 switch is sending a leave-group message upstream when it shouldn't, and the other is that the ASR9000 router is not correctly performing the last-member-query, or that it is but is not receiving a reply.

My main concern is with the IGMP Leave being sent when it shouldn't, as the ASR9000 Router is on legacy software, and is being deprecated very soon.

Talking with the Cisco engineer, he believes this is intended operation. After I asked for clarification, he reached out to 2 colleagues who indicated the same. So, I'm starting to get of the mind that I'm not processing the flow here correctly, but wanted a 3rd party's take.

I looked in the ASR9000 documentation for snooping, and found the following line, which indirectly seems to back me up:

"If the leave message was from the only remaining port, IGMP snooping removes the group entry and generates an IGMP leave to the multicast routers."

With the above quote, I would think the reverse is true as well? i.e. If the leave message was received on a port that was NOT the last remaining one, IGMP snooping would NOT generate a leave to the multicast routers.

After even more digging, I found the following from Beau Williamson's 'Developing IP Multicast Networks Volume 1'. (the last sentence is the most significant)

"If another IGMP Report is received from a host connected to port 2 (where a last-member-query was just sent out of on an IGMP Snooping switch) then the CPU quietly discards the original Leave Group message from Host 1 (on port 2). If, on the other hand, no IGMP Report is received on this port, then the CPU deletes the port from the CAM table entry. Because other nonrouter ports are still in the CAM table entry, no (leave) message is sent to the router"

The IGMP Snooping RFC didn't seem to give a lot of direction on this specific case, but I could have just misread it.

This problem is consistent, and reproduce-able.

I can included additional info if needed. Thanks!



No comments:

Post a Comment