Skip to content
Log in Sign up My account

1.11.a and 1.11.b BGP Sessions, States and Address Families

Blueprint 1.11: Troubleshoot BGP (Interior and External)

This page covers:

  • 1.11.a Address families (IPv4, IPv6)
  • 1.11.b Neighbor relationship and authentication: operation, states and timers, authentication, update-source and multihop, peer group

Next hop, 4-byte and private AS numbers, route refresh and synchronization (the rest of 1.11.b) are on Next Hop, AS Numbers and Route Exchange.

How a BGP session forms

BGP has no hello-based discovery. Every neighbor is configured by hand with neighbor <ip> remote-as <asn>, and the session runs over a TCP connection to port 179. One side opens the TCP connection (it uses a random source port and destination port 179), the other side accepts it. If both sides try at once, BGP keeps one connection and closes the other (collision detection, decided by the higher router ID).

Once TCP is up, the routers exchange five message types:

Type Message Purpose
1 OPEN Version, own AS, hold time, router ID, capabilities (address families, route refresh, 4-byte AS)
2 UPDATE Advertises prefixes with their path attributes, or withdraws prefixes
3 NOTIFICATION Reports an error and closes the session
4 KEEPALIVE Confirms the peer is alive, sent every keepalive interval when there is no UPDATE to send
5 ROUTE-REFRESH Asks the peer to resend its updates for one address family (soft reset)

Everything about troubleshooting a down session follows from this sequence: if TCP cannot be built, you never get an OPEN; if the OPEN contains something the peer does not accept, it answers with a NOTIFICATION and you see a syslog message that names the error.

The finite state machine

graph LR
  IDLE["Idle"] -->|"start, route to peer"| CONN["Connect"]
  CONN -->|"TCP fails"| ACT["Active"]
  ACT -->|"retry"| CONN
  CONN -->|"TCP up, OPEN sent"| OS["OpenSent"]
  ACT -->|"TCP up, OPEN sent"| OS
  OS -->|"good OPEN received"| OC["OpenConfirm"]
  OC -->|"KEEPALIVE received"| EST["Established"]
  OS -->|"NOTIFICATION"| IDLE
  OC -->|"NOTIFICATION or hold expiry"| IDLE
  EST -->|"error or hold expiry"| IDLE
State What the router is doing What it usually means when a session is stuck there
Idle Not trying to connect. Starting point and the state after any error. No route to the neighbor address, the neighbor is administratively shut (Idle (Admin)), the maximum-prefix limit was exceeded (Idle (PfxCt)), or the router is waiting before retrying after an error
Connect Waiting for its own TCP connection to complete Brief. Rarely seen for long.
Active TCP attempt failed; listening and retrying TCP 179 cannot be completed: the peer has no matching neighbor statement, the source address is wrong (missing update-source), an ACL or CoPP drops TCP 179, TTL expires (eBGP to a loopback without multihop), or MD5 authentication fails
OpenSent OPEN sent, waiting for the peer's OPEN Brief. If it bounces back to Idle or Active, look for a NOTIFICATION in the log.
OpenConfirm Peer's OPEN accepted, waiting for the first KEEPALIVE Brief. Hold time expiring here is unusual and points at one-way loss.
Established UPDATEs exchanged; State/PfxRcd shows a prefix count Session is fine. Missing routes are now a policy, next hop or best-path problem.

Exam trap

Active is not a good state. The name suggests progress, but a neighbor that stays in Active means TCP cannot be completed. A healthy session goes through Active in a fraction of a second, or not at all. If show ip bgp summary shows a state name instead of a number in the last column, the session is down.

Timers

Timer IOS default Notes
Keepalive 60 seconds Sent when no other message has been sent in that interval
Hold time 180 seconds If nothing is received for this long, the session is torn down with a NOTIFICATION (hold timer expired)
ConnectRetry 120 seconds (RFC 4271 value) Wait between TCP connection attempts

The hold time is negotiated in the OPEN: both routers use the lower of the two configured values, and the keepalive interval follows it at one third of the negotiated hold time. Hold time 0 means "never expire", and a non-zero hold time below 3 seconds is invalid. Timer mismatches never stop a session forming, which makes them a favourite wrong answer.

router bgp 65010
 timers bgp 10 30                       ! all neighbors: keepalive 10, hold 30
 neighbor 10.2.4.2 timers 5 15          ! one neighbor, overrides the global value

