Look back at 25 years of interconnection! Visit our anniversary website at withoutyou.de-cix.net

DE-CIX Chicago route server guide

Route server information

DE-CIX operates so-called route server systems (see RFC7947 for a detailed description) to facilitate the exchange of BGP announcements between peers at DE-CIX. 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 having a BGP connection with the route server.

BGP session parameters

This section provides a brief overview of the BGP session parameters to connect to the route servers:

rs1    149.112.11.252
2001:504:102::f528:a:1
rs2    149.112.11.253
2001:504:102::f528:a:2
AS    62760
RIR macro (AS-SET)    IPv4: AS-DECIX-ORD
IPv6: AS-DECIX-ORD-V6
Recommended prefix limit rs1/rs2 (your side):    IPv4: 250,000
IPv6: 70,000

BGP announcement filtering

This section describes the filtering mechanism that can be used to filter BGP announcements.

Your side

You can safely accept any BGP announcements received via the route servers as DE-CIX filters all incoming BGP announcements from all peers. The filtering mechanism is described in the Section "DE-CIX Side".

If you additionally want to filter on your side based on AS-SETs, you can do so by using one or more of the following AS-SETs registered in the RIPE database:

RIR macro (AS-SET)      Purpose
AS-DECIX-ORD      AS-SETs of all DE-CIX ORD customers (IPv4)
AS-DECIX-ORD-V6      AS-SETs of all DE-CIX ORD customers (IPv6)
AS-DECIX-ORD-CONNECTED      ASNs of all DE-CIX ORD customers

DE-CIX side

At DE-CIX, 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. The AS-SET can be changed by contacting the DE-CIX customer service team.

How and what the route servers filters

The DE-CIX filters are updated every 6 hours. Don't forget to register your IP prefixes in the IRR database well in advance (at least 24h before announcing the first time).

Bogon and Martian filtering

Please make sure not to announce routes tha

  • are > /24 (IPv4) and > /48 (IPv6) (RFC7454)
     
  • have a different BGP next-hop than the IP of your own router
  • are bogons/martians (private and reserved IP prefixes as defined by RFC1918, RFC2544, RFC3927, RFC 5735, RFC5737, RFC6598 and RFC6890)
  • are a DE-CIX 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)
  • differ in the leftmost ASN in the AS path from your own ASN
  • have an AS path length > 32
  • are < /8 (IPv4) and < /19 (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 DE-CIX Looking Glass – the reason why a route is filtered is also shown, as is a hint on how to fix the issue.

You can find more info on how to use the DE-CIX Looking Glass here.

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:

  • Origin ASN needs to be in customer cone (make sure that your AS-SET is well maintained and that all your downstreams are included)
  • Is the route a blackhole (RFC7999)?
    • If no, 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 yes, 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**

**Loose filtering on IRRDB route objects
We perform loose filtering on IRRDB route objects. For example: If you have a route object for 46.31.120.0/21 we will also accept e.g. 46.31.120.0/22 and other more specifics (up to /24 and up to /32 for blackholes). If this is not a desired behavior, we strongly encourage you to create a ROA and set the maxLength attribute accordingly. As RPKI validation is performed before the IRRDB route object check, it will render all undesired more specifics as RPKI Invalid, which will result in rejection of these. Please note that this method only works for non-blackholes as we perform loose RPKI validation on blackholes (i.e. ignore maxLength).

Route server setup

The route server setup at DE-CIX Frankfurt consists of two machines. The software utilized to provide the route server service is BIRD. Of the two route servers only one is required. However, in order to use the route server service, every peer is requested to connect to both machines for redundancy purposes, so that if one machine is out of order (e.g. maintenance), the route server service can still be used.

If the route servers system receive a BGP announcement marked as a Blackhole, the NO-EXPORT community and the BLACKHOLE Community are added if these communities are not already present. This makes sure each BGP announcement marked as Blackhole can be easily filtered and does not spread widely in the Internet routing system.

Route server control

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

  • control the redistribution of advertised prefixes
  • prepend your own AS up to three times
  • trigger the calculation of a new alternate path (if available) for your advertised prefixes before you start commencing a maintenance

More information can be found here.

Route server prefix information

Informational BGP Communities are used to signal various information about redistributed prefixes. The DE-CIX 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 DE-CIX 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.

Route server session types

We offer two session types:

Standard/Public session (default)

  • We re-distribute all your announcements to other peers while honoring the BGP Communities which allow you to restrict your announcements
  • We advertise all announcements from other peers to you while honoring the BGP Communities which allow others peers to restrict their announcements

Monitor session

From an operational point of view, it is advised to set up BGP sessions to both route servers, even if you do not want to peer with (i.e. advertise prefixes to) the route servers. This helps DE-CIX staff to quickly monitor the availability of each peer.

Please note that you are required to set up BGP sessions with (but don't need to advertise prefixes to) the DE-CIX route servers to be able to claim credits for the GlobePEER service. Otherwise DE-CIX may not be able to comply with its SLA (please see DE-CIX GlobePEER Technical Service Description - III. IP LAYER CONFIGURATION (ISO/OSI LAYER 3) - Interface configuration).

If your decision not to establish BGP sessions with the route servers was made due to your peering policy, please contact us for establishing a monitoring only session. You don’t have to advertise any prefixes and you won’t receive any prefixes from us on that session.

Example configurations

The following section contains configurations examples for different router operating systems: