max-reserved bandwidth command

[maher]

Hi,

I want to achieve 50% out of physical interface is allocated for Voice traffic and the remaining 50 % allocated for class-default...

I was wondering either is it appropriate or best practise to use the max-reserved bandwidth command to override the default 75% for QoS for Voice and class-default?

thanks in advanced.

maher

[ilya.varlashkin]

It quite depend on your interface type. Keep in mind that for certain link types router can not calculate correctly actual size of data on the wire and this will make scheduling go wrong. For example, on ATM PVC (e.g. DSL) router will take into account AAL5 overhead but will not see ATM cell overhead because segmentation of AAL5 packet into cells happens on the main interface and not on sub-interface. Slightly different thing happens on Ethernet interfaces - user-accessible part of standard Ethernet packet is 1518 bytes, however there is actually equivalent of 1538 bytes occupying the wire (some bytes, some silent periods); since it's PHY sub-layer that adds that extra 20Byte equivalent overhead, scheduler doesn't take it into account.

Another type of problem is with the routing protocols - at least on some router models packets originating directly on the router bypass user-applied QoS and instead transmitted based on so called PAK_PRIORITY. Your service-policy may start behaving funny if you ignore this fact. This is reason why Cisco says that remaining 25% are left-over for L2 overhead and routing protocols.

True is that 25% is quite generic and for some situations it might be too much, for others might be too little. For example, if you only transmit 60Byte voice packets (IP-layer size), then on ATM (DSL) interface you could only get about 50% of useful bandwidth, i.e. on 2304Kbps DSL link if you send only about 1100Kbps of voice data, your link is actually full and there's nothing left for class-default. So to answer your question - yes, you can change 'max-reserved-badnwidth' but you need to carefully investigate what is maximum amount of unaccountable traffic you can have on your link (L2 overhead, routing etc.)

Yet another problem with allocating 50% for voice is that this packets are transmitted whenever they happen to come to the router (packets already in tx-ring are not preempted though). Too much traffic in strict priority queue (LLQ) may starve other traffic of bandwidth to the point where non-voice traffic doesn't have any chance to be transmitted even if link is not fully utilised. Generally allocating above 30% of the link to LLQ should be done very carefully and with prior testing.

Hope this answers your question.

[maher]

Hi Ilya,

Thanks for the clarification and information.

BTW, regarding allocating too much to LLQ and it is possible to starve other traffic, like my case class-default right.

If I configured on 1024K link between PE and CE:

class-map match-all voip

match ip dscp ef

policy-map VOIP

class voip

priority percent 50

class class-default

fair-queue

Is it possible that class-default traffic can override and use other 50 % if VOIP traffic is not congested or not use at all. How can I make the other traffic should be able to utilized on certain class?

Thanks in advance.

maher

[ilya.varlashkin]

Hi Maher,

what you're asking for is actually default behaviour - if some class is not using all reserved bandwidth, the leftover will be fairly distributed among other classes provided that those other classes are not configured with hard policer setting upper limit.

Unused bandwidth is not devided into classes as such, so you can't specify "use leftover from that class, but not from this class".

Unlike time-division multiplexing (like fractional E1 links), IP QoS reserves bandwidth not directly but by using buffers and token-bucket scheduler. Buffers ensure that traffic can be temporarily stored within limits of reserved bandwidth. If some traffic doesn't use bandwidth completely, its buffers are NOT used for other traffic. However if the line is free (that is there are no packets in other class buffers), then traffic from let's say class-default will be simply sent out to the wire without buffering.

So saying simply: reserved bandwidth = buffer(ing), use leftover - send out without buffering as long as we can.

I have seen installations that have asked for 50% reserved bandwidth for voice class, however they've never used it, while traffic in class-default was performing poorly because they generally had more than 50% of the line rate in class-default so not everything was buffered. Besides buffering also keep in mind that WRED will kick in based on the buffer fill-level and not the line fill-level. So WRED can start randomly drop packets in your class-default even when the line is relatively free.

You should carefully consider how much bandwidth you need in each class. A good approach could be configuring a policy with all classes defined but without any bandwidth guarantees. After about a week of monitoring you could see how much traffic you have in each class, then you can add 'bandwidth' and 'priority' commands to your policy. Auto-QOS does basically the same, although I prefer manual configuration.

[globalnettech]

Hello Maher,

the 'max-reserved-bandwidth' command is actually one of 2 different ways to achieve your goal. Based on an E1 serial connection, you can configure:

interface Serial0

max-reserved-bandwidth 100

service-policy output QoS

!

class-map match-all VoIP

match access-group 101

!

policy-map QoS

class VoIP

bandwidth percent 50

!

access-list 101 permit tcp any any eq 1720

access-list 101 permit udp any any range 16384 32767

Or:

interface Serial0

service-policy output QoS

!

class-map match-all VoIP

match access-group 101

!

policy-map QoS

class VoIP

bandwidth 1024

!

access-list 101 permit tcp any any eq 1720

access-list 101 permit udp any any range 16384 32767

Check the available bandwidth with the command 'show queue serial0'

HTH,

GNT

[maher]

hi GNT,

Thanks for the example. Will test it :)

maher