All Cisco QoS books and papers are focused on managing congestion over output queues (TxQ). There is few or no mention to INPUT queues. What is the reason? Is it so irrelevant?
Please consider this scenario: A hub-and-spoke network (central node "A") with 2 remote nodes ("B" and "C") connected to "A" through FR PVCs. "B" is only transmitting VoIP to "A" and "C" is only transmitting data. "A" receive both traffics in the same interface. If "C" is flooding with FTP traffic the INPUT queue in "A", What do I do to avoid that VoIP traffic coming from "B" be discarded in "A", at the ingress? How do you manage congestion in "A" INPUT queue?
In short, there are no input queues. On input, you can do classification, marking, even rate limiting, but no queuing.
For example, in your scenario, once the data traffic has arrived at the interface, is there already. If it was too much and was disturbing voice, the damage is done already.
I'll put in another way. The router tries always to handle traffic as soon it arrives. putting it in a queues would slow processing and increase latency. If you had a queue, In fact you would have to process traffic twice, once at arrival, and then later again.That would be inefficient. The reason there are queues on output instead is because the trasmission media like T1, etc is slow, much slower that the amount of traffic that the router can process.
Now, is true that if you do show interface you will see something like "input queue", but these queues are purely virtual. It is just an indication of how many packet are there in the hardware input queue. If that queus start building up, the router is very sick, in fact it should never happen.
Last Post tought you the right vision. Resolving QoS issue on the outgoing interface is really the only efficient way to optimize the treatment of differents traffic flows without adding more delay..
To go further, you would configure LFI mechanisms on the outgoing interface of C (to achieve minimum serialization delay) from where annoying (because possibly larges) data packets are sent towards B via A.
So larges data packets sent from C will already be fragmented and interleaved with thoses precious voip packet, when arriving in the (real hardware) FIFO input queue.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...