ROUTE SERVER

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 backup peering LAN
    • RS v4: 217.29.68.254
    • RS v6: 2001:7F8:B:101:1D1:A5D1:6004:254
    • ASN: 65004

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 peer 0:61968 rt:0:61968 61968:0:0
Announce to peer, even if tagged with the previous community 61968:peer_as rt:61968:peer_as 61968:1:peer_as
Do not announce to peer 0:peer_as rt:0:peer_as 61968:0:peer_as
Prepend the announcing ASN once to peer 65511:peer_as rt:65511:peer_as 61968:101:peer_as
Prepend the announcing ASN twice to peer 65512:peer_as rt:65512:peer_as 61968:102:peer_as
Prepend the announcing ASN thrice to peer 65513:peer_as rt:65513:peer_as 61968:103:peer_as
Prepend the announcing ASN once to any 65501:61968 rt: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 65281:peer_as rt:65281:peer_as 61968:65281:peer_as
Add NO_ADVERTISE to peer 65282:peer_as rt:65282:peer_as 61968:65282:peer_as

On the secondary LAN the scheme is identical, but you need to use 65004 instead of 61968.
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

With the service is offered by means of two route-servers on the main peering LAN, and one route-server on the backup peering LAN. All the members configured on the main peering LAN will hence be asked to configure two peering sessions, in order to take advantage of the redundancy in case of an issue or maintenance. All the servers use BIRD as their routing daemon and ARouteServer as the configuration tool, and are enabled to support both IPv4 and IPv6 peering.
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.