Mikrotik 4011 recevied untagged (VLAN 2) and tagged traffic on ether9
I have a problem with reaching a host in the same VLAN while having /interface bridge port hw=yes for ether2. If I set hw=no for ether2 everything works.
Host A ----- Ubiquiti AP ----tagged(VLAN2)---- (ether2)Mikrotik(ether9) ----untagged---- Host B
I don’t understand the critical part of your solution, which solves my problem.
Is it possible without having VLAN 7 on the bridge? ether1 is my uplink which requires all packets to be tagged with VLAN 7. If this changes in the future, it can lead to problems, because I might use it already on my bridge.
hw=yes in ROS bridging means L2 packet forwarding in HW btw. physical ports of switch ASICs, aka l2hw
This is only possible for ports on the same switch chip.
RB4001 has two switch chips, one for ether1-5 and one for ether6-10.
No HW forwarding is possible ether2 ↔ ether9.
This is one of the advantages of RB5009 over RB4011. It has all etherX ports incl SFP+ on the same switch chip, allowing HW forwarding btw. all of them.
Running a jumper from ether5 to ether6 gets you partway there. It isn’t inter-IC switching, but it is line-speed forwarding, as if to a neighboring switch.
I can say all above suggested readings apply to my devices. Yours is …
IMO checking for yourself is worthwhile to fully optimize your device.
MiktroTik does fairly well with RourterOS to gloss over product hardware differences but exceptions remain and on-going improvements all make for a moving target. Be prepared to restudy this area for every product model and every RouterOS major release.
@chechito@jbl42@tangent
MikroTik documentation suggests at most one bridge per switch chip for various reasons.
Can I reasonably extrapolate that into two bridges with RB4011iGS+ as a sound design?
MikroTik documentation suggests at most one bridge per switch chip for various reasons.
For this thread’s router model (RB4011) yes. The exception is the CRS1xx/2xx series, which allow seven hardware-accelerated bridges per switch chip.
The RouterOS world is full of surprises.
Can I reasonably extrapolate that into two bridges with RB4011iGS+ as a sound design?
My comment about “three” bridges wasn’t pointless nit-picking. If you’ve got something plugged into the SFP+ it’s off on a third hardware bridge from the perspective of all this hw=yes acceleration stuff. I point this out because it may be materially important. (And it might not.)
As for the broader point I’m making about two switch chips, thus two hardware bridges, the key point I would take from that is that you should treat the RB4011 as two switches sharing a single power supply when it comes to hardware VLAN filtering.
Connecting its two internal switch chips with an external jumper lets you configure a trunk link between the two and then play VLAN filtering games on either end. For instance, you can configure an RB4011 so that when VLAN ID=10 traffic comes in on ether8 destined for ether2, it trunks from ether6 to ether5, then out ether2. Clumsy, but workable, and worthwhile in many circumstances.
Beyond these broad observations, I’m not the guy to solve your problems. I have a fair concept of VLANs and how they’re used, but I have yet to have good cause to implement them on RouterOS, giving me zero practical experience making VLANs work on this platform.
@tangent Before The MikriTik Way I used three desktop value switches for Internet, private, and DMZ subnets with ESXi VM as firewall router.
With CRS309 CRS326 CRS326 I have similar number of 1G ports and sufficient 10G ports to support three ESXi hosts with iSCSI.
hAP ax3 recently joined the family to retire 2.4G only WiFi and takeover the firewall router function.
Extra ports allow testing network platforms for co-location data center deployments.
VLAN became a valuable network management capability for my work.
hAP ax3 has Bridge VLAN Filtering setup which works but our work here suggests may not be optimal.
Can you suggest practical ways to draw the attention of hAP ax3 VLAN experienced users?
As far as I’m aware, nothing written above about the odd internals of the RB4011 has anything to do with the new “ax” lineup. They’ve all got a single switch chip that connects all their ports.
The same is true of CRS3xx.
As far as I was aware prior to this latest post of yours, you were here purely to help @gabscap, not to get help with your own configuration, which is quite different. If that’s true, you’re threadjacking, and you should take it up separately rather than distract those giving attention to @gabscap’s problem.
Can you suggest practical ways to draw the attention of hAP ax3 VLAN experienced users?
Draw a network diagram, post the configs of all devices involved, and include details of what you’re trying to accomplish and test results that show what isn’t working. When someone gives you advice of a thing to try, try it, don’t argue. Always remember: if your troubleshooting ideas were hot stuff, you wouldn’t be having trouble any more, now would you?
I think that concept of “one bridge per switch chip” has to be taken pretty verbosely in a sense that form performance point of view single bridge has to span only ports on the same switch chip, In RB4011 case: if you’d go with two bridge design, one bridge could span ports ether1-ether5 (or a subset of these) and the other bridge could span ports ether6-ether10 (or a subset of these). The point being that bridge can HW offload functions to underlying switch as long as that switch chip could perform all necessary steps on its own. If one bridge would span, for example, ether1,ether2 and ether6 (and ROS decides to offload this bridge to switch1), then ether6 can not be HW offloaded (the same way as SFP+ port can never be HW offloaded and neither can be wireless interfaces).
When it comes to inter-switch traffic: while it’s true that connecting with external patch cord would do the trick, it’s worth to remember that internal interconnects between switch chip and CPU are 2.5Gbps and that CPU is capable of bridging with ample speed … so in certain use cases (where other CPU load is low) using CPU as interconnect between ether port groups would yield in higher performance (example: ether1 communicates with ether10 and ether2 communicates with ether9 … when using external patch cord between ether5 and ether6, cumulative throughput is limited to 1Gbps due to hardware limits of used ether ports … while when using CPU as interconnect, both connections could flow wirespeed as hardware limit of interconnect is 2.5Gbps). So going for tricks (like using external patch cord and using two bridges) can benefit in certain use cases but one has to think about all consequences to decide which approach is better.
I didn’t know about that.
However, when talking about CRS1xx/2xx, it’s important to keep in mind that only basic switching is HW offloaded on these device models. VLANs are not. So in case of using VLANs in network, CRS1xx and CRS2xx have to be configured via switch menus and then number of bridges used doesn’t matter that much anymore (probably there are certain use cases where this option is still important, but I guess they are rare).
Yeah, I thought about that after posting but decided not to complicate matters still further. The primary virtue of the patch cord is that it’s easier to think about, but when it comes to implementation, it should be both unnecessary and suboptimal.
I apologize if I’ve created more confusion than illumination.
The exception is the CRS1xx/2xx series, which allow seven hardware-accelerated bridges per switch chip.
I didn’t know about that.
I believe I got the “seven” spec from the forums here, and it may well be conditional on the particular switch being discussed, because MT’s docs merely say “multiple bridges with hardware offloading.”
I think I need to clarify what I wrote before (not to add too much of confusion to the debate).
What I meant is that bridge can HW offload only basic switching to hardware on these models. If bridge has anything configured with regard to VLANs, then it won’t be offloaded to hardware.
Please use only and ever CRS3xx as switches! ROS is a ROUTING-OS, not a Switching-OS (their SWOS is unfortunately like a bad/old/buggy netgear OS).
I have spend hours over hours over hours configuring RB and CRS1xx devices as switches (in ROS). After reading hundreds of posts and endless long wiki/help-pages, I gave up. Even the simplest tasks are so complicated. And even I could figure it out, NO ONE in the whole company could achieve simple tasks besides me OR MT will change everything within a few releases. That makes these devices useless for the real world. CRS3xx are a bit better, because you can do everything through the Bridge-Menu and and not sketchy Switch-Submenus. But they are also buggy regarding switching, like MLAG which is too complicated, or Loop-Protection which does simply not work and and and… Support tickets are written and open, no response from MT. If you are a “bad” person, you could say they like to introduce half cooked-features like the BTH-VPN and left their buggy core-stuff left behind.
In the end, my best advice, use antoher vendor for switching! As told above, I have spend weekends over weekends, trying configuring a CRS1xx or RB. The same task was done with D-Link in under 30 minutes.
Can I reasonably extrapolate that into two bridges with RB4011iGS+ as a sound design?
The RB4011 is actually a 3-port router: 1x 10GBit Port (SFP+), and 2x 2.5GB Ports with attached extenders(ether1-5/6-10)
To take full advantage of l2hw capabilities, there should be one ROS bridge per switch chip.
bridge1 contains ether1-5/cpu ports with proper PVID and VLAN configuration, bridge2 the same for ether 6-10. SFP+ goes directly to the CPU and hence can’t be L2hw accelerated.
Ideally, no L2 broadcast domains or bridges span across the 3 CPU network ports. This keeps L2 traffic on the individual switch chips for l2hw and L3 traffic has to go trough the CPU for routing/forwarding anyway.
Or alternatively, the CPU attached SFP+ port makes the RB4011 an ideal router-on-a-10GBit-stick.
It should also be noted on RB4011 activating either IGMP or DHCP snooping on a bridge disables l2hw for all ports of the bridge.
