Configuring a DMR Cluster

A cluster is a provisioned object on an event broker that contains global DMR configuration parameters. There can be only one cluster for each node. Parameters configured at the cluster level apply to all links in the cluster, unless you override each setting by providing equivalent cluster link-level configuration.

To create a cluster, enter the following commands:

solace(configure)# routing
solace(configure/routing)# dynamic-message-routing
solace(...igure/routing/dynamic-message-routing)# create cluster <cluster-name>

To configure an existing cluster, enter the following command:

solace(...igure/routing/dynamic-message-routing)# cluster <cluster-name>

To enable the cluster, enter the following command:

solace(...uting/dynamic-message-routing/cluster)# no shutdown

Where:

<cluster-name> is the name of the cluster you want this node to belong to.

The configuration tasks that you can perform for an existing cluster include:

Configuring Authentication on a Cluster

When you configure cluster-level authentication, each setting applies for all links in the cluster. If you want to provide per-link authentication, refer to Configuring Authentication on the Link.

Configuring Basic Authentication

Basic authentication is the default client authentication scheme used by Solace PubSub+ event brokers. This authentication scheme allows cluster links to connect to a remote node and authenticate with that node using a password.

Basic authentication is compatible with both plain-text and encrypted connections.

To configure basic authentication for all links in the cluster, enter the following commands:

solace(...igure/routing/dynamic-message-routing)# cluster <cluster-name>
solace(...uting/dynamic-message-routing/cluster)# authentication
solace(...essage-routing/cluster/authentication)# basic

Configuring the Authentication Type

To configure the type of basic authentication to use for cluster link connections, enter the following command:

solace(...-routing/cluster/authentication/basic)# auth-type {internal | none}

Where:

internal specifies to authenticate cluster link connections against a locally-configured password.

none specifies that no authentication is required (in other words, an anonymous login is allowed).

Configuring a Password for Basic Internal Authentication

To configure a password for basic internal authentication of cluster link connections, enter the following command:

solace(...-routing/cluster/authentication/basic)# password <password>

Where:

<password> is the password you want to use to authenticate incoming cluster links (both control and data channels). This password is also used for all outgoing links if each link does not have a per-link password.

Configuring Authentication Using Client Certificates

Client-certificate authentication requires a cluster link to prove its identity to a remote node through an X509v3 client certificate from a recognized Certification Authority (CA).

To use client-certificate authentication, you must configure the client certificate that cluster links present to the remote node when initiating the connection. Each node can be configured with a per-cluster client certificate, which is used as the offered credentials for outgoing links. Only one client certificate can be configured per cluster; it can't be overridden on a per-link basis.

Client-certificate authentication is compatible with encrypted connections only.

To configure client-certificate authentication for all links in the cluster, enter the following commands:

solace(...igure/routing/dynamic-message-routing)# cluster <cluster-name>
solace(...uting/dynamic-message-routing/cluster)# authentication
solace(...essage-routing/cluster/authentication)# client-certificate 

Configuring the Client Certificate File to Present to Remote Nodes

To configure the certificate file to use, enter the following command:

solace(...ter/authentication/client-certificate)# certificate-file <file>

Where:

<file> specifies the certificate file used to authenticate all cluster links (both control and data channels). This certificate is presented to the remote node for authentication when the link is established. The certificate file must be in the certs directory in the jail directory (refer to Copying Files). Once installed, you may remove the file in the jail directory.

Enabling TLS/SSL Encryption

The following is required before you can enable TLS/SSL encryption for links in the cluster:

  • TLS/SSL service must be configured and enabled on both nodes on each cluster link. This requires the TLS/SSL server-certificate to be configured on the node which receives the encrypted connection. See Managing Server Certificates.

  • With client-certificate authentication configured, the client-certificate file that identifies the node initiating the encrypted connection must be loaded onto the node. See Configuring the Client Certificate File to Present to Remote Nodes.

To configure TLS/SSL encryption, enter the following commands:

solace(...uting/dynamic-message-routing/cluster)# ssl
solace(...g/dynamic-message-routing/cluster/ssl)# server-certificate-validation

The TLS/SSL configuration tasks that you can perform include:

When you make a change to the server certificate validation settings for a DMR cluster, the PubSub+ broker automatically disconnects and then reconnects all TLS-enabled links in the cluster to enable the change.

Enforcing Trusted Common Name

In release 9.7.0 and later, the enforce-trusted-common-name command has been deprecated and replaced with the validate-server-name command. For more information about the validate-server-name command, refer to Enabling the Validation of the Server Name.

You can enable or disable the enforcement of the common-name provided by the cluster link server-certificate against the list of common-names configured for that link. If enabled, the server-certificate’s common-name must match one of the trusted-common-names for the link to be accepted.

To enable trusted common name enforcement:

solace(...g/dynamic-message-routing/cluster/ssl)# server-certificate-validation
solace(...ter/ssl/server-certificate-validation)# enforce-trusted-common-name

To disable trusted common name enforcement:

solace(...ter/ssl/server-certificate-validation)# no enforce-trusted-common-name

Configuring the Maximum Certificate Chain Depth

You can configure the maximum allowed depth of a server-certificate chain. The depth of a chain is defined as the number of signing CA certificates that are present in the chain back to a trusted self-signed root CA certificate.

To configure the maximum allowed depth of a certificate chain, enter the following commands:

solace(...g/dynamic-message-routing/cluster/ssl)# server-certificate-validation
solace(...ter/ssl/server-certificate-validation)# max-certificate-chain-depth <max-depth>

Where:

<max-depth> specifies the maximum allowed depth of a certificate chain.

Enabling the Validation of the Certificate Date

You can enable or disable the validation of the Not Before and Not After validity dates in the server-certificate. When disabled, the certificate is accepted even if the certificate is not valid based on these dates.

To enable certificate date validation:

solace(...g/dynamic-message-routing/cluster/ssl)# server-certificate-validation
solace(...ter/ssl/server-certificate-validation)# validate-certificate-date

To disable certificate date validation:

solace(...ter/ssl/server-certificate-validation)# no validate-certificate-date

Enabling the Validation of the Server Name

You can enable or disable the TLS authentication mechanism to verify the name used to connect to the remote broker. If enabled, the Server Name Indication (SNI) extension is sent on outgoing TLS connections and the server name used for that connection is verified against the server names in the Subject Alternative Name (SAN) extension in the certificate returned from the remote broker.

This parameter is disabled for existing VPNs on brokers that have been upgraded from versions prior to 9.6; otherwise it is enabled by default.

To enable the validation of server names:

solace(...g/dynamic-message-routing/cluster/ssl)# server-certificate-validation
solace(...ter/ssl/server-certificate-validation)# validate-server-name

When validate-server-name is enabled, the enforce-trusted-common-name parameter is ignored (the broker behaves as if enforce-trusted-common-name is false regardless of its actual value).

To disable server name validation:

solace(...ter/ssl/server-certificate-validation)# no validate-server-name