The document conventions describe text formatting conventions, command syntax conventions, and
important notice formats used in Brocade technical documentation.
Text formatting conventions
Text formatting conventions such as boldface, italic, or Courier font may be used in the flow of the text
to highlight specific words or phrases.
Format
bold text
italic text
Courier font
Description
Identifies command names
Identifies keywords and operands
Identifies the names of user-manipulated GUI elements
Identifies text to enter at the GUI
Identifies emphasis
Identifies variables and modifiers
Identifies paths and Internet addresses
Identifies document titles
Identifies CLI output
Identifies command syntax examples
Command syntax conventions
Bold and italic text identify command syntax components. Delimiters and operators define groupings of
parameters and their logical relationships.
Convention
bold textIdentifies command names, keywords, and command options.
valueIn Fibre Channel products, a fixed value provided as input to a command
option is printed in plain text, for example, --show WWN.
[ ]
{x| y| z}
x | y
< >
...
\
Syntax components displayed within square brackets are optional.
Default responses to system prompts are enclosed in square brackets.
A choice of required parameters is enclosed in curly brackets separated by
vertical bars. You must select one of the options.
In Fibre Channel products, square brackets may be used instead for this
purpose.
A vertical bar separates mutually exclusive elements.
Nonprinting characters, for example, passwords, are enclosed in angle
brackets.
Repeat the previous element, for example, member[member...].
Indicates a “soft” line break in command examples. If a backslash separates
two lines of a command input, enter the entire command at the prompt without
the backslash.
Notes, cautions, and warnings
Notes, cautions, and warning statements may be used in this document. They are listed in the order of
increasing severity of potential hazards.
NOTE
A Note provides a tip, guidance, or advice, emphasizes important information, or provides a reference
to related information.
ATTENTION
An Attention statement indicates a stronger note, for example, to alert you when traffic might be
interrupted or the device might reboot.
CAUTION
A Caution statement alerts you to situations that can be potentially hazardous to you or cause
damage to hardware, firmware, software, or data.
DANGER
A Danger statement indicates conditions or situations that can be potentially lethal or
extremely hazardous to you. Safety labels are also attached directly to products to warn of
these conditions or situations.
Visit the Brocade website to locate related documentation for your product and additional Brocade
resources.
You can download additional publications supporting your product at www.brocade.com. Select the
Brocade Products tab to locate your product, then click the Brocade product name or image to open the
individual product page. The user manuals are available in the resources module at the bottom of the
page under the Documentation category.
To get up-to-the-minute information on Brocade products and resources, go to MyBrocade. You can
register at no cost to obtain a user ID and password.
Release notes are available on MyBrocade under Product Downloads.
White papers, online demonstrations, and data sheets are available through the Brocade website.
Getting technical help
Brocade resources
You can contact Brocade Support 24x7 online, by telephone, or by e-mail.
For product support information and the latest information on contacting the Technical Assistance
Center, go to http://www.brocade.com/services-support/index.html.
Use one of the following methods to contact the Brocade Technical Assistance Center.
OnlineTelephoneE-mail
Preferred method of contact for nonurgent issues:
•My Cases through MyBrocade
•Software downloads and
licensing tools
•Knowledge Base
Document feedback
Required for Sev 1-Critical and Sev
2-High issues:
•Continental US:
1-800-752-8061
•Europe, Middle East, Africa,
and Asia Pacific: +800-AT
FIBREE (+800 28 34 27 33)
•For areas unable to access toll
free number: +1-408-333-6061
•Toll-free numbers are available
in many countries.
support@brocade.com
Please include:
•Problem summary
•Serial number
•Installation details
•Environment description
To send feedback and report errors in the documentation you can use the feedback form posted with
the document or you can e-mail the documentation team.
Quality is our first concern at Brocade and we have made every effort to ensure the accuracy and
completeness of this document. However, if you find an error or an omission, or you think that a topic
needs further development, we want to hear from you. You can provide feedback in two ways:
•Through the online feedback form in the HTML documents posted on www.brocade.com.
•By sending your feedback to documentation@brocade.com.
Provide the publication title, part number, and as much detail as possible, including the topic heading
and page number if applicable, as well as your suggestions for improvement.
● About This Document........................................................................................................9
● What’s new in this document.......................................................................................... 10
● How command information is presented in this guide.....................................................10
About This Document
Introduction
This guide includes procedures for configuring the software. The software procedures show how to
perform tasks using the CLI. This guide also describes how to monitor Brocade products using statistics
and summary screens.
Supported Hardware
This guide supports the following product families from Brocade:
•FastIron X Series devices (chassis models):
‐FastIron SX 800
‐FastIron SX 1600
•Brocade FCX Series (FCX) Stackable Switch
•Brocade ICX™ 6610 (ICX 6610) Stackable Switch
•Brocade ICX 6430 Series (ICX 6430)
•Brocade ICX 6450 Series (ICX 6450)
•Brocade ICX 6650 Series (ICX 6650)
•Brocade TurboIron 24X Series
•Brocade ICX 7750 Series (ICX 7750)
For information about the specific models and modules supported in a product family, refer to the
hardware installation guide for that product family.
NOTE
The Brocade ICX 6430-C switch supports the same feature set as the Brocade ICX 6430 switch unless
otherwise noted.
NOTE
The Brocade ICX 6450-C12-PD switch supports the same feature set as the Brocade ICX 6450 switch
unless otherwise noted.
This document includes the information from FastIron software release 08.0.10b.
Summary of Enhancements in FastIron release 08.0.10bTABLE 1
FeatureDescriptionLocation
A new command has been added:
store-and-forward.
Support for Outbound rate
shaping.
The store-and-forward command
changes the switch mode to store-andforward.
Outbound rate shaping is supported
on ICX 7750 devices.
See store-and-forward on page
94.
See Configuring outbound rate
shaping for a LAG port on page 52
and Configuration notes for rate
shaping on page 50.
How command information is presented in this guide
For all new content, command syntax and parameters are documented in a separate command
reference section at the end of the publication.
In an effort to provide consistent command line interface (CLI) documentation for all products, Brocade
is in the process of preparing standalone Command References for the IP platforms. This process
involves separating command syntax and parameter descriptions from configuration tasks. Until this
process is completed, command information is presented in two ways:
•For all new content included in this guide, the CLI is documented in separate command pages.
The new command pages follow a standard format to present syntax, parameters, usage
guidelines, examples, and command history. Command pages are compiled in alphabetical order
in a separate command reference chapter at the end of the publication.
•Legacy content continues to include command syntax and parameter descriptions in the chapters
where the features are documented.
If you do not find command syntax information embedded in a configuration task, refer to the
command reference section at the end of this publication for information on CLI syntax and usage.
Lists the the individual BrocadeFastIron switches and the Quality of Service (QoS) features they
support.
The following table lists the individual BrocadeFastIron switches and the Quality of Service (QoS)
features they support. These features are supported in the Layer 2 and Layer 3 software images,
except where explicitly noted.
FeatureICX 6430ICX 6450FCXICX 6610ICX 6650FSX 800
FSX 1600
802.1p Quality of Service (QoS): Strict
Priority (SP), Weighted Round Robin
(WRR), Combined SP and WRR, 8
priority queues
Quality of Service (QoS) features are used to prioritize the use of bandwidth in a switch. When QoS
features are enabled, traffic is classified as it arrives at the switch, and processed through on the basis
of configured priorities. Traffic can be dropped, prioritized for guaranteed delivery, or subject to limited
delivery options as configured by a number of different mechanisms.
This chapter describes how QoS is implemented and configured in FastIron devices.
Classification is the process of selecting packets on which to perform QoS, reading the QoS
information, and assigning a priority to the packets. The classification process assigns a priority to
packets as they enter the switch. These priorities can be determined on the basis of information
contained within the packet or assigned to the packet as it arrives at the switch. Once a packet or
traffic flow is classified, it is mapped to a forwarding priority queue.
Packets on Brocade devices are classified in up to eight traffic classes with values from 0 to 7.
Packets with higher priority classifications are given a precedence for forwarding.
ICX 7750
08.0.10
Processing of classified traffic
The trust level in effect on an interface determines the type of QoS information the device uses for
performing QoS. The Brocade device establishes the trust level based on the configuration of various
features and whether the traffic is switched or routed. The trust level can be one of the following:
•Ingress port default priority.
•Static MAC address.
•Layer 2 Class of Service (CoS) value - This is the 802.1p priority value in the Ethernet frame. It
can be a value from 0 through 7. The 802.1p priority is also called the Class of Service .
•Layer 3 Differentiated Services Code Point (DSCP) - This is the value in the six most significant
bits of the IP packet header 8-bit DSCP field. It can be a value from 0 through 63. These values
are described in RFCs 2472 and 2475. The DSCP value is sometimes called the DiffServ value .
The device automatically maps the DSCP value of a packet to a hardware forwarding queue.
Refer to Viewing QoS settings on page 41.
•ACL keyword - An ACL can also prioritize traffic and mark it before sending it along to the next
hop. This is described under "QoS options for IP ACLs" section in the FastIron Ethernet SwitchSecurity Configuration Guide .
Given the variety of different criteria, there are many possibilities for traffic classification within a
stream of network traffic. For this reason, the priority of packets must be resolved based on which
criteria takes precedence. Precedence follows the schemes illustrated in the Determining a packettrust level - FSX devices through Determining a packet trust level - FCX, and ICX devices figures.
Determining the trust level of a packet
Packet trust level is determined differently on FSX devices than on FCX, and ICX series devices.
The following figure illustrates how FSX devices determine the trust level of a packet.
The Determining a packet trust level - FSX devices figure is not applicable to the third generation FSX
interface modules. To determine the trust level of a packet for the SX-FI48GPP, SX-FI-24GPP, SXFI-24HF, SX-FI-2XG, and SX-FI-8XG modules, refer to the Determining a packet trust level - SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and SX-FI-8XG modules figure.
As shown in the flowchart, the first criteria considered is whether the packet matches on an ACL that
defines a priority. Next, it checks if trust DSCP is enabled on the port. If this is not the case, the packet
is next classified based on the static MAC address. If this is not true and the packet is tagged, the
packet is classified with the 802.1p CoS value. If none of these is true, the packet is next classified
based on the ingress port default priority or the default priority of zero (0).
FIGURE 1 Determining a packet trust level - FSX devices
The Determining a packet trust level - SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and SXFI-8XG modules figure illustrates how the SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and
SX-FI-8XG modules determine the trust level of a packet. The marking process for these modules is
similar to the marking process for other FastIron SX modules. However, there are major differences
between these modules and other FastIron SX modules.
•For the SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and SX-FI-8XG modules, static
MAC priority takes higher precedence than VLAN priority. For other FastIron SX modules, VLAN
priority takes higher precedence over static MAC priority.
•For other FastIron SX modules, the priority of the dynamically learned MAC address is inherited
from the default port priority. For the SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and
SX-FI-8XG modules, the priority of the dynamically learned MAC address is not inherited from the
default port priority because it is not desirable to allow the port priority to take precedence over
the VLAN priority. All dynamically learned MAC addresses are assigned a priority of 0 in the SX-
FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG, and SX-FI-8XG modules. Therefore, configuring
a static MAC with a priority of 0 has no effect on QoS marking.
FIGURE 2 Determining a packet trust level - SX-FI48GPP , SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG,
and SX-FI-8XG modules
The following figure illustrates how FCX, and ICX series devices determine the trust level of a packet.
As shown in the flowchart, the first criteria considered is whether the packet matches on an ACL that
defines a priority. If this is not the case and the MAC address of the packet matches a static entry, the
packet is classified with the priority of the static MAC entry. If neither of these is true, the packet is next
Once a packet is classified, it is mapped to a forwarding queue. For all products except the SXF148GPP interface module and ICX 6430 switch, there are eight queues designated from 0 through 7.
The internal forwarding priority maps to one of these eight queues. For the SX-Fl48GPP interface
module and ICX 6430 switch, internal forwarding priority maps to four forwarding queues. The mapping
between the internal priority and the forwarding queue cannot be changed.
The following tables show the default QoS mappings for FCX platforms that are used if the trust level for
CoS or DSCP is enabled. For information on the SX-Fl48GPP interface module, refer to Queues for the
SX-FI48GPP interface module on page 20. For information on default QoS mappings for the ICX 6430
switch, refer to Queues for the ICX 6430 switch on page 22.
Mapping between the DSCP value and forwarding queue cannot be changed. However, mapping
between DSCP values and other properties can be changed as follows:
•DSCP to internal forwarding priority mapping - You can change the mapping between the
DSCP value and the internal forwarding priority value from the default values shown in the above
tables. This mapping is used for CoS marking and determining the internal priority when the trust
level is DSCP. Refer to Changing the DSCP to internal forwarding priority mappings on page 34.
•VLAN priority (802.1p) to hardware forwarding queue - You can change the mapping between the
802.1p value and hardware forwarding queue from the default value. Refer to Changing the VLAN
priority 802.1p to hardwareforwarding queue mappings on page 35.
QoS for Brocade stackable devices
Brocade FastIron units in a traditional stack support QoS. Units in a stack communicate the stack
topology information and other proprietary control information through the stacking links. For more
information about stacking links and traditional stack technology, refer to the FastIron Ethernet SwitchStacking Configuration Guide .
In addition to control information, the stacking links also carry user network data packets. In a traditional
stack topology, the priority of stacking-specific control packets is elevated above that of data path
packets, preventing loss of control packets, and timed retries that affect performance. This prioritization
also prevents stack topology changes that may occur if enough stack topology information packets are
lost.
Traditional stack technology reserves one QoS profile to provide a higher priority for stack topology and
control traffic.
QoS for Brocade stackable devices
QoS profile restrictions in a traditional stack
In a stacking topology, because CoS level 7 is reserved for stacking, quality profiles for qosp7 cannot
be configured. If an attempt is made to configure a profile for qosp7, the system ignores the
configuration.
NOTE
This applies only when the device is operating in stacking mode. It does not apply to stand-alone
devices.
QoS behavior for trusting Layer 2 (802.1p) in a traditional stack
By default, Layer 2 trust is enabled. Because priority 7 is reserved for stacking control packets, any
ingress data traffic with priority 7 is mapped to internal hardware queue 6. All other priorities are
mapped to their corresponding queues.
QoS behavior for trusting Layer 3 (DSCP) in a traditional stack
When the trust dscp mode is enabled, packets arriving with DSCP values 56 to 63 are mapped to
internal hardware queue 6. All other DSCP values are mapped to their corresponding internal hardware
queues.
QoS behavior on port priority and VLAN priority in a traditional stack
Port priority has a higher precedence than the 802.1p priority examination. If port priority is set to 7, all
incoming traffic is mapped to internal hardware queue 6.
QoS behavior for 802.1p marking in a traditional stack
When stacking is not enabled on a device, all priorities are mapped to their corresponding queues
without restrictions.
QoS behavior for 802.1p marking in a traditional stack
By default, 802.1p marking is not enabled in a traditional stack. Outgoing tagged traffic will not be
marked based on the hardware queue into which ingress traffic was classified. 802.1p marking can be
achieved using ACL. For configuration syntax, rules, and examples of QoS marking, refer to the "QoS
options for IP ACLs" section in the FastIron Ethernet Switch Security Configuration Guide .
QoS queues
Brocade devices support the eight QoS queues (qosp0 through qosp7) listed in the following table.
QoS queues TABLE 6
QoS priority levelQoS queue
0qosp0 (lowest priority queue)
1qosp1
2qosp2
3qosp3
4qosp4
5qosp5
6qosp6
7qosp7 (highest priority queue)
The queue names listed in the table are the default names. If desired, you can rename the queues as
shown in Renaming the queues on page 39.
Packets are classified and assigned to specific queues based on the criteria shown in the figures
described in the Determining the trust level of a packet section.
For FCX and ICX devices, ingress packets are classified into the eight priorities, which map to eight
hardware queues or traffic classes (TCs) based on the priority. Exceptions to this model are the SXFI48GPP and SX-FI-8XG interface modules and the ICX 6430 switch as explained in the following
sections.
Queues for the SX-FI48GPP interface module
The SX-FI48GPP interface module consists of two separate hardware Network Processors (NPs). The
front-end NP supports four hardware queues, and the back-end NP supports eight hardware queues.
Ingress packets are classified into eight priorities mapped into four hardware queues. In the egress,
traffic is destined to two adjacent network ports (for example, ports 1/1 and 1/2), and aggregated into
one 1-GbE port in the back-end NP. The two network ports share the same hardware queues, and
therefore they have the same buffer and descriptor limits and scheduling algorithm for transmission.
Ingress packets are classified into eight QoS priority levels at the front-end NP of the SX-FI48GPP
module. The eight priorities are mapped into four hardware queues based on the priority queue
configuration in the following table. QoS priority 7 is the highest priority, and QoS 0 is the lowest priority.
Priority queues for the SX-F148GPP TABLE 7
QoS priority levelHardware queues
(traffic classes)
00
10
21
31
42
52
63
73
QoS classification occurs in two iterations; initially in the front-end NP, followed by the back-end NP.
The back-end NP has the same classification and marking capabilities of existing FastIron SX interface
modules, but the front-end NP does not support ACL and static MAC priority. The front-end NP supports
basic QoS features, such as port priority, QoS-ToS mapping, 802.1p to priority mapping, 802.1p
override, and trust DSCP mode.
The default scheduling configuration for Weighted Round Robin (WRR), Hybrid WRR and Strict Priority
(SP), and SP mode for the eight QoS priority queues mapped to the four hardware queues is described
under Default scheduling configuration for the SX-FI48GPP module on page 36.
Queues for the SX-FI-8XG interface module
The SX-FI-8XG interface module consists of two separate hardware Network Processors (NP). The
front-end NP supports 8 hardware queues, and the back-end NP supports eight hardware queues. In
the egress, traffic is destined to four adjacent ports (for example, ports 1/1 to 1/4), and aggregated into
one 10GbE port in the back-end NP. The four network ports share the same hardware queues;
therefore, they have the same buffer and descriptor limits and scheduling algorithm for transmission.
QoS classification occurs in two iterations; initially in the front-end NP, followed by the back-end NP.
The back-end NP has the same classification and marking capabilities of existing FSX interface
modules, however, the front -end NP does not support ACL and static MAC priority. The front-end NP
supports basic QoS features, such as port priority, qos-tos mapping, 802.1p to priority mapping, 802.1p
override, and trust-dscp mode.
For the ICX 6430 switch, ingress packets are classified into eight QoS priority levels. These are
mapped internally to four hardware forwarding queues or traffic classes as shown in the following
table. QoS priority 7 is the highest priority, and QoS 0 is the lowest QoS priority (qosp) level.
QoS priority levelHardware queues
00
10
21
31
41
Priority queues for the ICX 6430 TABLE 8
(Traffic classes)
52
62
73
For the ICX 6430 switch, internal forwarding priority maps to hardware forwarding queues 0 through 3.
The mapping between the internal priority and hardware forwarding queue cannot be changed. The
following tables show the default QoS mappings that are used if the trust level for CoS or DSCP is
enabled. Mappings are the same for stand-alone and stacking systems.
Default QoS mappings for ICX 6430, columns 0 to 15 TABLE 9
DSCP value0 1234 5678 9101112121415
802.1p (CoS) value0 0000 0001 1111111
DSCP value01 2345 6789 101112121415
Internal forwarding priority0 0000 0001 1111111
Forwarding queue0 0000 0000 0000000
Default QoS mappings for ICX 6430, columns 16 to 31 TABLE 10
Mapping between DSCP value and forwarding queue cannot be changed. However, mapping between
DSCP values and other properties can be changed as follows:
•DSCP to internal forwarding priority mapping - You can change the mapping between the
DSCP value and the internal forwarding priority value from the default values shown in the above
tables. This mapping is used for CoS marking and determining the internal priority when the trust
level is DSCP. Refer to Changing the DSCP to internal forwarding priority mappings on page 34.
•VLAN priority (802.1p) to hardware forwarding queue - You can change the mapping between the
802.1p value and hardware forwarding queue from the default value. Refer to Changing the VLAN
priority 802.1p to hardwareforwarding queue mappings on page 35
User-configurable scheduler profile
The user-configurable scheduler profile is a template that defines either the scheduling mechanism or
scheduling profile (weights assigned to the queues) or both for the egress queues. A configured userconfigurable scheduler profile for egress queues can be applied to any hardware device. The default
QoS is applicable to the entire system. If the scheduler profile is configured using the qos mech strict
command, all devices in the system will be configured with the strict priority. The user-configurable
scheduler profile is applicable only to the specific devices, leaving the remaining devices running default
QoS. On any device, the user-configurable scheduler profile has high priority over the default QoS. On
any device, user-configurable scheduler profile has high priority over the default QoS. The userconfigurable scheduler profile should be in line with default QoS commands in both stacking and standalone systems.
On Brocade ICX 7750 devices, scheduler profiles are applied at the port, rather than at the device
(port region), level. See the description of the scheduler-profile command for more information.
User-configurable scheduler profile configuration
Configuring a user-configurable scheduler profile involves, selecting a proper mechanism and
appropriate weights for the traffic classes (TCs) corresponding to that mechanism. It is highly
recommended that you let the system use the default scheduling mechanism unless user knows what
parameters you intend to modify and for what reasons.
There are two ways of creating a user-configurable scheduler profile. The scheduler-profile can be
created either by specifying a mechanism (WRR, Strict, or Mixed) or by specifying weights.
The user-configurable scheduler profile can be created by specifying a mechanism. There are three
available mechanisms:
•Strict Priority (SP)
•Weighted Round Robin (WRR)
•Mixed (combination of SP and WRR)
Following is the command format for creating a profile while specifying a mechanism.
The user_profile_name variable is the name of the profile you are creating.
Profile qosp0 through qosp7 are the default queue names.
The w0 through w7 variables are the assigned weights.
If you create a profile specifying only the weights (qosp0 through qosp7) without specifying the
mechanism, the default mechanism is used. The default mechanism for stacking systems is Mixed ,
and WRR for stand-alone systems.
If you change the profile mechanism, the weights also get changed according to the mechanism. The
weights can be modified according to the following requirements:
•If the mechanism is changed to WRR , the default system weights get assigned
•If the mechanism is changed to Mixed , the default mix weights get assigned
•If the mechanism is changed to Strict , the weights are ignored and remain untouched.
Scheduler-profile modifications take effect dynamically on an active profile. The operational defaults
for all scheduling types for stacking and stand-alone systems are listed in the Default values forscheduling type for stacking and stand-alone systems (for FCX and ICX 6450 platforms) table.
Displaying the user-configurable scheduler profile configuration
To display the specified user-configurable scheduler profile configuration, use the show scheduler profileuser_profile_name command.
The user_profile_name variable is the name of the profile you are creating.
The following tables show the default values for the scheduling type for ICX 6650 platforms.
Default values for scheduling type for ICX 6650 platformsTABLE 15
SPSP JumboWRRWRR JumboMixedMixed Jumbo
TC0SPSP381515
TC1SPSP381515
TC2SPSP381515
TC3SPSP381515
TC4SPSP381515
TC5SPSP382525
TC6SPSP78SPSP
TC7SPSP7544SPSP
ICX 6430 platforms
The following table shows the default values for scheduling type for stacking and stand-alone ICX
6430 platforms. The lowest weighted priority is for qosp0, while the highest is for qosp7.
Note that values are provided for QoS priority (QSP) levels. The weights applied to the traffic class
(TC) are the sum of the weights of the QSP levels that map to that TC. For example, QSP0 and QSP1
map to TC0. If the weight for QSP0 is 6 and the weight for QSP1 is 6, then the weight for TC0 is 12.
Refer to the Priority queues for the ICX 6430 table for QoS priority to traffic class mapping.
Default values for scheduling type for stacking systems (for ICX 6430 platforms)TABLE 16
Default values for scheduling type for stacking systems (for ICX 6430 platforms)
(Continued)
Default values for scheduling type for stand-alone systems (for ICX 6430 platforms)TABLE 17
SPSP JumboWRRWRR JumboMixedMixed Jumbo
QSP7SPSP7544SPSP
QoS priorities-to-traffic assignment
By default, all traffic is in the best-effort queue (qosp0) and is honored on tagged ports on all FastIron
switches. You can assign traffic to a higher queue based on the following:
•Incoming port (sometimes called the ingress port )
•Static MAC entry
When you change the priority, you specify a number from 0 through 7. The priority number specifies the
IEEE 802.1 equivalent to one of the eight QoS queues on Brocade devices. The numbers correspond to
the queues as shown in the QoS queues table.
Although it is possible for a packet to qualify for an adjusted QoS priority based on more than one of the
criteria, the system always gives a packet the highest priority for which it qualifies. Thus, if a packet is
entitled to the premium queue because of its IP source and destination addresses, but is entitled only to
the high queue because of its incoming port, the system places the packet in the premium queue on the
outgoing port.
Changing a port priority
To change the QoS priority of port 1/1 to the premium queue (qosp7), enter the following commands.
Use the following command to configure a MAC entry and assign the entry to a priority queue.
Syntax:[no] static-mac-address mac-addr ethernet port [ prioritynum ]
The mac-addr is the MAC address.
The prioritynum variable can be from 0 through 7 and specifies the IEEE 802.1 equivalent to one of
the eight QoS queues.
Buffer allocation and threshold for QoS queues
By default, Brocade IronWare software allocates a certain number of buffers to the outbound transport
queue for each port based on QoS priority. The buffers control the total number of packets permitted in
the outbound queue for the port. If desired, you can increase or decrease the maximum number of
outbound transmit buffers allocated to all QoS queues, or to specific QoS queues on a port or group of
ports. For more information, refer to the FastIron Ethernet Switch Platform and Layer 2 SwitchingConfiguration Guide.
NOTE
On ICX 6650 devices, you cannot increase or decrease the maximum number of outbound transmit
buffers allocated to all QoS queues, or to specific QoS queues on a port or group of ports.
802.1p priority override
You can configure a port to ignore the 802.1p priority for traffic classification for an incoming packet.
When this feature is enabled, packets will be classified as follows:
•If the packet matches an ACL that defines the priority, then ACL priority will be used.
•If the packet source or destination MAC address matches a configured static MAC address with
priority, then static MAC priority will be used.
•If the ingress port has a configured priority, then port priority will be used.
•If the other situations do not apply, the configured or default port priority (0) will be used.
Note that the original 802.1p priority in the packet will be retained. This feature does not re-mark the
802.1p value.
Configuration notes and feature limitations
•802.1p priority override is supported on physical ports and trunk ports. When applied to the primary
port of a trunk group, the configuration applies to all members of the trunk group.
•This feature is not supported together with trust dscp .
Enabling 802.1p priority override
To enable 802.1p priority override, enter the following command at the interface level of the CLI.
device(config-if-e1000-2)#priority ignore-8021p
Syntax:[no] priority ignore-8021p
Use the following command to show whether 802.1p priority override is enabled on a port.
device# show run interface ethernet 1
interface ethernet 1
priority ignore-8021p
Syntax: show run interface ethernet port
Marking
Marking is the process of changing the packet QoS information (the 802.1p and DSCP information in a
packet) for the next hop. For example, for traffic coming from a device that does not support
Differentiated Services (DiffServ), you can change the packet IP precedence value into a DSCP value
before forwarding the packet.
You can mark a packet’s Layer 2 CoS value, its Layer 3 DSCP value, or both values. The Layer 2 CoS
or DSCP value the device marks in the packet is the same value that results from mapping the packet
QoS value into a Layer 2 CoS or DSCP value.
Marking is optional and is disabled by default. In releases prior to IronWare 8.0, marking is performed
only using ACLs. For configuration syntax, rules, and examples of QoS marking, refer to "QoS options
for IP ACLs" section in the FastIron Ethernet Switch Security Configuration Guide .
DSCP and CoS global remarking
NOTE
DSCP and CoS global marking is not supported on ICX 6650.
When marking is not used, the device performs the mappings listed for scheduling the packet, but
leaves the packet QoS values unchanged when the device forwards the packet. For more information,
refer to the QoS overview on page 12. When marking is not enabled using ACLs, a rogue host that
wants preferential treatment for all its traffic can mark the DSCP field as per its requirements and send
the traffic to the device.
Prior to 08.0.00, the only way to prevent such threats was to mark all packets using ACLs. Beginning
with 08.0.00, the internal forwarding priority can be set using an ACL only for flows that require
preferential QoS treatment. For all other flows, you can remark DSCP and CoS fields globally. Traffic
marked by the ACL method always has a higher priority than the global marking.
When DSCP marking is configured on a given port, the DSCP field of any IPv4 packet received on the
port is remarked to the configured value.
When CoS marking is configured, the PCP bit value in the VLAN header is remarked to the desired
value for all tagged packets. CoS marking can be configured on a port. When configured on a port, the
PCP bit in the VLAN header for all packets that egress the port is remarked to the configured value.
Both DSCP and CoS global marking can be configured on the ports of the modules that are configured
but not physically present. When the modules are hot-swapped, the marking is automatically applied
or removed.
The DSCP and CoS remarking can be configured through the command-line interface (CLI) at the
global level and the interface level. The global DSCP and CoS marking can coexist with other security
features configured on the same port. The coexistence rules are the same as those for IPv4 ACLs.
Configuration considerations and limitations
•When an ACL is configured on a port without remarking and global DSCP remarking is enabled,
the global DSCP remarking is enabled for the permitted traffic.
•DSCP and CoS global remarking are supported on the same interface together.
•DSCP and CoS global remarking cannot coexist with MAC filters and MAC-based VLANs.
The following table summarizes the behavior when the remarking is set.
DSCP and PCP remarkingTABLE 18
DSCPRemarking setRemarking setNot set
CoSRemarking setNot setRemarking set
DSCP action Remark DSCP at the ingressRemark DSCP at the ingressN/A
PCP actionRemark PCP at the egressN/ARemark PCP at the egress
Traffic class Apply the TC equivalent to DSCP Apply the TC equivalent to
DSCP
Apply the TC equivalent to
PCP
Enabling DSCP marking
To enable DSCP remarking globally, use the ip dscp-remark command in global configuration mode.
To enable DSCP remarking on a port, use the ip dscp-remark command in interface configuration
mode.
Example: DSCP marking
The following example shows how to set the DSCP value to 3 for all IP packets:
The following example shows how to set the DSCP value to 4 of all IP packets on a specific port:
device(config)# interface ethernet1/1/1
device(config-if-e1000-1/1/1)# ip dscp-remark 4
Enabling CoS marking
To enable CoS marking globally, use the ip pcp-remark command in global configuration mode.
To enable CoS marking on a port, use the ip pcp-remark command in interface configuration mode.
Example: CoS marking
The following example shows how to set the PCP value to 3 for all VLAN tagged packets:
device(config)# ip pcp-remark 3
The following example shows how to set the PCP value to 4 of all IP packets on a specific port:
device(config)# interface ethernet1/1/1
device(config-if-e1000-1/1/1)# ip pcp-remark 4
DSCP-based QoS configuration
Brocade IronWare releases support basic DSCP-based QoS (also called Type of Service (ToS)-based
QoS) as described in this chapter. However, the FastIron family of switches does not support other
advanced DSCP-based QoS features.
Brocade IronWare releases also support marking of the DSCP value. The software can read Layer 3
Quality of Service (QoS) information in an IP packet and select a forwarding queue for the packet based
on the information. The software interprets the value in the six most significant bits of the IP packet
header 8-bit ToS field as a DSCP value, and maps that value to an internal forwarding priority.
NOTE
MAC filter and DSCP marking cannot be configured on the same port.
The internal forwarding priorities are mapped to one of the eight forwarding queues (qosp0 through
qosp7) on the Brocade device. During a forwarding cycle, the device gives more preference to the
higher-numbered queues, so that more packets are forwarded from these queues. For example, queue
qosp7 receives the highest preference, while queue qosp0, the best-effort queue, receives the lowest
preference.
Application notes for DSCP-based QoS
•DSCP-based QoS is not automatically honored for routed and switched traffic. The default is
802.1p to CoS mapping. To honor DSCP-based QoS, you must either use an ACL or enable trust
DSCP. Refer to Using ACLs to honor DSCP-based QoS on page 32.
•When DSCP marking is enabled, the device changes the contents of the inbound packet ToS field
to match the DSCP-based QoS value.
This section shows how to configure Brocade devices to honor DSCP-based QoS for routed and
switched traffic.
FCX and ICX devices
Brocade FCX, ICX 6430, ICX 6450, ICX 6610, and ICX 6650 devices support DSCP-based QoS on a
per-port basis. DSCP-based QoS is not automatically honored for switched traffic. The default is
802.1p to CoS mapping. To honor DSCP-based QoS, enter the following command at the interface
level of the CLI.
[no] trust dscp
To disable the configuration, use the no form of the command.
When trust dscp is enabled, the interface honors the Layer 3 DSCP value. By default, the interface
honors the Layer 2 CoS value.
NOTE
The trust dscp command is not supported with 802.1p priority override.
FSX Series devices
FSX devices require the use of an ACL to honor DSCP-based QoS for routed traffic in the Layer 3
image, or for switched traffic in the Layer 2 image. To enable DSCP-based QoS on these devices,
apply an ACL entry such as the following.
device(config)#access-list 101 permit ip any any dscp-cos-mapping
NOTE
Use the bridged-routed keyword in the ACL to honor DSCP for switched traffic in the Layer 3 image.
Refer to "Enabling ACL support for switched traffic in the router image" section in the FastIron EthernetSwitch Security Configuration Guide .
NOTE
The access-list 101 permit ip any any dscp-cos-mapping command is supported on the SXFI48GPP interface module. For more information on QoS queues for the SX-FI48GPP interface
module, refer to Queues for the SX-FI48GPP interface module on page 20.
Trust DSCP for the SX-FI48GPP, SX-FI-24GPP, SX-FI-24HF, SX-FI-2XG,
and SX-FI8XG modules
On the following modules, trust DSCP can be enabled on a per-port basis:
Each port on the supported modules corresponds to a front-end panel port. By default, trust VLAN
priority is enabled.
NOTE
For all ports in the other FastIron SX modules, ACL should be used to implement the trust DSCP mode.
For example, to enable trust DSCP on interface ethernet 1/48 on the SX-FI48GPP module, enter the
following command.
Syntax:[no] trust dscp
To disable the configuration, use the no form of the command.
Configuring QoS mapping configuration
You can optionally change the following QoS mappings:
•DSCP to internal forwarding priority
•VLAN priority (802.1p) to hardware forwarding queue
The mappings are globally configurable and apply to all interfaces.
Configuring QoS mapping configuration
Default DSCP to internal forwarding priority mappings
The DSCP values are described in RFCs 2474 and 2475. The following table lists the default mappings
of DSCP values to internal forwarding priority values.
Default DSCP to internal forwarding priority mappings TABLE 19
Internal forwarding priorityDSCP value
0 (lowest priority queue)0 - 7
18 - 15
216 - 23
324 - 31
432 - 39
540 - 47
648 - 55
7 (highest priority queue)56 - 63
Notice that DSCP values range from 0 through 63, whereas the internal forwarding priority values range
from 0 through 7. Any DSCP value within a given range is mapped to the same internal forwarding
priority value. For example, any DSCP value from 8 through 15 maps to priority 1.
After performing this mapping, the device maps the internal forwarding priority value to one of the
hardware forwarding queues.
Changing the DSCP to internal forwarding priority mappings
On FCX and ICX devices, you can use QoS queue 1 for priority traffic, even when sFlow is enabled on
the port. This differs from the FastIron X Series devices, which support seven priorities for user data
instead of eight when sFlow is enabled. QoS queue 1 is reserved for sFlow and not used by other
packets. Any non-sFlow packets assigned to QoS queue 1 will be directed to QoS queue 0. Note that
the ICX 6430 does not support sFlow.
The following table lists the default mappings of internal forwarding priority values to the hardware
forwarding queues for the ICX 6430.
Default mappings of internal forwarding priority values for the ICX 6430 TABLE 20
Internal forwarding priorityForwarding queues
0 (lowest priority queue)qosp0
1qosp0
2qosp1
3qosp1
4qosp1
5qosp2
6qosp2
7 (highest priority queue)qosp3
You can change the DSCP to internal forwarding mappings. You also can change the internal
forwarding priority to hardware forwarding queue mappings.
Changing the DSCP to internal forwarding priority mappings
To change the DSCP to internal forwarding priority mappings for all the DSCP ranges, enter
commands such as the following at the global CONFIG level of the CLI.
device(config)#qos-tos map dscp-priority 0 2 3 4 to 1
device(config)#qos-tos map dscp-priority 8 to 5
device(config)#qos-tos map dscp-priority 16 to 4
device(config)#qos-tos map dscp-priority 24 to 2
device(config)#qos-tos map dscp-priority 32 to 0
device(config)#qos-tos map dscp-priority 40 to 7
device(config)#qos-tos map dscp-priority 48 to 3
device(config)#qos-tos map dscp-priority 56 to 6
device(config)#qos-tos map dscp-priority 56 t
Use the following command to map priority levels to DSCP values.
This output displays mappings in the DSCP to forwarding priority portion of the QoS information display.
To read this part of the display, select the first part of the DSCP value from the d1 column and select
the second part of the DSCP value from the d2 row. For example, to read the DSCP to forwarding
priority mapping for DSCP value 24, select 2 from the d1 column and select 4 from the d2 row. The
mappings that are changed by the example qos-tos map dscp-priority command are shown in bold
type.
Changing the VLAN priority 802.1p to hardwareforwarding queue
mappings
To map a VLAN priority to a different hardware forwarding queue, enter commands such as the
following at the global CONFIG level of the CLI.
Syntax:[no] qos tagged-prioritynumqueue
The num variable can be from 0 through 7 and specifies the VLAN priority.
The queue variable specifies the hardware forwarding queue to which you are reassigning the priority.
Default scheduling configuration for the SX-FI48GPP module
Default scheduling configuration for the SX-FI48GPP module
The default scheduling configuration for Weighted Round Robin (WRR), Strict Priority (SP), and mixed
WRR and SP mode for the eight QoS priority (qosp) queues mapped to the four hardware queues is
described in the following table.
Default configuration for 8 to 4 queues for the SX-FI48GPP module TABLE 21
Hardware Queue Weighted Round Robin (WRR) modeMixed WRR and SP Strict Priority (SP) mode
3Weight 82%Strict PriorityStrict Priority
2Weight 6%Weight 40%Strict Priority
1Weight 6%Weight 30%Strict Priority
0Weight 6%Weight 30%Strict Priority
Note that the above table includes values for default, non-jumbo mode WRR. The hardware queues
are calculated using default qosp values from the Default values for scheduling type for stacking andstand-alone systems (for FCX and ICX 6450 platforms) table as follows:
The default scheduling configuration for Weighted Round Robin (WRR), Strict Priority (SP), and mixed
WRR and SP mode for the eight QoS priority (qosp) queues mapped to the four hardware queues for
an ICX 6430 is described in the following table.
Default configuration for 8 to 4 queues (stand-alone system)TABLE 22
Hardware queue Weighted Round Robin (WRR) modeMixed WRR and SP Strict Priority (SP) mode
The above table includes values for default, non-jumbo mode WRR for a stand-alone system. The
hardware queues are calculated using default qosp values from the Default values for scheduling typefor stacking and stand-alone systems (for ICX 6430 platforms) table as follows:
If any qosp value is SP, then the weight of the hardware queue is SP.
Scheduling QoS information
Scheduling is the process of mapping a packet to an internal forwarding queue based on its QoS
information, and servicing the queues according to a mechanism.
Scheduling for the SX-FI48GPP module
The SX-FI48GPP module supports scheduling at the front-end and back-end NP. If egress congestion
occurs at the front-end NP of the SX-FI48GPP module, scheduling is based on four queues instead of
eight. For more information on default configuration for 8 to 4 queue mapping, refer to the Priorityqueues for the SX-F148GPP table. If egress congestion occurs at the back-end of the SX-FI48GPP
module, then scheduling is based on eight queues. When SX- FI48GPP ports are running at a reduced
speed (100 Mbps or 10 Mbps), egress congestion usually occurs at the front-end NP.
QoS queuing methods
The following QoS queuing methods are supported in all IronWare releases for the FastIron devices:
•Weighted Round Robin (WRR) - WRR ensures that all queues are serviced during each cycle. A
WRR algorithm is used to rotate service among the eight queues on the FastIron devices. The
rotation is based on the weights you assign to each queue. This method rotates service among the
queues, forwarding a specific number of packets in one queue before moving on to the next one.
NOTE
In stacking mode, the qosp7 queue is reserved as Strict Priority (SP) under weighted queuing. Attempts
to change the qosp7 setting will be ignored.
WRR is the default queuing method and uses a default set of queue weights.
The number of packets serviced during each visit to a queue depends on the percentages you configure
for the queues. The software automatically converts the percentages you specify into weights for the
queues.
Queue cycles on the Brocade FastIron devices (except on ICX 6650) are based on bytes. These
devices service a given number of bytes (based on weight) in each queue cycle. The QoS WRR on
ICX 6650 is configured to operate in packet count mode.
•Strict Priority (SP) - SP ensures service for high-priority traffic. The software assigns the maximum
weights to each queue, to cause the queuing mechanism to serve as many packets in one queue
as possible before moving to a lower queue. This method biases the queuing mechanism to favor
the higher queues over the lower queues.
For example, strict queuing processes as many packets as possible in qosp3 before processing any
packets in qosp2, then processes as many packets as possible in qosp2 before processing any
packets in qosp1, and so on.
•Hybrid WRR and SP - This configurable queueing mechanism combines both the SP and WRR
mechanisms. The combined method enables the Brocade device to give strict priority to delaysensitive traffic such as VoIP traffic, and weighted round robin priority to other traffic types.
By default, when you select the combined SP and WRR queueing method, the Brocade device
assigns strict priority to traffic in qosp7 and qosp6, and weighted round robin priority to traffic in qosp0
through qosp5. Thus, the Brocade device schedules traffic in queue 7 and queue 6 first, based on the
strict priority queueing method. When there is no traffic in queue 7 and queue 6, the device schedules
the other queues in round-robin fashion from the highest priority queue to the lowest priority queue.
NOTE
Brocade stackable devices that are operating as members of a stack reserve queue 7 for stacking
functions. For more information, refer to QoS for Brocade stackable devices on page 19.
By default, when you specify the combined SP and WRR queuing method, the system balances the
traffic among the queues as shown in the following table. If desired, you can change the default
bandwidth values as shown in Bandwidth allocations of the hybrid WRR and SP queues on page 41.
Default bandwidth for combined SP and WRR queueing methods TABLE 23
By default, Brocade devices use the WRR method of packet prioritization. To change the method to SP,
enter the qos mechanism strict command at the global CONFIG level of the CLI.
device(config)#qos mechanism strict
To change the method back to WRR, enter the qos mechanism weighted command.
device(config)#qos mechanism weighted
To change the queuing mechanism to the combined SP and WRR method, enter the qos mechanism
mixed-sp-wrr command at the global CONFIG level of the CLI.
Each of the queues has the following configurable parameters:
•The queue name
•The minimum percentage of a port outbound bandwidth guaranteed to the queue
Renaming the queues
The default queue names are qosp7, qosp6, qosp5, qosp4, qosp3, qosp2, qosp1, and qosp0. You can
change one or more of the names if desired.
To rename queue " qosp3 " to " 92-octane ", enter the following command.
device(config)#qos name qosp3 92-octane
Syntax:qos nameold-namenew-name
The old-name variable specifies the name of the queue before the change.
The new-name variable specifies the new name of the queue. You can specify an alphanumeric string
up to 32 characters long.
Changing the minimum bandwidth percentages of the WRR queues
If you are using the weighted round robin mechanism instead of the strict priority mechanism, you can
change the weights for each queue by changing the minimum percentage of bandwidth you want each
queue to guarantee for its traffic.
NOTE
On the SX-FI48GPP interface module, the bandwidth percentages for 8 to 4 queue mapping for WRR
queues are different from other Brocade SX modules. For more information on 8 to 4 queue mapping on
the SX-FI48GPP interface module, refer to Default scheduling configuration for the SX-FI48GPP
module on page 36.
By default, the eight QoS queues on FastIron devices receive the minimum guaranteed percentages of
a port’s total bandwidth, as shown in the following table. Note that the defaults differ when jumbo frames
are enabled.
Default minimum bandwidth percentages on Brocade devices TABLE 24
QueueDefault minimum percentage of bandwidth
Without jumbo framesWith jumbo frames
qosp775%44%
qosp67%8%
qosp53%8%
qosp43%8%
qosp33%8%
qosp23%8%
qosp13%8%
qosp03%8%
When the queuing method is WRR, the software internally translates the percentages into weights.
The weight associated with each queue controls how many packets are processed for the queue at a
given stage of a cycle through the weighted round robin algorithm.
NOTE
Queue cycles on the Brocade FastIron devices are based on bytes. These devices service a given
number of bytes (based on the weight) in each queue cycle.
The bandwidth allocated to each queue is based on the relative weights of the queues. You can
change the bandwidth percentages allocated to the queues by changing the queue weights.
There is no minimum bandwidth requirement for a given queue. For example, queue qosp3 is not
required to have at least 50 percent of the bandwidth.
To change the bandwidth percentages for the queues, enter commands such as the following. Note
that this example uses the default queue names.
Each queue variable specifies the name of a queue. You can specify the queues in any order on the
command line, but you must specify each queue.
The percentage variable specifies a number for the percentage of the device outbound bandwidth that
is allocated to the queue. Brocade QoS queues require a minimum bandwidth percentage of 3 percent
for each priority. When jumbo frames are enabled, the minimum bandwidth requirement is 8 percent. If
these minimum values are not met, QoS may not be accurate.
Configuration notes for changing the bandwidth
•The total of the percentages you enter must equal 100.
•FastIron devices do not adjust the bandwidth percentages you enter.
Bandwidth allocations of the hybrid WRR and SP queues
NOTE
On the SX-FI48GPP interface module, the bandwidth percentages for 8 to 4 queue mapping for hybrid
WRR and SP queues are different from other Brocade SX modules. For more information on 8 to 4
queue mapping on the SX-FI48GPP interface module, refer to the “Default scheduling configuration for
the SX-FI48GPP module” section.
To change the default bandwidth percentages for the queues when the device is configured to use the
combined SP and WRR queuing mechanism, enter commands such as the following. Note that this
example uses the default queue names.
Each queuespecifies the name of a queue, such as 7, 6, 5, 4, 3, 2, 1, and 0. You can specify the
queues in any order on the command line, but you must specify each queue. Note that queue 7
supports Strict Priority (sp) only, queue 6 supports both SP and WRR queuing mechanisms (sp |), and
queues 0 through 5 support the WRR queuing mechanism only.
NOTE
Brocade stackable devices that are operating as members of a stack reserve queue 7 for stacking
functions.
The sp parameter configures strict priority as the queuing mechanism. Note that only queue 7 and
queue 6 support this method.
The percentage variable configures WRR as the queuing mechanism and specifies the percentage of
the device outbound bandwidth allocated to the queue. The queues require a minimum bandwidth
percentage of 3 percent for each priority. When jumbo frames are enabled, the minimum bandwidth
requirement is 8 percent. If these minimum values are not met, QoS may not be accurate.
NOTE
The percentages must add up to 100. The Brocade FastIron devices do not adjust the bandwidth
percentages you enter.
Viewing QoS settings
To display the QoS settings for all of the queues, enter the show qos-profiles command.
DSCP-based QoS configuration information (Continued)TABLE 25
FieldDescription
d1 and d2The DSCP to forwarding priority mappings that are currently in effect.
NOTE
The example shows the default mappings. If you change the mappings, the
command displays the changed mappings
Traffic class to 802.1 priority map
Traffic Class and 802.1p
Priority
The traffic class to 802.1p priority mappings that are currently in effect.
NOTE
The example shows the default mappings. If you change the mappings, the
command displays the changed mappings.
The show qos-tos command can also be used to display configuration information for 8 to 4 queue
mapping. The following example displays an 8 to 4 queue mapping configuration.
Supported Rate Limiting and Rate Shaping features on FastIron X
Series and FCX and ICX Series Switches
Lists the rate limiting and rate shaping on FastIron X Series and FCX and ICX Series Switches.
The following table lists the individual BrocadeFastIron switches and the rate limiting and rate shaping
features they support. These features are supported in the Layer 2 and Layer 3 software images,
except where explicitly noted.
FeatureICX 6430ICX 6450FCXICX 6610ICX 6650FSX 800
FSX 1600
Inbound rate limiting (port-based rate
limiting on inbound ports)
Rate limiting is packet-based on ICX 6650 in contrast with the other platforms on which it is byte-based.
Port-based fixed rate limiting is supported on inbound ports. This feature allows you to specify the
maximum number of bytes (packets in the case of ICX 6650) a given port can receive. The port drops
bytes that exceed the limit you specify. You can configure a Fixed rate limiting policy on a port inbound
direction only. Fixed rate limiting applies to all traffic on the rate limited port.
Fixed rate limiting is at line rate and occurs in hardware. Refer to Rate limiting in hardware on page
46.
When you specify the maximum number of bytes, you specify it in kilobits per second (kbps). On ICX
6650, you specify the maximum number of packets. The Fixed rate limiting policy applies to one-second
intervals and allows the port to receive the number of bytes (packets in the case of ICX 6650) you
specify in the policy, but drops additional bytes (packets in the case of ICX 6650). Unused bandwidth
is not carried over from one interval to the next.
NOTE
Port based Rate Limiting affects only known-unicast traffic. Broadcast, Multicast and Unknown-unicast
(BUM) is not affected by this rate. To rate limit the BUM traffic, use BUM rate limiting as described in
chapter BUM Rate Limiting.
NOTE
Brocade recommends that you do not use Fixed rate limiting on ports that receive route control traffic
or Spanning Tree Protocol (STP) control traffic. If the port drops control packets due to the Fixed rate
limiting policy, routing or STP can be disrupted.
Rate limiting applies to inbound ports and rate shaping applies to outbound ports.
Rate limiting in hardware
Each Brocade device supports line-rate rate limiting in hardware. The device creates entries in
Content Addressable Memory (CAM) for the rate limiting policies. The CAM entries enable the device
to perform the rate limiting in hardware instead of sending the traffic to the CPU. The device sends the
first packet in a given traffic flow to the CPU, which creates a CAM entry for the traffic flow. A CAM
entry consists of the source and destination addresses of the traffic. The device uses the CAM entry
for rate limiting all the traffic within the same flow. A rate limiting CAM entry remains in the CAM for
two minutes before aging out.
How Fixed rate limiting works
Fixed rate limiting counts the number of bytes (packets in ICX 6650) that a port receives, in one
second intervals. If the number exceeds the maximum number you specify when you configure the
rate, the port drops all further inbound packets for the duration of the one-second interval.
Once the one-second interval is complete, the port clears the counter and re-enables traffic.
The following figure shows an example of how Fixed rate limiting works. In this example, a Fixed rate
limiting policy is applied to a port to limit the inbound traffic to 500000 bits (62500 bytes) (packets in
ICX 6650) a second. During the first two one-second intervals, the port receives less than 500000 bits
(packets in ICX 6650) in each interval. However, the port receives more than 500000 bits (packets in
ICX 6650) during the third and fourth one-second intervals, and consequently drops the excess traffic.
FIGURE 5 Fixed rate limiting
NOTE
The software counts the bytes (packets in ICX 6650) by polling statistics counters for the port every 100
milliseconds, which provides 10 readings each second. Due to the polling interval, the Fixed Rate
Limiting policy has an accuracy of within 10% of the port's line rate. It is therefore possible for the policy
to sometimes allow more traffic than the limit you specify, but the extra traffic is never more than 10% of
the port's line rate.
Configuration notes for rate limiting
•Rate limiting is available only on inbound ports.
•Port based Rate limiting is not supported on the SX-FI62XG and SX-FI42XG modules of the
FastIron X Series devices.
•FastIron X Series devices do not support fixed rate limiting on tagged ports in the base Layer 3 and
full Layer 3 images.
•The rate limit on IPv6 hardware takes several seconds to take effect at higher configured rate limit
values. For example, if the configured rate limit is 750 Mbps (1500000 packets/second, in ICX
6650), line-rate limiting could take up to 43 seconds to take effect.
•You can enable rate limiting on Static LAG only. You cannot enable rate limiting on other types of
LAG.
•You can configure rate limiting on individual ports of the LAG. You cannot configure rate limiting on
To configure rate limiting on a port, enter commands such as the following.
device(config)#interface ethernet 24
device(config-if-e1000-24)#rate input fixed 500
These commands configure a fixed rate limiting policy that allows port 24 to receive a maximum of 500
kbits (500 packets in ICX 6650) per second. If the port receives additional bytes (packets in ICX 6650)
during a given one-second interval, the port drops all inbound packets on the port until the next onesecond interval starts.
Syntax:[no] rate-limit input fixedaverage-rate
For FastIron devices, the average-rate parameter specifies the maximum number of kilobits per
second (kbps) (packets per second (pkts/s) in ICX 6650) the port can receive. The minimum rate that
can be configured is 64 kpbs (125 pkts/s in ICX 6650).
The optional burst parameter specifies the burst size in kilobits.
By default, the least burst size is set to accommodate five jumbo frames. The upper limit depends on
the burstiness of traffic in a deployment scenario and should be user configured.
NOTE
When traffic reaches the rate limiting threshold, TD2 sends traditional pause or PFC frames,
depending on the flow-control configuration.
When PFC is enabled, TD2 transmits PFC for all priorities mapped to the lossless priority group that
reaches the XOFF limit (TD2 chip limitation).
Configuring an ACL-based rate limiting policy
IP ACL-based rate limiting of inbound traffic provides the facility to limit the rate for IP traffic that
matches the permit conditions in extended IP ACLs. This feature is available in the Layer 2 and Layer
3 code.
To configure ACL-based rate limiting on a Brocade device, you create individual traffic policies , then
reference the traffic policies in one or more ACL entries (also called clauses or statements). The traffic
policies become effective on ports to which the ACLs are bound.
For configuration procedures for ACL-based rate limiting, refer to Traffic Policies chapter.
Displaying the fixed rate limiting configuration
To display the fixed rate limiting configuration on the device, enter the show rate-limit input
command.
device#show rate-limit input
Total rate-limited interface count: 5.
Port Configured Input Rate Actual Input Rate
1/1 65000 65000
1/2 195000 195000
1/6 1950 1950
Rate Limiting and Rate Shaping on FastIron X Series and FCX and ICX Series Switches
5/2 230432 230000
5/6 234113 234000
Syntax:show rate-limit input
The command lists the ports on which fixed rate limiting is configured, and provides the information
listed in the following table for each of the ports.
CLI display of fixed rate limiting information TABLE 27
FieldDescription
Total rate-limited interface count The total number of ports that are configured for fixed rate limiting.
PortThe port number.
Configured Input RateThe maximum rate requested for inbound traffic. The rate is measured in kilobits
per second (kbps).
Actual Input RateThe actual maximum rate provided by the hardware. The rate is measured in
bps.
To display the fixed rate limiting configuration on the ICX 6650 device, enter the show rate-limit input
command.
The command lists the ports on which fixed rate limiting is configured, and provides the information
listed in the following table for each of the ports.
CLI display of fixed rate limiting information TABLE 28
FieldDescription
Total rate-limited interface count The total number of ports that are configured for fixed rate limiting.
PortThe port number.
Configured Input RateThe maximum rate requested for inbound traffic. The rate is measured in packets
per second (pkts/s).
Actual Input RateThe actual maximum rate provided by the hardware. The rate is measured in
Outbound Rate Shaping is a port- level feature that is used to shape the rate and control the
bandwidth of outbound traffic on a port. This feature smooths out excess and bursty traffic to the
configured maximum limit before it is sent out on a port. Packets are stored in available buffers and
then forwarded at a rate no greater than the configured limit. This process provides for better control
over the inbound traffic of neighboring devices.
The device has one global rate shaper for a port and one rate shaper for each port priority queue.
Rate shaping is done on a single-token basis, where each token is defined to be 1 byte (1 packet for
ICX 6650).
Configuration notes for rate shaping
The following rules apply when configuring outbound rate shapers:
•Outbound rate shapers can be configured only on physical ports, not on virtual or loopback ports.
•When outbound rate shaping is enabled on a port on an IPv4 device, the port QoS queuing
method (qos mechanism ) will be strict mode. This applies to IPv4 devices only. On IPv6 devices,
the QoS mechanism is whatever method is configured on the port, even when outbound rate
shaping is enabled.
•You can configure a rate shaper for a port and for the individual priority queues of that port.
However, if a port rate shaper is configured, that value overrides the rate shaper value of a priority
queue if the priority queue rate shaper is greater than the rate shaper for the port. .
•You can configure rate shaping on individual ports of the LAG. You cannot configure rate shaping
on the LAG itself.
•You can enable rate shaping on the individual ports for static and dynamic LAG. You cannot
enable rate shaping on other types of LAG (for example, keep-alive).
•For configuring rate shaping on ICX7750 devices, you must reset the default switching
methodology from cut-through to store-and-forward mode. To change the default setting, use
store-and-forward command.
•For configuring rate shaping on dynamic LAG for ICX 7750 devices, be sure to configure the
queues where LACP packets are not forwarded. If you configure rate shaping on dynamic link
aggregation group (LAG) ports (either on the port or on the queue), it can drop LACP packets and
cause a dynamic LAG failure
For more information on LAG configuration, refer to the FastIron Ethernet Switch Layer 3 RoutingConfiguration Guide.
The configured rate shaper values are rounded up to the nearest multiples of minimum values
supported on the platform. The following table shows the minimum and maximum values for output
rate shaping on various devices. Values are in Kbps for all the platforms except those for ICX 6650
devices, which are in pkts/s.
This feature is supported on individual ports of a LAG group.
To configure the maximum rate at which outbound traffic is sent out on a LAG port, enter the following
on each LAG port where outbound traffic will be shaped.
Limiting Broadcast, Multicast, and Unknown Unicast Traffic
● Supported Limiting Broadcast, Multicast, and Unknown Unicast Traffic Features..........53
● Configuration notes and feature limitations.....................................................................53
● Command syntax for packet-based limiting ................................................................... 54
● Command syntax for byte-based limiting........................................................................ 56
● Viewing broadcast, multicast, and unknown unicast limits..............................................57
Supported Limiting Broadcast, Multicast, and Unknown Unicast
Traffic Features
Lists supported Limiting Broadcast, Multicast, and Unknown Unicast Traffic features supported on
FastIron devices.
The following table lists the individual BrocadeFastIron switches and the rate limiting and rate shaping
features they support. These features are supported in the Layer 2 and Layer 3 software images,
except where explicitly noted.
FeatureICX 6430ICX 6450FCXICX 6610ICX 6650FSX 800
FSX 1600
Byte-based broadcast, multicast, and
unknown-unicast limits
Packet-based broadcast, multicast, and
unknown-unicast limits
08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
Configuration notes and feature limitations
Brocade devices can forward all flooded traffic at wire speed within a VLAN. However, some third-party
networking devices cannot handle high rates of broadcast, multicast, or unknown-unicast traffic. If high
rates of traffic are being received by the Brocade device on a given port of that VLAN, you can limit the
number of broadcast, multicast, or unknown-unicast packets or bytes received each second on that
port. This can help to control the number of such packets or bytes that are flooded on the VLAN to other
devices.
The following describes feature differences on FastIron devices:
•FastIron X Series devices with generation 3 line cards
‐The control traffic is affected when broadcast, multicast and unknown unicast rate limit is
applied on an interface on FastIron X Series devices with generation 3 line cards (SXFI8XG, SX-FI-2XG, SX-FI-24HF, SX-FI- 24GPP, SX-FI-48GPP).
•FastIron X Series devices, except for the SX-FI48GPP interface module for all generation 2
‐Unknown unicast limiting is independent of broadcast and multicast limiting. To enable
multicast limiting, enable it after enabling broadcast limiting. Multicast limiting uses the
limit defined in broadcast limiting. You cannot set a separate limit for multicast limiting.
‐FastIron X Series devices support packet-based and byte-based limiting per port, as
well as simultaneously on the same port. For example, you can configure the broadcast
limit in packet-based mode and the unknown unicast limit in the byte-based mode on the
same port.
‐On FastIron X Series devices, when you configure unknown-unicast limiting, the rate
applies to all ports in the port range for which unknown unicast is enabled. Also, when
you enable multicast limiting, it is enabled on all the ports in the port range for which
broadcast limiting is enabled. A 1-Gbps port range consists of 12 ports.
•SX-FI48GPP interface module for all generation 3 line cards
‐To enable multicast or unknown-unicast limiting, enable it after enabling broadcast
limiting. Multicast and unknown-unicast limiting use the limit defined in broadcast limiting.
You cannot set a separate limit for unknown-unicast limiting and multicast limiting.
‐The SX-FI48GPP module supports packet-based limiting only. It does not support byte-
based limiting.
‐Each port on the SX-FI48GPP module can be configured individually.
•Brocade FCX Series , and ICX 6430 devices
‐To enable unknown-unicast limiting or multicast limiting, enable it after enabling
broadcast limiting. Unknown-unicast limiting and multicast limiting use the limit defined in
broadcast limiting. You cannot set a separate limit for unknown-unicast limiting and
multicast limiting.
‐Brocade FCX Series, and ICX 6430 devices support packet-based limiting only.
•Brocade ICX 6610 and ICX 6450 devices support byte-based limiting only.
•Brocade ICX 6650 devices support packet-based limiting only. Limits set on such flooded traffic
are also in terms of packets per second.
•Brocade ICX 7750 devices support both byte-based and packet-based rate-limiting.
Command syntax for packet-based limiting
On FastIron X-Series devices
To enable broadcast limiting on a group of ports by counting the number of packets received, enter
commands such as the following.
device(config)# interface ethernet 1 to 8
device(config-mif-e1000-1-8)# broadcast limit 65536
These commands configure packet-based broadcast limiting on ports 1 - 8. On each port, the
maximum number of broadcast packets per second cannot exceed 65,536 packets per second.
To include multicasts in the 65536 packets per second limit on each of the ports, enter the multicastlimit command after enabling broadcast limiting.
device(config-mif-e1000-1-8)# multicast limit
To enable unknown unicast limiting by counting the number of packets received, enter commands
such as the following.
On Brocade FCX Series, ICX 6430 , and ICX 6650 devices
device(config-if-e1000-1)# unknown-unicast limit 65536
The combined number of inbound Unknown Unicast packets permitted
for ports 1 to 12 is now set to 65536
device(config-if-e1000-1)#
NOTE
On the SX-FI48GPP module, multicast and unknown-unicast limiting use the value defined in broadcast
limiting. You cannot set a separate limit for unknown-unicast limiting and multicast limiting.
Syntax: [no] broadcast limit num
Syntax: [no] multicast limit
Syntax: [no] unknown-unicast num
The num variable specifies the maximum number of packets per second. It can be any number that is a
multiple of 8192, up to a maximum value of 2147418112. If you enter the multicast limit or unknown-unicast limit command, multicast packets or unknown-unicast limit are included in the corresponding
limit. If you specify 0, limiting is disabled. If you specify a number that is not a multiple of 8192, the
software rounds the number to the next multiple of 8192. Limiting is disabled by default.
On Brocade FCX Series, ICX 6430 , and ICX 6650 devices
To enable broadcast limiting on a group of ports by counting the number of packets received, enter
commands such as the following.
To include multicasts limiting, enter the multicast limit command after enabling broadcast limiting.
device(config-mif-e1000-1-8)# multicast limit
Syntax: [no] broadcast limit num
Syntax: [no] multicast limit
Syntax: [no] unknown-unicast limit
The num variable specifies the maximum number of packets per second. It can be any number that is a
multiple of 65536, up to a maximum value of 2147418112. If you enter the multicast limit command,
multicast packets are included in the corresponding limit. If you specify 0, limiting is disabled. If you
specify a number that is not a multiple of 65536, the software rounds the number to the next multiple of
65536. Limiting is disabled by default.
On Brocade ICX 6610 and ICX 6450 devices
To enable broadcast limiting on a group of ports by counting the number of bytes received, enter
commands such as the following.
To include multicasts limiting, enter the multicast limit command after enabling broadcast limiting.
device(config-mif-e1000-1-8)# multicast limit
Syntax: [no] broadcast limit num
Syntax: [no] multicast limit
Syntax: [no] unknown-unicast limit
The num variable specifies the maximum number of Kilo bytes per second. It can be any number that
is a multiple of 8192, up to a maximum value of 2147418112. If you enter the multicast limit or
unknown-unicast limit command, multicast or unknown-unicast packets are included in the
corresponding limit. If you specify 0, limiting is disabled. If you specify a number that is not a multiple
of 8192, the software rounds the number to the next multiple of 8192. Limiting is disabled by default.
Command syntax for byte-based limiting
NOTE
Byte-based limiting is supported only on FSX devices with SXR 800 and SXR 1600 generation 2 line
cards. Byte-based limiting is not supported on the Brocade FCX Series, ICX 6610, ICX 6450, ICX
6430 devices and the SX-FI8XG, SX-FI-2XG, SX-FI-24HF, SX-FI-24GPP, and SX-FI-48GPP modules.
Byte-based limiting provides the ability to rate limit traffic based on byte count. When the byte mode is
enabled, packets will be received on a port as long as the number of bytes received per second is less
than the corresponding limit. Once the limit is reached, further packets will be dropped.
To enable broadcast limiting on a group of ports by counting the number of bytes received, enter
commands such as the following.
These commands configure byte-based broadcast limiting on ports 9 and 10. On each port, the total
number of bytes received from broadcast packets cannot exceed 131,072 per second.
To include multicasts in the 131072 bytes per second limit on each of the ports, enter the multicastlimit command after enabling broadcast limiting.
device(config-mif-e1000-1-8)# multicast limit
To enable unknown unicast limiting, enter commands such as the following.
device(config-if-e1000-13)# unknown-unicast limit 65536 bytes
The combined number of bytes of inbound Unknown Unicast packets
permitted for ports 13 to 24 is now set to 65536
device(config-if-e1000-13)#
Viewing broadcast, multicast, and unknown unicast limits
Syntax:[no] unknown-unicast limitnumbytes
The num variable can be any number that is a multiple of 65536, up to a maximum value of
2147418112. If you enter the multicast limit command, multicast packets are included in the limit you
specify. If you specify 0, limiting is disabled. If you specify a number that is not a multiple of 65536, the
software rounds the number to the next multiple of 65536. Limiting is disabled by default. The
unknown-unicast limitnumbytes command is supported on FSX devices.
Viewing broadcast, multicast, and unknown unicast limits
You can use the show run interface command to display the broadcast, multicast, and unknownunicast limits configured on the device.
You can use the following commands, in addition to the show run interface command, to display the
broadcast, multicast, and unknown-unicast limits configured on the device:
•show rate-limit unknown-unicast
•show rate-limit broadcast
NOTE
The show rate-limit unknown-unicast command is supported only on FSX and the ICX 7750 devices.
Use the show run interface command to view the broadcast, multicast, and unknown-unicast limit
configured on each port.
● CPU rate-limiting............................................................................................................. 75
Supported Traffic Policies
Lists Traffic Policies supported on FastIron devices.
The following table lists the individual BrocadeFastIron switches and the traffic policy features they
support. These features are supported in the Layer 2 and Layer 3 software images, except where
explicitly noted.
CPU rate limiting08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
ICX 7750
Traffic policies overview
This chapter describes how traffic policies are implemented and configured on the FastIron devices.
Traffic policies are rules that define rate limits on packets permitted by ACLs. As traffic policies apply
rate limits on specific interfaces using ACLs, this method is also called ACL-based rate limiting. The
process for applying a traffic policy to an interface involves:
1.Creating a traffic policy
2.Adding a reference to the traffic policy in an ACL entry
3.Binding the ACL associated with this ACL entry to an interface
2
Statistics are supported in bytes only; there is no packet count.
Configuration notes and feature limitations for traffic policies
Brocade devices use traffic policies for the following reasons:
•To rate limit inbound traffic
•To count the packets and bytes per packet to which ACL permit or deny clauses are applied
Traffic policies consist of policy names and policy definitions:
•Traffic policy name - A string of up to eight alphanumeric characters that identifies individual traffic
policy definitions.
•Traffic policy definition (TPD) - The command filter associated with a traffic policy name. A TPD
can define any one of the following:
‐Rate limiting policy
‐ACL counting policy
‐Combined rate limiting and ACL counting policy (not applicable on ICX 6650)
The maximum number of supported active TPDs is a system-wide parameter and depends on the
device you are configuring. The total number of active TPDs cannot exceed the system maximum.
Refer to Maximum number of traffic policies supported on a device on page 63.
When you apply a traffic policy to an interface, you do so by adding a reference to the traffic policy in
an ACL entry, instead of applying the individual traffic policy to the interface. The traffic policy
becomes an active traffic policy or active TPD when you bind its associated ACL to an interface.
To configure traffic policies for ACL-based rate limiting, refer to Configuring ACL-based fixed rate
limiting on page 65 and ACL-based adaptive rate limiting configuration on page 66.
To configure traffic policies for ACL counting, refer to Enabling ACL statistics on page 70.
Configuration notes and feature limitations for traffic policies
Note the following when configuring traffic policies:
•Traffic policies applies to IP ACLs only.
•Traffic policies are supported on FastIron X Series devices, but not on the 10 Gbps Ethernet
interfaces of the SX-FI62XG and SX-FI42XG modules.
•The maximum number of supported active TPDs is a system-wide parameter and depends on the
device you are configuring. The total number of active TPDs cannot exceed the system maximum.
Refer to Maximum number of traffic policies supported on a device on page 63.
•You can reference the same traffic policy in more than one ACL entry within an ACL. For
example, two or more ACL statements in ACL 101 can reference a TPD named TPD1.
•You can reference the same traffic policy in more than one ACL. For example, ACLs 101 and 102
could both reference a TPD named TPD1.
•Rate limits and ACL counting are applied at the traffic policy level, and are cumulative across
ACLs and ACL entries on which they are applied. However, they are not cumulative across port
regions.
•For all types of rate limiting on Brocade ICX 6650 (ACL-based; Port-based; and Broadcast,
unknown Unicast, and Multicast rate limiting) the minimum value is 125 packets and can be
increased in steps of 125 packets.
•To modify or delete an active traffic policy, you must first unbind the ACL that references the
traffic policy.
•When you define a TPD (when you enter the CLI command traffic-policy ), explicit marking of
CoS parameters, such as traffic class and 802.1p priority, are not available on the device. In the
case of a TPD defining rate limiting, the device re-marks CoS parameters based on the DSCP
value in the packet header and the determined conformance level of the rate limited traffic, as
shown in the following table.
Maximum number of traffic policies supported on a device
CoS parameters for packets that use rate limiting traffic policiesTABLE 30
Packet conformance levelPacket DSCP valueTraffic class and 802.1p priority
0 (Green)
or
1 (Yellow)
2 (Red)N/A0 (lowest priority queue)
0 - 70 (lowest priority queue)
8 - 151
16 - 232
24 - 313
32 - 394
40 - 475
48 - 556
56 - 637 (highest priority queue)
•When you define a TPD, reference the TPD in an ACL entry, and then apply the ACL to a VE in the
Layer 3 router code, the rate limit policy is accumulative for all of the ports in the port region. If the
VE or VLAN contains ports that are in different port regions, the rate limit policy is applied per port
region.
For example, TPD1 has a rate limit policy of 600M and is referenced in ACL 101. ACL 101 is applied to
VE 1, which contains ports e 1/11 to e 1/14. Because ports e 1/11 and 1/12 are in a different port region
than e 1/13 and 1/14, the rate limit policy will be 600M for ports e 1/11 and 1/12, and 600M for ports e
1/13 and 1/14.
Maximum number of traffic policies supported on a device
The maximum number of supported active traffic policies is a system-wide parameter and depends on
the device you are configuring, as follows:
•By default, up to 1024 active traffic policies are supported on Layer 2 switches. This value is fixed
on Layer 2 switches and cannot be modified.
•For FastIron devices other than the FCX, the number of active traffic policies supported on Layer 3
switches varies depending on the configuration and the available system memory. The default
value and also the maximum number of traffic policies supported on Layer 3 switches is 50.
•On FCX devices, up to 1024 active traffic policies are supported on Layer 3 switches. This is the
default value as well as the maximum value.
•The maximum number of active TPDs (traffic policy definitions) supported by Brocade ICX 6650 is
896.
NOTE
On FCX devices, by default 992 of the maximum of 1024 active traffic policies are applied. The other 32
are reserved and the show traffic command returns zero references/bindings beyond the 992 traffic
policies.The show default values command displays the maximum number of traffic conditioners that
Setting the maximum number of traffic policies supported on a Layer 3 device
can be applied, in the hw-traffic-conditioner section of the results. The configurable tables and their
defaults and maximum values can be obtained using the show default command.
Setting the maximum number of traffic policies supported on a Layer 3
device
NOTE
This configuration is supported on FastIron devices with the exception of the FCX and ICX 6650
platforms. Setting the system-max for traffic policies is not required on FCX platforms as the default
number of traffic policies is also the maximum number.
If desired, you can adjust the maximum number of active traffic policies that a Layer 3 device will
support. To do so, enter commands such as the following at the global CONFIG level of the CLI.
You must save the configuration and reload the software to place the change into effect.
Syntax:[no] system-max hw-traffic-conditioner num
The num variable is a value from 0 through n , where 0 disables hardware resources for traffic policies,
and n is a number up to 50. The maximum number you can configure depends on the configuration
and available memory on your device. If the configuration you enter causes the device to exceed the
available memory, the device will reject the configuration and display a warning message on the
console.
NOTE
Brocade does not recommend setting the system maximum for traffic policies to 0 (zero), because this
renders traffic policies ineffective.
ACL-based rate limiting using traffic policies
ACL-based rate limiting provides the facility to limit the rate for IP traffic that matches the permit
conditions in extended IP ACLs. This feature is available in the Layer 2 and Layer 3 code.
To configure ACL-based rate limiting, you create individual traffic policies , and then reference the
traffic policies in one or more ACL entries (also called clauses or statements). The traffic policies
become effective on ports to which the ACLs are bound.
When you configure a traffic policy for rate limiting, the device automatically enables rate limit
counting , similar to the two-rate three-color marker (trTCM) mechanism described in RFC 2698 for
adaptive rate limiting, and the single-rate three-color marker (srTCM) mechanism described in RFC
2697 for fixed rate limiting. This feature counts the number of bytes and trTCM or srTCM conformance
level per packet to which rate limiting traffic policies are applied. Refer to ACL statistics and rate limit
Support for fixed rate limiting and adaptive rate limiting
You can configure ACL-based rate limiting on the following interface types:
•Physical Ethernet interfaces
•Virtual interfaces
•Trunk ports
•Specific VLAN members on a port (refer to "Applying an IPv4 ACL to specific VLAN members on a
port (Layer 2 devices only)" section in the FastIron Ethernet Switch Security Configuration Guide ).
•A subset of ports on a virtual interface (refer to "Applying an IPv4 ACL to a subset of ports on a
virtual interface (Layer 3 devices only)" section in the FastIron Ethernet Switch SecurityConfiguration Guide ).
Support for fixed rate limiting and adaptive rate limiting
FastIron devices support the following types of ACL-based rate limiting:
•Fixed rate limiting - Enforces a strict bandwidth limit. The device forwards traffic that is within the
limit but either drops all traffic that exceeds the limit, or forwards all traffic that exceeds the limit at
the lowest priority level, according to the action specified in the traffic policy.
•Adaptive rate limiting - Enforces a flexible bandwidth limit that allows for bursts above the limit.
You can configure adaptive rate limiting to forward traffic, modify the IP precedence of and forward
traffic, or drop traffic based on whether the traffic is within the limit or exceeds the limit.
Configuring ACL-based fixed rate limiting
Use the procedures in this section to configure ACL-based fixed rate limiting. Before configuring this
feature, see what to consider in Configuration notes and feature limitations for traffic policies on page
62.
Fixed rate limiting enforces a strict bandwidth limit. The port forwards traffic that is within the limit. If the
port receives more than the specified number of fragments in a one-second interval, the device either
drops or forwards subsequent fragments in hardware, depending on the action you specify.
To implement the ACL-based fixed rate limiting feature, first create a traffic policy, and then reference
the policy in an extended ACL statement. Lastly, bind the ACL to an interface. Complete the following
steps.
1.Create a traffic policy. Enter a command such as the following.
device(config)#traffic-policy TPD1 rate-limit fixed 100 exceed-action drop
2.Create an extended ACL entry or modify an existing extended ACL entry that references the traffic
policy. Enter a command such as the following.
device(config)#access-list 101 permit ip host 10.10.12.2 any traffic-policy TPD1
3.Bind the ACL to an interface. Enter commands such as the following.
device(config)#interface ethernet 1/1/5
device(config-if-e5)#ip access-group 101 in
device(config-if-e5)#exit
The previous commands configure a fixed rate limiting policy that allows port 1/1/5 to receive a
maximum traffic rate of 100 kbps (100 pkts/s for ICX 6650). If the port receives additional bits
during a given one-second interval, the port drops the additional inbound packets that are received
within that one-second interval.
For brevity, some parameters were omitted from the access-list syntax.
The software allows you to add a reference to a non-existent TPD in an ACL statement and to
bind that ACL to an interface. The software does not issue a warning or error message for nonexistent TPDs.
Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a
traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the
associated ACL.
The traffic-policyTPDname parameter is the name of the traffic policy definition. This value can
be eight or fewer alphanumeric characters.
The rate-limit fixed cirvalue parameter specifies that the traffic policy will enforce a strict
bandwidth. The cirvalue variable is the committed information rate in kbps. This value can be from
64 through 1,000,000 Kbps.
NOTE
For ICX 6650, the cirvalue variable is the committed information rate in packets per second. This
value can be from 125 through15,000,000 packets per second.
The exceed-actionaction parameter specifies the action to be taken when packets exceed the
configured committed information rate (CIR) value. Refer to Specifying the action to be taken for
packets that are over the limit on page 69.
The remark-cos sets 802.1p priority of the dropped packet to 0. If the option is specified, then the
COS/PCP field value set to 0 for the low priority traffic for any packet exceeding the rate-limit set
by the traffic policy. If the option is not used, there is no change in the existing behavior.
The count parameter is optional and enables ACL counting. Refer to ACL statistics and rate limit
counting on page 70.
ACL-based adaptive rate limiting configuration
Adaptive rate limiting enforces a flexible bandwidth limit. The port forwards traffic that is within the
limit. If the port receives more than the specified number of fragments in a one-second interval, the
device either drops or forwards subsequent fragments in hardware, depending on the exceed action
you specify.
Use the procedures in this section to configure ACL-based adaptive rate limiting. Before configuring
this feature, see what to consider in Configuration notes and feature limitations for traffic policies on
page 62.
The following table lists the configurable parameters for ACL-based adaptive rate limiting.
ACL based adaptive rate limiting parameters TABLE 31
The guaranteed kilobit (packets per second in ICX 6650) rate of inbound traffic that is
allowed on a port.
53-1003093-03
ACL based adaptive rate limiting parameters (Continued)TABLE 31
ParameterDefinition
Configuring ACL-based adaptive rate limiting
Committed Burst Size
(CBS)
Peak Information Rate
(PIR)
Peak Burst Size (PBS) The number of bytes per second (packets per second in ICX 6650) allowed in a burst
The number of bytes per second (packets per second in ICX 6650) allowed in a burst
before some packets will exceed the committed information rate. Larger bursts are more
likely to exceed the rate limit. The CBS must be a value greater than zero (0). Brocade
recommends that this value be equal to or greater than the size of the largest possible
IP packet in a stream.
The maximum kilobit (packets per second in ICX 6650) rate for inbound traffic on a port.
The PIR must be equal to or greater than the CIR.
before all packets will exceed the peak information rate. The PBS must be a value
greater than zero (0). Brocade recommends that this value be equal to or greater than
the size of the largest possible IP packet in the stream.
If a port receives more than the configured bit or byte (packets per second in ICX 6650) rate in a onesecond interval, the port will either drop or forward subsequent data in hardware, depending on the
action you specify.
Configuring ACL-based adaptive rate limiting
To implement the ACL-based adaptive rate limiting feature, first create a traffic policy, and then
reference the policy in an extended ACL statement. Lastly, bind the ACL to an interface. Complete the
following steps.
1.Create a traffic policy. Enter a command such as the following.
device(config)#traffic-policy TPDAfour rate-limit adaptive cir 10000 cbs 1600 pir
20000 pbs 4000 exceed-action drop
2.Create a new extended ACL entry or modify an existing extended ACL entry that references the
traffic policy. Enter a command such as the following.
device(config)#access-list 104 permit ip host 10.10.12.2 any traffic-policy
TPDAfour
3.Bind the ACL to an interface. Enter commands such as the following.
device(config)#interface ethernet 7
device(config-if-e7)#ip access-group 104 in
device(config-if-e7)#exit
The previous commands configure an adaptive rate limiting policy that enforces a guaranteed
committed rate of 10000 kbps on port e7 and allows bursts of up to 1600 bytes. It also enforces a
peak rate of 20000 kbps and allows bursts of 4000 bytes above the PIR limit. If the port receives
additional bits during a given one-second interval, the port drops all packets on the port until the
next one-second interval starts.
NOTE
On ICX 6650, rate-limiting is packet-based.
Syntax: [no] traffic-policy TPDname rate-limit adaptive cir cirvalue cbs cbsvalue pir pirvalue
pbs pbsvalue exceed-action action [ count ]
Inspecting the 802.1p bit in the ACL for adaptive rate limiting
NOTE
For brevity, some parameters were omitted from the access-list syntax.
The software allows you to add a reference to a non-existent TPD in an ACL statement and to
bind that ACL to an interface. The software does not issue a warning or error message for nonexistent TPDs.
Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a
traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the
associated ACL.
The traffic-policyTPDname parameter is the name of the traffic policy definition. This value can
be eight or fewer alphanumeric characters.
The rate-limit adaptive circirvalue specifies that the policy will enforce a flexible bandwidth limit
that allows for bursts above the limit. The cirvalue variable is the committed information rate in
kbps on all the other supported platform except on ICX 6650 where it is packets/second. Refer to
the ACL based adaptive rate limiting parameters table.
The cbscbsvalue parameter is the committed burst size in bytes on all supported platforms
except on ICX 6650 where it is in packets.
The pirpirvalue parameter is the peak information rate in kbps on all supported platforms except
on ICX 6650 where it is packets/second.
The pbspbsvalue parameter is the peak burst size in bytes on all supported platforms except on
ICX 6650 where it is in packets.
Theexceed-actionaction parameter specifies the action to be taken when packets exceed the
configured values. Refer to Specifying the action to be taken for packets that are over the limit on
page 69.
The count parameter is optional and enables ACL counting. Refer to ACL statistics and rate limit
counting on page 70.
Inspecting the 802.1p bit in the ACL for adaptive rate limiting
You can configure the Brocade device to rate limit traffic for a specified 802.1p priority value. To do so,
complete the following configuration steps.
1.Create an adaptive rate limiting traffic policy. Enter command such as the following:
device(config)#traffic-policy adap rate-limit adaptive cir 1000 cbs 1000 pir
2000 pbs 10000 exceed-action drop
2.Create an IPv4 extended ACL or IPv6 ACL that includes the traffic policy and 802.1p priority
matching value. Enter a command such as the following:
device(config)#access-list 136 permit ip any any 802.1p-priority matching 3
traffic-policy adap
3.Bind the ACL to an interface. Enter commands such as the following,.
device(config)#interface ethernet 7
device(config-if-e7)#ip access-group 136 in
device(config-if-e7)#exit
Use the show access-list accounting command to view accounting statistics. For more
information, refer to Viewing ACL and rate limit counters on page 71.
Specifying the action to be taken for packets that are over the limit
Specifying the action to be taken for packets that are over the limit
You can specify the action to be taken when packets exceed the configured CIR value for fixed rate
limiting, or the CIR, CBS, PIR, and PBS values for adaptive rate limiting. You can specify one of the
following actions:
•Drop packets that exceed the limit.
•Permit packets that exceed the limit and forward them at the lowest priority level.
Dropping packets that exceed the limit
The ultimate action that a device can take on a packet is to drop the packet. You can apply the drop
action on packets that exceed the rate limit in both fixed rate limiting and adaptive rate limiting traffic
policies. In fixed rate limiting policies, a packet is dropped only when the packet rate exceeds the CIR
limit. Whereas, in adaptive rate limiting policies, a packet is dropped only when the packet rate exceeds
PIR limit + PBS within one second.
This section shows some example configurations and provides the CLI syntax for configuring a port to
drop packets that exceed the configured limits for rate limiting.
The following example shows a fixed rate limiting configuration.
device(config)#traffic-policy TPD1 rate-limit fixed 10000 exceed-action drop
The command sets the fragment threshold at 10,000 packets per second. If the port receives more than
10,000 packets in a one-second interval, the device drops the excess fragments.
Syntax: [no] traffic-policy TPDname rate-limit fixed cir value exceed-action drop
The following example shows an adaptive rate limiting configuration.
device(config)#traffic-policy TPDAfour rate-limit adaptive cir 10000 cbs 1600 pir
20000 pbs 4000 exceed-action drop
The command configures an adaptive rate limiting policy that enforces a guaranteed committed rate of
10000 kbps (10000 pkts/s in ICX 6650) and allows bursts of up to 1600 bytes (1600 packets in ICX
6650). It also enforces a peak rate of 20000 kbps (20000 pkts/s in ICX 6650) and allows bursts of 4000
bytes (4000 packets in ICX 6650) above the PIR limit. If the port receives additional bits during a given
one-second interval, the port drops all packets on the port until the next one-second interval starts.
Syntax:[no] traffic-policy TPDname rate-limitadaptivecir cirvalue cbs cbsvalue pir pirvalue pbs
pbsvalue exceed-actiondrop
Permitting packets that exceed the limit
This section shows some example configurations and provides the CLI syntax for configuring a port to
permit packets that exceed the configured limit for rate limiting.
The following example shows a fixed rate limiting configuration.
The command sets the fragment threshold at 10,000 packets per second. If the port receives more than
10,000 packets in a one-second interval, the device takes the specified action. The action specified with
this command is to permit excess fragments and forward them at the lowest priority level.
The command configures an adaptive rate limiting policy that enforces a guaranteed committed rate of
10000 kbps (10000 pkts/s in ICX 6650) and allows bursts of up to 1600 bytes (1600 packets in ICX
6650). It also enforces a peak rate of 20000 kbps (20000 pkts/s in ICX 6650) and allows bursts of
4000 bytes (4000 packets in ICX 6650) above the PIR limit. If the port receives additional bits during a
given one-second interval, the port permits all packets on the port and forwards the packets at the
lowest priority level.
Syntax:[no] traffic-policy TPDname rate-limitadaptivecir cirvalue cbs cbsvalue pir pirvalue pbs
pbsvalue exceed-actionpermit-at-low-pri
ACL statistics and rate limit counting
ACL statistics , also called ACL counting , enables the Brocade device to count the number of packets
and the number of bytes per packet to which ACL filters are applied.
Rate limit counting counts the number of bytes and the conformance level per packet to which rate
limiting traffic policies are applied. The device uses the counting method similar to the two-rate threecolor marker (trTCM) mechanism described in RFC 2698 for adaptive rate limiting, and the single-rate
three-color marker (srTCM) mechanism described in RFC 2697 for fixed rate limiting. Rate limit
counting is automatically enabled when a traffic policy is enforced (active). You can view these
counters using the show commands listed in Viewing traffic policies on page 73.
Enabling ACL statistics
NOTE
ACL statistics and ACL counting are used interchangeably throughout this chapter and mean the
same thing.
Use the procedures in this section to configure ACL statistics. Before configuring ACL statistics, see
what to consider in Configuration notes and feature limitations for traffic policies on page 62.
To enable ACL statistics on a device, first create a traffic policy , and then reference the traffic policy in
an extended ACL entry. Lastly, bind the ACL to an interface. The ACL counting policy becomes
effective on ports to which the ACLs are bound.
You also can enable ACL statistics when you create a traffic policy for rate limiting. Refer to Enabling
ACL statistics with rate limiting traffic policies on page 71.
Complete the following steps to implement the ACL statistics feature.
1.Create a traffic policy. Enter a command such as the following.
device(config)#traffic-policy TPD5 count
2.Create an extended ACL entry or modify an existing extended ACL entry that references the
traffic policy definition. Enter a command such as the following.
device(config)#access-list 101 permit ip host 10.10.12.2 any traffic-policy TPD5
3.Bind the ACL to an interface. Enter commands such as the following.
device(config)#interface ethernet 4
device(config-if-e4)#ip access-group 101 in
device(config-if-e4)#exit
The previous commands configure an ACL counting policy and apply it to port e4. Port e4 counts
the number of packets and the number of bytes on the port that were permitted or denied by ACL
filters.
For brevity, some parameters were omitted from the access-list syntax.
The software allows you to add a reference to a non-existent TPD in an ACL statement and to bind
that ACL to an interface. The software does not issue a warning or error message for non-existent
TPDs.
Use the no form of the command to delete a traffic policy definition. Note that you cannot delete a
traffic policy definition if it is currently in use on a port. To delete a traffic policy, first unbind the
associated ACL.
The TPDname variable is the name of the traffic policy definition. This value can be eight
alphanumeric characters or fewer.
Enabling ACL statistics with rate limiting traffic policies
The configuration example in the section Enabling ACL statistics on page 70 shows how to enable ACL
counting without having to configure parameters for rate limiting. You also can enable ACL counting
while defining a rate limiting traffic policy, as illustrated in the following configuration examples.
To enable ACL counting while defining traffic policies for fixed rate limiting, enter commands such as
the following at the global CONFIG level of the CLI.
To enable ACL counting while defining traffic policies for adaptive rate limiting, enter commands such
as the following at the global CONFIG level of the CLI.
device(config)#traffic-policy TPDA4 rate-limit adaptive cir 10000 cbs 1600 pir 20000
pbs 4000 count
device(config)#traffic-policy TPDA5 rate-limit adaptive cir 10000 cbs 1600 pir 20000
pbs 4000 exceed-action permit-at-low-pri count
Syntax:[no] traffic-policy TPDname rate-limitadaptivecir cirvalue cbs cbsvalue pir pirvalue pbs
pbsvalue count
Syntax:[no] traffic-policy TPDname rate-limitadaptivecir cirvalue cbs cbsvalue pir pirvalue pbs
pbsvalue exceed-action action count
Viewing ACL and rate limit counters
When ACL counting is enabled on the Brocade device, you can use show commands to display the
total packet count and byte count of the traffic filtered by ACL statements. The output of the show
commands also displays the rate limiting traffic counters, which are automatically enabled for active rate
limiting traffic policies.
Use either the show access-list accounting traffic-policy command or the show statistics traffic-policy command to display ACL and traffic policy counters. The outputs of these commands is identical.
In the SX-FI48GPP module only, the outputs of these commands are identical with one exception.
When ACL counting is shown by show statistics traffic-policy , the Packet Count is not supported
and displays "N/A".
The following example shows the output from the show access-list accounting command.
device#show access-list accounting traffic-policy g_voip
Traffic Policy - g_voip:
General Counters:
Port Region# Byte Count Packet Count
7 (4/1 - 4/12) 85367040 776064
All port regions 84367040 776064
Rate Limiting Counters:
Port Region# Green Conformance Yellow Conformance Red Conformance
7 (4/1 - 4/12) 85367040 776064
All port regions 84367040 776064
Rate Limiting Counters (in Packets):
Port Region# Green Conformance Yellow Conformance Red Conformance
Port Region #The port region to which the active traffic policy applies.
Byte CountThe number of bytes (packets in ICX 6650) that were filtered (matched ACL clauses).
Packet CountThe number of packets that were filtered (matched ACL clauses).
Rate Limiting Counters
Port Region#The port region to which the active traffic policy applies.
Green ConformanceThe number of bytes (packets in ICX 6650) that did not exceed the CIR packet rate.
Yellow ConformanceThe number of bytes (packets in ICX 6650) that exceeded the CIR packet rate.
Red ConformanceThe number of bytes (packets in ICX 6650) that exceeded the PIR packet rate.
Clearing ACL and rate limit counters
The Brocade device keeps a running tally of the number of packets and the number of bytes per packet
that are filtered by ACL statements and rate limiting traffic policies. You can clear these accumulated
counters, essentially resetting them to zero. To do so, use either the clear access-list accountingtraffic-policy command or the clear statistics traffic-policy command.
To clear the counters for ACL counting and rate limit counting, enter commands such as the following.
The TPDname is the name of the traffic policy definition for which you want to clear traffic policy
counters.
Viewing traffic policies
To view traffic policies that are currently defined on the Brocade device, enter the show traffic-policy
command. The following example shows displayed output. The following table explains the output of the
show traffic-policy command.
To display all traffic policies, enter the show traffic-policy command without entering a TPD name.
Traffic policy information TABLE 33
ParameterDescription
Traffic PolicyThe name of the traffic policy.
MeteringShows whether or not rate limiting was configured as part of the traffic policy:
•Enabled - The traffic policy includes a rate limiting configuration.
•Disabled - The traffic policy does not include a rate limiting configuration.
ModeIf rate limiting is enabled, this field shows the type of metering enabled on the port:
•Fixed Rate-Limiting
•Adaptive Rate-Limiting
cirThe committed information rate, in kbps (pkts/s in ICX 6650), for the adaptive rate limiting
policy.
cbsThe committed burst size, in bytes (packets in ICX 6650) per second, for the adaptive rate-
imiting policy.
pirThe peak information rate, in kbps (pkts/s in ICX 6650), for the adaptive rate limiting policy.
pbsThe peak burst size, in bytes (packets in ICX 6650) per second, for the adaptive rate
limiting policy.
CountingShows whether or not ACL counting was configured as part of the traffic policy:
•Enabled - Traffic policy includes an ACL counting configuration.
•Not Enabled - Traffic policy does not include an ACL traffic counting configuration.
Number of
References/
Bindings
NOTE
This field does not apply to FastIron X Series and ICX 6650 devices.
The number of port regions to which this traffic policy applies. For example, if the traffic
policy is applied to a trunk group that includes ports e 9/9, 9/10, 9/11, and 9/12, the value in
this field would be 2, because these four trunk ports are in two different port regions.
Unnecessary traffic to the switch CPU lowers the efficiency of the CPU and delays handling of other
traffic that requires processing. CPU rate limiting is a CPU protection scheme which limits certain traffic
types.
CPU rate limiting identifies the traffic type and assigns a maximum rate limit to the traffic type. The
traffic types which are subjected to rate limiting include broadcast ARP and other exceptions, such as
TTL exceed, IP MTU failed, reverse path check failed, IP fragments, and unsupported tunneling. Each
of these types is rate-limited individually.
The following table shows the rate limits for each rate-limited packet type and shows which platforms on
which each rate limit applies. These rates cannot be configured by users currently.
CPU rate-limiting
CPU rate limits for packet type and applicable platforms TABLE 34
Packet typeRate limit in packets per
ARP6000All
IP TTL exceed, or
Reverse path check failed
IP MTU exceed,
IP tunnel-terminated packets which are fragmented or has
options, or
IP tunnel-terminated packets with unsupported GRE tunnel
header
IP Unicast packets mirrored to CPU due to ICMP redirect100All
Bridge packets forward to CPU5000FCX and ICX
second
150All
3000All
Applicable platforms
All currently supported FastIron devices support the CPU rate-limiting feature. However, on the FSX
devices, only the following modules support this feature:
PFC prevents frame loss from congestion by pausing traffic based on the congested priority without
affecting the traffic of uncongested priorities.
Flow control enables feedback from a receiver to its sender to communicate buffer availability.
Brocade's priority flow control (PFC) feature implements IEEE 802.1Qbb PFC on the Brocade ICX 7750
device, supporting eight priorities and four priority groups (PGs) that can be subject to flow control
independently. You can configure PGs for priority flow control and ingress buffer management.
Because multiple priorities can be mapped to a single PG, congestion on one priority in a PG might
generate a pause, stopping transmission of all priorities in the PG. Therefore, it is important to create a
custom priority-to-PG map to meet your application needs, using either PFC pause honoring or PFC
pause transmission.
PFC pause honoring
•The MAC decodes the class enable vector field to extract the priorities and pause timer value from
the packet.
•The per priority XOFF/XON status is passed to the pausing logic to pause/resume packet
scheduling to the corresponding queue of the egress port.
PFC pause transmission
•Each priority can be mapped to a PG. The mapping is configurable.
•When buffer threshold of a PG exceeds XOFF value, a PFC pause frame is sent. The pause frame
is encoded with all priorities that belong to the PG in class enable vector.
A receiver using PFC must predict the potential for buffer exhaustion for a PG and respond by
generating an explicit PAUSE frame for that class when that condition arises. At any time the receiver
must have enough ingress buffers available to store any packet that might be in flight while the PAUSE
frame travels back to the sender and gets processed there. In ICX 7750 the number of ingress buffers is
set automatically according to the port speed when PFC is enabled.
You can configure the qos priority-to-pg command to change the default priority to PG mapping. See
the description of the qos priority-to-pg command for more information on the default mapping.
By default, the Brocade ICX 7750 device boots up with tail-drop mode, which means that packets are
dropped at the egress queues during congestion. By default, all ports honor IEEE 802.3X pause.
However, when transmission of the 802.3x pause is disabled, PFC is also disabled. You can configure
the symmetrical-flow-control enable command to enable the transmission of the 802.3x pause. See
the description of the symmetrical-flow-control enable command for more information on symmetrical
flow control.
Enabling flow control on ports that have auto-neg enabled causes flap because the port pause
capabilities must be advertised and negotiated again with peer.
Ports that have auto-neg disabled do not experience flap.
Configuring priority flow control
Enables PFC globally and for a priority group.
1.Enable priority flow control (PFC)globally.
Device(config)# priority-flow-control enable
2.Enable PFC for priority group (PG) 0.
Device(config)# priority-flow-control 0
Packet buffer management
Packet buffer management.
On Brocade ICX 7750 devices, packet memory can support 960 Gbps bandwidth. The total packet
memory is 12M bytes. ICX 7750 devices run in cut-through mode, which means that cut-through
eligible packets are not buffered. If a packet needs to be buffered, it is buffered after Layer 2 and 3
lookup. Packet priority is classified before buffering.
There are two independent packet admission mechanisms: ingress buffer management and egress
buffer management.
Ingress buffer management
•The ingress buffer mechanism determines whether a packet should be admitted into memorybased on the state of available memory and the amount of buffer resources in use by the ingress
port priority group.
•It aims to support fair access to buffering resources while also enabling loss-less operation across
a network.
•The memory is logically divided into three sections: guaranteed, shared, and headroom for flow
control in fly packets.
•Ingress buffer limits are automatically configured based on user configuration to support either
loss-less or tail drop operation.
Egress buffer management
•The egress buffer mechanism tracks buffer utilization on a per egress port-priority basis. As these
accounting structures reach the limit, packets that are destined to the congested egress portpriority are tail-dropped.
•It aims to support fair access to the buffering resources among congested egress ports.
•Any incoming packet is counted only once per egress port regardless of whether it is unicast or
multicast.
•Memory is logically divided into two sections: guaranteed and shared.
•You can configure the qos egress-buffer-profile command to configure a share level, which
determines the maximum number of buffers an egress queue can use as a fraction of the total
sharing pool. For example, if queue 4 is at level4, queue 4 is entitled to use up to 1/9 of total
sharing buffers in the sharing pool. You can configure eight levels of sharing. The actual number of
buffers a queue can use depends on the current available buffers in the system. See the
description of the qos egress-buffer-profile command for more information on egress buffer
profiles.
The following example shows how to remove an egress buffer profile named user2 from multiple ports:
Device(config-mif-1/1/2-1/1/16)# no egress-buffer-profile egress2
History
Release versionCommand history
8.0.10This command was introduced.
ip dscp-remark
Enables remarking of the DSCP field for all IPv4 packets.
Syntax
Modes
Usage Guidelines
Examples
ip dscp-remark dscp-value
no ip dscp-remark dscp-value
Global configuration mode
Interface configuration mode
The no form of this command removes DSCP remarking.
In the interface configuration mode, the command enables differentiated services code point (DSCP)
remarking for the given port. The configuration can be done on a physical port, LAG, and VE.
The following example shows how to globally set the DSCP bit value to 40:
Device(config)# ip dscp-remark 40
The following example shows how to set the DSCP bit value to 50 on a specific port:
Device(config)# interface ethernet1/1/1
Device(config-if-e1000-1/1/1)# ip dscp-remark 50
History
Release versionCommand history
Unknown
ip pcp-remark
Enables remarking of the PCP field in the VLAN header for all received tagged packets.
The no form of this command removes PCP remarking.
In the interface configuration mode, the command enables PCP remarking for each port. The command
can be configured only on Layer 2 ports. The configuration can be done on a physical port, LAG, and
VE port.
Examples
The following example shows how to globally set the PCP bit value to 4:
Device(config)# ip pcp-remark 4
The following example shows how to set the PCP value to 5 on a specific port:
Device(config)# interface ethernet1/1/1
Device(config-if-e1000-1/1/1)# ip pcp-remark 5
priority-flow-control
Enables priority flow control on a priority group.
Syntax
priority-flow-control priority-group-number
History
Release versionCommand history
Not availableThis command was introduced.
Command Default
Parameters
Modes
Usage Guidelines
Examples
History
no priority-flow-controlpriority-group-number
PFC is globally disabled.
priority-group-number
Specifies a priority group. The range is 0-3.
Global configuration mode
The no form of this restores the default flow-control settings.
To enable global PFC, symmetrical-flow-control must be disabled.
You must enable PFC globally before you configure it for priority groups.
Priority flow control and 802.3x flow control are mutually exclusive; therefore, configuring the priority-flow-control command disables 802.3x in both transmit and receive directions.
The following example shows how to enable PFC for a priority group.
The no form of this restores the default flow-control settings.
To enable global PFC, symmetrical-flow-control must be disabled.
You must enable PFC globally before you configure it for priority groups.
Priority flow control and 802.3x flow control are mutually exclusive; therefore, configuring the priority-flow-control enable command disables 802.3x in both transmit and receive directions.
You can attach an egress buffer profile to a port.
You must configure the no qos egress-buffer-profile command to detach a profile from any ports that
are using it before you can configure the no qos egress-buffer-profile command to delete it.
The higher the sharing level, the better the port absorb micro-burst. However, higher sharing level of 7
and 8 may compromise QoS functions and create uneven distribution of traffic during congestions.
The following is the default egress buffer profile:
QueueShare level
0level4-1/9
1level3-1/16
2level3-1/16
3level3-1/16
4level3-1/16
5level3-1/16
6level3-1/16
7level3-1/16
The following eight queue-share levels are supported:
The following example shows how to create an egress buffer profile named port-40G.
Device(config)# qos egress-buffer-profile port-40G queue-share-level
level1-1/64 1/64 of buffers in the sharing pool
level2-1/32 1/32 of buffers in the sharing pool
level3-1/16 1/16 of buffers in the sharing pool
level4-1/9 1/9 of buffers in the sharing pool
level5-1/5 1/5 of buffers in the sharing pool
level6-1/3 1/3 of buffers in the sharing pool
level7-1/2 1/2 of buffers in the sharing pool
level8-2/3 2/3 buffers in the sharing pool
The following example shows how to configure queue 0 on the egress buffer profile named port-40G to
use 1/5 of sharing pool:
The following example shows how to attach the egress buffer profile named port-40G to ports 1/2/1 to
1/2/6:
Device(config)# interface ethernet 1/2/1 to 1/2/6
Device(config-mif-1/2/1-1/2/6)#egress-buffer-profile port-40G
Device(config-mif-1/2/1-1/2/6)#end
The following example shows the error if you try to delete a profile that is attached to a port:
Device(config)# no qos egress-buffer-profile port-40G
Error - Egress Profile port-40G is active on Port 1/2/1. It must be deactivated from
port before deleting.
The following example shows how to detach the egress buffer profile named port-40G from ports 1/2/1
to 1/2/6 and then delete the profile:
Device(config)# interface ethernet 1/2/1 to 1/2/6
Device(config-mif-1/2/1-1/2/6)# no egress-buffer-profile port-40G
Device(config-mif-1/2/1-1/2/6)#exit
Device(config)# no qos egress-buffer-profile port-40G
History
Release versionCommand history
8.0.10This command was introduced.
qos priority-to-pg
Configures priority-to-priority-group (PG) mapping for priority flow control (PFC).
Configures the internal priority based on classification in the range 0 to 7.
Specifies the internal priority-to-PG mapping. The range is 0 to 3.
Modes
Usage Guidelines
Global configuration mode
The no form of this command restores the default priority-to-PG map.
You must configure the priority-flow-control enable command to enable PFC globally before you
configure priority-to-PG mapping.
The default value of priority-to-PG maps is as follows:
•QoS internal priority 0 is mapped to PG 0
•QoS internal priority 1 is mapped to PG 0
•QoS internal priority 2 is mapped to PG 1
•QoS internal priority 3 is mapped to PG 1
•QoS internal priority 4 is mapped to PG 1
•QoS internal priority 5 is mapped to PG 2
•QoS internal priority 6 is mapped to PG 2
•QoS internal priority 7 is mapped to PG 2
You can map QoS internal priority 7 to PG 3. You can also map any other priority to PG 3 ifit meets
these requirements:
•Lower priorities mapped to lower PGs.
•PGs are configured in ascending order.
•Multiple priorities in a single PG must be consecutive.
Priority-to-pg mapping is not configurable in other modes. Symmetrical and Asymmetrical 802.3x Flow
Control modes have their own default priority-to-PG mapping.
You must configure PGs in ascending order, 0-3. You can configure a higher-order PG only if all the
lower-order PGs have some mapped priorities.
Examples
History
The following example shows how to configure a priority-to-PG map:
Specifies the name of the scheduler profile to be configured.
mechanismscheduling-mechanism
Configures the queue assignment with the specified scheduling mechanism . The following
scheduling mechanisms are supported:
mixed-sp-wrr
Specifies mixed strict-priority (SP) and weighted scheduling.
strict
Specifies SP scheduling.
weighted
Specifies weighted scheduling.
profile qosp0-7
Configures the profile based on classification in the range 0 to 7.
wt0-7
Specifies the bandwidth percentage for the corresponding QoS profile. The range is 0 to 7.
Modes
Usage Guidelines
Global configuration mode
The no form of this command removes the scheduler profile configuration.
You can use the scheduler-profile command to attach a user scheduler profile to a port. If you want to
remove a scheduler-profile, you must ensure that it is not attached to any port.
The default qos-profile weights for each queue using a weighted QoS mechanism are as follows:
The default qos-profile weights for each queue using a mixed QoS mechanism are as follows:
Per-queue DetailsBandwidth Percentage
Examples
Class 015
Class 115
Class 215
Class 315
Class 415
Class 525
Class 6sp
Class 7sp
The total weight (wt0-wt7) in both weighted and mixed mechanism must be 100%.
The minimum value for any weight is 1.
A maximum of eight scheduler profiles are supported.
The following example shows how to configure a QoS scheduler profile named user1, with weighted
scheduling, and specify the bandwidth percentage for each QoS class:
Displays the priority flow control (PFC) on the system.
show priority-flow-control
Syntax
Modes
Examples
show priority-flow-control
Privileged EXEC mode
The following example shows the PFC status of all priority groups:
Device# show priority-flow-control
Global PFC Status: Enabled
PFC Enabled on PG0
PFC Disabled on PG1
PFC Disabled on PG2
PFC Disabled on PG3
The following example shows the PFC status disabled:
Device# show priority-flow-control
Global PFC Status: Disabled
History
Release versionCommand history
8.0.10This command was introduced.
show qos egress-buffer-profile
Displays information about egress buffer profiles.
Syntax
Parameters
Modes
Examples
show qos egress-buffer-profile [ user-profile-name | all ]
user-profile-name
Specifies that information is displayed for the specified egress buffer profile.
all
Specifies that information is displayed for all the egress buffer profiles configured in the
system and a list of all the ports attached to any egress buffer profile.
Global configuration mode
The following example displays information for an egress buffer profile named egress1:
Device(config)# show qos egress-buffer-profile egress1
Displays priority-to-priority-group (PG) mapping for priority flow control (PFC).
Syntax
Modes
Usage Guidelines
Examples
show qos priority-to-pg
Global configuration mode
This command displays priority-to-PG mapping for following modes:
•PFC
•Symmetrical flow control
•Asymmetrical flow control
The following example shows priority-to-PG mapping for PFC:
Device(config)# show qos priority-to-pg
QoS Internal Priority 0 mapped to Priority Group 0
QoS Internal Priority 1 mapped to Priority Group 0
QoS Internal Priority 2 mapped to Priority Group 1
QoS Internal Priority 3 mapped to Priority Group 1
QoS Internal Priority 4 mapped to Priority Group 1
QoS Internal Priority 5 mapped to Priority Group 2
QoS Internal Priority 6 mapped to Priority Group 2
QoS Internal Priority 7 mapped to Priority Group 2
The following example shows priority-to-PG mapping for of 802.3x (Flow-Control). Honor is enabled.
Device(config)# show qos priority-to-pg
QoS Internal Priority 0 mapped to Priority Group 0
QoS Internal Priority 1 mapped to Priority Group 0
QoS Internal Priority 2 mapped to Priority Group 1
QoS Internal Priority 3 mapped to Priority Group 1
QoS Internal Priority 4 mapped to Priority Group 1
QoS Internal Priority 5 mapped to Priority Group 2
QoS Internal Priority 6 mapped to Priority Group 2
QoS Internal Priority 7 mapped to Priority Group 2
The following example shows priority-to-PG mapping for symmetrical flow control for 802.3x (FlowControl) in Both mode (Generate and Honor are enabled) or Generate-only mode.
Device(config)# symmetrical-flow-control enable
Device(config)# show qos priority-to-pg
QoS Internal Priority 0 mapped to Priority Group 7
QoS Internal Priority 1 mapped to Priority Group 7
QoS Internal Priority 2 mapped to Priority Group 7
QoS Internal Priority 3 mapped to Priority Group 7
QoS Internal Priority 4 mapped to Priority Group 7
QoS Internal Priority 5 mapped to Priority Group 2
QoS Internal Priority 6 mapped to Priority Group 2
QoS Internal Priority 7 mapped to Priority Group 2
The following example enables flow control on all priorities and shows the priority-to-PG mapping .
Device(config)# symmetrical-flow-control enable all
Device(config)# show qos priority-to-pg
QoS Internal Priority 0 mapped to Priority Group 7
QoS Internal Priority 1 mapped to Priority Group 7
QoS Internal Priority 2 mapped to Priority Group 7
QoS Internal Priority 3 mapped to Priority Group 7
QoS Internal Priority 4 mapped to Priority Group 7
QoS Internal Priority 5 mapped to Priority Group 7
QoS Internal Priority 6 mapped to Priority Group 7
QoS Internal Priority 7 mapped to Priority Group 7
History
Release versionCommand history
8.0.10This command was introduced.
show qos scheduler
Displays information about scheduler profiles.
Syntax
Command Default
Parameters
Modes
Usage Guidelines
show qos scheduleralluser-profile-name
None.
all
user-profile-name
Global configuration mode
A scheduler profile must be configured before it can be displayed.
Information can be displayed for a maximum eight scheduler profiles.
Specifies that information is displayed for all the scheduler profiles configured in the system
and a list of all the ports attached to any scheduler profile.
Specifies that information is displayed for the specified scheduler profile.
The following example displays information for a scheduler profile named user1:
Device(config)# show qos scheduler-profile user1
User Scheduler Profile: user1 Scheduling Option: Weighted round-robin
Ports attached: 1/1/1
Per Queue details: Bandwidth%
Traffic Class 0 1%
Traffic Class 1 1%
Traffic Class 2 10%
Traffic Class 3 10%
Traffic Class 4 10%
Traffic Class 5 10%
Traffic Class 6 20%
Traffic Class 7 38%
store-and-forward
The following example displays information for all the scheduler profiles configured in the system:
Device(config)# show qos scheduler-profile all
User Scheduler Profile: user1 Scheduling Option: Weighted round-robin
Ports attached: 1/1/1
Per Queue details: Bandwidth%
Traffic Class 0 1%
Traffic Class 1 1%
Traffic Class 2 10%
Traffic Class 3 10%
Traffic Class 4 10%
Traffic Class 5 10%
Traffic Class 6 20%
Traffic Class 7 38%
User Scheduler Profile: user3 Scheduling Option: Mixed-SP-WRR
Ports attached: -Per Queue details: Bandwidth%
Traffic Class 0 15%
Traffic Class 1 15%
Traffic Class 2 15%
Traffic Class 3 15%
Traffic Class 4 15%
Traffic Class 5 25%
Traffic Class 6 sp
Traffic Class 7 sp
User Scheduler Profile: user4 Scheduling Option: Weighted round-robin
Ports attached: -Per Queue details: Bandwidth%
Traffic Class 0 3%
Traffic Class 1 3%
Traffic Class 2 3%
Traffic Class 3 3%
Traffic Class 4 3%
Traffic Class 5 3%
Traffic Class 6 7%
Traffic Class 7 75%
History
Release versionCommand history
8.0.10This command was introduced.
store-and-forward
Syntax
Command Default
Parameters
Modes
Usage Guidelines
store-and-forward
no store-and-forward
By default, ICX 7750 runs in cut-through mode
None
Global configuration mode
The no form of this command restores the default packet forwarding settings to cut-through mode.
There are two basic methodologies used for packet forwarding decisions that you can set on your
ethernet switch. These include store-and-forward and cut-through mode. ICX 7750 supports cut-through
and store-and-forward mode. The store-and forward command changes the switching methodology to
store-and-forward.
A store-and-forward switch makes a forwarding decision on a data packet after it has received the
whole frame and checked its integrity, a cut-through switch engages in the forwarding process soon
after it has made the forwarding decision of an incoming frame. With cut-through switching, a packet
may start to forward before the entire packet has been received. Therefore, it drastically reduces
forwarding latency, especially for longer packets. However, there are many factors to consider when
selecting which switching mode is best for your environment. In some cases it is desirable to change
from the default mode and set your device to store-and-forward.
The table below describes some of the differences in the way packets are handled depending on the
switching mythology that you set on your device.
Cut-throughStore-and-forward
ForwardingData Forwarding starts before entire packet is
received
LatencyLow Latency, less more 1 micro secondHigher Latency / Latency depends on frame size
FCS ErrorsFCS Errors may be propagated from one
switch to another
MTU sizeMTU size is validated by MAC receive.
Oversize packets are marked as error packets,
but not dropped in the MAC received.
Examples
To globally enable store-and-forward mode and change the default mode from cut-through, enter the
following command:
Brocade(config)# store-and-forward
Brocade(config)# write memory
Brocade(config)# end
Brocade# reload
History
Release versionCommand history
08.0.10b
The store-and-forward command was introduced.
symmetrical-flow-control enable
Wait for entire packet received before processing
FCS errors are checked and error packets are
discarded in the MAC receive.
MTU size is validated by MAC receive. Oversize
packet will be drop at the MAC layer.
Enables symmetrical flow control (SFC) globally for priorities 0-4 by default and optionally for all
priorities (0-7).
Specifies SFC on all priorities. If you do not specify the all keyword, SFC is enabled only on
priorities 0-4. This parameter is optional.
Traffic Management Commands
Modes
Usage Guidelines
Examples
Global configuration mode
The no form of this restores the default flow-control settings.
By default, the system runs in tail-drop mode, with all ports honoring 802.3x flow control and disabling
802.3x transmit. The symmetrical-flow-control enablecommand enables transmission of 802.3x
pause frames.
Configuring the symmetrical-flow-control enable command changes priority-to-PG mapping.
You cannot configure the symmetrical-flow-control enable command if the priority-flow-control
command is enabled.
If the symmetrical-flow-control enable command is not enabled, you cannot configure the flow-control generate-only or the flow-control both commands in interface mode.
The following example shows how to enable SFC:
Device(config)# symmetrical-flow-control enable
The following example shows how to enable all priorities to send the IEEE 802.3x pause:
Device(config)# symmetrical-flow-control enable all
The following example shows how to enable SFC for Generate-only mode:
clearing counters 73
configuring 65
specifying action to be taken for packets that are
over the limit 69
statistics 70
using traffic policies 64
viewing counters 71
802.1p priority override 28
assigning static MAC entries to priority queues 28
behavior for Layer 2 (802.1p) 19
behavior on port priority and VLAN priority 19
buffer allocation and thresholds 28
changing a port priority 27
changing the DSCP to internal forwarding priority
mappings 34
changing the minimum bandwidth percentages 39
configuring the QoS queues 39
default mappings 12
default scheduling configuration for the ICX 6430
36
default scheduling configuration for the SXF148GPP module 36
default values for FCX and ICX 6450 platforms 24
default values for ICX 6430 platforms 24
determining the trust level of a packet 12
displaying DSCP-based settings 42
displaying the user-configurable scheduler profile
configuration 24
DSCP-based 31
enabling 802.1p priority override 29
mapping a VLAN priority to hardware forwarding
queue 35
mapping configuration 33
marking 29
priorities-to-traffic assignment 27
processing of classified traffic 12
profile restrictions 19
queues 20
queues for the ICX 6430 switch 22
queues for the SX-F148GPP interface modules 20
queuing methods 37
scheduling information 37
support on Brocade FastIron units 19
user-configurable scheduler profile 23
using ACLs to honor DSCP-based QoS 32
QoS behavior for trusting Layer 3 (DSCP) 19
Quality of Service (QoS)
overview 12
R
rate limiting
configuring ACL-based for FastIron X series, FCX,
and ICX series switches 48
configuring for FastIron X series, FCX, and ICX
series switches 48
displaying information for FastIron X series, FCX,
and ICX series switches 48
fixed rate limiting 46
hardware for FastIron X series, FCX, and ICX
series switches 46
overview for FastIron X series, FCX, and ICX
series switches 45
rate shaping
configuring outbound for a port 51
configuring outbound for a specific priority 51
displaying configurations 52
for FastIron X series, FCX, and ICX series
switches 50
S
show command
show access-list accounting traffic-policy 71
show qos-profiles
QoS
displaying settings 41
show qos-tos 34, 42
show rate-limit broadcast 57
show rate-limit fixed 48
show rate-limit output-shaping 52
show rate-limit unknown-unicast 57
show run interface 57
show run interface ethernet 29
show-traffic policy 73
T
traffic policies
configuration notes and feature limitations 62
CoS parameters for packets 62
CPU rate-limiting 75
enabling ACL statistics 70
maximum number supported on a device 63
overview 61
setting the maximum number on a Layer 3 device
64
using ACL-based rate limiting 64
viewing 73
98
U
unicast limiting command syntax 54
FastIron Ethernet Switch Traffic Management Guide
53-1003093-03
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.