Closed mustangthz closed 1 month ago
If we continue reading on the RFC, we see:
Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names.
That is not an as set, but a route set.
The difference is that route sets don't include ASes, but just prefixes. So they cannot be used to build as-path filters.
Worth noting that ARouteServer includes functionalities to configure client-specific "white list" for prefixes, AS paths and routes, that can be used to work around RPSL settings:
Thanks, is there a reason to not use a specified RS to build the prefix white list? Trying to get customers to change their configuration can be quite frustrating, so at least those using a RS are giving a list of prefixes they're routing.
The "white lists" are kind of "break the glass" tools to allow operators to force the acceptance of routes on the basis of their prefix, origin AS or both. There is not much effort around how they are populated, it's left to the operators to craft them and write them down into the clients.yml file.
Expanding a route-set object would allow the tool to just populate the white_list_pref
of a client, the one that is based only on the prefix. It seems quite a bit of extra work and code to maintain to ship a relatively small feature, with a very limited scope (like the automation of a subpart of a corner case exception).
ARouteServer 2024-04-18 15:13:02,786 ERROR Error parsing 'as_sets' at 'clients.cfg.filtering.irrdb' level - Invalid AS-SET: RS-TBS-AS5662, invalid name RS-TBS-AS5662
This AS-SET is compliant with RFC2280.
You are filtering out valid AS-SETs:
if not re.match(r"^(?:AS[\d]+|AS-[A-Z0-9_-]*[A-Z0-9])$", name):
See the relevant part of the RFC: