Introduction

Welcome to the TMOS Operations Guide. 1. What does this guide cover? 2. Who is this guide for? 3. What is not covered? a. Links to related information covered elsewhere

Section 1: Periodic Maintenance

Recommended practices for maintenance of your TMOS system are dependent on your industry and any existing industry standards or business rules you currently follow. F5 practices are meant to be a supplement to your established practices. The following table groups some common recommended practices by frequency. Table #: Recommended Maintenance Tasks Type DAILY Logs Description Check available log files for messages pertaining to system stability and health. Check for software updates. Run a short SMART check. See <link to heading in document> Notes Any caveats or exceptions

WEEKLY Software. Hard Disk Drives

<link to heading in document> <link to heading in document> <link to heading in document> <link to heading in document>

Any caveats or exceptions Any caveats or exceptions Any caveats or exceptions Any caveats or exceptions

TWICE MONTHLY Task type/area Describe task MONTHLY iHealth

MySQL database

Upload a qkview file from TMOS to iHealth and review recommended maintenance and alerts. Perform a backup and

<link to heading in

The Check, Optimize,

Type

Description general table checks

See document>

Hard Disk Drives

Run an extended SMART check. EVERY THREE MONTHS iHealth Review trends in your uploaded iHealth data.

<link to heading in document> <link to heading in document>

Notes and Analyze commands create locks, so use caution on your production server. Any caveats or exceptions Uploaded qkview data is deleted after three months, so this is the minimum trend review window. However, if you choose to back up the data, you may want to review longer trends. Any caveats or exceptions Any caveats or exceptions

TWICE YEARLY Task type/area YEARLY Failover test

Describe task

<link to heading in document> <link to heading in document>

Test your failover system as part of a regular disaster recovery plan. Make note of your license expiration and make sure you save the sysconfig beforehand.

AD-HOC Licensing

<link to heading in document>

This is from ID 364467 BIG-IP LTM, but does it apply also to TMOS?

Chapter 1: MySQL
1. Intro--what modules use the MySQL database? The MySQL database is a component of the BIG-IP Application Security Manager (BIG-IP ASM) module <any other modules or components? Yes, per client4 or 5>. 2. Cover routine maintenance tasks a System Administrator would expect to perform 3. Does the DB require cleaning? <Per a client, nobut does this depend on industry?>

4. Does the DB require optimization?

Determining the MySQL database password

To maintain the MySQL database, youll need access with the current password. The MySQL administrative password is randomly chosen during the installation process. To view the current MySQL administrative password, type the following command:
perl -MF5::GenUtils -e "print get_mysql_password.qq{\n}"

Resetting the MySQL database password

To reset the current MySQL password, use the following command syntax, replacing <newpassword> with the password of your choice:
/usr/share/mysql/mysqlpw -p <newpassword>

Maintaining your MySQL database

The MySQL database is a component of the following modules: BIG-IP Application Security Manager (BIG-IP ASM) BIG-IP If your system runs any of these modules, youll want to consider maintaining the MySQL database related to those modules by: Backing up the database Identifying integrity errors Reclaiming unused space Optimizing your indexes Backing up your database Before running suggested maintenance tasks, youll want to back up your database with mysqldump. If your database is large or if you already use replication and an existing backup system, then defer to your internal operating guidelines to back up your database. To back up your database: Run the following:
$ mysqldump -u root -p --create-options --routines --triggers dbname > ./db.dmp # copy to another server $ scp ./db.dmp user@somehost:~/

Note: If you have stored procedures or functions use the argument routines. If you use triggers, employ the triggers argument. Once you have a backup, its best if you then test restoring it on another system to make sure its valid.

Identifying integrity errors Identify integrity errors using the Check command. You can use the Check Table syntax with InnoDB, MyISAM, and ARCHIVE tables, and with CSV tables using MySQL 5.1.9 and later. To check a single table: Run the following command:
mysql> CHECK TABLE {table name};

To check all tables in a database:

From the command line, run the following: $ mysqlcheck -u root -p --check --databases dbname

Reclaiming unused space Reclaim any unused space by running an Optimize command (for MyISAM and InnoDB tables). When using this command with InnoDB, the process runs an ALTER TABLE statement that tells MySQL to rebuild the table and indexes but changes nothing. To optimize a single table: Run the command:
mysql> OPTIMIZE TABLE {table name};

To optimize all tables in a database: From the command line, run the following command:
$ mysqlcheck -u root -p --optimize --databases dbname

Note: For InnoDB tables, it is normal to receive the message, Table does not support optimize, doing recreate + analyze instead. Optimizing your indexes You can use the Analyze command to optimize indexes in MySQL. It does this by rebuilding the key distribution. It can be helpful to run this whenever your queries are slow but your indexes are in place. The Analyze command is good for tables other than InnoDB tables,which are already analyzed with the Optimize command (for more information, see Reclaiming unused space). To analyze a single table: Run the following command:
mysql> ANALYZE TABLE {table name};

To analyze all tables in a database: From the command line, run the following:
$ mysqlcheck -u root -p --optimize --databases dbname

Chapter 2: Drive Maintenance

1. Root file system fill up

a. You should put scratch files in the shared partition b. When should you use remote logging?

Checking the var Directory

<This section is for GTM and Link Controller v9.2.3does it have general applications for TMOS at all? If yes, it needs reworking to apply generally.>Configuration utility can cease to function if the /var directory fills up (CR57265) In instances where an extremely large amount of debugging information is generated, the /var directory can grow too large for the system to handle. See Workarounds for known issues for assistance with this issue. In environments where debugging is inactive, this issue does not occur. Resolving issues with the /var directory (CR57265) You can work around this issue by deleting the log files within the /var directory. To delete these log files, use the following steps: 1. From the command line, type du -h /var. 2. Identify the largest log file in the directory. 3. Delete the log file. 4. From the command line, type bigstart restart syslog. 5. Optionally, remove the file SESSIONS.ser from the /var/cache/tomcat4/work/StandAlone/localhost/tmui, if it exists. 6. From the command line, type bigstart restart tomcat4. Note that log files are swept every 30 minutes. For this issue to occur, the log files would have to fill up the available space on the system in less than 30 minutes.

2. Fsck (file system check utility) not required on our boxes 3. Disk Space cleaning a. Is this required b. Is log rotation enough? 1. How to adjust log rotate periods

Monitoring the hard disk capacity on a BIG-IP unit is critical to maintaining its health. If a BIGIP system is running low on disk space, you may experience performance-related issues, such as the inability to perform upgrades, run ConfigSync operations, or save UCS files. F5 recommends periodically checking disk space use and using industry recommended practices for keeping disk use to a minimum. Overview of the LVM disk-formatting scheme
The BIG-IP 11.x system utilizes the logical volume management (LVM) disk-formatting scheme. LVM is an enhanced software image manager used for deploying logical rather than physical storage. With the LVM disk-formatting scheme, logical volumes may span across one or more physical hard drives, and can be resized without interrupting service. The BIG-IP LVM volume sets are formatted such that every product module includes a description of the filesystems it needs, including a mount point and size for each volume. During installation, the BIG-IP system automatically allocates an appropriate amount of disk space when creating a volume set. For example, on a BIG-IP 2000 series platform provisioned for LTM and ASM, the system allocates disk space for each volume set that may appear similar to the following example:
# lvs -v LV VG #Seg Attr LSize Maj Min KMaj KMin set.1._config vg-db-sda 1 -wi-ao 3.00G -1 -1 253 14 set.1._usr vg-db-sda 1 -wi-ao 2.00G -1 -1 253 13 set.1._var vg-db-sda 1 -wi-ao 3.00G -1 -1 253 15 set.1.root vg-db-sda 1 -wi-ao 296.00M -1 -1 253 12 app.ASWADB.set.1.mysqldb vg-db-sda 1 -wi-ao 12.00G -1 -1 253 16

In addition, the system allocates a certain amount of disk space for the shared volume, and the log volume. For example, a BIG-IP 2000 series platform allocates disk space for the shared and log volumes that appears similar to the following example:
LV VG #Seg Attr LSize Maj Min KMaj KMinz dat.share.1 vg-db-sda 1 -wi-ao 30.00G -1 -1 253 1 dat.log.1 vg-db-sda 1 -wi-ao 7.00G -1 -1 253 2

Symptoms of a full/near full disk

When the BIG-IP file systems become full, undesirable or unpredictable behavior may result. Symptoms may include the following: The diskmonitor utility generates warning messages and/or traps. The diskmonitor utility is a script that runs periodically on the BIG-IP system and alerts you if the partition space or volumes reach a

defined threshold. If one or more of these thresholds are reached, a log message is logged to the /var/log/ltm file. For example, the following message indicates that the /shared partition has less than 30 percent free space available:
diskmonitor: 011d005: Disk partition shared has less than 30% free

The following message indicates that the /shared partition has 0 percent free space available:
diskmonitor: 011d004: Disk partition shared has only 0% free

In addition, the BIG-IP system sends the following SNMP trap alerts when the partition space reaches a defined threshold:
alert BIGIP_DMON_ERR_DMON_ALERT { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.25" } alert BIGIP_DMON_ERR_DMON_WARN { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.25" } alert BIGIP_DMON_ERR_DMON_GROWTH { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.26"

Upgrades or hotfix installations may fail to proceed. Daemon log messages may appear similar to the following examples:
Couldn't write to <file> / <partition> Failed to open file

The system performance may degrade, such as slow or failed disk writes.

Preventing disk utilization issues

To help prevent disk utilization issues, F5 recommends using the following guidelines to maintain adequate disk space on the system: Store maintenance-related files in the /shared/tmp directory. Maintenance-related files are those files that an administrator may create while performing maintenance or troubleshooting-related tasks on the system. For example, tcpdump files, UCS archives, or tech.out files should be stored in the /shared/tmp directory. Using the /shared/tmp directory for maintenance-related files is recommended for the following reasons: o o The BIG-IP installer allocates a large amount of disk space to the /shared partition. The /shared/tmp/ directory is shared between all installed images on a system. For example, if you save a tcpdump file to the /shared/tmp directory, each installation image or volume set has access to the tcpdump file. Store long-term maintenance files on a network share. If you create files that are suitable for longerterm storage such as UCS archives or SCF files, F5 recommends moving them to a network share. When creating or generating a file on the BIG-IP system, provide the full path location so that the file is saved to the intended location and not the current working directory. For example, the following tcpdump command saves the capture file to the /shared/tmp directory:
tcpdump -ni 1.1 -w /shared/tmp/example-tcpdump.pcap

The following qkview commands save the corresponding support file to the /shared/tmp directory:
qkview -f /shared/tmp/example-qkview.tar.gz

The following tmsh command saves the corresponding UCS file to the /shared/tmp directory:
tmsh save /sys ucs no-private-key /shared/tmp/example-config.ucs

Note: By default, UCS files are saved in their image-specific partitions, which are not visible to all installed images. If you plan to create an archive that will be used for production (using either the Configuration utility or command line), no path name is needed and the UCS archive will be saved to the default location of /var/local/ucs/. Avoid storing files in directories that reside on the root filesystem. The BIG-IP system has a relatively small root filesystem, and separate partitions for filesystems, such as /config, /usr/, and /shared. Directories, such as /home reside on the root filesystem and should not be used for file storage. Store image files in /shared/images/. If you upload installation images to the BIG-IP system using the command line, you should store them in the /shared/images directory. Periodically check the available disk space on the BIG-IP system. To check available disk space, you can use the command df -h. For example, the following df -h output indicates that the root filesystem is at 100 percent usage:
df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--sda-set.2.root 287M 287M 0 100% / /dev/mapper/vg--db--sda-set.2._config 3.0G 79M 2.8G 3% /config /dev/mapper/vg--db--sda-set.2._usr 2.0G 1.5G 408M 79% /usr /dev/mapper/vg--db--sda-set.2._var 3.0G 300M 2.6G 11% /var /dev/mapper/vg--db--sda-dat.share.1 30G 1.4G 27G 5% /shared /dev/mapper/vg--db--sda-dat.log.1 6.9G 129M 6.5G 2% /var/log none 4.0G 708K 4.0G 1% /dev/shm none 4.0G 13M 3.9G 1% /var/tmstat none 4.0G 1.4M 4.0G 1% /var/run prompt 4.0M 28K 4.0M 1% /var/prompt

Periodically check the inode usage on the BIG-IP system. Note: An inode is a data structure that is allocated to a file on a UNIX-based system. It is possible to run out of inodes before you run out of disk space if the system contains a large number of small files. To check inode usage, run the df -i command. For example, the following df -i output indicates the /var filesystem has no free inodes:

df -i Filesystem /dev/md7

Inodes 65536

IUsed 3384

IFree IUse% Mounted on 62152 6% /

/dev/md9 /dev/md8 /dev/md10 /dev/md0 /dev/md1 none none none prompt /dev/md15

393216 219520 393216 3932160 917504 1023877 1023877 1023877 1023877 1572864

307 28044 393216 200 159 39 27 182 4 188

392909 191476 0 3931960 917345 1023838 1023850 1023695 1023873 1572676

1% 13% 100% 1% 1% 1% 1% 1% 1% 1%

/config /usr /var /shared /var/log /dev/shm /var/tmstat /var/run /var/prompt /var/lib/mysql

If inode usage is at or near 100 percent, move any unnecessary maintenance-related files from the BIG-IP system to a network share and schedule a time to reboot the system. Periodically check for and remove non-critical maintenance files. Important: If you are unsure of the origin or operation of a specific file, contact F5 Technical Support before removing the file from the BIG-IP system. In many cases, non-critical maintenance files will be apparent and can be safely removed. For example, old tcpdump, qkviews, or core files should be deleted from the system or moved to a network share. You can use the find command to locate old maintenance-related files. For example, to locate the 20 largest files on the system, you would use the following command syntax:
find <dir> -xdev -type f | xargs du | sort -rn | head -20

For example, the below find command was used to locate the 20 largest files in the /shared partition, some of which can be safely removed, such as the 2-gigabyte tcpdump file, and the 18-megabyte core file: Note: The following output indicates that the /shared/images directory contains two ISO installation files. You can safely remove older installation files from the system. However, you should not remove installation images for versions that are currently running on the system.
find /shared/ -xdev -type f | xargs du | sort -rn | head -20 2189582 /shared/tcpdump.cap 1277060 /shared/images/BIGIP-11.3.0.2806.0.iso 1186512 /shared/images/BIGIP-11.2.1.797.0.iso 18460 /shared/core/mcpd.bld3341.0.core.gz 5200 /shared/rrd.1.2/endpisession 4984 /shared/rrd.1.2/blade0cpu 3796 /shared/bin/big3d 2460 /shared/rrd.1.2/connections 1308 /shared/rrd.1.2/throughput 1164 /shared/rrd.1.2/memory 1096 /shared/rrd.1.2/rollupcpu 876 /shared/rrd.1.2/gtm 732 /shared/rrd.1.2/ramcache 588 /shared/rrd.1.2/bwgain 224 /shared/tmp/packages/rt.pkc 156 /shared/rrd.1.2/bladeconnections 48 /shared/tmp/packages/tmui.pkc 20 /shared/tmp/packages/schema.pkc 16 /shared/tmp/packages/axis.pkc 12 /shared/tmp/packages/packages.idx 12 /shared/rrd.1.2/endpisession.info 12 /shared/rrd.1.2/blade0cpu.info

Monitoring disk use with the diskmonitor utility

The diskmonitor utility is a script that runs periodically on the BIG-IP system to monitor disk usage. The diskmonitor utility performs the following functions: Monitors BIG-IP disk usage limits and disk usage growth rates on selected partitions Sends warning and error logs to syslog when partitions are running out of space Dynamically adjusts the diskmonitor utility, which is executed when disk use is approaching critical levels Note: By default, 10 percent or less disk space in the /var/log partition is considered critical. When the /var/log partition is approaching critical levels, the diskmonitor utility sends a syslog message containing error 011d0004 for var_log. The alertd process monitors syslog for this error and runs logrotate to rotate and compress the logs. The following partitions are monitored, by default: Important: The nested directories and the root directory contain underscore ( _ ) characters. This formatting allows the Diskmonitor utility to reference the directories, as the forward slash ( / ) character is reserved for use in Perl for defining regular expressions. _root_ = / config = /config dev_shm = /dev/shm shared = /shared usr = /usr var = /var var_log = /var/log var_run = /var/run

Configuration variables for the diskmonitor utility The db variables allow customization of the diskmonitor utility on a per partition basis, as well as the option to disable the diskmonitor utility. For information about the db variables, refer to the following table: Variable Settings Description Example

Platform.DiskMonitor.State. <value>

Enable: Enables diskmonitor (default setting)

Enables or disables diskmonitor free disk space monitoring.

v11.x:

tmsh modify sys db platform.diskmonitor.state value enable

v9.x through v10.x:

bigpipe db Platform.DiskMonitor. State=enable

Disable: Disables diskmonitor Platform.DiskMonitor.Interval. <value> Specifies the interval at which diskmonitor will run and gather disk information.

1 - 1440 (minutes)

v11.x:

tmsh modify sys db platform.diskmonitor.interval value 10

The default setting is 30 minutes

v9.x through v10.x:

bigpipe db Platform.DiskMonitor. Interval=10

Changes diskmonitor interval to run every 10 minutes Platform.DiskMonitor.Monitor. <partition> <value> Specifies how diskmonitor should monitor the configured partition.

Limit: Checks the partition specified against the configured limits and sends a warning message if the disk space limit is reached.

v11.x:

tmsh modify sys db platform.diskmonitor.monitor.config value limit

v9.x though v10.x:

bigpipe db Platform.DiskMonitor. Monitor.config = limit

To display a list of DiskMonitors and their settings, use the following command:

Change: Monitors any changes and checks the changes

v11.x:

tmsh list sys db platform.diskmonitor.monitor.*

v9.x through v10.x:

against the limits specified.

bigpipe db show | grep Platform.DiskMonitor.Monitor

Growth: Monitors any changes in partition growth and sends a warning message if the amount of growth exceeds the allowed growth rate.

None: Does not monitor the partition specified for any changes, growth rate, or limits. Use with caution. Platform.DiskMonitor.FreeLast. <partition> No options for this variable Reports the N/A recorded percentage of free disk space available the last time diskmonitor was run. Specifies the If disk usage for /root/ grows amount of growth from 50 to 60 percent in the last half hour, a growth allowed (as a alert message is sent to syslog. percentage) since the last time diskmonitor was run, before the system sends a growth limit warning message to syslog. Specifies the percentage of free space remaining in the partition at which N/A

Platform.DiskMonitor.GrowthAlert. Integer value <partition> <value> between 0-100

Platform.DiskMonitor.LimitAlert. <partition> <value>

Integer value between 0-100

diskmonitor sends a disk space alert message to syslog. Platform.DiskMonitor.LimitWarn. <partition> <value> Integer value between 0-100 Specifies the percentage of free space remaining in the partition at which diskmonitor sends a disk space alert message to syslog. N/A

Platform.DiskMonitor.Time. <partition>

No options for this variable

Specifies the last N/A time diskmonitor detected a change in the percentage of the partition's free disk space.

Logging warning and error conditions

The diskmonitor utility reports error and warning conditions to the syslog-ng utility. For details about each error and warning condition, refer to the following table: Note: The local0.* messages are written to /var/log/ltm file. Error or Warning Condition
Syslog-ng <logfacility>.<severity level>: local0.error Syslog-ng <logfacility>.<severity level>: local0.warning Syslog-ng <logfacility>.<severity level>: local0.error Syslog-ng <logfacility>.<severity level>: local0.error Syslog-ng <logfacility>.<severity level>: local0.warning Syslog-ng <logfacility>.<severity level>: local0.warning 011d0006

Message Number
011d0002

Message Reported

Description

No diskmonitor entries in The bigpipe db utility cannot find any database Platform.DiskMonitor db keys. Cannot access the database because mcpd is not running Error parsing df-k output The mcpd process needs to be running for diskmonitor to get its db key configuration. The diskmonitor utility could not get the free space percentage from df-k. The monitored partition has only a critical amount of free space left. The diskmonitor utility sends a warning message because the monitored partition has less free space remaining than the warning level specifies. The diskmonitor utility detects that the usage in the monitored partition is growing quickly (the usage exceeded the growth percentage after its last monitored interval).

011d0002

011d0003

011d0004

Disk partition <partition> has only <percentage> free Disk partition <partition> has less than <percentage> free Disk partition <partition> exceeded growth limit <growth percentage>

011d0005

4. SMART check on each disk should be run how often ?

SMART Checking Hard Disk Drives

Self-Monitoring, Analysis, and Reporting Technology (or SMART) checks are one way you can track the pulse of your systems hard disk drives. Establishing regular monitoring of your drives can provide notice of imminent disk problems before they arise. A SMART test is run as part of the End User Diagnostics (EUD) process recommended on an annual basis. For more information, see Annual Diagnostics/EUD. SMART helps to detect indications the disk is likely to fail. However, a disk can fail a SMART test and still work well for weeks or months. <If users want to run a SMART test independent of the EUD process, how do they do that? The following is a possible examplenot sure if it applies to F5.> If your ATA drive supports self-tests, F5 suggests running them once a week:
smartctl -t long /dev/hd?

After the test has completed, you should examine the results with:
smartctl -l selftest /dev/hd?

Since the SMART daemon only checks values stored in the CPU of the hard disk, you can run it as frequently as you wish. The idea is to recognize problem as quickly as they happen. 5. Are there special checks required for solid state drives (SSDs)? a. Do SSDs need the TRIM command turned on? SSDs need the TRIM command turned on. This is usually set up by default. b. How do you check remaining write lifetime on SSDs?

About disk management

<This applies only to WOMcan we use the Monitoring SSD Usage section (see below) for general purposes or is datastor specifically WOM-related?>You can use disk management to allocate dedicated disk space for the datastor service, which increases the data storage that BIGIP WOM uses for deduplication. Additional disk space is available in the following deployments.

Selected higher-end BIG-IP WOM platforms support the use of solid-state drives (SSDs) that come in a dual-disk drive sled and are installed along with hard disk drives. If you are installing BIG-IP WOM Virtual Edition, you can select an extra disk deployment configuration.

The following figure shows the Disk Management screen in a BIG-IP WOM 11000 platform that has SSDs installed. In this example, datastor is still on the primary disk; it has not been allocated to the SSDs.

Example of the Disk Management screen Provisioning solid-state drives for datastor Before beginning this procedure, you must have licensed WAN Optimization Manager (WOM). By default, datastor, which is the data storage used for optimization, is provisioned on the primary hard disk drive (HDD). To use solid-state drives (SSDs) on BIG-IP WOM, you must

manually allocate the disk space on each SSD to the datastor service. If you install SSDs after you have provisioned WOM, you must first de-provision WOM, and then delete the datastor application volume from the primary disk, before you assign the datastor service to the SSD volume. 1. On the Main tab, click System > Resource Provisioning. 2. In the Resource Provisioning (Licensed Modules) area, from the WAN Optimization (WOM) list, select None (Disabled). 3. Click Update. 4. Click OK to proceed. The BIG-IP system restarts without WOM in the configuration. Note: This may take a minute or so. 5. Click Continue. 6. On the Main tab under System, click Disk Management. 7. If the Logical View shows Datastor allocation on HD1, delete it by performing the following steps. If datastor is not allocated to HD1, skip this step. Note: Datastor does not span the primary disk and the SSDs. If datastor is allocated to the primary disk, it will not use the SSDs. a. Click the disk label, for example HD1. The General Properties screen opens for the logical disk you selected. b. In the Contained Application Volumes area, select the check box for Datastor, and click Delete. 8. On the Disk Management screen, click the SSD disk label, for example, SSD1. The General Properties screen opens for the logical disk you selected. 9. For the Mode setting, select Datastor. The following figure shows the Datastor option selected.

10. Click Update. 11. Repeat the datastor selection steps for each SSD displayed on the Disk Management screen. 12. On the Main tab under System, click Resource Provisioning. 13. In the Resource Provisioning (Licensed Modules) area, from the WAN Optimization (WOM) list, select Nominal. 14. Click Update. 15. Click OK to proceed. The BIG-IP system restarts with WOM in the configuration. Note: This may take a minute or so. 16. Click Continue. The datastor service is now allocated to the SSDs. The datastor volume spans the installed SSDs. You can verify the result by checking the Disk Management screen. The logical view displays the datastor allocation for each disk. Monitoring SSD usage If you are using solid-state drives (SSDs) for datastor, you can view the SSD allocation and monitor the SSD lifespan. 1. On the Main tab under System, click Disk Management. 2. Use the Disk Management screen to view details about the SSDs, including the following. o To view the general properties of a disk, in the Logical View area, click the disk label. o In the Physical View area, note which bays contain the SSDs. o In the Data Disks area, view the Media Wearout Indicator to monitor disk usage.

6. RAID Maintenance/Monitoring <The following solution mentions monitoring RAID status but how do we do that? This section should be mainly about checking RAID status.>

Repairing disk errors on systems running on BIG-IP 10.x and 11.x with RAID storage
If both disks are showing data loss, or you suspect other issues, F5 recommends that you perform a clean installation of the software. For more information, refer to the relevant article:

SOL13117: Performing a clean installation of BIG-IP 11.x or Enterprise Manager 3.0.0 SOL10819: Performing a clean installation of BIG-IP 10.x or Enterprise Manager 2.x

If errors persist, contact F5 Technical Support for assistance.

For information about rebuilding RAID on BIG-IP WebAccelerator 4500 platforms, refer to SOL12223: Error Message: RAID monitor: RAID is degraded. Run 'rebuild_raid -s'. If only one disk in the RAID array is failing or suspect, you can repair the errors by first attempting a logical rebuild of the RAID array. If necessary, you can perform a physical rebuild. To do so, perform the following procedures: Performing a logical rebuild of the RAID array 1. Display the RAID information by typing one of the following commands: From the BIG-IP command line: tmsh show sys raid array From the tmsh console: show sys raid array The command displays output that appears similar to the following example: Sys::Raid::Array: MD1 -------------------Size (MB) 305245 Sys::Raid::ArrayMembers Bay ID Serial Number Name Array Member Array Status --------------------------------------------------------1 WD-WCAT18586780 HD2 yes failed 2 WD-WCAT1E733419 HD1 yes ok 2. Note the array label and the names of any drives associated with the array whose Array Status is failed. In the example, the array is labeled MD1 and the problem disk is HD2. 3. Logically remove the affected disk from the array by typing one of the following console commands: From the BIG-IP command line: tmsh modify sys raid array <array name> remove <disk name> From the tmsh console: modify sys raid array <array name> remove <disk name>

4. After you have logically removed the disk from the array, add the disk to the array again by typing one of the following commands: From the BIG-IP command line: tmsh modify sys raid array <array name> add <disk name> From the tmsh console: modify sys raid array <array name> add <disk name> Performing a physical rebuild of the RAID array 1. Display the RAID information by typing one of the following commands: From the BIG-IP command line: tmsh show sys raid array From the tmsh console: show sys raid array The command displays output that appears similar to the following example: Sys::Raid::Array: MD1 -------------------Size (MB) 305245 Sys::Raid::ArrayMembers Bay ID Serial Number Name Array Member Array Status --------------------------------------------------------1 WD-WCAT18586780 HD2 yes failed 2 WD-WCAT1E733419 HD1 yes ok 2. Note the array label and the Bay ID of any drives associated with the array whose Array Status is failed. In the example, the array is labeled MD1 and the problem disk is in Bay 1. 3. Physically remove the affected drive from the chassis. Note: When looking at the front panel of a 6900, 7xxx or 89xx series appliance, Bay 1 is the disk tray on the left and Bay 2 is the tray on the right.

4. After you have physically removed the disk from the chassis, wait about a minute to verify that the BIG-IP appliance is operating normally using only one drive. 5. Reinsert the drive into the appliance. 6. Monitor the system to verify that RAID begins rebuilding on the drive by typing one of the following commands: From the BIG-IP command line: tmsh show sys raid From the tmsh console: show sys raid The command displays output that appears similar to the following example: Sys::Raid::Array: MD1 -------------------Size (MB) 305245 Sys::Raid::ArrayMembers Bay ID Serial Number Name Array Member Array Status --------------------------------------------------------1 WD-WCAT18586780 HD2 yes replicating 2 WD-WCAT1E733419 HD1 yes ok If the array status of the affected drive is identified as replicating, this indicates that the system is transforming the disk into a RAID mirror and restoring the data to the array. Note: You can also monitor the RAID rebuilding process using the Configuration utility, on the RAID Management page located under the System portion of the navigation sidebar. For the duration of the replication process, the Configuration utility displays an alert near the top banner indicating that the RAID array is degraded. F5 expects this behavior. 7. Verify that the RAID array has been rebuilt successfully using the method you selected in Step 6 to monitor the status of the array. When the array is finished rebuilding, both disks display a status of ok, similar to the following example: Sys::Raid::Array: MD1 -------------------Size (MB) 305245 Sys::Raid::ArrayMembers Bay ID Serial Number Name Array Member Array Status ---------------------------------------------------------

1 2

WD-WCAT18586780 HD2 yes WD-WCAT1E733419 HD1 yes

ok ok

Note: The array rebuilding process typically takes approximately 30 to 60 minutes to complete. However, if the BIG-IP system is actively passing traffic, the process may take considerably longer to complete. 8. Monitor the RAID status over a period of several weeks to ensure disk errors have been fully repaired.

Chapter 3: Annual Diagnostics/EUD

1. Does F5 recommend taking a unit offline for End User Diagnostics EUD regularly?

Maintaining Hardware with End User Diagnostics (EUD)

The End User Diagnostics (EUD) software is a set of tests that report on various components in the hardware unit. The EUD is pre-installed on each BIG-IP system.
Caution: You should not run these test tools on a system that is in production. These tests stop the unit, and prevent it from passing traffic while these tests are run. Run this tool only if you are instructed to by a support representative, or if you are verifying a hardware issue with a unit that is already removed from production. Caution: Before you run these tests, you must disconnect all network cables from the system. Any cables connected to the system during the tests could cause false-positive results.

There are different EUD packages depending on the platform:

EUD Field Testing Enterprise Manager, WANJet, and WebAccelerator Hardware EUD Field Testing BIG-IP Hardware (1500, 3400, 3410, 4100, 6400, 6800, 8400, 8800) Field Testing BIG-IP Hardware: VIPRION 2000 Series Field Testing BIG-IP Hardware: VIPRION 4000 Series Field Testing BIG-IP Hardware (1600, 3600, 3900, 4500, 6900, 8900, 8950, 11050, EM4000)

When troubleshooting a potential hardware problem, F5 recommends downloading and installing the latest version of the EUD for your platform prior to running system diagnostics. Installing the latest version of EUD is recommended for the following reasons:
The EUD software is updated regularly for the relevant platform types. The latest EUD versions contain fixes and up-to-date changes for supported hardware platforms. Older versions of the EUD may not contain updates pertaining to platform changes such as those for RoHS compliance systems. Failure to use the latest released version of the EUD may result in false negative or false positive EUD reports. EUD reports containing false information or inaccuracies can delay the resolution of any potential underlying hardware problems.

About the EUD Tests Table <x> describes the various tests contained in EUD. You can specify options to run only non-interactive tests or to show test logs or quit the EUD.
Test Name Description If successful, returns message

Test Name System Report

Description
Provides comprehensive details about all system hardware components, such as: Serial number F5 part number Host information BIOS version Firmware version Bootloader version Processor, processor version Power supply firmware version Memory in each socket Total memory

If successful, returns message Test Complete: System Report: PASSED

Sensor Report

Performs the hardware sensor test on both the motherboard and the switchboard, if applicable and reports:
Host temperatures Host voltages Mezzanine temperature Mezzanine voltages CPU temperature CPU fan speeds SuperIO temperatures

Test Complete: Sensor Report: PASSED

SFP/SFP+ Report

I2C

PCI

Checks for interface modules installed in the system and reports: Vendor name Part number Revision Media type Verifies any Inter-Integrated Circuit (I2C) Bus protocol devices in the system. When you start the test, you get the following message: Test Begin: I2C Test Reports on and verifies the PCI devices on the PCI bus. Tests the following devices: Host PCI Host bridge System peripheral Communication controller ISA bridge RAID bus controller SMBus controller Signal processing controller Network and computing encryption MIPS USB controller PCI bridge Ethernet controller Switch controller When you start the test, you get the following message:

Test Complete: SFP/SFP+ Report: PASSED

Test Complete: I2C Test: PASSED

Test Complete: PCI Test: PASSED

Test Name

Description Test Begin: PCI Test Test Begin: verify HOST PCI: HOST PCI devices found Checks the ECC memory for error correction codes and reports single-bit or multi-bit errors. Uses the internal packet path to test the Ethernet interfaces in the system. This test sends known payload packets from the mainboard Ethernet interface back to the mezzanine Ethernet interface. The test checks for the correct receive order ad payload, and then checks the statistics at the switchboard and HSB. This test takes approximately two minutes. Sets the front interfaces into PHY or MAC loopback mode and runs packets through the path from the switch chips. Tests the SSL hardware. Tests the internal status of the hard drive, including: Read error rate Start/stop count Re-allocated sector count Power on hours count Spin-up retry count Drive calibration retry count Drive power cycle count Offline scan uncorrectable sector count Ultra ATA CRC error rate and multizone error rate Reports information about the power supplies installed in the system. It also returns the chassis voltage measurements, fan speeds, and the mode of the fan controller. Tests the USB ports on the mezzanine card installed in the platform. Treats HSB as a standard Ethernet NIC card, once the NIC module/driver is loaded, a loop test is performed by sending and receiving network packets over the HSB network interface. The number o fpakets is sent to and from one HiGig interface to another HiGig interface. Updates the hard drive firmware on Big-IP 3900 and EM 4000 platforms. This option appears only on those platforms when the system is booted with an older version of the firmware. Important: F5 recommends you back up your configuration before running the update.

If successful, returns message

ECC Status Internal Packet Path

Test Complete: ECC Status Test: PASSED Test complete: Internal Packet Path test: PASSED

Internal Loopback

Test Complete: Internal Loopback Test: PASSED Test Complete: Internal Loopback Test: PASSED Test Complete: SMART Test: PASSED

SSL Self-Monitoring Analysis and Reporting Technology (SMART)

Power System

Test Complete: Power system Test: PASSED

Mezzanine USB Mezzanine Packet

Test Complete: Mezzanine USB Test: PASSED Test Complete: Mezzanine Packet Test: PASSED

Hardware Firmware Update

Test Complete: Western Digital Firmware Update: PASSED

Test Name System RAM

Description Performs an SDRAM data bus and address bus test. All available userland memory is tested. Caution: This test might take several hours to complete depending on the amount o f memory available. It includes the following tests: Stuck address test Random value test XOR comparison test SUB comparison test MUL comparison test DIV comparison test OR comparison test AND comparison test Sequential increment test Sets each of the possible LED status levels and prompts you to verify the corresponding color and operation. You can perform this test from the console or LCD panel. Important: Some LED questions time out after a minute. If a question times out, the LED test fails. Tests the functionality of the LCD panel. To test, you need access to the LCD panel on the unit you want to test because you will need to respond Y or N to interactive prompts.

If successful, returns message Test Complete: System RAM Test: PASSED

LED (Interactive)

Test Complete: System RAM Test: PASSED

LCD

Test Complete: LCD Test: PASSED

Table <x> EUD Tests EUD Options You can specify the following options to modify the EUD process. EUD Test Option Description A Run All (Non-Interactive ) Tests Runs all tests that are applicable to the system except interactive tests. I Run All Interactive Tests Runs the LED and optional LCD tests D Display Test Report Log Displays a test report. A Report log is stored as the text file /shared/ log/eud.log in the host file system. Important: You must run eud_log from the command line to create output. S Display Test Summary Displays a test summary report showing the results of all tests run during a test session. Q Quit EUD and Reboot the System Stops the EUD and reboots the system. Warning: Using other methods to stop the diagnostics, such as the reboot command or the command menu option can destabilize the system.

Table <x> EUD Test Options Determining the EUD version F5 updates the EUD software regularly, and recommends that you install the latest version prior to running the EUD. You can also use this procedure to verify the installation of a new version is successful. To determine the EUD version on the BIG-IP system: 1. Log onto the command line of the BIG-IP system using an account with root access. 2. Enter the following command:
eud_info

The version number of the EUD installed on the system appears.

How to decide which files to download

There are several file types available from the F5 Networks download site,
http://downloads.f5.com .

File Name ISO image

Description The ISO image is provided for burning a CD or DVD of the EUD. You can boot the Cd/DVD from a powered USB CD/DVD drive plugged into the BIG-IP system. IM file The IM file is a self-extracting installation file. You can scp this file directly to the BIG-IP system and use it to upgrade the EUD on the system or load a USB flash drive. MD5 file There is a corresponding MD5 file for each ISO image and IM file you download. Us the MD5file to verify the integrity of the file you download. Readme-EUD.txt This file includes details about the release such as supported platforms. Table <x> EUD files available for download

Downloading the EUD IM file from F5 Networks

We recommend that you obtain the latest version of the EUD that is supported on your platform from the F5 Networks download site (http://downloads.f5.com) before you run these tests. 1. Log on to http://downloads.f5.com/ and click Find a Download. 2. In the Hardware-Specific area, click Platform / EUD. 3. Select your platform from the list. 4. Click the name of the release with the most recent date. You must accept the software terms and conditions before you can proceed. 5. Click the file name <file_name>.im to start the download. The <file_name> consists of the platform family and the build number. Note: You should copy the IM file to /var/tmp on the system you intend to update. 6. Download the corresponding checksum file. The corresponding checksum file has the same name as the IM file, except that .md5 is the file extension. After the download is complete, you should verify the integrity of the file by checking the MD5 checksum.

Downloading the EUD ISO file from F5 Networks

We recommend that you obtain the latest version of the EUD that is supported on your platform from the F5 Networks download site (http://downloads.f5.com) before you run these tests. 1. Log on to http://downloads.f5.com/and click Find a Download. 2. In the Hardware-Specific area, click Platform / EUD. 3. Select your platform from the list. 4. Click the name of the release with the most recent date. You have to accept the software terms and conditions before you can proceed. 5. Click the file name <file_name>.iso to start the download.

The <file_name> consists of the platform family and the build number. 6. Download the corresponding checksum file. The corresponding checksum file has the same name as the ISO file, except that .md5 is the file extension. After the download is complete, you should verify the integrity of the ISO file by checking the MD5 checksum.

Using the downloaded EUD files

There are several actions you can take after you download the EUD files. Task Description Use the MD5 checksum to verify the files Use the MD5 file to verify the integrity of the file you download. Install the EUD from the IM installation package You can scp this file directly to the BIG-IP system and use it to upgrade the EUD on the system. Load the EUD onto a USB flash drive Load the EUD onto a USB flash drive and run the EUD from the flash drive.

Using the MD5 checksum to check the integrity of the download

You can perform this task after you download update files and their corresponding .md5 files from the F5 Networks downloads site (http://downloads.f5.com). Verify the MD5 checksum on each file you download using the md5sum command. Use the output to verify the integrity of the downloaded file. 1. Log on to the command line of the system using an account with root access. 2. Type the following command to verify the integrity of the downloaded file, where <file_name>.md5 is the name of the .md5 file you downloaded.
md5sum -c <file_name>.md5

If the output is OK, the download was successful. If not, you should download the file again and repeat the process.

Installing the EUD from an IM installation package

You should copy the IM file to /var/tmp on the system you intend to update before you begin this procedure. Installing the EUD from an IM file is one method you can use to get the latest EUD installed on your hardware. 1. Log on to the command line of the BIG-IP system using an account with root access. 2. Type the following command to install the EUD, where <file_name>.im is the name of the file you downloaded.
im <file_name>.im

The latest EUD is installed on your hardware.

Loading the EUD onto a USB flash drive

You can run the EUD by booting the system from a USB flash drive loaded with the EUD software. Use this procedure to load the EUD onto a USB flash drive. 1. Log on to the command line of the BIG-IP system using an account with root access. 2. Download the IM file to /tmp/eud. 3. Loopback mount the IM file using the following command, where <file_name> is the name of the file you downloaded:
mkdir /tmp/eud; mount -o ro,loop <file_name>.im /tmp/eud

4. Insert a USB mass storage device into the platform on which you mounted the IM file. 5. Use the following command to run the mkdisk utility:
cd /tmp/eud; ./mkdisk

Follow the prompts to loads the EUD onto the USB flash drive. After the installation is complete, remove the USB flash drive from the BIG-IP system.

Running the EUD tests

There are several options for running the EUD tests. Task Description Boot the EUD from a USB flash drive Plug your EUD USB flash drive into the BIG-IP system and boot to the EUD. Boot the EUD from a USB DVD drive Plug your USB DVD drive into the BIG-IP system and boot to the EUD. Run the EUD from the system boot menu As the system is booting, select the EUD option from the boot menu.

Booting the EUD from a USB flash drive

You must load the EUD image onto the USB flash drive to run the EUD from the drive. You must have a console connected to the system to run the EUD. You can use this method to boot the EUD from a USB flash drive. 1. If the system is powered on, turn it off. 2. Plug in the USB flash drive that holds the EUD image into the USB port on the BIG-IP system. 3. Power on the system to boot the EUD. When the EUD starts, the EUD menu appears on the console.

Booting the EUD from a USB DVD drive

You must create a disk using the EUD ISO image before you can boot the EUD from a USB DVD drive. You must have a console connected to the system to run the EUD. You can use this method to boot the EUD from an externally-powered USB DVD drive. 1. If the system is powered on, turn it off. 2. Plug the USB DVD drive into the USB port on the BIG-IP system and insert the EUD DVD. 3. Power on the system to boot the EUD. When the EUD starts, the EUD menu appears on the console.

Starting the EUD from the boot menu

Install the latest version of the EUD before you boot the EUD from the boot menu. You must have a console connected to the system to run the EUD. You can use this method to boot the EUD installed on the BIG-IP system. 1. If the system is powered on, turn it off. 2. Power on the system. As the unit boots, it pauses briefly on the boot menu. 3.Use the arrow keys to highlight End User Diagnostics. When the EUD starts, the EUD menu appears on the console.

Chapter 4: iHealth
1. Recommend uploading a QkView to iHealth once a week BIG-IP iHealth enables you to verify the proper operation of your BIG-IP system and ensure your hardware and software function at peak efficiency. The technology at the heart of BIG-IP iHealth is the qkview file, which provides a running snapshot of your BIG-IP system with up-to-the-minute configuration and diagnostic information. You can quickly download a qkview file from your BIG-IP system, and then upload the file to the BIG-IP iHealth system. The BIG-IP iHealth system translates the output from your qkview file and displays the content in a customer-friendly format that mimics the familiar BIG-IP Configuration utility.

In addition to translating the raw data, the BIG-IP iHealth Diagnostics component of the BIG-IP iHealth system evaluates the logs, command output, and configuration of your BIGIP system against a database of known issues, common mistakes, and published F5 best practices. The prioritized 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. This customized diagnostic information enables you to take the recommended action, and in many cases, can help you resolve common configuration issues without the need to contact F5 Technical Support. If you require assistance from F5 Technical Support, your BIG-IP iHealth data will be available to F5 engineers for faster resolution.

Generating BIG-IP diagnostic data using the qkview utility

You should consider using this procedure under one of the following conditions:

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.

Prerequisites You must meet the following prerequisite to use this procedure:

You must have access to the BIG-IP command line or the Configuration utility.

Description The qkview utility is a BIG-IP program that an administrator can use to automatically collect configuration and diagnostic information from BIG-IP and Enterprise Manager systems. Starting in BIG-IP 10.0.0, the qkview utility is an executable program that generates machinereadable (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. Note: F5 Technical Support requires qkview output in all cases where remote access to the product is not available. Procedures Running qkview from the Configuration utility Running qkview from the command line Using qkview command line options Using BIG-IP iHealth to diagnose your qkview file

Running qkview from the Configuration utility Impact of procedure: The qkview utility runs a large number of commands when collecting information. This behavior may cause an additional performance burden on systems that are already heavily loaded. 1. Log in to the Configuration utility. 2. Click System. 3. Click Support. The QKView option is already selected. 4. Click Start. 5. When prompted, click the Download Snapshot File button to download the output file. Running qkview from the command line Impact of procedure: The qkview utility runs a large number of commands when collecting information. This behavior may cause an additional performance burden on systems that are already heavily loaded. 1. Log in to the command line. 2. Run qkview by typing the following command: qkview The output file name displays when the command has completed. 3. Collect the output file from the /var/tmp/ directory, by copying the file to an external host using a utility such as ftp or scp. Note: In BIG-IP 10.1.0 and later, you may also run qkview by using the tmsh run /util qkview command. Using qkview command line options Impact of procedure: None To view the list of qkview command line options, type the following command: qkview -h For example, to reduce the performance burden of qkview, you can run qkview at the lowest possible priority by typing the following command: nice -n 19 qkview

Note: On heavily loaded systems, qkview may take a long time to finish running when using nice -n 19. Using BIG-IP iHealth to diagnose your qkview file After you have obtained the qkview diagnostic file, you can upload the file to BIG-IP iHealth to diagnose the health and proper operation of your BIG-IP system. To do so, perform the following procedure: Impact of procedure: None. 1. 2. 3. 4. Open a web browser and log in to the BIG-IP iHealth website. Click Upload. Click Browse. Navigate to the qkview diagnostic file on your local system.

Note: As an alternative to using BIG-IP iHealth, you can also provide the qkview diagnostic file to F5 Technical Support. To do so, refer to the topic, Sharing Diagnostic Files with F5 Support in Section 3 of this manual, Optimizing the Support Experience. 2. You should address the issues identified on the iHealth Diagnostics output a. iHealth Diagnostics show what issues you are currently facing and should patch against 3. Use of EM for automatic uploads 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, and then view the diagnostics of all of your managed devices on a single screen. 4. Should we push the "upload to F5" button in the XUI again?

Chapter 5: Updating Software

F5 Networks recommends you check for software updates weekly. 1. Where to find a list of issues fixed in each release (AskF5) 2. Until we get Phone Home active check for other downloads a. OPSWAT b. Geolocation

Downloading and installing updates to the IP geolocation database The BIG-IP system uses an IP geolocation database to source data about the origin of a name resolution request. The default database provides geolocation data for IPv4 addresses at the continent, country, state, ISP, and organization levels. The state-level data is worldwide, and thus includes designations in other countries that correspond to the U.S. state-level in the geolocation hierarchy, for example, provinces in Canada. Note that you can only access the ISP and organization-level geolocation data for IPv4 addresses using the iRules whereis command. For more information, about iRules, see http://devcentral.f5.com/. The default database also provides geolocation data for IPv6 addresses at the continent and country levels.
Tip

If you require geolocation data at the city-level, contact your F5 Networks sales representative to purchase additional database files. You can download a monthly update to the IP geolocation database from F5 Networks.
To download and install an update to the IP geolocation database

1. Log in to the F5 Networks customer web site at https://downloads.f5.com. 2. Click Find a Download. 3. In the F5 Product Family column, find BIG-IP, and then in the Product Line column, click BIG-IP v10.x. 4. From the drop down list above the table, select a version. 5. In the Name column, click GeolocationUpdates. 6. Click I Accept to accept the license. 7. In the Filename column, click the name of the most recent zip file that you want to download. 8. In the Ready to Download table, click the download method that you want to use. 9. In the dialog box, click OK. 10. Select the directory in which you want to save the zip file. 11. Unzip the file, to save the RPM files on the system. 12. Install and load one of the RPM files using the following command sequence. Note that the path and file name are case-sensitive. geoip_update_data -f </path to RPM file and file name> The system installs and loads the specified database file. 13. Repeat step 12 for each of the other RPM files that you saved to the system in step 11. The system installs and loads the specified database file For information about uninstalling and reloading default geolocation data, see the TMOS Management guide for Big-IP Systems.
c. ASM Signatures d. DPI Signatures

Finding the latest software

To find the latest software version for your F5 product, view one of the following tables: The latest software versions for products that follow the F5 software life cycle policy The latest software versions for products that follow the Feature Release/Maintenance Release version schema The latest software versions for F5 hardware-specific software

The latest software versions for products that follow the F5 software life cycle policy Note: For more information, refer to SOL8986: F5 software life cycle policy. Product
BIG-IP LTM

Current Release
11.4.1 10.2.4

BIG-IP VE (Virtual Edition)

11.4.1 10.2.4

BIG-IP AAM BIG-IP AFM BIG-IP Analytics BIG-IP APM

11.4.1 11.4.1 11.3.0 11.4.1 10.2.4

BIG-IP ASM

11.4.1 10.2.4

BIG-IP Edge Gateway

11.4.1 10.2.4

BIG-IP GTM

11.4.1 10.2.4

BIG-IP Link Controller

11.4.1 10.2.4

BIG-IP PEM BIG-IP PSM

11.4.1 11.4.1 10.2.4

BIG-IP WebAccelerator

11.3.0 10.2.4

BIG-IP WOM

11.3.0 10.2.4

Enterprise Manager

3.1.1 2.3.0

Enterprise Manager (Virtual Edition)

3.1.0

ARX

6.4.0 5.2.2

ARX (Virtual Edition)

6.3.0 5.3.1

ARX Cloud Extender Data Manager

1.10.0 3.1.0 2.6.1

F5 Monitoring Pack BIG-IQ Cloud BIG-IQ Security Traffix Signaling Delivery Controller

3.2.1 4.1.0 4.1.0 4.0.2

The latest software versions for products that follow the Feature Release/Maintenance Release version schema Note: For more information, refer to SOL4476: F5 software life cycle policy (superseded by SOL8986). Current Feature Release
8.0.0 7.0.0 7.0.0 5.0.2 5.2.0

Product
BIG-IP SAM FirePass Controller FirePass Controller (Virtual Edition) WANJet WebAccelerator

Current Maintenance Release

N/A 6.1.0 N/A N/A 5.3.1

The latest software versions for F5 hardware-specific software Note: For information about F5 product hardware/software compatibility, refer to SOL9476: The F5 hardware/software compatibility matrix. Product
Always-On Management (AOM) End-User Diagnostics - BIG-IP

Current Version
10.1.13 10.4.0 Enterprise Manager, WANJet, and WebAccelerator Hardware 11.4.0 BIG-IP Hardware 12.1.0 VIPRION 2000 Series Hardware 12.2.0 VIPRION 4000 Series Hardware 12.0.0 VIPRION B4300 Blades Hardware 12.10.0 BIG-IP Hardware (1600, 3600, 3900, 6900, 8900, 8950, 11050, EM4000)

End-User Diagnostics - FirePass SCCP

10.0.9 FirePass Hardware (1200, 4100, 4300) 12.0.8

Updating the IP Geolocation Database

The BIG-IP system uses an IP geolocation database to source data about the origin of an IP address. You can download the IP geolocation database files and install them on the BIG-IP system by performing the following procedures. Downloading the geolocation database The database files are updated regularly and you can install them by performing the following procedure: 1. Access the F5 Downloads site. 2. Click Find a Download. 3. Under Product Line, click the appropriate BIG-IP software branch (for example, BIG-IP v11.x or BIGIP v10.x). 4. Select a BIG-IP version from the drop-down menu. 5. Click GeoLocationUpdates. 6. Accept the license agreement. 7. Download the ip-geolocation zip and MD5 files. Installing the geolocation database update 1. Copy the ip-geolocation zip and MD5 files you downloaded from the F5 Downloads site to the /shared/tmp directory on the BIG-IP system. 2. Log in to the BIG-IP command line. 3. Change the working directory to the /shared/tmp directory by entering the following command:
cd /shared/tmp

4. Unzip the file you copied in Step 1 to extract the RPM files. To do so, use the following command syntax, where </path/to/zipfile> is the path to the zip file on the BIG-IP system:
unzip </path/to/zipfile>

For example:
# unzip /shared/tmp/ip-geolocation-1.0.1-20120627.30.0.zip

Archive: ip-geolocation-1.0.1-20120627.30.0.zip inflating: geoip-data-Region2-1.0.1-20120627.30.0.i686.rpm inflating: geoip-data-ISP-1.0.1-20120627.30.0.i686.rpm inflating: geoip-data-Org-1.0.1-20120627.30.0.i686.rpm inflating: geoip-data-v6-1.0.1-20120627.30.0.i686.rpm

5. For each RPM file you extracted, use the following command syntax, where </path/to/rpm> is the path to the RPM file:
geoip_update_data -f </path/to/rpm>

For example:
# geoip_update_data -f /shared/tmp/geoip-data-Org-1.0.1-20120627.30.0.i686.rpm

The BIG-IP system installs and loads the specified database file. 6. Verify that the geolocation database was loaded. To verify that the geolocation database was loaded properly, use the geoip_lookup command to query the database. For example, the following command syntax queries one of the database files for a specific IP address:
geoip_lookup -f <path/to/db/files> IP

For example:
# geoip_lookup -f /shared/GeoIP/F5GeoIPOrg.dat 65.61.115.197

opening database in /shared/GeoIP/F5GeoIPOrg.dat size of geoip database = 180356873, version = GEO-146 20120627 Build 1 Copyright (c) F5 Networks Inc All Rights Reserved geoip_seek = 014f0ad1 geoip record ip = 65.61.115.197 name = f5 networks

Updating the BIG-IP ASM attack signatures

Attack signatures are rules or patterns that identify attack sequences or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. F5 releases a new attack signature update for BIG-IP ASM about every six weeks. The attack signature update includes new attack signatures as well as enhancements to existing attack signatures. Attack signature updates are released only for versions of software that have not yet reached their End of Software Development date, as detailed in SOL5903: BIG-IP software support policy. Attack signature updates are available from the F5 Downloads site, under the version of the BIG-IP system that you are currently running.

Since new web application attacks and threats are constantly being developed, you should update the system-supplied attack signatures on a regular basis to ensure that your applications are protected against new attacks. You can configure automatic updates, or you can manually update the signatures. The attack signature updates are cumulative; when you update the system-supplied attack signatures, the update provides the latest signatures and all signatures from the previous updates. Updating the attack signatures also provides any revisions to existing attack signatures. Attack signatures are also saved in UCS archives. When a UCS archive is created, the current cumulative signature set is saved in the archive. When a UCS archive is restored, the attack signatures in the archive fully replace existing signatures. If the UCS archive is old, the attack signatures may be out-of-date and need to be updated separately.

Licensing requirements
For the system to initiate the attack signature update, the Service Check Date in the BIG-IP ASM system's license must be within 60 days of the system date for versions prior to 9.4.7, and within 18 months of the system date for version 9.4.7 or later. Note: For more information about the licensing requirement changes, refer to SOL10018: Change in Behavior: Service Check Date Requirement for Signature Updates If the Service Check Date is recent enough, the system allows the signature update. If the Service Check Date is too old, the BIG-IP ASM system attempts to contact the license server and downloads a new license. If the system can reach the license server, and the support contract for the system is current: o

The system downloads a new license and verifies the Service Check Date. Note: The system does not install the new license, but only examines it for the required date. o If the Service Check Date is within seven days of the system date (accounting for time zone differences and system clock variance) the system initiates the signature update. If the license server cannot be reached or the support contract for the system is not current: o An error message that appears similar to the following example will be reported in the Configuration utility and logged to the /var/log/asm file:

Service contract cannot be verified (500 read timeout at /ts/packages//iControl.pm line 1005). Please re-license your installation of Big-IP manually.
o You must manually reactivate the system license, and reinitiate the attack signature update. Important: You should be logged into the system with the admin user account to perform the manual licensing procedure. For more information, refer to SOL9965: The admin user account must be used to license the system. Note: If the error persists when attempting to manually reactivate the license, contact F5 Technical Support for questions about the status of the support contract for the affected system.

Configuring automatic updates for system-supplied attack signatures

To configure the BIG-IP ASM to download the attack signature update files over the Internet, perform one of the following procedures: Configuring the BIG-IP ASM to download the attack signature update files using a scheduled update mode Configuring the BIG-IP ASM to download the attack signature update files using a manual update mode Note: The BIG-IP ASM uses its own self IP address and default gateway when requesting attack signature updates using the Automatic Method. If Internet access is not available for automatic updates, an error message similar to the following example is reported in the Configuration utility as well as in the /var/log/asm file:

Signature file server cannot be reached (500 SSL negotiation failed: ). Please download the signature file and install manually. Configuring the BIG-IP ASM to download the attack signature update files using a scheduled update mode
1. 2. 3. 4. 5. 6. Log in to the Configuration utility. On the Main tab of the Application Security navigation pane, click Options. From the Attack Signatures menu, select Attack Signatures Update. In the Attack Signature Updates section, select Scheduled. From the Update Interval menu, select an update interval. Click Save Settings.

Configuring the BIG-IP ASM to download the attack signature update files using a manual update mode
Note: When you select Manual for the Update Mode, you update the attack signatures on your own schedule by clicking Update Signatures. 1. Log in to the Configuration utility. 2. On the Main tab of the Application Security navigation pane, click Options. 3. From the Attack Signatures menu, select Attack Signatures Update. 4. In the Attack Signature Updates section, select Manual. 5. In the Delivery Mode section, select Automatic. 6. Click Save Settings. 7. When you are ready to update the attack signatures, click Check for Updates, and if an update is available, click Update Signatures to download and install the updates.

Configuring manual updates for system-supplied attack signatures

To configure the BIG-IP ASM to use attack signatures from an update file that was manually downloaded from an F5 server, perform the following procedure: Note: Use this option if your BIG-IP ASM system does not have direct Internet access. 1. Browse to https://downloads.f5.com. 2. Manually download the latest signature file to your local workstation. 3. Log in to the Configuration utility. 4. On the Main tab of the Application Security navigation pane, click Options. 5. From the Attack Signatures menu, select Attack Signatures Update. 6. In the Update Mode setting, click Manual. 7. For the Delivery Mode setting, select Manual.

8. Click Save Settings. 9. If you want to update the system-supplied signatures now, click Browse and locate the previouslysaved signature file, so that the path to the file appears in the Upload File box. 10. Click Update Signatures to upload and apply the signature update.

Allowing signature updates through a firewall

If your BIG-IP ASM system is behind a firewall, you should allow access for the following host servers, DNS servers, and ports so that the BIG-IP ASM system can obtain the attack signature updates: Host servers

o callhome.f5.com port 443 o activate.f5.com port 443 DNS servers o o The firewall should allow port 53 access for the DNS name server(s) configured for use by the BIGIP ASM system. Additionally, if the BIG-IP ASM has not been configured with a reachable DNS name server, it will attempt to use an F5 DNS nameserver configured in the /var/ts/etc/services.ini file. The firewall should allow port 53 access for the IP addresses listed for the prod_dns_server= setting in this file.

Configuring signature file updates through an HTTPS proxy

Beginning in BIG-IP ASM 10.0.0, you can configure the system to use an HTTPS proxy, which allows an administrator to configure the BIG-IP ASM to update attack signatures securely and automatically. To do so, perform the following procedure: 1. Log in to the command line. 2. Change directories to the /ts/etc/ directory by typing the following command:
cd /ts/etc/

3. Create a backup of the services.ini file by typing the following command:

cp services.ini /var/tmp/services.ini.bak

4. Using a text editor, edit the services.ini file. 5. Add the following section to the end of the file:
[proxy] https_proxy=https://<IP address of your HTTPS proxy server>:<HTTPS proxy server port>

For example:

[proxy] https_proxy=https://172.16.10.100:33750
6. Save the changes you made to the services.ini file. Note: This change must be made manually on both systems in redundant pair configurations. The services.ini file is not copied to the peer system during ConfigSync operations. Note: When signatures are updated, they are automatically removed from blocking mode. For more information, refer to SOL11303: Updated signatures are automatically removed from blocking mode and placed into staging mode.

Chapter 6: Check entitlement every 6 months

1. Module license dates 2. Subscription services dates 3. Monitor external services subscription expiration dates

Chapter 7: Log file scanning and alert checking

1. this should be about monitoring and alerting system interaction unless we supply a comprehensive list 2. Causes of excessive logging a. Debug modes b. iRules gone wild

Chapter 8: Backups/DR
1. Creation of UCS files

Introducing archives
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, bigpipe 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, redundant system settings, 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. 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 use the bigpipe utility, which exports 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. For details on creating and using a single configuration file, see Working with Single Configuration Files.

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 Each time you back up the configuration data, the BIG-IP system creates a new file with a .ucs extension. Each UCS file contains various configuration files needed for the BIG-IP system to operate correctly, as well as the configuration data.
Important

To create, delete, upload, or download an archive, you must have either the Administrator or Resource Administrator role assigned to your user account.

Working with archives

Using the Configuration utility, you can save and restore archives that are stored on the BIG-IP system. Furthermore, for added security, you can save archives to and restore archives from a remote system, that is, the system on which you are running the Configuration utility.

Saving archives
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 After you create an archive on the BIG-IP system, you can download a copy of the UCS file to the system from which you are running the Configuration utility (a secure remote system). This provides an extra level of protection by preserving the configuration data on a remote system. In the unlikely event that you need to restore the data, and a BIG-IP system event prevents you from accessing the archive in the BIG-IP system directory in which you saved the archive, you still have a backup copy of the data. For more information on saving archives, see Creating and saving an archive on the BIG-IP system.
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.

Restoring archives
Not only is the /var/local/ucs directory the only location on the BIG-IP system in which you can save an archive, but it is also the only location on the BIG-IP system from which you can restore an archive. However, if you previously downloaded an archive to a remote system, and a BIG-IP system event prevents you from accessing the /var/local/ucs directory, you can upload the archive from that remote system. For more information on restoring archive data, see Restoring data from a BIG-IP system archive.

Synchronizing data for redundant systems

When you have a redundant system configuration, it is essential that the same set of configuration data exists on both units of the BIG-IP system. To synchronize configuration data, you use the High Availability screens in the System area of the Configuration utility. To mitigate against data loss, however, you use the Archives screens. We recommend that you use the archives feature to routinely create an archive of the configuration data on each unit of the redundant system. 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. If you have set the Archive Encryption setting to On (using the Preferences screen), the BIG-IP system encrypts any UCS file that you create, including the cs_backup.ucs file.

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
Note

Only users with either the Administrator or Resource Administrator user role can manage archives.

Viewing a list of existing archives

You can view a list of archives (that is, UCS files) that are currently stored in the /var/local/ucs directory on the BIG-IP system. When you view a list of archives, the Configuration utility displays the following information: The name of the UCS file The date that the UCS file was created or uploaded The size of the file, in kilobytes

Note

Whenever you last upgraded the BIG-IP system to a new version, you were required to create a UCS file named config.ucs, using the bigpipe config save command. This UCS file appears in the list of UCS files on the Archives screen.

To view a list of existing archives

On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens, displaying a list of existing UCS files.

Creating and saving an archive on the BIG-IP system

You can create a new archive, which the BIG-IP system automatically stores in a default location, the /var/local/ucs directory. You can create as many separate archives as you want, as long as each archive has a unique file name. Also, you can specify that the BIG-IP system store an archive in a directory other than /var/local/ucs, although in this case, the Configuration utility does not include the archive name in the list of archives on the Archives screen. When you create an archive, you configure some settings, such as a setting to encrypt the archive file for security reasons. Table <x> lists and describes these settings, and shows their default values.
Setting Description Default Value File Name Specifies the file name for the archive. You do not need to specify the UCS file name extension. The BIG-IP system appends the UCS extension automatically. No default value Encryption Enables or disables encryption of the archive. If you select Enabled, two other settings, Passphrase and Verify Passphrase, appear on the screen. Note: This setting appears only when you have used the Preferences screen to set the Archive Encryption setting to On Request or On. Disabled Passphrase Specifies a password that a user must use to decrypt an archive. No default value Verify Passphrase Specifies the password that you defined with the Passphrase setting. No default value Private Keys Specifies whether to include or exclude private keys in the archive. Include Version Displays the version of the BIG-IP system application that is currently running on the BIG-IP hardware platform. You cannot configure the Version setting. No default value

Table <x> Settings for creating an archive

To create an archive
1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the upper-right corner of the screen, click Create. The New Archive screen opens. Note: If the Create button is unavailable, you do not have permission to create an archive. You must have the Administrator role assigned to your user account. 3. In the File Name box, type a unique file name for the archive. We recommend that the file name match the name of the BIG-IP system. For example, if the name of the BIG-IP system is bigip2, then the name of the archive file should be bigip2.ucs. For more information, see Working with archives. 4. If you want to encrypt the archive, locate the Encryption list and

select Enabled. Note: If the Encryption setting is unavailable, you must configure the Archive Encryption setting located on the Preferences screen. For more information, see the description of the Configuration utility in Chapter 1 of the TMOS Management Guide for BIG-IP Systems. 5. If you want the BIG-IP system to include any private keys, locate the Private Keys list and select Include. In this case, be sure to store the archive file in a secure environment. 6. Click Finished.

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 (encrypted or unencrypted) The date that the archive was created The size of the archive, in kilobytes

To view the properties of an archive

1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the Name column, click the name of the archive that you want to view. This displays the properties of that archive.

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

The host name stored in the archive file must match the host name of the BIG-IP system you are restoring. Otherwise, the system does not fully restore the data.

To restore data from a BIG-IP system archive

1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the File Name column, click the name of the archive that you want to use to restore the configuration data. This displays the properties of that archive. 3. Click Restore. This causes the system to display a progress message.

Downloading an archive to a remote system

As described in the section Introducing archives, on page 22-1, you can download a copy of an existing archive to a remote system, that is, the system from which you ran the Configuration utility to create the archive. This feature protects the configuration data in the unlikely event that the BIG-IP system experiences a system catastrophe.

When you download an existing archive, you first display the properties of the archive you want to download, and then specify the complete path name of the location to which you want to save the archive copy.

To download an archive
1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the File Name column, click the name of the archive that you want to view. This displays the properties of that archive. 3. For the Archive File setting, click the Download: <.ucs filename> button. A confirmation screen appears. 4. Click Save. The BIG-IP system downloads a copy of the UCS file to the system from which you initiated the download.

Uploading an archive from a remote system

If you previously downloaded a copy of an archive to a remote system (that is, the system from which you initiated the download), you can upload that archive to the BIG-IP system at any time. This is most useful when a BIG-IP system event has occurred that has caused the archive stored on the BIG-IP system to either become unavailable or corrupted for some reason. Note that when you upload a copy of an archive, you must specify the exact path name for the directory in which the downloaded archive copy is stored.

To upload an archive
1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the upper-right corner of the screen, click Upload. This opens the Upload screen. 3. In the File Name box, type the complete path and file name of the archive that you want to upload onto the BIG-IP system. If you do not recall the path or file name, you can use the Browse button to locate and select the file name. 4. For the Options setting, check the Overwrite existing archive file box if you want the BIG-IP system to overwrite any existing archive file. Note: The BIG-IP system overwrites an existing file with the uploaded file only when the name of the archive you are uploading matches the name of an archive on the BIG-IP system. 5. Click Upload. This uploads the specified archive to the directory /var/local/ucs on the BIG-IP system.

Deleting an archive
You can use the Configuration utility to delete any archive on the BIG-IP system that is stored in the directory /var/local/ucs.

To delete an archive
1. On the Main tab of the navigation pane, expand System, and click Archives. The Archives screen opens. 2. In the File Name column, locate the name of the archive you want to delete.

3. To the left of the archive name, check the Select box. 4. Click Delete. A confirmation box appears. 5. Click Delete again. This deletes the archive from the /var/local/ucs directory on the BIG-IP system.

Overview of UCS archives

A user configuration set (UCS) is a backup file containing BIG-IP configuration data that can be used to fully restore a BIG-IP system in the event of a failure or RMA replacement.

Contents of the UCS archive file

A UCS archive is a compressed file that contains all of the configuration files that are typically required to restore your current configuration to a new system. These files are: All BIG-IP-specific configuration files BIG-IP product licenses User accounts and password information DNS zone files and the ZoneRunner configuration SSL certificates and keys Important: In addition to user accounts, passwords, and critical system files, a typical UCS archive containsunless explicitly excluded during the backup process the SSL private keys that are associated with client and server SSL profiles. If your UCS archive contains SSL private keys, you must store backup UCS archives in an environment that is as secure as where you store your private keys.

Exceptions to UCS archive file on VIPRION systems

The BIG-IP VIPRION system is unique among BIG-IP hardware in that it allows you to combine all blades within the chassis to increase processing ability. This functionality, referred to as clustering, is unique and is written to a special file in the /shared/db directory called cluster.conf. Additionally, the system saves a copy as cluster.conf.<chassis SN>, where <chassis SN> is the unique serial number of the chassis. The blade maintains the *.<chassis SN> files and copies them to cluster.conf when the blade starts in a chassis that it has encountered before. The cluster.conf file consists of each blade's copy of the cluster configuration. The file contains the management addresses for the cluster and for each blade within the cluster, as well as other cluster-specific information. Since this information is specific and unique to the chassis, the information is not included within a UCS archive. If you load a UCS archive, the archive does not overwrite the current cluster.conf file and does not restore a previous cluster configuration. If you reconfigure the cluster, you must manually rebuild the cluster.conf file in the following circumstances:

A blade starts as the primary blade in the chassis, and the cluster.conf file does not contain the serial number of the chassis. You have replaced the chassis. (The chassis serial number must match the chassis serial number in the cluster.conf file.)

Viewing the list of files saved within a UCS archive

To view the files that have been saved in a UCS archive, use the following command syntax:
tar -ztf <filename>

In the previous syntax, replace <filename> with the name of the UCS archive. This command provides a list of all the files included in the UCS archive.

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), perform the following procedure: 1. Change to the directory that contains the UCS archive, using the following command syntax:
cd <directory>

In the previous syntax, replace <directory> with the name of the directory where the UCS archive is located. 2. Extract the file you want from the UCS archive, to standard output, using the following command syntax:
tar -zxOf <filename> <file-to-extract>

Note: The third character in the flags list is a capital letter O. In the previous syntax, replace <filename> with the name of the UCS archive, and replace <file-toextract> with the relative path and name of the file that you want to extract from the UCS archive. For example, to view the file bigip.conf you must specify the config directory, but not the root directory, as follows: tar -zxOf myconfig.ucs config/bigip.conf Note: You can use wildcards, for example config/bigip.*, to display multiple files from an archive. Warning: Some files contained in a UCS archive are binary files that do not display correctly to standard output.

Extracting files from the UCS archive

You can extract the files from a UCS archive without overwriting your existing configuration by performing one of the following processes: Extract a single file from a UCS archive file Extract all files from a UCS archive file

Extracting a single file from a UCS archive file 1. Create a new directory within the /var/tmp directory using the following command syntax:
mkdir /var/tmp/<directory>

In the previous syntax, replace <directory> with a name of your directory. 2. Copy the UCS archive into the new directory using the following command syntax:
cp <filename> /var/tmp/<directory>/

In the previous syntax, replace <filename> with the name of the UCS archive from which you want to extract files, and replace <directory> with the name of the directory that you created in step 1. 3. Change directories to the new directory using the following command syntax:
cd /var/tmp/<directory>

In the previous syntax, replace <directory> with the name of the directory that you created in step 1. 4. Extract the file you want from the UCS archive, using the following command syntax:
tar -zxf <filename> <file-to-extract>

In the previous syntax, replace <filename> with the name of the UCS archive, and replace <file-toextract> with the relative path and name of the file that you want to extract from the UCS archive. For example, to retrieve the file bigip.conf, you must specify the config directory, but not the root directory, as follows:
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. Extracting all files from a UCS archive file 1. Create a new directory within the /var/tmp directory, using the following command syntax:
mkdir /var/tmp/<directory>

In the previous syntax, replace <directory> with a name of your directory. 2. Copy the UCS archive into the new directory using the following command syntax:
cp <filename> /var/tmp/<directory>/

In the previous syntax, replace <filename> with the name of the UCS archive from which you want to extract files, and replace <directory> with the name of the directory that you created in step 1. 3. Change directories to the new directory using the following command syntax:
cd /var/tmp/<directory>

In the previous syntax, replace <directory> with the name of the directory that you created in step 1. 4. Extract the files from the UCS archive using the following command syntax:
tar -zxf <filename>

In the previous syntax, replace <filename> with the name of the UCS archive. 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.

Backing up and restoring BIG-IP configuration files

You should consider using this procedure when you want to perform one of the following actions: Back up your BIG-IP 11.x configuration data to a user configuration set (UCS) configuration archive. Restore your BIG-IP 11.x configuration data by using a UCS configuration archive.

Restore a BIG-IP 10.x UCS archive on a BIG-IP 11.x system.

Prerequisites
You must meet the following prerequisite to use this procedure: The BIG-IP system must be running BIG-IP 11.x software.

F5 advises that you read the following sections and perform the procedures that apply to your BIG-IP system before proceeding: Considerations for backing up configuration data Considerations for restoring configuration data

Description
This article describes how to back up and restore your BIG-IP 11.x configuration data by using a UCS configuration archive. The UCS archive, by default, contains all of the files that are required to restore your current configuration to a new system, including configuration files, the product license, local user accounts, and Secure Socket Layer (SSL) certificate/key pairs.

Considerations for backing up configuration data

Backing up customized configuration files If your system configuration has been customized to reference files that are not included in the default BIG-IP installation, refer to SOL4422: Viewing and modifying the files that are configured for inclusion in a UCS archive. File names and location By default, the BIG-IP system saves the UCS archive file with a .ucs extension if you do not include it in the file name. You can also specify a full path to the archive file, and then the archive file is saved to the specified location. If you do not include a path, the file is saved to the default archive directory, /var/local/ucs. Archives located in a directory other than the default do not appear in the list of available archives when using the Configuration utility to create or restore a UCS archive, or when using the list /sys ucs command in the tmsh utility. To easily identify the file, F5 recommends that you include the BIG-IP host name and current timestamp as part of the file name. Secure Storage Ensure that you have access to a secure location for storage of your UCS archive files. In addition to user accounts, passwords, and critical system files, a typical UCS archive contains (unless explicitly excluded

during the backup process) the SSL private keys that are associated with client and server SSL profiles. It is important to store the backup UCS archives containing sensitive information in a secure location. For instructions, refer to SOL175: Transferring files to or from an F5 system.

Considerations for restoring configuration data

BIG-IP software version and platform F5 recommends that you run the same version of the BIG-IP software on the BIG-IP system from which it was backed up. However, you can restore a BIG-IP 10.x UCS archive on a system running BIG-IP 11.x software. Due to an issue in BIG-IP 11.0.0, you must perform a configuration restoration using a configuration archive that is taken from the same hardware platform. For more information, refer to SOL13136: The UCS configuration archive cannot be restored on a platform other than the one on which the archive was created.

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 asneeded basis, in the event of a Return Materials Authorization (RMA). Relicense the BIG-IP system after restoring the UCS archive. Save the license file prior to restoring the configuration from another system, and then copy the license file back. Install the UCS archive by using the tmsh no-license option. Important: If you use a different license than the one contained in a restored UCS archive, the replacement license must include authorization for the same options and add-on modules, such as BIGIP WebAccelerator or BIG-IP ASM. If you attempt to restore a UCS configuration referencing an unlicensed module, the BIG-IP system does not properly restore the UCS archive. Additionally, the BIGIP system reports a Provisioning Warning message in the Configuration utility, as well as the status of ModuleNotLicensed in its command-line prompt.

UCS files
If necessary, copy the UCS archive file you want to restore to the BIG-IP filesystem. Host name and base configuration The UCS restore operation restores the full configuration to the target system, including the host name and the base configuration. Note: This behavior has changed from previous versions of the BIG-IP system.

SSL private keys with passphrases If you are restoring on a new system, a UCS archive that includes SSL private keys with encrypted passphrases cannot be decrypted by the new system. This format is an intentional security measure. When replacing one system of a failover pair, F5 recommends that you configure basic networking on the replacement unit and synchronize the configuration from its peer instead of restoring the configuration by installing the UCS archive. Because the master key is shared between units of a redundant pair, the configuration synchronization process synchronizes the original master key to the newly-installed device. If you cannot synchronize the original master key to the new system from its peer, but you know the original unencrypted passphrases, you can install the UCS file to restore the configuration, modify the affected SSL profiles to replace the encrypted passphrases with unencrypted versions, and save the resulting configuration. If you are restoring a backup that contains SSL private key passphrases after reinstalling the operating system, replacing a failed system with a new system, or otherwise moving an existing configuration to a new system, the encrypted passphrases for SSL private keys used in the configuration cannot be decrypted. An error message similar to the following example appears:

BIGpipe client SSL profile creation error: 01070937:3: Master Key decrypt failure - decrypt failure
If you receive this error message when installing the UCS archive, refer to SOL9420: Installing a UCS file containing an encrypted passphrase before proceeding.

BIG-IP GTM considerations

If you want to install a UCS archive on a BIG-IP GTM system (such as an RMA replacement), and prevent the BIG-IP GTM system from synchronizing the contents of the UCS archive to the GTM synchronization group, refer to SOL14083: Preventing synchronization when installing a UCS archive on a BIG-IP GTM system. For a BIG-IP GTM RMA unit that is licensed and provisioned with the BIG-IP GTM module and the DNSSEC feature, refer to SOL13542: Restoring DNSSEC configuration data to a BIG-IP GTM RMA unit.

BIG-IP ASM considerations

If you are restoring a UCS file that is licensed and provisioned with the BIG-IP ASM module, you may need to provision the system for BIG-IP ASM before loading the UCS file. For more information, refer to SOL13945: The BIG-IP ASM MySQL database is not installed completely if the BIG-IP ASM is not provisioned when the UCS is loaded.

Other considerations
If you are restoring a UCS file on a BIG-IP unit that is part of a redundant pair, refer to SOL8086: Replacing a BIG-IP system in a redundant pair without interrupting service.

vCMP considerations
For a Virtual Clustered Multiprocessing (vCMP) host, the UCS configuration archive contains only the necessary files that are required to restore the vCMP host configuration, but does not include the vCMP guest virtual disk. For a vCMP guest, the UCS configuration archive contains all of the files that are specific to the vCMP guest, including the configuration files, local user accounts, and SSL certificate and key pairs. When you restore a vCMP host UCS archive on an appropriate vCMP host, the vCMP host automatically attempts to restore the vCMP guest to a base state by performing the vCMP guest provisioning, installation, and deployment. When the vCMP guest has been restored to a base state, you can restore the vCMP guest by installing the desired UCS archive that was previously taken from a vCMP guest. The restoration of a UCS archive to a vCMP guest is subject to all of the restrictions and considerations described in the previous sections of this article.

Procedures
Backing up your BIG-IP system configuration Restoring your BIG-IP system configuration

Backing up your BIG-IP system configuration

Backing up configuration data by using the Configuration utility Backing up configuration data by using the tmsh utility

Backing up configuration data by using the Configuration utility

Impact of procedure: Performing the following procedure should not have a negative impact on your system. 1. Log in to the Configuration utility. 2. Click System. 3. Click Archives. 4. To initiate the process of creating a new UCS archive, click Create. 5. In the File Name box, type a name for the file. Important: You must use a unique file name. If a file by the same name already exists, the UCS archive file is not created, and the system displays a warning message that appears similar to the following example:

The file already exists on the system

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

7. Optional: If you want to exclude SSL private keys from the UCS archive, from the Private Keys menu, select Exclude. 8. To create the UCS archive file, click Finished. 9. When the backup process is done, examine the status page for any reported errors before proceeding to the next step. 10. To return to the Archive List page, click OK. 11. Copy the .ucs file to another system.

Backing up configuration data by using the tmsh utility

Impact of procedure: Performing the following procedure should not have a negative impact on your system. 1. Log in to tmsh by typing the following command:
tmsh

2. Create the UCS archive file by using the following command syntax. Replace <path/to/UCS> with the full path to the UCS archive file:

save /sys ucs <path/to/UCS>

For example:

save /sys ucs /var/tmp/MyUCS.ucs

3. Optional: If you want to encrypt the UCS archive with a passphrase, use the following command syntax. Replace <path/to/UCS> with the full path to the UCS archive file, and replace <password> with the passphrase you want to use to encrypt the UCS archive:

save /sys ucs <path/to/UCS> passphrase <password>

For example:

save /sys ucs /var/tmp/MyUCS.ucs passphrase password

4. Optional: If you want to exclude SSL private keys from the UCS archive, use the following command syntax. Replace <path/to/UCS> with the full path to the UCS archive file.

save /sys ucs <path/to/UCS> no-private-key

For example:

save /sys ucs /var/tmp/MyUCS.ucs no-private-key

5. Copy the .ucs file to another system Restoring your BIG-IP system configuration

Restoring configuration data by using the Configuration utility

Restoring configuration data from the command line by using the tmsh utility Restoring configuration data on a replacement RMA unit

Restoring UCS archives on BIG-IP systems running later software versions

Restoring configuration data by using the Configuration utility Impact of procedure: The BIG-IP system replaces any existing configuration with the UCS archive file configuration. If you are restoring a UCS archive on a BIG-IP 6400, 6800, 8400, or 8800 hardware platform other than the system from which the backup was created, such as when replacing an RMA system, you must perform the procedure in the Restoring configuration data from the command line by using the tmsh utility section of this article to restore the configuration.

To restore a configuration in a UCS archive by using the Configuration utility, review the considerations described in the Considerations for restoring configuration data section of this article before performing the following procedure: 1. 2. 3. 4. 5. 6. 7. 8. 9. Log in to the Configuration utility. Click System. Click 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. When the restore process is completed, examine the status page for any reported errors before proceeding to the next step. To return to the Archive List page, click OK. If you restored the UCS archive on a different device and received the errors noted in the Considerations for restoring configuration data section of this article, you must reactivate the BIG-IP system license. 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. If the system you restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World after completing steps 1 through 9. For additional information about recovering FIPS information after a system recovery, refer to the Configuring and Maintaining a FIPS Security Domain chapter in the Platform Guide: 6900 and 8900.

10. 11.

Restoring configuration data from the command line by using the tmsh utility
Impact of procedure: The BIG-IP system replaces any existing configuration with the UCS archive file configuration. 1. Log in to tmsh by typing the following command:
tmsh

2. Restore the UCS archive file by using the following command syntax. Replace <path/to/UCS> with the full path of the UCS archive file you want to restore:

load /sys ucs <path/to/UCS>

If you do not specify the path, the BIG-IP system performs as if the UCS archive file is located in the default /var/local/ucs directory. 3. If the UCS archive file was encrypted with a passphrase during the backup, you are prompted to enter the passphrase for the archive file. 4. 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:
run /util bash

5. 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):
keyswap.sh sccp

6. Type the following command to switch back to tmsh:

exit

7. Restart the system by typing the following command:

reboot

If you installed the UCS archive on the same device on which the backup was created, it loads the restored configuration after the system restarts. If you restored the backup on a different device and received the first error noted in the Considerations for restoring configuration data section of this article, you must reactivate the BIG-IP system license. Alternatively, you can replace the /config/bigip.license file with the original bigip.license file that you backed up from the target system. 8. If the system you restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World after completing steps 1 through 5. For additional information about recovering FIPS information after a system recovery, refer to the Configuring and Maintaining a FIPS Security Domain chapter in the Platform Guide: 6900 and 8900.

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)
F5 expects this message, and you can correct the issue by re-licensing the system, which is discussed later in the procedure. Impact of procedure: The BIG-IP system replaces any existing configuration with the UCS archive file configuration. 1. Activate the license on the unit according to the steps detailed in SOL7752: Overview of licensing the BIG-IP system. 2. Log in to tmsh by typing the following command:
tmsh

3. Restore the UCS archive file by using the following command syntax. Replace <path/to/UCS> with the full path of the UCS archive file you want to restore:

load /sys ucs <path/to/UCS> no-license

If you do not specify the path, the BIG-IP system performs as if the UCS archive file is located in the default /var/local/ucs directory.

4. If the UCS archive file was encrypted with a passphrase during the backup, you are prompted to enter the passphrase for the archive file. 5. If you are running the BIG-IP system on a 6400, 6800, 8400, or 8800 hardware platform, switch to the bash utility by entering the following command:
run /util bash

6. To verify that the new or replaced SSH keys from the UCS file are synchronized between the BIG-IP and the SCCP, enter the following command:
keyswap.sh sccp

7. To switch back to tmsh, type the following command:

exit

8. Restart the system by typing the following command:

reboot

9. If the system you restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World after completing steps 1 through 5. For additional information about recovering FIPS information after a system recovery, refer to the Configuring and Maintaining a FIPS Security Domain chapter in the Platform Guide: 6900 and 8900.

Restoring UCS archives on BIG-IP systems running later software versions

Impact of procedure: The BIG-IP system replaces any existing configuration with the UCS archive file configuration. 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. For information about supported upgrade paths, refer to the product release notes for your specific software version. 2. Review the previous section, Considerations for restoring configuration data. 3. Manually copy the UCS archive file to the /var/local/ucs/ directory on the target system.

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

2. Creation of SCF files

Overview of single configuration files (11.x)

A single configuration file (SCF) is a flat, text file that contains a series of Traffic Management Shell (tmsh) commands and the attributes and values of those commands that reflect the configuration of the BIG-IP system. Using the SCF feature, a user can define all BIG-IP configurations, including BIG-IP LTM and BIG-IP GTM objects and Linux configurations in a single file, using the tmsh utility. The SCF feature allows you to use an SCF file from one BIG-IP system to configure additional BIG-IP systems, and it is useful when you want to configure a new BIG-IP system. When you save a SCF file using the tmsh utility, the system prompts the tmsh utility to gather all of the commands (and their attributes and values) that compose the running configuration. Once gathered, the system saves the configuration to a flat file in the /var/local/scf/ directory with the name you specify and the extension of .scf. For example, the tmsh save /sys config file bigip1 command saves the currently running configuration to /var/local/scf/bigip1.scf. For information regarding the options available you can use the tmsh help sys config command. For example, if you want additional information regarding the user-only option, perform the following steps. 1. Log in to the Traffic Management Shell (tmsh) by entering the following command:

tmsh
Note: If you are currently logged in to the tmsh shell, you can skip this step. 2. Type the following command:

help /sys config

3. At the : prompt, type the following:

/user-only
4. Press the enter key and then press the n key to move to the next instances of the user-only option. Note: You can also navigate through the tmsh help using the Up or Down arrows on the keyboard. 5. Press the q key to exit from the tmsh command help. 6. To exit tmsh, type quit and then press the Enter key.

Note: Saving a configuration to an SCF does not affect the running or stored configuration of the BIG-IP system upon which you run the command. When you install an SCF file on a target BIG-IP system, the system first saves the currently running configuration to /var/local/scf/backup.scf, and then loads the specified SCF file into running memory. For example, the tmsh load /sys config file bigip1 command saves the currently running configuration to /var/local/scf/backup.scf before loading the /var/local/scf/bigip1.scf file on the system. Data contained in the SCF file The SCF file contains all of the BIG-IP configuration, including BIG-IP objects and the UNIX configuration. The following information is contained in an SCF file: All native BIG-IP LTM and GTM system configuration elements

The SCF file contains sufficient data to completely provision a BIG-IP LTM or BIG-IP GTM system from one file. Data from the following BIG-IP system files are contained in the SCF: o bigip.conf o bigip_base.conf o bigip_gtm.conf o bigip_user.conf Essential Linux configuration elements The SCF file contains essential Linux configuration elements. When you use the tmsh utility to modify the Linux configuration files on the BIG-IP system and then save an SCF file, the Linux configuration from the following files is saved to the SCF: o /etc/resolv.conf o /config/ssh/sshd_config o /config/ntp.conf o /etc/localtime o /etc/sysconfig/clock o /config/bigip/auth/pam.d/system-auth o /config/bigip/auth/pam.d/httpd o /config/httpd/conf/httpd.conf o /config/httpd/conf.d/ssl.conf o /var/run/config/httpd.conf.d/mod_auth_pam.conf o /etc/logrotate.conf o /etc/logrotate_common.conf o /etc/syslog-ng/syslog-ng.conf o /etc/hosts o /etc/sysconfig/network o /config/bigip/auth/userroles o /etc/hosts.allow o /config/snmp/snmpd.conf Data not contained in the SCF file: BIG-IP ASM configuration other than http class profiles Saving an SCF file 1. Log in to the Traffic Management Shell (tmsh) by entering the following command:
tmsh

Note: If you are currently logged in to the tmsh shell, you can skip this step. 2. To save the running configuration to an SCF file, use the following command syntax:

save /sys config file <name>

3. The SCF file is saved to the /var/local/scf/ directory. Installing an SCF file on the BIG-IP system 1. Log in to the Traffic Management Shell (tmsh) by entering the following command:

tmsh
2. To install an SCF file on a BIG-IP system, use the following command syntax:

load /sys config file <name>

3. Enter y at the below prompt to load the SCF file:
Replace the running configuration? (y/n)

Recommendations
General guidelines for using SCF files are as follows: Build a BIG-IP LTM template configuration by configuring a system using the Configuration utility or tmsh utility. Most custom Linux configuration must be completed using the tmsh utility. Save an SCF file from the fully-configured system using the tmsh save /sys command, and store the SCF file in a safe place for future use. The SCF file can be used as a template to configure future BIGIP systems. When you are ready to use the SCF file to configure a new BIG-IP system, copy the SCF file to the new BIG-IP system, and edit the SCF file prior to importing it. For example, change the IP addresses, routing information, and other common settings, as needed. Install the SCF file into a new system using the tmsh load /sys command. For more information, refer to SOL 14257: The BIG-IP local device trust may be corrupt after loading a single configuration file.

Introducing the single configuration file

The single configuration file feature allows you to save the configuration of a BIG-IP system in a single, flat, text file. You can then use the text file to easily replicate the configuration across multiple BIG-IP systems. This not only saves you time, but also allows you to create a consistent, secure, comprehensive local traffic management environment on your network.
Important

Before you begin working with the SCF feature, it is important to understand the two states of BIG-IP system configuration data: the stored configuration and the running configuration. For more information, see Chapter 5, Managing the BIG-IP System Configuration State.

What is a single configuration file?

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 configuration of the BIG-IP system. Specifically, the SCF contains the local traffic management and TMOS configuration of the BIG-IP system. Figure 6.1 shows a small part of a sample SCF.

Figure 6.1 Portion of a sample SCF

About the bigpipe utility and the single configuration file

You use the bigpipe utility to create and work with single configuration files. You create an SCF using the command export. When you run the command export, the bigpipe utility gathers all of the commands, (and their attributes and values), that compose the running configuration, and saves this configuration in a file with the extension.scf.(For additional information, see Creating a single configuration file, on page 6-4.) You then use the command import to apply the configuration contained in the SCF to another BIG-IP system. When you run the command import on a BIG-IP system, the bigpipe utility first saves the systems stored configuration in a backup file, and then resets the systems running configuration using the information contained in the SCF that you are importing. It is important to understand that to write the new running configuration to the systems stored configuration you must run the command save all after you run the command import.
WARNING

Never copy the contents of an SCF and paste it onto the command line to configure a system. Always use the import command to configure a system using an SCF, for example, import myconfiguration.scf. Tip If you create an SCF file twice (on two different occasions), you can compare the contents of the two files. To do this, you use the bigpipe config diff command.

About the bigpipe import command and backup files

As stated in the previous section, when you run the bigpipe import command on a BIG-IP system, the bigpipe utility first saves the systems running configuration in a backup file, named /var/local/scf/backup.scf. If a backup SCF already exists, the bigpipe utility appends a number to the name of the existing backup file, and then creates a new backup file. Thus: The first time the system backs up the running configuration during an import operation, the system names the backup file /var/local/scf/backup.scf. The next time the system backs up the running configuration, the system renames the file /var/local/scf/backup.scf to /var/local/scf/backup-1.scf. and creates a new file named /var/local/scf/backup.scf. If you import an SCF a third time, the system renames the file /var/local/scf/backup-1.scf to /var/local/scf/backup-2.scf, renames the file /var/local/scf/backup.scf to /var/local/scf/backup-1.scf, and once again creates a new file named /var/local/scf/backup.scf. By default, the system only saves two backup SCFs. You can configure the system to save a different number of backup files using the bigpipe cli import save <integer> command. For more information on using this command, see the Bigpipe Utility Reference Guide.

Understanding the bigpipe export, import, load, and save commands

You use the bigpipe commands export and import to create and work with an SCF. You use the bigpipe commands save and load to affect the running and stored configurations of the BIG-IP system. Table <x> compares the use of these four commands.
bigpipe Command Usage

bigpipe export

import

save all

load

Command Usage Use the export command to create an SCF that you can then use to configure another BIG-IP system using the import command. It is important to note that the export command does not affect the running or stored configurations of the BIG-IP system upon which you run the command; the export command simply saves the running configuration to an SCF. For more information about the parameters that you can use with the export command, see the Bigpipe Utility Reference Guide Use the import command to replace the entire running configuration of a BIG-IP system with the values in the SCF that you are importing. You must then use the save all command to write the running configuration to the stored configuration. For more information about the parameters that you can use with the import command, see the Bigpipe Utility Reference Guide Use the save all command to write the running configuration to the configuration files that contain the stored configuration. For example, if you add a new NTP server to your network, and then use the ntp command to configure that server on the BIG-IP system, you must then run the save all command to save this change to the stored configuration Important: When you want to save to the stored configuration changes that you make to the system F5 Networks recommends that you use the save all command . For more information about the parameters that you can use with the save command, see the Bigpipe Utility Reference Guide or the Traffic Management Shell (tmsh) Reference Guide Use the load command to replace the entire running configuration of a BIG-IP system with the values contained in the stored configuration. For example, when you use the bigpipe utility to make changes to the system, the running configuration contains those changes. If you decide that you do not want the running configuration to contain those changes, run the load comman For more information about the parameters that you can use with the load command, see the Bigpipe Utility Reference Guide or the Traffic Management Shell (tmsh) Reference Guide

Table <x> Comparison of the bigpipe commands export, import, save, and load

Creating a single configuration file

You use the command bigpipe export to create an SCF. This command saves the running configuration of the system in a flat, text file with a specified name and the extension .scf.
WARNING

The command bigpipe export is independent of, and distinct from, the command bigpipe save all command. The command bigpipe export does not save the running configuration into the configuration files that contain the stored configuration. To save the running configuration, you must use the bigpipe save all command. You use the command bigpipe export to create an SCF. When you use this command, the system by default creates a file (using a name that you specify) in the /var/local/scf directory. The system appends the specified file name with the .scf extension. However, if you use the .scf extension in the file name, the system does not add an additional extension. As an option, you can create an SCF in a location other than /var/local/scf, by specifying a different path name during the creation procedure.
Note

When you use the command bigpipe export, you can optionally specify the oneline attribute. The oneline attribute formats the contents of an SCF in a more compact way. For more information, see the Bigpipe Utility Reference Guide.

To create an SCF

1. Access the bigpipe shell. 2. Run the command export and include a name for the SCF, for example:
bp> export myConfiguration053107

The system creates the file, myConfiguration053107.scf, in the /var/local/scf directory. To create the SCF in another location, specify a full path for the file. For example, the command export /config/myConfiguration creates the SCF in the /config directory.

Restoring a BIG-IP system configuration using an SCF

The BIG-IP system ships with a default SCF. You can restore a BIG-IP system to either the factory default configuration or a previous configuration. When you restore the system to the factory default configuration, the management IP address and management default route are not reset to the default values. These settings remain the same. You can use either the command bigpipe import default or bigpipe import <file_name>.scf. These commands differ as follows: You use the command sequence bigpipe import default to restore a system to the factory default configuration. When you use this command, the system first saves the running configuration in the backup.scf file. Then, the system resets the local traffic management and the operating system configuration to the factory default configuration by loading the SCF, /defaults/defaults.scf. You can use the command sequence bigpipe import <file_name>.scf to change the configuration of a system using the values in the specified SCF. When you use this command, the system first saves the running configuration in the backup.scf file, and then resets the running configuration to the values contained in the specified SCF. You must then run the command sequence bigpipe save all to save the running configuration in the stored configuration files.
WARNING

The bigpipe import default command does not reset manually-modified bigdb database variables to their factory defaults. Therefore, F5 Networks recommends that you do not manually modify any of the bigdb database variables. Instead, use the bigpipe commands to change the system configuration.

To restore a system to the factory default configuration

1. Access the bigpipe shell. 2. Run the command sequence import default. The system saves the running configuration in the backup.scf file, and then resets the local traffic management and the operating system configuration to the factory default configuration by loading the SCF, /defaults/defaults.scf.
Note

The command sequence bigpipe import default does not reset the management IP address or the management default route back to the default values. These settings remain the same.

To restore a system to a previous configuration

1. Access the bigpipe shell. 2. Run the command sequence import <file name>.scf, using the name of the SCF that contains the configuration to which you want to restore the system. The system saves the running configuration in the backup file, and then resets the running configuration to the values contained in the specified SCF. 3. To save the running configuration to the stored configuration files, use the command sequence save all. The system saves the running configuration to the stored configuration files.

What is not being backed up?

<Describe whats not backed up in the UCS and SCF files. How can the Admin back up whats not captured in these files?> 3. Audit log of changes

<Do we want to describe setting up audit logs or are we talking only about the process or how to and when to audit any logs for maintenance purposes? Or both?>

Introducing BIG-IP system logging

Viewing and managing log messages is an important part of maintaining a BIG-IP system. Log messages inform you on a regular basis of the events that are happening on the system. Some of these events pertain to general events happening within the operating system, while other events are specific to the BIG-IP system, such as the stopping and starting of BIG-IP system services. The mechanism that the BIG-IP system uses to log events is the Linux utility syslog-ng. The syslog-ng utility is an enhanced version of the standard UNIX and Linux logging utility syslog. The types of events that the BIG-IP system logs are: System events System event messages are based on Linux events, and are not specific to the BIG-IP system. Packet filter events Packet filter messages are those that result from the implementation of packet filters and packet-filter rules. Local traffic events Local-traffic event messages pertain specifically to the local traffic management system. Audit events Audit event messages are those that the BIG-IP system logs as a result of changes to the BIG-IP system configuration. Logging audit events is optional.

Summarizing logging features

The logging mechanism on a BIG-IP system includes several features designed to keep you informed of system events in the most effective way possible: One of the primary features of the logging feature is its ability to log different types of events, ranging from Linux system events, to packet filtering events, to local traffic events. Through the BIG-IP system auditing feature, you can even track and report changes that users make to the BIG-IP system configuration, such as adding a virtual server or designating a device to be part of a redundant system. For more information, see Understanding log content, on page 23-2, and Understanding log types, on page 23-5. When setting up logging on the BIG-IP system, you can customize the logs by designating the minimum severity level, or log level, that you want the BIG-IP system to report when a type of event occurs. The minimum log level indicates the minimum severity level at which the BIG-IP system logs that type of event. For example, you can specify that, for any change a user makes to the bigdb database, the minimum severity level for which the BIG-IP system logs messages is Warning. This means that the BIG-IP system logs Warning and more severe messages such as Error and Critical messages, but not less severe ones such as Notice, Informational, or Debug messages. For more information, see Setting log levels, on page 23-9. You can also use the Configuration utility to search for a string within a log event, that is, filter the display of the log messages according to the string you provide. For more information, see Viewing and filtering log messages, on page 23-3. You can view historical logs using the Traffic Management shell (tmsh). For more information, see the Traffic Management Shell (tmsh) Reference Guide. Finally, you can log BIG-IP system events to a remote logging server. You do this by identifying the IP address or host name of the remote logging server, and creating an encrypted network connection, or tunnel, for sending log information to that remote server. For more information, see Configuring encrypted remote logging, on page 23-12.
Tip

You can also configure the system to send email or activate pager notification based on the priority of the logged event.

Understanding log content

The logs that the BIG-IP system generates include several types of information. For example, some logs show a timestamp, host name, and service for each event. Moreover, logs sometimes include a status code, while the audit log shows a user name and a transaction ID corresponding to each configuration change. All logs contain a 1-line description of each event. Table <x> lists the categories of information contained in the logs and the specific logs in which the information is displayed.

Information Type Timestamp. System Host name.

Explanation The time and date that the system logged the event message The host name of the system that logged the event message. Because this is typically the host name of the local machine, the appearance of a remote host name could be of interest. The service that generated the event. The status code associated with the event.Note that only events logged by BIG-IP system components, and not Linux system services, have status codes The description of the event that caused the system to log the message The name of the user who made the configuration change. Theidentification number of the configuration change A description of the configuration change that caused the system to log the message.

Log Type Packet Filter Local Traffic Audit System Packet Filter Local Traffic

Service Status code

System Packet Filter Local Traffic Packet Filter Local Traffic

Description User Name Transaction ID Event

System Packet filter Local traffic Audit Audit Audit

Table <x> Log information categories and their descriptions

Viewing and filtering log messages

Use the Configuration utility for an easy way to view the log files that the system generates. You can also control which messages the Configuration utility displays, by typing a search string. Note An alternate way to view and filter log messages is to use either the bigpipe utility or tmsh. For more information, see the Bigpipe Utility Reference Guide or the Traffic Management Shell (tmsh) Reference Guide.

Viewing standard log messages

On the BIG-IP system, you can use the Configuration utility to view standard system, packet filter, local traffic, or audit messages.

To view standard log messages

1. On the Main tab of the navigation pane, expand System, and click Logs. The Logs screen opens. 2. On the menu bar, click System, Packet Filter, Local Traffic, or Audit, depending on the type of log messages you want to view. This displays a list of this type of log message. 3. If you want to advance to another screen of messages, first locate the page list at the lower-right corner of the screen. You can either: Display the list and select a page number or Show All. Click the right arrow to advance to the next page of messages.

Viewing historical log files

You can view log files for a specific range of dates. To do this, you use the show log command within the sys module of the Traffic Management shell (tmsh). For more information, see the Traffic Management Shell (tmsh) Reference Guide.

Filtering log messages

By supplying a text string, you can filter the log messages to suit your needs.

To filter log messages based on a search string

1. On the Main tab of the navigation pane, expand System, and click Logs. The Logs screen opens. 2. On the menu bar, click System, Packet Filter, Local Traffic, or Audit, depending on the type of log messages you want to view. This displays log messages of the type you selected. 3. In the Search box (directly above the Timestamp column), type a string, optionally using the asterisk as a wildcard character.

4. Click Search. This displays only those messages containing the string you specified.

Auditing configuration changes

Audit logging is an optional feature that logs messages whenever a BIG-IP system object, such as a virtual server or a load balancing pool, is configured (that is, created, modified, or deleted). The BIG-IP system logs the messages for these auditing events in the file /var/log/ltm. Using the Configuration utility, you can display audit log messages. Table 23.4, on page 23-8, shows some sample audit log entries. In this example, the first entry shows that user Janet enabled the audit logging feature, while the second and third entries show that user Matt designated the BIG-IP system to be a redundant system with a unit ID of 1.
Timestamp Mon Feb 14 03:34:45 PST 2005 Mon Feb 14 03:35:06 PST 2005 Mon feb 14 03:35:06 PST 2005 User Name Janet Matt Transaction ID 79255-1 79609-1 Event DB_VARIABLE modified: name-config auditing DB_VARIABLE modified: name-failover.isredundant value-true DB_VARIABLE modified: name-failoer.unitid value-1

matt

79617

Table 23.4 Sample audit log entries There are three ways that objects can be configured: By user action By system action By loading configuration data Whenever an object is configured in one of these ways, the BIG-IP system logs a message to the audit log.

Setting log levels

Using the Configuration utility, you can set log levels on both local traffic and auditing events. For each type of local traffic event, you can set a minimum log level. The minimum log level indicates the minimum severity level at which the BIG-IP system logs that type of event. For more information, see Setting log levels for local traffic events, following. For auditing events, you can set a log level that indicates the type of event that the system logs, such as the user-initiated loading of BIG-IP system configurations, or system-initiated configuration changes. For more information, see Setting log levels for auditing events, on page 23-11.
Note

An alternate way to set log levels is to use either the bigpipe utility or tmsh. For more information, see the Bigpipe Utility Reference Guide or the Traffic Management Shell (tmsh) Reference Guide.

Setting log levels for local traffic events

For local traffic events, you can set a minimum log level. Thus, for different kinds of local traffic events, such as bigdb configuration events or events related to HTTP compression, you can set different minimum log levels. The log levels that you can set on certain types of events, ordered from highest severity to lowest severity, are: Emergency Alert Critical Error Warning Notice Informational Debug For example, if you set the minimum log level for bigdb events to Error, then the system only logs messages that have a severity of Error or higher for those events. If you retain the default minimum log level (Informational),

then the system logs all messages that have a severity of Informational or higher (that is, all messages except Debug messages). There are many different types of local traffic events for which you can set a minimum log level. Table 23.5, on page 23-10, shows the types of local traffic events and the minimum log levels that you can configure for them. Because not all log levels are available for every local-traffic event type, the table shows the specific log levels you can set on each event type. Following the table is the procedure for setting the minimum log level on a local traffic event type.
Local Traffic Event Type ARP/NDP BigDB HTTP HTTP Compression IP Layer 4 MCP Network Packet Velocity ASIC iRules SSL Traffic Management OS LIND CSYNCD CLUSTERID Available Minimum Log Levels Error, Warning, Notice, Informational, debug Critical, Error, Warning, Notice, Informational, Debug Error, debug Error, Debug Warning, Notice Notice, Informational, Debug Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug Critical, Error, warning, Notice, Informational, Debug Informational, Debug Error, Informational, Debug Error, Warning Emergency, Critical, Error, Notice, Informational Emergency, alert, Critical, Error, Warning, Notice, Informational, Debug Emergency, alert, Critical, Error, Warning, Notice, Informational, Debug Emergency, alert, Critical, Error, Warning, Notice, Informational, Debug Default Value Warning Warning Error Error Warning Notice Notice Warning Informational Informational Warning Notice Notice Notice Notice

Table 23.5 Local-traffic event types and their available log levels

To set a minimum log level for local traffic events

1. On the Main tab of the navigation pane, expand System, and click Logs. This opens the Logs screen. 2. On the menu bar, click Options. This displays the screen for setting minimum log levels on local traffic events. 3. In the Local Traffic Logging area of the screen, locate the event type for which you want to set a minimum log level. An example of an event type is HTTP Compression. 4. Select a minimum log level from the list. 5. Click Update.
Note

For more information on local traffic event types, see Logging local traffic events, on page 23-6.

Setting log levels for auditing events

An optional type of logging that you can enable is audit logging. Audit logging logs messages that pertain to configuration changes that users or services make to the BIG-IP system configuration. This type of audit logging is known as MCP audit logging. (For more information, see Auditing configuration changes, on page 23-7.) Optionally, you can set up audit logging for any bigpipe commands that users type on the command line. For both MCP and bigpipe audit logging, you can choose one of four log levels. In this case, the log levels do not affect the severity of the log messages; instead, they affect the initiator of the audit event. The log levels for MCP and bigpipe audit logging are: Disable This turns audit logging off. This is the default value. Enable This causes the system to log messages for user-initiated configuration changes only. Verbose This causes the system to log messages for user-initiated configuration changes and any loading of configuration data. Debug This causes the system to log messages for all user-initiated and system-initiated configuration changes.

To set a minimum log level for audit events

1. On the Main tab of the navigation pane, expand System, and click Logs. This opens the Logs screen. 2. On the menu bar, click Options.

This displays the screen for setting minimum log levels on local traffic events. 3. In the Audit Logging area of the screen, select a log level from the MCP list and from the bigpipe list. 4. Click Update.

Configuring encrypted remote logging

You can configure the syslog-ng utility on the BIG-IP system to send BIG-IP system log information to a remote logging host, using an encrypted network connection. To do this, you create a port-forwarding SSH tunnel to the remote logging host, and configure the syslog-ng utility on the BIG-IP system to send log messages through the SSH tunnel.

Before you begin

Before you attempt to configure encrypted remote logging, you must meet the following conditions on the BIG-IP system and your remote logging host: On the BIG-IP system You must have a console with root access to the BIG-IP system. On the remote logging host You must have a console with root access to the remote logging host, the IP address, or the host name of the remote logging host. For both systems You must have both systems connected to the same subnetwork.
WARNING

Attempt this configuration only if you understand the risks associated with making changes to daemon startup scripts.

Creating the remote encrypted logging configuration

When creating an encrypted remote logging configuration, you must complete the following tasks: Review the SSH syntax required to create this configuration. Create a unique SSH identity key to identify and authorize the BIG -IP system. Edit the syslog-ng utility startup script to create and destroy the SSH tunnels. Edit the remote logging host to accept syslog-ng messages through the SSH tunnel. Copy the unique SSH identity key to the remote logging host and append it to the authorized key file. Verify the logging configuration and restart the syslog-ng utility.

Reviewing the SSH syntax required to create this configuration

This configuration requires that the BIG-IP system is able to establish an SSH connection to the remote logging host. On the BIG-IP system, use the ssh command to create the tunnel. Figure 23.2 is an example of the syntax required to create an SSH tunnel. Table 23.6 contains detailed descriptions of the ssh syntax elements shown in Figure 23.2.

Creating an SSH key to identify and authorize the BIG-IP system

After you have reviewed the ssh command syntax, use the ssh command to create the encrypted tunnel on the BIGIP system. You must create a unique key on the BIG-IP system. The unique key is used to identify and authorize the BIG-IP system to the remote logging host. To create the file syslog_tunnel_ID and syslog_tunnel_ID.pub, use the following command sequence:
$ ssh -b 2048 -f syslog_tunnel_ID -t rsa -N "" -P ""

To make syslog_tunnel_ID readable only by the root account, use the following command sequence:
$ chmod 600 syslog_tunnel_ID

To make the public portion of the unique SSH ID named syslog_tunnel_ID.pub readable by all accounts, use the following command sequence:
$ chmod 644 syslog_tunnel_ID.pub

Copy syslog_tunnel_ID and syslog_tunnel_ID.pub into /var/ssh with the following command:
$ cp syslog_tunnel_ID* /var/ssh

Editing the syslog-ng start script to open and close the tunnel
Next, you must change the syslog-ng utility startup script, /etc/init.d/syslog-ng, so that the encrypted tunnel is opened when the syslog-ng script starts up, and is closed when the script is restarted or stopped. Before you edit the syslog-ng utility startup script, save a backup copy to the root directory. Use the following command to save the backup to the root directory:
$ cp /etc/init.d/syslog-ng /root/syslog-ng.backup

After you save a backup of the syslog-ng utility startup script, /etc/init.d/syslog-ng, edit it to automatically create SSH tunnels when the syslog-ng utility is started, or close the SSH tunnels when the syslog-ng utility is restarted or stopped. The example configuration in this document demonstrates how to create a tunnel to a host using the following IP addresses and ports: IP address of 10.0.0.100 Local tunnel port of 5140 Remote tunnel port of 5140 User name logger on host 10.0.0.100 Start by adding syntax below the line that reads start). Figure 23.3 is an example of what the section of the syslogng start script looks like after you add the new syntax. In this example, the syntax you need to add is shown with bold text.

Figure 23.3 The syntax to add below the start) line Next, add syntax below the line that reads stop). Figure 23.4 shows the syntax you need to add in bold text.

Figure 23.4 The syntax to add below the stop) line

Setting up message logging on a remote logging host

After you add the syntax to open and close SSH tunnels, you can modify the configuration of the syslog-ng utility to log messages to the remote machine. To do this, you need to create source and filter configuration blocks based on the local environment. Using the sample IP addresses and ports shown in the previous section, use the syslog command to set up the remote logging host.
tmsh modify sys syslog remote-servers add { server.foo.net { host 127.0.0.1 remote-port 514 }}

Copying the SSH identity to the remote logging host

After you have used the syslog command to set up the remote logging host to log messages, you must copy the unique SSH identity to the remote logging host. To do this, copy the syslog_tunnel_ID.pub identity to the remote syslog server, and append this key to the authorized_keys file found in the .ssh folder under the home directory of the user that you want to use to capture remote log messages.

$ cat syslog_tunnel_ID.pub >> ~logger/.ssh/authorized_keys

Verify that the logging facility is configured and ready to receive syslog-ng messages on the <remote tunnel port>. If the remote logging host uses the syslog-ng utility, you need to add a source configuration block such as the example shown in Figure 23.5.

Figure 23.5 Remote logging host source identification block In addition to the source identification block, you also need to add filter, destination, and log configuration blocks to use the data from the source remote as required by your application.

Verifying the logging configuration and restarting syslog-ng

Finally, verify that the SSH connection is functional and restart the syslog-ng utility.

To verify the configuration and restart the syslog-ng utility

1. Log on as root to the BIG-IP system. 2. Make an SSH connection to the remote logging host using the new identity key you created.
# ssh logger@10.0.0.100 -i /var/shh/syslog_tunnel_ID

If everything is configured correctly, you should be able to get shell access to the remote logging host without being challenged for a password. (When you add the new identity key to the remote host's authorized_keys file, the key is used to authenticate the BIG-IP system.) 3. Exit from the SSH session to the BIG-IP system command line. 4. Restart the syslog-ng utility by typing the following command:
$ /etc/init.d/syslog-ng restart

The BIG-IP system should now be sending log messages to your remote host.

Section 2: Monitoring
Chapter 9: Load
1. Memory a. Total Memory usage 1. What object identifier (OID) to monitor A. TMM Memory - why is in important/different B. Everything else C. Create a list of important numbers and make a tmsh command for it D. CLI memory mon E. Alternatives 1. XUI Graphs 2. iHealth G. Panic when it gets to 80% H. Monitor by blade I. Can this be upgraded? J. How does provisioning affect this?

1. If they tested a module and now it is unlicensed b. Swap stats 1. What OID to monitor 2. Is swapping allowed? 3. What is the threshold?

Chapter 10: CPU

b. Total 1. What OID to monitor 2. CLI/TMSH access to information 3. XUI Graphs 4. iHealth c. Should we care about individual CPUs? 1. What OIDs to monitor for each proc 2. How does provisioning affect this? 3. Break down by blade not CPU 4. CPU load should be relatively uniform across all CPUs A. info about CMP demotion and how it imbalances CPUs d. Trigger on processes that are at 100% CPU utilization

Chapter 11: Disk Utilization

1. How do various modules affect this?

Chapter 12: MySQL

1. Should this be monitored separately?

Chapter 13: Caches/DataStor

1. How do I flush this? 2. When should it be flushed? 3. Ramcache utilization 4. What OID to monitor

5. CLI/TMSH access to information 6. XUI Graphs 1 VCMP 7. Monitor each guest as an individual 8. Should the hypervisor also be monitored 1 AVR monitoring of the unit 9. Can this also be used for monitoring the box as opposed to monitoring the traffic through the box?

Chapter 14: Networking

1. Port stats a. What OID to monitor b. CLI/TMSH access to information c. Consider moving to a larger pipe when utilization to 75% 2. Interface status/info a. CLI/TMSH access to information b. What OID to monitor c. logfile 3. Trunk stats a. What OID to monitor b. CLI c. Internal trunks too? d. Traffic across trunks should be uniform e. Health of trunk/member stats f. Trigger on state changes 4. Connection stats a. What OID to monitor b. CLI c. AVR d. Alerts for over connection limits (rate limiting) e. Dropped connections 5. Dynamic routing peering information a. Looking glass functionality

Chapter 15: License compliance levels

1. SSL TPS 2. SSL certificate expiration dates a. Device certificate expiration b. Application (SSL Profile) certificate expiration 3. VE usage time/level

Chapter 16: Per iApp stats?

1. IRule Failures 2. LB failures 3. Fallback Rate

Chapter 17: Module-Specific Monitoring

1. APM a. Concurrent users

Verifying the health of APM tables in MySQL

You can run a few queries to verify the health of your APM tables in your local MySQL database. The following queries may be helpful when you are faced with overflowing APM session data and want to understand what is happening and how quickly the data is rolling over. Note: These commands were tested on 11.4.0 HF3. The APM session data is stored in six tables: log_data_0 log_data_1 log_data_2 log_data_3 log_data_4 log_data_current There is a master view, called log_data, that is the union of all of those tables. To log into MySQL: From the command line on a BIG-IP, run the following command: /usr/bin/mysql --user=root --password=`perl -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw`

Monitoring APM Session Records

The following procedure gives you an idea of how many session records are being retained by APM. Log entries are appended to the log_data_current table and then rolled off to one of the numbered tables as it fills up to the maximum log entries per table. The maximum is configured in /etc/logd.conf and is also available in the GUI under Access Policy | Reports | Preferences. To view the utilization of the tables as a whole: 1. From the command line on a BIG-IP, log into MySQL.

2.

Run the following query: select count(*) from log_data;

Viewing table size

To see the size of the data on disk thats being used for the data: 1. 2. From the command line on a BIG-IP, log into MySQL. Run the following queries: use information_schema; select table_name, round(((data_length + index_length) / (1024*1024)),2) as "size in MB" from information_schema.tables where table_schema = 'apm'; The process reports table size in MB for each of the tables on the disk.

2. ASM Can we adapt the topic, Verifying the Health of APM Tables in MySQL (provided by Jen at the Mayo Clinic) for the ASM module? If yes, please provide the queries.

Monitoring BIG-IP ASM through MySQL

You can use the following procedures to determine the status of the BIG-IP ASM process. If the database requires repair, see the procedure, Repairing the BIG -IP ASM MySQL database in the Ask F5 solution, SOL14194. Determining the status of the BIG-IP ASM process Verifying the MySQL status by reviewing database messages

Determining the status of the BIG-IP ASM process

As a first step, you can determine if the BIG-IP ASM process is running properly. To do so, perform the following procedure: 1. Log in to the command line of the affected BIG-IP ASM system. 2. Determine the status of the BIG-IP ASM process by entering the following command:
bigstart status asm

3. If the BIG-IP system fails to start due to the BIG-IP ASM MySQL database failure to start, the output from the command should appear similar to the following example:
asm down, waiting for mysqld to begin

Verifying MySQL status by reviewing database messages

You can verify if the BIG-IP ASM MySQL database failure to start is due to database corruption by reviewing the database log messages. To do so, perform the following procedure:

1. Log in to the command line of the affected BIG-IP ASM system. 2. Search for log messages indicating the starting of MySQL database in the /var/log/mysql.out file by entering the following command:
grep "Starting MySQL" /var/log/mysql.out

3. If the BIG-IP ASM MySQL database has failed to start due to database corruption, you may observe a log message that appears similar to the following example:
Starting MySQL... ERROR! Manager of pid-file quit without updating file.

3. GTM a. WIP Misses - fallback to BIND 4. WAM a. Cache Hit Rate 1. good list of OIDs here https://support.f5.com/kb/enus/products/wa/releasenotes/product/relnotes-wa-11-20.html#unique_1725603537

5. WOM a. Bandwidth usage b. Optimization percentage 6. PSM 7. Interfacing to external monitoring systems

Chapter 18: VIPRION

1. Always set up serial port a. That means per balde on a chassis 2. Always set up Admin port on a protected VLAN a. That means per blade on a chassis 3. SNMP a. Where are instructions to set it up b. Where are the OIDS c. What F5 custom OIDS are available

d. How to set up traps

Understanding F5-specific traps The alert system and the SNMP agent on the BIG-IP system can send a number of notifications about the current operation of the BIG-IP system. The definitions of these notifications are known as traps, and are contained in the MIB file F5-BIGIPCOMMON-MIB.txt. The types of notifications that the BIG-IP system can send to an SNMP manager are: General traps Hardware-related traps License-related traps Traffic Management Operating System (TMOS)-related traps Authentication-related traps Denial of Service (DoS)-related traps Network-related traps Logging-related traps Application Security Manager-related traps Other traps This section contains tables that list the trap names contained in the MIB file F5BIGIP-COMMON-MIB.txt, their descriptions, and the recommended action to take if you receive one of these notifications on your SNMP manager system. General traps The general notifications that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipAgentStart Description The SNMP agent on the BIGIP system has been started. The SNMP agent on the BIGIP system is in the process of being shut down. The SNMP agent on the BIGIP system has been restarted. The BIG-IP system configuration data was successfully loaded. Free space on the disk partition is limited, that is, less than a specified limit. By default, the limit is set to 30% of total disk space. The disk partition use exceeds the specified growth Recommended Action For your information only. No action required. For your information only. No action required.

bigipAgentShutdown

bigipAgent Restart

This trap is for future use only.

bigipConfigLoaded

For your information only. No action required.

bigipDiskPartitionWarn

Increase the available disk space.

bigipDiskPartitionGrowth

Increase the available disk space.

limit. By default, the limit is set to 5% of the total disk space

Table <x>: General traps and recommended settings Hardware-related traps The hardware-related notifications that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipCpuTempHigh Description The CPU temperature is too high. Recommended Action Check the CPU and air temperatures. For BIG-IP platforms C36, D39, D44, D45, D50, D51, D51C, and D62, the threshold is 75 degrees Celsius. For the BIG-IP platform C62, the threshold is 80 degrees Celsius. If the condition persists, contact f5 Networks technical support. Check the CPU temperature. If the CPU temperature is normal, the condition is not critical. For BIG-IP platforms C36, C62, D39, D44, D45, D50, D51, D51C, and D62, the threshold is 3000 RPM. Check the CPU temperature and verify that the CPU fan is plugged in and receiving power. If the CPU temperature is normal, the condition is not critical. Check the chassis and air temperatures. For BIG-IP platforms C36, D39, D44, D45, D50, D51, D51C, D62, and C62switchboard, the threshold is 75 degrees Celsius. For the BIG-IP platform C62 nonswitchboard, the threshold is 95 degrees Celsius for one chassis and 80 degrees Celsius for the other chassis. If the condition persists, contact F5 Networks technical support. Check the chassis temperature. Also check that the fan is receiving power, or replace the fan.

bigipCpuFanSpeedLow

The CPU fan speed is too low.

bigipCpuFanSpeedBad

The CPU fan is not receiving a signal.

bigipChassisTempHigh

The temperature of the chassis is too high.

bigipChassisFanBad

The chassis fan is not operating properly.

bigipChassisPowerSupplyBad

The chassis power supply is not functioning properly.

bigipHardDiskFailure

The hard disk is failing.

Verify that the power supply is plugged in, or contact F5 Networks technical support. For a dual-power-supply system, one power supply might not be plugged in. Power off the system and replace the hard disk. Contact F5 Networks technical support.

Table <x>: General traps and recommended actions

License-related traps The notifications related to licensing that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipLicenseFailed Description Validation of a BIG-IP system license has failed, or the dossier has errors. Occurs only when first licensing the system or adding a module key (such as HTTP compression) to an existing system. The BIG-IP license has expired. Recommended Action If using automatic licensing, verify connectivity to the outside world, fix the dossier if needed, and try again.

bigipLicenseExpired

Call F5 Networks technical support.

Table <x> License traps and recommended actions TMOS-related traps The TMOS-related notifications that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigIpNodeUp bigipStandby Description A Big-IP system health monitor has marked a node as up. The BIG-IP system has switched to standby mode. Recommended Action For your information only. No action required. Review the log files in the /var/logdirectory and then search for core files in the /var/coredirectory. If you find a core file, or find text similar to fault at location xxxx stack trace:, contact F5 Networks technical support. Investigate failover condition on the standby system. For your information only. No action required. For your information only. No action required. View high-availability processes and their current status using the BIG-IP system command bigpipe ha table. For more

bigipStandByFail

bigipActive bigipActiveActive bigipFeatureFailed

In failover condition, this standby system cannot become active. The BIG-IP system has switched to active mode. The BIG-IP system is in activeactive mode. A high-availability feature has failed.

bigipFeatureOnline

A high-availability feature is responding. The BIG-IP system has rejected some packets. Signifies that the TMM has run out of source ports and cannot open new communications channels with other machines.

information, see the Bigpipe Utility Reference Guide. For your information only. No action required. Check the detailed message within this trap and act accordingly. Either increase the number of addresses available for SNAT automapping or SNAT pools, or lower the idle timeout value if the value is excessively high.

bigipPacketRejected

bigipInetPortExhaustion

Table<x> TMOS-related traps and recommended actions

Authentication-related traps The notifications related to authentication that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipTamdAlert Description More than 60 authentication attempts have failed within one second, for a given virtual server. A login attempt failed. Recommended Action Investigate for a possible intruder.

bigipAuthfailed

Check the user name and password.

Table <x> Authentication traps and recommended actions

DoS-related traps The notifications related to denial of service that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipAggrReaperStateChange Description The state of the aggressive reaper has changed, indicating that the BIG-IP system is moving to a distress mode. Recommended Action We recommend that you use our default Denial of Service settings. However, you can add rate filters to survive the attack.

Table <x> Denial of Service traps and recommended actions Network-related traps The network-related notifications that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipARPConflict Description The BIG-IP system has detected an ARP advertisement for any of its own ARP-enabled addresses. This can occur for a virtual server address or a self IP address An interface link is down. This applies to L1 and L2, which are internal links within the box Recommended Action Check IP addresses and routes

bigipNetLinkDown

Contact F5 Networks technical support.

connecting the CPU and Switch subsystems. These links should never be down. If this occurs, the condition is serious.

Table <x> Network traps and recommended actions

Logging-related traps The notifications related to logging that you might receive on an SNMP manager system are listed and described in Table A.8.
Trap Name bigipLogEmerg Description The BIG-IP system is unusable. This notification occurs when the system logs a message with the log level LOG_EMERG. You must take action immediately for the BIG-IP system to function properly. This notification occurs when the system logs a message with the log level LOG_ALERT. The BIG-IP system is in a critical condition. This notification occurs when the system logs a message with the log level LOG_CRIT. The BIG-IP system has some error conditions. This notification occurs when the system logs a message with the log level LOG_ERR. The BIG-IP system is experiencing some warning conditions. This notification occurs when the system logs a message with the log level LOG_WARNING. Recommended Action Check the detailed message within this trap and within the /var/log files to determine which process has the emergency. Then act accordingly. Check the detailed message within this trap and within the /var/logfiles to determine which process has the alert situation. Then act accordingly. Check the detailed message within this trap and within the /var/log files to determine which process has the critical situation. Then act accordingly. Check the detailed message within this trap and within the /var/log files to determine which processes have the error conditions. Then act accordingly. Check the detailed message within this trap and within the /var/log files to determine which processes have the warning conditions. Then act accordingly.

bigipLogAlert

bigipLogCrit

bigipLogErr

bigipLogWarning

Table <x> Logging-related traps and recommended actions Note

You can also view logging information using the Logs screen of the Configuration utility. Application Security Manager-related traps The notifications related to Application Security Manager that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipAsmRequestBlocked Description The system blocked an HTTP request because the request contained at least one violation to the active security policy. The system issued an alert Recommended Action Check the HTTP request to determine the cause of the violation. Check the HTTP request to

bigipAsmRequestViolation

because an HTTP request violated the active security policy.

determine the cause of the violation

Other traps Other notifications that you might receive on an SNMP manager system are listed and described in Table <x>.
Trap Name bigipCompLimitExceeded Description The compression license limit is exceeded. The SSL license limit is exceeded, either for transactions per second (TPS) or for megabits per second (MPS). The status of an external interface link has changed to either DOWN or UP. This occurs when network cables are added or removed, and the network is reconfigured. Recommended Action Purchase additional compression licensing from F5 Networks. Purchase additional SSL licensing from F5 Networks.

bigipSslLimitExceeded

bigipExternalLinkChange

Determine whether the link should be down or up, and then take the appropriate action.

Table <x> Other traps and recommended actions 4. Remote syslog a. The difference between iRules log statemnets and HSL b. What is excessive logging and when remote logging is called for

Chapter 19: External APIs

1. iControl/pyControl a. Example for memory monitoring b. Example for traffic monitoring c. Example for Application monitoring 2. Remote TMSH

Chapter 20: Security

1. Monitoring a. Logins b. Failed logins c. Login statistics d. Who

e. When f. Role g. Syncheck activations h. Adaptive reaper activation i. ASM DoS? and anomaly detection?

Overview: Detecting and preventing web scraping

Web scraping is a technique for extracting information from web sites that often uses automated programs, or bots (short for web robots), opening many sessions, or initiating many transactions. You can configure Application Security Manager (ASM) to detect and prevent various web scraping activities on web sites that it is protecting. ASM provides the following methods to address web scraping attacks. These methods can work independently of each other, or work together to detect and prevent web scraping attacks.

Bot detection investigates whether a web client source is human by limiting the number of page changes allowed within a specified time. Session opening detects an anomaly when either too many sessions are opened from an IP address or when the number of sessions exceeds a threshold from an IP address. Also, session opening can detect an attack when the number of inconsistencies or session resets exceeds the configured threshold within the defined time period. This method also identifies as an attack an open session that sends requests that do not include an ASM cookie. Session transactions anomaly captures sessions that request too much traffic, compared to the average amount observed in the web application. This is based on counting the transactions per session and comparing that to the average amount observed in the web application.

The BIG-IP system can accurately detect such anomalies only when response caching is turned off. Task Summary Prerequisites for configuring web scraping For web scraping detection to work properly, you should understand the following prerequisites:

The web scraping mitigation feature requires that the DNS server is on the DNS lookup server list. Go to System > Configuration > Device > DNS to see if the DNS lookup server is on the list. If not, add it and restart the system. Client browsers need to have JavaScript enabled, and support cookies for anomaly detection to work.

Consider disabling response caching. If response caching is enabled, the system does not protect cached content against web scraping. The Application Security Manager does not perform web scraping detection on legitimate search engines traffic. If your web application has its own search engine, we recommend you add it to the system. Go to Security > Options > Application Security > Advanced Configuration > Search Engines and add it to the list.

Detecting web scraping based on bot detection You can mitigate web scraping on the web sites Application Security Manager defends by attempting to determine whether a web client source is human or a web robot. The bot detection method also protects web applications against rapid surfing by measuring the amount of time allowed to change a number of web pages before the system suspects a bot. 1. On the Main tab, click Security > Application Security > Anomaly Detection > Web Scraping. The Web Scraping screen opens. 2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on. 3. For the Bot Detection setting, select either Alarm or Alarm and Block to indicate how you want the system to react when it detects that a bot is sending requests to the web application. If you choose Alarm and Block, the security policy enforcement mode needs to be set to Blocking before the system blocks web scraping attacks. Note: The system can accurately detect a human user only if clients have JavaScript enabled and support cookies in their browsers. The screen displays the Bot Detection tab and more settings. 4. If you want to protect client identification data (when using Bot Detection or Session Opening detection), specify the persistence settings. a. Select the Persistent Client Identification check box. b. For Persistent Data Validity Period, type how long you want the client data to persist in minutes. The default value is 120 minutes. Note: This setting enforces persistent storage on the client and prevents easy removal of client data. Be sure that this behavior is compatible with the application privacy policy. The system maintains client data and prevents removal of this data from persistent storage for the validity period specified. 5. For the IP Address Whitelist setting, add the IP addresses and subnets from which traffic is known to be safe. Important: The system adds any whitelist IP addresses to the centralized IP address exceptions list. The exceptions list is common to both brute force prevention and web scraping detection configurations.

6. On the Bot Detection tab, for the Rapid Surfing setting, specify the maximum number of web pages that can be changed in the specified number of seconds before the system suspects a bot. The default value is Maximum 5 page changes per 1000 milliseconds. 7. For Grace Interval, type the number of requests to allow while determining whether a client is human. The default value is 100. 8. For Unsafe Interval, type the number of requests that cause the Web Scraping Detected violation if no human activity was detected during the grace period. The default value is 100. Reaching this interval causes the system to reactivate the grace period. 9. For Safe Interval, type the number of requests to allow after human activity is detected, and before reactivating the grace threshold to check again for non-human clients. The default value is 2000. 10. Click Save to save your settings. 11. To put the security policy changes into effect immediately, click Apply Policy. The system checks for rapid surfing and if too many pages are changed too quickly, it logs Web Scraping detected violations in the event log, and specifies the attack type of bot detection. After setting up bot detection, you can also set up session opening and session transactions anomaly detection for the same security policy. Detecting web scraping based on session opening You can configure how the system protects your web application against session opening web scraping violations that result from too many sessions originating from a specific IP address, inconsistencies detected in persistent storage, and the number of session resets exceeds the threshold. 1. On the Main tab, click Security > Application Security > Anomaly Detection > Web Scraping. The Web Scraping screen opens. 2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on. 3. For the Session Opening setting, select either Alarm or Alarm and Block to indicate how you want the system to react when it detects a large increase in the number of sessions opened from a. specific IP address, or when the number of session resets or inconsistencies exceeds the set threshold. If you choose Alarm and Block, the security policy enforcement mode needs to be set to Blocking before the system blocks web scraping attacks. The screen displays the Session Opening tab and more settings. 4. If you want to protect client identification data (when using Bot Detection or Session Opening detection), specify the persistence settings. a. Select the Persistent Client Identification check box. b. For Persistent Data Validity Period, type how long you want the client data to persist in minutes. The default value is 120 minutes. Note: This setting enforces persistent storage on the client and prevents easy removal of client data. Be sure that this behavior is compatible with the application privacy policy. The system maintains client data and prevents removal of this data from persistent storage for the validity period specified.

5. For the IP Address Whitelist setting, add the IP addresses and subnets from which traffic is known to be safe. Important: The system adds any whitelist IP addresses to the centralized IP address exceptions list. The exceptions list is common to both brute force prevention and web scraping detection configurations. 6. To detect session opening anomalies by IP address, on the Session Opening tab, select the Session Opening Anomaly check box and adjust the settings. 7. For the Prevention Policy setting, select one or more options to direct how the system should handle a session opening anomaly attack. Option Client Side Integrity Defense Rate Limiting Description When enabled, the system determines whether a client is a legitimate browser or an illegal script by sending a JavaScript challenge to each new session request. Legitimate browsers can respond to the challenge; scripts cannot. When enabled, the system drops sessions from suspicious IP addresses after determining that the client is an illegal script. If you select this option, the screen displays an option for dropping requests from IP addresses with a bad reputation.

When enabled, the system drops requests originating from IP addresses Drop IP Addresses with that are in the systems IP address intelligence database when the bad reputation attack is detected; no rate limiting will occur. (Attacking IP addresses that do not have a bad reputation undergo rate limiting, as usual.) This option is available only if you have enabled rate limiting. You also need to set up IP address intelligence, and at least one of the IP intelligence categories must have its Alarm flag enabled. 8. For the Detection Criteria setting, specify the criteria under which the system considers traffic to be a session opening anomaly attack. Option Sessions opened per second increased by Sessions opened per second reached Minimum sessions opened per second threshold for detection Description The system considers traffic to be an attack if the number of sessions opened per second increased by this percentage. The default value is 500%. The system considers traffic to be an attack if the number of sessions opened per second is equal to or greater than this number. The default value is 50 sessions opened per second. The system only considers traffic to be an attack if this value plus one of the sessions opened values is exceeded. The default value is 25 sessions opened per second.

9. Note: The Detection Criteria values all work together. The minimum sessions value and one of the sessions opened values must be met for traffic to be considered an attack. However, if the minimum sessions value is not reached, traffic is never considered an attack even if the Sessions opened per second increased by value is met. 10. For Prevention Duration, type a number that indicates how long the system prevents an anomaly attack by logging or blocking requests. The default is 1800 seconds. If the attack ends before this number of seconds, the system also stops attack prevention. 11. If you enabled Persistent Client Identification and you want to detect session opening anomalies based on inconsistencies, select the Device Identification Integrity check box, and set the maximum number of integrity faulty events to allow within a specified number of seconds. The system tracks the number of inconsistent device integrity events within the time specified, and if too many events occurred within the time, a Web scraping detection violation occurs. 12. If you enabled Persistent Client Identification and you want to track cookie deletion events, select the Cookie Deletion Detection check box, and set the maximum number of cookie deletions to allow within a specified number of seconds. The system tracks the number of cookie deletion events that occur within the time specified, and if too many cookies were deleted within the time, a Web scraping detection violation occurs. 13. For Prevention Duration, type a number that indicates how long the system prevents an anomaly attack by logging or blocking requests. The default is 1800 seconds. If the attack ends before this number of seconds, the system also stops attack prevention. 14. Click Save to save your settings. 15. To put the security policy changes into effect immediately, click Apply Policy. The system checks for too many sessions being opened from one IP address, too many cookie deletions, or persistent storage inconsistencies. The system logs violations in the web scraping event log along with information about the attack including whether it is a Session Opening Anomaly by IP Address or Session Resets by Persistent Client Identification attack type and when it began and ended. The log also includes the type of violation (Device Identification Integrity or Cookie Deletion Detection) and the violation numbers. After setting up session opening detection, you can also set up bot detection and session transactions anomaly detection for the same security policy. Detecting web scraping based on session transactions You can configure bot detection to specify how the system protects your web application from being harvested by non-human web robots. Bot detection settings define when to consider that multiple requests may have been initiated by web robots. 1. On the Main tab, click Security > Application Security > Anomaly Detection > Web Scraping. The Web Scraping screen opens. 2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on. 3. For the Session Transactions Anomaly setting, select either Alarm or Alarm and Block to indicate how you want the system to react when it detects a large increase in the number of transactions per session. If you choose Alarm and Block, the security policy enforcement mode needs to be set to Blocking before the system blocks web scraping attacks. The screen displays the Session Transactions Anomaly tab and more settings .

4. For the IP Address Whitelist setting, add the IP addresses and subnets from which traffic is known to be safe. Important: The system adds any whitelist IP addresses to the centralized IP address exceptions list. The exceptions list is common to both brute force prevention and web scraping detection configurations. 5. For the Detection Criteria setting, specify the criteria under which the system considers traffic to be a session transactions anomaly attack. Option Session transactions increased by Sessions transactions reached Minimum session transactions threshold for detection Description The system considers traffic to be an attack if the number of transactions per session increased by this percentage. The default value is 500%. The system considers traffic to be an attack if the number transactions per sessions is equal to or greater than this number. The default value is 400 transactions. The system considers traffic to be an attack only if the number of transactions per session is equal to or greater than this number, and at least one of the sessions transactions numbers was exceeded. The default value is 200 transactions.

6. Note: The Detection Criteria values all work together. The minimum sessions value and one of the sessions transactions values must be met for traffic to be considered an attack. However, if the Minimum session transactions threshold is not reached, traffic is never considered an attack even if the Sessions transactions increased by value is met. 7. For Prevention Duration, type a number that indicates how long the system prevents an anomaly attack by logging or blocking requests. The default is 1800 seconds. If the attack ends before this number of seconds, the system also stops attack prevention. 8. Click Save to save your settings. 9. To put the security policy changes into effect immediately, click Apply Policy. When the system detects a session that requests too many transactions (as compared to normal), all transactions from the attacking session cause the Web Scraping detected violation to occur until the end of attack or until the prevention duration expires. Displaying web scraping event logs You can display event logs to see whether web scraping attacks have occurred, and view information about the attacks. 1. On the Main tab, click Security > Event Logs > Application > Web Scraping Statistics. The Web Scraping Statistics event log opens. 2. If the log is long, you can filter the list by security policy and time period to show more specific entries.

3. Review the list of web scraping attacks to see the web scraping attack type that occurred, the IP address of the client that caused the attack, which security policy detected the attack, and the start and end times of the attack. 4. Examine the web scraping statistics shown, and click the attack type links to see what caused the attack. 5. To learn more about the requests that caused the web scraping attack, click the number of violating requests. The Requests screen opens where you can investigate the requests that caused the web scraping attacks. Web scraping statistics figure This figure shows a Web Scraping Statistics event log where a persistent storage violation occurred. You can click the attack type to view additional details about the cause of the attack (as shown in the figure).

Web scraping statistics screen The figure shows that a web scraping attack occurred on 2-19-2013 from 10:08 to 10:13. It was caused by too many session resets (more than 10 in 93 seconds) and inconsistencies (more than 3 in 60 seconds). Web scraping attack types Web scraping statistics specify the attack type so you have more information about why the attack occurred. This shows the web scraping attack types that can display in the web scraping event log. Attack Type Bot Detection Description Indicates that the system suspects that the web scraping attack was caused by a web robot.

Attack Type Session Opening Anomaly by IP

Description Indicates that the web scraping attack was caused by too many sessions being opened from one IP address. Click the attack type link to display the number of sessions opened per second from the IP address, the number of legitimate sessions, and the attack prevention state. Indicates that the web scraping attack was caused by too many session resets or inconsistencies occurring within a specified time. Click the attack type link to display the number of resets or inconsistencies that occurred within a number of seconds. Indicates that the web scraping attack was caused by too many transactions being opened during one session. Click the attack type link to display the number of transactions detected on the session. Indicates that there are more JavaScript injections than JavaScript replies. Click the attack type link to display the detected injection ratio and the injection ratio threshold. Note: You cannot configure the Transparent Mode CS injection ratio values. This attack type can occur only when the security policy is in Transparent mode.

Session Resets by Persistent Client Identification Transactions per session anomaly Transparent Mode CS injection ratio

Viewing web scraping statistics Before you can look at the web scraping attack statistics, you need to have configured web scraping protection. You can display charts that show information about web scraping attacks that have occurred against protected applications. 1. On the Main tab, click Security > Reporting > Application > Web Scraping Statistics. The Web Scraping Statistics screen opens. 2. From the Time Period list, select the time period for which you want to view information about web scraping attacks. 3. If you want to export the report to a file or send it by email, click Export and select the options. To send reports by email, you need to specify an SMTP configuration (System > Configuration > Device > SMTP). The statistics show the total number of web scraping attacks, violations and rejected requests that occurred. You can review the details about the attacks and see that mitigation is in place. Implementation Result When you have completed the steps in this implementation, you have configured the Application Security Manager to protect against web scraping. Depending on your configuration, the system detects web scraping attacks based on bot detection, session opening violations, or session transaction violations.

After traffic is flowing to the system, you can check whether web scraping attacks are being logged or prevented, and investigate them by viewing web scraping event logs and statistics. If you chose alarm and block for the web scraping configuration and the security policy is in the blocking operation mode, the system drops requests that cause the Web scraping detected violation. If you chose alarm only (or the policy is in the transparent mode), web scraping attacks are logged only but not blocked.

About configuring the BIG-IP system to detect DNS DoS attacks

DNS DoS protection is enabled with the BIG-IP Protocol Security Manager.<this isnt ASM but its PSMstill something we should include?> DNS attack detection and prevention serves two functions:

To detect and automatically drop DNS packets that are malformed or contain errors. To log unusual increases in DNS packets of any type, including packets that are malformed, packets that contain errors, or packets of any other type that appear to rapidly increase.

You can use the DNS DoS Protection profile to configure the percentage increase over the system baseline, which indicates that a possible attack is in process on a particular DNS query type, or an increase in anomalous packets. Later, you can use reporting or logging functions to detect such packets, and you can use the DNS Security profile to drop packets with specific query types or header opcodes. Task summary Detecting and protecting against DNS denial-of-service attacks with a DoS profile In this task, you create the DoS Protection profile and configure DNS settings at the same time. However, you can configure DNS attack settings in a DoS profile that already exists. The BIG-IP system handles DNS attacks that use malformed packets, protocol errors, and malicious attack vectors. Protocol error attack detection settings detect malformed and malicious packets, or packets that are employed to flood the system with several different types of responses. You can configure settings to identify DNS attacks with a DoS profile. 1. 2. 3. 4. 5. On the Main tab, click Security > DoS Protection. The DoS Profiles list screen opens. Click Create. The Create New DoS Profile screen opens. In the Profile Name field, type the name for the profile. To configure DNS security settings, next to Protocol Security (DNS), select Enabled. To enable attack detection based on the rate of protocol errors, next to Protocol Errors Attack Detection, select Enabled. 6. In the Rate Increased by % field, type the rate of change in protocol errors to detect as anomalous. The rate of detection compares the average rate over the last minute to the average rate over the last hour. For example, the 500% base rate would indicate an attack if the average rate for the previous hour was 100000 packets/second, and over the last minute the rate increased to 500000 packets/second.

7. To change the threshold or rate increase for a particular DNS query type, in the DNS Query Attack Detection area, select the Enabled check box for each query type that you want to change, then change the values for Threshold and Rate Increase in the associated fields. For example, to change the threshold for IPv6 address requests, select the Enabled check box next to aaaa, then set the threshold for packets per second and the rate increase percentage to be considered an attack. The Rate Increase compares the average rate over the last minute to the average rate over the last hour. For example, the 500% base rate would indicate an attack if the average rate for the previous hour was 100000 packets/second, and over the last minute the rate increased to 500000 packets/second. Note: DNS Query Attack Detection allows you to configure the thresholds at which the firewall registers an attack. However, no packets are dropped if an attack is detected. 8. Click Update to save your changes. You have now configured a DoS Protection profile to provide custom responses to malformed DNS attacks, and DNS flood attacks, and to allow such attacks to be identified in system logs and reports. Associate the DoS Protection profile with a virtual server to apply the settings in the profile to traffic on that virtual server. When a DNS attack on a specific query type is detected, you can configure the DNS security profile to drop packets of a query type that appears to be an attack vector. Associating a DoS profile with a virtual server You must first create a DoS profile separately, to configure denial-of-service protection for applications, the DNS protocol, or the SIP protocol. You add denial-of-service protection to a virtual server to provide enhanced protection from DoS attacks, and track anomalous activity on the BIG-IP system. 1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens. 2. Click the name of the virtual server you want to modify. 3. For the Destination setting, select Host and in the Address field, type the IP address for the virtual server. 4. From the Security menu, choose Policies. 5. To enable denial-of-service protection, from the DoS Protection Profile list, select Enabled, and then, from the Profile list, select the DoS profile to associate with the virtual server. 6. Click Update to save the changes. DoS protection is now enabled, and the DoS Protection profile is associated with the virtual server.

What is a DoS attack?

A denial-of-service attack (DoS attack) makes a computer resource unavailable to its intended users, or obstructs the communication media between the intended users and the victim so that they can no longer communicate adequately. Perpetrators of DoS attacks typically target sites or services, such as banks, credit card payment gateways, and e-commerce web sites. Denial-of-service attacks are also known as HTTP-GET attacks or page flood attacks. HTTP-GET attacks The attacks are initiated either from a single user (single IP address) or from thousands of computers (distributed DoS attack), which overwhelms the target system. Page flood attacks Page flood attacks (or HTTP flood attacks) may resemble the patterns of normal web surfing, making it harder for automated tools to differentiate between legitimate web traffic and an attempted attack.

About recognizing DoS attacks

Application Security Manager determines that traffic is a DoS attack based on calculations for transaction rates on the client side (TPS-based) or latency on the server side (latency-based). You can specify the calculations that you want the system to use. Note: You can set up both methods of detection to work independently or you can set them up to work concurrently to simultaneously detect attacks on both the client side and server side. You can view details about DoS attacks that the system detected and logged. You can also configure remote logging support for DoS attacks when creating a logging profile.

About configuring TPS-based DoS protection

When setting up DoS protection, you can configure the system to prevent DoS attacks based on transaction rates (TPS-based anomaly detection). If you choose TPS-based anomaly protection, the system detects DoS attacks from the client side using the following calculations: Transaction rate during detection interval The average number of requests per second sent for a specific URL, or by a specific IP address. Every second, the system calculates the average TPS for the last minute. Note: The averages for IP address and URL counts are done for each virtual server, not each DoS L7 profile, in case one DoS L7 profile is assigned to more than one virtual server. Transaction rate during history interval The average number of requests per second sent for a specific URL, or by a specific IP address. The system calculates this number every minute.

If the ratio of the transaction rate during the detection interval to the transaction rate during the history interval is greater than the percentage indicated in the TPS increased by setting, the system considers the URL to be under attack, or the IP address to be suspicious.

About configuring latency-based DoS protection

When setting up DoS protection, you can configure the system to prevent DoS attacks based on server latency (latency-based anomaly detection). If you choose latency-based anomaly protection, the system detects DoS attacks from the server side using the following calculations: Latency during detection interval The average time it takes for the system to respond to a request for a specific URL over the last minute. The system calculates this number every second. Note: The averages for IP address and URL counts are done for each virtual server, not each DoS L7 profile, in case one DoS L7 profile is assigned to more than one virtual server. Latency during history interval The average time it takes for the system to respond to a request for a specific URL over the last hour. The system calculates this number every minute. If the ratio of the latency during the detection interval to the latency during the history interval is greater than the percentage in the Latency increased by setting, the system detects that this URL is under attack.

Overview: Preventing DoS attacks for Layer 7 traffic

You can configure the Application Security Manager to protect against L7 DoS attacks. Depending on your configuration, the system detects DoS attacks based on transactions per second (TPS) on the client side, or server latency, or both. You configure DoS protection for Layer 7 by creating a DoS profile with Application Security enabled. You then associate the DoS profile with one or more virtual servers representing applications that you want to protect. DoS protection is not part of a security policy. Task Summary Configuring Layer 7 DoS protection You can configure Application Security Manager to mitigate DoS attacks and increase system security. 1. 2. 3. 4. On the Main tab, click Security > DoS Protection. The DoS Profiles list screen opens. Click Create. The Create New DoS Profile screen opens. In the Profile Name field, type the name for the profile. Select the Application Security check box. The screen refreshes and displays additional configuration settings. 5. If you have written an application DoS iRule to specify how the system handles a DoS attack and recovers afterwards, you may select the Trigger iRule setting.

6. If you want to set up DoS protection from the client side, in the TPS-based Anomaly area, select an Operation Mode and set up TPS-based DoS protection. Another task describes how to configure the settings. 7. If you want to set up DoS protection from the server side, in the Latency-based Anomaly area, select an Operation Mode and set up latency-based DoS protection. Another task describes how to configure the settings. 8. To omit certain addresses, for the IP Address Whitelist setting, type IP addresses or subnets that do not need to be examined for DoS attacks, and click Add. Note: You can add up to twenty IP addresses. 9. Click Finished to save the DoS profile. You have created a DoS profile. Next, configure TPS-based or latency-based DoS protection settings, or both. Configuring TPS-based DoS protection settings You can configure Application Security Manager to mitigate DoS attacks based on transaction rates using TPS-based DoS protection. 1. On the Main tab, click Security > DoS Protection. The DoS Profiles list screen opens. 2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens. 3. Select the Application Security check box. The screen refreshes and displays additional configuration settings. 4. In the TPS-based Anomaly area, for Operation Mode, select an operation mode. Option Description

Transparent Displays information about DoS attacks on the DoS: Application reporting screen but does not block requests. Blocking Drops connections coming from an attacking IP address and requests to attacked URLs. Also displays information about DoS attacks on the DoS: Application reporting screen.

5. The screen refreshes to display additional configuration settings when you select an operation mode. 6. For the Prevention Policy setting, select one or more options to determine how the system handles a DoS attack. Note: If you enable more than one option, the system uses the options in the order in which they are listed. Option Source IPDescription Determines whether a client is a legal browser or an illegal script by

Option Based ClientSide Integrity Defense URL-Based Client-Side Integrity Defense

Description injecting JavaScript into responses when suspicious IP addresses are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled. Determines whether a client is a legal browser or an illegal script by injecting JavaScript into responses when suspicious URLs are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. The default is disabled. Drops requests from suspicious IP addresses. The system limits the rate of requests to the average rate prior to the attack, or lower than the absolute threshold specified by the IP detection TPS reached setting. The default is enabled. Indicates that when the system detects a URL under attack, Application Security Manager drops connections to limit the rate of requests to the URL to the average rate prior to the attack. The default is enabled.

Source IPBased Rate Limiting URL-Based Rate Limiting

7. For IP Detection Criteria, modify the threshold values as needed. Note: This setting appears only if Prevention Policy is set to Source IP-Based Client Side Integrity Defense and/or Source IP-Based Rate Limiting. If any of these criteria is met, the system handles the attack according to the Prevention Policy settings. Option TPS increased by TPS reached Description Specifies that the system considers an IP address to be that of an attacker if the transactions sent per second have increased by this percentage. The default value is 500%. Specifies that the system considers an IP address to be suspicious if the number of transactions sent per second from an IP address equals, or is greater than, this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by value. The default value is 200 TPS.

Minimum TPS Specifies that the system considers an IP address to be an attacker if Threshold for the detected TPS for a specific IP address equals, or is greater than, this

Option detection

Description number, and the TPS increased by number was reached. The default setting is 40 transactions per second.

Tip: Click the Set default criteria link to reset these settings to their default values. 8. For the Prevention Duration setting, specify the length of time for which the system mitigates DoS attacks: o To perform attack prevention until the system detects the end of the attack, select Unlimited. o To limit the amount of time for attack prevention, select Maximum and type a value, in seconds. The system prevents detected DoS attacks for the time configured here (even if the attack is still occurring), or until the system detects the end of the attack, whichever is sooner. 9. Click Update to save the DoS profile. You have now configured a DoS profile to prevent DoS attacks based on the client side (TPSbased Detection Mode). Next, you need to associate the DoS profile with the applications virtual server. Configuring latency-based DoS protection You can configure Application Security Manager to mitigate Layer 7 DoS attacks based on server latency. 1. On the Main tab, click Security > DoS Protection. The DoS Profiles list screen opens. 2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens. 3. Select the Application Security check box. The screen refreshes and displays additional configuration settings. 4. In the Latency-based Anomaly area, for Operation Mode, select an operation mode. Option Description

Transparent Displays information about DoS attacks on the DoS: Application reporting screen but does not block requests. Blocking Drops connections coming from an attacking IP address and requests to attacked URLs. Also displays information about DoS attacks on the DoS: Application reporting screen.

5. The screen refreshes to display additional configuration settings when you select an operation mode. 6. For Detection Criteria, modify the threshold values as needed. If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.

Option Latency increased by Latency reached

Description Specifies that the system considers traffic to be an attack if the minimum latency threshold was reached and the latency has increased by this percentage. The default value is 500%. Specifies that the system considers traffic to be an attack if the latency is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases latency gradually, the increase might not exceed the Latency Increased by threshold and would not be detected. If server latency reaches the Latency reached value, the system considers traffic to be an attack even if it did not meet the Latency increased by value. The default value is 10000 ms. Specifies that the system considers traffic to be an attack if the detection interval for a specific URL equals, or is greater than, this number, and at least one of the Latency increased by numbers was reached. The default setting is 200 ms.

Minimum Latency Threshold for detection

7. Tip: Click the Set default criteria link to reset these settings to their default values. 8. For the Prevention Policy setting, select one or more options to determine how the system handles a DoS attack. Note: If you enable more than one option, the system uses the options in the order in which they are listed. Option Source IPBased ClientSide Integrity Defense URL-Based Client-Side Integrity Defense Description Determines whether a client is a legal browser or an illegal script by injecting JavaScript into responses when suspicious IP addresses are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled. Determines whether a client is a legal browser or an illegal script by injecting JavaScript into responses when suspicious URLs are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. The default is disabled. Drops requests from suspicious IP addresses. The system limits the rate of requests to the average rate prior to the attack, or lower than the absolute threshold specified by the IP detection TPS reached setting. The default is enabled. Indicates that when the system detects a URL under attack, Application Security Manager drops connections to limit the rate of requests to the URL to the average rate prior to the attack. The default

Source IPBased Rate Limiting URL-Based Rate Limiting

Option

Description is enabled.

9. For Suspicious IP Criteria, modify the threshold values as needed. Note: This setting appears only if Prevention Policy is set to Source IP-Based Client Side Integrity Defense and/or Source IP-Based Rate Limiting. Option TPS increased by TPS reached Description Specifies that the system considers an IP address to be that of an attacker if the transactions sent per second have increased by this percentage. The default value is 500%. Specifies that the system considers an IP address to be suspicious if the number of transactions sent per second from an IP address equals, or is greater than, this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by value. The default value is 200 TPS.

Minimum TPS Specifies that the system considers an IP address to be an attacker if Threshold for the detected TPS for a specific IP address equals, or is greater than, this number, and the TPS increased by number was reached. The default detection setting is 40 transactions per second. If any of these criteria is met, the system handles the attack according to the Prevention Policy settings. 10. For Suspicious URL Criteria, modify the threshold values as needed. Note: This setting appears only if Prevention Policy is set to URL-Based Client Side Integrity Defense and/or URL-Based Rate Limiting. Option TPS increased by TPS reached Description Specifies that the system considers a URL to be that of an attacker if the transactions sent per second sent to the URL have increased by this percentage. The default value is 500%. Specifies that the system considers a URL to be suspicious if the number of transactions sent per second to the URL is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually,

Option

Description the increase might not exceed the TPS increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by value. The default value is 1000 TPS.

Minimum TPS Specifies that the system considers a URL to be an attacker if the Threshold for detected TPS for a specific URL equals, or is greater than, this number, and the TPS increased by number was reached. The default setting is detection 40 transactions per second. If any of these criteria is met, the system handles the attack according to the Prevention Policy settings. 11. For the Prevention Duration setting, specify the length of time for which the system mitigates DoS attacks: o To perform attack prevention until the system detects the end of the attack, select Unlimited. o To limit the amount of time for attack prevention, select Maximum and type a value, in seconds. The system prevents detected DoS attacks for the time configured here (even if the attack is still occurring), or until the system detects the end of the attack, whichever is sooner. 12. Click Update to save the DoS profile. You have now configured a DoS profile to prevent DoS attacks based on server latency. Next, associate the DoS profile with the applications virtual server. Associating a DoS profile with a virtual server You must first create a DoS profile separately, to configure denial-of-service protection for applications, the DNS protocol, or the SIP protocol. You add denial-of-service protection to a virtual server to provide enhanced protection from DoS attacks, and track anomalous activity on the BIG-IP system. 1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens. 2. Click the name of the virtual server you want to modify. 3. For the Destination setting, select Host and in the Address field, type the IP address for the virtual server. 4. From the Security menu, choose Policies. 5. To enable denial-of-service protection, from the DoS Protection Profile list, select Enabled, and then, from the Profile list, select the DoS profile to associate with the virtual server. 6. Click Update to save the changes. DoS protection is now enabled, and the DoS Protection profile is associated with the virtual server.

Displaying DoS event logs You can display DoS Application event logs to see whether L7 DoS attacks have occurred, and view information about the attacks. 1. On the Main tab, click Security > Event Logs > DoS > Application. The DoS Application event log opens. 2. Review the list of DoS attacks to see what has occurred, what mitigation is in place, and what caused the attacks. 3. Click the Attack ID link for an attack to display additional information in a chart form. Viewing L7 DoS attack reports Before you can look at the DoS attack statistics, you need to have created a DoS profile so that the system is capturing the analytics on the BIG-IP system. You must associate the DoS profile with one or more virtual servers. If your browser is IE8 or earlier, you need to have Adobe Flash Player installed on the computer where you plan to review the data. You can display charts that show information about DoS attacks. The charts provide visibility into what caused the attack, IP addresses of the attackers, which applications are being attacked, and how the attacks are being mitigated. 1. On the Main tab, click Security > Reporting > DoS. The DoS Application reporting screen opens. 2. From the View By list, select the way you want to view information about DoS attacks. For example, click Client IP Addresses to see the IP addresses from which the attacks are emanating. 3. If you want to filter the information that displays further, click Expand Advanced Filters and select the details you want to see. 4. To focus in on the specific details you want more information about, point to the chart or click it. The system displays information about the item. You can continue to review the details about DoS attacks on the reporting screens. As a result, you become more familiar with what caused the attacks, what applications are most vulnerable, and see the mitigation methods that are in place.

Implementation Result
When you have completed the steps in this implementation, you have configured the Application Security Manager to protect against L7 DoS attacks. Depending on your configuration, the system detects DoS attacks based on transactions per second (TPS) on the client side, server latency, or both. In TPS-based detection mode, if the ratio of the transaction rate during the history interval is greater than the TPS increased by percentage, the system considers the URL to be under attack, or the IP address to be suspicious.

In latency-based detection mode, if the ratio of the transaction rate during the history interval is greater than the Latency increased by percentage, the system considers the URL to be under attack, or the IP address to be suspicious. If you chose the blocking operation mode, the system drops requests from suspicious IP addresses and URLs. If using the transparent operation mode, the system reports DoS attacks but does not block them. After traffic is flowing to the system, you can check whether DoS attacks are being prevented, and investigate them by viewing DoS event logs and reports.

sol14199: Determining if BIG-IP ASM has detected and prevented a Slow HTTP POST DDoS attack
Purpose You should consider using this procedure under the following condition:

You want to determine if the BIG-IP ASM system has detected and prevented a Slow HTTP POST DDoS attack.

Prerequisites You must meet the following prerequisite to use this procedure:

You have command line access to the BIG-IP ASM system

Description The BIG-IP ASM system is capable of detecting and preventing Slow HTTP POST DDoS attacks by using internal parameters to perform this enforcement. The system does not report the enforcement as a violation in the BIG-IP ASM Configuration utility. When the BIG-IP ASM system has prevented Slow HTTP POST DDoS attacks, it logs indicative messages to the /var/log/ts/bd.log file and the /var/log/asm file. F5 Product Development is tracking a Request for Enhancement (RFE) as ID 364640 to include the enforcement of Slow HTTP POST DDoS attacks as a violation to be reported in the BIG-IP ASM Configuration utility. Procedures Verifying Slow HTTP POST DDoS attack prevention

Impact of procedure: None. 1. Log in to the BIG-IP ASM command line. 2. Review the /var/log/ts/bd.log file or type the following command: grep "Slow transactions attack detected" /var/log/ts/bd.log 3. Look for a log message that appears similar to the following example: ATTACK_ENGINE|NOTICE|Dec 14 08:47:00.962|8469|dos_engine.c:6982|Slow transactions attack detected - account id: (18), number of dropped slow transactions: (350) 4. Review the /var/log/asm file or type the following command: grep "Slow transactions attack detected" /var/log/asm 5. Look for a log message that appears similar to the following example: 01310001:3: event code D6983 Slow transactions attack detected - account id: (18), number of dropped slow transactions: (350) 6. The existence of both messages in their respective log files indicates that the BIG-IP ASM has detected and prevented a Slow HTTP POST DDoS attack. Note: You can configure custom SNMP trap alerts for the attack prevention notification by performing the steps described in the two SNMP traps articles listed below.

Manual Chapter: Detecting and Preventing System DoS and DDoS Attacks
About configuring the BIG-IP system to detect and prevent DoS and DDoS attacks
DoS and DDoS attack detection and prevention is enabled by the BIG-IP Advanced Firewall Manager (AFM). DoS and DDoS detection and prevention serves two functions.

To detect, and automatically mitigate, packets that present as DoS or DDoS attacks. To determine unusual increases in packets of specific types that are known attack vectors. Possible attack vectors are tracked over the past hour, and current possible attacks are compared to the average of that hour.

You can configure a BIG-IP device to detect all system-supported DoS attacks at levels that you specify. Detecting and protecting against DoS and DDoS attacks The BIG-IP system handles DoS and DDoS attacks with preconfigured responses. With the DoS Protection Device Configuration, you set detection thresholds and internal rate limits for a range of DoS and DDoS attack vectors.

1. On the Main tab, click Security > DoS Protection > Device Configuration. The DoS Protection Device Configuration screen opens. 2. If you are using remote logging, from the Log Publisher list, select a destination to which the BIG-IP system sends DoS and DDoS log entries. 3. In the Attack Type column, click the name of any attack type to edit the settings. The configuration page for the particular attack appears. 4. From the Detection Threshold PPS list, select Specify or Infinite. o Use Specify to set a value, in packets per second, for the attack detection threshold. If packets of this type cross the threshold, an attack is logged and reported. The system continues to check every second, and marks the threshold as an attack as long as the threshold is exceeded. o Use Infinite to set no value for the threshold. This specifies that this type of attack is never logged or reported. 5. From the Detection Threshold Percent list, select Specify or Infinite. o Use Specify to set the percentage increase value, that specifies an attack is occurring. The system compares the current rate to an average rate from the last hour. For example, if the average rate for the last hour is 1000 packets per second, and you set the percentage increase threshold to 100, an attack is detected at 100 percent above the average, or 2000 packets per second. When the threshold is passed, an attack is logged and reported. The system then automatically institutes a rate limit equal to the average for the last hour, and all packets above that limit are dropped. The system continues to check every second until the incoming packet rate drops below the percentage increase threshold. Rate limiting continues until the rate drops below the specified limit again. o Use Infinite to set no value for the threshold. This specifies that this type of attack is never logged or reported. 6. From the Default Internal Rate Limit list, select Specify or Infinite. o Use Specify to set a value, in packets per second, which cannot be exceeded by packets of this type. All packets of this type over the threshold are dropped. Rate limiting continues until the rate drops below the specified limit again. o Use Infinite to set no value for the threshold. This specifies that this type of attack is not rate-limited. 7. Click the Update button. The selected configuration is updated, and the DoS Protection Device Configuration screen opens again. 8. Repeat the previous steps for any other attack types for which you want to change the configuration. Now you have configured the system to provide custom responses to possible DoS and DDoS attacks, and to allow such attacks to be identified in system logs and reports. Configure SNMP traps, logging, and reporting for DoS attacks, to track threats to your system. 2. Integration with external monitoring a. SIEM integration b. IPS integration

c. remote syslog 3. Device Hardening a. There is a iApp and guide available for hardening 1. https://devcentral.f5.com/wiki/iApp.NIST-Special-Publication-800-53.ashx b. Join the DevCentral"Security Compliance" Forum 4. Join the security mailing list

Section 3: Optimizing the Support Experience

1. Information to collect prior to contacting support a. In case of emergency write-in list (common IDs, passwords, version numbers, etc.) 2. Sharing Qkview files with F5 Suport

Sharing Diagnostic Files with F5 Support

F5 Technical Support may require diagnostic files to help resolve technical support issues. To upload files to F5, use one of the following two methods:

Uploading qkview diagnostic files to BIG-IP iHealth Uploading/downloading files using dropbox.f5.com

Uploading qkview diagnostic files to BIG-IP iHealth If you are running BIG-IP 10.x or later and need to provide a qkview diagnostic file to F5, the preferred way to do so is to upload the file to the BIG-IP iHealth website. BIG-IP iHealth allows you to quickly diagnose the health and proper operation of your BIG-IP system. For more information, refer to the BIG-IP iHealth website. Uploading/downloading files using dropbox.f5.com The dropbox.f5.com site is a widely-available file repository for exchanging incoming and outgoing diagnostic files with the F5 support team. The dropbox.f5.com site supports HTTP, FTP, and SFTP for transferring files to/from F5. Important: The dropbox.f5.com site does not support the SCP protocol. Username and Password

Access to the dropbox.f5.com site is associated with an open support ticket number with a syntax of CXXXXXX or 1-########. The username provided to the dropbox.f5.com site is the ticket number, and the password provided is an email address of a user associated with the ticket. For example: If joeuser@example.com has opened ticket C123456, he would log in to the dropbox.f5.com site using the following information: Username: C123456 Password: joeuser@example.com If joeuser@example.com has opened ticket 1-12345678, he would log in to the dropbox.f5.com site using the following information: Username: 1-12345678 Password: joeuser@example.com Note: If you experience difficulty in logging in to the dropbox.f5.com site, contact F5 Technical Support. Uploading files to the dropbox.f5.com site You can upload files to the dropbox.f5.com site by performing one of the following three procedures:

Uploading files to the dropbox.f5.com site using FTP Uploading files to the dropbox.f5.com site using HTTP Uploading files to the dropbox.f5.com site using SFTP

You can download files from the dropbox.f5.com site by performing one of the following two procedures:

Downloading files from the dropbox.f5.com site using FTP Downloading files from the dropbox.f5.com site using SFTP

Uploading files to the dropbox.f5.com site using FTP Note: If your email address is longer than 32 characters, you may not be able to use the Microsoft Windows command-line FTP client to connect to dropbox.f5.com. Some versions of the Microsoft Windows command-line FTP client truncate passwords longer than 32 characters. 1. From the F5 device, or the workstation containing the required files, FTP to the dropbox.f5.com site. 2. Log in using the case number as the username. For example:

C123456 or 1-12345678 3. When prompted for the password, enter the email address of the user associated with the ticket. 4. To enter binary mode, type the following command: binary 5. Upload the requested files using the following command syntax for each file: put <name_of_file> 6. After the files are uploaded, exit FTP by typing the following command: quit Uploading files to dropbox.f5.com using HTTP You can upload files to the dropbox.f5.com site by performing one of the following two procedures:

Uploading files to the dropbox.f5.com site using a standard web browser Uploading files to the dropbox.f5.com site using command line HTTP utilities

Uploading files to the dropbox.f5.com site using a standard web browser 1. Browse to the following site: http://dropbox.f5.com The site will prompt for authentication. Log in using the case number as the username and the email address of the user associated with the ticket as the password. In the text field, enter the full path to the file you want to upload, or click Browse and navigate to the file. If you want to add additional files, click Add Files and repeat Step 3 in the new text field. Repeat Steps 3 and 4 until all files you want to upload are listed. Click Upload Files. Important: HTTP basic authentication must be provided as described in the Username and Password section. The contents of the POST or PUT data will be placed in a destination file specified by the URI provided. The destination parent directory of the provided URI must already exist for the upload to succeed. Therefore, F5 recommends that you upload everything directly into the root directory unless you know a particular

2. 3. 4. 5. 6.

subdirectory already exists. Also, the destination URI provided to the server cannot be a directory. Note: The dropbox.f5.com site also supports the HTTP PUT method as well as posting data to a desired URI to upload relevant files. This can be useful using many command line utilities available on F5 products. Uploading files to the dropbox.f5.com site using command line HTTP utilities To upload files to dropbox.f5.com using command line HTTP utilities, such as curl from the BIG-IP system, use the following command syntax: curl --user <username>:<password> --upload-file <filename> http://dropbox.f5.com/<dst filename> You must replace the following information:

Replace <username> with the case number in the following format: Cxxxxxx or 1-########

Replace <password> with the email address of the user associated with the case. Replace <filename> with the name of the file you want to upload. Replace <dst filename> with the destination file name.

Note: The files will not upload correctly if the destination URI is a directory on a direct POST or PUT. For example, to upload the local file bigip.conf associated with case number C123456 to the dropbox.f5.com site with the name mybigip.conf, you would type the following command: curl --user 'c123456:joeuser@example.com' --upload-file bigip.conf http://dropbox.f5.com/mybigip.conf Alternatively, you could use an HTTP POST rather than HTTP PUT, and type the following command: curl --user 'c123456:joeuser@example.com' --data-binary @bigip.conf http://dropbox.f5.com/mybigip.conf To upload files using a proxy, you need to add the --proxy option to the curl utility. If the proxy requires authentication, you need to add the --proxy-user option to the curl utility. Using the above example, to upload the same file bigip.conf through a proxy with an IP address 192.168.1.1 and port 8080, and proxy user johnuser and password mypassword, you would type the following command:

curl --user 'c123456:joeuser@example.com' --proxy 192.168.1.1:8080 --proxy-user johnuser:mypassword --upload-file bigip.conf http://dropbox.f5.com/mybigip.conf

For more information, refer to the manual or man pages of your preferred HTTP client to see the proper usage for uploading file contents. Uploading files to the dropbox.f5.com site using SFTP Important: The dropbox.f5.com site does not support the SCP protocol. Note: The dropbox.f5.com site supports the SFTP protocol, but only a subset of features provided by many SFTP clients. The SFTP server does not support or allow setting file ownership or permissions, updating timestamps, or creating symlinks. Note: The dropbox.f5.com RSA server key fingerprint is 89:2c:32:50:c7:39:10:7b:75:42:1c:5b:14:d2:1c:4d. 1. From the F5 device, SFTP to the dropbox.f5.com site using the following syntax: sftp user@host For example: sftp c123456@dropbox.f5.com or sftp 1-12345678@dropbox.f5.com 2. When prompted for the password, enter the email address of the user associated with the case. 3. Upload the requested files using the following command syntax for each file: put <name_of_file> For example: put mybigip.conf 4. When all files have been uploaded, exit the SFTP utility by typing the following command: bye For more information, refer to the manual or man pages for the SFTP utility by typing man sftp at the command line. You may also use external SFTP applications to upload files if they are on a workstation or other system.

Note: WinSCP, by default, attempts to set the ownership and timestamp of newly-created files on the destination server. The dropbox.f5.com site does not permit this, and WinSCP will provide an error indicating that it failed to do so, even when the upload completed successfully. There are settings under Preferences->Transfer to disable this behavior or ignore the failures if this becomes bothersome. WinSCP is an open source, free SFTP client and FTP client for Windows. For more information about WinSCP, refer to http://winscp.net/eng/docs/introduction. This link takes you to a resource outside of AskF5, and it is possible that the documents may be removed without our knowledge. Downloading files from the dropbox.f5.com site using FTP To download a file from dropbox.f5.com, you must use the exact file name and location (path) provided by your F5 Technical Support representative. To download files from the dropbox.f5.com site using FTP, perform the following procedure: Note: If your email address is longer than 32 characters, you may not be able to use the Microsoft Windows command-line FTP client to connect to dropbox.f5.com. Some versions of the Microsoft Windows command-line FTP client truncate passwords longer than 32 characters. 1. From the F5 device, or the workstation containing the required files, FTP to the dropbox.f5.com site. 2. Log in using the case number as the username. For example: C123456 or 1-12345678 3. When prompted for the password, enter the email address of the user associated with the ticket. 4. To enter binary mode, type the following command: binary 5. Download the requested files using the following command syntax for each file: Note: The <full_path_to_file> section indicates the full path to the file. get <full_path_to_file> For example: get outgoing/hotfix-123456 6. After the files are downloaded, exit FTP by typing the following command:

quit Downloading files from the dropbox.f5.com site using SFTP To download a file from dropbox.f5.com, you must use the exact file name and location (path) provided by your F5 Technical Support representative. Important: The dropbox.f5.com site does not support the SCP protocol. Note: The dropbox.f5.com site supports the SFTP protocol, but only a subset of features provided by many SFTP clients. The SFTP server does not support or allow setting file ownership or permissions, updating timestamps, or creating symlinks. Note: The dropbox.f5.com RSA server key fingerprint is 89:2c:32:50:c7:39:10:7b:75:42:1c:5b:14:d2:1c:4d. 1. From the F5 device, SFTP to the dropbox.f5.com site using the following syntax: sftp user@host For example: sftp c123456@dropbox.f5.com or sftp 1-12345678@dropbox.f5.com 2. When prompted for the password, enter the email address of the user associated with the case. 3. Download the requested files using the following command syntax for each file: Note: The <full_path_to_file> section indicates the full path to the file. get <full_path_to_file> For example: get outgoing/hotfix-123456 4. When all files have been downloaded, exit the SFTP utility by typing the following command: bye For more information, refer to the manual or man pages for the SFTP utility by typing the following command at the command line: man sftp

You may also use external SFTP applications to download files if they are on a workstation or other system.

3. What are my options for assistance from F5? a. Types of assistance available b. General numbers to contact

Section 4: Resources Available

AskF5
1. Break/Fix solutions 2. Manuals 3. Release Notes

iHealth
1. Fast responses tailored to your configuration 2. Only recommend upgrades you need

F5 Support
The F5 Networks Technical Support web site, http://support.f5.com, provides the latest documentation for the product, including: Release notes for the BIG-IP system, current and past Updates for guides (in PDF form) Technical notes Answers to frequently asked questions The AskF5 Knowledge Base To access this site, you need to register at http://support.f5.com.
1. Opening Cases (point to solution) 2. WebSupport Portal 3. Entitlement Checking of the unit 4. Licensing Issues

DevCentral
1. Online Community 2. iApps 3. iRules References

F5 University
1. WBTs for new features 2. Provide link

F5 Training Services
1. F5 Certification 2. Courses link 3. https://www.f5.com/services/global-training/

Consulting Services
1. Link goes here