QoS statement

Unanswered Question
Jan 23rd, 2009
User Badges:
  • Purple, 4500 points or more

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
guruprasadr Fri, 01/23/2009 - 07:43
User Badges:
  • Gold, 750 points or more

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 Fri, 01/23/2009 - 08:02
User Badges:
  • Red, 2250 points or more

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

Joseph W. Doherty Fri, 01/23/2009 - 10:00
User Badges:
  • Super Bronze, 10000 points or more

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.

John Blakley Fri, 01/23/2009 - 10:14
User Badges:
  • Purple, 4500 points or more

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


John

Jon Marshall Fri, 01/23/2009 - 10:29
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Joseph W. Doherty Fri, 01/23/2009 - 10:58
User Badges:
  • Super Bronze, 10000 points or more

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.


milan.kulik Sat, 01/24/2009 - 04:04
User Badges:
  • Red, 2250 points or more

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

Joseph W. Doherty Sat, 01/24/2009 - 06:10
User Badges:
  • Super Bronze, 10000 points or more

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.

Jon Marshall Sat, 01/24/2009 - 07:29
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Jon Marshall Sat, 01/24/2009 - 10:00
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

milan.kulik Sat, 01/24/2009 - 14:05
User Badges:
  • Red, 2250 points or more

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





Jon Marshall Sat, 01/24/2009 - 18:06
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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



milan.kulik Sat, 01/24/2009 - 14:29
User Badges:
  • Red, 2250 points or more

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


Nicholas Matthews Sun, 01/25/2009 - 21:33
User Badges:
  • Red, 2250 points or more

For what it's worth, I got in an argument with someone on this functionality, and we proved it in the lab.


I configured an 8kb (minimum) priority queue for voice, and put in on a WAN circuit. Then, placed a call over it.


The 'show policy-map interface' showed that we were getting the full 8kb/s on the priority queue, plus run-over into the class-default.



So to confirm - the LLQ priority keyword only drops traffic with congestion. When you have congestion and traffic is dropped, the priority keyword becomes a policer.



hth,

nick

Actions

This Discussion