Join us now

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 now 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 ports 3784 and 3785, 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.

If you are interested to trial BFD on the route servers with us, please contact us at support[at]lu-cix[dot]lu. We are looking for testers!

LU-CIX route-servers

Thanks to the LU-CIX route-servers you can replace all or a subset of your BGP sessions with one session towards each route-server. This facilitates the implementation of peering arrangements, and lowers the barrier of entry for new participants on the peering platform.

The route-servers do not participate in the forwarding path, so it does not forward any traffic. Peering with a route-server does not mean that you must accept routes from all other route-server participants.

Route-Server Control

Disabling first AS check

The route-servers do not have their AS first in the AS_PATH. In some cases you might need to disable the first AS check in your BGP configuration. On Cisco routers please specify 'no BGP enforce-first-as' to disable the enforcement.

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 49624:<peer-as>.

If you want the route to be distributed to all peers, please tag the route with 49624:49624. 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 route-server to peer <peer-as> or by sending 0:49624 to block distribution to all peers.

Please note that you have to tag a route with both communities 49624:49624 and 0:<peer-as> if you want to block announcement to AS <peer-as> and allow distribution to everyone else.

Evaluation order of communities

Action*CommunityLarge Community
1. block of announcement of a route to a certain peer0:<peer-as>49624:0:<peer-as>
2. announcement of a route to a certain peer49624:<peer-as>49624:1:<peer-as>
3. block of announcement of a route to all peers0: 4962449624:0:0
4. announcement of a route to all peers49624: 4962449624:1:0

 

* 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
Communities not starting with 49624: or 0: are disregarded by the route-server. For backwards compatibility, routes with no community at all are distributed to all peers as well. Don't forget to set "send-community" if you want to influence propagation.

 

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.

 

Filtering

The route servers only allow duly declared prefixes. In order to pass the filter, a prefix must be part of a peer's AS macro, via the route objects, in the appropriate IRR.

On top of IRR filtering, LU-CIX also applies RPKI Route Origin Validation. 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 (ROV) 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.