Cisco BGP Multihoming: Dual-ISP Failover Configuration

Quick answer: Cisco BGP multihoming uses an eBGP session to each ISP, an outbound prefix filter that advertises only your own public prefix, and routing policy to choose a preferred path. Use local preference to control outbound traffic and AS-path prepending or provider communities to influence inbound traffic. With two customer edge routers, add iBGP between them and make the external next hops reachable.

Table of Contents

This guide shows two practical dual-ISP designs: one Cisco router connected to both providers, and two edge routers for device as well as circuit redundancy. The examples use documentation addresses and private AS numbers, so replace them with the prefixes, peer addresses, policies, and public ASN assigned to your organization.

Before You Configure BGP Multihoming

You need a public ASN and provider-independent address space if you want the same prefix to be reachable through two unrelated ISPs. Confirm routing policy and prefix-length acceptance with both providers.
The sample prefix 203.0.113.0/24 and peer addresses in 192.0.2.0/24 and 198.51.100.0/24 are reserved for documentation. Do not copy them into production.
The advertised network must exist in the local routing table with the exact mask used by the BGP network statement.
Ask each ISP whether it will send a default route, partial routes, or the full Internet table. Size the router and set prefix limits accordingly.

Important: BGP is not automatically a load balancer. It normally selects one best path for each destination prefix. The active/standby policy below is easier to predict. Equal-cost multipath is a separate design and should be tested with your platform, forwarding capacity, and ISP policies.

Scenario 1: One Cisco Router and Two ISPs

This design protects against an ISP or circuit failure, but the customer router remains a single point of failure. In the example, ISP1 is preferred for outbound and inbound traffic. ISP2 is the backup.

Cisco IOS Configuration

ip prefix-list OUR-PREFIX seq 5 permit 203.0.113.0/24

route-map ISP1-IN permit 10
 set local-preference 200

route-map ISP1-OUT permit 10
 match ip address prefix-list OUR-PREFIX

route-map ISP2-OUT permit 10
 match ip address prefix-list OUR-PREFIX
 set as-path prepend 65001 65001 65001

router bgp 65001
 bgp log-neighbor-changes
 network 203.0.113.0 mask 255.255.255.0

 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 description ISP1-PREFERRED
 neighbor 192.0.2.1 route-map ISP1-IN in
 neighbor 192.0.2.1 route-map ISP1-OUT out

 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 description ISP2-BACKUP
 neighbor 198.51.100.1 route-map ISP2-OUT out

The inbound route-map raises local preference for routes learned from ISP1. Because higher local preference wins inside the AS, outbound traffic prefers ISP1 when both providers advertise the same destination. The outbound route-maps also act as safety filters: only 203.0.113.0/24 is advertised, so routes learned from one ISP are not leaked to the other.

Prepending AS 65001 on ISP2 makes that path look longer and can make ISP1 more attractive for inbound traffic. It is an influence, not a guarantee: upstream networks can apply local preference or other policies before AS-path length. If an ISP supports BGP communities for primary/backup routing, use its documented community policy because it is usually more deterministic.

Scenario 2: Two Cisco Routers and Two ISPs

This design removes the customer-edge router as a single point of failure. R1 peers with ISP1, R2 peers with ISP2, and R1 and R2 exchange routes through iBGP. The example assumes an internal transit link of 10.0.0.0/30 between the edge routers and that both routers can reach the customer prefix through the internal network.

BGP multihoming failover with two customer edge routers and two ISPs

R1 Configuration: Preferred ISP1 Edge

ip prefix-list OUR-PREFIX seq 5 permit 203.0.113.0/24

route-map ISP1-IN permit 10
 set local-preference 200

route-map ISP1-OUT permit 10
 match ip address prefix-list OUR-PREFIX

router bgp 65001
 bgp log-neighbor-changes
 network 203.0.113.0 mask 255.255.255.0

 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 description ISP1-PREFERRED
 neighbor 192.0.2.1 route-map ISP1-IN in
 neighbor 192.0.2.1 route-map ISP1-OUT out

 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 description IBGP-TO-R2
 neighbor 10.0.0.2 next-hop-self

R2 Configuration: Backup ISP2 Edge

ip prefix-list OUR-PREFIX seq 5 permit 203.0.113.0/24

route-map ISP2-OUT permit 10
 match ip address prefix-list OUR-PREFIX
 set as-path prepend 65001 65001 65001

router bgp 65001
 bgp log-neighbor-changes
 network 203.0.113.0 mask 255.255.255.0

 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 description ISP2-BACKUP
 neighbor 198.51.100.1 route-map ISP2-OUT out

 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 description IBGP-TO-R1
 neighbor 10.0.0.1 next-hop-self

iBGP is the missing link in many dual-router examples. It lets both edge routers compare paths learned from the two providers. next-hop-self changes the next hop on routes sent to the other edge router, but the internal network must still know how to reach both customer edges. In a larger design, run an IGP such as OSPF or IS-IS between loopbacks and establish iBGP between those loopbacks.

Do not originate a public prefix from an edge router unless traffic for that prefix can reach the real destination from that router. A permanent static route to Null0 can satisfy the BGP network statement but may create a black hole during an internal failure. Production designs often tie origination to internal reachability, tracking, or conditional advertisement.

How the Dual-ISP Failover Works

When both sessions are established, R1 gives ISP1-learned routes local preference 200. The default local preference is 100, so the customer AS sends matching outbound traffic through ISP1.
The customer prefix is advertised normally through ISP1 and with three additional AS-path entries through ISP2. Many external networks therefore prefer ISP1 for inbound traffic.
If the ISP1 BGP session or route disappears, the ISP2 path becomes the remaining valid path. Convergence time depends on failure detection, BGP timers, upstream propagation, and the internal routing design.
When ISP1 returns, the higher-local-preference path becomes best again. External networks may return at different times as they receive the updated advertisements.

Verification and Failover Test Plan

First confirm that the sessions, accepted routes, best paths, and outbound advertisements match the design.

show ip bgp summary
show ip bgp 0.0.0.0
show ip route bgp
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp neighbors 198.51.100.1 advertised-routes
show ip bgp neighbors 192.0.2.1 received-routes
show route-map
show ip prefix-list

On some IOS and IOS XE releases, viewing received routes requires inbound soft reconfiguration; otherwise use accepted-prefix counters, route refresh, or the commands supported by your platform. The > marker in show ip bgp identifies the best BGP path.

Record the normal best path, next hop, local preference, AS path, and a continuous ping or application test.
During an approved maintenance window, shut the ISP1 interface or BGP neighbor. Confirm the ISP1 route is withdrawn and traffic moves to ISP2.
Test from an external looking glass or probe as well as from inside the network. An internal ping alone does not prove that inbound routing has converged.
Restore ISP1, verify stable sessions and prefix counts, and confirm that the preferred paths return without flapping.

Production Safety Checklist

Filter outbound advertisements. Permit only prefixes your AS is authorized to originate. This prevents accidental transit and route leaks.
Filter inbound routes. If you requested default-only service, accept only 0.0.0.0/0. For partial or full tables, build filters that match the ISP agreement.
Set maximum-prefix limits. Base the limit and warning threshold on the expected route count and the router’s capacity. Test the operational response before deployment.
Use route-security controls. Coordinate IRR route objects and RPKI ROAs for your prefixes, and use provider-supported authentication and filtering.
Protect both directions. BGP session failover does not help if the LAN, firewall, NAT, DNS, or return path still depends on one device.
Monitor the policy. Alert on neighbor state, prefix-count changes, route leaks, high CPU or memory use, and unexpected best-path changes.

Common BGP Multihoming Mistakes

Setting local preference in a route-map that matches communities the ISP never sends.
Leaving out iBGP between dual customer edge routers, so each router cannot compare both exit paths.
Advertising every BGP-learned route to the other ISP and accidentally becoming a transit AS.
Calling AS-path prepending “load balancing.” It only influences inbound path selection and upstream policy can override it.
Testing only a physical link failure. Also test peer failure, route withdrawal, an internal next-hop failure, and return-path behavior.

For related troubleshooting, see common BGP misconfigurations and fixes, BGP security best practices, and the explanation of eBGP versus iBGP.

Build This BGP Topology in a Home Lab

You can practice the policy with virtual Cisco routers before buying hardware. If you also want a physical network for VLANs, routing, firewalls, and certification labs, compare the best budget home lab setup under $300 and the complete home lab network gear guide. Those guides explain which hardware is useful, what each component adds, and where a cheaper option is enough.

Frequently Asked Questions

What is the simplest BGP multihoming failover configuration?

Use one eBGP neighbor per ISP, advertise only your authorized prefix through an outbound prefix filter, assign higher local preference to the primary ISP’s inbound routes, and prepend your AS on advertisements to the backup ISP. With two customer routers, also configure iBGP and internal next-hop reachability.

Does BGP automatically load balance across two ISPs?

No. BGP normally installs one best path per destination prefix. Cisco platforms can support BGP multipath when eligible paths are considered equal, but that requires an intentional design. Inbound traffic is controlled by external networks, so it may remain asymmetric.

Should I use local preference or AS-path prepending?

Use local preference inside your AS to choose the outbound exit. Use AS-path prepending or ISP-defined communities to influence how other autonomous systems reach you. Neither one replaces prefix filtering or a tested failover plan.

Do two BGP edge routers need iBGP?

Yes, if both routers must learn and compare the paths received at each edge. The iBGP next hop must be reachable through the internal network. In larger networks, loopback peering plus an IGP is usually more resilient than peering only across one physical transit link.

Official Cisco References

Bottom line: reliable BGP multihoming is a policy and failure-domain design, not just two neighbor commands. Filter what you advertise, make both exit paths visible inside the AS, verify next-hop reachability, and test each failure mode before depending on the backup link.

About
Latest Posts

Afroz Ahmad

I'm Afroz, a Network Engineer and CCIE with more than 20 years of experience in Computer Networking, Data Centers, Telecom, Internet Services and ISPs. Currently, I work as a Network Designer for a leading ISP equipment vendor. I share my expertise through my blog and courses, aiming to share my knowledge and simplify complex networking concepts for both beginners and experienced professionals.