RB3011 Block diagram?

You are not alone! Check out my thread http://forum.mikrotik.com/t/weird-routing-loop-in-logs-but-there-isnt-one/95280/1

I was told the recent RC would fix it but it has made no difference at all. I am not happy as I need software bridge for SFP and I currently can’t use any software bridge without the dreaded error logs.


MT support have been silent once provided with supout files confirming problem.

First of all, RB3011 does support fastpath. Counters are going quite nicely.
I found CPU load distribution to be tricky. You need many connections to distribute it properly.

As far as i understood from communication with support each switch-chip is connected with 1Gbps line to each CPU,
So if switch-chip decides to take path1, CPU will have to process it with core1, it switch-chip decides to take path2, then core2.
and it doesn’t matter how high the load is on CPU cores atm.

Hello,
The RB3011 block diagram has been updated to better represent internal connections among CPU cores.

Any comment on the looping problem? I am getting nothing from my support ticket.

Do you have an English translation? Google won’t translate the page.

I understand that is the switch chip, not the CPU. :slight_smile:

Try microsofttranslator
http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http%3A%2F%2Flanmarket.ua%2Fstats%2Fobzor-marshrutizatora-Mikrotik-RB3011UiAS-RM

Thank you! Did not know about that one.

Tilera/EZchip/Mellanox: TILE->ARM
Freescale/NXP: PPC->ARM
Applied Micro Circuits: PPC->ARM
Atheros/Qualcomm: MIPS->ARM

Allow me to resuscitate this topic :smiley:

Am I right to assume that if I have a fiber uplink to the LAN and WAN on the first switch chip the router will just use the CPU1 ??
I am not sure if SFP will connect directly to CPU1 or to the second Switch chip?

By the way, how does the router decide which CPU to use? Is it based on some kind of round-robin ?

Regards.

usually its choosen magic-driven dice roll, touched by libastral.so device/stub.
and sheduling(let alone balancing or parking) generally its tricky topic even in multi-core, let alone many-core platforms. several patents hold on-topic, several research stuff still ongoing.
and since ARM percentage/penetration even in networking keep skyrocketing - appropriate toolchain soon become mission-critical. thats why so many efforts(from countless companies) in upstream of linux do happens howdays. even legacy (and not produced anymore)Arm versions keep updated relavtively slowly among LTS stuff.