Hi,

I am a bit confused regarding this. I have seen many (MANY) posts regarding the BGP convergence time with Full Tables taking a long time.

I then see a test by stubarea51 (http://www.stubarea51.net/2015/07/25/mi ... rformance/) which shows the 1072 taking on a full bgp table in 1 minute, 33 seconds and it's concluded that this is as fast as a cisco ASR 1002. That seems rather fast.. what am I missing here?

As mentioned in that same article, RouterOS v6 isn't optimized for multi-core hardware, that is coming in v7.

With a multi-core optimized RouterOS, CCR1072 hardware (72 cores!) will be mostly limited by the speed the peers send the data to it, so instead of taking 1:30 to load the typical 500k table per peer, it will take seconds.

Mikrotik has already done improvements in this area on ROS v6, but when ROS v7 is released, specially on BGP-centric scenarios Multi-Threaded ROS will make CCRs, and specially the CCR1072 (1U, 125W, $3000) bring unprecedented price/rack space/power draw/performance ratios to the scene, making it a killer router.

But 1minutes 33 seconds doesn't seem slow at all, it seems rather normal to me.

ROS v7 is a pie in the sky and most people have been waiting 4/5 years for it, we could still be having this discussion in 4/5 years time.

I think you'll find that many of the complaints about BGP convergence time are frequently related to the speed of the upstream peer (even if that isn't acknowledged as the issue) as the CCR1036 and CCR1072 can take in a single feed very quickly under ideal conditions. If you add a second feed, it slows down a little bit, but it is still a good response time.

We do full table BGP peerings in MIkroTik every day and if you are on a version of RouterOS that is stable for all the features you need, then you shouldn't see any major difference between convergence time in a Cisco router vs. a Mikrotik router.

The whole BGP on a single core issue that's been talked about for years is blown way out of proportion in my opinion. It's important to push for better performance, but the current performance is still pretty good until you get to a large number of full table peers.

The thing about having 1M+ routes in the table has been search time for me, less about convergence and loading. This is where Cisco and other platforms have killed it over Mikrotik for me - if I want to look up the current active route entry for 8.8.8.8 (for example). the search time on a 1036 with only 40k routes is infuriating, let alone if I had 2 full feeds in there.

Having said that, have used 1036's at my core for 2 years now and although having some PSU problems (apparently capacitors are quite shit and swapping to solid state is much better), grunt wise they've not let me down. Had my longest uptime at over 1 year on 6.27 before the PSU failed in it.

Mikrotik BGP has a memory leak...
I have this on my ccr1016 and CHR ...
Then 1-2 peer with full table are reconnect, used memory increased by 300-400mb and Mikrotik doesn't reply on winbox and SSH
only mac-telnet work...
In this case one core is at 100% load and there are random troubles with routing and trafic ...
In normal state memory usage 800-900mb with 2 peers full-view
Then leak - 1300-1400mb with same peers

Mikrotik BGP has a memory leak...
I have this on my ccr1016 and CHR ...
Then 1-2 peer with full table are reconnect, used memory increased by 300-400mb and Mikrotik doesn't reply on winbox and SSH
only mac-telnet work...
In this case one core is at 100% load and there are random troubles with routing and trafic ...
In normal state memory usage 800-900mb with 2 peers full-view
Then leak - 1300-1400mb with same peers

have you logged this with Mikrotik?

The thing about having 1M+ routes in the table has been search time for me, less about convergence and loading. This is where Cisco and other platforms have killed it over Mikrotik for me - if I want to look up the current active route entry for 8.8.8.8 (for example). the search time on a 1036 with only 40k routes is infuriating, let alone if I had 2 full feeds in there.

If you use the search form of

/ip route print where 8.8.8.8 in dst-address

it is very slow.


A workaround is to use something like:

/ip route print where dst-address in 8.8.8.0/24

Obviously this is not as convenient but it does work.

Nick

I had a couple of full bgp tables running and time was about one minute with RouterOS on x86.
It's not very quick, but once peer is established you won't have any issues for months.

The thing about having 1M+ routes in the table has been search time for me, less about convergence and loading. This is where Cisco and other platforms have killed it over Mikrotik for me - if I want to look up the current active route entry for 8.8.8.8 (for example). the search time on a 1036 with only 40k routes is infuriating, let alone if I had 2 full feeds in there.

If you use the search form of

/ip route print where 8.8.8.8 in dst-address

it is very slow.


A workaround is to use something like:

/ip route print where dst-address in 8.8.8.0/24

Obviously this is not as convenient but it does work.

Nick

BUT what if the active route for 8.8.8.8 is 8.8.8.0/23, then your example would miss it. And then if there's multiple routes at different sizes and different local prefs you could potentially get a range of active routes and you'd still have to figure it out.

I need to know what the current active route for 8.8.8.8 is.

But yes I use your example as the work-around when in a hurry.

BUT what if the active route for 8.8.8.8 is 8.8.8.0/23, then your example would miss it. And then if there's multiple routes at different sizes and different local prefs you could potentially get a range of active routes and you'd still have to figure it out.

I need to know what the current active route for 8.8.8.8 is.

But yes I use your example as the work-around when in a hurry.

You can widen your search to say 8.8.0.0/16 which will catch 8.8.8.0/23

BUT what if the active route for 8.8.8.8 is 8.8.8.0/23, then your example would miss it. And then if there's multiple routes at different sizes and different local prefs you could potentially get a range of active routes and you'd still have to figure it out.

I need to know what the current active route for 8.8.8.8 is.

But yes I use your example as the work-around when in a hurry.

You can widen your search to say 8.8.0.0/16 which will catch 8.8.8.0/23

8.8.0.0/16 might have 100 active routes though.

And some of those active routes could overlap, like say you have 8.8.8.0/23 and 8.8.8.0/24, they will both be active routes, you are then stuck reading through the list and self-determining which route is used for 8.8.8.8, which in turn brings human error into the mix and you could make a mistake.

As I said previously - I KNOW how to search as it is now with those limitations, and I do use it, but it is STILL a weak point in the Mikrotik system that needs to be addressed.