cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1924
Views
5
Helpful
3
Replies

Some UCS QoS Default behavior questions

joel.cason
Level 1
Level 1

I'm trying to better understand how the default QoS behavior in UCS interacts with newly configured QoS policies.

 

1. My understanding is that the default behavior out of the box is that under congestion, FC traffic will get 50% of bandwidth and has no drop, and eth traffic will get 50% of bandwidth with drop.  This is the default behavior without configuring any QoS policies or applying to vHBAs or vNICs.  Is this correct?

 

2. There is an option of assigning a QoS policy to a vHBA.  Is there a reason to do this other than if you want to give different vHBAs different QoS policies?  In other words, as long as it is a vHBA it will get the % bandwidth and no drop from the system Fibre Channel class.  Is this correct?

 

3. If service profiles are configured in this default manner (meaning system policy is 50% FC and 50% best effort and there are no QoS policies applied to vNIC/vHBAs), will an adjustment of the best effort QoS class or FC class affect traffic for them?  Say I enable new QoS classes of service and adjust bandwidth so that FC only gets 30% of bandwidth and best effort gets 5% of bandwidth.  What will happen to traffic under contention?

 

4. Related to #3, is it understood that any eth vNIC with no QoS policy attached will default into the best effort bucket?

1 Accepted Solution

Accepted Solutions

Evan Mickel
Cisco Employee
Cisco Employee

1)  Your understanding is correct for the default behavior.

 

2)  There is no reason to adjust that, you also will not be allowed to adjust it, UCSM will throw a config failure.  Finally only one no-drop QoS class can exist and it will need to be the FC policy which will be applied by default.

 

3/4)  Defaults are Best Effort and FC, so changes to them will effect vNICs that are not set.

 

 

I think that basically covers your questions but reach back out for any further clarification and I can likely track down an answer for you.

 

 

 

 

Thanks!

View solution in original post

3 Replies 3

Evan Mickel
Cisco Employee
Cisco Employee

1)  Your understanding is correct for the default behavior.

 

2)  There is no reason to adjust that, you also will not be allowed to adjust it, UCSM will throw a config failure.  Finally only one no-drop QoS class can exist and it will need to be the FC policy which will be applied by default.

 

3/4)  Defaults are Best Effort and FC, so changes to them will effect vNICs that are not set.

 

 

I think that basically covers your questions but reach back out for any further clarification and I can likely track down an answer for you.

 

 

 

 

Thanks!

Thanks Evan that is very helpful.

 

With respect to my last scenario and your last answer, in order to not impact existing servers with Best Effort when implementing a new QoS scheme other than default, we would need to first put QoS policies in place on all vNICs and then properly set the QoS System Classes?  Does this sound right?

 

A couple of follow up questions.

 

1. Does setting a QoS policy (or changing a QoS policy) on a vNIC for an active server result in a reboot required situation?  Or will this happen non-disruptively?

 

2. It is possible to set QoS policies for non-enabled traffic classes.  E.g. I can create a QoS policy for Silver and attach it to a vNIC even though the Silver class is not enabled in System Class.  What is the expected effect here?  Will the non-enabled class default to Best Effort until it is enabled?

Any vNICs that do not have a QoS policy assigned would default to the Best Effort class.  We also know that any QoS polices that are implemented and mapped to a disabled system class will default to Best Effort (see below for details.)  Therefore you could arrange the QoS policies on your vNICs before or after enabling the system classes, it shouldn't make any difference.  If you do make changes to the Best Effort class, it would be implemented on all vNICs without a policy, or with a policy mapped to a disabled system class.

 

 

1)  It should not be a disruptive change, though there are several instances that we've encountered in the past that have seen changes that should not require reboots require a reboot.  In corner cases changes that require a reboot will not flag one, then a subsequent change is made, the system is re-analyzed, it will then note the previous change and flag the server for reboot.  This is just a caveat as we have seen this in the past, the follow up item here is that as long as you have the system set to user-ack, the server will sit in a pending reboot state until you acknowledge it and manually reboot.

 

2)  See below:

Disabling a QoS System Class

You cannot disable the Best Effort or Fibre Channel system classes.

All QoS policies that are associated with a disabled system class default to Best Effort or, if the disabled system class is configured with a Cos of 0, to the Cos 0 system class.

 

Documented Here:

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/sw/gui/config/guide/2-2/b_UCSM_GUI_Configuration_Guide_2_2/b_UCSM_GUI_Configuration_Guide_2_2_chapter_010100.html

Review Cisco Networking products for a $25 gift card