[Main] [Communities] [sBH/erBH] [rtsdCoS] [Routing Policy] [Filtering Policy] [Peering Policy]

AS286 Routing Policy



This document only applies to the KPN worldwide IP backbone AS286.

The hereby described routing policy may be adjusted, altered and updated any time. Even our processes cover updates to documentation, there's no guarantee, that it's always up-to-date. In case of doubt, transit customers should contact our NOC and peers should contact peering@as286.net.

A list of communities used by AS286 and their meaning can be found here AS286-communities.html.

AS286's AS-set is AS-KPN (RIPE). A current list of prefixes of the expanded AS-set (via RADb) can be found here:

Routing policy (transit (IPT) customers)

Routing policy (peering partners)

rPKI/route validation

In June 2018 AS286 started to evaluate RV/ROV (rPKI) on the production network. After some "real world" testing, impact analysis and some customer communication to have them clean their ROA (for the prefixes with no not-invalid alternatives) we decided to drop invalids from customers starting 1st of October 2018. Why customers first? Because here we have a direct relation (or the customer with his downstreams).

We decided NOT to reject everywhere from the start due to foreseen connectivity issues. If there would be complains, nice, then we could work on, but we decided not to take the risk for "hidden" failures (like someone trying to reach a shop not getting there and then going to another shop). Others might decide different - there's always some possible impact and risk involved.

Mid February 2019 we started to drop invalids from all peers except from Tier-1 / Tier-1-alike peers. There was no real reason for the time gap between customer filtering and non-Tier-1 (or alike) peers other than giving some people the good feeling this is not a big bang thing.

Mid May 2019 we started to drop invalids from a selected subset of Tier-1 / Tier-1-alike peers. Some Tier-1 peers remained unfiltered.

End June 2019 we finalize the deployment by pushing out the last updates and drop from then on all invalids on the edge (customers, IXes and all peers, including Tier-1 networks). The main reason for holding back Tier-1 networks had been as simple as waiting for our most important downstream to have a 2nd upstream in place (so they either get the invalids from the other network or none of us).

rPKI/RV doesn't play nice with RTBH, sBH, rtsdCoS and thus RV results are ignored for such announcements (customers only). Sigh

This is gone ... with 286 fading more and more away, the quality got worse over the time ... and there are nowadays more sites like this, providing similar views.

Little leftover of our impact analysis is a daily updated report (https://as286.net/data/ana-invalids.txt) of invalids we see from our peers/customers and "alternative" -not-invalid- paths (same sized valid prefix, more-specific valids (partial/covering full invalid prefix size) or less specifics valid/unknown). The report has its limitation, some "local" noise included and the "alternative" paths are just taken from a simple full view table and not all possible paths we have in the network, but it might be of use for the one or other.

It's generated the following way:

iROAS (prefix/mask-maxlen(originAS)) are the ROAs making this announcement invalid.

The rest of the format is hopefully more or less self explaining. In case of questions, drop us an email. Format might also change over time without notice. If you depend on it, drop us an email. Just one little note: The indented lines are just the different paths we recorded for this invalid. And it could be srcAS or srcASes on the non-indented line (invalid with single or multiple source ASes). srcas (lower case) is used on the indented lines (single).

[1] If the IX announces a less specific prefix including the IX LAN, than pMTUd with uRPF should work (if needed at all) for paths through the IX; but most IX do not announce the LAN space at all - so there's a potential risk of things going wrong; if IX start to announce the IX LAN, KPN may (will, must, should) consider re-announcing IX's own announcement (rather than suppressing re-announcement of internal/own -redistributed into iBGP- interface route ...)