Peering Policy

This document is an informative description of the Inter.link AS5405 peering policy. Inter.link may change this policy at any time without further notice. Any written peering or interconnection agreement prevails in the event of any conflict.

Scope and applicability

This document describes the conditions under which Inter.link AS5405 establishes settlement-free peering, both over Internet Exchange Points (IXPs) and through Private Network Interconnects (PNIs). It does not apply to paid services such as IP Transit, which are governed by their own Technical Service Specifications.

The policy has applied since 1 September 2024 and is reviewed periodically.

General policy

Inter.link operates a selective peering policy. A peering is established only where it is mutually beneficial and can improve service quality for Inter.link customers.

• Inter.link does not peer with its own customers.
• Every request is evaluated individually.
• Inter.link may accept, decline, or suspend a peering or PNI for network, quality, or commercial reasons at any time.
• Inter.link may join, upgrade, or leave IXPs.

Network overview

The Inter.link network has more than 40 points of presence (PoPs) in more than 15 countries, with at least one PoP per country. Every location is connected to at least two other locations, and the network is 400GE-enabled throughout.

Current IXP and private-facility presence is published in the AS5405 PeeringDB record. Prospective peers should check PeeringDB for common locations before submitting a request.

IXP peering

Item	Policy
Route servers	Inter.link peers with IXP route servers where feasible
Direct (bilateral) sessions	Considered when traffic exceeds 1 Gbps at the 95th percentile
Traffic ratio	No ratio requirement
Location	Local IXPs are preferred; remote peering and wide-area exchanges are discouraged

Inter.link announces all of its prefixes to IXP route servers. For traffic engineering, some prefixes may be announced only in specific regions.

Some IXPs filter route-server announcements using the PeeringDB “never via route servers” flag. A network that does not receive the expected prefixes through the route servers should request a direct peering session.

Private Network Interconnects

Item	Policy
Traffic threshold	Considered when traffic exceeds 20 Gbps at the 95th percentile
Redundancy	Multiple redundant connections in different metros
Traffic ratio	1:1.5
Evaluation	Each request is evaluated individually, followed by a 30-day trial period
Supported interfaces	100G-LR1, 100G-LR4, and 400G-LR4
Cross-connect costs	The requester pays for the first cross-connect; subsequent cross-connects are cost-shared, alternating between the parties

Remote-triggered blackholing

Support for remote-triggered blackholing (RTBH) is mandatory for all new PNIs from 1 January 2027. Existing PNIs must support RTBH by 30 June 2027; agreed exceptions may apply.

The RTBH communities accepted by Inter.link are described in the Inter.link BGP Communities documentation.

Technical requirements

A peer must meet the following requirements:

Area	Requirement
Address families	IPv4 and IPv6, or IPv6 only
Route registration	Every announced prefix is covered by valid IRR data or an RPKI ROA
Session addressing	Sessions use publicly routable addresses only; private (RFC 1918) addresses are not used
PeeringDB	The peer maintains an accurate PeeringDB record
Next hop	The peer sets next-hop-self on all advertised routes
Static routing	No default or static routes point toward Inter.link routers
Troubleshooting	The peer operates a looking glass or RIPE Atlas probes or anchors
Flow data	The peer operates a flow data collection system for debugging

Inter.link supports MP-BGP, LACP with one or more members, and BGP MD5 authentication. MD5 is supported but not preferred.

Inter.link publishes its announcements under the AS-SET RIPE::AS5405:INTERDOTLINK. The AS-SET is populated automatically and should be used by peers to build route filters.

Route acceptance and attribute handling on Inter.link sessions are described in the Inter.link Routing Policies documentation. Traffic-engineering and RTBH communities, which Inter.link accepts from peers as well as from customers, are described in the Inter.link BGP Communities documentation.

Operational requirements

Area	Requirement
Network operations	The peer operates a Network Operations Centre (NOC) and provides access to it free of charge for operational issues
Security and abuse	The peer cooperates with Inter.link on DDoS prevention and on abuse and misconfiguration handling

Contacts and resources

Purpose	Contact or resource
New peering requests	peering-policy@inter.link
Implementation and technical matters for existing peers	noc@inter.link
PeeringDB	as5405.peeringdb.com
Looking glass	lg.as5405.net
AS-SET	RIPE::AS5405:INTERDOTLINK

Responsibilities

Activity	Inter.link	Peer
Peering request	Evaluates each request against this policy	Checks common locations in PeeringDB and submits the request to the peering team
Route filtering	Publishes and maintains AS-SET RIPE::AS5405:INTERDOTLINK	Maintains IRR objects or ROAs for every announced prefix and filters using the Inter.link AS-SET
PNI provisioning	Shares cross-connect costs after the first order	Orders and pays for the first cross-connect and provides redundant connections
RTBH	Accepts RTBH as documented in the BGP Communities documentation	Supports RTBH on PNIs by the applicable date
Operations	Operates a NOC and a public looking glass	Operates a NOC, a looking glass or RIPE Atlas probes, and flow collection, and cooperates on abuse and DDoS handling