MANRS at Maharlika IX

Maharlika IX has been a participant in the Mutually Agreed Norms for Routing Security (MANRS) IXP Programme since 28 September 2026. This page states what the exchange enforces, how it is verified, and what we ask every member to do on their own network.

Version 1.1, published 1 October 2026.

Our commitment

Route hijacks, route leaks and address spoofing are the most common routing security problems. Most can be prevented. As a MANRS participant, Maharlika Connect Inc., the operator of Maharlika IX, whose route servers run as AS9420, commits to the actions of the MANRS IXP Programme and promotes MANRS to its members. MANRS lists the exchange, as Maharlika Internet Exchange, for Actions 1, 2, 4 and 5.

Action 1: filtering on the route servers

Both route servers (RS1 OpenBGPD, RS2 BIRD) filter every announcement before it is redistributed: IRR prefix filters built from each member’s AS-SET, RPKI route origin validation that rejects invalid routes, bogon filtering, AS-path and next-hop checks, and per-session maximum-prefix limits. Rejected routes are tagged and visible in the looking glass but never re-advertised. A member can peer without an IRR prefix filter. Its accepted routes are then marked 9420:1001:2, IRR not checked.

Verification

Route server RPKI conformance is checked with the official MANRS IXP validation tool, reading our public looking glass API against the full set of validated ROA payloads from the exchange’s own RPKI validator. Latest run: 1 October 2026 (UTC). All routes carried by RS1 and RS2 were checked against the 1,016,601 validated ROA payloads of that run, and zero unexpected RPKI-invalid routes were found. The run covered every route then carried by the two route servers. The report of the latest run is available on request.

Action 2: what we ask of our members

Adopt the four MANRS actions for network operators.

  • Filter what you announce and what you accept from customers and peers.
  • Deploy source-address validation (BCP 38 and uRPF), so that spoofed packets cannot leave your network.
  • Keep your PeeringDB, IRR and RIR contacts current.
  • Publish your routing data: register route and route6 objects, an AS-SET and RPKI ROAs for every prefix you originate.

Register your routing data before you peer with our route servers: the prefix filters are built from it. Where a member has no IRR filter yet, its accepted routes are marked 9420:1001:2.

Action 3: a protected peering platform

The peering LAN carries only IPv4, IPv6 and ARP between member routers and the route servers. One MAC address per port is enforced; routing protocols, tunnels, DHCP, SNMP and privately addressed traffic are dropped at the member port; broadcast and multicast are rate-limited; and spanning-tree BPDUs disable the port. These rules are in force on the platform. Action 3 is not yet part of our listing with MANRS.

Actions 4 and 5: coordination and tools

Our NOC is reachable at noc@maharlikaix.ph and through the contacts published on this site, so any operator can reach us quickly during a routing incident. The public looking glass shows every route seen by the route servers, including rejected routes and their RPKI state.

MANRS participants on the exchange

Members already listed as MANRS network-operator participants carry a MANRS label in our list of connected networks. The label is driven by the official MANRS participant list, refreshed weekly, so new participants appear automatically. We encourage every other member to join.

Get started

Learn about MANRS and join at manrs.org, then check the score of your network in the MANRS Observatory. Need help registering IRR objects, creating ROAs, or reading a filtering result in the looking glass? Contact the Maharlika IX NOC.