A route server is a device collecting BGP routes from everybody who peers with it and redistributing those routes to all other peers on the route server. Thus by peering with a route server you can avoid having to track and configure individual sessions with each peer at SwissIX. Furthermore, you'll get a lot of routes and traffic from day one.
SwissIX runs two OpenBSD/OpenBGPd-based route servers on the peering LAN. All SwissIX participants are strongly encouraged to peer with both route servers. We operate two independent route servers to allow for uninterrupted traffic flow even during maintenance.
Our route servers work transparently, meaning they don't insert their ASN into the AS path of the redistributed routes. At least on some Cisco IOS versions you have to allow this explicitly.
To peer with our route servers just set up BGP sessions with them as you would for any other peering. Please peer with both of them from all your connections. If you use IPv6, please don't forget to also setup IPv6 sessions. The route servers are both using ASN 42476
SwissIX Route Servers provide route security by filtering announcements. Please find below a list of filters and features available on our route servers.
The configuration of the Route Servers is rebuilt at 02:00h (LT/CE(S)T) and 16:00h (LT/CE(S)T) daily. If you announce new prefixes or change your IRRDB objects please take a possible delay into account.
The SwissIX Route Server accepts the following communities:
|Do not announce to any client||0:42476||42476:0:0|
|Announce to peer, even if tagged with the previous community||42476:peer_as||42476:1:peer_as|
|Do not announce to peer||0:peer_as||42476:0:peer_as|
|Prepend the announcing ASN once to peer||65511:peer_as||42476:101:peer_as|
|Prepend the announcing ASN twice to peer||65512:peer_as||42476:102:peer_as|
|Prepend the announcing ASN thrice to peer||65513:peer_as||42476:103:peer_as|
|Prepend the announcing ASN once to any||65501:42476||42476:101:0|
|Prepend the announcing ASN twice to any||65502:42476||42476:102:0|
|Prepend the announcing ASN thrice to any||65502:42476||42476:103:0|
|Add NO_EXPORT to peer||65281:peer_as||42476:65281_peer_as|
|Add NO_ADVERTISE to peer||65282:peer_as||42476:65282_peer_as|
Prefixes that are rejected by the filers will be tagged with the community 65520 and the below listed ID to document the reject reason. You can use the Looking Glass (rs1.swissix.ch / rs2.swissix.ch) to lookup these communities and understand why some of your prefixes have been rejected.
|0||Special meaning: the route must be treated as rejected. *|
|1||Invalid AS_PATH length|
|2||Prefix is bogon|
|3||Prefix is in global blacklist|
|6||Invalid left-most ASN|
|7||Invalid ASN in AS_PATH|
|8||Transit-free ASN in AS_PATH|
|9||Origin ASN not in IRRDB AS-SETs|
|10||IPv6 prefix not in global unicast space|
|11||Prefix is in client blacklist|
|12||Prefix not in IRRDB AS-SETs|
|13||Invalid prefix length|
|14||RPKI INVALID route|
We recommend you set a max-prefix limit on your side of the route server BGP session. At the moment we suggest to allow 100'000 IPv4 prefixes and 40'000 IPv6 prefixes.
On our side we have also implemented a max-prefix limits on each peer. We use PeeringDB to calculate this max-prefix limit.
Here are some cookbook examples for configuring your Route Server sessions. (Parts in italics need to be adapted by you. Bear in mind, these are just basic examples.)
First, an example for Cisco:
And here a Juniper example: