How to Announce an IPv4 Prefix with BGP
To announce an IPv4 prefix, agree its origin ASN with your upstream, prepare the required authorizations, configure origination and export policy, then verify the route outside your network. Registry registration, permission to announce, BGP visibility and working traffic are separate checks.
Before the change
Have control of the prefix or the holder’s permission, a working transit or hosting arrangement, router access, a reachable test host and an agreed rollback. Record the current route and authorization state before changing it.
This runbook assumes you already have a BGP-capable connection. If you only have a VPS or broadband connection, first choose between your own origin, provider origination and a supported routed-delivery service using the ASN and delivery decision table. Confirm routing responsibilities separately when discussing IPv4 leasing.
Examples use documentation prefix 192.0.2.0/24, origin AS64496 and peers 198.51.100.1 and 198.51.100.2. Replace them with your authorized resources; these examples must not be announced to the public internet.
Agree the prefix and origin with each upstream
Send each provider a change request containing the exact prefix, origin ASN, intended activation window and technical contact. Ask which routing registries it trusts, whether it needs an AS set, and when it refreshes customer filters.
An origin ASN identifies the network introducing the prefix into BGP. An upstream can carry that announcement without becoming its origin:
| Connection | Example path seen beyond the provider | Origin |
|---|---|---|
| Via upstream A | 64497 64496 | 64496 |
| Via upstream B | 64498 64496 | 64496 |
Adding B changes the path; the origin remains yours. If a provider will originate the block itself, agree that different origin explicitly. In these ordinary AS sequences, the rightmost ASN is the origin.
Many networks filter IPv4 prefixes longer than /24. A provider’s acceptance is not proof of worldwide propagation. Confirm the required prefix lengths and external reach before committing to the design.
Align the authorization records
Prepare three independent items where required:
| Item | What to agree or verify |
|---|---|
| Letter of authorization | Holder authority, prefix, origin and provider scope accepted by the recipient |
| IRR route object | Exact prefix and origin in a database the upstream actually uses |
| RPKI ROA | A valid authorization matching the planned prefix, length and origin |
For leased space, coordinate changes with the holder or its authorized administrator. Confirm the records and provider filters before the BGP change. A portal request marked complete is not evidence that a remote router has refreshed its data.
Prepare routing and explicit export policy
On the router, configure origination for the intended prefix and the IPv4 unicast address family. Ensure the aggregate has an appropriate routing-table entry and that more-specific forwarding reaches the services using it. An aggregate discard route alone does not deliver traffic to hosts.
In FRRouting’s network configuration, origination can depend on the prefix existing in the routing table. Check your version and configuration rather than disabling that check to hide a missing route.
Use an export allowlist for your intended prefixes and lengths, with rejection for everything else. With two transit providers, do not export routes learned from one to the other unintentionally. The BGP operational security guidance covers prefix filtering and related controls. Set import policy, route limits and next-hop handling for your actual service.
Announce and verify each upstream
Apply the agreed change to one connection first. In FRR’s vtysh shell, these read-only commands separate the checkpoints:
show bgp ipv4 unicast summary
show ip route 192.0.2.0/24
show bgp ipv4 unicast 192.0.2.0/24
show bgp ipv4 unicast neighbors 198.51.100.1 advertised-routesConfirm an established session, the expected local route and origin, and export of the exact prefix. Ask the provider to confirm acceptance and onward export; your advertised-route view cannot prove either. Repeat for the second peer after the first connection passes its checks.
Use the following as an interpretation example, not captured router output. Field names and formatting vary by FRR version:
| Observation | Expected finding in this example | What it still does not prove |
|---|---|---|
| Local route | Exact 192.0.2.0/24 present with usable forwarding toward the service | Acceptance by a provider |
| Locally originated BGP path | A local path can be empty; an i code describes the ORIGIN attribute, not ASN 64496 | The origin visible after export |
| Export to A | Exact prefix permitted in A’s advertised-route view | A’s import policy accepts it |
| External ordinary path via A | 64497 64496 | The path through B works |
| External ordinary path via B | 64498 64496 | Every remote network sees this path |
Test the loss of one upstream
With an agreed maintenance window and rollback, withdraw the test announcement from one upstream at a time. Verify that the other connection still accepts and exports the intended prefix, relevant external networks can reach the test service, and replies have a working return path. Restore the connection and check recovery before testing the other one.
Record measured interruption and observation points. Do not promise instantaneous failover or assume that two established sessions mean two independent working paths. Stateful firewalls, source-address validation and asymmetric return routing can affect traffic even when the prefix remains visible.
Test external visibility and service traffic
Use more than one external looking glass or route collector. Record the observed prefix, origin, validation state, observation point and time. Collectors sample the internet; no single view proves universal reach.
Test a permitted service connection from relevant external networks and verify the return path. If the route is visible but traffic fails, inspect forwarding, firewall rules, MTU and host configuration before changing authorizations.
When a check fails
| Finding | Next action |
|---|---|
| Prefix absent from your BGP table | Check origination, routing-table requirements and address family |
| Present locally, absent from advertised routes | Inspect the neighbor’s export policy |
| Advertised, rejected upstream | Obtain the rejection reason; compare IRR source, ROA, origin and prefix length |
| Accepted upstream, missing at some destinations | Compare independent paths and downstream policies |
| Visible route, failed service traffic | Check forwarding and return traffic with the upstream and host operator |
A prefix fails from one country or one website
Compare the same destination and service from a failing network and a working control network. A country is not a single routing viewpoint; record the source ASN and time instead of attributing every failure there to a country-wide block.
Compare route observations, connection evidence and the application’s response separately. The branches are overlapping clues, not automatic diagnoses. Combine the findings in an escalation to the responsible operator; a website denial or database label alone does not establish that the prefix needs replacement.
View full diagram
| Evidence | What it helps distinguish | Next check |
|---|---|---|
| Prefix, origin and RPKI state differ between views | Announcement, authorization or route-policy issue | Ask the upstream which exact route it accepts and exports |
| Route is present, but the TCP connection does not complete | Forwarding, ACL, return path or remote filtering | Compare captures or counters at the service and edge; inspect source-address checks |
| Small probes work, but larger transfers stall | Possible MTU or path-MTU discovery problem | Test the actual packet sizes and tunnel overhead; a successful ping alone is insufficient |
| Connection reaches the application and receives an explicit denial | Destination policy, authentication, rate limit or address classification | Save the response and ask the destination operator about its policy |
| GeoIP label differs from the deployment location | A database classification discrepancy | Check the relevant database separately from routing; a country label does not prove reachability |
| A named blocklist reports a listing | That source’s particular listing criteria | Record list name, covered range and result; absence from one list does not prove acceptance elsewhere |
These findings are clues, not exclusive diagnoses. An application denial can come from an intermediary, and a visible collector route can differ from the failing network’s route. Investigate layers independently before replacing the block or changing its authorizations.
Evidence to send with an escalation
Include the exact destination IP/prefix and origin, source ASN or test network, timestamp with timezone, protocol/port, expected behavior and observed result. Add relevant route/RPKI observations, the upstream ticket and IRR source, a working comparison, and sanitized service responses or packet evidence where available. Traceroute can add context, but silent hops alone do not establish where traffic was blocked.
Send route acceptance and propagation questions to the upstream; holder-controlled authorization changes to the holder or delegated administrator; explicit application rejections to the destination operator. A marketplace status or authorization update is not proof that a hosting or transit service has completed its work.
Acceptance and rollback
Complete the change only after the intended prefix and origin pass the provider’s acceptance checks, external observations agree with the plan, and required service traffic works in both directions. For two-upstream service, include the controlled failover and recovery results. Store the evidence and owners in the change record; avoid a universal propagation-time target.
For an origin change, stage authorization for the new origin before cutover and retain the old authorization only for the agreed transition and rollback period. Withdraw unintended announcements if necessary; remove obsolete records after confirming the intended state. Keep the provider tickets and observations with the change record.