Featured image

Table of Contents Link to heading

BGP Fundamentals Link to heading

Info
BGP (Border Gateway Protocol) is the routing protocol of the internet — the only EGP (Exterior Gateway Protocol) in production use. It is a path-vector protocol that makes routing decisions based on policies and attributes rather than simple metrics.

BGP is designed for routing between autonomous systems (ASes). Unlike IGPs (OSPF, EIGRP) which optimise for shortest path within a single administrative domain, BGP is optimised for policy-based routing across administrative boundaries — where who owns the path matters as much as how long it is.

Key BGP characteristics:

  • Transport: TCP port 179 — BGP relies on TCP for reliable delivery, so there is no built-in acknowledgement or retransmission mechanism in BGP itself
  • Administrative Distance: 20 for eBGP, 200 for iBGP
  • Convergence: Slow by design — BGP rate-limits updates to avoid instability propagation
  • Scalability: Carries the full internet routing table (~1M+ prefixes) — designed for massive scale

eBGP vs iBGP Link to heading

Feature eBGP (External BGP) iBGP (Internal BGP)
Between Different ASes Same AS
TTL (default) 1 (directly connected peers expected) 255 (can span multiple hops)
Next-hop behaviour Next-hop set to the advertising router’s IP Next-hop unchanged (IGP must resolve it)
AD 20 200
Loop prevention AS_PATH — drop if own AS is in the path Split horizon — iBGP routes not re-advertised to other iBGP peers
Route propagation Advertises to all eBGP and iBGP peers Does not re-advertise to other iBGP peers
Note
The iBGP split-horizon rule — that a router will not re-advertise a route learned from one iBGP peer to another iBGP peer — is why iBGP requires either a full mesh or a Route Reflector (RR) to distribute routes within an AS. Without one of these, some routers will have routing black holes for prefixes they never received.

BGP Path Selection Attributes Link to heading

BGP selects a single best path to each destination using a deterministic sequence of attribute comparisons. When multiple paths exist, BGP walks this list until a tiebreaker is found:

Step Attribute Prefer Notes
1 Weight Higher Cisco proprietary, local to the router only
2 Local Preference Higher Shared within the AS via iBGP
3 Locally Originated Prefer Routes originated via network or redistribute
4 AS_PATH length Shorter Primary inter-AS path selection mechanism
5 Origin IGP > EGP > Incomplete i beats e beats ?
6 MED Lower Hint to external AS about preferred entry point
7 eBGP over iBGP eBGP External paths preferred over internal
8 IGP metric to next-hop Lower Closest exit point (hot-potato routing)
9 Oldest eBGP path Oldest Stability preference
10 Router ID Lower Final tiebreaker
Tip
The mnemonic W-L-L-A-O-M-E-I-O-R (Weight, Local-pref, Locally-originated, AS-path, Origin, MED, External, IGP metric, Oldest, Router-id) covers the full sequence. In practice, most policy is applied by manipulating Weight (local), Local Preference (AS-wide), and AS_PATH prepending (inter-AS) — the other attributes are rarely touched in production.

Neighbour Configuration Link to heading

eBGP Neighbour Link to heading 

router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 description ISP-A

By default, eBGP requires the peer to be directly connected (TTL=1). For multi-hop eBGP (e.g., peering via loopbacks across multiple hops):

neighbor 203.0.113.1 ebgp-multihop 2
neighbor 203.0.113.1 update-source Loopback0

iBGP Neighbour Link to heading 

router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.2 description IBGP-RR

Always use loopback addresses for iBGP peering — loopbacks are stable regardless of which physical interface is up, which avoids BGP session drops on link failover.

iBGP Full Mesh and Route Reflectors Link to heading

A pure iBGP deployment requires every router to peer with every other router (full mesh) — O(n²) sessions. Route Reflectors solve this by relaxing the split-horizon rule for a designated RR:

! On the Route Reflector
router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 route-reflector-client
 neighbor 10.0.0.3 remote-as 65001
 neighbor 10.0.0.3 route-reflector-client

The RR reflects routes learned from one client to all other clients and to non-client iBGP peers, eliminating the need for full mesh among clients.

Warning
Deploy Route Reflectors in pairs for redundancy. A single RR is a control-plane single point of failure — if it goes down, clients lose iBGP-learned routes even though the data plane may still forward based on cached FIB entries until NSF/GR timers expire.

Advertising Networks into BGP Link to heading

Method 1 — network statement (preferred for precision):

router bgp 65001
 network 192.168.1.0 mask 255.255.255.0

The network must exist in the routing table (from any source) for the network statement to advertise it. Use a static null0 route as an anchor if the network is an aggregate:

ip route 192.168.0.0 255.255.0.0 Null0
router bgp 65001
 network 192.168.0.0 mask 255.255.0.0

Method 2 — redistribute (for injecting IGP routes):

router bgp 65001
 redistribute ospf 1 route-map OSPF-TO-BGP

Always use a route-map with redistribution to control which prefixes enter BGP. Redistributing without a filter can inject internal infrastructure prefixes into the global routing table.

Default Route Advertisement Link to heading

A BGP router can advertise a default route (0.0.0.0/0) to a neighbour without needing a default route in its own routing table:

router bgp 500
 neighbor 10.1.2.1 default-originate

Core internet routers that carry the full routing table and do not use a default route themselves are said to be in the Default-Free Zone (DFZ). These routers use default-originate to inject a default toward customer ASes that do not need the full table.

To advertise a default only when a specific condition is met (conditional default):

router bgp 500
 neighbor 10.1.2.1 default-originate route-map CHECK-DEFAULT

Route Filtering with Prefix Lists and Route Maps Link to heading

Prefix list — filter specific prefixes:

ip prefix-list ALLOW-ONLY-DEFAULT seq 5 permit 0.0.0.0/0
ip prefix-list ALLOW-ONLY-DEFAULT seq 10 deny 0.0.0.0/0 le 32

router bgp 65001
 neighbor 203.0.113.1 prefix-list ALLOW-ONLY-DEFAULT in

Route map — filter and manipulate attributes simultaneously:

route-map SET-LOCAL-PREF permit 10
 match ip address prefix-list PRIMARY-PATH
 set local-preference 200

route-map SET-LOCAL-PREF permit 20

router bgp 65001
 neighbor 10.0.0.2 route-map SET-LOCAL-PREF in
Tip
Apply inbound filters as close to the source as possible and outbound filters as close to the edge as possible. Inbound filters protect your routing table from unwanted prefixes; outbound filters control what you advertise to peers. Both should be explicit — never rely on a peer to filter what you advertise to them.

BGP Communities Link to heading

Communities are 32-bit tags attached to BGP routes that allow routers to apply consistent policy to groups of prefixes without maintaining per-prefix configuration.

! Tag routes with a community value
route-map TAG-WITH-COMMUNITY permit 10
 set community 65001:100

router bgp 65001
 neighbor 203.0.113.1 send-community

Well-known communities:

Community Value Effect
no-export 0xFFFFFF01 Do not advertise to eBGP peers
no-advertise 0xFFFFFF02 Do not advertise to any BGP peer
local-AS 0xFFFFFF03 Do not advertise outside the local AS
internet 0x00000000 Advertise to all peers (default)

Verification Link to heading 

show bgp summary
show bgp neighbors
show bgp ipv4 unicast
show bgp ipv4 unicast <prefix>
show ip bgp
show ip route bgp
debug ip bgp <neighbor-ip> updates

show bgp summary is the first command to run when checking BGP health — it shows neighbour state, uptime, and prefix counts in a single view. An Idle or Active state indicates the session has not been established; Established with a non-zero PfxRcd count confirms the peer is sending prefixes.