04-26-2013 09:23 PM - edited 03-04-2019 07:44 PM
Hi,
We have a non-cisco device peering with Cisco 6500 for bgp. The routing table is fully populated and connection is good.
But after some time we see bgp hold timer error on the non-cisco device. This device by default has a hold timer of 90 seconds which is different from default cisco hold timer.
Will this cause any disruptions to the network? If we change the hold timer on one device to match on both sides, will it reset the bgp session?
appreciate all inputs.
04-26-2013 10:19 PM
Hello,
Once you have defined two routers to be BGP neighbors, they will form a BGP connection and exchange routing information. If you subsequently change a BGP filter, weight, distance, version, or timer, or make a similar configuration change, you must reset BGP connections for the configuration change to take effect.
A soft reset updates the routing table for inbound and outbound routing updates. Cisco IOS software Release 12.1 and later releases support soft reset without any prior configuration. This soft reset allows the dynamic exchange of route refresh requests and routing information between BGP routers, and the subsequent re-advertisement of the respective outbound routing table. There are two types of soft reset:
•When soft reset is used to generate inbound updates from a neighbor, it is called dynamic inbound soft reset.
•When soft reset is used to send a new set of updates to a neighbor, it is called outbound soft reset.
To use soft reset without preconfiguration, both BGP peers must support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. Routers running Cisco IOS software releases prior to Release 12.1 do not support the route refresh capability and must clear the BGP session using the neighbor soft-reconfiguration router configuration command, described in "Configuring BGP Soft Reset Using Stored Routing Policy Information." Clearing the BGP session in this way will have a negative impact upon network operations and should only be used as a last resort.
Please see: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbgp.html
Hope this helps
Sent from Cisco Technical Support iPhone App
04-27-2013 09:23 AM
will changing the bgp hold timer on either of the device help in resolving the errors away?
04-27-2013 09:38 AM
Yes it would help if hold timers and keepalive timers were the same.
Which vendor is it and what is the message it comes up with?
By default (cisco), keepalive timer is 60 seconds and hold-down timer is 3xkeepalive or 180seconds. Once the peering between two peers is UP, router starts a hold-down timer counting from 0 second up. Every keepalive message it reachieved from the neighbor peer resets this timer back to 0 seconds. As you might imagine, failing to receive three keepalives in a row will make the hold-down timer reach 180 seconds what will mean the neighbor is considered down and routes from this neighbor are flushed. If timers were not the same, there is a chance this could happen.
So it would only be of benefit to you if timers were the same to be safe.
Defaults:
keepalive: 60 seconds
hold-down: 180
Hope this helps
Please rate useful posts and remember to mark any solved questions as answered. Thank you.
04-27-2013 09:46 AM
The hold timer is actually negotiated between the two peers and the lower of the two is used by both side. No need to adjust the timer on your side.The 90 second value advertized by your peer will be used. That does not cause any issue.
Hope this helps
04-27-2013 10:04 AM
Hello Harold, this is true, but why would the device be throwing up errors about hold-timers? In which case I would hard set both sides to be the same...?
Unless its some sort of bug with the other vendor?
Please rate useful posts and remember to mark any solved questions as answered. Thank you.
04-27-2013 01:22 PM
Hi Bilal,
What error messages are we talking about? There is no need to change the default value, except if the detection time needs to be reduced and other means such as BFD are not available.
At least one vendor I know of uses 90 seconds as their default value and they generally interoperate nicely with Cisco.
Regards
04-27-2013 01:57 PM
Hello Harold, I already know this, all I was suggesting was hard coding the timers in the config, makes no harm right??
As mentioned in the initial post (please kindly read in context)
'But after some time we see bgp hold timer error on the non-cisco device.'
This is the error that I was talking about which I requested for more info on this...
Sent from Cisco Technical Support iPhone App
04-27-2013 02:24 PM
Hi Bilal,
I doubt that this hold timer error anything to do with the fact that the two devices are using a different default values. I have seen such errors being trigerred by MTU issues in the past. Changing the hold timer on the either side will unfortunately not help.
Regards
04-27-2013 04:45 PM
Sure, I understand, thanks.
So are we saying that we should check MTU? I haven't seen this before... wouldn't the peering be flapping?
Unless there is pmtu discovery enabled on both sides? In which case they would be negotiated anyway?
Sent from Cisco Technical Support iPhone App
04-27-2013 05:52 PM
MTU issue is one potential issue. The best way to start would be to have the log messages from both peer bgp hold timer error are being seen.
The MTU issues that I was referring to where actually code related and the 6500 was involved.
A "show ver" from teh 6500 would also be helpful.
Regards
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide