The Border Gateway Protocol (BGP, full form: Border Gateway Protocol) is what holds the internet together. Every time you load a webpage, your packets traverse a series of autonomous systems (ASes) that learned about each other through BGP updates. It is also, increasingly, what holds large enterprise and data center networks together: BGP is no longer just a service-provider protocol.
This guide is the cluster overview for the full PingLabz BGP series: 30 articles covering fundamentals, configuration, traffic engineering, troubleshooting, security, and design, all built on a consistent Cisco IOS XE 17.x lab. If you are studying for CCNP ENCOR/ENARSI or CCIE Enterprise Infrastructure, or you just inherited a BGP-running network and need to come up to speed quickly, start here. We will work through what BGP is, how it operates, and how its attributes drive path selection, with links into the deeper articles where you need them.
What BGP Solves
Interior gateway protocols (OSPF, EIGRP, IS-IS) are excellent at finding the shortest path inside a single administrative domain. They converge fast, they react to topology changes in sub-second timeframes, and they assume the routers running them are all owned and trusted by the same operator.
That trust assumption breaks the moment you cross an organizational boundary. When AT&T's network needs to talk to Verizon's network, neither side is willing to flood link-state databases or run a shared SPF computation across the other operator's infrastructure. They need a protocol that can:
- Exchange reachability information (which prefixes are reachable through whom) without exposing internal topology
- Express rich policy about which routes to accept, prefer, or advertise, since peering relationships are commercial
- Scale to a routing table that today exceeds 1,000,000 IPv4 prefixes in the default-free zone (DFZ)
- Be slow on purpose: convergence trades raw speed for stability, because instability at internet scale is catastrophic
BGP is that protocol. It is a path-vector protocol (it carries the AS-level path each route has traversed), it runs over TCP port 179 for reliable delivery, and it is fundamentally policy-driven rather than metric-driven. There is no "shortest" route in BGP, only the route that wins the best-path algorithm based on the attributes operators have chosen to set.
How BGP Works (the 10,000-Foot View)
Two BGP routers form a peering relationship, called a neighbor or session. The session runs over TCP/179, which means the two routers must already have IP reachability to each other (BGP itself does not discover neighbors the way OSPF does on a multi-access link). You configure each peer explicitly.
Once the TCP session is up, the two peers walk through the BGP finite state machine. The neighbor states, in order, are:
- Idle - waiting to start
- Connect - trying to complete the TCP three-way handshake
- Active - TCP failed once and is being retried (counterintuitively, "Active" is a problem state, not a healthy one)
- OpenSent - we sent our OPEN message, waiting for theirs
- OpenConfirm - their OPEN looked good, waiting for KEEPALIVE
- Established - the session is up and updates can be exchanged
If you ever see a peer stuck in Active, that is your TCP layer telling you something: bad neighbor IP, ACL blocking 179, mismatched source interfaces, or no route to the peer. The full state-by-state diagnostic is in BGP Neighbor States: The 6-State FSM and How to Diagnose It. The full mechanics are covered in How BGP Works: Peers, Updates, and the Finite State Machine, with the four message types broken out in BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION.
Once Established, peers exchange UPDATE messages containing prefixes (NLRI) and the path attributes that describe each prefix. Those updates feed into per-peer Adj-RIB-In tables, get evaluated against inbound policy, run through the best-path algorithm, and the winners are pushed into the main BGP table and (if they are best in the IP routing table too) the FIB. How BGP Advertises Routes: NLRI, Withdrawn Routes, and the Adj-RIB walks through that pipeline.
BGP vs IGPs: When You Reach for Each
One of the most common interview questions for working network engineers is: when do you use BGP versus an IGP like OSPF? The honest answer is that they solve different problems and you almost always end up running both. The dedicated comparison is in BGP vs OSPF: When to Use Each Routing Protocol; the short version below.
| Trait | BGP | OSPF / EIGRP / IS-IS |
|---|---|---|
| Routing scope | Inter-AS (and increasingly intra-DC and SD-WAN overlays) | Intra-AS (single administrative domain) |
| Algorithm | Path-vector (AS_PATH carried with each route) | Link-state / DUAL |
| Convergence | Slow on purpose (seconds to minutes) | Fast (sub-second with tuning) |
| Policy expressiveness | Extreme (route maps, communities, MED, LP, weight) | Limited |
| Default Cisco AD | 20 (eBGP) / 200 (iBGP) | 110 (OSPF) / 90 (EIGRP) / 115 (IS-IS) |
| Typical prefix count | Hundreds of thousands to ~1M (DFZ) | 1,000 to 10,000 |
| Transport | TCP/179 (reliable, point-to-point) | IP protocol numbers, often multicast |
| Authentication | MD5, TCP-AO, GTSM | MD5, SHA |
In practice, you run an IGP underneath BGP to provide reachability between iBGP peers (so the TCP/179 sessions stay up and BGP NEXT_HOPs resolve), and you run BGP at the edge to talk to other ASes. In a data center, BGP is now often used as the underlay too (BGP unnumbered, EVPN), but the IGP-versus-BGP split still applies conceptually.
eBGP vs iBGP
The same protocol behaves differently depending on whether the two peers are in the same AS or different ASes. eBGP vs iBGP: What's the Difference and When to Use Each covers the full picture, but here is the short version:
| Behavior | eBGP (different ASes) | iBGP (same AS) |
|---|---|---|
| Default AD | 20 | 200 |
| TTL | 1 by default (peers must be directly connected, override with ebgp-multihop) | 255 |
| AS_PATH update | Local AS prepended on advertise | Not modified between iBGP peers |
| NEXT_HOP update | Rewritten to advertising router by default | Preserved (this is why next-hop-self exists) |
| Topology requirement | None beyond reachability | Full mesh, or use route reflectors / confederations |
Two iBGP-specific gotchas trip up almost everyone the first time:
- The NEXT_HOP problem. When an eBGP peer advertises a route into your AS, the NEXT_HOP attribute is the eBGP peer's IP. Your iBGP peers then receive that route, but the NEXT_HOP is unchanged, and they may have no route to it. The fix is BGP Next-Hop-Self on your edge router so internal peers see the advertising router as the NEXT_HOP.
- The full-mesh problem. iBGP routes received from one iBGP peer are not re-advertised to other iBGP peers (loop prevention). With n iBGP routers, that means you need n(n-1)/2 sessions for everyone to learn everything. At 50 routers, that is 1,225 sessions. You do not want to manage that. The two ways out are BGP Route Reflectors (most common) and BGP Confederations.
Path Attributes: The Heart of BGP
BGP does not pick the shortest path. It picks the best path according to a 13-step algorithm that walks down a list of attributes in priority order. Understanding those attributes is the whole game; once you know them, BGP troubleshooting and traffic engineering become tractable.
| Attribute | Type | Affects direction | Tiebreaker rule | Set by |
|---|---|---|---|---|
| WEIGHT | Cisco-proprietary, local only | Outbound | Highest wins | Local router (not advertised to peers) |
| LOCAL_PREF | Well-known discretionary | Outbound | Highest wins | iBGP peers within an AS |
| AS_PATH length | Well-known mandatory | Outbound | Shortest wins | Each AS prepends on advertise |
| ORIGIN | Well-known mandatory | Outbound | IGP < EGP < Incomplete | How the route entered BGP |
| MED | Optional non-transitive | Inbound (a hint to neighbors) | Lowest wins | Neighbor AS exit-point preference |
| NEXT_HOP | Well-known mandatory | Forwarding | Must be reachable; eBGP-learned preferred | Advertising router |
| COMMUNITY | Optional transitive | Policy tag | Mark-and-match | Any router in the path |
| ORIGINATOR_ID, CLUSTER_LIST | Optional non-transitive | Loop prevention | n/a | Route reflectors |
The deep dive lives in BGP Path Attributes Explained: Well-Known vs Optional. The key thing to internalize: WEIGHT and LOCAL_PREF influence what your AS chooses to do with traffic going out (outbound path selection from your perspective). MED and AS-Path Prepending are how you try to influence what other ASes do with traffic coming in. The latter is much harder, because remote operators are free to ignore your hints.
Best Path Selection: The 13-Step Tiebreaker
When BGP sees two or more paths to the same prefix, it walks this list in order and stops at the first step that picks a winner. Memorize the top 5 (the rest are edge cases):
- Prefer the path with the highest WEIGHT (Cisco only, local)
- Prefer the path with the highest LOCAL_PREF
- Prefer the path that was locally originated (network, redistribute, aggregate)
- Prefer the path with the shortest AS_PATH
- Prefer the path with the lowest ORIGIN code (IGP < EGP < Incomplete)
- Prefer the path with the lowest MED (only between paths from the same neighboring AS, by default)
- Prefer eBGP over iBGP
- Prefer the path with the lowest IGP cost to the NEXT_HOP
- Determine if multiple paths require multipath installation (ECMP)
- For eBGP, prefer the oldest path (stability heuristic)
- Prefer the path with the lowest router ID
- Prefer the path with the shortest CLUSTER_LIST
- Prefer the path from the lowest neighbor IP
If two paths still tie at step 13, BGP can install both with maximum-paths for ECMP load-sharing. Full algorithm walkthrough with worked examples lives in BGP Best Path Selection Algorithm.
Get the BGP Best-Path Selection cheat-sheet
All 13 tiebreakers on a single printable page, with the gotcha for each rule. Free for members.
Configuration on Cisco IOS XE: Minimum Viable BGP
Here is the smallest possible eBGP setup. R1 in AS 65001 peering with R2 in AS 65002:
R1(config)# router bgp 65001
R1(config-router)# bgp router-id 1.1.1.1
R1(config-router)# neighbor 10.0.12.2 remote-as 65002
R1(config-router)# address-family ipv4
R1(config-router-af)# neighbor 10.0.12.2 activate
R1(config-router-af)# network 192.168.1.0 mask 255.255.255.0
R1(config-router-af)# exit-address-familyThe network statement does not enable BGP on an interface (that is an OSPF habit you want to unlearn). It tells BGP "if a route exactly matching 192.168.1.0/24 is in the routing table, originate it into BGP." Once both sides are configured, you should see:
R1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 496 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.12.2 4 65002 14 14 3 0 0 00:09:42 1The State/PfxRcd column is the diagnostic gold mine. A number means Established and that is how many prefixes the peer is advertising you. A word (Idle, Active, OpenSent) means the session is not up and you have a problem. A working session sending zero prefixes is also a problem (filter mismatch, no activate, etc.).
The full configuration walkthrough, including iBGP, peer groups, and templates, is in How to Configure eBGP Neighbors on Cisco IOS XE and How to Configure iBGP Neighbors and Full Mesh.
Route Filtering and Policy
You should never run BGP without filters on a public-facing session. The default Cisco behavior is "advertise everything you have" and "accept everything you are sent" - which is how route leaks happen. Three tools cover 95% of filtering needs:
| Tool | Best for | Match granularity |
|---|---|---|
| Prefix list | Filtering by network/prefix-length | Exact prefix or range (ge/le) |
| AS-path access list | Filtering by AS_PATH regex (e.g. "any path through AS 65010") | Regex on AS_PATH string |
| Route map | Combining matches and setting attributes (LP, MED, communities) | Anything, plus the ability to mutate |
Route maps are the universal lever. BGP Route Maps: Matching, Setting, and Manipulating Paths covers the syntax and the six most common production patterns. Prefix-list-only filtering is faster to read and lives in BGP Route Filtering with Prefix Lists. And once you have multiple peering points, communities become the cleanest way to tag routes once and have policy elsewhere react to the tag - see BGP Communities: Standard, Extended, and Large.
Traffic Engineering with BGP
BGP traffic engineering breaks into two halves: influencing the traffic leaving your AS (outbound, easy), and influencing the traffic entering your AS (inbound, hard).
Outbound: you control your own routers, so you can use any attribute you like. WEIGHT (highest wins, Cisco-only, local-only) is the bluntest tool. Cisco BGP Weight Attribute covers when this is appropriate. Manipulating BGP Local Preference for Inbound Path Selection is the iBGP-friendly equivalent.
Inbound: you have to convince other ASes to do what you want. The two main levers are MED (a hint to your direct neighbor about which of your links to prefer) and AS-Path Prepending (artificially making one path look longer so neighbors avoid it). MED only works between paths from the same neighboring AS by default, so it is useful for primary/backup at one peer but not for multi-vendor steering. AS-Path Prepending is broader but unreliable - BGP AS-Path Prepending: When It Works and When It Doesn't explains why three prepends often have no effect (other operators may have a higher-priority LOCAL_PREF policy that ignores AS-Path entirely).
Two more useful TE tools sit in the same cluster: BGP Route Aggregation and Summarization for keeping your advertised footprint small, and Originating a Default Route in BGP for downstream simplification.
Scaling iBGP: Route Reflectors and Confederations
The iBGP full-mesh problem (mentioned earlier) is the thing that pushes designs toward route reflectors. With route reflectors, a small number of central routers (RRs) re-advertise iBGP routes to their clients, breaking the no-iBGP-readvertisement rule in a controlled way. You go from O(n²) sessions to O(n).
Confederations achieve a similar scaling result by splitting a single AS into sub-ASes (members) that run eBGP between each other internally and present a single AS number externally. Confederations are common in older service provider designs and rare in modern enterprise. BGP Route Reflectors: Eliminating the Full Mesh and BGP Confederations: An Alternative to Route Reflectors have the configurations and trade-offs.
BGP Security and the State of the Internet
BGP was designed in 1989. Its security model was "we know everyone running BGP." That is no longer true, and the internet has paid for it many times. The 2008 Pakistan-YouTube hijack, the 2019 Cloudflare-Verizon route leak, and the 2022 KlaySwap incident are all in the textbooks because BGP did exactly what it was told. The protocol itself is not broken, but it trusts whoever you peer with.
The modern hardening stack you should care about:
- Strict ingress filters on every eBGP peer (prefix lists + AS-path filters). This is the single most effective control. Most route leaks are filter mistakes, not protocol attacks.
- RPKI Route Origin Validation. RPKI lets prefix holders publish signed Route Origin Authorizations (ROAs), and your routers validate received routes against them. BGP RPKI and Route Origin Validation on IOS XE walks through the IOS XE configuration.
- Session authentication with MD5 or, on newer platforms, TCP-AO. Plus GTSM (TTL security) on eBGP sessions to defeat off-link attackers. BGP Session Authentication: MD5 and TCP-AO.
- maxprefix limits on every peer to cap blast radius if a peer leaks the DFZ at you.
The full picture, including the difference between hijacks and leaks and how to detect them, is in BGP Route Leaks and Hijacks: Detection and Prevention.
Troubleshooting: The Three Failures You Will See
Most BGP problems fall into one of three buckets: the session is not coming up, the session is up but routes are not flowing, or the session is up and routes are flowing but BGP is choosing the wrong path. The PingLabz troubleshooting cluster has one article per bucket:
- Troubleshooting BGP Neighbor Adjacency Issues - sessions stuck in Active or Idle
- Troubleshooting BGP Route Advertisement Problems - routes missing from the table
- Why Is BGP Choosing the Wrong Path? - 13-step algorithm in real outputs
- BGP Convergence: Timers, BFD, and Reducing Failover Time - when sessions are healthy but failover is too slow
Design and the Full BGP Cluster
Once you have the fundamentals, the next question is how to lay BGP out across a real network. Two design articles cover the dominant patterns:
- BGP Design for Enterprise Networks: Dual-Homed and Multi-Homed
- BGP Design for Service Providers: Full Tables, Peering, and Transit
The full 30-article cluster, in reading order:
Fundamentals
1. What Is BGP? The Protocol That Runs the Internet
2. How BGP Works: Peers, Updates, and the Finite State Machine
3. eBGP vs iBGP: What's the Difference and When to Use Each
4. BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION
5. BGP Path Attributes Explained: Well-Known vs Optional
6. BGP Best Path Selection Algorithm: All 13 Steps
7. How BGP Advertises Routes: NLRI, Withdrawn Routes, and the Adj-RIB
Configuration
8. How to Configure eBGP Neighbors on Cisco IOS XE
9. How to Configure iBGP Neighbors and Full Mesh
10. BGP Next-Hop-Self: When and Why You Need It
11. BGP Route Reflectors: Eliminating the Full Mesh
12. BGP Confederations: An Alternative to Route Reflectors
13. BGP Route Filtering with Prefix Lists
14. BGP Route Maps: Matching, Setting, and Manipulating Paths
15. BGP Communities: Standard, Extended, and Large
Traffic Engineering
16. Manipulating BGP Local Preference for Inbound Path Selection
17. BGP MED (Multi-Exit Discriminator): Influencing Inbound Traffic
18. BGP AS-Path Prepending: When It Works and When It Doesn't
19. Cisco BGP Weight Attribute: Local Path Preference
20. BGP Route Aggregation and Summarization
21. Originating a Default Route in BGP
22. BGP Session Authentication: MD5 and TCP-AO
Troubleshooting
23. Troubleshooting BGP Neighbor Adjacency Issues
24. Troubleshooting BGP Route Advertisement Problems
25. Why Is BGP Choosing the Wrong Path? Troubleshooting Best Path
26. BGP Convergence: Timers, BFD, and Reducing Failover Time
Security
27. BGP Route Leaks and Hijacks: Detection and Prevention
28. BGP RPKI and Route Origin Validation on IOS XE
Cross-Cluster and Deep Dives
A. BGP vs OSPF: When to Use Each Routing Protocol
B. BGP Neighbor States: The 6-State FSM and How to Diagnose It
C. MP-BGP: Multiprotocol BGP Address Families Explained
Design and Architecture
29. BGP Design for Enterprise Networks: Dual-Homed and Multi-Homed
30. BGP Design for Service Providers: Full Tables, Peering, and Transit
Solid on the CCNA foundations? - the PingLabz CCNA Labs library
BGP is CCNP+ territory. The CCNA foundations - subnetting, OSPF, EIGRP, FHRP, ACLs, AAA, NAT, QoS - are covered in the 60-lab PingLabz CCNA Labs library with real captures from Cisco IOS XE 17.16. If your CCNA fundamentals feel rusty, open the PingLabz CCNA Labs library to refresh.
Frequently Asked Questions
What does BGP stand for?
BGP stands for Border Gateway Protocol. It is defined in RFC 4271 (current version, BGP-4) and is the de facto inter-domain routing protocol of the internet.
What port does BGP use, and why TCP?
BGP uses TCP port 179. TCP gives BGP reliable, ordered delivery and built-in congestion control, which is what you want when you are exchanging hundreds of thousands of prefixes between routers that may be hundreds of milliseconds apart. UDP would force BGP to re-implement reliability itself, and getting that right is harder than just using TCP.
What is the difference between BGP and OSPF?
OSPF is an interior gateway protocol designed for fast convergence inside a single administrative domain. BGP is an exterior gateway protocol designed for policy-driven routing between administrative domains. OSPF picks paths by metric (lowest cost wins). BGP picks paths by attributes that operators set explicitly. You almost always run both: an IGP for internal reachability, BGP at the edge.
What is the administrative distance of BGP on Cisco?
20 for eBGP-learned routes, 200 for iBGP-learned routes. The high iBGP value is intentional: it ensures that if you also run an IGP, internal routes from the IGP win over iBGP for traffic that has an internal destination, which is usually what you want.
What is an AS number, and what are the private ranges?
An AS (autonomous system) number identifies a routing domain in BGP. Public AS numbers are assigned by the regional internet registries (RIRs) and are globally unique. The private ranges are 64512-65534 for 2-byte ASNs and 4200000000-4294967294 for 4-byte ASNs - useful for internal BGP designs (data center, SD-WAN overlay, multi-tenancy) where the AS numbers never escape your network.
Is BGP secure?
Not by default. BGP trusts whoever you peer with, which is why route leaks and hijacks happen. The modern hardening stack is: strict ingress filtering, RPKI Route Origin Validation, session authentication (MD5 or TCP-AO), GTSM, and maxprefix limits per neighbor. None of these are optional on a public-facing session in 2026.
Key Takeaways
If you take one thing away from this guide, make it this: BGP is a policy-driven protocol, not a metric-driven one. Once you internalize that, the 13-step best-path algorithm stops looking arbitrary and starts looking like a list of policy levers in priority order. Every other piece (configuration, troubleshooting, traffic engineering, security) flows from there.
The protocol itself is small (four message types, a handful of well-known attributes). What makes BGP hard is operating it in a network you do not control end-to-end - which is exactly why it is the protocol that runs the internet. Bookmark this page, work through the cluster articles in the order above, and run every configuration in a lab. By the time you finish, you will be ready for any BGP question a CCIE lab or a 3 AM ticket can throw at you.