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 LAN||Route Server 1||Route Server 2|
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.
|Action||Standard Communities||Large Communities|
|1||do not advertise route to a certain peer||0:<peer-as>||25172:0:<peer-as>|
|2||advertise route to a certain peer||25172:<peer-as>||25172:1:<peer-as>|
|3||do not advertise route to any peers||0:25172||25172:0:0|
|4||advertise route to all peers||25172:25172||25172: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.