[c-nsp] rate-limit 2 subinterfaces with shared bandwidth

[Chris Evans]

If you don't want to muck with DSCP you can set a qos-group for the traffic
on the ingress policy and then match that qos-group on the egress policy..
You could also match it based on source-interface too I believe.

Also you don't have to police the traffic down on the ingress port, that is
just if you want to. MQC is very powerful, tons of different style points in
how to do your desired results.

On Thu, Feb 3, 2011 at 7:17 PM, Tony <td_miles at yahoo.com> wrote:

> Lets start with some assumptions:
>
> 1. H-Qos is available. If it's not, then you're probably SOOL.
> 2. You're not doing any QoS at the moment and don't mind changing DSCP
> values randomly on packets
> 3. You have the CPU power to do this. Depends on your platform, but should
> be OK
> 4. This is only for UPLOAD traffic, ie traffic from your router outbound
> towards your WAN/Internet link (fa0/0)
> 5. You can't control what happens inbound (download) unless you control the
> router on the other end of your 10M link, so let's not worry about that.
> 6. You have other traffic that is not on these two sub-ints that use the
> remaining 2Mbps (or what is it used for) ?
>
>
> Steps:
>
> 1. Setup an ingress QoS policy on your two Fa0/1 sub-ints to tag the first
> 4Mbps of traffic as CS2 (DSCP-16) and then anything over 4Mbps as CS1
> (DSCP-8). I've just chosen those DSCP values, nothing special about them
> (except that CS1 is commonly used for excess/scavenger traffic).
>
> ===
> ! create an ACL to match all IP traffic
> ip access-list extended match-ip-any
>  permit ip any any
>
> ! put it in a traffic class
> class-map match-any 8mbps
>  match access-group name match-ip-any
>
> ! create policy-map
> policy-map input-mark
>  class 8mbps
> police cir 4000000 bc 4000000 conform-action set-dscp-transmit cs2
> exceed-action set-dscp-transmit cs1 violate-action drop
>
> ! apply policy map ingress on your two sub-ints
> int fa0/1.100
>  service-policy input input-mark
> int fa0/1.101
>  service-policy input input-mark
> ===
>
> Check that this is working using "show policy-map int xyz" and that you are
> matching/tagging traffic as expected. Of great interest is to create 8Mbps
> of traffic from one sub-int and make sure 4Mbps is matched into each class.
> Then create more than 8Mbps and see if you get 4Mbps in each class with
> remainder dropped.
>
>
> 2. On your 10Mbps interface setup a H-Qos policy to shape to 10Mbps with a
> child policy that then reserves 8Mbps of bandwidth for CS2 traffic and a
> really small reservation for CS1 traffic (the excess). Any other traffic
> (not from these two sub-ints) won't have any marking (DSCP-0 by default) and
> will go into the default class and get a share of whatever is left.
>
> ===
> ! put your traffic into classes
> class-map match-any dscp16
>  match ip dscp cs2
> class-map match-any dscp8
>  match ip dscp cs1
>
> ! create child policy to guarantee 8Mbps to dscp16 and not much to dscp8
> policy-map child-policy
>  class dscp16
>  bandwidth percent 80
>  class dscp8
>  bandwidth percent 1
>  police 4000000
>  class class-default
>  fair-queue
>
> ! create parent shaper to 10Mbps
> policy-map policy-parent-10m
>  class class-default
>  shape average 10000000
>  service-policy child-policy
>
> ! apply to your interface
> int fa0/0
>  service-policy output policy-parent-10m
> ===
>
>
> This MIGHT go someway to achieving what you'd like, but you might have to
> tweak it. You might need to play with the queue size on the dscp8 class if
> the router decides to make it too small so you don't get tail drops. It
> won't hard limit to 8Mbps each of your sub-ints, but having a small
> percentage of allocated traffic to that which is excess (the dscp8 class)
> means that it should only get bandwidth when it is available and not being
> used by anything else. Policing the dscp8 class to 4Mbps doesn't restrict
> your two sub-ints to a combined 8Mbps, but instead a combined 12Mbps, which
> will never happen as the parent shaper will only allow 10Mbps with
> preference given to up to 8Mbps of dscp16 traffic.
>
> So in theory if both of your sub-ints have 20Mbps of traffic inbound, then
> they should get 5Mbps each. If there is any OTHER traffic, then they should
> get 4Mbps each guaranteed and then a share of the remaining 2Mbps with
> whatever the other traffic is.
>
> I think I've got the police statement correct with cir & bc, but you might
> need to read up on this and change the values around if I've got it wrong
> and it should be 8m cir with burst (or some other combination).
>
> There could be numerous mistakes in the above, I've typed it out and not
> tried it on an actual box. Happy to hear comments on whether it does/doesn't
> work for you (or from any other who have thoughts on it).
>
>
>
> regards,
> Tony.
>
>
>
> --- On Fri, 4/2/11, Rens <rens at autempspourmoi.be> wrote:
>
> > From: Rens <rens at autempspourmoi.be>
> > Subject: Re: [c-nsp] rate-limit 2 subinterfaces with shared bandwidth
> > To: "'Chris Evans'" <chrisccnpspam2 at gmail.com>, "'Pshem Kowalczyk'" <
> pshem.k at gmail.com>
> > Cc: cisco-nsp at puck.nether.net
> > Received: Friday, 4 February, 2011, 5:26 AM
> > Maybe I didn't explain myself very
> > well but, here is what I want to do:
> >
> >
> >
> > Fa0/0 = WAN at 10 Mbps
> >
> >
> >
> > Fa0/1.100 & Fa0/1.101 currently rate-limited each at 8
> > Mbps
> >
> >
> >
> > rate-limit input 8192000 1536000 2048000 conform-action
> > transmit
> > exceed-action drop
> >
> > rate-limit output 8192000 1536000 2048000 conform-action
> > transmit
> > exceed-action drop
> >
> >
> >
> > But Fa0/1.100 & Fa0/1.101 should never go over 8 Mbps
> > together so they won't
> > saturate my 10 Mbps WAN and always have 2 Mbps left
> >
> >
> >
> >
> >
> > From: Chris Evans [mailto:chrisccnpspam2 at gmail.com]
> >
> > Sent: woensdag 2 februari 2011 23:01
> > To: Pshem Kowalczyk
> > Cc: cisco-nsp at puck.nether.net;
> > Rens
> > Subject: Re: [c-nsp] rate-limit 2 subinterfaces with shared
> > bandwidth
> >
> >
> >
> > This is commonly know has h-qos.   Not all
> > platforms support it However..
> >
> > On Feb 2, 2011 4:59 PM, "Pshem Kowalczyk" <pshem.k at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > On 3 February 2011 05:45, Rens <rens at autempspourmoi.be>
> > wrote:
> > >> Hi,
> > >> I have 2 subinterfaces (Fa0/1.100 &
> > Fa0/1.200)
> > >> Here are the things I would like:
> > >> 1)      rate limit both to 8 Mbps
> > >> 2)      never use over 8 Mbps
> > together
> > >> 3)      the first subinterface
> > should always have 4 Mbps needed
> > >> Is this possible?
> > >
> > > Depending on your hardware/software you might be able
> > to create a
> > > parent policy attached to the physical interface
> > (Fa0/1) that
> > > classifies traffic based on vlan id (match vlan).
> > Another option to
> > > try (only in inbound direction) is to match on
> > interface (match
> > > input-interface). You might also try attaching one
> > policy to the
> > > physical interface and another to the subinterfaces.
> > >
> > > kind regards
> > > Pshem
> > >
>
>
>
>