Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

4500 QOS question??


In my lab I have two 4707R switches linked with a 10Meg full duplex connection configured with QOS to trust DSCP with the autoqos voip commands. I am only running at 10Meg in order to test the QOS functions of the switches.

I have two voice generation tools -Net IQ Vivinet - connected to a port on each switch marking packets with DSCP EF. I am sending over 30 64K G711 trunks. The ports to which these voice tools are connected also trust dscp. Hence, DSCP 46 gets places in the priority queue and 0 in one of the three "normal" queues.

Everything works fine.

I now bit blast between two other PC's at 45Megabits/sec UDP - in seperate VLANS - across the link and the voice basicaly dies. Why? Why isn't the priority queue 3 doing it's thing? Is it because I am trying to bit blast (from PC's on gig ports) at such a high traffic level with respect to the 10Meg link that even priority queueing can't help? I would find this difficult to believe - why isn't the port just dropping the non-trusted (DSCP 0) frames? I know I have the ports set up correctly.

Are there any commands to see the frames in the four queues on the 4500 series?

Once upon a time, there were certain recommendations that Ethernet should not be driven over about 60% utilisation. Does this rule hold today on Full duplex links with QOS?

Any help would be gratefuly received.

Kind regards,


New Member

Re: 4500 QOS question??


I don't have any great answers for you, but I thought it might be helpful to let you know that I have seen the same thing, and share some info I found. Long story short... 1) Lower-end hardware is easier to overload and may drop a little of everything if flooded beyond resource capacity, and 2) You should see better performance with stateful traffic than with non-stateful.

Short story long...

We were at the Cisco Proof of Concept lab in San Jose running a QoS simulation, using a tool that would blast non-stateful TCP traffic over a link. For such purposes, non-stateful TCP traffic is the same as UDP in that the traffic does not respond to network conditions by throttling/windowing up and down, it just keeps blasting at a constant speed, which for us was 4x the capacity of the link.

And what we saw was that some of the smaller PA's just could not keep up, even if our QoS configs were correct. We had a 2651 with a WIC1DSU/T1 PA that would drop a little of everything when we tried to blast 6 megs of non-stateful traffic through. The Cisco lab guys got one of their colleagues on the line who is a QoS guru, and he said that he had seen it before, and we were simply overloading the hardware. That T1 PA has finite resources and we were asking too much of the interface. It was trying to drop as much best-effort traffic as quickly as possible but it just could not empty the outgoing buffers fast enough, so all traffic classes were impacted.

However, when we blasted 6 megs of stateful traffic through the same link, the PA would do just fine, and QoS behaved as expected. But that is because the stateful traffic responded to packet drops and throttled/windowed down, just as actual (non-UDP) traffic should.

But on higher-end WAN interfaces, we did not see the same problem. We could blast through 4x link capacity, and QoS treated both stateful and non-stateful traffic as expected.

I know this is no grand solution, but I thought the info might be helpful. Good luck!

Best Regards

Robert Hyde

New Member

Re: 4500 QOS question??

Hi Robert,

Thanks for the input. Yes, I think we are on a similar wavelength here. Just bit blasting 5x the slowest link speed with UDP traffic simply kills the interface.

I am going to do more testing with this and if necessary raise it to TAC. The amount of priority queue bandwidth I requie on the 10MEg link is not excessive so why can't the hardware keep up with the DSCP EF traffic and drop the UDP rubbish?

I'll post back.

Thanks again for your input Robert.

Best regards,