CNX Documentation

Route-server service

Endpoints

CNX route-server ASN: 132213

Route serverIPv4IPv6
rs01.cnx.net.kh103.7.144.12001:de8:1d::1
rs02.cnx.net.kh103.7.144.22001:de8:1d::2
rs03.cnx.net.kh103.7.144.32001:de8:1d::3

Use every endpoint. CNX performs routine maintenance by rotating work across the three route servers. An individual server may be unavailable during this rolling maintenance without customer notification. Members must establish and monitor IPv4 and IPv6 sessions with all three servers; no single endpoint is intended to provide the service by itself.

Peering networks:

IPv4: 103.7.144.0/24
IPv6: 2001:de8:1d::/64

Use the member addresses supplied in your CNX connection record. Do not infer an assignment from an unused-looking address.

Session behavior

  • Route-server sessions are passive; members initiate TCP/179.
  • AS132213 is not prepended to redistributed routes.
  • Members must disable first-AS enforcement where their platform enables it.
  • The original member next hop is preserved.
  • Standard and large communities are preserved, subject to policy processing and internal control-community scrubbing.
  • Add-Path transmit capability is enabled toward members.
  • Path-hiding mitigation is enabled.
  • ROV is enabled and RPKI Invalid routes are rejected.
  • ASPA verification is planned but currently disabled.
  • Maximum-prefix action is session shutdown.

Establish both address families with all three route servers and advertise the same intended prefix set to each.

Prefix limits

The general accepted prefix-length range is:

IPv4: /8 through /24
IPv6: /12 through /48, within 2000::/3

CNX learns member maximum-prefix values from participant configuration or PeeringDB. Where no specific value is available, the generated policy uses a general limit of 1,000 IPv4 and 1,000 IPv6 routes.

The CNX peering networks and their more-specific routes are rejected. Default, bogon, reserved, private, and policy-blacklisted prefixes are also rejected.

Optional session features

GTSM and BFD are enabled only when agreed for a particular session. Do not enable them unilaterally. BFD to a route server measures control-plane session reachability, not the member-to-member forwarding path.