Hello,

I have a small WISP (200 homes) and use VLANs, with one per customer. I use the switches to keep broadcast domains smaller to avoid typical L2 WISP problems. It works fine.

My question is; I remember a few years back there was a change with Mikrotik OS, and [at an apartment complex site] all the VLANs I had put on an ethernet interface were shifted to a new bridge. I did read up on this at the time and remember it was the new preferred way of doing it.

Could someone please tell me why we should put VLANS on bridges rather than directly on an eth interface, and what are the advantages/disadvantages?

All the WISP customers (VLANS) are currently on a single eth interface. There's no bridges. I feel like i'm not doing it right. CPU maxes out at under 50% with 800Mbps passing - 1009.

Soon I to need to setup LACP between this router and radio#1, which is a 2Gbps Siklu, which uses LACP to go from 1Gbps to 2Gbps, so i'll need two ports on router ... I will put a switch in the middle to but still need LACP between router and sw1. This is not really my question, but open to suggestions here.

Any and all help appreciated. I did have a look about forum but cannot see why bridges became the proper way.

Thank you!

Jimmy

Could someone please tell me why we should put VLANS on bridges rather than directly on an eth interface, and what are the advantages/disadvantages?

If you only have a single pair of interfaces per vlan (i.e. the custormer end and your end) then I don't see any possible advantage to using the bridge. The advantage of using the bridge is that you can have more than two host in a vlan, and then these host can communicate at layer 2 without any CPU involvement, the switching can be done by the switch ASIC.

Watch this Mikrotik Bridge VLAN Filtering which was made with v6.47.x on several different devices. Some devices have better bridge and switch support in v7.

cannot see why bridges became the proper way.

Simply put, it's not "bridges became the proper way", it's "a single bridge, common for all VLANs, became the proper replacement of one dedicated bridge per each VLAN". As @Buckeye said, since you had no bridge before, there is no advantage in inserting it now - you'd just load the CPU even more.

Having said that, I'm not sure how LACP treats VLAN-tagged packets when choosing the link to use. So if you eventually end up with all traffic on one link, which is most likely not what you want, it might make sense to add the bridge in order to use MSTP to create two groups of VLANs, each preferring one of the links and falling over to the other one if the preferred one fails. Intuitively it should create higher CPU load than LACP, but I may be wrong.

And the last point, if the machine is at 50 % of CPU already now, once you start using the 2 Gbit aggregate bandwidth, it will become even worse, so not sure it is the way to go. Do you use queues to restrict bandwidth for customers?

If we already talk about performance, IMHO, you should solve the problem - VLAN via switch chips.

I have significantly reduced the CPU load on the switches after such a transition. Currently, my device workflow is very similar to this - Manual:CRS1xx/2xx VLANs with Trunks. 2 gigabit channels to the Internet, on the router - DNS server and DHCP server. After - a few switches CRS125-24G-1S.

Elsewhere (in another building) - CRS326-24G-2S+ switches. They are easier to set up.

you should solve the problem - VLAN via switch chips.

In this particular case, the CRS acts as a router, not as a bridge, so offloading the (nonexistent) bridging to the switch chip would have no effect.

Thank you all so much, appreciate the info. I'm hoping very much that LACP isn't going to cause such problems, and that the LACP algorithm will distribute traffic evenly, rather than putting all VLANs down one side.

I seem to learn OK from videos so will watch any posted on these two topics.

Thanks again!

Jimmy

One thing I don't understand is why that apartment router, when updated, created a bridge and put all the VLANs on it. Previously all VLANs were directly on an ethernet interface, just like I have my WISP setup now. I wonder if it was because there were two LAN ports, with the old 'master port' function used to duplicate the first LAN port? I think the master port function got taken away, so maybe making a bridge and setting up bridge ports was the only way the router could provide the same functions out the same ports with the new OS?

Thanks,

Jimmy

I think the master port function got taken away, so maybe making a bridge and setting up bridge ports was the only way the router could provide the same functions out the same ports with the new OS?

Yes, it is related. Before 6.41.something, the "bridging" (done by CPU) and "switching" (done by switch chip) were strictly separated from the administration point of view. The "master port" was used as a kind of a handle object representing a whole group of ports among which traffic was switched in hardware. On most devices, only one such group of ports per switch chip is possible, so back then, you could only have a single master port per switch chip; when L2 forwarding among another group of ports was necessary, you had to use a bridge for that. With the current approach, although the frames are handled exactly the same way internally, the way it is presented to the administrator has changed - all the ports in that group are now members of the bridge, and the "handle object" is now the bridge. So all bridges look the same, but one of them is able to enjoy the hardware forwarding - by default the choice is made by RouterOS but you can configure it manually.

So indeed the reason why the bridge appeared is that there were multiple interfaces grouped together in your pre-6.41 configuration.

Thanks, Sindy!

So, just to confirm, there's no need to put these 200VLANs onto a bridge, to save CPU? If they're on an eth interface it will be the CPU processing them, so wouldn't it make sense to put them on a bridge and make that bridge the special one? Sorry if you've answered this already, I just want to understand properly.

The reason it happened back then, you've explained really well. It makes me think I need to look at all my bridges to see which one is getting access to the switch chip processing. I guess ROS chooses the one with the most ports, or most interfaces? Does it change dynamically?

Where can I see this chosen bridge and where can I set it?

Thanks very much

running a CCR1009

there's no need to put these 200VLANs onto a bridge, to save CPU? If they're on an eth interface it will be the CPU processing them, so wouldn't it make sense to put them on a bridge and make that bridge the special one?

Putting them to a bridge would consume more CPU, not less. Because no frames are L2 forwarded between two Ethernet ports at the 1009 - they all run from the wire to the routing stack or vice versa. So processing them in a bridge would be just extra steps that are not necessary in your case.

Outside your application case, the "special bridge" can only be special if there is a switch chip in a device, and that's only the case with the older version of the 1009 (CCR1009-8G-1S); the newer one (CCR1009-7G-1C-PC-xx) has no switch chip at all.

I guess ROS chooses the one with the most ports, or most interfaces? Does it change dynamically?

Where can I see this chosen bridge and where can I set it?

I was never eager enough to find out what the strategy is. But you can control which ports are eligible for "hardware accelerated bridging" by setting the hw item on the /interface bridge port row to yes (it is indeed selectable per port, not per the whole group); whether it has actually happened is seen in the output of /interface bridge port print - there is a H indicator in the indicator column. In Winbox the indicator is there too.

Thanks so much, Sindy!

I love Mikrotik.

Cheers!