BGP – Border Gateway Protocol Overview

1. What Is BGP and Why Does It Matter?

Border Gateway Protocol (BGP) is the routing protocol that makes the internet work. Defined in RFC 4271, BGP is the sole Exterior Gateway Protocol (EGP) in use today — the protocol responsible for exchanging routing information between separate organisations (autonomous systems) across the internet. Every time you visit a website, watch a video, or send an email, BGP is making the path decisions that carry your traffic across potentially hundreds of networks operated by different companies and ISPs.

Unlike interior routing protocols such as OSPF or EIGRP — which optimise paths based on metrics like bandwidth or delay — BGP is a policy-based routing protocol. Its primary concern is not speed but reachability and policy: which networks can be reached, through which organisations, and under what business rules.

Characteristic BGP IGPs (OSPF / EIGRP)
Protocol type Exterior Gateway Protocol (EGP) Interior Gateway Protocol (IGP)
Scope Between autonomous systems (inter-AS) Within a single autonomous system (intra-AS)
Transport TCP port 179 (reliable delivery built-in) Own transport (OSPF uses IP protocol 89; EIGRP uses 88)
Path selection basis Policy and path attributes (AS_PATH, LOCAL_PREF, MED, etc.) Metric (cost, bandwidth, delay)
Convergence speed Slow (minutes) — designed for stability, not speed Fast (seconds)
Scale Millions of routes (full internet routing table ~1,000,000+ prefixes) Thousands of routes (enterprise scale)
Neighbour relationship Manually configured (no auto-discovery) Auto-discovered via Hello packets (OSPF / EIGRP)

Related pages: OSPF Single-Area Config | OSPF Areas & LSAs | EIGRP Overview | EIGRP Configuration | Administrative Distance | Route Sources | Default Routes | WAN Overview | BGP eBGP Configuration Lab

2. Autonomous Systems (AS)

The foundation of BGP is the concept of the Autonomous System (AS) — a collection of IP networks and routers under the control of a single organisation that presents a common routing policy to the internet. Every organisation that participates in BGP routing on the internet must have an AS number.

2.1 AS Number Ranges

Range Type Notes
1 – 64511 Public 2-byte ASN Assigned by IANA / Regional Internet Registries (ARIN, RIPE, APNIC, etc.) for use on the public internet
64512 – 65534 Private 2-byte ASN For internal use — must be stripped before advertising routes to the public internet (similar to RFC 1918 private IP addresses)
65535 Reserved Reserved by IANA
131072 – 4199999999 Public 4-byte ASN (RFC 4893) Expanded AS number space — used as public 2-byte ASNs were exhausted
4200000000 – 4294967294 Private 4-byte ASN Private use 4-byte range — analogous to private 2-byte range

2.2 What Makes an Autonomous System

Characteristic Description
Single administration All routers within the AS are managed by the same organisation and share a common routing policy
Unique AS number Each AS is identified by a globally unique AS number (ASN) assigned by a Regional Internet Registry
IGP internally Routers within the AS use an IGP (OSPF, EIGRP, IS-IS) to exchange routes with each other
BGP externally The AS uses BGP to advertise its IP prefixes to other ASes and to receive routes from them. Large ISP backbones often combine BGP with MPLS for traffic engineering.

Examples of real-world AS numbers: Google (AS15169), Cloudflare (AS13335), Amazon AWS (AS16509), AT&T (AS7018). Large organisations often operate multiple ASes.

3. eBGP vs iBGP

BGP has two operational modes depending on whether the peering routers are in the same autonomous system or different autonomous systems.

Feature eBGP (External BGP) iBGP (Internal BGP)
AS relationship Peers are in different autonomous systems Peers are in the same autonomous system
Typical use Connecting your network to an ISP or to another organisation Distributing BGP routes among routers within your own AS
Default TTL TTL = 1 — peers must be directly connected (or use ebgp-multihop for multi-hop sessions) TTL = 255 — peers do not need to be directly connected
NEXT_HOP behaviour NEXT_HOP is set to the eBGP speaker's own interface IP NEXT_HOP is not changed by default — the iBGP peer receives the same NEXT_HOP set by the eBGP peer (must be reachable via IGP)
AS_PATH behaviour Sending router prepends its own ASN to the AS_PATH attribute AS_PATH is not modified (iBGP does not add the local ASN)
Route propagation rule Routes learned via eBGP can be advertised to both eBGP and iBGP peers Routes learned via iBGP are not re-advertised to other iBGP peers (iBGP split-horizon rule) — requires full mesh or route reflectors
Administrative distance 20 (more trusted — preferred over iBGP) 200 (less trusted — last resort after all IGPs)

