Hello-
When the host and IP phone transmit data and voice packets destined for the host and IP phone on the other side, it is likely that we get congestion on the serial link. The router will queue packets that are waiting to be transmitted but the queue is not unlimited.
Should it be, ’ but the que is limited’.
Hello Yonas
“The queue is not unlimited” is the same as “the queue is limited”. It’s just a different way of saying it. Indeed Rene chooses to say “not unlimited” which means “limited”, but it’s a matter of preference.
But thanks for keeping an eye out for discrepancies, it’s always helpful to get feedback of all types!
Laz
Hi,
Great article!. One question. I’ve noticed that the images with a router and ingress and egress actions to its left and right show Gi0/1 as the names of the input and output interfaces. Shouldn’t they be different interfaces?
Oh, and another question: in the section about congestion avoidance its mentioned that there is maximum threshold above the one all packets are drop. However, the illustration in that section shows a space between that maximum threshold and the “queue full” arrow. What represents that space?. If packets are drop just after the maximum threshold is reached, how would that space be filled with packets if packets are already being drop and no more packets can enter the queue?
Regards.
Hello José
Yes you are correct. I’ll let Rene know to make the correction on the diagrams…
This is to indicate that the Maximum Threshold is a value that you can modify. It does not necessarily have to be at the maximum of the actual queue. And remember, that the Maximum Threshold here is an average, which means that the actual queue capacity can surpass that at any given time. For more information about how WRED works and how the thresholds are defined and applied, take a look at the following lesson:
I hope this has been helpful!
Laz
Is the following summary of QoS correct?
Classification - ACL / NBAR
Marking - ToS / DS
Action - Congestion Management (Queuing) / Policing and Shaping / Congestion Avoidance
Hello Robert
Yes, that is indeed correct. Classification uses either the info in the headers (using ACLs) or payload inspection (using NBAR) to determine what kind of packet (VoIP, video, web, FTP, email, etc…) each one is. Classification is essentially used to identify the application from which packets are sent. Classification is locally significant and is not communicated to any other network device.
Marking changes the ToS in the header of the IP packet and/or the CoS in the tag of the Ethernet frame. Marking can be used to communicate to devices downstream about how to prioritize such traffic based on predefined agreements. Classification is used to mark packets/frames appropriately.
Once marked, network devices can be configured to act upon the markings based on predefined QoS mechanisms, including queuing, policing, shaping, congestion avoidance, and others.
I hope this has been helpful!
Laz
Good day,
I have a couple of questions:
2.An administrator must design a solution to connect a client to the Internet. And the solution will include a Layer 3 circuit with a CIR of 50 Mbps from the service provider. The throughput from the provider’s switch to the customer’s router is 1 Gbps. What solution should the engineer include in the exit interface to avoid possible problems with choppy voice traffic. Shaping or Policy?
Thank you
Hello @r41929998 ,
In a nutshell, shaping “buffers” your exceeding traffic and policing “drops” (or remarks) your exceeding traffic.
A service provider will use (inbound) policing to enforce a CIR rate. From the customer’s side, you could configure (outbound) shaping to prevent the service provider’s policer from dropping your traffic.
If you have a 1 Gbps connection and a 50 Mbps CIR, the service provider will police at 50 Mbps. That means they’ll drop everything above 50 Mbps.
You can configure shaping to rate-limit your traffic to 50 Mbps, but you have to be careful. Shaping increases your delay, so it’s unsuitable for delay-sensitive applications like VoIP.
It’s best to combine shaping with something like LLQ:
You put your delay sensitive traffic like VoIP in a priority queue with a limit. Other important traffic can be shaped if needed.
Rene
Hello, everyone!
I have a few QoS questions.
Thank you.
David
Hello David
When it comes to QoS, IP phones are typically easy to work with because they classify and mark voice traffic by default, and their traffic can be easily identified by other network devices due to the dedicated voice VLAN they use as well as the use of CDP or LLDP to identify the devices themselves. When voice traffic originates from applications like Discord, Skype, or Cisco Webex on a computer, the classification and prioritization become less automated, but it can still be achieved using several tactics:
Yes, that is correct. Queuing delay is only experienced when there is congestion. All the other forms of delay mentioned occur always.
I hope this has been helpful!
Laz
