f5 tmos commands

Log in to the Traffic Management Shell (tmsh) by entering the following command:

Tmsh

delete a partition

 To delete the VLAN named vlan-rd1234 that belongs to administrative partition named ResourceA, type the following command:

delete /net vlan /ResourceA/vlan-rd1234

Delete the affected route domain, using the following command syntax:

delete /net route-domain //

For example, to delete the affected route domain named rd1234 that belongs to administrative partition named ResourceA, type the following command:

delete /net route-domain /ResourceA/rd1234

Save the configuration using the following command:

save /sys config

Create a partition

create /auth

For example, to create a new administrative partition named ResourceA, type the following command:

create /auth partition ResourceA

Change tmsh path to the desired administrative partition, using the following command syntax:

cd /

For example, to change to the tmsh path to administrative partition named ResourceA, type the following command:

cd /ResourceA

Under the desired administrative partition created in Step 3, create the required VLAN, using the following command syntax:

create /net vlan interfaces add { } tag

For example, to create the VLAN named vlan-rd1234 with network interface 1.1 and tag it with a VLAN ID 1234, type the following command:

create /net vlan vlan-rd1234 interfaces add { 1.1 } tag 1234

Create the required route-domain and add the VLAN created in Step 4, using the following command syntax:

create /net route-domain { id vlans add { } }

For example, to create the route-domain named rd1234 with ID value 1234 and add the VLAN vlan-rd1234 as a member to the route-domain, type the following command:

create /net route-domain rd1234 { id 1234 vlans add { vlan-rd1234 } }

Set the route domain created in Step 5 as the Partition Default Route Domain, using the following command syntax:

modify /auth partition default-route-domain

For example, to set the partition named ResourceA to use route domain ID 1234 as the partition default route domain, type the following command:

modify /auth partition ResourceA default-route-domain 1234

Create the desired self IP address with the VLAN create in Step 4, using the following command syntax:

create /net self / vlan

For example, to create a self IP address of 10.0.0.100 with netmask 255.255.255.0 with the VLAN vlan-rd1234, type the following command:

create /net self 10.0.0.100/255.255.255.0 vlan vlan-rd1234

Continue to create any additional required self IP addresses.

Save the configuration, using the following command:

save /sys config

Change to the top-level administrative partition using the following command:

cd /

List the self IP address that is currently configured in the BIG-IP system, by typing the following command:

list /net self recursive

Create  VLAN
To create a VLAN on an untagged interface, use the following command syntax:

create net vlan interfaces add { }

For example:

create net vlan test-vlan interfaces add { 1.1 }

Save the change by typing the following command:

save /sys config

You can view the BIG-IP systems VLAN configuration by typing the following command:

show net vlan

Modifying the untagged interface associated with an existing VLAN

Impact of procedure: The impact of this procedure depends on the specific environment. F5 recommends testing any changes during a maintenance window, with consideration to the possible impact on your specific environment.

Log in to the Traffic Management Shell (tmsh) by typing the following command:

tmsh

To modify the untagged interface for a VLAN, use the following command syntax:

modify net vlan interfaces replace-all-with { }

For example:

modify net vlan test-vlan interfaces replace-all-with { 1.3 }

Save the change by typing the following command:

save /sys config

You can view the BIG-IP systems VLAN configuration by typing the following command:

show net vlan

Creating a VLAN with a tagged interface

Impact of procedure: The impact of this procedure depends on the specific environment. F5 recommends testing any changes during a maintenance window, with consideration to the possible impact on your specific environment.

Log in to the Traffic Management Shell (tmsh) by typing the following command:

tmsh

To create a VLAN with a tagged interface, use the following command syntax:

create net vlan interfaces add { { tagged }} tag

For example:

create net vlan test-vlan interfaces add { 1.1 { tagged }} tag 4093

Save the change by typing the following command:

save /sys config

You can view the BIG-IP systems VLAN configuration by typing the following command:

show net vlan

Modifying a VLAN to be associated with another tagged interface

Impact of procedure: The impact of this procedure depends on the specific environment. F5 recommends testing any changes during a maintenance window, with consideration to the possible impact on your specific environment.

To modify the VLAN associated with an existing tagged interface, use the following command syntax:

modify net vlan interfaces replace-all-with { { tagged }} tag

For example:

tmsh modify net vlan test-vlan interfaces replace-all-with { 1.3 { tagged }} tag 4093

Save the change by typing the following command:

save /sys config

You can view the BIG-IP systems VLAN configuration by typing the following command:

show net vlan

Modifying the VLAN tag number on an existing tagged interface

Impact of procedure: The impact of this procedure depends on the specific environment. F5 recommends testing any changes during a maintenance window, with consideration to the possible impact on your specific environment.

Log in to the Traffic Management Shell (tmsh) by typing the following command:

tmsh

To modify the VLAN tag number on an existing tagged interface, use the following command syntax:

modify net vlan tag

For example:

modify net vlan test-vlan tag 4092

Save the change by typing the following command:

save /sys config

You can view the BIG-IP systems VLAN configuration by typing the following command:

show net vlan

list ltm rule UDP_TUNNEL_DISCOVER_NODE to show IRule

run util bash to change to bash 

show sys connection cs-client-addr 10.30.164.xxx%338 all-properties

show net arp for mac-address

List auth partition/user/

modify ltm node POLICY-03 state user-down

cd /PARTITION

show sys connection | grep 10.30.xxx.1

list ltm rule [[partition name]]

list ltm node/node monitor/pool/pool members

ping 172.16.38.11%338

tcpdump -ni 0.0 host 172.yy.xx.11

tcpdump -ni 0.0:p dst host 172.xx.yy.20

tcpdump  -ni  /partiotin name/vlan name host 172.xx.xx.14

show ltm persistence persist-records client-addr 172.16.xxx.yyy

show ltm persistence persist-records

delete ltm persistence persist-records NAME

list net vlan/route/route-domain/self

show net arp/

show ltm node/pool/rule/policy/snat/snat-translation/virtual/virtual-address

/ect/init.d/ntpd dtop or start

TMM Traffic manager micro cirnal

tail -f  /var/log/ltm 

run cm config-sync to-group F5_HA

show ltm pool http_ACTIVE detail

show net route static/dynamic

show net arp | grep MAC ADDRESS

list ltm data-group

run util bash

PROD_F5_BACKUP

save /sys ucs backup.ucs

y

run util bash

SCP file transfer:

scp -P 22 /var/local/ucs/backip.ucs Guest@ftpserver:/${NodeCaption}-${Date}-${Time}.ucs

run util bash

cd /var/local/ucs

 SCP :

scp -P 22 cs_backup.ucs Guest@ftp server:/

show interfaces | include line_protocol|input_rate|output_rate

 create VIP

create ltm virtual XIPLINK_AC2_VIP6 destination 172.16.13.212:any ip-protocol udp persist replace-all-with {  STICKY_MASK24 } pool  XS-03 source 0.0.0.0/0 VLANS ADd {  XIPLINK_CLIENT  } vlans-enabled

Add monitor to pool

modify ltm pool XS-03 monitor

CREATE LTM NODE

create ltm node PIL_VM_trest_91 address 172.17.x.x

create ltm node PIL_VM_trest_92 address 172.7.x.x

create ltm pool trest members add {PIL_VM_trest_91:any PIL_VM_trest_92:any }

create ltm virtual trest POOl trest destination 172.x.x.x.30:any source 0.0.0.0/0 vlans-enabled vlans add { trest_CLIENT_522 } ip-protocol tcp

modify ltm pool trest members none

show sys connection cs-client-addr 10.x.x.85%338

f5 201 tmos administration study guide

---

The order of virtual server precedence (from the highest precedence to the lowest precedence) is as follows:

·         ip:port

·         ip:any

·         network:port

·         any:port

·         network:any

·         vlan:port

·         vlan:any

·         any:any

Once a packet is sent to a specific virtual server, it is added to the connection table for that virtual server. From that point forward, packets that come in from the same connection will always go to the virtual server that contains the connection in its connection table, ignoring virtual server precedence.

The order of precedence has changed in BIG-IP version 9.x. For more information, refer to SOL6459: Order of precedence for virtual server matching.

sol411: Overview of packet tracing with the tcpdump utility

Running the tcpdump utility
    Selecting an Interface or VLAN
    Disabling name resolution
Saving tcpdump output to a file
    Binary file
    Text file
Reading tcpdump binary file output
Filters
    Filtering on a host address
    Filtering on a port
    Filtering on a tcp flag
    Combining filters with the and operator
Capturing packet data
Suppressing hostname and port resolution
Combining tcpdump options
Advanced tcpdump topics
Supplemental Information

The tcpdump utility is a command line packet sniffer with many features and options. For a full description, refer to the tcpdump man pages by typing the following command:

man tcpdump

Running the tcpdump utility

Following are examples of commands used to run the tcpdump utility:

Selecting an Interface or VLAN

The tcpdump utility is able to sniff for packets on only one interface or VLAN. By default, it selects the lowest numbered interface.

To select an interface, use the -i flag, as follows:

tcpdump -i

For example:

To tcpdump a specific interface:

tcpdump -i 2.1

tcpdump -i 1.10

To tcpdump a specific vlan:

tcpdump -i internal

tcpdump -i external

To tcpdump the management interface:

tcpdump -i eth0

Note:  Do not attempt to run tcpdump on an interface that contains a colon.

For example: 

eth0:mgmt

Disabling name resolution

By default, tcpdump attempts to look up IP addresses and use names, rather than numbers, in the output. The BIG-IP system must wait for a response from the DNS server, so the lookups can be time consuming and the output may be confusing.

To disable name resolution, use the -n flag as in the following examples:

tcpdump -n

tcpdump -ni internal

Saving tcpdump output to a file

You can save the tcpdump data to one of the following file formats:

·         A binary file that contains all the information collected by the tcpdump and is readable by the tcpdump utility as well as many other traffic analysis packages.

·         A text file that contains a subset of the full tcpdump data, but is readable only as plain text.

When working with F5 Technical Support, you must provide the tcpdump output in the binary file format.

Binary file

To save the tcpdump output to a binary file, type the following command:

tcpdump -w

For example:

tcpdump -w dump1.bin

Note: The tcpdump utility does not print data to the screen while it is capturing to a file. To stop the capture, press CTRL-C.

Text file

To save the tcpdump output to a text file, type the following command:

tcpdump >

For example:

tcpdump >dump1.txt 

Reading tcpdump binary file output

To read data from a binary tcpdump file (that you saved by using the tcpdump -w command), type the following command:

tcpdump -r

For example:

tcpdump -r dump1.bin

In this mode, the tcpdump utility reads stored packets from the file, but otherwise operates just as it would if it were reading from the network interface. As a result, you can use formatting commands and filters.

Beginning in BIG-IP 11.2.0-HF3, 11.2.1-HF3, and 11.3.0, a pseudo header which includes the following parameters is added to the start of each binary tcpdump capture:

·         The tcpdump command syntax used, including all options

·         Version of software

·         Hostname of the system

·         Platform ID

·         Product

Filters

The tcpdump utility allows you to use filters to, among other things, restrict the output to specified addresses, ports, and tcp flags.

Filtering on a host address

·         To view all packets that are traveling to or from a specific IP address, type the following command:

tcpdump host

For example:

tcpdump host 10.90.100.1

·         To view all packets that are traveling from a specific IP address, type the following command:

tcpdump src host

For example:

tcpdump src host 10.90.100.1

·         To view all packets that are traveling to a particular IP address, type the following command:

tcpdump dst host

For example:

tcpdump dst host 10.90.100.1

Filtering on a port

·         To view all packets that are traveling through the BIG-IP system and are either sourced from or destined to a specific port, type the following command:

tcpdump port

For example:

tcpdump port 80

·         To view all packets that are traveling through the BIG-IP system and sourced from a specific port, type the following command:

tcpdump src port

For example:

tcpdump src port 80

·         To view all packets that are traveling through the BIG-IP system and destined to a specific port, type the following command:

tcpdump dst port

For example:

tcpdump dst port 80

Filtering on a tcp flag

·         To view all packets that are traveling through the BIG-IP system that contain the SYN flag, type the following command:

tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'

·         To view all packets that are traveling through the BIG-IP system that contain the RST flag, type the following command:

tcpdump 'tcp[tcpflags] & (tcp-rst) != 0'

Combining filters with the 'and' operator

You can use the and operator to filter for a mixture of output.

Following are some examples of useful combinations:

tcpdump host 10.90.100.1 and port 80

tcpdump src host 172.16.101.20 and dst port 80

tcpdump src host 172.16.101.20 and dst host 10.90.100.1

Capturing packet data

The tcpdump utility provides an option that allows you to specify the amount of each packet to capture.

You can use the -s (snarf/snaplen) option to specify the amount of each packet to capture. To capture the entire packet, use a value of 0 (zero).

For example:

tcpdump -s0 src host 172.16.101.20 and dst port 80

Alternatively, you can specify a length large enough to capture the packet data you need to examine.

For example:

tcpdump -s200 src host 172.16.101.20 and dst port 80

If you are using the tcpdump utility to examine the output on the console during capture or by reading from an input file with the -r option, you should also use the -X flag to display ASCII encoded output along with the default HEX encoded output.

For example:

tcpdump -r dump1.bin -X -s200 src host 172.16.101.20 and dst port 80

Suppressing hostname and port resolution

The tcpdump utility provides an option that allows you to specify whether IP addresses and service ports are translated to their corresponding hostnames and service names.

Since performing multiple name lookups during a packet capture may be resource intensive, you should disable name resolution while capturing on a busy system using the -n option.

For example:

tcpdump -n src host 172.16.101.20 and dst port 80

Service port lookups incur less overhead than DNS-based name resolutions, but still are usually unnecessary while performing a capture. You can disable both name and service port resolution while performing a capture, by using the -nn option.

For example:

tcpdump -nn src host 172.16.101.20 and dst port 80

Combining tcpdump options

This article contains the most essential tcpdump options. You will generally need to use most of the options in combination.

Following are examples of how to combine the tcpdump options to provide the most meaningful output:

tcpdump -ni internal -w dump1.bin

tcpdump -ni internal -r dump1.bin host 10.90.100.1

tcpdump -ni 2.1 host 10.90.100.1 and port 80

tcpdump -ni 1.10 src host 172.16.101.20 and dst port 80 >dump1.txt

tcpdump -Xs200 -nni eth0 -w /var/tmp/mgmt.cap dst host 172.16.101.20 and dst port 162

sol8082: Overview of TCP connection setup for BIG-IP LTM virtual server types

---

The BIG-IP virtual server type specifies the attributes for a virtual server. For example, a Standard virtual server has a different set of attributes and is used to process traffic differently than a Forwarding virtual server. The virtual server type can be found in the Configuration utility by navigating to Local Traffic > Virtual Servers, clicking a specific virtual server, and then viewing the Type drop-down box. The following is a description of the connection setup characteristics for BIG-IP LTM virtual server types:

Standard virtual server

Performance Layer4 virtual server

Performance HTTP virtual server

Forwarding Layer 2 virtual server

Forwarding IP virtual server

Reject virtual server

Standard virtual server

The BIG-IP LTM TMOS operating system implements a full proxy architecture for virtual servers configured with a TCP profile. By assigning a custom TCP profile to the virtual server, you can configure the BIG-IP LTM system to maintain compatibility to disparate server operating systems in the data center. At the same time, the BIG-IP LTM system can leverage its TCP/IP stack on the client side of the connection to provide independent and optimized TCP connections to client systems.

In a full proxy architecture, the BIG-IP LTM system appears as a TCP peer to both the client and the server by associating two independent TCP connections with the end-to-end session. Although certain client information, such as the source IP address or source TCP port, may be re-used on the server side of the connection, the BIG-IP LTM system manages the two sessions independently, making itself transparent to the client and server.

The Standard virtual server requires a TCP or UDP profile, and may optionally be configured with HTTP, FTP, or SSL profiles if Layer 7 or SSL processing is required.

The TCP connection setup behavior for a Standard virtual server varies depending on whether a TCP profile or a TCP and Layer 7 profile, such as HTTP, is associated with the virtual server

Creating packet filter rules

Packet filter rules are criteria statements that the BIG-IP system uses for filtering packets. The BIG-IP system attempts to match packet filter rules with an incoming packet, and if a match exists, determines whether or not to accept or reject the packet.

When you create a packet filter rule, you configure several settings, and then you define the criteria that you want the BIG-IP system to use to filter the traffic.

To create a packet filter rule

1.	On the Main tab of the navigation pane, expand Network, and click Packet Filters. The Packet Filters screen opens.

Note: If you have not enabled the Packet Filter feature, you can still create a packet filter rule. However, the BIG-IP system cannot use the packet filter rule until you have enabled the Packet Filter feature. For more information, see Enabling packet filtering.

2.	On the menu bar, click Rules. A list of any existing packet filter rules displays.
3.	In the upper-right corner of the screen, click Create. The New Packet Filter Rule screen opens.

Note: If the Create button is unavailable, you do not have permission to create a packet filter rule. You must have either the Administrator or Resource Administrator role assigned to your user account.

4.	Configure all settings. For more information, see Configuring settings for packet filter rules, following, and Creating a filter expression.
5.	Click Finished.

Configuring settings for packet filter rules

You can configure a number of different settings when you create a packet filter rule. Table 12.3 lists and describes the settings that you can configure. Following the table are sections that provide more detail on each setting.

Table 12.3 Configuration settings for a packet filter rule
Setting	Description	Default Value
Name	Specifies a unique name for the packet filter.	No default value
Order	Specifies a number that you assign to a rule, which determines when the packet filter is processed. Low numbers take priority over higher ones.	No default value
Action	Specifies the action that BIG-IP system should take when a match is found. Possible values are: Accept, Discard, Reject, and Continue.	Accept
Rate Class	Lists one or more existing rate classes that you assign to the packet filter. This setting applies only when you have enabled the rate shaping feature. For more information on rate classes, see the Configuration Guide for BIG-IP® Local Traffic Management.	None
Apply to VLAN	Specifies the incoming VLAN on which the BIG-IP system should search for matches.	* ALL VLANS
Logging	Action that the BIG-IP system takes to record every match that it finds.	Disabled

Specifying a name

Using the Name setting, you can specify a unique name for the packet filter rule. This setting is required.

The LDAP authentication module

An LDAP authentication module is a mechanism for authenticating or authorizing client connections passing through a BIG-IP system. This module is useful when your authentication or authorization data is stored on a remote LDAP server or a Microsoft® Windows Active Directory server, and you want the client credentials to be based on basic HTTP authentication (that is, user name and password).

With the LDAP authentication module, Local Traffic Manager can indicate that the authentication was a success or failure, or that the LDAP server needs a credential of some sort.

Additionally, the system can take some action based on certain information that the server returns in the LDAP query response. For example, LDAP response information can indicate the users group membership, or it can indicate that the users password has expired. To configure Local Traffic Manager to return specific data in an LDAP response, you can write an iRule, using the commands AUTH::subscribe, AUTH::unsubscribe, and AUTH::response_data. For more information, see Chapter 18, iRules, and the F5 Networks DevCentral web site, http://devcentral.f5.com.

Backing up customized configuration files

If your system configuration has been customized to reference files that are not included in the default BIG-IP installation, refer to SOL4422: Viewing and modifying the files that are configured for inclusion in a UCS archive.

File names and location

By default, the BIG-IP system saves the UCS archive file with a .ucs extension if you do not include it in the file name. You can also specify a full path to the archive file, and then the archive file is saved to the specified location. If you do not include a path, the file is saved to the default archive directory, /var/local/ucs. Archives located in a directory other than the default do not appear in the list of available archives when using the Configuration utility to create or restore a UCS archive, or when using the list /sys ucs command in the tmsh utility. To easily identify the file, F5 recommends that you include the BIG-IP host name and current timestamp as part of the file name.

Secure Storage

Ensure that you have access to a secure location for storage of your UCS archive files. A typical UCS archive contains user accounts, passwords, critical system files, and SSL private keys. However, you can explicitly exclude SSL private keys from a UCS archive during the backup process. It is important to store the backup UCS archives containing sensitive information in a secure location. For instructions, refer to SOL175: Transferring files to or from an F5 system.

Considerations for restoring configuration data

BIG-IP software version and platform

·         F5 recommends that you run the same version of the BIG-IP software on the BIG-IP system from which it was backed up. However, you can restore a BIG-IP 10.x UCS archive on a system running BIG-IP 11.x software.

·         Due to an issue in BIG-IP 11.0.0, you must perform a configuration restoration using a configuration archive that is taken from the same hardware platform. For more information, refer to SOL13136: The UCS configuration archive cannot be restored on a platform other than the one on which the archive was created.

·         The UCS archive is intended to back up and restore the configuration of a specific platform. When installing a UCS archive on a dissimilar platform, the configuration may fail to load due to the differing hardware components. These failures require that you intervene manually, and identify and resolve each error that the system presents when you attempt to load the configuration.

Licensing

The BIG-IP license is associated with a specific hardware serial number. The UCS archive contains the license of the file from which the configuration was saved. To successfully install a UCS archive file on a BIG-IP system, you must perform one of the following actions:

·         Restore the UCS archive to the same system from which it was saved.

·         Have the license associated with the serial number of a new system. To do so, contact F5 Technical Support.

Note: F5 Technical Support will associate a license file with a new serial number only on an as-needed basis, in the event of a Return Materials Authorization (RMA).

·         Relicense the BIG-IP system after restoring the UCS archive.

·         Save the license file prior to restoring the configuration from another system, and then copy the license file back.

·         Install the UCS archive by using the tmsh no-license option. For the command syntax, refer to the following example:

tmsh load sys ucs [ucs file name] no-license

Important: If you use a different license than the one contained in a restored UCS archive, the replacement license must include authorization for the same options and add-on modules, such as BIG-IP WebAccelerator or BIG-IP ASM. If you attempt to restore a UCS configuration referencing an unlicensed module, the BIG-IP system does not properly restore the UCS archive. Additionally, the BIG-IP system reports a Provisioning Warning message in the Configuration utility, as well as the status of ModuleNotLicensed in its command-line prompt.

UCS files

If necessary, copy the UCS archive file you want to restore to the BIG-IP filesystem.

Host name and base configuration

The UCS restore operation restores the full configuration to the target system, including the host name and the base configuration.

Note: This behavior has changed from previous versions of the BIG-IP system.

SSL private keys with passphrases

If you are restoring on a new system, a UCS archive that includes SSL private keys with encrypted passphrases cannot be decrypted by the new system. This format is an intentional security measure.

When replacing one system of a failover pair, F5 recommends that you configure basic networking on the replacement unit and synchronize the configuration from its peer instead of restoring the configuration by installing the UCS archive. Because the master key is shared between units of a redundant pair, the configuration synchronization process synchronizes the original master key to the newly-installed device. If you cannot synchronize the original master key to the new system from its peer, but you know the original unencrypted passphrases, you can install the UCS file to restore the configuration, modify the affected SSL profiles to replace the encrypted passphrases with unencrypted versions, and save the resulting configuration.

If you are restoring a backup that contains SSL private key passphrases after reinstalling the operating system, replacing a failed system with a new system, or otherwise moving an existing configuration to a new system, the encrypted passphrases for SSL private keys used in the configuration cannot be decrypted. An error message similar to the following example appears:

BIGpipe client SSL profile creation error:
      01070937:3: Master Key decrypt failure - decrypt failure

If you receive this error message when installing the UCS archive, refer to SOL9420: Installing a UCS file containing an encrypted passphrase before proceeding.

SSL private keys with passphrases

When restoring on a new system, a UCS archive that includes SSL private keys with encrypted passphrases cannot be decrypted by the new system. This format is an intentional security measure.

When replacing one system of a failover pair, instead of restoring the configuration by installing the UCS archive, F5 recommends that you configure basic networking on the replacement unit and synchronize the configuration from its peer. Because the master key is shared between units of a redundant pair, the configuration synchronization process synchronizes the original master key to the newly-installed device.

If you cannot synchronize the original master key to the new system from its peer, but you know the original unencrypted passphrases, you can install the UCS file to restore the configuration, modify the affected SSL profiles to replace the encrypted passphrases with unencrypted versions, and save the resulting configuration.

GTM consideration

For a BIG-IP GTM RMA unit that is licensed and provisioned with the GTM module and the DNSSEC feature, refer to SOL13542: Restoring DNSSEC configuration data to a BIG-IP GTM RMA unit.

For BIG-IP GTM 10.1.0 through 10.2.4, the BIG-IP GTM system updates the timestamp of the restored wideip.conf file during the UCS archive restoration process. As a result, the restored BIG-IP GTM configuration will overwrite the configuration on the remaining systems in the same synchronization group. For information about preventing this behavior, refer to SOL12679: The gtmparse utility now updates the timestamp of the wideip.conf file before reloading the configuration from disk or UCS archive.

Installing a hotfix image using the tmsh utility

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

To install the hotfix using the tmsh utility, perform the following procedure:

1.     Log in to tmsh by typing the following command:

tmsh

2.     To install the hotfix image, use the following tmsh syntax:

install sys software hotfix .iso volume

For example, to install a hotfix on HD1.1, the syntax appears similar to the following example:

install sys software hotfix Hotfix-BIGIP-11.0.0-1234.0-HF1.iso volume HD1.1

3.     To show the status of the hotfix installation, type the following command:

show sys software status

For example, the following output indicates that hotfix build 8120.0 is installing on volume HD1.1:

-----------------------------------------------------------
Sys::Software Status
Volume  Product  Version   Build  Active             Status
-----------------------------------------------------------
HD1.1    BIG-IP   11.0.0  8120.0      no    installing hotfix
HD1.2    BIG-IP   11.0.0  8120.0     yes           complete
HD1.3    BIG-IP   11.0.0  8037.0      no           complete

Reverting to a previous hotfix version or base software build

If you need to revert to the previous hotfix version, you can boot to the formerly-active boot location that contains the previous hotfix installation.

If you need to remove a hotfix installation, you must restore the BIG-IP base build on the boot location from the Software Management screen in the Configuration utility or the tmsh utility. For example, if the BIG-IP system runs BIG-IP 11.0.0 HF1 on HD1.2, and you want to remove the hotfix, you must back up the configuration, change to a different boot location (for example, HD1.1), and then use the Configuration utility, or the tmsh utility, to reinstall the base version 11.0.0 build on HD1.2.