pierky / arouteserver

A tool to automatically build (and test) feature-rich configurations for BGP route servers.
https://arouteserver.readthedocs.org/
GNU General Public License v3.0
284 stars 46 forks source link

BUG - AS-SET filters starting with RS and other characters are not processed #134

Closed mustangthz closed 1 month ago

mustangthz commented 4 months ago

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:

Many objects in RPSL have a name. An is made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names: Thanks
pierky commented 4 months 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.

pierky commented 4 months ago

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:

grizz commented 4 months ago

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.

pierky commented 4 months ago

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).