cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
320
Views
0
Helpful
4
Replies
sarahr202
Contributor

mqc, class map. policy map

Hi everybody

Please consider the following:

R1(config) #class-map VOICE

R!(config-cmap)# match protocol rtp audio

R!(config)#policy-map TSHOOT-EXAMPLE

R19config_pmap)# class VOICE

R1(config-pmap-c)# priority 256

R1(config)# int s0/1

R1(config-if)# service-policy output TSHOOT-EXAMPLE

Let say if voice packets begins to use more than 256 kbps. What will happen next?  Will voice packets get droopped?

thanks and have a great day.

2 ACCEPTED SOLUTIONS

Accepted Solutions
John Blakley
Advisor

Sarah,

There is an automatic policing mechanism in priority class. If the circuit is saturated, your policy would guarantee 256k to the VOICE class and it will police the traffic at 256k. Now, if the circuit isn't saturated, that means that the policy isn't in effect, so the VOICE class can have as much bandwidth as it needs.

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

When a link is congested, packets will pushed into the CBWFQ policy. LLQ classes support an implicit policer, i.e. bandwidth consumption beyond the configured amount will cause class packets to be dropped such that the egress bandwidth conforms to the policed rate.  For example, in your question about what happens if the LLQ class is already at the defined rate, 256 Kbps, some of the class's ingress packets will be dropped such that the class egress wouldn't consume more than 256 Kbps.

As policing measures bandwidth consumption over some time period, and many flows are variable bandwidth consumption over time, it's difficult to easily predict what specific packets will be dropped when the "offered" rate exceeds the policed rate.

BTW, generally if you're working with real VoIP traffic, you don't want any "random" drops.  Your VoIP flows should always be within the allocated bandwidth for them.  Ideally, VoIP bandwidth consumption should be controlled by limiting the number of concurrent calls.

View solution in original post

4 REPLIES 4
John Blakley
Advisor

Sarah,

There is an automatic policing mechanism in priority class. If the circuit is saturated, your policy would guarantee 256k to the VOICE class and it will police the traffic at 256k. Now, if the circuit isn't saturated, that means that the policy isn't in effect, so the VOICE class can have as much bandwidth as it needs.

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post

Thanks John.

Let assume circuit is saturated  voice packets are currently using 256 k. Let assume R1 receives more voice packets but the current bandwidth consumption by voice packet is already at 256 k( the maximum allowed as per policy). What will R1 do next with these new voice packet it just receives ?

thanks.

The new voice packets will be policed to the 256k speed. The priority command allows the router to set aside a guarantee, but it doesn't allow it to saturate the link in order to give fairness to other queues. If the router is congested and the voice class is already using 256k, any new packets that arrive would be dropped.

HTH,

John

HTH, John *** Please rate all useful posts ***

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

When a link is congested, packets will pushed into the CBWFQ policy. LLQ classes support an implicit policer, i.e. bandwidth consumption beyond the configured amount will cause class packets to be dropped such that the egress bandwidth conforms to the policed rate.  For example, in your question about what happens if the LLQ class is already at the defined rate, 256 Kbps, some of the class's ingress packets will be dropped such that the class egress wouldn't consume more than 256 Kbps.

As policing measures bandwidth consumption over some time period, and many flows are variable bandwidth consumption over time, it's difficult to easily predict what specific packets will be dropped when the "offered" rate exceeds the policed rate.

BTW, generally if you're working with real VoIP traffic, you don't want any "random" drops.  Your VoIP flows should always be within the allocated bandwidth for them.  Ideally, VoIP bandwidth consumption should be controlled by limiting the number of concurrent calls.

View solution in original post