Useful F5 commands

1, When copy configuration from one unit to the other unit, or creating a lot of vips at the same time, it would be easier to do it via CLI:
a) Edit the configuration on editor
b) Copy and paste the configuration throught F5 cli terminal
user@(xxx)(cfg-sync In Sync)(/S1-green-P:Active)(/partition)(tmos)# load sys config from-terminal merge
Enter configuration. Press CTRL-D to submit or CTRL-C to cancel.

2, ssldump for trouble ssl session
a) use find to find the path of keyfile
[user@xxx:/S1-green-P:Active:In Sync] / # find -iname *.key*
for example
b) ssldump -A -d -k <key file> -n -i <capture VLAN> <traffic expression>
-A Print all fields
-d Show application data when private key is provided via -k
-k Private key file, found in /config/ssl/ssl.key/; the key file can be located under client SSL profile
-n Do not try to resolve PTR records for IP addresses
-i The capture VLAN name is the ingres VLAN for the TLS traffic
For example:
[user@xxx:/S1-green-P:Active:Changes Pending] / # ssldump -A -k ./config/filestore/files_d/partition_d/certificate_key_d/ -i 0.0 host and port 443

3, Use command biptop on cli to check all currenct connections
For example:
[user@xxx:/S1-green-P:Active:In Sync] ~ # bigtop
QUERYING… | bits since | bits in prior | current
| Mar 4 00:16:03 | 0 seconds | time
BIG-IP ACTIVE |—In—-Out—Conn-|—In—-Out—Conn-| 14:28:57 691.0T 1.418P 8.543G 0 0 0

VIRTUAL ip:port |—In—-Out—Conn-|—In—-Out—Conn-|-Nodes Up–
/partition/ 668.2T 213.5T 704.4M 0 0 0 0

4, You can use the openssl command to verify the client certificate against the Trusted Certificate Authority bundle prior to importing it onto the BIG-IP system. For example, the following openssl command verifies the client certificate, client.crt, against the Trusted Certificate Authority bundle:

openssl verify -purpose sslclient -CAfile /path/to/trusted-ca-bundle.crt /path/to/client.crt

If the chain of trust can be established for the server certificate using the specified chain, the command returns output similar to the following example:

client.crt: OK
5, Use tcpdump to show more tmm information,
for example, to check routed vip:
tcpdump -vs0 -i 0.0:nnn host
it shows below, the red part showed routed vip when received request from client.
16:28:44.474154 IP (tos 0x0, ttl 255, id 37043, offset 0, flags [DF], proto: TCP (6), length: 52) vip.http > host.38934: ., cksum 0x4282 (incorrect (-> 0x8e1f), ack 159 win 4297 <nop,nop,timestamp 913578425 3245706819> out slot1/tmm2 lis=/partition/xxxhttp-vip flowtype=64 flowid=5701C0361D00 peerid=5


failover of F5 LTM


1, Normally we use HA group (fast failover) because failover when using VLAN fail-safe or Gateway fail-safe will take about 10 secs. HA group failover happens almost immediately.

2, We are using version 11.6 and I have found that we need change failover method (in traffic group) to HA group in order to make HA group failover works.
You may check HA score with command show /sys ha-group

When you have failover method as HA order configured, it shows like this:
LB(Active)(/Common)(tmos)# show /sys ha-group detail

Sys::HA Group: lb01-ha
State enabled
Active Bonus 10
Score 0

| Sys::HA Group Trunk: nko-lb01-ha:lb-trunk
| Threshold 1
| Percent Up 100
| Weight 20

HA group score is always 0, no failover will happen even if you shutdown the trunk. When you change failover method to HA group, then it shows as below:
LB(Active)(/Common)(tmos)# show /sys ha-group

Sys::HA Group: lb01-ha
State enabled
Active Bonus 10
Score 20

| Sys::HA Group Trunk: nko-lb01-ha:lb-trunk
| Threshold 1
| Percent Up 100
| Weight 20
| Score Contribution 20

3, HA failover unicast configuration
Always you need configure 2 ips in order to make failover works: MGMT IP and failover IP. Especially failover IP is in a dedicated failover link among LTM nodes.
Removing mgmt IP will cause both LTM nodes switch to active statue even failover ip is configured and reachable. Removing failover IP will cause the same issue even if the mgmt ip is configured and reachable.

Sync and mirror ip can be configured as failover IP only, mgmt ip is not necessary here.

4, What will triger failover?

refer to above link:

The BIG-IP system initiates failover according to any of several events that you define. These events fall into these categories:

System fail-safe
With system fail-safe, the BIG-IP system monitors various hardware components, as well as the heartbeat of various system services. You can configure the system to initiate failover whenever it detects a heartbeat failure.
Gateway fail-safe
With gateway fail-safe, the BIG-IP system monitors traffic between an active BIG-IP system in a device group and a pool containing a gateway router. You can configure the system to initiate failover whenever some number of gateway routers in a pool of routers becomes unreachable.
VLAN fail-safe
With VLAN fail-safe, the BIG-IP system monitors network traffic going through a specified VLAN. You can configure the system to initiate failover whenever the system detects a loss of traffic on the VLAN and the fail-safe timeout period has elapsed.
HA groups
With an HA group, the BIG-IP system monitors trunk, pool, or cluster health to create an HA health score for a device. You can configure the system to initiate failover whenever the health score falls below configurable levels.
When you enable auto-failback, a traffic group that has failed over to another device fails back to a preferred device when that device is available. If you do not enable auto-failback for a traffic group, and the traffic group fails over to another device, the traffic group remains active on that device until that device becomes unavailable.

5, failover methods:

refer to link

  • Select Load Aware when the device group contains heterogeneous platforms and you want to ensure that a traffic group fails over to the device with the most capacity at the moment that failover occurs.
  • Select HA Order to cause the traffic group to fail over to the first available device in the Failover Order list.
  • Select HA Group to cause the BIG-IP system to trigger failover based on an HA health score for the device.

F5 301b study

1, ssldump command with partition or not?
ssldump -r /var/tmp/www-ssl-client1.cap -k /config/filestore/files_d/Common_d/certificate_key_d/\:Common\ -M /var/tmp/client1.pms

2, client got reset via ltm, but work directly to server. Tcpdump provided, port translation and address translation, auto map, strict src port mapping?

3, traffic bypass ltm, snat to solve the problem?
When default gw of server nodes are not ltm, use snat to force return traffic route back to LTM 4, sql monitor for server with sql server?
The MS-SQL monitor (when properly configured) runs a query and compares the response to the receive string. If recvrow and recvcolumn are specified, the receive string comparison will be against only that data, rather than the full query result.
Here is a working example. (Thanks to Consultant Extraordinaire Nelson Ge for proving in the field.) How to use this snippet:
Follow the required procedures in the LTM Manual:
Installing the JDBC driver (reboot LTM after installing for best results) Configuring the monitor Use a username that can be logged in >1x concurrently to prevent false DOWN if both LTMs in a redundant pair connect simultaneously Use only integers for the optional fields "recvcolumn" and "recvrow", or the monitor won’t fire at all Use the debug option (found in the Advanced screen) -- very helpful in troubleshooting
Note: Having a SQL DBA on hand can be quite helpful in making sense of the monitor configuration fields and debug output.
monitor sql_field_check {
   defaults from mssql
   database "DB1"
   debug "no"
   password "bigip"
   recvcolumn "1"
   recvrow "2"
   recv "MyDogFrankie"
   send "select top 1 ItemID from Activity order by ActivityID"
   username "bigip"

5, avr reading and config?
Analytics profile

6, profile name for collecting page load info 7, email alert config file which path?
11.5.0 or later : tmsh modify /sys outbound-smtp mailhub
11.0 -11.4: vi /etc/ssmtp/ssmtp.conf
Optional: If the BIG-IP system has custom alerts configured in /config/user_alert.conf to send an email notification using the fromaddress parameter, you must clear the comment in the following line in the /etc/ssmtp/ssmtp.conf file:
If the SMTP mail host uses Secure Socket Layer (SSL)/TLS authentication, you must add the following four additional parameters into the /etc/ssmtp/ssmtp.conf configuration file:
<SMTP-Account-Username> refers to the user name of a valid account on the SMTP mail host server.
<SMTP-Account-Password> refers to the password of the user account on the SMTP mail host server

7, logger to test snmp alert email notification?
logger -p <facility>.<level> "<alert code>:<log level>: <descriptive message>"
logger -p local0.notice "01070640:5: Node monitor status down."
<facility> is the syslog-ng facility as listed in the /var/run/bigip_error_maps.dat file.
<leel> is the facility log level, which can include one of any eight available log levels.
<alert code> is the alert code as indicated in the *_maps.h file entry.
<log level> is the alert log level. This level corresponds with the following values:
Log level          Description     Corresponding syslog level
0                        System is unusable                 emerg
1                        Action must be taken immediately                alert
2                        Critical conditions                    crit
3                        Error conditions                       err
4                        Warning conditions                warning
5                        Normal but significant condition                    notice
6                        Informational info
7                        Debug-level messages            debug

8, syslogng?  Default log to local.?
The syslog-ng utility is an enhanced version of the standard UNIX and Linux logging utility syslog. It allows for more scalable and flexible logging The log definition example indicates the following:
Facility name: local0
Facility level: all levels
The location of the log file: /var/log/ltm The name of the log file: ltm

9, vhost and vguest upgrading process steps?
Starting in 11.0.0, BIG-IP supports vCMP, a feature that allows you to run multiple instances of the BIG-IP software on a single hardware platform. The hypervisor allows you to allocate hardware resources to each BIG-IP vCMP guest instance.
Upgrade considerations
When upgrading vCMP systems, take note of the following considerations:
Before upgrading a guest, ensure that the new version supports the hardware and is supported by the vCMP host version. For information, refer to SOL14088: vCMP host and compatible guest version matrix.
Before performing an upgrade, you should reactivate the license on the vCMP host system. The vCMP guests retrieve their license from the host, so you do not need to reactivate the guest licenses.
Important: Reactivating the vCMP host license will result in a temporary traffic interruption on the guest systems while the license is reactivated on the host system.
Before upgrading a host system, you should gracefully shut down the guests by setting the requested state to Configured. You should gracefully shut down one guest at a time.
Guests on separate slots can be upgraded at the same time. However, you should ensure that only one upgrade at a time is performed on any one slot. Attempting to upgrade multiple guests on the same slot may cause high CPU utilization and result in watchdog reboots.
Common upgrade questions
Q: Which should I upgrade first, the guests or the hypervisor host?
A: If the host is not at an I/O bug mitigated code level (e.g. 11.2.1 HF3+, 11.3.0 HF1+, 11.4.0 and newer) then you should upgrade the host first. Ensure that the host upgrade finishes, boots completely, and the guests start without issues. If the host is at or above those code levels, then you can upgrade either the guest or the host first.
Q: Can I update all of my guests at once?
A: While the system will allow you to upgrade multiple guests at the same time, F5 recommends that you only upgrade one guest, per slot, at a time. If you have multiple guests on separate slots, you can upgrade them at the same time. However, if you have two guests that use blade 1, then upgrade the guests one at a time. This rule also applies to guests that span multiple blades; if there is any overlap, then F5 recommends that you upgrade the guests one at a time.
Q: Are there any requirements for chassis, host, and guest versions?
A: The only requirements are based on the host and guest versions supported by your hardware. For information, refer to SOL14088: vCMP host and compatible guest version matrix.
Q: If I only plan to upgrade some vCMP guests, and not the host, is it required/suggested to re-activate the license on the host first?
A: While F5 recommends that you always re-activate the host license before performing an upgrade, it is possible to verify the license's service check date to see if re-activation is required. If the service check date is older than the license check date, required by the version that you want to upgrade to, then you must re-activate the license first.
You can view the service check date for a host system's license file by typing the following command (from the host system's command line):
grep -i "service check date" /config/bigip.license
Output appears similar to the following example:
Service check date: 20121010

10, 10-11 upgrading, process steps for active-active device group?
you force Device B to offline mode, and then install the new version software onto Device B (the offline device).
When you finish the installation of the new version software onto Device B, it creates two traffic groups called traffic-group-1 and traffic-group-2. Each traffic group is in standby state on Device B, and Device A (the version 10.x device) is in active mode. You can then force Device A to offline mode, changing both the new version software traffic groups to active state on Device B hen you complete upgrading both devices to the new version software, the BIG-IP system configuration includes traffic-group-1 and traffic-group-2 in active state on Device B, a traffic-group-1 and traffic-group-2 in standby state on Device A, and a device group that includes both devices.
Once each device is upgraded to the new version software, you can reconfigure the traffic groups to become active on the devices that you want by forcing the active traffic group on a device to standby state. When forcing the traffic group to standby state, you can target the device upon which you want that traffic group to run in active state. For example, you can force traffic-group-1 on Device B into standby state, and into active state on Device A. Additionally, if you use HA groups, you can create a unique HA group for each traffic group on each device.

11, persistence lost every time after client restart, how to make cookie saved even after  restart?
In cookie profile, click off session-cookie in expiration, set up a life-time
There are 2 types of cookies: session cookie and persistent cookie.
Session cookie is in memory and only survives until you close the browser.
Persistent cookie will be saved into disc and will be expired based on the Expires property.
Sessions work with cookies, which are deleted when the browser is closed, unless they have a specific life-time.

1, address translation port translation on Vip 14, nat and snat enabled in pool 15,TCPftp profile
Port and address translation are for destination address and port. In a standard VIP configuration, with port and address translation enabled, when packets from the client arrive at the VIP, the destination address and port are changed from the VIP's address and port to the load balanced server's address and port. You can obviously enable/disable each individually for different effects. When you create a wildcard VIP (, the port and address translation settings should be automatically disabled. This would be used in scenarios like firewall load balancing (inbound) or forward proxy (outbound) where you definitely don't want the original address and port altered.
SNAT is for changing the SOURCE address. Without SNAT, packets from the client arriving at the VIP retain the client's true source address. SNAT is then important if the downstream server knows how to route back to that address directly (not back through the F5). SNAT will change the client source to an address controlled by the F5 to essentially force return traffic back through the proxy.