Why is so complicated to make VLANs on MT router or switch?
Can some make comparation configuring VLAN on CISCO and MT? On CISCO is two command, but on MT is hardwork? This is my HO
Sent from my Redmi Note 4 using Tapatalk
You are wanting a conceptual model that makes sense to you.
A VLAN is a virtual switch on top of real hardware. MikroTik’s documentation could probably do better to walk the end user through a mental model of this idea. Groups of commands are probably unconnected ideas to most people new to VLAN, commands that don’t show relationships to things. With MikroTik, I think they may have mapped their command syntax to their GUI display labels (the names of their edit and check boxes). It is not that MikroTik’s VLAN implementation is a bad one, rather it is a misunderstood one.
Example concept:
Think about what it’s like to delete a file on a Windows computer. You have the concept of a Recycle Bin. To delete files, you Empty this virtual object. This helps you understand what becomes of your files. It is a concept. The actual computer code looks nothing like this behind the scenes. Instead, Microsoft designed a concept that office workers might understand: files live in folders, that go in a trash can, that gets emptied. The command line concept also was based on old world meaning and history, so del file.txt was easy to reason about.
MikroTik’s implementation:
To create an Access Port you issue the following commands:
# Create a container to holds ports. Imagine this as the switch plastic casing.
/interface bridge add name=B1 vlan-filtering=yes
# Add a port and set ingress mode. Does this command explain itself?
/interface bridge port add bridge=B1 interface=ether1 pvid=20
# Set the port's egress behavior. How would you know this?
/interface bridge vlan add bridge=B1 tagged=B1 untagged=ether1 vlan-ids=20
# Allow the VLAN to be used at L3. Huh?
/interface vlan add interface=B1 name=vLAN20 vlan-id=20
/ip address add interface=vLAN20 address=10.0.0.1/24
What is really interesting is the misunderstood option set in the third command that is important if you want to run the optional forth and fifth commands. I set tagged=B1, this means that when you make B1 accessible as a vLAN20 object it will be accessible from packets that have a matching vlan id set (necessary for using a DHCP server, or other IP services). Note, we’ve not yet discussed vlan id enforcement (where the Access port drops ingress packets containing vlan tags).
A better command model?:
Here is a sample VLAN textual based representation, one that might be easier to reason about:
# Create a VLAN and add one or more ports to it
/interface vlan=vLAN20 ingress=20 egress=1 routable=yes ip=10.0.0.1 add port=ether1,ether2
vLAN20 is a virtual switch that can hold one or more ports. All those ports behave the same way as their container. Make another vlan if you want a single port to act differently, and so on. Behind the scenes it does the right thing with your hardware, software bridges, and so on - an abstraction - so you don’t have to understand the low level changes necessary to make it work.
Read my post here http://forum.mikrotik.com/t/sofware-vlan-bridge-on-ruteros-explained/122534/1
I did learn the new way (6.41+) to do it trough this post.
I know what is VLAN, i have CCNP. But for me is very hard to configure VLAN and trunk on MT. I just need some comparative preview between Mikrotik and Cisco configuration.
Sent from my Redmi Note 4 using Tapatalk
I agree, VLAN support is very messy. It would be nice if when configuring a software VLAN that RouterOS would just enable hardware offloading like it does for a bridge. Having both hardware and software VLAN configurations mixed together gets very confusing.
It’s a feature in transition, and complicated as result: was originally on switch and is being move now to bridge.
Now, Vlans can be done on bridge and on switch, for one chip in hw on bridge for other in hw on switch only …
I have worked with Cisco for 20 years and 10+ year with HP network products so know what you talk about.
Both Cisco and HP are simple compare tp MT. I did use MT more than a year before I tried to understand VLAN.
But know I have an idea on how it works.
Some told me that MT is based on how Linux implement VLAN and it can be done in many many complex ways.
Understood, my post will get read by people from various levels of understanding, so I made it readable from someone new to VLAN. I would like to see Cisco, HP and MikroTik comparisons too. I only have experience with MikroTik.
I work too with different HP switches, and VLAN, depending on the model to configure them differently, for example, with HP Arbua and FlexNet, but it is again intuitive, but Mikrotik is very confusing.
On some HP support I found comparative table with most used command on Cisco and three model of HP switchs.
Like this
In Mikrotik world, if we stick to the new bridge-vlan concept, commands would be as follows:
/interface bridge
set [ find name=bridge ] vlan-filtering=yes # this only has to be done once to enable 802.1q functionality on bridge
/interface bridge port
set [ find interface=ether6 ] frame-types=admit-only-vlan-tagged ingress-filtering=yes # make ether6 port VLAN-tagged only trunk
set [ find interface=ether7 ] frame-types=admit-only-vlan-tagged ingress-filtering=yes # make ether7 port VLAN-tagged only trunk
set [ find interface=ether8 ] frame-types=admit-only-vlan-tagged ingress-filtering=yes # make ether8 port VLAN-tagged only trunk
set [ find interface=ether20 ] frame-types=admit-only-vlan-tagged ingress-filtering=yes # make ether20 port VLAN-tagged only trunk
set [ find interface=ether1 ] ingress-filtering=yes pvid=220 # make ether1 port access port for given VID
set [ find interface=ether2 ] ingress-filtering=yes pvid=220 # make ether2 port access port for given VID
set [ find interface=ether3 ] ingress-filtering=yes pvid=220 # make ether3 port access port for given VID
set [ find interface=ether5 ] ingress-filtering=yes pvid=220 # make ether5 port access port for given VID
/interface bridge vlan
set [ find bridge=bridge vlan-ids=220 ] tagged=ether6,ether7,ether8,ether20 untagged=ether1,ether2,ether3,ether5 # if stanza with vlan-ids=220 already exists ... or
# add bridge=bridge tagged=ether6,ether7,ether8,ether20 untagged=ether1,ether2,ether3,ether5 vlan-ids=220 # if VLAN 220 stanza doesn't exist yet
The example above is similar to ProVision example in table above.
In short:
- in /interface bridge port one configures ingress behaviour (access, trunk or hybrid - allowed both tagged and untagged frames, depending on frame-types, setting with PVID for access/hybrid ports and setting about ingress filtering - either strict or none)
- in /interface bridge vlan one sets the egress behaviour.
If you need to configure management VLAN (e.g. on VLAN 220), then add these commands:
/interface bridge vlan
set [ find bridge=bridge vlan-ids=220 ] tagged=bridge,ether6,ether7,ether8,ether20 # add bridge as tagged (trunk) member of given VLAN
/interface vlan
add interface=bridge name=vlan-220 vlan-id=220
/ip address
add address=192.168.88.1/24 interface=vlan-220 network=192.168.88.0
Nothing too complex.
Before ROS 6.41, where VLANs had to be configured on switch chip, things were slightly more complex and slightly different on different RB device types.
You could also connect VLAN directly to the interfaces if I am correct. You did not need to use the switch configuration.
As shown in my first post here: http://forum.mikrotik.com/t/sofware-vlan-bridge-on-ruteros-explained/122534/1
Beauty of ROS is that many things can be done in more than one way. However, the “one bridge per vlan” way had its drawbacks even then (it seemed to be more straight-forward or easier to grasp, but it included plenty of error-prone configuration) and it wasn’t HW accelerated (even if switch chip is capable of all necessary functions) on any of RBs (the new bridge-vlan stuff is HW acclerated on select CRS devices).
ROS was great that way once you get a decent skill level. But before that, it was a nightmare. At least for me.
could you please explain me this line
Set the port's egress behavior. How would you know this?
/interface bridge vlan add bridge=B1 tagged=B1 untagged=ether1 vlan-ids=20
is this correct understanding of this line?
I am defining a VLAN bridge (so all included interfaces in the VLAN bridge .. in this case whole bridge B1) which is having all interfaces within the bridge B1 tagged but only port eth1 can be both.. tagged and untagged resp packets coming in eth1 which are tagged will be sent via bridge B1 and those which are untagged will just pass through.. and those tagged.. have VLAN tag 20...
correct?
i do not understand why is also untagged been defined within the vlan bridge which all eht port are obviously tagged.
tx
korg
It’s a matter of port security. If you don’t trust the device on the other side of wire, you will make sure it won’t inject frames to wrong VLAN. Or untagged frames into tagged-only port for that matter. Even if it won’t be able to communicate (return won’t pass due to egress settings), it could launch (or participate in) DDOS attack or something. And, BTW, sometimes one should not trust oneself.
As for the bridge setting of ingress-filtering: I’d like to hear/read a good explanation about both ingress-filtering settings (port and bridge) … what are diffrences and examples of use cases. I’ll accept, if backed by arguments, even explanation that one of them actually doesn’t work. Until I get that explanation, I’ll keep being on the paranoid side …
I have rewritten your question to help me understand what you’re asking. First of all, it is easy to misunderstand VLAN because even though it is a standard across different manufactures, it is implemented and defined using terminology that is so generic and poorly visualized that confusion abounds
I’ll explain the line in just a moment, but first…
I can’t speak to the way your network works, only you know why things are plugged into your network. But I can tell you that you need to be thinking about two different things. First, it is you who takes control of the network, don’t allow the network to control you. Second, once you have that fortitude, you plow forward using Access and Trunk Port concepts.
You do have to accommodate poorly written software and bad hardware, but you are still in control. So, I don’t like to hear that you have ports sending you tagged and untagged traffic and then you just agree to let those tags tell you what to do.
Access Ports:
- What is plugged in here must never be allowed to have a tag. If it does, you forcefully change it or drop it.
- When the reply goes out, remove the tag!
Trunk Ports:
- These should probably be called Trunk Links. Any packet showing up here should only have tags on them and must have first come from an Access Port or another switch (it’s Trunk). You are trusting, very much so, that these tags are legitimate. So protect your Trunk Ports with correct Access Ports.
- I know what you’re thinking, “but I have untagged packets coming into the Trunk!”. That is okay as long as you know why that is happening. I believe the only excuse for this is because its Native VLAN traffic, which is fine. It should come in and go out untagged. Use the right port for the job.
Now, about that line of code. With MikroTik, it takes two lines to define one port, you’re only looking at one line. I’m setting the egress behavior for an Access Port, which is that ether1 gets tag 20 removed (because I had previously set the ingress (pvid) to 20). Now, that still does not explain why I have tagged=B1 set. Now, this is confusing, and I’m sorry … but here it goes … if you want to have a VLAN interface on a bridge (an L3 one for IP Services), you have to tag the Bridge so that the CPU can allow your VLAN interface (VLAN20) to use DHCP servers and other IP related things on it.
If you’ve made it this far … stay tuned here for easy to follow examples. I’m still working on it and will be helped by the wisdom of @mkx and @sindy.
A bit of behavior that is not really clear to me … perhaps somebody wants to experiment? Here it goes:
we all know that in order to get tagged traffic to the RB (i.e. bridge), we have to make bridge tagged member of that VLAN. And then we use vlan interfaces off the bridge to deal with that traffic.
But we also know that we can set pvid to bridge, which allows us to deal with that VLAN traffic without using vlan interface. If we follow the analogy with ether ports (if that’s access port with pvid set, it should become untagged member of VLAN on bridge), is bridge supposed to be an untagged member of given VLAN port group?
My head is a bit dizzy now, so I’ll keep sticking to the all-tagged approach for my bridges …
It is very confusing and so low level that I feel MikroTik needs to remove it. The only hope we have of understanding this (because I don’t have access to their VLAN source code) is to read this very closely. I’m still confused because I think they are telling me something I should never have been told. You will note that the VLAN bridge, is really the CPU Port itself! What?
Yes, so apparently we need to protect via ingress filtering. We will probably get a firmware update to do the right thing at some point, because I don’t think this has any place in VLAN planning. It’s beyond what network admins need to be thinking about.
Here’s a quote:
You should be aware that the CPU port (bridge1) is also a bridge port and therefore might get added to the bridge VLAN table dynamically. There is a chance that you might unintentionally allow access to the device because of this feature. For example, if you have followed this guide and left PVID=1 set for the trunk port (ether1) and did not change the PVID for the CPU port (bridge1) as well, then access through ether1 to the device using untagged traffic is allowed.
The next paragraph explains some more … so you should read that and then tell me what I should do.
You’ve posted a link to a very interesting document. It actually clears the dilemma I described above.
That’s something I actively suspected for some time … and been preaching around about dual presonnality of bridge (one being sorta switch and the other being a port). But that’s true even if there’s no VLANs anywhere near RB device, since it’s always possible to add L3 configuration to “bridge” and in principle that’s only possible to do on top of L2 interface.
It seems that every vendor has their own peculiarities. One vendor (D-Link) has a feature they call “unsymmetrical VLAN” where you can have more than one VLAN being untagged on egress which means you can have a VLAN untagged on egress which is not the same as PVID (on ingress).
However, I do agree that ingress-filtering=yes should in fact be default setting on bridge member ports when vlan-filtering is set on bridge.
You should be aware that the CPU port (bridge1) is also a bridge port and therefore might get added to the bridge VLAN table dynamically. There is a chance that you might unintentionally allow access to the device because of this feature. For example, if you have followed this guide and left PVID=1 set for the trunk port (ether1) and did not change the PVID for the CPU port (bridge1) as well, then access through ether1 to the device using untagged traffic is allowed.
This is a prime example of why a port should not get a PVID set implicitly if it is listed as tagged member of any VLAN. As a work around one should set proper options as described in the document: ingress-filtering=yes and frame-types=admit-only-vlan-tagged for trunk ports. For access and hybrid ports things are not as problematic (IMHO ingress-filtering should be enabled at all times) as PVID is set explicitly.
To return to my dilemma above: document describes it nicely and it is indeed the way I was fearing. What makes it worse is that every port with PVID set gets implicitly added as untagged port to the list of ports of a given VLAN. While it might seem easier to config for beginners, it actually adds confusion. IMO it’s allways better to configure things explicitly, it’s even good for readability (think /export … implicit things are not exported and one has to think about implicit settings while reading such config export). Another bad thing is (and that’s what is confusing our humble @anav) that bridge has two personnalities and setting ingress-filtering on bridge actually does nothing about port-to-port security as it works for CPU port and not bridge (switch).
IMO the pvid stuff should be entirely ditched from the CPU port configuration as it adds implicit settings which (almost) always add confusion to the mix. Same goes to wireless ports … if they’re carrying VLAN-tagged traffic, they are probably used as wireless bridge and the device on the other end should deal with access ports (tagging that traffic) … if they are used as AP, then all traffic should be untagged and VLAN settings directly on wireless interface should suffice (making it tagged member of bridge).