How the CNX Exchange works

CNX is a Layer-2 Internet Exchange Point. It provides a shared Ethernet fabric on which independently operated networks exchange traffic directly. The fabric forwards packets between members; CNX does not become an IP transit provider or sit in the forwarding path.

When two connected networks exchange their own routes, traffic between them stays on the exchange rather than passing through an upstream transit network. This keeps domestic traffic inside Cambodia where both networks are present, reduces latency and transit use, and provides an additional path during external network disruption.

Control plane and data plane

CNX route servers distribute routing information between members. They operate only in the BGP control plane: traffic continues to flow directly between the members' routers across the Layer-2 fabric.

All members establish sessions with the route servers for baseline multilateral reachability. Members retain control over which routes they announce, how they select received routes, and whether they establish additional bilateral sessions. CNX BGP communities allow a member to control route-server propagation without requiring a separate session with every participant.

Routing integrity

CNX builds route-server policy from public routing data rather than private prefix exceptions. Announcements are checked against Internet Routing Registry objects, hierarchical AS-SETs, Route Origin Authorisations, prefix-length rules, and configured limits. RPKI-invalid routes are rejected.

Members remain responsible for publishing accurate routing information, maintaining ROAs and AS-SETs, and exporting only routes they are authorised to announce. The binding requirements are defined in the Technical Requirements and Peering and Route-Server Policy.

Directly connected members can also use CNX's redundant RPKI validator service to perform Route Origin Validation on routes learned from the route servers, bilateral peers, and transit providers. The validator service is reached over the member peering network and is not exposed as a general public RTR service.

Connecting

A connection consists of a physical or metro-fibre handoff, an assigned service VLAN and peering addresses, BGP sessions to the CNX route servers, and published routing data that authorises the member's announcements. The connection section describes commercial and facility options.

Router configuration, route-server endpoints, community values, routing-data publication, RPKI validator setup, platform examples, and verification procedures are maintained in the technical documentation.