201 TMOS ADMINISTRATION
Packet-based vs. Proxy-based
F5 initially took the packet-based path, but simultaneously started addressing the root problem—making an
intelligent solution that also delivers high performance. The result is the F5 TMOS architecture, a collection of
real-time features and functions, purpose-built and designed as a full-proxy solution with the power and
performance required in today’s network infrastructure.
What is a packet-based design?
A network device with a packet-based (or packet-by-packet) design is located in the middle of a stream of
communications, but is not an endpoint for those communications; it just passes the packets through. Often a
device that operates on a packet-by-packet basis does have some knowledge of the protocols flowing through it,
but is far from being a real protocol endpoint. The speed of these devices is primarily based on not having to
understand the entire protocol stack, short-cutting the amount of work needed to handle traffic. For example, with
TCP/IP, this type of device might only understand the protocols well enough to rewrite the IP addresses and TCP
ports; only about half of the entire stack.
What is a proxy-based design (full proxy)?
A full-proxy design is the opposite of a packet-by-packet design. Instead of having a minimal understanding of the
communications streaming through the device, a full proxy completely understands the protocols, and is itself an
endpoint and an originator for the protocols. The connection between a client and the full proxy is fully
independent of the connection between the full proxy and the server; whereas in a packet-by-packet design, there
is essentially a direct communication channel between the client and the server (although the device in the middle
may manipulate the packets going back and forth).
This also means the full proxy can have its own TCP connection behavior, such as buffering, retransmits, and
TCP options. With a full proxy, each connection is unique; each can have its own TCP connection behavior. This
means that a client connecting to the full-proxy device would likely have different connection behavior than the full
proxy might use for communicating with the backend servers.
The real solution is to build a proxy-based solution with the performance of the packet-based solution.
TMOS is a collective term used to describe the completely purpose-built, custom architecture which F5 spent
years and significant investment developing as the foundation for F5 products going forward. From a high-level,
TMOS is:
A Collection of Modules, Each module performs a particular function. Every component of the system is selfcontained, which helps reduce the complexity of the system and eases future development. Adding support for
new protocols is simply a matter of adding a new module.
Self-Contained and Autonomous, Many people have observed that a TMOS-based device has a form of Linux
running on it, which can be seen when administering the device using the command line. TMOS has its own
dedicated CPU, memory, and system bus for access to peripheral devices. The Linux system is used for
management tasks, such as the command line or the web GUI only. The reason for this is simple: an operating
system which is ideal for high speed traffic management operations is not ideal as a general purpose operating
system.
A Real-Time Operating System, A real-time operating system means TMOS does not have a preemptive CPU
scheduler. This significantly reduces the overhead of CPU scheduling by eliminating interrupts, context switches,
and most of the work a scheduler would typically do. This also allows full control over when, and in what order,
processing occurs.
Both Hardware and Software, Because TMOS is inherently modular in design, it doesn’t matter whether individual
functions are handled by software or by hardware.
Stateful inspection, The core architecture of TMOS is based on a high speed full proxy which performs stateful
inspection to traffic flows as does a stateful firewall. While connection traffic is proxied through TMOS, the F5
iRules engine has full access (layer 2-7) to that traffic and can set various rules (based on traffic characteristics,
ACLs, or business logic). As an example, rule actions can be Drop, Block, Redirect, Log, or Transform.
Page 1 of 91
Dynamic Packet Filtering, By default, just like a firewall, TMOS has a “deny all” policy. Traffic flow can also be
filtered, redirected, or blocked dynamically at the same application layer such as HTTP, or packet by packet, such
as via UDP, SCP, or TCP.
First, there is the FastL4 stack; a limited-state TCP/UDP or traditional packet-by-packet design to handle any
high-connection rate, but limited functionality (layer 4 and below) requirements. Then, there is the FastHTTP
stack; a limited-state TCP/HTTP stack representing an extremely advanced packet-by-packet design to handle
high-connection rates with increased HTTP (layer 7) intelligence requirements. Finally, there is the Fast
Application Proxy; the default full-proxy based stack representing the pinnacle of proxy-based design.
TCP Express is a collection of TCP efficiency improvements, in the form of internet standards (RFCs), and
hundreds of custom F5 features and tuning based on our extensive real-world experience. TMOS supports every
modern TCP efficiency improvement, including: delayed and Selective Acknowledgements, Explicit Congestion
Notification (ECN), limited and Fast Retransmits, Slow Start with Congestion Avoidance, Adaptative Initial
Congestion Windows, TimeStamps and Windows Scaling, TCP Slow Start, Bandwidth Delay Control, etc.
The Fast Application Proxy component of TMOS, the full-proxy stack, is another key differentiator. The Fast
Application Proxy provides for the application fluency necessary to implement a host of other TMOS modules,
including: HTTP Compression, Multi-Store Caching, SSL Acceleration, Fast Cache, Content Spooling, Intelligent
Compression, QoS/ToS, and L7 Rate Shaping.
iRules are one of the most unique capabilities of TMOS. iRules are scripts created using the standard Tool
Command Language (TCL) with custom F5 extensions that enable users to create unique functions triggered from
TMOS events. Since the initial launch of TMOS, F5 customers have found hundreds of ways of taking advantage
of the power of the iRules engine in TMOS. For example:
• DNS rate limiting.
• Implementing an SMTP proxy to inspect and direct individual messages.
• Re-ordering HTTP cookies for easier parsing on the back-end systems.
• Authenticating user connections with a back-end RADIUS server using credentials stored in a HTTP cookie.
• Implementing a simple LDAP parser to inspect parameters of LDAP bind() requests.
• Selectively using SSL re-encryption to the back-end servers only for certain HTTP URLs. And selectively
requiring SSL client certificates based on HTTP URLs.
• Creating and inserting a custom session ID value into an HTTP request, which the server will echo back in
the response, then inspect the response and verify it matches the request. If not, logging the full session
information, and the last 100 requests.
• CORBA/IIOP request multiplexing.
There is no other device in the world that can implement this type of highly sophisticated logic via their inspection
feature-set.
TMOS is the first, completely purpose-built, modular, self-contained, real-time, event-driven proxy architecture
with the ability to transparently utilize hardware and software unilaterally to achieve the best performance and
intelligence.
Page 2 of 91
1.1 Connectivity, packet, and virtual server processing orders
SOL6459: Order of precedence for virtual server matching (9.x - 11.2.1)
When determining the order of precedence applied to new inbound connections, the BIG-IP system uses an
algorithm that places a higher precedence on the address netmask and a lesser emphasis on the port. BIG-IP
LTM sets virtual server precedence according to the following criteria:
 The first precedent of the algorithm chooses the virtual server that has the longest subnet match for the
incoming connection.
 If the number of bits in the subnet mask match, the algorithm chooses the virtual server that has a port
match.
 If no port match is found, the algorithm uses the wildcard server (if a wildcard virtual server is defined).
 A wildcard address has a netmask length of zero; thus, it has a lower precedence than any matching
virtual server with a defined address.
This algorithm results in the following order of precedence:
<address>:<port>
<address>:*
<network>:<port>
<network>:*
*:<port>
*:*
For example, for a BIG-IP system with the following VIPs configured on the inbound VLAN:
10.0.0.0/8:80
10.10.0.0/16:80
10.10.10.10/32:80
20.0.0.0/8:*
20.0.0.0/8:80
*:80 (alternatively noted as 0.0.0.0/0:80)
*:* (alternatively noted as any:any, 0.0.0.0/0:any)
The following table illustrates how inbound destination addresses map to the configured VIPs:
Inbound destination address VIP
10.10.10.10:80
10.10.10.10/32:80 - address match and port match
10.10.10.11:80
10.10.0.0/16:80 - most specific address match and port match
10.1.10.10:80
10.0.0.0/8:80 - most specific address match and port match
20.0.0.0:80
20.0.0.0/8:80 - most specific address match and port match
20.0.0.0:443
20.0.0.0/8:* - most specific address match with wildcard port
1.1.1.1:443
*:* - wildcard address and wildcard port
Beginning with BIG-IP LTM 9.4.0, the bigpipe db TM.ContinueMatching variable is set to false, which negates
the precedence order and causes BIG-IP LTM to reject the packet if the requested virtual server is
unavailable.
When the TM.ContinueMatching db variable is set to true, the BIG-IP system checks if another virtual server is
available to handle a request if the higher precedence virtual server is disabled.
In the following example, the port-specific virtual server is disabled, which allows the system to use the
wildcard virtual server 10.10.1.10:* to handle a client request to 10.10.1.10:80:
TM.ContinueMatching = true
Virtual Server: 10.10.1.10:80
Status: Disabled
Virtual Server: 10.10.1.10:*
Status: Up and Available
Page 3 of 91
When the TM.ContinueMatching db variable is set to false, the BIG-IP system does not allow a lower
precedence virtual server to handle a request when a higher precedence virtual server is disabled.
SOL411: Overview of packet tracing with the tcpdump utility
The tcpdump utility is able to sniff for packets on only one interface or VLAN. By default, it selects the lowest
numbered interface.
Selecting an Interface or VLAN
#tcpdump -i 1.10 #tcpdump -i internal
#tcpdump -i eth0
#tcpdump -i 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.
# 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
Text file
# tcpdump -w dump1.bin
# tcpdump > dump1.txt
Reading tcpdump binary file output
# tcpdump -r dump1.bin
Filters
Filtering on a host address
# tcpdump host 10.90.100.1
# tcpdump src host 10.90.100.1
# tcpdump dst host 10.90.100.1
To view all packets that are traveling to or from a specific IP address
To view all packets that are traveling from a specific IP address
To view all packets that are traveling to a particular IP address
Filtering on a port
# tcpdump port 80
destined to
# tcpdump src port 80
# tcpdump dst port 80
To view all packets that are traveling through the BIG-IP, sourced from or
To view all packets that are traveling through the BIG-IP and sourced from a specific port
To view all packets that are traveling through the BIG-IP and destined to a specific port
Filtering on a tcp flag
# tcpdump 'tcp[tcpflags] & (tcp-syn) != 0' To view all packets that are traveling through the BIG-IP system
that contain the SYN flag.
# tcpdump 'tcp[tcpflags] & (tcp-rst) != 0' To view all packets that are traveling through the BIG-IP system
that contain the RST flag.
Combining filters with the 'and' operator
# 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
Page 4 of 91
Capturing packet data
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).
# 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.
# tcpdump -s200 src host 172.16.101.20 and dst port 80
You can also use the -X flag to display ASCII encoded output along with the default HEX encoded output.
# 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.
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.
# tcpdump -nn src host 172.16.101.20 and dst port 80
Combining tcpdump options
Following are examples of how to combine the tcpdump options to provide the most meaningful output:
#tcpdump
#tcpdump
#tcpdump
#tcpdump
#tcpdump
-ni internal -w dump1.bin
-ni internal -r dump1.bin host 10.90.100.1
-ni 2.1 host 10.90.100.1 and port 80
-ni 1.10 src host 172.16.101.20 and dst port 80 >dump1.txt
-Xs200 -nni eth0 -w /var/tmp/mgmt.cap dst host 172.16.101.20 and dst port 162
Using tcpdump to view traffic on a tagged VLAN
To view VLAN tagged traffic on the BIG-IP system, you can specify the interface number. When you specify
the interface number in the tcpdump syntax, the VLAN header is present because tcpdump reads the packet
when it is copied on switch ingress from the switch fabric to the Host.
The following syntax displays all traffic for the interface, including the VLAN tag ID: # tcpdump -ni 1.1
To filter the traffic for a specific VLAN tag ID, use the following syntax:
# tcpdump -ni 1.1 vlan 2907
# tcpdump -ni 1.1 vlan 2907
tcpdump: listening on 1.1
09:39:11.800739 802.1Q vlan#2907 P0 10.24.2.254 > 10.24.2.34: icmp: echo request
09:39:11.800739 802.1Q vlan#2907 P0 10.24.2.34 > 10.24.2.254: icmp: echo reply (DF)
When you specify the VLAN name in the tcpdump syntax, the VLAN header is not present
because tcpdump reads the packet after it is copied on switch ingress.
#tcpdump -ni internal
o
o
o
o
o
If you run tcpdump on a heavily loaded BIG-IP system, the packet capture process may not capture
all matching traffic, and the statistical values reported by tcpdump may be inaccurate.
For systems containing a PVA ASIC, the tcpdump utility does not capture virtual server traffic that is
fully accelerated by the PVA chip.
Running tcpdump on a switch interface is rate-limited to 200 packets per second.
If the specified interface is a member of a trunk, tcpdump captures all traffic flowing through the trunk,
not just the traffic traversing the specified interface.
When using tcpdump to capture traffic in a non-default route domain, F5 recommends that you run
the tcpdump command from the default route domain (route domain 0), and specify interface 0.0.
For example, the following command captures traffic from all VLANs in all route domains when
invoked from the default route domain: # tcpdump -ni 0.0
Page 5 of 91
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.
Standard virtual server
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.
Standard virtual server with a TCP profile
A Standard virtual server processes connections using the full proxy architecture. The following TCP flow
diagram illustrates the TCP handshake for a Standard virtual server with a TCP profile:
Page 6 of 91
Standard virtual server with Layer 7 functionality
If a Standard virtual server is configured with Layer 7 functionality, such as an HTTP profile, the client must
send at least one data packet before the server-side connection can be initiated by the BIG-IP LTM system.
A Standard virtual server with Layer 7 functionality processes connections using the full proxy architecture.
The following TCP flow diagram illustrates the TCP handshake for a Standard virtual server with Layer 7
functionality:
Performance Layer4 virtual server
The Performance Layer4 virtual server type uses the Fast L4 profile. Depending on the configuration, the
virtual server uses the PVA ASIC chip with the PVA Acceleration mode defined as one of the
following: full, assisted, or none.
The Performance Layer4 virtual server packet-by-packet TCP behavior operates as follows: The initial SYN
request is sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM system makes the load
balancing decision and passes the SYN request to the pool member.
Page 7 of 91
Performance HTTP virtual server
The Performance HTTP virtual server type uses the Fast HTTP profile. The Performance HTTP virtual server
with the Fast HTTP profile is designed to speed up certain types of HTTP connections and reduce the number
of connections opened to the back-end HTTP servers. This is accomplished by combining features from the
TCP, HTTP, and OneConnect profiles into a single profile that is optimized for network performance. The
Performance HTTP virtual server processes connections on a packet-by-packet basis and buffers only
enough data to parse packet headers.
The Performance HTTP virtual server TCP behavior operates as follows: The BIG-IP system establishes
server-side flows by opening TCP connections to the pool members. When a client makes a connection to the
Performance HTTP virtual server, if an existing server-side flow to the pool member is idle, the BIG-IP LTM
system marks the connection as non-idle and sends a client request over the connection.
Performance HTTP virtual server with idle server-side flow
Performance HTTP virtual server with no idle server-side flow
Page 8 of 91
Forwarding Layer 2 virtual server
The Forwarding Layer 2 virtual server type uses the Fast L4 profile. The Forwarding Layer 2 virtual server
forwards packets based on the destination Layer 2 Media Access Control (MAC) address, and therefore does
not have pool members to load balance. The virtual server shares the same IP address as a node in an
associated VLAN. Before creating a Forwarding Layer 2 virtual server, you must define a VLAN group that
includes the VLAN in which the node resides. The Forwarding Layer 2 virtual server processes connections
on a packet-by-packet basis.
The Forwarding Layer 2 virtual server operates on a packet-by-packet basis with the following TCP behavior:
the initial SYN request is sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM passes the
SYN request to the node in the associated VLAN based on the destination MAC address.
Forwarding IP virtual server
The Forwarding IP virtual server type uses the Fast L4 profile. An IP forwarding virtual server forwards the
packet directly to the next hop IP address specified in the client request. Therefore, when the BIG-IP LTM
system evaluates the packet for processing, the system looks only at the destination IP address. The
Forwarding IP virtual server processes connections on a packet-by-packet basis.
The Forwarding IP virtual server operates on a packet-by-packet basis with the following TCP behavior: the
initial SYN request is sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM virtual server
passes the SYN request to the next IP address in the associated VLAN, based on the destination IP address.
The following TCP flow diagram illustrates the TCP handshake for a Forwarding IP virtual server:
Page 9 of 91
Reject virtual server
The Reject virtual server type causes the BIG-IP system to immediately reject any traffic destined for the
virtual server IP address. The Reject virtual server operates using the following TCP behavior: the initial SYN
request is sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM virtual server immediately
closes the connection by sending a TCP reset to the client.
The following TCP flow diagram illustrates the TCP behavior for a Reject virtual server:
Manual Chapter: Introducing BIG-IP Local Traffic Manager
The three most basic objects in Local Traffic Manager that you must configure for local traffic management
are:
a) Virtual Servers
b) Load balancing Pools
c) Profiles
Timeout settings for connections and sessions
Local Traffic Manager has a number of time-outs that can be set to promote active connection management.
The system manages each load-balanced connection explicitly by keeping track of the connection in the
connection table while the connection is still active.
Connection reaping
Connections that close or reset in a normal way are retired from the connection table automatically. A
significant number of connections, however, often remain idle without closing normally, for any number of
reasons. Consequently, Local Traffic Manager must reap these connections once they have been determined
to be inactive. Reaping is the process of retiring or recycling connections that would otherwise remain idle.
Page 10 of 91
Idle timeout
Table, Idle timeout settings that affect connection reaping
Default in
Seconds
Userconfigured?
Fast L4, Fast HTTP, TCP, and
SCTP profiles
300
Yes
UDP profiles
60
Yes
SNAT automap
300
No
VLAN group
300
No
Configuration Object Type
Table, Idle timeout settings that do not affect connection reaping
Configuration Object Type
Default in
Seconds
Userconfigured?
OneConnect profiles
Disabled
Yes
Cookie Hash, Destination Address Affinity,
Hash, SIP, Source Address Affinity, and
Universal persistence profiles
180
Yes
MSRDP and SSL persistence profiles
300
Yes
The network map
Object summary
When you first open the Network Map screen, the screen displays a summary of local traffic objects. This
summary includes the type of objects specified with the search mechanism, the number of each type of
object, and, for each object type, the number of objects with a given status.
The summary displays data for these object types:
 Virtual Servers
 Pools
 Pool Members
 Nodes
 iRules
Note: A local traffic summary includes only those objects that are referenced by a virtual server. For example,
if you have configured a pool on the system but there is no virtual server that references that pool, the local
traffic summary does not include that pool, its members, or the associated nodes in the summary.
1.2 Troubleshooting virtual servers
DevCentral: Pool Member won’t work through BIG-IP LTM
tcpdump -ni 0.0 -s0 host 1.1.1.1 or host 2.2.2.2
(where 1.1.1.1 and 2.2.2.2 are the client and server addresses)
Page 11 of 91
You can use curl to generate a valid HTTP request from the LTM command line. You can test direct to the
pool members as well as to the virtual server.
# curl -v 'http://1.1.1.1/path/to/file.ext?param1=value1'
If you want to make a request for the root object on the web app, you can just use:
# curl -v 'http://1.1.1.1/'
It would be simpler to troubleshoot if you create a test virtual server and then tcpdump on the client and server
IPs. You can create a test pool as well and only enable one server at a time to help isolate the issue.
DevCentral: Troubleshooting LTM Monitors
a) Enabling / Disabling debug on the monitoring daemon, bigd
tmsh:
modify sys db bigd.debug value [enable | disable]
bigpipe:
db bigd.debug [enable | disable]
Enables or disables debug on bigd. Output is written to /var/log/bigdlog
Note: The logging is very verbose and increases resource usage. So debug should be enabled sparingly and
disabled when troubleshooting is complete.
b) Command line tools
i.
tcpdump
ii.
netcat (nc)
iii.
curl [curl is a tool to transfer data from or to a server, using one of the supported protocols
(HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, DICT, TELNET, LDAP or FILE). The
command is designed to work without user interaction]
Example troubleshooting steps for a pool member unexpectedly being marked down by a monitor
Check the ltm log file for monitor log event
# tail -f /var/log/ltm
Enable debug on the monitoring daemon, bigd
Use tcpdump to check the communication to/from the pool member
# tcpdump -nni 0.0 -X -s0 host 10.41.0.21 and port 80 and host 10.41.1.3 (-X - print hex and ascii
output)
Use curl, netcat or another tool #curl -v http://10.41.0.21:80/monitor_page.html
Using netcat (nc) and echo to send a request
# echo -ne "GET /monitor_page.html HTTP/1.1\r\nConnection: Close\r\nHost: \r\n\r\n" | nc 10.41.0.21 80
Flags:
 -n - do not output the trailing newline
 -e - enable interpretation of backslash-escaped characters (specifically the \r - carriage
return and \n - new line characters)
My Example:
Monitor HTTP 1.1
GET / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: Close\r\n\r\n
[root@asm:Active:Standalone] config # curl -v 'http://208.85.209.20/'
* About to connect() to 208.85.209.20 port 80 (#0)
* Trying 208.85.209.20... connected
* Connected to 208.85.209.20 (208.85.209.20) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (i686-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3 libidn/0.6.5
> Host: 208.85.209.20
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Found
< Location: https://www.f5.com
Page 12 of 91
* HTTP/1.0 connection set to keep alive!
< Connection: Keep-Alive
< Content-Length: 0
< Server: F5
<
* Connection #0 to host 208.85.209.20 left intact
* Closing connection #0
[root@asm:Active:Standalone] config # echo -ne "GET / HTTP/1.1\r\nConnection: Close\r\nHost:
208.85.209.20\r\n\r\n" | nc 208.85.209.20 80
HTTP/1.0 302 Found
Location: https://www.f5.com
Connection: close
Content-Length: 0
Server: F5
[root@asm:Active:Standalone] config #
1.3 Troubleshooting pool members
SOL12531: Troubleshooting health monitors
When experiencing health monitor issues, you can use the following troubleshooting steps:
 Identifying a failing health monitor
 Verifying monitor settings
 Troubleshooting monitor types
 Troubleshooting daemons related to health monitoring
 Related solutions
Identifying a failing health monitor
The BIG-IP system logs messages related to the health monitor to the /var/log/ltm file.
SNMP
When the BIG-IP system is configured to send SNMP traps and a health monitor marks a
pool member or node down or up, the system sends the following traps:
 Pool members

alert BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.10"
}
alert BIGIP_MCPD_MCPDERR_POOL_MEMBER_MON_STATUS_UP {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.11"
}
Nodes
alert BIGIP_MCPD_MCPDERR_NODE_ADDRESS_MON_STATUS {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.12"
}
alert BIGIP_MCPD_MCPDERR_NODE_ADDRESS_MON_STATUS_UP {
snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.13"
}
Verifying monitor settings It is important to verify that monitor settings are properly defined for your
environment. For example, F5 recommends that you configure most monitors with a timeout value of three
times the interval value, plus one. This is to prevent the monitor from marking the node down before the last
check is sent.
A simple monitor is used to verify the status of the destination node: gateway_icmp, icmp, tcp_echo,
tcp_half_open
ECV monitors use Send and Receive string settings to retrieve content from pool members or nodes: tcp,
http, https, and https_443.
Troubleshooting monitor types
1. Determine the IP address of the nodes being marked down.
Page 13 of 91
a. # cat /var/log/ltm |grep 'Node' |grep 'status'
2. Check connectivity to the node. (ping, or traceroute (10.x, 11.x) or tracepath (9.x))
a. # ping -c 4 10.10.65.1
3. Check the monitor settings.
a. # tmsh list /ltm monitor mi_monitor
4. Create a custom monitor (if needed).
5. Test the response from the application.
[root@asm:Active:Standalone] config # time curl -v 'http://208.85.209.20/'
* Closing connection #0
real
0m0.186s
user
0m0.004s
sys
0m0.001s
[root@asm:Active:Standalone] config #
6. Use the tcpdump command to capture monitor traffic.
Note: If you want to test a specific HTTP request, including HTTP headers, you can use the telnet command
to connect to the pool member.
For example:
telnet <serverIP> <serverPort>
Next, at the prompt, enter an appropriate HTTP request line and HTTP headers, pressing Enter once after
each line. For example:
GET / HTTP/1.1 <enter>
Host: www.yoursite.com <enter>
Connection: close <enter>
<enter>
An HTTP health monitor reads up to 5,120 bytes into HTTP data. If the monitor cannot find a match to the
configured search string within the first 5,120 bytes, the BIG-IP LTM system marks the node as down.
Troubleshooting daemons related to health monitoring
The bigd process manages health checking for pool members, nodes, and services on the BIG-IP LTM
system. The bigd process collects health checking status and communicates the status information to
the mcpd process, which stores the data in shared memory so that the TMM can read it. If you are having
monitoring issues, you can check the memory utilization of the bigd process. If the %MEM is unusually high,
or continually increases, the process may be leaking memory.
[root@asm:Active:Standalone] config # ps aux | grep bigd
USER
PID %CPU %MEM VSZ RSS TTY
STAT START TIME COMMAND
root
5438 0.0 0.4
44808 17320 ?
S 11:08 0:00 /usr/bin/bigd
SOL10516: Overview of BIG-IP pool status
The BIG-IP system determines the status of a pool based on the availability of the members of that pool. The
availability of a pool member is determined by its health check results, and by the state to which the pool
member is set.
A BIG-IP Administrator can assign a pool member one of the following states:



Enabled
The pool member is eligible to receive all traffic.
Disabled
The pool member accepts new connections with a persistence record (for example, a new connection
arriving to the BIG-IP system that presents a persistence cookie pointing to that pool member), and
continues to serve existing connections (for example, an established TCP connection). New
connections without a persistence record are not load balanced to this pool member.
Forced offline
The pool member continues to serve only existing connections. No new connections are allowed.
Page 14 of 91
The BIG-IP system marks a pool down only when all of its members are either down, forced offline, or a
combination of these two statuses; only then does the Configuration utility use the red diamond icon to
represent the pool.
PM Disabled
PM Forced Offline
PM Offline (Down)
SOL13898: Determining which monitor triggered a change in the availability of a node or pool member (11.x)
When a health monitor is in use, the mcpd process logs a message when a pool, pool member, or node
changes state, although the mcpd process does not identify which health monitor caused a change in the
availability of an object.
Page 15 of 91
You may be able to determine which health monitor has caused a change in the availability of an object by
enabling the bigd.lognodestatuschange db key, which triggers the bigd process to log which particular health
monitor has caused a change in the availability of an object. To enable the key and review the /var/log/ltm file,
perform the following procedure:
1. Log in to the Traffic Management Shell (tmsh).
2. Verify the status of the bigd.lognodestatuschange db key by entering the following command:
# list /sys db bigd.lognodestatuschange
3. If the status is disabled, enable the bigd.lognodestatuschange db key by entering the following
command:
# modify /sys db bigd.lognodestatuschange value enable
In the following example, the pool member 10.1.2.9:80 is marked down because it fails to pass
the http monitor test. The pool member then passes the http monitor test and is subsequently marked up. In
the first example there is no indication of which monitor marks the node down or up. However, after enabling
the bigd.lognodestatuschange db key, the bigdprocess logs which monitor marks the node down and
subsequently back up again.
Example output taken before enabling the db key:
local/bigip-1 notice mcpd[3741]: 01070638:5: Pool member 10.1.2.9:80 monitor status down.
local/bigip-1 notice mcpd[3741]: 01070727:5: Pool member 10.1.2.9:80 monitor status up.
Example output taken after enabling the key:
local/bigip-1 notice bigd[3747]: 01060001:5: Service detected DOWN for ::ffff:10.1.2.9:80 monitor http.
local/bigip-1 notice mcpd[3741]: 01070638:5: Pool member 10.1.2.9:80 monitor status down.
local/bigip-1 notice bigd[3747]: 01060001:5: Service detected UP for ::ffff:10.1.2.9:80 monitor http.
local/bigip-1 notice mcpd[3741]: 01070727:5: Pool member 10.1.2.9:80 monitor status up.
F5 Product Development tracked RFE ID 227271, for an enhancement to allow the BIG-IP system to log
which particular health monitor caused a change in the availability of an object. This functionality has been
added in BIG-IP 11.4.0.
SOL10966: Determining which monitor triggered a change in the availability of a node or pool member (9.x,
10.x)
The mcpd process handles the operation of health monitors; however, the bigd process performs the actual
health checks. The mcpd process periodically requests the bigd process to spawn a monitor instance to verify
the availability of each object. Depending on the number of health monitors you applied to an object, a
monitor instance may carry out multiple health checks. Regardless of the number of health checks required,
the bigd process returns only the final result (the availability of the object) to the mcpd process.
You may be able to determine which health monitor has caused a change in the availability of an object by
executing the bigpipe monitor all instance command from the command line.
Enabling the bigd.lognodestatuschange db key enables monitor-status logging globally.
# bigpipe db bigd.lognodestatuschange
If the status is Disabled, # bigpipe db bigd.lognodestatuschange enable
1.4 Persistence
DevCentral: Persistent and Persistence, What's the Difference?
Persistent
Persistent connections are connections that are kept open and reused. The most commonly implemented
form of persistent connections are HTTP, with database connections a close second HTTP 1.1 and the KeepAlive header in HTTP 1.0 were aimed at improving the performance of HTTP by reusing TCP connections to
retrieve objects. They made the connections persistent such that they could be reused to send multiple HTTP
requests using the same TCP connection.
Page 16 of 91
Persistence
Persistence, on the other hand, is related to the ability of a load-balancer or other traffic management solution
to maintain a virtual connection between a client and a specific server.
Persistence is often referred to in the application delivery networking world as "stickiness" while in the web
and application server demesne it is called "server affinity". Persistence ensures that once a client has made
a connection to a specific server that subsequent requests are sent to the same server. This is very important
to maintain state and session-specific information in some application architectures and for handling of SSLenabled applications.
So persistent connections are connections that are kept open so they can be reused to send multiple
requests, while persistence is the process of ensuring that connections and subsequent requests are sent to
the same server through a load-balancer or other proxy device.
DevCentral: Single Node Persistence
Requirement: Direct traffic to only a single node in a pool at a time. Initially, traffic should always go to node A.
If Node A fails, then traffic will go to Node B. When Node A comes back online, traffic should continue to go to
Node B. When Node B fails, then the traffic should go to Node A.
To send traffic to only 1 pool member at a time, you can use an iRule and Universal Persistence to set a
single persistence record that applies to all connections.
1. Create a virtual server.
2. Create a pool with the real servers in it.
3. Create an iRule like this:
rule PriorityFailover {
when CLIENT_ACCEPTED { persist uie 1 }
}
4. Create a Persistence profile of type Universal which uses the iRule you just created. Set the
timeout high enough so it will never expire under typical traffic conditions.
5. In the virtual server definition, apply pool as the default pool, and the new persistence profile
as the default persistence profile (both on the virtual server "resources" screen).
The first connection will create a single universal persistence record with a key of "1". All subsequent
connections will look up persistence using "1" as the key, resulting in truly universal persistence for all
connections.
Page 17 of 91
DevCentral: Sessions and Cookies and Persistence
Persistence is the process of ensuring that a user is connected to the same server every time they make a
request within the boundaries of a single session. Even though users could be persisted based on their IP
address, this is rarely done due to the sharing of IP addresses. Persistence is most often implemented using
a cookie containing the server session id because it is the most accurate method of determining where a
user's session is currently stored.
If you're a web developer or administrator, you might think "that sounds a lot like server affinity". You'd be
right, of course, server affinity and persistence are two different terms that mean the same thing.
Sessions are stored on the server, and are not reliant on cookies being enable in the client's browser.
Sessions are where web developers store bits of application relevant data that they may wish to use across
requests. Shopping carts are the most ubiquitous example of session data, but there are other uses for it,
especially in complex web applications like CRM (customer relationship management) or SFA (sales force
automation) applications.
Cookies store bits of data on the client (the browser) and are passed to the server via the HTTP
header Cookie.
Persisting Connections
The most common data used to persist connections is SSL session id. The second most common data used
to persist connections is application or server session id, like JSESSIONID or PHPSESSIONID. These IDs
are automatically generated by applications and web servers, and are generally passed to the client as a
cookie on the first response, and then used by the load balancer to determine to which server it should direct
subsequent requests.
An example of HTTP headers storing a JSESSIONID in a cookie:
Cookie: JSESSIONID=9597856473431 Cache-Control: no-cache Host: 127.0.0.2:8080 Connection: Keep-Alive
DevCentral: Session Management (Wikipedia)
A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to
save information about the session history in order to be able to communicate, as opposed
to stateless communication, where the communication consists of independent requests with responses.
An established session is the basic requirement to perform a connection-oriented communication.
2.1 End User Diagnostics and Output
Supplemental Document: EUD 11.4.0 Field Testing BIG-IP Hardware
The end-user diagnostics (EUD) is a compilation of tests for checking the integrity of F5 Networks hardware.
This technical note describes how to use the end-user diagnostics (EUD) to identify possible hardware
problems.
Warning: Before you run these tests, you should disconnect all network cables from the system. Any cables
connected to the system during the tests might cause false positive results.
Downloading the EUD from F5 Networks
The different downloads are provided for the following uses:
a) EUD CDROM ISO image,
On supported systems, you can run the EUD from a USB CDROM drive. This method is useful if you
cannot access the host. This method requires that you have physical access to the system so you can
plug in the USB CDROM drive and reboot the system. Note that you must use a USB CDROM with
an external power source.
b) IM installation package.
On supported systems, you can copy the IM package to the system and update the EUD.
Page 18 of 91
Installing the EUD from an IM installation package
# im EUD_B-11.4.0.4.0.im
Loading the EUD onto a USB Mass storage device
You can load a USB mass storage device from a BIG-IP system by mounting the IM file.
This section describes how to create a USB mass storage device on a BIG-IP system for booting up the EUD.
1. Download the IM file to the /var directory
2. Loopback mount the IM file using the following command:
# mkdir /tmp/eud; mount -o ro,loop /var/EUD_B-11.4.0.4.0.im /tmp/eud
3. Insert a USB mass storage device into the platform on which you mounted the IM file.
4. Use the following command to run the mkdisk utility:
# cd /tmp/eud; ./mkdisk
Running the EUD
You can run the EUD only from a console connected to the BIG-IP system. You can start the EUD using the
following methods:
 Attach a USB CDROM drive containing the bootable system CD. As the system boots up, the EUD
