How CNX builds route-server policy
CNX generates route-server configuration from participant assignments and public routing datasets. The participant controls the public authorization data; CNX controls the session inventory, policy generation, and deployment.
| Data | Owner | Route-server use |
|---|---|---|
| ASN and assigned peering addresses | CNX participant configuration | Creates the member sessions and binds routes to the expected source |
| Per-session options | CNX participant configuration | Enables agreed features such as GTSM, BFD, or a policy exception |
| Route-server nodes and router IDs | CNX infrastructure inventory | Produces one configuration for each route server |
| PeeringDB AS-SET and prefix counts | Participant | Selects the AS-SET and derives maximum-prefix policy |
| IRR route objects and AS-SET membership | Participant and downstreams | Builds authorized origin-AS and prefix sets |
| RPKI ROAs | Resource holder | Performs origin validation and can supplement missing IRR route objects |
| ASPA objects | ASN holder | Supplies provider authorization data for future AS-path validation |
| BGP routes and large communities | Participant router | Supplies current reachability and propagation instructions |
The build produces:
- BIRD configuration for each route server;
- a human-readable route-server policy;
- an IX-F member export; and
- the CNX route-server-client AS-SET representation used for registry updates.
Participant and inventory records
+
PeeringDB, IRR, ROA and ASPA data
|
v
route-server policy build
|
+--> per-server BIRD configuration
+--> published policy reference
+--> IX-F member data
+--> CNX participant AS-SET
A change in PeeringDB, IRR, or RPKI is not a direct edit to a running route server. The upstream record must be published, collected, incorporated into a configuration build, and deployed through the CNX operational process.
If a route is rejected, correct the authoritative participant dataset rather than relying on an undocumented route-server exception.