Multi-Node Routing
Multi-Node Routing (MNR) allows multiple Solace PubSub+ event brokers to be networked together so that Direct messages published from clients connected to one event broker can be delivered to clients connected to other event brokers. This effectively distributes message routing loads across multiple event brokers in a network resulting in aggregate message forwarding rates across the network that exceed the capacity of any one event broker.
Solace's Content Shortest Path First (CSPF) protocol is used to link neighboring event brokers and allow them to discover the complete messaging network topology to which they belong. Event brokers can then determine which neighbor is the optimal node for forwarding messages addressed to specific destination event brokers. Topology discovery is continuous and dynamically updated as event brokers within the network go on or off line.
The Subscription Management Routing Protocol (SMRP) is also used to enable linked neighboring event brokers to propagate topic subscriptions added by the clients of one event broker throughout the messaging network. This allows messages that are published to one event broker to be routed to other event 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 event brokers, Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) encryption can be applied to the MNR links' data channels.
Linking Event Brokers
A routing link defines the route for connectivity between event brokers. When building a messaging network, administrators must explicitly configure the routing links between event broker neighbors. Both ends of a message routing link must be configured. That is, to link event 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 be optionally used on neighbor event broker data connections (only data connections are affected).
Multiple bi-directional routing links can be used to route messages between event 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 event 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 event broker A to C travel from event broker A to event broker B and then on to event broker C.
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 event broker A to C travel from event broker A to Site B, on to event broker D, and then to event broker C. Such a cost configuration may be desirable in cases where, for example, two event broker sites in one city are connected by a high-speed link, while other overseas event broker sites are connected by low-speed links.
Subscription Propagation and Management
When MNR is used, topic subscriptions and matching messages are only distributed between matching Message VPNs. This means that an event broker with a topic subscription in one message VPN can only receive matching messages from a neighbor event 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 event 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 event brokers in the network. The default policy is not to export subscriptions.
To receive messages from other event 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 event brokers in the network.
For information on how to configure the subscription export policy, see Enabling Subscription Export.
Configuration Prerequisites
Before configuring the MNR settings for each event broker used throughout the network, you'll need to read and observe all of the following:
- MNR uses the static IP addresses of all event brokers in the message routing network. Before you can configure MNR on an event broker, you must know the static IP address of each neighbor you want the event broker to connect to.
- The event broker with the name that comes first in alphabetical order initiates the TCP connections.
- You must ensure that the following TCP ports are opened on each event broker used in the message-routing network:
- The routing control port. The default is 55556.
- 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.
- The event brokers must have unique physical router names.
MNR Mode Configuration
In PubSub+ software event 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 event broker restart.
You must restart the event broker before changes take effect. If you do not specify the defer keyword, you are immediately prompted to restart the event broker.
Creating Neighbor Links
A CSPF routing link goes from one event broker to a neighboring event broker, as identified by its physical router name.
To successfully link neighboring event brokers, both ends of a message routing link must be configured. That is, between two Solace event 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 event broker to a neighbor event 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 event broker to a neighbor event 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 event 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 an event broker name. Router names must be unique among all configured event brokers.
The no version of this command, no cspf neighbor, deletes the CSPF link on the given event 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
- Configuring Neighbors' Control Ports
- Configuring Compressed Data Connections
- Enabling TLS/SSL Data Encryption
- Configuring Link Costs
- Configuring TCP Settings
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 event broker in the form IP address[:port] or FQDN[:port]. IPv4 addresses must be specified in the dotted decimal notation form, nnn.nnn.nnn.nnn. In SolOS version 9.12.0 and later, IPv6 formatted strings (RFC 5952) are supported, however, these addresses must be enclosed in square brackets. The port is specified as a decimal value from 0 to 65535. For example, a correctly formatted IPv4 address is: 192.168.100.1:55555. The same address in IPv6 fromat is [::ffff:c0a8:6401]:55555. If the port is unspecified, the default is 55555. The FQDN can contain up to 253 characters.
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 event broker. If left unspecified, the control port used is the one returned by the neighbor event 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 event broker.
Configuring Compressed Data Connections
You can use compression on the data connections to the neighbor event broker. Only data connections are affected—control connections are always uncompressed.
Compression is only available on plain-text connections to the neighbor event 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.
This attribute can only be changed when the neighbor event broker is shutdown.
Enabling TLS/SSL Data Encryption
You can use TLS/ SSL encryption on the data connections to the neighbor event 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.
- This attribute can only be changed when the neighbor event 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 event 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 event 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 event 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 event broker is initiating or accepting the neighbor connection, this list should contain both the server-certificate CN and client-certificate CN of the neighbor event 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.
The trusted common names list can be left empty if the Multi-Node Routing 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 event 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 event 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.
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 event broker-to-event broker connections, as well as client‑to‑event 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.
In versions prior to 9.5.0, a routing interface must also be assigned if the event 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 event 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 event broker, enter the following commands:
solace(configure)# routing solace(configure/routing)# shutdown
- By default, Solace routing protocols are stopped (that is, they are not running on event brokers).
- To start MNR, you must start each event broker being networked together.
- Whenever an event 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 event brokers. However, if Solace routing protocols are stopped on any neighbor event broker, the event 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 event brokers, with CPSF neighbor link connections provisioned between neighboring event brokers in accordance with the defined network topology.
Determining which pairs of event brokers have neighbor link connections determines the topology of a network. In this example we only describe the tasks required to configure event 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 event broker configuration tasks described in IP Interface Configuration for Appliances have been completed.
To successfully provision an MNR network, two separate levels of configuration are required, in this order:
Event Broker-Wide Configuration Tasks
Perform these tasks on each and every event 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:
- To enable event brokers to connect to the routing interface of their neighbors, configure a static IP interface on each event 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.
Create the static IP interface:
solace> enable solace# configure solace(configure)# ip vrf msg-backbone solace(configure/ip/vrf)# create interface 1/6/1:3 static
Set the static IP interface address:
solace(configure/ip/vrf/interface)# ip-address 192.168.1.10/24
Enable the static IP interface:
solace(configure/ip/vrf/interface)# no shutdown solace(configure/ip/vrfinterface)# exit
Configure the IP route for the Message Backbone VRF:
solace(configure/ip/vrf)# route default 192.168.1.1 solace(configure/ip/vrf)# end solace#
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 IP Interface Configuration for Appliances.
- Verify IP connectivity between the static IP addresses of neighboring event brokers.
In the following example, the static IP interface address of the neighbor event 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
- On each event broker, configure a routing interface and enable the Solace routing protocols.
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 event broker-wide configuration tasks, do the following:
- Configure the CSPF neighbor link connections between neighbor event brokers.
For example, assuming the neighboring event brokers are named
solace10andsolace11, 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
- 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 event brokers. These TCP transmit queues are used to manage the flow of data that is transmitted from the event 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 event brokers. Failure to do so may result in data loss or service interruption due to unwanted secondary effects on event 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.
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 255. 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 255.
Showing CSPF Queue Settings
To view the CSPF queue settings on the event broker, enter the following command:
solace> show cspf queue
Configuring Neighbor Link Encryption
To use TLS/SSL encryption on the data connections between neighboring event brokers, the following configurations are required on both event brokers on the routing link:
- TLS/SSL service must be configured and enabled for the event broker, which requires the TLS/SSL server certificate to be configured on the local event broker. See Managing Server Certificates.
- The client certificate file that identifies the local event broker must be loaded on the event broker. See Configuring Certificate Files to Present to Neighbors.
- Ensure that your certificate validation settings are set appropriately based on your network environment. Note that by default, the
enforce-trusted-common-namesetting is enabled. See Configuring Certificate Validation Settings. - TLS/SSL encryption must be enabled and configured for the neighbor link. See Enabling TLS/SSL Data Encryption.
Configuring Certificate Files to Present to Neighbors
To use TLS/SSL data connections to neighboring event brokers, you must configure the client certificate that neighbor links will present to the remote event broker when initiating the data connections with the neighbor. The specified file must have already been added into the /usr/sw/jail/certs directory 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. Once a certificate is configured, a copy of it is saved internally. The file in the certs directory is no longer required.
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 an event broker that can accept TLS/SSL data connections from the neighbor event broker. These settings are used for validating the client certificate that is passed from a neighbor event broker to the local event broker during a TLS/SSL handshake.
The configuration parameters that you can adjust include the following:
Validate Server Name
You can enable or disable the TLS authentication mechanism to verify the name used to connect to the neighbor. 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 neighbor.
This parameter is disabled for existing VPNs on brokers that have been upgraded from versions prior to 9.9; otherwise it is enabled by default.
To enable validation of server 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)# validate-server-name
The no version of this command, no validate-server-name, disables validation of the server names.
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 event 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 event 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 event 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 event 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 event 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 event 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-router asks to display only the SMRP subscriptions to remote event 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.
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. More specifically, you must use the built-in Request/Reply topic (an internal P2P topic by default). If you set the ReplyTo to a custom value, there will be subscription delays and the possibility of a subscription propagation race condition.
For more information on Request/Reply messaging refer to Request Reply Messaging.
For more information on Solace APIs refer to PubSub+ Messaging APIs.