Peering Policy

Our peering policy is Selective: open at every exchange route server, selective for everything else.

At IX route servers

We already peer with you

At every exchange where a route server is available, at any traffic volume. No request needed.

Bilateral and PNI

From 100 Mbps sustained

Private interconnect from 2 Gbps, measured per metro. How we measure.

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

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

• We use max-prefix filters on all sessions.
• We do not respect MED (Multi-Exit Discriminator) attributes from peers.
• We do not accept blackhole routes or communities.
• We accept and honor Graceful Shutdown (GSHUT) per RFC 8326.
• If a peer exceeds available capacity at a specific IX, we may choose to not advertise routes to that peer.

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
• Any AS we do not expect in your cone
• Bogon prefixes as designated by IANA
• AS_PATH invalid under ASPA, per draft-ietf-sidrops-aspa-verification
• Excessive or abusive use of BGP communities
• Excessive AS_PATH length (path-stretch or indicative of loops)

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

• Peering at an IX route server needs no request; we are already there, at every exchange listed on our PeeringDB record.
• For a bilateral session or a PNI, email peering@pdxnet.co.uk with the exchange or metro, your ASN, and your current traffic level with us.
• For help with a session that is already up, email noc@pdxnet.co.uk.
• Our BGP communities are available on downstream and customer sessions, not on peering sessions.