R2# show ip bgp neighbors 10.2.4.2 | include hold time
  Last read 00:00:03, last write 00:00:04, hold time is 15, keepalive interval is 5 seconds

Hold time is the slow way to detect a dead neighbor that is not directly connected or whose link stays up. For fast detection, use BFD (neighbor 10.2.4.2 fall-over bfd with bfd interval on the interface); see diagram N08.

Why a session will not come up: the checklist

Work from the bottom up. Each row has a command that proves or disproves it.

# Check Proof
1 The neighbor address is reachable from the address you source from ping <neighbor> source <update-source>
2 Both sides point at the address the other side actually uses as its source show ip bgp neighbors <ip> \| include host and compare with the other side's neighbor statement
3 eBGP to a non-adjacent address has TTL headroom show ip bgp neighbors <ip> \| include hops
4 Remote AS numbers match on both sides show logging \| include NOTIFICATION for "peer in wrong AS"
5 Passwords match, or neither side has one show logging \| include BADAUTH
6 TCP 179 is permitted by every ACL in the path, including CoPP show ip access-lists, show policy-map control-plane
7 The neighbor is activated for at least one address family, not shut, not over its prefix limit show ip bgp summary, show bgp all summary

Source address and update-source

A router sources its BGP TCP packets from the outgoing interface toward the neighbor, unless you set neighbor <ip> update-source <interface>. The receiving router accepts the connection only if the source address matches one of its configured neighbors. iBGP between loopbacks is the normal design (the session survives a link failure because the IGP finds another path to the loopback), so update-source Loopback0 is required on iBGP peers.

router bgp 65010
 neighbor 10.255.255.1 remote-as 65010
 neighbor 10.255.255.1 update-source Loopback0

If only one side has update-source, the session can still come up, because the TCP connection that the correctly configured side opens is accepted; the connection the other side opens is refused. That makes the fault intermittent across resets. Configure it on both sides.

TTL: ebgp-multihop, disable-connected-check and ttl-security

IOS sends eBGP packets with an IP TTL of 1 and iBGP packets with a TTL of 255. An eBGP session between loopbacks therefore fails, even when the loopbacks are reachable, because the packet arrives at the peer's loopback after one routed hop has already decremented the TTL. Three tools change this:

Command Effect Use when
neighbor x ebgp-multihop 2 Sends with TTL 2 (or the value given) eBGP to loopbacks, or through a non-BGP device
neighbor x disable-connected-check Skips the check that an eBGP neighbor is on a connected subnet, TTL stays 1 eBGP between loopbacks of two directly connected routers
neighbor x ttl-security hops 1 Sends with TTL 255 and only accepts packets arriving with TTL 254 or higher (GTSM) Protecting eBGP from spoofed packets sent from far away

ttl-security and ebgp-multihop cannot be configured on the same neighbor. Both sides need ttl-security if one side has it, because each side checks the TTL of what it receives.

R2# show ip bgp neighbors 10.255.255.4 | include hops
  External BGP neighbor may be up to 2 hops away.

Exam trap

If the exhibit shows eBGP neighbors configured on loopback addresses, a static route to the peer loopback and update-source, but no ebgp-multihop, the answer is the TTL. If the exhibit is iBGP, multihop is never the answer: iBGP already uses TTL 255.

Remote AS and router ID

A wrong remote-as lets TCP complete, but the receiver sees an OPEN with an unexpected AS and sends a NOTIFICATION with error code 2 subcode 2 (bad peer AS). The log names the problem and shows the AS the peer actually sent, in hex.

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

FDEA in hex is 65002, so the peer really is in AS 65002 and the local remote-as is wrong. The BGP router ID is chosen from bgp router-id, else the highest loopback address, else the highest address on an up interface. Set it explicitly: identical router IDs between peers cause the OPEN to be rejected and are hard to spot.

Authentication

neighbor <ip> password <string> turns on the TCP MD5 signature option (RFC 2385) for that TCP connection. It is enforced by TCP, not BGP, so a mismatch stops the three-way handshake and the neighbor sits in Active. The log tells you which side of the problem you are on:

Log message on the receiver Meaning
%TCP-6-BADAUTH: No MD5 digest from 10.255.255.3(19573) to 10.255.255.1(179) The sender has no password; the receiver expects one
%TCP-6-BADAUTH: Invalid MD5 digest from 10.255.255.3(19573) to 10.255.255.1(179) Both have passwords and they differ (case matters)

