Cisco Bug: CSCuq81832 - l2mcast process crashes during Vlan entry cleanup
Last Modified
Sep 09, 2019
Products (8)
- Cisco Nexus 7000 Series Switches
- Cisco Nexus 7000 10-Slot Switch
- Cisco Nexus 7000 4-Slot Switch
- Cisco Nexus 7700 6-Slot Switch
- Cisco Nexus 7700 18-Slot Switch
- Cisco Nexus 7000 18-Slot Switch
- Cisco Nexus 7000 9-Slot Switch
- Cisco Nexus 7700 10-Slot Switch
Known Affected Releases
6.2(8)
Description (partial)
Symptom: Modules may experience l2mcast process crashes: 2-SERVICE_CRASHED: Service "l2mcast" (PID 1220) hasn't caught signal 11 (core will be saved). A process crash may occur multiple times over multiple modules Conditions: The issue was first seen with v2 joins (*,G) and v3 joins (S,G) and has OMF disabled on the fabric path vlan 182. We see a bunch of leaves coming in for the (*,G)s on vlan 182. Since there are v3 joins as well , some of the (*,G)s have corresponding (S,G) s. Ideally , if a (*,G) delete comes in we wouldn't be deleting the (*,G) from our software db if we have an (S,G) entry for the same group and that (S,G) delete is yet to come . Only when all the (S,G) leaves comes in and number of Source specific entries for that Group becomes zero , we cleanup the (*,G) entry node in our software. Once all the Groups in a Vlan are cleaned up , we will go ahead and clean up the Vlan entry in our sw db. To be able to do so in a correct manner we keep count of number of G entries per Vlan per ftag and number of S entries per G etc. { note : S is short for Source , and G is multicast group address}
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)
- Status
- Severity
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases