Hmmm, even if not used in other parts of your configuration, you'd better use (say) vlan11 and vlan-id=11
Rules #1 and #2.
Please also consider the advice (Rule #7) about configuring an independent "offbridge" port to be sure that you don't lose accidentally access to the device when fiddling with vlans.
Besides, to get some meaningful assistance, you will need to post a description (or better a scheme, even a hand drawn sketch would do) of your network and what should these vlans be used for.
Do not use an /interface vlan with vlan-id=1 unless you have a deep understanding of VLANs and the default settings Mikrotik use but do not show in the regular /export
Do not mix using a VLAN-aware bridge and directly configuring switch settings as they interact in ways which are not obvious. Unless you need the performance of the switch chip stick to using a VLAN-aware bridge.
VLANs should not be attached to bridge port members, only the parent bridge.
There is no /interface bridge vlan section, newer versions of RouterOS automatically add the tagged bridge-to-CPU port membership, otherwise you have to add them manually:
I made some headway â-Im just trying to have multiple nets attached to my default setup.
got the message âDO NOT USE VLAN01â, I have a pretty good understanding of vlans, (cisco centric)
I can now get dhcp on both 22, 33)(ether2 and ether3) addition to the 192.168.88.0 net which is I think vlan01⌠this also gets dhcp and is my âmain networkâ
clients can ping their respective gateways. and other interfaces of the router.
I do not get to the internet from the vlans only from 192.168.88.0 net.
From what I understand you have set on top of the bridge (that is using VLAN 1 underneath) a VLAN interface with id=1, this may (or may not) cause issues.
Put more clearly, do not define VLAN with ID=01, in your /interface vlans, not required or desired.
The advice was NOT to use vlan with id=01 for any data or subnet vlans.
The advice was to clearly use something like vlan with ID=11 for that subnet if such a subnet is required.
Thus set all ports on /interface bridge ports ether4-spf1 to frame-types=admit-only-priority-and-untagged with PVID=11
Add the frame types to ether2 and ether3 as those appear to be access ports.
One big difference between Cisco and Mikrotik is an /inteface bridge is effectively a switch embedded inside the the Mikrotik, and in addition to interfaces added with /interface bridge port there is an inherent bridge-to-CPU port for access to services provided by the Mikrotik itself. This port has the same name as the bridge just to be confusing.
As with those added with /interface bridge port the bridge-to-CPU port has a default pvid=1 (a.k.a. native in Cisco terminology), so the /interface vlanadd interface=bridge name=vlan01 vlan-id=1 has no use in this case. It is merely a wrapper - anything with VID=1 from bridge will appear on interface vlan01, and there will be none as on egress bridge â bridge-to-CPU port the tag is removed with VLAN 1 being native. You donât actually use the interface vlan01 anywhere so should be removed.
For 6.49.8 (which is the ROS being used here) that is probably correct. I have nothing with any v6 any more to test one way or the other.
I agree that having the bridge pvid be the same as a vlan interface is unwise (if for no other reason than avoiding confusion).
However, for version > 7.16 (reported), verified in this post on RB760iGS running 7.19.6, when a vlan interface is added to the bridge, that vlan will be tagged on the "bridge-to-CPU port" (even when it is the same vlan as specified by the bridge pvid). I still don't think is is wise to create a vlan interface for the vlan used by the bridge pvid, but that's a personal preference. ROS now will give precedence to the vlan interface, and you will lose access to the base bridge interface (so it is still possible to lock yourself out, if you don't have firewall access to another vlan interface).
Here are excerpts from the post showing effect of adding vlan interface for vid=1 on ROS 7.19.6
Note: I was using either bridge.200 or br.210 (I can't remember which, but the important point is that I was not using bridge at the time I made the change. vlan-filtering was already on.)
Note that egress frames for VID=1 from "switch" to cpu-port were changed from untagged to tagged.
The pvid of the switch is still 1, so any traffic sent from either the bridge interface (untagged) or br.1 interface (explicitly tagged with VID=1) will enter the "switch" as vlan 1. But return traffic will be tagged after the br.1 vlan interface is created.
Subsequent posts in the thread discuss blocking the untagged traffic from entering the switch with frame-types=admit-only-vlan-tagged. But that seems to have the potential to interfere with spanning tree protocol (which I think is implemented by the CPU on some devices).
And we are back to the two fundamental Rules of the Mikrotik Club and their corollaries.
I really don't get it why people who are told that they can use VLAN 1 to 4094 but that in order to avoid possible issues it would be easier/better to use only VLAN 2 to 4094 have this fixation for using VLAN 1.
lets say for example you are hooking up a mikrotik to a network that already has vlan 1 enabled throughout, say a 200 node cisco network. At this point there are 2 options. Use vlan 1 as untagged all other vlans get tags for trunking purposes or you must map cisco vlan 1 to a mikrotk vlan 11, which ive done before on not mikrotik but IMO causes confusion when debugging problems.
thanks for all the input I have a much better understanding of mikrotik vlans. now to figure out 802.1q trunking⌠which still has me baffled.
All switches use vlan1 as the default untagged port, that is not in dispute, what is, is using vlan1 as a management and worse data vlan.
Go into the Cisco and change the settings so vlan1 is not the assigned managment vlan, DONE.
Itâs complicated. There are a number of layer 2 control protocols which are always untagged (spanning tree, LLDP, LACP, etc.) and passed to/from specific ports via the switch chip using proprietary vendor headers in the packets. This all goes on under the hood in RouterOS and is not directly visible in the UI, unfortunately with both data and control packets all being sent over the same link some releases occasionally break this due to unintended side-effects of changes.
The actual spanning tree logic is always handled by the CPU, where bridges support hardware offload when spanning tree is enabled the CPU controls blocking/forwarding on the switch ports based on the current spanning tree data. To implement this the switch chip has to be configured to permit spanning tree layer2 control packets between the CPU port and each of other switch ports whilst potentially dropping data packets from ports when in the alternate state.
Many vendors only allow you to create VLANs with IDs between 2 and 4094 (e.g. Ubiquiti), reserving VLAN 1 for untagged. The issue is really that Mikrotik allow any valid VLAN ID to be used allowing users to create invalid configurations, with the newer versions of RouterOS which dynamically add /interface bridge vlan entries when an /interface vlan is created on a bridge it would be helpful if the UI flagged this up as mentioned by @Buckeye
Perhaps âDo not use VLAN1â should become âDo not use VLAN1 taggedâ
The topic is simply broader.
It should also be considered that from 3968 to 4047 with 4094...
These 80 VLANs, plus VLAN
4094, are allocated for internal use.
3968â4047 and 4094 Internally allocated
You cannot create, delete, or
modify any VLANs within the
block reserved for internal use.
4095 for the inside forward...
And also for other devices...
By default, the range of reserved VLANs is from 4064 to 4094. Among the reserved VLANs, VLANs 4064 to 4071 are used for port mirroring, and VLAN 4095 is used by the system to forward packets inside a device. Other reserved VLANs are used for function extension in later versions.
Blah, blah, blah.....
Finally some documents recommend just using IDs (which are NOT names) from 2 to 1005 ONLY for normal VLANs.
VLAN ID 0 is reserved for tagging the priority of frames.
VLAN IDs 1 through 511 are reserved for normal VLANs. VLAN IDs 512 and above are reserved for VLAN circuit cross-connect (CCCs).
So, in the default configurations, to avoid creating incompatibilities between manufacturers, only 2 to 512 should be used as IDs, making only 511 VLANs available to the user...
