Where a member has an IRR filter, the route servers accept a prefix from it when the prefix is covered by the member’s registered IRR data, or when it has a valid ROA and an origin inside the member’s AS-SET. This page states what to register, how the filters are built and refreshed, and what happens when an object is missing.
Version 1.1, published 1 October 2026.
A route object for every IPv4 prefix and a route6 object for every IPv6 prefix announced to the exchange, with the correct origin ASN, plus an AS-SET that lists the member’s ASN and any downstream ASNs whose prefixes the member announces. The AS-SET name and the IRR database it lives in are recorded in the member’s IXP Manager profile at onboarding.
IXP Manager expands each member’s AS-SET with bgpq3 against the member’s registered IRR database (APNIC or RADb for most members) and generates per-member prefix lists and origin-AS lists for IPv4 and IPv6. The result is rendered into the configuration of RS1, which runs OpenBGPD, and into the configuration of RS2, which runs BIRD. Both route servers apply the same filtering policy.
IRR data is re-fetched on a fixed schedule and the route server filters are updated automatically in the next synchronisation cycle, so a new route object is normally accepted within 24 hours of registration without any request to the NOC. Register a prefix at least 24 hours before you announce it for the first time. If the registry cannot be reached, the last known good filter is kept for up to seven days and the NOC is alerted; a registry outage of less than seven days does not cause a member to be dropped.
A prefix with no covering route object in the member’s AS-SET expansion is rejected, unless it has a valid ROA and an origin inside that AS-SET. The rejected route stays visible in the looking glass with the reason, so the member sees it at once. An object registered with the wrong origin ASN is treated the same way. Fix the registry entry and the prefix is accepted at the next refresh.
IRR filtering and RPKI validation are separate checks. A prefix with an RPKI-invalid origin is rejected, whatever the IRR says. Where a member has an IRR filter, a prefix with a valid ROA is accepted when its origin is inside the AS-SET of the member, even without a route object, and a prefix without a ROA must be covered by a route object. Register a route object and a ROA for every prefix you announce. That is also what the MANRS network-operator actions ask of every member.
The NOC can check your AS-SET expansion, tell you which prefixes are currently accepted, and help you register missing objects. Share the affected prefixes, the AS-SET and the session details when you ask.
