Traffic shaping question...  Hope you guys can help!

I have a 3750 with an E1 going elsewhere.  I want to specify 2 different 
groups of ip's (either destination or source, doesn't matter)  Where one 
group can send as much as they want, but I want the other group to NOT 
exceed 1/3 of the available bandwidth.

Is this possible?  I'm totally new to traffic shaping.  (Hope this is 
what I would use to accomplish this.)


TIA!!!

Hi

Can you clarify exacly what you want to achieve. I feel this group would 
need a clearer picture to be able to help.

Do you intend for group 1 to have the ability of starving group 2 of traffic 
below it's allocated third?
Do you want to limit group 2 to a third of the bandwidth even if there is 
capacity on the link unused?
Do you want a group to have priority transport to reduce delay when within 
contract?

Other things to consider are delay/jitter/discards. Placing policies on an 
interface has the effect that if you improve performance for one group you 
will reduce performance for the other. This sounds obvious, and is with 
regard to bandwidth but also delay and jitter can also be improved for one 
group and reduced for the other.  Have you considered the traffic types in 
the group you are planning to limit. Will they be affected in an undesired 
way.

e.g.

If voice traffic is in a group with priority transport, It would suffer less 
delay and reduced jitter as long as the policy is applied network wide which 
is good but you would need to ensure the bandwidth allocated was within the 
maximum that would be offered as discards due to bandwidth resraints would 
destroy the voice quality of all calls.  Also If you give priority to one 
group the other group would be restricted with at best increased jitter and 
at worst suffer discards. This could adversely affect again voice as 
jitter/delays/discards are bad but also affect interactive applications 
where the end user suffers stuttering and application freezes.

I state the above as it is dangerous to give advice in this instance with 
limited knowledge of the reasoning or to an explicit request.

Regards

Toby

"Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
news:30jutqF31llmbU1@uni-berlin.de...
> Traffic shaping question...  Hope you guys can help!
>
> I have a 3750 with an E1 going elsewhere.  I want to specify 2 different 
> groups of ip's (either destination or source, doesn't matter)  Where one 
> group can send as much as they want, but I want the other group to NOT 
> exceed 1/3 of the available bandwidth.
>
> Is this possible?  I'm totally new to traffic shaping.  (Hope this is what 
> I would use to accomplish this.)
>
>
> TIA!!! 

Thanks for your reply, I will try to explain what it is I am after...

I have two groups that are paying for this line(an E1), one of them (we 
can call them "group 1") pays 2/3's of the cost of the line and the 
other ("group 2") pays the remaining 1/3.  I want to limit the lesser so 
that they don't pummel the line consuming more bandwidth than they 
rightly should.

This line is strictly data, no voip.  Mostly FTP transmissions.

I aim to limit "group 2" so that they will not abuse the line.  And so 
that "group 1" will have the pipe they pay for.


HTH,

Jesse



Toby wrote:
> Hi
> 
> Can you clarify exacly what you want to achieve. I feel this group would 
> need a clearer picture to be able to help.
> 
> Do you intend for group 1 to have the ability of starving group 2 of traffic 
> below it's allocated third?
> Do you want to limit group 2 to a third of the bandwidth even if there is 
> capacity on the link unused?
> Do you want a group to have priority transport to reduce delay when within 
> contract?
> 
> Other things to consider are delay/jitter/discards. Placing policies on an 
> interface has the effect that if you improve performance for one group you 
> will reduce performance for the other. This sounds obvious, and is with 
> regard to bandwidth but also delay and jitter can also be improved for one 
> group and reduced for the other.  Have you considered the traffic types in 
> the group you are planning to limit. Will they be affected in an undesired 
> way.
> 
> e.g.
> 
> If voice traffic is in a group with priority transport, It would suffer less 
> delay and reduced jitter as long as the policy is applied network wide which 
> is good but you would need to ensure the bandwidth allocated was within the 
> maximum that would be offered as discards due to bandwidth resraints would 
> destroy the voice quality of all calls.  Also If you give priority to one 
> group the other group would be restricted with at best increased jitter and 
> at worst suffer discards. This could adversely affect again voice as 
> jitter/delays/discards are bad but also affect interactive applications 
> where the end user suffers stuttering and application freezes.
> 
> I state the above as it is dangerous to give advice in this instance with 
> limited knowledge of the reasoning or to an explicit request.
> 
> Regards
> 
> Toby
> 
> "Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
> news:30jutqF31llmbU1@uni-berlin.de...
> 
>>Traffic shaping question...  Hope you guys can help!
>>
>>I have a 3750 with an E1 going elsewhere.  I want to specify 2 different 
>>groups of ip's (either destination or source, doesn't matter)  Where one 
>>group can send as much as they want, but I want the other group to NOT 
>>exceed 1/3 of the available bandwidth.
>>
>>Is this possible?  I'm totally new to traffic shaping.  (Hope this is what 
>>I would use to accomplish this.)
>>
>>
>>TIA!!! 
> 
> 
> 

Jesse Gardner wrote:
> Thanks for your reply, I will try to explain what it is I am after...
> 
> I have two groups that are paying for this line(an E1), one of them (we 
> can call them "group 1") pays 2/3's of the cost of the line and the 
> other ("group 2") pays the remaining 1/3.  I want to limit the lesser so 
> that they don't pummel the line consuming more bandwidth than they 
> rightly should.
> 
> This line is strictly data, no voip.  Mostly FTP transmissions.
> 
> I aim to limit "group 2" so that they will not abuse the line.  And so 
> that "group 1" will have the pipe they pay for.
> 
> 
> HTH,
> 
> Jesse
> 
> 
> 
> Toby wrote:
> 
>> Hi
>>
>> Can you clarify exacly what you want to achieve. I feel this group 
>> would need a clearer picture to be able to help.
>>
>> Do you intend for group 1 to have the ability of starving group 2 of 
>> traffic below it's allocated third?
>> Do you want to limit group 2 to a third of the bandwidth even if there 
>> is capacity on the link unused?
>> Do you want a group to have priority transport to reduce delay when 
>> within contract?
>>
>> Other things to consider are delay/jitter/discards. Placing policies 
>> on an interface has the effect that if you improve performance for one 
>> group you will reduce performance for the other. This sounds obvious, 
>> and is with regard to bandwidth but also delay and jitter can also be 
>> improved for one group and reduced for the other.  Have you considered 
>> the traffic types in the group you are planning to limit. Will they be 
>> affected in an undesired way.
>>
>> e.g.
>>
>> If voice traffic is in a group with priority transport, It would 
>> suffer less delay and reduced jitter as long as the policy is applied 
>> network wide which is good but you would need to ensure the bandwidth 
>> allocated was within the maximum that would be offered as discards due 
>> to bandwidth resraints would destroy the voice quality of all calls.  
>> Also If you give priority to one group the other group would be 
>> restricted with at best increased jitter and at worst suffer discards. 
>> This could adversely affect again voice as jitter/delays/discards are 
>> bad but also affect interactive applications where the end user 
>> suffers stuttering and application freezes.
>>
>> I state the above as it is dangerous to give advice in this instance 
>> with limited knowledge of the reasoning or to an explicit request.
>>
>> Regards
>>
>> Toby
>>
>> "Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
>> news:30jutqF31llmbU1@uni-berlin.de...
>>
>>> Traffic shaping question...  Hope you guys can help!
>>>
>>> I have a 3750 with an E1 going elsewhere.  I want to specify 2 
>>> different groups of ip's (either destination or source, doesn't 
>>> matter)  Where one group can send as much as they want, but I want 
>>> the other group to NOT exceed 1/3 of the available bandwidth.
>>>
>>> Is this possible?  I'm totally new to traffic shaping.  (Hope this is 
>>> what I would use to accomplish this.)
>>>
>>>
>>> TIA!!! 
>>
>>
>>
>>

Forget the term traffic shaping, that is just one technique in a bigger 
bag of tricks called quality of service.

Here are the steps to take:

1) Define a classes for the customer you want to limit

e.g.
class-map match-all CUSTOMER
  match access-group 1

access-list 1 permit ip x.x.x.x x.x.x.x

2) Create the policy, you want to POLICE not SHAPE this class. Assuming 
you have a 2Mb E1...

policy-map CUSTOMER-666Kb
  class CUSTOMER
   police 666000 conform-action transmit exceed-action drop

3) Apply it to the interface:

interface serial 1/0:15
  service-policy input CUSTOMER-3Mb

Ben wrote:
> Jesse Gardner wrote:
> 
>> Thanks for your reply, I will try to explain what it is I am after...
>>
>> I have two groups that are paying for this line(an E1), one of them 
>> (we can call them "group 1") pays 2/3's of the cost of the line and 
>> the other ("group 2") pays the remaining 1/3.  I want to limit the 
>> lesser so that they don't pummel the line consuming more bandwidth 
>> than they rightly should.
>>
>> This line is strictly data, no voip.  Mostly FTP transmissions.
>>
>> I aim to limit "group 2" so that they will not abuse the line.  And so 
>> that "group 1" will have the pipe they pay for.
>>
>>
>> HTH,
>>
>> Jesse
>>
>>
>>
>> Toby wrote:
>>
>>> Hi
>>>
>>> Can you clarify exacly what you want to achieve. I feel this group 
>>> would need a clearer picture to be able to help.
>>>
>>> Do you intend for group 1 to have the ability of starving group 2 of 
>>> traffic below it's allocated third?
>>> Do you want to limit group 2 to a third of the bandwidth even if 
>>> there is capacity on the link unused?
>>> Do you want a group to have priority transport to reduce delay when 
>>> within contract?
>>>
>>> Other things to consider are delay/jitter/discards. Placing policies 
>>> on an interface has the effect that if you improve performance for 
>>> one group you will reduce performance for the other. This sounds 
>>> obvious, and is with regard to bandwidth but also delay and jitter 
>>> can also be improved for one group and reduced for the other.  Have 
>>> you considered the traffic types in the group you are planning to 
>>> limit. Will they be affected in an undesired way.
>>>
>>> e.g.
>>>
>>> If voice traffic is in a group with priority transport, It would 
>>> suffer less delay and reduced jitter as long as the policy is applied 
>>> network wide which is good but you would need to ensure the bandwidth 
>>> allocated was within the maximum that would be offered as discards 
>>> due to bandwidth resraints would destroy the voice quality of all 
>>> calls.  Also If you give priority to one group the other group would 
>>> be restricted with at best increased jitter and at worst suffer 
>>> discards. This could adversely affect again voice as 
>>> jitter/delays/discards are bad but also affect interactive 
>>> applications where the end user suffers stuttering and application 
>>> freezes.
>>>
>>> I state the above as it is dangerous to give advice in this instance 
>>> with limited knowledge of the reasoning or to an explicit request.
>>>
>>> Regards
>>>
>>> Toby
>>>
>>> "Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
>>> news:30jutqF31llmbU1@uni-berlin.de...
>>>
>>>> Traffic shaping question...  Hope you guys can help!
>>>>
>>>> I have a 3750 with an E1 going elsewhere.  I want to specify 2 
>>>> different groups of ip's (either destination or source, doesn't 
>>>> matter)  Where one group can send as much as they want, but I want 
>>>> the other group to NOT exceed 1/3 of the available bandwidth.
>>>>
>>>> Is this possible?  I'm totally new to traffic shaping.  (Hope this 
>>>> is what I would use to accomplish this.)
>>>>
>>>>
>>>> TIA!!! 
>>>
>>>
>>>
>>>
>>>
> 
> Forget the term traffic shaping, that is just one technique in a bigger 
> bag of tricks called quality of service.
> 
> Here are the steps to take:
> 
> 1) Define a classes for the customer you want to limit
> 
> e.g.
> class-map match-all CUSTOMER
>  match access-group 1
> 
> access-list 1 permit ip x.x.x.x x.x.x.x
> 
> 2) Create the policy, you want to POLICE not SHAPE this class. Assuming 
> you have a 2Mb E1...
> 
> policy-map CUSTOMER-666Kb
>  class CUSTOMER
>   police 666000 conform-action transmit exceed-action drop
> 
> 3) Apply it to the interface:
> 
> interface serial 1/0:15
>  service-policy input CUSTOMER-3Mb
> 
Sorry a type there at the end...should be

 > interface serial 1/0:15
 >  service-policy input CUSTOMER-666Kb

