Cisco MDS 9000 Family NX-OS Fabric Configuration Guide

Displaying FLOGI Details

To view the FLOGI database details, use the show flogi database command. See Examples 8-1 to 8-4 .

Example 8-1 Displays Details on the FLOGI Database

Example 8-2 Displays the FLOGI Database by Interface

Example 8-3 Displays the FLOGI Database by VSAN

Example 8-4 Displays the FLOGI Database by FC ID

For more information, see the “Default Company ID List” section and refer to the “Loop Monitoring” section in the Cisco MDS 9000 Family Troubleshooting Guide.

Bulk Notification Sent from the Name Server

In order to improve the performance of the Fibre Channel protocols on the Cisco MDS 9000 switch, the name server optimizes the remote entry change notifications by sending multiple notifications in one MTS payload. Nearly 10 other components that receive this MTS notification would have to function on the single bulk notification instead of multiple notifications.

Enabling Name Server Bulk Notification

For NX-OS Release 6.2(1) to 6.2(7), bulk notification is disabled by default. Enabling this feature in one switch has no bearing on the other switches in the same fabric.

Note From NX-OS Release 6.2(9) onwards, bulk notification is enabled by default.

Restrictions

• Whenever the intelligent applications such as the DMM, IOA, and SME are enabled, the bulk notification feature is not supported.
• Any configuration present in the FC-Redirect, conflicts with the bulk notification feature.

Note The above restrictions are applicable only to release 6.2.7.

Detailed Steps

To enable the name server bulk notification, follow these steps for NX-OS Release 6.2(1) to 6.2(7):

Disabling Name Server Bulk Notification

Detailed Steps

To disable the name server bulk notification, follow these steps for NX-OS Release 6.2(1) to 6.2(7):

To disable the name server bulk notification, follow these steps for NX-OS Release 6.2(9) and later:

To re-enable once it is disabled already for NX-OS Release 6.2(9) and later, follow these steps:

Name Server Proxy Registration

All name server registration requests are sent from the same port with a parameter that is registered or changed. If the port that does not have the parameter, then the request is rejected.

This authorization enables WWNs to register specific parameters for another node.

Registering Name Server Proxies

To register the name server proxy, follow these steps:

About Rejecting Duplicate pWWN

By FC standard, NX-OS will accept a login on any interface of a pwwn that is already logged in on the same switch, same vsan, same fcdomain. To prevent the same pwwn from logging in the same switch on a different interface, use the port security feature.

By default, any future flogi (with duplicate pwwn) on different switch in the same vsan, will be rejected and earlier FLOGI retained, which does not follow FC standards.

If you disable this option, any future flogi (with duplicate pwwn) on different switch in the same VSAN, will be allowed to succeed by deleting earlier FCNS entry.

Rejecting Duplicate pWWNs

To reject duplicate pWWNs, follow these steps:

Name Server Database Entries

The name server stores name entries for all hosts in the FCNS database. The name server permits an Nx port to register attributes during a PLOGI (to the name server) to obtain attributes of other hosts. These attributes are deregistered when the Nx port logs out either explicitly or implicitly.

In a multiswitch fabric configuration, the name server instances running on each switch shares information in a distributed database. One instance of the name server process runs on each switch.

Optimizing Name Server Database Sync

If an end device doesn't register FC4 feature with Name Server database, VHBA (also called scsi-target) component would perform PRLI to the end device to discover FC4 feature and register with Name Server on behalf of end device. This discovery from VHBA was performed both for locally connected devices

as well as remotely connected devices. This discovery was unnecessary for remotely connected devices because, Name Server would get FC4 feature of remotely connected devices through regular Name Server sync protocol. So, the default behavior of VHBA component has been modified to discover only locally connected devices. To modify this behavior, follow these steps:

Verifying the Number of Name Server Database Entries

To Verify the number of name server database entries, follow these steps:

Displaying Name Server Database Entries

Use the show fcns command to display the name server database and statistical information for a specified VSAN or for all VSANs (see Examples 8-5 to 8-8 ).

Example 8-5 Displays the Name Server Database

Example 8-6 Displays the Name Server Database for the Specified VSAN

Example 8-7 Displays the Name Server Database Details

Example 8-8 Displays the Name Server Statistics

About RSCN Information

Apart from sending these events to registered hosts, a switch RSCN (SW-RSCN) is sent to all reachable switches in the fabric.

Note The switch sends an RSCN to notify registered nodes that a change has occurred. It is up to the nodes to query the name server again to obtain the new information. The details of the changed information are not delivered by the switch in the RSCN sent to the nodes.

Displaying RSCN Information

Use the show rscn command to display RSCN information (see Examples 8-12 and 8-13 ).

Example 8-12 Displays Register Device Information

Note The SCR table is not configurable. It is populated when hosts send SCR frames with RSCN information. If hosts do not receive RSCN information, then the show rscn scr-table command will not return entries.

Example 8-13 Displays RSCN Counter Information

multi-pid Option

If the RSCN multi-pid option is enabled, then RSCNs generated to the registered Nx ports may contain more than one affected port IDs. In this case, zoning rules are applied before putting the multiple affected port IDs together in a single RSCN. By enabling this option, you can reduce the number of RSCNs. For example: Suppose you have two disks (D1, D2) and a host (H) connected to switch 1. Host H is registered to receive RSCNs. D1, D2 and H belong to the same zone. If disks D1 and D2 are online at the same time, then one of the following applies:

• The multi-pid option is disabled on switch 1: two RSCNs are generated to host H—one for the disk D1 and another for disk D2.
• The multi-pid option is enabled on switch 1: a single RSCN is generated to host H, and the RSCN payload lists the affected port IDs (in this case, both D1 and D2).

Note Some Nx ports may not understand multi-pid RSCN payloads. If not, disable the RSCN multi-pid option.

Configuring the multi-pid Option

To configure the multi-pid option, follow these steps:

Suppressing Domain Format SW-RSCNs

A domain format SW-RSCN is sent whenever the local switch name or the local switch management IP address changes. This SW-RSCN is sent to all other domains and switches over the ISLs. The remote switches can issue GMAL and GIELN commands to the switch that initiated the domain format SW-RSCN to determine what changed. Domain format SW-RSCNs can cause problems with some non-Cisco MDS switches (refer to the Cisco MDS 9000 Family Switch-to-Switch Interoperability Configuration Guide).

To suppress the transmission of these SW RSCNs over an ISL, follow these steps:

Note You cannot suppress transmission of port address or area address format RSCNs.

Coalesced SW-RSCN

In order to improve the performance of the Fibre Channel protocols on the Cisco MDS 9000 switch, SW-RSCNs are delayed, collected and sent as a single coalesced SW-RSCN to all the switches in the fabric in a single Fibre Channel exchange.

Enabling Coalesced SW-RSCNs

Restrictions

• All the switches in the fabric should be running Cisco MDS 6.2(7) and above.
• This feature does not have interoperability with non-Cisco MDS switches.

Detailed Steps

To enable the coalesced SW-RSCNs, follow these step:

Note All the switches running 6.2(7) and above are capable of processing coalesced SW-RSCN by default, but they are capable of sending coalesced SW-RSCN only after enabling through CLI.

Disabling Coalesced SW-RSCNs

Detailed Steps

To disable the coalesced SW-RSCNs, follow these steps:

Clearing RSCN Statistics

You can clear the counters and later view the counters for a different set of events. For example, you can keep track of how many RSCNs or SW-RSCNs are generated on a particular event (such as ONLINE or OFFLINE events). You can use these statistics to monitor responses for each event in the VSAN.

Use the clear rscn statistics command to clear the RSCN statistics for the specified VSAN.

After clearing the RSCN statistics, you can view the cleared counters by issuing the show rscn command.

RSCN Timer Configuration Distribution Using CFS

Because the timeout value for each switch is configured manually, a misconfiguration occurs when different switches time out at different times. This means different N ports in a network can receive RSCNs at different times. Cisco Fabric Services (CFS) alleviates this situation by automatically distributing configuration information to all switches in a fabric. This also reduces the number of SW-RSCNs.

RSCN supports two modes, distributed and nondistributed. In distributed mode, RSCN uses CFS to distribute configuration to all switches in the fabric. In nondistributed mode, only the configuration commands on the local switch are affected.

Note All configuration commands are not distributed. Only the rscn event-tov tov vsan vsan command is distributed.

The RSCN timer is registered with CFS during initialization and switchover. For high availability, if the RSCN timer distribution crashes and restarts or a switchover occurs, it resumes normal functionality from the state prior to the crash or switchover.

Note Before performing a downgrade, make sure that you revert the RCSN timer value in your network to the default value. Failure to do so will disable the links across your VSANs and other devices.

Compatibility across various Cisco MDS NX-OS releases during an upgrade or downgrade is supported by conf-check provided by CFS. If you attempt to downgrade from Cisco MDS SAN-OS Release 3.0, you are prompted with a conf-check warning. You are required to disable RSCN timer distribution support before you downgrade.

By default, the RSCN timer distribution capability is disabled and is therefore compatible when upgrading from any Cisco MDS SAN-OS release earlier than Release 3.0.

Configuring the RSCN Timer

RSCN maintains a per-VSAN event list queue, where the RSCN events are queued as they are generated. When the first RSCN event is queued, a per VSAN timer starts. Upon time-out, all the events are dequeued and coalesced RSCNs are sent to registered users. The default timer values minimize the number of coalesced RSCNs sent to registered users. Some deployments require smaller event timer values to track changes in the fabric.

Note The RSCN timer value must be the same on all switches in the VSAN. See the “RSCN Timer Configuration Distribution” section.

Note Before performing a downgrade, make sure that you revert the RCSN timer value in your network to the default value. Failure to do so will disable the links across your VSANs and other devices.

To configure the RSCN timer, follow these steps:

Verifying the RSCN Timer Configuration

You verify the RSCN timer configuration using the show rscn event-tov vsan command.

RSCN Timer Configuration Distribution

Because the timeout value for each switch is configured manually, a misconfiguration occurs when different switches time out at different times. This means different N-ports in a network can receive RSCNs at different times. Cisco Fabric Services (CFS) infrastructure alleviates this situation by automatically distributing the RSCN timer configuration information to all switches in a fabric. This also reduces the number of SW-RSCNs. Refer to the Cisco MDS 9000 Family NX-OS System Management Configuration Guide.

RSCN supports two modes, distributed and nondistributed. In distributed mode, RSCN uses CFS to distribute configuration to all switches in the fabric. In nondistributed mode, only the configuration commands on the local switch are affected.

Note All configuration commands are not distributed. Only the rscn event-tov tov vsan vsan command is distributed.

Note Only the RSCN timer configuration is distributed.

The RSCN timer is registered with CFS during initialization and switchover. For high availability, if the RSCN timer distribution crashes and restarts or a switchover occurs, it resumes normal functionality from the state prior to the crash or switchover.

Note You can determine the compatibility when downgrading to an earlier Cisco MDS NX-OS release using show incompatibility system command. You must disable RSCN timer distribution support before downgrading to an earlier release.

Note By default, the RSCN timer distribution capability is disabled and is compatible when upgrading from any Cisco MDS SAN-OS release earlier than 3.0.

Note For CFS distribution to operate correctly for the RSCN timer configuration, all switches in the fabric must be running Cisco SAN-OS Release 3.0(1) or later, or Cisco NX-OS 4.1(1b).

This section includes the following topics:

• Enabling RSCN Timer Configuration Distribution
• Locking the Fabric
• Committing the RSCN Timer Configuration Changes
• Discarding the RSCN Timer Configuration Changes
• Clearing a Locked Session
• Displaying RSCN Configuration Distribution Information

Enabling RSCN Timer Configuration Distribution

To enable RSCN timer configuration distribution, follow these steps:

Locking the Fabric

The first action that modifies the database creates the pending database and locks the feature in the VSAN. Once you lock the fabric, the following situations apply:

• No other user can make any configuration changes to this feature.
• A copy of the configuration database becomes the pending database along with the first active change.

Committing the RSCN Timer Configuration Changes

If you commit the changes made to the active database, the configuration is committed to all the switches in the fabric. On a successful commit, the configuration change is applied throughout the fabric and the lock is released.

To commit RSCN timer configuration changes, follow these steps:

Discarding the RSCN Timer Configuration Changes

If you discard (abort) the changes made to the pending database, the configuration database remains unaffected and the lock is released.

To discard RSCN timer configuration changes, follow these steps:

Clearing a Locked Session

If you have changed the RSCN timer configuration and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.

Tip The pending database is only available in the volatile directory and are subject to being discarded if the switch is restarted.

To use administrative privileges and release a locked DPVM session, use the clear rscn session vsan command in EXEC mode.

Displaying RSCN Configuration Distribution Information

Use the show cfs application name rscn command to display the registration status for RSCN configuration distribution.

Use the show rscn session status vsan command to display session status information for RSCN configuration distribution.

Note A merge failure results when the RSCN timer values are different on the merging fabrics.

Use the show rscn pending command to display the set of configuration commands that would take effect when you commit the configuration.

Note The pending database includes both existing and modified configuration.

Use the show rscn pending-diff command to display the difference between pending and active configurations. The following example shows the time-out value for VSAN 10 was changed from 2000 milliseconds (default) to 300 milliseconds.