Hello,

I realized a rather straight forward setup of connecting two switches
Switch1: TP-Link SG3452
Switch2: CSS610-8G-2S+ (SwOS 2.18)
over a trunk port.
To be more precise I build a LACP of 4 ports and configured this as a trunk to transport only tagged VLANs.
Routing is done by a PFSense connected to Switch1.
For simplification Switch2 can be seen as an extension to get some more access ports or even connect a server by 10G.

After some time I got that to work and the traffic flow I see makes totally sense:
I am able to monitor traffic passing the LAG/Trunk
- on Switch1-side
- on Router-side
- on Switch2-side

BUT there is one open point I tend to call a bug on SwOS side or missing understanding on my personal end.

Monitoring EGRESS traffic of the trunk on switch2 (MT) does not show VLAN IDs at all.
That's weird esp. because on the corresponding INGRESS of switch1 (TPLink) the VLAN IDs are present.

Whereas watching INGRESS on switch2 (MT) shows VLAN-IDs as expected - as EGRESS of switch1 (TPLink) also has it.

I can't get around calling this a bug on SwOS side because it seems to be very unlikely that the EGRESS really misses the VLAN ID because:
1) switch 1 shows VID
2) My config on switch2 (MT) should prevent untagged traffic at all 3) traffic arrives tagged on my router

Does have anyone an explanation for this scenario or should I raise a bug report toward MT?

Thanks and best regards,
HF

A likely explanation is that the port mirror or monitor function is applied BEFORE the VLAN tag operation. On Cisco, for example, they have a command to force this:

For local SPAN, outgoing packets through the SPAN destination port carry the original encapsulation headers—untagged, ISL, or IEEE 802.1Q—if the encapsulation replicate keywords are specified. If the keywords are not specified, the packets are sent in native form.

From https://www.cisco.com/c/en/us/td/docs/s ... rspan.html.

Hello robertkjonesjr ,

thanks for your reply but I don't think your hypothesis can fit here.

Your explanation would be more likely if I would monitor the access port I think.

As far as I read/understand the packet flow:
- The packets get tagged correctly with VID 101 while it enters the access port [2], e.g sent by "Raspi"
- afterwards it gets passed to the trunk port that is monitored and furhter to the other switch
Let's assume for a second the access port would NOT tag the packet but the trunk (after it splits the monitoring part): How could the trunk port "know" what VLAN to assign?
IF (and that's a very hypothetical "IF") the trunk would tag it, I would expect it uses his default VLAN 999.
But I see the packets are correctly tagged with 101 on INGRESS of switch1 (TPLink).

Am I missing something?
Any other ideas?

Thanks for your help!

BR,
HF

Frankly I don't know *exactly* what is happening inside the Mikrotik switch chip (there are many in use across the product line, anyway), but there is a short discussion here https://community.cisco.com/t5/switchin ... -p/4080689 around what is happening with Cisco and tagging that does not match your model. Could the traffic flow and behavior from different switch chips be different? Absolutely.

I have an HP/Aruba switch that behaves as you describe - trunk mirror does not show tags, but the real trunk port does have them. For Cisco port mirror, I always prefer to use the encapsulation replicate command to be sure I have the tagged frames. The interpretation here, for me, is that other platforms will show the same exact symptom but have a configuration around it. Another solution I often use is to implement a tap device to avoid the whole issue - get the frames off the actual wire to reduce the ability of these types of issues to impact the observation as it is often harder to troubleshoot when the observation is incorrect. I just checked and on a 4011 at 7.14.1SW using the switch mirror functionality on a trunk port (from a bridge config), I see vlan tags on egress through that mirror port (which is your expected behavior, I believe).

This assumes you are capturing correctly, too - Intel adapters usually require a registry setting in Windows to NOT strip the tag even in promiscuous mode; USB adapters on Windows often need a configuration change to show tags too, in my experience. Since you can see vlan tags at least sometimes, it makes me think this is not the issue but you never know - one could be using different adapters to bring in the different traffic flows and run into this.

Hello robertkjonesjr,

thanks again for your detailed thoughts.
In the beginning I indeed faced some additional challenges trying to monitor the switch on the same wire where also network traffic is passed over.
To circumvent this problem I just added another LAN adapter just for monitoring and disabled IPv4/IPv6 on host side.
I also played around with port isolation but in the latter scenario it did not make any difference though.
So far I tend to file a bug towards MT.
Either it is really a bug and can be fixed or the developers probably explain if/how/why this is intended behavior.

Thanks again for your time and feedback!

BR,
HF