cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
406
Views
0
Helpful
3
Replies

Questions regarding IPP and QoS Markings

Mitrixsen
Level 1
Level 1

Hello, everyone.

I have a few questions regarding QoS.

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

    Mitrixsen_1-1735038748411.png
  2. Why are packets like OSPF marked by default? These markings don’t really do much if QoS isn’t implemented, or?Mitrixsen_3-1735038777605.png

    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:

    EF - 46 - 101011 - IPP 5
    AF4 - 100 - IPP 4
    AF3 - 011 - IPP 3  and so on...

That's all, thank you.

David

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

View solution in original post

3 Replies 3

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

These are default Classification, you can change the class where all control plane can be class as EF but I dont recommend it.

qos-1.png 

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

Spoiler