"Finally, IOS uses queuing only when congestion occurs. IOS considers congestion to be occurring
when the hardware queue is full; that generally happens when the offered load of traffic is far less
than the clock rate of the link. So, a router could have a service-policy out command on an interface,
with LLQ configured, but the LLQ logic would only be used when the hardware queue is full."
Nothing new here but in pages before he said:
"! The class map matches on UDP/RTP header and RTP port numbers.
class-map match-all voip-rtp
match ip rtp 16384 16383
! Next, the policy map uses the bandwidth command to reserve 64 kbps for the class
! voip-rtp. Class-default gets some of the leftover bandwidth by default.
! The interface?s bandwidth 128 command is used as the basis for the limit on the
! amount of bandwidth that can be allocated in the policy map queue-voip.
! The load-interval command sets how often counters are updated. Also, note
! that the policy-map is enabled for output; input is not allowed on routers for
! policy maps that perform queuing.
service-policy output queue-voip"
Note the "bandwidth command is used as a basis for the limit..." This indicates that the queueing would be active at 128k well below the interface tx-ring capability. Am I missing something? The way I see it these two things as they read on the page, cannot be true at the same time. If the queueing mechanisms are engaged only after tx-ring is congested, how can this "bandwidth reference" thing work?
1) When configuring QoS, you cannot reserve more than the interface bandwidth. Which is determined by the router based on the configured bandwidth command on that interface. Try to allocate more than that, and the policy map will be rejected when you try to apply it to an interface.
2) You can configure QoS at any time you wish. But as long as there is no congestion (the traffic stays below the interface limit), QoS will have no effect. As long as there is no congestion, there will always be free space in the hardware queue, so you don't use (and don't need) the fancy software queuing mechanisms. :) Those mechanisms will be used only when the interface is congested.
I don't see where the contradiction is. The bandwidth command is the "software" part, and decides what you can configure on that interface. The actual congestion is the "hardware" part, deciding when (or if) your configured QoS will go into effect.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...