Adding or changing a password on an established session does not reset it at once. The session keeps running until it is reset or until the hold timer expires because the peer's segments now fail the check, and then it cannot come back until both sides agree. That delay is why a password change at 10:00 shows up as an outage at 10:03.

Exam trap

An ACL that permits only eq bgp toward the router blocks half of the session. BGP uses port 179 on one side and a random port on the other, and either router may be the one that opened the connection. A correct ACL permits TCP from the neighbor with either source port 179 or destination port 179.

Peer groups and templates

A peer group applies one set of options to many neighbors and, in older IOS, made the router build each update once for the whole group. Modern IOS builds dynamic update groups automatically, so peer groups now mainly save typing and keep neighbors consistent.

router bgp 65010
 neighbor IBGP peer-group
 neighbor IBGP remote-as 65010
 neighbor IBGP update-source Loopback0
 neighbor IBGP password ENARSI-ibgp
 neighbor 10.255.255.2 peer-group IBGP
 neighbor 10.255.255.3 peer-group IBGP
 !
 address-family ipv4
  neighbor IBGP route-reflector-client
  neighbor 10.255.255.2 activate
  neighbor 10.255.255.3 activate

Rules worth knowing:

  • Members inherit every option from the group. An option configured directly on a member overrides the group for inbound settings, but outbound policy must be the same for all members of a peer group.
  • show ip bgp neighbors <ip> shows Member of peer-group IBGP for session parameters. show ip bgp peer-group IBGP shows the group's settings.
  • Peer templates (template peer-session and template peer-policy) are the more flexible alternative: a session template carries session options (remote AS, update source, password, timers), a policy template carries address-family options, and they can inherit from one another. Peer groups are the version you are most likely to see in an exhibit.

Exam trap

When a fault affects several neighbors at once, look at the peer group first. A wrong password or missing update-source on the group breaks every member, and the fix is one line on the group, not one per neighbor.

Address families: IPv4 and IPv6

Multiprotocol BGP (RFC 4760) carries more than IPv4 unicast by negotiating address families (AFI and SAFI) as capabilities in the OPEN. On IOS, router bgp starts with IPv4 unicast enabled for every neighbor you define. Anything else must be activated per neighbor under its address family.

ipv6 unicast-routing
!
router bgp 65010
 bgp router-id 10.255.255.2
 no bgp default ipv4-unicast
 neighbor 2001:db8:2:4::2 remote-as 65001
 !
 address-family ipv6 unicast
  neighbor 2001:db8:2:4::2 activate
  network 2001:db8:2::/48

router bgp 65010
 neighbor 10.2.4.2 remote-as 65001
 !
 address-family ipv6 unicast
  neighbor 10.2.4.2 activate
  neighbor 10.2.4.2 route-map V6-NH out
!
route-map V6-NH permit 10
 set ipv6 next-hop 2001:db8:2:4::1

Without the route-map, the IPv6 next hop is derived from the IPv4 session address (an IPv4-mapped IPv6 address), which the peer cannot route to, so the prefixes arrive but are never best.

Key points:

  • no bgp default ipv4-unicast stops new neighbors being activated for IPv4 automatically. Use it on dual-stack routers so an IPv6 neighbor does not also try to exchange IPv4 routes.
  • A neighbor that is not activated in any address family does not come up. A neighbor that is activated in one family exchanges nothing in the other.
  • IPv6 needs ipv6 unicast-routing and the router ID still has to be a 32-bit value. On an IPv6-only router with no IPv4 address, set bgp router-id by hand or BGP has no router ID.
  • The network statement works the same way in every family: the exact prefix and length must already be in the routing table.
R2# show bgp ipv6 unicast summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:DB8:2:4::2 4        65001      12      11        4    0    0 00:06:14        1

R2# show bgp ipv6 unicast
     Network          Next Hop            Metric LocPrf Weight Path
 *>  2001:DB8:4::/48  2001:DB8:2:4::2          0             0 65001 i

The IPv4-only commands (show ip bgp ...) do not show IPv6 information. Use show bgp ipv6 unicast ..., or show bgp all summary to see every family at once.

Reading the diagnostic output

show ip bgp summary answers "is it up and how many prefixes did it give me". show ip bgp neighbors <ip> answers almost everything else.

