Routing Policies
This document is an informative description of the standard Inter.link routing policies. The applicable service order, Service Level Agreement (SLA), and Master Services Agreement (MSA) prevail in the event of any conflict.
Scope and applicability
Section titled “Scope and applicability”This document defines route validation, route acceptance, and attribute handling for customer BGP sessions with Inter.link AS5405. It applies to IP Transit and FlexTunnel wherever those services refer to the Inter.link routing policies.
IPv4 unicast routes are exchanged over the IPv4 BGP session, and IPv6 unicast routes are exchanged over the IPv6 BGP session. BGP communities and remote-triggered blackholing (RTBH) are defined in the separate BGP Communities document. BGP FlowSpec is governed by the separate FlowSpec Technical Service Specification.
Customer route authorization and filter generation
Section titled “Customer route authorization and filter generation”Inter.link applies IRR-derived prefix, origin-AS, and AS-path filters to every
customer BGP session. Permitted prefix and origin-AS combinations are derived
from the customer’s route and route6 objects. The customer’s AS-SET is
recursively expanded to derive the permitted origin ASNs and corresponding
prefix filters. The originating ASN must appear in that expanded AS-SET, and
the other AS-path hygiene checks in this document also apply.
Inter.link uses IRR data mirrored from APNIC, AFRINIC, ARIN, RIPE, LACNIC, and RADB. An object that exists only in another routing registry does not authorize an announcement.
An RPKI Valid route does not require a matching IRR-derived prefix-list entry but remains subject to the applicable prefix-length and AS-path policies. An RPKI NotFound route must pass IRR prefix and origin-AS validation as well as the AS-path filters. An RPKI Invalid route is rejected unless it is an authorized RTBH announcement meeting the requirements in the BGP Communities document.
Route acceptance
Section titled “Route acceptance”Inter.link applies the following standard route-hygiene rules:
| Check | Standard policy |
|---|---|
| Ordinary IPv4 prefix length | /8 through /24 |
| Ordinary IPv6 prefix length | /19 through /48 |
| First AS | The leftmost ASN must equal the ASN configured for the customer BGP session |
| AS-path length | A maximum of 50 ASNs is accepted |
| Bogon resources | Bogon prefixes and bogon ASNs are rejected |
| Tier-1 ASNs | A route containing a Tier-1 ASN in the customer AS path is rejected |
The RTBH prefix-length exceptions are defined in the BGP Communities document. Both public and private ASNs may be used as the ASN of the customer BGP session, subject to the same first-AS requirement. The configured private session ASN is permitted for routes originated directly by that customer; other bogon ASNs remain subject to rejection. A customer may prepend its own session ASN, subject to the maximum AS-path length. Private ASNs are removed from the AS path before Inter.link advertises the route to another external BGP neighbour; they are not replaced with another customer ASN.
Attribute handling and route selection
Section titled “Attribute handling and route selection”Inter.link honours the Multi-Exit Discriminator (MED) received from a customer. An announcement without MED is treated as having MED 0. Inter.link does not use route dampening.
BGP communities and RTBH
Section titled “BGP communities and RTBH”Origin communities, traffic-engineering communities, the standard communities honoured by Inter.link, remote-triggered blackholing (RTBH), and the DDoS redirect community are defined in the separate BGP Communities document.
Policy updates and operational changes
Section titled “Policy updates and operational changes”Prefix filters are updated daily.
Maximum-prefix calculation and enforcement remain defined in the applicable IP Transit or FlexTunnel Technical Service Specification.
Responsibilities
Section titled “Responsibilities”| Activity | Inter.link | Customer |
|---|---|---|
| Route filtering | Builds and applies the standard IRR, RPKI, prefix, and AS-path policy | Announces only authorized routes that comply with the published policy |
| Routing data | Uses the supported mirrored IRR data and RPKI validation state | Maintains accurate route and route6 objects, AS-SET contents, ROAs, and address-space authorizations |
| BGP attributes | Applies the documented attribute handling | Sets MED as required for the customer’s intended routing policy |
| Policy verification | Operates the customer-facing routing policy | Verifies accepted routes and intended traffic engineering and reports discrepancies through the customer portal |
Service levels and support
Section titled “Service levels and support”Availability and performance commitments, incident priorities, response and restoration targets, maintenance rules, exclusions, remedies, and service credits are defined exclusively in the applicable SLA. Nothing in this informative specification changes those terms.