AS286 Routing Policy

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

AS286 Routing Policy
v20201104

Fading away ...

AS286/KPN International was taken over by AS3257/GTT in December 2019. AS286 will be integrated into / migrated to 3257 and fade away. Therefore some of the information found on these pages might be outdated / obsolete.

Introduction

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:

IRR 1:1 IPv4 and IPv6 (unified and sorted)
IRR "compressed" IPv4 and IPv6 (NET/P,N-M stands for all possible prefixes out of NET/P with prefix length between N and M; NET/N-M is the short form if P=N; list is suitable to be used for Juniper route-filters)
aggregated address space IPv4 and IPv6

Routing policy (transit (IPT) customers)

KPN protects customer sessions with a high max-prefix limit with auto-recover set to 30 minutes in case max-prefix is hit.
KPN does filter announcements received by IPT customers based on filters generated with customer's AS-set out of whois.radb.net (might change to other meta-IRR without further notice).
KPN will accept announcements of the address space reflected by the IRR registration (rather than accepting only prefixes exactly as stated with the route-objects)
We filter on AS-path members (every AS in the AS path must be member of the AS-set).
KPN does *reject* invalids (ROV/rPKI) from customers - see also below (start latest 1st October 2018). For RTBH, sBH and rtsdCoS announcements RV results will be ignored for now (only IRR filtering).
KPN does accept from customers and re-announce to customers prefixes more specific than /24 (v4) or /48 (v6)
KPN does not accept announcements with
- private ASNs (RFC6996: 64512-65534, 65535, 4200000000-4294967294, 4294967295), reserved ASNs (RFC5398: 64496-64511, 65536-65551; IANA reserved: 65552-131071), AS0 (RFC7606) or AS23456 (RFC4893) anywhere in the as-path (except on direct private AS BGP sessions; and we will remove private AS numbers on own announcements)
- long as-paths (>40)
- many communities (>75 incl. the ones added by us AS286 (up to ~10)) or
- first (left most) AS in the path unequal peer AS
- announcements of AS286 space (except the exceptions)
- "Tier-1" alike ASes in the as-paths from downstreams [20190724]: 174, 209, 286, 701, 702, 703, 1239, 1273, 1299, 2828, 2914, 3257, 3320, 3356, 3491, 3549, 3908, 3910, 4323, 4436, 5511, 5580, 6453, 6461, 6762, 6830, 6939, 7081, 8928, 12956]
KPN does not accept nor announce private or other RFC prefixes declared as "do not redistribute" (RFC 1122, 1918, 2544, 3849, 3927, 4193, 4291, 5180, 5737, 6598, ...) or IX (Exchange) LAN ranges KPN connects to [1]
KPN does not accept announcements within 0/0 up-to /7 and ::/0 up-to /15
KPN honours MEDs on customer sessions and will announce IGP metrics on all sessions (except for "own" routes)
KPN does not use route damp(en)ing as default
KPN will make -in most cases- use of GSHUT (BGP GRACEFUL SHUTDOWN) prior to maintenance works affecting BGP sessions. KPN encourages customers to implement support for this. In some cases KPN might in addition prepend (many times) announcements prior BGP affecting maintenance. And yes, we do support GSHUT announced by customers to us as well.
Prepend and local-preference adjusting communities as well as the blackhole community are available to IPT customers
- Blackhole marked prefixes (upto /32 (v4) or /128 (v6)) will be routed to Null/discarded on the complete AS286 backbone (not just on the connection PE), but not (yet) passed to others (peers, RS @ IXes supporting blackholing or alike)
- If multiple local-preference adjusting communities are given, the "lowest" will be used
- If multiple prepend communities are giving and applicable for use on re-announcements, the "more specific" one takes precedence (AS specific over IX specific over peering region and do-not-announce over do-not-prepend over prepend-once over prepend-twice over triple-prepend over quad-prepend)
Informational communities (geographical origin, route-type, ...) are available to customers for further consideration on routing decisions
Prefixes rejected from downstreams can be found here https://as286.net/data/hidden-pfx-downstream.txt (updated only a few times a day)

Routing policy (peering partners)

