q1) does this means the more bandwidth allocated to the class, the more weight and priority it has to be de-queue earlier ?
Yes and no. A class with a higher bandwidth guarantee, and a better "weight", all else being equal, will be dequeued more often, but that classes packets don't really have "priority" over the other class with the worst "weight".
For example, these two policies, as exactly configured, should provide the same dequeuing results:
policy-map LLQ1
class Foreground
priority percent 10
class class-default
bandwidth percent 90
policy-map LLQ2
class Foreground
priority percent 10
class class-default
bandwidth percent 1
but given the policy:
policy-map no-LLQ1
class Foreground
bandwidth percent 99
class class-default
bandwidth percent 1
This latter policy should provide results much like the two LLQ policies, but perhaps not exaclty the same. (Also, the LLQ classes have an implicit policer, which I've ignoring. Here I'm just concerned with dequeuing prioryites.)
Further if we had policies like (which appear more similar to the two LLQ policies):
policy-map no-LLQ2
class Foreground
bandwidth percent 10
class class-default
bandwidth percent 90
policy-map no-LLQ3
class Foreground
bandwidth percent 10
class class-default
bandwidth percent 1
They are quite different from the LLQ policies, and each other. If this is still a bit unclear, dequeuing ratios, for all these polices would be:
LLQ1: absolute priority:doesn't-matter
LLQ2: absolute priority:doesn't-matter
no-LLQ1: 99:1
no-LLQ2: 1:9
no-LLQ3: 10:1
q2) what if i have some traffic that are of higher priority but does not required that much of bandwidth ?
You might place such into LLQ (and the latter CBWFQ implementations now offer two levels within LLQ), or you need policies, with this traffic in the "Foreground" class, more like no-LLQ1 or no-LLQ3, NOT no-LLQ2.
BTW, a common example of such traffic being sent to LLQ, when it doesn't really need LLQ, would be VoIP control traffic. However, it doesn't so much need LLQ's low latency but insurance it's not dropped.
q3) i have some udp heartbeat packets that are of great importance and cannot tolerate any drops - is allocating them to the LLQ/priority queue the only option ? the rest of the classes/queues seems to have WRED configured
No, LLQ isn't the only option, see answer to q2. Also if using a CBWFQ with LLQ levels, you might place them there, but in the 2nd level. (NB: I believe the intent of 2nd level LLQ is really for real-time video.)
Further, if they are in a class with WRED (which I very, very strongly recommend against using, unless you're QoS wizard - class FQ is often much, much better choice), if distinctly tagged, you could set WRED parameters to (hopefully) not drop those UDP packets (latency/jitter different issue).
BTW, here's my handy-dandy, only four class, QoS policy (which effectively deals with most QoS needs):
policy-map General
class real-time
priority percent 35
class Foreground
bandwidth remaining percent 81
fair-queue
class Background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
For usage, traffic that really needs priority, provide best latency/jitter (e.g. VoIP bearer), is directed to the "real-time" class.
All other traffic, by default, goes to "class-default", where FQ, usually, keeps heavy bandwidth flows from being adverse to light bandwidth flows.
(BTW, sometimes I demonstrate the "power" of FQ by first opening a telnet session across a link. Then I slam multiple UDP traffic generated flows across that link, filling it. [Often I generate more than 100% of link's capacity in UDP test flow bandwidth.] The telnet session becomes about totally useless. Then I enable FQ. Then telnet starts working almost like there's no UDP test traffic.)
If you have some light bandwidth usage traffic that really, really (really) needs priority (but not LLQ level), and/or is really critical, but FQ isn't working well enough (and there are some possible cases with Cisco's FQ), you direct that traffic to the "Foreground" class.
If you have some heavy bandwidth usage traffic, that will work okay with "left over" bandwidth (e.g. large bulk TCP data transfers), you direct that traffic to "Background" class.
In theory, the Foreground and Background classes could work w/o FQ, because in the former, there shouldn't be much, if any queuing, and in the latter, the traffic flow(s) shouldn't "care" about optimal performance. Yet, I still recommend FQ for those classes too. Why? In the former, just in case there are multiple flows and there's congestion. In the latter, it "just works better" (w/o me describing why).
