CNX Documentation

Publishing routing data

Publish routing data before announcing a new prefix or downstream ASN. CNX derives route-server filters from public routing registries and RPKI; a BGP announcement does not override those authorizations.

The examples use documentation resources:

ASN: AS64496
IPv4: 203.0.113.0/24
IPv6: 2001:db8:100::/48
AS-SET: AS64496:AS-CUSTOMERS

1. Publish IRR route objects

Create a route object for IPv4 and a route6 object for IPv6 in the authoritative IRR for your resources:

route: 203.0.113.0/24
origin: AS64496
source: APNIC
route6: 2001:db8:100::/48
origin: AS64496
source: APNIC

Use your RIR's portal and maintainer fields. The origin must match the ASN that appears at the end of the advertised AS_PATH.

2. Maintain a hierarchical AS-SET

If you announce only prefixes originated by your own ASN, an AS-SET may not be needed. If you announce downstream routes, publish a hierarchical set and keep every authorized downstream ASN in it:

as-set: AS64496:AS-CUSTOMERS
members: AS64501, AS64502
source: APNIC

Reference the set in the IRR as-set/route-set field of your PeeringDB network record. Remove a downstream when the routing relationship ends.

3. Publish ROAs

Create a ROA for every originated prefix. Set maxLength to the longest prefix you actually intend to announce, rather than automatically permitting all more specific routes:

Prefix: 203.0.113.0/24
Origin ASN: AS64496
Max Length: 24
Prefix: 2001:db8:100::/48
Origin ASN: AS64496
Max Length: 48

A route with a different origin or a prefix length beyond maxLength is RPKI Invalid and is rejected by the CNX route servers.

4. Keep PeeringDB current

Maintain:

  • the hierarchical AS-SET name;
  • realistic IPv4 and IPv6 prefix counts;
  • NOC and policy contacts; and
  • current peering policy.

CNX uses PeeringDB data when deriving AS-SET and maximum-prefix policy. A maximum-prefix limit supplied directly in CNX's participant configuration can override the PeeringDB-derived value.

5. Publish ASPA when available

Use your RIR's RPKI service to publish the providers authorized for your ASN. ASPA objects are available through the CNX validators. CNX route-server ASPA enforcement is planned and is not active yet.

Publishing accurate ASPA data now prepares the path for validation without requiring a later inventory exercise. Remove providers when the corresponding relationship ends.

6. Verify before announcing

Use rpki.cnx.net.kh to inspect RPKI validation and query the relevant IRR and PeeringDB records. Allow for registry publication and route-server configuration generation before expecting a policy change to take effect.