Managing Multi-Node Routing

This section discusses the tasks associated with configuring routing links between neighbor Solace routers (that is, nodes) so that topic subscriptions and Direct messages that clients add to one router can be delivered to clients connected to other routers throughout the network.

To enable multi-node routing, the Solace Messaging Platform uses the Solace Content Shortest Path First (CSPF) protocol to enable the creation of routing links between neighbor routers to distribute and update the message‑routing network topology. It also relies on the Subscription Management Routing Protocol (SMRP) to enable topic subscriptions added by clients on one router to be propagated throughout the linked message‑routing network.

Creating Neighbor Links From Appliances

NOTICE: The Solace CLI configuration commands to create a CSPF multi-node routing link from a Solace appliance using SolOS version 8.1 onwards differ somewhat from the commands that are required for appliances using earlier SolOS versions and from Solace VMRs. This section only provides instructions for SolOS version 8.1 onwards. For instructions on how to create a CSPF multi-node routing link from a VMR, see Creating Neighbor Links From VMRs.

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

Note:  To successfully link neighboring routers, both ends of a message routing link must be configured. That is, between two Solace routers 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 Solace router to a neighbor router, enter the following CONFIG commands:

    solace(configure)# routing

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

  • To edit the properties of an existing CSPF routing link from the given Solace router to a neighbor router, enter the following CONFIG commands:

    solace(configure)# routing

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

Where:

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

Note:  The no version of this command (no cspf neighbor) deletes the CSPF link on the given router, 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. After entering the cspf neighbor CONFIG command, the CLI command moves to a configuration level that allows you to configure those parameters. These configuration tasks 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 CONFIG commands:

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# connect-via <connect-via>

Where:

<connect-via> is the static IP address and TCP port of the neighbor router in the form “IP address[:port]”, with the IP address specified in the dotted decimal notation form nnn.nnn.nnn.nnn, and the port specified as a decimal value from 0 to 65535 (for example, 192.168.100.1:55555). If port is unspecified, the default is 55555 for non-compressed plain-text data, 55003 for compressed data, and 55443 for TLS/SSL encrypted data.

Configuring Neighborsʼ Control Ports

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

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# <control-port>

Where:

<control-port> is the TCP control port number of the neighbor router. If left unspecified, the control port used is the one returned by the neighbor router 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 router.

Configuring Compressed Data Connections

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

Compression is only available on plain-text connections to the neighbor router (the default). Message compression is not available on Transport Layer Security (TLS)/ Secure Sockets Layer (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 CONFIG commands:

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# compressed-data

Note:   

  • This attribute can only be changed when the neighbor router is shutdown.
  • The no version of this command (no compressed-data) resets data connections to the default of uncompressed connections.

Enabling TLS/SSL Data Encryption

You can use Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) encryption on the data connections to the neighbor router. 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 CONFIG commands:

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# ssl-data

Note:   

  • This attribute can only be changed when the neighbor router 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 Solace appliances. It is not currently supported for VMRs.
  • The no version of this command (no ssl-data) resets data connections to the default of plain-text connections.

Configuring Cipher Suites

A list of cipher suites, in order of preference, can be specified to negotiate with the remote router. 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 Solace routers, see Supported Cipher Suites.

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

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# ssl

solace(configure/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. The command must be used with this parameter before any suites can be added to the list with the name parameter.

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.

Note:  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 router is initiating or accepting the neighbor connection, this list should contain both the server-certificate CN and client-certificate CN of the neighbor router.

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

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# ssl

solace(configure/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.

Note:   

  • 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 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 Routing Link Cost Examples.

To change the cost for a routing link to a neighbor router, enter the following CONFIG commands:

solace(configure)# routing

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

solace(configure/routing/cspf/neighbor)# link-cost <cost>

Where:

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

Note:   

  • 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 Configuring TCP Settings. This section discusses configuring the TCP settings used for router-to-router connections, as well as client‑to‑router connections.

Creating Neighbor Links From VMRs

NOTICE: The Solace CLI configuration commands to create a CSPF multi-node routing link from a Solace appliance using SolOS version 8.1 onwards differ somewhat from the commands that are required for appliances using earlier SolOS versions and from Solace VMRs. This section provides instructions for Solace VMRs. For instructions on how to create a CSPF multi-node routing link from a Solace appliance using SolOS version 8.1 onwards, see Creating Neighbor Links From Appliances.

 

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

  • To create a CSPF routing link from the given VMR to a neighbor router, enter the following CONFIG command:

    solace(configure)# routing

    solace(configure/routing)# create cspf neighbor <physical-router-name> connect-via <connect-via> [control-port <control-port>] [compressed-data]

  • To edit the properties of an existing CSPF routing link from the given VMR to a neighbor router, enter the following Routing CONFIG command:

    solace(configure)# routing

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

Where:

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

<connect-via> is the static IP address and TCP port of the neighbor router in the form “IP address[:port]”, with the IP address specified in the dotted decimal notation form nnn.nnn.nnn.nnn, and the port specified as a decimal value from 0 to 65535 (for example, 192.168.100.1:55555). If port is unspecified, the default is 55555 for non-compressed data, and 55003 for compressed data.

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

compressed-data specifies use compression across the neighbor router data connections. Only data connections are affected.

Entering the cspf neighbor Routing CONFIG command moves the CLI to a configuration mode for the CSPF link to the specified neighbor router. From here you can configure the cost for a routing link to the specified neighbor router.

Note:   

  • The no version of this command (no cspf neighbor) deletes a CSPF protocol link on the given router to a neighbor router.
  • Both ends of a message routing link must be configured. That is, between two Solace routers A and B, there must be a neighbor configuration in A for B, and a neighbor configuration in B for A.

Configuring Link Costs

If there are multiple routes between neighbor routes, and you want to enforce one route over another route using link costs, 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 Neighbor Link Configuration Example.

To change the cost for a routing link from the given VMR to a neighbor router, enter the following CONFIG command:

solace(configure/routing/cspf/neighbor)# link-cost <cost>

Where:

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

Note:   

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

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 multi-node routing. A routing interface must also be assigned if the router is to be used in a high‑availability (HA) redundant pair or if Config-Sync is to be enabled.

To assign a routing interface, enter the following CONFIG 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 Solace router (such as the CSPF protocol and SMRP used for the Multi-Node Routing feature), enter the following CONFIG command:

    solace(configure)# routing

    solace(configure/routing)# no shutdown

  • To stop Solace routing protocols from running on the router, enter the following CONFIG command:

    solace(configure)# routing

    solace(configure/routing)# shutdown

Note:   

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

Neighbor Link Configuration Example

NOTICE: Determining which pairs of Solace routers have neighbor link connections determines the topology of a network. However, network topology is a network engineering task, which is the responsibility of the customer. This example only describes the tasks required to configure Solace routers for a multi-node routing link configuration once all the network engineering is done. If required, contact Solace for assistance with network engineering.

A multi-node routing network consists of two or more Solace routers, with CPSF neighbor link connections provisioned between neighboring routers in accordance with the defined network topology.

To successfully provision a multi-node routing network, two separate levels of configuration are required, in this order:

  1. Router-Wide Configuration Tasks
  2. Per-Neighbor Link Configuration Tasks

Note:  This section applies to Solace appliances and assumes that the basic router configuration tasks described in Managing Appliance Interfaces have been completed.

Router-Wide Configuration Tasks

Perform these tasks on each and every router 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 multi-node routing:

  1. To enable routers to connect to the routing interface of their neighbors, configure a static IP interface on each router in the multi-node routing 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 Managing Appliance Interfaces.

  2. Verify IP connectivity between the static IP addresses of neighboring routers.

    In the following example, the static IP interface address of the neighbor router 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 router 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 router-wide configuration tasks, do the following:

  1. Configure the CSPF neighbor link connections between neighbor routers.

    For example, assuming the neighboring routers 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)# create cspf neighbor solace11

    solace10(configure/routing/cspf/neighbor)# connect-via 192.168.1.11

     

    solace11(configure)# routing

    solace11(configure/routing)# create cspf neighbor solace10

    solace11(configure/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 multi-node routing network.

Configuring Neighbor Queues

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

You can perform the following tasks for these queues:

ALERT! Always contact Solace for technical support before you attempt to configure the CSPF neighbor queues on Solace routers. Failure to do so may result in data loss or service interruption due to unwanted secondary effects on router 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 CONFIG commands:

solace(configure)# routing

solace(configure/routing)# cspf queue

solace(configure/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.

Note:   

  • The formula to convert a message size to number of work units is: NumWorkUnits = CEILING(message.length/2048)
  • The no version of this command (no max-depth) resets the neighbor to the associated default.

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 CONFIG command:

solace(configure)# routing

solace(configure/routing)# cspf queue

solace(configure/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.

Note:  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 router, enter the following User EXEC command:

solace> show cspf queue

Configuring Neighbor Link Encryption

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

Configuring Certificate Files to Present to Neighbors

To use TLS/SSL data connections to neighboring appliances, you must configure the client certificate that neighbor links will present to the remote appliance 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 CONFIG commands:

solace(configure)# routing

solace(configure/routing)# cspf

solace(configure/routing/cspf)# ssl

solace(configure/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 trusted root certificates that may be loaded is 64 for appliances.

Note:  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 appliance that can accept TLS/SSL data connections from the neighbor appliance. These settings are used for validating the client certificate that is passed from a neighbor appliance to the local appliance 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 router 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 router 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 multi-node routing links, enter the following CONFIG commands:

solace(configure)# routing

solace(configure/routing)# cspf ssl

solace(configure/routing/cspf)# ssl

solace(configure/routing/cspf/ssl)#certificate-validation

solace(...uting/cspf/ssl/certificate-validation)# enforce-trusted-common-name

Note:   

  • The no version of these commands (no enforce-trusted-common-name) disables the checking of trusted common names.
  • 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 router will reject any certificates whose depth is higher than the maximum limit.

To configure the maximum certificate chain depth for multi-node routing links, enter the following CONFIG commands:

solace(configure)# routing

solace(configure/routing)# cspf ssl

solace(configure/routing/cspf)# ssl

solace(configure/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.

Note:  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 router 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 for multi-node routing links, enter the following CONFIG commands:

solace(configure)# routing

solace(configure/routing)# cspf ssl

solace(configure/routing/cspf)# ssl

solace(configure/routing/cspf/ssl)#certificate-validation

solace(...uting/cspf/ssl/certificate-validation)# validate-certificate-date

Note:  The no version of these commands (no validate-certificate-date) disables validation of the certificate dates.

Viewing Multi-Node Routing Information

You can use the following show commands to view multi-node routing information.

Showing CSPF Neighbor Link Information

To show the configuration and state of CSPF neighbor links on the Solace router, enter the following User EXEC command:

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

Where:

<physical-router-name> is the name of the physical neighbor router. 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 physical neighbor router. 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 Information

To view SMRP subscription information on the Solace router, enter the following User EXEC 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 routers.

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.