Unanswered Question
May 7th, 2007

Hi to all,

I have some questions about LLQ on ATM PVCs.

The config output is from the CPE (Cisco 878):

controller DSL 0

mode atm

line-term cpe

line-mode 2-wire line-zero

dsl-mode shdsl symmetric annex B

line-rate auto

interface ATM0

bandwidth 1536

no ip address

load-interval 30

no atm ilmi-keepalive

max-reserved-bandwidth 100


interface ATM0.100 point-to-point

bandwidth 1280

ip address

pvc 8/80

protocol ip

ubr 1536

encapsulation aal5snap

service-policy output QOS_VOIP

max-reserved-bandwidth 75

I there possible, that it do not work on UBR connections.

Howewer it seems that works:

HOST#sh policy-map interface

ATM0.100: VC 8/80 -

Service-policy output: QOS_VOIP

Class-map: VOIP (match-all)

18769209 packets, 1317687321 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 100


Strict Priority

Output Queue: Conversation 72

Bandwidth 384 (kbps) Burst 9600 (Bytes)

(pkts matched/bytes matched) 18769210/1317687404

(total drops/bytes drops) 0/0

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

34018060 packets, 12074991095 bytes

30 second offered rate 40000 bps, drop rate 0 bps

Match: any


Flow Based Fair Queueing

Maximum Number of Hashed Queues 64

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

Has anyone a Link of how configure LLQ on ATM PVCs?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Paolo Bevilacqua Mon, 05/07/2007 - 01:27


it seems configured correctly, but UBR 1536 does not give a chance to the service policy to kick in - there is no congestion to do so.

You should find the real value of the upstream PVC and test in presence of congestion.

UBR or other service category should not make a difference.

Hope this helps, please rate all useful posts using the scrollbox below!

thomas.feichter Mon, 05/07/2007 - 02:35


the "real upstream" is 1536 ATM (1280 kbit/s real IP traffic without ATM overhead).

The line is G.SHDSL symmetric.

The CIR is a weightless factor , because the ATM Net is ours, and there is no congestion.

What do you mean about this?..



Paolo Bevilacqua Mon, 05/07/2007 - 02:51


LLQ, like any other priority mechanism, will start working only when there is congestion (backpressure). When there is no congestion, packets are sent out immediately and never queued.

So to test if your QoS is working, you need to generate congestion and verify that voice has no issues, eg you can look at the codec jetter statistics available on the router, etc.

Note: the command

protocol ip

is not necessary on point-to-point subinterfaces.

Hope this helps, please rate post if it does!

nedian123 Mon, 05/07/2007 - 04:31


I think "Queueing Strict Priority" shows that LLQ is already working.




This Discussion