Skip to main content
Cathrix Network

Peering Policy

Interconnection Guidelines and Requirements

Cathrix Network (AS62748) maintains an open, settlement-free peering policy.

Guidelines

We welcome peering with networks that satisfy the criteria below and share a mutual presence with us at an Internet Exchange Point (IXP) or supported colocation facility.

Our current IXP and facility presence is published on PeeringDB.

  • Route Servers (Default): We prefer peering via IXP route servers wherever available. Cathrix announces its standard routes to route servers and accepts eligible peer routes in accordance with our routing policy.
  • Direct Sessions: Direct bilateral BGP sessions over a shared IXP switching fabric may be established upon request where justified by technical, latency, or operational necessity.
  • Private Network Interconnect: Direct PNIs and physical cross-connects are evaluated based on traffic volume, capacity requirements, port availability, and mutual facility footprint. Please contact our NOC for more information.

Requirements

Tip

Compliance with these requirements does not guarantee peering. Settlement-free peering does not constitute an IP Transit service, carries no Service Level Agreement (SLA), and Cathrix reserves the right, at its sole discretion, to reject, suspend, or terminate any peering session at any time without liability.

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 /24 or shorter, or one IPv6 prefix of /48 or 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 INVALID state.
  • Routing Hygiene: Peers must not announce bogon, private, reserved, or otherwise non-routable prefixes, and shall neither include private nor reserved ASNs in the AS_PATH.

Operational

  • PeeringDB Record: Peers must maintain an accurate and current PeeringDB record, including NOC contact details, prefix limits, and facility presence.
  • Operations Contact: Both parties must provide an actively monitored NOC contact email address and commit to responding to operational routing incidents within a timely manner.
  • Traffic Routing Integrity: Peers must only route traffic across the peering session destined for prefixes announced by Cathrix. Setting default routes, pointing static routes, or utilizing the peering fabric to obtain unauthorized transit is strictly prohibited and will result in immediate session teardown.

Last Updated on October 22, 2026