Traffic Shaping HOW-TO?

Discussion in 'Cisco' started by Jesse Gardner, Nov 24, 2004.

  1. 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, Nov 24, 2004
    #1
    1. Advertising

  2. Jesse Gardner

    Toby Guest

    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" <> wrote in message
    news:...
    > 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!!!
     
    Toby, Nov 24, 2004
    #2
    1. Advertising

  3. 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" <> wrote in message
    > news:...
    >
    >>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, Nov 24, 2004
    #3
  4. Jesse Gardner

    Ben Guest

    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" <> wrote in message
    >> news:...
    >>
    >>> 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, Nov 24, 2004
    #4
  5. Jesse Gardner

    Ben Guest

    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" <> wrote in message
    >>> news:...
    >>>
    >>>> 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, Nov 24, 2004
    #5
  6. Jesse Gardner

    Toby Guest

    "Ben" <> wrote in message news:...
    > 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" <> wrote in message
    >>>> news:...
    >>>>
    >>>>> 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
     
    Toby, Nov 24, 2004
    #6
  7. 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" <> wrote in message news:...
    >
    >>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" <> wrote in message
    >>>>>news:...
    >>>>>
    >>>>>
    >>>>>>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, Nov 24, 2004
    #7
  8. Jesse Gardner

    Ben Guest

    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" <> wrote in message
    >> news:...
    >>
    >>> 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" <> wrote in message
    >>>>>> news:...
    >>>>>>
    >>>>>>
    >>>>>>> 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, Nov 25, 2004
    #8
  9. Jesse Gardner

    Toby Guest

    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.
     
    Toby, Nov 25, 2004
    #9
  10. Jesse Gardner

    Captain Guest

    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" <> 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.

    >
     
    Captain, Nov 25, 2004
    #10
  11. Jesse Gardner

    Toby Guest

    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" <> wrote in message
    news:...
    > 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" <> 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.

    >>

    >
     
    Toby, Nov 25, 2004
    #11
  12. Jesse Gardner

    Captain Guest

    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" <> wrote in message
    >news:...
    >> 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" <> 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.
    >>>

    >>

    >
     
    Captain, Nov 25, 2004
    #12
  13. In article <>,
    Captain <> 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)
     
    Walter Roberson, Nov 25, 2004
    #13
  14. In article <co5oj3$rfo$>, -
    cnrc.gc.ca says...
    > In article <>,
    > Captain <> 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...
     
    Dan Swartzendruber, Nov 25, 2004
    #14
  15. Jesse Gardner

    Captain Guest

    On Thu, 25 Nov 2004 18:23:33 -0500, Dan Swartzendruber
    <> wrote:

    >In article <co5oj3$rfo$>, -
    >cnrc.gc.ca says...
    >> In article <>,
    >> Captain <> 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)...
     
    Captain, Nov 26, 2004
    #15
  16. In article <>, 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...
     
    Dan Swartzendruber, Nov 26, 2004
    #16
  17. Jesse Gardner

    Ben Guest

    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 <>, 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...
    >
     
    Ben, Nov 26, 2004
    #17
  18. Jesse Gardner

    Captain Guest

    On Fri, 26 Nov 2004 09:58:29 GMT, Ben <> 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
     
    Captain, Nov 26, 2004
    #18
  19. Jesse Gardner

    Ben Guest

    > 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.
     
    Ben, Nov 26, 2004
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kenny D
    Replies:
    1
    Views:
    699
    Remien, Carsten
    Dec 5, 2003
  2. Hypno999

    traffic-shaping limit ftp traffic

    Hypno999, Oct 7, 2005, in forum: Cisco
    Replies:
    5
    Views:
    3,690
  3. Skybuck Flying
    Replies:
    0
    Views:
    4,928
    Skybuck Flying
    Jan 19, 2006
  4. Nova
    Replies:
    2
    Views:
    993
    ~misfit~
    Mar 20, 2006
  5. Replies:
    1
    Views:
    713
    Ios2012
    Oct 4, 2011
Loading...

Share This Page