LU-CIX route-server #1
- AS Number : 49624
- IPv4: 188.8.131.52
- IPv6: 2001:7f8:4c::ffff:1
LU-CIX route-server #2
- AS Number : 49624
- IPv4: 184.108.40.206
- 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
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.
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.
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 is as
|1. block of announcement of a route to a certain peer||0:<peer-as>|
|2. announcement of a route to a certain peer||49624:<peer-as>|
|3. block of announcement of a route to all peers||0: 49624|
|4. announcement of a route to all peers||49624: 49624|
* If none of the above communities are used, the prefixes will be announced to all peers.
** Should be considered as <peer-as>:
Google Global Cache (GGC) = 65535
Facebook = 63293
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 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.