MikroTik

Hi !

I do have a VLAN Trunk containing tagged packet, but also untagged packets. It's clear how to get the tagged packets to different vlan interfaces and connect them to different bridges.

BUT: How do I define an interface getting the untagged pakets from that interface/trunk to a different bridge ?

Not working: define a VLAN Interface with VLAN ID 1 (which should be reserved for that purpose)
Not working eigther: Putting the ether interface with the truck on a bridge, this will bridge away everything, tagged and untagged.

Thank you
Maria from Austria

Maria, have you solved this? I have the same problem. It seems to be imposible to solve it.
I've also tried everything.
Thanks!

Hi !

I haven't solved it yet - sorry. Perhaps Mikrotik could post a solution ?

Greetings Maria

I don't think you can do that at all. However, unless you don't have any control over the switch you're linking to, you can simply make sure that all VLANs include dot1q tags.

On a sidenote, VLAN 1 is not reserved for traffic without dot1q traffic (what Cisco calls the 'native VLAN') - it's just the default on most platforms. You can use any other VLAN for that purpose. VLAN 1 doesn't mean that there is no dot1q tag, it means that there is a dot1q tag with value 1. Since untagged packets do not have a dot1q tag, a VLAN interface for id 1 does not see those packets.

I have the same problem.

The interface has a VLAN defined on it (thus it is a trunk port) and most packets are tagged. But it also sometimes receives untagged packets - this is unavoidable. Most switches have the ability to support a PVID (Port VLAN) which is the default VLAN that the untagged packets are assigned.

Cisco routers can do this also by using default vlan on the interface.

This seems to be a real problem for the Mikrotik.

Has there been a solution to this scenario? I have the same issue. With my Cisco switch, I have no trouble assigning non-tagged packets to a default VLAN on my trunk, but can't get my RouterBoard to do the same thing.

Mikrotik routers aren't switches, and handle VLANs differently.

Just assign an unused VLAN (ideally it isn't even in the VLAN database) as the native VLAN on the trunk port on the Cisco switch. All packets in other VLANs will now have a dot1q tag (including ones that would be native, untagged packets on other switchports) and you can handle them on RouterOS via their dot1q tag.

That's a perfectly acceptable workaround, Cisco themselves lists using a completely unused VLAN as the native VLAN on trunks as part of their recommended best practices for layer 2 security.

Thanks for the response, but it won't work in my case. See my other post: http://forum.mikrotik.com/viewtopic.php?f=2&p=231847

I am not using a switch. I was just giving it as an example of what I wanted to see happen.

Replied to in that thread.

Have you tried bridging the underlying interface somewhere and then using a bridge firewall rule to strip off all tagged traffic?

Just a thought, I haven't extensively looked at the bridge filters to see if they can be easily convinced to do this. You might be able to do someting in conjunction with mangle/marking as well.

If you have a routerboard with the switch chip, have you looked in there to see if there are any relevant options?

(Replied to here as I'm addressing the Subject: specifically).

Rumaging around in one of our routerboards that has the switch chip, It appears that it can assign untagged to a specific vlan.

FEATURE REQUEST to MikroTik:

Allow creation of VLANs with vlan-id=0 and IF such a VLAN interface is attached (and active) on an interface, direct all inbound UNTAGGED or ZERO-TAGGED traffic to the vlan-id=0 interface. For traffic output over vlan-id=0 interfaces, add a new configuration item priority-tag=yes|no to indicate whether a zero-tagged frame should be emitted (i.e. 4-byte VLAN tag with VLAN ID zero--belongs to NO VLAN so tag is just for indicating priority), or whether (if "no") to emit a frame WITHOUT a tag.

This would fix all the troubles this thread has mentioned (and I've mentioned and many others have mentioned in other threads) by allowing a mixture of tagged and untagged traffic on an interface and provide a WORKING method to handle the traffic.

Thanks!

Aaron out.

Also, MikroTik, this KernelTrap thread has related/useful information:

http://kerneltrap.org/mailarchive/linux ... 18/6281280

Aaron out.

Rumaging around in one of our routerboards that has the switch chip, It appears that it can assign untagged to a specific vlan.

I've tried playing around with some of those settings, but there was no way to indicate different settings for incoming/outgoing. It would either strip all tags, or add a VLAN tag to all packets. In my case, I need all incoming untagged packets tagged, and all outgoing packets on VLAN 10 stripped. There didn't seem to be a way to configure this. If there is, it would seem like a solution...

In rule tab under Switch, you can add a rule with Match, vlan, vlan header not present, which should then only apply the action to packets which don't have a vlan header. Additionally, I think if you set the new vlan id to 0, that means strip.

You can kludge the input/output thing by using the Src and Dst MAC address fields (which can be a range) to match packets coming to/from your radios (in conjunction with the vlan matching, in case your clients have any of those radios as well).

ex:
ports 1,2,3
src mac: xx:yy:zz:00:00:00/00:xx:yy:ff:ff:ff
vlan header: not present
mean this packet is from one of my radios
action
set new vlan id 10.

ports 1,2,3
dst mac: xx:yy:zz:00:00:00/00:xx:yy:ff:ff:ff
vlan id: 10
means this packet is to one of my radios
action
set new vlan id 0.

where xx:yy:zz is whatever the manufacturer mac id(s) are of your radios. (you may need multiple copies of the rules if there are more than one and they are non-contiguous).

This hinges on vlan 0 really meaning untagged/no vlan.

If its such that incoming vlan-10 is always going to be from cpu, and the radios are always on physical ports, you could probably do away with the src/dst mac, and just use the ports to designate incoming/outgoing. (ex: convert untagged on 1,2,3 to vlan-10, convert vlan-10 on cpu to untagged (vlan-0)).

p.s. If memory serves, I think there is a limit to the number of rules the switch can handle, and it may also be tied into the complexity of the rules, I'm thinking it was something like 32 "steps" but I'm a bit rusty on this.

I've just been reading up on vlans, and it appears vlan-0 really means not a vlan, but still tagged (according to the 802.1q standards); so this becomes a bit harder problem.

You could bridge vlan-10 to the switch, but then we have to figure out how to only get the untagged packets injected into vlan-10 from the switch.

This is further complicated by different routerboards having different switch chips with different capabilities. It looks like only the 450g, 750g, and 1100 have the switch chip which is capable of rules. And it appears it can't strip tags either, at least as of 5.0rc1.

Oh well, ignore my last post I guess. It doesn't appear firewall mangle can add or strip tags either. There might be some kludge with creating pseudo interfaces with vlans on them and bridging them to things and using firewall rules to control what goes where, but it sounds very kludgy and my head hurts thinking about it right now. It appears the only way to add/remove vlan tags (excepting the switch chip) is to bridge a vlan and a non-vlan together, which is a problem if they also have traffic you don't want bridged together.

May just have to wait for that kerneltrap patch, and for RouterOS to expose it.

Have you considered alternatives, such as a private IP network for the radios and firewall rules to block access to it except from your management area? I'm guessing your using a generally bridged, rather than routed, network?

Or, if you're using (or could use) vlans everywhere else, you could use untagged as your management "vlan".

Sorry about the unintentional Red herring.

I've been out of the loop for awhile. Does anyone know if the latest RouterOS releases solve for this issue?