Blog

BGP is the only routing protocol on the CCNP ENCOR blueprint that does not discover its neighbors. There are no hellos, no multicast, no “whoever is out there, speak up.” Every peer is configured by hand, and the session is an ordinary TCP connection on port 179. That single design choice explains why BGP adjacencies fail in ways OSPF adjacencies never do, and why the troubleshooting method is different.

This is part 2 of a four-part BGP series for CCNP ENCOR 350-401 v1.2. The blueprint names neighbor relationships explicitly, which makes this the most directly examinable post in the series. Part 1 covered fundamentals, autonomous systems, and eBGP versus iBGP; part 3 covers route advertisement and path attributes, and part 4 covers the best path selection algorithm.

The Transport: TCP 179

BGP runs over TCP, and the consequences are worth stating explicitly because almost every adjacency failure traces back to one of them.

• Reliability is TCP’s job, not BGP’s. There is no acknowledgement in the BGP protocol itself because TCP already guarantees delivery and ordering. This is why BGP has no sequence numbers and no retransmission logic.
• The peer must be reachable by the routing table before BGP can start. BGP cannot bootstrap its own reachability. For iBGP peering between loopbacks, an IGP must already be advertising those loopbacks — otherwise the TCP session can never open.
• Anything that blocks TCP 179 blocks BGP silently. An ACL, a zone-based firewall, or a control-plane policing policy that does not permit 179 produces a session stuck in Active with no obvious cause.
• The session is initiated by both ends. Whichever router completes the handshake first wins; if both succeed simultaneously, a collision-detection rule keeps the session from the router with the higher BGP router-ID and drops the other.

The router with the higher IP address typically initiates from a random high port to the peer’s port 179; the responder sees an inbound connection to 179. Confirming which is which is occasionally useful:

R1# show tcp brief
TCB       Local Address          Foreign Address        (state)
7F4A2C10  192.0.2.1.179          192.0.2.2.31045        ESTAB

A TCP session in ESTAB with BGP still not Established points at the BGP negotiation — an AS mismatch or capability problem. No TCP session at all points at reachability, an ACL, or the wrong peer address.

The Finite State Machine

A BGP session moves through six states. Knowing which state a stuck session is in tells you almost exactly what is wrong, which is why this is worth memorizing rather than merely recognizing.

Two things about this table are exam-relevant and counter-intuitive:

• Active is bad. It sounds like progress but means the router is actively failing to connect and retrying. A session flapping between Idle and Active is the signature of a peer that cannot be reached.
• Reaching Established proves very little about routing. A session can sit at Established for months while exchanging zero prefixes because of a filter or a missing network statement.

The Five Message Types

All BGP messages share a 19-byte header: a 16-byte marker (all ones), a 2-byte length, and a 1-byte type. Maximum message size is 4096 bytes, extended to 65535 by RFC 8654 where both peers support it.

Three of these deserve more than a table row.

OPEN and What Must Match

The OPEN message is where a session most often dies, because it carries the values both ends must agree on:

The hold time row is the one most often got wrong. Timers do not have to match — unlike OSPF, where a hello/dead mismatch prevents adjacency. BGP simply takes the lower of the two proposed hold times and derives the keepalive interval as one third of it.

NOTIFICATION Always Kills the Session

There is no such thing as a warning in BGP. Any NOTIFICATION message tears the session down, and the error code tells you why:

Codes 2, 4, and 6 account for nearly every real-world case. The log message names them directly:

%BGP-3-NOTIFICATION: sent to neighbor 192.0.2.2 2/2 (peer in wrong AS) 2 bytes FDE8

That is error code 2, subcode 2 — the peer’s AS was not what this router expected. FDE8 is hexadecimal for 65000, which is the AS the peer actually claimed.

ROUTE-REFRESH and Soft Reconfiguration

Changing an inbound policy raises a problem: the router has already discarded the routes the old policy rejected, so it cannot re-evaluate them. There are two solutions, and knowing which is preferred matters.

