QoS Verification question

[BF79]

I have setup a qos as such.

class ipv4 "ImportantTraffic"
10 match tcp 0.0.0.0 255.255.255.255 10.0.0.1 0.0.0.0 eq 1521
20 match tcp 0.0.0.0 255.255.255.255 10.0.0.2 0.0.0.0 eq 8080
30 match tcp 0.0.0.0 255.255.255.255 10.0.0.2 0.0.0.0 eq 8443
exit

policy qos "prioritizeTraffic"
10 class ipv4 "ImportantTraffic" action priority 6
exit

qos device-priority 10.0.0.1 priority 6
qos device-priority 10.0.0.2 priority 6

vlan 1
service-policy "prioritizeTraffic" in
exit

vlan 6
service-policy "prioritizeTraffic" in
exit

I think i have it working, but how can I confirm? Is there a way I can check to see statistics on the policy or class?

Thanks!

-BF79

[Stephen Swain]

To check the results of any QoS policy, use wireshark on the egress interface with a span. The IPv4 ToS/DSCP field will confirm the results. With wireshark, ignore the sometimes incorrect DSCP flag, confirm the DSCP field using the bit pattern (e.g. sometimes you'll see ToS codes, rather than DSCP codes).

A few tips on Procurve QoS, i.e. once I figured out how to decipher the documentation and infer the Queue model from various Procurve documents I searched through, then finally confirmed my implementation using wireshark at various points in the network.

* qos type-of-service diff-services {to enable}

* Classify only works on ingress

* Queuing only works on egress

 - AFAIK model used is Deficit Weighted Round Robin, I'm unable to find authoritative source for this

 - Hardware ASIC based and depends upon IP Precedence to operate

 - The default queue model configuration (8, 4 queues) and queue weighting depends upon the switch model

 - The default queue model seems to be optimal

 - IP Precedence is carried to next switch in 802.1q tags

 - IP Precedence is not carried to next switch if the egress interface is untagged (not a dot1q trunk)

 - Setting Priority is really just setting the IP Precedence flag

* A much better option than Priority is to enable QoS end-to-end using DSCP field in IPV4 packet?

 - Mark traffic at admin boundary using DSCP instead, i.e. at ingress location

 - Won't need to remark in core network, as IPV4 based DSCP is carried across network, just need DSCP-MAP in core

 - Make sure any DSCP tags used are mapped in the 'qos dscp-map' table

 - The DSCP-MAP table maps the incoming DSCP tag to IP Precedence Priority

 - The DSCP-MAP dscp->priority entry is required for automatic DSCP classification and marking

 - Some switches populate many of the DSCP-MAP table, others only do DSCP-EF alone

 - The DSCP-MAP entry, will mark the packets with IP Precedence/Priority, so egress queues get used

* Changing the DSCP-MAP will be tricky, I'd suggest testing all policies on a non-critical switch of same model, get all of the config ready for deployment, and when ready apply on the critical switches. Making changes to the critical switches can sometimes fail to work, and the switch needs all QoS config removed and a reboot, to get that problem removed, and then the new config applied. Not a great option for a live network.

* RFC 4594 seems to be the latest generation of QoS model to follow

 - However, if the Procurve queue model is based on a Deficit Weighted Round Robin?

 - Then PQ, and DSCP based Two-Rate Three Colour Marker and AQM options are not available on Procurve

 - And the traffic priority and weighting is based upon time and usage

* There is a default queue model with two less-than-default priorities

 - Use these to mark down, like a scavenger class, any traffic below that of any DSCP 0 (default) traffic

 - The easy option is to make sure an DSCP-MAP entry for CS1 exists and mapped IP Precedence 1

Hope this helps. If you use DSCP instead of IP Precedence, the whole network config actually gets simpler than the Vlan tagged Priority design.

[BF79]

Thanks for your help.

I will test my current config with Wireshark.

I don't have a spare switch to test configs on and that isnt in the budget.

It is only two servers and three ports that need to be prioritized and this is just to eliminate the network as being the cause of a slow down in the application. We highly doubt that the network is the cause.

Thanks again!

[Vince-Whirlwind]

If the ports aren't seeing any congestion, then QoS won't do anything because nothing is being dropped anyway.

If you are able to provide monitoring stats on the ports (max bps with the lowest possible sampling period; dropped packets, errors, etc...) as well as CPU and memory stats (no unusual spikes) then this should demonstrate that the traffic is flowing OK.

Also, if you can do a file transfer to the server and show that the file transfer achieves the same throughput regardless of whether the dodgy app is running or not, that should also help you demonstrate you don't have a network problem.

The funny thing is, if you ask them, "what do the server and application logs say?", 9 times out of 10 they will admit they haven't even looked.