@krzysztofmaciejewskiit wrote:
If the port is in access mode, the switch should remove the tag if a tagged frame arrives, so this may actually solve the problem.
Actually, a host can send a VLAN tagged frame, with VLAN ID 0, just for CoS usage (on an access port).
What I recommended earlier, on the C1300, ignores using any L2 CoS, however, in theory, since you're doing L2 forwarding "upstream", a non-zero CoS could be sent "upstream".
Personally, I would have the "upstream" device just ignore any L2 CoS (which, I usually recommend, L2 CoS never be used unless you have a need for a QoS tag and cannot use the L3 ToS [which smart L2 switches often can].)
If you really want to insure a frame passed "upstream" has a zero CoS value, since you're using a trunk, which implicitly has a L2 CoS value, we might be able to force the CoS to a zero value upon egress.
Going down to an end-host might be a bit more dicey, as I'm unsure a host not expected a VLAN tag, just for its CoS value, would accept it at all. (On the C1300, the recommended global settings would ignore using the CoS value, if any.)
BTW, I perhaps I should have asked earlier, but actually I wouldn't recommend what you want to do. Instead, I would recommend a QoS policy that sets meaningful tags and QoS processing policy. Which might be very few legitimate none zero tags and all treated alike. This last may seem identical to what you want to do, and effectively it should be, but it sets a framework for QoS modifications. For example, say you add VoIP to your network. With your approach, you may have a mad scramble to support it effectively after creating a whole new revised QoS approach, vs. only VoIP packets will be tagged DSCP EF but given BE treatment becomes DSCP EF tagged packets (already in placed which only can be VoIP) are to be prioritized.
