Applies To:

Show Versions Show Versions

Manual Chapter: Additional Considerations for Redundant
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Configuring network failover for non-VIPRION systems that use multicast addresses
When you configure network failover for a BIG-IP® redundant system configuration, you configure each unit to use the network to determine the status of the active unit. The IP addresses that the two units of the redundant system use to monitor and initiate failover can be either unicast or multicast addresses.
Important: The target audience for this section of the appendix is users who want to configure both unicast and multicast addresses, or multicast addresses only, on a non-VIPRION system. If you want to configure unicast addresses only, see Chapter 16, Configuring High Availability. If you have a VIPRION system, see the Configuration Guide for the VIPRION® System.
If you want to configure network failover using both unicast and multicast settings, or mulitcast settings only, and you do not have a VIPRION system, you specify, on each unit, the management IP address that identifies the peer unit, and then you configure both unicast and multicast settings. That is, you need to specify at least one unicast addresses pair, and a multicast entry that contains a local interface and a remote address.
Important: One of the failover settings (either the Unicast or Multicast setting) needs to represent the management ports of the two units. For more information, see Using the Unicast setting to specify the management ports, following, or Using the Multicast setting to specify the management ports.
The unicast entry should contain the management IP addresses for the two units.
The multicast entry should contain a local interface and a remote self IP address representing the two HA VLANs.
For example, suppose that the host name for the local unit is bigip_A, and the host name for the remote unit is bigip_B. If the management IP addresses of the two units are 192.168.15.17 and 192.168.15.18, respectively, then the corresponding unicast entry (that is, IP address pair) on the local unit should specify a unique name, or configuration identifier, for the entry, the two management IP addresses, and the applicable service port, as in this example:
For added redundancy, you can add a second unicast entry that specifies the self IP addresses corresponding to the two HA VLANs. For example, if the self IP addresses for the two HA VLANs are 10.10.10.2 and 10.10.10.3, you can add a second unicast entry, resulting in these two unicast entries, where one entry represents the two management ports, while the other entry represents the two HA VLANs:
bigip_B_mgmtIPs_uni|192.168.15.17|192.168.15.18|1026
bigip_B_selfIPs_uni|10.10.10.2|10.10.10.3|1026
For the multicast entry, you can specify a local interface/self IP address pair, where the local interface is either eth0 or the name of the local trunk that you specified when creating VLAN HA, and the self IP address is the self IP address that you assigned to VLAN HA on the remote unit. The entry must also contain a configuration identifier and the applicable service port.
For example, if you previously assigned a trunk named HA_trunk_A to VLAN HA on the local unit bigip_A, and you assigned the self IP address 10.10.10.3 to VLAN HA on the remote unit bigip_B, then you would add this multicast entry:
The unicast entry that you specify should contain the self IP addresses corresponding to the two HA VLANs.
The multicast entry should contain local interface MGMT and the management IP address of the remote unit.
For example, if the self IP addresses for the two HA VLANs are 10.10.10.2 and 10.10.10.3, you add the unicast entry as in this example:
The multicast entry should contain the name of an interface on the local unit, and the management IP address of the remote unit. The entry must also contain the configuration identifier for the entry and the applicable service port. In our example, the interface name is MGMT, and the remote address is the management IP address of the remote unit, as in this example:
You use the Network Failover screen to configure the failover entries. Table B.1 shows the network failover settings that you can configure for a unit, followed by a description of each setting, and the default value of the setting.
Specifies, when checked (enabled), that the standby unit in a redundant system uses the network to determine the status of the active unit. By default, one unit monitors the status of its peer through a hard-wired connection.
Specifies the management IP address of the peer unit. This IP address is the address by which the unit identifies its peer unit. This address is used an alternate failover address if the self IP address on VLAN HA is not available.
Specifies a unique name for a Unicast entry. There is one configuration identifer per unicast entry. This name can be any string (such as yyy or zzz), but is usually most helpful when it includes the host name of the peer unit. For example, if the host name for the peer unit is bigip_B, then a useful configuration identifier for an entry that specifies management IP addresses might be bigip_B_mgmtIPs_uni. Similarly, a useful identifier for an entry that specifies self IP addresses might be bigip_B_selfIPs_uni. Note that these names must be different from the multicast configuration identifiers.
Specifies the local management IP address or the static self IP address that is associated with the failover VLAN you created on the unit you are configuring. Failover messages from the unit to its peer originate from this address. For more information, see the beginning of this section.
Specifies the remote management IP address or the remote static self IP address that is associated with the failover VLAN you created on the peer unit. This is the IP address on the peer that receives a failover message from the unit you are configuring. For more information, see the beginning of this section.
Identifies the service that you want to process the unicast failover communication traffic between the units.
Specifies a unique name for a multicast entry. There is one configuration identifer per multicast entry. This name can be any string (such as yyy or zzz), but is usually most helpful when it includes the host name of the peer unit. For example, if the host name for the peer unit is bigip_B, then a useful configuration identifier for an entry that specifies management IP addresses might be bigip_B_mgmtIPs_multi. Similarly, a useful identifier for an entry that specifies self IP addresses might be bigip_B_selfIP_multi. These names must be different from the unicast configuration identifiers.
If the management ports are specified in the Unicast settings, this Interface setting should specify the value eth0 or the name of the trunk you assigned to VLAN HA.
Conversely, if you want to specify the management ports in the Multicast settings, this Interface setting specifies interface MGMT of the unit you are configuring.
If the management ports are specified in the Unicast settings, this Remote Address setting specifies the self IP address of VLAN HA on the remote unit.
Conversely, if you want to specify the management ports in the Multicast settings, this Remote Address setting specifies the management IP address of the remote unit.
Identifies the service that you want to process the multicast failover communication traffic between the units.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
3.
On the menu bar, click Network Failover.
The Network Failover screen opens.
4.
Check the Network Failover box.
5.
In the Peer Management Address box, type the management IP address of the peer.
a)
In the Configuration Identifier box, type a unique name for the entry.
Note: This name must be different than the multicast configuration identifiers.
b)
In the Local Address box, type either the local management IP address or the self IP address of the local VLAN HA. For more information, see Table B.1.
c)
In the Remote Address box, if the unicast Local Address value is a management IP address, type the remote management IP address. If the unicast Local Address value is a self IP address, type the self IP address associated with VLAN HA on the peer unit. For more information, see Table B.1.
d)
In the Port box, retain the default value.
a)
In the Configuration Identifier box, type a unique name for the entry.
Note: This name must be different than the unicast configuration identifiers.
b)
In the Interface box, if the unicast Local Address and Remote Address values are self IP addresses, specify the interface MGMT. If the unicast Local Address and Remote Address values are management IP addresses, specify the trunk name or (or interface eth0) associated with the local VLAN HA. For more information, see Table B.1.
c)
In the Remote Address box, if the Interface value is MGMT, type the remote management IP address. If the Interface value is a trunk name or eth0, type the self IP address for the remote VLAN HA. For more information, see Table B.1.
d)
In the Port box, retain the default value.
8.
Click Update.
For certain network environments, you might want to configure an active-active configuration. The basic configuration procedure is similar to the configuration procedure for an active-standby configuration, except that you must set the redundancy mode on both units to Active.
The remainder of this appendix explains some concepts about active-active configurations, the procedures for controlling failback and changing the redundancy mode, and some special tasks and considerations.
Unlike an active/standby configuration, which is designed strictly to ensure no interruption of service in the event that a BIG-IP system becomes unavailable, an active-active configuration has an additional benefit. An active-active configuration allows the two units to simultaneously manage traffic, thereby improving overall performance.
A common active-active configuration is one in which each unit processes connections for different virtual servers. For example, you can configure unit 1 to process traffic for virtual servers A and B, and configure unit 2 to process traffic for virtual servers C and D. If unit 1 becomes unavailable, unit 2 begins processing traffic for all four virtual servers.
Figure B.1 shows an active-active configuration in which units 1 and 2 are both in active states. With this configuration, failover causes the following to occur:
Unit 2 (already in an active state) begins processing the connections that would normally be processed by unit 1.
When unit 1 becomes available again, you can initiate failback, which, in this case, means that the currently active unit relinquishes any processing that it is doing on behalf of its peer, and continues to operate in an active state, processing its own connections. From this point on, each unit in the active-active system handles its own unit-specific processing. For more information on failback, see Chapter 16, Configuring High Availability.
In addition to associating a unit in an active-active system with a specific virtual server, you can associate a unit with a particular SNAT. Thus, for an active-active configuration to operate successfully, you must associate each virtual server or SNAT with the unit of the redundant system that determines which active unit processes its connections.
Important: For an active-active system, you must assign a unique floating IP address to VLAN internal on each unit. Each unit shares its floating IP address with its peer (using ConfigSync).
For an active-active system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses, and when you ran Setup on unit 2, you again specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses. When you synchronize the configurations later, the addresses 11.12.11.3 and 11.12.11.4 should appear on both units as floating IP addresses.
The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 2.
The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address.
The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 1.
The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address.
Tip: You can configure additional floating IP addresses on the external VLANs of each BIG-IP system as well. This makes it possible for routers to route to a virtual server using virtual noarp mode.
Failback for an active-active configuration is never automatic, because during failback, the BIG-IP system drops the connections that failed over from the other unit, unless you have connection mirroring enabled on the relevant virtual server.
You can, however, specifically initiate failback. In this case, failback causes the failover unit (for example, unit 2) to relinquish the processing of unit 1 traffic back to unit 1, while continuing to process its own traffic. The normal time that it takes for failback to complete on an active-active system is 60 seconds.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
Returning to active/standby mode from active-active mode is relatively simple in that only a few things need be changed. Use the Configuration utility to do this conversion, being sure to make these same changes on each unit of the redundant system.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Redundancy Mode list, change the mode to Active/Standby.
3.
On the menu bar, click ConfigSync.
The ConfigSync screen opens.
4.
For the Synchronize setting, click Synchronize TO Peer.
5.
Click Update.
6.
On the menu bar, click Redundancy.
The Redundancy Properties screen opens.
7.
From the Redundancy State Preference list, change the preferred state of the unit to Active or Standby. For more information, see Chapter 16, Configuring High Availability.
8.
Click Update.
Once the system is running in active/standby mode, it is the active unit that manages connections for all local traffic management objects (such as virtual servers and SNATs), regardless of the unit associated with those objects. Therefore, it is not necessary to re-associate virtual servers, SNATs, or NATs with a specific unit when you transition from active-active mode to active/standby mode.
When the surviving unit takes over a virtual server of the failed unit (in addition to having its own virtual servers), the surviving unit must know which virtual server to use to process traffic that it receives from a back-end server. The way it knows this is by the floating IP address to which the response was sent. (As described previously, in an active-active configuration, each unit must have its own unique floating IP address.)
The floating IP address of unit 1 is 11.12.11.3, and the floating IP address of unit 2 is 11.12.11.4.
Server http_server normally handles traffic for unit 1, which has virtual server vs_http. Server smtp_server normally handles traffic for unit 2, which has virtual server vs_smtp.
You have configured the default routes of the servers accordingly. That is, you have set the default route of http_server to 11.12.11.3, and the default route of smtp_server to 11.12.11.4.
Continuing with our previous example of back-end server http_server, if the surviving unit receives a response from http_server (sent to 11.12.11.3, the unit 1 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by the unit 1 virtual server vs_http (now on unit 2).
Similarly, if the surviving unit receives a response from server smtp_server (sent to 11.12.11.4, the unit 2 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by its own virtual server, vs_smtp.
Thus, if you have 20 servers and half of them normally serve the unit 1 virtual servers, you must configure the default route for those 10 servers to be the floating IP address of unit 1. For the remaining 10 servers in your network, which serve the unit 2 virtual servers, you must configure their default route to be the floating IP address of unit 2.
By setting the default routes of your back-end servers to the floating IP address of either unit 1 or unit 2, you ensure that if a unit becomes unavailable, any connections that the servers normally send to that unit are received and processed by the surviving unit, because the surviving unit has assumed the internal floating IP address of the failed machine.
Important: If you plan to run your redundant system in active-active mode, you must synchronize the configuration data again. For more information, see Chapter 16, Configuring High Availability.
For active-active configurations, you cannot switch an active unit to a STANDBY or an OFFLINE state if that unit is currently processing connections for the peer unit due to a failover.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)