Route Server at CNX

Route Server Technical Details

ASN: 132213

IPv4 Peering Subnet: 103.7.144.0/24

  • rs01.cnx.net.kh — 103.7.144.1
  • rs02.cnx.net.kh — 103.7.144.2
  • rs03.cnx.net.kh — 103.7.144.3

IPv6 Peering Subnet: 2001:DE8:1D::/64

  • rs01.cnx.net.kh — 2001:DE8:1D::1
  • rs02.cnx.net.kh — 2001:DE8:1D::2
  • rs03.cnx.net.kh — 2001:DE8:1D::3

Operational Characteristics

  • Route servers operate in transparent AS_PATH mode (no ASN insertion).
  • Participants must disable first-AS enforcement
    (e.g. no bgp enforce-first-as on Cisco, undo check-first-as on Huawei).
  • Sessions are passive; participants must initiate the TCP connection.
  • IPv4 prefixes longer than /24 are rejected.
  • IPv6 prefixes longer than /48 or shorter than /16 are rejected.
  • Maximum prefix count enforced as per PeeringDB record.
  • IRR and RPKI validation enforced.
  • Standard and large communities preserved.
  • Participants must peer with all route servers and announce identical prefix sets to each.
  • The CNX peering LAN must never be announced.

Supported Features

  • Large BGP Communities
  • RPKI Route Origin Validation (ROV)
  • Features Available on Request
    • GTSM (Generalized TTL Security Mechanism)
    • BFD (Bidirectional Forwarding Detection)

Operational References

Architectural Model

The CNX route servers operate exclusively in the BGP control plane.

Participants establish BGP sessions with the route servers and exchange network layer reachability information (NLRI) and associated path attributes. Each participant independently applies its own BGP decision process to construct its routing table and forwarding entries. Traffic exchanged between CNX members flows directly across the Layer-2 exchange fabric. The route servers do not participate in packet forwarding and are not present in the forwarding path between participants.

The route server’s function is limited to receiving, validating, processing supported community signaling, and redistributing routing information.

Control plane vs data plane at CNX Route Server

Control-plane exchange occurs via the route server. Traffic flows directly between participant networks.

BGP Exchange Model at CNX

The interaction between participants and the CNX route servers follows a defined processing model.

What You Announce to CNX

Participants announce:

  • Their own originated prefixes,
  • Downstream prefixes authorized via IRR AS-SET,
  • Standard and large BGP communities,
  • Associated path attributes (AS_PATH, NEXT_HOP, MED, etc.).

Announcements are received by the route servers over established BGP sessions.

Technical Validation Performed by CNX

Upon receipt, the route servers apply technical validation before redistribution.

This includes:

  • Origin AS authorization via IRR / AS-SET,
  • RPKI origin validation,
  • Prefix-length limits,
  • Maximum prefix count enforcement,
  • AS-path sanity validation,
  • Basic NEXT_HOP and AFI validation.

Routes failing validation are rejected and marked with reject-reason communities (visible via looking glass and debugging tools). Routes passing validation proceed to redistribution.

Community-Based Signaling and Segmentation

CNX route servers support community-based signaling for route management.

Participants may attach supported communities to:

  • Control route propagation to specific peers,
  • Trigger AS-path prepending toward specific peers,
  • Influence announcement toward domestic or non-domestic participants.

The route servers interpret these supported communities and apply propagation rules accordingly. In addition, CNX attaches communities to redistributed routes to indicate:

  • Domestic or non-domestic origin,
  • IRR / AS-SET validation state,
  • RPKI validation state,
  • Reject reasons (for debugging and analysis).

These communities enable participants to apply their own routing policy based on transparent validation and segmentation signals.

What CNX Redistributes

For routes that pass technical validation, the route servers redistribute reachability information to other participants according to the CNX route server policy and any supported community-based signaling attached by the announcing participant.

In practice this means:

  • Routes are redistributed broadly by default.
  • CNX does not aggregate, collapse, or reduce multiple valid paths into a single selected route.
  • Redistribution can be limited or modified when the announcing participant attaches supported communities that:
    • suppress advertisement globally or toward specific peers,
    • control domestic vs non-domestic propagation,
    • request AS-path prepending toward specific peers.

