QOS on PIX 515 version 7.0

Some of the users on my network are using testing software that is sensitive to latency. The software company recommends 100 pings as a test and they say anything more than 4 seconds will cause the test to reset. I ran their diagnostic as well as using the ping command and I did see some latency of 4 seconds and greater.

From the inside of the network to the outside there is:

LAN-- ISA 2000--PIX-515--Router(2600)--Internet

If it makes any difference we are using 2 T-1's which are somehow bound together. I think I remember hearing some mention of express forwarding.

I used the following link to configure QOS on the PIX

formatting link
The problem is that I am not sure it is working. I did a 'sh priority-queue statistics' and my LLQ shows zero for all statistics. I guess the bigger questions is weather or not the problem is on my end and I'm not 100% sure what to ask my ISP.

Anyway, using the Cisco document I came up with the following config: (I only included the changes to my config - I can post the entire config if needed).

Thanks in advance for your help.

access-list myQOS extended permit tcp xxx.xx.0.0 255.255.0.0 any access-list myQOS extended permit udp xxx.xx.0.0 255.255.0.0 any

class-map inspection_default match default-inspection-traffic class-map QOS match access-list myQOS

policy-map global_policy class inspection_default inspect dns maximum-length 512 inspect ftp inspect h323 h225 inspect h323 ras inspect http inspect ils inspect netbios inspect pptp inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp policy-map QOS class QOS priority ! service-policy global_policy global service-policy QOS interface outside tftp-server inside 172.16.22.127 tftp-root priority-queue outside queue-limit 1000 tx-ring-limit 3 priority-queue inside queue-limit 1000 tx-ring-limit 3

Reply to
rjmnyc
Loading thread data ...

Bonding together channels can, in some configurations, make a big difference to latency. It's worth asking about the details of the bonding. Is it using per-packet distribution -- if so then latency is going to be inconsistant. If it is not using per-packet then it must be using some combination of source and destination addresses to determine which channel to send any given packet over; you need to know what the combination is and you need to know your PIX NAT policy, so that you can figure out whether different inside hosts might take different channels to the destination -- inconsistant latency if so, and possible underutilization of one link with congestion on the other link if the same channel is always used...

I haven't investigated PIX 7 QOS; when I had a quick look at your configuration, my mental question was whether the QOS ACL has the source and destination in the correct places, and whether the public or private IP needs to be used for that ACL. At first glance, it looks like -maybe- you are applying QOS to -incoming- packets... either that, or applying QOS to all outgoing packets (destination 'any')

Reply to
Walter Roberson

Hi Walter

I was applying priority based QOS to incoming packets and pinging the destination to see if my QOS ACL showed any hits but it didn't. I ended up contacting Cisco and I was told that I was not getting hits because it was return traffic. They told me I had to configure QOS on outbound packets even though it was the inbound throughput that was very high (outbound was only at 30% of capacity). After I did this I could see the ACL's (in and outbound) showing hits. I also did a 'show priority-queue statistics' and I could see packet statistics in the low latency queue (LLQ).

I hope it works.

Walter Robers> >

Reply to
rjmnyc

Applying QOS to inbound traffic is usually too late: the packet has already reached you and a fair bit of processing has already been done on it by the time the ACL is examined. You just might be able to shave a couple of microseconds off of latency by having the PIX prioritize the packet as it goes in through the PIX, but it probably wouldn't make that much difference.

When QOS is applied to inbound packets, often the main purpose is to have the QOS drop TCP packets so that the normal TCP congestion control mechanisms kick in and cause the sender to slow down.

Reply to
Walter Roberson

Hi Walter

Thanks for clearing that up. I am still experiencing latency > 4 seconds. Users are being bounced out of the application and Cisco is telling me I need to configure QOS on the router too. I asked Cisco if QOS is configured at the router what happens when the packets reach the next router. Would we have to configure every router on the Ineternet too? Verizon says either one (firewall or router) can be configured but they recommend the router. I'm really confused now. Any ideas?

Walter Robers> > >I was applying priority based QOS to incoming packets and pinging the

Reply to
rjmnyc

I spoke with several people at Verizon. They told me the congestion is on the inbound traffic and that QOS would have to be configured at the Verizon ISP (another department). When I contacted the ISP they told me what I wanted to do was available through a product they offered and that I should call my salesperson.

Walter Robers> > >I was applying priority based QOS to incoming packets and pinging the

Reply to
rjmnyc

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.