BGP Basics — eBGP Between Two Routers
BGP (Border Gateway Protocol) is the routing protocol that runs the internet. Every time your browser connects to a website, BGP is responsible for finding a path between your ISP's network and the destination — across hundreds of independently operated networks worldwide. Unlike OSPF or EIGRP, which are designed for routing within a single organisation, BGP is designed for routing between organisations — each identified by a globally unique Autonomous System (AS) number.
There are two flavours of BGP: eBGP (external BGP) runs between routers in different autonomous systems — this is what connects your network to an ISP, or one ISP to another. iBGP (internal BGP) runs between routers within the same AS, typically to distribute externally learned routes internally. This lab focuses entirely on eBGP — the foundation you must understand before tackling iBGP, route policies, or multi-homed ISP designs. For how BGP interacts with interior gateway protocols, see OSPF Single-Area Configuration and EIGRP Configuration.
Before starting, you should be comfortable with static routing concepts from Static Route Configuration and understand how to read the IP routing table from show ip route. For context on how BGP fits alongside IGPs like OSPF, see Administrative Distance and Route Sources. If you are building a multi-router lab, interface configuration is covered in Basic Interface Configuration.
1. BGP Core Concepts
Autonomous Systems and AS Numbers
An Autonomous System (AS) is a collection of IP networks under a single administrative domain that presents a unified routing policy to the internet. Every AS is identified by a unique AS number (ASN) — either a 16-bit number (1–65535) or a 32-bit extended number (up to 4,294,967,295):
| AS Number Range | Type | Use |
|---|---|---|
| 1 – 64511 | Public (16-bit) | Globally routable — assigned by IANA/RIRs (ARIN, RIPE, APNIC). Used by ISPs and large organisations connecting to the internet |
| 64512 – 65535 | Private (16-bit) | Not globally routable — for internal use and labs. Like RFC 1918 addresses, but for AS numbers |
| 131072 – 4,294,967,294 | Public (32-bit) | Extended AS numbers for modern internet scale. Written as X.Y notation (e.g., 1.0) or plain decimal (e.g., 65536) |
eBGP vs iBGP
| Property | eBGP (External BGP) | iBGP (Internal BGP) |
|---|---|---|
| AS relationship | Neighbours are in different AS numbers | Neighbours are in the same AS number |
| Typical use | Connecting to ISPs, peering with other organisations | Distributing BGP routes internally across multiple routers in the same AS. Often used with MPLS |
| Default TTL | TTL = 1 — peer must be directly connected (one hop) | TTL = 255 — peer can be anywhere in the AS (uses loopbacks) |
| AD value | 20 — preferred over iBGP and most IGPs | 200 — least preferred; IGP routes beat iBGP |
| Next-hop behaviour | Next-hop changes to the eBGP peer's IP when advertising to iBGP peers | Next-hop is not changed — iBGP preserves the eBGP next-hop (next-hop-self often needed) |
BGP Session Establishment — The 6 States
BGP uses a finite state machine to establish a TCP session (port 179) before any routing information is exchanged. Understanding these states is essential for troubleshooting — a stuck state tells you exactly where the problem lies:
| State | Description | If Stuck Here — Likely Cause |
|---|---|---|
| Idle | BGP is not attempting to connect. Waiting for a start event or recovering from an error | BGP process not started, or repeated connection failures causing hold-down |
| Connect | BGP is attempting a TCP connection to the neighbour on port 179 | TCP connectivity issue — wrong IP, ACL blocking port 179, no route to peer |
| Active | TCP connection attempt failed. BGP is retrying — listening for incoming connections from the peer | Peer IP misconfigured, wrong AS number in neighbor statement, no route to peer |
| OpenSent | TCP connected. BGP OPEN message sent — waiting for the peer's OPEN message | Peer received OPEN but has a mismatch (AS number, BGP version) |
| OpenConfirm | OPEN received and accepted. Exchanging KEEPALIVE messages to confirm the session | Rare — KEEPALIVE not arriving, authentication mismatch |
| Established | Session fully up. BGP peers exchange UPDATE messages containing routing information | — Session is healthy. Routes are being exchanged |
How BGP Advertises Routes — The network Statement
Unlike OSPF or EIGRP which discover and advertise interfaces automatically,
BGP requires explicit instruction on what to advertise. The
network statement tells BGP: "advertise this prefix to
my neighbours — but only if an exact match for this prefix
already exists in the local routing table (RIB)". Note that OSPF uses
wildcard masks while BGP uses
subnet masks — a common exam trap:
BGP network statement logic:
router bgp 65001
network 10.0.0.0 mask 255.255.255.0
Step 1: Does 10.0.0.0/24 exist as an EXACT match in the IP routing table?
┌─────────────────────────────────────────────────────────┐
│ YES (connected, static, or IGP) → BGP installs the │
│ prefix into the BGP table and advertises it to peers │
│ │
│ NO (route missing or wrong prefix length) → BGP does │
│ NOT advertise — no error is shown. This silent failure │
│ is the #1 BGP misconfiguration for beginners │
└─────────────────────────────────────────────────────────┘
Key difference from OSPF/EIGRP:
OSPF: network 10.0.0.0 0.0.0.255 area 0 → enables OSPF on matching interfaces
BGP: network 10.0.0.0 mask 255.255.255.0 → advertises this prefix to BGP peers
(uses subnet MASK, not wildcard — opposite of OSPF)
BGP Path Attributes — Why BGP Chooses One Path Over Another
| Attribute | Type | Description | Preference |
|---|---|---|---|
| Weight | Cisco proprietary | Local to the router — not advertised to peers. Highest weight preferred | Higher = better |
| LOCAL_PREF | Well-known discretionary | Shared within the AS (iBGP). Controls which exit point the AS uses for outbound traffic | Higher = better |
| AS_PATH | Well-known mandatory | List of AS numbers a route has traversed. Prevents routing loops — if own AS in path, route is rejected | Shorter = better |
| ORIGIN | Well-known mandatory | How the route entered BGP: i (IGP/network stmt) > e (EGP, legacy) > ? (incomplete/redistributed) | i > e > ? |
| MED | Optional non-transitive | Multi-Exit Discriminator — hints to the neighbouring AS which entry point to use for inbound traffic | Lower = better |
| NEXT_HOP | Well-known mandatory | IP address of the next-hop router to reach the destination. Must be reachable for route to be valid | Must be reachable |
2. Lab Topology & Scenario
This lab connects two routers — each in a separate autonomous system — via a point-to-point eBGP session. NetsTuts_R1 represents an enterprise edge router (AS 65001) and NetsTuts_R2 represents an ISP border router (AS 65002). The goal is to establish the eBGP session and have each AS advertise its internal network prefix to the other, achieving full end-to-end reachability.
AS 65001 (Enterprise) AS 65002 (ISP)
┌────────────────────┐ ┌────────────────────┐
│ NetsTuts_R1 │ │ NetsTuts_R2 │
│ │ │ │
│ Lo0: 10.1.1.1/32 │ │ Lo0: 10.2.2.2/32 │
│ LAN: 192.168.1.0 │ │ LAN: 192.168.2.0 │
│ /24 │ │ /24 │
│ │ eBGP │ │
│ Gi0/0: 203.0.113.1├─────────────┤203.0.113.2 :Gi0/0 │
│ │ /30 link │ │
└────────────────────┘ └────────────────────┘
Point-to-point link: 203.0.113.0/30
R1 Gi0/0: 203.0.113.1
R2 Gi0/0: 203.0.113.2
Networks to advertise:
R1 → advertises 192.168.1.0/24 (its LAN) to R2
R2 → advertises 192.168.2.0/24 (its LAN) to R1
Lab Objectives:
1. Configure eBGP neighbor relationship between R1 and R2
2. Advertise each router's LAN prefix via BGP network statement
3. Verify the session reaches Established state
4. Confirm prefixes appear in the BGP table and routing table
5. Test end-to-end reachability with ping
| Device | AS Number | Gi0/0 (eBGP link) | LAN Prefix | Loopback 0 |
|---|---|---|---|---|
| NetsTuts_R1 | 65001 | 203.0.113.1/30 | 192.168.1.0/24 | 10.1.1.1/32 |
| NetsTuts_R2 | 65002 | 203.0.113.2/30 | 192.168.2.0/24 | 10.2.2.2/32 |
3. Step 1 — Configure Interfaces
Before configuring BGP, the point-to-point link between R1 and R2
must be up and reachable. Both routers also need their LAN networks
in the routing table so the BGP network statement has
an exact prefix to match against:
NetsTuts_R1 — Interface Configuration
NetsTuts_R1>en NetsTuts_R1#conf t Enter configuration commands, one per line. End with CNTL/Z. ! ── eBGP peering interface ─────────────────────────────── NetsTuts_R1(config)#interface GigabitEthernet0/0 NetsTuts_R1(config-if)#ip address 203.0.113.1 255.255.255.252 NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#description eBGP link to NetsTuts_R2 AS65002 NetsTuts_R1(config-if)#exit ! ── Loopback (advertised into BGP for reachability demo) ─ NetsTuts_R1(config)#interface Loopback0 NetsTuts_R1(config-if)#ip address 10.1.1.1 255.255.255.255 NetsTuts_R1(config-if)#exit ! ── Simulate LAN with a static route (or use a real LAN int) NetsTuts_R1(config)#ip route 192.168.1.0 255.255.255.0 Null0 NetsTuts_R1(config)#exit
The
ip route 192.168.1.0 255.255.255.0 Null0 is a
common lab technique — it adds the LAN prefix to the routing table
without requiring a physical LAN interface, giving the BGP
network statement an exact match to advertise. In
production, this would be a connected LAN interface instead.
The Null0 route is also called an aggregate route
or discard route — traffic routed to Null0 is
silently dropped, which also helps prevent routing loops. See
Route Summarization & Aggregation
for how this pattern is used for prefix aggregation.
NetsTuts_R2 — Interface Configuration
NetsTuts_R2>en NetsTuts_R2#conf t Enter configuration commands, one per line. End with CNTL/Z. ! ── eBGP peering interface ─────────────────────────────── NetsTuts_R2(config)#interface GigabitEthernet0/0 NetsTuts_R2(config-if)#ip address 203.0.113.2 255.255.255.252 NetsTuts_R2(config-if)#no shutdown NetsTuts_R2(config-if)#description eBGP link to NetsTuts_R1 AS65001 NetsTuts_R2(config-if)#exit ! ── Loopback ───────────────────────────────────────────── NetsTuts_R2(config)#interface Loopback0 NetsTuts_R2(config-if)#ip address 10.2.2.2 255.255.255.255 NetsTuts_R2(config-if)#exit ! ── Simulate LAN ───────────────────────────────────────── NetsTuts_R2(config)#ip route 192.168.2.0 255.255.255.0 Null0 NetsTuts_R2(config)#exit
Verify Link Reachability Before BGP
NetsTuts_R1#ping 203.0.113.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 203.0.113.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
The link must be up before configuring BGP. If this ping fails, stop
and resolve the Layer 1/2/3 issue first — BGP cannot establish a TCP
session if the peer is unreachable. The five exclamation marks confirm
full connectivity across the /30 link.
4. Step 2 — Configure BGP on NetsTuts_R1 (AS 65001)
BGP configuration has three essential components: start the BGP process with your own AS number, declare the neighbour's IP and their AS number, and specify what networks to advertise:
NetsTuts_R1#conf t ! ── Start BGP process — AS 65001 ───────────────────────── NetsTuts_R1(config)#router bgp 65001 ! ── Identify this router in the BGP table ──────────────── NetsTuts_R1(config-router)#bgp router-id 10.1.1.1 ! ── Declare the eBGP neighbour ─────────────────────────── ! ── IP = R2's directly connected IP, remote-as = R2's AS ─ NetsTuts_R1(config-router)#neighbor 203.0.113.2 remote-as 65002 NetsTuts_R1(config-router)#neighbor 203.0.113.2 description ISP-R2 ! ── Advertise R1's LAN prefix into BGP ─────────────────── ! ── IMPORTANT: mask keyword — NOT a wildcard like OSPF ─── NetsTuts_R1(config-router)#network 192.168.1.0 mask 255.255.255.0 ! ── Advertise the loopback ─────────────────────────────── NetsTuts_R1(config-router)#network 10.1.1.1 mask 255.255.255.255 NetsTuts_R1(config-router)#exit NetsTuts_R1(config)#end NetsTuts_R1#wr Building configuration... [OK]
Breaking down the key commands:
router bgp 65001 — starts the BGP process
and assigns this router to AS 65001. There can only be one BGP process
per router.
bgp router-id 10.1.1.1 — manually sets
the BGP router ID (a 32-bit value shown as a dotted-decimal IP). Without
this, IOS picks the highest loopback IP automatically — but explicit
configuration is best practice for predictability.
neighbor 203.0.113.2 remote-as 65002 —
tells R1 to peer with R2 at 203.0.113.2, expecting R2 to announce itself
as AS 65002 in the OPEN message. If R2 announces a different AS, the
session is rejected.
network 192.168.1.0 mask 255.255.255.0 —
instructs BGP to advertise this exact prefix. The word mask
precedes a subnet mask (not a wildcard — this is a common exam trap).
5. Step 3 — Configure BGP on NetsTuts_R2 (AS 65002)
R2's configuration mirrors R1's — but with its own AS number, its own
router ID, R1 as the neighbour (with R1's AS number), and its own
LAN prefix in the network statement:
NetsTuts_R2#conf t ! ── Start BGP process — AS 65002 ───────────────────────── NetsTuts_R2(config)#router bgp 65002 ! ── Set router ID ──────────────────────────────────────── NetsTuts_R2(config-router)#bgp router-id 10.2.2.2 ! ── Declare the eBGP neighbour (R1) ────────────────────── NetsTuts_R2(config-router)#neighbor 203.0.113.1 remote-as 65001 NetsTuts_R2(config-router)#neighbor 203.0.113.1 description Enterprise-R1 ! ── Advertise R2's LAN prefix into BGP ─────────────────── NetsTuts_R2(config-router)#network 192.168.2.0 mask 255.255.255.0 NetsTuts_R2(config-router)#network 10.2.2.2 mask 255.255.255.255 NetsTuts_R2(config-router)#exit NetsTuts_R2(config)#end NetsTuts_R2#wr Building configuration... [OK]
Once both routers have their BGP configuration applied, the session
establishment begins automatically. R1 attempts a TCP connection to
R2 on port 179. They exchange OPEN messages, verify AS numbers match
expectations, exchange KEEPALIVE messages, and transition to the
Established state — at which point UPDATE messages
containing route prefixes are exchanged. This typically takes
5–30 seconds on a lab topology.
6. Step 4 — Optional: Useful eBGP Tuning Commands
These commands are not required for basic eBGP to work, but are commonly seen in production and lab scenarios:
BGP Timers — Keepalive and Hold Time
! ── Default: keepalive 60s, hold-time 180s (3x keepalive) ! ── Reduce for faster failure detection in labs: NetsTuts_R1(config-router)#neighbor 203.0.113.2 timers 10 30
BGP sends a KEEPALIVE every 60 seconds by default.
If no KEEPALIVE or UPDATE is received within the hold time
(180 seconds), the session is torn down. Reducing these
(e.g., 10/30) speeds up convergence detection in labs but increases
BGP control plane traffic. The hold time must be at least 3× the
keepalive interval — both peers must agree, and the lower values
are used when they differ.
MD5 Authentication
! ── Protect the BGP session with a shared password ─────── ! ── Must match on BOTH routers exactly ─────────────────── NetsTuts_R1(config-router)#neighbor 203.0.113.2 password NetsTuts@2025 NetsTuts_R2(config-router)#neighbor 203.0.113.1 password NetsTuts@2025
BGP MD5 authentication adds a password hash to every TCP segment of
the BGP session. Any segment arriving without the correct hash is
silently dropped — this prevents session hijacking and route injection
from spoofed TCP packets. The password must be identical on both peers
or the session will not establish (it will stay in the Active state).
Default Route Advertisement
! ── R2 (ISP) advertises a default route to R1 (Enterprise) ! ── R2 must have a default route in its own routing table NetsTuts_R2(config-router)#neighbor 203.0.113.1 default-originate
default-originate causes R2 to send a 0.0.0.0/0 default
route to R1 via BGP — even if R2 does not have a default route itself
(unlike the network statement which requires an exact RIB
match). This is how ISPs typically give customers a default route: the
enterprise router learns the default via BGP rather than needing a
static default configured manually.
Disable Automatic Summarisation
! ── Disable auto-summary on BOTH routers (default ON in older IOS) ! ── Auto-summary can advertise classful summaries instead of exact prefixes NetsTuts_R1(config-router)#no auto-summary NetsTuts_R2(config-router)#no auto-summary
In older IOS versions, BGP's
auto-summary is enabled by
default and summarises prefixes to their classful boundary (e.g.,
192.168.1.0/24 stays the same, but 10.1.1.1/32 could be summarised
to 10.0.0.0/8). This is almost always undesirable — no auto-summary
ensures BGP advertises exact prefixes as specified in the
network statement. Modern IOS versions (12.3+) have
auto-summary disabled by default for BGP.
7. Verification
show bgp summary — Session Status at a Glance
NetsTuts_R1#show bgp summary BGP router identifier 10.1.1.1, local AS number 65001 BGP table version is 5, main routing table version 5 4 network entries using 576 bytes of memory 4 path entries using 320 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 203.0.113.2 4 65002 12 12 5 0 0 00:04:23 2
This is the most important BGP verification command — it shows
everything about the session in one line per neighbour.
V = BGP version (always 4 today).
AS = the remote AS number — confirms R2 announced 65002.
MsgRcvd/MsgSent = message counters — incrementing values
confirm the session is alive and exchanging data.
Up/Down = session uptime (00:04:23 = healthy).
State/PfxRcd = either a state name (Active, Connect,
Idle) if the session is not Established, or a number showing how many
prefixes were received from this peer. Here, 2 prefixes
received from R2 — confirming R2 is advertising both its LAN and
loopback.
Reading the State/PfxRcd column:
A number means the session is Established and that
many prefixes were received. A word (Active, Idle, Connect) means the
session has not reached Established — this is the first place
to look when BGP is not working.
show ip bgp — The BGP Routing Table
NetsTuts_R1#show ip bgp
BGP table version is 5, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
*> 10.2.2.2/32 203.0.113.2 0 0 65002 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0 203.0.113.2 0 0 65002 i
Decoding each column:
* (asterisk) = valid route — the next-hop
is reachable and the route is eligible for use.
> (chevron) = best path — this route
is selected as the best and will be installed into the IP routing table.
Routes without > are in the BGP table but not installed.
Next Hop 0.0.0.0 = locally originated routes (R1 advertised
these itself via the network statement).
Next Hop 203.0.113.2 = routes learned from R2.
Weight 32768 = locally originated routes get weight 32768
by default; routes learned from peers get weight 0.
Path 65002 i = AS_PATH is 65002 (one hop through R2's AS),
origin is i (IGP — advertised via network
statement, the most trustworthy origin type).
show ip bgp — On R2 (Verify R2 Received R1's Prefixes)
NetsTuts_R2#show ip bgp BGP table version is 5, local router ID is 10.2.2.2 Network Next Hop Metric LocPrf Weight Path *> 10.1.1.1/32 203.0.113.1 0 0 65001 i *> 10.2.2.2/32 0.0.0.0 0 32768 i *> 192.168.1.0 203.0.113.1 0 0 65001 i *> 192.168.2.0 0.0.0.0 0 32768 i
R2's BGP table is the mirror of R1's. R2 now has R1's LAN
(192.168.1.0) and loopback (10.1.1.1/32) with next-hop 203.0.113.1
(R1's eBGP interface). The AS_PATH for these routes is
65001 i
— one hop through R1's AS.
show ip route — Confirm BGP Routes in the Routing Table
NetsTuts_R1#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
10.0.0.0/32 is subnetted, 1 subnets
B 10.2.2.2 [20/0] via 203.0.113.2, 00:04:23
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.2.0/24 [20/0] via 203.0.113.2, 00:04:23
B = BGP route. [20/0] = administrative
distance 20 (eBGP) / metric 0 (BGP does not use a traditional metric
like OSPF cost). via 203.0.113.2 = next-hop is R2's
interface. R1 can now reach R2's LAN (192.168.2.0/24) and loopback
(10.2.2.2) via the eBGP-learned routes.
show bgp neighbors — Detailed Session Information
NetsTuts_R1#show bgp neighbors 203.0.113.2
BGP neighbor is 203.0.113.2, remote AS 65002, external link
BGP version 4, remote router ID 10.2.2.2
BGP state = Established, up for 00:04:23
Last read 00:00:08, last write 00:00:08, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
...
Prefixes Current: 2 2 (Sent/Received)
...
Connections established 1; dropped 0
Local host: 203.0.113.1, Local port: 54623
Foreign host: 203.0.113.2, Foreign port: 179
show bgp neighbors [peer-IP] gives exhaustive detail about
a single BGP session. Key things to check:
BGP state = Established — the session is up.
remote router ID 10.2.2.2 — confirms R2's router ID.
hold time / keepalive interval — shows negotiated timer values.
Prefixes Sent/Received — confirms bidirectional prefix exchange.
Foreign port: 179 — confirms BGP is using TCP/179.
Connections established 1; dropped 0 — no session flaps,
a healthy session history.
Verify End-to-End Reachability
! ── Ping R2's LAN from R1 (sourced from R1's LAN address) NetsTuts_R1#ping 192.168.2.1 source 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms ! ── Ping R2's loopback ─────────────────────────────────── NetsTuts_R1#ping 10.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Full end-to-end reachability confirmed. R1 can reach R2's LAN and
loopback via BGP-installed routes. The
source keyword
is important here — it forces the ping to originate from R1's LAN
address (192.168.1.1), testing the return path via BGP as well.
Without the source keyword, the ping would originate from the
outgoing interface (203.0.113.1) which is directly connected and
does not test the BGP return route.
Verification Command Summary
| Command | What It Shows | Primary Use |
|---|---|---|
show bgp summary |
All BGP neighbours — AS, session state or prefix count, uptime, message counters | First command to run — instantly shows session health and prefix exchange status |
show ip bgp |
Full BGP table — all prefixes with next-hop, weight, AS_PATH, origin, best path marker | Verify which routes BGP has learned and which are installed as best paths |
show ip bgp [prefix] [mask] |
Detailed entry for a single prefix — all paths, attributes, why best path was chosen | Deep-dive a specific prefix — confirm attributes and path selection reasoning |
show ip route bgp |
Only BGP-installed routes in the IP routing table (marked B) | Confirm BGP routes made it from the BGP table into the routing table |
show bgp neighbors [IP] |
Detailed session info — state, timers, capabilities, prefix counts, TCP port numbers | Detailed troubleshooting — timers, capabilities negotiation, connection history |
show bgp neighbors [IP] advertised-routes |
Routes this router is advertising to the specified peer | Verify outbound policy — confirm expected routes are being sent to the peer |
show bgp neighbors [IP] received-routes |
All routes received from the peer (requires neighbor soft-reconfiguration inbound) |
See raw inbound updates before any inbound policy is applied |
clear ip bgp [IP] soft |
Soft reset — re-sends outbound updates and re-processes inbound without tearing down the session | Apply policy changes without dropping the BGP session |
show ip route |
Full routing table — BGP routes appear with code B and AD [20/0] | Confirm BGP routes are installed and preferred over other route sources |
8. Troubleshooting BGP eBGP Issues
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| Session stuck in Active state | show bgp summary shows neighbour state as Active |
R1 can initiate TCP toward R2 but the connection is failing. Most common causes: wrong neighbour IP in the neighbor statement, wrong remote-as number, no route to the peer's IP, or ACL blocking TCP/179 |
Verify the peer IP with ping [peer-IP]. Confirm the neighbor IP exactly matches the peer's interface IP. Check for ACLs blocking port 179 with show ip access-lists. Confirm the remote-as number matches the peer's actual AS |
| Session stuck in Idle state | show bgp summary shows Idle — BGP is not even attempting to connect |
BGP is in a hold-down after repeated failures, or the BGP process was just started and has not triggered its first connection attempt | Force a reset: clear ip bgp [peer-IP] (hard reset — tears down and re-establishes). Watch the state transition with debug ip bgp [peer-IP] events |
| Session Established but no prefixes received | show bgp summary shows state = 0 (zero prefixes received) |
The peer is not advertising any routes. Their network statement prefix does not have an exact match in their routing table — silent failure |
On the peer, run show ip bgp — do their locally originated routes show *>? If not, check that the prefix in the network statement exactly matches a route in show ip route. A /24 network statement needs a /24 in the routing table — a /25 will not match |
| Prefix in BGP table but not in routing table | show ip bgp shows the route with *> but show ip route bgp does not show it |
The next-hop IP is not reachable — the BGP route is valid in the BGP table but cannot be installed because IOS cannot resolve the next-hop | Verify the next-hop is reachable: show ip route [next-hop-IP]. For eBGP on directly connected links the next-hop is the peer's interface IP — it should be directly reachable. For iBGP, the next-hop is the eBGP peer's IP which may require an IGP to resolve |
| Authentication mismatch — session drops | Session was working but drops after MD5 authentication was added. State alternates between Active and Established | Passwords do not match on both sides, or one side has authentication configured and the other does not | Verify the password is identical on both routers: show run | include neighbor on both sides. Note: the password is shown in clear text with show run unless service password-encryption is active. After correcting, clear the session: clear ip bgp [peer-IP] |
| Wrong AS number causes OPEN rejection | Session reaches OpenSent but immediately drops. show bgp neighbors shows Connections established 1; dropped 1 |
The remote-as configured on one side does not match the actual AS number the peer announces in its OPEN message |
On R1, confirm: show bgp neighbors 203.0.113.2 | include remote AS. The remote AS in the OPEN message is shown in debug: debug ip bgp [peer-IP] events. Correct the remote-as value to match the peer's actual AS and clear the session |
Key Points & Exam Tips
- BGP is the path vector routing protocol used between autonomous systems on the internet. It is a policy-based protocol — administrators control what is advertised and how paths are preferred, unlike distance-vector or link-state IGPs which converge automatically. For a broader overview, see BGP Overview.
- eBGP runs between routers in different AS numbers (AD = 20). iBGP runs between routers in the same AS (AD = 200). eBGP neighbours are typically directly connected — the default TTL of 1 means a packet must reach the peer in one hop.
- BGP uses TCP port 179 for all session communication — it is the only major routing protocol that relies on TCP rather than its own transport. If TCP/179 is blocked by an ACL, the BGP session cannot establish.
- The three essential configuration commands are:
router bgp [your-AS],neighbor [peer-IP] remote-as [peer-AS], andnetwork [prefix] mask [subnet-mask]. All three must be correct for a session to form and routes to be advertised. - The BGP
networkstatement uses the keywordmaskfollowed by a subnet mask — not a wildcard mask like OSPF.network 192.168.1.0 mask 255.255.255.0is correct;network 192.168.1.0 0.0.0.255is wrong. - The
networkstatement only advertises a prefix if an exact match exists in the local routing table. Anetwork 192.168.1.0 mask 255.255.255.0statement will not advertise if the routing table only has 192.168.1.0/25 — this silent failure is the most common BGP misconfiguration. - In
show ip bgpoutput:*= valid (next-hop reachable),>= best path (installed in routing table). A route without>is in the BGP table but not being used. Routes locally originated have next-hop 0.0.0.0 and weight 32768. Confirm installation withshow ip route. show bgp summaryis the fastest diagnostic command. The State/PfxRcd column shows either the session state (Active, Idle, Connect) or the number of prefixes received. Any word instead of a number means the session is not Established.- BGP path selection evaluates attributes in order: Weight → LOCAL_PREF → locally originated → AS_PATH length → ORIGIN → MED → eBGP over iBGP → IGP metric to next-hop → Router ID. For the CCNA exam, know the first four: Weight (higher better), LOCAL_PREF (higher better), locally originated preferred, shorter AS_PATH preferred.
clear ip bgp [peer-IP] softperforms a soft reset — it re-advertises outbound routes and reprocesses inbound routes without dropping the TCP session. Use this after policy changes.clear ip bgp [peer-IP](hard reset) tears down and rebuilds the session — use only when necessary as it causes a routing disruption.
Next Steps: With a basic eBGP session running, the
natural progression is controlling what gets advertised and preferred.
For filtering BGP advertisements, see
Standard ACL Configuration
and
Extended ACL Configuration
— prefix lists and route maps build on these ACL concepts.
For understanding how BGP routes compare against OSPF and EIGRP routes
in the routing table, review
Administrative Distance.
To see how a default route from BGP provides internet access for the
enterprise, see
Default Route Redistribution into OSPF.
For combining BGP with policy-based routing for multi-ISP traffic
engineering, see Policy-Based Routing (PBR).
For securing the BGP session and the router itself, see
SSH Configuration
and
Login Security — Brute-Force Protection.