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 \u2014 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.<\/p>\n
Recently transferred IPv4 blocks are prime targets for hijackers, and it’s not a coincidence \u2014 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.<\/p>\n
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 \u2014 a critical first step, since blocks with disputed provenance attract both registry scrutiny and hijack attempts.<\/p>\n
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.<\/p>\n
The core mechanism here is a two-layer approach: prefix-lists define what<\/em> is permitted, and route-maps define how<\/em> matches are handled and what attributes get applied.<\/p>\n 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 \u2014 ideally generated from IRR data with tools like bgpq4.<\/p>\n Tip:<\/strong> Combine prefix-lists with route-maps so you can set local-preference, add communities, or tag accepted routes. And keep your filters in version control, so policy changes get reviewed rather than improvised at 2 a.m.<\/p>\n<\/div>\n 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.<\/p>\n Of all the defenses against prefix hijacking, Route Origin Authorization (ROA) statements \u2014 published through the RPKI framework \u2014 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.<\/p>\n 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 \u2014 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.<\/p>\n 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.<\/p>\n 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 \u2014 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.<\/p>\n Tip:<\/strong> Test your detection pipeline deliberately. Announce a test prefix with a bogus origin from a lab environment and verify your alerts fire within minutes. An untested monitoring setup is an unproven one \u2014 and unproven means it will fail exactly when you need it.<\/p>\n<\/div>\n Securing a border router isn’t a single configuration. It’s a discipline \u2014 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.<\/p>\n 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 \u2014 so the space you secure at the border is space you acquired with confidence.<\/p>\nImplementing RPKI and ROA Validation for Your Prefixes<\/h2>\n
Publishing ROAs correctly<\/h3>\n
\n
Enforcing RPKI on your own border<\/h3>\n
Monitoring and Detecting Unauthorized BGP Announcements<\/h2>\n
Practical detection methods<\/h3>\n
\n
Responding to a hijack<\/h3>\n
Conclusion: Building a Secure Routing Foundation for Your IPv4 Space<\/h2>\n