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 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 100Design 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
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.
- 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 and 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 alwaysAnnouncing 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)
- 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.
