Skip to main content
i.lease IPv4 marketplace
Login
i.lease IPv4 marketplace

IPv4 guide

What Is BGP? Border Gateway Protocol, ASN, and IP Prefixes

What is BGP? The short answer

BGP stands for Border Gateway Protocol. It is the control-plane protocol autonomous systems use to exchange reachability information for IP prefixes and apply their own routing policy. A BGP announcement tells a neighboring network that a prefix is reachable through a path. The neighbor may accept, reject, prefer, or re-advertise that route according to local policy.

BGP does not assign IP addresses, grant an Autonomous System Number (ASN), prove who holds a prefix, or guarantee that packets and applications work. Registration and contractual authority, documentary and machine-readable routing authorization, accepted control-plane routes, and data-plane reachability are related but distinct evidence.

BGP, ASN, IP prefix, and forwarding path

The separate roles behind an Internet route
ItemWhat it isWhat it does not prove
IP prefixA range of IPv4 or IPv6 addresses expressed in CIDR notation, such as the documentation prefix 203.0.113.0/24.That the range is currently announced, accepted, reachable, or authorized for a particular origin ASN.
ASNAn identifier for an autonomous system. Public ASNs appear in Internet routing; private ASNs have limited internal or coordinated uses.That the organization holds a particular prefix or that every route carrying the ASN is legitimate.
BGP routeReachability information for a prefix plus path attributes that a network can evaluate under local policy.Registry rights, universal acceptance, application availability, or the exact path every packet will take.
Forwarding pathThe installed data-plane next hops that routers use to send packets after route and policy decisions.That return routing, DNS, firewalls, transport, TLS, or the destination application will succeed.

The related ASN guide explains public and private ASN ranges and when an organization may need its own routing identity.

How a BGP announcement works

  1. Establish the session. Configured BGP neighbors identify each other, negotiate capabilities, and keep the session alive. A session being up proves only that the peers can exchange BGP messages.
  2. Advertise or withdraw reachability. UPDATE messages announce reachable prefixes with path attributes or withdraw routes that are no longer offered.
  3. Apply import policy. The receiving network checks the prefix, origin, next hop, communities, relationship, filters, RPKI state, and other local requirements before making the route eligible.
  4. Select and install a route. The network compares eligible routes under its own decision process. A selected BGP route can then contribute a forwarding entry if its next hop is resolvable.
  5. Apply export policy. The network decides which selected or eligible routes it may announce to each customer, peer, provider, or route server.

There is no single global routing table that every network must copy. Each autonomous system receives a different set of routes, applies its own policy, and exports a permitted subset. An external collector is therefore a useful observation point, not proof of universal visibility.

Does BGP always choose the shortest AS path?

No. AS-path length can influence selection, but it is not a universal first rule and it does not override every business or engineering policy. RFC 4271 makes the computation of route preference a local matter. Operators commonly use attributes and policy so a longer path from a customer, peer, protected region, or preferred transit can be selected over a shorter alternative.

Evidence commonly involved in BGP route selection
InputOperational purposeImportant limit
Import eligibilityReject routes that fail prefix, origin, relationship, next-hop, community, or other policy checks.An ineligible route is not rescued merely by having a short AS path.
Local preference or local policyExpress which ingress or relationship the autonomous system prefers.The value and policy are local; outsiders cannot infer them reliably from a public path.
AS_PATHRecords the autonomous systems through which an announcement has propagated and helps detect the local ASN in a loop.Length is only one input and does not prove authorization or physical distance.
NEXT_HOP and reachabilityIdentify the next address that must be reachable before the route can be used.A syntactically valid announcement can still have an unusable or withdrawn next hop.
Other attributes and tie-breaksSupport traffic engineering and deterministic selection among remaining candidates.Exact ordering and policy vary by implementation and operator configuration.

What do registry records, LOA, IRR, ROA, and BGP observations prove?

