Hi all,
I have a CCR2004 (which has two switch chips, 9 ports on chip 1 and 9 ports on chip 2, both Marvell 88E6191X). Can I create a single bridge containing ports of both switches or should they necessariliy be linked to different bridges? The aim would be to have ports with the same VLAN ID, member of the bridge but linked to different switches, would that work as if there was only on switch chip (if not, why not)?
Regards,
Kris.
Not a chip expert but wouldnt creating the same vlan to cross the two chips be self defeating as this then involves the CPU.
In concept, the idea is to maximize wire traffic between ports on the same chip and thus as you surmize, bridge the ports on one chip and the other ports on the other chip for another bridge.
In some case you may not be able to avoid inter vlan traffic crossing to the other chip…???
Yes, you can have single bridge spanning both port groups. With potential performance hit mentioned by @anav.
There was a bug in how ROS configures VLAN offload to switch chips … on devices with two switch chips it was necessary to add bridge port as tagged member of all VLANs which span both switch chips even if router doesn’t communicate with it (useful when device is used as a switch), otherwise frames would not pass between ports on different switch chips. This bug was acknowledged by MT, but I’m not sure if it was fixed already.
Be careful, SFP+ ports are connected to CPU, not switch chips.
mkx was that across platforms or only applicable to the RB4011 ??
Two ASICs, means two bridges.
bridge1 for ports ether1-8, bridge2 for ether 9-16, this ensures both port groups are fully hardware offloaded to the correct ASIC.
For SFP1 and SFP2, both being independent paths towards the CPU, you could put them in bride3, but I wouldn’t advise this, as you will likely want to make SFP1-2 an LACP bonding to your uplink, so the LACP bonding and the underlying physical ports are not members of any bridges at all. So 20G uplink via LACP bonding, independent of any bridges.
Nice!!
As far as I understood MT staffer who chimed in (could be it was Normis, could be it was somebody else) was that the bug was in the way ROS configured the switch-CPU interconnect port of the switch. I.e. it was configured to pass only VLANs of which bridge (the CPU-facing) port was member. Which is fine for devices with single switch-chip and the switch-CPU interconnect is really used only for interaction between ROS and network. But this is not OK on devices with multiple switch chips where switch-CPU interconnects are used also for (indirectly) interconnecting different switch chips where switch-CPU ports must be configured to pass also VLANs present on other switch chips even if ROS doesn’t interact with them.
So this bug is not RB4011 specific, but it seems it was first discovered there (perhaps because RB4011 is often used as router/switch combo for SOHO while CRS2004 is mostly used as a decent router).
That’s one way of doing it … if two bridges come handy. But it doesn’t have to be two bridges, one bridge spanning all ether ports will do just fine.
And there’s nothing wrong with adding SFP+ port to a bridge. Surely it won’t be HW offloaded, but the rest of bridge ports will be, just like when one adds wifi interface to a group of ether ports … ether ports keep being HW offloaded, wireless isn’t. One only has to keep in mind that SFP+ traffic will bog CPU, that’s all.
You could do that, by running a cable from ether8 to ether9, but why? This is a bandwidth poor approach.
Using a CCR2004 in a switch manner is a sin to begin with. But it’s up to device admin how he wants to use his device and I simply answered questions by @KrisVG. You, OTOH, are risking accusations about pushing your own ideas upon person asking for help (accusations seem to be fashionable these days).
Dont worry, Darknate has a thick skin, not concerned with wall flowers… 
But how insenstive of you mkx to imply the oP may have purchased the wrong product jajaja
Hi mkx, that’s an interesting remark. I may indeed have purchased the wrong device (in my defence: I’m a system administrator, not a network administrator). I could use the CCR2004’s ports only for routing/separating between interfaces but I thought using the switch chips in it would accomplish the same thing only on layer two. Furthermore, directly attached to the CCR2004 are a number of switches (different brands) that have a number of VLANs on them. How would I connect several VLANS (on different switches) if not by using a bridge on the CCR2004? I work for a school (thus (very) low budget) so I use the CCR2004 as a router with integrated core switch.
Hi DarkNate,
So if I want a single bridge I need to connect two ports (one of each switch chip) and probably configure them as trunk for all VLANs. Is that correct? If so, that would be a lot of unneccesary traffic going over that connection, is that what you mean by “bandwidth poor approach”?
FYI: I’m going for the two bridge approach and if a connected switch has VLANs of both bridges I’ll just connect two ports of that switch with one port of each bridge.
It was a more or less rethorical remark, directed at @DarkNate . Since you already have the device, you should use it as much as possible (“abuse” even). If using it as router/switch combo fits your needs, then just use it so. And if you’re not after last bps of performance, then you don’t have to bother with all the tricks @DarkNate mentioned (specially so as they come with their own price) which then allows you to apply a much more straight-forward config.
Wrong. Either you have single bridge and (implicitly) use internal interconnects to “glue” the two switch chips together. Or you have two bridges (with independent configuration) and use external interconnect to pass traffic between the two switches. Benefit of “two bridges” approach is that CPU will not be bothered by L2 traffic and will be free for routing duties (does your routing require the CPU power available?), the price is loss of two ethernet ports.
Don’t listen to @mkx, he’s trying to sell you a piss poor implementation that itself doesn’t match official MikroTik docs. He calls my approach as “tricks” even though official MikroTik agrees.
See this link:
https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching#BasicVLANswitching-Otherdeviceswithabuilt-inswitchchip
And read this fully:
For devices that have > multiple switch chips > (for example, RB2011, RB3011, RB1100), each switch chip is only able to switch VLAN traffic between ports that are on the same switch chip, > VLAN filtering will not work on a hardware level between ports that are on different switch chips> , this means you should not add all ports to a single bridge if you are intending to use VLAN filtering using the switch chip, VLANs between switch chips will not get filtered. > You can connect a single cable between both switch chips to work around this hardware limitation> , another option is to use Bridge VLAN Filtering, but it disables hardware offloading (and lowers the total throughput).
Using the cable works, offloading will work, but you’re limited to just 1Gig for inter-ASIC forwarding.
@DarkNate, I could have misread and I don’t even have 0,1% of your knowledge, the note you posted seems to be for “Other devices with a built-in switch chip” (VLANs configured on the switch).
I was one that reported bug on the RB4011 in v7.8 for devices with 2 switches and hardware offload, until v7.7 and from v7.10 devices (RB4011 + CCR2004) with multiple switches and a single bridge are working as expected.
CCR2004 fits under the “Other devices with a built-in switch chip” section, please check with official MikroTik support, you don’t have to trust me blindly, verify.
Single bridge for all ports of both switch chips as members? With HW? Share your config sample, /int bridge export.
RB4011 is also under the “Other devices with a built-in switch chip” section:
This type of configuration should be used on RouterBOARD series devices, this includes RB4xx, RB9xx, RB2011, RB3011, hAP, hEX, cAP and other devices.
Yes sir. DarkNate,
I trust you more than me 
This is an RB4011, currently I can’t show you that ports were hardware offloaded due to testing dhcp/igmp snooping enabled;
/interface bridge
add dhcp-snooping=yes frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=Bridge protocol-mode=mstp vlan-filtering=yes
/interface bridge port
add bridge=Bridge edge=no-discover frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1 point-to-point=yes
add bridge=Bridge edge=no-discover frame-types=admit-only-vlan-tagged interface=ether3 point-to-point=yes
add bridge=Bridge edge=no-discover frame-types=admit-only-vlan-tagged interface=ether10 point-to-point=yes
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 point-to-point=yes pvid=10
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 point-to-point=yes pvid=10
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether6 point-to-point=yes pvid=10
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether7 point-to-point=yes pvid=10
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 point-to-point=yes pvid=20
add bridge=Bridge edge=yes-discover fast-leave=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether9 point-to-point=yes pvid=30
Support involved with SUP-141900 to give us an official statement.