When a route is redistributed:

  • The original AS_PATH is preserved (transparent AS_PATH behavior).
  • Standard and large communities are preserved unless explicitly interpreted for supported propagation control.
  • CNX adds communities that signal validation state and segmentation (for example domestic/non-domestic origin and RPKI state).

The route servers do not select a single best path on behalf of participants. Participants receive the set of redistributed paths permitted by policy and signaling and apply their own BGP decision process locally.

Community-Based Propagation Control

CNX route servers support standard and large BGP communities that allow participants to influence how their prefixes are propagated within the exchange environment.

Participants may use supported communities to:

  • Suppress advertisement of a prefix globally or toward specific peers,
  • Control propagation toward domestic or non-domestic participants,
  • Request AS-path prepending toward specific peers or toward all peers,
  • Signal operational states such as graceful shutdown.

These communities affect how and where a route is redistributed by the route servers.

CNX also attaches communities to redistributed routes to signal:

  • POP site local peers,
  • Domestic or non-domestic origin,
  • IRR / AS-SET validation status,
  • RPKI origin validation state,
  • Reject reasons (visible in diagnostic tools).

Community signaling provides a structured and transparent mechanism for participants to manage route visibility and exchange behavior within the CNX platform.

The complete list of supported communities and their semantics is available here:

Multilateral Peering Model

In a bilateral peering model, each participant must establish a separate BGP session with every other participant. As the number of networks increases, the number of required sessions grows proportionally. The CNX route servers enable a multilateral peering model. Each participant establishes a BGP session with the route servers rather than with every other network individually.

Bilateral vs Route Server peering model

Left: Bilateral peering model. Right: Multilateral peering via CNX route servers.

This approach:

  • Reduces configuration overhead,
  • Simplifies onboarding,
  • Ensures consistent technical validation,
  • Scales efficiently as membership grows.

Traffic exchange remains direct between member networks.

Participant Responsibilities

Participants are responsible for:

  • Maintaining accurate IRR and ROA records,
  • Announcing only authorized prefixes,
  • Establishing sessions to all CNX route servers,
  • Announcing identical prefix sets to each route server,
  • Disabling first-AS enforcement,
  • Sending required communities where applicable,
  • Ensuring local policy reflects intended routing behavior.

Each participant retains full control over its routing decisions and forwarding policy.

Control-Plane and Data-Plane Separation

The CNX route servers operate as a control-plane service within the exchange environment. They distribute validated routing information among participants. Forwarding behavior is determined entirely by each participant’s router based on its locally computed routing table. Packets exchanged between members traverse the Layer-2 fabric directly between networks. This separation ensures that CNX provides neutral interconnection infrastructure while preserving full routing autonomy for all participants.

Platform Architecture and Change Management

The CNX route server platform is generated and deployed through an automated build process. The current routing platform consists of approximately 220,000 lines of generated configuration. This scale reflects:

  • More than 50 peering partners,
  • Over 100,000 advertised routes,
  • Technical validation logic applied consistently to every participant,
  • Distribution across three independent route server instances.

Each participant’s policy expands into structured control logic once authorization checks, prefix validation, and safety limits are applied. Even a single participant’s configuration may result in over 1,000 lines of generated platform configuration when fully rendered across all route servers.

To ensure stability and consistency:

  • All configuration changes are applied through the automated build system.
  • No manual or ad-hoc changes are performed directly on route server instances.
  • Configuration rebuilds and route server process reloads are scheduled and monitored.
  • Deployments occur during controlled maintenance windows with engineering supervision.

This operational model ensures:

  • Deterministic behavior across all route servers,
  • Consistent validation logic,
  • Protection of the shared exchange environment,
  • Stability for all participants.

The CNX route server infrastructure is operated as a shared national interconnection platform. Change management practices are designed to maintain predictable behavior and prevent unintended impact across the broader peering ecosystem