I am attempting to craft a filter that will not accept route advertisements for specific prefixes unless the origin ASN matches. The idea being that the router only accept advertisements for “internal” prefixes if they originate from what is considered an “internal” AS.
I drafted the following prefix-list:
set policy prefix-list deny-int-pfx rule 100 action 'deny'
set policy prefix-list deny-int-pfx rule 100 prefix '10.0.0.0/16'
set policy prefix-list deny-int-pfx rule 100 ge '16'
set policy prefix-list deny-int-pfx rule 110 action 'deny'
set policy prefix-list deny-int-pfx rule 110 prefix '172.16.0.0/16'
set policy prefix-list deny-int-pfx rule 110 ge '16'
And drafted the following as-path-list:
set policy as-path-list internal-as rule 10 action 'permit'
set policy as-path-list internal-as rule 10 regex '^6543[0-9]'
Then started drafting the following route-map:
set policy route-map general-in rule 10 action 'deny'
set policy route-map general-in rule 10 match as-path 'internal-as'
set policy route-map general-in rule 20 action 'permit'
Of course at rule 20 I get stuck. I think between the as-path-list and rule 10 in the route-map this achieves omitting anything that starts with an AS of 6543X. At this point, I want to say "for everything else, apply prefix-list deny-int-pfx but I’m not sure how to do that. Is this where I need to pull in a table?
Yep, this worked! I realized I had the as-path logic backwards too. Here’s the final result:
set policy prefix-list int-pfx description 'Internal prefixes for use with route-map gen-in'
set policy prefix-list int-pfx rule 100 action 'permit'
set policy prefix-list int-pfx rule 100 le '32'
set policy prefix-list int-pfx rule 100 prefix '10.0.0.0/16'
set policy prefix-list int-pfx rule 110 action 'permit'
set policy prefix-list int-pfx rule 110 le '32'
set policy prefix-list int-pfx rule 110 prefix '172.16.0.0/16'
set policy as-path-list int-as description 'AS paths originating from an internal ASN'
set policy as-path-list int-as rule 10 action 'permit'
set policy as-path-list int-as rule 10 regex '6543[0-9]$'
set policy route-map gen-in rule 10 action 'permit'
set policy route-map gen-in rule 10 match as-path 'int-as'
set policy route-map gen-in rule 20 action 'deny'
set policy route-map gen-in rule 20 match ip address prefix-list 'int-pfx'
set policy route-map gen-in rule 30 action 'permit'
Since you look for /16 in your prefix-list, shouldnt the “le” be “ge 16” (greater or equal) to allow for more specific routes within the advertised range meaning these prefixes should be matched?
10.0.0.0 - 10.0.255.255 where the prefix is 16 or higher (17, 18 … 31, 32).
172.16.0.0 - 172.16.255.255 where the prefix is 16 or higher (17, 18 … 31, 32).
When looking for your internal ranges the current check would allow for 165430 or any number in front of “65430-65439” which I assume you dont want to. That is also define the start with ‘^’ like so:
regex ‘^6543[0-9]$’
Above wouldnt allow for appending. To allow for that also add (if I got the regex correct?):
regex ‘^6543[0-9]_6543[0-9]*$’
That is the AS-PATH must start with “65430-65439” and follow by zero or more “65430-65439”. No other ASN (other than “65430-65439”) would be allowed in the AS-PATH.
Since you look for /16 in your prefix-list, shouldnt the “le” be “ge 16” (greater or equal) to allow for more specific routes within the advertised range meaning these prefixes should be matched?
This is actually how I initially structured it. However, I have two VyOS instances running different versions. One is on the 1.4 code train and the other is on the 1.3 code train. FRR on 1.3 requires that ge is smaller than the specified prefix (you get the slightly confusing ge must be greater than prefix length error). I found a “bug report” for this, but as stated in the bug report…it’s not a bug. Since I’m specifying /16’s, specifying ge 16 is actually redundant. Instead, to structure the prefix-list to match any sized prefixes up to a /16 using le 32 is logically more appropriate. To keep the configuration on both as similar as possible, I just switched it to le 32.
When looking for your internal ranges the current check would allow for 165430 or any number in front of “65430-65439” which I assume you dont want to. That is also define the start with ‘^’ like so:
In my OP the as-path regex was wrong. The path is going to start with the neighbor you learned the prefix from, then any intermediate hops (if any), then the originating AS (with some exceptions, as always… as-override for example). Since what I want to evaluate is the origin AS, I need to look at the last AS in the path. I think that '6543[0-9]$ achieves this as the $ signifies to match the end of the path, which is where the origin AS (again, with some exceptions) will reside. I believe if I add a ^ what will happen is it’ll look for a single AS path which I don’t want. Since I don’t have a wildcard before the 6, I think it should keep the match within the bounds I’m expecting, but I could be missing something. As far as I can tell, it is working, so I’m going to roll with it until I find otherwise
glad you got it working