Could you explain what you mean?The last time I checked the old way of using gazzillion of bridges with vlan configured on switch chip was still available in ROS 6.44 ... at this time only documentation tries to persuade device admins to switch over to new single bridge concept.
You are wrong. I don't know a way to use RB2011 as a managed switch. I tried with switch menu because with bridge vlan filtering I lose hardware offload. I don't understand how to manage vlans in a device with two separate switch chips and bridge vlan filtering: if you manage vlans with switch chips, you have two separate switches, and if you manage vlans with bridge vlan, you don't have hardware offload also in the same switch (5 ports); so, what to do? Do We need a CRS326-24G also for 6-7 ports?I'm sure you, with all of those MTCertifications, know all of that. And I have my own opinion (and you won't believe this: mostly I agree with my own opinions) which I wrote in my previous post.
Sure, you can do many things with cascaded bridges, but that kind of config is not readable/understandable by anyone who's not into cascaded bridges as you might be. On the other hand, configuration with VLANs on single bridge is plain & straight. And I'm pretty sure it's possible to lock one self from the device when config is not right whichever way of configuration is done.
Good for you. According to specifications RB750Gr3 doesn't have any VLAN capabilities whatsoever, everything remotely connected to VLAN needs to pass CPU.I managed to configure switch vlans correctly on the RB750Gr3,...
On the contrary, the bridge vlan filtering brings uniform way of configuring various bridge functions (VLANs included) on all ROS devices. So if you actually dug into, you'd see that the nightmare ended a year or two ago.So, I understand that you, mkx, love "bridge vlan filtering" (I not!), but you at least will agree with me that this heterogeneity of configuring vlans from device to device is a disaster, don't you?
You didn't give a very concrete example, but anyways: CRS (both 1xx and 2xx) should be capable of doing what you described in hardware, VLANs cofigured through /interface ethernet switch. This way, all VLANs (tagged or "native") can be switched wire-speed, none of packets are actually dealt with by CPU.I've already a CRS112 in production, as a 4 fiber trunk node with some ethernet trunks and also some access ports used by ip phone networks and home automation (different vlans).
So, to make CRS112 handle 1Gbps among the trunk ports, it's configured simply ad a master bridge with the trunk ports (hardware offload on) , vlan on this master bridge, and some other bridges that handle the single vlans with their access ports.
This configuration works because cpu handles only the phone and automation networks, that are slow devices, and the trunk traffic (which contains office computer traffic ad 100 and more IP cameras on their specific vlans not needed as access ports on this node) passes through switch chip.
But the CPU is however too much slow and often goes to 100%, so I was interested to move towards a better configuration as a manged switch.
I think you should try the switch-chip way of configuring VLANs on devices where bridge vlan-filtering doesn't allow good performance. You might get pleasantly surprised.So, sum the two situations which I described, and you can realize why I'm looking to find a more reliable configuration, although I'm very worried about migrate all my personal ISP network (all mikrotik) from bridges configuration to bridge vlan filtering or switch chip vlan configuration.
# jun/28/2019 15:40:29 by RouterOS 6.44.1 # model = 2011iL /interface bridge add name=bridge protocol-mode=none add name=bridge-uffici protocol-mode=none /interface ethernet set [ find default-name=ether1 ] comment="PC cassa" set [ find default-name=ether2 ] comment="Dorsale verso Mareluna 2011" set [ find default-name=ether5 ] comment="stampante test" set [ find default-name=ether7 ] comment=\ "xp80 stampante fiscale 100M 192.168.0.69" set [ find default-name=ether8 ] comment=\ "epson stampante cucina sala 100M 192.168.0.231" set [ find default-name=ether9 ] comment=\ "xprinter stampante cucina ristorante 100M 192.168.0.229" set [ find default-name=ether10 ] comment=\ "epson stampante comande bar 100M 192.168.0.230" /interface vlan add comment="vlan on bridge" \ interface=bridge name=vlan-uffici vlan-id=2000 /interface ethernet switch port set 0 default-vlan-id=2000 vlan-header=always-strip vlan-mode=secure set 1 default-vlan-id=1 vlan-header=add-if-missing vlan-mode=fallback set 2 default-vlan-id=2000 vlan-header=always-strip vlan-mode=secure set 3 default-vlan-id=2000 vlan-header=always-strip vlan-mode=secure set 4 default-vlan-id=2000 vlan-header=always-strip vlan-mode=secure set 5 default-vlan-id=1 set 6 default-vlan-id=1 set 7 default-vlan-id=1 set 8 default-vlan-id=1 set 9 default-vlan-id=1 set 10 default-vlan-id=1 vlan-mode=fallback set 11 default-vlan-id=1 /interface bridge port add bridge=bridge interface=ether2 add bridge=bridge interface=ether1 add bridge=bridge interface=ether3 add bridge=bridge interface=ether4 add bridge=bridge interface=ether5 add bridge=bridge-uffici interface=ether6 add bridge=bridge-uffici interface=ether7 add bridge=bridge-uffici interface=ether8 add bridge=bridge-uffici interface=ether9 add bridge=bridge-uffici interface=ether10 add bridge=bridge-uffici interface=vlan-uffici /interface ethernet switch rule add copy-to-cpu=yes ports=ether5 switch=switch1 /interface ethernet switch vlan add independent-learning=no ports=ether2,switch1-cpu switch=switch1 vlan-id=1 add independent-learning=no ports=\ ether1,ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=\ 2000 /ip address add address=192.168.87.47/24 interface=bridge network=192.168.87.0 /ip dns set servers=192.168.87.1 /ip route add distance=1 gateway=192.168.87.1 /ip ssh set allow-none-crypto=yes /snmp set enabled=yes /system clock set time-zone-name=Europe/Rome /system identity set name=Mareluna-cassa-2011 /system ntp client set enabled=yes primary-ntp=192.168.87.1 /tool sniffer set filter-interface=ether5
As long as you keep the default pvid of vlan1 on all devices (not as a management vlan per se but as a default) at least on the MT devices and what I have discovered between a mix of vendors, I can still see and control my managed devices. On the other hand I am a big proponent of it works DONT FIX IT!
Perhaps you don't like the management network on vlan id=1, but in large networks I prefer this metod because 1) if I put my computer in the trunk network, I can easily see all devices with both winbox (for mikrotiks) and other vendors applications; 2) if my wolrkers put on the network some new devices, I can easily find them and start programming them with the same pc on the same port, that often is a remote bridged port from my office to the customer.
Ether2 is the trunk port connected to the rest of network.There isn't much odd in your config apart from configuring one bridge (the 100Mbps one) without VLANs while configuring the other one (the 1Gbps one) with VLANs but then use vlan interface to bridge them both together.
My guess is that both bridges could be HW offloaded (they use distinct switch chips), it is possible to verify by running /interface bridge port print - actual HW offload status is indicated in the status column for each port. But then it's been said that only single bridge per RB device can be HW offloaded and it could well be design decission and nothing to do with actual hardware.
From the description it's not clear whether ether2 actually needs to be nember of bridge as it seems to be configured exclusively for RB2011 management. So it could be pulled out of bridge and IP config could be bound directly to ether2 interface. Which would enable to use the rest of gigabit ports without VLAN config. Probably you could actually configure RB with single bridge, add all ether ports (less ether2) to it and optionally set hw=no on ports ether6-ether10 if it turns out that only ports from one of switch chips can be HW offloaded and HW enabled is preferred on gigabit ports.
I'll just say it again: your setup is completely valid in recent ROS versions (also your export says the same, you're running 6.44), for now bridge vlan-filtering is not mandatory. I still don't undersrand your bad mood from original post in this thread.
So, you need an hybrid way, that shows the limitations of this new way (bridge vlan filtering) to do those things.
I simply don't understand the issue you talk about. Probably you have some tagged packets coming from some access interfaces; in this case, I think it's normale that tagged packets will be re-tagged in a Q in Q way.One thing that nobody mentioned: vlan interfaces are "dumb" tag injectors. They don't implement any logic. Just inject tag or strip tag, depending on the direction and that pose a risk of tagging already tagged frames. And I am not talking about QinQ. I am talking about 3, 4 or even 5 layers of tags.