Marwan ALshawi Tue, 08/12/2008 - 16:44
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

ok

to simplified for u


all the mentioned method are commen but each one has its use and capabilities


Class based wited faire queuing CBWFQ is used to reserve an amount of bandwidth for spisific traffic in case of conjestion while if there is no conjestion the traffic can go above that resrved traffic

it configured with the command bandwidth


Low Latency Queuing LLQ if an enhacement to the priority queue its work basicly the same as CBWFQ that resirve amount of traffic in case of conjestion BUT it use deffrent queue for it and always serviced first before other queues so it is the best for time-sensitive traffic such as voice over ip

it configured with the command priority


Wighted randon early ditiction

it is droping method but it is an enhancemnt to the tail droping because WRED start drop the lower classes first based on cos or dscp so that the voice traffic will not be selcted first to be droped incase of conjestion


that was a breif backgroun for all those mechnisems


good luck


please, if helpful rate

austindaz Tue, 08/12/2008 - 16:50
User Badges:

Hi there;


Is there any point in running QoS over a LAN? ie - would the LAN fall over anyway if it came down to having to apply QOS to time sensitive traffic?

Hope that makes sense?

Thanks

Joseph W. Doherty Tue, 08/12/2008 - 17:02
User Badges:
  • Super Bronze, 10000 points or more

If you interface congests, even if it's temporary congestion, and if your traffic is adversely impacted by the congestion, then QoS is a practical requirement.


Even when there's no adverse conditions, some QoS techniques can actually improve throughput, such as the RED or FQ variants which might avoid global tail drop.

4rmorris Tue, 08/12/2008 - 16:59
User Badges:
  • Bronze, 100 points or more

Regarding low latency queuing, it's important to note that the LLQ will be restricted to the bandwidth configured by a built in policer. It will not use additional bandwidth even if available.


Regards,


Ryan

austindaz Tue, 08/12/2008 - 17:02
User Badges:

LLQ would be no good for us then. Would CBWFQ be more appropriate?

Marwan ALshawi Tue, 08/12/2008 - 17:10
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

here i DISAGREE with Ryan because


LLQ Policing

The threat posed by any strict priority-scheduling algorithm is that it could starve lower-priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the interface is experiencing congestion.


the source is cisco press qos end to end, 2004

so whenever bandwidth avilable the LLQ will use but the policer will came in effect in case of the link get conjested


also see the following link for prevous discussion regarding the same point




http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Service%20Providers&topic=MPLS&topicID=.ee8558c&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cc18a05/3#selected_message


thank you


hop this helpful

Marwan ALshawi Tue, 08/12/2008 - 17:13
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

here i DISAGREE with Ryan because


LLQ Policing

The threat posed by any strict priority-scheduling algorithm is that it could starve lower-priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the interface is experiencing congestion.


the source is cisco press qos end to end, 2004

so whenever bandwidth avilable the LLQ will use but the policer will came in effect in case of the link get conjested


also see the following link for prevous discussion regarding the same point




http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Service%20Providers&topic=MPLS&topicID=.ee8558c&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cc18a05/3#selected_message


thank you


hop this helpful

4rmorris Tue, 08/12/2008 - 17:21
User Badges:
  • Bronze, 100 points or more

hm... you might be right:

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


Read down to the LLQ Bandwidth Allocation section.


However I've been to Networkers sessions where the doc I linked above was contradicted. Guess I'll have to test it to be sure.


Thanks!


Ryan

Marwan ALshawi Tue, 08/12/2008 - 18:36
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

i got confused with LLQ policer bfore too,:)


anyway i am happy with this nice discussion

thank you guys for rating

Joseph W. Doherty Tue, 08/12/2008 - 16:55
User Badges:
  • Super Bronze, 10000 points or more

Perhaps the most common might be WFQ (weighted fair queuing) since it's often the default for T1/E1 or slower serial interfaces. (Otherwise, FIFO is usually the default.)

austindaz Tue, 08/12/2008 - 16:58
User Badges:

Hi There;


Is there a drawback to running QoS on a LAN? Is there a need with time sensitivie traffic?

4rmorris Tue, 08/12/2008 - 17:01
User Badges:
  • Bronze, 100 points or more

LAN QoS is a little more complicated, as you're dealing with hardware queues in switches. Check out the QoS docs for the model you're using.


In general, LAN QoS is not required due to the large bandwidths available. However, if there's a virus outbreak or a misbehaving PC that's sucking up all the bandwidth, LAN QoS will protect priority traffic on congested uplinks.


Drawback: complexity (check out the "auto qos" feature for some simplification)


Benefit: critical data protected in case of congestion on LAN links.


Regards,


Ryan


husycisco Wed, 08/13/2008 - 06:56
User Badges:
  • Gold, 750 points or more

Hello,

My 2 cents here...

QOS provides a predictable level of service to particular applications. And some documentations refer as Guaranteed service level. Then the question 1)What makes my service not be delivered in a desired level of service? Answer is congestion. 2)Where does it happen? In interface hardware queues that has more offered packets than it can actually put on to wire in the given period of time (1.5 Mbit per secon for T1 for example) 3)How can I understand if I really need QOS in a specific device? Simply display interface stats and compare the dropped amount of packets with transmitetd amount of packets. Substract ACL drops in firewalls 4)Would I need QOS in LAN? Heavily depends on your architecture, but actually a virus outbreak or misbehaving PCs are not the primary reasons. The primary reason is the congestion possibility in uplink ports. Even larger bandwidths are available congestion is still an issue (10+ 100MB ports can congest a 1G uplink port) 5) Dont pull me into the complex world of MQC! OK then, simply issue auto discovery QOS in specific interface, let it run a couple of days and analyze your traffic, then show the policy-maps that device created for you, then apply it with auto qos command. If you have any issues with the Auto QOS created policy, simply paste it here and let us advise according to your needs. 6) I dont have voice or delay sensitive traffic. Do I still have to use LLQ? Actually, voice and video are not the only delay sensitive traffic. Dynamic routing protocol traffic like hellos also have to be prioritized over others. I have seen an issue in which neigbor relationships were flapping due to hellos waiting behind the other CBWFQ processed class packets.


Regards

Actions

This Discussion