RE: bandwidth remaining percentage

From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Tue Sep 06 2005 - 15:18:36 GMT-3


It can make CLI easier, but for the purposes of the exam, the usual
rules apply of needing to answer what is asked :)

Chris

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Tuesday, September 06, 2005 12:46 PM
To: Chris Lewis (chrlewis); ccielab@groupstudy.com
Subject: RE: bandwidth remaining percentage

Chris,

Based upon what you are saying, it seems to me that using bandwidth
remaining percent might be a better implementation for any class of
traffic specified within a policy that uses LLQ.

So, put another way, it might just be better to use bandwidth remaining
percentage whenever there is a LLQ. Yes?

andy

-----Original Message-----
From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com]
Sent: Thursday, September 01, 2005 7:26 PM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: RE: bandwidth remaining percentage

Here is one example;

 policy-map pm1
  class traffic
   bandwidth remaining percent 90
  class voice
   priority percent 20
  class class-default
   bandwidth remaining percent 10

The show policy-map output looks like this

Router1(config-if)#service-pol out pm1
Router1(config-if)#do sho policy-map int
 Serial3/0

  Service-policy output: pm1

    Class-map: traffic (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol ip
      Queueing
        Output Queue: Conversation 265
        Bandwidth remaining 90 (%) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: voice (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip rtp 16383 16383
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 20 (%)
        Bandwidth 308 (kbps) Burst 7700 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      1 packets, 24 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Output Queue: Conversation 266
        Bandwidth remaining 10 (%) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 1/365
        (depth/total drops/no-buffer drops) 0/0/0

So voice gets 308K, which is 20% of 1544Kbits as expected, and we are
not told what the other classes get, which is in contrast to what we see
when we use bandwidth percent.

 policy-map pm3
  class voice
   priority percent 20
  class traffic
   bandwidth percent 30
  class class-default
   bandwidth percent 25

Router1(config-if)#do sho policy-map int
 Ethernet0/0

  Service-policy output: pm3

    Class-map: voice (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip rtp 16383 16383
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 20 (%)
        Bandwidth 2000 (kbps) Burst 50000 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: traffic (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol ip
      Queueing
        Output Queue: Conversation 265
        Bandwidth 30 (%)
        Bandwidth 3000 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
          
    Class-map: class-default (match-any)
      1 packets, 60 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Output Queue: Conversation 266
        Bandwidth 25 (%)
        Bandwidth 2500 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 1/390
        (depth/total drops/no-buffer drops) 0/0/0

The reason is that bandwidth remaining will allocate available bandwidth
in the percentage defined in the configuration, so in the example given,
the worst case for the class traffic is it gets 90% of 1544-308 (1112)
if the priority traffic fills the priority queue, if the priority
traffic uses less than that, class traffic gets something more than
1112, but only in the proportion of 90% of whatever the priority traffic
is not using.

In terms of wording, you could be asked to configure a given amount for
priority, then be told to use a percentage scheme for allocating
bandwidth to the other classes, where the allocation must total 100%
(which you could not do using just bandwidth percent). Maybe they would
reference something about the difference in the output of the show
policy map display, maybe showing you this policy map and telling you to
make the router display that (as they do with BGP tables sometimes).
Alternatively they could ask about unused bandwidth being assigned in
the proportion of its allotment, but that I think would be hard to word
precisely, but you never know :)

Chris

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Thursday, September 01, 2005 6:12 PM
To: ccielab@groupstudy.com
Subject: Re: bandwidth remaining percentage

Anyone have a better explaination of when to use the remaining
percentage than CCO?

Explain it to me like a 5 year old? 8)

I know that it's the relative bandwidth available after LLQ, RSVP, and
ip rtp priority. But what type of example (wording) might lead you to
use it?

andy



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3