Maharlika IX operates two independent route servers with the same default-deny filtering policy. A prefix that is not explicitly permitted is never redistributed. This policy supports Action 1 of the MANRS IXP Programme.
Version 1.1, published 1 October 2026.
| Check | Rule | If it fails |
|---|---|---|
| Next hop | Must be the address of the announcing member | Rejected |
| First AS in the path | Must be the ASN configured for the member | Rejected |
| AS path | No well-known transit networks, and no more than 64 ASNs | Rejected |
| Bogons | No private, reserved, documentation or other special-purpose space | Rejected |
| Prefix length | IPv4 from /8 to /24. IPv6 no longer than /48, and no default route | Rejected, except blackhole routes |
| IRR | Covered by a route or route6 object reached through the AS-SET of the member, or RPKI-valid with an origin inside that AS-SET | Rejected, where the member has an IRR filter |
| RPKI | Origin checked against ROAs. Valid and not found both pass | Rejected |
| Maximum prefixes | A limit per member | The session is closed and restarts later |
RS1 runs OpenBGPD and RS2 runs BIRD, both as AS9420. They are transparent (AS9420 does not appear in the AS path), support IPv4 and IPv6, and are built from different software so that a bug in one cannot silently affect the other. Peering with the route servers is optional; bilateral sessions between members remain each member’s own responsibility. Session addresses are in the welcome guide sent to each member.
The next hop of an accepted route must be the address of the announcing member; third-party next hops are rejected. The first AS in the path must be the member’s configured ASN. Paths of more than 64 ASNs are rejected, as are routes whose path traverses well-known transit networks (for example AS174, AS1299, AS2914, AS3356 and AS6453), which should never appear at a peering exchange.
Prefixes from private, reserved, documentation and other special-purpose space, such as the ranges of RFC 6890, are rejected for IPv4 and IPv6. Prefixes outside conventional global-routing bounds are rejected: IPv4 longer than /24 or shorter than /8, IPv6 longer than /48, and the IPv6 default route. The only exception is a remotely triggered blackhole, described below.
Each member’s accepted prefixes must be covered by route or route6 objects reachable by expanding the AS-SET registered for the member. Prefix lists are rebuilt from the IRR by IXP Manager on a fixed schedule and installed on both route servers, so a change is normally live within 24 hours. Prefixes not covered by the member’s IRR data are rejected. A prefix that is RPKI-valid and originates from an ASN inside the member’s AS-SET is accepted without a route object. A member can peer without an IRR prefix filter. Routes accepted from such a member carry the large community 9420:1001:2, IRR not checked, and pass every other check on this page. The looking glass shows which routes these are. If an IRR refresh fails, the last known good filter is kept for up to seven days and the NOC is alerted, so a registry outage of less than seven days does not cause a member to be dropped.
Every prefix is validated against RPKI using the RPKI-to-Router (RTR) feed from the exchange’s own Routinator validator. RPKI-invalid routes are rejected and never redistributed. Routes that are valid or not found are accepted, subject to all other checks. Conformance is verified with the official MANRS IXP validation tool; the latest run found zero unexpected RPKI-invalid routes.
Each session enforces a per-member maximum-prefix limit; exceeding it closes the session to protect the platform. The session restarts by itself after a few minutes. Members may blackhole a covered more-specific of their own prefix with the well-known BLACKHOLE community 65535:666. Blackhole routes are the one exception to the prefix-length bound. The route servers mark them NO_EXPORT, so that they stay inside the exchange, and each member decides in its own router whether to act on them. A blackhole route is one address, a /32 for IPv4 or a /128 for IPv6, inside a prefix that the IRR data of the member covers. A member whose IRR data is older than 24 hours cannot blackhole.
Rejected routes are tagged with informational large communities that record the reason (RPKI-invalid, IRR not found, AS-path invalid, bogon) and remain visible in the looking glass so the announcing member can see why a route was rejected. They are never re-advertised to other members. Accepted routes carry informational tags for their RPKI state (9420:1000:1 valid, 9420:1000:2 not found) and IRR state (9420:1001:1 valid, 9420:1001:2 not checked). A route that is accepted for its valid ROA carries the RPKI tag alone.
Documented control communities let a member restrict export to selected peers or prepend towards them. Policy changes are validated on a test instance, deployed in stages with health checks and rollback, and announced to members in advance. Questions about filtering, IRR or RPKI acceptance, or blackholing go to the NOC.
