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

[Tony]

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