starts.
 Attach a USB mass storage device drive with the EUD boot image loaded. As the system boots up,
the EUD starts.
 While the system is booting, select the End User Diagnostics option from the boot menu.
Using the EUD for most F5 Networks systems
To use the EUD for the BIG-IP 1500 (C36), BIG-IP 3400 (C62), BIG-IP 3410 (C100), BIG-IP 4100 (D46), BIGIP 6400 (D63), BIG-IP 6800 (D68), BIG-IP 8400 (D84), BIG-IP 8800 (D88), Enterprise Manager 500, and
Secure Access Manager 4300, you should understand the EUD menu options.
The EUD menu options for most F5 Networks systems
When you start the EUD, the following menu displays:
1
2
3
4
5
6
7
8
9
10
11
12
System Report
Sensor Report
SFP/XFP Report
LED Test
SCCP I2C Test
PCI Test
Quick System RAM test
System RAM Test
LCD Test
Internal Packet Path Test
Internal Loopback Test
PVA Memory Test
Page 19 of 91
13 SSL Test
14 FIPS Test
15 Compression Test
13 SMART Test
17 File System Check
18 Run all Tests (Non User Intervention, Uses Normal Ram Test)
19 * Run all Tests (User Intervention Required, Uses Quick Ram Test)
20 * Display Test Report Log
21 * Quit EUD and Reboot the System
Select a Menu item # -
Detalle
1 System Report
2 Sensor Report
motherboard.
3 SFP/XFP Report
4 LED Test
5 SCCP I2C Test
6 PCI Test
This option provides a comprehensive test of all system hardware components
This test checks the switchboard CMOS Programmable Logic Device (CPLD) on the
This test checks the SFPs and XFPs installed on the system.
This test sets each of the possible status LED colors one at a time (Interactive)
This option verifies any Inter Chip Communication Bus (I2C) devices in the system.
This option runs a test that reports on and verifies the PCI devices on the PCI bus.
(Peripheral Component Interconnect)
7 Quick System RAM test
Use this option to verify the system RAM. The system RAM test performs an
SDRAM data bus and address bus test.
8 System RAM Test Use this option to verify the system RAM. The system RAM test performs an SDRAM data bus and
address bus test.
9 LCD Test
Use this option to test the functionality of the LCD panel. (Interactive)
10 Internal Packet Path Test This option tests the internal packet path.
11 Internal Loopback Test
This test sets the front ports into PHY or MAC loopback mode and runs packets
through the path from the switch chips.
12 PVA Memory Test Use this test to display the version of the PVA installed in the system.
13 SSL Test
Use this option to test the SSL hardware installed in the system.
14 FIPS Test
This test runs only if the system has a FIPS module installed.
15 Compression Test This test runs only if the system has additional hardware compression installed.
13 SMART Test
The self-monitoring, analysis, and reporting technology test (S.M.A.R.T.) is for testing hard
disks.
17 File System Check Use this option to run fsck, the file system consistency check on all drive partitions.
18 Run all Tests (Non User Intervention, Uses Normal Ram Test)
19 * Run all Tests (User Intervention Required, Uses Quick Ram Test)
20 * Display Test Report Log
21 * Quit EUD and Reboot the System
A report log is stored as the text file /shared/log/eud.log in the host file system.
Determining the EUD version installed on the system
[root@asm:Active] config # eud_info
12.10.0.3.0
[root@asm:Active] config #
[root@asm:Active] tmp # im EUD_M-12.12.0.4.0.im
Logical volume disk management detected.
final
update
info: media has tm_install version 2.8.1, release 39.0
info: system has tm_install version 2.7.4, release 42.0
.............................................................................
7309 blocks
/var/tmp
/tmp/rpmdisk.V10810 /var/tmp
info: Looking for system diagnostics package.
info: Testing integrity of EUD package.
info: OK
info: Updating system diagnostics.
info: Best available EUD release is 12.12.0.4.0
info: System current EUD release is 12.10.0.3.0
Page 20 of 91
info: EUD update is necessary.
info: Searching for existing EUD on hda.dat.boot
info: Installing EUD release 12.12.0.4.0
info: OK
**************************************************************
Update complete.
For more information on this version of the EUD, please
refer to the release notes available on the support
web site (http://tech.f5.com).
**************************************************************
[root@asm:Active] tmp #
My Example:
==================================================
Product:
F5 Networks End User Diagnostics
Build:
EUD_M build 12.12.0.4.0
Platform:
BIG-IP 3600
Serial Number: f5-dwwy-hchg
==================================================
System Tests:
1
System Report
2
Sensor Report
3
SFP/SFP+ Report
4
I2C Test
5
PCI Test
6
ECC Status Test
7
Internal Packet Path Test
8
Internal Loopback Test
9
SSL Test
10
SMART Test
11
Power System Test
18
System RAM Test
Interactive Tests: Requires access to system front panel
20
LED Test
21
LCD Test
EUD Commands
A
Run all System Tests
I
Run all Interactive Tests
D
Display Test Report Log
S
Display Test Summary
Q
Quit EUD and Reboot the System
Select a Menu Item:
2.2 LCD Warning Messages
Manual Chapter: Operating the LCD Panel
The liquid crystal display, or LCD panel, provides the ability to control the unit without attaching a serial or
network cable. The following menus are available on the LCD panel.
Information Menu, How to use the LCD, Front Panel LEDs, Port Indicators, Console and Failover serial port info
System Menu,
Reboot, Halt, Netboot, IP address, Netmask, Default route, Commit, Serial port
Screens Menu
VersionScreen, InfoScreen, DateScreen, MACscreen, SysinfoScreen, TMMCPUScreen,
TMMMemoryScreen, TMMAuthScreen, TMMStatScreen
Options Menu (LCD Config Menu) Heartbeat, Contrast, On Brightness, Off Brightness
Pausing on a Screen - Push the Check button to toggle the LCD between Hold and Rotate modes.
Powering down the unit - Hold the X button for 4 seconds to power down the unit.
Rebooting the unit - Hold the Check button for 4 seconds to reboot the unit.
Clearing alerts - Press the Check button to clear any alerts on the LCD screen.
Page 21 of 91
SOL4263: New front panel LED indicator behavior in BIG-IP version 9.x
LED indicators (V9 Platforms: 1500, 3400, 4100, 6400, 6800, 8400, and 8800)
There are 4 LED indicators:
 Power (ON green, OFF none, POWER FAILURE red)
 Status (ACTIVE green, STANDBY yellow)
 Activity (Activity on the switch to CPU Ethernet interface – Intermittent yellow)
 Alarm (0 WARNING yellow, 1 ERROR blink yellow, 2 ALERT red, 3 CRITICAL red, 4 EMERGENCY blink red)
LED indicators (M Platforms: 1600, 3600, 3900, 6900, and 8900)
There are 4 LED indicators:
 Status (ACTIVE green, STANDBY yellow, POWER OFF off)
 Alarm (No ALARM/POWEROFF off, ERROR yellow, EMERGENCY/POWER STANDBY red)
 Power 1 (PRESENT/NORMAL green, PRESENT/FAILURE yellow, NOT PRESENT off)
 Power 2 (PRESENT/NORMAL green, PRESENT/FAILURE yellow, NOT PRESENT off)
SOL10161: The Activity LED operation on 8400 platforms
The Activity LED on 8400 platforms does not illuminate during normal operations. The LED illuminates while
the system is power cycling, and turns off after the boot process has completed. This is expected behavior.
If the Activity LED light on an 8400 platform is solid green during normal operations, the LED is not operating
as expected, and may be considered defective. When this erroneous condition is present, the operation of the
unit is not affected, and there is no need to remove any units that are already installed in your network.
2.3 Troubleshooting Hardware with log files
Writing to and rotating custom log files
Writing to …
Sometimes I need to log information from iRules to debug something. So I add a simple log statement, like
this:
when HTTP_REQUEST {
if { [HTTP::uri] equals "/secure" } {
log local0. "[IP::remote_addr] attempted to access /secure"
}
}
This is fine, but it clutters up the /var/log/ltm log file. Ideally I want to log this information into a separate log
file. To accomplish this, I first change the log statement to incorporate a custom string - I chose the string "##":
when HTTP_REQUEST {
if { [HTTP::uri] equals "/secure" } {
log local0. "##[IP::remote_addr] attempted to access /secure"
}
}
Now I have to customize syslog to catch this string, and send it somewhere other than /var/log/ltm. I do this by
customizing syslog with an include statement:
tmsh modify sys syslog include '"
filter f_local0 {
facility(local0) and not match(\": ##\");
};
filter f_local0_customlog {
facility(local0) and match(\": ##\");
};
destination d_customlog {
file(\"/var/log/customlog\" create_dirs(yes));
};
log {
Page 22 of 91
source(local);
filter(f_local0_customlog);
destination(d_customlog);
};
"'
save the configuration change:
tmsh save / sys config
and restarting the syslog-ng service:
tmsh restart sys service syslog-ng
The included "f_local0" filter overrides the built-in "f_local0" syslog-ng filter, since the include statement will be
the last one to load. The "not match" statement is regex which will prevent any statement containing a “##”
string from being written to the /var/log/ltm log. The next filter, "f_local0_customlog", catches the "##" log
statement and the remaining include statements handle the job of sending them to a new destination which is
a file I chose to name "/var/log/customlog".
You may be asking yourself why I chose to match the string ": ##" instead of just "##". It turns out that
specifying just "##" also catches AUDIT log entries which (in my configuration) are written every time an iRule
with the string "##" is modified. But only the log statement from the actual iRule itself will contain the ": ##"
string. This slight tweak keeps those two entries separated from each other.
Rotating …
So now I have a way to force my iRule logging statements to a custom log file. This is great, but how do I
incorporate this custom log file into the log rotation scheme like most other log files? The answer is with a
logrotate include statement:
tmsh modify sys log-rotate syslog-include '"
/var/log/customlog {
Compress
….missingok
Notifempty
}"'
and save the configuration change:
tmsh save / sys config
Logrotate is kicked off by cron, and the change should get picked up the next time it is scheduled to run.
SOL13367: Managing log files on the BIG-IP system (11.x)
Procedures
a) Change the log rotation frequency
Move the logrotate script to the appropriate crontab directory (default daily)
# mv /etc/cron.daily/logrotate /etc/cron.[weekly,monthly,daily]/
The BIG-IP system will use the new setting the next time the crontab utility runs the logrotate script.
b) Change the age at which log files become eligible for removal
The logrotate script deletes log files older than the number of days specified by the Logrotate.LogAge database
variable. By default, the variable is set to 8.
# tmsh modify /sys db logrotate.logage value [0-100] # tmsh save /sys config
# bigpipe db Logrotate.LogAge [0-100] (10.x)
c) Change the number of archive copies that the system retains
By default, the BIG-IP system is configured to retain up to a maximum of 24 archive copies of each log file.
# tmsh modify /sys log-rotate common-backlogs [0-100] # tmsh save /sys config
# bigpipe logrotate common backlogs [1-100] (10.x)
d) Add custom options to the log rotation process
For example, you can configure a certain log file to rotate only when it reaches a certain size.
# tmsh # edit /sys log-rotate all-properties
Replace common-include none --> common-include "/var/log/ltm {
compress
missingok
size 1M
notifempty
}"
:wq!  Save changes? (y/n/e)y
# save /sys config
Page 23 of 91
2.4 Failover scenarios
SOL11736: Defining network resources for BIG-IP high availability features (9.x - 10.x)
BIG-IP high availability features, such as network mirroring, configuration synchronization, and network
failover, allow core system services to be available on one of two BIG-IP high availability systems in the event
that the peer system becomes unavailable.
SOL14135: Defining network resources for BIG-IP high-availability features (11.x)
BIG-IP high availability (HA) features, such as connection mirroring, configuration synchronization, and
network failover, allow core system services to be available for a BIG-IP device group in the event that a
particular device group member becomes unavailable.
In addition, certain high availability features allow you to configure the management IP address to process the
high availability traffic, while other features prohibit the use of the management IP address in certain versions.
Mirroring
The connection and persistence mirroring features duplicate the connection and persistence information from
the active to the peer unit. In the event of a failover, the peer system can begin processing connections
immediately without interruption.
BIG-IP 10.x By default, network mirroring addresses are used for ConfigSync. In BIG-IP version 10.x, the
network failover feature requires separate addresses.
Note: F5 does not recommend configuring the management IP address as the mirroring address. You should
configure a self IP address as the mirroring address. (9.x – 10.2.1)
Mirroring recommendations:
 Configure network mirroring addresses for all high availability pairs even if mirroring is not configured
on the system.
 Configure a dedicated VLAN and dedicated interfaces to process mirroring traffic.
 Directly cable network mirroring interfaces.
 Do not use a VLAN group for network mirroring traffic.
 Configure both primary and alternate mirroring addresses.
ConfigSync
ConfigSync is a high availability process that collects the configuration files and directories from one unit of a
redundant pair into an archive file, and then transmits and installs the shared configuration data on the peer.
Starting in BIG-IP 11.x, the ConfigSync feature works in combination with the device service clustering (DSC)
architecture. When the device clustering components (including the ConfigSync IP address) are properly
defined, the device group members establish a communication channel (CMI channel) to accommodate
device group communication and synchronization.
ConfigSync recommendation:
 Define explicit ConfigSync peer addresses for the high availability pair. If your BIG-IP system is
configured to mirror a considerable amount of traffic, consider defining an explicit ConfigSync peer
address for each system and move the ConfigSync traffic to a separate VLAN. (10.x)
 Avoid using the mgmt interface for ConfigSync/device service traffic.(11.x)
 Use an internal or dedicated HA VLAN (11.x)
Network Failover
When BIG-IP redundant systems are configured to use network failover, the systems communicate over the
configured failover addresses.
In BIG-IP 10.x, configuring the Peer Management Address setting is required for network failover.
In BIG-IP 11.x, Configure failover unicast and multicast addresses for each device group member, and Use
an internal or dedicated HA VLAN in addition to the management (MGMT) interface.
Page 24 of 91
SOL13478: Overview of connection and persistence mirroring (11.x)
The connection and persistence mirroring feature allows you to configure a BIG-IP system to duplicate
connection and persistence information to the standby unit of a redundant pair. This setting provides higher
reliability, but might affect system performance.
System redundancy includes the ability to mirror connection and persistence information to a peer device to
prevent interruption in service during failover. Traffic Management Microkernel (TMM) manages the state
mirroring mechanism, and connection and persistence data is synchronized to the standby unit over TCP port
1028 with every packet or flow state update. The standby unit decapsulates the packets and adds them to the
connection table.
You can use the Configuration utility or Traffic Management Shell (tmsh) utility to configure mirroring
addresses, configure connection mirroring for virtual servers and SNATs, and configure persistence mirroring.
You can also view mirroring data on the active and standby BIG-IP system using the tmsh utility. To do so,
refer to the following procedures:
a) Choosing a VLAN for mirroring traffic
If the BIG-IP system is required to mirror a high volume of connection and persistence information, F5
recommends using a dedicated VLAN and using dedicated interfaces to process mirroring traffic.
b) Configuring mirroring IP addresses
Mirroring addresses are the IP addresses that you want the BIG-IP system to use for connection and
persistence mirroring.
#
tmsh
modify
/sys
state-mirroring
[secondary-]addr
<prim|sec_mirror_addr>
c) Configuring connection mirroring for a virtual server
The BIG-IP system can mirror TCP or UDP connections for a virtual server.
(Config Utility) Local Traffic -> Virtual Servers -> Connection Mirroring check box or
(CLI) # tmsh modify /ltm virtual <virtual_server> mirror enabled # tmsh save /sys config
d) Configuring connection mirroring for a SNAT
The BIG-IP LTM system can mirror TCP or UDP connections for a SNAT.
(Config Utility) Local Traffic -> SNATs -> Stateful Failover Mirror check box or
(CLI) # tmsh modify /ltm snat <snat> mirror enabled # tmsh save /sys config
e) Configuring mirroring for a persistence profile
The BIG-IP system can mirror persistence information between peers for the following persistence profiles:
Destination address affinity, Hash, Microsoft Remote Desktop, SIP, Source address affinity, SSL, Universal
(Config Utility) Local Traffic -> Profiles -> Mirror Persistence check box or
(CLI) # tmsh modify /ltm persistence <profile_name> mirror enabled # tmsh save /sys config
f) Viewing mirrored connection data from either the active or standby unit
(CLI) # tmsh show /sys connection all-properties
(CLI 10.x) # bigpipe conn mirror show all
g) Viewing mirrored persistence data from either the active or standby unit
(CLI) # tmsh show /ltm persistence persist-records
(CLI 10.x) # bigpipe persist show
Recommendation
Note: Only FastL4 and SNAT connections are re-mirrored after failback.
 Enable connection and persistence mirroring when a BIG-IP failover would cause the user's session
to be lost or significantly disrupted. For example, where long-term connections, such as FTP and
Telnet, are good candidates for mirroring, mirroring short-term connections, such as HTTP and UDP,
is not recommended as this will cause a decrease in system performance.
 Configure a dedicated VLAN and dedicated interfaces to process mirroring Traffic, Directly cable
network mirroring interfaces
3.1 Perform a packet capture within the context of a performance issue
SOL6546: Recommended methods and limitations for running tcpdump on a BIG-IP system
If you run tcpdump on a heavily loaded BIG-IP system, the packet capture process may not capture all
matching traffic, and the statistical values reported by tcpdump may be inaccurate. For example, the packets
received by filter statistic may not provide an accurate reporting of all matching packets in the network. And
Page 25 of 91
the packets dropped by kernel statistic may not provide an accurate reporting of the real number of matching
packets that have been dropped.
If you run tcpdump on a heavily loaded system, F5 recommends using tcpdump filter expressions to mitigate
the potential for missed packets.
Running tcpdump on a VLAN
When the VLAN is specified in the tcpdump syntax, tcpdump can read packets processed by TMM.
# tcpdump -ni /<partition_name>/<vlan_name> (On 11.x)
For systems containing a PVA ASIC, the tcpdump utility does not capture virtual server traffic that is fully
accelerated by the PVA chip. You can work around this limitation by temporarily disabling PVA acceleration
for the FastL4 profile.
Running tcpdump on an interface
When tcpdump is run on an interface, the packet is copied on a switch ingress to the SCCP or AOM, which
then sends the packet to the host to be captured by tcpdump.
Running tcpdump in a route domain
The tcpdump utility does not capture traffic when run from a non-default route domain. For example, if you
use the rdsh utility to change the shell to a non-default route domain and run the tcpdump command, no traffic
will be captured. To capture traffic, use the following command to change back to the default route domain: #
rdsh 0
You can then run the #tcpdump -ni 0.0 command to capture all route domain traffic.
SOL9704: Capturing and viewing packets (Firepass)
The capture and view packets utility allows the FirePass administrator to troubleshoot networking issues by
capturing the network packets coming to and from the FirePass controller.
1. Log in to the FirePass Administrative Console.
2. Navigate to the Device Management: Maintenance: Troubleshooting tools: Network packet dump
section.
3.2 Use BIG-IP tools in order to identify potential performance issues
Manual: BIG-IP iHealth User Guide
BIG-IP iHealth enables you to verify the proper operation of your BIG-IP and Enterprise Manager systems and
ensures your hardware and software function at peak efficiency.
The results provide tailored feedback about configuration issues or code defects, and provide a description of
the issue, recommendations for resolution, and a link to further information in the AskF5 Knowledge Base.
BIG-IP iHealth was integrated with the Enterprise Manager system starting with version 3.0.0. You can
configure the Enterprise Manager system to automatically create and upload qkview files (from BIG-IP and
Enterprise Manager devices) to BIG-IP iHealth.
F5 recommends uploading a qkview file to the BIG-IP iHealth system at least once a month, since F5 updates
the BIG-IP iHealth known issues and best practices database on a weekly basis.
The default name for a qkview file is as follows:
Page 26 of 91
case_number_____support_file.tar.gz
Manual Chapter: Health and Performance Monitoring
BIG-IP Local Traffic Manager can monitor the health or performance of either pool members or nodes. Local
Traffic Manager supports these methods of monitoring: Simple monitoring, Active monitoring, Passive
monitoring.
Simple monitoring merely determines whether the status of a node is up or down. The system contains two
types of simple monitors, ICMP and TCP_ECHO.
Active monitoring checks the status of a pool member or node on an ongoing basis, at a set interval. If a pool
member or node being checked does not respond within a specified timeout period, or the status of a node
indicates that performance is degraded. Each type of active monitor checks the status of a particular protocol,
service, or application. For example, one type of monitor is HTTP. Active monitors fall into two categories:
Extended Content Verification (ECV) monitors and Extended Application Verification (EAV) monitors.
Passive monitoring occurs as part of a client request. There is only one type of passive monitor, called an
Inband monitor.
A pre-configured monitor is an existing monitor that Local Traffic Manager provides for you, with its settings
already configured. A custom monitor is a monitor that you create based on one of the allowed monitor types.
 Transparent and Reverse modes
 The Manual Resume feature
The resource subsequently becomes unavailable, the resource
remains offline until you manually re-enable it.
 The Time Until Up feature provides a way to adjust the default behavior. This feature allows the
system to delay the marking of a pool member or node as up for some number of seconds after
receipt of the first correct response.
You can configure Dynamic Ratio load balancing for pools that consist of RealNetworks RealServer servers,
Microsoft Windows servers equipped with Windows Management Instrumentation (WMI), or any server
equipped with an SNMP agent such as the UC Davis SNMP agent or Windows 2000 Server SNMP agent.
You must install the monitor plug-in on each server to be monitored, and you must create a performance
monitor that resides on the BIG-IP system. Once you have created a monitor, the monitor communicates
directly with the server plug-in. For each server type, Table 14.3 shows the required monitor plug-in and the
corresponding performance monitor types.
Page 27 of 91
Server Type
Monitor plug-in
Monitor Type
RealServer Windowsserver
RealServer UNIX server
F5RealMon.dll
Real Server
Real Server
Windows server with WMI
f5isapi.dll or
F5Isapi64.dll or
F5.IsHandler.dll
WMI
Windows 2000 Server server
SNMP agent
SNMP DCA and SNMP DCA Base
UNIX server
UC Davis SNMP agent
SNMP DCA and SNMP DCA Base
f5realmon.so
4.1 Verify remote connectivity to the box in order to determine the cause of a management
connectivity issue.
Manual Chapter: Configuring Network Access Resources (APM 11.2.x)
 Creating a network access resource
You configure a network access resource to allow users access to your local network through a secure VPN
tunnel.
1. On the Main tab, click Access Policy > Network Access . The Network Access List screen opens.
2. Click the Create button. The New Resource screen opens.
3. In the Name field, type a name for the resource.
4. Type an optional description for the network access resource.
5. Click Finished to save the network access resource.
The General Properties screen for the network access resource opens.
You can configure the properties for the network access resource using the menu bar at the top of the screen.
Later, you assign the network access resource to an access policy using one of the resource assign actions.





Configuring properties for a network access resource
Configuring network settings for a network access resource
o Proxy ARP considerations. Proxy ARP is not compatible with SNAT pools.
Configuring DNS and hosts for a network access resource
Mapping drives for a network access resource
Launching applications on a network access connection
Manual Chapter: Diagnosing Network Connection Issues (GTM 11.2.x)
To help you diagnose network connection issues, you can view the status of and statistics about the iQuery
connections between BIG-IP Global Traffic Manager (GTM) and other BIG-IP systems on your network.
iQuery connection information displays for IP addresses that are configured on BIG-IP server objects.
When you want to estimate iQuery traffic throughput, following these statistics:
o iQuery Reconnects
o Bytes Out
o Bytes Dropped
o Bytes In
o Backlogs
Manual Chapter: Defining Connectivity Options (APM 11.2.x)
About connectivity profiles
In the BIG-IP Access Policy Manager, a connectivity profile is the profile that you select in a virtual server
definition to define connectivity and client settings for a network access session.
The connectivity profile contains:
 Network access connection compression settings
 Client settings for virtual servers and location awareness
 Client update settings
 Password caching settings
 Citrix client settings
 Mobile client settings
Creating a connectivity profile
Page 28 of 91
You create a connectivity profile to configure client connections for a network access tunnel and clients.
o On the Main tab, click Access Policy > Secure Connectivity > Connectivity Profiles .
To provide functionality with a connectivity profile, you must add the connectivity profile and an access profile
to a virtual server.
Manual Chapter: About Network Access (APM 11.2.x)
What is network access?
The BIG-IP Access Policy Manager network access feature provides secure access to corporate applications
and data using a standard web browser, or the BIG-IP Edge Client. Using network access, employees,
partners, and customers can have access to corporate resources securely, from any location. The network
access feature provides users with the functionality of a traditional IPsec VPN client. Unlike IPsec, however,
network access does not require any pre-installed software or configuration on the remote user's computer. It
is also more robust than IPsec VPN against router and firewall incompatibilities.
Network access features











Full access from any client.- Provides Windows, Macintosh, Linux, and Windows Mobile users with access
Split tunneling of Traffic.- Provides control over exactly what traffic is sent over the network access connection to the
internal network, and what is not.
Client checking.- Detects operating system and browser versions, and processes, and checks files during the login
process to insure that the client configuration meets the organization's security policy for remote access.
Compression of transferred data.- Compresses traffic with GZIP before it is encrypted, reducing the number of bytes
transferred.
Routing table monitoring.- Monitors changes made in the client's IP routing table during a network access connection.
Session inactivity detection.- Closes network access connections after a period below an inactivity threshold.
Automatic application start.- Starts a client application automatically after establishing the network access connection.
Automatic drive mapping.- Connects the user to a specific drive on the intranet. This feature simplifies user access to
files.
Connection-based ACLs.- Filters network traffic by controlling whether packets are allowed, discarded, or rejected,
based on specific criteria.
Dynamic IP address assignment.- Assigns client endpoint IP addresses dynamically from a configured pool of
addresses.
Traffic classification, prioritization, and marking.Provides the ability to classify and prioritize traffic to ensure
levels of service to users with defined characteristics.
Page 29 of 91
Network access configuration elements
A network access configuration requires:
 A network access resource
 An access profile, with an access policy that assigns:
o A network access resource
o A network access or full webtop
 A lease pool that provides internal network addresses for tunnel clients
 A connectivity profile
 A virtual server that assigns the access profile
4.2 Check and interpret port lockdown settings in order to determine the cause of a management
connectivity issue
SOL13250: Overview of port lockdown behavior (10.x - 11.x)
Port lockdown is a BIG-IP security feature that allows you to specify particular protocols and services from
which the self IP address defined on the BIG-IP system can accept traffic.
The port lockdown feature allows you to secure the BIG-IP system from unwanted connection attempts by
controlling the level of access to each self IP address defined on the system.
Port lockdown Exceptions
 TCP port 1028: In a redundant pair configuration, the system allows tcp:1028 for connection and
persistence mirroring, regardless of the port lockdown settings.
 TCP port 4353: When BIG-IP 11.0.0 and later devices are configured in a synchronization group, peer
devices communicate using Centralized Management Infrastructure (CMI) on tcp:4353, regardless of
the port lockdown settings.
 ICMP: ICMP traffic to the self-IP address is not affected by the port lockdown list and is implicitly
allowed in all cases.
Page 30 of 91
Port lockdown setting definitions:
Allow Default
Allowed
protocol
Service
Service definition
OSPF
N/A
N/A
TCP
4353
iQuery
UDP
4353
iQuery
TCP
443
HTTPS
TCP
161
SNMP
UDP
161
SNMP
TCP
22
SSH
TCP
53
DNS
UDP
53
DNS
UDP
520
RIP
UDP
1026
network failover
[root@asm] config # tmsh list net selfallow
net self-allow {
defaults {
ospf:any
tcp:domain
tcp:f5-iquery
tcp:https
tcp:snmp
tcp:ssh
udp:520
udp:cap
udp:domain
udp:f5-iquery
udp:snmp
}
}
Allow All
This option specifies that all connections to the self IP address are allowed
Allow None This option specifies that no connections are allowed on the self IP address. However, ICMP
traffic is always allowed.
Allow Custom
This option allows you to specify the protocols and services for which connections are
allowed on the self IP address. However, ICMP traffic is always allowed.
When creating a self IP address, the default port lockdown setting in BIG-IP 10.x is Allow Default. In BIG-IP
11.x, the default port lockdown setting is None.
# tmsh modify /net self self_VLAN_Pruebas allow-service default
config
#
tmsh
save
/sys
SOL3475: The BIG-IP system may not respond to ICMP ping requests for a self IP address
To enhance system security, a BIG-IP self IP address will not respond to an ICMP request arriving on a
VLAN which the self IP is not configured.
However, the BIG-IP self IP will respond to the ICMP request if any of the following conditions is met:
 The request arrived on the VLAN which the self IP address is configured
 The request arrives on the VLAN which a virtual server is configured to use the self IP address as its
destination IP address
Note: By default, all VLANs are enabled when a virtual server is created.
For example, assume you have configured the following self IP addresses and a virtual server, enabled on
the external VLAN:
self 10.10.65.65 {
netmask 255.255.255.0
vlan internal
}
self 172.16.66.66 {
netmask 255.255.255.0
vlan external
}
virtual http_vip {
pool http_pool
destination 10.10.65.65:http
ip protocol tcp
vlans internal enable
Page 31 of 91
}
virtual http_vip {
pool http_pool
destination 172.16.66.100:http
ip protocol tcp
vlans external enable
}
The following table represents the results you can expect from the above configuration when sending ICMP
requests to the self IP addresses from various network locations relative to the BIG-IP system:
Origin
Destination
Result
Comentarios
10.10.65.x (or forwarded by router on internal
VLAN)
172.16.66.66
BIG-IP ignores
request
O i -> D e S
10.10.65.x (or forwarded by router on internal
VLAN)
10.10.65.65
BIG-IP responds
O i -> D i S=VS

172.16.66.x (or forwarded by router on external
VLAN)
172.16.66.66
BIG-IP responds
O e -> D e S

172.16.66.x (or forwarded by router on external
VLAN)
10.10.65.65
BIG-IP responds
O e -> D i S=VS

10.10.65.x (or forwarded by router on internal
VLAN)
172.16.66.100
BIG-IP ignores
request
O i -> D e VS≠S


4.3 Check and interpret packet filters in order to determine the cause of a management connectivity
issue.
Manual Chapter: Packet Filters (11.2.x)
Introduction to packet filtering
Packet filters enhance network security by specifying whether a BIG-IP system interface should accept or
reject certain packets based on criteria that you specify. Packet filters enforce an access policy on incoming
traffic. They apply to incoming traffic only.
The primary purpose of a packet filter rule is to define the criteria that you want the BIG-IP system to use
when filtering packets. Examples of criteria that you can specify in a packet filter rule are:
a) The source IP address of a packet b) The destination IP address of a packet c) The destination port of a
packet
You specify the criteria for applying packet filter rules within an expression. When creating a packet filter rule,
you can instruct the BIG-IP system to build an expression for you, in which case you need only choose the
criteria from predefined lists, or you can write your own expression text, using the syntax of
the tcpdump utility.
BIG-IP Configuration utility, and on the Main tab, expand Network, and click Packet Filters
Global settings
Properties
 Packet filter enabling. The default setting for packet filtering is Disabled.
 Control of unhandled packets. Specifies the action that the BIG-IP system should take when the packet
does not match packet filter rule criteria. Possible values for this setting are Accept (def), Discard, and
Reject.
Other options:
a) Filter established connections, b) Send ICMP error on packet reject
Global exemptions
There are a number of exemptions you can set for packet filtering. When filtering packets, the BIG-IP
system always applies these exemptions, effectively overriding certain criteria you might have previously
set within an individual packet filter rule.
Protocols:  Always accept ARP  Always accept important ICMP
MAC addresses: Always Accept, None
IP addresses: Always Accept, None
Page 32 of 91
VLANs:
Always Accept,
None
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.
Configuring settings for packet filter rules
a) Name
b) Order of packet filter rules: First, Last, After
c) Action: Accept, Discard, Reject, Continue
d) Rate class assignment: None
e) VLAN/Tunnel: * ALL
f) Logging: Enabled, Disabled
g) Creating a filter expression: To match incoming packets, the BIG-IP system must use a filter
expression. A filter expression specifies the criteria that you want the BIG-IP system to use when filtering
packets.
My Example:
[root@asm:Active:Standalone] config # tmsh list net packet-filter-trusted
net packet-filter-trusted {
ip-addresses { 10.2.0.13 }
}
[root@asm:Active:Standalone] config # tmsh list net packet-filter
net packet-filter reglapf1_https_configutil_accept {
action accept
logging enabled
order 5
rule "( src host 10.2.0.13 )"
}
net packet-filter reglapf2_https_configutil_discard {
action discard
logging enabled
order 10
rule "( dst host 10.3.1.153 or dst host 10.3.2.216 ) and ( dst port 443 )"
}
[root@asm:Active:Standalone] config #
Page 33 of 91
Manual Chapter: Configuring Packet Filters (v9.x)
Lo mismo que el anterior en versión 9.x
Manual Chapter: Setting Up Packet Filtering (v10.x)
By setting up some basic IP routing and configuring packet filtering, specific hosts on the internal VLAN can
connect to the internal VLANs self IP address. These hosts can also use common Internet services such as
HTTP, HTTPS, DNS, FTP, and SSH. Traffic from all other hosts in the internal VLAN is rejected.
To configure this implementation, you must:
 Create a SNAT [automap , Vlan Enabled on=Internal & External]
 Create a pool of routers (also known as a gateway pool).
 Create a forwarding virtual server. [Type=Network, Address=0.0.0.0, Mask=0.0.0.0, Service Port= *
All Ports, Vlan Enabled on=Internal, Default Pool= Gateway Pool]
 Create a packet filter rule.[Action=Reject, Vlan=Internal, Enter Expression Test]
not dst port 80 and not dst port 443 and not dst port 53 and no dst port 22 and not dst port 20 and not
dst port 21 and not dst host <internal self IP address>
Note: The BIG-IP system contains an implementation of IP filters. The syntax for a filter expression is based
on libpcap and is synonymous with the tcpdump utility syntax. The system applies packet filters to self IP
addresses and virtual servers, but does not apply them to the management interface. The system stores
packet filters in the bigip.conf file, and shares them with any existing failover peer in a redundant system
configuration.
Page 34 of 91
4.4 Given the use of a remote authentication server, verify proper DNS settings in order to diagnose a
connectivity issue.
Manual Chapter: Remote Server Authentication (LTM 11.2.0)
A significant feature of BIG-IP Local Traffic Manager is its ability to support Pluggable Authentication Module
(PAM) technology. PAM technology allows you to choose from a number of different authentication and
authorization schemes to use to authenticate or authorize network traffic.
The goal of PAM technology is to separate an application, such as the BIG-IP system, from its underlying
authentication technology. This means that you can dictate the particular authentication/authorization
technology that you want the BIG-IP system to use to authenticate application traffic coming into the BIG-IP
system.
To this end, Local Traffic Manager offers several authentication schemes, known as authentication modules.
These authentication modules allow you to use a remote system to authenticate or authorize application
requests that pass through the BIG-IP system.
Note: The BIG-IP system normally routes remote authentication traffic through a Traffic Management
Microkernel (TMM) switch interface (that is, an interface associated with a VLAN and a self IP address),
rather than through the management interface. Therefore, if the TMM service has been stopped for any
reason, remote authentication is not available until the service is running again.
BIG-IP system authentication modules
Local Traffic Manager authentication modules that you can implement for remote authentication are:
 Lightweight Directory Access Protocol (LDAP)
 Remote Authentication Dial-In User Service (RADIUS)
 TACACS+
 SSL client certificate LDAP
 Online Certificate Status Protocol (OCSP)
 Certificate Revocation List Distribution Point (CRLDP)
 Kerberos Delegation
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).
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.
LDAP configuration object settings
Remote LDAP Tree Specifies the search base distinguished name.
Hosts
Lists the addresses of the LDAP servers that the BIG-IP system uses to obtain authentication data.
Service Port Specifies the port number for the LDAP service.
389 (non-SSL), 636 (SSL-enabled)
LDAP Version
Specifies the version number of the LDAP application.
3
Bind DN
Specifies the distinguished name of an account to which to bind, in order to perform searches.
The admin account can be used as the search account.
SSL
Allowed values are: Enabled, Disabled, and Start TLS. Note that when enabled, the BIG-IP system
changes the service port number from 389 to 636. (def. Disabled)
LDAP profile configuration settings
Mode
[Enabled, Auto, Disabled]
Configuration
Specifies an existing LDAP configuration object. This setting is required.
Rule
_sys_auth_ldap
Idle Timeout [Specify… 300 seconds | Indefinite]
Page 35 of 91
My Example:
[root@asm:Active:Standalone] config #
tmsh list /ltm auth
ltm auth ldap Mi_LDAPconfig {
search-base-dn
"CN=Jeff
Smith,OU=Sales,DC=Fabrikam,DC=COM"
servers { 10.1.1.243 }
}
ltm auth profile Mi_LDAPprofile {
app-service none
configuration Mi_LDAPconfig
credential-source http-basic-auth
defaults-from ldap
type ldap
}
The RADIUS authentication module
A RADIUS authentication module is a mechanism for authenticating client connections passing through a
BIG-IP system. You use this module when your authentication data is stored on a remote RADIUS server. In
this case, client credentials are based on basic HTTP authentication (that is, user name and password).
RADIUS server object configuration settings
Host
Specifies a host name or IP address for the RADIUS server. This setting is required.
Service Port Specifies the port for RADIUS authentication traffic. 1812
Secret
Sets the secret key used to encrypt and decrypt packets sent or received from the server.
Timeout
Specifies a timeout value. 3
RADIUS configuration object settings
RADIUS Servers
authentication data.
Client ID
Lists the IP addresses of the RADUIS servers that the BIG-IP system will use to obtain
Sends a NAS-Identifier RADIUS attribute with string bar. If you do not specify a value for the
Client ID setting, the PAM service type is used instead.
Specifies the number of authentication retries that the BIG-IP system allows before
authentication fails. 3RADIUS profile configuration settings
Mode
Specifies whether the profile is enabled (def) or disabled or auto.
Configuration
Specifies an existing RADIUS configuration object.
Rule
_sys_auth_radius
Idle Timeout [Specify… 300 seconds | Indefinite]
My Example:
[root@asm:Active:Standalone] config # tmsh list /ltm auth
The TACACS+ authentication moduleA TACACS+ authentication module is a mechanism for
authenticating client connections passing through a BIG-IP system. You use this module when your
authentication data is stored on a remote TACACS+ server. In this case, client credentials are based on
basic HTTP authentication (that is, user name and password).TACACS+ configuration object settingsServers
Specifies a host name or IP address for the TACACS++ server.
Secret
Sets the secret key used to encrypt and decrypt packets sent or received from the server.
Encryption Enables or disables encryption of TACACS+ packets. (def. Enabled)
Service Name
Specifies the name of the service that the user is requesting to be authorized to use. You can use
following values: slip, ppp, arap, shell, tty-daemon, connection, system, and firewall.
Protocol Name
Specifies the protocol associated with the value specified in the Service Name setting.
Authentication
Possible values are: Authenticate to first server or Authenticate to each server until
successAccounting Information
Possible values are Send to first available server or Send to all
servers.TACACS+ profile configuration settings Mode Specifies whether the profile is enabled (def) or disabled or
auto.
Configuration
Specifies an existing TACACS+ configuration object.
Rule
_sys_auth_tacacs
Idle Timeout [Specify… 300 seconds | Indefinite]
[root@asm:Active:Standalone] config # tmsh list /ltm auth
The SSL client certificate LDAP authentication module
Page 36 of 91
An SSL client certificate LDAP authentication module is a mechanism for authorizing client connections
passing through a BIG-IP system. With the SSL client certificate LDAP authentication module, you can use a
remote LDAP server to impose access control on application traffic. The module bases this access control on
SSL certificates, as well as user groups and roles that you specify.
SSL client certificate authorization
Before you can implement an SSL client certificate LDAP module, you must understand the two different
types of credentials that the BIG-IP system uses to authorize application traffic using data on a remote LDAP
server. These two types of credentials are:
 SSL certificates
 Groups and roles
With SSL client certificate LDAP authorization, Local Traffic Manager can authorize clients based on signed
client certificates issued by trusted CAs. Then, to further enhance the ability of the system to authorize client
requests, you can also specify groups and roles. Basing authorization on certificates as well as groups and
roles provides the flexibility you need to control client access to system resources.
SSL certificates for LDAP authorization
During the process of authorizing a client, Local Traffic Manager must search the LDAP database.
When using certificate-based authorization, the system can search the LDAP database in three ways:
User. If certificates are not stored in the LDAP database, you can configure the system to
extract a user name from the certificate presented as part of the incoming client request. The
system then checks to see if an entry for the user exists in the LDAP database. This scenario
is a good choice for a company that acts as its own Certificate Authority, where the company
is assured that if the certificate is verified, then the user is authorized.
Certificate Map. If you create an object and class that map certificates to users in the LDAP
database, you can then configure the system to search for a certificate in the map, and
retrieve a user from that map. The system then checks to ensure that the user in the LDAP
database is a valid user.
Certificate. Many LDAP server environments already incorporate certificates into the user
information stored in the LDAP database. One way of configuring authorization in LDAP
server environments is to configure the system to compare an incoming certificate to the
certificate stored in the LDAP database for the user associated with the client request. If the
certificate is found in the users LDAP profile, access is granted to the user, and the request is
granted.Groups and roles for LDAP authorizationIn addition to enabling certificate-based
authorization, you can also configure authorization based on groups and roles.
Groups. Because LDAP servers already have the concept and structure of groups built into
them, Local Traffic Manager can include groups in its authorization feature. To enable the
use of groups for authorization purposes, you must indicate the base and scope under which
the system will search for groups in the LDAP database. Also, you must specify setting
values for a group name and a member name. Once you have completed these tasks, the
system can search through the list of valid groups until a group is found that has the current
user as a member.Unlike a group, a role is a setting directly associated with a user. Any rolebased authorization that Local Traffic Manager performs depends on the LDAP database
having the concept of roles built into it. To determine if a user should be granted access to a
resource, Local Traffic Manager searches through the roles assigned to the user and
attempts to match that role to a valid role defined by the administrator.SSL client certificate
LDAP configuration object settingsHosts
Lists the IP addresses, including port numbers, of the LDAP servers that
the BIG-IP system will use to obtain authorization data.
Search Type Specifies the certificate-based authorization method that the system uses when searching the LDAP
database (User, Certificate Map, CertificateUser Base DNSpecifies the search base for the subtree used by the User and
Certificate search types. A typical search base is:ou=people,dc=company,dc=com.
User Key
Specifies the name of the attribute in the LDAP database that specifies a user ID. Used by the User and
Certificate search type. A typical example of a user key value is uid.
SSL client certificate LDAP authorization profile settings
Mode
Specifies whether the profile is enabled (def) or disabled or auto.
Configuration
Specifies an existing SSL client certificate LDAP configuration
object.
Rule
_sys_auth_ssl_cc_ldap
Idle Timeout [Specify… 300 seconds | Indefinite]
Page 37 of 91
My Example:
ltm auth profile Mi_SSLclientCertificate_LDAP_profile {
app-service none
configuration Mi_SSLclientCertificateLDAP_config
credential-source http-basic-auth
defaults-from ssl_cc_ldap
type ssl-cc-ldap
}
ltm auth ssl-cc-ldap Mi_SSLclientCertificateLDAP_config
{
servers { 10.3.3.2:389 }
user-base ou=people,dc=it-solutions,dc=com
user-key uid
}
The SSL OCSP authentication module
An SSL OCSP authentication module is a mechanism for authenticating client connections passing through a
BIG-IP system. More specifically, an SSL OCSP authentication module checks the revocation status of an
SSL certificate, as part of authenticating that certificate.Online Certificate Status Protocol (OCSP) is a thirdparty software application and industry-standard protocol that offers an alternative to a certificate revocation
list (CRL) when using public-key technology. A CRL is a list of revoked client certificates, which a server
system can check during the process of verifying a client certificate.
You implement an SSL OCSP authentication module when you want to use OCSP instead of a CRL as the
mechanism for checking the revocation status of SSL certificates.
Local Traffic Manager supports both CRLs and the OCSP protocol. If you want to use CRLs instead of
OCSP, you configure an SSL profile.
The benefits of OCSP
OCSP ensures that Local Traffic Manager always obtains real-time revocation status during the certificate
verification process. OCSP is based on a client/server model, where a client system requests revocation
status of a certificate, and a server system sends the response. Thus, when you implement the SSL OCSP
authentication module, the BIG-IP system acts as the OCSP client, and an external system, known as an
OCSP responder, acts as the OCSP server. An OCSP responder is therefore an external server that sends
certificate revocation status, upon request, to the BIG-IP system.
How does OCSP work?
In general, after receiving an SSL certificate from a client application, the BIG-IP system (acting as an OCSP
client) requests certificate revocation status from an OCSP responder, and then blocks the connection until it
receives status from that responder. If the status from the responder shows that the certificate has been
revoked, Local Traffic Manager rejects the certificate and denies the connection. If the status from the
responder shows that the certificate is still valid, Local Traffic Manager continues with its normal certificate
verification process to authenticate the client application.
OCSP responder object configuration settings
URL
Specifies the URL used to contact the OCSP service on the responder.
Certificate Authority File
Specifies the name of the file containing trusted CA certificates used to verify the
signature on the OCSP response.
SSL OCSP configuration object settingsType
Specifies the type of authentication module you want
to implement.
SSL OCSP
Responders Specifies the OCSP responders that you want to use for checking that revocation status of SSL
certificates.SSL OCSP profile configuration settings Mode
Specifies whether the profile is enabled (def) or disabled or
auto.
Configuration Specifies an existing OCSP configuration object.
Rule _sys_auth_ssl_ocsp
Idle Timeout [Specify… 300 seconds | Indefinite]
The CRLDP authentication moduleA CRLDP authentication module is a mechanism for authenticating
client connections passing through a BIG-IP system. You implement a CRLDP authentication module when
you want the BIG-IP system to use CRL distribution points as the mechanism for checking the revocation
status of SSL certificates.This CRLDP authentication feature is based on a technology known as Certificate
Revocation List Distribution Points (CRLDP). CRLDP is an industry-standard protocol that offers an
alternative method for checking a standard certificate revocation list (CRL) to determine revocation status.
CRLDP is also an alternative to using Online Certificate Status Protocol (OCSP).CRLDP configuration object
settingsConnection Timeout 15
Page 38 of 91
Update Interval
0
Use Issuer Indicates whether the CRL distribution point should be extracted from the certificate of the client certificate
issuer.
Disabled
CRLDP Servers
Lists the IP addresses of the CRLDP servers that the BIG-IP system will use to obtain
authentication data.
CRLDP profile settingsMode Specifies whether the profile is enabled (def) or disabled or auto.
Configuration Specifies an existing CRLDP configuration object.
Rule _sys_auth_ssl_crldp
Idle Timeout [Specify… 300 seconds | Indefinite]
The Kerberos Delegation authentication moduleA Kerberos Delegation authentication module is a
mechanism for authenticating client connections passing through a BIG-IP system. You can use this module
when you are using Microsoft Windows Integrated Authentication to authenticate application traffic.
The Kerberos Delegation module obtains delegated Kerberos credentials for the client principal, and then
retrieves Kerberos credentials for the server-side principal. The Kerberos Delegation module essentially acts
as a proxy for Kerberos credentials. That is, when connecting to a server that is inside its domain, the
browser client fetches Kerberos credentials. These credentials, known as delegated credentials, are passed
to the BIG-IP system, which in turn retrieves credentials for the real server that is on the back end, and
passes those credentials back to the client.
Kerberos Delegation configuration object settingsClient Principal Name
Specifies the name of the
client principal, using the format HTTP/<fqdn>, where fqdn is the fully-qualified domain name of the virtual server you
create.Server Principal Name
Specifies the name of the principal of the back-end web server, using the format
HTTP/<fqdn>, where fqdn is the fully-qualified domain name of the web server in the pool.Kerberos Delegation profile
settingsMode
Specifies whether the profile is enabled (def) or disabled or auto.
Configuration Specifies an existing Kerberos Delegation configuration object.
Rule _sys_auth_krbdelegate
Idle Timeout [Specify… 300 seconds | Indefinite]
Cookie Name
Specifies a unique name for the cookie that you want to associate with this profile.
Cookie Key Specifies an encryption key, in the form of a strong password, for encrypting cookie data
f5auth
abc123
Manual Chapter: Configuring Remote User Authentication and
Authorization (11.2.0)
The BIG-IP system includes a comprehensive solution for managing BIG-IP administrative accounts on your
network. With this solution, you can:
Use a remote server to store BIG-IP system user accounts.
The BIG-IP system includes support for using a remote authentication server to store BIG-IP system
user accounts. After creating BIG-IP system accounts on the remote server (using the server
vendor's instructions), you can configure the BIG-IP system to use remote user authentication and
authorization (access control) for that server type.
Assign group-based access.
The BIG-IP system includes an optional feature known as remote role groups. With the remote role
groups feature, you can use existing group definitions on the remote server to define the access
control properties for users in a group. This feature not only provides more granularity in assigning
user privileges, but also removes any need to duplicate remote user accounts on the BIG-IP system
for the purpose of assigning those privileges.
Propagate a set of authorization data to multiple BIG-IP systems.
Page 39 of 91
The BIG-IP system includes a tool for propagating BIG-IP system configuration data to multiple BIGIP devices on the network. This tool is known as the Single Configuration File (SCF) feature.
Page 40 of 91
You can configure the BIG-IP system to authorize user accounts that are stored on a remote authentication
server.
Specifying LDAP or Active Directory server information
Before you begin:
 Verify that the BIG-IP system user accounts have been created on the remote authentication server.
 Verify that the appropriate user groups, if any, are defined on the remote authentication server.
 If you want to verify the certificate of the authentication server, import one or more SSL certificates.
You can configure the BIG-IP system to use an LDAP or Microsoft Windows Active Directory server for
authenticating BIG-IP system user accounts, that is, traffic that passes through the management interface
(MGMT).
Important: The values you specify in this procedure for the Role, Partition Access, and Terminal
Access settings do not apply to group-based authorization. These values represent the default values that
the BIG-IP system applies to any user account that is not part of a remote role group.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
On the Main tab, click System > Users.
On the menu bar, click Authentication.
Click Change.
From the User Directory list, select Remote - LDAP or Remote - Active Directory.
In the Host field, type the IP address of the remote server.
For the Port setting, retain the default port number (389) or type a new port number.
In the Remote Directory Tree field, type the file location (tree) of the user authentication database on the LDAP
or Active Directory server. At minimum, you must specify a domain component (that is, dc=[value]).
For the Scope setting, retain the default value (Sub) or select a new value. This setting specifies the level of the
remote server database that the BIG-IP system should search for user authentication.
For the Bind setting, specify a user ID login for the remote server:
1. In the DN field, type the distinguished name for the remote user ID.
2. In the Password field, type the password for the remote user ID.
3. In the Confirm field, re-type the password that you typed in the Password field.
To enable SSL-based authentication, from the SSL list select Enabled and, if necessary, configure these
settings:
1. From the SSL CA Certificate list, select the name of a chain certificate, that is, the third-party CA or
self-signed certificate that normally resides on the remote authentication server.
2. From the SSL Client Key list, select the name of the client SSL key. Use this setting only when the
remote server requires that the client present a certificate.
3. From the SSL Client Certificate list, select the name of the client SSL certificate. Use this setting only if
the remote server requires that the client present a certificate.
From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP user
accounts authenticated on the remote server:
From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-IP
user accounts can access.
From the Terminal Access list, select one of the following as the default terminal access for remotelyauthenticated user accounts: Disabled, tmsh, Advanced shell
Click Finished.
Specifying client certificate LDAP server information
Verify that the required user accounts for the BIG-IP system exist on the remote authentication server.
For authenticating BIG-IP system user accounts (that is, traffic that passes through the management
interface [MGMT]), you can configure the BIG-IP system to authenticate certificates issued by a certificate
authority's Online Certificate Status Protocol (OCSP) responder.
1.
2.
3.
4.
5.
6.
7.
On the Main tab, click System > File Management > Apache Certificate List > Import, browse for the certificate
file to import, type a name, and click Import. The certificate will be added to the Apache Certificate list.
On the Main tab, click System > Users.
On the menu bar, click Authentication.
Click Change.
From the User Directory list, select Remote - ClientCert LDAP.
In the Host field, type the IP address of the remote server.
For the Port setting, retain the default port number (389) or type a new port number. This number represents the
port number that the BIG-IP system uses to access the remote server.
Page 41 of 91
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
In the Remote Directory Tree field, type the file location (tree) of the user authentication database on the client
certificate server. At minimum, you must specify a domain component (that is, dc=[value]).
For the Scope setting, retain the default value (Sub) or select a new value. This setting specifies the level of the
remote server database that the BIG-IP system should search for user authentication.
For the Bind setting, specify a user ID login for the remote server:
a. In the DN field, type the distinguished name for the remote user ID.
b. In the Password field, type the password for the remote user ID.
c. In the Confirm field, re-type the password that you typed in the Password field.
To enable SSL-based authentication, from the SSL list select Enabled and, if necessary, configure these
settings:
a. From the SSL CA Certificate list, select the name of a chain certificate; that is, the third-party CA or
self-signed certificate that normally resides on the remote authentication server.
b. From the SSL Client Key list, select the name of the client SSL key. Use this setting only when the
remote server requires that the client present a certificate.
c. From the SSL Client Certificate list, select the name of the client SSL certificate. Use this setting only if
the remote server requires that the client present a certificate.
In the CA Certificate field, type the absolute folder path of apache-ssl-cert fileobject for the CA signing authority.
The absolute folder path is /Common/<folder path>/<certificate name>. To determine the absolute folder path of
the apache-ssl-cert fileobject, click System > File Management > Apache Certificate List and note the target
certificate's partition and path.
Important: Apache certificates can only be stored within /Common.
/>
In the Login Name field, type an LDAP search prefix that will contain the distinguished name (DN) from the user
certificate, such as CN. This specifies the LDAP attribute to be used as a login name. The default is disabled.
In the Login LDAP Attribute field, type the account name for the LDAP server. The value for this option is
normally the user ID. However, if the server is a Microsoft Windows Active Directory server, the value must be
the account name sAMAccountName (case-sensitive). The default value is none.
In the Login Filter field, type the LDAP attribute that contains the short name of the user. This specifies the filter
to be applied on the common name (CN) of the client certificate and usually this is the user ID or
sAMAccountName. The filter is a regular expression used to extract required information from the CN of the
client certificate that is matched against the LDAP search results. The default is disabled.
For the Depth setting, retain the default value (10) or type a new value for verification depth.
From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP system
user accounts authenticated on the remote server.
From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-IP
system user accounts can access.
From the Terminal Access list, select either of these as the default terminal access option for remotelyauthenticated user accounts: Disabled, tmsh
Click Finished.
Specifying RADIUS server information
Prerrequisites:
 Verify that the BIG-IP system user accounts have been created on the remote authentication server.
 Verify that the appropriate user groups, if any, are defined on the remote authentication server.
You can configure the BIG-IP system to use a RADIUS server for authenticating BIG-IP system user
accounts, that is, traffic that passes through the management interface (MGMT).
1.
2.
3.
4.
5.
6.
7.
8.
On the Main tab, click System > Users.
On the menu bar, click Authentication.
Click Change.
From the User Directory list, select Remote - RADIUS.
From the Server Configuration list, select one of the following options:
a. Primary Only: Specifies that you are using a single RADIUS server only for user authentication.
b. Primary and Secondary: Specifies that you are using a primary RADIUS server plus a secondary
RADIUS server, in case the primary server becomes unavailable.
For the Primary setting:
1. In the Host field, type the name of the primary RADIUS server.
2. In the Secret field, type the password for access to the primary RADIUS server.
3. In the Confirm field, re-type the RADIUS secret.
If you set the Server Configuration setting to Primary and Secondary, then for the Secondary setting:
1. In the Host field, type the name of the secondary RADIUS server.
2. In the Secret field, type the password for access to the secondary RADIUS server.
3. In the Confirm field, re-type the RADIUS secret.
From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP user
accounts stored on the remote server:
Page 42 of 91
9.
From the Partition Access list, select the administrative partition that all remotely-authenticated BIG-IP user
accounts can access.
10. From the Terminal Access list, select one of the following options as the default terminal access for remotelyauthenticated user accounts: Disabled, tmsh, Advanced Shell.
11. Click Finished.
Specifying TACACS+ server information
Prerrequisites:
 Verify that the BIG-IP system user accounts have been created on the remote authentication server.
 Verify that the appropriate user groups, if any, are defined on the remote authentication server.
You can configure the BIG-IP system to use a TACACS+ server for authenticating BIG-IP system user
accounts, that is, traffic that passes through the management interface (MGMT).
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
On the Main tab, click System > Users.
On the menu bar, click Authentication.
Click Change.
From the User Directory list, select Remote - TACACS+.
For the Servers setting, type an IP address for the remote TACACS+ server. The route domain to which this
address pertains must be route domain 0.
Click Add. The IP address for the remote TACACS+ server appears in the Servers list.
In the Secret field, type the password for access to the TACACS+ server.
In the Confirm Secret field, re-type the TACACS+ secret.
From the Encryption list, select an encryption option: Enabled, or Disabled.
In the Service Name field, type the name of the service that the user is requesting to be authenticated to use
(usually ppp). Specifying the service causes the TACACS+ server to behave differently for different types of
authentication requests. Examples of service names that you can specify are: ppp, slip, arap, shell, tty-daemon,
connection, system, and firewall.
In the Protocol Name field, type the name of the protocol associated with the value specified in the Service
Namefield. This value is usually ip. Examples of protocol names that you can specify are: ip, lcp, ipx, atalk,
vines, lat, xremote, tn3270, telnet, rlogin, pad, vpdn, ftp, http, deccp, osicp, and unknown.
From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP user
accounts stored on the remote server:
From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-IP
user accounts can access.
From the Terminal Access list, select one of the following options as the default terminal access for remotelyauthenticated user accounts: Disabled, tmsh, Advanced shell.
Click Finished.
Assigning access control properties to user groups
On the BIG-IP system, you can configure access control properties (privileges) for existing user groups that
are defined on a remote authentication server. For example, if the configuration of a remote LDAP
authentication
server
includes
the
attribute
string memberOF=cn=BigIPOperatorsGroup,cn=users,dc=dev,dc=net, you can assign a specific set of
access control properties to all user accounts in the group BigIPOperatorsGroup.
1.
2.
3.
4.
On the Main tab, click System > Users.
On the menu bar, click Remote Role Groups.
Click Create.
In the Group Name field, type the group name that is defined on the remote authentication server. An example
of a group name is BigIPOperatorsGroup.
5. In the Line Order field, type a number. An example of a line order is 1.
6. In the Attribute String field, type an attribute. An example of an attribute string is member
OF=cn=BigIPOperatorsGroup,cn=users,dc=dev,dc=net. The BIG-IP system attempts to match this attribute with
an attribute on the remote authentication server. On finding a match, the BIG-IP system applies the access
control settings defined here to the users in that group. If a match is not found, the system applies the default
access control settings to all remotely-stored user accounts (excluding any user account for which access
control settings are individually configured).
7. From the Remote Access list, select a value. Enabled, or Disabled.
8. From the Assigned Role list, select a user role for the remote user group.
9. From the Partition Access list, select an administrative partition value.
10. From the Terminal Access list, select the type of command-line access you want to grant users in the group, if
any.
11. Click Finished.
Page 43 of 91
Saving access control settings to a file
You can save the running configuration of the system, including all settings for remote user authentication
and authorization, in a flat, text file with a specified name and the extension .scf. (Single Configuration File)
1.
2.
3.
On the BIG-IP system, access a command-line prompt.
At the prompt, open the Traffic Management Shell by typing the command tmsh.
Type:
root@(asm)(cfg-sync Standalone)(Active)(/Common)(tmos)# save sys config file
MiConfig.scf
Saving running configuration...
/var/local/scf/MiConfig.scf
/var/local/scf/MiConfig.scf.tar
root@(asm)(cfg-sync Standalone)(Active)(/Common)(tmos)# save sys config file
/config/MiConfig
Saving running configuration...
/config/MiConfig
/config/MiConfig.tar
You can now import this file onto other BIG-IP devices on the network.
Importing BIG-IP configuration data onto other BIG-IP systems
1.
2.
3.
4.
5.
On the BIG-IP system on which you created the SCF, access a command-line prompt.
Copy the SCF that you previously created to a location on your network that you can access from the system
that you want to configure.
Edit the SCF to reflect the management routing and special passwords of the BIG-IP system that you want to
configure:
a. Open the SCF in an editor.
b. Where necessary, change the values of the management IP address, network mask, management
default route, self IP addresses, virtual server IP addresses, routes, default routes, and host name
fields to the values for the new system.
c. If necessary, change the passwords for the root and admin accounts.
d. Save the edited SCF.
On the BIG-IP system that you want to configure, open the Traffic Management Shell by typing the
command tmsh.
Type # load sys config myConfiguration053107.scf saves a backup of the running configuration in
the /var/local/scf directory, and then resets the running configuration with the configuration contained in the SCF
you are loading.
5.1 Identify the appropriate supporting components and severity levels for an F5Support ticket.
SOL2633: Instructions for submitting a support case to F5
Important: To open a support case with F5 Technical Support, or to register for access to the WebSupport
portal, you must have an active support contract, and you must be authorized to open support cases against
that contract. Only authorized contacts can open technical support cases with F5 Technical Support.
a) Contacting F5 Technical support by telephone
a.
Outside North America, Universal Toll-Free
+800 11 ASK 4 F5 or (800 11275 435)
b) Contacting F5 Technical support online
You can also contact F5 Technical Support online at the WebSupport Portal. To do so, you must first register
for access to the WebSupport portal.
To register for access to the WebSupport portal, perform the following procedure:
a) Log in to https://login.f5.com.
b) Under the Other Sites You May Apply For heading, in the WebSupport section, click the <click here>
link.
c) Complete the registration page.
You will be notified by email within 24 hours that your account has been enabled with WebSupport portal
access.
Product-Specific Information
For BIG-IP WebAccelerator
Page 44 of 91



Provide an explanation of the BIG-IP WebAccelerator deployment topology (asymmetrical or symmetrical
including number of accelerators). A Visio network diagram is preferable.
Provide an XML export of any relevant policies. Policies can be exported individually from the Polices
page of the Admin Tool Web UI.
If the WebAccelerator pvac (v9.x/v10.x) or wamd (v11.x) daemon is experiencing performance issues,
provide the result of a continuous top command. Type the following command, and provide the file
produced:
# top -cbn 10 -d 1 > /var/tmp/top_output.sol6705.txt
For BIG-IP APM
 BIG-IP APM access profiles should also be provided to F5 Technical Support when troubleshooting BIGIP APM issues. Exported access profiles are saved as files with the .conf extension.
 Client specific information. The remaining items are needed if the issue is specific to a particular client:
Operating system, version and patch level, Browser type and version, SSL VPN client log file information
For BIG-IP ASM
 Exported Security Policy. You should export the active security policy so F5 Technical Support can
review it.
 The asm_snapshot file. If the BIG-IP ASM system is running as a standalone system, you can run the
asmqkview script to generate an asm_snapshot file. The asm_snapshot file contains the configuration
files that F5 Technical Support most frequently needs when troubleshooting a BIG-IP ASM issue. An
asm_snapshot file is produced by the asmqkview utility.
SOL135: Information required when opening a support case for BIG-IP LTM, AFM, GTM, Link Controller, and
PEM
F5 Technical Support can help resolve issues more quickly when you provide a full description of the issue
and the details of your configuration. To help you gather all the required information, use the following
guidelines to prepare for opening a case:
General Information
Provide the following information when you open a case with F5 Technical Support:
 A full description of the issue, including the following details:
o The symptoms of the issue
o The approximate time the issue first occurred
o The number of times the issue has recurred
o Any error output provided by the system
o Steps to reproduce the issue
o Any changes you made to the system before the issue first occurred
o Any steps you have attempted to resolve the issue
 A description of the impact the issue is having on your site, using the following definitions:
o Site Down
All network traffic has ceased, causing a critical impact to your business.
o Site at Risk
Primary unit has failed resulting in no redundancy. Site is at risk of going down.
o Performance Degraded
Network traffic is partially functional causing some applications to be unreachable.
o General Assistance
Questions regarding configurations. Troubleshooting non-critical issue or request for product
functionality that is not part of the current product feature set.
 The hours that you are available to work on the issue and any alternative contacts that can work on
the issue if you are not available.
 Remote access information, if possible.
