Some features in the Cisco Nexus Series switch require configuration synchronization with other switches in the network to function correctly. Synchronization through manual configuration at each switch in the network can be a tedious and error-prone process.

Cisco Fabric Services (CFS) provides a common infrastructure for automatic configuration synchronization in the network. It provides the transport function and a set of common services to the features. CFS has the ability to discover CFS-capable switches in the network and to discover feature capabilities in all CFS-capable switches.

Cisco Nexus Series switches support CFS message distribution over Fibre Channel and IPv4 or IPv6 networks. If the switch is provisioned with Fibre Channel ports, CFS over Fibre Channel is enabled by default while CFS over IP must be explicitly enabled.

CFS provides the following features:

• Peer-to-peer protocol with no client-server relationship at the CFS layer.

• CFS message distribution over Fibre Channel and IPv4 or IPv6 networks.

• Three modes of distribution.

  • Coordinated distributions—Only one distribution is allowed in the network at any given time.

  • Uncoordinated distributions—Multiple parallel distributions are allowed in the network except when a coordinated distribution is in progress.

  • Unrestricted uncoordinated distributions—Multiple parallel distributions are allowed in the network in the presence of an existing coordinated distribution. Unrestricted uncoordinated distributions are allowed to run in parallel with all other types of distributions.

The following features are supported for CFS distribution over IP:

• One scope of distribution over an IP network:

  • Physical scope—The distribution spans the entire IP network.

The following features are supported for CFS distribution over Fibre Channel SANs:

• Three scopes of distribution over SAN fabrics.

  • 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 — Some features require configuration distribution over some specific VSANs. These features can specify to CFS the set of VSANs over which to restrict the distribution.

• Supports a merge protocol that facilitates the merge of feature configuration during a fabric merge event (when two independent SAN fabrics merge).

The CFS distribution functionality is independent of the lower layer transport. Cisco Nexus Series switches support CFS distribution over IP and over Fibre Channel. Features that use CFS are unaware of the lower layer transport.

All switches in the network must be CFS capable. Switches that are not CFS capable do not receive distributions, which results in part of the network not receiving the intended distribution. CFS has the following requirements:

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

• 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 network. When you commit the changes, the pending database overwrites the configuration database (also known as the active database or the effective database).

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

• Explicit CFS commit—Most applications require an explicit commit operation to copy the changes in the temporary buffer to the application database, to distribute the new database to the network, and to release the network lock. The changes in the temporary buffer are not applied if you do not perform the commit operation.

All CFS-based applications provide an option to enable or disable the distribution capabilities.

Applications have the distribution enabled by default.

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

When you configure (first-time configuration) a feature (application) that uses the CFS infrastructure, that feature starts a CFS session and locks the network. When a network is locked, the switch software allows configuration changes to this feature only from the switch that holds the lock. If you make configuration changes to the feature from another switch, the switch 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 network lock but forget to end the session, an administrator can clear the session. If you lock a network at any time, your username is remembered across restarts and switchovers. If another user (on the same machine) tries to perform configuration tasks, that user’s attempts are rejected.

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

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 network lock.

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

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

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

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

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 overwrite 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.

You can clear a lock held by an application from any device in the fabric.

Caution

When you clear a lock in the fabric, any pending configurations in any device in the fabric are discarded.

A CFS region is a user-defined subset of switches for a given feature or application in its physical distribution scope. When a network spans a vast geography, you might need to localize or restrict the distribution of certain profiles among a set of switches based on their physical proximity. CFS regions allow you to create multiple islands of distribution within the network for a given CFS feature or application. CFS regions are designed to restrict the distribution of a feature’s configuration to a specific set or grouping of switches in a network.

Note	You can only configure a CFS region based on physical switches. You cannot configure a CFS region in a VSAN.

The Smart Call Home application triggers alerts to network administrators when a situation arises or something abnormal occurs. When the network covers many geographies, and there are multiple network administrators who are each responsible for a subset of switches in the network, the Smart Call Home application sends alerts to all network administrators regardless of their location. For the Smart Call Home application to send message alerts selectively to network administrators, the physical scope of the application has to be fine tuned or narrowed down. You can achieve this scenario by implementing CFS regions.

CFS regions are identified by numbers ranging from 0 through 200. Region 0 is reserved as the default region and contains every switch in the network. You can configure regions from 1 through 200. The default region maintains backward compatibility.

If the feature is moved, that is, assigned to a new region, its scope is restricted to that region; it ignores all other regions for distribution or merging purposes. The assignment of the region to a feature has precedence in distribution over its initial physical scope.

You can configure a CFS region to distribute configurations for multiple features. However, on a given switch, you can configure only one CFS region at a time to distribute the configuration for a given feature. Once you assign a feature to a CFS region, its configuration cannot be distributed within another CFS region.

You can create a CFS region.

You can assign an application on a switch to a region.

You can move an application from one region to another region.

Removing an application from a region is the same as moving the application back to the default region (Region 0), which brings the entire network into the scope of distribution for the application.

Deleting a region nullifies the region definition. All the applications bound by the region are released back to the default region.

You can enable or disable CFS over IPv4.

Note	CFS cannot distribute over both IPv4 and IPv6 from the same switch.

You can enable or disable CFS over IPv6.

Note	CFS cannot distribute over both IPv4 and IPv6 from the same switch.

The following example show how to verify the CFS over IP configuration:

switch# show cfs status
Distribution : Enabled
Distribution over IP : Enabled - mode IPv4
IPv4 multicast address : 239.255.70.83
IPv6 multicast address : ff15::efff:4653

All CFS over IP enabled switches with similar multicast addresses form one CFS over IP network. CFS protocol-specific distributions, such as the keepalive mechanism for detecting network topology changes, use the IP multicast address to send and receive information.

Note	CFS distributions for application data use directed unicast.

The following example shows how to verify the IP multicast address configuration for CFS over IP:

switch# show cfs status
Fabric distribution Enabled
IP distribution Enabled mode ipv4
IPv4 multicast address : 10.1.10.100
IPv6 multicast address : ff13::e244:4754

The show cfs merge status name command displays the merge status for a given application. The following example displays the output for an application distributing in logical scope. It shows the merge status in all valid VSANs on the switch. The command output shows the merge status as one of the following: Success, Waiting, or Failure or In Progress. In case of a successful merge, all the switches in the network are shown under the local network. In case of a merge failure or a merge in progress, the local network and the remote network involved in the merge are indicated separately. The application server in each network that is mainly responsible for the merge is indicated by the term Merge Master.

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 following example of the show cfs merge status name command output displays 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.

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 output displays all the switches in the physical network in terms of the switch WWN and the IP address. The local switch is indicated as Local.

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 command output shows all the peers for the physical scope or for each of the valid VSANs on the switch, depending on the application scope. For physical scope, the switch WWNs for all the peers are indicated. The local switch is indicated as Local.

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 following example show cfs peers name command output displays all the application peers (all switches in which that application is registered). The local switch is indicated as Local.

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 

The following table lists the default settings for CFS configurations.

The CISCO-CFS-MIB contains SNMP configuration information for any CFS-related functions. See the MIB reference for your platform.