Message VPN Bridges

Message VPN bridges can link two Message VPNs so that messages published to one Message VPN that match the topic subscriptions set for the bridge are also delivered to the linked Message VPN.

A Message VPN bridge allows for the delivery of Direct messages that match an explicit set of topic subscriptions from a remote Message VPN to a local Message VPN.

Guaranteed messages can also be delivered over Message VPN bridges when additional parameters are configured for the remote Message VPN.

Scenarios in which Message VPN bridges can be used include:

• Linking two Message VPNs with different names to enable Direct or Guaranteed messages published to one Message VPN to be delivered to the other Message VPN. The linked Message VPNs can be either on the same event broker or two separate event brokers.
• Linking two Message VPNs with the same names on two separate event brokers to enable Guaranteed messages published to one Message VPN to be delivered to the other Message VPN.
• Linking two Message VPNs with the same names on two separate event brokers to enable Direct messages published to one Message VPN to be delivered to the other Message VPN. This scenario operates differently than multi-node routing. There are two key differences: Message VPN bridges only transfer those Direct messages that match the bridge's topic subscriptions, and Message VPN bridges do not exchange the complete set of topic subscriptions used by the event brokers and their topology.

A bridge can be uni-directional (messages pass over the bridge in only one direction) or bi-directional (messages pass over the bridge in both directions). The messages that pass in either direction may be different, depending on the remote topic subscriptions that are assigned to the bridge for each local Message VPN.

This section discusses the basic concepts underlying the behavior, configuration and use of Message VPN Bridges. Topics discussed here include,

• How to Configure Message VPN Bridges
• Controlling Access to Messages
• Internetworking
• Establishing Message VPN Bridges
• Guaranteed Messaging Over Message VPN Bridges
• Uni-Directional Versus Bi-Directional Message VPN Bridges

If you are using Dynamic Message Routing (DMR), you can use DMR instead of a static Message VPN Bridge to deliver messages to a linked Message VPN. For more information, see DMR or a Message VPN Bridge?.

How to Configure Message VPN Bridges

If you are already familiar with the basics, you can move on to configuring Message VPN Bridges. There are two ways to do this,

• Click-to-Connect: The recommended way to configure Message VPN Bridges is with the configuration wizard, called Click-to-Connect, provided by PubSub+ Broker Manager. You'll find a discussion about how to access Broker Manager at the PubSub+ Broker Manager overview page.
• Manual Set Up: Alternatively, detailed instructions on how to manually configure Message VPN Bridges via Solace CLI can be found at Message VPN Bridge Configuration.

Controlling Access to Messages

Solace PubSub+ networks may use Message VPN bridges to control whether messages may pass from one Message VPN to another. As shown in below, when a Message VPN bridge is used to link two Message VPNs, the topic subscriptions assigned to the bridge (or the bridge queue for Guaranteed messages) determines which messages may be delivered from a remote Message VPN to the local Message VPN it is linked to.

Typical Message VPN Bridge Configurations for Controlled Access

The next figure shows a deployment where there are clients across three different Message VPNs and two event brokers not participating in multiple-node routing that all have subscriptions for the same topic–“quotes/equities/NA”.

Message VPN Bridge Example

The message is sent from Message VPN green on event broker EB-1 across Message VPN bridge B to Message VPN red to fulfill the topic subscription quotes/>. Note that Message VPN bridge B is a bi-directional bridge, so that messages published to Message VPN red could also be delivered to Message VPN green on event broker EB-2 if they match the news/> subscription set for that end of the bridge.

Internetworking

As shown in the figure below, a Message VPN bridge can also be used to link two networks together. In this use case, an entire remote network (rather than just a single remote client) can join to another network to form an extended intranet.

This configuration is useful for companies with offices and private networks located in different physical locations that need to carefully control the message flow over expensive WAN links between sites. For this scenario, each location uses multiple-node routing for fully‑distributed Message VPN connectivity for Direct messages, and Message VPN bridging is used to transfer messages for specific topics over a LAN or MAN.

Bridging Message VPNs for Internetworking

As shown in the figure below, a group of event brokers can be configured as neighbors for multiple-node routing to efficiently route traffic through a network. Edge event brokers in that group can then be linked by Message VPN bridges so that messages in the network that match select topics can be delivered to clients connected to event brokers outside of those groups of neighbors.

In this type of Message VPN bridge application:

• publishers are typically in the core network with subscribers on the edge of the network
• Message VPN bridges subscribe to a small subset of the topics in Message VPN blue in the core

Message VPN Bridges with Multi-Node Routing in the Core

Establishing Message VPN Bridges

To establish a Message VPN bridge, you must create it in a local Message VPN. An internal client is then automatically created for the bridge. This client allows a connection to be established to a remote Message VPN. A Message VPN bridge connection looks like a client connection to the remote event broker, and its login attempt to the remote event broker is authenticated in the same manner as other client connections. Through this client, control and data messages are sent between the local and remote Message VPNs.

Once a Message VPN bridge is created, the following parameters must be configured for the bridge before it can be enabled and messages can begin to be transferred:

• remote Message VPN and event broker—This is the remote Message VPN and event broker to receive messages from. The event broker is specified either by its name or “connect-via” address expressed as an IP address or DNS name. Multiple remote Message VPNs can also be specified in order of preference. These redundant remote Message VPNs provides some protection if the first remote Message VPN the bridge connects to becomes unavailable.

If you want to establish a bridge link to a remote Message VPN that is also on the local event broker, use an IP address of 127.0.0.1 and do not specify a physical interface. This configuration will establish a loopback Message VPN bridge.

• remote Message VPN authentication scheme—the authentication scheme that the bridge uses to authenticate with the remote Message VPN. An authentication scheme is required for each remote Message VPN that is configured for the bridge.
  • basic authentication client username—the username used to authenticate with the remote Message VPN, if basic authentication is configured. An optional password can also be specified.
  • client certificate authentication certificate file—the certificate file used to authenticate with the remote Message VPN, if client certificate authentication is configured. If no certificate file is specified, the bridge will present the event broker’s server certificate for authentication.

By default, remote Message VPN bridge connections are not available to clients—permission must first be configured in the client profile that is assigned to the client username. Permission to create bridge connections can be enabled through the clientsʼ assigned client profile (refer to Allowing Bridge Connections).

• remote subscription topic—If you want to transfer Direct messages over the Message VPN bridge, configure one or more topic subscriptions for the bridge that will attract Direct messages published to the remote Message VPN. Topics are added to the top level of the bridge and apply across all hosts. The set of topics may be changed while the bridge is enabled.
• remote message spool queue—If you want to transfer Guaranteed messages over the Message VPN bridge, use this parameter to specify an existing durable queue (with an exclusive access type) on the remote Message VPN to which a consumer flow will connect. Topic subscriptions must be added to the queue to attract messages published to specific topics of interest.

The following parameters can also be configured (if they are not modified, the default values will be used):

• remote deliver-to-one priority—The deliver-to-one priority given to the subscriptions that are assigned to the bridge. By default, the highest priority is used.
• remote Message VPN SSL—Sets whether to use TLS/SSL encryption for the remote Message VPN bridge link. This can be configured for each remote Message VPN that is configured for the bridge. If TLS/SSL encryption is used, the port on the event broker used by the remote Message VPN must also be a TLS/SSL port (port 55443 is the default TLS/SSL port). For information on using TLS/SSL with Message VPN bridges, refer to TLS/SSL Service.
• remote Message VPN compressed data—Sets whether to use data compression for the remote Message VPN bridge link. This can be configured for each remote Message VPN that is configured for the bridge. If data compression is used, the port on the event broker used by the remote Message VPN must also be a compression port (port 55003 is the default compression port).
• remote Message VPN connect order—Configures the order in which the bridge attempts to connect to configured redundant remote Message VPN hosts. This is configured per host (that is, for each remote Message VPN that is configured for the bridge).
• SSL parameters—Sets the cipher suites to be used for TLS/SSL encryption as well as the list of trusted common names used to verify the identity of remote server certificates. For information on using TLS/SSL encryption with Message VPN bridges, refer to TLS/SSL Service.
• remote Message VPN message spool window size—Sets the requested transport window size for the consumer Flow that is bound to the remote queue. This determines how many outstanding Guaranteed messages can be delivered from the remote queue over the Message VPN connection before an acknowledgment must be received by the remote queue. Modifying the window size can be helpful for bridges that go across high-latency links.

VPN Bridging and Fault Tolerance

For details on how to establish Message VPN bridge connections to remote event brokers when those remote event brokers have been deployed in high-availability (HA) redundant event broker pairs for fault tolerance, refer to Bridging With Appliances Using Active/Standby Redundancy.

Guaranteed Messaging Over Message VPN Bridges

To use a Message VPN bridge to transfer Guaranteed messages from a remote Message VPN to a local Message VPN, there must first be:

• a durable queue provisioned on the remote Message VPN
• a durable topic subscription added to that durable queue so that messages with a topic match can be spooled to the queue

Then, when you create the bridge on the local Message VPN, you must specify the following:

• the remote Message VPN to connect the bridge to
• the provisioned queue on that remote Message VPN

When the bridge is established, a consumer flow is bound to the queue. Then messages published to the remote Message VPN with matching topics can be transported over the bridge to the consuming event broker using the bound flow.

For clients to receive these messages, topic subscriptions must be added to the local Message VPN:

• For the Guaranteed messages received from the bridge to remain as Guaranteed messages (that is, retain their non-persistent or persistent delivery modes), a durable queue that has been assigned a matching topic subscription is required. In this case, the received messages are persisted because they are saved to the message spool.
• If the Guaranteed messages received from the bridge only match client topic subscriptions on the local Message VPN, the messages are converted to Direct messages and are not persisted.
• If there are no matching subscriptions on the local Message VPN, the event broker discards the messages.

