Feature Request: RPSL-VIA

[MHammett]

Job Snijders pointed me to AMS-IX’s use of RPSL-VIA (which he drafted) as a way to solve an issue I was having. I have been looking at using arouteserver to automate my prefix filters for my IXes.

Does arouteserver support the use of RPSL-VIA? I didn’t see it explicitly mentioned.

https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers

http://datatracker.ietf.org/doc/draft-ietf-grow-rpsl-via/?include_text=1

Per AMS-IX's documentation, it looks like if implemented, a network's IRR entry could block prefixes on a specific IX. That would be mighty convenient.

[pierky]

Hello @MHammett, thanks for your message.

What's the issue you are dealing with?

Currently ARouteServer does not support rpsl-via yet, even if it's on my todo list.

Outbound announcements control (what a client wants to be announced to other clients) like the one achievable using rpsl-via can be implemented using the BGP communities offered by the tool, that allow to build a fine grained distribution matrix based on destination peer AS too (both using standard and extended/large communities for 32-bit ASN support).

Inbound announcements control can't be achieved with the options currently offered by ARouteServer; a client must implement local filters to accept or reject routes sent by the route server. This is the point where, IMHO, this feature could be more useful.

Back to the AMS-IX example, a very quick and dirty research I made showed that 81 over 675 route server participants have at least an "import-via/export-via AS6777" entry in their aut-num object, that is 12% (please take these numbers with a grain of salt).

It's definitely a feature that's worth to be added to ARouteServer. It seems I must give a higher priority to it, even if I guess it will take some time before having it ready.

Trying to speed this up with the GitHub "help wanted" label too!

[MHammett]

Was that already on your ToDo list and I just missed it?

The inbound control is what I was after.

The short version: Network A and Network B can't reach an agreement about who is going to filter who's routes. Some is platform ability, some is the lack of desire for one-off configs. I did a manual tweak, which IXes should never do, but did do so that everyone else benefits.

Something like "import-via: AS6777 from AS-ANY EXCEPT AS666 accept ANY" where network A simply tells the route servers on the IX via RPSL that it doesn't want to receive network B's prefixes would be the most "community accepted" way I could come up with.

How long it takes to get ready isn't overly important to me as long as it's understood that it's wanted and why.

[pierky]

Yes of course, well understood and definitely a wanted feature.

In the meanwhile I can suggest you a way to implement the "tweak that IXes should never do" using ARouteServer, just in case you would like to consider it for your environment.

Site-specific custom configuration files allow to inject custom snippets of code into the BGP daemon, in some "strategic" points of the generated config. This allow to both keep the automation offered by the tool and also to handle local "exceptions".

For example a BIRD hook can be used to tweak the announcement control toward peers by implementing the hook_pre_announce_to_client function (that should be defined in an external file which is finally included by ARouteServer into the generated config):

arouteserver/examples/bird_hooks/bird4.conf

Lines 751 to 752 in b00d92c

	if !hook_pre_announce_to_client(3333, 192.0.2.11, "AS3333_1") then
	reject "hook_pre_announce_to_client returned false - NOT ANNOUNCING ", net, " TO AS3333_1";

@MHammett do you think this could work for you, while waiting for the more elegant rpsl-via implementation?

[job]

This ticket should be closed for inactivity