•
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.
•
Outbound traffic flow:
Configuring ICMP rate-limiting on an interface does
not
control the rate of outbound
traffic flow on the interface.
ICMP rate-limiting trap and Event Log messages
If the switch detects a volume of inbound ICMP traffic on a port that exceeds the ICMP rate-limit configured for
that port, it generates one SNMP trap and one informational Event Log message to notify the system operator of
the condition. (The trap and Event Log message are sent within two minutes of when the event occurred on the
port.) For Example:
I 06/30/05 11:15:42 RateLim: ICMP traffic exceeded configured limit on port A1
These trap and Event Log messages provide an advisory that inbound ICMP traffic on a given interface has
exceeded the configured maximum. The additional ICMP traffic is dropped, but the excess condition may indicate
an infected host (or other traffic threat or network problem) on that interface. The system operator should
investigate the attached devices or network conditions further; the switch does not send more traps or Event Log
messages for excess ICMP traffic on the affected port until the system operator resets the port's ICMP trap
function.
The switch does not send more traps or Event Log messages for excess ICMP traffic on the affected port until the
system operator resets the port’s ICMP trap function. The reset can be done through SNMP from a network
management station or through the CLI with the
trap-clear
command option.
Chapter 6 Port Traffic Controls
161
