09-18-2008 12:53 PM - edited 03-06-2019 01:28 AM
Hi:
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?
Thank you
Victor
Solved! Go to Solution.
09-20-2008 04:08 PM
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?
09-19-2008 03:28 AM
Victor, is 3750 correct? If so, 3750s are L3 switches.
PS:
Recently I working another post where device was a 2970, which is a L2 switch but also supported L3 QoS similar to a 3560/3750.
09-19-2008 05:10 AM
as joseph stated this is L3 switch
also with 2950 these ACLs works onthe switchport level because it is L2 switch but has L3/L4 intelegance thrus u can match based on L3/L4 with calss maps
because here u are not routing the traffic
but there is limitation with 2950 that it dose not support ACL with port range u have to put the ports manuly!
for example
if u put on the uplink trust DSCP (this is L3 right) and it is available on 2950 and for sure 3500 and above
u can use ACLs with port numbers and policy map for plicing as well on the switcport level!!
hope this helpful
09-19-2008 05:47 AM
interesting points chaps.
Francisco.
09-19-2008 06:25 AM
for ur information
The Catalyst 2970/3650/3750 does not currently support (true) per-port/per-VLAN policing.
Therefore, access lists are required to match voice and signaling traffic sourced from the VVLAN; these ACLs require the administrator to specify the VVLAN subnet information
09-19-2008 11:50 AM
Hi, folks:
I know that the 3750 is an L3 switch. Ive configured like a hundred of them. :-)
But what seemed confusing to me is that the access ports are indeed layer 2 AND the switch is not activated at L3. It is acting only as an L2 device.
So, I am picturing ethernet frames entering the L2 access port of the switch and having that frame's header examined for forwarding information, not the ip address in the datagram or the L4 application port information. So, it seemed weird that one would configure a QoS policy that would have to do just that....
Can someone explain what I am not understanding or how I should be thinking about this?
Thanks
Victor
09-19-2008 03:53 PM
Victor, it might be it's just as simple that some devices that are unable to perform L3 forwarding (routing) doesn't preclude them from offering features that look deeper into the L2 frame. This is similar to not all L2 switches offer all the same features, best example being those that can be managed and those that can not, but both sill perform L2 forwarding.
09-20-2008 08:41 AM
Joseph:
Im not sure I understand what you're saying.
Anyway, I am surprised that this point is never addressed in documents that describe QoS and how to implement it, etc.
I mean it is after all counter-intuitive to what we have been taught about how L2 and L3 switches operate...
Victor
09-20-2008 04:08 PM
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?
09-20-2008 05:23 PM
hi Joseph
then all the descritions mentioned above agree to i have mentioned ! right?
which is evthough it is a L2 device but iclude L3/L4 intelegance
and this is from cisco :
Cisco Catalyst 2960 Series
Layer 2 switching with intelligent
Layer 2 - 4 services
Cisco Catalyst 3560 Series
Layer 2 - 4 switching and intelligent
services with dynamic IP routing and IPv6
WHILE:
Cisco Catalyst 2940 Series
Standalone fixed-configuration Layer 2
switches with no fan
hope this helpful
09-21-2008 03:09 AM
"hi Joseph
then all the descritions mentioned above agree to i have mentioned ! right? "
Yes, although I suspect what Victor might be having some difficulity with is the difference between pure L2/L3 concepts vs. real world devices. How the latter can blur the former.
09-21-2008 08:38 AM
Marwan and Joseph:
You have both been very helpful and iogical in your approaches to help me understand. I appreciate it.
I haven't configued QoS too many times. Everytime I did, though, it was on an L3 switch, so I have never been confronted with this seeming contradiction until now.
However, there is nothing too difficult about understanding the notion that a switch that is meant to act as a L2 device CAN also do deeper packet inspections of L3/L4 information in the event that a service or protocol structure such as QoS is configured on it, which would require such inspections. And THAT is what Cisco must mean by an L2 switch with "intelligent services."
Am I making sense now?
Thanks, gents.
Victor
09-21-2008 08:53 AM
Victor, yes I think you're making sense. What might have been part of your understanding problem is expecting "pure" when things are "messy". L2/L3, etc., are abstract layers such as seen in the OSI model but we, and vendors, are not really bound to them.
Recently another question was posted in this same forum, somewhat similar to yours. See "LAN, Switching and Routing: layer2, layer3 devices" and Scott's answer for another explanation. (Marwan's post there should look familar.)
09-21-2008 09:02 AM
Joseph:
LOL, I know. Go check out my post on that thread.
Victor
09-21-2008 11:24 AM
Victor, but my post to you is 7 minutes before yours to the other thread. ROFL
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide