What Is BGP Multihoming? Benefits, Risks and How It Works

BGP multihoming is a network architecture in which an organisation connects its network to two or more external Internet providers and uses Border Gateway Protocol to exchange routing information between them.

The main goal is usually resilience.

Instead of depending entirely on one provider:

Network → Provider A → Internet

a multihomed network may use:

Provider A
↗
Organisation ASN
↘
Provider B

If one path becomes unavailable, BGP can make another path available, depending on the network's addressing, routing policy and physical design.

But multihoming does not automatically make a network outage-proof.

Two providers may still depend on:

• the same fibre path;
• the same data centre;
• the same upstream network;
• the same power infrastructure;
• or the same submarine cable.

Understanding BGP multihoming therefore requires looking beyond the number of ISP connections.

The more important question is:

How independent are the paths underneath those connections?

What Is BGP Multihoming?

Multihoming broadly means connecting a network to more than one external network or provider.

For Internet-scale BGP multihoming, an organisation typically operates its own Autonomous System and advertises its prefixes through multiple upstream providers.

The IETF's RFC 4116: IPv4 Multihoming Practices and Limitations describes the common BGP approach as announcing routes through two or more transit providers so that the Internet can see multiple possible paths toward the multihomed site.

That creates two important forms of choice.

For outbound traffic, the organisation may have multiple ways to reach the Internet.

For inbound traffic, other networks may have multiple paths through which they can reach the organisation.

BGP provides the routing-policy mechanisms used to manage those choices.

Why Do Networks Use Multihoming?

The most common reason is reliability.

Internet connectivity has become critical infrastructure for:

• cloud platforms;
• financial systems;
• data centres;
• universities;
• SaaS providers;
• online services;
• enterprise applications;
• public services;
• and telecommunications networks.

A failure in a single upstream connection can therefore affect far more than web browsing.

Multihoming attempts to reduce dependence on one external connectivity path.

The goals identified in Internet engineering literature include:

• reliability;
• fault recovery;
• load sharing;
• performance optimisation;
• and routing-policy flexibility.

The IETF has long recognised reliability, load sharing and performance tuning as important motivations for multihoming. See RFC 5772.

Single-Homed vs Multi-Attached vs Multihomed Networks

These terms are sometimes used interchangeably, but they describe different architectures.

Single-Homed

A single-homed network depends on one external connectivity path.

The architecture is simple:

Organisation → ISP A → Internet

If the upstream connection or provider fails, Internet connectivity may be lost.

Multi-Attached

A network can have two physical links to the same provider.

For example:

Link 1 → Provider A

Link 2 → Provider A

This can protect against some failures, such as:

• one router interface failing;
• one local circuit failing;
• or one access connection being interrupted.

But it does not protect against the failure of Provider A itself.

RFC 4116 refers to this as multi-attachment and distinguishes it from multihoming across independent transit providers.

Multihomed

A multihomed network connects to multiple external Autonomous Systems.

For example:

Provider A
↗
Customer AS
↘
Provider B

This architecture can provide protection against a wider range of upstream failures—provided the underlying infrastructure is genuinely diverse.

How Does BGP Multihoming Work?

A simplified BGP multihoming deployment has four main components.

1. An Autonomous System

The organisation operates an Autonomous System with its own ASN.

An ASN identifies a routing domain that can express its own external routing policy.

LARUS Foundation's 2026 ASN analysis explains how ASNs allow independently operated networks to participate in global routing.

2. Internet Address Space

The organisation needs IP address space that can be routed appropriately through the upstream providers.

Classic BGP multihoming commonly uses Provider-Independent address space, because the address block is not tied to one particular transit provider.

RFC 4116 describes Provider-Independent, or PI, addressing as an established approach for IPv4 multihoming.

Provider-assigned addressing can also be used in some architectures, but the design becomes more dependent on the providers and addressing model.

3. Multiple Upstream Networks

The organisation connects to at least two external networks.

For example:

AS64500 → ISP A

and:

AS64500 → ISP B

4. BGP Sessions

The organisation establishes BGP sessions with its providers.

Through those sessions, it exchanges route information.

BGP's core protocol behaviour is specified in RFC 4271.

The organisation can announce its prefix through both providers.

The rest of the Internet may then see more than one route toward that prefix.

A Simple BGP Multihoming Example

Imagine a company operates:

ASN: AS65010

and the public prefix:

203.0.113.0/24

It connects to:

Provider A — AS64501

and:

Provider B — AS64502

The company announces:

203.0.113.0/24

through both providers.

The simplified routing structure becomes:

Provider A / AS64501
↗
AS65010 — 203.0.113.0/24
↘
Provider B / AS64502

Networks elsewhere on the Internet may now learn two possible paths toward the same destination.

One might see:

64501 65010

while another path could appear as:

64502 65010

BGP then uses routing policy and path attributes to determine which route is preferred.

What Happens When One Provider Fails?

Suppose the normal route uses Provider A.

Then Provider A becomes unavailable.

The BGP route through that provider may be withdrawn.

Networks that previously selected:

Internet → Provider A → Customer

can eventually select:

Internet → Provider B → Customer

instead.

Likewise, the customer's outbound routers can stop using the failed path and route traffic through Provider B.

This is the basic resilience benefit of BGP multihoming.

However, failover is not necessarily instantaneous.

BGP needs time to:

• detect failure;
• withdraw unavailable routes;
• propagate changes;
• recalculate preferred paths;
• and converge on new routing decisions.

RFC 4116 notes that although BGP-based multihoming can provide session survivability, transport sessions may still time out when convergence following a routing change takes too long.

Therefore:

Multihoming reduces dependency on a single route. It does not guarantee zero interruption.

Does BGP Multihoming Require an ASN?

For classic multihoming in which an organisation connects to multiple providers and expresses its own independent routing policy, a public ASN is normally required.

The IETF's RFC 1930 describes a multihomed site as one connected to more than one service provider and explains why a distinct AS enables that site to express routing policy independently from its providers.

However, not every organisation with two Internet connections needs its own public ASN.

Other architectures can use:

• NAT;
• SD-WAN;
• application-level failover;
• multiple provider-assigned address ranges;
• DNS-based traffic management;
• or provider-managed redundancy.

These can improve availability without making the organisation an independently routed Autonomous System.

The right architecture depends on the operational requirement.

Do You Need Provider-Independent IP Addresses?

Not in every possible multihoming design.

But Provider-Independent address space is particularly useful for classic BGP multihoming.

With PI addressing:

the prefix belongs to the network's routing identity rather than to one upstream path.

The network can announce the same prefix through multiple providers.

That supports provider diversity while allowing external systems to continue reaching the same address space.

This can be important when public IP addresses become embedded in:

• customer allowlists;
• firewall rules;
• APIs;
• DNS;
• security policies;
• partner integrations;
• and service configurations.

LARUS Foundation discusses this broader relationship between IP addresses, ASNs and operational continuity in What Is Network Identity and Why Does It Matter?.

BGP Multihoming and Network Identity

Multihoming is not only about adding a backup circuit.

It can also separate a network's public routing identity from one specific connectivity provider.

Consider two designs.

Provider-Dependent Design

Business → ISP A → Internet

The business uses addressing and routing closely tied to ISP A.

Changing provider may require changing:

• public addresses;
• firewall rules;
• DNS;
• allowlists;
• partner configurations;
• and security policies.

Independent Routing Design

ISP A
↗
Business ASN + stable prefix
↘
ISP B

Connectivity providers can change while the public routing identity remains more stable.

This is one reason ASN and address portability can matter for network continuity.

Outbound Traffic Engineering

A multihomed network usually has more control over its outbound traffic than its inbound traffic.

Why?

Because the network controls its own routers.

If both providers offer routes toward the Internet, the operator can apply local routing policy to determine the preferred exit.

BGP attributes commonly used in outbound policy include:

• Local Preference;
• route preference;
• communities;
• and internal policy rules.

For example:

Cloud traffic → Provider A

while:

general Internet traffic → Provider B

or:

Provider A = primary

Provider B = backup

The exact policy depends on operational goals.

Inbound Traffic Engineering

Inbound traffic is more complicated.

Once a route leaves the organisation's network, remote networks apply their own BGP policies.

