cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
693
Views
5
Helpful
8
Replies

Nex 9300 QoS config-- IPP or also DSCP config?

Hello.

GOAL: Configure QoS on a LACP port channel so that a specific layer 3 circuit is given precedence above all other non-control traffic.

GIVEN: Within link Cisco Nexus 9000 Series NX-OS Quality of Service Configuration Guide, Release 9.3(x) - Configuring Marking [Cisco Nexus 9000 Series Switches] - Cisco
there exist configurations for both IP Precedence (IPP), and also DSCP.

QUESTIONS:

1. to attain the goal, may I just execute an IPP config as explained in the link, or must I also execute a DSCP config?

-- After I create config, I will list it here. May you please review it when posted?

Thank you.

8 Replies 8

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

to attain the goal, may I just execute an IPP config as explained in the link, or must I also execute a DSCP config?

From the config guide you posted:

Marking is a method that you use to modify the QoS fields of the incoming and outgoing packets. The QoS fields that you can mark are IP precedence and differentiated services code point (DSCP) in Layer 3. 

So, you need both.

HTH

Joseph W. Doherty
Hall of Fame
Hall of Fame

You goal might not be automatically accomplished using either IPP or DSCP nor might either be needed to accomplish it.

I suspect the usage of IPP and/or DSCP, and its role within QoS, might not be totally clear to you.

IPP and DSCP are recommendations to how to use part of the IP packet's ToS octet.  DSCP is the newer recommendation, but, by design, it's somewhat backward compatible with IPP.

The ToS octet is just for efficiency.  Rather than every device doing deep/extensive analysis of a packet's contents, to determine QoS treatment, it's a "tag" that can be examined, "short circuiting" the need to re-do packet analysis.

For example, rather than every hop doing deep/extensive analysis to determine if a IP packet is a VoIP bearer packet, the device can look at the ToS octet and for packet's with a specific marking, provide QoS treatment suitable for VoIP bearer packets.  (BTW, VoIP bearer packets would normally be tagged with either IPP 5 or DSCP EF, the latter also sharing the same bit configuration as IPP 5 [backward compatibility].  BGP, I recall, uses IPP 6 or DSCP CS6 [ToS octet would likely look identical, for either, but although IPP will "see" CS6 as IPP 6, they have different settings].)

Again, IPP/DSCP is not needed to QoS, but it's more efficient, so using the ToS is common when doing QoS.

By default, Cisco routers ignore ToS, unless you configure them to use it, for QoS, or other purposes.

By default, older Cisco switches, also ignored ToS unless QoS was enabled, and then they, also by default, usually had a default QoS treatment plan, but they also, by default, erased ToS treating all traffic as IPP 0 or DSCP BE.

By default, newer Cisco switches, use a default QoS treatment plan.

