Route Server Guide (Last updated 2010-03-03)

Route Server Information

Our configuration information is

You can safely accept any routes announced by us, as we filter all incoming advertisements according to the configured policies.

You'll find objects AS-DECIX, AS-DECIX-V6, AS-DECIX-CONNECTED and AS6695 in the RIPE database. They are maintained by DE-CIX technical management. The current status of DE-CIX can be obtained from our looking glass

Routesever Setup

The DE-CIX routeserver systems consists of two boxes (80.81.192.157, 2001:7f8::1a27:5051:c09d and 80.81.193.157, 2001:7f8::1a27:5051:c19d) running iBGP. To work properly only one is needed. Every now and then we have to do some housekeeping on the boxes so that bgpd will go down. Housekeeping will not last longer than one hour. That means service is Ok as long as there is one session operational and the second one is not down for more than one hour.

Generic Routeserver Configuration

Given ISP with AS 65000, IP address 80.81.192.X and AS-SET AS-TESTIP. The AS-SET is enrolled using whois.radb.net resulting in prefix-list PPP (aggregated and allowing any more specific prefix ≤24) and filter-list ZZZ. The resulting sample config then will look like

router bgp 6695
 neighbor 80.81.192.X remote-as 65000
 neighbor 80.81.192.X passive
 neighbor 80.81.192.X prefix-list PPP in
 neighbor 80.81.192.X filter-list ZZZ in
 neighbor 80.81.192.X attribute-unchanged

Please also note that "attribute-unchanged" will give a fully transparent session. Detail see below.

Also note that since our side is configured passive that on your side the BGP session has to be configured active.

NOTE: As of Cisco release 12.0(S) Cisco added the bgp feature "bgp enforce-first-as". This feature is enabled by default. To use the route-server fully transparently you have to set "no bgp enforce-first-as".

Route Server Control

Filtering

Both Routeservers support AS-path filtering as well as prefix filtering.

Incoming AS-path filtering is done according to the macro you provide. This macro is resolved against whois.radb.net and appropriate as-path filters are buildt and installed.

Incoming prefix filtering is also done according to the macro you provide. Via extended whois features of whois.radb.net all of the prefixes belonging to all your AS are extracted and aggregated.

Filters are update daily at around 22:30. Don't forget to register prefixes well in advance (at least 24h before announcing)

For outgoing announcements communities applied are checked as well as checked against a "martian" filter (RFC1918, DHCP, Multicast).

Communities

Outgoing routing information of your routes via the route server can be controlled by you. For this, we do accept communities from you. If you want to announce a certain route to a certain peer AS <peer-as>, please tag the route with the community 6695:<peer-as>. If you want the route to be distributed to all peers, please tag the route with 6695:6695. You can tag one route with more than one community, though. If you want to block certain routes from being distributed to certain peers, you can do so by sending 0:<peer-as> for blocking routing advertisement by the routeserver to peer <peer-as> or by sending 0:6695 to block distribution to all peers. Please note that you have to tag a route with both communities 6695:6695 and 0:<peer-as> if you want to block announcement to AS <peer-as> and allow distribution to everyone else.

Evaluation order of communities is as

Communities not starting with 6695: or 0: are disregarded by the RS. For backwards compatibility, routes with no community at all are distributed to all peers as well. So don't forget to set "send-community" if you want to influence propagation. You can obtain a list of routes distributed to a peer by selecting the "advertised-routes" in the DE-CIX looking glass.

From experience, it is advised to open a peering session with the routeservers at least with community 0:6695 attached to all routes sent. In case of any irregularities, DE-CIX technical management can quickly obtain a complete picture of peers affected.

Local Preferences

To overcome route-server limitations regarding best path selection local preferences are applied to each prefix. A prefix tagged

If you want a collector/looking glass type of service only, please talk to us. We then will set community 0:6695 incoming for all of your prefixes and only announce ^$ to you. Thus you can set up a session to DE-CIX the same way as to all other peers.

Transparency

Besides communities routeservers support additional feature like hiding of ASN, next_hop (default) and transparency of MEDs. Each of these features may be enabled separately. Removing the DE-CIX ASN often eases peering configuration as you don't have to take care for different path lengths.