cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1107
Views
15
Helpful
16
Replies

QoS statement

John Blakley
VIP Alumni
VIP Alumni

Based off of the following configuration, do you think this will limit all NON-VOIP traffic to 768? If voice traffic isn't going across, will it allow all other traffic to use the full bandwidth of the link?

policy-map VOIP

class VOIP

priority 768

class class-default

fair-queue

random-detect dscp-based

Service-policy output: VOIP

Class-map: VOIP (match-any)

306 packets, 14019 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 110

306 packets, 14019 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 768 (kbps) Burst 19200 (Bytes)

(pkts matched/bytes matched) 25/1244

(total drops/bytes drops) 0/0

Class-map: class-default (match-any)

3743 packets, 393837 bytes

5 minute offered rate 11000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/0/0

exponential weight: 9

Thanks!

John

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

guruprasadr
Level 7
Level 7

HI John, [Pls RATE if HELPS]

The "priority command" implements a maximum bandwidth guarantee.

The real benefit of the priority command-and its major difference from the bandwidth command-is how it provides a strict de-queueing priority to provide a bound on latency.

The "bandwidth command" provides a minimum bandwidth guarantee during congestion.

During the NO-VoIP Traffic condictions, if you want to utilize the link means use,

"bandwidth command"

using command:bandwidth {kbps} (or) bandwidth percent {value}

Hope I am Informative. Pls Rate if HELPS

Best Regards,

Guru Prasad R

milan.kulik
Level 10
Level 10

Hi,

this should limit your VOIP traffic to 768.

(It's not visible how you mathc the traffic to the VOIP class though.)

If there's no VOIP traffic, the full bandwidth should be available to other traffic.

BR,

Milan

As Milan notes, non-VoIP in your post can use all available bandwidth (up to the link's full capacity.)

However, recently discovered LLQ's implicit policer will only be limited to the defined limit when there's congestion. I.e. your VoIP could also use all the link's bandwidth or more than the defined limit when there's no congestion.

So, because I have "priority 768", that only allows a guaranteed 768, but it can go above that?

John

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

John

Basically yes. Priority 768 is a guarantee of bandwidth during periods of congestion. It is also a guarantee that no more than 768 will be used during periods of congestion.

But if there is no congestion then any traffic that is over 768 can still use available bandwidth on the interface.

Jon

Yes, so I understand (as so seems does Jon). If there's really a need to always cap the rate you can define an explicit policer or shaper within the LLQ class.

Hi Joseph,

this is a question I'd like to clarify:

If LLQ (CBWFQ with a PQ) configured, what happens with a traffic matching a Priority Class and exceeding the bandwidth reseverd by "priority" command in a case there's no congestion on the line?

I asked this question to several QoS gurus and 50% of them replied "If there's a bandwidth available, there's no reason to drop anything." while other 50% replied "There is an implicit policer included in the LLQ PQ. The exceeding traffic will be dropped."

I'd really like to clarify this question.

Don't you pls have any link to CCO document or CiscoPress book confirming the correct answer?

Thanks,

Milan

I too used to believe the latter (LLQ implicit policer drops when exceeded, always), but have read Cisco documentation for the former (LLQ implicit policer only drops when there's congestion). Writing that, I'm sure you would like the reference, but I don't have it at hand. I'm sure you might be able to find it on Cisco's site.

I have not, however, tested actual LLQ implementation of its implicit policer operation because for practical purposes I assume the implicit policer is always active.

If in fact LLQ's implicit policer is only active when there's congestion, it's likely the policer is tied to LLQ's software queue. Packets first go to the interface hardware FIFO queue and only when they overflow that queue do the software queues have packets.

From the 12.4 configuration guides -

"In the event of congestion, policing is used to drop packets when the bandwidth is exceeded"

"When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded."

Full link -

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/congstion_mgmt_oview_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1003189

I have always read this to mean that if there is no congestion on the interface then any traffic type, whether it is mapped to the priority queue or not, can use any available bandwidth on the interface.

I do remember a lab i did a while back where i used FTP between a client and a server separated by a router. The baseline was to transfer a large file from client to server with no QOS configuration.

From memory i recall i tried 2 things

1) policed the traffic to 1Mb on the outbound interface and the result was a much slower transfer than the baseline.

2) Allocated the FTP traffic to the priority queue and then allocated the priority queue 1Mb. The result was no difference from the baseline.

Now i am wondering if i remember incorrectly :-), so i should probably go and retest i guess !

Jon

Joseph / Milan

Ran this in the test lab. Not entirely sure it proves the point ??. Perhaps if you both

checked the configuration, my figures and my logic !!

Setup

=====

SW1 (fa0/4) - (fa0/1) R1 (fa0/0) - (fa0/4) SW2

SW1 is tftp-server. SW2 tftp's IOS from SW1. After each run the IOS is deleted from flash.

Normal run is with no QOS applied anywhere on 100Mb interfaces.

Then apply a shape average of 512k outbound on the fa0/0 interface of R1. **

Then apply a priority queue with a bandwidth of 512k outbound on the fa0/0 interface of R1.

** Note - i tried using policing rather than shaping but packets were getting dropped everywhere.

TFTP being a UDP application does not have the recovery mechanisms that TCP has.

The very fact that when i applied the priority queueing i did not get the same set of results as

when i applied the policer directly to the interface again suggests that without congestion the

tftp traffic will use all available bandwidth.

Baseline

========

1st run - 7136047 bytes copied in 181.080 secs (39408 bytes/sec)

2nd run - 7136047 bytes copied in 169.716 secs (42047 bytes/sec)

3rd run - 7136047 bytes copied in 169.016 secs (42221 bytes/sec)

Apply shaping to router interface fa0/0

=======================================

access-list 101 permit ip any any

class-map match-all POL

match access-group 101

!

!

policy-map POLICE

class POL

shape average 512000

!

interface FastEthernet0/0

ip address 192.168.6.2 255.255.255.252

duplex auto

speed auto

service-policy output POLICE

end

1st run - 7136047 bytes copied in 229.460 secs (31099 bytes/sec)

2nd run - 7136047 bytes copied in 229.004 secs (31161 bytes/sec)

Control Runs

============

Remove service-policy off int fa0/0

-----------------------------------

Control run - 7136047 bytes copied in 168.460 secs (42360 bytes/sec)

Apply service-policy to int fa0/0

---------------------------------

Control run - 7136047 bytes copied in 228.676 secs (31206 bytes/sec)

Remove service-policy from int fa0/0

------------------------------------

7136047 bytes copied in 168.696 secs (42301 bytes/sec)

Priority Queue testing

======================

Apply service-policy with Priority queueing

-------------------------------------------

access-list 101 permit ip any any

class-map match-all PRI

match access-group 101

!

!

policy-map PRIORITY

class PRI

priority 512

!

interface FastEthernet0/0

ip address 192.168.6.2 255.255.255.252

duplex auto

speed auto

service-policy output PRIORITY

1st run - 7136047 bytes copied in 169.592 secs (42078 bytes/sec)

2nd run - 7136047 bytes copied in 168.760 secs (42285 bytes/sec)

Jon

Hi Jon,

thanks for your effort!

Sorry to say that, but your test is not a prove for me.

I agree it indicates, as you said: "The very fact that when i applied the priority queueing i did not get the same set of results as when i applied the policer directly to the interface again suggests that without congestion the tftp traffic will use all available bandwidth."

IMHO, the test setup would need some improvement:

1. Not using Cisco switches as data traffic source/destination. TFTP (and also FTP)copying between Cisco devices is extremely slow and unreliable for any testing.

2. QoS should be applied on a low-bandwidth serial inteface, not FastEthernet. I'm afraid FE QoS implementation might be different from a serial one.

I'll thry to build a lab with improvement described "when I have some free time".

I think it's a Cisco shame we have to discuss such a basic questions here and even build labs to get answers :-(

This should be clearly stated in the documentation!!

I already opened a conversation

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Idea%20Center&topic=Cisco.com%20Technical%20Documentation%20Ideas&topicID=.2cc28e03&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc2d818

in the Cisco.com Technical Documentation Ideas forum, but Cisco guys don't seem to understand what I'm looking for :-(

Thanks and best regards,

Milan

Hi Milan

"Sorry to say that, but your test is not a prove for me." - interesting. I myself was not 100% comfortable with the test as it seemed a little "simple". Appreciate your straightforward reply.

1. Not using Cisco switches as data traffic source/destination. TFTP (and also FTP)copying between Cisco devices is extremely slow and unreliable for any testing.

Agreed - unfortunately i only had 2 switches and a router for testing. The test times were fairly consistent but i know what you mean about tftp and reliability.

2. QoS should be applied on a low-bandwidth serial inteface, not FastEthernet. I'm afraid FE QoS implementation might be different from a serial one.

Not sure about this one. I think LLQ is the same on all interfaces with the exceptions mentioned in the link ie. Frame relay LLQ etc.

" think it's a Cisco shame we have to discuss such a basic questions here and even build labs to get answers :-(

This should be clearly stated in the documentation!!"

I couldn't agree more. The link i posted with that clear statement is fine, but i'm sure i have also seen documentation that suggests the opposite. It is a very grey area in the docs i think.

Jon

Hi Jon,

I think I've got it!!!

Reading the document you provided the link to I found in the "Guaranteeing Bandwidth with the priority Command" section:

"The bandwidth value or percentage guarantees the configured bandwidth to the priority class under worst-case congestion scenarios. If excess bandwidth is available, the priority class will be allowed to utilize the bandwidth. If no excess bandwidth is available, the priority traffic will be constrained to the configured rate via packet drops."

This is the clear statement I was looking for!!

Thanks a lot,

Milan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco