Wednesday, January 30, 2013

Checking monitor page


========
CURL
========
We can try testing an HTTP pool member using curl, netcat or other tools like telnet. Let's try curl as it forms a majority of the request for us. The -v flag

curl -v http://10.41.0.21:80/monitor_page.html

curl -kv http://10.41.0.21:80/monitor_page.html

  • -v - print verbose output (includes request and response HTTP headers)

For HTTPS servers, add the -k flag to ignore cert validation errors


=========================================

If you didn't  save the file in pcap by -w pcap than u can save it by editcap -F

=============================================
============================================= 

Also if its https then its better to login into pool member/generic host via openssl and then entering monitor.

openssl s_client -connect 171.182.199.19:4025

============================================== 
==============================================



=======
TCPDUMP
=======

https://devcentral.f5.com/wiki/advdesignconfig.troubleshootingltmmonitors.ashx

We can use tcpdump to see what response is being sent and received to and from the pool member. We use some specific flags to configure the output:

  • -nn - don't attempt to convert IP addresses to hostnames or ports to service names
  • -X - print hex and ascii output
  • -s0 - don't limit the snap length (packet size) captured

tcpdump -nni 0.0 -X -s0 host 10.41.0.21 and port 80 and host 10.41.1.3 -w test.pcap


To filter the traffic, we use the pool member IP address, port and the non-floating self IP that the monitor requests will be sent from.

===================================================================


If you want to know something more about editcap go to link below.


http://www.softpanorama.org/Net/Netutils/Sniffers/editcap.shtml#F_flag


Introduction

editcap [ -c <packets per file> ] [ -C <choplen> ] [ -E <error probability> ] [ -F <file format> ] [ -A <start time> ] [ -B <stop time> ] [ -h ] [ -r ] [ -s <snaplen> ] [ -t <time adjustment> ] [ -T <encapsulation type> ] [ -v ] infile  outfile  [ packet#[-packet#] ... ]



Editcap is a filter that reads some or all of the captured packets from the infile, optionally converts them in various ways and writes the resulting packets to the capture outfile  (or outfiles).

By default, it reads all packets from the infile  and writes them to the outfile  in libpcap file format.

A list of packet numbers can be specified on the command line; ranges of packet numbers can be specified as start-end, referring to all packets from start  to end. The selected packets with those numbers will not  be written to the capture file. If the -r flag is specified, the whole packet selection is reversed; in that case only  the selected packets will be written to the capture file.

Editcap is able to detect, read and write the same capture files that are supported by Ethereal. The input file doesn't need a specific filename extension, the file format and an optional gzip compression will be automatically detected. The capture file format  section of ethereal(1)  or http://www.ethereal.com/docs/man-pages/ethereal.1.html  provides a detailed description.

Editcap can write the file in several output formats. The -F flag can be used to specify the format in which to write the capture file, editcap -F provides a list of the available output formats.

OPTIONS

-c <packets per file>
Sets the maximum number of packets per output file. Each output file will be created with a suffix -nnnnn, starting with 00000. If the specified number of packets are written to the output file, the next output file is opened. The default is to use a single output file.
-C <choplen>
Sets the chop length to use when writing the packet data. Each packet is chopped at the packet end by a few <choplen> bytes of data.
This is useful in the rare case that the conversion between two file formats leaves some random bytes at the end of each packet.

-E <error probability>
Sets the probabilty that bytes in the output file are randomly changed. Editcap uses that probability (between 0.0 and 1.0 inclusive) to apply errors to each data byte in the file. For instance, a probability of 0.02 means that each byte has a 2% chance of having an error.
This option is meant to be used for fuzz-testing protocol dissectors.

-F <file format>
Sets the file format of the output capture file. Editcap can write the file in several formats, editcap -F provides a list of the available output formats. The default is the libpcap format.
-A <start time>
Saves only the packets whose timestamp is on or after start time. The time is given in the following format YYYY-MM-DD HH:MM:SS
-B <stop time>
Saves only the packets whose timestamp is on or before stop time. The time is given in the following format YYYY-MM-DD HH:MM:SS
-h
Prints the version and options and exits.
-r
Reverse the packet selection. Causes the packets whose packet numbers are specified on the command line to be written to the output capture file, instead of discarding them.
-s <snaplen>
Sets the snapshot length to use when writing the data. If the -s flag is used to specify a snapshot length, packets in the input file with more captured data than the specified snapshot length will have only the amount of data specified by the snapshot length written to the output file.
This may be useful if the program that is to read the output file cannot handle packets larger than a certain size (for example, the versions of snoop in Solaris 2.5.1 and Solaris 2.6 appear to reject Ethernet packets larger than the standard Ethernet MTU, making them incapable of handling gigabit Ethernet captures if jumbo packets were used).

-t <time adjustment>
Sets the time adjustment to use on selected packets. If the -t flag is used to specify a time adjustment, the specified adjustment will be applied to all selected packets in the capture file. The adjustment is specified as [-]seconds[.fractional seconds]. For example, -t 3600 advances the timestamp on selected packets by one hour while -t -0.5 reduces the timestamp on selected packets by one-half second.
This feature is useful when synchronizing dumps collected on different machines where the time difference between the two machines is known or can be estimated.

-T <encapsulation type>
Sets the packet encapsulation type of the output capture file. If the -T flag is used to specify an encapsulation type, the encapsulation type of the output capture file will be forced to the specified type. editcap -T provides a list of the available types. The default type is the one appropriate to the encapsulation type of the input capture file.
Note: this merely forces the encapsulation type of the output file to be the specified type; the packet headers of the packets will not be translated from the encapsulation type of the input capture file to the specified encapsulation type (for example, it will not translate an Ethernet capture to an FDDI capture if an Ethernet capture is read and '-T fddi' is specified).

-v
Causes editcap to print verbose messages while it's working.
Examples

To see more detailed description of the options use:

    editcap -h
To shrink the capture file by truncating the packets at 64 bytes and writing it as Sun snoop file use:

    editcap -s 64 -F snoop capture.pcap shortcapture.snoop
To delete packet 1000 from the capture file use:

    editcap capture.pcap sans1000.pcap 1000
To limit a capture file to packets from number 200 to 750 (inclusive) use:

    editcap -r capture.pcap small.pcap 200-750
To get all packets from number 1-500 (inclusive) use:

    editcap -r capture.pcap 500.pcap 1-500
or

    editcap capture.pcap 500.pcap 501-9999999
To filter out packets 10 to 20 and 30 to 40 into a new file use:

    editcap capture.pcap selection.pcap 10-20 30-40
To introduce 5% random errors in a capture file use:

  editcap -E 0.05 capture.pcap capture_error.pcap

Failsafe and Failover


Thursday, January 24, 2013

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.
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.
  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.
  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.
  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.