Community discussions

 
stucki
just joined
Topic Author
Posts: 19
Joined: Sun Apr 16, 2017 3:57 pm

ETA v8

Sun Apr 16, 2017 5:14 pm

at the last mum someone said the next release will be v8 ; )
 
jarda
Forum Guru
Forum Guru
Posts: 7604
Joined: Mon Oct 22, 2012 4:46 pm

Re: ETA v8

Sun Apr 16, 2017 6:07 pm

The next release will be 7. 8 can come just after that. And 9 then... So what?
 
w0lt
Member
Member
Posts: 485
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: ETA v8

Sun Apr 16, 2017 7:15 pm

The release dates will be Q2/Q3 20xx, approximately. :lol:

Don't worry, it will be real soon now... :lol:
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "

Image
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24277
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: ETA v8

Tue Apr 18, 2017 8:59 am

does the number really matter?
No answer to your question? How to write posts
 
dtoffo
Trainer
Trainer
Posts: 97
Joined: Tue May 17, 2011 9:19 am

Re: ETA v8

Tue Apr 18, 2017 9:58 am

does the number really matter?
Right, the number doesn't matter...
the date could matter....

Davide
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24277
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: ETA v8

Tue Apr 18, 2017 10:02 am

I guess you are waiting for some specific feature, not the number or the date.
No answer to your question? How to write posts
 
User avatar
Murmaider
Member Candidate
Member Candidate
Posts: 121
Joined: Fri Oct 30, 2015 10:10 am

Re: ETA v8

Wed Apr 19, 2017 6:11 pm

I guess you are waiting for some specific feature, not the number or the date.
multi-threaded bgp seems to be at the top of the list...
 
timberwolf
Member Candidate
Member Candidate
Posts: 274
Joined: Mon Apr 25, 2011 12:08 pm
Location: Germany

Re: ETA v8

Wed Apr 19, 2017 9:05 pm

Fix for muticore packet reordering comes to mind, if this isn't already silently fixed.
I didn't have the motivation of retesting this since a few months. Last time I stumbled upon this(6.34 I think) I disabled one core of the RB850Gx2 under test.
Im referring to viewtopic.php?t=102252 where someone tripped over this with IPTV and was put off to v7 and "maybe" ;-)
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1821
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: ETA v8

Thu Apr 20, 2017 1:56 pm

I guess you are waiting for some specific feature, not the number or the date.
multi-threaded bgp seems to be at the top of the list...
BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
User avatar
sguox
Trainer
Trainer
Posts: 73
Joined: Fri Mar 09, 2012 6:23 pm

Re: ETA v8

Thu Apr 20, 2017 2:26 pm

does the number really matter?
number no longer relevant since free lifetime upgrade :)
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: ETA v8

Fri Apr 28, 2017 3:38 am

Right. But they don't run bgp and ospf and fib updates and filtering and xxxxxxx under the same process. That's why a dual core major brand router can handle several hundred peers with convergence times 5x faster than 2 peers on a mikrotik.
I guess you are waiting for some specific feature, not the number or the date.
multi-threaded bgp seems to be at the top of the list...
BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..
 
parham
newbie
Posts: 32
Joined: Sun Feb 15, 2015 11:35 pm

Re: ETA v8

Sun Apr 30, 2017 9:07 pm

does the number really matter?
No at all, as much as ROS and SWOS get more improvements and more features thats matter, just a suggestion its a time to add one important feature, let's encrypt, its now necessary for https, ikev2, sstp, ... hope see it in next RC release.

Thanks.
 
stucki
just joined
Topic Author
Posts: 19
Joined: Sun Apr 16, 2017 3:57 pm

Re: ETA v8

Sat May 27, 2017 8:09 am

we should stop to annoy normis, I guess he hates openvpn and udp since to many poke for it.
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

Re: ETA v8

Sat May 27, 2017 11:15 am

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..
Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false
 
tetecko
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Sun Jun 11, 2006 7:44 pm

Re: ETA v8

Tue Jun 06, 2017 10:00 pm

I guess you are waiting for some specific feature, not the number or the date.
multi-threaded bgp seems to be at the top of the list...
+1000
 
upower3
Member
Member
Posts: 384
Joined: Thu May 07, 2015 11:46 am

Re: ETA v8

Wed Jun 07, 2017 5:23 pm

does the number really matter?
Only bugs really matters. Finish and polish existing features - this will be the best way.
 
brotherdust
Member Candidate
Member Candidate
Posts: 110
Joined: Tue Jun 05, 2007 1:31 am

Re: ETA v8

Fri Jun 23, 2017 8:52 pm

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..
Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false
Multi-threaded BGP might be hard, but it's necessary; and, here's the thing: it's already a solved problem. I'm using this in production: https://github.com/osrg/gobgp.
  • I've verified it's multi-threaded.
  • Takes about 1GB for full Internet BGP table
  • Has lots of kick-ass modern features
  • Built for SDN from the ground up
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5942
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: ETA v8

Mon Jun 26, 2017 12:18 pm

1GB for just one BGP feed :shock: that's a lot.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1821
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: ETA v8

Mon Jun 26, 2017 12:24 pm

1GB for just one BGP feed :shock: that's a lot.
I agree, that is a lot.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

Re: ETA v8

Fri Jul 07, 2017 6:29 pm

1GB for just one BGP feed :shock: that's a lot.
Just wait till you see some of the L3VPN/L2VPN NLRI on a service provider on a route reflector. It's far more than that.....
 
barkas
Member Candidate
Member Candidate
Posts: 260
Joined: Sun Sep 25, 2011 10:51 pm

Re: RE: Re: ETA v8

Fri Jul 07, 2017 6:48 pm

1GB for just one BGP feed :shock: that's a lot.
Just wait till you see some of the L3VPN/L2VPN NLRI on a service provider on a route reflector. It's far more than that.....
Full table doesn't fit in 1GB anymore.
 
pqatsi
just joined
Posts: 3
Joined: Thu Jun 18, 2015 3:03 pm

Re: ETA v8

Fri Jul 07, 2017 8:52 pm

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..
Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false
Multi-threaded BGP might be hard, but it's necessary; and, here's the thing: it's already a solved problem. I'm using this in production: https://github.com/osrg/gobgp.
  • I've verified it's multi-threaded.
  • Takes about 1GB for full Internet BGP table
  • Has lots of kick-ass modern features
  • Built for SDN from the ground up
+1 for GoBGP. How expensive is RAM today? I dont think it matter for a router that must handle full BGP tables.

Who is online

Users browsing this forum: Google [Bot] and 48 guests