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.
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
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.
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.