"Ben" <l33t@hax0r.com> wrote in message news:41A6078D.4000400@hax0r.com...
> Ben wrote:
>> Jesse Gardner wrote:
>>
>>> Thanks for your reply, I will try to explain what it is I am after...
>>>
>>> I have two groups that are paying for this line(an E1), one of them (we 
>>> can call them "group 1") pays 2/3's of the cost of the line and the 
>>> other ("group 2") pays the remaining 1/3.  I want to limit the lesser so 
>>> that they don't pummel the line consuming more bandwidth than they 
>>> rightly should.
>>>
>>> This line is strictly data, no voip.  Mostly FTP transmissions.
>>>
>>> I aim to limit "group 2" so that they will not abuse the line.  And so 
>>> that "group 1" will have the pipe they pay for.
>>>
>>>
>>> HTH,
>>>
>>> Jesse
>>>
>>>
>>>
>>> Toby wrote:
>>>
>>>> Hi
>>>>
>>>> Can you clarify exacly what you want to achieve. I feel this group 
>>>> would need a clearer picture to be able to help.
>>>>
>>>> Do you intend for group 1 to have the ability of starving group 2 of 
>>>> traffic below it's allocated third?
>>>> Do you want to limit group 2 to a third of the bandwidth even if there 
>>>> is capacity on the link unused?
>>>> Do you want a group to have priority transport to reduce delay when 
>>>> within contract?
>>>>
>>>> Other things to consider are delay/jitter/discards. Placing policies on 
>>>> an interface has the effect that if you improve performance for one 
>>>> group you will reduce performance for the other. This sounds obvious, 
>>>> and is with regard to bandwidth but also delay and jitter can also be 
>>>> improved for one group and reduced for the other.  Have you considered 
>>>> the traffic types in the group you are planning to limit. Will they be 
>>>> affected in an undesired way.
>>>>
>>>> e.g.
>>>>
>>>> If voice traffic is in a group with priority transport, It would suffer 
>>>> less delay and reduced jitter as long as the policy is applied network 
>>>> wide which is good but you would need to ensure the bandwidth allocated 
>>>> was within the maximum that would be offered as discards due to 
>>>> bandwidth resraints would destroy the voice quality of all calls.  Also 
>>>> If you give priority to one group the other group would be restricted 
>>>> with at best increased jitter and at worst suffer discards. This could 
>>>> adversely affect again voice as jitter/delays/discards are bad but also 
>>>> affect interactive applications where the end user suffers stuttering 
>>>> and application freezes.
>>>>
>>>> I state the above as it is dangerous to give advice in this instance 
>>>> with limited knowledge of the reasoning or to an explicit request.
>>>>
>>>> Regards
>>>>
>>>> Toby
>>>>
>>>> "Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
>>>> news:30jutqF31llmbU1@uni-berlin.de...
>>>>
>>>>> Traffic shaping question...  Hope you guys can help!
>>>>>
>>>>> I have a 3750 with an E1 going elsewhere.  I want to specify 2 
>>>>> different groups of ip's (either destination or source, doesn't 
>>>>> matter)  Where one group can send as much as they want, but I want the 
>>>>> other group to NOT exceed 1/3 of the available bandwidth.
>>>>>
>>>>> Is this possible?  I'm totally new to traffic shaping.  (Hope this is 
>>>>> what I would use to accomplish this.)
>>>>>
>>>>>
>>>>> TIA!!!
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> Forget the term traffic shaping, that is just one technique in a bigger 
>> bag of tricks called quality of service.
>>
>> Here are the steps to take:
>>
>> 1) Define a classes for the customer you want to limit
>>
>> e.g.
>> class-map match-all CUSTOMER
>>  match access-group 1
>>
>> access-list 1 permit ip x.x.x.x x.x.x.x
>>
>> 2) Create the policy, you want to POLICE not SHAPE this class. Assuming 
>> you have a 2Mb E1...
>>
>> policy-map CUSTOMER-666Kb
>>  class CUSTOMER
>>   police 666000 conform-action transmit exceed-action drop
>>
>> 3) Apply it to the interface:
>>
>> interface serial 1/0:15
>>  service-policy input CUSTOMER-3Mb
>>
> Sorry a type there at the end...should be
>
> > interface serial 1/0:15
> >  service-policy input CUSTOMER-666Kb

This is very close to what you want, but this method only allows what has 
been paid for.and no more (also note the example only refers to one of your 
customers). It is good policy to allow extra when and only when it is 
available, unless you are paying for bandwidth usage upstream of the E1 and 
are offering a strict bandwidth service to save yourself money.

Again we need to establish some facts. Do you mind the E1 link being fully 
utillised regardless of which group is using it or do you want to strictly 
restict this traffic to their contracts to save money?

Also does the i/c traffic from the customers come through a common 
interface/subinterface into this routeror do we have to manage this via 
source IP address.

Regards

Toby

To answer your question, I don't mind the link being fully utilized by 
either group, I just want to make sure that the group paying more has 
access to that bandwidth if they need it.

The i/c traffic will be coming in the *same* ethe interface and going 
out the E1.  I would imagine we would need to manage by source IP addresses.


Also, For informational/learning purposes, could you also explain the 
best way to allow only what has been paid for?  Or is Ben's description 
exactly that?


Thanks to both of you for your input on this!


Toby wrote:
> "Ben" <l33t@hax0r.com> wrote in message news:41A6078D.4000400@hax0r.com...
> 
>>Ben wrote:
>>
>>>Jesse Gardner wrote:
>>>
>>>
>>>>Thanks for your reply, I will try to explain what it is I am after...
>>>>
>>>>I have two groups that are paying for this line(an E1), one of them (we 
>>>>can call them "group 1") pays 2/3's of the cost of the line and the 
>>>>other ("group 2") pays the remaining 1/3.  I want to limit the lesser so 
>>>>that they don't pummel the line consuming more bandwidth than they 
>>>>rightly should.
>>>>
>>>>This line is strictly data, no voip.  Mostly FTP transmissions.
>>>>
>>>>I aim to limit "group 2" so that they will not abuse the line.  And so 
>>>>that "group 1" will have the pipe they pay for.
>>>>
>>>>
>>>>HTH,
>>>>
>>>>Jesse
>>>>
>>>>
>>>>
>>>>Toby wrote:
>>>>
>>>>
>>>>>Hi
>>>>>
>>>>>Can you clarify exacly what you want to achieve. I feel this group 
>>>>>would need a clearer picture to be able to help.
>>>>>
>>>>>Do you intend for group 1 to have the ability of starving group 2 of 
>>>>>traffic below it's allocated third?
>>>>>Do you want to limit group 2 to a third of the bandwidth even if there 
>>>>>is capacity on the link unused?
>>>>>Do you want a group to have priority transport to reduce delay when 
>>>>>within contract?
>>>>>
>>>>>Other things to consider are delay/jitter/discards. Placing policies on 
>>>>>an interface has the effect that if you improve performance for one 
>>>>>group you will reduce performance for the other. This sounds obvious, 
>>>>>and is with regard to bandwidth but also delay and jitter can also be 
>>>>>improved for one group and reduced for the other.  Have you considered 
>>>>>the traffic types in the group you are planning to limit. Will they be 
>>>>>affected in an undesired way.
>>>>>
>>>>>e.g.
>>>>>
>>>>>If voice traffic is in a group with priority transport, It would suffer 
>>>>>less delay and reduced jitter as long as the policy is applied network 
>>>>>wide which is good but you would need to ensure the bandwidth allocated 
>>>>>was within the maximum that would be offered as discards due to 
>>>>>bandwidth resraints would destroy the voice quality of all calls.  Also 
>>>>>If you give priority to one group the other group would be restricted 
>>>>>with at best increased jitter and at worst suffer discards. This could 
>>>>>adversely affect again voice as jitter/delays/discards are bad but also 
>>>>>affect interactive applications where the end user suffers stuttering 
>>>>>and application freezes.
>>>>>
>>>>>I state the above as it is dangerous to give advice in this instance 
>>>>>with limited knowledge of the reasoning or to an explicit request.
>>>>>
>>>>>Regards
>>>>>
>>>>>Toby
>>>>>
>>>>>"Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
>>>>>news:30jutqF31llmbU1@uni-berlin.de...
>>>>>
>>>>>
>>>>>>Traffic shaping question...  Hope you guys can help!
>>>>>>
>>>>>>I have a 3750 with an E1 going elsewhere.  I want to specify 2 
>>>>>>different groups of ip's (either destination or source, doesn't 
>>>>>>matter)  Where one group can send as much as they want, but I want the 
>>>>>>other group to NOT exceed 1/3 of the available bandwidth.
>>>>>>
>>>>>>Is this possible?  I'm totally new to traffic shaping.  (Hope this is 
>>>>>>what I would use to accomplish this.)
>>>>>>
>>>>>>
>>>>>>TIA!!!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>Forget the term traffic shaping, that is just one technique in a bigger 
>>>bag of tricks called quality of service.
>>>
>>>Here are the steps to take:
>>>
>>>1) Define a classes for the customer you want to limit
>>>
>>>e.g.
>>>class-map match-all CUSTOMER
>>> match access-group 1
>>>
>>>access-list 1 permit ip x.x.x.x x.x.x.x
>>>
>>>2) Create the policy, you want to POLICE not SHAPE this class. Assuming 
>>>you have a 2Mb E1...
>>>
>>>policy-map CUSTOMER-666Kb
>>> class CUSTOMER
>>>  police 666000 conform-action transmit exceed-action drop
>>>
>>>3) Apply it to the interface:
>>>
>>>interface serial 1/0:15
>>> service-policy input CUSTOMER-3Mb
>>>
>>
>>Sorry a type there at the end...should be
>>
>>
>>>interface serial 1/0:15
>>> service-policy input CUSTOMER-666Kb
> 
> 
> This is very close to what you want, but this method only allows what has 
> been paid for.and no more (also note the example only refers to one of your 
> customers). It is good policy to allow extra when and only when it is 
> available, unless you are paying for bandwidth usage upstream of the E1 and 
> are offering a strict bandwidth service to save yourself money.
> 
> Again we need to establish some facts. Do you mind the E1 link being fully 
> utillised regardless of which group is using it or do you want to strictly 
> restict this traffic to their contracts to save money?
> 
> Also does the i/c traffic from the customers come through a common 
> interface/subinterface into this routeror do we have to manage this via 
> source IP address.
> 
> Regards
> 
> Toby
> 
> 

Jesse Gardner wrote:
> To answer your question, I don't mind the link being fully utilized by 
> either group, I just want to make sure that the group paying more has 
> access to that bandwidth if they need it.
> 
> The i/c traffic will be coming in the *same* ethe interface and going 
> out the E1.  I would imagine we would need to manage by source IP 
> addresses.
> 
> 
> Also, For informational/learning purposes, could you also explain the 
> best way to allow only what has been paid for?  Or is Ben's description 
> exactly that?
> 
> 
> Thanks to both of you for your input on this!
> 
> 
> Toby wrote:
> 
>> "Ben" <l33t@hax0r.com> wrote in message 
>> news:41A6078D.4000400@hax0r.com...
>>
>>> Ben wrote:
>>>
>>>> Jesse Gardner wrote:
>>>>
>>>>
>>>>> Thanks for your reply, I will try to explain what it is I am after...
>>>>>
>>>>> I have two groups that are paying for this line(an E1), one of them 
>>>>> (we can call them "group 1") pays 2/3's of the cost of the line and 
>>>>> the other ("group 2") pays the remaining 1/3.  I want to limit the 
>>>>> lesser so that they don't pummel the line consuming more bandwidth 
>>>>> than they rightly should.
>>>>>
>>>>> This line is strictly data, no voip.  Mostly FTP transmissions.
>>>>>
>>>>> I aim to limit "group 2" so that they will not abuse the line.  And 
>>>>> so that "group 1" will have the pipe they pay for.
>>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Jesse
>>>>>
>>>>>
>>>>>
>>>>> Toby wrote:
>>>>>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Can you clarify exacly what you want to achieve. I feel this group 
>>>>>> would need a clearer picture to be able to help.
>>>>>>
>>>>>> Do you intend for group 1 to have the ability of starving group 2 
>>>>>> of traffic below it's allocated third?
>>>>>> Do you want to limit group 2 to a third of the bandwidth even if 
>>>>>> there is capacity on the link unused?
>>>>>> Do you want a group to have priority transport to reduce delay 
>>>>>> when within contract?
>>>>>>
>>>>>> Other things to consider are delay/jitter/discards. Placing 
>>>>>> policies on an interface has the effect that if you improve 
>>>>>> performance for one group you will reduce performance for the 
>>>>>> other. This sounds obvious, and is with regard to bandwidth but 
>>>>>> also delay and jitter can also be improved for one group and 
>>>>>> reduced for the other.  Have you considered the traffic types in 
>>>>>> the group you are planning to limit. Will they be affected in an 
>>>>>> undesired way.
>>>>>>
>>>>>> e.g.
>>>>>>
>>>>>> If voice traffic is in a group with priority transport, It would 
>>>>>> suffer less delay and reduced jitter as long as the policy is 
>>>>>> applied network wide which is good but you would need to ensure 
>>>>>> the bandwidth allocated was within the maximum that would be 
>>>>>> offered as discards due to bandwidth resraints would destroy the 
>>>>>> voice quality of all calls.  Also If you give priority to one 
>>>>>> group the other group would be restricted with at best increased 
>>>>>> jitter and at worst suffer discards. This could adversely affect 
>>>>>> again voice as jitter/delays/discards are bad but also affect 
>>>>>> interactive applications where the end user suffers stuttering and 
>>>>>> application freezes.
>>>>>>
>>>>>> I state the above as it is dangerous to give advice in this 
>>>>>> instance with limited knowledge of the reasoning or to an explicit 
>>>>>> request.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Toby
>>>>>>
>>>>>> "Jesse Gardner" <admin_deleteth1s@badcrc.com> wrote in message 
>>>>>> news:30jutqF31llmbU1@uni-berlin.de...
>>>>>>
>>>>>>
>>>>>>> Traffic shaping question...  Hope you guys can help!
>>>>>>>
>>>>>>> I have a 3750 with an E1 going elsewhere.  I want to specify 2 
>>>>>>> different groups of ip's (either destination or source, doesn't 
>>>>>>> matter)  Where one group can send as much as they want, but I 
>>>>>>> want the other group to NOT exceed 1/3 of the available bandwidth.
>>>>>>>
>>>>>>> Is this possible?  I'm totally new to traffic shaping.  (Hope 
>>>>>>> this is what I would use to accomplish this.)
>>>>>>>
>>>>>>>
>>>>>>> TIA!!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> Forget the term traffic shaping, that is just one technique in a 
>>>> bigger bag of tricks called quality of service.
>>>>
>>>> Here are the steps to take:
>>>>
>>>> 1) Define a classes for the customer you want to limit
>>>>
>>>> e.g.
>>>> class-map match-all CUSTOMER
>>>> match access-group 1
>>>>
>>>> access-list 1 permit ip x.x.x.x x.x.x.x
>>>>
>>>> 2) Create the policy, you want to POLICE not SHAPE this class. 
>>>> Assuming you have a 2Mb E1...
>>>>
>>>> policy-map CUSTOMER-666Kb
>>>> class CUSTOMER
>>>>  police 666000 conform-action transmit exceed-action drop
>>>>
>>>> 3) Apply it to the interface:
>>>>
>>>> interface serial 1/0:15
>>>> service-policy input CUSTOMER-3Mb
>>>>
>>>
>>> Sorry a type there at the end...should be
>>>
>>>
>>>> interface serial 1/0:15
>>>> service-policy input CUSTOMER-666Kb
>>
>>
>>
>> This is very close to what you want, but this method only allows what 
>> has been paid for.and no more (also note the example only refers to 
>> one of your customers). It is good policy to allow extra when and only 
>> when it is available, unless you are paying for bandwidth usage 
>> upstream of the E1 and are offering a strict bandwidth service to save 
>> yourself money.
>>
>> Again we need to establish some facts. Do you mind the E1 link being 
>> fully utillised regardless of which group is using it or do you want 
>> to strictly restict this traffic to their contracts to save money?
>>
>> Also does the i/c traffic from the customers come through a common 
>> interface/subinterface into this routeror do we have to manage this 
>> via source IP address.
>>
>> Regards
>>
>> Toby
>>
>>

