BGP Announcement: Make Your IPv4 Block Reachable

By Savvas Bout, Founder of Prefixx. Last updated 23 October 2026.

Invisible on the Internet until announced with a BGP update into the internet routing table, each IPv4 block bought, leased or transferred is solely the responsibility of the origin ASN that announces it.

Announcing a block incorrectly can turn a clean, transferred block invisible on the internet via a bad BGP update message while your team is busy resolving routing issues.

This article describes what a BGP announcement actually does, how origin validation with RPKI and IRR relates to the BGP announcement itself. Additionally, What the announcement looks like for different scenarios to deploy announced IP addresses:. buying IP addresses , leasing them with a guarantee of non-revocation , and announcing your own IP address space from your own bare-metal hosts or cloud servers.

If you are purchasing IP addresses and need a valid BGP route established from day one, the work to properly route those announced IP addresses is in fact part of the work to acquire IP addresses in the first place. So, start with the fundamentals: what is a BGP announcement?

What is a BGP routing announcement

A BGP announcement is a router's way of notifying its neighboring routers of a prefix it can reach, and the path to get to it. Without an announcement of a block of IP addresses, even though they may be owned by someone, they would not be invisible on the Internet.

Border gateway protocol vs internal routing protocol explained

BGP is used to connect together all of the networks on the global Internet. As opposed to internal routing protocols like OSPF, which are used to route traffic within a single organization, BGP is used to route between completely separate organizations. For more context, see Border Gateway Protocol.

Each AS has a unique ASN, and they run BGP to advertise available IP addresses (or "prefixes") that they can send traffic to. These routers connect to form the mesh of autonomous systems that exchange reachability information across the internet.

Autonomous system and the update message

An operator makes a prefix reachable by advertising it using BGP UPDATE messages to its peers. Every such UPDATE message contains four key fields. Operators must carefully construct these messages to advertise their prefixes in a way that neighboring routers will accept and propagate.

• Prefix: the IP address block being announced (for example, 203.0.113.0/24).
• AS path: the sequence of autonomous systems that traffic will travel through.
• Next-hop: IP address of next router to internet destination.
• Path attributes: LOCAL_PREF and MED values which influence routing decisions.

BGP as an internal routing protocol and router behavior

The UPDATE messages received by a BGP router are evaluated against the local policy of that router. The “best” path is chosen from the set of received paths and distributed to all other peers of that router. Policy filters may also shape which BGP route ultimately enters the local routing table based on community tags or prefix length constraints.

The BGP routing decisions are policy-driven and not solely based on the metrics of the routes as with other routing protocols. When a block changes hands, the prefix reputation and the length of the AS path play a significant role. Operators must configure their policies to ensure the best path selection reflects both security validation and business peering relationships.

The LOA, RPKI ROA and IRR route objects for a network block are prepared by the Prefixx team before a block is announced to be live. The Prefixx team coordinates with the relevant registries to ensure all documentation is in order for the block owner's account.

How BGP works step by step as an internal routing protocol

In-depth knowledge of the BGP update announcement lifecycle is necessary for any network engineer operating in address space.

External BGP routing: session setup and update exchange

An external BGP peering is set up between two routers in different autonomous systems over a TCP connection on port 179. The routers then exchange OPEN messages with AS numbers, hold times, and BGP identifiers.

After the two peers have agreed to the setup of the BGP session, the two peers then start to exchange KEEPALIVE messages in order to verify if the BGP session is operational. The TCP connection itself must remain stable throughout the session, as any interruption will cause the peering to fail and require re-establishment.

The BGP session is established, and each router now sends UPDATE messages to its BGP neighbor or peers.

The router continues sending KEEPALIVE messages regularly.

Internal BGP: how a BGP router propagates routes inside one as

After entering the AS with BGP advertisements from an external peer, routes are distributed throughout the internal BGP (iBGP) within the AS. Unlike external peers, iBGP speakers do not re-advertise routes learned from other iBGP speakers within the same AS network by default.

As a result, interconnect routers within large ASes typically maintain a full-mesh of BGP speaker connections or employ a set of specialized route reflectors. Route reflectors help avoid the scaling problem that would otherwise require every router to maintain full tables of all iBGP sessions in a mesh topology.

Path selection: from adj-rib-in to the routing table

All routes learned from a neighbor are added to the Adj-RIB-In. Best path selection is then performed on all candidate routes for a given prefix. The network selection criteria are weight, LOCAL_PREF, AS_PATH length, origin, MED, and eBGP-over-iBGP preference in that order. The chosen route is then added to the main routing tables and, if configured, advertized in addition. Operators must ensure that route reflectors and border routers are configured consistently to avoid asymmetric routing or path selection discrepancies across the AS.

Once you acquire or lease a block of IP addresses, expect a delay before the first prefix reaches your network.

As long as Prefixx prepares the necessary LOA, RPKI ROA and IRR route objects for the acquired prefixes, the routes received by the path selection process will be clean and properly originated from the very first day the first prefix of your newly acquired block reaches your network.

The following section describes the path selection process in more detail. Path selection evaluates each candidate route to a given destination prefix based on attributes like AS_PATH length, local preference, and origin type before installing the best route.

BGP route selection: how routers pick the best path

A router using BGP to advertise prefixes will always choose one of the announced routes (using a deterministic tie breaker) when there are multiple routes of equal metric for a given prefix.

The BGP route selection process

1. The highest local preference wins first. Local preferences are compared to determine the highest value. The attribute is used for internal purposes within an AS, and is never advertised to external peers. It provides a clean means to set an internal policy within an AS.
2. Shortest AS path. If local preference is equal, then we count AS hops. The fewest wins. This is seen by every external peer, so influences choices across the global Internet.
3. Origin type. Here IGP is preferred over EGP, and Incomplete is worse. Note that for modern networks this decision is almost never made to affect routing. However, it is here.
4. Lowest MED. Multi-Exit Discriminator (MED) tells neighboring ASes which entry point(s) to use. It only compares routes from the same neighboring AS.
5. eBGP over iBGP. External learned routes are preferred over internal learned routes.
6. tie breaker 1, lowest IGP metric to next hop. In case of all other tie breakers being equal, the router chooses the next hop with lowest IGP metric to reach that next hop from within the AS.

BGP route example: two paths, one winner

You receive two advertisements for 203.0.113.0/24. Path A was announced via eBGP with an AS Path length of 3. Path B was announced via eBGP with an AS Path length of 2. The local preference for both announcements is the same.

Therefore the best route is Path B because of the shorter AS Path which breaks a tie at step two of the Route Selection Decision making process. Routers apply best path selection criteria in a fixed sequence, evaluating each attribute only when the preceding steps yield identical values across candidate routes.

Increase the local preference of Path A to be greater than that of Path B.

Note: Local preference is set by your own routing policy. If you forget to set it consistently across all border routers, different routers inside the same AS may each pick a different best route exit for the same prefix. Inconsistent local preference values can cause suboptimal best path selection, forcing traffic through congested or higher-latency links even when better alternatives exist.

Using BGP communities to influence best path selection

A BGP community is a tag, which a operator can attach to a BGP route. He can then signal his upstream providers to change their local preference or to prepend AS hops for him. Operators often request that upstream providers assign the highest local preference to routes tagged with specific communities, ensuring those paths are selected over alternatives.

This way he can steer network traffic, which is coming from peers he does not control directly, to the desired location. After we have explained how path selection for BGP routes works, we will continue with the explanation of the UPDATE messages that are used to distribute these routes. Each update message carries the routing information that enables autonomous systems to coordinate their forwarding decisions across the global internet.

BGP routing update messages: announcements and withdrawals

Each BGP session uses the same message, UPDATE, to exchange routing information.

Update message structure

An update message can consist of up to three variable-length fields: Path attributes (ORIGIN, AS_PATH, NEXT_HOP, LOCAL_PREF, MED) that describe the announced route in more detail. The NLRI field lists all prefixes that are announced by the sending router in length-prefix form. The withdrawn routes field contains those prefixes that are no longer reachable from the sending router. Each path attribute serves as a distinct feature that routers use to evaluate and compare competing routes during the selection process.

An update message can contain multiple announcements and withdrawals.

Route propagation hop by hop

When a router learns a new route, it advertises the prefix to other neighbors by prepending its own ASN to the AS_PATH attribute.

By advertising new prefixes in the global routing table hop-by-hop across the Internet, the global BGP table grows every time a new prefix is advertised and accepted.

Withdrawals and when they fire

Additionally, Deaggregation events where a single covering aggregate is replaced by more specific routes.

The time it takes a router to process an update, add it to its RIB, and advertise the withdrawn route to its neighbors varies greatly depending on the number of sessions connected to that router.

The complexity of the routing policies, the number of routes received, and the timer settings for MRAI (Maximum Route Advertisement Interval) as defined in RFC 4271. The reader can find more information on how the BGP routing table grows and why aggregation is important in the next section.

BGP route origin authorization and RPKI: securing BGP announcements

BGP as normally deployed has no authentication capability.

How route origin authorization closes the gap

Regional internet registries issue resource certificates for their customers for the address space that customers hold. These in turn are used by operators to create Route Origin Authorizations. Signed objects that assert the best path for a particular prefix is originated by the ASN of the operator that created the object and by no other.

When a router receives a BGP announcement, the announcement’s payload is added to the router’s Adj-RIB-In and checked against the RPKI cache for that announcement.

IRR route objects as a complement

IRR route objects predate RPKI. Although they serve a somewhat similar purpose in keeping routing tables consistent through policy management, IRR objects are managed based on policy whereas RPKI route origin authorizations (ROAs) carry a cryptographic signature that cannot be replicated in IRR route objects.

For example an operator can use IRR data to block connections from certain peers. But someone else can easily register a conflicting IRR route object. Operators must evaluate whether each peer enforces RPKI validation, relies on IRR filtering, or accepts announcements with minimal policy checks.

Implementing RPKI with Prefixx

We create the LOA, RPKI ROA and IRR route objects for you so your new block is announcement ready from the day you get it. We don't have you manually enter data into any web or network portals, and you don't have to guess at maximum length values.

Now that we have this framework validated, the next question for network operators is how to apply it to situations where you bring your own address space to run on cloud instances or bare-metal servers. Operators must ensure that their routing architecture maintains stable connectivity regardless of whether prefixes originate from traditional data centers or distributed cloud environments.

BGP announcements in BYOIP: bringing your own IP to cloud and bare metal

BYOIP allows you to announce your own IP prefix via a cloud or hosting provider’s autonomous system. Announcing your IP via an AS helps keep your IP address portable, and protects your online reputation. Your IP address block will remain your own and we will originate the BGP announcement on your behalf. Below is an example of how BYOIP can work. This arrangement allows you to connect your infrastructure across multiple providers while maintaining consistent addressing and routing policies.

Preparation for global internet access

1. Confirm ownership and transfer eligibility. Verify that your block is registered with the correct RIR and that there are no encumbrances on it. A clean record is required for transfer of any prefix to accept service from providers.
2. Letter of Authorization. Get an LOA from your RIR or your upstream provider, confirming that you are authorized to advertise a particular prefix. This is the very first document that any service provider checks.
3. Create a Route Origin Authorization (ROA). Publish an RPKI ROA that authorizes the origin of announcements from the provider’s ASN. Without a valid ROA, announcements from the provider will be flagged as invalid by all ISPs that perform RPKI filtering.

Submission

