How to Announce a New IPv4 Prefix via BGP: Complete Guide

Announcing an IPv4 prefix via BGP is what makes your block reachable across the global internet, whether it’s a freshly acquired /24 or legacy space recently transferred to your organization. This guide walks network engineers through the whole process: preparing prerequisites, configuring routers from Cisco, Juniper, and MikroTik, and validating announcements with RPKI and IRR objects.

Prerequisites Before You Announce an IPv4 Prefix

Before you touch a router configuration, make sure the fundamentals are in place. Missing any of these is, in my experience, the most common reason new announcements simply fail to propagate.

• Legitimate rights to the prefix. The prefix must be registered to your organization with an RIR such as ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC. If you bought the block on the secondary market, check that the transfer was actually completed and the WHOIS record now shows your organization. Platforms like IP4 Market specialize in verified IPv4 transfers, so buyer and seller details get validated before the RIR updates the registration.
• A unique 16-bit or 32-bit ASN. Obtain one from your RIR unless you plan to announce through a provider using their AS. Note that a /24 is the smallest globally routable prefix; anything longer will typically be filtered.
• Upstream transit or peering. You need at least one BGP session with an upstream provider or an IXP. Ask them to configure the session and confirm they’ll accept your prefix length.
• IRR and RPKI records. Create a route (or route6) object in the relevant IRR database and ROAs in your RIR’s RPKI service. Many large networks filter unmarked routes by default these days.
• Documented IP plan. Know which subnets you’ll announce and how internal routing will deliver traffic to them.

Step-by-Step BGP Configuration to Announce an IPv4 Prefix (Cisco, Juniper, MikroTik)

The core pattern is identical across vendors: originate the prefix in BGP, establish an eBGP session with your upstream, and make sure the prefix exists in the routing table. BGP will not advertise a route it can’t resolve. Ever.

Cisco IOS

Use a network statement plus a static route to null0 so the prefix shows up in the RIB:

• router bgp 65001, then network 203.0.113.0 mask 255.255.255.0
• ip route 203.0.113.0 255.255.255.0 null0
• Configure the eBGP neighbor with neighbor 198.51.100.1 remote-as 64500

Juniper Junos

Define a policy that exports your aggregate or static route, apply it under protocols bgp group with export ADVERTISE, and create route 203.0.113.0/24 discard in the routing-options table.

MikroTik RouterOS

Add a blackhole route (/ip route add dst-address=203.0.113.0/24 blackhole), then under /routing bgp connection set the remote AS and use an output filter or networks list containing your /24.

After configuring, confirm session establishment with show ip bgp summary (Cisco), show bgp neighbor (Junos), or the BGP sessions window in Winbox. Then verify your prefix appears with your ASN as the origin.

RPKI, IRR, and Route Objects: Making Your Announcement Trusted

Modern routing security depends on cryptographic and registry-based validation. Relying parties — large carriers, Cloudflare, Google — increasingly apply Route Origin Validation, so an unvalidated prefix may be dropped or deprioritized. Sometimes silently.

1. Create ROAs. In your RIR portal, authorize your ASN to originate the prefix, specifying the maximum prefix length (a /24 ROA with maxLength 24 is typical for exact announcements).
2. Publish IRR route objects. Maintain objects in the authoritative IRR (RIPE, ARIN, or via RADb for legacy space) listing your ASN as the origin.
3. Maintain consistency. The ROA, IRR object, and actual BGP origin AS must match exactly. Mismatches cause RPKI “invalid” status and immediate filtering.

Keeping these records current after any transfer or ASN change is essential — and it’s one more reason to buy IPv4 space from a marketplace like IP4 Market, where post-transfer registry accuracy is part of the service.

Common Mistakes When You Announce a New IPv4 Prefix

Here’s the thing: even seasoned network teams trip up the first time they announce IPv4 space on a new ASN. Most of these mistakes are avoidable with a short checklist before you go live. Not glamorous work. But neither is a two-hour outage.

• Missing or stale ROA: If your ROA lists the wrong ASN, or the maxlen excludes the prefix length you’re actually announcing, RPKI-invalid routes get dropped by the major transit providers. Simple as that. Create the ROA before the first BGP session comes up, not after.
• Announcing more-specifics without a covering aggregate: Some operators carve a /24 out of a /22 and originate only the /24. This can break reachability for the rest of the block, and it tends to trigger deaggregation filters upstream. I’ve seen this one more than once.
• Inconsistent IRR objects: A route object in RADB that doesn’t match your aut-num in the RIR database will get your routes rejected by peer filters. Keep route and route6 objects in sync everywhere. Everywhere.
• Announcing from an AS that doesn’t match the registry: Recently transferred prefix? Then make sure the RIR record reflects your ASN before you originate anything. Mismatches are a common source of hijack reports, which is not the kind of attention you want.
• Forgetting to export routes to the route server: At an IX, a missing export policy toward the route server leaves you invisible to most members. The sessions look established. Nothing flows.

Monitoring and Validating Your BGP Announcements

Your prefix is live. Now what? Validation shouldn’t be a one-time check, because routing doesn’t stay static, and a handful of free services will give you near-real-time visibility into how the announcement travels.

• Route collectors: RIPE RIS and RouteViews show which ASNs see your prefix and from which origin. If only a few monitors report visibility, something’s off — the announcement isn’t propagating as intended.
• RIPEstat and BGPlay: Both visualize BGP updates over time. Flapping, unexpected origins, sudden path changes — easy to spot once you can actually see them.
• RPKI validators: Confirm the prefix shows “valid” from multiple vantage points. An “invalid” usually means the ROA and the real announcement disagree.
• Looking glasses at major peers: Check the large transit networks and IX route servers to confirm your prefix is accepted, not filtered by bogon or max-prefix policies.

It’s also worth setting up automated alerting — ARIN’s delegated statistics, Cloudflare Radar, or a commercial platform that flags route leaks, hijack attempts, or origin changes you didn’t make. For leased or transferred space, monitoring matters twice over: previous holders sometimes leave stale configurations pointing at the block. They usually don’t mean any harm. It still causes problems.

Final Thoughts: Announcing IPv4 Prefixes the Right Way

None of this is mysterious. Secure the space with clean registry records, create accurate ROA and IRR objects, configure your origin AS with sensible policies, then validate propagation through independent monitoring. Skip a step and you risk outages, filtering — or worse, being mistaken for a route hijack.

The foundation matters as much as the configuration. Prefixes bought through informal channels often come with tangled registry history, unresolved ROAs, or disputed provenance, and all of that complicates origination later. A reputable marketplace like IP4 Market takes most of that headache off the table: verified sellers, clean transfer documentation, competitive pricing. Your engineering team gets to focus on routing instead of paperwork.

Follow the steps here, keep your records current, monitor continuously. Do that, and the prefix will serve your network reliably for years.