KPN protects peering sessions with manually maintained max-prefix limits with auto-recover setting in the range of 30-90 minutes in case max-prefix is hit. We'll update settings on your request (peering@as286.net) or eventually if you get close to your limit ...
RANT: Thanks to (our) vendors, prefix-filtering does not scale and can't be deployed in general for all peers. However KPN reserve it's right, to filter individual peers at any time.
KPN does *reject* invalids (ROV/rPKI) from all peers.
KPN does not accept nor announce prefixes more specific than /24 (v4) or /48 (v6) (except some specials) on peering sessions
KPN does not accept announcements
- with private ASNs (RFC6996: 64512-65534, 65535, 4200000000-4294967294, 4294967295), reserved ASNs (RFC5398: 64496-64511, 65536-65551; IANA reserved: 65552-131071), AS0 (RFC7606) or AS23456 (RFC4893) anywhere in the as-path (and will remove private AS numbers on own announcements)
- long as-paths (>40)
- too many communities (>75 incl. the ones added by us AS286 (up to ~10))
- first (left most) AS in the path unequal peer AS
- or announcements of AS286 space (except the exceptions)
(experimental) KPN de-prefs routes (-20 and community 286:28684 added) from peers being potential leaks with AS-path matching "Tier1*-nonTier1+-Tier1-.*" pattern. [20190724: 174, 209, 286, 701, 702, 703, 1239, 1273, 1299, 2828, 2914, 3257, 3320, 3356, 3491, 3549, 3908, 3910, 4323, 4436, 5511, 5580, 6453, 6461, 6762, 6830, 6939, 7081, 8928, 12956]
KPN does not accept nor announce private or other RFC prefixes declared as "do not redistribute" (RFC 1122, 1918, 2544, 3849, 3927, 4193, 4291, 5180, 5737, 6598, ...) or IX (Exchange) LAN ranges KPN connects to [1]
KPN does not accept announcements within 0/0 up-to /7 and ::/0 up-to /15
KPN does not honour MEDs per default nor does KPN announce MEDs (reset to 0); if you think this might be beneficial for both of us, please contact us
KPN does not use route damp(en)ing as default
KPN will make -in most cases- use of GSHUT (BGP GRACEFUL SHUTDOWN) prior to maintenance works affecting BGP sessions. KPN encourages peers to implement support for this. In some cases KPN might in addition prepend (many times) announcements prior BGP affecting maintenance. And yes, we do support GSHUT announced by peers to us as well.
Prepend and local-preference adjusting communities are *NOT* available to peering partners
Blackhole support is not enabled by default for peers; if you are interested in, please contact us
Informational communities (geographical origin, route-type, ...) are available to peers for further consideration on routing decisions

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:

take a full, single clean table (not including invalids)

collect from every PE eBGP received invalids

search in the clean table for every invalid an alternative path (in this order; origin AS of altpfx in ()):

same size not-invalid prefix (must valid), e.g.
5.236.0.0/18;srcAS=49666;altpfx=5.236.0.0/18(48159);
if there are not-invalid more-specifics (must be valid), list them {>...}; if these cover only partial the space, mark it with p, e.g.
95.64.14.0/23;srcAS=50064;altpfx=95.64.14.0/23(197207),{>95.64.14.0/24(197207),>95.64.15.0/24(197207)};

else

if there are not-invalid more-specifics (must be valid) covering the full prefix of the invalid, use these as altpfx
43.243.132.0/23;srcAS=64072;altpfx={>43.243.132.0/24(64072),>43.243.133.0/24(64072)};

else

if there's a not-invalid less specific (could be valid or unknown), use this as altpfx, marked with <, e.g.
45.64.72.0/24;srcAS=134739;altpfx=<45.64.72.0/23(134739);
if there are not-invalid more-specifics (must be valid), list them {>...}; as these cover only partial of the space (full coverage is case above), mark it with p, e.g.
80.91.184.0/21;srcAS=21219;altpfx=<80.91.176.0/20(21219),p{>80.91.185.0/24(21219)};

else

if there are some not-invalid more-specifics (must be valid) seen within the invalid but NOT covering the full prefix size list then marked with PARTIAL and list them, e.g.
80.81.144.0/20;srcAS=9051;altpfx=PARTIAL{>80.81.159.0/24(24634)};

else

altpfx=NONE

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