Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
After editing two or more IPv4 or IPv6 ACLs already applied on an interface, the change does not seem to take place. Sometimes, the affected ACLs appear differently in "show access-list ipv4 " and "show access-list ipv4 hardware ingress location " command. This means, the ACL's definition is out of sync between Control Plane and Data Plane
A few criteria must be met to trigger this issue. (1) Two or more ACLs are edited at the same time. "ACL edit" here means adding/deleting one or more ACEs, within an ACL. The ACL shall have already been applied to at least 1 interface in the system. If the ACL is defined but not used anywhere, this problem will not occur (2) Regular ACL edit will not trigger such problem. If any one of the following conditions is met, then the ACL is NOT a regular ACL, then editing of them will contribute to occurrence of the problem: (a) The ACL is compressed (b) The ACE is previously classic ACE (i.e. contains no object-groups), but after editing, it contains object-groups (c) The ACE previously contains object-group ACE, after editing, it still contains object-group (d) The ACE previously contains object-group, after editing, it no longer contains object-group (e) The ACE is deleted or added, and it contains object-group (f) The ACE is deleted or added, it contains no object-group, but the other, not-changed ACE in the same ACL contains object-group ACE (g) The ACE is deleted or added, it contains no object-group, but the ACL is compressed
There is no reliable workaround when this problem has occurred. Preventative measure is advised. One straightforward measure is that when editing non-regular ACLs (see above section for definition of "non-regular" ACL), edit them one by one. That is, edit one non-regular ACL, then commit, then edit another one. Do NOT edit two or more non-regular ACLs in one commit
The issue is fixed in IOS-XR 5.1.1. The problem is NOT applicable to IOS-XR 4.3.0 and prior releases. The first affected release is IOS-XR 4.3.1. The problem is additionally not-applicable in IOS-XR 5.1.0 because IOS-XR 5.1.0 does not contain Scale ACL feature (with sub-features such as object-groups and ACL compression), even though its version number is subsequent to 4.3.1