R1# show ip bgp neighbors 10.255.255.2
BGP neighbor is 10.255.255.2,  remote AS 65010, internal link
 Member of peer-group IBGP for session parameters
  BGP version 4, remote router ID 10.255.255.2
  BGP state = Established, up for 00:08:41
  Last read 00:00:12, last write 00:00:31, 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
 ...
 For address family: IPv4 Unicast
  Route-Reflector Client
 ...
  Connections established 1; dropped 0
  Last reset never
Local host: 10.255.255.1, Local port: 179
Foreign host: 10.255.255.2, Foreign port: 21345

What to read: the state and uptime, the negotiated hold time, which capabilities and address families both sides agreed, the per-family options (route reflector client, next-hop-self, route-maps), the reset counter and reason, and the local and foreign host addresses (this is where a missing update-source shows up). Here R1 is listening on port 179, so R2 opened the connection.

Useful messages and debugs:

Output Meaning
%BGP-5-ADJCHANGE: neighbor 10.2.4.2 Up Session reached Established
%BGP-5-ADJCHANGE: neighbor 10.2.4.2 Down BGP Notification sent Local router closed it; a NOTIFICATION line follows
%BGP-3-NOTIFICATION: received from neighbor 10.2.4.2 4/0 (hold time expired) The peer stopped hearing from this router
debug ip bgp Session events and OPEN errors
debug ip bgp 10.2.4.2 updates Updates for one neighbor only
debug ip tcp transactions TCP connection attempts when a session is stuck in Active

Lab: build the baseline and fix tickets 1 to 4

Topology: the module topology: five IOSv routers. AS 65010 runs OSPF area 0 between R1, R2 and R3 for loopback reachability. R1 is the route reflector and originates 192.0.2.0/24. R2 peers with ISP-A (R4, AS 65001), which originates 203.0.113.0/24 and 198.51.100.0/24. R3 peers with ISP-B (R5, AS 65002), which originates 203.0.113.0/24. The eBGP links are not in OSPF, so R2 and R3 use next-hop-self toward R1. R2 and R4 also exchange IPv6.

Device Interface IPv4 IPv6
R1 Lo0 / Lo10 10.255.255.1/32 / 192.0.2.1/24
R1 Gi0/0 to R2 / Gi0/1 to R3 10.1.2.1/30 / 10.1.3.1/30
R2 Lo0 10.255.255.2/32
R2 Gi0/0 to R1 / Gi0/1 to R4 10.1.2.2/30 / 10.2.4.1/30 Gi0/1 2001:db8:2:4::1/64
R3 Lo0 10.255.255.3/32
R3 Gi0/0 to R1 / Gi0/1 to R5 10.1.3.2/30 / 10.3.5.1/30
R4 Gi0/0 / Lo100 / Lo101 10.2.4.2/30 / 203.0.113.4/24 / 198.51.100.1/24 Gi0/0 2001:db8:2:4::2/64, Lo102 2001:db8:4::1/48
R5 Gi0/0 / Lo100 10.3.5.2/30 / 203.0.113.5/24

Baseline configuration

R1 baseline 
hostname R1
interface Loopback0
 ip address 10.255.255.1 255.255.255.255
 ip ospf 1 area 0
interface Loopback10
 ip address 192.0.2.1 255.255.255.0
interface GigabitEthernet0/0
 ip address 10.1.2.1 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
interface GigabitEthernet0/1
 ip address 10.1.3.1 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
router ospf 1
 router-id 10.255.255.1
router bgp 65010
 bgp router-id 10.255.255.1
 bgp log-neighbor-changes
 neighbor IBGP peer-group
 neighbor IBGP remote-as 65010
 neighbor IBGP update-source Loopback0
 neighbor IBGP password ENARSI-ibgp
 neighbor 10.255.255.2 peer-group IBGP
 neighbor 10.255.255.3 peer-group IBGP
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor IBGP route-reflector-client
  neighbor 10.255.255.2 activate
  neighbor 10.255.255.3 activate
R2 baseline 
hostname R2
ipv6 unicast-routing
interface Loopback0
 ip address 10.255.255.2 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet0/0
 ip address 10.1.2.2 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
interface GigabitEthernet0/1
 ip address 10.2.4.1 255.255.255.252
 ipv6 address 2001:db8:2:4::1/64
 no shutdown
router ospf 1
 router-id 10.255.255.2
router bgp 65010
 bgp router-id 10.255.255.2
 bgp log-neighbor-changes
 neighbor 10.255.255.1 remote-as 65010
 neighbor 10.255.255.1 update-source Loopback0
 neighbor 10.255.255.1 password ENARSI-ibgp
 neighbor 10.2.4.2 remote-as 65001
 neighbor 2001:db8:2:4::2 remote-as 65001
 address-family ipv4
  neighbor 10.255.255.1 activate
  neighbor 10.255.255.1 next-hop-self
  neighbor 10.2.4.2 activate
  no neighbor 2001:db8:2:4::2 activate
 address-family ipv6 unicast
  neighbor 2001:db8:2:4::2 activate
R3 baseline 
hostname R3
interface Loopback0
 ip address 10.255.255.3 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet0/0
 ip address 10.1.3.2 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
interface GigabitEthernet0/1
 ip address 10.3.5.1 255.255.255.252
 no shutdown
router ospf 1
 router-id 10.255.255.3
router bgp 65010
 bgp router-id 10.255.255.3
 bgp log-neighbor-changes
 neighbor 10.255.255.1 remote-as 65010
 neighbor 10.255.255.1 update-source Loopback0
 neighbor 10.255.255.1 password ENARSI-ibgp
 neighbor 10.3.5.2 remote-as 65002
 address-family ipv4
  neighbor 10.255.255.1 activate
  neighbor 10.255.255.1 next-hop-self
  neighbor 10.3.5.2 activate
R4 baseline (ISP-A) 
hostname R4
ipv6 unicast-routing
interface Loopback100
 ip address 203.0.113.4 255.255.255.0
interface Loopback101
 ip address 198.51.100.1 255.255.255.0
interface Loopback102
 ipv6 address 2001:db8:4::1/48
interface GigabitEthernet0/0
 ip address 10.2.4.2 255.255.255.252
 ipv6 address 2001:db8:2:4::2/64
 no shutdown
router bgp 65001
 bgp router-id 10.255.255.4
 bgp log-neighbor-changes
 neighbor 10.2.4.1 remote-as 65010
 neighbor 2001:db8:2:4::1 remote-as 65010
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  network 203.0.113.0 mask 255.255.255.0
  neighbor 10.2.4.1 activate
  no neighbor 2001:db8:2:4::1 activate
 address-family ipv6 unicast
  network 2001:db8:4::/48
  neighbor 2001:db8:2:4::1 activate
R5 baseline (ISP-B) 
hostname R5
interface Loopback100
 ip address 203.0.113.5 255.255.255.0
interface GigabitEthernet0/0
 ip address 10.3.5.2 255.255.255.252
 no shutdown
router bgp 65002
 bgp router-id 10.255.255.5
 bgp log-neighbor-changes
 neighbor 10.3.5.1 remote-as 65010
 address-family ipv4
  network 203.0.113.0 mask 255.255.255.0
  neighbor 10.3.5.1 activate

Verify the baseline

  1. On every router, show ip bgp summary shows a number (not a state) in the last column for every IPv4 neighbor.
  2. On R2, show bgp ipv6 unicast summary shows 2001:db8:2:4::2 with 1 prefix.
  3. R1 has a best path for all three prefixes, with the reflector clients' loopbacks as next hops:
R1# show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.0.2.0        0.0.0.0                  0         32768 i
 *>i 198.51.100.0     10.255.255.2             0    100      0 65001 i
 * i 203.0.113.0      10.255.255.3             0    100      0 65002 i
 *>i                  10.255.255.2             0    100      0 65001 i

R1 has two equally good iBGP paths to 203.0.113.0/24 and picks the one from the lower router ID (10.255.255.2). You will take that decision apart on the best path page.

  1. ping 203.0.113.4 source 192.0.2.1 from R1 succeeds. Save the baseline on every router: copy running-config flash:baseline.cfg.

Tickets 1 to 4

Apply one fault block at a time, run clear ip bgp * on the routers you changed, wait a minute, then troubleshoot from the symptom only. Restore with configure replace flash:baseline.cfg force before the next ticket.

Fault injection, ticket 1 
! R3
router bgp 65010
 neighbor 10.255.255.1 password Enarsi-ibgp
Fault injection, ticket 2 
! R3
router bgp 65010
 no neighbor 10.3.5.2 remote-as 65002
 neighbor 10.3.5.2 remote-as 65020
 address-family ipv4
  neighbor 10.3.5.2 activate
