201 tmos administration master cheat sheet

of 111

SKILLCERTPRO

201 TMOS ADMINISTRATION MASTER CHEAT SHEET

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 self-contained, 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,

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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



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:

of 111

SKILLCERTPRO

TM.ContinueMatching = true Virtual Server: 10.10.1.10:80 Status: Disabled Virtual Server: 10.10.1.10:* Status: Up and Available

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 # tcpdump -w dump1.bin Text file # tcpdump > dump1.txt

Reading tcpdump binary file output # tcpdump -r dump1.bin

Filters Filtering on a host address # tcpdump host 10.90.100.1 To view all packets that are traveling to or from a specific IP address # tcpdump src host 10.90.100.1 To view all packets that are traveling from a specific IP address # tcpdump dst host 10.90.100.1 To view all packets that are traveling to a particular IP address

Filtering on a port # tcpdump port 80 To view all packets that are traveling through the BIG-IP, sourced from or destined to # tcpdump src port 80 To view all packets that are traveling through the BIG-IP and sourced from a specific port # tcpdump dst port 80 To view all packets that are traveling through the BIG-IP and destined to a specific port

Filtering on a tcp flag

of 111

SKILLCERTPRO

# 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

of 111

SKILLCERTPRO

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 -ni internal -w dump1.bin #tcpdump -ni internal -r dump1.bin host 10.90.100.1 #tcpdump -ni 2.1 host 10.90.100.1 and port 80 #tcpdump -ni 1.10 src host 172.16.101.20 and dst port 80 >dump1.txt #tcpdump -Xs200 -nni eth0 -w /var/tmp/mgmt.cap dst host 172.16.101.20 and dst port 162

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

o For systems containing a PVA ASIC, the tcpdump utility does not capture virtual server traffic that is fully accelerated by the PVA chip.

o Running tcpdump on a switch interface is rate-limited to 200 packets per second.

of 111

SKILLCERTPRO

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

o 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

of 111

SKILLCERTPRO

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:

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

Performance HTTP virtual server with no idle server-side flow

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.

of 111

SKILLCERTPRO

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:

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

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

Idle timeout

Table, Idle timeout settings that affect connection reaping

Configuration Object Type Default in Seconds

User-configured?

Fast L4, Fast HTTP, TCP, and SCTP profiles

300 Yes

UDP profiles 60 Yes

SNAT automap 300 No

VLAN group 300 No

Table, Idle timeout settings that do not affect connection reaping

Configuration Object Type Default in Seconds

User-configured?

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 * 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 {

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 Keep-Alive 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. 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 SSL-enabled 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.

of 111

SKILLCERTPRO

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

b) IM installation package. On supported systems, you can copy the IM package to the system and update the EUD.

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), BIG-IP 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 System Report 2 Sensor Report

of 111

SKILLCERTPRO

3 SFP/XFP Report 4 LED Test 5 SCCP I2C Test 6 PCI Test 7 Quick System RAM test 8 System RAM Test 9 LCD Test 10 Internal Packet Path Test 11 Internal Loopback Test 12 PVA Memory Test 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 This option provides a comprehensive test of all system hardware components 2 Sensor Report This test checks the switchboard CMOS Programmable Logic Device (CPLD) on the motherboard. 3 SFP/XFP Report This test checks the SFPs and XFPs installed on the system. 4 LED Test This test sets each of the possible status LED colors one at a time (Interactive) 5 SCCP I2C Test This option verifies any Inter Chip Communication Bus (I2C) devices in the system. 6 PCI Test 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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 { source(local); filter(f_local0_customlog); destination(d_customlog); }; "'

save the configuration change:

tmsh save / sys config and restarting the syslog-ng service:

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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)

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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.

Server Type Monitor plug-in Monitor Type

RealServer Windowsserver RealServer UNIX server

F5RealMon.dll f5realmon.so

Real Server Real Server

Windows server with WMI f5isapi.dll or F5Isapi64.dll or F5.IsHandler.dll

WMI

Windows 2000 Server server UNIX server

SNMP agent UC Davis SNMP agent

SNMP DCA and SNMP DCA Base SNMP DCA and SNMP DCA Base

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.

of 111

SKILLCERTPRO

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 In

o Bytes Out o Backlogs

o Bytes Dropped

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

of 111

SKILLCERTPRO

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.

Network access configuration elements A network access configuration requires:

A network access resource

of 111

SKILLCERTPRO

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.

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 self-allow 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 } }

of 111

SKILLCERTPRO

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 # tmsh save /sys config

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

of 111

SKILLCERTPRO

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 VLANs: Always Accept, None

of 111

SKILLCERTPRO

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 )"

of 111

SKILLCERTPRO

} [root@asm:Active:Standalone] config #

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.

of 111

SKILLCERTPRO

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)

of 111

SKILLCERTPRO

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]

of 111

SKILLCERTPRO

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 Lists the IP addresses of the RADUIS servers that the BIG-IP system will use to obtain authentication data. Client ID 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.

of 111

SKILLCERTPRO

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 settingsMode 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 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 role-based

of 111

SKILLCERTPRO

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 DN Specifies 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]

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 third-party 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?

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

Idle Timeout [Specify… 300 seconds | Indefinite]

Cookie Name Specifies a unique name for the cookie that you want to associate with this profile. f5auth

Cookie Key Specifies an encryption key, in the form of a strong password, for encrypting cookie data 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. The BIG-IP system includes a tool for propagating BIG-IP system configuration data to multiple BIG-IP devices on the network. This tool is known as the Single Configuration File (SCF) feature.

of 111

SKILLCERTPRO

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. On the Main tab, click System > Users. 2. On the menu bar, click Authentication. 3. Click Change. 4. From the User Directory list, select Remote - LDAP or Remote - Active Directory. 5. In the Host field, type the IP address of the remote server. 6. For the Port setting, retain the default port number (389) or type a new port number. 7. 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]).

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

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

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

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

12. From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-

IP user accounts can access.

13. From the Terminal Access list, select one of the following as the default terminal access for remotely-

authenticated user accounts: Disabled, tmsh, Advanced shell

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

of 111

SKILLCERTPRO

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

2. On the Main tab, click System > Users. 3. On the menu bar, click Authentication. 4. Click Change. 5. From the User Directory list, select Remote - ClientCert LDAP. 6. In the Host field, type the IP address of the remote server. 7. 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. 8. 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]). 9. 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. 10. 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.

11. 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. 12. 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. />

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

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

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

16. For the Depth setting, retain the default value (10) or type a new value for verification depth. 17. 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. 18. From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-IP

system user accounts can access. 19. From the Terminal Access list, select either of these as the default terminal access option for remotely-

authenticated user accounts: Disabled, tmsh 20. Click Finished.

Specifying RADIUS server information Prerrequisites:

Verify that the BIG-IP system user accounts have been created on the remote authentication server.

of 111

SKILLCERTPRO

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. On the Main tab, click System > Users. 2. On the menu bar, click Authentication. 3. Click Change. 4. From the User Directory list, select Remote - RADIUS. 5. 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. 6. 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.

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

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

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 remotely-authenticated 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. On the Main tab, click System > Users. 2. On the menu bar, click Authentication. 3. Click Change. 4. From the User Directory list, select Remote - TACACS+. 5. 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. 6. Click Add. The IP address for the remote TACACS+ server appears in the Servers list. 7. In the Secret field, type the password for access to the TACACS+ server. 8. In the Confirm Secret field, re-type the TACACS+ secret. 9. From the Encryption list, select an encryption option: Enabled, or Disabled. 10. 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.

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

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

of 111

SKILLCERTPRO

13. From the Partition Access list, select the default administrative partition that all remotely-authenticated BIG-IP user accounts can access.

14. From the Terminal Access list, select one of the following options as the default terminal access for remotely-authenticated user accounts: Disabled, tmsh, Advanced shell.

15. 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. On the Main tab, click System > Users. 2. On the menu bar, click Remote Role Groups. 3. Click Create. 4. 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.

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. On the BIG-IP system, access a command-line prompt. 2. At the prompt, open the Traffic Management Shell by typing the command tmsh. 3. 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. On the BIG-IP system on which you created the SCF, access a command-line prompt.

of 111

SKILLCERTPRO

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

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

4. On the BIG-IP system that you want to configure, open the Traffic Management Shell by typing the command tmsh.

