[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 as286-peering@kpn.com.

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 make use of ROA information. However ... slow start ... it's for now a trial and requires some follow up before getting strict.

Why not enforce it right away?

First we want to inform our customer and give them some time to get their setup corrected and help them if needed rather than annoy them from day one. And by now we haven't yet decided on how to handle (customer) RTBH, sBH/erBH and rtsdCoS announcements - it's very unlikely that standard ROA covered address space includes masks up-to /32 or /128 ... And who knows, what else pops up ...

Further we see (20180627) ~5400 invalid prefixes from peers and for ~2300 out of these prefixes no valid prefixes or less-specific not-invalid prefixes (=valid or unknown validation state) prefixes are known in the DFZ. Maybe we'll reach out to some of them ... or not ...

Here (ana-invalids.txt) is an -from time to time (daily) updated- analysis of invalids we "see". The list is generated the following way: collect from each PE invalids received from eBGP peers (ignoring prefixes we filter out based on other criteria). For every invalid check if there's a non-invalid - most likely less-specific - prefix in the table. (Note: the lookup is done against one central RIB which prefs customer routes and thus does not hold all possible alternatives received from eBGP peers ...).

The format is somewhat simple. For every invalid prefix seen there is a single line like (note the uppercase AS in srcAS/srcASes):


For every prefix there is one or there are multiple lines with (note the lowercase AS in srcas)


Routing policy rPKI/route validation - 20180806

[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 ...)