BGP Design for Enterprise Networks: Dual-Homed and Multi-Homed

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.

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

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 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)
• 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.