I'm kind of curious what exactly this "Total Output Drops:" field means. I've looked through a bunch of cisco docs and they never really explain it. The input queue on fa0/0 has filled up in the past, but the "drops" field in there never increases: (Input queue: 0/75/0/0 (size/max/drops/flushes)). Anyone? I realize that we are pushing this particular router/interface pretty hard (its peaking in the low 70Mb's and 75-80%cpu) - we have other plans to relieve the situation.
Thanks for the info. IDK why they would not format the output queue the same way as the input queue or put it on the same line at least? Heh heh... anyways, its increased to 128, cleared counters, and I'll check again in an hour or two and work from there. As far as not worrying about the drops - lots of this traffic is SIP or RTP (UDP) so its directly effecting quality of service (to some small degree) even if its only 1/25000.
Ah, I had thought to mention that your overall drop rate was low, but since you mention concern for non-TCP traffic, you might also want to consider using CBWFQ for outbound traffic. A simple policy using just class-default with FQ is a nice first step. (It also usually expands the overall queue size, i.e., shouldn't need hold-queue command.)
Once you have CBWFQ active, you can use LLQ for any real-time traffic as a second step.
Well, input queue and output queue are two very different things. First of all, the input queue doesn't really exist. Or better said, it exist only in the form an hardware or driver-level queue, most often a round-robin circular buffer. The idea is that whenever possible, packets have to be copied directly from the input hardware to the output queue, to minimize memory to memory copies.
Packets are never supposed to be waiting in the input queue, because that would mean the router is not servicing the interface. That is very bad and that is why any input queue drop must be dealt with immediately. You will also notice that there are no options to configure different queueing schemes on input.
On output, all is different. Router will control how and when send the the packet if congestion occurs. And when there is congestion, the output queue fills up and drops.
Now, you have one the the few cases in which a quite fast interface fills up. You said that "most" of the traffic is RTP, so you could configure QoS / LLQ for output. That would attempt to drop anything else before RTP (let's say, dscp EF).
I'm alway vary of increasing queue sizes. True, at FA speeds even 256 or 512 packets in queue isn't much of a delay, but again I think queues should be kept small to aggressively drop TCP, while priority traffic should be treated like that and never dropped if possible.
That is a very abridged version of general IP queueing discussion, but i hope you got the idea.
Great info! Thanks for your help. I think I'm sticking with FIFO and a 256 out queue. I was seeing very minimal drops (9 since I changed it) with 128 and its been 0 over the last hour or so at 256. Latency w/ the larger queue seems to be unchanged, and now we've not dropping anything.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...