The multihomed organisation can influence those choices but does not completely control them.

Common tools include:

• AS-path prepending;
• selective announcements;
• BGP communities;
• provider-specific routing policies;
• and, in some designs, more-specific prefix announcements.

For example, if a network wants Provider A to be preferred, it might announce:

Through A:

65010

Through B:

65010 65010 65010

Some remote networks may prefer the shorter AS path through Provider A.

But this is not guaranteed because BGP path selection considers more than AS-path length.

Remote networks can apply their own Local Preference and commercial policies.

Therefore:

BGP provides routing influence, not end-to-end routing command.

Multihoming vs Load Balancing

Multihoming and load balancing are related but not identical.

Multihoming means maintaining connectivity through multiple external networks.

Load balancing means distributing traffic across multiple paths or systems.

A multihomed network can choose to use:

• one primary link and one backup;
• both providers simultaneously;
• different providers for different destinations;
• or asymmetric inbound and outbound paths.

So a network can be multihomed without evenly balancing traffic.

Likewise, traffic can be load-balanced internally without the network being multihomed to multiple ISPs.

Why Multihoming Matters in 2026

The global BGP routing system continues to grow.

The APNIC CIDR Report for 15 October 2026 observed approximately:

See the current APNIC CIDR Report.

These numbers illustrate the scale of today's inter-domain routing environment.

Tens of thousands of Autonomous Systems independently originate routes and make routing-policy decisions.

Multihoming is one mechanism through which those networks can avoid relying on a single connectivity path.

But the growing routing table also highlights one of multihoming's trade-offs.

Multihoming Can Add Routes to the Global BGP Table

The benefits of multihoming come with a scalability cost.

Route aggregation allows multiple networks to be represented efficiently by larger prefixes.

Multihoming can sometimes require a more-specific route to remain globally visible so that multiple providers can route traffic toward an independently connected site.

This reduces aggregation.

RFC 4116 specifically notes the tension between IPv4 multihoming and the CIDR architecture, which was designed partly around hierarchical route aggregation.

At Internet scale, the trade-off is:

more independently routable networks

versus:

a larger global routing table.

That does not mean multihoming is undesirable.

It means independent routing has a shared infrastructure cost.

What Are More-Specific Prefixes?

Suppose a provider announces:

203.0.112.0/20

A customer inside that address range may announce:

203.0.113.0/24

The /24 is more specific than the /20.

Under longest-prefix matching, routers generally prefer the more-specific route for addresses covered by that prefix.

This technique can support certain multihoming arrangements.

But widespread deaggregation increases the number of routes that global BGP routers must maintain.

This is one reason route aggregation remains important.

The Biggest Multihoming Mistake: Assuming Two ISPs Mean Two Independent Paths

Connecting to two providers looks redundant.

But the underlying infrastructure may still share the same failure domain.

Consider:

ISP A
↘
same metro fibre conduit
↗
ISP B

A construction accident that cuts that conduit could disconnect both.

Or:

ISP A
↘
same data centre
↗
ISP B

A facility-wide power failure can remove both connections.

The same problem can occur with:

• shared submarine cables;
• shared backhaul providers;
• shared carrier hotels;
• common upstream transit;
• shared cloud regions;
• shared routers;
• and shared power systems.

This produces one of the most important principles of network resilience:

Logical diversity is not the same as physical diversity.

LARUS Foundation explores this distinction in Why Decentralisation Improves System Survivability.

What Failure Types Should a Multihomed Design Consider?

A resilient design should examine multiple layers.

Local Circuit Failure

What happens if one fibre circuit fails?

Router Failure

Do both upstream connections terminate on one router?

If so, the router may remain a single point of failure.

Data Centre Failure

Do both connections terminate in the same building?

Provider Failure

Are the upstream providers actually independent?

Upstream Transit Failure

Do both providers ultimately depend on the same larger backbone?

Power Failure

Are both routers and circuits supported by independent power systems?

Regional Failure

Can a flood, earthquake or major infrastructure incident affect both paths?

Configuration Failure

Could one incorrect routing change affect both providers simultaneously?

True resilience requires looking across these layers rather than counting ISP logos.

BGP Multihoming and RPKI

