Cisco MDS 9000 Family Configuration Guide, Release 2.x
Using the CFS Infrastructure

Table Of Contents

Using the CFS Infrastructure

About CFS

Cisco SAN-OS Features Using CFS

CFS Features

CFS Protocol

CFS Distribution Scopes

CFS Distribution Modes

Uncoordinated Distribution

Coordinated Distribution

Disabling CFS Distribution on a Switch

CFS Application Requirements

Enabling CFS for an Application

Locking the Fabric

Committing Changes

Discarding Changes

Saving the Configuration

Clearing a Locked Session

CFS Merge Support

Displaying CFS Configuration Information

Default Settings


Using the CFS Infrastructure


The Cisco SAN-OS software uses the Cisco Fabric Services (CFS) infrastructure to enable efficient database distribution and to foster device flexibility. It simplifies SAN provisioning by automatically distributing configuration information to all switches in a fabric.

Several Cisco SAN-OS applications use the CFS infrastructure to maintain and distribute the contents of a particular application's database.

About CFS

CFS Features

Cisco SAN-OS Features Using CFS

CFS Protocol

CFS Distribution Scopes

CFS Distribution Modes

Disabling CFS Distribution on a Switch

CFS Application Requirements

Enabling CFS for an Application

Locking the Fabric

Committing Changes

Discarding Changes

Saving the Configuration

Clearing a Locked Session

CFS Merge Support

Displaying CFS Configuration Information

Default Settings

About CFS

Many features in the Cisco MDS switches require configuration synchronization in all switches in the fabric. Maintaining configuration synchronization across a fabric is important to maintain fabric consistency. In the absence of a common infrastructure, such synchronization is achieved through manual configuration at each switch in the fabric. This process is tedious and error prone.

Cisco Fabric Services (CFS) provides a common infrastructure for automatic configuration synchronization in the fabric. It provides the transport function as well as a rich set of common services to the applications. CFS has the ability to discover CFS capable switches in the fabric and discovering application capabilities in all CFS capable switches.

Cisco SAN-OS Features Using CFS

The following Cisco SAN-OS features use the CFS infrastructure:

NTP (see "NTP Configuration Distribution" section on page 4-20).

Dynamic Port VSAN Membership (see Chapter 17, "Creating Dynamic VSANs").

Distributed Device Alias Services (see Chapter 20, "Distributing Device Alias Services").

IVR topology (see "Database Merge Guidelines" section on page 18-29).

TACACS and RADIUS (see the "Distributing AAA Server Configuration" section on page 28-15).

User and administrator roles (see "Role-Based Authorization" section on page 26-1).

Port security (see "Port Security Configuration Distribution" section on page 32-9).

iSNS (see "About iSCSI Storage Name Services" section on page 35-58).

Call Home (see "Call Home Configuration Distribution" section on page 45-12).

Syslog (see "System Message Logging Configuration Distribution" section on page 44-8).

Fctimer (see "fctimer Distribution" section on page 25-3).

SCSI Flow Services (see "Enabling SCSI Flow Configuration Distribution" section on page 38-4).

Saving startup configurations in the fabric using the Fabric Startup Configuration Manager (FSCM) (see "Saving Startup Configurations in the Fabric" section on page 7-5).

CFS Features

CFS has the following features:

Three modes of distribution

Coordinated distributions

Only one distribution is allowed in the fabric at any given time.

Uncoordinated distributions

Multiple parallel distributions are allowed in the fabric except when a coordinated distribution is in progress.

Unrestricted uncoordinated distributions

As of Cisco SAN-OS Release 2.1(1a), multiple parallel distributions are allowed in the fabric in the presence of an existing coordinated distribution. Unrestricted uncoordinated distributions are allowed to run in parallel with all other types of distributions.

Three scopes of distribution

Logical scope

The distribution occurs within the scope of a VSAN.

Physical scope

The distribution spans the entire physical topology.

Over a selected set of VSANs

As of Cisco SAN-OS Release 2.1(1a), some applications, such as Inter-VSAN Routing (IVR), require configuration distribution over some specific VSANs. These applications can specify to CFS the set of VSANs over which to restrict the distribution.

A peer-to-peer protocol that does not have a client-server relationship at the CFS layer.

Supports a merge protocol which facilitates the merge of application configuration during a fabric merge event (when two independent fabrics merge).

CFS Protocol

The CFS functionality is independent of the lower layer transport. Currently, in Cisco MDS switches, the CFS protocol layer resides on top of the FC2 layer. CFS uses the FC2 transport services to send information to other switches. CFS uses a proprietary SW_ILS (0x77434653) protocol for all CFS packets. CFS packets are sent to/from the switch domain controller addresses.

Applications that use CFS are completely unaware of the lower layer transport.

CFS Distribution Scopes

Different applications on the Cisco MDS 9000 Family switches need to distribute the configuration at various levels:

VSAN level

Applications that operate within the scope of a VSAN have the configuration distribution restricted to the VSAN. An example application is port security where the configuration database is applicable only within a VSAN.

Physical topology level

Applications might need to distribute the configuration to the entire physical topology spanning several VSANs. Such applications include NTP and DPVM (WWN based VSAN), which are independent of VSANs.

Between two switches

Applications might only operate between two switches in the fabric. An example application is SCSI Flow Services.

CFS Distribution Modes

CFS supports different distribution modes to support different application requirements: coordinated and uncoordinated distributions. Both modes are mutually exclusive. Only one mode is allowed at any given time.

Uncoordinated Distribution

Uncoordinated distributions are used to distribute information that is not expected to conflict with that from a peer. An example is local device registrations like in the case of iSNS. Parallel uncoordinated distributions are allowed for an application.

Coordinated Distribution

Coordinated distributions where an application can have only one such distribution at a given time. CFS uses locks to enforce this. A coordinated distribution is not allowed to start if locks are taken for the application anywhere in the fabric. A coordinated distribution consists of three stages:

1. A fabric lock is acquired.

2. The configuration is distributed and committed.

3. The fabric lock is released.

Coordinated distribution has two variants:

CFS driven —the stages are executed by CFS in response to an application request without intervention from the application.

Application driven—the stages are under the complete control of the application.

Coordinated distributions are used to distribute information that can be manipulated and distributed from multiple switches, for example, the port security configuration.

Disabling CFS Distribution on a Switch

By default, CFS distribution is enabled. Applications can distribute data and configuration information to all CFS-capable switches in the fabric where the applications exist. This is the normal mode of operation.

As of Cisco MDS SAN-OS 2.1(1a), you can globally disable CFS on a switch to isolate the applications using CFS from fabric-wide distributions while maintaining physical connectivity. When CFS is globally disabled on a switch, CFS operations are restricted to the switch and all CFS commands continue to function as if the switch were physically isolated.

To globally disable CFS distribution on a switch, follow these steps:

 
Command
Purpose

Step 1 

switch# config t

switch(config)#

Enters configuration mode.

Step 2 

switch(config)# no cfs distribution

Globally disables CFS distribution for all applications on the switch.

switch(config)# cfs distribution

Enables (default) CFS distribution on the switch.

CFS Application Requirements

All switches in the fabric must be CFS capable. A Cisco MDS 9000 Family switch is CFS capable if it is running Cisco SAN-OS Release 2.0(1b) or later. Switches that are not CFS capable do not receive distributions and result in part of the fabric not receiving the intended distribution.

CFS has the following requirements:

Implicit CFS usage—The first time you issue a CFS task for a CFS-enabled application, the configuration modification process begins and the application locks the fabric.

Pending database—The pending database is a temporary buffer to hold uncommitted information. The uncommitted changes are not applied immediately to ensure that the database is synchronized with the database in the other switches in the fabric. When you commit the changes, the pending database overwrites the configuration database (also know as active database or the effective database).

CFS distribution enabled or disabled on a per-application basis—The default (enable or disable) for CFS distribution state differs between applications. If CFS distribution is disabled for an application, then that application does not distribute any configuration nor does it accept a distribution from other switches in the fabric.

Explicit CFS commit—Most applications require an explicit commit operation to copy the changes in the temporary buffer to the application database and distributes the new database to the fabric and releases the fabric lock. The changes in the temporary buffer are not applied if you do not perform the commit operation.

Enabling CFS for an Application

All CFS based applications provide an option to enable or disable the distribution capabilities. Features that existed prior to Cisco SAN-OS Release 2.0(1b) have the distribution capability disabled by default and must have distribution capabilities enabled explicitly.

Applications that are introduced in Cisco SAN-OS Release 2.0(1b) have the distribution enabled by default.

The application configuration is not distributed by CFS unless distribution is explicitly enabled for that application.

Locking the Fabric

When you configure (first time configuration) a Cisco SAN-OS feature (or application) which uses the CFS infrastructure, that feature starts a CFS session and locks the fabric. When a fabric is locked, the Cisco SAN-OS software does not allow any configuration changes from a switch, other than the switch holding the lock, to this Cisco SAN-OS feature and issues a message to inform the user about the locked status. The configuration changes are held in a pending database by that application.

If you start a CFS session that requires a fabric lock but forget to end the session, an administrator can clear the session. If you lock a fabric at any time, your user name is remembered across restarts and switchovers. If another user (on the same machine) tries to perform configuration tasks, that user's attempts are rejected.

Committing Changes

A commit operation saves the pending database for all application peers and releases the lock for all switches.

In general, the commit function does not start a session—only a lock function starts a session. However, an empty commit is allowed, if configuration changes are not previously made. In this case, a commit operation results in a session that acquires locks and distributes the current database.

When you commit configuration changes to a feature using the CFS infrastructure, you receive a notification about one of the following responses:

One or more external switches report a successful status—The application applies the changes locally and releases the fabric lock.

None of the external switches report a successful state—The application considers this state as a failure and does not apply the changes to any switch in the fabric. The fabric lock is not released.

You can commit changes for a specified feature by using the commit command for that feature.

Discarding Changes

If you discard configuration changes, the application flushes the pending database and releases locks in the fabric. Both the abort and commit functions are only supported from the switch from which the fabric lock is acquired.

You can discard changes for a specified feature by using the abort command for that feature.

Saving the Configuration

Configuration changes that have not been applied yet (still in the pending database) are not shown in the running configuration. The configuration changes in the pending database overwrites the configuration in the effective database when you commit the changes.


Caution If you do not commit the changes, they are not saved to the running configuration.

The CISCO-CFS-MIB contains SNMP configuration information for any CFS-related functions. Refer to the Cisco MDS 9000 Family MIB Quick Reference for more information on this MIB.

Clearing a Locked Session

You can clear locks held by an application from any switch in the fabric. This option is provided to rescue you from situations where locks are acquired and not released. This function requires ADMIN permissions.


Caution Exercise caution when using this function to clear locks in the fabric. Any pending configurations in any switch in the fabric is flushed and lost.

CFS Merge Support

An application keeps the configuration synchronized in a fabric through CFS. Two such fabrics might merge as a result of an ISL coming up between them. These two fabrics could have two different sets of configuration information that need to be reconciled in the event of a merge. CFS provides notification each time an application peer comes online. If two fabrics with M and N application peers merge and if a application triggers a merge action on every such notification, a link up event results in M*N merges in the fabric

CFS supports a protocol that reduces the number of merges required to one by handling the complexity of the merge at the CFS layer. This protocol runs per application per scope. The protocol involves selecting one switch in a fabric as the merge manager for that fabric. The other switches do not play any role in the merge process.

During a merge, the merge manager in the two fabrics exchange their configuration databases with each other. The application on one of them merges the information, decides if the merge is successful and informs all switches in the combined fabric of the status of the merge.

In case of a successful merge, the merged database is distributed to all switches in the combined fabric and the entire new fabric remains in a consistent state. You can recover from a merge failure by starting a distribution from any of the switches in the new fabric. This distribution restores all peers in the fabric to the same configuration database.

Displaying CFS Configuration Information

The show cfs status command displays the status of CFS distribution on the switch (see Example 5-1).

Example 5-1 Displays CFS Distribution Status

switch# show cfs status
Fabric distribution Enabled

The show cfs application command displays the applications which are currently registered with CFS (see Example 5-2). The first column displays the application name. The second column indicates whether the application is enabled or disabled for distribution (enabled or disabled). The last column indicates the scope of distribution for the application (logical, physical, or both).


Note The show cfs application command only displays applications registered with CFS. Conditional services that use CFS do not appear in the output unless these services are running.



Note Prior to Cisco MDS SAN-OS Release 2.1(1a), vsan in the Application field represents the fctimer application. In Cisco Cisco MDS SAN-OS Release 2.1(1a) and later, the fctimer application appears as fctimer in the Application field.


Example 5-2 Displays the Currently Registered Applications Using CFS

switch# show cfs application

----------------------------------------------
 Application    Enabled   Scope
----------------------------------------------
 ntp            No        Physical
 fscm           Yes       Physical
 role           No        Physical
 radius         No        Physical
 tacacs         No        Physical
 fctimer        No        Physical
 syslogd        No        Physical
 callhome       No        Physical
 device-alias   Yes       Physical
 port-security  No        Logical

Total number of entries = 10

The show cfs application name command displays the details for a particular application. It displays the enabled/disabled state, timeout as registered with CFS, merge capability (if it has registered with CFS for merge support), and lastly the distribution scope. (see Example 5-3)

Example 5-3 Displays a Specified CFS Application

switch# show cfs application name ntp

 Enabled        : Yes
 Timeout        : 5s
 Merge Capable  : Yes
 Scope          : Physical

The show cfs lock command displays all the locks that are currently acquired by any application. For each application the command displays the application name and scope of the lock taken. If the application lock is taken in the physical scope it indicates the switch WWN, IP address, user name, and user type of the lock holder. If the application is taken in the logical scope then the VSAN in which the lock is taken, the domain, IP address, user name, and user type of the lock holder are displayed.(see Example 5-4)

Example 5-4 Displays the Currently Locked Applications

switch# show cfs lock

Application: ntp
Scope      : Physical
--------------------------------------------------------------------
 Switch WWN               IP Address       User Name    User Type
--------------------------------------------------------------------
 20:00:00:05:30:00:6b:9e  10.76.100.167    admin        CLI/SNMP v3
 Total number of entries = 1

Application: port-security
Scope      : Logical
-----------------------------------------------------------
 VSAN   Domain   IP Address       User Name    User Type
-----------------------------------------------------------
 1      238      10.76.100.167    admin        CLI/SNMP v3
 2      211      10.76.100.167    admin        CLI/SNMP v3
 Total number of entries = 2

The show cfs lock name command displays the lock details similar for the specified application.(see Example 5-5)

Example 5-5 Displays the Lock Information for the Specified Application

switch# show cfs lock name ntp
Scope      : Physical
--------------------------------------------------------------------
 Switch WWN               IP Address       User Name    User Type
--------------------------------------------------------------------
 20:00:00:05:30:00:6b:9e  10.76.100.167    admin        CLI/SNMP v3

 Total number of entries = 1

The show cfs merge status name command displays the merge status for a given application. Example 5-6 displays the output for an application distributing in logical scope shows the merge status in all the valid VSANs on the switch. The command shows the scope of merge i.e. logical and the vsan. It shows the merge status which is one of the following Success, waiting, Failure or In Progress. In case of a successful merge all the switches in the fabric are shown under the local fabric. In case of a merge failure or a merge being in progress the local fabric and the remote fabric involved in the merge are indicated separately. The application server in each fabric which is mainly responsible for the merge is indicated by the term Merge Master.

Example 5-6 Displays the Merge Status for the Specified Application

switch# show cfs merge status name port-security

Logical [VSAN 1] Merge Status: Failed
Local Fabric
----------------------------------------------------------------
 Domain Switch WWN               IP Address
----------------------------------------------------------------
 238    20:00:00:05:30:00:6b:9e  10.76.100.167   [Merge Master]

Remote Fabric
----------------------------------------------------------------
 Domain Switch WWN               IP Address
----------------------------------------------------------------
 236    20:00:00:0e:d7:00:3c:9e  10.76.100.169    [Merge Master]

Logical [VSAN 2] Merge Status: Success
Local Fabric
----------------------------------------------------------------
 Domain Switch WWN               IP Address
----------------------------------------------------------------
 211    20:00:00:05:30:00:6b:9e  10.76.100.167    [Merge Master]
 1      20:00:00:0e:d7:00:3c:9e  10.76.100.169

Logical [VSAN 3] Merge Status: Success
Local Fabric
----------------------------------------------------------------
 Domain Switch WWN               IP Address
----------------------------------------------------------------
 221    20:00:00:05:30:00:6b:9e  10.76.100.167    [Merge Master]
 103    20:00:00:0e:d7:00:3c:9e  10.76.100.169

The show cfs merge status name command displayed in Example 5-7 shows an application using the physical scope with a merge failure. The command uses the specified application name to display the merge status based on the application scope.

Example 5-7 Displays the Merge Status for a Physical Scope with Merge Failure

switch# show cfs merge status name ntp

Physical  Merge Status: Failed
Local Fabric
---------------------------------------------------------
 Switch WWN               IP Address
---------------------------------------------------------
 20:00:00:05:30:00:6b:9e  10.76.100.167    [Merge Master]

Remote Fabric
---------------------------------------------------------
 Switch WWN               IP Address
---------------------------------------------------------
 20:00:00:0e:d7:00:3c:9e  10.76.100.169    [Merge Master]

The show cfs peers command displays all the switches in the physical fabric in terms of the switch WWN and the IP address. The local switch is indicated as Local (see Example 5-8).

Example 5-8 Displays Peers in the Fabric

switch# show cfs peers

Physical Fabric
-------------------------------------------------
 Switch WWN               IP Address
-------------------------------------------------
 20:00:00:05:30:00:6b:9e  10.76.100.167   [Local]
 20:00:00:0e:d7:00:3c:9e  10.76.100.169

 Total number of entries = 2

The show cfs peers name command displays all the peers for which a particular application is registered with CFS. The output shows all the peers for physical scope or for each of the valid vsans on the switch depending on the application scope. For physical scope the switch WWN for all the peers are indicated. The local switch is indicated as Local (see Example 5-9).

Example 5-9 Displays Peers for a Specified CFS-Registered Application

switch# show cfs peers name ntp

Scope      : Physical 
------------------------------------------------- 
Switch WWN               IP Address 
------------------------------------------------- 
20:00:00:44:22:00:4a:9e  172.22.92.27    [Local] 
20:00:00:05:30:01:1b:c2  172.22.92.215 

The show cfs peers name command in Example 5-10 displays all the application peers (all switches in which that application is registered). The local switch is indicated as Local.

Example 5-10 Displays Logical Scope for Each VSAN

switch# show cfs peers name port-security
Scope      : Logical [VSAN 1] 
----------------------------------------------------------- 
Domain   Switch WWN               IP Address 
----------------------------------------------------------- 
124      20:00:00:44:22:00:4a:9e  172.22.92.27    [Local] 
98       20:00:00:05:30:01:1b:c2  172.22.92.215 

Total number of entries = 2 


Scope      : Logical [VSAN 3] 
----------------------------------------------------------- 
Domain   Switch WWN               IP Address 
----------------------------------------------------------- 
224      20:00:00:44:22:00:4a:9e  172.22.92.27    [Local] 
151      20:00:00:05:30:01:1b:c2  172.22.92.215 

Total number of entries = 2 

Default Settings

Table 5-1 lists the default settings for CFS configurations.

Table 5-1 Default CFS Parameters 

Parameters
Default

Database changes

Implicitly enabled with the first configuration change.

Application distribution

Differs based on application.

Commit

Explicit configuration is required.