Now in Russia one because it doesn't trust any markings that it's receiving.
There's more configuration in this example.
Notice as an example that we've got a class map matching white control.
There's a class map matching RTP.
This is using n bar or network based application recognition to determine whether the traffic is actually
RTP traffic.
It also matches an access list.
So this is a match any side will either match RTP audio or whatever's configured in the success list.
So let's have a look at that access list notice the access lists are fairly complicated.
We have an access list for RTP traffic Cisco IP phones as an example will send a voice traffic in the
UDP range 16 3 8 for up to 3 2 7 6 7.
So that's voice traffic.
Notice the signaling traffic that's referenced here as an example that's.
This is a treaty 3.
This is MVP.
This is skinny so explicit port numbers are matched for VoIP control.
And here this port range is used for RTP and all DCP
RTP is a protocol used in RTP to give quality of service information back to a sender so notice we are
matching both RTP the actual audio and all DCP traffic that's put into this RTP untrusting Klaus SAP
skinny H3 3 and other signalling protocols are put into this VoIP control untrusted CLOs and here we
have remarking.
So if someone sends us e f traffic what we gonna do is we're going to read market.
So notice down here any traffic that's received marked as E F CLOs elect a 3 or a f 31 is a remarked
as default.
In other words it's marked as a zero based effort traffic save rather three is marking its traffic as
E F and then sends it across this link to write a one rather one is going to read market as a zero because
right one doesn't trust wrote it two in the way that I've configured this so any of these traffic types
will be remarked as default traffic voice traffic.
Based on this match RTP audio and the access list of the RTP port range will have its bandwidth set
to 70 percent.
So again voice traffic will be poor terrorized over other traffic types.
This is an example of low latency queuing with a priority bandwidth set to 70 percent.
But notice it's also mocking the traffic as E.F..
On this side the traffic wasn't marked because we trusting the markings that we receive on the side.
We don't trust the markings that we receive.
So we mock the traffic ourselves so RTP voice traffic is set to E.F. call signaling is set to a f 31
and gets a guaranteed minimum bandwidth of 5 percent traffic that we receive that's already marked as
e f or C as three will f 31 is marked down to best effort.
Other traffic is queued using fake queuing so these two classes share the remaining 25 percent.
That's not used by voice and signaling when there's congestion.
This is an example of using order cause VoIP to provide a good quality of service to voice traffic.
And again it's at the detriment of other traffic on the network but because of voice traffic is high
priority low latency.
It's power to rise over other traffic types and is given a priority queue of 70 percent.
This is an example of using order chaos.
This may not be right for your environment and you may want to manually configure quality of service
or allow order quads to discover the traffic on your network and then suggest policies.
Again you don't need to memorize all of this configuration but I wanted to show you an example of both
trusting and not trusting markings that a rider receives.
So in this example rider 1 doesn't trust Rider 2 but rather to trust the rider one.
Typically you would match those policies up so they would either both trust each other or neither would
trust one another.