Community discussions

 
AlexS
Member Candidate
Member Candidate
Topic Author
Posts: 259
Joined: Thu Oct 10, 2013 7:21 am

BGP Converge time

Thu May 04, 2017 4:11 am

Hi

Say I have 4 x ccr1036 router A, B, C, D.

Each router has a ISP BGP connection and each routers has a connection to VLAN Internet.

eBGP to ISP and iBGP over Internet.

On the internet vlan I have a fw it routers via DGW. the DGW is handled by the routers using a VRRP on the Internet vlan.

lets say C has the VRRP now.

lets say my example prefix i'm looking at i 8.8.8.0/24 and it routes via router A.

If I disable the BGP peer on router A. My advertised prefixes are removed from router A, ISP route table and slowly inbound filters down.

But the ASA -> VRRP via router C, which sends it to router A, router A no longer has the route and sends it to router B,C,D which in turns sends it back to router A.

So the loop begins.

It seems to take 3 min to get tge BGP to converge between router A and B,C,D.

Is there some way to make this quicker ?
 
AlexS
Member Candidate
Member Candidate
Topic Author
Posts: 259
Joined: Thu Oct 10, 2013 7:21 am

Re: BGP Converge time

Thu May 04, 2017 4:23 am

To add to that, currently we take full BGP feeds on all ISP connections.

It's been suggested that if we take a smaller feed, convergence will be much smaller.
 
savage
Forum Guru
Forum Guru
Posts: 1213
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: BGP Converge time

Thu May 04, 2017 9:15 am

Mikrotik's BGP is single threaded and runs only on one CPU core. It is extremely slow - especially with things like updates/withdraws. You're not the only one with issues like this, trust me.

If convergence time is a concern, I'd suggest you look at other routers TBH.
Regards,
Chris
 
faisali
Member Candidate
Member Candidate
Posts: 179
Joined: Fri Oct 08, 2010 5:11 am

Re: BGP Converge time

Wed May 17, 2017 6:22 pm

BGP Convergence time, is an issue on the CCR but not on the X-86 or CHR platforms.
 
AlexS
Member Candidate
Member Candidate
Topic Author
Posts: 259
Joined: Thu Oct 10, 2013 7:21 am

Re: BGP Converge time

Thu May 18, 2017 1:42 am

Is that a function of different code base or because the VM's have higher frequency ?

I am guessing its still single core, but you get a better performing cpu in the VM

I got my convergence time down to ~ 1sec, by cutting my prefixes down to < 3k... around 30K is goes back to about 2-3 minutes.
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1053
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: BGP Converge time

Thu May 18, 2017 4:03 pm

It's typically due to better clock speeds on a single core for a VM since the process is still confined to a single core. The Tilera family of processors is optimized to move packets. BGP has a heavy computational load with large route tables and so Intel x86 chipsets are able the chew through the data much faster.
Global - MikroTik Support & Consulting - English | Francais | Español | Portuguese +1 855-645-7684
https://iparchitechs.com/services/mikro ... l-support/ mikrotiksupport@iparchitechs.com
 
savage
Forum Guru
Forum Guru
Posts: 1213
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: BGP Converge time

Thu May 18, 2017 4:14 pm

It's typically due to better clock speeds on a single core for a VM since the process is still confined to a single core. The Tilera family of processors is optimized to move packets. BGP has a heavy computational load with large route tables and so Intel x86 chipsets are able the chew through the data much faster.
Truly a sad predicament that MT then leaves us in... Considering that 1) CCR is marketed as the "flagship" product, the holy grail, the mother of all routers - apparently, and 2) that MT is slowly but surely caning x86 support in preference for CHR (which would now include ADDITIONAL costs, as ESXi and a lot of virtual platforms needs to be licensed as well). Given the lack of VMWare-tools and other requirements on the CHR platform, that too, is not really a usable / production ready product (MT can't even be bothered to make a proper installation system).

So, MT... What *exactly* are we supposed to be using then? And PLEASE don't say to wait for the "non-existent" release of v7. Even IF v7 is released tomorrow, it will take at least a year before it is production ready in terms of bugs and stability.
Regards,
Chris
 
paulct
Member Candidate
Member Candidate
Posts: 298
Joined: Fri Jul 12, 2013 5:38 pm

Re: BGP Converge time

Thu May 18, 2017 7:05 pm

It's typically due to better clock speeds on a single core for a VM since the process is still confined to a single core. The Tilera family of processors is optimized to move packets. BGP has a heavy computational load with large route tables and so Intel x86 chipsets are able the chew through the data much faster.
Truly a sad predicament that MT then leaves us in... Considering that 1) CCR is marketed as the "flagship" product, the holy grail, the mother of all routers - apparently, and 2) that MT is slowly but surely caning x86 support in preference for CHR (which would now include ADDITIONAL costs, as ESXi and a lot of virtual platforms needs to be licensed as well). Given the lack of VMWare-tools and other requirements on the CHR platform, that too, is not really a usable / production ready product (MT can't even be bothered to make a proper installation system).

So, MT... What *exactly* are we supposed to be using then? And PLEASE don't say to wait for the "non-existent" release of v7. Even IF v7 is released tomorrow, it will take at least a year before it is production ready in terms of bugs and stability.
I think nothing can really be done on ROS for the Tilera platform. Hence this post: viewtopic.php?f=2&t=121533

Who is online

Users browsing this forum: No registered users and 6 guests