Central Management System Peer Service

Prev Next

As described in the Central Management System Administration Guide, Central Management System Peer Service provides a backbone to connect distributed Central Management System networks. It enables two-way interactions between the networks, allowing the networks to share vital data. For example, with the "Peer Event Correlation" feature, malicious URL events detected by a managed Network Security appliance in one network can be correlated with email events detected by a managed Email Security — Server appliance in another network.

In Central Management System HA deployments, Central Management System Peer Service runs between two HA clusters. One of the clusters manages Email Security — Server appliances, and the other cluster manages Network Security appliances.

Central Management System Peer Service runs between the two primary nodes in the HA clusters. After a failover, the Central Management System Peer Update feature sends the address information for the new primary node to the primary node in the other HA cluster. This allows seamless routing to the new primary node. For example, suppose the two Central Management System HA clusters in the following table are peers.

Cluster East

Cluster West

NY-01 (primary)

172.16.1.1

LA-01 (primary)

10.1.1.1

NY-02 (secondary)

172.16.1.2

LA-02 (secondary)

10.1.1.2

The Central Management System Peer Service runs between NY-01 and LA-01. Central Management System Peer service is disabled on the two secondary nodes (NY-02 and LA-02).

If LA-01 fails over to LA-02, the following happens:

  1. LA-02 is now the primary node, and knows the address information for NY-01 from the replication of the Central Management System Peer Service configuration from the original primary node, LA-01.

  2. NY-01 cannot interact with LA-02, because it does not have its address information.

  3. LA-02 invokes Central Management System Peer Update to update NY-01 with its address information.

  4. NY-01 now has address information for LA-02, and can interact normally using Central Management System Central Management System Peer Service.

Task List for Configuring Central Management System Peer Service Between HA Clusters

This section describes how to configure Central Management System Peer Service between two HA clusters. For details about how to perform each step, see the Central Management System Administration Guide.

Important

Perform these steps on each of the primary nodes. Do not perform these steps on the secondary nodes.

  1. Log in to each of the primary nodes.

  2. Enable Central Management System Peer Service with the cms feature peer-service enable command.

  3. Generate an authentication token with the cms peer-service auth-token generate command.

  4. Copy and paste the authentication token so it can be imported into the other primary node.

  5. Import the authentication token for the other primary node using the cms peer-service auth-token import <token> command. (Exclude the double-quotation marks.)

  6. Add the other primary node as a peer using the cms peer <peer name> enable command.

  7. Enable one or both of the Central Management System Peer Service features for the other primary node using the cms peer <peer name> interaction dist-correlation enable and cms peer <peer name> interaction dti enable commands.

  8. Save the configuration using the write memory command. The configuration will be replicated to the secondary node, but Central Management Systemp Peer Service will be disabled on the secondary node.

Example

In this example, Peer Service is configured between the primary node of each cluster (NY-01 and LA-01). The output shows the Peer Service status before and after LA-01 fails over to its secondary node (LA-02).

NY-01 Configuration

These commands configure Peer Service on NY-01, and add LA-01 as a peer.

NY-01 > enable
NY-01 # configure terminal
NY-01 (config) # cms peer-service enable
NY-01 (config) # cms peer-service auth-token generate
AUTH-TOKEN=
"ND91bWbgduG..."

AUTH-TOKEN CHECKSUM = "cav8813a3bdm173b4c86d0x8fr6038d9"
...
NY-01 (config) # cms peer-service auth-token import UT65jeutwpN...
NY-01 (config) # cms peer LA-01 enable
NY-01 (config) # cms peer LA-01 interaction dist-correlation enable
NY-01 (config) # cms peer LA-01 interaction dti enable
NY-01 (config) # show cms peer-service

CMS peer-service enabled:       yes

--------------------
  CMS peer LA-01:

     Enabled:                   yes
     Hostname:                  LA-01
     Address:                   10.1.1.1
     Auth-token checksum:       dux7696b0bnv427m6n38v3y2ds8654h2
     ...

LA-01 Configuration

These commands configure Peer Service on LA-01, and add NY-01 as a peer.

LA-01 > enable
LA-01 # configure terminal
LA-01 (config) # cms peer-service enable
LA-01 (config) # cms peer-service auth-token generate
AUTH-TOKEN=
"UT65jeutwpN..."

AUTH-TOKEN CHECKSUM = "dux7696b0bnv427m6n38v3y2ds8654h2"
LA-01 (config) # cms peer-service auth-token import ND91bWbgduG...
LA-01 (config) # cms peer NY-01 enable
LA-01 (config) # cms peer NY-01 interaction dist-correlation enable
LA-01 (config) # cms peer NY-01 interaction dti enable
LA-01 (config) # show cms peer-service

CMS peer-service enabled:       yes

--------------------
  CMS peer NY-01:

     Enabled:                   yes
     Hostname:                  NY-01
     Address:                   172.16.1.1
     Auth-token checksum:       cav8813a3bdm173b4c86d0x8fr6038d9
     ...

LA-02 Status Before Failover

This command shows that Peer Service is disabled for LA-02 because it is a secondary node.

LA-02 # show cms peer-service 

CMS peer-service enabled:       no

--------------------
  CMS peer NY-01:

     Enabled:                   yes
     Hostname:                  NY-01
     Address:                   172.16.1.1
     Auth-token checksum:       cav8813a3bdm173b4c86d0x8fr6038d9
     ... 

LA-02 Status After failover

This command shows that Peer Service is now enabled for LA-02, because after failover, LA-02 has the primary role.

LA-02 # show cms peer-service 

CMS peer-service enabled:       yes

--------------------
  CMS peer NY-01:

     Enabled:                   yes
     ...   

NY-01 Status After Failover

This command shows that after failover, the hostname and IP address for LA-02 are now displayed. However, the peer name and auth-token checksum remain the same.

NY-01 (config) # show cms peer-service

CMS peer-service enabled:       yes

--------------------
  CMS peer LA-01:

     Enabled:                   yes
     Hostname:                  LA-02
     Address:                   10.1.1.2
     Auth-token checksum:       dux7696b0bnv427m6n38v3y2ds8654h2
     ...