5. 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 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 BIG-IP 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

of 111

SKILLCERTPRO

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:

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.

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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 Central Is 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

of 111

SKILLCERTPRO

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 90-day 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 support, or Premium hours, which includes 7 x 24 support. Expedited RMA Services and Maintenance Add-On 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

of 111

SKILLCERTPRO

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

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

of 111

SKILLCERTPRO

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 Do This Local BIG-IP syslog (System > Select Syslog. The alerts are logged in the /var/log/ltm file. Logs > Local Traffic) Remote syslog server Select Syslog. You must configure the remote syslog server on the BIG-IP system. SNMP traps sent to an external Select SNMP. If you need to configure SNMP, wait until after you SNMP receiver 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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 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 BIG-IP system, you must perform one of the following actions:

Restore the UCS archive to the same system from which it was saved. Have the license associated with the serial number of a new system. To do so, contact F5 Technical

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

Relicense the BIG-IP system after restoring the UCS archive. Save the license file prior to restoring the configuration from another system, and then copy the

license file back. Install the UCS archive by using the tmsh no-license option.

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.

of 111

SKILLCERTPRO

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 no-private-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 -rw-r--r-- 1 root root 3089464 Sep 9 11:47 /var/tmp/MiRespaldoSinSSLkeys.ucs -rw-r--r-- 1 root root 3092349 Sep 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.

of 111

SKILLCERTPRO

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] config # tmsh load /sys ucs /var/tmp/MiRespaldoSeguro.ucs no-license 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. 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

of 111

SKILLCERTPRO

# 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 license, run loaddb -local /config/BigDB.dat.cs

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>

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:

of 111

SKILLCERTPRO

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. Log in to the command line. 2. 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 3. Remount the /usr filesystem in read-write mode by typing the following command:

# mount -o remount,rw /usr 4. Edit the /usr/local/bin/install_ucs.pm file using a text editor of your choice. 5. 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. Save the modifications and exit the text editor. 8. 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 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.

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

5. Install the master key that you copied in Step 3 to the RMA BIG-IP system by entering the following command: # f5mku -r <key_value> For example: # f5mku -r oruIVCHfmVBnwGaSR/+MAA==

6. Restore the UCS file to the RMA BIG-IP system by entering the following command: # tmsh load sys ucs <filename>.ucs

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

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

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

of 111

SKILLCERTPRO

To activate the license for the system, you must have a base registration key. The base registration key is a 27-character 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. 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

of 111

SKILLCERTPRO

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.

of 111

SKILLCERTPRO

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 Communication between managed devices and the EM system Device management 4353 Communication between EM and a managed device's big3d agent Collecting statistics 3306 Communication between EM and a remote statistics database 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 Activate, The End User License Agreement (EULA) displays, Accept Specifying initial configuration settings Configuring a basic network

of 111

SKILLCERTPRO

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.

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.

of 111

SKILLCERTPRO

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 • 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:

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 <[email protected]>:/<full_file_path_for_backup_file>

The default file name is f5em_extern-<date stamp> # em-restore-extern <[email protected]>:/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 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:

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

• Verifying, staging, and deploying the security policy • Managing ASM attack signatures for Application Security Manager 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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 A minimum of one floating traffic group is currently active on the device.

This status applies to Sync-Failover device groups only. Forced offline An administrator has intentionally made the device unavailable for processing traffic. Offline The device is unavailable for processing traffic. Standby 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. Unknown The status of the device is unknown.

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.

of 111

SKILLCERTPRO

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 attribute. Note that in this configuration, Bigip1 and Bigip2 are members of both the Sync-Only and the Sync-Failover groups.

of 111

SKILLCERTPRO

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. The types of configuration objects that you can associate with a floating traffic group are:

• iApps application services • Virtual IP addresses

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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 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-group-1 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

of 111

SKILLCERTPRO

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

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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

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

type

Description of virtual server 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)

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

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. The following slides will describe the purpose and show typical examples of each. 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.

of 111

SKILLCERTPRO

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

of 111

SKILLCERTPRO

if the original response includes a Last-Modified header, the client’s subsequent request can include a If-Modified-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.

201 tmos administration master cheat sheet

Documents