Cisco CCNA Packet Tracer Ultimate labs: Quality of Service (QoS) Lab. Answers Part 2

Cisco CCNA Packet Tracer Ultimate labs: Quality of Service (QoS) Lab. Answers Part 2

Packet Tracer file (PT Version 7.1):
Get the Packet Tracer course for only $10 by clicking here:
Get my ICND1 and ICND2 courses for $10 here: (you will get ICND2 as a free bonus when you buy the ICND1 course).

For lots more content, visit – learn about GNS3, CCNA, Packet Tracer, Python, Ansible and much, much more.

QoS is the measure of transmission quality and service availability of a network (or internetworks).

Service availability is a crucial foundation element of QoS. The network infrastructure must be designed to be highly available before you can successfully implement QoS. The target for High Availability is 99.999 % uptime, with only five minutes of downtime permitted per year. The transmission quality of the network is determined by the following factors:
•Loss—A relative measure of the number of packets that were not received compared to the total number of packets transmitted. Loss is typically a function of availability. If the network is Highly Available, then loss during periods of non-congestion would be essentially zero. During periods of congestion, however, QoS mechanisms can determine which packets are more suitable to be selectively dropped to alleviate the congestion.
•Delay—The finite amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. In the case of voice, this is the amount of time it takes for a sound to travel from the speaker’s mouth to a listener’s ear.
•Delay variation (Jitter)—The difference in the end-to-end delay between packets. For example, if one packet requires 100 ms to traverse the network from the source endpoint to the destination endpoint and the following packet requires 125 ms to make the same trip, then the delay variation is 25 ms.
Each end station in a Voice over IP (VoIP) or Video over IP conversation uses a jitter buffer to smooth out changes in the arrival times of voice data packets. Although jitter buffers are dynamic and adaptive, they may not be able to compensate for instantaneous changes in arrival times of packets. This can lead to jitter buffer over-runs and under-runs, both of which result in an audible degradation of call quality.


So here’s router 2.
show run
no quality of service configuration has been configured on this router.
Interface that we’re working on is serial 0/2/0.

So on router 2 class-map we could use different names here but I’m going to use the same names. We’ve got class maps for voice. Here we need to match on DSCP.
So match ip dscp ef
per these instructions we’re going to set the IP precedence to 5 but that needs to be done in the policy map.

Next class is HTTP
so class-map http match ip dscp af32
class-map icmp match ip dscp af11

So on router 2, we are matching DSCP values. We are not using NBAR. We are going to read the DSCP values of packets received on the serial interface and then we’re going to do something with it such as remark the DSCP values.

So I’ll create a policy map called remark. The first class that we’re going to match is a voice and we’re told to set the IP precedence to 5.

So set precedence and notice of the words we could either use the word critical or we could use a value such as 5. So I’m going to specify critical but notice what happens.

Do show run
It’s been changed to the number 5. So either will work but in the output you’ll see numbers. So you could either enter critical or 5 but it gets converted to the number.

class http
set precedence
and we’ve been told to set the precedence to 3.

class icmp and here we going to set the precedence to routine or 0.

So again, show run
Here are our class maps matching different traffic types.
Here’s our policy map where we’re changing the DSCP values.
In other words we are rewriting the type of service field or TOS field in the IP header and using precedence or rather than DSCP values.

Next step is to bind the policy map.
So interface serial 0/2/0 service-policy inbound or input in this case remark
So we’ve completed the configuration.
There are our class maps, here’s our policy map, scrolling down, here’s the service policy bound to the serial interface. I’ll save the router configuration…………..