Open Nav

LINX Route Server Project

Internet exchange points provide every connected member with a direct Layer2 connection to all other members at the exchange. Across this Layer2 network, members will establish BGP peering between each other, allowing them to exchange IP prefixes and subsequently allow traffic to be routed between them across the peering LAN.

This is done by setting up bilateral peering session, which means that once members agree to peer, they configure their routers by establishing a BGP session between them. At large IXPs, (LINX has over 750 members available for peering) setting up these individual BGP sessions, and the required operational overhead can be a challenging and time-consuming task. The large number of BGP sessions can also lead to performance issues, especially in the case of members with lower bandwidth requirements, and as such often less powerful routers.

One way to overcome this, is the use of multilateral peering. To enable this, LINX provides route servers on each of each Peering LANs. Members who want to use the router server, only have to establish a single BGP session. This will provide them direct access to the prefixes of any other member using this route server. Particularly for new members, the ease with which they can access many peers allows them to quickly see a return on their investment for joining the Internet Exchange. It also reduces the network management overhead again bringing value to the member. Members also use them for redundancy purposes.

There are a few instances, which might prevent some members from using a route server. They may have an open peering policy but they like the ability to shut down a peering session if they develop an issue with the peer. Although it is easily possible to achieve this also on route servers, the complexity is higher compared to a simple shutdown of a direct peering session. When peering, members should follow best practice rules but this can be a complicated, time consuming processes and sometimes errors creep in. Incorrect routing information can cause connectivity problems, the most common of which is the advertising of invalid prefixes or leaking a full or partial routing table. With direct, bilateral sessions, it is easy to build prefix filters to prevent issues from propagating into the network. However, because of the volume of peers available at the route server this becomes much harder for the individual member to manage.

LINX have embarked on a project to address this issue. The project is going to be carried out in two phases. All prefixes will be validated against the publicly available IRR databases. Specifically, LINX are going to use radb.net. This is a conglomerate of internet registry data bases and mirrors all the largest and most important IRR and private databases. If a prefix is found to be invalid then it will be tagged with a communicated BGP community. LINX will also be working with members to identify any possible issues, and where necessary provide guidance on how to address them. It also means that from the moment LINX start tagging, any member who is receiving invalid prefixes can easily stop this from happening by applying a simple prefix filter to his own router rejecting any prefixes tagged with that BGP community. LINX will continue to monitor the number of invalid prefixes and would expect to see them drop over time. It is hoped that after 6 weeks or so that the levels would have dropped significantly. Once this has happened, LINX will announce phase two of the project. In phase two LINX will no longer propagate any prefixes that are deemed to be invalid. If members want they can still receive these prefixes, however the LINX default will be not to propagate. Any member wishing to receive such prefixes will need to contact LINX directly, via the support services mailbox. The aim of this project is to capture and reduce all non malicious errors and reduce member issues caused by prefix leaks.

Validating against the IRR database means that it becomes very important that all members have correct and current information in Peering DB. LINX has always stressed the importance to members of registering their information on Peering DB but as this project becomes live it is now critical. LINX are urging all members to check and update their information on peering DB. As a future improvement, LINX are also evaluating the use of additional checks, i.e the use of RPKI to further improve the platforms.

 

< Go Back

Latest News

26th March 2024

AFR-IX Telecom Join LINX Nairobi

By Lynsey Buckingham

The London Internet Exchange (LINX) are pleased to announce that AFR-IX Telecom are the latest member network to join...

Read More
14th March 2024

Interconnection Services Live at AtlasEdge Manchester

By Lynsey Buckingham

AtlasEdge, a leading pan-European Edge data centre provider, and London Internet Exchange (LINX), one of Europe’s largest internet exchanges,...

Read More
7th February 2024

A New Era of Interconnectivity: LINX NoVA Ushers In 10-Year Milestone

By Lynsey Buckingham

The London Internet Exchange (LINX) is marking a significant milestone – 10 years of operation in Northern Virginia, a...

Read More
Website by Echo
Email
Call