Bridging to Remote Appliances That Use Redundancy

This section describes how to establish Message VPN bridge connections to remote appliances, when the remote appliances have been deployed in a redundant configuration to provide fault tolerance. There are three different redundancy models available:

Note:  To keep the examples simple, not all configuration commands required to create a bridge are shown in this section—only those commands that are unique to the redundancy models being discussed are shown.

Bridging With Appliances Using Active/Standby Redundancy

The figure below shows a pair of Solace appliances (solace2 and solace3) that have been configured to operate in an active/standby configuration. Message VPN Green on solace1 is configured with a VPN bridge connection to Message VPN Yellow on solace2, so that Message VPN Green can receive messages from VPN Yellow.

If solace2 goes offline for any reason, solace3 takes over for the primary IP addresses of solace2, and provides service for all of the Message VPNs on solace2.

VPN Bridging with Active/Standby Redundancy

No special configuration is needed on solace1 to make use of this redundancy model. Appliance solace1 is simply configured with a bridge connection from Message VPN Green (primary), to Message VPN Yellow on solace2, connecting through the primary address of solace2 (or the Domain Name System [DNS] name corresponding to that primary address):

solace1(configure)# create bridge To-Yellow message-vpn Green primary

solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2

To have Message VPN Yellow on solace2 connect to Message VPN Green on solace1, solace2 needs to be configured with a bridge connection from Message VPN Yellow (primary) to Message VPN Green on solace1 connecting through the primary address of solace1 (or the DNS name corresponding to that primary address).

Note:  When Config-Sync is enabled for both appliances in the redundant pair, the configuration parameters between them are automatically synchronized. Therefore, a bridge connection from Message VPN Yellow (backup) on solace3 to Message VPN Green on solace1 is also created.

Bridging With n+1 Redundancy Using Alternate Remote Connections

The figure below shows a set of appliances (solace2, solace3, and solace4) deployed in an n+1 redundancy configuration. Appliance solace4 acts as a backup router for the Message VPNs configured on appliances solace2 and solace3. In this configuration, clients connecting to solace2 use the hostlist feature in the Solace APIs to connect to solace4, if solace2 is unreachable. Similarly, clients connecting to solace3 use the host list feature to connect to solace4, if solace3 is unreachable.

Message VPN Green on solace1 is configured with a bridge connection to Message VPN Yellow on solace2 so that it can receive messages from Message VPN Yellow.

In this case, the Message VPN bridge on appliance solace1 must be configured with multiple “remote” parameters, to identify the fallback connection for the bridge if the primary connection cannot be established:

solace1(configure)# create bridge To-Yellow message-vpn Green primary

solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2

solace1(configure/bridge/remote)# connect-order 1

solace1(configure/bridge/remote)# exit

solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace4

 

solace2(configure/bridge/remote)# connect-order 2

Bridging with n+1 Redundancy Using Alternate Remote Connections

To guard against situations whereby a temporary loss of connectivity to solace2 causes the bridge connection to be inadvertently established to solace4, it is recommended that the remote retry count and remote retry delay Bridge VPN CONFIG command parameters for the bridge be set to a sufficiently high value to debounce any transient network outages that may occur.

Alternatively, many network operators choose to administratively disable through the shutdown command the Message VPNs on the backup appliance, and only enable through the no shutdown command a particular backup instance of a VPN when the primary appliance for that VPN has gone offline. However, such a policy increases failover times substantially, since manual intervention is required to bring the backup VPN instances online.

In cases where VPN Yellow on solace2 wishes to connect to Message VPN Green on solace1, appliances solace2 and solace4 need to be configured with a bridge connection to Message VPN Green on solace1:

Note:  Since active/standby redundancy is not being used in this case, the bridge connection is a primary connection on both the solace2 and solace4 appliances.

solace2(configure)# create bridge To-Green message-vpn Yellow primary

solace2(configure/bridge)# create remote message-vpn Green connect-via solace1

 

solace4(configure)# create bridge To-Green message-vpn Yellow primary

solace4(configure/bridge)# create remote message-vpn Green connect-via solace1

For such a configuration, it is strongly recommended that the Message VPNs on the backup appliance be administratively disabled through the shutdown command under normal operating conditions, and only enabled for activation when the primary appliance has failed. Otherwise, the Message VPN bridges on the backup appliance always attract traffic from the appliances to which they are connected, even when the Message VPNs are on standby, and do not have active subscribers connected to them.

Bridging With n+1 Redundancy Using DNS Redirection

The n+1 redundancy model when using DNS redirection is virtually identical to the redundancy model that makes use of alternate remote connections, as shown in the figure above. However, when using DNS redirection, the same appliance DNS name is used at all times, so there is no need to configure an alternate connection. The configuration on appliance solace1 becomes the following:

solace1(configure)# create bridge To-Yellow message-vpn Green primary

solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2

solace1(configure/bridge/remote)# exit

The disadvantage of this redundancy approach is that in a failover scenario, the network operator must reconfigure DNS, such that requests for the address of solace2 return the IP address of solace4.

Note:  All the recommendations around shutdown of the Message VPNs on the backup appliance discussed in Bridging With n+1 Redundancy Using Alternate Remote Connections apply also to redundancy using DNS redirection.