Loading...
Loading...
An ACL applied on interface is using object-group. The object-group is changed. The change could be add new member, delete existing member. The change was accepted by the system (no error). However, traffic filtering does not behave correctly. It is as if the accepted change has never occurred.
The ACL has undergone multiple changes. There are multiple edits of object-group that leads to one single most important trigger of this problem - the edit has previously failed. In this customer's case, the object-group edit failed because the resulting ACL requires more TCAM that the system could afford. After the error, another object-group edit is accepted, and the problem occurs. It must be noted that without any prior obj-group edit failure, this issue cannot occur.
There's no reliable workaround. As stated in ''Conditions'' section, a prior object-group edit failure is the primary trigger. There is not foolproof way to guarantee obj-group edit will always succeed. The most common error is TCAM resource exhausted, since a change in object-group members, depending on how the object-group is used in ACL, could result in the ACL to grow so significantly it no longer fits the TCAM.
An object-group edit failure causes obj-mgr, processes handling object-group change, to send roll-back request to all object-group users. The rollback is necessary because multiple processes may be using object-group, while the edit fails in one process, the same change may not fail in others. Thus rollback is an indication for all processes to change what they have done, in order to restore system back to original state (prior to the edit). There is a bug in the rollback processing logic, that the rollback may not be handled. A fail-to-handle rollback means stale info will be stuck in obj-group user processes (such as pfilter-ea, netio). When next obj-group edit arrives, they conflict with the stale info left over by previous failed roll-back, and the current edit would fail, too. Albeit they failed at a location where the error wasn't properly propagated to obj-mgr, thereby causing the system to believe the current edit is a success. In reality, the current one also fails, but the change is not reflected in the hardware. PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 1.5/1.2: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C&version=2.0 No CVE ID has been assigned to this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.