BGP hold down and keepalive timers.

Unanswered Question
Jun 27th, 2002
User Badges:
  • Bronze, 100 points or more

Does Cisco recommend tweaking the BGP keepalive and holddown timers? If so are there any values that are preferred?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Anonymous (not verified) Thu, 06/27/2002 - 09:29
User Badges:

If you need to adjust the holddown timer to make a session stable, you are probably just masking an underlying network problem. You shouldn't need to adjust these during normal operation. Instead, the defaults should work well.


Zubair.Sayed_2 Sat, 12/11/2010 - 07:55
User Badges:

Ofcourse if you using a full Cisco environment then I agree there is no use to change timers.


However, take my case for instance. We connecting to a service provider that uses Juniper. The default hold down timer for Juniper is 90 seconds.


Cisco default hold down is 180 seconds + 3 x keepalive (60 seconds).


We keep getting BGP neighbor change issues and losing connectivity. In this we will be changing our timers to match the SP of 90 seconds.

Lei Tian Sat, 12/11/2010 - 14:11
User Badges:
  • Cisco Employee,

I thought bgp will negotiate the hold timer, and use the lower timer by default. Maybe not ture for Juniper box. Anyway, 30 90 should be fine.


HTH,

Lei Tian

Mahesh Gohil Sat, 12/11/2010 - 19:54
User Badges:
  • Silver, 250 points or more

Hello,


A lowest one will be negotiated so if you set something other than default which is lower than 60/180 than

the value you set will be negotiated.


Now what timer to keep is basically depend upon many things


> If you have primary/secondary setup and you want traffic to shift to backup immediately incase of primary fails you can configure 1/3 (kepalive/hold) ..this is the lowest one supported. But there is one disadvantage (If primary link is flapping than traffic will have some adverse effect..).


so as per cisco the prefered value for hold down is not below 20 second. But for that much time (20 sec) your traffic will be black-holed.


so what to keep now. well bgp is not meant to respond faster ..If you have voice traffic you will never prefer any timers in second (need something that

trigger in mill-second)..you can think of bfd (bidirectional forwarding detection for faster response)


hope this is useful to you


Regards

Mahesh

Zubair.Sayed_2 Sun, 12/12/2010 - 00:15
User Badges:

Thanks for comments guys.


I understand that a 30second gap should not cause any issues. please try and help me explain the below, we have experienced 2 outages so far on 2 seperate WAN routers, and the log states hold time expired.


Router 1 (I removed ip information)


000350: Dec 10 06:54:09.832 UTC: %TRACKING-5-STATE: 21 ip route x.x.x.0/20 reachability Up->Down
000351: Dec 10 06:54:09.832 UTC: %TRACKING-5-STATE: 22 ip route x.x.x.0/21 reachability Up->Down
000352: Dec 10 06:54:10.544 UTC: %TRACKING-5-STATE: 20 list boolean or Up->Down
000353: Dec 10 06:54:10.648 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2137 Grp 1 state Active -> Speak
000354: Dec 10 06:54:19.340 UTC: %BGP-5-ADJCHANGE: neighbor x.x.0.xDown BGP Notification sent
000355: Dec 10 06:54:19.340 UTC: %BGP-3-NOTIFICATION: sent to neighbor x.x.0.x4/0 (hold time expired) 0 bytes
000356: Dec 10 06:54:19.340 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.0.x IPv4 Unicast topology base removed from session  BGP Notification sent
000357: Dec 10 06:54:21.784 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2137 Grp 1 state Speak -> Standby
000358: Dec 10 06:54:24.832 UTC: %TRACKING-5-STATE: 11 ip route x.0.0.0/11 reachability Up->Down
000359: Dec 10 06:54:24.832 UTC: %TRACKING-5-STATE: 12 ip route x.x.0.0/11 reachability Up->Down
000360: Dec 10 06:54:24.832 UTC: %TRACKING-5-STATE: 13 ip route x.x.0.0/11 reachability Up->Down
000361: Dec 10 06:54:25.544 UTC: %TRACKING-5-STATE: 10 list boolean or Up->Down
000362: Dec 10 06:54:27.080 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2136 Grp 1 state Active -> Speak
000363: Dec 10 06:54:38.484 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2136 Grp 1 state Speak -> Standby
000364: Dec 10 06:56:44.743 UTC: %BGP-5-ADJCHANGE: neighbor x.97.0.xUp
000365: Dec 10 06:56:48.155 UTC: %BGP-5-ADJCHANGE: neighbor x.97.0.xvpn vrf gsoa Up
000366: Dec 10 06:56:54.935 UTC: %TRACKING-5-STATE: 11 ip route x.0.0.0/11 reachability Down->Up
000367: Dec 10 06:56:54.935 UTC: %TRACKING-5-STATE: 12 ip route x.x.0.0/11 reachability Down->Up
000368: Dec 10 06:56:54.935 UTC: %TRACKING-5-STATE: 13 ip route x.x.0.0/11 reachability Down->Up
000369: Dec 10 06:56:54.935 UTC: %TRACKING-5-STATE: 21 ip route x.x.x.0/20 reachability Down->Up
000370: Dec 10 06:56:54.935 UTC: %TRACKING-5-STATE: 22 ip route x.x.x.0/21 reachability Down->Up
000371: Dec 10 06:56:55.683 UTC: %TRACKING-5-STATE: 10 list boolean or Down->Up
000372: Dec 10 06:56:55.683 UTC: %TRACKING-5-STATE: 20 list boolean or Down->Up
000373: Dec 10 06:56:57.079 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2136 Grp 1 state Standby -> Active
000374: Dec 10 06:56:57.331 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1.2137 Grp 1 state Standby -> Active
000375: Dec 10 07:09:30.719 UTC: %BGP-5-ADJCHANGE: neighbor x.x.0.xDown BGP Notification sent
000376: Dec 10 07:09:30.719 UTC: %BGP-3-NOTIFICATION: sent to neighbor x.x.0.x4/0 (hold time expired) 0 bytes
000377: Dec 10 07:09:30.719 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.0.xIPv4 Unicast topology base removed from session  BGP Notification sent
000378: Dec 10 07:09:32.767 UTC: %BGP-5-ADJCHANGE: neighbor x.x.0.xvpn vrf gsoa Down BGP Notification sent
000379: Dec 10 07:09:32.767 UTC: %BGP-3-NOTIFICATION: sent to neighbor x.x.0.x4/0 (hold time expired) 0 bytes


Router 2 (I removed ip information)


000047: *Nov 28 04:21:48.480 UTC: %BGP-5-ADJCHANGE: neighbor x.x.x.xDown BGP Notification sent
000048: *Nov 28 04:21:48.480 UTC: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x4/0 (hold time expired) 0 bytes
000049: *Nov 28 04:21:48.480 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.xIPv4 Unicast topology base removed from session  BGP Notification sent
000050: *Nov 28 04:55:17.456 UTC: %BGP-5-ADJCHANGE: neighbor x.x.x.xUp


Any help would be appreciated or else I plan to raise a change and amend the hold down timers to 90seconds.


Thanks

ZS

lgijssel Sun, 12/12/2010 - 02:04
User Badges:
  • Red, 2250 points or more

From the log I get the impression there is more going on than just a sub-optimal timer.

Where do you think the hsrp-state-changes come from and what causes the tracking messages?

It looks to me as if all those messages have a common cause, track it down and your problem is likely resolved without timer adjustments.


regards,

Leo

.

Zubair.Sayed_2 Sun, 12/12/2010 - 23:56
User Badges:

Hey Leo.


Thanks alot for the reply.


Do you suggest we check the tracking objects and HSRP settings on both routers?


Where would be the best place to start?


Cheers

ZS

Actions

This Discussion