AS62597 Peering Policy

NSONE (NS1) has a selective, but generally open peering policy - peers are selected based upon performance, capability, and where there is mutual benefit.

NSONE's general technical requirements for peering are:

• A knowledgeable and fully staffed 24x7x365 Network Operations Center (NOC), capable of assisting in the resolution of:
• All technical and performance issues.
• All security violations, denial of service attacks, or any other abuse originating within the peer or their customers.
• NSONE will overwrite received Multi-Exit Discriminators (MEDs) by default.
• A publicly routable ASN.
• At least one publicly routable /24 and/or /48
• Current and complete peeringdb.com entry including a 24x7 NOC email role account and phone number.
• Neither party shall establish a static route, a route of last resort, or otherwise send traffic to the other party for a route not announced via BGP.
• Both IPv4 and IPv6 are supported (and expected).
• Both parties are expected to register their routes in a public Internet Routing Registry (IRR) database, for the purpose of filtering. Both parties shall make good faith efforts to keep this information up to date.
• MD5 is not required, nor recommended.

Additional Routing Policy

• NSONE may not advertise its anycast prefixes to peers depending on their geographic scope, whether they operate a backbone, and whether we peer in multiple locations.
• NSONE does not operate a backbone and may advertise pop specific routes to peers in addition to anycast prefixes.
• NSONE does not advertise anycast prefixes to route servers.

Filtering Policy

NSONE relies on IRR for prefix lists and as-path access lists:
• Routes from ASNs not included in peers' AS-SET will be rejected.
• Unregistered prefixes will be rejected.

Peer with us

Find us on PeeringDB if you'd like to peer.