[c-nsp] rate-limit plus queueing strategy

[Anton Kapela]

> steve at telecomplete.co.uk wrote:
> > Hi,
> >  does anyone know.. is it possible to combine rate limit 
> with custom or priority queueing?

Yes, indeed it is! However, there's platform specific caveats which you
need to be aware of. 

> !
> interface FastEthernetX/Y
>   service-policy input PARENT
> !
> policy-map PARENT
>   class class-default
>   police <yada yada> (or even shape <yada yada> if your HW 
> can do it>!)
>   service-policy CHILD
> !
> policy-map CHILD
>   class gold
>   <gold priority foo>
>   class silver
>   <silver bandwidth foo>
>   class bronze
>   <bronze bandwidth foo>
>   class class-default
>   <default foo>

..a fine example of nested policies, but this won't work, because when:

> policy-map PARENT
>   class class-default
>   police <yada yada>

..is used as stated, it won't provide backpressure to the CHILD policy,
thus the bandwidth and/or priority rules won't do anything. 

The poster is correct & good in mentioning ("or even shape <yada
yada>"), however "shape" (gts-generic traffic shaping) only works on
specific types of boxes  with specific interfaces. 3550, 3560, 3750,
3750me, cat6/7600 (without specific linecards that provide this)  all
the XL's, and cat4k's will leave you cold.  Want to do class-based
queuing on ethernet subinterfaces? Sorry! Expecting ingress shaping,
too? Forget it! 

Bottom line is this feature is _required_ to do what you outline
wanting. So, unless you're using a cpu-switched/distributed cpu-switched
box (17xx, 18xx, 26xx, 28xx, 36xx, 38xx, 72xx, 75xx, gsr, etc) or a
l2/l3 switch with appropriate interfaces (sip/spa, osm, flexwan in
65xx/76xx), nested polices that depend on backpressure from GTS simply
won't work or do what you need. 

One way I've dealt with this is to write several classes matching
specific traffic (tcp80 vs. icmp vs. udp classes) and have set specific
policed rates for each. Thus, if your aim is to 'tame' 50mbits of HTTP
(or some well-behaved application), you can do so selectively and not
impact other things like ssh, telnet, etc. You could even do this with
rate-limit statements directly on the interface, using ACL's to match
specific packets within each statement if you wished to avoid class-maps
and policy-maps. 

Lastly, one glimmer of hope for if you're using of the l3 switches
(without special ints): You can use class/policy maps to set the class
of service value (CoS in docs) on packets leaving the switch, and define
a CoS to queue map for the switch. On 3550 for instance, there are 4
output queues, one of which can be marked as a 'priority' queue. You can
also configure weighted round robin on the remaining queues, given each
of the three remaining queues a specific share of the output bandwidth.
But, these queue configurations are only going to be effective at native
rates of the interface; i.e. 10mbits, 100, etc. If you were to setup
WRR/CoS maps/etc, and then policed the port at 50mbits, none of the
queues would ever fill, and no prioritization would happen. 

Best of luck,

-Tk