Documente Academic
Documente Profesional
Documente Cultură
Alpine, Altitude, BlackDiamond, EPICenter, Ethernet Everywhere, Extreme Ethernet Everywhere, Extreme
Networks, Extreme Turbodrive, Extreme Velocity, ExtremeWare, ExtremeWorks, GlobalPx Content Director, the Go
Purple Extreme Solution Partners Logo, ServiceWatch, Summit, the Summit7i Logo, and the Color Purple, among
others, are trademarks or registered trademarks of Extreme Networks, Inc. or its subsidiaries in the United States
and other countries. Other names and marks may be the property of their respective owners.
2006 Extreme Networks, Inc. All Rights Reserved.
Specifications are subject to change without notice.
The ExtremeWare XOS operating system is based, in part, on the Linux operating system. The machine-readable
copy of the corresponding source code is available for the cost of distribution. Please direct requests to Extreme
Networks for more information at the following address:
Software Licensing Department
3585 Monroe Street
Santa Clara CA 95051
NetWare and Novell are registered trademarks of Novell, Inc. Merit is a registered trademark of Merit Network,
Inc. Solaris and Java are trademarks of Sun Microsystems, Inc. F5, BIG/ip, and 3DNS are registered trademarks of
F5 Networks, Inc. see/IT is a trademark of F5 Networks, Inc.
sFlow is a registered trademark of InMon Corporation.
All other registered trademarks, trademarks and service marks are property of their respective owners.
123456789
Contents
Preface......................................................................................................................................... 21
Introduction .............................................................................................................................21
Terminology........................................................................................................................21
Conventions..............................................................................................................................21
Platform-Dependent Conventions ..........................................................................................22
Text Conventions.................................................................................................................22
Related Publications .................................................................................................................23
Using ExtremeWare XOS Publications Online .........................................................................23
Contents
Creating a Management Account...........................................................................................51
Failsafe Account .................................................................................................................51
Managing Passwords .................................................................................................................52
Applying a Password to the Default Account ..........................................................................52
Applying Security to Passwords.............................................................................................53
Displaying Passwords...........................................................................................................54
Access to Both MSM Console PortsModular Switches Only.........................................................55
Domain Name Service Client Services .........................................................................................55
Checking Basic Connectivity.......................................................................................................56
Ping...................................................................................................................................56
Traceroute ..........................................................................................................................57
Displaying Switch Information ....................................................................................................58
Contents
Configuring SNMPv1/v2c Settings ........................................................................................86
Displaying SNMP Settings....................................................................................................86
SNMPv3.............................................................................................................................87
Message Processing.............................................................................................................88
SNMPv3 Security ................................................................................................................88
SNMPv3 MIB Access Control ...............................................................................................91
SNMPv3 Notification...........................................................................................................92
Using the Simple Network Time Protocol.....................................................................................94
Configuring and Using SNTP ................................................................................................95
SNTP Example....................................................................................................................98
Contents
Dynamic versus Static Load Sharing....................................................................................127
Load-Sharing Algorithms....................................................................................................127
LACPDynamic Link Aggregation.......................................................................................129
Configuring Switch Load Sharing ........................................................................................132
Load-Sharing Examples .....................................................................................................134
Displaying Switch Load Sharing..........................................................................................136
Switch Port Mirroring...............................................................................................................140
Switch Port Mirroring on the BlackDiamond 8800 Family of Switches
and the Summit X450 Switch Only .....................................................................................141
Switch Port Mirroring on the BlackDiamond 10K and 12804 Switch Only ..............................141
Switch Port-Mirroring Rules and Restrictions for All Switches ................................................142
Switch Port-Mirroring Examples ..........................................................................................142
Verifying the Switch Port-Mirroring Configuration .................................................................143
Extreme Discovery Protocol ......................................................................................................144
Software-Controlled Redundant Port and Smart Redundancy .......................................................146
Guidelines for Software-Controlled Redundant Ports and Port Groups .....................................147
Configuring Software-Controlled Redundant Ports.................................................................148
Verifying Software-Controlled Redundant Port Configurations.................................................148
Configuring Automatic Failover for Combination PortsSummit X450 Switch Only .......................150
Displaying Port Configuration Information..................................................................................151
Port DisplaySummit X450 Switch Only ............................................................................154
Port DisplayBlackDiamond 8800 Family of Switches Only .................................................155
Port DisplayBlackDiamond 10K and 12804 Switch Only ...................................................156
Port DisplayBlackDiamond 12804 R-Series Switch Only....................................................157
Chapter 7: Connectivity Fault ManagementBlackDiamond 10K Series and 12804 Switch Only ..... 175
Overview of CFM Elements .......................................................................................................175
Ping and Traceroute ................................................................................................................178
Supported Instances for CFM ...................................................................................................179
Contents
Configuring CFM .....................................................................................................................179
Creating Maintenance Domains ..........................................................................................180
Creating and Associating MAs.............................................................................................181
Creating MPs and the CCM Transmission Interval .................................................................182
Executing Layer 2 Ping and Traceroute Messages .................................................................183
Displaying CFM.......................................................................................................................183
CFM Example .........................................................................................................................185
Contents
Configuring System Health CheckingModular Switches Only.....................................................216
Understanding the System Health CheckerBlackDiamond 10K
and BlackDiamond 12804 Switches Only ............................................................................216
Understanding the System Health CheckerBlackDiamond 8800 Family of Switches Only ......217
Enabling and Disabling Backplane Diagnostic Packets on the Switch .....................................217
Configuring Backplane Diagnostic Packets on the Switch ......................................................218
System Health Check Examples..........................................................................................218
Setting the System Recovery Level............................................................................................220
Configuring System Recovery..............................................................................................220
Configuring Module RecoveryModular Switches Only .........................................................220
Using ELSM ...........................................................................................................................223
About ELSM .....................................................................................................................223
ELSM Hello Messages .......................................................................................................224
ELSM Port States..............................................................................................................224
Link States .......................................................................................................................225
ELSM Link States .............................................................................................................225
ELSM Timers ....................................................................................................................226
Configuring ELSM on a Switch ...........................................................................................227
Displaying ELSM Information .............................................................................................230
Using ELSM with Layer 2 Control Protocols .........................................................................232
ELSM Configuration Example .............................................................................................232
Viewing the System Temperature ..............................................................................................233
System Temperature OutputModular Switches Only...........................................................233
System Temperature OutputSummit X450 Switch Only .....................................................234
Power Supply TemperatureModular Switches Only.............................................................234
Fan Tray TemperatureBlackDiamond 10K Switch Only ......................................................234
Using the Event Management System/Logging ...........................................................................235
Sending Event Messages to Log Targets...............................................................................235
Filtering Events Sent to Targets ..........................................................................................237
Displaying Real-Time Log Messages ....................................................................................245
Displaying Event Logs........................................................................................................245
Uploading Event Logs ........................................................................................................246
Displaying Counts of Event Occurrences ..............................................................................246
Displaying Debug Information.............................................................................................247
Logging Configuration Changes...........................................................................................247
Using sFlow............................................................................................................................247
Configuring sFlow..............................................................................................................248
Displaying sFlow Information..............................................................................................251
Using RMON ..........................................................................................................................251
About RMON ....................................................................................................................251
Supported RMON Groups of the Switch ...............................................................................252
Configuring RMON ............................................................................................................254
Event Actions ...................................................................................................................254
Displaying RMON Information ............................................................................................255
Contents
Types of VLANs.......................................................................................................................258
Port-Based VLANs .............................................................................................................259
Tagged VLANs ..................................................................................................................261
Protocol-Based VLANs .......................................................................................................264
Precedence of Tagged Packets Over Protocol Filters .............................................................267
Default VLAN....................................................................................................................267
VLAN Names ..........................................................................................................................267
Renaming a VLAN .............................................................................................................268
Configuring VLANs on the Switch .............................................................................................268
Creating and Configuring VLANs .........................................................................................268
Enabling and Disabling VLANs ...........................................................................................269
VLAN Configuration Examples ............................................................................................270
Displaying VLAN Settings.........................................................................................................271
Displaying Protocol Information ..........................................................................................272
Tunneling (VMANs) .................................................................................................................272
Overview...........................................................................................................................273
QoS Queue on Egress Port with VMAN packets.....................................................................276
Guidelines for Configuring VMANs ......................................................................................276
Configuring VMANs ...........................................................................................................277
Displaying VMAN Configurations.........................................................................................281
MAC-in-MAC TunnelingBlackDiamond 10K Series and 12804 Switch Only ...............................283
Guidelines for Using MAC-in-MAC Tunnels ..........................................................................286
Configuring MAC-in-MAC Tunnels .......................................................................................286
Displaying MAC-in-MAC Tunneling Information ....................................................................289
Example of MAC-in-MAC Tunneling.....................................................................................292
Contents
Adding Routing Protocols to a Virtual Router........................................................................307
Displaying Ports and Protocols............................................................................................308
Configuring the Routing Protocols and VLANs ......................................................................308
Virtual Router Configuration Example ........................................................................................309
10
Contents
Traffic Groupings ....................................................................................................................352
Precedence of Traffic Groupings .........................................................................................352
ACL-Based Traffic Groupings..............................................................................................353
Explicit Class of Service (802.1p and DiffServ) Traffic Groupings ..........................................354
Physical and Logical Groupings ..........................................................................................361
Verifying QoS Configuration and Performance ............................................................................367
Monitoring PerformanceBlackDiamond 10K and 12804 Switch Only ..................................367
Displaying QoS Profile Information......................................................................................367
Guidelines for Configuring QoS.................................................................................................368
Metering Using ACLsBlackDiamond 8800 Family of Switches, Summit X450 Switch,
and BlackDiamond 12804 R-Series Switch Only ........................................................................368
Creating the ACL Meter......................................................................................................369
Configuring the ACL Meter .................................................................................................369
Associating the Meter with an ACL......................................................................................370
Displaying Meters..............................................................................................................370
Egress Traffic Rate LimitingBlackDiamond 8800 Family of Switches
and Summit X450 Switch Only.................................................................................................370
Applying Egress Bandwidth to a PortBlackDiamond 10K Series and 12804 Switch Only ............371
Bi-Directional Rate ShapingBlackDiamond 10K Switch Only....................................................373
Bandwidth Settings ...........................................................................................................374
Configuring Bi-Directional Rate Shaping..............................................................................375
Hierarchical QoSBlackDiamond 12804 R-Series Switch Only...................................................376
HQoS Implementation .......................................................................................................377
Guidelines for Using Ingress-Only and Ingress and Egress HQoS ............................................382
Configuring HQoS Ingress and Egress Queues ......................................................................382
Displaying HQoS ...............................................................................................................385
HQoS Example..................................................................................................................390
11
Contents
Using SCP2 from an External SSH2 Client ..........................................................................418
SSH2 Client Functions on the Switch..................................................................................419
Secure Socket Layer ................................................................................................................420
Enabling and Disabling SSL ...............................................................................................421
Creating Certificates and Private Keys .................................................................................421
Displaying SSL Information ................................................................................................423
12
Contents
13
Contents
Configuring the Shared Port Segment Timer.........................................................................500
Unconfiguring an EAPS Shared Port....................................................................................500
Displaying EAPS Shared-Port Status Information..................................................................500
EAPS Shared Port Configuration Rules ......................................................................................503
EAPS Shared Port Configuration Examples ................................................................................503
Basic Configuration ...........................................................................................................504
Basic Core Configuration....................................................................................................504
Right Angle Configuration ..................................................................................................505
Combined Basic Core and Right Angle Configuration ............................................................505
Large Core and Access Rings Configuration..........................................................................506
Advanced Configuration .....................................................................................................507
14
Contents
Linking ESRP Switches......................................................................................................563
ESRP and Hitless FailoverModular Switches Only..............................................................563
Determining the ESRP Master ..................................................................................................564
Master Switch Behavior .....................................................................................................565
Pre-Master Switch Behavior................................................................................................565
Slave Switch Behavior .......................................................................................................565
Neutral Switch Behavior ....................................................................................................566
Electing the Master Switch.................................................................................................566
ESRP Failover Time...........................................................................................................566
ESRP Election Algorithms ..................................................................................................567
Configuring an ESRP Domain on a Switch .................................................................................568
Creating and Deleting an ESRP Domain...............................................................................569
Configuring the ESRP Domain ID........................................................................................570
Adding VLANs to an ESRP Domain .....................................................................................570
Enabling and Disabling an ESRP Domain ............................................................................571
Advanced ESRP Features.........................................................................................................571
ESRP Tracking..................................................................................................................571
ESRP Port Restart .............................................................................................................574
ESRP Host Attach .............................................................................................................575
ESRP Port Weight and Dont Count .....................................................................................576
ESRP Groups ....................................................................................................................576
Displaying ESRP Information ...................................................................................................577
Using ELRP with ESRP............................................................................................................578
Using ELRP with ESRP to Recover Loops ............................................................................578
Configuring ELRP..............................................................................................................579
Displaying ELRP Information..............................................................................................580
ESRP Examples ......................................................................................................................580
Single Domain Using Layer 2 and Layer 3 Redundancy.........................................................580
Multiple Domains Using Layer 2 and Layer 3 Redundancy ....................................................583
ESRP Cautions .......................................................................................................................584
Configuring ESRP and IP Multinetting.................................................................................585
ESRP and STP..................................................................................................................585
ESRP and VRRP ...............................................................................................................585
ESRP Groups and Host Attach............................................................................................585
Port Configurations and ESRP ............................................................................................585
15
Contents
VRRP Cautions .......................................................................................................................595
Assigning Multiple Virtual IP Addresses...............................................................................596
VRRP and ESRP ...............................................................................................................596
16
Contents
Route Advertisement of VLANs ...........................................................................................635
RIP Version 1 Versus RIP Version 2 ....................................................................................635
Route Redistribution ...............................................................................................................636
Configuring Route Redistribution ........................................................................................636
RIP Configuration Example ......................................................................................................637
17
Contents
OSPFv3 Configuration Example ................................................................................................668
Configuration for Router 1..................................................................................................668
Configuration for Router 2..................................................................................................669
Configuration for Router 3..................................................................................................669
Part 3: Appendixes
Appendix A: Software Upgrade and Boot Options........................................................................... 709
Downloading a New Image .......................................................................................................709
Image Filename Prefixes ....................................................................................................710
Understanding the Image Version String ..............................................................................710
Software Signatures...........................................................................................................711
Selecting a Primary or a Secondary Image ...........................................................................711
Installing a Core Image ......................................................................................................711
Installing a Modular Software Package ................................................................................713
Rebooting the Switch ........................................................................................................715
Rebooting the Management ModuleModular Switches Only ................................................716
18
Contents
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch
and BlackDiamond 8800 Family of Switches Only......................................................................716
Understanding the I/O Version NumberBlackDiamond 8800 Family of Switches Only ...........717
Performing a Hitless Upgrade .............................................................................................718
Hitless Upgrade Examples..................................................................................................721
Saving Configuration Changes ..................................................................................................724
Viewing a Configuration .....................................................................................................725
Returning to Factory Defaults .............................................................................................725
ASCII-Formatted Configuration Files ...................................................................................725
Using TFTP to Upload the Configuration....................................................................................727
Using TFTP to Download the Configuration ................................................................................729
Synchronizing MSMsModular Switches Only ...........................................................................730
Additional Behavior on the BlackDiamond 8800 Family of Switches Only ...............................730
Automatic Synchronization of Configuration Files .................................................................730
Accessing the Bootloader .........................................................................................................731
Upgrading the BootROMBlackDiamond 10K Switch Only.........................................................732
Upgrading the BootROMSummit X450 Switch Only.................................................................732
Accessing the Bootstrap CLI on the Summit X450................................................................732
Upgrading the FirmwareBlackDiamond 8800 Family of Switches Only ......................................733
Upgrading the FirmwareBlackDiamond 12804 Switch Only .....................................................734
Accessing the Bootstrap CLI on the BlackDiamond 12804 ....................................................735
Displaying the BootROM and Firmware Versions.........................................................................736
19
Contents
Copying Debug Information ................................................................................................757
Managing Debug Files .......................................................................................................758
Evaluation Precedence for ACLs ...............................................................................................762
TOP Command........................................................................................................................762
TFTP Server Requirements.......................................................................................................762
System Health CheckModular Switches Only ..........................................................................762
Overview of the System Health Checker ...............................................................................763
Enabling and Disabling Backplane Diagnostic Packets on the Switch .....................................763
Configuring Backplane Diagnostic Packets on the Switch ......................................................764
System Odometer....................................................................................................................764
Monitored Components ......................................................................................................764
Recorded Statistics ...........................................................................................................764
Temperature Operating Range ..................................................................................................766
Corrupted BootROM on the BlackDiamond 8800 Family of Switches............................................766
Inserting Powered Devices in the PoE ModuleBlackDiamond 8800 Family of Switches Only........766
Modifying the Hardware Table Hash AlgorithmBlackDiamond 8800 Family of Switches and the Summit X450 Switch Only .............................................................................................................767
Untagged Frames on the 10 Gbps ModuleBlackDiamond 10K Switch Only................................768
Running MSM Diagnostics from the BootloaderBlackDiamond 10K Switch Only ........................768
Contacting Extreme Networks Technical Support........................................................................769
20
Preface
This preface provides an overview of this guide, describes guide conventions, and lists other
publications that might be useful.
Introduction
This guide provides the required information to configure ExtremeWare XOS software version 11.3
running on switches from Extreme Networks.
The guide is intended for use by network administrators who are responsible for installing and setting
up network equipment. It assumes a basic working knowledge of:
Ethernet concepts
Routing concepts
Routing Information Protocol (RIP) and Open Shortest Path First (OSPF)
IP Multicast concepts
If the information in the release notes shipped with your switch differs from the information in this guide, follow the
release notes.
Terminology
When features, functionality, or operation is specific to a switch family, the family name is used.
Explanations about features and operations that are the same across all product families simply refer to
the product as the switch.
Conventions
This section describes conventions used in the documentation:
21
Preface
Platform-Dependent Conventions
Unless otherwise noted, all information applies to all platforms supported by ExtremeWare XOS
software, which are the following:
When a feature or feature implementation applies to specific platforms, the specific platform is noted in
the heading for the section describing that implementation.
Finally, minor differences in platform implementations are called out in a note, as shown below:
NOTE
This is a note.
Text Conventions
Table 1 and Table 2 list conventions that are used throughout this guide.
22
Notice Type
Note
Caution
Warning
Related Publications
Description
Screen displays
When you see the word enter in this guide, you must type something, and then
press the Return or Enter key. Do not press the Return or Enter key when an
instruction simply says type.
[Key] names
Italics emphasize a point or denote new terms at the place where they are defined in
the text. (Italics are also used when referring to publication titles.)
Related Publications
The publications related to this one are:
Documentation for Extreme Networks products is available on the World Wide Web at the following
location:
http://www.extremenetworks.com/
23
Preface
NOTE
If you activate a cross-referencing link from the concepts guide PDF file to the command reference PDF file when
the command reference PDF file is closed (that is, not currently open on your computer desktop), the system will
close the user guide PDF file and open the command reference PDF file. To keep both PDF files open when you
activate a cross-reference link, open both PDF files before using the link.
24
This chapter provides an overview of the ExtremeWare XOS version 11.4 software.
BlackDiamond 8810 switch (formerly known as Aspen)ExtremeWare XOS 11.1 and higher
You cannot mix BlackDiamond 12804 R-Series module with non-R-Series modules in the BlackDiamond 12804
chassis. If you attempt to mix these, the system returns an error message.
Summary of Features
The features of ExtremeWare XOS include:
Virtual local area networks (VLANs) including support for IEEE 802.1Q and IEEE 802.1p
Spanning Tree Protocol (STP) (IEEE 802.1D) with multiple STP domains
IP multinetting
27
28
DHCP/BOOTP Relay
RIPng
DiffServ support
TACACS+ support
Traffic mirroring
CLEAR-Flow
IPv6
NetLogin
MAC-in-MAC tunneling
Rate-limiting
Summary of Features
NOTE
For more information on Extreme Networks switch components, see the Extreme Networks Consolidated XOS
Hardware Installation Guide.
ExtremeWare XOS supports virtual routers. This capability allows a single physical switch to be split
into multiple virtual routers. This feature separates the traffic forwarded by a virtual router from the
traffic on a different virtual router. Each virtual router maintains a separate logical forwarding table,
which allows the virtual routers to have overlapping address spaces. Because each virtual router
maintains its own separate routing information, packets arriving at a port on one virtual router can
never be switched to the ports on another. In this release of ExtremeWare XOS, the management port
belongs to one virtual router and all other ports belong to other virtual routers. With software release
11.2, ports can belong to multiple virtual routers.
With multiple virtual routers contained on a single physical switch, some commands in
ExtremeWare XOS now require you to specify to which virtual router the command applies. For
example, when you use the ping command, you must specify from which virtual router the ping
packets are generated. Many commands that deal with switch management use the management virtual
router by default. See the ExtremeWare XOS Command Reference Guide for information on the defaults for
individual commands.
NOTE
The term virtual router is also used with VRRP. VRRP uses the term to refer to a single virtual router that spans
more than one physical router and allows multiple switches to provide redundant routing services to users. For more
information about VRRP, see Chapter 23.
Software Modules
With software version 11.0, ExtremeWare XOS introduces the ability for the user to download a discrete
software module (or feature pack) that contains complete functionality for a specified feature. The user
no longer must download the entire image in order to obtain these specific modules. Secure Shell (SSH)
is the software module available with version 11.0, and the Converged Network Analysis (CNA) test
plug is available with 11.2. (Refer to Appendix C for information on the CNA test plug software, which
you use only if you are running an Avaya voice over IP (VoIP) solution.)
29
SSH
To access the switch using the Secure Shell (SSH), you must download, install, and enable the SSH
software module. After the SSH module is installed, you use it to access the switch. You obtain the SSH
software module through your Extreme Networks support account on the website, after you provide
the required information.
With ExtremeWare XOS version 11.2, Secure Socket Layer (SSL) software is bundled with the SSH
software module.
For more information on SSH and SSL, see Chapter 17.
EAPS
With software version 11.0, the switch supports Ethernet Automatic Protection Switching (EAPS). This
Extreme Networks proprietary protocol provides fast protection switching to Layer 2 devices connected
in a ring topology, such as large campuses. EAPS provides protection to switching similar to STP, but
the convergence is much faster using EAPS. This fast convergence occurs regardless of the number of
switches in the ring.
ExtremeWare XOS software version 11.1 introduces support for multiple EAPS rings. To use this feature,
you must have Core license. (Refer to Software Licensing for more information on the Core license.)
For more information on EAPS, see Chapter 20.
Quality of Service
ExtremeWare XOS has Policy-Based Quality of Service (QoS) features that enable you to specify service
levels for different traffic groups. By default, all traffic is assigned the low QoS policy profile. If needed,
you can customize other QoS policies and apply these policies to different traffic types so that the traffic
types have different guaranteed priority.
With software version 11.0 on the BlackDiamond 10K switch, you can set parameters for ingress traffic,
called bi-directional rate shaping; the BlackDiamond 8800 family of switches, the Summit X450 switch,
and the BlackDiamond 12804 switch do not support bi-directional rate-shaping. (You can do rate
limiting on the BlackDiamond 12804 R-Series modules; see Rate Limiting on page 33.)
For more information on Quality of Service, see Chapter 16.
sFlow
sFlow is a technology for monitoring traffic in data networks containing switches and routers. The
technology relies on statistical sampling of packets from high-speed networks, plus periodic gathering
of the statistics. A UDP datagram format is defined to send the information to an external entity for
analysis. sFlow consists of a Management Information Base (MIB) and a specification of the packet
format for forwarding information to a remote agent. Details of sFlow specifications can be found in
RFC 3176, and specifications and more information can be found at the following website:
http://www.sflow.org
The ExtremeWare XOS implementation is based on sFlow version 5, an improvement from that
specified in RFC3176.
For information on sFlow, see Chapter 9.
30
Summary of Features
ESRP
With software version 11.0, you can use the Extreme Standby Routing Protocol (ESRP). ESRP is an
Extreme Networks proprietary protocol that allows multiple switches to provide redundant routing
services to users. ESRP also provides Layer 2 redundancy; the Layer 3 and Layer 2 redundancy can be
used separately or together.
Using ESRP allows you to simplify your network, and it works very well in meshed networks where
Layer 2 loop protection and Layer 3 redundancy are both required.
For more information on ESRP, see Chapter 22.
IP Multinetting
Software version 11.0 of ExtremeWare XOS introduces IP multinetting, which allows you to overlap
multiple subnets onto the same physical segment. IP multinetting is designed for use in legacy
networks, as a transitional tactic.
For more information on IP multinetting, see Chapter 24.
RMON
With software version 11.1, ExtremeWare XOS introduces Remote Monitoring (RMON), which supports
RFC 1757 and RFC 2021. RMON provides a method of monitoring the network by collecting Ethernet
port statistics and to set systemwide alarm variables.
For more information on RMON, see Chapter 9.
ELRP
ExtremeWare XOS 11.1 introduces support for the Extreme Loop Recovery Protocol (ELRP) ELRP allows
you to prevent, detect, and recover from Layer 2 loops in the network. After a loop is detected through
ELRP, different recovery actions can be taken such as blocking certain ports to prevent looping or
logging a message to the system log. The action taken is largely dependent on the protocol using ELRP
to detect loops in the network.
For more information on using standalone ELRP, see Appendix B. For more information on using ELRP
in conjunction with ESRP, see Chapter 22.
Network Login
Network Login is a method of authenticating users as hosts are added to a network. As a new host is
added to the network, its port connection is in an unauthenticated state, which denies any access to the
network. During authentication, the user supplies a password to the switch using the host. If the
password is authenticated, the port connection is authenticated, and traffic flows to and from the host
and the network.
31
Hitless failoverModular switches with network login configured and enabled support hitless
failover by relaying current client authentication information from the primary MSM to the backup
MSM. If failover occurs during the authentication or re-authentication of a client, the client must
repeat the authentication process.
Local database authenticationYou can explicitly configure and use the local database for
authentication instead of using a RADIUS server. In ExtremeWare XOS 11.2, the local database was
available only if the RADIUS servers became unavailable.
Secure MACYou can configure ports on the switch to accept and authenticate a client with a
specific MAC address. If you associate a MAC address with one or more ports, only authentication
requests for that MAC address received on the port(s) are sent to the configured RADIUS server or
local database; the port(s) block all other authentication requests.
Netlogin MAC-based VLANsThe BlackDiamond 8800 family of switches and the Summit X450
switch support netlogin MAC-based VLANs. Netlogin MAC-based VLANs allow a port assigned to
a VLAN to operate in a MAC-based fashion. This means that each individual untagged supplicant,
identified by its MAC address, can be in different VLANs.
CLEAR-Flow
NOTE
CLEAR-Flow is supported only on the BlackDiamond 10K and 12804 switches.
CLEAR-Flow is a broad framework for implementing security, monitoring, and anomaly detection in
ExtremeWare XOS software. Instead of simply looking at the source and destination of traffic, CLEARFlow allows you to specify certain types of traffic that require more attention. After certain criteria for
this traffic have been met, the switch can either take an immediate, predetermined action; or it can send
a copy of the traffic to another device for analysis.
IPv6
With version 11.2, ExtremeWare XOS software supports IPv6. IPv6 is a more robust IP addressing
scheme and allows for next-generation routing.
NOTE
IP refers to IPv4; IPv6 is always referred to as IPv6.
LLDP
ExtremeWare XOS version 11.2 introduces support for the Link Layer Discovery Protocol (LLDP). LLDP
is a Layer 2 protocol (IEEE standard 802.1ab) that is used to determine the capabilities of devices such
32
Summary of Features
as repeaters, bridges, access points, routers, and wireless stations. ExtremeWare XOS version 11.2 LLDP
support enables devices to advertise their capabilities and media-specific configuration information and
to learn the same information from the devices connected to it.
LLDP provides a standard method of discovering and representing the physical network connections of
a given network management domain. LLDP works together with Extreme Discovery Protocol (EDP).
The LLDP neighbor discovery protocol allows you to discover and maintain accurate network
topologies in a multivendor environment.
For complete information on LLDP, see Chapter 6.
LACP
Beginning with ExtremeWare XOS version 11.3, you can run the Link Aggregation Control Protocol
(LACP) on Extreme Networks devices. LACP enables dynamic load sharing and hot standby for link
aggregation links, in accordance with the IEEE 802.3ad standard. All third-party devices supporting
LACP run with Extreme Networks devices.
The addition of LACP provides the following enhancements to static load sharing, or link aggregation:
Automatic configuration
Deterministic behavior
MAC-in-MAC Tunnels
ExtremeWare XOS version 11.4 introduces support for the emerging IEEE standard 802.1ah, also called
Backbone MAC-in-MAC tunnels. It is used to allow Internet Service Providers (ISPs) to use Ethernet to
create a separate backbone over which the subscribers frames are transported. Each provider has a
separate ID (the service ID). This ID maps to the I-tag on the 802.1ah frame; thus allowing many more
S-tags than the VMAN-limited 4094. These tools permit true hierarchical scaling and full isolation of
provider infrastructure from subscriber broadcast domains.
For complete information on 802.1ah, see Chapter 10.
Rate Limiting
NOTE
You must have R-Series MSMs and modules installed in your BlackDiamond 12804 chassis to run rate limiting.
ExtremeWare XOS version 11.4 introduces support for rate limiting on the BlackDiamond 12804 R-Series
modules. Rate limiting is an important tool for IT managers, especially as more Gigabit Ethernet ports
come online. Limiting bandwidth to specific users, interfaces, or applications helps control network
congestion, ensure high performance, and guarantee that specified traffic flows access the network.
Simply stated, rate limiting is the ability to control bandwidth throughout the network. This is
accomplished by limiting traffic flows in both directionsingress and egresswithin the network. Such
33
CFM
ExtremeWare XOS version 11.4 introduces support for the Connectivity Fault Management (CFM)
protocol. CFM is a Layer 2 protocol (the emerging IEEE standard 802.1ag, draft 4.1) that is used to
detect link faults. You create hierarchical networks, or domains, and test connectivity within that
domain by sending Layer 2 messages, known as Connectivity Check Messages (CCMs).
For complete information on CFM, see Chapter 7.
MSTP
ExtremeWare XOS version 11.4 introduces support for the Multiple Spanning Tree Protocol (MSTP).,
which is the IEEE standard 802.1Q-2003. MSTP allows you to bundle multiple VLANs into one
spanning tree topology, which also provides enhanced loop protection and better scaling. MSTP uses
RSTP as the converging algorithm and is compatible with legacy STP protocols.
For complete information on MSTP, see Chapter 21.
ELSM
ExtremeWare XOS version 11.4 introduces support for Extreme Link Status Monitoring (ELSM). This
Extreme Networks proprietary protocol monitors network health by exchanging hello messages
between two ELSM-enabled peer ports. By monitoring network health, ELSM can detect CPU and
remote link failures. You can also use ELSM with Layer 2 control protocols such as STP, ESRP, and so on
to improve the recovery of Layer 2 loops in the network.
3For complete information on ELSM, see Chapter 9.
Software Licensing
Some Extreme Networks products have capabilities that are enabled by using a software license key.
Typically the keys are unique to the switch and are not transferable. Keys are stored in NVRAM on the
34
Software Licensing
chassis and, once enabled, persist through reboots, software upgrades, power outages, and
reconfigurations.
As all switches ship with Advanced Edge capabilities, two levels of software licensing apply to
ExtremeWare XOS version 11.4: the Core and the Advanced Core license (refer to Table 3). Additionally,
the U.S. government requires a security license to enable certain features.
License level
BlackDiamond
10K switch
BlackDiamond
8800 family
of switches
Summit X450
switch
Advanced Edge
Ships
Ships
Core
Ships
Requires license
Requires license
Advanced Core
MSM 1N/A
N/A
N/A
BlackDiamond
12804 switch
MSM-5 ships
MSM-5R ships
N/A
MSM1XL
Ships
NOTE
With ExtremeWare XOS software version 11.2, BGP functionality moved from the Advanced Core license level to the
Core license. You have BGP functionality with a Core license.
When you are working with modular switches, the license belongs with the switch chassis, not with the
particular MSM module.
The licensing levels required for each feature, if any, are outlined in the discussion of each feature. If
licensing is not mentioned, the full functionality of that feature is available on every switch.
If you attempt to execute a command and you either do not have the required license or have reached
the limits defined by the current license level, the system returns one of the following messages:
Error: This command cannot be executed at the current license level.
Error: You have reached the maximum limit for this feature at this license level.
License Levels
This section describes the licensing capabilities of the various switches.
Upgrading License on the BlackDiamond 8800 Family of Switches and Summit X450
Switch Only
The BlackDiamond 8800 family of switches and the Summit X450 switch ship with an Advanced Edge
license. With ExtremeWare XOS 11.2, you can obtain the Core license for these switches. The Core
license provides additional functionality for some features, as well as Border Gateway Protocol (BGP)
functionality, on the switches.
35
NOTE
Refer to the specific chapter of the ExtremeWare XOS Concepts Guide to determine if the Core license is required
for some functionality. If not noted, all functionality is available, and license is not required.
The MSM 1 ships with a Core license; you cannot upgrade to an Advanced Core license.
Beginning with ExtremeWare XOS version 11.2, you can run BGP with a Core license on the BlackDiamond 10K
switch; that is both the MSM1 and the MSM1XL now run BGP.
NOTE
Beginning with ExtremeWare XOS version 11.2, you can run BGP with a Core license.
PIM DM full
PIM SM full
BGP4
36
Software Licensing
switch. After the license key is installed, it should not be necessary to enter the information again.
However, Extreme Networks recommends keeping the certificate for your records.
You can obtain a regular license; you cannot downgrade licenses. The software key contains all the
necessary information on the license level.
You can upgrade the license of an existing product by purchasing a license voucher from Extreme
Networks. Contact your supplier to purchase a voucher.
The voucher contains information and instructions on obtaining a license key for the switch using the
Extreme Networks Support website at:
http://www.extremenetworks.com/support/techsupport.asp
or by phoning Extreme Networks Technical Support at:
(800) 998-2408
(408) 579-2826
To verify the current license level as well as enabled feature packs (or installed software modules), use
the following command:
show licenses
The show licenses command also displays what feature packs are enabled.
Security Licensing
Certain additional ExtremeWare XOS features, such as the use of SSH2 encryption, may be under
United States export restriction control. Extreme Networks ships these security features in a disabled
state. You can obtain information on enabling these features at no charge from Extreme Networks.
The SSH2 feature is in a separate, loadable software module, which must be installed on the Extreme
Networks switches.
37
Email address
Default Setting
Telnet
Enabled
Port status
Enabled
SSH2
SNMP access
Enabled
SSL
public
private
Disabled
Jumbo frames
EAPS
Disabled
EDP
Enabled
Port mirroring
Disabled
Load sharing
Disabled
ESRP
Disabled
QoS
QoS802.1p replacement
Disabled
QoSDiffServ examination
Disabled
Disabled
Autonegotiation
38
Default Setting
Two VLANs are predefined; the VLAN named default contains all
ports and belongs to the Spanning Tree Protocol Domain (STPD)
named s0. The VLAN mgmt exists only on switches that have an
Ethernet management port and contains only that port. The switch
uses the Ethernet management port for host operation only, not for
switching or routing.
VLANs
Enabled
802.1Q tagging
Disabled for the switch; enabled for each port in the STPD.
IPv4 Routing
Disabled
RIP
Disabled
OSPFv2
Disabled
BGPv4
Disabled
IPv6 Routing
Disabled
RIPng
Disabled
OSPFv3
Disabled
Smart Redundancy
Enabled
Enabled
1812
1813
Auto
VRRP priority
100
IGMP
Enabled
IGMP snooping
Enabled
Enabled
50 W
Low
ELRP
Disabled
Net Login
Disabled
Egress flooding
Enabled
LLDP
Disabled
Autopolarity
Enabled
NOTE
For default settings of individual ExtremeWare XOS features, see individual chapters in this guide.
39
40
41
Names on page 43
Symbols on page 43
Limits on page 44
Syntax Helper
The CLI has a built-in syntax helper. If you are unsure of the complete syntax for a particular command,
enter as much of the command as possible and press [Tab] or [?]. The syntax helper provides a list of
options for the remainder of the command and places the cursor at the end of the command you have
entered so far, ready for the next option.
If you enter an invalid command, the syntax helper notifies you of your error and indicates where the
error is located.
If the command is one where the next option is a named component (such as a VLAN, access profile, or
route map), the syntax helper also lists any currently configured names that might be used as the next
option. In situations where this list is very long, the syntax helper lists only one line of names, followed
by an ellipses (...) to indicate that there are more names that can be displayed.
The syntax helper also provides assistance if you have entered an incorrect command.
Abbreviated Syntax
Abbreviated syntax is the shortest unambiguous allowable abbreviation of a command or parameter.
Typically, this is the first three letters of the command. If you do not enter enough letters to allow the
switch to determine which command you mean, the syntax helper provides a list of the options based
on the portion of the command you have entered.
NOTE
When using abbreviated syntax, you must enter enough characters to make the command unambiguous and
distinguishable to the switch.
42
Command Shortcuts
Components are typically named using the create command. When you enter a command to configure
a named component, you do not need to use the keyword of the component. For example, to create a
VLAN, enter a VLAN name:
create vlan engineering
After you have created the name for the VLAN, you can then eliminate the keyword vlan from all other
commands that require the name to be entered. For example, instead of entering the modular switch
command:
configure vlan engineering delete port 1:3,4:6
Although it is helpful to have unique names for system components, this is not a requirement. If
ExtremeWare XOS encounters any ambiguity in the components within your command, it generates a
message requesting that you clarify the object you specified.
NOTE
If you use the same name across categories (for example, STPD and VLAN names), Extreme Networks recommends
that you specify the identifying keyword as well as the actual name. If you do not use the keyword, the system may
return an error message.
Names
All named components within a category of the switch configuration, such as VLAN, must have a
unique name. Names can be re-used across categories, however. Names must begin with an alphabetical
character and cannot contain any spaces. The maximum length for a name is 32 characters. Names may
contain alphanumeric characters and underscores (_) and cannot be keywords, such as vlan, stp, and so
on.
NOTE
If you use the same name across categories (for example, STPD and VLAN names), Extreme Networks recommends
that you specify the identifying keyword as well as the actual name. If you do not use the keyword, the system may
return an error message.
Symbols
You may see a variety of symbols shown as part of the command syntax. These symbols explain how to
enter the command, and you do not type them as part of the command itself. Table 5 summarizes
command syntax symbols.
43
Description
Enclose a variable or value. You must specify the variable or value. For example, in the
syntax
configure vlan <vlan> ipaddress <ipaddress>
you must supply a VLAN name for <vlan name> and an address for <ipaddress> when
entering the command. Do not type the angle brackets.
square brackets [ ]
Enclose a required value or list of required arguments. One or more values or arguments
can be specified. For example, in the syntax
disable port [<port_list> | all]
you must specify either specific ports or all for all ports when entering the command. Do
not type the square brackets.
vertical bar |
Separates mutually exclusive items in a list, one of which must be entered. For example,
in the syntax
configure snmp add community [readonly | readwrite]
<alphanumeric_string>
you must specify either the read or write community string in the command. Do not type
the vertical bar.
braces { }
Enclose an optional value or a list of optional arguments. One or more values or arguments
can be specified. For example, in the syntax
reboot {time <month> <day> <year> <hour> <min> <sec>} {cancel}
{warm} {msm <slot_id>}
You can specify either a particular date and time combination, or the keyword cancel to
cancel a previously scheduled reboot. (In this command, if you do not specify an
argument, the command will prompt, asking if you want to reboot the switch now.) Do not
type the braces.
Limits
The command line can process up to 4500 characters, including spaces. If you attempt to enter more
than 4500 characters, the switch emits an audible beep and will not accept any further input. The first
4500 characters are processed, however.
Port Numbering
ExtremeWare XOS runs on both stand-alone and modular switches, and the port numbering scheme is
slightly different on each. This section describes the following topics:
The keyword all acts on all possible ports; it continues on all ports even if one port in the sequence fails.
44
Line-Editing Keys
Separate the port numbers by a dash to enter a range of contiguous numbers, and separate the numbers
by a comma to enter a range of noncontiguous numbers:
switch.
For example, if an I/O module that has a total of four ports is installed in slot 2 of the chassis, the
following ports are valid:
2:1
2:2
2:3
2:4
You can also use wildcard combinations (*) to specify multiple modular slot and port combinations. The
following wildcard combinations are allowed:
slota:x-slotb:ySpecifies a contiguous series of ports that begin on one I/O module and end on
another I/O module.
Line-Editing Keys
Table 6 describes the line-editing keys available using the CLI.
Description
[Ctrl] + H or Backspace
Delete or [Ctrl] + D
[Ctrl] + K
45
Description
Insert
Toggles on and off. When toggled on, inserts text and shifts previous text to right.
[Ctrl] + A
[Ctrl] + E
[Ctrl] + L
[Ctrl] + P or Up Arrow
Displays previous command in command history buffer and places cursor at end of
command.
Displays next command in command history buffer and places cursor at end of
command.
[Ctrl] + U
[Ctrl] + W
[Ctrl] + C
Command History
ExtremeWare XOS remembers the commands you enter. You can display a list of these commands by
using the following command:
history
Common Commands
Table 7 describes some of the common commands used to manage the switch. Commands specific to a
particular feature may also be described in other chapters of this guide. For a detailed description of the
commands and their options, see the ExtremeWare XOS Command Reference Guide.
Description
46
configure banner
Common Commands
Description
Creates a VLAN.
Deletes a VLAN.
disable cli-config-logging
disable clipaging
disable idletimeout
disable ssh2
enable cli-config-logging
47
Description
enable clipaging
enable idletimeout
enable telnet
history
show banner
48
configure safe-default-script
All the changes you make using this interactive script can be saved through switch reboots, if you save
the setting. If you want to change the management access:
Use the configure safe-default-script commandmaintains your configuration and reruns the
script.
Use the unconfigure switch all commandresets your switch to the default factory setting and
reruns this script.
You see this interactive script only under the following conditions:
Initial login (when you use the switch the first time)
User
Administrator
In addition to the management levels, you can optionally use an external RADIUS server to provide CLI
command authorization checking for each command. For more information on RADIUS, see Chapter 17.
49
User Account
A user-level account has viewing access to all manageable parameters, with the exception of:
A person with a user-level account can use the ping command to test device reachability and change
the password assigned to the account name. If you have logged on with user capabilities, the command
line prompt ends with a (>) sign. For example:
BD-1.2 >
Administrator Account
A person with an administrator-level account can view and change all switch parameters. With this
level, you can also add and delete users, as well as change the password associated with any account
name (to erase the password, use the unconfigure switch all command).
The administrator can disconnect a management session that has been established by way of a Telnet
connection. If this happens, the user logged on by way of the Telnet connection is notified that the
session has been terminated.
If you have logged on with administrator capabilities, the command line prompt ends with a (#) sign.
For example:
BD-1.18 #
Prompt Text
You must have an administrator-level account to change the text of the prompt. The prompt text is
taken from the SNMP sysname setting. The number that follows the colon indicates the sequential line
of the specific command or line.
If an asterisk (*) appears in front of the command line prompt, it indicates that you have outstanding
configuration changes that have not been saved. For example:
* BD-1.19 #
Default Accounts
By default, the switch is configured with two accounts, as shown in Table 8.
Access Level
admin
This user can access and change all manageable parameters. However, the user may not
delete all admin accounts.
user
This user can view (but not change) all manageable parameters, with the following
exceptions:
This user cannot view the user account database.
This user cannot view the SNMP community strings.
50
If you do not want a password associated with the specified account, press [Enter] twice.
Viewing Accounts
To view the accounts that have been created, you must have administrator privileges. To see the
accounts, use the following command:
show accounts
Deleting an Account
To delete a account, you must have administrator privileges. To delete an account, use the following
command:
delete account <name>
Failsafe Account
The failsafe account is the account of last resort to access your switch. This account is never displayed
by the show accounts command, but it is always present on the switch. To configure the account name
and password for the failsafe account, use the following command:
configure failsafe-account
You will be prompted for the failsafe account name and prompted twice to specify the password for the
account. For example:
BD-10808.1 # configure failsafe-account
enter failsafe user name: blue5green
enter failsafe password:
enter password again:
BD-10808.2
51
NOTE
The information that you use to configure the failsafe account cannot be recovered by Extreme Networks. Technical
support cannot retrieve passwords or account names for this account. Protect this information carefully.
To access your switch using the failsafe account, you must connect to the serial port of the switch. You
cannot access the failsafe account through any other port.
At the switch login prompt, carefully enter the failsafe account name. If you enter an erroneous account
name, you cannot re-enter the correct name.
After you have entered the failsafe account name, you are prompted to enter the password. You will
have three tries to enter the password correctly.
After you have successfully logged in to the failsafe account, you see the following prompt:
failsafe>
LoginUse this command to access the switch CLI. You will have full administrator capabilities.
RebootUse this command to reboot the current MSM (MSM on modular switches only).
ExitUse this command to exit the failsafe account and return to the login prompt.
Typically, you use the Login command to correct the problem that initially required you to use the
failsafe account.
Managing Passwords
When you first access the switch, you have a default account. You configure a password for your
default account. As you create other accounts (see Creating a Management Account on page 51), you
configure passwords for those accounts.
Beginning with ExtremeWare XOS version 11.2, the software allows you to apply additional security to
the passwords. You can enforce a specific format and minimum length for the password. Additionally,
you can age out the password, prevent a user from employing a previously used password, and lock
users out of the account after three consecutive failed login attempts.
This section describes the following topics:
52
Managing Passwords
NOTE
Passwords are case-sensitive; user names are not case-sensitive.
NOTE
If you forget your password while logged out of the CLI, contact your local technical support representative, who will
advise on your next course of action.
Upper-case A-Z
Lower-case a-z
0-9
!, @, #, $, %, ^, *, (, )
To set this format for the password, use the following command:
configure account [all | <name>] password-policy char-validation [none | all-chargroups]
You can enforce a minimum length for the password and set a maximum time limit, after which the
password will not be accepted.
To set a minimum length for the password, use the following command:
configure account [all | <name>] password-policy min-length [<num_characters> |
none]
53
You can block users from employing previously used passwords by issuing the command:
configure account [all | <name>] password-policy history [<num_passwords> | none]
By default, the system terminates a session after the user has three consecutive failed login attempts.
The user may then launch another session (which again would terminate after three consecutive failed
login attempts). To increase security, you can lock users out of the system entirely after three failed
consecutive login attempts. To use this feature, use the following command:
configure account [all | <name>] password-policy lockout-on-login-failures [on |
off]
NOTE
If you are not working on SSH, you can configure the number of failed logins that trigger lockout, using the
configure cli max-failed-logins <num-of-logins> command. (This command also sets the number of
failed logins that terminate the particular session.)
After the users account is locked out (using the configure account password-policy lockout-onlogin-failures command), it must be specifically re-enabled by an administrator. To re-enable a
locked-out account, use the following command:
clear account [all | <name>] lockout
Selecting the all option affects the setting of all existing and future new accounts.
NOTE
The default admin account and failsafe accounts are never locked out, no matter how many consecutive failed login
attempts.
Displaying Passwords
To display the accounts and any applied password security, use the following command:
show accounts password-policy
The following output shows a sample display from the show accounts password-policy command:
--------------------------------------------------------------------------Accounts global configuration(applied to new accounts on creation)
--------------------------------------------------------------------------Password Max. age
: None
Password History limit
: None
Password Min. length
: None
Password Character Validation
: Disabled
Accts. lockout on login failures: Disabled
Accounts locked out
: No
---------------------------------------------------------------------------
54
Password
Password Password Password Flags
Expiry
Max. age Min. len History
Date
Limit
--------------------------------------------------------------------------admin
None
None
None
--user
None
None
None
--test Apr-17-2005
12
32
9
C---------------------------------------------------------------------------Flags: (C) Password character validation enabled, (L) Account locked out
(l) Account lockout on login failures enabled
You can also display which accounts may be locked out by issuing the following command:
show accounts
The following output shows a sample display from the show accounts command:
User Name
Access LoginOK Failed
---------------- ------ ------- -----admin
R/W
3
1
user
RO
0
0
dbackman
R/W
0
0
ron* RO
0
0
nocteam
RO
0
0
---------------------------------------(*) - Account locked
telnet
download bootrom
download image
ping
traceroute
55
In addition, the nslookup utility can be used to return the IP address of a hostname. (This command is
available only on the Default VR on the BlackDiamond 10K and 12804 switches.)
You can specify up to eight DNS servers for use by the DNS client using the following command:
configure dns-client add
You can specify a default domain for use when a host name is used without a domain. Use the
following command:
configure dns-client default-domain
For example, if you specify the domain xyz-inc.com as the default domain, then a command such as
ping accounting1 will be taken as if it had been entered ping accounting1.xyz-inc.com.
The switch offers the following commands for checking basic connectivity:
ping
traceroute
Ping
The ping command enables you to send Internet Control Message Protocol (ICMP) echo messages to a
remote IP device. The ping command is available for both the user and administrator privilege level.
Beginning with ExtremeWare XOS version 11.2, you can ping an IPv6 address.
The ping command syntax is:
ping {count <count> {start-size <start-size>} | continuous {start-size <start-size>} |
{start-size <start-size> {end-size <end-size>}}} {udp} {dont-fragment} {ttl <ttl>}
{tos <tos>} {interval <interval>} {vr <vrid>} {ipv4 <host> | ipv6 <host>} {from} {with
record-route}
56
Description
count
start-size
Specifies the size, in bytes, of the packet to be sent, or the starting size if
incremental packets are to be sent.
continuous
Specifies that UDP or ICMP echo messages to be sent continuously. This option can
be interrupted by pressing [Ctrl] + C.
end-size
udp
Specifies that the ping request should use UDP instead of ICMP.
dont-fragment
ttl
tos
interval
vr
Specifies the virtual router name to use for sending out the echo message. If not
specified, VR-Default is used.
NOTE: The BlackDiamond 8800 family of switches and the Summit X450 switch
does not support user-created VRs.
ipv4
ipv6
host
from
Uses the specified source address. If not specified, the address of the transmitting
interface is used.
with record-route
If a ping request fails, the switch stops sending the request after three attempts. Press [Ctrl] + C to
interrupt a ping request earlier. The statistics are tabulated after the ping is interrupted or stops.
You use the ipv6 variable to ping an IPv6 host by generating an ICMPv6 echo request message and
sending the message to the specified address. If you are contacting an IPv6 link local address, you must
specify the VLAN you are sending the message from, as shown in the following example (you must
include the % sign): ping <ipv6> <link-local address> %<vlan_name> <host>.
Traceroute
The traceroute command enables you to trace the routed path between the switch and a destination
endstation. The traceroute command syntax is:
traceroute {vr <vrid>} {ipv4 <host>} {ipv6 <host>} {ttl <number>} {from <from>} {[port
<port>] | icmp}
Where:
vr is the name of the virtual router (the BlackDiamond 8800 family of switches and the Summit
57
from uses the specified source address in the ICMP packet. If not specified, the address of the
transmitting interface is used.
host is the host of the destination endstation. To use the hostname, you must first configure DNS.
ttl configures the switch to trace the hops until the time-to-live has been exceeded for the switch.
Beginning with ExtremeWare XOS, you can trace the route between the switch and an IPv6 address.
However, you must specify the targets IPv6 address to use this command.
The following output shows a sample display from this command on a modular switch:
58
SysName:
SysLocation:
SysContact:
System MAC:
BD-10808
SysHealth check:
Recovery Mode:
System Watchdog:
Enabled
None
Enabled
Current Time:
Timezone:
Boot Time:
Next Reboot:
MSM:
Current State:
MSM-A *
-----------------------MASTER
Image Selected:
Image Booted:
Primary ver:
Secondary ver:
primary
primary
11.1.0.14
11.1.0.14
Config Selected:
Config Booted:
primary.cfg
primary.cfg
primary.cfg
MSM-B
-----------------------INIT
SummitX450-24x
Current Time:
Timezone:
Boot Time:
Next Reboot:
Current State:
Image Selected:
Image Booted:
Primary ver:
Secondary ver:
OPERATIONAL
primary
primary
11.2.0.16
11.2.0.10
Config Selected:
Config Booted:
primary.cfg
primary.cfg
primary.cfg
59
60
Overview on page 61
Understanding System Redundancy with Dual MSMs InstalledModular Switches Only on page 72
Overview
Using ExtremeWare XOS, you can manage the switch using the following methods:
Access the command line interface (CLI) by connecting a terminal (or workstation with terminalemulation software) to the console port.
Access the switch remotely using TCP/IP through one of the switch ports or through the dedicated
10/100 unshielded twisted pair (UTP) Ethernet management port. Remote access includes:
Simple Network Management Protocol (SNMP) access using EPICenter or another SNMP
manager.
Download software updates and upgrades. For more information, see Appendix A, Software
Upgrade and Boot Options.
NOTE
Beginning with ExtremeWare XOS 11.2, the switch accepts IPv6 Telnet and SSH2 connections.
Two console sessions are available if two management modules are installed.
61
For more information about the line-editing keys that you can use with the XOS shell, see Line-Editing
Keys on page 45.
After the connection has been established, you see the switch prompt and you can log in.
62
The switch uses the Ethernet management port only for host operation, not for switching or routing.
The TCP/IP configuration for the management port is done using the same syntax as used for virtual
LAN (VLAN) configuration. The VLAN mgmt comes preconfigured with only the management port as a
member. The management port is a member of the virtual router VR-Mgmt.
When you configure the IP address for the VLAN mgmt, this address gets assigned to the primary
MSM. You can connect to the management port on the primary MSM for any switch configuration. The
management port on the backup MSM is available only when failover occurs. At that time, the primary
MSM relinquishes its role, the backup MSM takes over, and the VLAN mgmt on the new primary MSM
acquires the IP address of the previous primary MSM.
To configure the IP address and subnet mask for the VLAN mgmt, use the following command:
configure vlan mgmt ipaddress <ip_address>/<subnet_mask>
To configure the default gateway (you must specify VR-Mgmt for the management port and VLAN
mgmt), use the following command:
configure iproute add default <gateway> {vr <vrname>} {<metric>} {multicast-only |
unicast-only}
The following example configuration sets the management port IP address to 192.168.1.50, mask length
of 25, and configures the gateway to use 192.168.1.1:
configure vlan mgmt ipaddress 192.168.1.50/25
configure iproute add default 192.168.1.1 vr vr-mgmt
63
Authenticating Users
ExtremeWare XOS provides three methods to authenticate users who log in to the switch:
RADIUS client
TACACS+
RADIUS Client
Remote Authentication Dial In User Service (RADIUS, RFC 2138) is a mechanism for authenticating and
centrally administrating access to network nodes. The ExtremeWare XOS RADIUS client
implementation allows authentication for Telnet or console access to the switch.
For detailed information about RADIUS and configuring a RADIUS client, see Chapter 17, Security.
TACACS+
Terminal Access Controller Access Control System Plus (TACACS+) is a mechanism for providing
authentication, authorization, and accounting on a central server, similar in function to the RADIUS
client. The ExtremeWare XOS version of TACACS+ is used to authenticate prospective users who are
attempting to administer the switch. TACACS+ is used to communicate between the switch and an
authentication database.
For detailed information about TACACS+ and configuring TACACS+, see Chapter 17, Security.
Management Accounts
ExtremeWare XOS supports two levels of management accounts (local database of accounts and
passwords): User and Administrator. A user level account can view but not change all manageable
parameters, with the exception of the user account database and SNMP community strings. An
administrator level account can view and change all manageable parameters.
For detailed information about configuring management accounts, see Chapter 2, Accessing the
Switch.
Using Telnet
ExtremeWare XOS supports the Telnet Protocol based on RFC 854. Telnet allows interactive remote
access to a device and is based on a client/server model. ExtremeWare XOS uses Telnet to connect to
other devices from the switch (client) and to allow incoming connections for switch management using
the CLI (server).
64
Using Telnet
This section describes the following Telnet topics:
If you use Telnet to establish a connection to the switch, you must specify the IP address or host name
of the device that you want to connect to. Check the user manual supplied with the Telnet facility if you
are unsure of how to do this.
After the connection is established, you see the switch prompt and you can log in.
The same is true if you use the switch to connect to another host. From the CLI, you must specify the IP
address or host name of the device that you want to connect to. If the host is accessible and you are
allowed access, you may log in.
For more information about using the Telnet client on the switch, see Connecting to Another Host
Using Telnet on page 66.
65
NOTE
The BlackDiamond 8800 family of switches (formerly known as Aspen) and the Summit X450 switch do not support
user-created VRs.
If the TCP port number is not specified, the Telnet session defaults to port 23. If the virtual router name
is not specified, the Telnet session defaults to VR-Mgmt. Only VT100 emulation is supported.
Beginning with ExtremeWare XOS 11.2, you can use Telnet to access either the primary or the backup
MSM regardless of which console port you are connected to. For more information see Chapter
2, Accessing the Switch.
Switch Media Access Control (MAC) address, found on the rear label of the switch
IP address
The switch contains a BOOTP and Dynamic Host Configuration Protocol (DHCP) client, so if you have
a BOOTP or DHCP server in your IP network, you can have it assign IP addresses to the switch. This is
more likely to be desirable on the switch's VLAN mgmt than it is on any other VLANs.
You can enable the BOOTP or DHCP client per VLAN by using the following commands:
enable bootp vlan [<vlan> | all]
enable dhcp vlan [<vlan_name> | all]
You can disable the BOOTP or DHCP client per VLAN by using the following commands:
disable bootp vlan [<vlan> | all]
disable dhcp vlan [<vlan_name> | all]
To view the current state of the BOOTP or DHCP client, use the following command:
show dhcp-client state
The switch does not retain IP addresses assigned by BOOTP or DHCP through a power cycle, even if
the configuration has been saved. To retain the IP address through a power cycle, you must configure
the IP address of the VLAN using the CLI or Telnet.
66
Using Telnet
If you need the switch's MAC address to configure your BOOTP or DHCP server, you can find it on the
rear label of the switch. Note that all VLANs configured to use BOOTP or DHCP use the same MAC
address to get their IP address, so you cannot configure the BOOTP or DHCP server to assign multiple
specific IP addresses to a switch depending solely on the MAC address.
Log in to the switch with administrator privileges using the console interface.
If you are logging in for the first time, use the default user name admin to log in with
administrator privileges. For example:
login: admin
Administrator capabilities enable you to access all switch functions. The default user names have
no passwords assigned.
If you have been assigned a user name and password with administrator privileges, enter them at
the login prompt.
For example:
configure vlan default ipaddress 123.45.67.8 255.255.255.0
67
NOTE
As a general rule, when configuring any IP addresses for the switch, you can express a subnet mask by using
dotted decimal notation or by using classless inter domain routing notation (CIDR). CIDR uses a forward slash
plus the number of bits in the subnet mask. Using CIDR notation, the command identical to the previous
example is: configure vlan default ipaddress 123.45.67.8/24
6 Configure the default route for the switch using the following command:
configure iproute add default <gateway> {vr <vrname>} {<metric>} {multicast-only |
unicast-only}
For example:
configure iproute add default 123.45.67.1
7 Save your configuration changes so that they will be in effect after the next switch reboot.
If you want to save your changes to the currently booted configuration, use the following
command:
save
ExtremeWare XOS allows you to select or create a configuration file name of your choice to save
the configuration to. If you want to save your changes to an existing or new configuration file,
use the following command:
save configuration [<existing-config> | <new-config>]
8 When you are finished using the facility, log out of the switch by typing:
logout or quit
ExtremeWare XOS 11.2 introduces the concept of safe defaults mode. Safe defaults mode runs an
interactive script that allows you to enable or disable SNMP, Telnet, and switch ports. When you set up
your switch for the first time, you must connect to the console port to access the switch. After logging
in to the switch, you enter safe defaults mode. Although SNMP, Telnet, and switch ports are enabled by
default, the script prompts you to confirm those settings.
If you choose to keep the default setting for Telnetthe default setting is enabledthe switch returns
the following interactive script:
Since you have chosen less secure management methods, please remember to increase
the security of your network by taking the following actions:
* change your admin password
* change your SNMP public and private strings
* consider using SNMPv3 to secure network management traffic
For more detailed information about safe defaults mode, see Safe Defaults Setup Method on page 49.
68
Using Telnet
To configure the virtual router from which you receive a Telnet request, use the following command:
configure telnet vr [all | default | <vr_name>]
To change the default TCP port number, use the following command:
configure telnet port [<portno> | default]
The range for the port number is 1 through 65535. The following TCP port numbers are reserved and
cannot be used for Telnet connections: 22, 80, and 1023. If you attempt to configure a reserved port, the
switch displays an error message.
Use the edit policy command to launch a VI-like editor on the switch. You can create the policy
directly on the switch.
Use the tftp command to transfer a policy that you created using a text editor on another system to
the switch.
For more information about creating and implementing ACLs and policies, see Chapter 13, Policy
Manager, and Chapter 14, Access Lists (ACLs).
Sample ACL Policies. The following are sample policies that you can apply to restrict Telnet access.
In the following example named MyAccessProfile.pol, the switch permits connections from the subnet
10.203.133.0/24 and denies connections from all other addresses:
MyAccessProfile.pol
Entry AllowTheseSubnets {
if {
source-address 10.203.133.0 /24;
}
then
{
permit;
}
}
In the following example named MyAccessProfile_2.pol, the switch does not permit connections from
the subnet 10.203.133.0/24 but accepts connections from all other addresses:
MyAccessProfile_2.pol
Entry dontAllowTheseSubnets {
if {
source-address 10.203.133.0 /24;
}
then
{
deny;
69
Configuring Telnet to Use ACL Policies. This section assumes that you have already loaded the policy on
the switch. For more information about creating and implementing ACLs and policies, see Chapter
13, Policy Manager, and Chapter 14, Access Lists (ACLs).
To configure Telnet to use an ACL policy to restrict Telnet access, use the following command:
configure telnet access-profile [<access_profile> | none]
You must be logged in as an administrator to configure the virtual router(s) used by Telnet and to
enable or disable Telnet.
70
71
NOTE
The BlackDiamond 8800 family of switches and the Summit X450 switch do not support user-created VRs.
The TFTP session defaults to port 69. If you do not specify a virtual router, VR-Mgmt is used.
For example, to connect to a remote TFTP server with an IP address of 10.123.45.67 and get or retrieve
an ExtremeWare XOS configuration file named XOS1.cfg from that host, use the following command:
tftp 10.123.45.67 -g -r XOS1.cfg
When you get the file via TFTP, the switch saves the file to the primary MSM. If the switch detects a
backup MSM in the running state, the file is replicated to the backup MSM.
To view the files you retrieved, enter the ls command at the command prompt.
Node Election
Node election is based on leader election between the MSMs installed in the chassis. The MSM installed
in slot A has master status. The Device Manager collects the node health information and forwards that
information to the Node Manager. The Node Manager then computes the quality of the node which is
later used in leader election.
When two nodes exchange their health information, they determine the healthier node. Based on the
election results obtained from all of the nodes, the healthiest node wins the election criteria.
At the end of the election process, a master is selected. The master MSM runs the switch management
functions, and the backup MSM is available if the master fails.
72
Node stateThe node state must be STANDBY to participate in leader election and be selected
master. If the node is in the INIT, DOWN, or FAIL states, it cannot participate in leader election. For
more information about the node states, see Viewing Node Status on page 75.
Configuration priorityThis is a user assigned priority. The configured priority is compared only
after the node meets the minimum thresholds in each category for it to be healthy. Required
processes and devices must not fail.
Health of secondary hardware componentsThis represents the health of the switch components,
such as power supplies, fans, and so forth.
Slot IDThe MSM slot where the node is installed (MSM-A or MSM-B).
If you do not configure any priorities, MSM-A has a higher priority than MSM-B. For the slot_id
parameter, enter A for the MSM installed in slot A or B for the MSM installed in slot B. By default, the
priority is 0 and the node priority range is 1 through 100. The lower the value, the higher the priority.
If the nodes are not synchronized, and both MSMs are running ExtremeWare XOS 11.0 or later,
proceed to step 2.
If the nodes are not synchronized, and one MSM is running ExtremeWare XOS 10.1 or earlier,
proceed to step 3.
2 Use the synchronize command to ensure that the backup has the same software in flash as the
master.
NOTE
On the BlackDiamond 10K switch, both the backup and the master MSMs must be running ExtremeWare XOS
11.0 or later to use the synchronize command.
73
Reboots the backup MSM to prepare it for synchronizing with the master MSM
If both nodes are running ExtremeWare XOS 11.0 or later, use the run msm-failover command.
If one node is running ExtremeWare XOS 10.1 or earlier, use the run msm-failover {force}
command. By specifying force, failover occurs regardless of the version of software running on
the MSMs.
NOTE
To ensure that all of the configuration commands in the backups flash are updated, issue the save command after
you make any changes.
If a failover occurs, the backup MSM continues to use the masters active configuration. If the backup
determines that it does not have the masters active configuration because a run-time synchronization
did not happen, the backup uses the configuration stored in its flash memory. Because the backup
always uses the masters active configuration, the active configuration remains in affect regardless of
the number of failovers.
74
NOTE
If you issue the reboot command before you save your configuration changes, the switch prompts you to save your
changes. To keep your configuration changes, save them before you reboot the switch.
Bulk Checkpointing
Bulk checkpointing requires that the master and backup run-time states be synchronized. Since
ExtremeWare XOS runs a series of applications, an application starts checkpointing only after all of the
applications it depends on have transferred their run-time states to the backup MSM.
After one application completes bulk checkpointing, the next application proceeds with its bulk
checkpointing.
To monitor the checkpointing status, use the show checkpoint-data {<process>} command.
To view the status of bulk checkpointing and see if the backup MSM is synchronized with the master
MSM, use the show switch {detail} command.
Dynamic Checkpointing
After an application transfers its saved state to the backup MSM, dynamic checkpointing requires that
any new configuration information or state changes that occur on the master be immediately relayed to
the backup. This ensures that the backup has the most up-to-date and accurate information.
This command is also helpful in debugging synchronization problems that occur at run time.
This command displays, in percentages, the amount of copying completed by each process and the
traffic statistics between the process on both the master and the backup MSMs.
75
Description
BACKUP
In the backup state, this node becomes the master node if the master fails or enters the DOWN
state. The backup node also receives the checkpoint state data from the master.
DOWN
In the down state, the node is not available to participate in leader election. The node enters this
state during any user action, other than a failure, that makes the node unavailable for
management. Examples of user actions are:
Upgrading the software
Rebooting the system using the reboot command
Initiating an MSM failover using the run msm-failover command
Synchronizing the MSMs software and configuration in non-volatile storage using the
synchronize command
FAIL
In the fail state, the node has failed and needs to be restarted or repaired. The node reaches this
state if the system has a hardware or software failure.
INIT
In the initial state, the node is being initialized. A node stays in this state when it is coming up
and remains in this state until it has been fully initialized. Being fully initialized means that all of
the hardware has been initialized correctly and there are no diagnostic faults.
MASTER
In the master state, the node is responsible for all switch management functions.
STANDBY
In the standby state, leader election occursthe master and backup nodes are elected. The
priority of the node is only significant in the standby state.
76
Behavior
Hitless
Yes
Ethernet Automatic
Protection Switching
(EAPS)
The primary MSM replicates all EAPS BPDUs to the backup, which allows
the backup to be aware of the state of the EAPS domain. Since both MSMs
receive EAPS BPDUs, each MSM maintains equivalent EAPS states.
Yes
By knowing the state of the EAPS domain, the EAPS process running on the
backup MSM can quickly recover after an MSM failover. Although both
MSMs receive EAPS BPDUs, only the primary transmits EAPS BPDUs to
neighboring switches and actively participates in EAPS.
Extreme Standby
Router Protocol (ESRP)
If MSM failover occurs on the ESRP MASTER switch, it sends a hello packet
with the HOLD bit set. On receiving this packet, the ESRP SLAVE switch
freezes all further state transitions. The MASTER switch keeps sending
hellos with the HOLD bit set on every hello interval. When the MASTER is
done with its MSM failover, it sends another hello with the HOLD bit reset.
The SLAVE switch resumes normal processing. (If no packet is received with
HOLD bit reset, the SLAVE timeouts after a certain time interval and
resumes normal processing).
Yes
No
Extreme Discovery
Protocol (EDP)
EDP does not checkpoint protocol data units (PDUs) or states, so the backup
MSM does not have the neighbors information. If the backup MSM becomes
the master MSM, and starts receiving PDUs, the new master learns about its
neighbors.
No
Protocol Independent
Multicast (PIM)
After a failover, all hardware and software caches are cleared and learning
from the hardware is restarted. This causes a traffic interruption since it is
the same as if the switch rebooted for all Layer 3 multicast traffic.
No
If you use ELRP as a standalone tool, hitless failover support is not needed
since the you initiate the loop detection.
No
If you use ELRP in conjunction with ESRP, ELRP does not interfere with the
hitless failover support provided by ESRP.
Although there is no hitless failover support in ELRP itself, ELRP does not
affect the network behavior if a failover occurs.
Link Layer Discovery
Protocol (LLDP)
No
Link Aggregation
Control Protocol (LACP)
If the backup MSM becomes the primary MSM, there is no traffic disruption.
Yes
77
Behavior
Hitless
Routing Information
Protocol (RIP)
RIP does not support graceful restart, so the route manager deletes all RIP
routes 1 second after the failover occurs. This results in a traffic interruption
as well as an increase in control traffic as RIP
re-establishes its database.
No
Routing Information
Protocol next
generation (RIPng)
RIPng does not support graceful restart, so the route manager deletes all
RIPng routes 1 second after the failover occurs. This results in a traffic
interruption.
No
In addition, after RIPng comes up on the new primary MSM, it relearns the
routes from its neighbors. This causes an increase in control traffic onto the
network.
Open Shortest Path
First (OSPF)
Yes
If you do not configure graceful restart, the route manager deletes all OSPF
routes 1 second after the failover occurs, which results in a traffic
interruption in addition to the increased control traffic.
Open Shortest Path
First v3 (OSPFv3)
OSPFv3 does not support graceful restart, so the route manager deletes all
OSPFv3 routes 1 second after the failover occurs. This results in a traffic
interruption.
No
In addition, after OSPFv3 comes up on the new primary MSM, it relearns the
routes from its neighbors. This causes an increase in control traffic onto the
network.
Border Gateway
Protocol (BGP)
If you configure BGP graceful restart, by default the route manager does not
delete BGP routes until 120 seconds after failover occurs. There is no traffic
interruption. However, after BGP comes up after restart, BGP re-establishes
sessions with its neighbors and relearns routes from all of them. This causes
an increase in control traffic onto the network.
Yes
If you do not configure graceful restart, the route manager deletes all BGP
routes 1 second after the failover occurs, which results in a traffic
interruption in addition to the increased control traffic.
Power over Ethernet
(PoE)
Yes
802.1x Authentication
Yes
MAC-Based Authentication
Yes
78
Behavior
Hitless
Network Login
Continued
Web-Based Authentication
Yes
Protocol
ExtremeWare
XOS Version
BlackDiamond 10K
11.4
EAPS
11.4
ESRP
11.0
LACP
11.4
Network login
11.3
11.3
STP
11.0
11.4
EAPS
11.4
ESRP
11.3
LACP
11.4
Network login
11.3
11.3
PoE
11.3
STP
11.3
11.4
EAPS
11.4
ESRP
11.4
LACP
11.4
Network login
11.4
11.4
STP
11.4
BlackDiamond 12804
79
A brief traffic interruption (less than 1/2 of a second) can occur when the failover happens due to
reprogramming of the I/O modules to bypass the original primary MSMs switch chips.
Caveats for the BlackDiamond 10K Switch and the BlackDiamond 8800 Family of
Switches Only
The following summary describes the hitless failover caveats for the BlackDiamond 10K switch and the
BlackDiamond 8800 family of switches only
MSM I/O ports on the original primary MSM are not available during the failover and this
MSM I/O subsection is power cycled. It takes about 2 minutes for these MSM I/O ports to be able to
pass traffic again.
I/O modules not yet in the Operational state are powered off and the card state machine is restarted
to bring them to the Operational state. This results in a delay in the I/O module becoming
Operational.
80
Monitors all installed PSUs, even installed PSUs that are disabled
Powers up or down I/O modules based on available power and required power resources
Logs power resource changes, including power budget, total available power, redundancy, and so on
The switch includes two power supply controllers that collect data from the installed PSUs and report
the results to the MSM modules. When you first power on the switch, the power supply controllers
enable a PSU. As part of the power management function, the power controller disables the PSU if an
unsafe condition arises. For more information about the power supply controller, see the Extreme
Networks Consolidated XOS Hardware Installation Guide.
If you have a BlackDiamond 8800 Power over Ethernet (PoE) G48P module installed in any of the
BlackDiamond 8800 family of switches, there are specific power budget requirements and
configurations associated with PoE that are not described in this section. For more detailed information
about PoE, see Chapter 8, Power Over EthernetBlackDiamond 8800 Family of Switches Only.
This section describes the following power management topics:
Collects information about the PSUs installed to determine how many are running and how much
power each can supply.
Calculates the number of I/O modules to power up based on the available power budget and the
power requirements of each I/O module, including PoE requirements for the BlackDiamond 8800
PoE I/O module.
Reserves the amount of power required to power up a second MSM if only one MSM is installed.
Reserves the amount of power required to power all fans and chassis components.
Logs and sends SNMP traps for transitions in the overall system power status, including whether
the available amount of power is:
81
Redundant or N+1Power from a single PSU can be lost and no I/O modules are powered
down.
Sufficient, but not redundantPower from a single PSU is lost, and one or more I/O modules are
powered down.
InsufficientOne or more modules are not powered up due to a shortfall of available power.
By reading the PSU information, ExtremeWare XOS determines the power status and the total amount
of power available to the system. The total power available determines which I/O modules can be
powered up.
Power Redundancy
In simple terms, power redundancy (N+1) protects the system from shutting down. With redundancy, if
the output of one PSU is lost for any reason, the system remains fully powered. In this scenario, N is the
minimum number of power supplies needed to keep the system fully powered and the system has N+1
PSUs powered.
If the system power status is not redundant, the removal of one PSU, the loss of power to one PSU, or a
degradation of input voltage results in insufficient power to keep all of the I/O modules powered up. If
there is not enough power, ExtremeWare XOS powers down the I/O modules from the highest
numbered slot to the lowest numbered slot until the switch has enough power to continue operation.
If you install or provide power to a new PSU, I/O modules powered down due to earlier insufficient
power are considered for power up from the lowest slot number to the highest slot number, based on
the I/O modules power requirements.
Whenever the system experiences a change in power redundancy, including a change in the total
available power, degraded input voltage, or a return to redundant power, the switch sends messages to
the syslog.
If you disable a slot, the I/O module installed in that slot is always powered down regardless of the
number of PSUs installed.
If a switch has PSUs with a mix of both 220V AC and 110V AC inputs, ExtremeWare XOS maximizes
system power by automatically taking one of two possible actions:
If all PSUs are enabled then all PSUs must be budgeted at 110V AC to prevent overload of PSUs
with 110V AC inputs.
OR
If the PSUs with 110V AC inputs are disabled, then the PSUs with 220V AC inputs can be
budgeted with a higher output per PSU.
ExtremeWare XOS computes the total available power using both methods and automatically uses
the PSU configuration that provides the greatest amount of power to the switch. Table 13 lists
combinations where ExtremeWare XOS maximizes system power by disabling the PSUs with 110V
AC inputs.
82
For all other combinations of 220V AC and 110V AC PSUs, ExtremeWare XOS maximizes system
power by enabling all PSUs and budgeting each PSU at 110V AC.
NOTE
If you are running ExtremeWare XOS 11.2 or 11.1 and mix PSUs with 110V and 220V AC inputs, the switch
budgets all PSUs as if they have 110V AC inputs.
NOTE
If you override automatic power supply management, you may reduce the available power and cause one or more I/O
modules to power down.
To resume using automatic power supply management on a PSU, use the configure power supply
<ps_num> auto command. The setting for each PSU is stored as part of the switch configuration.
To display power supply status and power budget information, use the show power and show power
budget commands.
83
On modular switches, the following commands provide additional power supply information.
To view the system power status and the amount of available and required power, use the following
command:
show power budget
To display the status of the currently installed power supply controllers, use the following command:
show power controller {<num>}
84
SNMPv3 on page 87
To prevent access using SNMPv1/v2c methods and allow access using SNMPv3 methods only, use the
following commands:
enable snmp access
disable snmp access {snmp-v1v2c}
The switch cannot be configured to simultaneously allow SNMPv1/v2c access and prevent SNMPv3
access.
Most of the commands that support SNMPv1/v2c use the keyword snmp; most of the commands that
support SNMPv3 use the keyword snmpv3.
After a switch reboot, all slots must be in the Operational state before SNMP can manage and access
the slots. To verify the current state of the slot, use the show slot command.
For more detailed information about safe defaults mode, see Safe Defaults Setup Method on page 49.
85
Supported MIBs
In addition to private MIBs, the switch supports the standard MIBs listed in Appendix D, Supported
Protocols, MIBs, and Standards.
Authorized trap receiversAn authorized trap receiver can be one or more network management
stations on your network. The switch sends SNMPv1/v2c traps to all configured trap receivers. You
can specify a community string and UDP port individually for each trap receiver. All community
strings must also be added to the switch using the configure snmp add community command.
To configure a trap receiver on a switch, use the following command:
configure snmp add trapreceiver <ip_address> community [[hex <hex_community_name>]
| <community_name>] {port <port_number>} {from <src_ip_address>} {mode <trap_mode>
[enhanced | standard]}
You can delete a trap receiver using the configure snmp delete trapreceiver command.
Entries in the trap receiver list can also be created, modified, and deleted using the RMON2
trapDestTable MIB table, as described in RFC 2021.
Community stringsThe community strings allow a simple method of authentication between the
switch and the remote network manager. There are two types of community strings on the switch:
Read community strings provide read-only access to the switch. The default read-only
community string is public.
Read-write community strings provide read- and-write access to the switch. The default readwrite community string is private.
System contact (optional)The system contact is a text field that enables you to enter the name of
the person(s) responsible for managing the switch.
System name (optional)The system name enables you to enter a name that you have assigned to
this switch. The default name is the model name of the switch (for example, BD-1.2).
System location (optional)Using the system location field, you can enter the location of the switch.
86
Login statistics
SNMPv3
SNMPv3 is an enhanced standard for SNMP that improves the security and privacy of SNMP access to
managed devices and provides sophisticated control of access to the device MIB. The prior standard
versions of SNMP, SNMPv1, and SNMPv2c, provided no privacy and little security.
The following six RFCs provide the foundation for the Extreme Networks implementation of SNMPv3:
RFC 2570, Introduction to version 3 of the Internet-standard Network Management Framework, provides an
overview of SNMPv3.
RFC 2571, An Architecture for Describing SNMP Management Frameworks, talks about SNMP
architecture, especially the architecture for security and administration.
RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP),
talks about the message processing models and dispatching that can be a part of an SNMP engine.
RFC 2573, SNMPv3 Applications, talks about the different types of applications that can be associated
with an SNMPv3 engine.
RFC 2574, The User-Based Security Model for Version 3 of the Simple Network Management Protocol
(SNMPv3), describes the User-Based Security Model (USM).
RFC 2575, View-based Access Control Model (VACM) for the Simple Network Management Protocol
(SNMP), talks about VACM as a way to access the MIB.
The SNMPv3 standards for network management were primarily driven by the need for greater security
and access control. The new standards use a modular design and model management information by
cleanly defining a message processing (MP) subsystem, a security subsystem, and an access control
subsystem.
The MP subsystem helps identify the MP model to be used when processing a received Protocol Data
Unit (PDU), which are the packets used by SNMP for communication. The MP layer helps in
implementing a multilingual agent, so that various versions of SNMP can coexist simultaneously in the
same network.
The security subsystem features the use of various authentication and privacy protocols with various
timeliness checking and engine clock synchronization schemes. SNMPv3 is designed to be secure
against:
Disclosure, where packet exchanges are sniffed (examined) and information is learned about the
contents
The access control subsystem provides the ability to configure whether access to a managed object in a
local MIB is allowed for a remote principal. The access control scheme allows you to define access
policies based on MIB views, groups, and multiple security levels.
87
NOTE
In SNMPv3, many objects can be identified by a human-readable string or by a string of hexadecimal octets. In
many commands, you can use either a character string, or a colon-separated string of hexadecimal octets to specify
objects. To indicate hexadecimal octets, use the keyword hex in the command.
Message Processing
A particular network manager may require messages that conform to a particular version of SNMP. The
choice of the SNMPv1, SNMPv2c, or SNMPv3 MP model can be configured for each network manager
as its target address is configured. The selection of the MP model is configured with the mp-model
keyword in the following command:
configure snmpv3 add target-params [[hex <hex_param_name>] | <param_name>] user [[hex
<hex_user_name>] | <user_name>] mp-model [snmpv1 | snmpv2c | snmpv3] sec-model [snmpv1
| snmpv2c | usm] {sec-level [noauth | authnopriv | priv]} {volatile}
SNMPv3 Security
In SNMPv3 the User-Based Security Model (USM) for SNMP was introduced. USM deals with security
related aspects like authentication, encryption of SNMP messages, and defining users and their various
access security levels. This standard also encompasses protection against message delay and message
replay.
88
A number of default, permanent users are initially available. The default user names are: admin, initial,
initialmd5, initialsha, initialmd5Priv, initialshaPriv. The default password for admin is password. For the
other default users, the default password is the user name.
To display information about a user, or all users, use the following command:
show snmpv3 user {[[hex <hex_user_name>] | <user_name>]}
NOTE
The SNMPv3 specifications describe the concept of a security name. In the ExtremeWare XOS implementation, the
user name and security name are identical. In this manual, both terms are used to refer to the same thing.
Groups. Groups are used to manage access for the MIB. You use groups to define the security model,
the security level, and the portion of the MIB that members of the group can read or write. To
underscore the access function of groups, groups are defined using the following command:
configure snmpv3 add access [[hex <hex_group_name>] | <group_name>] {sec-model [snmpv1
| snmpv2c | usm]} {sec-level [noauth | authnopriv | priv]} {read-view [[hex
<hex_read_view_name>] | <read_view_name>]} {write-view [[hex <hex_write_view_name>]] |
<write_view_name>]} {notify-view [[hex <hex_notify_view_name]] | <notify_view_name>]}
{volatile}
The security model and security level are discussed in Security Models and Levels on page 90. The
view names associated with a group define a subset of the MIB (subtree) that can be accessed by
members of the group. The read view defines the subtree that can be read, write view defines the
subtree that can be written to, and notify view defines the subtree that notifications can originate from.
MIB views are discussed in SNMPv3 MIB Access Control on page 91.
89
To show which users are associated with a group, use the following command:
show snmpv3 group {[[hex <hex_group_name>] | <group_name>] {user [[hex
<hex_user_name>] | <user_name>]}}
When you delete a group, you do not remove the association between the group and users of the group.
To delete the association between a user and a group, use the following command:
configure snmpv3 delete group {[[hex <hex_group_name>] | <group_name>]} user [all-nondefaults | {[[hex <hex_user_name>] | <user_name>] {sec-model [snmpv1|snmpv2c|usm]}}]
Security Models and Levels. For compatibility, SNMPv3 supports three security models:
SNMPv1no security
SNMPv3USM security
The default is USM. You can select the security model based on the network manager in your network.
The three security levels supported by USM are:
noAuthnoPrivNo authentication, no privacy. This is the case with existing SNMPv1/v2c agents.
AuthPrivAuthentication, privacy. This represents the highest level of security and requires every
message exchange to pass the authentication and encryption tests.
When a user is created, an authentication method is selected, and the authentication and privacy
passwords or keys are entered.
When MD5 authentication is specified, HMAC-MD5-96 is used to achieve authentication with a 16-octet
key, which generates an 128-bit authorization code. This authorization code is inserted in
msgAuthenticationParameters field of SNMPv3 PDUs when the security level is specified as either
AuthnoPriv or AuthPriv. Specifying SHA authentication uses the HMAC-SHA protocol with a 20-octet
key for authentication.
For privacy, a 16-octet key is provided as input to DES-CBS encryption protocol, which generates an
encrypted PDU to be transmitted. DES uses bytes 1-7 to make a 56 bit key. This key (encrypted itself) is
placed in msgPrivacyParameters of SNMPv3 PDUs when the security level is specified as AuthPriv.
90
The mask can also be expressed in hex notation (this is used for the ExtremeWare XOS CLI):
1.3.6.1.2.1.1/fe
To define a view that includes the entire MIB-2, use the following subtree/mask:
1.3.6.1.2.1.1/1.1.1.1.1.0.0.0
When you create the MIB view, you can choose to include the MIB subtree/mask or to exclude the MIB
subtree/mask. To create a MIB view, use the following command:
configure snmpv3 add mib-view [[hex <hex_view_name>] | <view_name>] subtree
<object_identifier> {/<subtree_mask>} {type [included | excluded]} {volatile}
After the view has been created, you can repeatedly use the configure snmpv3 add mib-view
command to include and/or exclude MIB subtree/mask combinations to precisely define the items you
want to control access to.
In addition to the user-created MIB views, there are three default views. These default views are of
storage type permanent and cannot be deleted, but they can be modified. The default views are:
defaultUserView, defaultAdminView, and defaultNotifyView. To show MIB views, use the following
command:
show snmpv3 mib-view {[[hex <hex_view_name>] | <view_name>] {subtree
<object_identifier>}}
91
SNMPv3 Notification
SNMPv3 can use either SNMPv1 traps or SNMPv2c notifications to send information from an agent to
the network manager. The terms trap and notification are used interchangeably in this context.
Notifications are messages sent from an agent to the network manager, typically in response to some
state change on the agent system. With SNMPv3, you can define precisely which traps you want sent, to
which receiver by defining filter profiles to use for the notification receivers.
To configure notifications, you configure a target address for the target that receives the notification, a
target parameters name, and a list of notification tags. The target parameters specify the security and
MP models to use for the notifications to the target. The target parameters name also points to the filter
profile used to filter the notifications. Finally, the notification tags are added to a notification table so
that any target addresses using that tag will receive notifications.
Target Addresses
A target address is similar to the earlier concept of a trap receiver. To configure a target address, use the
following command:
configure snmpv3 add target-addr [[hex <hex_addr_name] | <addr_name>] param [[hex
<hex_param_name] | <param_name>] ipaddress [[<ip_address> {<netmask>}] | <ip_address>]
{transport-port <port_number> {from <src_ip_address>} {tag-list <tag_list>} {volatile}
In configuring the target address you supply an address name that identifies the target address, a
parameters name that indicates the MP model and security for the messages sent to that target address,
and the IP address and port for the receiver. The parameters name also is used to indicate the filter
profile used for notifications. The target parameters is discussed in Target Parameters next.
The from option sets the source IP address in the notification packets.
The tag-list option allows you to associate a list of tags with the target address. The tag defaultNotify
is set by default. Tags are discussed in the section Notification Tags.
To display target addresses, use the following command:
show snmpv3 target-addr {[[hex <hex_addr_name>] | <addr_name>]}
To delete a single target address or all target addresses, use the following command:
configure snmpv3 delete target-addr [{[[hex <hex_addr_name>] | <addr_name>]} | all]
Target Parameters
Target parameters specify the MP model, security model, security level, and user name (security name)
used for messages sent to the target address. See Message Processing on page 88 and Users, Groups,
and Security on page 89 for more details on these topics. In addition, the target parameter name used
for a target address points to a filter profile used to filter notifications. When you specify a filter profile,
92
To display the options associated with a target parameters name or all target parameters names, use the
following command:
show snmpv3 target-params {[[hex <hex_target_params>] | <target_params>]}
To delete one or all the target parameters, use the following command:
configure snmpv3 delete target-params [{[[hex <hex_param_name>] | <param_name>]} |
all]
After the profile name has been created, you associate filters with it using the following command:
configure snmpv3 add filter [[hex <hex_profile_name>] | <profile_name>] subtree
<object_identifier> {/<subtree_mask>} type [included | excluded] {volatile}
The MIB subtree and mask are discussed in SNMPv3 MIB Access Control on page 91, as filters are
closely related to MIB views. You can add filters together, including and excluding different subtrees of
the MIB until your filter meets your needs.
To display the association between parameter names and filter profiles, use the following command:
show snmpv3 filter-profile {[[hex <hex_profile_name>] | <profile_name>]} {param [[hex
<hex_param_name>] | <param_name>]}
To display the filters that belong a filter profile, use the following command:
show snmpv3 filter {[[hex <hex_profile_name>] | <profile_name>] {{subtree}
<object_identifier>}
To delete a filter or all filters from a filter profile, use the following command:
configure snmpv3 delete filter [all | [[hex <hex_profile_name>] | <profile_name>]
{subtree <object_identifier>}]]
93
Notification Tags
When you create a target address, either you associate a list of notification tags with the target or by
default, the defaultNotify tag is associated with the target. When the system generates notifications, only
those targets associated with tags currently in the standard MIB table, called snmpNotifyTable, are
notified.
To add an entry to the table, use the following command:
configure snmpv3 add notify [[hex <hex_notify_name>] | <notify_name>] tag [[hex
<hex_tag>] | <tag>] {volatile}
Any targets associated with tags in the snmpNotifyTable are notified, based on the filter profile associated
with the target.
To display the notifications that are set, use the following command:
show snmpv3 notify {[[hex <hex_notify_name>] | <notify_name>]}
You cannot delete the default entry from the table, so any targets configured with the defaultNotify tag
will always receive notifications consistent with any filter profile specified.
Configuring Notifications
Because the target parameters name points to a number of objects used for notifications, configure the
target parameter name entry first. You can then configure the target address, filter profiles and filters,
and any necessary notification tags.
94
By default, Daylight Saving Time is assumed to begin on the first Sunday in April at 2:00 AM, and
end the last Sunday in October at 2:00 AM and to be offset from standard time by one hour. If this is
the case in your time zone, you can set up automatic daylight savings adjustment with the
command:
configure timezone <GMT_offset> autodst
If your time zone uses starting and ending dates and times that differ from the default, you can
specify the starting and ending date and time in terms of a floating day, as follows:
configure timezone name MET 60 autodst name MDT begins every last sunday march at
1 30 ends every last sunday october at 1 30
You can also specify a specific date and time, as shown in the following command:
configure timezone name NZST 720 autodst name NZDT 60 begins every first sunday
october at 2 00 ends on 3 16 2004 at 2 00
The optional time zone IDs are used to identify the time zone in display commands such as show
switch {detail}.
std-timezone-ID
Specifies an optional name for this timezone specification. May be up to six characters in
length. The default is an empty string.
autodst
dst-timezone-ID
Specifies an optional name for this Daylight Savings Time specification. May be up to six
characters in length. The default is an empty string.
dst_offset
Specifies an offset from standard time, in minutes. Value is in the range of 1 to 60.
Default is 60 minutes.
floating_day
Specifies the day, week, and month of the year to begin or end Daylight Savings Time
each year. Format is:
<week> <day> <month> where:
<week> is specified as [first | second | third | fourth | last]
<day> is specified as [sunday | monday | tuesday | wednesday | thursday | friday |
saturday]
<month> is specified as [january | february | march | april | may | june | july | august |
september | october | november | december]
Default for beginning is first sunday april; default for ending is last sunday october.
95
Specifies a specific day of a specific year on which to begin or end DST. Format is:
<month> <day> <year> where:
<month> is specified as 1-12
<day> is specified as 1-31
<year> is specified as 1970 - 2035
The year must be the same for the begin and end dates.
time_of_day_hour
Specifies the time of day to begin or end Daylight Savings Time. May be specified as an
hour (0-23). Default is 2.
time_of_day_minut
es
Specify the minute to begin or end Daylight Savings Time. May be specified as a minute
(0-59).
noautodst
Automatic Daylight Savings Time changes can be enabled or disabled. The default setting is enabled.
To disable automatic Daylight Savings Time, use the command:
configure timezone {name <std_timezone_ID>} <GMT_offset> noautodst
After SNTP has been enabled, the switch sends out a periodic query to the NTP servers defined in
step 4 (if configured) or listens to broadcast NTP updates from the network. The network time
information is automatically saved into the onboard real-time clock.
4 If you would like this switch to use a directed query to the NTP server, configure the switch to use
the NTP server(s). If the switch listens to NTP broadcasts, skip this step. To configure the switch to
use a directed query, use the following command:
configure sntp-client [primary | secondary] <host-name-or-ip> {vr <vr_name>}
NTP queries are first sent to the primary server. If the primary server does not respond within 1
second, or if it is not synchronized, the switch queries the secondary server (if one is configured). If
the switch cannot obtain the time, it restarts the query process. Otherwise, the switch waits for the
sntp-client update interval before querying again.
5 Optionally, the interval for which the SNTP client updates the real-time clock of the switch can be
changed using the following command:
configure sntp-client update-interval <update-interval>
show sntp-client
This command provides configuration and statistics associated with SNTP and its connectivity to
the NTP server.
This command indicates the GMT offset, the Daylight Savings Time configuration and status, and
the current local time.
96
GMT Offset
in Minutes
Cities
+0:00
+0
-60
-2:00
-120
AT - Azores
Azores
-3:00
-180
-4:00
-240
Caracas; La Paz
-5:00
-300
-6:00
-360
-7:00
-420
Saskatchewan, Canada
-8:00
-480
-9:00
-540
-10:00
-600
-660
NT - Nome
-12:00
-720
+1:00
+60
+120
+3:00
+180
+4:00
+240
+5:00
+300
+5:30
+330
+6:00
+360
+7:00
+420
+8:00
+480
+9:00
+540
97
GMT Offset
in Minutes
+10:00
+600
Cities
+660
+12:00
+720
SNTP Example
In this example, the switch queries a specific NTP server and a backup NTP server. The switch is
located in Cupertino, California, and an update occurs every 20 minutes. The commands to configure
the switch are as follows:
configure timezone -480 autodst
configure sntp-client update-interval 1200
enable sntp-client
configure sntp-client primary 10.0.1.1
configure sntp-client secondary 10.0.1.2
98
Like any advanced operating system, ExtremeWare XOS gives you the tools to manage your switch and
create your network configurations. With the introduction of ExtremeWare XOS, the following
enhancements and functionality have been added to the switch operating system:
Process control
Memory protection
CPU monitoring
File system administrationWith the enhanced file system, you can move, copy, and delete files from
the switch. The file system structure allows you to keep, save, rename, and maintain multiple copies of
configuration files on the switch. In addition, you can manage other entities of the switch such as
policies and access control lists (ACLs).
99
NOTE
Filenames are case-sensitive. For information on filename restrictions, refer to the specific command in the
ExtremeWare XOS Command Reference Guide.
You can also download configuration and policy files from the switch to a network Trivial File Transfer
Protocol (TFTP) server using TFTP. For detailed information about downloading switch configurations,
see Chapter A, Software Upgrade and Boot Options. For detailed information about downloading
policies and ACLs, see Chapter 13, Policy Manager.
With guidance from Extreme Networks Technical Support personnel, you can configure the switch to
capture core dump files, which contain debugging information that is useful in troubleshooting
situations. For more information about configuring core dump files and managing the core dump files
stored on your switch, see Appendix B, Troubleshooting.
This section describes the following file management topics:
100
old-name-internalSpecifies the current name of the core dump file located on the internal
memory card.
new-name-internalSpecifies the new name of the core dump file located on the internal memory
card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
old-name-memorycardSpecifies the current name of the file located on the external compact flash
memory card. Depending on your switch configuration, you can have configuration, policy, or core
dump files stored in this card. (This parameter is available only on modular switches.)
new-name-memorycardSpecifies the new name of the file located on the external compact flash
memory card. (This parameter is available only on modular switches.)
XML-formatted configuration files have a .cfg file extension. The switch only runs .cfg files. ASCIIformatted configuration files have a .xsf file extension. See ASCII-Formatted Configuration Files on
page 725 for more information. Policy files have a .pol file extension.
When you rename a file, make sure the renamed file uses the same file extension as the original file. If
you change the file extensions, the file may be unrecognized by the system. For example, if you have an
existing configuration file named test.cfg, the new filename must include the .cfg file extension.
When you rename a file on the switch, a message similar to the following appears:
Rename config test.cfg to config megtest.cfg on switch? (y/n)
Enter y to rename the file on your system. Enter n to cancel this process and keep the existing filename.
If you attempt to rename an active configuration file (the configuration currently selected the boot the
switch), the switch displays an error similar to the following:
Error: Cannot rename current selected active configuration.
For more information about configuring core dump files and managing the core dump files stored on
your switch, see Appendix B, Troubleshooting.
101
Examples
The following example renames the configuration file named Test.cfg to Final.cfg:
mv Test.cfg Final.cfg
On a modular switch, the following command moves the configuration file named test1.cfg from the
switch to the external memory card:
mv test1.cfg memorycard test1.cfg
old-name-internalSpecifies the name of the core dump file located on the internal memory card
new-name-internalSpecifies the name of the newly copied core dump file located on the internal
memory card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
old-name-memorycardSpecifies the name of the file located on the external compact flash memory
card that you want to copy. Depending on your switch configuration, you can have configuration,
policy, or core dump files stored in this card. (This parameter is available only on modular switches.)
102
new-name-memorycardSpecifies the name of the newly copied file located on the external compact
flash memory card. (This parameter is available only on modular switches.)
old-nameSpecifies the name of the configuration or policy file that you want to copy.
Enter y to copy the file. Enter n to cancel this process and not copy the file.
If you enter y, the switch copies the file with the new name and keeps a backup of the original file with
the original name. After the switch copies the file, use the ls command to display a complete list of
files.
For more information about configuring core dump files and managing the core dump files stored on
your switch, see Appendix B, Troubleshooting.
Example
The following example copies an existing configuration file named test.cfg and names the copied
configuration file test_rev2.cfg:
cp test.cfg test_rev2.cfg
On a modular switch, the following command makes a copy of a configuration file named primary.cfg
from the switch to the external memory card with the same name, primary.cfg:
cp primary.cfg memorycard
103
internal-memoryLists the core dump files that are present and saved in the internal memory card.
If the switch is not configured to save debug files or has not saved any debug files, no files are
displayed. For more information about configuring core dump files and managing the core dump
files stored on your switch, see Appendix B, Troubleshooting.
memorycardLists all files that are stored in the external compact flash memory card. (This
Example
The following command displays all of the configuration and policy files stored on your switch:
ls
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
50
94256
100980
35
100980
94256
Jul
Jul
Sep
Jun
Sep
Jun
30
23
23
29
23
30
14:19
14:26
09:16
06:42
09:17
17:10
hugh.pol
hughtest.cfg
megtest.cfg
newpolicy.pol
primary.cfg
roytest.cfg
On a modular switch, the following command displays all of the configuration and policy files stored
on the external memory card:
ls memorycard
1
1
1
1
1
root
root
root
root
root
0
0
0
0
0
15401865
10
10
10
223599
Mar
Mar
Apr
Mar
Mar
30
31
4
31
31
00:03
09:41
09:15
09:41
10:02
bd10K-11.2.0.13.xos
test-1.pol
test.pol
test_1.pol
v11_1_3.cfg
104
tftp get [<host-name> | <ip-address>] {-vr <vr_name>} [{[internal-memory <localfile-internal> | memorycard <local-file-memcard> | <local_file>} {<remote_file>} |
{<remote_file>} {[internal-memory <local-file-internal> | memorycard <local-filememcard> | <local_file>]}] {force-overwrite}
tftp put [<host-name> | <ip-address>] {-vr <vr_name>} [{[internal-memory <localfile-internal> | memorycard <local-file-memcard> | <local_file>} {<remote_file>} |
{<remote_file>} {[internal-memory <local-file-internal> | memorycard <local-filememcard> | <local_file>]}]
NOTE
The BlackDiamond 8800 family of switches and the Summit X450 switch do not support user-created VRs.
-gGets the specified file from the TFTP server and copies it to the local host. (This parameter is
available only on the tftp command.)
getGets the specified file from the TFTP server and copies it to the local host. (This is part of
the tftp get command.)
-pPuts the specified file from the local host and copies it to the TFTP server. (This parameter is
available only on the tftp command.)
putPuts the specified file from the local host and copies it to the TFTP server. (This is part of
the tftp put command.)
local-file-internalSpecifies the name of the core dump file located on the internal memory
card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
local-file-memcardSpecifies the name of the file on the external compact flash memory card.
(This parameter is available only on modular switches.)
local-fileSpecifies the name of the file (configuration file, policy file) on the local host.
NOTE
By default, if you transfer a file with a name that already exists on the system, the switch prompts you to
overwrite the existing file. For more information, see the tftp get command in the ExtremeWare XOS
Command Reference Guide.
For more information about TFTP, see Chapter 3, Managing the Switch. For detailed information
about downloading software image files, BootROM files, and switch configurations, see Appendix A,
Software Upgrade and Boot Options. For more information about configuring core dump files and
managing the core dump files stored on your switch, see Appendix B, Troubleshooting.
105
Example
The following example uses the tftp command to download the configuration file named XOS1.cfg
from the TFTP server:
tftp 10.123.45.67 -g -r XOS1.cfg
The following example uses the tftp get command to download the configuration file from the TFTP
server:
tftp get 10.123.45.67 XOS1.cfg
The following example uses the tftp put command to upload the configuration file from the switch to
the TFTP server:
tftp put 10.123.45.67 XOS1.cfg
NOTE
On a modular switch, you can transfer files to and from the switch and an installed external compact flash memory
card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
When you delete a configuration or policy file from the system, make sure you specify the appropriate
file extension. For example, if you want to delete a policy file, specify the filename and .pol. After you
delete a file, it is unavailable to the system.
When you delete a file from the switch, a message similar to the following appears:
Remove testpolicy.pol from switch? (y/n)
Enter y to remove the file from your system. Enter n to cancel the process and keep the file on your
system.
106
For more information about configuring core dump files and managing the core dump files stored on
your switch, see Appendix B, Troubleshooting.
Example
The following example removes the policy file named newpolicy.pol from the system:
rm newpolicy.pol
On a modular switch with an external memory card installed, the following command removes the
policy file named test.pol from the external memory card:
rm memorycard test.pol
Behavior
ExtremeWare XOS supports saving a configuration file into any named file and
supports more than two saved configurations.
For example, you can download a configuration file from a network TFTP
server and save that file as primary, secondary, or with a user-defined name.
You also select where to save the configuration: primary or secondary
partition, or another space.
The file names primary and secondary exist for backward compatibility with
ExtremeWare.
ExtremeWare XOS uses the tftp and tftp get commands to download
configuration files from the network TFTP server to the switch.
For more information about downloading configuration files, see Using TFTP
to Download the Configuration on page 729.
ExtremeWare XOS uses the tftp and tftp put commands to upload
configuration files from the switch to the network TFTP server.
For more information about uploading configuration files, see Using TFTP to
Upload the Configuration on page 727.
107
Behavior
ASCII-formatted configuration
file
Beginning with ExtremeWare XOS 11.4, you can upload your current
configuration in ASCII format to a network TFTP server. The uploaded ASCII
file retains the CLI format.
To view your configuration in ASCII format, save the configuration with the
.xsf file extension (known as the XOS CLI script file). This saves the XMLbased configuration in an ASCII format readable by a text editor.
ExtremeWare XOS uses the upload configuration command to upload
the ASCII-formatted configuration file from the switch to the network TFTP
server.
ExtremeWare XOS uses the tftp and tftp get commands to download
configuration files from the network TFTP server to the switch.
For more information about ASCII-formatted configuration files, see ASCIIFormatted Configuration Files on page 725.
Indicated by (xml) at the front of the switch prompt. Do not use. Use the
command disable xml-mode to disable this mode.
You can also see a complete list of configuration files by entering the ls
command followed by the Tab key.
For more information about saving, uploading, and downloading configuration files, see Saving
Configuration Changes on page 724.
108
detailSpecifies more detailed process information, including memory usage statistics, process ID
information, and process statistics.
descriptionDescribes the name of all of the processes or the specified process running on the
switch.
slotidSpecifies the slot number of the MSM. A specifies the MSM installed in slot A. B specifies
the MSM installed in slot B. (This parameter is available only on modular switches.)
The show process and show process slot <slotid> commands display the following information
in a tabular format:
CardThe name of the module where the process is running (modular switches only).
Version numberA series of numbers that identify the version number of the process. This is
helpful to ensure that you have version-compatible processes and if you experience a problem.
Not StartedThe process has not been started. This can be caused by not having the appropriate
license or for not starting the process.
RestartThe number of times the process has been restarted. This number increments by one each
time a process stops and restarts.
No LicenseThe process requires a license level that you do not have. For example, you have not
upgraded to that license, or the license is not available for your platform.
Day/Month/Date/Time/YearThe date and time the process began. If a process terminates and
restarts, the start time is also updated.
Not StartedThe process has not been started. This can be caused by not having the appropriate
license or for not starting the process.
If you specify the detail keyword, more specific and detailed process information is displayed. The
show process detail and show process slot <slotid> detail commands display the following
information in a multi-tabular format:
Recovery policies
Process statistics
Resource usage
Stopping a Process
If recommended by Extreme Networks Technical Support personnel, you can stop a running process. To
stop a running process, use the following command:
terminate process <name> [forceful | graceful] {msm <slot>}
109
forcefulSpecifies that the software quickly terminate a process. Unlike the graceful option, the
process is immediately shutdown without any of the normal process cleanup.
gracefulSpecifies that the process shutdown gracefully by closing all opened connections,
slotSpecifies the slot number of the MSM. A specifies the MSM installed in slot A. B specifies the
MSM installed in slot B. (This parameter is available only on modular switches.)
NOTE
Do not terminate a process that was installed since the last reboot unless you have saved your configuration. If you
have installed a software module and you terminate the newly installed process without saving your configuration,
your module may not be loaded when you attempt to restart the process with the start process command.
You can also use a single command to stop and restart a running process during a software upgrade on
the switch. By using the single command, there is less process disruption and it takes less time to stop
and restart the process. To stop and restart a process during a software upgrade, use the following
command:
restart process [class <cname> | <name> {msm <slot>}]
cnameSpecifies that the software terminates and restarts all instances of the process associated with
Starting a Process
To start a process, use the following command:
start process <name> {msm <slot>}
slotSpecifies the slot number of the MSM. A specifies the MSM installed in slot A. B specifies the
MSM installed in slot B. (This parameter is available only on modular switches.)
You are unable to start a process that is already running. If you try to start a currently running process,
for example telnetd, an error message similar to the following appears:
Error: Process
As described in the section, Stopping a Process on page 109, you can use a single command, rather
than multiple commands, to stop and restart a running process. To stop and restart a process during a
software upgrade, use the following command:
restart process [class <cname> | <name> {msm <slot>}]
For more detailed information, see the previous section or the ExtremeWare XOS Command Reference
Guide.omm
110
slotSpecifies the slot number of the MSM. A specifies the MSM installed in slot A. B specifies the
MSM installed in slot B. (This parameter is available only on modular switches.)
The show memory process command displays the following information in a tabular format:
The current memory statistics for the individual process also includes the following:
The module (MSM A or MSM B) and the slot number of the MSM (modular switches only)
You can also use the show memory {slot [a | b]} command to view the system memory and the
memory used by the individual processes, even for all processes on all MSMs installed in modular
switches. The slot parameter is available only on modular switches.
In general, the free memory count for an MSM or Summit X450 switch decreases when one or more
running processes experiences an increase in memory usage. If you have not made any system
configuration changes, and you observe a continued decrease in free memory, this might indicate a
memory leak.
The information from these commands may be useful for your technical support representative if you
experience a problem.
111
This command disables CPU monitoring on the switch; however, it does not clear the monitoring
interval. Therefore, if you altered the monitoring interval, this command does not return the monitoring
interval to 20 seconds. The next time you enable CPU monitoring, the switch uses the existing
configured interval.
secondsSpecifies the monitoring interval. The default interval is 20 seconds, and the range is 5 to
60 seconds. Extreme Networks recommends the default setting for most network environments. If
you enter a number lower than 20 seconds, CPU utilization may increase.
thresholdSpecifies the CPU threshold value. CPU usage is measured in percentages. The default
is 60%, and the range is 0% to 100%.
By default, CPU monitoring is enabled and occurs every 20 seconds. The default CPU threshold value is
60%.
slotSpecifies the slot number of the MSM. A specifies the MSM installed in slot A. B specifies the
MSM installed in slot B. (This parameter is available only on modular switches.)
112
CardThe location (MSM A or MSM B) where the process is running on a modular switch.
Range of time (5 seconds, 10 seconds, and so forth)The CPU utilization history of the process or
the system. The CPU utilization history goes back only 1 hour.
Total User/System CPU UsageThe amount of time recorded in seconds that the process spends
occupying CPU resources. The values are cumulative meaning that the values are displayed as long
as the system is running. You can use this information for debugging purposes to see where the
process spends the most amount of time: physical memory or virtual memory.
Process
5
10
30
1
5
30
1
Max
Total
secs secs secs min mins mins hour
User/System
util util util util util util util util
CPU Usage
(%) (%) (%) (%)
(%) (%) (%) (%)
(secs)
------------------------------------------------------------------------------MSM-A
MSM-B
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
MSM-A
...
System
System
GNSS_cpuif
GNSS_ctrlif
GNSS_esmi
GNSS_fabric
GNSS_mac_10g
GNSS_pbusmux
GNSS_pktengine
GNSS_pktif
GNSS_switch
aaa
acl
bgp
cfgmgr
cli
devmgr
dirser
dosprotect
eaps
edp
elrp
ems
epm
esrp
etmon
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.9
0.0
0.0
0.0
0.0
0.0
0.9
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.9
0.0
0.0
0.0
0.0
0.9
0.0
0.0
0.0
0.0
0.0
0.4
0.1
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.3
0.0
0.0
0.0
0.0
0.4
0.0
0.0
0.0
0.0
0.0
0.6
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
3.7
48.3
0.9
0.0
0.0
0.0
0.0
0.0
0.0
0.9
0.0
1.2
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.2
9.6
0.3
0.0
0.0
0.0
0.0
0.0
0.0
0.1
0.0
1.1
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.2
2.5
0.2
0.0
0.0
0.0
0.0
0.0
0.0
0.2
0.0
1.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.3
2.1
0.2
0.0
0.0
0.0
0.0
0.0
0.0
0.2
0.0
1.0
0.9
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
8.4
7.5
5.2
27.3
48.3
17.1
9.5
3.8
8.4
10.2
8.4
12.2
4.7
7.5
23.3
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.82
0.37
0.27
7.70
0.51
2.22
0.0
0.20
2.40
0.99
0.44
1.1
2.6
0.44
21.84
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.56
0.33
0.42
7.84
0.37
2.50
0.0
0.26
1.40
0.47
0.28
1.16
4.18
0.36
7.24
5
10
30
1
5
30
1
Max
Total
secs secs secs min mins mins hour
User/System
util util util util util util util util
CPU Usage
(%) (%) (%) (%)
(%) (%) (%) (%)
(secs)
----------------------------------------------------------------------System
aaa
acl
bgp
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
0.0
0.0
0.0
0.0
0.9
0.0
0.0
0.0
0.1
0.0
0.0
0.0
0.2
0.0
0.0
0.0
0.5
0.0
0.0
0.0
34.6
1.8 1.72
0.0 0.40
12.6 11.18
0.78
0.24
2.21
113
114
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.8
0.0
0.0
0.0
0.0
0.1
0.0
0.0
0.0
0.0
0.0
0.5
39.8
0.0
19.5
0.0
0.0
5.5
11.1
0.0
0.0
30.7
2.7
30.5
4743.92
0.59
74.44
0.0
0.8
36.40
10.92
0.49
1.19
48.74
0.82
4865.78
3575.79
0.42
24.52
0.0
0.12
15.41
3.97
0.44
1.29
32.93
0.45
873.87
Configuring Automatic Failover for Combination PortsSummit X450 Switch Only on page 150
This section describes configuring slots on a modular switch, which are the BlackDiamond 10K switch,
the BlackDiamond 12804 switch, and the BlackDiamond 8800 family of switches. This section describes
the following topics:
Overview
If a slot has not been configured for a particular type of module, then any type of module is accepted in
that slot, and a default port and VLAN configuration is automatically generated.
After any port on the module has been configured (for example, a VLAN association, a VLAN tag
configuration, or port parameters), all the port information and the module type for that slot must be
saved to non-volatile storage. Otherwise, if the modular switch is rebooted or the module is removed
from the slot, the port, VLAN, and module configuration information is not saved.
115
NOTE
For information on saving the configuration, see Appendix A.
You configure the modular switch with the type of input/output (I/O) module that is installed in each
slot. To do this, use the following command:
configure slot <slot> module <module_type>
You can also preconfigure the slot before inserting the module. This allows you to begin configuring the
module and ports before installing the module in the chassis.
If a slot is configured for one type of module, and a different type of module is inserted, the inserted
module is put into a mismatch state and is not brought online. To use the new module type in a slot,
the slot configuration must be cleared or configured for the new module type. To clear the slot of a
previously assigned module type, use the following command:
clear slot <slot>
All configuration information related to the slot and the ports on the module is erased. If a module is
present when you issue this command, the module is reset to default settings.
To display information about a particular slot, use the following command:
show slot
Port information
On the BlackDiamond 8810 switch (formerly known as Aspen), the MSM module also has eight 1 Gbps
fiber SFP GBIC data, or I/O, ports. You configure these ports exactly as you do any other ports on the
switch.
116
Configuring a Slot on a Modular SwitchBlackDiamond 10K Switch, BlackDiamond 12804 Switch, and BlackDiamond
Additionally, one slot on the BlackDiamond 8810 switch is dedicated to MSM useslot A, or slot 5. Slot
B, or slot 6, is a dual-purpose slot; it can be used for a secondary MSM or for a module consisting solely
of data, or I/O, ports.
The primary MSM must be in slot A in the BlackDiamond 8810 switch, which is referred to as slot 5
when working with the data ports. If you have a secondary MSM, that one goes into slot B, which is
slot 6 when you work with the data ports. So, when you work with the data ports on the MSM, you
specify slot 5 if you have one MSM, and slot 5 or 6 if you have two MSMs in the switch.
When you issue any slot commands specifying a slot that contains an MSM (slot 5 with one MSM and
slots 5 and 6 with two MSMs) on the BlackDiamond 8810 switch, those commands affect only the data
ports on that slot; the MSMs remain unaffected. When you issue most msm commands on this switch,
those commands affect only the MSM host CPU subsystem; the I/O ports remain unaffected. The sole
exception is that the reboot msm command reboots both the MSM and the I/O ports on that module.
If you are working on a switch with dual MSMs and the system fails over to the backup MSM from the
primary MSM, the I/O ports on the original primary MSM are not available during the failover period.
It takes about 2 minutes for the I/O ports on the original MSM to be able to pass traffic again.
On the BlackDiamond 8806 switch, the MSM module also has eight 1 Gbps fiber SFP GBIC data, or I/O,
ports. You configure these ports exactly as you do any other ports on the switch.
Additionally, one slot on the BlackDiamond 8806 switch is dedicated to MSM useslot A, or slot 3. Slot
B, or slot 4, is a dual-purpose slot; it can be used for a secondary MSM or for a module consisting solely
of data, or I/O, ports.
The primary MSM must be in slot A in the BlackDiamond 8806 switch, which is referred to as slot 3
when working with the data ports. If you have a secondary MSM, that one goes into slot B, which is
slot 4 when you work with the data ports. So, when you work with the data ports on the MSM, you
specify slot 3 if you have one MSM, and slot 3 or 4 if you have two MSMs in the switch.
When you issue any slot commands specifying a slot that contains an MSM (slot 3 with one MSM and
slots 3 and 4 with two MSMs) on the BlackDiamond 8806 switch, those commands affect only the data
ports on that slot; the MSMs remain unaffected. When you issue most msm commands on this switch,
those commands affect only the MSM host CPU subsystem; the I/O ports remain unaffected. The sole
exception is that the reboot msm command reboots both the MSM and the I/O ports on that module.
If you are working on a switch with dual MSMs and the system fails over to the backup MSM from the
primary MSM, the I/O ports on the original primary MSM are not available during the failover period.
It takes about 2 minutes for the I/O ports on the original MSM to be able to pass traffic again.
117
Port Numbering
ExtremeWare XOS runs on both stand-alone and modular switches, and the port numbering scheme is
slightly different on each. This section describes the following topics:
Separate the port numbers by a dash to enter a range of contiguous numbers, and separate the numbers
by a comma to enter a range of noncontiguous numbers:
switch
For example, if an I/O module that has a total of four ports is installed in slot 2 of the chassis, the
following ports are valid:
118
2:1
2:2
2:3
2:4
slota:x-slotb:ySpecifies a contiguous series of ports that begin on one I/O module and end on
another I/O module
For example, to disable slot 7, ports 3, 5, and 12 through 15 on a modular switch, use the following
command:
disable port 7:3,7:5,7:12-7:15
Refer to Displaying Port Configuration Information for information on displaying link status.
10 Gbps ports
1 Gbps small form factor (SFP) gigabit Ethernet interface converter (GBIC) fiber ports
100/1000 FX/LX SFP GBIC portsonly on the Black Diamond 8800 family of switches, the
BlackDiamond 12804 switch, and the Summit X450 switch
Autonegotiation determines the port speed and duplex setting for each port (except 10 Gbps ports). You
can manually configure the duplex setting and the speed of 10/100/1000 Mbps ports.
The 10/100/1000 Mbps ports can connect to either 10BASE-T, 100BASE-T, or 1000BASE-T networks. By
default, the ports autonegotiate port speed. You can also configure each port for a particular speed
(either 10 Mbps or 100 Mbps).
NOTE
With autonegotiation turned off, you cannot set the speed to 1000 Mbps.
119
NOTE
The 10 Gbps ports on the BlackDiamond 8800 family of switches and the Summit X450 switch do not initiate
pause frames; these ports do respond to receiving pause frames.
Beginning with ExtremeWare XOS 11.1, the 10 Gbps ports support the Link Fault Signal (LFS) function.
This function, which is always enabled, monitors the 10 Gbps ports and indicates either a remote fault
or a local fault. The system then stops transmitting or receiving traffic from that link. After the fault has
been alleviated, the system puts the link back up and the traffic automatically resumes.
The Extreme Networks implementation of LFS conforms to the IEEE standard 802.3ae-2002.
NOTE
On the BlackDiamond 10K switch, the 10 Gbps module must have the serial number 804405-00-09 or higher to
support LFS. To display the serial number of the module, use the show slot <slot_number> command. (All the
modules on the BlackDiamond 8800 family of switches support LFS.)
Although the physical link remains up, all Layer 2 and above traffic stops. The system sends LinkDown
and LinkUp traps when these events occur. Additionally, the system writes one or more information
messages to the syslog, as shown in the following example:
09/09/2004 14:59:08.03 <Info:vlan.dbg.info> MSM-A: Port 4:3 link up at
10 Gbps speed and full-duplex
09/09/2004 14:59:08.02 <Info:hal.sys.info> MSM-A: 4:3 - remote fault
recovered.
09/09/2004 14:59:05.56 <Info:vlan.dbg.info> MSM-A: Port 4:3 link down
due to remote fault
09/09/2004 14:59:05.56 <Info:hal.sys.info> MSM-A: 4:3 - remote fault.
120
NOTE
A link down or up event may trigger Spanning Tree Protocol topology changes or transitions.
The 10 Gbps ports do not autonegotiate; they always run at full duplex and 10 Gbps speed.
Table 17 lists the support for autonegotiation, speed, and duplex setting for the various types of ports.
Autonegotiation
Speed
Duplex
10 Gbps
Off
10000 Mbps
Full duplex
10/100/1000 Mbps
On (default)
10 Mbps
100 Mbps
Full/half duplex
Full/half duplex
Off
1000 Mbps
Full duplex
On (default)
100 Mbps
Off
1000 Mbps
Off
1 Gbps fiber SFP GBIC
100/1000 Mbps FX/LX
SFP GBIC
On (default)
Full duplex
121
Under certain conditions, you might opt to turn autopolarity off on one or more ports. The following
example turns autopolarity off for ports 5 to 7 on a Summit X450 switch:
configure ports 5-7 auto-polarity off
When autopolarity is disabled on one or more Ethernet ports, you can verify that status by using the
command:
show ports information detail
Jumbo Frames
Jumbo frames are Ethernet frames that are larger than 1522 bytes, including four bytes used for the cyclic
redundancy check (CRC). Extreme products support switching and routing of jumbo frames at wirespeed on all ports. The configuration for jumbo frames is saved across reboots of the switch.
Jumbo frames are used between endstations that support larger frame sizes for more efficient transfers
of bulk data. Both endstations involved in the transfer must be capable of supporting jumbo frames.
The switch only performs IP fragmentation, or participates in maximum transmission unit (MTU)
negotiation on behalf of devices that support jumbo frames.
You need jumbo frames when running the Extreme Networks VMAN implementation. When you are
working on the BlackDiamond 10K and 12804 switches, the switch enables jumbo frames when you
configure VMANs. If you are working on the BlackDiamond 8800 family of switches and the Summit
X450 switch, you enable jumbo frames for the entire switch before configuring VMANs. For more
information on configuring VMANs, refer to Chapter 10.
Refer to Displaying Port Configuration Information for information on displaying jumbo frame status.
122
Jumbo Frames
The BlackDiamond 8800 family of switches and the Summit X450 switch support jumbo frames on
the entire switch; you cannot enable or disable jumbo frames per port.
The BlackDiamond 8800 family of switches and the Summit X450 switch enable or disable jumbo
frames on the entire switch; jumbo frames are either enabled or disabled on every port on the
switch. The system returns an error message if you attempt to enter specified ports.
To enable jumbo frame support on the BlackDiamond 8800 family of switches or the Summit X450
switch, use the following command:
enable jumbo-frame ports all
After you issue this command, any new modules you add to the switch will also have jumbo frames
enabled.
When you configure VMANs on the BlackDiamond 8800 family of switches and the Summit X450
switch, you must enable jumbo frames for the entire switches before configuring the VMANs.
To enable jumbo frame support, enable jumbo frames on the desired ports. To set the maximum jumbo
frame size, use the following command:
configure jumbo-frame-size <framesize>
The jumbo frame size range is 1523 to 9216. This value describes the maximum size of the frame in
transit (on the wire), and includes 4 bytes of CRC plus another 4 bytes if 802.1Q tagging is being used.
Set the MTU size for the VLAN by using the following command:
configure ip-mtu <mtu> vlan <vlan_name>
Next, enable support on the physical ports that will carry jumbo frames using the following command:
enable jumbo-frame ports [all | <port_list>]
NOTE
The BlackDiamond 8800 family of switches and the Summit X450 switch enable or disable jumbo frames on the
entire switch; the system returns an error message if you attempt to enable jumbo frames on specified ports.
123
Using path MTU discovery, a source host assumes that the path MTU is the MTU of the first hop
(which is known). The host sends all datagrams on that path with the dont fragment (DF) bit set,
which restricts fragmentation. If any of the datagrams must be fragmented by an Extreme switch along
the path, the Extreme switch discards the datagrams and returns an ICMP Destination Unreachable
message to the sending host, with a code meaning fragmentation needed and DF set. When the
source host receives the message (sometimes called a Datagram Too Big message), the source host
reduces its assumed path MTU and retransmits the datagrams.
The path MTU discovery process ends when one of the following is true:
The source host sets the path MTU low enough that its datagrams can be delivered without
fragmentation.
The source host does not set the DF bit in the datagram headers.
If it is willing to have datagrams fragmented, a source host can choose not to set the DF bit in datagram
headers. Normally, the host continues to set DF in all datagrams, so that if the route changes and the
new path MTU is lower, the host can perform path MTU discovery again.
ExtremeWare XOS supports the fragmenting of IP packets. If an IP packet originates in a local network
that allows large packets and those packets traverse a network that limits packets to a smaller size, the
packets are fragmented instead of discarded.
This feature is designed to be used in conjunction with jumbo frames. Frames that are fragmented are
not processed at wire-speed within the switch fabric.
NOTE
Jumbo frame-to-jumbo frame fragmentation is not supported. Only jumbo frame-to-normal frame fragmentation is
supported.
124
The ip-mtu value ranges between 1500 and 9216, with 1500 the default.
NOTE
To set the MTU size greater than 1500, all ports in the VLAN must have jumbo frames enabled.
125
Load sharing allows the switch to use multiple ports as a single logical port, or LAG. For example,
VLANs see the LAG as a single logical port. And, although you can only reference the master port of a
LAG to a Spanning Tree Domain (STPD), all the ports of the LAG actually belong to the specified STPD.
Most load-sharing algorithms guarantee packet sequencing between clients.
Link aggregation, or load sharing, is disabled by default.
If a port in a load-sharing group (or LAG) fails, traffic is redistributed to the remaining ports in the
LAG. If the failed port becomes active again, traffic is redistributed to include that port.
NOTE
Load sharing must be enabled on both ends of the link, or a network loop may result.
In both situations, the aggregation of separate physical links into a single logical link multiplies total
link bandwidth in addition to providing resiliency against individual link failures.
In modular switches, ExtremeWare XOS supports LAGs across multiple modules, so resiliency is also
provided against individual module failures.
The software supports control protocols across the LAGs, both static and dynamic. If you add the
protocols (for example, EAPS, ESRP, and so forth) to the port and then create a LAG on that port, you
may experience a slight interruption in the protocol operation. To seamlessly add or delete bandwidth
when running control protocols, Extreme Networks recommends that you create a LAG consisting of
only one port. Then add your protocols to that port and add other ports as needed.
VMAN ports can belong to LAGs. If any port in the LAG is enabled for VMAN, all ports in the group
are automatically enabled to handle jumbo size frames on the BlackDiamond 10K switch; you must
enable jumbo frames on the BlackDiamond 8800 family of switches and the Summit X450 switch. Also,
VMAN is automatically enabled on all ports of the untagged LAG.
126
NOTE
Beginning with ExtremeWare XOS 11.4, you can use VMAN ACLs to configure load sharing on a VMAN. See
Chapter 14 for complete information on VMAN ACLs.
You can run the Link Layer Discovery Protocol (LLDP) on ports in a LAG.
Only the master logical port can be a either a primary or redundant port.
You must unconfigure the software-controlled redundant ports before either configuring or
unconfiguring load sharing.
The entire LAG must go down before the software-controlled redundant port takes effect.
Dynamic load sharingDynamic load sharing is a grouping of ports that use the Link Aggregation
Control Protocol (LACP) to dynamically determine if link aggregation is possible and then to
automatically configure the aggregation. LACP is part of the IEEE 802.3ad standard and allows the
switch to dynamically reconfigure the link aggregation groups (LAGs). The LAG is enabled only
when LACP detects that the remote device is also using LACP and is able to join the LAG.
Static load sharingStatic load sharing is a grouping of ports specifically configured to load share.
The switch ports at each end must be specifically configured as part of a load-sharing group.
NOTE
The platform-related load-sharing algorithms apply to LACP (as well as static load sharing).
Load-Sharing Algorithms
With ExtremeWare XOS version 11.2, you can use IPv6 addresses in the load-sharing algorithms.
Load-sharing, or link aggregation, algorithms allow you to select the distribution technique used by the
LAG to determine the output port selection. Algorithm selection is not intended for use in predictive
traffic engineering.
The ExtremeWare XOS software supports static load sharing, which is a grouping of ports specifically
configured to load share. Beginning with ExtremeWare XOS version 11.3, the software also supports
dynamic load sharing. (See LACPDynamic Link Aggregation on page 129 for complete information
on LACP.) The switch ports at each end must be configured as part of a load-sharing group.
Additionally, you can choose the load-sharing algorithm used by the group.
127
NOTE
Always reference the master logical port of the load-sharing group when configuring or viewing VLANs. VLANs
configured to use other ports in the LAG will have those ports deleted from the VLAN when link aggregation is
enabled.
Link Aggregation Algorithm on the BlackDiamond 8800 Family of Switches and the
Summit X450 Switch
NOTE
You cannot configure port-based load sharing on the BlackDiamond 8800 family of switches or the Summit X450
switch.
Address-based load sharing. When you configure address-based load sharing, the switch examines a
specific place in the packet to determine which egress port to use for forwarding traffic:
For Layer 2 load sharing, the switch uses the MAC source address and destination address.
For Layer 3 load sharing, the switch uses the IP source address and destination address.
You control the field examined by the switch for address-based load sharing when the load-sharing
group is created by using the following command:
enable sharing {<master_port>} grouping <port_list> {algorithm address-based [L2 |
L3]}
If the packet is not IP, the switch applies the Layer 2 algorithm, which is the default setting.
Port-basedUses the ingress port to determine which physical port in the load-sharing group is
used to forward traffic out of the switch.
IP packetsUses the source and destination MAC and IP addresses and the TCP port number.
If you do not explicitly select an algorithm, the port-based scheme is used. However, the address-based
algorithm has a more even distribution and is the recommended choice.
128
For Layer 2 load sharing, the switch uses the MAC source address and destination address.
For Layer 3 load sharing, the switch uses the IP source address and destination address.
For Layer 4 load sharing, the switch using the TCP source and destination port number.
You can control the field examined by the switch for address-based load sharing by using the following
command:
configure sharing address-based [L2 | L2_L3 | L2_L3_L4 | L2_L3_CHK_SUM |
L2_L3_L4_CHK_SUM]
Where CHK SUM indicates that the switch should examine the IP check sum. Examining the IP check
sum in addition to the other parameters produces a random traffic pattern on the egress of the loadsharing links because the IP check sum includes the packet length, which is likely to change from
packet to packet.
NOTE
Those variables with CHK_SUM apply only to IPv4 packets.
This feature is available only for the address-based load-sharing algorithm. The selected address-based
algorithm is applied to the entire switch, to all the load-sharing groups configured as address-based.
Layer 2 is the default setting.
The master port of the load-sharing group can be the monitor port for port-mirroring.
Beginning with ExtremeWare XOS version 11.3, you can run the Link Aggregation Control Protocol
(LACP) on Extreme Networks devices. LACP enables dynamic load sharing and hot standby for link
aggregation links, in accordance with the IEEE 802.3ad standard. All third-party devices supporting
LACP run with Extreme Networks devices.
The addition of LACP provides the following enhancements to static load sharing, or link aggregation:
Automatic configuration
Deterministic behavior
After you enable load-sharing, the LACP protocol is enabled by default. You configure dynamic link
aggregation by first assigning a primary, or logical, port to the group, or LAG and then specifying the
other ports you want in the LAG.
129
130
NOTE
Always verify the LACP configuration by issuing the show ports sharing command; look for the ports specified
as being in the aggregator. You can also display the aggregator count by issuing the show lacp lag command.
Beginning with ExtremeWare XOS 11.4, you can configure additional parameters for the LACP protocol
and the system sends certain SNMP traps in conjunction with LACP. The system sends a trap when a
member port is added to or deleted from an aggregator.
The system now detects and blocks loopbacks; that is, the system does not allow a pair of ports that are
in the same LAG but are connected to one another by the same link to select the same aggregator. If a
loopback condition exists between two ports, they cannot aggregate. Ports with the same MAC address
and the same admin key cannot aggregate; ports with the same MAC address and a different admin key
can belong to the same LAG.
The system sends an error message if a LAG port is configured and up but still not attached to the
aggregator or in operation within 60 seconds. Use the show lacp member-port <port> detail
command to display the churn on both sides of the link. If the Churn value is shown as True in the
display, check your LACP configuration. The issue may be either on your end or on the partner link,
but you should check your configuration. The display shows as True until the aggregator forms, when it
changes to display as False.
A LAG port moves to expired and then to the defaulted state when it fails to receive an LACPDU from
its partner for a specified time. You can configure this timeout value as long, which is 90 seconds, or
short, which is 3 seconds; the default is long. (In ExtremeWare XOS version 11.3, the timeout value is
not configurable and is set as long, or 90 seconds.) Use the show lacp lag <group-id> detail
command to display the timeout value for the LAG.
There are two LACP activity modes: active and passive. In LACP active mode, the switch periodically
sends LACPDUs; in passive mode, the switch sends LACPDUs only when it receives one from the other
end of the link. The default is active mode. (In ExtremeWare XOS version 11.3, the mode is not
configurable; it is always active mode.) Use the show lacp lag <group-id> detail command to
display the LACP mode for the LAG.
NOTE
One side of the link must be in active mode in order to pass traffic. If you configure your side in the passive mode,
ensure that the partner link is in LACP active mode.
A LAG port moves into a defaulted state after the timeout value expires with no LACPDUs received for
the other side of the link. You can configure whether you want this defaulted LAG port removed from
the aggregator or added back into the aggregator. If you configure the LAG to remove ports that move
into the default state, those ports are removed from the aggregator and the port state is set to
unselected. The default configuration for defaulted ports is to be removed, or deleted, from the
aggregator. (In ExtremeWare XOS version 11.3, defaulted ports in the LAG are always removed from the
aggregator; this is not configurable.)
NOTE
To force the LACP trunk to behave like a static sharing trunk, use the configure sharing lacp defaulted-state-action
command to add ports to the aggregator.
131
NOTE
If the defaulted port is assigned to standby, that port automatically has a lower priority than any other port in the
LAG (including those already in standby).
Configuring Load Sharing on the BlackDiamond 8800 Family of Switches and the
Summit X450 Switch
The following rules apply to load sharing on the BlackDiamond 8800 family of switches and the
Summit X450 switch:
132
Any broadcast, multicast, or unknown unicast packet is transmitted on a single port of a LAG.
NOTE
See Configuring LACP on page 133 for the maximum number of links, selected and standby, per LACP.
Configuring Load Sharing on the BlackDiamond 10K Series and 12804 Switches
The following rules apply to load sharing on the BlackDiamond 10K series and 12804 switches:
See Configuring LACP on page 133 for the maximum number of links, selected and standby, per LACP.
A LAG that spans multiple modules must use ports that have the same maximum bandwidth
capability, with one exceptionyou can mix media type on 1 Gbps ports.
Configuring LACP
NOTE
Extreme Networks does not recommend enabling LACP and ELSM on the same port. See Chapter 9 for information
on ELSM.
To configure LACP, or dynamic link aggregation, you must, again, first create a LAG. The first port in
the LAG serves as the logical port for the LAG. This is the reference port used in configuration
commands. It can be thought of as the logical port representing the entire port group, and it serves as
the LAG Group ID.
To create a LAG for LACP:
1 Create a LAG, using the following command:
enable sharing <port> grouping <port_list> {algorithm [port-based | address-based
{L2|L3}]} {lacp}
The port you assign using the first parameter becomes the logical port for the link aggregation group
and the LAG Group ID when using LACP. This logical port must also be included in the port list of
the grouping itself.
133
This step is optional; LACP handles prioritization using system MAC addresses.
3 Add or delete ports to the LAG as desired, using the following command:
configure sharing <port> add ports <port_list>
4 If you want to override the ports selection for joining the LAG by configuring a priority for a port
within a LAG, issue the following command:
configure lacp member-port <port> priority <port_priority>
5 If you want to change the expiry timer, use the following command:
configure sharing <port> lacp timeout [long | short]
The default value for defaulted LAG ports is delete the default ports.
NOTE
Always verify the LACP configuration by issuing the show ports sharing command; look for the ports listed as
being in the aggregator.
Configuring LACP on BlackDiamond 8800 Family of Switches and Summit X450 Switch. The following rules
apply to the number of LACP ports in one LAG on the BlackDiamond 8800 family of switches and on
the Summit X450 switch:
Configuring LACP on BLackDiamond 10K Series and 12804 Switches. The following rules apply to the
number of LACP ports in one LAG on the BlackDiamond 10K series and 12804 switches:
Load-Sharing Examples
This section provides examples of how to define load sharing, or link aggregation, on stand-alone and
modular switches, as well has defining dynamic link aggregation.
134
In this example, logical port 5:7 represents physical ports 3:9 through 3:12 and 5:7 through 5:10.
When using load sharing, you should always reference the LAG Group ID of the load-sharing group
(port 3:9 in the previous example) when configuring or viewing VLANs. VLANs configured to use
other ports in the load-sharing group will have those ports deleted from the VLAN when load sharing
becomes enabled.
Address-based load sharing can also span modules.
In this example, logical port 3:9 represents physical ports 3:9 through 3:12.
LACP Example
The following configuration example:
Creates a dynamic LAG with the logical port (LAG Group ID) of 10 that contains ports 10 through
12.
135
The following is an example of the display you see when you display load sharing, or link aggregation,
on the Summit X450 switch:
Load Sharing Monitor
Config
Current
Agg
Ld Share
Ld Share Agg
Link
Link Up
Master
Master
Control
Algorithm
Group
Mbr
Status transitions
==============================================================================
5
5
LACP
L2
5
Y
A
3
L2
6
Y
A
3
L2
7
Y
A
3
L2
8
Y
A
3
L2
9
A
3
L2
10
A
3
12
Static
L2
12
R
0
L2
13
R
0
===========================================================================
Link Status: A-Active, D-Disabled, R-Ready, NP-Port not present
Load Sharing Algorithm: (L2) Layer 2 address based, (L3) Layer 3 address based
Default algorithm: L2
Number of load sharing trunks: 2
NOTE
The Agg Mbr column displays which ports in the LACP LAG are added to the aggregator at the hardware level. Only
those ports that are added to the aggregator actually send and receive traffic. The Y means the port is added to the
aggregator.
The following is sample output from this command on the modular switch:
LACP Up
LACP Enabled
System MAC
LACP PDUs dropped on non-LACP ports
:
:
:
:
Yes
Yes
00:04:96:10:33:60
0
Lag
Actor
Actor
Partner
Partner Partner Agg
Sys-Pri Key
MAC
Sys-Pri Key
Count
-------------------------------------------------------------------------------2:1
90
0x07d1 00:01:30:f9:9c:30
601
0x1391
2
4:5
100
0x0fa5 00:01:30:f9:9c:30
321
0x1f47
16
4:9
677
0x0fa9 00:01:30:f9:9c:30
87
0x0fa9
8
136
The following is sample output you see when you display the LACP information for this command on a
modular switch:
Lag
Actor
Actor
Partner
Partner Partner Agg
Sys-Pri Key
MAC
Sys-Pri Key
Count
-------------------------------------------------------------------------------4:9
2110
0x0fa9 00:04:96:10:33:60
2110
0x0fa9
16
Port list:
Member
Port
Rx
Sel
Mux
Actor
Partner
Port
Priority State
Logic
State
Flags
Port
-------------------------------------------------------------------------------4:9
300
Current
Selected
Collect-Dist
A-GSCD-- 4009
4:10
301
Current
Selected
Collect-Dist
A-GSCD-- 4010
4:11
302
Current
Standby
Detached
A-G----- 4011
4:12
303
Current
Standby
Detached
A-G----- 4012
4:29
200
Current
Selected
Collect-Dist
A-GSCD-- 4029
4:30
0
Current
Selected
Collect-Dist
A-GSCD-- 4030
4:31
202
Current
Selected
Collect-Dist
A-GSCD-- 4031
4:32
203
Current
Selected
Collect-Dist
A-GSCD-- 4032
8:7
101
Current
Selected
Collect-Dist
A-GSCD-- 8013
8:8
10
Current
Selected
Collect-Dist
A-GSCD-- 8014
8:9
9
Current
Selected
Collect-Dist
A-GSCD-- 8015
8:10
8
Current
Selected
Collect-Dist
A-GSCD-- 8016
8:11
7
Current
Selected
Collect-Dist
A-GSCD-- 8017
8:12
6
Current
Selected
Collect-Dist
A-GSCD-- 8018
8:13
5
Current
Selected
Collect-Dist
A-GSCD-- 8019
8:14
3
Current
Selected
Collect-Dist
A-GSCD-- 8020
8:15
0
Current
Selected
Collect-Dist
A-GSCD-- 8043
8:16
3
Current
Selected
Collect-Dist
A-GSCD-- 8044
8:17
2
Idle
Unselected
Detached
-------- 0
8:18
37
Idle
Unselected
Detached
-------- 0
8:19
36
Idle
Unselected
Detached
-------- 0
8:20
35
Idle
Unselected
Detached
-------- 0
================================================================================
Actor Flags: A-Activity, T-Timeout, G-Aggregation, S-Synchronization
C-Collecting, D-Distributing, F-Defaulted, E-Expired
The following is sample output when you add the detail parameter for LAG 4:9 on a modular switch:
show lacp lag 4:9 detail
Lag
Actor
Actor
Partner
Partner Partner Agg
Sys-Pri Key
MAC
Sys-Pri Key
Count
-------------------------------------------------------------------------------4:9
2110
0x0fa9 00:04:96:10:33:60
2110
0x0fa9
16
Up
Enabled
Unack count
Wait-for-count
:
:
:
:
Yes
Yes
0
0
137
Port list:
Member
Port
Rx
Sel
Mux
Actor
Partner
Port
Priority State
Logic
State
Flags
Port
-------------------------------------------------------------------------------4:9
300
Current
Selected
Collect-Dist
A-GSCD-- 4009
4:10
301
Current
Selected
Collect-Dist
A-GSCD-- 4010
4:11
302
Current
Standby
Detached
A-G----- 4011
4:12
303
Current
Standby
Detached
A-G----- 4012
4:29
200
Current
Selected
Collect-Dist
A-GSCD-- 4029
4:30
0
Current
Selected
Collect-Dist
A-GSCD-- 4030
4:31
202
Current
Selected
Collect-Dist
A-GSCD-- 4031
4:32
203
Current
Selected
Collect-Dist
A-GSCD-- 4032
8:7
101
Current
Selected
Collect-Dist
A-GSCD-- 8013
8:8
10
Current
Selected
Collect-Dist
A-GSCD-- 8014
8:9
9
Current
Selected
Collect-Dist
A-GSCD-- 8015
8:10
8
Current
Selected
Collect-Dist
A-GSCD-- 8016
8:11
7
Current
Selected
Collect-Dist
A-GSCD-- 8017
8:12
6
Current
Selected
Collect-Dist
A-GSCD-- 8018
8:13
5
Current
Selected
Collect-Dist
A-GSCD-- 8019
8:14
3
Current
Selected
Collect-Dist
A-GSCD-- 8020
8:15
0
Current
Selected
Collect-Dist
A-GSCD-- 8043
8:16
3
Current
Selected
Collect-Dist
A-GSCD-- 8044
8:17
2
Idle
Unselected
Detached
-------- 0
8:18
37
Idle
Unselected
Detached
-------- 0
8:19
36
Idle
Unselected
Detached
-------- 0
8:20
35
Idle
Unselected
Detached
-------- 0
================================================================================
Actor Flags: A-Activity, T-Timeout, G-Aggregation, S-Synchronization
C-Collecting, D-Distributing, F-Defaulted, E-Expired
To display LACP information for a specific port that is a member of a LAG, use the following
command:
show lacp member-port <port> {detail}
The following is sample output you see when you display the LACP information for port 4:9 on a
modular switch:
Member
Port
Rx
Sel
Mux
Actor
Partner
Port
Priority State
Logic
State
Flags
Port
-------------------------------------------------------------------------------4:9
300
Current
Selected
Collect-Dist
A-GSCD-- 4009
138
The following is sample output you see when you add the detail parameter for port 4:9 on a modular
switch:
Member
Port
Rx
Sel
Mux
Actor
Partner
Port
Priority State
Logic
State
Flags
Port
-------------------------------------------------------------------------------4:9
300
Current
Selected
Collect-Dist
A-GSCD-- 4009
Up
: Yes
Enabled
: Yes
Link State
: Up
Actor Churn
: False
Partner Churn : False
Ready_N
: Yes
Wait pending : No
Ack pending
: No
LAG Id:
S.pri:2110, S.id:00:01:30:f9:9c:30, K:0x0fa9, P.pri:300 , P.num:4009
T.pri:2110, T.id:00:04:96:10:33:60, L:0x0fa9, Q.pri:300 , Q.num:4009
Stats:
Rx - Accepted
: 2174
Rx - Dropped due to error in verifying PDU
: 0
Rx - Dropped due to LACP not being up on this port : 0
Rx - Dropped due to matching own MAC
: 0
Tx - Sent successfully
: 2175
Tx - Transmit error
: 0
================================================================================
Actor Flags: A-Activity, T-Timeout, G-Aggregation, S-Synchronization
C-Collecting, D-Distributing, F-Defaulted, E-Expired
Refer to Displaying Port Configuration Information for information on displaying summary loadsharing information.
To clear the counters, use the following command:
clear lacp counters
Beginning with ExtremeWare XOS version 11.4, you can display the LCAP counters for all member
ports in the system. To display the LACP counters, use the following command:
show lacp counters
PDUs
Bulk
Bulk
PDUs
PDUs
:
:
:
:
:
519392
1
0
575616
0
139
Member
Port
Rx
Ok
Rx Drop
PDU Err
Rx Drop
Not Up
Rx Drop Tx
Same MAC Sent Ok
Tx
Xmit Err
-------------------------------------------------------------------------------1:1
1:1
2169
0
0
0
2170
0
1:2
2169
0
0
0
2170
0
1:3
2169
0
0
0
2170
0
1:4
2169
0
0
0
2170
0
1:5
2169
0
0
0
2170
0
1:6
2169
0
0
0
2170
0
1:7
2169
0
0
0
2170
0
1:8
2168
0
0
0
2169
0
================================================================================
Port mirroring configures the switch to copy all traffic associated with one or more ports. The monitor
port can then be connected to a network analyzer or RMON probe for packet analysis. The system uses
a traffic filter that copies a group of traffic to the monitor port. You can have only one monitor port on
the switch.
NOTE
The mirroring limits discussed in this chapter do not apply when you are working with Sentriant devices.
NOTE
On the BlackDiamond 8800 family of switches and the Summit X450 switch, you can mirror only 8 VLANs on a
given port.
NOTE
Frames that contain errors are not mirrored.
140
Physical portAll data that traverses the port, regardless of VLAN configuration, is copied to the
monitor port. You can specify which traffic the port mirrors:
VLANAll data to a particular VLAN, regardless of the physical port configuration, is copied to the
monitor port.
Virtual portAll data specific to a VLAN on a specific port is copied to the monitor port.
Only traffic ingressing a VLAN can be monitored; you cannot specify ingressing or egressing traffic
when mirroring VLAN traffic.
When routing between VLANs, ingress mirrored traffic is presented to the monitor port as modified
for routing.
When you specify the ingress traffic, the packet is mirrored after it is modified by the ingress process
and may include internal tagging and/or egress tagging.
Even if you select ingress and egress traffic, the packet is mirrored only the first time it matches a
mirror filter and is not mirrored on subsequent configured filters.
You cannot include the monitor port for the BlackDiamond 8800 family of switches or a Summit
X450 switch in a load-sharing group.
You cannot run sFlow and mirroring on the same switch for the BlackDiamond 8800 family of
switches or the Summit X450 switch. If you attempt to enable mirroring on a port that is already
enabled for sFlow, the switch returns the following message:
Mirroring is not compatible with SFlow. Mirroring is not enabled!
All traffic egressing the monitor port is tagged on the BlackDiamond 8800 family of switches and the
Summit X450 switch. Even if some untagged ports send mirrored traffic to the monitor port, that traffic
also egresses the monitor port tagged with the internal VLAN ID.
Physical portAll data that traverses the port, regardless of VLAN configuration, is copied to the
monitor port.
VLANAll data to and from a particular VLAN, regardless of the physical port configuration, is
copied to the monitor port.
Virtual portAll data specific to a VLAN on a specific port is copied to the monitor port.
141
The master port of the load-sharing group can be the monitor port for port-mirroring.
The monitor port transmits tagged or untagged frames, according to the way you configured the
monitor port. This feature allows you to mirror multiple ports or VLANs to a monitor port, while
preserving the ability of a single protocol analyzer to track and differentiate traffic within a broadcast
domain (VLAN) and across broadcast domains (for example, across VLANs when routing).
NOTE
The monitor port on the BlackDiamond 10K switch must be explicitly configured for tagged or untagged frames
beginning with ExtremeWare XOS version 11.0.
The traffic egressing the monitor port can be either tagged or untagged. If the mirroring is enabled as
tagged on the monitor port, all traffic egressing the monitor port is tagged. In this case, even if some
untagged ports send mirrored traffic to the monitor port, that traffic also egresses the monitor port as
tagged. And, if mirroring is enabled as untagged on the monitor port, all traffic egressing the monitor
port is untagged, including mirrored tagged packets.
When you upgrade to ExtremeWare XOS 11.0 on the BlackDiamond 10K switches, all restored mirroring
configurations are tagged on the monitor ports.
To change monitor ports, you must first remove all the filters.
Any mirrored port can also be enabled for load sharing (or link aggregation); however, each
individual port of the load-sharing group must be explicitly configured for mirroring.
The monitor port is automatically removed from all VLANs; you cannot add it to a VLAN.
The mirroring filters are not confined to a single module; they can have ports that span multiple
modules.
You cannot use the management port at all in switch port-mirroring configurations.
142
NOTE
When you change the mirroring configuration, the switch stops sending egress packets from the monitor port until
the change is complete. The ingress mirroring traffic to the monitor port and regular traffic are not affected.
The BlackDiamond 8800 Family of Switches and the Summit X450 Switch Only
The following example selects slot 3, port 4 on a modular switch as the monitor port and sends all
traffic received at slot 6, port 5 to the monitor port:
enable mirroring to port 3:4
configure mirroring add port 6:5 ingress
The following example selects slot 3, port 4 on a modular switch as the monitor port and send all traffic
sent from slot 6, port 5 to the monitor port:
enable mirroring to port 3:4
configure mirroring add port 6:5 egress
The following example selects port 4 on a standalone switch as the monitor port and sends all traffic
ingressing the VLAN red to the monitor port:
enable mirroring to port 4
configure mirroring add vlan red
The following example selects port 4 on a standalone switch as the monitor port and sends all traffic
ingressing the VLAN red on port 5 to the monitor port:
enable mirroring to port 4
configure mirroring add vlan red port 5
The following example sends all traffic coming into or out of the system on slot 8, port 1 and the VLAN
default to the untagged monitor port, which is slot 7, port 3:
enable mirroring to port 7:3 untagged
configure mirroring add port 8:1 vlan default
143
Switch IP address
EDP is enabled on all ports by default. EDP enabled ports advertise information about the Extreme
Networks switch to other switches on the interface and receives advertisements from other Extreme
Networks switches. Information about other Extreme Networks switches is discarded after a timeout
interval is reached without receiving another advertisement.
144
This command clears the following counters for EDP protocol data units (PDUs) sent and received per
EDP port:
To view EDP port information on the switch, use the following command:
show edp
The following is sample output from the show edp command (the screen display was interrupted in the
following sample) on a modular switch:
EDP advert-interval
EDP holddown-interval
EDP enabled on ports
1
:60 seconds
:180 seconds
:1:1 1:2 1:3 1:4 1:5 1:6
1:12 1:13 1:14 1:15 1:16
1:22
2:20
2:31
2:42
1:23
2:10
1:24
2:11
2:21
2:22
2:23
2:24
2:25
2:26
2:27
2:28
2:29
2:3
2:32
2:33
2:34
2:35
2:36
2:37
2:38
2:39
2:40
2:4
The following is sample output from the show edp ports 1:1 detail command on a modular
switch:
=============================================================================
Port 1:1: EDP is Enabled
Tx stats: sw-pdu-tx=2555
Rx stats: sw-pdu-rx=2511
vlan-pdu-tx=1465
vlan-pdu-rx=2511
pdu-tx-err=0
pdu-rx-err=0
Age = 41
145
11.1.0.19
1:1
Ethernet
OFF
SYMMETRIC/ASYMMETRIC
Configured = HALF
Configured = ERROR
Actual = HALF
Actual = 100 Mbps
Age = 41
=============================================================================
To configure the advertisement interval and the timeout interval, use the following command:
configure edp advertisment-interval <timer> holddown-interval <timeout>
Refer to Displaying Port Configuration Information for information on displaying EDP status.
Smart Redundancy is a feature that allows control over how the failover from a redundant port to the
primary port is managed. If this feature is enabled, which is the default setting, the switch attempts to
revert to the primary port as soon as it can be recovered. If the feature is disabled, the switch attempts
only to recover the primary port to active if the redundant port fails.
146
Switch B
Primary
Link
Redundant
Link
Switch C
XOS002
In normal operation, the primary port is active and the software redundant switch (switch C in
Figure 1) blocks the redundant port for all traffic, thereby avoiding a loop in the network. If the switch
detects that the primary port is down, the switch unblocks the redundant port and allows traffic to flow
through that redundant port.
NOTE
The primary and redundant ports must have identical VLAN membership.
You configure the software-controlled redundant port feature either to have the redundant link always
physically up but logically blocked or to have the link always physically down. The default value is to
have the link physically down, or Off.
By default, Smart Redundancy is always enabled. If you enable Smart Redundancy, the switch
automatically fails over to the redundant port and returns traffic to the primary port after connectivity
is restored on that port. If you do not want the automatic restoration of the primary link when it
becomes active, disable Smart Redundancy.
You cannot have any Layer 2 protocols configured on any of the VLANs that are present on the
ports. (You will see an error message if you attempt to configure software redundant ports on ports
with VLANs running Layer 2 protocols.)
The primary and redundant ports must have identical VLAN membership.
The master port is the only port of a load-sharing group that can be configured as either a primary
or redundant port. Also, all ports on the load-sharing group must fail before the software-controlled
redundancy is triggered.
You must disable the software redundancy on the master port before enabling or disabling load
sharing.
You can configure only one redundant port for each primary port.
147
Recovery may be limited by FDB aging on the neighboring switch for unidirectional traffic. For bidirectional traffic, the recovery is immediate.
NOTE
On the BlackDiamond 10K switch, 10 Gbps modules with a serial number lower than 804405-00-09 the software
redundant port feature cover only those failures where both the TX and RX paths fail. If a single strand of fiber is
pulled on these ports, the software redundant port cannot correctly recover from the failure.To display the serial
number of the module, use the show slot <slot_number> command. (All the modules on the BlackDiamond
8800 family of switches have this serial number or higher.)
The first port specified is the primary port. The second port specified is the redundant port.
To unconfigure a software-controlled redundant port, use the following command and enter the
primary port(s):
unconfigure ports <port_list> redundant
To configure the switch for the Smart Redundancy feature, use the following command:
enable smartredundancy <port_list>
148
The following is sample output on a modular switch of the show port 1:1 information detail after
redundancy is configured:
Port:
1:1
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Disabled
Admin state:
Enabled with auto-speed sensing auto-duplex
Link State:
Active, 100Mbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: peggy, Internal Tag = 4094, MAC-limit = No-limit
STP cfg:
Protocol:
Name: peggy
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% PR
=
100K Pri = 8
Queue:
QP1 MinBw =
0% MaxBw =
100% Pri = 1
QP2 MinBw =
0% MaxBw =
100% Pri = 2
QP3 MinBw =
0% MaxBw =
100% Pri = 3
QP4 MinBw =
0% MaxBw =
100% Pri = 4
QP5 MinBw =
0% MaxBw =
100% Pri = 5
QP6 MinBw =
0% MaxBw =
100% Pri = 6
QP7 MinBw =
0% MaxBw =
100% Pri = 7
QP8 MinBw =
0% MaxBw =
100% Pri = 8
Ingress Rate Shaping :
support IQP1-2
IQP1 MinBw =
0% MaxBw =
100% Pri = 1
IQP2 MinBw =
0% MaxBw =
100% Pri = 2
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogIn:
Disabled
Smart redundancy:
Enabled
Software redundant port:
Enabled
Primary:
1:1
Redundant:
1:2
Redundant link configuration: Off
autopolarity:
Enabled
149
The redundant ports are shared PHY copper and fiber ports; these are ports 1 to 4 on both the Summit
X450-24x and the Summit X450-24t switches.
To display the port type currently used as well as the preferred media setting, use the following
command:
show ports {mgmt | <port_list>} information {detail}
Refer to Displaying Port Configuration Information for more information on the show ports
information command.
The first four fiber ports and the first four 10/100/1000BASE-T ports of the Summit X450 switch are
designed as combination ports for uplink redundancy. When sharing ports, only the fiber medium or
only the copper medium can be active at one time. See Figure 2 for a diagram of these combination
ports on the Summit X450-24t switch and Figure 3 for a diagram of these combination ports on the
Summit X450-24x switch. If copper medium 1 goes down while transmitting packets, fiber medium 1
activates and becomes the primary link, and vice-versa.
S450_004
150
S450_005
The switch determines whether the port uses the primary or redundant media based upon the order in
which the connectors are inserted into the switch. When the switch senses a mini-GBIC and a copper
connector are inserted, the switch enables the uplink redundancy feature. As an example on the Summit
X450-24t switch, if you insert mini-GBICs into fiber port 1 and fiber port 3 first and then connect copper
ports 1 and 3, the switch assigns ports 1 and 3 as redundant ports.
Hardware determines when a link is lost and swaps the primary and redundant ports to maintain
stability. After a failover occurs, the switch keeps or sticks with the current port assignment until there
is another failure or until a user changes the assignment using the CLI. To change the uplink failover
assignment, use the following command:
configure ports <port_list> preferred-medium [copper | fiber] {force}
The default preferred-medium is fiber. If you use the force option, it disables automatic failover. If you
force the preferred-medium to fiber and the fiber link goes away, the copper link is not used, even if
available.
commands.
The show ports configuration command shows you either summary configuration information on
all the ports, or more detailed configuration information on specific ports. If you specify the norefresh parameter, the system displays a snapshot of the data at the time you issue the command.
The following sample output is from the show ports configuration command on a modular switch
and displays the port configuration for all ports:
show ports configuration
Port Configuration
Port
Virtual
Port Link Auto
Speed
Duplex
Flow Load
Media
router
State State Neg Cfg Actual Cfg Actual Cntrl Master Pri Red
================================================================================
1:1
VR-Default
E
A
ON AUTO
100 AUTO FULL SY/ASYM
UTP
1:2
VR-Default
E
R
ON AUTO
AUTO
UTP
2:1
VR-Default
E
R
ON AUTO
AUTO
UTP
2:2
VR-Default
E
R
ON AUTO
AUTO
UTP
151
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
VR-Default
E
E
E
E
E
E
E
E
E
E
E
E
E
E
R
R
R
R
R
R
R
R
R
R
R
R
R
R
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
UTP
VR-Default
VR-Default
VR-Default
E
E
E
R
R
R
ON
ON
ON
AUTO
AUTO
AUTO
AUTO
AUTO
AUTO
UTP
UTP
UTP
================================================================================
Link Status: A-Active, R-Ready, NP-Port not present
Port State: D-Disabled E-Enabled, Media: !-Unsupported XENPAK
0->Clear Counters U->page up D->page down ESC->exit
NOTE
On 10 Gbps ports, the Media Primary column displays NONE when no module is installed, and SR, LR, or ER
depending on the module installed when there is one present.
The following sample command displays the port configuration statistics for slot 2, port 2 on a modular
switch:
show ports 2:2 configuration
The show ports information command shows you either summary information on all the ports, or
more detailed information on specific ports. The output from the command differs very slightly
depending on the platform you are using.
The information displayed by issuing the show ports information varies by platform; the following
sample output is from this command and displays the port configuration for a specified port on a
BlackDiamond 10K switch:
152
Flags
Link
Link Num Num Num
Jumbo QOS
Load
State ELSM UPS STP VLAN Proto Size profile Master
=============================================================================
3:1
Em------e-- ready
0
0
1
1
9216
==============================================================================
Flags : a - Load Sharing Algorithm address-based, D - Port Disabled,
e - Extreme Discovery Protocol Enabled, E - Port Enabled,
g - Egress TOS Enabled, j - Jumbo Frame Enabled,
l - Load Sharing Enabled, m - MACLearning Enabled,
n - Ingress TOS Enabled, o - Dot1p Replacement Enabled,
P - Software redundant port(Primary),
R - Software redundant (Redundant),
q - Background QOS Monitoring Enabled,
s - diffserv Replacement Enabled,
v - Vman Enabled, f - Unicast Flooding Enabled
M - Multicast Flooding Enabled, B - Broadcast Flooding Enabled
L - Extreme Link Status Monitoring Enabled
NOTE
The BlackDiamond 10K series and 12804 switches have an additional flag: p - Load Sharing Algorithm
port-based.
Beginning with ExtremeWare XOS software version 11.3 you can display real-time port utilization
information, by issuing the following command:
show ports {mgmt | <port_list>} utilization {bandwidth | bytes | packets}
The following sample output is from the show ports utilization command for all ports on the
Summit X450 switch (real-time display that constantly refreshes):
Link Utilization Averages
Fri Aug 5 13:23:45 UTC 2005
Port
Link
Receive
Peak Rx
Transmit
Peak Transmit
Status packets/sec
packets/sec
packets/sec
packets/sec
================================================================================
1
A
0
0
0
0
2
R
0
0
0
0
3
R
0
0
0
0
4
R
0
0
0
0
5
R
0
0
0
0
6
R
0
0
0
0
7
R
0
0
0
0
8
R
0
0
0
0
9
R
0
0
0
0
10
R
0
0
0
0
11
R
0
0
0
0
12
R
0
0
0
0
13
R
0
0
0
0
14
R
0
0
0
0
15
R
0
0
0
0
16
R
0
0
0
0
17
R
0
0
0
0
================================================================================
Link Status : A-Active, R-Ready, NP-Port Not Present
153
NOTE
Use the <spacebar> to toggle this real-time display for all ports from packets to bytes and bandwidth, in that order.
When you use a parameter (packets, byte, or bandwidth) with the command, the display for the
specified type shows a snapshot per port when you issued the command.
3
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Unsupported
Admin state:
Enabled with auto-speed sensing auto-duplex
Link State:
Active, 1 Gbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1 (MAC-Based), MAC-limit = No-limit
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo: Enabled, MTU= 9216
Egress Port Rate:
128 Kbps, Max Burst Size: 200 Kb
Broadcast Rate:
No-limit
Multicast Rate:
No-limit
Unknown Dest Mac Rate: No-limit
QoS Profile:
QP3 configured by user
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Ingress 802.1p Examination:
Enabled
Ingress 802.1p Inner Exam:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Enabled
NetLogin authentication mode:
MAC based
NetLogin port mode:
MAC based VLANs
154
Enabled
Disabled
Fiber
3:1
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Unsupported
Admin state:
Enabled with auto-speed sensing auto-duplex
ELSM Link State:
Up
Link State:
Active, 1 Gbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1 (MAC-Based), MAC-limit = No-limit
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Enabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo: Enabled, MTU= 9216
Egress Port Rate:
128 Kbps, Max Burst Size: 200 Kb
Broadcast Rate:
No-limit
Multicast Rate:
No-limit
Unknown Dest Mac Rate: No-limit
QoS Profile:
QP3 configured by user
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Ingress 802.1p Examination:
Enabled
Ingress 802.1p Inner Exam:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Enabled
NetLogin authentication mode:
MAC based
NetLogin port mode:
MAC based VLANs
Smart redundancy:
Enabled
Software redundant port:
Disabled
autopolarity:
Enabled
155
1:1
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Unsupported
Admin state:
Enabled with auto-speed sensing auto-duplex
Link State:
Active, 100Mbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: peggy, Internal Tag = 4094, MAC-limit = No-limit
STP cfg:
Protocol:
Name: peggy
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% PR
=
100K Pri = 8
Queue:
QP1 MinBw =
0% MaxBw =
100% Pri = 1
QP2 MinBw =
0% MaxBw =
100% Pri = 2
QP3 MinBw =
0% MaxBw =
100% Pri = 3
QP4 MinBw =
0% MaxBw =
100% Pri = 4
QP5 MinBw =
0% MaxBw =
100% Pri = 5
QP6 MinBw =
0% MaxBw =
100% Pri = 6
QP7 MinBw =
0% MaxBw =
100% Pri = 7
QP8 MinBw =
0% MaxBw =
100% Pri = 8
Ingress Rate Shaping :
support IQP1-2
IQP1 MinBw =
0% MaxBw =
100% Pri = 1
IQP2 MinBw =
0% MaxBw =
100% Pri = 2
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogIn:
Disabled
Smart redundancy:
Enabled
Software redundant port:
Enabled
Primary:
1:1
Redundant:
1:2
156
2:1
Virtual-router: VR-Default
Type:
NONE
Random Early drop:
Unsupported
Admin state:
Enabled with 10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual ro
uter: VR-Default
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
High Priority COS: 7
Packet Length Adjustment: 0 bytes
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% MaxBw =
Queue:
QP1 MinBw =
0% MaxBw =
QP2 MinBw =
0% MaxBw =
QP3 MinBw =
0% MaxBw =
QP4 MinBw =
0% MaxBw =
QP5 MinBw =
0% MaxBw =
QP6 MinBw =
0% MaxBw =
QP7 MinBw =
0% MaxBw =
QP8 MinBw =
0% MaxBw =
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
100%
Pri = 8
100%
100%
100%
100%
100%
100%
100%
100%
Pri
Pri
Pri
Pri
Pri
Pri
Pri
Pri
=
=
=
=
=
=
=
=
1
2
3
4
5
6
7
8
157
Disabled
Disabled
Port based VLANs
Enabled
Disabled
Fiber
NOTE
On the GM-20XT and GM-20XTR modules for the BlackDiamond 12804 and 12804 R-Series switches, you can use
each port as either copper or fiber; preferred medium displays which medium the specified port is using.
158
Overview
Beginning with ExtremeWare XOS version 11.2, the software supports the Link Layer Discovery
Protocol (LLDP). LLDP is a Layer 2 protocol (IEEE standard 802.1ab) that is used to determine the
capabilities of devices such as repeaters, bridges, access points, routers, and wireless stations.
ExtremeWare XOS version 11.2 LLDP support enables devices to advertise their capabilities and mediaspecific configuration information and to learn the same information from the devices connected to it.
The information is represented in Type Length Value (TLV) format for each data item. The 802.1ab
specification provides detailed TLV information. The TLV information is contained and transmitted in
an LLDP protocol data unit (LLDPDU). Certain TLVs are mandatory and are always sent after LLDP is
enabled; other TLVs are optionally configured. LLDP defines a set of common advertisement messages,
a protocol for transmitting the advertisements, and a method for storing the information contained in
received advertisements.
LLDP provides a standard method of discovering and representing the physical network connections of
a given network management domain. LLDP works concurrently with Extreme Discovery Protocol
(EDP); it also works independently, you do not have to run EDP to use LLDP. The LLDP neighbor
discovery protocol allows you to discover and maintain accurate network topologies in a multivendor
environment.
The information distributed using LLDP is stored by its recipients in a standard Management
Information Base (MIB), making it possible for the information to be accessed by a Network
Management System (NMS) using a management protocol such as the Simple Network Management
Protocol (SNMP).
LLDP transmits periodic advertisements containing device information and media-specific configuration
information to neighbors attached to the same network. LLDP agents cannot solicit information from
other agents by way of this protocol. The TLV format with link layer control frames is used to
communicate with other LLDP agents. LLDP agents also receive link layer control frames, extract the
information from TLVs, and store them in LLDP MIB objects.
If the information values from the device change at any time, the LLDP agent is notified. The agent then
sends an update with the new values, which is referred to as a triggered update. If the information for
multiple elements changes in a short period, the changes are bundled together and sent as a single
update to reduce network load.
159
NOTE
LLDP runs with load sharing.
LLDP Messages
You configure the device to transmit messages, to receive messages, or both. This section describes the
following topics:
LLDP Packets
LLDP is enabled and configured per port.
Multiple advertisements messages (or TLVs) are transmitted in one LAN packet, the LLDPDU
(Figure 4). The LLDP packet contains the destination multicast address, the source MAC address, the
LLDP EtherType, the LLDPDU data, and a frame check sequence (FCS). The LLDP multicast address is
defined as 01:80:C2:00:00:0E, and the EtherType is defined as 0x88CC.
SA
Ethertype
Data + Pad
LLDP_Multicast
Address
Source MAC
Address
88-CC
LLDPDU
FCS
1500
Octets
XOS005
The frames are sent with a link-local-assigned multicast address as destination address.
The Spanning Tree Protocol (STP) state of the port does not affect the transmission of LLDP frames.
The length of the packet cannot exceed 1500 bytes. As you add TLVs, you increase the length of the
LLDP frame. When you reach 1500 bytes, the remaining TLVs are dropped. Extreme Networks
recommends that you advertise information regarding only one or two VLANs on the LLDP port, to
avoid dropped TLVs. If the system drops TLVs because of exceeded length, the system logs a message
to the EMS and the show lldp statistics commands shows this information under the Tx Length
Exceeded field.
160
LLDP Messages
NOTE
The LLDPDU has a maximum of 1500 bytes, even with jumbo frames enabled. TLVs that exceed this limit are
dropped.
Chassis ID (mandatory)
Port ID (mandatory)
Time-to-live (mandatory)
Port description
System name
System capabilities
Management address
802.1-specific information
VLAN name
Port VLAN ID
802.3-specific information
MAC/PHY
Link aggregation
This information is obtained from memory objects such as standard MIBs or from system management
information.
161
Managing LLDP
LLDP can work in tandem with EDP. LLDP is disabled by default, and EDP is enabled by default. LLDP
information is transmitted periodically and stored for a finite period. You access the information using
SNMP. A port configured to receive LLDP messages can store information for up to four neighbors.
You manage LLDP using the CLI and SNMP. (Refer to ExtremeWare XOS Command Reference Guide for
complete information on configuring, managing, and displaying LLDP.)
LLDP information is transmitted periodically and stored for a finite period. After you enable LLDP, you
can set a variety of time periods for the transmission and storage of the LLDP messages (or you can use
the default values), as follows:
Time-to-live (TTL) value (default is 2 minutes)time that the information remains in the recipients
LLDP database
Each time a device receives an LLDP advertisement packet, the device stores the information and
initializes a timer that is compared to the TTL value of the packet. If the timer reaches the TTL value,
the LLDP agent deletes the stored information. This action ensures that only valid information is stored
in the LLDP agent.
After you enable LLDP, you can enable the LLDP-specific SNMP traps; the traps are disabled by default.
You configure the period between the system sending SNMP notifications; the default interval is 5
seconds. LLDP configurations are saved across reboots when you issue the save configuration
command.
The system logs EMS messages regarding LLDP when:
Configured optional TLVs that exceed the 1500-byte limit and are dropped.
When both IEEE 802.1x and LLDP are enabled on the same port, LLDP packets are not sent until one or
more clients authenticate a port. Also, incoming LLDP packets are only accepted if one or more clients
are authenticated.
You can configure an optional TLV to advertise or not to advertise the devices management address
information to the ports neighbors. With ExtremeWare XOS, when enabled, this TLV sends out the IPv4
address configured on the management VLAN. If you have not configured an IPv4 address on the
management VLAN, the software advertises the systems MAC address. LLDP does not send out IPv6
addresses in this field.
Supported TLVs
The TLVs are contained in the LLDPDU portion of the LLDP packet, and the LLDPDU cannot exceed
1500 bytes. Some TLVs are mandatory according to the 802.1ab standard, and the rest are optional. The
mandatory TLVs are included by default as soon as you enable LLDP, as is the system description TLV.
One other TLV, system description, is enabled by default on the ExtremeWare XOS LLDP
implementation. Additionally some TLVs can be repeated in one LLDP.
162
Supported TLVs
NOTE
To avoid exceeding the 1500-byte limit, Extreme Networks recommends sending information on only one or two
VLANs on the LLDP port. Any TLVs that exceed the limit are dropped.
The following TLVs are enabled by default when LLDP transmit is enabled on a port:
Chassis ID
Port ID
Time to live
System description
End-of-LLDP PDU
All of these TLVs that are sent by default are mandatory for the protocol and cannot be disabled, except
the system description. You can configure the system not to advertise the system description when
LLDP is enabled; the other four TLVs cannot be configured not to advertise. Table 18 lists all the defined
TLVs, if they are included by default after you enable LLDP, if they can be configured, if they are
mandatory or optional, and if you can repeat that TLV in one LLDP packet.
NOTE
Refer to ExtremeWare XOS Command Reference Guide for complete information on configuring LLDP using the CLI.
Included by
default
Chassis ID
Mandatory TLV
Port ID
Mandatory TLV
Mandatory TLV
User configurable
Port description
System name
System description
Repeatable
System capabilities
Management address
VLAN name
Port VLAN ID
Protocol identity
MAC/PHY configuration/
status
Link aggregation
End-of-LLDP PDU
ExtremeWare XOS
sends only 1 TLV
X
X
Comments
Not supported
X
X
Mandatory TLV
163
Mandatory TLVs
This section describes the following mandatory TLVs, which are automatically enabled after you enable
LLDP on a port:
Chassis ID TLV
This mandatory TLV is sent by default after you enable LLDP on the port. It is not configurable.
The ExtremeWare XOS software uses the systems MAC address to uniquely identify the device. EDP
also uses this to identify the device.
Port ID TLV
This mandatory TLV is sent by default after you enable LLDP on the port; you cannot configure this
TLV. The port ID TLV is used to uniquely identify the port within the device.
The software uses the ifName object for this TLV, so it is the port number on stand-alone switches and
the combination of slot and port number on modular switches.
TTL TLV
The TTL TLV is mandatory, sent by default after LLDP is enabled, and nonconfigurable. This TLV
indicates how long the record should be maintained in the LLDP database. The default value is 120
seconds (or 2 minutes).
A value of 0 in the TTL TLV means the client is shutting down and that record should be deleted from
the database. When you disable an LLDP port, the triggered update LLDPU from that port contains a
TTL TLV of 0.
The TTL TLV is mandatory and is sent by default after LLDP is enabled. Although, technically, you do
not configure the TTL TLV, you can configure the transmit hold value, which is used to calculate the
TTL TLV. (See Configuring LLDP Timers on page 169 for more information on transmit hold value
and TTL.)
End-of-LLDPDU TLV
The end-of-LLDPDU TLV marks the end of the data. The system automatically adds this TLV to the
LLDPDU after you enable LLDP.
Optional TLVs
All the optional TLVs are configurable using the CLI and/or SNMP.
164
Supported TLVs
NOTE
The system description TLV is automatically enabled after you enable LLDP and is always sent as part of the
LLDPDU. Although this TLV is not mandatory according to the standard, the ExtremeWare XOS software includes this
TLV in all LLDPDUs by default; you can configure the system not to advertise this TLV.
165
166
Supported TLVs
As Extreme Networks devices are always capable of supporting protocol-based VLANs, after you
configure this TLV, the system always advertises support for this type of VLAN.
By default, after you configure this TLV, the system sends information for all VLANs on the port.
However, as VLAN TLV requires space and the LLDPDU cannot exceed 1500 bytes, you should
configure the port to advertise only specified VLANs.
Power source
PSE device
PD device
2-3
Reserved
Additional PoE information is advertised as well, including the power status, power class, and pin pairs
used to supply power.
167
Configuring LLDP
You configure LLDP per port. To configure LLDP:
1 Enable LLDP on the desired port(s).
2 If desired, configure the system not to advertise the system description TLV.
3 If you want to change any default values, configure the following values:
a Reinitialize period
b Transmit interval
c
Transmit delay
d Transmit hold
4 Enable the SNMP traps and configure the notification interval.
5 Configure any optional TLV advertisements that you want included in the LLDPDU.
This section describes how to configure LLDP using the CLI. Refer to ExtremeWare XOS Command
Reference Guide for complete information on configuring LLDP You can also reference the IEEE 892,1ab
standard.
After you enable LLDP, the following TLVs are automatically added to the LLDPDU:
Chassis ID
Port ID
TTL
System description
End of LLDPDU
All of these, except the system description, are mandated by the 802.1ab standard. Similarly, none of
these, except the system description, can be configured to advertise or not to advertise.
To disable LLDP, use the following command:
disable lldp ports [all | <port_list>] {receive-only | transmit-only}
168
Configuring LLDP
To disable the default advertisement of the system description, use the following command:
configure lldp ports [all | <port_list>] no-advertise system-description
When LLDP is disabled or if the link goes down, LLDP is reinitialized. The reinitialize delay is the
number of seconds the port waits to restart LLDP state machine; the default is 2 seconds.
To change the default reinitialize delay period, use the following command:
configure lldp reinitialize-delay <seconds>
LLDP messages are transmitted at a set interval; this interval has a default value of every 30 seconds. To
change this default value, use the following command:
configure lldp transmit-interval <seconds>
The time between triggered update LLDP messages is referred to as the transmit delay, and the default
value is 2 seconds. You can change the default transmit delay value to a specified number of seconds or
to be automatically calculated by multiplying the transmit interval by 0.25. To change the value for the
transmit delay, use the following command:
configure lldp transmit-delay [ auto | <seconds>]
Each LLDP message contains a TTL value. The receiving LLDP agent discards all LLDP messages that
surpass the TTL value; the default value is 120 seconds.
The TTL is calculated by multiplying the transmit interval value and the transmit hold value; the
default transmit hold value is 4. To change the default transmit hold value, use the following command:
configure lldp transmit-hold <hold>
The traps are only sent for those ports that are both enabled for LLDP and have LLDP traps enabled.
To disable the LLDP SNMP traps, use the following command:
disable snmp traps lldp {ports [all | <port_list>]}
169
NOTE
Extreme Networks recommends that you advertise only one or two VLANS on specified ports to avoid dropping TLVs
from the LLDPDU.
You configure LLDP ports to advertise any of the following optional TLVs:
Refer to Optional TLVs on page 164 for complete information on each optional TLV.
To advertise the optional port description information, use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] port-description
170
Configuring LLDP
To advertise the IP address of the management VLAN (or the system MAC address if IP is not
configured), use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] managementaddress
You can advertise more than one VLAN name per LLDP-enabled port. To do so, add one optional
VLAN name TLV for each VLAN you want to advertise. If you do not specify VLAN names, the system
sends an advertisement for all VLANs on the port.
To advertise VLAN names, use the following command:
configure lldp ports [all | <port_list>] [advertise | dont-advertise] vendorspecific dot1 vlan-name {vlan [all | <vlan_name>]}
NOTE
The total LLPDU size is 1500 bytes; any TLVs after that limit are dropped.
You can advertise the untagged, port-based VLAN for the LLDP-enabled port using the port VLAN ID
TLV. To configure the port VLAN ID TLV, use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] vendor-specific
dot1 port-vlan-ID
You can advertise more than one protocol-based VLAN per LLDP-enabled port. To do so, add one
optional port and protocol VLAN ID TLV for each VLAN you want to advertise. To advertise these
VLANs, use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] vendor-specific
dot1 port-protocol-vlan-ID {vlan [all | <vlan_name>]}
NOTE
The total LLPDU size is 1500 bytes; any TLVs after that limit are dropped.
You can advertise the speed capabilities, autonegotiation support and status and physical interface of
the LLDP-enabled port using the MAC/PHY configuration/status TLV. To advertise this information,
use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] vendor-specific
dot3 mac-phy
Configure the power via MDI TLV to advertise the PoE capabilities of the LLDP-enabled port. To
advertise the PoE capabilities and status, use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] vendor-specific
dot3 power-via-mdi
You advertise the load-sharing capabilities and status of the LLDP-enabled port by configuring the link
aggregation TLV. To advertise load-sharing capabilities, use the following command:
configure lldp ports [all | <port_list>] [advertise | no-advertise] vendor-specific
dot3 link-aggregation
171
Unconfiguring LLDP
To unconfigure LLD, use the following command:
unconfigure lldp
This command only returns the LLDP timers to default values; LLDP remains enabled, and all the
configured TLVs are still advertised.
To leave LLDP enabled, but reset the advertised TLVs to the five default TLVs, use the following
command, and specify the affected ports:
unconfigure lldp port [all | <port_list>]
172
transmit interval
transmit hold multiplier
transmit delay
SNMP notification interval
reinitialize delay
:
:
:
:
:
30 seconds
4 (used TTL = 120 seconds)
2 seconds
5 seconds
2 seconds
Rx
Tx
SNMP
Optional enabled transmit TLVs
Mode
Mode
Notification LLDP
802.1 802.3
============================================================================
1:1
Enabled
Enabled
Disabled
PNDCM PpNM-LF
2:2
Enabled
Enabled
Disabled
--D-- ------=============================================================================
LLDP Flags : (P) Port Description, (N) System Name, (D) System Description
(C) System Capabilities, (M) Mgmt Address
802.1 Flags: (P) Port VLAN ID, (p) Port & Protocol VLAN ID, (N) VLAN Name
802.3 Flags: (M) MAC/PHY Configuration/Status, (P) Power via MDI
(L) Link Aggregation, (F) Frame Size
The following sample output is from the show lldp port 1 detailed command:
# show lldp port 1 detailed
LLDP
LLDP
LLDP
LLDP
LLDP
transmit interval
transmit hold multiplier
transmit delay
SNMP notification interval
reinitialize delay
:
:
:
:
:
30 seconds
4 (used TTL = 120 seconds)
2 seconds
5 seconds
2 seconds
Rx
Tx
SNMP
Optional enabled transmit TLVs
Mode
Mode
Notification LLDP
802.1 802.3
============================================================================
1
Enabled
Enabled
Disabled
-ND-- --N---VLAN: Default
----- ------VLAN: voice
----- --N---=============================================================================
LLDP Flags : (P) Port Description, (N) System Name, (D) System Description
(C) System Capabilities, (M) Mgmt Address
802.1 Flags: (P) Port VLAN ID, (p) Port & Protocol VLAN ID, (N) VLAN Name
802.3 Flags: (M) MAC/PHY Configuration/Status, (P) Power via MDI
(L) Link Aggregation, (F) Frame Size
To display the statistical counters related to the LLDP port, use the show lldp statistics command.
The following is sample output from the show lldp statistics command:
# show lldp statistics
Last table change time
Number of Table Inserts
Number of Table Deletes
Number of Table Drops
Number of Table Age Outs
:
:
:
:
:
Port
Tx
Tx Length Rx
Rx
Rx
TLVs
TLVs
Total
Exceeded
Total Discarded
Errors
Discarded
Unrecogn.
===================================================================================
1:1
189
0
5654
0
0
0
0
2:2
188
0
565
0
0
0
0
173
NOTE
The Tx Length Exceeded column shows the number of LLDPDUs sent from the port that dropped configured optional
TLVs to meet the 1500-byte limit for the LLDPDU.
For detailed LLDP neighbor information for all switch ports, use the show lldp neighbors detailed
command. The following is sample output from this command:
# show lldp all neighbors detailed
----------------------------------------------------------------------------LLDP Port 4:1 detected 2 neighbors
Neighbor: 00:04:96:10:51:81/1:2, age 29 seconds
- Chassid ID Type: MAC Address (4)
Chassis ID
: "00:04:96:10:51:81"
- Port ID Type: ifName (5)
Port ID
: "1:2"
- Time to Live: 120 seconds
Neighbor: 00:30:48:42:F3:12/1:1, age 1 seconds
- Chassis ID type: MAC address (4)
Chassis ID
: 00:30:48:42:F3:12
- Port ID type: ifName (5)
Port ID
: "1:1"
- Time To Live: 120 seconds
- Port Description: Port-2-Internet
- System Name: CoreSwitch01
- System Description: "ExtremeWare X0S version 11.2.0.0 branch-shasta7_v\
1111b7 by eelco on Tue Dec 14 09:51:30 CET 2004"
- System Capabilities : "Bridge, Router"
Enabled Capabilities: "Bridge"
----------------------------------------------------------------------------LLDP Port 4:2 detected 1 neighbor
Neighbor: 00:04:96:10:51:80/1:2, age 60 seconds
- Chassid ID Type: MAC Address (4)
Chassis ID
: "00:04:96:10:51:80"
- Port ID Type: ifName (5)
Port ID
: "1:1"
- Time to Live: 120 seconds
174
Connectivity Fault Management (CFM), discussed in the emerging IEEE 802.1ag specification, allows
you to detect, verify, and isolate connectivity failures in virtual bridged LANs. Part of this specification
is a toolset to manually check connectivity, which is sometimes referred to as Layer 2 ping.
NOTE
The ExtremeWare XOS implementation of CFM is based on draft 4.1 of the IEEE 802.1ag standard.
There is no direct interaction between CFM and other Layer 2 protocols; however, blocked Spanning
Tree Protocol (STP) ports are taken into consideration when forwarding CFM messages.
This chapter describes the following topics:
You create hierarchical networks, or domains, and test connectivity within that domain by sending
Layer 2 messages, known as Connectivity Check Messages (CCMs).
175
Customer
MA level
ISP
ISP
Operator
ISP
ISP
Customer
CFMs
EX_116A
NOTE
The arrows in Figure 5 indicate the span that CCM messages take, not the direction. (See Table 20 for more
information on spans for CCM messages.)
To achieve this hierarchical connectivity testing, you create and configure the following entities:
Maintenance association (MA) level; a unique hierarchical numeric value for each domain
Maintenance end points (MEPs), which are one of the following types:
- Inward-facing MEPs
- Outward-facing MEPs
You must have at least one MP on an intermediate switch in your domain. Ensure that you map and
configure all ports in your domain carefully, especially the inward-facing MEPs and the outward-facing
MEPs. If these are incorrectly configured, the CCMs are sent in the wrong direction in your network,
and you will not be able to test the connectivity within the domain.
You can have up to eight domains on an Extreme Networks switch. A domain is the network or part of
the network for which faults are to be managed; it is that section where you are monitoring Layer 2
connectivity. A domain is intended to be fully connected internally.
NOTE
Domains may cross VR boundaries; domains not virtual router-aware.
176
All CFM messages with a superior MA level (numerically lower) pass throughout domains with an
inferior MA level (numerically higher). CFM messages with an inferior MA level are not forwarded to
domains with a superior MA level. Refer to Table 20 for an illustration of domains with hierarchical MA
levels.
Use
Customer
Superiority
Most
superior
Service provider
< ----- Superior / Inferior ----- >
Operator
Most
inferior
Within a given domain, you associate maintenance associations (MAs). Extreme Networks
implementation of CFM associates MAs with VLANs. All of the ports in that VLAN are now in that MA
and its associated domain. In general, you should configure one MIP on each intermediate switch in the
domain and a MEP on every edge switch.
Each MA associates with one VLAN, and each VLAN associates with one MA. Thus, you can have a
total of 4096 MAs on a switch (each associated with 1 of 8 possible domains). The MA is unique within
the domain. You can configure up to 4096 MAs in any 1 domain. One switch can have 8 domains, 128
ports, 4096 associations (see Supported Instances for CFM on page 179 for supported CFM elements).
If you attempt to put 1 MA into 2 domains, the system returns an error message.
NOTE
You cannot associate the Management VLAN with an MA or a domain.
NOTE
If you configured MAC-in-MAC on a port or have an untagged VMAN on that port, you cannot configure CFM on that
port.
You assign the MPs to ports: inward-facing MEPs, outward-facing MEPs, MIPs, and CFFs. These
various MPs filter or forward the CFM messages to test the connectivity of your network.
177
The inward-facing MEPs potentially sends the CCM message to all ports on the VLAN (MA)
except the sending portdepending on the MPs configured on the outgoing ports.
NOTE
Ensure that you configured the inward-facing and outward-facing MEPs correctly, or the CCMs will flow in the wrong
through the domain and not allow connectivity testing.
MIPs define intermediate points within a domain. MIPs relay the CCM messages to the next MIP or
MEP in the domain. MIPs look at the CCM and pass it along.
You configure the time interval for each MEP to send a CCM. Extreme Networks recommends setting
this interval for at least 1 second. Each MEP also makes a note of what port and what time it received a
CCM. This information is stored in the CCM database. The CCM database holds up to 64 entries per
MEP; after that, additional CCM messages are discarded.
Each CCM has a time-to-live (TTL) value also noted for that message. This TTL interval is 3.5 times the
CCM transmission interval you configured on the switch that is originating the CCM. After the TTL
expires, the connectivity is considered broken, and the system sends a message to the log. One
important result of the continual transmission of CCM frames is that the MAC address of the
originating MEP is known to all MPs in the association.
NOTE
You must configure the following EMS filter to capture the messages on the log: configure log filter
DefaultFilter add events cfm.rMEPExp. See Chapter for Chapter 9 for complete information on
configuring EMS messages.
The MA values are from 0 to 7; in the hierarchy, the MA level of 0 is highest and 7 is lowest. CFFs
configured on a port block all inward and outward CCM messages with an equal or inferior MA level
(higher MA value of 0 to 7) than the MA level of the domain that CFF is in. A CFF port passes every
CFM packet that has a superior MA level (lower MA value of 0 to 7) in both directions.
Not all combinations of MPS are allowed on the same port within an MA; only the following
combinations can be on the same port within an MA:
178
Limit
Notes
Domains
Associations (MAs)
4096
Per switch
Inward-facing MEPs
32
Per switch
Outward-facing MEPs
32
Per switch
MIPs
32
Per switch
128
64
There is no limit on the CFFs. Additionally, ExtremeWare XOS 11.4 does not support CFM traps, MIBs,
or alarm suppression.
NOTE
The total number of CFM ports is a guideline, not a limit enforced by the system.
Configuring CFM
To configure CFM, you create a maintenance domain and assign it a unique MA level. Next, you
associate MAs with the specified domain and assign MPs within that MA. Optionally, you can configure
the transmission interval for the CCMs.
179
NOTE
Enhanced ACLs are automatically applied when you configure CFM using the CLI commands. These ACLs are
displayed when you issue the command show access-list dynamic.
Whatever convention you choose, you must use that same format throughout the entire domain.
The CFM messages carry the domain name, so the name and naming format must be identical to be
understood throughout the domain. You can, however, use different naming conventions on different
domains on one switch (up to eight domains allowed on one switch).
180
Configuring CFM
To create a domain and assign an MA level using the ITU-T M.1400 carrier code convention, use the
following CLI command:
create cfm domain m1400 <name> ma-level <level>
To create a domain and assign an MA level using the ISO 3166 country code convention, use the
following CLI command:
create cfm domain iso3166 <name> ma-level <level>
To create a domain and assign an MA level using the DNS convention, use the following CLI command:
create cfm domain dns <name> ma-level <level>
To create a domain and assign an MA level using the MAC address convention, use the following CLI
command:
create cfm domain mac <mac> <int> ma-level <level>
To create a domain and assign an MA level using the RFC 2685 VPN ID convention, use the following
CLI command:
create cfm domain vpn-id oui <oui> index <index> ma-level <level>
Although you assign an MA level to the domain when you create that domain, you can change the MA
level on an existing domain by using the following command:
configure cfm domain <domain_name> ma-level <level>
Character string
2-octet integer
To add an MA to a domain using the character string format, use the following command:
configure cfm domain <domain_name> add association string <name> vlan <vlan_name>
To add an MA to a domain using the 2-octet integer format, use the following command:
configure cfm domain <domain_name> add association integer <int> vlan <vlan_name>
181
Maintenance end points (MEPs), which are one of the following types:
Each MEP must have an ID that is unique for that MEP throughout the MA.
Not all combinations of MPS are allowed on the same port within an MA; only the following
combinations can be on the same port within an MA:
Ensure that you configured the inward-facing and outward-facing MEPs correctly, or the CCMs will flow in the wrong
through the domain and not allow connectivity testing.
To configure inward-facing and outward-facing MEPs and its unique MEP ID, use the following
command:
configure cfm domain <domain_name> association <association_name> ports <port_list>
add end-point [inward-facing | outward-facing ] <mepid>
182
Displaying CFM
To configure a MIP, use the following command:
configure cfm domain <domain_name> association <association_name> ports <port_list>
add intermediate-point
To configure the transmission interval for the MEP to send CCMs, issue the following command:
configure cfm domain <domain_name> association <association_name> ports <port_list>
end-point [inward-facing | outward-facing] transmit-interval <interval>
NOTE
You must have all the CFM parameters configured on your network before issuing the ping and traceroute messages.
To send a Link Trace Message (LTM) and receive information on the path, use the following command:
traceroute mac <mac> {inward-facing-end-point} port <port> {domain} <domain_name>
{association} <association_name> {ttl <ttl>}
Displaying CFM
To verify your CFM configuration, you can display the current CFM configuration using the show cfm
command. The information this command displays includes the total ports configured for CFM, the
domain names and MA levels, the MAs and associated VLANs, and the inward-facing and outwardfacing MEPs.
183
To display the CCM database for each MEP, use the show cfm detail command. The following is
sample output from this command:
Domain/
Port
MP Remote End-Point
MEP
Life
Association
MAC Address
ID
time
Age
===============================================================================
dnsname
short ma name
1:1
IE 00:30:48:42:f3:12 43
3500
770
1:1
IE 00:30:48:42:f1:68 69
3500
380
2:1
IE 00:30:48:42:f3:12 12
3500
570
2:1
IE 00:30:48:42:f1:68 69
3500
380
===============================================================================
Maintenance Point: (IE) Inward-Facing End-Point, (OE) Outward-Facing End-Point
NOTE: The Domain and Association names are truncated to 28 characters, Lifetime
and Age are in milliseconds.
To display statistics on the CFM functioning on the switch, use the show cfm statistics command.
The following is sample output from this command:
Domain/
Port
MP eff_level_in/ iff_level_in/ iff_opcode
Association
eff_level_out iff_level_out
===============================================================================
dnsname
short ma name
2:1
IE 0
0
0
0
0
2:1
OE 0
0
0
2:2
FF 396
0
===============================================================================
Maintenance Point: (IE) Inward-Facing End-Point, (I) Intermediate-Point,
(OE) Outward-Facing End-Point, (FF) Filter-Function
NOTE: The Domain and Association names are truncated to 28 characters, also the
counters displayed are software counters, i.e. packets blocked by
hardware are not included.
184
CFM Example
CFM Example
As shown in Figure 6, this examples assumes a simple network; this example assumes that CFM is
configured on the access switches, as well as the necessary VLANs configured with the ports added.
1:1
1:1
Switch 1
1:2
Switch 2
1:1
Switch 3
= Inward MEP
= Outward MEP
= Intermediate point
EX_111A
To configure switch 1 for this example, use the following CLI commands:
configure cfm domain corp add association string core vlan corenet
configure cfm domain corp association core ports 1:1 add end-point outward-facing
101
To configure switch 2 for this example, use the following CLI commands:
configure cfm domain corp add association string core vlan corenet
configure cfm domain corp association core ports 1:1 add intermediate-point
configure cfm domain corp association core ports 1:2 add intermediate-point
configure cfm domain corp association core ports 1:3 add end-point inward-facing
102
To configure switch 3 for this example, use the following CLI commands:
configure cfm domain corp add association string core vlan corenet
configure cfm domain corp association core ports 1:1 add end-point outward-facing
103
185
186
Power over Ethernet (PoE) is an effective method of supplying 48 VDC power to certain types of
powered devices (PDs) through Category 5 or Category 3 twisted pair Ethernet cables. PDs include
wireless access points, IP telephones, laptop computers, web cameras, and other devices. With PoE, a
single Ethernet cable supplies power and the data connection, reducing costs associated with separate
power cabling and supply.
NOTE
You must have the G48P module installed in the BlackDiamond 8800 family of switches to run PoE.
Beginning with ExtremeWare XOS version 11.3, the system supports hitless failover for PoE in a system
with two Master Switch Modules (MSMs). Hitless failover means that if the primary MSM fails over to
the backup MSM, all port currently powered will maintain power after the failover and all the power
configurations remain active.
NOTE
The BlackDiamond 8800 family of switches was formerly known as Aspen.
Configuration and control of the power distribution for PoE at the system, slot, and port levels
Real-time discovery and classification of 802.3af-compliant PDs and many legacy devices
Monitor and control of port PoE fault conditions including exceeding configured class limits and
power limits and short-circuit detection
Support for configuring and monitoring PoE status at the system, slot, and port levels
187
If a PoE module is inserted into a chassis, the chassis calculates the power budget and only powers up
the PoE module if there is enough power. Installed modules are not affected. However, if you reboot the
chassis, power checking proceeds as described in the previous paragraph. If there is now enough power,
I/O modules that were not powered up previously are powered up.
If you lose power or the overall available power decreases, the system removes power to the I/O
modules beginning with the highest numbered slots until enough power is available. Inline power
reserved for a slot that is not used cannot be used by other PoE slots (inline power is not shared among
PoE modules).
Before you install your PoE module, consult your sales team to determine the required power budget.
Power Delivery
This section describes how the system provides power to the PDs.
Disabling inline power removes power immediately to all connected PDs. The default value is enabled.
188
Power Delivery
NOTE
Extreme Networks recommends that you fully populate a single PoE module with PDs until the power usage is just
below the usage threshold, instead of spacing PDs evenly across PoE modules.
To reserve the power budget for the PoE module slot, use the following command:
configure inline-power budget <num_watts> slot <slot>
If you disable a slot with a PoE module, the reserved power budget remains with that slot until you
unconfigure or reconfigure the power budget. Also, you can reconfigure the reserved power budget for
a PoE module without disabling the slot first; you can reconfigure dynamically.
These settings are preserved across reboots and other power-cycling conditions.
The total of all reserved slot power budgets cannot be larger than the total available power to the
switch. If the base module power requirements plus the reserved PoE power for all modules exceeds
the unallocated power in the system, the lowest numbered slots have priority in getting power and one
or more modules in higher-numbered slots will be powered down.
NOTE
PoE modules are not powered-up at all, even in data-only mode, if the reserved PoE power cannot be allocated to
that slot.
To reset the reserved power budget for a slot to the default value of 50 W, use the following command:
unconfigure inline-power budget slot <slot>
PD Disconnect Precedence
After a PD is discovered and powered, the actual power drain is continuously measured, If the usage
for power by PDs is within 19 W of the reserved power budget for the PoE module, the system begins
denying power to PDs.
To supply power to all PDs, you can reconfigure the reserved power budget for the slot, so that enough
power is available to power all PDs. You reconfigure the reserved power budget dynamically; you do
not have to disable the slot to reconfigure the power budget.
189
Disconnect PDs according to the configured PoE port priority for each device.
Deny power to the next PD requesting power, regardless of that ports PoE priority.
This is a switchwide configuration that applies to each slot; you cannot configure this disconnect
precedence per slot.
The default value is deny-port. So, if you do not change the default value and the slots power is
exceeded, the next PD requesting power is not connected (even if that port has a higher configured PoE
port priority than those ports already receiving power). When you configure the deny-port value, the
switch disregards the configured PoE port priority and port numbering.
When the switch is configured for lowest-priority mode, PDs are denied power based on the ports
configured PoE priority. If the next PD requesting power is of a higher configured PoE priority than an
already powered port, the lower-priority port is disconnected and the higher-priority port is powered.
To configure the disconnect precedence for the switch, use the following command:
configure inline-power disconnect-precedence [deny-port | lowest-priority]
To reset the disconnect precedence value to the default value of deny port to the switch, use the
following command:
unconfigure inline-power disconnect-precedence
To reset the PoE priority of the ports to the default value of low, use the following command:
unconfigure inline-power priority ports [all | <port_list>]
If several PDs have the same configured PoE port priority, the priority is determined by the port
number. The highest port number has the lowest PoE priority.
The switch withdraws power (or disconnects) those ports with the highest port number (s). That is, the
highest port number is the lowest PoE priority.
190
Power Delivery
again, available only to other ports on the same slot; it cannot be redistributed to other slots. The port
stays in the fault state until you disable that port, or disconnect the attached PD, or reconfigure the
operator limit to be high enough to satisfy the PD requirements.
To display the status of PoE ports, including disconnected or faulted ports, use the following command:
show inline-power info ports
When a port is disconnected or otherwise moves into a fault state, SNMP generates an event (after you
configure SNMP and a log message is created).
Ports are immediately depowered and repowered, maintaining current power allocations.
To reset the threshold that causes the system to generate an SNMP event and EMS message per slot to
70% for measured power compared to budgeted power, use the following command:
unconfigure inline-power usage-threshold
Legacy Devices
ExtremeWare XOS software allows the use of non-standard PDs with the switch. These are PDs that do
not comply with the IEEE 802.3af standard.
191
The system unsuccessfully attempted to discover the PD using the standard resistance measurement
method.
To enable the switch to use legacy PDs, use the following command:
enable inline-power legacy slot <slot>
To disable the non-standard power detection method that allows the switch to use legacy PDs, use the
following command:
disable inline-power legacy slot <slot>
If the measured power for a specified port exceeds the ports operator limit, the power is withdrawn
from that port and the port moves into a fault state.
To reset the power limit allowed for PDs to the default value of 15.4 W per port, use the following
command:
unconfigure inline-power operator-limit ports [all |<port_list>]
If you attempt to set an operator-limit outside the accepted range, the system returns an error message.
LEDs
Individual port LEDs on the PoE module also indicate the inline power status of each port (Table 22).
192
Port Power
Port Disabled
Port Enabled:
Link Down
Port Enabled:
Link Up
Activity
Device powered
Slow blinking
amber
Slow blinking
amber
Solid amber
Blinking amber
Blinking
amber/green
Blinking
amber/green
Blinking
amber/green
Blinking amber/
green
Nonpowered device
Slow blinking
green
Off
Solid green
Blinking green
Configuring PoE
Configuring PoE
PoE on the G48P module supports a full set of configuration and monitoring commands that allow you
configure, manage, and display PoE settings at the system, slot, and port level. Refer to the ExtremeWare
XOS Command Reference Guide for complete information on using the CLI commands.
To enable inline power, or PoE, you must have a powered chassis and module.
NOTE
If your chassis has an inline power module and there is not enough power to supply a slot, that slot will not power
on; the slot will not function in data-only mode without enough power for inline power.
To configure inline power, or PoE, you must accomplish the following tasks:
Configure the disconnect precedence for the PDs in the case of excessive power demands.
Additionally, you can configure the switch to use legacy PDs, apply specified PoE limits to ports, apply
labels to PoE ports, and configure the switch to allow you to reset a PD without losing its power
allocation.
NOTE
If your chassis has an inline power module and there is not enough power to supply a slot, that slot will not power
on; the slot will not function in data-only mode without enough power for inline power.
To disable inline power to the switch, slot, or port, use the following commands:
disable inline-power
disable inline-power slot <slot>
disable inline-power ports [all | <port_list>]
Disabling the inline power to a PD immediately removes power from the PD.
To display the configuration for inline power, use the following command:
show inline-power
193
The default power budget is 50 W per slot, and the maximum is 768 W. The minimum reserved power
budget you can configure is 37 W for an enabled slot. If inline power on the slot is disabled, you can
configure a power budget of 0.
NOTE
Extreme Networks recommends that you fully populate a single PoE module with PDs until the power usage is just
below the usage threshold, instead of spacing PDs evenly across PoE modules.
To reset the power budget for a PoE module to the default value of 50 W, use the following command:
unconfigure inline-power budget slot <slot>
To display the reserved power budget for the PoE modules, use the following command:
show inline-power slot <slot>
When the actual power used by the PDs on a slot exceeds the power budgeted for that slot, the switch
refuses power to PDs. There are two methods used by the switch to refuse power to PDs, and
whichever method is in place applies to all PoE slots in the switch. This is called the disconnect
precedence method, and you configure one method for the entire switch.
The available disconnect precedence methods are:
Deny port
Lowest priority
The default value is deny port. Using this method, the switch simply denies power to the next PD
requesting power from the slot, regardless of that ports PoE priority or port number.
Using the lowest priority method of disconnect precedence, the switch disconnects the PDs connected to
ports configured with lower PoE priorities. (Refer to Configuring the PoE Port Priority for
information on port priorities.)
194
Configuring PoE
When several ports have the same PoE priority, the lower port numbers have higher PoE priorities. That
is, the switch withdraws power (or disconnects) those ports with the highest port number(s).
The system keeps dropping ports, using the algorithm you selected with the disconnect ports command,
until the measured inline power for the slot is lower than the reserved inline power.
To configure the disconnect precedence for the switch, use the following command:
configure inline-power disconnect-precedence [deny-port | lowest-priority]
To return the disconnect precedence to the default value of deny port, use the following command:
unconfigure inline-power disconnect-precedence
To display the currently configured disconnect precedence, use the following command:
show inline-power
To reduce the chances of ports fluctuating between powered and non-powered states, newly inserted
PDs are not powered when the actual delivered power for the module is within approximately 19 W of
the configured inline power budget for that slot. However, actual aggregate power can be delivered up
to the configured inline power budget for the slot (for example, when delivered power from ports
increases or when the configured inline power budget for the slot is reduced).
To reset the port priority to the default value of low, use the following command:
unconfigure inline-power priority ports [all | <port_list>]
195
To display the currently configured usage threshold, use the following command:
show inline-power
The switch unsuccessfully attempted to discover the PD using the standard resistance measurement
method.
To enable the switch to detect legacy, non-standard PDs, use the following command:
enable inline-power legacy slot <slot>
To reset the switch to the default value, which does not detect legacy PDs, use the following command:
disable inline-power legacy slot <slot>
196
To reset the operator limit to the default value of 15.4 W, use the following command:
unconfigure inline-power operator-limit ports [all |<port_list>]
To display the current operator limit on each port, use the following command:
show inline-power configuration ports <port_list>
Clearing Statistics
You can clear the PoE statistics for specified ports or for all ports. To clear the statistics and reset the
counters to 0, use the following command:
clear inline-power stats ports [all | <port_list>]
197
Configured inline power statusThe status of the inline power for the switch: enabled or disabled.
System power surplusThe surplus amount of power on the system, in watts, available for
budgeting.
Redundant power surplusThe amount of power on the system, in watts, available for budgeting if
one power supply is lost.
System power usage thresholdThe configured power usage threshold for each slot, shown as a
percentage of budgeted power. After this threshold has been passed on any slot, the system sends an
SNMP event and logs a message.
Disconnect precedenceThe method of denying power to PDs if the budgeted power on any slot is
exceeded.
Legacy modeThe status of the legacy mode, which allows detection of non-standard PDs.
The output indicates the following inline power status information for each slot:
Inline power statusThe status of inline power. The status conditions are:
Enabled
Disabled
Firmware statusThe operational status of the slot. The status conditions are:
Operational
Not operational
Disabled
Subsystem failure
Slot disabled
Budgeted powerThe amount of inline power, in watts, that is reserved and available to the slot.
Measured powerThe amount of power, in watts, that is currently being used by the slot.
System Information
Enabled
1500 Watts available for budgeting
465 Watts available for budgeting to maintain N+1
70 percent (per slot)
lowest-priority
Disabled
Budgeted
Measured
Slot Inline-Power Firmware Status
Power (Watts) Power (Watts)
3
Enabled
Operational
50 W
9 W
4
Enabled
Card Not Present
( 50 W)
n/a
7
Enabled
Operational
50 W
0 W
Note: A budget value in parentheses is not allocated from the system power
budget because the card is not present, or the slot is disabled.
198
The term 2% loss shown in this display is the 2% associated with powering PDs. For example, when
you reserve 50 W for a particular slot, the system reserves 51 W.
NOTE
Refer to the ExtremeWare XOS Command Reference Guide for more detailed explanation of the show power
budget display.
199
Inline power statusThe status of inline power. The status conditions are:
Enabled
Disabled
Firmware statusThe operational status of the slot. The status conditions are:
Operational
Not operational
Disabled
Subsystem failure
Slot disabled
Measured powerThe amount of power, in watts, that is currently being used by the slot.
Inline-Power
Enabled
Firmware Status
Operational
Budgeted
Power (Watts)
80 W
Measured
Power (Watts)
65 W
200
Operational
Not operational
Disabled
Subsystem failure
Slot disabled
Total ports awaiting powerDisplays the number of remaining ports in the slot that are not
powered
: Operational
: 292b1
Total
Total
Total
Total
:
:
:
:
ports
ports
ports
ports
powered
awaiting power
faulted
disabled
17
31
0
0
Operator LimitDisplays the configured limit, in milliwatts, for inline power on the port.
PriorityDisplays inline power priority of the port, which is used to determine which ports get
power when there is insufficient power for all ports requesting power:
Low
High
Critical
LabelDisplays a text string, if any, associated with the port (15 characters maximum).
Config
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Operator
15000
15000
15000
15000
15000
15000
15000
15000
15000
15000
Limit
mW
mW
mW
mW
mW
mW
mW
mW
mW
mW
Priority
Low
Low
Low
Low
Low
Low
Low
Low
Low
Low
Label
201
202
Disabled
Searching
Delivering
Faulted
Disconnected
Other
Denied
VoltsDisplays the measured voltage. A value from 0 to 2 is valid for ports that are in a searching
or discovered state.
None
UV/OV fault
UV/OV spike
Over current
Overload
Undefined
Underload
HW fault
Disconnect
Force on error
Label
Operator Limit
PD Class
Measured Power
Line Voltage
Current
Fault Status
Detailed Status
Priority
The following is sample output from the show inline-power info port command:
Port
State
Class
Volts
3:1
3:2
3:3
delivering
delivering
searching
class3
class3
------
48.3
48.3
0.0
Curr
(mA)
192
192
0
Power
(Watts)
9.300
9.300
0.0
Fault
None
None
None
The following is sample output from the show inline-power info detail port command:
Port 3:1
Configured Admin State:
Inline Power State
:
MIB Detect Status
:
Label
:
Operator Limit
:
PD Class
:
Max Allowed Power
:
Measured Power
:
Line Voltage
:
Current
:
Fault Status
:
Detailed Status
:
Priority
:
enabled
delivering
delivering
16800 milliwatts
class3
15.400 W
9.400 W
48.3 Volts
193 mA
None
low
Disabled
203
Searching
Delivering
Faulted
Disconnected
Other
Denied
204
State
delivering
delivering
searching
searching
searching
searching
searching
searching
searching
searching
Class
class3
class3
class0
class0
class0
class0
class0
class0
class0
class0
STATISTICS COUNTERS
Absent InvSig
Denied
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
OverCurrent
18
0
0
0
0
0
0
0
0
0
Short
0
0
0
0
0
0
0
0
0
0
Viewing statistics on a regular basis allows you to see how well your network is performing. If you
keep simple daily records, you can see trends emerging and notice problems arising before they cause
major network faults. In this way, statistics can help you get the best out of your network.
205
Not Present (NP)The port is configured, but the module is not installed in the slot (modular
switches only).
Transmitted Packet Count (Tx Pkt Count)The number of packets that have been successfully
transmitted by the port.
Transmitted Byte Count (Tx Byte Count)The total number of data bytes successfully transmitted
by the port.
Received Packet Count (Rx Pkt Count)The total number of good packets that have been received
by the port.
Received Byte Count (RX Byte Count)The total number of bytes that were received by the port,
including bad or lost frames. This number includes bytes contained in the Frame Check Sequence
(FCS), but excludes bytes in the preamble.
Received Broadcast (RX Bcast)The total number of frames received by the port that are addressed
to a broadcast address.
Received Multicast (RX Mcast)The total number of frames received by the port that are addressed
to a multicast address.
206
Not Present (NP)The port is configured, but the module is not installed in the slot (modular
switches only).
Transmit Collisions (TX Coll)The total number of collisions seen by the port, regardless of whether
a device connected to the port participated in any of the collisions.
Transmit Late Collisions (TX Late Coll)The total number of collisions that have occurred after the
ports transmit window has expired.
Transmit Deferred Frames (TX Deferred)The total number of frames that were transmitted by the
port after the first transmission attempt was deferred by other network traffic.
Transmit Errored Frames (TX Errors)The total number of frames that were not completely
transmitted by the port because of network errors (such as late collisions or excessive collisions).
Transmit Lost Frames (TX Lost)The total number of transmit frames that do not get completely
transmitted because of buffer problems (FIFO underflow).
Transmit Parity Frames (TX Parity)The bit summation has a parity mismatch.
Port Number
Not Present (NP)The port is configured, but the module is not installed in the slot (modular
switches only).
Receive Bad CRC Frames (RX CRC)The total number of frames received by the port that were of
the correct length but contained a bad FCS value.
Receive Oversize Frames (RX Over)The total number of good frames received by the port greater
than the supported maximum length of 1,522 bytes.
Receive Undersize Frames (RX Under)The total number of frames received by the port that were
less than 64 bytes long.
Receive Fragmented Frames (RX Frag)The total number of frames received by the port that were
of incorrect length and contained a bad FCS value.
Receive Jabber Frames (RX Jabber)The total number of frames received by the port that were
greater than the support maximum length and had a Cyclic Redundancy Check (CRC) error.
Receive Alignment Errors (RX Align)The total number of frames received by the port with a CRC
error and not containing an integral number of octets.
Receive Frames Lost (RX Lost)The total number of frames received by the port that were lost
because of buffer overflow in the switch.
207
Description
[Esc]
[Space]
Table 24 describes the keys used to control the displays that appear if you use any of the show ports
commands and specify the no-refresh parameter.
Description
[Space]
208
Application-Specific Integrated Circuit (ASICs) and Central Processing Unit (CPUs) operate as
required.
Before running slot diagnostics on a modular switch, you must have at least one MSM installed in the chassis.
Running Diagnostics on the BlackDiamond 10K Switch and the BlackDiamond 8800 Family of
Switches on page 209
209
extendedTakes the switch fabric and ports offline and performs extensive ASIC, ASIC-memory,
and packet loopback tests. Extended diagnostic tests take a maximum of 15 minutes. The CPU is not
tested. Console access is available during extended diagnostics.
normalTakes the switch fabric and ports offline and performs a simple ASIC and packet loopback
test on all ports.
<slot>Specifies the slot number of an I/O module. When the diagnostics test is complete, the
system attempts to bring the I/O module back online.
NOTE
On the BlackDiamond 8810 switch (formerly known as Aspen), if you run diagnostics on slots 5 and 6 with an
MSM installed in those slots, the diagnostic routine tests the I/O subsystem of the MSM. To run diagnostics on
the management portion of the master MSM, specify slot A or B.
A | BSpecifies the slot letter of the primary MSM. The diagnostic routine is performed when the
system reboots. Both switch fabric and management ports are taken offline during diagnostics.
BlackDiamond 8800 Family of Switches OnlyBefore running diagnostics on a module, you can use the
disable slot <slot> offline command to force the module to enter the offline state which takes the
switch fabric and ports offline. If you run diagnostics on a module that is not offline, the switch
automatically takes the switch fabric and ports offline when you use the run diagnostics [extended
| normal] {slot [<slot> | A | B]} command.
After the diagnostic routine has finished, use the enable slot <slot> command to bring the module
back online and operational.
210
extendedTakes the switch fabric and ports offline and performs extensive ASIC, ASIC-memory,
and packet loopback tests. Extended diagnostic tests take a maximum of 25 minutes. The CPU is not
tested. Console access is available during extended diagnostics.
normalTakes the switch fabric and ports offline and performs a simple ASIC and packet loopback
test on all ports. Normal diagnostic tests take a minimum of 5 minutes.
To run diagnostics on the backup MSM, you must failover to the backup MSM, thereby relinquishing
primary MSM status to the backup. After failover, you can run diagnostics on the new primary MSM.
Remember, the diagnostic routine runs on all of the installed I/O modules in addition to the new
primary MSM. For more detailed information about system redundancy and MSM failover, see
Understanding System Redundancy with Dual MSMs InstalledModular Switches Only on page 72.
extendedReboots the switch and performs extensive ASIC, ASIC-memory, and packet loopback
tests. Extended diagnostic tests take a maximum of 5 minutes. The CPU is not tested.
normalReboots the switch and performs a simple ASIC and packet loopback test on all ports.
Color
Indicates
DIAG
Amber blinking
Amber
Amber blinking
Status
211
Color
Indicates
SYS
Amber blinking
Amber
After the MSM completes the diagnostic test, or the diagnostic test is terminated, the SYS LED is reset.
During normal operation, the status LED blinks green.
Table 27: BlackDiamond 8800 family of switches I/O module LED behavior
LED
Color
Indicates
DIAG
Amber blinking
Amber
Green
Amber blinking
Off
Stat
After the I/O module completes the diagnostic test, or the diagnostic test is terminated, the DIAG and
the Status LEDs are reset. During normal operation, the DIAG LED is off and the Status LED blinks
green.
Table 28: BlackDiamond 8800 family of switches MSM LED behavior during diagnostic test on
primary MSM
MSM
LED
Color
Indicates
Primary
ERR
Off
212
Table 28: BlackDiamond 8800 family of switches MSM LED behavior during diagnostic test on
primary MSM (Continued)
MSM
LED
Color
Indicates
ENV
Off
Mstr/Diag
Amber blinking
Green/Off
Off/Green
Sys/Stat
Off/Off
Backup
ERR
Amber/Green
blinking
Off
ENV
Off
Mstr/Diag
Sys/Stat
Off/Off
Green/Green
Green/Off
Off/Green blinking
Off/Off
Amber/Green
blinking
Table 29 describes the BlackDiamond 8800 family of switches MSM LED behavior during a diagnostic
test on the backup MSM.
Table 29: BlackDiamond 8800 family of switches MSM LED behavior during diagnostic test on
backup MSM
MSM
LED
Color
Indicates
Backup
ERR
Off
ENV
Off
213
Table 29: BlackDiamond 8800 family of switches MSM LED behavior during diagnostic test on
backup MSM (Continued)
MSM
LED
Color
Indicates
Mstr/Diag
Off/Green
Sys/Stat
Primary
ERR
Off/Green
Off/Off
Amber
ENV
Off
Mstr/Diag
Green/Off
Sys/Stat
Off/Green blinking
Color
Indicates
DIAG
Amber blinking
Amber
Amber blinking
Status
After the I/O modules complete the diagnostic test, or the diagnostic test is terminated, the DIAG and
the Status LEDs are reset. During normal operation, the DIAG LED is off and the Status LED blinks
green. If you start another diagnostic test, the LED returns to blinking amber.
214
Color
Indicates
SYS
Amber blinking
Amber
Off
MSTR
After the MSM completes the diagnostic test, or the diagnostic test is terminated, the SYS LED is reset.
During normal operation, the SYS LED blinks green.
Color
Indicates
MGMT
Green blinking
Amber blinking
Amber
While diagnostic tests are running, the MGMT LED blinks amber. If a diagnostic test fails, the MGMT
LED goes to solid amber. During normal operation, the MGMT LED blinks green.
NOTE
The slot, A, and B parameters are available only on modular switches.
215
BlackDiamond 10K
Polling is always enabled on the system and occurs every 60 seconds by default. The system health
checker polls and tracks the ASIC counters that collect correctable and uncorrectable packet memory
errors, checksum errors, and parity errors on a per ASIC basis. By reading and processing the
registers, the system health check detects and associates faults to specific system ASICs.
Backplane diagnostic packets are disabled by default. If you enable this feature, the system health
checker tests the packet path for a specific I/O module every 6 seconds by default. The MSM sends
and receives diagnostic packets from the I/O module to determine the state and connectivity. (The
other I/O modules with backplane diagnostic packets disabled continue polling every 60 seconds by
default.)
System health check errors are reported to the syslog. If you see an error, contact Extreme Networks
Technical Support.
216
Polling is always enabled on the system and occurs every 5 seconds by default. The polling value is
not a user-configured parameter. The system health check polls the control plane health between
MSMs and I/O modules, monitors memory levels on the I/O module, monitors the health of the
I/O module, and checks the health of applications and processes running on the I/O module. If the
system health checker detects an error, the health checker notifies the MSM.
Backplane diagnostic packets are disabled by default. If you enable this feature, the system health
checker tests the data link for a specific I/O module every 5 seconds by default. The MSM sends and
receives diagnostic packets from the I/O module to determine the state and connectivity. If you
disable backplane diagnostics, the system health checker stops sending backplane diagnostic packets.
System health check errors are reported to the syslog. If you see an error, contact Extreme Networks
Technical Support.
BlackDiamond 10K and BlackDiamond 12804 switchesBy default, the system health checker tests
the packet path every 6 seconds for the specified slot.
BlackDiamond 8800 family of switchesBy default, the system health checker tests the data link
every 5 seconds for the specified slot.
NOTE
Enabling backplane diagnostic packets increases CPU utilization and competes with network traffic for resources.
BlackDiamond 10K and BlackDiamond 12804 switchesBy default, the system health checker
discontinues sending backplane diagnostic packets and returns the polling frequency to 60 seconds
on the specified slot. Only polling is enabled.
BlackDiamond 8800 family of switchesBy default, the system health checker discontinues sending
backplane diagnostic packets to the specified slot. Only polling is enabled.
217
NOTE
Extreme Networks does not recommend configuring an interval of less than the default interval. Doing so can cause
excessive CPU utilization.
Configures backplane diagnostic packets to be sent every 7 seconds and polling to occur every 7
seconds
When you enable backplane diagnostic packets on slot 3, the polling timer changes from its current
default value of 60 seconds to 6 seconds; 6 seconds is the default for sending backplane diagnostic
packets.
2 Configure backplane diagnostic packets to be sent every 7 seconds and update the polling rate to 7
seconds using the following command:
configure sys-health-check interval 7
NOTE
Extreme Networks does not recommend configuring an interval of less than 6 seconds. Doing this can cause
excessive CPU utilization.
Disabling Backplane Diagnostics. Building upon the previous example, the following example disables
backplane diagnostics on slot 3:
disable sys-health-check slot 3
218
When you enable backplane diagnostic packets on slot 3, the timer runs at the default rate of 5
seconds.
2 Configure backplane diagnostic packets to be sent every 7 seconds using the following command:
configure sys-health-check interval 7
NOTE
Extreme Networks does not recommend configuring an interval of less than 5 seconds. Doing this can cause
excessive CPU utilization.
Disabling Backplane Diagnostics. Building upon the previous example, the following example disables
backplane diagnostics on slot 3:
disable sys-health-check slot 3
Backplane diagnostic packets are no longer sent, but the configured interval for sending backplane
diagnostic packets remains at 7 seconds. The next time you enable backplane diagnostic packets, the
health checker sends the backplane diagnostics packets every 7 seconds.
To return to the "default" setting of 5 seconds, configure the frequency of sending backplane diagnostic
packets to 5 seconds using the following command:
configure sys-health-check interval 5
219
allConfigures ExtremeWare XOS to log an error into the syslog and automatically reboot the
system after any task exception.
noneConfigures the system to take no action is taken when a task exception occurs.
The default setting is all. Extreme Networks recommends using the default setting.
This command displays general switch information, including the system recovery level. The following
truncated output from a Summit X450 switch displays the system recovery setting (displayed as
Recovery Mode):
SysName:
SysLocation:
SysContact:
System MAC:
Recovery Mode:
System Watchdog:
TechPubs Lab
support@extremenetworks.com, +1 888 257 3000
00:04:96:1F:A4:0E
All
Enabled
NOTE
All platforms display the system recovery setting as Recovery Mode.
220
noneConfigures the MSM or I/O module to maintain its current state regardless of the detected
fault. The offending MSM or I/O module is not reset. ExtremeWare XOS logs fault and error
messages to the syslog.
resetSpecifies that the offending MSM or I/O module be reset upon fault detection. ExtremeWare
XOS logs fault, error, system reset, and system reboot messages to the syslog.
The default setting is reset. Extreme Networks recommends using the default setting.
To get the most from module recovery, Extreme Networks recommends using the default settings for
both system recovery and module recovery. The default setting for system recovery is all, and the
default setting for module recovery is reset. For more information about system recovery, see
Configuring System Recovery on page 220.
By using the default settings, the switch resets the offending MSM or I/O module if fault detection
occurs. An offending MSM is reset any number of times and is not permanently taken offline. On the
BlackDiamond 10K and BlackDiamond 12804 switches, an offending I/O module is reset a maximum of
three times. On the BlackDiamond 8800 family of switches, an offending I/O module is reset a
maximum of five times. After the maximum number of resets, the I/O module is permanently taken
offline.
reset
all
Single MSM
Dual MSM
221
I/O Module
reset
none
Single MSM
Dual MSM
I/O Module
If you configure the module recovery setting to none, the output displays an E flag that indicates no
corrective actions will occur for the specified MSM or I/O module. The E flag appears only if you
configure the module recovery setting to none.
Restarting the I/O moduleUse the disable slot <slot> command followed by the enable
slot <slot> command to restart the offending I/O module. By issuing these commands, the I/O
module and its associated fail counter is reset. If the module does not restart, or you continue to
experience I/O module failure, contact Extreme Networks Technical Support.
Running diagnosticsUse the run diagnostics normal <slot> command to run diagnostics on
the offending I/O module to ensure that you are not experiencing a hardware issue. If the module
continues to enter the failed state, please contact Extreme Networks Technical Support. For more
information about switch diagnostics, see Performing Switch Diagnostics on page 208.
222
Using ELSM
Using ELSM
ExtremeWare XOS 11.4 introduces support for the Extreme Link Status Monitoring (ELSM) protocol.
ELSM is an Extreme Networks proprietary protocol that monitors network health by detecting CPU and
remote link failures. ELSM is available only on Extreme Networks devices and operates on a point-topoint basis. You configure ELSM on the ports that connect to other network devices and on both sides
of the peer connection.
This section describes the following topics:
About ELSM
ELSM monitors network health by exchanging various hello messages between two ELSM peers. ELSM
uses an open-ended protocol, which means that an ELSM-enabled port expects to send and receive hello
messages from its peer. The Layer 2 connection between ports determines the peer connection. Peers can
be either directly connected or separated by one or more hubs. If there is a direct connection between
peers, they are considered neighbors.
If ELSM detects a failure, the ELSM-enabled port responds by blocking traffic on that port. For example,
if a peer stops receiving messages from its peer, ELSM brings down that connection by blocking all
incoming and outgoing data traffic on the port and notifying applications that the link is down.
In some situations, a software or hardware fault may prevent the CPU from transmitting or receiving
packets, thereby leading to the sudden failure of the CPU. If the CPU is unable to process or send
packets, ELSM isolates the connections to the faulty switch from the rest of the network. If the switch
fabric sends packets during a CPU failure, the switch may appear healthy when it is not. For example, if
hardware forwarding is active and software forwarding experiences a failure, traffic forwarding may
continue. Such failures can trigger control protocols such as Extreme Standby Router Protocol (ESRP) or
Ethernet Automatic Protection Switching (EAPS) to select different devices to resume forwarding. This
recovery action, combined with the CPU failure, can lead to loops in a Layer 2 network.
Configuring ELSM on Extreme Networks devices running ExtremeWare XOS is backward compatible
with Extreme Networks devices running ExtremeWare.
223
Hello+ The ELSM-enabled port receives a hello message from its peer and no problem is detected.
Hello- The ELSM-enabled port has not received a hello message from its peer.
In addition to the ELSM port states described in the next section, ELSM has hello transmit states. The
hello transmit states display the current state of transmitted ELSM hello messages and can be one of the
following:
HelloRx(+)The ELSM-enabled port is up and receives Hello+ messages from its peer. The port
remains in the HelloRx+ state and restarts the HelloRx timer each time it receives a Hello+ message.
If the HelloRx timer expires, the hello transmit state enters HelloRx(-). The HelloRx timer is 6 * hello
timer, which by default is 6 seconds.
HelloRx(-)The ELSM-enabled port either transitions from the initial ELSM state or is up but has
not received hello messages because there is a problem with the link or the peer is missing.
For information about displaying ELSM hello messages and hello transmit states, see Displaying ELSM
Information on page 230.
UpIndicates a healthy remote system and this port is receiving Hello+ messages from its peer.
If an ELSM-enabled port enters the Up state, the up timer begins. Each time the port receives a
Hello+ message from its peer, the up timer restarts and the port remains in the Up state. The up
timer is 6* hello timer, which by default is 6 seconds.
DownIndicates that the port is down, blocked, or has not received Hello+ messages from its peer.
If an ELSM-enabled port does not receive a hello message from its peer before the up timer expires,
the port transitions to the Down state. When ELSM is down, data packets are neither forwarded nor
transmitted out of that port.
224
Using ELSM
NOTE
If you reboot the peer switch, its ELSM-enabled peer port may enter the Down-Stuck state. If this occurs, clear
the stuck state using one of the following commands: clear elsm ports <portlist> auto-restart or
enable elsm ports <portlist> auto-restart.
For information about displaying ELSM port states, see Displaying ELSM Information on page 230.
Link States
The state of the link between ELSM-enabled (peer) ports is known as the link state. The link state can be
one of the following:
To view the state of the link between the peer ports, use the following commands:
If you use the show elsm ports <all | portlist> command, the Link State row displays link
state information.
If you use the show ports show ports {<port_list>} information command, the Link State
column displays link state information.
If you use the show ports {<port_list>} information command and specify the detail option, the
ELSM Link State row displays ELSM link state information. For more information, see ELSM Link
States on page 225.
For more information about these show commands, see Displaying ELSM Information on page 230.
ELSM is enabled and the ELSM peer ports are up and communicating
ELSM is enabled but the ELSM peer ports are not up or communicating
ELSM is disabled
To view the current state of ELSM on the switch, use the following commands:
show elsm
225
UpIndicates that ELSM is enabled and the ELSM peer ports are up and communicating; the ELSM
link state is up. In the up state, the ELSM-enabled port sends and receives hello messages from its
peer.
DownIndicates that ELSM is enabled, but the ELSM peers are not communicating; the ELSM link
state is down. In the down state, ELSM transitions the peer port on this device to the down state.
ELSM blocks all incoming and outgoing switching traffic and all control traffic except ELSM PDUs.
Flags
ELSM
upIndicates that ELSM is enabled and the ELSM peer ports are up and communicating; the
ELSM link state is up. In the up state, the ELSM-enabled port sends and receives hello messages
from its peer.
dnIndicates that ELSM is enabled, but the ELSM peers are not communicating; the ELSM link
state is down. In the down state, ELSM transitions the peer port on this device to the down state.
ELSM blocks all incoming and outgoing switching traffic and all control traffic except ELSM
PDUs.
If you specify the optional detail parameter, the following ELSM output is called out in written
explanations versus displayed in a tabular format:
UpIndicates that ELSM is enabled and the ELSM peer ports are up and communicating; the
ELSM link state is up. In the up state, the ELSM-enabled port sends and receives hello messages
from its peer.
DownIndicates that ELSM is enabled, but the ELSM peers are not communicating; the ELSM
link state is down. In the down state, ELSM transitions the peer port on this device to the down
state. ELSM blocks all incoming and outgoing switching traffic and all control traffic except ELSM
PDUs.
ELSM
For more information about these show commands, see Displaying ELSM Information on page 230.
ELSM Timers
To determine whether there is a CPU or link failure, ELSM requires timer expiration between the ELSM
peers. Depending on the health of the network, the port enters different states when the timers expire.
For more information about the ELSM port states, see ELSM Port States on page 224.
226
Using ELSM
Table 34 describes the ELSM timers. Only the hello timer is user-configurable; all other timers are
derived from the hello timer. This means that when you modify the hello timer, you also modify the
values for down, up, and HelloRx timers.
Description
Hello
The ELSM hello timer is the only user-configurable timer and specifies the time in seconds
between consecutive hello messages. The default value is 1 second, and the range is 1 to 128
seconds.
Down
The ELSM down timer specifies the time it takes the ELSM port to cycle through the following
states:
DownIndicates that the port is down, blocked, or has not received Hello+ messages from its
peer.
Down-WaitIndicates a transitional state.
UpIndicates a healthy remote system and this port is receiving Hello+ messages from its peer.
By default, the down timer is (2 + hold threshold) * hello timer, which is 4 seconds. If the hold
threshold is set to 2 and the hello timer is set to 1 second, it takes 4 seconds for the ELSM port
receiving messages to cycle through the states.
After the down timer expires, the port checks the number of Hello+ messages against the hold
threshold. If the number of Hello+ messages received is greater than or equal to the configured
hold threshold, the ELSM receive port moves from the Down-Wait state to the Up state.
If the number of Hello+ messages received is less than the configured hold threshold, the ELSM
receive port moves from the Down-Wait state back to the Down state and begins the process again.
Up
The ELSM up timer begins when the ELSM-enabled port enters the UP state. Each time the port
receives a Hello+ message, the timer restarts.
By default, the up timer is 6 * hello timer, which is 6 seconds.
HelloRx
The ELSM HelloRx timer specifies the time in which a hello message is expected. If the port does
not receive a hello message from its peer, there is the possibility of a CPU or link failure.
By default the HelloRx timer 6 * hello timer, which is 6 seconds.
Enabling ELSM
Disabling ELSM
NOTE
Extreme Networks does not recommend enabling the Link Aggregation Control Protocol (LACP) and ELSM on the
same port. For more information about LACP, see Chapter 5, Configuring Slots and Ports on a Switch.
227
Enabling ELSM
ELSM works between two connected ports (peers), and each ELSM instance is based on a single port.
The Layer 2 connection between the ports determines the peer. You can have a direct connection
between the peers or hubs that separate peer ports. In the first instance, the peers are also considered
neighbors. In the second instance, the peer is not considered a neighbor.
To enable ELSM on one or more ports, use the following command:
enable elsm ports <portlist>
When you enable ELSM on a port, ELSM immediately blocks the port and it enters the Down state.
When the port detects an ELSM-enabled peer, the peer ports exchange ELSM hello messages. At this
point, the ports enter the transitional Down-Wait state. If the port receives Hello+ messages from its
peer and does not detect a problem, the peers enter the Up state. If a peer detects a problem or there is
no peer port configured, the port enters the Down state.
For more information about the types of ELSM hello messages, see ELSM Hello Messages on
page 224. For information about configuring the ELSM hello timer, see the next section.
228
Using ELSM
You configure the hold threshold on a per-port basis, not on a per-switch basis.
To configure the ELSM hold threshold, use the following command:
configure elsm ports <portlist> hold-threshold <hold_threshold>
If you use the enable elsm ports <portlist> auto-restart command, automatic restart is always
enabled; you do not have to use the clear elsm ports <portlist> auto-restart command to clear
the stuck state.
Disabling Automatic Restart. To disable automatic restart, use the following command:
disable elsm ports <portlist> auto-restart
Extreme Networks recommends that you use the same automatic restart configuration on each peer
port.
Re-Enabling Automatic Restart. To re-enable automatic restart, use the following command:
enable elsm ports <portlist> auto-restart
Extreme Networks recommends that you use the same automatic restart configuration on each peer
port.
Re-Setting the Sticky Threshold. The following user events clear, re-set the sticky threshold:
Clearing the port that is in the Down-Stuck state using the following command:
clear elsm ports <portlist> auto-restart
229
Disabling ELSM
To disable ELSM on one or more ports, use the following command:
disable elsm ports <portlist>
When you disable ELSM on the specified ports, the ports no longer send ELSM hello messages to their
peers and no longer maintain ELSM states.
This command displays in a tabular format the operational state of ELSM on the configured ports. If no
ports are configured for ELSM (ELSM is disabled), the switch does not display any information.
Information displayed includes the following:
Hello timeThe current value of the hello timer, which by default is 1 second.
For information about configuring the hello timer, see Configuring the ELSM Hello Timer on
page 228.
To display detailed information for one or more ELSM-enabled ports on the switch, use the following
command:
show elsm ports <all | portlist>
In addition to the port, ELSM state, and hello timer information, this command displays in a tabular
format the following:
ELSM Link StateThe current state of the ELSM logical link on the switch.
For more information, see ELSM Link States on page 225.
230
Hello Transmit StateThe current state of ELSM hello messages being transmitted.
Hold ThresholdThe number of Hello+ messages required by the ELSM-enabled port to transition
from the Down-Wait state to the Up state within the hold threshold.
Using ELSM
Sticky ThresholdThe number of times a port can transition between the Up and Down states. The
sticky threshold is not user-configurable and has a default value of 1.
Sticky CountThe number of times the port transitions from the Up state to the Down state.
The remaining output displays counter information. Use the counter information to determine the
health of the ELSM peers and how often ELSM has gone up or down. The counters are cumulative.
To display summary port information in a tabular format for one or more ELSM-enabled ports, use the
following command:
show ports {<port_list>} information {detail}
Flags
ELSM
ELSM
231
You can also use the clear counters command, which clears all of the counters on the device,
including those associated with ELSM.
Switch A
Switch B
L2 cloud
EX_169
A sudden failure of the switch CPU may cause the hardware to continue forwarding traffic. For
example, ESRP may select a second device for forwarding traffic thereby creating a Layer 2 loop in the
network. If you configure ELSM and the CPU fails, ELSM closes the connection to the faulty device to
prevent a loop.
NOTE
In the following sample configurations, any lines marked (Default) represent default settings and do not need to be
explicitly configured.
Switch A Configuration
232
ELSM-enabled portPort 1
Switch B Configuration
After you enable ELSM on the ports, the peers exchange hello messages with each other as displayed in
Figure 8.
Figure 8: Extreme Networks switches with ELSM-enabled ports exchanging hello messages
Hello message
Switch A
Hello message
Switch B
EX_170
233
:
:
:
:
:
:
:
G60X
G60X
34.68
34.31
Normal
Normal
MSM-1XL
MSM-1XL
31.37
29.75
Normal
Normal
29.00
Normal
The switch monitors the temperature of each component and generates a warning if the temperature
exceeds the normal operating range. If the temperature exceeds the minimum/maximum limits, the
switch shuts down the overheated module.
The switch monitors its temperature and generates a warning if the temperature exceeds the normal
operating range. If the temperature exceeds the maximum limit, the show switch output indicates the
switch in an OPERATIONAL (Overheat) mode, and the show temperaturee output indicates an error
state due to overheat.
234
Send event messages to a number of logging targets (for example, syslog host and NVRAM)
Match expression (for example, any messages containing the string user5)
Matching parameters (for example, only messages with source IP addresses in the 10.1.2.0/24
subnet)
Severity level (for example, only messages of severity critical, error, or warning)
Change the format of event messages (for example, display the date as 12-May-2005 or 2005-0512)
Display log messages in real time and filter the messages that are displayed, both on the console and
from Telnet sessions
Beginning with ExtremeWare XOS 11.2, EMS supports IPv6 as a parameter for filtering events.
Console display
Primary MSM
235
Backup MSM
Syslog host
The first six types of targets exist by default; but before enabling any syslog host, you must add the
hosts information to the switch using the configure syslog command. Extreme Networks EPICenter
can be a syslog target.
By default, the memory buffer and NVRAM targets are already enabled and receive messages. To start
sending messages to the targets, use the following command:
enable log target [console | memory-buffer | nvram | primary-msm | backup-msm |
session | syslog [all | <ipaddress> | <ipPort>] {vr <vr_name>} [local0 ... local7]]]
After you enable this feature, the target receives the messages it is configured for. See Target
Configuration later in this chapter for information on viewing the current configuration of a target. The
memory buffer can contain only the configured number of messages, so the oldest message is lost when
a new message arrives, when the buffer is full.
To stop sending messages to the target, use the following command:
disable log target [console | memory-buffer | nvram | primary-msm | backup-msm |
session | syslog [all | <ipaddress> | <ipPort>] {vr <vr_name>} [local0 ... local7]]]
NOTE
Refer to your UNIX documentation for more information about the syslog host facility.
236
Target Configuration
To specify the messages to send to an enabled target, you will set a message severity level, a filter name,
and a match expression. These items determine which messages are sent to the target. You can also
configure the format of the messages in the targets. For example, the console display target is
configured to get messages of severity info and greater, the NVRAM target gets messages of severity
warning and greater, and the memory buffer target gets messages of severity debug-data and greater.
All the targets are associated by default with a filter named DefaultFilter, that passes all events at or
above the default severity threshold. All the targets are also associated with a default match expression
that matches any messages (the expression that matches any message is displayed as Match : (none)
from the command line). And finally, each target has a format associated with it.
To display the current log configuration of the targets, use the following command:
show log configuration target {console | memory-buffer | nvram | primary-msm | backupmsm | session | syslog {<ipaddress> | <ipPort> | vr <vr_name>} {[local0 ... local7]}}
To configure a target, you use specific commands for severity, filters, and formats. In addition, you can
configure the source IP address for a syslog target. Configuring the source IP address allows the
management station or syslog server to identify from which switch it received the log messages. To
configure the source IP address for a syslog target, use the following command:
configure log target syslog [all | <ipaddress> | <ipPort>] {vr <vr_name>} {local0 ...
local7} from <source-ip-address>
The following sections describe the commands required for configuring filters, formats, and severity.
Severity
Messages are issued with one of the severity levels specified by the standard Berkeley Software
Distribution (BSD) syslog values (RFC 3164)critical, error, warning, notice, and infoplus three
severity levels for extended debuggingdebug-summary, debug-verbose, and debug-data. Note that
RFC 3164 syslog values emergency and alert are not needed because critical is the most severe
event in the system.
The three severity levels for extended debuggingdebug-summary, debug-verbose, and debug-data
require that debug mode be enabled (which may cause a performance degradation). See Displaying
Debug Information on page 247 for more information about debugging.
Description
Critical
A serious problem has been detected that is compromising the operation of the
system; the system cannot function as expected unless the situation is remedied. The
switch may need to be reset.
Error
A problem has been detected that is interfering with the normal operation of the
system; the system is not functioning as expected.
237
Description
Warning
An abnormal condition, not interfering with the normal operation of the system, has
been detected that indicate that the system or the network in general may not be
functioning as expected.
Notice
A normal but significant condition has been detected, which signals that the system is
functioning as expected.
Info (Informational)
A normal but potentially interesting condition has been detected, which signals that
the system is functioning as expected; this level simply provides potentially detailed
information or confirmation.
Debug-Summary
A condition has been detected that may interest a developer seeking the reason
underlying some system behavior.
Debug-Verbose
A condition has been detected that may interest a developer analyzing some system
behavior at a more verbose level than provided by the debug summary information.
Debug-Data
A condition has been detected that may interest a developer inspecting the data
underlying some system behavior.
You can use more than one command to configure the severity level of the messages sent to a target.
The most direct way to set the severity level of all the sent messages is to use the following command:
configure log target [console | memory-buffer | nvram | primary-msm | backup-msm |
session | syslog [all | <ipaddress> | <ipPort> {vr <vr_name>} [local0 ... local7]]]
{severity <severity> {only}}
When you specify a severity level, messages of that severity level and greater are sent to the target. If
you want only those messages of the specified severity to be sent to the target, use the keyword only.
For example, specifying severity warning will send warning, error, and critical messages to the target,
but specifying severity warning only sends only warning messages.
You can also use the following command to configure severity levels, which associate a filter with a
target:
configure log target [console | memory-buffer | primary-msm | backup-msm | nvram |
session | syslog [all | <ipaddress> | <ipPort> {vr <vr_name>} [local0 ... local7]]]
filter <filter-name> {severity <severity> {only}}
When you specify a severity level as you associate a filter with a target, you further restrict the
messages reaching that target. The filter may allow only certain categories of messages to pass. Only the
messages that pass the filter and then pass the specified severity level reach the target.
Finally, you can specify the severity levels of messages that reach the target by associating a filter with a
target. The filter can specify exactly which message it will pass. Constructing a filter is described in
Filtering By Components and Conditions on page 240.
238
Title
Threshold
---------------------------------------------- -------------
Error
Warning
Warning
Error
The display above lists the components, subcomponents, and the default severity threshold assigned to
each. In EMS, you use A period (.) is used to separate component, subcomponent, and condition names.
For example, you can refer to the InBPDU subcomponent of the STP component as STP.InBPDU. On the
CLI, you can abbreviate or TAB complete any of these.
A component or subcomponent often has several conditions associated with it. To see the conditions
associated with a component, use the following command:
show log events [<event condition> | [all | <event component>] {severity <severity>
{only}}] {details}
For example, to see the conditions associated with the STP.InBPDU subcomponent, use the following
command:
show log events stp.inbpdu
SubComp
----------InBPDU
InBPDU
InBPDU
InBPDU
InBPDU
Condition
----------------------Drop
Dump
Trace
Ign
Mismatch
Severity
Parameters
------------- ---------Error
2 total
Debug-Data
3 total
Debug-Verbose 2 total
Debug-Summary 2 total
Warning
2 total
The display above lists the five conditions contained in the STP.InBPDU component, the severity of the
condition, and the number of parameters in the event message. In this example, the severities of the
events in the STP.InBPDU subcomponent range from error to debug-summary.
When you use the details keyword, you see the message text associated with the conditions. For
example, if you want to see the message text and the parameters for the event condition
STP.InBPDU.Trace, use the following command:
show log events stp.inbpdu.trace details
239
The Comp heading shows the component name, the SubComp heading shows the subcomponent (if any),
the Condition heading shows the event condition, the Severity heading shows the severity assigned
to this condition, the Parameters heading shows the parameters for the condition, and the text string
shows the message that the condition will generate. The parameters in the text string (for example, %0%
and %1% above) will be replaced by the values of these parameters when the condition is encountered
and displayed as the event message.
Filtering By Components and Conditions. You may want to send the messages that come from a specific
component that makes up ExtremeWare XOS or to send the message generated by a specific condition.
For example, you might want to send only those messages that come from the STP component, or send
the message that occurs when the IP.Forwarding.SlowPathDrop condition occurs. Or you may want to
exclude messages from a particular component or event. To do this, you construct a filter that passes
only the items of interest, and you associate that filter with a target.
The first step is to create the filter using the create log filter command. You can create a filter
from scratch, or copy another filter to use as a starting point. (It may be easiest to copy an existing filter
and modify it.) To create a filter, use the following command:
create log filter <name> {copy <filter name>}
If you create a filter from scratch, that filter initially blocks all events until you add events (either the
events from a component or a specific event condition) to pass. You might create a filter from scratch if
you want to pass a small set of events and to block most events. If you want to exclude a small set of
events, use the default filter that passes events at or above the default severity threshold (unless the
filter has been modified), named DefaultFilter, that you can copy to use as a starting point for your filter.
After you create your filter, you configure filter items that include or exclude events from the filter.
Included events are passed; excluded events are blocked. To configure your filter, use the following
command:
configure log filter <name> [add | delete] {exclude} events [<event-condition> | [all
| <event-component>] {severity <severity> {only}}]
For example, if you create the filter myFilter from scratch, use the following command to include events:
configure log filter myFilter add events stp
All STP component events of at least the default threshold severity passes myFilter (for the STP
component, the default severity threshold is error). You can further modify this filter by specifying
additional conditions.
For example, assume that myFilter is configured as before, and assume that you want to exclude the
STP.CreatPortMsgFail event. To add that condition, use the following command:
configure log filter myFilter add exclude events stp.creatportmsgfail
240
You can continue to modify this filter by adding more filter items. The filters process events by
comparing the event with the most recently configured filter item first. If the event matches this filter
item, the incident is either included or excluded, depending on whether the exclude keyword was
used. if necessary, subsequent filter items on the list are compared. If the list of filter items is exhausted
with no match, the event is excluded and is blocked by the filter.
To view the configuration of a filter, use the following command:
show log configuration filter {<filter name>}
The following is sample output from this command (for the earlier filter):
Log Filter
I/
E Comp.
- ------I STP
E STP
I STP
Name: myFilter
Sub-comp.
Condition
----------- ----------------------InBPDU
CreatPortMsgFail
Severity
CEWNISVD
---------------E-------------
Include/Exclude:
Component Unreg:
Severity Values:
Debug Severity :
I - Include, E - Exclude
* - Component/Subcomponent is not currently registered
C - Critical, E - Error, W - Warning, N - Notice, I - Info
S - Debug-Summary, V - Debug-Verbose, D - Debug-Data
+ - Debug Severities, but log debug-mode not enabled
If Match parameters present:
Parameter Flags: S - Source, D - Destination, (as applicable)
I - Ingress, E - Egress, B - BGP
Parameter Types: Port - Physical Port list, Slot - Physical Slot #
MAC - MAC address, IP - IP Address/netmask, Mask - Netmask
VID - Virtual LAN ID (tag), VLAN - Virtual LAN name
L4
- Layer-4 Port #, Num - Number, Str - String
Nbr - Neighbor, Rtr - Routerid, EAPS - EAPS Domain
Proc - Process Name
Strict Match
: Y - every match parameter entered must be present in the event
N - match parameters need not be present in the event
The show log configuration filter command shows each filter item, in the order that it will be
applied and whether it will be included or excluded. The above output shows the three filter items, one
including events from the STP.InBPDU component, one excluding the event STP.CreatPortMsgFail, and
the next including the remaining events from the STP component. The severity value is shown as *,
indicating that the components default severity threshold controls which messages are passed. The
Parameter(s) heading is empty for this filter because no match is configured for this filter. Matches are
described in Matching Expressions next.
Each time a filter item is added to or deleted from a given filter, the specified events are compared
against the current configuration of the filter to try to logically simplify the configuration. Existing items
will be replaced by logically simpler items if the new item enables rewriting the filter. If the new item is
already included or excluded from the currently configured filter, the new item is not added to the filter.
241
Matching Expressions
You can configure the switch so messages reaching the target match a specified match expression. The
message text is compared with the configured match expression to determine whether to pass the
message on. To require that messages match a match expression, use the following command:
configure log target [console | memory-buffer | nvram | primary-msm | backup-msm |
session | syslog [all | <ipaddress> | <ipPort> {vr <vr_name>} [local0 ... local7]]]
match [any |<match-expression>]
The messages reaching the target will match the match-expression, a simple regular expression. The
formatted text string that makes up the message is compared with the match expression and is passed
to the target if it matches. This command does not affect the filter in place for the target, so the match
expression is compared only with the messages that have already passed the targets filter. For more
information on controlling the format of the messages, see Formatting Event Messages on page 244.
Simple Regular Expressions. A simple regular expression is a string of single characters including the dot
character (.), which are optionally combined with quantifiers and constraints. A dot matches any single
character, while other characters match only themselves (case is significant). Quantifiers include the star
character (*) that matches zero or more occurrences of the immediately preceding token. Constraints
include the caret character (^) that matches at the beginning of a message and the currency character ($)
that matches at the end of a message. Bracket expressions are not supported. There are a number of
sources available on the Internet and in various language references describing the operation of regular
expressions. Table 36 shows some examples of regular expressions.
Matches
port
port 2:3
import cars
portable structure
poor
por
pot
..ar
baar
bazaar
rebar
bar
port.*vlan
myvlan$
delete myvlan
error in myvlan
Matching Parameters
Rather than using a text match, EMS allows you to filter more efficiently based on the parameter values
of the message. In addition to event components and conditions and severity levels, each filter item can
also use parameter values to further limit which messages are passed or blocked. The process of
creating, configuring, and using filters has already been described in Filtering By Components and
Conditions on page 240, so this section describes matching parameters with a filter item.
To configure a parameter match filter item, use the following command:
configure log filter <name> [add | delete] {exclude} events [<event-condition> | [all
| <event-component>] {severity <severity> {only}}] [match | strict-match] <type>
<value>
242
Beginning with ExtremeWare XOS 11.2, you can specify the ipaddress type as IPv4 or IPv6, depending
on the IP version. The following examples show how to configure IPv4 addresses and IPv6 addresses:
IPv4 address
To configure an IP address, with a mask of 32 assumed, use the following command:
configure log filter myFilter add events all match ipaddress 12.0.0.1
IPv6 address
To configure an IPv6 address, with a mask of 128 assumed, use the following command:
configure log filter myFilter add events all match ipaddress 3ffe::1
To configure a range of IPv6 addresses with a mask of 16, use the following command:
configure log filter myFilter add events all match ipaddress 3ffe::/16
To configure a range of scoped IPv6 addresses with a mask of 16, use the following command:
configure log filter myFilter add events all match ipaddress 3ffe::/16%Default
To configure a scoped IPv6 address with any VLAN, use the following command:
configure log filter myFilter add events all match ipaddress 3ffe::/16%*
243
NOTE
In the previous example, if you specify the VLAN name, it must be a full match; wild cards are not allowed.
The <value> depends on the parameter type specified. As an example, an event may contain a physical
port number, a source MAC address, and a destination MAC address. To allow only those RADIUS
incidents, of severity notice and above, with a specific source MAC address, use the following
command:
configure log filter myFilter add events aaa.radius.requestInit severity notice match
source mac-address 00:01:30:23:C1:00
The string type is used to match a specific string value of an event parameter, such as a user name. A
string can be specified as a simple regular expression.
Match Versus Strict-Match. The match and strict-match keywords control the filter behavior for those
incidents with event definition that does not contain all the parameters specified in a configure log
filter events match command.
This is best explained with an example. Suppose an event in the XYZ component, named XYZ.event5,
contains a physical port number, a source MAC address, but no destination MAC address. If you
configure a filter to match a source MAC address and a destination MAC address, XYZ.event5 will
match the filter when the source MAC address matches regardless of the destination MAC address
because the event contains no destination MAC address. If you specify the strict-match keyword,
then the filter will never match event XYZ.event5 because this event does not contain the destination
MAC address.
In other words, if the match keyword is specified, an incident will pass a filter so long as all parameter
values in the incident match those in the match criteria, but all parameter types in the match criteria
need not be present in the event definition.
Using the default format for the session target, an example log message might appear as:
06/25/2004 22:49:10.63 <Info:dm.Info> MSM-A: PowerSupply:4 Powered On
If you set the current session format using the following command:
configure log target session format timestamp seconds date mm-dd-yyyy event-name
component
244
To provide some detailed information to technical support, set the current session format using the
following command:
configure log target session format timestamp hundredths date mmm-dd event-name
condition process-name source-line
This setting may be saved to the FLASH configuration and is restored on boot-up (to the console
display session).
To turn on log display for the current session, use the following command:
enable log target session
This setting only affects the current session and is lost when you log off the session.
The messages that are displayed depend on the configuration and format of the target. For information
on message filtering, see Filtering Events Sent to Targets on page 237. for information on message
formatting, see Formatting Event Messages on page 244.
You can use many options to select those log entries of interest. You can select to display only those
messages that conform to the specified:
Severity
Match expression
The displayed messages can be formatted differently from the format configured for the targets, and
you can choose to display the messages in order of newest to oldest or in chronological order (oldest to
newest).
245
You must specify the TFTP host and the filename to use in uploading the log. There are many options
you can use to select the log entries of interest. You can select to upload only those messages that
conform to the specified:
Severity
Match expression
The uploaded messages can be formatted differently from the format configured for the targets, and you
can choose to upload the messages in order of newest to oldest or in chronological order (oldest to
newest).
The system displays two counters. One counter displays the number of times an event has occurred,
and the other displays the number of times that notification for the event was made to the system for
further processing. Both counters reflect totals accumulated since reboot or since the counters were
cleared using the clear log counters or clear counters command.
The show log counters command also displays an included flag (the column titled In in the output).
The included flag is set to Y(es) if one or more targets are receiving notifications of this event without
regard to matching parameters.
The keywords include, notified, and occurred display events only with non-zero counter values for
the corresponding counter.
The output of the command:
show log counters stp.inbpdu severity debug-summary
SubComp
----------InBPDU
InBPDU
InBPDU
Occurred :
Flags
:
In(cluded):
Notified :
246
Condition
----------------------Drop
Ign
Mismatch
Severity
Occurred
------------- -------Error
0
Debug-Summary
0
Warning
0
In Notified
-- -------Y
0
N
0
Y
0
Using sFlow
The output of the command:
show log counters stp.inbpdu.drop
In Notified
-- -------Y
0
When the switch is in debug-mode, any filters configured for your targets still affect which messages
are passed on or blocked.
Using sFlow
sFlow is a technology for monitoring traffic in data networks containing switches and routers. It relies
on statistical sampling of packets from high-speed networks, plus periodic gathering of the statistics. A
User Datagram Protocol (UDP) datagram format is defined to send the information to an external entity
for analysis. sFlow consists of a Management Information Base (MIB) and a specification of the packet
247
NOTE
On the BlackDiamond 8800 family of switches, and on a Summit X450 switch, sFlow and mirroring are mutually
exclusive. You can enable either sFlow, or mirroring, but not both.
However, you should be aware of a few limitations in the current release. The current release supports:
Non-extended data
Only those packets that do not match an ACL rule are considered for sampling
No MIB support
Configuring sFlow
ExtremeWare XOS allows you to collect sFlow statistics on a per port basis. An agent, residing locally
on the switch, sends data to a collector that resides on another machine. You configure the local agent,
the address of the remote collector, and the ports of interest for sFlow statistics gathering. You can also
modify default values for how frequently on average a sample is taken and the maximum number of
samples allowed before throttling the sample gathering.
To configure sFlow on a switch, you must do the following tasks:
Optionally, you may also change the default values of the following items:
248
Using sFlow
management port IP address as its IP address. You change the agent IP address by using the following
command:
configure sflow agent {ipaddress} <ip-address>
To unconfigure the remote collector and remove it from the database, use the following command:
unconfigure sflow collector {ipaddress} <ip-address> {port <udp-port-number>} {vr
<vrname>}
When you disable sFlow globally, the individual ports are also put into the disabled state. If you later
enable the global sFlow state, individual ports return to their previous state.
You may enable and disable sFlow on ports irrespective of the global state of sFlow, but samples are not
taken until both the port state and the global state are enabled.
To disable sFlow on ports, use the following command:
disable sflow ports <portlist>
249
Global Sampling Rate. This is the rate that newly enabled sFlow ports will have their sample rate set to.
Changing this rate will not affect currently enabled sFlow ports. The default sample rate is 8192, so by
default sFlow samples one packet out of every 8192 received. To configure the switch to use a different
sampling rate, use the following command:
configure sflow sample-rate <number>
For example, if you set the sample rate number to 16384, the switch samples one out of every 16384
packets received. Higher numbers mean fewer samples and longer times between samples. If you set
the number too low, the number of samples can be very large, which increases the load on the switch.
Do not configure the sample rate to a number lower than the default unless you are sure that the traffic
rate on the source is low.
Per Port Sampling Rate. To set the sampling rate on individual ports, use the following command:
configure sflow ports <portlist> sample-rate <number>
For BlackDiamond 10K switchAt the hardware level, all ports on the same slot are sampled at the
same rate, so if one port is configured to sample less frequently than another on the same slot, the extra
samples are discarded. This is indicated in the output of the show sflow {configuration} command
as the sub-sampling factor. For example, if one port is configured to sample one packet per every 8192
packets, and the second port on the same slot is configured to sample one packet per every 16384
packets, the second port will show a sub-sampling factor of two.
For Summit X450 switchAt the hardware level, all ports on the switch are sampled at the same rate,
so if one port is configured to sample less frequently than another, the extra samples are discarded. This
is indicated in the output of the show sflow {configuration} command as the sub-sampling factor.
For example, if one port is configured to sample one packet per every 8192 packets, and the second port
on the same slot is configured to sample one packet per every 16384 packets, the second port will show
a sub-sampling factor of two.
Maximum CPU Sample Limit. A high number of samples can cause a heavy load on the switch CPU. To
limit the load, there is a CPU throttling mechanism to protect the switch. Whenever the limit is reached,
the sample rate value is doubled on the slot from which the maximum number of samples are received.
For ports on that slot that are sampled less frequently, the sampling rate is not changed; the subsampling factor is adjusted downward. To configure the maximum CPU sample limit, use the following
command:
configure sflow max-cpu-sample-limit <rate>
250
Using RMON
Unconfiguring sFlow
To reset the any configured values for sFlow to their default values and remove from sFlow any
configured collectors and ports, use the following command:
unconfigure sflow
Using RMON
Using the Remote Monitoring (RMON) capabilities of the switch allows network administrators to
improve system efficiency and reduce the load on the network.
The following sections explain more about the RMON concept and the RMON features supported by
the switch.
NOTE
You can only use the RMON features of the system if you have an RMON management application and have enabled
RMON on the switch.
About RMON
RMON is the common abbreviation for the Remote Monitoring Management Information Base (MIB)
system defined by the Internet Engineering Task Force (IETF) documents RFC 1757 and RFC 2021,
which allows you to monitor LANs remotely.
A typical RMON setup consists of the following two components:
RMON agent
Management workstation
RMON Agent
An RMON agent is an intelligent software agent that continually monitors port statistics and system
variables. The agent transfers the information to a management workstation on request, or when a
predefined threshold is crossed.
Information collected by RMON includes Ethernet port statistics and history and the software version
and hardware revision of the device. RMON generates alarms when threshold levels are met and then
251
Management Workstation
A management workstation communicates with the RMON agent and collects the statistics from it. The
workstation does not have to be on the same network as the RMON agent and can manage the agent by
in-band or out-of-band connections.
If you enable RMON on the switch, you can use a management workstation to review port statistics and
port history, no configuration of the management workstation is necessary. However, you must use a
management workstation to configure the alarm and event entries.
Statistics
History
Alarms
Events
The switch also supports the following parameters for configuring the RMON agent and the trap
destination table, as defined in RFC 2021:
probeCapabilities
probeSoftwareRev
probeHardwareRev
probeDateTime
probeResetControl
trapDestTable
The following sections describe the supported groups, the RMON probe configuration parameters, and
the trap destination parameter in greater detail.
Statistics
The RMON Ethernet Statistics group provides traffic and error statistics showing packets, bytes,
broadcasts, multicasts, and errors on an Ethernet port.
Information from the Statistics group is used to detect changes in traffic and error patterns in critical
areas of the network.
History
The History group provides historical views of network performance by taking periodic samples of the
counters supplied by the Statistics group. The group features user-defined sample intervals and bucket
counters for complete customization of trend analysis.
252
Using RMON
The group is useful for analysis of traffic patterns and trends on an Ethernet port, and to establish
baseline information indicating normal operating parameters.
Alarms
The Alarms group provides a versatile, general mechanism for setting threshold and sampling intervals
to generate events on any RMON variable. Both rising and falling thresholds are supported, and
thresholds can be on the absolute value of a variable or its delta value.
Note, creating an entry in the alarmTable does not validate the alarmVariable and does not generate a
badValue error message.
Alarms inform you of a network performance problem and can trigger automated action responses
through the Events group.
Events
The Events group creates entries in an event log and/or sends SNMP traps to the management
workstation. An event is triggered by an RMON alarm. The action taken can be configured to ignore it,
to log the event, to send an SNMP trap to the receivers listed in the trap receiver table, or to both log
and send a trap. The RMON traps are defined in RFC 1757 for rising and falling thresholds.
Effective use of the Events group saves you time. Rather than having to watch real-time graphs for
important occurrences, you can depend on the Event group for notification. Through the SNMP traps,
events can trigger other actions, which provides a mechanism for an automated response to certain
occurrences.
probeCapabilitiesIf you configure the probeCapabilities object, you can view the RMON MIB
groups supported on at least one interface by the probe.
probeSoftwareRevIf you configure the probeSoftwareRev object, you can view the current software
version of the monitored device.
probeHardwareRevIf you configure the probeHardwareRev object, you can view the current
hardware version of the monitored device.
probeDateTimeIf you configure the probeDateTime object, you can view the current date and time
of the probe. For example, Friday December 31, 2004 at 1:30:15 PM EST is displayed as: 2004-1231,13:30:15.0
If the probe is aware of time zones, the display also includes the Greenwich Mean Time (GMT)
offset. For example, Friday, December 31, 2004, 1:30:15 PM EST with the offset known is displayed
as: 2004-12-31,13:30:15.0, -4.0
If time information is unavailable or unknown, the time is not displayed.
253
probeResetControlIf you configure the probeResetControl object, you can restart a managed device
that is not running normally. Depending on your configuration, you can do one of the following:
Warm bootA warm boot restarts the device using the current configuration saved in nonvolatile memory.
Cold bootA cold boot causes the device to reset the configuration parameters stored in nonvolatile memory to the factory defaults and then restarts the device using the restored factory
default configuration.
trapDestTable
The trapDestTable contains information about the configured trap receivers on the switch and stores this
information in non-volatile memory. To configure one or more trap receivers, see Using the Simple
Network Management Protocol, in Chapter 3.
Configuring RMON
RMON requires one probe per LAN segment, and standalone RMON probes traditionally have been
expensive. Therefore, the approach taken by Extreme Networks has been to build an inexpensive
RMON probe into the agent of each system. This allows RMON to be widely deployed around the
network without costing more than traditional network management. The switch accurately maintains
RMON statistics at the maximum line rate of all of its ports.
To enable or disable the collection of RMON statistics on the switch, use one of the following
commands:
enable rmon
disable rmon
By enabling RMON, the switch begins the processes necessary for collecting switch statistics. By default,
RMON is disabled. However, even in the disabled state, the switch collects etherStats and you can
configure alarms and events.
RMON saves the history, alarm, and event configurations to the configuration file. Runtime data is not
stored in the configuration file and is subsequently lost after a system restart.
Event Actions
The actions that you can define for each alarm are shown in Table 37.
High Threshold
no action
log
log-and-trap
snmp-trap
To be notified of events using SNMP traps, you must configure one or more trap receivers, as described
in the section, Using the Simple Network Management Protocol, in Chapter 3.
254
Using RMON
To view the RMON memory usage statistics for a specific RMON feature (for example, statistics, events,
logs, history, or alarms) or for all features, use the following command:
show rmon memory {detail | <memoryType>}
255
256
10 Virtual LANs
This chapter describes the following topics:
MAC-in-MAC TunnelingBlackDiamond 10K Series and 12804 Switch Only on page 283
Setting up Virtual Local Area Networks (VLANs) on the switch eases many time-consuming tasks of
network administration while increasing efficiency in network operations.
The term VLAN is used to refer to a collection of devices that communicate as if they were on the same
physical LAN. Any set of ports (including all ports on the switch) is considered a VLAN. LAN
segments are not restricted by the hardware that physically connects them. The segments are defined by
flexible user groups that you create with the command line interface (CLI).
Benefits
NOTE
The system switches traffic within each VLAN using the Ethernet MAC address. The system routes traffic between
two VLANs using the IP addresses.
VLANs help to control trafficWith traditional networks, broadcast traffic that is directed to all
network devices, regardless of whether they require it, causes congestion. VLANs increase the
efficiency of your network because each VLAN can be set up to contain only those devices that must
communicate with each other.
257
Virtual LANs
VLANs provide extra securityDevices within each VLAN can communicate only with member
devices in the same VLAN. If a device in VLAN Marketing must communicate with devices in VLAN
Sales, the traffic must cross a routing device.
VLANs ease the change and movement of devicesWith traditional networks, network
administrators spend much of their time dealing with moves and changes. If users move to a
different subnetwork, the addresses of each endstation must be updated manually.
ExtremeWare XOS supports virtual routers. Beginning with XOS version 11.2, each port can belong to
multiple virtual routers; that is port can belong to more than one virtual router. Ports can belong to
different VLANs that are in different virtual routers.
If you do not specify a virtual router when you create a VLAN, the system creates that VLAN in the
default virtual router (VR-Default). The management VLAN is always in the management virtual router
(VR-Mgmt).
After you create virtual routers, ExtremeWare XOS software allows you to designate one of these virtual
routers as the domain in which all your subsequent configuration commands, including VLAN
commands, are applied. After you create virtual routers, ensure that you are creating each VLAN in the
desired virtual router domain. Also, ensure that you are in the correct virtual router domain before you
begin modifying each VLAN.
For information on configuring and using virtual routers, see Chapter 12.
Types of VLANs
NOTE
Beginning with ExtremeWare XOS version 11.3, you may have netlogin dynamic VLANs and, on the Summit X450
switch and BlackDiamond 8800 family of switches only, netlogin MAC-based VLANs. See Chapter 18 for complete
information on netlogin.
258
Physical port
Types of VLANs
Port-Based VLANs
In a port-based VLAN, a VLAN name is given to a group of one or more ports on the switch.
At boot-up, all ports are members of the port-based VLAN default. Before you can add any port to
another port-based VLAN, you must remove it from the default VLAN, unless the new VLAN uses a
protocol other than the default protocol any. A port can be a member of only one port-based VLAN.
On the Extreme Networks switch in Figure 9, ports 9 through 14 are part of VLAN Marketing; ports 25
through 29 are part of VLAN Sales; and ports 21 through 24 and 30 through 32 are in VLAN Finance.
Marketing
Finance
Sales
EX_060
For the members of different IP VLANs to communicate, the traffic must be routed by the switch, even
if the VLANs are physically part of the same I/O module. This means that each VLAN must be
configured as a router interface with a unique IP address.
NOTE
On the BlackDiamond 10K switch, the 10 Gbps module must have the serial number 804405-00-09 or higher to
support untagged frames. If your configuration has untagged frames, but the wrong 10 Gbps module, the system
fails that slot; to use the earlier revision of the 10 Gbps module, you must remove the untagged ports from the
VLAN and reset the module. To display the serial number of the module, use the show slot <slot_number>
command.
259
Virtual LANs
Figure 10 illustrates a single VLAN that spans a BlackDiamond switch and another Extreme Networks
switch. All ports on the system 1 switch belong to VLAN Sales. Ports 1 through 29 on the system 2
switch also belong to VLAN Sales. The two switches are connected using slot 8, port 4 on system 1 (the
BlackDiamond switch), and port 29 on system 2 (the other switch).
Sales
System 1
System 2
EX_061
To create multiple VLANs that span two switches in a port-based VLAN, a port on system 1 must be
cabled to a port on system 2 for each VLAN you want to have span across the switches. At least one
port on each switch must be a member of the corresponding VLANs, as well.
260
Types of VLANs
Figure 11 illustrates two VLANs spanning two switches. On system 2, ports 25 through 29 are part of
VLAN Accounting; ports 21 through 24 and ports 30 through 32 are part of VLAN Engineering. On
system 1, all port on slot 1 are part of VLAN Accounting; all ports on slot 8 are part of VLAN
Engineering.
Accounting
Engineering
System 2
EX_063
VLAN Accounting spans system 1 and system 2 by way of a connection between system 2, port 29 and
system 1, slot 1, port 6. VLAN Engineering spans system 1 and system 2 by way of a connection between
system 2, port 32, and system 1, slot 8, port 6.
Using this configuration, you can create multiple port-based VLANs that span multiple switches, in a
daisy-chained fashion. Each switch must have a dedicated port for each VLAN. Each dedicated port
must be connected to a port that is a member of its VLAN on the next switch.
Tagged VLANs
Tagging is a process that inserts a marker (called a tag) into the Ethernet frame. The tag contains the
identification number of a specific VLAN, called the VLANid (valid numbers are 1 to 4094).
NOTE
The use of 802.1Q tagged packets may lead to the appearance of packets slightly bigger than the current IEEE
802.3/Ethernet maximum of 1,518 bytes. This may affect packet error counters in other devices and may also lead
to connectivity problems if non-802.1Q bridges or routers are placed in the path.
261
Virtual LANs
NOTE
Packets arriving tagged with a VLANid that is not configured on a port will be discarded.
262
Types of VLANs
Figure 12 illustrates the physical view of a network that uses tagged and untagged traffic.
System 1
= Tagged port
Marketing & Sales
802.1Q
Tagged server
M
M
M
S
S
S
System 2
EX_064
Marketing
Sales
System 1
Ports 1-4 & 9-12
System 1
Port 25 *
Port 29 *
System 1
Ports 5-8, 13-16 & 32
System 2
Slot 1, Port 2
Slot 2, Ports 1-8 & 17-24
System 2
Slot 1, Port 1 *
System 2
Slot 1, Port 3
Slot 1, Port 4
Slot 2, Ports 9-16 & 25-32
*Tagged Ports
EW_025
The trunk port on each switch carries traffic for both VLAN Marketing and VLAN Sales.
The server connected to port 25 on system 1 has a NIC that supports 802.1Q tagging.
The server connected to port 25 on system 1 is a member of both VLAN Marketing and VLAN Sales.
263
Virtual LANs
As data passes out of the switch, the switch determines if the destination port requires the frames to be
tagged or untagged. All traffic coming from and going to the server is tagged. Traffic coming from and
going to the trunk ports is tagged. The traffic that comes from and goes to the other stations on this
network is not tagged.
Protocol-Based VLANs
Protocol-based VLANs enable you to define a packet filter that the switch uses as the matching criteria
to determine if a particular packet belongs to a particular VLAN.
264
Types of VLANs
Protocol-based VLANs are most often used in situations where network segments contain hosts running
multiple protocols. For example, in Figure 14, the hosts are running both the IP and NetBIOS protocols.
The IP traffic has been divided into two IP subnets, 192.207.35.0 and 192.207.36.0. The subnets are
internally routed by the switch. The subnets are assigned different VLAN names, Finance and Personnel,
respectively. The remainder of the traffic belongs to the VLAN named MyCompany. All ports are
members of the VLAN MyCompany.
192.207.35.1
192.207.36.1
My Company
192.207.35.0
Finance
192.207.36.0
Personnel
= IP traffic
= All other traffic
EX_065
IP (IPv4)
IPX
NetBIOS
DECNet
IPX_8022
IPX_SNAP
AppleTalk
Protocol filters on the BlackDiamond 8800 family of switches and the Summit X450 switch only. These
devices do not forward packets with a protocol-based VLAN set to AppleTalk. To ensure that AppleTalk
packets are forwarded on the device, create a protocol-based VLAN set to any and define other
265
Virtual LANs
protocol-based VLANs for other traffic, such as IP traffic. The AppleTalk packets will pass on the any
VLAN, and the other protocols will pass traffic on their specific protocol-based VLANs.
For example:
create protocol fred
etypeEtherType
The values for etype are four-digit hexadecimal numbers taken from a list maintained by the
IEEE. This list can be found at the following URL:
http://standards.ieee.org/regauth/ethertype/index.html
The values for llc are four-digit hexadecimal numbers that are created by concatenating a twodigit LLC Destination SAP (DSAP) and a two-digit LLC Source SAP (SSAP).
The values for snap are the same as the values for etype, described previously.
For example:
configure protocol fred add llc feff
configure protocol fred add snap 9999
A maximum of 15 protocol filters, each containing a maximum of 6 protocols, can be defined. No more
than 7 protocols can be active and configured for use.
NOTE
For more information on SNAP for Ethernet protocol types, see TR 11802-5:1997 (ISO/IEC) [ANSI/IEEE std.
802.1H, 1997 Edition].
266
VLAN Names
Default VLAN
The switch ships with one default VLAN that has the following properties:
The default VLAN is untagged on all ports. It has an internal VLANid of 1; this value is userconfigurable.
VLAN Names
Each VLAN is given a name that can be up to 32 characters. VLAN names use standard alphanumeric
characters.
VLAN names must begin with an alphabetical letter. The names can be no longer than 32 characters and
must begin with an alphabetic character. The remainder of the name can be alphanumeric or contain
underscore (_) characters. VLAN names cannot be keywords.
NOTE
If you use the same name across categories (for example, STPD and EAPS names), Extreme Networks recommends
that you specify the identifying keyword as well as the actual name. If you do not use the keyword, the system may
return an error message.
VLAN names can be specified using the tab key for command completion.
VLAN names are locally significant. That is, VLAN names used on one switch are only meaningful to
that switch. If another switch is connected to it, the VLAN names have no significance to the other
switch.
NOTE
Extreme Networks recommends that you use VLAN names consistently across your entire network.
VLANs
VMANs
Ipv6 tunnels
267
Virtual LANs
Renaming a VLAN
To rename an existing VLAN, use the following command:
configure vlan <vlan_name> name <name>
This section describes how to create, name, and enable or disable a VLAN. This part covers the
following areas:
Beginning with ExtremeWare XOS version 11.4, the system returns the following message if the ports
you are adding are already EAPS primary or EAPS secondary ports:
WARNING: Make sure Vlan1 is protected by EAPS, Adding EAPS ring ports to a VLAN
could cause a loop in the network.
Do you really want to add these ports? (y/n)
This section describes the commands associated with setting up VLANs on the switch. To configure a
VLAN:
1 Create and name the VLAN.
NOTE
Each IP address and mask assigned to a VLAN must represent a unique IP subnet. You cannot configure the same
IP subnet on different VLANs on the same virtual router.
268
NOTE
Beginning with ExtremeWare XOS 11.2, the software supports using IPv6 addresses, in addition to IPv4 addresses.
You can configure the VLAN with an IPv4 address, IPv6 address, or both. See Chapter 25 for complete information
on using IPv6 addresses.
Disabling a VLAN stops all traffic on all ports associated with the specified VLAN.
You cannot disable any VLAN that is running any Layer 2 protocol traffic at all.
When you attempt to disable a VLAN running Layer 2 protocol traffic (for example, the VLAN
accounting), the system returns a message similar to the following:
VLAN accounting cannot be disabled because it is actively use by an L2 Protocol
You can disable the default VLAN; ensure that this is necessary before disabling the default VLAN.
Although you can remove ports from a disabled VLAN, you cannot add ports to a disabled VLAN or
bind Layer 2 protocols to that VLAN.
When you attempt to add ports or bind L2 protocols to a disabled VLAN (for example, the VLAN
accounting), the system returns a message similar to the following:
VLAN accounting is disabled. Enable VLAN before adding ports.
269
Virtual LANs
Named accounting
NOTE
Because VLAN names are unique, you do not need to enter the keyword vlan after you have created the unique
VLAN name. You can use the VLAN name alone (unless you are also using this name for another category such as
STPD or EAPS, in which case Extreme Networks recommends including the keyword vlan).
The following stand-alone switch example creates a port-based VLAN with an IPv6 address:
Named development
Ports 1, 2, and 3
The following modular switch example creates a protocol-based VLAN named ipsales. Slot 5, ports 6
through 8, and slot 6, ports 1, 3, and 4-6 are assigned to the VLAN. In this example, you can add
untagged ports to a new VLAN without first deleting them from the default VLAN, because the new
VLAN uses a protocol other than the default protocol.
create vlan ipsales
configure ipsales protocol ip
configure ipsales add port 5:6-5:8,6:1,6:3-6:6
The following modular switch example defines a protocol filter, myprotocol and applies it to the VLAN
named myvlan. This is an example only, and has no real-world application.
create protocol myprotocol
configure protocol myprotocol add etype 0xf0f0
configure protocol myprotocol add etype 0xffff
create vlan myvlan
configure myvlan protocol myprotocol
270
The show command displays information about each VLAN, which includes:
Name
VLANid
Enabled or disabled
STPD information
Protocol information
NetLogin information
Ports assigned
EAPs information
ESRP information
IP forwarding information
Multicasting information
271
Virtual LANs
Use the detail option to display the detailed format.
NOTE
To display IPv6 information, you must use either the show vlan detail command or show vlan command
with the name of the specified VLAN.
You can display additional useful information on VLANs configured with IPv6 addresses by issuing the
show ipconfig ipv6 vlan <vlan_name>. The following is sample output from this command:
BD10K # show ipconfig ipv6 my_ipv6_100
Router Interface on my_ipv6_100 is enabled and up. MTU: 1500
Locally registered unicast addresses:
2001:db8::8:802:200c:417a/64
fe80::230:48ff:fe41:ed97%my_ipv6_100/64
Flags:
IPv6 Forwarding: YES Accept recvd RA: NO
Send redirects: NO Accept redirects: NO
Protocol name
Type
Value
Tunneling (VMANs)
NOTE
Beginning with ExtremeWare XOS version 11.4, you can configure many aspects of VMANs using ACLs on the
BlackDiamond 10K and 12804 switch. See Chapter 14 for complete information on ACLs.
This section describes how to configure the virtual metropolitan area network (VMAN) feature,
discussed in the IEEE 802.1ad specification, and contains the following topics:
272
Tunneling (VMANs)
Overview
Beginning with ExtremeWare XOS software version 11.3, you can assign an IP address (including IPv6
addresses) to a specified VMAN. You assign an IP address to a specified VMAN using the following
command (insert the VMAN name, rather than a VLAN name):
configure vlan <vlan_name> ipaddress [<ipaddress> {<ipNetmask>} | ipv6-link-local |
{eui64} <ipv6_address_mask>]
You can tunnel any number of 802.1Q and/or Cisco ISL VLANs into a single VLAN that can be
switched through an Extreme Networks Ethernet infrastructure. A given tunnel is completely isolated
from other tunnels or VLANs. For the metropolitan area network (MAN) provider, the tagging numbers
and methods used by the customer are transparent to the provider.
You establish a private path through the public network using the Extreme Networks VMAN feature,
which creates a bidirectional virtual data connection. A given tunnel switches Layer 2 traffic; the
specified tunnel traffic is completely isolated from other traffic or tunnels. This feature is useful in
building transparent private networks, or VMANs, that provide point-to-point or point-to-multipoint
connectivity across an Ethernet infrastructure. Using encapsulation, the routing nodes in the public
network are unaware that the transmission is part of a VMAN connection.
NOTE
You cannot configure Connectivity Fault Management (CFM) on ports you include in the VMAN.
To use the VMAN feature, you configure an encapsulation for all the traffic on the specified VMAN.
The encapsulation allows the VMAN traffic to be switched over an Layer 2 infrastructure. To
encapsulate the packet, the system adds a VMAN header that forms an outer VLAN header to the
Ethernet frame. The traffic is switched through the infrastructure based on the VMAN header. The
egress port of the entire VMAN removes the VMAN header, and the frame proceeds through the rest of
the network with the original VLAN header.
VMAN is enabled on the ports in the tunnel. When VMAN is enabled on a network port, that port adds
the VMAN tag to all ingressing frames, whether the frame is originally tagged or untagged. The
Ethernet type configured for the VMAN header applies to the entire switch; this value cannot be
configured per port. The default VMAN Ethernet type on Extreme Networks devices is 0x88a8.
If your VMAN transits a third-party device (other than an Extreme Networks device), you must
configure the EtherType as the Ethernet type that the third-party device uses.
The system adds a 4-byte VMAN header on all packets, both originally tagged and untagged packets
arriving at the VMAN port. Beginning with ExtremeWare XOS 11.3, the system supports all VMAN
EtherTypes, including the standard VLAN Ethernet type of 0x8100.
The VMAN tunnel begins at the ingress, or customer access, port and terminates at the egress, or trunk,
port. Traffic flows from the egress trunk port onto the network thereafter without the VMAN tag.
Ensure that all the switch-to-switch ports in the VMAN tunnel are configured as tagged ports.
Configure the VMAN ingress, or customer access, port as an untagged port (although this port does
accept tagged packets). You must configure the VMAN tunnel egress, or trunk, port as an untagged port
so that the VMAN header is stripped from the frame.
273
Virtual LANs
NOTE
You must configure the VMAN tunnel egress, or trunk, port as untagged so that the VMAN header is stripped from
the frame.
Each tunnel port that accesses the user can support (or belong to) only one VMAN tunnel; the remaining
ports throughout the VMAN tunnel can support many VMANs.
VMANs on the BlackDiamond 8800 Family of Switches and the Summit X450
Switch Only
You must enable jumbo frames before configuring the VMANs on the BlackDiamond 8800 family of
switches (formerly known as Aspen) and the Summit X450 switch. On these switches, you enable jumbo
frames on the entire switch; you cannot enable jumbo frames on separate ports. See Chapter 5 for more
information on configuring jumbo frames on these devices.
Beginning with ExtremeWare XOS 11.4, you can configure VMANs and VLANs on the same module or
on the same stand-alone switch after you configure the VMAN Ethernet type as 0x8100. You must
specifically configure this VMAN Ethernet type; the default VMAN Ethernet type is 0x88a8. If you
attempt to configure VMANs and VLANs on the same module or stand-alone box without changing the
Ethernet type to 0x8100, the system returns an error. Depending on which (VLAN/VMAN) you are
trying to add, the system returns the following error message:
Error: Port X;X cannot be added to (Vlan/vMan) XXX because ports on slot X are (vMan/
Vlan) members and the vMan ethertype is not 8100.
NOTE
You must configure the VMAN Ethernet type as 0x8100 to configure VMANs and VLANs on the same module or
stand-alone switch. The default VMAN Ethernet type is 0x88a8.
If you already configured VLANs and VMANs on the same module or stand-alone switch, you cannot
change the VMAN Ethernet type from 0X8100 without first removing either the VLAN or VMAN
configuration.
Before ExtremeWare XOS version 11.4, you cannot configure both VLANs and VMANs on the same slot
on the BlackDiamond 8800 family of switches; all ports on each slot must belong exclusively to either
VLANs or VMANs. If you do configure both VLANs and VMANs on the same slot, the system returns
an error message. The VMAN can span multiple modules, but you cannot configure VLANs and
VMANs on the same module. Also, on the Summit X450 switch, you cannot configure both VLANs and
VMANs on the same switch; all ports on each discrete Summit X450 switch must belong exclusively to
either VLANs or VMANs.
VMAN multicasting with IP addresses. Beginning with ExtremeWare XOS software version 11.4, you can
use a common uplink to carry both VLAN and VMAN traffic and provide multicast services from a
VMAN through a separate VLAN. The VMAN traffic cannot be double-tagged if you want to use IP
multicast routing between VMANs and VLANs. You can also perform IGMP snooping on packets that
arrive untagged on VMAN ports for multicast registration.
274
Tunneling (VMANs)
To enable this configuration:
1 Enable jumbo frames on the switch.
2 Configure the VMAN Ethernet type to be 0x8100.
3 Assign an IP address to both the VLAN and VMAN.
4 Enable IP forwarding on both the VLAN and VMAN.
5 Enable IP multicast forwarding on both the VLAN and VMAN.
6 Enable and configure multicasting on both the VLAN and VMAN.
NOTE
See Chapter 31 for information on configuring and using multicasting.
After you enable multicast forwarding on the VMAN, you can configure and use IGMP snooping.
VMANs on the BlackDiamond 10K Switch and BlackDiamond 12804 Switch Only
NOTE
Beginning with ExtremeWare XOS version 11.4, you can use ACLs to create and configure VMANs on the
BlackDiamond 10K series and 12804 switches. See Chapter 14 for more information on using ACLs for VMANs.
The system automatically enables the specified ports for jumbo frames when you add ports to the
VMANs.
On the BlackDiamond 10K and 12804 switch, all ports added to a specified VMAN must be in the same
virtual router. For more information on displaying, configuring, and using virtual routers, see
Chapter 12.
VMAN multicasting with IP addresses. Beginning with ExtremeWare XOS software version 11.3, you can
assign an IP address to a specified VMAN to enable multicasting. To enable multicasting on the
specified VMAN after you have assigned an IP address:
1 Enable IP forwarding.
2 Enable IP multicast forwarding.
3 Enable and configure multicasting.
NOTE
See Chapter 31 for information on configuring and using multicasting.
After you enable multicast forwarding on the VMAN, you can configure and use IGMP snooping.
275
Virtual LANs
Egress Queue on the BlackDiamond 8800 Family of Switches and the Summit X450
Switch Only
On the BlackDiamond 8800 family of switches and the Summit X450 switch with VMAN packets, you
can configure the switch to examine the packets inner 802.1p tag and use that value to direct the packet
to the appropriate queue on the egress port. To configure this feature, use the following command:
enable dot1p examination inner-tag port [all | <port_list>]
To return to the default value of ignoring the 802.1p value on the inner tag, use the following command:
disable dot1p examination inner-tag ports [all | <port_list>]
NOTE
See Chapter 16 for information on configuring and displaying the current 802.1p and DiffServ configuration for the
inner, or original header, 802.1p value.
By default, the system on the BlackDiamond 8800 family of switches and the Summit X450 switch uses
the 802.1p value on the outer VMAN header to direct the packet to the queue on the egress port.
Each tunnel port that accesses the user, or customer port, can support (or belong to) only one VMAN
tunnel; the remaining ports throughout the VMAN tunnel can support many VMANs.
Duplicate customers MAC address ingressing from multiple VMAN ports may disrupt the port
learning association process in the switch.
276
VLANs
VMANs
IPv6 tunnels
Tunneling (VMANs)
SVLANs
BVLANs
Configuring VMANs
You configure VMANs slightly differently on the BlackDiamond 10K and 12804 switch and on the
BlackDiamond 8800 family of switches and the Summit X450 switch.
Before Extreme Ware XOS version 11.4 on the BlackDiamond 8800 family of switches, you could not
configure both VLANs and VMANs on the same slot on the BlackDiamond 8800 family of switches; all
ports on each slot had to belong exclusively to either VLANs or VMANs. If you did configure both
VLANs and VMANs on the same slot, the system returned an error message. The VMAN was able to
span multiple modules, but the same module could not have both VLANs and VMANs. Similarly, each
discrete Summit X450 switch had to have all ports belonging to either VLANs or VMANs; you could
not have VMAN and VLAN ports on the same switch.
Because the BlackDiamond 8800 family of switches and the Summit X450 switch enable jumbo frames
switch-wide, you enable jumbo frames before configuring VMANs on that system.
To configure a VMAN:
1 Enable jumbo frames on the switch.
2 Change the VMAN Ethernet type to 0x8100 if you want to configure VLANs and VMANs on the
same module or stand-alone box.
3 Create the tunnel by creating the VMAN.
4 Assign a tag value to the VMAN.
5 Add the ports in the tunnel to the VMAN.
6 Configure VMAN member ports as tagged on switch-to-switch ports and untagged on the ingress
and egress ports of the tunnel.
NOTE
You must configure the VMAN tunnel egress, or trunk, port as untagged so that the VMAN header is stripped from
the frame.
7 Configure the switch to use the 802.1p value on the inner tag to assign the packet to the appropriate
egress queue on the egress port, if desired.
8 If you want to configure multicasting on a specified VMAN:
a Ensure that you changed the VMAN Ethernet type to 0x8100.
b Assign different IP addresses to the VLAN and the VMAN.
277
Virtual LANs
c
d Configure IGMP.
278
Tunneling (VMANs)
Engineering &
Science Building
BlackDiamond 10808
BlackDiamond 6808
EX_101
The VMAN is from the building to port 1, slot 1 on the BlackDiamond 10808 switch and from port 1,
slot 6 on the BlackDiamond 10808 switch to the BlackDiamond 6808 switch:
create vman vman_tunnel_1
configure vman vman_tunnel_1 tag 100
configure vman vman_tunnel_1 add port 1:1 untagged
configure vman vman_tunnel_1 add port 6:1 tagged
configure vlan vman_tunnel ipaddress 10.120.120.120.1/24
enable ipforwarding vman_tunnel_1
enable ipmcforwarding vman_tunnel_1
279
Virtual LANs
Engineering &
Science Building
Aspen 8810
BlackDiamond 6808
XOS001
The VMAN is from the building to port 1, slot 3 on the BlackDiamond 8810 switch and from port 2, slot
3 on the BlackDiamond 8810 switch to the BlackDiamond 6808 switch:
enable jumbo frames
create vman vman_tunnel_1
configure vman vman_tunnel_1 tag 100
configure vman vman_tunnel_1 add port 3:1 untagged
configure vman vman_tunnel_1 add port 3:2 tagged
enable dot1p examination inner-tag port 3:2
The following example configuration demonstrates configuring IP multicast routing between VMANs
and VLANs (when VMAN traffic is not double-tagged) on the BlackDiamond 8800 family of switches
and the Summit X450 switch. Using this configuration you can use a common uplink to carry both
VLAN and VMAN traffic and to provide multicast services from a VMAN through a separate VLAN
(notice that port 1:1 is in both a VLAN and a VMAN):
enable jumbo-frame ports all
configure vman ethertype 0x8100
create vlan mc_vlan
configure vlan mc_vlan tag 77
create vman vman1
configure vman vman1 tag 88
configure vlan vman1 ipaddress 10.0.0.1/24
configure vlan mc_vlan ipaddress 11.0.0.1/24
enable ipforwarding vman1
enable ipforwarding mc_vlan
enable ipmcforwarding vman1
enable ipmcforwarding mc_vlan
configure vlan mc_vlan add port 1:1 tag
configure vman vman1 add port 1:1 tag
configure vman vman1 add port 2:1, 2:2, 2:3
NOTE
IGMP reports can be received untagged on ports 2:1, 2:2, and 2:3. Tagged IP multicast data is received on mc_vlan
port 1:1 and is routed using IP multicasting to vman1 ports that subscribe to the IGMP group.
280
Tunneling (VMANs)
NOTE
IGMP snooping (Layer 2 IP multicasting forwarding) does not work on the VMAN ports because there is no doubletagged IP multicast cache look capability from port 1:1.
The following is sample output from the show vman test command on a modular switch:
VLAN Interface with name test created by user
Admin State: Enabled
Tagging:Untagged (Internal tag 4090)
Priority:
802.1P Priority 0
Virtual router: VR-Default
Primary IP
: 10.10.255.3/24
IPv6:
NONE
STPD:
None
Protocol:
Match all unfiltered protocols
Loopback:
Disable
NetLogin:
Enabled
Rate Shape:
Disable
281
Virtual LANs
QosProfile:
QP1
Ports:
2.
(Number of active ports=2)
Flags:
(*) Active, (!) Disabled
(g) Load Sharing port
Untag:
*3:1
Tag:
*3:2
The display from the show vman detail command shows all the information shown in the show vman
<vlan_name> command, but displays information for all configured VMANs.
To display the EtherType, use the following command:
show vman <vman_name> ethertype
The following is sample output from the show vman etherType command:
vMan EtherType: 0x88a8
NOTE
You use this command to display the Ethernet type for MAC-in-MAC tunneling (802.1ah) also.
The following is sample output when you use the show vman ethertype command and you have
configured MAC-in-MAC tunnels:
BlackDiamond 12804.41 # show vman etherType
vman EtherType : 0x88a8
bvlan EtherType: 0x88b5
282
Beginning with ExtremeWare XOS version 11.4, the software anticipates the emerging IEEE 802.1ah
Backbone Bridge standard, also known as MAC-in-MAC tunneling. This standard allows Internet
Service Providers (ISPs) to use Ethernet to create a separate backbone over which the subscribers
frames are transported (see Figure 17).
NOTE
You must use IEEE 802.1ad VMAN tunneling (also known as Q-in-Q tunneling) in tandem with this feature. The
802.1ah-configured switch can receive and transmit only 802.1ad frames.
User networks
IEEE 802.1ah
Core backbone
IEEE 802.1ad
ISP
User networks
ISP
Bridge
Bridge
Bridge
Bridge
Laptop
Servers
Each provider has a separate ID (the service ID), or ISID. This ISID maps to the I-tag on the 802.1ah
frame; thus allowing many more S-tags than the VMAN-limited 4094. These tools permit true
hierarchical scaling and full isolation of provider infrastructure from subscriber broadcast domains.
This feature works with the service provider having already created a service ID tag, using VMAN
tagging, to isolate the traffic for a particular customer; this tag is referred to as the S-tag (the original
customer tag is referred to as the C-tag). Then the 802.1ah prepends L2 information onto the existing
VMAN frame, which creates a MAC-in-MAC tunnel or provider backbone, for the ISP to send all its
traffic through the network (see Figure 18).
283
Virtual LANs
The 802.1ah frame maps and replaces the original service provider tag (S-tag) on the 802.1ad frame to an
I-tag on the 802.1ah frame. This mapping allows many more S-tags than the 4094 limited by VMANs; it
allows duplicate S-tags on different ingress ports, each of which is mapped to a different I-tag on the
802.1ah frame. The Ethernet type of the 802.1ah frame is 0x88B5 by default; you can change this by
configuring with the CLI.
B-DA
B-SA B-TAG
I-TAG
DATA
FCS
FCS
I-tagused to identify the service provider in the scope of MAC-in-MAC (the BVLAN is the tunnel
inside of which the system uses the I-tag to identify the service provider using the I-tag to S-tag
mapping and replacement)
In the Extreme Networks implementation, the original VLAN tag is the customers VLAN and remains
unchanged from end-to-end.
Figure 19 shows more detail on the information in the B-TAG and I-TAG areas of the 802.1ah frame.
B-SA
B-TAG
88A8
I-TAG
10
88B5
S-TAG value
802.1ad frame
FCS
1000
ISID value
(mapped S-TAG to I-TAG value)
EW_115B
You configure an SVLAN, which carries the traffic for the specific service provider and is identified by
the S-tag on the 802.1ad, or VMAN, packet. Using 802.1ah, the system maps the S-tag (on the original
VMAN packet) to the I-tag on the 802.1ah frame using the ISID, if configured, or just by copying the
original S-tag value into the I-tag. You must configure an ISID if you have duplicate S-tag values on the
same BVLAN ingressing port or if you need more than 4094 S-tag values for one BVLAN.
Then, you configure a backbone VLAN, or BVLAN, which the ISP uses as a separate backbone for all
the service traffic. Finally, you associate the specified SVLAN with the ISPs BVLAN.
284
NOTE
There is no interaction between the STPs of the ISP and the subscriber. The subscribers BPDUs are tunneled
through the ISP backbone.
The B-VLAN tag identifies the ISPs backbone MAC-in-MAC tunnel, over which the subscribers frames
are transported, and the service ID identifies the service provider in the ISPs network. The ISP switches
traffic based on its backbone bridge MAC addresses. The service providers frames are tunneled by the
MAC-in-MAC feature; the ISP and service provider networks are isolated.
You can also view MAC-in-MAC tunneling as a Layer 2 multipoint tunnel. The backbone interface is the
tunnel entry point and multiple subscribers traffic can be tunneled through the MAC-in-MAC tunnel.
The default Ethernet type for MAC-in-MAC, or 802.1ah, frames is 0x88B5 (the default Ethernet type for
VMAN, or 802.1ad, frames is 0x88A8). If you choose to configure the MAC-in-MAC Ethernet type to
another value than the default 0x88B5, ensure that the 802.1ah Ethernet type is different than the
802.1ad Ethernet type of your switch. You can change the 802.1ah Ethernet type from the default
0x88A0 value by issuing the configure bvlan ethertype <value> command.
NOTE
Ensure that the Ethernet types are different for 802.1ah and 802.1ad on your switch; the default values are
different on the Extreme Networks devices.
You can use any physical topology on the core backbone network, or BVLAN. Although you can assign
IP addresses to backbone interfaces to test connectivity, do not enable IP forwarding. The BVLAN must
be tagged, and only tagged ports can be added to the BVLAN.
Each SVLAN carries the traffic for a different service provider, or service instance. Within the SVLAN,
or VMAN, the customer VLANs remain untouched. The SVLAN is a pure Layer 2 VMAN, which is
transparent to users. Do not install Layer 2 control protocols on these interfaces because all BPDUs are
tunneled through the 802.1ah, or MAC-in-MAC, tunnel. Do not assign any IP addresses to these SVLAN
interfaces and ensure that IP forwarding is disabled.
When you configure the MAC-in-MAC tunnels using the CLI, the system automatically installs dynamic
ACLs. Although these ACLs are not user-configurable, you will see these ACLS displayed when you
use the show access-list dynamic rules command. (See Chapter 14 for information on ACLs.)
285
Virtual LANs
In case of a failover from MSM A to MSM B, the network traffic for this feature is not interrupted at all.
The system has hitless failovernetwork traffic not interrupted in case of a failover.
The ExtremeWare XOS software supports only the B format encapsulation without FCS.
The ExtremeWare XOS software does not support Drop Eligible Indicator (DEI) in the B-tag or the
I-tag.
You can use the same SVLAN tags (duplicate SVLAN tags) on one BVLAN as long as they use
different ingressing BVLAN ports.
You cannot configure Connectivity Fault Management (CFM), based on IEEE standard 802.1ag, on
ports in the SVLAN or BVLAN.
You cannot have overlapping ports when you add an SVLAN to a BVLAN. You cannot have any of
the same ports on a specific SVLAN that you add to a specific BVLAN.
Sentriant-installed ACLs
CFM-installed ACLs
MAC-in-MAC-installed ACLs
ACLs applied with a policy file (see Chapter 14 for precedence among these ACLs)
NOTE
For information on policy files and ACLs, see Chapter 13 and Chapter 14, respectively.
If you choose to change the Ethernet type for the 802.1ah, or MAC-in-MAC frames, Extreme Networks
recommends changing the value before any other 802.1ah configuration. Changing the 802.1ah Ethernet
type may cause the system to flush both the FDB and the MAC-binding tables. To change the 8021.ah
Ethernet type from the default value of 0X88B5, use the following command:
configure bvlan ethertype <value>
286
To configure the BVLAN by adding a tag and adding ports, using the following commands:
configure bvlan <blvan-name> tag <tag>
configure bvlan <blvan-name> add ports <port_list> tagged
NOTE
You must tag the ports you add to the BVLAN.
To delete the BLVAN or any ports assigned to it, use the following commands:
delete bvlan <bvlan-name>
You configure the SVLAN by assigning it a tag and adding ports, which can be either tagged or
untagged. To do this, use the following commands:
configure svlan <svlan-name> tag <tag>
configure svlan <svlan-name> add ports <port_list> {tagged | untagged}
You can assign a specific ISID to each SVLAN in the BVLAN; if you do not assign an ISID, the system
uses the value in the S-tag as the value in the I-tag. Each ISID in the BVLAN must be unique. To
configure the ISID for the SVLAN, use the following command:
configure svlan <svlan-name> isid <isid>
NOTE
You must configure an ISID if you have duplicate S-tag values on the same BVLAN ingressing port or if you need
more than 4094 S-tag values for one BVLAN.
To delete the SVLAN or to remove ports from the SVLAN, use the following commands:
delete svlan <slvan-name>
287
Virtual LANs
To clear the database that binds the BVLAN MAC address and the MAC address for all the customer
host MAC addresses behind the BVLAN, use the following command:
clear mac-binding {bvlan <bvlan-name> {<bridge-mac>} | svlan <svlan-name> <customermac>}
The following is an example of the display from the show bvlan <bvlan_name> command:
BVLAN Interface with name test created by user
Admin State:
Enabled
Tagging:Untagged (Internal tag 4091)
Priority:
802.1P Priority 0
Virtual router: VR-Default
IPv6:
None
STPD:
None
Protocol:
Match all unfiltered protocols
288
Disabled
Disabled
QP1
Backbone
0
(Number of active ports=0)
The display from the show bvlan detail command shows all the information shown in the show
bvlan <bvlan_name> command, but displays information for all configured BVLANs.
The following is an example of the display from the show svlan command:
* BD-10808.8 # show svlan
-------------------------------------------------------------------------------------Name
VID Protocol Addr
Flags
Proto Ports Virtual
Active router
/Total
-------------------------------------------------------------------------------------servtest
4090 -------------------- ----------------S
ANY
0 /0 VR-Default
-------------------------------------------------------------------------------------Flags : (C) EAPS Control vlan, (E) ESRP Enabled, (f) IP Forwarding Enabled,
(i) ISIS Enabled, (I) IP Forwarding lpm-routing Enabled, (L) Loopback
Enabled, (m) IPmc Forwarding Enabled,
(n) IP Multinetting Enabled, (N) Network LogIn vlan,
(o) OSPF Enabled, (p) PIM Enabled,
(P) EAPS protected vlan, (r) RIP Enabled, (T) Member of STP Domain,
(v) VRRP Enabled, (B) 802.1ah Backbone VMAN, (S) 802.1ah Service VMAN
Total number of svlan(s) : 1
The following is sample output for the show svlan <svlan_name> command when you are displaying
a service VLAN (SVLAN) for a MAC-in-MAC tunnel:
BlackDiamond 12804.36 # show svlan servtest
SVLAN Interface with name servtest created by user
Admin State:
Enabled
Tagging:
Priority:
802.1P Priority 0
Virtual router: VR-Default
IPv6:
None
STPD:
None
Protocol:
Match all unfiltered protocols
Loopback:
Disable
NetLogin:
Disabled
Rate Shape:
Disable
QosProfile:
QP1
Dot1ah Mode:
Service
I-SID:
250
In Backbone:
backbone
Ports:
0.
(Number of active ports=0)
NOTE
If you did not configure an ISID, the I-SID line does not display. (The system uses the value of the S-tag if you do
not optionally configure an ISID.)
289
Virtual LANs
The display from the show svlan detail command shows all the information shown in the show
svlan <svlan_name> command, but displays information for all configured SVLANs.
The following is an example of the display from the show vman etherType command when you
configure MAC-in-MAC tunnels (802.1ah):
BlackDiamond 12804.41 # show vman etherType
vman EtherType : 0x88a8
bvlan EtherType: 0x88b5
AGE
60
Port
2:1
290
S1 tag 10
S1 tag 10
S2 tag 10
S2 tag 10
S3 tag 30
S3 tag 30
BlackDiamond
Edge 1
BlackDiamond
Edge 2
VMAN1
Port 5:5 tag
Backbone
core switch
B1 tag 100
EX_112A
NOTE
You must enable jumbo frames on all ports before configuring MAC-in-MAC tunneling.
To configure MAC-in-MAC tunneling for this example, use the following CLI commands:
create svlan s1
create svlan s2
create svlan s3
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
create bvlan b1
configure bvlan
configure bvlan
configure bvlan
s1
s2
s3
s1
s2
s3
s1
s2
s3
tag 10
tag 10
tag 30
add port 1:1 untagged
add port 1:2 tagged
add port 1:3 tagged
isid 1000
isid 2000
isid 3000
b1 tag 100
b1 add port 2:2 tagged
b1 add svlan s1
291
Virtual LANs
configure bvlan b1 add svlan s2
configure bvlan b1 add svlan s3
create svlan s1
create svlan s2
create svlan s3
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
configure svlan
create bvlan b1
configure bvlan
configure bvlan
configure bvlan
configure bvlan
configure bvlan
s1
s2
s3
s1
s2
s3
s1
s2
s3
tag 10
tag 10
tag 30
add port 4:1 untagged
add port 4:2 tagged
add port 4:3 tagged
isid 1000
isid 2000
isid 3000
b1
b1
b1
b1
b1
tag
add
add
add
add
100
port 3:1 tagged
svlan s1
svlan s2
svlan s3
On the Summit X450 switch (core MAC-in-MAC tunnel backbone), use the following commands:
After you have accomplished these CLI commands, the switches will have configurations detailed in the
following paragraphs.
The BlackDiamond 12804 switch (backbone edge 1) has the following configuration:
A BVLAN, or backbone VLAN, named B1 tag100 and port 2:2 tagged added to that BVLAN
The BlackDiamond 10K switch (backbone edge 2) has the following configuration:
A BVLAN, or backbone VLAN, named B1 tag100 and port 3:1tagged added to that BVLAN
The core backbone switch (core MAC-in-MAC tunnel backbone) has the following configuration:
292
Port 5:4 is connected to the BlackDiamond 12804 switch BVLAN b1 port 2:2.
Port 5:5 is connected to the BlackDiamond 10K switch BVLAN b1 port 3:2.
293
Virtual LANs
294
11 Forwarding Database
This chapter describes the following topics:
Multicast FDB with Multiport EntrySummit X450 Switch and BlackDiamond 8800 Chassis Only on
page 302
The switch maintains a database of all MAC addresses received on all of its ports. It uses the
information in this database to decide whether a frame should be forwarded or filtered.
This section describes the following topics:
FDB Contents
Each Forwarding Database (FDB) entry consists of:
Flags
Frames destined for MAC addresses that are not in the FDB are flooded to all members of the VLAN.
295
Forwarding Database
The switch can learn entries by examining packets it receives. The system updates its FDB with the
source MAC address from a packet, the VLAN, and the port identifier on which the source packet is
received.
The ability to learn MAC addresses can be enabled or disabled on a port-by-port basis.
You can also limit the number of addresses that can be learned, or you can lock down the current
entries and prevent additional MAC address learning.
NOTE
For more information on port control for learning MAC address, refer to Chapter 5.
You can enter and update entries using the command line interface (CLI).
Certain static entries are added by the system upon switch boot-up.
Dynamic entriesA dynamic entry is learned by the switch by examining packets to determine the
source MAC address, VLAN, and port information. The switch then creates or updates an FDB entry
for that MAC address. Initially, all entries in the database are dynamic, except for certain entries
created by the switch at boot-up.
Entries in the database are removed (aged-out) if, after a period of time (aging time), the device has
not transmitted. This prevents the database from becoming full with obsolete entries by ensuring
that when a device is removed from the network, its entry is deleted from the database. Dynamic
entries are flushed and relearned (updated) when any of the following take place:
A VLAN is deleted.
A port is disabled.
A non-permanent dynamic entry is initially created when the switch identifies a new source MAC
address that does not yet have an entry in the FDB. The entry may then be updated as the switch
continues to encounter the address in the packets it examines. These entries are identified by the d
flag in show fdb output.
Dynamic entries agethat is, a dynamic entry is removed from the FDB (aged-out) if the device
does not transmit for a specified period of time (the aging time). This aging process prevents the
FDB from becoming full with obsolete entries by ensuring that when a device is removed from the
network, its entry is deleted from the database. The aging time is configurable. For more information
about setting the aging time, see Configuring the FDB Aging Time on page 298.
296
Static entriesA static entry does not age and does not get updated through the learning process. A
static entry is maintained exactly as it was created. Conditions that cause dynamic entries to be
updated, such as VLAN or port configuration changes, do not affect static entries.
A locked static entry is an entry that was originally learned dynamically, but has been made static
(locked) using the MAC address lock-down feature. It is identified by the s, p, and l flags in
show fdb output and can be deleted using the delete fdbentry command. See MAC Address
Lock Down on page 397 for more information about MAC address lock-down.
If the FDB entry aging time is set to 0, all entries in the database are considered static, non-aging
entries. This means that the entries do not age, but they are still deleted if the switch is reset.
NOTE
On the BlackDiamond 8800 family of switches (formerly known as Aspen) and the Summit X450 switch, if the same
MAC address is detected on another virtual port that is not defined in the static FDB entry for the MAC address,
that address is handled as a blackhole entry.
Permanent entriesPermanent entries are retained in the database if the switch is reset or a power
off/on cycle occurs. Permanent entries must be created by the system administrator through the CLI.
Permanent entries are static, meaning they do not age or get updated.
On the BlackDiamond 8800 family of switches and the Summit X450 switch, if the MAC address
00:E0:2B:12:34:56 is encountered on any port/VLAN other than VLAN marketing, port 3:4, that address will be
handled as a blackhole entry, and packets from that source will be dropped.
297
Forwarding Database
If the aging time is set to 0, all aging entries in the database are defined as static, nonaging entries. This
means the entries will not age out, but non-permanent static entries can be deleted if the switch is reset.
Supported aging is between 15 and 1,000,000 seconds. The default is 5 minutes (300 seconds).
Specified ports
Specified VLANs,
To clear dynamic entries from the FDB, use the following command:
clear fdb {<mac_addr> | ports <port_list> | vlan <vlan_name> | blackhole}
Specified VLANs
To clear permanent entries from the FDB, use the following command:
delete fdbentry [all | <mac_address> [vlan <vlan name>]
netloginDisplays all FDBs created as a result of the netlogin process. You can display all of these
298
MAC-Based Security
NOTE
The MAC-based VLAN netlogin parameter applies only for the Summit X450 switch and the BlackDiamond 8800
family of switches. See Chapter 18 for more information on netlogin.
permanentDisplays all permanent entries, including the ingress and egress QoS profiles.
ports <portlist>Displays the entries for a set of ports or slots and ports.
statsDisplays the number of static, permanent, dynamic, and dropped entries; as well as the
aging time.
With no options, the command displays all FDB entries. (The age parameter does not show on the
display for the backup MSM on modular switches; it does show on the display for the primary MSM.)
MAC-Based Security
MAC-based security allows you to control the way the FDB is learned and populated. By managing
entries in the FDB, you can block and control packet flows on a per-address basis.
MAC-based security allows you to limit the number of dynamically-learned MAC addresses allowed
per virtual port. You can also lock the FDB entries for a virtual port, so that the current entries will
not change, and no additional addresses can be learned on the port.
You can also prioritize or stop packet flows based on the source MAC address of the ingress VLAN or
the destination MAC address of the egress VLAN.
NOTE
For detailed information about MAC-based security, see Chapter 17.
If MAC address learning is disabled, only broadcast traffic, EDP traffic, and packets destined to a
permanent MAC address matching that port number, are forwarded. Use this command in a secure
environment where access is granted via permanent FDBs per port. Disabling learning on a port causes
the MAC addresses to flood (unless you disable egress flooding) because those addresses will not be
present in the FDB during a destination lookup.
299
Forwarding Database
Disabling MAC Address Learning on the BlackDiamond 8800 Family of Switches and
the Summit X450 Switch Only.
When learning is disabled, packets with unknown source MAC addresses are dropped.
NOTE
Disabling egress flooding can affect many protocols, such as IP and ARP among others.
Figure 21 illustrates a case where you want to disable Layer 2 egress flooding on specified ports to
enhance security and network performance.
Client 1
EXOS Switch
Access VLAN
Access Link
port 2
Client 2
XOS004A
In this example, the three ports are in an ISP-access VLAN. Ports 1 and 2 are connected to clients 1 and
2, respectively, and port 3 is an uplink to the ISP network. Because clients 1 and 2 are in the same
VLAN, client 1 could possible learn about the other clients traffic by sniffing client 2s broadcast traffic;
client 1 could then possibly launch an attack on client 2.
However, when you disable all egress flooding on ports 1 and 2, this sort of attack is impossible, for the
following reasons:
300
Broadcast and multicast traffic from the clients is forwarded only to the uplink port.
Any packet with unlearned destination MAC addresses is forwarded only to the uplink port.
One client cannot learn any information from the other client. Because egress flooding is disabled on
the access ports, the only packets forwarded to each access port are those packets that are specifically
targeted for one of the ports. There is no traffic leakage.
MAC-Based Security
In this way, the communication between client 1 and client 2 is controlled. If client 1 needs to
communicate with client 2 and has that IP address, client 1 sends out an ARP request to resolve the IP
address for client 2.
Egress flooding can be disabled on ports that are in a load-sharing group. If that is the situation, the
ports in the group take on the egress flooding state of the master port; each member port of the loadsharing group has the same state as the master port.
FDB learning is independent of egress flooding; either can be enabled or disabled independently.
Disabling unicast (or all) egress flooding to a port also stops packets with unknown MAC addresses
to be flooded to that port.
Disabling broadcast (or all) egress flooding to a port also stops broadcast packets to be flooded to
that port.
Disabling Egress Flooding on the BlackDiamond 8800 Family of Switches and the
Summit X450 Switch Only
You can enable or disable egress flooding for unicast, multicast, or broadcast MAC addresses, as well as
for all packets on the ports of the BlackDiamond 8800 family of switches (formerly known as Aspen) or
the Summit X450 switch.
Disabling multicasting egress flooding does not affect those packets within an IGMP membership group
at all; those packets are still forwarded out. If IGMP snooping is disabled, multicast packets with static
FDB entries are forwarded according to the FDB entry.
To enable egress flooding for these switches, use the following command:
enable flooding [all_cast | broadcast | multicast | unicast] port [<port_list> | all]
Disabling Egress Flooding on the BlackDiamond 10K and 12804 Switch Only
You must enable or disable egress flooding on all packets on the specified port or ports. You cannot
specify broadcast, unicast, or multicast packets; the egress flooding command applies to all packets.
Disabling multicasting egress flooding does not affect those packets within an IGMP membership group
at all; those packets are still forwarded out. If IGMP snooping is disabled, multicast packets are not
flooded.
To enable egress flooding on the BlackDiamond 10K switch, use the following command:
enable flooding all_cast port [<port_list> | all]
To disable egress flooding on the BlackDiamond 10K switch, use this command:
disable flooding all_cast port [<port_list> | all]
301
Forwarding Database
NOTE
When you disable egress flooding on the BlackDiamond 10K or 12804 switch, you also turn off broadcasting.
Flags
Link
Link Num Num Num
Jumbo QOS
Load
State ELSM UPS STP VLAN Proto Size profile Master
=============================================================================
3:1
Em------e-- ready
0
0
1
1
9216
==============================================================================
Flags : a - Load Sharing Algorithm address-based, D - Port Disabled,
e - Extreme Discovery Protocol Enabled, E - Port Enabled,
g - Egress TOS Enabled, j - Jumbo Frame Enabled,
l - Load Sharing Enabled, m - MACLearning Enabled,
n - Ingress TOS Enabled, o - Dot1p Replacement Enabled,
P - Software redundant port(Primary),
R - Software redundant (Redundant),
q - Background QOS Monitoring Enabled,
s - diffserv Replacement Enabled,
v - Vman Enabled, f - Unicast Flooding Enabled
M - Multicast Flooding Enabled, B - Broadcast Flooding Enabled
L - Extreme Link Status Monitoring Enabled
NOTE
The BlackDiamond 10K series and 12804 switches have an additional flag: p - Load Sharing Algorithm
port-based.
302
12 Virtual Routers
This chapter describes the following topics:
Using Virtual RoutersBlackDiamond 10K and BlackDiamond 12804 Switches Only on page 306
NOTE
The term virtual router is also used with the Virtual Router Redundancy Protocol (VRRP). VRRP uses the term to
refer to a single virtual router that spans more than one physical router, which allows multiple switches to provide
redundant routing services to users. For more information about VRRP, see Chapter 22.
303
Virtual Routers
User virtual routers are supported only on the BlackDiamond 10K and BlackDiamond 12804 switches.
VR-Mgmt
VR-Mgmt enables remote management stations to access the switch through Telnet, SSH, and SNMP
sessions; and it owns the management port. No other ports can be added to this VR-Mgmt, and the
management port cannot be removed from it.
The Mgmt VLAN is created in the VR-Mgmt during the ExtremeWare XOS system boot-up. No other
VLAN can be created in this virtual router, and the Mgmt VLAN cannot be deleted from it.
No routing protocol is running or can be added to this virtual router.
This virtual router is called VR-0 in ExtremeWare XOS releases before 11.0.
VR-Control
VR-Control is used for internal communications between all the modules and subsystems in the
switch. It has no external visible ports, and you cannot assign any port to it.
This virtual router, VR-Control, has no VLAN interface, and no VLAN can be created for it.
No routing protocol is running or can be added to this virtual router.
This virtual router is called VR-1 in ExtremeWare XOS releases before 11.0.
VR-Default
VR-Default is the default virtual router created by the ExtremeWare XOS system. All data ports in
the switch are assigned to this virtual router by default. Any data port can be added to and deleted
from this virtual router.
Users can create and delete VLANs in this virtual router. The Default VLAN is created in this virtual
router during the ExtremeWare XOS system boot-up. The Default VLAN cannot be deleted from this
virtual router.
One instance of each routing protocol is spawned for this virtual router during the ExtremeWare
XOS system boot-up, and these routing instances cannot be deleted.
This virtual router is called VR-2 in ExtremeWare XOS releases before 11.0.
304
305
Virtual Routers
A virtual router name cannot be the same as a VLAN name. You cannot name a user virtual router with
the names VR-Mgmt, VR-Control, or VR-Default because these are the existing default system virtual
routers. For backward compatibility, user virtual routers also cannot be named VR-0, VR-1 or VR-2,
because these three names are the names for the system virtual routers in ExtremeWare XOS releases
before 11.0.
To delete a user virtual router, use the following command:
delete virtual-router <vr-name>
Before you delete a virtual router, you must delete all VLANs created in that virtual router. All of the
ports assigned to this virtual router will be deleted and made available to assign to other virtual routers.
Any routing protocol that is running on the virtual router will be shut down and deleted gracefully.
306
The following is an example of removing all the ports on slot 3 from the default VLAN in the default
virtual router and adding them for the exclusive use of the virtual router helix:
configure vlan default delete ports 3:*
configure vr vr-default delete ports 3:*
configure vr helix add ports 3:*
In the following example we add port 3:5 to the virtual routers VR-green and VR-blue. Weve already
created the tagged VLAN bldg_200 in VR-green, and the tagged VLAN bldg_300 in VR-blue.
configure
configure
configure
configure
307
Virtual Routers
For example, to enter the configuration domain for the virtual router helix, your CLI session would look
similar to this:
* BD10K.13 # virtual-router helix
* (vr helix) BD10K.14 #
If you do not specify a virtual router in the create vlan command, the VLAN is created in the virtual
router of the current configuration domain.
NOTE
All VLAN names and VLAN IDs on a switch must be unique, regardless of the virtual router they are created in. You
cannot have two VLANs with the same name, even if they are in different virtual routers.
To display the VLANs in a specific virtual router, use the following command:
show vlan virtual router <vr-name>
You can also configure routing protocols, by using the standard ExtremeWare XOS commands. The
routing configurations of the different virtual routers are independent of each other.
308
Ports are removed from the VLAN Default and the virtual router VR-Default.
The configuration domain is set to helix, so that subsequent virtual router commands affect the
virtual router helix.
Ports that belong to the virtual router helix are added to the VLAN helix-accounting.
The CLI prompt is shown in this example to show how the virtual router configuration domain is
displayed. At the end of the example, the virtual router is ready to be configured for OSPF, using
ExtremeWare XOS commands.
*
*
*
*
*
*
*
*
*
309
Virtual Routers
310
13 Policy Manager
This chapter describes the following topics:
Policy Manager
One of the processes that make up the ExtremeWare XOS system is the policy manager. The policy
manager is responsible for maintaining a set of policy statements in a policy database and
communicating these policy statements to the applications that request them.
Policies are used by the routing protocol applications to control the advertisement, reception, and use of
routing information by the switch. Using policies, a set of routes can be selectively permitted (or
denied) based on their attributes, for advertisements in the routing domain. The routing protocol
application can also modify the attributes of the routing information, based on the policy statements.
Policies are also used by the access control list (ACL) application to perform packet filtering and
forwarding decisions on packets. The ACL application will program these policies into the packet
filtering hardware on the switch. Packets can be dropped, forwarded, moved to a different QoS profile,
or counted, based on the policy statements provided by the policy manager.
When you create a policy file, name the file with the policy name that you will use when applying the
policy, and use .pol as the filename extension. For example, the policy name boundary refers to the
text file boundary.pol.
311
Policy Manager
There are many commands available with the editor. For information about the editor commands, use
any tutorial or documentation about VI. The following is only a short introduction to the editor.
Edit operates in one of two modes; command and input. When a file first opens, you are in the
command mode. To write in the file, use the keyboard arrow keys to position your cursor within the
file, then press one of the following keys to enter input mode:
To escape the input mode and return to the command mode, press the Escape key.
Several commands can be used from the command mode. The following commands are the most
commonly used:
Checking Policies
A policy file can be checked to see if it is syntactically correct. To check the policy syntax, use the
following command:
check policy <policy-name> {access-list}
This command can only determine if the syntax of the policy file is correct and can be loaded into the
policy manager database. Since a policy can be used by multiple applications, a particular application
may have additional constraints on allowable policies.
312
Applying Policies
Refreshing Policies
When a policy file is changed (such as adding, deleting an entry, adding/deleting/modifying a
statement), the information in the policy database does not change until the policy is refreshed. The user
must refresh the policy so that the latest copy of policy is used.
When the policy is refreshed, the new policy file is read, processed, and stored in the server database.
Any clients that use the policy are updated. To refresh the policy, use the following command:
refresh policy <policy-name>
For ACL policies only, during the time that an ACL policy is refreshed, packets on the interface are
blackholed, by default. This is to protect the switch during the short time that the policy is being
applied to the hardware. It is conceivable that an unwanted packet could be forwarded by the switch as
the new ACL is being setup in the hardware. You can disable this behavior. To control the behavior of
the switch during an ACL refresh, use the following commands:
enable access-list refresh blackhole
disable access-list refresh blackhole
In releases previous to ExtremeWare XOS 11.4, when ACLs were refreshed, all the ACL entries were
removed, and new ACL entries were created to implement the newly applied policy. Beginning in
release 11.4, the policy manager uses Smart Refresh to update the ACLs. When a change is detected,
only the ACL changes needed to modify the ACLs are sent to the hardware, and the unchanged entries
remain. This behavior avoids having to blackhole packets because the ACLs have been momentarily
cleared. Smart Refresh works well for minor changes, however, if the changes are too great, the refresh
reverts to the earlier behavior. To take advantage of Smart Refresh, disable access-list refresh
blackholing.
Applying Policies
ACL policies and routing policies are applied using different commands.
If you use the any keyword, the ACL is applied to all the interfaces and is referred to as the wildcard
ACL. This ACL is evaluated for any ports without specific ACLs, and it is also applied to any packets
that do not match the specific ACLs applied to the interfaces.
If an ACL is already configured on an interface, the command will be rejected and an error message
displayed.
313
Policy Manager
To remove an ACL from an interface, use the following command:
unconfigure access-list {any | ports <portlist> | vlan <vlanname>} {ingress | egress}
To display which interfaces have ACLs configured, and which ACL is on which interface, use the
following command:
show access-list {any | ports <portlist> | vlan <vlanname>} {ingress | egress}
Commands that use the keyword route-policy control the routes advertised or received by the
protocol. For BGP and RIP, here are some examples:
configure bgp neighbor [<remoteaddr> | all] {address-family [ipv4-unicast | ipv4multicast]} route-policy [in | out] [none | <policy>]
configure bgp peer-group <peer-group-name> route-policy [in | out] [none | <policy>]
configure rip vlan [<vlan-name> | all] route-policy [in | out] [<policy-name> | none]
314
VMAN ACLsBlackDiamond 10K and BlackDiamond 12804 Switches Only on page 323
Conserving ACL Masks and RulesBlackDiamond 8800 Family and Summit X450 Only on page 331
ACLs
ACLs are used to perform packet filtering and forwarding decisions on traffic traversing the switch.
Each packet arriving on an ingress port and/or VLAN is compared to the access list applied to that
interface and is either permitted or denied. On the BlackDiamond 10K and the BlackDiamond 12804
switches, packets egressing an interface can also be filtered. However, only a subset of the filtering
conditions available for ingress filtering are available for egress filtering. In addition to forwarding or
dropping packets that match an ACL, the switch can also perform additional operations like
incrementing counters, logging packet headers, mirroring traffic to a monitor port, sending the packet to
a QoS profile, and, for the BlackDiamond 8800 family and Summit X450 switches only, meter the
packets to control bandwidth. Using ACLs has no impact on switch performance (with the minor
exception of the mirror-cpu action modifier).
ACLs are typically applied to traffic that crosses Layer 3 router boundaries, but it is possible to use
access lists within a Layer 2 virtual LAN (VLAN).
ACLs in ExtremeWare XOS apply to all traffic. This is somewhat different from the behavior in
ExtremeWare. For example, if you deny all the traffic to a port, no traffic, including control packets, such
as OSPF or RIP, will reach the switch and the adjacency will be dropped. You must explicitly allow
those type of packets (if desired). In ExtremeWare, an ACL that denied all traffic would allow control
packets (those bound for the CPU) to reach the switch.
ACLs are created in two different ways. One method is to create an ACL policy file and apply that ACL
policy file to a list of ports, a VLAN, or to all interfaces. This first method creates ACLs that can be
persistent across switch reboots, can contain a large number of rule entries, and are all applied at the
same time. See ACL Policy File Syntax on page 316 for information about creating ACLs using policy
files. For information about creating policy files, see Chapter 13, Policy Manager.
The second method to create an ACL is to use the CLI to specify a single rule, called a dynamic ACL.
Dynamic ACLs do not persist across a reboot and consist of only a single rule. Multiple dynamic ACLs
can be applied to an interface, and the precedence of the ACLs is determined as they are being
configured. See Dynamic ACLs on page 325 for information about creating dynamic ACLs.
315
Zero or one action (permit or deny). If no action is specified, the packet is permitted by default.
ACL rule entries are evaluated in order, from the beginning of the file to the end, as follows:
If the packet matches all the match conditions, the action in the then statement is taken and the
evaluation process terminates.
For ingress ACLs, if a rule entry does not contain any match condition, the packet is considered to
match and the action in the rule entrys then statement is taken and the evaluation process
terminates. For egress ACLs, if a rule entry does not contain any match condition, no packets will
match. See Matching All Egress Packets for more information.
If the packet matches all the match conditions, and if there is no action specified in the then
statement, the action permit is taken by default.
If the packet does not match all the match conditions, the next rule entry in the ACL is evaluated.
This process continues until either the packet matches all the match conditions in one of the
subsequent rule entries or there are no more entries.
If a packet passes through all the rule entries in the ACL without matching any of them, it is
permitted.
Often an ACL will have a rule entry at the end of the ACL with no match conditions. This entry will
match any ingress packets not otherwise processed, so that user can specify an action to overwrite the
default permit action.
316
ACLs
Matching All Egress Packets. Unlike ingress ACLs, for egress ACLs, you must specify either a source or
destination address, instead of writing a rule with no match conditions.
For example, an ingress ACL deny all rule could be:
entry DenyAllIngress{
if {
} then {
deny;
}
}
The previous rule would not work as an egress ACL. The following is an example of an egress ACL
deny all rule:
entry DenyAllEgress{
if {
source-address 0.0.0.0/0;
} then {
deny;
}
}
317
Match Conditions
You can specify multiple, single, or zero match conditions. If no match condition is specified, all packets
match the rule entry. Among the match conditions commonly used are:
Actions
The actions are:
The default action is permit, so if no action is specified in a rule entry, the packet is forwarded.
Action Modifiers
Additional actions can also be specified, independent of whether the packet is dropped or forwarded.
These additional actions are called action modifiers. Not all action modifiers are available on all
switches, and not all are available for both ingress and egress ACLs. The action modifiers are:
count <countername>Increments the counter named in the action modifier (ingress only)
meter <metername>Takes action depending on the traffic rate (BlackDiamond 8800 family and
Summit X450 switches only)
mirrorSends a copy of the packet to the monitor (mirror) port (ingress only)
qosprofile <qosprofilename>Forwards the packet to the specified QoS profile (ingress only)
12804R only)
redirect <ipv4 addr>Forwards the packet to the specified IPv4 address (BlackDiamond 10K
and BlackDiamond 12804 only)
replace-dscpReplace the packets DSCP field with the value from the associated QoS profile
replace-dot1pReplace the packets 802.1p field with the value from the associated QoS profile
To count packets: When the ACL entry match conditions are met, the specified counter is incremented.
The counter value can be displayed by the command:
show access-list counter {<countername>} {any | ports <portlist> | vlan <vlanname>}
{ingress | egress}
To log packets: Packets are logged only when they go to the CPU, so packets in the fastpath are not
automatically logged. You must use both the mirror-cpu action modifier and the log or log-raw action
modifier if you want to log both slowpath and fastpath packets that match the ACL rule entry.
318
ACLs
Additionally, KERN:INFO messages are not logged by default. You must configure the EMS target to
log these messages. See Chapter 9, Status Monitoring and Statistics, for information about configuring
EMS.
To meter packets: BlackDiamond 8800 Family and Summit X450 OnlyFor the BlackDiamond 8800
family and Summit X450 switches, the meter <metername> action modifier associates a rule entry with
an ACL meter. See the section, Metering Using ACLsBlackDiamond 8800 Family of Switches,
Summit X450 Switch, and BlackDiamond 12804 R-Series Switch Only on page 368 for more
information.
To mirror packets: You must enable port-mirroring on your switch. See the section, Switch Port
Mirroring on page 140. If you attempt to apply a policy that requires port-mirroring, you will receive
an error message if port-mirroring is not enabled.
To redirect packets: BlackDiamond 10K and BlackDiamond 12804 OnlyPackets are forwarded to the
IPv4 address specified, without modifying the IP header. The IPv4 address must be in the IP ARP cache,
otherwise the packet is forwarded normally. Only fast path traffic can be redirected. This capability can
be used to implement Policy Based Routing.
You may want to create a static ARP entry for the redirection IP address, so that there will always be a
cache entry.
To replace DSCP or 802.1p fields: Specify a QoS profile for matching packets. The field values are
replaced with the value associated with that profile. In the following example, DiffServ replacement is
configured such that QP8 is mapped to code point 56. Matching packets are sent to QP8, and the DSCP
value in the packet is set to 56:
entry voice_entry {
if {
source-address 2.2.2.2/32;
} then {
qosprofile qp8;
replace-dscp;
}
}
See Chapter 16, Quality of Service, for more details about QoS profiles, and 802.1p and DSCP
replacement.
Syntax Details
Table 39 lists the match conditions that can be used with ACLs, and whether the condition can be used
for ingress ACLs only, or with both ingress and egress. The conditions are case-insensitive; for example,
the match condition listed in the table as TCP-flags can also be written as tcp-flags. Within Table 39
are five different data types used in matching packets. Table 40 lists the data types and details on using
them.
319
Match Conditions
Description
ethernet-type <number>
Ethernet/
Ingress only
ethernet-source-address
<mac-address>
Ethernet/
Ingress only
ethernet-destination-address
<mac-address> <mask>
Ethernet/
Ingress only
ethernet-destination-address 00:01:02:03:01:01
ff:ff:ff:ff:00:00
Only those bits of the MAC address whose corresponding bit in
the mask is set to 1 will be used as match criteria. So, the
example above will match 00:01:02:03:xx:xx.
If the mask is not supplied then it will be assumed to be
ff:ff:ff:ff:ff:ff. In other words, all bits of the MAC address will be
used for matching.
320
source-address <prefix>
All IP/
Ingress and
Egress
destination-address <prefix>
All IP/
Ingress and
Egress
protocol <number>
All IP/
Ingress and
Egress
fragments
All IP, no L4
rules/Ingress
only
first-fragments
All IP/
Ingress only
Source-port {<number> |
<range>}
TCP or UDP source port. In place of the numeric value, you can
specify one of the text synonyms listed under destination port.
TCP, UDP/
Ingress and
Egress
ACLs
Match Conditions
Description
Destination-port {<number> |
<range>}
TCP, UDP/
Ingress and
Egress
TCP-flags <bitfield>
TCP/Ingress
and Egress
IGMP-msg-type <number>
IGMP message type. Possible values and text synonyms: v1report(0x12), v2-report(0x16), v3-report(0x22), V2-leave (0x17),
or query(0x11).
IGMP/
Ingress and
Egress
ICMP-type <number>
ICMP/Ingress
and Egress
321
Match Conditions
Description
ICMP-code <number>
ICMP/Ingress
and Egress
Parameter-problem:
ip-header-bad(0), required-option-missing(1)
Redirect:
redirect-for-host (1), redirect-for-network (2), redirect-for-tosand-host (3), redirect-for-tos-and-net (2)
Time-exceeded:
ttl-eq-zero-during-reassembly(1), ttl-eq-zero-during-transit(0)
Unreachable:
communication-prohibited-by-filtering(13), destination-hostprohibited(10), destination-host-unknown(7), destinationnetwork-prohibited(9), destination-network-unknown(6),
fragmentation-needed(4), host-precedence-violation(14), hostunreachable(1), host-unreachable-for-TOS(12), networkunreachable(0), network-unreachable-for-TOS(11), portunreachable(3), precedence-cutoff-in-effect(15), protocolunreachable(2), source-host-isolated(8), source-route-failed(5)
IP-TOS <number>
IP TOS field. In place of the numeric value, you can specify one
of the following text synonyms (the field values are also listed):
minimize-delay 16 (0x10), maximize-reliability 4(0x04),
minimize-cost2 (0x02), and normal-service 0(0x00).
All IP/
Ingress and
Egress
DSCP <number>
All IP/
Ingress only
However, packets using the Ethernet type for VMANs, 0x88a8 by default, are handled by VMAN ACLs. See the section, VMAN
ACLsBlackDiamond 10K and BlackDiamond 12804 Switches Only for more information.
b. You can not specify an IPv6 address with a 128-bit mask (host entry) for the Summit X450.
NOTE
Directed ARP response packets cannot be blocked with ACLs from reaching the CPU and being learned on the
BlackDiamond 8800 family and Summit X450 switches.
322
ACLs
Along with the data types described in Table 40, you can use the operators <, <=, >, and >= to specify
match conditions. For example, the match condition, source-port > 190, will match packets with a
source port greater than 190. Be sure to use a space before and after an operator.
NOTE
The BlackDiamond 8800 family and Summit X450 support 128 rules per Gigabit Ethernet port and 1024 rules per
10 Gigabit Ethernet port. Certain features also use rules for their implementation. A single match condition can
require the creation of many rules, and may not be supported on these switches. For example, the match condition
source-port 1000 - 3000 requires creating 2000 rules, and is not supported on these switches. The match condition
source-port > 90 will also not work, as it requires a large number of rules to implement in the hardware. The match
condition source-port 100 - 200 could work, as it uses fewer than 120 rules to implement. See also the section,
Conserving ACL Masks and RulesBlackDiamond 8800 Family and Summit X450 Only, for further information on
ACL limits.
Description
prefix
IP source and destination address prefixes. To specify the address prefix, use the
notation prefix/prefix-length. For a host address, prefix-length should be
set to 32.
number
Numeric value, such as TCP or UDP source and destination port number, IP protocol
number.
range
A range of numeric values. To specify the numeric range, use the notation: number number
bit-field
Used to match specific bits in an IP packet, such as TCP flags and the fragment flag.
mac-address
323
Description
Direction
ccos <number>
Ingress and
Egress
cvid <number>
Ingress and
Egress
diffserv-codepoint <number>
Diffserv Codepoint.
Ingress only
Ingress and
Egress
scos <number>
Ingress and
Egress
svid <number>
Ingress and
Egress
tos <number>
IP TOS field.
Ingress only
An additional match condition, ethernet-destination-address, can also be used in VMAN ACLs, but
must not be the first match condition in an entry. This condition is listed in Table 39.
The default action is permit, so if no action is specified in a rule entry, the packet is forwarded.
Action Modifiers
Additional actions can also be specified, independent of whether the packet is dropped or forwarded.
These additional actions are called action modifiers. The action modifiers are:
count <countername>Increments the counter named in the action modifier (ingress only)
only)
324
qosprofile <qosprofilename>Forwards the packet to the specified QoS profile (ingress only)
stag-ethertype <ethertype>Modifies the VMAN Ethertype value, also called the S-Tag value
ACLs
12804R only)
To count packets: When the ACL entry match conditions are met, the specified counter is incremented.
The counter value can be displayed by the command:
show access-list counter {<countername>} {any | ports <portlist> | vlan <vlanname>}
{ingress | egress}
To control link usage: Any matching VMAN traffic that egresses a load sharing (link aggregation) group
can be forced to use the same link in the group for all traffic. The hash value range is 1 to 16. For
example, for a link aggregation hash of three, the matching VMAN traffic will go over link number
three. If the hash value is greater than the number of links, the value rolls over. For example, if the hash
value is six, the traffic will go over link six in an eight link group and over link two in a four link
group.
If a member link of a group goes down, the link indices are reassigned, so the traffic still goes over the
same link, but might be assigned to a different member link.
Dynamic ACLs
Dynamic ACLs are created using the CLI. They use a similar syntax and can accomplish the same
actions as single rule entries used in ACL policy files. More than one dynamic ACL can be applied to an
interface, and the precedence among the dynamic ACLs is determined as they are being configured.
Dynamic ACLs have a higher precedence than ACLs applied using a policy file.
325
As an example of creating a dynamic ACL rule, lets compare an ACL policy file entry with the CLI
command that creates the equivalent dynamic ACL rule. The following ACL policy file entry will drop
all ICMP echo-requests:
entry icmp-echo {
if {
protocol icmp;
icmp-type echo-request;
} then {
deny;
}
}
To create the equivalent dynamic ACL rule, use the following command:
create access-list icmp-echo protocol icmp;icmp-type echo-request deny
Notice that the conditions parameter is a quoted string that corresponds to the match conditions in the
if { ... } portion of the ACL policy file entry. The individual match conditions are concatenated into
a single string. The actions parameter corresponds to the then { ... } portion of the ACL policy file
entry.
From the command line, you can get a list of match conditions and actions by using the following
command:
check policy attribute {<attr>}
Limitations. Dynamic ACL rule names must be unique, but can be the same as used in a policy-file
based ACL. Any dynamic rule counter names must be unique. Dynamic ACLs only apply to ACLs and
do not apply to CLEAR-Flow rules.
326
ACLs
To remove a dynamic ACL from an interface, use the following command:
configure access-list delete <ruleName> [all | any | ports <portlist> | vlan
<vlanname>] {ingress | egress}
L2 ruleA rule containing only Layer 2 (L2) matching conditions, such as Ethernet MAC address
and Ethernet type
L3 ruleA rule containing only Layer 3 (L3) matching conditions, such as source or destination IP
address and protocol
L4 ruleA rule containing both Layer 3 (L3) and Layer 4 (L4) matching conditions, such as TCP/
UDP port number
NOTE
BlackDiamond 10K and BlackDiamond 12804 switches onlyL2 matching conditions cannot be mixed with L3/L4
matching conditions in a rule, otherwise, syntax checking will fail.
BlackDiamond 10K and BlackDiamond 12804 Only. When an ACL file contains both L2 and L3/L4 rules:
L3/L4 rules have higher precedence over L2 rules. L3/L4 rules are evaluated before any L2 rules.
The precedence among L3/L4 rules is determined by their relative position in the ACL file. Rules are
evaluated sequentially from top to bottom.
The precedence among L2 rules is determined by their position in the ACL file. Rules are evaluated
sequentially from top to bottom.
It is recommended that L2 and L3/L4 rules be grouped together for easy debugging.
BlackDiamond 8800 family and Summit X450 Only. Rule precedence is solely determined by the rules
relative order in the policy file. L2, L3, and L4 rules are evaluated in the order found in the file.
If the ACL is configured on port 1:2, the port-based ACL is evaluated and the evaluation process
terminates.
327
If the ACL is configured on the VLAN yellow, the VLAN-based ACL is evaluated and the evaluation
process terminates.
If the wildcard ACL is configured, the wildcard ACL is evaluated and evaluation process terminates.
In summary, the port-based ACL has highest precedence, followed by the VLAN-based ACL and then
the wildcard ACL.
fragmentsFO field > 0 (FO means the fragment offset field in the IP header.)BlackDiamond 10K
and BlackDiamond 12804 only.
first-fragmentsFO == 0.
Policy file syntax checker. The fragments keyword cannot be used in a rule with L4 information. The
syntax checker will reject such policy files.
An L3-only rule that does not contain either the fragments or first-fragments keyword matches
any IP packets.
An L4 rule that does not contain either the fragments or first-fragments keyword matches nonfragmented or initial-fragment packets.
With the fragment keyword specified (BlackDiamond 10K and BlackDiamond 12804 only):
An L3-only rule with the fragments keyword only matches fragmented packets.
An L3-only rule with the first-fragments keyword matches non-fragmented or initial fragment
packets.
An L4 rule with the first-fragments keyword matches non-fragmented or initial fragment packets.
328
To display which interfaces have ACLs configured, and which ACL is on which interface, use the
following command:
show access-list {any | ports <portlist> | vlan <vlanname>} {ingress | egress}
The following rule entry accepts TCP packets from the 10.203.134.0/24 subnet with a source port larger
than 190 and ACK & SYN bits set and also increments the counter tcpcnt. The packets will be forwarded
using QoS profile QP3. This example will only work with the BlackDiamond 10K and BlackDiamond
12804, since the match condition source-port > 190 alone will create more than 118 rules in the
hardware:
entry tcpacl {
if {
source-address 10.203.134.0/24;
protocol TCP;
source-port > 190;
tcp-flags syn_ack;
329
The following example denies ICMP echo request (ping) packets originating from the 10.203.134.0/24
subnet, and increments the counter icmpcnt:
entry icmp {
if {
source-address 10.203.134.0/24;
protocol icmp;
icmp-type echo-request;
} then {
deny;
count icmpcnt;
}
}
The following example prevents TCP connections from being established from the 10.10.20.0/24 subnet,
but allows established connections to continue, and allows TCP connections to be established to that
subnet. A TCP connection is established by sending a TCP packet with the SYN flag set, so this example
blocks TCP SYN packets. This example emulates the behavior of the ExtremeWare permit-established
ACL command:
entry permit-established {
if {
source-address 10.10.20.0/24;
protocol TCP;
tcp-flags syn;
} then {
deny;
}
}
The following entry denies every packet and increments the counter default:
entry default {
if {
} then {
deny;
count default;
}
}
The following entry permits only those packets with destination MAC addresses whose first 32 bits
match 00:01:02:03:
entry rule1 {
if {
ethernet-destination-address 00:01:02:03:01:01 ff:ff:ff:ff:00:00 ;
} then {
permit ;
}
}
330
331
In this example, the only difference between policy1.pol and policy2.pol is that rule entries two and
three are swapped. Policy1.pol consumes three masks since there are no adjacent rules with the same
match criteria. Policy2.pol consumes two masks since rules one and three are adjacent and have
identical match criteria. However, policy1.pol and policy2.pol have different meanings because of
precedence.
With this being said, you have to be careful to avoid wasting masks. For example consider the following
policy:
policy3.pol:
entry one {
if {
source-address 1.1.1.1/32;
} then {
count debug;
}
}
entry two {
if {
protocol tcp;
destination-port 23;
} then {
deny;
}
}
entry three {
if {
source-address 2.2.2.2/32;
} then {
deny;
}
}
332
The only difference between policy3.pol and policy4.pol is that rule entries two and three are swapped.
The two policies have the same effect, but policy4.pol does not unnecessarily consume an ACL mask.
Mask and Rule Use by Feature: Additionally, certain non-ACL features allocate ACL masks and use ACL
rules in order to function. Here are is a list by feature:
DiffServ examination1 mask, 64 rules for 10G ports; 0 masks, 0 rules for 1G ports (disabled by
default)
EAPS1 master config + 1 transit config masks, 1 + number of transit-mode EAPS domains on the
port rules
333
NOTE
The above list of mask and rule usage changed from that in ExtremeWare XOS 11.3. In release 11.4, VRRP mask
and rule usage was reduced, dot1p examination could be disabled, and diffserv for 1 G ports did not require any
masks or rules.
To display the number of masks and rules used by a particular port, use the following command:
show access-list usage [acl-mask | acl-rule] port <port>
334
15 Routing Policies
This chapter describes the following topics:
Routing Policies
Routing policies are used to control the advertisement or recognition of routes using routing protocols,
such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), or Border Gateway
Protocol (BGP). Routing policies can be used to hide entire networks or to trust only specific sources
for routes or ranges of routes. The capabilities of routing policies are specific to the type of routing
protocol involved, but these policies are sometimes more efficient and easier to implement than access
lists.
Routing policies can also modify and filter routing information received and advertised by a switch.
Zero or one match type. If no type is specified, the match type is all, so all match conditions must be
satisfied.
Zero or more match conditions. If no match condition is specified, then every routing entity matches.
335
Routing Policies
nlri 10.204.134.0/24;
} then {
next-hop
192.168.174.92;
origin
egp;
}
}
Policy entries are evaluated in order, from the beginning of the file to the end, as follows:
if the action contains an explicit permit or deny, the evaluation process terminates.
if the action does not contain an explicit permit or deny, then the action is an implicit permit, and
the evaluation process terminates.
If a match does not occur, then the next policy entry is evaluated.
If no match has occurred after evaluating all policy entries, the default action is deny.
Often a policy will have a rule entry at the end of the policy with no match conditions. This entry will
match anything not otherwise processed, so that user can specify an action to override the default deny
action.
The next sections list detailed information about policy match conditions, about matching BGP AS
paths, and about action statements. For information on those subjects, see the following sections:
match allAll the match conditions must be true for a match to occur. This is the default.
Description
336
Routing Policies
Description
med <number>;
Where <ipaddress> and <mask> are IP addresses, <masklength> is an integer, and keyword any matches any IP
address with a given (or larger) mask/mask-length.
tag <number>;
Autonomous system expressions. The AS-path keyword uses a regular expression string to match against
the autonomous system (AS) path. Table 43 lists the regular expressions that can be used in the match
conditions for Border Gateway Path (BGP) AS path and community. Table 44 shows examples of regular
expressions and the AS paths they match.
Definition
As number
N1 - N2
[Nx ... Ny]
Matches 0 or 1 instance
337
Routing Policies
Definition
Regular Expression
Example Matches
AS path is 1234
1234
1234
1234*
1234
1234 1234
10 12 { 34
10 12 34 { 99
33 10 12 { 34 37
12 } 34
12 } 34 56
^99 34
99 34 45
99 $
45 66 99
4 5 6 .*
456456789
.* 4 5 6 $
456
123456
Here are some additional examples of using regular expressions in the AS-Path statement.
The following AS-Path statement matches AS paths that contain only (begin and end with) AS number
65535:
as-path "^65535$"
The following AS-Path statement matches AS paths beginning with AS number 65535, ending with AS
number 14490, and containing no other AS paths:
as-path "^65535 14490$"
The following AS-Path statement matches AS paths beginning with AS number 1, followed by any AS
number from 2 - 8, and ending with either AS number 11, 13, or 15:
as-path "^1 2-8 [11 13 15]$"
The following AS-Path statement matches AS paths beginning with AS number 111 and ending with
any AS number from 2 - 8:
as-path "111 [2-8]$"
The following AS-Path statement matches AS paths beginning with AS number 111 and ending with
any additional AS number, or beginning and ending with AS number 111:
as-path "111 .?"
338
Routing Policies
Description
community remove;
cost <cost(0-4261412864)>;
deny;
local-preference <number>;
next-hop <ipaddress>;
permit;
tag <number>;
weight <number>
339
Routing Policies
Commands that use the keyword route-policy control the routes advertised or received by the
protocol. For BGP and RIP, here are some examples:
configure bgp neighbor [<remoteaddr> | all] {address-family [ipv4-unicast | ipv4multicast]} route-policy [in | out] [none | <policy>]
configure bgp peer-group <peer-group-name> route-policy [in | out] [none | <policy>]
configure rip vlan [<vlan-name> | all] route-policy [in | out] [<policy-name> | none]
Policy Examples
The following sections contain examples of policies. The examples are:
340
Action
permit
permit
deny
permit
deny
IP Address
22.16.0.0
192.168.0.0
any
10.10.0.0
22.44.66.0
IP Mask
255.252.0.0
255.255.192.0
255.0.0.0
255.255.192.0
255.255.254.0
Exact
No
Yes
No
No
Yes
Routing Policies
Equivalent ExtremeWare XOS policy map definition:
entry entry-5 {
If {
nlri
22.16.0.0/14;
}
then {
permit;
}
}
entry entry-10 {
if {
nlri
192.168.0.0/18 exact;
}
then {
permit;
}
}
entry entry-15 {
if {
nlri
any/8;
}
then {
deny;
}
}
entry entry-20 {
if {
nlri
10.10.0.0/18;
}
then {
permit;
}
}
entry entry-25 {
if {
nlri
22.44.66.0/23
}
then {
deny;
}
}
exact;
The policy above can be optimized by combining some of the if statements into a single expression. The
compact form of the policy will look like this:
entry permit_entry {
If match any {
nlri
22.16.0.0/14;
nlri
192.168.0.0/18 exact ;
nlri
10.10.0.0/18;
}
341
Routing Policies
then {
permit;
}
}
entry deny_entry {
if match any {
nlri
any/8;
nlri
22.44.66.0/23
}
then {
deny;
}
}
exact;
342
Routing Policies
}
entry
if
entry-20
{
community
{
6553800;
}
then {
deny;
}
}
entry
if
entry-30
{
med
30;
}
then {
next-hop 10.201.23.10;
as-path 20;
as-path 30;
as-path 40;
as-path 40;
permit;
}
}
entry
if
entry-40
{
}
then {
local-preference 120;
weight 2;
permit;
}
}
entry
if
}
then {
dampening half-life 20 reuse-limit 1000 suppress-limit 3000 max-suppress 40
permit;
}
}
entry
if
entry-60 {
{
next-hop 192.168.1.5;
}
then {
community
permit;
}
add
949616660;
343
Routing Policies
entry deny_rest {
if {
}
then {
deny;
}
}
344
16 Quality of Service
This chapter describes the following topics:
Metering Using ACLsBlackDiamond 8800 Family of Switches, Summit X450 Switch, and
BlackDiamond 12804 R-Series Switch Only on page 368
Egress Traffic Rate LimitingBlackDiamond 8800 Family of Switches and Summit X450 Switch Only
on page 370
Applying Egress Bandwidth to a PortBlackDiamond 10K Series and 12804 Switch Only on
page 371
Policy-based Quality of Service (QoS) is a feature of ExtremeWare XOS and the Extreme Networks
switch architecture that allows you to specify different service levels for traffic traversing the switch.
Policy-based QoS is an effective control mechanism for networks that have heterogeneous traffic
patterns. Using Policy-based QoS, you can specify the service level that a particular traffic type receives.
NOTE
Specifying the level of service for specified traffic types may be referred to as Class of Service (CoS).
345
Quality of Service
On the BlackDiamond 10K and the 12804 switch, the switch contains separate hardware queues on
every physical port. On the BlackDiamond 8800 family of switches (formerly known as Aspen) and the
Summit X450 switch, the switch has two default queues (based on flows), and you can configure up to
six additional queues. Each queue is programmed by ExtremeWare XOS with specific parameters that
modify the forwarding behavior of the switch and affect how the switch transmits traffic for a given
queue on a physical port.
The switch tracks and enforces the specified parameters on every queue for every port. When two or
more queues on the same physical port are contending for transmission, the switch prioritizes use so
long as the respective queue management parameters are satisfied. Up to eight queues per port are
available.
NOTE
Policy-based QoS has no impact on switch performance. Using even the most complex traffic groupings has no cost
in terms of switch performance.
Voice applications
Video applications
General guidelines for each traffic type are given below and summarized in Table 46. Consider them as
general guidelines and not as strict recommendations. After QoS parameters have been set, you can
monitor the performance of the application to determine if the actual behavior of the applications
matches your expectations. It is very important to understand the needs and behavior of the particular
applications you want to protect or limit. Behavioral aspects to consider include bandwidth needs,
sensitivity to latency and jitter, and sensitivity and impact of packet loss.
Voice Applications
Voice applications, or voice over IP (VoIP), typically demand small amounts of bandwidth. However,
the bandwidth must be constant and predictable because voice applications are typically sensitive to
latency (inter-packet delay) and jitter (variation in inter-packet delay). The most important QoS
parameter to establish for voice applications is minimum bandwidth, followed by priority.
Video Applications
Video applications are similar in needs to voice applications, with the exception that bandwidth
requirements are somewhat larger, depending on the encoding. It is important to understand the
behavior of the video application being used. For example, in the playback of stored video streams,
some applications can transmit large amounts of data for multiple streams in one spike, with the
346
Table 46 summarizes QoS guidelines for the different types of network traffic.
Voice
Video
Database
Minimum bandwidth
Web browsing
File server
Minimum bandwidth
347
Quality of Service
Configuring QoS
NOTE
With software version 11.0, you can create access control lists (ACLs) with QoS actions. The QoS forwarding
information you configured in an ACL takes precedence over QoS configuration using the CLI commands.
If you are using ACLs for QoS actions, please note that the ACLs on a port are evaluated in the
following order:
Sentriant-installed ACLs
CFM-installed ACLs
MAC-in-MAC-installed ACLs
ACLs applied with a policy file (see Chapter 14 for precedence among these ACLs)
NOTE
For information on policy files and ACLs, see Chapter 15 and Chapter 14, respectively.
To configure QoS, you define how your switch responds to different categories of traffic by creating and
configuring QoS profiles. You then group traffic into categories (according to the needs of the
application, as previously discussed) and assign each category to a QoS profile. Configuring QoS is a
three-step process:
1 Configure the QoS profile.
QoS profileA class of service that is defined through minimum and maximum bandwidth
parameters and prioritization settings on the BlackDiamond 10K and 12804 switch or through
configuration of buffering and scheduling settings on the BlackDiamond 8800 family of switches and
the Summit X450 switch. The level of service that a particular type of traffic or traffic grouping
receives is determined by assigning it to a QoS profile. The names of the QoS profiles are QP1
through QP8; these names are not configurable.
2 Create traffic groupings.
Traffic groupingA classification or traffic type that has one or more attributes in common. These
can range from a physical port to IP Layer 4 port information. You assign traffic groupings to QoS
profiles to modify switch forwarding behavior. Traffic groupings transmitting out the same port that
are assigned to a particular QoS profile share the assigned characteristics and hence share the class of
service.
3 Monitor the performance of the application with the QoS monitor to determine whether the policies
are meeting the desired results.
348
QoS Profiles
The following considerations apply only to QoS on the BlackDiamond 8800 family of switches and the
Summit X450 switch:
The BlackDiamond 8800 family of switches and the Summit X450 switch do not support QoS
monitor.
The following QoS features share resources on the BlackDiamond 8800 family of switches and the
Summit X450 switch:
ACLs
DiffServ
dot1p
VLAN-based QoS
Port-based QoS
You may receive an error message when configuring a QoS feature in the above list on the
BlackDiamond 8800 family of switches and the Summit X450 switch; it is possible that the shared
resource is depleted. In this case, unconfigure one of the other QoS features and reconfigure the one
you are working on.
QoS Profiles
QoS profiles are configured differently:
On the BlackDiamond 8800 family of switches and the Summit X450 switch
349
Quality of Service
The parameters that make up a QoS profile on the BlackDiamond 8800 family of switches and the
Summit X450 switch include:
BufferThis parameter is the maximum amount of packet buffer memory available to all packets
associated with the configured QoS profile within all affected ports. All QoS profiles use 100% of
available packet buffer memory by default. You can configure the buffer amount from 1 to 100%, in
whole integers. Regardless of the maximum buffer setting, the system does not drop any packets if
any packet buffer memory remains to hold the packet and the current QoS profile buffer use is
below the maximum setting.
NOTE
Use of all eight queues on all ports may result in insufficient buffering to sustain 0 packet loss throughput
during full-mesh connectivity with large packets.
WeightThis parameter is the relative weighting for each QoS profile; 1 through 16 are the available
weight values. The default value for each QoS profile is 1, giving each queue equal weighting. When
you configure a QoS profile with a weight of 4, that queue is serviced four times as frequently as a
queue with a weight of 1. However, if you configure all QoS profiles with a weight of 16, each queue
is serviced equally but for a longer period of time.
Finally, you configure the scheduling method that the entire switch will use to empty the queues. The
scheduling applies globally to the entire switch, not to each port. You can configure the scheduling to be
strict priority, which is the default, or weighted round robin. In the strict priority method, the switch
services the higher-priority queues first. As long as a queued packet remains in a higher-priority queue,
any lower-priority queues are not serviced. If you configure the switch for weighted-round-robin
scheduling, the system services all queues based on the weight assigned to the QoS profile. The
hardware services higher-weighted queues more frequently, but lower-weighted queues continue to be
serviced at all times.
When configured to do so, the priority of a QoS profile can determine the 802.1p bits used in the
priority field of a transmitted packet (see Replacing 802.1p priority information on page 355). The
priority of a QoS profile determines the DiffServ code point value used in an IP packet when the packet
is transmitted (see Replacing DiffServ code points on page 359).
A QoS profile switch does not alter the behavior of the switch until it is assigned to a traffic grouping.
The default QoS profiles cannot be deleted. The settings for the default QoS parameters on the
BlackDiamond 8800 family of switches and the Summit X450 switch are summarized in Table 47.
Table 47: Default QoS profile parameters on the BlackDiamond 8800 family of switches and the
Summit X450 switch
350
Profile name
Priority
Buffer
Weight
QP1
Low
100%
QP8
High
100%
QoS Profiles
Minimum bandwidthThe minimum total link bandwidth that is reserved for use by a hardware
queue on a physical port (each physical port has eight hardware queues, corresponding to a QoS
profile). The minimum bandwidth value is configured either as a percentage of the total link
bandwidth or using absolute committed rates in Kbps or Mbps. Bandwidth unused by the queue can
be used by other queues. The minimum bandwidth for all queues should add up to less than 100%.
The default value on all minimum bandwidth parameters is 0%.
Maximum bandwidthThe maximum total link bandwidth that can be transmitted by a hardware
queue on a physical port (each physical port has eight hardware queues, corresponding to a QoS
profile). The maximum bandwidth value is configured either as a percentage of the total link
bandwidth or using absolute peak rates in Kbps or Mbps. The default value on all maximum
bandwidth parameters is 100%.
PriorityThe level of priority assigned to a hardware egress queue on a physical port. There are
eight different available priority settings and eight different hardware queues. By default, each of the
default QoS profiles is assigned a unique priority. You use prioritization when two or more hardware
queues on the same physical port are contending for transmission on the same physical port, only
after their respective bandwidth management parameters have been satisfied. If two hardware
queues on the same physical port have the same priority, a round-robin algorithm is used for
transmission, depending on the available link bandwidth.
When configured to do so, the priority of a QoS profile can determine the 802.1p bits used in the
priority field of a transmitted packet (see Replacing 802.1p priority information on page 355).
The priority of a QoS profile determines the DiffServ code point value used in an IP packet when
the packet is transmitted (see Replacing DiffServ code points on page 359).
A QoS profile does not alter the behavior of the switch until it is assigned to a traffic grouping. Recall
that QoS profiles on the BlackDiamond 10K and 12804 switch are linked to hardware queues. There are
multiple hardware queues per physical port. By default, a QoS profile links to the identical hardware
queue across all the physical ports of the switch.
The default QoS profiles cannot be deleted. Also by default, a QoS profile maps directly to a specific
hardware queue across all physical ports. The settings for the default QoS parameters on the
BlackDiamond 10K and 12804 switch are summarized in Table 48.
Table 48: Default QoS profile parameters on the BlackDiamond 10K and 12804 switch
Profile name
Hardware queue
Priority
Minimum bandwidth
Maximum bandwidth
QP1
Q0
Low
0%
100%
QP2
Q1
LowHi
0%
100%
QP3
Q2
Normal
0%
100%
QP4
Q3
NormalHi
0%
100%
QP5
Q4
Medium
0%
100%
QP6
Q50
MediumHi
0%
100%
QP7
Q6
High
0%
100%
QP8
Q7
HighHi
0%
100%
351
Quality of Service
Traffic Groupings
After a QoS profile has been created or modified, you assign a traffic grouping to the profile. A traffic
grouping is a classification of traffic that has one or more attributes in common. Traffic is typically
grouped based on the needs of the applications discussed starting on page 346.
Traffic groupings are separated into the following categories for discussion:
ACL-based information
Explicit packet class of service information, such as 802.1p or DiffServ (IP TOS)
IP ACL
MAC ACL
802.1p
Physical/logical groupings
Source port
VLAN
NOTE
The source port and VLAN QoS apply only to untagged packets, and 802.1p QoS applies only to tagged packets. If
you use 802.1p or DiffServ QoS in conjunction with ACLs, you must configure the 802.1p or DiffServ action within
the ACL itself.
352
Traffic Groupings
802.1p
Physical/logical groupings
Source port
VLAN
The source port and VLAN QoS apply only to untagged packets, and 802.1p QoS applies only to tagged packets. If
you use 802.1p or DiffServ QoS in conjunction with ACLs, you must configure the 802.1p or DiffServ action within
the ACL itself.
IP protocol
TCP flag
IP fragmentation
Ethertype
ACL-based traffic groupings are defined using access lists. Access lists are discussed in detail in
Chapter 14. By supplying a named QoS profile on an ACL rule, you can prescribe the bandwidth
management and priority handling for that traffic grouping. This level of packet filtering has no impact
on performance.
353
Quality of Service
IP Differentiated Services (DiffServ) code points, formerly known as IP Type of Service (TOS) bits
An advantage of explicit packet marking is that the class of service information can be carried
throughout the network infrastructure, without repeating what can be complex traffic grouping policies
at each switch location. Another advantage is that endstations can perform their own packet marking
on an application-specific basis. Extreme Networks switch products have the capability of observing
and manipulating packet marking information with no performance penalty.
The documented capabilities for 802.1p priority markings or DiffServ capabilities (if supported) are not
impacted by the switching or routing configuration of the switch. For example, 802.1p information can
be preserved across a routed switch boundary and DiffServ code points can be observed or overwritten
across a Layer 2 switch boundary.
This section describes the following topics:
Configuring DiffServ
802.1p
priority
802.1Q
VLAN ID
8100
Destination
address
Source
address
IP packet
CRC
EW_024
354
Traffic Groupings
802.1p information on the 8800 family of switches and the Summit X450 only
802.1p information on the BlackDiamond 10K series and 12804 switches only
Observing 802.1p information. When ingress traffic that contains 802.1p prioritization information is
detected by the switch, that traffic is mapped to various queues on the egress port of the switch. The
BlackDiamond 10K and 12804 switch supports 8 hardware queues by default; you can modify the
characteristics of each queue. By default, the BlackDiamond 8800 family of switches and the Summit
X450 switch support 2 queues based on flows; you can define up to 6 additional queues. The
transmitting queue determines the characteristics used when transmitting packets.
NOTE
See for Chapter 10 information regarding VMANs using 802.1p information to direct packets to appropriate egress
QoS queues.
To control the mapping of 802.1p prioritization values to queues, 802.1p prioritization values can be
mapped to a QoS profile. The default mapping of each 802.1p priority value to QoS profile is shown in
Table 49.
QP1
QP1
QP2
QP1
QP3
QP1
QP4
QP1
QP5
QP1
QP6
QP1
QP7
QP1
QP8
QP8
Changing the default 802.1p mapping. By default, a QoS profile is mapped to a queue, and each QoS
profile has configurable parameters. In this way, an 802.1p priority value seen on ingress can be
mapped to a particular QoS profile.
To change the mapping of 802.1p priority value to QoS profile, use the following command:
configure dot1p type <dot1p_priority> {qosprofile} <qosprofile>
Replacing 802.1p priority information. By default, 802.1p priority information is not replaced or
manipulated, and the information observed on ingress is preserved when transmitting the packet. This
behavior is not affected by the switching or routing configuration of the switch.
NOTE
In the BlackDiamond 8800 family of switches and the Summit X450 switch, 802.1p replacement uses existing flow
classifiers. If this feature is enabled and the flow classifier has been defined (traffic groupings), the related flow
classifier causes the replacement.
355
Quality of Service
However, the switch is capable of inserting and/or overwriting 802.1p priority information when it
transmits an 802.1Q tagged frame. If 802.1p replacement is enabled, the 802.1p priority information that
is transmitted is determined by the queue that is used when transmitting the packet. The 802.1p
replacement configuration is based on the ingress port. To replace 802.1p priority information, use the
following command:
enable dot1p replacement ports [<port_list> | all]
NOTE
The port in this command is the ingress port.
NOTE
On the BlackDiamond 8800 family of switches and the Summit X450 switch, only QP1 and QP8 exist by default;
you must create QP2 to QP7. If you have not created these QPs, the replacement feature will not take effect.
The 802.1p priority information is replaced according to the queue that is used when transmitting from
the switch. The mapping is described in Table 50. This mapping cannot be changed.
Q0
Q1
Q1
Q2
Q2
Q3
Q3
Q4
Q4
Q5
Q5
Q6
Q6
Q7
Q7
Q8
NOTE
This command affects only that traffic based on explicit packet class of service information and physical/logical
configuration.
802.1p information on the BlackDiamond 8800 family of switches and the Summit X450 switch only.
Beginning in ExtremeWare XOS 11.4, you can disable the 802.1p examination. Although this feature is
enabled by default, you can disable it to conserve ACL resources. (See Chapter 14 for information on
available ACL resources.) To display the amount of available ACL resources, use the following
command:
show access-list usage port
356
Traffic Groupings
NOTE
Extreme Networks recommends disabling this feature when you are not using this form of traffic grouping to free
resources.
Also, beginning with ExtremeWare XOS version 11.4 on the 1 Gigabit Ethernet ports, 802.1p replacement
always happens when you configure the DiffServ traffic grouping.
802.1p information on the BlackDiamond 10K series and 12804 switches only. If a port is in more than one
virtual router, you cannot use the QoS 802.1p features. The default VLAN DiffServ examination
mappings apply on ports in more than one VR. If you attempt to configure examining or replacing
802.1p information on a port that is in more than one virtual router, the system returns the following
message:
Warning: Port belongs to more than one VR. Port properties related to diff serv and
code replacement will not take effect.
Configuring DiffServ
Contained in the header of every IP packet is a field for IP Type of Service (TOS), now also called the
Differentiated Services (DiffServ) field. The DiffServ field is used by the switch to determine the type of
service provided to the packet.
357
Quality of Service
Figure 23 shows the encapsulation of an IP packet header.
bits
Version
IHL
31
Type-of-service
Identification
Time-to-live
Total length
Flags
Protocol
Fragment offset
Header checksum
Source address
Destination address
Options (+ padding)
Data (variable)
EW_023
Observing DiffServ code points as a traffic grouping mechanism for defining QoS policies and
overwriting the Diffserv code point fields are supported.
This section describes the following sections:
DiffServ information on the BlackDiamond 8800 family of switches and the Summit X450 switch
only
Observing DiffServ information. When a packet arrives at the switch on an ingress port and this feature is
enabled, the switch examines the first six of eight TOS bits, called the DiffServ code point. The switch can
then assign the QoS profile used to subsequently transmit the packet based on the code point. The QoS
profile controls which queue is used when transmitting the packet out of the switch and determines the
forwarding characteristics of a particular code point. Examining DiffServ information can be enabled or
disabled; by default it is disabled. To enable DiffServ examination, use the following command:
enable diffserv examination port [<port_list> | all]
358
Traffic Groupings
Because the DiffServ code point uses six bits, it has 64 possible values (26 = 64). By default, the values
are grouped and assigned to the default QoS profiles listed in Table 51.
0-7
QP1
QP1
8-15
QP2
QP1
16-23
QP3
QP1
24-31
QP4
QP1
32-39
QP5
QP1
40-47
Q61
QP1
48-55
QP7
QP1
56-63
QP8
QP8
Changing the default DiffServ code point mapping. You can change the QoS profile assignment for each of
the 64 code points using the following command:
configure diffserv examination code-point <code-point> {qosprofile} <qosprofile>
After they have been assigned, the rest of the switches in the network prioritize the packet using the
characteristics specified by the QoS profile.
Replacing DiffServ code points. The switch can be configured to change the DiffServ code point in the
packet before the packet is transmitted by the switch. This is done with no impact on switch
performance.
The DiffServ code point value used in overwriting the original value in a packet is determined by the
QoS profile. You enter the QoS profile you want to use to determine the replacement DiffServ code
point value.
To replace DiffServ code points, you must enable DiffServ replacement using the following commands
enable diffserv replacement ports [<port_list> | all]
NOTE
The port in this command is the ingress port. This command affects only that traffic based on explicit packet class
of service information and physical/logical configuration.
The default QoS profile to DiffServ code point mapping is shown in Table 52, and the default 802.1p
priority value to code point mapping is described in Table 52.
Code point
QP1
QP1
QP2
QP1
QP3
QP1
16
359
Quality of Service
Table 52: Default 802.1p priority value-to-DiffServ code point mapping (Continued)
BlackDiamond 10K and
12804 switch QoS profile
Code point
QP4
QP1
24
QP5
QP1
32
QP61
QP1
40
QP7
QP1
48
QP8
QP8
56
You change the DiffServ code point mapping, using either the QoS profile or the 802.1p value, to any
code point value using the following command:
configure diffserv replacement [{qosprofile} <qosprofile> | priority <value>] codepoint <code_point>
NOTE
Extreme Networks recommends that you use the qosprofile <qosprofile> value to configure this parameter.
By doing so, the queue used to transmit a packet determines the DiffServ value replaced in the IP
packet.
To view currently configured DiffServ information, use the following command:
show diffserv [examination | replacement]
NOTE
You can also use ACLs to replace the DSCP value; to do so you must first configure the values using these CLI
commands.
DiffServ information on the BlackDiamond 8800 family of switches and Summit X450 switch. Beginning with
ExtremeWare XOS version 11.4 on the 1 Gigabit Ethernet ports, 802.1p replacement always happens
when you configure the DiffServ traffic grouping.
DiffServ information on the BlackDiamond 10K and 12804 switch only. The default VLAN DiffServ
examination mappings apply on ports in more than one VR. If you attempt to configure examining or
replacing DiffServ information on a port that is in more than one virtual router, the system returns the
following message:
Warning: Port belongs to more than one VR. Port properties related to diff serv and
code replacement will not take effect.
DiffServ example. In this example, we use DiffServ to signal a class of service throughput and assign any
traffic coming from network 10.1.2.x with a specific DiffServ code point. This allows all other network
switches to send and observe the Diffserv code point instead of repeating the same QoS configuration
on every network switch.
360
Traffic Groupings
To configure the switch:
1 Using ACLs, assign a traffic grouping for traffic from network 10.1.2.x to QP3:
configure access-list qp3sub any
2 Configure the switch so that other switches can signal calls of service that this switch should observe
by entering the following:
enable diffserv examination ports all
NOTE
The switch only observes the DiffServ code points if the traffic does not match the configured access list. Otherwise,
the ACL QoS setting overrides the QoS DiffServ configuration.
Source port
VLAN
Source port
A source port traffic grouping implies that any traffic sourced from this physical port uses the indicated
QoS profile when the traffic is transmitted out to any other port. To configure a source port traffic
grouping, use the following command:
configure ports <port_list> {qosprofile} <qosprofile>
In the following modular switch example, all traffic sourced from slot 5 port 7 uses the QoS profile
named QP8 when being transmitted.
configure ports 5:7 qosprofile qp8
NOTE
On the BlackDiamond 10K and 12804 switch, this command applies only to untagged packets. On the
BlackDiamond 8800 family of switches and the Summit X450 switch, this command applies to all packets.
361
Quality of Service
VLAN
A VLAN traffic grouping indicates that all intra-VLAN switched traffic and all routed traffic sourced
from the named VLAN uses the indicated QoS profile. To configure a VLAN traffic grouping, use the
following command:
configure vlan <vlan_name> {qosprofile} <qosprofile>
For example, all devices on VLAN servnet require use of the QoS profile QP1. The command to
configure this example is as follows:
configure vlan servnet qosprofile qp1
NOTE
On the BlackDiamond 10K and 12804 switch, this command applies only to untagged packets. On the
BlackDiamond 8800 family of switches and the Summit X450 switch, this command applies to all packets.
BlackDiamond 8800 family of switches and Summit X450 switch display. You display which QoS profile, if
any, is configured on the BlackDiamond 8800 family of switches and the Summit X450 switch using the
show ports <port_list> information detail command. The following is a sample output of this
command for an BlackDiamond 8810 switch:
Port:
3:1
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Unsupported
Admin state:
Enabled with auto-speed sensing auto-duplex
ELSM Link State:
Up
Link State:
Active, 1 Gbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1 (MAC-Based), MAC-limit = No-limit
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Load sharing is not enabled.
Enabled
Trunking:
EDP:
362
Traffic Groupings
ELSM:
Enabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo: Enabled, MTU= 9216
Egress Port Rate:
128 Kbps, Max Burst Size: 200 Kb
Broadcast Rate:
No-limit
Multicast Rate:
No-limit
Unknown Dest Mac Rate: No-limit
QoS Profile:
QP3 configured by user
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Ingress 802.1p Examination:
Enabled
Ingress 802.1p Inner Exam:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Enabled
NetLogin authentication mode:
MAC based
NetLogin port mode:
MAC based VLANs
Smart redundancy:
Enabled
Software redundant port:
Disabled
autopolarity:
Enabled
NOTE
To ensure that you display the QoS information, you must use the detail variable.
BlackDiamond 10K switch display. You display information on the egress QoS profiles and the ingress
QoS profiles (shown as Ingress Rate Shaping), as well as the minimum and maximum available
bandwidth and priority on the BlackDiamond 10K switch using the show ports <port_list>
information detail command. The display is slightly different for a 1 Gbps port and for a 10 Gbps
port.
The following is sample output of this command for a BlackDiamond 10K switch 10 Gbps port:
Port:
8:1
Virtual-router: VR-Default
Type:
XENPAK
Random Early drop:
Unsupported
Admin state:
Enabled with 10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
STP cfg:
Protocol:
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
363
Quality of Service
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% PR
=
Queue: Qp1 MinBw=0% MaxBw=100% Pri=1
Qp2 MinBw=0% MaxBw=100% Pri=2
Qp3 MinBw=0% MaxBw=100% Pri=3
Qp4 MinBw=0% MaxBw=100% Pri=4
Qp5 MinBw=0% MaxBw=100% Pri=5
Qp6 MinBw=0% MaxBw=100% Pri=6
Qp7 MinBw=0% MaxBw=100% Pri=7
Qp8 MinBw=0% MaxBw=100% Pri=8
Ingress Rate Shaping : support IQP1-8
IQP1 MinBw= 0% MaxBw=100% Pri=1
IQP2 MinBw= 0% MaxBw=100% Pri=2
IQP3 MinBw= 0% MaxBw=100% Pri=3
IQP4 MinBw= 0% MaxBw=100% Pri=4
IQP5 MinBw= 0% MaxBw=100% Pri=5
IQP6 MinBw= 0% MaxBw=100% Pri=6
IQP7 MinBw= 0% MaxBw=100% Pri=7
IQP8 MinBw= 0% MaxBw=100% Pri=8
Ingress IPTOS: Disabled
Egress IPTOS:
Replacement disabled
Egress 802.1p: Replacement disabled
NetLogIn:
Disabled
Smart Redundancy:
Enabled
Software redundant port: Disabled
autopolarity:
Enabled
100K
Pri = 8
The following is sample output of this command for a BlackDiamond 10K switch 1 Gbps port:
Port:
2:1
Virtual-router: VR-Default
Type:
XENPAK
Random Early drop:
Unsupported
Admin state:
Enabled with 10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
STP cfg:
Protocol:
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% PR
=
Queue: Qp1 MinBw=0% MaxBw=100% Pri=1
Qp2 MinBw=0% MaxBw=100% Pri=2
Qp3 MinBw=0% MaxBw=100% Pri=3
364
100K
Pri = 8
Traffic Groupings
Qp4 MinBw=0% MaxBw=100% Pri=4
Qp5 MinBw=0% MaxBw=100% Pri=5
Qp6 MinBw=0% MaxBw=100% Pri=6
Qp7 MinBw=0% MaxBw=100% Pri=7
Qp8 MinBw=0% MaxBw=100% Pri=8
Ingress Rate Shaping : support IQP1-8
IQP1 MinBw= 0% MaxBw=100% Pri=1
IQP2 MinBw= 0% MaxBw=100% Pri=2
Ingress IPTOS: Disabled
Egress IPTOS:
Replacement disabled
Egress 802.1p: Replacement disabled
NetLogIn:
Disabled
Smart Redundancy:
Enabled
Software redundant port: Disabled
autopolarity:
Enabled
BlackDiamond 12804 switch display. You display information on the QoS profiles and rate limiting, as
well as the minimum and maximum available bandwidth and priority on the BlackDiamond 12804
switch using the show ports <port_list> information detail command.
Port:
2:1
Virtual-router: VR-Default
Type:
UTP
Random Early drop:
Unsupported
Admin state:
Enabled with auto-speed sensing auto-duplex
Link State:
Active, 100Mbps, full-duplex
Link Counter: Up
1 time(s)
VLAN cfg:
Name: peggy, Internal Tag = 4094, MAC-limit = No-limit
STP cfg:
Protocol:
Name: peggy
Protocol: ANY
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% PR
=
Queue:
QP1 MinBw =
0% MaxBw =
QP2 MinBw =
0% MaxBw =
QP3 MinBw =
0% MaxBw =
QP4 MinBw =
0% MaxBw =
QP5 MinBw =
0% MaxBw =
QP6 MinBw =
0% MaxBw =
QP7 MinBw =
0% MaxBw =
QP8 MinBw =
0% MaxBw =
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
100K
Pri = 8
100%
100%
100%
100%
100%
100%
100%
100%
Pri
Pri
Pri
Pri
Pri
Pri
Pri
Pri
=
=
=
=
=
=
=
=
1
2
3
4
5
6
7
8
365
Quality of Service
Egress 802.1p Replacement:
NetLogIn:
Smart redundancy:
Software redundant port:
Primary:
Redundant:
Redundant link configuration:
autopolarity:
Disabled
Disabled
Enabled
Enabled
1:1
1:2
Off
Enabled
BlackDiamond 12804 R-Series switch display. You display information on the QoS profiles, hierarchical
QoS, and rate limiting, as well as the minimum and maximum available bandwidth and priority on the
BlackDiamond 12804 switch using the show ports <port_list> information detail command.
Port:
2:1
Virtual-router: VR-Default
Type:
NONE
Random Early drop:
Unsupported
Admin state:
Enabled with 10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual ro
uter: VR-Default
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
High Priority COS: 7
Packet Length Adjustment: 0 bytes
QoS Profile:
None configured
Aggregate Queue:
QP0 MinBw =
0% MaxBw =
Queue:
QP1 MinBw =
0% MaxBw =
QP2 MinBw =
0% MaxBw =
QP3 MinBw =
0% MaxBw =
QP4 MinBw =
0% MaxBw =
QP5 MinBw =
0% MaxBw =
QP6 MinBw =
0% MaxBw =
QP7 MinBw =
0% MaxBw =
QP8 MinBw =
0% MaxBw =
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Disabled
366
100%
Pri = 8
100%
100%
100%
100%
100%
100%
100%
100%
Pri
Pri
Pri
Pri
Pri
Pri
Pri
Pri
=
=
=
=
=
=
=
=
1
2
3
4
5
6
7
8
NOTE
To ensure that you display the QoS information, you must use the detail variable.
After you have created QoS policies that manage the traffic through the switch, you can use the QoS
monitor on the BlackDiamond 10K and 12804 switch to determine whether the application performance
meets your expectations.
QoS features performance monitoring with a either a real-time or a snapshot display of the monitored
ports. To view switch performance per port, use the following command:
show ports <port_list> qosmonitor {ingress | egress} {bytes | packets} {no-refresh}
NOTE
You must specify ingress to view the ingress rate-shaping performance. By default, this command displays the egress
performance.
Displaying QoS Profile Information on the BlackDiamond 8800 Family of Switches and
Summit X450 Switch Only
To display QoS information on the BlackDiamond 8800 family of switches and the Summit X450 switch,
use the following command:
show qosprofile
367
Quality of Service
Displayed information includes:
Weight
Displaying QoS Profile Information on the BlackDiamond 10K and 12804 Switch Only
To display QoS information on the BlackDiamond 10K switch, use the following command:
show qosprofile [ingress | egress | ports [ all | <port_list>]
Minimum bandwidth
Maximum bandwidth
Priority
If you are using DiffServ for QoS parameters, Extreme Networks recommends that you also
configure 802.1p or port-based QoS parameters to ensure that high-priority traffic is not dropped
before it reaches the Master Switch Module (MSM) on modular switches.
The command to replace the 802.1p or DiffServ value affects only those traffic groupings based on
explicit packet class of service and physical/logical groupings.
The BlackDiamond 8800 family and Summit X450 switches provide a metering capability that can be
used to associate an ACL rule to a specified bit-rate and out-of-profile action. The rate granularity is
64 Kbps (up to 1 Gbps for GE ports and up to 10 Gbps for 10 G ports) and the out-of-profile actions are
drop, set the drop precedence, or mark the DSCP with a configured value. Additionally, each meter has
an associated out-of-profile byte counter that counts the number of packets that were above the
committed-rate (and subject to the out-of-profile-action).
368
Metering Using ACLsBlackDiamond 8800 Family of Switches, Summit X450 Switch, and BlackDiamond 12804 R-Series
With strict priority rate limiting on the BlackDiamond 12804 R-Series switch, you configure a peak rate
for a specified ingress queue.
To configure ACL metering:
1 Create the meter
2 Configure the meter
3 Associate the meter with an ACL rule entry (see Chapter 14 for complete information on ACLs)
Configuring ACL Meters on the BlackDiamond 8800 Family of Switches and the
Summit X450 Switch
After the ACL meter is created, you configure it. Configuring the ACL meter sets allowable traffic limits
and the actions to take with out of limit traffic. To configure an ACL meter, use the following command:
configure meter <metername> {max-burst-size <burst-size> [Gb | Kb | Mb]} {committedrate <cir> [Gbps | Mbps | Kbps]} {out-actions [drop | set-drop-precedence {dscp [none
| <dscp-value>]}}
Once you create the meter, use the following command to configure the meter on the BlackDiamond
12804 R-Series switch:
configure meter <metername> [peak-rate <pr> [Gbps | Mbps | Kbps]]
369
Quality of Service
NOTE
See Chapter 14 for complete information on ACLs.
Displaying Meters
To display the meters that you created you can use either the show-access list or, beginning in
ExtremeWare XOS 11.4, the show meter command.
The following is sample output from the show meter command:
----------------------------------------------------------------------Name
Committed Rate(Kbps) Peak Rate(Kbps)
Burst Size(KB)
----------------------------------------------------------------------black
50
--
--
To view the configured egress port rate-limiting behavior, use the following command:
show ports {mgmt | <port_list>} information {detail}
You must use the detail parameter to display the Egress Port Rate configuration and, if configured, the
Max Burst size. Refer to Displaying Port Configuration Information for more information on the show
ports information command.
You can also display this information using the following command:
show configuration vlan
The following is sample output from the show configuration vlan command for configured egress
rate limiting:
# Module vlan configuration.
#
create virtual-router "VR-Default"
370
Applying Egress Bandwidth to a PortBlackDiamond 10K Series and 12804 Switch Only
configure virtual-router VR-Default add ports 3:1-48
create vlan "Default"
configure vlan Default tag 1
config port 3:1 rate-limit egress 128 Kbps max-burst-size 200 Kb
config port 3:2 rate-limit egress 128 Kbps
config port 3:10 rate-limit egress 73 Kbps max-burst-size 128 Kb
configure vlan Default add ports 3:1-48 untagged
NOTE
Refer to Chapter 11 for more information on limiting broadcast, multicast, or unknown MAC traffic ingressing the
port.
To configure the egress bandwidth per port, use the following CLI command:
configure ports <port_list> rate-limit egress aggregate [{{committed_rate
<committed_bps> [k | m ]} {peak_rate <peak_bps> [k | m]}} | {{minbw <minbw_number>}
{maxbw <maxbw_number>}}]
To remove the limit on egress bandwidth per port, re-issue this command using the default values.
To display the current configuration for the port-based egress rate limiting, use the following command:
show ports <port_list> information detail
NOTE
You must use the detail variable to display this information.
The following is sample output from the show port information detail command (the setting for
aggregate egress bandwidth is displayed in the Aggregate Queue line) on the BlackDiamond 12804 RSeries switch:
Port:
1:1
Virtual-router: VR-Default
Type:
NONE
Random Early drop:
Unsupported
Admin state:
Enabled with
10G full-duplex
Link State:
Ready
371
Quality of Service
Link Counter: Up
0 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual
router: VR-Default
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
High Priority COS: 7
Packet Length Adjustment: 0 bytes
QoS Profile:
None configured
Aggregate Queue:
QP0
MinBw =
0% MaxBw =
100% Pri = 8
Queue:
QP1
MinBw =
0% MaxBw =
100% Pri = 1
QP2
MinBw =
0% MaxBw =
100% Pri = 2
QP3
MinBw =
0% MaxBw =
100% Pri = 3
QP4
MinBw =
0% MaxBw =
100% Pri = 4
QP5
MinBw =
0% MaxBw =
100% Pri = 5
QP6
MinBw =
0% MaxBw =
100% Pri = 6
QP7
MinBw =
0% MaxBw =
100% Pri = 7
QP8
MinBw =
0% MaxBw =
100% Pri = 8
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Disabled
NetLogin port mode:
Port based VLANs
Smart redundancy:
Enabled
Software redundant port:
Disabled
Preferred medium:
Fiber
372
Table 53: Ingress queue mapping for I/O modules on the BlackDiamond 10K switch
I/O module
Ingress queues
Priority value
1 Gbps module
IQP1
1 to 4
IQP2
5 to 8
IQP1
IQP2
IQP3
IQP4
IQP5
IQP61
IQP7
IQP8
10 Gbps module
Using bi-directional rate shaping, excess traffic is discarded at the I/O module and does not traverse to
the backplane. You view statistics on the discarded traffic using the show ports qosmonitor or show
ports information command.
The 802.1p value is mapped to the ingress queue. For untagged ports, use port- or VLAN-based QoS to
map traffic to the ingress queue.
Bandwidth Settings
You apply ingress QoS profile (IQP or rate shaping) values on the BlackDiamond 10K switch as either a
percentage of bandwidth or as an absolute value in Kbps or Mbps. IQP bandwidth settings are in turn
applied to queues on physical ports. The impact of the bandwidth setting is determined by the port
speed (1 or 10 Gbps).
373
Quality of Service
NOTE
You may see slightly different bandwidths because the switch supports granularity down to 62.5 Kbps.
Table 54: Maximum committed rates per port for I/O module on the BlackDiamond 10K switch
I/O module
MSM configuration
1 Gbps module
Single MSM
200 Mbps
Dual MSM
400 Mbps
Single MSM
2 Gbps
Dual MSM
4 Gbps
10 Gbps module
Note that these maximum committed rates vary with the number of active ports on each I/O module.
The rates shown in Table 54 are what you can expect when you all running all ports at traffic level. If
you are using fewer ports, you will have higher committed rates available for each port. And, the
maximum committed rate is reached when you are running traffic on only one port.
NOTE
Cumulative percentages of minimum bandwidth of the queues on a given port should not exceed 100%
If you choose a setting not listed in the tables, the setting is rounded up to the next value. If the actual
bandwidth used is below the minimum bandwidth, the additional bandwidth is not available for other
queues on that physical port.
374
If you choose to use committed rate and peak rate values, be aware of the interactions between the
values and the command line interface (CLI) management system. You can enter any integer from 0 in
the CLI; however, functionally the switch operates only in multiples of 62.5 Kbps. Also note that the CLI
system does not accept decimals.
Rate shaping is disabled by default on all ports; the system does use existing 802.1p, port, and VLAN
values to assign packets to the ingress queue. The rate shaping function is used to assign specific
priorities by absolute rates or percentages of the bandwidth.
To enable this ingress rate shaping feature, use the configuration command. To disable the ingress rate
shaping, use the following command:
unconfigure qosprofile ingress ports all
To display the parameters for ingress rate shaping (the values for the IQPs), use the following
commands:
show qosprofile [ingress | egress | ports [ all | <port_list>]
show ports {mgmt | <port_list>} information {detail}
Additionally, you can monitor the performance on the BlackDiamond 10K switch by using the following
command:
show ports <port_list> qosmonitor {ingress | egress} {bytes | packets} {no-refresh}
NOTE
You must specify ingress to view ingress rate shaping performance.
Hierarchical Quality of Service (HQoS), or rate limiting, is an important enabling feature for the
deployment of residential integrated networks and advanced business services; it is available on the
BlackDiamond 12804 R-Series switch. HQoS allows the Internet Service Provider (ISP) to assign a
committed bandwidth to each customer. The customer then assigns priorities to their applications, and
HQoS, or rate limiting, ensures that the highest priority traffic is always serviced first. If the highest
priority applications are idle, the lower priority applications are allowed to send their data. HQoS also
allows a straightforward way to determine network load, easing the network planning burden.
375
Quality of Service
This is accomplished by limiting traffic flows in both directionsingress and egresswithin the
network. Such an efficient, high-performance network supports the diverse requirements of several
service types, including the requirements of real-time voice and video, along with priority and besteffort data traffic. All this is accomplished with no impact on network performance.
NOTE
You can configure VMAN-based rate limiting using VMAN ACLs. (See Chapter 14 for information on VMAN ACLs.).
Guidelines for Using Ingress-Only and Ingress and Egress HQoS on page 382
HQoS Implementation
NOTE
You must be running the BlackDiamond 12804 R-Series modules to use HQoS. You must use the MSM-5R plus
either the GM-20XTR module or the XM-2XR module (or both).
Beginning with ExtremeWare XOS version 11.4, Extreme Networks introduces hardware-based HQoS, or
rate limiting, on the BlackDiamond 12804 R-Series switch. You configure HQoS in different ways for
different streams of traffic: ingress-only and ingress and egress.
To configure strict priority ingress-only HQoS and ingress and egress HQoS, you create and configure
traffic queues, create and apply ACL policy files, create and configure meters, and associate the traffic
queues with the ACL policy files. (You use the meters to configure a peak rate for a specified queue.)
This section describes the following topics:
Controlling Flooding, Multicast, and Broadcast Traffic on VMAN Egress Ports with Rate Limiting
Applied on page 381
376
Egress HQoS. (You map the egress queue to an ingress queue and configure the ingress queue as
unlimited rate limiting.)
NOTE
All egress traffic queues must be mapped to an ingress traffic queue, and those ingress queues must be configured
to allow egress shaping on the specified ingress queues.
You can create multiple traffic queues, using the CLI commands, that create different limits for HQoS,
or rate limited, traffic. The traffic is first matched, using ACLs you specify in an ACL policy file, and
then assigned to a particular traffic queue. (See Chapter 14 for more information on using specific ACLs
to achieve HQoS or rate limiting.) The ACL policy file is then applied to one or more ingress ports.
NOTE
All traffic that enters these ports that does not match any ACLs for that port is unlimited.
Ingress HQoS limits the rate of traffic entering the switch on a specified interface or interfaces. The
system classifies the ingressing traffic using the ACLs, and the configured ingress traffic queue defines
the rate limiting parameters.
With ingress and egress HQoS, or rate limiting, you associate the egress traffic queue with an ingress
traffic queue.
NOTE
The egress traffic queue is applied to ports only.
The ingress traffic queue identifies the traffic that is to be rate limited. By associating an ingress traffic
queue with an egress traffic queue, you send the classified traffic (classified at the ingress queue) to a
rate limited HQoS egress queue that limits the traffic as it exits the switch. Egress traffic queues are
associated with one or more ingress traffic queues, and traffic is limited by the egress traffic queue only
if that traffic is not dropped by the ingress traffic queue.
NOTE
Multiple ingress traffic queues can be attached to a single egress traffic queue. Thus, traffic matching different
ingress traffic queues is combined and sent to the same egress traffic queue for HQoS.
The system uses strict priority HQoS, or rate limiting. In this scheme, the system has three queues: high,
medium, and low. You use ACL policies to match traffic and map each traffic category to a Class of
Service (CoS) value, which in turn determines the queue (high, medium, or low) that the traffic moves
to. If your ACL policy file does not assign a CoS value, the packet is assigned the default CoS value of
0. By default, packets with a CoS value of 7 go to the high queue, those with a value of 6 go to the
medium queue, and those packets with a value of 5 to 0 go to the low queue. (See Mapping CoS Value
to High Queue on page 380 for information on changing the mapping of CoS values to the respective
queues.)
You must associate one or more ports to the egress traffic queue with ingress and egress HQoS, or rate
limiting.
377
Quality of Service
To configure ingress-only or ingress and egress HQoS, or rate limiting, you create a traffic queueeither
an ingress-only queue, an ingress queue that allows egress shaping, and/or an egress queue you
associate to ingress queues. For each queue, you create and configure one or more meters, which are
used to enforce rate limits on traffic streams, and configure the meter to be associated with the traffic
queue. ACL rules assign traffic queues to the traffic, using ACL policy files.
NOTE
You must create and configure the traffic queues before applying the ACLs, and you must associate the traffic queue
with one or more ACLs to achieve rate limiting.
The system accomplishes HQoS, or rate limiting, using the following elements:
Ingress-only and ingress and egress HQoS are accomplished by strict priority, which has three levels of
priority: high, medium, and low. Strict priority HQoS, or rate limiting, supports one rate as an
aggregate rate for the traffic queue and can be associated with one aggregate peak limit.
NOTE
You configure egress-only HQoS by associating the egress queue with an ingress queue that allows unlimited traffic;
you configure the egress rate limits.
Changing Rates
To change the rate for a traffic queue, you must disassociate the current ACL policy and delete the
specified traffic queue. Then, you begin again creating and configuring the HQoS by:
Creating and configuring a new meter with the rate you want.
See Guidelines for Using Ingress-Only and Ingress and Egress HQoS for more information on deleting or modifying
HQoS parameters.
See Configuring HQoS Ingress and Egress Queues on page 382 for information on configuring HQoS
and Displaying HQoS on page 385 for information on displaying HQoS.
378
High queueContains packets with CoS value assigned to high queue. By default, the CoS value
assigned to the high queue is 7; you can configure this value from 7 to 2. The high queue contains
packets with a single CoS value.
NOTE
All packets with a CoS value higher than that configured for the high queue automatically go to the low queue. (If
you configure 2 as the CoS value for the high queue, packets with a CoS value of 3 to 7 all go to the low queue.)
Medium queueContains packets with the next-highest CoS value (numerically lower) to that value
configured as the high queue value; the medium queue contains packets with a single CoS value.
You do not need to configure the CoS value for packets in the medium queue; rather the system
automatically places packets with the next-highest value to the high queue CoS value in this queue.
By default, this queue contains packets with a CoS value of 6 (because default high queue CoS value
is 7).
Low queueContains packets with all other CoS values plus packets with no CoS value. By default,
this queue contains all packets with a CoS value of 5, 4, 3, 2, 1, or 0, as well as packets with no CoS
value. The low queue contains packets with any of six different CoS values and those with no CoS
value. You do not configure the CoS value for this queue; the system automatically puts all packets
not assigned to the high or medium queue to the low queue. Also note that the system automatically
puts all packets with a CoS value higher than that assigned to the high queue into the low queue.
For example, if you configure 5 as the CoS value for the high queue, the queues contain packets with
the following CoS values:
High contains 5
Medium contains 4
As another example, if you configure 2 as the CoS value for the high queue, the queues contain packets
with the following CoS values:
High contains 2
Medium contains 1
By default, the system puts packets with a CoS value of 7 into the high queue, packets with a CoS value
of 6 into the medium queue, and all other packets into the low queue.
To configure the CoS value you want as the value for the high queue for the specified ports, use the
following CLI command:
configure ports <port_list> rate-limit map cos high <cos_value>
379
Quality of Service
NOTE
You must use the detail variable to display this information.
Controlling Flooding, Multicast, and Broadcast Traffic on VMAN Egress Ports with
Rate Limiting Applied
You apply egress rate limiting to VMAN ports using VMAN ACLs. (See Chapter 14 for information on
applying egress rate limiting to a VMAN using VMAN ACLs).
After you apply egress rate limiting to a VMAN, you can configure how to control flooding, multicast,
and broadcast traffic on the specified VMAN. You specify one port in that VMAN as the designated
port, and the system applies the egress rate limiting profile of the designated port to send flood,
multicast, and broadcast traffic on all ports on that VMAN.
To assign the port to use the rate limiting profile, use the following command:
configure vman <vman_name> ratelimit flood-traffic designated-port <port>
NOTE
This VMAN feature works only with those VMANs to which you have applied egress rate limiting using VMAN ACLs.
To remove the control on a VMAN with egress rate limiting enabled, use the following command:
unconfigure vman <vman_name> ratelimit flood-traffic designated-port
To display the designated port, use the show vman detail command.
If you do not issue this command, this traffic is not limited at egress.
By default, all bytes are counted for the ingressing traffic rate. After you issue this command, the
default number of bytes removed is 0; you can add or subtract from 1 to 4 bytes from each ingressing
packet on the specified ports for calculating the ingressing traffic rate.
To display the number of bytes added to or subtracted from the packet to calculate the ingressing traffic
rate, traffic utilization, and traffic statistics, use the following command:
show ports <port_list> information detail
380
NOTE
You must use the detail variable to display this information.
To unconfigure this setting, re-issue the command and enter the value 0.
If you use this command to decrease by 4, the show traffic queue statistics display shows only
bytes; the packets are displayed as 0.
All interfaces in a given ingress traffic queue must be on the same one-half of the module (GM--XTR
or XM-2XR module), and you cannot configure cross-module traffic queues. You will receive an error
message (about failure to connect the ACL policy file) if you attempt to apply ingress traffic queues
on interfaces located on more than one-half of each module. All interfaces in a given ingress traffic
queue must be only on the specified ports on the following modules:
GM-XTR moduleAll interfaces (in all VLANs and VMANs) on a given ingress queue must be
either on ports 1 to 10 or on ports 11 to 20.
XM-2XR moduleAll interfaces (in all VLANs and VMANs) on a given ingress queue must be
either on port 1 or on port 2.
You can apply the same traffic queue to multiple ports (on the same module), keeping in mind the
ingress queues guidelines.
To change the meter attributes, you must delete the meter and create and configure the new meter;
then you configure that new meter with the traffic queue. (See Changing Rates on page 379 for
complete information.)
After you apply the ACL policy file, you cannot change either the traffic queue attribute or the meter
attribute. To change either the traffic queue or meter attributes, you must unconfigure the ACL
policy file, re-configure the ACL policy file, and rebind the ACL policy file to the interfaces. (See
Changing Rates on page 379 for complete information.)
You can specify multiple traffic queues in one ACL policy file.
To delete a traffic queue, you must remove all ACL policy file associations; you cannot delete a
traffic queue that is currently associated with one or more ACL policy files.
The associated meters are not deleted when you delete any type of traffic queue. Those meters
remain and can be associated with other traffic queues. To display the configured meters, use the
show meters command.
381
Quality of Service
Ingress-only HQoS.
Egress HQoS on the specified ingress queue. (You must previously allow egress shaping on the
specified ingress queue.)
NOTE
With ingress and egress HQoS, you are applying separate bandwidth limits to both the specified ingressing traffic
and the specified egressing traffic.
If desired, configure the CoS value that directs the packet to the high queue.
Review the section Guidelines for Using Ingress-Only and Ingress and Egress HQoS on page 382.
Create a meter.
Configure the ACL policy files on the desired interfaces; you must have configured the traffic queues
before this step.
To configure the meter for ingress-only HQoS, use the following command:
configure meter <metername> [peak-rate <pr> [Gbps | Mbps | Kbps]]
To associate the meter to the traffic queue, use the following command:
configure traffic queue <queue_name> aggregate-meter <metername>
See Chapter 14 for information on creating and configuring ACL policy files. To display the meters
already configured on the switch, use the show meters command.
To delete a traffic queue, use the following command:
delete traffic queue <queue_name>
Before deleting an ingress traffic queue, you must remove all ACL policy file associations; you cannot
delete an ingress traffic queue that is currently associated with one or more ACL policy files.
When you delete an ingress traffic queue, the associated egress queue is also deleted.
382
If desired, configure the CoS value that directs the packet to the high queue.
Review the section Configuring HQoS Ingress and Egress Queues on page 382.
Create a meter for the ingress queue that allows egress shaping.
Create a traffic queue that specifies allowing egress shaping (this creates an ingress queue).
Associate the meters to the ingress traffic queue that allows egress shaping.
Associate the egress queue with ingress queue (the specified ingress queue must allow egress
shaping).
Configure the ACLs on the desired interfaces; you must have configured the traffic queues before
this step.
To create a meter for the ingress queue that allows egress shaping, use the following command:
create meter <metername>
To configure the meter for this ingress queue that allows egress shaping, use the following command:
configure meter <metername> [peak-rate <pr> [Gbps | Mbps | Kbps]]
To create an ingress traffic queue that allows egress shaping, use the following CLI command:
create traffic queue <queue_name> allow-egress-shaping [strict-priority]
To associate the meter to the traffic queue, use the following command:
configure traffic queue <queue_name> aggregate-meter <metername>
To configure the meter for egress HQoS, use the following command:
configure meter <metername> [peak-rate <pr> [Gbps | Mbps | Kbps]]
To associate the meter to the traffic queue, use the following command:
configure traffic queue <queue_name> aggregate-meter <metername>
383
Quality of Service
To associate the egress queue with an ingress queue that allows egress shaping (and specify interfaces
for the egress queue), use the following command:
configure traffic ingress queue <queue_name> add egress queue <equeue_name> ports [all
| <port_list>]
See Chapter 14 for information on creating and configuring ACL policy files. To display the meters
already configured on the switch, use the show meters command.
After you associate an egress queue with an ingress queue, in order to delete the association between
the ingress and egress queue, use the following command:
configure traffic ingress queue <queue_name> delete egress queue [all | <equeue_name>]
Before deleting an ingress traffic queue, you must remove all ACL policy file associations; you cannot
delete an ingress traffic queue that is currently associated with one or more ACL policy files.
Changing the traffic queue rate. If you need to change the rate on a traffic queue:
Create a new meter, and configure it with the rate you want.
Create the traffic queue again, and associate it with the new meter.
Displaying HQoS
This section describes how to display the following HQoS configurations:
384
To display detailed information on all traffic queues or on a specific queue, use the following command:
show traffic queue {detail | <queue_name>}
Egress
strict-priority
m3_300
Ingress
Yes
strict-priority
m1_100
Ingress
No
strict-priority
m2_200
Ingress
Yes
eqq1
Egress Ports: 1:2
strict-priority
m3_300
To display the statistics for your current ingress-only and ingress and egress HQoS configuration, use
the following command:
show traffic queue [port <port_list> | <queue_name>] statistics
385
Quality of Service
po_62_egr
E
E
E
E
High
Med
Low
*
3472754
904283
7549233
11926270
331359794
78810756
452274980
8622445530
0
0
3790
3790
0
0
135288
135288
(*)-PR aggregate CoS Level for entire traffic queue, (I)-Ingress, (E)-Egress
If you issue the command configure ports rate-limit packet byte-adjustment, the system
calculates uses that byte size to calculate the statistics. If you use this command to decrease by 4, the
output of the show traffic queue statistics command displays only bytes; the packets are
displayed as 0.
To display utilization information for your current ingress-only and ingress and egress HQoS
configuration, use the following command:
show traffic queue [port <port_list> | <queue_name>] utilization
Priority Levels
H
M
L
------22
15
44
I=Ingress, E=Egress
You can also clear the counters for these statistics, by using the following command:
clear counters traffic queue [all | <queue_name>]
Finally, to display the meters you configured, use the following command:
show meter
---------
10000000
100000
200000
300000
400000
500000
600000
100000
---------
386
NOTE
You must use the detail variable to display this information.
The following is sample output from the show port information detail command (the setting for
this feature is displayed in the High Priority QOS line) on the BlackDiamond 12804 R-Series switch:
Port:
1:1
Virtual-router: VR-Default
Type:
NONE
Random Early drop:
Unsupported
Admin state:
Enabled with
10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual
router: VR-Default
STP cfg:
s0(disable), Tag=(none), Mode=802.1D, State=FORWARDING
Protocol:
Name: Default
Protocol: ANY
Match all protocols.
Trunking:
Load sharing is not enabled.
EDP:
Enabled
ELSM:
Disabled
Learning:
Enabled
Unicast Flooding:
Enabled
Multicast Flooding:
Enabled
Broadcast Flooding:
Enabled
Jumbo:
Disabled
High Priority COS: 7
Packet Length Adjustment: 0 bytes
QoS Profile:
None configured
Aggregate Queue:
QP0
MinBw =
0% MaxBw =
100% Pri = 8
Queue:
QP1
MinBw =
0% MaxBw =
100% Pri = 1
QP2
MinBw =
0% MaxBw =
100% Pri = 2
QP3
MinBw =
0% MaxBw =
100% Pri = 3
QP4
MinBw =
0% MaxBw =
100% Pri = 4
QP5
MinBw =
0% MaxBw =
100% Pri = 5
QP6
MinBw =
0% MaxBw =
100% Pri = 6
QP7
MinBw =
0% MaxBw =
100% Pri = 7
QP8
MinBw =
0% MaxBw =
100% Pri = 8
Ingress Rate Shaping :
Unsupported
Ingress IPTOS Examination:
Disabled
Egress IPTOS Replacement:
Disabled
Egress 802.1p Replacement:
Disabled
NetLogin:
Disabled
NetLogin port mode:
Port based VLANs
387
Quality of Service
Smart redundancy:
Software redundant port:
Preferred medium:
Enabled
Disabled
Fiber
NOTE
You must use the detail variable to display this information.
The following is sample output from the show port information detail command (the setting for
this feature is displayed in the Packet Length Adjustment line) on the BlackDiamond 12804 R-Series
switch:
Port:
1:1
Virtual-router: VR-Default
Type:
NONE
Random Early drop:
Unsupported
Admin state:
Enabled with
10G full-duplex
Link State:
Ready
Link Counter: Up
0 time(s)
VLAN cfg:
Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual
router: VR-Default
388
HQoS Example
The following example shows the configuration for six ingress-only strict priority traffic queues, each
associated with a separate meter. All traffic that ingresses the interfaces associated with these six traffic
queues that does not match any of the ACL rules, passes through unlimited.
create
create
create
create
create
create
traffic
traffic
traffic
traffic
traffic
traffic
create
create
create
create
create
create
meter
meter
meter
meter
meter
meter
queue
queue
queue
queue
queue
queue
m1_1
m2_10
m3_40
m4_2
m5_20
m6_80
389
Quality of Service
configure
configure
configure
configure
configure
configure
meter
meter
meter
meter
meter
meter
configure
configure
configure
configure
configure
configure
traffic
traffic
traffic
traffic
traffic
traffic
queue
queue
queue
queue
queue
queue
NOTE
These are the ACL policy files without VMAN ACLs.
entry mac-rule-1 {
if match all {
ethernet-destination-address 00:00:00:00:00:01 ;
}
then {
permit ;
traffic-queue "tq1_100" ;
count mac-counter-1 ;
qosprofile qp8 ;
}
}
entry mac-rule-2 {
if match all {
ethernet-destination-address 00:00:00:00:00:02 ;
}
then {
permit ;
traffic-queue "tq2_200" ;
count mac-counter-2 ;
qosprofile qp7 ;
}
}
entry mac-rule-3 {
if match all {
ethernet-destination-address 00:00:00:00:00:03 ;
}
then {
permit ;
traffic-queue "tq3_300" ;
count mac-counter-2 ;
qosprofile qp6 ;
}
}
390
391
Quality of Service
392
17 Security
This chapter describes the following topics:
Security Overview
Security is a term that covers several different aspects of network use and operation. One general type
of security is control of the devices or users that can access the network. Ways of doing this include
authenticating the user at the point of logging in. You can also control access by defining limits on
certain types of traffic. Another general type of security operates to protect the operation of the switch
itself. Security measures in this category include routing policies that can limit the visibility of parts of
the network or denial of service protection that prevents the CPU from being overloaded. Finally,
management functions for the switch can be protected from unauthorized use. This type of protection
uses various types of user authentication.
ExtremeWare XOS 11.3 introduces enhanced security features designed to protect, rapidly detect, and
correct anomalies in your network. Extreme Networks products incorporate a number of features
designed to enhance the security of your network while resolving issues with minimal network
disruption. No one feature can ensure security, but by using a number of features in concert, you can
substantially improve the security of your network.
The following list provides a brief overview of some of the available security features:
Access Control ListsAccess Control Lists (ACLs) are policy files used by the ACL application to
perform packet filtering and forwarding decisions on incoming traffic and packets. Each packet
arriving on an ingress port is compared to the ACL applied to that port and is either permitted or
denied.
For more information about using ACLs to control and limit network access, see Chapter 14, Access
Lists (ACLs).
CLEAR-FlowCLEAR-Flow is a security rules engine available only on the BlackDiamond 10K and
the BlackDiamond 12804 switches. CLEAR-Flow inspects Layer 2 and Layer 3 packets, isolates
suspicious traffic, and enforces policy-based mitigation actions. Policy-based mitigation actions
include the switch taking an immediate, predetermined action or sending a copy of the traffic offswitch for analysis. Working together, CLEAR-Flow and Sentriant provide a rapid response to
network threats. For off-switch analysis, CLEAR-Flow sends the suspicious traffic to Sentriant and
Sentriant stops the threats.
For more information about CLEAR-Flow, see Chapter 19, CLEAR-Flow. For more information
about Sentriant, contact your Extreme Networks representative.
393
Security
Network LoginNetwork login controls the admission of user packets and access rights thereby
preventing unauthorized access to the network. Network login is controlled on a per port basis.
When network login is enabled on a port in a VLAN, that port does not forward any packets until
authentication takes place. Network login is capable of three types of authentication: web-based,
MAC-based, and 802.1x.
For more information about network login, see Chapter 18, Network Login.
Policy FilesPolicy files are text files that contain a series of rule entries describing match conditions
and actions to take. Policy files are used by both routing protocol applications (routing policies) and
the ACL application (ACLs).
For more information about policy files, see Chapter 13, Policy Manager.
Routing PoliciesRouting policies are policy files used by routing protocol applications to control
the advertisement, reception, and use of routing information by the switch. By using policies, a set of
routes can be selectively permitted or denied based on their attributes for advertisements in the
routing domain. Routing policies can be used to hide entire networks or to trust only specific
sources for routes or ranges of routes.
For more information about using routing policies to control and limit network access, see
Chapter 15, Routing Policies.
394
In addition, if you keep the default settings for SNMP and Telnet, the switch returns the following
interactive script:
Since you have chosen less secure management methods, please remember to increase
the security of your network by taking the following actions:
* change your admin password
* change your SNMP public and private strings
* consider using SNMPv3 to secure network management traffic
For more detailed information about safe defaults mode, see Safe Defaults Setup Method on page 49.
NOTE
You can either limit dynamic MAC FDB entries or lock down the current MAC FDB entries, but not both.
Using ACLS, you can also prioritize or stop packet flows based on the source MAC address of the
ingress virtual LAN (VLAN) or the destination MAC address of the egress VLAN. For more information
about ACL policies, see Chapter 14, Access Lists (ACLs).
Another method of enhancing security, depending on your network configuration, is to disable Layer 2
flooding. For more information about enabling and disabling Layer 2 flooding, see the section,
Disabling Egress Flooding in Chapter 11, Forwarding Database.
395
Security
NOTE
Blackhole FDB entries added due to MAC security violations on the BlackDiamond 8800 family of switches (formerly
known as Aspen) and the Summit X450 switch are removed after each FDB aging period regardless of whether the
MAC addresses in question are still sending traffic. If the MAC addresses are still sending traffic, the blackhole
entries will be re-added after they have been deleted.
This command specifies the number of dynamically-learned MAC entries allowed for these ports in this
VLAN. The range is 0 to 500,000 addresses.
When the learned limit is reached, all new source MAC addresses are blackholed at the ingress and
egress points. This prevents these MAC addresses from learning and responding to ICMP and ARP
packets.
Dynamically learned entries still get aged and can be cleared. If entries are cleared or aged out after the
learning limit has been reached, new entries will then be able to be learned until the limit is reached
again.
Permanent static and permanent dynamic entries can still be added and deleted using the create
fdbentry and disable flooding port commands. These override any dynamically learned entries.
For ports that have a learning limit in place, the following traffic still flows to the port:
Packets destined for permanent MAC addresses and other non-blackholed MAC addresses
Broadcast traffic
EDP traffic
Traffic from the permanent MAC and any other non-blackholed MAC addresses still flows from the
virtual port.
To remove the learning limit, use the unlimited-learning option in the following command:
configure ports <portlist> vlan <vlan name> [limit-learning <number> | lock-learning |
unlimited-learning | unlock-learning]
This command displays the MAC security information for the specified VLAN.
show ports {mgmt | <portlist>} info {detail}
396
ESRP
vlan
10.1.2.1
S1
20.1.1.1
20.1.2.2
S2
192.10.1.1
S4
10.1.2.2
10.1.2.100
192.10.1.100
S3
30.1.1.2
10.1.2.1
30.1.1.1
EX_036
In Figure 24, S2 and S3 are ESRP-enabled switches, while S1 is an ESRP-aware (regular Layer 2) switch.
Configuring a MAC address limit on all S1 ports might prevent ESRP communication between S2 and
S3. To resolve this, you should add a back-to-back link between S2 and S3. This link is not needed if
MAC address limiting is configured only on S2 and S3, but not on S1.
This command causes all dynamic FDB entries associated with the specified VLAN and ports to be
converted to locked static entries. It also sets the learning limit to 0, so that no new entries can be
learned. All new source MAC addresses are blackholed.
397
Security
NOTE
Blackhole FDB entries added due to MAC security violations on the BlackDiamond 8800 family of switches and the
Summit X450 switch are removed after each FDB aging period regardless of whether the MAC addresses in question
are still sending traffic. If the MAC addresses are still sending traffic, the blackhole entries will be re-added after
they have been deleted.
Locked entries do not get aged, but can be deleted like a regular permanent entry.
For ports that have lock-down in effect, the following traffic still flows to the port:
Packets destined for the permanent MAC and other non-blackholed MAC addresses
Broadcast traffic
EDP traffic
Traffic from the permanent MAC still flows from the virtual port.
To remove MAC address lock down, use the unlock-learning option from the following command:
configure ports <portlist> vlan <vlan name> [limit-learning <number> | lock-learning |
unlimited-learning | unlock-learning]
When you remove the lock down using the unlock-learning option, the learning-limit is reset to
unlimited, and all associated entries in the FDB are flushed.
Notify a Layer 2 switch that a host has moved from one port to another port
However, hosts can launch man-in-the-middle attacks by sending out gratuitous ARP requests for the
router's IP address. This results in hosts sending their router traffic to the attacker, and the attacker
forwarding that data to the router. This allows passwords, keys, and other information to be
intercepted.
To protect against this type of attack, the router will send out its own gratuitous ARP request to
override the attacker whenever a gratuitous ARP broadcast with the router's IP address as the source is
received on the network. Also, the switch will add a MAC ACL to blackhole the offending host.
To enable gratuitous ARP protection, use the following command:
enable iparp gratuitous protect vlan <vlan-name>
398
DHCP Server
DHCP Server
Dynamic Host Configuration Protocol (DHCP) support was introduced into ExtremeWare XOS in
release 11.0. In simple terms, a DHCP server dynamically manages and allocates IP addresses to clients.
When a client accesses the network, the DHCP server provides an IP address to that client. The client is
not required to receive the same IP address each time it accesses the network. A DHCP server with
limited configuration capabilities is included in the switch to provide IP addresses to clients.
This section describes the following topics:
To set how long the IP address lease assigned by the server exists, use the following command:
configure vlan <vlan_name> dhcp-lease-timer <lease-timer>
To set the default gateway, Domain Name Servers (DNS) addresses, or Windows Internet Naming
Service (WINS) server, use the following command:
configure vlan <vlan_name> dhcp-options [default-gateway | dns-server | wins-server]
<ipaddress>
To remove the default gateway, DNS server addresses, and WINS server information for a particular
VLAN, use the following command:
unconfigure vlan <vlan_name> dhcp-options
To remove all the DHCP information for a particular VLAN, use the following command:
unconfigure vlan <vlan_name> dhcp
399
Security
You can clear the DHCP address allocation table selected entries, or all entries. You would use this
command to troubleshoot IP address allocation on the VLAN. To clear entries, use the following
command:
clear vlan <vlan_name> dhcp-address-allocation [[all {offered | assigned | declined |
expired}] | <ipaddress>]
The next two commands were retained for compatibility with earlier versions of ExtremeWare. To view
only the address allocation of the DHCP server on a VLAN, use the following command:
show vlan <vlan_name> dhcp-address-allocation
To view only the configuration of the DHCP server on a VLAN, use the following command:
show vlan <vlan_name> dhcp-config
Learning new traffic (BlackDiamond 10K switch only; the BlackDiamond 8800 family of switches and
the Summit X450 switch learn in hardware)
Routing and control protocols including ICMP, BGP, OSPF, STP, EAPS, ESRP, and so forth
Switch management traffic (switch access by Telnet, SSH, HTTP, SNMP, and so forth)
Other packets directed to the switch that must be discarded by the CPU
If any one of these functions is overwhelmed, the CPU may be too busy to service other functions and
switch performance will suffer. Even with very fast CPUs, there will always be ways to overwhelm the
CPU with packets that require costly processing.
DoS Protection is designed to help prevent this degraded performance by attempting to characterize the
problem and filter out the offending traffic so that other functions can continue. When a flood of CPU
bound packets reach the switch, DoS Protection will count these packets. When the packet count nears
the alert threshold, packets headers will be saved. If the threshold is reached, then these headers are
analyzed, and a hardware access control list (ACL) is created to limit the flow of these packets to the
CPU. This ACL will remain in place to provide relief to the CPU. Periodically, the ACL will expire, and
if the attack is still occurring, it will be re-enabled. With the ACL in place, the CPU will have the cycles
to process legitimate traffic and continue other services.
400
NOTE
User-created ACLs take precedence over the automatically applied DoS protect ACLs.
DoS Protection will send a notification when the notify threshold is reached.
You can also specify some ports as trusted ports, so that DoS protection will not be applied to those
ports.
This mode is useful to gather information about normal traffic levels on the switch. This will assist in
configuring denial of service protection so that legitimate traffic is not blocked.
The remainder of this section describes how to configure DoS protection, including alert thresholds,
notify thresholds, ACL expiration time, and so on.
After enabling DoS protection, the switch will count the packets handled by the CPU and periodically
evaluate whether to send a notification and/or create an ACL to block offending traffic. You can
configure a number of the values used by DoS protection if the default values are not appropriate for
your situation. The values that you can configure are:
intervalHow often, in seconds, the switch evaluates the DoS counter (default: 1 second)
alert thresholdThe number of packets received in an interval that will generate an ACL (default:
4000 packets)
notify thresholdThe number of packets received in an interval that will generate a notice (default:
3500 packets)
ACL expiration timeThe amount of time, in seconds, that the ACL will remain in place (default: 5
seconds)
To configure the interval at which the switch checks for DoS attacks, use the following command:
configure dos-protect interval <seconds>
401
Security
To configure the notification threshold, use the following command:
configure dos-protect type l3-protect notify-threshold <packets>
RADIUS
TACACS+
RADIUS, TACACS+, local database of accounts and passwords, and SSH are management access
security features that control access to the management functions available on the switch. These features
help ensure that any configuration changes to the switch can be done only by authorized users.
This section describes RADIUS and TACACS+. For a detailed description of the local database of
accounts and passwords (the two levels of management accounts), see Chapter 2, Accessing the
Switch. For information about SSH, see Secure Shell 2 on page 415.
RADIUS
Remote Authentication Dial In User Service (RADIUS), in RFC 2138, is a mechanism for authenticating
and centrally administrating access to network nodes. The ExtremeWare XOS RADIUS implementation
allows authentication for Telnet or console access to the switch.
402
NOTE
You cannot enable RADIUS and TACACS+ at the same time.
You define a primary and secondary RADIUS server for the switch to contact. When a user attempts to
log in using Telnet, HTTP, or the console, the request is relayed to the primary RADIUS server and then
to the secondary RADIUS server, if the primary does not respond. If the RADIUS client is enabled, but
access to the RADIUS primary and secondary server fails, the switch uses its local database for
authentication. Beginning with ExtremeWare XOS 11.2, you can specify one pair of RADIUS servers for
switch management and another pair for network login.
The privileges assigned to the user (admin versus nonadmin) at the RADIUS server take precedence
over the configuration in the local switch database.
This section describes the following topics:
Configuring the Shared Secret Password for RADIUS Servers on page 404
Configuring the Shared Secret Password for RADIUS Accounting Servers on page 405
To configure the primary RADIUS server, specify primary. To configure the secondary RADIUS server,
specify secondary.
By default, switch management and network login use the same primary and secondary RADIUS
servers for authentication. To specify one pair of RADIUS servers for switch management and another
pair for network login, make sure to specify the mgmt-access or netlogin keywords.
If the timeout expires, another authentication attempt will be made. After three failed attempts to
authenticate, the alternate server will be used. After six failed attempts, local user authentication will be
used.
If you do not specify the mgmt-access or netlogin keywords, the timeout interval applies to both
switch management and netlogin RADIUS servers.
403
Security
To configure the primary RADIUS server, specify primary. To configure the secondary RADIUS server,
specify secondary.
If you do not specify the mgmt-access or netlogin keywords, the secret applies to both the primary or
secondary switch management and netlogin RADIUS servers.
Do not use the encrypted keyword to set the shared secret. The encrypted keyword is primarily for
the output of the show configuration command, so the shared secret is not revealed in the command
output.
If you do not specify the mgmt-access or netlogin keywords, RADIUS authentication is enabled on the
switch for both management and network login.
To disable RADIUS authentication, use the following command:
disable radius {mgmt-access | netlogin}
If you do not specify the mgmt-access or netlogin keywords, RADIUS authentication is disabled on
the switch for both management and network login.
To configure the primary RADIUS accounting server, specify primary. To configure the secondary
RADIUS accounting server, specify secondary.
404
If the timeout expires, another authentication attempt will be made. After three failed attempts to
authenticate, the alternate server will be used.
To configure the primary RADIUS accounting server, specify primary. To configure the secondary
RADIUS accounting server, specify secondary.
If you do not specify the mgmt-access or netlogin keywords, the secret applies to both the primary or
secondary switch management and netlogin RADIUS accounting servers.
Do not use the encrypted keyword to set the shared secret. The encrypted keyword is primarily for
the output of the show configuration command, so the shared secret is not revealed in the command
output.
If you do not specify a keyword, RADIUS accounting is enabled on the switch for both management
and network login.
To disable RADIUS accounting, use the following command:
disable radius-accounting {mgmt-access | netlogin}
If you do not specify a keyword, RADIUS accounting is disabled on the switch for both management
and network login.
405
Security
Configuring RADIUS
You can define primary and secondary server communication information and, for each RADIUS server,
the RADIUS port number to use when talking to the RADIUS server. The default port value is 1812 for
authentication and 1813 for accounting. The client IP address is the IP address used by the RADIUS
server for communicating back to the switch.
NOTE
For information on how to use and configure your RADIUS server, refer to the documentation that came with your
RADIUS server.
User-Name
User-Password
Service-Type
Login-IP-Host
EAP-Message
Message-Authenticator
State
Termination-Action
Session-Timeout
NAS-Port-Type
Calling-Station-ID
406
Read-only
Read-write
Extreme RADIUS
Extreme Networks provides its users, free of charge, a radius server based on Merit RADIUS. Extreme
RADIUS provides per-command authentication capabilities in addition to the standard set of radius
features. Source code for Extreme RADIUS can be obtained from the Extreme Networks Technical
Assistance Center and has been tested on Red Hat Linux.
When Extreme RADIUS is up and running, the two most commonly changed files will be users and
profiles. The users file contains entries specifying login names and the profiles used for per-command
authentication after they have logged in. Sending a HUP signal to the RADIUS process is sufficient to
get changes in the users file to take place. Extreme RADIUS uses the file named profiles to specify
command lists that are either permitted or denied to a user based on their login identity. Changes to the
profiles file require the RADIUS server to be shutdown and restarted. Sending a HUP signal to the
RADIUS process is not enough to force changes to the profiles file to take effect.
When you create command profiles, you can use an asterisk to indicate any possible ending to any
particular command. The asterisk cannot be used as the beginning of a command. Reserved words for
commands are matched exactly to those in the profiles file. Due to the exact match, it is not enough to
simply enter sh for show in the profiles file, the complete word must be used. Commands can still
be entered in the switch in partial format.
When you use per-command authentication, you must ensure that communication between the
switch(es) and radius server(s) is not lost. If the RADIUS server crashes while users are logged in, they
will have full administrative access to the switch until they log out. Using two RADIUS servers and
enabling idle timeouts on all switches will greatly reduce the chance of a user gaining elevated access
due to RADIUS server problems.
Cistron RADIUS
Cistron RADIUS is a popular server, distributed under GPL. Cistron RADIUS can be found at:
http://www.radius.cistron.nl/
When you configure the Cistron server for use with Extreme switches, you must pay close attention to
the users file setup. The Cistron RADIUS dictionary associates the word Administrative-User with
Service-Type value 6, and expects the Service-Type entry to appear alone on one line with a leading tab
character.
The following is a user file example for read-write access:
adminuser Auth-Type = System
407
Security
Service-Type = Administrative-User,
Filter-Id = unlim
RSA Ace
For users of their SecureID product, RSA offers RADIUS capability as part of their ACE server software.
With some versions of ACE, the RADIUS shared-secret is incorrectly sent to the switch resulting in an
inability to authenticate. As a work around, do not configure a shared-secret for RADIUS accounting
and authentication servers on the switch.
=
=
=
=
=
Extreme Networks
Extreme
yes
per-port-type
2000
After modifying the vendor.ini file, the desired user accounts must be configured for the MaxConcurrent connections. Using the SBR Administrator application, enable the check box for MaxConcurrent connections and fill in the desired number of maximum sessions.
408
Key
[type]
[version]
--------------- -------------- --------test
type = nas
v2
%^$%#*(&!(*&)+
type=nas
:-):-(;^):-}!
type nas
hmoemreilte.ses
[prefix]
-------pfx
pm1.
pm2.
testing
moretesting
whoknows?
andrew-linux
eric
eric
samf
type proxy
v1
type=Ascend:NAS v1
type=NAS+RAD_RFC+ACCT_RFC
type=nas
type=nas
type=nas
type=nas
users
user
Password
Filter-Id =
admin
Password
Filter-Id =
= ""
"unlim"
= "", Service-Type = Administrative
"unlim"
eric
albert
Password = "password", Service-Type = Administrative
Filter-Id = "unlim"
samuel Password = "password", Service-Type = Administrative
Filter-Id = "unlim"
Within the users configuration file, additional keywords are available for Profile-Name and ExtremeCLI-Authorization. To use per-command authentication, enable the CLI authorization function and
indicate a profile name for that user. If authorization is enabled without specifying a valid profile, the
user is unable to perform any commands.
Next, define the desired profiles in an ASCII configuration file called profiles. This file contains
named profiles of exact or partial strings of CLI commands. A named profile is linked with a user
through the users file. A profile with the permit on keywords allows use of only the listed commands.
A profile with the deny keyword allows use of all commands except the listed commands.
CLI commands can be defined easily in a hierarchal manner by using an asterisk (*) to indicate any
possible subsequent entry. The parser performs exact string matches on other text to validate
commands. Commands are separated by a comma (,) or newline.
Looking at the following example content in profiles for the profile named PROFILE1, which uses the
deny keyword, the following attributes are associated with the user of this profile:
409
Security
We know from the users file that this applies to the users albert and lulu. We also know that eric is
able to log in, but is unable to perform any commands, because he has no valid profile assigned.
In PROFILE2, a user associated with this profile can use any enable command, the clear counters
command and the show management command, but can perform no other functions on the switch. We
also know from the users file that gerald has these capabilities.
The following lists the contents of the file users with support for per-command authentication:
user
Password = ""
Filter-Id = "unlim"
admin
eric
410
TACACS+
Terminal Access Controller Access Control System Plus (TACACS+) is a mechanism for providing
authentication, authorization, and accounting on a centralized server, similar in function to RADIUS.
The ExtremeWare XOS version of TACACS+ is used to authenticate prospective users who are
attempting to administer the switch. TACACS+ is used to communicate between the switch and an
authentication database.
NOTE
You cannot use RADIUS and TACACS+ at the same time.
You can configure two TACACS+ servers, specifying the primary server address, secondary server
address, and TCP port number to be used for TACACS+ sessions.
This section describes the following topics:
Configuring the Shared Secret Password for TACACS+ Servers on page 412
Configuring the Shared Secret Password for TACACS+ Accounting Servers on page 414
To configure the primary TACACS+ server, specify primary. To configure the secondary TACACS+
server, specify secondary.
To detect and recover from a TACACS+ server failure when the timeout has expired, the switch makes
one authentication attempt before trying the next designated TACACS+ server or reverting to the local
database for authentication. In the event that the switch still has IP connectivity to the TACACS+ server,
but a TCP session cannot be established, (such as a failed TACACS+ daemon on the server), fail over
happens immediately regardless of the configured timeout value.
411
Security
For example, if the timeout value is set for 3 seconds (the default value), it will take 3 seconds to fail
over from the primary TACACS+ server to the secondary TACACS+ server. If both the primary and the
secondary servers fail or are unavailable, it takes approximately 6 seconds to revert to the local database
for authentication.
To configure the primary TACACS+ server, specify primary. To configure the secondary TACACS+
server, specify secondary.
Do not use the encrypted keyword to set the shared secret. The encrypted keyword is primarily for
the output of the show configuration command, so the shared secret is not revealed in the command
output.
All other settings use the default settings as described earlier in this section or in the ExtremeWare XOS
Command Reference Guide.
configure tacacs primary server 10.201.31.238 client-ip 10.201.31.85 vr "VR-Default"
configure tacacs primary shared-secret purple
configure tacacs secondary server 10.201.31.235 client-ip 10.201.31.85 vr "VR-Default"
412
To display the TACACS+ server settings, use the show tacacs command. The following is sample
output from this command:
TACACS+: enabled
TACACS+ Authorization: disabled
TACACS+ Accounting : disabled
TACACS+ Server Connect Timeout sec: 3
Primary TACACS+ Server:
Server name
:
IP address
: 10.201.31.238
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
Secondary TACACS+ Server:
Server name
:
IP address
: 10.201.31.235
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
TACACS+ Acct Server Connect Timeout sec: 3
Primary TACACS+ Accounting Server:Not configured
Secondary TACACS+ Accounting Server:Not configured
To configure the primary TACACS+ accounting server, specify primary. To configure the secondary
TACACS+ accounting server, specify secondary.
To detect and recover from a TACACS+ accounting server failure when the timeout has expired, the
switch makes one authentication attempt before trying the next designated TACACS+ accounting server
or reverting to the local database for authentication. In the event that the switch still has IP connectivity
to the TACACS+ accounting server, but a TCP session cannot be established, (such as a failed TACACS+
daemon on the accounting server), fail over happens immediately regardless of the configured timeout
value.
For example, if the timeout value is set for 3 seconds (the default value), it takes 3 seconds to fail over
from the primary TACACS+ accounting server to the secondary TACACS+ accounting server. If both
413
Security
the primary and the secondary servers fail or are unavailable, it takes approximately 6 seconds to revert
to the local database for authentication.
To configure the primary TACACS+ accounting server, specify primary. To configure the secondary
TACACS+ accounting server, specify secondary.
Do not use the encrypted keyword to set the shared secret. The encrypted keyword is primarily for
the output of the show configuration command, so the shared secret is not revealed in the command
output.
Configures the shared secret for the primary TACACS+ accounting server
Configures the shared secret for the secondary TACACS+ accounting server
All other settings use the default settings as described earlier in this section or in the ExtremeWare XOS
Command Reference Guide.
configure tacacs-accounting primary server 10.201.31.238 client-ip 10.201.31.85 vr
"VR-Default"
configure tacacs-accounting primary shared-secret purple
414
Secure Shell 2
configure tacacs-accounting secondary server 10.201.31.235 client-ip 10.201.31.85 vr
"VR-Default"
config tacacs-accounting secondary shared-secret purple
enable tacacs-accounting
To display the TACACS+ accounting server settings, use the show tacacs or the show tacacsaccounting command. The following is sample output from the show tacacs command:
TACACS+: enabled
TACACS+ Authorization: enabled
TACACS+ Accounting : enabled
TACACS+ Server Connect Timeout sec: 3
Primary TACACS+ Server:
Server name
:
IP address
: 10.201.31.238
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
Secondary TACACS+ Server:
Server name
:
IP address
: 10.201.31.235
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
TACACS+ Acct Server Connect Timeout sec: 3
Primary TACACS+ Accounting Server:
Server name
:
IP address
: 10.201.31.238
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
Secondary TACACS+ Accounting Server:
Server name
:
IP address
: 10.201.31.235
Server IP Port: 49
Client address: 10.201.31.85 (VR-Default)
Shared secret : purple
Secure Shell 2
Secure Shell 2 (SSH2) is a feature of ExtremeWare XOS that allows you to encrypt session data between
a network administrator using SSH2 client software and the switch or to send encrypted data from the
switch to an SSH2 client on a remote system. Configuration and policy files may also be transferred to
the switch using the Secure Copy Protocol 2 (SCP2) or the Secure File Transfer Protocol (SFTP).
Beginning with ExtremeWare XOS 11.2, you can also use SSH2 to connect to other devices from the
switch. The ExtremeWare XOS CLI provides a command that enables the switch to function as an SSH2
client, sending commands to a remote system via an SSH2 session.
The ExtremeWare XOS SSH2 switch application also works with SSH2 client (version 2.x or later) from
SSH Communication Security, and with (version 2.5 or later) from OpenSSH. The SFTP file transfer
protocol is required for file transfer using SCP2.
415
Security
The section describes the following topics:
Because SSH2 is currently under U.S. export restrictions, you must first obtain and install the ssh.xmod
software module from Extreme Networks before you can enable SSH2.
You must enable SSH2 on the switch before you can connect to the switch using an external SSH2 client.
Enabling SSH2 involves two steps:
Enabling SSH2 access by specifying a TCP port to be used for communication and specifying on
which virtual router SSH2 is enabled.
After it has enabled, by default, SSH2 uses TCP port 22 and is available on all virtual routers.
An authentication key must be generated before the switch can accept incoming SSH2 sessions. This can
be done automatically by the switch, or you can enter a previously generated key. To have the key
generated by the switch, use the following command:
configure ssh2 key
The key generation process can take up to ten minutes. After the key has been generated, you should
save your configuration to preserve the key.
To use a key that has been previously created, use the following command:
configure ssh2 key {pregenerated}
NOTE
The pregenerated key must be one that was generated by the switch. To get such key, you can use the command
show configuration exsshd to display the key on the console. Copy the key to a text editor and remove the carriage
416
Secure Shell 2
return/line feeds from the key. Finally, copy and paste the key into the command line. The key must be entered as
one line.
The key generation process generates the SSH2 private host key. The SSH2 public host key is derived
from the private host key and is automatically transmitted to the SSH2 client at the beginning of an
SSH2 session.
To enable SSH2, use the following command:
enable ssh2 {access-profile [<access_profile> | none]} {port <tcp_port_number>} {vr
[<vr_name> | all | default]}
You can also specify a TCP port number to be used for SSH2 communication. By default the TCP port
number is 22. Beginning with ExtremeWare XOS 11.2, the switch accepts IPv6 connections.
Before you initiate a session from an SSH2 client, ensure that the client is configured for any non-default
access list or TCP port information that you have configured on the switch. After these tasks are
accomplished, you may establish an SSH2-encrypted session with the switch. Clients must have a valid
user name and password on the switch in order to log in to the switch after the SSH2 session has been
established.
To view the status of SSH2 sessions on the switch, use the show management command. The show
management command displays information about the switch including the enable/disable state for
SSH2 sessions and whether a valid key is present.
For additional information on the SSH protocol refer to Federal Information Processing Standards
Publication (FIPSPUB) 186, Digital Signature Standard, 18 May 1994. This can be download from: ftp://
ftp.cs.hut.fi/pub/ssh. General technical information is also available from:
http://www.ssh.fi
Use the edit policy command to launch a VI-like editor on the switch. You can create the policy
directly on the switch.
Use the tftp command to transfer a policy that you created using a text editor on another system to
the switch.
For more information about creating and implementing ACLs and policies, see Chapter 13, Policy
Manager and Chapter 14, Access Lists (ACLs).
417
Security
Entry AllowTheseSubnets {
if {
source-address 10.203.133.0 /24;
}
then
{
permit;
}
}
In the following example named MyAccessProfile_2.pol, the switch does not permit connections from
the subnet 10.203.133.0/24 but accepts connections from all other addresses:
MyAccessProfile_2.pol
Entry dontAllowTheseSubnets {
if {
source-address 10.203.133.0 /24;
}
then
{
deny;
}
}
Entry AllowTheRest {
If {
; #none specified
}
then
{
permit;
}
}
418
Secure Shell 2
ExtremeWare XOS only allows SCP2 to transfer to the switch files named as follows:
In the following examples, you are using a Linux system to move files to and from the switch at
192.168.0.120, using the switch administrator account admin.You are logged into your Linux system as
user.
To transfer the primary configuration file from the switch to your current Linux directory using SCP2,
use the following command:
[user@linux-server]# scp2 admin@192.168.0.120:/config/primary.cfg primary.cfg
To copy the policy filename test.pol from your Linux system to the switch, use the following command:
[user@linux-server]# scp2 test.pol admin@192.168.0.120:/config/test.pol
NOTE
The BlackDiamond 8800 family of switches and the Summit X450 switch do not support user-created VRs.
To send commands to a remote system using SSH2, use the following command:
ssh2 {cipher [3des | blowfish]} {port <portnum>} {compression [on | off]} {user
<username>} {debug <debug_level>} {<username>@} [<host> | <ipaddress>] {<remote
command>} {vr <vr_name>}
The remote commands can be any command acceptable by the remote system. You can specify the login
user name as a separate argument or as part of the user@host specification. If the login user name for
the remote system is the same as your user name on the switch, you can omit the username parameter
entirely.
For example, to obtain a directory listing from a remote Linux system with IP address 10.10.0.2 using
SSH2, enter the following command:
ssh2 admin@10.10.0.2 ls
To initiate a file copy from a remote system to the switch using SCP2, use the following command:
scp2 {cipher [3des | blowfish]} {port <portnum>} {debug <debug_level>} <user>@
[<hostname> | <ipaddress>]:<remote_file> <local_file> {vr <vr_name>}
419
Security
For example, to copy the configuration file test.cfg on host system1 to the switch, enter the following
command:
scp2 admin@system1:/config/test.cfg localtest.cfg
To initiate a file copy to a remote system from the switch using SCP2, use the following command:
scp2 {cipher [3des | blowfish]} {port <portnum>} {debug <debug_level>} <local_file>
<user>@ [<hostname> | <ipaddress>]:<remote_file> {vr <vr_name>}
For example, to copy the configuration file engineering.cfg from the switch to host system1, enter the
following command:
scp2 engineering.cfg admin@system1:/config/engineering.cfg
RSA for public key cryptography (generation of certificate and public-private key pair, certificate
signing). RSA key size between 1024 and 4096 bits.
The Converged Network Analyzer (CNA) Agent requires SSL to encrypt communication between the
CNA Agent and the CNA Server. For more information about the CNA Agent, see Appendix C, CNA
Agent.
420
To use SSL with web-based login (secure HTTP access, HTTPS) you must specify the HTTPS
protocol when configuring the redirect URL.
If you are downloading the SSH module for the first time and want to immediately use SSL for
secure HTTPS web-based login, restart the thttpd process after installing the SSH module. For more
detailed information about activating the SSH module, see Guidelines for Activating SSL in
Appendix A.
To enable SSL and allow secure HTTP (HTTPS) access on the default port (443), use the following
command:
enable web https
421
Security
The size of the certificate depends on the RSA key length (privkeylen) and the length of the other
parameters (country, organization name, and so forth) supplied by the user. If the RSA key length is
1024, then the certificate is approximately 1 kb. For an RSA key length of 4096, the certificate length is
approximately 2 kb, and the private key length is approximately 3 kb.
NOTE
For security measures, you can only download a certificate key in the VR-Mgmt virtual router.
To see whether the private key matches with the public key stored in the certificate, use the following
command:
show ssl
HTTPS port configured. This is the port on which the clients will connect.
Length of the RSA key (the number of bits used to generate the private key).
If the operation is successful, the existing private key is overwritten. After the download is successful, a
check is performed to find out whether the private key downloaded matches the public key stored in
the certificate. If the private and public keys do not match, the switch displays a warning message
similar to the following: Warning: The Private Key does not match with the Public Key in
the certificate. This warning acts as a reminder to also download the corresponding certificate.
For security reasons, when downloading private keys, Extreme Networks recommends obtaining a pregenerated key rather than downloading a private key from a TFTP server. See Configuring
Pregenerated Certificates and Keys on page 423 for more information.
422
You can copy and paste the certificate into the command line followed by a blank line to end the
command.
This command is also used when downloading or uploading the configuration. Do not modify the
certificate stored in the uploaded configuration file because the certificate is signed using the issuers
private key.
The certificate and private key file should be in PEM format and generated using RSA as the
cryptography algorithm.
To get the pregenerated private key from the user, use the following command:
configure ssl privkey pregenerated
You can copy and paste the key into the command line followed by a blank line to end the command.
This command is also used when downloading or uploading the configuration. The private key is
stored in the EEPROM.
The certificate and private key file should be in PEM format and generated using RSA as the
cryptography algorithm.
423
Security
424
18 Network Login
This chapter describes the following topics:
Web-based login using HTTPSif you install the SSH software module that includes SSLavailable
on each port
Multiple supplicants for web-based, MAC-based, and 802.1x authentication on each port
425
Network Login
answer DHCP requests following authentication if DHCP is enabled on the specified VLAN. If netlogin
clients are required to obtain DHCP leases from an external DHCP server elsewhere on the network,
DHCP should not be enabled on the VLAN.
The DHCP allocation for network login has a short time duration of 10 seconds and is intended to
perform web-based network login only. As soon as the client is authenticated, it is deprived of this
address. The client must obtain an operational address from another DHCP server in the network.
DHCP is not required for 802.1x, because 802.1x uses only Layer 2 frames (EAPOL) or MAC-based
network login.
URL redirection (applicable to web-based mode only) is a mechanism to redirect any HTTP request to
the base URL of the authenticator when the port is in unauthenticated mode. In other words, when the
user tries to log in to the network using the browser, the user is first redirected to the network login
page. Only after a successful login is the user connected to the network. URL redirection requires that
the switch is configured with a DNS client.
Web-based, MAC-based, and 802.1x authentication each have advantages and disadvantages, as
summarized next.
1.
426
A workstation running Windows 2000 Service Pack 4 or Windows XP supports 802.1x natively and does not
require additional authentication software.
Works with any operating system that is capable of obtaining an IP address using DHCP. There is no
need for special client side software; only a web browser is needed.
The login process involves manipulation of IP addresses and must be done outside the scope of a
normal computer login process. It is not tied to a Windows login. The client must bring up a login
page and initiate a login.
Works silently. The user, client, or device does not know that it gets authenticated.
Ease of management. A set of devices can easily be grouped by the vendor part of the MAC address.
There is no re-authentication mechanism. The FDB aging timer determines the logout.
Security is based on the MAC address of the client, so the network is more vulnerable to spoofing
attacks.
In cases where the 802.1x is natively supported, login and authentication happens transparently.
Authentication happens at Layer 2. It does not involve getting a temporary IP address and
subsequent release of the address to obtain a permanent IP address.
802.1x native support is available only on newer operating systems, such as Windows XP.
802.1x requires an EAP-capable RADIUS Server. Most current RADIUS servers support EAP, so this
is not a major disadvantage.
Transport Layer Security (TLS) and Tunneled TLS (TTLS) authentication methods involve Public Key
Infrastructure (PKI), which adds to the administrative requirements.
427
Network Login
the BlackDiamond 10K switch, BlackDiamond 12804 switch, or 10 Gigabit Ethernet ports. For more
information, see Configuring Netlogin MAC-Based VLANsBlackDiamond 8800 Family of Switches
and the Summit X450 Switch Only on page 452.
The choice of web-based versus 802.1x authentication is again on a per-MAC basis. Among multiple
clients on the same port, it is possible that some clients use web-based mode to authenticate, and some
others use 802.1x. This is not true if you configure netlogin MAC-based VLANs on the BlackDiamond
8800 family of switches of the Summit X450 switch. For more information, see Configuring Netlogin
MAC-Based VLANsBlackDiamond 8800 Family of Switches and the Summit X450 Switch Only on
page 452.
NOTE
With multiple supplicant support, after the first MAC is authenticated, the port is transitioned to the authenticated
state and other unauthenticated MACs can listen to all data destined for the first MAC. Be aware of this as
unauthenticated MACs can listen to all broadcast and multicast traffic directed to a network login-authenticated
port.
428
NOTE
If you use 802.1x network login, authenticated clients remain authenticated during failover; however, shortly after
failover, all authenticated clients automatically re-authenticate themselves. Re-authentication occurs without user
intervention.
If failover occurs during the authentication or re-authentication of a client, the client must repeat the
authentication process.
To initiate hitless MSM failover on a network that uses network login:
1 Confirm that the MSMs are synchronized and have identical software and switch configurations
using the show switch {detail} command. The output displays the status of the MSMs, with the
primary MSM showing MASTER and the backup MSM showing BACKUP (InSync).
If the MSMs are not synchronized, proceed to step 2.
If the MSMs are synchronized, proceed to step 3.
2 If the MSMs are not in sync, replicate all saved images and configurations from the primary to the
backup using the synchronize command.
3 Initiate failover using the run msm-failover command.
For more detailed information about verifying the status of the MSMs and system redundancy, see
Understanding System Redundancy with Dual MSMs InstalledModular Switches Only on page 72.
For more information about hitless failover, see Understanding Hitless Failover SupportModular
Switches Only on page 76.
This section also contains information about the Exclusions and Limitations of network login.
For more detailed information about a specific mode of network login, including configuration
examples, refer to the following sections:
429
Network Login
authenticateNetwork login authenticates the first client that requests a move and moves that
client to the requested VLAN. Network login authenticates the second client but does not move that
client to the requested VLAN. The second client moves to the first clients authenticated VLAN.
denyNetwork login authenticates the first client that requests a move and moves that client.
430
Authenticating Users
All unauthenticated MACs will be seeing broadcasts and multicasts sent to the port if even a single
MAC is authenticated on that port.
Network login must be disabled on a port before that port can be deleted from a VLAN.
In Campus mode on the BlackDiamond 8800 family of switches and the Summit X450 switch, with
untagged VLANs and the netlogin ports mode configured as port-mode, after the port moves to the
destination VLAN, the original VLAN for that port is not displayed.
Link Aggregation
Authenticating Users
Network login uses two methods to authenticate users trying to access the network:
RADIUS servers
Local database
All three network login protocols, web-based, MAC-based, and 802.1x netlogin, support RADIUS
authentication. Only web-based and MAC-based netlogin support local database authentication.
This section describes the following topics in greater detail:
In the following example using FreeRADIUS, you add the configuration to the RADIUS server users
file. The users file determines which attributes are sent back by the RADIUS server to the RADIUS
client (an Extreme Networks switch). Depending on your RADIUS server, where and how you add the
configuration might be different.
431
Network Login
Add the following line to the RADIUS server users file for netlogin-only disabled users:
Extreme:Extreme-Netlogin-Only = Disabled
Add the following line to the RADIUS server users file for netlogin-only enabled users:
Extreme:Extreme-Netlogin-Only = Enabled
Table 55 contains the Vendor Specific Attribute (VSA) definitions for web-based, MAC-based, and 802.1x
network login. The Extreme Network Vendor ID is 1916.
Table 55: VSA Definitions for Web-based, MAC-based, and 802.1x network login
VSA
Extreme: NetloginExtended-VLAN
Vendor
Type
Type
Sent-in
Description
211
String
Access-Accept
Extreme: NetloginVLAN-Name
203
String
Access-Accept
Extreme: NetloginVLAN-ID
209
Integer
Access-Accept
Extreme: Netlogin-URL
204
String
Access-Accept
Extreme: NetloginURL-Desc
205
String
Access-Accept
Extreme: Netlogin-Only
206
Integer
Access-Accept
432
Attribute
Attribute
Value
Type
Sent-in
Description
IETF: Tunnel-Type
64
Integer
Access-Accept
IETF: Tunnel-Medium-Type
65
Integer
Access-Accept
IETF: Tunnel-Private-Group-ID
81
String
Access-Accept
Authenticating Users
The NetLogin-Url and NetLogin-Url-Desc attributes are used in case of Web-based login as the page to
use for redirection after a successful login. Other authentication methods will ignore these attributes.
The other attributes are used in the following order to determine the destination VLAN to use:
IETF: Tunnel-Private-Group-ID representing the VLAN TAG as a string, but only if IETF: TunnelType == VLAN(13) and IETF: Tunnel-Medium-Type == 802 (6).
If none of the previously described attributes are present ISP mode is assumed, and the client remains
in the configured VLAN.
VSA 211Extreme: Netlogin-Extended-VLAN. The following describes the guidelines for VSA 211:
For tagged VLAN movement with 802.1x netlogin, you must use VSA 211.
For untagged VLAN movement with 802.1x netlogin, you can use all current Extreme Networks
VLAN VSAs: VSA 203, VSA 209, and VSA 211.
To specify the VLAN name or the VLAN ID, use an ASCII string; however, you cannot specify both
the VLAN name and the VLAN ID at the same time. If the string only contains numbers, it is
interpreted as the VLAN ID.
For tagged VLANs, specify T for tagged before the VLAN name or VLAN ID.
For untagged VLANs, specify U for untagged before the VLAN name or VLAN ID.
For movement based on the incoming ports traffic, specify * before the VLAN name or VLAN ID.
The behavior can be either tagged or untagged, based on the incoming ports traffic, and mimics the
behavior of VSA 203 and VSA 209, respectively.
VSA 211 Examples. The following examples use FreeRADIUS to modify the VSA to support tagged or
untagged VLANs using either the VLAN name or the VLAN ID.
*Include before the VLAN name for movement based on the incoming ports traffic (mimics
the behavior of VSA 203)
433
Network Login
To configure the untagged VLAN data, add the following line:
Extreme-Netlogin-Extended-VLAN = Udata
To configure the VLAN orange to be tagged or untagged based on the incoming ports traffic, add
the following line:
Extreme-Netlogin-Extended-VLAN = *orange
*Include before the VLAN name for movement based on the incoming ports traffic (mimics
the behavior of VSA 209)
To configure a tagged VLAN with a VLAN ID of 229, add the following line:
Extreme-Netlogin-Extended-VLAN = T229
To configure an untagged VLAN with a VLAN ID of 4091, add the following line:
Extreme-Netlogin-Extended-VLAN = U4091
To configure a VLAN with a VLAN ID of 145 to be tagged or untagged based on the incoming ports
traffic, add the following line:
Extreme-Netlogin-Extended-VLAN = *145
VSA 203Extreme: Netlogin-VLAN-Name. The following describes the guidelines for VSA 203:
For untagged VLAN movement with 802.1x netlogin, you can use all current Extreme Networks
VLAN VSAs: VSA 203, VSA 209, and VSA 211.
When using this VSA, you do not specify a tagged or untagged VLAN.
VSA 203 Example. The following example modifies the VSA to specify the name of the destination
VLAN. To configure VLAN purple as the destination VLAN, add the following line:
Extreme: Netlogin-VLAN-Name = purple
VSA 209Extreme: Netlogin-VLAN-ID. The following describes the guidelines for VSA 209:
For untagged VLAN movement with 802.1x netlogin, you can use all current Extreme Networks
VLAN VSAs: VSA 203, VSA 209, and VSA 211.
When using this VSA, you do not specify a tagged or untagged VLAN.
VSA 209 Example. The following example modifies the VSA to specify the VLAN ID (tag) of the
destination VLAN. To configure the VLAN with VLAN ID 234 as the destination VLAN, add the
following line:
Extreme: Netlogin-VLAN-ID = 234
434
Authenticating Users
VSA 204Extreme: Netlogin-URL. The following describes the guidelines for VSA 204:
If you do not specify a URL, the network login infrastructure uses the default redirect page URL,
http://www.extremenetworks.com, or the URL that you configured using the configure netlogin
redirect-page command.
VSA 204 applies only to the web-based authentication mode of Network Login.
VSA 204 Example. The following example modifies the VSA to specify the destination URL after
successful authentication. To configure the redirect URL as http://www.myhomepage.com, add the
following line:
Extreme: Netlogin-URL = http://www.myhomepage.com
VSA 205Extreme: Netlogin-URL-Desc. The following describes the guidelines for VSA 205:
To include a description of the redirect page URL (as specified by VSA 204), use an ASCII string.
To let the user know where they will be redirected to after authentication, use an ASCII string to
provide a brief description of the URL.
VSA 205 applies only to the web-based authentication mode of Network Login.
VSA 205 Example. The following example modifies the VSA to describe the network login URL. To
describe the network login URL as my home page, add the following line:
Extreme: Netlogin-URL-Desc = homepage
VSA 206Extreme: Netlogin-Only. The following describes the guidelines for VSA 206:
To specify that a user can authenticate only via network login, use a value of 1 (enabled).
To specify that a user can authenticate via other methods, use a value of 0 (disabled).
VSA 206 Example. See the examples described in the section Creating User Accounts on the RADIUS
Server on page 431.
If both the primary and secondary (if configured) RADIUS servers timeout or are unable to respond
to authentication requests
If any of the above conditions are met, the switch checks for a local user account and attempts to
authenticate against that local account.
For local authentication to occur, you must configure the switchs local database with a user name and
password for network login. Extreme Networks recommends a maximum of 64 local accounts. If you
need more than 64 local accounts, Extreme Networks recommends using RADIUS for authentication.
435
Network Login
Beginning with ExtremeWare XOS 11.3 you can also specify the destination VLAN to enter upon a
successful authentication.
If you have a BlackDiamond 8800 family switch or a Summit X450 switch, you can also use local
database authentication in conjunction with netlogin MAC-based VLANs. For more detailed
information about netlogin MAC-based VLANs, see Configuring Netlogin MAC-Based VLANs
BlackDiamond 8800 Family of Switches and the Summit X450 Switch Only on page 452.
The following sections describe how to configure your switch for local database authentication:
Creating a Local Netlogin AccountUser Name and Password Only on page 436
User names are not case-sensitive; passwords are case-sensitive. User names must have a minimum of 1
character and a maximum of 32 characters. Passwords must have a minimum of 0 characters and a
maximum of 32 characters. If you use RADIUS for authentication, Extreme Networks recommends that
you use the same user name and password for both local authentication and RADIUS authentication.
If you attempt to create a user name with more than 32 characters, the switch displays the following
messages:
%% Invalid name detected at '^' marker.
%% Name cannot exceed 32 characters.
If you attempt to create a password with more than 32 characters, the switch displays the following
message after you re-enter the password:
Password cannot exceed 32 characters
The encrypted option is used by the switch to encrypt the password. Do not use this option through the
command line interface (CLI). After you enter a local netlogin user name, press [Return]. The switch
prompts you twice to enter the password.
436
Authenticating Users
The following example:
For information about specifying the destination VLAN, see the next section Specifying a Destination
VLAN.
Adding VLANs at a Later Time. To specify the destination VLAN after you created the local netlogin
account, use the following command:
configure netlogin local-user <user-name> {vlan-vsa [[{tagged | untagged}
[<vlan_name>] | <vlan_tag>]] | none]}
437
Network Login
noneSpecifies that the VSA 211 wildcard (*) is applied, only if you do not specify tagged or
untagged
Destination VLAN attributes including: adding clients tagged or untagged, the name of the VLAN,
and the VLAN ID
If you try modifying a local netlogin account that is not present on the switch, or you incorrectly enter
the name of the account, output similar to the following appears:
* SummitX450.14 # configure netlogin local-user purplenet
^
%% Invalid input detected at '^' marker.
To confirm the names of the local netlogin accounts on your switch, use the following command:
show netlogin local-users
Updating the Local Netlogin Password. To update the password of an existing local netlogin account, use
the following command:
configure netlogin local-user <user_name>
Where user_name specifies the name of the existing local netlogin account. After you enter the local
netlogin user name, press [Return]. The switch prompts you to enter a password. At the prompt enter
the new password and press [Return]. The switch then prompts you to reenter the password.
Passwords are case-sensitive. Passwords must have a minimum of 0 characters and a maximum of 32
characters. If you attempt to create a password with more than 32 characters, the switch displays the
following message after you re-enter the password:
Password cannot exceed 32 characters
The following example modifies the password for the existing local netlogin account megtest. The
following is a sample display from this command:
configure netlogin local-user megtest
password: <Enter the new password. The switch does not display the password.>
Reenter password: <Re-enter the new password. The switch does not display the
password.>
After you complete these steps, the password has been updated.
438
802.1x Authentication
Updating VLAN Attributes. You can add a destination VLAN, change the destination VLAN, or remove
the destination VLAN from an existing local netlogin account. To make any of these VLAN updates, use
the following command:
configure netlogin local-user <user-name> {vlan-vsa [[{tagged | untagged}
[<vlan_name>] | <vlan_tag>]] | none]}
noneSpecifies that the VSA 211 wildcard (*) is applied, only if you do not specify tagged or
untagged
802.1x Authentication
802.1x authentication methods govern interactions between the supplicant (client) and the
authentication server. The most commonly used methods are Transport Layer Security (TLS); Tunneled
TLS (TTLS), which is a Funk/Certicom standards proposal; and PEAP.
TLS is the most secure of the currently available protocols, although TTLS is advertised to be as strong
as TLS. Both TLS and TTLS are certificate-based and require a Public Key Infrastructure (PKI) that can
issue, renew, and revoke certificates. TTLS is easier to deploy, as it requires only server certificates, by
contrast with TLS, which requires client and server certificates. With TTLS, the client can use the MD5
mode of user name/password authentication.
If you plan to use 802.1x authentication, refer to the documentation for your particular RADIUS server,
and 802.1x client on how to set up a PKI configuration.
This section describes the following topics:
439
Network Login
Interoperability Requirements
For network login to operate, the user (supplicant) software and the authentication server must support
common authentication methods. Not all combinations provide the appropriate functionality.
Supplicant Side
The supported 802.1x clients (supplicants) are Windows 2000 SP4 native client, Windows XP native
clients, and Meetinghouse AEGIS.
A Windows XP 802.1x supplicant can be authenticated as a computer or as a user. Computer
authentication requires a certificate installed in the computer certificate store, and user authentication
requires a certificate installed in the individual user's certificate store.
By default, the Windows XP machine performs computer authentication as soon as the computer is
powered on, or at link-up when no user is logged into the machine. User authentication is performed at
link-up when the user is logged in.
Windows XP also supports guest authentication, but this is disabled by default. Refer to relevant
Microsoft documentation for further information. The Windows XP machine can be configured to
perform computer authentication at link-up even if user is logged in.
Need to support VSAs. Parameters such as Extreme-Netlogin-Vlan-Name (destination vlan for port
movement after authentication) and Extreme-NetLogin-Only (authorization for network login only)
are brought back as VSAs.
Need to support both EAP and traditional user name-password authentication. These are used by
network login and switch console login respectively.
NOTE
For information on how to use and configure your RADIUS server, refer to the documentation that came with your
RADIUS server.
Any combination of types of authentication can be enabled on the same switch. At least one of the
authentication types must be specified on the CLI.
440
802.1x Authentication
To disable 802.1x network login on the switch, use the following command:
disable netlogin dot1x
To enable 802.1x network login on one or more ports, use the following command:
enable netlogin ports <portlist> dot1x
Network Login must be disabled on a port before you can delete a VLAN that contains that port. To
disable 802.1x network login on one or more ports, use the following command:
disable netlogin ports <portlist> dot1x
The following example is for the FreeRADIUS server; the configuration might be different for your
RADIUS server:
#RADIUS Server Setting, in this example the user name is eaptest
eaptest Auth-Type := EAP, User-Password == "eaptest"
Session-Timeout = 120,
Termination-Action =1
441
Network Login
NOTE
For information about how to use and configure your RADIUS server, refer to the documentation that came with your
RADIUS server.
NOTE
The supplicant does not move to a guest VLAN if it fails authentication after an 802.1x exchange; the supplicant
moves to the guest VLAN only if it does not respond to an 802.1x authentication request.
Suppose you have a meeting that includes company employees and visitors from outside the company.
In this scenario, your employees have 802.1x enabled supplicants (clients) but your visitors do not. By
configuring a guest VLAN, when your employees log into the network, they are granted network access
(based on their user credentials and 802.1x enabled clients). However, when the visitors attempt to log
into the network, they are granted limited network access because they do not have 802.1x enabled
clients. The visitors might be able to reach the Internet, but they are unable to access your network.
By default, the switch uses the supplicant response timer and attempts to authenticate the supplicant
every 30 seconds for a maximum of three tries. If the supplicant does not respond to the authentication
requests, the supplicant moves to the guest VLAN. The number of authentication attempts is not a userconfigured parameter.
The port moves out of the guest VLAN if, during subsequent authentications, the port is successfully
authenticated and the RADIUS server indicates a different VLAN to move to.
This section describes the following topics:
442
802.1x Authentication
NOTE
You configure only one guest VLAN per virtual router (VR).
The default supplicant response timeout is 30 seconds. The number of authentication attempts is not a
user-configured parameter.
443
Network Login
Web-Based Authentication
This section describes web-based network login. For web-based authentication, you need to configure
the switch DNS name, default redirect page, session refresh, and logout-privilege. URL redirection
requires the switch to be assigned a DNS name. The default name is network-access.net. Any DNS
query coming to the switch to resolve switch DNS name in unauthenticated mode is resolved by the
DNS server on the switch in terms of the interface (to which the network login port is connected to)
IP address.
This section describes the following topics:
Any combination of types of authentication can be enabled on the same switch. At least one of the
authentication types must be specified on the CLI.
To disable web-based network login on the switch, use the following command:
disable netlogin web-based
To enable web-based network login on one or more ports, use the following command:
enable netlogin ports <portlist> web-based
Network Login must be disabled on a port before you can delete a VLAN that contains that port. To
disable web-based network login on one or more ports, use the following command:
disable netlogin ports <portlist> dot1x
Where <url> is the DNS name of the switch. For example, configure netlogin base-url networkaccess.net makes the switch send DNS responses back to the netlogin clients when a DNS query is
made for network-access.net.
444
Web-Based Authentication
Where <url> defines the redirection information for the users after they have logged in. You must
configure a complete URL starting with http:// or https://
By default, the redirect URL value is http://www.extremenetworks.com.
This redirection information is used only in case the redirection info is missing from RADIUS server.
For example, configure netlogin base-url http://www.extremenetworks.com redirects all users
to this URL after they get logged in.
To support https, you must first download and install the separate Extreme Networks SSH software
module (ssh.xmod). This additional module allows you to configure both SSH2 and SSL on the switch.
For more information about SSH2, see Chapter 17, Security. For information about installing the SSH
module, see Appendix A, Software Upgrade and Boot Options.
Where <minutes> ranges from 1 - 255. The default setting is 3 minutes. enable netlogin sessionrefresh makes the logout window refresh itself at every configured time interval. Session -refresh
is disabled by default. When you configure the network login session refresh for the logout window,
ensure that the FDB aging timer is greater than the network login session refresh timer.
These commands turn the privilege for netlogin users to logout by popping up (or not popping up) the
logout window. Logout-privilege is enabled by default.
ISP ModeNetwork login clients connected to ports 1:10 - 1:14, VLAN corp, will be logged into the
network in ISP mode. This is controlled by the fact that the VLAN in which they reside in
445
Network Login
unauthenticated mode and the RADIUS server Vendor Specific Attributes (VSA), ExtremeNetlogin-Vlan, are the same, corp. So there will be no port movement. Also if this VSA is missing
from RADIUS server, it is assumed to be ISP Mode.
Campus ModeOn the other hand, clients connected to ports 4:1 - 4:4, VLAN temp, will be logged
into the network in Campus mode since the port will move to the VLAN corp after getting
authenticated. A port moves back and forth from one VLAN to the other as its authentication state
changes.
Both ISP and Campus mode are not tied to ports but to a user profile. In other words, if the VSA
Extreme:Extreme-Netlogin-Vlan represents a VLAN different from the one in which the user
currently resides, then VLAN movement will occur after login and after logout. In following example, it
is assumed that campus users are connected to ports 4:1-4:4, while ISP users are logged in through ports
1:10-1:14.
NOTE
In the following sample configuration, any lines marked (Default) represent default settings and do not need to
be explicitly configured.
create vlan temp
create vlan corp
configure vlan default delete ports 4:1-4:4
enable ipforwarding
# Configuration Information for VLAN temp
# No VLAN-ID is associated with VLAN temp.
configure vlan temp ipaddress 198.162.32.10 255.255.255.0
# Configuration Information for VLAN corp
# No VLAN-ID is associated with VLAN corp.
configure vlan corp ipaddress 10.203.0.224 255.255.255.0
configure vlan corp add port 1:10 untagged
configure vlan corp add port 1:11 untagged
configure vlan corp add port 1:12 untagged
configure vlan corp add port 1:13 untagged
configure vlan corp add port 1:14 untagged
# Network Login Configuration
configure vlan temp dhcp-address-range 198.162.32.20 - 198.162.32.80
configure vlan temp dhcp-options default-gateway 198.162.32.1
configure vlan temp dhcp-options dns-server 10.0.1.1
configure vlan temp dhcp-options wins-server 10.0.1.85
configure netlogin vlan temp
enable netlogin web-based
enable netlogin ports 1:10-1:14,4:1-4:4 web-based
configure netlogin base-url "network-access.net" (Default)
configure netlogin redirect-page http://www.extremenetworks.com (Default)
enable netlogin logout-privilege (Default)
disable netlogin session-refresh 3 (Default)
# DNS Client Configuration
configure dns-client add name-server 10.0.1.1
configure dns-client add name-server 10.0.1.85
446
Web-Based Authentication
#RADIUS Configuration
configure radius netlogin primary server 10.0.1.2 1812 client-ip 10.10.20.30 vr VrMgmt
configure radius netlogin primary shared-secret purple
enable radius
The following example is for the FreeRADIUS server; the configuration might be different for your
RADIUS server:
#RADIUS Server Setting (VSAs)(optional)
Extreme:Extreme-Netlogin-Only = Enabled (if no CLI authorization)
Extreme:Extreme-Netlogin-Vlan = "corp" (destination vlan for CAMPUS mode network
login)
NOTE
For information about how to use and configure your RADIUS server, refer to the documentation that came with your
RADIUS server.
Windows 9xUse the winipcfg tool. Choose the Ethernet adapter that is connected to the port
on which network login is enabled. Use the buttons to release the IP configuration and renew the
DHCP lease.
Windows NT/2000/XPUse the ipconfig command line utility. Use the command ipconfig/
release to release the IP configuration and ipconfig/renew to get the temporary IP address
from the switch. If you have more than one Ethernet adapter, specify the adapter by using a
number for the adapter following the ipconfig command. You can find the adapter number using
the command ipconfig/all.
NOTE
The idea of explicit release/renew is required to bring the network login client machine in the same subnet as
the connected VLAN. When using we-based authentication, this requirement is mandatory after every logout and
before login again as the port moves back and forth between the temporary and permanent VLANs.
At this point, the client will have its temporary IP address. In this example, the client should have
obtained the an IP address in the range 198.162.32.20 - 198.162.32.80.
5 Bring up the browser and enter any URL as http://www.123.net or http://1.2.3.4 or switch IP
address as http://<IP address>/login (where IP address could be either temporary or Permanent
VLAN Interface for Campus Mode). URL redirection redirects any URL and IP address to the
network login page. This is significant where security matters most, as no knowledge of VLAN
interfaces is required to be provided to network login users, as they can login using a URL or IP
address.
447
Network Login
NOTE
URL redirection requires that the switch is configured with a DNS client.
After successful authentication, the connection information configured on the RADIUS server is
returned to the switch:
After a successful login has been achieved, there are several ways that a port can return to a nonauthenticated, non-forwarding state:
The user successfully logs out using the logout web browser window.
Because network login is sensitive to state changes during the authentication process, Extreme Networks
recommends that you do not log out until the login process is complete. The login process is complete when you
receive a permanent address.
MAC-Based Authentication
MAC-based authentication is used for supplicants that do not support a network login mode, or
supplicants that are not aware of the existence of such security measure, for example an IP phone.
If a MAC address is detected on a MAC-Based enabled netlogin port, an authentication request will be
sent once to the AAA application. AAA tries to authenticate the MAC address against the configured
radius server and its configured parameters (timeout, retries, and so on) or the local database.
448
MAC-Based Authentication
The credentials used for this are the supplicants MAC address in ASCII representation, and a locally
configured password on the switch. If no password is configured, the MAC address is used as the
password. You can also group MAC addresses together using a mask.
You can configure a MAC list or a table of MAC entries to filter and authenticate clients based on their
MAC addresses. If there a match is found in the table of MAC entries, authentication occurs. If no
match is found in the table of MAC entries, and a default entry exists, the default will be used to
authenticate the client. All entries in the list are automatically sorted in longest prefix order. All
passwords are stored and showed encrypted.
Beginning with ExtremeWare XOS 11.3, you can associate a MAC address with one or more ports. By
learning a MAC address, the port confirms the supplicant before sending an authorization request to
the RADIUS server. This additional step protects your network against unauthorized supplicants
because the port accepts only authorization requests from the MAC address learned on that port. The
port blocks all other requests that do not have a matching entry.
This section describes the following topics:
Any combination of types of authentication can be enabled on the same switch. At least one of the
authentication types must be specified on the CLI.
To disable MAC-based network login on the switch, use the following command:
disable netlogin mac
To enable MAC-based network login on one or more ports, use the following command:
enable netlogin ports <portlist> mac
Network Login must be disabled on a port before you can delete a VLAN that contains that port. To
disable MAC-based network login on one or more ports, use the following command:
disable netlogin ports <portlist> mac
449
Network Login
To associate a MAC address with one or more ports, specify the ports option when using the following
command:
configure netlogin add mac-list [<mac> {<mask>} | default] {encrypted} {<password>}
{ports <port_list>}
You must enable MAC-based netlogin on the switch and the specified ports. If MAC-based netlogin is
not enabled on the specified port(s), the switch displays a warning message similar to the following:
WARNING: Not all specified ports have MAC-Based NetLogin enabled.
For a sample configuration, see Secure MAC Configuration Example on page 451.
To remove a MAC address from the table, use the following command:
configure netlogin delete mac-list [<mac> {<mask>} | default]
When a client needs authentication the best match will be used to authenticate to the server.
MAC-based authentication is VR aware, so there is one MAC list per VR.
Assume we have a supplicant with MAC address 00:04:96:05:40:00, and the switch has the following
table:
MAC Address/Mask
-------------------00:00:00:00:00:10/48
00:00:00:00:00:11/48
00:00:00:00:00:12/48
00:01:30:70:0C:00/48
00:01:30:32:7D:00/48
00:04:96:00:00:00/24
Password (encrypted)
---------------------<not configured>
<not configured>
<not configured>
yaqu
ravdqsr
<not configured>
Port(s)
-------------1:1-1:5
1:6-1:10
any
any
any
any
The user name used to authenticate against the Radius server would be 000496000000, as this is the
supplicants MAC address with the configured mask applied.
Note that the commands are VR aware, and therefore one MAC list table exists per VR.
450
MAC-Based Authentication
Specify one or more ports to accept authentication requests from a specific MAC address.
To view your network login configuration, use one of the following commands:
show netlogin {port <portlist> vlan <vlan_name>} {dot1x {detail}} {mac} {webbased}
451
Network Login
The following example is for the FreeRADIUS server; the configuration might be different for your
RADIUS server:
#RADIUS Server Setting
00E018A8C540 Auth-Type := Local,
User-Password == "00E018A8C540"
NOTE
For information about how to use and configure your RADIUS server, refer to the documentation that came with your
RADIUS server.
452
You must configure and enable netlogin on the switch and before you configure netlogin MAC-based
VLANs.
If you attempt to configure the ports mode of operation before enabling netlogin, the switch
displays an error message similar to the following:
ERROR: The following ports do not have NetLogin enabled; 1
10 Gigabit Ethernet ports such as those on the 10G4X I/O module and the uplink ports on the
Summit X450 switch do not support netlogin MAC-based VLANs.
If you attempt to configure netlogin MAC-based VLANs on 10 Gigabit Ethernet ports, the switch
displays an error message similar to the following:
ERROR: The following ports do not support the MAC-Based VLAN mode; 1, 2, 10
You can have a maximum of 1,024 MAC addresses per I/O module or per Summit X450 switch.
By default, the netlogin ports mode of operation is port-based-vlans. If you modify the mode of
operation to mac-based-vlans and later disable all netlogin protocols on that port, the mode of
operation automatically returns to port-based-vlans.
When you change the netlogin ports mode of operation, the switch deletes all currently known
supplicants from the port and restores all VLANs associated with that port to their original state. In
addition, by selecting mac-based-vlans, you are unable to manually add or delete untagged VLANs
from this port. Netlogin now controls these VLANs.
With netlogin MAC-based operation, every authenticated client has an additional FDB flag that
indicates a translation MAC address. If the supplicants requested VLAN does not exist on the port, the
switch adds the requested VLAN.
By specifying netlogin, you see only FDB entries related to netlogin or netlogin MAC-based VLANs.
The flags associated with netlogin include:
vIndicates the FDB entry was added because the port is part of a MAC-Based virtual port/VLAN
combination
453
Network Login
VLAN and Port Information. To view the VLANs that netlogin adds temporarily in MAC-based mode, use
the following command:
show ports <port_list> information detail
By specifying information and detail, the output displays the temporarily added VLANs in netlogin
MAC-based mode. To confirm this, review the following output of this command:
Netlogin port modeThis output was added to display the port mode of operation. Mac based
appears and the network login port mode of operation.
To view information about the ports that are temporarily added in MAC-based mode for netlogin, due
to discovered MAC addresses, use the following command:
show vlan detail
By specifying detail, the output displays detailed information including the ports associated with the
VLAN. The flags associated with netlogin include:
Expanding upon the previous example, you can also utilize the local database for authentication rather
than the RADIUS server:
create netlogin local-user 000000000012 vlan-vsa untagged default
create netlogin local-user 000000000010 vlan-vsa untagged users12
For more information about local database authentication, see Configuring Local Database
Authentication on page 435.
454
19 CLEAR-Flow
This chapter describes the following topics:
Overview
CLEAR-Flow is a broad framework for implementing security, monitoring, and anomaly detection in
ExtremeWare XOS software. Instead of simply looking at the source and destination of traffic,
CLEAR-Flow allows you to specify certain types of traffic that require more attention. After certain
criteria for this traffic are met, the switch can either take an immediate, predetermined action, or send a
copy of the traffic off-switch for analysis.
CLEAR-Flow is an extension to Access Control Lists (ACLs). You create ACL policy rules to count
packets of interest. CLEAR-Flow rules are added to the policy to monitor these ACL counter statistics.
The CLEAR-Flow agent monitors the counters for the situations of interest to you and your network.
You can monitor the cumulative value of a counter, the change to a counter over a sampling interval,
the ratio of two counters, or even the ratio of the changes of two counters over an interval. For example,
you can monitor the ratio between TCP SYN and TCP packets. An abnormally large ratio may indicate
a SYN attack.
The counters used in CLEAR-Flow are either defined by you in an ACL entry, or can be a predefined
counter. See Predefined CLEAR-Flow Counters on page 467 for a list and description of these
counters.
If the rule conditions are met, the CLEAR-Flow actions configured in the rule are executed. The switch
can respond by modifying an ACL that will block, prioritize, or mirror the traffic, executing a set of CLI
commands, or sending a report using a SNMP trap or EMS log message.
NOTE
CLEAR-Flow is available only on the BlackDiamond 10K family and BlackDiamond 12804 switches.
Configuring CLEAR-Flow
CLEAR-Flow is an extension to ACLs, so you must be familiar with configuring ACLs before you add
CLEAR-Flow rules to your ACL policies. Creating ACLs is described in detail in Chapter 14, Access
Lists (ACLs). Chapter 14 describes how to create ACL policies, the syntax of an ACL policy file, and
how to apply ACL policies to the switch. In this current chapter, you will find information about the
CLEAR-Flow rules that you add to ACL policies, including the CLEAR-Flow rules syntax and behavior.
455
CLEAR-Flow
After creating the ACLs that contain CLEAR-Flow rules, and after applying the ACLs to the appropriate
interface, you will enable CLEAR-Flow on the switch. When CLEAR-Flow is enabled, the rules will be
evaluated by the CLEAR-Flow agent on the switch, and if any rules are triggered, the CLEAR-Flow
actions are executed.
To enable CLEAR-Flow, use the following command:
enable clear-flow
When you disable the CLEAR-Flow agent on the switch, CLEAR-Flow sampling stops, and all rules are
left in the current state. To disable CLEAR-Flow, use the following command:
disable clear-flow
NOTE
Any actions triggered while CLEAR-Flow is enabled will continue when CLEAR-Flow is disabled, unless explicitly
stopped.
To display the CLEAR-Flow rules and configuration, use the following command:
show clear-flow [port <port> | vlan <vlanname> | any] {rule <rulename>} {detail}
When CLEAR-Flow is enabled, any rules that satisfy the threshold will trigger and take action. To
display the CLEAR-Flow rules that have been triggered, use the following command:
show clear-flow rule-triggered
To display which ACLs have been modified by CLEAR-Flow rules, use the following command:
show clear-flow acl-modified
456
In the CLEAR-Flow rule syntax, the <CLFrulename> is the name of the rule (maximum of 31
characters). The <match-type> specifies whether the rule is triggered when any of the expressions that
make up the conditions are true (logical OR), or only when all of the expressions are true (logical AND).
The <match-type> is an optional element. The <match-conditions> specifies the conditions that will
trigger the rule, and how often to evaluate the rule. The <actions> in the then clause is the list of
actions to take when the rule is triggered, and the optional else clause <actions> is the list of actions to
take after the rule is triggered, and when the <match-conditions> later become false.
NOTE
When you create an ACL policy file that contains CLEAR-Flow rules, the CLEAR-Flow rules do not have any
precedence, unlike the ACL entries. Each CLEAR-Flow rule specifies how often it should be evaluated. The order of
evaluation depends on the sampling time and when the CLEAR-Flow agent receives the counter statistics. The order
of the CLEAR-Flow rules in the policy file does not have any significance.
The rule match type, rule match conditions, and rule actions are discussed in these sections:
match allAll the match expressions must be true for a match to occur. This is the default.
457
CLEAR-Flow
NOTE
The match type was first available for CLEAR-Flow in ExtremeWare XOS 11.2.
In the following example, the CLEAR-Flow rule cflow_count_rule_example will be evaluated every ten
seconds. The actions statements will be triggered if the value of counter1 (defined earlier in the ACL
policy file) is greater than 1,000,000:
entry cflow_count_rule_example {
if { count counter1 > 1000000 ;
period 10 ;
}
then {
<actions>;
}
}
The global-rule statement is optional and affects how the counters are treated. An ACL that defines
counters can be applied to more than one interface. In the original release of CLEAR-Flow, however, any
counters used in an expression were only evaluated for that particular interface that the CLEAR-Flow
rule was applied to. Beginning with the ExtremeWare XOS 11.2 release, you can specify the global-rule
statement so that counters are evaluated for all the applied interfaces. For example, if a policy that
defines a counter is applied to port 1:1 and 2:1, a CLEAR-Flow rule that used the global-rule statement
would sum up the counts from both ports. Without the global-rule statement, the CLEAR-Flow rule
would only look at the counts received on one port at a time.
The period <interval> statement is optional and sets the sampling interval, in seconds. This
statement specifies how often the rule is evaluated by the CLEAR-Flow agent. If not specified, the
default value is 5 seconds.
458
NOTE
In ExtremeWare XOS 11.1 only one expression was allowed per CLEAR-Flow rule.
The five CLEAR-Flow rule expressions are: count, delta, ratio, delta-ratio, and rule. All of these
expressions check the values of counters to evaluate if an action should be taken. The counters are
either defined in the ACL entries that are defined on the switch, or are the predefined CLEAR-Flow
counters. When you use a counter statement in an ACL, you are defining the counter used by CLEARFlow to monitor your system.
The following sections discuss the CLEAR-Flow rule expressions in detail:
Count Expression
A CLEAR-Flow count expression compares a counter with the threshold value. The following is the
syntax for a CLEAR-Flow count expression:
count <counterName> REL_OPER <countThreshold> ;
hysteresis <hysteresis> ;
Beginning in ExtremeWare XOS release 11.4, the value of <countThreshold> and <hysteresis> can be
specified as floating point numbers. The count statement specifies how to compare a counter with its
threshold. The <counterName> is the name of an ACL counter referred to by an ACL rule entry and the
<countThreshold> is the value compared with the counter. The REL_OPER is selected from the relational
operators for greater than, great than or equal to, less than, or less than or equal to (>, >=, <, <=).
The hysteresis <hysteresis> statement is optional, and sets a hysteresis value for the threshold.
After the count statement is true, the value of the threshold is adjusted so that a change smaller than
the hysteresis value will not cause the statement to become false. For statements using the REL_OPER >
or >=, the hysteresis value is subtracted from the threshold; for < or <=, the hysteresis value is added to
the threshold.
Here is an example of a count expression used in a CLEAR-Flow rule:
entry cflow_count_rule_example {
if { count counter1 > 1000000 ;
period 10 ;
}
then {
<actions>;
}
}
The actions will be discussed in the section, CLEAR-Flow Rule Actions on page 464.
459
CLEAR-Flow
In Table 57 is an example of evaluating the CLEAR-Flow count expression above multiple times. Notice
that the rule is not triggered until evaluation 3, when the value of the counter is greater than 1,000,000.
counter1 value
Rule triggered?
384625
No
769250
No
1153875
Yes
1538500
Yes
See Count Expression Example on page 469 for a full example of an ACL and a CLEAR-Flow rule
using a count expression.
Delta Expression
A CLEAR-Flow delta expression computes the difference from one sample to the next of a counter
value. This difference is compared with the threshold value. The following is the syntax for a CLEARFlow delta expression:
delta <counterName> REL_OPER <countThreshold> ;
hysteresis <hysteresis> ;
Beginning in ExtremeWare XOS release 11.4, the value of <countThreshold> and <hysteresis> can be
specified as floating point numbers. The delta expression specifies how to compare the difference in a
counter value from one sample to the next with its threshold. The <counterName> is the name of an
ACL counter referred to by an ACL rule entry and the <countThreshold> is the value compared with
the difference in the counter from one sample to the next. The REL_OPER is selected from the relational
operators for greater than, great than or equal to, less than, or less than or equal to (>, >=, <, <=).
The hysteresis <hysteresis> statement is optional, and sets a hysteresis value for the threshold.
After the delta statement is true, the value of the threshold is adjusted so that a change smaller than
the hysteresis value will not cause the statement to become false. For statements using the REL_OPER >
or >=, the hysteresis value is subtracted from the threshold; for < or <=, the hysteresis value is added to
the threshold.
For example, the following delta expression:
delta counter1 >= 100 ;
hysteresis 10 ;
will only be true after the delta of the counter reaches at least 100. At the time it becomes true, the
hysteresis value is subtracted from the threshold (setting the threshold to 90). With the threshold now at
90, the condition would stay true until the delta of the counter becomes less than 90.
If the expression becomes false, the threshold is reset to its original value. You would use the hysteresis
value to prevent the expression from vacillating between the true and false states if the difference
between the counter values is near the threshold. If the hysteresis value is greater than the threshold
value, the hysteresis value will be set to 0.
460
counter1 value
Delta value
Rule triggered?
397
N/A
No
467
70
No
547
80
No
657
110
Yes
757
100
Yes
852
95
Yes
932
80
No
1031
99
No
1131
100
Yes
10
1230
99
Yes
See Delta Expression Example on page 470 for a full example of an ACL and a CLEAR-Flow rule
using a delta expression.
Ratio Expression
A CLEAR-Flow ratio expression compares the ratio of two counter values with the threshold value. The
following is the syntax for a CLEAR-Flow ratio expression:
ratio <counterNameA> <counterNameB> REL_OPER <countThreshold> ;
min-value <min-value> ;
hysteresis <hysteresis> ;
Beginning in ExtremeWare XOS release 11.4, the value of <countThreshold> and <hysteresis> can be
specified as floating point numbers, and the ratio is computed as a floating point number. The ratio
statement specifies how to compare the ratio of two counters with its threshold. The value of
<counterNameA> is divided by the value of <counterNameB>, to compute the ratio. That ratio is
compared with the <countThreshold>. The REL_OPER is selected from the relational operators for
greater than, great than or equal to, less than, or less than or equal to (>, >=, <, <=).
The min-value statement is optional, and sets a minimum value for the counters. If either counter is less
than the minimum value, the expression evaluates to false. If not specified, the minimum value is 1.
The hysteresis <hysteresis> statement is optional, and sets a hysteresis value for the threshold.
After the ratio statement is true, the value of the threshold is adjusted so that a change smaller than
the hysteresis value will not cause the statement to become false. For statements using the REL_OPER >
or >=, the hysteresis value is subtracted from the threshold; for < or <=, the hysteresis value is added to
the threshold.
461
CLEAR-Flow
For example, the following ratio expression:
ratio counter1 counter2 >= 5 ;
min-value 100;
hysteresis 1 ;
will only be true after the ratio of the counters reached at least 5 and the counter values are at least 100.
At the time it became true, the hysteresis value would be subtracted from the threshold (setting the
threshold to 4). With the threshold now at 4, the condition would stay true until the ratio of the
counters became less than 4.
If the statement becomes false, the threshold is reset to its original value. You would use the hysteresis
value to prevent the rule from vacillating between the true and false states if the ratio between the
counter values is near the threshold. If the hysteresis value is greater than the threshold value, the
hysteresis value will be set to 0.
In Table 59 is an example of evaluating the CLEAR-Flow ratio expression above multiple times. Notice
that the rule is not triggered at the first evaluation because both counters have not yet reached the minvalue of 100. The rule first triggers at evaluation 3, when ratio of the two counters exceeds 5. After the
rule is triggered, it remains triggered until the ratio value is less than 4 (the original threshold minus the
hysteresis), at evaluation 5. At evaluation 7, the rule is again triggered when the ratio reaches 5. The
rule will remain triggered until the ratio drops below 4.
counter1 value
counter2 value
ratio
Rule triggered?
427
70
No
941
235
No
2475
412
Yes
2308
570
Yes
2313
771
No
3597
899
No
5340
1065
Yes
See Ratio Expression Example on page 471 for a full example of an ACL and a CLEAR-Flow rule
using a ratio expression.
Delta-Ratio Expression
A CLEAR-Flow delta-ratio expression is a combination of the delta and ratio expressions. The CLEARFlow agent computes the difference from one sample to the next for each of the two counters. The ratio
of the differences is then compared to the threshold value. The following is the syntax for a CLEARFlow delta-ratio expression (note the similarity to the delta expression):
delta-ratio <counterNameA> <counterNameB> REL_OPER <countThreshold> ;
min-value <min-value> ;
hysteresis <hysteresis> ;
Beginning in ExtremeWare XOS release 11.4, the value of <countThreshold> and <hysteresis> can be
specified as floating point numbers, and the delta-ratio is computed as a floating point number. The
delta-ratio statement specifies how to compare the ratio of the counter differences with its threshold.
The difference of the sample values of <counterNameA> is divided by the difference of the sample
values of <counterNameB>, to compute the ratio that is compared with the <countThreshold>. The
462
will only be true after the ratio of the deltas of the counters reached at least 5. At the time it became
true, the hysteresis value would be subtracted from the threshold (setting the threshold to 4). With the
threshold now at 4, the condition would stay true until the ratio of the deltas of the counters became
less than 4.
If the statement becomes false, the threshold is reset to its original value. You would use the hysteresis
value to prevent the rule from vacillating between the true and false states if the ratio of the deltas of
the counters is near the threshold. If the hysteresis value is greater than the threshold value, the
hysteresis value will be set to 0.
In Table 60 is an example of evaluating the CLEAR-Flow delta-ratio expression above multiple times.
Notice that the rule is not triggered at the second evaluation because both counters have not yet reached
the min-value of 100. The rule first triggers at evaluation 4, when ratio of the two counters exceeds 5.
After the rule is triggered, it remains triggered until the ratio value is less than 4 (the original threshold
minus the hysteresis), at evaluation 6. At evaluation 8, the rule is again triggered when the ratio reaches
5. The rule will remain triggered until the ratio drops below 4.
counter1
value
counter1
delta
counter2
value
counter2
delta
Ratio
Rule
triggered?
110
N/A
20
N/A
N/A
No
537
427
90
70
No
1478
941
325
235
No
3953
2475
737
412
Yes
6261
2308
1307
570
Yes
8574
2313
2078
771
No
12171
3597
2977
899
No
17511
5340
4042
1065
Yes
See Delta-Ratio Expression Example on page 472 for a full example of an ACL and a CLEAR-Flow
rule using a delta-ratio expression.
463
CLEAR-Flow
Rule-True-Count Expression
A CLEAR-Flow rule-true-count expression compares how many times a CLEAR-Flow rule is true with a
threshold value. One use is to combine multiple rules together into a complex rule. The following is the
syntax for a CLEAR-Flow rule-true-count expression:
rule-true-count <ruleName> REL_OPER <countThreshold> ;
The rule-true-count statement specifies how to compare how many times a CLEAR-Flow rule is true
with the expression threshold. The <ruleName> is the name of the CLEAR-Flow rule to monitor and the
<countThreshold> is the value compared with the number of times the rule is true. The REL_OPER is
selected from the relational operators for greater than, great than or equal to, less than, or less than or
equal to (>, >=, <, <=).
For example, the following delta-ratio expression:
rule-true-count cflow_count_rule_example >= 5 ;
will only be true after the CLEAR-Flow rule cflow_count_rule_example has been true at least five times. If
the rule cflow_count_rule_example becomes true and remains true, and the period for
cflow_count_rule_example is the default five seconds, the rule would have to be true for at least 20
seconds before the rule-true-count expression will become true. If the period of the rule
cflow_count_rule_example is 10 seconds, it will need to be true for at least 40 seconds before the ruletrue_count expression becomes true.
Permit/Deny
QoS Profile
Mirror
SNMP Trap
Syslog
CLI
Additionally, the SNMP trap, syslog, and CLI rule actions can use keyword substitution to make the
rule actions more flexible. The keyword substitutions are described at the end of the rule action
descriptions. See Keyword Substitution on page 466 for more information.
The following sections describe the different rule actions.
Permit/Deny
This action modifies an existing ACL rule to permit or block traffic that matches that rule.
To change an ACL to permit, use the following syntax:
permit <ACLRuleName>
464
QoS Profile
This action modifies an existing ACL rule to set the QoS profile for traffic that matches that rule.
To change the ACL to forward to QoS profile <QPx>, use the following syntax:
qosprofile <ACLRuleName> <QPx>
For example:
qosprofile acl_rule_1 QP3
Mirror
This action modifies an existing ACL rule to mirror traffic that matches that rule, or to stop mirroring
that traffic. The mirroring port must be enabled when mirroring on an ACL rule is turned on. This
could be configured earlier, or use the CLI action to execute CLI commands to configure mirroring at
the same time.
To change the ACL to mirror traffic, use the following syntax:
mirror [add|delete] <ACLRuleName>
SNMP Trap
This action sends an SNMP trap message to the trap server, with a configurable ID and message string,
when the rule is triggered.
The message is sent periodically with interval <period> seconds. If <period> is 0, or if this optional
parameter is not present, the message is sent only once when the rule is triggered. The interval must be
a multiple of the rule sampling/evaluation interval, or the value will be rounded down to a multiple of
the rule sampling/evaluation interval.
To send an SNMP trap, use the following syntax:
snmptrap <id> <message> <period>
Syslog
This action sends log messages to the ExtremeWare XOS EMS sever. The possible values for message
level are: DEBU, INFO, NOTI, WARN, ERRO, and CRIT.
The message is sent periodically with interval <period> seconds. If <period> is 0, or if this optional
parameter is not present, the message is sent only once when the rule is triggered. The interval must be
a multiple of the rule sampling/evaluation interval, or the value will be rounded down to a multiple of
the rule sampling/evaluation interval.
465
CLEAR-Flow
The messages are logged on both MSMs, so if the backup log is sent to the primary MSM, then the
primary MSM will have duplicate log messages.
To send a log message, use the following syntax:
syslog <message> <level> <period>
CLI
This action executes a CLI command. There is no authentication or checking the validity of each
command. If a command fails, the CLI will log a message in the EMS log.
To execute a CLI command, use the following syntax:
cli <cliCommand>
Keyword Substitution
To make the SNMP trap, syslog, and CLI actions more flexible, keyword substitutions are supported in
the syslog and SNMP trap message strings, as well as in the CLI command strings. Table 61 lists the
keywords and their substitutions.
If a keyword is not supported, or a counter name is not found, a string of
unknownKeyword[$keyword] will be substituted.
For the $vlanName and $port keyword, the keyword all will be substituted for those rules in the
wildcard ACL Some CLI commands do not support the all keyword, so caution must be used with CLI
commands that use this feature.
A maximum of 10 different counter substitutions can be used per rule, including counters used in
expressions. For example, if a rule uses four counters in its expressions, then we can use six more
different counters in keyword substitutions, for a total of 10.
466
Keyword
Substitution
$policyName
$ruleName
$<counterName>
$ruleValue
$ruleThreshold
$ruleInterval
$vlanName
$port
Descriptiona
sys_IpInReceives
The total number of input IP packets received from interfaces, including those
received in error.
sys_IpInHdrErrors
sys_IpInAddrErrors
sys_IpForwDatagrams
The number of input IP packets for which this entity was not their final IP
destination, as a result of which an attempt was made to find a route to forward
them to that final destination.
sys_IpInUnknownProtos
sys_IpInDiscards
sys_IpInDelivers
sys_IpOutRequests
sys_IpOutDiscards
sys_IpOutNoRoutes
sys_IpReasmTimeout
The maximum number of seconds which received fragments are held while they
are awaiting reassembly at this entity.
sys_IpReasmReqds
sys_IpReasmOKs
sys_IpReasmFails
sys_IpFragOKs
The number of IP packets that have been successfully fragmented at this entity.
467
CLEAR-Flow
468
Counter Name
Descriptiona
sys_IpFragFails
The number of IP packets that have been discarded because they needed to be
fragmented at this entity but could not be, for example, because their Don't
Fragment flag was set.
sys_IpFragCreates
sys_IcmpInMsgs
The total number of ICMP messages which the entity received. Note that this
counter includes all those counted by icmpInErrors.
sys_IcmpInErrors
The number of ICMP messages which the entity received but determined as
having ICMP-specific errors (bad ICMP checksums, bad length, etc.).
sys_IcmpInDestUnreachs
sys_IcmpInTimeExcds
sys_IcmpInParmProbs
sys_IcmpInSrcQuenchs
sys_IcmpInRedirects
sys_IcmpInEchos
sys_IcmpInEchoReps
sys_IcmpInTimestamps
sys_IcmpInTimestampReps
sys_IcmpInAddrMasks
sys_IcmpInAddrMaskReps
sys_IcmpOutMsgs
The total number of ICMP messages which this entity attempted to send. Note
that this counter includes all those counted by icmpOutErrors.
sys_IcmpOutErrors
The number of ICMP messages which this entity did not send due to problems
discovered within ICMP such as a lack of buffers. This value should not include
errors discovered outside the ICMP layer such as the inability of IP to route the
resultant datagram. In some implementations there may be no types of error
which contribute to this counter's value.
sys_IcmpOutDestUnreachs
sys_IcmpOutTimeExcds
sys_IcmpOutParmProbs
sys_IcmpOutSrcQuenchs
sys_IcmpOutRedirects
sys_IcmpOutEchos
sys_IcmpOutEchoReps
sys_IcmpOutTimestamps
sys_IcmpOutTimestampReps
sys_IcmpOutAddrMasks
sys_IcmpOutAddrMaskReps
sys_IcmpInProtoUnreachs
sys_IcmpInBadLen
Descriptiona
sys_IcmpInBadCode
The number of incoming ICMP packets with a bad code field value.
sys_IcmpInTooShort
sys_IcmpInBadChksum
sys_IcmpInRouterAdv
sys_IcmpOutProtoUnreachs
sys_IcmpOutRouterAdv
sys_IgmpInQueries
The number of Host Membership Query messages that have been received on
this interface.
sys_IgmpInReports
The number of Host Membership Report messages that have been received on
this interface for this group address.
sys_IgmpInLeaves
sys_IgmpInErrors
sys_IgmpOutQueries
The number of Host Membership Query messages that have been sent on this
interface
sys_IgmpOutReports
The number of Host Membership Report messages that have been sent on this
interface for this group address.
sys_IgmpOutLeaves
a. Most of these descriptions can be found in RFC 2011, SNMPv2 Management Information Base for the Internet Protocol using SMIv2.
b. The length of an ICMP packet depends on the type and code field.
469
CLEAR-Flow
} then {
count counter1;
}
}
entry cflow_count_rule_example {
if { count counter1 > 1000000 ;
period 10 ;
}
then {
snmptrap 123 "Traffic on acl_rule1 exceeds threshold";
deny acl_rule1;
}
}
470
entry cflow_ratio_rule_example {
if { ratio counter1 counter2 > 5 ;
period 2;
min-value 1000;
}
then {
syslog "Rule $ruleName threshold ratio $ruleValue exceeds limit
$ruleThreshold";
}
}
471
CLEAR-Flow
472
Licensing
You must have a Core or an Advanced Core license to configure and use all of the Ethernet Automatic
Protection Switching (EAPS) features described in this chapter.
The BlackDiamond 10K switch with an MSM-1 module or an MSM1-XL module ships with a Core or
Advanced Core license, respectively.
The BlackDiamond 12804 switch with an MSM-5 module or an MSM-5R module ships with a Core
license.
The BlackDiamond 8800 family of switches (formerly known as Aspen) and the Summit X450 switch
ship with an Advanced Edge license. To use the complete EAPS functionality, including running two or
more EAPS rings, having a switch belonging to multiple EAPS rings, or configuring shared-ports that
allow multiple EAPS domains to share a common link, you must have a Core software license.
A subset of EAPS, called EAPS Edgemode, is available with an Advanced Edge license. The following
features are available with EAPS Edgemode:
For more information about software licensing, including how to obtain and upgrade your license, see
Chapter 1, ExtremeWare XOS Overview.
475
Transit
node
Transit
node
Master
node
EW_070
One port of the master node is designated the master nodes primary port (P) to the ring; another port is
designated as the master nodes secondary port (S) to the ring. In normal operation, the master node
blocks the secondary port for all non-control traffic belonging to this EAPS domain, thereby avoiding a
loop in the ring, like STP. Layer 2 switching and learning mechanisms operate per existing standards on
this ring.
NOTE
Like the master node, each transit node is also configured with a primary port and a secondary port on the ring, but
the primary/secondary port distinction is ignored as long as the node is configured as a transit node.
476
S4
S3
S5
S2
S6
P
S
S1
Direction of
health-check
message
Secondary port
is logically blocked
Master
node
EW_071
If the ring is complete, the master node logically blocks all data traffic in the transmit and receive
directions on the secondary port to prevent a loop. If the master node detects a break in the ring, it
unblocks its secondary port and allows data traffic to be transmitted and received through it.
Fast Convergence
The Fast Convergence mode allows EAPS to converge more rapidly. In EAPS Fast Convergence mode,
the link filters on EAPS ring ports are turned off. In this case, an instant notification is sent to the EAPS
process if a ports state transitions from up to down or vice-versa.
You configure Fast Convergence for the entire switch, not by EAPS domain.
477
NOTE
The control VLAN is not blocked. Messages sent on the control VLAN must be allowed into the switch for the master
node to determine whether the ring is complete.
To avoid loops in the network, the control VLAN must be NOT be configured with an IP address, and ONLY ring
ports may be added to this VLAN.
Polling response
The rest of this section describes the fault detection methods and the applicable restoration options.
478
S4
S3
S5
S2
S6
S
S1
EW_072
Polling
The master node transmits a health check packet on the control VLAN at a user-configurable interval
(see Figure 26). If the ring is complete, the master node receives the health-check packet on its
secondary port (the control VLAN is not blocked on the secondary port). When the master node
receives the health-check packet, it resets its failtimer and continues normal operation.
479
Restoration Operations
The master node continues sending health check packets out its primary port even when the master
node is operating in the failed state. As long as there is a break in the ring, the fail period timer of the
master node continues to expire, and the master node remains in the failed state.
When the broken link is restored, the master receives its health check packet back on its secondary port
and again declares the ring to be complete. Again, the master node logically:
During the time between when the transit node detects that the link is operable again and when the
master node detects that the ring is complete, the secondary port on the master node is still open and
data could start traversing the transit node port that just came up.
To prevent the possibility of a such a temporary loop, when the transit node detects that its failed link is
up, it performs these steps:
1 For the port that just came up, put all the protected VLANs traversing that port into a temporary
blocked state.
2 Remember which port has been temporarily blocked.
3 Set the state to Preforwarding.
When the master node receives its health check packet back on its secondary port and detects that the
ring is again complete, it sends a message to all its associated transit nodes to flush their forwarding
databases.
When the transit nodes receive the message to flush their forwarding databases, they perform these
steps:
1 Flush their forwarding databases on the protected VLANs.
2 If the port state is set to Preforwarding, unblock all the previously blocked protected VLANs for the
port.
480
EAPS Data VLAN Spanning Two Rings Connected by One Switch on page 481
Figure 28: EAPS data VLAN spanning two rings interconnected by one switch
S4
S6
S7
S3
Ring 1
S2
S5
Ring 2
S
S
S1
Master
node
S 8 Master
node
S9
EW_073
481
S
EAPS 1
Transit EAPS 1
Transit EAPS 2
EAPS 1
EAPS 2
Transit EAPS 1
Transit EAPS 2
EAPS 2
Master EAPS 2
Transit EAPS 1
EX_100
So, a single ring might have two EAPS domains running on it. Each EAPS domain would have a
different EAPS master node. Each EAPS domain will protect its own set of protected VLANS.
In a spatial reuse configuration, do not add the same protected VLAN to both EAPS domains.
482
EX_105
For information about configuring common links and EAPS shared ports, see Configuring EAPS
Shared Ports on page 496.
483
Figure 31: Multiple EAPS domains sharing a common link with EAPS shared ports
S4
S6
S5
Controller
S3
S7
EAPS1
EAPS2
Common
link
link ID=1
S2
Partner
S1
S 10
Master
node
S8
S9
Master
node
EW_095
The switches on either end of the common link must be configured as controller and a partner. For
information about configuring common links, see Configuring EAPS Shared Ports on page 496.
NOTE
If the shared port is not configured and the common link goes down a superloop between the multiple EAPS
domains will occur.
NOTE
To take advantage of the Spatial Reuse technology in a shared-port environment in this software release, you can use
the existing solution of configuring EAPS plus STP.
484
NOTE
If you configure a VMAN on a switch running EAPS, make sure you configure the VMAN attributes on all of the
switches that participate in the EAPS domain. For more information about VMANs, see the section Tunneling
(VMANs) on page 272.
The name parameter is a character string of up to 32 characters that identifies the EAPS domain to be
created.
NOTE
If you use the same name across categories (for example, STPD and EAPS names), Extreme Networks recommends
that you specify the identifying keyword as well as the actual name. If you do not use the keyword, the system may
return an error message.
485
One node (or switch) on the ring must be configured as the master node for the specified domain; all
other nodes (or switches) on the ring are configured as transit nodes for the same domain.
Notify you that changing a master node to a transit node might cause a loop in the network. If you
have not assigned a new master node before changing the current master node to a transit node, you
might cause a loop in the network.
The following command example identifies this switch as a transit node for the EAPS domain named
eaps_1.
configure eaps eaps_1 mode transit
The switch displays the following warning message and prompts you to confirm this action:
WARNING: Make sure this specific EAPS domain has a Master node in the ring. If
you change this node from EAPS master to EAPS transit, you could cause a
loop in the network.
Are you sure you want to change mode to transit? (y/n)
486
NOTE
These commands apply only to the master node. If you configure the polling timers for a transit node, they will be
ignored. If you later reconfigure that transit node as the master node, the polling timer values will be used as the
current values.
Use the hellotime keyword and its associated seconds parameter to specify the amount of time the
master node waits between transmissions of health check packets on the control VLAN. The value for
seconds must be greater than 0 when you are configuring a master node. The default value is 1 second.
NOTE
Increasing the hellotime value keeps the processor from sending and processing too many health check packets.
Use the failtime keyword and seconds parameters to specify the amount of time the master node
waits before the failtimer expires.
The seconds parameter must be greater than the configured value for hellotime. The default value is 3
seconds.
To configure the action taken if there is a break in the ring, use the following command:
configure eaps <name> failtime expiry-action [open-secondary-port | send-alert]
You can configure the action taken when the failtimer expires by using the configure eaps failtime
expiry-action command. Use the send-alert parameter to send an alert when the failtimer expires.
Instead of going into a failed state, the master node remains in a Complete or Init state, maintains
the secondary port blocking, and writes a critical error message to syslog warning the user that there is
a fault in the ring. An SNMP trap is also sent.
Use the open-secondary-port parameter to open the secondary port when the failtimer expires.
NOTE
Increasing the failtime value provides more protection by waiting longer to receive a health check packet when the
network is congested.
487
The following command example adds port 1 of the module installed in slot 8 of the switch to the EAPS
domain eaps_1 as the primary port.
configure eaps eaps_1 primary port 8:1
Enter y to add the ports to the VLAN. Enter n or press [Return] to cancel this action.
If you see this message, either configure the VLAN as an EAPS protected VLAN by using the configure
eaps add protected vlan command or add ports that the EAPS domain does not use as primary or
secondary ring ports.
Extreme Networks recommends that you keep the loop protection warning messages enabled. If you
have considerable knowledge and experience with EAPS, you might find the EAPS loop protection
warning messages unnecessary. For more information see, Disabling EAPS Loop Protection Warning
Messages on page 492.
488
To configure the EAPS control VLAN for the domain, use the following command:
configure eaps <name> add control vlan <vlan_name>
NOTE
The control VLAN must NOT be configured with an IP address. In addition, only ring ports may be added to this
control VLAN. No other ports can be members of this VLAN. Failure to observe these restrictions can result in a loop
in the network.
NOTE
The ring ports of the control VLAN must be tagged.
By default, EAPS protocol data units (PDUs) are automatically assigned an 802.1p priority of seven.
With a priority of seven, EAPS PDUs take precedence within the EAPS topology thereby giving priority
to EAPS traffic, including EAPS control VLAN traffic and control VLAN messages. This ensures that the
control VLAN messages reach their intended destinations. You do not need to configure a QoS profile
for the control VLAN.
However, if you have a protected (data) VLAN with a QoS profile of QP8, you may need to create a
QoS profile of QP8 for the control VLAN. Whether you need to configure the control VLAN with a QoS
profile of QP8 depends entirely on your configuration.
NOTE
On the BlackDiamond 8800 family of switches and the Summit X450 switch, assigning a QoS profile to the control
VLAN affects the amount of available ACL masks. For more information see Conserving ACL Masks and Rules
BlackDiamond 8800 Family and Summit X450 Only on page 331.
The following command example adds the control VLAN keys to the EAPS domain eaps_1.
configure eaps eaps_1 add control vlan keys
489
NOTE
When you configure the VLAN that will act as a protected VLAN, the ring ports of the protected VLAN must be
tagged (except in the case of the default VLAN).
NOTE
As long as the ring is complete, the master node blocks the protected VLANs on its secondary port.
If the protected VLAN has a QoS profile of QP8, make sure the control VLAN has the appropriate QoS
profile setting. For more information, see the previous section Configuring the EAPS Control VLAN
on page 489.
The following command example adds the protected VLAN orchid to the EAPS domain eaps_1.
configure eaps eaps_1 add protected vlan orchid
To prevent loops in the network, the switch displays by default the following warning message and
prompts you to disable EAPS for the specified domain:
WARNING: Disabling specific EAPS domain could cause a loop in the network!
Are you sure you want to disable this specific EAPS domain? (y/n)
Extreme Networks recommends that you keep the loop protection warning messages enabled. If you
have considerable knowledge and experience with EAPS, you might find the EAPS loop protection
490
To disable the EAPS function for the entire switch, use the following command:
disable eaps
To prevent loops in the network, the switch displays by default the following warning message and
prompts you to disable EAPS for the entire switch:
WARNING: Disabling EAPS on the switch could cause a loop in the network!
Are you sure you want to disable EAPS? (y/n)
Extreme Networks recommends that you keep the loop protection warning messages enabled. If you
have considerable knowledge and experience with EAPS, you might find the EAPS loop protection
warning messages unnecessary. For more information see, Disabling EAPS Loop Protection Warning
Messages on page 492.
To prevent loops in the network, the switch displays by default a warning message and prompts you to
unconfigure the specified EAPS primary or secondary ring port. When prompted, do one of the
following:
The following command example unconfigures this nodes EAPS primary ring port on the domain
eaps_1:
unconfigure eaps eaps_1 primary port
491
Enter y to continue and unconfigure the EAPS primary ring port. Enter n to cancel this action.
The switch displays a similar warning message if you unconfigure the secondary EAPS port.
Extreme Networks recommends that you keep the loop protection warning messages enabled. If you
have considerable knowledge and experience with EAPS, you might find the EAPS loop protection
warning messages unnecessary. For more information see, Disabling EAPS Loop Protection Warning
Messages on page 492.
Extreme Networks recommends that you keep the loop protection warning messages enabled. If you
have considerable knowledge and experience with EAPS, you might find the EAPS loop protection
warning messages unnecessary. For example, if you use a script to configure your EAPS settings,
disabling the warning messages allows you to configure EAPS without replying to each interactive yes/
no question.
To disable loop protection messages, use the following command:
configure eaps config-warnings off
492
The following display shows sample output for the command show eaps <eapsDomain>:
Name: d1
State: Complete
Running: Yes
Enabled: Yes
Mode: Master
Primary port:
3:8
Port status: Up
Tag status: Tagged
Secondary port: 3:16
Port status: Blocked
Tag status: Tagged
Hello timer interval: 1 sec
Fail timer interval: 3 sec
Fail Timer expiry action: Send alert
Last update: From Master Id 00:01:30:f9:9c:b0, at Wed Jun 9 09:09:35 2004
EAPS Domain has following Controller Vlan:
Vlan Name
VID
c1
1000
EAPS Domain has following Protected Vlan(s):
Vlan Name
VID
p_1
1
p_2
2
p_3
3
p_4
4
p_5
5
p_6
6
p_7
7
p_8
8
p_9
9
p_10
10
p_11
11
p_12
12
p_13
13
p_14
14
p_15
15
p_16
16
p_17
17
p_18
18
p_19
19
p_20
20
p_21
21
p_22
22
p_23
23
p_24
24
p_25
25
p_26
26
p_27
27
p_28
28
p_29
29
p_30
30
493
NOTE
You may see a slightly different display, depending on whether you display the master node or the transit node.
The display from the show eaps detail command shows all the information shown in the show eaps
<eapsDomain> command, but displays information for all configured EAPS domains. Table 63 explains
the fields on the EAPS display.
Description
EAPS Enabled
494
Name
Description
State
[Running: ]
Enabled
Mode
The configured EAPS mode for this switch: transit (T) or master (M).
Primary/Secondary port
The port numbers assigned as the EAPS primary and secondary ports.
On the master node, the port distinction indicates which port is
blocked to avoid a loop.
Port status
495
Description
Tag status
The configured value of the timer in seconds, specifying the time that
the master node waits between transmissions of health check packets.
The configured value of the timer in seconds, specifying the time that
the master node waits before the failtimer expires.
The configured value of the timer. This value is set internally by the
EAPS software.
Last update
Indicates the last time a hello packet is received from the master
node.
Vlansb
a. This field applies only to master nodes; it does not display for a transit mode.
b. These fields apply only to transit nodes; they are not displayed for a master node.
When multiple EAPS rings share a physical link, this link is referred to as the common link. Each node
on either end of this common link should be configured with an EAPS shared port instance. You must
configure one node of the common link as the controller and the node on the other end as the partner.
Each common link in the EAPS network must have a unique link ID. The controller and partner shared
ports belonging to the same common link must have matching link IDs. These controller and partner
nodes with matching link IDs must be directly connected to each other. No other instance in the
network should have that link ID. During normal operation, both the controller and the partner send
segment health check messages on their EAPS domain every second.
In the situation described above, if there is no EAPS shared ports configuration, and the common link
fails, this might result in a superloop.
496
Steady State
In steady state when the common link is up, both the controller and partner are said to be in the
ready state. After EAPS has converged and the EAPS master node has blocked its own secondary
ports, the controller puts all its ports into forwarding, and goes back to ready state.
P3
P2
S1
Controller
EAPS1
S4
S9
P4
S6
EAPS3
P1
link ID=10
Common
link
EAPS2
S7
S10
P5
S2
P8
Partner
S5
P6
S8
Master
P7
Master
S11
Master
EX_104
EAPS1 is the EAPS domain for ring S1, S3, S4, S5, and S2
EAPS2 is the EAPS domain for ring S1, S6, S7, S8, and S2
EAPS3 is the EAPS domain for ring S1, S9, S10, S11, and S2
S5, S8, and S11 are the master nodes of their respective EAPS domains
S3, S4, S6, S7, S9, and S10 are the transit nodes of their respective EAPS domains
S1 is the controller
S2 is the partner
497
S3
P2
Active-Open
S1
Controller P4
P1
S4
EAPS1
S9
EAPS3
x
S2
Partner
S6
EAPS2
S8
Master
S5
Master
S10
S7
S11
Master
EW_102b
When the common link is restored, the controller goes into Preforwarding state. After the controller
receives notification from the master nodes that they have converged and blocked their secondary ports,
the controller opens all ports.
If you have an EAPS configuration with multiple common links and a second common link fails, the
controllers continue to take steps to prevent a superloop. In addition to having one controller with an
Active-Open port, the controller with the smallest link ID becomes the root blocker. There can be
only one root blocker in the network.
Port Considerations
In an EAPS shared port configuration, the segment ports are sorted in ascending order based on their
port number, not the order you add an EAPS domain to EAPS shared ports. This is particularly useful
when planning your EAPS configuration.
The benefit of sorting ports in ascending order is evident if a common link fails. The port with the
lowest port number among the segment ports in the UP state becomes the Active Open port. When
configuring your EAPS domain, keep the port numbers in mind. For high bandwidth links, utilize
lower port numbers, and for low bandwidth links, utilize higher port numbers. This way, if a common
link fails, the high bandwidth link is still available.
NOTE
The order you add EAPS domains to EAPS shared ports is relevant if the EAPS domains have matching ring ports
and participate in spatial reuse. In this case, the show eaps shared-port {<port>} {detail} command
displays the newly added EAPS domain after all other existing EAPS domains with the same matching ring port.
To display EAPS shared port status information, use the following command:
show eaps shared-port {<port>} {detail}
498
NOTE
A switch can have a maximum of two shared ports.
499
segment-downIf the controller or partner switchs segment timer expires, that segment is set to
down, and a query is not sent through the ring.
send-alertIf the controller or partner switchs segment timer expires, that switch keeps the
segment up, with the failed flag set, and sends a warning message to the log.
All segments, including the controller and partner shared ports belonging to the same common link,
must use the same segment timer expiry action. By default, the segment timer expiry action is send-alert
and the timer is set to 3 seconds.
If you enter the show eaps shared-port command without an argument or keyword, the command
displays a summary of status information for all configured EAPS shared ports.
If you specify an EAPS shared-port, the command displays information about that specific port.
Otherwise, the command displays information about all of the shared-ports configured on the switch.
You can use the detail keyword to display more detailed status information about the segments and
VLANs associated with each shared port.
The following examples of the show eaps shared-port command displays shared port information
when the EAPS domain is in a ready state (for example, when the common link is up).
EAPS shared-port count: 1
-------------------------------------------------------------------------------Link
Domain Vlan
RB
RB
Shared-port Mode
Id
Up State
count count Nbr State
Id
-------------------------------------------------------------------------------10:1
Controller 1
Y Ready
2
1
Yes None
None
500
Table 64 describes the significant fields and values in the display output of the show eaps sharedport {<port>} {detail} commands.
Description
Shared Port
Mode
Link ID
Up
State
Domain Count
VLAN Count
Indicates the total number of VLANs that are protected under the
EAPS domains sharing this common link.
Nbr
RB State
501
Description
RB ID
The ID of the root blocker. If the value is none, there are not two or
more common-link failures.
The segment port is the other ring port of an EAPS domain that is not
the shared-port.
502
The EAPS domain having the segment port as one of its ring ports.
The total number of VLANs being protected under this segment port.
Description
The controller and partner shared ports on either side of a common link must have the same
link ID.
Each common link in the network must have a unique link ID.
The modes on either side of a common link must be different from each other; one must be a
controller and one must be a partner.
1 controller
1 partner
2 partners
503
Basic Configuration
This example, shown in Figure 34, is the most basic configuration; two EAPS domains with a single
common link between them.
S4
S6
S5
Controller
S3
S7
EAPS1
EAPS2
link ID=1
S2
Partner
Common
link
S1
S8
S9
S 10
Master
node
Master
node
EW_095
S7
S4
P1:2
Controller EAPS3
EAPS2
P1:1
Common link
S 10
S1
Master
node
S 11
P
Master
node
Partner
Partner
S
link ID=1
S6
S2
S9
Controller
EAPS1
504
S 12
P1:3
S5
S3
Master
node
S8
Master
node
EAPS4
S 13
EW_096
S5
EAPS1
S6
S7
link ID=2
S 4 Controller
Common
link
EAPS2
Common
link
S3
S 10
Partner
Controller
EAPS4
link ID=1
Master
node
S9
EAPS3
P
P
Partner
S2
S1
Master
node
S8
S 11
EW_097
Master
node
S7
S4
S5
Common
link
EAPS1
Master
node
Common
link
EAPS5
link ID=3
Partner
Controller
S3
S8
link ID=1
S9
EAPS4
Controller
Partner
EAPS3
Common link ID=2
link
EAPS2
Controller
Master
node
S 13
S2
Partner
S 14
P
S
S1
S6
S 12
Master
node
S 10
P
S
S 11
S 15
P
Master
node
EW_098
505
S3
S2
S4
S
S
S5
EAPS3
Controller
Partner
S
Controller
EAPS5
EAPS4
link ID=30
Master
node
S6
Partner
Master
link ID=40
EAPS1
S1
P
link ID=50
S7
Controller
S 12
Partner
link ID=20
Controller
Partner
EAPS2
S 11
Master
node
S8
S9
P
506
S 10
Master
node
EW_099
Advanced Configuration
Figure 39 shows an extension of the Basic Core and Right Angle configuration.
S4
link ID=1
EAPS5
S5
Partner
Master
Controller
S2
link ID=2
Common
link
Controller
EAPS2
Common
link
EAPS1
S1
Partner
Master
link ID=4
Controller
S 14
S 13
S
EAPS3
Common
link
Common
link
Partner
link ID=3
S9
S6
Partner
Controller
EAPS6
S 12
S7
S8
EAPS4
S 11
S 10
EW_101
507
508
Using the Spanning Tree Protocol (STP) functionality of the switch makes your network more fault
tolerant. The following sections explain more about STP and the STP features supported by
ExtremeWare XOS.
NOTE
STP is a part of the 802.1D bridge specification defined by the IEEE Computer Society. To explain STP in terms
used by the IEEE 802.1D specification, the switch will be referred to as a bridge.
STP and Extreme Standby Router Protocol (ESRP) cannot be configured on the same Virtual LAN (VLAN)
simultaneously.
509
Within any given STPD, all VLANs belonging to it use the same spanning tree.
For more detailed information about configuring STP and STP parameters, see Configuring STP on the
Switch on page 546.
Member VLANs
When you add a VLAN to an STPD, that VLAN becomes a member of the STPD. The two types of
member VLANs in an STPD are:
Carrier
Protected
Carrier VLAN
A carrier VLAN defines the scope of the STPD, which includes the physical and logical ports that
belong to the STPD and if configured, the 802.1Q tag used to transport Extreme Multiple Instance
Spanning Tree Protocol (EMISTP) or Per VLAN Spanning Tree (PVST+) encapsulated bridge protocol
data units (BPDUs) (see Encapsulation Modes on page 512 for more information about encapsulating
STP BPDUs). Only one carrier VLAN can exist in a given STPD, although some of its ports can be
outside the control of any STPD at the same time.
If you configure EMISTP or PVST+, the StpdID must be identical to the VLANid of the carrier VLAN in
that STPD. See Specifying the Carrier VLAN on page 511 for an example.
If you have an 802.1D configuration, Extreme Networks recommends that you configure the StpdID to
be identical to the VLANid of the carrier VLAN in that STPD. See Basic 802.1D Configuration
Example on page 548 for an example.
If you configure Multiple Spanning Tree (MSTPIEEE 802.1Q-2003, formerly IEEE 802.1s) you do not
need carrier VLANs for MSTP operation. With MSTP, you configure a Common and Internal Spanning
Tree (CIST) that controls the connectivity of interconnecting MSTP regions and sends BPDUs across the
regions to communicate the status of MSTP regions. All VLANs participating in the MSTP region have
the same privileges. For more information about MSTP, see Multiple Spanning Tree Protocol on
page 535.
510
Protected VLAN
Protected VLANs are all other VLANs that are members of the STPD. These VLANs piggyback on the
carrier VLAN. Protected VLANs do not transmit or receive STP BPDUs, but they are affected by STP
state changes and inherit the state of the carrier VLAN. Protected VLANs can participate in multiple
STPDs, but any particular port in the VLAN can belong to only one STPD. Also known as non-carrier
VLANs.
If you configure MSTP, all member VLANs in an MSTP region are protected VLANs. These VLANs do
not transmit or receive STP BPDUs, but they are affected by STP state changes communicated by the
CIST to the MSTP regions. Multiple spanning tree instances (MSTIs) cannot share the same protected
VLAN; however, any port in a protected VLAN can belong to multiple MSTIs. For more information
about MSTP, see Multiple Spanning Tree Protocol on page 535.
Creates the same tag ID for the VLAN and the STPD (the carrier VLANs VLANid must be identical
to the STPDs StpdID).
create vlan v5
configure vlan
configure vlan
create stpd s8
configure stpd
configure stpd
enable stpd s8
v5 tag 100
v5 add ports 1:1-1:20 tagged
s8 add vlan v5 ports all emistp
s8 tag 100
Notice how the tag number for the VLAN v5 and the STPD s8 is identical (the tag is 100). By using
identical tags, you have selected the carrier VLAN. The carrier VLANs VLANid is identical to the
STPDs StpdID.
STPD Modes
An STPD has three modes of operation:
802.1D mode
Use this mode for backward compatibility with previous STP versions and for compatibility with
third-party switches using IEEE standard 802.1D. When configured in this mode, all rapid
configuration mechanisms are disabled.
802.1w mode
Use this mode for compatibility with Rapid Spanning Tree (RSTP). When configured in this mode,
all rapid configuration mechanisms are enabled. The benefit of this mode is available on point-topoint links only and when the peer is likewise configured in 802.1w mode. If you do not select
point-to-point links and the peer is not configured for 802.1w mode, the STPD fails back to 802.1D
mode.
You enable or disable RSTP on a per STPD basis only. You do not enable RSTP on a per port basis.
511
MSTP mode
Use this mode for compatibility with MSTP. MSTP is an extension of RSTP and offers the benefit of
better scaling with fast convergence. When configured in this mode, all rapid configuration
mechanisms are enabled. The benefit of MSTP is available only on point-to-point links and when
you configure the peer in MSTP or 802.1w mode. If you do not select point-to-point links and the
peer is not configured in 802.1w mode, the STPD fails back to 802.1D mode.
You must first configure a CIST before configuring any MSTIs in the region. You cannot delete or
disable a CIST if any of the MSTIs are active in the system.
You create only one MSTP region on the switch, and all switches that participate in the region must
have the same regional configurations. You enable or disable an MSTP on a per STPD basis only. You
do not enable MSTP on a per port basis.
If configured in MSTP mode, an STPD uses the 802.1D BPDU encapsulation mode by default. To
ensure correct operation of your MSTP STPDs, do not configure EMISTP or PVST+ encapsulation
mode for MSTP STPDs.
For more information about MSTP and MSTP features, see Multiple Spanning Tree Protocol on
page 535.
By default, the:
Encapsulation Modes
You can configure ports within an STPD to accept specific BPDU encapsulations. This STP port
encapsulation is separate from the STP mode of operation. For example, you can configure a port to
accept the PVST+ BPDU encapsulation while running in 802.1D mode.
An STP port has three possible encapsulation modes:
802.1D mode
Use this mode for backwards compatibility with previous STP versions and for compatibility with
third-party switches using IEEE standard 802.1D. BPDUs are sent untagged in 802.1D mode. Because
of this, any given physical interface can have only one STPD running in 802.1D mode.
This encapsulation mode supports the following STPD modes of operation: 802.1D, 802.1w, and
MSTP.
512
These encapsulation modes are for STP ports, not for physical ports. When a physical port belongs to
multiple STPDs, it is associated with multiple STP ports. It is possible for the physical port to run in
different modes for different domains to which it belongs.
If configured in MSTP mode, an STPD uses the 802.1D BPDU encapsulation mode by default. To ensure
correct operation of your MSTP STPDs, do not configure EMISTP or PVST+ encapsulation mode for
MSTP STPDs.
To configure the BPDU encapsulation mode for one or more STP ports, use the following command:
configure stpd <stpd_name> ports mode [dot1d | emistp | pvst-plus] <port_list>
To configure the default BPDU encapsulation mode on a per STPD basis, use the following command:
configure stpd <stpd_name> default-encapsulation [dot1d | emistp | pvst-plus]
Instead of accepting the default encapsulation modes of dot1d for the default STPD s0 and emistp for
all other STPDs, this command allows you to specify the type of BPDU encapsulation to use for all
ports added to the STPD (if not otherwise specified).
STPD Identifier
An StpdID is used to identify each STP domain. You assign the StpdID when configuring the domain,
and that carrier VLAN of that STPD cannot belong to another STPD. Unless all ports are running in
802.1D mode, an STPD with ports running in either EMISTP mode or PVST+ mode must be configured
with an StpdID.
An StpdID must be identical to the VLANid of the carrier VLAN in that STP domain. For an 802.1D
STPD, the VLANid can be either a user-defined ID or one automatically assigned by the switch.
NOTE
If an STPD contains at least one port not in 802.1D mode, you must configure the STPD with an StpdID.
MSTP uses two different methods to identify the STPDs that are part of the MSTP network. An instance
ID of 0 identifies the CIST. The switch assigns this ID automatically when you configure the CIST STPD.
An MSTI identifier (MSTI ID) identifies each STP domain that is part of an MSTP region. You assign the
MSTI ID when configuring the STPD that participates in the MSTP region. In an MSTP region, MSTI
IDs only have local significance. You can reuse MSTI IDs across MSTP regions. For more information
about MSTP and MSTP features, see Multiple Spanning Tree Protocol on page 535.
513
STP States
Each port that belongs to a member VLAN participating in STP exists in one of the following states:
Blocking
A port in the blocking state does not accept ingress traffic, perform traffic forwarding, or learn MAC
source addresses. The port receives STP BPDUs. During STP initialization, the switch always enters
the blocking state.
Listening
A port in the listening state does not accept ingress traffic, perform traffic forwarding, or learn MAC
source addresses. The port receives STP BPDUs. This is the first transitional state a port enters after
being in the blocking state. The bridge listens for BPDUs from neighboring bridge(s) to determine
whether the port should or should not be blocked.
Learning
A port in the learning state does not accept ingress traffic or perform traffic forwarding, but it begins
to learn MAC source addresses. The port also receives and processes STP BPDUs. This is the second
transitional state after listening. From learning, the port will change to either blocking or forwarding.
Forwarding
A port in the forwarding state accepts ingress traffic, learns new MAC source addresses, forwards
traffic, and receives and processes STP BPDUs.
Disabled
A port in the disabled state does not participate in STP; however, it will forward traffic and learn
new MAC source addresses.
Binding Ports
The two ways to bind (add) ports to an STPD are: manually and automatically. By default, ports are
manually added to an STPD.
NOTE
The default VLAN and STPD S0 are already on the switch.
configure stpd <stpd_name> add vlan <vlan_name> ports [all | <port_list>] {[dot1d
| emistp | pvst-plus]}
configure vlan <vlan_name> add ports [all | <port_list>] {tagged | untagged} stpd
<stpd_name> {[dot1d | emistp | pvst-plus]}
The first command adds all ports or a list of ports within the specified VLAN to an STPD. For EMISTP
and PVST+, the carrier VLAN must already exist on the same set of ports. The second command adds
all ports or a list of ports to the specified VLAN and STPD at the same time. If the ports are added to
the VLAN but not to the STPD, the ports remain in the VLAN.
For EMISTP and PVST+, if the specified VLAN is not the carrier VLAN and the specified ports are not
bound to the carrier VLAN, the system displays an error message. If you configure MSTP on your
switch, MSTP does not need carrier VLANs.
514
NOTE
The carrier VLANs VLANid must be identical to the StpdID of the STP domain.
If you add a protected VLAN or port, that addition inherits the carrier VLANs encapsulation mode
unless you specify the encapsulation mode when you execute the configure stpd add vlan or
configure vlan add ports stpd commands. If you specify an encapsulation mode (dot1d, emistp,
or pvst-plus), the STP port mode is changed to match; otherwise, the STP port inherits either the
carrier VLANs encapsulation mode on that port or the STPDs default encapsulation mode.
For MSTP, you do not need carrier a VLAN. A CIST controls the connectivity of interconnecting MSTP
regions and sends BPDUs across the regions to communicate region status. You must use the dot1d
encapsulation mode in an MSTP environment. For more information about MSTP, see the section
Multiple Spanning Tree Protocol on page 535.
To remove ports, use the following command:
configure stpd <stpd_name> delete vlan <vlan_name> ports [all | <port_list>]
If you manually delete a protected VLAN or port, only that VLAN or port is removed. If you manually
delete a carrier VLAN or port, all VLANs on that port (both carrier and protected) are deleted from that
STPD.
To learn more about member VLANs, see Member VLANs on page 510. For more detailed
information about these command line interface (CLI) commands, see the ExtremeWare XOS Command
Reference Guide.
The autobind feature is disabled on user-created STPDs. The autobind feature is enabled on the default
VLAN that participates in the default STPD S0.
For EMISTP or PVST+, when you issue this command, any port or list of ports that you add to the
carrier VLAN are automatically added to the STPD with autobind enabled. In addition, any port or list
of ports that you remove from a carrier VLAN are automatically removed from the STPD. This feature
allows the STPD to increase or decrease its span as ports are added to or removed from a carrier VLAN.
NOTE
The carrier VLANs VLANid must be identical to the StpdID of the STP domain.
Enabling autobind on a protected VLAN does not expand the boundary of the STPD. If the same set of
ports are members of the protected VLAN and the carrier VLAN, protected VLANs are aware of STP
state changes. For example, assume you have the following scenario:
515
Since v1 contains ports 3:1-3:2, v2 is aware only of the STP changes for ports 3:1 and 3:2, respectively.
Ports 3:3 and 3:4 are not part of the STPD, which is why v2 is not aware of any STP changes for those
ports.
In addition, enabling autobind on a protected VLAN causes ports to be automatically added or
removed as the carrier VLAN changes.
For MSTP, when you issue this command, any port or list of ports that gets automatically added to an
MSTI are automatically inherited by the CIST. In addition, any port or list of ports that you remove
from an MSTI protected VLAN are automatically removed from the CIST. For more information, see
Automatically Inheriting PortsMSTP Only.
To remove ports, use the following command:
configure stpd <stpd_name> delete vlan <vlan_name> ports [all | <port_list>]
If you manually delete a port from the STPD on a VLAN that has been added by autobind,
ExtremeWare XOS records the deletion so that the port does not get automatically added to the STPD
after a system restart.
To learn more about the member VLANs, see Member VLANs on page 510. For more detailed
information about these CLI commands, see the ExtremeWare XOS Command Reference Guide.
516
STP Configurations
To support hitless failover, the primary MSM replicates STP BPDUs to the backup, which allows the
MSMs to run STP in parallel. Although both MSMs receive STP BPDUs, only the primary transmits STP
BPDUs to neighboring switches and participates in STP.
To initiate hitless failover on a network that uses STP:
1 Confirm that the MSMs are synchronized and have identical software and switch configurations
using the show switch {detail} command. The output displays the status of the MSMs, with the
primary MSM showing MASTER and the backup MSM showing BACKUP (InSync).
If the MSMs are not synchronized, proceed to step 2.
If the MSMs are synchronized, proceed to step 3.
2 If the MSMs are not synchronized, replicate all saved images and configuration from the primary to
the backup using the synchronize command.
3 Initiate failover using the run msm-failover command.
For more detailed information about verifying the status of the MSMs and system redundancy, see
Understanding System Redundancy with Dual MSMs InstalledModular Switches Only on page 72.
For more information about hitless failover, see Understanding Hitless Failover SupportModular
Switches Only on page 76.
STP Configurations
When you assign VLANs to an STPD, pay careful attention to the STP configuration and its effect on
the forwarding of VLAN traffic.
This section describes three types of STP configurations:
Basic STP
517
Marketing is defined on all switches (switch A, switch B, switch Y, switch Z, and switch M).
Switch A
Switch Y
Switch B
Switch Z
STPD 1
Switch M
STPD 2
EX_048
When the switches in this configuration boot-up, STP configures each STPD such that the topology
contains no active loops. STP could configure the topology in a number of ways to make it loop-free.
518
STP Configurations
In Figure 40, the connection between switch A and switch B is put into blocking state, and the
connection between switch Y and switch Z is put into blocking state. After STP converges, all the
VLANs can communicate, and all bridging loops are prevented.
The protected VLAN Marketing, which has been assigned to both STPD1 and STPD2, communicates
using all five switches. The topology has no loops, because STP has already blocked the port connection
between switch A and switch B and between switch Y and switch Z.
Within a single STPD, you must be extra careful when configuring your VLANs. Figure 41 illustrates a
network that has been incorrectly set up using a single STPD so that the STP configuration disables the
ability of the switches to forward VLAN traffic.
Switch 1
Switch 3
Switch 2
EX_049
The tagged trunk connections for three switches form a triangular loop that is not permitted in an
STP topology.
STP can block traffic between switch 1 and switch 3 by disabling the trunk ports for that connection on
each switch.
Switch 2 has no ports assigned to VLAN Marketing. Therefore, if the trunk for VLAN Marketing on
switches 1 and 3 is blocked, the traffic for VLAN Marketing will not be able to traverse the switches.
NOTE
If an STPD contains multiple VLANs, all VLANs should be configured on all ports in that domain, except for ports
that connect to hosts (edge ports).
519
S1
S2
S1
S2
B
EX_050
The two switches are connected by a pair of parallel links. Both switches run two VLANs, A and B. To
achieve load-balancing between the two links using the traditional approach, you would have to
associate A and B with two different STPDs, called S1 and S2, respectively, and make the left link carry
VLAN A traffic while the right link carries VLAN B traffic (or vice versa). If the right link fails, S2 is
broken and VLAN B traffic is disrupted.
To optimize the solution, you can use the Extreme Multiple Instance Spanning (EMISTP) mode, which
allows a port to belong to multiple STPDs. EMISTP adds significant flexibility to STP network design.
Referring to Figure 42, using EMISTP, you can configure all four ports to belong to both VLANs.
Assuming that S1 and S2 still correspond to VLANs A and B, respectively, you can fine-tune STP
parameters to make the left link active in S1 and blocking in S2, while the right link is active in S2 and
blocking in S1. Again, if the right link fails, the left link is elected active by the STP algorithm for S2,
without affecting normal switching of data traffic.
Using EMISTP, an STPD becomes more of an abstract concept. The STPD does not necessarily
correspond to a physical domain; it is better regarded as a vehicle to carry VLANs that have STP
instances. Because VLANs can overlap, so do STPDs. However, even if the different STPDs share the
entire topology or part of the redundant topology, the STPDs react to topology change events in an
independent fashion.
520
STP Configurations
Alternatively, the same VLAN may span multiple large geographical areas (because they belong to the
same enterprise) and may traverse a great many nodes. In this case, it is desirable to have multiple STP
domains operating in a single VLAN, one for each looped area. The justifications include the following:
The complexity of the STP algorithm increases, and performance drops, with the size and complexity
of the network. The 802.1D standard specifies a maximum network diameter of seven hops. By
segregating a big VLAN into multiple STPDs, you reduce complexity and enhance performance.
Local to each site, there may be other smaller VLANs that share the same redundant looped area
with the large VLAN. Some STPDs must be created to protect those VLAN. The ability to partition
VLANs allows the large VLAN to be piggybacked in those STPDs in a site-specific fashion.
Figure 43 has five domains. VLANs green, blue, brown, and yellow are local to each domain. VLAN red
spans all of the four domains. Using a VLAN that spans multiple STPDS, you do not have to create a
separate domain for VLAN red. Instead, VLAN red is piggybacked onto those domains local to other
VLANs.
S2
VLAN green
VLAN yellow
VLAN red
S3
VLAN red
VLAN brown
S4
VLAN red
VLAN blue
EX_051
Each site can be administered by a different organization or department within the enterprise.
Having a site-specific STP implementation makes the administration more flexible and convenient.
Between the sites the connections usually traverse distribution switches in ways that are known
beforehand to be safe with STP. In other words, the looped areas are already well-defined.
Although a physical port can belong to multiple STPDs, any VLAN on that port can be in only one
domain. Put another way, a VLAN cannot belong to two STPDs on the same physical port.
521
Although a VLAN can span multiple domains, any LAN segment in that VLAN must be in the same
STPD. VLANs traverse STPDs only inside switches, not across links. On a single switch, however,
bridge ports for the same VLAN can be assigned to different STPDs. This scenario is illustrated in
Figure 44.
S2
S2
Correct
Wrong
EX_052
The VLAN partition feature is deployed under the premise that the overall inter-domain topology
for that VLAN is loop-free. Consider the case in Figure 45, VLAN red (the only VLAN in the figure)
spans STPDs 1, 2, and 3. Inside each domain, STP produces a loop-free topology. However, VLAN
red is still looped, because the three domains form a ring among themselves.
Domain 3
EX_053
522
A necessary (but not sufficient) condition for a loop-free inter-domain topology is that every two
domains only meet at a single crossing point.
NOTE
You can use MSTP to overcome the EMISTP constraints described in this section. See Multiple Spanning Tree
Protocol on page 535 for information about MSTP.
Native VLAN
In PVST+, the native VLAN must be peered with the default VLAN on Extreme Networks devices, as
both are the only VLAN allowed to send and receive untagged packets on the physical port.
Third-party PVST+ devices send VLAN 1 packets in a special manner. ExtremeWare XOS does not
support PVST+ for VLAN 1. Therefore, when the switch receives a packet for VLAN 1, the packet is
dropped.
When a PVST+ instance is disabled, the fact that PVST+ uses a different packet format raises an issue. If
the STPD also contains ports not in PVST+ mode, the flooded packet has an incompatible format with
those ports. The packet is not recognized by the devices connected to those ports.
523
RSTP Concepts
This section describes the following important RSTP concepts:
Port Roles
RSTP uses information from BPDUs to assign port roles for each LAN segment. Port roles are not userconfigurable. Port role assignments are determined based on the following criteria:
RSTP assigns one of four port roles to bridge ports in the network, as described in Table 65.
Description
Root
Provides the shortest (lowest) path cost to the root bridge. Each bridge has only one root port; the
root bridge does not have a root port. If a bridge has two or more ports with the same path cost,
the port with the best port identifier becomes the root port.
Designated
Provides the shortest path connection to the root bridge for the attached LAN segment. To
prevent loops in the network, there is only one designated port on each LAN segment. To select
the designated port, all bridges that are connected to a particular segment listen to each others
BPDUs and agree on the bridge sending the best BPDU. The corresponding port on that bridge
becomes the designated port. If there are two or more ports connected to the LAN, the port with
the best port identifier (lowest MAC address) becomes the designated port.
Alternate
Provides an alternate path to the root bridge and the root port.
Backup
Supports the designated port on the same attached LAN segment. Backup ports exist only when
the bridge is connected as a self-loop or to a shared-media segment.
RSTP makes the distinction between the alternate and backup port roles to describe the rapid transition
of the alternate port to the forwarding state if the root port fails.
Ports that connect to non-STP devices are edge ports. Edge ports do not participate in RSTP, and their
role is not confirmed. Edge ports immediately enter the forwarding state unless the port receives a
BPDU. In that case, edge ports enter the blocking state. The edge port remains in the blocking state until
it stops receiving BPDUs and the message age timer expires.
524
Link Types
With RSTP, you can configure the link type of a port in an STPD. RSTP tries to rapidly move designated
point-to-point links into the forwarding state when a network topology change or failure occurs. For
rapid convergence to occur, the port must be configured as a point-to-point link.
Table 66 describes the link types.
Description
Auto
Specifies the switch to automatically determine the port link type. An auto link behaves like a
point-to-point link if the link is in full-duplex mode or if link aggregation is enabled on the
port. Otherwise, the link behaves like a broadcast link used for 802.1w configurations.
Edge
Specifies a port that does not have a bridge attached. An edge port is placed and held in the
STP forwarding state unless a BPDU is received by the port. In that case, an edge port enters
and remains in the blocking state until it stops receiving BPDUs and the message age timer
expires.
Broadcast
Specifies a port attached to a LAN segment with more than two bridges. A port with a
broadcast link type cannot participate in rapid reconfiguration using RSTP or MSTP. By
default, all ports are broadcast links.
Point-to-point
Specifies a port attached to a LAN segment with only two bridges. A port with port-to-port link
type can participate in rapid reconfiguration. Used for 802.1w and MSTP configurations.
Configuring Link Types. By default, all ports are broadcast links. To configure the ports in an STPD, use
the following command:
configure stpd <stpd_name> ports link-type [[auto | broadcast | point-to-point]
<port_list> | edge <port_list> {edge-safeguard [enable | disable]}]
autoConfigures the ports as auto links. If the link is in full-duplex mode or if link aggregation is
enabled on the port, an auto link behaves like a point-to-point link.
broadcastConfigures the ports as broadcast ports. By default, all ports are broadcast links.
edgeConfigures the ports as edge ports. For information about edge safeguard, see Configuring
To display detailed information about the ports in an STPD, use the following command:
show stpd <stpd_name> ports {[detail | <port_list> {detail}]}
Configuring Edge Safeguard. Loop prevention and detection on an edge port configured for RSTP is
called edge safeguard. You configure edge safeguard on RSTP edge ports to prevent accidental or
deliberate misconfigurations (loops) resulting from connecting two edge ports together or by connecting
a hub or other non-STP switch to an edge port. Edge safeguard also limits the impact of broadcast
storms that might occur on edge ports. This advanced loop prevention mechanism improves network
resiliency but does not interfere with the rapid convergence of edge ports.
525
If you have already configured a port as an edge port and you want to enable edge safeguard on the
port, use the following command:
configure stpd <stpd_name> ports edge-safeguard enable <port_list>
To disable edge safeguard on an edge port, use one of the following commands:
RSTP Timers
For RSTP to rapidly recover network connectivity, RSTP requires timer expiration. RSTP derives many
of the timer values from the existing configured STP timers to meet its rapid recovery requirements
rather than relying on additional timer configurations. Table 67 describes the user-configurable timers,
and Table 68 describes the timers that are derived from other timers and not user-configurable.
Description
Hello
The root bridge uses the hello timer to send out configuration BPDUs through all of
its forwarding ports at a predetermined, regular time interval. The default value is 2
seconds. The range is 1 to 10 seconds.
Forward delay
A port moving from the blocking state to the forwarding state uses the forward delay
timer to transition through the listening and learning states. In RSTP, this timer
complements the rapid configuration behavior. If none of the rapid rules are in
effect, the port uses legacy STP rules to move to the forwarding state. The default
is 15 seconds. The range is 4 to 30 seconds.
Description
TCN
The root port uses the topology change notification (TCN) timer when it detects a
change in the network topology. The TCN timer stops when the topology change
timer expires or upon receipt of a topology change acknowledgement. The default
value is the same as the value for the bridge hello timer.
Topology change
The topology change timer determines the total time it takes the forwarding ports to
send configuration BPDUs. The default value for the topology change timer depends
upon the mode of the port:
802.1D modeThe sum of the forward delay timer value (default value is
15 seconds; range of 4 to 30 seconds) and the maximum age timer value
(default value is 20 seconds; range of 6 to 40 seconds).
802.1w modeDouble the hello timer value (default value is 4 seconds).
526
Description
Message age
A port uses the message age timer to time out receiving BPDUs. When a port
receives a superior or equal BPDU, the timer restarts. When the timer expires, the
port becomes a designated port and a configuration update occurs. If the bridge
operates in 1w mode and receives an inferior BPDU, the timer expires early. The
default value is the same as the STPD bridge max age parameter.
Hold
A port uses the hold timer to restrict the rate that successive BPDUs can be sent.
The default value is the same as the value for the bridge hello timer.
Recent backup
The timer starts when a port leaves the backup role. When this timer is running, the
port cannot become a root port. The default value is double the hello time
(4 seconds).
Recent root
The timer starts when a port leaves the root port role. When this timer is running,
another port cannot become a root port unless the associated port is put into the
blocking state. The default value is the same as the forward delay time.
The protocol migration timer is neither user-configurable nor derived; it has a set value of 3 seconds.
The timer starts when a port transitions from STP (802.1D) mode to RSTP (802.1w) mode and viceversa. This timer must expire before further mode transitions can occur.
RSTP Operation
In an RSTP environment, a point-to-point link LAN segment has two bridges. A switch that considers
itself the unique, designated bridge for the attached LAN segment sends a propose message to the
other bridge to request a confirmation of its role. The other bridge on that LAN segment replies with an
agree message if it agrees with the proposal. The receiving bridge immediately moves its designated
port into the forwarding state.
Before a bridge replies with an agree message, it reverts all of its designated ports into the blocking
state. This introduces a temporary partition into the network. The bridge then sends another propose
message on all of its designated ports for further confirmation. Because all of the connections are
blocked, the bridge immediately sends an agree message to unblock the proposing port without
having to wait for further confirmations to come back or without the worry of temporary loops.
Beginning with the root bridge, each bridge in the network engages in the exchange of propose and
agree messages until they reach the edge ports. Edge ports connect to non-STP devices and do not
participate in RSTP. Their role does not need to be confirmed. If an edge port receives a BPDU, it enters
an inconsistency state. An inconsistency state puts the edge port into the blocking state and starts the
message age timer. Every time the edge port receives a BPDU, the message age timer restarts. The edge
port remains in the blocking state until no further BPDUs are received and the message age timer
expires.
RSTP attempts to transition root ports and designated ports to the forwarding state and alternate ports
and backup ports to the blocking state as rapidly as possible.
A port transitions to the forwarding state if any of the following is true. The port:
Has been in either a root or designated port role long enough that the spanning tree information
supporting this role assignment has reached all of the bridges in the network.
527
NOTE
RSTP is backward compatible with STP, so if a port does not move to the forwarding state with any of the RSTP
rapid transition rules, a forward delay timer starts and STP behavior takes over.
Is now a root port and no other ports have a recent role assignment that contradicts with its root
port role.
Is a designated port and attaches to another bridge by a point-to-point link and receives an agree
message from the other bridge port.
Is an edge port.
An edge port is a port connected to a non-STP device and is in the forwarding state.
Becomes the root bridge and sends a BPDU to the LAN that is received by both ports on the old
bridge
New topology
Bridge
Backup
port
LAN segment
Bridge
Designated
port
Backup
port
Designated
port
Superior STP
bridge priority
Root
bridge
EX_054
If the backup port receives the BPDU first, STP processes this packet and temporarily elects this port as
the new root port while the designated ports role remains unchanged. If the new root port is
immediately put into the forwarding state, there is a loop between these two ports.
528
Synchronizes all of the designated ports if the receiving port is the root port of the new topology.
If the receiving bridge receives a proposal for a designated port, the bridge replies with its own BPDU.
If the proposal is for an alternate or backup port, the bridge keeps silent.
529
Rapid Reconvergence
This section describes the RSTP rapid behavior following a topology change. In this example, the bridge
priorities are assigned based on the order of their alphabetical letters; bridge A has a higher priority
than bridge F.
Suppose we have a network, as shown in Figure 47, with six bridges (bridge A through bridge F) where
the following is true:
A,0
A,1
A,2
A,1
A,2
A,3
Designated
port
530
Root
port
Blocked
port
EX_055a
A,0
A,1
A,2
Down
link
BPDU
F,0
A,2
A,3
Designated
port
Root
port
EX_055b
2 Bridge E believes that bridge A is the root bridge. When bridge E receives the BPDU on its root port
from bridge F, bridge E:
Sends BPDU messages on both of its designated ports to bridges F and D, respectively.
A,0
A,1
A,2
Designated
port
F,0
E,0
A,3
Root
port
BPDU
EX_055c
531
A,0
A,1
A,2
Designated
port
E,1
E,0
A,3
Root
port
EX_055d
532
Sends a propose message to bridge E to solicit confirmation of its designated role and to
rapidly move the port into the designated state.
A,0
A,1
A,2
Designated
port
E,1
E,0
A,3
Root
port
Propose BPDU
EX_055e
A,0
A,1
A,2
Designated
port
Root
port
E,1
A,4
A,3
Agree BPDU
EX_055f
533
Bridge D moves the port that received the agree message into the forwarding state.
Bridge F confirms that its receiving port (the port that received the propose message) is the root
port, and immediately replies with an agree message to bridge E to unblock the proposing port.
A,0
A,1
A,2
Root
port
Designated
port
A,5
A,4
A,3
EX_055g
A,0
A,1
A,2
Root
port
Designated
port
A,5
A,4
A,3
EX_055h
534
To save control path bandwidth and provide improved scalability, MSTP uses regions to localize
BPDU traffic. BPDUs containing information about MSTIs contained within an MSTP region do not
cross that regions boundary.
A single BPDU transmitted from a port can contain information for up to 64 STPDs. MSTP BPDU
processing utilizes less resources compared to 802.1D or 802.1w where one BPDU corresponds to one
STPD.
In a typical network, a group of VLANs usually share the same physical topology. Dedicating a
spanning tree per VLAN like PVST+ is CPU intensive and does not scale very well. MSTP makes it
possible for a single STPD to handle multiple VLANs.
MSTP Concepts
This section describes the following MSTP concepts:
MSTP Regions
An MSTP network consists of either individual MSTP regions connected to the rest of the network with
802.1D and 802.1w bridges or as individual MSTP regions connected to each other. An MSTP region
defines the logical boundary of the network. With MSTP, you can divide a large network into smaller
areas similar to an OSPF area or a BGP Autonomous System, which contain a group of switches under a
single administration. Each MSTP region has a unique identifier, is bound together by one CIST that
535
C
B
(40) CIST
regional root,
MSTI
regional root
(20) CIST
regional
root
D
MSTP
Region 1
F
(50) MSTI
regional
root
MSTP
Region 2
K
(60)
(80)
(90)
H
(100)
EX_167
Configuring MSTP Region Identifiers. For multiple switches to be part of an MSTP region, you must
configure each switch in the region with the same MSTP configuration attributes, also known as MSTP
region identifiers.
The following list describes the MSTP region identifiers:
536
Region NameThis indicates the name of the MSTP region. In the Extreme Networks
implementation, the maximum length of the name is 32 characters and can be a combination of
alphanumeric characters and underscores ( _ ).
Format SelectorThis indicates a number to identify the format of MSTP BPDUs. The default is 0.
Revision LevelThis identifier is reserved for future use; however, the switch uses and displays a
default of 3.
The maximum length of the region name is 32 characters and can be a combination of alphanumeric
characters and underscores ( _ ). You can configure only one MSTP region on the switch at any given
time.
If you have an active MSTP region, Extreme Networks recommends that you disable all active
STPDs in the region before renaming the region on all of the participating switches.
By default, the value used to identify the MSTP BPDUs is 0. The range is 0 to 255.
If you have an active MSTP region, Extreme Networks recommends that you disable all active
STPDs in the region before modifying the value used to identify MSTP BPDUs on all participating
switches.
Unconfiguring an MSTP Region. Before you unconfigure an MSTP region, Extreme Networks
recommends that you disable all active STPDs in the region.
To unconfigure the MSTP region on the switch, use the following command:
unconfigure mstp region
After you issue this command, all of the MSTP settings return to their default values. See Configuring
MSTP Region Identifiers on page 536 for information about the default settings.
537
You enable MSTP on a per STPD basis only. By specifying the mstp [cist] parameters, you configure
the mode of operation for the STPD as MSTP, and you identify the STPD to be the CIST.
CIST Root Bridge. In a Layer 2 network, the bridge with the lowest bridge ID becomes the CIST root
bridge. The parameters (vectors) that define the root bridge include the following:
MAC address
The CIST root bridge can be either inside or outside an MSTP region. The CIST root bridge is unique for
all regions and non-MSTP bridges, regardless of its location.
For more information about configuring the bridge ID, see the configure stpd priority command in
the ExtremeWare XOS Command Reference Guide.
CIST Regional Root Bridge. Within an MSTP region, the bridge with the lowest path cost to the CIST root
bridge is the CIST regional root bridge. The path cost, also known as the CIST external path cost, is a
function of the link speed and number of hops. If there is more than one bridge with the same path
cost, the bridge with the lowest bridge ID becomes the CIST regional root. If the CIST root is inside an
MSTP region, the same bridge is the CIST regional root for that region because it has the lowest path
cost to the CIST root. If the CIST root is outside an MSTP region, all regions connect to the CIST root via
their CIST regional roots.
The total path cost to the CIST root bridge from any bridge in an MSTP region consists of the CIST
internal path cost (the path cost of the bridge to the CIST regional root bridge) and the CIST external
path cost. To build a loop-free topology within a region, the CIST uses the external and internal path
costs, and the MSTI uses only the internal path cost.
538
A
= boundary port
= master port
= MSTI root port
(20) CIST
regional root
D
MSTP
Region 1
F
(50) MSTI
regional root
G
(60)
EX_168
CIST Root Port. The port on the CIST regional root bridge that connects to the CIST root bridge is the
CIST root port (also known as the master port for MSTIs). The CIST root port is the master port for all
MSTIs in that region, and it is the only port that connects the entire region to the CIST root.
If a bridge is both the CIST root bridge and the CIST regional root bridge, there is no CIST root port on
that bridge.
Enabling the CIST. To enable the CIST, use the following command and specify the CIST domain as the
<stpd_name>:
enable stpd {<stpd_name>}
539
MAC address
Within an MSTP region, the cost from a bridge to the MSTI regional root bridge is known as the MSTI
internal path cost. Looking at MSTP region 1 in Figure 56 on page 539, the bridge with ID 60 has a path
cost of F to the MSTI regional root bridge.
The MSTI regional root bridge can be the same as or different from the CIST regional root bridge of that
region. You achieve this by assigning different priorities to the STP instances configured as the MSTIs
and the CIST. For more information about configuring the bridge ID, see the configure stpd
priority command in the ExtremeWare XOS Command Reference Guide.
MSTI Root Port. The port on the bridge that has the lowest path cost to the MSTI regional root bridge is
the MSTI root port. If a bridge has two or more ports with the same path cost, the port with the best
port identifier becomes the root port.
Enabling the MSTI. To enable the MSTI, use the following command and specify the MSTI domain as the
<stpd_name>:
enable stpd {<stpd_name>}
Boundary Ports
Boundary ports are bridge ports that are only connected to other MSTP regions or 802.1D or 802.1w
bridges. The ports that are not at a region boundary are called internal ports. The boundary ports
exchange only CIST BPDUs. A CIST BPDU originated from the CIST root enters a region through the
CIST root port and egresses through boundary ports. This behavior simulates a region similar to an
802.1w bridge, which receives BPDUs on its root ports and forwards updated BPDUs on designated
ports.
540
C
B
(40) CIST
regional root,
MSTI
regional root
(20) CIST
regional
root
D
MSTP
Region 1
F
(50) MSTI
regional
root
MSTP
Region 2
K
(60)
(80)
(90)
H
(100)
EX_167
MSTP Region 1 and MSTP Region 2 are connected to the CIST root through directly connected ports,
identified as master ports. The bridge with ID 100 connects to the CIST root through Region 1, Region 2,
or segment B. For this bridge, either Region 1 or Region 2 can be the designated region or segment B
can be the designated segment. The CIST BPDUs egressing from the boundary ports carry the CIST
regional root as the designated bridge. This positions the entire MSTP region as one virtual bridge.
The CIST controls the port roles and the state of the boundary ports. A master port is always
forwarding for all CIST and MSTI VLANs. If the CIST sets a boundary port to the discarding state, the
CIST blocks traffic for all VLANs mapped to it and the MSTIs within that region. Each MSTI blocks
traffic for their member VLANs and puts their internal ports into the forwarding or blocking state
depending on the MSTI port roles. For more information about port states, see MSTP Port States on
page 541.
541
MSTP Timers
MSTP uses the same timers as STP and RSTP, respectively. For more information, see RSTP Timers on
page 526.
2 Create and configure the CIST, which forms the CST, using the following commands:
create stpd <stpd_name>
configure stpd <stpd_name> mode mstp cist
NOTE
You can configure the default STPD, S0 as the CIST.
542
configure stpd <stpd_name> add vlan <vlan_name> ports [all | <port_list>] {[dot1d
| emistp | pvst-plus]}
configure vlan <vlan_name> add ports [all | <port_list>] {tagged | untagged} stpd
<stpd_name> {[dot1d | emistp | pvst-plus]}
Automatically binding ports to an STPD when ports are added to a member VLAN
configure stpd <stpd_name> add vlan <vlan_name> ports [all | <port_list>] {[dot1d
| emistp | pvst-plus]}
configure vlan <vlan_name> add ports [all | <port_list>] {tagged | untagged} stpd
<stpd_name> {[dot1d | emistp | pvst-plus]}
Automatically binding ports to an STPD when ports are added to a member VLAN
For a more detailed configuration example, see MSTP Configuration Example on page 551.
543
MSTP Operation
To further illustrate how MSTP operates and converges, Figure 58 displays a network with two MSTP
regions. Each region contains three MSTP bridges and one MSTI. The overall network topology also
contains one CIST root bridge (Switch A, which has the lowest bridge ID), one interconnecting 802.1w
bridge (Switch D), and 10 full duplex, point-to-point segments. VLAN Default spans all of the bridges
and segments in the network, VLAN engineering is local to its respective region, and STPD S0 is
configured as the CIST on all bridges.
Figure 58: MSTP topology with the CIST root bridge contained within a region
= boundary port
= master port
= MSTI root port
Switch D
MSTP
Region 1
MSTP
Region 2
3
Switch A
CIST root
CIST regional root
MSTI regional root
Switch E
8
Switch B
CIST
regional root
7
10
Switch C
Switch F
Switch G
Switch A as the CIST root bridge (this is the CIST root bridge for all regions)
Three boundary ports that connect to MSTP region 2 and other 802.1D or 802.1w bridges
544
Three boundary ports that connect to MSTP region 1 and other 802.1D or 802.1w bridges
545
The carrier VLAN must span all ports of the STPD. (This is not applicable to MSTP.)
The StpdID must be the VLANid of the carrier VLAN; the carrier VLAN cannot be partitioned. (This
is not applicable to MSTP.)
A default VLAN cannot be partitioned. If a VLAN traverses multiple STPDs, the VLAN must be
tagged.
An STPD can carry, at most, one VLAN running in PVST+ mode, and its StpdID must be identical
with that VLANid. In addition, the PVST+ VLAN cannot be partitioned.
The default VLAN of a PVST+ port must be identical with the native VLAN on the PVST+ device
connected to that port.
If an STPD contains both PVST+ and non-PVST+ ports, that STPD must be enabled. If that STPD is
disabled, the BPDUs are flooded in the format of the incoming STP port, which may be incompatible
with those of the connected devices.
The 802.1D ports must be untagged; and the EMISTP/PVST+ ports must be tagged in the carrier
VLAN.
An STPD with multiple VLANs must contain only VLANs that belong to the same virtual router
instance.
A Netlogin port.
In an MSTP environment, A VLAN can belong to either a CIST or one of the MSTIs.
2 Add one or more VLANs to the STPD using the following command:
configure stpd <stpd_name> add vlan <vlan_name> ports [all | <port_list>] {[dot1d
| emistp | pvst-plus]}
546
NOTE
The carrier VLANs VLANid must be identical to the StpdID of the STPD.
4 Enable STP for one or more STPDs using the following command:
enable stpd {<stpd_name>}
After you have created the STPD, you can optionally configure STP parameters for the STPD.
NOTE
You should not configure any STP parameters unless you have considerable knowledge and experience with STP. The
default STP parameters are adequate for most networks.
Hello time (In an MSTP environment, configure this only on the CIST.)
Forward delay
Max age (In an MSTP environment, configure this only on the CIST.)
Bridge priority
Path cost
Port priority
Port mode
NOTE
The device supports the RFC 1493 Bridge MIB, RSTP-03, and Extreme Networks STP MIB. Parameters of the s0
default STPD support RFC 1493 and RSTP-03. Parameters of any other STPD support the Extreme Networks STP
MIB.
NOTE
If an STPD contains at least one port not in 802.1D (dot1D) mode, the STPD must be configured with an StpdID.
The following section provides more detailed STP configuration examples, including 802.1D, EMISTP,
RSTP, and MSTP.
547
Removes ports from the VLAN Default that will be added to VLAN Engineering.
Configures the default encapsulation mode of dot1d for all ports added to STPD Backbone_st.
Enables STP.
By default, the port encapsulation mode for user-defined STPDs is emistp. In this example, you set it to
dot1d.
548
S2
VLAN green
VLAN yellow
VLAN red
VLAN red
VLAN brown
S4
VLAN red
S3
VLAN blue
EX_051
NOTE
By default, all ports added to a user-defined STPD are in emistp mode, unless otherwise specified.
The following commands configure the switch located between S1 and S2:
create vlan red
configure red tag 100
configure red add ports 1:1-1:4 tagged
create vlan green
configure green tag 200
configure green add ports 1:1-1:2 tagged
create vlan yellow
configure yellow tag 300
configure yellow add ports 1:3-1:4 tagged
create stpd s1
configure stpd s1 add green ports all
configure stpd s1 tag 200
configure stpd s1 add red ports 1:1-1:2 emistp
enable stpd s1
create stpd s2
configure stpd s2 add yellow ports all
configure stpd s2 tag 300
configure stpd s2 add red ports 1:3-1:4 emistp
enable stpd s2
549
Create an STPD.
Create the VLANs and assign the VLANid and the VLAN ports.
Enable STP.
Switch A
Switch Y
Switch B
Switch Z
Switch M
STPD 1
STPD 2
EX_048
In this example, the commands configure switch A in STPD1 for rapid reconvergence. Use the same
commands to configure each switch and STPD in the network.
create stpd stpd1
configure stpd stpd1 mode dot1w
create vlan sales
create vlan personnel
create vlan marketing
configure vlan sales tag
configure vlan personnel
configure vlan marketing
configure vlan sales add
configure vlan personnel
550
100
tag 200
tag 300
ports 1:1,2:1 tagged
add ports 1:1,2:1 tagged
Switch D
MSTP
Region 1
MSTP
Region 2
3
Switch A
8
Switch B
Switch E
9
Switch C
7
10
Switch F
Switch G
For MSTP to work, complete the following steps on all switches in Region 1 and Region 2:
Remove ports from the VLAN Default that will be added to VLAN Engineering.
551
Create the STPD to be used as the CIST, and configure the mode of operation for the STPD.
Create the STPD to be used as an MSTI and configure the mode of operation for the STPD.
Create an STPD that has the same name as the CIST, and configure the mode of operation for the
STPD.
In the following sample configurations, any lines marked (Default) represent default settings and do not need to be
explicitly configured. STPD s0 already exists on the switch.
In the following example, the commands configure Switch A in Region 1 for MSTP. Use the same
commands to configure each switch in Region 1:
create vlan engineering
configure vlan engineering tag 2
configure vlan engineering add port 2-3 tagged
configure mstp
create stpd s0
configure stpd
configure stpd
552
region region1
(Default)
s0 mode mstp cist
s0 priority 32768 (Default)
In the following example, the commands configure Switch E in Region 2 for MSTP. Use the same
commands to configure each switch in Region 2:
create vlan finance
configure vlan finance tag 2
configure vlan finance add port 2-3 tagged
configure mstp
create stpd s0
configure stpd
configure stpd
enable stpd s0
configure stpd
enable stpd s0
create stpd s1
configure stpd
configure stpd
enable stpd s1
configure stpd
enable stpd s1
region region2
(Default)
s0 mode mstp cist
s0 priority 32768 (Default)
auto-bind vlan Default
s0 ports link-type point-to-point 4-5
In the following example, the commands configure switch D, the external switch. Switch D becomes the
CIST root bridge:
create stpd s0
configure stpd
configure stpd
enable stpd s0
configure stpd
enable stpd s0
(Default)
s0 mode dot1w
s0 priority 28672
auto-bind vlan Default
s0 ports link-type point-to-point 4-5
To display more detailed information for one or more STPDs, specify the detail option.
This command displays the following information:
STPD name
STPD state
553
Tag
Ports
Active VLANs
Bridge Priority
Bridge ID
Designated root
If you have MSTP configured on the switch, this command displays additional information:
MSTP Region
Format Identifier
Revision Level
To display the state of a port that participates in STP, use the following command:
show stpd <stpd_name> ports {[detail | <port_list> {detail}]}
To display more detailed information for one or more ports in the specified STPD, including
participating VLANs, specify the detail option.
This command displays the following information:
STPD priority
If you have MSTP configured and specify the detail option, this command displays additional
information:
MSTP timers
If you have a VLAN that spans multiple STPDs, use the show vlan <vlan_name> stpd command to
display the STP configuration of the ports assigned to that specific VLAN.
554
STPD priority
555
556
Overview of ESRP
The Extreme Standby Router Protocol (ESRP) is a feature of ExtremeWare XOS that allows multiple
switches to provide redundant routing services to users. From the workstations perspective, there is
only one default router (that has one IP address and one MAC address), so address resolution protocol
(ARP) cache entries in client workstations do not need to be refreshed or aged out. ESRP is available
only on Extreme Networks switches.
In addition to providing Layer 3 routing redundancy for IP and IPX, ESRP also provides Layer 2
redundancy. You can use these layered redundancy features in combination or independently.
You do not have to configure the switch for routing to make valuable use of ESRP. The Layer 2
redundancy features of ESRP offer fast failure recovery and provide for dual-homed system design. In
some instances, depending on network system design, ESRP can provide better resiliency than using
Spanning Tree Protocol (STP) or Virtual Router Redundancy Protocol (VRRP).
Extreme Networks recommends that all switches participating in ESRP run the same version of
ExtremeWare XOS.
This section describes the following topics:
557
ESRP Concepts
You configure ESRP on a per domain basis on each switch. A maximum of two switches can participate
in providing redundant Layer 3 or Layer 2 services to a single Virtual LAN (VLAN). If you configure
and use ESRP groups, more than two switches can provide redundant Layer 2 or Layer 3 services to a
single VLAN. The switches exchange keep-alive packets for each VLAN independently. Only one switch
(the master) can actively provide Layer 3 routing and/or Layer 2 switching for each VLAN. This switch
handles the forwarding, ARP requests, and routing for this particular VLAN. Other participating
switches for the VLAN are in slave mode waiting for an ESRP state change.
For a VLAN within an ESRP domain, each participating switch uses the same MAC address and must
be configured with the same IP address or IPX NetID. It is possible for one switch to be a master switch
for one or more VLANs while being a slave switch for other VLANs, thus allowing the load to be split
across participating switches.
558
ESRP Concepts
Figure 62 displays a basic ESRP topology.
Corpnet1, Corpnet2
advertised ESRP
virtual mac:
00:E0:2B:00:00:80
ESRP-aware
Corpnet3
advertised virtual mac:
00:E0:2B:00:00:80
ESRP-aware
ESRP-aware
EX_099
NOTE
If you configure the Open Shortest Path First (OSPF) routing protocol and ESRP, you must manually configure an
OSPF router identifier (ID). Be sure that you configure a unique OSPF router ID on each switch running ESRP. For
more information on configuring OSPF, see Chapter 28.
The IP address for the VLANs participating in an ESRP domain must be identical.
All switches in the ESRP network must use the same election algorithm, otherwise loss of
connectivity, broadcast storms, or other unpredictable behavior may occur.
If you have an untagged master VLAN, you must specify an ESRP domain ID. The domain ID must
be identical on all switches participating in ESRP for that particular domain.
If you have a tagged master VLAN, ESRP uses the 802.1Q tag (VLANid) of the master VLAN for the
ESRP domain ID. If you do not use the VLANid as the domain ID, you must specify a different
domain ID. As previously described, the domain ID must be identical on all switches participating in
ESRP for that particular domain.
559
ESRP-Aware Switches
Extreme Networks switches that are not actively participating in ESRP but are connected on a network
that has other Extreme Networks switches running ESRP are ESRP-aware. When ESRP-aware switches
are attached to ESRP-enabled switches, the ESRP-aware switches reliably perform failover and failback
scenarios in the prescribed recovery times.
If Extreme Networks switches running ESRP are connected to Layer 2 switches that are manufactured
by third-party vendors, the failover times for traffic local to that segment may appear longer, depending
on the application involved and the FDB timer used by the other vendors Layer 2 switch. ESRP can be
used with Layer 2 switches from other vendors, but the recovery times vary.
The VLANs associated with the ports connecting an ESRP-aware switch to an ESRP-enabled switch
must be configured using an 802.1Q tag on the connecting port; or, if only a single VLAN is involved, as
untagged using the protocol filter any. ESRP will not function correctly if the ESRP-aware switch
interconnection port is configured for a protocol-sensitive VLAN using untagged traffic. You can also
use port restart in this scenario. For more information about port restart, see ESRP Port Restart on
page 574.
The ESRP domain name must identical on all switches (ESRP-enabled and ESRP-aware) participating
in ESRP for that particular domain.
The master VLAN name and IP address must be identical on all switches (ESRP-enabled and ESRPaware) participating in ESRP for that particular domain.
If configured, the member VLAN name and IP address must be identical on all switches (ESRPenabled and ESRP-aware) participating in ESRP for that particular domain.
If you have an untagged master VLAN, you must specify an ESRP domain ID.
If you have a tagged master VLAN, ESRP uses the 802.1Q tag (VLANid) of the master VLAN for
the ESRP domain ID. If you do not use the VLANid as the domain ID, you must specify a
different domain ID.
NOTE
Before you begin, make a note of the ESRP domain parameters on the ESRP-enabled switch. That way you can
easily refer to your notes while creating the ESRP domain on the ESRP-aware switch.
560
ESRP Concepts
3 If configured, add the member VLANs to your ESRP domain using the configure esrp
<esrpDomain> add member <vlan_name> command.
4 If necessary, configure a domain ID for the ESRP domain using the configure esrp <esrpDomain>
domain-id <number> command.
The display includes the group number and MAC address for the master of the group, as well as the
age of the information.
Standard mode is backward compatible with and supports the ESRP functionality of switches running
ExtremeWare. ESRP functionality available in extended mode is not applicable in standard mode. Use
standard mode if your network contains both switches running ExtremeWare and switches running
ExtremeWare XOS participating in ESRP.
Extended mode supports and is compatible with switches running ExtremeWare XOS while
participating in ESRP. Use extended mode if your network contains only switches running ExtremeWare
XOS.
The following list describes the major differences in behavior between standard and extended mode:
Handshaking
In standard mode, events such as link flapping cause the ESRP master switch to generate a large
number of packets and to increase processing time.
To prevent this, extended mode supports handshaking. Handshaking occurs when a switch requests
a state change, forces its neighbor to acknowledge the change, and the neighbor sends an
acknowledgement to the requesting switch. For example, if a slave switch wants to become the
master, it enters the pre-master state, notifies the neighbor switch, and forces the neighbor to
acknowledge the change. The neighbor then sends an acknowledgement back to the slave switch.
While the requesting switch waits for the acknowledgements, future updates are suppressed to make
sure the neighbor does not act on incorrect data.
Stickiness
In standard mode, if an event causes the ESRP master switch to fail over to the slave, it becomes the
new master. If another event occurs, the new master switch returns to the slave and you have
experienced two network interruptions.
To prevent this, extended mode supports the sticky election metric. The default election algorithm
uses the sticky metric. For example, if an event causes the ESRP master switch to fail over to the
slave, it becomes the new master and has a higher sticky value. If another event occurs, for example
adding active ports to the slave, the new master does not fail back to the original master even if the
slave has more active ports. After sticky is set on the master, regardless of changes to its neighbors
election algorithm, the new master retains its position. Sticky algorithms provide for fewer network
interruptions than non-sticky algorithms. Sticky is set only on the master switch.
561
Port weight
In standard mode, the port count calculation does not take into account the available bandwidth of
the ports. For example, a switch with a one Gigabit Ethernet uplink may be unable to become master
because another switch has a load-shared group of four fast Ethernet links. The active port count
only consider the number of active ports, not the bandwidth of those ports.
In extended mode, the active port count considers the number of active ports and the port weight
configuration also considers the bandwidth of those ports. You enable port weight only on the loadshared master port.
Domain ID
In standard mode, ESRP packets do not contain domain information; therefore, the only information
about the packet comes from the receiving port.
The concept of domain ID is applicable only to extended mode. A domain ID in the packet clearly
classifies the packet, associates a received ESRP PDU to a specific ESRP domain, and tells the
receiving port where the packet came from. In extended mode, you must have a domain ID for each
ESRP domain. Each switch participating in ESRP for a particular domain must have the same
domain ID configured.
The ESRP domain ID is determined from one of the following user-configured parameters:
ESRP domain number created with the configure esrp <esrpDomain> domain-id <number>
command
Hello messages
In standard mode, both the master switch and slave switch send periodic ESRP hello messages. This
causes an increase in packet processing by both the master and slave.
In extended mode, the master switch sends periodic ESRP hello messages. This reduces the amount
of packet processing, increases the amount of available link bandwidth, and does not impact
communicating state changes between switches.
In addition to the modes of operation, ESRP has an auto toggle feature. Depending on the mode of
operation configured on the neighbor switch, the mode of operation at this end will toggle to the same
mode of operation as the neighbor. For example, if you use the default modeextendedand your
ESRP domain contains a switch running ExtremeWare XOS that detects a neighbor switch running
ExtremeWare, the mode automatically changes to standard for that domain. This action causes the
switch to enter the neutral state and re-elect the ESRP master. Since you are using the default mode of
operation, and the switch running ExtremeWare XOS detected a neighbor switch running ExtremeWare,
the ExtremeWare XOS switch toggles to standard mode although the configured mode of operation
remains as extended.
ESRP Domains
ESRP domains allow you to configure multiple VLANs under the control of a single instance of the
ESRP protocol. By grouping multiple VLANs under one ESRP domain, the ESRP protocol can scale to
provide protection to large numbers of VLANs. All VLANs within an ESRP domain simultaneously
share the same active and standby router and failover router, as long as one port of each member VLAN
belongs to the domain master.
Depending on the election policy used, when a port in a member VLAN belongs to the domain master,
the member VLAN ports are considered when determining the ESRP master. You can configure a
maximum of 64 ESRP domains in a network.
562
ESRP Concepts
If you disable an ESRP domain, the switch notifies its neighbor that the ESRP domain is going down,
and the neighbor clears its neighbor table. If the master switch receives this information, it enters the
neutral state to prevent a network loop. If the slave switch receives this information, it enters the
neutral state.
A direct link can provide a more direct routed path, if the ESRP switches are routing and supporting
multiple VLANs where the master/slave configuration is split such that one switch is master for
some VLANs and a second switch is master for other VLANs. The direct link can contain a unique
router-to-router VLAN/subnet, so that the most direct routed path between two VLANs with
different master switches uses a direct link, instead of forwarding traffic through another set of
connected routers.
A direct link can be used as a highly reliable method to exchange ESRP hello messages, so that the
possibility of having multiple masters for the same VLAN is lessened if all downstream Layer 2
switches fail.
A direct link is necessary for the ESRP host attach (HA) option. The direct link is used to provide
Layer 2 forwarding services through an ESRP slave switch.
Direct links may contain a router-to-router VLAN, along with other VLANs participating in an ESRP
domain. If multiple VLANs are used on the direct links, use 802.1Q tagging. The direct links may be
aggregated into a load-shared group, if desired. If multiple ESRP domains share a host port, each VLAN
must be in a different ESRP group.
NOTE
Beginning with ExtremeWare XOS 11.0, the BlackDiamond 10K switch supports hitless failover for ESRP. If you are
running an earlier version of ExtremeWare XOS, the BlackDiamond 10K switch does not support ESRP hitless
failover.
563
Beginning with ExtremeWare XOS 11.3, the BlackDiamond 8800 family of switches (formerly known as Aspen)
support hitless failover for ESRP. If you are running an earlier version of ExtremeWare XOS, the BlackDiamond 8800
family of switches do not support ESRP hitless failover.
Beginning with ExtremeWare XOS 11.4, the BlackDiamond 12804 series switch supports hitless failover for ESRP.
The ESRP domain on the primary MSM is active and participates in the ESRP protocol. The ESRP
domain on the backup MSM is in the neutral state listening for configuration changes, tracking failures,
and checkpointing messages and link state events. When you initiate MSM failover, the master ESRP
switch notifies its neighbor ESRP switch about the failover. After the neighbor receives information
from the master switch, the neighbor remains in its current state and waits for the failover to occur.
After the failover from the primary MSM to the backup MSM is complete, the master ESRP switch
notifies the neighbor so the neighbor can relinquish its current state.
To initiate hitless MSM failover on a network that uses ESRP:
1 Confirm that the MSMs are synchronized and have identical software and switch configurations
using the show switch {detail} command. The output displays the status of the MSMs, with the
primary MSM showing MASTER and the backup MSM showing BACKUP (InSync).
If the MSMs are not synchronized, proceed to step 2.
If the MSMs are synchronized, proceed to step 3.
2 If the MSMs are not in sync, replicate all saved images and configurations from the primary to the
backup using the synchronize command.
3 Initiate failover using the run msm-failover command.
For more detailed information about verifying the status of the MSMs and system redundancy, see
Understanding System Redundancy with Dual MSMs InstalledModular Switches Only on page 72.
For more information about hitless failover, see Understanding Hitless Failover SupportModular
Switches Only on page 76.
564
StickinessThe switch with the higher sticky value has higher priority. When an ESRP domain
claims master, its sticky value is set to 1 (available only in extended mode).
Active portsThe switch that has the greatest number of active ports takes highest precedence.
Tracking informationVarious types of tracking are used to determine if the switch performing the
master ESRP function has connectivity to the outside world. ExtremeWare XOS supports the
following types of tracking:
VLANTracks any active port connectivity to one designated VLANs. An ESRP domain can
track one VLAN, and the tracked VLAN should not be a member of any other ESRP domain in
the system.
IP route table entryTracks specific learned routes from the IP route table.
Environment (health checks)Tracks the environment of the switch, including power supply and
chassis temperature.
If any of the configured tracking mechanisms fail, the master ESRP switch relinquishes status as
master, and remains in slave mode for as long as the tracking mechanism continues to fail.
ESRP priorityThis is a user-defined field. The range of the priority value is 0 to 255; a higher
number has higher priority, except for 255. The default priority setting is 0. A priority setting of 255
makes an ESRP switch a standby switch that remains in slave mode until you change the priority
setting. Extreme Networks recommends this setting for system maintenance. A switch with a
priority setting of 255 will never become the master.
System MAC addressThe switch with the higher MAC address has higher priority.
Active port weightThe switch that has the highest port weight takes precedence. The bandwidth of
the port automatically determines the port weight (available only in extended mode).
You can configure the precedence order of the factors used by the system to determine the master ESRP
switch. For more information about configuring the ESRP election metrics, see ESRP Election
Algorithms on page 567.
565
If a parameter determines the master changes (for example, link loss or priority change), the election of
the new master typically occurs within one second. A parameter change triggers a handshake between
the routers. As long as both routers agree upon the state transition, new master election is immediate.
If a switch in slave mode loses its connection with the master, a new election occurs (using the same
precedence order indicated on page 564 or using a configured precedence order described in ESRP
Election Algorithms on page 567). The new election typically takes place in three times the defined
timer cycle (8 seconds by default).
Before the switch transitions to the master state, it enters a temporary pre-master state. While in the premaster state, the switch sends ESRP PDUs until the pre-master state timeout expires. Depending upon
the election algorithm, the switch may then enter the master or slave state. Traffic is unaffected by the
pre-master state because the master continues to operate normally. The pre-master state avoids the
possibility of having simultaneous masters.
You can configure the pre-master state timeout using the following command:
configure esrp <esrpDomain> timer premaster <seconds>
CAUTION
Configure the pre-master state timeout only with guidance from Extreme Networks personnel. Misconfiguration can
severely degrade the performance of ESRP and your switch.
The routing protocol being used for interrouter connectivity if Layer 3 redundancy is used; OSPF
failover time is faster than RIP failover time.
The failover time associated with the ESRP protocol depends on the timer setting and the nature of the
failure. The default hello timer setting is 2 seconds; the range is 2 to 1024 seconds. The default neighbor
timer setting is 8 seconds; the range is 3*hello to 1024 seconds. The failover time depends on the type of
event that caused ESRP to failover. In most cases, a non-hardware failover is less than 1 second, and a
hardware failover is 8 seconds.
566
Table 69 describes the ESRP election algorithms. Each algorithm considers the election factors in a
different order of precedence. The election algorithms that use sticky and weight are only available in
extended mode.
Description
567
Description
CAUTION
All switches in the ESRP network must use the same election algorithm, otherwise loss of connectivity, broadcast
storms, or other unpredictable behavior may occur.
NOTE
If you have a network that contains a combination of switches running ExtremeWare XOS and ExtremeWare, only the
ports-track-priority-mac election algorithm is compatible with ExtremeWare releases before version 6.0.
568
For more detailed information about all of the commands used to create, configure, enable, and disable
an ESRP domain, refer to the ExtremeWare XOS Command Reference Guide.
The esrpDomain parameter is a character string of up to 32 characters that identifies the ESRP domain
to be created.
NOTE
If you use the same name across categories (for example, STPD and ESRP names) Extreme Networks recommends
that you specify the appropriate keyword as well as the actual name. If you do not specify the keyword, the switch
may display an error message.
569
The number parameter specifies the number of the domain ID. The user-configured ID range is 4096
through 65,535.
The following example creates a domain ID of 4097 for ESRP domain esrp1:
configure esrp esrp1 domain-id 4097
The esrpDomain parameter specifies the name of the ESRP domain, and the vlan_name parameter
specifies the name of the master VLAN.
The following example adds the VLAN sales as the master VLAN to ESRP domain esrp1:
configure esrp esrp1 add master sales
To delete a master VLAN, you must first disable the ESRP domain before removing the master VLAN
using the disable esrp {<esrpDomain>} command.
To delete a master VLAN from an ESRP domain, use the following command:
configure esrp <esrpDomain> delete master <vlan_name>
The following examples removes the master VLAN sales from ESRP domain esrp1:
configure esrp esrp1 delete master sales
570
The esrpDomain parameter specifies the name of the ESRP domain, and the vlan_name parameter
specifies the name of the master VLAN.
The following example adds the VLAN purple as a member VLAN to ESRP domain esrp1:
configure esrp esrp1 add member purple
To delete a member VLAN from an ESRP domain, use the following command:
configure esrp <esrpDomain> delete member <vlan_name>
The following example removes the member VLAN purple from ESRP domain esrp1:
configure esrp esrp1 delete member purple
ESRP Tracking
Tracking information is used to track various forms of connectivity from the ESRP switch to the outside
world. This section describes the following ESRP tracking options:
571
2 Assign the priority flag precedence over the active ports count, using the following command:
configure esrp <esrpDomain> election-policy [ports > track > priority | ports >
track > priority > mac | priority > mac | priority > ports > track > mac |
priority > track > ports > mac | sticky > ports > track > priority | sticky >
ports > track > priority > mac | sticky > ports > weight > track > priority >
mac | sticky > priority > mac | sticky > priority > ports > track > mac | sticky
> priority > track > ports > mac | sticky > track > ports > priority > | track >
ports > priority | track > ports > priority > mac >]
Because the priority of both ESRP domains are set to the same value, ESRP will use the active ports
count to determine the master ESRP domain.
572
573
(track-vlan)
vlan vlan1
Host 2:
200.1.1.14/24
Gateway:
200.1.1.1
Router
L2 switch
10.10.10.121
Host 1:
200.1.1.13/24
Gateway:
200.1.1.1
ESRP slave
200.1.1.2/24
EX_094
Using the tracking mechanism, if VLAN1 fails, the ESRP master realizes that there is no path to the
upstream router via the master switch and implements an ESRP failover to the slave switch.
To configure route table tracking, use the following command:
configure esrp esrp1 add track-iproute 10.10.10.0/24
The route specified in this command must exist in the IP routing table. When the route is no longer
available, the switch implements an ESRP failover to the slave switch.
To configure ping tracking, use the following command:
configure esrp esrp1 add track-ping 10.10.10.121 frequency 2 miss 2
The specified IP address is tracked. If the fail rate is exceeded, the switch implements an ESRP failover
to the slave switch.
574
If a switch becomes a slave, ESRP takes down (disconnects) the physical links of member ports that
have port restart enabled. The disconnection of these ports causes downstream devices to remove the
ports from their FDB tables. This feature allows you to use ESRP in networks that include equipment
from other vendors. After 2 seconds, the ports re-establish connection with the ESRP switch.
To remove a port from the restart configuration, delete the port from the VLAN and re-add it.
EX_095
ESRP VLANs that share ESRP HA ports must be members of different ESRP groups. Each port can have
a maximum of seven VLANs.
575
ESRP Groups
ExtremeWare XOS supports running multiple instances of ESRP within the same VLAN or broadcast
domain. This functionality is called an ESRP group. Although other uses exist, the most typical
application for multiple ESRP groups is when two or more sets of ESRP switches are providing fastfailover protection within a subnet. A maximum of seven distinct ESRP groups can be supported on a
single ESRP switch, and a maximum of seven ESRP groups can be defined within the same network
broadcast domain. You can configure a maximum of 32 ESRP groups in a network.
576
ESRP
ESRP
Group1
Master
Group1
Standby
ESRP
Group2
Master
(L2 only)
(L2 only)
EX_096
An additional use for ESRP groups is ESRP HA, described on page 575.
The operational state of an ESRP domain and the state of its neighbor
To view more detailed information about an ESRP domain, use the following command and specify the
domain name:
show esrp {<name>}
Timer statistics
577
To view ESRP-aware information for a specific domain (including the group number, MAC address for
the master, and the age of information) use the following command:
show esrp {<name>}
For more information about any of the commands used to enable, disable, or configure ESRP, refer to
the ExtremeWare XOS Command Reference Guide.
578
Configuring ELRP
This section describes the commands used to configure ELRP for use with ESRP. By default, ELRP is
disabled.
countSpecifies the number of times the switch sends ELRP PDUs. The default is 3, and the range
is 1 to 32.
intervalSpecifies how often, in seconds, the ELRP PDUs are sent. The default is 1 seconds, and
579
intervalSpecifies how often, in seconds, successive ELRP packets are sent. The default is 1
Configuring Ports
You can configure one or more ports of an ESRP domain where ELRP packet transmission is requested
by ESRP. This allows the ports in your network that might experience loops, such as ports that connect
to the master, slave, or ESRP-aware switches, to receive ELRP packets. You do not need to send ELRP
packets to host ports.
By default, all ports of the ESRP domain have ELRP transmission enabled on the ports.
If you change your network configuration, and a port no longer connects to a master, slave, or ESRPaware switch, you can disable ELRP transmission on that port. To disable ELRP transmission, use the
following command:
configure esrp <esrpDomain> delete elrp-poll ports [<ports> | all]
In addition to displaying the enabled/disabled state of ELRP, the command displays the total number
of:
For more information about the output associated with the show elrp command, see the ExtremeWare
XOS Command Reference Guide.
ESRP Examples
This section provides examples of ESRP configurations.
580
ESRP Examples
between the edge switches and Layer 3 routing to the outside world. Each edge switch is dual-homed
using active ports to two BlackDiamond 10K switches. ESRP is enabled on each BlackDiamond 10K
switch for the ESRP domain esrp1 that interconnects to the edge switches. Each BlackDiamond 10K
switch has the VLAN Sales configured using the identical IP address. The BlackDiamond 10K switches
then connect to the routed enterprise normally, using the desired routing protocol (for example, RIP or
OSPF).
Figure 66: Single ESRP domain using Layer 2 and Layer 3 redundancy
OSPF or RIP
Domain - esrp1,
VLAN - Sales
(master)
Domain - esrp1,
VLAN - Sales
(standby)
EX_097
The BlackDiamond 10K switch, acting as master for ESRP domain esrp1, performs both Layer 2
switching and Layer 3 routing services for VLAN Sales. The BlackDiamond 10K switch in slave mode
for ESRP domain esrp1, performs neither for VLAN Sales, thus preventing bridging loops in the VLAN.
The BlackDiamond 110K10808 switch.
There are four paths between the BlackDiamond 10K switches on VLAN Sales. All the paths are used to
send ESRP packets, allowing for four redundant paths for communication. The edge switches, being
ESRP-aware, allow traffic within the VLAN to failover quickly because these edge switches sense when
a master/slave transition occurs and flush FDB entries associated with the uplinks to the ESRP-enabled
BlackDiamond 10K switches.
The following commands are used to configure both BlackDiamond 10K switches. In this scenario, the
master is determined by the programmed MAC address of the switch because the number of active
links for the VLAN and the priority are identical to both switches.
581
ESRP election algorithm used is the default for standard mode (ports > track > priority >
mac).
The Inter-router backbone is running OSPF, with other routed VLANs already properly configured.
Similar commands would be used to configure a switch on a network running RIP.
Ports added to the VLAN have already been removed from VLAN default.
If your network has switches running ExtremeWare and ExtremeWare XOS participating in ESRP, Extreme Networks
recommends that the ExtremeWare XOS switches operate in ESRP standard mode. To change the mode of operation,
use the configure esrp mode [extended | standard] command.
582
ESRP Examples
Figure 67: Multiple ESRP domains using Layer 2 and Layer 3 redundancy
Sales master,
Engineering standby
Sales
Sales
OSPF
or RIP
Sales standby,
Engineering master
Sales +
Engineering
Engineering
EX_098
This example builds on the previous example. It has the following features:
The VLAN Sales uses three active links to each BlackDiamond 10K switch.
The VLAN Engineering has two active links to each BlackDiamond 10K switch.
The link between the third edge device and the first BlackDiamond 10K switch uses 802.1Q tagging
to carry traffic from both VLANs traffic on one link. The BlackDiamond switch counts the link active
for each VLAN.
The second BlackDiamond switch has a separate physical port for each VLAN connected to the third
edge switch.
In this example, the BlackDiamond switches are configured for ESRP such that the VLAN Sales
normally uses the first BlackDiamond switch and the VLAN Engineering normally uses the second
BlackDiamond switch. This is accomplished by manipulating the ESRP priority setting for each VLAN
for the particular BlackDiamond switch.
583
Configuration commands for the second BlackDiamond 10K switch are as follows:
create vlan sales
configure vlan sales tag 10
configure vlan sales add ports 1:1-1:3
configure vlan sales ipaddress 10.1.2.3/24
create vlan engineering
configure vlan engineering tag 20
configure vlan engineering add ports 1:4, 2:1
configure vlan engineering ipaddress 10.4.5.6/24
create esrp esrp1
configure esrp esrp1 domain-id 4096
configure esrp 1 add master sales
enable esrp esrp1
create esrp esrp2
configure esrp esrp2 domain-id 4097
configure esrp esrp2 add master engineering
configure esrp esrp2 priority 5
enable esrp esrp2
ESRP Cautions
This section describes important details to be aware of when configuring ESRP.
584
ESRP Cautions
A Netlogin port
In addition, the following ESRP ports cannot be a mirroring, software-controlled redundant port, or
Netlogin port:
Restart port.
585
586
This chapter assumes that you are already familiar with the Virtual Router Redundancy Protocol
(VRRP). If not, refer to the following publications for additional information:
RFC 2787Definitions of Managed Objects for the Virtual Router Redundancy Protocol
Overview
Like the Extreme Standby Router Protocol (ESRP), VRRP allows multiple switches to provide redundant
routing services to users. VRRP is used to eliminate the single point of failure associated with manually
configuring a default gateway address on each host in a network. Without using VRRP, if the
configured default gateway fails, you must reconfigure each host on the network to use a different
router as the default gateway. VRRP provides a redundant path for the hosts. Using VRRP, if the default
gateway fails, the backup router assumes forwarding responsibilities.
VRRP priorityThis is a user-defined field. The range of the priority value is 1 to 254; a higher
number has higher priority. The value of 255 is reserved for a router that is configured with the
virtual router IP address. A value of 0 is reserved for the master router, to indicate it is releasing
responsibility for the virtual router. The default value is 100.
Higher IP addressIf the routers have the same configured priority, the router with the higher IP
address becomes the master.
587
VRRP Tracking
Tracking information is used to track various forms of connectivity from the VRRP router to the outside
world. ExtremeWare XOS supports the use of the following VRRP tracking options:
588
Router
L2 switch
or hub
10.10.10.121
Host 1:
200.1.1.13/24
Gateway:
200.1.1.1
VRRP backup
200.1.1.2/24
EX_067
To configure VLAN tracking, as shown in Figure 68, use the following command:
configure vrrp vlan vrrp1 vrid 2 add track-vlan vlan1
Using the tracking mechanism, if VLAN1 fails, the VRRP master realizes that there is no path to
upstream router via the master switch and implements a VRRP failover to the backup.
To configure route table tracking, as shown in Figure 68, use the following command:
configure vrrp vlan vrrp1 vrid 2 add track-iproute 10.10.10.0/24
The route specified in this command must exist in the IP routing table. When the route is no longer
available, the switch implements a VRRP failover to the backup.
To configure ping tracking, as shown in Figure 68, use the following command:
configure vrrp vlan vrrp1 vrid 2 add track-ping 10.10.10.121 frequency 2 miss 2
The specified IP address is tracked. If the fail rate is exceeded, the switch implements a VRRP failover
to the backup. A VRRP node with a priority of 255 may not recover from a ping-tracking failure if there
is a Layer 2 switch between it and another VRRP node. In cases where a Layer 2 switch is used to
connect VRRP nodes, Extreme Networks recommends that those nodes have priorities of less than 255.
589
Another VRRP router is attached to the VLAN, and the new router has the same priority as the
current master.
When VRRP is disabled on the master interface, the master router sends an advertisement with the
priority set to 0 to all backup routers. This signals the backup routers that they do not need to wait for
the master down interval to expire, and the master election process for a new master can begin
immediately.
The master down interval is set as follows:
3 * advertisement interval + skew time
Where:
An extremely busy CPU can create a short dual master situation. To avoid this, increase the advertisement interval.
590
Duplicate VRIDs are allowed on the router but not on the same interface.
An interconnect link between VRRP routers should not be used, except when VRRP routers have
hosts directly attached.
Up to seven unique VRIDs can be configured on the router. VRIDs can be re-used, but not on the
same interface.
VRRP Operation
VRRP and the Spanning Tree Protocol (STP) can be simultaneously enabled on the same switch.
Extreme Networks does not recommend simultaneously enabling VRRP and ESRP on the same
switch.
VRRP Operation
This section describes two VRRP network configurations:
Switch B
Switch A = Master
VRID = 1
Virtual router IP address = 192.168.1.3
MAC address = 00-00-5E-00-01-01
Priority = 255
Switch B = Backup
VRID = 1
Virtual router IP address = 192.168.1.3
MAC address = 00-00-5E-00-01-01
Priority = 100
192.168.1.3
192.168.1.5
In Figure 69, a virtual router is configured on Switch A and Switch B using these parameters:
VRID is 1.
IP address is 192.168.1.3.
Switch A is configured with a priority of 255. This priority indicates that it is the master router. Switch B
is configured with a priority of 100. This indicates that it is a backup router.
The master router is responsible for forwarding packets sent to the virtual router. When the VRRP
network becomes active, the master router broadcasts an ARP request that contains the virtual router
MAC address (in this case, 00-00-5E-00-01-01) for each IP address associated with the virtual router.
Hosts on the network use the virtual router MAC address when they send traffic to the default gateway.
The virtual router IP address is configured to be the real interface address of the IP address owner. The
IP address owner is usually the master router. The virtual router IP address is also configured on each
backup router. However, in the case of the backup router, this IP address is not associated with a
591
Switch B
Default Route
Backup Route
EX_069
IP address 192.168.1.3
IP address 192.168.1.5
Both virtual routers are simultaneously operational. The traffic load from the four hosts is split between
them. Host 1 and host 2 are configured to use VRID 1 on switch A as their default gateway. Host 3 and
host 4 are configured to use VRID 2 on switch B as their default gateway. In the event that either switch
fails, the backup router configured is standing by to resume normal operation.
592
Description
vrid
priority
ip_address
This is the IP address associated with this virtual router. You can
associate one or more IP addresses to a virtual router. This parameter
has no default value.
advertisement_interval
skew_time
master_down_interval
This is the time interval for the backup router to declare master down,
in seconds. This value is calculated as
((3 * advertisement_interval) + skew_time).
preempt_mode
593
VRRP Examples
This section provides the configuration syntax for the two VRRP networks discussed in this chapter.
Switch B
Switch A = Master
VRID = 1
Virtual router IP address = 192.168.1.3
MAC address = 00-00-5E-00-01-01
Priority = 255
Switch B = Backup
VRID = 1
Virtual router IP address = 192.168.1.3
MAC address = 00-00-5E-00-01-01
Priority = 100
192.168.1.3
192.168.1.5
The following examples assume that you have already created the VLAN named vlan1 on the switch.
Configuration commands for switch A are as follows:
configure vlan vlan1 ipaddress 192.168.1.3/24
create vrrp vlan vlan1 vrid 1
configure vrrp vlan vlan1 vrid 1 prioirty 255
configure vrrp vlan vlan1 vrid 1 add 192.168.1.3
enable vrrp
594
VRRP Cautions
Switch B
Default Route
Backup Route
EX_069
The following examples assume that you have already created the VLAN named vlan1 on the switch.
Configuration commands for switch A are as follows:
configure vlan vlan1 ipaddress
create vrrp vlan vlan1 vrid 1
configure vrrp vlan vlan1 vrid
configure vrrp vlan vlan1 vrid
create vrrp vlan vlan1 vrid 2
configure vrrp vlan vlan1 vrid
enable vrrp
192.168.1.3/24
1 priority 255
1 add 192.168.1.3
2 add 192.168.1.5
192.168.1.5/24
2 priority 255
2 add 192.168.1.5
1 add 192.168.1.3
VRRP Cautions
This section describes important details to be aware of when configuring VRRP.
595
For example, if you have a VLAN named v1 configured with IP addresses 1.1.1.1/24 and 2.2.2.2/24, the
following configurations are allowed:
VRRP VR on VLAN v1 with VRID 99 with virtual IP addresses 1.1.1.2 and 1.1.1.3
VRRP VR on VLAN v1 with VRID 99 with virtual IP addresses 1.1.1.98 and 1.1.1.99
Using the VLAN v1 configuration described above, the following configurations are not allowed:
VRRP VR on VLAN v1 with VRID 99 with virtual IP addresses 1.1.1.1 and 2.2.2.2 (the IP addresses
are not on the same subnet).
VRRP VR on VLAN v1 with VRID 99 with virtual IP addresses 1.1.1.1 and 1.1.1.99 (the switch owns
IP address 1.1.1.1).
596
This chapter assumes that you are already familiar with IP unicast routing. If not, refer to the following
publications for additional information:
For more information on interior gateway protocols, see Chapter 26, RIP, or Chapter 28, OSPF. For information
on exterior gateway protocols, see Chapter 30, Border Gateway Protocol. For more information on switch support
for IPv6, see Chapter 25, IPv6 Unicast Routing.
597
Router Interfaces
The routing software and hardware routes IP traffic between router interfaces. A router interface is
simply a virtual LAN (VLAN) that has an IP address assigned to it.
As you create VLANs with IP addresses belonging to different IP subnets, you can also choose to route
between the VLANs. Both the VLAN switching and IP routing function occur within the switch.
NOTE
Each IP address and mask assigned to a VLAN must represent a unique IP subnet. You cannot configure the same
IP address and subnet on different VLANs.
In Figure 73, a BlackDiamond switch is depicted with two VLANs defined; Finance and Personnel. All
ports on slots 1 and 3 are assigned to Finance; all ports on slots 2 and 4 are assigned to Personnel. Finance
belongs to the IP network 192.207.35.0; the router interface for Finance is assigned the IP address
192.207.35.1. Personnel belongs to the IP network 192.207.36.0; its router interface is assigned IP address
192.207.36.1. Traffic within each VLAN is switched using the Ethernet MAC addresses. Traffic between
the two VLANs is routed using the IP addresses.
192.207.35.1
192.207.35.11
192.207.36.1
192.207.35.0
Finance
192.207.36.0
Personnel
192.207.35.13
192.207.36.12
192.207.36.14
EX_070
598
Dynamically, by way of routing protocol packets or by Internet Control Message Protocol (ICMP)
redirects exchanged with other routers
If you define a default route and subsequently delete the VLAN on the subnet associated with the default route, the
invalid default route entry remains. You must manually delete the configured default route.
Dynamic Routes
Dynamic routes are typically learned by way of RIP or OSPF. Routers that use RIP or OSPF exchange
information in their routing tables in the form of advertisements. Using dynamic routes, the routing
table contains only networks that are reachable.
Dynamic routes are aged out of the table when an update for the network is not received for a period of
time, as determined by the routing protocol.
Static Routes
Static routes are manually entered into the routing table. Static routes are used to reach networks not
advertised by routers.
Static routes can also be used for security reasons, to control which routes you want advertised by the
router. You configure, if you want all static routes to be advertised, using one of the following
commands:
enable rip export [bgp | direct | e-bgp | i-bgp | ospf | ospf-extern1 | ospfextern2 | ospf-inter | ospf-intra | static] [cost <number> {tag <number>} |
policy <policy-name>]
or
disable rip export [bgp | direct | e-bgp | i-bgp | ospf | ospf-extern1 | ospfextern2 | ospf-inter | ospf-intra | static]
enable ospf export [bgp | direct | e-bgp | i-bgp | rip | static] [cost <cost>
type [ase-type-1 | ase-type-2] {tag <number>} | <policy-map>]
or
disable ospf export [bgp | direct | e-bgp | i-bgp | rip | static]
The default setting is disabled. Static routes are never aged out of the routing table.
A static routes nexthop (gateway) must be associated with a valid IP subnet. An IP subnet is associated
with a single VLAN by its IP address and subnet mask. If the VLAN is subsequently deleted, the static
route entries using that subnet must be deleted manually.
Multiple Routes
When there are multiple, conflicting choices of a route to a particular destination, the router picks the
route with the longest matching network mask. If these are still equal, the router picks the route using
the following default criteria (in the order specified):
599
Static routes
ICMP redirects
Dynamic routes
If you define multiple default routes, the route that has the lowest metric is used. If multiple default routes have the
same lowest metric, the system picks one of the routes.
You can also configure blackhole routestraffic to these destinations is silently dropped.
The criteria for choosing from multiple routes with the longest matching network mask is set by
choosing the relative route priorities.
Priority
Direct
10
BlackHole
50
Static
1100
ICMP
1200
EBGP
1700
IBGP
1900
OSPFIntra
2200
OSPFInter
2300
RIP
2400
OSPFExtern1
3200
OSPFExtern2
3300
BOOTP
5000
600
Proxy ARP
IP Route Sharing
IP route sharing allows multiple equal-cost routes to be used concurrently. IP route sharing can be used
with static routes or with OSPF routes. In OSPF, this capability is referred to as equal cost multipath
(ECMP) routing. To use IP route sharing, use the following commands:
BlackDiamond 8800 family and Summit X450:
enable iproute sharing
Next, configure static routes and/or OSPF as you would normally. For better resiliency when sharing
static routes, it is advised to configure static ARP and FDB entries for each gateway used by the shared
static routes. To do so, use the following commands:
configure iparp add <ip_addr> {vr <vr_name>} <mac>
create fdbentry <mac_addr> vlan <vlan_name> ports <port_list>
BlackDiamond 10K and BlackDiamond 12804. For the BlackDiamond 10K and BlackDiamond 12804,
ExtremeWare XOS supports route sharing across up to eight static routes and up to eight ECMP routes
for OSPF.
BlackDiamond 8800 family and Summit X450. For the BlackDiamond 8800 family and the Summit X450
switches, ExtremeWare XOS supports route sharing across up to four static routes and up to four ECMP
routes for OSPF, by default, but can be configured to support eight. To configure the maximum number
of ECMP gateways, use the following command:
configure iproute sharing max-gateways <max_gateways>
Using route sharing makes router troubleshooting more difficult because of the complexity in predicting
the path over which the traffic will travel.
Proxy ARP
Proxy Address Resolution Protocol (ARP) was first invented so that ARP-capable devices could respond
to ARP request packets on behalf of ARP-incapable devices. Proxy ARP can also be used to achieve
router redundancy and to simplify IP client configuration. The switch supports proxy ARP for this type
of network configuration. The section describes some example of using proxy ARP with the switch.
ARP-Incapable Devices
To configure the switch to respond to ARP requests on behalf of devices that are incapable of doing so,
you must configure the IP address and MAC address of the ARP-incapable device using the use the
following command:
configure iparp add proxy [<ipNetmask> | <ip_addr> {<mask>}] {vr <vr_name>} {<mac>}
{always}
601
The target IP address matches the IP address configured in the proxy ARP table.
The proxy ARP table entry indicates that the system should answer this ARP request, based on the
ingress VLAN and whether the always parameter is set. When the always option is set, the switch
will ARP for the host even if the ARP requester is on the same subnet as the requested host. If the
always option is not set, the switch will only answer if the ARP request comes in from a VLAN that
is not on the same subnet as the requested host.
When all the proxy ARP conditions are met, the switch formulates an ARP response using the
configured MAC address in the packet.
Default routes are used when the router has no other dynamic or static route to the requested
destination.
4 Turn on IP routing for one or all VLANs using the following command:
enable ipforwarding {ipv4 | broadcast} {vlan <vlan_name>}
602
603
Finance
IP address 192.207.35.1.
Personnel
IP address 192.207.36.1.
MyCompany
Port-based VLAN.
192.207.35.1
192.207.36.1
MyCompany
192.207.35.0
Finance
192.207.36.0
Personnel
IP
NetBIOS
IP
NetBIOS
IP
NetBIOS
IP
NetBIOS
= IP traffic
= NetBIOS traffic
EX_047
The stations connected to the system generate a combination of IP traffic and NetBIOS traffic. The IP
traffic is filtered by the protocol-sensitive VLANs. All other traffic is directed to the VLAN MyCompany.
In this configuration, all IP traffic from stations connected to slots 1 and 3 have access to the router by
way of the VLAN Finance. Ports on slots 2 and 4 reach the router by way of the VLAN Personnel. All
other traffic (NetBIOS) is part of the VLAN MyCompany.
604
IPv4 Multinetting
The example in Figure 74 is configured as follows:
create vlan Finance
create vlan Personnel
create vlan MyCompany
configure Finance protocol ip
configure Personnel protocol ip
configure Finance add port 1:*,3:*
configure Personnel add port 2:*,4:*
configure MyCompany add port all
configure
configure
configure
configure
enable ipforwarding
enable rip
IPv4 Multinetting
IP multinetting refers to having multiple IP networks on the same bridging domain (or VLAN). The
hosts connected to the same physical segment can belong to any one of the networks, so multiple
subnets can overlap onto the same physical segment. Any routing between the hosts in different
networks is done through the interface of the router. Typically, different IP networks will be on different
physical segments, but IP multinetting does not require this.
Multinetting can be a critical element in a transition strategy, allowing a legacy assignment of IP
addresses to coexist with newly configured hosts. However, because of the additional constraints
introduced in troubleshooting and bandwidth, Extreme Networks recommends that you use
multinetting as a transitional tactic only, and not as a long-term network design strategy.
Multinetting was not supported in ExtremeWare XOS 10.1, but versions of ExtremeWare before that
supported a multinetting implementation that required separate VLANs for each IP network. The
implementation introduced in ExtremeWare XOS 11.0 is simpler to configure, does not require that you
create a dummy multinetting protocol, and does not require that you create VLANs for each IP
network. This implementation does not require you to explicitly enable IP multinetting. Multinetting is
automatically enabled when a secondary IP address is assigned to a VLAN.
The following sections discuss these multinetting topics:
605
Multinetting Topology
For an IP multinetted interface, one of the IP networks on the interface acts as the transit network for
the traffic that is routed by this interface. The transit network is the primary subnet for the interface.
The remaining multinetted subnets, called the secondary subnets, must be stub networks. This
restriction is required because it is not possible to associate the source of the incoming routed traffic to a
particular network. IP routing happens between the different subnets of the same VLAN (one arm
routing) and also between subnets of different VLANs.
VLAN multi
Primary subnet
Secondary
subnet-1
Host
Secondary
subnet-2
BD10K
EX_102
Figure 75 shows a multinetted VLAN named multi. VLAN multi has three IP subnets so three IP
addresses have been configured for the VLAN. One of the subnets is the primary subnet and can be
connected to any transit network (for example, the Internet). The remaining two subnets are stub
networks, and multiple hosts such as management stations (such as user PCs and file servers) can be
connected to them. You should not put any additional routing or switching devices in the secondary
subnets to avoid routing loops. In Figure 75 the subnets are on separate physical segments, however,
multinetting can also support hosts from different IP subnets on the same physical segment.
When multinetting is configured on a VLAN, the switch can be reached using any of the subnet
addresses (primary or secondary) assigned to VLAN. This means that you can perform operations like
ping, Telnet, Trivial File Transfer Protocol (TFTP), Secure Shell 2 (SSH2), and others to the switch from a
host residing in either the primary or the secondary subnet of the VLAN. Other host functions (such as
traceroute) are also supported on the secondary interface of a VLAN.
606
IPv4 Multinetting
ARP
ARP operates on the interface and responds to every request coming from either the primary or
secondary subnet. When multiple subnets are configured on a VLAN and an ARP request is generated
by the switch over that VLAN, the source IP address of the ARP request must be a local IP address of
the subnet to which the destination IP address (which is being ARPed) belongs.
For example, if a switch multinets the subnets 10.0.0.0/24 and 20.0.0.0/24 (with VLAN IP addresses of
10.0.0.1 and 20.0.0.1), and generates an ARP request for the IP address 10.0.0.2, then the source IP
address in the ARP packet will be set to 10.0.0.1 and not to 20.0.0.1.
Route Manager
The Route Manager will install a route corresponding to each of the secondary interfaces. The route
origin will be direct, will be treated as a regular IP route, and can be used for IP data traffic forwarding.
These routes can also be redistributed into the various routing protocol domains if you configure route
redistribution.
IRDP
Some functional changes are required in Internet Router Discovery Protocol (IRDP) as result of IP
multinetting support. When IRDP is enabled on a Layer 3 VLAN, ExtremeWare XOS periodically sends
ICMP router advertisement messages through each subnet (primary and secondary) and responds to
ICMP router solicitation messages based on the source IP address of soliciting host.
Each network is treated as an interface, and hello messages are not sent out or received over the nonprimary interface. In this way, the router LSA includes information to advertise that the primary
607
Any inbound OSPF control packets from secondary interfaces are dropped.
Direct routes corresponding to secondary interfaces can be exported into the OSPF domain (by
enabling export of direct routes), if OSPF is not enabled on the container VLAN.
When you create an OSPF area address range for aggregation, you must consider the secondary
subnet addresses for any conflicts. That is, any secondary interface with the exact subnet address as
the range cannot be in another area.
The automatic selection algorithm for the OSPF router ID considers the secondary interface
addresses also. The numerically highest interface address is selected as the OSPF router-id.
RIP. This section describes the behavior of the Routing Information Protocol (RIP) in an IP multinetting
environment:
RIP does not send any routing information update on the secondary interfaces. However, RIP will
advertise networks corresponding to secondary interfaces in its routing information packet to the
primary interface.
Any inbound RIP control packets from secondary interfaces are dropped.
Direct routes corresponding to secondary interfaces can be exported into the RIP domain (by
enabling export of direct routes), if RIP is not enabled on the container VLAN.
BGP. There are no behavioral changes in the Border Gateway Protocol (BGP) in an IP multinetting
environment. This section describes a set of recommendations for using BGP with IP multinetting:
Be careful of creating a BGP neighbor session with a BGP speaker residing in secondary subnet. This
situation may lead to routing loops.
All secondary subnets are like stub networks, so you must configure BGP in such a way that the
BGP next hop becomes reachable using the primary subnet of a VLAN.
When setting the BGP next hop using an inbound or outbound policy, ensure that the next hop is
reachable from the primary interface.
A BGP static network's reachability can also be resolved from the secondary subnet.
Secondary interface addresses can be used as the source interface for a BGP neighbor.
Direct routes corresponding to secondary interfaces can be exported into the BGP domain (by
enabling export of direct routes).
608
A layer 3 VLAN will always use the primary IP address as the source address to send out an IGMP
query, and querier election is based on the primary IP address of interface. Because the RFC dictates
that there is only one querier per physical segment, the querier may be attached to any of configured
IP interfaces, including secondary interfaces, although this is not a recommended configuration.
For a static IGMP group, the membership report is also sent out using the primary IP address.
For local multicast groups such as 224.0.0.X, the membership report is sent out using the first IP
address configured on the interface, which is the primary IP address in ExtremeWare XOS.
IPv4 Multinetting
The source IP address check is disabled for any IGMP control packets (such as IGMP query and
IGMP membership report). Source IP address checking for IGMP control packet is disabled for all
VLANs, not just the multinetted VLANs.
PIM does not peer with any other PIM router on a secondary subnet.
PIM also processes data packets from the host on secondary subnets.
DHCP Server
The Dynamic Host Configuration Protocol (DHCP) server implementation in ExtremeWare XOS 11.0
will only support address allocation on the primary IP interface of the configured VLAN. That is, all
DHCP clients residing on a bridging domain will have IP address belonging to the primary subnet. To
add a host on secondary subnet, you must manually configure the IP address information on that host.
DHCP Relay
When the switch is configured as a DHCP relay agent, it will forward the DHCP request received from
a client to the DHCP server. When doing so, the system sets the GIADDR field in the DHCP request
packet to the primary IP address of the ingress VLAN. This means that the DHCP server that resides on
a remote subnet will allocate an IP address for the client in the primary subnet range.
VRRP
The Virtual Router Redundancy Protocol (VRRP) protection can be provided for the primary as well as
for the secondary IP addresses of a VLAN. For multinetting, the IP address assigned to an VRRP virtual
router identifier (VRID) can be either the primary or the secondary IP addresses of the corresponding
VLAN.
For example, assume a VLAN v1 with two IP addresses: a primary IP address of 10.0.0.1/24, and a
secondary IP address of 20.0.0.1/24.
To provide VRRP protection to such a VLAN, you must configure one of the following:
Configure VRRP in VLAN v1 with two VRRP VRIDs. One VRID will have the virtual IP address
10.0.0.1/24, and the other VRID will have the virtual IP address 20.0.0.1/24. The other VRRP router,
the one configured to act as backup, should be configured similarly.
OR
609
Configure VRRP in VLAN v1 with two VRRP VRIDs. One VRID will have the virtual IP address as
10.0.0.1/24, and the other VRID will have the virtual IP address as 20.0.0.1/24.
It is possible for a VRRP VR to have additional virtual IP addresses assigned to it. In this case, the
following conditions must be met:
Multiple virtual IP addresses for the same VRID must be on the same subnet.
Assuming a VLAN v1 that has IP addresses 1.1.1.1/24 and 2.2.2.2/24, here are some more examples of
valid configurations:
VRRP VR on v1 with VRID of 100 with virtual IP addresses of 2.2.2.3 and 2.2.2.4
VRRP VR on v1 with VRID of 100 with virtual IP addresses of 2.2.2.98 and 2.2.2.99
Given the same VLAN v1 as above, here are some invalid configurations:
VRRP VR on v1 with VRID of 99 with virtual IP addresses of 1.1.1.1 and 2.2.2.2 (the virtual IP
addresses are not on the same subnet)
VRRP VR on v1 with VRID of 100 with virtual IP addresses of 2.2.2.2 and 1.1.1.1 (the virtual IP
addresses are not on the same subnet)
VRRP VR on v1 with VRID of 99 with virtual IP addresses of 1.1.1.1 and 1.1.1.99 (one virtual IP
address is owned by the switch and one is not)
VRRP VR on v1 with VRID of 100 with virtual IP addresses of 2.2.2.2 and 2.2.2.99 (one virtual IP
address is owned by the switch and one is not).
After you have added a secondary IP address, you cannot change the primary IP address of a VLAN
until you first delete all the secondary IP addresses. To delete secondary IP addresses, use the following
command:
configure vlan <vlan_name> delete secondary-ipaddress [<ipaddress> | all]
IP Multinetting Examples
The following example configures a switch to have one multinetted segment (port 5:5) that contains
three subnets (192.168.34.0/24, 192.168.35.0/24, and 192.168.37.0/24).
configure default delete port 5:5
create vlan multinet
configure multinet ipaddress 192.168.34.1/24
configure multinet add secondary-ipaddress 192.168.35.1/24
configure multinet add secondary-ipaddress 192.168.37.1/24
configure multinet add port 5:5
enable ipforwarding
610
3 Configure the addresses to which DHCP or BOOTP requests should be directed, using the following
command:
configure bootprelay add <ip_address> {vr <vrid>}
611
Agent circuit ID sub-option: Contains the ID of the port on which the original DHCP request packet
was received. This ID is encoded as ((slot_number * 1000) + port_number). For example, if the DHCP
request were received on port 3:12, the agent circuit ID value would be 3012. On non-slot-based
switches, the agent circuit ID value is simply the port number.
Agent remote ID sub-option: Always contains the Ethernet MAC address of the relaying switch.
You can display the Ethernet MAC address of the switch by issuing the show switch command.
To enable the DHCP relay agent option, use the following command after configuring the DHCP/
BOOTP relay function:
configure bootprelay dhcp-agent information option
To disable the DHCP relay agent option, use the following command:
unconfigure bootprelay dhcp-agent information option
In some instances, a DHCP server may not properly handle a DHCP request packet containing a relay
agent option. To prevent DHCP reply packets with invalid or missing relay agent options from being
forwarded to the client, use the following command:
configure bootprelay dhcp-agent information check
A DHCP relay agent may receive a client DHCP packet that has been forwarded from another relay
agent. If this relayed packet already contains a relay agent option, then the switch will handle this
packet according to the configured DHCP relay agent option policy. The possible actions are to replace
the option information, to keep the information, or to drop packets containing option 82 information. To
configure this policy, use the following command:
configure bootprelay dhcp-agent information policy [drop | keep | replace]
The default relay policy is replace. To configure the policy to the default, use this command:
unconfigure bootprelay dhcp-agent information policy
For more general information about the DHCP relay agent information option, refer to RFC 3046.
This command displays the configuration of the BOOTP relay service and the addresses that are
currently configured.
612
UDP Forwarding
UDP Forwarding
UDP Forwarding is a flexible and generalized routing utility for handling the directed forwarding of
broadcast UDP packets. UDP Forwarding enables you to configure your switch so that inbound
broadcast UDP packets on a VLAN are forwarded to a particular destination IP address or VLAN.
UDP Forwarding allows applications, such as multiple DHCP relay services from differing sets of
VLANs, to be directed to different DHCP servers. The following rules apply to UDP broadcast packets
handled by this feature:
If the UDP profile includes BOOTP or DHCP, it is handled according to guidelines specified in RFC
1542.
If the UDP profile includes other types of traffic, these packets have the IP destination address
modified as configured, and changes are made to the IP and UDP checksums and decrements to the
TTL field, as appropriate.
If UDP Forwarding is used for BOOTP or DHCP forwarding purposes, do not configure or use the
existing bootprelay function. However, if the previous bootprelay functions are adequate, you may
continue to use them.
NOTE
UDP Forwarding only works across a layer 3 boundary and currently, UDP Forwarding can be applied to IPv4 packets
only, not to IPv6 packets.
You can apply a UDP Forwarding policy only to an L3 VLAN (a VLAN having at least one IP address
configured on it). If no IP address is configured on the VLAN, then the command will be rejected.
UDP profiles are similar to ACL policy files. UDP profiles use a subset of the match conditions allowed
for ACLs. A UDP Forwarding policy must contain only the following attributes. Unrecognized
attributes will be ignored.
Match attributes
Policy files used for UDP Forwarding are processed differently from standard policy files. Instead of
terminating when an entrys match clause becomes true, each entry in the policy file will be processed
and the corresponding action will be taken for each true match clause.
613
If you include more than one VLAN set attribute or more than one destination-ipaddress set attribute in
one policy entry, the last one will be accepted and the rest ignored. Therefore, you can have two valid
set statements in each entry of a UDP Forwarding policy; one a destination-ipaddress and one a VLAN.
ExtremeWare XOS currently allows a maximum of eight entries in a UDP Forwarding policy, so you can
define a maximum of 16 destinations for one inbound broadcast UDP packet: eight IP address and eight
VLANs.
NOTE
It is strongly advised not to have more than eight entries in a UDP Forwarding profile. The UDP Forwarding module
will process those entries even if the entries do not contain any attributes for UDP Forwarding. Having more than
eight entries will drastically reduce the performance of the system. If the inbound UDP traffic rate is very high,
having more than eight entries could cause the system to freeze or become locked.
NOTE
If you rename a VLAN referred to in your UDP Forwarding profile, you must manually edit the policy to reflect the
new name, and refresh the policy.
You can also validate whether the UDP profile has been successfully associated with the VLAN by
using the command show policy {<policy-name> | detail}. UDP Forwarding is implemented as
part of the netTools process, so the command will display netTools as a user of the policy.
To remove a policy, use the none form of the following command:
configure vlan <vlan_name> udp-profile [<profilename> | none]
For more information about creating and editing policy files, see Chapter 13, Policy Manager. For
more information about ACL policy files, see Chapter 14, Access Lists (ACLs).
614
UDP Forwarding
615
616
This chapter assumes that you are already familiar with IPv6 unicast routing. If not, refer to the
following publications for additional information:
For more information on interior gateway protocols, see Chapter 27, RIPng or Chapter 29, OSPFv3.
NOTE
IPv6 functionality is supported only on the virtual routers VR-Default and VR-Mgmt. VR-Mgmt supports only IPv6
addressing and static routing; VR-Default also supports dynamic routing.
617
Router Interfaces
The routing software and hardware routes IPv6 traffic between router interfaces. A router interface is
either a virtual LAN (VLAN) that has an IP address assigned to it, or, new for IPv6, a layer 3 tunnel.
As you create VLANs and tunnels with IPv6 addresses, you can also choose to route (forward traffic)
between them. Both the VLAN switching and IP routing function occur within the switch.
An interface can have up to 255 IPv6 addresses, with at least one being a link local address. IPv4 and
IPv6 interfaces can coexist on the same VLAN, allowing both IPv4 and IPv6 networks to coexist on the
same Layer 2 broadcast domain.
NOTE
Each IP address and mask assigned to a VLAN must represent a unique IP subnet. You cannot configure the same
IP address and subnet on different VLANs within the same virtual router.
Tunnels
Layer 3 tunnels are a transition method, as networks change over from IPv4 to IPv6. ExtremeWare XOS
supports the use of IPv6-in-IPv4 tunnels (known as configured tunnels or 6in4 tunnels) and IPv6-toIPv4 tunnels (known as 6to4 tunnels). To create or delete a tunnel, use the following commands:
create tunnel <tunnel_name> 6to4 source <source-address>
create tunnel <tunnel_name> ipv6-in-ipv4 destination <destination-address> source
<source-address>
delete tunnel <tunnel_name>
To configure and unconfigure IPv6 addresses for the tunnels, use the following commands:
configure tunnel <tunnel_name> ipaddress [{eui64} [<ipv6_address_mask> |
<ipv6_address>] | ipv6-link-local]
unconfigure tunnel <tunnel_name> ipaddress <ipv6_address_mask>
618
Additionally, you can specify an address in a mixed IPv4/IPv6 mode that uses six, four-digit
hexadecimal numbers for the highest-order part of the address, and uses the IPv4 dotted decimal
representation for the lowest-order remaining portion. For example:
0:0:0:0:0:0:192.168.1.1
0:0:0:0:0:ffff:10.0.14.254
Scoped Addresses
IPv6 uses a category of addresses called link local addresses that are used solely on a local subnet. Due
to the way that local link addresses can be automatically assigned, a switch can have the same link local
address assigned to different VLANs, or different neighbors on different links may be using the same
link local address. Because of this, there are cases where you need to specify an address and a VLAN/
tunnel to indicate which interface to use. For those cases, you can indicate the interface by using a
scoped address. To scope the address, append the VLAN/tunnel name to the end of the address,
separated by a percent sign (%). For example, to indicate the link local address fe80::2 on VLAN finance,
use the following form:
fe80::14%finance
619
Locating the address prefixes that are located on the attached link.
Learn link parameters such as the link MTU, or Internet parameters such as the hop limit value that
has to be used in the outgoing packets.
Detect whether the address that it wants to use is not already in use by another node, also known as
Duplicate Address Detection (DAD).
Router Discovery
Also supported is router discoverythe ability to send out router advertisements that can be used by a
host to discover the router. The advertisements sent out contain the prefixes and configuration
parameters that allow the end nodes to auto-configure their addresses. The switch also responds to
requests from nodes for router advertisements.
620
Settings to control the sending of router advertisements over the interface periodically and to control
responding to router solicitations
You can configure the following values, that are advertised by the switch:
Link MTU
Retransmit Timer
Default Lifetime
Reachable Time
Additionally, you can configure the following values for each prefix on the prefix list associated with an
interface:
On-Link Flag
Autonomous Flag
To configure the prefixes advertised by router discovery, use the following command to add prefixes:
configure vlan <vlan_name> router-discovery {ipv6} add prefix <prefix>
NOTE
Unlike ExtremeWare, ExtremeWare XOS does not support host processing of neighbor router advertisements.
Dynamically, by way of routing protocol packets or by Internet Control Message Protocol (ICMP)
redirects exchanged with other routers
621
NOTE
If you define a default route and subsequently delete the VLAN on the subnet associated with the default route, the
invalid default route entry remains. You must manually delete the configured default route.
Dynamic Routes
Dynamic routes are typically learned by way of RIPng or OSPFv3. Routers that use RIPng or OSPFv3
exchange information in their routing tables in the form of advertisements. Using dynamic routes, the
routing table contains only networks that are reachable.
Dynamic routes are aged out of the table when an update for the network is not received for a period of
time, as determined by the routing protocol.
Static Routes
Static routes are manually entered into the routing table. Static routes are used to reach networks not
advertised by routers.
Static routes can also be used for security reasons, to control which routes you want advertised by the
router. You configure, if you want all static routes to be advertised, using one of the following
commands:
enable ripng export [direct | ospfv3 | ospfv3-extern1 | ospfv3-extern2 | ospfv3inter | ospfv3-intra | static] [cost <number> {tag <number>} | policy <policyname>]
or
disable ripng export [direct | ospfv3 | ospfv3-extern1 | ospfv3-extern2 | ospfv3inter | ospfv3-intra | static]
enable ospfv3 {domain <domainName>} export [direct | ripng | static] [cost <cost>
type [ase-type-1 | ase-type-2] | <policy-map>]
or
disable ospfv3 {domain <domainName>} export [direct | ripng | static]
The default setting is disabled. Static routes are never aged out of the routing table.
A static routes nexthop (gateway) must be associated with a valid IP subnet. An IP subnet is associated
with a single VLAN by its IP address and subnet mask. If the VLAN is subsequently deleted, the static
route entries using that subnet must be deleted manually.
Multiple Routes
When there are multiple, conflicting choices of a route to a particular destination, the router picks the
route with the longest matching network mask. If these are still equal, the router picks the route using
the following default criteria (in the order specified):
622
Static routes
ICMP redirects
Dynamic routes
NOTE
If you define multiple default routes, the route that has the lowest metric is used. If multiple default routes have the
same lowest metric, the system picks one of the routes.
You can also configure blackhole routestraffic to these destinations is silently dropped.
The criteria for choosing from multiple routes with the longest matching network mask is set by
choosing the relative route priorities.
Priority
Direct
10
BlackHole
50
Static
1100
ICMP
1200
OSPF3Intra
2200
OSPF3Inter
2300
RIPng
2400
OSPFv3 ASExt
3100
OSPFv3 Extern1
3200
OSPFv3 Extern2
3300
623
Default routes are used when the router has no other dynamic or static route to the requested
destination.
4 Turn on IP routing for one or all VLANs using the following command:
enable ipforwarding ipv6 {vlan <vlan_name> | tunnel <tunnel-name> | vr <vr_name>}
5 Configure the routing protocol, if required. For a simple network using RIPng, the default
configuration may be acceptable.
6 Turn on RIPng or OSPFv3 using one of the following commands:
enable ripng
enable ospfv3 {domain <domainName>}
624
show neighbor-discovery cache ipv6Displays the neighbor discovery cache of the system.
Finance
IP address 2001:db8:35::1/48.
Personnel
IP address 2001:db8:36::1/48.
MyCompany
Port-based VLAN.
2001:db8:35::1/48
2001:db8:36::1/48
MyCompany
2001:db8:35::/48
Finance
2001:db8:36::/48
Personnel
IPv6
NetBIOS
IPv6
NetBIOS
IPv6
NetBIOS
IPv6
NetBIOS
= IPv6 traffic
= NetBIOS traffic
EX_106
The stations connected to the system generate a combination of IPv6 traffic and NetBIOS traffic. The
IPv6 traffic is filtered by the protocol-sensitive VLANs. All other traffic is directed to the VLAN
MyCompany.
625
626
Host A
Router A
2001:db8:1::101/64
2001:db8:1::1/64
1 2001:db8:a::1/64
IPv6
192.168.1.1/24
IPv4
Router B
IPv6
2001:db8:a::2/64 1
10.2.0.1/24
2001:db8:2::1/64 2
Host B
2001:db8:2::101/64
EX_108
In Figure 77, Router A has an interface to an IPv4 region with the address 192.168.1.1 (for this example
we are using private IPv4 addresses, but to tunnel across the Internet, you would use a public address).
Router B has an IPv4 interface of 10.2.0.1. The IPv4 interface must be created before the tunnel is
configured and cannot be deleted until the tunnel is deleted.
This example has one subnet in each IPv6 region, 2001:db8:1::/64 for Router A and 2001:db8:2::/64 for
Router B. Hosts A and B are configured to use IPv6 addresses 2001:db8:1::101 and 2001:db8:2::101
respectively.
For traffic to move from one region to the other, there must be a route. In this example, a static route is
created, but you could enable RIPng or OSPFv3 on the tunnel interface.
In this example, we assume that the IPv4 network can route from Router A to Router B (in other words,
some IPv4 routing protocol is running on the public-ipv4 interfaces). However, you do not need to
enable IPv4 forwarding on the public interfaces in this example unless you are also routing IPv4 traffic
on them (in this example, it is assumed you are running no IPv4 traffic inside your respective IPv6
networks, although you could).
627
Router A
configure vlan default delete port all
create vlan public-ipv4
configure vlan public-ipv4 add port 1 untagged
configure vlan public-ipv4 ipaddress 192.168.1.1/24
create tunnel public6in4 ipv6-in-ipv4 destination 10.2.0.1 source 192.168.1.1
configure tunnel public6in4 ipaddress 2001:db8:a::1/64
enable ipforwarding ipv6 public6in4
create vlan private-ipv6
configure vlan private-ipv6 add port 2 untagged
configure vlan private-ipv6 ipaddress 2001:db8:1::1/64
enable ipforwarding ipv6 private-ipv6
configure iproute add 2001:db8:2::/64 2001:db8:a::2
Router B
configure vlan default delete port all
create vlan public-ipv4
configure vlan public-ipv4 add port 1 untagged
configure vlan public-ipv4 ipaddress 10.2.0.1/24
create tunnel public6in4 ipv6-in-ipv4 destination 192.168.1.1 source 10.2.0.1
configure tunnel public6in4 ipaddress 2001:db8:a::2/64
enable ipforwarding ipv6 public6in4
create vlan private-ipv6
configure vlan private-ipv6 add port 2 untagged
configure vlan private-ipv6 ipaddress 2001:db8:2::1/64
enable ipforwarding ipv6 private-ipv6
configure iproute add 2001:db8:1::/64 2001:db8:a::1
628
Host 1
Router 1
2002:c0a8:101::204:96ff:fe1f:a52a/48
2002:c0a8:101::2/48
1 2002:c0a8:101::1/16
192.168.1.1/24
IPv6
IPv4
Router 2
IPv6
2002:a00:1::1/16
10.0.0.1/24
2002:a00:1:1::1/64
2002:a00:1:2::1/64
1
2
Host 2
2002:a00:1:1:204:96ff:fe1f:a432/64
Host 3
2002:a00:1:2:201:30ff:fe00:c200/64
EX_109
In Figure 78, Router 1 has an interface to an IPv4 region with the address 192.168.1.1 (for this example
we are using private IPv4 addresses, but to tunnel across the Internet, you would use a public address).
Router 2 has an IPv4 interface of 10.0.0.1. The IPv4 interface must be created before the tunnel is
configured and cannot be deleted until the tunnel is deleted.
The IPv6 endpoints of 6to4 tunnels must follow the standard 6to4 address requirement. The address
must be of the form 2002:<IPv4_source_endpoint>::/16, where <IPv4_source_endpoint> is replaced by
the IPv4 source address of the endpoint, in hexadecimal, colon separated form. For example, for a
tunnel endpoint located at IPv4 address 10.20.30.40, the tunnel address would be 2002:0a14:1e28::/16. In
hex, 10 is 0a, 20 is 14, 30 is 1e and 40 is 28.
This example shows a simple setup on the Router 1 side (one big /48 IPv6 routing domain with no
subnets), and a slightly more complex setup on the Router 2 side (two subnets :0001: and :0002: that are
/64 in length). Hosts 1, 2, and 3 will communicate using their global 2002: addresses.
The hosts in this example configure themselves using the EUI64 interface identifier derived from their
MAC addresses. Refer to your host OS vendors documentation for configuring IPv6 addresses and
routes.
629
Router 1
configure vlan default delete port all
create vlan public-ipv4
configure vlan public-ipv4 add port 1 untagged
configure vlan public-ipv4 ipaddress 192.168.1.1/24
create tunnel public6to4 6to4 source 192.168.1.1
configure tunnel public6to4 ipaddress 2002:c0a8:0101::1/16
enable ipforwarding ipv6 public6to4
create vlan private-ipv6
configure vlan private-ipv6 add port 2 untagged
configure vlan private-ipv6 ipaddress 2002:c0a8:0101::2/48
enable ipforwarding ipv6 private-ipv6
Router 2
configure vlan default delete port all
create vlan public-ipv4
configure vlan public-ipv4 add port 1 untagged
configure vlan public-ipv4 ipaddress 10.0.0.1/24
create tunnel public6to4 6to4 source 10.0.0.1
configure tunnel public6to4 ipaddress 2002:0a00:0001::1/16
enable ipforwarding ipv6 public6to4
create vlan private-ipv6-sub1
configure vlan private-ipv6-sub1 add port 2 untagged
configure vlan private-ipv6-sub1 ipaddress 2002:0a00:0001:0001::1/64
enable ipforwarding ipv6 private-ipv6-sub1
create vlan private-ipv6-sub2
configure vlan private-ipv6-sub2 add port 3 untagged
configure vlan private-ipv6-sub2 ipaddress 2002:0a00:0001:0002::1/64
enable ipforwarding ipv6 private-ipv6-sub2
Host Configurations
The IPv6 addresses of these hosts are based on their MAC address-derived EUI64 interface identifiers
and the address prefixes for their subnets. Each host must also have a static route configured on it for
6to4 addresses.
Host 1:
630
MAC address00:04:96:1F:A5:2A
IPv6 address2002:c0a8:0101::0204:96ff:fe1f:a52a/48
MAC address00:04:96:1F:A4:32
IP address2002:0a00:0001:0001:0204:96ff:fe1f:a432/64
Host 3:
MAC address00:01:30:00:C2:00
IP address2002:0a00:0001:0002:0201:30ff:fe00:c200/64
631
632
26 RIP
This chapter describes the following topics:
This chapter assumes that you are already familiar with IP unicast routing. If not, refer to the following
publications for additional information:
Overview
The switch supports the use of two interior gateway protocols (IGPs); the Routing Information Protocol
(RIP), and the Open Shortest Path First (OSPF) protocol.
RIP is a distance-vector protocol, based on the Bellman-Ford (or distance-vector) algorithm. The
distance-vector algorithm has been in use for many years and is widely deployed and understood.
OSPF is a link-state protocol, based on the Dijkstra link-state algorithm. OSPF is a newer IGP and solves
a number of problems associated with using RIP on todays complex networks.
NOTE
RIP and OSPF can be enabled on a single VLAN.
RIP is described in this chapter, and OSPF is described in Chapter 28, OSPF.
633
RIP
A large amount of bandwidth taken up by periodic broadcasts of the entire routing table
Slow convergence
Faster convergence
Support for load balancing to multiple routers based on the actual cost of the link
Support for hierarchical topologies where the network is divided into areas
Overview of RIP
RIP is an IGP first used in computer routing in the Advanced Research Projects Agency Network
(ARPAnet) as early as 1969. It is primarily intended for use in homogeneous networks of moderate size.
To determine the best path to a distant network, a router using RIP always selects the path that has the
least number of hops. Each router that data must traverse is considered to be one hop.
Routing Table
The routing table in a router using RIP contains an entry for every known destination network. Each
routing table entry contains the following information:
Timer that tracks the amount of time since the entry was last updated
The router exchanges an update message with each neighbor every 30 seconds (default value), or when
there is a change to the overall routed topology (also called triggered updates). If a router does not receive
an update message from its neighbor within the route timeout period (180 seconds by default), the
router assumes the connection between it and its neighbor is no longer available.
634
Overview of RIP
Split Horizon
Split horizon is a scheme for avoiding problems caused by including routes in updates sent to the
router from which the route was learned. Split horizon omits routes learned from a neighbor in updates
sent to that neighbor.
Poison Reverse
Like split horizon, poison reverse is a scheme for eliminating the possibility of loops in the routed
topology. In this case, a router advertises a route over the same interface that supplied the route, but the
route uses a hop count of 16, which defines that router as unreachable.
Triggered Updates
Triggered updates occur whenever a router changes the metric for a route. The router is required to
send an update message immediately, even if it is not yet time for a regular update message to be sent.
This generally results in faster convergence, but may also result in more RIP-related traffic.
Support for next-hop addresses, which allows for optimization of routes in certain environments.
Multicasting.
RIP version 2 packets can be multicast instead of being broadcast, reducing the load on hosts that do
not support routing protocols.
NOTE
If you are using RIP with supernetting/Classless Inter-Domain Routing (CIDR), you must use RIPv2 only.
635
RIP
Route Redistribution
More than one routing protocol can be enabled simultaneously on the switch. Route redistribution
allows the switch to exchange routes, including static routes, between the routing protocols. Figure 79 is
an example of route redistribution between an OSPF AS and a RIP AS.
OSPF AS
Backbone Area
0.0.0.0
ABR
Area
121.2.3.4
ASBR
ASBR
RIP AS
EX_046
636
These commands enable or disable the exporting of static, direct, and OSPF-learned routes into the RIP
domain. You can choose which types of OSPF routes are injected, or you can simply choose ospf, which
will inject all learned OSPF routes regardless of type. The default setting is disabled.
Finance
IP address 192.207.35.1.
Personnel
IP address 192.207.36.1.
MyCompany
Port-based VLAN.
This example does use protocol-sensitive VLANs that only admit IP packets. This is not a common
requirement for most networks. In most cases, VLANs will admit different types of packets to be
forwarded to the hosts and servers on the network.
637
RIP
192.207.35.1
192.207.36.1
MyCompany
192.207.35.0
Finance
192.207.36.0
Personnel
IP
NetBIOS
IP
NetBIOS
IP
NetBIOS
IP
NetBIOS
= IP traffic
= NetBIOS traffic
EX_047
The stations connected to the system generate a combination of IP traffic and NetBIOS traffic. The IP
traffic is filtered by the protocol-sensitive VLANs. All other traffic is directed to the VLAN MyCompany.
In this configuration, all IP traffic from stations connected to slots 1 and 3 have access to the router by
way of the VLAN Finance. Ports on slots 2 and 4 reach the router by way of the VLAN Personnel. All
other traffic (NetBIOS) is part of the VLAN MyCompany.
More commonly, NetBIOS traffic would be allowed on the Finance and Personnel VLANs, but this
example shows how to exclude that traffic. To allow the NetBIOS traffic (or other type of traffic) along
with the IP traffic, remove the configure finance protocol ip and configure Personnel
protocol ip commands from the example.
The example in Figure 80 is configured as follows:
create vlan Finance
create vlan Personnel
create vlan MyCompany
configure Finance protocol ip
configure Personnel protocol ip
configure Finance add port 1:*,3:*
configure Personnel add port 2:*,4:*
configure MyCompany add port all
configure Finance ipaddress 192.207.35.1
configure Personnel ipaddress 192.207.36.1
638
enable ipforwarding
configure rip add vlan all
enable rip
639
RIP
640
27 RIPng
This chapter describes the following topics:
This chapter assumes that you are already familiar with IP unicast routing. If not, refer to the following
publications for additional information:
Overview
Routing Information Protocol Next Generation (RIPng) is an interior gateway protocol (IGP) developed
for IPv6 networks. The analogous protocol used in IPv4 networks is called Routing Information Protocol
(RIP). Like RIP, RIPng is a relatively simple protocol for the communication of routing information
among routers. Many concepts and features of RIPng are directly parallel to those same features in RIP.
RIPng is a distance-vector protocol, based on the Bellman-Ford (or distance-vector) algorithm. The
distance-vector algorithm has been in use for many years and is widely deployed and understood. The
other common IGP for IPv6 is OSPFv3, a link-state protocol.
NOTE
RIPng and OSPFv3 can be enabled on a single VLAN.
RIPng is described in this chapter, and OSPFv3 is described in Chapter 29, OSPFv3.
641
RIPng
A large amount of bandwidth taken up by periodic broadcasts of the entire routing table
Slow convergence
Faster convergence
Support for load balancing to multiple routers based on the actual cost of the link
Support for hierarchical topologies where the network is divided into areas
Overview of RIPng
RIPng is primarily intended for use in homogeneous networks of moderate size.
To determine the best path to a distant network, a router using RIPng always selects the path that has
the least number of hops. Each router that data must traverse is considered to be one hop.
Routing Table
The routing table in a router using RIPng contains an entry for every known destination network. Each
routing table entry contains the following information:
IP address of the next hop router, if the destination is not directly connected
Timer that tracks the amount of time since the entry was last updated
A flag that indicates if the entry is a new one since the last update
The source of the route, for example, static, RIPng, OSPFv3, etc.
The router exchanges an update message with each neighbor every 30 seconds (default value), or when
there is a change to the overall routed topology (also called triggered updates). If a router does not receive
an update message from its neighbor within the route timeout period (180 seconds by default), the
router assumes the connection between it and its neighbor is no longer available.
642
Route Redistribution
Split Horizon
Split horizon is a scheme for avoiding problems caused by including routes in updates sent to the
router from which the route was learned. Split horizon omits routes learned from a neighbor in updates
sent to that neighbor.
Poison Reverse
Like split horizon, poison reverse is a scheme for eliminating the possibility of loops in the routed
topology. In this case, a router advertises a route over the same interface that supplied the route, but the
route uses a hop count of 16, which defines that router as unreachable.
Triggered Updates
Triggered updates occur whenever a router changes the metric for a route. The router is required to
send an update message immediately, even if it is not yet time for a regular update message to be sent.
This generally results in faster convergence, but may also result in more RIPng-related traffic.
Route Redistribution
More than one routing protocol can be enabled simultaneously on the switch. Route redistribution
allows the switch to exchange routes, including static routes, between the routing protocols. Route
redistribution is also called route export.
643
RIPng
These commands enable or disable the exporting of static, direct, and OSPF-learned routes into the
RIPng domain. You can choose which types of OSPF routes are injected, or you can simply choose ospf,
which will inject all learned OSPF routes regardless of type. The default setting is disabled.
Finance
IP address 2001:db8:35::1/48.
Personnel
IP address 2001:db8:36::1/48.
MyCompany
Port-based VLAN.
The stations connected to the system generate a combination of IPv6 traffic and NetBIOS traffic.
In this configuration, all traffic from stations connected to slots 1 and 3 have access to the router by way
of the VLAN Finance. Ports on slots 2 and 4 reach the router by way of the VLAN Personnel. All traffic
(NetBIOS and IPv6) is part of the VLAN MyCompany.
The example is configured as follows:
create vlan Finance
create vlan Personnel
create vlan MyCompany
configure Finance add port 1:*,3:*
configure Personnel add port 2:*,4:*
configure MyCompany add port all
configure Finance ipaddress 2001:db8:35::1/48
configure Personnel ipaddress 2001:db8:36::1/48
644
645
RIPng
646
28 OSPF
This chapter describes the following topics:
This chapter assumes that you are already familiar with IP unicast routing. If not, refer to the following
publications for additional information:
Overview of OSPF
Open Shortest Path First (OSPF) is a link state protocol that distributes routing information between
routers belonging to a single IP domain; the IP domain is also known as an autonomous system (AS). In a
link-state routing protocol, each router maintains a database describing the topology of the AS. Each
participating router has an identical database maintained from the perspective of that router.
From the link state database (LSDB), each router constructs a tree of shortest paths, using itself as the
root. The shortest path tree provides the route to each destination in the AS. When several equal-cost
routes to a destination exist, traffic can be distributed among them. The cost of a route is described by a
single metric.
OSPF is an interior gateway protocol (IGP), as is the other common IGP, RIP. OSPF and RIP are
compared in Chapter 26, RIP.
Licensing
To use the complete OSPF functionality, you must have a Core license installed on your switch. The
BlackDiamond 10K ships with a Core, or Advanced Core license. Other platforms can be upgraded to a
Core license. See Software Licensing on page 34 for more information about licensing.
A subset of OSPF, called OSPF Edge Mode, is available with an Advanced Edge license.
647
OSPF
At most, two Active OSPF VLAN interfaces are permitted. There is no restriction on the number of
Passive interfaces.
The OSPF Priority on VLANs is 0, and is not configurable. This prevents the system from acting as a
DR or BDR
Description
Router LSA
Network LSA
Summary LSA
AS summary LSA
AS external LSA
Link localOpaque
10
Area scopingOpaque
11
AS scopingOpaque
Database Overflow
The OSPF database overflow feature allows you to limit the size of the LSDB and to maintain a
consistent LSDB across all the routers in the domain, which ensures that all routers have a consistent
view of the network.
Consistency is achieved by:
Where:
<number>Specifies the number of external LSAs that the system supports before it goes into
overflow state. A limit value of 0 disables the functionality.
When the LSDB size limit is reached, OSPF database overflow flushes LSAs from the LSDB. OSPF
database overflow flushes the same LSAs from all the routers, which maintains consistency.
648
Overview of OSPF
timeoutSpecifies the timeout, in seconds, after which the system ceases to be in overflow state. A
timeout value of 0 leaves the system in overflow state until OSPF is disabled and re-enabled.
Opaque LSAs
Opaque LSAs are a generic OSPF mechanism used to carry auxiliary information in the OSPF database.
Opaque LSAs are most commonly used to support OSPF traffic engineering.
Normally, support for opaque LSAs is autonegotiated between OSPF neighbors. In the event that you
experience interoperability problems, you can disable opaque LSAs across the entire system using the
following command:
disable ospf capability opaque-lsa
To re-enable opaque LSAs across the entire system, use the following command:
enable ospf capability opaque-lsa
If your network uses opaque LSAs, Extreme Networks recommends that all routers on your OSPF
network support opaque LSAs. Routers that do not support opaque LSAs do not store or flood them. At
minimum a well interconnected subsection of your OSPF network must support opaque LSAs to
maintain reliability of their transmission.
649
OSPF
Since a router can act as a restart helper router to multiple neighbors, you will specify which neighbors
to help. To configure a router to act as a graceful OSPF restart helper, use the following command:
configure ospf [vlan [all | <vlan-name>] | area <area-identifier> | virtual-link
<router-identifier> <area-identifier>] restart-helper [none | planned | unplanned |
both]
The graceful restart period sent out to helper routers can be configured with the following command:
configure ospf restart grace-period <seconds>
By default, a helper router will terminate graceful restart if received LSAs would affect the restarting
router. This will occur when the restart-helper receives an LSA that will be flooded to the restarting
router or when there is a changed LSA on the restarting router's retransmission list when graceful
restart is initiated. To disable this behavior, use the following command:
disable ospf [vlan [all | <vlan-name>] | area <area-identifier> | virtual-link
<router-identifier> <area-identifier>] restart-helper-lsa-check
Areas
OSPF allows parts of a network to be grouped together into areas. The topology within an area is
hidden from the rest of the AS. Hiding this information enables a significant reduction in LSA traffic
and reduces the computations needed to maintain the LSDB. Routing within the area is determined
only by the topology of the area.
The three types of routers defined by OSPF are as follows:
650
Internal router (IR)An internal router has all of its interfaces within the same area.
Area border router (ABR)An ABR has interfaces in multiple areas. It is responsible for exchanging
summary advertisements with other ABRs.
Autonomous system border router (ASBR)An ASBR acts as a gateway between OSPF and other
routing protocols, or other autonomous systems.
Overview of OSPF
The backbone allows summary information to be exchanged between ABRs. Every ABR hears the area
summaries from all other ABRs. The ABR then forms a picture of the distance to all networks outside of
its area by examining the collected advertisements and adding in the backbone distance to each
advertising router.
When a VLAN is configured to run OSPF, you must configure the area for the VLAN. If you want to
configure the VLAN to be part of a different OSPF area, use the following command:
configure ospf vlan <vlan-name> area <area-identifier>
If this is the first instance of the OSPF area being used, you must create the area first using the
following command:
create ospf area <area-identifier>
Stub Areas
OSPF allows certain areas to be configured as stub areas. A stub area is connected to only one other area.
The area that connects to a stub area can be the backbone area. External route information is not
distributed into stub areas. Stub areas are used to reduce memory consumption and computational
requirements on OSPF routers. Use the following command to configure an OSPF area as a stub area:
configure ospf area <area-identifier> stub [summary | nosummary] stub-default-cost
<cost>
Not-So-Stubby-Areas
Not-so-stubby-areas (NSSAs) are similar to the existing OSPF stub area configuration option but have
the following two additional capabilities:
External routes originating from an ASBR connected to the NSSA can be advertised within the
NSSA.
External routes originating from the NSSA can be propagated to other areas, including the backbone
area.
The command line interface (CLI) command to control the NSSA function is similar to the command
used for configuring a stub area, as follows:
configure ospf area <area-identifier> nssa [summary | nosummary] stub-default-cost
<cost> {translate}
The translate option determines whether type 7 LSAs are translated into type 5 LSAs. When
configuring an OSPF area as an NSSA, the translate should only be used on NSSA border routers,
where translation is to be enforced. If translate is not used on any NSSA border router in a NSSA, one
of the ABRs for that NSSA is elected to perform translation (as indicated in the NSSA specification). The
651
OSPF
option should not be used on NSSA internal routers. Doing so inhibits correct operation of the election
algorithm.
Normal Area
A normal area is an area that is not:
Area 0
Stub area
NSSA
Virtual links can be configured through normal areas. External routes can be distributed into normal
areas.
Virtual Links
In the situation when a new area is introduced that does not have a direct physical attachment to the
backbone, a virtual link is used. A virtual link provides a logical path between the ABR of the
disconnected area and the ABR of the normal area that connects to the backbone. A virtual link must be
established between two ABRs that have a common area, with one ABR connected to the backbone.
Figure 81 illustrates a virtual link.
NOTE
Virtual links cannot be configured through a stub or NSSA area.
ABR
Area 2
ABR
Area 1
Area 0
EX_044
652
Overview of OSPF
Virtual links are also used to repair a discontiguous backbone area. For example, in Figure 82, if the
connection between ABR1 and the backbone fails, the connection using ABR2 provides redundancy so
that the discontiguous area can continue to communicate with the backbone using the virtual link.
Area 2
ABR 1
ABR 2
Area 1
Area 3
Area 0
EX_045
Point-to-Point Support
You can manually configure the OSPF link type for a VLAN. Table 74 describes the link types.
Number of Routers
Description
Auto
Varies
Broadcast
Any
Point-to-point
Up to 2
Passive
NOTE
The number of routers in an OSPF point-to-point link is determined per VLAN, not per link.
653
OSPF
NOTE
All routers in the VLAN must have the same OSPF link type. If there is a mismatch, OSPF attempts to operate, but
it may not be reliable.
Route Redistribution
More than one routing protocol can be enabled simultaneously on the switch. Route redistribution
allows the switch to exchange routes, including static routes, between the routing protocols. Figure 83 is
an example of route redistribution between an OSPF AS and a RIP AS.
OSPF AS
Backbone Area
0.0.0.0
ABR
Area
121.2.3.4
ASBR
ASBR
RIP AS
EX_046
654
Configuring OSPF
These commands enable or disable the exporting of RIP, static, and direct routes by way of LSA to other
OSPF routers as AS-external type 1 or type 2 routes. The default setting is disabled.
The cost metric is inserted for all Border Gateway Protocol (BGP), RIP, static, and direct routes injected
into OSPF. If the cost metric is set to 0, the cost is inserted from the route. For example, in the case of
BGP export, the cost equals the multiple exit discriminator (MED) or the path length. The tag value is
used only by special routing applications. Use 0 if you do not have specific requirements for using a
tag. (The tag value in this instance has no relationship with IEEE 802.1Q VLAN tagging.)
The same cost, type, and tag values can be inserted for all the export routes, or policies can be used for
selective insertion. When a policy is associated with the export command, the policy is applied on every
exported route. The exported routes can also be filtered using policies.
Verify the configuration using the command:
show ospf
Configuring OSPF
Each switch that is configured to run OSPF must have a unique router ID. Extreme Networks
recommends that you manually set the router ID of the switches participating in OSPF, instead of
having the switch automatically choose its router ID based on the highest interface IP address. Not
performing this configuration in larger, dynamic environments could result in an older LSDB remaining
in use.
655
OSPF
CAUTION
Do not configure OSPF timers unless you are comfortable exceeding OSPF specifications. Non-standard settings may
not be reliable under all circumstances.
Retransmit intervalThe length of time that the router waits before retransmitting an LSA that is not
acknowledged. If you set an interval that is too short, unnecessary retransmissions result. The
default value is 5 seconds.
Transit delayThe length of time it takes to transmit an LSA packet over the interface. The transit
delay must be greater than 0.
Hello intervalThe interval at which routers send hello packets. Shorter times allow routers to
discover each other more quickly but also increase network traffic. The default value is 10 seconds.
Dead router wait interval (Dead Interval)The interval after which a neighboring router is declared
down because hello packets are no longer received from the neighbor. This interval should be a
multiple of the hello interval. The default value is 40 seconds.
Router wait interval (Wait Timer Interval)The interval between the interface coming up and the
election of the DR and BDR. This interval should be greater than the hello interval. If this time is
close to the hello interval, the network synchronizes very quickly but might not elect the correct DR
or BDR. The default value is equal to the dead router wait interval.
NOTE
The OSPF standard specifies that wait times are equal to the dead router wait interval.
656
Area 0
IR 2
10.0.1.1
IR 1
10.0.1.2
10.0.3.2
ABR 2
10.0.3.1
HQ
3
0_
0_
_1
HQ
_1
0_
0_
2
10.0.2.2
Headquarters
ABR 1
10.0.2.1
161.48.2.2
Los Angeles
LA
Ch
i_1
60
_2
8_
6_
_4
Virtual link
161.48.2.1
61
26
160.26.26.1
_1
160.26.25.1
160.26.26.2
160.26.25.2
Chicago
Area 5
Area 6 (stub)
EX_040
Area 0 is the backbone area. It is located at the headquarters and has the following characteristics:
Area 5 is connected to the backbone area by way of ABR1 and ABR2. It is located in Chicago and has
the following characteristics:
657
OSPF
Area 6 is a stub area connected to the backbone by way of ABR1. It is located in Los Angeles and has
the following characteristics:
Two router configurations for the example in Figure 84 are provided in the following section.
vlan
vlan
vlan
vlan
configure
configure
configure
configure
HQ_10_0_2
HQ_10_0_3
LA_161_48_2
Chi_160_26_26
vlan
vlan
vlan
vlan
ospf
ospf
ospf
ospf
ospf
enable ospf
658
The detail option displays information about all OSPF areas in a detail format.
To display information about OSPF interfaces for an area, a VLAN, or for all interfaces, use the
following command:
show ospf interfaces {vlan <vlan-name> | area <area-identifier>}
The detail option displays information about all OSPF interfaces in a detail format.
ExtremeWare XOS provides several filtering criteria for the show ospf lsdb command. You can
specify multiple search criteria, and only those results matching all of the criteria are displayed. This
allows you to control the displayed entries in large routing tables.
To display the current link-state database, use the following command:
show ospf lsdb {detail | stats} {area [<area-identifier> | all]} {{lstype} [<lstype> |
all]} {lsid <lsid-address>{<lsid-mask>}} {routerid <routerid-address> {<routeridmask>}} {interface[[<ip-address>{<ip-mask>} | <ipNetmask>] | vlan <vlan-name>]}
The detail option displays all fields of matching LSAs in a multiline format. The summary option
displays several important fields of matching LSAs, one line per LSA. The stats option displays the
number of matching LSAs but not any of their contents. If not specified, the default is to display in the
summary format.
A common use of this command is to omit all optional parameters, resulting in the following shortened
form:
show ospf lsdb
The shortened form displays LSAs from all areas and all types in a summary format.
659
OSPF
660
29 OSPFv3
This chapter describes the following topics:
Overview of OSPFv3
Open Shortest Path First (OSPF) is a link state protocol that distributes routing information between
routers belonging to a single IP domain; the IP domain is also known as an autonomous system (AS). In a
link-state routing protocol, each router maintains a database describing the topology of the AS. Each
participating router has an identical database for an area maintained from the perspective of that router.
From the link state database (LSDB), each router constructs a tree of shortest paths, using itself as the
root. The shortest path tree provides the route to each destination in the AS. When several equal-cost
routes to a destination exist, traffic can be distributed among them. The cost of a route is described by a
single metric.
OSPFv3 supports IPv6, and uses commands only slightly modified from that used to support IPv4.
OSPFv3 has retained the use of the 4-byte, dotted decimal numbers for router IDs, LSA IDs, and area
IDs.
OSPFv3 is an interior gateway protocol (IGP), as is the other common IGP for IPv6, RIPng. OSPFv3 and
RIPng are compared in Chapter 27, RIPng on page 641.
Licensing
To use OSPFv3, you must have a Core license installed on your switch. The BlackDiamond 10K ships
with a Core, or Advanced Core license. Other platforms can be upgraded to a Core license. See the
section Software Licensing on page 34 for more information about licensing.
Description
0x0008
Link LSA
0x2001
Router LSA
661
OSPFv3
Description
0x2002
Network LSA
0x2003
Inter-Area-Prefix LSA
0x2004
Inter-Area-Router LSA
0x2009
Intra-Area-Prefix LSA
0x4005
AS external LSA
Areas
OSPFv3 allows parts of a network to be grouped together into areas. The topology within an area is
hidden from the rest of the AS. Hiding this information enables a significant reduction in LSA traffic
and reduces the computations needed to maintain the LSDB. Routing within the area is determined
only by the topology of the area.
The three types of routers defined by OSPFv3 are as follows:
Internal router (IR)An internal router has all of its interfaces within the same area.
Area border router (ABR)An ABR has interfaces in multiple areas. It is responsible for exchanging
summary advertisements with other ABRs.
Autonomous system border router (ASBR)An ASBR acts as a gateway between OSPFv3 and other
routing protocols, or other autonomous systems.
The backbone allows summary information to be exchanged between ABRs. Every ABR hears the area
summaries from all other ABRs. The ABR then forms a picture of the distance to all networks outside of
its area by examining the collected advertisements and adding in the backbone distance to each
advertising router.
When a VLAN is configured to run OSPFv3, you must configure the area for the VLAN. If you want to
configure the VLAN to be part of a different OSPFv3 area, use the following command:
configure ospfv3 {domain <domainName>} [vlan <vlan-name> | tunnel <tunnel-name>] area
<area-identifier>
If this is the first instance of the OSPFv3 area being used, you must create the area first using the
following command:
create ospfv3 {domain <domainName>} area <area-identifier>
662
Overview of OSPFv3
Stub Areas
OSPFv3 allows certain areas to be configured as stub areas. A stub area is connected to only one other
area. The area that connects to a stub area can be the backbone area. External route information is not
distributed into stub areas. Stub areas are used to reduce memory consumption and computational
requirements on OSPFv3 routers. To configure an OSPFv3 area as a stub area, use the following
command:
configure ospfv3 {domain <domainName>} area <area-identifier> stub [summary |
nosummary] stub-default-cost <cost>
Not-So-Stubby-Areas
Not-so-stubby-areas (NSSAs) are not supported currently in the ExtremeWare XOS implementation of
OSPFv3.
Normal Area
A normal area is an area that is not:
Area 0
Stub area
NSSA
Virtual links can be configured through normal areas. External routes can be distributed into normal
areas.
Virtual Links
In the situation when a new area is introduced that does not have a direct physical attachment to the
backbone, a virtual link is used. A virtual link provides a logical path between the ABR of the
disconnected area and the ABR of the normal area that connects to the backbone. A virtual link must be
established between two ABRs that have a common area, with one ABR connected to the backbone.
Figure 85 illustrates a virtual link.
NOTE
Virtual links cannot be configured through a stub or NSSA area.
663
OSPFv3
ABR
Area 2
ABR
Area 1
Area 0
EX_044
Virtual links are also used to repair a discontiguous backbone area. For example, in Figure 86, if the
connection between ABR1 and the backbone fails, the connection using ABR2 provides redundancy so
that the discontiguous area can continue to communicate with the backbone using the virtual link.
Area 2
ABR 1
ABR 2
Area 1
Area 3
Area 0
EX_045
Link-Type Support
You can manually configure the OSPFv3 link type for a VLAN. Table 76 describes the link types.
664
Link Type
Number of Routers
Description
Auto
Varies
Route Redistribution
Number of Routers
Description
Broadcast
Any
Passive
NOTE
The number of routers in an OSPFv3 point-to-point link is determined per VLAN, not per link.
NOTE
All routers in the VLAN must have the same OSPFv3 link type. If there is a mismatch, OSPFv3 attempts to operate,
but it may not be reliable.
Route Redistribution
More than one routing protocol can be enabled simultaneously on the switch. Route redistribution
allows the switch to exchange routes, including static routes, between the routing protocols. Figure 87 is
an example of route redistribution between an OSPFv3 AS and a RIPng AS.
665
OSPFv3
OSPF AS
Backbone Area
0.0.0.0
ABR
Area
121.2.3.4
ASBR
ASBR
RIP AS
EX_046
These commands enable or disable the exporting of RIPng, static, and direct routes by way of LSA to
other OSPFv3 routers as AS-external type 1 or type 2 routes. The default setting is disabled.
666
Route Redistribution
The cost metric is inserted for all RIPng, static, and direct routes injected into OSPFv3. If the cost metric
is set to 0, the cost is inserted from the route. The tag value is used only by special routing applications.
Use 0 if you do not have specific requirements for using a tag. (The tag value in this instance has no
relationship with IEEE 802.1Q VLAN tagging.)
The same cost, type, and tag values can be inserted for all the export routes, or policies can be used for
selective insertion. When a policy is associated with the export command, the policy is applied on every
exported route. The exported routes can also be filtered using policies.
Verify the configuration using the command:
show ospfv3 {domain <domainName>}
OSPFv3 Timers
Configuring OSPFv3 timers on a per area basis is a shortcut to applying the timers to each VLAN in the
area at the time of configuration. If you add more VLANs to the area, you must configure the timers for
the new VLANs explicitly. Use the command:
configure ospfv3 {domain <domainName>} [vlan <vlan-name> | tunnel <tunnel-name> |
[vlan | tunnel] all] timer {retransmit-interval} <retransmit-interval> {transit-delay}
<transit-delay> {hello-interval} <hello-interval> {dead-interval} <dead-interval>
667
OSPFv3
Area 0.0.0.0
2001:db8:4444:6666::2/64
to-r2
Router 1
2001:db8:4444:6666::1/64
2001:db8:3333:5555::1/64
Router 3
to-r3
2001:db8:3333:5555::2/64
Area 0.0.0.1
EX_107
In Figure 88 there are three Extreme Networks switches running ExtremeWare XOS images that have
support for OSPFv3. Router 1 is an area border router and is connected to two other switches Router 2
and Router 3. Router 1 runs OSPFv3 on both the links connecting it to Router 2 and Router 3.
The router configurations for the example in Figure 88 are provided in the following section. After
doing all the configurations, Router 1 will establish OSPFv3 adjacency with Router 2 and Router 3. They
will also exchange the various link state databases.
668
669
OSPFv3
670
This chapter describes how to configure the Border Gateway Protocol (BGP), an exterior routing
protocol available on the switch.
For more information on BGP, refer to the following documents:
RFC 2385Protection of BGP Sessions via the TCP MD5 Signature Option
NOTE
Although the CLI commands are available, this release of ExtremeWare XOS does not support the MBGP/Routerefresh features.
Licensing
BGP requires a Core license, at a minimum. The BGP process will not spawn without the required
license level. The MSM-1XL is shipped with an Advanced Core license and the MSM-1 is shipped with
a Core license. Other platforms can be upgraded to a Core license. See Software Licensing on page 34
for more information about licensing.
671
Overview
BGP is an exterior routing protocol that was developed for use in TCP/IP networks. The primary
function of BGP is to allow different autonomous systems (ASs) to exchange network reachability
information.
An AS is a set of routers that are under a single technical administration. This set of routers uses a
different routing protocol, for example Open Shortest Path First (OSPF), for intra-AS routing. One or
more routers in the AS are configured to be border routers, exchanging information with other border
routers (in different ASs) on behalf of all of the intra-routers.
BGP can be used as an exterior gateway protocol (referred to as EBGP), or it can be used within an AS
as an interior gateway protocol (referred to as IBGP).
BGP Attributes
The following BGP attributes are supported by the switch:
OriginDefines the origin of the route. Possible values are Interior Gateway Protocol (IGP), Exterior
Gateway Protocol (EGP), and incomplete.
Next_hopThe IP address of the next hop BGP router to reach the destination listed in the NLRI
field.
Local_PreferenceUsed to advertise this routers degree of preference to other routers within the
AS.
Atomic_aggregateIndicates that the sending border router has used a route aggregate prefix in the
route update.
AggregatorIdentifies the BGP router AS number and IP address that performed route aggregation.
Cluster_IDSpecifies a 4-byte field used by a route reflector to recognize updates from other route
reflectors in the same cluster.
Originator_IDSpecifies the router ID of the originator of the route in the local AS.\
BGP Communities
A BGP community is a group of BGP destinations that require common handling. ExtremeWare XOS
supports the following well-known BGP community attributes:
672
no-export
no-advertise
no-export-subconfed
BGP Features
BGP Features
This section describes the following BGP features supported by ExtremeWare XOS:
Route Reflectors
Another way to overcome the difficulties of creating a fully meshed AS is to use route reflectors. Route
reflectors allow a single router to serve as a central routing point for the AS.
A cluster is formed by the route reflector and its client routers. Peer routers that are not part of the
cluster must be fully meshed according to the rules of BGP.
A BGP cluster, including the route reflector and its clients, is shown in Figure 89.
10.0.0.1
2.2.2.2
Non-client
20.0.0.1
Client
10.0.0.2
20.0.0.2
30.0.0.2
4.4.4.4
30.0.0.1
Client
Route Reflector
Cluster
EX_042
The topology shown in Figure 89 minimizes the number of BGP peering sessions required in an AS by
using route reflectors.
In this example, although the BGP speakers 3.3.3.3 and 4.4.4.4 do not have a direct BGP peering session
between them, these speakers still receive routes from each other indirectly through 2.2.2.2. The router
673
To configure router 2.2.2.2, the route reflector, use the following commands:
create vlan to_nc
configure vlan to_nc add port 1:1
configure vlan to_nc ipaddress 10.0.0.2/24
enable ipforwarding vlan to_nc
create vlan to_c1
configure vlan to_c1 add port 1:2
configure vlan to_c1 ipaddress 20.0.0.2/24
enable ipforwarding vlan to_c1
create vlan to_c2
configure vlan to_c2 add port 1:2
configure vlan to_c2 ipaddress 30.0.0.2/24
enable ipforwarding vlan to_c2
configure bgp router 2.2.2.2
configure bgp as-number 100
create bgp neighbor 10.0.0.1 remote-as 100
create bgp neighbor 20.0.0.1 remote-as 100
create bgp neighbor 30.0.0.1 remote-as 100
configure bgp neighbor 20.0.0.1 route-reflector-client
configure bgp neighbor 30.0.0.1 route-reflector-client
enable bgp neighbor all
enable bgp
674
BGP Features
To configure router 4.4.4.4, use the following commands:
create vlan to_rr
configure vlan to_rr add port 1:1
configure vlan to_rr ipaddress 30.0.0.1/24
enable ipforwarding vlan to_rr
configure bgp router 4.4.4.4
configure bgp as-number 100
create bgp neighbor 30.0.0.2 remote-as 100
enable bgp neighbor all
enable bgp
Route Confederations
BGP requires networks to use a fully meshed router configuration. This requirement does not scale well,
especially when BGP is used as an IGP. One way to reduce the size of a fully meshed AS is to divide the
AS into multiple sub-ASs and to group these sub-ASs into a routing confederation. Within the
confederation, each sub-AS must be fully meshed. The confederation is advertised to other networks as
a single AS.
AS 200
SubAS 65001
A
EBGP
192.1.1.6/30
192.1.1.5/30
192.1.1.17/30
192.1.1.9/30
192.1.1.22/30
IBGP
192.1.1.21/30
192.1.1.18/30
EBGP
EBGP
192.1.1.13/30
192.1.1.14/30
IBGP
192.1.1.10/30
SubAS 65002
EX_043
In this example, AS 200 has five BGP speakers. Without a confederation, BGP would require that the
routes in AS 200 be fully meshed. Using the confederation, AS 200 is split into two sub-ASs: AS65001
and AS65002. Each sub-AS is fully meshed, and IBGP is running among its members. EBGP is used
between sub-AS 65001 and sub-AS 65002. Router B and router D are EBGP peers. EBGP is also used
between the confederation and outside ASs.
675
676
BGP Features
To configure router C, use the following commands:
create vlan ca
configure vlan ca add port 1
configure vlan ca ipaddress 192.1.1.18/30
enable ipforwarding vlan ca
configure ospf add vlan ca area 0.0.0.0
create vlan cb
configure vlan cb add port 2
configure vlan cb ipaddress 192.1.1.21/30
enable ipforwarding vlan cb
configure ospf add vlan cb area 0.0.0.0
enable ospf
configure bgp as-number 65001
configure bgp routerid 192.1.1.21
configure bgp confederation-id 200
enable bgp
create bgp neighbor 192.1.1.22 remote-AS-number 65001
create bgp neighbor 192.1.1.17 remote-AS-number 65001
enable bgp neighbor all
677
Route Aggregation
Route aggregation is the process of combining the characteristics of several routes so that they are
advertised as a single route. Aggregation reduces the amount of information that a BGP speaker must
store and exchange with other BGP speakers. Reducing the information that is stored and exchanged
also reduces the size of the routing table.
remote AS
source-interface
route-policy
send-community
next-hop-self
Each BGP peer group is assigned a unique name when it is created. To create or delete peer groups, use
the following command:
create bgp peer-group <peer-group-name>
delete bgp peer-group <peer-group-name>
678
BGP Features
Changes made to the parameters of a peer group are applied to all neighbors in the peer group.
Modifying the following parameters will automatically disable and enable the neighbors before changes
take effect:
remote-as
timer
source-interface
soft-in-reset
password
The new neighbor is created as part of the peer group and inherits all of the existing parameters of the
peer group. The peer group must have remote AS configured.
To add an existing neighbor to a peer group, use the following command:
configure bgp neighbor [all | <remoteaddr>] peer-group [<peer-group-name> | none]
{acquire-all}
If you do not specify the acquire-all option, only the mandatory parameters are inherited from the
peer group. If you specify the acquire-all option, all of the parameters of the peer group are
inherited. This command disables the neighbor before adding it to the peer group.
To remove a neighbor from a peer group, use the peer-group none option.
When you remove a neighbor from a peer group, the neighbor retains the parameter settings of the
group. The parameter values are not reset to those the neighbor had before it inherited the peer group
values.
679
To enable route flap dampening for a BGP peer group, use the following command:
configure bgp peer-group <peer-group-name> {address-family [ipv4-unicast | ipv4multicast]} dampening {{half-life <half-life-minutes> {reuse-limit <reuse-limitnumber> supress-limit <suppress-limit-number> max-suppress <max-suppress-minutes>}} |
policy-filter [<policy-name> | none]}
You can supply the dampening parameters directly through the command line interface (CLI)
command, or use the command to associate a policy that contains the desired parameters.
To disable route flap dampening for a BGP peer group, use the following command:
configure bgp peer-group <peer-group-name> no-dampening
680
BGP Features
To view the configured values of the route flap dampening parameters for a BGP peer group, use the
following command:
show bgp peer-group {detail | <peer-group-name> {detail}}
higher weight
lowest routerID
You want to conserve AS numbers if you are multihomed to the local AS.
Private AS numbers should not be advertised on the Internet. Private AS numbers can be used only
locally within an administrative domain. Therefore, when routes are advertised out to the Internet, the
routes can be stripped out from the AS paths of the advertised routes using this feature.
To configure private AS numbers to be removed from updates, use the following command:
enable bgp neighbor [<remoteaddr> | all] remove-private-AS-numbers
Route Redistribution
BGP, OSPF, and RIP can be enabled simultaneously on the switch. Route redistribution allows the
switch to exchange routes, including static and direct routes, between any two routing protocols.
681
Using the export command to redistribute routes complements the redistribution of routes using the
configure bgp add network command. The configure bgp add network command adds the route
to BGP only if the route is present in the routing table. The enable bgp export command redistributes
the specified routes from the routing table to BGP. If you use both commands to redistribute routes, the
routes redistributed using the network command take precedence over routes redistributed using the
export command.
682
BGP Features
stale and wont be used to forward traffic to that router. However, in many cases, two conditions exist
that allow the router restarting BGP to continue to forward traffic correctly. The first condition is that
forwarding can continue while the control function is restarted. Most modern router system designs
separate the forwarding function from the control function so that traffic can still be forwarded
independent of the state of the BGP function. Routes learned through BGP remain in the routing table
and packets continue to be forwarded. The second condition required for graceful restart is that the
network remain stable during the restart period. If the network topology is not changing, the current
routing table remains correct. Often, networks can remain stable during the time for restarting BGP.
With graceful BGP restart, routes received from a restarting router are marked as stale, but traffic
continues to be forwarded over these routes during the restart process.
The address families participating in graceful restart are configured using the following command:
configure bgp restart [add | delete] address-family [ipv4-unicast | ipv4-multicast]
There are three timers that can be configured with the following commands:
configure bgp restart restart-time <seconds>
configure bgp restart stale-route-time <seconds>
configure bgp restart update-delay <seconds>
683
You can use the following commands to verify that BGP graceful restart is configured:
show bgp
show bgp neighbor
684
The following URL points to the website for the IETF PIM Working Group:
http://www.ietf.org/html.charters/pim-charter.html
Overview
Multicast routing and switching is the functionality of a network that allows a single host (the multicast
server) to send a packet to a group of hosts. With multicast, the server is not forced to duplicate and
send enough packets for all the hosts in a group. Instead, multicast allows the network to duplicate the
packet where needed to supply the group. Multicast greatly reduces the bandwidth required to send
data to a group of hosts. IP multicast routing is a function that allows multicast traffic to be forwarded
from one subnet to another across a routing domain.
IP multicast routing consists of the following functions:
A router-to-router multicast routing protocol (for example, Protocol Independent Multicast (PIM))
A method for the IP host to communicate its multicast group membership to a router (for example,
Internet Group Management Protocol (IGMP))
NOTE
You should configure IP unicast routing before you configure IP multicast routing.
PIM Overview
The switch supports both dense mode and sparse mode operation. You can configure dense mode or
sparse mode on a per-interface basis. After they are enabled, some interfaces can run dense mode, while
others run sparse mode.
685
Licensing
To use the complete PIM functionality, you must have at least a Core license installed on your switch.
The BlackDiamond 10K ships with a Core, or Advanced Core license. Other platforms can be upgraded
to a Core license. See Software Licensing on page 34 for more information about licensing.
A subset of PIM, called PIM Edge Mode, is available with an Advanced Edge license.
At most, two Active PIM-SM interfaces are permitted. There is no restriction on the number of
Passive interfaces (within the limit of the maximum IP interfaces).
Active PIM interfaces can have other PIM enabled routers on them. Passive interfaces should only have
hosts sourcing or receiving multicast traffic.
686
Overview
NOTE
You can run either PIM-DM or PIM-SM per virtual LAN (VLAN).
No overhead of switching to the source-specific tree and waiting for the first packet to arrive
No need for the complex register mechanism from the source to the RP
PIM-SSM is designed as a subset of PIM-SM and all messages are compliant with PIM-SM. PIM-SSM
and PIM-SM can coexist in a PIM network; only the last hop router need to be configured for PIM-SSM
687
IGMP Overview
IGMP is a protocol used by an IP host to register its IP multicast group membership with a router. A
host that intends to receive multicast packets destined for a particular multicast address registers as a
member of that multicast address group. Periodically, the router queries the multicast group to see if the
group is still in use. If the group is still active, a single IP host responds to the query, and group
registration is maintained.
IGMPv2 is enabled by default on the switch, and beginning with release 11.2, ExtremeWare XOS
supports IGMPv3. However, the switch can be configured to disable the generation of periodic IGMP
query packets. IGMP should be enabled when the switch is configured to perform IP unicast or IP
multicast routing.
IGMPv3, specified in RFC 3376, adds support for source filtering. Source filtering is the ability for a
system to report interest in receiving packets only from specific source addresses, (filter mode include),
or from all sources except for specific addresses, (filter mode exclude). IGMPv3 is designed to be
interoperable with IGMPv1 and IGMPv2.
IGMP Snooping
IGMP snooping is a Layer 2 function of the switch; it does not require multicast routing to be enabled.
In IGMP snooping, the Layer 2 switch keeps track of IGMP reports and only forwards multicast traffic
to that part of the local network that requires it. IGMP snooping optimizes the use of network
bandwidth and prevents multicast traffic from being flooded to parts of the local network that do not
need it.
IGMP snooping is enabled by default on the switch. If IGMP snooping is disabled, all IGMP and IP
multicast traffic floods within a given VLAN. IGMP snooping expects at least one device on every
VLAN to periodically generate IGMP query messages.
When a port sends an IGMP leave message, the switch removes the IGMP snooping entry after 1000
milliseconds (the leave time is configurable, ranging from 0 to 10000 ms). The switch sends a query to
determine which ports want to remain in the multicast group. If other members of the VLAN want to
remain in the multicast group, the router ignores the leave message, but the port that requests removal
is removed from the IGMP snooping table.
If the last port within a VLAN sends an IGMP leave message and the router does not receive any
responses to the query, then the router immediately removes the VLAN from the multicast group.
688
Overview
Static IGMP
To receive multicast traffic, a host must explicitly join a multicast group by sending an IGMP report;
then, the traffic is forwarded to that host. In some situations, you would like multicast traffic to be
forwarded to a port where a multicast-enabled host is not available (for example, when you test
multicast configurations).
Static IGMP emulates a host or router attached to a switch port, so that multicast traffic is forwarded to
that port, and the switch will send a proxy join for all the statically configured IGMP groups when an
IGMP query is received. You can emulate a host to forward a particular multicast group to a port; and
you may emulate a router to forward all multicast groups to a port. Static IGMP is only available with
IGMPv2.
To emulate a host on a port, use the following command:
configure igmp snooping {vlan} <vlanname> ports <portlist> add static group <ip
address>
To display the IGMP snooping static groups, use the following command:
show igmp snooping vlan <name> static [group | router]
689
After you create a policy file, use the following command to associate the policy file and filter a set of
ports:
configure igmp snooping vlan <vlanname> ports <portlist> filter [<policy> | none]
3 Enable PIM on all IP multicast routing interfaces using the following command:
configure pim add vlan [<vlan-name> | all] {dense | sparse} {passive}
4 For PIM-SSM, specify the PIM-SSM range, specify IGMPv3, and enable PIM-SSM on the interfaces
using the following commands:
configure pim ssm range [default | policy <policy-name>]
enable igmp {vlan <vlan name>} {IGMPv1 | IGMPv2 | IGMPv3}
enable pim ssm vlan [<vlan_name> | all]
690
Area 0
IR 2
10.0.1.1
IR 1
10.0.1.2
10.0.3.2
Headquarters
_3
HQ
0
0_
_1
HQ
_1
0_
0_
2
10.0.2.2
ABR 2
10.0.3.1
ABR 1
10.0.2.1
161.48.2.2
Los Angeles
LA
Ch
i_1
60
_2
8_
6_
_4
Virtual link
161.48.2.1
61
26
160.26.26.1
_1
160.26.25.1
160.26.26.2
160.26.25.2
Area 5
Chicago
Area 6 (stub)
EX_040
691
IR 2
10.0.1.1
IR 1
10.0.1.2
10.0.3.2
Headquarters
ABR 2
10.0.3.1
HQ
3
0_
0_
_1
HQ
_1
0_
0_
2
10.0.2.2
ABR 1
HQ_10_10_4
Area 0
10.0.2.1
Rendezvous
point
161.48.2.2
Los Angeles
LA
26
Ch
i_1
60
_2
8_
6_
_4
Virtual link
161.48.2.1
61
160.26.26.1
_1
160.26.25.1
160.26.26.2
160.26.25.2
Area 5
Chicago
Area 6 (stub)
EX_062
The policy file, rp_list.pol, contains the list of multicast group addresses serviced by this RP. This set
of group addresses are advertised as candidate RPs. Each router then elects the common RP for a group
address based on a common algorithm. This group to RP mapping should be consistent on all routers.
692
693
Stream to Group G
Stream to Group G
Vlan1
(MVR Enabled)
Vlan1
Switch1
H1 subscribed to G
Switch1
H1 subscribed to G
Vlan2
H2 subscribed to G
Vlan2
H2 subscribed to G
EX_142
In Figure 93, the left side shows a standard VLAN carrying a multicast stream. The host H1 receives the
multicast stream because it resides on VLAN Vlan1, but host H2 does not receive the multicast traffic
because no IP multicast routing protocol forwards the stream to VLAN Vlan2. On the right side of the
figure, H2 does receive the multicast stream. Because Vlan1 was configured as an MVR VLAN, the
multicast stream is forwarded to the other VLANs on the switch. containing hosts that have requested
the stream. To configure a VLAN as an MVR VLAN, use the following command:
configure mvr add vlan <vlan-name>
Typically, IGMP snooping is enabled, so only hosts that have requested a stream will see the multicast
traffic. For example, another host on Vlan2 would not receive the traffic unless it had sent an IGMP
request to be included in the group.
Notice that only Vlan1 is MVR enabled. Configure MVR only on the ingress VLAN. To enable MVR on
the switch, use the following command:
enable mvr
694
IPTV server
Switch3
McastVlan
Switch2
Switch4
McastVlan
McastVlan
Switch1
Vlan2
H2
Vlan4
H3
H4
EX_143
Without MVR, there are two ways to distribute multicast streams in this topology:
Extend subscriber VLANs (Vlan2, Vlan3, and Vlan4) to the network core, by tagging the ports
connecting the switches.
Configure all VLANS with an IP address and run PIM or DVMRP on each switch.
There are problems with both of these approaches. In the first approach, multiple copies of the same
stream (IPTV channel) would be transmitted in the core, wasting bandwidth. In the second approach, all
switches in the network core would have to be layer 3 multicast aware, and would have to run a
multicast protocol. Typical network cores are layer 2 only.
MVR provides a simple solution to this problem. If McastVlan in Switch1 is configured with MVR, it
will leak the traffic into the local subscriber VLANs that contain hosts that request the traffic. For simple
cases, perform these configuration steps:
1 Configure MVR on McastVlan.
2 Configure an IP address and enable IGMP and IGMP snooping on the subscriber VLANs (by default
IGMP and IGMP snooping are enabled on Extreme Networks switches).
3 For all the multicast streams (IPTV channels), configure static IGMP snooping membership on the
router on McastVlan.
4 Enable MVR on the switches in the network.
This strategy conserves bandwidth in the core and does not require running PIM on the subscriber
switches.
695
If a multicast packet for a group in the static MVR range is received on an MVR enabled VLAN, it will
always be flooded on the MVR VLAN. This allows the neighbor switch in the ring to receive all the
static MVR streams.
Dynamic MVR: In contrast, since a video content provider would like to provide a variety of on-demand
and other premium channels, there are often many lower demand (fewer viewers) premium channels
that cannot all be made available simultaneously at the core network. These should be streamed from
the router only if requested by a host.
IGMP is the standard method used by a host to request a stream. However, IGMP packets are
constrained to a VLAN. Thus, subscribers' IGMP join requests on the VLAN cannot be forwarded onto
other VLANS. With MVR, a VLAN sends proxy IGMP join messages on behalf of all the subscriber
VLANs on the switch. Thus, in Figure 94, McastVlan would send join and leave messages on behalf of
Vlan2, Vlan3, and Vlan4. The router receives the messages on McastVlan and streams corresponding
channels onto the core network. This provides on-demand service, and an administrator doesn't need to
configure static IGMP on the router for each of these channels.
Configuring Static and Dynamic MVR: By default, all MVR streams are static. You can specify which
groups are static by using the following command:
configure mvr vlan <vlan-name> static group {<policy-name> | none}
Any other groups in the MVR address range are dynamic. You can specify the MVR address range by
using the following command:
configure mvr vlan <vlan-name> mvr-address {<policy-name> | none}
696
MVR Forwarding
The goal for MVR is to limit the multicast traffic in the core layer 2 network to only the designated
multicast VLAN. If the backbone layer 2 port is tagged with multiple VLANs, as shown in Figure 95, a
set of rules is needed to restrict the multicast streams to only one VLAN in the core.
Vlan2
H2
PC2
Switch1
p1
p2 vc2
H3
H4
EX_144
In Figure 95, the core network has 2 more VLANs, vc1 and vc2, to provide other services. With MVR,
multicast traffic should be confined to McastVlan, and should not be forwarded to vc1 and vc2. It
should be noted that MVR is configured only on the ingress VLAN (McastVlan). MVR is not configured
on any other VLANs.
In the same way as the IGMP snooping forwarding rules, the multicast stream is forwarded onto
member ports and router ports on the VLAN. For a stream received on MVR enabled ports, this rule is
extended to extend membership and router ports to all other VLANs. This rule works well on the
topology in Figure 94. However, in a tagged core topology, this rule forwards traffic onto VLANs, such
as vc1 and vc2, on ports PC1 and PC2. This results in multiple copies of same stream on the core
network, thus reintroducing the problem that MVR was intended to solve.
To avoid multiple copies of the same stream, MVR forwards traffic with some special restrictions. MVR
traffic is not forwarded to another VLAN unless a host is detected on the port. On the ingress MVR
VLAN, packets are not duplicated to ports belonging to MVR VLANs. This is to prevent duplicate
multicast traffic streams on ingress ports. Streams belonging to static MVR groups will always be
forwarded on MVR VLANs so that any host can join such channels immediately. However, dynamic
groups will be streamed from the server only if some host is interested in them. A command is
provided to receive traffic on a port which is excluded by MVR. However, regular IGMP rules still
apply to these ports, so the ports must have a router connected or an IGMP host to receive the stream.
These rules are to prevent multicast packets from leaking into undesired virtual port, such as p2 on
VLAN pc2 in Figure 95. These rules also allow that, in most topologies, MVR could be deployed with
minimal configuration. However, unlike EAPS/STP, MVR is not intended to be a layer 2 protocol to
solve packet looping problems. Since multicast packets leak across VLANs, one can misconfigure and
end up with a multicast storm. MVR does not attempt to solve such problems.
697
NOTE
If a port were blocked by layer 2 protocols, that port would be removed from the egress list of the cache. This is
done dynamically per the port state.
For most situations, you will not need to manually configure ports to receive the MVR multicast
streams. But if one of the forwarding rules denies forwarding to a port that requires the streams, you
can manually receive the MVR multicast streams by using the following command:
configure mvr vlan <vlan-name> add receiver port <port-list>
1:2
1:1
SW1
1:2
SW2
1:4
1:5
1:5
Sw6
Customer ring
CustVlan
1:3
H2
1:4
H3
H4
EX_145
In this topology, a multicast stream could be leaked into the customer multicast network through either
switch SW1 or SW2. However, as described in MVR Forwarding, packets will not be forwarded to
router ports (ports 1:4 and 1:5 could be router ports if SW2 is an IGMP querier). To get around this,
MVR needs to be configured on CustVlan either on SW1 or SW2. Since the forwarding rules apply only
to non-MVR VLANs, traffic from one MVR VLAN will be leaked into the router ports of another
VLAN, if MVR is enabled on that.
In the topology above, the MSP multicast VLAN is carried on two switches that also carry the customer
multicast VLAN. When multiple switches carry both multicast VLANs, it is imperative that MVR is
configured on only one switch. Only that switch should be used as the transit point for multicast
698
MVR Configurations
MVR enables layer 2 network installations to deliver bandwidth intensive multicast streams. It is
primarily aimed at delivering IPTV over layer 2 networks, but would be valuable in many existing
EAPS or STP installations. This section explores a few possible deployment scenarios and configuration
details. Of course, real world networks could be lot different from these examples. This section is meant
to present some ideas on how to deploy MVR over existing networks, as well as to design new
networks that support MVR.
699
IPTV server
McastVlan
1:1
1:2
Router1
McastVlan,
V1, V2
Switch4
1:3
Switch3
EAPS ring
Switch2
McastVlan, V1, V2
1:1
1:2
Switch1
Vlan4
1:4
Vlan2
1:3
H2
H3
H4
EX_146
Switch1:
create vlan mcastvlan
create vlan v1
create vlan v2
create vlan vlan2
configure vlan vlan2 add port 1:3
configure vlan vlan2 ipaddress 10.20.1.1/24
configure mcastvlan tag 20
configure mcastvlan add port 1:1,1:2 tag
configure mvr add vlan mcastvlan
700
vlan v1 tag
v1 add port
vlan v2 tag
v2 add port
create eaps e1
configure eaps
configure eaps
configure eaps
configure eaps
configure eaps
configure eaps
enable eaps
enable mvr
30
1:1,1:2 tag
40
1:1,1:2 tag
e1 mode transit
e1 add control vlan v1
e1 add protect vlan mcastvlan
e1 add protect vlan v2
port primary port 1:1
port secondary port 1:2
Switch3:
create vlan McastVlan
create vlan v1
create vlan v2
configure mcastvlan tag 20
configure mcastvlan add port 1:2,1:3 tag
configure mcastvlan add port 1:1
configure mvr add vlan mcastvlan
configure vlan v1 tag 30
configure v1 add port 1:2,1:3 tag
configure vlan v2 tag 40
configure v2 add port 1:2,1:3 tag
create eaps e1
configure eaps
configure eaps
configure eaps
configure eaps
configure eaps
configure eaps
enable eaps
enable mvr
e1 mode master
e1 add control vlan v1
e1 add protect vlan mcastvlan
e1 add protect vlan v2
port primary port 1:3
port secondary port 1:2
NOTE
In this example, Switch3 is the EAPS master, but any of the other switches in the ring could have been configured
as the master.
701
Switch4
Switch2
MSP ring
MVlan, vc1
MVlan, vc1
Switch1
1:3
1:4
V1
V1
Vlan V1 cloud
EX_148
In this topology, subscribers are in a layer 2 cloud on VLAN V1. STP is configured for all ports of V1.
Since V1 spans on the ring as well, multicast cannot be forwarded on V1 blindly. Forwarding rules
(described in MVR Forwarding), dictates that multicast traffic will not be forwarded on STP enabled
ports. This is to make sure that multiple copies of multicast packets are not forwarded on the ring.
However, since other STP enabled ports on V1 (1:3,1:4) are not part of the ring multicast stream, they
need to be configured so that they get the packets. To configure the ports to receive packets, use the
following command (mentioned previously in MVR Forwarding):
configure mvr vlan <vlan-name> add receiver port <port-list>
NOTE
If the layer 2 cloud is connected back to ring ports, traffic may end up leaking into VLAN V1 in the ring. There is no
way to avoid that. So, such topologies must be avoided.
702
IPTV server
MVlan
1:1
1:2
Router1
To BRAS
1:3
Switch3
Switch4
MVlan, VMAN
Switch2
MVlan, VMAN
1:1
1:2
Switch1
Untag CE port
2:2
2:3
User VMAN
MVlan
DSLAM
User VMAN
MVlan
IGMP
DSLAM
EX_149
703
704
32 IPv6 Multicast
This chapter describes the following topics:
Overview
IPv6 multicast is a function that allows a single IPv6 host to send a packet to a group of IPv6 hosts.
NOTE
In the current release of ExtremeWare XOS (11.4), IPv6 multicast packets are flooded to VLANs that receive the
traffic, therefore, MLD snooping is not supported. Also, ExtremeWare XOS does not currently support any IPv6
multicast routing protocols.
MLD Overview
MLD is a protocol used by an IPv6 host to register its IP multicast group membership with a router.
Periodically, the router queries the multicast group to see if the group is still in use. If the group is still
active, a single IP host responds to the query, and group registration is maintained.
MLD is the IPv6 equivalent to IGMP. MLDv1 is equivalent to IGMPv2, and MLDv2 is equivalent to
IGMPv3. MLDv1 is currently supported on the switch.
MLD Snooping
MLD snooping is a Layer 2 function of the switch; it does not require multicast routing to be enabled. In
MLD snooping, the Layer 2 switch keeps track of MLD reports and only forwards multicast traffic to
that part of the local network that requires it. MLD snooping optimizes the use of network bandwidth
and prevents multicast traffic from being flooded to parts of the local network that do not need it.
MLD snooping is enabled by default on the switch. If MLD snooping is disabled, all MLD and IP
multicast traffic floods within a given VLAN. MLD snooping expects at least one device on every
VLAN to periodically generate MLD query messages.
When a port sends an MLD done message, the switch removes the MLD snooping entry after 1000
milliseconds (the leave time is configurable, ranging from 0 to 10000 ms). The switch sends a query to
determine which ports want to remain in the multicast group. If other members of the VLAN want to
remain in the multicast group, the router ignores the done message, but the port that requests removal
is removed from the MLD snooping table.
705
IPv6 Multicast
If the last port within a VLAN sends an MLD done message and the router does not receive any
responses to the query, then the router immediately removes the VLAN from the multicast group.
Static MLD
To receive multicast traffic, a host must explicitly join a multicast group by sending an MLD report;
then, the traffic is forwarded to that host. In some situations, you would like multicast traffic to be
forwarded to a port where a multicast-enabled host is not available (for example, when you test
multicast configurations).
Static MLD emulates a host or router attached to a switch port, so that multicast traffic is forwarded to
that port, and the switch will send a proxy join for all the statically configured MLD groups when an
MLD query is received. You can emulate a host to forward a particular multicast group to a port; and
you may emulate a router to forward all multicast groups to a port.
To emulate a host on a port, use the following command:
configure mld snooping {vlan} <vlanname> ports <portlist> add static
group <v6grpipaddress>
To display the MLD snooping static groups, use the following command:
show mld snooping vlan <name> static [group | router]
706
Appendixes
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800
Family of Switches Only on page 716
709
Filename Prefixes
BlackDiamond 12804
bd12K-
BlackDiamond 10K
bd10K-
BlackDiamond 8810
bd8800-
BlackDiamond 8806
bd8800-
Summit X450
summitX450-
For example, if you have a BlackDiamond 8806 switch, download image filenames with the prefix
bd8800-. For additional installation requirements see the sections, Installing a Core Image on page 711
and Installing a Modular Software Package on page 713.
show version
show switch
<major>.<minor>.<patch>.<build>
For example: 10.1.2.16
Table 78 describes the image version fields.
710
Field
Description
major
minor
patch
build
Specifies the ExtremeWare XOS build number. This value is reset to 0 for each new major
and minor release.
NOTE
The information displayed does not include the I/O version number for the BlackDiamond 8800 family of switches
as described in the section Displaying the I/O Version Number on page 718. The I/O version string includes the
major, minor, and I/O version number, not the patch and build numbers.
The show version command also displays information about the firmware (BootROM) images running
on the switch. For more information, see Displaying the BootROM and Firmware Versions on
page 736.
Software Signatures
Each ExtremeWare XOS image contains a unique signature. The BootROM checks for signature
compatibility and denies an incompatible software upgrade. In addition, the software checks both the
installed BootROM and software and also denies an incompatible upgrade.
Output from this command includes the selected and booted images and if they are in the primary or
secondary partition.
If two MSMs are installed in a modular switch, the downloaded image is saved to the same location on
each one.
To select which image the switch will load on the next reboot, use the following command:
use image {partition} <partition> {msm <slotid>}
711
Before the download begins, the switch asks if you want to install the image immediately after the
download is finished. If you install the image to the active partition, you must reboot the switch. If
you install the image to the inactive partition, you do not need to reboot the switch. Enter y to install
the image after download. Enter n to install the image at a later time.
If you download and install the software image on the active partition, the switch automatically
reboots after the download and installation is completed. The following message appears when
downloading and installing on the active partition:
Image will be installed to the active partition, a reboot required. Do you want
to continue? (y or n)
Enter y to continue the installation and reboot the switch. Enter n to cancel.
If you install the image at a later time, the image is still downloaded and saved to the switch, but
you must use the following command to install the software:
install image <fname> {<partition>} {msm <slotid>} {reboot}
NOTE
Unlike ExtremeWare, the download image command in ExtremeWare XOS causes the switch to use the newly
downloaded software image during the next switch reboot. To modify or reset the software image used during a
switch reboot, use the use image command.
712
Enter y to remove the core dump files and download the new software image. Enter n to cancel this
action and transfer the files before downloading the image.
You can install a modular software package on the active partition or on the inactive partition. You
would install on the active partition if you want to add the package functionality to the currently
running core image without having to reboot the switch. You would install on the inactive partition if
you want the functionality available after a switch reboot.
To install the package, you use the same process that you use to install a new core image. Follow the
process described in the earlier section Installing a Core Image. On the BlackDiamond 10K switch and
the BlackDiamond 8800 family of switches, you can use hitless upgrade to install the package. See
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800
Family of Switches Only on page 716 for more information.
You activate the installed modular software package either by rebooting the switch or by issuing the
following command:
run update
NOTE
Do not terminate a process that was installed since the last reboot unless you have saved your configuration. If you
have installed a software module and you terminate the newly installed process without saving your configuration,
your module may not be loaded when you attempt to restart the process with the start process command.
713
Download and install the SSH software module on the active partition
Gracefully terminate and re-start the thttpd process running on the switch
For more information about SSH and SSL, see Chapter 17, Security.
2 Download the software module from your TFTP server or external compact flash memory card using
the following command:
download image [[<hostname> | <ipaddress>] <filename> {{vr} <vrname>} | memorycard
<filename>] {<partition>} {msm <slotid>}
3 Activate the installed modular package, if installed on the active partition, using the following
command:
run update
4 Restart the processes associated with the software module using the following command:
start process <name> {msm <slot>}
714
2 Activate the installed modular package, if installed on the active partition, using the following
command:
run update
3 Terminate and restart the processes associated with the software module using the following
command:
restart process [class <cname> | <name> {msm <slot>}]
Examples. The following examples upgrade the SSH module on the active partition and assume that
you have:
Upgraded the switch to a new core image (see Installing a Core Image on page 711 for more
information)
Downloaded the corresponding modular software package to your TFTP server. On a modular
switch, you can download the modular software package to an external compact flash memory card
(see Downloading a New Image on page 709 for more information)
The first example uses the terminate process and start process commands to terminate and restart
the processes associated with the software module that you are updating:
terminate process exsshd graceful
download image 10.10.10.2 bd10K-11.3.0.10-ssh.xmod
run update
start process exsshd
The second example uses the restart process command to terminate and restart the processes
associated with the software module that you are updating:
download image 10.10.10.2 bd10K-11.3.0.10-ssh.xmod
run update
restart process exsshd
Use this command to schedule a time to reboot the switch or to reboot the switch immediately. To
schedule a time to reboot the switch, use the following command:
reboot time <date> <time>
Where date is the date and time is the time (using a 24-hour clock format) when the switch will be
rebooted. The values use the following format:
mm dd yyyy hh mm ss
715
NOTE
When you configure a timed reboot of the switch, use the show switch command to see the scheduled time.
If you do not specify a reboot time, the reboot occurs immediately following the command, and any
previously schedule reboots are cancelled. To cancel a previously scheduled reboot, use the cancel
option.
NOTE
When you configure a timed reboot of an MSM, use the show switch command to see the scheduled time.
For more information about all of the options available with the reboot command, see the ExtremeWare
XOS Command Reference Guide.
Although any method of upgrading software can have an impact on network operation, including
interrupting Layer 2 network operation, performing a hitless upgrade can decrease that impact.
You must have two MSMs installed in your switch to perform a hitless upgrade. With two MSMs
installed in the switch, one assumes the role of primary and the other assumes the role of backup. The
primary MSM provides all of the switch management functions including bringing up and
716
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800 Family of Switches Only
programming the I/O modules, running the bridging and routing protocols, and configuring the switch.
The primary MSM also synchronizes its configurations with the backup MSM which allows the backup
to take over the management functions of the primary.
NOTE
The software on the I/O modules is not updated during a hitless upgrade, only the software on the MSMs. The I/O
module software is updated when the switch reboots or when a disabled slot is enabled.
NOTE
If you download an image to the backup MSM, the image passes through the primary MSM before the image is
downloaded to the backup MSM.
If the new ExtremeWare XOS image supports hitless upgrade and is compatible with the current
running I/O module image, you can perform a hitless upgrade.
If the new ExtremeWare XOS image supports hitless upgrade, is compatible with the current running
I/O image but with a degradation of functionality, you can perform a hitless upgrade with caveats.
The switch warns you that the upgrade is hitless; however, the downloaded software may result in a
loss of new functionality. You can either continue the upgrade with the modified functionality or
cancel the action.
To prevent a loss in functionality, schedule time to take the switch offline to perform the upgrade; do
not upgrade the software using hitless upgrade.
If the new ExtremeWare XOS image supports hitless upgrade but is not compatible with the current
running I/O module image (the I/O version numbers do not match), you cannot perform a hitless
upgrade.
The switch warns you that the upgrade may not be hitless. You can either continue the upgrade or
cancel the action. If you continue the upgrade, the primary MSM downloads the new image to the
I/O module and reboots.
717
The other MSM operates with a different version of I/O module image.
If you continue with the MSM failover, all I/O modules will be reset.
Are you sure you want to failover? (y/n)
The local I/O version identifies the software currently running on the switch, and the remote I/O
version identifies the software you want to install.
The output from this command displays the ExtremeWare XOS image as follows:
<major>.<minor>.<IO version>
If the I/O versions are compatible, you can perform a hitless upgrade.
NOTE
The information displayed does not include the patch and build numbers as described in the section Understanding
the Image Version String on page 710. The image version string includes the major, minor, patch, and build
numbers, not the I/O version number.
718
You have received the new software image from Extreme Networks, and the image is on either a
TFTP server or an external compact flash memory card. See Downloading a New Image on
page 709 for more information.
On the BlackDiamond 10K switch, you are running ExtremeWare XOS 11.1 or later on both MSMs
installed in the switch. Earlier versions of ExtremeWare XOS do not support hitless upgrade.
On the BlackDiamond 8800 family of switches, you are running ExtremeWare XOS 11.4.
On the BlackDiamond 12804 switch, you are running ExtremeWare XOS 11.4.
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800 Family of Switches Only
NOTE
Hitless upgrade support for the BlackDiamond 10K switch was introduced in ExtremeWare XOS 11.1.
Hitless upgrade support for the BlackDiamond 8800 family of switches and the BlackDiamond 12804 switch was
introduced in ExtremeWare XOS 11.4.
Summary of Tasks
To perform a hitless upgrade to install and upgrade the ExtremeWare XOS software on your system:
1 Determine your selected and booted image partitions.
2 On the BlackDiamond 8800 family of switches, verify the I/O version number of the software image
currently running on the switch.
If you have a BlackDiamond 10K or 12804 switch, proceed to step 3.
3 Select the partition to download the image to (and the partition to boot from after installing the
image).
4 Download and install the new ExtremeWare XOS software on the backup MSM. Reboot this MSM if
necessary.
5 Initiate failover from the primary MSM to the backup MSM. This MSM now becomes the new
backup MSM and the original MSM becomes the primary MSM.
6 Download and install the new ExtremeWare XOS software on the original primary MSM (new
backup MSM). Reboot this MSM if necessary.
7 Initiate failover from the new primary MSM to the new backup MSM.
This optional step restores the switch to the original primary and backup MSM.
Detailed Steps
To perform a hitless upgrade to install and upgrade the ExtremeWare XOS software on your system:
1 View your selected and booted partition using the following command:
show switch
Output from this command indicates, for each MSM, the selected and booted images and if they are
in the primary or the secondary partition. The selected image partition indicates which image will be
used at the next reboot. The booted image partition indicates the image used at the last reboot. It is
the active partition.
2 On the BlackDiamond 8800 family of switches, verify that the current I/O version number is
compatible with the new ExtremeWare XOS image that you want to install using the following
command:
show platform upgrade-compatibility
Output from this command indicates the major and minor ExtremeWare XOS image numbers as well
as the I/O version number for the currently running image and the new image you want to install. If
the I/O version numbers are compatible, you can perform a hitless upgrade.
If you have a BlackDiamond 10K or 12804 switch, proceed to step 3.
3 Select the partition to download the image to and download and install the new ExtremeWare XOS
software on the backup MSM using the following command:
download image [[<hostname> | <ipaddress>] <filename> {{vr} <vrname>} | memorycard
<filename>] {<partition>} {msm <slotid>}
719
NOTE
If the backup MSM is installed in slot B, specify msm B. If the backup MSM is installed in slot A, specify msm
A.
Before the download begins, the switch prompts you to install the image immediately after the
download is finished. If you install the image immediately after download on the active partition,
the switch MSM reboots.
If you download and install the software image on the active partition, you immediately reboot
the MSM. The following message appears when downloading and installing on the active
partition:
Image will be installed to the active partition, a reboot required. Do you
want to continue? (y or n)
Enter y to continue the installation and reboot the MSM. Enter n to cancel.
If you download and install the software image on the non-active partition, you need to reboot
the MSM manually before you proceed. Use the following command to reboot the switch:
reboot {time <month> <day> <year> <hour> <min> <sec>} {cancel} {warm} {msm
<slot_id>}
Reboot only the backup MSM so the switch continues to forward traffic.
If you install the image at a later time, use the following command to install the software:
install image <fname> {<partition>} {msm <slotid>} {reboot}
4 Initiate failover from the primary MSM to the backup MSM using the following command:
run msm-failover {force}
When you failover from the primary MSM to the backup MSM, the backup becomes the new
primary, runs the software on its active partition, and provides all of the switch management
functions.
5 Select the partition to download the image to and download and install the new ExtremeWare XOS
software on the new backup MSM (this was the original primary MSM) using the following
command:
download image [[<hostname> | <ipaddress>] <filename> {{vr} <vrname>} | memorycard
<filename>] {<partition>} {msm <slotid>}
NOTE
If the new backup MSM is installed in slot A, specify msm A. If the new backup MSM is installed in slot B,
specify msm B.
Before the download begins, the switch prompts you to install the image immediately after the
download is finished. If you install the image immediately after download on the active partition,
the switch MSM reboots.
If you download and install the software image on the active partition, you immediately reboot
the MSM. The following message appears when downloading and installing on the active
partition:
Image will be installed to the active partition, a reboot required. Do you
want to continue? (y or n)
Enter y to continue the installation and reboot the MSM. Enter n to cancel.
720
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800 Family of Switches Only
If you download and install the software image on the non-active partition, you need to reboot
the MSM manually before you proceed. Use the following command to reboot the switch:
reboot {time <month> <day> <year> <hour> <min> <sec>} {cancel} {warm} {msm
<slot_id>}
Reboot only the backup MSM so the switch continues to forward traffic.
If you install the image at a later time, use the following command to install the software:
install image <fname> {<partition>} {msm <slotid>} {reboot}
6 Optionally, initiate failover from the new primary MSM to the new backup MSM using the following
command:
run msm-failover {force}
When you failover from the new primary MSM to the new backup MSM, this optional step restores
the switch to the original primary and backup MSM.
You can also perform a hitless upgrade on ExtremeWare XOS modular software packages (.xmod files).
To perform a hitless upgrade of a software package, you must install the core software image first, and
the version number of the modular software package must match the version number of the core image
that it will be running with.
For more detailed information about modular software packages, see Installing a Modular Software
Package on page 713. To perform a hitless upgrade, follow the steps described in the previous section,
Performing a Hitless Upgrade.
When you initiate failover, the MSM I/O ports on the original primary MSM are not available
during and this MSM I/O subsection is power cycled. It takes about 2 minutes for these MSM I/O
ports to be able to pass traffic again.
If you attempt a hitless upgrade between major releases, the switch warns you that the upgrade is
not hitless. You can either continue the upgrade or cancel the action. If you continue the upgrade,
the primary MSM downloads the new image to the I/O module and reboots them.
721
You have received the new software image from Extreme Networks named bd10K-11.1.0.14.xos.
After executing these commands, MSM B will be the master, and the secondary partition will be the
active partition for both MSMs. The previously running software will reside on the inactive partition
(now, the primary partition).
NOTE
If you download the image to the current partition, specifying the partition name is optional.
After executing these commands, MSM B will be the master, and the primary partition will be the active
partition for both MSMs. The previously running software was overwritten on the primary partition,
and is no longer on the switch.
722
Understanding Hitless UpgradeBlackDiamond 10K and 12804 Switch and BlackDiamond 8800 Family of Switches Only
You have received the new software image from Extreme Networks named bd8800-11.4.0.12.xos.
After executing these commands, MSM B will be the master, and the secondary partition will be the
active partition for both MSMs. The previously running software will reside on the inactive partition
(now, the primary partition).
NOTE
If you download the image to the current partition, specifying the partition name is optional.
After executing these commands, MSM A is restored as the primary MSM, and the primary partition
will be the active partition for both MSMs. The previously running software was overwritten on the
primary partition, and is no longer on the switch.
723
NOTE
Configuration files have a .cfg file extension. When you enter the name of the file in the CLI, the system
automatically adds the .cfg file extension.
If you have made a mistake or you must revert to the configuration as it was before you started making
changes, you can tell the switch to use the backup configuration on the next reboot.
Each filename must be unique and can be up to 32 characters long. Filenames are also case sensitive.
For information on filename restrictions, refer to the specific command in the ExtremeWare XOS
Command Reference Guide.
To save the configuration, use the following command:
save configuration {primary | secondary | <existing-config> | <new-config>}
existing-configSpecifies an existing user-defined configuration (displays a list of available userdefined configuration files)
You are then prompted to save the changes. Enter y to save the changes or n to cancel the process.
To use the configuration, use the following command:
use configuration [primary | secondary | <file_name>]
724
NOTE
If the switch is rebooted while in the middle of saving a configuration, the switch boots to factory default settings if
the previously saved configuration file is overwritten. The configuration that is not in the process of being saved is
unaffected.
Viewing a Configuration
You can view the current configuration on the switch by using the following command:
show configuration {<module-name>}
You can also view just the portion of the configuration that applies to a particular module (for example,
SNMP) by using the module-name parameter.
You can send output from the show configuration {<module-name>} command to the Extreme
Networks Technical Support department for problem-solving purposes. The output maintains the
command line interface (CLI) format of the current configuration on the switch.
This command resets the entire configuration, with the exception of user accounts and passwords that
have been configured and the date and time.
To unset the currently selected configuration image, reset all switch parameters, and reboot the switch,
use the following command:
unconfigure switch {all}
View and modify the configuration using a text editor, and later download a copy of the file to the
same switch or to one or more different switches.
Send a copy of the configuration file to Extreme Networks Technical Support for problem-solving
purposes.
If you want to view your configuration in ASCII format, use the .xsf file extension (known as the XOS
CLI script file) when you save the configuration file on the switch. This saves the XML-based
configuration in an ASCII format readable by a text editor.
Summary of Tasks
The following summary only describes the CLI involved to transfer the configuration and load it on the
switch; it is assumed that you know how to modify the configuration file with a text editor. As
725
After the configuration file is on the TFTP server, use a text editor to enter the desired changes.
2 Download the configuration from the TFTP server to the switch using one of the following
commands:
tftp [<host-name> | <ip-address>] -g -r <remote-file>
tftp get [<host-name> | <ip-address>] <remote-file>
3 Verify the configuration file is on the switch using the following command:
ls
4 Load and restore the new configuration file on the switch using the following command:
load script <script-file>
5 Save the configuration to the configuration database so the switch can reapply the configuration
after switch reboot using the following command:
save configuration {primary | secondary | <existing-config> | <new-config>}
When you save the configuration file, the switch automatically adds the .cfg file extension to the
filename. This saves the ASCII configuration as an XML-based configuration file.
For example, to transfer the current switch configuration as an ASCII-based file named
meg_upload_config1.xsf to the TFTP server with an IP address of 10.10.10.10, do the following:
upload configuration 10.10.10.10 meg_upload_config1.xsf
If you successfully upload the configuration to the TFTP server, the switch displays a message similar to
the following:
Uploading meg_upload_config1.xsf to 10.10.10.10 ... done!
If you successfully download the configuration to the switch, the switch displays a message similar to
the following:
Downloading meg_upload_config1.xsf to switch... done!
726
1
1
1
1
1
1
1
root
root
root
root
root
root
root
0
0
0
0
0
0
0
98362
117136
68
21203
119521
96931
92692
Nov
Dec
Oct
Dec
Dec
Nov
Jul
2
12
26
13
6
11
19
13:53
12:56
11:17
15:40
14:35
11:01
16:42
Nov022005.cfg
epicenter.cfg
mcastgroup.pol
meg_upload_config1.xsf
primary.cfg
primary_11_11_05.cfg
secondary.cfg
#
#
#
#
#
#
Instead of entering each command individually, the script runs and loads the CLI on the switch.
727
-pPuts the specified file from the local host and copies it to the TFTP server
-l <local-file>Specifies the name of the configuration file that you want to save to the TFTP
server
putPuts the specified file from the local host and copies it to the TFTP server
<local-file>Specifies the name of the configuration file that you want to save to the TFTP
server
Check to make sure that you entered the filename correctly, including the .cfg extension, and that you
entered the correct host name or IP address for the TFTP server.
If your upload is successful, the switch displays a message similar to the following:
Uploading megtest1.cfg to TFTPhost ... done!
Beginning with ExtremeWare XOS 11.4, you can also upload the current configuration in ASCII format
from the switch to a TFTP server on your network. For more information, see ASCII-Formatted
Configuration Files on page 725.
728
-gGets the specified file from the TFTP server and copies it to the local host
-r <remote-file>Specifies the name of the configuration file that you want to retrieve from
getGets the specified file from the TFTP server and copies it to the local host
<remote_file>Specifies the name of the configuration file that you want to retrieve from the
TFTP server
NOTE
By default, if you transfer a file with a name that already exists on the system, the switch prompts you to
overwrite the existing file. For more information, see the tftp get command in the ExtremeWare XOS
Command Reference Guide.
Make sure that you entered the filename correctly, including the .cfg extension, and that you entered the
correct host name or IP address for the TFTP server.
If your download is successful, the switch displays a message similar to the following:
Downloading megtest2.cfg to switch... done!
729
CAUTION
During a synchronization, half of the switch fabric is lost. When the primary MSM finishes replicating its
configurations and images to the backup MSM, the full switch fabric is restored.
In addition to replicating the configuration settings and images, this command also replicates which
configuration or image the MSM should use on subsequent reboots. This command does not replicate
the run-time configuration. You must use the save configuration command to store the run-time
configuration first.
730
As soon as you see the BOOTLOADER> prompt (BlackDiamond 10K or Summit X450 switch) or the
BootRom -> prompt (BlackDiamond 8800 family of switches and the BlackDiamond 12804 switch),
release the spacebar. You can issue a series of commands to:
Load a recovery image over the serial port (BlackDiamond 10K switch only).
To see a list of available commands or additional information about a specific command, enter h or
type help.
The following describes some ways that you can use the Bootloader.
Viewing imagesTo display a list of installed images, use the show image command.
Selecting an imageTo change the image that the switch boots from in flash memory, use the boot
{image number} command. If you specify image number, the specified image is booted. If you do
not specify an image number, the default image is booted.
Selecting a configurationTo select a different configuration from the one currently running, use the
config {alt | default | <filename> | none} command. This command is useful if you
experience a problem with the current configuration and there is an alternate configuration available.
731
noneUses no configuration
To view the current configuration, use this command without any arguments.
To exit the Bootloader, use the boot command. Specifying boot runs the currently selected ExtremeWare
XOS image.
NOTE
The Summit X450 switch does not support user-created VRs.
732
For detailed information and instructions on accessing the bootloader, see Accessing the Bootloader
on page 731.
on-demandSpecifies the switch to prompt you to upgrade the firmware when ExtremeWare XOS
determines that a newer firmware image is available. This is the default behavior.
You can use the install firmware {force} command to install the firmware bundled with the
ExtremeWare XOS image. To install the new BootROM and firmware, wait until the show slot
command indicates the MSM and I/O modules are operational. When the modules are operational, use
the install firmware command.
NOTE
Specify the force parameter only under guidance from Extreme Networks Technical Support personnel. Forcing a
firmware upgrade may cause incompatibility issues between the firmware and the software installed on the MSM.
733
NOTE
Upgrading the firmware on a BlackDiamond 12804 switch can take a minimum of 6 minutes per slot.
To install the new BootROM and firmware, wait until the show slot command indicates the MSMs and
I/O modules are operational. When the modules are operational, use the install firmware command
to install the BootROM and/or firmware only on modules that have older BootROM or firmware
images installed.
734
NOTE
When you use the install firmware command to install the new BootROM and firmware images, all of the I/O
modules enter the Down state. Upgrade the firmware when you can schedule a downtime for your network.
If the bundled firmware image is newer than the existing firmware image, the switch prompts you to
confirm the upgrade. Enter y to upgrade the firmware. Enter n to cancel the firmware upgrade for the
specified hardware and continue scanning for other hardware that needs to be upgraded. Enter <cr> to
cancel the upgrade. The PSU controller firmware is used immediately after it is installed without
rebooting the switch. The new BootROM and firmware overwrite the older versions flashed into the
hardware. If you upgrade the firmware image, a reboot is required. Use the reboot command to reboot
the switch.
On a single MSM system, reboot the switch using the reboot command after the firmware installation
is complete.
On dual MSM systems, the install firmware command cannot install all of the necessary software
while the MSM is primary. To completely install the firmware, an MSM failover is required. To do this,
complete the following:
1 On the primary MSM, issue the install firmware command to install the new BootROM and/or
firmware images.
2 When the installation is complete, initiate failover to the backup MSM using the run msm-failover
command.
3 On the new primary MSM, issue the install firmware command to install the remaining firmware
images.
4 When the installation is complete, return to your original primary MSM by initiating failover from
the new backup MSM to the original primary MSM using the run msm-failover command.
NOTE
Because two failovers are required for a dual-MSM firmware installation, you do not use the reboot command
after executing the firmware installation.
During the firmware upgrade, do not cycle down or disrupt the power to the switch. If a power
interruption occurs, the firmware may be corrupted and need to be recovered. ExtremeWare XOS
automatically attempts to recover corrupted firmware; however, in some situations user intervention is
required.
After a firmware image upgrade, messages are sent to the log.
735
For detailed information and instructions on accessing the bootloader, see Accessing the Bootloader
on page 731.
IMG: 11.4.0.15
Image
:
:
:
:
:
:
:
:
:
:
:
:
:
804300-00-09
804403-00-08
804406-00-02
804406-00-02
0438F-00850
0405F-00063
0511F-00605
0511F-00602
Rev
Rev
Rev
Rev
9.0
8.0 BootROM: 1.3.0.0
2.0
2.0
804301-00-09
804301-00-09
704025-00-06
704025-00-06
0434F-00125
0437F-00026
0438F-00089
0438F-00096
Rev
Rev
Rev
Rev
9.0
9.0
6.0
6.0
BootROM:
BootROM:
BootROM:
BootROM:
1.0.1.5
1.0.1.5
5.3
5.3
IMG: 11.4.0.23
IMG: 11.4.0.25
IMG: 11.4.0.23
Image
The following is sample output from the BlackDiamond 8800 family of switches:
Chassis
Slot-1
Slot-2
Slot-3
736
:
:
:
:
800129-00-02
800114-00-04
800115-00-02
800113-00-04
04344-00039
04364-00021
04344-00006
04354-00031
Rev
Rev
Rev
Rev
2.0
4.0 BootROM: 1.0.1.7
2.0 BootROM: 1.0.1.7
4.0 BootROM: 1.0.1.7
IMG: 11.4.0.23
IMG: 11.4.0.23
IMG: 11.4.0.23
:
:
:
:
:
:
:
:
:
:
:
IMG: 11.4.0.23
IMG: 11.4.0.23
800112-00-03
800112-00-03
450117-00-01
450117-00-01
IMG: 11.4.0.23
IMG: 11.4.0.23
04334-00040
04334-00004
04334-00021
04334-00068
Rev
Rev
Rev
Rev
3.0
3.0
1.0
1.0
BootROM:
BootROM:
BootROM:
BootROM:
1.0.1.7
1.0.1.7
2.13
2.13
Image
06065-00549
05234-00033
05404-00055
05474-00070
05234-00026
05394-00007
Rev
Rev
Rev
Rev
Rev
Rev
9.0
1.0
2.0
3.0
1.0
2.0
uC: 2.01
uC: 2.01
uC: 2.01
uC: 2.01
BootROM:
FPGA: 5.07
FPGA: 5.07
FPGA: 5.07
FPGA: 5.07
1.0.0.2
IMG: 11.4.0.25
IMG: 11.4.0.25
uC:
uC:
Image
737
738
Troubleshooting
Inserting Powered Devices in the PoE ModuleBlackDiamond 8800 Family of Switches Only on
page 766
Modifying the Hardware Table Hash AlgorithmBlackDiamond 8800 Family of Switches and the
Summit X450 Switch Only on page 767
Untagged Frames on the 10 Gbps ModuleBlackDiamond 10K Switch Only on page 768
Running MSM Diagnostics from the BootloaderBlackDiamond 10K Switch Only on page 768
If you encounter problems when using the switch, this appendix may be helpful. If you have a problem
not listed here or in the release notes, contact Extreme Networks Technical Support.
Troubleshooting Checklists
This section provides simple troubleshooting checklists for Layer 1, Layer 2, and Layer 3. The
commands and recommendations described are applicable to both IPv4 and IPv6 environments unless
otherwise specified. If more detailed information about a topic is available, you are referred to the
applicable section in this appendix.
Layer 1
When troubleshooting Layer 1 issues, verify:
739
Troubleshooting
The behavior of LED status lights. For additional information about LEDs, see LEDs on page 743.
That the port is enabled, the link status is active, and speed and duplex parameters match the port
settings at the other end of the cable.
To display the configuration of one or more ports, use the show ports configuration command.
Layer 2
When troubleshooting Layer 2 issues, verify:
That the MAC addresses are learned, in the correct Virtual LAN (VLAN), and are not blackhole
entries.
To display FDB entries, use the show fdb command.
Your VLAN configuration, including the VLAN tag, ports in the VLAN, and whether or not the
ports are tagged.
To display detailed information for each VLAN configured on the switch, use the show vlan detail
command.
For additional VLAN troubleshooting tips, see VLANs on page 748.
Your Spanning Tree Protocol (STP) configuration, including the STP domain (STPD) number, VLAN
assignment, and port state.
To display STP information, use the following commands:
show vlan stpdDisplays the STP configuration of the ports assigned to a specific VLAN
Layer 3
When troubleshooting Layer 3 issues, verify:
That IP forwarding is enabled, the routing protocol is globally enabled, and the routing protocol is
enabled for a VLAN.
To display the configuration information for a specific VLAN, use one of the following commands:
740
Troubleshooting Checklists
Which destination networks are in the routing table and the source of the routing entry.
To display the contents of the routing table or the route origin priority, use one of the following
commands:
To display the contents of the routing table only for routes of a specified origin, use one of the
following commands:
That the IP Address Resolution Protocol (ARP) table has the correct entries.
NOTE
The ARP table is applicable only in IPv4 environments.
To display the contents of the IP ARP table, use the show iparp command.
That the Neighbor Discovery (ND) cache has the correct entries.
NOTE
The ND cache is applicable only in IPv6 environments.
To display the contents of the ND cache, use the show neighbor-discovery cache ipv6
command.
Your Open Shortest Path First (OSPF) configuration, including the OSPF area ID, router state, link
cost, OSPF timers, interface IP address, and neighbor list.
NOTE
OSPF is applicable only in IPv4 environments.
Your OSPFv3 configuration, including the OSPFv3 area ID, router state, link cost, OSPFv3 timers,
interface IP address, and neighbor list.
NOTE
OSPFv3 is applicable only in IPv6 environments.
741
Troubleshooting
To display OSPFv3 information, use the following commands:
Your Routing Information Protocol (RIP) configuration, including RIP poison reverse, split horizon,
triggered updates, transmit version, and receive version.
NOTE
RIP is applicable only in IPv4 environments.
To display detailed information about how you have RIP configured on the switch, use the show
rip command.
To display RIP-specific statistics for all VLANs, use the show rip interface detail command.
Your RIP next generation (RIPng) configuration, including RIPng poison reverse, split horizon,
triggered updates, transmit version, and receive version.
NOTE
RIPng is applicable only in IPv6 environments.
To display detailed information about how you have RIPng configured on the switch, use the show
ripng command.
To display RIPng-specific statistics for all VLANs, use the show ripng interface command.
End-to-end connectivity.
To test for connectivity to a specific host, use the ping command.
The routed path between the switch and a destination end station.
To verify and trace the routed path, use the traceroute command.
742
LEDs
LEDs
Power LED does not light:
Check that the power cable is firmly connected to the device and to the supply outlet.
On powering-up, the MGMT LED lights yellow:
The device has failed its Power On Self Test (POST) and you should contact your supplier for advice.
A link is connected, but the Status LED does not light:
Check that:
Both ends of the Gigabit link are set to the same autonegotiation state.
The Gigabit link must be enabled or disabled on both sides. If the two sides are different, typically
the side with autonegotiation disabled will have the link LED lit, and the side with autonegotiation
enabled will not be lit. The default configuration for a Gigabit port is autonegotiation enabled. Verify
by entering the following command:
show ports configuration
If you continue to see critical software errors or the ERR LED is still amber after issuing the clear
log static command and a switch reboot, contact Extreme Networks Technical support for further
assistance.
Status LED on the I/O module turns amber:
Check the syslog message for a related I/O module error. If the error is an inserted I/O module that
conflicts with the software configuration, use one of the following commands to reset the slot
configuration:
clear slot
configure slot <slot> module <module_type>
743
Troubleshooting
ENV LED on the MSM turns amber:
Check each of the power supplies and all of the fans. Additionally, you display the status in the show
power and show fans displays.
9600 baud
8 data bits
1 stop bit
no parity
For console port access, you may need to press [Return] several times before the welcome prompt
appears.
744
The Simple Network Management Protocol (SNMP) access is enabled for the system.
The device IP address, subnet mask, and default router are correctly configured, and that the device
has been reset.
The device IP address is correctly recorded by the SNMP Network Manager (refer to the user
documentation for the Network Manager).
The community strings configured for the system and Network Manager are the same.
The SNMPv3 USM, Auth, and VACM configured for the system and Network Manager are the
same.
The device IP address, subnet mask, and default router are correctly configured, and that the device
has been reset.
You entered the IP address of the switch correctly when invoking the Telnet facility.
If you attempt to log in and the maximum number of Telnet sessions are being used, you should receive
an error message indicating so.
Traps are not received by the SNMP Network Manager:
Check that the SNMP Network Manager's IP address and community string are correctly configured,
and that the IP address of the Trap Receiver is configured properly on the system.
The SNMP Network Manager or Telnet workstation can no longer access the device:
Check that:
The port through which you are trying to access the device has not been disabled. If it is enabled,
check the connections and network cabling at the port.
The port through which you are trying to access the device is in a correctly configured Virtual LAN
(VLAN).
The community strings configured for the device and the Network Manager are the same.
Try accessing the device through a different port. If you can now access the device, a problem with the
original port is indicated. Re-examine the connections and cabling.
A network problem may be preventing you from accessing the device over the network. Try accessing
the device through the console port.
Permanent entries remain in the FDB:
If you have made a permanent entry in the FDB that requires you to specify the VLAN to which the
entry belongs and then deleted the VLAN, the FDB entry remains. Although this does not harm the
system, if you want to removed the entry, you must manually delete it from the FDB.
745
Troubleshooting
Default and static routes:
If you have defined static or default routes, those routes remain in the configuration independent of
whether the VLAN and VLAN IP address that used them remains. You should manually delete the
routes if no VLAN IP address is capable of using them.
You forget your password and cannot log in:
If you are not an administrator, another user having administrator access level can log in, delete your
user name, and create a new user name for you, with a new password.
Alternatively, another user having administrator access level can log in and initialize the device. This
will return all configuration information (including passwords) to the initial values.
In the case where no one knows a password for an administrator level user, contact your supplier.
You have user privileges, not administrator privileges, on the backup MSM:
If you establish a console connection to access the backup MSM, only user privileges are available. This
is true regardless of the privileges configured on the primary MSM. If you enter an administrator level
command on the backup MSM, the switch displays a message stating that the command is only
supported on the primary MSM.
Command Prompt
You do not know if the switch configuration has been saved:
If an asterisk (*) precedes the command prompt, a new change to the switch configuration has not been
saved. To save the configuration, use the save configuration command. After you save the
configuration, the asterisk (*) no longer precedes the command prompt.
You do not know if you are logged in as an administrator or a user:
Observe the console prompt. If you are logged in as an administrator, the prompt ends with the hash
symbol(#). If you are logged in as a user, the prompt ends with a greater than sign (>).
The following is sample output from an administrator-level account:
BD-10808.1 #
746
Port Configuration
No link light on 10/100 Base port:
If patching from a switch to another switch, ensure that you are using a category 5 (CAT5) crossover
cable. This is a CAT5 cable that has pins 1 and 2 on one end connected to pins 3 and 6 on the other end.
Excessive RX CRC errors:
When a device that has autonegotiation disabled is connected to an Extreme Networks switch with
autonegotiation enabled, the Extreme Networks switch links at the correct speed, but in half-duplex
mode. The Extreme Networks switch 10/100 physical interface uses a method called parallel detection to
bring up the link. Because the other network device is not participating in autonegotiation (and does
not advertise its capabilities), parallel detection on the Extreme Networks switch is able only to sense
10 Mbps versus 100 Mbps speed and not the duplex mode. Therefore, the switch establishes the link in
half-duplex mode using the correct speed.
The only way to establish a full-duplex link is either to force it at both sides, or run autonegotiation on
both sides (using full-duplex as an advertised capability, which is the default setting on the Extreme
Networks switch).
NOTE
A mismatch of duplex mode between the Extreme switch and another network device causes poor network
performance. Viewing statistics using the show ports rxerrors command on the Extreme Networks switch may
display a constant increment of CRC errors. This is characteristic of a duplex mismatch between devices. This is
NOT a problem with the Extreme Networks switch.
Always verify that the Extreme Networks switch and the network device match in configuration for
speed and duplex.
No link light on Gigabit fiber port:
Check that:
The transmit fiber goes to the receive fiber side of the other device and vice-versa. All Gigabit fiber
cables are of the crossover type.
The Gigabit ports are set to Auto Off (using the command configure ports <port_list> auto
off speed [10 | 100 | 1000 | 10000] duplex [half | full]) if you are connecting the
Extreme Networks switch to devices that do not support autonegotiation.
By default, the Extreme Networks switch has autonegotiation set to On for Gigabit ports and set to
Off for 10 Gigabit ports.
You are using multimode fiber (MMF) when using a 1000BASE-SX Gigabit Ethernet Interface
Connector (GBIC), and single-mode fiber (SMF) when using a 1000BASE-LX GBIC. 1000BASE-SX
technology does not work with SMF. The 1000BASE-LX technology works with MMF but requires
the use of a mode conditioning patchcord (MCP).
747
Troubleshooting
VLANs
You cannot add a port to a VLAN:
If you attempt to add a port to a VLAN and get an error message similar to:
localhost:7 # configure vlan marketing add ports 1:1,1:2
Error: Protocol conflict when adding untagged port 1:1. Either add this port as tagged
or assign another protocol to this VLAN.
You already have a VLAN using untagged traffic on a port. Only one VLAN using untagged traffic can be
configured on a single physical port.
You verify the VLAN configuration using the following command:
show vlan {detail {ipv4 | ipv6} |<vlan_name> {ipv4 | ipv6} | virtual-router <vrrouter> | <vlan_name> stpd}
The solution for this error using this example is to remove ports 1 and 2 from the VLAN currently using
untagged traffic on those ports. If this were the default VLAN, the command would be:
localhost:23 # configure vlan default delete ports 1:1,1:2
VLAN names:
There are restrictions on VLAN names. They cannot contain whitespaces and cannot start with a
numeric value.
VLANs, IP addresses, and default routes:
The system can have an IP address for each configured VLAN. You must configure an IP address
associated with a VLAN if you intend to manage (Telnet, SNMP, ping) through that VLAN or route IP
traffic.
You can also configure multiple default routes for the system. The system first tries the default route
with the lowest cost metric.
STP
You have connected an endstation directly to the switch and the endstation fails to boot correctly:
The switch has the Spanning Tree Protocol (STP) enabled, and the endstation is booting before the STP
initialization process is complete. Specify that STP has been disabled for that VLAN, or turn off STP for
the switch ports of the endstation and devices to which it is attempting to connect; then, reboot the
endstation.
Spanning Tree Domain names:
There are restrictions on Spanning Tree Domain (STPD) names. They cannot contain whitespaces and
cannot start with a numeric value.
748
Another 802.1D mode STP port to a physical port that already contains an 802.1D mode STP port
(only one 802.1D encapsulation STP port can be configured on a particular STP port).
A carrier VLAN port to a different STP domain than the carrier VLAN belongs.
A VLAN and/or port for which the carrier VLAN does not yet belong.
NOTE
This restriction is only enforced in an active STPD and when you enable STP to make sure you have a legal STP
configuration.
Reduce the number of topology changes by disabling STP on those systems that do not use
redundant paths.
ESRP
ESRP names:
There are restrictions on Extreme Standby Router Protocol (ESRP) names. They cannot contain
whitespaces and cannot start with a numeric value.
You cannot enable an ESRP domain:
Before you enable a specific ESRP domain, it must have a domain ID. A domain ID is either a userconfigured number or the 802.1Q tag (VLANid) of the tagged master VLAN. The domain ID must be
identical on all switches participating in ESRP for that particular domain. If you do not have a domain
ID, you cannot enable ESRP on that domain.
Note the following on the interaction of tagging, ESRP, and ESRP domain IDs:
If you have an untagged Master VLAN, you must specify an ESRP domain ID.
If you have a tagged master VLAN, ESRP uses the 802.1Q tag (VLANid) of the master VLAN for the
ESRP domain ID. If you do not use the VLANid as the domain ID, you must specify a different
domain ID.
749
Troubleshooting
You cannot delete the master VLAN from the ESRP domain:
If you attempt to remove the master VLAN before disabling the ESRP domain, you see an error
message similar to the following:
ERROR: Failed to delete master vlan for domain "esrp1" ; ESRP is enabled!
If this happens:
Remove the master VLAN from the ESRP domain using the configure esrp delete master
command.
VRRP
You cannot define VRRP virtual router parameters:
Before configuring any virtual router parameters for VRRP, you must first create the VRRP instance on
the switch. If you define VRRP parameters before creating the VRRP, you may see an error similar to
the following:
Error: VRRP VR for vlan vrrp1, vrid 1 does not exist.
Please create the VRRP VR before assigning parameters.
Configuration failed on backup MSM, command execution aborted!
If this happens,:
Create a VRRP instance using the create vrrp vlan vrid command.
750
Configure transmission of ELRP packets on specified ports of a VLAN periodically with the added
ability to configure the interval between consecutive timings.
You can specify the number of times ELRP packets must be transmitted and the interval between
consecutive transmissions.
A message is printed to the console and logged into the system log file indicating detection of
network loop when ELRP packets are received back or no packets are received within the
specified duration.
If ELRP packets are received back, a message is printed to the system log file and a trap is sent to
the SNMP manager indicating detection of a network loop.
751
Troubleshooting
The ELRP client can be disabled globally so that none of the ELRP VLAN configurations take effect. To
globally disable the ELRP client, use the following command:
disable elrp-client
To start one-time, non-periodic ELRP packet transmission on specified ports of a VLAN using a
particular count and interval, use one of the following commands:
These commands start one-time, non-periodic ELRP packet transmission on the specified ports of the
VLAN using the specified count and interval. If any of these transmitted packets is returned, indicating
loopback detection, the ELRP client can perform a configured action such as logging a message in the
system log file or printing a log message to the console. There is no need to trap to the SNMP manager
for non-periodic requests.
To start periodic ELRP packet transmission on specified ports of a VLAN using a particular interval, use
one of the following commands:
configure elrp-client periodic <vlan_name> ports [<ports> | all] interval <sec> [log |
log-and-trap | trap]
This command starts periodic ELRP packet transmission on the specified ports of the VLAN using the
specified interval. If any of these transmitted packets is returned, indicating loopback detection, the
ELRP client can perform a configured action such as logging a message in the system log file and/or
sending a trap to the SNMP manager.
To disable a pending one-shot or periodic ELRP request for a specified VLAN, use the following
command:
unconfigure elrp-client <vlan_name>
For more detailed information about the output associated with the show elrp command, see the
ExtremeWare XOS Command Reference Guide.
752
The concept of a rescue software image was introduced in ExtremeWare XOS 11.1. The rescue software
image recovers a switch that does not boot up by initializing the internal compact flash and installing
the ExtremeWare XOS software on both primary and secondary images of the compact flash. To use the
rescue software image, you must be running ExtremeWare XOS 11.1 or later. Earlier versions of
ExtremeWare XOS do not support the rescue software image.
Beginning with ExtremeWare XOS 11.3, the BlackDiamond 8800 family of switches support loading the
rescue image to the external compact flash memory card installed in the MSM. For more information
see Obtaining the Rescue Image from an External Compact Flash Memory CardBlackDiamond 8800
Family of Switches Only on page 754.
Before you begin the recovery process, collect the following information:
IP address of the Trivial File Transfer Protocol (TFTP) server that contains the ExtremeWare XOS
image
ExtremeWare XOS image filename (the image has a .xos filename extension)
NOTE
The rescue process initializes the primary and secondary images with the ExtremeWare XOS software image. No
additional software packages or configuration files are preserved or installed. This process takes a minimum of 7
minutes to complete. To install additional modular software packages, BootROM images (BlackDiamond 10K switch
only), and configuration files, see Appendix A, Software Upgrade and Boot Options, for more information.
9600 baud
8 data bits
1 stop bit
no parity
3 Reboot the MSM and press the spacebar key on the keyboard of the terminal during the boot up
process.
753
Troubleshooting
NOTE
You must press the spacebar key immediately after a power cycle of the MSM in order to get into the Bootloader
application.
On the BlackDiamond 12804 and the BlackDiamond 8800 family of switches, when you see the BootRom
banner, press the spacebar key to get into the Bootloader application.
As soon as you see the BOOTLOADER -> prompt (BlackDiamond 10K switch) or the BootRom ->
prompt (BlackDiamond 8800 family of switches and BlackDiamond 12804 switch), release the
spacebar. From here, you can begin the recovery process.
To obtain the rescue image and recover the switch:
1 Provide the network information (IP address, netmask, and gateway) for the switch using the
following command:
configip ipaddress <ip-address>[/<netmask>] gateway <gateway-address>
tftp-addressSpecifies the IP address of the TFTP server that contains the ExtremeWare
XOS image
If you attempt to download a non-rescue image, the switch displays an error message and returns
you to the BOOTLOADER -> (BlackDiamond 10K switch) or the BootRom -> (BlackDiamond 8800
family of switches and BlackDiamond 12804 switch) command prompt.
After you download the ExtremeWare XOS image file, the switch installs the software and reboots. After
the switch reboots, the switch enters an uninitialized state. At this point, configure the switch and save
your configuration. In addition, if you previously had modular software packages installed, you must
re-install the software packages to each switch partition. For more information about installing software
packages, see Appendix A, Software Upgrade and Boot Options.
If you are unable to recover the switch with the rescue image, or the switch does not reboot, contact
Extreme Networks Technical Support.
754
9600 baud
8 data bits
1 stop bit
no parity
5 Provide power to the switch by re-inserting the power cords into the power supplies.
6 Immediately press the spacebar until the BootRom -> prompt appears.
NOTE
You must press the spacebar key immediately after a power cycle of the MSM in order to get into the Bootloader
application.
As soon as you see the BootRom -> prompt, release the spacebar. From here, you can begin the
recovery process.
To obtain the rescue image that you placed on the compact flash memory card and recover the switch:
1 Download the ExtremeWare XOS image that is already on the external compact flash memory card
using the following command:
boot file <filename>
Where the filename specifies the image file for the BlackDiamond 8800 family of switches.
2 At the BootRom -> prompt, press [Return]. The following message appears:
ok to continue
Type YES to begin the recovery process. This takes a minimum of 7 minutes.
3 After the process runs, the BootRom -> prompt displays the following message:
****press enter to reboot*****
Press [Return] to reboot the switch. The switch reboots and displays the login prompt. You have
successfully completed the setup from the external compact flash memory card.
4 Remove the external compact flash memory card installed in the MSM.
755
Troubleshooting
After you download the ExtremeWare XOS image file, the switch installs the software and reboots. After
the switch reboots, the switch enters an uninitialized state. At this point, configure the switch and save
your configuration. In addition, if you previously had modular software packages installed, you must
re-install the software packages to each switch partition. For more information about installing software
packages, see Appendix A, Software Upgrade and Boot Options.
If you are unable to recover the switch with the rescue image, or the switch does not reboot, contact
Extreme Networks Technical Support.
Debug Mode
The Event Management System (EMS) provides a standard way to filter and store messages generated
by the switch.With EMS, you must enable debug mode to display debug information. You must have
administrator privileges to use these commands. If you do not have administrator privileges, the switch
rejects the commands.
To enable or disable debug mode for EMS, use the following commands:
enable log debug-mode
disable log debug-mode
After debug mode has been enabled, you can configure EMS to capture specific debug information from
the switch. Details of EMS can be found in Chapter 9, Status Monitoring and Statistics.
The core dump file contains a snapshot of the process when the error occurred.
NOTE
Use the commands described in this section only under the guidance of Extreme Networks Technical Support
personnel to troubleshoot the switch.
756
internal-memorySpecifies that saving debug information to the internal memory card is enabled.
Use this parameter only under the guidance of Extreme Networks Technical Support personnel.
memorycardSpecifies that saving debug information to the external memory card is enabled. Use
this parameter only under the guidance of Extreme Networks Technical Support personnel. (This
parameter is available only on modular switches.)
offSpecifies that saving debug information to the external memory card is disabled. This is the
default behavior.
Core dump files have a .gz file extension. The filename format is: core.<process-name.pid>.gz where
process-name indicates the name of the process that failed and pid is the numerical identifier of that
process. If you have a modular switch and save core dump files to the external memory card, the
filename also includes the affected MSM: MSM-A or MSM-B.
If you configure the switch to write core dump files to the internal memory card and attempt to
download a new software image, you might have insufficient space to complete the image download. If
this occurs, you must decide whether to continue the software download or move or delete the core
dump files from the internal memory. For example, if you have a modular switch with an external
memory card installed with space available, transfer the files to the external memory card. On the
Summit X450 switch, transfer the files from the internal memory card to a TFTP server. This frees up
space on the internal memory card while keeping the core dump files.
Modular Switches OnlyAfter the switch writes a core dump file or other debug information to the
external memory card, and before you can view the contents on the card, you must ensure it is safe to
remove the card from the external compact flash slot on the MSM. Use the eject memorycard
command to prepare the card for removal. After you issue the eject memorycard command, you can
manually remove the card from the external compact flash slot on the MSM am read the data on the
card.
To access and read the data on the card, use a PC with appropriate hardware such as a compact flash
reader/writer and follow the manufacturers instructions to access the compact flash card and read the
data.
757
Troubleshooting
For information about managing the configuration or policy files stored on your system, see Chapter 4,
Managing the ExtremeWare XOS Software.
NOTE
Filenames are case-sensitive. For information on filename restrictions, refer to the specific command in the
ExtremeWare XOS Command Reference Guide.
Displaying Files
To display a list of the files stored on your card, including core dump files, use the following command:
ls {internal-memory | memorycard}
internal-memoryLists the core dump files that are present and saved in the internal memory card.
If the switch has not saved any debug files, no files are displayed.
memorycardLists all files, including the core dump files, that are stored in the external compact
flash memory card. (This parameter is available only on modular switches.)
Output from this command includes the file size, date and time the file was last modified, and the file
name.
For more information about this command, including managing the configuration or policy files stored
on your system, see Chapter 4, Managing the ExtremeWare XOS Software.
758
old-name-internalSpecifies the current name of the core dump file located on the internal
memory card.
new-name-internalSpecifies the new name of the core dump file located on the internal memory
card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
old-name-memorycardSpecifies the current name of the core dump file located on the external
compact flash memory card. (This parameter is available only on modular switches.)
new-name-memorycardSpecifies the new name of the core dump file located on the external
compact flash memory card. (This parameter is available only on modular switches.)
For more information about this command, including managing the configuration or policy files stored
on your system, see Chapter 4, Managing the ExtremeWare XOS Software.
Copying Files
The copy function allows you to make a copy of an existing file before you alter or edit the file. By
making a copy, you can easily go back to the original file if needed.
To copy an core dump file, use the following command:
cp [internal-memory <old-name-internal> internal-memory <new-name-internal> |
internal-memory <old-name-internal> memorycard <new-name-memorycard> | memorycard
<old-name-memorycard> memorycard <new-name-memorycard> | memorycard <old-namememorycard> <new-name> | <old-name> memorycard <new-name-memorycard> | <old-name>
<new-name>]
old-name-internalSpecifies the name of the core dump file located on the internal memory card
new-name-internalSpecifies the name of the newly copied core dump file located on the internal
memory card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
old-name-memorycardSpecifies the name of the core dump file located on the external compact
flash memory card. (This parameter is available only on modular switches.)
759
Troubleshooting
new-name-memorycardSpecifies the name of the newly copied core dump file located on the
external compact flash memory card. (This parameter is available only on modular switches.)
By making a copy of a core dump file, you can easily compare new debug information with the old file
if needed.
If you configure the switch to send core dump (debug) information to the internal memory card, specify
the internal-memory option to copy an existing core dump file. If you have a modular switch with an
external compact clash memory card installed, you can copy the core dump file to that card.
For more information about this command, including managing the configuration or policy files stored
on your system, see Chapter 4, Managing the ExtremeWare XOS Software.
Transferring Files
TFTP allows you to transfer files to and from the switch, internal memory card, and on a modular
switch, the external memory card. To transfer a core dump file, use the tftp, tftp get, and tftp put
commands.
tftp [<host-name> | <ip-address>] {-v <vr_name>} [-g | -p] [{-l [internal-memory
<local-file-internal> | memorycard <local-file-memcard> | <local-file>} {-r <remotefile>} | {-r <remote-file>} {-l [internal-memory <local-file-internal> | memorycard
<local-file-memcard> | <local-file>]}]
tftp get [<host-name> | <ip-address>] {-vr <vr_name>} [{[internal-memory <local-fileinternal> | memorycard <local-file-memcard> | <local_file>} {<remote_file>} |
{<remote_file>} {[internal-memory <local-file-internal> | memorycard <local-filememcard> | <local_file>]}] {force-overwrite}
tftp put [<host-name> | <ip-address>] {-vr <vr_name>} [{[internal-memory <local-fileinternal> | memorycard <local-file-memcard> | <local_file>} {<remote_file>} |
{<remote_file>} {[internal-memory <local-file-internal> | memorycard <local-filememcard> | <local_file>]}]
NOTE
The BlackDiamond 8800 family of switches and the Summit X450 switch do not support user-created VRs.
760
-gGets the specified file from the TFTP server and copies it to the local host. (This parameter is
available only on the tftp command.)
getGets the specified file from the TFTP server and copies it to the local host. (This is part of the
tftp get command.)
-pPuts the specified file from the local host and copies it to the TFTP server. (This parameter is
available only on the tftp command.)
putPuts the specified file from the local host and copies it to the TFTP server. (This is part of the
tftp put command.)
local-file-internalSpecifies the name of the core dump file located on the internal memory
card.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
local-file-memcardSpecifies the name of the file on the external compact flash card. (This
parameter is available only on modular switches.)
local-fileSpecifies the name of the file (configuration file, policy file) on the local host.
NOTE
By default, if you transfer a file with a name that already exists on the system, the switch prompts you to
overwrite the existing file. For more information, see the tftp get command in the ExtremeWare XOS
Command Reference Guide.
If you configure the switch to send core dump information to the internal memory card, specify the
internal-memory option to transfer an existing core dump file from the internal memory card to the
TFTP server. If you have a modular switch with an external compact clash memory card installed,
specify the memorycard option to transfer an existing core dump file from the external memory card to
the TFTP server.
For more information about TFTP, see Chapter 3, Managing the Switch. For more information about
managing the configuration or policy files stored on your system, see Chapter 4, Managing the
ExtremeWare XOS Software. For detailed information about downloading software image files,
BootROM files, and switch configurations, see Chapter A, Software Upgrade and Boot Options.
Deleting Files
To delete a core dump file from your card, use the following command:
rm {internal-memory | memorycard} <file-name>
If you have core dump files stored in the internal memory and you attempt to download a new
software image, you might have insufficient space to complete the image download. If this happens,
delete core dump files from the internal memory.
For example, if you have a modular switch with an external memory card installed with space
available, transfer the files to the external memory card. On the Summit X450 switch, transfer the
files from the internal memory card to a TFTP server. This frees up space on the internal memory
card while keeping the core dump files.
memorycardSpecifies the removable external compact flash memory card. (This parameter is
available only on modular switches.)
If you delete a core dump file from the system, that file is unavailable.
You can use the * wildcard to delete core dump files from the internal memory card.
761
Troubleshooting
For more information about this command, including managing the configuration or policy files stored
on your system, see Chapter 4, Managing the ExtremeWare XOS Software.
Sentriant-installed ACLs
CFM-installed ACLs
ACLs applied with a policy file (see Chapter 14, Access Lists (ACLs) for precedence among these
ACLs)
For information on policy files and ACLs, see Chapter 13, Policy Manager and Chapter 14, Access
Lists (ACLs).
TOP Command
The top command is a UNIX-based command that displays real-time CPU utilization information by
process. The output contains a list of the most CPU-intensive tasks and can be sorted by CPU usage,
memory usage, and run time. For more detailed information about the top command, refer to your
UNIX documentation.
BlackDiamond 10K
For all switches, system health check errors are reported to the syslog. If you see an error, contact
Extreme Networks Technical Support.
For more detailed information about the system health checker, including a configuration example, see
Chapter 9, Status Monitoring and Statistics.
762
Polling is always enabled on the system and occurs every 60 seconds by default. The system health
checker polls and tracks the ASIC counters that collect correctable and uncorrectable packet memory
errors, check sum errors, and parity errors on a per ASIC basis. By reading and processing the
registers, the system health check detects and associates faults to specific system ASICs.
Backplane diagnostic packets are disabled by default. After this feature is enabled, the system health
checker tests the packet path for a specific I/O module every 6 seconds by default. The Management
Switch Fabric Module (MSM) sends and receives diagnostic packets from the I/O module to
determine the state and connectivity. (The other I/O modules with backplane diagnostic packets
disabled continue polling every 60 seconds by default.)
Polling is always enabled on the system and occurs every 5 seconds by default. The polling value is
not a user-configured parameter. The system health check polls the control plane health between
MSMs and I/O modules, monitors memory levels on the I/O module, monitors the health of the
I/O module, and checks the health of applications and processes running on the I/O module. If the
system health checker detects an error, the health checker notifies the MSM.
Backplane diagnostic packets are disabled by default. If you enable this feature, the system health
checker tests the data link for a specific I/O module every 5 seconds by default. The MSM sends and
receives diagnostic packets from the I/O module to determine the state and connectivity. If you
disable backplane diagnostics, the system health checker stops sending backplane diagnostic packets.
BlackDiamond 10K and the BlackDiamond 12804 series switchesBy default, the system health
checker tests the packet path every 6 seconds for the specified slot.
BlackDiamond 8800 family of switchesBy default, the system health checker tests the data link
every 5 seconds for the specified slot.
NOTE
Enabling backplane diagnostic packets increases CPU utilization and competes with network traffic for resources.
763
Troubleshooting
To disable backplane diagnostic packets, use the following command:
disable sys-health-check slot <slot>
BlackDiamond 10K and the BlackDiamond 12804 series switchBy default, the system health
checker discontinues sending backplane diagnostic packets and returns the polling frequency to
60 seconds on the specified slot. Only polling is enabled.
BlackDiamond 8800 family of switchesBy default, the system health checker discontinues sending
backplane diagnostic packets to the specified slot. Only polling is enabled.
NOTE
Extreme Networks does not recommend configuring an interval of less than the default interval. Doing so can cause
excessive CPU utilization.
System Odometer
Each field replaceable component contains a system odometer counter in EEPROM. The show
odometers command displays an approximate days of service duration for an individual component
since the component was manufactured.
Monitored Components
On a modular switch, the odometer monitors the following components:
Chassis
MSMs
I/O modules
Power controllers
On the Summit X450 switch, the odometer monitors the following components:
Switch
XGN-2xn card
Recorded Statistics
The following odometer statistics are collected by the switch:
Service DaysThe amount of days that the component has been running
First Recorded Start DateThe date that the component was powered-up and began running
Depending on the software version running on your switch, the modules installed in your switch, and
the type of switch you have, additional or different odometer information may be displayed.
764
System Odometer
The following is sample output from a BlackDiamond 10K switch:
Field Replaceable Units
----------------------Chassis
: BD-10808
Slot-1
: G60X
Slot-2
: G60X
Slot-3
: G60X
Slot-4
:
Slot-5
: 10G6X
Slot-6
:
Slot-7
: G60T
Slot-8
: 10G6X
MSM-A
: MSM-1XL
MSM-B
: MSM-1XL
PSUCTRL-1 :
PSUCTRL-2 :
Service
Days
------107
99
74
151
First Recorded
Start Date
-------------Feb-23-2004
Dec-10-2003
Mar-22-2004
Jan-12-2004
49
Apr-09-2004
184
146
62
172
152
Dec-03-2003
Jan-12-2004
Apr-21-2004
Dec-14-2003
Mar-17-2004
The following is sample output from the BlackDiamond 8800 family of switches:
Field Replaceable Units
------------------------Chassis
: BD-8810
Slot-1
: G48T
Slot-2
: 10G4X
Slot-3
: G48T
Slot-4
: G24X
Slot-5
: G8X
Slot-6
:
Slot-7
: 10G4X
Slot-8
: 10G4X
Slot-9
: G48P
Slot-10
:
MSM-A
: MSM-G8X
MSM-B
:
PSUCTRL-1 :
PSUCTRL-2 :
Service
Days
------209
208
219
228
226
139
First Recorded
Start Date
-------------Dec-07-2004
Dec-07-2004
Nov-02-2004
Oct-26-2004
Oct-19-2004
Dec-07-2004
160
133
111
Dec-16-2004
Dec-14-2004
Nov-04-2004
137
Dec-07-2004
209
208
Dec-07-2004
Dec-07-2004
Days
------40
20
Start Date
-------------Sep-22-2005
Nov-10-2005
20
Nov-10-2005
20
20
0
Nov-10-2005
Nov-10-2005
Nov-05-2005
765
Troubleshooting
PSUCTRL-2
Nov-05-2005
Service
Days
------7
First Recorded
Start Date
-------------Dec-08-2004
766
Modifying the Hardware Table Hash AlgorithmBlackDiamond 8800 Family of Switches and the Summit X450 Switch Only
In this situation, you can configure a different hash algorithm to select a different section of the
hardware to store addresses. You must save your configuration and reboot the switch to modify the
hash algorithm used by the hardware table.
NOTE
Modify the hardware table hash algorithm only with the guidance of Extreme Networks technical personnel.
After you enter the command, the switch displays a message similar to the following:
Warning:
This command will only take effect after a save and reboot
To use the new hash algorithm, save your switch configuration and reboot the switch. By default, the
hash algorithm is crc16.
To view the hardware table settings on the switch, including the configured hash algorithm and the
current hash algorithm, use the following command:
show forwarding configuration
767
Troubleshooting
As soon as you see the BOOTLOADER> prompt, release the key. From here, you can run the diagnostics
on the MSM.
To run diagnostics on the MSM:
1 Identify the currently running software images by using the show images command.
2 Run diagnostics on the MSM by using the boot [1-4] command.
The numbers 1 through 4 correlate to specific images and diagnostics on the MSM:
For example, to run diagnostics on the primary image, use the following command:
boot 3
When the test is finished, the MSM reboots and runs the ExtremeWare XOS software.
768
(800) 998-2408
(408) 579-2826
Or by email at:
support@extremenetworks.com
769
Troubleshooting
770
CNA Agent
The entire CNA software package consists of multiple parts. The Extreme Networks devices run only
the CNA Agent. You must have the entire package; you cannot use the CNA Agent without the CNA
software from Avaya. The user interface is a combination of a Java applet hosted from the CNA Server
and a command line interface (CLI). You configure and manage the CNA Agent using the CLI.
NOTE
Contact your Avaya representative to obtain the rest of the CNA software and the associated documentation.
If you are using Avaya CNA solutions, you download a separate software module to add the CNA
Agent to ExtremeWare XOS 11.2 software; this software module runs on all platforms.
NOTE
You must download and install the SSH software module before downloading and installing the CNA Agent software
module.
This appendix covers the following topics regarding the CNA Agent:
Overview
The CNA Agent accepts requests (from the CNA Server) to run tests for measuring and verifying
network performance, and the CNA Agent reports back the results to the CNA Server. The CNA Agent
functions as a UDP service accepting authenticated requests from and returning test results to the CNA
Server.
You download the CNA Agent software as a separate software module onto your device. If you do not
have it already, you must also download the separate SSH software module, which contains SSL.
After you enable the software, the CNA Agent registers with the CNA Server and exchanges openSSL
keys, using a 128-bit encryption key. All following communication between the CNA Agent and the
CNA Server is encrypted.
The CNA Server communicates with the CNA Agent to request specific tests and to schedule those
tests. The CNA Agent runs the requested tests and sends the results back to the CNA Server.
The CNA Agent can register with one CNA Server, talk to one CNA Server at a time, and respond to
only one test request at a time. The other test requests are queued up.
771
CNA Agent
The system sends messages to the syslog for each new connection, the status of that connection,
received test requests, and reported test results. Also EMS messages are generated after successful
registration.
NOTE
You must download the SSH module before downloading the CNA module.
If you attempt to download the CNA software module and you have not already downloaded the SSH
software module, the system returns an error.
772
RTPEmulates VoIP traffic to measure delay, packet loss and jitter to another CNA Agent by
sending a simulated RTP stream that is echoed back
PingSends an ICMP echo message to a target IP address and reports whether or not a response
was returned
MergeUsed by CNA software to identify a single device with multiple IP addresses and to merge
its multiple appearances into one in the network topology map
Configure the IP address the CNA Agent uses to communicate with the CNA Server.
This step is optional. By default, the CNA Server uses the primary IP address on the switchs
Default VLAN.
This step is optional.
After you enable the CNA Agent, you register the CNA Agent with the CNA Server, and the CNA
Agent performs the requested network tests and reports the results.
To disable the CNA Agent, use the following command:
disable cna-testplug
You enter the IP address of the CNA Server. (With ExtremeWare XOS software version 11.2, this must be
an IPv4 address.)
After you configure the IP address for the CNA server, the CNA Agent and the CNA Server exchange
SSL keys and establish encryption. After successful registration, you can connect with more than one
CNA Server, in which case you share the encryption key you negotiated with your initial CNA Server
connection.
At this time, the system establishes the socket connection to the CNA Server using this IP address. The
CNA Agent listens for instructions for the testing from this IP address.
773
CNA Agent
If the VLAN has more than one IP address, the system uses the primary IP address.
NOTE
Extreme Networks recommends that you put IP telephones on the same virtual router.
This command clears the CNA Agent counters on the Extreme Networks devices and resets those
counters to 0.
You can also use the clear counters command, which clears all the counters on the device including
those associated with the CNA Agent.
774
NOTE
Adaptive Networking Software (ANS) runs on the CNA Server.
Troubleshooting
If the CNA Agent is not able to register with the CNA Server, check the following items:
To reset the time, use the configure time <month> <day> <year> <hour> <min> <sec>
command.
Ensure that the openSSL certificate on the CNA Server has not expired.
775
CNA Agent
776
This appendix provides a list of software standards and protocols supported by ExtremeWare XOS. This
appendix includes the following topics:
Virtual LANS (VLANs), Virtual MANs (VMANs) and MAC in MAC on page 777
Protocol-sensitive VLANs
Virtual MANs
777
IP Multicast
RFC 1112 Host extensions for IP multicasting (Internet
Group Management Protocol version 1)
778
IEEE-8021-PAE-MIB
IEEE8021X-EXTENSIONS-MIB
779
Management - Other
RFC 854 Telnet Protocol Specification
Telnet client and server
Secure Shell 2 (SSH2) client and server
Secure Copy 2 (SCP2) client and server
Configuration logging
Multiple Images, Multiple Configs
Security
Routing protocol authentication
IPv6
RFC 2460, Internet Protocol, Version 6 (IPv6)
Specification
RFC 2461, Neighbor Discovery for IP Version 6, (IPv6)
780
Standard MIBs
RFC 1213 (MIB-II)
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
Comments
All objects
Interfaces group
IP Group scalars
All objects
ipAddrTable
All objects
ipRouteTable
All objects
ipNetToMediaTable
All objects
ICMP group
All objects
All objects
tcpConnTable
All objects
All objects
udpTable
All objects
EGP Group
Not supported
SNMP group
All objects
At group
All objects
Supported Variables
Comments
IfNumber
ifTable
ifIndex
ifDescr
ifType
ifMtu
781
Table/Group
Supported Variables
Comments
ifSpeed
ifPhysAddress
ifAdminStatus
ifOperStatus
ifLastChange
ifXTable
ifInOctets
ifInUcastPkts
IfInNUcastPkts(deprecated)
ifInDiscards
ifInErrors
ifInUnknownProtos
ifOutOctets
ifOutUcastPkts
IfOutNUcastPkts(deprecated)
ifOutDiscards
ifOutErrors
IfOutQLen(deprecated)
IfSpecific
All objects
ifStackTable
Not supported
IfTestTable
Not supported
ifRcvAddressTable
All objects
snmpTraps
linkDown
linkUp
RFC 1215
This MIB defines an SMI for SNMPv1 traps, and some traps themselves. Of these, the following are
supported.
782
Traps
Comments
coldStart
The system cannot distinguish between a cold and warm reboot, so the warmStart
trap is always sent. This is the same behavior as in Extremeware.
warmStart
authenticationFailure
linkDown
linkUp
Supported Variables
dot1dBaseBridgeAddress
dot1dBaseNumPorts
Comments
dot1dBaseType
dot1dBasePortTable
Partial
dot1dBasePortIfIndex is supported.
dot1dBasePortCircuit will always have the value {
0 0 } since there is a one to one correspondence
between a physical port and its ifIndex.
dot1dBasePortDelayExceededDiscards and
dot1dBasePortMtuExceededDiscards are not
supported and always return 0.
dot1dStpProtocolSpecification
dot1dStpPriority
dot1dStpTimeSinceTopologyChang
e
dot1dStpTopChanges
dot1dStpDesignatedRoot
dot1dStpRootCost
dot1dStpRootPort
dot1dStpMaxAge
dot1dStpHelloTime
dot1dStpHoldTime
dot1dStpForwardDelay
dot1dStpBridgeMaxAge
dot1dStpBridgeHelloTime
dot1dStpBridgeForwardDelay
dot1dStpVersion
783
Table/Group
Supported Variables
Comments
dot1dStpTxHoldCount
dot1dStpPathCostDefault
dot1dStpExtPortTable
All objects
dot1dStpPortTable
All objects
STP Traps
newRoot
topologyChange
dot1dTpFdbTable
Supported
dot1dTpPortTable
Supported
dot1dStatic group
Supported
Dot1dStaticAllowedToGoTo
Not supported
Supported Variables
rip2Globals
rip2GlobalRouteChanges
Comments
rip2GlobalQueries
784
rip2IfStatTable
All objects
rip2IfConfTable
All objects
rip2PeerTable
Not supported
Supported Variables
ospfGeneralGroup
All objects
ospfAreaTable
All objects
ospfStubAreaTable
All objects
ospfLsdbTable
All objects
ospfAreaRangeTable
All objects
ospfHostTable
All objects
ospfIfTable
All objects
ospfIfMetricTable
All objects
ospfVirtIfTable
All objects
ospfNbrTable
All objects
ospfVirtNbrTable
All objects
ospfExtLsdbTable
All objects
ospfAreaAggregateTable
All objects
ospfTrap
All traps
Comments
BGP4-V2-MIB (draft-ietf-idr-bgp4-mibv2-02.txt)
This MIB is supported in lieu of RFC 1657(BGP4-MIB). The following tables, groups, and variables are
supported in this MIB.
Table/Group
Supported Variables
bgpM2BaseNotifications
All notifications
bgpM2VersionTable
bgpM2VersionIndex
bgpM2SupportedAuthTable
Comment
bgpM2VersionSupported
bgpM2SupportedAuthCode
bgpM2SupportedAuthValue
bgpM2SupportedCapabilities
bgpM2CapabilitySupportAvailable
bgpM2SupportedCapabilitiesTable
bgpM2SupportedCapabilityCode
bgpM2SupportedCapability
bgpM2BaseScalars
bgpM2AsSize
bgpM2LocalAs
bgpM2LocalIdentifier
bgpM2BaseScalarRouteReflectExts
bgpM2RouteReflector
bgpM2ClusterId
785
Table/Group
Supported Variables
bgpM2BaseScalarASConfedExts
bgpM2ConfederationRouter
Comment
bgpM2ConfederationId
bgpM2BaseScalarConfiguration
bgpM2CfgBaseScalarStorageType
bgpM2CfgLocalAs
bgpM2CfgLocalIdentifier
bgpM2CfgBaseScalarReflectorExts
bgpM2CfgRouteReflector
Supported read-only.
bgpM2CfgClusterId
bgpM2CfgBaseScalarASConfedExts
bgpM2CfgConfederationRouter
Supported read-only.
bgpM2CfgConfederationId
bgpM2PeerTable
bgpM2PeerIdentifier
bgpM2PeerState
bgpM2PeerStatus
bgpM2PeerConfiguredVersion
bgpM2PeerNegotiatedVersion
bgpM2PeerLocalAddrType
bgpM2PeerLocalAddr
bgpM2PeerLocalPort
bgpM2PeerLocalAs
bgpM2PeerRemoteAddrType
bgpM2PeerRemoteAddr
bgpM2PeerRemotePort
bgpM2PeerRemoteAs
bgpM2PeerIndex
bgpM2PeerErrorsTable
bgpM2PeerLastErrorReceived
bgpM2PeerLastErrorSent
bgpM2PeerLastErrorReceivedTime
bgpM2PeerLastErrorSentTime
bgpM2PeerLastErrorReceivedText
bgpM2PeerLastErrorSentText
bgpM2PeerAuthTable
bgpM2PeerLastErrorReceivedData
bgpM2PeerLastErrorSentData
bgpM2PeerAuthSent
bgpM2PeerAuthSentCode
bgpM2PeerAuthSentValue
bgpM2PeerAuthRcvd
bgpM2PeerAuthRcvdCode
bgpM2PeerAuthRcvdValue
bgpM2PeerEventTimesTable
786
bgpM2PeerFsmEstablishedTime
Table/Group
Supported Variables
Comment
bgpM2PeerInUpdatesElapsedTime
bgpM2PeerConfiguredTimersTable
bgpM2PeerConnectRetryInterval
bgpM2PeerHoldTimeConfigured
bgpM2PeerKeepAliveConfigured
bgpM2PeerMinASOrigInterval
bgpM2PeerMinRouteAdverInterval
bgpM2PeerNegotiatedTimersTable
bgpM2PeerHoldTime
bgpM2PeerKeepAlive
bgpM2PeerCapsAnnouncedTable
bgpM2PeerCapAnnouncedCode
bgpM2PeerCapAnnouncedIndex
bgpM2PeerCapAnnouncedValue
bgpM2PeerCapsReceivedTable
bgpM2PeerCapReceivedCode
bgpM2PeerCapReceivedIndex
bgpM2PeerCapReceivedValue
bgpM2PeerCountersTable
bgpM2PeerInUpdates
bgpM2PeerOutUpdates
bgpM2PeerInTotalMessages
bgpM2PeerOutTotalMessages
bgpM2PeerFsmEstablishedTrans
bgpM2PrefixCountersTable
bgpM2PrefixCountersAfi
bgpM2PrefixCountersSafi
bgpM2PrefixInPrefixes
bgpM2PrefixInPrefixesAccepted
bgpM2PrefixInPrefixesRejected
bgpM2PrefixOutPrefixes
bgpM2PeerReflectorClientTable
bgpM2PeerReflectorClient
bgpM2PeerConfedMemberTable
bgpM2PeerConfedMember
bgpM2CfgPeerAdminStatusTable
bgpM2CfgPeerAdminStatus
bgpM2CfgPeerNextIndex
bgpM2CfgPeerTable
bgpM2CfgPeerConfiguredVersion
bgpM2CfgAllowVersionNegotiation
bgpM2CfgPeerLocalAddrType
bgpM2CfgPeerLocalAddr
bgpM2CfgPeerLocalAs
bgpM2CfgPeerRemoteAddrType
bgpM2CfgPeerRemoteAddr
bgpM2CfgPeerRemotePort
Implemented as read-only.
bgpM2CfgPeerRemoteAs
787
Table/Group
Supported Variables
Comment
bgpM2CfgPeerEntryStorageType
Not supported.
bgpM2CfgPeerError
Not supported.
bgpM2CfgPeerBgpPeerEntry
Not supported.
bgpM2CfgPeerRowEntryStatus
bgpM2CfgPeerIndex
bgpM2CfgPeerStatus
bgpM2CfgPeerAuthTable
bgpM2CfgPeerAuthEnabled
bgpM2CfgPeerAuthCode
bgpM2CfgPeerAuthValue
bgpM2CfgPeerTimersTable
bgpM2CfgPeerConnectRetryInterval
Implemented as read-only.
bgpM2CfgPeerHoldTimeConfigured
bgpM2CfgPeerKeepAliveConfigured
bgpM2CfgPeerMinASOrigInterval
Implemented as read-only.
bgpM2CfgPeerMinRouteAdverInter
Implemented as read-only.
bgpM2CfgPeerReflectorClientTable
bgpM2CfgPeerReflectorClient
bgpM2CfgPeerConfedMemberTable
bgpM2CfgPeerConfedMember
bgpM2NlriTable
bgpM2NlriIndex
bgpM2NlriAfi
bgpM2NlriSafi
bgpM2NlriPrefix
bgpM2NlriPrefixLen
bgpM2NlriBest
bgpM2NlriCalcLocalPref
bgpM2PathAttrIndex
bgpM2AdjRibsOutTable
bgpM2NlriOpaqueType
bgpM2NlriOpaquePointer
bgpM2AdjRibsOutIndex
bgpM2AdjRibsOutRoute
bgpM2Rib
bgpM2PathAttrCount
bgpM2PathAttrTable
bgpM2PathAttrOrigin
bgpM2PathAttrNextHopAddrType
bgpM2PathAttrNextHop
bgpM2PathAttrMedPresent
bgpM2PathAttrMed
bgpM2PathAttrLocalPrefPresent
bgpM2PathAttrLocalPref
bgpM2PathAttrAtomicAggregate
bgpM2PathAttrAggregatorAS
788
Table/Group
Supported Variables
Comment
bgpM2PathAttrAggregatorAddr
bgpM2AsPathCalcLength
bgpM2AsPathString
bgpM2AsPathIndex
bgpM2AsPath4byteTable
Not supported
bgpM2AsPathTable
bgpM2AsPathSegmentIndex
bgpM2AsPathElementIndex
bgpM2AsPathType
bgpM2AsPathElementValue
bgpM2PathAttrUnknownTable
Not supported
bgpM2PathAttrOriginatorIdTable
bgpM2PathAttrOriginatorId
bgpM2PathAttrClusterTable
bgpM2PathAttrClusterIndex
bgpM2PathAttrClusterValue
bgpM2PathAttrCommTable
bgpM2PathAttrCommIndex
bgpM2PathAttrCommValue
bgpM2PathAttrExtCommTable
Not supported
bgpM2LinkLocalNextHopTable
Not supported
Supported Variables
ifMauTable
All objects
ifJackTable
All objects
ifMauAutoNegTable
All objects
Comments
The following new Extreme proprietary Mau types have been added to the ifMauType textual
convention:
extremeMauType1000BaseWDMHD OBJECT IDENTIFIER
::= { extremeMauType 7 }
"Gigabit WDM, half duplex"
extremeMauType1000BaseWDMFD OBJECT IDENTIFIER
::= { extremeMauType 8 }
"Gigabit WDM, full duplex"
extremeMauType1000BaseLX70HD OBJECT IDENTIFIER
::= { extremeMauType 9 }
"Gigabit LX70, half duplex"
extremeMauType1000BaseLX70FD OBJECT IDENTIFIER
789
The following standards-based additions have been made as a 'Work in Progress', as per draft-ietfhubmib-mau-mib-v3-02.txt.
1. A new enumeration 'fiberLC(14)' for the JackType textual convention.
2. New Mau types:
dot3MauType10GigBaseX OBJECT-IDENTITY
STATUS
current
DESCRIPTION "X PCS/PMA (per 802.3 section 48), unknown PMD."
::= { dot3MauType 31 }
dot3MauType10GigBaseLX4 OBJECT-IDENTITY
STATUS
current
DESCRIPTION "X fiber over WWDM optics (per 802.3 section 53)"
::= { dot3MauType 32 }
dot3MauType10GigBaseR OBJECT-IDENTITY
STATUS
current
DESCRIPTION "R PCS/PMA (per 802.3 section 49), unknown PMD."
::= { dot3MauType 33 }
dot3MauType10GigBaseER OBJECT-IDENTITY
STATUS
current
DESCRIPTION "R fiber over 1550 nm optics (per 802.3 section 52)"
::= { dot3MauType 34 }
dot3MauType10GigBaseLR OBJECT-IDENTITY
STATUS
current
DESCRIPTION "R fiber over 1310 nm optics (per 802.3 section 52)"
::= { dot3MauType 35 }
dot3MauType10GigBaseSR OBJECT-IDENTITY
STATUS
current
DESCRIPTION "R fiber over 850 nm optics (per 802.3 section 52)"
::= { dot3MauType 36 }
dot3MauType10GigBaseW OBJECT-IDENTITY
790
10GBASE-X
10GBASE-LX4
10GBASE-R
10GBASE-ER
10GBASE-LR
10GBASE-SR
10GBASE-W
10GBASE-EW
10GBASE-LW
10GBASE-SW
Supported Variables
vrrpOperations
vrrpNodeVersion
Comments
vrrpNotificationCntl
vrrpStatistics
vrrpRouterChecksumErrors
vrrpRouterVersionErrors
vrrpRouterVrIdErrors
vrrpOperTable
All objects
vrrpAssoIpAddrTable
All objects
791
Table/Group
Supported Variables
vrrpRouterStatsTable
All objects
vrrpNotifications
vrrpTrapNewMaster
Comments
vrrpTrapAuthFailure
PIM-MIB (draft-ietf-pim-mib-v2-01.txt)
This MIB is superset of RFC 2934.
Table/Group
Supported Variables
pimInterfaceTable
pimInterfaceIfIndex
Comments
pimInterfaceAddress
pimInterfaceNetMask
pimInterfaceMode
pimInterfaceDR
pimInterfaceHelloInterval
pimInterfaceStatus
pimInterfaceJoinPruneInterval
pimInterfaceCBSRPreference
pimInterfaceTrigHelloInterval
Not supported.
pimInterfaceHelloHoldtime
pimInterfaceLanPruneDelay
pimInterfacePropagationDelay
pimInterfaceOverrideInterval
pimInterfaceGenerationID
pimInterfaceJoinPruneHoldtime
pimInterfaceGraftRetryInterval
pimInterfaceMaxGraftRetries
pimInterfaceSRTTLThreshold
pimInterfaceLanDelayEnabled
pimInterfaceSRCapable
pimInterfaceDRPriority
pimNeighborTable
pimNeighborAddress
pimNeighborIfIndex
pimNeighborUpTime
pimNeighborExpiryTime
pimNeighborMode
pimNeighborLanPruneDelay
pimNeighborOverrideInterval
792
Table/Group
pimIpMRouteTable
Supported Variables
Comments
pimNeighborTBit
pimNeighborSRCapable
pimNeighborDRPresent
pimIpMRouteUpstreamAssertTimer
pimIpMRouteAssertMetric
pimIpMRouteAssertMetricPref
pimIpMRouteAssertRPTBit
pimIpMRouteFlags
pimIpMRouteRPFNeighbor
pimIpMRouteSourceTimer
pimIpMRouteOriginatorSRTTL
pimIpMRouteNextHopTable pimIpMRouteNextHopPruneReason
pimIpMRouteNextHopAssertWinner
pimIpMRouteNextHopAssertTimer
pimRPSetTable
pimIpMRouteNextHopAssertMetric
Not supported.
pimIpMRouteNextHopAssertMetricPref
Not supported.
pimIpMRouteNextHopJoinPruneTimer
Not supported.
pimRPSetGroupAddress
pimRPSetGroupMask
pimRPSetAddress
pimRPSetHoldTime
pimRPSetExpiryTime
pimRPSetComponent
pimCandidateRPTable
pimCandidateRPGroupAddress
pimCandidateRPGroupMask
pimCandidateRPAddress
pimCandidateRPRowStatus
pimComponentTable
pimComponentIndex
pimComponentBSRAddress
pimComponentBSRExpiryTime
pimComponentCRPHoldTime
pimComponentStatus
Scalars
pimJoinPruneInterval
793
Table/Group
Supported Variables
Comments
pimSourceLifetime
pimStateRefreshInterval
pimStateRefreshLimitInterval
pimStateRefreshTimeToLive
PIM Traps
pimNeighborLoss
Not supported.
SNMPv3 MIBs
The XOS SNMP stack fully supports the SNMPv3 protocol and therefore implements the MIBs in the
SNMPv3 RFCs. Specifically, the MIBs in following RFCs are fully supported.
RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP)
RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)
RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)
RFC 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework
Supported Variables
entityPhysicalTable
entPhysicalndex
Comments
entPhysicalDescr
entPhysicalVendorType
entPhysicalContainedIn
entPhysicalClass
entPhysicalParentRelPos
entPhysicalName
entPhysicalHardwareRev
entPhysicalFirmwareRev
entPhysicalSoftwareRev
entPhysicalSerialNum
entPhysicalMfgName
entPhysicalModelName
794
Table/Group
Supported Variables
Comments
entPhysicalAlias
entPhysicalAssetID
entPhysicalIsFRU
Supported Variables
Comments
pethPsePortTable
All objects
pethMainPseTable
All objects
pethNotifications
pethPsePortOnOffNotification
pethMainPowerUsageOnNotification
pethMainPowerUsageOffNotification
IEEE-8021-PAE-MIB
This MIB contains objects for the 802.1X protocol draft D10 of the 802.1X standard. The following tables,
groups, and variables are supported in this MIB.
Table/Group
Supported Variables
Comments
dot1xPaeSystemAuthControl
dot1xPaePortTable
All objects
dot1xAuthConfigTable
Not supported
dot1xAuthStatsTable
Not supported
dot1xAuthDiagTable
Not supported
dot1xAuthSessionStatsTable
Not supported
dot1xSuppConfigTable
None
dot1xSuppStatsTable
None
IEEE8021X-EXTENSIONS-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
dot1xAuthStationTable
All objects
dot1xAuthConfigTable
All objects
dot1xAuthStatsTable
All objects
Comments
795
Supported Variables
etherStatsTable
historyControlTable
All objects
etherHistoryTable
alarmTable
All objects
eventTable
All objects
logTable
All objects
Comments
Supported Variables
Comments
probeCapabilities
probeSoftwareRev
probeHardwareRev
probeDateTime
probeResetControl
trapDestTable
All objects
796
Table/Group
Supported Variables
ipv6Forwarding
All objects
ipv6DefaultHopLimit
All objects
ipv6Interfaces
All objects
ipv6IfTableLastChange
All objects
ipv6IfTable
ipv6IfStatsTable
All objects
ipv6AddrPrefixTable
All objects
ipv6AddrTable
All objects
ipv6RouteNumber
All objects
Comments
Table/Group
Supported Variables
ipv6DiscardedRoutes
All objects
ipv6RouteTable
All objects
ipv6NetToMediaTable
All objects
Comments
Supported Variables
ipv6IfIcmpTable
All objects
Comments
Supported Variables
Dot3StatsTable
dot3StatsIndex
Comments
dot3StatsAlignmentErrors
dot3StatsFCSErrors
dot3StatsSingleCollisionFrames
dot3StatsMultipleCollisionFrames
dot3StatsSQETestErrors
Not supported
dot3StatsDeferredTransmissions
dot3StatsLateCollisions
dot3StatsExcessiveCollisions
dot3StatsInternalMacTransmitErrors
dot3StatsCarrierSenseErrors
Not supported
dot3StatsFrameTooLongs
dot3StatsInternalMacReceiveErrors
797
Table/Group
Supported Variables
Comments
dot3StatsSymbolErrors
Not supported
dot3StatsEtherChipSet
dot3StatsDuplexStatus
dot3CollTable
dot3CollCount
dot3CollFrequencies
dot3ControlTable
Not supported
dot3PauseTable
Not supported
Other unsupported Tables and nodes in EtherLike MIB: dot3ControlTable, dot3PauseTable, dot3Tests all
nodes under this, dot3Errors, etherConformance, etherGroups, etherCompliance, dot3Compliance
Supported Variables
Comments
extremeSaveConfiguration
extremeSaveStatus
extremeCurrentConfigInUse
extremeConfigToUseOnReboot
extremeOverTemperatureAlarm
extremePrimaryPowerOperational
extremePowerStatus
extremePowerAlarm
extremeRedundantPowerStatus
extremeRedundantPowerAlarm
extremeInputPowerVoltage
extremePrimarySoftwareRev
798
Table/Group
Supported Variables
Comments
extremeSecondarySoftwareRev
ExtremeImageToUseOnReboot
extremeSystemID
extremeSystemBoardID
extremeSystemLeftBoardID
extremeSystemRightBoardID
Not supported.
extremeRmonEnable
extremeBootROMVersion
extremeDot1dTpFdbTableEnable
extremeHealthCheckErrorType
extremeHealthCheckAction
extremeHealthCheckMaxRetries
extremeCpuUtilRisingThreshold
extremeCpuTaskUtilPair
Not supported.
extremeCpuAggregateUtilization
extremeCpuUtilRisingThreshold
extremeAuthFailSrcAddr
extremeCpuTransmitPriority
extremeImageBooted
extremeMasterMSMSlot
extremeChassisPortsPerSlot
ExtremeMsmFailoverCause
extremeFanStatusTable
All objects
extremeCpuTaskTable
All objects
Not supported.
extremeCpuTask2Table
All objects
Not supported.
extremeSlotTable
All objects
extremePowerSupplyTable
extremePowerSupplyStatus,
extremePowerSupplyInputVoltage
799
Table/Group
Supported Variables
Comments
extremeImageTable
extremeImageNumber
extremeMajorVersion
extremeSubMajorVersion
extremeMinorVersion
extremeBuildNumber
extremeTechnologyReleaseNumber
extremeSustainingReleaseNumber
extremeBranchRevisionNumber
extremeImageType
extremeImageDescription
extremePatchVersion
extremeCpuMonitorInterval
extremeCpuMonitorTotalUtilization
extremeCpuMonitorTable
extremeCpuMonitorSlotId
extremeCpuMonitorProcessName
extremeCpuMonitorProcessId
extremeCpuMonitorProcessState
extremeCpuMonitorUtilization5secs
extremeCpuMonitorUtilization10secs
extremeCpuMonitorUtilization30secs
extremeCpuMonitorUtilization1min
extremeCpuMonitorUtilization5mins
extremeCpuMonitorUtilization30mins
extremeCpuMonitorUtilization1hour
extremeCpuMonitorUserTime
extremeCpuMonitorSystemTime
extremeCpuMonitorSystemTable
extremeCpuMonitorSystemSlotId
extremeCpuMonitorSystemUtilization5secs
extremeCpuMonitorSystemUtilization10secs
extremeCpuMonitorSystemUtilization30secs
800
Table/Group
Supported Variables
Comments
extremeCpuMonitorSystemUtilization1min
extremeCpuMonitorSystemUtilization5mins
extremeCpuMonitorSystemUtilization30mins
extremeCpuMonitorSystemUtilization1hour
extremeCpuMonitorSystemMaxUtilization
extremeMemoryMonitorSystemTable
extremeMemoryMonitorSystemSlotId
extremeMemoryMonitorSystemTotal
extremeMemoryMonitorSystemFree
extremeMemoryMonitorSystemUsage
extremeMemoryMonitorUserUsage
extremeMemoryMonitorTable
extremeMemoryMonitorSlotId
extremeMemoryMonitorProcessName
extremeMemoryMonitorUsage
extremeMemoryMonitorLimit
extremeMemoryMonitorZone
extremeMemoryMonitorGreenZoneCount
extremeMemoryMonitorYellowZoneCount
extremeMemoryMonitorOrangeZoneCount
extremeMemoryMonitorRedZoneCount
extremeMemoryMonitorGreenZoneThreshold
extremeMemoryMonitorYellowZoneThreshold
extremeMemoryMonitorOrangeZoneThreshold
extremeMemoryMonitorRedZoneThreshold
EXTREME-VLAN-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeVirtualGroup
extremeNextAvailableVirtIfIndex
extremeVlanIfTable
extremeVlanIfIndex
Comments
extremeVlanIfDescr
extremeVlanIfType
801
Table/Group
Supported Variables
Comments
extremeVlanIfGlobalIdentifier
Not supported.
extremeVlanIfStatus
extremeVlanIfIgnoreStpFlag
Not supported.
extremeVlanIfIgnoreBpduFlag
Not supported.
extremeVlanIfLoopbackModeFlag
extremeVlanIfVlanId
extremeGlobalMappingTable
Not supported
extremeVlanEncapsTable
Not supported
extremeVlanIpTable
All objects
extremeVlanProtocolTable
Not supported
extremeVlanProtocolBindingTable
Partial
extremeVlanProtocolVlanTable
Not supported
extremeVlanProtocolDefTable
Partial
extremeVlanOpaqueTable
All objects
extremeVlanOpaqueControlTable
All objects
802
extremeVlanStackTable
All objects
Not supported.
extremeVlanL2StatsTable
All objects
Not supported.
This table contains per VLAN information
about the number of packets sent to the
CPU, the number of packets learnt, the
number of Igmp control packets snooped
and the number of Igmp data packets
switched. This is the same information
that is available via the CLI command
'show l2stats'.
EXTREME-TRAPPOLL-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
Comments
extremeSmartTrapFlushInstanceTableIndex
extremeSmartTrapRulesTable
extremeSmartTrapInstanceTable
extremeSmartTrapInstanceTable is
a read-only table that stores the
information about which variables
have changed according to rules
defined in the
extremeSmartTrapRulesTable.
EXTREME-ESRP-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeEsrpDomainTable
All objects
extremeEsrpDomainMemberTable
All objects
Comments
All objects
extremeEsrpDomainStatsTable
All objects
extremeEsrpNotifications
extremeEsrpDomainStateChange
803
EXTREME-EDP-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeEdpTable
All objects
extremeEdpNeighborTable
All objects
extremeEdpPortTable
All objects
Comments
EXTREME-OSPF-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeOspfInterfaceTable
All objects
Comments
EXTREME-FDB-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeFdbPermFdbTable
All objects
extremeFdbMacFdbCounterTable
All objects
Comments
Support SNMP get and get next operations only.
EXTREME-TRAP-MIB
This MIB defines the following Extreme-specific SNMPv1 traps generated by Extreme Networks
devices.
Trap
Comments
extremeOverheat
extremeFanFailed
extremeFanOK
extremeInvalidLoginAttempt
extremePowerSupplyGood
extremePowerSupplyFail
extremeEdpNeighborAdded
extremeEdpNeighborRemoved
extremeModuleStateChanged
804
EXTREME-V2TRAP-MIB
This MIB defines the following Extreme-specific SNMPv2c traps generated by Extreme Networks
devices.
Trap
Comments
extremeHealthCheckFailed
extremeMsmFailoverTrap
extremeBgpM2PrefixReachedThreshold
extremeBgpM2PrefixMaxExceeded
extremeEapsStateChange
extremeEapsFailTimerExpFlagSet
extremeEapsFailTimerExpFlagSet
extremeEapsLinkDownRingComplete
extremeNMSInventoryChanged
These traps are not generated by the Extremeware XOS SNMP agent but
by the EPICenter NMS.
extremeNMSTopologyChanged
EXTREME-STPEXTENSIONS-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeStpDomainTable
All objects
extremeStpPortTable
All objects
extremeStpVlanPortTable
All objects
Comments
These tables contain information on all STP
domains, whereas the BRIDGE-MIB contains
information only of the STP domain 's0'.
EXTREME-ENTITY-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
extremeEntityFRUTable
Supported Variables
Comments
entPhysicalndex
extremeEntityStartTime
extremeEntityOdometer
extremeEntityOdometerUnit
EXTREME-CLEARFLOW-MIB
This MIB defines the following Extreme-specific traps generated by Extreme Networks devices.
Trap
Comments
extremeClearflowMessage
The varbinds supported in this trap are:
extremeClearflowMsgId
805
extremeClearflowMsg
extremeClearflowPolicyName
extremeClearflowRuleName
extremeClearflowRuleValue
extremeClearflowRuleThreshold
extremeClearflowRuleInterval
extremeClearflowVlanName
extremeClearflowPortName
EXTREME-PoE-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
extremePethSystemAdminEnable
extremePethSystemDisconnectPrecedence
extremePethSystemUsageThreshold
extremePethSystemPowerSupplyMode
extremePethPseSlotTable
All objects
extremePethPsePortTable
All objects
EXTREME-RMON-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
extremeRtStatsTable
extremeRtStatsIndex
Comments
extremeRtStatsIntervalStart
extremeRtStatsCRCAlignErrors
extremeRtStatsUndersizePkts
extremeRtStatsOversizePkts
extremeRtStatsFragments
extremeRtStatsJabbers
extremeRtStatsCollisions
extremeRtStatsTotalErrors
extremeRtStatsUtilization
806
EXTREME-QOS-MIB
The following tables, groups, and variables are supported in this MIB.
Table/Group
Supported Variables
Comments
extremeQosProfileTable
extremeQosProfileIndex
The extremeQosProfileTable is
table is read only.
extremeQosProfileName
extremeQosProfileMinBw
extremeQosProfileMaxBw
extremeQosProfilePriority
extremeQosProfileRowStatus
extremeIQosProfileTable
extremeIQosProfileIndex
extremeIQosProfileName
extremeIQosProfileMinBwType
extremeIQosProfileMinBw
extremeIQosProfileMaxBwType
extremeIQosProfileMaxBw
extremeIQosProfileRED
extremeIQosProfileMaxBuf
extremePerPortQosTable
extremePerPortQosIndex
extremePerPortQosMinBw
extremePerPortQosMaxBw
ExtremePerPortQosPriority
extremePerPortQosRowStatus
extremeQosByVlanMappingTable
extremeVlanIfIndex
extremeQosByVlanMappingQosProfileIndex
807
808
Glossary
A
AAA
ABR
ACL
Access Control List. ACLs are a mechanism for filtering packets at the
hardware level. Packets can be classified by characteristics such as the
source or destination MAC, IP addresses, IP type, or QoS queue. Once
classified, the packets can be forwarded, counted, queued, or dropped.
In Extreme Networks XOS software, you configure ACLs by creating a
file, called a policy file (with a .pol file extension). The system parses
the policy file and loads the ACL into the hardware.
alternate port
AP
Access point. In wireless technology, access points are the devices that
connect to the regular wired network and forward and receive the
radio signals that transmit wireless data.
area
ARP
AS
ASBR
809
Glossary
A (Continued)
autobind
autonegotation
backbone area
In OSPF, a network that has more than one area must have a
backbone area, configured as 0.0.0.0. All areas in an AS must connect
to the backbone area.
backup port
In RSTP, the backup port supports the designated port on the same
attached LAN segment. Backup ports exist only when the bridge is
connected as a self-loop or to a shared media segment.
backup router
In VRRP, the backup router is any VRRP router in the VRRP virtual
router that is not elected as the master. The backup router is available
to assume forwarding responsibility if the master becomes
unavailable.
BDR
BGP
810
B (Continued)
blackhole
BOOTP
BPDU
bridge
broadcast
carrier VLAN
In STP, carrier VLANs define the scope of the STPD, including the
physical and logical ports that belong to the STPD as well as the
802.1Q tags used to transport EMISTP- or PVST+-encapsulated
BPDUs. Only one carrier VLAN can exist in any given STPD.
CCM
CFF
In CFM, this means CFM filter function. You apply CFFs to specified
ports within the CFM MA to block CCM messages at or inferior to
that MA level.
811
Glossary
C (Continued)
CFM
checkpointing
CIDR
CIST
Within an MSTP region, the bridge with the lowest path cost to the
CIST root bridge is the CIST regional root bridge If the CIST root
bridge is inside an MSTP region, that same bridge is the CIST regional
root for that region because it has the lowest path cost to the CIST
root. If the CIST root bridge is outside an MSTP region, all regions
connect to the CIST root through their respective CIST regional roots.
CLEAR-Flow
CLI
Command line interface. You use the CLI to monitor and manage the
switch.
cluster
812
C (Continued)
CNA
combo port
common link
In EAPS, the common link is the physical link between the controller
and partner nodes in a network where multiple EAPS share a
common link between domains.
controller node
In EAPS, the controller node is that end of the common line that is
responsible for blocking ports if the common link fails, thereby
preventing a superloop.
control VLAN
In EAPS, the control VLAN is a VLAN that sends and receives EAPS
messages. You must configure one control VLAN for each EAPS
domain.
CoS
Class of Service. Specifying the service level for the classified traffic
type.
CRC
CRC error
CSPF
DA
DAD
813
Glossary
D (Continued)
default encapsulation mode
PVST+This mode implements PVST+ in compatibility with thirdparty switches running this version of STP.
designated port
Device Manager
DF
Dont fragment bit. This is the dont fragment bit carried in the flags
field of the IP header that indicates that the packet should not be
fragmented. The remote host will return ICMP notifications if the
packet had to be split anyway, and these are used in MTU discovery.
DHCP
DiffServ
DNS
814
D (Continued)
domain
DoS attack
DR
dropped packets
These are packets that the switch received but does not transmit.
EAPS
EAPS domain
EAPS link ID
Each common link in the EAPS network must have a unique link ID.
The controller and partner shared ports belonging to the same
common link must have matching link IDs, and not other instance in
the network should have that link ID.
EBGP
ECMP
edge ports
EDP
EEPROM
815
Glossary
E (Continued)
EGP
election algorithm
ELSM
Extreme Link Status Monitoring. ELSM is an Extreme Networksproprietary protocol that monitors network health. You can also use
ELSM with Layer 2 control protocols to improve Layer 2 loop
recovery in the network.
ELRP
Extreme Loop Recovery Protocol. ELRP is an Extreme Networksproprietary protocol that allows you to detect Layer 2 loops.
EMISTP
EMS
encapsulation mode
Using STP, you can configure ports within an STPD to accept specific
BPDU encapsulations. The three encapsulation modes are:
PVST+This mode implements PVST+ in compatibility with thirdparty switches running this version of STP.
EPICenter
ESRP
Extreme Standby Router Protocol. ESRP is an Extreme Networksproprietary protocol that provides redundant Layer 2 and routing
services to users.
ESRP-aware device
This is an Extreme Networks device that is not running ESRP itself but
that is connected on a network with other Extreme Networks switches
that are running ESRP. These ESRP-aware devices also fail over.
ESRP domain
816
E (Continued)
ESRP-enabled device
ESRP groups
ESRP instance
You enable ESRP on a per domain basis; each time you enable ESRP is
an ESRP instance.
ESRP VLAN
Ethernet
This is the IEEE 802.3 networking standard that uses carrier sense
multiple access with collision detection (CSMA/CD). An Ethernet
device that wants to transmit first checks the channel for a carrier, and
if no carrier is sensed within a period of time, the device transmits. If
two devices transmit simultaneously, a collision occurs. This collision
is detected by all transmitting devices, which subsequently delay their
retransmissions for a random period. Ethernet runs at speeds from 10
Mbps to 10 Gbps on full duplex.
extended mode
Fast Convergence
fast path
This term refers to the data path for a packet that traverses the switch
and does not require processing by the CPU. Fast path packets are
handled entirely by ASICs and are forwarded at wire speed rate.
FDB
FIB
frame
This is the unit of transmission at the data link layer. The frame
contains the header and trailer information required by the physical
medium of transmission.
817
Glossary
F (Continued)
full-duplex
GBIC
Gigabit Ethernet
HA
half-duplex
header
hitless failover
IBGP
ICMP
818
I (Continued)
IEEE
IETF
IGMP
IGMP snooping
IGP
inline power
IP
IPv6
819
Glossary
I (Continued)
IP address
IPTV
IR
IRDP
Internet Router Discovery Protocol. Used with IP, IRDP enables a host
to determine the address of a router that it can use as a default
gateway. In Extreme Networks implementation, IP multinetting
requires a few changes for the IRDP.
ISO
ISP
ITU-T
International Telecommunication Union-Telecommunication. The ITUT is the telecommunications division of the ITU international
standards body.
jumbo frames
These are Ethernet frames that are larger that 1522 bytes (including the
4 bytes in the CRC). The jumbo frame size is configurable on Extreme
Networks devices; the range is from 1523 to 9216 bytes.
820
L
LACP
LAG
Layer 2
Layer 2 is the second, or data link, layer of the OSI model, or the MAC
layer. This layer is responsible for transmitting frames across the
physical link by reading the hardware, or MAC, source and
destination addresses.
Layer 3
Layer 3 is the third layer of the OSI model. Also known as the
network layer, Layer 3 is responsible for routing packets to different
LANs by reading the network address.
LED
license
link aggregation
link type
In OSPF, there are four link types that you can configure: auto,
broadcast, point-to-point, and passive.
LLDP
load sharing
LFS
821
Glossary
L (Continued)
loop detection
LSA
LSDB
MAC address
MAN
master node
master router
In VRRP, the master router is the physical device (router) in the VRRP
virtual router that is responsible for forwarding packets sent to the
VRRP virtual router and for responding to ARP requests. The master
router sends out periodic advertisements that let backup routers on
the network know that it is alive. If the VRRP IP address owner is
identified, it always becomes the master router.
master VLAN
In ESRP, the master VLAN is the VLAN on the ESRP domain that
exchanges ESRP-PDUs and data between a pair of ESRP-enabled
devices. You must configure one master VLAN for each ESRP domain,
and a master VLAN can belong to only one ESRP domain.
MED
MEP
In CFM, maintenance end point is and end point for a single domain,
or maintenance association. The MEP may be either outward-facing or
inward facing.
822
M (Continued)
metering
In QoS, metering monitors the traffic pattern of each flow against the
traffic profile. For out-of-profile traffic the metering function interacts
with other components to either re-mark or drop the traffic for that
flow. In the Extreme Networks implementation, you use ACLs to
enforce metering.
member VLAN
In ESRP, you configure zero or more member VLANs for each ESRP
domain. A member VLAN can belong to only one ESRP domain. The
state of the ESRP device determines whether the member VLAN is in
forwarding or blocking state.
MIB
MIP
mirroring
Port mirroring configures the switch to copy all traffic associated with
one or more ports to a designated monitor port. The monitor port can
be connected to an network analyzer or RMON probe for packet
analyzer.
MMF
MSM
MSTI
823
Glossary
M (Continued)
MSTI root port
In an MSTP environment, the port on the bridge with the lowest path
cost to the MSTI regional root bridge is the MSTI root port.
MSTP
MSTP region
MTU
multicast
multinetting
MVR
NAT
824
N (Continued)
netlogin
netmask
neutral state/switch
In ESRP, the neutral state is the initial state entered by the switch. In a
neutral state, the switch waits for ESRP to initialize and run. A neutral
switch does not participate in ESRP elections.
NLRI
node
Node Manager
NSSA
O
odometer
chassis
MSMs
I/O modules
power controllers
825
Glossary
O (Continued)
option 82
OSI
The 7-layer standard model for network architecture is the basis for
defining network protocol standards and the way that data passes
through the network. Each layer specifies particular network
functions; the highest layer is closest to the user, and the lowest layer
is closest to the media carrying the information. So, in a given message
between users, there will be a flow of data through each layer at one
end down through the layers in that computer and, at the other end,
when the message arrives, another flow of data up through the layers
in the receiving computer and ultimately to the end user or program.
This model is used worldwide for teaching and implementing
networking protocols.
OSPF
Open Shortest Path First. This is an IGP. OSPF, a routing protocol for
TCP/IP networks, uses a link state routing algorithm that calculates
routes for packets based on a number of factors, including least hops,
speed of transmission lines, and congestion delays. You can also
configure certain cost metrics for the algorithm. This protocol is more
efficient and scalable than vector-distance routing protocols. OSPF
features include least-cost routing, ECMP routing, and load balancing.
Although OSPF requires CPU power and memory space, it results in
smaller, less frequent router table updates throughout the network.
This protocol is more efficient and scalable than vector-distance
routing protocols.
OSPFv3
OSPFv3 is one of the routing protocols used with IPV6 and is similar
to OSPF.
OUI
packet
This is the unit of data sent across a network. Packet is a generic term
used to describe units of data at all levels of the protocol stack, but it
is most correctly used to describe application data units. The packet is
a group of bits, including data and control signals, arranged in a
specific format. It usually includes a header, with source and
destination data, and user data. The specific structure of the packet
depends on the protocol used.
partner node
In EAPS, the partner node is that end of the common link that is not a
controller node; the partner node does not participate in any form of
blocking.
PD
Powered device. In PoE, the PD is the powered device that plugs into
the PoE switch.
826
P (Continued)
PDU
PIM-DM
PIM-SM
ping
Packet Internet Groper. Ping is the ICMP echo message and its reply
that tests network reachability of a device. Ping sends an echo packet
to the specified host, waits for a response, and reports success or
failure and statistics about its operation.
PMBR
PIM multicast border router. A PIMBR integrates PIM-DM and PIMSM traffic.
PoE
Power over Ethernet. The PoE standard (IEEE 802.3af) defines how
power can be provided to network devices over existing Ethernet
connections.
policy files
port mirroring
Port mirroring configures the switch to copy all traffic associated with
one or more ports to a designated monitor port. A packet bound for or
heading away from the mirrored port is forwarded onto the monitor
port as well. The monitor port can be connected to a network analyzer
or RMON probe for packet analysis. Port mirroring is a method of
monitoring network traffic that a network administrator uses as a
diagnostic tool or debugging feature; it can be managed locally or
remotely.
POST
primary port
827
Glossary
P (Continued)
protected VLAN
In STP, protected VLANs are the other (other than the carrier VLAN)
VLANs that are members of the STPD but do not define the scope of
the STPD. Protected VLANs do not transmit or receive STP BPDUs,
but they are affected by STP state changes and inherit the state of the
carrier VLAN. Also known as non-carrier VLANs, they carry the data
traffic.
In EAPS, a protected VLAN is a VLAN that carries data traffic
through an EAPS domain. You must configure one or more protected
VLANs for each EAPS domain. This is also known as a data VLAN.
proxy ARP
PVST+
QoS
RADIUS
RARP
RFC
Request for Comment. The IETF RFCs describe the definitions and
parameters for networking.
828
R (Continued)
RIP
RIPng
RIP next generation. RIPng is one of the routing protocols used with
IPV6 and is similar to RIP.
RMON
root bridge
In STP, the root bridge is the bridge with the best bridge identifier
selected to be the root bridge. The network has only one root bridge.
The root bridge is the only bridge in the network that does not have a
root port.
root port
In STP, the root port provides the shortest path to the root bridge. All
bridges except the root bridge contain one root port.
route aggregation
route flapping
route reflector
In BGP, you can configure the routers within an AS such that a single
router serves as a central routing point for the entire AS.
routing confederation
In BGP, you can configure a fully meshed AS into several sub-ASs and
group these sub-ASs into a routing confederation. Routing
confederations help with the scalability of BGP.
RSTP
829
Glossary
S
SA
SCP
secondary port
sFlow
SFP
6in4 tunnels
The 6in4 tunnels, which encapsulate IPv6 packets into IPv4 packets,
use dynamic routing protocols to establish connectivity between
several IPv6 networks through over the intervening IPv4 network. The
6in4 tunnel must be created at each tunnel endpoint. The IPv6 routing
protocol considers the 6in4 tunnel as a single IPv6 hop, even if the
tunnel comprises many IPv4 hops; the IPv6 protocol considers the
6in4 tunnel as a normal IPv6 point-to-point link. You can have many
6in4 tunnels per VR.
6to4 tunnels
The 6to4 tunnels are one way to send IPv6 packets over IPv4
networks. This transition mechanism provides a way to connect IPv6
end-site networks by automatically tunnelling over the intervening
IPv4 Internet. A special IPv6 routing prefix is used to indicate that the
remaining part of the external routing prefix contains the IPv4
endpoint address of a boundary IPv6 router for that site that will
process IPv6-in-IPv4-encapsulated packets. You can have only one
6to4 tunnel per VR.
slow path
This term refers to the data path for packets that must be processed by
the switch CPU, whether these packets are generated by the CPU,
removed from the network by the CPU, or simply forwarded by the
CPU.
SMF
SNMP
830
S (Continued)
SNTP
SSH
Secure Shell, sometimes known as Secure Socket Shell, is a UNIXbased command interface and protocol of securely gaining access to a
remote computer. With SSH commands, both ends of the client/server
connection are authenticated using a digital certificate, and passwords
are protected by being encrypted. At Extreme Networks, the SSH is a
separate software module, which must be downloaded separately.
(SSH is bundled with SSL in the software module.)
SSL
standard mode
STP
STPD
STPD mode
The mode of operation for the STPD. The two modes of operation are:
stub areas
In OSPF, a stub area is connected to only one other area (which can be
the backbone area). External route information is not distributed to
stub areas.
831
Glossary
S (Continued)
superloop
TACACS+
tagged VLAN
TCN
TCP
TFTP
transit node
UDP
832
U (Continued)
unicast
untagged VLAN
USM
virtual link
In OSPF, when a new area is introduced that does not have a direct
physical attachment to the backbone, a virtual link is used. Virtual
links are also used to repair a discontiguous backbone area.
virtual router
In VRRP, RFC 2338 assigns a static MAC address for the first five
octets of the VRRP virtual router. These octets are set to 00-00-5E-0001. When you configure the VRRP VRID, the last octet of the MAC
address is dynamically assigned the VRID number.
VLAN
VLSM
VMAN
Virtual MAN. In ExtremeWare XOS software, VMANs are a bidirectional virtual data connection that creates a private path through
the public network. One VMAN is completely isolated from other
VMANs; the encapsulation allows the VMAN traffic to be switched
over Layer 2 infrastructure. You implement VMAN using an
additional 892.1Q tag and a configurable EtherType; this feature is
also known as Q-in-Q switching.
833
Glossary
V (Continued)
VPN
VoIP
VR-Control
VR-Default
VRID
In VRRP, the VRID identifies the VRRP virtual router. Each VRRP
virtual router is given a unique VRID. All the VRRP routers that
participate in the VRRP virtual router are assigned the same VRID.
VR-Mgmt
834
V (Continued)
VRRP
VRRP router
XENPAK
835
Glossary
836
Index of Commands
C
check policy, 312
clear access-list counter, 329
clear counters, 246, 410
clear elsm ports counters, 232
clear inline-power stats ports, 197
clear log counters, 246
clear log static, 743
clear session, 46, 71
clear slot, 116, 743
clear vlan dhcp-address-allocation, 400
configure access-list, 313, 328
configure account, 46
configure banner, 46
configure bgp add aggregate-address, 678
configure bgp add network, 682
configure bgp delete network, 682
configure bgp import-policy, 314, 340
configure bgp neighbor dampening, 680
configure bgp neighbor no-dampening, 680
configure bgp neighbor peer-group, 679
configure bgp neighbor route-policy, 314, 340
configure bgp peer-group dampening, 680
configure bgp peer-group no dampening, 680
configure bgp peer-group route-policy, 314, 340
configure bootprelay add, 611
configure bootprelay delete, 611
configure cli max-sessions, 62
configure core-dumps, 757
configure diffserv examination code-point, 359
configure diffserv replacement, 360
configure dns-client add, 56
configure dns-client default-domain, 56
configure dos-protect acl-expire, 402
configure dos-protect interval, 401
configure dos-protect trusted-ports, 402
configure dos-protect type l3-protect alertthreshold, 401
configure dos-protect type l3-protect notifythreshold, 402
configure dot1p type, 355
configure eaps add control vlan, 489
configure eaps add protect vlan, 490
configure eaps config-warnings off, 492
configure eaps config-warnings on, 492
configure eaps failtime, 487
configure eaps failtime expiry-action, 487
837
Index of Commands
configure igmp snooping filter, 690
configure inline-power budget slot, 189, 194
configure inline-power disconnect-precedence,
190, 195
configure inline-power label ports, 197
configure inline-power operator-limit ports, 192,
197
configure inline-power priority ports, 190, 195
configure inline-power usage-threshold, 191, 196
configure iparp add proxy, 601
configure ip-mtu vlan, 123, 125
configure iproute add default, 63, 68, 602, 624
configure iproute priority, 600, 623
configure jumbo-frame size, 123
configure log filter, 240, 242
configure log filter events match, 244
configure log target, 238
configure log target filter, 238
configure log target format, 244
configure log target match, 242
configure log target syslog, 237
configure mld snooping add static group, 706
configure mstp format, 537
configure mstp region, 537
configure mstp revision, 537
configure netlogin add mac-list, 450
configure netlogin base-url, 444
configure netlogin delete mac-list, 450
configure netlogin dot1x guest-vlan, 443
configure netlogin dotix timers, 443
configure netlogin local-user, 437, 438
configure netlogin move-fail-action, 430
configure netlogin port mode, 453
configure netlogin redirect-page, 445
configure node slot priority, 73
configure ospf area external-filter, 314, 340
configure ospf area interarea-filter, 314, 340
configure ospf area nssa, 651
configure ospf area stub, 651, 663
configure ospf area timer, 656
configure ospf ase-limit, 648
configure ospf timer, 656
configure ospf virtual-link timer, 656
configure ospf vlan area, 651, 662
configure ospf vlan timer, 655, 656, 667
configure pim add vlan, 690
configure ports auto off, 46, 120, 747
configure ports auto on, 120
configure ports auto-polarity off, 122
configure ports auto-polarity on, 122
configure ports limit-learning, 396
configure ports lock-learning, 397
configure ports preferred-medium, 151
configure ports qosprofile, 361
838
Index of Commands
configure ssl certificate, 421
configure ssl certificate pregenerated, 423
configure ssl privkeyword pregenerated, 423
configure stpd add vlan, 514, 543, 546
configure stpd default-encapsulation, 513
configure stpd delete vlan, 515, 516
configure stpd max-hop-count, 542
configure stpd mode, 512
configure stpd ports edge-safeguard disable, 526
configure stpd ports edge-safeguard enable, 526
configure stpd ports link-type, 525
configure stpd ports mode, 513
configure stpd tag, 547
configure sys-health-check interval, 218, 764
configure sys-recovery-level, 47, 220
configure sys-recovery-level slot, 221
configure tacacs server client-ip, 411
configure tacacs shared-secret, 412, 414
configure tacacs timeout, 411
configure tacacs-accounting timeout, 413
configure telnet access-profile, 70
configure telnet port, 69
configure telnet vr, 69
configure time, 47
configure timezone, 47, 95
configure vlan add esrp elrp-poll ports, 580
configure vlan add ports, 514
configure vlan dhcp-address-range, 399
configure vlan dhcp-lease-timer, 399
configure vlan dhcp-options, 399
configure vlan esrp elrp-master-poll enable, 579
configure vlan ipaddress, 47, 67, 602, 624
configure vlan name, 268
configure vlan qosprofile, 362
configure vr add ports, 307
configure vr add protocol, 307
configure vr delete ports, 306
configure vr delete protocol, 307
configure vrrp vlan vrid add track-iproute, 588
configure vrrp vlan vrid add track-ping, 588
configure vrrp vlan vrid add track-vlan, 588
configure vrrp vlan vrid delete track-iproute, 588
configure vrrp vlan vrid delete track-ping, 588
configure vrrp vlan vrid delete track-vlan, 588
cp, 102, 108, 759
create account, 47, 51
create bgp neighbor peer-group, 679
create bgp peer-group, 678
create eaps, 485
create eaps shared-port, 499
create esrp, 560, 569
create log filter, 240
create netlogin local-user, 436, 437
create ospf area, 651, 662
create
create
create
create
protocol, 266
stpd, 510, 546
virtual-router, 306
vlan, 47, 308
D
delete account, 47, 51
delete bgp peer-group, 678
delete eaps, 486
delete eaps shared-port, 499, 500
delete esrp, 569
delete fdbentry, 396
delete netlogin local-user, 439
delete stpd, 510
delete virtual router, 306
delete vlan, 47
disable access-list refresh blackhole, 313
disable bgp export, 682
disable bgp neighbor remove-private-as-numbers,
681
disable bootp vlan, 47, 66
disable clear-flow, 456
disable cli-config-logging, 47, 247
disable clipaging, 47
disable cpu-monitoring, 112
disable dhcp ports vlan, 399
disable dhcp vlan, 66
disable dos-protect, 401
disable eaps, 490, 491
disable edp ports, 145
disable elrp-client, 752
disable elsm ports, 230
disable elsm ports auto-restart, 229
disable esrp, 567, 570, 571, 750
disable idletimeout, 47
disable inline-power, 188, 193
disable inline-power legacy, 192, 196
disable inline-power ports, 193
disable inline-power slot, 193
disable ipforwarding, 409
disable learning port, 299
disable log debug-mode, 756
disable log target, 236
disable netlogin, 430
disable netlogin dot1x guest-vlan ports, 443
disable netlogin logout-privilege, 445
disable netlogin ports vlan, 430
disable netlogin session-refresh, 445
disable ospf capability opaque-lsa, 649
disable ospf export, 655, 666
disable ospf export static, 599, 622
disable port, 47, 119
disable radius, 404
839
Index of Commands
disable radius-accounting, 405
disable rip export, 637
disable rip export static, 599, 622
disable ripng export, 644
disable rmon, 254
disable sflow, 249
disable sflow ports, 249
disable sharing, 132
disable smartredundancy, 148
disable snmp access, 85
disable ssh2, 47
disable sys-health-check slot, 217, 764
disable tacacs, 412
disable tacacs-accounting, 414
disable telnet, 47, 70
disable udp-echo-server, 615
disable web https, 421
download bootrom, 55, 732
download image, 55, 712, 719, 720
download ssl certificate, 422
download ssl privkey, 422
E
edit policy, 69, 312, 417
eject memorycard, 757
enable access-list refresh blackhole, 313
enable bgp aggregation, 678
enable bgp export, 682
enable bgp neighbor remove-private-as-numbers,
681
enable bootp vlan, 47, 66
enable bootprelay, 611
enable clear-flow, 456
enable cli-config-logging, 47, 247
enable clipaging, 48
enable cpu-monitoring, 112
enable dhcp ports vlan, 399
enable dhcp vlan, 66
enable diffserv replacement ports, 359
enable dos-protect, 401
enable dos-protect simulated, 401
enable dot1p replacement ports, 356
enable eaps, 490, 491
enable edp ports, 145
enable elrp-client, 751
enable elsm ports, 228
enable elsm ports auto-restart, 229
enable esrp, 571
enable idletimeout, 48
enable inline-power, 188, 193
enable inline-power legacy, 192, 196
enable inline-power ports, 193
enable inline-power slot, 193
840
H
history, 46, 48
I
install firmware, 733
install image, 712, 720, 721
Index of Commands
L
load script, 726, 727
logout, 68
ls, 72, 103, 104, 108, 726, 727, 758
ls memorycard, 104
M
mv, 101, 108, 759
N
nslookup, 56
P
ping, 50, 55, 56, 57
Q
quit, 68
R
reboot, 75, 76, 715, 716
refresh policy, 313
reset inline-power ports, 191, 197
restart process, 110
rm, 106, 108, 761
run diagnostics, 209, 210
run elrp, 752
run msm-failover, 74, 76, 720, 721
run update, 713
S
save configuration, 724, 726, 730
save debug tracefiles memorycard, 757
scp2, 419
show access-list, 314, 329
show access-list counter, 329
show account, 51
show accounts, 51
show banner, 48
show bgp peer-group, 681
show bootprelay, 612
show checkpoint-data, 74, 75
show clear-flow, 456
show clear-flow acl-modified, 456
show clear-flow any, 456
show clear-flow port, 456
show clear-flow rule-all, 456
show clear-flow rule-triggered, 456
show clear-flow vlan, 456
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
201
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
show
841
Index of Commands
show ports info detail, 396
show ports information, 362, 376
show ports qosmonitor, 367, 376
show ports rxerrors, 207, 747
show ports sharing, 136
show ports statistics, 206
show ports txerrors, 206
show power, 84, 234, 744
show power budget, 84
show power controller, 84
show process, 108
show protocol, 272
show qosprofile, 367, 368
show qosprofile ports, 376
show rmon memory, 255
show session, 71
show sflow, 249, 251
show sflow statistics, 251
show slot, 85, 116, 222
show snmpv3 access, 90
show snmpv3 filter, 93
show snmpv3 filter-profile, 93
show snmpv3 group, 90
show snmpv3 mib-view, 91
show snmpv3 notify, 94
show snmpv3 target-addr, 92
show snmpv3 target-params, 93
show snmpv3 user, 89
show sntp-client, 96
show ssl, 422, 423
show stpd, 516, 553
show stpd ports, 525, 554
show switch, 73, 75, 95, 96, 220, 410, 710,
711, 719
show temperature, 233
show version, 710
show virtual-router, 308
show vlan, 271, 448, 748
show vlan dhcp-address-allocation, 400
show vlan dhcp-config, 400
show vlan security, 396
show vlan stpd, 554
show vman, 281
show vrrp, 588
ssh2, 419
start process, 110
synchronize, 73, 76, 730
U
unconfigure access-list, 314, 329
unconfigure eaps primary port, 491
unconfigure eaps secondary port, 491
unconfigure eaps shared-port link-id, 500
unconfigure eaps shared-port mode, 500
unconfigure elrp-client, 752
unconfigure inline-power budget slot, 189, 194
unconfigure inline-power disconnect-precedence,
190, 195
unconfigure inline-power operator-limit ports,
192, 197
unconfigure inline-power priority ports, 190, 195
unconfigure inline-power usage-threshold, 191,
196
unconfigure mstp region, 537
unconfigure port redundant, 148
unconfigure sflow, 251
unconfigure sflow agent, 249
unconfigure sflow collector, 249
unconfigure stpd ports link-type, 525
unconfigure switch, 48, 725
unconfigure vlan dhcp, 399
unconfigure vlan dhcp-address-range, 399
unconfigure vlan dhcp-options, 399
uninstall image, 713
upload configuration, 108, 726
upload log, 246
use configuration, 724
use image, 711
V
virtual-router, 308
T
telnet, 55, 66
terminate process, 109
tftp, 69, 72, 107, 108, 312, 417, 726, 728,
729
842
Index
Symbols
, 177
# prompt, 50
* prompt, 50
.cfg file, 724
.gz file, 757
.pol file, 311
.xmod file, 713
.xos file, 713
.xsf file, 725
> prompt, 50
Numerics
10 gigabit ports, 120
802.1ad, 272
802.1ag
802.1ah, 283
802.1D, 509
802.1Q tagging, 261, 262
802.1Q-2003, 535
802.1s, 535
802.1w, 523
802.1x authentication
advantages, 427
co-existence with web-based, 426
configuration, example, 441
disadvantages, 427
interoperability requirements, 440
methods, 439
requirements, 426
VLAN movement, post-authentication, 443
A
access levels, 49
accessing the switch, 48
account types
admin, 50
user, 50
accounting server
RADIUS, 404
TACACS, 413
accounts
creating, 51
default, 50
deleting, 51
failsafe, 51
viewing, 51
ACL match conditions, 320, 324
ACL-based traffic, QoS, 353
ACLs
.pol file, 311
action modifiers, 318
actions, 318
counters, 329
description, 315
editing, 312
evaluation precedence, 762
examples, 329331
file syntax, 316
metering, 368
refreshing, 313
rule entry, 316
rules, 327
smart refresh, 313
transferring to the switch, 312
troubleshooting, 311, 762
action modifiers
ACL, 318
VMAN ACLs, 324
action statements, policy, 339
actions
ACL, 318
VMAN ACLs, 324
active interfaces, 686
Address Resolution Protocol. See ARP
address-based load-sharing, 128
admin account, 50
advertisement interval, EDP, 146
agent, local, 248
agent, RMON, 251
aging entries, FDB, 296
alarm actions, 254
Alarms, RMON, 253
area 0
OSPF, 651
OSPFv3, 662
areas
OSPF, 650
OSPFv3, 662
ARP
and IP multinetting, 607
communicating with devices outside subnet,
602
843
Index
configuring proxy ARP, 601
displaying system table, 603
gratuitous ARP protection, 398
incapable device, 601
proxy ARP between subnets, 602
proxy ARP, description of, 601
responding to ARP requests, 601
AS numbers, private, 681
ASCII-formatted configuration file, 108
.xsf, 725
downloading, 726
loading, 727
troubleshooting, 726
uploading, 726
verifying, 727
authentication
local database, 435
RADIUS, 402, 431
TACACS+, 411
authentication methods
802.1x, 439
MAC-based, 448
web-based, 444
AuthnoPriv, 90
AuthPriv, 90
autobind ports, 515
automatic failover, 150
automatic restart, ELSM, 229
autonegotiation
description, 119
displaying setting, 151, 152
flow control, 120
Gigabit ports, 121
off, 121
on, 120
possible settings, 121
support, 121
autonomous system
description, 672
expressions, 337
autopolarity, 121
B
backbone area, OSPF, 651
backbone area, OSPFv3, 662
backbone bridge. See MAC-in-MAC, 283
backplane diagnostics
configuring, 218
disabling, 217
enabling, 217
bandwidth restriction, 371
base URL, network login, 444
844
BGP
and IP multinetting, 608
attributes, 672
autonomous system, 672
autonomous system path, 672
cluster, 673
community, 672
description, 672
examples
route confederations, 675678
route reflector, 673675
features, 673
loopback interface, 678
peer groups
creating, 678
deleting, 678
description, 678
mandatory parameters, 678
neighbors, 679
private AS numbers, 681
redistributing to OSPF, 681
route aggregation
description, 678
using, 678
route confederations, 675
route flap dampening
configuring, 680
description, 679
viewing, 680
route reflectors, 673
route selection, 681
static networks, 682
bi-directional rate shaping
configuring, 376
description, 373
maximum bandwidth settings, 374
maximum committed rate, 374
maximum ingress queues, 373
minimum bandwidth settings, 374
BlackDiamond 10K series switches, 22
BlackDiamond 12804 R-Series switches, 22
BlackDiamond 12804 switches, 22
BlackDiamond 8800 family of switches, 22
BlackDiamond 8806
MSM slots, 117
BlackDiamond 8810
MSM slot, 116
blackhole entries, FDB, 395
blackhole entry, FDB, 297
Bootloader
accessing, 731
exiting, 732
prompt, 731
Index
BOOTP relay
configuring, 611
viewing, 612
BOOTP server, 66
BOOTP, using, 66
BootROM
displaying, 736
upgrading
BlackDiamond 10K, 732
Summit X450, 732
BootRom
prompt, 731
bootstrap
accessing
BlackDiamond 12804, 735
Summit X450, 732
Bootstrap Protocol. See BOOTP
Border Gateway Protocol. See BGP
bulk checkpointing, 75
C
cabling
10/10/1000BASE-T ports, 121
crossover cables, 121
cabling for redundancy, 150, 151
campus mode, 428
carrier vlan, STP, 510
CFM, 176, 183
and MAC-in-MAC, 177
and VMANs, 177, 273
CCM messages, 177
CFM messages, 177
configuring CCMs, 183
configuring domains, 179, 180
configuring MAs, 179, 181
configuring MEPs, 182
configuring MIPs, 182
configuring ping, 183
displaying, 183
domain format, 180
example, 185
implementation, 175
limits, 179
MA formats, 181
MA levels, 176
MAC addresses, 175
mapping, 176, 177
MEPs, 177
MIPs, 178
MPs, 177
number of ports, 177
ping, 178
traceroute, 178
troubleshooting, 175
TTL, 178
VLAN association with MAs, 177
CFM Ethernet types, 175
checkpointing
bulk, 75
dynamic, 75
statistics, displaying, 75
CIST
See also MSTP
BPDUs
CIST records, 538
M-records, 538
configuring, 538
definition, 537
enabling, 539
regional root bridge, 538
root bridge, 538
root port, 539
CLEAR-Flow
configuring, 455
enabling and disabling, 456
overview, 455
rule types, 459
CLI
# prompt, 50
* prompt, 50
> prompt, 50
access levels, 49
command shortcuts, 43
configuration access, 50
history, 46
limits, 44
line-editing keys, 45
named components, 43
prompt line, 50
starting up, 53
symbols, 43
syntax, 41
syntax helper, 42
syntax symbols (table), 44, 192
users
adding, 51
deleting, 51
viewing, 51
using, 4142
cluster, 673
collector, remote, 249
combination ports, 150
combo ports, 150
command
history, 46
prompts, 50
shortcuts, 43
845
Index
command line interface. See CLI
command syntax, understanding, 41
Common and Internal Spanning Tree. See CIST
common commands (table), 4648
communicating with devices outside subnet, 602
community strings
private, 86
public, 86
read, 86
read-write, 86
compatibility version number, 717
components, EMS, 238
conditions, EMS, 239
configuration
primary and secondary, 724
returning to factory default, 725
viewing current, 725
configuration command prompt, 50
configuration domain, virtual routers, 305
configuration file
.cfg file, 724
.xsf file, 725
ASCII-formatted, 108, 725
copying, 102
deleting, 106
description, 724
displaying, 103
downloading, 729
managing, 100
overview, 107
relaying from primary to backup, 74
renaming, 101
saving changes, 724
selecting, 724
uploading, 727
using, 724
configuration mode, XML, 108
configuration, change log, 247
configuring PoE, 193
configuring traceroute, 183
connectivity, 56
Connectivity Fault Management. See CFM
console
connection, 62
maximum sessions, 61
control VLAN, EAPS, 489
controlling Telnet access, 68
conventions, guide
notice icons, 22
text, 23
core dump file
.gz file, 757
copying, 759
copying to the switch, 757
846
deleting, 761
description, 756
displaying, 758
renaming, 759
sending to the switch, 757
core image. See image
Core license, 35
CPU monitoring
description, 111
disabling, 112
enabling, 112
overview, 100
troubleshooting, 112
cpu utilization, history, 112
CPU utilization, TOP command, 762
D
database applications, and QoS, 347
database overflow, OSPF, 648
debug information, 756
debug mode, 247, 756
See also EMS
default
accounts, 50
gateway, 587, 597
passwords, 52
port status, 119
returning to factory settings, 725
software values, 38
users, 50
denial of service protection
configuring, 401
description, 400
disabling, 401
displaying settings, 402
enabling, 401
destination VLAN, network login, 437
DHCP
disabling, 399
displaying settings, 400
enabling, 399
network login and, 426
requirement for web-based network login, 426
DHCP relay
and IP multinetting, 609
configuring, 611
viewing, 612
DHCP server
and IP multinetting, 609
configuring, 399
description, 399
Index
diagnostics
BlackDiamond 10K
running, 209
BlackDiamond 10K switch
I/O module, 209
MSM, 209
BlackDiamond 12804
I/O module, 210
MSM, 210
BlackDiamond 12804 R-Series switch
I/O module, 210
MSM, 210
BlackDiamond 8800 family
I/O module, 209
MSM, 209
running, 209
displaying, 206, 215
LEDs, 211
running, 210
slot, 208
Summit X450 switch, 211
system, 208
DiffServ
See also QoS
and virtual routers, 360
code point, 358
configuring, 357
examining, 358
disabling route advertising
RIP, 635
RIPng, 643
distance-vector protocol, description, 633, 641
DNS
configuring, 56
description, 55
Domain Name Service. See DNS
domains, 176
domains, EAPS, 478
domains, ESRP, 562
domains, STP, 509
downloading
ASCII-formatted configuration, 726
configuration, 729
duplex setting, ports, 120
duplex, displaying setting, 151, 152
dynamic checkpointing, 75
dynamic entries, FDB, 296, 395
Dynamic Host Configuration Protocol. See DHCP
Dynamic MVR, 696
dynamic routes, 599
dynamic routes, IPv6, 622
E
EAPOL and DHCP, 426
EAPS
and IP multinetting, 609
common link, 496
configuring, 484
control VLAN, 489
description, 475, 477
disabling
domain, 490
loop protection, 492
on a switch, 491
EAPS domain
creating and deleting, 485
enabling, 484
domain, 490
loop protection, 492
on a switch, 491
failed state, 479, 487
failtime expiry action, 480, 487
failtimer, 480, 487
Fast Convergence, 477, 490
FDB, 479
hardware layer, 479
health-check packet, 480, 487
hellotime, 487
hitless failover support, 477
licensing, 475
link down message, 479
loop protection messages, 492
master node, 476, 486
multiple domains per switch, 481
names, 43
overview, 30
polling, 479
polling timers, configuring, 487
primary port, 476, 488
process, 479
protected VLAN, 489
ring port, unconfiguring, 491
ring restoration, 480
rings and a common link, 483
secondary port, 476, 478, 488
shared port
common link failure, 497
configuration rules, 503
configuring the domain ID, 499
creating and deleting, 499
defining the mode, 499
description, 496
show eaps display fields (table), 494, 501
show eaps shared-port display fields (table),
501
847
Index
spatial reuse, 482
status information, displaying, 492, 500
switch mode, defining, 486
transit node, 476, 486
troubleshooting, 478, 488
edge safeguard
description, 525
disabling, 526
enabling, 526
EDP
advertisement interval, 146
clearing counters, 145
default, 144
description, 144
disabling, 145
enabling, 145
timeout interval, 146
viewing information, 145, 152
egress flooding
displaying, 302
guidelines, 301
egress traffic rate limiting, 370
election algorithms, ESRP, 567
ELRP
and ESRP, 578
description, 578
loop detection, 750
master behavior (ESRP), 579
pre-master behavior (ESRP), 578
standalone, 750
with ESRP, overview, 558
without ESRP, 750
ELSM
and Layer 2 protocols, 232
automatic restart, 229
clearing counters, 232
configuration example, 232
configuring
hello timer, 228
hold threshold, 229
description, 223
disabling, 230
displaying information, 230
ELSM link state, 225
enabling, 228
fault detection, 223
hello messages, 224
hello transmit states, 224
hold threshold, 228
link state, 225
port states
down, 224
down-stuck, 224
848
down-wait, 224
up, 224
sticky threshold, 229
timers
down, 227
hello, 227
hellorx, 227
up, 227
EMISTP
description, 512
example, 520
rules, 521
EMS
and dual MSM systems, 236
configuring targets
components, 238
conditions, 239
description, 237
severity, 238
subcomponents, 238
debug mode, 247
description, 235
displaying messages
console, 245
session, 245
event message formats, 244
expressions
matching, 242
regular, 242
filtering event messages, 237
filters
configuring, 240
creating, 240
viewing, 241
log target
default, 236
disabling, 236
enabling, 236
types, 235
logs
displaying, 245
displaying counters, 246
uploading, 246
parameters
behavior, 244
matching, 242
viewing components and subcomponents, 239
viewing conditions, 239
encapsulation modes, 512
See also STP
entries, FDB, 295
EPICenter support, 63
Index
ESRP
802.1Q tag, 563
and ELRP, 558
and IP multinetting, 585, 609
and load sharing, 576
and OSPF, 567
and STP, 585
and VRRP, 585, 591, 596
auto toggle, 558, 562
basic topology, 559
description, 557
direct link, 563
displaying data, 577
domain ID, 563
domains, description, 562
dont count, 576
election algorithms, 567
environment tracking, 572
ESRP-aware, 560
examples, 580584
extended mode
description, 558, 561
differences between standard mode, 561
failover time, 566
groups, 576
hitless failover support, 563
host attach, 575
linking switches, 563
load sharing and, 576
master
behavior, 565
definition, 558
determining, 564
electing, 566
election algorithms, 567
multiple VLANs sharing a host port, 563
neutral state, behavior, 566
overview, 31
ping tracking, 573
port restart, 574
port weight, 562
pre-master
behavior, 565
timeout, 566
reasons to use, 558
restarting ports, 574
route table tracking, 572
slave mode
behavior, 565
definition, 558
standard mode
description, 558, 561
differences between extended mode, 561
tracking
description, 571
example, 574
troubleshooting, 559, 560, 749
VLANid, 563
ESRP-aware, description, 560
Ether type, 281
Ethernet Automatic Protection Switching. See
EAPS
evaluation precedence, ACLs, 762
Event Management System. See EMS
Events, RMON, 253
explicit packet marking, QoS, 354
extended mode, ESRP domain, 558, 561
Extreme Discovery Protocol. See EDP
Extreme Link Status Monitoring. See ELSM
Extreme Loop Recovery Protocol. See ELRP
Extreme Multiple Instance Spanning Tree
Protocol. See EMISTP
Extreme Standby Router Protocol. See ESRP
F
factory default values, 38
failover, 73
failsafe account, 51
Fast Convergence, EAPS, 477
fault protection, 476
FDB
configuring aging time, 298
contents, 295
creating a permanent entry example, 297
description, 295
disabling MAC learning, 299
displaying, 298
dynamic entries, limiting, 396
egress flooding, 300
entries
adding, 296
aging, 296
blackhole, 297
description, 295
dynamic, 296
limiting, 299
multicast with multiport entries, 302
non-aging, 297
permanent, 297
prioritizing, 299
static, 297
prioritizing entries, 395
feature highlights, 27
feature pack, 29
feature packs, 37
features, platform-specific, 22
849
Index
file server applications, and QoS, 347
file syntax
ACL, 316
policy, 335
file system administration, 99
filename requirements, 100, 758
filenames, troubleshooting, 100, 758
files
copying, 102, 759
deleting, 106, 761
displaying, 103, 758
renaming, 101, 759
filter profiles and filters, SNMPv3, 93
filters, protocol, 265
firmware
displaying, 736
upgrading
BlackDiamond 12804, 734
BlackDiamond 8800 family, 733
flooding, 300
flooding, displaying, 152
flow control
displaying setting, 151, 152
Gigabit Ethernet ports, 120
Forwarding Database. See FDB
forwarding rules
MVR, 697
G
graceful OSPF restart, 649
gratuitous ARP
description, 398
enabling, 398
Greenwich Mean Time Offsets (table), 97
groups
ESRP, 576
SNMPv3, 89
guest VLAN
description, 442
disabling, 443
enabling, 443
troubleshooting, 442
H
hardware support, 27
helper-mode, 649
Hierarchical QoS.
See HQoS, rate limiting
History, RMON, 252
850
hitless failover
caveats
BlackDiamond 10K, 80
BlackDiamond 12804, 80
BlackDiamond 8800, 80
modular switches, all, 80
description, 76
EAPS, 477
ESRP, 563
I/O ports on MSM, 117
I/O version number, 717
network login, 429
platform support, 79
PoE, 187
protocol support, 77
STP, 517
hitless upgrade, 716
hold threshold, ELSM, 228
host attach, ESRP, 575
HQoS, 376
troubleshooting, 382
I
I/O module
diagnostics, 210
MSM, same module on BlackDiamond 8800
MSM
I/O ports, same module on BlackDiamond
8800 MSM, 116
power management, 81
I/O ports
BlackDiamond 8806 switch, 117
BlackDiamond 8810 switch, 116
I/O version number, 717
IEEE
802.1x, 439
IEEE 802.1ad, 129, 272
IEEE 802.1ag
IEEE 802.1ah, 283
IEEE 802.1D, 509
IEEE 802.1Q, 261
tagging, 261
IEEE 802.1Q-2003, 535
IEEE 802.1s, 535
IEEE 802.1w, 523
IGMP
and IP multinetting, 608
description, 688
snooping, 688, 705
snooping filters, 689
static, 689
Index
image
.xos file, 713
definition, 709
downloading, 712
primary and secondary, 711
rescue, 753
selecting a partition, 711
upgrading, 711
version string, 710
ingress rate shaping. See bi-directional rate
shaping or QoS
ingress rates, 373
inheriting ports, MSTP, 516
Input/Output module. See I/O module
interfaces
active, 686
IP multinetting, 606
IPv6 router, 618
passive, 686
router, 598
Internet Group Management Protocol. See IGMP
Internet Router Discovery Protocol. See IRDP
interoperability
requirements,
802.1x
authentication, 440
IP address
entering, 67
VLANs, 268
VMANs, 273
IP fragmentation, 124
IP multicast routing
configuring, 690
description, 685
example, 691
IGMP
description, 688
snooping, 688, 705
snooping filters, 689
PIM mode interoperation, 687
PIM multicast border router (PMBR), 687
PIM-DM, 686
PIM-SM, 686
IP multinetting
and ESRP, 585
configuring, 610
description, 605
example, 610
interface, 606
interoperability with
ARP, 607
BGP, 608
DHCP relay, 609
DHCP server, 609
EAPS, 609
ESRP, 609
851
Index
J
jumbo frames
BlackDiamond and Summit X450, 123
configuring on the BlackDiamond 8800
switch, 123
description, 122
enabling, 123
IP fragmentation, 124
path MTU discovery, 124
troubleshooting, 123
viewing port settings, 152
VMANs, 122
K
keys
line-editing, 45
port monitoring, 208
L
LACP
See link aggregation
LAG
See link aggregation
latestReceivedEngineTime, 88
Layer 1, troubleshooting, 739
Layer 2 protocols and ELSM, 232
Layer 2, troubleshooting, 740
Layer 3, troubleshooting, 740
LEDs, during diagnostics, 211
legacy powered devices.
See PoE
LFS
description, 120
troubleshooting, 120
license voucher, 36
licensing
description, 34
enabling, 37
license voucher, 36
ordering, 36
security license, 37
software keys, 34
SSH2, 38
verifying, 37
limit, sFlow maximum CPU sample limit, 250
limiting entries, FDB, 299
line-editing keys, 45
link aggregation
See also load sharing
adding or deleting ports, 132
and control protocols, 126
852
Index
load sharing
See also link aggregation
algorithms, 128
and ESRP dont count, 576
and ESRP host attach, 576
and VLANs, 135
BlackDiamond 10K switch, 128
BlackDiamond 8800 switch, 128
configuring, 132
displaying, 152
master port, 132
maximum ports and groups, 132
Summit X450 switch, 128
troubleshooting, 135
local agent, 248
local database authentication
description, 435
password, 435
user name, 435
local netlogin account
creating, 436
deleting, 439
destination VLAN
creating, 437
modifying, 439
displaying, 439
modifying, 438
log target, EMS
disabling, 236
enabling, 236
logging configuration changes, 247
logging in, 53
logging messages. See EMS
logout privilege, network login, 445
loop detection
using ELRP and ESRP, 578
using standalone ELRP, 750
loop tests
using ELRP and ESRP, 578
using standalone ELRP, 750
loopback interface, 678
LSA type numbers (table)
OSPF, 648
OSPFv3, 661
LSA, description, 648, 661
LSDB, description, 648, 661
M
MAC learning, FDB, 299
MAC-based
security, 299, 395
VLANs, network login, 452
MAC-based authentication
advantages, 427
configuration, example, 451
configuration, secure MAC, 451
description, 448
disabling, 449
disadvantages, 427
enabling, 449
MAC-in-MAC
and ACLs, 285
and VMAN frames, 284
BVLANs, 284
description, 283
Ethertype, 285
SVLANs, 284, 285
tag description, 284
troubelshooting, 285
management access, 49
management accounts
displaying, 54
Management Information Base. See MIBs
management port, 63
Management Switch Fabric Module. See MSM
manually bind ports, 514
master port, load sharing, 132
match conditions, ACL, 320, 324
match conditions, policy, 336
matching expressions, EMS, 242
matching parameters, EMS, 242
maximum CPU sample limit, sFlow, 250
memory protection, 100, 111
metering, 368, 373
mgmt VLAN, 63
MIBs, supported, 86, 779
MLD
description, 705
static, 706
modular switch
jumbo frames, 122
load sharing, configuring, 132
monitor port, 140
port number, 45, 118
port-mirroring, 140, 141
slot configuration, 115
virtual port, 141
module
enabling and disabling, 116
module recovery
actions, 221
configuring, 221
description, 220
displaying, 222
troubleshooting, 222
module, type and number of, 116
853
Index
monitor port, port-mirroring, 140
monitoring command prompt, 50
monitoring the switch, 205
MSM
console sessions, 61
diagnostics, 210
reboot, 716
MSM module
BlackDiamond 8806 switch, 117
BlackDiamond 8810 switch, 116
MSM prompt, troubleshooting, 746
MSMs, synchronizing, 730
MSTI
See also MSTP
configuring, 539
enabling, 540
identifier, 539
regional root bridge, 540
root port, 540
MSTI ID, 539
MSTP
See also RSTP
advantages of, 535
boundary ports, 540
common and internal spanning tree, 537
configuring, 542
edge safeguard, 525
enabling, 542
hop count, 542
identifiers, 513
inheriting ports, 516
link types
auto, 525
broadcast, 525
configuring, 525
description, 525
edge, 525
point-to-point, 525
multiple spanning tree instances, 539
operation, 544
overview, 535
port roles
alternate, 524
backup, 524
designated, 524
master, 541
root, 524
region
configuring, 537
description, 536
identifiers, 536
unconfiguring, 537
854
multicast
FDB static entry, 302
VMANs, 275
Multicast VLAN Registration
See MVR
Multicast, Source Specific, 687
multinetting. See IP multinetting
multiple routes, 599
multiple routes IPv6, 622
Multiple Spanning Tree Instances. See MSTI
Multiple Spanning Tree Protocol. See MSTP
multiple supplicants, network login support, 427
MVR, 696
dynamic, 696
forwarding rules, 697
N
names
character types, 43
conventions, 43
maximum length of, 43
VLAN, 267
VLAN, STP, EAPS, 43
native VLAN, PVST+, 523
netlogin. See network login
netlogin-only
disabled, 431
enabled, 431
network login
authenticating users, 431
authentication methods, 426
campus mode, 428
configuration examples
802.1x, 441
MAC-based, 451
web-based, 446
description, 425
disabling, 430
disabling, port, 430
enabling, 430
exclusions and limitations, 431
guest VLAN, 442
hitless failover support, 429
ISP mode, 428
local account
creating, 436
deleting, 439
displaying, 439
modifying, 438
local account, destination VLAN
creating, 437
modifying, 439
local database authentication, 435
Index
logout privilege, 445
MAC-based VLANs, 452
move fail action, 430
multiple supplicants, 427
port, enabling, 430
RADIUS attributes, 432
RADIUS authentication, 431
redirect page, 445
secure MAC, 449
session refresh, 445
settings, displaying, 430
user
netlogin-only disabled, 431
netlogin-only enabled, 431
user accounts, 431
web-based authentication, user login, 447
noAuthnoPriv, 90
node election
configuring priority, 73
determining primary, 73
overview, 72
node states, 76
node status, viewing, 75
non-aging entries, FDB, 297
normal area
OSPF, 652
OSPFv3, 663
notification tags, SNMPv3, 94
notification, SNMPv3, 92
Not-So-Stubby-Area. See NSSA
NSSA, 651, 663
See also OSPF
See also OSPFv3
O
opaque LSAs, OSPF, 649
Open Shortest Path First IPv6. See OSPFv3
Open Shortest Path First. See OSPF
OSPF
advantages, 634
and ESRP, 567
and IP multinetting, 607
area 0, 651
areas, 650
authentication, 655
backbone area, 651
configuration example, 657658
consistency, 648
database overflow, 648
description, 633, 647
display filtering, 659
enabling, 603
graceful restart, 649
P
partition, 711
passive interfaces, 686
password security
configuring, 53
displaying, 54
passwords, 52
creating, 53
default, 52
displaying, 54
failsafe account, 51
855
Index
forgetting, 53
local database authentication, 435
security, 52
shared secret, RADIUS, 404
shared secret, RADIUS accounting, 405
shared secret, TACACS, 412
shared secret, TACACS accounting, 414
troubleshooting, 52
path MTU discovery, 124
peer groups, 678
Per VLAN Spanning Tree. See PVST+
permanent entries, FDB, 297
permit-established, 330
PIM
and IP multinetting, 609
mode interoperation, 687
multicast border router (PMBR), 687
Source Specific Multicast, 687
PIM-DM
description, 686
example, 691
PIM-SM
description, 686
example, 692
rendezvous point, 686
PIM-SSM, 687
ping
troubleshooting, 57
platform availability, 27
platform dependence, 22
PoE
budgeted power, 189, 194
capacitance measurement, 196
configuration display, 197
configuring, 193
default power, 194
deny port, 194
denying power, 189
disconnect precedence, 194
EMS message, 191
enabling and disabling power, 193
features, 187
hitless failover support, 187
LEDs for usage, 192
legacy powered devices, 196
operator limit, 196
port fault state, 190
port labels, 197
port power limits, 192
port priority for PoE, 194
power budget, 197
power checking, 188
powering PoE modules, 188
required power, 188
856
Index
statistics, 206
transmit errors, 206
wildcard combinations, 45, 119
port lists, 44, 118
port mode, 547
port priority, STP, 547
port restart, ESRP, 574
port states, ELSM, 224
port weight, ESRP, 562
port-based load-sharing, 128
port-based VLANs, 259261
port-mirroring
and protocol analyzers, 142
description, 140
displaying, 143
examples, 142
guidelines, 142
monitor port, 140
tagged and untagged frames, 142
traffic filter, 141
troubleshooting, 142
virtual port, 141
post-authentication VLAN movement, network
login, 443
power checking, PoE modules, 188
power management
consumption, 81
displaying information, 84
initial system boot-up, 81
loss of power, 82
overriding, 83
re-enabling, 83
replacement power supply, 82
Summit X450, 83
Power over Ethernet.
See PoE
power supply controller, 81
powered devices.
See PoE
primary image, 711
prioritizing entries, FDB, 299
private AS numbers, 681
private community, SNMP, 86
privilege levels
admin, 50
user, 50
privileges
creating, 51
default, 50
viewing, 51
probe, RMON, 251
probeCapabilities, 253
probeDateTime, 253
probeHardwareRev, 253
probeResetControl, 254
probeSoftwareRev, 253
process
control, 100
displaying information, 108
error reporting, 756
management, 108
restarting, 110
starting, 110
stopping, 109
terminating, 109
profiles, QoS, 349, 351
prompt
admin account, 50
Bootloader, 731
BootRom, 731
unsaved changes, 50
user account, 50
protected VLAN, EAPS, 489
protected VLAN, STP, 511
protocol analyzers, use with port-mirroring, 142
protocol filters, 265
Protocol Independent Multicast- Dense Mode. See
PIM-DM
Protocol Independent Multicast. See PIM
Protocol Independent Multicast-Sparse Mode. See
PIM-SM
protocol-based VLANs, 264
proxy ARP
communicating with devices outside subnet,
602
conditions, 602
configuring, 601
description, 601
MAC address in response, 602
responding to requests, 602
subnets, 602
public community, SNMP, 86
PVST+
description, 513, 523
native VLAN, 523
VLAN mapping, 523
Q
QoS
802.1p priority
changing QoS profile mapping, 355
default mapping to QoS profile, 355
overview, 354
replacing value, 356
and ACLs, 348
and duplex, 347
applications, 346
857
Index
bandwidth utilization, 346
bi-directional rate shaping
configuring, 376
description, 373
maximum bandwidth, 374
maximum committed rate, 374
minimum bandwidth settings, 374
BlackDiamond 8800 specific, 349
buffer, 350
class of service, 354
classification priorities, 352
committed rates, 351
database applications, 347
default QoS profiles, 350, 351
description, 345
DiffServ
changing mapping to QoS profile, 359
configuring, 357
default mapping to QoS profile, 359
examining, 358
replacing value, 359
viewing mapping to QoS profile, 360
examples
source port, 361
VLAN, 362
file server applications, 347
guidelines, 368
ingress hardware queues
default mapping to priority value, 373
description, 373
ingress QoS profile (IQP), 373
maximum bandwidth, 351
metering, 368, 373
minimum bandwidth, 351
monitoring real-time performance, 367
overview, 30
peak rates, 351
precedence of traffic, 352
priority, 350, 351
profiles
default, 350, 351
description, 348
naming, 348
parameters, 350, 351
qostype priorities, 352
queues, 346
sFlow, 349
Summit X450 specific, 349
traffic groupings
ACL-based, 353
description, 348, 352
explicit packet marking, 354
source port, 361
VLAN, 362
858
R
RADIUS
accounting
configuring, 404
disabling, 405
enabling, 405
password, 405
and TACACS+, 64, 403, 411
client configuration, 406
description, 64, 402
enabling and disabling, 404
Merit server configuration (example), 408
password, 404
per-command authentication, 406
per-command configuration (example), 409
RFC 2138 attributes, 406
server configuration, 403
servers, 403
TCP port, 406
user accounts, creating, 431
RADIUS accounts, network login, 431
RADIUS attributes, network login, 432
rapid root failover, 516
Rapid Spanning Tree Protocol. See RSTP
rate limiting
egress traffic, 370, 371
strict priority, 376, 379
configuring CoS values, 380
configuring egress queues, 384
configuring ingress queues, 383
CoS values, 378
displaying, 385
egress, 377
example, 390
guidelines, 382
ingress, 377
meters, 379
modifying, 379
Index
modifying traffic queues, 385
ports, 378
queue CoS values, 388
queues, 378
statistics, 381, 386, 389
traffic queues, 378, 385
troubleshooting, 382
utilization, 387
VMANs, 377
flood control, 381, 389
rate shaping, bi-directional. See bi-directional
rate shaping
read-only switch access, 86
read-write switch access, 86
reboot
MSM, 716
switch, 715
receive errors, port, 207
receiver-mode, 683
redirect page, network login, 445
redirection, URL. See URL redirection
redundant ports, software-controlled
configuring, 148
description, 146
refresh
ACLs, 313
regions, MSTP, 536
related publications, 23
relative route priorities
IPv4, 600
IPv6, 623
Remote Authentication Dial In User Service. See
RADIUS
remote collector, 249
Remote Monitoring. See RMON
renaming a VLAN, 268
rendezvous point, 686
rescue image, 753
resilience, 476
responding to ARP requests, 601
restart
graceful, 649
restart process, 110
returning to factory defaults, 725
RFCs, 777
BGP, 671
bridge, 547
IPv4 multicast routing, 685
IPv4 unicast routing, 597
IPv6 unicast routing, 617, 619, 620
OSPF, 647
RIP, 633
RIPng, 641
VRRP, 587
RIP
advantages, 634
and IP multinetting, 608
configuration example, 637639
description, 633, 634
disabling route advertising, 635
enabling, 603
limitations, 634
poison reverse, 635
redistributing routes
configuring, 636, 654
description, 636, 654
enabling or disabling, 637
redistributing to BGP, 681
routing table entries, 634
split horizon, 635
triggered updates, 635
version 2, 635
RIPng
advantages, 642
configuration example, 644645
description, 641
disabling route advertising, 643
enabling, 624
limitations, 642
poison reverse, 643
redistributing routes
configuring, 643, 666
description, 643, 665
enabling or disabling, 644
routing table entries, 642
split horizon, 643
triggered updates, 643
RMON
agent, 251
alarm actions, 254
Alarms group, 253
configuring, 254
description, 251
Events group, 253
features supported, 252
History group, 252
management workstation, 252
output, 255
probe, 251
probeCapabilities, 253
probeDateTime, 253
probeHardwareRev, 253
probeResetControl, 254
probeSoftwareRev, 253
Statistics group, 252
trapDestTable, 254
route aggregation, 678
route confederations, 675
859
Index
route flap dampening, 679
route reflectors, 673
route selection, 681
router interfaces, 598, 618
router types
OSPF, 650
OSPFv3, 662
routing
See IP unicast routing
See IPv6 unicast routing
Routing Information Protocol, IPv6. See RIPng
Routing Information Protocol. See RIP
routing protocols and virtual routers, 307
routing table entries
RIP, 634
RIPng, 642
routing table IPv6, populating, 621
routing table, populating, 598
RSTP
See also STP
and STP, 534
configuring, 546
designated port rapid behavior, 529
edge safeguard, 525
link types
auto, 525
broadcast, 525
configuring, 525
description, 525
edge, 525
point-to-point, 525
operation, 527
overview, 523
port roles
alternate, 524
backup, 524
designated, 524
edge, 524
root, 524
rapid reconvergence, 530
receiving bridge behavior, 529
root port rapid behavior, 528
timers, 526
topology information, propagating, 529
rule entry
ACL, 316
policy, 335
rule types, 459
S
safe defaults mode, 48
safe defaults script, 48
sampling rate, sFlow, 250
860
Index
slot
automatic configuration, 115
clearing, 116
diagnostics, 208
displaying information, 116
enabling and disabling, 116
manual configuration, 116
mismatch, 116
preconfiguring, 116
Smart Redundancy
configuring, 148
description, 146
displaying, 152
port recovery, 147
smart refresh, ACLs, 313
SNAP protocol, 266
SNMP
and safe defaults mode, 85
community strings, 86
configuring, 86
settings, displaying, 86
supported MIBs, 86
system contact, 86
system location, 86
system name, 86
trap receivers, 86
using, 84
SNMPEngineBoots, 88
snmpEngineID, 88
SNMPEngineTime, 88
SNMPv3
filter profiles and filters, 93
groups, 89
MIB access control, 91
notification, 92
overview, 87
security, 88
security name, 89
tags, notification, 94
target address, 92
target parameters, 92
user name, 89
SNTP
configuring, 95
Daylight Savings Time, 95
description, 94
example, 98
Greenwich Mean Time offset, 95
Greenwich Mean Time Offsets (table), 97
NTP servers, 95
software
version for platforms, 27
software factory defaults, 38
software functionality, 35
861
Index
standards, 777
start process, 110
static, 696
static IGMP, 689
static MLD, 706
static MVR, 696
static networks, and BGP, 682
static routes, 599, 622
statistics
CPU utilization, 112
port, 206
Statistics, RMON, 252
status monitoring, 205
sticky threshold, ELSM, 229
stop process, 109
STP
advanced example, 520
and ESRP, 585
and IP multinetting, 609
and RSTP, 534
and VLANs, 510
and VRRP, 591
autobind ports, 515
basic configuration example, 518
bridge priority, 547
carrier vlan, 510
configurable parameters, 547
configuration examples, 548
configuring, 546
description, 509
displaying settings, 152, 553
domains
802.1D, 511
802.1w, 511
creating, 510
deleting, 510
description, 509
displaying, 554
mstp, 512
EMISTP
example, 520
rules, 521
encapsulation mode
802.1D, 512
description, 512
EMISTP, 512
PVST+, 513
forward delay, 547
guidelines, 546
hello time, 547
hitless failover support, 517
inheriting ports, 516
manually bind ports, 514
max age, 547
862
Index
example, BlackDiamond 10K switch, 218
example, BlackDiamond 8800 family, 219
modes of operation, BlackDiamond 10K
switch, 216, 763
modes of operation, BlackDiamond 8800
family, 217
modes of operation, BlackDiamond 8800
family of switches, 763
system health, monitoring, 216
system LEDs, 743
system location, SNMP, 86
system name, SNMP, 86
system odometer, 764
system recovery
configuring, 220
description, 220
displaying, 220
system redundancy
bulk checkpointing, 75
configuring node priority, 73
determining the primary node, 73
dynamic checkpointing, 75
failover, 73
node election, 72
relaying configurations, 74
viewing
checkpoint statistics, 75
status, 75
system temperature, 233
system virtual routers, 304
T
TACACS
accounting
configuring, 413
disabling, 414
enabling, 414
password, 414
configuration example, 412
password, 412
server configuration, 411
TACACS accounting
configuration example, 414
TACACS+
and RADIUS, 64, 403, 411
description, 64, 411
servers, specifying, 411
tagging, VLAN, 261
target address, SNMPv3, 92
target parameters, SNMPv3, 92
technical support, contacting, 769
Telnet
ACL policy, 69
863
Index
transmit errors, port, 206
trap receivers, SNMP, 86
trapDestTable, 254
triggered updates, RIP, 635
triggered updates, RIPng, 643
Trivial File Transfer Protocol. See TFTP
troubleshooting
ACLs, 311
AppleTalk, 265
ASCII-formatted configuration file, 726
campus mode, 428
connectivity, 56
copying files, 102
CPU utilization, 112
debug mode, EMS, 756
deleting files, 106
diagnostics
viewing results, 215
disabling backplane diagnostics, 764
downloads and TFTP, 71, 762
EAPS, 478
loop protection messages, 492
EAPS ring ports, 488
enabling backplane diagnostics, 763
ESRP, 559, 560, 749
filenames, 100, 758
guest VLAN configuration, 442
hitless failover
BlackDiamond 10K, 80
BlackDiamond 12804, 80
BlackDiamond 8800, 80
modular switches, all, 80
HQoS, 382
IP, 32
IP fragmentation, 124
ISP mode, 428
jumbo frames, 123
Layer 1, 739
Layer 2, 740
Layer 3, 740
LEDs
BlackDiamond 10K switch I/O module
diagnostics, 211
BlackDiamond 12804 R-Series switch I/O
module diagnostics, 214
BlackDiamond 12804 switch I/O module
diagnostics, 214
BlackDiamond 8800 family backup MSM
diagnostics, 213
BlackDiamond 8800 family I/O module
diagnostics, 212
BlackDiamond 8800 family primary MSM
diagnostics, 212
MSM-1 diagnostics, 212
864
MSM-1XL, 212
MSM-5 diagnostics, 215
MSM-5R, 215
Summit X450 switch diagnostics, 215
licenses, 35
link aggregation, 126
LLDP, 160, 161
load sharing, 126, 132
MAC-in-MAC, 285
memory, 111
module recovery, 222
MSM and I/O ports same module, 117
MSM prompt, 746
MSM-1 diagnostics, 768
MSM-1XL diagnostics, 768
passwords, 52
path MTU discovery, 124
ping, 56
PoE, 188, 189, 194, 195
port configuration, 747
port-mirroring, 141, 142
power fluctuation on PoE module, 766
QoS, 349, 357, 360, 361, 362
rate limiting, 382
rescue image, 753
software, 35
software-controlled redundant ports, 148
SSH2, 416
SSL, 50
SSL commands, 420
STP, 546, 748
system LEDs, 743
TFTP server, 71, 762
traceroute, 56
untagged frames on 10Gbps module, 768
virtual routers, 29
VLANs, 259, 262, 268, 270, 748
VMANs, 122, 274
VRRP, 595, 750
VRRP and ESRP, 596
trunks, 262
tunneling
IP, 626
See also VMANs
VMANs, 281
Type of Service. See TOS
U
UDP echo server, 615
untagged frames, VLANs, 259, 268
upgrading the image, 711
Index
uploading
ASCII-formatted configuration, 726
configuration, 727
upstream forwarding, 300
URL redirection, 426
user account, 50
user name, local database authentication, 435
user name, SNMPv3, 89
user sessions, 61
See also sessions
user virtual routers, 305
User-Based Security Model. See USM
users
access levels, 49
adding, 51
authenticating, 64, 402
creating, 51
default, 50
deleting, 51
passwords, 52
viewing, 51
USM, SNMPv3 security, 88
utilization
port, 154
V
vendor ID, 432
Vendor Specific Attribute. See VSA
verifying, 183
version string, 710
video applications, and QoS, 346
View-Based Access Control Model, SNMPv3, 91
Virtual LANs. See VLANs
virtual link
OSPF, 652
OSPFv3, 663
virtual port, port-mirroring, 141
Virtual Router Redundancy Protocol. See VRRP
virtual routers
adding and deleting routing protocols, 307
and routing protocols, 307
and VLANs, 258
commands, 305
configuration domain, 305
configuration example, 309
configuring routing protocols and VLANs, 308
creating, 306
default for Telnet, 66
deleting, 306
description, 303
displaying information, 308
overview, 29
system, 304
troubleshooting, 29
user, 305
VLAN tagging, 261
VLAN, guest. See guest VLAN
VLANid, 261
VLANs
and load sharing, 135
and STP, 510
and virtual routers, 258
assigning a tag, 262
assigning IP address, 268
benefits, 257
configuration examples, 270
configuring, 268
default tag, 262
description, 257
disabling, 269
disabling route advertising, 635, 643
displaying IPv6 addresses, 271
displaying settings, 152, 271
enabling, 269
IP fragmentation, 125
IPv4 routing, 602
IPv6 address, 270
IPv6 addresses, 257
IPv6 routing, 624
mgmt, 63
mixing port-based and tagged, 264
names, 43, 267
port-based, 259261
precedence, 267
protocol filters
customizing, 266
deleting, 266
predefined, 265
protocol-based, 264, 265
QoS profile, 271
renaming, 268
tagged, 261
troubleshooting, 259, 262, 267, 268, 270,
277, 748
trunks, 262
types, 258
untagged packets, 259, 262, 268
VLANid, 261
VMAN ACLs
action modifiers, 324
actions, 324
VMANs
ACLs, 377
and ACLs, 275
and CFM, 273
and EAPS, 281
and link aggregation, 126
865
Index
and virtual routers, 275
assigning IP addresses, 273
configuring, 277
displaying, 281
displaying settings, 152
EtherTypes, 273
example, 279, 280
guidelines, 276
jumbo frames, 122, 274
multicasting, 275
names, 43
rate limiting, 377
tagging ports, 273
troubleshooting, 126, 274, 277
voice applications, and QoS, 346
VoIP
network measurement, 772
VRRP
advertisement interval, 590, 593
and ESRP, 585, 591, 596
and IP multinetting, 609
and STP, 591
configuration parameters (table), 593
default gateway, 587
description, 587
electing the master, 590
examples, 594595
IP address, 593
master down interval, 590, 593
master router
determining, 587
electing, 590
multicast address, 590
operation, 591
ping tracking, 588, 589
preempt mode, 593
priority, 587, 590, 593
redundancy, 592
route table tracking, 588
skew time, 590, 593
tracking
description, 588
example, 589
troubleshooting, 595, 750
virtual IP addresses, 596
virtual router MAC address, 590, 591
VLAN tracking, 588, 589
VRRP virtual router identifier (VRID), 593
VSA
definitions, 432
definitions (table), 432
order of use, 433
866
VSA 203
example, 434
guidelines, 434
VSA 204
example, 435
guidelines, 435
VSA 205
example, 435
guidelines, 435
VSA 206
examples, 432
guidelines, 435
VSA 209
example, 434
guidelines, 434
VSA 211
examples, 433
guidelines, 433
W
web browsing applications, and QoS, 347
web-based authentication, 444
advantages, 427
configuration, example, 446
disabling, 444
disadvantages, 427
enabling, 444
requirements, 426
URL redirection, 426
user login setup, 447
wildcard combinations, port, 45, 119
X
XML, 108
XML configuration mode, 108