3.1 iBGP Full Mesh and Route Reflectors

Because iBGP does not re-advertise routes learned from one iBGP peer to another (to prevent routing loops), all iBGP routers within an AS must have a full mesh of iBGP sessions — every iBGP router peers directly with every other. This scales poorly: n routers require n(n−1)/2 sessions.

The solution is a Route Reflector (RR) — a designated iBGP router that re-advertises (reflects) routes learned from iBGP clients to all other clients, eliminating the need for a full mesh. Route reflection is defined in RFC 4456 and is the standard iBGP scaling mechanism used in large networks and ISP backbones.

iBGP Scaling Method Description Sessions Required
Full Mesh Every iBGP router peers with every other iBGP router directly n(n−1)/2 — grows exponentially; impractical above ~10 routers
Route Reflectors Clients peer only with the RR; RR reflects routes to all clients n−1 (each client to RR) — scales linearly
BGP Confederations AS is divided into sub-ASes; sub-ASes use eBGP between them but appear as one AS to the outside Reduced full mesh within each sub-AS

4. BGP Neighbour Relationships

BGP neighbours (also called peers) are not discovered automatically. Every BGP peering session must be manually configured on both routers. BGP uses TCP port 179 as its transport, inheriting TCP's reliable, ordered delivery — eliminating the need for BGP to implement its own retransmission or sequencing.

4.1 BGP Session Establishment Steps

Step Action BGP State
1 BGP process starts; router begins trying to connect to configured neighbour IP address via TCP port 179 Idle
2 TCP connection is being attempted (SYN sent) Connect
3 If TCP fails, router waits before retrying Active
4 TCP three-way handshake completes; BGP OPEN message sent to neighbour with local AS number, BGP version, router ID, and Hold Time OpenSent
5 OPEN message received and parameters verified (AS number must match remote-as configured); KEEPALIVE sent back OpenConfirm
6 KEEPALIVE received; session fully established — routers begin exchanging UPDATE messages with route information Established

4.2 BGP Message Types

Message Type Purpose When Sent
OPEN Initiates a BGP session; carries BGP version, local AS number, Hold Time, BGP Router ID, and optional parameters (capabilities) Once per session, immediately after TCP connection established
KEEPALIVE Confirms the session is alive and the peer is reachable; no route information is carried Every Hold Time / 3 seconds (default every 60 s, Hold Time = 180 s)
UPDATE Advertises new reachable prefixes (NLRI) with their path attributes, and/or withdraws previously advertised prefixes no longer reachable When routing information changes
NOTIFICATION Reports an error condition (e.g., unsupported version, bad AS number, Hold Timer expired); always followed by session teardown When a BGP error is detected; session closed immediately after
ROUTE-REFRESH (RFC 2918) Requests a peer to re-send its full routing table without resetting the BGP session; used after policy changes On demand — requires both peers to support the capability

4.3 BGP Timers

Timer Default Purpose
Hold Time 180 seconds Maximum time between messages before declaring the peer dead. Negotiated during OPEN — the lower value of the two peers is used.
Keepalive Interval 60 seconds (Hold Time ÷ 3) How often KEEPALIVE messages are sent to maintain the session
Connect Retry Timer 120 seconds How long BGP waits before retrying a TCP connection after failure

5. BGP Path Attributes

BGP path attributes are the metadata carried in UPDATE messages alongside network prefixes (NLRI — Network Layer Reachability Information). They are the levers BGP uses for policy-based path selection. Understanding which attributes exist, what they mean, and whether they are mandatory or optional is essential for both CCNA exams and real-world BGP operation.

5.1 Attribute Categories

Category Description Examples
Well-known Mandatory Must be recognised by all BGP implementations and must be present in every UPDATE message AS_PATH, NEXT_HOP, ORIGIN
Well-known Discretionary Must be recognised by all BGP implementations but may or may not be included in an UPDATE message LOCAL_PREF, ATOMIC_AGGREGATE
Optional Transitive May not be recognised by all routers; if unrecognised, must still be passed on to other BGP peers COMMUNITY, AGGREGATOR
Optional Non-Transitive May not be recognised by all routers; if unrecognised, must be silently dropped and not forwarded MED (MULTI_EXIT_DISC), ORIGINATOR_ID

5.2 Key BGP Path Attributes Explained

Attribute Type Description & Role in Path Selection
AS_PATH Well-known Mandatory An ordered list of AS numbers the prefix has traversed to reach the current router. Shorter AS_PATH = fewer hops = preferred. Also used as the primary loop prevention mechanism — if a router sees its own AS number in the AS_PATH, it rejects the route.
NEXT_HOP Well-known Mandatory The IP address of the next-hop router to use to reach the advertised prefix. For eBGP, set to the advertising router's interface. For iBGP, unchanged from the eBGP peer — must be reachable via the IGP.
ORIGIN Well-known Mandatory Indicates how the prefix entered BGP: IGP (i) — injected via network command; EGP (e) — learned from old EGP protocol (rarely seen); Incomplete (?) — redistributed from another protocol. IGP is preferred over Incomplete.
LOCAL_PREF Well-known Discretionary Used only within an AS (exchanged between iBGP peers, never sent to eBGP peers). Higher value is preferred. Default = 100. Used to influence which exit point an AS uses to reach an external destination — the primary tool for outbound traffic engineering.
MED (MULTI_EXIT_DISC) Optional Non-Transitive Sent to an eBGP peer to suggest which of multiple entry points into your AS should be used by that peer. Lower value is preferred. Default = 0. Compared only between routes from the same AS by default. Used for inbound traffic engineering.
COMMUNITY Optional Transitive A 32-bit tag attached to prefixes to group them for policy application. Well-known communities include NO_EXPORT (don't advertise beyond AS), NO_ADVERTISE (don't advertise to any peer), and INTERNET (advertise to all). Widely used for ISP traffic engineering and route filtering.
WEIGHT Cisco proprietary (local only) Not a standard BGP attribute — Cisco-specific, local to the router only (never advertised). Higher value is preferred. Default = 0 for learned routes, 32768 for locally originated routes. Checked first in Cisco's BGP best-path algorithm — overrides all other attributes.

6. BGP Best-Path Selection Algorithm

When BGP has multiple paths to the same prefix, it selects a single best path using a deterministic sequence of attribute comparisons. Cisco IOS evaluates attributes in the following order — the first attribute that differs between paths decides the winner:

Step Attribute / Criterion Preference Scope
1 WEIGHT Higher is better Local router only (Cisco proprietary)
2 LOCAL_PREF Higher is better Within the AS (iBGP only)
3 Locally originated route Local origin preferred over learned routes Prefer routes originated via network or redistribute on this router
4 AS_PATH length Shorter is better Fewer AS hops = more preferred
5 ORIGIN IGP (i) > EGP (e) > Incomplete (?) How the route was injected into BGP
6 MED Lower is better Compared only between routes from the same AS
7 eBGP over iBGP eBGP-learned route preferred over iBGP-learned route —
8 IGP metric to NEXT_HOP Lower IGP cost to reach NEXT_HOP is better Uses the IGP routing table to compare next-hop reachability
9 Oldest eBGP route Prefer the route received first (most stable) eBGP routes only
10 BGP Router ID Lower Router ID is better Tiebreaker — lowest BGP Router ID of the next-hop router
11 Shortest cluster list Shorter cluster list preferred Route reflector environments only
12 Lowest neighbour IP address Lower IP address of the peer is better Final tiebreaker

A common memory aid for the first four steps: We Love Oranges As Snacks — Weight, Local_pref, Originally local, AS_path, Origin, MED…

7. BGP Router ID

Every BGP router has a Router ID (RID) — a 32-bit value presented in dotted-decimal notation (e.g., 1.1.1.1) that uniquely identifies the router within a BGP session. The Router ID is selected using the same logic as OSPF:

Priority Selection Method
1 (highest) Manually configured: bgp router-id <A.B.C.D>
2 Highest IP address on any loopback interface that is up/up
3 Highest IP address on any physical interface that is up/up

Best practice: always configure a loopback interface with a stable /32 IP and use it as the BGP Router ID and the source of iBGP sessions. Loopbacks never go down due to a physical link failure, keeping iBGP sessions stable even if a physical path fails (provided the IGP can still reach the loopback).

8. Basic BGP Configuration (Cisco IOS)

The following demonstrates a minimal eBGP configuration between two routers in different autonomous systems, and a basic iBGP configuration within the same AS.

8.1 eBGP Configuration Example

! ========== Router A (AS 65001) ==========
RouterA(config)# router bgp 65001
RouterA(config-router)# bgp router-id 1.1.1.1
RouterA(config-router)# neighbor 203.0.113.2 remote-as 65002       ! eBGP peer in AS 65002
RouterA(config-router)# network 192.168.1.0 mask 255.255.255.0     ! Advertise this prefix
RouterA(config-router)# exit

! ========== Router B (AS 65002) ==========
RouterB(config)# router bgp 65002
RouterB(config-router)# bgp router-id 2.2.2.2
RouterB(config-router)# neighbor 203.0.113.1 remote-as 65001       ! eBGP peer in AS 65001
RouterB(config-router)# network 10.0.0.0 mask 255.0.0.0            ! Advertise this prefix
RouterB(config-router)# exit

