I want to perform BASIC QoS on a few ip access-lists, is this enough?

[davebornack]

Keep in mind this isn't the entire config, but can I just QoS based on ip access-lists and matching class/policy maps alone, or do I need to dig way deeper?

Also, is QoS bi-directional in this case (return traffic also treated the same)? Or do I need ACLs for both ways?

ip access-list extended CItrix

 permit tcp any any eq 1494

 permit tcp any any eq 2598

class-map match-any Citrix

  match access-group name Citrix

Policy-map QOS

class Citrix

   set dscp af21

Thanks!!

[Peter Paluch]

Hi Dave,

can I just QoS based on ip access-lists and matching class/policy maps alone, or do I need to dig way deeper?

That depends exclusively on how sophisticated your classification needs to be. If you find ACLs to be sufficiently flexible and matching just the traffic you need to treat specially, by all means - ACLs are perfect.

Also, is QoS bi-directional in this case (return traffic also treated the same)? Or do I need ACLs for both ways?

For each traffic direction, you need a separate ACL, a separate class and policy-map. Your existing ACL matches traffic going to destination TCP ports 1494 and 2598. For return traffic, you would not only need to have an ACL that identifies the responses by looking for source ports 1494 and 2598, but you would also need to enclose this ACL into a separate class-map, and treat the resulting traffic class in a separate policy-map applied to a different network interface (or to the same as the previous one but in the opposite direction).

Just to make sure - your policy-map currently performs marking only. It does not do anything beyond that, so no min/max bandwidth guarantees, priorities, etc. Even though the DSCP is set to AF21, the traffic continues to be handled as best effort.

Best regards,
Peter

[davebornack]

OK, so technically, I'm not doing anything to prioritize these packets, and my config is incomplete?

What I'm gathering form your answer is that I need to apply these to an interface, along with bandwidth guarantees and/or priorities?

My end goal I guess, is to just make sure these packets get processed in the priority that I set them to.  I'm not caring so much about bandwidth, as that I just want the higher priority traffic to have priority, packet-wise.

I completely understand what I need to do to get this traffic prioritized inbound/return.  Thanks.

My apologies, but I'm not great at understanding how QoS.works.

[Peter Paluch]

Hi Dave,

OK, so technically, I'm not doing anything to prioritize these packets, and my config is incomplete?

Yes, that is what I believe. Unless there is some other configuration on the device that was not shown, or there is a different device acting specifically on packets that have their DSCP field set to AF21, your packets get marked but that's all. You are not doing any kind of prioritization.

What I'm gathering form your answer is that I need to apply these to an interface, along with bandwidth guarantees and/or priorities?

That is correct. With recent IOSes, you can assign minimum bandwidth guarantees (using the bandwidth policy-map command), maximum allowed bandwidth consumption (either police or shape, depending on whether you want to drop excess traffic right away or attempt to delay it for later transmission), and - usually used just for a single class - a strict priority using the priority command. Priority classes are dequeued as soon as there is data waiting in them, up to the amount of bandwidth guaranteed by the priority command. However, strict priority classes are intended to be used for voice traffic that needs to be dequeued as soon as possible to minimize the delay and jitter, and are not inteded for use on general data.

My end goal I guess, is to just make sure these packets get processed in the priority that I set them to.  I'm not caring so much about bandwidth, as that I just want the higher priority traffic to have priority, packet-wise.

Unfortunately, I am afraid this is not the way Cisco routers can be configured. Strict priority queueing with multiple priority queues (high priority, medium, low) has been unsupported for years.

I suppose we should start from a different end: If you want to configure QoS then you must have observed some issues with some of your applications, otherwise you would not be looking into this. So let us have a closer look on what issues you have experienced and what do your individual traffic classes need in order for your applications to run smoothly. Then we can translate these requirements into QoS parameters we can configure. Blindly throwing some QoS mechanism on the transit traffic without knowing what it does and what the traffic needs is not going to solve the problems. It's like trying to shoot a moving target with a gun that is itself moving :)

Best regards,
Peter

[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

CBWFQ policies are applied for ingress and/or egress traffic.  I.e. to have a bi-direction policy, you would need to apply the same policy for both "in" and "out".  BTW, CBWFQ ingress policies are command restricted compared to egress policies.

If you use the same policy for both ingress and egress, you would need to insure you'll correctly match your intended traffic.  As you're using ACLs, you could use the same ACL to match the traffic bi-directionally, i.e.:

ip access-list extended CItrix

 permit tcp any any eq 1494

 permit tcp any any eq 2598

 permit tcp any eq 1494 any

 permit tcp any eq 2598 any

BTW, depending on your CBWFQ version, it might support (NBAR) protocol matching Citrix, i.e.:

class-map match-any Citrix

  match protocol Citrix

Also, BTW, some versions of NBAR can match Citrix subclasses, i.e. screen interaction vs. file copying.

As Peter has described, you're policy only tags your Citrix traffic with DSCP AF21.  This, on most Cisco devices, would not treat you Citrix traffic any better than other traffic.  (NB: Conversely, you're not required to use ToS tags to treat traffic differently.)