ā04-13-2010 07:36 PM - edited ā03-06-2019 10:36 AM
Why do switches map CoS or IP-Precedence numbers to DSCP vlues when trusting ingress frames based on CoS or IP precedence?
"When trusting CoS or IP Precedence, Catalyst switches map an ingress packet's CoS or IP-Precedence to an internal DSCP value."
ā04-13-2010 07:54 PM
Hi,
I'm not sure that I understand your question, but you want to know why CoS or IP precedence is copied to DSCP?
It's because DSCP is the new format, provides you with more flexibility in QoS.
Previously only 3-bits were used from the IP packet field and now there are 6 fields used by DSCP giving you 64 classes.
DSCP is backwards compatible with IP precedence.
Switches can trust incoming frames from IP phones for example when using VoIP.
If this is not what you were asking please clarify.
Federico.
ā04-13-2010 08:01 PM
Federico:
What you are saying is somewhat inaccurate. It is true that DSCP is more granular than CoS , but that's not the reason that CoS values are translated into DSCP. CoS is used for devices that operate in Layer 2 and use dot1q or ISL trunking. That is where the CoS value is located.
DSCP, on the other hand, is used for applying QoS policies to IPv4 packets that have the QoS markings in what used to be the TOS byte. And, yes, IP Prec is less granular than DSCP, which is the newer standard.
Victor
ā04-13-2010 08:05 PM
Lamav, you said, "DSCP, on the other hand, is used for applying QoS policies to IPv4 packets that have the QoS markings in what used to be the TOS byte"
You say, "in what used to be the TOS byte"
Where is the DSCP value now?
ā04-13-2010 08:11 PM
The TOS byte of the IP precedence model as defined in RFC 791 and 1349 are outdated. The replacing model as described in RFC 2474 uses the Differentiated Services Code Point value and the explicit congestion notification field.
So, its the same BYTE's worth of information, but it's divided differently.
HTH
Victor
ā04-13-2010 07:56 PM
The CoS value will be mapped to an internal DSCP regardless of whether the port is trusted or not.
If the port is not trusted, the CoS value in the dot1q or ISL header will be mapped to the default DSCP value for an untrusted port, which is 0 by default.
If the port is trusted, the CoS-to-DSCP map will be used to translate the CoS value to an internal DSCP value.
The internal DSCP value will be used for matching policy statements that are used for policing and marking.
HTH
Victor
ā04-13-2010 08:02 PM
What's the difference between using CoS and DSCP? Do they differ based on just the amount of levels of classification?
When would anyone want to use CoS for classification then? Or do you mean it just uses the TOS byte now for classification? I hope I'm not over analyzing this.
ā04-13-2010 08:05 PM
Nelson:
CoS is used for devices that operate in Layer 2 and use dot1q or ISL trunking. That is where the CoS value is located. LAN QoS uses CoS values.
DSCP, on the other hand, is used for applying QoS policies to IPv4 packets that have the QoS markings in what used to be the TOS byte.
ā04-13-2010 08:10 PM
The DSCP is in the TOS byte (as well as the IP precedence).
The difference is the amount of bits used for classifying.
The TOS byte is part of the IP header, take a look:
http://www.erg.abdn.ac.uk/users/gorry/eg3561/inet-pages/ip-packet.html
The CoS as Lamav said, is for L2 devices (i did not mean to say otherwise).
Federico.
ā04-13-2010 08:13 PM
Federico, sorry if I misunderstood what you were trying to say.
ā04-13-2010 08:15 PM
No problem!
Thank you very much lamav ;-)
Federico.
ā04-13-2010 08:12 PM
I appreciate the responses, thank you, gentlemen. My questions ave been answered.
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