Cisco Bug: CSCvv38797 - 6800 Switch running IGMPV2 deletes the snooping entry for any port when IGMPV3 report was received.
Aug 27, 2020
- Cisco Catalyst 6000 Series Switches
Known Affected Releases
Symptom: Very specific use case, refer to the steps indicated in "condition" section. This problem won't be seen in most business cases. Cat6800 acting as IGMP V2 querier , deletes a port with v3 report from IGMP list for a given VLAN/port, after downgrading it's querier version from v3 to v2. This results in momentarily traffic loss (for specific multicast group in given vlan) of about 1-10 sec Conditions: Here is what is needed to recreate the issue- Sender---------Vlan1503----Cat6K---te4/1---Vlan3108-------3850/4500------reciever-1,2 Configure 6K as IGMPv2 querier (PIM enabled). Have a port of 6K connected to 3850/4500, behind which we should have one or more real receivers or simulated receivers. Make sure there is at least one receiver active which is sending v2 reports in reply to query packets. That will make sure Cat6K lists te4/1 as membership report port for given group/Vlan. Now send a v3 proxy query through any other port of 6K (in vlan3108), either through IXIA or by hooking in a real device. This will make Cat6K upgrade the querier version to 3 for given vlan3108 and it will pass the query to all ports in Vlan3108 including te4/1 Make one of the receiver respond to that query with v3 report, we are doing it in lab through IXIA but in reality any v2/v3 capable recover would do same. That will make Cat6K updating igmp table indicating v3 report from te4/1. After Cat6K’s regular querier interval (60sec) , when it attempts to send a GQ again, it realizes this is actually configured for V2, so it downgrades querier version from 3 to 2. This time, it deletes the entry for te4/1 since a v3 report was received there. Note, if there were other ports there where only v2 report arrived, that port is not removed from IGMP. Cat6K will not populate 4/1 back in IGMP, unless it receives further v2 report in respond to it’s v2 GQ, resulting in 1-10 sec of traffic loss during this transition. During this scenario udp loss and packet loss occurred.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases