RPKI policy

Both route servers perform RPKI route origin validation on every announcement, using the RPKI-to-Router (RTR) feed from the exchange’s own Routinator validator.

Version 1.1, published 1 October 2026.

Valid

Accepted and redistributed to members, subject to the origin-AS, bogon, AS-path and next-hop checks in the route server policy. A valid ROA takes the place of a route object for a member with an IRR filter. Tagged with the informational large community 9420:1000:1.

Invalid

Rejected on both route servers and never redistributed to any member. The rejected route stays visible in the looking glass tagged 9420:1101:13 so the announcing member can see why it was rejected.

Not found

Accepted, subject to the IRR filter and the other checks of the route server policy. Tagged 9420:1000:2. Members are encouraged to create ROAs so their prefixes validate as RPKI-valid.

Validator and data

Validation data comes from a Routinator instance operated by the exchange, feeding both route servers over RTR. It refreshes about every 10 minutes from the five RIR trust anchors. Members can inspect the RPKI state of any route in the looking glass.

Verification

Conformance is checked with the official MANRS IXP validation tool against the public looking glass API and the full set of validated ROA payloads. Latest run: 1 October 2026 (UTC). Zero unexpected RPKI-invalid routes on RS1 and RS2.

Create your ROAs

Publish ROAs for every prefix you announce, with the correct origin ASN and a max-length that matches what you actually announce. Over-broad max-lengths invite hijacks of more-specifics; missing ROAs leave your prefixes as not found.