[c-nsp] ASR920: egress ACL on BDIs

Saku Ytti saku at ytti.fi
Tue Jan 28 02:21:13 EST 2020

On Mon, 27 Jan 2020 at 23:30, Chris Jones <chrisj at aprole.com> 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
200 deny host
300 permit any

Consider new ACL

100 deny host
200 deny host
300 deny host
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.


More information about the cisco-nsp mailing list