BGP Updates

Unanswered Question
Feb 4th, 2008


I noticed the following logs in a test environment at a cisco academy:

MAC#sh log | i Feb 4

Feb 4 12:04:34.858 UTC: %BGP-5-ADJCHANGE: neighbor Down BGP Notification sent

Feb 4 12:04:34.858 UTC: %BGP-3-NOTIFICATION: sent to neighbor 4/0 (hold time expired) 0 bytes

Feb 4 12:04:43.858 UTC: %BGP-5-ADJCHANGE: neighbor Down BGP Notification sent

Feb 4 12:04:43.858 UTC: %BGP-3-NOTIFICATION: sent to neighbor 4/0 (hold time expired) 0 bytes

Feb 4 12:07:29.043 UTC: %BGP-5-ADJCHANGE: neighbor Up

Feb 4 12:08:04.111 UTC: %BGP-5-ADJCHANGE: neighbor Up

This resulted in the connection being down for 3 minutes...

I'm new to BGP..

Is this normal? Was there a problem here? Can anyone explain what exactly went on?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.2 (4 ratings)
Richard Burts Mon, 02/04/2008 - 07:48


The link sent by Dandy seems to be a very interesting presentation and you should find good information in it. The answer from Dandy implies response to the questions that you ask. I thought it might be helpful to provide explicit answers: No this is not normal, and yes it would appear that there was a problem.

Without more information it is hard to be sure of what the problem was, but here is what I believe we can say based on what you have posted so far.

- there are 2 BGP neighbor routers. One is at and the other is at

- your router stopped receiving keepalive messages from both of these neighbors. We do not have enough information at this point to know why the keepalives stopped but common reasons are that an interface went down somewhere in the data path to these neighbors, or there might have been a routing issue and the routes to these neighbors (or their routes to you) were withdrawn from some routing table somewhere in the data path to these neighbors, or there might have a temporary change in an access list that denied the BGP traffic.

- when the hold interval expired with no keepalive received your router terminated the neighbor relationship and sent a notification message to each neighbor that it was terminating the neighbor relationship.

- part of terminating the neighbor relationship is to tear down the TCP based session to the neighbors.

- your router continues to try to initiate a TCP based BGP session. and a few minutes later it was successful and the BGP neighbor relationship was restored.



danny9797 Tue, 02/05/2008 - 13:12

Thanks a lot for both replies...I will investgiate further. Has anyone ever witnessed these errors as well and what they mean:

Feb 5 20:39:04.359 UTC: %SYS-2-LINKED: Bad enqueue of 83B829FC in queue 833E066C

I saw about 15 of these messages in the same minute with different enqueue values but the "in queue - 833E066C" values were the same, and the BGP flapped 20 seconds later..

Rick Morris Tue, 02/05/2008 - 13:25

Another area to check is to see your bgp settings

sh ip bgp neigh

ir1.7206#sh ip bgp neigh

BGP neighbor is, remote AS 7132, external link

Description: PEER: SBC

BGP version 4, remote router ID

BGP state = Established, up for 38w5d

Last read 00:00:28, hold time is 180, keepalive interval is 60 seconds

Neighbor capabilities:

Route refresh: advertised and received(old & new)

Address family IPv4 Unicast: advertised and received

Message statistics:

InQ depth is 0

OutQ depth is 0

Sent Rcvd

Opens: 3 3

Notifications: 0 0

Updates: 5 17959648

Keepalives: 446925 446912

Route Refresh: 0 0

Total: 446933 18406563

Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast

BGP table version 63398060, neighbor version 63398053

Index 1, Offset 0, Mask 0x2

Inbound soft reconfiguration allowed

Outbound path policy configured

Route map for outgoing advertisements is SBC-OUT

Sent Rcvd

Prefix activity: ---- ----

Prefixes Current: 2 240320 (Consumes 11535360 bytes)

Prefixes Total: 3 40493122

Implicit Withdraw: 0 36092174

Explicit Withdraw: 1 4160628

Used as bestpath: n/a 109544

Used as multipath: n/a 0

Outbound Inbound

Local Policy Denied Prefixes: -------- -------

route-map: 27237793 0

Suppressed duplicate: 0 15187941

AS_PATH loop: n/a 702

Bestpath from this peer: 11477038 n/a

Total: 38714831 15188643

Number of NLRIs in the update sent: max 2, min 0

Connections established 3; dropped 2

Last reset 38w5d, due to User reset

External BGP neighbor may be up to 2 hops away.

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host:, Local port: 11006

Foreign host:, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x63E5009E4):

Timer Starts Wakeups Next

Retrans 404609 14264 0x0

TimeWait 0 0 0x0

AckHold 2460496 1075431 0x0

SendWnd 0 0 0x0

KeepAlive 0 0 0x0

GiveUp 0 0 0x0

PmtuAger 0 0 0x0

DeadWait 0 0 0x0

iss: 1863448300 snduna: 1870864979 sndnxt: 1870864979 sndwnd: 16289

irs: 2657902246 rcvnxt: 3575441112 rcvwnd: 16027 delrcvwnd: 357

SRTT: 300 ms, RTTO: 304 ms, RTV: 4 ms, KRTT: 0 ms

minRTT: 0 ms, maxRTT: 832 ms, ACK hold: 200 ms

Flags: higher precedence, nagle, md5

Datagrams (max data segment is 516 bytes):

Rcvd: 2967774 (out of order: 267), with data: 2578989, total data bytes: 9175388


Sent: 2897433 (retransmit: 14264, fastretransmit: 0), with data: 390346, total d

ata bytes: 7416678

This is useful as well to see if you are established in your session. You can check the keepalives received and sent.

tomy.nurhadi Fri, 07/04/2008 - 22:20

Hi Dan,

I am having the same problem as yours. Only the BGP is between CE and PE and keeps flapping in 90 seconds interval. Have you figured out the solution?

Many Thanks,


wilson_1234_2 Sat, 07/05/2008 - 18:05

Have you done a "sh process cpu" on the CE router to make sure nothing is going on that would utilize all the resources on the router?

tomy.nurhadi Sat, 07/05/2008 - 23:29

Hi Wilson,

The problem is solved. It's a hardware faulty. We change the WIC to another slot and the BGP is working fine now. Hard to believe that hardware faulty can prevent ONLY BGP keepalive from being sent while other packets flow freely.




This Discussion