Multihomed networks also need to consider routing security.

Resource Public Key Infrastructure allows a resource holder to create a Route Origin Authorisation specifying which ASN is authorised to originate a prefix.

Suppose:

203.0.113.0/24

is legitimately originated by:

AS65010

through both Provider A and Provider B.

The origin ASN remains:

AS65010

even though the upstream AS path changes.

A ROA authorising AS65010 can therefore be consistent with announcements through either provider.

But if a backup design changes the origin ASN, the corresponding RPKI authorisation also needs to support that routing design.

Incorrect ROA configuration can result in an otherwise intended route appearing RPKI Invalid.

LARUS Foundation's RPKI Adoption in 2026 explains the distinction between Valid, Invalid and Not Found routes and why RPKI is becoming increasingly important in operational routing.

Multihoming Does Not Replace Routing Security

Multiple providers improve connectivity options.

They do not automatically protect against:

• route leaks;
• incorrect announcements;
• route hijacking;
• configuration errors;
• or incorrect RPKI records.

A mature multihomed deployment should consider:

• prefix filtering;
• RPKI Route Origin Validation;
• IRR records;
• maximum-prefix limits;
• BGP session protection;
• route-policy controls;
• monitoring;
• and alerting.

Redundancy without routing discipline can create additional complexity rather than additional resilience.

BGP Multihoming vs IXP Peering

Multihoming and IXP peering are also different concepts.

A network may connect to:

Provider A + Provider B

for Internet transit while also connecting to an:

Internet Exchange Point

for direct peering.

The roles are different.

LARUS Foundation's What Is an Internet Exchange Point (IXP)? explains how independent networks exchange traffic through public peering infrastructure.

A sophisticated network might therefore use:

multiple transit providers

plus:

IXP peering

plus:

private interconnections

to create several different forms of connectivity.

Multihoming Is About Choice, Not Just Backup

A common view of multihoming is:

Provider B is there in case Provider A fails.

That is useful, but incomplete.

Multiple upstream paths can also give operators choices about:

• cost;
• latency;
• congestion;
• destination;
• traffic type;
• regional routing;
• maintenance;
• performance;
• and policy.

The network may dynamically or administratively choose different paths for different traffic.

That creates something deeper than redundancy:

routing autonomy.

The organisation can make more of its connectivity decisions locally rather than inheriting all routing choices from one upstream provider.

Does Multihoming Make the Internet More Decentralised?

Potentially.

A network dependent on one provider has fewer routing options than a network that can independently choose between several providers and peers.

At scale, multihoming can support:

• diversified routing relationships;
• more autonomous network policy;
• competitive upstream choice;
• multiple paths;
• and reduced dependence on one network.

But the decentralisation benefit depends on whether those paths are genuinely independent.

Consider two networks.

Network A

Two ISP contracts.

But both ISPs depend on the same physical route and same upstream backbone.

Network B

Two providers.

Different fibre entrances.

Different data centres.

Different upstream dependencies.

Regional peering at an IXP.

Independent routing policy.

Both networks are technically multihomed.

But Network B has significantly greater structural diversity.

This is why the number of BGP sessions alone cannot measure resilience.

BGP Multihoming and Operator Control

One of BGP's defining characteristics is that each Autonomous System can apply its own routing policy.

The global Internet does not require one central router to choose paths for every network.

Instead, thousands of networks coordinate by exchanging route information while retaining local control over their decisions.

Multihoming demonstrates this architecture clearly.

Shared protocols provide interoperability.

Globally unique ASNs and prefixes provide identifiers.

But operators still determine:

• who they connect to;
• which routes they accept;
• which routes they announce;
• what their preferred paths are;
• and how they respond when infrastructure changes.

This combination of coordination and local routing autonomy is one of the foundations of the Internet's network-of-networks architecture.

BGP Multihoming Design Checklist

Before treating a dual-provider design as resilient, an operator should ask:

Are the upstream providers independent?

Do the connections use different physical fibre routes?

Do they enter the building at different points?

Do the circuits terminate on separate edge routers?

Are power dependencies separated?

Do both providers depend on the same upstream backbone?

Is the IP address space portable between providers?

Is the ASN under the operator's control?

