How BGP Multihoming Works: Redundancy and Load Sharing

Multihoming in BGP means connecting your network to two or more upstream providers simultaneously, so that a single provider failure does not cut off your connectivity. For a single-homed network, every packet in and out travels through one ISP — if that ISP's link goes down or their network has an internal fault, you are unreachable. Multihoming eliminates that single point of failure and, with proper configuration, also gives you control over which link carries inbound traffic.

Single-Homed vs Multihomed

Provider-Aggregatable vs Provider-Independent Address Space

A single-homed network typically uses provider-aggregatable (PA) address space: IP addresses assigned to you by your ISP, drawn from the ISP's own block. PA space is efficient for the global routing table because it aggregates into the ISP's announcement. The problem: if you change ISPs, you return the addresses and renumber every host — a painful process. If you announce PA space from a second ISP, remote routers see a prefix originated by an AS that does not own it (from the perspective of the original ISP's route), causing inconsistency and potential filtering.

Provider-independent (PI) address space is assigned directly to you by a Regional Internet Registry (RIR) — ARIN in North America, RIPE NCC in Europe, APNIC in Asia-Pacific, LACNIC in Latin America, and AFRINIC in Africa. PI space is yours regardless of which ISPs you use. You originate it from your own ASN, and both upstreams announce it to the rest of the internet. Changing ISPs is transparent to the outside world.

Getting an ASN

To run BGP with multiple upstreams, you need an Autonomous System Number (ASN). ASNs are 32-bit numbers (RFC 6793 extended the original 16-bit space). The process:

1. Become a member of your RIR (ARIN, RIPE NCC, etc.) or work with an existing member as a sponsor.
2. Submit a request demonstrating that you have a multihomed topology (or a documented plan for one).
3. Pay the applicable fee (a few hundred dollars per year for most RIRs).
4. Receive a 32-bit ASN from the 4200000000–4294967294 private range for testing, or a public ASN for production use.

Private ASNs (64512–65534 in 16-bit space; 4200000000–4294967294 in 32-bit space) are not globally routable — they must be stripped at eBGP boundaries to external peers, similar to RFC 1918 addresses in the IP layer.

Minimum Announceable Prefix Sizes

The global routing table has practical lower bounds on prefix length. Most networks filter prefixes that are too specific because they add table size without benefit and are often the result of misconfiguration or deaggregation abuse.

This means you need at least a /24 of IPv4 PI space (256 addresses) and at least a /48 of IPv6 PI space to announce a routable prefix. RIRs typically allocate at minimum a /24 for IPv4 PI and a /48 for IPv6 PI to qualifying organizations.

Session Setup with Two Upstreams

Each upstream requires a separate eBGP session. The router at your edge peers with the upstream's router on a point-to-point link (typically a /30 or /31 for IPv4, or a /127 for IPv6). The session exchanges:

• From the upstream to you — a default route, a partial table, or a full table (all ~1 million IPv4 routes), depending on your commercial agreement and router memory.
• From you to the upstream — your PI prefix(es), nothing else. Never advertise upstream A's routes back to upstream B without explicit policy — that turns you into unintended transit (discussed below).

Outbound Traffic: Which Path Leaves Your Network?

Outbound routing (your traffic leaving to reach remote destinations) is controlled by what routes your upstreams send to you and how you apply local preference. With two upstreams, typical options are:

• Default routes only — Each upstream sends a single 0.0.0.0/0. Set local-pref 200 on Transit-A's default and 100 on Transit-B's default. All outbound traffic exits via Transit-A; if that session drops, Transit-B's default becomes active.
• Full table from one, default from the other — Transit-A sends you all routes (for intelligent path selection); Transit-B sends only a default (failover). Set Transit-A's routes to local-pref 200 and Transit-B's default to 50.
• Full table from both — Requires significant router memory (a dedicated FIB TCAM or a router with ample RAM). Enables optimal exit selection per destination prefix but adds operational complexity.

Inbound Traffic: Failover and Load Sharing

Inbound traffic is controlled by remote networks' best-path decisions, not yours directly. When both upstreams announce your prefix to the internet, remote routers see two valid paths. Failover is automatic: when one upstream withdraws your prefix (because your session or link went down), remote routers converge to the other path within seconds to a few minutes depending on BGP timer configuration at each hop.

To influence which upstream carries more inbound traffic, operators use several techniques:

• AS path prepending — Announce your prefix to the less-preferred upstream with your ASN repeated 2–3 times. Remote routers see a longer path and prefer the non-prepended announcement. See AS path prepending for details and caveats.
• BGP communities — Many providers accept communities from customers that set local-pref internally. This is more reliable than prepending because it controls a higher-priority attribute. See BGP communities.
• MED — Relevant only when both upstreams are the same provider (dual PoP scenario).
• Selective announcement — Announce a longer prefix (e.g., /25 from a /24 block) only to the preferred upstream. Remote networks route to the /25 via the preferred upstream (longest-prefix-match wins) and the /24 via both.

BGP Convergence and Failover Timing

When a link or session fails, the timeline for traffic to shift is:

1. Your router detects the session drop (BGP hold timer expires, typically 90 seconds by default; BFD can reduce this to sub-second).
2. Your router withdraws the prefix from the failed session's upstream.
3. The upstream propagates the withdrawal through its network (seconds to tens of seconds).
4. Remote networks receive the withdrawal, re-run best-path, and reroute traffic to the surviving upstream.
5. Total convergence across the internet: typically 30 seconds to a few minutes, depending on BGP timer settings at each hop in the path.

For sub-second failover, deploy BFD (Bidirectional Forwarding Detection) alongside BGP. BFD detects link failures in milliseconds, triggering immediate BGP session teardown rather than waiting for the hold timer.

Creating ROAs for Your Prefixes

Once you have PI space and an ASN, create RPKI Route Origin Authorizations (ROAs) through your RIR's portal. A ROA cryptographically records that your ASN is authorized to originate your prefix (and, optionally, longer prefixes up to a specified maximum length). Networks enforcing Route Origin Validation (ROV) will drop announcements that conflict with your ROA — including both accidental misconfiguration and deliberate hijacking attempts.

For a multihomed network with prefix 203.0.113.0/24 and ASN 64500, create a ROA specifying: origin AS 64500, prefix 203.0.113.0/24, max-length /24. If you also plan selective /25 announcements for traffic engineering, create an additional ROA with max-length /25. The ROA is published in the RIR's RPKI repository and distributed via the RPKI-to-Router (RTR) protocol to routers that enforce it.

The Accidental Transit Pitfall

The most common serious mistake in multihomed BGP configuration is becoming unintended transit. If your routers accept a full routing table from Transit-A and re-advertise those routes to Transit-B (or vice versa), you have effectively made yourself a transit provider between two large networks. Traffic from Transit-B's customers destined for Transit-A's customers may start routing through your network — consuming your bandwidth and link capacity without any compensation.

The fix is strict export filtering: your router should only advertise your own prefixes to each upstream, never prefixes learned from other upstreams. On Cisco IOS:

ip prefix-list MY-PREFIXES seq 5 permit 203.0.113.0/24

route-map EXPORT-ONLY-MINE permit 10
 match ip address prefix-list MY-PREFIXES

router bgp 64500
 neighbor 198.51.100.1 route-map EXPORT-ONLY-MINE out
 neighbor 198.51.100.2 route-map EXPORT-ONLY-MINE out

This is a foundational principle of BGP operational practice — sometimes called maintaining a proper "customer cone." See BGP route leaks for what happens when this goes wrong at scale.

iBGP Between Edge Routers

In a multihomed network with two edge routers (one connected to each upstream), the routers must share route information internally so each knows the full set of available paths. This is done with iBGP sessions between the two edge routers — or, in larger networks, through a route reflector. Without iBGP, each edge router only knows about routes received via its own upstream, and the network cannot make coherent best-path decisions.

The IGP (OSPF, IS-IS, or even static routing for simple topologies) must also advertise the loopback addresses used as iBGP update sources, so sessions stay up even if a specific link between the routers changes. A best practice is to use loopback addresses for iBGP sessions rather than point-to-point link addresses — this makes the iBGP session resilient to individual link failures.

IXP as a Third Connectivity Option

For networks with the resources to participate, an Internet Exchange Point provides a third form of connectivity beyond transit providers. At an IXP, a multihomed network can establish direct peering sessions with hundreds of other networks — content providers, CDNs, other ISPs — at zero or low per-peer cost. IXP connectivity complements transit: transit provides universal reachability while IXP peering provides low-latency, high-capacity paths to specific networks.

A heavily peered network may find that the majority of its traffic (by volume) traverses IXP links rather than transit, because the largest content providers (Google, Meta, Netflix, Akamai) are present at all major IXPs. Adding IXP connectivity on top of two transit providers creates a genuinely resilient and well-optimized routing posture. See peering and economics of internet peering for context.

Practical Considerations

Beyond the technical configuration, multihoming involves operational overhead: maintaining two commercial relationships with ISPs, monitoring two sessions, handling prefix filter updates when your address space changes, and coordinating ROA maintenance. Many organizations find that the reliability benefit far outweighs the cost, particularly for services where downtime is expensive.

A critical operational step is registering your prefixes in the IRR (Internet Routing Registry) and creating route objects for each prefix you plan to announce. Your upstreams use IRR to build prefix filters — if your prefix is not registered, some providers will reject your BGP announcement entirely, leaving your network unreachable via that upstream. Register route objects and an as-set in the IRR database appropriate for your region (ARIN DB, RIPE DB, RADB) before expecting announcements to propagate.

You should also deploy monitoring for your BGP sessions and announced prefixes. If a session goes down silently and you don't have alerting, you may not discover the failure until customers report problems. BGP monitoring tools track session state changes, prefix withdrawal events, and unexpected path changes — any of these can indicate a multihomed failover scenario or a network problem requiring investigation. The combination of proper export filtering, RPKI ROAs, IRR registrations, and active monitoring is the operational foundation of a well-run multihomed network.

Related: AS path prepending, BGP best-path selection, route aggregation, the default-free zone, BGP communities.

Explore It Live

• AS13335 (Cloudflare) — a heavily multihomed network with hundreds of upstreams and peers
• AS20940 (Akamai) — another example of extreme multihoming for global CDN resilience
• 1.1.1.1 — trace the AS path to Cloudflare's DNS and observe short paths from many vantage points

The BGP looking glass shows live route data including AS paths, which reveal each network's upstream relationships.