Fast Iron
Fast Iron
31 March 2015
ADX, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, HyperEdge, ICX, MLX, MyBrocade, OpenScript, The Effortless
Network, VCS, VDX, Vplane, and Vyatta are registered trademarks, and Fabric Vision and vADX are trademarks of Brocade
Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be
trademarks of others.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any
equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document
at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be
currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in
this document may require an export license from the United States government.
The authors and Brocade Communications Systems, Inc. assume no liability or responsibility to any person or entity with respect to the
accuracy of this document or any loss, cost, liability, or damages arising from the information contained herein or the computer programs that
accompany it.
The product described by this document may contain open source software covered by the GNU General Public License or other open
source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to
the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.
Preface...................................................................................................................................11
Document conventions....................................................................................11
Text formatting conventions................................................................ 11
Command syntax conventions............................................................ 11
Notes, cautions, and warnings............................................................ 12
Brocade resources.......................................................................................... 13
Contacting Brocade Technical Support...........................................................13
Document feedback........................................................................................ 14
Management Applications...................................................................................................... 19
Management port overview.............................................................................19
How the management port works....................................................... 19
CLI Commands for use with the management port.............................20
Web Management Interface............................................................................21
Management VRFs......................................................................................... 21
Source interface and management VRF compatibility........................ 22
Supported management applications..................................................22
Configuring a global management VRF.............................................. 24
Displaying management VRF information...........................................25
IPv6....................................................................................................................................139
Static IPv6 route configuration.................................................................... 139
Configuring a static IPv6 route........................................................ 139
Configuring a static route in a non-default VRF or User VRF......... 141
IPv6 over IPv4 tunnels................................................................................ 141
IPv6 over IPv4 tunnel configuration notes...................................... 142
Configuring a manual IPv6 tunnel................................................... 142
Clearing IPv6 tunnel statistics......................................................... 143
Displaying IPv6 tunnel information..................................................143
Foundry Discovery Protocol (FDP) and Cisco Discovery Protocol (CDP) Packets .................... 163
FDP Overview.............................................................................................163
FDP configuration........................................................................... 163
Displaying FDP information.............................................................165
Clearing FDP and CDP information................................................ 167
CDP packets............................................................................................... 168
Enabling interception of CDP packets globally............................... 168
Enabling interception of CDP packets on an interface....................168
Displaying CDP information............................................................ 169
Clearing CDP information............................................................... 170
System Monitoring..............................................................................................................265
Overview of system monitoring................................................................... 265
Configuration notes and feature limitations.....................................265
Configure system monitoring...................................................................... 266
disable system-monitoring all .........................................................266
enable system-monitoring all ......................................................... 266
sysmon timer ..................................................................................267
sysmon log-backoff ........................................................................ 267
sysmon threshold ........................................................................... 268
System monitoring on FCX and ICX devices.............................................. 268
sysmon ecc-error ........................................................................... 268
sysmon link-error ............................................................................269
System monitoring for Fabric Adapters.......................................................270
sysmon fa error-count .................................................................... 271
sysmon fa link ................................................................................ 272
System monitoring for Cross Bar................................................................ 273
sysmon xbar error-count ................................................................ 273
sysmon xbar link ............................................................................ 274
System monitoring for Packet Processors.................................................. 275
Syslog.................................................................................................................................. 285
About Syslog messages................................................................................285
Displaying Syslog messages........................................................................ 286
Enabling real-time display of Syslog messages................................286
Enabling real-time display for a Telnet or SSH session.................... 286
Displaying real-time Syslog messages ............................................ 287
Syslog service configuration......................................................................... 287
Displaying the Syslog configuration.................................................. 287
Disabling or re-enabling Syslog........................................................ 290
Specifying a Syslog server................................................................291
Specifying an additional Syslog server............................................. 291
Disabling logging of a message level................................................291
Changing the number of entries the local buffer can hold.................291
Changing the log facility.................................................................... 292
Displaying interface names in Syslog messages.............................. 293
Displaying TCP or UDP port numbers in Syslog messages............. 293
Retaining Syslog messages after a soft reboot.................................293
Clearing the Syslog messages from the local buffer.........................294
Syslog messages for hardware errors.............................................. 294
OpenSSL License................................................................................................................385
OpenSSL license........................................................................................ 385
Original SSLeay License.................................................................385
● Document conventions....................................................................................................11
● Brocade resources.......................................................................................................... 13
● Contacting Brocade Technical Support...........................................................................13
● Document feedback........................................................................................................ 14
Document conventions
The document conventions describe text formatting conventions, command syntax conventions, and
important notice formats used in Brocade technical documentation.
Format Description
bold text Identifies command names
Identifies keywords and operands
Identifies the names of user-manipulated GUI elements
Identifies text to enter at the GUI
Convention Description
bold text Identifies command names, keywords, and command options.
italic text Identifies a variable.
value In Fibre Channel products, a fixed value provided as input to a command
option is printed in plain text, for example, --show WWN.
Convention Description
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.
Brocade resources
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.
Brocade customers
For product support information and the latest information on contacting the Technical Assistance
Center, go to http://www.brocade.com/services-support/index.html.
If you have purchased Brocade product support directly from Brocade, use one of the following methods
to contact the Brocade Technical Assistance Center 24x7.
Preferred method of contact for non- Required for Sev 1-Critical and Sev [email protected]
urgent issues: 2-High issues:
Please include:
• My Cases through MyBrocade • Continental US: 1-800-752-8061
• Problem summary
• Software downloads and licensing • Europe, Middle East, Africa, and
• Serial number
tools Asia Pacific: +800-AT FIBREE
(+800 28 34 27 33) • Installation details
• Knowledge Base
• For areas unable to access toll • Environment description
free number: +1-408-333-6061
• Toll-free numbers are available in
many countries.
• Brocade Supplemental Support augments your existing OEM support contract, providing direct
access to Brocade expertise. For more information, contact Brocade or your OEM.
• For questions regarding service levels and response times, contact your OEM/Solution Provider.
Document feedback
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 [email protected].
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.
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.
For information about the specific models and modules supported in a product family, refer to the
hardware installation guide for that product family.
ICX 7750 40 Gbps Certain ICX 7750 40 Gbps ports can be Refer to the chapter 40 Gbps
breakout port configured with sub-ports when a breakout Breakout Ports for configuration
configuration cable is installed. information. Refer to the ICX 7750
Ethernet Switch Hardware Installation
Guide for information on the breakout
cable.
Energy efficient Regulates and saves power consumed by the Refer to the chapter Operations
ethernet active hardware components in the switch and Administration and Maintenance
conserves power during idle time. This feature
is supported on the ICX 7250 and ICX 7450
devices.
External USB hotplug Allows you to copy images, cores, logs and Refer to the chapter Operations
configurations between the external USB and Administration and Maintenance
the internal eUSB. This feature is supported on
ICX 7250, ICX 7450 and ICX 7750 devices.
Histogram The histogram framework feature monitors and Refer to the chapter Operations
records system resource usage information. Administration and Maintenance
This feature is supported on ICX 6430, ICX
6450, ICX 7250, ICX 7450 and ICX 7750
devices.
IEEE 802.3ah EFM- EFM-OAM provides mechanisms to monitor link Refer to IEEE 802.3ah EFM-OAM on
OAM operation, health and improve fault isolation of page 114
Ethernet network to increase management
capability.
sFlow sample mode The sample mode can be changed to include Refer to Changing the sampling
the dropped packets for sFlow sampling. mode on page 251
sFlow source IP The sFlow source interface can be configured Refer to sFlow and source IP address
address from which the IP source address is selected for on page 248
the sFlow datagram.
Flash timeout The flash timeout can be configured to a value Refer to Flash timeout on page 94
from 12 through 60 minutes.
Elapsed timestamp The elapsed time between the most recent Refer to Enabling the display of the
display for port statistics reset of the port statistics counters and the time elapsed timestamp for port statistics
reset when the show statistics command is reset on page 231
executed, can be displayed in the output of the
show statistics command.
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 supported in FastIron Release 08.0.20 and later, the CLI is documented in
separate command pages included in the FastIron Command Reference. Command pages are
compiled in alphabetical order and follow a standard format to present syntax, parameters, usage
guidelines, examples, and command history.
NOTE
Many commands from previous FastIron releases are also included in the command reference.
• Legacy content in configuration guides 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 FastIron
Command Reference.
NOTE
The management port applies to FCX, SX 800, SX 1600, ICX 6430, and ICX 6450 devices.
The management port is an out-of-band port that customers can use to manage their devices without
interfering with the in-band ports. The management port is widely used to download images and
configurations, for Telnet sessions and for Web management.
For FCX devices, the MAC address for the management port is derived from the base MAC address of
the unit, plus the number of ports in the base module. For example, on a 48-port FCX standalone
device, the base MAC address is 0000.0034.2200. The management port MAC address for this device
would be 0000.0034.2200 plus 0x30, or 0000.0034.2230. The 0x30 in this case equals the 48 ports on
the base module.
For SX 800 and SX 1600 devices, the MAC address for the management port is derived as if the
management port is the last port on the management module where it is located. For example, on a 2 X
10G management module, the MAC address of the management port is that of the third port on that
module.
management port. In this situation, the MAC address of the old Active Controller and the MAC address
of the new controller will be different.
To display the current configuration, use the show interfaces management command.
Syntax: show interfaces management num
To display the management interface information in brief form, enter the show interfaces brief
management command.
Syntax: show interfaces brief management num
To display management port statistics, enter the show statistics management command.
Syntax: show statistics management num
InDiscards 0 OutErrors 0
CRC 0 Collisions 0
InErrors 0 LateCollisions 0
InGiantPkts 0
InShortPkts 0
InJabber 0
InFlowCtrlPkts 0 OutFlowCtrlPkts 0
InBitsPerSec 83728 OutBitsPerSec 24
InPktsPerSec 130 OutPktsPerSec 0
InUtilization 0.01% OutUtilization 0.00%
To display the management interface statistics in brief form, enter the show statistics brief
management command.
Syntax: show statistics brief management num
Management VRFs
Virtual routing and forwarding (VRF) allows routers to maintain multiple routing tables and forwarding
tables on the same router. A management VRF can be configured to control the flow of management
traffic as described in this section.
NOTE
For information on configuring Multi-VRF, sometimes called VRF-Lite or Multi-VRF CE, refer to the
FastIron Ethernet Switch Layer 3 Routing Configuration Guide.
A management VRF is used to provide secure management access to the device by sending inbound
and outbound management traffic through the VRF specified as a global management VRF and through
the out-of-band management port, thereby isolating management traffic from the network data traffic.
By default, the inbound traffic is unaware of VRF and allows incoming packets from any VRF, including
the default VRF. Outbound traffic is sent only through the default VRF. The default VRF consists of an
out-of-band management port and all the LP ports that do not belong to any other VRFs.
Any VRF, except the default VRF, can be configured as a management VRF. When a management
VRF is configured, the management traffic is allowed through the ports belonging to the specified VRF
and the out-of-band management port. The management traffic through the ports belonging to the other
VRFs and the default VRF are dropped, and the rejection statistics are incremented.
If the management VRF is not configured, the management applications follows default behavior. The
management VRF is configured the same way for IPv4 and IPv6 management traffic.
The management VRF is supported by the following management applications:
• SNMP server
• SNMP trap generator
• Telnet server
• SSH server
• Telnet client
• RADIUS client
• TACACS+ client
• TFTP
• SCP
• Syslog
NOTE
Any ping or traceroute commands use the VRF specified in the command or the default VRF if no
VRF is specified.
SNMP server
When the management VRF is configured, the SNMP server receives SNMP requests and sends
SNMP responses only through the ports belonging to the management VRF and through the out-of-
band management port.
Any change in the management VRF configuration becomes immediately effective for the SNMP
server.
NOTE
The SNMP source interface configuration command snmp-server trap-source must be compatible
with the management VRF configuration.
SSH server
When the management VRF is configured, the incoming SSH connection requests are allowed only
from the ports belonging to the management VRF and from the out-of-band management port.
Management VRF enforcement occurs only while a connection is established.
To allow the incoming SSH connection requests only from the management VRF and not from the out-
of-band management port, enter the following command.
The ip ssh strict-management-vrf command is applicable only when the management VRF is
configured. If not, the command issues the following warning message.
For the SSH server, changing the management VRF configuration or configuring the ip ssh strict-
management-vrf command does not affect the existing SSH connections. The changes are be applied
only to new incoming connection requests.
Telnet client
When the VRF name is specified in the telnet vrf command, the Telnet client initiates Telnet requests
only from the ports belonging to the specified VRF.
To configure the VRF name in outbound Telnet sessions, enter the following command at the privileged
EXEC level.
RADIUS client
When the management VRF is configured, the RADIUS client sends RADIUS requests or receives
responses only through the ports belonging to the management VRF and through the out-of-band
management port.
Any change in the management VRF configuration takes effect immediately for the RADIUS client.
NOTE
The RADIUS source interface configuration command ip radius source-interface must be compatible
with the management VRF configuration.
TACACS+ client
When the management VRF is configured, the TACACS+ client establishes connections with TACACS
+ servers only through the ports belonging to the management VRF and the out-of-band management
port.
For the TACACS+ client, a change in the management VRF configuration does not affect the existing
TACACS+ connections. The changes are applied only to new TACACS+ connections.
NOTE
The TACACS+ source interface configuration command ip tacacs source-interface must be
compatible with the management VRF configuration.
TFTP
When the management VRF is configured, TFTP sends or receives data and acknowledgments only
through ports belonging to the management VRF and through the out-of-band management port.
Any change in the management VRF configuration takes effect immediately for TFTP. You cannot
change in the management VRF configuration while TFTP is in progress.
NOTE
The TFTP source interface configuration command ip tftp source-interface must be compatible with
the management VRF configuration.
SCP
SCP uses SSH as the underlying transport. The behavior of SCP is similar to the SSH server.
Syslog
When the management VRF is configured, the Syslog module sends log messages only through the
ports belonging to the management VRF and the out-of-band management port.
Any change in the management VRF configuration takes effect immediately for Syslog.
NOTE
The Syslog source interface configuration command ip syslog source-interface must be compatible
with the management VRF configuration.
The vrf-name parameter must specify the name of a pre-configured VRF. If the VRF is not pre-
configured, command execution fails, and the following error message is displayed.
When the management VRF is configured, the following Syslog message is displayed.
Enter the no form of the command to remove the management VRF. When the management VRF is
deleted, the following Syslog message is displayed.
Configuration notes
Consider the following configuration notes:
• If a management VRF is already configured, you must remove the existing management VRF
configuration before configuring a new one. If not, the system displays the following error message.
• If you try to delete a management VRF that was not configured, the system displays the following
error message.
Routes The total number of IPv4 and IPv6 Unicast routes configured on this VRF.
Configured as management-vrf Indicates that the specified VRF is configured as a management VRF.
Number of Unicast Routes The number of Unicast routes configured on this VRF.
The show who command displays information about the management VRF from which the Telnet or
SSH connection has been established.
Rx Drop Pkts Displays the number of packets dropped in the inbound traffic.
Tx Drop Pkts Displays the number of packets dropped in the outbound traffic.
TCP Connection rejects Displays the number of TCP connections per application rejected due to management
VRF validation.
Make sure that the management VRF is configured before executing the show management-vrf
command. If not, the system displays the following error message.
To clear the management VRF rejection statistics, enter the following command.
NOTE
Before assigning or modifying any router parameters, you must assign the IP subnet (interface)
addresses for each port.
NOTE
For information about configuring IP addresses, DNS resolver, DHCP assist, and other IP-related
parameters, refer to "IP Configuration" chapter in the FastIron Ethernet Switch Layer 3 Routing
Configuration Guide
NOTE
For information about the Syslog buffer and messages, refer to Basic system parameter configuration.
The procedures in this section describe how to configure the basic system parameters listed in Basic
Software Features on page 29.
Here is an example of how to configure a system name, system contact, and location.
Syntax:hostname string
Syntax: snmp-server contact string
Syntax: snmp-server location string
The text strings can contain blanks. The SNMP text strings do not require quotation marks when they
contain blanks but the host name does.
NOTE
The chassis name command does not change the CLI prompt. Instead, the command assigns an
administrative ID to the device.
NOTE
To add and modify "get" (read-only) and "set" (read-write) community strings, refer to "Security
Access" chapter in the FastIron Ethernet Switch Security Configuration Guide .
To specify an SNMP trap receiver and change the UDP port that will be used to receive traps, enter a
command such as the following.
To add a trap receiver and configure the software to encrypt display of the community string in the CLI
and Web Management Interface, enter commands such as the following.
The port value parameter allows you to specify which UDP port will be used by the trap receiver. This
parameter allows you to configure several trap receivers in a system. With this parameter, a network
management application can coexist in the same system. Brocade devices can be configured to send
copies of traps to more than one network management application.
The command in this example changes the holddown time for SNMP traps to 30 seconds. The device
waits 30 seconds to allow convergence in STP and OSPF before sending traps to the SNMP trap
receiver.
Syntax: [no] snmp-server enable traps holddown-time seconds
The secs parameter specifies the number of seconds and can be from 1 - 600 (ten minutes). The
default is 60 seconds.
NOTE
By default, all SNMP traps are enabled at system startup.
SNMP ifIndex
On Brocade IronWare devices, SNMP Management Information Base (MIB) uses Interface Index
(ifIndex) to assign a unique value to each port on a module or slot. The number of indexes that can be
assigned per module is 64. On all IronWare devices, the system automatically assign 64 indexes to
each module on the device. This value is not configurable.
NOTE
This feature is supported on FastIron X Series and ICX 6650 devices only.
You can enable SNMP to extract and display virtual routing interface statistics from the ifXTable (64-bit
counters).
The following describes the limitations of this feature:
• The Brocade device counts traffic from all virtual interfaces (VEs). For example, in a configuration
with two VLANs (VLAN 1 and VLAN 20) on port 1, when traffic is sent on VLAN 1, the counters (VE
statistics) increase for both VE 1 and VE 20.
• The counters include all traffic on each virtual interface, even if the virtual interface is disabled.
• The counters include traffic that is denied by ACLs or MAC address filters.
To enable SNMP to display VE statistics, enter the enable snmp ve-statistics command.
NOTE
The Privileged EXEC level is sometimes called the "Enable" level, because the command for accessing
this level is enable.
NOTE
Messages for accessing the User EXEC level apply only to access through Telnet. The device does
not authenticate initial access through serial connections but does authenticate serial access to the
Privileged EXEC level. Messages for accessing the Privileged EXEC level apply to access through the
serial connection or Telnet.
The following examples show login and logout messages for the User EXEC and Privileged EXEC
levels of the CLI.
NOTE
Network Time Protocol (NTP) commands must be configured on each individual device.
• NTP can operate in authenticate or non-authenticate mode. Only symmetric key authentication is
supported.
• By default, NTP operates in default VLAN and it can be changed.
Limitations
• FastIron devices cannot operate as primary time server (or stratum 1). It only serves as secondary
time server (stratum 2 to 15).
• NTP server and client cannot communicate using hostnames.
• NTP is not supported on VRF enabled interface.
• Autokey public key authentication is not supported.
• The NTP version 4 Extension fields are not supported. The packets containing the extension fields
are discarded.
• The NTP packets having control (6) or private (7) packet mode is not supported. NTP packets with
control and private modes will be discarded.
• On reboot or switchover, all the NTP state information will be lost and time synchronization will start
fresh.
• NTP multicast server/client and manycast functionalities are not supported.
• NTP versions 1 and 2 are not supported.
• NTP MIB is not supported.
the last day of a chosen month, so that second 23:59:58 of that date would be followed immediately by
second 00:00:00 of the following date.
Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap
seconds are irregularly spaced and unpredictable. Insertion of each UTC leap second is usually
decided about six months in advance by the International Earth Rotation and Reference Systems
Service (IERS), when needed to ensure that the difference between the UTC and UT1 readings will
never exceed 0.9 second.
NTP server
A NTP server will provide the correct network time on your device using the Network time protocol
(NTP). Network Time Protocol can be used to synchronize the time on devices across a network. A
NTP time server is used to obtain the correct time from a time source and adjust the local time in each
connecting device.
The NTP server functionality is enabled when you use the ntp command, provided SNTP configuration
is already removed.
When the NTP server is enabled, it will start listening on the NTP port for client requests and responds
with the reference time. Its stratum number will be the upstream time server's stratum + 1. The stratum
1 NTP server is the time server which is directly attached to the authoritative time source.
The device cannot be configured as primary time server with stratum 1. It can be configured as
secondary time server with stratum 2 to 15 to serve the time using the local clock.
The NTP server is stateless and will not maintain any NTP client information.
NOTE
Local time and time zone has to be configured before configuring the master command.
• The following scenarios are observed when the master command is not configured and the NTP
upstream servers are configured:
• If the synchronization with the NTP server/peer is active, the system clock is synchronized and the
reference time is the NTP time.
• If the NTP server/peer is configured but not reachable and if the local clock is valid, the server will
respond to client's request with the stratum number set to 16.
• If there is no NTP server/peer configured and if the local clock is valid, the server will respond to
client's request with the stratum number set to 16.
• If there is no NTP server/peer configured and if the local clock is invalid, the system clock is not
synchronized.
The following scenarios are observed when the master command is configured and the NTP upstream
servers are also configured:
• If the synchronization with the time server/peer is active, system clock is synchronized and the
reference time is the NTP time.If the NTP server/peer is configured but not reachable, the system
clock is synchronized. If the local time is valid then the reference time is the local clock time.
• If the NTP server/peer is not configured, the system clock is synchronized. If the local clock is valid,
then the reference time is the local clock time.
• If the NTP server/peer is not configured and the local clock is invalid, system clock is not
synchronized.
NOTE
Use the master command with caution. It is very easy to override valid time sources using this
command, especially if a low stratum number is configured. Configuring multiple machines in the same
network with the master command can cause instability in timekeeping if the machines do not agree on
the time.
NTP Client
An NTP client gets time responses from an NTP server or servers, and uses the information to calibrate
its clock. This consists of the client determining how far its clock is off and adjusting its time to match
that of the server. The maximum error is determined based on the round-trip time for the packet to be
received.
The NTP client can be enabled when we enter the ntp command and configure one or more NTP
servers/peers.
The NTP client maintains the server and peer state information as association. The server and peer
association is mobilized at the startup or whenever user configures. The statically configured server/
peer associations are not demobilized unless user removes the configuration. The symmetric passive
association is mobilized upon arrival of NTP packet from peer which is not statically configured. The
associations will be demobilized on error or time-out.
NTP peer
NTP peer mode is intended for configurations where a group of devices operate as mutual backups for
each other. If one of the devices loses a reference source, the time values can flow from the surviving
peers to all the others. Each device operates with one or more primary reference sources, such as a
radio clock, or a subset of reliable NTP secondary servers. When one of the devices lose all reference
sources or simply cease operation, the other peers automatically reconfigures so that time values can
flow from the surviving peers to others.
When the NTP server or peer is configured with burst mode, client will send burst of up to 8 NTP
packets in each polling interval. The burst number of packets in each interval increases as the polling
interval increases from minimum polling interval towards maximum interval.
The NTP peer can operate in:
• Symmetric Active-When the peer is configured using the peer command.
• Symmetric Passive-Dynamically learned upon arrival of a NTP packet from the peer which is not
configured. The symmetric passive association is removed on timeout or error.
The following scenarios are observed when the upstream server is not reachable after retries:
• If the NTP server/peer is configured and the master command is not configured, then the system
clock is synchronized. When the system clock is synchronized, the server will respond to client's
request with the stratum number set to +1. And when the system clock is unsynchronized, the
server will respond to client's request with the stratum number set to 16.
• If the NTP server/peer is configured and the master command is configured, then the system clock
is synchronized. When the system clock is synchronized, the reference time is the local clock time.
If the local clock is valid then the server will respond to client's request with the specified stratum
number if it is configured otherwise with the default stratum number.
The following scenarios are observed when you remove the last NTP server/peer under the conditions
- the NTP server/peer is configured, master command is not configured, system clock is synchronized
and the reference time is the NTP time:
• If the local clock is not valid, the system clock is not synchronized.
• If the local clock is valid, the system clock is synchronized and the reference time is the local clock.
The server will respond to the client's request with the specified stratum number if it is configured
otherwise with the default stratum number.
NOTE
To create a symmetric active association when a passive association is already formed, disable NTP,
configure peer association and then enable NTP again.
‐ NTP broadcast server is configured on the interface which is down even if the system clock
is synchronized and the local clock is valid.
‐ NTP broadcast server is configured on the interface which is up and no IP address is
configured for the broadcast subnet even if the system clock is synchronized and the local
clock is valid.
‐ NTP broadcast server is configured on the interface which is not present and no IP address
is configured for the broadcast subnet even if the system clock is synchronized and the local
clock is valid.
‐ NTP broadcast server without authentication key is configured on the interface which is up
and the IP address is configured for the broadcast subnet even when NTP authentication is
enforced and the system clock is synchronized and the local clock is valid.
NTP associations
Networking devices running NTP can be configured to operate in variety of association modes when
synchronizing time with reference time sources. A networking device can obtain time information on a
network in two ways-by polling host servers and by listening to NTP broadcasts. That is, there are two
types of associations-poll-based and broadcast-based.
mode is a peer-to-peer relationship, the host will also retain time-related information of the local
networking device that it is communicating with. When many mutually redundant servers are
interconnected via diverse network paths, the symmetric active mode should be used. Most stratum
1 and stratum 2 servers on the Internet adopt the symmetric active form of network setup. The
FastIron device operates in symmetric active mode, when the peer information is configured using
the peer command and specifying the address of the peer. The peer is also configured in symmetric
active mode in this way by specifying the FastIron device information. If the peer is not specifically
configured, a symmetric passive association is activated upon arrival of a symmetric active
message.
The specific mode that you should set for each of your networking devices depends primarily on the
role that you want them to assume as a timekeeping device (server or client) and the device's
proximity to a stratum 1 timekeeping server. A networking device engages in polling when it is
operating as a client or a host in the client mode or when it is acting as a peer in the symmetric
active mode. An exceedingly large number of ongoing and simultaneous polls on a system can
seriously impact the performance of a system or slow the performance of a given network. To avoid
having an excessive number of ongoing polls on a network, you should limit the number of direct,
peer-to-peer or client-to-server associations. Instead, you should consider using NTP broadcasts to
propagate time information within a localized network.
Synchronizing time
After the system peer is chosen, the system time is synchronized based on the time difference with
system peer:
• If the time difference with the system peer is 128 msec and < 1000 sec, the system clock is stepped
to the system peer reference time and the NTP state information is cleared.
Authentication
The time kept on a machine is a critical resource, so it is highly recommended to use the encrypted
authentication mechanism.
The NTP can be configured to provide cryptographic authentication of messages with the clients/
peers, and with its upstream time server. Symmetric key scheme is supported for authentication. The
scheme uses MD5 keyed hash algorithm.
The authentication can be enabled using the authenticate command. The set of symmetric key and
key string is specified using the authentication-key command.
If authentication is enabled, NTP packets not having a valid MAC address are dropped.
If the NTP server/peer is configured without authentication keys, the NTP request is not sent to the
configured server/peer.
NOTE
The same set or subset of key id and key string should be installed on all NTP devices.
Configuring NTP
NTP services are disabled on all interfaces by default.
Prerequisites:
• Before you begin to configure NTP, you must use the clock set command to set the time on your
device to within 1000 seconds of the coordinated Universal Time (UTC).
• Disable SNTP by removing all the SNTP configurations.
Enabling NTP
NTP and SNTP implementations cannot operate simultaneously. By default, SNTP is enabled. To
disable SNTP and enable NTP, use the ntp command in configuration mode. This command enables
the NTP client and server mode if SNTP is disabled.
Brocade(config)# ntp
Brocade(config-ntp)#
NOTE
The no ntp command removes all the configuration which are configured statistically and learned
associations from NTP neighbors.
NOTE
You cannot configure the ntp command if SNTP is enabled. If SNTP is enabled, configuring the ntp
command will display the following message:"SNTP is enabled. Disable SNTP before using NTP for
time synchronization"
Disabling NTP
To disable the NTP server and client mode, use the disable command in NTP configuration mode.
Disabling the NTP server or client mode will not remove the configurations.
Brocade(config-ntp)# disable
NOTE
The disable command disables the NTP server and client mode; it does not remove the NTP
configuration.
NOTE
If JITC is enabled, only the sha1 option is available.
The key-string option is the value of the MD5 or SHA1 key. The maximum length of the key string may
be defined up to 16 characters. Up to 32 keys may be defined.
NOTE
If the source-interface is not configured, then the lowest IP address in the outgoing interface will be
used in the NTP packets. Source IP address of a tunnel interface is not supported.
NOTE
The management interface is not part of any VLAN. When configuring the VLAN containment for NTP, it
will not use the management interface to send or receive the NTP packets.
Syntax: [no] server { ipv4-address | ipv6-address } [ version num ] [ key key-id ] [ minpoll interval ] [
maxpoll interval ] [ burst ]
The ipv4-address or ipv6-address parameter is the IP address of the server providing the clock
synchronization.
The version num option defines the Network Time Protocol (NTP) version number. Valid values are 3 or
4. If the num option is not specified, the default is 4.
The key key-id option defines the authentication key. By default, no authentication key is configured.
The minpoll interval option is the shortest polling interval. The range is from 4 through 17. Default is 6.
The interval argument is power of 2 (4=16s, 5=32s, 6=64s, 7=128s, 8=256s, 9=512s, and so on).
The maxpoll interval option is the longest polling interval. The range is 4 through 17. Default is 10. The
interval argument is calculated by the power of 2 (4=16s, 5=32s, 6=64s, 7=128s, 8=256s, 9=512s, and
so on).
The burst option sends a burst of packets to the server at each polling interval.
NOTE
This command is not effective, if the NTP is enabled in client-only mode.
NOTE
If the peer is a member of symmetric passive association, then configuring the peer command will fail.
Syntax: [no] peer { ipv4-address | ipv6-address } [ version num [ key key-id ] [ minpoll interval ] [
maxpoll interval ] [ burst ]
The ipv4-address or ipv6-address parameter is the IP address of the peer providing the clock
synchronization.
The version num option defines the Network Time Protocol (NTP) version number. Valid values are 3
and 4. If this option is not specified, then the default is 4.
The key key-id option defines the authentication key. By default, no authentication key is configured.
The minpoll interval option is the shortest polling interval. The range is from 4 through 17. Default is 6.
The interval argument is power of 2 (4=16s, 5=32s, 6=64s, 7=128s, 8=256s, 9=512s, and so on).
The maxpoll interval option is the longest polling interval. The range is 4 through 17. Default is 10. The
interval argument is calculated by the power of 2 (4=16s, 5=32s, 6=64s, 7=128s, 8=256s, 9=512s, and
so on).
The burst option sends a burst of packets to the peer at each polling interval.
NOTE
When the NTP server/peer is configured, the master command is not configured; on configuring the
clock set command the system clock is not synchronized. When the master command is configured,
on configuring the clock set command the system clock is synchronized and the reference time will be
the local clock.
To have active peers at both the ends, you need to disable NTP, configure the peers and enable the
NTP using the no disable command.
NOTE
The ntp-interface command is a mode change command, and will not be included in to the show run
output unless there is configuration below that interface.
NOTE
This command is not effective, if the NTP server is disabled.
Brocade(config)#int m1
Brocade(config-if-mgmt-1)#ip address 10.20.99.173/24
Brocade(config-if-mgmt-1)#ntp
Brocade(config-ntp)#ntp-interface m1
Brocade(config-ntp -mgmt-1)# broadcast destination 10.20.99.0 key 2
The following table provides descriptions of the show ntp status command output.
Field Description
stratum Indicates the stratum number that this system is operating. Range 2..15.
reference IPv4 address or first 32 bits of the MD5 hash of the IPv6 address of the peer to which clock
is synchronized.
root delay Total delay (in milliseconds) along path to root clock.
Field Description
last update Time the router last updated its NTP information.
server mode Status of the NTP server mode for this device.
client mode Status of the NTP client mode for this device.
master stratum Stratum number that will be used by this device when master is enabled and no upstream
time servers are accessible.
The following table provides descriptions of the show ntp associations command output.
Field Description
* The peer has been declared the system peer and lends its variables to the system variables.
ref clock IPv4 address or first 32 bits of the MD5 hash of the IPv6 address of the peer to which clock is
synchronized.
Field Description
when Time, in seconds, since last NTP packet was received from peer.
offset Relative time difference between a peer clock and a local clock, in milliseconds.
disp Dispersion.
Use the show ntp associations detail command with the appropriate parameters to display the NTP
servers and peers association information for a specific IP address.
Field Description
ref ID IPv4 address or hash of IPv6 address of the upstream time server to which the peer is
synchronized.
Time Last time stamp that the peer received from its master.
root delay The delay along path to root (the final stratum 1 time source).
Field Description
Configuration Examples
The following sections list configuration examples to configure the Brocade device.
Brocade(config-ntp)# authenticate
Brocade(config-ntp)# authentication-key key-id 1 md5 key123
Brocade(config-ntp)# server 10.1.2.4 key 1
Brocade(config)#int management 1
Brocade(config-if-mgmt-1)#ip address 10.20.99.173/24
Brocade(config-if-mgmt-1)#ntp
Brocade(config-ntp)# ntp-interface management 1
Brocade(config-ntp-mgmt-1)# broadcast destination 10.23.45.128
Brocade(config-ntp)# ntp-interface ethernet 1/3
Brocade(config-ntp-if-e1000-1/3)# broadcast destination 10.1.1.0 key 1
Brocade(config-ntp)# ntp-interface ve 100
Brocade(config-ntp-ve-100)# broadcast destination 10.2.2.0 key 23
The management port number is always 1. This example shows how to specify the management port:
ICX 6610
The management port number is always 1. This example shows how to specify the management port:
FCX
The management port number is always 1. This example shows how to specify the management port:
FSX
The management port number is always 1. This example shows how to specify the management port:
NOTE
Stacking is not supported on FSX devices.
Syntax: show interface brief [ wide ] [ ethernet stack-unit/slot/port | loopback port | management
port | slot port | tunnel port | ve port ]
The ethernet stack-unit/slot/port parameter specifies the Ethernet port for which you want to display the
interface information.
The loopback option specifies the loopback port for which you want to display the interface information.
The management option specifies the management port for which you want to display the interface
information.
The slot option specifies all the ports in a slot for which you want to display the interface information.
The tunnel option specifies the tunnel port for which you want to display the interface information.
The ve option specifies the virtual routing (VE) port for which you want to display the interface
information.
The following table describes the output parameters of the show interface brief wide command.
Field Description
To display the complete port name for an Ethernet interface, enter a command such as the following.
PPort Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/23 Up Forward Full 1G None No 1 0 748e.f82d.7a16
connected- to-FCX
NOTE
You can modify the port speed of copper ports only; this feature does not apply to fiber ports.
NOTE
For optimal link operation, copper ports on devices that do not support 803.3u must be configured with
like parameters, such as speed (10,100,1000), duplex (half, full), MDI/MDIX, and Flow Control.
The following commands change the port speed of copper interface 8 on a FastIron device from the
default of 10/100/1000 auto-sense, to 100 Mbps operating in full-duplex mode.
NOTE
On Brocade ICX 7450 and Brocade ICX 7250-24G, the command options 10-half and 100-half are
not supported on 1G fiber ports with mini-GBIC (SFPs) for copper.
NOTE
On FastIron devices, when setting the speed and duplex-mode of an interface to 1000-full, configure
one side of the link as master (1000-full-master) and the other side as slave (1000-full-slave).
NOTE
On Brocade ICX 6610 and ICX 6650 devices, after you remove the 10 Gbps speed from the running
configuration, plugging in a 1Gbps optic SFP transceiver into a 10 Gbps port causes the software to fail
to revert the ports back from the default 10Gbps mode to the 1 Gbps speed. Remove the 1Gbps SFP
transceiver and plug in the 10Gbps optic SFP+transceiver so that the devices go into the default 10
Gbps mode.
NOTE
When you use fixed speed and duplex configuration, you should use the non-auto MDI-MDIX
configuration.
NOTE
For optimal link operation, link ports on devices that do not support 802.3u must be configured with like
parameters, such as speed (10,100,1000), duplex (half, full), MDI/MDIX, and Flow Control.
Maximum Port speed advertisement is an enhancement to the auto-negotiation feature, a mechanism
for accommodating multi-speed network devices by automatically configuring the highest performance
mode of inter-operation between two connected devices.
Port speed down-shift enables Gbps copper ports on the Brocade device to establish a link at 1000.
Mbps over a 4-pair wire when possible, or to down-shift to 100 Mbps if the medium is a 2-pair wire.
Maximum port speed advertisement enables you to configure an auto-negotiation maximum speed that
Gbps copper ports on the Brocade device will advertise to the connected device. You can configure a
port to advertise a maximum speed of either 100 Mbps or 10 Mbps. When the maximum port speed
advertisement feature is configured on a port that is operating at 100 Mbps maximum speed, the port
will advertise 10/100 Mbps capability to the connected device. Similarly, if a port is configured at 10
Mbps maximum speed, the port will advertise 10 Mbps capability to the connected device.
The maximum port speed and down-shift advertisement features operate dynamically at the physical
link layer between two connected network devices. They examine the cabling conditions and the
physical capabilities of the remote link, then configure the speed of the link segment according to the
highest physical-layer technology that both devices can accommodate.
The maximum port speed and down-shift advertisement features operate independently of logical
trunk group configurations. Although Brocade recommends that you use the same cable types and
auto-negotiation configuration on all members of a trunk group, you could utilize the auto-negotiation
features conducive to your cabling environment. For example, in certain circumstances, you could
configure each port in a trunk group to have its own auto-negotiation maximum port speed
advertisement or port speed down-shift configuration.
NOTE
This is not supported in ICX devices.
To configure a maximum port speed advertisement of 10 Mbps on a port that has auto-negotiation
enabled, enter a command such as the following at the Global CONFIG level of the CLI.
device(config)
# link-config gig copper autoneg-control 10m ethernet 1
To configure a maximum port speed advertisement of 100 Mbps on a port that has auto-negotiation
enabled, enter the following command at the Global CONFIG level of the CLI.
device(config)
# link-config gig copper autoneg-control 100m ethernet 2
Syntax: [no] link-config gig copperautoneg-control [ 10m | 100m ] ethernet port [ ethernet port ]
You can enable maximum port speed advertisement on one or two ports at a time.
To disable maximum port speed advertisement after it has been enabled, enter the no form of the
command.
For example, to configure down-shift on ports 0/1/1 to 0/1/10 and 0/1/15 to 0/1/20 on the device, enter
the following.
Brocade(config)# link-config gig copper autoneg-control down-shift ethernet 0/1/1
to 0/1/10 ethernet 0/1/15 to 0/1/20
NOTE
The <port-list> variable represents the list of ports to which the command will be applied.
To disable selective auto-negotiation of 100m-auto on ports 0/1/21 to 0/1/25 and 0/1/30, enter the
following.
Brocade(config)# no link-config gig copper autoneg-control 100m-auto ethernet
0/1/21 to 0/1/25 ethernet 0/1/30
The above command configures Gbps copper ports 1 and 2 to establish a link at 1000 Mbps over a
4-pair wire when possible, or to down-shift (reduce the speed) to 100 Mbps when the medium is a
2-pair wire.
Syntax: [no] link-config gig copperautoneg-control down-shift ethernet port [ ethernet port ]
to port
2. Specify the port variable in one of the following formats:
• FWS and FCX stackable switches – <stack-unit/slotnum/portnum>
• FSX 800 and FSX 1600 chassis devices – <slotnum/portnum>
• FESX compact switches – <portnum>
NOTE
To list all of the ports individually, use the keyword in order to specify ranges of ports, or a
combination of both. You can enable port speed down-shift on one or two ports at a time.
3. To disable port speed down-shift, enter the no form of the command.
NOTE
You can modify the port duplex mode of copper ports only. This feature does not apply to fiber ports.
Port duplex mode and port speed are modified by the same command.
device(config)
# interface ethernet 8
device(config-if-e1000-8)# speed-duplex 10-full
NOTE
On Brocade ICX 7450 and Brocade ICX 7250-24G, the command options 10-half and 100-half are not
supported on 1G fiber ports with mini-GBIC (SFPs) for copper.
To turn off automatic MDI/MDIX detection and define a port as an MDIX only port.
To turn on automatic MDI/MDIX detection on a port that was previously set as an MDI or MDIX port.
device(config)
# interface ethernet 8
device(config-if-e1000-8)# disable
You also can disable or re-enable a virtual interface. To do so, enter commands such as the following.
device(config)
# interface ve v1
device(config-vif-1)# disable
Syntax: disable
To re-enable a virtual interface, enter the enable command at the Interface configuration level. For
example, to re-enable virtual interface v1, enter the enable command.
device(config-vif-1)# enable
Syntax: enable
NOTE
You must save the configuration and reload for the change to take effect. See the description of the
store-and-forward command in the FastIron Command Reference for more information.
device(config)# no flow-control
device(config)# flow-control
NOTE
For optimal link operation, link ports on devices that do not support 803.3u must be configured with like
parameters, such as speed (10,100,1000), duplex (half, full), MDI/MDIX, and Flow Control.
device(config)
# interface ethernet 0/1/21
device(config-if-e1000-0/1/21)# no flow-control
NOTE
The port up/down time is required only for physical ports and not for loopback/ ve/ tunnel ports.
Issuing the show interface command with the appropriate parameters on a FSX device displays the
following output:
The line highlighted in bold will resemble one of the following, depending on the configuration:
• If flow control negotiation is enabled (and a neighbor advertises "Pause-Not Capable"), the display
shows:
• If flow control negotiation is enabled (and a neighbor advertises "Pause-Capable"), the display
shows:
• If flow control is enabled, and flow control negotiation is disabled, the display shows:
Limit when Jumbo disabled / % of buffer limit Limit when Jumbo enabled / % of buffer limit
1G ports
10G ports
40G ports
If necessary, you can change the total buffer limits and the XON and XOFF default thresholds. Refer
to Changing the total buffer limits on page 70 and Changing the XON and XOFF thresholds on page
69, respectively.
• To use this feature, 802.3x flow control must be enabled globally and per interface on FCX and ICX
devices. By default, 802.3x flow control is enabled, but can be disabled with the no flow-control
command.
• The following QoS features are not supported together with symmetric flow control:
‐ Dynamic buffer allocation (CLI commands qd-descriptor and qd-buffer )
‐ Buffer profiles (CLI command buffer-profile port-region )
‐ DSCP-based QoS (CLI command trust dscp )
NOTE
Although the above QoS features are not supported with symmetric flow control, the CLI will still accept
these commands. The last command issued will be the one placed into effect on the device. For
example, if trust dscp is enabled after symmetric-flow-control is enabled, symmetric flow control will
be disabled and trust dscp will be placed into effect. Make sure you do not enable incompatible QoS
features when symmetric flow control is enabled on the device.
• Head of Line (HOL) blocking may occur when symmetric flow control is enabled. This means that a
peer can stop transmitting traffic streams unrelated to the congestion stream.
To enable symmetric flow control globally on all full-duplex data ports of a particular unit in a traditional
stack, enter the symmetric-flow-control enable command with the appropriate paramters.
To change the thresholds for all 10G ports, enter a command such as the following.
In the above configuration examples, when the XOFF limit of 91% is reached or exceeded, the Brocade
device will send PAUSE frames to the sender telling it to stop transmitting data temporarily. When the
XON limit of 75% is reached, the Brocade device will send PAUSE frames to the sender telling it to
resume sending data.
Syntax: symmetric-flow-control set { 1 | 2 } xoff % xon %
symmetric-flow-control set 1 sets the XOFF and XON limits for 1G ports.
symmetric-flow-control set 2 sets the XOFF and XON limits for 10G ports.
For xoff % , the % minimum value is 60% and the maximum value is 95%.
For xon % , the % minimum value is 50% and the maximum value is 90%.
Use the show symmetric command to view the default or configured XON and XOFF thresholds.
Refer to Displaying symmetric flow control status on page 70.
To change the total buffer limit for all 10G ports, enter a command such as the following.
NOTE
Higher settings give better tolerance for clock differences with the partner phy, but may marginally
increase latency as well.
• When you enter a value for IPG, the device applies the closest valid IPG value for the port mode to
the interface. For example, if you specify 120 for a 1 Gbps Ethernet port in 1 Gbps mode, the device
assigns 112 as the closest valid IPG value to program into hardware.
10/100M mode
To configure IPG on a Gbps Ethernet port for 10/100M mode, enter the following command.
1G mode
To configure IPG on a Gbps Ethernet port for 1-Gbps Ethernet mode, enter commands such as the
following.
For multiple interface levels, to configure IPG for ports 0/1/11 and 0/1/14 through 0/1/17, enter the
following commands.
device(config-if-e1000-11)# 100-tx
After the link is up, it will be in 100M/full-duplex mode, as shown in the following example.
The show media command will display the SFP transceiver as 1G M-TX .
Syntax: [no] 100-tx
To disable support, enter the no form of the command.
NOTE
The following procedure applies to Stackable devices and to Chassis-based 100/1000 Fiber interface
modules only. The CLI syntax for enabling and disabling 100BaseFX support on these devices differs
than on a Compact device. Make sure you refer to the appropriate procedures. These are not
supported on ICX 6430 and ICX 6450 devices.
NOTE
Connect the 100BaseFX fiber transceiver after configuring both sides of the link. Otherwise, the link
could become unstable, fluctuating between up and down states.
To enable support for 100BaseFX on an FSX fiber port or on a Stackable switch, enter commands
such as the following.
To disable 100BaseFX support on a fiber port, enter the no form of the command. Note that you must
disable 100BaseFX support before inserting a different type of module In the same port. Otherwise, the
device will not recognize traffic traversing the port.
NOTE
Gbps negotiation is not supported on ICX 6430, ICX 6450, and ICX 6650devices.
• Negotiate-full-auto - The port first tries to perform a handshake with the other port to exchange
capability information. If the other port does not respond to the handshake attempt, the port uses the
manually configured configuration information (or the defaults if an administrator has not set the
information). This is the default.
• Auto-Gbps - The port tries to perform a handshake with the other port to exchange capability
information.
• Negotiation-off - The port does not try to perform a handshake. Instead, the port uses configuration
information manually configured by an administrator.
To change the mode for individual ports, enter commands such as the following.
device(config)
# interface ethernet 1 to 4
device(config-mif-1-4)# gig-default auto-gig
This command overrides the global setting and sets the negotiation mode to auto-Gbps for ports 1 - 4.
Syntax: gig-default{ neg-full-auto | auto-gig | neg-off ]
NOTE
When Gbps negotiation mode is turned off (CLI command gig-default neg-off ), the Brocade device
may inadvertently take down both ends of a link. This is a hardware limitation for which there is currently
no workaround.
When the Brocade device receives the VoIP phone query, it sends the voice VLAN ID in a reply
packet back to the VoIP phone. The VoIP phone then configures itself within the voice VLAN.
As long as the port to which the VoIP phone is connected has a voice VLAN ID, the phone will
configure itself into that voice VLAN. If you change the voice VLAN ID, the software will immediately
send the new ID to the VoIP phone, and the VoIP phone will re-configure itself with the new voice
VLAN.
device(config)
# interface ethernet 2
device(config-if-e1000-2)# voice-vlan 1001
To create a voice VLAN ID for a group of ports, enter commands such as the following.
device(config)
# interface ethernet 1-8
device(config-mif-1-8)# voice-vlan 1001
The following example shows the message that appears when the port does not have a configured
voice VLAN.
To view the voice VLAN for all ports, use the show voice-vlan command. The following example shows
the command output results.
Use the show link-error-disable all command to display the ports with the port flap dampening
feature enabled.
For FastIron Stackabledevices, the output of the command shows the following.
For FastIron X Series devices, the output of the command shows the following.
Displaying ports configured with port flap dampening defines the port flap dampening statistics
displayed by the show link-error-disable all command.
Column Description
Threshold The number of times the port link state will go from up to down and down to up before the wait
period is activated.
Sampling-Time The number of seconds during which the specified toggle threshold can occur before the wait
period is activated.
Shutoff-Time The number of seconds the port will remain disabled (down) before it becomes enabled. A zero (0)
indicates that the port will stay down until an administrative override occurs.
• Idle - The link is normal and no link state toggles have been detected or sampled.
• Down - The port is disabled because the number of sampled errors exceeded the configured
threshold.
• Err - The port sampled one or more errors.
The line "Link Error Dampening" displays "Enabled" if port flap dampening is enabled on the port or
"Disabled" if the feature is disabled on the port. The feature is enabled on the ports in the two examples
above. Also, the characters "ERR-DISABLED" is displayed for the "GbpsEthernet" line if the port is
disabled because of link errors.
Syntax: show interface ethernet port-number
In addition to the show commands above, the output of the show interface brief command for FastIron
X Series indicates if a port is down due to link errors.
The ERR-DIS entry under the "Link" column indicates the port is down due to link errors.
NOTE
If a port name is longer than five characters, the port name is truncated in the output of the show
interface brief command.
• If the wait time (port is down) expires and the port is brought up the following Syslog message is
displayed.
NOTE
Brocade recommends that you limit the use of Loose Mode. If you have a large number of VLANS,
configuring loop detection on all of them can significantly affect system performance because of the
flooding of test packets to all configured VLANs. An alternative to configuring loop detection in a VLAN-
group of many VLANs is to configure a separate VLAN with the same tagged port and configuration,
and enable loop detection on this VLAN only.
NOTE
When loop detection is used with Layer 2 loop prevention protocols, such as spanning tree (STP), the
Layer 2 protocol takes higher priority. Loop detection cannot send or receive probe packets if ports are
blocked by Layer 2 protocols, so it does not detect Layer 2 loops when STP is running because loops
within a VLAN have been prevented by STP. Loop detection running in Loose Mode can detect and
break Layer 3 loops because STP cannot prevent loops across different VLANs. In these instances, the
ports are not blocked and loop detection is able to send out probe packets in one VLAN and receive
packets in another VLAN. In this way, loop detection running in Loose Mode disables both ingress and
egress ports.
device(config)# vlan20
device(config-vlan-20)# loop-detection
By default, the port will send test packets every one second, or the number of seconds specified by the
loop-detection-interval command. Refer to Configuring a global loop detection interval on page 81.
Syntax: [no] loop-detection
Use the [no] form of the command to disable loop detection.
device(config)# loop-detection-interval 50
To revert to the default global loop detection interval of 10, enter one of the following.
device(config)# loop-detection-interval 10
OR
device(config)# no loop-detection-interval 50
The above command will cause the Brocade device to automatically re-enable ports that were
disabled because of a loop detection. By default, the device will wait 300 seconds before re-enabling
the ports. You can optionally change this interval to a value from 10 to 65535 seconds. Refer to
Specifying the recovery time interval on page 82.
Syntax: [no] errdisable recovery cause loop-detection
Use the [no] form of the command to disable this feature.
The above command configures the device to wait 120 seconds (2 minutes) before re-enabling the
ports.
To revert back to the default recovery time interval of 300 seconds (5 minutes), enter one of the
following commands.
OR
Clearing loop-detection
To clear loop detection statistics and re-enable all ports that are in Err-Disable state because of a loop
detection, enter the clear loop-detection command.
If a port is errdisabled in Strict mode, it shows "ERR-DISABLE by itself". If it is errdisabled due to its
associated vlan, it shows "ERR-DISABLE by vlan ?"
The following command displays the current disabled ports, including the cause and the time.
This example shows the disabled ports, the cause, and the time the port was disabled. If loop-detection
is configured on a physical port, the disable cause will show "itself". For VLANs configured for loop-
detection, the cause will be a VLAN.
The following command shows the hardware and software resources being used by the loop-detection
feature.
Field Description
In prior FastIron releases, when a loop detection probe packet was received back on an interface, the
corresponding interface would be shut down either permanently or for a specific duration configured by
the user. The new shut down prevention for loop-detection functionality allows users to disable the
shutdown of a port when the loop detection probe packet is received on an interface. This provides
control over deciding which port is allowed to enter into an error-disabled state and go into a shutdown
state when a loop is detected. This function can also be used as a test tool to detect Layer 2 and Layer
3 loops in network current data packet flow.
Limitations of shutdown prevention for loop-detection
Shutdown prevention for loop-detection does not allow any corrective action to be taken on the loop.
There could be network instability due to the presence of network loops, if adequate corrective
measures are not taken by the network administrator.
To enable shutdown prevention for loop detection, follow these steps.
1. Enter global configuration mode.
2. Specify the interface on which you would like to enable the loop-detection shutdown-disable
command.
3. Enter the loop-detection shutdown-disable command.
Brocade (config)# interface ethe 1/7
Brocade (config-if-e1000-1/7)# loop-detection shutdown-disable
You can raise a periodic syslog that provides information about loops in the network. When a loop is
detected because of a loop detection protocol data unit (PDU), on a loop detection shutdown-disabled
interface, the interface will never be put into an error-disabled state, but it will generate a periodic log
message indicating that the interface is in the shutdown-disabled mode. The periodic syslog is by
default generated at an interval of five minutes. You can change this interval as required.
You can globally specify the interval at which the loop-detection syslog message is generated if the
loop detection shutdown-disable command is configured on the port. This configuration applies to all
the ports that have shutdown prevention for loop detection configured.
During a log interval duration window, a log message will be displayed for the first loop detection PDU
received on the interface. This means that there will be only one log message per port in an interval
window.
To configure the periodic log message generation for shutdown prevention, follow these steps.
1. Enter global configuration mode.
2. Enter the loop-detection syslog-interval <num> command.
The following command will set the syslog-interval to 1 hr.
Brocade (config)# loop-detection-syslog-interval 60
<14>0d01h38m44s:<product type>: port <port-num> detect loop, ignoring shut down event in
shutdown-disable mode.
For example, to display the message “Welcome to FESX!” when a Telnet CLI session is established.
Brocade(config)# banner motd $ (Press Return)
Enter TEXT message, End with the character '$'.
Welcome to FESX! $
A delimiting character is established on the first line of the banner motd command. You begin and end
the message with this delimiting character. The delimiting character can be any character except
“ (double-quotation mark) and cannot appear in the banner text. In this example, the delimiting
character is $ (dollar sign). The text in between the dollar signs is the contents of the banner. The
banner text can be up to 4000 characters long, which can consist of multiple lines.
Syntax: [no] banner motd delimiting-character
To remove the banner, enter the no banner motd command.
NOTE
The banner delimiting-character command is equivalent to the banner motd delimiting-character
command.
When you access the Web Management Interface, the banner is displayed.
NOTE
If you are using a Web client to view the message of the day, and your banners are very wide, with
large borders, you may need to set your PC display resolution to a number greater than the width of
your banner. For example, if your banner is 100 characters wide and the display is set to 80 characters,
the banner may distort, or wrap, and be difficult to read. If you set your display resolution to 120
characters, the banner will display correctly.
Requiring users to press the Enter key after the message of the day
banner
In earlier IronWare software releases, users were required to press the Enter key after the Message of
the Day (MOTD) was displayed, prior to logging in to the Brocade device on a console or from a Telnet
session.
Now, this requirement is disabled by default. Unless configured, users do not have to press Enter after
the MOTD banner is displayed.
For example, if the MOTD "Authorized Access Only" is configured, by default, the following messages
are displayed when a user tries to access the Brocade device from a Telnet session.
Authorized Access Only ...
Username:
The user must press the Enter key before the login prompt is displayed.
Also, on the console, the following messages are displayed if the requirement to press the Enter key is
disabled.
Press Enter key to login
Authorized Access Only ...
User Access Verification
Please Enter Login Name:
However, if the requirement to press the Enter key after a MOTD is enabled, the following messages
are displayed when accessing the switch on the console.
Press Enter key to login
Authorized Access Only ...
Press <Enter> to accept and continue the login process....
The user must press the Enter key to continue to the login prompt.
To enable the requirement to press the Enter key after the MOTD is displayed, enter a command such
as the following.
Brocade(config)# banner motd require-enter-key
Example
You can configure the Brocade device to display a message when a user enters the
Privileged EXEC CLI level.
As with the banner motd command, you begin and end the message with a
delimiting character; in this example, the delimiting character is #(pound sign).
The delimiting character can be any character except “ (double-quotation mark)
and cannot appear in the banner text. The text in between the pound signs is
the contents of the banner. Banner text can be up to 4000 characters, which
can consist of multiple lines.
This message indicates where the user is connecting from and displays a configurable text message.
Brocade(config)# banner incoming $ (Press Return)
Enter TEXT message, End with the character '$'.
Incoming Telnet Session!! $
When a user connects to the CLI using Telnet, the following message appears on the Console.
Telnet from 209.157.22.63
Incoming Telnet Session!!
As with the banner motd command, you begin and end the message with a delimiting character; in
this example, the delimiting character is $(dollar sign). The delimiting character can be any character
except “ (double-quotation mark) and cannot appear in the banner text. The text in between the dollar
signs is the contents of the banner. Banner text can be up to 4000 characters, which can consist of
multiple lines.
Syntax: [no] banner incoming delimiting-character
To remove the banner, enter the no banner incoming command.
● OAM Overview................................................................................................................ 89
● Software versions installed and running on a device...................................................... 90
● Software Image file types................................................................................................93
● Flash timeout...................................................................................................................94
● Software upgrades.......................................................................................................... 94
● Boot code synchronization feature..................................................................................95
● Viewing the contents of flash files................................................................................... 95
● Using SNMP to upgrade software...................................................................................96
● Software reboot...............................................................................................................97
● Displaying the boot preference....................................................................................... 98
● Loading and saving configuration files............................................................................ 99
● Loading and saving configuration files with IPv6.......................................................... 103
● System reload scheduling............................................................................................. 109
● Diagnostic error codes and remedies for TFTP transfers............................................. 110
● Network connectivity testing..........................................................................................112
● IEEE 802.3ah EFM-OAM.............................................................................................. 114
● Hitless management on the FSX 800 and FSX 1600................................................... 122
● Displaying management redundancy information ........................................................ 132
● Layer 3 hitless route purge ...........................................................................................133
● Energy Efficient Ethernet.............................................................................................. 134
● Histogram information overview....................................................................................135
● External USB Hotplug................................................................................................... 136
● Commands....................................................................................................................137
OAM Overview
For easy software image management, all Brocade devices support the download and upload of
software images between the flash modules on the devices and a Trivial File Transfer Protocol (TFTP)
server on the network.
Brocade devices have two flash memory modules:
• Primary flash - The default local storage device for image files and configuration files.
• Secondary flash - A second flash storage device. You can use the secondary flash to store
redundant images for additional booting reliability or to preserve one software image while testing
another one.
Only one flash device is active at a time. By default, the primary image will become active upon reload.
You can update the software contained on a flash module using TFTP to copy the update image from a
TFTP server onto the flash module. In addition, you can copy software images and configuration files
from a flash module to a TFTP server.
NOTE
Brocade devices are TFTP clients but not TFTP servers. You must perform the TFTP transaction from
the Brocade device. You cannot "put" a file onto the Brocade device using the interface of your TFTP
server.
NOTE
If you are attempting to transfer a file using TFTP but have received an error message, refer to
Diagnostic error codes and remedies for TFTP transfers on page 110.
Compact devices
To determine the flash image version running on a Compact device, enter the show version
command at any level of the CLI. The following shows an example output.
device#show version
Copyright (c) 1996-2012 Brocade Communications Systems, Inc. All rights reserved.
UNIT 1: compiled on Mar 2 2012 at 12:38:17 labeled as ICX64S07400
(10360844 bytes) from Primary ICX64S07400.bin
SW: Version 07.4.00T311
Boot-Monitor Image size = 774980, Version:07.4.00T310 (kxz07400)
HW: Stackable ICX6450-24
==========================================================================
UNIT 1: SL 1: ICX6450-24 24-port Management Module
Serial #: BZSxxxxxxxx
License: BASE_SOFT_PACKAGE (LID: dbuFJJHiFFi)
P-ENGINE 0: type DEF0, rev 01
==========================================================================
UNIT 1: SL 2: ICX6450-SFP-Plus 4port 40G Module
==========================================================================
800 MHz ARM processor ARMv5TE, 400 MHz bus
65536 KB flash memory
512 MB DRAM
STACKID 1 system uptime is 3 minutes 39 seconds
The system : started=warm start reloaded=by "reload"
device#show version
==========================================================================
Active Management CPU [Slot-9]:
SW: Version 07.4.00T3e3 Copyright (c) 1996-2012 Brocade Communications Systems,
Inc. All rights reserved.
Compiled on Mar 02 2012 at 11:54:29 labeled as SXR07400
(4585331 bytes) Primary /GA/SXR07400.bin
BootROM: Version 07.2.00T3e5 (FEv2)
Chassis Serial #: Bxxxxxxxxx
License: SX_V6_HW_ROUTER_IPv6_SOFT_PACKAGE (LID: yGFJGOiFLd)
HW: Chassis FastIron SX 800-PREM6 (PROM-TYPE SX-FIL3U-6-IPV6)
==========================================================================
Standby Management CPU [Slot-10]:
SW: Version 07.4.00T3e3 Copyright (c) 1996-2012 Brocade Communications Systems,
Inc. All rights reserved.
Compiled on Mar 02 2012 at 11:54:29 labeled as SXR07400
BootROM: Version 07.2.00T3e5 (FEv2)
HW: Chassis FastIron SX 800-PREM6 (PROM-TYPE SX-FIL3U-6-IPV6)
==========================================================================
SL 1: SX-FI-8XG 8-port 10G Fiber
Serial #: BQKxxxxxxxx
P-ASIC 0: type C341, rev 00 subrev 00
==========================================================================
SL 2: SX-FI-24GPP 24-port Gig Copper + PoE+
Serial #: BTUxxxxxxxx
P-ASIC 2: type C300, rev 00 subrev 00
==========================================================================
SL 8: SX-FI-48GPP 48-port Gig Copper + PoE+
Serial #: BFVxxxxxxxx
P-ASIC 14: type C300, rev 00 subrev 00
==========================================================================
SL 9: SX-FIZMR6 0-port Management
Serial #: Wxxxxxxxxx
License: SX_V6_HW_ROUTER_IPv6_SOFT_PACKAGE (LID: yGFJGOiFLd)
==========================================================================
SL 10: SX-FIZMR6 0-port Management
Serial #: Wxxxxxxxxx
License: SX_V6_HW_ROUTER_IPv6_SOFT_PACKAGE (LID: ÿÿÿÿÿÿÿÿÿÿ)
==========================================================================
Active Management Module:
660 MHz Power PC processor 8541 (version 0020/0020) 66 MHz bus
512 KB boot flash memory
16384 KB code flash memory
512 MB DRAM
Standby Management Module:
660 MHz Power PC processor 8541 (version 0020/0020) 66 MHz bus
512 KB boot flash memory
16384 KB code flash memory
512 MB DRAM
The system uptime is 1 minutes 2 seconds
The system : started=warm start reloaded=by "reload"
device#show flash
Active Management Module (Slot 9):
Compressed Pri Code size = 3613675, Version 03.1.00aT3e3 (sxr03100a.bin)
Compressed Sec Code size = 2250218, Version 03.1.00aT3e1 (sxs03100a.bin)
Compressed BootROM Code size = 524288, Version 03.0.01T3e5
Code Flash Free Space = 9699328
Standby Management Module (Slot 10):
Compressed Pri Code size = 3613675, Version 03.1.00aT3e3 (sxr03100a.bin)
Compressed Sec Code size = 2250218, Version 03.1.00aT3e1 (sxs03100a.bin)
Compressed BootROM Code size = 524288, Version 03.0.01T3e5
Code Flash Free Space = 524288
NOTE
To minimize the boot-monitor image size on FastIron devices, the ping and tftp operations performed
in the boot-monitor mode are restricted to copper ports on the FastIron Chassis management modules
and to the out-of-band management port on the FastIron stackable switches. The other copper or fiber
ports on these devices do not have the ability to ping or tftp from the boot-monitor mode.
To generate a SHA-1 hash value for the secondary image, enter the following command.
To generate a CRC32 hash value for the secondary image, enter the following command.
To verify the hash value of a secondary image with a known value, enter the following commands.
In the previous example, the codes did not match, and verification failed. If verification succeeds, the
output will look like this.
The following examples show this process for SHA-1 and CRC32 algorithms.
and
NOTE
The boot images are applicable to the listed devices only and are not interchangeable. For example,
you cannot load FCX boot or flash images on an FSX device, and vice versa.
Flash timeout
The operations that require access to the flash device are expected to be completed within the default
flash timeout value of 12 minutes.
If the operations exceed the timeout value, the flash device will be locked and further flash operations
cannot be processed. To facilitate prolonged flash operations without the device being locked, you can
manually configure the flash timeout for a longer duration using the flash-timeout command. You can
configure the flash timeout to a value from 12 through 60 minutes. The new timeout value is applicable
for all flash operations and will be effective from the next flash operation.
Software upgrades
For instructions about upgrading the software, refer to the FastIron Ethernet Switch Software Upgrade
Guide.
NOTE
There is currently no option for manual synchronization of the boot image.
To activate the boot synchronization process, enter the following command.
device#show dir
133 [38f4] boot-parameter
0 [ffff] bootrom
3802772 [0000] primary
4867691 [0000] secondary
163 [dd8e] stacking.boot
1773 [0d2d] startup-config
1808 [acfa] startup-config.backup
8674340 bytes 7 File(s)
56492032 bytes free
F 641 startup-config.txt
F 391 stacking.boot
F 76942 debug.boot
F 638 startup-config.backup
F 0 startup-config.no
NOTE
The syntax shown in this section assumes that you have installed HP OpenView in the "/usr" directory.
NOTE
Brocade recommends that you make a backup copy of the startup-config file before you upgrade the
software. If you need to run an older release, you will need to use the backup copy of the startup-config
file.
1. Configure a read-write community string on the Brocade device, if one is not already configured. To
configure a read-write community string, enter the following command from the global CONFIG level
of the CLI.snmp-server community string ro | rw where string is the community string and can be
up to 32 characters long.
2. On the Brocade device, enter the following command from the global CONFIG level of the CLI.
no snmp-server pw-check
This command disables password checking for SNMP set requests. If a third-party SNMP
management application does not add a password to the password field when it sends SNMP set
requests to a Brocade device, by default the Brocade device rejects the request.
3. From the command prompt in the UNIX shell, enter the following command.
/usr/OV/bin/snmpset -c rw-community-string brcd-ip-addr 1.3.6.1.4.1.1991.1.1.2.1.5.0 ipaddress
tftp-ip-addr 1.3.6.1.4.1.1991.1.1.2.1.6.0 octetstringascii file-name 1.3.6.1.4.1.1991.1.1.2.1.7.0
integer command-integer
where
rw-community-string is a read-write community string configured on the Brocade device.
brcd-ip-addr is the IP address of the Brocade device.
tftp-ip-addr is the TFTP server IP address.
file-name is the image file name.
command-integer is one of the following.
20 - Download the flash code into the primary flash area.
22 - Download the flash code into the secondary flash area.
Software reboot
You can use boot commands to immediately initiate software boots from a software image stored in
primary or secondary flash on a Brocade device or from a BootP or TFTP server. You can test new
versions of code on a Brocade device or choose the preferred boot source from the console boot
prompt without requiring a system reset.
NOTE
It is very important that you verify a successful TFTP transfer of the boot code before you reset the
system. If the boot code is not transferred successfully but you try to reset the system, the system will
not have the boot code with which to successfully boot.
By default, the Brocade device first attempts to boot from the image stored in its primary flash, then its
secondary flash, and then from a TFTP server. You can modify this booting sequence at the global
CONFIG level of the CLI using the boot system command.
NOTE
FSX device with FastIron 08.0.00a, ICX 6430, and ICX 6450 devices support only one configured
system boot preference.
To initiate an immediate boot from the CLI, enter one of the boot system commands.
NOTE
When using the boot system tftp command, the IP address of the device and the TFTP server should
be in the same subnet.
device#show boot-preference
Boot system preference (Configured):
Use Default
Boot system preference(Default):
Boot system flash primary
Boot system flash secondary
Brocade#show boot-preference
Boot system preference(Configured):
Boot system tftp 10.1.1.1 FCXR08000.bin
Boot system flash primary
Boot system preference(Default):
Boot system flash primary
Boot system flash secondary
Brocade#show run
Current configuration:
!
ver 08.0.00T7f3
!
stack unit 1
module 1 fcx-24-poe-port-management-module
module 2 fcx-cx4-2-port-16g-module
priority 128
stack-port 1/2/1 1/2/2
stack unit 2
module 1 fcx-48-port-management-module
module 2 fcx-cx4-2-port-16g-module
stack-port 2/2/1 2/2/2
stack enable
stack mac 748e.f80e.dcc0
!
boot sys tf 10.1.1.1 FCXR08000.bin
boot sys fl pri
ip route 0.0.0.0/0 10.37.234.129
!
end
NOTE
To return the unit to the default startup configuration, use the delete startup-config command.
device# reload
If the startup-config file was modified by a valid user, the following Syslog message is generated.
To disable or re-enable Syslog messages when the startup-config file is changed, use the following
command.
Syntax:[no] logging enable config-changed
NOTE
For details about the copy command used with IPv6, refer to Using the IPv6 copy command on page
104.
NOTE
You can name the configuration file when you copy it to a TFTP server. However, when you copy a
configuration file from the server to a Brocade device, the file is always copied as "startup-config" or
"running-config", depending on which type of file you saved to the server.
To initiate transfers of configuration files to or from a TFTP server using the CLI, enter one of the
following commands:
• copy startup-config tftp tftp-ip-addr filename - Use this command to upload a copy of the startup
configuration file from the Layer 2 Switch or Layer 3 Switch to a TFTP server.
• copy running-config tftp tftp-ip-addr filename - Use this command to upload a copy of the
running configuration file from the Layer 2 Switch or Layer 3 Switch to a TFTP server.
• copy tftp startup-config tftp-ip-addr filename - Use this command to download a copy of the
startup configuration file from a TFTP server to a Layer 2 Switch or Layer 3 Switch.
NOTE
It is recommended to use a script or the copy running-config tftp command for extensive
configuration. You should not copy-paste configuration with more than 2000 characters into CLI.
NOTE
You can enter text following " ! " as a comment. However, the " !" is not a comment marker. It returns
the CLI to the global configuration level.
NOTE
If you copy-and-paste a configuration into a management session, the CLI ignores the " ! " instead of
changing the CLI to the global CONFIG level. As a result, you might get different results if you copy-
and-paste a configuration instead of loading the configuration using TFTP.
• Make sure you enter each command at the correct CLI level. Since some commands have identical
forms at both the global CONFIG level and individual configuration levels, if the CLI response to the
configuration file results in the CLI entering a configuration level you did not intend, then you can
get unexpected results.
For example, if a trunk group is active on the device, and the configuration file contains a command to
disable STP on one of the secondary ports in the trunk group, the CLI rejects the commands to enter
the interface configuration level for the port and moves on to the next command in the file you are
loading. If the next command is a spanning-tree command whose syntax is valid at the global CONFIG
level as well as the interface configuration level, then the software applies the command globally. Here
is an example.
The configuration file contains these commands.
interface ethernet
2
no spanning-tree
device(config)#interface ethernet 2
Error - cannot configure secondary ports of a trunk
device(config)#no spanning-tree
device(config)#
• If the file contains commands that must be entered in a specific order, the commands must appear
in the file in the required order. For example, if you want to use the file to replace an IP address on
an interface, you must first remove the old address using "no" in front of the ip address command,
then add the new address. Otherwise, the CLI displays an error message and does not implement
the command. Here is an example.
The configuration file contains these commands.
interface ethernet 11
ip address 10.10.10.69/24
The running-config already has a command to add an address to port 11, so the CLI responds like
this.
device(config)#interface ethernet 11
device(config-if-e1000-11)#ip add 10.10.10.69/24
Error: can only assign one primary ip address per subnet
device(config-if-e1000-11)#
To successfully replace the address, enter commands into the file as follows.
interface ethernet
11
no ip address 10.20.20.69/24
ip address 10.10.10.69/24
This time, the CLI accepts the command, and no error message is displayed.
device(config)#interface ethernet 11
device(config-if-e1000-11)#no ip add 10.20.20.69/24
• Always use the end command at the end of the file. The end command must appear on the last line
of the file, by itself.
NOTE
In the current FastIron release, the copy tftp running-config command merges only the access-lists
and mac-filters configuration from the configuration file on the TFTP server to the running configuration
on the device.
NOTE
If you are loading a configuration file that uses a truncated form of the CLI command access-list , the
software will not go into batch mode.
For example, the following command line will initiate batch mode.
This command copies the secondary boot image named test.img from flash memory to a TFTP server
with the IPv6 address of 2001:DB8:e0ff:7837::3.
Syntax: copy flash tftp ipv6-address source-file-name primary | secondary
The ipv6-address parameter specifies the address of the TFTP server. You must specify this address
in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The source-file-name parameter specifies the name of the file you want to copy to the IPv6 TFTP
server.
The primary keyword specifies the primary boot image, while the secondary keyword specifies the
secondary boot image.
This command copies the running configuration to a TFTP server with the IPv6 address of
2001:DB8:e0ff:7837::3 and names the file on the TFTP server newrun.cfg.
Syntax: copy running-config | startup-config tftp ipv6-address destination-file-name
Specify the running-config keyword to copy the running configuration file to the specified IPv6 TFTP
server.
Specify the startup-config keyword to copy the startup configuration file to the specified IPv6 TFTP
server.
The tftp ipv6-address parameter specifies the address of the TFTP server. You must specify this
address in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The destination-file-name parameter specifies the name of the file that is copied to the IPv6 TFTP
server.
This command copies a boot image named test.img from an IPv6 TFTP server with the IPv6 address of
2001:DB8:e0ff:7837::3 to the secondary storage location in the device flash memory.
Syntax: copy tftp flash ipv6-address source-file-name primary | secondary
The ipv6-address parameter specifies the address of the TFTP server. You must specify this address in
hexadecimal using 16-bit values between colons as documented in RFC 2373.
The source-file-name parameter specifies the name of the file you want to copy from the IPv6 TFTP
server.
The primary keyword specifies the primary storage location in the device flash memory, while the
secondary keyword specifies the secondary storage location in the device flash memory.
This command copies the newrun.cfg file from the IPv6 TFTP server and overwrites the running
configuration file with the contents of newrun.cfg.
NOTE
To activate this configuration, you must reload (reset) the device.
Copying a primary or secondary boot Image from flash memory to an IPv6 TFTP server
For example, to copy the primary or secondary boot image from the device flash memory to an IPv6
TFTP server, enter a command such as the following.
This command copies the primary boot image named primary.img from flash memory to a TFTP
server with the IPv6 address of 2001:DB8:e0ff:7837::3.
Syntax: copy flash primary | secondary tftp ipv6-address source-file-name
The primary keyword specifies the primary boot image, while the secondary keyword specifies the
secondary boot image.
The tftp ipv6-address parameter specifies the address of the TFTP server. You must specify this
address in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The source-file-name parameter specifies the name of the file you want to copy from flash memory.
This command copies a device running configuration to a TFTP server with the IPv6 address of
2001:DB8:e0ff:7837::3 and names the destination file bakrun.cfg.
Syntax: copy running-config | startup-config tftp ipv6-address destination-file-name
Specify the running-config keyword to copy the device running configuration or the startup-config
keyword to copy the device startup configuration.
The tftp ipv6-address parameter specifies the address of the TFTP server. You must specify this
address in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The destination-file-name parameter specifies the name of the running configuration that is copied to
the IPv6 TFTP server.
This command uploads the primary boot image named primary.img from a TFTP server with the IPv6
address of 2001:DB8:e0ff:7837::3 to the device primary storage location in flash memory.
Syntax:copy tftp ipv6-address source-file-name flash primary | secondary
The tftp ipv6-address parameter specifies the address of the TFTP server. You must specify this
address in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The source-file-name parameter specifies the name of the file you want to copy from the TFTP server.
The primary keyword specifies the primary location in flash memory, while the secondary keyword
specifies the secondary location in flash memory.
This command uploads a file named newrun.cfg from a TFTP server with the IPv6 address of
2001:DB8:e0ff:7837::3 to the device.
Syntax:copy tftp ipv6-address source-file-name running-config|startup-config
The tftp ipv6-address parameter specifies the address of the TFTP server. You must specify this
address in hexadecimal using 16-bit values between colons as documented in RFC 2373.
The source-file-name parameter specifies the name of the file you want to copy from the TFTP server.
Specify the running-config keyword to upload the specified file from the IPv6 TFTP server to the
device. The device copies the specified file into the current running configuration but does not overwrite
the current configuration.
Specify the startup-config keyword to upload the specified file from the IPv6 TFTP server to the
device. The the device copies the specified file into the current startup configuration but does not
overwrite the current configuration.
NOTE
The syntax shown in this section assumes that you have installed HP OpenView in the "/usr" directory.
1. Configure a read-write community string on the Brocade device, if one is not already configured. To
configure a read-write community string, enter the following command from the global CONFIG level
of the CLI.
snmp-server community string ro|rw
NOTE
Option 23 adds configuration information to the running-config on the device, and does not replace
commands. If you want to replace configuration information in the device, use "no" forms of the
configuration commands to remove the configuration information, then use configuration commands
to create the configuration information you want. Follow the guidelines in Dynamic configuration
loading on page 101.
NOTE
The scheduled reload feature requires the system clock. Refer to Network Time Protocol Version 4
(NTPv4) on page 35.
device#show reload
device#reload cancel
6 TFTP out of buffer space. The file is larger than the amount of room on the device or TFTP server.
If you are copying an image file to flash, first copy the other image to
your TFTP server, then delete it from flash. (Use the erase flash ... CLI
command at the Privileged EXEC level to erase the image in the flash.)
If you are copying a configuration file to flash, edit the file to remove
unnecessary information, then try again.
7 TFTP busy, only one Another TFTP transfer is active on another CLI session, or Web
TFTP session can be management session, or network management system.
active.
Wait, then retry the transfer.
8 File type check failed. You accidentally attempted to copy the incorrect image code into the
system. For example, you might have tried to copy a Chassis image into
a Compact device.
Retry the transfer using the correct image.
16 TFTP remote - general The TFTP configuration has an error. The specific error message
error. describes the error.
Correct the error, then retry the transfer.
17 TFTP remote - no such
file.
This section describes the error messages associated with the TFTP transfer of PoE firmware file to a
Brocade device.
Firmware is not valid for this Each PoE firmware file delivered by Brocade is meant to be used on the specific
platform. platform only. If the file is used on a platform for which it is not meant, then this error
message will display.
Download the correct file, then retry the transfer.
Firmware is not valid for the Each PoE firmware file delivered by Brocade is meant to be used on the specific
IEEE 802.3at (PoE-Plus) platform only. If the file is used on a platform for which it is not meant, then this error
controller type. message will display.
Download the correct file, then retry the transfer.
Firmware type cannot be Each PoE firmware file delivered by Brocade is meant to be used on the specific
detected from the firmware platform and the specific PoE controller on the specified module. If the file is used for
content. a platform for which it is meant, but the PoE controller is not same then this error
message will display.
TFTP File not Valid for PoE Download the correct file, then retry the transfer.
Controller Type.
Firmware tftp remote file The TFTP server needs read access on the PoE firmware file. Check the
access failed. permissions on the file, then try again.
NOTE
This section describes the IPv4ping command. For details about IPv6 ping , refer to the FastIron
Ethernet Layer 3 Routing Configuration Guide .
To verify that a Brocade device can reach another device through the network, enter a command such
as the following at any level of the CLI on the Brocade device:
Syntax:ping ip-addr | hostname [source ip-addr ] [count num ] [ timeout msec ] [ ttl num] [sizebyte]
[quiet][numeric][no-fragment][verify][data1-to-4 byte hex ][brief[max-print-per-sec number]]
NOTE
If the device is a Brocade Layer 2 Switch or Layer 3 Switch, you can use the host name only if you
have already enabled the Domain Name Server (DNS) resolver feature on the device from which you
are sending the ping. Refer to "IP Configuration" chapter in the FastIron Ethernet Switch Layer 3
Routing Configuration Guide .
The data 1 - 4 byte hex parameter lets you specify a specific data pattern for the payload instead of the
default data pattern, "abcd", in the packet data payload. The pattern repeats itself throughout the ICMP
message (payload) portion of the packet.
NOTE
For numeric parameter values, the CLI does not check that the value you enter is within the allowed
range. Instead, if you do exceed the range for a numeric value, the software rounds the value to the
nearest valid value.
The brief parameter causes ping test characters to be displayed. The following ping test characters are
supported:
! Indicates that a reply was received.
. Indicates that the network server timed out while waiting for a reply.
U Indicates that a destination unreachable error PDU was received.
I Indicates that the user interrupted ping.
NOTE
The number of ! characters displayed may not correspond to the number of successful replies by the
ping command. Similarly, the number of . characters displayed may not correspond to the number of
server timeouts that occurred while waiting for a reply. The "success" or "timeout" results are shown in
the display as "Success rate is XX percent (X/Y)".
The optional max-print-per-sec number parameter specifies the maximum number of target responses
the Brocade device can display per second while in brief mode. You can specify from 0 - 2047. The
default is 511.
NOTE
If you address the ping to the IP broadcast address and network address, the device lists the first four
responses to the ping.
NOTE
On 48GC modules in non-jumbo mode, the maximum size of ping packets is 1486 bytes and the
maximum frame size of tagged traffic is no larger than 1581 bytes.
NOTE
This section describes the IPv4traceroute command. For details about IPv6traceroute , refer to the
FastIron Ethernet Switch Layer 3 Routing Configuration Guide .
Use the traceroute command to determine the path through which a Brocade device can reach another
device. Enter the command at any level of the CLI.
The CLI displays trace route information for each hop as soon as the information is received.
Traceroute requests display all responses to a given TTL. In addition, if there are multiple equal-cost
routes to the destination, the Brocade device displays up to three responses by default.
Syntax: traceroute host-ip-addr [ maxttl value ] [ minttl value ] [ numeric ] [ timeout value ] [
source-ip ip-addr ]
Possible and default values are as follows.
minttl value - Minimum TTL (hops) value: Possible values are 1 through 255. Default value is 1
second.
maxttl value - Maximum TTL (hops) value: Possible values are 1 through 255. Default value is 30
seconds.
timeout value - Possible values are 1 through 120. Default value is 2 seconds.
numeric - Changes the display to list the devices by their IP addresses instead of their names.
source-ip ip-addr - Specifies an IP address to be used as the origin for the traceroute.
EFM-OAM protocol
The functionality of the EFM-OAM can be summarized under the following categories:
• Discovery: Discovery is the mechanism to detect the presence of an OAM sub-layer on the remote
device. During the discovery process, information about OAM entities, capabilities, and
configurations are exchanged.
• Remote fault detection: Provides a mechanism for an OAM entity to convey error conditions to its
peer by way of a flag in the OAMPDUs.
• Remote loopback: This mechanism is used to troubleshoot networks and to isolate problem
segments in a large network by sending test segments.
Discovery
Discovery is the first phase of EFM-OAM. At this phase, EFM-OAM identifies network devices along
with their OAM capabilities. The Discovery process relies on the Information OAMPDUs. During
discovery, the following information is advertised through the TLVs within periodic information
OAMPDUs:
• OAM capabilities: Advertises the capabilities of the local OAM entity. Using this information, a peer
can determine what functions are supported and accessible (for example, loopback capability).
• OAM mode: The OAM mode is conveyed to the remote OAM entity. The mode can be either active or
passive, and can also be used to determine a device’s functionality.
• OAMPDU configuration: This configuration includes the maximum OAMPDU size to delivery. In
combination with the limited rate of 10 frames per second, this information can be used to limit the
bandwidth allocated to OAM traffic.
Timers
Two configurable timers control the protocol, one determining the rate at which OAMPDUs are to be
sent, and the second controlling the rate at which OAMPDUs are to be received to maintain the
Discovery procedure from resetting.
• The timer should generate PDUs in the range of 1 through 10 PDUs per second. The default value is
1 PDU per second.
• The Hold timer assumes the peer is dead if no packet is received for a period of 1 through 10
seconds. The default value is 5 seconds.
Flags
Included in every OAMPDU is a flags field, which contains, besides other information, the status of the
discovery process. There are three possible values for the status:
• Discovering: Discovery is in progress.
• Stable: Discovery is completed. Once aware of this, the remote OAM entity can start sending any
type of OAMPDU.
• Unsatisfied: When there are mismatches in the OAM configuration that prevent OAM from completing
the discovery, the discovery process is considered unsatisfied and cannot continue.
Process overview
The discovery process allows local Data Terminating Entity (DTE) to detect OAM on a remote DTE.
Once OAM support is detected, both ends of the link exchange state and configuration information
(such as mode, PDU size, loopback support, and so on). If both DTEs are satisfied with the settings,
OAM is enabled on the link. However, the loss of a link or a failure to receive OAMPDUs for five
seconds may cause the discovery process the start over again.
DTEs may be in either active or passive mode. Active mode DTEs instigate OAM communications and
can issue queries and commands to a remote device. Passive mode DTEs generally wait for the peer
device to instigate OAM communications and respond to, but do not instigate, commands and queries.
Rules of what DTEs in active or passive mode can do are discussed in the following sections.
Exceptions
• A DTE in active mode does not respond to variable request PDUs from DTEs in passive mode
• A DTE in active mode does not react to loopback control PDUs from DTEs in passive mode
Remote loopback
An OAM entity can put its remote entity into loopback mode using a loopback control OAMPDU. This
helps you ensure quality of links during installation or when troubleshooting. In loopback mode, each
frame received is transmitted back on that same port except for OAMPDUs and pause frames. The
periodic exchange of OAMPDUs must continue while in the loopback state to maintain the OAM
session. The loopback command is acknowledged by responding with an information OAMPDU with the
loopback state indicated in the state field.
NOTE
Brocade recommends to ensure that any higher layer protocol running over the local and remote
loopback ports does not block the interfaces in the VLAN on which loopback traffic testing is being
performed.
NOTE
Ethernet loopback and EFM-OAM remote loopback cannot be configured on the same interface.
NOTE
If EEE is enabled globally, port ceases to be in the remote loopback mode.
Configuring EFM-OAM
The EFM-OAM configuration includes the following procedural steps to enable EFM-OAM on an
interface or multiple interfaces for advanced monitoring and maintenance of Ethernet network.
1. Enter the configure terminal command to enter global configuration mode.
device# configure terminal
2. Enter the link-oam command to enable the EFM-OAM protocol and enter EFM-OAM protocol
configuration mode.
device(config)# link-oam
device(config-link-oam)#
3. Enter the timeout command to configure the time in seconds for which the local Data Terminal
Equipment (DTE) waits to receive OAM Protocol Data Units (OAM-PDUs) from the remote entity.
device(config-link-oam)# timeout 5
4. Enter the pdu-rate command to configure the number of PDUs to be transmitted per second by the
DTE.
device(config-link-oam)# pdu-rate 2
5. Enter the ethernet command to enable EFM-OAM on an interface.
EFM-OAM can be enabled on more than one interface. You can also specify a range of interfaces to
enable EFM-OAM on multiple interfaces.
6. (Optional) Enter the ethernet stackid/slot/port allow-loopback command to enable the interface to
respond to a loopback request from the remote device.
device(config-link-oam)# ethernet 1/1/3 allow-loopback
7. (Optional) Enter the ethernet stackid/slot/port remote-failure command to set the device for the
remote-failure action to be taken upon the reception of critical event information on the interface.
device(config-link-oam)# ethernet 1/1/3 remote-failure critical-event action
block-interface
8. (Optional) Enter the remote-loopback ethernet stackid/slot/port command to start or stop the
remote loopback procedure on a remote device.
device(config-link-oam)# remote-loopback ethernet 2/1/1 start
device(config-link-oam)# remote-loopback ethernet 2/1/1 stop
The following sample output of the show link-oam info detail command displays detailed OAM
information on all OAM-enabled ports.
device(config)# show link-oam info detail
OAM information for Ethernet port: 10/1/1
+link-oam mode: passive
+link status: down
+oam status: down
Local information
multiplexer action: forward
The following sample output of the show link-oam info detail ethernet command displays detailed
OAM information on a specific Ethernet port.
device(config)# show link-oam info detail ethernet 1/1/3
OAM information for Ethernet port: 1/1/3
+link-oam mode: active
+link status: up
+oam status: up
Local information
multiplexer action: forward
parse action: forward
stable: satisfied
state: up
loopback state: disabled
dying-gasp: false
critical-event: false
link-fault: false
Remote information
The following sample output of the show link-oam statistics detail command displays detailed OAM
statistics on all OAM-enabled ports.
device(config)# show link-oam statistics detail
OAM statistics for Ethernet port: 10/1/1
Tx statistics
information OAMPDUs: 377908
loopback control OAMPDUs: 0
variable request OAMPDUs: 0
variable response OAMPDUs: 0
unique event notification OAMPDUs: 0
duplicate event notification OAMPDUs: 0
organization specific OAMPDUs: 0
link-fault records: 0
critical-event records: 0
dying-gasp records: 0
Rx statistics
information OAMPDUs: 377967
loopback control OAMPDUs: 0
loopback control OAMPDUs dropped: 0
variable request OAMPDUs: 0
variable response OAMPDUs: 0
unique event notification OAMPDUs: 0
duplicate event notification OAMPDUs: 0
organization specific OAMPDUs: 0
unsupported OAMPDUs: 0
link-fault records: 0
critical-event records: 377395
dying-gasp records: 0
discarded TLVs: 0
unrecognized TLVs: 0
link-fault records: 0
critical-event records: 0
dying-gasp records: 0
discarded TLVs: 0
unrecognized TLVs: 0
The following sample output of the show link-oam statistics detail ethernet command displays
detailed OAM statistics on a specific Ethernet port.
device(config)# show link-oam statistics detail ethernet 1/1/3
OAM statistics for Ethernet port: 1/1/3
Tx statistics
information OAMPDUs: 122474
loopback control OAMPDUs: 0
variable request OAMPDUs: 0
variable response OAMPDUs: 0
unique event notification OAMPDUs: 0
duplicate event notification OAMPDUs: 0
organization specific OAMPDUs: 0
link-fault records: 0
critical-event records: 0
dying-gasp records: 0
Rx statistics
information OAMPDUs: 94691
loopback control OAMPDUs: 0
loopback control OAMPDUs dropped: 0
variable request OAMPDUs: 0
variable response OAMPDUs: 0
unique event notification OAMPDUs: 0
duplicate event notification OAMPDUs: 0
organization specific OAMPDUs: 0
unsupported OAMPDUs: 0
link-fault records: 0
critical-event records: 0
dying-gasp records: 0
discarded TLVs: 0
unrecognized TLVs: 0
Port 1 is LOAM logically Link-OAM: Logical link on interface Ethernet 1/1/1 is up.
Up
Port 1 is LOAM logically Link-OAM: Logical link on interface Ethernet 1/1/1 is down.
Down
Port 1 entered remote Link-OAM: Link entered remote loopback on ethernet 1/1/1
Loopback mode
Port 1 cleared remote Link-OAM: Link cleared remtote loopback on ethernet 1/1/1
Loopback mode
Port 1 entered local Link-OAM: Link entered local loopback on ethernet 1/1/1
Loopback mode
Port 1 cleared local Link-OAM: Link cleared local loopback on ethernet 1/1/1
Loopback mode
Dying gasp event on port Link-OAM: Link received dying-gasp event on ethernet 1/1/1
1
Critical event on port 1 Link-OAM: Link received critical event on ethernet 1/1/1
hitless-supported services and protocols. Unlike a switchover, a failover generally happens without
warning.
Hitless Operating System (OS) Upgrade - An operating system upgrade and controlled switchover
without any packet loss to the services and protocols that are supported by Hitless management. The
services and protocols supported by Hitless management are listed in this section. Hitless failover and
hitless switchover are disabled by default.
NOTE
All traffic going through Ethernet interfaces (if present) on the management modules will be interrupted
during a hitless OS upgrade. This is because both management modules must be reloaded with the
new image. This applies to hitless OS upgrade only. It does not apply to hitless switchover or failover,
which does not interrupt traffic going through Ethernet interfaces on the standby management module
(the module that takes over the active role).
TABLE 13 Hitless-supported services and protocols - FSX 800 and FSX 1600
Layer 2 switched • 802.1p and 802.1Q Layer 2 switched traffic is not impacted
traffic, including • 802.3ad - LACP during a Hitless management event. All
unicast and multicast • 802.3af - PoE existing switched traffic flows continue
uninterrupted.
+ • 802.3at - PoE+
• DSCP honoring and Diffserv New switched flows are not learned by the
System-level FastIron switch during the switchover
• Dual-mode VLAN
+ • IGMP v1, v2, and v3 snooping process and are flooded to the VLAN
members in hardware. After the new active
Layer 4 • IPv4 ACLs
management module becomes operational,
• IPv6 ACLs new switched flows are learned and
• Layer 2 switching (VLAN and 802.1Q-in- forwarded accordingly. The Layer 2 control
Q) protocol states are not interrupted during the
• MLD v1 and v2 snooping switchover process.
• MRP
Configured ACLs, PBR or GRE & IPv6 to
• Multiple spanning tree (MSTP) IPv4 Tunnels will operate in a hitless
• Physical port/link state manner.
• PIM SM snooping
• Port mirroring and monitoring
• Port trunking
• Rapid spanning tree (RSTP)
• Spanning tree (STP)
• ToS-based QoS
• Policy Based Routing
• Traffic policies
• UDLD
• VSRP
Layer 3 IPv4 routed • BGP4 Layer 3 routed traffic for supported protocols
traffic • IPv4 unicast forwarding is not impacted during a Hitless
• OSPFv2 management event.
• OSPFv2 with ECMP Other Layer 3 protocols that are not
• Static routes supported will be interrupted during the
• IPv4 PIM (IPv4 non-stop multicast switchover or failover.
routing needs to be enabled for IPv4 PIM
If BGP4 graceful restart or OSPF graceful
to be hitless.)
restart is enabled, it will be gracefully
• VRRP restarted and traffic will converge to
• VRRP-E normalcy after the new active module
• GRE becomes operational.
• IPv6 to IPv4 Tunnels
Configured ACLs, PBR or GRE & IPv6 to
IPv4 Tunnels will operate in a hitless
manner.
TABLE 13 Hitless-supported services and protocols - FSX 800 and FSX 1600 (Continued)
Layer 3 IPv6 routed • BGP4+ Layer 3 routed traffic for supported protocols
traffic • IPv6 unicast forwarding is not impacted during a Hitless
• OSPFv3 management event. Traffic will converge to
normalcy after the new active module
• OSPFv3 with ECMP
becomes operational.
• Static routes
• VRRP Other Layer 3 protocols that are not
• VRRP-E supported will be interrupted during the
switchover or failover.
If BGP4+ graceful restart or OSPF graceful
restart / OSPFv3 NSR is enabled, it will be
gracefully restarted and traffic will converge
to normalcy after the new active module
becomes operational.
Configured ACLs will operate in a hitless
manner.
Security • 802.1X, including use with dynamic Supported security protocols and services
ACLs and VLANs are not impacted during a switchover or
• IPv4 ACLs failover.
• IPv6 ACLs
• DHCP snooping
• Dynamic ARP inspection NOTE
• EAP with RADIUS If 802.1X and multi-device port
• IP source guard authentication are enabled together on the
• Multi-device port authentication, same port, both will be impacted during a
including use with dynamic ACLs and switchover or failover. Hitless support for
VLANs these features applies to ports with 802.1X
only or multi-device port authentication only.
• All traffic going through Ethernet interfaces (if present) on the management modules will be
interrupted during a hitless OS upgrade. This is because both management modules must be
reloaded with the new image. This applies to hitless OS upgrade only. It does not apply to hitless
switchover or failover, which does not interrupt traffic going through Ethernet interfaces on the
standby management module (the module that takes over the active role).
• Static and dynamic multi-slot trunks will flap during a hitless switchover if any of the trunk port
members reside on the management module.
• Layer 3 multicast traffic is not supported by Hitless management.
chassis. The control plane carries traffic that is destined for the CPU of the active management module.
Control plane traffic includes the following:
• Management traffic
• Control protocol traffic
• In some cases, the first packet of a data flow
During a controlled or forced switchover, the data plane is not affected. Traffic in the forwarding plane
will continue to run without interruption while the standby management module takes over operation of
the system. However, traffic in the control plane will be minimally impacted.
The first message indicates that the active management module has detected the standby management
module. The second message indicates that the standby module has been hot-inserted and is ready for
baseline synchronization. The third message is seen when baseline synchronization is completed, and
the fourth message is seen when protocol synchronization is completed.
The console of the standby management module also displays the progress of the synchronization.
The first message indicates that baseline synchronization is completed, and the second message
indicates that protocol sychronization is completed.
When control protocols are synchronized and protocol synchronization timers expire, the standby
management module will be in hot-standby mode, meaning the standby module is ready to take over as
the active management module. In the event of a switchover, the standby module will pick up where the
active module left off, without interrupting data traffic.
After baseline synchronization, any new events that occur on the active CPU will be dynamically
synchronized on the standby CPU. Examples of such events include:
• CLI/HTTP/SNMP configurations
• CPU receive packets
• Link events
• Interrupts
• Layer 2 and Layer 3 forwarding table updates
• Dynamic user authentication updates such as 802.1X or multi-device port authentication
• Routing protocols OSPFv2 and OSPFv3 updates if NSR is enabled.
Dynamic events are synchronized in such a way that if the active CPU fails before fully executing an
event, the standby CPU (newly active CPU) will execute the event after the failover. Also, if the active
CPU aborts the event, the standby CPU will abort the event as well.
NOTE
Since both the standby and active management modules run the same code, a command that brings
down the active management module will most likely bring down the standby management module.
Because all configuration commands are synchronized from active to standby management module in
real time, both management modules will reload at almost the same time. This in turn will cause the
system to reset all interface modules (similar to the behavior when the reboot command is executed)
and will cause packet loss associated with a system reboot.
NOTE
If the new active management module becomes out-of-sync with an interface module, information on
the interface module can be overwritten in some cases, which can cause an interruption of traffic
forwarding.
NOTE
Hitless OS upgrade is not impacted by this option and is supported whether or not hitless failover is
enabled.
NOTE
Synchronization between the active management module and standby management module will occur
whether or not hitless failover is enabled.
To enable hitless failover, enter the following command at the Global CONFIG level of the CLI:
device(config)#hitless-failover enable
The command takes effect immediately. Manual switchover is allowed, and in the event of a failover, the
standby management module will take over the active role without reloading the system.
Syntax: [no] hitless-failoverenable
Use the no form of the command to disable hitless failover once it has been enabled.
device# switch-over-active-role
Once you enter this command, the system will prompt you as follows.
Syntax: switch-over-activerole
If this command is entered when hitless failover is disabled, the following message will appear on the
console:
Switch-over is not allowed. Reason: hitless-failover not configured.
A management slot which is in active management preference will always attempt to be active on the
next reboot.
To reset the preference, enter the command such as the following:
NOTE
The default active management preference is set to mgmt0 (slot 9).
1. The standby management module resets and reloads with the new software image in its flash
memory.
2. The Ethernet interfaces (if present) on the standby module become operational and start carrying
data traffic.
3. The active management module synchronizes the standby management module with all the
information required to take over the active role.
4. The Layer 2 and Layer 3 control protocols on the standby management module converge. This
process takes approximately 70 seconds.
5. The standby management module takes over the active role.
6. The old active management module resets and reloads with the same software image running on
the newly active management module.
7. The FastIron switch is now operating with the new software image. The management module that
was initially configured as the standby management module is now the active management module
and the management module that was initially configured as the active management module is now
the standby.
NOTE
The events described above occur internally and do not create or affect the external network
topology.
device#hitless-reload primary
NOTE
The hitless-reload command is accepted only when the running configuration and startup configuration
files match. If the configuration file has changed, you must first save the file (write mem ) before
executing a hitless reload. Otherwise, the following message will display on the console.Error: Running
config and start-up config differs. Please reload the system or save the configuration before attempting
hitless reload.
device#show ipc
Version 6, Grp 0, Recv: stk-p0: 840918, p1: 0, sum: 840918
Message types have callbacks:
1:Reliable IPC mesage 2:Reliable IPC atomic 4:fragmentation,jumbo
20:SYNC dynamic change 22:SYNC download reply 24:SYNC download spec i
25:SYNC restart download 26:SYNC verification 27:SYNC disable/enable
29:SYNC mgmt hello 35:IPC Ready Msg 36:IPC Msg for Sync Fra
38:SYNC reliable
Send message types:
[1]=815798, [21]=1, [35]=1, [38]=24442,
Recv message types:
[1]=816446,0, [20]=2,0 [22]=1,0
[29]=25,0, [38]=24442,0,
Statistics:
send pkt num : 840242, recv pkt num : 840918
send msg num : 840242, recv msg num : 840918,
send frag pkt num : 0, recv frag pkt num : 0,
pkt buf alloc : 832113,
Reliable-mail send success receive time us
target ID 0 0 0 0
target MAC 0 0 0 0
There is 0 current jumbo IPC session
Possible errors:
***recv msg no callback 2, last msg_type=20, from stack0, e1/9
Syntax:show ipc
device#show ipc_stat
Total available Hsync channel space = 1048580
Total available Appl channel space = 524292
Total number of application msgs in dyn queue = 0
Total number of hsync msgs in dyn queue = 0
Total number of rel sync msgs in dyn queue = 0
Total number of rx pkt msgs in standby dynamic queue
Total number of rx pkt msgs in active dyn queue = 0
Total number of rx pkts relayed = 0
Total number of rx pkts received = 5686578
Total number of dyn-sync messages received so far = 3
Total number of rel-sync pending complete = 0
Total number of L3 baseline-sync packets = 655
Total number of packet drops in sync = 0
Is image_sync_in_progress? = 0
Total num of rx dyn queue drops = 0
Total num of jumbo corrupts = 0
Total number of messages in IP send queue = 0
Syntax: showipc_stat
Example for setting IPv4 hitless purge timer on the default VRF
The following example shows how to set the IPv4 hitless purge timer on the default VRF:
Brocade(config)# ip hitless-route-purge-timer 60
Example for setting the IPv4 hitless purge timer on the non-default
VRF
The following example shows how to set the IPv4 purge timer on the non-default VRF:
Example for setting the IPv6 hitless purge timer on the defatult VRF
The following example shows how to set the IPv6 hitless purge timer on the default VRF:
Example for setting the IPv6 hitless purge timer on the non-default
VRF
The following example shows how to set the IPv6 purge timer on the non-default VRF:
a passive, no traffic condition. The EEE feature in switching platforms reduces overall energy
consumption, cooling, noise, and operating costs for energy and cooling. Lower power consumption
also means lower heat dissipation and increased system stability, less energy usage, thereby reducing
costs and impact on the environment.
EEE is a set of enhancements to the Ethernet specification to address power consumption during
periods of low data activity. EEE is specified in IEEE Std 802.3az-2010 which is an amendment to the
IEEE Std 802.3-2008 specification. The optional EEE capability combines the IEEE 802.3 Media
Access Control (MAC) sublayer with a family of physical layers defined to support operation in the Low
Power Idle (LPI) mode. When the LPI mode is enabled, systems on both sides of the link can save
power during periods of low link utilization. LPI signaling allows the LPI client to indicate to the PHY,
and to the link partner, that a break in the data stream is expected. The LPI client can then use this
information to enter power-saving modes that require additional time to resume normal operation. LPI
signaling also informs the LPI client when the link partner sends such an indication.
NOTE
Histogram information is not maintained across reboot.
show files disk0 Displays the files in the external USB drive.
unmount disk0 Unmounts the filesystem of the external USB drive. This command is
required to safely plug out the USB, so that files are not lost or corrupted.
copy flash disk0 primary \ Copies the image binary stored in the primary or secondary partition of the
secondary flash to a destination file in the external USB.
copy flash disk0 file Copies any file from a source file in the system flash to an external USB
destination file.
copy disk0 license Copies the license file present in the external USB drive to the system.
copy disk0 running-config Copies the configuration file present on the external USB drive to the
system's running configuration.
copy disk0 startup-config Copies the configuration file present on the external USB drive to the
system's startup configuration file.
Refer to the FastIron Command Reference Guide for details on using the External USB Hotplug
commands.
Commands
ip hitless-route-purge-timer
Configures the maximum time before stale routes are purged from the routing information base (RIB)
after a switchover, failover, or OS upgrade. The no form of this command sets the purge timer time to
its default value.
no ip hitless-route-purge-timer seconds
Parameters seconds
Maximum time, in seconds, before stale routes are purged. The valid range is from 2 to 600.
The default is 45 seconds.
Usage Guidelines Under normal circumstances, you may not need to change the value of the route purge timer. If you
anticipate delay in learning the routes after switchover, you can configure a larger value for the route
purge timer.
Examples The following example shows how to set the IPv4 hitless purge timer on the default VRF:
The following example shows how to set the IPv4 purge timer on the non-default VRF:
ipv6 hitless-route-purge-timer
Configures the maximum time before stale routes are purged from the routing information base (RIB)
after a switchover, failover, or OS upgrade. The no form of this command sets the purge timer time to
its default value.
Parameters seconds
Maximum time, in seconds, before stale routes are purged. The valid range is from 2 to 600.
The default is 45 seconds.
Usage Guidelines Under normal circumstances, you may not need to change the value of the route purge timer. If you
anticipate delay in learning the routes after switchover, you can configure a larger value for the route
purge timer. IPv6 unicast routing must be enabled using the ipv6 unicast-routing command before
configuring the purge timer.
Examples The following example shows how to set IPv6 hitless purge timer on default VRF:
The following example shows how to set IPv6 purge timer on a non-default VRF:
NOTE
Static IPv6 route configuration is supported only with the IPv6 Layer 3 license on FSX devices and the
full Layer 3 image on other devices.
You can configure a static IPv6 route to be redistributed into a routing protocol, but you cannot
redistribute routes learned by a routing protocol into the static IPv6 routing table.
NOTE
The maximum IPv6 static routes supported on an ICX 6450 device is 1070.
Before configuring a static IPv6 route, you must enable the forwarding of IPv6 traffic on the Layer 3
switch using the ipv6 unicast-routing command and enable IPv6 on at least one interface by
configuring an IPv6 address or explicitly enabling IPv6 on that interface. For more information on
performing these configuration tasks, refer to "Configuring IPv4 and IPv6 protocol stacks" section in the
FastIron Ethernet Switch Administration Guide .
Syntax: ipv6 route dest-ipv6-prefix / prefix-length interface port [ metric ] [ distance number]
The following table describes the parameters associated with this command and indicates the status
of each parameter.
The IPv6 prefix and You must specify the dest-ipv6-prefix parameter in Mandatory for all static
prefix length of the hexadecimal using 16-bit values between colons as IPv6 routes.
route’s destination documented in RFC 2373.
network.
You must specify the prefix-length parameter as a decimal
value. A slash mark (/) must follow the ipv6-prefix parameter
and precede the prefix-length parameter.
The route’s next-hop You can specify the next-hop gateway as one of the Mandatory for all static
gateway, which can be following types of IPv6 addresses: IPv6 routes.
one of the following:
• A global address.
• The IPv6 address of a • A link-local address.
next-hop gateway.
If you specify a global address, you do not need to specify
• A tunnel interface.
any additional parameters for the next-hop gateway.
• An Ethernet interface.
• A tunnel interface.
• A virtual interface (VE).
The route’s metric. You can specify a value from 1 - 16. Optional for all static
IPv6 routes. (The
default metric is 1.)
The route’s You must specify the distance keyword and any numerical Optional for all static
administrative distance. value. IPv6 routes. (The
default administrative
distance is 1.)
A metric is a value that the Layer 3 switch uses when comparing this route to other static routes in the
IPv6 static route table that have the same destination. The metric applies only to routes that the Layer
3 switch has already placed in the IPv6 static route table.
The administrative distance is a value that the Layer 3 switch uses to compare this route with routes
from other route sources that have the same destination. (The Layer 3 switch performs this
comparison before placing a route in the IPv6 route table.) This parameter does not apply to routes
that are already in the IPv6 route table. In general, a low administrative distance indicates a preferred
route. By default, static routes take precedence over routes learned by routing protocols. If you want a
dynamic route to be chosen over a static route, you can configure the static route with a higher
administrative distance than the dynamic route.
NOTE
The vrf needs to be a valid VRF to be used in this command.
NOTE
This feature is supported only with the IPv6 Layer 3 license on FSX devices and the full Layer 3 image
on other devices.
To enable communication between isolated IPv6 domains using the IPv4 infrastructure, you can
manually configure IPv6 over IPv4 tunnels that provide static point-point connectivity.
As shown in the following illustration, these tunnels encapsulate an IPv6 packet within an IPv4 packet.
In general, a manually configured tunnel establishes a permanent link between switches in IPv6
domains. A manually configured tunnel has explicitly configured IPv4 addresses for the tunnel source
and destination.
This tunneling mechanism requires that the Layer 3 switch at each end of the tunnel run both IPv4 and
IPv6 protocol stacks. The Layer 3 switches running both protocol stacks, or dual-stack routers, can
interoperate directly with both IPv4 and IPv6 end systems and routers. Refer to "Configuring IPv4 and
IPv6 protocol stacks" section in the FastIron Ethernet Switch Administration Guide.
device(config)#interface tunnel 1
device(config-tnif-1)#tunnel source ethernet 1/3/1
device(config-tnif-1)#tunnel destination 10.162.100.1
device(config-tnif-1)#tunnel mode ipv6ip
device(config-tnif-1)#ipv6 enable
This example creates tunnel interface 1 and assigns a link local IPv6 address with an automatically
computed EUI-64 interface ID to it. The IPv4 address assigned to Ethernet interface 1/3/1 is used as
the tunnel source, while the IPv4 address 10.168.100.1 is configured as the tunnel destination. The
tunnel mode is specified as a manual IPv6 tunnel. Finally, the tunnel is enabled. Note that instead of
entering ipv6 enable , you could specify an IPv6 address, for example, ipv6 address
2001:DB8:384d:34::/64 eui-64 , which would also enable the tunnel.
Syntax: [no] interfacetunnel number
For the number parameter, specify a value between 1-8.
Syntax: [no] tunnelsource ipv4-address | ethernet port | loopback number | ve number
The tunnel source can be an IP address or an interface.
For ipv4-address , use 8-bit values in dotted decimal notation.
The ethernet | loopback | ve parameter specifies an interface as the tunnel source. If you specify an
Ethernet interface, also specify the port number associated with the interface. If you specify a
loopback, VE, or interface, also specify the loopback, VE, or number, respectively.
Syntax: [no] tunneldestination ipv4-address
Specify the ipv4-address parameter using 8-bit values in dotted decimal notation.
Syntax: [no] tunnelmode ipv6ip
ipv6ip indicates that this is an IPv6 manual tunnel.
Syntax: ipv6 enable
The ipv6 enable command enables the tunnel. Alternatively, you could specify an IPv6 address, which
would also enable the tunnel.
Syntax: ipv6 address ipv6-prefix / prefix-length [ eui-64 ]
The ipv6 address command enables the tunnel. Alternatively, you could enter ipv6 enable , which
would also enable the tunnel.
Specify the ipv6-prefix parameter in hexadecimal format using 16-bit values between colons as
documented in RFC 2373.
Specify the prefix-length parameter as a decimal value. A slash mark (/) must follow the ipv6-prefix
parameter and precede the prefix-length parameter. The eui-64 keyword configures the global address
with an EUI-64 interface ID in the low-order 64 bits. The interface ID is automatically constructed in
IEEE EUI-64 format using the interface’s MAC address.
To clear statistics for all IPv6 tunnels, enter the following command.
Field Description
Field Description
Packet Received The number of packets received by a tunnel interface. Note that this is the number of packets
received by the CPU. It does not include the number of packets processed in hardware.
Packet Sent The number of packets sent by a tunnel interface. Note that this is the number of packets sent
by the CPU. It does not include the number of packets processed in hardware.
Field Description
Tunnel interface status The status of the tunnel interface can be one of the following:
Line protocol status The status of the line protocol can be one of the following:
• An IPv4 address
• The IPv4 address associated with an interface/port.
Field Description
Port name The port name configured for the tunnel interface.
Field Description
Interface Tunnel status The status of the tunnel interface can be one of the following:
• up - IPv4 connectivity is established.
• down - The tunnel mode is not set.
• administratively down - The tunnel interface was disabled with the disable command.
Line protocol status The status of the line protocol can be one of the following:
• up - IPv6 is enabled through the ipv6 enable or ipv6 address command.
• down - The line protocol is not functioning and is down.
● SNMP overview.............................................................................................................147
● SNMP community strings..............................................................................................147
● User-based security model........................................................................................... 150
● Defining SNMP views....................................................................................................154
● SNMP version 3 traps................................................................................................... 155
● Displaying SNMP Information....................................................................................... 159
● SNMP v3 configuration examples................................................................................. 160
SNMP overview
SNMP is a set of protocols for managing complex networks. SNMP sends messages, called protocol
data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data
about themselves in Management Information Bases (MIBs) and return this data to the SNMP
requesters.
"Security Access" chapter in the FastIron Ethernet Switch Security Configuration Guide introduced a
few methods used to secure SNMP access. They included the following:
• Using ACLs to restrict SNMP access
• Restricting SNMP access to a specific IP address
• Restricting SNMP access to a specific VLAN
• Disabling SNMP access
This section presents additional methods for securing SNMP access to Brocade devices.
Restricting SNMP access using ACL, VLAN, or a specific IP address constitute the first level of defense
when the packet arrives at a Brocade device. The next level uses one of the following methods:
• Community string match In SNMP versions 1 and 2
• User-based model in SNMP version 3
SNMP views are incorporated in community strings and the user-based model.
The Web Management Interface supports only one read-write session at a time. When a read-write
session is open on the Web Management Interface, subsequent sessions are read-only, even if the
session login is “set” with a valid read-write password.
NOTE
If you delete the startup-config file, the device automatically re-adds the default "public" read-only
community string the next time you load the software.
NOTE
As an alternative to the SNMP community strings, you can secure Web management access using
local user accounts or ACLs. Refer to Security Access chapter in the FastIron Ethernet Switch
Security Configuration Guide.
NOTE
If you issue a no snmp-server community public ro command and then enter a write memory
command to save that configuration, the "public" community name is removed and will have no SNMP
access. If for some reason the device is brought down and then brought up, the "no snmp-server
community public ro" command is restored in the system and the "public" community string has no
SNMP access.
The 0 | 1 parameter affects encryption for display of the string in the running-config and the startup-
config file. Encryption is enabled by default. When encryption is enabled, the community string is
encrypted in the CLI regardless of the access level you are using. In the Web Management Interface,
the community string is encrypted at the read-only access level but is visible at the read-write access
level.
The encryption option can be omitted (the default) or can be one of the following:
• 0 - Disables encryption for the community string you specify with the command. The community
string is shown as clear text in the running-config and the startup-config file. Use this option if you do
not want the display of the community string to be encrypted.
• 1 - Assumes that the community string you enter is encrypted, and decrypts the value before using it.
NOTE
If you want the software to assume that the value you enter is the clear-text form, and to encrypt display
of that form, do not enter 0 or 1 . Instead, omit the encryption option and allow the software to use the
default behavior.
NOTE
If you specify encryption option 1 , the software assumes that you are entering the encrypted form of the
community string. In this case, the software decrypts the community string you enter before using the
value for authentication. If you accidentally enter option 1 followed by the clear-text version of the
community string, authentication will fail because the value used by the software will not match the
value you intended to use.
The command in the example above adds the read-write SNMP community string "private". When you
save the new community string to the startup-config file (using the write memory command), the
software adds the following command to the file.
snmp-server community 1
encrypted-string
rw
To add a non-encrypted community string, you must explicitly specify that you do not want the software
to encrypt the string. Here is an example.
The command in this example adds the string "private" in the clear, which means the string is displayed
in the clear. When you save the new community string to the startup-config file, the software adds the
following command to the file.
The view viewname parameter is optional. It allows you to associate a view to the members of this
community string. Enter up to 32 alphanumeric characters. If no view is specified, access to the full MIB
is granted. The view that you want must exist before you can associate it to a community string. Here is
an example of how to use the view parameter in the community string command.
The command in this example associates the view "sysview" to the community string named "myread".
The community string has read-only access to "sysview". For information on how to create views, refer
to SNMP v3 configuration examples on page 160.
The standard-ACL-name | standard-ACL-id parameter is optional. It allows you to specify which ACL
group will be used to filter incoming SNMP packets. You can enter either the ACL name or its ID. Here
are some examples.
The command in the first example indicates that ACL group 2 will filter incoming SNMP packets;
whereas, the command in the second example uses the ACL group called "myACL" to filter incoming
packets.Refer to "Using ACLs to restrict SNMP access" section in the FastIron Ethernet Switch
Security Configuration Guide for more information.
NOTE
To make configuration changes, including changes involving SNMP community strings, you must first
configure a read-write community string using the CLI. Alternatively, you must configure another
authentication method and log on to the CLI using a valid password for that method.
NOTE
If display of the strings is encrypted, the strings are not displayed. Encryption is enabled by default.
SNMP version 3 also supports View-Based Access Control Mechanism (RFC 2575) to control access at
the PDU level. It defines mechanisms for determining whether or not access to a managed object in a
local MIB by a remote principal should be allowed. For more information, refer to SNMP v3
configuration examples on page 160.)
See the section Displaying the Engine ID on page 159 for details.
The default engine ID guarantees the uniqueness of the engine ID for SNMP version 3. If you want to
change the default engine ID, enter the snmp-server engineid local command.
NOTE
Each user localized key depends on the SNMP server engine ID, so all users need to be reconfigured
whenever the SNMP server engine ID changes.
NOTE
Since the current implementation of SNMP version 3 does not support Notification, remote engine IDs
cannot be configured at this time.
The hex-string variable consists of 11 octets, entered as hexadecimal values. There are two
hexadecimal characters in each octet. There should be an even number of hexadecimal characters in
an engine ID.
The default engine ID has a maximum of 11 octets:
• Octets 1 through 4 represent the agent's SNMP management private enterprise number as
assigned by the Internet Assigned Numbers Authority (IANA). The most significant bit of Octet 1 is
"1". For example, "000007c7" is the ID for Brocade Communications, Inc. in hexadecimal. With
Octet 1 always equal to "1", the first four octets in the default engine ID is always "800007c7" (which
is 1991 in decimal).
• Octet 5 is always 03 in hexadecimal and indicates that the next set of values represent a MAC
address.
• Octets 6 through 11 form the MAC address of the lowest port in the management module.
NOTE
Engine ID must be a unique number among the various SNMP engines in the management domain.
Using the default engine ID ensures the uniqueness of the numbers.
NOTE
This command is not used for SNMP version 1 and SNMP version 2. In these versions, groups and
group views are created internally using community strings. (refer to SNMP community strings on
page 147.) When a community string is created, two groups are created, based on the community
string name. One group is for SNMP version 1 packets, while the other is for SNMP version 2 packets.
The group groupname parameter defines the name of the SNMP group to be created.
The v1 , v2c , or v3 parameter indicates which version of SNMP is used. In most cases, you will be
using v3, since groups are automatically created in SNMP versions 1 and 2 from community strings.
The auth | noauth parameter determines whether or not authentication will be required to access the
supported views. If auth is selected, then only authenticated packets are allowed to access the view
specified for the user group. Selecting noauth means that no authentication is required to access the
specified view. Selecting priv means that an authentication password will be required from the users.
The access standard-ACL-id parameter is optional. It allows incoming SNMP packets to be filtered
based on the standard ACL attached to the group.
The ipv6 ipv6-ACL-name option configures IPv6 ACL for SNMP group and allows incoming SNMP
packets to be filtered based on the IPv6 ACL attached to the group.
The read viewname | write viewname parameter is optional. It indicates that users who belong to this
group have either read or write access to the MIB.
The viewname variable is the name of the view to which the SNMP group members have access. If no
view is specified, then the group has no access to the MIB.
The value of viewname is defined using the snmp-server view command. The SNMP agent comes
with the "all" default view, which provides access to the entire MIB; however, it must be specified when
creating the group. The "all" view also allows SNMP version 3 to be backwards compatibility with SNMP
version 1 and version 2.
NOTE
If you will be using a view other than the "all" view, that view must be configured before creating the
user group. Refer to the section SNMP v3 configuration examples on page 160, especially for details
on the include | exclude parameters.
device(config)#snmp-s user bob admin v3 access 2 auth md5 bobmd5 priv des bobdes
The CLI for creating SNMP version 3 users has been updated as follows.
Syntax: no snmp-server user name groupname v3 [ [ access standard-ACL-id ] [ [ encrypted ] [auth
md5 md5-password | sha sha-password ] [ priv [ encrypted ] des des-password-key | aes aes-
password-key ] ] ]
The name parameter defines the SNMP user name or security name used to access the management
module.
The groupname parameter identifies the SNMP group to which this user is associated or mapped. All
users must be mapped to an SNMP group. Groups are defined using the snmp-server group
command.
NOTE
The SNMP group to which the user account will be mapped should be configured before creating the
user accounts; otherwise, the group will be created without any views. Also, ACL groups must be
configured before configuring user accounts.
The access standard-ACL-id parameter is optional. It indicates that incoming SNMP packets are
filtered based on the ACL attached to the user account.
NOTE
The ACL specified in a user account overrides the ACL assigned to the group to which the user is
mapped. If no ACL is entered for the user account, then the ACL configured for the group will be used
to filter packets.
The encrypted parameter means that the MD5 or SHA password will be a digest value. MD5 has 16
octets in the digest. SHA has 20. The digest string has to be entered as a hexadecimal string. In this
case, the agent need not generate any explicit digest. If the encrypted parameter is not used, the user
is expected to enter the authentication password string for MD5 or SHA. The agent will convert the
password string to a digest, as described in RFC 2574.
The auth md5 | sha parameter is optional. It defines the type of encryption that the user must have to
be authenticated. Choose between MD5 or SHA encryption. MD5 and SHA are two authentication
protocols used in SNMP version 3.
The md5-password and sha-password define the password the user must use to be authenticated.
These password must have a minimum of 8 characters. If the encrypted parameter is used, then the
digest has 16 octets for MD5 or 20 octets for SHA.
NOTE
Once a password string is entered, the generated configuration displays the digest (for security
reasons), not the actual password.
The priv [encrypted] parameter is optional after you enter the md5 or sha password. The priv
parameter specifies the encryption type (DES or AES) used to encrypt the privacy password. If the
encrypted keyword is used, do the following:
• If DES is the privacy protocol to be used, enter des followed by a 16-octet DES key in hexadecimal
format for the des-password-key . If you include the encrypted keyword, enter a password string of
at least 8 characters.
• If AES is the privacy protocol to be used, enter aes followed by the AES password key. For a small
password key, enter 12 characters. For a big password key, enter 16 characters. If you include the
encrypted keyword, enter a password string containing 32 hexadecimal characters.
device(config)#system-max view 15
This command specifies the maximum number of SNMPv2 and v3 views that can be configured on a
device. The number of views can be from 10 - 65536. The default is 10 views.
To add an SNMP view, enter one of the following commands.
NOTE
The snmp-server view command supports the MIB objects as defined in RFC 1445.
NOTE
All MIB objects are automatically excluded from any view unless they are explicitly included; therefore,
when creating views using the snmp-server view command, indicate which portion of the MIB you
want users to access.
For example, you may want to assign the view called "admin" a community string or user group. The
"admin" view will allow access to the Brocade MIBs objects that begin with the 1.3.6.1.4.1.1991 object
identifier. Enter the following command.
You can exclude portions of the MIB within an inclusion scope. For example, if you want to exclude the
snAgentSys objects, which begin with 1.3.6.1.4.1.1991.1.1.2 object identifier from the admin view, enter
a second command such as the following.
NOTE
Note that the exclusion is within the scope of the inclusion.
Syntax: [no] snmp-server host ip-addr | ipv6-addr version [v1 | v2c community-string | v3 auth |
noauth | priv security-name ] [ port trap-UDP-port-number ]
The ip-addr parameter specifies the IP address of the host that will receive the trap.
For version , indicate one of the following
For SNMP version 1, enter v1 and the name of the community string ( community-string ). This string
is encrypted within the system.
NOTE
If the configured version is v2c, then the notification is sent out in SMIv2 format, using the community
string, but in cleartext mode. To send the SMIv2 notification in SNMPv3 packet format, configure v3 with
auth or privacy parameters, or both, by specifying a security name. The actual authorization and privacy
values are obtained from the security name.
For SNMP version 2c, enter v2 and the name of the community string. This string is encrypted within
the system.
For SNMP version 3, enter one of the following depending on the authorization required for the host:
• ‐ v3 auth security-name : Allow only authenticated packets.
‐ v3 no auth security-name : Allow all packets.
‐ v3 priv security-name : A password is required
For port trap-UDP-port-number , specify the UDP port number on the host that will receive the trap.
none If the security model shows v1 or v2, then security level is blank. User names are not used to
authenticate users; community strings are used instead.
noauthNoPriv Displays if the security model shows v3 and user authentication is by user name only.
authNoPriv Displays if the security model shows v3 and user authentication is by user name and the MD5 or
SHA algorithm.
username = bob
ACL id = 2
group = admin
security model = v3
group ACL id = 0
authtype = md5
authkey = 3aca18d90b8d172760e2dd2e8f59b7fe
privtype = des, privkey = 1088359afb3701730173a6332d406eec
engine ID= 800007c70300e052ab0000
1. 3. 6. 1. 6. 3. 12. 1. 5. 0 The value of the varbind shows the engine ID that needs to be used in the snmp-
server engineid command
1. 3. 6. 1. 6. 3. 15. 1. 1. 4. 0 Unknown engine ID. The value of this varbind would be the correct authoritative
engineID that should be used.
Example 1
device(config)#snmp-s group admingrp v3 priv read all write all notify all
device(config)#snmp-s user adminuser admingrp v3 auth md5
auth password
priv
privacy password
device(config)#snmp-s host
dest-ip
version v3 privacy adminuser
Example 2
device(config)#snmp-server view internet internet included
device(config)#snmp-server view system system included
device(config)#snmp-server community ..... ro
device(config)#snmp-server community ..... rw
device(config)#snmp-server contact isc-operations
device(config)#snmp-server location sdh-pillbox
device(config)#snmp-server host 128.91.255.32 .....
device(config)#snmp-server group ops v3 priv read internet write system
device(config)#snmp-server group admin v3 priv read internet write internet
device(config)#snmp-server group restricted v3 priv read internet
device(config)#snmp-server user ops ops v3 encrypted auth md5
ab8e9cd6d46e7a270b8c9549d92a069 priv encrypted des 0e1b153303b6188089411447dbc32de
device(config)#snmp-server user admin admin v3 encrypted auth md5
0d8a2123f91bfbd8695fef16a6f4207b priv encrypted des 18e0cf359fce4fcd60df19c2b6515448
device(config)#snmp-server user restricted restricted v3 encrypted auth md5
261fd8f56a3ad51c8bcec1e4609f54dc priv encrypted des d32e66152f89de9b2e0cb17a65595f43
FDP Overview
The Foundry Discovery Protocol (FDP) enables Brocade devices to advertise themselves to other
Brocade devices on the network. When you enable FDP on a Brocade device, the device periodically
advertises information including the following:
• Hostname (device ID)
• Product platform and capability
• Software version
• VLAN and Layer 3 protocol address information for the port sending the update. IP, IPX, and
AppleTalk Layer 3 information is supported.
A Brocade device running FDP sends FDP updates on Layer 2 to MAC address 00-00-00-CC-CC-CC.
Other Brocade devices listening on that address receive the updates and can display the information in
the updates. Brocade devices can send and receive FDP updates on Ethernet interfaces.
FDP is disabled by default.
NOTE
If FDP is not enabled on a Brocade device that receives an FDP update or the device is running a
software release that does not support FDP, the update passes through the device at Layer 2.
FDP configuration
The following sections describe how to enable Foundry Discovery Protocol (FDP) and how to change
the FDP update and hold timers.
To configure a Layer 3 switch to advertise the IPv6 address, enter the following command at the
Interface level of the CLI:
To change the FDP hold time, enter the fdp holdtime command at the global CONFIG level of the CLI.
NOTE
If the Brocade device has intercepted CDP updates, then the CDP information is also displayed.
Local Int The interface on which this Brocade device received an FDP or CDP update for the neighbor.
Holdtm The maximum number of seconds this device can keep the information received in the update before
discarding it.
Port ID The interface through which the neighbor sent the update.
To display detailed information, enter the show fdp neighbor detail command.
The show fdp neighbor detail command displays the following information.
Parameter Definition
Device ID The hostname of the neighbor. In addition, this line lists the VLAN memberships and other
VLAN information for the neighbor port that sent the update to this device.
Entry address(es) The Layer 3 protocol addresses configured on the neighbor port that sent the update to this
device. If the neighbor is a Layer 2 Switch, this field lists the management IP address.
Interface The interface on which this device received an FDP or CDP update for the neighbor.
Port ID The interface through which the neighbor sent the update.
Holdtime The maximum number of seconds this device can keep the information received in the update
before discarding it.
This example shows information for Ethernet port 2/3. The port sends FDP updates every 5 seconds.
Neighbors that receive the updates can hold them for up to 180 seconds before discarding them.
Syntax: show fdp interface [ ethernet port ]
The ethernet port parameter lists the information only for the specified interface.
NOTE
This command clears all the updates for FDP and CDP.
CDP packets
Cisco Discovery Protocol (CDP) packets are used by Cisco devices to advertise themselves to other
Cisco devices. By default, Brocade devices forward these packets without examining their contents.
You can configure a Brocade device to intercept and display the contents of CDP packets. This
feature is useful for learning device and interface information for Cisco devices in the network.
Brocade devices support intercepting and interpreting CDP version 1 and CDP version 2 packets.
NOTE
The Brocade device can interpret only the information fields that are common to both CDP version 1
and CDP version 2.
NOTE
When you enable interception of CDP packets, the Brocade device drops the packets. As a result,
Cisco devices will no longer receive the packets.
Displaying neighbors
To display the Cisco neighbors the Brocade device has learned from CDP packets, enter the show fdp
neighbors command.
To display detailed information for the neighbors, enter the show fdp neighbors detail command.
To display information about a neighbor attached to a specific port, enter a command such as the
following.
To display CDP entries for a specific device, specify the device ID, as shown in the following example.
TTL (Time-to-Live) - Specifies the length of time that the receiving device should maintain the
information acquired through LLDP in its MIB.
LLDP overview
LLDP enables a station attached to an IEEE 802 LAN/MAN to advertise its capabilities to, and to
discover, other stations in the same 802 LAN segments.
The information distributed by LLDP (the advertisement) is stored by the receiving device in a
standard Management Information Base (MIB), accessible by a Network Management System (NMS)
using a management protocol such as the Simple Network Management Protocol (SNMP). The
information also can be viewed from the CLI, using show LLDP commands.
The following diagram illustrates LLDP connectivity
Benefits of LLDP
LLDP provides the following benefits:
• Network Management:
‐ Simplifies the use of and enhances the ability of network management tools in multi-vendor
environments
‐ Enables discovery of accurate physical network topologies such as which devices are
neighbors and through which ports they connect
‐ Enables discovery of stations in multi-vendor environments
• Network Inventory Data:
‐ Supports optional system name, system description, system capabilities and management
address
‐ System description can contain the device product name or model number, version of
hardware type, and operating system
‐ Provides device capability, such as switch, router, or WLAN access point
• Network troubleshooting:
‐ Information generated by LLDP can be used to detect speed and duplex mismatches
‐ Accurate topologies simplify troubleshooting within enterprise networks
‐ Can discover devices with misconfigured or unreachable IP addresses
LLDP-MED overview
LLDP-MED is an extension to LLDP. This protocol enables advanced LLDP features in a Voice over IP
(VoIP) network. Whereas LLDP enables network discovery between Network Connectivity devices,
LLDP-MED enables network discovery between Network Connectivity devices and media Endpoints
such as, IP telephones, softphones, VoIP gateways and conference bridges.
The following diagram illustrates LLDP-MED connectivity.
Benefits of LLDP-MED
LLDP-MED provides the following benefits:
• Vendor-independent management capabilities, enabling different IP telephony systems to
interoperate in one network.
• Automatically deploys network policies, such as Layer 2 and Layer 3 QoS policies and Voice
VLANs.
• Supports E-911 Emergency Call Services (ECS) for IP telephony
• Collects Endpoint inventory information
• Network troubleshooting
‐ Helps to detect improper network policy configuration
LLDP-MED class
An LLDP-MED class specifies an Endpoint type and its capabilities. An Endpoint can belong to one of
three LLDP-MED class types:
• Class 1 (Generic endpoint) - A Class 1 Endpoint requires basic LLDP discovery services, but does
not support IP media nor does it act as an end-user communication appliance. A Class 1 Endpoint
formatting errors, are assumed to be valid and are assigned a temporary identification index and
stored for future possible alter retrieval by network management. All validated TLVs are stored in the
neighbor database.
LLDP packets
LLDP agents transmit information about a sending device/port in packets called LLDP Data Units
(LLDPDUs). All the LLDP information to be communicated by a device is contained within a single
1500 byte packet. A device receiving LLDP packets is not permitted to combine information from
multiple packets.
As shown in the following figure, each LLDPDU has three mandatory TLVs, an End of LLDPDU TLV,
plus optional TLVs as selected by network management.
Each LLDPDU consists of an untagged Ethernet header and a sequence of short, variable length
information elements known as type, length, value (TLV).
TLVs have Type, Length, and Value fields, where:
• Type identifies the kind of information being sent
• Length indicates the length (in octets) of the information string
• Value is the actual information being sent (for example, a binary bit map or an alpha-numeric string
containing one or more fields).
TLV support
This section lists the LLDP and LLDP-MED TLV support.
LLDP TLVs
There are two types of LLDP TLVs, as specified in the IEEE 802.3AB standard:
• Basic management TLVs consist of both optional general system information TLVs as well as
mandatory TLVs.
Mandatory TLVs cannot be manually configured. They are always the first three TLVs in the LLDPDU,
and are part of the packet header.
General system information TLVs are optional in LLDP implementations and are defined by the
Network Administrator.
Brocade devices support the following Basic Management TLVs:
• ‐ Chassis ID (mandatory)
‐ Port ID (mandatory)
‐ Time to Live (mandatory)
‐ Port description
‐ System name
‐ System description
‐ System capabilities
‐ Management address
‐ End of LLDPDU
• Organizationally-specific TLVs are optional in LLDP implementations and are defined and encoded
by individual organizations or vendors. These TLVs include support for, but are not limited to, the
IEEE 802.1 and 802.3 standards and the TIA-1057 standard.
Brocade devices support the following Organizationally-specific TLVs:
• ‐ 802.1 organizationally-specific TLVs
Port VLAN ID
VLAN name TLV
• ‐ 802.3 organizationally-specific TLVs
MAC/PHY configuration/status
Power through MDI
Link aggregation
Maximum frame size
LLDP-MED TLVs
Brocade devices honor and send the following LLDP-MED TLVs, as defined in the TIA-1057 standard:
• LLDP-MED capabilities
• Network policy
• Location identification
• Extended power-via-MDI
Mandatory TLVs
When an LLDP agent transmits LLDP packets to other agents in the same 802 LAN segments, the
following mandatory TLVs are always included:
• Chassis ID
• Port ID
• Time to Live (TTL)
This section describes the above TLVs in detail.
Chassis ID
The Chassis ID identifies the device that sent the LLDP packets.
There are several ways in which a device may be identified. A chassis ID subtype, included in the TLV
and shown in the following table, indicates how the device is being referenced in the Chassis ID field.
ID subtype Description
0 Reserved
1 Chassis component
2 Interface alias
3 Port component
4 MAC address
5 Network address
6 Interface name
7 Locally assigned
8 - 255 Reserved
Brocade devices use chassis ID subtype 4, the base MAC address of the device. Other third party
devices may use a chassis ID subtype other than 4. The chassis ID will appear similar to the following
on the remote device, and in the CLI display output on the Brocade device (show lldp local-info ).
Port ID
The Port ID identifies the port from which LLDP packets were sent.
There are several ways in which a port may be identified, as shown in the following table. A port ID
subtype, included in the TLV, indicates how the port is being referenced in the Port ID field.
ID subtype Description
0 Reserved
1 Interface alias
2 Port component
3 MAC address
4 Network address
5 Interface name
ID subtype Description
6 Agent circuit ID
7 Locally assigned
8 - 255 Reserved
Brocade devices use port ID subtype 3, the permanent MAC address associated with the port. Other
third party devices may use a port ID subtype other than 3. The port ID appears similar to the following
on the remote device, and in the CLI display output on the Brocade device (show lldp local-info).
TTL value
The Time to Live (TTL) Value is the length of time the receiving device should maintain the information
acquired by LLDP in its MIB.
The TTL value is automatically computed based on the LLDP configuration settings. The TTL value will
appear similar to the following on the remote device, and in the CLI display output on the Brocade
device (show lldp local-info).
If the TTL field has a value other than zero, the receiving LLDP agent is notified to completely replace
all information associated with the LLDP agent/port with the information in the received LLDPDU.
If the TTL field value is zero, the receiving LLDP agent is notified that all system information associated
with the LLDP agent/port is to be deleted. This TLV may be used, for example, to signal that the
sending port has initiated a port shutdown procedure.
The LLDPDU format is shown in LLDP packets on page 178.
The TTL TLV format is shown below.
MIB support
Brocade devices support the following standard management information base (MIB) modules:
• LLDP-MIB
• LLDP-EXT-DOT1-MIB
• LLDP-EXT-DOT3-MIB
• LLDP-EXT-MED-MIB
Syslog messages
Syslog messages for LLDP provide management applications with information related to MIB data
consistency and general status. These Syslog messages correspond to the lldpRemTablesChange
SNMP notifications. Refer to Enabling LLDP SNMP notifications and Syslog messages on page 187.
Syslog messages for LLDP-MED provide management applications with information related to
topology changes. These Syslog messages correspond to the lldpXMedTopologyChangeDetected
SNMP notifications. Refer to Enabling SNMP notifications and Syslog messagesfor LLDP-MED
topology changes on page 197.
LLDP configuration
This section describes how to enable and configure LLDP.
The following table lists the LLDP global-level tasks and the default behavior/value for each task.
Specifying the maximum number of LLDP Automatically set to 392 neighbors per device
neighbors per device
TABLE 23 LLDP global configuration tasks and default behavior /value (Continued)
Specifying the maximum number of LLDP Automatically set to 4 neighbors per port
neighbors per port
Changing the minimum time between SNMP traps Automatically set to 2 seconds when SNMP notifications and
and Syslog messages Syslog messages for LLDP are enabled
Enabling and disabling TLV advertisements When LLDP transmit is enabled, by default, the Brocade
device will automatically advertise LLDP capabilities, except
for the system description, VLAN name, and power-via-MDI
information, which may be configured by the system
administrator.
Also, if desired, you can disable the advertisement of
individual TLVs.
To enable LLDP globally, enter the following command at the global CONFIG level of the CLI.
device(config)#lldp run
You can configure a different operating mode for each port on the Brocade device. For example, you
could disable the receipt and transmission of LLDP packets on port e 2/1, configure port e 2/3 to only
receive LLDP packets, and configure port e 2/5 to only transmit LLDP packets.
The following sections show how to change the operating mode.
The above command disables LLDP on ports 2/4 and 2/5. These ports will not transmit nor receive
LLDP packets.
To enable LLDP on a port after it has been disabled, enter the following command.
NOTE
When a port is configured to both receive and transmit LLDP packets and the MED capabilities TLV is
enabled, LLDP-MED is enabled as well. LLDP-MED is not enabled if the operating mode is set to
receive only or transmit only.
The above command changes the LLDP operating mode on ports 2/4, 2/5, and 2/6 from transmit and
receive mode to receive only mode.
To change a port LLDP operating mode from transmit only to receive only, first disable the transmit only
mode, then enable the receive only mode. Enter commands such as the following.
The above commands change the LLDP operating mode on ports 2/7, 2/8, and 2/9, from transmit only
to receive only. Note that if you do not disable the transmit only mode, you will configure the port to both
transmit and receive LLDP packets.
NOTE
LLDP-MED is not enabled when you enable the receive only operating mode. To enable LLDP-MED,
you must configure the port to both receive and transmit LLDP packets. Refer to Changing a port LLDP
operating mode.
The above command changes the LLDP operating mode on ports 2/4, 2/5, and 2/6 from transmit and
receive mode to transmit only mode. Any incoming LLDP packets will be dropped in software.
To change a port LLDP operating mode from receive only to transmit only, first disable the receive only
mode, then enable the transmit only mode. For example, enter commands such as the following at the
Global CONFIG level of the CLI.
The above commands change the LLDP operating mode on ports 2/7 and 2/8 from receive only mode
to transmit only mode. Any incoming LLDP packets will be dropped in software. Note that if you do not
disable receive only mode, you will configure the port to both receive and transmit LLDP packets.
NOTE
LLDP-MED is not enabled when you enable the transmit only operating mode. To enable LLDP-MED,
you must configure the port to both receive and transmit LLDP packets. Refer to Changing a port
LLDP operating mode.
Syntax: [no] lldp enabletransmit ports ethernet port-list | all
Use the [no] form of the command to disable the transmit only mode.
NOTE
If lldp-pass-through is disabled, the neighboring information is lost only after LLDP timeout period
(default is 120).
device(config)#lldp max-total-neighbors 26
device(config)#lldp max-neighbors-per-port 6
The above command enables SNMP notifications and corresponding Syslog messages on ports 4/2
and 4/6. By default, the device will send no more than one SNMP notification and Syslog message
within a five second period. If desired, you can change this interval. Refer to Specifying the minimum
time between SNMP traps and Syslog messages on page 188.
Syntax: [no] lldp enablesnmp notifications ports ethernet port-list | all
Specifying the minimum time between SNMP traps and Syslog messages
When SNMP notifications and Syslog messages for LLDP are enabled, the device will send no more
than one SNMP notification and corresponding Syslog message within a five second period. If desired,
you can throttle the amount of time between transmission of SNMP traps (lldpRemTablesChange) and
Syslog messages from five seconds up to a value equal to one hour (3600 seconds).
NOTE
Because LLDP Syslog messages are rate limited, some LLDP information given by the system will not
match the current LLDP statistics (as shown in the show lldp statistics command output).
To change the minimum time interval between traps and Syslog messages, enter a command such as
the following.
device(config)#lldp snmp-notification-interval 60
When the above command is applied, the LLDP agent will send no more than one SNMP notification
and Syslog message every 60 seconds.
Syntax: [no] lldp snmp-notification-interval seconds
where seconds is a value between 5 and 3600. The default is 5 seconds.
NOTE
The LLDP transmit delay timer must not be greater than one quarter of the LLDP transmission interval
(CLI command lldp transmit-interval ).
The LLDP transmit delay timer prevents an LLDP agent from transmitting a series of successive LLDP
frames during a short time period, when rapid changes occur in LLDP. It also increases the probability
that multiple changes, rather than single changes, will be reported in each LLDP frame.
To change the LLDP transmit delay timer, enter a command such as the following at the Global
CONFIG level of the CLI.
device(config)#lldp transmit-delay 7
The above command causes the LLDP agent to wait a minimum of seven seconds after transmitting
an LLDP frame and before sending another LLDP frame.
Syntax: [no] lldp transmit-delay seconds
where seconds is a value between 1 and 8192. The default is two seconds. Note that this value must
not be greater than one quarter of the LLDP transmission interval (CLI command lldp transmit-
interval ).
device(config)#lldp transmit-interval 40
The above command causes the LLDP agent to transmit LLDP frames every 40 seconds.
Syntax:[no] lldp transmit-interval seconds
where seconds is a value from 5 to 32768. The default is 30 seconds.
NOTE
Setting the transmit interval or transmit holdtime multiplier, or both, to inappropriate values can cause
the LLDP agent to transmit LLDPDUs with TTL values that are excessively high. This in turn can affect
how long a receiving device will retain the information if it is not refreshed.
device(config)#lldp transmit-hold 6
NOTE
Setting the transmit interval or transmit holdtime multiplier, or both, to inappropriate values can cause
the LLDP agent to transmit LLDPDUs with TTL values that are excessively high. This in turn can affect
how long a receiving device will retain the information if it is not refreshed.
To set the re-initialization delay timer, enter a command such as the following at the Global CONFIG
level of the CLI.
device(config)#lldp reinit-delay 5
The above command causes the device to wait five seconds after LLDP is disabled, before attempting
to honor a request to re-enable it.
Syntax: [no] lldp reinit-delay seconds
where seconds is a value from 1 - 10. The default is two seconds.
NOTE
The system description, VLAN name, and power-via-MDI information TLVs are not automatically
enabled. The following sections show how to enable these advertisements.
Management Address
A management address is normally an IPv4 or IPv6 address that can be used to manage the device.
Management address advertising has two modes: default, or explicitly configured. The default mode is
used when no addresses are configured to be advertised for a given port. If any addresses are
configured to be advertised for a given port, then only those addresses are advertised. This applies
across address types, so for example, if just one IPv4 address is explicitly configured to be advertised
for a port, then no IPv6 addresses will be advertised for that port (since none were configured to be
advertised), even if IPv6 addresses are configured within the system.
If no management address is explicitly configured to be advertised, the Brocade device will use the first
available IPv4 address and the first available IPv6 address (so it may advertise IPv4, IPv6 or both). A
Layer 3 switch will select the first available address of each type from those configured on the following
types of interfaces, in the following order of preference:
• Physical port on which LLDP will be transmitting the packet
• Virtual router interface (VE) on a VLAN that the port is a member of
• Dedicated management port
• Loop back interface
• Virtual router interface (VE) on any other VLAN
• Other physical port
• Other interface
For IPv6 addresses, link-local and anycast addresses will be excluded from these searches.
If no IP address is configured on any of the above, the port's current MAC address will be advertised.
To advertise a IPv4 management address, enter a command such as the following:
The management address will appear similar to the following on the remote device, and in the CLI
display output on the Brocade device (show lldp local-info ):
Syntax:[no] lldp advertise management-address ipv4 ipv4 address ports ethernet port list | all
To support an IPv6 management address, there is a similar command that has equivalent behavior as
the IPv4 command.
To advertise an IPv6 management address, enter a command such as the following:
Syntax:[no] lldp advertise management-address ipv6 ipv6 address ports ethernet port list | all
ipv4 address or ipv6 address or both are the addresses that may be used to reach higher layer entities
to assist discovery by network management. In addition to management addresses, the advertisement
will include the system interface number associated with the management address.
For port list , specify the port(s) in the format [ slotnum /] portnum , where slotnum is required on
chassis devices only. You can list all of the ports individually; use the keyword to specify a range of
ports, or a combination of both. To apply the configuration to all ports on the device, use the keyword all
instead of listing the ports individually.
Port description
The port description TLV identifies the port from which the LLDP agent transmitted the advertisement.
The port description is taken from the ifDescr MIB object from MIB-II.
By default, the port description is automatically advertised when LLDP is enabled on a global basis. To
disable advertisement of the port description, enter a command such as the following.
The port description will appear similar to the following on the remote device, and in the CLI display
output on the Brocade device (show lldp local-info ).
System capabilities
The system capabilities TLV identifies the primary functions of the device and indicates whether these
primary functions are enabled. The primary functions can be one or more of the following (more than
one for example, if the device is both a bridge and a router):
• Repeater
• Bridge
• WLAN access point
• Router
• Telephone
• DOCSIS cable device
• Station only (devices that implement end station capability)
• Other
System capabilities for Brocade devices are based on the type of software image in use (e.g., Layer 2
switch or Layer 3 router). The enabled capabilities will be the same as the available capabilities,
except that when using a router image (base or full Layer 3), if the global route-only feature is turned
on, the bridge capability will not be included, since no bridging takes place.
By default, the system capabilities are automatically advertised when LLDP is enabled on a global
basis. To disable this advertisement, enter a command such as the following.
The system capabilities will appear similar to the following on the remote device, and in the CLI display
output on the Brocade device (show lldp local-info ).
System description
The system description is the network entity, which can include information such as the product name
or model number, the version of the system hardware type, the software operating system level, and
the networking software version. The information corresponds to the sysDescr MIB object in MIB-II.
To advertise the system description, enter a command such as the following.
The system description will appear similar to the following on the remote device, and in the CLI display
output on the Brocade device (show lldp local-info ).
NOTE
The contents of the show command output will vary depending on which TLVs are configured to be
advertised.
System name
The system name is the system administratively assigned name, taken from the sysName MIB object in
MIB-II. The sysName MIB object corresponds to the name defined with the CLI command hostname .
By default, the system name is automatically advertised when LLDP is enabled on a global basis. To
disable this advertisement, enter a command such as the following.
The system name will appear similar to the following on the remote device, and in the CLI display output
on the Brocade device (show lldp local-info ).
802.1 capabilities
Except for the VLAN name, the Brocade device will advertise the following 802.1 attributes when LLDP
is enabled on a global basis:
• VLAN name (not automatically advertised)
• Untagged VLAN ID
VLAN name
The VLAN name TLV contains the name and VLAN ID of a VLAN configured on a port. An LLDPDU
may include multiple instances of this TLV, each for a different VLAN.
To advertise the VLAN name, enter a command such as the following.
The VLAN name will appear similar to the following on the remote device, and in the CLI display output
on the Brocade device (show lldp local-info ).
Syntax:[no] lldp advertise vlan-name vlan vlan ID ports ethernet port-list | all
Forvlan ID , enter the VLAN ID to advertise.
Untagged VLAN ID
The port VLAN ID TLV advertises the Port VLAN Identifier (PVID) that will be associated with
untagged or priority-tagged frames. If the port is not an untagged member of any VLAN (i.e., the port is
strictly a tagged port), the value zero will indicate that.
By default, the port VLAN ID is automatically advertised when LLDP is enabled on a global basis. To
disable this advertisement, enter a command such as the following.
The untagged VLAN ID will appear similar to the following on the remote device, and in the CLI display
output on the Brocade device (show lldp local-info ).
802.3 capabilities
Except for Power-via-MDI information, the Brocade device will advertise the following 802.3 attributes
when LLDP is enabled on a global basis:
• Link aggregation information
• MAC/PHY configuration and status
• Maximum frame size
• Power-via-MDI information (not automatically advertised)
The MAC and PHY configuration and status TLV includes the following information:
• Auto-negotiation capability and status
• Speed and duplex mode
• Flow control capabilities for auto-negotiation
The MAC/PHY configuration advertisement will appear similar to the following on the remote device,
and in the CLI display output on the Brocade device (show lldp local-info ).
The maximum frame size TLV provides the maximum 802.3 frame size capability of the port. This value
is expressed in octets and includes the four-octet Frame Check Sequence (FCS). The default maximum
frame size is 1522. The advertised value may change depending on whether the aggregated-vlan or
jumbo CLI commands are in effect.
NOTE
On 48GC modules in non-jumbo mode, the maximum size of ping packets is 1486 bytes and the
maximum frame size of tagged traffic is no larger than 1581 bytes.
By default, the maximum frame size is automatically advertised when LLDP is enabled on a global
basis. To disable this advertisement, enter a command such as the following.
The maximum frame size advertisement will appear similar to the following on the remote device, and in
the CLI display output on the Brocade device (show lldp local-info ).
Power-via-MDI
The power-via-MDI TLV provides general information about Power over Ethernet (POE) capabilities and
status of the port. It indicates the following:
• POE capability (supported or not supported)
• POE status (enabled or disabled)
• Power Sourcing Equipment (PSE) power pair - indicates which pair of wires is in use and whether
the pair selection can be controlled. The Brocade implementation always uses pair A, and cannot
be controlled.
• Power class - Indicates the range of power that the connected powered device has negotiated or
requested.
NOTE
The power-via-MDI TLV described in this section applies to LLDP. There is also a power-via-MDI TLV
for LLDP-MED devices, which provides extensive POE information. Refer to Extended power-via-MDI
information on page 207.
The power-via-MDI advertisement will appear similar to the following on the remote device, and in the
CLI display output on the Brocade device (show lldp local-info ).
LLDP-MED configuration
This section provides the details for configuring LLDP-MED.
The following table lists the global and interface-level tasks and the default behavior/value for each
task.
Changing the Fast Start Repeat Count The system automatically sets the fast start repeat count to 3 when a
Network Connectivity Device receives an LLDP packet from an
Endpoint that is newly connected to the network.
NOTE
The LLDP-MED fast start mechanism is only intended to run on links
between Network Connectivity devices and Endpoint devices. It does
not apply to links between LAN infrastructure elements, including
between Network Connectivity devices, or to other types of links.
Interface-level tasks
Enabling LLDP-MED
When LLDP is enabled globally, LLDP-MED is enabled if the LLDP-MED capabilities TLV is also
enabled. By default, the LLDP-MED capabilities TLV is automatically enabled. To enable LLDP, refer to
Enabling and disabling LLDP on page 183.
NOTE
LLDP-MED is not enabled on ports where the LLDP operating mode is receive only or transmit only.
LLDP-MED is enabled on ports that are configured to both receive and transmit LLDP packets and have
the LLDP-MED capabilities TLV enabled.
NOTE
The LLDP-MED fast start mechanism is only intended to run on links between Network Connectivity
devices and Endpoint devices. It does not apply to links between LAN infrastructure elements,
including between Network Connectivity devices, or to other types of links.
To change the LLDP-MED fast start repeat count, enter commands such as the following.
The above command causes the device to send five LLDP packets during the LLDP-MED fast start
period.
Syntax: [no] lldp medfast-start-repeat-count value
where value is a number from 1 to 10, which specifies the number of packets that will be sent during
the LLDP-MED fast start period. The default is 3.
Defining a location id
The LLDP-MED Location Identification extension enables the Brocade device to set the physical
location that an attached Class III Endpoint will use for location-based applications. This feature is
important for applications such as IP telephony, for example, where emergency responders need to
quickly determine the physical location of a user in North America that has just dialed 911.
For each port, you can define one or more of the following location ID formats:
• Geographic location (coordinate-based)
• Civic address
• Emergency Call Services (ECS) Emergency Location Identification Number (ELIN)
The above location ID formats are defined in the following sections.
Coordinate-based location
Coordinate-based location is based on the IETF RFC 3825 [6] standard, which specifies a Dynamic
Host Configuration Protocol (DHCP) option for the coordinate-based geographic location of a client.
When you configure an Endpoint location information using the coordinate-based location, you specify
the latitude, longitude, and altitude, along with resolution indicators (a measure of the accuracy of the
coordinates), and the reference datum (the map used for the given coordinates).
To configure a coordinate-based location for an Endpoint device, enter a command such as the
following at the Global CONFIG level of the CLI.
Syntax: [no] lldp med location-id coordinate-based latitude degrees resolution bits longitude
degrees resolution bits altitude floors number resolution bits | meters number resolution bits
datum
latitude degrees is the angular distance north or south from the earth equator measured through 90
degrees. Positive numbers indicate a location north of the equator and negative numbers indicate a
location south of the equator.
resolution bits specifies the precision of the value given for latitude. A smaller value increases the area
within which the device is located. For latitude, enter a number between 1 and 34.
longitude degrees is the angular distance from the intersection of the zero meridian. Positive values
indicate a location east of the prime meridian and negative numbers indicate a location west of the
prime meridian.
resolution bits specifies the precision of the value given for longitude. A smaller value increases the
area within which the device is located. For longitude resolution, enter a number between 1 and 34.
altitude floors number is the vertical elevation of a building above the ground, where 0 represents the
floor level associated with the ground level at the main entrance and larger values represent floors that
are above (higher in altitude) floors with lower values. For example, 2 for the 2nd floor. Sub-floors can
be represented by non-integer values. For example, a mezzanine between floor 1 and floor 2 could be
represented as 1.1. Similarly, the mezzanines between floor 4 and floor 5 could be represented as 4.1
and 4.2 respectively. Floors located below ground level could be represented by negative values.
resolution bits specifies the precision of the value given for altitude. A smaller value increases the area
within which the device is located. For floors resolution, enter the value 0 if the floor is unknown, or 30 if
a valid floor is being specified.
altitude meters number is the vertical elevation in number of meters, as opposed to floors.
resolution bits specifies the precision of the value given for altitude. A smaller value increases the area
within which the device is located. For meters resolution, enter a value from 0 to 30.
Datum is the map used as the basis for calculating the location. Specify one of the following:
• wgs84 - (geographical 3D) - World Geodesic System 1984, CRS Code 4327, Prime Meridian Name:
Greenwich
• nad83-navd88 - North American Datum 1983, CRS Code 4269, Prime Meridian Name: Greenwich;
The associated vertical datum is the North American Vertical Datum of 1988 (NAVD88). Use this
datum when referencing locations on land. If land is near tidal water, use nad83-mllw (below).
• nad83-mllw - North American Datum 1983, CRS Code 4269, Prime Meridian Name: Greenwich; The
associated vertical datum is mean lower low water (MLLW). Use this datum when referencing
locations on water, sea, or ocean.
The following shows an example coordinate-based location configuration for the Sears Tower, at the
following location.
103rd Floor233 South Wacker DriveChicago, IL 60606
The coordinate-based location advertisement will appear similar to the following on the remote device,
and in the CLI display output on the Brocade device (show lldp local-info ).
+ MED Location ID
Syntax: [no] lldp med location-id civic-address refers-to elem country country code elem CA type
value [ elem CA type value ] [ elem CA type value ] ....
refers-to elem describes the location that the entry refers to. Specify one of the following:
• client
• dhcp-server
• network-element
where dhcp-server or network-element should only be used if it is known that the Endpoint is in
close physical proximity to the DHCP server or network element.
country code is the two-letter ISO 3166 country code in capital ASCII letters.
• CA - Canada
• DE - Germany
• JP - Japan
• KR - Korea
• US - United States
CA type is a value from 0 - 255, that describes the civic address element. For example, a CA type of
24 specifies a postal or zip code. Valid elements and their types are listed in the following table.
value is the actual value of the elem CA type , above. For example, 95123 for the postal or zip code.
Acceptable values are also listed in the following table.
NOTE
If the value of an element contains one or more spaces, use double quotation marks (") at the
beginning and end of the string. For example, elem 3 "Santa Clara" .
0 Language The ISO 639 language code used for presenting the address
information.
Japan - Metropolis
Korea - Province
Germany - County
Korea - County
Germany - City
Japan - Town
Canada - N/A
Germany - N/A
Korea - Neighborhood
6 Street Examples:
Canada - Street
Germany - Street
Japan - Block
Korea - Street
16 Leading street direction N (north), E (east), S (south), W (west), NE, NW, SE, SW
17 Trailing street suffix N (north), E (east), S (south), W (west), NE, NW, SE, SW
18 Street suffix Acceptable values for the United States are listed in the United
States Postal Service Publication 28 [18], Appendix C.
Example: 1234
20 House number suffix A modifier to the house number. It does not include parts of the
house number.
Example: A, 1/2
21 Landmark or vanity A string name for a location. It conveys a common local designation
address of a structure, a group of buildings, or a place that helps to locate the
place.
Example: UC Berkeley
23 Name (residence and Identifies the person or organization associated with the address.
office occupant)
Example: Textures Beauty Salon
24 Postal / zip code The valid postal / zip code for the address.
Example: 95054-1234
25 Building (structure) The name of a single building if the street address includes more
than one building or if the building name is helpful in identifying the
location.
26 Unit (apartment, suite) The name or number of a part of a structure where there are
separate administrative units, owners, or tenants, such as separate
companies or families who occupy that structure. Common
examples include suite or apartment designations.
Example: Apt 27
27 Floor Example: 4
Example: 7A
29 Placetype The type of place described by the civic coordinates. For example, a
home, office, street, or other public space.
Example: Office
30 Postal community name When the postal community name is defined, the civic community
name (typically CA type 3) is replaced by this value.
Example: Alviso
31 Post office box (P.O. box) When a P.O. box is defined, the street address components (CA
types 6, 16, 17, 18, 19, and 20) are replaced with this value.
32 Additional code An additional country-specific code that identifies the location. For
example, for Japan, this is the Japan Industry Standard (JIS)
address code. The JIS address code provides a unique address
inside of Japan, down to the level of indicating the floor of the
building.
128 Script The script (from ISO 15924 [14]) used to present the address
information.
Example: Latn
NOTE
If not manually configured, the system assigns the default value
Latn
255 Reserved
The Civic address location advertisement will appear similar to the following on the remote device, and
in the CLI display output on the Brocade device (show lldp local-info) .
+ MED Location ID
Data Format: Civic Address
Location of: Client
Country : "US"
CA Type : 1
CA Value : "CA"
CA Type : 3
CA Value : "Santa Clara"
CA Type : 6
CA Value : "4980 Great America Pkwy."
CA Type : 24
CA Value : "95054"
CA Type : 27
CA Value : "5"
CA Type : 28
CA Value : "551"
CA Type : 29
CA Value : "office"
CA Type : 23
CA Value : "John Doe"
Syntax: [no] lldp med location-id ecs-elin number ports ethernet port-list | all
number is a number from 10 to 25 digits in length.
The ECS ELIN location advertisement will appear similar to the following on the remote device, and in
the CLI display output on the Brocade device (show lldp local-info ).
+ MED Location ID
Data Format: ECS ELIN
Value : 4082071700
NOTE
This feature applies to applications that have specific real-time network policy requirements, such as
interactive voice or video services. It is not intended to run on links other than between Network
Connectivity devices and Endpoints, and therefore does not advertise the multitude of network policies
that frequently run on an aggregated link.
To define an LLDP-MED network policy for an Endpoint, enter a command such as the following.
The network policy advertisement will appear similar to the following on the remote device, and in the
CLI display output on the Brocade device (show lldp local-info ).
NOTE
Endpoints will advertise a policy as "unknown" in the show lldp neighbor detail command output, if it
is a policy that is required by the Endpoint and the Endpoint has not yet received it.
Syntax: [no] lldp med network-policy application application type taggedvlan vlan ID priority 0-7
dscp 0-63 ports ethernet port-list | all
Syntax:[no] lldp med network-policy application application type untagged dscp 0-63 ports
ethernet port-list | all
Syntax:[no] lldp med network-policy application application type priority-tagged priority 0-7 dscp
0-63 ports ethernet port-list | all
application type indicates the primary function of the applications defined by this network policy.
Application type can be one of the following:
• guest-voice - Limited voice service for guest users and visitors with their own IP telephony handsets
or similar devices that support interactive voice services.
• guest-voice-signaling - Limited voice service for use in network topologies that require a different
policy for guest voice signaling than for guest voice media.
• softphone-voice - Softphone voice service for use with multi-media applications that work in
association with VoIP technology, enabling phone calls direct from a PC or laptop. Softphones do not
usually support multiple VLANs, and are typically configured to use an untagged VLAN or a single
tagged data-specific VLAN. Note that when a network policy is defined for use with an untagged
VLAN, the Layer 2 priority field is ignored and only the DSCP value is relevant.
• streaming-video - Applies to broadcast- or multicast-based video content distribution and similar
applications that support streaming video services requiring specific network policy treatment. Video
applications that rely on TCP without buffering would not be an intended use of this application type.
• video-conferencing - Applies to dedicated video conferencing equipment and similar devices that
support real-time interactive video/audio services.
• video-signaling - For use in network topologies that require a separate policy for video signaling
than for video media. Note that this application type should not be advertised if all the same network
policies apply as those advertised in the video conferencing policy TLV.
• voice - For use by dedicated IP telephony handsets and similar devices that support interactive
voice services.
• voice-signaling - For use in network topologies that require a different policy for voice signaling
than for voice media. Note that this application type should not be advertised if all the same network
policies apply as those advertised in the voice policy TLV.
• tagged vlan vlan id specifies the tagged VLAN that the specified application type will use.
• untagged indicates that the device is using an untagged frame format.
• priority-tagged indicates that the device uses priority-tagged frames. In this case, the device uses
the default VLAN (PVID) of the ingress port.
• priority 0 -7 indicates the Layer 2 priority value to be used for the specified application type. Enter 0
to use the default priority.
• dscp 0 - 63 specifies the Layer 3 Differentiated Service codepoint priority value to be used for the
specified application type. Enter 0 to use the default priority.
NOTE
Although the Location ID and Network policy attributes are automatically advertised, they will have no
effect until they are actually defined.
LLDP-MED capabilities
When enabled, LLDP-MED is enabled, and the LLDP-MED capabilities TLV is sent whenever any
other LLDP-MED TLV is sent. When disabled, LLDP-MED is disabled and no LLDP-MED TLVs are
sent.
The LLDP-MED capabilities advertisement includes the following information:
NOTE
Disabling the LLDP-MED capabilities TLV disables LLDP-MED.
To re-enable the LLDP-MED Capabilities TLV (and LLDP-MED) after it has been disabled, enter a
command such as the following.
The LLDP-MED capabilities advertisement will appear similar to the following on the remote device, and
in the CLI display output on the Brocade device (show lldp local-info ).
NOTE
Brocade devices always advertise the power source as "unknown".
• Power priority - The in-line power priority level for the PSE or PD:
‐ 3 - low
‐ 2 - high
‐ 1 - critical
‐ unknown
• Power level - The total power, in tenths of watts, required by a PD from a PSE, or the total power a
PSE is capable of sourcing over a maximum length cable based on its current configuration.
If the exact power is not known for a PSE or PD, it will advertise the power level associated with its
802.3af power class listed in the following table.
Power class Minimum power level output at the PSE Maximum power levels at the PD
For a PD (Endpoint device), the power level represents the maximum power it can consume during
normal operations in its current configuration, even if its actual power draw at that instance is less than
the advertised power draw.
For a PSE (Network Connectivity device), the power level represents the amount of power that is
available on the port at the time. If the PSE is operating in reduced power (i.e., it is using backup
power), the reduced power capacity is advertised as long as the condition persists.
By default, LLDP-MED power-via-MDI information is automatically advertised when LLDP-MED is
enabled, the port is a POE port, and POE is enabled on the port. To disable this advertisement, enter
a command such as the following.
The LLDP-MED power-via-MDI advertisement will appear similar to the following on the remote
device, and in the CLI display output on the Brocade device (show lldp local-info ).
device#show lldp
LLDP transmit interval : 10 seconds
LLDP transmit hold multiplier : 4 (transmit TTL: 40 seconds)
LLDP transmit delay : 1 seconds
LLDP SNMP notification interval : 5 seconds
LLDP reinitialize delay : 1 seconds
LLDP-MED fast start repeat count : 3
LLDP maximum neighbors : 392
LLDP maximum neighbors per port : 4
Field Description
LLDP transmit interval The number of seconds between regular LLDP packet transmissions.
LLDP transmit hold The multiplier used to compute the actual time-to-live (TTL) value of an LLDP
multiplier advertisement. The TTL value is the transmit interval multiplied by the transmit hold
multiplier.
LLDP transmit delay The number of seconds the LLDP agent will wait after transmitting an LLDP frame and
before transmitting another LLDP frame.
LLDP SNMP The number of seconds between transmission of SNMP LLDP traps
notification interval (lldpRemTablesChange) and SNMP LLDP-MED traps
(lldpXMedTopologyChangeDetected).
LLDP reinitialize delay The minimum number of seconds the device will wait from when LLDP is disabled on a
port, until a request to re-enable LLDP on that port will be honored.
LLDP-MED fast start The number of seconds between LLDP frame transmissions when an LLDP-MED
repeat count Endpoint is newly detected.
Field Description
LLDP maximum The maximum number of LLDP neighbors for which LLDP data will be retained, per
neighbors device.
LLDP maximum The maximum number of LLDP neighbors for which LLDP data will be retained, per port.
neighbors per port
NOTE
You can reset LLDP statistics using the CLI command clear LLDP statistics . Refer to Resetting
LLDP statistics on page 215.
The following table describes the information displayed by the show lldp statistics command.
Field Description
Last neighbor change time The elapsed time (in hours, minutes, and seconds) since a neighbor last advertised
information. For example, the elapsed time since a neighbor was last added,
deleted, or its advertised information changed.
Neighbor entries added The number of new LLDP neighbors detected since the last reboot or since the last
time the clear lldp statistics all command was issued.
Neighbor entries deleted The number of LLDP neighbors deleted since the last reboot or since the last time
the clear lldp statistics all command was issued.
Field Description
Neighbor entries aged out The number of LLDP neighbors dropped on all ports after the time-to-live expired.
Note that LLDP entries age out naturally when a port cable or module is
disconnected or when a port becomes disabled. However, if a disabled port is re-
enabled, the system will delete the old LLDP entries.
Neighbor advertisements The number of valid LLDP neighbors the device detected, but could not add. This
dropped can occur, for example, when a new neighbor is detected and the device is already
supporting the maximum number of neighbors possible. This can also occur when
an LLDPDU is missing a mandatory TLV or is not formatted correctly.
Rx Pkts w/Errors The number of LLDP packets the port received that have one or more detectable
errors.
Rx Pkts Discarded The number of LLDP packets the port received then discarded.
Rx TLVs Unrecognz The number of TLVs the port received that were not recognized by the LLDP local
agent. Unrecognized TLVs are retained by the system and can be viewed in the
output of the show LLDP neighbors detail command or retrieved through SNMP.
Rx TLVs Discarded The number of TLVs the port received then discarded.
Neighbors Aged Out The number of times a neighbor information was deleted because its TTL timer
expired.
Field Description
Brocade devices use the base MAC address of the device as the Chassis ID.
Brocade devices use the permanent MAC address associated with the port as the port ID.
Brocade devices use the ifDescr MIB object from MIB-II as the port description.
Brocade devices use the sysName MIB object from MIB-II, which corresponds to the CLI
hostname command setting.
NOTE
A tilde (~) at the end of a line indicates that the value in the field is too long to display in full and
is truncated.
NOTE
The show lldp neighbors detail output will vary depending on the data received. Also, values that
are not recognized or do not have a recognizable format, may be displayed in hexadecimal binary
form.
VLAN ID : 300
L2 Priority : 7
DSCP Value : 7
+ MED Extended Power via MDI
Power Type : PD device
Power Source : Unknown Power Source
Power Priority : High (2)
Power Value : 6.2 watts (PSE equivalent: 6656 mWatts)
+ MED Hardware revision : "PCB Version: 2"
+ MED Firmware revision : "Boot 02.01.00.11"
+ MED Software revision : "Main 02.01.00.11"
+ MED Serial number : ""
+ MED Manufacturer : "Mitel Corporation"
+ MED Model name : "MITEL 5235 DM"
+ MED Asset ID : ""
A backslash (\) at the end of a line indicates that the text continues on the next line.
Except for the following field, the fields in the above output are described in the individual TLV
advertisement sections in this chapter.
Field Description
Neighbor The source MAC address from which the packet was received, and the remaining TTL for the neighbor
entry.
NOTE
The show lldp local-info output will vary based on LLDP configuration settings.
FCX_ADV_ROUTER_SOFT_PACKAGE,
IronWare Version 07.3.00T7f3 compiled on Sep 26 2011 at 21:15:14 labeled
as FCXR07300"
+ System capabilities : bridge
Enabled capabilities: bridge
+ 802.3 MAC/PHY : auto-negotiation enabled
Advertised capabilities: 10BaseT-HD, 10BaseT-FD, 100BaseTX-HD,
100BaseTX-FD, fdxSPause, fdxBPause, 1000BaseT-HD,
1000BaseT-FD
Operational MAU type: 100BaseTX-FD
+ 802.3 Power via MDI: PSE port, power enabled, class 2
Power Pair : A (not controllable)
NOTE
The contents of the show output will vary depending on which TLVs are configured to be advertised.
A backslash (\) at the end of a line indicates that the text continues on the next line.
The fields in the above output are described in the individual TLV advertisement sections in this
chapter.
Syntax: show lldp local-info [ ports ethernet port-list | all ]
If you do not specify any ports or use the keyword all , by default, the report will show the local
information advertisements for all ports.
SX-FI424P SX-FI624HF
SX-FI424F SX-FI624P
SX-FI424HF SX-FI62XG
SX-FI42XG
The clear-diag tdr command clears results of any previous TDR test from test registers for port 1/1/1
(port 1 on slot 1 on device 1).
NOTE
It is recommended that you clear the TDR test registers before each test.
The command in the previous example diagnoses the cable attached to port 1/1/1.
When you issue the phy cable-diagnostics command, the command brings the port down for a
second or two, and then immediately brings the port back up.
Syntax: clear cable-diagnostics tdr stackid/slot/port
Syntax: phy cable-diagnostics tdr stackid/slot/port
Port Speed Local pair Pair Length Remote pair Pair status
--------- ----- ---------- ----------- ----------- -----------
-- ----- ------- ----- ------ ----------
01 UNKWN Pair A <=3 M Open
Pair B <=3 M Open
Pair C <=3 M Open
Pair D <=3 M Open
In the second test example, the TDR test results for the same port show details for an active port.
The following table describes the fields shown in the show cable-diagnostics port command output.
Field Meaning
Local pair The local link name. Refer to the previous local pair definition table.
Pair Length The cable length when terminated, or the distance to the point of fault when the line is not up.
Pair status The status of the link. This field displays one of the following:
NOTE
A Brocade ICX 6650 device allows all ports to support Digital Optical Monitoring (DOM).
device(config)#optical-monitor
NOTE
The commands no optical-monitor and optical-monitor 0 perform the same function. That is, they
both disable digital optical monitoring.
Use the show media slot command to obtain information about the media device installed in a slot.
Use the show media ethernet command to obtain information about the media device installed in a
port.
Use the show media validation command to find out whether the connected optic modules are
supported or not on Brocade devices.
device# show media validation
Port Supported Vendor Type
-----------------------------------------------------------------------------
1/2/1 Yes FINISAR CORP. 1GE M-SX(SFP)
1/2/2 Yes BROCADE 10GE Twinax 1m (SFP +)
2/2/1 Yes BROCADE 10GE SR 300m (SFP +)
2/2/3 Yes BROCADE 10GE SR 300m (SFP +)
Syntax: show media [ validation [ ethernet [ unit / slot / port ] | slot slot-num | stack stack-id ] |
ethernet [ unit / slot / port ] | slot slot-num | stack stack-id ]
Use the show optic command to view information about an XFP, SFP, or SFP+ installed in a particular
port. The following shows example output.
Optical monitoring feature will not work in the following scenarios:
• The port is DOWN.
• The port is configured as a stacking port.
• The the optic module does not support optical monitoring.
• For ICX 6430 devices only:
‐ If an SFP+ optic is inserted in an SFP only port, the optic will not initialize.
‐ If an SFP optic is inserted in an SFP+ only port, the optic will not initialize.
‐ If an optic is inserted into a device that supports both SFP and SFP+ optics, use the speed-
duplex command to set the port speed correctly.
device#show optic 13
Port Temperature Tx Power Rx Power Tx Bias Current
+----+-----------+----------+------------+-------------------+
13 33.2968 C -005.4075 dBm -007.4328 dBm 6.306 mA
Normal Normal Normal Normal
NOTE
The show optic slot command is supported on the FSX 800 and FSX 1600 only.
NOTE
The show optic function takes advantage of information stored and supplied by the manufacturer of the
XFP, SFP, or SFP+ transceiver. This information is an optional feature of the Multi-Source Agreement
standard defining the optical interface. Not all component suppliers have implemented this feature set.
In such cases where the XFP, SFP, or SFP+ transceiver does not supply the information, a "Not
Available" message will be displayed for the specific port on which the module is installed.
The following table describes the information displayed by the show optic command.
Field Description
Field Description
Tx Power • The transmit power signal, in decibels (dB), of the measured power referenced to one milliwatt
(mW).
• The alarm status, as described in the next table.
Rx Power • The receive power signal, in decibels (dB), of the measured power referenced to one milliwatt
(mW).
• The alarm status, as described in the next table.
For Temperature, Tx Power, Rx Power, and Tx Bias Current in the show optic command output,
values are displayed along with one of the following alarm status values: Low-Alarm, Low-Warn,
Normal, High-Warn or High-Alarm. The thresholds that determine these status values are set by the
manufacturer of the optical transceivers. The following table describes each of these status values.
Low-Alarm Monitored level has dropped below the "low-alarm" threshold set by the manufacturer of the optical
transceiver.
Low-Warn Monitored level has dropped below the "low-warn" threshold set by the manufacturer of the optical
transceiver.
Normal Monitored level is within the "normal" range set by the manufacturer of the optical transceiver.
High-Warn Monitored level has climbed above the "high-warn" threshold set by the manufacturer of the optical
transceiver.
High-Alarm Monitored level has climbed above the "high-alarm" threshold set by the manufacturer of the
optical transceiver.
NOTE
The output may vary depending on the device on which you run the show version.
The following hardware details are listed in the output of the show version command:
• Chassis type
• PROM type (if applicable)
• Chassis serial number
• Management and interface module serial numbers and ASIC types
For a description of the software details in the output of the show version command, refer to the
section Software versions installed and running on a device on page 90 in the FastIron Ethernet
Switch Administraiton Guide.
Starting with FastIron 08.0.30, you can view the serial number pluggable modules. If there are no
pluggable modules on the device, the serial number of the fixed modules on the device is displayed.
The following is an example of the show version output on an ICX 7750.
device# show version
Copyright (c) 1996-2014 Brocade Communications Systems, Inc. All rights reserved.
UNIT 1: compiled on Dec 22 2014 at 12:35:56 labeled as SWR08030b1
(20833985 bytes) from Secondary SWR08030b1.bin
SW: Version 08.0.30b1T203
UNIT 2: compiled on Dec 22 2014 at 12:35:56 labeled as SWR08030b1
(20833985 bytes) from Secondary SWR08030b1.bin
SW: Version 08.0.30b1T203
Compressed Boot-Monitor Image size = 1835008, Version:10.1.03T205
(swz10103b003)
HW: Stackable ICX7750-26Q
Internal USB: Serial #: 40D41E003CF90029
Vendor: UNIGEN, Total size = 1910 MB
==========================================================================
UNIT 1: SL 1: ICX7750-20QXG 20-port Management Module
Serial #:CRK2234J00V
License: ICX7750_L3_SOFT_PACKAGE (LID: etmHHIJlFFx)
P-ASIC 0: type B850, rev 03 Chip BCM56850_A2
==========================================================================
UNIT 1: SL 2: ICX7750-QSFP 6-port QSFP 240G Module
==========================================================================
UNIT 1: SL 3: ICX7750-6Q 6-port QSFP 240G Module
Serial #:PR320400290
==========================================================================
UNIT 2: SL 1: ICX7750-48XGF 48-port Management Module
Serial #:CRH2234J00M
License: ICX7750_L3_SOFT_PACKAGE (LID: etjHHIJlFFo)
==========================================================================
UNIT 2: SL 2: ICX7750-QSFP 6-port QSFP 240G Module
==========================================================================
UNIT 2: SL 3: ICX7750-6Q 6-port QSFP 240G Module
Serial #:PR320400289
==========================================================================
1500 MHz Power PC processor (version 8023/0022) 88 MHz bus
8192 KB boot flash memory
2048 MB code flash memory
256 MB DRAM
STACKID 1 system uptime is 14 minute(s) 30 second(s)
STACKID 2 system uptime is 14 minute(s) 6 second(s)
The system: started=warm start reloaded=by "reload"
To determine the available show commands for the system or a specific level of the CLI, enter the
following command.
device#show ?
Enabling the display of the elapsed timestamp for port statistics reset
Whenever the port statistics of a device are cleared globally or on an interface, the counter values of the
received and transmitted packets on the device are reset for all the ports or for an interface,
respectively.
The elapsed time after the most recent reset of the port statistics counters can be displayed in the
output of the show statistics command by configuring the port-statistics-reset-timestamp enable
command. By default, the display of the elapsed timestamp information is disabled.
The elapsed time is calculated as the time between the most recent reset of the port statistics counters
and the time when the show statistics command is executed.
The following list provides details of the conditions under which the port statistics counters are reset and
also explains the elapsed time calculation considerations.
• When the port statistics are cleared individually using the clear statistics ethernet command. The
elapsed time is calculated and displayed only for that particular interface.
• When the port statistics are cleared globally using the clear statistics command. The port statistics
counters for all the ports, including management ports, are cleared and the elapsed time is calculated
and displayed for each of the interfaces.
• When the management interface is cleared using the clear statistics management command. The
port statistics counters specific to management ports are cleared. The elapsed time is calculated and
displayed for the management interface.
• If the system is reloaded (hard reboot or soft reboot), the port statistics on the device are cleared
automatically. In this case, the time when the ports are cleared during the reload is considered as the
most recent reset time.
• In a stacking device, the Elapsed Timestamp information is applicable for other unit's ports. In case
of a switchover, all the port statistics are cleared and the elapsed time is calculated and displayed for
all ports.
• If hitless failover is enabled and if any unit is reloaded, the statistics of the reloading device's
interfaces are cleared. In this case, the time when the ports are cleared during the reload is
considered as the most recent reset time.
• The elapsed time is not impacted when the Network Time Protocol (NTP) syncs up with a different
time other than the recorded time.
• show statistics
• show statistics brief
• show statistics ethernet
• show statistics management
NOTE
The port-statistics-reset-timestamp enable command must be configured to have the Elapsed
Timestamp information displayed in the output.
To display the statistics, enter a command such as the following.
Parameter Description
Port configuration
Trunk The trunk group number, if the port is a member of a trunk group.
Parameter Description
Statistics
*Last time counter reset The elapsed time between the most recent reset of the port statistics counters and
(Elapsed Timestamp) the time when the show statistics command is executed.
InOctets The total number of good octets and bad octets received.
OutOctets The total number of good octets and bad octets sent.
InPkts The total number of packets received. The count includes rejected and local packets
that are not sent to the switching core for transmission.
OutPkts The total number of good packets sent. The count includes unicast, multicast, and
broadcast packets.
InBadPkts The total number of packets received for which one of the following is true:
InFragments The total number of packets received for which both of the following is true:
Parameter Description
InDiscards The total number of packets that were received and then dropped due to a lack of
receive buffers.
OutErrors The total number of packets with internal transmit errors such as TX underruns.
CRC The total number of packets received for which all of the following is true:
• The data length is between 64 bytes and the maximum allowable frame size.
• No Collision or Late Collision is detected.
• The CRC is invalid.
Collisions The total number of packets received in which a Collision event was detected.
InErrors The total number of packets received that had Alignment errors or PHY errors.
NOTE
Excessive errors for some counters usually indicate a problem. When you operate at
a half-duplex setting, some data link errors incrementing in Frame Check Sequence
(FCS), alignment, runts, and collision counters are normal. Generally, a one percent
ratio of errors to total traffic is acceptable for half-duplex connections. If the ratio of
errors to input packets is greater than two or three percent, performance degradation
could be noticed.
In half-duplex environments, it is possible for both the switch and the connected
device to sense the wire and transmit at exactly the same time and result in a
collision. Collisions may cause runts, errors in FCS, and alignment errors due to the
frame not being completely copied to the wire, resulting in fragmented frames. When
you operate at full-duplex, errors in FCS, Cyclic Redundancy Check (CRC),
alignment, and runt counters must be minimal.
LateCollisions The total number of packets received in which a Collision event was detected, but
for which a receive error (Rx Error) event was not detected.
InGiantPkts The total number of packets for which all of the following is true:
• The data length is longer than the maximum allowable frame size.
• No Rx Error is detected.
NOTE
Packets are counted for this statistic regardless of whether the CRC is valid or
invalid.
Parameter Description
InShortPkts The total number of packets received for which all of the following is true:
NOTE
Packets are counted for this statistic regardless of whether the CRC is valid or
invalid.
InJabber The total number of packets received for which all of the following is true:
• The data length is longer than the maximum allowable frame size.
• No Rx Error is detected.
• The CRC is invalid.
Clearing statistics
You can clear statistics for many parameters using the clear command.
To determine the available clear commands for the system, enter the clear command at the Privileged
EXEC level of the CLI.
device#clear ?
To configure traffic counters for outbound traffic on a specific port, enter a command such as the
following.
The above command creates and enables traffic counter 4 on port 18. The device will count the
number of packets sent out on port 18 that are in VLAN 1 and have a priority queue of 7.
To configure traffic counters for outbound traffic in a specific port region, enter a command such as the
following.
The above command creates and enables traffic counter 1 on all ports that are in the same port region
as port 1. The device will count the number of packets transmitted in this port region that belong to any
VLAN and have any assigned priority queue.
Syntax: [no] transmit-counter counter-ID port [slotnum /] port-num { only | region} vlan {vlan-ID |
all } priority {priority-queue | all} enable
Enter the no form of the command to remove the outbound traffic counter.
The counter-ID parameter identifies the traffic counter. You can configure up to 64 traffic counters.
Enter a number from 1 - 64.
The slotnum parameter is required on chassis devices.
The port-num parameter is the port number to which enhanced traffic counters will apply. Enter the port
number followed by only to apply the enhanced traffic counter to a specific port, or enter the port
number followed by region to apply the enhanced traffic counter to all of the ports in the port region.
The vlan-ID parameter identifies the VLAN ID for which outbound traffic will be counted. Enter a number
from 0 - 4095 or enter all to indicate all VLANs.
The priority-queue parameter identifies the 802.1p priority queue for which traffic will be counted. Enter
a number from 0 - 7 or enter all to indicate all priority queues.
NOTE
Once the enhanced traffic counters are displayed, the counters are cleared (reset to zero).
Transmitted frames
Multicast & Unknown The number of multicast and unknown unicast packets transmitted.
Unicast
Dropped Frames
Bridge Egress Filtered The number of bridged outbound packets that were filtered and dropped.
This number includes the number of packets that were dropped because of any one of
the following conditions:
Congestion Drops The number of outbound packets that were dropped because of traffic congestion.
NOTE
These counters do not include traffic on management ports or for a stack member unit that is down.
The egress queue counters display at the end of the show interface command output as shown in the
following example.
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual none
Member of L2 VLAN ID 52, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Flow Control is config enabled, oper enabled, negotiation disabled
mirror disabled, monitor disabled
Not member of any active trunks
Not member of any configured trunks
No port name
Inter-Packet Gap (IPG) is 96 bit times
IP MTU 1500 bytes
300 second input rate: 0 bits/sec, 0 packets/sec, 0.00% utilization
300 second output rate: 256 bits/sec, 0 packets/sec, 0.00% utilization
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 multicasts, 0 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
215704 packets output, 13805066 bytes, 0 underruns
Transmitted 0 broadcasts, 215704 multicasts, 0 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Egress queues:
Queue counters Queued packets Dropped Packets
0 0 0
1 0 0
2 1 0
3 0 0
4 0 0
5 0 0
6 0 0
7 215703 0
Parameter Description
Queued packets The number of packets queued on the port for the given traffic class.
Dropped packets The number of packets for the given traffic class that were dropped because of congestion.
NOTE
This command output displays the total of unicast and multicast counters for any particular QOS priority.
Brocade# show interface ethernet 1/1/1
10GigabitEthernet 1/1/1 is down, line protocol is down
Port down for 16 hours 16 minutes 48 seconds
Hardware is 10GigabitEthernet , address is 748e.f8f9.6280 (bia 748e.f8f9.6280)
Interface type is 40Gig Fiber
Configured speed 40Gbit, actual unknown, configured duplex fdx, actual unknown
Configured mdi mode AUTO, actual unknown
Egress queues:
Queue counters Queued packets Dropped Packets
0 0 0
1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
RMON support
The Brocade RMON agent supports the following groups. The group numbers come from the RMON
specification (RFC 1757):
NOTE
RFC 1757 is obsolete and is replaced by RFC 2819 for the Brocade ICX devices.
• Statistics (RMON Group 1)
• History (RMON Group 2)
• Alarms (RMON Group 3)
• Events (RMON Group 9)
The CLI allows you to make configuration changes to the control data for these groups, but you need a
separate RMON application to view and display the data graphically.
NOTE
You must save the change to the startup-config file and reload or reboot. The change does not take
effect until you reload or reboot.
Syntax: system-max rmon-entries value
where value can be:
• 1536 - 32768 for FSX 800 and FSX 1600 devices
NOTE
Though 48GC modules receive oversized packets and jabbers, they do not support count information
for oversized packets and jabbers and the output of the show rmon statistics command reports 0 for
both of these counters.
The port parameter specifies the port number. You can use the physical port number or the SNMP port
number. The physical port number is based on the product.
The SNMP numbers of the ports start at 1 and increase sequentially. For example, if you are using a
Chassis device and slot 1 contains an 8-port module, the SNMP number of the first port in slot 2 is 9.
The physical port number of the same port is 2/1.
This command shows the following information.
Parameter Definition
This number includes octets in bad packets. This number does not include framing bits but
does include Frame Check Sequence (FCS) octets.
Drop events Indicates an overrun at the port. The port logic could not receive the traffic at full line rate
and had to drop some packets as a result.
The counter indicates the total number of events in which packets were dropped by the
RMON probe due to lack of resources. This number is not necessarily the number of packets
dropped, but is the number of times an overrun condition has been detected.
This number includes bad packets, broadcast packets, and multicast packets.
Broadcast pkts The total number of good packets received that were directed to the broadcast address.
Multicast pkts The total number of good packets received that were directed to a multicast address.
This number does not include packets directed to the broadcast address.
CRC alignment The total number of packets received that were from 64 - 1518 octets long, but had either a
errors bad FCS with an integral number of octets (FCS Error) or a bad FCS with a non-integral
number of octets (Alignment Error).
The packet length does not include framing bits but does include FCS octets.
Undersize pkts The total number of packets received that were less than 64 octets long and were otherwise
well formed.
This number does not include framing bits but does include FCS octets.
Fragments The total number of packets received that were less than 64 octets long and had either a bad
FCS with an integral number of octets (FCS Error) or a bad FCS with a non-integral number
of octets (Alignment Error).
It is normal for this counter to increment, since it counts both runts (which are normal
occurrences due to collisions) and noise hits.
This number does not include framing bits but does include FCS octets.
Parameter Definition
Oversize packets The total number of packets received that were longer than 1518 octets and were otherwise
well formed.
This number does not include framing bits but does include FCS octets.
NOTE
48GC modules do not support count information on oversized packets and report 0.
Jabbers The total number of packets received that were longer than 1518 octets and had either a bad
FCS with an integral number of octets (FCS Error) or a bad FCS with a non-integral number
of octets (Alignment Error).
NOTE
This definition of jabber is different from the definition in IEEE-802.3 section 8.2.1.5
(10BASE5) and section 10.3.1.4 (10BASE2). These documents define jabber as the
condition where any packet exceeds 20 ms. The allowed range to detect jabber is between
20 ms and 150 ms.
This number does not include framing bits but does include FCS octets.
NOTE
48GC modules do not support count information on jabbers and report 0.
Collisions The best estimate of the total number of collisions on this Ethernet segment.
64 octets pkts The total number of packets received that were 64 octets long.
This number does not include framing bits but does include FCS octets.
65 to 127 octets The total number of packets received that were 65 - 127 octets long.
pkts
This number includes bad packets.
This number does not include framing bits but does include FCS octets.
128 to 255 octets The total number of packets received that were 128 - 255 octets long.
pkts
This number includes bad packets.
This number does not include framing bits but does include FCS octets.
256 to 511 octets The total number of packets received that were 256 - 511 octets long.
pkts
This number includes bad packets.
This number does not include framing bits but does include FCS octets.
Parameter Definition
512 to 1023 octets The total number of packets received that were 512 - 1023 octets long.
pkts
This number includes bad packets.
This number does not include framing bits but does include FCS octets.
1024 to 1518 The total number of packets received that were 1024 - 1518 octets long.
octets pkts
This number includes bad packets.
This number does not include framing bits but does include FCS octets.
Syntax: rmon historyentry-number interface port buckets number interval sampling-interval owner
text-string
You can modify the sampling interval and the bucket (number of entries saved before overwrite) using
the CLI. In the above example, owner refers to the RMON station that will request the information.
NOTE
To review the control data entry for each port or interface, enter the show rmon history command.
device(config)# rmon event 1 description ‘testing a longer string’ trap public owner
nyc02
Syntax: rmon eventevent-entry description text-string {log | trap | log-and-trap} owner rmon-station
NOTE
FastIron devices currently support only the trap option.
sFlow
NOTE
FastIron devices support sFlow version 5 by default.
sFlow is a standards-based protocol that allows network traffic to be sampled at a user-defined rate for
the purpose of monitoring traffic flow patterns and identifying packet transfer rates on user-specified
interfaces.
When sFlow is enabled on a Layer 2 or Layer 3 switch, the system performs the following sFlow-related
tasks:
• Samples traffic flows by copying packet header information
• Identifies ingress and egress interfaces for the sampled flows
• Combines sFlow samples into UDP packets and forwards them to the sFlow collectors for analysis
• Forwards byte and packet count data, or counter samples, to sFlow collectors
sFlow is described in RFC 3176, "InMon Corporation's sFlow: A Method for Monitoring Traffic in
Switched and Routed Networks".
On ICX and FCX Series devices, you can use QoS queue 1 for priority traffic, even when sFlow is
enabled on the port. This differs from FastIron X Series devices, which support seven priorities instead
of eight when sFlow is enabled. In this case, QoS queue 1 is reserved for sFlow and is not used by
other packets. Any non-sFlow packets assigned to QoS queue 1 will be directed to QoS queue 0.
sFlow version 5
sFlow version 5 enhances and modifies the format of the data sent to the sFlow collector. sFlow version
5 introduces several new sFlow features and also defines a new datagram syntax used by the sFlow
agent to report flow samples and interface counters to the sFlow collector.
sFlow version 5 adds support for the following:
NOTE
Autonomous System communities and local preferences are not included in the sampled packets.
To obtain extended gateway information, use "struct extended_gateway" as described in RFC 3176.
NOTE
The device uses the router ID only if the device also has an IP interface with the same address.
Router ID is not supported on IPv6 devices.
NOTE
If an IP address is not already configured when you enable sFlow, the feature uses the source
address 0.0.0.0. To display the agent_address, enable sFlow, then enter the show sflow command.
Refer to Enabling sFlow forwarding on page 254 and Displaying sFlow information on page 260.
NOTE
In sFlow version 5, you can set an arbitrary IPv4 or IPv6 address as the sFlow agent IP address. Refer
to Specifying the sFlow agent IP address on page 256.
NOTE
The value range for sampling rate is from 8 through 1073741823 on the Brocade ICX 6430, Brocade
ICX 6450, Brocade ICX 6610, Brocade ICX 6650, FCX, and FSX 800 and FSX 1600 devices. The value
range for sampling rate is from 256 through 1073741823 on Brocade ICX 7750, Brocade ICX 7450, and
Brocade ICX 7250. The default value is 4096 for all devices.
NOTE
The commands in this section apply to sFlow version 2 and sFlow version 5. CLI commands that are
specific to sFlow version 5 are documented in sFlow version 5 feature configuration on page 256.
To configure sFlow, perform the following tasks:
• Optional - If your device supports sFlow version 5, change the version used for exporting sFlow data
• Specify collector information. The collector is the external device to which you are exporting the
sFlow data. You can specify up to four collectors.
• Optional - Change the polling interval
• Optional - Change the sampling mode to include dropped packets
• Optional - Change the sampling rate
• Optional - Change the sFlow source IP address
• Optional - Change the sFlow source port
• Enable sFlow globally
To specify an sFlow collector on an IPv4 device, enter a command such as the following.
This command specifies a collector with IPv4 address 10.10.10.1, listening for sFlow data on UDP port
6343.
Syntax: [no] sflow destination ip-addr [ dest-udp-port | vrf]
The ip-addr parameter specifies the IP address of the collector.
The dest-udp-port parameter specifies the UDP port on which the sFlow collector will be listening for
exported sFlow data. The default port number is 6343. For information on VRF parameter, see the
FastIron Layer 3 Routing Configuration Guide .
The sampled sFlow data sent to the collectors includes an agent_address field. This field identifies the
device that sent the data. Refer to sFlow and agent address on page 247.
To specify an sFlow collector on an IPv6 device, enter a command such as the following.
This command specifies a collector with IPv6 address 2001:DB8::0b:02a, listening for sFlow data on
UDP port 6343.
Syntax: [no] sflow destination ipv6 ip-addr [dest-udp-port]
The ip-addr parameter specifies the IP address of the collector.
The dest-udp-port parameter specifies the UDP port on which the sFlow collector will be listening for
exported sFlow data. The default port number is 6343.
If the IPv6 address you specify is a link-local address on a Layer 3 switch, you must also specify the
outgoing-interface ethernet port-num or the ve port-num. This identifies the outgoing interface through
which the sampled packets will be sent.
The sampled sFlow data sent to the collectors includes an agent_address field. This field identifies the
device that sent the data. Refer to sFlow and agent address on page 247.
for one of the ports are sent after ten seconds, and counter data for the other port are sent after an
additional ten seconds. Ten seconds later, new counter data for the first port are sent. Similarly, if sFlow
is enabled on five ports and the polling interval is 20 seconds, the Brocade device sends counter data
every four seconds.
The default polling interval is 20 seconds. You can change the interval to a value from 0 to 4294967295
seconds. The interval value applies to all interfaces on which sFlow is enabled. If you set the polling
interval to 0, counter data sampling is disabled.
To change the polling interval, enter a command such as the following at the global CONFIG level of the
CLI.
device(config)#sflow polling-interval 30
The dropped packets are not included in the sFlow samples that are sent to the sFlow collector. The
sampling mode can be changed to include the dropped packets using the sflow sample-mode
command.
NOTE
The sflow sample-mode command is not supported on Brocade ICX 7750, Brocade ICX 7450,
Brocade ICX 7250, Brocade ICX 6430, Brocade ICX 6650, and FSX 800/1600 devices.
Configuration considerations
The sampling rate is a fraction in the form 1/N, meaning that, on average, one out of every N packets
will be sampled. The sflow sample command at the global level or port level specifies N, the
denominator of the fraction. Thus a higher number for the denominator means a lower sampling rate
since fewer packets are sampled. Likewise, a lower number for the denominator means a higher
sampling rate because more packets are sampled. For example, if you change the denominator from
512 to 128, the sampling rate increases because four times as many packets will be sampled.
NOTE
Brocade recommends that you do not change the denominator to a value lower than the default.
Sampling requires CPU resources. Using a low denominator for the sampling rate can cause high CPU
utilization.
To change the default (global) sampling rate, enter a command such as the following at the global
CONFIG level of the CLI.
• 8
• 16
• 32
• 64
• 128
• 256
• 512
• 1024
• 2048
• 4096
• 8192
• 16384
• 32768
• 65536
• 131072
• 262144
• 524288
• 1048576
• 2097152
• 4194304
• 8388608
• 16777216
• 33554432
• 67108864
• 134217728
• 268435456
• 536870912
• 1073741823
For example, if the configured sampling rate is 1000, then the actual rate is 1024 and 1 in 1024 packets
are sampled by the hardware.
You cannot change a module sampling rate directly. You can change a module sampling rate only by
changing the sampling rate of a port on that module.
You can configure an individual port to use a different sampling rate than the global default sampling
rate. This is useful in cases where ports have different bandwidths. For example, if you are using sFlow
on 10/100 ports and Gbps Ethernet ports, you might want to configure the Gbps ports to use a higher
sampling rate (and thus gather fewer samples per number of packets) than the 10/100 ports.
To change the sampling rate on an individual port, enter a command such as the following at the
configuration level for the port.
NOTE
Configuring a sampling rate on a port that is the primary port of a trunk applies that same sampling
rate to all ports in the trunk.
You can configure an individual static trunk port to use a different sampling rate than the global default
sampling rate. This feature is also supported on LACP trunk ports. This feature is useful in cases
where ports have different bandwidths. For example, if you are using sFlow on 10/100 ports and Gbps
Ethernet ports, you might want to configure the Gbps ports to use a higher sampling rate (and thus
gather fewer samples per number of packets) than the 10/100 ports.
To configure a static trunk port to use a different sampling rate than the global default sampling rate,
enter commands such as the following:
NOTE
Configuring a sampling rate on only the port that is the primary port of a trunk automatically applies
that same sampling rate to all ports in the trunk.
NOTE
Before you enable sFlow, make sure the device has an IP address that sFlow can use as its source
address. Refer to sFlow and agent address on page 247 for the source address requirements.
NOTE
When you enable sFlow forwarding on an 802.1X-enabled interface, the samples taken from the
interface include the username used to obtain access to either or both the inbound and outbound ports,
if that information is available. For information about 802.1X, refer to "802.1X Port Security" chapter in
the FastIron Ethernet Switch Security Configuration Guide
To enable sFlow forwarding, you must first enable it on a global basis, then on individual interfaces or
trunk ports, or both.
To globally enable sFlow forwarding, enter the following command.
device(config)#sflow enable
You can now enable sFlow forwarding on individual ports as described in the next two sections.
Syntax: [no] sflow enable
device(config)#sflow enable
device(config)#interface ethernet 1/1 to 1/8
device(config-mif-1/1-1/8)#sflow forwarding
These commands globally enable sFlow, then enable sFlow forwarding on Ethernet ports 1/1 - 1/8. You
must use both the sflow enable and sflow forwarding commands to enable the feature.
Syntax: [no] sflow enable
Syntax: [no] sflow forwarding
This feature is supported on individual ports of a static trunk group. It is also supported on LACP trunk
ports.
NOTE
When you enable sFlow forwarding on a trunk port, only the primary port of the trunk group forwards
sFlow samples.
To enable sFlow forwarding on a trunk port, enter commands such as the following.
device(config)#sflow enable
device(config)#trunk e 4/1 to 4/8
device(config-trunk-4/1-4/8)#config-trunk-ind
device(config-trunk-4/1-4/8)#sflow forwarding e 4/2
These commands globally enable sFlow, then enable sFlow forwarding on trunk port e 4/2. You must
use both the sflow enable and sflow forwarding commands to enable the feature.
Syntax: [no] sflow enable
Syntax: [no] sflow forwarding
NOTE
The commands in this section are supported when sFlow version 5 is enabled on the device. These
commands are not supported with sFlow version 2. sFlow version 5 also supports all of the sFlow
configuration commands in Configuring and enabling sFlow on page 249.
When sFlow version 5 is enabled on the device, you can do the following:
• Specify the sFlow version (version 2 or version 5)
• Specify the sFlow agent IP address
• Specify the maximum flow sample size
• Export CPU and memory usage Information to the sFlow collector
• Specify the polling interval for exporting CPU and memory usage information to the sFlow collector
• Export CPU-directed data (management traffic) to the sFlow collector
NOTE
When the sFlow version number is changed, the system will reset sFlow counters and flow sample
sequence numbers.
To specify the sFlow version used for exporting sFlow data, enter the following command.
device(config)#sflow version 2
Specifying the polling interval for exporting CPU and memory usage information to the sFlow
collector
The polling interval defines how often sFlow data for a port is sent to the sFlow collector. With sFlow
version 5, you can optionally set the polling interval used for exporting CPU and memory usage
information.
For example, to set the polling interval for exporting CPU and memory usage information to 30
seconds, enter the following command.
To enable the sFlow agent on a Brocade device to export data destined to the CPU to the sFlow
collector, enter the following command.
The sampling rate is the average ratio of the number of packets incoming on an sFlow-enabled port, to
the number of flow samples taken from those packets. You can optionally set the sampling rate for
CPU-directed data exported to the sFlow collector. For example, to set this sampling rate to 2048,
enter the following command.
management VRF to send the samples to the collector. See the section Management VRFs on page 21
for information on management VRFs. If no management VRF is configured, sFlow uses the default
VRF, and this default VRF ID will be assigned to any configured collector that does not have a user-
included VRF.
Collectors can be added and per VRF so that collectors can be spread out across different VRFs. The
sFlow forwarding port can belong to a non-default VRF, and captured sFlow packets will have correct
sample routing next hop information.
sFlow forwarding ports can come from ports belonging to any VRF. The port does not have to be in the
same VRF as the collector. sFlow collects packets from all sFlow forwarding ports, even if they do not
belong to a VRF, compiles the packets into the sFlow samples, and sends the samples to the particular
collector with no filtering for VRF membership. For counter samples, sample statistics from each port
are sent to each collector specified, even if the port and collector do not belong to a VRF instance.
To distinguish collected packets from different VRFs, refer to the in vlan and out vlan data fields for
each captured ingress packet. For example, when two collected packets are from different VRFs but
have the same source/destination IP and the same incoming/outgoing port, the VLAN field differs in the
two samples. A VLAN/VE can only belong to one VRF. The collector does not have any VRF
knowledge, but, based on the VLAN fields, the collector can distinguish which packet came from which
VLAN/VRF.
To configure an sFlow collector and specify a VRF, enter the following command.
Syntax: [no] sflow destination [ ipaddress | ipv6 ipv6-address ] [ udp-port-number ] [ vrf vrf-name ]
To disable the management VRF in sFlow, enter the following command.
device#show sflow
sFlow version:5
sFlow services are enabled.
sFlow agent IP address: 10.123.123.1
sFlow source IP address: 5.5.5.5
sFlow source IPv6 address: 4545::2
4 collector destinations configured:
Collector IP 192.168.4.204, UDP 6343
Collector IP 192.168.4.200, UDP 6333
Collector IP 192.168.4.202, UDP 6355
Collector IP 192.168.4.203, UDP 6565
Configured UDP source port: 33333
Polling interval is 0 seconds.
Configured default sampling rate: 1 per 512 packets
Actual default sampling rate: 1 per 512 packets
Sample mode: Non-dropped packets
The maximum sFlow sample size:512
exporting cpu-traffic is enabled
exporting cpu-traffic sample rate:16
exporting system-info is enabled
exporting system-info polling interval:20 seconds
10552 UDP packets exported
24127 sFlow samples collected.
sFlow ports: ethe 1/2 to 1/12 ethe 1/15 ethe 1/25 to 1/26 ethe 4/1 ethe 5/10 to
5/20 ethe 8/1 ethe 8/4
Module Sampling Rates
---------------------
Slot 1 configured rate=512, actual rate=512
Slot 3 configured rate=0, actual rate=0
Slot 4 configured rate=10000, actual rate=32768
Slot 5 configured rate=512, actual rate=512
Slot 7 configured rate=0, actual rate=0
Slot 8 configured rate=512, actual rate=512
Port Sampling Rates
-------------------
Port 8/4, configured rate=512, actual rate=512, Subsampling factor=1
Port 8/1, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/20, configured rate=3000, actual rate=8192, Subsampling factor=16
Port 5/19, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/18, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/17, configured rate=1500, actual rate=2048, Subsampling factor=4
Port 5/16, configured rate=1500, actual rate=2048, Subsampling factor=4
Port 5/15, configured rate=1500, actual rate=2048, Subsampling factor=4
Port 5/14, configured rate=1500, actual rate=2048, Subsampling factor=4
Port 5/13, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/12, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/11, configured rate=512, actual rate=512, Subsampling factor=1
Port 5/10, configured rate=512, actual rate=512, Subsampling factor=1
Port 4/1, configured rate=10000, actual rate=32768, Subsampling factor=1
Port 1/26, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/25, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/15, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/12, configured rate=512, actual rate=512, Subsampling factor=1
...continued on next page...
...continued from previous page...
Port 1/11, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/10, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/9, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/8, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/7, configured rate=1000, actual rate=2048, Subsampling factor=4
Port 1/6, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/5, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/4, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/3, configured rate=512, actual rate=512, Subsampling factor=1
Port 1/2, configured rate=1000, actual rate=2048, Subsampling factor=4
Parameter Definition
sFlow version The version of sFlow enabled on the device, which can be one of the following:
• 2
• 5
sFlow services The feature state, which can be one of the following:
• disabled
• enabled
sFlow agent IP address The IP address that sFlow is using in the agent_address field of packets sent to the
collectors. Refer to sFlow and agent address on page 247.
sFlow source IP address The IPv4 address that sFlow is using as the source IP address in the sFlow datagram.
sFlow source IPv6 The IPv6 address that sFlow is using as the source IP address in the sFlow datagram.
address
Collector The collector information. The following information is displayed for each collector:
• IP address
• UDP port
If more than one collector is configured, the line above the collectors indicates how
many have been configured.
Configured UDP source The UDP source port used to send data to the collector.
port
Configured default The configured global sampling rate. If you changed the global sampling rate, the value
sampling rate you entered is shown here. The actual rate calculated by the software based on the
value you entered is listed on the next line, "Actual default sampling rate".
Sample mode Indicates whether only the non-dropped packets or all the packets, including the
dropped packets, are included for sFlow sampling.
The maximum sFlow The maximum size of a flow sample sent to the sFlow collector.
sample size
exporting cpu-traffic Indicates whether or not the sFlow agent is configured to export data destined to the
CPU (e.g., Telnet sessions) to the sFlow collector:
• enabled
• disabled
Parameter Definition
exporting cpu-traffic The sampling rate for CPU-directed data, which is the average ratio of the number of
sample rate incoming packets on an sFlow-enabled port, to the number of flow samples taken from
those packets.
exporting system-info Indicates whether or not the sFlow agent is configured to export information about CPU
and memory usage to the sFlow collector:
• enabled
• disabled
exporting system-info Specifies the interval, in seconds, that sFlow data is sent to the sFlow collector.
polling interval
UDP packets exported The number of sFlow export packets the Brocade device has sent.
NOTE
Each UDP packet can contain multiple samples.
sFlow samples collected The number of sampled packets that have been sent to the collectors.
Module Sampling Rates The configured and actual sampling rates for each module. If a module does not have
any sFlow-enabled ports, the rates are listed as 0.
Port Sampling Rates The configured and actual sampling rates for each sFlow-enabled port.
The Subsampling factor indicates how many times the sampling rate of the port's
module is multiplied to achieve the port's sampling rate. Because of the way the actual
sampling rates are computed, the Subsampling factors are always whole numbers.
device#clear statistics
NOTE
This command also clears the statistics counters used by other features.
NOTE
This feature is intended for ISP or collocation environments in which downlink ports are dedicated to
various customers’ traffic and are isolated from one another. If traffic regularly passes between the
downlink ports, the information displayed by the utilization lists does not provide a clear depiction of
traffic exchanged by the downlink ports and the uplink port.
Each uplink utilization list consists of the following:
• Utilization list number (1, 2, 3, or 4)
• One or more uplink ports
• One or more downlink ports
Each list displays the uplink port and the percentage of that port bandwidth that was utilized by the
downlink ports over the most recent 30-second interval.
You can configure up to four bandwidth utilization lists.
Syntax: [no] relative-utilization num uplink ethernet [to port | port...] downlink ethernet port [to port
| [port...]
The num parameter specifies the list number. You can configure up to four lists. Specify a number from
1 - 4.
The uplink ethernet parameters and the port numbers you specify after the parameters indicate the
uplink ports.
The downlink ethernet parameters and the port numbers you specify after the parameters indicate the
downlink ports.
device#show relative-utilization 1
uplink: ethe 1
30-sec total uplink packet count = 3011
In this example, ports 1/2 and 1/3 are sending traffic to port 1/1. Port 1/2 and port 1/3 are isolated (not
shared by multiple clients) and typically do not exchange traffic with other ports except for the uplink
port, 1/1.
Syntax: show relative-utilizationnum
The num parameter specifies the list number.
NOTE
The example above represents a pure configuration in which traffic is exchanged only by ports 1/2 and
1/1, and by ports 1/3 and 1/1. For this reason, the percentages for the two downlink ports equal 100%.
In some cases, the percentages do not always equal 100%. This is true in cases where the ports
exchange some traffic with other ports in the system or when the downlink ports are configured
together in a port-based VLAN.
In the following example, ports 1/2 and 1/3 are in the same port-based VLAN.
device#show relative-utilization 1
uplink: ethe 1
30-sec total uplink packet count = 3011
packet count ratio (%)
1/ 2:100 1/ 3:100
Here is another example showing different data for the same link utilization list. In this example, port
1/2 is connected to a hub and is sending traffic to port 1/1. Port 1/3 is unconnected.
device#show relative-utilization 1
uplink: ethe 1
30-sec total uplink packet count = 2996
packet count ratio (%)
1 /2:100 1/ 3:---
• ‐ Link errors.
‐ ECC errors.
• By default, system monitoring starts on system boot up and runs in the background every three
minutes. You can configure, disable, or enable, the time interval through the CLI; however, if you
define the system monitoring interval at the global level, this value overrides the individual settings.
Valid range for the sysmon timer is 1 to 60 minutes.
• You can define a system monitoring threshold that is defined as N/W, where N is the number of
error events in a specified window (W) of consecutive polling periods. When the threshold is
reached, the action that is defined is performed. The threshold enables the sysmon utility to ignore
random errors that occur because of corrupted data coming in to the device, and perform the action
only for errors generated because of device failure. A threshold of 1/W means no threshold.
• You can choose the log action as either to the internal sysmon buffer or to the syslog. If you choose
the internal sysmon buffer, logs that are written beyond the limit of the sysmon buffer rolls over. On
the other hand, if you choose logging to syslog, messages are sent to the configured syslog
servers.
Usage Guidelines Disabling sysmon at the global level disables any individually configured and enabled sysmon tasks as
well. However, any sysmon configuration that is made, including global and event-specific configuration
are retained.
Enables system monitoring at the global level for all event types.
Usage Guidelines This command enables system monitoring globally, and covers all event-specific system monitoring
configuration as well. If specific configuration is not made for different types, default values defined at
the global level are used.
Examples The following example enables all system monitoring tasks at the global level:
sysmon timer
Parameters minutes
Specifies the system monitoring timer in minutes. The range of values is 1 through 60. The
default value is 3.
Examples The following example sets the system monitoring timer to five minutes:
sysmon log-backoff
Defines the number of times to skip logging an event before logging again at the global level. The no
form of this command resets the parameter to default value.
no sysmon log-backoff
Parameters number
Specifies the number of times to skip an event logging before logging again.
Usage Guidelines Logging every error may not provide any new information, but adds significantly to the number of error
entries that need to be analyzed. You can configure the system monitoring utility to ignore a certain
number of errors (within a stream of consecutive errors) before writing the entry to the log again.
This option helps you further isolate issues that randomly occur from issues because of device failure.
The sysmon utility keeps a counter of the number of times the threshold value is exceed. If the number
exceeds the back-off value, the error is logged as specified by the action option.
Examples The following example sets the number of times to skip logging to 20.
sysmon threshold
Defines the threshold for errors at the global level. The no form of this command resets the threshold
configuration to default values.
no sysmon threshold
Parameters events
Specifies the threshold in terms of the number of events. Valid values are 1 through 10.
When expressed in the command, the default value is 2.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events. When expressed in
the command, the default value is 10.
Usage Guidelines The type-specific threshold values that you define overrides the global threshold value for each event.
However, if you define the global value later, the latest value prevails. The threshold is defined as N/W,
where N is the number of events, and W is the number of consecutive polling periods. When the
threshold is reached, actions configured for this event type will take place. Note that a threshold of 1/W
implies that there is no threshold, and the action will always be triggered.
Examples The following example sets the threshold to 3 events over 7 consecutive polling periods:
sysmon ecc-error
Configures how sysmon handles ECC errors. The no version of this command disables system
monitoring on internal ECC errors.
Syntax sysmon ecc-error -count { threshold events polling-interval | log-backoff value | action { none |
syslog } }
no sysmon fa error-count
Parameters threshold
Defines the threshold for errors. The threshold is defined as N/W, where N is the number of
events, and W is the number of consecutive polling periods. When the threshold is reached,
actions configured for this event type will take place. Note that a threshold of 1/W implies
that there is no threshold, and the action will always be triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally to
syslog as defined by the action). The log back-off count skips configured number of logs
before logging again.
action
Specifies the action to take when error count exceeds the specified threshold and log back-
off values.
none
The error is logged in the internal sysmon logs. This is the default value.
syslog
The error is logged to syslog.
Usage Guidelines This command is supported only on FCX and ICX devices.
Examples The following example configures system monitoring for fabric adaptor errors:
sysmon link-error
Configures how sysmon handles link errors. The no version of this command disables system
monitoring on link errors.
Syntax sysmon link-error { threshold events polling-interval | log-backoff value | action { none | syslog } }
no sysmon link-error
Parameters threshold
Defines the threshold for errors. The threshold is defined as N/W, where N is the number of
events, and W is the number of consecutive polling periods. When the threshold is reached,
actions configured for this event type will take place. Note that a threshold of 1/W implies
that there is no threshold, and the action will always be triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally to
syslog as defined by the action). The log back-off count skips configured number of logs
before logging again.
action
Specifies the action to take when the error count exceeds the specified threshold and log
back-off values.
none
The error is logged in the internal sysmon logs. This is the default value.
syslog
The error is logged to syslog.
Usage Guidelines This command is supported only on FCX and ICX devices.
Examples The following example configures system monitoring for fabric adaptor errors:
sysmon fa error-count
Configures how sysmon handles fabric adaptor-related errors. The no version of this command disables
system monitoring on fabric adaptors.
Syntax sysmon fa error-count { threshold events polling-interval | log-backoff value | action { none |
syslog } }
no sysmon fa error-count
Parameters threshold
Defines the threshold for errors. The threshold is defined as N/W, where N is the number of
events, and W is the number of consecutive polling periods. When the threshold is reached,
actions configured for this event type will take place. Note that a threshold of 1/W implies
that there is no threshold, and the action will always be triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally to
syslog as defined by the action). The log back-off count skips configured number of logs
before logging again.
action
Specifies the action to take when a fabric adapter error count exceeds the specified
threshold and log back-off values.
none
The error is logged in the internal sysmon logs. This is the default value.
syslog
The error is logged to syslog.
Examples The following example configures system monitoring for fabric adaptor errors:
sysmon fa link
Configures system monitoring for link errors on all or specified fabric adaptors. The no form of this
command resets the parameters to default values.
Syntax sysmon fa link { threshold events polling-interval | log-backoff value | action { none | syslog } }
no sysmon fa link
Parameters threshold
Defines the failure threshold for the fabric adapter link error event. The threshold is defined
as N/W, where N is the number of events, and W is the number of consecutive polling
periods. When the threshold is reached, actions configured for this event type will take
place. Note that a threshold of 1/W implies that there is no threshold, and no event will be
triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally). The
log back-off count skips configured number of logs before logging again. This avoids
overflow of the internal log or of the syslog.
action
Specifies the action to take when a fabric adapter link error exceeds the specified threshold
and log back-off values.
none
No action is taken. This is the default.
syslog
The error is logged to syslog.
Examples The following example configures the sysmon options for fabric adaptor links:
Configures system monitoring for cross bar errors. The no form of this command resets the parameters
to default values.
Syntax sysmon xbar error-count { threshold events polling-interval | log-backoff value | action { none |
syslog } }
Parameters threshold
Defines the failure threshold for the cross bar error-count event. The threshold is defined as
N/W, where N is the number of events, and W is the number of consecutive polling periods.
When the threshold is reached, actions configured for this event type will take place. Note
that a threshold of 1/W implies that there is no threshold, and no event will be triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally). The
log back-off count skips configured number of logs before logging again. This avoids
overflow of the internal log or of the syslog.
action
Specifies the action to take when the error count exceeds the specified threshold and log
back-off values.
none
No action is taken.
syslog
The error is logged to syslog.
Examples The following example configures system monitoring for cross bar errors.
Configures the sysmon parameters for the crossbar link. The no form of this command resets the
parameters to default values.
Syntax sysmon xbar link { threshold events polling-interval | log-backoff value | action { none | syslog } }
Parameters threshold
Defines the failure threshold for the fabric adapter error-count event. The threshold is
defined as N/W, where N is the number of events, and W is the number of consecutive
polling periods. When the threshold is reached, actions configured for this event type will
take place. Note that a threshold of 1/W implies that there is no threshold, and no event will
be triggered.
events
Specifies the threshold in terms of the number of events. Valid values are 1 through
10.
polling-interval
Specifies the number of polling windows. The device polls the internal registers at the
interval specified by the sysmon timer value. Valid values 1-32. However, the polling
window number must be equal or greater than the number of events.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally). The
log back-off count skips configured number of logs before logging again. This avoids
overflow of the internal log or of the syslog.
action
Specifies the action to take when the error count exceeds the specified threshold and log
back-off values.
none
No action is taken.
syslog
The error is logged to syslog.
Examples The following example configures system monitoring for cross bar link errors:
sysmon pp error-count
Configures the sysmon monitoring parameters for error events in packet processors. The no form of
this command resets the parameters to default values.
no sysmon pp error-count
Parameters threshold
Defines the failure threshold for the fabric adapter error-count event. The threshold is
defined as N/W, where N is the number of events, and W is the number of consecutive
polling periods. When the threshold is reached, actions configured for this event type will
take place. Note that a threshold of 1/W implies that there is no threshold, and no event will
be triggered.
log-backoff
If an error condition persists, it will be continuously logged (internally and/or externally). The
log back-off count skips configured number of logs before logging again. This avoids
overflow of the internal log or of the syslog.
action
Specifies the action to take when the error count exceeds the specified threshold and log
back-off values.
none
No action is taken. This is the default action.
syslog
The error is logged to syslog.
Usage Guidelines This is a global configuration for all packet processors-- you cannot configure sysmon parameters for
individual packet processors. However, you can display the logs for individual packet processors by
specifying the packet processor identifier.
This command is supported only on FSX devices.
Parameters all
Clears all sysmon counters.
fa
Clears the fabric adaptor sysmon counters.
error
Clears the fabric adaptor error counters. You can specify all or a fabric adaptor,
identified by the index.
link
Clears the fabric adaptor sysmon counters for links. You can specify all or a fabric
adaptor identified by the index.
pp error
Clears packet processor sysmon counters. You can specify all or a packet processor
identified by the index.
xbar
Clears cross bar sysmon counters for cross bar. You can specify all or a cross bar identified
by the index.
error
Clears the cross bar sysmon error counters. You can specify all or a cross bar
identified by the index.
link
Clears the cross bar sysmon counters for links. You can specify all or a cross bar
identified by the index.
ecc-error
Clears the ECC error count on FCX and ICX devices. This option is not supported on FSX
devices.
stack-unit
Specifies the stack unit on which errors to be cleared.
all
Specifies that all stack units are cleared of errors.
link-error
Clears the link error count on FCX and ICX devices. This option is not supported on FSX
devices.
stack-unit
Specifies the stack unit on which errors to be cleared.
all
Examples The following example clears the fabric adaptor sysmon counters.
Displays the entries written to syslog for all event types if the action specified is to log them into
syslog. If the action specified is none , the sysmon logs display nothing.
Examples The following example displays the syslog entries that were made by sysmon if the action specified
either at the global level or type level was to log the events to syslog. If the action specified was none ,
no syslog entries exist.
Field Description
Critical or Warning A ‘C’ indicates a critical error and a ‘W’ indicates a warning.
Event type Possible values are FA ERROR, FA Link, XBAR ERROR, XBAR LINK, or PP ERROR
Component identifier Identifies the component of the system where the error was detected
Parameters type
The event type for which sysmon counters are displayed. For FSX devices, the options are
all, fa (fabric adapter), pp (packet processor), and xbar (cross bar). For FCX and ICX
devices, the options are ecc-error and link-error. The default value is all.
error
Displays the error counter for the specified event type.
link
Displays the link error counters. You can specify either all or specific links.
ecc-error
Displays the ECC error count on FCX and ICX devices. This option is not supported on FSX
devices.
stack-unit
Specifies the stack unit on which errors to be displayed.
all
Displays errors for all stack units.
link-error
Displays the link error count on FCX and ICX devices. This option is not supported on FSX
devices.
stack-unit
Specifies the stack unit on which errors to be displayed.
all
Displays errors for all stack units.
Examples The following displays all fabric adaptor statistics on an FSX device:
The following example displays the error events that sysmon has recorded for the fabric adaptor 0.
The following example shows the crossbar errors for the switch fabric module 0.
The following example displays the cross bar link errors for the SFM module 0.
The following example displays the error counter for the specified packet processor 0.
The following example displays all error counter data on an FCX device:
Displays the complete sysmon configuration, including the global configuration and the event-specific
configuration.
Examples The following command displays the sysmon configuration an FSX device. The global configuration is
displayed first, followed by the configuration for specific events.
Parameters all
Displays the statistics for all SFMs on the device.
number
Specifies the SFM ID for which the statistics is to be displayed.
Examples The following command displays the statistics for all SFMs on the device.
NOTE
To enable the Brocade device to retain Syslog messages after a soft reboot (reload command). Refer
to Retaining Syslog messages after a soft reboot on page 293.
The Syslog service on a Syslog server receives logging messages from applications on the local host or
from devices such as a Layer 2 Switch or Layer 3 Switch. Syslog adds a time stamp to each received
message and directs messages to a log file. Most Unix workstations come with Syslog configured.
Some third party vendor products also provide Syslog running on NT.
Syslog uses UDP port 514 and each Syslog message thus is sent with destination port 514. Each
Syslog message is one line with Syslog message format. The message is embedded in the text portion
of the Syslog format. There are several subfields in the format. Keywords are used to identify each
subfield, and commas are delimiters. The subfield order is insensitive except that the text subfield
should be the last field in the message. All the subfields are optional.
device>#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 3 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dec 15 19:04:14:A:Fan 1, fan on right connector, failed
Dynamic Log Buffer (50 entries):
Dec 15 18:46:17:I:Interface ethernet 4, state up
Dec 15 18:45:21:I:Bridge topology change, vlan 4095, interface 4, changed
state to forwarding
Dec 15 18:45:15:I:Warm start
For information about the Syslog configuration information, time stamps, and dynamic and static
buffers, refer to Displaying the Syslog configuration on page 287.
device(config)#logging console
telnet@device#terminal monitor
Syslog trace was turned ON
telnet@device#terminal monitor
Syslog trace was turned OFF
telnet@device#terminal monitor
Syslog trace was turned ON
SYSLOG: <9>device, Power supply 2, power supply on left connector, failed
SYSLOG: <14>device, Interface ethernet 6, state down
SYSLOG: <14>device, Interface ethernet 2, state up
device>#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 3 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dec 15 19:04:14:A:Fan 1, fan on right connector, failed
Dynamic Log Buffer (50 entries):
Dec 15 18:46:17:I:Interface ethernet 1/4, state up
Dec 15 18:45:21:I:Bridge topology change, vlan 4095, interface 4, changed
state to forwarding
Dec 15 18:45:15:I:Warm start
Syntax:show logging
The Syslog display shows the following configuration information, in the rows above the log entries
themselves.
Field Definition
messages dropped The number of Syslog messages dropped due to user-configured filters. By default, the
software logs messages for all Syslog levels. You can disable individual Syslog levels, in
which case the software filters out messages at those levels. Refer to Disabling logging of a
message level on page 291. Each time the software filters out a Syslog message, this
counter is incremented.
flushes The number of times the Syslog buffer has been cleared by the clear logging command or
equivalent Web Management Interface option. Refer to Clearing the Syslog messages from
the local buffer on page 294.
overruns The number of times the dynamic log buffer has filled up and been cleared to hold new
entries. For example, if the buffer is set for 100 entries, the 101st entry causes an overrun.
After that, the 201st entry causes a second overrun.
level The message levels that are enabled. Each letter represents a message type and is
identified by the key (level code) below the value. If you disable logging of a message level,
the code for that level is not listed.
messages logged The total number of messages that have been logged since the software was loaded.
device#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 3 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dec 15 19:04:14:A:Fan 1, fan on right connector, failed
Dec 15 19:00:14:A:Fan 2, fan on left connector, failed
Dynamic Log Buffer (50 entries):
Dec 15 18:46:17:I:Interface ethernet 4, state up
Dec 15 18:45:21:I:Bridge topology change, vlan 4095, interface 4, changed
state to forwarding
Dec 15 18:45:15:I:Warm start
Notice that the static buffer contains two separate messages for fan failures. Each message of each
type has its own buffer. Thus, if you replace fan 1 but for some reason that fan also fails, the software
replaces the first message about the failure of fan 1 with the newer message. The software does not
overwrite the message for fan 2, unless the software sends a newer message for fan 2.
Time stamps
The contents of the time stamp differ depending on whether you have set the time and date on the
onboard system clock:
• If you have set the time and date on the onboard system clock, the date and time are shown in the
following format.
mm dd hh:mm:ss
where
• ‐ mm - abbreviation for the name of the month
‐ dd - day
‐ hh - hours
‐ mm - minutes
‐ ss - seconds
For example, "Oct 15 17:38:03" means October 15 at 5:38 PM and 3 seconds.
• If you have not set the time and date on the onboard system clock, the time stamp shows the amount
of time that has passed since the device was booted, in the following format.
num d num h num m num s
where
• ‐ num d - day
‐ num h - hours
‐ num m - minutes
‐ num s - seconds
For example, "188d1h01m00s" means the device had been running for 188 days, 11 hours, one minute,
and zero seconds when the Syslog entry with this time stamp was generated.
The example shows the format of messages on a device where the onboard system clock has been set.
Each time stamp shows the month, the day, and the time of the system clock when the message was
generated. For example, the system time when the most recent message (the one at the top) was
generated was October 15 at 5:38 PM and 3 seconds.
device#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 38 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dec 15 19:04:14:A:Fan 1, fan on right connector, failed
Dec 15 19:00:14:A:Fan 2, fan on left connector, failed
Dynamic Log Buffer (50 entries):
Oct 15 17:38:03:warning:list 101 denied tcp 10.157.22.191(0)(Ethernet 18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
Oct 15 07:03:30:warning:list 101 denied tcp 10.157.22.26(0)(Ethernet 18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
Oct 15 06:58:30:warning:list 101 denied tcp 10.157.22.198(0)(Ethernet 18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
Example of Syslog messages on a device wih the onboard clock not set
The example shows the format of messages on a device where the onboard system clock is not set.
Each time stamp shows the amount of time the device had been running when the message was
generated. For example, the most recent message, at the top of the list of messages, was generated
when the device had been running for 21 days, seven hours, two minutes, and 40 seconds.
device#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 38 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Static Log Buffer:
Dynamic Log Buffer (50 entries):
21d07h02m40s:warning:list 101 denied tcp 10.157.22.191(0)(Ethernet 4/18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
19d07h03m30s:warning:list 101 denied tcp 10.157.22.26(0)(Ethernet 4/18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
17d06h58m30s:warning:list 101 denied tcp 10.157.22.198(0)(Ethernet 4/18
0000.001f.77ed) -> 10.99.4.69(http), 1 event(s)
device(config)#no logging on
device(config)#logging on
This command enables local Syslog logging with the following defaults:
• Messages of all severity levels (Emergencies - Debugging) are logged.
• Up to 50 messages are retained in the local Syslog buffer.
• No Syslog server is specified.
The default number of messages is 50. For FastIron devices, you can set the Syslog buffer limit from 1
- 1000 entries.
NOTE
You can specify only one facility. If you configure the Brocade device to use two Syslog servers, the
device uses the same facility on both servers.
FastIron(config)# ip show-portname
This command is applied globally to all interfaces on Layer 2 Switches and Layer 3 Switches.
Syntax:[no] Ip show-portname
By default, Syslog messages show the interface type, such as "ethernet", and so on. For example, you
see the following
However, if ip show-portname is configured and a name has been assigned to the port, the port name
replaces the interface type as in the example below, where "port5_name" is the name of the port.
Also, when you display the messages in the Syslog, you see the interface name under the Dynamic Log
Buffer section. The actual interface number is appended to the interface name. For example, if the
interface name is "lab" and its port number is "2", you see "lab2" displayed as in the example below:
device(config)#ip show-service-number-in-log
device(config)#logging persistence
device#clear logging
NOTE
This feature is supported on FastIron X Series devices only. It is not supported on FCX and ICX
devices.
FastIron Chassis devices support the display of hardware read and write errors encountered on a slot
or module during bootup and during normal system operations. There are four types of errors, which
may cause the system to disable or power down the modules on which they occur:
• Configuration read error
• Configuration write error
• Memory read error
• Memory write error
The following shows examples of some hardware errors in the show logging display output.
device>#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Buffer logging: level ACDMEINW, 3 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Dynamic Log Buffer (50 lines):
0d00h00m27s:I:System: Interface ethernet mgmt1, state up
0d00h00m26s:N:powered On switch Fabric
0d00h00m17s:N:powered On switch Fabric
0d00h00m08s:I:System: Warm start
Syslog messages (alerts) for hardware errors are listed in Brocade Syslog messages on page 297.
NOTE
This chapter does not list Syslog messages that can be displayed when a debug option is enabled.
The messages are listed by message level, in the following order, then by message type:
• Emergencies (none)
• Alerts
• Critical
• Errors
• Warnings
• Notifications
• Informational
• Debugging
Explanation Indicates that the chassis needs more power supplies to run the modules
in the chassis.
Explanation Multi-device port authentication failed for the mac-address on a tagged port
because the packet with this MAC address as the source was tagged with
a VLAN ID different from the RADIUS-supplied VLAN ID.
• active
• standby
• crashed
• coming-up
• unknown
The lsa-type parameter indicates the type of LSA that experienced the
overflow condition. The LSA type is one of the following:
• 1 - Router
• 2 - Network
• 3 - Summary
• 4 - Summary
• 5 - External
Explanation The chassis temperature has risen above shutdown level. The system will
be shut down in the amount of time indicated.
Explanation Denial of Service (DoS) attack protection was enabled for multi-device port
authentication on the specified portnum , and the per-second rate of
RADIUS authentication attempts for the port exceeded the configured limit.
The Brocade device considers this to be a DoS attack and disables the
port.
Explanation The device could not start the BGP4 routing protocol because there is not
enough memory available.
Explanation There is not enough system memory for 802.1X authentication to take
place. Contact Brocade Technical Support.
Explanation The Layer 3 switch has received more than the specified maximum number
of prefixes from the neighbor, and the Layer 3 switch is therefore shutting
down its BGP4 session with the neighbor.
Explanation IPv6 protocol was disabled on the device during the specified session.
Explanation IPv6 protocol was enabled on the device during the specified session.
Explanation Indicates a MAC address filter was applied to the specified port by the
specified user during the specified session.
Explanation Indicates a MAC address filter was removed from the specified port by the
specified user during the specified session.
Explanation Password of the specified user has been changed during the specified
session ID or type. session-id can be console, telnet, ssh, or snmp.
Explanation The specified ports were logically brought down while singleton was
configured on the port.
Explanation The specified ports were logically brought up while singleton was
configured on the port.
Explanation A user has logged into the Privileged EXEC mode of the CLI.
Explanation A user has logged into the USER EXEC mode of the CLI.
Explanation A user has logged out of Privileged EXEC mode of the CLI.
Explanation A user has logged out of the USER EXEC mode of the CLI.
Explanation A Spanning Tree Protocol (STP) topology change has occurred, resulting
in the Brocade device becoming the root bridge.
The vlan-id is the ID of the VLAN in which the STP topology change
occurred.
The vlan-id is the ID of the VLAN in which the STP topology change
occurred.
The portnum is the number of the port connected to the new root bridge.
Explanation A Spanning Tree Protocol (STP) topology change has occurred on a port.
The vlan-id is the ID of the VLAN in which the STP topology change
occurred.
The stp-state is the new STP state and can be one of the following:
• disabled
• blocking
• listening
• learning
• forwarding
• unknown
Explanation The device has indicated that the DHCP client receives DHCP server reply
packets on untrusted ports, and packets are dropped.
Explanation The RADIUS server returned an IP ACL or MAC address filter, but the port
is a member of a virtual interface (VE).
Explanation The RADIUS server returned an MAC address filter, but the portnum is a
router port (it has one or more IP addresses).
Explanation The RADIUS server returned an IP ACL, but the portnum is a switch port
(no IP address).
Explanation The Brocade device was unable to implement the MAC address filters
returned by the RADIUS server.
Explanation The MAC address filter ID returned by the RADIUS server does not exist in
the Brocade configuration.
Explanation The port was assigned a MAC address filter ID that had been dynamically
created by another user.
Explanation 802.1X authentication failed for the Client with the specified mac address
on the specified portnum either due to insufficient system resources on the
device, or due to invalid IP ACL or MAC address filter information returned
by the RADIUS server.
Message Informational
Level
Explanation The RADIUS server returned a MAC address filter, but a MAC address
filter had already been applied to the port.
Explanation The RADIUS server returned a MAC address filter while an IP ACL was
applied to the port, or returned an IP ACL while a MAC address filter was
applied to the port.
Explanation 802.1X authentication could not take place on the port. This happened
because strict security mode was enabled and one of the following
occurred:
Message Informational
Level
Explanation A user has completed 802.1X authentication. The profile received from the
RADIUS server specifies a VLAN ID for the user. The port to which the
user is connected has been moved to the VLAN indicated by vlan-id .
Explanation The user connected to portnum has disconnected, causing the port to be
moved back into its default VLAN, vlan-id .
Explanation The status of the interface controlled port has changed from unauthorized
to authorized.
Explanation The status of the interface controlled port has changed from authorized to
unauthorized.
Explanation Errdisable recovery timer expired and the port has been reenabled.
Explanation If the wait time (port is down and is waiting to come up) expires and the
port is brought up the following message is displayed.
Explanation The threshold for the number of times that a port link toggles from "up" to
"down" and "down" to "up" has been exceeded.
Explanation A user created, modified, deleted, or applied this MAC address filter
through the SNMP, console, SSH, or Telnet session.
Explanation The optical transceiver is qualified by Brocade, but the transceiver does not
support digital optical performance monitoring.
Explanation The specified user logged into the device console into the specified EXEC
mode.
Explanation The specified user logged into the device using Telnet or SSH from either
or both the specified IP address and MAC address. The user logged into
the specified EXEC mode.
Explanation The specified user logged out of the device. The user was using Telnet or
SSH to access the device from either or both the specified IP address and
MAC address. The user logged out of the specified EXEC mode.
Explanation A user made SNMP configuration changes through the SNMP, console,
SSH, or Telnet session.
Explanation A user has tried to open a management session with the device using an
invalid SNMP community string.
The ip-addr is the IP address of the host that sent the invalid community
string.
Explanation A user enabled or disabled an SSH or Telnet session, or changed the SSH
enable/disable configuration through the SNMP, console, SSH, or Telnet
session.
The user-name is the user ID, if they entered a user ID to log in.
Explanation The BPDU guard feature has detected an incoming BPDU on {vlan-id, port-
id}
Explanation The root protect feature goes back to the consistent state.
Explanation The root protect feature has detected a superior BPDU and goes into the
inconsistent state on { vlan-id , port-id }.
Explanation STP placed a port into an errdisable state for BPDU guard.
Explanation A user made Syslog configuration changes to the specified Syslog server
address, or enabled or disabled a Syslog operation through the SNMP,
console, SSH, or Telnet session.
Explanation The system automatically changed the fan speed to the speed specified in
this message.
Explanation A MAC address is deleted from a range of interfaces, which are members
of the specified VLAN.
Explanation A MAC address is deleted from a range of interfaces, which are members
of the specified VLAN range.
Explanation A MAC address is deleted from an interface and the interface is a member
of the specified VLAN.
Explanation A MAC address is deleted from an interface and the interface is a member
of the specified VLAN range.
Explanation There were failed SSH, or Telnet login access attempts from the specified
source IP and MAC address.
• [by user username ] does not appear if telnet or SSH clients are
specified.
• n is the number of times this SNMP trap occurred in the last five
minutes, or other configured number of minutes.
Message Informational
Level
Explanation 802.3ad link aggregation is configured on the device, and the feature has
dynamically created a trunk group (aggregate link).
The ports variable is a list of the ports that were aggregated to make the
trunk group.
Explanation A user created, modified, or deleted a local user account through the
SNMP, console, SSH, or Telnet session.
Explanation A user created, modified, or deleted a VLAN through the SNMP, console,
SSH, or Telnet session.
Explanation The specified unit has been deleted from the stacking system.
Explanation The specified unit in a stack has been elected as the Master unit for the
stacking system.
Explanation The specified unit has been added to the stacking system.
Explanation The management MAC address of a stacking system has been changed
Explanation The operational status of a fan in the specified unit in a stack changed from
normal to failure.
Explanation The operational status of a power supply of the specified unit in a stack
changed from normal to failure.
Explanation The operational status of a power supply of the specified unit in a stack
changed from failure to normal.
Explanation The operational status of a fan in the specified unit in a stack changed from
failure to normal.
Explanation The actual temperature reading for a unit in a stack is above the warning
temperature threshold.
Explanation 802.1W changed the current bridge to be the root bridge of the given
topology due to administrative change in bridge priority.
Explanation The message age expired on the Root port so 802.1W changed the current
bridge to be the root bridge of the topology.
Explanation 802.1W recognized a topology change event in the bridge. The topology
change event is the forwarding action that started on a non-edge
Designated port or Root port.
Explanation 802.1W changed the state of a port to a new state: forwarding, learning,
blocking. If the port changes to blocking, the bridge port is in discarding
state.
Explanation 802.1W selected a new root bridge as a result of the BPDUs received on a
bridge port.
Explanation 802.1W changed the port role to Root port, using the root selection
computation.
Explanation The port does not have enough Layer 4 CAM entries for the ACL.
Explanation The port does not have a large enough CAM partition for the ACLs
Explanation The device does not have enough Layer 4 session entries.
Explanation The fragment rate allowed on an individual interface has been exceeded.
Explanation The fragment rate allowed on the device has been exceeded.
Explanation The multi-device port authentication feature was disabled on the on the
specified portnum .
Explanation The multi-device port authentication feature was enabled on the on the
specified portnum .
The ip-addr is the IP address of the neighbor BGP4 interface with the
Brocade device.
The ip-addr is the IP address of the neighbor BGP4 interface with the
Brocade device.
Explanation Indicates that the DHCP client receives DHCP server reply packets on
untrusted ports, and packets are dropped.
Explanation The device has indicated that the specified is no longer authorized, but the
actual port may still be active.
Explanation The device has indicated that the specified port has been authenticated,
but the actual port may not be active.
Explanation The RADIUS session has timed out for this 802.1x port.
Explanation The Layer 3 switch adjacency with this Level-1 IS-IS has gone down.
The circuit-id is the ID of the circuit over which the adjacency was
established.
Explanation The Layer 3 switch adjacency with this Level-1 IS-IS has come up.
The circuit-id is the ID of the circuit over which the adjacency was
established.
Explanation The Layer 3 switch adjacency with this Level-2 IS-IS has gone down.
The circuit-id is the ID of the circuit over which the adjacency was
established.
Explanation The Layer 3 switch adjacency with this Level-2 IS-IS has come up.
The circuit-id is the ID of the circuit over which the adjacency was
established.
Explanation The number of ICMP packets exceeds the burst-max threshold set by the
ip icmp burst command. The Brocade device may be the victim of a
Denial of Service (DoS) attack.
All ICMP packets will be dropped for the number of seconds specified by
the lockup value. When the lockup period expires, the packet counter is
reset and measurement is restarted.
Explanation The number of TCP SYN packets exceeds the burst-max threshold set by
the ip tcp burst command. The Brocade device may be the victim of a
TCP SYN DoS attack.
All TCP SYN packets will be dropped for the number of seconds specified
by the locku p value. When the lockup period expires, the packet counter is
reset and measurement is restarted.
Message Notification
Level
Explanation Threshold parameters for local TCP traffic on the device have been
configured, and the maximum burst size for TCP packets has been
exceeded.
The first num is the maximum burst size (maximum number of packets
allowed).
The second num is the number of seconds during which additional TCP
packets will be blocked on the device.
NOTE
This message can occur in response to an attempted TCP SYN attack.
Message Notification
Level
Explanation The RADIUS session has timed out for the MAC address for this port.
The slot-num is the number of the chassis slot into which the module was
inserted.
The slot-num is the number of the chassis slot from which the module was
removed.
The ospf-state indicates the state to which the interface has changed and
can be one of the following:
• down
• loopback
• waiting
• point-to-point
• designated router
• backup designated router
• other designated router
• unknown
Message Notification
Level
The src-ip-addr is the IP address of the interface from which the Brocade
device received the authentication failure.
• bad version
• area mismatch
• unknown NBMA neighbor
• unknown virtual neighbor
• authentication type mismatch
• authentication failure
• network mask mismatch
• hello interval mismatch
• dead interval mismatch
• option mismatch
• unknown
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
The src-ip-addr is the IP address of the interface from which the Brocade
device received the error packet.
• bad version
• area mismatch
• unknown NBMA neighbor
• unknown virtual neighbor
• authentication type mismatch
• authentication failure
• network mask mismatch
• hello interval mismatch
• dead interval mismatch
• option mismatch
• unknown
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
Message OSPF intf rcvd bad pkt, rid router-id , intf addr
ip-addr , pkt src addr src-ip-add r, pkt type
pkt-type
The src-ip-addr is the IP address of the interface from which the Brocade
device received the authentication failure.
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
Message OSPF intf rcvd bad pkt: Bad Checksum, rid ip-
addr , intf addr ip-addr , pkt size num , checksum
num , pkt src addr ip-addr , pkt type type
Explanation The device received an OSPF packet that had an invalid checksum.
The intf addr ip-addr is the IP address of the Brocade interface that received
the packet.
The pkt src addr ip-addr is the IP address of the neighbor that sent the
packet.
The pkt type type is the OSPF packet type and can be one of the following:
• hello
• database description
• link state request
• link state update
• link state acknowledgement
• unknown (indicates an invalid packet type)
Message Notification
Level
Message OSPF intf rcvd bad pkt: Bad Packet type, rid ip-
addr, intf addr ip-addr , pkt size num , checksum
num , pkt src addr ip-addr , pkt type type
The parameters are the same as for the Bad Checksum message. The pkt
type type value is "unknown", indicating that the packet type is invalid.
Message OSPF intf rcvd bad pkt: Invalid packet size, rid
ip-addr, intf addr ip-addr, pkt size num ,
checksum num , pkt src addr ip-addr , pkt type
type
Explanation The device received an OSPF packet with an invalid packet size.
The parameters are the same as for the Bad Checksum message.
Explanation The neighbor IP address in the packet is not in the list of OSPF neighbors
in the Brocade device.
The parameters are the same as for the Bad Checksum message.
Explanation An OSPF interface on the Brocade device has retransmitted a Link State
Advertisement (LSA).
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
The ospf-state indicates the state to which the interface has changed and
can be one of the following:
• down
• attempt
• initializing
• 2-way
• exchange start
• exchange
• loading
• full
• unknown
Message Notification
Level
Message Notification
Level
Explanation Indicates that an OSPF virtual routing interface authentication failure has
occurred.
The src-ip-addr is the IP address of the interface from which the Brocade
device received the authentication failure.
• bad version
• area mismatch
• unknown NBMA neighbor
• unknown virtual neighbor
• authentication type mismatch
• authentication failure
• network mask mismatch
• hello interval mismatch
• dead interval mismatch
• option mismatch
• unknown
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
Explanation Indicates that an OSPF virtual routing interface configuration error has
occurred.
The src-ip-addr is the IP address of the interface from which the Brocade
device received the error packet.
• bad version
• area mismatch
• unknown NBMA neighbor
• unknown virtual neighbor
• authentication type mismatch
• authentication failure
• network mask mismatch
• hello interval mismatch
• dead interval mismatch
• option mismatch
• unknown
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
The src-ip-addr is the IP address of the interface from which the Brocade
device received the authentication failure.
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
Explanation An OSPF interface on the Brocade device has retransmitted a Link State
Advertisement (LSA).
• hello
• database description
• link state request
• link state update
• link state ack
• unknown
Message Notification
Level
Explanation Indicates that the state of an OSPF virtual routing interface has changed.
The ospf-state indicates the state to which the interface has changed and
can be one of the following:
• down
• loopback
• waiting
• point-to-point
• designated router
• backup designated router
• other designated router
• unknown
Message Notification
Level
Explanation Indicates that the state of an OSPF virtual neighbor has changed.
The ospf-state indicates the state to which the interface has changed and
can be one of the following:
• down
• attempt
• initializing
• 2-way
• exchange start
• exchange
• loading
• full
• unknown
Message Notification
Level
Explanation Threshold parameters for ICMP transit (through) traffic have been
configured on an interface, and the maximum burst size for ICMP packets
on the interface has been exceeded.
The first num is the maximum burst size (maximum number of packets
allowed).
The second num is the number of seconds during which additional ICMP
packets will be blocked on the interface.
NOTE
This message can occur in response to an attempted Smurf attack.
Message Notification
Level
Explanation Threshold parameters for TCP transit (through) traffic have been configured
on an interface, and the maximum burst size for TCP packets on the
interface has been exceeded.
The first num is the maximum burst size (maximum number of packets
allowed).
The second num is the number of seconds during which additional TCP
packets will be blocked on the interface.
NOTE
This message can occur in response to an attempted TCP SYN attack.
Message Notification
Level
• init
• master
• backup
• unknown
Message Notification
Level
Explanation Indicates that the Brocade device received a packet from another device on
the network with an IP address that is also configured on the Brocade
device.
The mac-addr is the MAC address of the device with the duplicate IP
address.
The portnum is the Brocade port that received the packet with the duplicate
IP address. The address is the packet source IP address.
Message Warning
Level
Explanation IGMP or MLD snooping has run out of hardware application VLANs. There
are 4096 application VLANs per device. Traffic streams for snooping
entries without an application VLAN are switched to the entire VLAN and to
the CPU to be dropped. This message is rate-limited to appear a maximum
of once every 10 minutes. The rate-limited number shows the number on
non-printed warnings.
Message Warning
Level
Explanation Port has received a query with a MLD version that does not match the port
MLD version. This message is rated-limited to appear a maximum of once
every 10 hours.
Explanation The optical transceiver on the given port has risen above or fallen below
the alarm or warning threshold.
Explanation Indicates that an Access Control List (ACL) denied (dropped) packets.
The src-tcp / udp-port is the source TCP or UDP port, if applicable, of the
denied packets.
The portnum indicates the port number on which the packet was denied.
The mac-addr indicates the source MAC address of the denied packets.
The dst-tcp / udp-port indicates the destination TCP or UDP port number, if
applicable, of the denied packets.
Message Warning
Level
Explanation Indicates that a MAC address filtergroup configured on a port has denied
packets.
The num indicates how many packets matching the values above were
dropped during the five-minute interval represented by the log entry.
Explanation IGMP or MLD snooping has run out of software resources. This message
is rate-limited to appear a maximum of once every 10 minutes. The rate-
limited number shows the number of non-printed warnings.
Explanation The device is configured for ip multicast active but there is no configured
IP address and the device cannot send out IGMP queries.
Explanation The Layer 3 switch has received more than the allowed percentage of
prefixes from the neighbor.
The num is the number of prefixes that matches the percentage you
specified. For example, if you specified a threshold of 100 prefixes and 75
percent as the warning threshold, this message is generated if the Layer 3
switch receives a 76th prefix from the neighbor.
Message Warning
Level
The direction indicates whether the filter was applied to incoming packets or
outgoing packets. The value can be one of the following:
• in
• out
The num indicates how many packets matching the values above were
dropped during the five-minute interval represented by the log entry.
Message Warning
Level
Explanation The chassis temperature has risen above the warning level.
• PoH - Covered by IEEE 802.3at 2009 and sometimes called power over HDBaseT, provides up to
95 Watts of power to power-consuming devices.
• Power-sourcing device or Power-sourcing equipment (PSE) - The source of the power, or the
device that integrates the power onto the network. Power sourcing devices and equipment have
embedded PoE technology. The Brocade FastIron PoE device is a power sourcing device.
NOTE
All 802.3af- and 802.3at-compliant power-consuming devices are required to support both application
methods defined in the 802.3af and 802.3at specification.
FIGURE 9
FIGURE 10
PoE autodiscovery
PoE autodiscovery is a detection mechanism that identifies whether an installed device is 802.3af- or
802.3at-compatible. When you plug a device into an Ethernet port that is capable of providing inline
power, the autodiscovery mechanism detects whether the device requires power and how much power
is needed. The autodiscovery mechanism also has a disconnect protection mechanism that shuts
down the power once a PD has been disconnected from the network or when a faulty PD has been
detected. This feature enables safe installation and prevents high-voltage damage to equipment.
PoE autodiscovery is achieved by periodically transmitting current or test voltages that can detect
when a PD is attached to the network. When an 802.3af- or 802.3at-compatible device is plugged into
a PoE, PoE+, or PoH port, the PD reflects test voltage back to the power-sourcing device (the Brocade
device), ultimately causing the power to be switched on. Devices not compatible with 802.3af do not
reflect test voltage back to the power-sourcing device.
Power class
A power class determines the amount of power a PD receives from power-sourcing equipment. When
a valid PD is detected, the Brocade PoE device performs power classification by inducing a specific
voltage and measuring the current consumption of the PD. Depending on the measured current, the
appropriate class is assigned to the PD. PDs that do not support classification are assigned a class of
0 (zero). The following table shows the different power classes and their respective power
consumption needs.
1 optional 4 4 4 4
2 optional 7 7 7 7
Power specifications
The 802.3af (PoE) standard limits power to 15.4 watts (44 to 50 volts) from the power-sourcing device,
in compliance with safety standards and existing wiring limitations. Though limited by the 802.3af
standard, 15.4 watts of power was ample for most PDs, which consumed an average of 5 to 12 watts of
power (IP phones, wireless LAN access points, and network surveillance cameras each consume an
average of 3.5 to 9 watts of power). The 802.3at 2008 (PoE+) standard nearly doubles the power,
providing 30 watts (52 to 55 volts) from the power-sourcing device. The 802.3at 2009 (High PoE)
standard increases available power again, to 60 watts for High PoE and 95 watts for Power over
HDBase-T (PoH).
NOTE
PoH ports on Brocade devices allocate 95 watts for PoE+, High PoE, and PoH PDs.
The PoE power supply provides power to the PoE circuitry block and ultimately to PoE power-
consuming devices. The number of PoE power-consuming devices that one PoE power supply can
support depends on the number of watts required by each power-consuming device and the capacity of
the power supply or power supplies. Each PoE or PoE+ port supports a maximum of 15.4 or 30 watts of
power per power-consuming device. Each PoH port supports a maximum of 95 watts of power (lower
wattage can be negotiated through LLDP messages).
As an example, if each PoE power-consuming device attached to a FastIron PoE device is budgeted to
consume 30 watts of power, one 720- or 748-watt power supply can power up to 24 PoE ports. With the
exception of the ICX6430-C12 and the ICX6450-C12-PD, FastIron platforms support either a second
power supply or an external power supply (EPS) to augment PoE power budget, depending on the
product. Refer to the power supply specifications in the Brocade FastIron hardware installation guide for
the appropriate FastIron device.
By default, a FastIron device pre-allocates power of 15.4 for a physically operational PoE configured
port, 30 watts for a PoE+ configured port, and 95 watts for a PoH port. However, in an ICX 6450-C12
device that is operational without a direct power supply and has pass-through power, there is no pre-
allocation. Instead, power is allocated only when a powered device is connected to the port. By default,
the amount of power allocated depends on the power class of the powered device.
1 First eight ports of Brocade ICX 7450-24P or ICX 7450-48P supply 95w unless PD negotiates lower power requirement through LLDP
protocol messages.
2 Maximum power required for High PoE is 60 watts.
NOTE
This section applies to the FSX 800 and FSX 1600 chassis with PoE power supplies.
PoE+ requires higher power levels than standard PoE. In a chassis running software release 07.2.00
or higher, POE power supplies (SX-ACPWR-POE) are upgraded dynamically to 52 or 54 volts,
depending on the maximum operating voltage the power supplies are capable of. The preferred
voltage mode for PoE+ is 54 volts.
For safety reasons, all PoE power supplies installed in the chassis must operate at the same voltage
mode, either 52 volts or 54 volts. The system selects the voltage mode of the power supply with the
lowest supported voltage as the voltage mode for all PoE power supplies installed in the chassis. For
example, in an FSX 800 chassis with one 52-volt capable PoE power supply and one 54-volt capable
PoE power supply, both power supplies are configured dynamically to operate at 52 volts.
PoE+ voltage selection occurs during each of the following events:
• When the device is powered ON or is rebooted
• When a PoE power supply is installed in the chassis
• When a PoE power supply is removed from the chassis
These events are described in detail in the following sections.
NOTE
A PoE power supply upgrade does not persist beyond a single power cycle. An upgrade occurs
automatically each time a power supply is re-inserted in the chassis.
You can use the show inline power detail command to display detailed information about the PoE
power supplies installed in a FastIron PoE device. For more information, refer to section Displaying
detailed information about PoE power supplies on page 364.
CAUTION
The SX-POE-AC-PWR power supply is designed exclusively for use with the BrocadeFSX PoE
devices. The power supply produces extensive power to support 802.3af and 802.3at
applications. Installing the power supply in a device other than the BrocadeFSX PoE device will
cause extensive damage to your equipment.
device(config)#
Power supply 1 (from left when facing front side) detected.
Power supply 1 (from left when facing front side) is up.
WARNING: PoE power supplies in slots 1 are down rev. PoE/PoE+ function will work,
but output power may be less than 50V under worst case load.
If all power supplies are 54 volts-capable, then all power supplies are configured to operate at 54 volts.
In this case, the system does not display or log a warning message.
device(config)#
Power supply 1 (from left when facing front side) detected.
Power supply 1 (from left when facing front side) is up.
Shutting down power supply in slot 1 because it is not compatible with the existing
PoE power supplies. Please remove and replace.
When the system is next reloaded, the power supply voltage will be selected as described in the section
Voltage selection during bootup on page 344.
• If a 52 volt-capable power supply is installed in a chassis that is operating with 54 volt-capable power
supplies that are not actively providing power, the system configures the power supplies to operate at
52 volts. In this case, the newly installed 52-volt power supply is not powered OFF, and a message
similar to the following is displayed on the console.
However, if the system is currently providing power to one or more PDs, the system does not upgrade
the voltage level. When the system is next reloaded, the power supply voltage is selected as described
in the section Voltage selection during bootup on page 344.
VoIP
Voice over IP (VoIP) is the convergence of traditional telephony networks with data networks. VoIP
uses the existing data network infrastructure as the transport system for both services. Voice is
traditionally transported on a network that uses circuit-switching technology, but data networks are
built on packet-switching technology. To achieve this convergence, technology has been developed to
take a voice signal, which originates as an analog signal, and transport it within a digital medium. This
is done by devices such as VoIP telephones that receive the originating tones and place them in UDP
packets. The size and frequency of these UDP packets depends on the coding / decoding (CODEC)
technology that has been implemented in the VoIP telephone or device. The VoIP control packets use
TCP/IP format.
IP surveillance cameras
IP surveillance technology provides digital streaming of video over Ethernet, providing real-time,
remote access to video feeds from cameras.
The main benefit of using IP surveillance cameras on the network is that you can view surveillance
images from any computer on the network. If you have access to the Internet, you can securely
connect from anywhere in the world to view a chosen facility or even a single camera from your
surveillance system. By using a Virtual Private Network (VPN) or the company intranet, you can
manage password-protected access to images from the surveillance system. Similar to secure
payment over the Internet, images and information are kept secure and can be viewed only by
approved personnel.
FCX fcx_poeplus_02.1.0.b004.fw
PoE firmware is stored in the PoE controller of the FastIron switch. You can install PoE firmware from
the TFTP server on a FastIron switch using CLI commands. To do so, you should have a valid firmware
image on the TFTP server.
NOTE
The PoE firmware upgrade feature is not supported in FIPS mode on Brocade devices.
NOTE
You can install PoE firmware only on one switch at a time. To install PoE firmware on stacked units, you
need to install it individually on every switch in the stack.
NOTE
The CLI syntax to install PoE firmware is different on FSX, FCX, and ICX platforms.
NOTE
Installation of PoE firmware interrupts PoE services on the individual device or module as it is
upgraded. PoE service restarts once PoE firmware installation is complete.
1. Place the PoE firmware on a TFTP server to which the Brocade device has access.
2. Copy the PoE firmware from the TFTP server into the switch as shown in the following examples. Be
sure to use the correct file image for the platform.
To install PoE firmware on FCX and ICX platforms, use the inline power install-firmware stack-
unit command as shown in the following example.
To install PoE firmware on an FSX platform, use the inline power install-firmware command as
shown in the example.
The process of PoE installation begins. You should see output similar to the following.
3. After the firmware is downloaded into the controller, the controller resets and reboots with the new
PoE firmware, You should see output similar to the following.
[MEMBER]local-3@ICX6450-24P Router>Download request from active unit 1 mac =
748e.f8dc.b39c
Downloading - poe.fw
Done.
PoE Info: Programming Brocade defaults.....
PoE Info: Programming Brocade defaults. Step 1: Writing port defaults on module in
slot 1....
PoE Info: Programming Brocade Defaults: Step 2: Writing PM defaults on module in
slot 1.
PoE Info: Programming Brocade defaults. Step 3: Writing user byte 0xf0 on module
in slot 1.
PoE Info: Programming Brocade defaults. Step 4: Saving settings on module in slot
1.
PoE Info: Programming Brocade defaults....completed.
[MEMBER]local-3@ICX6450-24P Router>
NOTE
If you are attempting to transfer a file using TFTP but have received an error message, refer to
Firmware image file types on page 346.
NOTE
In a stack, you must install the PoE firmware on each individual member unit.
1. Place the PoE firmware file on an SCP-enabled host to which the Brocade device has access.
2. Copy the PoE firmware file from the SCP-enabled host into the switch by entering the following
command on the SCP-enabled host.
For FCX, ICX 6430, ICX 6450, ICX 6610, ICX 7250, and ICX 7450 devices:
pscp firmware hostname@management-ip:firmware:stackid:stack-id
The process of PoE firmware installation begins. In the FastIron device CLI, you should see output
similar to the following.
Brocade(config)# scp download successful stackId = 1 file name = poe-fw
Sending PoE Firmware to Stack Unit 1.
PoE Warning: Upgrading firmware in slot 1....DO NOT SWITCH OVER OR POWER DOWN
THE UNIT.
PoE Info: FW Download on slot 1...sending download command...
PoE Info: FW Download on slot 1...TPE response received.
PoE Info: FW Download on slot 1...sending erase command...
PoE Info: FW Download on slot 1...erase command...accepted.
PoE Info: FW Download on slot 1...erasing firmware memory...
PoE Info: FW Download on slot 1...erasing firmware memory...completed
PoE Info: FW Download on slot 1...sending program command...
PoE Info: FW Download on slot 1...sending program command...accepted.
PoE Info: FW Download on slot 1...programming firmware...takes around 6
minutes....
Brocade(config)# U1-MSG: PoE Info: Firmware Download on slot 1.....10 percent
completed.
Once you have entered the commands to enable inline power, the console displays the following
message.
ICX7250-48P Router(config-mif-1/1/1-1/1/48)#
Use the no form of the command to disable the port from receiving inline power.
NOTE
Inline power should not be configured between two switches, as it may cause unexpected behavior.
NOTE
FastIron PoE and PoE+ devices can automatically detect whether a power-consuming device is
802.3af- or 802.3at-compliant.
device(config)# no legacy-inline-power
To disable support for legacy power-consuming devices on a stackable device, enter the following
command at the stack unit CONFIG level of the CLI.
device(config-unit-2)# no legacy-inline-power
On chassis devices, you can disable support for legacy power-consuming devices per slot. To disable
legacy support on all ports in slot 2, enter the following command at the global CONFIG level of the
CLI.
device(config)# no legacy-inline-power 2
NOTE
The no legacy-inline-power command does not require a software reload if it is entered prior to
connecting the PDs. If the command is entered after the PDs are connected, the configuration must be
saved (write memory ) and the software reloaded after the change is placed into effect.
Syntax: [no] legacy-inline-power [slotnum]
NOTE
By default, the inline-power command reserves 30 watts. On PoH ports, inline-power reserves 95
watts.
To re-enable support for legacy power-consuming devices after it has been disabled, enter the
legacy-inline-power command (without the no parameter).
The slotnum variable is required for chassis devices when you disable or re-enable legacy support on
a slot.
Use the show run command to view whether support for PoE legacy power-consuming devices is
enabled or disabled.
The following example turns off support for legacy inline power on an FSX 800.
SX800-3J31-u7(config)# leg
legacy-inline-power set legacy (capacitance-based) PD detection -
default
SX800-3J31-u7(config)# legacy-inline-power
DECIMAL Slot number
<cr>
SX800-3J31-u7(config)# legacy-inline-power 8
SX800-3J31-u7(config)# no leg
legacy-inline-power set legacy (capacitance-based) PD detection -
default
SX800-3J31-u7(config)# no legacy-inline-power 8
The following example turns off legacy inline power for a single stack unit.
ICX7250-24-3J32-u12(config)# no legacy-inline-power
The following example turns off legacy inline power support on the entire stack.
NOTE
If you configure a port with a maximum power level or a power class for a power-consuming device, the
power level or power class takes precedence over the CDP power requirement. If you want a device to
adhere to the CDP power requirement, do not configure a power level or power class on the associated
port.
These commands enable inline power on interface ethernet 1 in slot 1 of unit 1 and set the PoE power
level to 14,000 milliwatts (14 watts).
Syntax: inline power power-limit power-level
The power level variable is the maximum power level in number of milliwatts. The following values are
supported:
• PoE - Enter a value from 1000 through 15,400. The default is 15,400.
• PoE+ - Enter a value from 1000 through 30,000. The default is 30,000.
• PoH - Enter a value from 1000 through 95,000. The default is 95,000. Value is always adjusted to
nearest multiple of 5.
NOTE
Do not configure a power level higher than the default listed. Setting the power level higher than the
default could damage the PD.
For information about resetting the maximum power level, refer to Resetting PoE parameters on page
358.
1 optional 4 4 4
2 optional 7 7 7
4 optional 15.4 30 95
Refer to Considerations for setting power levels on page 354 for essential information. Consider the
following points when setting the power class for a PoE power-consuming device.
• The power class includes any power loss through the cables. For example, a PoE port with a power
class of 3 (15.4 watts) receives a maximum of 12.95 watts of power after 2.45 watts of power loss
through the cable. This is compliant with the IEEE 802.3af and 802.3at specifications for delivering
inline power. Devices that are configured to receive less PoE power, for example, class 1 devices
(4.0 watts), experience a lower rate of power loss through the cable.
• The Brocade PoE, PoE+, or PoH device adjusts the power on a port only if there are available power
resources. If power resources are not available, the following message is displayed on the console
and in the Syslog:
PoE: Failed power allocation of 30000 mwatts on port 1/1/21. Will retry when more
power budget.
These commands enable inline power on interface ethernet 1 in slot 1 of unit 1 and set the power
class to 2.
Syntax: inline power power-by-class class value
The class value variable is the power class. Enter a value between 0 and 4. The default is 0. The table
in Setting the power class for a PoE power-consuming device on page 355 shows the different power
classes and their respective maximum power allocations.
For information about resetting the power class, refer to Resetting PoE parameters on page 358.
NOTE
FSX does not support PoH.
To change the power allocation on an FSX device, use the inline power budget command as shown
in the following example.
In the previous example, the command allocates 150000 milliwatts (150 watts) to the PoE interface
module in slot 7. The command takes effect immediately. The results are displayed in the "power
budget" column in the show inline power detail output. The configuration (inline power budget
150000 module 7) is displayed in the show running-config output.
Syntax: inline power budget num module slot
The num variable is the number of milliwatts to allocate to the module. Enter a value from 0 through
65535000.
The slot variable specifies where the PoE or PoE+ module resides in the chassis.
Command syntax for setting the inline power priority for a PoE port
To configure an inline power priority for a PoE port on a FastIron PoE device, use the inline power
priority command as shown in the following example.
ICX7250-48P Switch# configure terminal
ICX7250-48P Switch(config)# interface ethernet 1/1/1
ICX7250-48P Switch(config-if-e1000-1/1/1)# inline power
decouple-datalink Decouple PoE from data link operational behavior
power-by-class Allocate power based on class of the power devices
power-limit Allocate power based on specified limit
priority Priority class for the purpose of power management
<cr>
ICX7250-48P Switch(config-if-e1000-1/1/1)# inline power priority
DECIMAL Priority value 1..3 (highest..lowest)
<cr>
ICX7250-48P Switch(config-if-e1000-1/1/1)# inline power priority 1
Warning: Inline power configuration on port 1/1/1 has been modified.
In the previous example, the command enables inline power on interface ethernet 1 in slot 1 of unit 1
and sets the inline power priority level to high.
Syntax: [no] inline power priority priority num
The priority num parameter is the inline power priority number. The default is 3 (low priority). You can
specify one of the following values:
• 3 - Low priority
• 2 - High priority
• 1 - Critical priority
Use the inline power command without a priority number to reset a port priority to the default (low)
priority.
Use the no inline power command to disable the port from receiving inline power.
For information about resetting the inline power priority, refer to "Resetting PoE parameters."
To view the inline power priority for all PoE ports, issue the show inline power command at the
Privileged EXEC level of the CLI. Refer to "Displaying PoE operational status."
NOTE
When you reset PoE parameters on an FSX 800 or FSX 1600, you reset the parameters for the entire
PoE chassis.
1--Changing a PoE port power priority from low to high
To change a PoE port power priority from low (the default value) to high and keep the current
maximum configured power level of 3000, enter commands such as the following.
You must specify both the inline power priority and the maximum power level (power-limit command),
even though you are keeping the current configured maximum power level at 3000. If you do not
specify the maximum power level, the device will apply the default value. Also, you must specify the
inline power priority before specifying the power limit.
2--Changing a port power class from 2 to 3
To change a port power class from 2 (7 watts maximum) to 3 (15.4 watts maximum) and keep the
current configured power priority of 2, enter commands such as the following.
device#configure terminal
device(config)# interface ethernet 1/1/1
device(config-if-e1000-1/1/1)# inline power priority 2 power-by-class 3
You must specify both the power class and the inline power priority, even though you are not changing
the power priority. If you do not specify the power priority, the device will apply the default value of 3
(low priority). Also, you must specify the inline power priority before specifying the power class.
The following example sets PoE parameters on interface 2/1/1 in stack unit 12.
Column Definition
Power Capacity The total PoE power supply capacity and the amount of available power (current free) for PoE
power consuming devices. Both values are shown in milliwatts.
Power The number of times the device fulfilled PoE requests for power.
Allocations
Admin State Specifies whether or not Power over Ethernet has been enabled on the port. This value can be
one of the following:
Oper State Shows the status of inline power on the port. This value can be one of the following:
NOTE
When you enable a port using the CLI, it may take 12 or more seconds before the operational
state of that port is displayed correctly in the show inline power output.
Power The number of milliwatts allocated to the port. This value is either the default or configured
Allocated maximum power level, or the power class that was automatically detected by the device.
TABLE 43 Field definitions for the show inline power command (Continued)
Column Definition
PD Type The type of PD connected to the port. This value can be one of the following:
PD Class Determines the maximum amount of power a PD receives. The table in the section Setting the
power class for a PoE power-consuming device on page 355 shows the different power classes
and their respective maximum power allocations.
This field can also be "Unknown" when the device attached to the port cannot advertise its
power class.
NOTE
If an 802.3at PD with a class 4 value is connected to a Brocade FastIron switch, the switch must
be running FastIron release 08.0.20 or later to be able to perform the necessary power
negotiations.
Pri The port in-line power priority , which determines the order in which the port will receive power
while in standby mode (waiting for power). Ports with a higher priority will receive power before
ports with a low priority. This value can be one of the following:
• 3 - Low priority
• 2 - High priority
• 1 - Critical priority
TABLE 43 Field definitions for the show inline power command (Continued)
Column Definition
Fault/Error If applicable, this is the fault or error that occurred on the port. This value can be one of the
following:
• critical temperature - The PoE chip temperature limit rose above the safe operating level,
thereby powering down the port.
• detection failed - discharged capacitor - The port failed capacitor detection (legacy PD
detection) because of a discharged capacitor. This can occur when connecting a non-PD on
the port.
• detection failed - out of range capacitor - The port failed capacitor detection (legacy PD
detection) because of an out-of-range capacitor value. This can occur when connecting a
non-PD on the port.
• internal h/w fault - A hardware problem has hindered port operation.
• lack of power - The port has shut down due to lack of power.
• main supply voltage high - The voltage was higher than the maximum voltage limit, thereby
tripping the port.
• main supply voltage low - The voltage was lower than the minimum voltage limit, thereby
tripping the port.
• overload state - The PD consumes more power than the maximum limit configured on the
port, based on the default configuration, user configuration, or CDP configuration.
• over temperature - The port temperature rose above the temperature limit, thereby powering
down the port.
• PD DC fault - A succession of underload and overload states, or a PD DC/DC fault, caused
the port to shutdown.
• short circuit - A short circuit was detected on the port delivering power.
• underload state - The PD consumes less power than the minimum limit specified in the
802.3af standard.
• voltage applied from ext src - The port failed capacitor detection (legacy PD detection)
because the voltage applied to the port was from an external source.
Total The total power in milliwatts being consumed by all PDs connected to the Interface module, and
the total power in milliwatts allocated to all PDs connected to the Interface module.
Grand Total The total number of current, actual milliwatts being consumed by all PDs connected to the
FastIron PoE device, and the total number of milliwatts allocated to all PDs connected to the
FastIron PoE device.
In the absence of valid PSU power, the total PD power switched is equal to that available to PSE, as
shown in the following example.
device# show inline power pd
Number of PD Ports: 2
Total PD Power Available to PSE: 22400
Total PD Power Switched to PSE: 22400
Port Oper Oper Fault/
State Mode Error
--------------------------------
1/2/1 On 802.3at n/a
1/2/2 On 802.3at n/a
The following shows an example of the show inline power pd display output on a PoE device with the
internal PSU up and no PD ports on.
device# show inline power pd
Number of PD Ports: 2
Total PD Power Available to PSE: 0
Total PD Power Switched to PSE: 0
The following shows an example of the show inline power pd display output on a PoE device with the
internal PSU up and one PD port on in the AT mode.
device# show inline power pd
Number of PD Ports: 2
Total PD Power Available to PSE: 0
Total PD Power Switched to PSE: 0
The following shows an example of the show inline power pd display output on a PoE device with the
internal PSU down and two PD ports on in the AT mode.
device# show inline power pd
Number of PD Ports: 2
Total PD Power Available to PSE: 22400
Total PD Power Switched to PSE: 22400
The following example of the show inline power pd command output is displayed for devices such as
the ICX 6430-C12 that do not support PD ports.
device# show inline power pd
The cli is not applied to this platform
Column Definition
TABLE 44 Field definitions for the show inline power pd command (Continued)
Column Definition
Total PD Power Total PD power switched to PSE. It is either 0 or the total available power.
Switched to PSE
Oper State The operational state of the PD port. This value can be one of the following:
Oper Mode The operational mode of the PD port. This value is meaningful if Oper State is On. This
value can be one of the following:
Fault/Error Shows the error or fault conditions affecting the PD port. This value can be one of the
following:
++++++++++++++++++
Power Supply Data:
++++++++++++++++++
Power Supply #1:
Max Curr: 7.5 Amps
Voltage: 54.0 Volts
Capacity: 410 Watts
POE Details Info. On Stack 2 :
General PoE Data:
+++++++++++++++++
Firmware
Version
--------
02.1.0
... continued on next page...
Slot #Ports #Ports #Ports Power Power Power
Pri: 1 Pri: 2 Pri: 3 Consumption Allocation Budget
------------------------------------------------------------------
3 0 0 48 513.468 W 739.200 W 65535.0 W
4 0 0 48 1349.320 W 1440.0 W 65535.0 W
------------------------------------------------------------------
Total:0 0 96 1862.788 W 2179.200 W 131070.0 W
... continued from previous page...
Cumulative Port State Data:
+++++++++++++++++++++++++++
#Ports #Ports #Ports #Ports #Ports #Ports #Ports
Admin-On Admin-Off Oper-On Oper-Off Off-Denied Off-No-PD Off-Fault
-------------------------------------------------------------------------
20 4 0 24 0 20 0
Cumulative Port Power Data:
+++++++++++++++++++++++++++
#Ports #Ports #Ports Power Power
Pri: 1 Pri: 2 Pri: 3 Consumption Allocation
-----------------------------------------------
20 0 0 0.0 W 0.0 W
Power Supply Data On stack 3:
++++++++++++++++++
Power Supply #1:
Max Curr: 7.5 Amps
Voltage: 54.0 Volts
Capacity: 410 Watts
POE Details Info. On Stack 3 :
General PoE Data:
+++++++++++++++++
Firmware
Version
--------
02.1.0
Cumulative Port State Data:
+++++++++++++++++++++++++++
#Ports #Ports #Ports #Ports #Ports #Ports #Ports
Admin-On Admin-Off Oper-On Oper-Off Off-Denied Off-No-PD Off-Fault
-------------------------------------------------------------------------
22 2 0 24 0 22 0
Cumulative Port Power Data:
+++++++++++++++++++++++++++
#Ports #Ports #Ports Power Power
Pri: 1 Pri: 2 Pri: 3 Consumption Allocation
-----------------------------------------------
0 10 12 0.0 W 0.0 W
The following is an example of the show inline power detail command output on a FSX Series PoE
switch.
The following is an example of show inline power detail command output for an ICX 7250 stack.
Firmware
Version
----------------
01.2.1 Build 003
ICX7250-48p-3J32-u10#
Firmware
Version
----------------
01.6.1 Build 009
ICX7250-24P Router#
TABLE 45 Field definitions for the show inline power detail command
Column Definition
PoE+ Max Operating Voltage This field is applicable to FSX 800 and FSX 1600 PoE+ chassis devices only. It
displays the maximum operating voltage supported by the PoE power supply.
Possible values are:
• 52 V
• 54 V
Model Number The manufacturing part number of the PoE power supply. Values are eight digits in
length and begin with "32" or "30" for example:
• 32016000
• 32007000
Serial Number The serial number of the PoE power supply, for example, AA100730213.
Test Date The PoE power supply firmware test date in the format mm/dd/yyyy.
H/W Status The PoE power supply hardware status code. This field is used by Brocade
Technical Support for troubleshooting.
Capacity The PoE power supply total power capacity (in watts).
PoE Capacity The PoE power supply PoE power capacity (in watts).
Consumption The total number of watts consumed by PoE power consuming devices and PoE
modules in the system, plus any internal or cable power loss.
NOTE
Under the lower total inline power consumption level by Powered Devices (PDs) on
FSX 800 and FSX 1600 devices, the power consumption displayed by the power
supply units (PSUs) is inaccurately displayed as lower than the actual power
consumption of the PSUs due to the sensitivity limitations of power supply
measurements.
TABLE 45 Field definitions for the show inline power detail command (Continued)
Column Definition
NOTE
When you enable a port using the CLI, it may take 12 or more seconds before the operational state of that port is
displayed correctly in the show inline power output.
#Ports Admin-On The number of ports on the Interface module on which the inline power command
was issued.
#Ports Admin-Off The number of ports on the Interface module on which the inline power command
was not issued.
#Ports Oper-On The number of ports on the Interface module that are receiving inline power from
the PoE power supply.
#Ports Oper-Off The number of ports on the Interface module that are not receiving inline power
from the PoE power supply.
#Ports Off-Denied The number of ports on the Interface module that were denied power because of
insufficient power.
#Ports Off-No-PD The number of ports on the Interface module to which no PDs are connected.
#Ports Off-Fault The number of ports on the Interface module that are not receiving power because
of a subscription overload.
Total The totals for all of the fields in the Cumulative Port State Data report.
#Ports Pri: 1 The number of PoE ports on the Interface module that have a PoE port priority of 1.
#Ports Pri: 2 The number of PoE ports on the Interface module that have a PoE port priority of 2.
#Ports Pri: 3 The number of PoE ports on the Interface module that have a PoE port priority of 3.
Power Consumption The total number of watts consumed by PoE power consuming devices, plus any
cable loss.
Power Allocation The number of watts allocated to the Interface module PoE ports. This value is the
sum of the ports’ default or configured maximum power levels, or power classes
automatically detected by the FastIron PoE device.
TABLE 45 Field definitions for the show inline power detail command (Continued)
Column Definition
Power Budget The power budget allocated to the slot. The default value is 65535 watts. Any other
value indicates that the power budget was configured using the CLI command
inline power budget .
Total The totals for all of the fields in the Cumulative Port Power Data report.
Without the inline power ethernet command, you cannot enable inline power on any secondary LAG
ports because the interface configuration mode is not available for LAG secondary ports to run the
inline power command.
You can configure inline power in interface configuration mode on a port that is not a member of a LAG.
If that port then becomes part of a LAG, you can use the inline power ethernet command to configure
inline power parameters on any other port in that LAG.
LAG operational changes can affect the PoE power state unless the decouple-datalink keyword is
used as a command option when configuring inline power on the LAG ports. For more information, refer
to “Decouple the PoE and datalink operations on PoE ports.”
After configuring inline power on PoE ports, you can verify the configuration using the show running-
config command. If you have configured inline power on a regular PoE port in either global
configuration or interface configuration mode, the inline power configuration commands display under
the interface configuration level. If a regular PoE port becomes a PoE LAG port, or a PoE LAG port is
configured under global configuration mode, the inline power configuration commands display under the
global configuration level. If a LAG is removed, the inline power configuration commands for all ports
display under the interface configuration level.
WARNING
If you downgrade to a release earlier than 08.0.01, there is no backwards compatibility for the inline
power ethernet command or the decouple-datalink keyword.
Restriction
If you want to keep decoupling in place on a PoE port when you configure the inline power ethernet
command to change its other parameters, for example, priority, you must also configure the decouple-
datalink keyword.
1. Configure a LAG.
The following example onfigures a static LAG named mylag with an ID of 5.
Device(config-lag-mylag)# deploy
5. Configure inline power on the primary port with the power-by-class option.
The following example configures inline power on the primary port,1/1/1, with power-by-class option
3.
The following are some example datalink operations that can affect the operational state of the PoE on
PoE ports:
• Using disable or enable CLI on the power sourcing equipment (PSE) port interface
• Adding or deleting a tagged PSE port from a VLAN or VLAN group
• The PSE port enters an ErrDisable state
• Adding or deleting a PSE port from a LAG and deploying it
When the optional decouple-datalink keyword is configured using the inline power or inline power
ethernet command, the datalink operational behavior on a PoE port does not affect the power state of
the powered device (PD) that is connecting to the port. You can also configure the power limits and
power-management priority. The inline power command is available in interface configuration mode for
most PoE ports, and the inline power ethernet command is available in global configuration mode for
LAG ports.
The feature Decoupling of Inline Power and Datalink Operations on PoE Ports is useful when a PoE
port is powering a PD that serves a PSE device such as the ICX 6450-C12-PD.
NOTE
The decouple-datalink keyword was introduced in Release 08.0.01 to support the Decoupling of PoE
and Datalink Operations feature. Decoupling of inline power and datalinks is not supported in releases
earlier than Release 08.0.01.
WARNING
If you downgrade to a release earlier than 08.0.01, there is no backwards compatibility for the
decouple-datalink keyword or the inline power ethernet command.
Restriction
If you want to keep decoupling in place on a PoE port when you configure the inline power ethernet
command to change its other parameters, for example, priority, you must also configure the decouple-
datalink keyword.
This task provides a method of overriding the current default behavior of datalink operations that affect
the operation of PoE ports. If you use the optional decouple-datalink keyword when enabling inline
power with the inline power ethernet command, the datalink operational behavior on a PoE port does
not affect the power state of the powered device (PD) that is connecting to the port.
Configure this task on the Brocade PSE for any PoE ports that require the decoupling of inline power
and datalink operations. Any Layer 2 features can then be configured and deployed on these PoE ports.
To avoid the disruption of inline power after the LAG ports are powered up, perform the following
configuration steps in order.
1. Configure inline power on the primary port with the power-by-class option.
The following example configures inline power on the primary port,1/1/1, with power-by-class option
3 and decouples the datalink operations and the inline power for this port.
Device(config-lag-mylag)# deploy
LAG mylag deployed successfully!
While PoE and datalink operations are functionally independent of each other, some datalink
operations affect the operational behavior of PoE ports. When the optional decouple-datalink
keyword is configured using the inline power command, the datalink operational behavior on a PoE
port does not affect the power state of the powered device (PD) that is connecting to the port. You can
also configure the power limits and power-management priority. The inline power command is
available in interface configuration mode for most PoE ports and the inline power ethernet command
is available in global configuration mode for LAG ports.
Perform the following steps to enable inline power and decouple the behavior of the Power over
Ethernet (PoE) and the datalink operations for regular PoE ports. This task provides a method of
overriding the current default behavior of datalink operations that affect the operation of PoE ports. If
you use the optional decouple-datalink keyword when enabling inline power using the inline power
command, the datalink operational behavior on a PoE port does not affect the power state of the
powered device (PD) that is connecting to the port.
NOTE
To enable inline power and decouple PoE and datalink operations on PoE LAG ports, refer to
“Decoupling of PoE and datalink operations on PoE LAG ports.”
Perform this task on the Brocade PSE for any PoE ports that require the decoupling of PoE operations
and datalink operations. Any Layer 2 features can then be configured and deployed on these PoE ports.
1. Enable interface configuration for a PoE port.
The following example enters interface configuration mode for Ethernet port 1/1/1.
The following example configures inline power on Ethernet port 1/1/4 port, specifies an actual power
value of12000 mWatts, and decouples the datalink operations and the PoE operations for this port.
NOTE
Any interface-level configuration must be removed from a 40 Gbps port before it can be broken out into
sub-ports. Refer to Configuring 40 Gbps breakout ports on page 378 for more information.
NOTE
Breakout can be configured only when the device is in store-and-forward mode. Breakout is not
supported in cut-through mode.
NOTE
Stacking cannot be enabled on ICX 7750 units that have breakout configuration on any 40 Gbps ports.
Ports available for breakout are shown for each model in the following table. Refer to the ICX 7750
Ethernet Switch Hardware Installation Guide for information on installing breakout cables.
Module 2 1/2/1 through 1/2/6 (6 ports) 1/2/1 through 1/2/6 (6 ports) 1/2/1 through 1/2/6 (6 ports)
Module 3 1/3/1 through 1/3/6 (6 ports) 1/3/1 through 1/3/6 (6 ports) 1/3/1 through 1/3/6 (6 ports)
NOTE
You should remove any interface-level configuration before configuring breakout.
NOTE
If the device is in cut-through mode and you attempt to configure breakout, an error is returned. Cut-
through must be disabled to return the unit to store-and-forward mode before breakout is configured.
The breakout ethernet command first checks for existing configuration on the port. If existing
configuration is detected, an error message similar to the following is displayed to indicate that prior
configuration must be removed.
Once any previous configuration is removed, the breakout ethernet command must be reissued. The
resulting configuration must be saved, and the unit must then be reloaded before the four 10 Gbps
sub-ports are created and accessible.
For example, to configure ports 1/3/1 through 1/3/6 for breakout, issue the
following commands:
Device# configure terminal
Device(config)# breakout ethernet 1/3/1 to ethernet 1/3/6
Configuring sub-ports
After 40 Gbps ports are successfully configured and activated for breakout, the sub-ports are available
for configuration.
NOTE
Sub-port configuration persists only as long as the original 40 Gbps port is configured for breakout.
Once breakout is removed and the device is reloaded, the sub-ports and their configuration are also
removed.
NOTE
When a breakout cable is removed, the breakout configuration still exists. The user should manually
issue the no breakout command to change a breakout port to a regular port.
Once a 40 Gbps port is broken out, the configuration is saved (with the write memory command), and
the unit is reloaded with the updated configuration, four sub-ports are available for detailed
configuration.
The sub-ports are configured like any other port; however, special four-tuple notation is required to
reference them. Regular ports are identified by three-tuple notation; that is, by three numbers separated
by a forward slash to indicate unit, slot, and port. For example 1/2/3 designates unit 1/slot 2/port 3. To
designate sub-ports, you must add a fourth identification number, for example, 1/2/3:4. The four 10
Gbps sub-ports for port 1/2/3 can be represented as 1/2/3:1, 1/2/3:2, 1/2/3:3, and 1/2/3:4.
The following example shows no breakout on port 1/2/4, a 40 Gbps port that is up.
device# show interface brief
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/1 Down None None None None No 1 0 cc4e.
2439.3700
1/1/2 Down None None None None No 1 0 cc4e.
2439.3701
1/1/3 Down None None None None No 1 0 cc4e.
2439.3702
1/1/4 Down None None None None No 1 0 cc4e.
2439.3703
1/1/5 Down None None None None No 1 0 cc4e.
2439.3704
1/1/6 Down None None None None No 1 0 cc4e.
2439.3708
1/1/7 Down None None None None No 1 0 cc4e.
2439.370c
1/1/8 Down None None None None No 1 0 cc4e.
2439.3710
1/1/9 Down None None None None No 1 0 cc4e.
2439.3714
1/1/10 Down None None None None No 1 0 cc4e.
2439.3718
1/1/11 Down None None None None No 1 0 cc4e.
2439.371c
1/1/12 Down None None None None No 1 0 cc4e.
2439.3720
1/1/13 Down None None None None No 1 0 cc4e.
2439.3724
1/1/14 Down None None None None No 1 0 cc4e.
2439.3728
1/1/15 Down None None None None No 1 0 cc4e.
2439.372c
1/1/16 Down None None None None No 1 0 cc4e.
2439.3730
1/1/17 Down None None None None No 1 0 cc4e.
2439.3734
1/1/18 Down None None None None No 1 0 cc4e.
2439.3735
The following example shows that port 1/2/4 has been configured for breakout into four 10 Gbps sub-
ports.
device# show interface brief
Port Link State Dupl Speed Trunk Tag Pvid Pri MAC Name
1/1/1 Down None None None None No 1 0 cc4e.
2439.3700
1/1/2 Down None None None None No 1 0 cc4e.
2439.3701
1/1/3 Down None None None None No 1 0 cc4e.
2439.3702
1/1/4 Down None None None None No 1 0 cc4e.
2439.3703
1/1/5 Down None None None None No 1 0 cc4e.
2439.3704
1/1/6 Down None None None None No 1 0 cc4e.
2439.3708
1/1/7 Down None None None None No 1 0 cc4e.
2439.370c
1/1/8 Down None None None None No 1 0 cc4e.
2439.3710
1/1/9 Down None None None None No 1 0 cc4e.
2439.3714
1/1/10 Down None None None None No 1 0 cc4e.
2439.3718
1/1/11 Down None None None None No 1 0 cc4e.
2439.371c
1/1/12 Down None None None None No 1 0 cc4e.
2439.3720
1/1/13 Down None None None None No 1 0 cc4e.
2439.3724
1/1/14 Down None None None None No 1 0 cc4e.
2439.3728
1/1/15 Down None None None None No 1 0 cc4e.
2439.372c
1/1/16 Down None None None None No 1 0 cc4e.
2439.3730
1/1/17 Down None None None None No 1 0 cc4e.
2439.3734
1/1/18 Down None None None None No 1 0 cc4e.
2439.3735
1/1/19 Down None None None None No 1 0 cc4e.
2439.3736
1/1/20 Down None None None None No 1 0 cc4e.
2439.3737
1/2/1 Down None None None None No 1 0 cc4e.
2439.3715
1/2/2 Down None None None None No 1 0 cc4e.
2439.3719
1/2/3 Down None None None None No 1 0 cc4e.
2439.371d
1/2/4:1 Up Forward Full 10G None No 1 0 cc4e.
2439.3721
1/2/4:2 Up Forward Full 10G None No 1 0 cc4e.
2439.3722
1/2/4:3 Up Forward Full 10G None No 1 0 cc4e.
2439.3723
1/2/4:4 Up Forward Full 10G None No 1 0 cc4e.
2439.3724
1/2/5 Down None None None None No 1 0 cc4e.
2439.3725
1/2/6 Down None None None None No 1 0 cc4e.
2439.3729
mgmt1 Up None Full 1G None No None 0 cc4e.2439.3700
device> enable
device# configure terminal
device(config)# interface ethernet 1/2/4:1
device(config-if-e10000-1/2/2:1)# port-name subport1
device(config-if-e10000-1/2/2:1)# interface ethernet 1/2/4:2
device(config-if-e10000-1/2/2:2)# port-name subport2
device(config-if-e10000-1/2/2:2)# interface ethernet 1/2/4:3
device(config-if-e10000-1/2/2:3)# port-name subport3
device(config-if-e10000-1/2/2:3)# interface ethernet 1/2/4:4
device(config-if-e10000-1/2/2:4)# port-name subport4
device(config-if-e10000-1/2/2:4)# end
device(config)# end
device# end
device>
The following example checks for ports with active breakout configuration and then removes breakout
from ports 1/3/1 through 1/3/6.
Unit-Id: 1
NOTE
If there had been any configuration on any sub-ports (1/3/1:1 to 1/3/6:4), the no
breakout command would have returned an error. The configuration would
then have to be removed from the sub-ports before breakout configuration
could be removed.
The following example shows a failed attempt to remove breakout from port
1/1/5 as indicated by the error message. Configuration is then removed from
sub-port 1/1/5:1 before the breakout configuration is successfully removed.
Once the updated configuration is loaded, the ports are restored as full 40 Gbps
ports. The former sub-port configuration is not retained in memory.
device(config)# no breakout ethernet 1/1/5
Error: Port 1/1/5:1 is tagged
The following example displays breakout port information for an ICX 7750-48F.
Port 1/2/1 is the only port with active sub-ports; however, ports 1/2/2 and 1/2/4
are configured for breakout, pending reload.
OpenSSL license
Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved.
1. Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
2. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
3. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation or other materials provided with the distribution.
4. All advertising materials mentioning features or use of this software must display the following
acknowledgment: "This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit. ( http://www.openssl.org/ )"
5. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote
products derived from this software without prior written permission. For written permission, please
contact [email protected] .
6. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in
their names without prior written permission of the OpenSSL Project.
7. Redistributions of any form whatsoever must retain the following acknowledgment: "This product
includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( http://
www.openssl.org/ )"
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS'' AND ANY EXPRESSED
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Young should be given attribution as the author of the parts of the library used. This can be in the form
of a textual message at program startup or in documentation (online or textual) provided with the
package.
1. Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
2. Redistributions of source code must retain the copyright notice, this list of conditions and the
following disclaimer.
3. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other materials provided with the distribution.
All advertising materials mentioning features or use of this software must display the following
acknowledgment: "This product includes cryptographic software written by Eric
Young([email protected])" The word 'cryptographic' can be left out if the rouines from the library
being used are not cryptographic related.
4. If you include any Windows specific code (or a derivative thereof) from the apps directory
(application code) you must include an acknowledgment: "This product includes software written by
Tim Hudson ([email protected])"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The licence and
distribution terms for any publically available version or derivative of this code cannot be changed.
i.e. this code cannot simply be copied and put under another distribution licence.
JITC overview
The Joint Interoperability Test Command (JITC) mode on a FastIron device is compliant with the
standards established by JITC, a United States military organization that tests technology pertaining to
multiple branches of the armed services and the government.
The JITC mode implemented on a FastIron device enforces default behavior for some features to
ensure strict JITC certification compliance.
NOTE
The AES-CTR mode must be configured both on the client and server sides to establish an SSH
connection.