LLQ & Bandwidth Reservation

[landrew5]

Hey guys & gals,

I posted the following topic on the Cisco discussion forums and have not yet heard a response so I will post it here.

I have a question about Low-latency queuing. The following is configured on my branch routers to handle VoIP traffic.

!
class-map match-all VOICE
match ip dscp ef
class-map match-any CALL-SETUP
match ip dscp af31
match ip dscp cs3
!
!
policy-map LLQ
class CALL-SETUP
bandwidth percent 4
class VOICE
priority 256
class class-default
fair-queue
!
!
!
interface Serial0/0.105 point-to-point
description Primary_Frame_To_RCC-FRAME-R1
bandwidth 768
ip address XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
no ip redirects
no ip unreachables
no ip proxy-arp
frame-relay interface-dlci XXX
class BUR_TO_RCC
crypto map OutsideInterface
!
map-class frame-relay BUR_TO_RCC
frame-relay cir 1544000
frame-relay bc 15440
frame-relay be 0
frame-relay mincir 1544000
service-policy output LLQ
!
!

Now how I understand it above, it says that any packet that matches a DSCP code of EF gets placed in the class/queue VOICE that has a guaranteed and reserved (or at least I thought) bandwidth of 256K.

The reason I say "I thought" above is because recently we backed up one of our servers at night and noticed that the transfer rate was maxed (1.5 Mbps). But if the bandwidth is supposed to be reserved for the VOICE class/queue, should my transfer rate have risen past 1.28 Mbps???

Please let me know if I am interpreting this incorrectly. Thanks much everyone!!

-Lloyd

 

[pmesjar]

Queueing mechanisms are applied only when there is congestion on an interface. Did you send any voice packets simultaneously with file transfer?

One more point, I don't see command commands

frame-relay traffic-shaping
frame-relay class BUR_TO_RCC

in your s0/0.105 subif configuration, so your frame-relay map-class commands are useless in this subif. However, this has no impact on your issue.

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[landrew5]

Thanks Peter for the reply. My bad, I forgot to include the config of the major interface which does have the 'frame-relay traffic-shaping' command on there. The BUR_TO_RCC class is applied under the DLCI definition (frame-relay interface-dlci XXX).

And actually, this should have an effect on the queueing because the LLQ policy is applied under the class which is then applied under F/R DLCI config mode.

At the time the network backup was taking place, there were no voice packets being transmitted over the wire. I guess I just thought that LLQ was different that CBWFQ due to the 'priority' command actually reserving a guaranteed bandwidth.

Thanks again Peter for the reply.

-Lloyd

 

[pmesjar]

LLQ is a congestion avoidance technique, which means it tries to prevent your buffers completely because QoS can take place only if there is some space free in interface buffers. LLQ was specifically developed for VoIP traffic, which cannot take advantage of TCP windowing and acknowledgement techniques that is used with WRED. CBWFQ, on the other had is scheduling technique.

If you really want to reserve traffic for anytime and squeeze file downloads to about 1,28Mbps try traffic shaping mechanisms like CAR or FRTS.

Hope this helps a little further

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[supatech]

you may want to consider the auto QOS in 12.3

CCNA MCSE MCP NET+ A+ Security+