MANRS IXP programme
The checklist, with status.
We treat the five actions of the MANRS IXP programme as acceptance criteria rather than as a badge. This page says what is in place and what is not, and it is updated with every change rather than when it flatters us.
The programme asks an exchange to meet three of the five, and makes the first two mandatory. Four are in place. The second counts as met on its first part, which is the one the programme requires; the rest of that row is what we have not done yet.
Actions
Where each one stands
| Action | How we meet it | Status |
|---|---|---|
| Action 1 · Prevent propagation of incorrect routing information | Both route servers reject RPKI-invalid routes and anything whose prefix and origin are absent from the member's AS-SET, alongside bogons, other exchanges' peering LANs, next-hop and first-ASN checks. The filters are rebuilt every ten minutes from PeeringDB, the IRR and RPKI. Every rejected route keeps a community naming the check it failed. | in force |
| Action 2 · Promote MANRS in the membership | The rejection causes tell a member exactly which registry object is missing, and the requirement for route6 objects or a covering ROA is stated before anyone connects. | partial: member list does not yet show MANRS participation |
| Action 3 · Protect the peering platform | A member port accepts only the MAC they registered and only their own LAN address as source. Router advertisements, DHCPv6, spanning tree, LLDP and discovery protocols are dropped, multicast is rate-limited, and a departed member's address is answered for. | in force; AS0 ROA for the peering LAN still pending |
| Action 4 · Facilitate global communication and coordination | Operations, peering and abuse addresses are published here, in our PeeringDB network record and in our RIR objects. The acceptable use policy binds members to answer abuse notices within 24 hours, and binds us to disconnect a member found hijacking within the hour. The membership is published as a directory and as an IX-F export. | not met: no telephone number published, and no PeeringDB exchange record until three networks are connected |
| Action 5 · Provide monitoring and debugging tools | A public looking glass showing every route both servers hold and the reason behind every one they rejected, exchange-wide traffic figures, and each member's own graphs in the portal. | in force |