Peering Policy
Interconnection Guidelines and Requirements
Cathrix Network maintains an open peering policy.
Guidelines
We welcome peering with networks that meet the requirements below and share a mutual presence with us at an Internet Exchange Point (IXP) or supported interconnection facility.
Our current IXP and facility presence is published on PeeringDB.
- Route Servers (Default): We prefer peering through IXP route servers where available. Standard routes are announced to route servers, and eligible routes are accepted in accordance with our routing policy.
- Direct Sessions: Direct bilateral BGP sessions over a shared IXP fabric may be established upon request where there is a reasonable technical or operational justification.
- Private Network Interconnect: PNIs and physical cross-connects are evaluated based on traffic volume, capacity, facility availability, and port availability. Please contact our Network Operations Centre (NOC) for more information.
Requirements
Important
Compliance with these requirements does not guarantee peering. Cathrix Network reserves the right, at its sole discretion, to reject any peering request or suspend or terminate any peering session at any time.
Technical
- Public ASN: Peers must operate a publicly routable and visible Autonomous System Number (ASN).
- Minimum Prefix Size: Peers must announce at least one publicly routable IPv4 prefix of
/24or shorter, or one IPv6 prefix of/48or shorter. - IRR Registration: Peers must register all announced prefixes in an authoritative Internet Routing Registry (IRR), including APNIC, RIPE NCC, ARIN, AFRINIC, LACNIC, and RADb, and keep the corresponding routing information accurate and current.
- RPKI Validation: Peers must maintain appropriate Route Origin Authorizations (ROAs) for all announced prefixes. Cathrix performs RPKI Route Origin Validation (ROV) and rejects prefixes with an
INVALIDstate. - Routing Hygiene: Peers must not announce bogon, private, reserved, or otherwise non-routable prefixes, and shall neither include private or reserved ASNs in the AS_PATH.
Operational
- PeeringDB: Peers must maintain an accurate and current PeeringDB record, including interconnection information, NOC contacts, prefix limits, and AS-SET information.
- Operational Contact: Both parties must maintain a monitored NOC contact email address and commit to responding to operational incidents within a reasonable timeframe.
- Traffic Routing: Peers must only send traffic for destinations announced by Cathrix over the applicable BGP session. Static routes, default routes, or other mechanisms intended to obtain unauthorized IP transit are prohibited.
Last Updated on August 26, 2026