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, of course, do not exclude the traditional bilateral agreement: on the contrary, it is a useful integration.
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 RIPE database, 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 the database, 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: 18.104.22.168
- RS1 v6: 2001:7F8:B:100:1D1:A5D1:6004:254
- RS2 v4: 22.214.171.124
- RS2 v6: 2001:7F8:B:100:1D1:A5D1:6004:253
- ASN: 61968
- On the backup peering LAN
- RS v4: 126.96.36.199
- RS v6: 2001:7F8:B:101:1D1:A5D1:6004:254
- ASN: 65004
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
- Do not announce to a specific ASN:
- Announce only to a group of ASNs:
- Do not announce to any ASN:
where <rs-asn> is 61968 for the main peering LAN or 65004 for the backup peering LAN.
If no communities are sent, the defaul behavior is announcing to all the route-server participants.
Maximum number of announced prefixes
For those members who have a max-prefix limit configured on the peering sessions with the route-servers, these are the recommended minimun thresholds:
- 60k prefixes for IPv4 peering
- 20k prefixes for IPv6 peering
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 are configured for 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.