Peer1IX
Internet Exchange
Services

Interconnection

Internet ExchangeMicro PoPsEdge Data Centers

Network Services

Data Center to Data CenterVirtual Connectivity HubData Center to CloudCloud to CloudPeer1ix Cloud RouterPeer1ix Virtual EdgeNAT GatewayPeer1ix PortVirtual Cross Connect

Security Services

DDoS ProtectionPeer1ix FWaaSIPsec Tunnel

Cloud Interconnect

Cloudflare Network Interconnect
Locations
Network toolsAll-in-One Network ReportBGP Looking GlassRPKI ValidatorBGP Security & Hijack CheckIP WHOISAS WHOISBGP Route ExplorerASN InsightsBGP Hijacks & Route LeaksInternet Outage TrackerCountry Internet InsightsTop Domains RankingDNS LookupSubnet CalculatorWhat Is My IP
BlogAboutContact Get connected

MANRS, RPKI and Filtering: How an Exchange Keeps Routing Safe

· 2 min read · Peer1IX Team

MANRS, RPKI and Filtering: How an Exchange Keeps Routing Safe

Exchanges sit at the crossroads of many networks, which makes them a powerful place to stop bad routes. Here is how Peer1IX applies routing-security best practice.

The problem with trust

BGP, the protocol that glues the internet together, was designed for a small community of networks that trusted each other. By default, a router accepts what its neighbour tells it. That is how route leaks and hijacks spread: one misconfigured or malicious announcement can be accepted and passed on until it affects traffic far away.

Why exchanges matter

An exchange route server talks to many networks at once. If it accepts a bad route, it can distribute that route to dozens or hundreds of members. Equally, if it filters well, it protects all of them at once. That makes the exchange one of the most effective places to apply routing security.

What Peer1IX route servers check

  • RPKI origin validation. If a ROA says a prefix may only be originated by a particular ASN, any other origin is invalid and is dropped. Announcements more specific than the ROA’s maximum length are dropped too.
  • IRR filtering. We build prefix filters from Internet Routing Registry data. A member can only announce prefixes covered by route objects for its own ASN or its customers’ ASNs.
  • Bogon prefixes. Private, reserved, documentation and unallocated ranges are rejected.
  • Bogon ASNs. Paths containing private or reserved ASNs are rejected.
  • Max-prefix limits. Sessions are protected against accidental full-table leaks.

MANRS alignment

The Mutually Agreed Norms for Routing Security (MANRS) set out practical actions for operators and exchanges: filtering, anti-spoofing, coordination and global validation. Peer1IX applies these practices on its route servers and encourages members to adopt them on their own networks.

What members should do

  • Publish accurate ROAs for all your prefixes.
  • Keep route objects and as-sets up to date.
  • Filter what you accept from bilateral peers, not just from the route server.
  • Implement anti-spoofing (BCP 38) on customer-facing interfaces.
  • Keep contact details current so others can reach you during incidents.

Check yourself

You can see how your network looks to the world with our free BGP security check. It reports RPKI coverage, invalid announcements, bogons and recent hijack or leak events involving your ASN.

MANRSRPKIroute filteringrouting security