For colocation facilities, datacenters, and enterprises with their own public IP space, BGP multi-homing is the standard approach to achieving ISP-level redundancy and controlling routing. Rather than depending on a single provider's reliability and path selection, multi-homed networks establish eBGP sessions with two or more upstream providers and can route around outages or congested paths automatically.

Prerequisites: Your Own AS and IP Space

Full BGP multi-homing requires:

  • Your own Autonomous System Number (ASN) — assigned by APNIC, ARIN, RIPE, etc. Public ASNs require justification; private ASNs (64512–65534) are available without registration but not usable on the public internet.
  • Your own Provider Independent (PI) IPv4/IPv6 address space — APNIC minimum allocation for PI IPv4 is /24 (256 addresses). PI space is portable — you can announce it to multiple providers independently of which provider hosts your connection.

If you don't have your own ASN and PI space, pseudo-multihoming (using provider-assigned addresses with static routing to two ISPs) is possible but lacks the traffic engineering capabilities of full BGP.

eBGP Session Design

In a dual-ISP setup, you establish eBGP sessions with two upstream routers (one per ISP). Your edge router (Cisco IOS-XE, Juniper JunOS, or a software router like VyOS/FRRouting) announces your PI prefix(es) to both ISPs.

[Your Edge Router ASN 65000]
    ├── eBGP to ISP-A (AS 9498 - Bharti)   — Transit circuit A
    └── eBGP to ISP-B (AS 18101 - Reliance) — Transit circuit B

Both ISPs announce your prefix to the internet, making your addresses reachable via either path. The internet at large selects which path to use based on BGP best-path selection (AS path length, MED, local preference of the upstream).

Outbound Traffic Engineering: Local Preference

For outbound traffic (your network to the internet), you control path selection via Local Preference (LOCAL_PREF). Local Preference is an iBGP attribute — it's shared between your own routers but never sent to external peers. Higher value wins.

Example policy — prefer ISP-A for all outbound, use ISP-B only as fallback:

route-map ISP-A-IN permit 10
 set local-preference 200

route-map ISP-B-IN permit 10
 set local-preference 100

If ISP-A's session goes down, ISP-B's routes at LP 100 become the best path automatically.

Inbound Traffic Engineering: AS Path Prepending and MED

Controlling which ISP carries inbound traffic is harder — you're influencing external AS routing decisions. Two mechanisms:

AS Path Prepending

Prepending your own ASN multiple times to routes sent to a specific ISP makes those routes appear less attractive (longer AS path = less preferred). To make inbound traffic prefer ISP-A:

route-map ANNOUNCE-TO-ISP-B permit 10
 match ip address prefix-list MY-PREFIXES
 set as-path prepend 65000 65000 65000

Routes announced to ISP-B now have an AS path of 65000 65000 65000 65000 (original + 3 prepends), making them less preferred than the path via ISP-A which has a shorter AS path.

MED (Multi-Exit Discriminator)

MED is a BGP attribute you can set on outbound announcements to suggest to a directly connected AS which of their multiple connections to your network to prefer. MED is only respected by the directly connected AS (it's not transitive) and only when that AS has multiple connections to your network — less useful for most dual-ISP setups.

Prefix Filtering: Protecting the Global Routing Table

Never accept full internet routing tables from both ISPs and redistribute them — 950,000+ IPv4 prefixes would overwhelm all but high-memory core routers. Common approaches:

  • Default route only — accept only a default route (0.0.0.0/0) from each ISP. Simple, lowest memory requirement. No traffic engineering based on prefix knowledge.
  • Partial routes — accept customer routes from each ISP (routes they originate or have learned from their own customers) plus a default. Allows traffic engineering for direct customers of your ISPs.
  • Full routes — accept complete internet routing tables from both ISPs. Requires routers with 4–8 GB RAM minimum (Cisco ASR 1001-X, Juniper MX series, etc.). Enables optimal path selection for all destinations.

RPKI and Route Origin Validation

RPKI (Resource Public Key Infrastructure) cryptographically ties IP prefixes to the authorised ASN that can originate them. Without RPKI, BGP route hijacks (malicious or accidental) can redirect your traffic. To protect your prefix:

  1. Create a Route Origin Authorisation (ROA) for your prefix via your RIR's (APNIC) member portal, authorising your ASN to originate it
  2. Configure your edge routers to validate ROAs from an RPKI validator (Routinator, FORT, OctoRPKI) and drop INVALID routes
  3. Enable BGP Prefix limits per session to prevent a misbehaving peer from flooding your routing table
"BGP multi-homing is the only way to achieve true ISP-level redundancy. Static routing with two ISPs gives you failover — BGP gives you traffic engineering, faster convergence, and the ability to survive a complete provider outage without manual intervention."

Sripadatech designs and manages BGP multi-homed network architectures for colocation and enterprise environments. Contact us to discuss your WAN design.