Peering policy

AS55285 maintains an open peering policy and welcomes interconnection with networks that follow good routing practice. We expect peers to filter their announcements, validate origins, and honour prefix limits. We hold our own announcements to the same standards.

Policy
Open
Locations
Multiple preferred
Ratio
Not required
Contract
Not required
01

Register in an IRR

Every session is filtered against a registered as-set.

✓
We rebuild prefix filters every hour from the registered IRR objects of every peer and downstream, across all exchanges, PNIs and transit links.
✓
Register your routes and as-set in a recognised IRR (RADB, RIPE, ARIN, or an RIR-hosted database) before requesting a session.
✓
Provide your as-set so we can build accurate prefix filters; announcements outside it are dropped.
✓
Keep IRR objects current. Filters rebuild automatically, so a stale object withdraws your prefixes within the hour.
02

Validate with RPKI

We drop RPKI-invalid routes and ask you to do the same.

✓
AS55285 performs Route Origin Validation on all sessions: invalid announcements are rejected, valid and not-found are accepted.
✓
Create ROAs for every prefix you originate so your space validates as RPKI-valid across the internet.
✓
Deploy ROV on your own borders. Validation contains a leak or a hijack only when both sides drop invalids.
03

Respect prefix limits

Honour our v4 and v6 maximum-prefix limits.

✓
Set max-prefix limits on your side and stay within the published v4 and v6 ceilings; sessions that exceed them will shut down.
✓
Announce only your own and your customers’ routes. No default, no full table, no unregistered space.
✓
Aggregate your announcements, and send more-specifics only where you are steering traffic with them.
04

Keep the peering LAN clean

Ports that break these rules get disabled.

✓
MAC layer: Ethernet II framing only, no LLC/SNAP. The only permitted ethertypes are IPv4 (0x0800), ARP (0x0806) and IPv6 (0x86DD).
✓
One source MAC per port, unicast only. The sole exceptions are broadcast ARP and multicast ICMPv6 Neighbour Discovery / Solicitation and MLD, never Router Solicitation or Router Advertisement.
✓
No proxy ARP and no link-local noise: spanning tree, CDP / LLDP / EDP, VTP / DTP, UDLD, L2 keepalives, IRDP, ICMP redirects, BOOTP / DHCP, PIM, DVMRP, ICMPv6 ND-RA and MOP must never reach our ports.
✓
IP layer: no directed broadcast, no IGP chatter (OSPF, IS-IS, RIP), and never re-advertise the peering LAN prefix without our permission.
✓
Application layer: BGP hijacking, DNS / NTP / SSDP amplification, and HTTP / UDP / ICMP floods across the fabric will get your port shut down.
✓
Announce consistently and symmetrically across all our meeting points, filter bogons and RFC1918 / RFC6598 space, and support BFD where available.
05

Operate a reachable NOC

Stay contactable and keep records accurate.

✓
Maintain a 24/7 reachable NOC and keep your PeeringDB record complete and up to date.
✓
We report leaks, hijacks and limit breaches to the NOC address in your PeeringDB record. Keep it monitored.
✓
Send us notice before maintenance that affects our sessions.

Prefix limits & filtering

We apply strict prefix filters built from your IRR as-set and RPKI validation state. Set the following maximum-prefix limits on your BGP sessions with us, and stay within them.

IPv4 max-prefix
10,000
Advertised in PeeringDB · set your limit at or above this
IPv6 max-prefix
1,000
Advertised in PeeringDB · set your limit at or above this

Ready to peer?

Confirm your details in PeeringDB, then contact our NOC. We provision on the route servers at all 6 exchanges we attend, and directly at any facility where we both have a presence.

View on PeeringDB → Open Looking Glass →