Subject: Feature request - add interface Vlans & ports & bridge functions into a single easy Winbox/Web settings page

IMO :
Managing interface Vlans ( mode access vlan and/or mode 802.1q trunk - and configuring what vlans are allowed to go through Trunk interfaces is ( at this time ) very difficult for most admins to understand how Mikrotik SwOS and ROS does port management.
Also depending on the hardware , things are different again.
Also depending on if the OS is SwOS or ROS , things are different again.
Also depending on which ROS version ( 6 or 7 ) things are different again.
Also there is no single winbox/Web interface that allows you to see all port settings.

At best , it's a guru Mikrotik nerd thing only - if that.

I wish to make a Feature-Request for all basic port settings to be on one simple single page ( and one single area in a CLI export ).

Question , what percentage of Mikrotik admins know to do the following:
- Configure ether1 as an 802.1q trunk and allow all vlans
- Configure ether2 as mode-access on Vlan-10
- Configure ether3 as an 802.1q trunk interface and only allow vlans 10,20, 50, 200, 210
- Configure ether4 as an 802.1q trunk interface and block/deny vlans 11,22,55,220,215
- Configure ether5 as a Q-in-Q interface - vlan(s) in vlan .
- Configure ether6 as an S-Tag and.or C-Tag to/from any network device.
- Configure ether7 as a trunk & set a native vlan & configure what vlans may pass through that port.

On many/most switches , this is normally simple and easy-to-understand single GUI screen or in a single section of CLI code.
However -- On a Mikrotik ( especially any version of ROS ) , you are all over the place on multiple screens. And if you are like me , I just give up and get a different brand of switch that does all of the above - and all versions of the non-Mikrotik switch have the almost same simple port easy-to-configure vlan(s) configuration procedure on a single screen.

I've requested a single configuration page many many times since I started using Mikrotik routers a long long long time ago.
I love Mikrotik devices , but switch & vlan port configurations are a total nightmare because there is no single GUI or CLI section to manage ports and vlans access/trunk interfaces.

Please create/add a single GUI / CLI page to manage all ports and their vlan access/trunk configurations.

Mikrotik switches are decently priced , but managing port vlan access/trunk configurations is not possible to easily do -- and near 100-percent impossible if you are an experienced network engineer and you have your first Mikrotik switch.

** Recently , I was given several dozen(s) new Mikrotik switches by a near-by Casino because they could not figure out how to manage port/vlan access/trunk configurations. This Casino's network admins were never able to get a single Mikrotik switch configured to replace their older Cisco switches - so they gave them to me ( a large pallet truck-load of new Mikrotik switches never-installed ) and went with another brand which has what I am requesting.

Please please please , create/add the above requested functions/features.

North Idaho Tom Jones

Also - related to my original post here

The single GUI page should also have the ability to manage both HW-bridges and non-HW-bridges.

The new GUI could possibly auto-detect if a port is already configured and mark it in the single GUI as non-configurable because the port is already
configured in other sections of port/switch configurations - aka only able to configure in the GUI if the port & bridge & vlans that are not already configured else where. This might make it easy to create a single page GUI if the GUI page does not have to translate and/or modify other sections of ports & bridges. Thus if a port or vlan or bridge is already configured , then the admin would simpley delete/remove the old configurations for that port then let the new single-page GUI do it all.

Note - I just did a forum search for vlan
I got the following response: Search found 62303 matches
** That's a huge amount of vlan ( port /switch ) questions - and none of them simple/easy for any non-guru Mikrotik admin.

I personally never use "quick set". In fact one of the first things I do when setting up a new device is remove the "quick set" button all together.
With that being said, it wouldn't be the worst thing in the world to have an entire menu for "quick set" type changes such as what Tom is suggesting. Stuff that covers the 80% use case scenarios that most people would need. One of the biggest challenges RouterOS has is that most people who aren't used to it become very overwhelmed trying to change really simple settings and just give up on it.

And Tom, feel free to send one of those switches my way

... And Tom, feel free to send one of those switches my way ...

lol - yea right - I'm still thinking what what I'm gonna do with a ton of new still-in-the-box never-installed never-configured 1-Gig PoE /10-Gig/25-Gig/40-Gig/100-Gig switches.

- note - the Casino staff member who gave me the ton of free switches was given a no-charge 100-Meg Internet account. Made it worth his effort to bring them to me from his work at the Casino.

The part I will agree with you on is that I don't understand what is preventing them from unifying the front-end VLAN config interface as much as possible across the different models of switch chips used in the different products. I understand that not all switch chips support all of the same features, but still...you should be able to abstract away as much of the implementation details as possible behind a common interface. Why do some Atheros/Qualcomm chips require mucking around with /interface/ethernet/switch, and CRS1xx/2xx also involve /interface/ethernet/switch but with a *completely* different interface, but CRS3xx/5xx allows you to just use the same /interface/bridge abstraction that you use when configuring a software bridge? Why can't all of the switch chips just take their marching orders from /interface/bridge?

Aside them that, I am fairly happy with the current /interface/bridge model...it makes logical enough sense to me. So as long as I limit myself to CRS3xx/CRS5xx/CCR2xxx hardware, or am fine with just a software bridge, I'm golden.

There are, admittedly, a couple of glaring shortcomings with even the current implementation, the primary one (in my opinion) being that you can only ever manipulate one kind/ethertype of tag. So if you have a need to filter based on C-tag (0x8100) for most trunk ports, but also want to designate one or more ports as QinQ (or, more accurately, "QinAD") and so filter on S-tag (0x88a8), this is impossible as far as I know. You have to pick one or the other. However, with the new tag-stacking feature on ROS 7, you can do true "QinQ" (or "Ctag-in-Ctag"), which probably satisfies most people's requirements. If you DO configure the bridge to filter on 0x88a8, though, it will automatically treat frames with 0x8100 tags on them as "untagged", so tag-stacking does just automatically work with no extra config.

Managing interface Vlans ( mode access vlan and/or mode 802.1q trunk - and configuring what vlans are allowed to go through Trunk interfaces is ( at this time ) very difficult for most admins to understand how Mikrotik SwOS and ROS does port management.

I tried to provide a summary of this recently for RouterOS in a different thread that I'll re-echo here:

• To configure an access port, all you need to do is change the PVID of that interface in /interface/bridge/port
• To configure a trunk port, you add a given interface to the "tagged" list of a defined VLAN under /interface/bridge/vlan

Also depending on if the OS is SwOS or ROS , things are different again.

These are two completely different software platforms, so I'll give them a pass on this.

Also depending on which ROS version ( 6 or 7 ) things are different again.

Not that much different? In any case, things changing is a way of life, like it or not...whatever changes that they have made to the switch config UI in ROS 7, they're not going to go and back-port those to ROS 6.

Also there is no single winbox/Web interface that allows you to see all port settings.

/interface/bridge/vlan is pretty comprehensive. I can't think of anything that you can't see there at a glance with respect to what ports are getting trunked which VLANs. Any access ports that you configured by setting a port's PVID also shows up here, with the interface showing up under the "current-untagged" list for that VLAN-ID.

I wish to make a Feature-Request for all basic port settings to be on one simple single page ( and one single area in a CLI export ).

So basically a "Quick Set" for VLAN config on switches? It's not an entirely terrible idea, admittedly, but...you just got finished complaining about too many different ways to configure VLANs across different MT platforms and ROS versions, did you not? And now you want to introduce yet another different way?

I am reminded of this comic.

Configure ether1 as an 802.1q trunk and allow all vlans

Configure ether2 as mode-access on Vlan-10

Configure ether3 as an 802.1q trunk interface and only allow vlans 10,20, 50, 200, 210

Configure ether4 as an 802.1q trunk interface and block/deny vlans 11,22,55,220,215

Are you maybe starting to get the flavor of this a little bit?

(It's important to note that valid IDs for a trunk port are basically a whitelist on ROS, while on other switches you may be used to a trunk port allowing all IDs by default until you explicitly remove some.)

Configure ether5 as a Q-in-Q interface - vlan(s) in vlan

Configure ether6 as an S-Tag and.or C-Tag to/from any network device

Ambiguous what exactly you mean here. As mentioned earlier, you can't mix S-tag filtering and C-tag filtering on MT switches (that I know of). Whatever VLAN tag ethertype you filter on, it will ignore all others and just treat those as if they are "untagged". If you truly need to deal with S-tags, though, you would:


If you are content with just using C-tag ethertype as if it were an S-tag, though, then I'm guessing you want this?:

Configure ether7 as a trunk & set a native vlan & configure what vlans may pass through that port

Configure ether7 as a trunk + what VLANs "may pass through" (get trunked by) that port...it's the same as all of the previous ones:


...and then set that same trunk port's native VLAN:


So, to sum up:

• Any port where you don't add a "tagged=" attribute to a VLAN for it under /interface/bridge/vlan is de-facto an access port
• Any port where you add it to a "tagged=" attribute to one or more VLANs under /interface/bridge/vlan is de-facto a trunk port (actually a hybrid port, since it will by default continue to pass VID 1 as untagged, at least unless/until you set the native VLAN for that same port)
• Setting "pvid=" property for a port under /interface/bridge/port sets the access VLAN for an access port, and the native VLAN for a trunk port

Seems pretty simple, really.

The disclaimer, of course, is that this is all true as long as you are using anything except for the old CRS1xx/2xx, or one of the residential/SOHO router models that has some low-end 5-port switch chip in it (so, basically, the models that don't have Marvell switch chips in them are the oddballs). But friends don't let friends use CRS1xx/2xx anyway.

Hi Nathan, great summary.
However I am helping mostly new persons and they dont understand the basic entry method (manual) which uses both /interface bridge port and vlan to tell a coherent story.
In fact by cross-checking the two sets of entries, a consistent approach and understanding is solidified.

Then once they can do that, your approach makes sense as they understand the basics and then can grasp how the router is dynamically adding all these rules ( and switches as well).

re - feature request

I'm not saying it can't be done.
I am saying it's nearly impossible to configure switchport vlans if you are not already experienced with Mikrotik routers/switches.

Let's take the Casio and Hotel(s) mentioned for example.
3 very experienced network engineers who are already using switches that support things like switchport , access/trunk , vlan allowed , vlan deny , and VoIP phones where the IP phone is PoE powered , connects to a trunk port on the switch , the phone comes up on vlan-71 and the PC behind the phone comes up on Vlan-51. ( On a Cisco , this is easy and nearly identical configuration settings across all Cisco switches ( decades old or new out of the box - a simple show run and you can see everything about the switchport configurations in one place. They tried for months , researched the forums and on-line Google searches - every attempt failed. So they gave up on the Mikrotik switches and gave them to me.

I personally know about 10+ other local larger organizations who tried Mikrotik switches and gave up on them also. Mikrotik switchport Vlan documentation is not consistent and not similar to other products ( CLI and/or GUI ).

An experienced network engineer who has never touched a Mikrotik switch , should be able to configure their first Mikrotik switch in 30 minutes or less - and not need to spend months trying to figure out how Mikrotik does vlans in ROS.

SwOS looks very promising with it's single simple GUI. I would like to see something like a SwOS optional package for ROS or built-in where there is a single GUI page that shows everything for all ports/bridges/vlans/access/trunk ... configurations.

I am saying it's nearly impossible to configure switchport vlans if you are not already experienced with Mikrotik routers/switches. [...] Mikrotik switchport Vlan documentation is not consistent and not similar to other products ( CLI and/or GUI ).

I get the argument. I guess all I was trying to demonstrate was that virtually all of the VLAN config that you need to do on a MT switch running ROS can be accomplished using & knowing only 2 different commands: one that tags VLANs on trunk ports, and one that sets access port VLAN / native VLAN on trunks. I basically alternated between using the same two commands for all of my examples.

It is perhaps slightly regrettable that the PVID setting is located in a separate area ("ports") from the VLAN trunk config setting ("vlans"). But even so, within both Winbox and CLI, you can still see BOTH at the same time by looking at / printing just the "vlans" section, and looking at "current-tagged" and "current-untagged" for each VLAN. So there is in fact a one-stop-shopping place in the UI to at least SEE everything all together on one screen, even if you can't necessarily change the port native VLAN from that same screen.

I have personally run into many managed switch models in the past that split PVID config from trunk config in their UIs (as in, two separate web pages), though, so it is not like this is unique to MikroTik. This was a constant thing with many a Dell PowerConnect model back in the day, as well as several other "smart" switch models from vendors like Netgear, D-Link, Linksys, etc. that I'm sure were all OEMing their switches from the same common set of Chinese contractors.

Finally, the same argument you make about MikroTik VLAN config being "unlike" Cisco could be made about virtually any MikroTik feature. I know people well-versed in Cisco who have had trouble just getting basic IP routing up and working on MT the very first time they sat down at it. This is not an argument for changing how MikroTik works, though. The fact is, MikroTik isn't Cisco, and they do things their own way...they aren't trying to create a routing platform with a cheap IOS interface clone slapped on top of it. So, yeah, if you've never used it, there is inevitably going to be a learning curve that you are going to have to go through for almost ANY MT feature, and that includes just understanding basic CLI syntax & navigation, which of course is wholly different on ROS than on virtually any other platform. Once you grok general "MikroTik-eze", though, then picking up specific things like VLAN config arguably becomes easier.

Tom, these engineers are not all that resourceful, they never came here for help!
I do know that Mikrotik has been making advancements in the automation of setting up vlans on multiple connected devices and automations on interface lists etc......
But nothing towards what you are looking at ...

Sadly, MT thinks of UI progress as akin to quickset, which they avoid doing.
They do not approach their product from a user experience, but just slapping features in........
Hence many menus and especially documentation is technical but often not friendly or enlightening.

PS I have no need for 100Gig switch but 40 gig.........LOL
Always willing to help a friend get rid of their hoarding problem!

anav
Re: ... these engineers ...

IMO ; Mikrotik has two pretty good OS systems ( ROS & SwOS ).

- ROS for L3 routing is very good and easy to understand. Easy to learn and follow their CLI and GUI configurations - even for a newbie admin and/or for most experienced network engineers who are working on their first Mikrotik.
- ROS - MAC telnet and MAC Winbox are totally awesome features/functions - some of the best tools in the industry. It's very easy to use and learn.
- ROS Bridges work well when kept simple ( excluding L2 vlan configurations ).
- ROS Safe-Mode works well. It's a really powerful function when working on remote Mikrotik ROS networks.
- ROS is very stable and reliable and the only minor brief down-time is during an upgrade.

- SwOS is pretty good for most L2 only switch needs.
- SwOS has a very simple easy to learn and understand L2 switch/port configuration.
- SwOS mostly has a single/simple GUI screen for basic L2 switch port configurations.
- SwOS makes it easy to work with Vlans.

However ;
- SwOS is not a router
- ROS is not a switch ( yes ROS can do L2 switching - but it's all over the place ( multiple screens ) and not something that can be learned and understood in a few hours or days )

Re my Feature request ;
* I hope I am not beating a dead horse here ...
I truly believe there can be good mix of both ROS and SwOS features where the best features of both are combined. Where the simple L2 configuration screens in SwOS are added into ROS.
- Possibly SwOS package ( optional or built-in ) for ROS.
- Possibly a Mikroitk beta OS , call it SwROS. Where a ROS system can be uploaded/upgraded to SwROS and/or where a SwROS can be downgraded back to normal ROS.
- I would think it might be straight forward for a Tik software programmer to remove the L2 functions in ROS and insert the L2 functions of SwOS then call it SwROS-beta or alpha.

Somewhere , there has got to be an easier way to use a simple one-screen GUI in ROS for switchport access/trunk/vlan configurations.

*** for anav --- How does Canada feel about Trump making your country a 51'st state ? ( don't know what's gonna happen in the next 4 years - might be crazy )

North Idaho Tom Jones

Haha,
My answer to your question is simple, Welcome to Canada, South BC ( formerly North Idaho ).

I see what your getting at, try to merge SwoS simplicity within RoS for vlans.
I like the concept.

PS. Working on my Teeter Accent, in case things go awry.