Purpose of the 'cos flood-ctrl' command set

[FAQ_User]

Article ID: 16074

Products
7100-Series
S-Series
Matrix N-Series DFE
K-Series
I-Series
G-Series
D-Series
C5, C3, C2-Series
B5, B3, B2-Series
A4-Series

Changes
Implemented the '

code:

cos ... flood-ctrl

' command set - this does not require licensing - in order to limit the ingress of what is perceived to be a flood of excess traffic from the network.

For example:

#cos state

set cos state enable

!

#cos port-config

set cos port-config flood-ctrl 1.0 ports ge.1.10;ge.1.13 append

!

#cos port-resource

set cos port-resource flood-ctrl 1.0 unicast rate 5

set cos port-resource flood-ctrl 1.0 multicast rate 5

set cos port-resource flood-ctrl 1.0 broadcast rate 5

Symptoms
The applied Flood Control configuration has no discernable limiting effect on the volume of incoming traffic.

Cause
The Configuration/CLI Guides outline the purpose of the Flood Control feature as follows:

CoS-based flood control prevents configured ports from being disrupted by a traffic storm by rate limiting specific types of packets through those ports. When flood control is enabled on a port, incoming traffic is monitored over one second intervals. During an interval, the incoming traffic rate for each configured traffic type (unicast, broadcast, or multicast) is compared with the configured traffic flood control rate, specified in packets per second. If, during a one second interval, the incoming traffic of a configured type reaches the traffic flood control rate configured on the port, CoS-based flood control drops the traffic until the interval ends. Packets are then allowed to flow again until the limit is again reached.

What is not made fully clear in the Configuration and CLI Guides but is made slightly clearer in Release Notes...
(7100/S/N/K-Series: "

code:

Support for Flood-Limiting controls for Broadcast,

code:

Multicast, and Unknown Unicast per port.

")
(I/G/D/C/B/A-Series: "

code:

CoS MIB based Flood Control (broadcast, multicast,

code:

and unknown unicast)

")
...is that the Flood Control feature is intended to act only upon egress-port-flooded traffic which has been forwarded via the CPU-based "soft path" rather than having been forwarded more efficiently via hardware. Such soft-forwarded traffic otherwise has the potential to contribute to poor throughput performance and high CPU utilization. Broadcast traffic is always flooded, multicast traffic is flooded only when not scoped by IGMP Snooping ('

code:

set igmpsnooping...

') or Static Multicast MAC configuration ('

code:

set mac multicast...

'), and unicast traffic is flooded whenever the destination MAC address has not been learned for the ingress VLAN (see the IVL/SVL discussion in 4918).

The Flood Control feature is assigned to traffic upon its ingress to the configured port(s), but only potentially takes effect upon CPU-flooded traffic before such traffic is - or would have been - forwarded by the CPU to one or more egress ports. If the traffic has no appreciable flooded element to it, then no rate-limiting effect will be observed.

Solution
If the intent is to broadly rate-limit traffic, this is most typically implemented using Policy-based inbound rate-limiting, outbound rate-limiting, and/or outbound rate shaping (11667) - depending upon design requirements and product hardware/firmware support. For products not supporting Policy either by design (A2-Series) or in the absence of a required policy license (D, B3, B2-Series), then DiffServ may be used instead (5848) for outbound rate-limiting.

Contact the GTAC for further assistance, as necessary.