Rate limiting connections on a Cisco 65xx would seem to be a commonly desired configuration, yet documentation on it is a bit sketchy IMHO.

Firstly, it's lumped under QoS. While QoS is certainly related, there are reasons to rate limit that have little to do with QoS. That is, a small colo facillity might well wish to rate limit all customers in accordance with contracted bandwidth while having no desire to configure what most would consider QoS (That is segregating traffic by type (such as audio stream, web, ftp) and assigning performance priority to each type.

No nonsense HOWTO:

Background: Rate limiting is accomplished through the class-map and policy-map. A class-map is a named configuration object which classifies traffic, in this case by matching criteria in the IP header such as protocol, source and/or destination address, etc. This is accomplished by assigning an extended access-list to the class.

In turn, a policy-map is a config object containing one or more class-maps and what policies to apply to those classes.

Finally, a policy map is attached to one or more interfaces where the policy is to be applied.

Note that these policies are only garanteed to work on Rx packets for an interface, not necessarily Tx traffic. Therfore, to rate-limit bi-directionally, a single customer will be assigned two of each of access-list and class map. One for Rx packets on the customer connection (or trunk to the customer connection), and one on the upstream port(s) to limit their outbound traffic.

All rate limiting is based on the policer. A policer is a software object which counts packets/bytes for a particular class of traffic (in this case, all trafic to/from a particular customer). The police policy specifies the allowed bandwidth (and how much traffic may burst over that bandwidth before policing happens). The default action for packets beyond that is to drop them. Other setups that are not so concerned with their upstream traffic may instead choose to mark the excess to be dropped first if necessary.

In cases where the customer is connected by a single port, a regular policer (as part of the policy/class) may be used. If the customer has multiple connections to the switch, a global named policer may be used and attached to the policy-map on each of those ports. This aggregate policer will maintain a single global bandwidth figure over all configured ports. If a seperate policer is used on each port (even if THE SAME POLICY-MAP is attached to all ports!!!), the bandwidth limits will be applied PER-PORT, effectively multiplying the specified limit by the number of ports (probably not what you want!).

Configuration details.

Firstly, none of this will have any effect at all unless mls is enabled globally. Instead, when attaching a policy to an interface, you'll get a nearly useless error message that the interface doesn't support the required features (it might be a bit more helpful if it would indicate that the needed support must be enabled rather than claiming it to be non-existant!) So, first:

(config)# mls qos

For an example, we have 2 customers assigned /25's out of 192.168.1.0/24 First, we must set up access-lists for them, one for inbound (from the net) and one outbound (to the net) so from the (config) prompt:

ip access-list extended custa-in permit ip any 192.168.1.1 0.0.0.127   ip access-list extended custa-out permit ip 192.168.1.1 0.0.0.127 any   ip access-list extended custb-in permit ip any 192.168.1.128 0.0.0.127   ip access-list extended custb-out permit ip 192.168.1.128 0.0.0.127 any

Now, the associated class-maps

class-map custa-in match access-group name custa-in   class-map custa-out match access-group name custa-out   class-map custb-in match access-group name custa-in   class-map custb-out match access-group name custa-out

Now we have classified the traffic, but we have to do something with it. Lets say for the sake of argument, both customers are vlan trunked to Gi3/1 and we have 2 providers on fa2/1 and fa2/2. Your milage may vary!

First, we will police the output traffic for both customers. Since this is on a single interface, there must be a single policy containing both classes:

policy-map cust-out class custa-out police 20000000 class custb-out police 30000000

This gives custa 20Mbps and custb 30Mbps. However, it won't do anything until attached to the interface:

interface Gi3/1 service-policy input cust-out

Now to control inbound traffic. Since inbound can be on either of two ports, we must use aggregate policers for that:

mls qos aggregate-policer custa-in 20000000 mls qos aggregate-policer custb-in 30000000

Note that the bandwidth must be set in the policer itself. Since these are aggregate (global) policers, they are named. The ones for outbound are unnamed since they will only be referenced by one policy.

policy-map inbound class custa-in police aggregate custa-in class custb-in police aggregate custb-in

And assign it to the upstream ports:

interface fa2/1 service-policy input inbound interface fa2/2 service-policy input inbound class cust

Note that the same policy map is applied to two ports here. The policy map is more of a macro than an object. That is, this only works right because the classes in the policy-map refer to aggregate (names) policers. Otherwise, each use of the policy-map inbound would create a new policer that has no knowledge of the other instances (and so the limits will be PER-PORT rather than being global to all ports where the policy-map is attached).

Further work:

This is a simple no-nonsense (I hope) quick guide. It's more or less what I wish I had found on Google when I needed to set up rate limiting. There are several more things that might be a good idea in production, but with this document as a beginning, they're more or less variations on a theme.

For example, to limit incoming icmp traffic (probably not a bad idea)

ip access-list extended incoming-icmp permit icmp any any

Now set up a class map for this and add it to the inbound policy.

IMPORTANT SAFETY TIP: if you are using the network to configure the router, make sure that traffic is not included in a policer, the last time you need to have packets dropping is when you're trying to find out why your net is overloaded!!! If you configure a catch-all policer (not a bad idea), you might want to add a deny to the access-list for packets to your peering address(es) from your peers and the address(es) you might connect from so you wont lose peering sessions or the ability to log in in the event of a flood. Remember, the snowstorm, the guy cutting the wrong wires in the phone closet (killing your back door POTS modem), and the customer mis-configuring and becoming an accidental warez site will all happen at the same time. A little planning now will save a lot of pain then.

Final note:

To see what's happening, from the enable prompt, issue: sho mls qos ip

to get a table showing the policers, packets transmitted, and packets dropped. — Steven James & Eduard Goiu 2005/12/17 07:46

cisco.txt · Last modified: 2010/04/15 15:18 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki