What Is BGP? How Border Gateway Protocol Turns IP Addresses into Reachable Services

BGP (Border Gateway Protocol) is the routing protocol that connects independent networks across the Internet. It allows networks to announce which IP address blocks they can reach, and it lets every other network decide how to send traffic toward those blocks. Without BGP, an IPv4 address can be registered, allocated, or leased — but no one on the Internet would know how to reach it.

For businesses, this distinction matters more than it first appears. Acquiring public IPv4 space and making that space reachable are two separate steps. A registry record confirms who is authorized to use an address block. A BGP announcement is what actually places that block on the live Internet.

Whether a company runs hosting infrastructure, VPN services, SaaS platforms, email systems, or enterprise gateways, the same operational chain applies: the IPv4 addresses provide the public endpoint, the ASN provides the routing identity, and BGP announces the two together to the rest of the world. This article explains how that chain works, what happens when a business announces a newly acquired or leased prefix, and what to check before deployment.

What Is BGP?

BGP, or Border Gateway Protocol, is the standard protocol used to exchange routing information between autonomous systems on the Internet. An autonomous system (AS) is a network under one administrative control — for example, an ISP, a cloud provider, a hosting company, or a large enterprise network. Each autonomous system is identified by an Autonomous System Number (ASN).

BGP performs one essential job: it lets each autonomous system tell its neighbors which IP prefixes it can reach, and it lets every network build a map of paths toward every publicly announced prefix in the world.

A useful way to think about it: the global Internet is not one network. It is tens of thousands of independent networks that agree to exchange traffic. BGP is the language those networks use to describe reachability to each other.

The current version, BGP-4, has been in production use since the 1990s and remains the routing foundation of the public Internet for both IPv4 and IPv6.

How Does BGP Work?

BGP works by having neighboring networks establish sessions with each other and exchange route announcements. Each announcement says, in effect: “This IP prefix can be reached through me, and here is the path of autonomous systems the traffic will pass through.”

The process can be summarized in four steps:

1. Origination. The network responsible for an IP prefix announces it to its directly connected neighbors (its upstream providers and peers). The ASN that first announces the prefix is called the origin ASN.
2. Propagation. Each neighbor that accepts the announcement passes it on to its own neighbors, adding its ASN to the path. The announcement spreads across the Internet, network by network.
3. Path selection. Most networks receive multiple paths to the same prefix. BGP uses a series of tie-breaking rules — heavily influenced by each network’s own commercial and traffic policies, with shorter AS paths generally preferred — to select which path to use.
4. Forwarding. Once a path is selected, traffic destined for that prefix is forwarded hop by hop along the chosen route.

A simple example

Imagine a hosting company (a hypothetical example) that operates AS 65001 and deploys the prefix 203.0.113.0/24 for customer servers. The company announces 203.0.113.0/24 to its two upstream providers. Each upstream accepts the route and passes it to its own peers and customers. Within minutes, networks around the world have a path toward 203.0.113.0/24, and the servers inside that block become reachable from anywhere on the Internet.

If the company stops announcing the prefix — or if its upstreams stop accepting the announcement — the addresses still exist in the registry, but traffic no longer has a path to reach them. From the Internet’s perspective, the services behind those addresses disappear.

This is the core operational lesson of BGP: reachability is created by announcement and acceptance, not by registration alone.

BGP, ASN, and IP Addresses: How the Three Fit Together

IP addresses, ASNs, and BGP perform three different roles: the IP address is the reachable endpoint, the ASN is the routing identity, and BGP is the mechanism that connects the two. They are frequently confused because they always appear together in routing operations.

Resource	What it is	Operational role	Who assigns or manages it
IPv4 address / prefix	A numeric identifier for a network endpoint (e.g., 203.0.113.0/24)	The destination that customers, applications, and services actually connect to	Registered through RIRs; used through allocation, transfer, or leasing arrangements
ASN	A unique number identifying an autonomous system (e.g., AS 65001)	The routing identity that originates announcements and appears in AS paths	Issued by RIRs to organizations that need independent routing
BGP	A protocol, not a resource	The mechanism that announces prefixes, propagates paths, and selects routes	Operated by each network on its own routers and sessions

We cover autonomous systems in depth in our dedicated guide to the Autonomous System Number (ASN), including when a business needs its own ASN. For this article, the key relationship is simple: an ASN without prefixes has an identity but nothing to announce, and a prefix without a BGP announcement has an identity but no path. Reachable infrastructure requires all three working together.

Why Does BGP Matter for Businesses?

BGP matters because every public-facing service a business operates depends on its prefixes being announced and accepted. Websites, APIs, VPN gateways, mail servers, DNS resolvers, streaming platforms, and payment endpoints all sit behind announced IP space. When announcements work correctly, nobody notices BGP. When they fail, the failure is total: the service is unreachable regardless of how healthy the servers themselves are.

Beyond basic reachability, BGP gives businesses three practical capabilities:

• Provider redundancy (multihoming). A network that announces its own prefixes through two or more upstream providers can survive the failure of one provider. Traffic reroutes along the remaining paths, often within seconds to minutes, without changing any IP addresses.
• Provider independence. A business that uses its own address space and ASN can change transit providers, data centres, or cloud platforms without renumbering. The infrastructure underneath changes; the public network identity does not.
• Traffic control. Through announcement policies, a network can influence how inbound traffic arrives — for example, preferring one provider for capacity or cost reasons, or spreading traffic across regions.

These capabilities are a major reason businesses acquire or lease their own IPv4 blocks rather than relying entirely on provider-assigned addresses. Provider-assigned space usually cannot move with the business; independently held or leased space, announced under the business’s own routing arrangements, can.

What Happens When You Announce a Leased or Newly Acquired Prefix

Announcing a prefix requires more than router configuration: the announcement must be authorized, documented, and accepted by upstream networks before the prefix becomes reachable. This is the step where many deployments of newly acquired or leased IPv4 space run into delays.

Upstream providers do not blindly accept every announcement. Because a false announcement can redirect someone else’s traffic, responsible networks filter what they accept and check that the announcing party has the right to announce the prefix. In practice, several layers of authorization and documentation are involved:

• Letter of Authorization (LOA). A document from the party that controls the prefix, authorizing a specific network or ASN to announce it. Upstream providers commonly request an LOA before accepting a new announcement.
• Route Origin Authorization (ROA). A cryptographically signed record in the RPKI system stating which ASN is authorized to originate the prefix. A growing number of major networks reject announcements that conflict with a published ROA, so a missing or mismatched ROA can silently limit reachability.
• IRR route objects. Entries in Internet Routing Registry databases that many providers use to build their route filters automatically. If the route object does not match the announcing ASN, some networks will filter the announcement.

Only when these records align does the routing side proceed smoothly: the business (or its provider) originates the prefix from the agreed ASN, upstreams accept it, and the announcement propagates. Global propagation of a new, correctly authorized announcement typically completes within minutes to hours, though filter updates at some providers can take longer.

Two distinctions are worth stating precisely, because they are often blurred in casual discussion:

• Announcement is not ownership. The ability to announce a prefix reflects authorization, not registry-level rights. A lessee announcing a leased block is authorized to use and announce it under the lease terms; the registration remains with the registered holder.
• Registration is not reachability. A perfectly documented registry record does nothing operationally until the prefix is announced and accepted. The registry layer and the routing layer are connected but separate systems.

For businesses leasing IPv4 space, this is why the quality of the leasing arrangement directly affects routing outcomes. A structured lease — such as those arranged through IPv4 leasing should come with clear announcement authorization, LOA issuance, ROA support where applicable, and a defined process for updating routing records. A lease that delivers only an IP range, without the authorization chain behind it, frequently produces the deployment delays and filtering problems described in our guide on avoiding downtime when deploying leased IPv4 blocks.

Common BGP Problems That Affect Reachability

Most business-impacting BGP problems fall into four categories: unauthorized announcements, filtered announcements, misconfigured records, and route instability.

1. Prefix hijacking

A hijack occurs when a network announces a prefix it is not authorized to announce, intentionally or by mistake. Traffic destined for the legitimate holder can be redirected or dropped. Hijack risk is highest during transitions, when authorization records are changing hands — we cover the protective sequence in detail in How to Prevent IPv4 Hijacking During a Transfer.

2. Route leaks

A route leak happens when a network propagates announcements beyond their intended scope — for example, a customer network re-announcing routes learned from one provider to another. Leaks can pull traffic through unintended paths, causing congestion or outages even without malicious intent.

3. Filtered or rejected announcements

The quietest failure mode: the announcement is made, but some networks refuse it. Causes include a missing LOA, an IRR route object that does not match the origin ASN, or an RPKI ROA that conflicts with the announcement. The result is partial reachability — the service works from some networks and fails from others, which is one of the most confusing symptoms to troubleshoot.

4. Wrong origin ASN

If a prefix is announced from an ASN different from the one recorded in the ROA and route objects, networks performing origin validation will treat the announcement as invalid. This commonly occurs when a business changes providers or announces newly leased space without first updating the authorization records.

The pattern across all four categories is consistent: BGP problems are usually authorization and record-alignment problems, not router problems. The routing layer reflects the paperwork behind it.

Do You Need to Run BGP Yourself?

No — many businesses use public IPv4 space without operating BGP directly, because an upstream provider can announce the prefix on their behalf. Whether to run BGP yourself is a real infrastructure decision with trade-offs in both directions.

Approach	How it works	Best suited for	Trade-offs
Upstream announces for you	Your hosting provider, ISP, or data centre announces your prefix from their ASN under an LOA	Single-site deployments, businesses without network engineering staff, faster initial deployment	Reachability depends on one provider’s routing; moving providers requires re-coordinating announcements
Run BGP with your own ASN	You operate BGP sessions with one or more upstreams and originate your own prefixes	Multihomed networks, ISPs, VPN operators, hosting platforms, businesses needing failover and traffic control	Requires an ASN, capable routers or routing software, and engineering ownership of routing policy

A reasonable rule of thumb: if your business needs provider redundancy, plans to operate from multiple locations, or expects to change providers while keeping the same addresses in production, running BGP with your own ASN is usually worth the operational investment. If you operate a single-site deployment behind one provider, having that provider announce your space is often the simpler and equally functional path — provided the authorization documents clearly permit it.

Both models work with leased space as well as purchased space. What matters is that the lease or acquisition explicitly supports the announcement model you intend to use, including which ASN will originate the prefix and who is responsible for keeping ROAs and route objects aligned.

Practical Checklist Before Announcing a Prefix

Before putting a newly acquired or leased prefix into production, confirm the following:

1. Announcement authorization is documented. An LOA exists naming the correct prefix and the exact ASN that will originate it.
2. ROA status is checked and aligned. If a ROA exists for the prefix, it must name your origin ASN. If it names a previous ASN, reachability will be degraded on networks enforcing origin validation until it is corrected.
3. IRR route objects match. The route object for the prefix should reference the announcing ASN so automated provider filters accept the route.
4. Upstream providers are notified. Filters at your transit providers should be updated before the announcement, not after it fails.
5. The origin ASN is agreed in writing. Especially for leased space, the lease terms should state which ASN may announce the block and how changes are handled.
6. Propagation is verified externally. After announcing, check visibility from multiple external vantage points rather than assuming global acceptance from one successful session.
7. A rollback contact exists. If the announcement causes conflicts, you need a defined path to the party who can correct records quickly.

Practical Note from i.lease

In practice, most BGP-related deployment problems we see with IPv4 space trace back to one root cause: the commercial arrangement and the routing records were never aligned. A business receives a block, configures the announcement correctly, and still experiences partial reachability — because the ROA points at an old ASN, the route object was never updated, or the LOA names the wrong party.

This is why it is worth treating announcement authorization as part of the acquisition itself, not as an afterthought. Whether a business chooses to Buy IPv4 addresses or lease them, the questions to resolve before deployment are the same: Which ASN will originate the prefix? Who issues the LOA? Who controls ROA creation and updates? How quickly can routing records be corrected if something conflicts? A block that arrives with clear answers to these questions deploys in days. A block that arrives without them can spend weeks partially reachable.

Final Thoughts

BGP is the mechanism that turns registered IP address space into reachable Internet services. It works through announcements: each network declares the prefixes it can reach, neighbors accept and propagate those declarations, and traffic follows the selected paths. The three resources involved keep distinct roles throughout — the IPv4 prefix is the endpoint, the ASN is the routing identity, and BGP connects the two.

For businesses, the operational takeaway is that reachability is created and maintained, not granted. Registration confirms authorization to use address space; announcement and acceptance are what place it on the live Internet; and the records that support announcement — LOA, ROA, route objects — decide how smoothly that happens. Businesses that plan the routing layer alongside the acquisition of address space, whether purchased or leased, avoid the most common and most avoidable category of deployment failure: a prefix that exists on paper but not on the Internet.

Frequently Asked Questions

What does BGP stand for?

BGP stands for Border Gateway Protocol. It is the standard routing protocol used to exchange reachability information between independent networks (autonomous systems) on the Internet.

Is BGP the same as an ASN?

No. An ASN (Autonomous System Number) is an identifier for a network, while BGP is the protocol that networks use to exchange routes. The ASN appears inside BGP announcements as the routing identity, but they are separate concepts.

Do I need my own ASN to use BGP?

You need an ASN to originate BGP announcements yourself. However, many businesses do not run BGP directly — instead, their upstream provider announces their IP prefixes from the provider’s ASN under a Letter of Authorization.

Can I use leased IPv4 addresses with my own ASN?

Yes. Leased IPv4 space can be announced from the lessee’s own ASN, provided the lease authorizes it and the supporting records — LOA, ROA where applicable, and IRR route objects — name the correct origin ASN.

What is a BGP announcement?

A BGP announcement is a message in which a network declares that a specific IP prefix is reachable through it. Neighboring networks that accept the announcement propagate it further, building global paths toward the prefix.

How long does BGP propagation take?

A correctly authorized new announcement typically propagates across most of the Internet within minutes to a few hours. Delays beyond that usually indicate filtering issues, such as missing authorization records or providers whose filters have not yet been updated.

Does announcing an IP prefix mean you own it?

No. Announcement reflects routing authorization, not ownership. A network can be authorized to announce a prefix — for example, under a lease — while the registration remains with the registered holder. Announcement, registration, and ownership are distinct layers.

Can someone else announce my IP block?

It can happen, either by mistake or maliciously — this is known as prefix hijacking. Publishing a ROA for your prefix and keeping IRR route objects accurate helps networks that validate route origins reject unauthorized announcements.

What is BGP origin validation?

Origin validation is the practice of checking a BGP announcement against RPKI records (ROAs) to confirm that the announcing ASN is authorized to originate the prefix. Networks that enforce it reject announcements that conflict with a published ROA.

Does BGP work with IPv6?

Yes. BGP-4 carries both IPv4 and IPv6 routing information. The announcement, propagation, and validation concepts described in this article apply to both protocols.

What is BGP peering?

Peering is a relationship in which two networks connect and exchange routes directly, typically for their own and their customers’ prefixes, rather than through a paid transit provider. Peering and transit together determine the paths available to a network’s announcements.

Also Read

• How to Prevent IPv4 Hijacking During a Transfer: 10 Security Steps
• How to Avoid Downtime When Deploying Leased IPv4 Blocks
• Understanding RIR Transfer Rules Across Regions
• What Is a /24 IPv4 Subnet and Why Is It Popular for Leasing?