RBD52G-5HacD2HnD-TC just popped up on FCC web site.
they refer to it as hap ac^2
it is supported already by 6.40.4, i found no data on cpu, could be one like the Qualcomm IPQ-40xx maybe but neither of them is triple chain: https://www.qualcomm.com/products/ipq4019
Looks good, although it is a pity there seems to be no SFP port.
Dual core arm looks good, WIFI looks good, but would be nice if external antennas could be added.
Probably same processor as in hEX?
What is the fcc id?
that’s mmips.
Indeed…
Why would it be triple chain? Model name suggests 2x2 2.4/5 GHz.
Looks like a no-frills version of the hAP AC to me. No SFP, TC case but still gigabit.
Speaking of ARM goodies, the QCA9984 (4x4 wave2) Routerboard still hasn’t surfaced.
I suspect a whole slew of new ARM based products will be announced at the EU MUM in April.
Products we know for sure:
cAP ac
hAP ac2
SXTsq ac
LHG 5ac
Products I think we may see, in order of likeliness:
CCR grade router with 64bit ARM processor and multiple “next-gen” interfaces, e.g. SFP28, QSFP28
RB2011 replacement with ARM processor (possibly something along the lines of the CRS109 but with ARM CPU)
Omnitik ac2
mANTBox 15/19 ac2
BaseBox/Netmetal ac2
RB M33 type board with ARM processor
RB M11 type board with ARM processor
wAP ac2
They better start with ROS7 in this year, ARM Products only badly supported, and Wave 2 Chipsets are buggy with ROS6, most Packages are not multicore capable
i mistook the last TC - probably a freudian slip - as the first gen hAP ac was triple chain on both bands.
indeed the last TC must be standing for “tower case” i presume…
I don’t disagree.
Can you give me an example of a package that is not multicore capable ?
Not package, but BGP, BW test and other ale single core…
On the BW test point, I agree it would be great if Mikrotik split the individual tests into seperate threads.
On the BGP/Routing however I disagree.
A few points:
-
Control Plane ≠ Forwarding Plane
While the processing of routing updates happens in a single thread, packet forwarding (the actual movement of your packets) is already multicore capable. -
BGP is single threaded on Cisco IOS, IOS-XE and IOS-XR as well as on Juniper JunOS and Nokia SRos
The processing of routing updates, and in particular the application of route-filters needs to happen in a “run to completion” matter. That means that running it accross multiple threads will result in unpredictable results. This is why you cant just “make BGP multi-threaded”. What can be done is to split each protocol to a seperate process with a central “condcutor” process, this is what Quagga/FRR do with the zebrad process, and what JunOS does with RPD.
Excellent comment, nz_monkey. Thanks for clarifying it for others, much appreciated.
@normis is there anything on the horizon that will help offset the shortcomings of current CCRs in terms of BGP performance aside from ROS7/multi-threading?
E.g. a CCR device with a more powerful CPU? Or this is rather in the realm of CHR?
i’ve been thinking a bit.
there is a (theoretical) way to make it a “bit more” multithreaded / multicore, but the whole idea will only (some) benefit if there are multiple “heavy” neighbours with lots of updates and/or big amount of prefixes.
there is a bgp backend process, which has all bgp routes (we may refer to this as bgp table) and does all the best path calculation. other threads are doing per neighbour communication, e.g. processing incoming advertisements, applying inbound route filters, etc and sending the final prefix data to the backend.
as they could have “read only” access to the bgp table, the outgoing filters could be also done by the same per-neighbor-threads.
then you could have a 3rd process that is responsible to update the kernel routing tables based on the bgp table, and notifying the backend process in case of kernel routing table changes.
this is similar to the implementation of openbgpd, and would allow to split the “big” bgp elephant onto multiple cores. however there must be some sort of control that locks a certain entry in the bgp table (as it is being modified by the backend) so no half baked data is read out by the other processes - which would introduce other blockers…
Except what nz_monkey wrote … we are implementing much faster BGP in v7. Not multi-threaded, because of reasons that were outlined, but much faster.
So is that confirmation that you are actively working on v7 and it is not just a pipe dream? I presume it would be needed if the next generation of products are to be sold.
Some parts are ready in v7, some parts are not nearly ready. We can’t release only the good parts. Those we can sometimes backport. If we backport enough stuff, there is no more need for v7 though 