Route server

A feature at SOL-IX is the ability for members to exchange routes via our route servers.

Routes are transparently exchanged via the route servers, meaning that BGP attributes (as-path, next-hop and MED) are not modified when advertised to peers. SOL-IX filters bogus networks from all incoming advertisements, and use maximum prefix limit on a peer-to-peer basis. More about filtering.


Peering LANRoute Server 1Route Server 2
MTU 1500
IPv6: 2001:7f8:21:9::254
IPv6: 2001:7f8:21:9::253
MTU 4470
IPv6: 2001:7f8:21:10::254
IPv6: 2001:7f8:21:10::253

All route servers use AS25172.


SOL-IX offers the opportunity to filter route server announcements, and control to whom (on an AS basis) your routes should be advertised. For this, we accept communities from you – and filter accordingly.

ActionStandard CommunitiesLarge Communities
1do not advertise route to a certain peer0:<peer-as>25172:0:<peer-as>
2advertise route to a certain peer25172:<peer-as>25172:1:<peer-as>
3do not advertise route to any peers0:2517225172:0:0
4advertise route to all peers25172:2517225172:1:0

Default action is advertise routes to all peers, make sure to attach communities according to your policy.


SOL-IX applies the following filters on all RS sessions.

  • RPKI validation.
    • RPKI VALID: Accept the route.
    • RPKI INVALID: Filter the route.
    • RPKI UNKNOWN: Fall back to IRRDB filtering.
  • Filter IPv4 nets smaller than /24.
  • Filter IPv6 nets smaller than /50.
  • Filter martian / bogon ranges.
  • Filter known transit networks.
  • Sanity check to ensure the AS path has at least one ASN and no more than 64.
  • Sanity check to ensure the peer ASN is the same as first ASN in the prefix’s AS path.
  • Prevent next-hop hijacking, where a member advertises a route but puts the next hop as another member’s router rather than their own.
  • Ensure that the origin AS is in the set of ASNs from member’s AS-SET.