1. Each provider runs a BYOIP program. Upload your LOA and ROA proof to have the prefix made reachable by the provider after they have verified ownership of the range. List of providers that run a BYOIP program is provided below: AWS, GCP, Azure, OCI, and Cloudflare.
2. Create IRR route objects. Register a route object in the appropriate IRR database. This allows traffic to flow to networks that filter on IRR as opposed to RPKI.

Note: Skipping the IRR step is a common mistake. Some networks filter on IRR alone, so a missing route object can leave users unable to reach your services over a valid connection.

Deployment on bare metal

1. Make the prefix live. Once the prefix has been accepted by the provider it will start to advertise the corresponding block from your IP range in the full BGP table. All traffic addressed to your IP range will then start to flow through the provider’s network.
2. Work with Prefixx for end-to-end handling. For BYOIP deployment onto Netrouting bare metal (AS6206), the Prefixx team prepares the LOA, RPKI ROA, and IRR route objects on your behalf. The same support covers cloud BYOIP programs across AWS, GCP, Azure, OCI, and Cloudflare. Nothing is automated; a senior consultant manages each step. Learn more at Prefixx.net/BYOIP.

Once a prefix is announced over the Internet, verifying that it is indeed visible and stays that way is next in line. The corresponding monitoring for BGP announcements is covered in the following section. Operators must confirm that the prefix propagates correctly to each intended destination network and that traffic flows as expected.

Common BGP announcement problems and how to fix them

The majority of BGP announcement failures can be categorized into 5 buckets. Knowing which layer to start investigating within each failure category is key to identifying root-cause quickly (ROA/session/prefix length/path attributes).

Prefix not visible or RPKI invalid

If your announcement never seems to reach global routing tables, the place to start is with RPKI. Missing ROAs mean that your origin ASN and prefix are in a state of unknown validity. In particular, a single ROA for a /20 will cause invalid results for any /24s announced from the same origin, meaning any next hop RPKI-enforcing peer will simply dump those more-specific prefixes.

We prepared a ROA which exactly matches the announced prefix length. Our team also prepares the corresponding IRR route objects as well as the LOA for each lease and transfer we do at Prefixx.

Route flapping and session instability

Announce and withdraw of the same prefix (in repeated cycles) indicates an unstable BGP session. Every such cycle causes the upstream routers to run out of the update message counters and thus to be dampened. Even after the session recovers to the fully active state the prefix in question stays unreachable.

Session resets caused by a misconfigured timer should be fixed by first correcting the timer and sending an update message to clean up the session, rather than forcing a hard reset over and over.

Prefix hijacking and route leaks

A hijack is when a foreign AS originates a prefix that you own without you authorizing them to do so. A route leak is when an iBGP peer or a transit provider origins a prefix outside of the scope in which it was originally advertised. Typically changing some of the path attributes to point to a different route. Route leaks often occur when an intermediate AS incorrectly propagates a prefix learned from one peer to another, effectively rerouting traffic away from the intended destination.

• Monitor origin ASN changes in real time with your BGP monitoring tools.
• Publish accurate IRR route objects so upstream filters can block unexpected announcements.
• Enforce strict export policies to prevent a peer propagating routes learned from another peer.

BGP monitoring using RIPEstat is included in the Prefixx client portal. Routing hygiene is not something that can be added after the fact, it has to start with the choice of where to acquire IP address space in the first place.

Why proper BGP announcement setup matters when you buy or lease IPv4 space

Announce the prefix correctly (valid route origin, clean IRR, LOA on file) and it starts carrying mail within a short time span. Stale routing information and blacklist entries for the block affect deliverability immediately.

Prefixx handles the routing hygiene side so you don't have to:

• Tixx performs a set of quality control checks on every block prior to sale or lease, including verification of ownership, transfer eligibility, blacklists, and BGP routing health.
• White-glove service covers LOA, RPKI ROA, and IRR route objects plus geo-IP correction, reverse DNS, and a bad-ass reputation monitoring system.
• We can provision a lease for you within 24 hours with a non-revocation guarantee. This means that when you bring up a BGP session it will see a clean, valid prefix.
• Transfers of Inter-RIR resources between ARIN and RIPE NCC, APNIC, and LACNIC are coordinated with end-to-end regional Internet resource holders.
• BYOIP deployment support on Netrouting bare metal, with our team preparing every route object. See the BYOIP page for details.

Need a vetted block of copy to announce your launch on day one?

Frequently asked questions

Does BGP still matter for managing new routes and network traffic in modern networking?

BGP is the routing protocol that holds the internet together. Every autonomous system on the public internet exchanges reachability information through BGP, and there is no credible replacement on the horizon. Cloud providers, ISPs, content networks, and enterprises all depend on it daily. Its relevance has grown, not shrunk, as the internet has scaled.

What does BGP stand for when it comes to sharing new routes between networks?

BGP stands for Border Gateway Protocol. It is the standardized exterior gateway protocol used to exchange routing and reachability information between autonomous systems on the internet. The current version, BGP-4, is defined in RFC 4271.

When was the BGP route protocol first released?

The first version of BGP was published in 1989 in RFC 1105. BGP-4, the version in universal use across the network today, was standardized in 1994 via RFC 1654 and later updated by RFC 4271 in 2006. It replaced the earlier EGP protocol as the internet's inter-domain routing standard.

How do you check a BGP route being advertised?

The fastest public tool is RIPEstat, which shows live BGP visibility, the originating ASN, RPKI validity, and upstream peer views for any prefix. Looking Glass servers operated by major carriers let you query their routers directly with commands like show IP BGP prefix/length.

BGP monitoring platforms backed by RIS or RouteViews data give you historical visibility and alert on unexpected origin changes. Prefixx's client portal includes BGP monitoring to help find the best path for leased and owned blocks, covering origin ASN, RPKI status, and IRR consistency.

What is the difference between ebgp and ibgp?

eBGP (external BGP) runs between routers in different autonomous systems and is how networks exchange routes across the public internet. iBGP (internal BGP) runs between routers within the same autonomous system to distribute those external routes internally.

A key difference is that iBGP routers do not re-advertise routes learned from one iBGP peer to another, which is why full-mesh or route-reflector designs are needed inside large networks. eBGP sessions also reset the AS path and apply different default administrative distances than iBGP.

What happens if a BGP announcement is RPKI invalid?

An RPKI-invalid announcement means the originating ASN does not match any ROA covering that prefix. Networks that enforce RPKI Origin Validation will drop the route entirely, making the prefix unreachable from those networks.

As more ISPs and major networks deploy Route Origin Validation, an invalid state increasingly causes real traffic loss, not just a warning. Fixing it requires creating or correcting a ROA through the relevant RIR to ensure routes received are valid, which Prefixx handles as part of its white-glove routing paperwork on every lease and transfer.

BGP announcements allow the Internet to be routed. Every originated prefix is a statement of reachability that gets propagated hop by hop in UPDATE messages, subjected to the various path selection decisions, and finally ends up in the global route table. Announcing a single prefix incorrectly (e.g., by means of bad RPKI, a missing IRR object, or an overly specific deaggregated announcement) can cause problems with your traffic, override the highest local preference settings on peer routers, or even get your whole IP block blocked.

Announcing prefixes correctly is important for the actual announcement itself, but prefix hygiene is even more important. A valid ROA (Route Origin Authorisation) and sufficient consistent route objects in the IRR (Internet Routing Registry) are the minimum requirements to get your announced prefixes accepted or at least not dropped by more than one peer or upstream provider. Even if your router configuration is perfect.

If you are acquiring, leasing, or moving a block and need the LOA, RPKI ROA, and IRR objects prepared correctly before you announce, Prefixx handles that paperwork end to end.