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.
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
priority percent 50
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?
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.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...