8.2 iBGP Configuration Example

! ========== Router A (AS 65001) — iBGP with Router C (same AS) ==========
RouterA(config)# router bgp 65001
RouterA(config-router)# neighbor 10.0.0.2 remote-as 65001          ! iBGP — same AS number
RouterA(config-router)# neighbor 10.0.0.2 update-source Loopback0  ! Use loopback as source
RouterA(config-router)# exit

! ========== Router C (AS 65001) — iBGP with Router A ==========
RouterC(config)# router bgp 65001
RouterC(config-router)# neighbor 10.0.0.1 remote-as 65001          ! iBGP — same AS number
RouterC(config-router)# neighbor 10.0.0.1 update-source Loopback0
RouterC(config-router)# exit

8.3 eBGP Multihop (for non-directly-connected peers)

! eBGP peers are not directly connected — increase TTL
RouterA(config-router)# neighbor 203.0.113.10 remote-as 65003
RouterA(config-router)# neighbor 203.0.113.10 ebgp-multihop 2      ! Allow TTL up to 2 hops

For a complete guided lab, see BGP eBGP Configuration Lab. For summarising BGP prefixes before advertising them, see Route Summarisation & Aggregation. ACLs and prefix lists are commonly used to filter BGP advertisements — see ACL Overview.

9. Where BGP Fits — Enterprise vs ISP

BGP is not used in every network. Understanding when BGP is appropriate versus when a default route or static route is sufficient is a key skill.

Scenario BGP Needed? Typical Solution
Single-homed enterprise — one ISP, one connection No A static default route to the ISP; ISP advertises your prefix via its own BGP. No BGP needed on your router.
Dual-homed enterprise — two connections to the same ISP Rarely Static routes with floating defaults or HSRP/tracking. BGP only if you need inbound load balancing control.
Multi-homed enterprise — two or more different ISPs Yes eBGP to each ISP; use LOCAL_PREF for outbound path preference and MED or AS_PATH prepending for inbound traffic engineering.
Internet Service Provider (ISP) Yes — always Full BGP with multiple eBGP peers; carries full internet routing table (~1 million+ prefixes); uses route reflectors for iBGP scaling.
Data centre / cloud provider Yes BGP used both externally (to ISPs) and internally (BGP as IGP in large-scale data centres — e.g., RFC 7938).
SD-WAN overlay networks Sometimes BGP may run between SD-WAN edges and hub sites for prefix advertisement; underlying transport uses default routes.

9.1 Full Table vs Partial Table vs Default Route

Option What You Receive from ISP Use Case
Full BGP table All ~1,000,000+ internet prefixes ISPs and large enterprises needing optimal path selection to every destination on the internet. Requires significant router memory and CPU.
Partial table Selected prefixes (e.g., customer routes) + default route Enterprises that want some BGP path control without storing the full internet table
Default route only 0.0.0.0/0 — send everything to ISP Small enterprises and single-homed sites — simplest, lowest resource requirement

10. BGP Verification Commands

Command Output / Purpose
show bgp summary Overview of all BGP neighbours — state (Established / Idle / Active), up/down time, number of prefixes received from each peer
show bgp neighbors Detailed per-neighbour information — BGP state, hold time, keepalive interval, capabilities, message counters, and session uptime
show bgp ipv4 unicast BGP table for IPv4 unicast — all known prefixes with their path attributes; best path marked with >
show bgp ipv4 unicast <prefix> Detailed path information for a specific prefix — all known paths, attributes, and why the best path was selected
show ip route bgp Only BGP-learned routes installed in the IP routing table (routes marked with B) — see show ip route for full routing table interpretation
show bgp neighbors <IP> advertised-routes Prefixes being advertised to a specific BGP neighbour
show bgp neighbors <IP> received-routes Prefixes received from a specific BGP neighbour (requires soft-reconfiguration inbound enabled)
clear ip bgp * soft Soft reset all BGP sessions — re-applies policy without tearing down TCP sessions
debug ip bgp Real-time BGP events — neighbour state changes, UPDATE messages sent/received (use with caution in production)

11. BGP Quick-Reference Summary

