On Mon, 27 Jan 2020 at 23:30, Chris Jones <[email protected]> wrote: > > Aside from this behavior, XE in the enterprise access layer is full of bugs > > related to ACLs. We've recently begun a practice of maintaining two > > distinct versions of every ACL so we can swap them on interfaces after > > modifying the unused one. Modifying a used one in-place results in some > > degree of data plane failure on affected interfaces, i.e. they stop passing > > all or some subset of traffic. Even on "fixed" code, the problem persists, > > though less frequently. > > Do you happen to have a bug reference for this? We’ve been seeing this > behaviour intermittently on some csr 1ks and haven’t had the time/energy to > debate it with TAC yet.
Somewhat related, IOS (all flavours) do in-place ACL unless you do object ACLs. In-place ACL update behaviour essentially doubles your ACL scale, if you are running exactly 1 large ACL but it's unpredictable what happens when ACL is changed. Many other devices, such as Juniper program new copy and then switch the ACL pointer to new copy and delete old, making it predictable but halving the ACL size if you are running exactly 1 large ACL as you need double space during reprogramming. Consider old ACL 100 deny host 1.1.1.1 200 deny host 2.2.2.2 300 permit any Consider new ACL 100 deny host 1.1.1.1 200 deny host 2.2.2.2 300 deny host 3.3.3.3 400 permit any this change would cause interruption of traffic if implied default is deny (IOS-XR) because the ACL solver has to remove the '300 permit deny' to fit the new rules and during this delta all packets are hitting implied deny. The implicit default thus optimizes for security rather than hitlessness. If instead of 300 permit any, you had used 100000 permit any, during reprogramming you might have permitted something you should not have (not in this case), but you would not have dropped anything you should not, which may be much more desirable behaviour for example iACL updates, you'd rather let packets pass for few microseconds than drop what should not be dropped. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
