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.


On the main peering LAN

  • RS1 v4:
  • RS1 v6: 2001:7F8:B:100:1D1:A5D1:6004:254
  • RS2 v4:
  • RS2 v6: 2001:7F8:B:100:1D1:A5D1:6004:253
  • ASN: 61968

On the peering LAN of MIX-IT Palermo

  • RS v4:
  • RS v6: 2001:7f8:101:7::253
  • ASN: 61968

On the peering LAN of MIX-IT Bologna

  • RS v4:
  • 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, even if tagged with the previous community


rt:61968: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 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 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

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:

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.