Peering Policy

Policy Overview

  • Our peering policy is Selective.
  • At public Internet Exchanges (IX), we peer at all IX route server(s) where available. We will consider bilateral peering once sustained traffic exceeds 100 Mbps.
  • For sustained traffic above 2 Gbps, we will move to a Private Network Interconnect (PNI). PNI decisions are made per metro; cross-connect fees and logistics are the responsibility of the requesting party unless otherwise agreed.
  • Traffic thresholds are evaluated using the 95th percentile over a rolling 30-day window, per metro and per interconnection (each IX peering session or private cross-connect).
  • Where feasible and mutually beneficial, we prefer PNIs over public IX capacity.
  • If a peer exceeds available capacity at a specific IX, we may choose to not advertise routes to that peer.
  • We do not respect MED (Multi-Exit Discriminator) attributes from peers.
  • Only send us traffic destined for the routes we announce; do not point default routes to us.
  • Only send us traffic originating from your own networks, including downstreams.
  • You must operate a 24×7 Network Operations Center (NOC) reachable at any time.
  • Refer to our PeeringDB record for locations, contact details, and recommended max-prefix values; set sensible limits accordingly for approved sessions.

Routing and Filtering

  • We use max-prefix filters on all sessions.
  • We will discard prefixes where one or more of the following conditions are met:
    • -IPv4 prefix length longer than /24
    • -IPv6 prefix length longer than /48
    • -NEXT_HOP doesn't match the neighbor's IP address
    • -First AS in the AS_PATH doesn't match the neighbor's AS
    • -Private AS anywhere in the AS_PATH
    • -Bogon prefixes as designated by IANA
    • -Excessive or abusive use of BGP communities
    • -Excessive AS_PATH length (path-stretch or indicative of loops)
  • We do not accept blackhole routes or communities.
  • We accept and honor Graceful Shutdown (GSHUT) per RFC 8326.

We require sound routing hygiene and consistent announcements across interconnections. RPKI must be properly maintained; routes with invalid ROAs are rejected.