Matrix N-Series DFE
C5, C3, C2-Series
B5, B3, B2-Series
Implemented the '
cos ... flood-ctrl
- [code]#cos state[/code]
[code]set cos state enable[/code]
[code]set cos port-config flood-ctrl 1.0 ports ge.1.10;ge.1.13 append[/code]
[code]set cos port-resource flood-ctrl 1.0 unicast rate 5[/code]
[code]set cos port-resource flood-ctrl 1.0 multicast rate 5[/code]
[code]set cos port-resource flood-ctrl 1.0 broadcast rate 5[/code]
The applied Flood Control configuration has no discernable limiting effect on the volume of incoming traffic.
The Configuration/CLI Guides outline the purpose of the Flood Control feature as follows:
[code]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.[/code]
Support for Flood-Limiting controls for Broadcast,
Multicast, and Unknown Unicast per port.
CoS MIB based Flood Control (broadcast, multicast,
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 ('
set mac multicast...
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.
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.