BGP is the protocol that intimidated me the most when I was starting out, and honestly, it should — it’s the protocol holding the entire internet together. But once I actually sat down and worked through it hop by hop, I realized the core mechanics are simpler than the reputation suggests. The complexity comes from what you do with it, not from the base configuration. Let me walk you through both.
What BGP Actually Is
Border Gateway Protocol is the path-vector routing protocol used to exchange routing information between autonomous systems (ASes) — think of an AS as a network under one administrative control, like an ISP or a large enterprise. Unlike interior gateway protocols such as OSPF or EIGRP, which are built for fast convergence inside one organization, BGP is built for scale and policy control across organizational boundaries. It’s not trying to find the fastest path; it’s trying to find the path you’ve told it to prefer, based on policy.
Fundamentals Before You Touch a Config
- Autonomous System Number (ASN): a unique number identifying a routing domain. Public ASNs are assigned by regional internet registries; private ASNs (64512–65534 in the 16-bit range) are used for internal or lab purposes.
- eBGP vs iBGP: eBGP runs between routers in different ASes (typically directly connected); iBGP runs between routers in the same AS (typically not directly connected, and requiring a full mesh or route reflectors).
- Path vector, not distance vector: BGP routes carry the entire AS-path they’ve traversed, which is how loop prevention works — a router simply rejects a route if its own AS number already appears in the path.
- Best path selection: BGP doesn’t just pick the shortest path; it runs through a well-defined, ordered list of attributes (weight, local preference, AS-path length, origin, MED, and more) to choose exactly one best path per prefix.
How BGP Operates
- Two BGP routers form a peering (neighbor) relationship over TCP port 179.
- They exchange full routing tables initially, then only incremental updates afterward.
- Each route carries attributes like AS-path, next-hop, local preference, and MED.
- Routers run the BGP best-path algorithm to select a single best path per prefix, then advertise that path onward according to configured policy.
- Routes learned via eBGP are, by default, advertised to iBGP peers and other eBGP peers; routes learned via iBGP are not, by default, advertised to other iBGP peers — this is why iBGP requires a full mesh or route reflectors.
Basic eBGP Configuration
Let’s configure two routers in different ASes, directly connected, exchanging routes.
R1 — AS 65001, connected to R2 via 10.0.0.1/30:
R1(config)# router bgp 65001
R1(config-router)# bgp router-id 1.1.1.1
R1(config-router)# neighbor 10.0.0.2 remote-as 65002
R1(config-router)# network 192.168.1.0 mask 255.255.255.0
R2 — AS 65002, connected to R1 via 10.0.0.2/30:
R2(config)# router bgp 65002
R2(config-router)# bgp router-id 2.2.2.2
R2(config-router)# neighbor 10.0.0.1 remote-as 65001
R2(config-router)# network 192.168.2.0 mask 255.255.255.0
The network command doesn’t create the route — it just tells BGP to advertise a route that must already exist in the local routing table (typically via a connected interface, static route, or IGP). This trips up a lot of people early on: BGP won’t originate a prefix it can’t already reach.
Verifying eBGP
R1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 65002 15 14 5 0 0 00:08:12 1
R1# show ip bgp
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0/24 0.0.0.0 0 32768 i
*> 192.168.2.0/24 10.0.0.2 0 0 65002 i
Configuring iBGP with a Route Reflector
In a larger AS, running a full iBGP mesh between every router doesn’t scale — N routers need N(N-1)/2 sessions. Route reflectors solve this by letting one router “reflect” routes to a set of clients without those clients needing to peer with each other.
! On the Route Reflector (R3, AS 65001)
R3(config)# router bgp 65001
R3(config-router)# neighbor 192.168.100.1 remote-as 65001
R3(config-router)# neighbor 192.168.100.1 route-reflector-client
R3(config-router)# neighbor 192.168.100.2 remote-as 65001
R3(config-router)# neighbor 192.168.100.2 route-reflector-client
The clients themselves just peer normally with the reflector using neighbor X remote-as 65001 — they don’t need any special configuration on their end.
Enterprise Scenario: Dual-Homed Internet Edge
A common real-world case: an enterprise multihoming to two different ISPs for redundancy. I typically configure this with private or assigned public ASNs, using local preference to prefer one ISP as primary:
R1(config)# router bgp 65010
R1(config-router)# neighbor 203.0.113.1 remote-as 64500
R1(config-router)# neighbor 198.51.100.1 remote-as 64501
R1(config-router)# neighbor 203.0.113.1 route-map PREFER-ISP1 in
R1(config-router)# route-map PREFER-ISP1 permit 10
R1(config-router)# set local-preference 200
Higher local preference (default 100) wins the best-path comparison first, before AS-path length is even considered, so this reliably makes ISP1 the preferred outbound path for anything learned from both.
Route Filtering and Policy Control
I never advertise or accept BGP routes without filtering — an open BGP session is a real operational and security risk. Prefix-lists and route-maps are the standard tools:
R1(config)# ip prefix-list ALLOWED-OUT seq 5 permit 192.168.1.0/24
R1(config)# route-map OUTBOUND permit 10
R1(config-route-map)# match ip address prefix-list ALLOWED-OUT
R1(config-router)# neighbor 10.0.0.2 route-map OUTBOUND out
Securing BGP Sessions
MD5 authentication on the TCP session:
R1(config-router)# neighbor 10.0.0.2 password MyBgpSecret
TTL security (GTSM) to reject packets that didn’t originate from a directly connected or expected-hop-count neighbor:
R1(config-router)# neighbor 10.0.0.2 ttl-security hops 1
Maximum prefix limits to prevent a misconfigured or compromised peer from flooding your routing table:
R1(config-router)# neighbor 10.0.0.2 maximum-prefix 500 80
Common Configuration Mistakes
- Advertising a
networkstatement for a prefix that doesn’t exist in the routing table — the route silently never appears in BGP. - Forgetting the iBGP full-mesh/reflector requirement, leading to routes learned via iBGP not being passed on to other iBGP peers.
- No inbound/outbound filtering, accidentally becoming a transit AS for someone else’s traffic.
- Mismatched AS numbers in the
neighbor remote-asstatement, which silently prevents peering — the session sits in Idle or Active state indefinitely. - Confusing MED with local preference — MED is exchanged between ASes and only compared for routes from the same neighboring AS; local preference is an internal-only attribute used to influence outbound path selection.
Troubleshooting BGP
show ip bgp summary
show ip bgp neighbors 10.0.0.2
show ip bgp
debug ip bgp updates
debug ip bgp events
If a session is stuck in Idle or Active (not Established), check basic IP reachability first, then AS number mismatches, then authentication, then any ACL/firewall blocking TCP 179.
Performance and Scale Tuning
- Use route reflectors or confederations for iBGP scale instead of a full mesh.
- Apply
bgp dampeningcarefully on unstable links to suppress route flapping, but be aware it can add real delay to legitimate reconvergence. - Summarize routes at AS boundaries where possible to reduce table size and churn.
- Tune BGP timers (
neighbor X timers keepalive holdtime) only when you understand the operational tradeoff — faster timers mean faster failure detection but more control-plane overhead.
FAQs
What port does BGP use? TCP port 179.
What’s the difference between eBGP and iBGP? eBGP runs between different autonomous systems; iBGP runs within the same AS and requires a full mesh or route reflectors since iBGP routes aren’t re-advertised to other iBGP peers by default.
Do I need a public ASN to use BGP? No — private ASNs work fine for internal use or multihoming where you’re not requesting a public allocation, though ISPs may assign or require a specific ASN for internet peering.
Why isn’t my BGP-learned route showing up in the routing table? Check that the BGP best-path algorithm actually selected it as best (only the best path is installed), and that the next-hop is reachable — BGP won’t install a route with an unreachable next-hop.
Summary
BGP is less about raw protocol complexity and more about policy discipline — every attribute exists to give you a lever for controlling exactly how traffic enters and leaves your network. Once I stopped thinking of it as “the internet’s protocol” and started thinking of it as “a policy engine that happens to route packets,” it became a lot more approachable. Get the peering fundamentals right, filter aggressively, and the rest builds on top of that foundation.
