On Fri, 27 Feb 2026 at 09:15, James Bensley <lists+nanog@bensley.me> 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