4

Is it possible to throttle traffic coming or going to a specific ip address on a cisco 877 running : C870-ADVIPSERVICESK9-M, 12.4(15)T12, RELEASE SOFTWARE (fc3)?

Background: we have a WAN where thinclients login using citrix. When a big print job is sent, the desktop sessions suffer. So I would like to limit the traffic with source/destination the print server.

  • thanks both for your very detailed answers. I will try them and both. – natxo asenjo Aug 27 '13 at 9:17
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 14:35
6

What you describe would be something like this:

class-map match-all Printer
 match access-group name Printer
!
policy-map WAN-OUT
 class Printer
  shape average 1000000
 class class-default
  fair-queue
  random-detect
!
int WAN
  service-policy output WAN-OUT
!
ip access-list extended Printer
 permit ip any 192.0.2.0 0.0.0.255

This would match traffic going to 192.0.2/24 and shape it to 1Mbps. However I don't think this is necessarily what you want, what if there is no other demand to the circuit, wouldn't you want print job to get full capacity at that time?

Maybe classify traffic in 3 classes, like

  1. Important
  2. Normal
  3. Scavanger

Configuration could be something like:

class-map match-any Important
 match access-group name Important
 match precedence 4  5  6  7 
 match precedence 1  2  3 
class-map match-any Normal
 match precedence 0 
 match access-group name Normal
class-map match-any Scavanger
 match access-group name Scavanger
!
class-map match-all QOS5
 match qos-group 5
class-map match-all QOS3
 match qos-group 3
class-map match-all QOS0
 match qos-group 0
!
policy-map LAN-IN
 class Scavanger
  set qos-group 0
 class Important
  set qos-group 5
 class Normal
  set qos-group 3
!
policy-map WAN-OUT
 class QOS5
  priority percent 80
 class QOS3
  bandwidth percent 20 
 class QOS0
!
int LAN
  service-policy input LAN-IN
int WAN
  service-policy output WAN-OUT
!

Now in LAN ingress we match on traffic and give it internal qos-group 5, 3, 0, these numbers are insignificant they could be anything, it's just way to differentiate the traffic without mangling the existing CoS/PREC/DSCP bits.

After we've marked the traffic in LAN ingress, on WAN egress we match on the earlier defined qos-groups and treat traffic differently.

Here we give Important traffic 80% low-latency privilege to the capacity. For Normal traffic we give 20% contract, so if Important traffic sends 100% and you start to send Normal traffic, 20% of Important traffic would be dropped in favor of letting some Normal traffic pass. We give no contractual capacity to Scavanger class, it'll only send if either Important or Normal class are using less than contractual capacity.

5

Given your aim is to avoid the Citrix sessions lagging, I would expect you'd prefer just to prioritise Citrix traffic over all other traffic? That way if something other than a large print job causes saturation, the same QoS still applies.

I've not tested this configuration explicitly with Citrix, but this is what I use.

NOTE: I'm assuming your 877 is an ADSL Modem/Router

First, you want to define a class-map to match the traffic you want to apply a QoS rule to:

! You could match against traffic in other ways, such as via an ACL of some kind.
class-map match-any Citrix
 match protocol citrix 

Then you want to define your QoS policy. I am assuming your WAN link is a public internet link. If you have some kind of private WAN link (assuming QoS is not still stripped), it would benefit you to have QoS on both incoming and outgoing traffic, and on both sides of the link.

In the cases where QoS is stripped over the WAN link, though, the best you can do is to prioritise your upstream traffic so as to improve overall performance.

policy-map OutboundPrioritisationPolicy
 class Citrix
! In this example I'm allowing Citrix to take up to 70% of your upstream traffic,
! as it requires, which may be overkill, depending on how many sessions you have
! running and how important they are vs. other traffic.
    priority percent 70
 ! I've also added fair-queue to all other traffic as I find it helps generally. 
 ! But this is optional for what you're trying to achieve.
 class class-default
    fair-queue

If you're using ADSL, you will need to apply a "parent" policy, which is the one that actually gets applied to the WAN interface. This has to do with the way virtual interfaces are used with ADSL, I believe. The maximum upload speed of the link must be enforced using a shaper.

! Use the shape average command to define your maximum upload speed.
! In this case I've set it to 1.2 Mbps. But you will want to confirm your own maximum.
policy-map OutboundPrioritisationPolicyParent
 class class-default
    shape average 1200000
  service-policy OutboundPrioritisationPolicy

Finally, apply your policy to the appropriate interface, on the 877 I've done this before, it seemed to work (The line you want is the "service-policy" command):

See here for reference: https://supportforums.cisco.com/thread/2010527

! We want to apply the policy to the PVC interface
interface ATM0.1 point-to-point
 atm route-bridged ip
 pvc 8/35
  ! Policy added here
  service-policy output OutboundPrioritisationPolicy
  vbr-nrt 766 766
  tx-ring-limit 4
  encapsulation aal5mux ppp dialer
  dialer pool-member 1

After you've applied your service policy, you would want to of course make sure it's working. There's two main things I usually do:

1) Firstly, and most easily, check the packet counters on the policy. They should be increasing on the policy-map you're trying to apply QoS rules to.

2) This is a bit more involved, and should be done after hours, but is a better test.

  • Setup a PC on the LAN running iperf or some other traffic generator

  • Setup your traffic generator to send out enough traffic to saturate your upstream speed. So for example, if you have an ADSL line with a maximum upstream speed of 1 Mbps, you would want to generate close to that amount in order to get an easily noticeable degredation of quality for your Citrix clients.

    For example: iperf -c X.X.X -u -p 5001 --time 360 -i 3 -b 2

    In this case we are sending UDP:5001 traffic, for 6 minutes, with updates every 3 seconds. 2 Mbp/s of traffic is being generated to a destination of X.X.X.X (NOTE: If you generate UDP traffic then it's not strictly necessary to run the iperf server).

  • Try logging into Citrix, it should be noticeably horrible.

  • Now apply your service-policy. It should be noticeably better.

  • Maybe try this a few times, make sure you notice a difference with and without QoS to ensure it's doing it's job.

  • 2
    +1, Since the OP has a certain destination IP in mind, I think it's preferable to use that IP for classification instead of NBAR... NBAR can be pretty CPU-intensive – Mike Pennington Aug 27 '13 at 9:25
  • @MikePennington Fair point. I had assumed his destination IP was the printer, which I didn't feel was applicable in the way I approached the question. That being said, not much experience with Citrix and I suppose it may be just as easy to determine a destination IP for Citrix. – Geekman Aug 27 '13 at 9:32
  • 2
    You don't need HQoS (parent) if physical interface knows the actual rate. If 877 is just used as ethernet router and there is separate ADSL modem, then you need HQoS to tell the QoS that interface isn't 100M, but some 1Mbps. If your physical interface is ethernet and actual WAN is ATM, you should also tell shaper to account the capacity as ATM cells, but very few devices support this, 877 does not (ASR1k does), without this the QoS will never work perfectly, as it does not know when the ADSL modem will be congested, you can make it work reasonably well by reducing some 10% capacity. – ytti Aug 27 '13 at 11:01
  • @ytti Much appreciated. This gives me some additional insight. I knew the core of what you're saying (QoS needs to be told the actual speed) but I had understood that this was to due to the fact that the actual bandwidth needs to be defined on the Virtual-Access interface (which isn't permanent) and this is why you need the shaper, so I had thought the same must apply. – Geekman Aug 27 '13 at 11:06
  • @ytti Given what you're saying though, I am confused by one thing. I typically use this config on an 891 (which is purely a router) so it fits. But then, that doesn't explain to me why I had to use the traffic shaper, and could not simply apply a bandwidth statement on the interface where the policy is applied? This might the case, but I am quite sure my previous testing revealed that I needed the shaper instead of the bandwidth statement. Perhaps time for a separate question! – Geekman Aug 27 '13 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.