• ROUTE-REFRESH (RFC 2918) — ask the peer to resend everything. Costs nothing in memory and is the modern default, requiring only that both ends advertise the capability. Triggered by clear bgp ipv4 unicast * soft in.
• Soft reconfiguration inbound — store an unfiltered copy of everything received, so policy can be re-applied locally without asking. Costs memory proportional to the table size, which is prohibitive against a full internet feed. Still needed to use show ... received-routes.

A hard clear bgp ipv4 unicast * resets the sessions entirely and should be avoided in production — against a full table it is a multi-minute outage.

Timers

The relationship is hold time = 3 × keepalive. Setting the hold time to 0 disables keepalives entirely and the session never times out, which is occasionally used with BFD providing failure detection instead.

! Per-neighbor (preferred — takes effect on that session only)
router bgp 65001
 neighbor 192.0.2.2 timers 10 30

! For all neighbors in the process
router bgp 65001
 timers bgp 10 30

Changing timers requires the session to reset before taking effect. Because BGP’s own detection is slow even at aggressive timers, the better answer for fast failure detection is BFD:

interface GigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3
!
router bgp 65001
 neighbor 192.0.2.2 fall-over bfd

That detects failure in under a second instead of 180, without the CPU cost of very aggressive BGP timers.

Configuring the Session

Directly Connected eBGP

This is precisely what the blueprint asks for, and it is the simplest case: peer to the interface address of the directly connected neighbor.

router bgp 65001
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 description eBGP to ISP-A
 !
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
 exit-address-family

No update-source and no ebgp-multihop are needed, because the default TTL of 1 is sufficient to reach a directly connected peer.

iBGP Peering on Loopbacks

Internal sessions should peer between loopbacks so the session survives the loss of any single physical link:

router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family ipv4 unicast
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 next-hop-self
 exit-address-family

update-source Loopback0 is mandatory here. Without it the router sources the TCP session from the outgoing physical interface, the peer sees a source address that does not match its configured neighbor statement, and it refuses the connection. The symptom is a session stuck in Active on one side and Idle on the other.

iBGP does not need ebgp-multihop even across several router hops, because iBGP already uses a TTL of 255.

eBGP Beyond the Blueprint: Multihop and Loopback Peering

The blueprint limits itself to directly connected eBGP neighbors, but understanding why is what makes the limitation meaningful. eBGP sets the IP TTL to 1 by default, on the assumption that the peer is one hop away. Two situations break that assumption:

• Peering to a loopback — reaching the loopback requires at least one routed hop, so TTL 1 expires before arrival.
• A genuinely multi-hop path to the peer, such as across a firewall or a provider’s aggregation layer.

router bgp 65001
 neighbor 10.99.99.2 remote-as 65002
 neighbor 10.99.99.2 ebgp-multihop 2
 neighbor 10.99.99.2 update-source Loopback0

Both commands are needed for eBGP loopback peering, and a static or IGP route to the peer’s loopback must exist. ebgp-multihop raises the outgoing TTL; update-source makes the source address match what the peer expects.

The inverse protection is TTL security (GTSM, RFC 5082), which is frequently confused with multihop on exams:

router bgp 65001
 neighbor 192.0.2.2 ttl-security hops 1

They are mutually exclusive on the same neighbor — configuring one removes the other.

Authentication

router bgp 65001
 neighbor 192.0.2.2 password 7 MySecretKey

This enables TCP MD5 signatures (RFC 2385) on the session. The password must match on both ends; a mismatch produces a session that never reaches Established and logs:

%TCP-6-BADAUTH: No MD5 digest from 192.0.2.2(179) to 192.0.2.1(11000) tableid - 0

Note that authentication protects the TCP session from spoofing and injection; it does not encrypt anything, and it does not validate that the routes being advertised are legitimate. That is what RPKI is for, and it is well beyond ENCOR.

Peer Groups and Peer Templates

Where many neighbors share a policy, a peer group applies it once and improves update generation efficiency:

router bgp 65001
 neighbor IBGP-PEERS peer-group
 neighbor IBGP-PEERS remote-as 65001
 neighbor IBGP-PEERS update-source Loopback0
 neighbor 2.2.2.2 peer-group IBGP-PEERS
 neighbor 3.3.3.3 peer-group IBGP-PEERS
 !
 address-family ipv4 unicast
  neighbor IBGP-PEERS activate
  neighbor IBGP-PEERS next-hop-self
  neighbor 2.2.2.2 peer-group IBGP-PEERS
  neighbor 3.3.3.3 peer-group IBGP-PEERS

Troubleshooting an Adjacency

The reliable method is to work up the stack rather than guessing. Each layer has one question and one command.

Step 1 — Is the peer reachable?

R1# ping 192.0.2.2
R1# show ip route 192.0.2.2
! For loopback peering, source correctly:
R1# ping 2.2.2.2 source Loopback0

Sourcing the ping the same way BGP will source the session is the part people skip, and it is exactly what catches a missing return route.

Step 2 — Does the TCP session open?

R1# show tcp brief | include 179
R1# telnet 192.0.2.2 179 /source-interface Loopback0

A refused connection means nothing is listening — usually the peer has no matching neighbor statement. A timeout means something is dropping the packets, typically an ACL or firewall.

Step 3 — What does BGP say?

R1# show bgp ipv4 unicast summary
R1# show bgp ipv4 unicast neighbors 192.0.2.2

The detailed neighbor output carries the answer in its first few lines:

BGP neighbor is 192.0.2.2,  remote AS 65002, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:14:22
  Last read 00:00:21, last write 00:00:19, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable
  Last reset 00:22:10, due to Peer closed the session
  Connections established 3; dropped 2
  Local host: 192.0.2.1, Local port: 179
  Foreign host: 192.0.2.2, Foreign port: 31045

The two fields that matter most: Last reset … due to names the cause of the most recent failure in plain language, and Connections established / dropped reveals a flapping session even when it happens to be up at the moment you look.

Step 4 — Watch it happen

R1# debug bgp ipv4 unicast events
R1# debug ip bgp                       ! session-level events
R1# clear bgp ipv4 unicast 192.0.2.2   ! force a fresh attempt
R1# undebug all

Always scope a debug to a single neighbor on a production router, and turn it off explicitly.

Symptom-to-Cause Table

Worked Examples

Example 1 — Diagnosing “Active”

R1# show bgp ipv4 unicast summary
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.2       4 65002       0       0        1    0    0 00:04:12 Active

Zero messages received and zero sent is the key detail: the session never got far enough to send an OPEN. That rules out AS mismatch and authentication, both of which require a TCP session first. Work through reachability:

R1# ping 192.0.2.2
Success rate is 100 percent (5/5)

R1# show tcp brief | include 179
(no output)

Reachable at IP level but no TCP session: something is blocking port 179, or the peer has no matching neighbor statement. On the peer:

R2# show run | include neighbor
 neighbor 192.0.2.5 remote-as 65001     ! wrong address — should be 192.0.2.1

Example 2 — Hold Timer Negotiation

R1 proposes: hold time 180, keepalive 60
R2 proposes: hold time  90, keepalive 30

Negotiated: hold time = min(180, 90) = 90 seconds
            keepalive = 90 / 3          = 30 seconds  (both ends)

Both routers now use 30/90, and neither configuration was an error. This is the difference from OSPF worth remembering: mismatched BGP timers are negotiated, not rejected.

Example 3 — Established with Zero Prefixes

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.2       4 65002      48      46        9    0    0 00:42:07        0

The session is healthy — messages are flowing in both directions — but no prefixes arrived. The question is whether the peer is not sending, or this router is discarding. Check both ends:

! On R2 — is anything being advertised?
R2# show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes
Total number of prefixes 0

! On R2 — does BGP even have the route?
R2# show bgp ipv4 unicast
(empty)

