To simplify the management of peering agreements and facilitate the onboarding of new participants, MIX provides a route server service on its peering LANs.
This mechanism allows participants to configure and manage multiple BGP sessions with other peers using a single BGP session.
This approach does not replace traditional bilateral peering agreements but rather serves as a natural complement to them.
Technical Features
Each participant connected to the route server platform is associated with a list of prefixes considered valid for BGP announcements. This list is generated by querying major IRRDB databases, using the participant’s Autonomous System (AS) number or, if necessary, a specific AS-set provided by the participant.
Prefix Validity Requirements
It is essential for each participant to keep their information updated in the IRRDB databases. Specifically, for each prefix announced on MIX, there must be a corresponding route (or route6) object with the participant’s AS number as the origin. Only prefixes meeting this condition will be included in the valid prefix list.
BGP Session Management
Once the BGP session is established, IP traffic will be exchanged directly between peering LAN neighbors.
- The route server’s IP address will not be used as the next-hop.
- The route server’s AS number will not appear in the AS-path.
To ensure this configuration, the “no bgp enforce-first-as” command must be enabled.
32-bit Autonomous Systems are natively supported.
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 check
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
Community BGP
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.