Rate-limiting for all traffic operates on a per-port basis to allow only the specified bandwidth to be used for inbound or outbound traffic. When traffic exceeds the configured limit, it is dropped. This effectively sets a usage level on a given port and is a tool for enforcing maximum service level commitments granted to network users. This feature operates on a per-port level and is not configurable on port trunks. Rate-limiting is designed to be applied at the network edge to limit traffic from non-critical users or to enforce service agreements such as those offered by Internet Service Providers (ISPs) to provide only the bandwidth for which a customer has paid.
|
|
NOTE: Rate-limiting also can be applied by a RADIUS server during an authentication client session. (See the Access Security Guide.) |
|
|
|
|
CAUTION: Rate-limiting is intended for use on edge ports in a network. HP does not recommend it for use on links to other switches, routers, or servers within a network, or for use in the network core. Doing so can interfere with applications the network requires to function properly. |
|
|
The switches also support ICMP rate-limiting to mitigate the effects of certain ICMP-based attacks.
The mode using bits per second (bps) in releases before K.12.XX has been replaced by the kilobits per second (kbps) mode. Switches that have configurations with bps values are automatically converted when you update your software to the new version. However, you must manually update to kbps values an older config file that uses bps values or it will not load successfully onto a switch running later versions of the software (K.12.XX or greater.)
-
The
rate-limit icmp
command specifies a rate limit on inbound ICMP traffic only (See “ICMP Rate-Limiting” on page 13-9) -
Rate-limiting does not apply to trunked ports (including meshed ports.)
-
Kbps rate-limiting is done in segments of 1% of the lowest corresponding media speed.
For example, if the media speed is 100 Kbps, the value would be 1 Mbps.
-
Percentage limits are based on link speed.
For example, if a 100 Mbps port negotiates a link at 100 Mbps and the inbound rate-limit is configured at 50%, the traffic flow through that port is limited to no more than 50 Mbps. Similarly, if the same port negotiates a 10 Mbps link, it allows no more than 5 Mbps of inbound traffic.
-
Configuring a rate limit of 0 (zero) on a port blocks all traffic on that port. However, if this is the desired behavior on the port, HP Switch recommends that you use the
command instead of configuring a rate limit of 0.<PORT-LIST>
disable -
You can configure a rate limit from either the global configuration level or from the port context level.
Example
Either of the following commands configures an inbound rate limit of 60% on ports A3 to A5:
HP Switch (config #) int a3-a5 rate-limit all in percent 60 HP Switch (eth-A3-A5)# rate-limit all in percent 60
-
When going from a switch with faster links to a switch with slower links, it is better to force the speed of the port connection to be slower rather than to rate-limit the traffic.
-
Rate-limiting operates on a per-port basis, regardless of traffic priority. Rate-limiting is available on all types of ports and at all port speeds configurable for these switches.
-
Except for the
egress per-queue
option with static trunks on 5400R and 3800 ProVision switches, rate-limiting is not supported on trunked ports (including mesh ports.) Where trunked ports are not supported, configuring a port for rate-limiting and then adding it to a trunk suspends rate-limiting on the port while it is in the trunk. Attempting to configure rate-limiting on a port that already belongs to a trunk generates the following message: -
Rate-limiting for inbound and outbound traffic are separate features. The rate limits for each direction of traffic flow on the same port are configured separately—even the specified limits can be different.
-
Rate-limiting and hardware: The granularity of actual limits may vary across different switch models.
-
Rate-limiting is visible as an outbound forwarding rate. Because inbound rate-limiting is performed on packets during packet-processing, it is not shown via the inbound drop counters. Instead, this limit is verifiable as the ratio of outbound traffic from an inbound rate-limited port versus the inbound rate. For outbound rate-limiting, the rate is visible as the percentage of available outbound bandwidth (assuming that the amount of requested traffic to be forwarded is larger than the rate-limit.)
-
Operation with other features: Configuring rate-limiting on a port where other features affect port queue behavior (such as flow control) can result in the port not achieving its configured rate-limiting maximum. For example, in a situation whereflow control is configured on a rate-limited port, there can be enough "back pressure" to hold high-priority inbound traffic from the upstream device or application to a rate that is lower than the configured rate limit. In this case, the inbound traffic flow does not reach the configured rate and lower priority traffic is not forwarded into the switch fabric from the rate-limited port. (This behavior is termed "head-of-line blocking" and is a well-known problem with flow-control.)
In another type of situation, an outbound port can become oversubscribed by traffic received from multiple rate-limited ports. In this case, the actual rate for traffic on the rate-limited ports may be lower than configured because the total traffic load requested to the outbound port exceeds the port's bandwidth, and thus some requested traffic may be held off on inbound.
-
Traffic filters on rate-limited ports. Configuring a traffic filter on a port does not prevent the switch from including filtered traffic in the bandwidth-use measurement for rate-limiting when it is configured on the same port. For example, ACLs, source-port filters, protocol filters, and multicast filters are all included in bandwidth usage calculations.
-
Monitoring (mirroring) rate-limited interfaces.If monitoring is configured, packets dropped by rate-limiting on a monitored interface are still forwarded to the designated monitor port. (Monitoring shows what traffic is inbound on an interface, and is not affected by "drop" or "forward" decisions.)
-
Optimum rate-limiting operation. Optimum rate-limiting occurs with 64-byte packet sizes. Traffic with larger packet sizes can result in performance somewhat below the configured bandwidth. This is to ensure the strictest possible rate-limiting of all sizes of packets.