! Cause: the network statement mask did not match the routing table
R2# show run | section bgp
 network 10.2.0.0 mask 255.255.0.0      ! but the RIB holds 10.2.2.0/24

If advertised-routes on the peer does show prefixes but none arrive locally, the filter is inbound on this router instead.

Lab Exercises

These run on CML, EVE-NG, GNS3, or physical gear with IOSv, CSR1000v, or Catalyst 8000v. Attempt each task before opening the answer.

Lab 1 — Build and Observe the FSM

Topology: R1 (AS 65001, Gi0/0 = 192.0.2.1/30) directly connected to R2 (AS 65002, Gi0/0 = 192.0.2.2/30).

Tasks:

1. Configure R1’s side of the eBGP session only, and record the state after 60 seconds.
2. Enable debug bgp ipv4 unicast events on R1 and describe what is happening.
3. Configure R2’s side and watch the session transition to Established.
4. Identify the negotiated hold time and keepalive interval.
5. Shut the neighbor on R2 and identify the NOTIFICATION code R1 receives.

! Task 1 — R1 only
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 192.0.2.2 remote-as 65002
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate

R1# show bgp ipv4 unicast summary
192.0.2.2       4 65002   0   0   1  0  0 00:01:02 Active

! Task 3 — R2
router bgp 65002
 bgp router-id 2.2.2.2
 neighbor 192.0.2.1 remote-as 65001
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate

%BGP-5-ADJCHANGE: neighbor 192.0.2.1 Up

! Task 4
R1# show bgp ipv4 unicast neighbors 192.0.2.2 | include hold time
  hold time is 180, keepalive interval is 60 seconds

! Task 5 — on R2
router bgp 65002
 neighbor 192.0.2.1 shutdown

! On R1:
%BGP-3-NOTIFICATION: received from neighbor 192.0.2.2 6/2 (Administrative Shutdown) 0 bytes

Lab 2 — Break It Four Ways

Topology: the working session from Lab 1.

Tasks: introduce each fault, record the resulting state and log message, then repair it before moving on.

1. Change R2’s remote-as to 65009.
2. Restore it, then apply an inbound ACL on R1’s Gi0/0 that denies TCP 179.
3. Restore it, then set an MD5 password on R1 only.
4. Restore it, then change R1’s neighbor address to 192.0.2.6.
5. For each, state which FSM state the session rests in and why.

! Fault 1 — AS mismatch
R2(config-router)# neighbor 192.0.2.1 remote-as 65009
%BGP-3-NOTIFICATION: sent to neighbor 192.0.2.1 2/2 (peer in wrong AS) 2 bytes FDE9
State: Idle / OpenSent cycling.  Code 2/2 = OPEN error, bad peer AS.

! Fault 2 — ACL blocking TCP 179
ip access-list extended BLOCK-BGP
 deny tcp any any eq 179
 permit ip any any
interface GigabitEthernet0/0
 ip access-group BLOCK-BGP in
State: Active.  No TCP session can form; show tcp brief is empty.

! Fault 3 — one-sided MD5
R1(config-router)# neighbor 192.0.2.2 password CISCO
%TCP-6-BADAUTH: No MD5 digest from 192.0.2.2(179) to 192.0.2.1(15332)
State: Active / OpenConfirm.  TCP itself rejects the unsigned segments.

! Fault 4 — wrong neighbor address
R1(config-router)# no neighbor 192.0.2.2 remote-as 65002
R1(config-router)# neighbor 192.0.2.6 remote-as 65002
State: Idle, then Active.  192.0.2.6 is outside the /30, so there is no route to it.

Lab 3 — Loopback Peering, Both Flavours

Topology: R1 (AS 65001, Lo0 = 1.1.1.1/32) and R2 (AS 65002, Lo0 = 2.2.2.2/32), directly connected on 192.0.2.0/30.

Tasks:

1. Add static routes so each router can reach the other’s loopback.
2. Configure eBGP peering between the loopbacks with update-source only, and record the result.
3. Add the missing command and verify the session comes up.
4. Replace it with ttl-security hops 1 and explain what happens.
5. State why an iBGP session between loopbacks needs neither command.

! Task 1
R1: ip route 2.2.2.2 255.255.255.255 192.0.2.2
R2: ip route 1.1.1.1 255.255.255.255 192.0.2.1

! Task 2 — incomplete
router bgp 65001
 neighbor 2.2.2.2 remote-as 65002
 neighbor 2.2.2.2 update-source Loopback0

R1# show bgp ipv4 unicast summary
2.2.2.2         4 65002   0   0  1  0  0 00:02:11 Idle

! Task 3
router bgp 65001
 neighbor 2.2.2.2 ebgp-multihop 2
! ... same on R2
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

! Task 4
R1(config-router)# neighbor 2.2.2.2 ttl-security hops 1
! ebgp-multihop is removed automatically — the two are mutually exclusive.
! The session drops: GTSM with hops 1 requires a received TTL of 255,
! but the packet loses one hop reaching the loopback, arriving with 254.
! ttl-security hops 2 would allow it.

Lab 4 — Timers, BFD, and Failure Detection

Topology: the working directly-connected eBGP session, with a switch between R1 and R2 so the physical link stays up when a device fails.

Tasks:

1. With default timers, shut R2’s interface and time how long R1 takes to drop the session.
2. Set timers to 10 30 on both ends and repeat.
3. Configure BFD with a 300 ms interval and multiplier 3, and repeat.
4. Explain why a switch in the middle matters for this test.
5. State the risk of very aggressive BGP timers versus BFD.

! Task 1 — default: up to 180 s (the hold time) before teardown
%BGP-3-NOTIFICATION: sent to neighbor 192.0.2.2 4/0 (hold time expired)

! Task 2
router bgp 65001
 neighbor 192.0.2.2 timers 10 30
! ... same on R2, then clear the session. Detection now ~30 s.

! Task 3
interface GigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3
router bgp 65001
 neighbor 192.0.2.2 fall-over bfd

R1# show bfd neighbors detail
! Detection now under 1 second.

Common Mistakes and Exam Traps

• Active means failing, not working. The single most reliable BGP trap.
• Timers do not need to match. The lower hold time wins; keepalive becomes one third of it.
• NOTIFICATION always closes the session. There are no warnings.
• eBGP defaults to TTL 1. Loopback peering requires ebgp-multihop and update-source.
• iBGP defaults to TTL 255. Multihop is never needed internally.
• ebgp-multihop and ttl-security are opposites and mutually exclusive on one neighbor.
• Missing update-source on loopback peering gives Active on one side, Idle on the other.
• Established does not mean working. Zero prefixes is a filter or a missing network statement.
• Use soft clears. clear bgp * is an outage on a real table.
• received-routes needs soft-reconfiguration inbound, or it silently returns nothing.
• BGP cannot bootstrap its own reachability. An IGP must underlie loopback-based iBGP.

Check Your Understanding

Ten questions on the material in Part 2. Each answer is explained as you go, so a wrong answer is worth as much as a right one.

Time's up

Summary

A BGP session is a manually configured TCP connection on port 179 that walks through Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Five message types carry it: OPEN negotiates, UPDATE carries routes, KEEPALIVE maintains, NOTIFICATION kills, and ROUTE-REFRESH re-requests. AS numbers and authentication must match; timers do not, because the lower hold time is negotiated. eBGP assumes a directly connected peer with TTL 1, which is why loopback peering needs both ebgp-multihop and update-source, while iBGP needs only the latter.

Troubleshooting is a stack walk: is the peer reachable, does TCP open, what does BGP report, and what does the log say. The FSM state at rest tells you which layer to look at first.

The next post covers getting routes into BGP — the network statement, redistribution, the next-hop rules that break iBGP, and the path attributes that feed the best path algorithm.