User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

cisco [2010/04/15 21:18] (current)
Line 1: Line 1:
 +**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 
 +**No nonsense HOWTO:**
 +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:
 +<​html>​(config)#​ mls qos</​html>​
 +For an example, we have 2 customers assigned /25's out of 
 +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:
 +<​html>​ip access-list extended custa-in
 + ​permit ip any
 +ip access-list extended custa-out
 + ​permit ip any
 +ip access-list extended custb-in
 + ​permit ip any
 +ip access-list extended custb-out
 + ​permit ip any</​html>​
 +Now, the associated class-maps
 +<​html>​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</​html>​
 +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 
 +<​html>​policy-map cust-out
 + class custa-out
 +  police 20000000
 + class custb-out
 +  police 30000000</​html>​
 +This gives custa 20Mbps and custb 30Mbps. However, it won't do anything ​
 +until attached to the interface:
 +<​html>​interface Gi3/1
 + ​service-policy input cust-out</​html>​
 +Now to control inbound traffic. Since inbound can be on either of two 
 +ports, we must use aggregate policers for that:
 +<​html>​mls qos aggregate-policer custa-in 20000000
 +mls qos aggregate-policer custb-in 30000000</​html>​
 +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.
 +<​html>​policy-map inbound
 + class custa-in
 +  police aggregate custa-in
 + class custb-in
 +  police aggregate custb-in</​html>​
 +And assign it to the upstream ports:
 +<​html>​interface fa2/1
 + ​service-policy input inbound
 +interface fa2/2
 + ​service-policy input inbound
 + class cust</​html>​
 +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)
 +<​html>​ip access-list extended incoming-icmp
 + ​permit icmp any any</​html>​
 +Now set up a class map for this and add it to the inbound policy.
 +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:
 +<​html>​sho mls qos ip</​html>​
 +to get a table showing the policers, packets transmitted,​ and packets ​
 +dropped. --- //[[pyro dot|Steven James]] & [[eduard dot|Eduard Goiu]] 2005/12/17 07:46//
cisco.txt ยท Last modified: 2010/04/15 21:18 (external edit)