QoS Policy question, default class set to af43

[wilson_1234_2]

I have a question about a QoS policy with traffic prioritized in a way I am unfamiliar with. The classes are marked with access-lists, but the class-default is set to dscp af43.

I am wondering if the fair-queue setting would affect how the traffic would be prioritized with this policy.

Would all other traffic be higher priority than Signal af41 and Data Af33 (aside from the Voice)?

policy-map QoS-For-VoIP

class QoS-Voip

  priority percent 60

  set dscp ef

class QoS-Signal

  bandwidth percent 4

  set dscp af41

class Data

  bandwidth percent 5

  set dscp af33

class class-default

  fair-queue

  set dscp af43

!

We have a lot of replication traffic that is in the Data queue, but there is some traffic in the Class-default queue that does not seem to be getting priority over the Data traffic.

[John Blakley]

I wouldn't configure the class-default this way unless told to do so for some reason. The AF classes have the drop probabilities, but the receiver needs to be configured to handle the marking. AF43 may be dropped before AF41, but that doesn't necessarily mean that it will due to configuration on the receiving side (they may want to drop AF41 instead).

Class-default is usually set to dscp 0, so I'm not sure what the thought was behind doing it this way. Have you spoken to the provider to see if they would understand why? If you're using an ISP for your MPLS provider, they should have 'packages' that would tell you what to mark your traffic as. I would check the service that you have with the provider to see if they want you to mark any traffic as af43. If not, then they're probably remarking your traffic inbound to default anyway. If all of your connections are P2P, then it depends on what you're doing with the traffic inbound that's marked as af43.

HTH,
John

*** Please rate all useful posts ***

[wilson_1234_2]

It was set this way before I got here with the thought that the Data traffic is replication and everything else should have higher priority that replication traffic.

I guess it was easier than configuring ACLs.

But, I am not sure how it would be dropped by the receiver, if the class was specified to be af43, wouldn't the receiver see it as such?

The carrier should see the traffic as it leaves the sending router as af43, the carrier I am thinking doesn't care as long we tell the packets what to be.

Is this not correct? (The carrier does not remark the packets and honors what we mark them).

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I am wondering if the fair-queue setting would affect how the traffic would be prioritized with this policy.

Yes.  (Also depends on whether platform is pre or post HQF.)

Would all other traffic be higher priority than Signal af41 and Data Af33?

"It depends" - it would be up to follow-on devices to determine relative treatment based on marking.

[John Blakley]

No, generally the carrier will not honor a marking that you set if you don't have a service that supports the marking. They have to prioritize the traffic in their network, so they'll usually remark it to defaul to give others priority if they do pay for the service.

You could test this concept by creating another policy matching on dscp 43 inbound on a remote router. If you don't get any hits, you can be assured that the carrier isn't keeping your marking.

Sent from Cisco Technical Support iPhone App

[wilson_1234_2]

We do have the service from the carrier, so they should be honoring all packets we mark as af43.

My understanding is that once we mark the packets, the carrier doesn't know that it came from the Best Effort Queue, all they know is they are recieving packets that are af43.

We are paying to have the service that they will prioritize this traffic, so it should be carried through.

But, I was thinking that the fact that it is the best effort or class default queue, we could be affecting how it is prioritized befre the carrier sees the traffic. Also, I wasn't sure about the fair-queue setting in the class and how it could be affecting it.

I do see a ton of drops in the class-default queue, not near as many in the Data queue (supposedly a lower priority)

JosephDoherty mentioned that fair-queue could be affecting the policy.

What are your thoughts on this?

[John Blakley]

Joseph is great with QoS. Fair-queueing will help identify flows in the class-default queue and determine which packet goes out next within the queue.

The fact that you have the service, and the ISP honors af43 as a marking, is a good thing. So, in effect, what I believe whoever configured this is trying to give some preference to anything that's not matched in your classes that are attached to the policy.

class QoS-Voip

  priority percent 60

  set dscp ef

class QoS-Signal

  bandwidth percent 4

  set dscp af41

class Data

  bandwidth percent 5

  set dscp af33

class class-default

  fair-queue

  set dscp af43

Basically, your voip class gets 60 percent of the bandwidth. Let's assume it's a 10Mb circuit. That means that if any voice traffic is going through, it gets 6Mb of that. That leaves you with 4Mb to work with (I'm assuming 100% of the interface bandwidth. It could be 75%, but I think that's changed with post-HQF and Joseph can verify). Call Signaling would get 160k, data gets 200k, and class-default doesn't get a guarantee.

Supposing that your ISP gives AF43, AF41, and AF33 drop preference respectively. (The treatment is based on the receiving node and how they want to treat it.) AF41 is technically less likely to be dropped than AF41, and AF33 would more likely be dropped than both of the other two. The AF assignments are 11,12,13,21,22,23,...up to 41,42,43. The first number is lower priority to higher 1 < 2 < 3 < 4 in preference. The second number is the drop probabilitiy where 1 is less likely to be dropped than 2 and 2 less likely than 3. For this example, AF33 is more likely to be dropped than AF43 because of the first value of 3 vs 4. (Does that make sense?)

This is the RFC though, and providers don't have to honor this and can change it at any time, but this is where they tell you what to mark and how they're going to treat it. You are correct in that your provider doesn't know anything about your queues, and your queues are local to your router. It helps the router to determine what to send out to the wire next. Your class default is anything that doesn't match in your other classes. You don't have a guarantee for your default class, so it will get what it can. If the provider stated that they guarantee 15% of your bandwidth to AF43, then you'll get 15% through their network (of your cir) from anything that's coming through your default class.

HTH,
John

*** Please rate all useful posts ***

[wilson_1234_2]

Correct, what yoy are saying makes sense.

what was attempted is to class the voice and prioritize it , class the Data and prioritize it (making sure it is lower than anything else) and then everything else, which would be user traffic to anything would be higher than the Data traffic (replication).

The goal was to ensure that the replication traffic does not take precedence over user traffic.

The problem is we are having issues with come traffic that spans the WAN that should be getting priority over the replication traffic, but it is not.

The replication traffic seems to be sonsuming the link and the traffic needing priority (ties to a higher priority service) is getting squeezed out.

When the replication traffic is halted, the other service in the af43 queue recovers.

Also when the replication traffic is halted, the BW utilization on the link drops down to probably 25% utilization. So it seems the af43 queue is not getting prioritized.

[John Blakley]

Personally, I'd go for creating another queue called users and giving it a bandwidth guarantee. You could then tag your traffic there. If you aren't wanting your replication traffic to consume all of the bandwidth (I'm assuming that this replication traffic is in the Data class), you could put a shaper in the Data class under the policy-map that caps the traffic. Then you wouldn't have to worry about it starving other queues. Going back to the 10Mb circuit example:

class QoS-Voip

  priority percent 60

  set dscp ef

class QoS-Signal

  bandwidth percent 4

  set dscp af41

class Data

  shape average 2000000  <--- shape the class when it gets to 2Mb

  bandwidth percent 5

  set dscp af33

class Users

  bandwidth percent 20   <--- guarantee 800k

  set dscp af43

class class-default

  fair-queue

bandwidth percent 11

Your bandwidth guarantees don't equal 100 though. You could play around with those numbers as well. There's nothing wrong with giving a guarantee to the default class even though you're not marking the traffic.

The problem with the shaper is that it will always be enacted regardless if there's anything in the other queues. This is where you could get into time ranges with your acls, etc, but that's another topic I think. You could have a class that matches on an acl with a time range and shapes this traffic back during the hours of 8 - 5pm, and then after 5 it's allowed 100% of the link if you wanted.

HTH,
John

*** Please rate all useful posts ***

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

The goal was to ensure that the replication traffic does not take precedence over user traffic.
The problem is we are having issues with come traffic that spans the WAN that should be getting priority over the replication traffic, but it is not.
The replication traffic seems to be sonsuming the link and the traffic needing priority (ties to a higher priority service) is getting squeezed out.
When the replication traffic is halted, the other service in the af43 queue recovers.
Also when the replication traffic is halted, the BW utilization on the link drops down to probably 25% utilization. So it seems the af43 queue is not getting prioritized.

It would help if you described your WAN topology, your WAN vendor's QoS, also your platforms and IOS versions being used.

Even if your link was a dedicated lease line, without knowing the platform and IOS, we don't know exactly how your policy will behave.  Non lease lines, such as clouds that support QoS, add many additional variables.

[wilson_1234_2]

I am trying to get confirmation on what the provider is actually doing as far as QoS goes.

Here is the platform and version of the routers invbolved:

(C3845-ADVIPSERVICESK9-M), Version 12.4(23)

The topology is a typical MPLS cloud with the above CE router connected to PE routers.

Assuming the provider would leave all marking as we have applied them and everything is prioritized accordingly.

What are your thoughts on prioritizing the default queue this way?

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

What are your thoughts on prioritizing the default queue this way?

Difficult to say as I don't know what a "typical MPLS could" is.  I've worked with multiple MPLS vendors, each having their own quirks.

If you're using the cloud for multipoint, vendor's QoS is very important.  My experience is, besides differences in QoS support between MPLS vendors, often a single MPLS vendor offers different QoS models.

What's the bandwidth, and media, to/from the cloud on both sides?  Are there any soft are hard bandwidth caps to/from the cloud (both sides)?

[wilson_1234_2]

I am trying to get the QoS information from the vendor. Typical MPLS is all I have for a description at the moment, they give us a circuit and we can reach all of our sites. That is all I know for now.

The BW is DS3 handoff and there are no hard\soft cap.

The links are heavily utilized and QoS will be queueing. We have a subnet that connects to a database and it is sensative to delays. When the link is fully utilized, they have problems. They are in the default Queue, that should be prioritized over the Class Data Queue.

The Data Queu is utilizing the majority of the BW. So, I am thinking either the provider is not prioritizing the way the original designer thought, or we have a problem with the way we are applying the policy.

UPDATE:

I just got a crtical piece to the puzzle, the provider is prioritizing EF, AF31, AF11 and everything else is BE.

So Voice is getting prioritized and everything else, per the policy we have in place is BE across MPLS.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

The far side is a DS3 too?

Often MPLS vendors will offer some committed bandwidth across their cloud, one of the major MPLS vendors calls it CDR (committed data rate).  They also might have special rules for real-time bandwidths and what happens if you exceed those.  Your vendor should be able to provide documentation about their QoS offering, and tell you what you've contracted for.

I'm surprised our vendor is prioritizing AF11.  CS1 and/or AF1x might be deprioritized relative to BE.

When working with MPLS, you can have QoS policies that manage your egress to the MPLS cloud different from what the cloud's QoS supports for managing cloud egress.  (NB: they don't have to differ, but often MPLS could QoS options are limited.)

[wilson_1234_2]

This is what I have from the provider:

"we maintain all markings as long as they are EF, AF31, and AF11 (and 0/BE of course).  Anything not marked with those values will be remarked as BE. Each class can have the full port if there is no contention by a higher class"

Yes the remote side is DS3 also.

Per your comment:

"When working with MPLS, you can have QoS policies that manage your egress to the MPLS cloud different from what the cloud's QoS supports for managing cloud egress"

Even if we do this, wouldn't the traffic all (other than voice) pretty much be BE once it hits the cloud with what the provider has said? If the DS3 is fully congested, would us marking the traffic (when the provider treats it as BE) make a difference?

And, per the provider's comments, I should be able to create a class, mark it as AF11 and put the delay sensative traffic in it and it should help, correct?