In that case we modify it like so. Note this is more of a typical 
configuration but I understood your requirement was only to limit one of 
the customer's to 1/3 of the bandwidth:

 >>>> 1) Define a class-map for both customers
 >>>>
 >>>> class-map match-all CUSTOMER1
 >>>> match access-group 1
 >>>> class-map match-all CUSTOMER2
 >>>> match access-group 2
 >>>>
 >>>> access-list 1 permit ip x.x.x.x x.x.x.x
 >>>> access-list 2 permit ip x.x.x.x x.x.x.x
 >>>>
 >>>> 2) Create the policy
 >>>>
 >>>> policy-map CUSTOMER-ACCESS
 >>>> class CUSTOMER1
 >>>>  bandwidth percent 31
 >>>> class CUSTOMER2
 >>>>  bandwidth percent 64
 >>>>
 >>>> 3) Apply it to the interface:
 >>>>
 >>>> interface serial 1/0:15
 >>>>  max-reserved-bandwidth 95
 >>>>  service-policy input CUSTOMER-ACCESS

The reason for the 31 and 64 is you don't want to reserve all of the 
interface bandwidth for customers as there is invariably some quantity 
of control traffic (routing, ntp etc) on the link. 95 is a reasonable 
compromise. As there is a little give (burst) in the implementation of 
bandwidth statements, the customer won't know the difference.

The big difference between this and policing is the 31 and 64 represent 
a minimum guarantee - not an absolute maximum as in policing. So if 
CUST1 needs says 50% of the link bandwidth at a particular moment, he 
will get it, but only so long as CUST2 does need more than 50% at that 
same moment. The converse is also true. Extra configured bandwidth is 
automatically shared if it's not being used, so this is a very flexible 
configuration.

Ben has it spot on here, No customer has priority except to use there bare 
minimum bandwidth and can use up unused bandwidth.

Toby


> In that case we modify it like so. Note this is more of a typical 
> configuration but I understood your requirement was only to limit one of 
> the customer's to 1/3 of the bandwidth:
>
> >>>> 1) Define a class-map for both customers
> >>>>
> >>>> class-map match-all CUSTOMER1
> >>>> match access-group 1
> >>>> class-map match-all CUSTOMER2
> >>>> match access-group 2
> >>>>
> >>>> access-list 1 permit ip x.x.x.x x.x.x.x
> >>>> access-list 2 permit ip x.x.x.x x.x.x.x
> >>>>
> >>>> 2) Create the policy
> >>>>
> >>>> policy-map CUSTOMER-ACCESS
> >>>> class CUSTOMER1
> >>>>  bandwidth percent 31
> >>>> class CUSTOMER2
> >>>>  bandwidth percent 64
> >>>>
> >>>> 3) Apply it to the interface:
> >>>>
> >>>> interface serial 1/0:15
> >>>>  max-reserved-bandwidth 95
> >>>>  service-policy input CUSTOMER-ACCESS
>
> The reason for the 31 and 64 is you don't want to reserve all of the 
> interface bandwidth for customers as there is invariably some quantity of 
> control traffic (routing, ntp etc) on the link. 95 is a reasonable 
> compromise. As there is a little give (burst) in the implementation of 
> bandwidth statements, the customer won't know the difference.
>
> The big difference between this and policing is the 31 and 64 represent a 
> minimum guarantee - not an absolute maximum as in policing. So if CUST1 
> needs says 50% of the link bandwidth at a particular moment, he will get 
> it, but only so long as CUST2 does need more than 50% at that same moment. 
> The converse is also true. Extra configured bandwidth is automatically 
> shared if it's not being used, so this is a very flexible configuration. 

This looks like a great way to divide up available bandwidth
between 2 major clients!

(Just what I'm looking for!!)

BUT, I also need to limit all my inbound traffic to 3-Mb,(see
how I do it here):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
interface FastEthernet0/0
!
 rate-limit input access-group 199 3000000 375000 375000
conform-action transmit exceed-action drop
!
..
..
..
..
!
access-list 199 permit ip any any
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Can I use the above, AND also add in your service-policy
example below,(ie. I want to divide the 3-Mb into the 64/31
split, but keep the total usage of everyone to 3-Mb)?


//////////////////////////////////////////////////////////////////
On Thu, 25 Nov 2004 14:11:34 GMT, "Toby" <Nomail@ntlworld.com> wrote:

>Ben has it spot on here, No customer has priority except to use there bare 
>minimum bandwidth and can use up unused bandwidth.
>
>> >>>> 1) Define a class-map for both customers
>> >>>>
>> >>>> class-map match-all CUSTOMER1
>> >>>> match access-group 1
>> >>>> class-map match-all CUSTOMER2
>> >>>> match access-group 2
>> >>>>
>> >>>> access-list 1 permit ip x.x.x.x x.x.x.x
>> >>>> access-list 2 permit ip x.x.x.x x.x.x.x
>> >>>>
>> >>>> 2) Create the policy
>> >>>>
>> >>>> policy-map CUSTOMER-ACCESS
>> >>>> class CUSTOMER1
>> >>>>  bandwidth percent 31
>> >>>> class CUSTOMER2
>> >>>>  bandwidth percent 64
>> >>>>
>> >>>> 3) Apply it to the interface:
>> >>>>
>> >>>> interface serial 1/0:15
>> >>>>  max-reserved-bandwidth 95
>> >>>>  service-policy input CUSTOMER-ACCESS
>>
>> The reason for the 31 and 64 is you don't want to reserve all of the 
>> interface bandwidth for customers as there is invariably some quantity of 
>> control traffic (routing, ntp etc) on the link. 95 is a reasonable 
>> compromise. As there is a little give (burst) in the implementation of 
>> bandwidth statements, the customer won't know the difference.
>>
>> The big difference between this and policing is the 31 and 64 represent a 
>> minimum guarantee - not an absolute maximum as in policing. So if CUST1 
>> needs says 50% of the link bandwidth at a particular moment, he will get 
>> it, but only so long as CUST2 does need more than 50% at that same moment. 
>> The converse is also true. Extra configured bandwidth is automatically 
>> shared if it's not being used, so this is a very flexible configuration. 
>

Hi Captain

Your inbound rate limit relies on TCP to slow down in the event of discarded 
packets to achieve it's goal. It will not stop UDP or DOS attacks from 
consuming the links bandwidth even if the packets are discarded at your end 
(depending on application).as the remote end will just send the packets 
regardless consuming your bandwidth. Perhaps a better way would be to talk 
to the administrators of the remote end and set up a outbound policy to 
protect your link from unwanted traffic. If they want too much money for 
this then your solution is valid. (as long as you know the downside)

This is not the answer to your question though. There is nothing to stop you 
applying an outgoing policy as well apart from the IOS i.e. if it supports 
it.

Regards

Toby

"Captain" <captain99_1999@yahoo.com> wrote in message 
news:f06cq0hkt4fhamclalvq2r0f7eop9f9ggp@4ax.com...
> This looks like a great way to divide up available bandwidth
> between 2 major clients!
>
> (Just what I'm looking for!!)
>
> BUT, I also need to limit all my inbound traffic to 3-Mb,(see
> how I do it here):
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> interface FastEthernet0/0
> !
> rate-limit input access-group 199 3000000 375000 375000
> conform-action transmit exceed-action drop
> !
> .
> .
> .
> .
> !
> access-list 199 permit ip any any
> !
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> Can I use the above, AND also add in your service-policy
> example below,(ie. I want to divide the 3-Mb into the 64/31
> split, but keep the total usage of everyone to 3-Mb)?
>
>
> //////////////////////////////////////////////////////////////////
> On Thu, 25 Nov 2004 14:11:34 GMT, "Toby" <Nomail@ntlworld.com> wrote:
>
>>Ben has it spot on here, No customer has priority except to use there bare
>>minimum bandwidth and can use up unused bandwidth.
>>
>>> >>>> 1) Define a class-map for both customers
>>> >>>>
>>> >>>> class-map match-all CUSTOMER1
>>> >>>> match access-group 1
>>> >>>> class-map match-all CUSTOMER2
>>> >>>> match access-group 2
>>> >>>>
>>> >>>> access-list 1 permit ip x.x.x.x x.x.x.x
>>> >>>> access-list 2 permit ip x.x.x.x x.x.x.x
>>> >>>>
>>> >>>> 2) Create the policy
>>> >>>>
>>> >>>> policy-map CUSTOMER-ACCESS
>>> >>>> class CUSTOMER1
>>> >>>>  bandwidth percent 31
>>> >>>> class CUSTOMER2
>>> >>>>  bandwidth percent 64
>>> >>>>
>>> >>>> 3) Apply it to the interface:
>>> >>>>
>>> >>>> interface serial 1/0:15
>>> >>>>  max-reserved-bandwidth 95
>>> >>>>  service-policy input CUSTOMER-ACCESS
>>>
>>> The reason for the 31 and 64 is you don't want to reserve all of the
>>> interface bandwidth for customers as there is invariably some quantity 
>>> of
>>> control traffic (routing, ntp etc) on the link. 95 is a reasonable
>>> compromise. As there is a little give (burst) in the implementation of
>>> bandwidth statements, the customer won't know the difference.
>>>
>>> The big difference between this and policing is the 31 and 64 represent 
>>> a
>>> minimum guarantee - not an absolute maximum as in policing. So if CUST1
>>> needs says 50% of the link bandwidth at a particular moment, he will get
>>> it, but only so long as CUST2 does need more than 50% at that same 
>>> moment.
>>> The converse is also true. Extra configured bandwidth is automatically
>>> shared if it's not being used, so this is a very flexible configuration.
>>
> 

This brings up an interesting point, how does the router know
what the maximum throughput is when we are only giving it
percentages?

ie.
customer1 is allowed 31%
customer2 is allowed 64%
and the service-policy is applied onto a FastEthernet interface.

So how do I tell the router the total bandwidth to apply the
percentages to, is ONLY 3-Mb?



////////////////////////////////////////////////////////////////////////
>Hi Captain
>
>Your inbound rate limit relies on TCP to slow down in the event of discarded 
>packets to achieve it's goal. It will not stop UDP or DOS attacks from 
>consuming the links bandwidth even if the packets are discarded at your end 
>(depending on application).as the remote end will just send the packets 
>regardless consuming your bandwidth. Perhaps a better way would be to talk 
>to the administrators of the remote end and set up a outbound policy to 
>protect your link from unwanted traffic. If they want too much money for 
>this then your solution is valid. (as long as you know the downside)
>
>This is not the answer to your question though. There is nothing to stop you 
>applying an outgoing policy as well apart from the IOS i.e. if it supports 
>it.
>
>Regards
>
>Toby
>
>"Captain" <captain99_1999@yahoo.com> wrote in message 
>news:f06cq0hkt4fhamclalvq2r0f7eop9f9ggp@4ax.com...
>> This looks like a great way to divide up available bandwidth
>> between 2 major clients!
>>
>> (Just what I'm looking for!!)
>>
>> BUT, I also need to limit all my inbound traffic to 3-Mb,(see
>> how I do it here):
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !
>> interface FastEthernet0/0
>> !
>> rate-limit input access-group 199 3000000 375000 375000
>> conform-action transmit exceed-action drop
>> !
>> .
>> .
>> .
>> .
>> !
>> access-list 199 permit ip any any
>> !
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>
>> Can I use the above, AND also add in your service-policy
>> example below,(ie. I want to divide the 3-Mb into the 64/31
>> split, but keep the total usage of everyone to 3-Mb)?
>>
>>
>> //////////////////////////////////////////////////////////////////
>> On Thu, 25 Nov 2004 14:11:34 GMT, "Toby" <Nomail@ntlworld.com> wrote:
>>
>>>Ben has it spot on here, No customer has priority except to use there bare
>>>minimum bandwidth and can use up unused bandwidth.
>>>
>>>> >>>> 1) Define a class-map for both customers
>>>> >>>>
>>>> >>>> class-map match-all CUSTOMER1
>>>> >>>> match access-group 1
>>>> >>>> class-map match-all CUSTOMER2
>>>> >>>> match access-group 2
>>>> >>>>
>>>> >>>> access-list 1 permit ip x.x.x.x x.x.x.x
>>>> >>>> access-list 2 permit ip x.x.x.x x.x.x.x
>>>> >>>>
>>>> >>>> 2) Create the policy
>>>> >>>>
>>>> >>>> policy-map CUSTOMER-ACCESS
>>>> >>>> class CUSTOMER1
>>>> >>>>  bandwidth percent 31
>>>> >>>> class CUSTOMER2
>>>> >>>>  bandwidth percent 64
>>>> >>>>
>>>> >>>> 3) Apply it to the interface:
>>>> >>>>
>>>> >>>> interface serial 1/0:15
>>>> >>>>  max-reserved-bandwidth 95
>>>> >>>>  service-policy input CUSTOMER-ACCESS
>>>>
>>>> The reason for the 31 and 64 is you don't want to reserve all of the
>>>> interface bandwidth for customers as there is invariably some quantity 
>>>> of
>>>> control traffic (routing, ntp etc) on the link. 95 is a reasonable
>>>> compromise. As there is a little give (burst) in the implementation of
>>>> bandwidth statements, the customer won't know the difference.
>>>>
>>>> The big difference between this and policing is the 31 and 64 represent 
>>>> a
>>>> minimum guarantee - not an absolute maximum as in policing. So if CUST1
>>>> needs says 50% of the link bandwidth at a particular moment, he will get
>>>> it, but only so long as CUST2 does need more than 50% at that same 
>>>> moment.
>>>> The converse is also true. Extra configured bandwidth is automatically
>>>> shared if it's not being used, so this is a very flexible configuration.
>>>
>> 
>

In article <p6lcq09jth0s4s11n80ffjt25adootk613@4ax.com>,
Captain  <captain99_1999@yahoo.com> wrote:
:This brings up an interesting point, how does the router know
:what the maximum throughput is when we are only giving it
:percentages?

:how do I tell the router the total bandwidth to apply the
:percentages to, is ONLY 3-Mb?

I don't know if it applies to QoS, but there's a "bandwidth" interface
configuration statement as I recall.

Someone once posted here saying that in practice that the statement
didn't do much except affect the calculation of metrics for the
purposes of administrative distances in routing protocols; I don't
know if that's still true in these days of more advanced QoS facilities.
-- 
   Live it up, rip it up, why so lazy?
   Give it out, dish it out, let's go crazy, yeah!
   -- Supertramp (The USENET Song)

In article <co5oj3$rfo$1@canopus.cc.umanitoba.ca>, roberson@ibd.nrc-
cnrc.gc.ca says...
> In article <p6lcq09jth0s4s11n80ffjt25adootk613@4ax.com>,
> Captain  <captain99_1999@yahoo.com> wrote:
> :This brings up an interesting point, how does the router know
> :what the maximum throughput is when we are only giving it
> :percentages?
> 
> :how do I tell the router the total bandwidth to apply the
> :percentages to, is ONLY 3-Mb?
> 
> I don't know if it applies to QoS, but there's a "bandwidth" interface
> configuration statement as I recall.
> 
> Someone once posted here saying that in practice that the statement
> didn't do much except affect the calculation of metrics for the
> purposes of administrative distances in routing protocols; I don't
> know if that's still true in these days of more advanced QoS facilities.

It also affects interface metrics fetched via SNMP.  For example, if you 
use MRTG to monitor the router...

On Thu, 25 Nov 2004 18:23:33 -0500, Dan Swartzendruber
<dswartz@druber.com> wrote:

>In article <co5oj3$rfo$1@canopus.cc.umanitoba.ca>, roberson@ibd.nrc-
>cnrc.gc.ca says...
>> In article <p6lcq09jth0s4s11n80ffjt25adootk613@4ax.com>,
>> Captain  <captain99_1999@yahoo.com> wrote:
>> :This brings up an interesting point, how does the router know
>> :what the maximum throughput is when we are only giving it
>> :percentages?
>> 
>> :how do I tell the router the total bandwidth to apply the
>> :percentages to, is ONLY 3-Mb?
>> 
>> I don't know if it applies to QoS, but there's a "bandwidth" interface
>> configuration statement as I recall.
>> 
>> Someone once posted here saying that in practice that the statement
>> didn't do much except affect the calculation of metrics for the
>> purposes of administrative distances in routing protocols; I don't
>> know if that's still true in these days of more advanced QoS facilities.
>
>It also affects interface metrics fetched via SNMP.  For example, if you 
>use MRTG to monitor the router...



Interesting!

I've never used the bandwidth statement before,(but I've
also never had a reason to use it either)...

In article <quvcq0t969476hf6e1psjjnpganouu8q3s@4ax.com>, captain99_1999
@yahoo.com says...
> >It also affects interface metrics fetched via SNMP.  For example, if you 
> >use MRTG to monitor the router...
> 
> 
> 
> Interesting!
> 
> I've never used the bandwidth statement before,(but I've
> also never had a reason to use it either)...

