cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3572
Views
10
Helpful
14
Replies

QoS/CoS on a L2 Switch

lamav
Level 8
Level 8

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

1 Accepted Solution

Accepted Solutions

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?

View solution in original post

14 Replies 14

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

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

interesting points chaps.

Francisco.

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

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

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.

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

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?

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

"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.

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

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.)

Joseph:

LOL, I know. Go check out my post on that thread.

Victor

Victor, but my post to you is 7 minutes before yours to the other thread. ROFL

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: