MDS-Series Switch Tools

Copyright © 2010 EMC Corporation. Do not Copy - All Rights Reserved.
The objectives for this module are shown here. Please take a moment to read them.
MDS-Series Switch Tools - 1

The objectives for this lesson are shown here. Please take a moment to read them.

MDS-Series switches can be managed through CLI or GUI tools.

Command Line Interface - Useful for initial implementation and automation processes. The
CLI can be accessed from a serial connection through the console port, or through a telnet or
SSH session connected through the mgmt0 (management) port. Telnet is the default CLI
interface on the management port. The CLI enables the configuration of every feature of the
switch.
GUI – SNMP - The Cisco Fabric Manager is a set of network management tools that supports
Secure Simple Network Management Protocol version 3 (SNMPv3) with a Java web-based GUI
to view and configure MDS-Series of switches. Not all functions available through the CLI are
available through the GUI.
The Cisco Fabric Manager applications are:
 Fabric Manager Client/Server
 Device Manager
 Fabric Manager Web Services
 Performance Manager

There are multiple connection options and protocols available to manage the MDS Series
switches via the CLI. The initial configuration must be done with VT100 console access. VT100
console access can be a direct connection or a serial link connection, such as a modem.
When the initial configuration is complete, you can access the switch with either Secure Shell
(SSH) protocol or Telnet. SSH provides a secure encrypted means of access. Terminal Telnet
access involves a TCP/IP out-of-band (OOB) connection through the 10/100 MB Ethernet port
or an in-band connection via IP over Fibre Channel (FC).
You can access the MDS Series for configuration, status, or management through the console
port, or initiate a Telnet session through the OOB Ethernet management port or through the in-
band IP over FC management feature. The console port is an asynchronous port with a default
configuration of 9600 bps, 8 data bits, no parity, and 1 stop bit.
This port is the only means of accessing the switch after the initial power up until an IP address
is configured for the management port. After an IP address is configured, you can telnet to the
switch through the management 10/100/1000 (previously 10/100) port on the supervisor card.
In-band IP over FC is used to manage remote switches through the local 10/100 port.

The CLI commands are organized hierarchically, with commands that perform similar functions
grouped under the same level. For example, all commands that display information about the
system, configuration, or hardware are grouped under the show command, and all commands
that permit to configure the switch are grouped under the config terminal command.
To execute a command, start at the top level of the hierarchy. For example, to configure a Fibre
Channel interface, use the config terminal command. Once you are in Configuration mode, issue
the interface command. When you are in the interface submode, you can query the available
commands by typing "?".
To move up one level from Config mode or config sub-mode: type exit.
To move up directly to the top EXEC level: type end.

Fabric Manager (FM) software is no longer embedded in SAN-OS software. A user cannot
install Fabric Manager from the MDS Series switches. There are now Relational databases that
are separated from Fabric Manager software. There are two distinct versions of Fabric Manager,
Standalone and Fabric Manager Server. These are explained in this module. Fabric Manager
requires a more robust, commercial grade database for improved scalability and reliability.
Commercial database and Fabric Manager framework far exceed flash space available on
switches for management software. It is recommended that Fabric Manager Server be deployed
on a dedicated server. Fabric Manager is a Java-based application that can be deployed on any
platform that has the Java Runtime Environment (JRE). See the Fabric Manager Configuration
Guide for details on installing Fabric Manager Server on other operating systems and other
options for installation.

The MDS series SAN-OS is the underlying system software that powers the award-winning MDS series
multilayer switches. SAN-OS is designed for storage area networks (SANs) in the best traditions of Cisco
IOS software to create a strategic SAN platform of superior reliability, performance, scalability, and
features.
In addition to providing all the features that the market expects of a storage network switch, the SAN-OS
provides many unique features that help the MDS series to deliver low total cost of ownership (TCO) and
a quick return on investment (ROI).
Common Software across All Platforms
The SAN-OS runs on all MDS series switches, from multilayer fabric switches to multilayer directors.
Using the same base system software across the entire product line enables Cisco Systems to provide an
extensive, consistent, and compatible feature set on the MDS series.
Most MDS series software features are included in the base switch configuration. The standard software
package includes the base set of features that Cisco believes are required by most customers for building a
SAN. However, some features are logically grouped into add-on packages that must be licensed
separately.
The MDS series SAN-OS is the underlying system software that powers the award-winning MDS series
multilayer switches. SAN-OS is designed for storage area networks (SANs) in the best traditions of Cisco
IOS software to create a strategic SAN platform of superior reliability, performance, scalability, and
features.
In addition to providing all the features that the market expects of a storage network switch, the SAN-OS
provides many unique features that help the MDS series to deliver low total cost of ownership (TCO) and
a quick return on investment (ROI).
The SAN-OS feature packages are:

Enterprise package: Adds a set of advanced features which are recommended for all enterprise
SANs.
SAN Extension over IP package: Enables FCIP for IP Storage Services and allows the
customer to use the IP Storage Services to extend SANs over IP networks. Note: FCIP tape read
acceleration is not currently supported by EMC.
Mainframe package: Adds support for the FICON protocol. FICON VSAN support is provided
to help ensure that there is true hardware-based separation of FICON and open systems. Switch
cascading, fabric binding, and intermixing are also included in this package.
Note: FICON tape acceleration and FICON over FCIP are not currently supported by EMC, and
FICON is only qualified on specific versions of SANOS.
Fabric Manager Server package: Extends Cisco Fabric Manager by providing historical
performance monitoring for network traffic hotspot analysis, centralized management services,
and advanced application integration for greater management efficiency.
Storage Services Enabler package: Enables network-hosted storage applications to run on the
MDS series Storage Services Module (SSM). A Storage Services Enabler package must be
installed on each SSM.
The SAN-OS software package fact sheets are available at
http://www.cisco.com/en/US/products/hw/ps4159/ps4358/products_data_sheets_list.html.
License usability can be a nightmare with existing products. Customers have concerns about
compromising availability with disruptive software installations for licensed features. License
management is a notorious problem.
Cisco license packages require a simple installation of an electronic license: no software
installation or upgrade is required. Licenses can also be installed on the switch in the factory.
MDS switches store license keys on the chassis SPROM, so license keys are never lost even
during a switch software reinstall.
Cisco Fabric Manager (CFM) includes a centralized license management console that provides a
single interface for managing licenses across all MDS switches in the fabric, reducing
management overhead and preventing problems due to improperly maintained licensing. In the
event that an administrative error does occur with licensing, the switch provides a grace period
before the unlicensed features are disabled, so there is plenty of time to correct the licensing
issue.
All licensed features may be evaluated for a period of up to 120 days before a license is
required.

Licensing allows access to specified premium features on the switch after you install the
appropriate licenses. The licensing model defined for the MDS product line has two options:
 Feature-based licensing covers features that are applicable to the entire switch. The cost
varies based on a per switch usage.
 Module-based licensing covers features that require additional hardware modules. The cost
varies based on a per module usage. An example is the IPS-8 module using the CIP feature.
The FCIP license bundled with the Cisco MDS 9216i switch enables FCIP on the two fixed IP
services ports only. The features enabled on these ports by the bundled license are identical to
the features enabled by the FCIP license on the 14/2-port Multiprotocol Services module, such
as the FCIP package. If you install a module with IP ports in the empty slot on the Cisco MDS
9216i, you need a separate FCIP license to enable FCIP on the IP ports of the additional line
card.

If you need to install multiple licenses in any switch in a MDS Series switch, be sure to provide
unique file names for each license key file. To install a license key file in any switch, follow
these steps:
From a console session on the active supervisor, invoke the install license command:
 switch# install license bootflash:license_file.lic
 Installing license . . . done
If you provide a target name for the license key file, the file is installed with the specified name.
Otherwise, the file name specified in the license key file is used to install the license.
Exit the switch console and open a new terminal session to view all license files installed on the
switch using the show license command.
If the license meets all guidelines when the install license command is issued, all features and
modules continue functioning as configured. This is true for any MDS Series switch.


Before you can install the Cisco Fabric Manager, a supervisor module must be installed on each
switch that you want to manage. The supervisor module must be configured with the following
values, using the setup routine or the CLI:
 IP address assigned to the mgmt0 interface
 SNMPv3 user name and password, maintaining the same password for all the switches in the
fabric
The procedures you need to follow to access the Cisco Fabric Manager include:
 Completing the setup just described.
 Installing the fabric manager software on the client and server machines.
 Configuring a proxy server if your network uses a proxy server for HTTP requests.
 Launching the client applications.

FM cannot be downloaded directly from the switch. It must be installed from the provided CD-
ROM or from files downloaded from Powerlink. Once the FM server has been installed and
configured, the FM server can be accessed from a host, and FM may be downloaded.
Cisco FM Software Distribution:
 Cisco MDS Series switches
− Cisco Device Manager embedded in SAN-OS
 Cisco MDS Series Mgmt and Doc CD-ROM
− In accessory kit with every switch, includes:
 PostgreSQL database
 Cisco FM (standalone and server versions)
 Cisco MDS Series documentation
 CD distribution and Powerlink Download
− Fabric Manager

This screenshot shows how to access the FM software from the CD-ROM.

Current installation requirements:

 ActiveX
 JRE 1.5 required (1.6 not supported)

When installing FM for the first time, you can choose to install either FM Server or FM
Standalone. The install defaults to FM Standalone. If the FM server is desired, it must be
selected. FM Server requires a database and uses clients to manage fabrics.
Fabric Manager Server uses considerable system resources and CPU time, it is not
recommended for laptop installation.

These are the database options available for FM.

 PostgreSQL http://www.postgresql.org/
 Oracle XE http://www.oracle.com/technology/products/database/xe/index.html

FM server does not create desktop icons. FM client must be loaded in order for icons to be
created.
To verify that the installation was successful and that the server is functioning, check the
Services window. The service that will be running is Cisco Fabric Manager.

Once Fabric Manager Server is installed and running, the Client and be installed. The Client
allows interaction thru the server to manage the switches.
To install Fabric Manager Client open a connection thru port 80 with a web browser to the IP
address of the Fabric Manager Server. Log into the Server with the user and password created
during the installation.

Once logged on the Server, select Download on the far right of the web client. You see the Cisco
Fabric Manager screen where you can download both the Fabric Manager Client, which is
displayed as Fabric Manager, and Device Manager. Clicking these links installs either
application.

Steps to add a switch to be managed via Fabric Manager:

 Launch FM Client and log on to the FM server. Use IP address>username>password of the
FM Server.
 Add a switch, if there are none, or click the Discover button to add a switch.
 Select the Open tab and select a fabric to manage.
All manageable fabrics are listed regardless of their current status.
 Managed continuously
 Unmanaged
Select the checkbox to view/open fabrics in FM.

The menu tree is used to view fabric connectivity where links and switches are highlighted on
the topology map. Object attributes can be seen by double-clicking on the associated menu or
map object.
On the topology map, Inter-Switch Link (ISL) colors change based on utilization:
 Black: Normal utilization
 Orange: A greater than lower utilization threshold
 Red: A greater than high utilization threshold
Slashes (\) and Xs on the map are used as follows:
 Orange dashed X: A switch alert warning, such as a PortChannel member is down.
 Red X: Switch is unmanageable and nonfunctional, such as with a link down condition.
 Red \: Switch is unmanageable but functional.
Down elements can be removed from the map with Map Refresh or Purge.

Hosts and storage devices, otherwise referred to as initiators and targets, can have enclosures
created for them on the topology map by entering a common name among the discovered ports.
This screen is from the Fabric Manager Physical pane, under Connectivity/Storage/Interfaces. It
displays information about links to storage in the currently discovered fabric, in a tabular form
in the Information panel. Storage devices show logical unit numbers (LUNs) reported through
the LUN0 inquiry.
The most important information the screen provides is the relationship between the port World
Wide Name (pWWN), the FC identifier (FCID), the name of the device, and the attached-to
information for the switch and interface. This information can assist in troubleshooting, because
you get an overall view of the particular switch interface and what is connected to it.
Fabric pane can be filtered by group.
Hosts and storage devices
 Initiators and targets
 Enclosures created
 Distributed device aliases provide friendly names

Cisco Fabric Manager is a set of network management tools that supports secure SNMPv3 and
legacy versions. It provides a GUI that displays real-time views of the network fabric and lets
you manage the configuration of MDS series devices and third-party switches.
FMS is the server component of the Cisco Fabric Manager tool set and must be started before
running Cisco Fabric Manager. The most common deployment for the FMS is on a Windows
PC, where FMS is installed as a service. This service can then be administered using the service
panel on the control panel. In addition, the FMS can run as a UNIX or Linux daemon.
The figure illustrates communication between FMS, Cisco Fabric Manager client, Cisco Device
Manager client, and a Cisco MDS Series fabric. FMS, a Cisco Fabric Manager client, and a
Cisco Device Manager client can communicate directly with the Cisco MDS fabric using secure
SNMPv3 (by default). In addition, communication between FMS and a Cisco Fabric Manager
client occurs using remote method invocation (RMI).

Device manager is used to manage an individual switch/director including the installed

switching modules, the supervisor modules, the status of each port within each module, the
power supplies, and the fan assemblies.
While a Fabric Manager tables show values for one or more switches, Device Manager just can
show values for single switch, however, DM provide more detailed information (for
troubleshooting) of a specific device configuration than Fabric Manager.
Device Manager must be started for each switch/director that the user wishes to monitor and
manage.

Fabric Manager Web Server allows operators to monitor MDS events, performance and
inventory, and perform minor configuration tasks from a remote location using a web browser.
Fabric Manager Web Server provides the following features:
 Summary and drill-down reports
 Provides a high-level view of the network performance. These reports list the average and
peak throughput and provides hot-links to additional performance graphs and tables with
additional statistics.
 Zero maintenance database for statistics storage
 No maintenance is required to maintain Performance Manager’s round-robin database,
because its size does not grow over time. At prescribed intervals the oldest samples are
averaged (rolled-up) and saved. A full two days of raw samples are saved for maximum
resolution. Gradually the resolution is reduced as groups of the oldest samples are rolled up
together

Device Manager provides real-time, detailed port statistics using SNMP, Performance Manager
monitors network device statistics historically and provides this information graphically with a
web browser. It presents recent statistics in detail and older statistics in summary. Performance
Manager also is integrated with external tools, such as Cisco Traffic Analyzer. Performance
Manager requires an FMS license.

Performance Manager monitors receive (Rx) and transmit (Tx) bytes for ISL, host, and storage
ports. In addition, Performance Manager monitors traffic flows. Flows are the bytes and frames
sent from sources to destinations. Flows are configured based on active zones. Performance
Manager uses Cisco MDS Series route flow counters. No other application does this. In addition,
the data collection is end device-centric, meaning that port assignments can be changed without
requiring any reconfiguration.
The figure illustrates one active zone, Zone A, with three members that result in four traffic
flows. The following devices are not monitored:
 Devices attached to non-MDS switches
 Devices attached to Fabric Virtual (FV) advanced services module (ASM) interfaces
 Multiple devices sharing an interface (For example, a single NL device attached to an
FL_Port is monitored; however, more than one NL_Ports attached to an FL_Port, for
example, multidisk JBOD, that is, just a bunch of disks, are not.)

It is possible to configure the MDS-Series switch to send notifications to SNMP managers when
particular events occur. These notifications can be send as traps or inform requests. Traps are
unreliable because the receiver does not send any acknowledgment when it receives a trap. The
sender cannot determine if the trap was received. However, an SNMP manager that receives an
inform request acknowledges the message with an SNMP response. If the sender never receives
a response, the inform request can be sent again. Thus, informs are more likely to reach their
intended destinations.
Notifications may contain a list of MIB variables or varbinds that clarify the status being relayed
by the notification.

This lesson explains software licensing requirements and system software upgrade procedures.
The objectives for this lesson are shown here. Please take a moment to review them.

The MDS SAN-OS consists of two images: the kickstart image and the system image.
To upgrade the switch to a new image, you must specify the variables that direct the switch to
the images:
 To select the kickstart image, use the KICKSTART variable.
 To select the system image, use the SYSTEM variable.
The images and variables are important factors in any install procedure. You must specify the
variable and the image to upgrade your switch.
Unless explicitly stated, the software installation procedures in this section apply to any switch
in the MDS series.
The software image installation procedure is dependent on the following factors:
 Software images: The kickstart and system image files reside in directories or folders that
can be accessed from the MDS series switch prompt.
 Image version: Each image file has a version.
 Flash disks on the switch: The bootflash resides on the supervisor and the CompactFlash
disk is inserted into the slot0 device.
Supervisor-1 and Supervisor-2 have specific image requirements:
 Sup-1 image filename contains -sf1ek9
 Sup-2 image filename contains -sf2ek9
The software installation process is disruptive on systems with a single supervisor module.

Before attempting to migrate to any software image version, follow these guidelines:
 Before performing any software upgrade, contact your respective customer service
representative to review your software upgrade requirements and to provide
recommendations based on your current operating environment.
 Schedule the upgrade when the fabric is stable and steady. Ensure that everyone who has
access to the switch or the network is not configuring the switch or the network during this
upgrade, because all configurations will be disallowed at this time.
 Verify that sufficient space is available in the location where you are copying the images.
This location includes the active and standby supervisor modules or bootflash that is internal
to the switch. You can use the dir command to ensure that the required free space is available
for the image files to be copied. The internal bootflash offers approximately 200 MB of user
space.
 Avoid power interruptions to the hardware during any installation procedures. These kinds of
problems can corrupt the software image.
 Connectivity to remote servers to retrieve software images requires you to configure the IP
address for the management Ethernet port on the switch (interface mgmt0) and ensure the
switch has a route to the remote server. The switch and the remote server must be on the
same sub-network if you do not have a router to route traffic between subnets. Verify
connectivity to the remote server with the ping command.
 The specified system and kickstart images must be compatible with each other. If the
kickstart image is not specified, the switch uses the current running kickstart image. If you
specify a different system image, ensure that it is compatible with the running kickstart
image. To view the current version of system and kickstart images, use the show version
command.
Each switch is shipped with a Cisco MDS SAN-OS operating system for MDS series switches.
The SAN-OS consists of two images; the kickstart image and the system image.
All Flash devices reside on the supervisor module. The switch software can reside in either of
the two Flash devices. The Cisco MDS 9216 fabric switch has a single internal bootflash. The
MDS 9500 series has an internal bootflash and an external Compactflash.

At power-on, only supervisor modules are powered up, and the line card modules stay powered
down. Supervisors jump to the BIOS and start executing the loader from internal Flash. The
loader verifies the kickstart image and loads it. Optionally, you can boot the kickstart image
through bootp/tftp using the management port, directly from the BIOS or the loader.
The loader loads the kickstart image from bootflash, based on boot variables or what the user
types in at the loader prompt. The kickstart image contains the operating system (OS),
associated libraries, binaries, and some basic drivers and utilities necessary to boot the system
image. The loader then jumps to the SAN-OS and the OS boot starts. After the OS has
completely booted, some basic drivers are loaded.
When boot utilities are fired up and the console starts booting a system image from bootflash, if
no image is found or the image is corrupted or the wrong image type is found, kickstart stops at
the switch(boot)# prompt. If the corruption causes the console to stop at this prompt, copy the
system image and reboot the switch.
Vshboot provides scp and tftp facilities, where the system image is compressed with an MD5
checksum. Kickstart utilities verify the checksum and uncompress and load the system image.
At this time, a component called Platform Manager is loaded. Platform Manager is one of the
first services to be started.

The Cisco MDS SAN-OS software, designed for mission-critical high availability environments,
provides the ability to upgrade software without any disruptions. To realize the benefits of
nondisruptive upgrades on the Cisco MDS 9500 series, it is highly recommended that you install
dual supervisor modules. You can upgrade any switch in the Cisco MDS 9100, 9200 and 9500
series using one of three mechanisms:
 An automated, one step upgrade using the install all command
 A manual step-by-step upgrade
 A quick one-step upgrade using the reload command
Before running the reload command, copy the correct kickstart and system images to the correct
location and change the boot commands in config to use them. The quick upgrade, however is
disruptive. For nondisruptive upgrades, use the automated one-step upgrade or the manual step-
by-step upgrade.
In some cases, any software upgrade may be disruptive. These exception situations can occur
under the following conditions:
 A single supervisor system with kickstart image changes
 A single supervisor system with incompatible system software images
 A dual supervisor system with incompatible system software images
The install all command compares and presents the results of the compatibility before
proceeding with the installation. You have the opportunity to exit if you do not want to proceed
with these changes. To determine version compatibility between switch images, use the show
install all impact command. This command displays the impact of using the install all command.

It is recommended that the one-step install all command be used to upgrade your system software. This
command upgrades all modules in any MDS series switch. Only one install all command can be running
on a switch at any time, and no other command can be issued while running that command. The install all
command can not be performed on the standby supervisor module. It can only be issued on the active
supervisor module.
If the switching modules are not compatible with the new supervisor module image, some traffic
disruption may be noticed in the related modules, depending on your configuration. These modules are
identified in the summary when you issue the install all command. You can choose to proceed with the
upgrade or abort at this point.
To save the configuration after an upgrade, enter the copy running-config startup-config command from
the executive mode prompt to save the configuration into non-volatile storage. After this command is
issued, the running and the startup copies of the configuration are identical. This is necessary because the
boot variables are not automatically instantiated to the startup config file after an upgrade (manual, install
all, GUI, and so on). Without issuing this command immediately after a successful upgrade, you run the
risk of the switch rebooting to a previous release.
It is recommended that you issue the install all command from the console terminal of the active
supervisor module while having an additional console terminal open for the standby supervisor module.
After the install all command is issued in the console terminal of the active supervisor module, the
console terminal of the active supervisor module does not close, but it does become the console for the
new standby supervisor. The standby supervisor module console terminal remains open and displays the
full set of messages printed by the install all command process. If you choose to issue the install all
command from a telnet or secure shell (SSH) session, you can not view the full set of messages because
the connection is lost when the supervisor switchover occurs.

Images can be retrieved in one of two ways:

 Local, where images are locally available on the switch. The install all command uses the
specified local images.
 Remote, where images are in a remote location and the user specifies the destination using
the remote server parameters and the file name to be used locally.
To upgrade the switch to a new image, you must specify the variables that direct the switch to
the images. To select the kickstart image, use the kickstart variable, or to select the system
image, use the system variable. The images and variables are important factors in any install
procedure. You must specify the variable and the image to upgrade your switch. Both images are
not always required for each installation.

When you issue the install all command, the switch displays a summary of changes that are
made to your configuration and waits for your authorization to continue executing the command
process.
A compatibility check is conducted for each module installed in the system to be upgraded. The
impact of an upgrade and the install type are displayed.
Modules and specific images to be upgraded based on the files specified in the previous step are
displayed in an upgrade table that also shows the running and new versions.
Compatibility check terms are as follows:
 Bootable: The ability of the module to boot or not boot, based on image compatibility
 Impact: The type of software upgrade mechanism; disruptive or nondisruptive.
 Install type terms are as follows:
− reset: Resets the module
− sw-reset: Resets the module immediately after switchover
− rolling: Upgrades each module in sequence
− copy-only: Updates the software for BIOS, loader, or bootrom

If there are no issues with compatibility and you wish to continue with installing the images
identified, enter y (yes) when prompted.
After you confirm to continue with the installation, a display of the installation progress appears.
If install succeeds, you receive a notification that the install has been successful and the switch
prompt is displayed.
Some benefits of using the install all command to upgrade system software are:
 The streamlined process ensures using the best possible procedures to upgrade the software
in the least disruptive manner.
 All the software is upgraded in one easy step.
 The process verifies all the images before installation and detects incompatibilities.
 The process checks configuration compatibility.
 Information is provided about the impact of the upgrade before it takes place.

This section describes how to successfully downgrade SAN-OS versions that may have feature
incompatibility with the current running-config on the MDS Series platform.
Downgrading from a Higher Release
Use the install all command to gracefully reload the switch and handle configuration
conversions. When downgrading any switch in the MDS series, avoid using the reload
command.
See Determining Software Compatibility in the Cisco MDS Series Configuration Guide for more
details.


Device aliases have the following features:

 The device alias information is independent of your VSAN configuration. Aliases need only
be defined once and can then be used regardless of their VSAN.
 The device alias configuration and distribution is independent of the zone server and the
zone server database.
You can import legacy zone alias configurations without losing data.
The device alias application uses the Cisco Fabric Services (CFS) infrastructure to enable
efficient database management and distribution. Device aliases use the coordinated distribution
mode and the physical distribution scope. The device alias feature and CFS distribution are both
enabled by default in SAN-OS release 2.0 and later.
When you configure zones, inter-VSAN routing (IVR) zones, or quality of service (QoS)
features using device aliases, and display the configuration, you automatically see that the
device aliases are displayed along with their respective pWWNs.
Up to 8-K (8192) device aliases can be configured fabric-wide.
DDAS is a highly available process. The device alias databases are preserved across switch
restarts and switchovers, and the system can be restarted or switched over during CFS
distributions or merges.

As of MDS SAN-OS release 2.0, all switches in the MDS Series offer a new alias distribution
feature DDAS. In MDS SAN-OS release 1.3 and earlier, aliases were distributed on a per-VSAN
basis. Using this new, enhanced service, you now have the option to distribute device alias
names on a fabricwide basis.
Whenever the pWWN of a device is used to configure various features (zoning, QoS, port
security) in a MDS Series switch, you must assign the correct pWWN. An incorrect pWWN may
cause unexpected results. You can help prevent this problem by defining user-friendly names for
pWWNs and then use these in configuration commands as required. User-friendly names are
referred to as device aliases.
Device aliases simplify administration, and unlike legacy fcalias definitions, they allow you to
move HBAs and storage devices between VSANs without having to manually reenter the alias
names.

Device aliases have the following requirements:

 You can only assign device aliases to pWWNs.
 Ensure that the mapping between the pWWN and the device alias to which it is mapped has
a one to one relationship. A pWWN can be mapped to only one device alias and vice versa.
 A device alias name must begin with a letter and is restricted to 1-64 characters. Permissible
characters include one or more of the following:
− a to z and A to Z
− 0 to 9
− - (hyphen) and _ (underscore)
− $ and ^

To configure and distribute device aliases using Cisco Fabric Manager, choose the End Devices
folder in the Physical Attributes pane. Enter the device alias names as desired in the Device
Alias fields in the Information pane, and then click Apply Changes.
To make device alias names appear as enclosure names in the topology map, highlight the rows
in the table, and click the Alias Enclosure button.
Device aliases can be also be used in Cisco Fabric Manager. For example, when creating zones
for a VSAN using Fabric Manager, the configured device aliases appear for all the pWWNs that
have been mapped to device aliases within that VSAN.

This lesson describes the Fibre Channel (FC) interface configuration process.
Please take a moment to review the objectives.

There are three main types of ports on MDS-Series switches, though each type has its own
subtypes.
An N_Port (node port) is a port on a node that connects to a fabric, for example a host HBA.
I/O adapters and array controllers contain one or more N_Ports. N_Ports can also directly
connect two nodes in a point-to-point or Direct-Attached topology.
An F_Port (fabric port) is a port on a switch that connects to an N_Port.
An E_Port (expansion port) is a port on a switch that connects to another E_Port, in other words
an ISL of some kind. In addition, MDS switches implement TE_Port mode on switches that
connect to other MDS switches and perform VSAN trunking.

There is a special configuration submode for interface configuration. This submode is entered
with the interface fc2/1 command.
The switchport ? command from the interface configuration submode provides a listing of all
the options that are available for the switchport configuration of the interface.

The switchport mode fx command configures the interface for F_Port or FL_Port operation. In
order to configure interface fc1/5 as an F_Port, with a speed of 1-Gbps, follow these steps:
 Enter config
 Enter interface fc1/5
 Enter switchport mode fx
 Enter switchport speed 1000 (for connections to devices needing to receive at slower speed,
such as SD Port connecting to Port Analyzer Adapter)
 Enter no shutdown
 Enter end
To verify your configuration, use the show interface command: show interface fc1/5 brief.
The Rate Mode can be either dedicated or shared. The trunk mode is ignored for any port not
configured as an E_Port.

Each second-generation FC line card has four port groups that provide 12.8 Gbps per port group.
Port bandwidth reservations enable bandwidth to be dedicated to individual ports within a port
group.
Port bandwidth reservations enable bandwidth to be dedicated to individual ports such that they
are capable of sustaining a line rate of 4 Gbps on 24-port line cards and a line rate of 2 Gbps and
4 Gbps on 48-port line cards. That is, both the 24-port line card and the 48-port line card can be
configured so that they reserve capacity for up to 12 ports of line-rate traffic at 4 Gbps.

The MDS-PBF-24-8G line card has 24 auto-sensing 8 Gbps capable ports. There are eight port
groups, each consisting of three ports. Each port group shares approximately 12 Gb of
bandwidth. Ports can be configured in dedicated mode in configurations that do not exceed that
capacity. In shared-bandwidth mode, the oversubscription rate is 2:1 if all three ports in the
group are running at 8 Gbps. Since this is a performance card, it can only be installed in a
MDS-9500 series switch.
The MDS-PBF-44-8G line card has 48 8 Gbps capable FC ports. These ports are divided into 4
separate port groups, each containing 12 ports. If ports are configured for dedicated mode
bandwidth, as an E-Port for example, there are limitations as to how many ports per port group
can be configured. Essentially, each port group has 12 Gbps of bandwidth to utilize, and that
capacity can be divided in any way that does not exceed 12 Gbps. In shared rate mode, if all
ports in a port group are running at 8 Gbps, then the oversubscription rate is roughly 8:1.
This line card is the only 8 Gbps line card that can be installed in a MDS-9222i.
The MDS-PBF-48-8G line card has 48 auto-sensing 8 Gbps capable ports. There are eight port
groups, each consisting of six ports. Each port group shares approximately 12 Gb of bandwidth.
Ports can be configured in dedicated mode in configurations that do not exceed that capacity. In
shared-bandwidth mode, the oversubscription rate is 4:1 if all six ports in the group are running
at 8 Gbps. Since this is a performance card, it can only be installed in a MDS-9500 series
switch.

The switchport mode e command configures the interface for E_Port operation. In order to
configure interface fc1/2 as an E_Port, with a speed of 2 Gbps, and trunking disabled, follow
these steps:
 Enter config.
 Enter interface fc1/2.
 Enter switchport mode e (for connections to non-MDS switches).
 Enter switchport trunk mode off (for connections to non-MDS switches).
 Enter switchport speed 2000.
 Enter no shutdown.
 Enter end.
To verify your configuration, use the show interface command: show interface fc1/2 brie

Configuration allows for administratively enabling or disabling an interface. Any interface that
is administratively disabled will not function operationally, meaning it never comes to the up
state.
The shutdown command in the interface configuration submode disables a port, while preceding
the shutdown with the no shutdown option in the command enables the port (make it
administratively active). More examples are given in the figures showing actual configuration.
The operational state can be down even though the link layer is up, because the operational state
of an interface depends on the protocol running on the interface. For example, a trunking E_Port
(TE port) might have Fabric Shortest Path First (FSPF) running on it. If you get FSPF status for
the interface, it could be in the INIT state and will not be in the full operational state until the
FSPF Protocol has successfully completed its initialization sequence.
Traffic flows only through an interface when it is both administratively and operationally
functional.

The shutdown command administratively disables the interface, and the no shutdown command
administratively enables, or activates, the interface.
Follow these steps using Device Manager:
1. Right-click the port.
2. Choose Enable or Disable from the menu.
3. Click the Refresh icon.

The switchport mode e command configures the interface for E_Port operation. To
configure interface fc1/2 as an E_Port, with a speed of 2 Gbps, and trunking enabled,
follow these steps:
1. Enter conf t.
2. Enter interface fc1/2.
3. Enter switchport mode e.
4. Enter switchport trunk mode on (default).
5. Enter switchport speed 2000.
6. Enter no shutdown.
7. Enter end.
To verify your configuration, use the show interface command: show interface fc1/2 brief

Trunking mode is specific to the MDS Series, so if equipment attached to an Inter-Switch Link
(ISL) E_Port does not support trunk mode, the parameter is ignored. Therefore, equipment of
other vendors will not operate with the MDS switches in the trunking mode. It operates as a
regular E_Port. Even though trunking mode operates with one MDS Series switch set to
trunking mode auto and the other set to trunking mode on, it is advisable to set both ends to ON
if you use the link in a PortChannel, which you normally do. However, the PortChannel
demands only that all interfaces on one end of the channel have the same configuration. In TE
mode, an allowed list of VSANs can be configured for the interface; by default, all VSAN traffic
is allowed.

The switchport trunk ? command returns two options, the allowed VSAN list and the trunk
mode configuration.
Remember that a TE_Port allows traffic only for active allowed VSANs. If you do not configure
the VSAN allowed list correctly, certain VSAN traffic is not able to traverse the link. The
trunking mode should be set to on for TE_Ports and off for E_Ports.

This module outlines the secure protocols and methods that can be used to ensure secure access
to the management functions of the MDS Series. The increasing prevalence of SANs in the
enterprise have resulted in an increased awareness of SAN security vulnerabilities. Unauthorized
SAN management access poses serious risks to fabric stability, data integrity, and secrecy.
Without effective safeguards, a malicious user could alter the network configuration.
Please take a moment to review these objectives.

Unauthorized or unintentional access to SAN management can jeopardize the integrity and
stability of the SAN infrastructure. Traditional access protocols such as Telnet, rlogin, SNMPv1,
SNMPv2 and FTP are inherently insecure when used to access management ports on the MDS.

SSHv2 helps to prevent man-in-the-middle or replay attacks by providing an encrypted access

link between the management client and the switch. SSHv2 encrypts traffic between client and
MDS Series, authenticates communication between client and host, and prevents unauthorized
access. However, you must configure SSH Host Key Pair before enabling the SSH service.
There are three key pairs:
 Rivest, Shamir, and Adelman (RSA1) for Secure Shell version 1 (SSHv1) protocol
 Digital Signature Authority (DSA) for SSHv2 protocol
 RSA for SSHv2 protocol
With SSH, no password prompt is given. SSH is useful when running scripts. You need to first
generate the SSH key-pair on the SSH client machine, then configure the public key on the
MDS switch. You need to create a user account before you can configure an SSH key.
SNMPv3 uses encrypted gets, sets, and traps.
Secure File Transfer Protocol (SFTP) is an interactive file transfer program similar to FTP that
performs all operations over an encrypted SSH transport connection.

IP Access Control Lists (IP ACLs) provide basic network security to all switches in the MDS
Series. IP ACLs restrict IP-related MDS out-of-band management traffic and in-band traffic
based on IP addresses (Layer 3 and Layer 4 information). You can use IP ACLs to control
transmissions on an interface.
Follow these guidelines when configuring IP ACLs in any switch or director in the MDS Series:
 IP ACLs cannot be configured on Fibre Channel interfaces.
 IP ACLs can be configured only on the management interface, VSAN interfaces, and Gigabit
Ethernet interfaces.
An IP ACL is a sequential collection of permit and deny conditions that apply to IP flows. Each
IP packet is tested against the conditions in the list. The first match determines if the software
accepts or rejects the rule. Because the software stops testing conditions after the first match, the
order of the conditions in the list is critical. If no conditions match, the software rejects that rule.
An IP protocol can be configured using an integer ranging from 0 to 255 to represent a particular
IP protocol. Alternatively, you can specify the name of a protocol: icmp, ip, tcp, or udp. IP
includes Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control
Message Protocol (ICMP), and other protocols.

IP ACLs can be used to restrict the hosts that are allowed to access mgmt0.
To configure an IP ACL, you must complete the following tasks:
 Create an IP ACL by specifying a name and access condition. All lists use the source and destination
address for matching operations. You can configure finer granularity using optional keywords.
 Apply the access list to specified interfaces.
In this figure, an ACL (List1) is configured that will allow only a single host (host A) to access the
switch’s mgmt0 port. First the ACL is constructed to permit traffic flow from Host A to mgmt0; 10.0.17.2
is the IP address of the host, 10.0.17.5 is the IP address of the mgmt0 interface, and 0.0.0.0 specifies a
zero-length subnet mask. The second command in step 1 prevents traffic from all other sources; “deny tcp
any any” means “deny all tcp traffic from any source to any destination”.
ACLs are processed in order from the top down, until a match is found. When the switch detects a TCP
packet coming from 10.0.17.2 and destined for 10.0.17.5, the packet is matched against the first rule and
the packet is allowed to pass. TCP packets that do not match the first rule are compared against the
second rule, which specifies that they should be dropped.
In Step 2, the ACL List1 is applied to ingress traffic on mgmt0.
Note that the source/source-wildcard and destination/destination-wildcard can be specified in either of
two ways:
Using the 32-bit quantity in four-part, dotted decimal format (10.1.1.2/0.0.0.0 is the same as host
10.1.1.2).
Using the any option as an abbreviation for a source/source-wildcard or destination/destination-wildcard
(0.0.0.0/255.255.255.255).
You can control management access to MDS Series switches whether you are using the
command-line interface (CLI) or Simple Network Management Protocol (SNMP). CLI users
connect directly to the management port or via Telnet, and the Cisco Fabric Manager and Device
Manager use SNMP to communicate remotely with switches.
CLI and SNMP in all switches in the MDS Series, use common roles. Each role in SNMP is the
same as a role created or modified through the CLI. Common roles allow you to use a set of
rules to set the scope of VSAN security. Each role can be restricted to one or more VSANs as
required.
You can use SNMP to modify a role that was created using CLI and vice versa.

Switches in the MDS Series perform authentication based on roles. Role-based authorization limits access
to switch operations by assigning users to roles. This kind of authentication restricts users to management
operations based on the roles to which they have been assigned. When you execute a command, perform
command completion, or obtain context sensitive help; the switch software allows the operation to
progress only if you have permission to access that command.
By default, two roles exist in all MDS switches:
 Network-operator: This person has permission to view the configuration only and cannot make any
configuration changes.
 Network-admin: This person has permission to execute all commands and make configuration
changes.
The administrator can also create and customize up to 64 additional roles. Up to 16 rules can be
configured for each role. Only users belonging to the network-admin role can perform commands related
to roles.
If you use a SAN Volume Controller (SVC) setup, two more default roles exist in all MDS switches:
 Svc-admin: This person has permission to view the entire configuration and make SVC-specific
configuration changes.
 Svc-operator: This person has permission to view the entire configuration.
The operator cannot make any configuration changes.
Each role can contain multiple users and each user can be part of multiple roles. If you belong to multiple
roles, you can execute a union of all the commands permitted by these roles. Access to a command takes
priority over being denied access to a command.

VSAN-based access control enables the deployment of VSANs that fit existing operational
models. Network administrators can configure all platform-specific capabilities, while VSAN
administrators can configure and manage their own VSANs independently. Basically, the
existing role definition is enhanced to include VSANs.
In the figure, an administrator responsible for the email VSAN can only access it and not the
CRM VSAN. The same goes for the administrator of CRM VSAN who cannot access or control
the email VSAN. This feature adds another layer of security to the network.
Roles can be used to create VSAN administrators. You can configure a role so that it only allows
tasks to be performed for a chosen set of VSANs. By default, the VSAN policy for any role is
permit. In order to selectively allow VSANs for a role, the VSAN policy needs to be set to deny,
and then the appropriate VSANs need to be permitted.
Users configured in roles where the VSAN policy is set to deny cannot modify the configuration
for E_Ports. They can only modify the configuration for F or FL_Ports. This is to prevent
modifying configurations that may impact the core topology of the fabric.
Users in roles in which the VSAN policy is set to deny are referred to as VSAN-restricted users.
These users cannot perform commands that require the startup configuration to be viewed or
modified.
The Enterprise license is required for per-VSAN RBAC.

RBAC is recommended for increased SAN security. RBAC allows different administrative users
and groups to be granted different levels of access, as required by their job function. Some
administrators might be given read-only access to permit device monitoring, and others might be
given the ability to change port configurations, while only a few trusted administrators are given
the ability to change fabric-wide parameters.
With MDS SAN-OS Release 1.3.1 and higher, customers are able to define roles on a per-VSAN
basis. This enhanced granularity allows different administrators to be assigned to manage
different SAN domains, as defined by VSANs.
A Network Administrator is responsible for overall configuration and management of the
network, including platform-specific configuration, configuration of roles and role assignment.
Matching the VSANs to the existing operational structure allows for ease of matching user roles
to realistic groupings of operational responsibility. VSAN-based roles both limit the reach of
individual VSAN Administrators to the resources within their logical domain. In addition,
efficient grouping of commands into roles, and assignment of roles to users, allows mapping of
user accounts to practical roles, which reduces the likelihood of password sharing among
operational groups.

To create a role, use the role name <role-name> command. This command creates the role and moves you to
the role configuration sub-mode. To create an optional description for the role, use the description <line>
command.
Up to 16 rules can be configured for each role. The user-specified rule number determines the order in which
the rules are applied. Rule 1 is applied before rule 2, which is applied before rule 3, and so on. If, for example,
rule 1 specifies that all clear commands are denied, and rule 2 specifies all clear commands are allowed; then
all clear commands are allowed.
The rule command specifies operations that can be performed by the role. Each rule consists of a rule number,
a rule type, permit or deny, a command type; for example, config, clear, show, exec, or debug; and an optional
feature name; for example, fabric shortest path first (FSPF), zone, VSAN, fcping, or interface.
When creating a rule, exec commands refer to all commands in the EXEC mode that do not fall in the show,
debug, and clear, categories.
To configure a VSAN restricted role, first use the vsan policy deny command (requires Enterprise Package
License). This command disallows all VSANs on the role and moves you to the VSAN policy sub-mode.
Then, to allow one or more VSANs on the role, use the permit vsan <range> command. Multiple entries are
allowed. For example, given the following configuration:
 (config-role)# vsan policy deny
 (config-role-vsan)# permit vsan 2-5
 (config-role-vsan)# no permit vsan 3
The resulting VSAN allow list includes VSANs 1-2 and VSANs 4-5, but not VSAN 3.

When custom roles have been created, they can then be assigned to user accounts. If a user
account is created without assigning a role, that user is given the network-operator role.
To create a new user account with a password and default network-operator role, use the
username <user> password <password> command.
To create a new user account with a non-default role, use the username <user> password
<password> role <role-name> command.
To add a role to an existing user account, use the username <user> role <role-name>
command.

Cisco Fabric Manager can be used to create simple roles across multiple switches in the fabric.
To create a role using Cisco Fabric Manager, first choose SNMP from the Security folder in the
Physical Attributes pane, and then click the Create Row button in the toolbar. A creation dialog
box appears. Click the checkboxes for the switches where you want to configure the role, and
enter a name and description for the role.
The granularity of the roles created using Cisco Fabric Manager is limited. You can check or
uncheck the Has Config and Exec Permission checkbox. If you uncheck the box, the role
basically has read-only permissions. You can check the VSAN Scope Enable checkbox to
restrict role to one or more VSANs.

Cisco Device Manager can be used to create complex roles on a single switch. To create a role
using Cisco Device Manager, first choose Common Roles from the Security menu, and then
click Create in the dialog box displayed. Enter a name and description for the role. You can
check the VSAN Scope Enable checkbox to restrict role to one or more VSANs.
Click Rules to view the rules for the role, and choose the rules you want to enable or disable.
Click Apply to complete the configuration.

The authentication, authorization, and accounting (AAA) mechanism verifies the identity of,
grants access to, and tracks the actions of users managing a switch. All MDS Series switches use
Remote Access Dial-In User Service (RADIUS) and Terminal Access Controller Access Control
System Plus (TACACS+) protocols to provide solutions using remote AAA servers.
Based on the user ID and password combination provided, switches perform local authentication
or authorization using the local database or remote authentication or authorization using AAA
server(s). A preshared secret key provides security for communication between the switch and
AAA servers. This secret key can be configured for all AAA server or for only a specific AAA
server. This security mechanism provides a central management capability for AAA servers.

TACACS+ is a client/server protocol that uses TCP (TCP port 49) for transport requirements. All
switches in the MDS Series provide centralized authentication using the TACACS+ protocol.
The addition of TACACS+ support in MDS SAN-OS Release1.3(x) enables the following
advantages over RADIUS authentication:
 Provides independent, modular AAA facilities. Authorization can be done without
authentication.
 TCP transport protocol to send data between the AAA client and server, using reliable
transfers with a connection-oriented protocol.
 Encrypts the entire protocol payload between the switch and the AAA server to ensure
higher data confidentiality. The RADIUS protocol only encrypts passwords.
Enabling TACACS+
By default, the TACACS+ feature is disabled in all switches in the MDS Series. You must
explicitly enable the TACACS+ feature to access the configuration and verification commands
for fabric authentication. When you disable this feature, all related configurations are
automatically discarded.

You can specify remote AAA servers for authentication, authorization, and accounting using
server groups. A server group is a set of remote AAA servers implementing the same AAA
protocol. The purpose of a server group is to provide for fail-over servers in case a remote AAA
server fails to respond. If the first remote server in the group fails to respond, the next remote
server in the group is tried until one of the servers sends a response.
If all the AAA servers in the server group fail to respond, then that server group option is
considered a failure. If required, you can specify multiple server groups. If the MDS switch
encounters errors from the servers in the first group, it tries the servers in the next server group.

You can add up to five RADIUS servers using the radius-server host command. A RADIUS
server can be configured to be a primary server so that it is always contacted first. If you have
not configured a primary server, the RADIUS servers are tried in the order they were
configured. RADIUS keys are always stored in encrypted form in persistent storage. The
running configuration also displays encrypted keys.
To specify the RADIUS server address and the options, follow these steps:
 Add 10.10.0.0 users to the RADIUS server list as the primary server. This server is always
tried first:
− switch(config)# radius-server host 10.10.0.0 primary
 Specify a key for the selected RADIUS server. This key overrides the key assigned using the
radius-server key command:
− switch(config)# radius-server host 10.10.0.0 key HostKey
 Specify the destination User Datagram Protocol (UDP) port number to which the RADIUS
authentication messages should be sent:
− switch(config)# radius-server host 10.10.0.0 auth-port 2003
 Specify the destination UDP port number to which RADIUS accounting messages should be
sent:
− switch(config)# radius-server host 10.10.0.0 acct-port 2004

 Specify this server to be used for accounting purposes:

switch(config)# radius-server host 10.10.0.0 accounting
 Specify this server to be the primary server:
switch(config)# radius-server host radius1 primary
 Specify a clear text key for the specified server. The key is restricted to 65 characters:
switch(config)# radius-server host radius2 key 0 abcd
 Specify a reversible encrypted key for the specified server. The key is restricted to 65
characters:
switch(config)# radius-server host radius3 key 7 1234

You need to configure the RADIUS pre-shared key to authenticate the switch to the RADIUS
server. The length of the key is restricted to 65 characters and can include any printable
ASCII characters (white spaces are not allowed). You can configure a global key to be used
for all RADIUS server configurations on the switch. You can override this global key
assignment by explicitly using the key option in the radius-server host command.
To set the RADIUS pre-shared key, follow these steps:
1. Configure a preshared key (AnyWord) to authenticate communication between the
RADIUS client and server. The default is clear text:
switch(config)# radius-server key AnyWord
2. Configure a preshared key (AnyWord) specified in clear text (indicated by 0) to
authenticate communication between the RADIUS client and server:
switch(config)# radius-server key 0 AnyWord
3. Configure a preshared key (public) specified in encrypted text (indicated by 7) to
authenticate communication between the RADIUS client and server:
switch(config)# radius-server key 7 public
4. Use the show radius-server command to display configured RADIUS parameters.
Only administrators can view the RADIUS pre-shared key.

You can set authentication options separately for remote (Telnet and SSH) versus console login
using the aaa authentication login command. If authentication is not configured, local
authentication is used by default.
To configure AAA authentication for Telnet and SSH:
 switch(config)# aaa authentication login console group servergroup local
To configure console authentication:
 switch(config)# aaa authentication login default group servergroup local
Use the show aaa authentication command to verify your AAA configuration.

Display RADIUS server statistics using show radius-server statistics command:

 MDS# show radius-server statistics 10.1.3.2

These are the key points covered in this module. Please take a moment to review them.

MDS-Series Switch Tools

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MDS-Series Switch Tools

Uploaded by

Copyright:

Available Formats

Copyright © 2010 EMC Corporation. Do not Copy - All Rights Reserved.

MDS-Series Switch Tools - 1

MDS-Series Switch Tools - 2

MDS-Series switches can be managed through CLI or GUI tools.

MDS-Series Switch Tools - 3

MDS-Series Switch Tools - 4

MDS-Series Switch Tools - 5

MDS-Series Switch Tools - 6

The SAN-OS feature packages are:

MDS-Series Switch Tools - 9

MDS-Series Switch Tools - 10

MDS-Series Switch Tools - 11

MDS-Series Switch Tools - 12

MDS-Series Switch Tools - 13

MDS-Series Switch Tools - 14

MDS-Series Switch Tools - 15

Current installation requirements:

MDS-Series Switch Tools - 16

MDS-Series Switch Tools - 17

These are the database options available for FM.

MDS-Series Switch Tools - 18

MDS-Series Switch Tools - 19

MDS-Series Switch Tools - 20

MDS-Series Switch Tools - 21

Steps to add a switch to be managed via Fabric Manager:

MDS-Series Switch Tools - 22

MDS-Series Switch Tools - 23

MDS-Series Switch Tools - 24

MDS-Series Switch Tools - 25

Device manager is used to manage an individual switch/director including the installed

MDS-Series Switch Tools - 26

MDS-Series Switch Tools - 27

MDS-Series Switch Tools - 28

MDS-Series Switch Tools - 29

MDS-Series Switch Tools - 30

MDS-Series Switch Tools - 31

MDS-Series Switch Tools - 32

MDS-Series Switch Tools - 34

MDS-Series Switch Tools - 35

MDS-Series Switch Tools - 36

MDS-Series Switch Tools - 37

Images can be retrieved in one of two ways:

MDS-Series Switch Tools - 38

MDS-Series Switch Tools - 39

MDS-Series Switch Tools - 40

MDS-Series Switch Tools - 41

MDS-Series Switch Tools - 42

Device aliases have the following features:

MDS-Series Switch Tools - 43

MDS-Series Switch Tools - 44

Device aliases have the following requirements:

MDS-Series Switch Tools - 45

MDS-Series Switch Tools - 46

MDS-Series Switch Tools - 47

MDS-Series Switch Tools - 48

MDS-Series Switch Tools - 49

MDS-Series Switch Tools - 50

MDS-Series Switch Tools - 51

MDS-Series Switch Tools - 52

MDS-Series Switch Tools - 53

MDS-Series Switch Tools - 54

MDS-Series Switch Tools - 55

MDS-Series Switch Tools - 56

MDS-Series Switch Tools - 57