F5 reset tshoot

The following causes are those of the most generous causes that clients get reset from F5:

1, retransmission 5 times + timeout, reset

2, If F5 does not support any of the SSL versions/ciphers client wants to use, F5 would respond with TCP/RST immediately with reset.

3, ssl handshake timeout by default 10 secs

4,Application caused reset.The simplest is when you close the socket, and then write more data on the output stream. By closing the socket, you told your peer that you are done talking, and it can forget about your connection. When you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn’t listen
5, one arm scenario, vip need have snat configured in case the backend server has default gw bypass f5, it that case, f5 connection towards backend server will timeout, after that f5 will send reset to client side

6, following item5, if automap is configured,  source is translated to self IP on egress interface heading toward servers, if no self ip on that vlan configured on f5, f5 will send reset packet.

7, The Server SSL profile Secure Renegotiate setting is set to Require or Require Strict. The back-end SSL server lacks support for the Transport Layer Security (TLS) Renegotiation Indication Extension

8, HTTP header size exceeded by server

9, HTTP header size exceeded by client

10, When an existing client-side connection has been detached from the server-side connection and reselects a new server, the BIG-IP system sends a TCP RST to the server to close the existing server-side connection. This behavior typically comes from using iRule commands such as LB::reselect.

11, No route to host

12, The BIG-IP system receives a SYN for either one of the following conditions:

  • A virtual server of type reject
  • A port that is protected by the Port Lockdown settings on a self IP address


1, display the routing table
$netstat -r
$route –n
$ip route show
$ ip addr show
2, display interface
$netstat -i
ifconfig for detailed interface information, root previledge might be needed
3, display connections
$netstat -ta
4. display listening server sockets
$netstat -l

ethtool example:

# sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: Twisted Pair
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Supports Wake-on: uag
Wake-on: d
Link detected: yes


nmap -sp 192.178.1.*
tcp syn 1-1000 port number
tcp syn, protocol number, operation version, operation system
nmap -sS -p0 -sV -o
quick scanning
nmap -T5
tcp connect scan for only port 80
nmap -sT -p80
to use faked source ip address and reall src ip together
nmap -sS -D (faked src add)
scan only the first 100 ports instead of 1000 ports
nmap -F -exclude
do ping first, if get response, then go to scap 1000 port
nmap -Pn
scap ipv6 address
nmap -6 ipv6 address
nmap -iflist
to scan the 20 most popular ports
nmap –top-ports 20
run nmap with script
nmap –script=default
nmap -script -help to find all script that can be used
enable all advanced/aggressive scan
nmap -A -T5

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\:test.org.key_1 -M /var/tmp/client1.pms https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13180.html

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 mail.mydomain.com:587
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.