-
Notifications
You must be signed in to change notification settings - Fork 0
Setting up a route server
(This entire document is still under construction)
This document is meant to give IXPs information in how to set up their own route server in their peering LAN. We do not claim to be the ultimate source of knowledge on route servers or anything else for that matter, if there is anything in here which you do not agree with then do not hesitate to start a discussion!
TL;DR - An eBGP route reflector
A route server's primary goal is to make peering for your peers easier.
As you probably well know a BGP peering, unlike with other routing protocols, needs to be set up explicitly on both sides. In an IXP environment where new peers join the peering LAN frequently it can become a lot of work for a peer to add new peers one by one.
A route server helps the peers by offering to:
- peer with everyone
- collect everyone's routes
- keep the advertised NEXT_HOP attributes unaltered
- advertise everyone's routes to everyone (depending on policies which might have been set by the peers)
It is important to understand that the route server will NEVER be in the actual path of the end-to-end traffic flowing over your IXP. This is because the route server does NOT update the NEXT_HOP attribute to its own IP address in the routes it receives.
(picture of how the peering relation is and how the traffic flows)
By having a central route server which collects all routes the peers no longer need to update their peerings each time a new peer enters the peering LAN. They simply peer with the route server once and wait until the other peers also peer with the route server.
Usually a route server is offered by the IXP operator as a service, meaning that peers are not required to peer with the route server and that private peerings between individual peers is still allowed and encouraged.
Of course this is just a basic description of what a route server is, if you want to read more we recommend the following 2 RFCs:
TL;DR - Hot backup
As also said in RFC7948 section 4.4 a route server setup should never consist out of only 1 route server. This simply means that you will need to set up at least a second route servers in your peering LAN.
These two route servers should ideally interact exactly the same to the other peers (except for using a different IP address). They should peer with the same peers and thus should be sending out the same routes. It is therefore important to ask your peers to please peer with BOTH of your route servers (or none if they don't want to) but never with only 1 route server.
Although the route servers should be almost the same in their peer interactions, it is definitely a valid idea to run different BGP daemons on the route servers, for example running BIRD on RS1 and GoBGP on RS2. This might be a good idea to prevent being dependent on 1 specific daemon, but if that is worth the extra management overhead is entirely up to you.
TL;DR - Should not matter to much
Traditionally a Route Server was a physical device in the peering network, but there is no reason why you cannot make this a Virtual Machine. As long as its in the Peering LAN it should be fine.
Again this is something you should decide for yourself.
ARouteServer is a Python tool that automatically builds feature-rich configurations for BIRD and OpenBGPD route servers. Among the other features it offers options to enable prefixes and origin ASNs validation based on an extended data-set made up by IRR records, RPKI ROAs and Origin AS from ARIN Whois, integration with PeeringDB to fetch networks' info (AS-SETs, max-prefix limits) and a rich set of control and informational BGP communities.
ATOW, BIRD (1.6.3) and OpenBGPD (OpenBSD 6.0, 6.1 and 6.2) are supported, with almost feature parity between them; this can help to run a pair of route server which are based on different BGP daemons with no additional management overhead.
A comprehensive list of features and options can be found within the docs website: https://arouteserver.readthedocs.io/
The installation process is quite straightforward and documented at https://arouteserver.readthedocs.io/en/latest/INSTALLATION.html
Once installed, the arouteserver configure command can be used to quickly initialize a working policy definition file (the general.yml file - see it on GitHub) based on best practices and suggestions.
The list of clients, which contains ASNs, IP addresses, AS-SETs and all the client-specific options, can be manually configured by editing the clients.yml file or automatically fetched from Euro-IX member list JSON file, like those exported by IXP-Manager; indeed, when this tool is also used, ARouteServer can be easily configured to fetch the list of clients and all the other options from it.
Once the policy definition file has been configured and the list of clients filled out, the tool can be executed to build BIRD/OpenBGPD configuration files:
arouteserver bird --ip-ver 4 -o /etc/bird/bird4.conf
Some examples of configuration files built using ARouteServer can be found on GitHub.
Python templating
Special thanks to the following people for their help in writing/reviewing this document: