What's Unit ID

Version 4.X says :

Local.Bigip.Failover.UnitId
This key is required. Each BIG-IP system must have a unique unit ID of 1 or 2 in the event that network communication is not possible with its peer.

[http://support.f5.com/kb/en-us/archived_products/big-ip/manuals/product/bigip4_6_2ref/bigip_ApxKeys.print.html]



Version 11.X

http://support.f5.com/kb/en-us/solutions/public/11000/200/sol11215.html

Overview

Note: For information about upgrading an active-active BIG-IP high availability pair, refer to SOL12157: Upgrading an active-active BIG-IP high availability pair.

An active/standby BIG-IP high availability pair consists of two systems: one operating in active mode, and one operating in standby mode. In the event that the active system fails, the standby unit automatically becomes active.
BIG-IP systems in an active/standby high availability pair determine their operating mode (active/standby) based on heartbeat detection. As part of setting up an active/standby BIG-IP high availability pair, an administrator must choose between the following failover mechanisms (how the systems will exchange the heartbeats):

• Serial cable failover (also known as hardware failover)
• Network failover

Note: Serial cable failover is always enabled and cannot be disabled by a BIG-IP system administrator. If an active/standby BIG-IP high availability pair is configured to use network failover, and the serial failover cable also connects the two units, serial cable failover will always have precedence. For example, if network failover traffic is compromised, the two units will not fail over because the serial failover cable is still connecting them. If the two BIG-IP units are located close enough to use serial cable failover, that is the recommended choice; network failover in addition to serial cable failover is redundant.

Regardless of the failover mechanism being used, BIG-IP systems in an active/standby high availability pair communicate with each other over the network to exchange information required by the following features:

• Connection mirroring
• Persistence mirroring

Note: When upgrading BIG-IP systems that are configured to perform connection mirroring or persistence mirroring, if you are upgrading to a software version that is incompatible with the mirroring protocol used by the old software version, eligible connection and persistence records will not be mirrored to the peer system until you have upgraded both systems.

Prerequisites to upgrading

Before proceeding, F5 recommends that you read the following articles:
SOL2397: Comparison of serial failover and network failover features
SOL9057: Overview of the BIG-IP LTM network failover protocol
SOL7225: Overview of the BIG-IP LTM mirroring transport protocol
SOL7222: Overview of connection and persistence mirroring
SOL8184: Overview of the Redundancy State Preference setting
SOL8665: BIG-IP redundant pair hardware and software parity requirements
SOL11939: Configuring network failover for redundant VIPRION systems
When an active/standby BIG-IP high availability pair is upgraded to a new software version, the upgrade procedure will vary slightly depending on whether serial cable failover or network failover is used. The standard upgrade procedure calls for upgrading one system in the high availability pair while the peer system temporarily runs the older version. When network failover is used, a BIG-IP system administrator must consider whether:

• The new software version will use the same transport protocol and port for network failover as the old software version
• The network failover payload of the new software version will be compatible with that of the old software version

If during the upgrade procedure the systems in the active/standby high availability pair are running BIG-IP versions that do not meet these requirements, network failover will not function. This behavior usually results in an active-active situation and ultimately in traffic disruption.
The network failover payload of a BIG-IP system is likely to be incompatible with that of another BIG-IP system running a new major or minor release. This is because when a new software version introduces enhancements to the network failover feature, the network failover payload is also likely to change. For example, although BIG-IP version 9.4.8 and BIG-IP version 10.0.0 use the same network failover transport protocol and port (UDP port 1026), their network failover payloads are different and incompatible.
The aim of this Solution is to provide an upgrade procedure that will result in zero or minimum traffic disruption. To upgrade an active/standby BIG-IP high availability pair, perform one of the following procedures:

Important: F5 does not support high availability pair configurations in which each system is running a different software version, because this configuration may affect certain functionalities, such as network failover traffic. However, when you follow the standard upgrade procedure, and you upgrade one unit in the high availability pair while the peer system temporarily runs the older version, systems running different but very close maintenance releases are likely to use the same network failover protocol and payload. Systems running different major or minor releases may use a different network failover protocol or payload, causing network failover to cease functioning. F5 recommends that you upgrade BIG-IP high availability pairs that are configured with network failover by performing one of the following Upgrading an active/standby BIG-IP high availability pair configured with network failover procedures. For more information about the F5 software versioning schema, refer to SOL8986: F5 software life cycle policy.

Important: If the active/standby BIG-IP high availability pair being upgraded uses both serial cable failover and network failover, perform the Upgrading an active/standby BIG-IP high availability pair configured with serial cable failover procedure.

• Upgrading an active/standby BIG-IP high availability pair configured with serial cable failover
• Upgrading an active/standby BIG-IP high availability pair in which network failover is configured to use a TMM interface
  
• Upgrading an active/standby BIG-IP high availability pair in which network failover is configured to use the management interface
  

Note: F5 strongly recommends that you have a serial console connection open to each unit for the duration of the upgrade. This action allows you to follow an installation through all of its stages, making it possible to detect any errors or premature interruptions of the installation process.

Note: Customer configurations and environments vary. Therefore, F5 recommends testing the upgrade procedure in a test environment first, and then upgrading the production units during a designated maintenance window.

Note: In the following procedures, F5 assumes that at the time of the upgrade, Unit ID 1 will be active and Unit ID 2 will be standby.

Upgrading an active/standby BIG-IP high availability pair configured with serial cable failover

 

The following procedure assumes that you are upgrading a BIG-IP HA pair that is configured to use serial cable failover, or a combination of serial failover and network failover.

1. Read the release notes and any known issue articles for the BIG-IP version to which you are upgrading.
2. Reactivate the license of both units. You can use the Configuration utility to reactivate a system's license; to do so, navigate to System, License, and click Re-activate.
   Note: For more information about why this step is required, refer to SOL7727: A service check date that is earlier than the license check date now requires you to relicense the system before upgrading.
3. Temporarily disable VLAN failsafe and gateway failsafe on both units so that failover actions do not interrupt the upgrade procedure.
   Note: For more information about configuring VLAN failsafe and gateway failsafe, refer to the BIG-IP Network and System Management Guide.
4. Temporarily set the Redundancy State Preference setting of both units to None. This action ensures that the BIG-IP systems will not swap roles unnecessarily during the procedure. For more information on how to configure this setting, refer to: SOL8184: Overview of the Redundancy State Preference setting.
5. Create a UCS backup of each unit by running the following command:
   bigpipe config save /config.ucs
   Note: For more information about UCS archives, refer to SOL4423: Overview of UCS archives and SOL10245: BIG-IP UCS installation and licensing behavior.
6. Copy the UCS archives off the units to a safe location on the network.
7. If you are performing the upgrade using an Enterprise Manager, skip to Step 7.
   
   Copy the software image and its associated MD5 to both units, and verify the integrity of each image against its MD5.
8. Launch the install on Unit ID 2. For specific instructions, refer to the release notes of the software version you are installing.
   
   Once the installation has completed and the BIG-IP system has rebooted, Unit ID 2 will set itself as standby.
9. Confirm that Unit ID 2 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
10. If the BIG-IP systems are configured to perform connection mirroring or persistence mirroring, and if you are upgrading to a software version that is compatible with the mirroring protocol used by the old software version, wait until eligible connections and persistence records are repopulated on Unit ID 2. If you are upgrading to a software version that is incompatible with the mirroring protocol used by the old software version, eligible connections and persistence records will not be repopulated on Unit ID 2.
    Note: You can list all current connections and persistence records by entering the following commands from the command line:
    bigpipe conn show all
    bigpipe persist show all
11. Manually fail over to Unit ID 2 using either the Configuration utility or issuing the bigpipe failover standby command from the command line of Unit ID 1, and confirm that Unit ID 2 is successfully passing traffic.
    
    Do not fail over to Unit ID 2 by rebooting Unit ID 1; doing so may not work as intended, because at this stage the two systems are running different software versions. 
    Note: If any issues occur during this test, gather all appropriate data (for example, qkviews, full logs, traffic captures, and core files), and contact F5 Technical Support before rebooting the unit into the previous software version.
12. Launch the install on Unit ID 1, which is now standby.
    
    Once the installation has completed and Unit ID 1 has rebooted, confirm that the system remains standby.
    
13. Confirm that Unit ID 1 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
14. If you want, reconfigure the Redundancy State Preference setting of the two units to meet your needs.

Upgrading an active/standby BIG-IP high availability pair in which network failover is configured to use a TMM interface

 

The following procedure assumes that you are upgrading a BIG-IP HA pair in which network failover is configured to communicate over a TMM interface.

1. Read the release notes and any known issue Solutions for the BIG-IP version to which you are upgrading.
2. Reactivate the license of both units. You can use the Configuration utility to reactivate a system's license; to do so, navigate to System, License, and click Re-activate.
   Note: For more information about why this step is required, refer to SOL7727: A service check date that is earlier than the license check date now requires you to relicense the system before upgrading.
3. Temporarily disable VLAN failsafe and gateway failsafe on both units so that failover actions do not interrupt the upgrade procedure.
   Note: For more information about configuring VLAN failsafe and gateway failsafe, refer to the BIG-IP Network and System Management Guide.
4. Temporarily set the Redundancy State Preference setting of both units to None. This action ensures that the BIG-IP systems will not swap roles unnecessarily during the procedure. For more information on how to configure this setting, refer to: SOL8184: Overview of the Redundancy State Preference setting.
5. Create a UCS backup of each unit by running the following command:
   bigpipe config save /config.ucs
   Note: For more information about UCS archives, refer to SOL4423: Overview of UCS archives and SOL10245: BIG-IP UCS installation and licensing behavior.
6. Copy the UCS archives off the units to a safe location on the network.
7. If you are performing the upgrade using an Enterprise Manager, skip to Step 8.
   
   Copy the software image and its associated MD5 to both units, and verify the integrity of the image against its MD5. 
8. On Unit ID 2, disconnect all network cables except that of the management interface. Alternatively, you may shut down the interfaces on the upstream device(s).
   Important: If the BIG-IP systems are configured to use multiple interfaces, ensure that the interfaces used by the network failover feature are disconnected/shut down last (this will prevent the unit from going active while a traffic facing interface is still up).
   Note: At this point, Unit ID 2 will become active (as it is no longer receiving the heartbeats from Unit ID 1), and you will have an active-active situation. However, as Unit ID 2 will effectively be isolated from the network, this situation will not result in any traffic disruption. Unit ID 1 will continue serving traffic as expected.
9. Launch the install on Unit ID 2. For specific instructions, refer to the release notes of the software version you are installing.
   Note: Once the installation has completed and the BIG-IP system has rebooted, Unit ID 2 will set itself as active, as it is still isolated from its peer.
10. Confirm that Unit ID 2 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
    
    Important: Steps 11 through 13 will temporarily disrupt traffic as you transition the traffic to the newly upgraded Unit ID 2. Complete these steps as quickly as possible to minimize the downtime.
11. On Unit ID 1, disconnect all network cables except that of the management interface. Alternatively, you may shut down the interfaces on the upstream device(s).
    Important: Upon execution of this step, both units will be isolated from the network and all traffic will be temporarily stopped until Step 13 is completed.
12. Reconnect all network cables to Unit ID 2 (or re-enable the relative interfaces on the upstream devices).
13. Flush the L2 databases on the upstream devices so they will now begin forwarding traffic to Unit ID 2 instead.
    Note: If for some reason you are unable to flush the L2 databases on the upstream devices, you may trigger Unit ID 2 to send another round of gratuitous ARPs by forcing a standby/active transition. On Unit ID 2, trigger a failover manually, either through the Configuration utility or by issuing the bigpipe failover standby command from the command line. As Unit ID 2 notices its peer is not available, it will transition to active again. This transition will result in Unit ID 2 sending another round of gratuitous ARPs to help send traffic to the unit with new software.
14. Confirm that Unit ID 2 is successfully passing traffic.
    Note: If any issues occur during this test, gather all appropriate data (for example, qkviews, full logs, traffic captures, and core files) and contact
    F5 Technical Support before rebooting the unit into the previous software version.
15. Launch the install on Unit ID 1.
    
    Once the installation has completed and the BIG-IP system has rebooted, Unit ID 1 will set itself as active, as it is still isolated from its peer.
16. Confirm that Unit ID 1 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
    Note: If you do not complete Steps 17 through 19 and you bring the interfaces of Unit ID 1 back up while the system is online and active, you will experience an active-active situation. If the Redundancy State Preference setting of the systems is set to None, Unit ID 1 will remain active and Unit ID 2 will become standby. To avoid this additional transition, perform Steps 17 through 19.
17. On Unit ID 1, stop all services by entering the following command from the command line:
    bigstart stop
    Important: If you are upgrading a VIPRION platform, enter the clsh bigstart stop command instead. This command is the equivalent of running bigstart stop on every blade.
18. Reconnect all network cables to Unit ID 1 (or re-enable the relative interfaces on the upstream devices).
19. On Unit ID 1, start all services by entering the following command from the command line:
    bigstart start
    Important: If you are upgrading a VIPRION platform, enter the clsh bigstart start command instead. This command is the equivalent of running bigstart start on every blade.
    Unit ID 1 will come online and set itself standby.
    
    Important: If Unit ID 1 sets itself active, disconnect all network cables from the device and verify that the old configuration was successfully imported and that no errors are returned.
    
20. Once both units have been successfully upgraded and tested, you may re-enable VLAN failsafe and gateway failsafe if any were disabled in Step 3 of this procedure.
21. If you want to, reconfigure the Redundancy State Preference setting of the two units to meet your needs.

Upgrading an active/standby BIG-IP high availability pair in which network failover is configured to use the management interface

 

The following procedure assumes that you are upgrading a BIG-IP HA pair in which network failover is configured to communicate over the management (MGMT) interface.

1. Read the release notes and any known issue Solutions for the BIG-IP version you are upgrading to.
2. Reactivate the license of both units. You can use the Configuration utility to reactivate a system's license; to do so, navigate to System, License, and click Re-activate.
   Note: For more information about why this step is required, refer to SOL7727: A service check date that is earlier than the license check date now requires you to relicense the system before upgrading.
3. Temporarily disable VLAN failsafe and gateway failsafe on both units so that failover actions do not interrupt the upgrade procedure.
   Note: For more information about configuring VLAN failsafe and gateway failsafe, refer to the BIG-IP Network and System Management Guide.
4. Temporarily set the Redundancy State Preference setting of both units to None. This action ensures that the BIG-IP systems will not swap roles unnecessarily during the procedure.
   Note: For more information about configuring this setting, refer to: SOL8184: Overview of the Redundancy State Preference setting.
5. Create a UCS backup of each unit by running the following command:
   bigpipe config save /config.ucs
   Note: For more information about UCS archives, refer to SOL4423: Overview of UCS archives and SOL10245: BIG-IP UCS installation and licensing behavior.
6. Copy the UCS archives off the units to a safe location on the network.
7. If you are performing the upgrade using an Enterprise Manager, skip to Step 8.
   
   Copy the software image and its associated MD5 to both units, and verify the integrity of the image against its MD5. 
8. On Unit ID 2, disconnect all network cables except that of the management interface. Alternatively, you may shut down the interfaces on the upstream device(s).
   Note: Unit ID 2 remains standby because the two units are still exchanging heartbeats over the management network.
9. Launch the install on Unit ID 2. For specific instructions, refer to the release notes of the software version you are installing.
   Note: Once the installation has completed and the BIG-IP system has rebooted, the status of Unit ID 2 will depend on whether the network failover protocol and payload of the two BIG-IP versions are compatible. If they are compatible, Unit ID 2 will set itself as standby; if they are not compatible, Unit ID 2 will set itself as active.
   
   If after upgrading Unit ID 2 the two units are active/standby, proceed to the High availability protocols are compatible procedure.
   
   If after upgrading Unit ID 2 the two units are active-active, proceed to the High availability protocols are not compatible procedure.
   
   In either case, Unit ID 2 will be isolated from the network.

High availability protocols are compatible

1. Confirm that Unit ID 2 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
2. Reconnect all network cables to Unit ID 2 (or re-enable the relative interfaces on the upstream devices).
3. If the BIG-IP systems are configured to perform connection mirroring and/or persistence mirroring, and if you are upgrading to a software version that is compatible with the mirroring protocol used by the old software version, wait until eligible connections and persistence records are repopulated on Unit ID 2. If you are upgrading to a software version that is incompatible with the mirroring protocol used by the old software version, eligible connections and persistence records will not be repopulated on Unit ID 2.
   Note: You can list all current connections and persistence records by entering the following commands from the command line:
   bigpipe conn show all
   bigpipe persist show all
4. Manually fail over to Unit ID 2 using either the Configuration utility or issuing the bigpipe failover standby command from the command line of Unit ID 1, and confirm that Unit ID 2 is successfully passing traffic.
   Note: If any issues occur during this test, gather all appropriate data (for example, qkviews, full logs, traffic captures, and core files), and contact F5 Technical Support before rebooting the unit into the previous software version.
5. Launch the install on Unit ID 1, which is now standby.
   Note: Once the installation has completed and Unit ID 1 has rebooted, the system will remain standby.
6. Confirm that Unit ID 1 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
7. Once both units have been successfully upgraded and tested, you may re-enable VLAN failsafe and gateway failsafe if any were disabled.
8. If you want to, reconfigure the Redundancy State Preference setting of the two units to meet your needs.

High availability protocols are not compatible

1. Confirm that Unit ID 2 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
   Note: Steps 2 through 4 will transition traffic to the newly-upgraded Unit ID 2. Complete these steps as quickly as possible to minimize the downtime.
2. On Unit ID 1, disconnect all network cables except that of the management interface. Alternatively, you may shut down the interfaces on the upstream devices.
   Important: Upon execution of this step, both units are isolated from the network and all traffic is temporarily stopped until Step 4 is completed.
3. Reconnect all network cables to Unit ID 2 (or re-enable the relative interfaces on the upstream devices.
4. Flush the L2 databases on the upstream devices so they will now begin forwarding traffic to Unit ID 2 instead.
   Note: If for some reason you are unable to flush the L2 databases on the upstream devices, you may trigger Unit ID 2 to send another round of gratuitous ARPs by forcing a standby/active transition. On Unit ID 2, trigger a failover manually, either through the Configuration utility or by issuing the bigpipe failover standby command from the command line. As Unit ID 2 notices its peer is not available, it will transition to active again. This transition will result in Unit ID 2 sending another round of gratuitous ARPs to help send traffic to the unit with new software.
5. Confirm that Unit ID 2 is successfully passing traffic.
   Note: If any issues occur during this test, gather all appropriate data (for example, qkviews, full logs, traffic captures, and core files) and contact
   F5 Technical Support before rebooting the unit into the previous software version.
6. Launch the install on Unit ID 1.
   Note: Once the installation has completed and the BIG-IP system has rebooted, Unit ID 1 will set itself as standby because the two BIG-IP systems are now running the same software version.
7. Confirm that Unit ID 1 has successfully imported the old configuration and that no errors are returned when you issue the bigpipe load command from the command line.
8. Reconnect all network cables to Unit ID 1 (or re-enable the relative interfaces on the upstream devices).
9. Once both units have been successfully upgraded and tested, you may re-enable VLAN failsafe and gateway failsafe if any were disabled.
10. If you want to, reconfigure the Redundancy State Preference setting of the two units to meet your needs.