A clearer path
through BGP.

01 / The basics

Networks exchange reachability.

An autonomous system, or AS, is a network or group of networks presented to the Internet under a common routing policy. Its autonomous system number, or ASN, identifies it in routing exchanges. An IP prefix describes a range of addresses, such as an IPv4 or IPv6 block.

Two BGP routers establish a session and advertise routes: the address ranges they can reach, together with attributes used in route selection. The receiving network applies its own policy to decide which routes to accept and use. An advertisement is information about a path, not a reservation of capacity or a guarantee that every application works.

02 / Is it useful?

Consider the problem before the protocol.

BGP is also used with one provider for particular routing needs. Conversely, two providers do not automatically require the customer to run BGP.

03 / Getting ready

Identify your routing resources.

For a public Internet BGP deployment, establish which organization will operate the routing, which ASN is used, and which public prefixes may be announced. Some designs use a provider’s resources or managed routing; others use resources held by the business. Ask the provider and, where relevant, the regional Internet registry about current eligibility, registration, fees, and responsibilities.

In North America, ARIN provides guidance on requesting Internet number resources. Having an ASN does not itself provide public address space. Address assignments, route authorization, and upstream acceptance are separate matters. Check IPv4 and IPv6 requirements separately. Our business IP addresses guide explains the addressing basics.

04 / Traffic in both directions

Outbound and inbound paths are different decisions.

Your routers and policies influence which provider your network uses to send traffic out. For traffic coming in, you can advertise routes and use agreed attributes to influence external networks, but those networks make their own routing decisions. Inbound and outbound traffic need not follow the same provider or physical path.

Ask whether you need a default route, a selection of routes, or a full Internet routing table. The choice affects router memory, processing, operations, and troubleshooting. Ensure the equipment can support the intended IPv4 and IPv6 tables, policies, and growth.

A BGP session can remain established while an application or downstream path is impaired. Detection, route withdrawal, convergence, firewall state, and application behavior all affect recovery. Confirm the expected behavior in a controlled test.

05 / Routing safeguards

Advertise only what you intend.

Agree on explicit import and export policies with each peer. Filters, route limits, peer authentication where supported, and change controls help reduce the effects of errors. Do not advertise provider routes onward unless that transit is explicitly intended and authorized.

RPKI route origin authorizations can state which AS is authorized to originate a prefix and the permitted prefix length. Networks that perform origin validation can use that information in their policy. Origin validation does not verify the complete path or guarantee that traffic is safe or reachable; it works alongside filtering, monitoring, and operational review.

Keep registrations and authorizations current when adding an origin, changing providers, or transferring address space. Coordinate any change with your registry, providers, and network team before it is made.

06 / Put it into practice

Design, test, and keep records.

1. 01

   Map the dependencies

   Document circuits, entrances, building pathways, routers, power, providers, and the facilities on which they depend. Shared components can affect both connections.

2. 02

   Agree on the routing plan

   Document peer addresses, ASN, authorized prefixes, route policies, expected route volume, monitoring, and responsibility for each connection. Store sensitive configuration securely.

3. 03

   Test the real failure

   In an approved maintenance window, test the scenarios that matter, observe routing and application recovery, and keep a rollback plan. Record outcomes and address any shared dependencies.

For the physical and organizational side of resilience, see Internet redundancy and provider independence.

07 / Planning checklist

Questions for your network team and providers.

• Which failure or operational need are we trying to address?
• Who operates the routers and routing policy, and who responds to an incident?
• Which ASN and address blocks will be used? Who holds and maintains them?
• Which prefixes and route types will each provider accept and advertise?
• What route filters, limits, and origin authorizations are required?
• Do the hardware and team have capacity for the chosen route tables and policies?
• How will a failure be detected, and how will we test and monitor recovery?
• What facilities, paths, devices, and power supplies are still shared?