[c-nsp] ASR920: egress ACL on BDIs

Gert Doering gert at greenie.muc.de
Mon Dec 30 05:57:54 EST 2019


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

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at greenie.muc.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20191230/6d565747/attachment.sig>


More information about the cisco-nsp mailing list