Somewhere I read that if the wan link is not congested then the priority queueing mechnism is not used. A little confused about this. say I have a 256K wan, and 90k assigned to voice for about 3 G729 calls. say same time there are 100K data. WE see here in total is less than 256. so it's not congested. Does that mean the voice traiffic is not put into priority queueing because no congestion? If that's the case, which queue does it put before exit? THanks
queues actually exist only when there is congestion. When there is not, packets leave immediately the interfaces and no queueing occurs. If you want to see how your Qos is working, try "show policy-map interface".
Software queuing that you configured in this case is LLQ. This won't be used if the link isn't congestion.
Note : Be careful about the bandwidth that you configured if it is less than exact bandwidth that you need then the exceeding packets will be dropped all the time because in this queue inherits tail drop of FIFO mechanism.
As paolo said : You can confirm with "show policy-map interface".
I had the same idea as you guys before I saw the following from Cisco. It apparently even without congestion the priority queue is still necessary and used to fix the queuing and buffer latency. In other word, the data still will cause delay if in a non congested port and as we thought if priority not used.
After the compressed voice payload is built, a header is added and the frame is queued for transmission
on the network connection. Voice needs to have absolute priority in the router/gateway. Therefore, a
voice frame must only wait for either a data frame that already plays out, or for other voice frames ahead
of it. Essentially the voice frame waits for the serialization delay of any preceding frames in the output
queue. Queuing delay (?n) is a variable delay and is dependent on the trunk speed and the state of the
queue. There are random elements associated with the queuing delay.
For example, assume that you are on a 64 Kbps line, and that you are queued behind one data frame (48
bytes) and one voice frame (42 bytes). Because there is a random nature as to how much of the 48 byte
frame has played out, you can safely assume, on average, that half the data frame has been played out.
Based on the data from the serialization table, your data frame component is 6 ms * 0.5 = 3 ms. When
you add the time for another voice frame ahead in the queue (5.25 ms), it gives a total time of 8.25 ms
Actually the example you quoted, is about a congested interface, because when the voice packet arrives, another packet is being sent out. Being the interface in the example a mere 64 kpbs, this happens quite often.
But, on high speed like fast ethernet that can transmit 144,000 packets per second, there is no much probability that congestion (more than few packets in queue, or packet drops) will ever happen.
So there is a big difference waiting for packets to be transmitted over a slow or a fast link.
I agree with you that slow link for sure has more chance to be congested. But even fast link you stil have to wait the data packets to be sent out if no priority used. Say you have 10M link, there is FTP packet train each with 1500 byte are sending. Then voice has to be waited until it is finished. If the tfp size is 1M byte, then you could wait about 1s before send the voice. And it's not congested yet since 1Mbyte technically only uses 9Mbits link.
FTP being TCP does not really sends packet trains but is limited to the TCP window size. After a little bit of time (and few packet drops perhaps) it will adapt nicely and will start sending at a steady rate, let's sat 9 mpbs per second. There is still 1 mbps left, now without QoS it will be strictly FIFO. One voice call being some 110 kpbs will still work, and believe me, no packet will ever wait 1 sec, because the default of 40 packets output queue size on a 10 mbps interface, means less than 50 msec for packet size 1500 !
Rememeber that one single TCP flow is never enough to completely fill a link.
Now, it that circuit was shared by many many users, or with aggressive UDP senders, yes you could have issues.
My point is priority queuing is still should be used even in a non congested link if priority is configured. Take the same example above(or maybe say UDP for argument per say), voice will wait more time at least 50ms in your calculation. But if priority is being used then voice doesn't have to wait so long. It could just wait for one packet.
I have no interest in making you not to configure QoS on LAN interfaces, it's just that is useless.
I don't say this to make weight my opinion, but I've formed it in 15 years of networking, and I was with cisco already when voice and qos was introduced, and I was lucky enough to have it proved many times on both real networks, and sophisticated laboratories.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...