BGP Multihoming: Planning Redundancy with Two Upstreams

BGP multihoming connects an autonomous network to at least two independent upstreams. When designed correctly, services remain reachable during a link, router or carrier failure, while inbound and outbound traffic can be controlled deliberately.

Define the objective first

Before configuring sessions, define the failures the architecture must survive. Two BGP sessions on the same router and cross-connect remove only a few risks. Real redundancy needs separate routers, ports, power paths and, where possible, physically diverse routes.

Technical prerequisites

• Your own public ASN and independently usable IP prefixes.
• Correct IRR and RPKI records for every announced prefix.
• Globally accepted prefix lengths, commonly up to /24 for IPv4 and /48 for IPv6.
• Routers with sufficient FIB, RIB and BGP capacity for the required routing table.
• Documented filters for your prefixes, bogons, default routes and maximum prefix counts.

Active/active or primary/backup

In an active/active design, both upstreams carry production traffic. This uses capacity efficiently but requires careful policy. Primary/backup is simpler: one path is preferred and the second takes over on failure. The choice depends on traffic volumes, cost, routing expertise and carrier capabilities.

Controlling outbound traffic

Local preference is the primary tool inside your own AS. A higher value selects the desired exit. AS-path length and MED are among the attributes considered later in the BGP decision process. Set local preference centrally and predictably so that a single customer or peer route cannot accidentally alter the entire policy.

Influencing inbound traffic

Remote networks choose the inbound path. You mainly influence their choice with more-specific prefixes, AS-path prepending and upstream communities. Communities are often more precise than blanket prepending because announcements can be changed by region, peer or transit. Both carriers need to document the supported values.

DDoS protection belongs in the policy

A second upstream does not help when an attack fills both links or mitigation applies to only one path. Confirm which prefixes are protected, how diversion is triggered, whether FlowSpec or blackholing is supported and how protection communities interact with normal traffic engineering.

Test failover for real

1. 1Shut down one BGP session in a controlled manner and measure convergence.
2. 2Disconnect the physical port to verify Layer 1 and LACP behaviour.
3. 3Isolate the preferred router and observe internal routing dependencies.
4. 4Check reachability from multiple external networks and regions.
5. 5Include return paths, stateful firewalls and asymmetric routing in the test.
6. 6Document the procedure, measurements and rollback, then repeat it regularly.

Conclusion

Multihoming is a routing architecture, not simply a number of circuits. Separate failure domains, clear policies, compatible mitigation and repeatable tests turn two upstreams into a resilient high-availability solution.