Cisco – How to view qos statistics on cisco 6500

Whhich bandwidth are you concerned about - outgoing or incoming? If you do not have control over Service Provider's router, you can't achieve true QoS(when you can make sure certain kinds of traffic get more priority than others) for incoming traffic. What you can do though, is to limit certain traffic on your router, ensuring that the remaining portion is available to the target network. For example, you can limit traffic(or certain kinds of traffic, like streaming videos) on LAN2 and LAN3 interfaces which will guarantee that LAN1 always has 3mbits available.

In Cisco terminology this is called traffic policing(as opposed to shaping for true QoS) This document is a good start : http://www.ict-partner.net/en/US/docs/ios/12_2/qos/configuration/guide/qcfpolsh.html#wpxref40342

We operate a couple network implementations where third-party connections are linked up to a centralized Cisco backbone (i.e. multi-tenant setup). I can say I've seen a bunch of diverse (okay, ghetto) devices connected up to the Catalyst platform, and if there's one thing I've learned, it's that the Cisco platform is remarkably resilient to these kinds of things.

There is one achilles heel, though - A cheap hub in the right configuration can easily bring down an entire network with a broadcast storm, and it's not even the Cisco platform's fault. I discovered this in a production configuration, and the only real research I did was finding the closest trash can for that hub, but here's how it happened:

1. Connect hub to Cisco switch as normal, with uplink port
2. Connect a workstation to a hub port (in our case, running Windows XP OS, but shouldn't matter)
3. Connect two other ports together on the hub (either directly, with a single CAT5 or indirectly through another hub).

Everything runs smoothly until that workstation sends out a broadcast announcement. While the hub and the Cisco are smart enough to prevent a broadcast storm on other broadcast packets, the hub isn't smart enough to detect that two of its ports are connected to each other, and will use up almost 100% of its processing power to broadcast that packet in an infinite loop back and forth, as well as out all the other ports (i.e. the uplink to your Cisco).

If this is the case in your configuration, you will notice that across your network, all of the ports on that broadcast VLAN will go nuts, up until the hub can't sustain the capacity and drops the magical looping packet (could be a couple minutes depending on the competing traffic), and then all is back to normal.

In this situation SNMP won't help you since all the ports on that VLAN go crazy with traffic. However, Wireshark is your friend here, since it's easy to capture which IP (and sometimes machine name if it's a broadcast packet) caused the loop, and quickly locate the offending device.

May not be the exact case you're experiencing, but this one bit us hard and might give you some ideas to research with your situation.