Are routing policies documented?

Are ROAs correct?

Are IRR records current?

Are prefix filters configured?

Is failover tested regularly?

Is BGP convergence monitored?

Can DNS, firewalls, APIs and allowlists continue using the same addresses during failover?

A second ISP contract is only the beginning of a resilient design.

Frequently Asked Questions

What is BGP multihoming?

BGP multihoming is an architecture where a network connects to two or more external networks and uses BGP to exchange routing information, giving it multiple possible Internet paths.

Why is BGP multihoming used?

The main reasons include redundancy, fault recovery, routing flexibility, traffic engineering, performance optimisation and reduced dependence on one provider.

Do I need an ASN for BGP multihoming?

For classic multihoming across multiple ISPs using an independent external routing policy, an organisation normally uses its own ASN. Other redundancy methods can provide multiple Internet connections without operating a public ASN.

Do I need Provider-Independent IP addresses?

Not every multihoming architecture requires PI space, but PI addressing is commonly used for classic BGP multihoming because the same address prefix can remain independent of a specific upstream provider.

Can BGP multihoming prevent outages?

It can reduce the risk of outages caused by the failure of one path or provider, but it cannot eliminate every outage. Shared fibre, data centres, upstream infrastructure, power and routing configuration can remain common failure points.

Is dual-WAN the same as BGP multihoming?

Not necessarily. Dual-WAN can use two Internet connections without operating BGP or an independent ASN. BGP multihoming normally implies inter-domain routing across multiple external networks.

Is multihoming the same as load balancing?

No. Multihoming provides multiple connectivity paths. Load balancing distributes traffic across paths. A multihomed network can use one connection as primary and another purely for backup.

Can multihoming use both ISPs at the same time?

Yes. Networks can use both paths simultaneously or operate a primary/backup design depending on routing policy.

How does BGP choose between two ISPs?

BGP considers routing policy and attributes such as Local Preference and AS path. Operators can configure policies to prefer one provider or use different providers for different routes.

Why is inbound BGP traffic engineering difficult?

The local network does not control the routing policies of every remote Autonomous System. It can influence inbound routing through announcements, communities and AS-path manipulation, but remote networks ultimately make their own route-selection decisions.

Does BGP failover happen instantly?

No. Failure detection and BGP convergence take time. The exact interruption depends on the network architecture, timers, failure type and routing environment.

Does multihoming increase the global routing table?

It can. Some multihoming designs require independently visible or more-specific prefixes, which can reduce route aggregation and add entries to the global BGP table.

How does RPKI affect multihoming?

RPKI allows networks to verify whether the origin ASN announcing a prefix is authorised. A multihomed network should ensure that its ROAs match the intended origin ASN and prefix announcements across all providers.

Can a network use multihoming and an IXP together?

Yes. A network can use multiple transit providers for broad Internet connectivity while also connecting to IXPs for direct peering.

Conclusion

BGP multihoming is one of the Internet's most important mechanisms for giving networks multiple connectivity options.

Instead of depending on:

one provider

one path

and:

one external routing relationship,

a multihomed network can exchange routing information with multiple external networks.

This can improve:

resilience,

routing flexibility,

traffic engineering,

and:

operator choice.

But the presence of two providers does not itself create true redundancy.

If both connections depend on the same fibre, facility, upstream network or power system, one failure can still remove both.

For this reason, the strongest multihoming designs consider two different layers:

routing diversity

and:

infrastructure diversity.

Both matter.

The 2026 Internet routing system now contains roughly 79,600 visible Autonomous Systems and more than 1.08 million IPv4 BGP prefixes, illustrating the scale at which independently operated networks exchange routing decisions. APNIC CIDR Report

Multihoming is one expression of that architecture.

It allows an operator to participate in a globally coordinated routing system without surrendering every connectivity decision to one external provider.

That reflects an important principle of Internet infrastructure:

Resilience is not created simply by adding more connections. It comes from creating genuinely independent paths while preserving the ability of each network to make its own routing decisions.

For operators, that means the right question is not:

“Do we have two ISPs?”

It is:

“If one path fails, how much of the other path is truly independent?”

That distinction is what turns multihoming from a second connection into a resilience architecture.