Securing Your Border Router: Filtering Unwanted Announcements

Filtering announcements at your border router is one of the better defenses you have against route hijacking, accidental leaks, and upstream neighbors who misconfigure things. And misconfigured things happen constantly. IPv4 scarcity keeps pushing address blocks from one organization to another, which means your routing perimeter shifts more often than most operators admit — and every unfiltered session is an open door for bad routes, both coming in and, worse, going out and propagating worldwide. This guide walks through how to harden your border router step by step, from understanding your exposure to writing prefix-lists and route-maps that actually enforce your policy.

Why New IPv4 Space Is Vulnerable to Route Hijacking

Recently transferred IPv4 blocks are prime targets for hijackers, and it’s not a coincidence — it’s structural. When a block moves from one organization to another, routing databases such as IRR registries and RPKI repositories often lag behind the official transfer records. During that gap, the legitimate new owner announces the prefix while legacy route objects still point at the previous holder. Ambiguity, in other words. Exactly the kind hijackers go looking for.

• Stale IRR objects: Aut-num and route objects referencing the old holder cause downstream networks to filter the legitimate announcement while accepting a fraudulent one from somewhere else entirely.
• Missing ROAs: No RPKI authorization means anyone can announce the prefix, and validating networks have no cryptographic basis to reject the impostor.
• Inactive prefix detection: Hijackers scan for allocated but unannounced space — a common situation for buyers who purchase blocks and then delay deployment. An unannounced /24 is silent prey.

Practical advice? The moment you acquire IPv4 space, update your IRR objects, create ROAs for every prefix and its common sub-prefixes (a /24 ROA with maxLength 24 is the usual minimum), and start announcing promptly. Marketplaces such as IP4 Market support buyers through this transition by ensuring clean, documented transfers with verified sellers — a critical first step, since blocks with disputed provenance attract both registry scrutiny and hijack attempts.

Understanding BGP Announcements and Prefix Visibility

Before you can filter anything, you need to know what your network is actually announcing. And accepting. BGP is chatty by design: every session exchanges the full table (roughly 950,000+ IPv4 routes today), and a single misconfiguration can silently export prefixes you never intended to originate.

1. Audit your own origins. Use looking glasses and services like RIPEstat or RouteViews to confirm exactly which prefixes the world sees from your ASNs. Unexpected sub-prefixes — a /25 leaking out of an internal summarization error — are surprisingly common.
2. Monitor inbound received routes. Log everything accepted from each peer for at least a week. You will almost certainly find more-specific prefixes, martian space, and routes you have no business path for.
3. Track your visibility. Routing analytics platforms (BGPlay, GRIP, Cloudflare Radar) let you spot third parties announcing overlapping space before customers notice blackholing.

Filtering Unwanted Announcements: Prefix-Lists and Route-Maps Explained

The core mechanism here is a two-layer approach: prefix-lists define what is permitted, and route-maps define how matches are handled and what attributes get applied.

Outbound, maintain a prefix-list of only the prefixes you’re authorized to originate, and apply it to every eBGP neighbor. Never rely on a default “advertise what’s in the table” posture. One redistributed static or connected route can leak an entire customer’s space to the internet. Inbound, deny bogons and your own prefixes coming back at you, then apply per-peer filters based on the peer’s authorized prefixes — ideally generated from IRR data with tools like bgpq4.

Applied consistently on every session, this layered filtering turns your border router from a passive conduit into an active policy enforcement point. Which is where it should have been all along.

Implementing RPKI and ROA Validation for Your Prefixes

Of all the defenses against prefix hijacking, Route Origin Authorization (ROA) statements — published through the RPKI framework — are the ones that actually bite. A ROA is a cryptographic declaration of which Autonomous System (AS) is allowed to originate a given prefix, plus the maximum prefix length permitted. Once it’s out there, relying parties (major transit providers, big content networks, the operators who matter) can automatically reject any announcement that violates it.

Publishing ROAs correctly

• Set maxLength precisely: If you announce 203.0.113.0/24 as a single prefix, maxLength should be 24. Nothing more. An overly permissive maxLength of 32 hands an attacker the ability to announce deaggregated subprefixes — and those can end up preferred over your legitimate route.
• Cover every announced prefix: Check that each prefix in your allocations has a valid ROA, including any more-specifics you use for traffic engineering. One missing ROA and that route sits classified as “NotFound.” Vulnerable.
• Update before re-homing: Moving address space or switching upstreams? Publish the new ROA before withdrawing the old one. Otherwise you’ve created a validation gap for no reason.

Enforcing RPKI on your own border

There’s a flip side to this, and it’s the one people forget. Publishing ROAs protects your prefixes; enforcing RPKI protects everyone else, including you. Run RTR synchronization against one or more trusted RPKI validators (Fort, FRR’s built-in RTR, a Routinator instance — any of them work) and apply origin validation on all your eBGP sessions. Drop “invalid” routes outright, and think about depreferring “unknowns” until global coverage improves. It’s a stronger posture than static allow-lists, because you’re working with cryptographic proof instead of a list someone hand-maintained and forgot to update.

Monitoring and Detecting Unauthorized BGP Announcements

Filtering and RPKI handle your outbound policy. But they won’t tell you when someone else is out there announcing your space. Only continuous monitoring catches hijacks, leaks, and misconfigurations in near real time.

Practical detection methods

• Route collectors and looking glasses: RIPE RIS, RouteViews, commercial platforms like RIPEstat, BGStream, or Cloudflare Radar — all let you query the global visibility of your prefixes. Schedule regular checks for origins and AS-paths you don’t recognize.
• Automated alerting: Set up alerting tools — ARIN/RIPE alarm services, Monarb, ARTEMIS — so you get notified the moment your prefix shows up with an unexpected origin AS. This matters more than it sounds: fast detection can shorten a hijack from hours to minutes.
• RPKI invalid monitoring: Keep an eye out for your prefixes being flagged “invalid” by third parties. That usually means someone announced your space without authorization.
• Peering session telemetry: Sudden changes in announced prefix counts, unexpected route refreshes, a spike in withdrawals from a peer — in my experience these quiet anomalies are often the first sign of a leak upstream of you.

Responding to a hijack

So it happened. An unauthorized announcement is live. Now what? Contact the originating AS’s NOC immediately (abuse and peering contacts are in WHOIS or PeeringDB), notify your transit providers, and double-check that your own ROA is accurate — if it is, RPKI-invalid filtering works in your favor and containment spreads on its own. And document everything: timestamps, affected prefixes. Your post-incident review will thank you.

Conclusion: Building a Secure Routing Foundation for Your IPv4 Space

Securing a border router isn’t a single configuration. It’s a discipline — strict prefix filters on every session, max-prefix limits, IRR-based policy, RPKI both published and enforced, monitoring running continuously to close the loop. Each layer covers the blind spots of the others. Together, they cut your exposure to hijacks, leaks, and plain accidental outages down to something you can actually live with.

The same rigor applies to acquisition, by the way. If your organization is building or expanding its IPv4 holdings, verify prefix provenance, confirm a clean routing history, and make sure RPKI resources transfer correctly. IP4 Market provides a trusted platform for IPv4 transactions, with verified sellers, full due-diligence support, and competitive pricing — so the space you secure at the border is space you acquired with confidence.