At its most recent membership meeting LINX99 in November, LINX updated the membership on the status of the route validation project.
At its membership meeting LINX96 in February 2017, The London Internet Exchange (LINX) announced the plans for deploying route validation at all its route servers. After the discussions with the membership in February LINX had agreed on a two stage approach, firstly invalid prefixes would be tagged and then after a short period the tagged prefixes would no longer be propagated. Any member who wished to receive all data would always have the option to request such data.LINX’s caution came from concerns that once initial validation was put in place the quantity of invalid prefixes was very large. To mitigate this risk LINX embarked upon an individual programme with their NOC team to contact all members who were announcing invalid prefixes or leaking routing tables to inform them of the route server project to help them correct the issue (namely correcting information held in PeeringDB, and other databases). Contacting members has had some impact on the number of invalid prefixes being announced, but surprisingly it is still around 20% of the total prefixes.At its most recent membership meeting LINX99 in November, LINX updated the membership on the status of the route validation project. LINX informed that the next step was to start to implement the route tagging, as originally agreed with the members, and that this was due to start the same week as LINX99. After a short discussion with the members following the announcement it became clear that the members now preferred for LINX to go straight to a non-propagated approach. The majority of members present thought that a two staged implementation would not be effective as members would have to build their own filters based upon the LINX tagging. This work would then become redundant when LINX started not to propagate tagged prefixes and as a result most of them wouldn’t build their own filters. As for members who were announcing invalid prefixes, whilst the number of routes were high, the number of members that this represented was not as significant.
LINX CMO, Kurtis Lindqvist, posed the question directly to the room regarding which approach would LINX should take. It was agreed that the roll out should be by individual route servers with non-propagation being in place almost immediately after the tagging is announced. The first route server to go through this process is at IXManchester, with LINX enabled tagging of prefixes with communities based on the result of prefix validation, beginning on Tuesday 28th November. At this first step, LINX will be using the IRR object registered in PeeringDB to check for valid IRR entries for the announced prefixes. In addition, LINX check for a valid ASN origin.
On Wednesday 29th November, LINX changed the default configuration on rs1.man1 (quagga) and will no longer propagate any prefixes which do not pass the prefix validation. On Monday, 11th December, LINX will change the default configuration for rs2.man1 to match that of rs1.man1.
If for whatever reason, members want to continue to receive the unfiltered prefixes, they can opt-out of this change by opening a ticket with the LINX NOC, stating their IXManchester peering LAN IP address and ASN.
Similar changes will be applied to the LINX route servers on all LANs over the next few weeks. If members are using LINX route servers then they are encouraged to look out for further announcements on the LINX ops-announce mailing list.
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 PeeringDB. LINX has always stressed the importance to members of registering their information on PeeringDB, but as this project becomes live, it is now critical. LINX are urging all members to check and update their information to ensure that it is correct.
As a future improvement, LINX are also evaluating the use of additional checks, i.e. the use of RPKI to further improve the platforms.
Ends
