Route Server
With the aim of simplifying the management of peering agreements and facilitating the setup of new members, in 2010 MIX has made available a route-server service on its peering LANs.
This mechanism, through a single BGP session, allows to configure and manage multiple BGP sessions with the other participants. This approach does not exclude the traditional setup of bilateral agreements: on the contrary, it is a useful integration.
Technical info
Every member of the route-server platform has its own list of prefixes that are considered valid for the BGP announcements. This list is obtained by querying the main IRRDB databases, using the Autonomous System Number of the member or, if necessary, a given as-set.
To this purpose, it is essential that every member keeps its records up-to-date: in particular, for every prefix that will be announced on the route-server, a corresponding route (or route6) object must exist on such databases, with the member ASN listed as the origin. Only those prefixes will be considered valid for that specific ASN. Once the BGP session is established, IP traffic will be exchanged transparently between pairs of neighbors on the peering LAN: the route-server IP address will never show up as a next-hop address, nor the route-server ASN will appear in the as-path. It is also necessary to configure no bgp enforce-first-as.
Finally, 32-bit ASNs are managed natively.
Addressing
On the main peering LAN
- RS1 v4: 217.29.66.254
- RS1 v6: 2001:7F8:B:100:1D1:A5D1:6004:254
- RS2 v4: 217.29.66.253
- RS2 v6: 2001:7F8:B:100:1D1:A5D1:6004:253
- ASN: 61968
On the peering LAN of MIX-IT Palermo
- RS v4: 185.1.186.253
- RS v6: 2001:7f8:101:7::253
- ASN: 61968
On the peering LAN of MIX-IT Bologna
- RS v4: 185.1.231.253
- RS v6: 2001:7f8:101:13::253
- ASN: 61968
Sanity checks
Every prefix announced on route-servers are subject to some preliminary checks:
- Prefix lengths allowed are /8 – /24 for IPv4 and /12 – /48 for IPv6
- The first ASN in the as-path must be the one of the peering ASN
- Routes that are well-known bogons or martians will be rejected
- Routes with one or more private or invalid ASNs in their as-path will be rejected
- Routes with one or more “transit free” ASNs in their as-path will be rejected
BGP Communities
All the route-servers handle well-known communities transparently, and allow to filter what is being announced by sending communities according to the following scheme
| Function | Standard | Extended | Large |
|---|---|---|---|
| Do not announce to any client | 0:61968 | rt:0:61968 | 61968:0:0 |
| Announce to peer_as, even if tagged with the previous community |
61968:peer_as |
rt:61968:peer_as |
61968:1:peer_as |
| Do not announce to peer_as | 0:peer_as | rt:0:peer_as | 61968:0:peer_as |
| Prepend the announcing ASN once to peer_as | 65511:peer_as | rt:65511:peer_as | 61968:101:peer_as |
| Prepend the announcing ASN twice to peer_as | 65512:peer_as | rt:65512:peer_as | 61968:102:peer_as |
| Prepend the announcing ASN thrice to peer_as | 65513:peer_as | rt:65513:peer_as | 61968:103:peer_as |
| Prepend the announcing ASN once to any | 65501:61968 | r:65501:61968 | 61968:101:0 |
| Prepend the announcing ASN twice to any | 65502:61968 | rt:65502:61968 | 61968:102:0 |
| Prepend the announcing ASN thrice to any | 65503:61968 | rt:65503:61968 | 61968:103:0 |
| Add NO_EXPORT to peer_as | 65281:peer_as | rt:65281:peer_as | 61968:65281:peer_as |
| Add NO_ADVERTISE to peer_as | 65282:peer_as | rt:65282:peer_as | 61968:65282:peer_as |
If no communities are sent, the default behavior is announcing to all the route-server participants.
RPKI support
On the route-servers origin validation via RPKI is enabled.
All INVALID prefixes are rejected.
Graceful BGP session shutdown
Route-servers honor the GRACEFUL_SHUTDOWN community (65535:0): routes tagged with this community have their LOCAL_PREF attribute lowered to 0.
“Never via route-servers” attribute
Routes with an AS_PATH containing one or more “never via route-servers” networks’ ASNs are rejected. The status of “never via route-servers” flag is obtained from PeeringDB.
Max prefix number
Route-server participants that explicitly set a max-prefix limit on the peering sessions are encouraged to set these limits according to what is published on the following PeeringDB page: https://peeringdb.com/net/13105
General info
Peering sessions on route-servers are configured as regular BGP sessions and allow, since day one, to exchange traffic with all the other members connected to the same platform. Route-servers only compute routing information, while the actual traffic exchange is clearly performed by the peering switches.