Route-Servers

LU-CIX route-server #1

AS Number : 49624
IPv4: 188.93.170.255
IPv6: 2001:7f8:4c::ffff:1

LU-CIX route-server #2

AS Number : 49624
IPv4: 188.93.171.0
IPv6: 2001:7f8:4c::ffff:2

If you would like to peer with the LU-CIX route servers, please contact: support[at]lu-cix[dot]lu

LU-CIX route-servers

Thanks to the LU-CIX route-servers you can reduce the number of BGP sessions you need to maintain on LU-CIX. When peering with the route-servers you will by default receive all the routes from all members peering, with open policies, on the route-server. This facilitates the implementation of peering arrangements and lowers the bar for new members of the peering platform.

Peering with the route-servers does not mean that you have to accept routes from all other route-server peers. You can implement your own filters for incoming routes, and you can use BGP Communities (see below) to control distribution of your own routes to other peers.

LU-CIX recommends peering with both route-servers. We perform maintenance of the route-servers on a regular basis. During maintenance we will always make sure that at least one route-server remains operational. Peering with both route-servers will guarantee that prefix distribution and as a result traffic exchange with your AS will not be impacted.

Configuration of BGP sessions with route-servers

Setting up BGP sessions with the route-servers is not much different from other BGP sessions. If you want to influence route propagation with communities, you may have to set "send-community" in your BGP configuration. Also depending on your router vendor you may have to disable the first AS check.

Disabling first AS check

In most circumstances the first AS in the AS_PATH is the peer ASN. However, the LU-CIX route-servers do not prepend their own ASN onto the AS_PATH. Some BGP routers are by default configured to reject announcements where the first AS in the AS_PATH does not correspond to the peer ASN. Such routers need a special configuration to accept the routes from the route-servers. For instance on some Cisco routers you need to specify 'no BGP enforce-first-as' to disable this enforcement.

Filtering routes sent by the route-servers

If you wish, you can apply filtering of routes sent by the route-server. We publish the AS Macro “AS-LUCIX-RS” which contains all ASes expected to source prefixes distributed over the LU-CIX route-servers.

Route-Server Control

Communities

Distribution of routes via the route-servers can be controlled by attaching BGP Communities. LU-CIX recommends the use of BGP Large Communities because they allow 32-bit AS numbers. LU-CIX still supports “standard” BGP Communities but considers their usage legacy. Multiple BGP Communities can be attached to a single route, allowing fine-grained control of route distribution.

Scenario 1: Distributing to all route-server peers:

By default, without any communities, routes will be distributed to all route-server peers. If you want to distribute to all route-server peers there is nothing special to be done.

Scenario 2: Distributing to most route-server peers, but excluding a small number of peers:

For each peer with ASN <peer-asn> you want to suppress announcements for, add large community 49624:0:<peer-asn>. To make sure that the route will be announced to all other peers also add large community 49624:1:0 (legacy: 49624:49624).

Scenario 3: Distributing to specific route-server peers and no one else:

For each peer with AS <peer-as> you want to announce a route to, add large community 49624:1:<peer-as> (legacy: 49624:<peer-as>). To make sure the route is not announced to any other peer also add 49624:0:0 (legacy: 0:49624).

Well-Known Communities (RFC1997)

The LU-CIX route-servers are transparent to, i.e. do not interpret, the RFC1997 well-known communities (NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED). Any routes tagged with these communities will be forwarded to peers with the communities still in place, allowing receiving peers to interpret them.

Evaluation order of communities

Action*	Large Community	Legacy Community
1. block route announcement to certain peer	49624:0:<peer-as>	0:<peer-as>
2. announce route to certain peer	49624:1:<peer-as>	49624:<peer-as>
3. block route announcement to all peers	49624:0:0	0: 49624
4. announce route to all peers	49624:1:0	49624: 49624

* If none of the above communities are used, the prefixes will be announced to all peers.
Special <peer-as> values:
Google Global Cache (GGC) = 65535
Apple Edge Cache (AEC) = 31128
Large communities not starting with 49624: and legacy communities not starting with 49624: or 0: are disregarded by the route-server. Don't forget to set "send-community" in your BGP configuration if you want to influence propagation of your routes.

Route Filtering

LU-CIX attaches great importance to Internet routing security. Therefore, we apply strict filtering on the route-servers to ensure that a member is authorized to announce a certain route. The following filters are applied on incoming routing updates:

max prefix checking
Martians filtering
AS-PATH length check
IRR filtering
RPKI ROV

If the maximum number of prefixes expected to be sent by the member is exceeded, the session is dropped. This limit is obtained from the member’s entry in PeeringDB if it exists, or else a default limit of 100 prefixes is used.
The LU-CIX route-servers refuse any route for private or reserved address space; we are filtering out the so-called “martians”.
The LU-CIX route-servers refuse any prefix that has an AS-PATH length of more than 64.
The route-servers only allow prefixes duly registered in an IRR. In order to pass our filter, a prefix must be registered as a route object with a source AS that is part of the peer's AS macro (or equal to the peer’s AS, if no macro defined), in the appropriate IRR.

BGP communities are applied to accepted prefixes on the route-servers to inform of the IRR verification result:

49624:1001:1 = valid

LU-CIX applies RPKI Route Origin Validation (ROV). RPKI, short for Resource Public Key Infrastructure, is a community-driven technology based on open standards that is aimed at making Internet routing more secure. Please visit this page for more information.

Route Origin Validation is a mechanism by which route advertisements can be authenticated as originating from an expected autonomous system (AS) and as matching the expected prefix size. Our route-servers drop any routes that are RPKI invalid, i.e. routes that fail one or both criteria. The criteria are checked against public databases of cryptographically signed Route Origin Authorisations (ROA). If no ROA exists for a received prefix, the route is accepted with RPKI status “unknown”. If a ROA exists that matches, the prefix is accepted as valid. A prefix is rejected only if a ROA exists but the received prefix does not match it.

BGP communities are applied to accepted prefixes on the route-servers to inform of the RPKI verification result:

49624:1000:1 = valid
49624:1000:2 = unknown

LU-CIX encourages all its members to actively participate in maintaining routing security by creating ROAs for their announced prefixes.

BFD

LU-CIX offers BFD support on the route-servers.

BFD is a generic keepalive and failure detection protocol that runs over almost any communication media. In this case, each BGP session will be doubled by a dedicated BFD session that runs on UDP port 3784, on the same IPv4 or IPv6 addresses as the BGP session itself. When BFD detects the failure of a neighbor, it informs the BGP process which triggers immediately the withdrawal of the neighbor’s routes, shortcutting the overly generous BGP timeouts and enabling the use of an alternate route.

We encourage members to use BFD on their route-server BGP sessions. This allows for extremely fast failover in case of control path outages. Our route-servers are configured with BFD passive sessions by default. As soon as a member starts BFD on a route-server session, the route-server will switch into BFD mode, i.e. will perform failure detection with BFD.

The following are our current recommended timer values for BFD:

* Min Rx interval 500ms

* Min Tx interval 500ms

* Idle TX interval 1000ms

* Multiplier 3