Cisco ios commands reference
![cisco ios commands reference cisco ios commands reference](https://www.ciscozine.com/wp-content/uploads/nmap-for-ios-no-iosmap.jpg)
The TM is merely the hardware portion of the NPU concerned with the shaping and queuing (policing and marking is done in the pipeline already). If you google "asr9000 quality of service architecture" I have a hopefully decent write up that might help there
![cisco ios commands reference cisco ios commands reference](https://miro.medium.com/max/1400/1*1pWRmqeNOTDXgF6zyRaVPw.jpeg)
So the way to mimick the holdQ is by means of a class-default queue on your main interface with a queue limit setting. Now, the way the a9k (for instance) implements QOS is by that TM scheduler, it makes sure the interface remains busy with packets and there is always a class default queue (which is then your sort of holdQ) for any unclassified traffic that has no specific queue. So while holdQ buffering provides for good things in terms of performance and Q'ing strategy, at the same time it might affect PQ latency also. In addition, if there is a high priority packet to be xmitted, it has to be put in that holdQ. While this is a great methodology, it has pros and cons. Also the excess use of the holdQ would exert backpressure to instruct the Q'ing hierarchy to starting buffering or Q'ing. The hold queue in IOS (based platforms) is used to "keep the framer busy" with a pipeline of packets that have been scheduled for transmission. Yeah that is a good question but it is heavily platform dependent whether this is useful or not.īy platform depdendent, I am merely talking about the way the QOS is implemented for these platforms which in turn is directly related to the hw architecture of the forwarder that implements the QOS.įor ASR9000, it is the trident or typhoon NPU, and more specifically the traffic manager portion of it. If you want to do something (but monitor the situation first before adding buffers to queues, as it will increase delay and jitter), a queue limit on a class-default on a main interface might be what you're after. In short, you have no need to tune the holdQ, so you can omit this command in your conversation. Note that a holdQ is not really the equivailent to a queue limit buffer. The internal "VOQ's" (virtual output queues) are shaped already, and the traffic manager shapes the circuits on egress also already by nature.įor that reason there is no need for a holdQ to get backpressure.ĭue to the architecture, this final fifo queue serves little purpose and for that reason it is not there as such (or configurable). There is internal QOS inside the system already with backpressure, regardless of an egress queue.
![cisco ios commands reference cisco ios commands reference](https://i.pinimg.com/originals/9d/9f/0c/9d9f0c8396f0cf2c3c852266706340db.jpg)
In A9k/XR this is not necessary: typhoon (or trident for that matter) have a traffic manager (TM) that is always active, QOS configured or not. In IOS the holdQ is also used to trigger backpressure to the q'ing system to get activated.