Community discussions

MikroTik App
 
User avatar
andrewe02000
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 69
Joined: Tue Aug 28, 2012 6:33 am
Location: Canton, OH
Contact:

Question: Multi-thread BGP

Tue Apr 14, 2020 4:44 pm

I am curious if your implementation of bgp will be one core per bgp session or if it will truly be multi-threaded with one bgp session using multiple cores.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Question: Multi-thread BGP

Tue Apr 14, 2020 6:07 pm

All I can say is tht it will not be multithreaded. AFAIK none of currently existing implementations are fully multithreaded.
 
TUNG0407
newbie
Posts: 48
Joined: Tue Nov 03, 2009 7:04 am

Re: Question: Multi-thread BGP

Tue Apr 14, 2020 7:09 pm

So what is the BGP improvement on v7.0?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Question: Multi-thread BGP

Wed Apr 15, 2020 8:44 am

Load distribution between cores can be done without multithreading.
https://www.youtube.com/watch?v=NbfKplzda7I
 
User avatar
andrewe02000
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 69
Joined: Tue Aug 28, 2012 6:33 am
Location: Canton, OH
Contact:

Re: Question: Multi-thread BGP

Wed Apr 15, 2020 9:48 pm

Load distribution between cores can be done without multithreading.
https://www.youtube.com/watch?v=NbfKplzda7I
Yes, I have seen that video. It appeared to me that it was one core per session which will help but with the growing routing tables sizes I think it would be a game changer to have multi-threaded BGP because of improved convergence time. My CCR1036-12G-4S with one session to another provider using a Juniper MX80 takes about 3 minutes to converge 808,000 routes. When I was lucky enough watch his routers converge down in our local IX the convergence times were happening in under 15 seconds. I know that I'm not spending Juniper money on my CloudCore here but I think it would definitely give Mikrotik a very competitive advantage to have this functionality. I understand that your development for BGP is completely in-house and with this pandemic going on a lot of things have been delayed. To what extent I am not sure. I am more curious if you think that it is possible based on other research I have posted below to have this functionality in the future if not in ROS7 then later in the development cycle. I am hoping that just having 1 cpu per session will at least enable me to share full BGP tables between my core routers so I can blend all my connections fully without routers locking up as that is what happened in the past when trying this. I know there are x86 options to get around the CloudCore limitations I would just prefer to use the full power available in the CloudCore platfor if possible. Thank you for taking the time to look at this and take community feedback.

https://www.semanticscholar.org/paper/A ... 27f0d22f69
https://www.researchgate.net/publicatio ... ion_Router
https://www.quora.com/What-is-multi-thread-BGP-access
 
User avatar
kosyot
newbie
Posts: 36
Joined: Wed Jan 16, 2019 1:28 pm
Contact:

Re: Question: Multi-thread BGP

Mon May 11, 2020 11:30 am

What about if you have more than two or tree full table BGP peers ?

For example :
> ip route print count-only
5127833

> ipv6 route print count-only
338525

Quagga based linux server can manage route changes real time without any problem. CCR1036-8G-2S+ needs 1/2 hour to process changes at just one peer...

Whole BGP processing must be multi-tread with no doubt.

p.s. not talking about something elementary as to get basic routing info needed on daily base:
>ip route print detail where 8.8.8.8 in dst-address
answer about a hour....
 
User avatar
paoloaga
Member Candidate
Member Candidate
Posts: 227
Joined: Tue Mar 08, 2011 2:52 am
Location: Lugano - Switzerland
Contact:

Re: Question: Multi-thread BGP

Tue May 12, 2020 2:00 am

The time needed to download the routing table is quite fast already. The huge problem is that it takes 20 minutes or so to install the routes (and make them active). It seems that the process that executes this task is always only one.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Question: Multi-thread BGP

Tue May 12, 2020 3:00 am

It might be possible in v7 right now to use /routing/fantasy to load up a routing table with enough fictitious routes to simulate multiple full BGP tables and then check to see how long it takes to perform operations on those routes. At least I suspect that is what /routing/fantasy is meant for - a fake dynamic routing protocol designed to load randomized routes into the routing table to facilitate load and performance testing.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Question: Multi-thread BGP

Tue May 12, 2020 3:44 am

Yup, I figured out routing fantasy - that's exactly what it does.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Question: Multi-thread BGP

Tue May 12, 2020 5:11 am

I don't fully understand the syntax, but:

/routing fantasy
add comment=test count=1000 dealer-id=1000 dst-address=12.0.0.0/8 gateway=192.168.88.1 instance-id=1 name=fantasy-test prefix-length=32 \
priv-offs=1000 priv-size=100 seed=mducharme use-hold=no

creates 1000 random /32 routes within 12.0.0.0/8 all of which have gateway 192.168.88.1
 
t4thfavor
just joined
Posts: 18
Joined: Tue Apr 13, 2021 4:40 pm

Re: Question: Multi-thread BGP

Thu Jan 12, 2023 5:50 pm

Here is exactly how Juniper does it. It's definitely parallel execution of BGP route processing. I have "no dog in this fight" but as a developer I always lean towards "nothing is impossible".

https://www.juniper.net/documentation/e ... arding.pdf

I know it's not a simple checkbox and magic happens and there's multi-threadded BGP, but someone has figured out the logistics and thread control algorithm (Juniper), and I presume it's not novel enough to be patented, so it's possible to just implement the same type of algorithm on the Mikrotik hardware (given enough time, interest, and investment).

I read the "Run to completion" argument, and it's not really something that applies because you ARE running to completion, you are just running it on several cpu's at the same time and the main "thread" will wait for this to complete. Does it matter if route 887,123 gets processed before route 123? I don't know, but it seems Juniper has figured out how to deal with it, so it's not "impossible"

Who is online

Users browsing this forum: No registered users and 22 guests