> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # BGP Design for Enterprise Networks: Dual-Homed and Multi-Homed - URL: https://www.pinglabz.com/bgp-design-enterprise/ - Published: 2026-03-28T06:51:57.000Z - Updated: 2026-07-04T22:56:38.000Z - Description: Enterprise BGP design comes down to how many ISPs, how many borders, full table or defaults, and active-active or active-standby. From single-homed to multi-homed with traffic engineering, and when you do not need BGP at all. - Author: Jaime - Tags: BGP, #Import 2026-08-01 19:54 Enterprise BGP design is about answering a few critical questions: How many ISPs? How many border routers? Full routing table or just defaults? Active-active or active-standby? The answers determine your resilience, your traffic engineering capability, and your operational complexity. This article covers the standard enterprise design patterns - from simple single-homed (spoiler: you don't even need BGP) to fully multi-homed with traffic engineering. If you want the bigger picture first, the [BGP complete guide](https://www.pinglabz.com/bgp/) covers the architecture this article plugs into. ## Do You Need BGP? BGP is only necessary when you need to: - Connect to multiple ISPs and control path selection - Maintain internet connectivity during a single ISP failure - Influence how traffic enters or leaves your network - Advertise your own PI (Provider Independent) address space If you have a single ISP with a single connection, you don't need BGP. A static default route is simpler, has zero convergence overhead, and provides the same connectivity. ## Design Pattern 1: Single-Homed (No BGP Needed) ``` [ISP-A] | [R1-HQ] | [Internal] ``` One ISP, one link. Use a static default route and PAT/NAT. If the ISP link fails, you're down regardless of what protocol you run. BGP adds complexity with zero benefit here. ## Design Pattern 2: Dual-Homed, Single ISP ``` [ISP-A-PE1]---[ISP-A-PE2] | | [R1-HQ]--------[R2-HQ] | | [ Internal Network ] ``` Two links to the same ISP. BGP provides automatic failover between links. Since it's the same AS, the ISP handles internal path selection. ### What to Request from ISP - **Default route only:** Simplest. ISP sends 0.0.0.0/0 from both PE routers. Use local-pref to prefer one link, failover to the other. - **Default + partial routes:** ISP sends defaults plus their customer routes. Gives you better path selection for the ISP's direct customers. ### Configuration ``` router bgp 65001 neighbor 172.16.0.2 remote-as 65010 neighbor 172.16.0.2 description ISP-A-PE1-Primary neighbor 172.16.0.2 prefix-list ACCEPT-DEFAULT in neighbor 172.16.0.2 route-map PRIMARY-IN in ! neighbor 172.16.0.4 remote-as 65010 neighbor 172.16.0.4 description ISP-A-PE2-Backup neighbor 172.16.0.4 prefix-list ACCEPT-DEFAULT in neighbor 172.16.0.4 route-map BACKUP-IN in ! route-map PRIMARY-IN permit 10 set local-preference 200 ! route-map BACKUP-IN permit 10 set local-preference 100 ``` ## Design Pattern 3: Multi-Homed, Two ISPs, Single Router ``` [ISP-A] [ISP-B] \ / [R1-HQ] | [Internal] ``` This is the PingLabz BGP Lab topology. One border router, two ISPs. Provides ISP redundancy but the router is a single point of failure. ### Routing Table Options Default routes only MemoryMinimal TE CapabilityPrimary/backup only ComplexityLow Partial routes + defaults MemoryModerate TE CapabilityGood for ISP customers ComplexityMedium Full tables Memory\~2GB+ RAM TE Capability Optimal per-prefix decisions ComplexityHigh For most enterprises, **partial routes + defaults** is the sweet spot. Full tables (950K+ IPv4 prefixes) require significant memory and offer diminishing returns unless you're doing sophisticated per-prefix traffic engineering. ### Traffic Engineering - **Outbound (where YOUR traffic goes):** Use local-pref. Simple primary/backup or per-destination load sharing. See [Manipulating BGP Local Preference](https://www.pinglabz.com/bgp-local-preference/). - **Inbound (where traffic comes TO you):** Much harder. Use AS-path prepending, MED (if same ISP), or communities (if ISP supports them). See [BGP AS-Path Prepending](https://www.pinglabz.com/bgp-as-path-prepending/) and [BGP Communities](https://www.pinglabz.com/bgp-communities/). ## Design Pattern 4: Multi-Homed, Two ISPs, Two Routers ``` [ISP-A] [ISP-B] | | [R1-HQ]-----[R2-HQ] | | [ Internal Network ] ``` The gold standard for enterprise BGP. Each ISP connects to a different border router, and iBGP between R1-HQ and R2-HQ shares routing information. ### Design Decisions - **iBGP between border routers:** Required so each router knows about paths learned by the other. Use loopback-based peering with `next-hop-self`. - **Route reflector or full mesh:** With two routers, full mesh IS the only option (one iBGP session). No RR needed. - **IGP between border routers:** OSPF or EIGRP for loopback reachability and internal routing. - **Redistribute into IGP?** Usually just a default route. Don't redistribute the full BGP table into OSPF - it's not designed for that scale. ### Configuration (R1-HQ) ``` router bgp 65001 bgp router-id 1.1.1.1 ! ! eBGP to ISP-A neighbor 172.16.0.2 remote-as 65010 neighbor 172.16.0.2 description ISP-A neighbor 172.16.0.2 prefix-list OUR-SPACE out neighbor 172.16.0.2 prefix-list ISP-A-IN in neighbor 172.16.0.2 route-map ISP-A-POLICY in neighbor 172.16.0.2 password SecurePass! neighbor 172.16.0.2 fall-over bfd ! ! iBGP to R2-HQ neighbor 2.2.2.2 remote-as 65001 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 next-hop-self neighbor 2.2.2.2 description R2-HQ-iBGP ! ! Advertise our space network 10.1.0.0 mask 255.255.0.0 ! ! Redistribute default into OSPF for internal routers router ospf 1 default-information originate always ``` ## Announcing Your Address Space If you have provider-independent (PI) address space from a RIR: - Advertise the aggregate from both border routers to both ISPs - Use consistent outbound prefix-lists on all eBGP sessions - Create ROAs for RPKI (see [BGP RPKI](https://www.pinglabz.com/bgp-rpki-route-origin-validation/)) - Register in IRR databases If you use provider-assigned (PA) space from one ISP, you can only advertise it if the ISP allows (check your agreement). Most PA space can't be announced to a second ISP - you'll need PI space for true multi-homing. ## Design Checklist - Outbound prefix-lists on ALL eBGP sessions - only advertise your space - Inbound bogon filtering on ALL eBGP sessions - Maximum-prefix limits on all peers - MD5 or TCP-AO authentication on all eBGP sessions - BFD for fast failover on critical links - RPKI ROAs created for all your prefixes - iBGP with next-hop-self between all border routers - Default route redistribution into IGP for internal routers ## Key Takeaways - Single-homed networks don't need BGP. Dual-homed to one ISP is the minimum use case. - Multi-homed with two ISPs and two routers is the gold standard for enterprise redundancy. - Partial routes + default is usually better than full tables for enterprises - sufficient traffic engineering with lower resource requirements. - Always filter outbound (your space only), filter inbound (bogons + limits), and authenticate every eBGP session. - PI address space is required for true multi-homing where you advertise to both ISPs independently.