Re: How long AS-PATH policies have you used

On Fri, 27 Feb 2026 at 09:15, James Bensley <[email protected]> wrote:

> As I'm sure you know, $ matches "ends with". Each number before that between a vertical pipe is an "OR" and matches an entire ASN. So we're matching an AS path that end's with AS1 or ends with AS2 or ends with AS3, etc. This doesn't also match; ends with AS11 or ends with AS111 etc.

I was being unclear, but now I notice, it doesn't actually matter. And
I think your answer is 'yes, EOS does have a traditional regex, where
atom is a character, not ASN'. But in this case, both will work. In
Junos '.' represents single ASN, in traditional regexp '.' represents
single character (or byte in worst case). This difference makes
writing AS_PATH filters in Junos a lot easier in complex cases, but is
definitely not a show stopper.

> You mentioned in a previous email about problems committing such large configs. For us, prefix filters and AS path filters are files on the router's disk. So in the device's config, it's just one line of config which references the file on the disk, the prefix filters and AS path filters aren't part of the running config. This massively reduces the config size.

That's very cute. But I think I can just get rid of prefix-lists and
lose 0 security posture, just as long as the ASN origin scale check is
there. I already have a prefix-list over RTR, as I'm sure most others
do too, so it seems unnecessary to send it again via another protocol.

> >90% of our "running config" then comes from the BGP policy ("RCF" in EOS terminology). RCF can also be files on disk. For us RCF is not in files on disk today, still in "running config". This is something that needs fixing; we have 175k lines of RCF on some edge routers. We've worked with Arista to get big functional changes into EOS (RCF now supports functions, and takes arguments like AS numbers, communities, etc., to avoid repeating code). This wasn't present when we started, hence the giant policies. We'll work on replacing this with functions, and then after that, see if we still need to separate RCF from running config out to files on disk. But so far, committing such large configs works fine and the plan is to address this before it becomes "not fine".

We've had +1M line configs and they do work, but getting there has
been a lot of TAC work during the years, and I'd prefer to be behind
the market than ahead of it here.


-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/MSCTQJHBULW5JIWJ2QILKFGF6WHLEO2V/