A question about QoS Classification and Marking on L2

[Mitrixsen]

So once we configure an IP phone to be part of a voice VLAN, the phone will automatically mark its traffic as PCP5.

Once a switch receives a dot1q frame with such marking, will it automatically prioritize it over the other frames, or is configuration required for this?

[MHM Cisco World]

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKCRS-2501.pdf

check the boundary and it position in above ciscolive slides 

[Joseph W. Doherty · Accepted solution]

A VoIP phone might, by default or configuration, set L3 ToS.  If possible, convert L2 CoS to L3 ToS (and for VoIP bearer traffic, use DSCP EF).

"Once a switch receives a dot1q frame with such marking, will it automatically prioritize it over the other frames, or is configuration required for this?"

Depends on the switch.  Historically Cisco switches required configuration (in fact, on the old Cisco switches, QoS was totally disabled by default), even if just enabling AutoQoS.  Latest Cisco switches might, by default, provide priority for such marked frames, but something you would want to verify per actual switch.

[MHM Cisco World]

As I know voip never use l3 ToS, simply because it connect to SW that can not read this value, 

The l3 ToS is in ip header and SW is l2 device never read l3 header and hence 

Voip use cos that SW can read it and do QoS 

[Joseph W. Doherty]

"As I know voip never use l3 ToS . . ."

My memory might be faulty (and often is), but I recall many VoIP phones being capable of setting L2 CoS and/or L3 ToS.

". . . SW is l2 device never read l3 header and hence"

True for a "dumb" L2 switches, but often Enterprise level L2 switches are "enhanced" or "smart", i.e. they support some L3 capabilities even without any L3 routing capability (which some now even offer very limited support for that too).  Of course, L3 switches can process L3 info.

[MHM Cisco World]

if the GW of VoIP VLAN is not SVI of SW then SW never see L3 header, and it use CoS. 
and also if VoIP connect to PC and PC send huge data the VoIP taffic will drop in Egree L2 port of SW becasue L2 port check only L2 header not L3 header and if VoIP use L3 header ToS then sure traffic will drop. 
SO 
VoIP use CoS 
SW can use CoS or it can use CoS-ToS Mapping for QoS 
this ensure that traffic when first enter to SW not drop and handle with it CoS value.

[Joseph W. Doherty]

"if the GW of VoIP VLAN is not SVI of SW then SW never see L3 header, and it use CoS."

@MHM Cisco World, as an example of a "L2 switch" working with L3, without an SVI, you might want to read: 2960-X configuring QoS in it, you will see the 2960-X can (QoS) classify using L2 CoS or L3 ToS.  (I chose the 2960-X, as an example, as such capability on "enhanced"/"smart" Cisco L2 switches has been available for a while, I recall [?] such capabilities on earlier Cisco L2 switches.)

". . . also if VoIP connect to PC and PC send huge data the VoIP taffic will drop . . ."

