Hello Laz,
Thank you for your replay.
I fact when i use ping extend on cisco router on Packet tracer and specify a ToS different of 0. the ToS of packet generated doesn’t change. It remains 0 .
Hello Mohamed
I attempted to recreate the same scenario and I too saw that the DSCP value did not change within the header. This could be due to an issue with Packet tracer (I’m using version 7.1.0.0222). You’ll have to take it up with Packet Tracer themselves. There are several forums that specifically focus on the use of Packet tracer and your best bet is to take a look there.
I also suggest you try the same thing on GNS3 or on real equipment and using wireshark to capture the packets and see if you still get the same thing (just for verification).
I hope this has been helpful!
Laz
Hello,
Perhaps some notes can be added to this tutorial.
One could be something like:
During congestion the priority queue (voice) cannot use any bandwidth above the configured amount (2000 Kbps) since priority queue can drop all traffic from other queues.
Also the call signaling queue will have a minimum bandwidth of 1000 Kbps during congestion that will not be dropped by traffic from other queues.
The second could be something like:
ToS byte is composed of 6 (leftmost bits) from DSCP and 2 (rightmost bits) of ECN which are ignored. The DSCP value in decimal starts at 2^2 compared to the ToS value. In this case ToS (decimal) = 4 x DSCP (decimal).
A question I would like to ask:
Would be useful to apply the policy map for the traffic ingressing the device? For the vendors I work for and also in this tutorial the queuing is done on device egress. There cannot be a congestion for traffic that ingress the device (you cannot receive more than the link supports). At ingress you can apply hard limits like metering/policing to limit specific traffic.
Thank you,
Stefanita
Hello Stuat
Concerning your question, traffic that ingresses an interface can indeed be placed in a queue, or classified, have policing applied, or any number of other things. These are further described in this Cisco documentation which states the various QoS parameters that can be adjusted.
However, as you very correctly stated, if you have a volume of traffic coming in to a port that goes beyond the physical speed of that port, there is no way to buffer that traffic using any QoS mechanisms. Packets will be dropped. Queuing (and any other QoS mechanism) can only be applied to incoming packets that have successfully entered the interface.
As for your suggestions, thank you so much for your feedback. It is always helpful to see what readers find useful and where we can improve. It helps us to provide a better service! I will relay your suggestions to Rene.
Thanks again and I hope this has been helpful!
Laz
1 Like
Hi Ren and Laz,
I read this tourial but i confuse there nothing to match on class map
Example:
R2(config)#class-map VOICE
R2(config-cmap)#match dscp efR2(config)#class-map CALL_SIGNALING
R2(config-cmap)#match dscp cs3
and result :
Class-map: VOICE (match-all)
100 packets, 11400 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 2000 kbps, burst bytes 50000, b/w exceed drops: 0
Class-map: CALL_SIGNALING (match-all)
200 packets, 22800 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 200/22800
bandwidth 1000 kbps
“match-all” here meaning all traffic through router so Which is source IP that marking for voice traffic ? How does router know which is traffic voice or call_signal and router can treat it in QoS policy if we do not give an access-list here ?
I read this tourial: https://networklessons.com/quality-of-service/ip-precedence-dscp-values
but in my mind i know that we must classification (creat access-list ) before marking .
Hello Nguyen
The “match-all” here indicates that all statements in the specific class map must be matched in order to consider it a match. In contrast, you can have “match-any” which simply matches any one of the statements in the policy map. In our case here, we only have one statement in the policy map, so the match-all or match-any designation here will make no difference.
The traffic that is matched is always based on the condition in the class map. Specifically, for VOICE, any packet with a DSCP value of ef will be matched. Similarly for CALL_SIGNALING, any DSCP value of cs3 will be matched. We don’t need an access list here since in the class maps we are referencing DSCP values directly. If we were to use source and destination IP addresses as criteria, then we could create access lists that can be referenced by the class maps.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Thank your explain but i always think when a packet through router, it will classification by source IP and after that it marked by set an DSCP value and QoS policy will treat it base DCSP value
**
The traffic that is matched is always based on the condition in the class map. Specifically, for VOICE, any packet with a DSCP value of ef will be matched. Similarly for CALL_SIGNALING, any DSCP value of cs3 will be matched. We don’t need an access list here since in the class maps we are referencing DSCP values directly. If we were to use source and destination IP addresses as criteria, then we could create access lists that can be referenced by the class maps.
**
I don’t see how router know that packet is VOICE packet ort CALL_SIGNLING for marking .
Please correct if i wrong.
Hello Nguyen
In this scenario, voice traffic is DEFINED as that having a DSCP of ef. This is how the router knows the packet is indeed voice. Similarly, call signaling traffic is DEFINED as having a DSCP of cs3. The class maps are matching based on this criteria. The action that is being taken in each case is defined in the policy map. Specifically, voice traffic (DSCP of ef) will have a priority queue for 2000 Kbps and call signaling traffice (DSCP of cs3) will have a bandwidth guarantee of 1000 Kbps.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Agree and nothing if voice traffice or call signaling traffic defined with DSCP value and QoS processing
Something i still confuse here, example behind R1, I have subnet 192.168.100.0/24 , a phone with IP 192.168.100.100 and a PC with IP 192.168.100.200.
With your config :
-
How router know traffic from 192.168.100.100 is voice and call signal and treat it with high priority than from source 192.168.100.200 is normal.
-
And from PC, i using and app as 3CX to make phone call, and browser web at same times, how does router know and define with traffic from 192.168.100.200
Hi Laz,
Following this matrix table
so that your config following Cisco recomend and when config as below , router implicit know which is VOICE traffic and match it with ef DSCP value ?
R2(config)#class-map VOICE
R2(config-cmap)#match dscp ef
1 Like
Hello Nguyen
It is true that there is no guarantee that traffic that is marked as EF is voice and traffic that is marked as CS3 is call signalling. However, if you are managing your own network, then you can configure phones and other VoIP equipment to mark voice and call signaling traffic in this way, so you can discern what it is. It all depends on what QoS administrative policy you as a network engineer decide on using.
Once again, if you configure your network so that the phone will assign the appropriate DSCP markings, then you know that any packet with those markings is voice or call signalling. If there are no markings, then you know that it is not voice or call signalling, and can be treated accordingly.
This is a special case where you must use the capabilities of the operating system you are running on to mark voice packets. For windows devices for example, you must apply a Windows group policy to mark all the voice data with the desired DSCP which is generated by the softphone. You can use your favourite search engine to find out how to do this on Windows, or other operating systems.
As you can see, Cisco recommends EF for voice traffic and CS3 for call signalling. These are the DSCP values that Rene is using to match traffic. What Rene doesn’t mention in the lesson, which may be the source of the confusion here, is that we are implicitly ASSUMING that voice traffic has EF and call signalling has CS3 DSCP markings. If left to their defaults, this is what you would see, at least for IP phones, and this is why Rene used them.
I hope this has been helpful!
Laz
1 Like
Dear Rene,
I have some thing to clarify,
Assume,
LLQ is configured to have 20% of the total bandwidth,
and other 2 Queues are attached to CBWFQ with 50% and 30%,
and the total bandwidth of the link is 1Gig.
So in an event of congestion, LLQ gets 200 Mbps guaranteed ryt?
As per my understanding now, the remaining portion of the bandwidth which is 800 Mbps is shared among the other 2 queues in a round robin fashion.
Which means one CBWFQ queue gets 400 Mbps and the other one gets 240 Mbps.
Am I correct?
Hello Roshan
The values in percent correspond to the total bandwidth of 1 Gig. This means that 20% for the LLQ is 20% of 1000Mbps =200 Mbps. Queues 2 and 3 get 50% and 30% respectively, of the 1000Mbps as well, not of the remaining 800Mbps.
So queue 1 which is an LLQ queue will have 200Mbps guaranteed. Queue 2 and queue 3 will be served in a weighted round robin fashion resulting in them getting 500 Mbps and 300 Mbps respectively.
I hope this has been helpful!
Laz
1 Like
Thanks,
1 Like
Hello Team
Could you please help me to understand bandwidth remaining ratio concept. Also can you please let me know, how can I calculate the bandwidth of the class from the bandwidth remaining ratio command?
For example,
class pe_af4_output
**bandwidth remaining ratio 251 account user-defined 24**
queue-limit 282000 bytes
random-detect dscp-based
random-detect exponential-weighting-constant 7
random-detect dscp 32 70500 bytes 112500 bytes 10
random-detect dscp 34 70500 bytes 112500 bytes 10
random-detect dscp 36 21000 bytes 57000 bytes 5
random-detect dscp 38 21000 bytes 57000 bytes 5
class pe_af3_output
**bandwidth remaining ratio 108 account user-defined 24**
queue-limit 186000 bytes
random-detect dscp-based
random-detect exponential-weighting-constant 6
random-detect dscp 24 46500 bytes 75000 bytes 10
random-detect dscp 26 46500 bytes 75000 bytes 10
random-detect dscp 28 13500 bytes 37500 bytes 5
random-detect dscp 30 13500 bytes 37500 bytes 5Hello Payal
The way the bandwidth remaining ratio is used for sub-interfaces and class queues. It is used so that each of these can use a different ratio of the remaining (unprioritized) bandwidth. Otherwise, they are all treated the same.
The ratio is a weighted value. It can be any value between 1 and 1000. Here we see that the ratio is being employed between two class queues.
Specifically, the ratio of bandwidth that class pe_af4_output should get compared to pe_af3_output is 251/108 or 2.324 times more (of the unprioritized) bandwidth.
For more information about this feature, take a look at the following links:
I hope this has been helpful!
Laz
Hi
After reading this lesson and others would i be right in saying that the different types of QoS tags don’t actually “do” anything when you tag a packet with a particular QoS tag. Meaning that they don’t actually police, queue or drop packets by themselves. They’re just “tags” that are associated with particular devices and applications like VOIP is associated with the “ef” tag and “cs3” is associated with call signalling…
Thanks again
Hello Michael
Yes, you’re absolutely right. The QoS markings that are placed in the L2 frame header and in the L3 packet header are simply markings which don’t actually do anything. By marking packets/frames, you are simply classifying traffic.
In order for QoS mechanisms to function, a network device must be configured to do something specific with packets based on those markings. Queuing, policing, shaping, and trusting, can all be configured to take these markings into account and to prioiritize them accordingly.
Also, remember that QoS mechanisms only kick in whenever there is congestion. Congestion will occur whenever there is more traffic than a particular network path can handle, either due to bandwidth limitations of the physical interface, or due to a configured bandwidth limitation.
I hope this has been helpful!
Laz
Hi Laz,
Thanks for clarifying that up, i have one more question in relation to this if you don’t mind.
In regards to the priority queue and whatever bandwidth is assigned to it, how would any of the other queues ever get packets processed as well if there would always be a constant flow of voice packets through the priority queue?
I understand the config in the lesson but i keep thinking if there is always traffic coming into the priority queue then how would any other packet in another queue be processed as well?
Thanks again
Hello Michael
If you have a steady stream of marked voice packets and QoS mechanisms have been configured for LLQ, then these voice packets will indeed all go to the priority queue. You must remember however that the full capacity of the interface is at all of the queues’ disposal. And queuing will only “kick in” if you have congestion.
If you don’t have congestion on this interface, this means that the traffic that arrives on the interface is served immediately, no matter what its classification. In other words, as soon as a packet arrives at the interface, there is no delay in it being forwarded.
Queuing (and QoS mechanisms in general) have no meaning unless congestion is present. Now when congestion is present, and you configure a QoS LLQ, there is what is known as “an implicit policer” that limits the bandwidth that can be consumed by the priority queue. This is done to prevent bandwidth starvation of the non-priority queue flows serviced by the CBWFQ scheduler. The policing rate is set to match the bandwidth allocation for that particular priority queue. In the lesson, this is set to 2000 Kbps. So any excess traffic on the priority queue will be dropped by the policer. And keep in mind that the policer will only be “en force” whenever there is congestion and the queuing mechanism kicks in. If it does not, there is no limitation.
It is up to the network designer to ensure that the expected network traffic patterns and the infrastructure designed to carry them, are sufficiently well designed to allow for QoS mechanisms to handle high priority traffic successfully.
You can find out more about how this behaviour of LLQ at the following Cisco documentation:
I hope this has been helpful!
Laz