BGP Concept Key Fact
Full name Border Gateway Protocol
RFC RFC 4271 (BGP-4)
Protocol type Exterior Gateway Protocol (EGP) — path-vector
Transport TCP port 179
eBGP Admin Distance 20
iBGP Admin Distance 200
eBGP default TTL 1 (peers must be directly connected unless ebgp-multihop configured)
iBGP default TTL 255 (peers can be multiple hops away)
Neighbour discovery Manual only — no auto-discovery
Hold Time default 180 seconds
Keepalive default 60 seconds
Best path: first attribute checked WEIGHT (Cisco proprietary, local only) — higher wins
Outbound traffic control LOCAL_PREF (higher = preferred exit) — iBGP only
Inbound traffic suggestion MED (lower = preferred entry) — eBGP, same-AS comparison
Loop prevention AS_PATH — route rejected if local AS number found in AS_PATH
iBGP scaling solution Route Reflectors (RFC 4456)

Test Your Knowledge – BGP Quiz

1. What type of protocol is BGP, and what transport does it use?

Correct answer is C. BGP is the only EGP in use today and is classified as a path-vector protocol. It uses TCP port 179 for reliable, connection-oriented transport between peers — inheriting TCP's reliability removes the need for BGP to implement its own retransmission.

2. What is the key difference between eBGP and iBGP?

Correct answer is B. The defining distinction is the AS relationship. eBGP (External BGP) operates between routers in different autonomous systems — such as your edge router and your ISP's router. iBGP (Internal BGP) operates between routers in the same autonomous system — used to distribute BGP routing information internally.

3. A router running iBGP learns a route from an iBGP peer. Can it advertise that route to another iBGP peer?

Correct answer is D. The iBGP split-horizon rule states that routes learned from an iBGP peer must not be re-advertised to another iBGP peer. This prevents routing loops within the AS. The consequence is that all iBGP routers must either form a full mesh (every router peers with every other) or use Route Reflectors / Confederations to propagate routes.

4. Which BGP path attribute is used to influence outbound traffic flow (which exit point your AS uses to reach an external destination)?

Correct answer is A. LOCAL_PREF is the primary tool for outbound traffic engineering. It is set by the border router when receiving a route from an eBGP peer, then distributed to all iBGP peers. All internal routers prefer the exit with the highest LOCAL_PREF. Default value is 100; a value of 200 on one path makes that path preferred.

5. What is the default administrative distance for eBGP routes on Cisco IOS?

Correct answer is C. eBGP has an administrative distance of 20 — lower than OSPF (110), EIGRP (90/170), and RIP (120), making eBGP routes highly preferred when they exist. iBGP has an AD of 200 — the highest of any dynamic routing protocol — meaning iBGP routes are used only as a last resort when no IGP route exists for the same destination.

6. In Cisco's BGP best-path selection algorithm, which attribute is evaluated FIRST?

Correct answer is B. WEIGHT is evaluated first in Cisco's BGP best-path algorithm. It is a Cisco-proprietary attribute that is local to the router — it is never advertised to BGP peers. Higher WEIGHT is preferred. Default WEIGHT is 0 for learned routes and 32768 for locally originated routes. Because it is checked first, it overrides all other attributes including LOCAL_PREF.

7. What is the purpose of the AS_PATH attribute in BGP?

Correct answer is D. AS_PATH is a well-known mandatory attribute that carries an ordered list of every AS a route has passed through. It serves two purposes: (1) loop prevention — a router discards a route if its own AS number appears in the AS_PATH; (2) path selection — shorter AS_PATH (fewer ASes traversed) is preferred when other attributes are equal.

8. An eBGP session between two directly connected routers fails to establish. You check and find the TCP session is not forming. What is the most likely cause related to eBGP's default TTL behaviour?

Correct answer is A. eBGP sets TTL=1 by default, which means the BGP TCP packets are dropped after one hop. For directly connected peers this is fine, but for non-directly-connected eBGP peers (e.g., peering over a loopback across multiple hops) you must use ebgp-multihop <ttl> to increase the TTL. Also verify that TCP port 179 is not blocked by an ACL or firewall between the peers.

9. A small enterprise connects to a single ISP with one circuit. Should they run BGP to the ISP?

Correct answer is C. For a single-homed enterprise with one ISP and one connection, a static default route (ip route 0.0.0.0 0.0.0.0 <ISP-gateway>) is all that is needed. BGP is justified when you connect to multiple ISPs and need to control inbound and outbound traffic paths, or when you need to advertise your own public IP prefixes autonomously.

10. Which BGP message type is used to advertise new prefixes or withdraw previously advertised prefixes?

Correct answer is B. BGP UPDATE messages carry all routing information changes. An UPDATE can contain: (1) new prefixes (NLRI — Network Layer Reachability Information) with their path attributes to advertise; (2) withdrawn routes that are no longer reachable. OPEN establishes the session, KEEPALIVE maintains it, and NOTIFICATION reports errors and tears down the session.

← Back to Home