I found it a handy side-effect, since you don't have to hack up the mrtg 
config file each time...

That's right, the percentages are based on the bandwidth statement! Or 
so the documentation says. I have seen some strange behaviour on an ATM 
PVC where it didn't seem to match up to the bandwidth or pvc 
settings...but I digress.

Captain, rate-limit is also legacy code. The cleanest way now to 
implement an overall cap, plus per-customer qos is through nested 
policies. However, I don't believe the percentages will work any 
differently - they will still be based on the interface configuration, 
so we need do get rid of the percentages and specify kbs.

 >>>> 1) Define a class-map for both customers, same as before
 >>>>
 >>>> class-map match-all CUSTOMER1
 >>>>  match access-group 1
 >>>> class-map match-all CUSTOMER2
 >>>>  match access-group 2
 >>>>
 >>>> access-list 1 permit ip x.x.x.x x.x.x.x
 >>>> access-list 2 permit ip x.x.x.x x.x.x.x
 >>>>
 >>>> 2) Now nest these class-maps in another one:
 >>>>
 >>>> class-map match-all CUSTOMERS
 >>>>  match class-map CUSTOMER1
 >>>>  match class-map CUSTOMER2
 >>>>
 >>>> 3) Create the policy map as before but with kbs (based on previous 
 >>>> percentages X 2048)
 >>>>
 >>>> policy-map CUSTOMER-ACCESS
 >>>>  class CUSTOMER1
 >>>>   bandwidth 635
 >>>>  class CUSTOMER2
 >>>>   bandwidth 1311
 >>>>
 >>>> 3) But now we create another policy in which we will nest the
 >>>> customer policy. This is the one that gets applied to the
 >>>> interface.
 >>>>
 >>>> policy-map E1-POLICY
 >>>>  class CUSTOMERS
 >>>>   police 2048000
 >>>>   service-policy CUSTOMER-ACCESS
 >>>>

Note this will currently have the same effect as before until you scale 
back the numbers.

This set up is great because you can come back later and nest more 
customers but also create non-customer classes that don't need to be 
nested. This is probably more applicable to faster links but it's a nice 
scalable way of doing things.

e.g.
 >>>> policy-map E1-POLICY
 >>>>  class CUSTOMERS
 >>>>   service-policy CUSTOMER-ACCESS
 >>>>  class MY-REAL-TIME
 >>>>   priority 200





Dan Swartzendruber wrote:
> In article <quvcq0t969476hf6e1psjjnpganouu8q3s@4ax.com>, captain99_1999
> @yahoo.com says...
> 
>>>It also affects interface metrics fetched via SNMP.  For example, if you 
>>>use MRTG to monitor the router...
>>
>>
>>
>>Interesting!
>>
>>I've never used the bandwidth statement before,(but I've
>>also never had a reason to use it either)...
> 
> 
> I found it a handy side-effect, since you don't have to hack up the mrtg 
> config file each time...
> 

On Fri, 26 Nov 2004 09:58:29 GMT, Ben <l33t@hax0r.com> wrote:

>That's right, the percentages are based on the bandwidth statement! Or 
>so the documentation says. I have seen some strange behaviour on an ATM 
>PVC where it didn't seem to match up to the bandwidth or pvc 
>settings...but I digress.
>
>Captain, rate-limit is also legacy code. The cleanest way now to 
>implement an overall cap, plus per-customer qos is through nested 
>policies. However, I don't believe the percentages will work any 
>differently - they will still be based on the interface configuration, 
>so we need do get rid of the percentages and specify kbs.
>
> >>>> 1) Define a class-map for both customers, same as before
> >>>>
> >>>> class-map match-all CUSTOMER1
> >>>>  match access-group 1
> >>>> class-map match-all CUSTOMER2
> >>>>  match access-group 2
> >>>>
> >>>> access-list 1 permit ip x.x.x.x x.x.x.x
> >>>> access-list 2 permit ip x.x.x.x x.x.x.x
> >>>>
> >>>> 2) Now nest these class-maps in another one:
> >>>>
> >>>> class-map match-all CUSTOMERS
> >>>>  match class-map CUSTOMER1
> >>>>  match class-map CUSTOMER2
> >>>>
> >>>> 3) Create the policy map as before but with kbs (based on previous 
> >>>> percentages X 2048)
> >>>>
////////////////////////////////////////////////////////////////////



So if I want to limit all users to 3-Mb I would use "X 3072"?
And for 5-Mb I would use "5120"?



Also, should I use:
 - standard access lists <1-99>, or
 - extended access lists <100-199>, or
 - does it not matter?


////////////////////////////////////////////////////////////////////
> >>>>
> >>>> policy-map CUSTOMER-ACCESS
> >>>>  class CUSTOMER1
> >>>>   bandwidth 635
> >>>>  class CUSTOMER2
> >>>>   bandwidth 1311
> >>>>
> >>>> 3) But now we create another policy in which we will nest the
> >>>> customer policy. This is the one that gets applied to the
> >>>> interface.
> >>>>
> >>>> policy-map E1-POLICY
> >>>>  class CUSTOMERS
> >>>>   police 2048000
> >>>>   service-policy CUSTOMER-ACCESS
> >>>>
>
>Note this will currently have the same effect as before until you scale 
>back the numbers.
>
>This set up is great because you can come back later and nest more 
>customers but also create non-customer classes that don't need to be 
>nested. This is probably more applicable to faster links but it's a nice 
>scalable way of doing things.
>
>e.g.
> >>>> policy-map E1-POLICY
> >>>>  class CUSTOMERS
> >>>>   service-policy CUSTOMER-ACCESS
> >>>>  class MY-REAL-TIME
> >>>>   priority 200

 > So if I want to limit all users to 3-Mb I would use "X 3072"?
 > And for 5-Mb I would use "5120"?

bandwidth statements are in kbs, but policing is done bps so you have to 
be a little careful.
Also whilst 2mb on an E1 is 2x1024x1000 bits per second, on ethernet 
it's 2x1000x1000.

To police everyone to 5mb on Ethernet would be:
	police 5000000

Then divvy up your 4750 bandwidth points (5000kbs x 95%) amongst the 
users under their respective classes.

************

I have just realised I left off one important command in my earlier post:

interface serial 1/0:15
   max-reserved-bandwidth 95	<<<<

This is essential, since the default is only 75%.

 > Also, should I use:
 >  - standard access lists <1-99>, or
 >  - extended access lists <100-199>, or
 >  - does it not matter?

It doesn't matter which kind you use, but if you only need to match on 
source ip then use standard to minimise the cpu required to process the ACL.