CNX Documentation

Using the CNX RPKI validators

CNX operates three RPKI relying-party validators for directly connected IX members. Configure all three so one validator can be maintained without removing validation data from your router.

Configure all three validators. CNX operates the validators as a redundant service, not as individually guaranteed endpoints. CNX may remove one validator from service for routine rolling maintenance without customer notification. Configure and monitor all three RTR sessions so validation continues while an individual validator is unavailable. A configuration using fewer than all three is not fully redundant.

2001:df6:1441::d:7f48  TCP/3323
2001:df6:1441::2:d027  TCP/3323
2001:df6:1441::6:1ba7  TCP/3323

The RTR service is IPv6-only. Source each connection from the IPv6 address CNX assigned to your router on the peering LAN. Access from arbitrary Internet addresses is not provided.

1. Configure the RTR sessions

For each validator:

  • set transport to TCP;
  • set the remote port to 3323;
  • bind the local source to your CNX peering IPv6 address; and
  • load IPv4 ROAs, IPv6 ROAs, and ASPA data where the router supports them.

Do not configure rpki.cnx.net.kh as the router's RTR endpoint. That hostname is the HTTPS interface for human and API queries; the router-facing endpoints are the three addresses above.

2. Apply ROV to external routes

Classify received routes as:

  • Valid: a covering ROA authorizes the origin ASN and prefix length;
  • Invalid: a covering ROA does not authorize the origin or length; or
  • NotFound: no covering ROA is present.

Reject Invalid routes. Make the handling of NotFound routes explicit in your policy. Apply the check to route-server, bilateral, and transit imports rather than assuming that validation by one neighbor protects every ingress path.

3. Define validator-loss behavior

Configure refresh, retry, and expiry behavior appropriate for your platform. Monitor all three sessions and the age of the retained validation data. A TCP session being Established does not prove that the serial is advancing.

Decide how the router treats routes after validation data expires. Record this choice in the network's routing policy.

4. Verify

Confirm:

  • all three RTR sessions are connected;
  • IPv4 and IPv6 ROA tables contain records;
  • serials and refresh times advance;
  • a known Valid route is classified Valid;
  • a controlled Invalid test route is rejected; and
  • rejected routes remain observable in diagnostic output where the platform supports it.

Use rpki.cnx.net.kh to investigate a prefix from a browser. That view helps explain published RPKI data; the router's local state remains the evidence for its actual import decision.

Platform snippets

Cisco IOS XE

router bgp <YOUR_ASN>
 bgp rpki server tcp 2001:df6:1441::d:7f48 port 3323 refresh 600

route-map ROV deny 10
 match rpki invalid
route-map ROV permit 100

Repeat the server command for all three validators and insert the Invalid rejection into every external import policy. Do not enable prefix-validate allow-invalid.

Junos OS

set routing-options validation group CNX-RPKI session 2001:df6:1441::d:7f48 port 3323
set routing-options validation group CNX-RPKI session 2001:df6:1441::d:7f48 local-address <MEMBER_IPV6>
set policy-options policy-statement ROV term invalid from validation-database invalid
set policy-options policy-statement ROV term invalid then reject

Repeat the session for all three validators and place the rejection before the remainder of each external import policy.

Huawei VRP

rpki
 session 2001:df6:1441::d:7f48
  tcp port 3323
  connect-interface <MEMBER_IPV6>

bgp <YOUR_ASN>
 ipv6-family unicast
  prefix origin-validation enable
  bestroute origin-as-validation

Repeat the RPKI session for all three validators and enable origin validation in both BGP address families. Do not add allow-invalid.

See the complete Cisco IOS XE, Junos OS, and Huawei VRP configurations.

ASPA status

The validators publish ASPA payloads. CNX route-server ASPA enforcement is planned. Peer-side ASPA examples will be added after router vendors provide implementations that CNX can verify. Do not infer ASPA enforcement from a working ROA/RTR session.