Unsure what a Nexus 9000 does by default, as the Nexus series, often uses different defaults than the Catalyst switches or Cisco routers.  (Some of the Nexus series also had very limited QoS support [as they often work on the assumption, if you have enough bandwidth, you don't need QoS].)

Sure, you can post a config for review, but I would suggest, you might work out a bit what you want to logically happen, and then there can be a discussion how to accomplish that.

Hello Joseph.

My intent is to solve the symptoms in the thread linked here... To remediate the output discards and Rx pause issues, you... - Cisco Community

After investigation, I have concluded that a config change to load balancing is not useful. My strategy is now to change the QoS. Is there something else to look into? What are your thoughts here?

Hmm, I recall (?) seeing that "virtual engineer" recommendation, but don't recall seeing it posted as a response to one of your other postings.

In any case, I would need to study up on the Nexus, particularly your Nexus model's QoS architecture, but in general, I don't agree with many of the "virtual engineer's" suggestions.

Ethernet's flow control, for example, I wouldn't recommend using unless you're pretty knowledgeable about it.  It can easily cause unintended or unexpected side effects.  Some of them mitigated if using a DCB like Ethernet (which the Nexus might support).

BTW, looking at your referenced posting:

8449947 / 8449947 + 367705068529  = a drop percentage of (about) .002 (traditionally, up to 1% is considered acceptable)

31018127 / 31018127 + 407279841508 = (about) .008%

2223093 / 2223093  + 418612402996  = (about)  .0005%

3953256 / 3953256 + 491843996241 = (about) .0008%

BTW, even if the drop percentages are below 1%, that alone doesn't mean these drops are not problematic and/or might be reduced.  Conversely, though, these symptoms might not need resolution.  Insufficient information to say one way or the other.

I fully understand wanting to QoS protect some traffic, but it also easy to have side effects or unintended consequences, if you don't think it through.  For example, IPP5/CoS5/DSCPef, is generally used only for VoIP bearer traffic, but if you assign it for another kind of traffic, will in conflict with VoIP bearer traffic now or in the future?

I mentioned BGP uses IPP6/CS6, which in the IPP model has precedence over IPP5, but do we really need to prioritize BGP updates over VoIP bearer traffic?

Thank you for your insight, Joe (may i call you Joe?).

I agree with everything you've stated.

I told my bosses that the drops are in acceptable range. Also the stress test was 99.93% successful, which I told them seemed acceptable to me. They disagreed and instructed me to fix it. So here we are.

"IPP5/CoS5/DSCPef, is generally used only for VoIP bearer traffic, but if you assign it for another kind of traffic, will in conflict with VoIP bearer traffic now or in the future?"-- It seems to me that in this situation, the VOIP traffic will have equal precedence as this traffic. I am fin with this consequence.

QUESTION: To the best of your knowledge, is there anything besides this point that would cause bad symptoms with this config, such as an internal logic config bug?

---

Please see below reply from Reza Sharifi...

"Reza Sharifi 
Hall of Fame Master

Hi,

to attain the goal, may I just execute an IPP config as explained in the link, or must I also execute a DSCP config?

From the config guide you posted:

Marking is a method that you use to modify the QoS fields of the incoming and outgoing packets. The QoS fields that you can mark are IP precedence and differentiated services code point (DSCP) in Layer 3. 

So, you need both."

---

He states that I "need both" IPP config and DSCP config. You state that I do not. Do you disagree with Reza? (Logic seems to side with you.)

===================

After you have answered the above questions with only the info you had before this sentence, may you please answer below?...

I just now investigated the ports and port-channel where needs this config. I am glad to say that I am now confused-- I thought these interfaces had IP addresses attached to them. They do not. These are all trunk switchports. IP is disabled on these ports.

QUESTIONS:

1. Is the NON-CoS config even relevant here?

ALSO: 2. Should this config be on the "int port-channel 77" or should it only/also live on the two ports that form the port channel?

3. May you please view below config, then suggest what best config should look like?

Thank you.

policy-map type qos match-first MY-MAP-1
class type qos CLASS-MYCLASS-1
set dscp cs5
set precedence 5
set cos 5

"Thank you for your insight, Joe (may i call you Joe?)."

You may.

"I told my bosses that the drops are in acceptable range. Also the stress test was 99.93% successful, which I told them seemed acceptable to me. They disagreed and instructed me to fix it. So here we are."

Without knowing the attributes of your traffic, I cannot say what is, or isn't, truly acceptable.  As I wrote earlier, traditionally, the rule-of-thumb, was, drop rate under 1% was acceptable (BTW, this would be end-to-end).  That rule-of-thumb predates, I believe, interactive and/or real-time traffic requirements.  Personally, I've found most any traffic doesn't have any noticeable issues as long as drop rate doesn't exceed .1%  However, there's a very huge difference between truly dropping every 100th (or 1,000th) packet and an average drop rate of 1%.

Simple example, if told the average latency is 50 ms, is that because individual latencies are 50, 50, 50, 50, etc, or 49, 52, 51, 48, etc, or 1, 99, 7, 93, etc.?  If you see a difference between these, realize same can happen with drops, i.e. an average calculation, alone, often doesn't tell us all we should know.

Anyway, although many consider zero drop percentage, ideal, and any drops at all, "bad", both views can be very wrong!

TCP, by design, uses drops as a flow rate regulator.  Without it, something like a gig port would transmit a whole data stream at the gig rate even though down stream there's a lessor bandwidth link and/or there are other gig senders whose combined traffic exceeds the bandwidth of a downstream link.

As an aside, although some form of flow rate control is critically important, it has been recognized dropping packets might not be the best way to accomplish this.

So, ECN was proposed (using two of the ToS octet's bit's) to convey congestion without dropping a packet.  Never really caught on.

Some of the (later) TCP variants, though, take a much keener interest in RTT.  If they see RTT suddenly start to spike, they assume the flow is encountering congestion.  (See TCP congestion control - look at all the variants trying to deal with this issue!)

Personally, I've long considered "drop management" a key component of QoS, but to manage drops, you need to understand they are sometimes "good", yet the goal is to have a few as possible, while accomplishing our goals.

Hopefully, the above might help you to convince those wanting you to solve the "drops" problem, because, it really might not be a "problem".  (Again, although drops might still happen in the most optimal situation, I don't know how close your situation is to "optimal".)

"He states that I "need both" IPP config and DSCP config. You state that I do not. Do you disagree with Reza? (Logic seems to side with you.)"

I do disagree with @Reza Sharifi on this, because both use the same 1st 3 bits of the ToS.  (Also see DSCP and Precedence Values.)

Normally you would use the newer standard DSCP, but since they overlay their bit usage, I'll still use both in some situations, but not in a manner as your policy is doing (setting both DSCP and IPP).

For example, rather than something like (my syntax might be off) "match IP DSCP CS4 AF41 AF42 AF43", I'll use something like "match IP precedence 4", although the latter also matches IP DSCP 33, 35, 37, 39.

"It seems to me that in this situation, the VOIP traffic will have equal precedence as this traffic. I am fin with this consequence."

Correct, they would have equal precedence, which often breaks VoIP.  But, if VoIP breaking is not a concern, now or in the future, then, agreed, go ahead and use class 5 treatment.

However, VoIP class level (5) traffic is often given absolute priority over ALL other traffic (even routing updates), and because of this, it's sometimes rate limited to preclude this class from breaking ALL other traffic.  If breaking ALL other traffic is also a consequence of no concern, again, go ahead.  ; )

(BTW, I don't know the attributes of the traffic you want to possible provide class 5 treatment for.  I.e. it's also possible, it wouldn't be adverse at all.  For example, often VoIP control traffic is also directed into class 5, but it uses so little bandwidth, it's usually not a problem in that class too.)

"1. Is the NON-CoS config even relevant here?"

Yes, it may be, as most Enterprise level equipment, supporting QoS, can use L3 ToS.

"2. Should this config be on the "int port-channel 77" or should it only/also live on the two ports that form the port channel?"

Depends on the platform.  Over the years, Cisco's IOSs have permitted more and more to be configured on the PC interface, and IOS will apply to PC links as needed.  I.e. it depends on the platform.

3. May you please view below config, then suggest what best config should look like?

policy-map type qos match-first MY-MAP-1
class type qos CLASS-MYCLASS-1
set dscp cs5
set precedence 5 !redundant with set dscp cs5, i.e. you're resetting the same first 3 bits to the same value
set cos 5 !1st assumes VLAN tagged frames - also both this and L3 ToS depend on what QoS treatment, if any, is set aside for this values

BTW, when setting ToS/CoS, big difference whether setting on ingress or egress to device!  Setting on ingress, device usually will use that setting for egress treatment.  Setting on egress, generally devices ignores for that device treatment, but tag passed along to next device(s).

Hello.

Can you please tell me if below QoS config looks correct for my intent? Thank you.

policy-map type qos match-first MY-MAP-1
class type qos CLASS-MYCLASS-1
set dscp cs5
set precedence 5
set cos 5

Set dscp cs5 effectively also sets precedence 5.  I.e. you don't need the latter.

Set cos 5 only applies if you have VLAN tags.  You can do that and setting DSCP/IPP, but if doing the latter, unless your devices cannot process the latter (e.g. some L2 switches), I recommend using just IP ToS.  Also, IP ToS is carried end-to-end, whereas L2 CoS is lost at every L3  hop.

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: