Multi-Node Routing Management

In this section we'll discuss how to configure routing links between neighboring Solace PubSub+ message brokers so that topic subscriptions and Direct messages that clients add to one message broker can be delivered to clients connected to other message brokers throughout the network.

Solace's Content Shortest Path First (CSPF) protocol is used to enable the creation of routing links between neighboring message brokers to distribute and update the message broker network topology. MNR also relies on the Subscription Management Routing Protocol (SMRP) to enable topic subscriptions added by clients on one message broker to be propagated throughout the network.

 

Basics of Multi-Node Routing

Multi-Node Routing (MNR) allows multiple Solace PubSub+ message brokers to be networked together so that Direct messages published from clients connected to one message broker can be delivered to clients connected to other message brokers. This effectively distributes message routing loads across multiple message brokers in a network resulting in aggregate message forwarding rates across the network that exceed the capacity of any one message broker.

Solace's Content Shortest Path First (CSPF) protocol is used to link neighboring message brokers and allow them to discover the complete messaging network topology to which they belong. Message brokers can then determine which neighbor is the optimal node for forwarding messages addressed to specific destination message brokers. Topology discovery is continuous and dynamically updated as message brokers within the network go on or off line.

The Subscription Management Routing Protocol (SMRP) is also used to enable linked neighboring message brokers to propagate topic subscriptions added by the clients of one message broker throughout the messaging network. This allows messages that are published to one message broker to be routed to other message brokers that also have connected clients interested in those topics.

By default, data and routing traffic carried over MNR links is carried in plain text over TCP. Data compression can be applied on these links; however, if you'll be transmitting sensitive data in the messages sent between message brokers, Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) encryption can be applied to the MNR linksʼ data channels.

Linking Message Brokers

A routing link defines the route for connectivity between message brokers. When building a messaging network, administrators must explicitly configure the routing links between message broker neighbors. Both ends of a message routing link must be configured. That is, to link message brokers A and B, there must be a neighbor configuration in A for B, and a neighbor configuration in B for A. Using these bi-directional links, those neighbors are then able to exchange network topology using the CSPF protocol and subscription information using SMRP. These configured neighbor links allow Direct messages published by clients to travel between neighbors on their way to the final subscriber clients.

Compression can optionally used on neighbor message broker data connections (only data connections are affected).

Multiple bi-directional routing links can be used to route messages between message brokers in your network for load balancing or redundancy, and the routing protocols that are used will calculate the shortest path (as defined by link costs). Routes with lower link costs are preferred over those with higher link costs. If there are multiple routing links with equal cost paths, then a route with less hops will be chosen as the preferred route.

Where alternative routes are possible, an administrator can assign explicit link costs to indicate the best inter-neighbor message route. The rationale for assigning a higher link cost to a particular route could be based on considerations such as the speed, latency, or monetary cost of the underlying communication link.

Routing Link Cost Examples

To prefer one route over another (for example, to specify a default link), you can change the routing link costs to set the preferred message route.

In the example shown in Routing Link Cost—Example 1, there are four bi-directional routing links available between message brokers A, B, C, and D:

  • A-B routing link
  • B-C routing link
  • B-D routing link
  • C-D routing link

If the cost associated with the A-B routing link is set to 150, and the cost associated with the three other routing links is set to 100, messages routed from message broker A to C travel from message broker A to message broker B and then on to message broker C.

Routing Link Cost—Example 1
Routing Link Cost-Example 1

However, as shown in Routing Link Cost Example 2 , if the cost associated with the A-B routing link is set to 150, while the cost associated with the B-C routing link is set to 250, and the cost associated with the C-D and B-D routing links is set to 100, messages routed from message broker A to C travel from message broker A to Site B, on to message broker D, and then to message broker C. Such a cost configuration may be desirable in cases where, for example, two message broker sites in one city are connected by a high-speed link, while other overseas message broker sites are connected by low-speed links.

Routing Link Cost Example 2
Routing Link Cost—Example 2

Subscription Propagation and Management

When MNR is used, topic subscriptions and matching messages are only distributed between matching Message VPNs. This means that a message broker with a topic subscription in one message VPN can only receive matching messages from a neighbor message broker that were published to a Message VPN of the same name. For example if a message was published to Message VPN Blue on Router A, that message may be delivered to a client on Router B with a matching topic subscription in a Message VPN Blue, but it may not be delivered to a client on Router B with a matching topic subscription in a Message VPN Green.

Topic subscriptions can be added by external clients and internal clients (for example, the internal client of the Message VPN, #client). When external client subscriptions are associated with a specific virtual router name; internal client subscriptions are associated with a physical message broker name.

Exporting Topic Subscriptions

Each Message VPN has a topic subscription export policy associated with it, which controls whether or not topic subscriptions on the Message VPN get advertised to other message brokers in the network. The default policy is to not export subscriptions.

To receive messages from other message brokers, the subscription export policy in a Message VPN must be set to export subscriptions. This causes all subscriptions added locally to the Message VPN to be dynamically propagated to the other message brokers in the network.

Configuration Prerequisites

Before configuring the MNR settings for each message broker used throughout the network, you'll need to read and observe all of the following:

  1. MNR uses the static IP addresses of all message brokers in the message routing network. Before you can configure MNR on a message broker, you must know the static IP address of each neighbor you want the message broker to connect to.
  2. The message broker with the name that comes first in alphabetical order initiates the TCP connections.
  3. You must ensure that the following TCP ports are opened on each message broker used in the message-routing network:
    1. The routing control port. The default is 55556.
    2. One of either the SMF data, SMF compressed data, or SMF TLS / SSL data port, depending on the chosen configuration. The defaults are 55555, 55003, and 55443 respectively.
  4. The message brokers must have unique physical router names.

MNR Mode Configuration

In PubSub+ software message broker versions 8.13.0+, and appliance versions 9.1.0+, DMR routing mode is enabled by default. You must enable MNR mode before you can use MNR capabilities.

To enable or disable MNR mode, do the following:

To enable MNR mode, enter the following commands.

solace(configure)# routing
solace(configure/routing)# mode multi-node-routing [defer]

To disable MNR mode and enable DMR mode, enter the following commands:

solace(configure)# routing
solace(configure/routing)# mode dynamic-message-routing [defer]

Where:

defer specifies to defer the change until the next message broker restart.

You must restart the message broker before changes take effect. If you do not specify the defer keyword, you are immediately prompted to restart the message broker.

Creating Neighbor Links

A CSPF routing link goes from one message broker to a neighboring message broker, as identified by its physical router name.

Note:  To successfully link neighboring message brokers, both ends of a message routing link must be configured. That is, between two Solace message brokers A and B, there must be a neighbor configuration in A for B, and a neighbor configuration in B for A.

To create a CSPF routing link from the given message broker to a neighbor message broker, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# create cspf neighbor <physical-router-name>

To edit the properties of an existing CSPF routing link from the given message broker to a neighbor message broker, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>

Where:

<physical-router-name> is the name of the message broker. This name can contain up to 64 characters, composed of alphanumeric characters 0 to 9, a to z, A to Z, underscore '_', dot '.', and hyphen. Note that '_', '.' and '-' cannot be used at the beginning or end of a message broker name. Router names must be unique among all configured message brokers.

The no version of this command, no cspf neighbor, deletes the CSPF link on the given message broker, as long as the neighbor is shutdown.

The configuration parameters used for the link are set separately from the command that creates the routing link. The configuration tasks that you can perform for an existing link include:

Configuring Neighborsʼ IPs and Data Ports

To configure the IP address and optional port that the neighborʼs data port is reachable from, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# connect-via <ip-port>

Where:

<ip-port> is the static IP address or fully qualified domain name (FQDN) and TCP port of the neighbor message broker in the form “IP address[:port]” or "FQDN[:port]". The IP address is specified in the dotted decimal notation form nnn.nnn.nnn.nnn. The FQDN can contain up to 253 characters. The port is specified as a decimal value from 0 to 65535 (for example, 192.168.100.1:55555). If the port is unspecified, the default is 55555.

Note:  FQDNS are supported only on appliances using version 8.4.0+ software and Solace PubSub+ software message brokers version 8.8.0+.

Configuring Neighborsʼ Control Ports

To configure the IP address and optional port that the neighborʼs data port is reachable from, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# control-port <control-port>

Where:

<control-port> is the TCP control port number of the neighbor message broker. If left unspecified, the control port used is the one returned by the neighbor message broker during the neighbor link establishment phase. If specified as a decimal value from 0 to 65535, then this value takes precedence over that returned by the neighbor message broker.

Configuring Compressed Data Connections

You can use compression on the data connections to the neighbor message broker. Only data connections are affected—control connections are always uncompressed.

Compression is only available on plain-text connections to the neighbor message broker (the default). Message compression is not available on TLS/ SSL encryption is used for the data connections (that is, secure/encrypted client connections) to the neighbor.

To use compressed data connections to the neighbor, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# compressed-data

The no version of this command, no compressed-data, resets data connections to the default of uncompressed connections.

Note  This attribute can only be changed when the neighbor message broker is shutdown.

Enabling TLS/SSL Data Encryption

You can use TLS/ SSL encryption on the data connections to the neighbor message broker. Only data connections are affected. Control connections are not encrypted.

To use TLS/SSL data encryption on neighbor links, enable TLS/SSL encryption for each given link through the command below:

To enable the use encrypted data connections to the neighbor, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# ssl-data

The no version of this command, no ssl-data, resets data connections to the default of plain-text connections.

Note  
  • This attribute can only be changed when the neighbor message broker is shutdown.
  • TLS/SSL encryption is not available when data compression is used because data compression requires plain-text connections.
  • TLS/SSL encryption is only supported on the data links between appliances and the data links between software message brokers of release 8.5.0 and greater.

Configuring Cipher Suites

A list of cipher suites, in order of preference, can be specified to negotiate with the remote message broker. By default, all supported cipher suites are used, ordered from the most secure to the least secure. An empty cipher suite list will prevent the routing link from initiating a connection.

For a full list of cipher suites supported by message brokers, see Supported Cipher Suites.

To configure which cipher suites should be use on the routing link, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# ssl
solace(.../multi-node-routing/cspf/neighbor/ssl)# cipher-suite {default | empty | name <suite-name> [{before | after} <suite-name>]}

Where:

default specifies to use the default list of supported cipher suites, ordered from most secure to least secure.

empty removes all cipher suites from the list.

name <suite-name> adds the specified cipher suite to the list of suites to be used.

before <suite-name> specifies that the suite specified by the name parameter should be inserted into the list immediately before (that is, with a higher priority than) the suite specified by the before parameter.

after <suite-name> specifies that the suite specified by the name parameter should be inserted into the list immediately after (that is, with a lower priority than) the suite specified by the after parameter.

The no version of this command, no cipher suite name <suite-name>, removes the specified cipher suite from the list of eligible cipher suites.

Configuring Trusted Common Names

The routing link uses a list of trusted common names to verify the name in the certificate presented by the neighbor. By default, the list of trusted common names is empty, meaning that the link will not trust any common names.

To ensure that link will be established, regardless of whether the message broker is initiating or accepting the neighbor connection, this list should contain both the server-certificate CN and client-certificate CN of the neighbor message broker.

To configure a list of trusted common names for the link, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# ssl
solace(.../multi-node-routing/cspf/neighbor/ssl)# trusted-common-name {empty | name <common-name>}

Where:

empty removes all previously specified common names from the list.

name <common-name> specifies the name of a certificate to add to the list of trusted common names.

The no version of this command, no trusted-common-name name <common-name>, removes the specified common name from the list.

Note  The trusted common names list can be left empty if the Enforce Trusted Common Names certificate validation option is disabled.

Configuring Link Costs

If there are multiple routes between neighbors, and you want to enforce one route over another, you can assign specific costs to routing links to reflect the differences in the speed or monetary cost of each underlying communication link. Links with lower costs are preferred over links with higher costs. For examples of how to calculate link costs, see .

To change the cost for a routing link to a neighbor message broker, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf neighbor <physical-router-name>
solace(...ting/multi-node-routing/cspf/neighbor)# link-cost <cost>

Where:

<cost> is the integer value representing the new link cost to the neighbor message broker. The valid range is 1 to 255. If this parameter is not provided, the default value is 100.

The no version of this command, no link-cost, resets the link-cost value to the default.

Note  Existing link costs can be viewed using the show cspf route User EXEC command.

Configuring TCP Settings

For information on how to configure the TCP settings for neighbor links, see TCP Settings. This section discusses configuring the TCP settings used for message broker-to-message broker connections, as well as client‑to‑message broker connections.

Assigning Routing Interfaces

A routing interface must be assigned to use Solace routing protocols such as the CSPF and SMRP protocols that are used for MNR. A routing interface must also be assigned if the message broker is to be used in an HA redundant pair or if Config-Sync is to be enabled.

To assign a routing interface, enter the following command:

solace(configure)# routing
solace(configure/routing)# interface <phy-interface>

Where:

<phy-interface> is an ASCII string specifying the Ethernet interface port or LAG to be assigned. Valid values are eth<port> (for example, eth1); <cartridge>/<slot>/<port> (for example, 1/1/8); <cartridge>/<slot>/lag<N> (for example, 1/1/lag1). There is no default value.

Starting/Stopping Routing Protocols

To start running Solace routing protocols on the message broker (such as the CSPF protocol and SMRP used for MNR), enter the following commands:

solace(configure)# routing
solace(configure/routing)# no shutdown

To stop Solace routing protocols from running on the message broker, enter the following commands:

solace(configure)# routing
solace(configure/routing)# shutdown

Note  
  • By default, Solace routing protocols are stopped (that is, they are not running on message brokers).
  • To start MNR, you must start each message broker being networked together.
  • Whenever a message broker is restarted while running MNR, SMRP needs to learn of the topic subscriptions it is to become active for. It does this by synchronizing its database with the neighbor message brokers. However, if Solace routing protocols are stopped on any neighbor message broker, the message broker that is attempting to synchronize its SMRP database will stop its resynchronization attempt after three minutes.

Neighbor Link Configuration Example

An MNR network consists of two or more message brokers, with CPSF neighbor link connections provisioned between neighboring message brokers in accordance with the defined network topology.

Determining which pairs of message brokers have neighbor link connections determines the topology of a network. In this example we only describe the tasks required to configure message brokers for an MNR link configuration once all the network engineering has been done. As well, this section applies to appliances and assumes that the basic message broker configuration tasks described in Appliance Interface Configuration have been completed.

To successfully provision an MNR network, two separate levels of configuration are required, in this order:

  1. Message Broker-Wide Configuration Tasks
  2. Per-Neighbor Link Configuration Tasks

Message Broker-Wide Configuration Tasks

Perform these tasks on each and every message broker in the network, regardless of the number of neighbor link connections, to provision and enable the routing interface used by the Solace routing protocols for MNR:

  1. To enable message brokers to connect to the routing interface of their neighbors, configure a static IP interface on each message broker in the MNR network. This static IP interface can either be an independent port on the NAB, or a LAG interface consisting of one or more NAB ports.

    solace> enable

     

    solace# configure

     

    solace(configure)# ip vrf msg-backbone

     

    solace(configure/ip/vrf)# create interface 1/6/1:3 static

    Create the static IP interface

    solace(configure/ip/vrf/interface)# ip-address 192.168.1.10/24

    Set the static IP interface address

    solace(configure/ip/vrf/interface)# no shutdown

    Enable the static IP interface

    solace(configure/ip/vrfinterface)# exit

     

    solace(configure/ip/vrf)# route default 192.168.1.1

    Configure the IP route for the Message Backbone VRF

    solace(configure/ip/vrf)# end

     

    solace#

     

    Note:  To assign independent IP addresses to all ports of the NAB (that is, when there is no LAG configured), or have a mixture of some NAB Ethernet ports grouped into a single LAG and the remaining ports independently addressed, see Appliance Interface Configuration.

  2. Verify IP connectivity between the static IP addresses of neighboring message brokers.

    In the following example, the static IP interface address of the neighbor message broker is 192.168.1.11:

    solace(configure)# ping msg-backbone:192.168.1.11

    PING 192.168.1.11 56(84) bytes of data.

    64 bytes from 192.168.1.11: icmp_seq=1 ttl=20 time=0.105ms

    64 bytes from 192.168.1.11: icmp_seq=2 ttl=20 time=1.570ms

    64 bytes from 192.168.1.11: icmp_seq=3 ttl=20 time=0.098ms

    64 bytes from 192.168.1.11: icmp_seq=4 ttl=20 time=0.089ms

     

    --- 192.168.1.11 ping statistics ---

    4 packets transmitted, 4 received, 0% packet loss, time 4000ms

    rtt min/avg/max/mdev = 0.089/0.466/1.570/0.736 ms

  3. Configure on each message broker a routing interface and enable the Solace routing protocols.

    Note:  The routing interface should be the same physical interface as the static IP interface already created in step 1, whether it be a single port on the NAB or a LAG interface.

    solace# configure
    solace(configure)# routing
    solace(configure/routing)# interface 1/6/1
    solace(configure/routing)# no shutdown

Per-Neighbor Link Configuration Tasks

After successfully completing the preceding message broker-wide configuration tasks, do the following:

  1. Configure the CSPF neighbor link connections between neighbor message brokers.

    For example, assuming the neighboring message brokers are named solace10 and solace11, and they have static IP addresses of 192.168.1.10 and 192.168.1.11, respectively:

    solace10(configure)# routing
    solace10(configure/routing)# multi-node-routing
    solace10(configure/routing/multi-node-routing)# create cspf neighbor solace11
    solace10(...ting/multi-node-routing/cspf/neighbor)# connect-via 192.168.1.11

     

    solace11(configure)# routing
    solace11(configure/routing)# multi-node-routing
    solace11(configure/routing/multi-node-routing)# create cspf neighbor solace10
    solace11(...ting/multi-node-routing/cspf/neighbor)# connect-via 192.168.1.10

  2. Repeat the previous step for both sides of each and every CSPF neighbor link connection in the MNR network.

Configuring Neighbor Queues

CSPF neighbor queues are used to enqueue messages before they are sent over the data connection to neighbor message brokers. These TCP transmit queues are used to manage the flow of data that is transmitted from the message broker over the routing links to its neighbors.

You can perform the following tasks for these queues:

Always contact Solace for technical support before you attempt to configure the CSPF neighbor queues on message brokers. Failure to do so may result in data loss or service interruption due to unwanted secondary effects on message broker performance.

Configuring Max Neighbor Queue Depths

Each neighbor queue has an associated maximum depth that is measured in work units, whereby a work unit represents 2048 bytes of a message. When a new message is placed on the neighbor queue, its depth in work units is checked against the configured maximum depth of the queue.

If the CSPF neighbor queue depth is at or above the configured maximum depth and new messages are received, the oldest messages currently queued can be discarded to make room for the newest received messages. When this happens a dataplane statistic for Egress Congestion Discards is incremented.

To modify the maximum depth of CSPF neighbor queues, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf queue
solace(...routing/multi-node-routing/cspf/queue)# max-depth <depth>

Where:

<depth> is the integer value representing the number of work units for the neighbor queues. The valid range is 50 to 262144. The default value is 20000. Changing this value does not affect messages already successfully placed on the queue.

The no version of this command, no max-depth, resets the neighbor to the associated default.

Note  The formula to convert a message size to number of work units is: NumWorkUnits = CEILING(message.length/2048)

Configuring Minimum Message Bursts

A neighbor queue may temporarily exceed its maximum depth if it has a sufficiently sized minimum burst length tolerance. The minimum burst length tolerance ensures that a neighbor queue does not lose messages when it receives bursts of very large messages. It specifies the number of messages per queue that are always allowed entry into the queue, regardless of its current configured maximum depth.

To configure the minimum number of messages that must be on a CSPF neighbor queue before the queue’s depth is checked against the maximum depth setting (thereby allowing the queue to absorb a burst of large messages that exceeds the number of allowed work units), enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf queue
solace(...routing/multi-node-routing/cspf/queue)# min-msg-burst <depth>

Where:

<depth> is the integer value representing the queue burst depth in messages. The valid range is 0 to 262144. The default value is 4. Changing this value does not affect messages already successfully placed on the queue.

The no version of this command, no min-msg-burst, resets the queue burst depth in messages to the default of 4.

Showing CSPF Queue Settings

To view the CSPF queue settings on the message broker, enter the following command:

solace> show cspf queue

Configuring Neighbor Link Encryption

To use TLS/SSL encryption on the data connections between neighboring message brokers, the following configurations are required on both message brokers on the routing link:

Configuring Certificate Files to Present to Neighbors

To use TLS/SSL data connections to neighboring message brokers, you must configure the client certificate that neighbor links will present to the remote message broker when initiating the data connections with the neighbor. The specified file must have already been added into the /certs subdirectory through the copy Privileged EXEC command (see Copying Files).

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

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf
solace(...igure/routing/multi-node-routing/cspf)# ssl
solace(...e/routing/multi-node-routing/cspf/ssl)# client-certificate
solace(...e-routing/cspf/ssl/client-certificate)# certificate-file <filename>

Where:

<filename> is the file name of the certificate to load. The certificate must be encoded with a Privacy Enhanced Mail (PEM) format. The maximum number of CA certificates that may be loaded is 64.

The no version of this command, client-certificate, deprovisions the specified client certificate.

Configuring Certificate Validation Settings

You can configure the certificate validation settings on a message broker that can accept TLS/SSL data connections from the neighbor message broker. These settings are used for validating the client certificate that is passed from a neighbor message broker to the local message broker during a TLS/SSL handshake.

The configuration parameters that you can adjust include the following:

Enforce Trusted Common Names

You can configure a list of trusted common names that a message broker expects to be returned in a certificate from the neighbor. You may choose not to enforce this list of common names, in which case the message broker will consider any server certificate that it receives.

By default, enforce-trusted-common-name is enabled.

To enable the checking of trusted common names for MNR links, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf
solace(...igure/routing/multi-node-routing/cspf)# ssl
solace(...e/routing/multi-node-routing/cspf/ssl)# certificate-validation
solace(...uting/cspf/ssl/certificate-validation)# enforce-trusted-common-name

The no version of these commands, no enforce-trusted-common-name, disables the checking of trusted common names.

Note  If this option is enabled but a list of common names has not been configured on the neighbor level of a TLS/SSL link, enabling the given neighbor will not be permitted.

Maximum Certificate Chain Depth

The depth of a certificate chain is the number of signing CA certificates that are present in the chain back to a trusted self-signed root CA certificate. Setting a maximum certificate chain depth means that the message broker will reject any certificates whose depth is higher than the maximum limit.

To configure the maximum certificate chain depth for MNR links, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf
solace(...igure/routing/multi-node-routing/cspf)# ssl
solace(...e/routing/multi-node-routing/cspf/ssl)# certificate-validation
solace(...uting/cspf/ssl/certificate-validation)# max-certificate-chain-depth <max-depth>

Where:

<max-depth> is a number from 0 to 8 specifying the maximum number of signing CA certificates that may be present in the certificate chain. The default value is 3.

The no version of these commands, no max-certificate-chain-depth, resets this parameter to its default value.

Validate Certificate Dates

Certificates may specify “not before” and “not after” dates to provide a time range for which they will be valid. This setting will enable or disable the validation of these dates. If this check is disabled, the message broker will accept a certificate even if the valid date range provided in the certificate is not fulfilled. By default, validation of certificate dates is enabled.

To enable validation of certificate dates MNR links, enter the following commands:

solace(configure)# routing
solace(configure/routing)# multi-node-routing
solace(configure/routing/multi-node-routing)# cspf
solace(...igure/routing/multi-node-routing/cspf)# ssl
solace(...e/routing/multi-node-routing/cspf/ssl)# certificate-validation
solace(...uting/cspf/ssl/certificate-validation)# validate-certificate-date

The no version of these commands, no validate-certificate-date, disables validation of the certificate dates.

Viewing MNR Information

You can use the following show commands to view MNR information.

Showing CSPF Neighbor Link Information

To show the configuration and state of CSPF neighbor links on the message broker, enter the following command:

solace> show cspf neighbor <physical-router-name> [stats [queues | detail] | connections [wide] | detail]

Where:

<physical-router-name> is the name of the neighbor message broker. This name cannot begin with “v:”, as that indicates a virtual router.

stats asks to show basic dataplane statistics on messages for the specified neighbor.

queues asks to show dataplane statistics on queued messages for the specified neighbor.

detail asks to show detailed dataplane statistics on messages for the specified neighbor.

connections asks to show TCP connection status information between the specified neighbor.

connections wide asks to show detailed TCP connection status information between neighbors in a wide-screen computer display format (300+ character width).

detail asks to show detailed information on the configuration and state of CSPF links.

Clearing CSPF Neighbor Link Stats

To clear CSPF message statistics related to neighbor links, enter the following commands:

solace> enable
solace# clear cspf neighbor <physical-router-name> stats

Where:

<physical-router-name> is the name of the neighbor message broker. This name cannot begin with “v:”, as that indicates a virtual router.

When this command is entered, all of the CSPF message statistics are reset to 0, and CSPF statistics begin to be recorded again from this point.

Showing SMRP Subscription Info

To view SMRP subscription information on the message broker, enter the following command:

solace> show smrp subscriptions [message-vpn <vpn-name>] [destination-name <destination-name>] [remote-router] [client] [queue] [topic-endpoint] [primary] [backup] [static] [{[dto-priority <priority>] [topic <topic-str>] [persistent] [non-persistent]} | {summary}]

Where:

message-vpn asks to display only the SMRP subscriptions for the specified Message VPN, <vpn-name>. The given Message VPN name can be its full name, or part of its name with the wildcard character ? used to represent one character of the name, or the wildcard character * used to represent zero or more characters of the name. Entering only the wildcard character * for the name displays all Message VPNs.

destination-name asks to display only the SMRP subscriptions to the specified destination, <destination-name>. The given destination name can be the full name of the destination, or part of the destination name with the wildcard character ? used to represent one character of the name, or the wildcard character * used to represent zero or more characters of the name. Entering only the wildcard character * for the name displays all destinations.

remote-message broker asks to display only the SMRP subscriptions to remote message brokers.

client asks to display only the SMRP subscriptions to local clients.

queue asks to display only the SMRP subscriptions to local queues.

topic-endpoint asks to display only the SMRP subscriptions to local topic-endpoints.

primary asks to display only the SMRP subscriptions to primary local destinations.

backup asks to display only the SMRP subscriptions to backup local destinations

static asks to display only the SMRP subscriptions to static local destinations.

<priority> asks to display SMRP subscriptions for only the specified Deliver-To-One (DTO) client priority level. Valid values are P1, P2, P3, P4, or DA (for Delivery Always).

topic asks to display SMRP subscriptions for a topic subscription string, topic-str. The given topic subscription string must be in the form a/b/c.

persistent asks to display only the SMRP subscriptions tor persistent topics.

non-persistent asks to display only the SMRP subscriptions to non-persistent topics.

summary asks to show the number of SMRP subscriptions for each destination.

Note:  In addition to Solace Message Format (SMF) topic subscriptions, the show smrp subscriptions User EXEC command may also display Message Queuing Telemetry Transport (MQTT) topic subscriptions. Because this command must be able to represent both SMF and MQTT topic syntax, if a topic subscription uses characters with special meaning for the topic syntax it uses (for example, wildcards), those characters may be displayed in the output as escaped characters.

The direct messaging health check could be used with the appliance and a load-balancer to horizontally scale direct messaging.

Prevention of Subscription Propagation Race Conditions

If you're doing Request/Reply messaging with MNR, you must use the Request/Reply methods of the Solace APIs to prevent possible race conditions associated with subscription propagation.

For more information on Request/Reply messaging refer to Request Reply Messaging.

For more information on Solace APIs refer to APIs & Protocols.