Cisco Bug: CSCsy96348 - Bundle_ea acts on ACTIVE notifications instead of ATTACH notifications
May 08, 2018
- Cisco Carrier Routing System
Known Affected Releases
1) Symptom: FQM Errors and ASIC resets Conditions: FQM errors (FQM overflow) indicate a problem (internal to the Ingressq) with regards to managing buffers. There are multiple ways a FQM overflow error can occur. One possible trigger is bundle interface flap: A bundle interface is assigned a vport which has one HP queue (along with one or more LP queues). When the interface goes down, the bundle_mgr programs the vport bandwidth to zero and then deletes the HP queue (basically disassociates the HP queue from the vport). But, if the hp queue had some packets already enqueued into it, the moment we set the vport bw to 0, the hp queue would stop draining. Then when a request comes in, to delete the hp queue, ingressq, seeing that the queue is non-empty, would leave the queue as, it is hoping that it would drain (wrong assumption by ingressq). When the bundle interfaces comes back up, the reverse operation happens. A HP queue is allocated to the vport and the vport bandwidth is again set to non-zero. Now when ingressq allocates a new hp queue, the old non-empty hp queue is orphaned (so to speak) and causes an error in ingressq's queue scheduling algorithm. It ends up reading a queue element which exceeds the bounds of valid queue elements and hits the overflow error. QoS handles a member addition/deletion based on a certain event (iir_attach/detach) while the bundle uidb programming takes place based on another event iir_active/inactive. The fix ensures that both actions take place on iir_attach/detach.
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