Authority and routing evidence for an IP prefix
EvidenceUseful meaningWhat it cannot establish alone
Registry and contract recordsIdentify the registered resource context and the parties, scope, term, and duties of an allocation, transfer, or lease.That an upstream will accept a route or that the prefix is reachable now.
Letter of Authorization (LOA)Documents permission for a named party, prefix, origin ASN, and purpose when an upstream or platform requests it.A globally standardized or cryptographic authorization. Format, signatory checks, expiry, and acceptance depend on the recipient.
IRR route or route6 objectPublishes a prefix and origin ASN in Routing Policy Specification Language so operators can build or review route filters.Cryptographic origin validation, current contractual authority, use by every network, or accurate data in every IRR source.
RPKI ROA and validated payloadCryptographically authorizes an origin ASN for a prefix and optional maximum length, producing origin-validation states for matching BGP announcements.The complete AS path, lease terms, an LOA, route propagation, or application reachability.
Observed BGP routeShows that one collector or peer received a prefix, origin, AS path, and attributes at an observation time.Authorization, universal visibility, return-path health, or delivery of packets to the intended service.

These records should agree on the exact prefix and intended origin before a change window. Agreement reduces avoidable filtering, but it still does not force another autonomous system to accept or prefer the route.

What BGP origin validation checks

Route Origin Validation compares a BGP announcement with validated ROA payloads that cover the announced prefix. A route can be Valid when an applicable payload authorizes the origin ASN and prefix length, Invalid when covering authorization exists but the origin or allowed length does not match, or Not Found when no validated payload covers it. Not Found does not by itself mean the route is fraudulent.

ROA maximum length deserves change control. Authorizing only an aggregate while announcing a more-specific route can make that route Invalid; allowing unnecessary more specifics expands what the ROA authorizes. Prepare the exact origin and prefix set, validate the result before announcement, and keep authorization changes synchronized with routing changes.

Origin validation does not validate the complete AS path. A route may be origin-valid yet leaked beyond its intended relationship, diverted later in the path, blackholed, or unable to serve the application. The RPKI and ROA guide covers those boundaries in more detail.

Should an upstream announce the prefix or should you use your own ASN?

Common prefix-origination models
ModelWhen it can fitOperating duties and limits
Upstream originates from its ASNA bounded deployment where one provider operates routing and the holder or lessee authorizes that provider ASN.Align the contract, LOA if requested, IRR data, and ROA with the provider ASN. Moving providers requires a coordinated origin and record change.
Your ASN with one upstreamAn organization needs its own routing identity but initially uses one transit relationship.It must operate or delegate BGP policy and maintain origin authorization. One upstream does not by itself provide provider redundancy.
Your ASN with multiple upstreamsThe service has measured continuity, path-control, or provider-migration requirements.It adds policy, filtering, capacity, monitoring, failure-domain, and coordination work. Multihoming reduces some dependencies but is not a failover guarantee.

Leased address space can use any of these models only when the holder's authority, the lease terms, the intended origin, and the upstream's acceptance process support it. Do not infer permission from the fact that a router accepts a configuration command.

Hijacks, route leaks, filtered routes, and data-plane failures

  • Misorigin or hijack: another AS originates a prefix without the intended authorization, whether by mistake or deliberately. Accurate ROAs and route filters can help other networks reject some misoriginations.
  • Route leak: an AS propagates routes beyond the scope expected by customer, provider, peer, or route-server relationships. An origin-valid route can still be leaked because origin validation is not path validation.
  • Filtered or partial announcement: an upstream or remote network rejects the prefix, origin, length, AS path, community, or stale filter. Some observers may see the route while others do not.
  • Session or next-hop failure: transport, authentication, capability, keepalive, next-hop resolution, or router policy prevents the route from becoming usable.
  • Data-plane or application failure: the route exists, but reverse routing, ACLs, DDoS controls, MTU, NAT, DNS, TLS, host configuration, or the service itself fails.

The IPv4 hijacking prevention guide explains how to sequence a prefix handover without confusing registration, authorization, and observed routing.

How long does BGP propagation or failover take?

There is no universal BGP propagation or failover time. A change depends on when the holder, RPKI and IRR publishers, upstream filter systems, router sessions, local import and export policies, and remote networks process it. Some networks may never accept the route. Withdrawal and alternate-path selection also vary by topology, session state, implementation, and policy.