(NB: BTW, would only apply to PCs being on the same VLAN.  That noted, it's a worthwhile point to keep in mind!  Although, I've never seen it happen only because I have never seen large data transfers between PCs (behind VoIP phones), between PCs (behind VoIP phones) and servers, yes, but between PCs (behind VoIP phones), no.  Still it's possible, especially in smaller networks where there might be more peer-to-peer file sharing and/or servers and PCs are on the same VLAN.)

As the data passes through the VoIP phone, the VoIP phone should prioritize its own traffic, i.e. L2/L3 tag shouldn't matter (for VoIP traffic prioritization to the switch port from the VoIP phone).  As seen, in above reference, some "L2" switches can prioritize using CoS or ToS.

"L2 header not L3 header and if VoIP use L3 header ToS then sure traffic will drop."

Agreed (it may), if L2 switch is dumb or "L2 only".

"VoIP use CoS"

It might, but except in the (very rare?) case MHM described, using L2 CoS if you can use L3 ToS, is a PIA.  Remember L2 CoS requires a tagged frame, and needs to be reset every L3 hop.  L3 ToS works end-to-end.

BTW, the general recommendation is VoIP bearer should be DSCP EF, but VoIP signally should be DSCP CS3 or AF31.

Also BTW, since DSCP EF usually gets fantastic QoS treatment, it's a really good idea to "trust but verify" "VoIP" traffic entering your network.

[MHM Cisco World]

 VoIP use CoS (and/or ToS)

SW use CoS not ToS and using default or costume mapping to set the new ToS value 

so as I mention before VoIP use CoS and SW depend on that value. 
it simple rule we try to push boundary to the nearest point to Host.

about the huge data from PC, that normal 
assume PC exhcange TCP packet and TCP packet is near 1500 bytes 
in other hand the max VoIP size is 200-280 bytes 

that meaning around 5-6 frames can pass for only one frame pass from PC, here you must consider PC data when design QoS.

[Joseph W. Doherty]

"SW use CoS not ToS"

Just wondering, did you actually review/skim the reference I provided?  If so, also wondering, is English your native language?

Reason I ask, that reference makes if very clear a 2960-X can work directly with L3 ToS.  If needed, I guess I could pull quotations from the reference and highlight them, or explain what's being described, if unclear.

Where did you pull your diagrams, as it shows a 2950, a rather old (ancient) Cisco switch (EoSale 2008, EoSupport 2013).

Interestingly, it shows VoIP phone marking both CoS (5) and ToS (DSCP EF) as I also described earlier many VoIP phones will do. Diagram also shows lost of the CoS (not unusual - assuming you even has a tagged frame to begin with) and changing the ToS to DSCP CS5 (not a good thing - should have been left as EF).

BTW, the 2950 has two software level, SI and EI, the latter being the advanced version, but even for the SI variant (from

Q. What QoS features does the 2950 standard image (SI) support?

A. The 2950 with the SI supports queuing and scheduling at egress. The 2950 with SI supports ingress classification with use of port trust states in Cisco IOS Software Release 12.1(11)EA1 and later. You can configure the ingress port to trust either class of service (CoS) or differentiated services code point (DSCP), where the default port trust state is untrusted. You can configure egress scheduling as either strict priority scheduling or weighted round-robin (WRR) scheduling.

The following applies to the EI variant.

 Q. Can the Catalyst 2950 series switches mark or rewrite IP precedence (type of service [ToS]) bits in an IP packet?

A. Yes, the Catalyst 2950 series switches that run the enhanced image (EI) can mark or rewrite ToS bits in the header of an IP version 4 (IPv4) packet. Use a policy map that contains the set ip dscp statement. Or configure a policer to mark down or rewrite the differentiated services code point (DSCP) value on frames that do not conform to the rules in the policer.

Q. Can I use access control lists (ACLs) to define traffic for the application of QoS features?

A. Yes, you can use IP standard, IP extended, and Layer 2 (L2) MAC ACLs in order to define a group of packets with the same characteristics. This definition of a group of packets classifies the packets. However, configuration of a deny action is not supported in QoS ACLs on the switch. Also, if there is a match with a permit action, the switch takes the specified action that relates to QoS and exits the list. If there is no match with all entries in the list, then the QoS processing does not occur on the packet. For all Cisco IOS Software releases, this process has support in enhanced image (EI) only. Cisco IOS Software Release 12.1(11)EA1 and later support the match on the basis of the differentiated services code point (DSCP) value.

 As noted earlier, Cisco has, on their "smart"/"enhanced" L2 switches have supported examination of L3 info for some time now.

BTW, I'm not saying you cannot use L2 CoS, just that L3 ToS is generally a better choice, when you can use it rather than L2 CoS.

"about the huge data from PC, that normal 
assume PC exhcange TCP packet and TCP packet is near 1500 bytes 
in other hand the max VoIP size is 200-280 bytes

that meaning around 5-6 frames can pass for only one frame pass from PC, here you must consider PC data when design QoS."

Sorry, I'm lost on the point you're trying to make.

If you're concerned with VoIP and data being fed from a VoIP phone with a PC behind it, again, as also described earlier, the VoIP phone should prioritize its VoIP traffic over traffic from the PC.  (Also, BTW, when using a "softphone" on the PC, that app should have the PC also prioritize its VoIP traffic over other PC traffic.)  Again, VoIP and PC data being injected into the network, should not have any QoS issues.

That noted, once the PC's combined VoIP and data traffic is in the network, every other interface it needs to transit, at L2 or L3, is often a potential congestion point and QoS needs to be considered there.

If your switches can only prioritize using L2 CoS, then that's what you would use.  However, again, if you can use L3 ToS, use it.

[MHM Cisco World]

first I am discussion with one of best, so really I appreciate your time to answer and correct me (alot .... LOL)
I will answer some point here
1- DSCP have many value for VoIP

 

2- why the Cos is Lost, 
Cos depend on 802.1q tag if there is no tag (native VLAN) this CoS will not appear 

3- still I see using CoS is better than ToS even if VoIP support that, because make SW read both L2 header (for forwarding) and L3 for QoS for my view is not right. 
may be I wrong but I make double check this point. 

[Joseph W. Doherty]

"1- DSCP have many value for VoIP"

Yes and no.

DSCP EF has been RFC recommended for VoIP bearer traffic.

VoIP signaling traffic has a recommendation history of using either DSCP CS3 or AF31.  This, I recall (?), due to differences in RFC and Cisco recommendations (I also recall there's another difference between Cisco and the RFC).

Many times, VoIP devices just mark both VoIP kinds of traffic with the same marking, usually DSCP EF.  Usually, this doesn't cause any issues, but the "needs" for the two kinds of traffic are different (actually bearer class easily supports signaling, but signaling doesn't need bearer level of QoS).

"2- why the Cos is Lost, 
Cos depend on 802.1q tag if there is no tag (native VLAN) this CoS will not appear"

Correct, another reason I prefer using ToS, whenever possible.

Also keep in mind, both CoS and ToS are but "shortcuts" to identify a QoS class for processing the traffic.

BTW, interestingly, in theory, you can have tagged frames without a VLAN ID, for the purpose of carrying a CoS.  Unsure whether all network equipment will be "happy" with such frames.

"3- still I see using CoS is better than ToS even if VoIP support that, because make SW read both L2 header (for forwarding) and L3 for QoS for my view is not right. 
may be I wrong but I make double check this point."

It's not really a question of CoS vs. ToS being right or wrong.  It's whatever works best for you!

In my experience, in large to extremely large Enterprises, working with L2 switches that did support L3 analysis, it was much less "headache" to support ToS for QoS.

For example, in your posted diagram, not shown is in that diagram is the packet getting to the other side of the network, where if using CoS, you now need to map DSCP back to CoS (this after having to map the initial CoS to DSCP).  Using ToS alone, again if possible, avoids the concern to do these CoS/ToS conversions.

Further when using L2 CoS vs. L3 ToS, we lose "granularity".  (NB: Remember, ToS used to use IPPrec, 0..7, much like CoS, but this was felt to be inadequate for QoS needs, like supporting a 12-class model, as your recent posting shows).

Having many years experience of very effectively using QoS in the real-world, I have some opinions quite different from "QoS textbooks".

[MHM Cisco World]

"""Further when using L2 CoS vs. L3 ToS, we lose "granularity".  (NB: Remember, ToS used to use IPPrec, 0..7, much like CoS, but this was felt to be inadequate for QoS needs, like supporting a 12-class model, as your recent posting shows)."""
that totally right CoS have limit since it use (as I remember) only three bites.