In the example shown in the figure below, the Message VPN bridge on Router 1 is configured to establish a Guaranteed message flow to the durable queue named BlueQueue. That queue is configured through the CLI or SolAdmin on Router 2, along with a list of topics which are to be mapped to BlueQueue (in this example ibm/price/> and apple/price/>). Any messages published to these topics are written to BlueQueue, and then transported through the Guaranteed message flow over the bridge to Router 1. Upon reaching Router 1, the messages are delivered to all queues and topic endpoints with matching subscriptions.

Message VPN Bridge Configuration for Guaranteed Messaging

If multiple consumer flows are going to be established to a remote Message VPN, then a separate durable message queue should be created in the Message VPN for each of the inbound bridges that want to receive Guaranteed messages.

Avoiding Loss of Guaranteed Messages with VPN Bridges

When properly configured, Guaranteed messages will not be lost when sent over a Message VPN bridge. The normal operational behavior is as follows:

• Guaranteed messages do not unspool from the remote Message VPN of a Message VPN bridge unless they can be spooled by all matching endpoints on the local Message VPN. When a Guaranteed message cannot be successfully spooled to all endpoints with matching subscriptions on the local Message VPN, the event broker periodically retransmits the message across the Message VPN bridge. Once the Guaranteed message is successfully spooled to all matching endpoints on the local Message VPN, then it is unspooled from the remote Message VPN.
• If a Guaranteed message is rejected by the local Message VPN when it is retransmitted across the bridge, no other Guaranteed messages can traverse the bridge. This can cause the bridge queue on the remote Message VPN to fill up. If the bridge queue reaches its quota, it will reject Guaranteed messages just published to the remote Message VPN. Direct messages, however, including those that are promoted on the local Message VPN, continue to traverse the bridge while in this state.
• Once the condition that prevents the Guaranteed messages to be spooled by the endpoints on the local Message VPN is cleared, Guaranteed messages begin to traverse the Message VPN bridge again. Once the bridge queue has dropped below quota, it starts accepting newly published Guaranteed messages again.

The correct configuration for this behavior requires the reject‑msg‑to‑sender‑on‑discard option to be enabled on the durable endpoints and for a matching durable subscription to be configured on the local Message VPN. By default, the reject-msg-to-sender-on-discard option is enabled on queues but is disabled on topic endpoints.

Although the reject-msg-to-sender-on-discard option only needs to be enabled on one matching endpoint in the local Message VPN to get the desired behavior, it is recommended that it be enabled on all endpoints in the local Message VPN. For more information on this feature, refer to Message VPN-Level Guaranteed Messaging Configuration.

The local Message VPN must also have a matching durable subscription for the Guaranteed message. If there are no endpoints with matching subscriptions, then the message is discarded as “No Eligible Destination” on the local Message VPN and the message is unspooled from the bridge queue on the remote Message VPN. This prevents the bridge consumer flow from being blocked by messages that have no destination on the local Message VPN.

If the Guaranteed messages received from the bridge match client topic subscriptions on the local Message VPN, the messages are converted to Direct messages and are not persisted.

Uni-Directional Versus Bi-Directional Message VPN Bridges

Subscriptions must be statically configured on a Message VPN bridge to attract Direct messages from a remote Message VPN. The figure below shows a uni‑directional bridge that has been configured on Router 1 so that messages from that remote Message VPN with matching topics can be transferred over the bridge from Router 2 to Router 1 using a single TCP connection.

Uni-Directional Message VPN Bridge

It is possible to extend the configuration shown above to create a bi-directional bridge between the two Message VPNs. A bi-directional bridge essentially creates a bridge link in the opposite direction of an existing uni-directional bridge; where the local Message VPN of the uni-directional bridge is the remote Message VPN that the new bridge links to, and the remote Message VPN that the uni-directional bridge links to is the local Message VPN of the new bridge link.

As shown in the figure below, by adding a bridge configuration on Router 2 from Message VPN yellow to Message VPN blue on Router 1, a bi-directional bridge is established, and a single TCP connection is used to transport all messages between the two Message VPNs.

The No Local Delivery property is automatically enabled for Message VPN bridges to prevent forwarding loops. This means that messages transferred across a Message VPN bridge to a remote Message VPN cannot then be sent back to the local Message VPN they originally came from to fulfill matching topic subscriptions again.

Bi-Directional Message VPN Bridge

Establishing Bi-Directional Bridge Links

Two uni-directional bridges cannot be established between the same two Message VPNs—a bi-directional bridge must be used. Therefore, before a local event broker attempts to establish a bridge to a remote event broker, it inspects the existing incoming bridges to see if there is a compatible bridge already established from the remote event broker that can be used. To be compatible, an existing bridge from the remote event broker must pass the following tests:

• the remote event broker name from the peer event broker must match the local event broker name
• the event broker name of the peer must match the specified remote event broker name
• the remote Message VPN of the peer must match the local Message VPN
• the Message VPN of the peer must match the specified remote Message VPN
• if TLS/SSL encryption is to be used, then TLS/SSL must be configured on both bridges (that is, an TLS/SSL bridge is not compatible with a non-TLS/SSL bridge)

If there is a compatible incoming bridge, then no new Message VPN bridge connection is required and an existing uni‑directional Message VPN bridge is transformed into a bi-directional Message VPN bridge. The login is performed with the existing connection.