Sh policy-map LLQ counters showing strange results.

Question

I've config'd LLQ for video conferencing across a dual-T1 multilink connection. When I have a video conf. session going, the Class-map counters for 'packets', 'match' and 'pkts matched' under queueing being exactly the same. This is supposed to show either that all packets are being processed switched - which they aren't, or that there is congestion on the link, but there isn't. There is nothing else going across the link except my telnet session I use to get the counters. I would have expected all counters, except Class-default, to be zero under the queueing area, and then when I flood the link with large file transfers, the other class queueing counters to begin incrementing - but all counters are equal even without congestion. This doesn't help me prove that my QOS LLQ is working properly. What gives?
Here is the config and some outputs:
policy-map WAN-multilink
class Voice
priority 90
class Video
bandwidth 460
class Call-Control
bandwidth 27
class class-default
fair-queue
random-detect
policy-map QOS_classes
class Voice
priority 90
class Video
bandwidth 460
class Call-Control
bandwidth 27
class class-default
fair-queue
interface Multilink1
ppp multilink
ppp multilink fragment delay 20
ppp multilink interleave
ppp multilink group 1
max-reserved-bandwidth 95
service-policy output WAN-multilink
interface Serial0/2/0
bandwidth 1536
encapsulation ppp
no fair-queue
service-module t1 timeslots 1-24
ppp multilink
ppp multilink group 1
max-reserved-bandwidth 95
interface Serial0/3/0
bandwidth 1536
encapsulation ppp
no fair-queue
service-module t1 timeslots 1-24
ppp multilink
ppp multilink group 1
max-reserved-bandwidth 95
MDF-VoIP-RT2811#sh int stats
Multilink1
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 2175 179609 2436 237735
Route cache 7519 3809321 7416 2108198
Total 9694 3988930 9852 2345933
MDF-VoIP-RT2811#sh policy-map int mu 1
Multilink1
Service-policy output: WAN-multilink
Class-map: Voice (match-any)
2037 packets, 411126 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
2037 packets, 411126 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 90 (kbps) Burst 2250 (Bytes)
(pkts matched/bytes matched) 2037/411126
(total drops/bytes drops) 0/0
Class-map: Video (match-any)
1919 packets, 1087702 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af41 (34)
1919 packets, 1087702 bytes
5 minute rate 0 bps
Match: ip precedence 4
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 460 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1919/1087702
(depth/total drops/no-buffer drops) 0/0/0
Class-map: Call-Control (match-any)
430 packets, 31418 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
430 packets, 31418 bytes
5 minute rate 0 bps
Match: ip precedence 3
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 266
Bandwidth 27 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 430/31418
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
4669 packets, 612771 bytes
5 minute offered rate 3000 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

Answer 1

In accordance with the above, you would need to apply the policy to the subinterface.
As my collegue clearly depicts, you should be able to combine the two pvc's into one, that would also be the scenario where the policy comes in action. When you are sending voice over a dedicated pvc there is little need to prioritize the flow. This equals the configuration where you have a dedicated leased line for voice.
regards,
Leo