Community discussions

MikroTik App
 
jmay
Member
Member
Topic Author
Posts: 326
Joined: Tue Jun 23, 2009 8:26 pm

BGP Hold Time

Thu Aug 27, 2015 10:19 pm

Are there any consequences to increasing the BGP Hold Time? What exactly does this do? I had an issue last night where our fiber connection maxed out and my MT reported "Hold Timer Expired". The router then rebooted itself and after reboot failed to re-establish the BGP session with my provider. It reported TCP Connection Established and then instantly reported Connection Terminated. I shut BGP off and back on and everything connected fine afterwards.

I'm guess my congestion caused my router to not be able to talk to their router for a time. The default Hold time is 180. Is this seconds or minutes? My BGP peer only sends me a default route, not a full route so is there any reason why I should not increase this time? The congestion only lasts an hour or 2 in the evenings and we are working toward having our pipe increased to take care of that.

Thanks.
 
patrick7
Member
Member
Posts: 302
Joined: Sat Jul 20, 2013 2:40 pm

Re: BGP Hold Time

Thu Aug 27, 2015 10:28 pm

BGP sends keepalives every few seconds. If there is no keepalive for a specific time (hold time), the BGP connection will drop and all routes will be removed from the kernel routing table.

The hold time value is in seconds.
 
jmay
Member
Member
Topic Author
Posts: 326
Joined: Tue Jun 23, 2009 8:26 pm

Re: BGP Hold Time

Thu Aug 27, 2015 10:39 pm

Ok, any reason why setting this to say a couple hours could be a problem? Does it need to match up with what my provider is doing or no? Once I get my gig port I can put it back but to sooner.
 
patrick7
Member
Member
Posts: 302
Joined: Sat Jul 20, 2013 2:40 pm

Re: BGP Hold Time

Thu Aug 27, 2015 10:52 pm

The lowest value will be used. If you use 10 hours, and your upstream 30 sec, it will take 30sec.
If you are single-homed, you can increase this value.
If you are multihomed, I would not recommend using high values. If one of the upstreams goes down, it will still use its routes (which are not working) until hold time expires.
 
jmay
Member
Member
Topic Author
Posts: 326
Joined: Tue Jun 23, 2009 8:26 pm

Re: BGP Hold Time

Thu Aug 27, 2015 11:11 pm

Makes sense. We are dual homed but the other fiber is several cities away so we don't really have the backhauls to send everything that direction. Since this is a short term problem do you have any ideas how I can avoid this? Do I need to learn how to prioritize packets at this point?
 
patrick7
Member
Member
Posts: 302
Joined: Sat Jul 20, 2013 2:40 pm

Re: BGP Hold Time

Thu Aug 27, 2015 11:25 pm

I would use a lower hold time even if your bandwidth on the backup link is not enough. Better use working routes with packetloss, than routes which are not working. You can use QoS to priorize important services.
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1312
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: BGP Hold Time

Fri Aug 28, 2015 12:36 am

It is better to implement a queue/QoS for TCP/179 traffic than to turn the timers way up. BGP doesn't require much in the way of bandwidth and you'll have a more consistent peering if you just provide BGP priority queuing.

On the flip side....

The timers that are standard for BGP (60/180) work well when dealing with the full global table as there is a lot of data to sort through with 500,000+ route advetisements.

However, if you need more rapid convergence and are taking in a much smaller routing table or just a default, you might consider tuning them down to 5 second keepalive and 15 second holddown or 10 second keepalive and 30 holddown.

We routinely tune the timers down when the route table is under 20,000 routes and typically don't see any issues.
Global - MikroTik Support & Consulting - English | Español | Serbian | Danish +1 855-645-7684
https://iparchitechs.com/ecosystem/mikr ... consulting mikrotiksupport@iparchitechs.com
 
patrick7
Member
Member
Posts: 302
Joined: Sat Jul 20, 2013 2:40 pm

Re: BGP Hold Time

Fri Aug 28, 2015 12:41 am

Why limiting BGP? It uses some kbit/s. I think he hasn't enough bandwidth to the second upstream to send all traffic towards it.
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1312
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: BGP Hold Time

Fri Aug 28, 2015 12:56 am

Not so much a question of limiting BGP as it is prioritizing BGP updates over all other types of traffic. Most QoS schemes put network management / control plane traffic as the highest class of traffic.
Global - MikroTik Support & Consulting - English | Español | Serbian | Danish +1 855-645-7684
https://iparchitechs.com/ecosystem/mikr ... consulting mikrotiksupport@iparchitechs.com
 
jmay
Member
Member
Topic Author
Posts: 326
Joined: Tue Jun 23, 2009 8:26 pm

Re: BGP Hold Time

Fri Aug 28, 2015 2:02 am

Yah let me clarify. I have 2 fiber connections to my provider. I use BGP at each location but mainly so I can redirect specific towers and IP's on the fly. The one I am having a problem with is a 500 meg connection. The 2nd connection is only 200 megs and is very located several tower hops away and is also nearly maxed out. So sending more traffic to the 2nd location is not a realistic option. The 500 meg connection is about to get upgraded to a gig which will solve the congestion issue. We only recently started hitting 500 megs a few days ago and last night was the only time so far I've had the bgp session just shut down like it did.

Might have been a fluke because the router also crashed at the same time. Here's my logs that I had. I send my logs to the dude, don't see an easy way to export them and I gotta leave the office but here's a screen shot.
You do not have the required permissions to view the files attached to this post.
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1312
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: BGP Hold Time

Fri Aug 28, 2015 2:53 am

Looks like something interrupted your traffic especially since OSPF seems to have torn down a little later as well.

BGP is inherently marked with DSCP 48 (and so is OSPF) in MikroTik, so you can create a mangle rule that matches DSCP 48 and then put it into a queue so BGP always has priority when the links are full.

Here is a little more info on using DSCP in MikroTik

http://wiki.mikrotik.com/wiki/DSCP_based_QoS_with_HTB
Global - MikroTik Support & Consulting - English | Español | Serbian | Danish +1 855-645-7684
https://iparchitechs.com/ecosystem/mikr ... consulting mikrotiksupport@iparchitechs.com
 
nikku
just joined
Posts: 1
Joined: Sat Nov 21, 2020 9:23 pm

Re: BGP Hold Time

Sat Nov 21, 2020 9:50 pm

Hi, I have a similar problem for more than 3 weeks, the connections are up but my ip class doesn't have internet, sometimes it's ok for 2-3 days other times it drops every 5 minutes. I always log with keepalive time expired remote address x.x.x.x (isp gateway)
Everything worked perfectly at 5 years after which it broke, I changed the router and I have the same errors, I upgraded / updated and nothing. Another idea? I mention that I am not a guru of mikrotik, but some ideas for hold timer, keepalive, route filters.

My internal ping to google is like this:
Request timeout for icmp_seq 8716
Request timeout for icmp_seq 8717
Request timeout for icmp_seq 8718
Request timeout for icmp_seq 8719
Request timeout for icmp_seq 8720
Request timeout for icmp_seq 8721
Request timeout for icmp_seq 8722
Request timeout for icmp_seq 8723
Request timeout for icmp_seq 8724
64 bytes from 172.217.19.99: icmp_seq=8725 ttl=116 time=51.638 ms
64 bytes from 172.217.19.99: icmp_seq=8726 ttl=116 time=49.955 ms
Request timeout for icmp_seq 8727
Request timeout for icmp_seq 8728
Request timeout for icmp_seq 8729
64 bytes from 172.217.19.99: icmp_seq=8730 ttl=116 time=49.746 ms
64 bytes from 172.217.19.99: icmp_seq=8731 ttl=116 time=48.378 ms
Request timeout for icmp_seq 8732
Request timeout for icmp_seq 8733
Request timeout for icmp_seq 8734
Request timeout for icmp_seq 8735
Request timeout for icmp_seq 8736
Request timeout for icmp_seq 8737
Request timeout for icmp_seq 8738
64 bytes from 172.217.19.99: icmp_seq=8739 ttl=116 time=53.915 ms
Request timeout for icmp_seq 8740
Request timeout for icmp_seq 8741
Request timeout for icmp_seq 8742
Request timeout for icmp_seq 8743
Request timeout for icmp_seq 8744

Who is online

Users browsing this forum: No registered users and 21 guests