12-24-2024 03:13 AM - edited 12-24-2024 03:14 AM
Hello, everyone.
I have a few questions regarding QoS.
With IPP, a lot of my resources say that values 6 and 7 are reserved. However, there doesn’t seem to be anything preventing me from using 6 and 7 in IPP to mark my traffic
3. Why were Class Selector markings even created? If the idea is to provide backwards compatibility with IPP-enabled devices, wouldn’t the other DSCP values already achieve that?
If an IPP device was to read a packet, it would only check the first 3 left-most bits of the ToS byte, or not? So:
That's all, thank you.
David
Solved! Go to Solution.
12-24-2024 06:25 AM - edited 12-24-2024 10:43 AM
#1 is a logical restriction, as both are set aside for network operations.
#2 A routing protocol is considered part of network operations, non emergency, so an IPPrec 6 is correct.
Correct, if there no active QoS, such marking, or ANY marking, has no value, but if such packets are subject to QoS, the correct marking is already in place. So, what benefit is there to not marking?
#3 Correct, IPPrec only uses the first 3 bits of ToS, but other bits within the ToS had QoS meanings too. See RFC1349.
As to backward capability, not exactly, the DSCP model is different, but it's first 3 bits might be used keeping in mind IPPrec, but something like the "scavenger" RFC, using CS1, breaks IPPrec prioritization.
12-24-2024 06:25 AM - edited 12-24-2024 10:43 AM
#1 is a logical restriction, as both are set aside for network operations.
#2 A routing protocol is considered part of network operations, non emergency, so an IPPrec 6 is correct.
Correct, if there no active QoS, such marking, or ANY marking, has no value, but if such packets are subject to QoS, the correct marking is already in place. So, what benefit is there to not marking?
#3 Correct, IPPrec only uses the first 3 bits of ToS, but other bits within the ToS had QoS meanings too. See RFC1349.
As to backward capability, not exactly, the DSCP model is different, but it's first 3 bits might be used keeping in mind IPPrec, but something like the "scavenger" RFC, using CS1, breaks IPPrec prioritization.
12-24-2024 06:29 AM
These are default Classification, you can change the class where all control plane can be class as EF but I dont recommend it.
12-24-2024 07:10 AM - edited 12-24-2024 10:51 AM
"These are default Classification, you can change the class where all control plane can be class as EF but I dont recommend it."
Or you can change the marking to whatever you want, but traffic that's marked IPPrec 6 or 7, I agree, shouldn't be changed.
Since, @MHM Cisco World mentioned EF marked traffic, which is usually given priority over ALL other traffic, it begets the question should it have priority over IPPrec 6 and/or 7? In fact most QoS literature doesn't spend much, if any time, discussing those markings. At least the table @MHM Cisco World provided does have routing as CS6. But what's CS7/IPPrec7 used for and should such traffic (and/or 6) be QoS treated?
I'll not answer my last question as it's not germane to OP or, I believe, useful for passing the QoS examination. However, if you ever want to effectively, and correctly, use QoS, it's worth understanding.
I will say, consider if something like OSPF hellos are lost on a congested interface, what happens?
On many Cisco platforms, even when there's no explicit QoS, there's implicit QoS, in PAK priority (additional information left as a student exercise).
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