Measure the event instead of promising a number. Record the authorization and provider-change timestamps; confirm the upstream accepted and advertised the exact prefix and origin; observe multiple independent collectors; test RPKI state; then run synthetic traffic from representative networks over the intended address families. Track DNS, connection, TLS, return path, packet loss, and application results separately. The deployment guide on avoiding downtime with leased IPv4 blocks provides a wider cutover sequence.

BGP deployment checklist for a leased or acquired prefix

  1. Fix the scope. Record the exact prefix, intended more specifics, address family, RIR, registered holder, contract or lease authority, term, renewal, withdrawal, and return duties.
  2. Choose the origin model. Name the exact public origin ASN, upstreams, sites, sessions, communities, route limits, and responsible operators.
  3. Align evidence before cutover. Prepare the recipient-specific LOA when requested, authoritative IRR route objects, and ROAs with the intended prefix and maximum length. Remove conflicting stale records through the responsible party.
  4. Agree provider filters and timing. Obtain confirmation that the upstream's import policy is ready. Do not treat a submitted ticket as proof that routers have accepted the change.
  5. Define observability. Select independent collectors, RPKI validators, real client networks, packet and application checks, timestamps, and an owner for every signal.
  6. Test a bounded change. Announce only the approved routes, confirm the local session and advertised route, then verify external control-plane and data-plane results.
  7. Exercise failure and rollback. Test a withdrawal or alternate path within the authorized window, preserve the old state, and identify who can restore routing and authorization records.
  8. Operate the lifecycle. Monitor origin changes, invalid states, unexpected more specifics, route leaks, abuse contacts, expiry, renewal, provider changes, and the final route withdrawal and record cleanup.

Prepare the routing brief before choosing IPv4 capacity

A useful request states the prefix size and RIR, intended origin ASN, upstream model, regions, more-specific policy, LOA format, IRR source, ROA access, change window, monitoring, acceptance criteria, rollback owner, term, and return plan. With those facts prepared, review managed IPv4 leasing for an address-space path that matches the operating model. Availability, third-party acceptance, propagation, reachability, reputation, and performance remain subject to verification.

BGP FAQs

What does BGP stand for?

BGP stands for Border Gateway Protocol. It exchanges reachability information and path attributes between autonomous systems so each network can apply its own routing policy.

Is BGP an IP address or an ASN?

Neither. BGP is a routing protocol. An IP prefix is the destination range, and an ASN identifies an autonomous system that can originate or propagate routes.

Does announcing an IP prefix prove ownership?

No. An observed announcement proves only that a route was received at an observation point. Registry records and contracts describe resource authority, while LOA, IRR, and RPKI records provide different forms of routing evidence. None is replaced by the announcement itself.

Do I need my own ASN to use public IPv4 space?

Not always. An authorized upstream can originate a prefix from its ASN. Your own public ASN is relevant when you need an independent routing identity and can operate or delegate the associated policy, security, monitoring, and lifecycle duties.

What is a BGP LOA?

A Letter of Authorization documents permission for a named party or ASN to announce specified prefixes when an upstream or platform requests it. It is manually reviewed, recipient-specific evidence rather than a globally standardized or cryptographically validated routing object.

What is the difference between an IRR route object and a ROA?

An IRR route object publishes a prefix and origin ASN as routing-policy data that operators may use to build filters. A ROA is a cryptographically signed RPKI object that authorizes an origin ASN and prefix length for Route Origin Validation. Operators may use both, and neither proves data-plane reachability.

How long does BGP propagation take?

There is no universal time. Provider workflows, filters, sessions, policies, topology, and remote acceptance all affect the result. Verify dated observations from the upstream, independent collectors, RPKI validation, and representative application tests.

Does RPKI validate the complete BGP path?

Route Origin Validation checks the prefix, origin ASN, and authorized length against validated ROA data. It does not validate every AS in the path, prevent every route leak, or prove that packets reach the intended service.

Can leased IPv4 addresses be announced from my ASN?

They can when the registered holder's authority, lease terms, origin model, upstream process, LOA if requested, IRR objects, and ROAs support that exact prefix and ASN. Confirm acceptance and rollback before production use.

Primary technical sources

Back to Blog