Community discussions

MikroTik App
 
User avatar
bigcw
Member Candidate
Member Candidate
Topic Author
Posts: 112
Joined: Mon Sep 08, 2014 2:38 pm

Slow routing table performance - please share your experiences

Mon Apr 10, 2017 1:28 pm

Hi everyone

Hoping that some of you will share your experiences of big routing tables on Mikrotik and the issues that they cause. I am trying to make a decision as to whether to stick with the MT platform (upgrade a bunch of routers) or find something else.

So for me the two biggest limitations of the platform are the poor BGP performance and the slow routing table updates. I assume the two are interlinked. MT have said that BGP is multithreaded in ROS7 but we still have no actual release date and even when I questioned staff at MUM in London they had no idea either. I think we have to assume that ROS7 is vaporware at the moment.

On the router that is worst affected (a CCR1036) it takes around 10 minutes from typing an /ip route add... command to the route being inserted into the forwarding table. Likewise querying the routing table takes an age - 15 minutes to run a '/ip route print where static=yes' is pretty common. To give an idea, this router has three BGP feeds of the full global routing table, circa 600k v4 routes at present, and another 600k-ish v4 routes learnt from 600 peers. There are also v6 peers on the same router. We don't do anything fancy on the device - no MPLS, VPLS, nothing that needs connection tracking, etc - it is literally just being used as a BGP router.

This makes working with the router very difficult but it is the 'good vs fast vs cheap' trade off that we accept in order to get several gigs of routing ability into 1U, 36 watts and <£1k purchase price.

However we are at a crossroads now in that we desperately need to get more 10G ports onto the network which involves spending significant amounts to replace several 1036's with 1072's. I really want to stick with Mikrotik, but I am scared that it will turn out to be a poor investment and that these issues will never be resolved.

Why am I telling you this? Well I am hoping others with similar setups will share their experiences, particularly of:

1. Has anything improved in the latest ROS versions? (Admittedly that router does run a fairly old version). I checked through the changelogs and nothing is listed.

2. Has anyone gone from a 1036 to a 1072 and seen this problem get better or worse? My fear here is due to the lack of multithreading: the 1036 is clocked at 1.2GHz vs the 1072 which has more cores but clocked at 1GHz. In theory, if the routing engine is single threaded, it will run slower.

3. Has anybody tried implementing Openflow in a real-world environment? As I understand it, this can hand off the BGP and routing table decisions to an x86 box so that the CCR just becomes the packet pushing device

As above, I would very much appreciate any experiences you are prepared to share.

Thanks, Chris
 
User avatar
bigcw
Member Candidate
Member Candidate
Topic Author
Posts: 112
Joined: Mon Sep 08, 2014 2:38 pm

Re: Slow routing table performance - please share your experiences

Sat Apr 22, 2017 1:37 pm

Nobody else seeing issues with this? Surely I can't be the only one....
 
helectro
newbie
Posts: 48
Joined: Mon Jun 28, 2010 1:09 am

Re: Slow routing table performance - please share your experiences

Fri Jul 14, 2017 1:56 pm

Greetings, I imagine it is late, but recently we are installing our first ASN granted, we are reading many post with problems in BGP, and the same as you said that version 7 is the solution but they are tired of waiting
viewtopic.php?f=2&t=122604&p=603074&hil ... v4#p603074
viewtopic.php?f=14&t=119695&p=598633&hi ... v4#p598633
viewtopic.php?f=3&t=89924&p=450557&hilit=bgp+v4#p450557

I think we are going to install the BGP in an old server dell sc1425 with Mkrotik, we only cost $ 100 on ebay, it has more than 5 years running like a rock without any problem, at the moment we have in parallel working CCR1016-12G in our network Only because of the fear that the star server of only $ 100 will get tired of working so hard, but for the post I think we're going to have to keep giving it more work to the server dell sc1425

another other History of X86
viewtopic.php?f=3&t=91237&p=456502&hilit=bgp+v4#p456502

Sorry my bad english
 
itscmo
just joined
Posts: 15
Joined: Thu Jul 27, 2017 7:46 pm

Re: Slow routing table performance - please share your experiences

Fri Aug 11, 2017 12:18 am

On the router that is worst affected (a CCR1036) it takes around 10 minutes from typing an /ip route add... command to the route being inserted into the forwarding table. Likewise querying the routing table takes an age - 15 minutes to run a '/ip route print where static=yes' is pretty common. To give an idea, this router has three BGP feeds of the full global routing table, circa 600k v4 routes at present, and another 600k-ish v4 routes learnt from 600 peers. There are also v6 peers on the same router. We don't do anything fancy on the device - no MPLS, VPLS, nothing that needs connection tracking, etc - it is literally just being used as a BGP router.
We are seeing this issue as well. Apparently the BGP daemon is single-threaded. 1 full table and 1 table with ISP's customer routes works fine in terms of routing decisions, but is literally impossible to sort/troubleshoot.

I heard rumblings somewhere in the past that they were working on making filtering threaded for the next major version but can not seem to find the thread.

We are considering moving to Quagga at the edge so we can get usable performance for filtering. But that adds a hop and adds complexity that would be nice to avoid.
 
infused
Member
Member
Posts: 313
Joined: Fri Dec 28, 2012 2:33 pm

Re: Slow routing table performance - please share your experiences

Fri Aug 11, 2017 1:34 am

There are so many threads on this. It's been touted for v7. So was Ikev2, but since Microsoft Azure makes Ikev2 mandatory, Mikrotik actually introduced it into v6.

You're going to be waiting for v7 for some time.