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 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.
| 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.
TEST WHAT YOU LEARNED
What is the fundamental difference between eBGP and iBGP?
Correct answer is B. The "e" and "i" prefixes refer solely to the AS relationship between the peers. eBGP (external) = different AS numbers. iBGP (internal) = same AS number. Both use TCP port 179 — the transport is identical. Both support IPv4 and IPv6. The AD difference (20 vs 200) means eBGP routes are strongly preferred over iBGP routes when both exist for the same prefix. iBGP is typically used to propagate eBGP-learned routes across a large AS that has multiple routers — the edge routers run eBGP to external peers and iBGP to internal routers.
A router has this configuration: router bgp 65001 / network 10.0.0.0 mask 255.0.0.0. The routing table shows 10.1.1.0/24 [connected] only. Will BGP advertise the 10.0.0.0/8 prefix to its peers?
Correct answer is D. The BGP network statement demands a bit-for-bit exact match — both the network address and the prefix length must match an entry in the local RIB. A /24 connected route does not satisfy a /8 network statement. BGP will not generate an error — it silently does nothing. This is the most common BGP misconfiguration trap. The fix is either: (1) change the network statement to match an existing route exactly, or (2) add the exact prefix to the routing table (e.g., a static route to Null0 for the aggregate). Option B describes auto-summary behaviour, which is disabled by default in modern IOS.
In the output of show bgp summary, the State/PfxRcd column for a neighbour shows Active. What does this mean?
Correct answer is A. In the BGP finite state machine, "Active" is a specific state that means TCP connection attempts to the peer are failing and BGP is retrying. It does NOT mean the session is working. In the State/PfxRcd column: a number (like 2, 5, 10) means the session is Established and that many prefixes were received. Any word (Active, Idle, Connect, OpenSent) means the session is not Established. "Active" is the most common stuck state seen during troubleshooting — it typically points to a connectivity or configuration issue between the two peers (wrong IP, wrong AS, blocked port, no route).
What TCP port does BGP use, and why is this significant compared to OSPF and EIGRP?
Correct answer is C. BGP uses TCP port 179 — it is the only major routing protocol that runs entirely over TCP. OSPF uses IP protocol number 89 directly. EIGRP uses IP protocol number 88 (RTP — Reliable Transport Protocol, Cisco proprietary). BGP's use of TCP has several implications: (1) TCP provides reliable delivery, so BGP does not need to implement its own retransmission. (2) BGP sessions can be established between non-directly-connected routers (iBGP uses this — peers communicate via loopbacks across the AS). (3) Any ACL blocking TCP port 179 will silently prevent BGP from forming — this is a frequent real-world misconfiguration. (4) BGP is vulnerable to TCP reset attacks, which is why MD5 authentication (TCP-AO in modern implementations) is recommended.
In show ip bgp output, a route shows * but not >. What does this indicate?
Correct answer is D. In BGP table output, the two status codes work independently.
* (valid) means the route is usable: the next-hop is reachable, the AS_PATH does not contain the local AS (no loop), and the route passes any inbound policy. > (best) means this route won the BGP path selection process and will be installed into the IP routing table. A route can be * but not > when: another BGP path to the same prefix has better attributes (shorter AS_PATH, higher LOCAL_PREF, etc.), or a non-BGP route (connected, static, OSPF) to the same prefix has a lower administrative distance and is preferred. Only *> routes are installed in the routing table and actually used for forwarding.What is wrong with this BGP network statement: network 192.168.1.0 0.0.0.255?
Correct answer is B. This is one of the most common BGP configuration errors, especially for engineers coming from OSPF. OSPF uses wildcard masks after the
network command to define which interfaces to enable OSPF on. BGP uses subnet masks after the keyword mask to specify the exact prefix to advertise. The values are inverses of each other: /24 = wildcard 0.0.0.255 (OSPF) vs mask 255.255.255.0 (BGP). IOS will reject network 192.168.1.0 0.0.0.255 with a syntax error or misinterpret the second value as something other than a mask. Always use network [address] mask [subnet-mask] for BGP.Why does eBGP have a default TTL of 1, and what does this mean for neighbour placement?
Correct answer is A. eBGP sets TTL = 1 on its TCP packets by default, which means packets can only survive one router hop before being discarded. This enforces a security boundary: eBGP peers must be directly connected. If you need to peer with a non-directly-connected eBGP neighbour (e.g., across an intermediate transit network), you must use
neighbor [IP] ebgp-multihop [hop-count] to increase the TTL. This is distinct from iBGP, which uses TTL = 255 and is designed to peer between loopback addresses across the AS. The TTL-1 default also provides some protection against spoofed BGP packets from hosts further away on the internet.R1 (AS 65001) shows neighbour R2 (AS 65002) as Established with 0 prefixes received. R2's BGP config has network 172.16.0.0 mask 255.255.0.0. R2's routing table shows 172.16.10.0/24 connected. Why are no prefixes received?
Correct answer is C. The BGP network statement requires a bit-exact prefix match in the routing table. R2 has 172.16.10.0/24 — a /24 subnet of 172.16.0.0/16. The network statement specifies /16 (mask 255.255.0.0). These are different prefixes — the /24 does not satisfy the /16 requirement. BGP generates no error or warning; it simply does not advertise. The standard fix is to add a static Null0 route for the aggregate:
ip route 172.16.0.0 255.255.0.0 Null0 — this places the exact /16 prefix in the routing table, satisfying the network statement. BGP will then originate 172.16.0.0/16 as an aggregated advertisement to R1. Option D is incorrect — BGP has no automatic filter for RFC 1918 private ranges; that requires explicit configuration with route maps or prefix lists.Which BGP path attribute is used to prevent routing loops between autonomous systems, and how does it work?
Correct answer is D. AS_PATH loop prevention is one of BGP's fundamental mechanisms. When R1 (AS 65001) advertises a route to R2 (AS 65002), R2 prepends 65001 to the AS_PATH before advertising it onward. If that route ever came back to R1, R1 would see 65001 in the AS_PATH and reject it — preventing a routing loop. This is elegant because it works without any additional protocol overhead: every router simply checks whether its own identity is in the path history. AS_PATH also serves as a metric — BGP prefers routes with shorter AS_PATHs (fewer AS hops) over longer ones, all else being equal. This is why AS_PATH prepending is used for traffic engineering: prepend your own AS number multiple times to make a path look longer and less preferred.
An engineer makes a route map change on R1 that affects what is advertised to R2. Which command applies the change without dropping the BGP session?
Correct answer is B. A soft reset (
soft) refreshes BGP advertisements without tearing down the TCP session — no routing disruption occurs. Since the change affects what R1 is advertising outbound to R2, soft out is the correct direction. soft out causes R1 to re-send its full BGP table to R2 with the updated outbound policy applied. Option C (soft in) is used when an inbound policy on R1 changes — it re-processes routes received from R2 through the new inbound filters; this requires neighbor soft-reconfiguration inbound to be pre-configured. Option A (hard reset) works but causes a session teardown and temporary routing outage. Option D is incorrect — BGP does not auto-detect route map changes; a manual clear is always required.Related Topics & Step-by-Step Tutorials
Related concepts and next steps:
- BGP – Border Gateway Protocol Overview — BGP theory — eBGP, iBGP, attributes, path selection
- Wide Area Network (WAN) — WAN connectivity where BGP is used
- MPLS – Multiprotocol Label Switching — MPLS — MP-BGP used inside MPLS L3VPN
- OSPF Multi-Area Configuration
- Default Route Redistribution into OSPF
- MPLS Fundamentals