Route Server guides

Route servers information

1-IX EU operates a Route Servers system (RS for short) to facilitate the exchange of BGP announcements between peers at 1-IX EU IXP. 

Each peer needs only to set up a BGP connection to the route server in order to receive the BGP announcements of all other peers with a BGP connection to the route server.

 

BGP announcement filtering

At 1-IX EU, the route servers filter based on AS-path as well as IP prefixes. The BGP announcements that a route server receives from a peer are checked against the AS-SET the peer has provided.

How and what the route servers filters

The 1-IX EU filters are updated every 6 hours.

Bogon and Martian filtering 
Please make sure not to announce routes that

  • - are > /24 (IPv4) and > /48 (IPv6) (RFC7454)

  • - have a different BGP next-hop to the IP of your own router

  • - are bogons/martians (private and reserved IP prefixes as defined by RFC1122, RFC1918, RFC2544, RFC3927, RFC 5735, RFC5737, RFC6598 and RFC6890)

  • - are a 1-IX EU peering LAN (please also do not announce any of our peering LANs in the DFZ!)

  • - contain bogon ASNs in the BGP AS path (private and reserved ASN numbers as defined by RFC7607, RFC6793, RFC5398, RFC6996, RFC7300)

  • - has Tier 1 Network ASN in the AS path

  • - first ASN in the AS path is differ from your own ASN

  • - have an AS path length > 32

  • - are < /8 (IPv4) and < /16 (IPv6) (RFC7454)

We will drop these kinds of routes.

Check the status of your routes    
You can check the status of your announced routes to us in the 1-IX EU Looking Glass – the reason why a route is filtered is also shown, as is a hint on how to fix the issue.


IRR and RPKI validation    
Any routes you announce will also be RPKI (RFC6811, RFC7115) validated and checked against Internet Routing Registry (IRR) data. The AS-SET you provide to us will be recursively resolved. Then filtering is executed as follows:

  • The origin ASN needs to be in the customer as-set (make sure that your AS-SET is well maintained and that all your downstreams are included)

  • Is the route a blackhole (RFC7999)?    
     

    • If not, the route undergoes strict RPKI validation filtering (both origin and maxLength):    
       

      • If the result is RPKI Valid, the route is accepted (a missing route object will have no implication in this case).

      • If the result is RPKI Invalid, the route is rejected.

      • If the result is RPKI NotFound/Unknown, we check if the route is resolvable for its origin ASN (this will be the case if a proper route object exists) and it might get accepted or rejected depending on the result.    
         

    • If it is, the route undergoes loose RPKI validation filtering (origin only):    
       

      • If the result is RPKI Valid, the route is accepted.

      • if the result is RPKI Invalid, the route is rejected.

      • If the result is RPKI NotFound/Unknown, we check if the route is resolvable for its origin ASN (this will be the case if a proper route object exists) and it might get accepted or rejected depending on the result.


 Action BGP Communities can be used to control various functions of the route server. With these communities, you can:

  • control the redistribution of advertised prefixes,

  • selectively prepend your own AS up to three times,

  • trigger the Blackholing for your network prefix,

More information can be found here and here

Informational BGP communities are used to signal various information about redistributed prefixes. The 1-IX EU route servers tag all prefixes with certain BGP communities to indicate their origin. You can use this information to determine where a certain prefix has been injected into the 1-IX EU switching platform. This gives you the possibility to filter routes learned from the route servers based on geographical location. 

More information can be found here.