Applies To:

Show Versions Show Versions

Manual Chapter: Configuring High Availability
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

20 
High availability refers to the ability of a BIG-IP® system to process network traffic successfully. The specific meaning of high availability differs depending on whether you have a single BIG-IP device or a redundant system configuration:
Single device
When you are running the BIG-IP system as a single device (as opposed to a unit of a redundant system), high availability refers to core services being up and running on that device, and VLANs being able to send and receive traffic. For information on configuring a single device for high availability, see Configuring fail-safe. The other sections of this chapter are not applicable to systems configured as single devices.
Redundant system configuration
When you are running the BIG-IP system as a unit of a redundant system configuration, high availability refers to core system services being up and running on one of the two BIG-IP systems in the configuration. High availability also refers to a connection being available between the BIG-IP system and a pool of routers, and VLANs on the system being able to send and receive traffic. For information on configuring a redundant system for high availability, see the remainder of this chapter.
A redundant system is a type of BIG-IP system configuration that allows traffic processing to continue in the event that a BIG-IP system becomes unavailable or unhealthy. A BIG-IP redundant system consists of two identically-configured BIG-IP units. When an event occurs that prevents an active unit from processing network traffic or puts that unit at risk for processing traffic, the peer unit in the redundant system immediately begins processing that traffic, and users experience no interruption in service.
You can configure the units of a redundant system to run in one of two redundancy modes: active/standby or active-active.
Active/standby mode
With active/standby mode, only one of the two units is in an active state, that is, processing traffic, at any given time. The inactive unit serves strictly as a standby unit, becoming active only if the active unit becomes unavailable or unhealthy. When a standby unit becomes active, it normally remains active until an event occurs that requires the other unit to become active again, or until you specifically force it into a standby state. Active/standby mode is the recommended mode for redundant system configuration. For more information, see Understanding failover in active/standby mode.
Active-active mode
With active-active mode, both units are in an active state simultaneously, each processing traffic for different virtual servers or SNATs. If an event prevents one of the units from processing traffic, the other unit begins processing that traffic in addition to its own. For more information, see Appendix B, Additional Considerations for Redundant System Configurations.
Failover is a process that occurs when one system in a redundant system becomes unavailable or unhealthy, thereby causing the peer unit to assume the processing of traffic originally targeted for the unavailable unit.
To enable a unit to fail over to its peer unit, you must first specify the type of failover that you want the redundant system to use. The two possible failover types are hard-wired failover and network-based failover.
Hard-wired failover
When you configure hard-wired failover, you enable failover by using a serial cable to physically connect the two redundant units. Serial cable failover is based on heartbeat detection, where voltage is continuously sent from one BIG-IP system to another. If a response does not initiate from one BIG-IP system, failover to the peer will occur in less than one second. This is the default setting. Note that serial cable failover is always enabled and cannot be disabled by a BIG-IP system administrator.
Network failover
When you configure network failover, you enable failover by configuring your redundant system to use the network to determine the status of the active unit. Like hard-wired failover, network failover is based on heartbeat detection, but instead of using the serial cable, heartbeat packets are sent over the internal network.
You use network failover in addition to hard-wired failover. Even with serial cable failover configured, communication through network failover is required for certain features to function properly, for example, the communication that occurs over the network during failover mirroring.
Configuring network failover is also required for active-active configurations. An active-active pair must communicate over the network to indicate the objects and resources they are servicing. Otherwise, if network communications fail, the two systems may attempt to service the same objects, which could result in duplicate IP addresses on the network. For more information on enabling network failover and specifying the required IP addresses, see Creating VLANs and self IP addresses for failover.
If a BIG-IP high availability pair is configured to use network failover, and the serial failover cable also connects the two units, serial cable failover always takes precedence. If network failover traffic is compromised, the two units do not failover because the serial failover cable is still connecting the two units. If the two BIG-IP units are located close enough for serial cable failover, this is the recommended failover choice for active-standby configurations.
When a redundant system is in active/standby mode, one unit is active, that is, accepting and processing connections on behalf of the redundant system, while the other unit is idle (that is, in a standby state).
When failover occurs, the standby unit becomes active, and it normally stays active until failover occurs again, or until you force it into a standby state. Forcing the unit into a standby state automatically causes the other system to become active again, if possible.
For example, you can configure unit 1 to process traffic for virtual servers A and B. The standby unit monitors the active unit, and if communications fail or indicate that the active unit is unhealthy, the standby unit initiates a failover and becomes the active unit. The newly-active unit then begins processing traffic for both virtual servers.
You can see an active/standby configuration, first as it behaves normally, and then after failover has occurred, by viewing Figure 20.1.
As you can see in Figure 20.1, unit 1 is in an active state, and unit 2 is in a standby state. With this configuration, failover causes the following to occur:
When the failed or unhealthy unit becomes available or healthy again, you can force a unit to change its state from active to standby or from standby to active, thereby initiating failback. Failback on an active/standby system causes a unit to relinquish any processing that it is doing on behalf of its peer, and return to a standby state. A redundant system in active/standby mode is the most common type of redundant system.
A static self IP address is an IP address that you assign to a BIG-IP system VLAN. On any BIG-IP device, you normally assign a unique static self IP address to VLAN internal, and another self IP address to VLAN external, when you run the Setup utility on that device.
When you set up an active/standby system configuration that uses network failover, F5 Networks® recommends that you create an additional VLAN (with a static self IP address) on each unit of the redundant system, to be used specifically for failover communication. Consequently, during normal redundant-system operation prior to failover, the two units use these static self IP addresses to continually communicate with one another about system status. These static self IPs are known as failover addresses, that is, addresses that the two units use to communicate with one another, before, during, and after failover.
Additionally, you can specify an additional static self IP address for that failover VLAN on each unit that the BIG-IP system can use for network mirroring.
Fail-safe is the ability of a BIG-IP system to monitor certain aspects of the system or network, detect interruptions, and consequently take some action, such as rebooting or initiating failover to the peer unit. Fail-safe can apply to: system services, traffic between the BIG-IP system and a gateway router, or VLAN traffic, and pertains to both single devices and redundant system configurations. For more information, see Configuring fail-safe.
If you are setting up a redundant system configuration, you must first run the Setup utility on each unit that is to make up the redundant system if you have not already done so. Once you have supplied this information, you can use the remainder of this chapter to complete the configuration of your redundant system. You also need to perform a task on the back-end servers to which the redundant system sends network traffic.
Note: Only users with either the Administrator or Resource Administrator user role can configure a redundant system.
Before you create a redundant system configuration, you should ensure that the device you are configuring is already designated as being part of a redundant system. (You typically designate a device as being part of a redundant system when you initially run the Setup utility on that unit. You can also designate this in the Configuration utility on the Platform screen. For more information, see To ensure redundant-system designation for a unit, following.)
1.
On the Main tab of the navigation pane, expand System, and click Platform.
The General screen opens.
2.
In the General Properties area, verify that the High Availability list is set to Redundant Pair. If not, select this value.
3.
For the Unit ID list, retain or change the value, depending on which unit ID you want to assign to this BIG-IP system.
Note: The unit ID must be unique on each BIG-IP system.
4.
Click Update.
Important: The default (and recommended) type of redundant system that you create is an active/standby system. For active-active configurations, you must perform additional configuration tasks after using the Configuration utility. For detailed information, see Appendix B, Additional Considerations for Redundant System Configurations.
You can use the HA Setup wizard from within the Configuration utility. With this wizard, you can use just a few screens to quickly create or specify all of the objects required for redundancy. For more information, see To use the HA Setup wizard.
You can use the High Availability screens in the System menu of the Configuration utility. The remainder of this chapter describes how to use these screens.
You can use the bigpipe utility. For more information, see the Bigpipe Utility Reference Guide.
You can use tmsh. For more information, see the Traffic Management Shell (tmsh) Reference Guide.
1.
In the Main tab of the navigation pane, expand Templates and Wizards, and click Device Wizards.
The Wizard List screen opens.
2.
In the System Configuration setting, click HA Setup Wizard.
3.
Click Next.
4.
Configure the Redundancy Properties screen.
For conceptual information on redundancy properties, see Configuring redundancy properties, and the online help.
5.
Click Next.
6.
Configure the failover VLAN and self IP address properties.
For conceptual information on configuring the failover VLAN and self IP address properties, see Creating VLANs and self IP addresses for failover, and the online help.
7.
Click Next.
8.
Configure the Network Failover screen.
For conceptual information on configuring network failover, see Configuring network failover, and the online help.
9.
Click Next.
11.
If you want to implement the configuration, click Finished. If you want to cancel the configuration, click Cancel.
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, either retain the default value of Active/Standby, or select Active/Active. For more information, see Configuring the redundancy mode.
3.
From the Redundancy State Preference list, select a preferred state for the unit you are configuring. For more information, see Specifying a redundancy state preference.
4.
If you want an interface down time other than 0.0, type a value in the Link Down Time on Failover box. For more information, see Specifying the link down-time on failover.
Configuring the redundancy mode means specifying whether your redundant system runs in active/standby mode or active-active mode. If you choose active/standby mode, you can specify whether you prefer that unit to be an active or a standby unit when both units are available for processing traffic. For information on setting a preference for a units redundancy state, see Specifying a redundancy state preference, following.
When you configure a system to be part of an active/standby redundant system, you can specify whether you want that system to function primarily as the active system or the standby system in the event that both units can be active at the same time. You can also can specify that you have no preference.
None
Specifies that this unit does not have a preferred redundancy state.
If you set this value to None on one unit of the redundant system configuration, you must set the same value (None) on the other unit also. Otherwise, an invalid configuration results.
Active
Specifies that this unit is the preferred active unit. If you choose this option, the unit can be in a standby state due to a failover event. However, failback to this unit is automatic when this unit becomes available.
Standby
Specifies that this unit is the preferred standby unit. If you choose this option, then the unit can be in an active state due to a failover condition. However, failback to the peer unit is automatic when the peer unit becomes available.
When configuring a unit of a redundant system configuration, you can use the Link Down Time on Failover setting to specify the amount of time, in seconds, that interfaces for any VLANs on external devices are down when the unit fails over and goes to a standby state. Specifying a value other than 0 for this setting causes other vendor switches to use the specified time to learn the MAC address of the newly-active unit.
The allowed value for this setting is 0 to 10. Setting the value to 0 disables this setting.
The next step is to create a dedicated VLAN, on each unit, that the system uses specifically for failover communications. You should also create a static self IP address for each of these dedicated VLANs. To create these objects, you should use the Configuration utility.
When you configure network failover for a redundant system configuration, you specify the unicast or multicast IP addresses that you want each system in the configuration to use for failover. To do this, you use the Network Failover screen.
Table 20.1 lists some important considerations for configuring network failover.
Active-active configuration
If you are setting up an active-active configuration, a hard-wired failover configuration is not sufficient; you must also configure network failover. For more information on active-active configuration, see Appendix B, Additional Considerations for Redundant System Configurations.
As an alternative to using the Network Failover screen, you can use the HA Setup wizard. For more information, see To use the HA Setup wizard.
If the units of the redundant system consist of multi-bladed chassis platforms (that is, VIPRION systems), see the Configuration Guide for the VIPRION® System.
On the Network Failover screen and in the remainder of this chapter, the term local unit refers to the unit you are currently configuring, and the term remote unit refers to the peer unit.
When specifying unicast, rather than multicast, addresses for failover, you need to specify two pairs of IP addresses, where one of the pairs indicates the management IP addresses of the two units. The other pair indicates two self IP addresses, one for VLAN HA on each unit.
For example, suppose 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 on the local unit should indicate the two management IP addresses, as well as the host name (also known as the configuration identifier) of the peer unit and the applicable service port, as in this example:
If the self IP addresses for the two HA VLANs are 10.10.10.2 (for the local unit) and 10.10.10.3 (for the remote unit), then a second unicast entry on the local unit should indicate the two self IP addresses, as well as the host name of the peer unit and the applicable service port. Adding this second unicast entry results in a configuration such as the following:
bigip_B_mgmt|192.168.15.17|192.168.15.18|1026
bigip_B_self|10.10.10.2|10.10.10.3|1026
Specifying a multicast address for failover is typically most useful for a VIPRION system. However, you can specify a multicast address for non-VIPRION systems as well.
When specifying a multicast address for network failover, you need to specify a local interface and a multicast IP address, where the multicast address represents the management IP address of the remote unit. For example, you can specify this entry, where bigip_B represents the configuration identifier of the remote unit:
Table 20.2 shows the network failover settings that you can configure for a unit, along with their default values.
Specifies, when checked (enabled), that the unit, when in standby mode, 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 as an alternate failover address if the self IP address on VLAN HA is not available.
Important: F5 Networks strongly recommends that you specify a value for this setting. This value should be the IP address of the management port. You can find this address on the Platform screen of the Configuration utility.
Specifies either the static self IP address that is associated with the local HA VLAN or the local management IP address. Failover messages from the unit to its peer originate from this address.
Specifies either the static self IP address that is associated with the remote HA VLAN or the remote management IP address. This is the IP address on the peer that receives a failover message from the unit you are configuring.
Identifies the service that you want to process the unicast failover communication traffic between the units.
Specifies the name of the peer in the redundant system configuration. This name must be different from the Unicast Configuration Identifier.
Displays the name of the management interface, either eth0 or mgmt. To change this value, you must use the tmsh utility.
Identifies the service that you want to process the multicast failover communication traffic between the units.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
On the menu bar, click Network Failover.
The Network Failover screen opens.
3.
Click the Network Failover box.
4.
In the Peer Management Address box, delete the colons (::) and type the management IP address of the peer unit.
a)
In the Configuration Identifier box, type the name of the peer unit.
b)
In the Local Address box, type the management IP address for the unit you are configuring.
Note that you can skip steps 5b, 5c, and 5d if you intend to configure the Multicast setting as well,
c)
In the Remote Address box, type the management IP address on the peer unit.
d)
In the Port box, retain the default value.
e)
Click Add.
f)
In the Configuration Identifier box, again type the name of the peer unit.
g)
In the Local Address box, type the self IP address associated with the failover VLAN you created on the unit you are configuring (such as VLAN HA).
h)
In the Remote Address box, type the self IP address associated with the failover VLAN you created on the peer (such as VLAN HA).
i)
In the Port box, retain the default value.
j)
Click Add.
a)
In the Configuration Identifier box, type the name of the peer unit.
b)
In the Remote Address box, type a multicast address for the peer unit.
c)
In the Port box, retain the default value.
d)
Click Add.
7.
Click Update.
The failover process of a redundant system ensures that a BIG-IP system is always available to process connections with no discernible interruption in service at the time of the failure event. However, failover does not preserve the open connections at the moment of failover; connections are dropped when an active unit becomes unavailable, unless you have configured network mirroring.
The network mirroring feature on the BIG-IP system duplicates a units state (that is, real-time connection and persistence information) on the peer unit. When network mirroring is enabled, failover can be so seamless that file transfers can proceed uninterrupted and your servers can continue with their tasks at the time of failover.
Note: Prior to enabling network mirroring, you must enable connection mirroring on the relevant virtual server or SNAT. For more information, see the Configuration Guide for BIG-IP® Local Traffic Manager.
To enable network mirroring for a redundant system, you specify the static self IP addresses that the BIG-IP system uses to mirror connections.
For the Mirroring Address setting:
With the Self setting, you specify the primary self IP address on this unit to which the peer unit mirrors its connections. This is a required setting.
With the Peer setting, you specify the primary self IP address on the peer unit to which this unit mirrors its connections. This is a required setting.
For the Alternate Mirroring Address setting:
With the Self setting, you specify another self IP address on this unit to which the peer unit mirrors its connections when the primary Self address is unavailable.
With the Peer setting, you specify another self IP address on the peer unit to which this unit mirrors its connections when the primary Peer address is unavailable.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
On the menu bar, click Network Mirroring.
The Network Mirroring screen opens.
3.
For the Mirroring Address settings, in the Self box, type the static self IP address on this unit to which the peer unit should mirror connections. In the Peer box, type the static self IP address for the peer unit to which this unit should mirror connections.
Note: Before typing the IP addresses, delete the two colons (::) in each box.
4.
For the Alternate Mirroring Address settings, in the Self box, type the static self IP address on this unit to which the peer unit should mirror connections when the primary Self address is unavailable. In the Peer box, type the static self IP address for the peer unit to which this unit should mirror connections when the primary Peer address is unavailable. For more information, see Configuring network mirroring.
Note: Before typing the IP addresses, delete the two colons (::) in each box.
5.
Click Update.
Note: If connection mirroring is enabled and failback occurs, connection re-mirroring can only occur when the virtual server processing the connections is a Performance (Layer 4) type of virtual server. For more information, see Re-mirroring connections.
The BIG-IP system includes a feature known as an HA group. An HA group is a set of trunks, pools, or clusters (or any combination of these) that you want the BIG-IP system to use to calculate an overall health score for a unit in a redundant system configuration. A health score is based on the number of members that are currently available for any trunks, pools, and clusters in the HA group, combined with a weight that you assign to each trunk, pool, and cluster. The unit that has the best overall score at any given time becomes or remains the active unit.
Note: Only VIPRION® systems can have a cluster as an object in an HA group. For all other platforms, HA group members consist of pools and trunks only.
An HA group is typically configured to fail over based on trunk health in particular. Trunk configurations are not synchronized between units, which means that the number of trunk members on the two units often differs whenever a trunk loses or gains members. The HA group feature allows failover to occur based on changes to trunk health instead of on system or VLAN failure.
One of the benefits of configuring an HA group is a feature known as fast failover. When you configure the HA group, the process of one BIG-IP unit failing over to the other based on HA scores is noticeably faster than if failover occurs due to a hardware or daemon failure.
Important: Before you configure the HA groups feature, verify that the redundant pair is set up to use network failover, rather than hard-wired failover. Network failover is a prerequisite for this feature.
A weight is a health value that you assign to each object in the HA group (that is, pool, trunk, and cluster). The weight that you assign to each object must be in the range of 10 through 100. The maximum overall score that the BIG-IP system can potentially calculate for a unit is the sum of the individual weights for the HA group objects, plus the active bonus value. There is no limit to the sum of the object weights for the HA group as a whole. (For information on the Active Bonus setting, see Specifying an active bonus.)
Table 20.3 shows an example of how the system calculates a score for the unit, based solely on the weight of objects in the HA group. In this example, the HA group contains two pools (my_http_pool and my_ftp_pool) and one trunk (my_trunk1). A user has assigned a weight to each object.
Available Members
31
(60% x 50)
20
(100% x 20)
23
(75% x 30)
Total unit score = 74
On each unit, the system uses each weight, along with a percentage that the system derives for each object (the percentage of the objects members that are available), to calculate a score for each object.
The system then adds the scores to determine a total score for the unit. The unit with the highest score becomes or remains the active unit in the redundant system configuration.
Note that if you have configured VLAN fail-safe, and the VLAN fails on an active unit, the unit goes offline regardless of its score, and its peer becomes active.
For each object in an HA group, you can specify an optional setting known as a threshold. A threshold is a value that specifies the number of object members that must be available to prevent failover. If the number of available members dips below the threshold, the BIG-IP system assigns a score of 0 to the object, so that the score of that object no longer contributes to the overall score of the unit.
For example, if a trunk in the HA group has four members and you specify a threshold value of 3, and the number of available trunk members falls to 2, then the trunk contributes a score of 0 to the total unit score.
If the number of available object members equals or exceeds the threshold value, or you do not specify a threshold, the BIG-IP system calculates the score as described previously, by multiplying the percentage of available object members by the weight for each object and then adding the scores to determine the overall unit score.
The threshold that you define for pools can be less than or equal to the number of members in the pool. For clusters, the threshold can be less than or equal to the number of possible blades in the chassis, and for trunks, the threshold can be less than or equal to the number of possible members in a trunk for that platform.
Tip: Do not configure the tmsh attribute min-up-members on any pool that you intend to include in the HA group.
An active bonus is an amount that the BIG-IP system automatically adds to the overall score of the active unit. An active bonus ensures that the active unit remains active when the units score would otherwise temporarily fall below the score of the standby unit. The active bonus that you configure can be in the range of 0 to 100.
A common reason to specify an active bonus is to prevent failover due to flapping, the condition where failover occurs frequently as a trunk member toggles between availability and unavailability. In this case, you might want to prevent the HA scoring feature from triggering failover each time a trunk member is lost. You might also want to prevent the HA scoring feature from triggering failover when you make minor changes to the BIG-IP system configuration, such as adding or removing a trunk member.
Suppose that the HA group on each unit contains a trunk with four members, and you assign a weight of 30 to each trunk. Without an active bonus defined, if the trunk on unit 1 loses some number of members, failover occurs because the overall calculated score for unit 1 becomes lower than that of unit 2. Table 20.4 shows the scores that could result if the trunk on unit 1 loses one trunk member and no active bonus is specified.
30 30
30 30
23 30
(75% of 30) (100% of 30)
23 30
You can prevent this failover from occurring by specifying an active bonus value. In our example, if we specify an active bonus of 10 (the default value), the score of the active unit changes from 23 to 33, thereby ensuring that the score of the active unit remains equal to or higher than that of the standby unit (30).
Although you specify an active bonus value on each unit, the BIG-IP system uses the active bonus specified on the active unit only, to contribute to the score of the active unit. The BIG-IP system never uses the active bonus on the standby unit to contribute to the score of the standby unit.
Important: An exception to this behavior is when the active unit score is 0. If the score of the active unit is 0, the system does not add the active bonus to the active unit score.
To decide on an active bonus value, calculate the trunk score for some number of failed members (such as one of four members), and then specify an active bonus that results in a trunk score that is greater than or equal to the weight that you assigned to the trunk.
For example, if you assigned a weight of 30 to the trunk, and one of the four trunk members fails, the trunk score becomes 23 (75% of 30), putting the unit at risk for failover. However, if you specified an active bonus of 7 or higher, failover would not actually occur, because a score of 7 or higher, when added to the score of 23, is greater than or equal to 30.
You can prevent failover from occurring by specifying an active bonus value. Table 20.5 and the list that follows shows how configuring an active bonus for the active unit can affect failover.
Unit Score
(Trunk Score + Active Bonus)
Unit 1 is active (initial state)
30 30
(100% of 30) (100% of 30)
40 30
Unit 1 loses a trunk member
23 30
(75% of 30) (100% of 30)
33 30
Unit 1 loses another trunk member
15 30
(50% of 30) (100% of 30)
25 30
Unit 1 goes to standby. Unit 2 goes active.
15 30
(50% of 30) (100% of 30)
0 10
15 40
Unit 2 loses a trunk member
15 23
(50% of 30) (75% of 30)
0 10
15 33
Unit 1 regains two trunk members
30 23
(100% of 30) (75% of 30)
0 10
30 33
To help understand Table 20.5, the row numbers in the left column of the table correspond to the explanations below:
1 Unit 1 is active (initial state)
With all trunk members available on both units, and the active bonus configured, the active unit (unit 1) retains the higher unit score and therefore remains active.
2 Unit 1 loses a trunk member
The unit score for unit 1 is still higher than the score for unit 2, due to an active bonus value of 10.
3 Unit 1 loses another trunk member
With an active bonus of 10, failover occurs when 50% of the members are lost.
4 Unit 1 switches to standby mode and unit 2 becomes active
Once the active unit (unit 1) has failed over to unit 2, the active bonus on unit 1 no longer applies, thus reducing its score from 25 to 15. The active bonus on unit 2 is then applied, increasing unit 2s score from 30 to 40.
5 Unit 2 loses a trunk member
If the active unit (unit 2) loses a trunk member, the score on unit 2 is still higher than unit 1 (with two unavailable members), due to the active bonus.
6 Unit 1 regains two trunk member
Unit 2 remains the active unit even when one trunk member is unavailable, due to the active bonus.
To configure the system so that failover can occur based on an HA score, you must specify values for the properties of an HA group. The BIG-IP system allows you to configure one HA group only; you cannot create additional HA groups.
Once you have configured HA group properties, the BIG-IP system uses that configuration to calculate an overall HA score for each unit of the redundant system configuration.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
Specify an integer the represents the amount by which you want the system to increase the overall score of the active unit. The purpose of the active bonus is to prevent failover when minor or frequent changes occur to the configuration of a pool, trunk, or cluster.
In the Available box, click a pool name and use the Move button to move the pool name to the Selected box. This populates the table that appears along the bottom of the screen with information about the pool.
In the Available box, click a trunk name and use the Move button to move the trunk name to the Selected box. This populates the table that appears along the bottom of the screen with information about the trunk.
In the Available box, click a cluster name and use the Move button to move the cluster name to the Selected box. This populates the table that appears along the bottom of the screen with information about the cluster.
Note: This setting appears on VIPRION systems only.
For each pool or trunk in the HA group, specify an integer for a threshold value. This value is optional.
For each pool or trunk in the HA group, specify an integer for the weight. The allowed weight for an HA group object ranges from 10 through 100. This value is required.
5.
Click Create.
You can view the HA score that the BIG-IP system has calculated for each unit at any given time. To view the score, as well as other details about the HA group, use the tmsh command line interface.
You can compare the score of the HA score on the current unit with the HA score of the peer unit. At the system prompt on either unit, type:
Once you have completed the initial configuration of one of the units in your redundant system, you must synchronize the configuration between the two units.
Note: Only users with either the Administrator or Resource Administrator user role can synchronize configuration data.
When you synchronize data from one unit to another, you are giving the target unit the data that it needs to assume traffic processing for its peer when failover occurs. Examples of configuration data that a target unit receives during configuration synchronization are virtual servers, SNATs, and floating IP addresses.
When you have a redundant system configuration, it is essential that each unit shares, or synchronizes, its current configuration data with its peer unit. If a unit does not share its configuration data with its peer, the surviving unit cannot process traffic for that peer unit. For this reason, you must synchronize configuration data when you initially configure the redundant system, and then repeatedly, on an ongoing basis. The need to repeatedly synchronize data is because a units configuration data typically changes over time during normal system maintenance, such as when you add a virtual server or create a new profile, and the unit must share those changes with its peer.
You can synchronize configuration data from the current system to the peer system, or from the peer system to the current system. The method you choose depends on which units data has most recently changed and which unit you are currently configuring.
Normally, the BIG-IP system uses the peers failover address as the address to which to synchronize the configuration. As an option, however, you can specify a peer address other than the peers failover address.
When you perform configuration synchronization, the BIG-IP system copies a .ucs file containing configuration data from one unit to the other. You must synchronize the configuration data before you can put any redundant system into operation.
Prior to synchronizing configuration data, the BIG-IP system creates a backup configuration file on the target system, named cs_backup.ucs, as a preventative measure. For more information, see Chapter 22, Creating and Managing Archives.
Tip: You can easily determine when to synchronize configuration data by using the Configuration utility to view synchronization status. Synchronization status indicates whether the configuration data of the units is synchronized. For more information, see Viewing synchronization status.
You synchronize configuration data using the ConfigSync screen that is available from the Redundancy Properties screen of the Configuration utility. The ConfigSync screen contains several settings. Two of these settings, ConfigSync User and Synchronize, cause the actual configuration synchronization between redundant units to occur. The following sections describe the settings on the ConfigSync screen. Following these descriptions is the procedure for performing the configuration synchronization.
Use the ConfigSync Peer setting to specify the type of IP address that you want the BIG-IP system to use when synchronizing the configuration data. The two possible values are:
Use Primary Connection Mirror Address
Selecting this value causes the system to use the peers primary network mirroring address, which you previously specified on the Network Mirroring screen in the Mirroring Address setting.
Specify IP Address
Selecting this value allows you to type an IP address of your choice for the ConfigSync Peer Address setting (described in the following section). Select this value when you do not want the system to use the peers primary mirror address to synchronize the configuration.
By default, the ConfigSync Peer Address setting is a non-configurable ConfigSync property. That is, when the ConfigSync Peer setting is set to Use Primary Connection Mirror Address (the default setting), you cannot configure the ConfigSync Peer Address setting. In this case, the setting is for informational use only.
If you set the ConfigSync Peer setting to Specify IP Address, you can configure the ConfigSync Peer Address setting by typing an IP address for the peer system that you want the BIG-IP system to use for configuration synchronization.
The ConfigSync User setting allows you to specify the name of the user who is allowed to perform configuration synchronization. In order for configuration synchronization to function correctly, the name and password for the ConfigSync User account must be the same on both BIG-IP units. Whenever you change the ConfigSync User password, the BIG-IP system reminds you to update the password on the peer unit.
Important: If you use the bigpipe utility instead of the Configuration utility to change the ConfigSync user name and password, you must remember to make the same changes on the peer unit. Unlike the Configuration utility, the bigpipe utility does not display a message reminding you to change the user name and password on the peer unit.
Only users with either the Administrator or Resource Administrator role assigned to their user accounts can perform configuration synchronization. Consequently, all existing BIG-IP system user accounts that have the Administrator or Resource Administrator role assigned to them appear in the Name list.
The default user account name for the ConfigSync User setting is admin. If you want to perform a configuration synchronization and you are not user admin, you must select a user name from the Name list and type your password.
If you want to give a user other than yourself permission to perform a configuration synchronization, and the user name does not appear in the Name list, use the Users screen to assign the Administrator or Resource Administrator role to that user account.
As a security precaution, you can enable the Encryption setting. Enabling this setting causes the BIG-IP system to encrypt the configuration data immediately prior to synchronization. The two possible values are on and off. The default value is off.
When you set the Encryption setting to on, you must configure two additional settings:
Passphrase
Specifies a password for encryption.
Verify Passphrase
Confirms the password by requiring you to type it again.
To ensure that you are aware of any need to synchronize configuration data, you can display synchronization status on each screen of the Configuration utility. You enable this display of synchronization status on the ConfigSync screen, using the Detect ConfigSync Status setting. If you check this box, the BIG-IP system displays, on every screen of the Configuration utility, the current synchronization status of the unit you are configuring.
Tip: The Configuration utility also displays more detailed synchronization status information. For complete information on viewing configuration synchronization status, see Viewing synchronization status.
The Synchronize setting allows you to perform a configuration synchronization between two units. To synchronize data, you can click either of the following buttons:
Synchronize TO Peer
Use this button when the unit you are currently configuring contains updated configuration data that you want to share with the peer unit.
Synchronize FROM Peer
Use this button when the peer unit contains updated configuration data that you want to share with the unit you are currently configuring.
In either case, the term peer refers to the unit with the self IP address that appears in the ConfigSync Peer Address setting.
Note: When you synchronize the configuration on an active/standby system, the unit ID displayed for a floating IP address after a config sync is the unit ID assigned to the self IP address of the unit that syncs its data to the peer.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
On the menu bar, click ConfigSync.
The ConfigSync screen opens.
3.
From the ConfigSync Peer list, retain the default setting Use Primary Connection Mirror Address, or select Specify IP Address.
4.
In the previous step, if you retained the default setting, skip to step 5. If you selected Specify IP Address, type an IP address in the ConfigSync Peer Address box.
5.
If the user name you are using is not admin, follow these steps. Otherwise, skip to Step 6:
a)
From the Configuration list, and select Advanced.
b)
For the ConfigSync User setting, select a user name from the Name list.
This displays the Password box.
c)
In the Password box, type the password for the selected user name.
Note: If you want encrypted configuration data to be included in archive files, use the Preferences screen to turn on the Archive Encryption setting.
7.
If you want the BIG-IP system to display synchronization status on every screen of the Configuration utility, locate the Detect ConfigSync Status setting and check the Enabled box.
For more information, see Enabling the global display of synchronization status.
8.
For the Synchronize setting, click Synchronize TO Peer or Synchronize FROM Peer.
For more information, see Specifying synchronization direction.
9.
Click Update.
Fail-safe is the ability of a BIG-IP system to monitor certain aspects of the system or network, detect interruptions, and consequently take some action. More specifically:
In the case of a redundant system, a unit can detect a problem with a service, VLAN, or gateway, and initiate failover to the peer unit.
In the case of a single device (non-redundant system), the system can detect a problem with a service, VLAN, or gateway, and take some action, such as restarting the service.
System fail-safe
Monitors the switch board component and a set of key system services.
Gateway fail-safe
Monitors traffic between the BIG-IP system and a gateway router.
VLAN fail-safe
Monitors traffic on a VLAN.
Note: Only users with either the Administrator or Resource Administrator user role can configure fail-safe.
When you configure system fail-safe, the BIG-IP system monitors various hardware components, as well as the heartbeat of various system services, and can take action if the system detects a heartbeat failure.
You can configure the BIG-IP system to monitor the switch board component and then take some action if the BIG-IP system detects a failure.
Using the Configuration utility, you can specify the action that you want the BIG-IP system to take when the component fails. Possible actions that the BIG-IP system can take are:
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Fail-safe menu, choose System.
The System Fail-safe screen opens.
3.
From the Switch Board Failure list, select an action, or retain the default setting (Go Offline Abort TMM).
4.
Click Update.
You can specify the particular action that you want the BIG-IP system to take when the heartbeat of a system service fails. Table 20.6 lists each system service, and shows the possible actions that the BIG-IP system can take in the event of a heartbeat failure.
TMROUTED
(Single device only)
Note: You can find additional, background information about the MCPD, TMM, and SOD services in Appendix C, Understanding Core System Services. For information on managing optional services such as ntpd or sshd, see Chapter 24, Configuring BIG-IP System Services.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Fail-safe menu, choose System.
The System Fail-safe screen opens.
3.
In the System Services area, in the Name column, click the name of the service you want to monitor.
The screen for that service opens.
4.
From the Heartbeat Failure list, select an action, or retain the default setting.
5.
Click Finished.
The System Fail-safe screen displays.
One type of network failure detection is known as gateway fail-safe, which applies to a redundant system configuration only. Gateway fail-safe monitors traffic between the active BIG-IP system and a pool containing a gateway router. This type of monitoring protects the system from a loss of an internet connection by triggering a failover when a gateway router is unreachable for a specified duration. You configure the gateway fail-safe feature if you want failover to occur when a gateway router is unreachable.
You can configure gateway fail-safe using the Configuration utility. Configuring gateway fail-safe means designating a load balancing pool as a gateway fail-safe pool.
The action that the BIG-IP system should take when the number of available gateway pool members drops below the designated threshold. The default value is Failover.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Fail-safe menu, choose Gateway.
The Gateway Fail-safe screen opens.
3.
In the upper-right corner of the screen, click Add.
The Add Gateway Pool screen. opens.
4.
From the Gateway Pool list, select the name of a load balancing pool.
5.
From the Unit ID list, select a unit ID for the pool (1 or 2).
6.
In the Threshold box, type the number of pool members that must be available to avoid the action designated in the Action setting.
7.
From the Action list, select Failover.
8.
Click Finished.
For maximum reliability, the BIG-IP system supports failure detection on all VLANs. When you configure the fail-safe option on a VLAN, the BIG-IP system monitors network traffic going through that VLAN. If the BIG-IP system detects a loss of traffic on the VLAN and the fail-safe timeout period has elapsed, the BIG-IP system attempts to generate traffic by issuing ARP requests to nodes accessible through the VLAN. The BIG-IP system also generates an ARP request for the default route, if the default router is accessible from the VLAN. Failover is averted if the BIG-IP system is able to send and receive any traffic on the VLAN, including a response to its ARP request.
For a redundant system configuration, if the BIG-IP system does not receive traffic on the VLAN before the timeout period expires, the system can initiate failover and switch control to the standby unit, reboot, or restart all system services. The default action is Reboot.
Warning: You should configure the fail-safe option on a VLAN only after the BIG-IP system is in a stable production environment. Otherwise, routine network changes might cause failover unnecessarily.
Each interface card installed on the BIG-IP system is typically mapped to a different VLAN. Thus, when you set the fail-safe option on a particular VLAN, you need to know the interface to which the VLAN is mapped. You can use the Configuration utility to view VLAN names and their associated interfaces.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Fail-safe menu, choose VLANs.
The VLAN Fail-safe screen opens.
3.
4.
From the VLAN list, select a VLAN name.
5.
In the Timeout box, specify the period of time during which traffic should be detected on the VLAN, after which the designated action occurs.
The default value, in seconds, is 90.
6.
From the Action list, select the action that the BIG-IP system should take when the timeout period expires.
7.
Click Finished.
1.
On the Main tab of the navigation screen, expand Network, and click VLANs.
The VLANs list screen opens.
3.
From the Configuration list, select Advanced.
4.
In the Fail-safe setting, check the box.
This shows additional settings.
5.
In the Fail-safe Timeout box, specify the period of time during which traffic should be detected on the VLAN, after which the designated action occurs.
The default value, in seconds, is 90.
6.
From the Action list, select the action that the BIG-IP system should take when the timeout period expires.
7.
Click Update or Finished.
In the section titled Before you begin, you learned how to use the Configuration utility to configure a redundant system. After you have configured your redundant system and put it into service, however, you can perform a number of tasks on a regular basis to keep the system up and running properly. These tasks are:
You can view the current redundancy state of a unit at any time. You can also view synchronization status, but only if you have configured the unit to do so.
Each unit in a redundant system is in either an active or a standby state at any given time. The current state of a unit depends on the units redundancy state preference, and whether the unit is available or unavailable to accept connections. To view the redundancy state of a BIG-IP unit, check the status display that appears in the upper-left corner of every Configuration utility screen
As you learned in Synchronizing configuration data, it is essential that an active unit share its current configuration data with its peer to ensure that failover can occur successfully. Configuration data on a unit can change for a variety of reasons (such as when adding a virtual server or modifying a profile), so it is important that you be able to monitor synchronization status at any given time, and re-synchronize the units if necessary.
You can view either detailed synchronization information about the current unit and its peer, or you can view general synchronization status on every Configuration utility screen.
You can view detailed configuration synchronization status, such as the internal static self IP addresses that the two units use when synchronizing data, by displaying the ConfigSync screen of the Configuration utility. This screen is available from the Redundancy Properties screen.
Table 20.7 lists and describes the status-related settings that the ConfigSync screen displays.
Displays the internal static self IP address that the BIG-IP system uses to determine the peer unit for synchronization.
Displays the state of the peer, that is, active or standby. May also report the status as unknown if connectivity problems exist.
Displays the day, date, and exact time that the configuration data of the unit you are configuring was last changed.
Displays the day, date, and exact time that the configuration data of the peer unit was last changed.
Displays the day, date, and exact time that a user synchronized the configuration data between the two units.
Tip: You can also display this detailed status information by enabling the auto detection feature and then clicking on the resulting synchronization status in the upper-left corner of the Configuration utility. For more information, see Viewing general synchronization status, following.
The BIG-IP system can display general synchronization status in the upper-left corner of every Configuration utility screen. To use this feature, you must first enable the feature that automatically detects synchronization status. For more information on how to enable this feature, see Performing Configuration Synchronization.
Once you have enabled the automatic status detection feature, the status that the Configuration utility displays indicates whether or not you need to synchronize the configurations of the two units due to changes that you might have made to the configuration data. For example, if you change the redundancy preference of unit 2, you must then synchronize the configuration so that both units are aware of the change.
ConfigSync: OK (green circular arrow)
No synchronization required
Sync Recommended (orange/yellow circular arrow)
Synchronize to or from the peer
Sync Recommended (gray/white circular arrow)
Manual intervention recommended
Unknown sync state (gray/white circular arrow)
State of unit is unknown due to loss of peer connection
Tip: You can view more detailed synchronization information by clicking the synchronization status that is displayed in the upper-right corner of every Configuration utility screen. You can also view this detailed information by displaying the ConfigSync screen within the Configuration utility. For more information, see Viewing detailed synchronization status.
During normal operation, a BIG-IP unit of a redundant pair is in either an Active or a Standby state. The state of a unit depends on the state of the peer unit, as well as the redundancy preference that you configured for the unit.
Besides being in an Active or Standby state, however, a BIG-IP unit can be in an Offline state. A BIG-IP unit enters an Offline state when you actively force the unit offline. The Offline state indicates to both units that the offline unit is unavailable for accepting network traffic. This feature is useful when you need to take an active unit out of service in order to perform standard system maintenance tasks on that unit.
For active/standby configurations, the forcing of the active unit to a Standby or an Offline state causes its connections to fail over to the peer unit, and the normally-idle peer unit becomes active.
When a unit is in an Offline state, the unit cannot return to an Active or Standby state until you actively release it from the Offline state.
To put a BIG-IP unit into, or release a unit from, an Offline state, you can use the buttons on the High Availability screen that displays the redundancy properties of a unit. From this screen, you can also force a unit into a Standby state. The available buttons are:
Force to Standby
Forces the BIG-IP unit into the OFFLINE state until the peer becomes active. The state then switches from OFFLINE to STANDBY. For more information, see To force a BIG-IP unit to the STANDBY or OFFLINE state, following.
Force Offline
Forces the BIG-IP unit into the FORCED_OFFLINE state. In this state, the unit is unable to accept network traffic.
Release Offline
Releases the BIG-IP unit from being in the FORCED_OFFLINE state. When you release a unit from being forced offline, the unit temporarily changes to the OFFLINE state, and then to either the ACTIVE or STANDBY state, depending on whether the peer unit becomes active.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
Click the Force to Standby button.
The unit switches to the OFFLINE state and is unavailable to accept traffic until you release the unit from the FORCED_OFFLINE state.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
Click the Release Offline button.
If a unit of a redundant system configuration suddenly go into the Offline state, you can use the bigpipe utility to diagnose the problem. The following commands provide useful troubleshooting information:
bigpipe ha table
Displays the contents of the HA table, in friendly format.
bigpipe ha table show all
Displays the contents of the HA table, in verbose format.
bigpipe ha table failures
Displays information about system failures only.
For more information on these commands, see the Bigpipe Utility Reference Guide.
Sometimes, you might need to know the unit ID assigned to a BIG-IP unit. A typical reason for needing this information is if you are configuring a second BIG-IP unit to be part of a redundant system and want to know the unit ID of the existing redundant-system unit.
The Unit ID setting on the Redundancy Properties screen indicates whether a system is designated as unit 1 or unit 2 in the redundant system configuration.
You assign a unit ID to a unit of a redundant system at the time that you initially run the Setup utility on one of the BIG-IP units. For more information, see Before you begin.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
Locate the Unit ID setting and view the unit ID number.
Failback is the process of a previously-unavailable unit reclaiming its normal traffic when the unit returns to an active state. When failback occurs in either an active/standby configuration, the BIG-IP system drops any connections that had previously failed over to the peer unit, unless you configured the relevant virtual server or SNAT to mirror those connections.
Tip: The upper-left corner of the Configuration utility screens continually reports the state of the redundant-system unit that you are currently managing (active or standby). For more information, see Viewing redundancy state
In a typical active/standby configuration, where no preference is set for which unit is active, failback is not automatic. If unit 1 fails over to unit 2 and later becomes available again, unit 1 remains in a standby state and unit 2 continues to process the traffic, unless you specifically initiate failback or failover occurs again. In the latter case, unit 2 fails over to unit 1.
You normally initiate failback by forcing the currently-active unit into a standby state. When you initiate 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 or SNAT.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
As an option, you can set a state preference for a particular unit. Setting this preference automates the failback process. For example, if you specify that you prefer unit 1 to be the active unit whenever possible, then automatic failback to unit 1 occurs as soon as possible after a failover to unit 2. Automatic failback also occurs if you specify that you prefer unit 2 to be the standby unit. For information on setting a state preferences see Specifying the link down-time on failover.
If connection mirroring is enabled and then failback occurs, connection re-mirroring can only occur when the virtual server processing the connections is a Performance (Layer 4) type of virtual server. This type of virtual server is one that references a Fast L4 type of protocol profile.
Re-mirroring on failback does not occur when the virtual server type is Standard or Performance (HTTP), both of which reference a TCP type of protocol profile. This is true regardless of whether the virtual server is processing any Layer 7 connections (such as HTTP connections).
You might want the system to perform some maintenance tasks on either the active or the standby system, or both, immediately after failover has occurred. To configure the BIG-IP system to automatically perform these tasks, you can use a text editor to manually edit two scripts named active and standby. You can find these files on the BIG-IP system in the /config/failover directory.
The purpose of these scripts is to automatically run short, non-persistent system maintenance tasks after failover. For example, you can edit the active script to read the ARP table on the newly-active unit, to remove an erroneous entry that might appear as a result of failover.
Important: Two additional scripts, named f5active and f5standby, are located in the directory /usr/lib/failover. Do not edit these scripts unless an F5 Networks customer service representative instructs you to do so.
Once you have used the Redundancy Properties screen of the Configuration utility to configure various settings on each unit, you can perform the next task, configuring the default route on each back-end server. (For a high-level summary of tasks, see Before you begin.)
Tip: For any back-end server that receives requests from a unit of a redundant system, you do not need to perform this step if the relevant virtual server is associated with a SNAT.
When failover occurs on a BIG-IP system, the surviving BIG-IP unit begins handling the inbound virtual server connections (those targeted to back-end servers) that are normally processed by the failed unit, and begins handling the outbound connections (those originating from back-end servers) that are normally destined for the failed BIG-IP unit.
For a redundant system to do this properly, you need to set the default route for each back-end server to the shared, floating IP address assigned to the BIG-IP unit that normally processes the servers responses. This ensures that the back-end server can successfully send a response to the surviving BIG-IP unit.
For example, for an active/standby configuration, if the server http_server normally receives connections from unit 1 of your redundant system, and the floating IP address shared by the two units is 11.12.11.3, you must set the default route for server http_server to 11.12.11.3. Then, if unit 1 goes out of service, the surviving unit (unit 2) can receive the servers response because the IP address 11.12.11.3 is a shared IP address.
A floating self IP address is an IP address that is shared between two systems, or between two units of a redundant system. When you run the Setup utility, you normally assign a floating IP address to VLAN internal and VLAN external of each unit (in addition to assigning a static self IP address).
Normally, for non-redundant systems (that is, single devices), it is a VLANs static self IP address that appears as the source IP address in the header of a TCP packet going from a BIG-IP device to a back-end server. This causes the back-end server to send its response to that static self IP address. If the BIG-IP system becomes unavailable, the system fails to receive the response.
With a redundant system, however, you can configure the back-end servers to send their responses to a shared floating IP address instead of a static self IP address, and if the target unit is unavailable, the peer unit can receive and process that traffic. Without this shared floating IP address, the delivery of back-end server traffic to the surviving BIG-IP unit would fail.
For an active/standby system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 as the internal floating IP address, and when you ran Setup on unit 2, you also specified 11.12.11.3 as its internal floating IP address. When you synchronize the configurations later, 11.12.11.3 should appear on both units as the floating IP address belonging to 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, even though this incoming traffic is now processed by unit 2.
For active/standby systems only, you can share the media access control (MAC) masquerade address between BIG-IP units. This feature is useful if you want to use the system in a topology with secure hubs. Sharing the MAC masquerade address between units has the following advantages:
A BIG-IP unit uses the shared MAC address when it is the active unit in a redundant system. When the unit is in a standby state, the system uses the actual MAC address of the interface. Note that this option is valid only for active/standby mode.
Note: As a best practice, you should set the MAC masquerade address to be the same on both the active and standby units. Only users with either the Administrator or Resource Administrator user role can set a MAC masquerade address.
The MAC address for a VLAN is the MAC address of the first interface to be mapped to the VLAN, typically 1.1 for external and 1.2 for internal. You can view the interfaces mapped to a VLAN using the Configuration utility.
1.
On the Main tab of the navigation pane, expand Network, and click VLANs.
The VLANs list screen opens.
1.
On the Main tab of the navigation pane, expand Network, and click Interfaces.
The Interfaces list screen opens.
The first step in designating a MAC masquerade address that the redundant units can share is to find the MAC address on both the active and standby units, and choose an address that is similar but unique. A safe technique for selecting the shared MAC address follows.
Suppose you want to set up a MAC masquerade on the external interfaces. Using the Configuration utility on the active and standby units, you note that their MAC addresses are:
To avoid packet collisions, you now must choose a unique MAC address. The safest way to do this is to select one of the addresses and logically OR the first byte with 0x40. This makes the MAC address a locally-administered MAC address.
In this example, either 40:0:0:ac:4c:a2 or 40:0:0:ad:4d:f3 is a suitable shared MAC address to use on both BIG-IP units in the redundant system.
The shared MAC address is used only when the BIG-IP system is in active mode. When the unit is in a standby state, the original MAC address of the network card is used.
Use the following procedure to set the MAC masquerade address that is shared by both BIG-IP units in the redundant system.
1.
On the Main tab of the navigation pane, expand Network, and click VLANs.
The VLANs list screen opens.
2.
Click a VLAN name.
The properties screen for that VLAN opens.
3.
From the Configuration list, select Advanced.
This displays the MAC address for the first interface added to the VLAN, as well as a box for designating the MAC masquerade address.
5.
Click Update.
If you do not configure a MAC masquerade address on startup, or when transitioning from a standby state to an active state, the BIG-IP system sends gratuitous ARP requests to notify the default router and other machines on the local Ethernet segment that its MAC address has changed. See RFC 826 for more details on ARP.
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)