[c-nsp] ASR920: egress ACL on BDIs

[Tassos Chatzithomaoglou]

Hi,

We have been using small (<300 ACEs) egress ACLs under BDIs without any apparent issues until now.

Maybe have a look at the following outputs:

show platform hardware pp active tcam utilization acl detail 0
show platform hardware pp active tcam utilization egress-acl detail 0

Also check the limitations of your SDM template (i.e. https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/sdm/16-11-1/b-sys-sdm-xe-16-11-1-asr-920.html)

--
Tassos

Gert Doering wrote on 30/12/19 12:57:
> Hi,
>
> quick question to the group - ACLs on BDIs on ASR920s, is this something
> known as something you want to stay away from?
>
> I'm trying to get rid of one of our remaining 6500/Sup720s - most VLANs
> got moved to Aristas, but a few of them have egress ACLs on the SVI/BDI
> (which does not really work well with the default Arista TCAM carving,
> only 1000 entries...) - so I decided "make good use of the ASR920 on
> that site, which isn't really doing much" and moved the three (3!) BDIs
> over.
>
> Bäm.
>
> *Some* packets that are supposed to be permitted by very simple IPv4
> ACLs are just not arriving.  Like, TCP SYNs that should be matched
> by a "permit ip host $source host $dest" rule, right at the top of 
> the ACL in question.  Or ping, which is permitted in all our ACLs
> with a "permit icmp any any" rule.
>
> Removing and re-adding the ACLs (and checking with a sniffer port) has
> confirmed that it's indeed the egress ACLs, not routing or anything else
> which might eat packets.
>
> Interesting enough, the pattern shifts - so when you change something,
> a non-working ACL entry "A" starts working, but something in ACL B
> starts failing.  Nothing interesting in the logs, ever.
>
> This is an ASR920-12CZ with "Cisco IOS XE Software, Version 16.06.05a".
>
> I have a TAC case open, which has proceeded nicely to "I will have a 
> look at your logs, but first I go on vacation".
>
>
>
> I'm not looking for debugging advise right now, more for experience from
> the field - like "yes, we've done egress ACLs with 16.06, and it just
> does not work!" or "there is a hidden switch to make the ACL compiler
> work correctly if you have <foo>" or maybe even "there is <this> hidden
> command to force re-programming of ACLs, it is needed because <that>"...
>
>
> This box does IPv4, IPv6 routing (BGP, EIGRP, OSPFv3) and EoMPLS/VPLS
> things (LDP), on a fairly small scale (~250 IPv4 routes, ~900 IPv6 routes,
> ~8 bridge-domains, 2 VPLS groups and 2 EoMPLS circuits).  So this should
> be well within the limits of the architecture...
>
> (I'm tempted to move these VLANs to an old 7301 - it's the backup uplinks
> anyway, so falling down to ~500 Mbit/s in case the primary router fails
> would be acceptable.  But it irks me that I have this new and shiny box
> which is not behaving...)
>
> gert
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/