Product specific information
Collect the following information from the affected systems and provide the information when you open the
case.
A tech.out file contains the configuration files that F5 Technical Support most frequently needs when
troubleshooting
an
issue.
A tech.out file
is
produced
by
the qkview utility
and
the
terms tech.out and qkview may be used interchangeably.
The tech.out file contains the log files for the last day. If the issue has existed for more than a day, provide all
the log files on the system by performing the following procedure:
Page 45 of 91
1. Create a tar archive named logfiles.tar.gz in the /var/tmp directory which contains all the files in the
/var/log directory, by typing the following command: # tar -czpf /var/tmp/logfiles.tar.gz
/var/log/*
Packet traces. If the issue involves the network, perform a packet trace while the issue is occurring and
provide the packet trace when you open the case.
UCS archive. If you cannot give F5 Technical Support remote access to your system, you must provide a
UCS archive of the current configuration.
Core files. Core files contain the contents of the system memory at the time a crash occurred. If the system
has been configured to save core files, they will be located in /var/core directory (BIG-IP versions 9.3 and
later). Provide any existing core files when you open the case.
SOL12878: Generating BIG-IP diagnostic data using the qkview utility (10.x - 11.x)
Purpose
 You want to verify the proper operation of your BIG-IP system by uploading the qkview diagnostic
data to BIG-IP iHealth.
 You want to provide diagnostic data to F5 Technical Support to aid in troubleshooting an issue with a
BIG-IP or Enterprise Manager system.
Starting in BIG-IP 10.0.0, the qkview utility is an executable program that generates machine-readable (XML)
diagnostic data from the BIG-IP or Enterprise Manager system and combines the data into a single
compressed tar file. The diagnostic file can then be uploaded to BIG-IP iHealth, or given to F5 Technical
Support to aid in troubleshooting.
[root@asm:Active:Standalone] config # qkview
Gathering System Diagnostics: Please wait ...
Core files found are being included.
Diagnostic information has been saved in:
/var/tmp/asm.appdeliver.com.tgz
Please send this file to F5 support.
In BIG-IP 10.1.0 and later, you may also run qkview by using tmsh.
[root@asm:Active:Standalone] config # tmsh run /util qkview
Gathering System Diagnostics: Please wait ...
Core files found are being included.
Diagnostic information has been saved in:
/var/tmp/asm.appdeliver.com.tgz
Please send this file to F5 support.
SOL13066: Information required when opening a support case for BIG-IP Analytics
La misma informacion general y de Producto Específico que en SOL135.
Severity Levels and Response Times listed in the WBT F5 Networks Technical Support Overview
F5’s technical support centers are strategically located in Seattle and Spokane, Washington; Lowell,
Massachussetts; London; Singapore; Tokyo and Beijing.
Page 46 of 91
Severity Definitions
When a case is opened, you, set the severity level for the issue.
Site Down (Sev 1) denotes that hardware or software conditions on your F5 device are preventing the
execution of critical business activities. The device will not power up or is not passing traffic.
Site at Risk (Sev 2) cases denote that software or hardware conditions on your F5 device are preventing or
significantly impairing high-level commerce or business activities. The device is in a degraded state that
places your network or commerce at risk.
A severity of performance degraded (Sev 3) denotes a degraded service or functionality for normal business
or commerce activities. Network traffic through the device is causing some applications to be unreachable, or
operate in a diminished capacity.
Finally, General Assistance (Sev 4) issues pertain to questions regarding configuration “how-to’s,”
troubleshooting non-critical issues, or a request for product functionality that is not part of the current product
feature set.
F5 Online Resources
 Ask F5
http://www.askf5.com Houses product manuals, release notes, how-to advice,
known-issue resolutions, general solutions, policy documents, hot fix info, security advisories,
firmware info, etc.
 F5 University
http://university.f5.com
 Dev CentralIs a global user community that helps you get the most from F5 technologies; in addition,
allows you to access blogs and forums on various F5 topics, receive TechTips and view podcasts.
 iHealth
https://ihealth.f5.com
5.2 Assessing issue severity
SUPPORT IT
Your experience with F5 is just beginning when you purchase a product. F5’s support, training, certification,
and consulting services are there to ensure you get the greatest value possible from your investment,
immediately and long-term.
Free self-service tools give you 24x7 access to a wealth of knowledge and technical support is on hand to
help you fix issues fast. Whether it’s providing quick answers to questions, training your staff, or handling
entire implementations from design to deployment, F5 services teams are ready to ensure you get the most
from your F5 technology
Guidelines and Policies
Scope of Support
Maintenance agreements: All F5 products come with a one-year manufacturer’s hardware warranty and a 90day software media warranty. Technical support is limited to F5 products with active support contracts.
Contract support levels: Annual support agreements are available for Standard hours, which includes 5 x 10
Page 47 of 91
support, or Premium hours, which includes 7 x 24 support. Expedited RMA Services and Maintenance AddOn Packages are also available.
iRules and iApps support: Standard and Premium support include iRules scripting language and F5 iApps
template assistance. Standard iRules and iApps support provides basic troubleshooting help for customers
with active Standard support maintenance contracts. In addition to Standard iRules and iApps support,
Premium support includes validation, troubleshooting, and functional analysis of scripted iRules and iApps
Templates.
Installation: For comprehensive installation assistance, you can purchase on-site installation services through
F5 Professional Services or your local authorized F5 reseller. F5 Technical Support does not provide remote
installation services.
Professional Services offerings: For assistance with planning, design, deployments, upgrades, migrations,
optimization, and application verification, contact F5 Professional Services. A consultant will provide a SOW
iRules OnDemand and Consulting OnDemand are available in North America only.
5.3 Assembling accurate problem description
SOL2633: Instructions for submitting a support case to F5 (tema ya revisado)
5.4 F5 escalation method
Working with F5 Support
F5 Technical Support
Remote technical support is available for all F5 customers with eligible support contracts. Annual support
services can be purchased from your F5 authorized reseller.
iRules Support
 iRules are officially supported by F5 through F5 Support Services only
 F5 will provide basic support for existing iRules
o Check iRule syntax
o Assist in troubleshooting iRules
o Validate iRule logic against functional requirements to F5’s reasonable effort
RAPID-RMA 4-Hour Onsite
F5 customers can upgrade the RMA service levels on their existing Standard, Premium, or Premium Plus
maintenance contract to 4-Hour onsite service for business-critical hardware. This option is only available to
customers whose F5 products are deployed within the 4-Hour RMA availability area (i.e., no more than 50
miles from an F5 authorized RMA Depot). Customers outside of the 4-Hour RMA availability area have
alternative options.
6.1 Network Map
WBT Course LTM Essentials Module 2. Processing Traffic
BIG-IP is a default deny device. Therefore, it is important to realize that without configuring a listener, such as
a Virtual Server, BIG-IP processes NO client traffic.
6.2 Dashboard (v10.1)
BIG-IP Dashboard: Cpu, Memory, Connections (Open, New, SSL, Combined View), Throughput
(Throughput, Compression, Combined View)
Monitoring the BIG-IP System
 Introducing the dashboard
The BIG-IP system provides a dashboard that you can use to monitor overall system performance
and performance of specific modules. The dashboard displays system statistics graphically, showing
gauges and graphs, and you can view the same statistics in a table view. Information is updated
every three seconds.

Viewing BIG-IP system information
Page 48 of 91
You can view CPU usage, memory usage, connection types, and throughput statistics for the BIG-IP
system on the dashboard.
(on V10.x) Overview -> Performance -> Dashboard
(on V11.x) Statistics -> Dashboard

Viewing statistics for other modules
If you have licensed and provisioned other modules on the BIG-IP system that support the
dashboard, you can view statistics specific to the module (for example, the WAN Optimization
Module).
6.3 Review log files
SOL13317: Configuring the level of information that syslog-ng sends to log files (11.x)
You should consider using this procedure to change the level of information that the syslog-ng utility delivers
to the BIG-IP log files.
Page 49 of 91
The BIG-IP system uses the standard UNIX logging utility, syslog-ng, to deliver system messages to log files.
You can configure the level of information that syslog-ng delivers to log files.
Note: Log messages for events related to Traffic Management Microkernel (TMM) are controlled by
the alertd process.
Syslog-ng uses facilities and levels to describe system messages. Facilities describe the specific element of
the system generating the message. Levels describe the severity of the message.
Facilities
The following facilities are available on the BIG-IP system. Each facility handles messages for specific
elements of the system, as described in the following table:
Facility
Description
Default log file
local0
BIG-IP specific messages
/var/log/ltm
local1
EM specific messages
APM specific messages
/var/log/em
/var/log/apm
local2
GTM and Link Controller specific messages
/var/log/gtm
local3
ASM specific messages
/var/log/asm
local4
ITCM portal and server (iControl) specific messages
/var/log/ltm
local5
Packet Filtering specific messages
/var/log/pktfilter
local6
HTTPD specific messages
/var/log/httpd/httpd_errors
local7
Linux specific boot messages
/var/log/boot.log
cron
Messages related to the cron daemon
/var/log/cron
daemon
Messages related to system daemons (including named and ntpd)
/var/log/daemon.log
kern
Kernel messages
/var/log/kern.log
mail
Mail system messages
/var/log/maillog
auth
User authentication messages that do not contain sensitive
information
/var/log/secure
authpriv
User authentication messages that contain sensitive information
/var/log/secure
ftp
Unused, messages for FTP are reported under daemon
N/A
lpr
Unused, printing support is not provided
N/A
mark
A facility that produces time-stamps at regular intervals
N/A
news
Unused, news server support is not provided
N/A
ntp
Unused, messages for ntpd are reported under daemon
N/A
user
Messages related to user processes
/var/log/user.log
uucp
Unused
None
Levels
The following levels are available for each facility, as described in the following table. The facilities are listed
in order of the severity of the messages they handle. Generally, higher levels contain all the messages for
lower levels. For example, the alert level will generally also report all messages from the emerg level; and the
debug level will generally also report all messages for all levels.
Level
Description
Verbosity
emerg
Emergency system panic messages
Minimum
alert
Serious errors that require administrator intervention
Low
crit
Critical errors, including hardware and filesystem failures
Low
err
Non-critical, but possibly very important, error messages
Low
warning
Warning messages that should at least be logged for review
Medium
notice
Messages that contain useful information, but may be ignored
Medium
info
Messages that contain useful information, but may be ignored
High
debug
Messages that are only necessary for troubleshooting
Maximum
Page 50 of 91
Displaying the level of information that syslog-ng sends to log files
[root@training:Active:Standalone] config # tmsh list /sys syslog all-properties
sys syslog {
auth-priv-from notice
auth-priv-to emerg
console-log enabled
cron-from warning
cron-to emerg
daemon-from notice
daemon-to emerg
description none
include none
iso-date disabled
kern-from notice
kern-to emerg
local6-from notice
local6-to emerg
mail-from notice
mail-to emerg
messages-from notice
messages-to warning
remote-servers none
user-log-from notice
user-log-to emerg
}
Configuring the level of information that syslog-ng sends to log file
[root@training:Active:Standalone] config # tmsh modify /sys syslog auth-priv-from warning
[root@training:Active:Standalone] config # tmsh save /sys config
/var/run/config/syslog-ng.conf
6.4 iApps Analytics
Setting Up Application Statistics Collection
What is Analytics?
Analytics (also called Application Visibility and Reporting) is a module on the BIG-IP system that lets you
analyze performance of web applications. It provides detailed metrics such as transactions per second,
server and client latency, request and response throughput, and sessions. You can view metrics for
applications, virtual servers, pool members, URLs, specific countries, and additional detailed statistics about
application traffic running through the BIG-IP system.
The Analytics module also provides remote logging capabilities so that your company can consolidate
statistics gathered from multiple BIG-IP appliances onto syslog servers or SIEM devices, such as Splunk.
About Analytics profiles
An Analytics profile is a set of definitions that determines the circumstances under which the system gathers,
logs, notifies, and graphically displays information regarding traffic to an application.
The BIG-IP system includes a default Analytics profile called analytics. It is a minimal profile that internally
logs application statistics for server latency, throughput, response codes, and methods. You can create
custom Analytics profiles for each application if you want to track different data for each one.
Overview: Setting up application statistics collection
You can collect application statistics for one or more virtual servers or for an iApps application service. If
virtual servers are already configured, you can specify them when setting up statistics collection. If you want
to collect statistics for an iApps application service, you should first set up statistics collection, creating an
Analytics profile, and then create the application service.
Page 51 of 91
The system can send alerts regarding the statistics when thresholds are exceeded, and when they cross
back into the normal range. You can customize the threshold values for transactions per second, latency,
page load time, and throughput.
Setting up local application statistics collection
You need to provision the Application Visibility and Reporting (AVR) module: System > Resource
Provisioning; before you can set up local application statistics collection. You must have Adobe Flash Player
installed on the computer where you plan to view Analytics statistics.
You can configure the BIG-IP system to collect specific application statistics locally.
1. On the Main tab, click Local Traffic > Profiles > Analytics.
The Analytics screen opens and lists all Analytics profiles that are on the system, including a default profile
called analytics.
2. Click Create.
For the Statistics Logging Type setting, verify that Internal is selected. Selecting Internal causes the system
to store statistics locally, and you can view the charts on the system by clicking Overview > Statistics >
Analytics.
3. Review the Transaction Sampling Ratio value and consider it if suits the networking environment, a higher
sampling rate (such as 1 of every 99) is less precise but requires fewer resources. If you need to change the
value, you can do it later by editing the default analytics profile.
4. In the Included Objects area, specify the virtual servers for which to capture performance statistics.
Note: You need to have previously configured the virtual servers (with an HTTP profile) for them to appear in
the list.
5. In the Statistics Gathering Configuration, for Collected Metrics, select the statistics you want the system to
collect: Server Latency, Page Load Time, Throughput, User Sessions.
6. For Collected Entities, select the entities for which you want the system to collect statistics: URLs,
Countries, Client IP Addresses, Response Codes, User Agents, Methods.
7. In the Capture Filter area, adjust the settings to specify criteria to determine what application traffic to
capture.
If you want to monitor statistics for an iApps application, create the iApps application service, enable Analytics
on the template, and specify the Analytics profile you just created. The BIG-IP system then collects statistics
for the application service, and the application name appears in the Analytics charts.
Setting up remote application statistics collection
You need to provision the Application Visibility and Reporting (AVR) module: System > Resource
Provisioning before you can set up remote application statistics collection. You also need the IP address and
port number for the remote logging server.
1. On the Main tab, click Local Traffic > Profiles > Analytics.
The Analytics screen opens and lists all Analytics profiles that are on the system, including a default profile
called analytics.
2. Click Create.
3. To the right of the General Configuration area, click the Custom check box. The settings in the area
become available for modification.
4. For the Statistics Logging Type setting, click External.
5. For the Remote Server IP Address field, type the IP address of the external logging server.
6. For the Remote Server Port field, type the port used for the external logging server.
7. From the Remote Server Facility list, select the facility category of the logged traffic. The possible values
are LOG_LOCAL0 through LOG_LOCAL7.
8. In the Included Objects area, specify the virtual servers for which to capture performance statistics.
9. In the Statistics Gathering Configuration, for Collected Metrics, select the statistics you want the system to
collect: Server Latency, Page Load Time, Throughput, User Sessions.
10. For Collected Entities, select the entities for which you want the system to collect statistics: URLs,
Countries, Client IP Addresses, Response Codes, User Agents, Methods.
11. In the Capture Filter area, adjust the settings to specify criteria to determine what application traffic to
capture.
Page 52 of 91
Page 53 of 91
Configuring application performance alerts
Before you can configure the system to send alerts concerning statistics, you need to have created an
Analytics profile to collect application statistics locally.
You can configure the BIG-IP system to send alerts concerning local application statistics based on threshold
values that you set. The system sends notifications when threshold values are breached, and when they
return to normal. Therefore, it is a good idea to get familiar with the typical statistics for the web application
before attempting to set up alerts and notifications. When you understand the typical values, you can
configure the system to alert you of limiting system situations, such as system overload.
1. On the Main tab, click Local Traffic > Profiles > Analytics.
2. Click the name of a previously created Analytics profile, or create a new one.
3. For the Statistics Logging Type, ensure that the Internal check box is selected.
4. For the Notification Type setting, select the appropriate check boxes to determine the type of notification
and where you want to receive it
To Send Alerts Like This
Local BIG-IP syslog (System >
file.
Logs > Local Traffic)
Remote syslog server
server on
SNMP traps sent to an external
after you
SNMP receiver
Do This
Select Syslog. The alerts are logged in the /var/log/ltm
Select Syslog. You must configure the remote syslog
the BIG-IP system.
Select SNMP. If you need to configure SNMP, wait until
finish creating alerts.
The system selects both Syslog and SNMP.
E-mail
Select E-mail.
The system selects Syslog, SNMP, and E-mail.
To send email alerts, you need to configure the BIG-IP
system to
communicate with a mail exchange server.
5. In the Alerts and Notifications Configuration area, for the Add New Rule setting, define the rules that
determine when the system sends alerts. Note that you cannot add overlapping rules, for example, two rules
that request an alert when average TPS is above 100 and 50 for 200 seconds.
a) For Alert when, select the condition under which you want to send an alert.
b) Select below or above, type an integer that represents the threshold value, and type the number of
seconds (an integer) that the rule has to apply.
c) Select the granularity level to which the threshold applies: traffic sent to an Application, a Virtual
Server, or a Pool Member.
d) Click Add.
The rule is added to the list of Active Rules.
Continue to add as many rules as you want to specify conditions under which you want to be alerted.
6. Click Update.
7. If SNMP is not configured on the BIG-IP system and you want to send SNMP traps or e-mail notifications,
configure it now:
a) In the General Configuration area, for the Notification Type setting, next to SNMP, click the link.
The SNMP Traps Destination screen opens.
b) Click Create.
c) Configure the version, community name, destination IP address, and port.
d) Click Finished.
Based on the rules you configured and the notification type, the system sends an alert when thresholds are
breached and when they cross back from the threshold.
Examining Application Statistics
Before you can look at the application statistics, you need to have created an Analytics profile so that the
system is capturing the application statistics internally on the BIG-IP system. You must associate the
Analytics profile with one or more virtual servers (in the Analytics profile or in the virtual server). If you
created an iApp application service, the template provided allows you to associate the virtual server. To view
Page 54 of 91
Analytics statistics properly, Adobe Flash Player must be installed on the computer where you plan to view
them.
The system recalculates the Analytics statistics and updates the data every five minutes.
Continue to review the collected metrics on the system viewing transactions, latency, throughput, and
sessions. As a result, you will get more familiar with the system, applications, resource utilization, and more,
and you can view the statistics in clear graphical charts, and troubleshoot the system as needed.
Investigating Server Latency Issues
Before you can investigate server latency, you need to have created an Analytics profile that is logging
statistics internally on the BIG-IP system. In the profile, the statistics gathering configuration must have
Server Latency selected as one of the collected metrics. The Analytics profile must be associated with one or
more virtual servers, or an iApps application service. To view Analytics statistics properly, Adobe Flash
Player must be installed on the computer where you plan to view them.
You can review statistics concerning server latency on the Analytics charts. Server latency is how long it
takes (in milliseconds ) from the time a request reaches the BIG-IP system, for it to proceed to the web
application server, and return a response to the BIG-IP system.
1. On the Main tab, click Statistics > Analytics.
The Analytics Overview screen opens and shows a summary of the most active application traffic, such as
the top URLs, top virtual servers, top pool members, top response codes, and top countries in recent times.
Settings in the associated Analytics profile govern what you see on this screen.
2. From the Latency menu, click Server Latency.
A chart shows the server latency for all applications and virtual servers associated with all Analytics profiles.
3. If further investigation is needed, in the View By setting, select other entities to view charts that show
latency for other collected entities included in the Analytics profile, for example, specific pool members,
URLs, countries, or client IP addresses.
Viewing Application Page Load Times
Note: The system can collect page load times only for clients using browsers that meet the following
requirements:
• Supports Navigation Timing by W3C
• Accepts cookies from visited application sites
• Enables JavaScript for the visited application sites
Before you can view application page load times, you need to have created an Analytics profile that is logging
statistics internally on the BIG-IP system. In the profile, the statistics-gathering configuration must have Page
Load Time selected as one of the collected metrics. The Analytics profile also needs to be associated with
one or more virtual servers, or an iApps application service.
You can view page load times on the Analytics charts. Page load time is how long (in milliseconds) it takes
from the time an end user makes a request, until the web page response from the application server finishes
loading on the end user's system.
1. On the Main tab, click Statistics > Analytics.
2. From the Latency menu, choose Page Load Time.
Charts show the average page load times in milliseconds for all applications and virtual servers associated
with all Analytics profiles.
3. To view page load time for a specific virtual server:
a) Click Expand Advanced Filters.
b) For Virtual Servers choose Custom.
c) Click Add and select the virtual server whose page load times you want to view.
The charts show page load times for the selected virtual server.
Troubleshooting Applications by Capturing Traffic
Capturing traffic for troubleshooting
You can configure the BIG-IP system to capture application traffic locally or remotely (on syslog servers or
SIEM devices, such as Splunk). To do this, you create an Analytics profile designed for capturing traffic. The
profile instructs the BIG-IP system to collect a portion of application traffic using the Application Visibility and
Reporting module.
Page 55 of 91
1. On the Main tab, click Local Traffic > Profiles > Analytics.
2. Click Create.
3. In the Capture Filter area, from the Capture Requests and Capture Responses lists, select the options that
indicate the part of the traffic to capture.
Option
Description
None
Specifies that the system does not capture request (or response) data.
Headers
Specifies that the system captures request (or response) header data only.
Body
Specifies that the system captures the body of requests (or responses) only.
All
Specifies that the system captures all request (or response) data.
4. Depending on the application, customize the remaining filter settings to capture the portion of traffic to use
for troubleshooting.
The BIG-IP system captures the application traffic described by the Analytics profile for 1000 transactions (or
until system limits are reached).
Note: System performance is affected when traffic is being captured.
Page 56 of 91
7.1 Create and restore a UCS archive under the appropriate circumstances
Manual Chapter: Creating and Managing Archives (10.x)
What is an archive?
Before you replace a version of the BIG-IP system with a newer version, you should always create
an archive, which is a backup copy of the configuration data. This archive is in the form of a user
configuration set, or UCS. Then, if you need to recover that data later, you can restore the data from the
archive that you created.
A UCS contains the following types of BIG-IP system configuration data:
 System-specific configuration files
 Product licenses
 User accounts and password information
 Domain Name Service (DNS) zone files
 Installed SSL keys and certificates
Important: To create, delete, upload, or download an archive, you must have either the Administrator or
Resource Administrator role assigned to your user account.
By default, the system stores all archives in the directory /var/local/ucs. You can specify a different location,
but in this case, the Configuration utility does not display the UCS files when you view the list of archives
Important: Any UCS file that you create includes the host name of the BIG-IP system as part of the data
stored in that file. When you later specify this UCS file during the process of restoring configuration data to a
BIG-IP system, the host name stored in this UCS file must match the host name of the system to which you
are restoring the configuration data. Otherwise, the system does not fully restore the data.
Important: If your configuration data includes SSL keys and certificates, be sure to store the archive file in a
secure environment.
Note, too, that when you synchronize configuration data for a redundant system, the BIG-IP system
automatically creates a backup archive, named cs_backup.ucs, immediately prior to performing the
synchronization. This ensures that you always have a copy of the most recent configuration data in the event
that a system event occurs during the synchronization process.
Managing archives
You can create, store, and access archives, on both the BIG-IP system and a remote system. You can also
view any existing archive files and their properties, as well as delete archives that you no longer need.
Specifically, you can use the Configuration utility to:
 View a list of existing archives
 Create a new archive and save it on the BIG-IP system
 View the properties of an existing archive
 Restore data from a BIG-IP system archive
 Download a copy of an archive to another system
 Upload a copy of an archive that you previously saved to another system
 Delete an existing archive from the BIG-IP system
Viewing archive properties
Using the Configuration utility, you can view the properties of an archive that you previously created. Note
that you cannot modify the properties of an archive. If you want to modify an archive, you must delete the
archive you want to change and then create a new one. The properties of an archive that you can view are:
The name of the archive, The version of the BIG-IP system on which the archive was created, The encryption
state of the archive, The date that the archive was created, The size of the archive, in kilobytes.
Restoring data from a BIG-IP system archive
In the unlikely event that the BIG-IP system configuration data becomes corrupted, you can restore the data
from the archive that is currently stored in the directory /var/local/ucs. If no archive exists in that directory,
then you cannot restore configuration data.
Page 57 of 91
Manual Chapter: Archives (11.2.x)
On any BIG-IP system, you have a set of data that you created when you initially configured the system,
using the Setup utility and the Configuration utility or tmsh. This data consists of traffic management elements
such as virtual servers, pools, and profiles. Configuration data also consists of system and network
definitions such as interface properties, self IP addresses, VLANs, and more.
Once you have created the configuration data for the BIG-IP system, you can replicate all of this set of data
in a separate file. You can then use this replicated data later, for these reasons:
As an archive for disaster recovery
Using the Archives feature, you can back up the current configuration data, and if necessary, restore
the data at a later time. We highly recommend that you use this feature to mitigate the potential loss of
BIG-IP system configuration data. To create an archive, you can use the Configuration utility, which
stores the configuration data in a special file known as a user configuration set, or UCS file. You can
then use the UCS file to recover from any loss of data, in the unlikely event that you need to do so. For
more information about creating and managing archives, see the remainder of this chapter.
As a way to propagate data to other systems
Using the single configuration file feature, you can easily and quickly propagate the exact
configuration of the BIG-IP system to other BIG-IP systems. To create a single configuration file, you
export the configuration data to a special file known as an .scf file. You can then use the .scf file to
configure another system in one simple operation.
To configure and manage archives, log in to the BIG-IP Configuration utility, and on the Main tab,
expand System, and click Archives.
SOL4423: Overview of UCS archives
Exceptions to UCS archive file on VIPRION systems
The BIG-IP VIPRION system is unique among BIG-IP hardware because it allows you to combine all blades
within the chassis to increase processing ability. This functionality, referred to as clustering, is unique and is
written to a special file in the /shared/db directory called cluster.conf. Additionally, the system saves a copy
as cluster.conf.<chassis SN>, where <chassis SN> is the unique serial number of the chassis. The blade
maintains the *.<chassis SN> files and copies them to cluster.conf when the blade starts in a chassis that it
has encountered before. The cluster.conf file consists of each blade's copy of the cluster configuration. The
file contains the management addresses for the cluster and for each blade within the cluster, as well as other
cluster-specific information. Since this information is specific and unique to the chassis, the information is not
included within a UCS archive.
If you load a UCS archive, the archive does not overwrite the current cluster.conf file and does not restore a
previous cluster configuration.
If you reconfigure the cluster, you must manually rebuild the cluster.conf file in the following circumstances:
 A blade starts as the primary blade in the chassis, and the cluster.conf file does not contain the serial
number of the chassis.
 You have replaced the chassis. (The chassis serial number must match the chassis serial number in
the cluster.conf file.)
Viewing the list of files saved within a UCS archive
To view the files that have been saved in a UCS archive, use the following command syntax:
# tar -ztf backup_file_bigip1.ucs
Viewing the contents of a file saved within a UCS archive
To view a single file from a UCS archive on a terminal screen (standard output)
# tar –zxOf myconfig.ucs config/bigip.conf
Extracting files from the UCS archive
# tar -zxf myconfig.ucs config/bigip.conf
This command extracts the files and puts them in the current directory. It creates a subdirectory to match the
directory in which the configuration file is normally stored. For example, if you extract config/bigip.conf, a
config directory is created.
# tar -zxf myconfig.ucs
Page 58 of 91
This command extracts the files and puts them in the current directory. It creates subdirectories to match the
directories in which the configuration files are normally stored. For example, a config directory is created and
contains all the files that are normally contained in the /config directory.
SOL13132: Backing up and restoring BIG-IP configuration files (11.x)
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 BIGIP 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 asneeded 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.
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.
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.
vCMP considerations
For a Virtual Clustered Multiprocessing (vCMP) host, the UCS configuration archive contains only the
necessary files that are required to restore the vCMP host configuration, but does not include the vCMP
guest virtual disk.
For a vCMP guest, the UCS configuration archive contains all of the files that are specific to the vCMP guest,
including the configuration files, local user accounts, and SSL certificate and key pairs.
Backing up your BIG-IP system configuration
(XUI)
Optional: If you want to encrypt the UCS archive file, from the Encryption menu, select Enabled and enter a
passphrase. You must supply the passphrase to restore the encrypted UCS archive file.
Optional: If you want to exclude SSL private keys from the UCS archive, from the Private Keys menu, select
Exclude.
(CLI)
[root@training:Active] config # tmsh save /sys ucs /var/tmp/MiRespaldo.ucs
Saving active configuration...
/var/tmp/MiRespaldo.ucs is saved.
[root@training:Active] config # tmsh save /sys ucs /var/tmp/MiRespaldoSeguro.ucs
passphrase 123456
Saving active configuration...
/var/tmp/MiRespaldoSeguro.ucs is saved.
[root@training:Active] config # tmsh save /sys ucs /var/tmp/MiRespaldoSinSSLkeys.ucs noprivate-key
Saving active configuration...
/var/tmp/MiRespaldoSinSSLkeys.ucs is saved.
Please note that UCS files saved with the no-private-key option may load with validation
errors.
[root@training:Active] config # ls -l /var/tmp/MiR*
-rw-r--r-- 1 root root 4187980 Sep 9 11:46 /var/tmp/MiRespaldoSeguro.ucs
Page 59 of 91
-rw-r--r-- 1 root root 3089464 Sep
-rw-r--r-- 1 root root 3092349 Sep
9 11:47 /var/tmp/MiRespaldoSinSSLkeys.ucs
9 11:45 /var/tmp/MiRespaldo.ucs
Restoring your BIG-IP system configuration
(XUI)
Click System. -> Archives. Click the name of the UCS archive you want to restore.
If the UCS archive is encrypted, type the passphrase for the encrypted UCS archive file in the Restore
Passphrase field. If the UCS archive is not encrypted, you can skip this step.
To initiate the UCS archive restore process, click Restore.
After relicensing the system, restart the system to ensure that the configuration is fully loaded. To restart the
system, navigate to System > Configuration, and then click Reboot.
(CLI)
[root@training:Active] config # tmsh load /sys ucs /var/tmp/MiRespaldoSeguro.ucs
Saving active configuration...
Current configuration backed up to /var/local/ucs/cs_backup.ucs.
Product : BIG-IP
Platform: Mercury
Version : 11.2.0
Hostname: training.appdelivery.com
Installing --full-- configuration on host training.appdelivery.com
Installing configuration...
Installing the license file...
Post-processing...
Reloading License and configuration - this may take a few minutes...
Full configuration has been loaded successfully.
/var/tmp/MiRespaldoSeguro.ucs is loaded.
If you are running BIG-IP on a 6400, 6800, 8400, or 8800 hardware platform, type the following command to
switch to the bash shell:
(tmsh) # run /util bash
Type the following command to verify that the new or replaced secure shell (SSH) keys from the UCS file are
synchronized between the BIG-IP system and the Switch Card Control Processor (SCCP):
(tmsh) # keyswap.sh sccp
Type the following command to switch back to tmsh:
(tmsh) # exit
[root@training:Active:Standalone] config # reboot
Restoring configuration data on a replacement RMA unit
F5 recommends that you use the following procedure when you restore the archive on a different device than
the system on which the backup was created, such as an RMA system. If you do not use this procedure
when restoring the archive on a different device, the configuration load may fail and the mcpd process
generates an error message that appears similar to the following example to both stdout and
the /var/log/ltm file:
mcpd[2395]: 01070608:0: License is not operational(expired or digital signature does not match contents)
[root@training:Active]
license
config
#
tmsh
load
/sys
ucs
/var/tmp/MiRespaldoSeguro.ucs
no-
Restoring UCS archives on BIG-IP systems running later software versions
F5 recommends that the BIG-IP system run the same version of the BIG-IP software from which it was
backed up. However, in some cases, it is possible to restore a UCS archive that was obtained from an earlier
software version on a target BIG-IP system running a later software version. For example, if you saved a
UCS archive on a system running BIG-IP 10.2.3, it is possible to restore the version BIG-IP 10.2.3 archive file
on a BIG-IP system running 11.x. To restore a UCS archive on a BIG-IP system running a later software
version, perform the following procedure:
1. Verify that a supported upgrade path exists between the software version from which the UCS
archive was obtained and the software version running on the target system.
For example, there is a supported upgrade path between BIG-IP 10.x and BIG-IP 11.x. As a result,
you can successfully restore a BIG-IP 10.x UCS archive file on a BIG-IP system running 11.x.
Page 60 of 91
However, there is no supported upgrade path between BIG-IP 9.x and BIG-IP 11.x. As a result, you
cannot restore a BIG-IP 9.x UCS archive file on a BIG-IP system running 11.x.
2. Manually copy the UCS archive file to the /var/local/ucs/ directory on the target system.
3. Restore the UCS archive on the BIG-IP system:
o If you are restoring the archive on a different device than the system on which the backup
was created, follow the Restoring configuration data on a replacement RMA unit procedure.
o If you are restoring the archive on a different device than the system on which the backup
was created, follow the Restoring configuration data from the command line by using the
tmsh utility procedure.
SOL11318: Backing up and restoring BIG-IP configuration files (10.x)
Backing up configuration data from the command line using the bigpipe utility
# bigpipe config save respaldo1.ucs [passphrase 123456]
Important: If a file by the same name already exists, the system overwrites the existing file without warning.
Note: F5 recommends that you include the BIG-IP hostname and current timestamp as part of the filename
for ease of identification.
Restoring configuration data from the command line using the bigpipe utility
#
#
#
#
cp /config/bigip.license /var/tmp
bigpipe config install respaldo1.ucs
keyswap.sh sccp {If you are running BIG-IP on a 1500, 3400, 4100, 6400, 6800, or 8400 hardware Platform}
reboot
Important: If you are restoring the backup on a different device from the system where the backup was
created, such as an RMA system, the configuration load may fail with a license error. As a result,
a BigDB.dat load error message that appears similar to the following example displays:
mcpd[2395]: 01070608:0: License is not operational(expired or digital
signature does not match contents). Loading the new /config/BigDB.dat failed.
01080023:3: Error return while getting reply from mcpd: 0x1070370,
01070370:3: Failover (redundant mode) is not licensed. After updating your
local /config/BigDB.dat.cs
license, run loaddb -
The previous error message is expected, and is corrected by re-licensing the system later in the procedure.
Restoring configuration data on a replacement RMA unit (BIG-IP 10.1.0 or later)
# tmsh
(TMSH) # load /sys ucs /var/tmp/MiRespaldo.ucs rma
(TMSH) # run /util bash
{If you are running BIG-IP on a 6400, 6800, 8400, or 8800 hardware platform}
# keyswap.sh sccp
# exit
# reboot
Restoring UCS archives obtained from an earlier software version onto BIG-IP systems running later
software versions
F5 recommends that the BIG-IP system runs the same version of the BIG-IP software from which it was
backed up. However, in some cases it is possible to restore a UCS archive that was obtained from an earlier
software version on a target BIG-IP system that is running a later software version. For example, if you saved
a UCS archive on a system running BIG-IP 9.4.8, it is possible to restore the archive file on a BIG-IP system
running version 10.x. To restore a UCS archive on a BIG-IP system running a later software version, perform
the following procedure:
1. Verify that a supported upgrade path exists between the software version from which the UCS
archive was obtained and the software version running on the target system.
For example, there is a supported upgrade path between BIG-IP 9.4.x and 10.x. As a result, you can
successfully restore a BIG-IP 9.4.x UCS archive file on a BIG-IP system running version 10.x.
However, there is no supported upgrade path between BIG-IP 9.2.x and 10.x. As a result, you cannot
restore a BIG-IP 9.2.x UCS archive file on a BIG-IP system running version 10.x.
2. Manually copy the UCS archive file to the /var/local/ucs/ directory on the target system.
3. Restore the UCS archive file using the bigpipe utility, by typing the following command,
replacing <filename> with the name of your UCS archive file:
# bigpipe config install all <filename>
Page 61 of 91
4. Reboot the system.
SOL3499: Backing up and restoring BIG-IP 9.x configuration files
Backing up configuration data from the command line
# bigpipe config save <filename>
# bigpipe config save <filename> passphrase <passphrase>
Restoring the configuration data for a system that is currently running system software
a. # cp /config/bigip.license /var/tmp
b. Copy the UCS archive file you want to restore to the BIG-IP filesystem.
c. Set the host name of the system to match the host name of the system where the UCS
archive was created, by typing one of the following commands:
 BIG-IP system 9.4.2 and later:
bigpipe system hostname <hostname>
 BIG-IP system 9.4.1 and earlier:
hostname <hostname>
d. Restore the configuration from the UCS archive by typing the following command
# bigpipe config install <filename>
e. If you are running BIG-IP 9.x software on a 1500, 3400, 4100, 6400, 6800, or 8400 hardware
platform # keyswap.sh sccp
f. # reboot
g. Relicense the system.
h. Finish loading the BigDB.dat information
# loaddb -local /config/BigDB.dat.cs
i. Synchronize the BIG-IP system clock with the restored time zone configuration
# tw_activate_keys ntp.timezone
SOL13136: The UCS configuration archive cannot be restored on a platform other than the one on which the
archive was created (v11.0)
You cannot restore the UCS configuration archive on a platform other than the one on which you created the
archive. This issue occurs when the following condition is met:
You attempt to restore a UCS configuration archive on a different BIG-IP platform than the one on which
the archive was created. For example, you attempt to restore a UCS archive on a BIG-IP 8900 platform
that was created on a BIG-IP 1600 platform.
The BIG-IP system reports a message in the status page when you attempt to perform the restoration from the
Configuration utility or from the tmsh shell. The message appears similar to the following example:
ERROR: The platform on the system is different from the platform in the UCS. Can't install the UCS.
Workaround
Impact of workaround: None
To work around this issue, you can disable the platform check by modifying the UCS installation Perl script. To
do so, perform the following procedure:
1.
2.
3.
4.
5.
Log in to the command line.
Back up a copy of the UCS installation /usr/local/bin/install_ucs.pm Perl script by typing the following command:
# cp -p /usr/local/bin/install_ucs.pm /var/tmp/install_ucs.pm.sol13136
Remount the /usr filesystem in read-write mode by typing the following command:
# mount -o remount,rw /usr
Edit the /usr/local/bin/install_ucs.pm file using a text editor of your choice.
Locate the following line:
&Exit(1, "ERROR: The platform on the system is different from the platform in the UCS. Can't install the UCS.\n");
6.
Comment out the line by inserting a # in front of the line, as shown in the following example:
#&Exit(1, "ERROR: The platform on the system is different from the platform in the UCS. Can't install the UCS.\n");
7.
8.
Save the modifications and exit the text editor.
Remount the /usr filesystem in read-only mode by typing the following command:
# mount -o remount,ro /usr
SOL9420: Installing a UCS file containing an encrypted passphrase
Page 62 of 91
Beginning in BIG-IP LTM 9.4.5, passphrases for SSL private keys are stored in the configuration file in encrypted
form. The BIG-IP system uses a hardware-key encrypted master SSL key to encrypt and decrypt SSL key
passphrases in the configuration file.
When attempting to install a UCS file containing encrypted SSL passphrases on a system with a different master
key, such as restoring the configuration after reinstalling the operating system, replacing a failed system with a
new system, or otherwise moving an existing configuration to a new system, the passphrases cannot be
decrypted with the new key, and the system generates a message that appears similar to one of the following
examples:
0107102b:3: Master Key decrypt failure - decrypt failure - final
BIGpipe client SSL profile creation error: 01070937:3: Master Key decrypt failure - decrypt failure
Since the original master key used to encrypt the passphrase does not exist on the system, the encrypted
passphrase cannot be decrypted. This is an intentional design decision that follows security best practices
regarding SSL private key management.
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. Since the master key is shared between units of a redundant pair, the configuration synchronization
process will synchronize 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 the unencrypted versions, and save the resulting
configuration.
Note: Saving the configuration automatically re-encrypts any configured passphrases prior to saving them in the
configuration file.
Recovering a restored UCS archive that contained SSL private key passphrases (If you know the passphrases
for your SSL private keys)
If you know the passphrases for your SSL private keys, you can recover a restored UCS archive that contained
SSL key passphrases. To do so, perform one of the following two procedures:
BIG-IP 11.x {10.x}
1. After restoring the UCS file, open the /config/bigip.conf file with a text editor.
2. Edit each SSL profile containing an SSL private key passphrase, replacing each encrypted passphrase
with the unencrypted version.
3. To load the new configuration into memory, type the following command:
tmsh load /sys config {bigpipe load}
4. To save the running configuration with the encrypted passphrases in the bigip.conf file, type the
following command:
tmsh save /sys config {bigpipe save}
Recovering a restored UCS archive that contained SSL private key passphrases (If you do not know the
passphrases for your SSL private keys)
BIG-IP 11.x
If you do not know the original unencrypted passphrases for your SSL private keys, you can manually copy the
master key from the peer system, and then install the UCS file to restore the configuration. To do so, refer to the
following procedure:
1. Log in to the peer BIG-IP system command line.
2. From the active peer BIG-IP system, obtain the master key by entering the following command:
# f5mku -K
The command output appears similar to the following example:
oruIVCHfmVBnwGaSR/+MAA==
3. Copy the output.
Note: The output is the master key that you will install on the RMA BIG-IP system.
4. Log in to the RMA BIG-IP system command line.
5. Install the master key that you copied in Step 3 to the RMA BIG-IP system by entering the following
command:
Page 63 of 91
6.
7.
8.
9.
# f5mku -r <key_value>
For example:
# f5mku -r oruIVCHfmVBnwGaSR/+MAA==
Restore the UCS file to the RMA BIG-IP system by entering the following command:
# tmsh load sys ucs <filename>.ucs
Verify that the master key is the same on the active peer BIG-IP system and the RMA BIG-IP system by
entering the following command from the command lines of both systems:
# f5mku -K
To save and load the configuration, and to ensure no errors, enter the following commands from the
RMA BIG-IP system command line:
tmsh save /sys config
tmsh load /sys config
Set the active peer BIG-IP system as the sync leader by entering the following command:
tmsh modify cm device-group <device_group> devices modify { <Active peer BIG-IP> { set-sync-leader }
}
In this command, note the following:
o <device_group> is the name of the device group for the active peer system and the RMA BIG-IP
system
o <Active peer BIG-IP> is the hostname of the active peer BIG-IP system
10. To sync the configuration to the RMA BIG-IP system, enter the following command from the active peer
BIG-IP system command line:
# tmsh run cm config-sync to-group <device_group>
Note: This command can take up to a full minute to initialize the new configuration on the RMA device.
11. Verify the sync status by entering the following command:
# tmsh show cm sync-status
Manual Chapter: Preparing the System for Installation (10.x)
Summarizing 10.x installation and upgrade
All BIG-IP systems include the local traffic management components. You can also obtain the following optional
modules: Global Traffic Manager, Link Controller, Application Security Manager, Protocol Security Module,
WebAccelerator system, and WAN Optimization Module. The license you have determines which modules you
can use.
Warning: If the system you plan to upgrade has WAN Optimization Module, WebAccelerator, or Application
Security Manager already provisioned or if you have a number of volumes with software installed, you might
experience an upgrade failure due to insufficient space. Before you proceed, set the module provisioning to
Minimal, or remove unneeded volumes and reboot the system. After installation is complete, you can set the
provisioning back to its original setting.
If the alternate network is present on the LAN, 192.168.245.0/24, or if the node address 192.168.1.245 is in use,
then the BIG-IP software assigns the alternate IP address 192.168.245.245 to the management interface instead.
Activating the software license
To install new versions of BIG-IP system software, you must have an active and updated license. An active and
updated license contains a valid service check date for the system software release you plan to install and run.
During installation and initialization, the system verifies the software release check date in the software against
the service check date in the license file on your system.
To activate the license for the system, you must have a base registration key. The base registration key is a 27character string that lets the license server know which F5 products you are entitled to license. The base
registration key is preinstalled on your system.
Performing optional tasks
If you have a BIG-IP system that is already configured with elements such as profiles and monitors, self IP
addresses, VLANs, and so on, you can preserve that configuration when you install or upgrade. This is
called rolling forward a configuration. When you install, the system uses the previously archived user
configuration set (UCS) file in the /var/local/ucs directory on the source installation location to update the
configuration on the installation destination.
Page 64 of 91
Understanding configuration file differences
BIG-IP system software has a feature called the single configuration file (SCF). A single configuration file (SCF)
is a flat, text file that contains a series of bigpipe commands, and the attributes and values of those commands,
that reflect the entire configuration of one BIG-IP system. Specifically, the SCF contains the local traffic
management and operating system configuration of the BIG-IP system.
An SCF is useful when you want to transfer a configuration from one BIG-IP system to another. Typically, this
involves using the bigpipe export command to create an SCF of one systems configuration, and then using
the bigpipe import command to install the configuration on another system. In this way, you can propagate the
exact configuration of one BIG-IP system to other BIG-IP systems.
The SCF file is not the same as the user configuration set (UCS) archive. A UCS archive is a compressed file
that contains all the configuration files (*.conf) that make up a single systems configuration. You use the SCF
strictly to manually transfer configuration information to new or different BIG-IP hardware. You create a UCS for
archival purposes, and to preserve a configuration for software upgrade.
Copying the configuration
You can use the cpcfg utility to copy the running configuration from one installation location to another. This is a
quick way to update an offline location to the latest configuration, and is useful when applying hotfixes, where the
configuration and license are not applied to the target.
The operation replaces the configuration on the target. The destination for the copy operation must represent an
installation location that is not currently active, and that contains a configuration older than the source.
To copy the running configuration
1.On the source, log on to the command line using an account with administrative permissions.
2.Type the following command: # cpcfg source=<source> <destination>
If you do not specify a source, the operation uses the configuration from the active installation location. For
example, to copy the active configuration from HD1.3 to HD1.1, if you are logged on to HD1.3, you run the
following command: # cpcfg HD1.1
SOL13294: Installing a UCS configuration archive now restores the full configuration (v11.x)
Old Behavior
Prior to BIG-IP 11.0.0, the BIG-IP system restored the configuration either in full or only partially, depending on
the host name of the unit on which you installed the UCS configuration archive.
If the host name of the unit matches the host name stored in the UCS archive, the BIG-IP system restores the full
configuration, including self IP addresses and VLANs. If the host name of the unit does not match the host name
stored in the UCS archive, the BIG-IP system restores only the shared configuration, such as virtual servers,
pools, and profiles.
New Behavior
Beginning in BIG-IP 11.0.0, when installing a UCS configuration archive, the BIG-IP system restores the full
configuration.
Due to an architectural change in BIG-IP 11.0.0, the UCS configuration archive is intended for complete
configuration backup and restore usage only.
Page 65 of 91
7.2 Identify the components and methods associated with automating and scheduling tasks with the
Enterprise Manager
Enterprise Manager Getting Started Guide Version 2.3
Enterprise Manager is an appliance that helps you streamline the administrative tasks associated with managing
multiple network devices. These administrative tasks include: performance monitoring, software installation and
upgrades, configuration archival and restoration, certificate monitoring, security policy management, software
image storage, and user account management.
You can use Enterprise Manager to manage networks with devices running the following software.
• BIG-IP system version 9.3 and later
• BIG-IP Local Traffic Manager Virtual Edition (VE) version 10.2 and later
• BIG-IP Secure Access Manager version 8.0 and later
• WANJet version 5.0 and later
• Enterprise Manager version 1.0 and later
Understanding how to incorporate Enterprise Manager into your network
Tiered network, BIG-IP Local Traffic Manager performs address translation
Tiered network, a SNAT performs network translation
About interfaces used for communication
Management (MGMT) interface
F5 devices use the management (MGMT) interface port exclusively for
administrative traffic and for the Always-On Management (AOM) subsystem and do not forward user application
traffic.
TMM interfaces
For each of the following processes, you must dedicate a TMM interface to
perform: Application traffic and load balancing, Communication between Enterprise Manager and managed
devices, Communication between systems in a high availability configuration (for both static and floating self IP
address support).
Ports required for two-way communication
443
4353
3306
Communication between managed devices and the EM system
Communication between EM and a managed device's big3d agent
Communication between EM and a remote statistics database
Device management
Collecting statistics
Storing and reporting statistics on a remote db
About device management through the management (MGMT) interface
When you use the management (MGMT) interface for enterprise management communication, you do not have
to dedicate a TMM switch interface for device management, and less configuration is required when you add new
devices on the same subnet. Using the management interface on Enterprise Manager and managed devices for
communication is preferable.
Attention: The only exception is for high availability configurations. Peer devices in a high availability
configuration must use a floating self IP address to communicate with the active device. If you have a high
availability configuration, use the TMM switch port on each device because it can support floating self IP
addresses.
Overview of initial setup tasks
Activating the Enterprise Manager license
Specifying initial configuration settings
Configuring a basic network
Activate, The End User License Agreement (EULA) displays, Accept
The purpose of Enterprise Manager's high availability feature is to provide access to a current backup of the
active Enterprise Manager system's configuration.
Device Discovery and Importation
Before you can use Enterprise Manager™ to manage devices in your network, you must add the devices. For
BIG-IP devices in your network, you can use the discovery method to search specific IP addresses or IP subnets
in your network, and add those devices to Enterprise Manager.
Page 66 of 91
1. On the Main tab, click Enterprise Management > Devices.
The Device List screen opens.
2. Click the Discover button located on the upper right-side of the screen.
The Discover Device(s) screen opens.
3. For the Scan Type setting, select one of the following options:
• Address List
• Subnet
The screen refreshes to display settings specific to the selected option.
4. If you selected the Address List option, perform the following steps:
a) In the User Name and Password fields, type a user name and password to use to log on to the
discovered device.
b) Click Add.
5. If you selected the Subnet, option perform the following steps:
a) In the IP Address field, type the device IP address.
b) In the Network Mask field, type the netmask that you want Enterprise Manager to use when
searching the network.
You can search by class B or C network.
c) In the User Name and Password fields, type a user name and password to use to log on to
each device discovered in the subnet.
6. Click the Discover button.
Importing non-BIG-IP devices (v2.3)
For non-BIG-IP devices, such as WANJet systems, you must create a comma-separated value (CSV) file on your
local system and import the file into the device list.
1. Create a .csv file on your local system that contains each non-BIG-IP device's IP address, user name,
and password on a separate line in the following format: <device IP address>, <username>, <password>
For example:
10.10.10.1,admin,pass001
10.10.10.2,admin,pass002
10.10.10.3,admin,pass003
2. On the Main tab, click Enterprise Management > Devices.
The Device List screen opens.
3. Click the Discover button located on the upper right-side of the screen.
The Discover Device(s) screen opens.
4. Click the Import From File button.
The Import Address List screen opens.
5. Click Import.
The screen refreshes to display the import status. When the importation finishes, the Device Discover
screen opens and a list of imported IP addresses and user names appears in the Address List field.
6. Click Start Task to add the devices in the Address List field to the device list.
Custom Lists (v3.0)
A custom list is a collection of selected network objects that can span multiple devices in your network. Creating
custom lists allows you to monitor a group of objects from one screen, without restricting the view to an
associated device. There are two types of custom network object lists that you can create: static lists and
dynamic lists. A static list is a fixed selection of network objects. A dynamic list is a selection of network objects,
which match characteristics that you define in the list's rules.
Optional Configuration
About UCS archive storage. A benefit of using Enterprise Manager is the ability to store, or archive, the user
configuration set (UCS) for each managed device in your network.
Creating a rotating UCS archive schedule
About the health and performance monitoring database
When statistics data collection is enabled, Enterprise Manager stores the following information in its statistics
database for each managed device on which the Data Collection Agent is installed:
• Specifics about the managed devices, such as host name, IP address, and software version
Page 67 of 91
• Details, such as object type and name, about any enabled network objects associated with a managed device
• Performance and health data for managed devices and associated network objects.
You can use the collected statistics to display standardized reports about the health and performance of
managed devices in your network. This helps you identify any systems that are not performing at full capacity and
assists you in determining when you should add new devices.
Important: Enterprise Manager collects statistics only from devices that have BIG-IP Local Traffic Manager
licensed and provisioned. Starting with Enterprise Manager version 2.3, Enterprise Manager can also collect
statistics from devices licensed and provisioned for BIG-IP Global Traffic Manager.
Installing the Data Collection Agent
When data collection is enabled, Enterprise Manager collects health and performance monitoring statistics data
for each managed device in your network on which the most current version of the Data Collection Agent is
installed.
About alert management
You can configure Enterprise Manager to manage alerts in these ways:
• Send SNMP traps to a remote SNMP server
• Send email alerts to a specific recipient
Understanding user roles
Enterprise Manager classifies the permissions for the user roles as either non-restricted or restricted. These user
roles are defined as:
Administrator This role (non-restricted) can perform all management functions available to Enterprise Manager,
including managing other user accounts and roles.
Operator and Application Editor
By default, these roles (restricted) perform fewer management tasks than
the Administrator. You can customize each role by specifying the tasks that the role is allowed to perform.
Manual: Enterprise Manager Administrator Guide
1. Performing basic tasks on managed devices
Once you add devices to the Device List screen, you can remotely perform basic management tasks, such as:
• Verifying and testing device communication
• Rebooting devices (Boot Location)
• Specifying device refresh interval (By default, EM collects information once every 60 minutes)
• Deleting devices
Enterprise Manager provides the following basic management for high availability redundant systems.
• Manage a high availability device’s failover state
• Synchronize peer configurations
Other Tasks:
 Collecting information for F5 support (and sent it)
 Maintaining and replacing devices
Enabling or disabling maintenance mode for a device. Maintenance mode does not disable
communications on the managed device itself. Maintenance mode only disables communication between
EM and a managed device.
 Using the device replacement checklist
2. User Roles and Authentication
Adding new users
Modifying user authentication source
By default, Enterprise Manager uses a local database to authenticate users. Enterprise Manager maintains a
local authentication list of users, but you can choose to use a remote LDAP, Active Directory, RADIUS, or
TACACS+ authentication source.
3. Managing UCS Archives
Enterprise Manager can create and store UCS archives for managed devices on demand, or at regularly
scheduled intervals using rotating archives. Rotating archives are UCS archives created at a regular interval
according to a schedule that you set in Enterprise Manager.
Page 68 of 91
By default, Enterprise Manager stores up to 10 rotating device archives and 10 saved, or pinned, archives per
device in its database.
Enterprise Manager deletes the oldest archive in the rotating archive list. Conversely, you must manually delete
pinned archives.
Comparing multiple versions of archives
When you manage multiple versions of UCS archives, you may encounter situations where you need to compare
the differences between device configuration archives. When you compare archives, Enterprise Manager
highlights the differences between two archives so that you can easily identify configuration changes. Examining
these changes can help you troubleshoot issues related to restoring archives or upgrading software.
Creating configuration archives
You have two main options for creating a UCS archive.
 Basic
A basic UCS archive contains configuration data specific to a device. To create a basic UCS archive, you add an
Enterprise Manager device to a rotating archive schedule (in the same way that you do for any managed device)
and store basic UCS archives on an Enterprise Manager system.
 Advanced
An advanced UCS archive includes the device configuration information as well as all imported data, including
UCS information, and managed device UCS archives.
To create an advanced UCS Enterprise Manager archive
a) At the command line, log in as root.
b) At the command prompt, type the following command: # em-backup <archive_name>.ucs
The em-backup script begins archiving all configuration and imported data stored on the Enterprise Manager
system.
c) To restore: # em-restore <archive_name>.ucs
The em-restore script begins the process of restoring all configuration and imported data stored on the Enterprise
Manager system.
4. Using Templates and Changesets to Manage Device Configurations
Enterprise Manager offers two versatile options that you can use to simultaneously manage multiple device
configurations: templates and changesets.
A template is a tool that you use to create and deploy new configurations based on an existing device
configuration.
A changeset is a collection of user-defined configuration data that you create and save for any managed device
in your network and distribute to other managed devices.
Publishing templates
When you create a custom template, it is available only for you to deploy and use. To make the template
available for others, you must publish it.
Importing and exporting templates
Templates are a flexible method for changing device configurations. You can share templates among Enterprise
Manager devices in your network, or with other users through the F5 developer community DevCentral by
importing and exporting them.
Page 69 of 91
5. Managing Software Images
• Downloading and managing software images
To add an image to the software repository
On the Main tab, expand Enterprise Management, click Repository, and select one of the following:
ASM Attack Signature List, Hotfix Image List, Software Image List. Click on Import.
• Copying and installing software to managed devices
Software Image Copy and Installation wizard (10.x and EM 2.x)
Legacy Software Image Installation wizard (9.x and EM 1.x)
• Viewing installation task progress
6. Managing User Account Data
• Managing user accounts
• Copying user access configuration information
• Changing user account passwords
7. Monitoring Object and Device Performance
• Collecting performance data and health statistics
The Enterprise Manager system uses its Data Collection Agent, big3d, to gather this information. The statistics
collection feature is disabled by default.
When you enable statistics collection, Enterprise Manager checks each managed device to verify that it has a
compatible version of the Data Collection Agent. If a device requires a more recent version, Enterprise Manager
marks that device as Impaired on the Device List screen, and displays a message indicating that an upgrade is
required.
• Using custom statistic profiles
Choosing a statistics profile
o Standard statistics profiles: The default data collected is: Device Global, Device Chassis, Device CPU,
Device Disk Space, Device UDP, Device TCP, Device HTTP, Device Client SSL, LTM Virtual Server,
LTM Pool, LTM Pool Member, and LTM Node.
o Custom statistics profiles These are profiles that you create and for which you define metrics and
optional threshold values.
• Viewing device statistics
• Managing storage for statistics
Enterprise Manager stores statistical data until the system reaches the storage capacity that you define. When
that capacity is met, the oldest data in the system is replaced with new data, up to the storage limit you set. The
Enterprise Manager system’s default value of 1 GB for statistics data storage is intentionally low, allowing you to
establish a reasonable value based on your environment.
Enterprise Manager provides information about the amount of space available for the storage of statistics, the
amount of space currently in use for statistics data, and the estimated number of days of storage with the current
data allocation.
To determine the allocation of resources on the drive, as well as estimate the storage capacity, you can
recalculate the estimated days of storage without committing the change. When you have determined that you
are satisfied with the storage space value, you can opt to save the changes.
• Backing up and restoring the statistics database
The Enterprise Manager system offers the following options to back up the statistic database.
• Backing up and restoring the statistics database from the command line
# em-backup-extern <user@host.com>:/<full_file_path_for_backup_file>
The default file name is f5em_extern-<date stamp>
# em-restore-extern <user@host.com>:/f5em_extern-<date stamp>
• Scheduling remote backups of the statistics database
You also have the option configure the Enterprise Manager system to allow remote access to the statistics
database (MySQL database) from a third-party database browsing or editing tool, and then schedule a regular
backup interval. The MySQL database listens on port 3306 of your Enterprise Manager system when data
collection is enabled
To successfully query the MySQL database, you use the following credentials:
• Username: f5em_client
• Password: default
• Database name: f5em_extern
Page 70 of 91
If the Enterprise Manager system is configured as a high availability system, you can back up your system’s
monitoring information by regularly running the ConfigSync task.
8. Using Alerts
• Overview of alerts
Enterprise Manager can take actions on a wide variety of alerts that you can use in managing your F5 Networks
devices. The alerts that you can set include:
o Statistical data thresholds exceeded. Statistical data threshold alerts are available only for
statistics stored locally on the Enterprise Manager system.
o Device status change
o Certificate expired or near-expiration
o Completed software, hotfix, or attack signature image installations
o Failed software, hotfix, or attack signature image installations
o Clock skew between the Enterprise Manager and managed devices
o Failed rotating archive creation
• Setting alert default options
When you create alerts, you can specify delivery options for that alert. You can also set a certain recipient’s email
address, or a remote syslog server, to receive notifications for all alerts by default. Once these are set, Enterprise
Manager sends alert notifications to the default email address you specified, or to the remote syslog server,
unless the alert is configured to notify another recipient.
• Creating alerts for Enterprise Manager
To help maintain the health of the Enterprise Manager device, you can create system alerts to notify you when
CPU, disk, or memory usage meets or exceeds a particular threshold.
• Creating, modifying, and deleting alerts for devices
9. Managing Device Certificates
• Monitoring device certificates
Certificate monitoring is enabled by default for all managed devices.
• Creating a device certificate alert
10. Auditing Enterprise Manager System Events
• Reviewing the different event logging options
So that you can review valuable information about pertinent events, Enterprise Manager provides access to a
comprehensive set of logs. The types of logs you can view are:
o System events: System event messages are based on Linux events, and are not specific to the
Enterprise Manager system.
o Local traffic events: Local-traffic event messages pertain specifically to the local EM system.
o Audit events: Audit event messages are logged when changes are made to the Enterprise Manager
system configuration. The Enterprise Manager system logs the messages for these events in the file
/var/log/em. Logging audit events is optional.
Enterprise Manager and BIG-IP systems use the Linux utility, syslog-ng, to log events.
• Auditing events for Enterprise Manager
The Enterprise Manager system features seven processes that enable the system to manage other F5 Networks
devices in the network. The processes are briefly described here:
discoveryd, emadmind (ConfigSync), emalertd, emdeviced, emfiled, emreportd, swimd
• Searching the audit log
11. Working with Application Security Manager Policies and Attack Signatures
• Staging and deploying Application Security Manager Policies
Starting with BIG-IP Application Security Manager (ASM) version 10.0.1, Enterprise Manager helps you to easily
manage security policies and ASM attack signature files among multiple devices.
Staging and deploying security policies to your Application Security Policy devices using the Stage Security
Policy Changeset wizard involves three main procedures.
• Selecting a security policy to stage and deploy to a device
• Selecting a target device on which to install the security policy
• Verifying, staging, and deploying the security policy
• Managing ASM attack signatures for Application Security Manager
Page 71 of 91
Manual: Enterprise Manager: Monitoring Network Health and Activity (v3.0)
C1. Using iHealth for configuration collection and diagnostics
When you create a task to gather iHealth diagnostics, Enterprise Manager captures a snapshot of the specified
device in the form of a qkview file. The iHealth service compares the device's information to an F5 database
containing known issues, common configuration errors, and F5 published best practices.
Scheduling Enterprise Manager to perform a weekly data collection of iHealth diagnostics data ensures that your
managed devices are working at peak efficiency and you are apprised of any upcoming system events.
C2. Using Alerts
You can configure Enterprise Manager to manage alerts in these ways:
• Send SNMP traps to a remote SNMP server
• Send email alerts to a specific recipient using SMTP
Before configuring SMTP email notification alerts, you must configure DNS resolution and create an SMTP server
configuration. SMTP port 25, for SSL encryption, port 465.
C3. Managing Traffic and System Certificates
The information that displays on the certificate list screen provides a summary of:
• Certificate expiration status
• Certificate and organization name
• Device on which the certificate is configured
Certificate expiration status flag definitions
Red, This certificate has expired.
Yellow,
This
certificate will expire in 30 days or less. Green, This certificate is valid and will remain valid for 30 days.
C4. Logging and Auditing
Enterprise Manager creates separate audit and system event logs specific to:
• Enterprise Manager activities associated with device management events
• System events for Enterprise Manager itself, not related to device management
C5. Customizing Views for Network Objects
You can view activity in a summary and detailed graph format. This
information ensures that your network is performing efficiently and helps you to troubleshoot potential issues.
Viewing
C6. Collecting Statistics
When statistics data collection is enabled, Enterprise Manager stores the following information in its statistics
database for each managed device on which the Data Collection Agent is installed:
• Specifics about the managed devices, such as host name, IP address, and software version
• Details, such as object type and name, about any enabled network objects associated with a managed device
• Performance and health data for managed devices and associated network objects
Page 72 of 91
Tip: If Enterprise Manager is managing devices that are part of a BIG-IP Global Traffic Manager synchronization
group, Enterprise Manager temporarily disrupts communication between GTM and remote BIG-IP objects while it
verifies the version of the big3d agent on GTM. To reduce the impact to production traffic relying on the BIG-IP
GTM infrastructure, we recommend that you enable statistics data collection during a maintenance window.
C7. Using Statistics Profiles
Statistics data collected for the standard statistics profiles
When statistics collection is enabled, Enterprise Manager collects the following statistics data to create standard reports.
Report name
Statistics data collected for this report
Certificate Inventory
None
Device Inventory
None
Capacity Planning
• Device CPU - Processor Utilization (%)
• Device Global Memory Utilization (%)
• Device Global Client: Bits In (/Sec)
• Device Global Client: Bits Out (/Sec)
Flapping Node
None
Flapping Pool Member
None
GTM Object Activity
• GTM Virtual Server Bits In (Ave per Sec)
• GTM Virtual Server Bits Out (Ave per Sec)
• GTM Virtual Server Connections (Ave per Sec)
LTM Node Inventory
None
SSL TPS Usage
• Device Client SSL Native Connections (per Sec)
• Device Client SSL Compat-mode Connections (per Sec)
LTM Object Activity
• LTM Node Bits In (per Sec)
• LTM Node Bits Out (per Sec)
• LTM Pool Member Bits In (per Sec)
• LTM Pool Bits In (per Sec)
• LTM Pool Bits Out (per Sec)
• LTM Virtual Server Bits In (per Sec)
• LTM Virtual Server Bits Out (per Sec)
LTM Unused Object
• LTM Node Bits In (per Sec)
• LTM Node Bits Out (per Sec)
• LTM Pool Member Bits In (per Sec)
• LTM Pool Bits In (per Sec)
• LTM Pool Bits Out (per Sec)
• LTM Virtual Server Bits In (per Sec)
• LTM Virtual Server Bits Out (per Sec)
C8. Storing Statistics
Enterprise Manager stores statistical data until the system reaches the storage capacity, which is by default, 1
GB stored locally.
By default, Enterprise Manager stores health and performance monitoring statistics data in the database located
on its hard drive. You have the option of configuring Enterprise Manager to store these statistics on a hard drive
that is separate (external) from the Enterprise Manager system. Storing statistics on an external database clears
space on Enterprise Manager for more storage of archives, images, configuration files, and so forth. A space
dedicated only to health and performance monitoring statistic data can also provide you with more historical data
storage. To use an external database for health and performance monitoring statistics storage, you must create
the external database and then configure Enterprise Manager to store data on that database.
Before configuring Enterprise Manager to store statistics data on an external database, you must create an
external database on a system that is running Oracle MySQL version 5.1 with patch 52 or later.
C9. Understanding and Using Reports
You can use Enterprise Manager reports to retrieve and view information about the devices and BIG-IP Local
Traffic Manager (LTM) and BIG-IP Global Traffic Manager (GTM) objects in your network. To create a report, you
define parameters, the devices from which to collect the data, and the object types you want to include. You can
collect data and view the report immediately, or you can schedule the report to run in the future either once, or at
regular intervals. Depending on the report type, completed reports are presented in Adobe portable document
format (PDF) or comma-separated value (CSV) text, which you can export to a spreadsheet, such as Microsoft
Excel. The Capacity Planning report also supports an interactive HTML format.
Page 73 of 91
C10. Viewing Application Statistics for Multiple Devices
You can use Enterprise Manager to view reports for managed devices that are provisioned to use Analytics, also
referred to as Application Visibility and Reporting (AVR). The Enterprise Manager device must have an AVR
centralized reporting license. You can display the Analytics reports for a single BIG-IP device or aggregated
reports for a group of devices. In this way, Enterprise Manager provides centralized Analytics reporting.
C11. Health and Performance Monitoring Database Schema
You also have the option use this collected data to create your own queries and customized graphs and reports
using the details provided in the following sections in conjunction with any MySQL Connector,
7.4: Manage software images
Manual: BIG-IP Redundant Systems Configuration Guide (v11.0)
C1. Introducing BIG-IP System Redundancy
The Traffic Management Operation System (TMOS) within the BIG-IP system includes an underlying architecture
that allows you to create a redundant system configuration, known as device service clustering (DSC), for
multiple BIG-IP devices on a network. This redundant system architecture provides both synchronization of BIGIP configuration data and high availability at user-defined levels of granularity.
Configuration components
Devices. A device is a physical or virtual BIG-IP system, as well as a member of a local trust domain and a
device group. Each device member has a set of unique identification properties that the BIG-IP system
generates.
Device groups. A device group is a collection of BIG-IP devices that trust each other and can synchronize, and
sometimes fail over, their BIG-IP configuration data.
You can create two types of devices groups:
Sync-Failover. A Sync-Failover device group contains devices that synchronize configuration data and support
traffic groups for failover purposes when a device becomes unavailable. Devices in a Sync-Failover device group
must match with respect to hardware platform, product licensing, and module provisioning.
Sync-Only. A Sync-Only device group contains devices that synchronize configuration data, such as policy data,
but do not synchronize failover objects.
A BIG-IP device can be a member of only one Sync-Failover group. However, a device can be a member of both
a Sync-Failover device group and a Sync-Only device group.
Traffic groups. A traffic group is a collection of related configuration objects (such as a virtual IP address and a
self IP address) that run on a BIG-IP device and process a particular type of application traffic.
Device trust and trust domains. Device trust establishes trust relationships between BIG-IP devices on the
network, through mutual certificate-based authentication. A trust domain is a collection of BIG-IP devices that
trust one another and can therefore synchronize and fail over their BIG-IP configuration data, as well as
exchange status and failover messages on a regular basis. A local trust domain is a trust domain that includes
the local device, that is, the device you are currently logged in to.
Folders and sub folders. Folders and sub-folders are containers for the configuration objects on a BIG-IP device.
For every administrative partition on the BIG-IP system, there is a high-level folder. At the highest level of the
folder hierarchy is a folder named root.
Configuration overview for failover
To set up failover, you perform these tasks:
• Add the local device as a member of the local trust domain.
• Specify on the local device the IP addresses that you want the system to use for configuration
synchronization, failover, and mirroring.
• Add the local device as a member of a Sync-Failover device group.
• If needed, create a custom traffic group.
• Assign the relevant traffic group to the folder that you want to fail over (either the root folder or a sub-folder).
Serial and network failover
Note: You can use serial failover only when the device group contains a maximum of two devices. For a group
with more than two devices, network failover is required. Also, if the hardware platform is a VIPRION platform,
you must use network failover.
Page 74 of 91
C2. Understanding Devices
IP addresses for config sync, failover, and mirroring
Each trust domain member contains device connectivity information, that is, the IP addresses that you define on
a device for configuration synchronization (config sync), failover, and connection mirroring.
Config sync IP address
This is the IP address that you want the BIG-IP system to use when synchronizing configuration objects to the
local device. By default, the system uses the self IP address of VLAN internal.
Important: A self IP address is the only type of BIG-IP system address that encrypts the data during
synchronization. For this reason, you cannot use a management IP address for config sync.
Failover IP addresses
These are the IP addresses that you want the BIG-IP system to use when another device in the device group
fails over to the local device. You can specify two types of addresses: unicast and multicast.
For appliance platforms, specifying two unicast addresses should suffice. For VIPRION platforms, you should
also retain the default multicast address that the BIG-IP system provides.
The recommended unicast addresses for failover are:
• The self IP address that you configured for either VLAN HA or VLAN internal. If you created VLAN HA when
you initially ran the Setup utility on the local device, F5 recommends that you use the self IP address for that
VLAN. Otherwise, use the self IP address for VLAN internal.
• The IP address for the local management port.
Mirroring IP addresses
These are the IP addresses that you want the BIG-IP system to use for connection mirroring. You specify both a
primary addresses, as well as a secondary address for the system to use if the primary address is unavailable. If
you configured VLAN HA, the system uses the associated self IP address as the default address for mirroring. If
you did not configure VLAN HA, the system uses the self IP address of VLAN internal.
About device status
Active
Forced offline
Offline
Standby
Unknown
A minimum of one floating traffic group is currently active on the device.
This status applies to Sync-Failover device groups only.
An administrator has intentionally made the device unavailable for processing traffic.
The device is unavailable for processing traffic.
The device is available for processing traffic, but all traffic groups on the device are in a standby state.
This status applies to Sync-Failover device groups only.
The status of the device is unknown.
Page 75 of 91
C3. Understanding Device Trust
Before any BIG-IP devices on a local network can synchronize configuration data or fail over to one another, they
must establish a trust relationship known as device trust. Device trust between any two BIG-IP devices on the
network is based on mutual authentication through the signing and exchange of x509 certificates.
Within a local trust domain, in order to establish device trust, you designate each BIG-IP device as either a
certificate signing authority or a subordinate non-authority. For each device, you also specify peer authorities.
Certificate signing authorities
A certificate signing authority can sign x509 certificates for another BIG-IP device that is in the local trust domain.
Subordinate non-authorities
A subordinate non-authority device is a device for which a certificate signing authority device signs its certificate.
Peer authorities
A peer authority is another device in the local trust domain that can sign certificates if the certificate signing
authority is not available.
When a BIG-IP device joins the local trust domain and establishes a trust relationship with peer devices, the
device and its peers exchange their device properties and device connectivity information. This exchange of
device properties and IP addresses is known as device discovery.
By default, each BIG-IP device on the local network is a member of a one-member local trust domain. Use this
procedure to log into any BIG-IP device on the network and add one or more devices to the local system's local
trust domain.
C4. Understanding Folders
For every administrative partition on the BIG-IP system, the BIG-IP system creates an equivalent folder with the
same name. In the context of the BIG-IP system, a folder is a container for BIG-IP system objects.
Folders resemble standard UNIX directories, in that the system includes a hierarchy of folders and includes a root
folder (represented by the / symbol) that is the parent for all other folders on the system.
By default, the BIG-IP system assigns a Sync-Failover device group and a traffic group to the root folder. All
folders and sub-folders under the root folder inherit these default assignments.
C5. Understanding Device Groups
You can create two types of devices groups:
Sync-Failover. A Sync-Failover device group contains devices that synchronize configuration data and support
traffic groups for failover purposes when a device becomes unavailable. A maximum of eight devices is
supported in a Sync-Failover device group.
Sync-Only. A Sync-Only device group contains devices that synchronize configuration data, such as policy data,
but do not synchronize failover objects. A maximum of 32 devices is supported in a Sync-Only device group.
A BIG-IP device can be a member of only one Sync-Failover group. However, a device can be a member of both
a Sync-Failover device group and a Sync-Only device group.
A typical use of a Sync-Only device group is one in which you configure a device to synchronize the contents of a
specific folder to a different device group than to the device group to which the other folders are synchronized.
For Sync-Only device groups, you can choose to either automatically or manually synchronize configuration data
in a device group. When enabled, this feature causes any BIG-IP device in the device group to synchronize its
configuration data to the other members of the device group whenever that data changes.
Note: For Sync-Failover device groups, the BIG-IP system supports manual synchronization only.
The most common reason to use a Sync-Only device group is to synchronize a
specific folder containing policy data that you want to share across all BIG-IP
devices in a local trust domain, while setting up a Sync-Failover device group
to fail over the remaining configuration objects to a subset of devices in the
domain. In this configuration, you are using a Sync-Only device group attribute
on the policy folder to override the inherited Sync-Failover device group
Page 76 of 91
attribute. Note that in this configuration, Bigip1 and Bigip2 are members of both the Sync-Only and the SyncFailover groups.
C6. Understanding Traffic Groups
When a BIG-IP device becomes unavailable, a traffic group floats (that is, fails over) to another device in a device
group to ensure that application traffic continues to be processed with little to no interruption in service.
Important: Although a specific traffic group can be active on only one device in a device group, the traffic group
actually resides and is in a standby state on all other device group members, due to configuration
synchronization.
Only certain types of configuration objects can belong to a traffic group. Examples of traffic group objects are self
IP addresses and virtual IP addresses.
Note: A Sync-Failover device group can support a maximum of 15 traffic groups.
Default traffic groups on the system
When you initially run the Setup utility on a device or upgrade from a previous BIG-IP version, the system creates
two default traffic groups:
 A default traffic group named traffic-group-1 initially contains the floating self IP addresses that you
configured for VLANs internal and external, as well as any iApps application services, virtual IP
addresses, NATs, or SNAT translation addresses that you have configured on the device.
 A default non-floating traffic group named traffic-group-local-only contains the static self IP addresses
that you configured for VLANs internal and external. Because the device is not a member of device
group, the traffic group never fails over to another device.
A MAC masquerade address is a unique, floating Media Access Control (MAC) address that you create and
control. You can assign one MAC masquerade address to each traffic group on a BIG-IP device.
By assigning a MAC masquerade address to a traffic group, you indirectly associate that address with any
floating IP addresses (services) associated with that traffic group.
A primary purpose of a MAC masquerade address is to minimize ARP communications or dropped packets as a
result of a failover event. A MAC masquerade address ensures that any traffic destined for the relevant traffic
group reaches an available device after failover has occurred, because the MAC masquerade address floats to
the available device along with the traffic group. Without a MAC masquerade address, on failover the sending
host must relearn the MAC address for the newly-active device, either by sending an ARP request for the IP
address for the traffic or by relying on the gratuitous ARP from the newly-active device to refresh its stale ARP
entry.
Note: When you assign a MAC masquerade address to a traffic group, the BIG-IP system sends a gratuitous
ARP to notify other hosts on the network of the new address.
Page 77 of 91
The types of configuration objects that you can associate with a floating traffic group are:
• iApps application services
• Virtual IP addresses
• NATs
• SNAT translation addresses
• Self IP addresses
C7. Working with Folders
System -> Platform
C8. Understanding Fast Failover
The BIG-IP system includes a feature known as fast failover. Fast failover is a feature that is based on the
concept of an HA group. An HA group is a set of trunks, pools, or clusters (or any combination of these) that you
want the BIG-IP system to use to calculate an overall health score for a device in a redundant system
configuration.
The fast failover feature is designed for a redundant configuration that contains a maximum of two devices in a
device group, with one active traffic group.
A health score is based on the number of members that are currently available for any trunks, pools, and clusters
in the HA group, combined with a weight that you assign to each trunk, pool, and cluster. The device that has the
best overall score at any given time becomes or remains the active device.
SOL8086: Replacing a BIG-IP system in a redundant pair without interrupting service
Important: As a result of an issue affecting BIG-IP 9.x through 11.x, you must disable connection mirroring or
persistence mirroring prior to powering down the standby unit
When you have verified that the restored configuration loads without errors, perform one of the following steps:
o If the BIG-IP systems use serial cable failover, connect all of the network cables.
o If the BIG-IP systems use network failover, power down the replacement system, connect all of the network
cables, and then power the replacement system back on. This extra step reduces the likelihood of IP
conflicts in the network until network failover traffic is restored between the two units.
BIG-IP System: Upgrading Active-Standby Systems (v11.0)
Upgrading BIG-IP Active-Standby Systems to Version 11.0
An upgrade of BIG-IP active-standby systems to version 11.x involves the following tasks.
a) Preparing Device A (the active mode BIG-IP 1 system) and Device B (the standby mode BIG-IP 2
system)
b) Upgrading Device B (the standby mode BIG-IP 2 system)
c) Upgrading Device A (the standby mode BIG-IP 1 system)
d) Verifying the upgrade
e) Configuring module-specific settings
Preparing BIG-IP modules for an upgrade from version 10.x to version 11.0
Access Policy Manager system does not require specific preparation.
Post-upgrade activities: Sessions, Authentication agents and SSO methods, iRule for processing URI,
OAM Support, Citrix support functionality, Reporting functionality.
Application Security Manager system does not require specific preparation.
Global Traffic Manager systems do not require any preparation.
Link Controller system does not require specific preparation.
Local Traffic Manager system does not require specific preparation
Protocol Security Module does not require specific preparation
WebAccelerator systems require specific preparation tasks and changes:
Page 78 of 91
Preparation activities: Symmetric deployment, Unpublished policies, Signed policies, Configuration files,
Debug Options
Post-upgrade activities: Web acceleration, Compression, Request logging, Policy logging,
URL normalization, iControl backward compatibility
WAN Optimization Manager systems do not require specific preparation
Preparing BIG-IP active-standby systems for an upgrade
1. Examine the Release Notes for specific configuration requirements, and reconfigure the systems, as
necessary.
2. From the device that is running the latest configuration, synchronize the configuration to the peer unit
3. For each device, reactivate the license.
4. For each device, click System > High Availability > Redundancy, and, from the Redundancy State
Preference list, select None.
5. For each device, create a backup file.
6. Download the BIG-IP version 11.x .iso file from the AskF5 downloads web site
7. Import the version 11.x software image file to each device.
Upgrading the standby BIG-IP 2 system
1. Select a location to install the image, and click Install.
2. Reboot the device to the location of the installed version 11.x software image. System > Software
Management > Boot Locations -> Activate
Upgrading the active BIG-IP 1 system
1. Select a location to install the image, and click Install.
2. Force the BIG-IP device (Device A) to standby mode.
3. Reboot the BIG-IP device (Device A) to the location of the installed version 11.x software image. 1.
System > Software Management > Boot Locations -> Activate
4. Synchronize the configuration.
Verifying a BIG-IP active-standby upgrade
BIG-IP System: Upgrading Active-Active Systems (v11.1)
Upgrading BIG-IP Active-Active Systems to Version 11.X
An upgrade of BIG-IP active-active systems to version 11.x involves the following tasks.
a) Preparing Device A (active mode on the BIG-IP 1 system) and Device B (active mode on the BIG-IP 2
system)
b) Forcing Device B to standby mode
c) Upgrading Device B (the standby mode BIG-IP 2 system)
d) Upgrading Device A (the standby mode BIG-IP 1 system)
e) Verifying the upgrade
f) Configuring module-specific settings
Preparing BIG-IP modules for an upgrade from version 10.x to version 11.0
-- Los mismos que el anterior
Preparing BIG-IP active-active systems for an upgrade
Prerequisites:
• The BIG-IP systems (Device A and Device B) are configured as an active-active pair.
• Each BIG-IP device is running the same version of 10.x software.
• The BIG-IP active-active devices are the same model of hardware.
1. Examine the Release Notes for specific configuration requirements, and reconfigure the systems, as
necessary.
2. For each device, synchronize the configuration.
3. For each device, reactivate the license.
4. For each device, disable the VLAN Fail-safe setting.
System > High Availability > Fail-safe > VLANs. >
Remove
Page 79 of 91
5. For each device, disable the Gateway Fail-safe setting. System > High Availability > Fail-safe > VLANs. >
Remove
6. For each device, click System > High Availability > Redundancy , and, from the Redundancy State
Preference list, select None.
7. For each device, create a backup file.
8. Download the BIG-IP version 11.x .iso and .md5 files from the AskF5 downloads web site
9. Import the version 11.x software image and MD5 files to each device.
10. Force Device B (the BIG-IP 2 device) into standby mode. System > High Availability > Redundancy > Force to
Standby
11. Do one of the following steps to disconnect Device B (the standby BIG-IP 2 device) from the network.
 Disconnect all network cables, except for the management interface cable.
 Shut down the interfaces on the upstream device.
Upgrading the standby BIG-IP 2 system
Prerequisites: Device A (the active BIG-IP 1 system) and Device B (the standby BIG-IP 2 system) must be
prepared to upgrade Device B with version 11.x software.
1. Select a location to install the image, and click Install.
2. Reboot the device to the location of the installed version 11.x software image. System > Software
Management > Boot Locations -> Activate
3. Do one of the following steps to disconnect Device A (the version 10.x active BIG-IP 1 device) from the
network.
• Disconnect all network cables, except for the management interface cable.
• Shut down the interfaces on the upstream device.
4. Do one of the following steps to connect Device B (the version 11.x BIG-IP with traffic-group-1) to the
network.
• Reconnect all network cables.
• Enable the interfaces on the upstream device.
5. Flush the Level 2 databases on the upstream devices to start passing traffic to the Device B traffic-group1 in active state.
Upgrading the standby BIG-IP 1 system
Prerequisites: Device A (the version 10.x BIG-IP 1 system) must be prepared to upgrade the software to version
11.x.
and Device A is in standby mode.
and Device B has version 11.x installed with traffic-group-1 and
traffic-group-2 in active state.
1. Select a location to install the image, and click Install.
2. Reboot the BIG-IP device (Device A) to the location of the installed version 11.x software image. 1.
System > Software Management > Boot Locations -> Activate
3. Stop the services on the device. # tmsh , (tmsh) # stop sys service all
4. Do one of the following steps to connect Device A to the network.
• Reconnect all network cables.
• Enable the interfaces on the upstream device.
5. Start the services on Device A. # tmsh , (tmsh) # start sys service all
Device A restarts, with traffic-group-2 in active state and traffic-group-1 in standby state.
6. For each device, create the VLAN Fail-safe setting.
7. For each device, create the Gateway Fail-safe setting.
Verifying a BIG-IP system active-active upgrade
Page 80 of 91
SOL13123: Managing BIG-IP product hotfixes (11.x)
Hotfixes must be installed on an inactive boot location.
The configuration and license from the current boot location is copied to the target installation location.
For Virtual Clustered Multiprocessing (vCMP) systems, hotfixes are managed from the vCMP Guest.
The Software Management interface automatically installs the hotfix file to the image library (the /shared/images/
directory) on the BIG-IP system.
Verifying the MD5 checksum of the hotfix image:
# cd /shared/images
# md5sum --check Hotfix-BIGIP-11.0.0-8120.0-HF1.iso.md5
Hotfix-BIGIP-11.0.0-8120.0-HF1.iso: OK
Installing a hotfix image using the tmsh utility
# tmsh
(tmsh) # install sys software hotfix Hotfix-BIGIP-11.0.0-1234.0-HF1.iso volume HD1.1
(tmsh) # show sys software status
Manual Chapter: Preparing the System for Installation (v10.x)
Important: You cannot upgrade and roll forward a configuration directly to this version from versions 9.2.x or
earlier. If you have a configuration from version 9.2.x or earlier, you must upgrade to version 9.3.x or 9.4.x, and
then upgrade to version 10.x.
Performing prerequisite tasks
 Configuring the management interface. (config command)
 Establishing a connection to the system.
 Setting the active volume.
 Making sure the license is active and updated.
This version of the BIG-IP system software uses the volumes disk-formatting scheme. A specific section of a hard
drive is called a volume. Also called logical volume management (LVM), this feature supports all platforms and
modules available for the BIG-IP system.
SOL4178: Restarting the BIG-IP system in single-user mode (GRUB 0.97)
GRUB 0.97 (9.x – 11.4.1)
GRUB2 (11.3.0 – 11.4.1)
Displaying part of the GRUB configuration (title = 0.97, menuentry = 2)
[root@training:Active:Standalone] config # grub_default -d | grep -A6 "TMOS maintenance"
title TMOS maintenance
root (hd1,0)
kernel /vmlinuz.mos root=/dev/ram0 rw console=ttyS0 ramdisk_size=224707.5 skip_media
initrd /initrd.img.mos
# TIC_STATIC_KEY: st.mos
# TIC_STATIC_VERSION: 2.8.1-44.0
PROCEDURE
1. Connect a terminal to the BIG-IP serial console port.
2. Restart the BIG-IP system.
While restarting, the BIG-IP system displays the GRUB menu and counts down before continuing the start process.
3. Before the countdown expires, use the Up Arrow and Down Arrow keys to select the appropriate start image.
Note: Alternately, press Shift+6 (^) to move up, and press the V key to move down.
Page 81 of 91
4.
Press the E key to edit the start options.
A new GRUB menu screen displays.
5. Use the Up Arrow and Down Arrow keys to select the line that begins with kernel /boot/vmlinuz.
Note: Alternately, press Shift+6 (^) to move up, and press the V key to move down.
6. Press the E key to edit the line.
7. Type the word single at the end of the kernel /boot/vmlinuz line, and then press Enter.
For example:
kernel /boot/vmlinuz single
Depending on the platform, the kernel operative syntax may appear similar to the following example:
kernel
/boot/1/vmlinuz
ro
root=UUID=2c3f024c-ff84-499b-8466-0a189963c55d
console=ttyS0
panic=1
platform=Mercury quiet single
The previous menu screen appears, and the system shows the new start command.
8. Press the B key to start the system using the modified options.
A prompt displays. You have now started the system in single-user mode.
9. When you are finished using single-user mode, type exit or reboot to return the BIG-IP system to normal operating
mode.
Page 82 of 91
SOL13117: Performing a clean installation of BIG-IP 11.x or Enterprise Manager 3.x
On rare occasions, you may be required to perform a clean installation of BIG-IP 11.x or Enterprise Manager 3.x.
During a clean installation, all mass-storage devices are wiped, therefore restoring the BIG-IP system or
Enterprise Manager to its factory defaults. In addition, a clean installation allows you to reinstall a BIG-IP unit that
no longer boots from any of its boot locations.
1. You have booted the F5 system from a USB removable media containing a BIG-IP 11.0.0 image, but you
want to perform a custom installation using the diskinit and image2disk utilities.
2. You have booted the F5 system from a PXE server.
Otherwise, to reinstall the system according to the manufacturing installation plan displayed in the output, press
Enter and skip to step 10.
To wipe all mass-storage devices inside the BIG-IP system, type the following command:
# diskinit --style volumes
Note: BIG-IP 11.x cannot be installed on a CompactFlash media drive; you must use boot locations on the
system’s hard drive.
SOL13127: Restoring the BIG-IP configuration to factory default settings (11.x)
You may occasionally need to remove the current BIG-IP configuration and restore the system to the factory
default setting. To do so, you can use the tmsh load sys config default command.
The tmsh load sys config default command saves the currently-running configuration to the
/var/local/scf/backup.scf file, and then loads the /defaults/defaults.scf file to restore the configuration to factory
default settings.
When you restore the BIG-IP configuration to factory default settings, the system performs the following tasks:
 Removes all BIG-IP local traffic configuration objects
 Removes all BIG-IP network configuration objects
 Removes all non-system maintenance user accounts
 Retains the management IP address
 Removes system maintenance user account passwords (root and admin)
 Retains the BIG-IP license file
 Retains files in the /shared partition
 Retains manually-modified bigdb database variables
(tmsh) # load sys config default
(tmsh) # save sys config partitions all
SOL10449: Upgrading the software version or applying a hotfix to BIG-IP GTM
Beginning in BIG-IP GTM 9.3.0, changes were made regarding how BIG-IP GTM devices communicate. The
change includes a version field in the message packets that is used to communicate between BIG-IP GTM
devices. This version field alleviates the need to remove BIG-IP GTM devices from a synchronization group. If a
BIG-IP GTM device receives a message packet with a version that does not match, no changes are allowed by
the device.
Installing the upgrade software
1. Log in to the command line of the BIG-IP GTM system you are going to upgrade.
2. Stop the named process by typing the following command:
Note: Stopping the named process prevents the BIG-IP GTM system from answering DNS requests that
fall back to BIND.
bigstart shutdown named
3. Stop the big3d process by typing the following command:
Note: Stopping the big3d process prevents the BIG-IP GTM system from communicating with other BIGIP devices.
bigstart shutdown big3d
4. Stop the gtmd process by typing the following command:
Note: Stopping the gtmd process prevents the BIG-IP GTM system from answering DNS requests.
bigstart shutdown gtmd
5. Install the upgrade software
Page 83 of 91
6. Reboot the BIG-IP GTM once the hotfix has finished installing by typing the following command:
/usr/bin/full_box_reboot
Manual Chapter: Upgrading the VIPRION System
When you perform an upgrade, the system upgrades the open boot location of each blade of the cluster
concurrently. Note that the term open boot location refers to the boot location to which the system is not currently
booted.
8.1: Modify and manage virtual servers
SOL8018: Overview of the BIG-IP HTTP class traffic flow
An HTTP class provides a method for matching HTTP requests to specific patterns and defining the action that
should be applied to that traffic.
An HTTP class may be configured to match HTTP requests based on the following attributes:
 Hosts
 URI Paths
 Headers
 Cookies
The HTTP class must then define the actions to be applied to matching requests. An HTTP class may be
configured to define the following actions:
 Send matching requests to the pool specified by the HTTP class.
 Send matching requests to the virtual server default pool.
 Redirect matching requests to a specified URL.
 Rewrite the request URI for matching requests to a specified URI without sending an HTTP redirect to
the client.
The following table illustrates the manner in which requests are handled, depending on the HTTP class and
virtual server pool configuration:
Ensuring that all traffic is accounted for
The ability to configure various filter and pool configuration combinations allows for several options to control
traffic flow and provides flexibility in designing solutions. Evaluate the HTTP class configurations carefully, in
order to ensure that all traffic is accounted for.
Possible methods to ensure that all requests are matched:
 Create an HTTP class, with no filters, that redirects requests to the site homepage; apply the HTTP class
as the virtual server’s last HTTP class.
 Create an HTTP class with no filter that rewrites the request to a specific page on the server; apply the
HTTP class as the virtual server's last HTTP class.
Ordering HTTP classes for the virtual server
You can configure a virtual server to use multiple HTTP classes. The order of the HTTP classes determines how
the request is evaluated. When a request matches an HTTP class, the request is processed and is not evaluated
against any subsequent HTTP classes. If a request does not match any of the HTTP classes, the virtual servers
default pool will be used; if the virtual server does not have a default pool configured, the request will be dropped.
Logging unmatched requests
When the configuration results in a dropped request, the drop will not be logged, which is the desired behavior in
most situations. However, you might want to ensure that all traffic is accounted for.
Page 84 of 91
SOL10640: Pool member reselection options
On a BIG-IP system, in the event that a pool member fails, the default behavior is for connection attempts to that
pool member to continue until the pool member is marked down by its assigned monitor(s). This behavior may
cause the BIG-IP system to load balance new connections to a pool member that has just failed, but whose
monitor has not yet timed out.
You can improve the behavior outlined in the above example by performing the following actions:
 Selecting a new pool member as soon as the BIG-IP system detects that the pool member to which it is
attempting to connect has become unresponsive.
 Immediately marking the unresponsive pool member down to avoid further connections being load
balanced to that pool member.
To perform the aforementioned actions, you can either write an iRule, or beginning in BIG-IP version 10.0.0, you
can use features readily available within the Configuration utility of the BIG-IP system.
You can improve the default behavior with an iRule similar to the following example:
when LB_FAILED {
if { [active_members [LB::server pool]] > 0 } {
catch { LB::down }
LB::mode rr
LB::reselect
}
}
This iRule allows a client-side connection to remain open after a pool member has become unresponsive. For
example, if the pool member failed to complete a TCP handshake or respond to an ARP request.
Using the LB::reselect iRule command, the client request is then load balanced to a different pool member, or
even to a different pool, once the LB_FAILED event fires. The time between the initial connection attempt
and LB_FAILED is dependent on profile parameters. For example, in regards to TCP, the profile parameters that
affect SYN retransmission.
The LB::down iRule command causes the pool member to be marked down upon the LB_FAILED event rather
than wait for its monitor(s) to time out and limit the number of client connections affected. More complex iRules
can be written to defer LB::down until a number of failures have occurred to allow a margin of error.
Improving the default behavior using the Inband monitor feature (10.x or later)
Beginning in BIG-IP 10.x, the Inband monitor type was introduced. The Inband monitor determines the availability
of a pool member based on a specified number of failed connection attempts or data request attempts within a
specified time interval. This monitor works in parallel with regular monitors, and can be used instead of
the LB::down iRule command.
SOL13675: Overview of the stateless virtual server
A stateless virtual server provides improved UDP performance over a standard virtual server in specific
scenarios, but with limited feature support.
A stateless virtual server accepts traffic that matches the virtual server address and load balances the packet to
the pool members without attempting to match the packet to a pre-existing connection in the connection table.
Any new connection entry is immediately removed from the connection table. This behavior addresses the
requirements for one-way UDP traffic that needs to be processed at very high throughput levels. As such, a
stateless virtual server is not be suitable for processing traffic that requires stateful tracking, such as TCP traffic.
The stateless virtual server does not support the following features:
 iRules
 Persistence
 Connection mirroring
 Rate shaping
 SNAT automap
(tmsh) # create ltm virtual <vs name> stateless ip-protocol udp pool <pool name> destination <IP:Port>
(tmsh) # create ltm virtual myIngressStatelessvs stateless ip-protocol udp pool myDNSpool destination
30.30.30.234:53
(tmsh) # save sys config
Page 85 of 91
SOL12272: Overview of BIG-IP virtual server types (10.x)
The following table lists the virtual server type options and defines each virtual server type:
Virtual server Description of virtual server type
type
Standard
A Standard virtual server directs client traffic to a load balancing pool and is the most basic type of virtual
server. It is a general purpose virtual server that does everything not expressly provided by the other type of
virtual servers.
Forwarding
(Layer 2)
A Forwarding (Layer 2) virtual server typically shares the same IP address as a node in an associated VLAN. A
Forwarding (Layer 2) virtual server is used in conjunction with a VLAN group.
Forwarding (IP)
A Forwarding (IP) virtual server forwards packets directly to the destination IP address specified in the client
request. A Forwarding (IP) virtual server has no pool members to load balance.
Performance
(Layer 4)
A Performance (Layer 4) virtual server has a FastL4 profile associated with it. A Performance (Layer 4) virtual
server increases the speed at which the virtual server processes packets.
Performance
(HTTP)
A Performance (HTTP) virtual server has a FastHTTP profile associated with it. The Performance (HTTP)
virtual server and related profile increase the speed at which the virtual server processes HTTP requests.
Stateless
A Stateless virtual server improves the performance of UDP traffic in specific scenarios. (10.2.2 and later)
Reject
A Reject virtual server rejects any traffic destined for the virtual server IP address.
HTTP Basics I Web Based Training Course
In this presentation, we will discuss the general format of HTTP messages and specific information about HTTP
requests and typical headers in those requests. In HTTP Basics II, we will focus on HTTP responses and two
examples where various HTTP headers are key to managing HTTP communication.
HTTP is the fundamental means of communication used by the World Wide Web. It defines a formal syntax that
allows user-agents, such as browsers, to interact with web servers. HTTP is one of many protocols designed to
allow clients to store and retrieve files from servers. Other examples include File Transfer Protocol (FTP),
Common Internet File System (CIFS) or Network File System (NFS). Each has unique capabilities; HTTP has
been designed specifically for the needs of the World Wide Web. For example, an HTTP request can specify the
language the browser would like to see in a page as well as information about how the data is encoded.
A very simple client-server interaction in HTTP includes 4 steps:
First, the client opens a Transmission Control Protocol (TCP) connection.
Next, the client sends an HTTP request, such as “GET /index.html”.
Then, the server sends an HTTP response, including a status and the requested object.
Finally, the TCP connection is ended.
This is a simplified example; actual HTTP transactions are more complex.
There are multiple versions of HTTP, though almost all clients and server support version 1.1. The earliest
version in common use was 0.9. Version 1.0 added improvements, but almost all clients and servers support
version 1.1 today. Version 1.1 improved performance for clients and defined interactions with proxies and
caches more completely.
HTTP messages are either requests (from clients) or responses (from servers.)
Initially, each request-response pair used a separate TCP connection. Clients opened a connection, sent a
request, server’s sent a response, and the server ended the connection.
In the example, the client opens the first connection and sends the first request. Then the server sends it’s
response and then ends the connection.
If another object was needed, the client would open another connection and send another response.
Page 86 of 91
This was a simple protocol; for each object transfer, another TCP connection was opened, used to transfer the
object, then closed. But as web pages became more sophisticated and clients needed to request more and more
objects, the overhead of opening and closing TCP connections impacted performance. These type of issues lead
to innovation. In this case, it led to Keep-Alives.
“Keep-Alives” were an early update to HTTP. With keep-alives, the client can re-use existing TCP connections to
request additional objects. With keep-alives, the server must indicate the amount of data it will send in response
to each client request. After sending that data, the client can send another request across the existing TCP
connection. Once the client has all the objects it needs, the client can close the connection.
Once again, the client opens the TCP connection and sends a request. However, once the first response is
received, the client is free to send another request. Once the client’s last request is fulfilled, the client will end the
TCP connection.
In HTTP version 1.0, Keep-Alives were supported but were disabled by default. In version 1.1, Keep-Alives are
enabled by default. Version 1.1 also added support for “Pipelining.” With pipelining, clients can send multiple
requests across the TCP connection before the first response has been received. Pipelining is not supported
widely.
HTTP clients use Universal Resource Locators (URL) to interact with resources. The format of a URL is
dependent upon the scheme, but for HTTP, the URL is composed of the scheme, the host, the port, the path, and
the query.
When the URL is used by browsers, HTTP messages do not contain the complete URL. The scheme is implied
by the fact that it is an HTTP message. In HTTP 1.0, the host was not always included in HTTP messages, but in
HTTP 1.1, it is included in the HOST header. The port is used by TCP, not HTTP and is assumed to be 80 if it is
not included. Finally, the path and query together are contained in the request start line.
A browser’s address window would display a complete formatted string.
In the example, the scheme is “http“, the host “www.f5.com”, the port “80”, the path “/path/time.jsp”, and the
query “h=13&m=48”.
Some portions of the URL are case sensitive and others are not.
In the scheme and hostname of the URL, case does not matter.
However, in the path and query, case can be significant depending on the implementation on the server.
HTTP is only one layer of the communication between browsers and web servers.
While not required, almost all implementations use Ethernet and TCP/IP.
Within the TCP data, HTTP messages include three parts: the initial line of the message, HTTP headers, and
HTTP data. The HTTP data can contain many object types. Common examples include HTML, the Hypertext
Markup Language and image files.
Each HTTP message is either a request or a response. For both, the first line has a distinct format. It may also
contain headers, which are used to refine the request or explain the response more fully. When data is passed in
the message, it will follow a blank line after the headers. The data can contain multiple lines, including blank
lines.
The first line of a request is made up of three space-separated parts: the Method, the Universal Resource
Indicator or “URI”, and the Version.
All methods MUST be in all upper case and define the action desired by the client. In most cases, the URI is
composed of the path and an optional query. If no query or explicit path is included, the URI will typically be a
single slash. Finally, the HTTP version is indicated.
Some older browsers may not include the HTTP version and some servers may refuse to respond to a request
that does not include the version.
Page 87 of 91
Next, requests usually include many HTTP headers that define such things as the preferred language, the
browser’s ability to decompress data, the browser’s version and the host name for the request. Version 1.1
requests MUST contain a host header, but no other headers are required.
HTTP headers follow the initial line. Headers are included, one per line, and each will appear in the format
Header-Name: Header Value. Header names do not contain spaces and are followed by a colon and a space.
Header values can be a single value or a space separated list of
values.
The examples show typical headers that are seen in requests.
The example request headers indicate the host of the content,
the compression types that the client supports, and the
language that the client prefers.
This example shows an actual HTTP request. It is a GET
request for the default page of the web server named
www.f5.com. This is a typical request and includes the initial
line, headers, but no data. In the example, two of the headers,
Accept and User-Agent, are longer than one line.
We have looked at the overall process, now let us look at some specifics – starting with HTTP methods.
RFC 2616, defining HTTP 1.1 describes eight methods. However, only a few are used frequently and the RFC
only defines 2 as “safe” – GET and HEAD. Briefly, here is what features the methods provide.
GET is used to retrieve a resource from a server.
When HEAD is used, the headers in the request and response will be the same as when a GET is used, but the
server will not return any data. This allows a client to check for the existence or size of a resource without
actually retrieving it.
POST is used to pass information to the server. POST allows clients to send messages to forums or update
databases.
The OPTIONS method is used to determine communications options that are available between the client and
the server.
The PUT method tells the server to replace the Requested URI with the data contained in this message. If the
resource does not exist, the server will create it.
The DELETE method deletes the resource specified by the Request-URI.
The TRACE method is used to send test messages to servers. If successful, the server should respond with a
200 OK.
The CONNECT method is reserved for use with proxies.
HTTP headers are grouped into four categories: General, Request, Response and Entity. This course will show
examples of HTTP headers typically seen in HTTP requests - general and request headers. The HTTP Basics II
course will show examples of HTTP headers typically used in HTTP responses.
General headers have to do with the message and the method of communication rather than the data that is
being transferred.
In the example request, we see two general headers: Connection: Keep-Alive and Pragma: no-cache. The
connection header indicates the client would like to send multiple HTTP requests across the existing TCP
connection. The pragma header indicates the client would like to get the data from the origin server rather than a
cache or proxy.
Request Headers apply either to the request or to the client. For example, they can
indicate the type of data that the client would like to receive. In the example request,
there are multiple “accept” headers that tell the server about the format of data the
client would like to receive. First, the Accept header indicates what file types the client
can manage. The Accept-Language header shows that the client prefers US formatted
English. The Accept-Encoding header shows what type of compression the client
understands. Finally, Host is the hostname portion of the URL.
Page 88 of 91
We hope that this has given you a good introduction to HTTP. While it may seem a simple process – open a
connection, send a request, process a response – there are many options within those few steps that can greatly
improve the user experience, but will certainly add in the protocols complexity. We hope this course has given
you a foundation to work from in understanding all that is HTTP.
HTTP Basics II Web Based Training Course
In this presentation, we will continue the discussion begun in HTTP Basics I. That presentation focuses on the
general format of HTTP messages and specific information about HTTP requests and typical headers in those
requests. This presentation focuses on HTTP responses and two examples where various HTTP headers are key
to managing HTTP communication.
As a reminder, both HTTP requests and responses are made up of an initial line, headers, and optional data.
The first line of a response is made up of three space-separated parts: the Version, the Status, and a Reason
Phrase. The version format is the same as in the request. Status codes are used to describe the results of the
request. The Reason-Phrase is a brief explanation of the status code.
Next, responses usually include many HTTP headers describing things such as the content length, content type,
content compression method, caching directives, and server information.
Finally, if the response includes the object, the body of the content will be included after a blank line.
Request and response headers have the same format. One header per line including the header name and its
value.
The examples show typical headers that are seen in responses. In this case, the response headers indicate the
date and time of the response, the length of the object, and the type of object that is being sent to the client.
HTTP messages, especially responses, often contain data. If an HTTP message contains any data, it will be
after the first blank line of the messages, this is usually after the headers. The Content-Type header is typically
used to define the format of the data. The data can contain blank lines. Here we see a small sample of HTML,
which could be the data of an HTTP message, and how it is processed by Internet Explorer.
This shows an HTTP response. The initial line indicates the object was available and is being transmitted. The
headers show information about the server and the type of data stored by the object. After the headers, a blank
line is seen and then the data begins. Most of the data is not shown.
Page 89 of 91
The initial line of all responses includes a server status code. These are three-digit codes grouped into five
categories.
The 100 series codes are informational only and do not indicate either success or failure. There are only two 100
series codes:
100 - Continue will be returned if a client is sending a multi-part request and the server is ready for the next
piece.
101 – Switching Protocols will be returned if the server has accepted the client’s request to change protocols.
The 200 series codes indicate success.
Code 200 means OK, the request succeeded. Code 206 indicates Partial Content, which means the request is
succeeding but this response does not contain all the data and more is coming.
There are seven different 200 series codes defined in HTTP 1.1.
300 series codes indicate that the resource is available, but it is somewhere else. There are eight different 300
series codes defined in HTTP 1.1. For example, 301 – Moved Permanently tells the client the resource should
always be retrieved from the location specified in the response. Other 300 series codes indicate that the
redirection is temporary.
400 series codes indicate the server thinks the client has made an error. For example, 400 Bad Request
indicates the client’s message is formatted incorrectly. 404 – File Not Found is seen frequently and indicates that
the server does not have the requested object. There are 18 status codes in the 400 range.
Finally, 500 series codes deal with errors on the server. For example, 500 Internal Server Error is a generic error
message and 505 HTTP Version Unsupported indicates the client’s requested HTTP version is not supported by
the server. There are six status codes in the 500 range.
HTTP headers are grouped into four categories: General, Request, Response and Entity.
will describe the purpose and show typical examples of each.
The following slides
General headers have to do with the message and the method of communication rather than the data that is
being transferred.
In the example response, we see two general headers: Date: and Transfer-Encoding: chunked. The date
indicates the date and universal time when the message was sent and Transfer-Encoding tells the client about
the format of the data.
Response headers typically contain information about the server, the format of the message, and the object itself.
For example, caches may include an Age header indicating how long the object has been in the cache.
In the example response, the Accept-Ranges header indicates the server could send the object in byte ranges
rather than the entire object. The Vary header indicates that while the content is cacheable, the object could vary
if the requesting client’s Accept-Encoding or User-Agent fields were different. Other potential response codes
include Etag, a digital fingerprint of the object so the client can determine whether the object has changed, and
Location, used to specify the new resource in redirect messages.
Finally, Entity headers describe the content itself. For example, the Content-Length field is used to tell the client
the length of the object. In the example response, the Content-Type header indicates the object is a text file
containing HTML. The Content-Encoding header indicates the object is compressed using gzip.
Page 90 of 91
Now that we have discussed many individual components of the HTTP protocol, we are going to briefly look at
some HTTP transactions and see how the headers indicate what is happening and why. The HTTP protocol
uses it’s methods, response codes and various headers to manage both caching and the ways used to tell clients
that entire objects have been received.
The first time an object is requested, the origin server will typically send a response with a 200 status code and
the data. The next time the object is requested, it could be served by the origin server or it could be served from
a cache. When the content has not changed, serving from cache decreases the load on the server and the
response time to the client. However, if the content has changed, serving from cache will result in the client
viewing out of date, or stale, content. The HTTP protocol is designed to help manage this process and supports
caching on clients and intermediary devices such as proxies and dedicated caches.
Caching is performed through two models: the “Expiration” model and the “Validation” model. Which model is
used by the given request-response pair varies based on the information the server provides about an object and
the information the client has about an object.
The expiration model hopes to reduce the overall number of HTTP requests that reach the server by eliminating
requests for resources that are already in the cache. This can be done if the server returns content marked in
such a way that the caching device has confidence that the original object is still valid. For example, the server
may return an object with a Cache-Control: max-age header set to 3600. The client knows that that object is
valid for 3600 seconds or one hour. If the object is needed again before the hour ends, the object will be served
from cache. Alternately, the server may return an object with an Expires: header set to an explicit date. In this
case, the client knows the object can be served until that date arrives.
Interaction with intermediary caches can vary from these examples.
Often, the server’s first response does not include an explicit period that the object is good. In those cases, it
may include headers that allow the client to verify that the object hasn’t changed before serving it from cache. In
this case, the client still needs to send a request and the server still needs to respond, but often the object itself
does not have to be present. If the server includes an Etag header in its initial response, the client can send
requests with a If-None-Match header, set to the Etag value. When the server sees that the client already has
the object, it can respond with a 304 Not-Modified status code and not send any data in the response. Similarly,
if the original response includes a Last-Modified header, the client’s subsequent request can include a IfModified-Since header with the same date. Again, when the server sees the client has the correct version of the
object, it can respond with a 304 and the client can present the object from its cache.
HTTP uses multiple techniques to let client’s know when an entire object has been received. Prior to HTTP 1.0,
each request used a separate connection, so it was simple for the server to indicate the transfer was complete: it
closed the TCP connection. However, Keep-Alives support meant the client needed other ways to know when
the transfer was finished. The most common method used today involves the Content-Length header. When the
server’s response includes this header, the value of the header is the length of the object in bytes. Once that
number of bytes have been received, the client knows the entire object has been transmitted.
Another alternative is for the server to not support Keep-Alives and revert to sending one object per connection.
In HTTP 1.1, Keep-Alives are enabled by default, so the server must explictly tell the client that it will not support
Keep-Alives. This is accomplished with a Connection: Close header.
A third method involves chunking. At times, the server must dynamically generate the content that will become
the response. And rather than caching all the components on the server, it may wish to begin sending parts of
the response as they are generated. When servers choose this option, they will send the data in chunks and
indicate this with a Tranfer-Encoding: chunked header. When the client sees this, it knows to expect a series of
length-field – data-field pairs and eventually receive a length field of zero, indicating the server has completed the
transfer.
We hope that this has given you a good introduction to HTTP. While it may seem a simple process – open a
connection, send a request, process a response – there are many options within those few steps that can greatly
improve the user experience, but will certainly add in the protocols complexity. We hope this course has given
you a foundation to work from in understanding all that is HTTP.
Page 91 of 91