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 <[email protected]> wrote: > From: Rens <[email protected]> > Subject: Re: [c-nsp] rate-limit 2 subinterfaces with shared bandwidth > To: "'Chris Evans'" <[email protected]>, "'Pshem Kowalczyk'" > <[email protected]> > Cc: [email protected] > 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:[email protected]] > > Sent: woensdag 2 februari 2011 23:01 > To: Pshem Kowalczyk > Cc: [email protected]; > 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" <[email protected]> > wrote: > > Hi, > > > > On 3 February 2011 05:45, Rens <[email protected]> > 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 > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