Fault injection, ticket 3 
! R2
ip access-list extended EDGE-IN
 permit icmp any any
 deny   ip any any
interface GigabitEthernet0/1
 ip access-group EDGE-IN in
Fault injection, ticket 4 
! R4
router bgp 65001
 address-family ipv6 unicast
  no network 2001:db8:4::/48
  network 2001:db8:4::/64

Tickets

Ticket 1: "Branch users behind R3 can no longer reach head office or ISP-A destinations. The ISP-B session on R3 is up." Ticket 2: "ISP-B says our session to them has been down since a change last night. Their side is unchanged." Ticket 3: "R2 can ping ISP-A's router, but the ISP-A BGP session is down." Ticket 4: "The IPv6 BGP session to ISP-A is up but we receive no IPv6 prefixes."

Ticket 1: root cause and fix

show ip bgp summary on R1 shows 10.255.255.3 in Active. Loopback pings work, so reachability is fine. The log on R1 shows %TCP-6-BADAUTH: Invalid MD5 digest from 10.255.255.3(...) to 10.255.255.1(179). "Invalid" means both sides have a password and they differ: R3 now has Enarsi-ibgp with a capital E. Fix on R3: neighbor 10.255.255.1 password ENARSI-ibgp. Do not change the peer group on R1, because R2 uses the same password.

Ticket 2: root cause and fix

R3's summary shows 10.3.5.2 cycling through Idle and Active, and the log shows %BGP-3-NOTIFICATION: sent to neighbor 10.3.5.2 2/2 (peer in wrong AS) 2 bytes FDEA. FDEA is 65002, the AS R5 is really in. R3 expects 65020. Fix on R3: neighbor 10.3.5.2 remote-as 65002 (IOS replaces the remote AS in place). The TCP connection was fine all along, which is why a wrong AS shows a NOTIFICATION while a wrong password does not.

Ticket 3: root cause and fix

The session is in Active. show ip access-lists EDGE-IN shows matches only on the ICMP line and the deny. TCP 179 from R4 is dropped inbound, so neither router can complete the handshake. Fix by permitting BGP in both port directions above the deny:

ip access-list extended EDGE-IN
 5 permit tcp host 10.2.4.2 host 10.2.4.1 eq bgp
 6 permit tcp host 10.2.4.2 eq bgp host 10.2.4.1

Then check show ip bgp summary again. If the ticket allows, removing the ACL also works, but a security ACL is usually there for a reason.

Ticket 4: root cause and fix

show bgp ipv6 unicast summary on R2 shows the neighbor up with 0 prefixes. On R4, show bgp ipv6 unicast has no local entry, because the network statement asks for 2001:db8:4::/64 and the routing table holds 2001:db8:4::/48 (show ipv6 route 2001:db8:4::/64 returns nothing). The network command needs an exact match. Fix on R4: no network 2001:db8:4::/64 and network 2001:db8:4::/48 under the IPv6 address family.

Quick check

A neighbor shows Idle (Admin) in show ip bgp summary. What is the fix?

Someone configured neighbor <ip> shutdown. Remove it with no neighbor <ip> shutdown. Nothing is wrong with reachability or parameters.

R1 is configured with timers bgp 20 60 and its neighbor uses the defaults. What hold time does the session use?

60 seconds. The lower hold time from the two OPEN messages wins, and both routers use it. The session forms normally.

An eBGP session between two directly connected routers' loopbacks fails. Name two single-command fixes, apart from configuration on the IGP side.

neighbor x ebgp-multihop 2 on both routers, or neighbor x disable-connected-check on both routers. Either way, both sides also need update-source Loopback0 and a route to the peer's loopback.

References

  • RFC 4271 (BGP-4), RFC 4760 (multiprotocol extensions), RFC 2385 (TCP MD5 signature option) and RFC 5082 (GTSM, used by ttl-security), at rfc-editor.org
  • IP Routing: BGP Configuration Guide, Cisco IOS XE (search on cisco.com for "BGP configuration guide IOS XE")
  • Cisco IOS IP Routing: BGP Command Reference (search on cisco.com)
  • Troubleshoot BGP neighbor states, Cisco TAC tech note (search on cisco.com for "BGP neighbor Active state")
  • Cisco Live On-Demand Library: search "BGP troubleshooting"