What is BGP?
Border Gateway Protocol (BGP) is the routing protocol that holds the internet together. Standardized in RFC 4271, BGP is an Exterior Gateway Protocol (EGP) engineered to exchange routing and reachability information between Autonomous Systems (ASes). An Autonomous System is a collection of IP networks and routers under the control of a single organization, presenting a unified routing policy to the outside world.
Unlike Interior Gateway Protocols such as OSPF or EIGRP — which focus on finding the lowest-cost path within a single organization — BGP is built for policy-based routing across administrative boundaries. BGP is a path-vector protocol: instead of advertising a distance metric, it advertises the complete sequence of AS numbers a route must traverse to reach a destination. This design makes loop prevention straightforward — if a router sees its own AS number already present in an incoming AS_PATH, it discards the route immediately.
BGP operates over TCP port 179, inheriting TCP's reliability, sequencing, and flow control without needing to implement them independently. All BGP relationships are explicitly configured — BGP never auto-discovers neighbors the way OSPF uses multicast hellos on a segment.
eBGP vs. iBGP
BGP operates in two distinct modes depending on whether the peering session crosses an AS boundary:
- External BGP (eBGP) — sessions between routers in different autonomous systems. eBGP peers are typically directly connected. Routes learned via eBGP are advertised to both eBGP and iBGP peers by default, and the next-hop attribute is set to the advertising router's own IP address.
- Internal BGP (iBGP) — sessions between routers within the same autonomous system. iBGP peers do not need to be directly connected; they commonly peer using loopback addresses for resilience. A fundamental iBGP rule is the split-horizon rule: a route learned from one iBGP peer is never re-advertised to another iBGP peer. This prevents loops but requires either a full mesh of iBGP sessions or the use of Route Reflectors or BGP Confederations to propagate routes throughout the AS. Additionally, iBGP does not modify the next-hop attribute by default — requiring either IGP reachability to the original eBGP next-hop or the use of
next-hop-self
.
BGP Message Types
BGP uses four message types to establish neighbor relationships and exchange routing state:
- OPEN — sent immediately after the TCP session is established. Negotiates BGP version, AS number, hold timer, and BGP Identifier (Router ID). Both peers must successfully exchange OPEN messages before the session moves to the Established state.
- UPDATE — the workhorse of BGP. Carries newly advertised prefixes (called NLRI — Network Layer Reachability Information) along with their path attributes, and simultaneously withdraws previously advertised prefixes that are no longer valid.
- KEEPALIVE — sent periodically (default every 60 seconds on Cisco IOS-XE) to maintain the session and confirm peer reachability. A KEEPALIVE is also sent in response to an OPEN message as an acknowledgment.
- NOTIFICATION — sent when an error is detected (malformed message, hold timer expiry, unsupported capability). Sending a NOTIFICATION immediately terminates the BGP session.
BGP Tables
A BGP router maintains three distinct information stores:
- Neighbor Table — tracks all configured BGP peers and their current finite state machine (FSM) state: Idle, Connect, Active, OpenSent, OpenConfirm, or Established.
- BGP RIB (Routing Information Base) — stores every path received from every BGP peer for every prefix, before any selection algorithm is applied. This is sometimes called the Adj-RIB-In.
- IP Routing Table — receives only the single best BGP path for each prefix after the path selection algorithm completes. Only the best path is installed here and used for forwarding.
How BGP Path Selection Works
When multiple paths to the same destination prefix are present in the BGP RIB, the router must select exactly one best path to install in the routing table and advertise to peers. Cisco's BGP implementation evaluates eleven attributes in strict sequential order — the algorithm stops at the first attribute where one path is clearly preferred over the others.
A useful mnemonic for the order is W-L-L-A-O-M-E-I-O-R-N, but most experienced engineers simply memorize the list through repeated exposure to production troubleshooting scenarios.
Step 1 — Weight (Highest Wins)
Weight is a Cisco-proprietary attribute that is entirely local to the router — it is never communicated to any BGP peer. Routes learned from a neighbor have a default weight of 0. Routes originated locally (via the
networkcommand or redistribution) have a default weight of 32768. Weight is the first and most powerful tiebreaker precisely because it is local: it lets a single router override global BGP policy without affecting any other device in the network.
! Prefer all routes from 172.16.10.1 over 172.16.20.1
router bgp 65001
neighbor 172.16.10.1 weight 200
neighbor 172.16.20.1 weight 100Step 2 — Local Preference (Highest Wins)
Local Preference is shared among all iBGP routers within the same AS. Its default value is 100. A higher Local Preference indicates a more preferred exit point from the AS. When your AS has two upstream providers and you want every router in the AS to agree on which one to use for outbound traffic, Local Preference is the correct tool. It is set inbound on the receiving edge router and propagated to all iBGP peers.
route-map ISP-A-IN permit 10
description Mark ISP-A as preferred exit
set local-preference 200
!
route-map ISP-B-IN permit 10
description Mark ISP-B as backup exit
set local-preference 100
!
router bgp 65001
neighbor 172.16.10.1 route-map ISP-A-IN in
neighbor 172.16.20.1 route-map ISP-B-IN inStep 3 — Locally Originated Routes (Prefer Local)
Routes originated by the local router — injected via
network, redistribution, or aggregation — are preferred over routes learned from any BGP peer. This step ensures a router always trusts its own origination over external advertisements for the same prefix.
Step 4 — AS Path Length (Shortest Wins)
BGP prefers the route with the fewest autonomous system hops in its AS_PATH attribute. Each time a route crosses an AS boundary, the traversed AS number is prepended to the path. AS Path prepending is a widely used traffic engineering technique: by artificially prepending your own AS number multiple times when advertising to a specific provider, you make that path appear longer and therefore less attractive to remote networks — steering inbound traffic toward your preferred ingress link.
! Make routes via ISP-B appear 3 hops longer
route-map PREPEND-TO-ISP-B permit 10
set as-path prepend 65001 65001 65001
!
router bgp 65001
address-family ipv4
neighbor 172.16.20.1 route-map PREPEND-TO-ISP-B outStep 5 — Origin Code (Lowest Wins)
The Origin attribute describes how a prefix entered BGP. In order of preference:
- IGP (i) — injected via the
network
command. Most preferred. - EGP (e) — learned from the now-obsolete Exterior Gateway Protocol. Extremely rare in modern networks.
- Incomplete (?) — injected via redistribution from another protocol. Least preferred.
In practice, Origin rarely acts as a tiebreaker in well-designed networks, but it can cause unexpected path selection when routes are redistributed rather than originated cleanly.
Step 6 — MED / Metric (Lowest Wins)
The Multi-Exit Discriminator (MED) is advertised to external peers to suggest the preferred entry point into your AS when multiple physical connections exist between the same two ASes. Unlike Local Preference — which controls outbound traffic — MED influences inbound traffic direction. By default, Cisco IOS-XE only compares MED values between routes received from the same neighboring AS. Enabling
bgp always-compare-medforces cross-AS MED comparison, but this is considered unsafe in most environments as it can produce non-deterministic routing.
! Advertise lower MED on preferred ingress link
route-map SET-MED-LOW permit 10
set metric 50
!
route-map SET-MED-HIGH permit 10
set metric 200
!
router bgp 65001
neighbor 172.16.10.1 route-map SET-MED-LOW out
neighbor 172.16.20.1 route-map SET-MED-HIGH outStep 7 — eBGP over iBGP
If all previous attributes are equal, BGP prefers a route learned from an external BGP peer over a route learned from an internal BGP peer. This reflects the principle that an external AS's direct advertisement of a prefix is more authoritative than a route that has been reflected through internal BGP infrastructure.
Step 8 — Lowest IGP Metric to Next-Hop
When two eBGP paths (or two iBGP paths) remain tied after all previous steps, BGP selects the path whose BGP next-hop is reachable via the lowest IGP cost. This step ties BGP path selection directly to your underlying IGP — OSPF, EIGRP, or IS-IS metric tuning becomes another lever for BGP traffic engineering in multi-homed data center or campus designs.
Step 9 — Oldest eBGP Route
To maximize routing stability, if two external BGP paths remain equivalent, BGP prefers the path that has been present in the BGP table the longest. This prevents unnecessary traffic shifts every time a new equivalent eBGP path is learned, prioritizing stability over churn.
Step 10 — Lowest BGP Router ID
The BGP Router ID is a 32-bit value displayed in dotted-decimal notation used to uniquely identify a BGP speaker. On Cisco IOS-XE it defaults to the highest loopback IP or the highest physical interface IP if no loopback exists, but should always be set explicitly. When paths are still tied at this step, the route from the peer with the numerically lowest Router ID is selected.
router bgp 65001
bgp router-id 10.255.0.1Step 11 — Lowest Neighbor IP Address
The final tiebreaker. If two paths still cannot be distinguished — possible in certain confederation or multi-session scenarios where peers share the same Router ID — BGP selects the path from the neighbor with the lowest IP address. Reaching this step is rare and typically indicates a design issue worth investigating.
Why BGP Matters Beyond the Internet
BGP is not exclusively an internet protocol. It has become the routing protocol of choice for large-scale enterprise and data center environments. Cisco's EVPN/VXLAN fabric designs use BGP as the control plane to distribute MAC and IP reachability information across leaf and spine switches. SD-WAN overlays use BGP to exchange reachability between branch sites and regional hubs. Cloud interconnect solutions — AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect — all require BGP sessions to exchange routes between enterprise networks and cloud providers.
For organizations with multiple ISP connections, BGP provides the policy controls to:
- Prefer one provider for all outbound traffic while maintaining a second as a hot standby, using Local Preference or Weight
- Influence which provider's network carries inbound traffic for specific prefixes, using MED or AS Path prepending
- Apply granular routing policies with prefix-lists and route-maps on a per-neighbor or per-prefix basis
- Achieve automatic failover when a BGP session drops, without manual intervention
Real-World Dual-Homed BGP Configuration
The following complete configuration demonstrates a dual-homed BGP deployment on sw-infrarunbook-01, a Cisco IOS-XE edge router connected to two upstream providers. ISP-A (AS 64500) is the preferred path. ISP-B (AS 64501) is the warm standby.
! sw-infrarunbook-01 — Dual-homed BGP edge configuration
! Local AS: 65001 | BGP Router-ID / Loopback0: 10.255.0.1/32
! Advertised prefix: 192.168.100.0/24
ip prefix-list DEFAULT-ROUTE-ONLY seq 5 permit 0.0.0.0/0
route-map ISP-A-IN permit 10
description ISP-A is preferred exit — set high local-pref
set local-preference 200
!
route-map ISP-B-IN permit 10
description ISP-B is backup exit — set low local-pref
set local-preference 100
!
route-map PREPEND-TO-ISP-B permit 10
description Make our prefix less attractive via ISP-B
set as-path prepend 65001 65001 65001
!
route-map PREPEND-TO-ISP-B permit 20
description Allow all other prefixes unchanged
!
router bgp 65001
bgp router-id 10.255.0.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
neighbor 172.16.10.1 remote-as 64500
neighbor 172.16.10.1 description ISP-A-PEER
neighbor 172.16.10.1 update-source Loopback0
!
neighbor 172.16.20.1 remote-as 64501
neighbor 172.16.20.1 description ISP-B-PEER
neighbor 172.16.20.1 update-source Loopback0
!
address-family ipv4
network 192.168.100.0 mask 255.255.255.0
!
neighbor 172.16.10.1 activate
neighbor 172.16.10.1 prefix-list DEFAULT-ROUTE-ONLY in
neighbor 172.16.10.1 route-map ISP-A-IN in
neighbor 172.16.10.1 send-community
!
neighbor 172.16.20.1 activate
neighbor 172.16.20.1 prefix-list DEFAULT-ROUTE-ONLY in
neighbor 172.16.20.1 route-map ISP-B-IN in
neighbor 172.16.20.1 route-map PREPEND-TO-ISP-B out
neighbor 172.16.20.1 send-community
exit-address-familyVerifying BGP Session State and Path Selection
sw-infrarunbook-01# show bgp summary
BGP router identifier 10.255.0.1, local AS number 65001
BGP table version is 14, main routing table version 14
2 network entries using 288 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.10.1 4 64500 512 510 14 0 0 05:12:44 1
172.16.20.1 4 64501 509 508 14 0 0 05:11:19 1
sw-infrarunbook-01# show bgp ipv4 unicast 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1
64500
172.16.10.1 from 172.16.10.1 (172.16.10.1)
Origin IGP, metric 0, localpref 200, valid, external, best
Last update: 05:12:44 ago
64501
172.16.20.1 from 172.16.20.1 (172.16.20.1)
Origin IGP, metric 0, localpref 100, valid, external
Last update: 05:11:19 agoThe output confirms the default route via ISP-A (172.16.10.1) is marked best due to its Local Preference of 200 versus ISP-B's 100. The ISP-B path remains in the BGP table as a standby and is automatically promoted if the ISP-A session drops — BGP will withdraw the best path and re-evaluate, installing the ISP-B route in milliseconds (faster if BFD is configured alongside BGP).
Common BGP Misconceptions
Misconception 1: BGP is only relevant for ISPs.
Reality: BGP is the control-plane protocol of choice for modern data center fabrics (EVPN/VXLAN), SD-WAN overlays, cloud interconnects, and multi-homed enterprises. Network engineers encounter BGP far outside ISP environments today.
Misconception 2: A shorter AS Path always means a better physical path.
Reality: AS Path length counts administrative hops, not physical links or latency. A two-hop AS path could traverse slow or congested inter-AS links while a four-hop path uses high-capacity, low-latency infrastructure. BGP has no inherent awareness of link quality below the AS level.
Misconception 3: MED controls your outbound traffic.
Reality: MED is advertised to neighboring ASes to influence their routing decisions about how to send traffic into your AS. It controls inbound traffic. Local Preference is what controls outbound traffic selection within your own AS.
Misconception 4: BGP automatically fails over as quickly as OSPF.
Reality: BGP is deliberately conservative about convergence. Default hold timers are 180 seconds with keepalives at 60 seconds. BGP prioritizes stability over speed. Fast failure detection requires explicit configuration of BFD (Bidirectional Forwarding Detection) alongside BGP sessions.
Misconception 5: iBGP and eBGP handle next-hop the same way.
Reality: eBGP changes the next-hop to the advertising router's own address. iBGP does not modify the next-hop by default — it preserves the original eBGP peer's address. iBGP peers must reach that external next-hop via the IGP, or the edge router must configure
next-hop-selfto replace it with its own reachable address.