QoS config - displaying results using ping

Unanswered Question
Nov 1st, 2007

I'm testing QoS in our environment and want to be able to show management some hard results of the QoS configuration. I'm trying a simple test of uploading a large file from site A to site B, and during this period of congestion am pinging a host that I've setup to be caught by an access-list and applied that access list to a class map. Then that class map is added to a policy map and given bandwidth priority. That policy map is then applied to the serial interface in the outbound direction, which leads to the other end of a point to point T1. The return traffic, host to any IP address is caught in another access list and given the same priority. However, all my ping responses, to both the host whose traffic is being caught in my access list and another host not being classified are returning avg response times essentially the same. Is there a better way of testing, or does this test actually prove my configuration is wrong?

My goal ultimately is to provide preferential treatment to traffic heading to certain web application servers using QoS. I have some match protocol http host and url statements, but it's hard to show that the QoS policies are actually improving performance. I get matches on my class maps and policy map as evidenced by my sh service policy-map inte s 0/0/0 command.

I've double checked my config on both ends and everything looks fine. I even replaced the bandwidth percent 30 in my policy map to priority percent 30 and saw no change in ping response times. They are the same whether or not the traffic is being classified as priority. The link is a point to point leased T1. It doesn't require any special service like MPLS to be able to carry QoS tags does it?

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Wed, 11/07/2007 - 04:59

You're not going to see much of a difference with your pings unless you compare against a loaded ciruit using FIFO, or traffic in the same CBWFQ non-FQ class. T1/E1 serial interfaces normally default to WFQ which often performs very well except in some cases.

Your stats also show

(pkts matched/bytes matched) 806/414262

8173 packets, 1748438 bytes

which means only about 10% of your BUSCRITICAL even queued.

shiva_ial Fri, 11/09/2007 - 04:28

hi,

there will be an hardware queue which has

to be filled first for qos to be in action

u can use show access-lists (access-list-name) to verify matches under particular access-lists and class u have created.

do some bulk transfers and do ping and verify

icmp matching which class either default or your priority class , if it is under priority access list sure response will be faster, will have low reponse times but under default class no difference will be there

Actions

This Discussion