tim@as214380.net ~ $

Peering

AS214380 has an open peering policy. We do however follow some guidelines for peering requests:

  • You must have a public ASN with at least one globally routable IPv4 or IPv6 prefix.
  • Your IRR entries should be up-to-date.
  • Your PeeringDB entry should be up-to-date.
  • Also, make sure your ROAs are valid. AS214380 does strict RPKI ROV filtering.

I’m open to peering at any IXPs we share. If you meet these criteria and are ready to proceed, feel free to send an email to peering [at] as214380 [dot] net.

Filtering

AS214380 filters every session strictly:

  • IRR: your routes must be covered by the route(6) objects of the AS-SET in your PeeringDB record (or your ASN when it has none). Prefixes that are not are rejected. The lists are built with bgpq4 and refreshed daily, so a new route object takes up to a day.
  • RPKI: RPKI-invalid routes are rejected (ROV).
  • Sanity: bogon prefixes and ASNs, prefixes longer than /24 (IPv4) or /48 (IPv6), AS paths of 100 or more hops and the IXP peering LANs are rejected.

Every rejected route is tagged with the reason, see ~/bgp_communities/#rejected-routes.

Blackholing (RTBH)

Under attack? Announce the attacked address with the well-known community 65535:666 (RFC 7999) and AS214380 drops traffic to it at the edge. The prefix must be inside your IRR (see above) and be a /25-/32 (IPv4) or /49-/128 (IPv6). It is not propagated further (NO_EXPORT).

BGP communities

AS214380 tags every route it learns and announces with large communities: where it was learned or announced (IXP and facility), RPKI state and reject reasons. See ~/bgp_communities.