Hi,

I'm hopeful this is an easy one for someone. I'm struggling to understand why egress packets are being VLAN tagged in a particular circumstance.

I have an old-model 260GS running SwOS 1.17. I have a computer attached to an access port, and then a (incorrectly configured IMO) trunk port heading off elsewhere. Please see the screenshots [2] showing the config of the ports in question.

I've mirrored egress from the trunk port, and can see in Wireshark that packets from the computer have VLAN tag of 2. Why is this the case? The trunk port is not set to add the tag if missing, and from the docs [1] my understanding was that the default VLAN ID for the port will not actually modify the packet unless there's an egress rule to do this? The computer on the access port is sending untagged packets.

If somebody could explain why/where the packets are being tagged that would be greatly appreciated. Thanks in advance.


[1]

Switch will treat both untagged and "Default VLAN ID" tagged ingress packets as they are tagged with this VLAN ID. VLAN tag itself will be added only if there is VLAN Header = add if missing specified on egress port

[2]

You have to have VLAN tagging on the trunk port or else you would have both VLAN 2 & 3 untagged (and therefore no longer separate) on the trunk port.

Thanks for your reply.

Certainly I see the need to tag on the trunk port, no question about that. However from my screenshots and the docs I would expect, as you suggest, for the traffic to be thrown down the trunk untagged (and thus not work, dependent on the pvid at the other end anyway). As I say though, the traffic does seem to be tagged.

Are you implying that SwOS will just tag unconditionally if a port is a member of multiple VLANs or something?

Are you implying that SwOS will just tag unconditionally if a port is a member of multiple VLANs or something?

Could be. I really don't know. I certainly don't claim to be the expert. In fact I just learned an hour ago that a setting in 2.7 did not work quite the way I expected for un-tagged ports. I changed a bunch of ports and stuff stopped working. Fortunately I had not changed the port that I was using for access (I'm not that that location). However it appeared to work in 2.8. That CSS326-24G-2S switch is scheduled to be upgraded to 2.8 this weekend, so I will play with it after the upgrade (I will be at the site at the time so a little easier to recover from an Oops!).

The "Default VLAN ID" you can understand as a PVID (Port VLAN ID) that assign this specific VLAN to untagged ingress packets - the switch internally adds this VLAN to all incoming (untagged) PC packets. Then switch needs to decide where to forward this packet, only now comes the egress action (leave as is, add if missing, always strip) - it looks in your VLANs table, decides to forward through your "Trunk" port which has egress action "leave as is" (remember that Default VLAN ID was already added when packet was received), thus packet is sent out with VLAN.

Thanks for your response EdPa.

That certainly makes sense, and I would have assumed it to work this way had it not been for the line in your documentation that reads as follows,
taken from the table at https://wiki.mikrotik.com/wiki/SwOS/RB2 ... 0#VLAN_Tab :

Switch will treat both untagged and "Default VLAN ID" tagged ingress packets as they are tagged with this VLAN ID. VLAN tag itself will be added only if there is VLAN Header = add if missing specified on egress port

How does this quote apply to the sequence of events you just described?

The first part:

Switch will treat both untagged and "Default VLAN ID" tagged ingress packets as they are tagged with this VLAN ID.

This is meant for ingress traffic (PC --> switch). Received untagged packets will be assigned with "Default VLAN ID". It also states that received packets with already added VLAN header that matches "Default VLAN ID" will be processed similar to untagged packets (only that VLAN header is already added, the switch is not going to change anything here).

The second part:

VLAN tag itself will be added only if there is VLAN Header = add if missing specified on egress port

This is meant for egress traffic (switch --> PC). When you set egress action to "add if missing" on PC port, the PC will receive tagged packets. The other actions "always strip" and "leave as is" will remove the VLAN tag before forwarding to PC.

I see why this can be misleading. See now if Wiki description makes more sense.

Thanks for clarifying EdPa ‒ indeed, the description really didn't make that behaviour clear! I see now the behaviour essentially provides that of a trunk's 'native VLAN' to borrow Cisco/others' parlance.

The change you've made to the wiki is definitely an improvement, thanks, but may I suggest an alternative which I believe is more straightforward to understand ‒ hopefully it summarises the behaviour correctly?

Ingress packets to this port will be tagged with 'Default VLAN ID' if they arrive untagged. Egress packets from this port will have their VLAN tag removed if it matches 'Default VLAN ID'. To have egress packets keep their 'Default VLAN ID' tag, set the 'add if missing' option on the egress port.

This does raise another question which was another area of confusion for me when trying to configure this correctly, perhaps you can help to clarify this too? What's the relationship between the 'global' port egress setting and those specified on a per-VLAN basis in the 'VLANs' tab? It's my understanding that once entries are in that table, then egress is totally defined by the settings there and the global setting is ignored in all circumstances ‒ is that accurate?

The documentation for the port settings in the VLANs tab reads:

Each port has individual VLAN header options for each VLAN ID. Depending on VLAN mode if lookup is done in this table, egress action of packets is processed by this option. Egress option from VLAN tab is ignored.

The bit that I don't totally follow in this is the part which says 'Depending on VLAN mode if lookup is done in this table'. I had thought that the port's VLAN mode only has an effect for ingress packets, not for egress (from the documentation description again). What is the condition it's specifying here for egress packets to be processed by the options in the VLANs table?

Thanks again for your help so far.

EdPa, thanks for the explanation. A couple suggestions to pass along to the software people. Any chance of making the VLAN and VLANs tabs look and operate the same between the CSS326 and the CSS106 & RB260GS. I have both types of switches and it is annoying to have to think quite differently between the two different switches with the same software version. In my opinion, the way it is on the CSS326 makes more sense. Although that could be improved so it makes more sense.

Last point. This quote from the Wiki about the VLANs page:

Ports Each port has individual VLAN header options for each VLAN ID. Depending on VLAN mode if lookup is done in this table, egress action of packets is processed by this option. Egress option from VLAN tab is ignored.

Looking at the last sentence. If the Egress option on the VLAN tab is ignored, why is there even an option there?