Now, you're not expected to know this for the CCNA exam, but I'm going to demonstrate an example of
quality of service on two Cisco routers.
In this example, I've got two routers running in genius three show run interface, serial, 2/0.
Shows us the configuration.
These routers simply have IP addresses configured and I have no shut the interfaces.
No other configuration has been done.
Show Interface Serial 2/0 shows us the speed of the interface, which is using the default of 1.54 megabits
per second.
So on this interface of the router we can use the command auto quoz.
Now notice we do have the discovery option where we can configure the rider to discover traffic that
traverses that interface.
But in this example, I'm simply going to enable the interface for VoIP, and I'm not going to specify
the option trust, which means it's not going to trust the markings that it receives from rather to.
Not typically in the real world you would do that.
You would trust traffic from one router to another unless router one is a service provider and router
two is a customer as an example.
Now here I'm going to use order VoIP trust so that you can see the difference between trusting and not
trusting a neighboring router.
So rather one doesn't trust router two rather two trusts router one based on the order configuration.
Now order cause creates.
A large amount of configuration.
So rather than you manually typing configuration.
It's done for you because rather to trusts rather one, it's created a quality of service class map
that matches DCP f.
So essentially, if rather two receives traffic from rather one marked as F, it's going to go into
this order.
Quoz VoIP RTP Trust class.
That's referenced by this policy map.
The configuration that you see here is an example of moxie or the modular quality of service command
line interface.
It consists of two main parts.
We've got class maps and we've got policy maps.
And policy maps are then bound onto interfaces.
So in this example.
We've got the service policy which references the policy map bound to the serial 2/0 interface.
So going back to our class maps.
We've got two class maps, one matching DCP f.
And one matching either notice the match any key word clause selector three or IP precedence three and
assured forwarding class three one or AF three one.
Now, rather to trusting the markings that it receives from rather one.
So it's looking for traffic that matches F and that class is then matched within this policy map.
So notice the name order quasi VoIP trust is matched here and it's given 70% of the interface bandwidth
when there's congestion.
So in other words, voice traffic matched by F will be given a priority bandwidth of 70%.
That's a priority queue.
This is an example of low latency queuing.
We've got classes of traffic, but we've also got a priority queue.
So this is the priority queue in low latency queuing.
A voice will be given 70% of the bandwidth, other traffic.
So in this case, we've got VoIP control is given 5% of the bandwidth.
Notice this matches the class configured over here, which is matching CS3 and AF 31.
That's essentially call signaling protocols such as CIP, H three, D three and skinny.
In other words, those are protocols you use to set up telephone calls.
So notice what Audioquest has done.
It's allocated 75% of the interface bandwidth to voice calls.
So the actual voice traffic, the HTTP traffic gets 70%, call signaling gets 5%, and the remaining
traffic is shared using fare queuing.
So this is an example of waited for queuing on the default clause.
Default clause is going to match anything not explicitly matched.
So a low latency cue is actually priority queue.
Class based weighted.
Fair queuing.
But that's too much of a mouthful.
So we call it low latency queuing.
There's the priority queue.
He has an example of a class.
And this is an example of waiting for queuing within a class.
Low latency queuing is part of queuing.
Class based waited for queuing.
And in this example, we are prioritizing VoIP traffic over other traffic types.
70% of the bandwidth can be taken by voice calls.
It's a priority queue, so it will be serviced first.
5% of the interface bandwidth could be taken by call signaling, but this is a guaranteed minimum bandwidth,
not a priority.
This is a guaranteed minimum bandwidth of 70% of the interface bandwidth, but it's a priority queue.
So voice traffic will be prioritized over all other traffic.
If voice traffic is only using 20% of the interface bandwidth, other traffic can use whatever is not
reserved for voice.
So this is a maximum amount of bandwidth that voice can take and voice will be policed at that level.
But in the worst case scenario, other traffic will only get 25% of the bandwidth.
This policy is applied on the serial to zero interface outbound.
So any traffic leaving the rudder will be prioritized or cued based on this configuration.