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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
