I'm running SwOS 1.14 on a RB260GS.

What I'm trying to do is use this as a port multiplexor for a layer two fibre access network. That is, we want to run the SFP port (with the fibre back to our main concentrators) tagged with five VLANs, one for each of the five ports (plus a sixth for management). We'd like everything received on, say port 1, to be tagged with VLAN 1001 and sent out the SFP port; and anything received on the SPF port with VLAN 1001 have the tag removed and sent otherwise unmolested out of port 1. Ditto for Port 2 / VLAN 1002 and so-on.

This includes tagged traffic. That is, if I send an 802.1q tagged packet into port 1, I'd like it to appear with a VLAN 1001 tag prepended, but with the original tag intact.

The idea is that a service provider can use the outer tag to specify the port on the network they wish to communicate with. The inner tag (customer tag, or C-Tag) is then available to the service provider to differentiate services, provide multiple VLANs and so-on. Basically, we don't want to care if there's a C-Tag or not - that's between the service provider and their customers, but if they send one in either direction, we want it to remain intact.

We've been doing this with switches like the EdgeCore ECS4210-12T and others for some years, but for deployment to smaller (including residential) sites, would like to use the RB260GS or something like it, for cost and form factor reasons.

I kinda hoped that setting the "VLAN Mode" on port 1 to "disabled", "Default VLAN ID" to 1001 and ticking" Force VLAN ID" would achieve this, but no, it re-writes the VLAN ID to the port VLAN rather than prepending a new tag. In fact it's pretty hard to see any distinction between the behaviours of many of the permutations available in the UI.

Is there some combination of settings that I've missed? If not, is it possible for a near future release of SwOS to provide this functionality? We'd kinda like to buy a bunch of RB260GSes, but can't unless we can make them handle C-tags correctly.

-- don

http://wiki.mikrotik.com/wiki/SwOS

Everything on VLAN setup that you should need is on the wiki.

Setting VLAN mode to "disabled" causes the switch to treat all packets on that port as untagged. You'll want to use either "enabled" or "strict". "Enabled" will drop packets tagged with a VLAN that is not present in the VLAN table, and will effectively tag any untagged packets with the "Default VLAN ID". "Strict" does the same thing, except it also checks the VLAN table to make sure that you've allowed the specific VLAN on that particular port. In short, "enabled" will allow an ingress packet as long as the VLAN tag exists in the VLAN table anywhere, whereas "strict" enforces the port VLAN assignments. Both settings will use the "Default VLAN ID" for untagged packets.

I think you're missing the point. What I want is, given:

Port 1: default VLAN 1001
Port 2: default VLAN 1002
Port 3: default VLAN 1003
Port 4: default VLAN 1004
Port 5: default VLAN 1005
SFP: default VLAN 1 (or other), Member, VLANs 1001-1005,

If a packet is received on port 1, and sent on the SFP, I want to see the following behaviour:

Untagged, IP -> Tag 1001, IP
Tag 99, IP -> Tag 1001, Tag 99, IP
Tag 1001, IP -> Tag 1001, Tag 1001, IP

That is, I don't want it to have any difference in behaviour. In all cases, the outbound packet should have a new tag (1001 for port 1) prepended, regardless of whether the inbound packet was tagged at or not. I want it to always behave as if the inbound packet is untagged, and ethernet type 8100 is just another packet type like IP, ARP, IPv6 and friends.

But the only behaviours I've managed to get it to do when faced with an inbound packet have been to either drop it, leave the original tag intact (and not add the 1001 tag), or discard the tag received and overwrite it with 1001.

Note that the converse direction works fine, i.e. if I send it a double tagged packet, the outer tag is stripped off and used for its forwarding decisions correctly, leaving the inner tag intact (and forwarded as the only tag), i.e. Tag 1001, Tag 99, IP is translated to Tag 99, IP.

As far as I know, SwOS doesn't not support any options to configure Q-in-Q. While it appears that it is supporting it on a certain level, full support just isn't there. This makes me think the hardware is capable, but they haven't fully implemented it in the software. Perhaps this should become a feature request.

any update on this thread? I'm about to buy a css326-24g switch and for lab use, we need to have q-in-q support. is it there, yet? this thread is a bit old, so I'm hoping the latest switch-os has it (?)

No. There is no Q-in-Q and Mikrotik support eta in swOS.

any update on this thread? I'm about to buy a css326-24g switch and for lab use, we need to have q-in-q support. is it there, yet? this thread is a bit old, so I'm hoping the latest switch-os has it (?)