You can use the active/active redundancy facility of the TIBCO Messaging Appliance P-7500 system to eliminate the potential for a single point of failure in a message routing network. Please start by reading and following the
Prerequisites, and then following the
“Steps to Configure Redundancy” on page 160.
2.
|
The underlying signaling for TIBCO Messaging Appliance P-7500 redundancy is based on RFC 3768. Observe all precautions in RFC 3768 regarding VRRP Virtual Router Identifier (VRID) and uniqueness of protected addresses when configuring system redundancy. In particular, the vrrp-vrid must not conflict with a RFC 3768 VRRP VRID that is active on the same Local Area Network (LAN) segment.
|
However, when P-7500 systems are used in a redundant pair, the total maximum load for the pair should be the same as that of a single P-7500 system operating in a non-redundant mode. As a result, the individual load allocated to each P-7500 system in a redundant pair should be much less than its potential, individual maximum load.
By limiting the maximum total load for a redundant pair to the same as that of a standalone system ensures that in a failover situation the active system has sufficient operating capacity to also handle the connections typically served by its mate.
To configure an active/active redundancy pairing for two systems use the following procedure. The exact steps required may vary depending on your network conditions and preferred configuration.
The physical interfaces (or ports) on the NAB used by a P-7500 system can be configured as a single LAG, as independent ethernet ports with their own IP addresses, or as a combination of both (that is, some of the ports can be grouped into a LAG and the remainder addressed independently).
For more information on the configuration of physical interfaces on the NAB or the Command Line Interface (CLI) commands used in the following procedure, refer to Chapter 16, "Configuring IP Interfaces and Addresses".

tibco(config-rv)# shutdown
tibco(config)# create interface <phy-interface
>
tibco(config-interface)# no shutdown
where <ip-interface> is an ASCII string specifying the ethernet interface port. Valid values are <fabric>/<slot>/<port> (for example, 1/1/8). There is no default value.
3.
|
Repeat step 2 for each IP interface you want to configure. A maximum of eight independent physical interfaces are possible.
|
tibco(config)# create interface 1/1/lag1
tibco(config-interface)# no shutdown
tibco(config-interface)# member <fabric>/<slot>/<port>
tibco(config-interface)# no shutdown
tibco(config-interface)# exit
tibco(config)# ip vrf msg-backbone
tibco(config-ip-vrf)# create interface <ip-interface> primary
tibco(config-ip-vrf-interface)# ip-address <ip-addr>
where <ip-interface> is an ASCII string specifying the ethernet interface port or LAG.
where <ip-addr> is an IP address and network mask in Classless Inter-Domain Routing (CIDR) form: n.n.n.n/y (n is 0-255, y is 0-32).
tibco(config-ip-vrf-interface)# no shutdown
tibco(config-ip-vrf-interface)# exit
tibco(config)# ip vrf msg-backbone
tibco(config-ip-vrf)# create interface <ip-interface> backup
tibco(config-ip-vrf-interface)# ip-address <ip-addr>
tibco(config-ip-vrf-interface)# no shutdown
tibco(config-ip-vrf-interface)# exit
tibco(config-ip-vrf)# route default <ip-addr>
where <ip-addr> is an IP address in CIDR form: n.n.n.n (n is 0-255).
tibco(config-ip-vrf)# exit
tibco(config)# virtual-router primary
tibco(config-virtual-router)# rv-interface <ip-interface>
where <ip-interface> is an ASCII string specifying an ethernet interface port or LAG on the NAB.
tibco(config-virtual-router)# vrrp-interface <ip-interface>
tibco(config-virtual-router)# vrrp-vrid <vrid>
where <ip-interface> is an ASCII string specifying an ethernet interface port or LAG on the NAB.
where <vrid> is a value between 1 and 255 (this value must differ from the VRRP VRIDs being used by anything else on the local subnet; there is no default value).
tibco(config-virtual-router)# exit
tibco(config)# virtual-router backup
tibco(config-virtual-router)# rv-interface <ip-interface>
tibco(config-virtual-router)# vrrp-interface <ip-interface-id>
tibco(config-virtual-router)# vrrp-vrid <vrid>
where <ip-interface> is an ASCII string specifying an ethernet interface port or LAG on the NAB.
where <vrid> is a value between 1 and 255 (this value must be different from the VRRP VRIDs being used by anything else on the local subnet; there is no default value).
tibco(config-virtual-router)# exit
tibco(config)# ip vrf management
tibco(config-ip-vrf)# interface eth2:1
tibco(config-ip-vrf-interface)# ip-address <ip-addr>
tibco(config-ip-vrf-interface)# exit
tibco(config-ip-vrf)# interface eth2:2
tibco(config-ip-vrf-interface)# ip-address <ip-addr>
tibco(config-ip-vrf-interface)# exit
tibco(config-ip-vrf)# exit
where <ip-addr> is an IP address in CIDR form: n.n.n.n (n is 0-255).
tibco(config)# router redundancy
tibco(config-router-redundancy)# no shutdown
tibco(config-router-redundancy)# exit
tibco(config-router)# exit
tibco(config-rv)# no shutdown
|
When you configure the primary and backup IP interfaces on the mate system, you must use the same IP addresses assigned to the first system, but in a reverse fashion, to ensure that redundancy protection is enabled. For example, if the system P-7500 1 uses 192.168.161.110/19 for its primary IP interface and 192.168.171.133/19 for its backup IP interface, P-7500 2 must use 192.168.171.133/19 for its primary IP interface and 192.168.161.110/19 for its backup IP interface.
|
|
If you are running Rendezvous Gateway services, the primary and backup RVGDs used on each P-7500 system must use the same configuration, but in a reverse fashion, to ensure that redundancy protection is enabled. For example, the configuration of the primary RVGD used on system P-7500 1 should match the configuration of the backup RVGD used on the mate system P-7500 2, and the configuration of the backup RVGD used on P-7500 1 should match the configuration of the primary RVGD used on P-7500 2. For more information on configuring RV Gateway services, refer to Chapter 3, "Managing TIBCO Rendezvous Tasks".
|
To make changes to the redundancy configuration of a P-7500 system, you must stop redundancy on that system. In addition to stopping and starting a P-7500 system, you can restore the default redundancy configuration of a P-7500 system.
Both the redundancy facility and Rendezvous services must be turned off before any commands other than the
release-activity Router Redundancy CONFIG command are run. The redundancy facility is turned off by default.
The no shutdown Router Redundancy CONFIG command starts the redundancy facility on the P-7500 system. You can use this command to restart redundancy after changing any redundancy settings for the system.
The shutdown Router Redundancy CONFIG command stops the redundancy facility on the P-7500 system. You can use this command to stop the redundancy facility, which is required to make changes to the system’s redundancy settings.
The no redundancy Router Redundancy CONFIG command removes all of the currently configured redundancy configuration settings for a P-7500 system and restores the default redundancy settings:
The auto-revert Router Redundancy CONFIG command enables the backup P-7500 system to automatically revert activity back to the primary system (provided the mate system is available, otherwise an error message is received):
The no version (no auto-revert) disables the backup system from automatically giving up activity, even when the mate system is ready to provide service to the messaging clients.
When auto revert is disabled (system default), the backup system does not automatically give up activity, even if the mate router is ready to provide service to the messaging clients. When disabled, activity only reverts back to the primary system if any one of the following occurs:
•
|
the redundancy revert-activity Admin EXEC command is run on the backup system
|
•
|
the release-activity Router Redundancy CONFIG command is run on the backup system
|
The redundancy revert-activity Admin EXEC command administratively forces a P-7500 system acting as backup in a redundant system pair to give up service (provided the mate system is available, otherwise an error message is received):