Management and Configuration Guide K/KA/KB.15.15

Rate-limiting is not permitted on mesh
ports
Either type of rate-limiting (all-traffic or ICMP) can reduce
the efficiency of paths through a mesh domain.
Rate-limiting is not supported on port
trunks
Neither all-traffic nor ICMP rate-limiting are supported on
ports configured in a trunk group.
ICMP percentage-based rate-limits
are calculated as a percentage of the
negotiated link speed
For example, if a 100 Mbps port negotiates a link to another
switch at 100 Mbps and is ICMP rate-limit configured at
5%, the inbound ICMP traffic flow through that port is limited
to 5 Mbps. Similarly, if the same port negotiates a 10 Mbps
link, it allows 0.5 Mbps of inbound traffic. If an interface
experiences an inbound flow of ICMP traffic in excess of its
configured limit, the switch generates a log message and
an SNMP trap (if an SNMP trap receiver is configured.)
ICMP rate-limiting is port-based ICMP rate-limiting reflects the available percentage of an
interface's entire inbound bandwidth. The rate of inbound
flow for traffic of a given priority and the rate of flow from
an ICMP rate-limited interface to a particular queue of an
outbound interface are not measures of the actual ICMP rate
limit enforced on an interface.
Below-maximum rates ICMP rate-limiting operates on a per-interface basis,
regardless of traffic priority. Configuring ICMP rate-limiting
on an interface where other features affect inbound port
queue behavior (such as flow control) can result in the
interface not achieving its configured ICMP rate-limiting
maximum. For example, in some situations with flow control
configured on an ICMP rate-limited interface, there can be
enough "back pressure" to hold high-priority inbound traffic
from the upstream device or application to a rate that does
not allow bandwidth for lower-priority ICMP traffic. In this
case, the inbound traffic flow may not permit the forwarding
of ICMP traffic into the switch fabric from the rate-limited
interface. (This behavior is termed "head-of-line blocking"
and is a well-known problem with flow-control.) In cases
where both types of rate-limiting (rate-limit all and
rate-limit icmp) are configured on the same interface,
this situation is more likely to occur.
In another type of situation, an outbound interface can
become oversubscribed by traffic received from multiple
ICMP rate-limited interfaces. In this case, the actual rate for
traffic on the rate-limited interfaces may be lower than
configured because the total traffic load requested to the
outbound interface exceeds the interface's bandwidth, and
thus some requested traffic may be held off on inbound.
Monitoring (mirroring) ICMP
rate-limited interfaces
If monitoring is configured, packets dropped by ICMP
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 inbound bandwidth. This
is to ensure the strictest possible rate-limiting of all sizes of
packets.
ICMP rate-limiting 189