I have a 3750 L2 switch that has a QoS policy on it that seems peculiar. This switch is not in production; it's sitting in a lab.
Anyway, it seems as though the person who created the configs wants to apply a QoS policy on an L2 switch that should be applied to an L3 switching/routing engine instead.
This is what I mean:
Attached are the pertinent configs for the L2 access switch, including QoS.
So, what seems peculiar to me is that these class maps are using L3/L4 ACLs to match traffic, but this is an L2 switch. The switch is not going to examine IP or TCP headers. It will make a forwarding decision bsed on L2 header information. I would think that these configurations would be valid fo application to a routed interface....
Am I missing something?
Victor, guess what I'm trying to say, "book" descriptions tend to be black and white but the real world sometimes comes in many colors (or perhaps many shades of grey). In other words, other than the basic distinction of a L2 switch being a multi-port bridge that forwards frames, and a L3 switch routing packets, other features are really up to the vendor. So, if a vendor wants to provide what we normally think of as L3 features in a L2 switch, there's no reason they can't or shouldn't.
If you think of it, other than the problem of providing some L3 features into a L2 switch, why not address L2 port congestion based on L3 ToS? Actually makes more sense rather than mapping L3 ToS into an optional L2 CoS which can't contain the complete L3 ToS.
Consider WAN links that have LAN Ethernet handoffs, e.g. Metro Ethernet. They're "sold" as providing all the simplicity of Ethernet, yet they're more likely to have WAN congestion issues rather than LAN congestion issues. So, wouldn't it be nice to tap into L3 QoS while doing just L2 forwarding?