Typically CBWFQ (Class-based Weighted Fair Queueing) is not used for voice as it gives a bandwdith guarantee, but not one for latency. To keep voice quality consistent you want a fixed amount of bandwidth and the lowest latency possible. On cisco gear this is implemented using LLQ (Low Latency Queuing) which works as a straight priority queue. You can use policing to keep it from running away with all the bandwidth.
Why someone would want to integrate their firewall into their internal switch is beyond me anyway.
Yes, it seems it is beyond you...:-)
#1: Who says this has to be your only firewall?
#2: In large networks it might be desirable to shield the servers from the global userbase (Hint: Not all attacks come from the outside)
Well I am a CCIE and I would never refer to a Cisco OS generically as "IOS"... It is incorrect to do so and implies something that may not be true.
For example, the 6500 series can run CatOS on the supervisor by itself, CatOS on the Sup & IOS on the MSFC in "hybrid" mode, or "native" IOS running on both. If you simply referred to it as "IOS" no one would have any idea what you are talking about.
If nothing else, the highly crippled PIX OS does not deserve to be called "IOS". Cisco should port IOS (and the firewall feature set) to the x86 and put the nail in the PIX OS (aka "Finesse") coffin.
You really don't want to do that. HTTP over UDP is simply a bad idea... Why? In order to meet the most basic needs of a stream reliant protocol (ala HTTP) you need a few things:
1. Reordering (No guarantee packets arrive in order) 2. Retransmiting (Detect lost packets and resend) 3. Speed throttling (Packets go too fast -> router interface buffers overflow -> packet dropped)
It is of course possible to write a protocol on top of UDP to do these things, but thankfully we don't have to as someone did the work for us... it is called TCP.
I suppose if you wanted to use a HTTP/UDP mechanism for very short communication only (read: one request packet, one reply packet) then those issues aren't relevant, but otherwise leave the heavy lifting to TCP or other stream based IP protocols.
Slashdot Mirror
This was my guess as well. The most common way to build up that much traffic is with an STP loop.
Typically CBWFQ (Class-based Weighted Fair Queueing) is not used for voice as it gives a bandwdith guarantee, but not one for latency. To keep voice quality consistent you want a fixed amount of bandwidth and the lowest latency possible. On cisco gear this is implemented using LLQ (Low Latency Queuing) which works as a straight priority queue. You can use policing to keep it from running away with all the bandwidth.
Why someone would want to integrate their firewall into their internal switch is beyond me anyway.
Yes, it seems it is beyond you... :-)
#1: Who says this has to be your only firewall?
#2: In large networks it might be desirable to shield the servers from the global userbase (Hint: Not all attacks come from the outside)
Well I am a CCIE and I would never refer to a Cisco OS generically as "IOS"... It is incorrect to do so and implies something that may not be true.
For example, the 6500 series can run CatOS on the supervisor by itself, CatOS on the Sup & IOS on the MSFC in "hybrid" mode, or "native" IOS running on both. If you simply referred to it as "IOS" no one would have any idea what you are talking about.
If nothing else, the highly crippled PIX OS does not deserve to be called "IOS". Cisco should port IOS (and the firewall feature set) to the x86 and put the nail in the PIX OS (aka "Finesse") coffin.
You really don't want to do that. HTTP over UDP is simply a bad idea... Why? In order to meet the most basic needs of a stream reliant protocol (ala HTTP) you need a few things:
1. Reordering (No guarantee packets arrive in order)
2. Retransmiting (Detect lost packets and resend)
3. Speed throttling (Packets go too fast -> router interface buffers overflow -> packet dropped)
It is of course possible to write a protocol on top of UDP to do these things, but thankfully we don't have to as someone did the work for us... it is called TCP.
I suppose if you wanted to use a HTTP/UDP mechanism for very short communication only (read: one request packet, one reply packet) then those issues aren't relevant, but otherwise leave the heavy lifting to TCP or other stream based IP protocols.