f5 Tmos Operations Guide

TMOS Operations Guide
Unified intelligence, flexibility,

and programmability
TMOS is the underlying architecture common to
all BIG-IP products
CONTENTS—
Contents
Quick Start Guides viii
Maintenance at a glance viii
Maintenance checklist xiii
Upgrade checklist xiv
Upgrade tasks reporting (BIG-IP 13.x and later) xiv
About This Guide 1

Before using this guide 1
Limits of this guide 1
Glossary 2
Customization 2
Issue escalation 2
Feedback and notifications 3
Configuration utility 3
Command-line syntax 3
Finding other documents 4
BIG-IP iHealth 5
At a glance–Recommendations 5
Background 5
Additional resources 9
Operating Environment 10
Background 10
Procedures 11
Hardware Diagnostics 16
Background 16
Procedures 17
i
CONTENTS—
VIPRION 28
Background 28
Procedures 33
Drive Maintenance 45
Background 45
Procedures 51
Licenses and Entitlement 57

Background 57
Procedures 58
Backup and Data Recovery 67

Background 67
Procedures 73
Software Updates 85
Background 85
Procedures 85
Networking and Cluster Health 96

Background 96
Local Authentication Fallback 100
Procedures 104
Troubleshooting enhancements (BIG-IP 13.x and later) 112
ii
CONTENTS—
Log Files and Alerts 115

Background 115
Procedures 120
Modules 132
Background 132
Procedures 142
MySQL 146
Background 146
Caches 148
Procedures 150
External APIs 156

Background 156
Procedures 160
Security 167
Background 167
Procedures 174
Optimizing the Support Experience 176

F5 technical support commitment 176
F5 certification 177
Self-help 178
iii
CONTENTS—
F5 training programs and education 181
Engage F5 Support 181
Appendix A: Outside the Box 192

Front panel characteristics 192
Back panel characteristics 195
VIPRION chassis characteristics 196
Appendix B: Deployment and Response Methodologies 199

Background 199
Appendix C: Support Incident Report 209

Support Incident Report 209
Opening a Support Case 210
Legal Notices 211

Trademarks 211
Patents 211
Notice 211
Publication Date 212
Copyright 212
Change List 213
iv
FIGURES—
Figures
Figure 0.1: F5 documentation coverage 2
Figure 11.1: BIG-IP objects configured for remote high-speed logging 124
Figure A.1: BIG-IP 5000 series platform front panel 192
Figure A.2: LCD panel on a BIG-IP 7000 series application delivery controller 194
Figure A.3: BIG-IP 5000 series platform back panel 195
Figure A.6: VIPRION 4800 Platform chassis components 197
Figure A.7: VIPRION B4300 blade components 198
v
TABLES—
Tables
Table 0.1 Command-line syntax 3
Table 1.1 Quick information bar items 6
Table 1.2 Areas of the BIG-IP iHealth Status > Overview page 7
Table 1.3 Additional iHealth resources 9
Table 2.1 General platform environmental operating specifications 11
Table 2.2 Additional Operational Environment Resources 14
Table 3.1 File types available for EUD download 19
Table 3.2 Possible tasks with downloaded EUD files 21
Table 3.3 Options for running EUD tests 22
Table 3.4 EUD test suite 22
Table 3.5 EUD options 25
Table 3.6 Additional hardware diagnostics resources 26
Table 4.1 LED indicators for chassis standard operating states 29
Table 4.2 LED indicators for blade standard operating states 30
Table 4.3 Additional VIPRION resources 44
Table 5.1 Logging and error conditions 50
Table 5.2 Additional drive maintenance resources 55
Table 6.1 Additional licensing and entitlement resources 66
Table 7.1 Default UCS archive encryption values 74
Table 7.2 Additional backup and data recovery resources 84
vi
TABLES—
Table 8.1 Additional software updates resources 95
Table 9.1 Ntpq command returns 110
Table 9.2 Additional networking and cluster health resources 114
Table 10.1 Log information categories and their descriptions 117
Table 10.2 Available facilities 119
Table 10.3 Emerg level report messages 120
Table 10.4 Description of high-speed logging configuration objects 124
Table 10.5 MCP logging levels 125
Table 10.6 tmsh logging levels 126
Table 10.7 Additional log files and alerts resources 130
Table 11.1 Recommended maintenance for BIG-IP APM 135
Table 11.2 Recommended maintenance for BIG-IP ASM 135
Table 11.3 Additional modules resources 145
Table 12.1 Additional MySQL resources 147
Table 13.1 Additional caches resources 155
Table 14.1 Additional external APIs resources 166
Table 15.1 Additional security resources 174
Table B.1 Articles to assist with assembling your support case 210
vii
QUICK START GUIDES—Maintenance at a glance
Quick Start Guides

These quick start guides are intended to help you hit the ground running if you need to quickly prepare for
maintenance of your BIG-IP® system investment.
The guides include the following sections:
• Maintenance at a glance, which compiles the recommendations and breaks them down by frequency and
location of the procedures and background information in this document. They also provide a few external
references.
• Maintenance checklist, which offers a set of tasks to help prepare for your BIG-IP maintenance periods.
• BIG-IP upgrade checklist, which provides a set of recommended tasks for preparing for BIG-IP upgrades.
There may be additional activities and tasks required by your company policies or industry standards that you
want to add to these lists.
Important These guides are intended to supplement your current business and systems operations and
requirements. They are not intended to replace them.
Maintenance at a glance
One-time tasks
Description Refer to chapter Notes
Ensure system is
“Operating Platform guides are available by searching AskF5™
mounted according to the
Environment” (support.f5.com).
relevant platform guide.
Ensure the BIG-IP system
You can use the NTPQ command to monitor NTP
synchronizes its clock “Networking and
activity. For more information, refer to AskF5 article
with a network time Cluster Health”
K10240: Verifying NTP peer server communications
protocol (NTP) server.
Configure logging to If you use centralized logging, ensure that you set the
“Log Files and Alerts”
remote log servers. correct time and time zone on the device.
Configure SNMP traps. “Log Files and Alerts”
Set up a second power Not all platforms support multiple power supplies.
“Operating
supply if your system has Applies only to 1600, 2000, 3600, 4000, and 5000
Environment”
only one power supply. series.
Connect redundant
power supplies to two “Operating

separate power sources Environment”
in your data center.
Subscribe to F5® “Software Updates”
Refer to AskF5 Publication Preference Center
TechNews and security or “Optimizing the
(interact.f5.com/technews.html).
mailing lists. Support Experience”
viii
One-time tasks
F5 recommends that you create a baseline for
purposes of tracking performance changes over time.
Become familiar with the Also refer to the F5 Product Datasheets page. (f5.
initial baseline com/resources/datasheets).

performance of your
system. Baseline data is offered for informational purposes
and may not reflect the performance of your
implementation.
Daily tasks
Check available log files
for messages pertaining
to system stability and
health.
Review log files to identify
and prevent excessive “Log Files and Alerts”
logging.
Check debug modes to
identify excessive logging
and lower log rotation
rate.
Monitor the system Monitoring activity can identify possible Distributed
(SNMP, iControl®, script) “Networking and Denial-of-Service (DDoS) attacks. F5 recommends
for rapid increases in Cluster Health” sending data to an external monitoring system that
connections per second. can trigger alerts when values rise rapidly.
Weekly tasks
Upload a QKView file to
“BIG-IP iHealth” BIG-IP iHealth (ihealth.f5.com)
iHealth®.
Check available disk
“Drive Maintenance”
space.
BIG-IP system versions 11.5 and later include an
automatic update check feature. For more
information, refer to AskF5 article: K15000: Using the
Check for software
“Software Updates” Automatic Update Check feature.
updates.
All BIG-IP system software can be obtained from F5
Downloads (downloads.f5.com).
Check cache use. “Caches”
ix
Twice-monthly tasks
Audit console messages
“Networking and
to review logged
Cluster Health”
messages.
Check neighbor routing “Networking and Complete this task if you are using your BIG-IP
table entries. Cluster Health” system as a router.
Monthly tasks
Create a UCS archive and
“Backup and Data
move to a storage
Recovery”
repository.
Perform BIG-IP system
“Backup and Data
change management
Recovery”
review.
Check for OPSWAT
“Modules”
updates.
Check for attack
“Modules”
signature updates.
Review attack signature
“Modules”
and policy settings.
Quarterly tasks
BIG-IP iHealth (ihealth.f5.com)
Review iHealth trends. “BIG-IP iHealth” Uploaded qkview data is deleted after three months.
F5 recommends you back up and save this data to
review trends over longer periods of time.
Track data center and
system temperatures as
“Operating
part of your review of
Environment”
BIG-IP iHealth qkview
data.
x
Twice-yearly tasks
Complete facilities review:
• Verify ground lugs are

attached to solid
earth ground.
• Evaluate current and

“Operating
projected needs for
Environment”
rack space, power,
HVAC, and so on.
• Consider
virtualization and
other potential
optimizations.
Verify system entitlement,
check for license “Licenses and

expiration, and validate Entitlement”
compliance levels.
Test BIG-IP ASM® high-
availability configuration Also complete this task before major application or
“Modules”
and fail over under configuration changes.
controlled environment.
“Appendix B:
Deployment and
iRules® code review.
Response
Methodologies”
Yearly tasks
In BIG-IP systems versions 11.4.0 and later, you can
use the platform_check utility to collect SMART test
Run diagnostics with “Hardware data from the drive. The disk portion of the command
platform check. Diagnostics”
output indicates Pass or Fail for the drive and logs
detailed information to /var/log/platform_check.
Test failover systems as
“Backup and Data
part of disaster recovery
Recovery”
plan.
Check BIG-IP license
“Modules”
service check date.
xi
As-needed tasks
Set data center humidity iHealth monitors do not measure humidity.
monitoring systems “Operating
according to system Environment” Platform guides are available by searching AskF5
platform guide. (support.f5.com).
Ensure proper airflow in
data center and protect “Operating
Be aware of airflow when moving equipment.
equipment from Environment”
particulates.
Complete capacity “Operating

planning. Environment”
“Backup and Data Create and keep an SCF if you plan to copy a
Create an SCF.
Recovery” configuration across multiple BIG-IP systems.
“Backup and Data Create an archive before and after making significant
Create UCS archive.
Recovery” changes to your system before upgrading.
Check your system load
“External APIs”
when updating iRules.
Complete penetration
“Modules” F5 recommends regular testing.
testing.
Review F5 customer training offerings and add to staff
training schedule as needed.
Review F5 customer
training offerings and “Quick Start Guides”
Refer to F5 Certification (f5.com/education/
train staff.
certification) and F5 Training Programs and Education
(f5.com/education/training).
xii
QUICK START GUIDES—Maintenance checklist
Maintenance checklist
Using this checklist to plan your maintenance periods may ensure a better quality maintenance experience.
Timing Recommended action See

Review and sign-off
on your rollback
“Backup and Data Recovery”.
process, including
validation of rollover.
Synchronize Managing Configuration Synchronization in BIG-IP
configurations. Device Clustering: Administration.
Create a UCS archive
Before you begin for each BIG-IP AskF5 article: K13132: Backing up and restoring BIG-IP
maintenance. system to be configuration files (11.x - 12.x).
updated.
Create a pre-
maintenance baseline
by generating a AskF5 article: K12878: Generating BIG-IP diagnostic
QKView file and
data.
upload to iHealth in
case you need F5
support.
Verify all pool AskF5 article: K10516: Overview of BIG-IP pool status
members are up. (11.x - 12.x).
Check high availability AskF5 article: K9231: Overview of BIG-IP daemon
status table for
heartbeat failover.
anomalies.
At the command line, type the following command:
Verify that your
configuration loads.
tmsh load sys configuration verify file
Check log for errors. “Log Files and Alerts”
After maintenance. Verify that all monitors

are online.
Ensure blades are
online (VIPRION® “VIPRION”.
only).
Create a new QKView
file and upload to
iHealth to compare BIG-IP Health User Guide.
with pre-maintenance
baseline.
xiii
QUICK START GUIDES—Upgrade tasks reporting (BIG-IP 13.x and later)
Upgrade checklist
Before you upgrade your BIG-IP system software, review the release notes on AskF5 (support.f5.com).
Finding the release notes for your product
1. Navigate to AskF5 (support.f5.com).
2. Under Documentation, click the product name.
3. From the Product Documentation menu, select your version.
4. Under Release Notes, click your version.
Note If your BIG-IP system has not been reactivated in the last 6 months, do so before you upgrade. Refer
to ”Reactivating a BIG-IP system license”.
Completed Research and preparation

[ ] Supported hardware.
[ ] Known issues.
[ ] Behavior changes.
[ ] Upgrade from earlier versions.
[ ] Installation checklist.
Review licensing information to ensure it’s current.
[ ]
Update as needed.
[ ] Confirm iRules and other automation is compatible with new version.
For more information, refer to AskF5 article: K7727: License activation may be required prior to a software upgrade
for the BIG-IP or Enterprise Manager system.
Upgrade tasks reporting (BIG-IP 13.x and later)

Beginning in BIG-IP 13.0, the Configuration utility reports the status of long-running tasks during the system
initialization phase, following a system upgrade.
When you upgrade BIG-IP software, certain initialization tasks can take a long time to complete, which may make
it appear as though something is going wrong during the upgrade. Beginning in BIG-IP 13.0, while the system
restarts, the upgrade status dialog contains a Details link so that you can follow the upgrade process. The
upgrade status dialog appears similar to the following example:
Please wait while this BIG-IP device reboots...
Mon Mar 06 2017 15:08:46
Elapsed Time: 1 minute, 27 seconds
Shutting down device
The device is shutting down services and closing network connections. This process
takes approximately one minute to complete.
xiv
QUICK START GUIDES—Upgrade tasks reporting (BIG-IP 13.x and later)
Reboot in progress
Please do not turn off your device. Depending on your configuration, reboot time
will vary, taking 5 to 10 minutes.
Startup in progress (details)
By clicking the details link, you can view the status of any long-running upgrade
tasks that are in progress, including an estimate of how long the tasks will take
to complete. The startup tasks status appears similar to the information in the
following table:
Note The startup progress details are visible only if you are connected to the BIG-IP Configuration utility
through the management IP address. For VIPRION systems, you must connect to a blade’s individual
management IP address and not to the floating cluster management IP address.
Startup Tasks
The following is a list of long-running tasks and the order in which the system runs them. The number next to the
label helps you determine the system’s current initialization phase:
• Firmware update (0)
• BIOS update (1)
• FPGA update (2) (this is for legacy PIC-based FPGA loaders)
• FPGA update (3) (this is for legacy ARM-based FPGA loaders)
• FPGA update (4) (this is HSB)
• Firmware update (5) (this is for LOP/LBH firmware)
• Firmware update (6) (this is for BUC firmware)
• Firmware update (7) (this is for PIC firmware)
• Hardware Accelerator update (8)
• AOM firmware update (9)
• Filesystem labeling (10)
• Filesystem integrity testing (11)
• Key generation
• Initial storage provisioning
xv
ABOUT THIS GUIDE—Limits of this guide
About This Guide

The goal of this guide is to help F5® customers keep their BIG-IP® system healthy, optimized, and performing as
designed. It was written by F5 engineers who assist customers with solving complex problems every day. Some
of these engineers were customers before joining F5, and their unique perspective and hands-on experience
serves the guides F5 customers have requested.
This guide describes common information technology procedures, as well as those which are exclusive to BIG-IP
systems. There may be procedures particular to your industry or business that are not identified. While F5
recommends the procedures outlined in this guide, they are intended to supplement your existing operations
requirements and industry standards. F5 suggests that you read and consider the information provided to find the
procedures to suit your implementation, change-management process, and business-operations requirements.
Doing so can result in higher productivity and fewer unscheduled interruptions.
Refer to “Feedback and notifications” for information on how to help improve future versions of the guide.
Before using this guide

To get the most out of this guide, first complete the following steps, as appropriate to your implementation:
• Install your F5 platform according to its requirements and recommendations. Search the AskF5™ (support.
f5.com) for “platform guide” to find the appropriate guide.
• Follow the general environmental guidelines in the hardware platform guide to make sure of proper
placement, airflow, and cooling.
• Set recommended operating thresholds for your industry, accounting for predictable changes in load. For
assistance contact F5 Professional Services (f5.com/support/professional-services).
• Familiarize yourself with F5 technology concepts and reviewed and applied appropriate recommendations
from F5 BIG-IP TMOS: Operations Guide.
Limits of this guide

This guide does not focus on installation, setup, or configuration of your BIG-IP system or modules. There is a
wealth of documentation covering these areas in AskF5 (support.f5.com) The F5 self-help community, DevCentral™
(devcentral.f5.com), is also a good place to find answers about initial deployment and configuration.
The following figure shows where the F5 operations guides can best be applied in the product life cycle.
1
ABOUT THIS GUIDE—Issue escalation
Figure 0.1: F5 documentation coverage
Glossary
A glossary is not included in this guide. Instead, the Glossary and Terms page (f5.com/glossary) offers an up-to-
date and complete listing and explanation of common industry and F5-specific terms.
Customization
Customization may benefit your implementation. You can get help with customization from a subject matter expert,
such as a professional services consultant, from F5 Consulting Services (f5.com/support/professional-services).
Issue escalation
Refer to Optimizing the Support Experience for issue escalation information.
If you have an F5 websupport contract, you can open a support case by clicking Open a support case on AskF5
(support.f5.com)
2
ABOUT THIS GUIDE—Command-line syntax
Feedback and notifications

F5 frequently updates the operations guides and new guides may be released as needed. If you would like to be
notified when new or updated content is available, or if you have feedback, corrections, or suggestions to improve
this guide, email opsguide@f5.com. F5 internal users can file a request using Service-Now.
Configuration utility
The BIG-IP Configuration utility is the name of the graphic user interface (GUI) of the BIG-IP system and its
modules. It is a browser-based application you can use to install, configure, and monitor your BIG-IP system.
For more information about the Configuration utility, refer to Introducing BIG-IP Systems in BIG-IP Systems:
Getting Started Guide.
Command-line syntax
We show command line input and output in courier font. The corresponding prompt is not included. For example,
the following command shows the configuration of the specified pool name:
tmsh show /ltm pool my _ pool
The following table explains additional special conventions used in command-line syntax:
Table 0.1 Command-line syntax
Character Description
Identifies a user-defined variable parameter. For
<> example, if the command has <your name>, type in
your name but do not include the brackets.
[] Indicates that syntax inside the brackets is optional.
... Indicates that you can type a series of items.
TMOS Shell syntax
The BIG-IP system includes a utility known as the TMOS® Shell (tmsh) that you can use to configure and manage
the system at the command line. Using tmsh, you can configure system features and set up network elements.
You can also configure the BIG-IP system to manage local and global traffic passing through the system and view
statistics and system performance data.
You can run tmsh and issue commands in the following ways:
• You can issue a single tmsh command at the BIG-IP system command line using the following syntax:
tmsh [command] [module . . . module] [component] (options)
• You can open tmsh by typing tmsh at the BIG-IP system command line:
(tmsh)#
3
ABOUT THIS GUIDE—Finding other documents
Once at the tmsh prompt, you can issue the same command syntax, leaving off tmsh at the beginning.
Note You can use the command line utilities directly on the BIG-IP system console, or you can run
commands using a remote shell, such as the SSH client or a Telnet client. For more information about
command line utilities, refer to the Traffic Management Shell (tmsh) Reference Guide.
Finding other documents

For information about how to locate F5 product guides, refer to AskF5 article: K12453464: Finding product
documentation on AskF5.
4
BIG-IP IHEALTH—Background
BIG-IP iHealth
At a glance–Recommendations
F5® has identified the following iHealth® recommendations:
• Collect QKView files from each BIG-IP® system.
• Upload QKView files to BIG-IP iHealth and review recommended maintenance and alerts to identify
actionable items.
• Review qkview data trends on a regular basis.
Note If you choose not to use BIG-IP iHealth, you can provide your QKView file to F5 Support. For more
information, refer to ”Share diagnostic files with F5 Support”.
Background
This section provides context for our recommended procedures in the form of overviews and supplemental
information.
BIG-IP iHealth overview
BIG-IP iHealth (iHealth.f5.com) is available for free to customers running BIG-IP 10.x and later or Enterprise
Manager™ 2.x and later. BIG-IP iHealth enables you to verify operation of your BIG-IP system and ensure your
hardware and software function at peak efficiency by providing information covering your hardware, software,
licensing, configuration, best practices, and known issues.
BIG-IP iHealth is a hosted application that parses a QKView file. The QKView file provides a running “snapshot” of
your BIG-IP system with up-to-the-minute configuration and diagnostic information. You can use the qkview utility
to create a QKView file, download it from your BIG-IP system, and then upload the file to the BIG-IP iHealth
system.
BIG-IP iHealth provides outputs from commands running at the time you create a QKView file, the ability to graph
system use and network traffic, software module details, and End of Life (EoL) information for both hardware and
software.
The BIG-IP iHealth system translates the output from your QKView file and displays the content in a format that
mimics the familiar BIG-IP Configuration utility. In addition to translating the raw data, the BIG-IP iHealth
Diagnostics component evaluates the logs, command output, and configuration of your BIG-IP system against a
database of known issues, common mistakes, and published F5 recommended practices. The prioritized results
provide custom-tailored information specific to your configuration, along with recommendations for resolution, and
a link to further information in AskF5.
5
Recommended frequency for running QKView files
F5 recommends that you create and download a QKView file from your BIG-IP system and upload it to BIG-IP
iHealth on a weekly basis. The BIG-IP iHealth team updates diagnostics once a week. F5 recommends that you
address Issues revealed by the BIG-IP iHealth diagnostic output at the earliest opportunity.
Regularly uploading a QKView file to BIG-IP iHealth can help you prevent unplanned outages by exposing risks.
BIG-IP iHealth helps you resolve common configuration issues without F5 Support assistance. If you require
additional support, F5 Technical Support can provide a rapid resolution using your BIG-IP iHealth data.
Note The BIG-IP iHealth web application interface may change; refer to the BIG-IP iHealth User Guide for
details. To use BIG-IP iHealth you must have access to the BIG-IP system’s command line or the
Configuration utility.
Note For information about how to locate F5 product guides, refer to AskF5 article: K12453464: Finding
product documentation on AskF5.
BIG-IP iHealth interface
When you log in to BIG-IP iHealth, the Uploads tab displays a list of all QKView files you have uploaded. You can
select other views, including Comparisons, Shared, Hidden, and Recently. Depending on the view, you can sort
your files by Hostname, Generation Date, Description, or Upload Date. If you have uploaded a lot of files, you
can also search by QKView name using Find QKViews at the top of the BIG-IP iHealth page.
Quick Information bar
The following table describes items in the Quick Information bar.
Table 1.1 Quick information bar items

Item Description
QKView Name of the QKView file.
Hostname of the associated QKView file. For VIPRION® systems, the Hostname
Hostname field allows you to select each individual blade and the chassis for diagnostic
review.
Version Software version including hotfix name.
Generation Date Date and time the QKView file was created.
F5 Support Case SR number associated with this QKView file.
Description Description and identifier of the platform
Upload Date Shows when QKView file was uploaded.
This feature provides a space for annotating a QKView to help provide context
upon future reviews. The first time you use this feature, a plus sign (+) appears
Comments
next to the label, signifying that no comments exist. After you enter comment, the
icon changes to a page icon.
From this page, you can view a summary of BIG-IP iHealth diagnostic findings.
The menu on the left side of the page provides access to detailed information about the QKView file, including
6
Status, Network, Commands, Graphs, Diagnostics, and Files.
Status menu
The Status menu contains information about the status of your system:
• Overview
• Hardware
• Software
• Failover
• Licensing
Status > Overview page
The Status > Overview page highlights key configuration data about your BIG-IP system.
Table 1.2 Areas of the BIG-IP iHealth Status > Overview page
Area Description
Tells you when the current version of the BIG-IP software reaches its End
Life Cycle Dates
of Software development date.
Diagnostics Contains a summary of BIG-IP iHealth diagnostics findings.
Lists details about the View file and any F5 Support case numbers
File
associated with the upload.
Provides quick access to configuration files and logs, such as the bigip.
Quick Links
conf file.
Provides details about your BIG-IP system hostname, time zone, chassis
System S/N, blade S/N, status, uptime, load average, physical memory, and CPU
totals.
Provides a total count of all virtual servers, nodes, pools, iRules, SNATs,
ConfigurationTotals
NATs, and monitors associated with your configuration.
Provides information about your product, including the current software
Software
version, with links to details regarding installed hotfixes.
Licensing and Provides the status of all software modules, including product names,
Provisioning licensing status, provisioning status, and resource provisioning level.
7
Status > Hardware page
The Status > Hardware page provides a snapshot of appliance information related to the system.
Specifications shows the specifications of your device.
VIPRION hardware is fully supported in BIG-IP iHealth. Each VIPRION blade has its own summary, with detailed
disk partitioning information. The per-blade serial numbers aid in tracking chassis content. You can also identify
mixed blade chassis on this page.
Status > Software page
The Status > Software page provides a snapshot of the installed software version, including licensing information
for your F5 software, your Registration Key, and available firmware information.
Status > High Availability page
The Status > High Availability page outlines your network and hardware failover configuration data.
Status > Licensing page
The Status > Licensing page provides a snapshot of all licensing information.
Commands menu
The Commands menu allows you to browse some commands as if they were typed at the command line. You can
view the TMOS® Shell (tmsh), UNIX, and other utilities command results.
Diagnostics menu
The BIG-IP iHealth Diagnostics component automatically analyzes all custom diagnostics using your data once the
QKView file is uploaded to the BIG-IP iHealth system.
You can expand an individual issue to show more information by clicking Details in the issue pane or display the
details for all listed issues by clicking Show All.
The detailed view includes a Related Changes ID, a more complete Description of the issue, a Recommended
resolution (if applicable), and Additional Information.
The detailed view also contains a rating feature allowing you to rate whether the issue was helpful or not. F5
Support uses rating information to update the diagnostics or to influence the development of other diagnostics.
Note If new diagnostics are added after you upload your QKView file, the new diagnostics are run against
your existing QKView file the next time you access BIG-IP iHealth and the new results are displayed.
Files menu
Under the Files menu, you can find more about the configuration files, logs, and other raw information contained in
8
BIG-IP IHEALTH—Additional resources
the QKView file. This information is unprocessed but may assist you in locating issues that the BIG-IP iHealth
Diagnostics component did not find.
Some information (such as large log files) may not be included in the QKView file.
Security menu
Under the Security menu you can see general security diagnostic and performance information.
Additional resources
The following table points to additional resources you can visit to learn more about the concepts and areas
mentioned in this chapter. You can find AskF5 solution articles and the right product manuals for your software
version by searching AskF5 (support.f5.com).
Table 1.3 Additional iHealth resources

For more information about See
K12878: Generating diagnostic data using the qkview
BIG-IP iHealth procedures
utility
9
OPERATING ENVIRONMENT—Background
Operating Environment
F5® has identified the following operating environment recommendations:
• Track data center and system temperatures.
• Set data center humidity monitoring systems within specifications.
• Set up redundant power supply for systems with only one power supply and connect power supplies to
separate power sources.
• Verify grounding lugs are still properly attached to a solid earth ground.
• Ensure proper airflow in data center and protect equipment from particulates.
• Ensure system is running within noise specifications.
• Ensure system is mounted properly.
• Perform capacity planning and environmental evaluation.
• Perform recommended handling and cleaning of optic fiber.
Background
information. F5 appliances are designed to be run in a data center environment. They have broad specifications
within that environment.
Platform guides
See specifications for your hardware in the appropriate platform guide for your BIG-IP® system or VIPRION®
platform, available on AskF5™ (support.F5.com). To find the appropriate guide, enter the platform number from the
front panel of your VIPRION device and “platform guide” in the search field.
Capacity planning
Having a healthy data center environment is important to the long-term health of your F5 hardware investment.
Anticipating your ongoing power, space, network, and other resource needs can be determined by doing regular
capacity planning. F5 suggests that you consider doing a capacity planning exercise at least once a year.
Recommended capacity planning may include the following procedures:
• Create a baseline inventory of your current server, storage and network infrastructure.
• Evaluate the needs required to support planned changes to your applications and network.
10
OPERATING ENVIRONMENT—Procedures
• Evaluate the “drift” or expected workload changes expected due to business growth or changes in your
business cycle.
• Analyze the data collected and forecasting future infrastructure requirements and steps needed to meet
them.
It is beyond the scope of this document to recommend a particular method of capacity planning.
Procedures
This section details how to complete the following operating environment-related tasks:
Environmental monitoring
F5 devices are tested at the maximum and minimum temperature and humidity combinations. The following table
lists general platform environmental operating specifications for your reference.
Important Always check the appropriate platform guide for your device’s particular specifications.
Table 2.1 General platform environmental operating specifications
Item Specification
Operating temperature. 32 to 104°F (0 to 40°C).
Operational relative humidity. 10 to 90% (40°C).
Non-operational temperature. -40 to 158°F (-40 to 70°C).
Non-operational relative humidity. 5 to 95% (40°C) non-condensing.
Temperature monitoring
Several temperature sensors are included in every F5 platform. They monitor the data center environment and the
health of the appliance or chassis.
If the sensors on the air inlet temperatures indicate there is a problem, either the data center is too warm (check
the platform guide for your device to see the exact limits), or the airflow to the rack or the specific device may be
blocked. Blocked exhaust areas can increase temperature by preventing airflow through the device.
A physical inspection and polling automated temperature-tracking systems within your data center is
recommended.
To check appliance temperature using BIG-IP iHealth®
1. In the Status menu, click Hardware.
2. On the Appliance tab, find the specs for Temp to verify that they are within the temperature
guidelines specified in the appropriate platform guide for your device.
If data is not present, you can run the TMOS® Shell (tmsh) command, detailed in the next
procedure.
11
Note BIG-IP iHealth heuristics report high-temperature conditions, but not all qkview files report
temperatures other than that of the CPU.
To check appliance temperature using tmsh in BIG-IP iHealth
1. In the left navigation menu click Commands.
2. Click tmsh.
3. Click System.
4. Click show /sys hardware.
To check appliance temperature using tmsh at the command line
1. Log in to tmsh by typing the following command:
tmsh
2. At the command line, type the following command:
show /sys hardware
Humidity monitoring
F5 devices can operate at a wide range of humidity, usually similar to or exceeding the other equipment in your
data center. Very low humidity can cause excess static to build up, increasing the chance of damage to devices,
and very high humidity can cause problems with condensation. Grounding the hardware provides additional safety
for the hardware in the event of a short, as well as help reduce any static charge that builds up due to low humidity
environments.
Important F5 devices themselves do not track humidity, so you need to set your data center humidity
monitoring systems to track humidity according to specifications given in the platform guide for your
specific device(s).
Power source and electrical noise monitoring
AC or DC power supplies provide power to F5 systems. F5 determines the power supplies required at the time of
your order, depending on the wiring of your data center. The connections to your data center power distribution
are important and you must monitor them for safe and efficient use. The platform guide for your system includes
installation instructions and specifications. Consult an electrician when necessary.
Earth grounding your F5 devices is very important for safety. All F5 appliances have a mechanism for grounding.
As you make changes to your data center over time, verify that the grounding lugs are still properly attached to a
solid earth ground.
F5 devices comply with various international electromagnetic compatibility standards for both emission and
sensitivity to electrical noise. Check the platform guide for details for your region.
12
Redundancy
Many F5 devices have redundant power supplies, but some do not. The BIG-IP 1600, 3600, 3900, 2000, 4000,
and 5000 series come standard with only one power supply. You may want to consider purchasing a second
power supply for redundancy.
Important For devices with redundant supplies, connect the supplies to two separate power distribution
points within your data center. This ensures that if one power distribution point has a problem, the
appliance remains up and running.
You can find the exact specifications for the power source for each device in the platform guide for your
device. As you add equipment to and remove equipment from your data center, verify that you are still
maintaining the proper current and voltage requirements for your device.
Airflow monitoring
Maintaining good airflow is critical to keeping your device working well. As you move equipment around in a data
center or make other changes in the ventilation system, airflow intake and venting may cause your F5 devices to
overheat. Most F5 devices use front-to-back airflow, but some, notably the VIPRION 4000 series, use side-to-side
airflow. Check your platform guide for a diagram of the airflow for your specific device.
Take care when labeling equipment or placing informational placards not to cover inlet or exhaust ports.
Keep data center equipment in an area with filtered air and low dust and particulates.
If your physical environment changes (construction work being done, for example), take care to protect your F5
appliances and your other data center equipment from dust. The airflow in most electronics pulls dust inside the
chassis, and a buildup of dust can cause problems over time.
The VIPRION C4800 has two air filters; check the corresponding platform guide for instructions on how to locate
and periodically clean the filters. If dust has accumulated in the equipment, your regular BIG-IP iHealth checks
likely show a slow rise in internal temperatures, even if the inlet temperatures remain constant.
Acoustic noise monitoring
Acoustic noise may be an issue in some environments where there are specific standards for health and safety. F5
devices rarely function above normal limits for a data center. Check the specifications in the platform guide for
your device to verify that it is within its normal limits.
Acoustic noise increases over the lifetime of a device, so verify the operation of the fans with your periodic BIG-IP
iHealth checks. Increased noise can indicate that a fan is not working properly, and most fans can be replaced as
a field-replaceable unit (FRU).
Physical safety monitoring
As you make changes in your data center, you may move devices around to different racks or move them higher or
lower within their existing racks. When doing so, check the platform guide for proper mounting options for your
specific device(s) and verify that you have the correct hardware.
13
OPERATING ENVIRONMENT—Additional resources
F5 chassis-based products come with lifting handles which you should use whenever devices are moved.
Important Take care not to lift chassis-based systems from areas like the fan assembly front panel or blade
slots.
Some devices are quite heavy and require two or more people to move or re-install them. Check the
platform guide for details on mounting hardware, placement instructions, and safety notes regarding weight
and moving your device(s).
Optic fiber material cleaning
F5 hardware may contain optic fiber materials. Anyone using or installing optic fiber materials should first be
instructed in proper handling and installation.
The Fiber Optic Association provides the following guidelines:
• Clean fiber optic components are a requirement for quality connections between fiber optic equipment.
• Cleaning is essential as even microscopic contaminants in the fiber connection can cause component or
system failure.
• Some contaminants, such as skin oils, film residues from air vapor, and powdery coatings can be especially
difficult to remove from fiber optic materials.
You should use cartridge cleaner for cleaning connectors and lint-free wipes, ALCO pads, and OneClick cleaner
(AFL or FLUKE) for bulkheads.
Table 2.2 Additional Operational Environment Resources

Environmental specifications for the 4000
Platform Guide: 4000 Series
series.
series.
Platform Guide: 8900
system.
system.
system.
system.
14
OPERATING ENVIRONMENT—Additional resources

system.
system.
system.
system.
series.
series.
series.
Environmental specifications for the 8400 and
Platform Guide: 8400 and 8800
8800 systems.
Environmental specifications for the 1500, 3400,
Platform Guide: 1500, 3400, 6400, and 6800
6400, and 6800 systems.
Environmental specifications for the VIPRION
Platform Guide: VIPRION 2200 Series
2200 series.
2400 system.
4400 series.
4800 system.
Environmental specifications for the Enterprise
Platform Guide: Enterprise Manager 4000
Manager 4000.
Environmental specifications for the VIPRION. Platform Guide: VIPRION

Manager 500.
Manager 3000.
Environmental specifications for i2000 and
Platform Guide: i2000/i4000 Series
i4000 series.
Environmental specifications for i5000/i7000/
Platform Guide: i5000/i7000/i10000 Series
i10000 series
15
HARDWARE DIAGNOSTICS—Background
Hardware Diagnostics
F5® has identified the following hardware diagnostic recommendations:
• Run diagnostics with BIG-IP® iHealth® and/or the platform_check utility.
• Use End-user diagnostics (EUD) software when F5 recommends.
Background
information.
You can use the following tools to check your hardware:
• BIG-IP iHealth (refer to ”BIG-IP iHealth”)
• EUD software
• platform_check and platform_diag utilities
Note If you run EUD software, you must restart your system afterwards.
BIG-IP iHealth
BIG-IP iHealth can verify operation of most systems within the appliance or blade. It can check power, devices on
the internal buses, disks, and memory.
EUD software
The EUD software consists of a set of tests which report on various components in the hardware unit. The EUD is
pre-installed on each BIG-IP system. Some parts of the hardware can only be checked if the system is offline and
require the use of EUD. For compression hardware testing you must restart into the EUD partition to run the EUD
tests.
platform_check and platform_diag utilities
If you want to evaluate potential hardware issues without booting the BIG-IP system into the End-User Diagnostics
(EUD) software, you can use the platform_check and platform_diag utilities.
Platform diagnostics are introduced in BIG-IP 11.4.0 and run a series of hardware diagnostics to quickly identify
hardware failures on an F5 BIG-IP platform.
The platform diagnostic tests are only a subset of the tests available to the EUD software. However, the benefit is
that you can perform the tests without actually booting the system into the EUD software.
16
HARDWARE DIAGNOSTICS—Procedures
For detailed information about these utilities, see the following documents:
• Platform Diagnostics platform_check tests in F5 Platforms: Platform Diagnostics
• Platform Diagnostics platform_diag tests in F5 Platforms: Platform Diagnostics
Procedures
This section details how to complete the following hardware diagnostics tasks:
Maintaining hardware with BIG-IP iHealth
You can check hardware status through BIG-IP iHealth once you have run and upload a qkview file. From the
Hardware menu in the left navigation menu. All hardware issues discovered by BIG-IP iHealth are listed under
Diagnostics, ranked by severity or importance from Low to Critical.
Tip Verify your hardware on the same monitoring schedule as you collect your other BIG-IP iHealth data.
To check your hardware status using BIG-IP iHealth
1. Open the Status > Hardware page.
2. Check to see that the data for the following hardware monitors fall within acceptable
specifications for your platform:
• Disks and power supply units
• Temperature, voltage, and fan speeds
• Physical RAM
Note RAM is measured as a power of ten (SI units) in platform guide documentation but displays in BIG-IP
iHealth data in a power of two (IEC units). This can cause confusion in comparison. Make sure to convert
measurements using an SI to IEC converter.
If you discover problems with your hardware, contact F5 Support. F5 Support may ask you to run EUD as part of
diagnostics, so you should be prepared to take the system offline.
For VIPRION® systems, BIG-IP iHealth collect data for all blades. Information on sensors is also available in the
chassis display.
To view BIG-IP iHealth hardware information on your VIPRION chassis display
• Navigate to BIG-IP iHealth > Procedures > Using BIG-IP iHealth > Status > Hardware for
information.
17
If you are using a qkview taken from a Virtual Clustered Multiprocessing® (vCMP®) guest, minimal hardware
information is available and no information on sensors, disks, or other critical items is available. To view this data,
you can upload a qkview file collected from the hypervisor, also called virtual machine manager (VMM).
For more information about using BIG-IP iHealth, refer to ”BIG-IP iHealth”.
Maintaining hardware with EUD
EUD software is a set of tests that report on various components in the hardware unit. EUD is pre-installed on
each BIG-IP system.
Using the correct and latest EUD software version
There are different EUD software packages available depending on your platform. For information about the latest
EUD packages, refer to Ask F5 article: K7172: Overview of End User Diagnostics.
F5 recommends that you download and install the latest version of the EUD software for your platform prior to
running system diagnostics. EUD software is updated regularly for the relevant platform types and contains fixes
and up-to-date changes for supported hardware platforms. Older versions may not contain updates pertaining to
platform changes such as those for Restriction of Hazardous Substances (RoHS) compliance systems.
Important Failure to use the latest released version of the EUD may result in false negative or false positive
reports. EUD reports containing false information or inaccuracies can delay the resolution of any potential
underlying hardware problems.
Before running EUD software
• Do not run EUD software on a system that is in production. EUD software prevents traffic from passing
during testing. Run EUD on a production system only if F5 Support instructs you to do so.
• Disconnect all network cables from the system. Any cables connected to the system during the tests may
cause false-positive results.
• The B4300 blade allows additional EUD chassis back-plane data testing. EUD must run on two blades for
this test. Running EUD on only one blade results in test failure.
Downloading and installing new EUD software
Before you download and install new EUD software, check to see which version you have installed on your BIG-IP
system.
To determine the EUD version on your BIG-IP system at the command line
• At the command line, type the following command:
eud _ info
If you have EUD software installed, the version number appears.
18
Note You can also use the previous procedure to verify correct installation new EUD software
You have two options for downloading and installing EUD software:
• Download an ISO image, burn it to a disk, and start the disk from an external drive.
• Secure copy (SCP) an indexed mesh (IM) file to your BIG-IP system or a USB flash drive.
You also need to download the MD5 checksum file to verify the ISO or IM file you downloaded.
Deciding which files to download
There are several EUD file types available from the F5 Downloads page (downloads.f5.com).
Table 3.1 File types available for EUD download

File type Description
The ISO image is provided for burning to a CD or DVD of the EUD. You can start the
ISO image
CD/DVD from a powered USB CD/DVD drive plugged into the BIG-IP system.
The IM file is a self-extracting installation file. You can secure copy (SCP) this file
IM files directly to the BIG-IP system and use it to upgrade the EUD on the system or load a
USB flash drive.
A corresponding MD5 file exists for each ISO image or IM file you download. Use the
MD5 file
MD5 file to verify the integrity of the file you download.
Readme-EUD.txt The readme file includes details about the release, such as supported platforms.
19
To download EUD IM and corresponding MD5 checksum files
1. Navigate to F5 Downloads (downloads.f5.com) and log in with your support ID.
2. Click Find a Download.
3. Under F5 Product Family, find Hardware-Specific, then click Platform / EUD.
4. In the platform list, click your platform.
5. Click the name of the release with the most recent date.
6. Read and accept the software terms and conditions.
7. On the Select a Download page, click the file name <file_name>.im.

The <file_name> consists of the platform family and the build number.
8. On the Download Locations page, click a download location closest to yours and save the file to
your computer.
9. Return to Select a Download page and download the corresponding MD5 checksum file. It has
the same name as the IM file with .md5 as the file extension.
To download EUD ISO and corresponding MD5 checksum files
1. Navigate to F5 Downloads (downloads.f5.com) and log in with your support ID.
3. Under F5 Product Family, find Hardware-Specific, then click Platform / EUD.
4. In the platform list, click your platform.
5. Click the name of the release with the most recent Date.
6. Read and accept the software terms and conditions.
7. On the Select a Download page, click the file name <file_name>.iso.

The <file_name> consists of the platform family and the build number.
8. On the Download Locations page, click a download location closest to yours and save the file to
your computer.
9. Return to Select a Download page and download the corresponding MD5 checksum file. It has
the same name as the ISO file with .md5 as the file extension.
20
Using downloaded EUD files
There are a few possible tasks you can do with downloaded EUD files.
Table 3.2 Possible tasks with downloaded EUD files
Task Description
Use the MD5 checksum file to
Use the MD5 file to verify the integrity of the file you download.
verify integrity.
Install the EUD from the IM You can SCP this file directly to the BIG-IP system and use it to
installation package. upgrade the EUD on the system.
Load the EUD onto a USB flash Load the EUD onto a USB flash drive and run the EUD from the flash
drive. drive.
Checking the integrity of the download with MD5 checksum
You can complete this task after you download update files and their corresponding .md5 files from F5 Downloads
(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.
To check integrity of the download at the command line
1. At the command line, enter the following command syntax:
md5sum -c <file _ name>.md5
Note Replace <file name> with the name of the file you downloaded.
If the output returns OK, the download was successful. If you receive any other output, download
the file again and repeat the process.
Installing the EUD from an IM installation package
Copy the IM file to /var/tmp directory on the system you want 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.
To install EUD from an IM installation package at the command line
• At the command line, enter the following command syntax:
im <file _ name>.im
The latest EUD is installed on your hardware.
To load the EUD onto a USB drive at the command line
1. Download the IM file to /tmp/eud.
21
2. Loopback mount the IM file by entering the following command syntax:
mkdir /tmp/eud; mount -o ro,loop <file _ name>.im/tmp/eud
Note Replace <file name> with the name of the file you downloaded.
3. Insert a USB mass storage device into the platform on which you mounted the IM file.
4. Run the mkdisk utility by typing the following command:
cd /tmp/eud;./mkdisk
5. Follow the prompts to load 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 two options for running the EUD tests. You must have a console connected to your BIG-IP system to run
the EUD software.
Table 3.3 Options for running EUD tests

Task Description
Start the EUD from a USB flash Plug your EUD USB flash drive into the BIG-IP system and boot to
drive. the EUD.
Run the EUD from the system boot
As the system is starting, select the EUD option from the boot menu.
menu.
EUD test suite
The following table describes the various tests EUD software can do.
Table 3.4 EUD test suite

Test name Description Success message
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
Test Complete: PCI Test
PCI
PASSED
• RAID bus controller, SMBus controller
• Signal processing controller, Network and

computing encryption MIPS
• USB controller, PCI bridge, Ethernet

controller, Switch controller
22

Checks ECC memory for error correction codes Test Complete: ECC
ECC Status
and reports single-bit or multi-bit errors Status PASSED
Uses internal packet path to test Ethernet
interfaces in system
Sends known payload packets from mainboard

Ethernet interface back to mezzanine Ethernet
interface Test Complete: Internal Packet
Internal Packet Path
Path PASSED
Checks for correct receive order and payload
and then checks statistics at switchboard and
HSB
Test takes approximately two minutes

Sets front interfaces into PHY or MAC loopback
Test Complete: Internal
Internal Loopback mode and runs packets through path from switch
Loopback PASSED
chips
SSL Tests SSL hardware
Tests internal status of hard drive, including:
Read error rate start/stop count
Re-allocated sector count, Power on hours

Self-Monitoring
count, Spin-up retry count Test Complete: SMART Test
Analysis and Report
PASSED
Technology (SMART) Drive calibration retry count, Drive power cycle
count
Offline scan uncorrectable sector count, Ultra

ATA CRC error rate and multi-zone error rate
Reports information about installed power
supplies Test Complete: Power System
Power System
Returns chassis voltage measurements, fan Test PASSED
speeds, and mode of fan controller
Updates hard drive firmware on BIG-IP 3900 and

EM 4000 platforms. Appears only on these
platforms when system is started with older
Hardware Firmware Test Complete: Mezzanine
version of firmware
Update Packet Test PASSED
Important F5 recommends backing up
configuration before running update.
23
Performs SDRAM data bus and address bus

test. All available user memory tested
Runs following tests:
• Stuck address test
• Random value test
• XOR comparison test
System RAM • SUB comparison test Test Complete: PASSED

• MUL comparison test
• DIV comparison test, OR comparison test,

AND comparison test
• Sequential increment test
Warning This test may take several hours

to complete, depending on the amount of
available memory.
Sets each possible LED status levels and

prompts to verify corresponding color and
operation
LED (Interactive) From console or LCD panel Test Complete: PASSED

Important Some LED questions time out
after a minute. If a question times out, the
LED test fails.
Tests functionality of LCD panel

LCD Requires access to LCD panel on the tested unit. Test Complete: PASSED
You need to respond to interactive prompts
Tests USB ports on mezzanine card installed in
Mezzanine USB Test Complete: PASSED
platform
Treats HSB as standard Ethernet NIC card
Once NIC module/driver is loaded, does loop

test by sending and receiving network packets
Mezzanine Packet Test Complete: PASSED
over HSB network interface
Tests number of packets sent from one HiGig

interface to another HiGig interface
24
EUD options
You can specify the options listed in the following table to modify the EUD process.
Table 3.5 EUD options
EUD option Description

A Run All Runs all tests applicable to system except interactive
(Non-Interactive) Tests tests
I Run All Interactive Tests Runs LED and optional LCD tests
Displays test report. A report log is stored as text file

named /shared/log/eud.log in host file system.
D Display Test Report Log
Important You must run eud_log at the
command line to create output.
Displays test summary report showing the results of

S Display Test Summary
all tests run during test session
Stops the EUD and restarts the system
Warning Using other methods to stop the

Q Quit EUD and Reboot the System diagnostics, such as the reboot command or
the command menu option can destabilize the
system.
Starting 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.
To start EUD software from a USB flash drive
1. Turn off the BIG-IP system.
2. Load the EUD image onto a USB flash drive.
3. Insert flash drive into USB port on BIG-IP system.
4. Turn on the BIG-IP system.
When the EUD starts, the EUD menu appears on the console.
25
HARDWARE DIAGNOSTICS—Additional resources
Starting the EUD from the boot menu
Install the latest version of the EUD before you start the EUD from the boot menu.
To start 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 starts, it pauses briefly on the boot menu.
3. Use the arrow keys to highlight End-user diagnostics.
4. The EUD starts and the EUD menu appears on the console.
Table 3.6 Additional hardware diagnostics resources

K14748: The EUD utility may incorrectly report a
EUD testing empty SFP/SFP+ port on an 8900
failure when testing an empty SFP/SFP+ port
On a 2000,4000, 5000, or 7000 system, the EUD K14640: The EUD ‘Verify Host I2C’ test may fail
Verify Host I2C test fails indicating a false positive hardware failure
K8002: Determining the end-user diagnostics
Determining the EUD version your system is running
version
Running the EUD memory test without K13608: Running the EUD memory test may cause
disconnecting all the network cables a bridge loop
K12942: The EUD Internal Packet Path Test may
Considerations for running EUD on a VIPRION
generate false positive results on VIPRION
platform
platforms
K7172: Overview of the end-user diagnostics
Overview of the EUD software
software
EUD pass when a hard disk is missing or K14078: The EUD may report a PASSED test when a
undetected on a 6900 or 8900 platform hard drive is missing or undetected
Troubleshoot Cavium Nitrox Secure Socket Layer K95944198: Overview of the nitrox_diag diagnostic
(SSL) hardware accelerator card hardware errors utility
Devcentral: Create EUD on USB from Windows
Creating a bootable USB drive from a Windows Note A Dev Central account is required to
computer from an F5 appliance access this content.
K13165: Creating a bootable USB thumb drive.
26
HARDWARE DIAGNOSTICS—Additional resources
27
VIPRION—Background
VIPRION
F5® has identified the following VIPRION recommendations:
• Ensure VIPRION® is configured according to recommended practices.
• Determine the primary blade.
• Work from blade to blade (address the management port on any blade).
• Refer to platform guide for maintenance activities.
• Monitor tasks that are different from a BIG-IP® Application Delivery Controller (ADC).
• Add a blade and monitor its installation.
• Conduct failover management.
• Conduct blade migration.
• Create cluster traps.
Background
information.
VIPRION platform maintenance
All VIPRION platforms contain several components that you can replace without exchanging the entire system. The
list of components varies from one VIPRION platform to another. They may include:
• AC power supply
• DC power supply
• Fan tray
• Hard drive assembly
• Blades
• Bezel (with LCD component)
• Cable managers
• Chassis filter
• Power supply filter
28
• Annunciator cards
The platform guide for each VIPRION series provides detailed procedures for replacing these components.
VIPRION standard operating states
Chassis standard operating states
When the VIPRION platform is in a standard operating state, the LEDs behave in a defined manner.
Table 4.1 LED indicators for chassis standard operating states
System state Primary LED Secondary LED Status LED Alarm LED
Active mode Off/None Off/None Green solid Off/None
Powered off Off/None Off/None Off/None Off/None
VIPRION platform guides
Platform guides for each of the VIPRION models are available at AskF5 (support.f5.com).
Each guide provides detailed information on the VIPRION platform, including:
• Chassis components
• Blade components
• LCD menus
• Chassis and blade standard operating states
• Blade LED status conditions
• Indicator LEDs
• LED alert conditions
• Platform interfaces
• Platform installation
• Platform maintenance
• Environmental guidelines
• Platform specifications
Note The LCD panel on both VIPRION 2000 Series platforms is available as a separate USB module.
Blade standard operating states
When the VIPRION platform is running in a standard operating state, the Status LED of each blade turns yellow on
29
startup and turns green when the BIG-IP software has booted successfully.
Table 4.2 LED indicators for blade standard operating states

System state Status LED Alarm LED
Primary Green solid Off/None
Secondary Green solid Off/None
Powered off Off/None Off/None
Recommended practices for configuring your VIPRION
F5 recommends the following configuration practices for setting up your VIPRION:
• Cable all management ports to allow access in the event the primary blade shifts.
Note In BIG-IP 12.0 and later, any blade in the chassis can be the primary blade.
• Use the system cluster IP address as the management IP that is routed to the appropriate primary blade.
Note When the primary blade shifts, the cluster IP address always has access to the primary blade.
• You must have management access to each blade for blade-specific administrative activities and to
configure a full high-availability (HA) mesh within an HA pair of VIPRION chassis.
• Assign a management IP address to every slot.
Using multi-blade aggregated links (trunks) for all VLANs
Always use aggregated links (trunks) for all VLANs. Aggregated links provide fault tolerance if one link goes down,
and they can increase bandwidth as well.
If you configure the aggregated links to use interfaces on multiple blades, you remove a single point of failure if a
blade becomes unavailable. The connections can remain up, even if one blade is missing.
Configuring NTP
In multi-blade VIPRION HA pairs, you must enable NTP. Time synchronization is critical both for inter-chassis
communication and inter-blade communication. For more information, refer to “Networking and Cluster Health”.
The VIPRION uses Rsync for inter-blade communication, and system time must be maintained to ensure this
communication is successful.
Ensuring the serial ports on all blades are connected to a serial concentrator
Console connection is important for a VIPRION chassis for the following reasons:
• If a critical event causes a blade to go offline, console output supersedes any syslog type logging.
• EUD software needs console access to boot and do diagnostic tests.
In the event that the VIPRION chassis is not accessible through the network, console access is be required to
30
determine root cause analysis and to restore services on the VIPRION.
Using a high-availability VLAN between chassis
Having a dedicated network is important for the following reasons:
• Network failover is the only method to ensure high availability. F5 recommends that you use a network
failover trunk with member interfaces from each blade of a VIPRION.
• Connection mirroring VIPRION traffic may use excessive resources due to the amount of traffic that can be
handled from the hardware.
F5 recommends using a dedicated mirroring network to ensure successful connection mirroring.
• Ensure that each VIPRION in a sync-failover device service cluster has the same number and model of
blades installed in each chassis. Configurations must be able to config-sync across the two chassis.
Different blades use different addresses, trunks, and VIPs.
• Install blades in the same position(s) in both chassis. For example, if one chassis in the sync-failover device
group has blades in slots 1 and 2, then the other chassis should also have its blades installed in slots 1 and
2.
• Wire the management ports on all blades to the management network.
Using multicast network failover on the management network
If available, consider adding multicast network failover to the management network as a backup method to
maintain high availability. For more information, refer to AskF5 article: K13915: Configuring network failover for
redundant VIPRION systems (11.x - 12.x).
VIPRION inter-blade administrative traffic
The VIPRION system is comprised of a cluster of blades that work together to process network traffic.
Each blade in a VIPRION system communicates by sending inter-blade administrative traffic over the management
backplane. The blades are connected to the management backplane by the mgmt_bp interface, meaning the
management backplane is distinct from both the data backplane and the management interface.
You can display interface statistics for the mgmt_bp interface by running the ifconfig –a command. For example,
the following mgmt_bp interface statistical information was taken from slot 2 of a VIPRION system:
mgmt _ bp Link encap:Ethernet HWaddr 00:01:D7:71:CD:41 inet addr:192.0.2.2
Bcast:192.0.2.22 Mask:255.255.255.0
inet6 addr: fe80::201:d7ff:fe71:cd41/64
Scope:Link UP BROADCAST RUNNING MULTICAST
MTU:4096 Metric:1
RX packets:39088409 errors:0 dropped:0 overruns:0 frame:0 TX packets:37470798
31
errors:0 dropped:0 overruns:0
carrier:0 collisions:0 txqueuelen:1000
RX bytes:4141196638 (3949.3 Mb) TX bytes:694315251
(662.1 Mb)
Interrupt:16
mgmt _ bp Link encap:Ethernet HWaddr 00:01:D7:71:CD:41 inet addr:192.0.2.2
Bcast:192.0.2.20 Mask:255.255.255.0
inet6 addr: fe80::201:d7ff:fe71:cd41/64 Scope:Link UP BROADCAST RUNNING MULTICAST

MTU:4096 Metric:1
RX packets:39088409 errors:0 dropped:0 overruns:0 frame:0 TX packets:37470798 |
errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:4141196638 (3949.3 Mb) TX bytes:694315251 (662.1 Mb)
Interrupt:16
The clusterd process controls the clustering technology for the VIPRION chassis. The clusterd process sends
one multicast packet per second over the management backplane. If a blade fails to respond within 10 seconds,
the clusterd process marks the blade down and logs an error message to the /var/log/ltm file which appears
similar to the following example:
slot1/<hostname> err clusterd[2346]: 013a0014:3: Blade 1: blade 4 FAILED
Each blade in the chassis independently determines the status of the other blades. For example, the following
error messages indicate that blades 1 and 3 in the cluster lost communication with blade 4:
A blade can log another blade as failed due to any factor that prevents the generation, transmission, or reception
of the clusterd process packets. For example, a backplane hardware issue, congestion on the backplane, and
excessive memory or CPU utilization on the sending blade can all potentially impede the clusterd process from
processing clustering traffic in a timely manner.
VIPRION-specific SNMP traps
Other than normal alerts on the BIG-IP system, the traps that follow are specific to the VIPRION platform:
• bigipBladeTempHigh (“Blade temperature is too high.”)
BIGIP _ SYSTEM _ CHECK _ E _ BLADE _ TEMP _ HIGH _ 1 snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.87

”
• bigipLibhalBladePoweredOff («Blade is about to be powered off.»)
BIGIP _ LIBHAL _ HALERR _ BLADE _ POWERED _ OFF snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.119”
32
VIPRION—Procedures
• bigipBladeNoPower “A blade lost power. The blade may be pulled out”
BIGIP _ CLUSTERD _ CLUSTERD _ ERR _ BLADE _ PWRDOWN snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.8

8”
• bigipClusterdNoResponse “The cluster daemon failed to respond for 10 or more seconds.”
BIGIP _ CLUSTERD _ CLUSTERD _ FAILED snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.89”

BIGIP _ CLUSTERD _ CLUSTERD _ TURNED _ RED snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.90”
Procedures
This section details how to complete the following VIPRION-related tasks:
To find the right platform guide for your VIPRION system
1. Locate the product name on the front of your VIPRION chassis.
2. Navigate to AskF5™ and search for the string: VIPRION <chassis_product_name> Platform
Guide (“VIPRION 2400 Platform Guide,” for example).
To add management IP addresses using the Configuration utility
1. Navigate to System > Clusters > Management IP Addresses.
2. Add management IP addresses for each slot in the Cluster Member IP Addresses area, and
click Update.
To add management IP addresses using the TMOS® shell (tmsh) at the command line
1. Log in to tmsh by typing the following command: :
tmsh
modify /sys cluster default members { <slot#> ( address <IP address> } }
Note Replace <slot#> with the number of each slot contained on the VIPRION and <IP address> with
assigned management IP address.
For example, to add 10.10.10.10 as the management IP address for slot1 type the following command:
modify /sys cluster default members { 1 { address 10.10.10.10 } }
3. Repeat step 2 for each slot number.
4. Save the configuration by typing the following command:
save /sys config
33
To configure multicast network failover using the Configuration utility
1. Navigate to Device Management > Devices.
2. Click the local hostname (Self).
3. For Device Connectivity, click Failover Network.
4. Under Failover Multicast Configuration, for Failover Multicast Address, click Enabled.
5. Review Multicast Address.
6. Click Update.
To determine the primary blade on a VIPRION system using tmsh at the command line
tmsh
2. Type the following the command:
show /sys cluster
In the following sample output, the blade in slot 2 (172.24.62.132) is the primary blade, as shown in the Primary
Slot ID entry.
+------------------------------------------------------------------------------+
| Sys::Cluster: default
+------------------------------------------------------------------------------+
| Address 192.0.2.0/24 Availability available State enabled
| Reason Cluster Enabled Primary Slot ID 2 Primary Selection Time 1393007920
+-------------------------------------------------------------------------------+
| Sys::Cluster Members
+-------------------------------------------------------------------------------+
| ID Address Availability State Licensed HA

Clusterd Reason |
+-------------------------------------------------------------------------------+
| 1 192.0.2.1 available enabled true active running Run |
+-------------------------------------------------------------------------------+
34
Shutting down and restarting VIPRION systems at the command line
On a VIPRION system, the reboot, halt, full_box_reboot, and shutdown commands only affect the blade on
which the command is rund. To run a command on all available (green) blades, you can use the clsh command.
To shutdown command on all VIPRION blades
clsh shutdown -r now
You can also shut down or reboot all blades with tmsh by specifying slot all with the required
command.
To reboot all VIPRION blades
tmsh reboot slot all
To restart a specific slot
tmsh reboot slot <slot number>
To view available blades
tmsh show /sys cluster
When running the shutdown command, you can also use the –k flag to verify which blades run the command
without shutting down or restarting the system. For example:
[root@VIP-R22-S35:/S1-P:Active] config # clsh shutdown -r -k now=== slot 2 addr

192.0.2.2 color green |
=== Shutdown cancelled.=== slot 3 addr
127.3.0.3 color green ===
Shutdown cancelled.=== slot 4 addr 192.0.2.4 color green === Shutdown cancelled.===
slot 1 addr
127.3.0.1 color green === Broadcast message from root (Wed Mar 24 06:37:42 2015):
The system is going down for reboot NOW!
Shutdown cancelled.
[root@VIP-R22-S35:/S1-P:Active] config #
35
If you want to run the command in a specific order, you can use a for loop command.
For example, to run the shutdown command in the order of blade 1, 4, 2, 3, enter the following command syntax:
for i in 1 4 2 3 ; do echo “Running shutdown in slot
$i” ; ssh slot$i shutdown -r now ; done
Output appears similar to the following example:
[root@VIP-R22-S35:/S1-P:Active] config # for i in 1 4
2 3 ; do echo “Running shutdown in slot $i” ; ssh slot$i shutdown -r now ; done
Running shutdown in slot 1
Broadcast message from root (Wed Mar 24 06:49:32 2015):
The system is going down for reboot NOW!
[root@VIP-R22-S35:/S1- P:INOPERATIVE] config #
Replacing a VIPRION chassis that has one or more blades installed
When you replace an existing VIPRION chassis that has one or more blades installed by moving the blades to a
new chassis, you may experience the following issues:
• Missing license: When a blade starts on a VIPRION chassis, the blade compares the serial number of the
chassis on which it is currently running with the serial number recorded in the blade license file. If the serial
numbers are different, the blade runs without a license instead of using its existing license file.
• Missing cluster configuration: When a blade starts on a VIPRION chassis, the blade compares the serial
number of the chassis it is currently running on with its copy of the /shared/db/cluster.conf.<chassis SN>
file. If the serial numbers are different, the blade runs with a factory-default cluster configuration instead of
copying the /shared/db/cluster.conf.<chassis SN> file to the /shared/db/cluster.conf file and using that
as its cluster configuration. The cluster.conf file contains each blade’s copy of the cluster configuration, the
management addresses for the cluster and each blade within the cluster, as well as other cluster-specific
information.
• Failure to load a configuration with SSL profiles that use the SSL key passphrase encryption: If the
VIPRION system or a Virtual Clustered Microprocessing™ (vCMP®) guest that runs on the VIPRION system is
configured with SSL profiles that use the SSL key passphrase encryption, moving the blades to a new
chassis during a configuration load may result in SSL key passphrase errors.
Note If you take a UCS archive file from a vCMP guest which is running on a blade and reinstall it to the
same vCMP guest that is running on the same blade but is inserted into a different chassis, the vCMP guest
fails to load its configuration and reports an error message to the /var/ log/ltm file.
36
For complete documentation on the chassis replacement procedure and its additional preventive maintenance
tasks, refer to AskF5 article: K14302: Replacing a VIPRION chassis that has one or more blades installed.
Adding a new blade to a cluster and monitor its status
Many changes to the VIPRION platform, such as adding a new blade, can take a long time to complete. To
physically install a blade in a VIPRION chassis, follow the instructions in the appropriate platform guide for the
hardware. The following sections are intended to provide assistance in monitoring the status of a newly installed
blade as it becomes a member of the cluster.
Description
The slots in a VIPRION chassis work together as a single, powerful unit called a cluster. The size of the cluster
depends on the number of running blades installed in the chassis.
When a blade is installed in a slot and is turned on, the blade automatically becomes a member of the cluster. For
the newly installed blade to become a member of a cluster, the following automated events occur without user
interaction:
• The system restarts the newly inserted blade.
• The system copies software images from the primary blade to the newly inserted blade.
• The system installs software images on the newly inserted blade to match the boot locations of the primary
blade.
• The newly inserted blade restarts to complete the software installation.
• The system may restart the newly inserted blade an additional time to update the firmware.
• The system activates the newly inserted blade’s license.
• The system places the newly inserted blade online and it becomes active.
These steps take time, and some of them may be repeated. For example, multiple restarts may be required when
adding a blade with software installed in multiple boot locations. Make sure to plan enough time for the process.
1. The system boots the newly inserted blade.
If you monitor the newly inserted blade using its console port, a login prompt displays when the system
completes its initial boot. However, the blade is not yet an online or active member of the cluster. The system
places the newly inserted blade into ‘quorum’ status.
You can view the status of the newly inserted blade at this time, using the tmsh show /sys cluster
command on the primary blade.
The output of the command displays the quorum status, which appears similar to the following example:
+------------------------------------------------------------------------------+
| Sys::Cluster: default |
37
+------------------------------------------------------------------------------+
| Address 192.0.2.0/24 |
| Availability available |
| State enabled |
| Reason Cluster Enabled |
| Primary Slot ID 1 |
| Primary Selection Time 0 |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| Sys::Cluster Members |
| ID Address Availability State Licensed HA Clusterd |
+------------------------------------------------------------------------------+
| ID Address Availability State Licensed HA Clusterd
+------------------------------------------------------------------------------+
| |1 192.0.2.2 available enabled true active running |
| |2 192.0.2.1 available enabled true active running |
| |3 192.0.2.3 unavailable enabled false active quorum |
| |4 : : unknown disabled false unknown shutdown |
+------------------------------------------------------------------------------+
2. The system copies software images from the primary blade to the newly inserted blade
The system automatically copies software images from the primary blade to the newly inserted blade to
ensure that the software images for each boot location match the other blades in the cluster.
You can use the tmsh show /sys software status command on the primary blade to determine if the newly
inserted blade needs a software image from the primary blade. The command displays the “waiting for
product image status” for each boot location needing a new software image.
The output of the command appears similar to the following example:
------------------------------------------------------------------------------+
Sys::Software Status
------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------+
| Volume Slot Product Version Build Active Status |
38
+-----------------------------------------------------------------------------+
| HD1.1 1 BIG-IP 11.1.0 1943.0 no complete |
| HD1.1 3 BIG-IP 11.1.0 1943.0 yes complete |
| HD1.2 3 BIG-IP 11.1.0 1943.0 no waiting for |

product image
(BIG-IP 1.2.1)
| HD1.3 3 BIG-IP 11.2.0 2446.0 no waiting for |

product image |
BIG-IP 10.2.4)|
+-----------------------------------------------------------------------------+
No user interaction is required; the system automatically copies the software images from the primary blade.
However, it may take several minutes for this to occur.
Ensure that you have software installation images and hotfix images available for each version of software
that is installed into a boot location on the chassis.
For example, if you are running 11.3.0 HF1, and have 11.2.0 in another boot location, you should ensure that
there are 11.3.0 and 11.2.0 installation ISOs as well as an 11.3.0 HF1 installation ISO available.
You can run the tmsh list /sys software command to see what installation images are available. If an
installation image is missing, it can prevent the new blade from installing the appropriate software and
becoming available.
3. The system installs software images on the newly inserted blade to match the boot locations of the primary
blade. Once the software images are copied from the primary blade to the proper boot location of the newly
installed blade, the installation of the software begins. It is a good idea to have software installed in at least
two boot locations. If software is only installed in one boot location, the system can run into a deadlock
condition trying to install software. For example, if the chassis only has boot location HD1.1 installed with
BIG-IP 11.4.0 and you insert a blade, which only has boot location HD1.1 installed with BIG-IP 11.3, the
system cannot automatically install software to the new blade because it cannot install software to the active
boot location.
You can monitor the status of the software installation using the tmsh show sys software status command
on the primary blade. The command output indicates the installation completion percentage. The output of
the command appears similar to the following example:
------------------------------------------------------------------------------+
Sys::Software Status
39
------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------+
| Volume Slot Product Version Build Active Status | |+--

-------------------------------------------------------------------------+
| HD1.1 1 BIG-IP 11.1.0 1943.0 no complete| |
| HD1.1 2 BIG-IP 11.1.0 1943.0 no complete| |
| HD1.1 3 BIG-IP 11.1.0 1943.0 yes complete| |
| HD1.2 1 BIG-IP 11.2.1 797.0 yes complete| |
| HD1.2 3 BIG-IP 11.1.0 1943.0 no waiting _ for _

| productimage _
| (BIG-IP _ 11.2.1)
|
| HD1.3 3 BIG-IP 10.2.4 577.0 no installing _

90.000 _ pct |
| +---------------------------------------------------------------------------+
40
You can continue to monitor the status of the software installation by repeating the command on the primary blade.
+------------------------------------------------------------------------------+
| Volume Slot Product Version Build Active Status |
+------------------------------------------------------------------------------+
| HD1.2 3 BIG-IP 11.2.1 797.0 no installing

10.000 pct |
+------------------------------------------------------------------------------+
4. The newly inserted blade reboots to complete the software installation.
Once the software installation is complete, the newly-inserted blade displays messages that appear similar
to the following example, and then reboots:
slot3/VIP4400-R24-S42 emerg overdog[4097]: 01140043:0: Ha feature software _

update reboot requested. INIT: Switching to runlevel: 6 (reboot)
INIT: Sending processes the TERM signal INIT: Sending processes the KILL
signal Shutting down smartd: [ OK ]
Using bigstart to shutdown BIG-IP:
5. The system may reboot the newly inserted blade an additional time to update the firmware.
As the blade boots up following the software installation, it may require an additional reboot to update the
firmware. If the firmware requires an update, the system displays messages that appear similar to the
following on the blade’s console:
Checking for firmware updates:
...
Updating HSB on mezzanine to version 1.4.2.0... DO NOT INTERRUPT Erasing

flash... (may take up to 30 secs)
Programming flash...
HSB firmware update: the system will automatically reboot to activate slot 1.
Updating HSB on main to version 1.4.2.0... DO NOT INTERRUPT
41
Erasing flash... (may take up to 30 secs) Programming flash...
HSB firmware update: the system will automatically reboot to activate slot 1.
INIT: Sending processes the TERM signal
Using bigstart to shutdown BIG-IP:
Following reboot, the blade boots to the same active boot location as the primary blade. As the blade boots
back up following the firmware update, the system displays messages that appear similar to the following, to
the blade’s console:
Checking for firmware updates:
...
Successful update to HSB v1.4.2.0 Successful update to HSB v1.4.2.0
6. The system activates the newly inserted blade’s license. Once the blade has finished the required reboots,
the system automatically activates the new blade’s license. You can verify that the blade’s license has been
activated using the tmsh show sys cluster command on the primary blade. The Licensed column in the
output of the command shows a status of true for the newly inserted blade. The output of the command
appears similar to the following example:
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| Address 192.0.2.0/24
| Availability available
| State enabled
| Reason Cluster Enabled
| Primary Slot ID 1
| Primary Selection Time 0
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
Address
| ID Availability State Licensed HA Clusterd |
+------------------------------------------------------------------------------+
| 1 192.0.2.1 available enabled true active running |
| 3 192.0.2.2 offline enabled true offline running |
| 4 : : unknown disabled false unknown shutdown |

+------------------------------------------------------------------------------+
42
7. The system places the newly inserted blade online and it becomes active.
A short time after the system activates the blade’s license, the system places the blade online and it is
active. You can verify that the blade is online and active using the tmsh show sys cluster command on the
primary blade. The output of the command appears similar to the following example:
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
Address 192.0.22.0/24
Availability available
State enabled
Reason Cluster Enabled
Primary Slot ID 1
Primary Selection Time 0
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
Address
| ID Availability State Licensed HA Clusterd |
+------------------------------------------------------------------------------+
| 4 :: unknown disabled false unknown shutdown |
+------------------------------------------------------------------------------+
Note If your system is running BIG-IP 12.0.0 or later, you can use the disk-firmware-update.pl script to
update the firmware on storage drives, that is, hard disk drives (HDDs) or solid-state drives (SSDs), that are
installed in a BIG-IP platform or VIPRION blade.
43
VIPRION—Additional resources
Table 4.3 Additional VIPRION resources

K11843: After installing an additional VIPRION blade,
VIPRION blades rebooting
the new blade may reboot continuously
K14255: The B4300 blade may fail to join the cluster
VIPRION blades failing to join a cluster
and reboot continuously
K10633: BIOS update may be required before
Installing on the VIPRION installing BIG-IP version 10.1.0 or later on the
VIPRION platform
Configuring network failover for redundant K13915: Configuring network failover for redundant
VIPRION systems VIPRION systems (11.x - 12.x)
K10633: BIOS update may be required before
Installing on the VIPRION installing BIG-IP version 10.1.0 or later on the
VIPRION platform
Configuring network failover for redundant K13915: Configuring network failover for redundant
VIPRION systems VIPRION systems (11.x - 12.x)
Storage Drive Maintenance in BIG-IP LTM F5
Firmware
Platforms: Essentials
44
DRIVE MAINTENANCE—Background
Drive Maintenance
F5® has identified the following drive maintenance recommendations:
• Prevent disk utilization issues.
• Prevent full root file systems.
• Perform disk space cleaning.
• Understand how SMART check works.
• Check remaining lifetime on solid state drives (SSDs).
• Monitor RAID.
• View pendsect reporting for BIG-IP® 11.2.1 HF-8, BIG-IP 11.3.0 HF-6, and BIG-IP 11.4.0 systems to help
identify drive failures.
Background
information, including the following:
• Understanding the LVM disk-formatting scheme.
• Identifying symptoms of a full/near full disk.
Logical volume management disk-formatting scheme
BIG-IP 11.x and later uses logical volume management (LVM) disk-formatting. LVM is an enhanced software image
manager used for deploying logical storage on a physical storage device or devices. 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 file
systems 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. In addition, the system
allocates a certain amount of disk space for the shared volume, and the log volume.
Identifying symptoms of a full or nearly full disk
When the BIG-IP file systems become full, undesirable or unpredictable behavior may result. Symptoms of a full or
nearly full disk may include warning messages and/or traps from the diskmonitor utility or daemon log messages.
45
Diskmonitor utility messages
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 the system reaches one or more of these thresholds, diskmonitor logs a
message 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
The following message indicates that the /shared partition is growing quickly:
diskmonitor: 011d004: Disk partition shared exceeded growth limit 10%
In addition, the BIG-IP system sends the following SNMP trap alerts when the partition space reaches a defined
threshold:
bigipDiskPartitionWarn (“The disk partition free space is very limited, which is less than a specified limit. By
default, the limit is set.to 30% of total disk space.”)
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”}
bigipDiskPartitionGrowth “The disk partition exceeds the specified growth limit. By default, the limit is set to 5% of
the total disk space. The growth is difference of two consecutive monitoring data.”
alert BIGIP _ DMON _ ERR _ DMON _ GROWTH { snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.26”}
Daemon log messages
If your disk is full or nearly full, daemon log messages may appear similar to the following example:
Couldn’t write to <file> / <partition> Failed to open file
The system performance may degrade, and you may see symptoms such as slow or failed disk writes. You may be
unable to sync configurations or save a UCS file.
File storage
This section provides guidelines for optimal disk maintenance.
Storing maintenance-related files
To help prevent disk usage issues, F5 recommends maintaining 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 doing maintenance or
46
troubleshooting-related tasks on the system.
For example, you should store tcpdump files, UCS archives, or qkview files in the /shared/tmp directory.
F5 recommends using the /shared/tmp directory for maintenance-related files for the following reasons:
• 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 longer-term storage
such as UCS archives or SCFs, 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 -ni1.1 –w /shared/tmp/example-tcpdump.pcap
The following qkview command saves the corresponding support file to the /shared/tmp directory:
qkview -f /shared/tmp/example-qkview.tar.gz
The following TMOS® Shell (tmsh) command saves the corresponding UCS file to the /shared/tmp directory:
tmsh save /sys ucs no-private-key /shared/tmp/example- config.ucs
Avoid storing files in directories that reside on the root file system. The BIG-IP system has a relatively small root file
system, and has separate partitions for file systems, such as /config, /usr, and /shared. Directories, such as /
home reside on the root file system, and you should not use them 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. As you remove old images, removing the old files in /
shared/images avoids filling this partition.
Checking available disk space
To check available disk space, you can use the df -h command. For example, the following df -h output indicates
that the root file system is at 100 percent usage:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vgdbsdaset.1.root 380M 214M 147M 60% /
/dev/mapper/vgdbsdaset.1.config 3.0G 77M 2.8G 3% /config
/dev/mapper/vgdbsdaset.1. _ usr 2.7G 2.0G 643M 76% /usr
/dev/mapper/vgdbsdaset.1. _ var 3.0G 415M 2.4G 15% /var
47
/dev/mapper/vgdbsdadat.share.1 20G 269M 19G 2% /shared
/dev/mapper/vgdbsdadat.log.1 485M 32M 428M 7% /var/log
none 2.0G 956K 2.0G 1% /dev/shm
none 2.0G 30M 2.0G 2% /shared/rrd.1.2
none 2.0G 5.5M 2.0G 1% /var/tmstat
none 2.0G 1.2M 2.0G 1% /var/run
prompt 4.0M 28K 4.0M 1% /var/prompt
none 2.0G 0 2.0G 0% /var/loipc
Periodically check the inode usage on the BIG-IP system. 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 Inodes IUsed IFree IUsed% Mounted on
/dev/md 765536 3384 62152 6% /

/dev/md9 393216 307 392909 1% /config
/dev/md8 219520 28044 191476 13% /usr
/dev/md10 393216 393216 0 100% /var
/dev/md0 3932160 200 3931960 1% /shared
/dev/md1 917501 159 917345 1% /var/log
none 1023877 39 1023838 1% /dev/shm
none 1023877 27 1023850 1% /var/tmstat
none 1023877 182 1023895 1% /var/run
prompt 1023877 4 1023873 1% /var/prompt
/dev/md15 1572861 188 1572676 1% /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 checking for and removing non-critical maintenance files.

In many cases, non-critical maintenance files are apparent and can be safely removed. For example, old
tcpdump, qkview files, 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 type the following command syntax:
find <dir> -xdev -type f | xargs du | sort -rn | head -20
For example, the find command below was used to locate the 20 largest files in the /shared partition, some of
which can be safely removed, such as the 2 GB tcpdump file, and the 18 MB core file:
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
48
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
Diskmonitor utility
The diskmonitor utility is a script that runs periodically on the BIG-IP system to monitor disk use. The
diskmonitor utility does the following:
• Monitors BIG-IP system 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 runs when disk use approaches critical levels
The following partitions are monitored, by default:
root = /
config = /config dev _ shm = /dev/shm
shared = /shared usr = /usr
var = /var
var _ log = /var/log var _ run = /var/run
49
Configuration variables for the diskmonitor utility
The database (db) variables allow customization of the diskmonitor utility on a per partition basis, as well as the
option to disable the diskmonitor utility.
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.
Table 5.1 Logging and error conditions

Error or warning condition Message number Message report Description
syslog-
ng<logfacility>.<severity The bigpipe db utility
No diskmonitor entries in
level> 011d0002 cannot find any Platform.
database.
: local0.error DiskMonitor db keys.

The mcpd process needs
syslog- Cannot access the
to be running for
ng<logfacility>.<severity 011d0002 database because mcpd diskmonitor to get its db
level>: local0.warning is not running. key configuration.
The diskmonitor utility
syslog-
Error parsing df -k could not get the free
ng<logfacility>.<severity 011d0003
output. space percentage from df
level>: local0.warning
-k.
The monitored
syslog- Disk partition
partition<partition> has
ng<logfacility>.<severity 011d0004 <partition> has only
only a critical amount of
level>: local0.error <percentage> free.
free space left.
sends a warning message
syslog- Disk
because the monitored
ng<logfacility>.<severity 011d0005 partition <partition>has
partition has less free
level>: local0.warning only <percentage> free.
space remaining than the
warning level specifies.
detects that the usage in
Disk the monitored partition is
syslog-ng<logfacility>
partition <partition>exceed growing quickly (the
.<severity level>: local0. 011d0006
ed growth limit <growth usage exceeded the
warning
percentage>. growth percentage after
its last monitored
interval).
50
DRIVE MAINTENANCE—Procedures
Procedures
This section details how to complete the following drive maintenance tasks:
Monitoring RAID
Some F5 devices—notably the 6900, 8900, and 8950 platforms—have two redundant disks set up in a RAID array.
The RAID array can be degraded if there is a problem with one of the disks. This section describes how to monitor
your system to be certain the RAID system has both disks participating, and information on repair if you need to
replace a disk.
Managing log files on the BIG-IP system
The following prerequisites are necessary to manage log files:
• You must have command-line access to the BIG-IP system.
• You should have familiarity with using a Linux text editor.
You can configure the following log-related elements on the BIG-IP system:
• Change the log rotation frequency.
• Change the age at which log files become eligible for removal.
• Change the number of archive copies that the system retains
• Add a custom option to the log rotation process.
Preventing full file systems
Store scratch data in the /shared partition. Scratch data is data you want to stage for deployment on or retrieve
from the BIG-IP system, including troubleshooting data. Ideally, you should remotely store all scratch data in a
central repository such as CVS or Git, but if this is not possible, the /shared partition is the best option because
data placed here is visible and shareable.
For more information, refer to AskF5 article K13367 Manage log files on the BIG-IP system (11.x - 12.x).
Performing disk space cleaning
Monitoring the hard disk capacity on a BIG-IP system is critical to maintaining its health. If a BIG-IP 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 and taking action when you reach a threshold defined by your
processes and procedures.
51
SMART checking your disks
Self-monitoring, analysis, and reporting technology (SMART) checks are not generally necessary on BIG-IP 10.2.4
HF7, BIG-IP 11.2.1 HF8, BIG-IP 11.3.0 HF6, or BIG-IP 11.4.0 and later.
A SMART test runs as part of the EUD process, which F5 recommends that you run annually.
SMART checks help you detect whether a disk is likely to fail. In BIG-IP 11.2.1 HF8, BIG-IP 11.3.0 HF6, and BIG-IP
11.4.0, the pendsect utility detects SMART errors on most platforms and produces logging that recommends
action, including running SMART through the EUD process.
In BIG-IP 11.4.0 and later, you can also use the platform_check command to collect the SMART test data from
the drive. The disk portion of the command output indicates a Pass or Fail status for the drive and logs detailed
information to the /var/log/platform_check file.
SMART check SSDs
SMART checks can be used on your solid-state disks (SSDs) as well. This is a command-line method to get to the
same information that is available through the Configuration utility.
A SMART test is run as part of the EUD process recommended on an annual basis.
The only valid SMART attribute for SSDs is the Media Wearout Indicator.
To run SMART checks on SSDs using tmsh at the command line
1. Determine the disk drives you have in your system.
tmsh
run util bash fdisk -1
To determine the name of your SSD at the command line
smartctl -a /dev/sda | grep 233
The returned result appears similar to the following:
233 Media _ Wearout _ Indicator 0x0032 100 100 000 Old _ age Always - 0
The code 233 indicates the attribute number of the Media_Wearout_Indicator.
The hex value 0x0032 is a flag and is unimportant for this analysis. The following number is the
value from 0 to 100. A value of 100 indicates 100 percent of the disk life remains; a value of 0
indicates that the disk has reached the maximum number of writes expected from the drive.
52
Using TRIM
SSDs should have TRIM support turned on by default on F5 systems that include them. TRIM support slightly
reduces the amount of space available on your SSDs and improves their performance by keeping pages available
as the system overwrites memory. TRIM runs automatically and should not interfere with the amount of space
available for data.
Check remaining write lifetime on SSDs
If you are using SSDs for the datastor process on the 11000 or 11050 systems, or if you are using SSDs for main
storage for new appliances, you can view the SSD allocation and monitor the SSD lifespan.
To view the SSD allocation and monitor the SSD lifespan using the Configuration utility
1. Under System, click Disk Management.
2. View details about the SSDs, including the following:
• To view the general properties of a disk, in the Logical View area, click disk label.
• In the Physical View area, note which bays contain the SSDs.
• In the Data Disks area, view the Media Wearout Indicator to monitor disk usage.
Monitoring RAID status
There are four ways to receive monitoring data for RAID status on a BIG-IP system:
• The Configuration utility notes that the RAID status is degraded if one of the disks is offline.
• BIG-IP iHealth® displays an error at the top of your page if you view a qkview file where one of the two disks
in a RAID array is offline.
• tmsh allows you to view RAID status by typing the following command:
showsysraidarray
• Syslogs provide information when you search for the following phrase:
alert kernel: raid1: Disk failure
Note If there are any results of this search, it tells you which disk has had a problem.
If any of these methods show a degraded RAID status, contact F5 Support because it is likely you need to replace
a disk.
Repairing disk errors on BIG-IP systems with RAID storage
If both disks show data loss or you suspect other issues, contact F5 Support for assistance.
If you have a replacement disk from F5 and need to rebuild your RAID array, refer to the appropriate platform guide
53
for your hardware platform.
Note You must explicitly remove the old disk from the RAID from the array and manually add the new disk
before the new disk is operational.
For more information on repairing disk errors, refer to Ask F5 article: K12756: Repairing disk errors on RAID-
capable BIG-IP platforms.
Viewing pendsect reporting to help identify actual drive failures
In BIG-IP 11.2.1 HF8, BIG-IP 11.3.0 HF6, and BIG-IP 11.4.0, the pendsect feature of TMOS helps improve disk
error detection, correction, and messaging on the drives in the following:
• 1600
• 3600
• 3900
• 6900
• 8800
• 8900
• 8950
• 11000
• 11050
• 2000
• 4000
• 5000
• B4100 blades with 160Gb drives,
• B4200
• B4300
• B2100
• B2150
The pendsect utility helps you identify actual drive failures and reduce the number of unnecessary return material
authorizations (RMAs) your operations center processes. The software periodically checks for pending sector
alerts and resolves them. It is configured to run daily and provides improved disk error detection and correction.
The system logs the pendsect messages to the /var/log/user.log file. When the pendsect process runs and no
errors are detected or corrected, the system logs messages that appear similar to the following example:
warning pendsect[21788]: pendsect: /dev/sdb no Pending Sectors detected
54
DRIVE MAINTENANCE—Additional resources
When the pendsect process detects and corrects an error, the system logs messages that appear similar to the
following example:
warning pendsect[19772]: Recovered LBA:230000007
warning pendsect[19772]: Drive /dev/sda partition UNKNOWN warning pendsect[19772]:

File affected NONE
When the pendsect process detects an error and is unable to correct the error, the system logs messages that
appear similar to the following example:
warning pendsect[20702]: seek(1) error[25] recovery of LBA:226300793 not complete

warning pendsect[20702]: Drive: /dev/sda filesystem type:
Undetermined warning pendsect[20702]: File affected: NONE
If pendsect reports an error, you cannot correct, or if you suspect a possible disk failure, you can run the EUD
SMART test to test the drive.
Using the fsck utility
The fsck utility runs automatically on restart, so it does not require an administrator to manually run it on BIG-IP
units.
Table 5.2 Additional drive maintenance resources

K14426: Hard disk error detection and correction
Pendsect improvements (versions 11.4.1, 11.4.0, 11.3.0, 11.2.1,
and 10.2.4)
K12380: RAID capable BIG-IP platforms report the
RAID status degraded after a hard drive RAID status as degraded in the Configuration utility
replacement after a hard drive replacement (versions 11.4.1,
11.4.0, 11.3.0, 11.2.1, 11.2.0, 11.1.0, and 11.0.0)
K13654: Replacing a disk may cause a reboot loop
Restart loop after disk replacement on BIG-IP 6900, 8900, or 8950 platforms (versions
11.4.1, 11.4.0, 11.3.0, 11.2.1, 11.2.0, 11.1.0, and 11.0.0)
K12756: Repairing disk errors on RAID-capable
Repairable disk errors BIG-IP platforms (versions: 11.5.0, 11.4.1, 11.4.0,
11.3.0, 11.2.1, 11.2.0, 11.1.0, and 11.0.0)
K11965: Disabling RAID drive mirroring (versions
Upgrading to 11.0 or 11.1 without using RAID
11.1.0 and 11.0.0)
55
DRIVE MAINTENANCE—Additional resources

K14269: Attempting to modify an undefined RAID
array may result in error or an unexpected format of
Modifying a system with an undefined RAID array
the hard drive (versions 11.3.0, 11.2.1, 11.2.0, 11.1.0,
and 11.0.0)
Platform Maintenance in the appropriate Platform
Replacing the hard drive Guide for your system. Refer to Additional
Resources in “VIPRION”.
K14426 Hard disk error detection and correction
Hard disk error detection
improvements
56
LICENSES AND ENTITLEMENT—Background
Licenses and Entitlement

F5® has identified the following license and entitlement recommendations:
• Check for license expiration.
• Check that your licenses are valid.
• Schedule license renewals.
Background
information, including information on the following topics:
• Licenses
• Provision licensed modules
• License Virtual Edition (VE) and appliances
Licenses
When you purchase support from F5, it is associated with a particular BIG-IP® system. A system with an active
support contract is considered entitled until such time as the contract expires. When a support contract expires,
the system is not entitled to support until the contact is renewed.
Licenses are also associated with the modules you purchase to run on the system. These model licenses are
add-ons to the main license for your system. Add-on licenses are automatically linked to the main BIG-IP system
license and eligible for technical support as long as that system is entitled.
Major software upgrades are only supported for entitled systems and require relicensing the BIG-IP system. Minor
upgrades do not require relicensing.
F5 recommends checking your BIG-IP system entitlement every six months.
For more information, refer to AskF5™ article: K7752: Overview of licensing the BIG-IP system.
Provisioning licenses
If you install a license for an add-on module on a BIG-IP system, you must provision resources for the module.
Until provisioned, module function is limited in the following ways:
• The system does not perform the functions of the licensed module.
• Items related to the module do not appear in Configuration utility menus.
57
LICENSES AND ENTITLEMENT—Procedures
• The TMOS® Shell (tmsh) does not present or permit configuration of objects related to the module.
• The bigstart status command returns output similar to the following example for daemons related to the
unprovisioned module:
<daemon _ name> down, Not provisioned
For information on provisioning modules, refer to “Modules”.
Note In some versions, configuration objects related to unprovisioned modules are incorrectly exposed.
For more information, refer to AskF5 article: K10376: The Configuration utility allows configuration of
unprovisioned modules.
When you upgrade a BIG-IP system, the install script verifies the Service Check Date with the license check date
of the version being installed. If the service check date is missing or the verification process finds your license
pre-dates the software’s release date, a line displays in the /var/log/liveinstall.log with a note about the service
check date verification, and the installation of the software may continue.
Evaluation and subscription service licenses
Evaluation licenses and subscription service licenses granted by F5 have their own subscription service and
expiration dates. When an evaluation license ends, the module becomes inactive and all configuration items are
expected to cease functioning.
When a subscription period ends, the system service no longer receives updates. In the case of the IP Intelligence
service, the IP address database becomes outdated.
The subscription-based feature is expected to continue functioning as designed, but with outdated data.
BIG-IP Application Security Manager attack signatures
BIG-IP Application Security Manager™ (ASM®) attack signatures do not update if the Service Check Date is not
within 18 months of the system date. BIG-IP ASM attempts to update the service check date automatically. If it
cannot reach the license server and the Service Check Date is less than seven days from the system date,
BIG-IP ASM attempts an attack signature update anyway. After seven days from the system date, you may have to
manually reactivate the system license and re-initiate the attack signature update.
Procedures
This section details how to complete the following licensing and entitlement tasks:
Reactivating a BIG-IP system license
Before you do a software upgrade, F5 recommends you reactivate BIG-IP system license.
To reactivate your BIG-IP system license using the Configuration utility
1. Navigate to System > License.
58
2. Click Re-activate.
3. In the Activation Method area, select Automatic (requires outbound connectivity).
4. Click Next.
The BIG-IP software license renews.
Viewing and verifying a BIG-IP system license
You can test the validity of the BIG-IP software license by obtaining license information in any of the following
ways:
• View license information at the command line.
• Request a product license profile from F5.
• View license profile in BIG-IP iHealth®.
• View license profile in the Configuration utility.
To view license information at the command line
tmsh show /sys license
Output displays licensing information for the BIG-IP system, including a list of active modules.
For a system with a valid license, output appears similar to the following example:
Sys::License
Licensed Version 11.4.1
Registration key Txxxx-xxxxx-xxxxx-xxxxx-xxxxx26 Licensed On 2014/03/14
License Start Date 2014/03/13 License End Date 2014/04/14 Service Check Date
2014/03/14 Platform ID
Z100
Active Modules
ASM, 5Gbps, VE (G536528-5957369)
IPV6 Gateway Rate Shaping Ram Cache
50 Mbps Compression Client Authentication AFM, VE Routing Bundle, VE PSM,

VE
If your system license is not properly installed, basic system functionality is lost, and the tmsh command output
does not show the active modules enabled on the system.
59
Output for a system with a missing license appears similar to the following example:
Can’t load license, may not be operational
To inspect the expiration date at the command line
grep trust /config/bigip.license
The system returns an IP intelligence license key value that appears similar to the following
example:
20120809 _ subscr _ trusted _ i 290345338
The initial eight-digit response indicates the system license expiration date in YYYYMMDD format.
To check query the status of the IP Intelligence at the command line
tmsh show sys iprep-status.
Output returns the following information:
• Date and time that the BIG-IP system last contacted the vendor server the date
• Time that the BIG-IP system last received an update
• Total number of IP addresses in the database
• Number of IP addresses in the most recent update
For more information, refer to AskF5 article: K13776: Determining the IP intelligence subscription expiration date.
Note Another subscription service you may want to monitor is the WhiteHat Sentinel web application
vulnerability scanner. That subscription is managed on the WhiteHat website. For more information, refer to
AskF5 article: K11926: Integrating BIG-IP ASM with WhiteHat Sentinel.
To request a product license profile from F5
1. Navigate to the F5 Product Information Request page (secure.f5.com/validate/validate.jsp)
2. Enter your contact email.
3. In the F5 Licenses / Serial Numbers field, type the serial number(s) or base registration key(s).
4. Click Submit Info Request.
A license summary for the entered registration keys is sent to the email address you entered.
60
Note In BIG-IP 12 and later, if you attempt to install a license that is not compatible, the system warns
you that the new license could cause a lack of functionality an ask you to confirm if the new license
should be installed.
The email appears similar to the following example:
From: F5 Networks®
Sent: Monday, January 1, 2017 12:34 AM To: John Doe
Subject: Information for F5 Keys
ABCDE-FGHIJ-KLMNO-PQRST-UVWXYZA
#------------------------------------------------------------------#
# F5 License Information Server#
# Thank you for requesting a product license profile
# from F5 Networks. To better understand the information
# provided below, you may want to refer to the Product License
# Profile solution on AskF5 for definitions of the values included
# in the profile.#
#------------------------------------------------------------------
#------------------------------------------------------------------#
F5 License Information for ABCDE-FGHIJ-KLMNO-PQRST-UVWXYZA
#-----------------------------------------------------------------
Serial Number : bip012345s (D68)F5 Product
: F5-BIG-LTM-6800-E2 BIG-IP SWITCH:
LTM 6800 ENTERPRISE (4GB MEM, 2GBCMP,20KSSL,RS,Usage :ProductionEntitled

Service :
12-31-2016 - 12-31-2017 (F5-SVC-BIG-PRE-9)Warranty Date :12-31-2017
----------------------------------------------------
Base Key for BIG-IP 9.x
----------------------------------------------------
F5 Platform : D68
Activation Date : 12-31-2017
Base RegKey : UVWXYZA (Locked)
BIG-IP Mac Address : 00:01:a1:23:b0:45
Add-on: ABCDEFG (Active) BIG-IP LTM
61
Add-on : HIJKLMN(Active) BIG-IP LTM Enterprise 6800
#-----------------------------------------------------------------
# Copyright © 1999-2017, F5 Networks, Inc.# All rights reserved.
#----------------------------------------------------------------—
Licensing information in BIG-IP iHealth
• If your system is nearing the end of support entitlement, a banner message appears on the main Status
page.
To inspect the expiration date using the Configuration utility
2. Locate the entry for the IPI Subscription module
The expiration date is listed beneath the IPI Subscription entry, for example:
Subscription expires after Aug 9, 2017.
As the expiration date approaches, a banner warning also displays on the license page when you
log in to the Configuration utility.
Note The ProductionEntitled Service and Warranty Date fields specify the date of service coverage and
the service part number.
Licensing the BIG-IP system
Before you can configure and use the BIG-IP system, you must activate a valid license on the system.
To license the BIG-IP system, you must complete the following procedures:
• Obtain a registration key.
• Obtain a dossier.
• Activate the license.
Note If you have received a replacement BIG-IP device for a Return Materials Authorization (RMA), refer to
AskF5 article: K12880: Configuring a replacement BIG-IP device after an RMA for configuration assistance.
Obtaining a registration key
Before you can activate the license for the BIG-IP system, you must obtain a base registration key. The base
registration key is a 27-character string that instructs the license server which F5 products you can license. The
base registration key is pre-installed on new BIG-IP systems.
When you navigate to the Configuration utility, the Licensing page displays the registration key.
62
The format of the BIG-IP base registration key is as follows:
AAAAA-BBBBB-CCCCC-DDDDD-EEEEEEE
If you do not have a base registration key, contact your F5 Sales representative, or F5 Support.
Moving a BIG-IP VE license

BIG-IP Virtual Edition (VE) licenses are permanently associated with the virtual instance. If you need to move that
virtual edition instance, you typically have to call F5 Technical Support to move the license. However, in BIG-IP
12.1.3.3 and BIG-IP 13.1 and later, you can move the RegKey without contacting support. You can revoke the
instance’s license from tmsh, the Configuration utility, and iControl/REST by using tmsh revoke sys license
command on that virtual instance. This revokes the license and unlocks the RegKey so that you can use it again to
activate a new virtual machine.
If you want to move the license but you’ve lost connection to the current virtual edition, the hypervisor crashes, or
you’ve forgotten the password or network address, then you need to call F5 Technical Support for assistance.
Note: If your BIG-IP system is licensed by BIG-IQ you must contact the BIG-IQ administrator to revoke and
reactivate your license. However, if the BIG-IP VE system is removed from BIG-IQ and mcpd is restarted,
you can manage your license by navigating to Licensing.
Obtaining a dossier
The dossier is an encrypted list of key characteristics used to identify the platform, which you can obtain from the
BIG-IP software. It is generated by your F5 product after you choose a license activation method and appears
similar to the following truncated example:
efe3bef1df38cb46ca4c1f82f6d03a02ea2d8da4d26767cb801c1e4b4024
08b1f763a09ff571ca860e4d61ebdb010aeee8c86de7966c267436cbe27e
6d9900db229c2b96ddc4bf48c54cd18a34d028c99819146b532de7216b6e
9c631db79175e6a18d180300ffa75befa36025721ede7efea2949512bd0a
f4f25e3ebc5d194a405dc57fe1da0599e2f8b1c21ad01a1557dd10d4a5b5
b34dbcf76046fc6f60ab5d06006f13061fab336ade7ed14a7df7a9dce32d
277bcfb6ff456931e91933b1c895aa79cfd235c39fcb83f4528475712001
7e7a44a8c2be423c71c1be7eee9d0a2b5572e39e9dd6b4af5a118172dfa2
5347d0061ed0208e30bb0119f4c66fa4642b4612b68c8c7df7cdce862ad7
efe55c615603fa3fa77f8929f99d236c927f0d2bb00f382c42030c1b7ff0
Activating the BIG-IP system license
If your BIG-IP system is not yet licensed to you, you may be prompted for the base registration key or an add-on
registration key.
To activate the license on the BIG-IP system using the Configuration utility, you can use either the automatic
activation method or the manual activation method. The activation method specifies the method by which you want
the system to communicate with the F5 license server.
Note To activate the license on the BIG-IP system at the command line, refer to AskF5 article: K2595:
Activating and installing a license file at the command line.
63
You can use the automatic method if the BIG-IP management port is configured to route traffic to the Internet. You
should use the manual method if the BIG-IP management port is not configured to route traffic to the Internet.
To activate a license using the manual activation method
1. Log in to the Configuration utility.
2. Click Activate.
3. Click Manual.
4. Click Next.
5. Copy the dossier, and navigate to F5 Product Licensing (https://secure.f5.com/validate/validate.

jsp).
6. On the Licensing Tools page, click Activate F5 product registration key for BIG-IP 9.x and later.
7. Paste the dossier into the Enter your dossier field, and then click Next.
8. Copy the license returned by Product Licensing and paste it into the License field in the
9. Click Next.
Note If your BIG-IP system is new, when logging in, open a web browser on a work station attached to the
network on which you configured the management port, then, type the following URL in the browser:
https://<IP address>/. <IP_address> is the address you configured for the management port.
Important This process briefly interrupts traffic processing while the BIG-IP system reloads the
configuration.
Activating an add-on module
BIG-IP feature modules can be added to a BIG-IP device for additional functionality. Adding a feature module
requires you to obtain an add-on registration key, and re-activate the license. After you obtain an add-on
registration key, you can activate the feature using the Configuration utility.
The BIG-IP add-on registration key appears in the following syntax:
AAAAAAA-BBBBBBB
To re-activate the license with the Add-On registration using the manual activation method
1. Log in to the Configuration utility.
3. Click Re-activate.
64
4. Paste the Add-On registration key into the Add-On Key field and click Add.
5. Click Manual.
6. Click Next.
7. Copy the dossier and navigate to F5 Product Licensing (https://secure.f5.com).
8. On the F5 Licensing Tools page, click Activate F5 product registration key for BIG-IP 9.x and
later.
9. Paste the dossier into the Enter your dossier field, and click Next.
10. Copy the license returned by Product Licensing and paste it into the License field in the
11. Click Next.
Important Traffic processing is briefly interrupted while the BIG-IP system reloads the configuration
Provisioning licensed modules in your BIG-IP system
You must provision a module before you can use it.
To provision a licensed module using the Configuration utility
1. Navigate to System > Resource Provisioning.
2. Select the check box for each licensed module.
3. Select either Minimum or Nominal for each licensed module.
4. After making the necessary provisioning changes, click System.
5. Click Configuration, click Device, and then click Reboot to restart the system.
6. When prompted, click OK to confirm the restart operation.
Validating license compliance levels
vCMP Guests
The vCMP license allows you to deploy the maximum number of guests that the specific blade platform allows. For
more information, refer to AskF5 article: K14218: vCMP guest memory/CPU core allocation matrix.
When your system exceeds the licensed compression limit, the following events occur:
• The BIG-IP system logs the following message to the /var/log/ltm file:
65
LICENSES AND ENTITLEMENT—Additional resources
Compression license limit of <limit> Mbit/s exceeded today
• The BIG-IP system logs the following message once per day:
bigipCompLimitExceeded (“The compression license limit is exceeded.”)
• The BIG-IP system sends an SNMP trap with the following Object ID: OID=.1.3.6.1.4.1.3375.2.4.0.35.
SSL TPS license
When SSL TPS limits have been reached, a log message shows up in /var/log/ltm as follows:
tmm tmm[1253]: 01260008:3: SSL transaction (TPS) rate limit reached
Tip You can search for the previous message to determine if your system has exceeded these limits. In
addition, you can review performance graphs for current SSL TPS and compression levels for more
guidance on purchasing additional licenses.
Table 6.1 Additional licensing and entitlement resources

K7727: License activation may be required prior to
License activation prior to software upgrades software upgrade for the BIG-IP or Enterprise
Manager system.
K3782: Finding the serial number or registration key
Finding the serial number or reg key on your system
of your BIG- IP system.
SSL TPS licensing limits K6475: Overview of SSL TPS licensing limits.
K13469: Determining the compression capability of

Determining BIG-IP compression capabilities
your BIG-IP system (11.x).
BIG-IP ASM attack signature updates K8217: Updating the BIG-IP ASM attack signatures.
66
BACKUP AND DATA RECOVERY—Background
Backup and Data Recovery

F5® has identified the following backup and data recovery recommendations:
• Create a user configuration set (UCS) archive and store the file on a remote backup server.
• Create a UCS archive before and after making significant changes to your system and before upgrades.
• Store UCS archive files on a secure remote backup server.
• Restore a UCS archive on the same unit in which the archive was created, or same platform type in the case
of a return materials authorization (RMA).
• Create a single configuration file (SCF) if you are planning to copy the configuration across multiple BIG-IP®
systems.
• Load the default SCF to restore the factory default settings.
Background
information. It includes the following topics:
• UCS archives
• Backing up configuration data
• Restoring configuration data
• SCFs
BIG-IP software offers two supported methods for backing up and restoring the configuration: UCS archives and
SCFs. To create, delete, upload, or download an archive, you must have either the administrator or resource
administrator role privileges.
UCS archives
A UCS archive contains BIG-IP configuration data that can fully restore a BIG-IP system in the event of a failure or
RMA.
Each time you back up the configuration data, the BIG-IP system creates a new UCS archive file in the /var/local/
ucs directory. In addition to configuration data, each UCS file contains various configuration files necessary for the
BIG-IP system to operate correctly.
A UCS archive contains the following types of BIG-IP system configuration data:
• System-specific configuration files (traffic management elements, system and network definitions, and
others)
67
• Product licenses
• User accounts and password information
• Domain Name Service (DNS)
• Zone files
• Installed SSL keys and certificates
Note A typical UCS archive contains the SSL private keys associated with client and server SSL profiles. It
also contains user accounts, passwords, and critical system files, unless explicitly excluded during the
backup process.
If your UCS archive contains SSL private keys, store backup UCS archives in a secure environment.
Backing up and restoring configuration data
You can use UCS archives to back up and restore the data. F5 recommends using this feature to mitigate potential
loss of BIG-IP system configuration data.
Determining archiving frequency
F5 recommends creating an archive at the following times:
• On a monthly basis for backup purposes
Note F5 recommends storing the file on a remote backup server.
• Before you upgrade a BIG-IP system
• Before and after you make significant changes to your system, such as adding or modifying iRules or editing
configuration settings
• According to your company’s practices and specific industry requirements
Saving UCS archives
When you save a UCS archive, the system by default stores it in the 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 TMOS® Shell (tmsh).
To identify the file easily, F5 recommends that you include the BIG-IP host name and current time stamp as part of
the file name.
F5 recommends keeping a backup copy of your UCS archives on a secure remote server. In the unlikely event you
need to restore your BIG-IP system and are unable to access the /var /loca/ucs directory on your BIG-IP system,
you can upload the backup file from the remote server and use it to restore your system.
Important A typical UCS archive contains the SSL private keys associated with client and server SSL
profiles. It also contains user accounts, passwords, and critical system files, unless explicitly excluded
68
during the backup process.
If your UCS archive contains SSL private keys, store backup UCS archives in a secure environment.
Note If you set Encryption to Enabled under System > Archives > General Properties when creating an
archive, the BIG-IP system encrypts the UCS archive file.
Restoring configuration data from a UCS archive
When restoring configuration data, 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.
F5 also recommends that you only restore a UCS file to another platform of the same model as the one where the
UCS file was created. Certain core hardware changes can cause a UCS to fail to load properly on dissimilar
hardware, requiring manual intervention to correct.
If your system configuration has been customized to reference files that are not included in the default BIG-IP
installation, refer to AskF5™ article: K4422: Viewing and modifying the files that are configured for inclusion in a
UCS archive.
For more information, refer to AskF5 article: K175: Transferring files to or from an F5 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 high availability (HA) pair, F5 recommends that you configure basic networking on
the replacement unit and synchronize the configuration from its peer rather than restoring it from a UCS archive.
Synchronizing the units allows the peer to share the master key with the new system.
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 pass phrases with unencrypted versions, and save the resulting configuration.
If you are restoring a backup that contains SSL private key pass phrases 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 pass phrases 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, before going further, refer to AskF5 article:
K9420: Installing a UCS file containing an encrypted pass phrase.
69
Use UCS archive to restore a system outside the device cluster
You can install a UCS file onto a BIG-IP system that is outside the cluster of the system that generated the archive.
The SecureVault key is hard-coded into the device hardware, so the SSL private key pass phrases are not
decrypted.
Installing UCS archive on BIG-IP DNS

If you want to install a UCS archive on a BIG-IP DNS™ (formerly Global Traffic Manager™/GTM™) system, for an
RMA replacement for example, and prevent the BIG-IP DNS system from synchronizing the contents of the UCS
archive to the BIG-IP DNS synchronization group, refer to AskF5 article: K14083: Preventing synchronization when
installing a UCS archive on a BIG-IP GTM system.
For a BIG-IP DNS RMA unit that is licensed and provisioned with the BIG-IP DNS module and the DNSSEC
feature, refer to AskF5 article: K13542: Restoring DNSSEC configuration data to a BIG- IP GTM RMA unit.
Restoring a UCS file with BIG-IP Application Security Manager
If you are restoring a UCS file that is licensed and provisioned with the BIG-IP Application Security Manager™
(ASM®) module, you may need to provision the system for BIG-IP ASM before loading the UCS file. For more
information, refer to AskF5 article: K13945: The BIG-IP ASM MySQL database is not installed completely if BIG-IP
ASM is not provisioned when the UCS is loaded.
Restoring a UCS file on a redundant pair
If you are restoring a UCS file on a BIG-IP unit that is part of a redundant pair, refer to AskF5 article: K8086:
Replacing a BIG-IP system in a redundant pair without interrupting service.
Restoring a UCS file on a vCMP host or vCMP guest
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 doing 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 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 chapter.
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.
70
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. It 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.)
For more details on replacing a VIPRION chassis, refer to AskF5 article: K14302: Replacing a VIPRION chassis that
has one or more blades installed.
Licensing
The BIG-IP license is associated with a specific hardware serial number. The UCS archive contains the license of
the BIG-IP system from which the configuration was saved.
To install a UCS archive file on a BIG-IP system successfully, you must do one of the following actions:
• Restore the UCS archive to the same system from which it was saved.
• 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.
• Contact F5 Support to have the license associated with the serial number of a new system.
Important F5 Support associates a license file with a new serial number only on an as-needed basis in the
event of a return materials authorization (RMA).
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 BIG-IP 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 BIG-IP system reports a Provisioning Warning message in the Configuration utility, as well
as the status of ModuleNotLicensed in its command line.
71
SCFs
A single configuration file (SCF) is a flat text file that contains a series of 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.
Note An SCF does not contain SSL certificate or key files.
F5 recommends creating an SCF when you are planning to migrate the BIG-IP configuration to another device.
You can use an SCF to copy system configuration to multiple BIG-IP systems. This helps create a secure and
consistent BIG-IP LTM® environment on your network.
For added security, F5 recommends the SCF to a remote location until you are ready to install.
For more information, refer to Ask F5 article: K13408: Overview of single configuration files (11.x - 12.x).
File location and naming
By default, SCF files are saved to the /var/local/scf/ directory with the name you specify and the .scf extension.
Example:
tmsh save /sys config file bigip1
The previous command saves the current configuration as /var/local/scf/bigip1.scf.
Installing an SCF
When you install an SCF on a target BIG-IP system, the system first saves the currently running configuration to
the /var/local/scf/backup.scf, and then loads the specified SCF into running memory. For example, the tmsh
load /sys config file bigip1 command saves the currently running configuration to the /var/local/scf/backup.scf
before loading the /var/local/scf/bigip1.scf on the system.
Note Run tmsh save sys config to save the current BIG-IP system configuration to an SCF. Unsaved
changes are not be reflected in the SCF.
Using an SCF to restore a BIG-IP system configuration to factory default settings
You can load the default SCF to reset the BIG-IP configuration to the factory default setting. When you restore the
BIG-IP configuration to factory default settings, the system does the following tasks:
• Removes all BIG-IP local traffic configuration objects
• Removes all BIG-IP network configuration objects
• Removes all non-system maintenance user accounts
• Retains the management IP address
• Removes system maintenance user account passwords (root and admin)
72
BACKUP AND DATA RECOVERY—Procedures
Procedures
This section details how to complete the following backup and recovery tasks:
Using tmsh help sys config command
For information regarding the options available you can use the tmsh help sys config command.
This procedure is an example that shows how to get information regarding the user-only option.
To use tmsh help sys config at the command line
tmsh
help /sys config
user-only
4. Press Enter.
5. To move to the next instances of the user-only option, press n.
6. To exit from the tmsh command help, press q.
7. To exit tmsh, type quit, then press Enter.
Tip You can also navigate through the tmsh help using the Up and Down arrows on your keyboard.
Viewing a list of existing UCS archives
You can view a list of archives (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
To view a list of existing archives using the Configuration utility
• Navigate to System > Archives.
A list of existing UCS files displays.
73
Note If you have upgraded your BIG-IP system, a UCS file named config.ucs was created in the process.
This UCS file should appear in this list.
Creating and saving a UCS archive on the BIG-IP system
When you create a new archive, unless otherwise directed, the BIG-IP system automatically stores it in a default
location, the /var/local/ucs directory. You can create as many archives as you want, as long as each archive has a
unique file name.
You can specify that the BIG-IP system store an archive in a directory other than /var/local/ucs; however those
archives are not displayed in the Configuration utility Archives list.
All boot locations on a BIG-IP system use the same /shared directory, which makes it a good choice for a UCS
save location. Saving an archive to the /shared directory allows you boot to another boot location and access the
archive. This can greatly simplify recovery from a variety of issues.
When you create an archive, you can configure some settings. The following table lists and describes these
settings, including default values, if they exist.
Table 7.1 Default UCS archive encryption values

Settings Description Default value
Specifies the file name for the archive. You do not
need to specify the UCS file name extension. The
File Name No default value
BIG-IP system appends the UCS extension
automatically.
Enables or disables encryption of the archive. If you
Encryption click Enabled, you are asked to type and verify a Disabled
Passphrase
Specifies a password that a user must use to decrypt
Passphrase No default value
an archive.
Specifies the password that you defined with the
Verify Passphrase No default value
Passphrase setting.
Specifies whether to include or exclude private keys in
Private Keys Included
the archive.
Displays the version of the BIG-IP system application
Version that is currently running on the BIG- IP hardware No default value
platform. You cannot configure the Version field.
74
To create a UCS archive file using the Configuration utility
1. Navigate to System > Archives.
2. Click Create.
Note If the Create button is unavailable, you do not have permission to create an archive. You must have
administrator role privileges assigned to your user account to create an archive.
3. Type a unique file name.
F5 recommends 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.
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
4. If you want to encrypt the archive, for Encryption click Enabled.
5. If you want the BIG-IP system to include any private keys, click Include for Private Keys.
If you choose to include private keys, be sure to store the archive file in a secure environment.
6. Click Finished.
7. Once the data has been backed up and the file created, click OK.
To download and copy an archive to another system using the Configuration utility
2. Click the UCS file name you want to download.
3. In the General Properties field, click Download <filename.ucs>.
4. Click Save file and save the file.
5. Find the file in your computer’s Downloads folder and copy it.
To create a UCS archive file using tmsh at the command line
tmsh
2. Save your running configuration by typing the following command:
save sys config
75
3. Create the UCS archive file by typing the following command syntax:
save /sys UCS </path/to/ucs>
Replace <path/to/ucs> with the full path to the UCS archive file.
For example:
save /sys UCS /var/tmp/Myucs.ucs
Optional: If you want to encrypt the UCS archive with a passphrase, type the following command
syntax:
save /sys UCS <path/to/ucs> passphrase <password>
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. For example:
save /sys UCS /var/tmp/Myucs.ucs passphrase password
Optional: If you want to exclude SSL private keys from the UCS archive, type the following
command syntax:
save /sys ucs <path/to/ucs> no-private-key
Replace <path/to/ucs> with the full path to the UCS archive file. For example:
save /sys ucs /var/tmp/Myucs.ucs no-private-key
4. Copy the UCS file to another system.
Viewing UCS archive properties
Using the Configuration utility, you can view the properties previously created archives.
Note You cannot modify the properties of an archive. If you want to make changes, you have to delete the
archive and create a new one.
The viewable properties of an archive include:
• 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
To view the properties of an archive using the Configuration utility
76
2. Click the name of the archive that you want to view.
The archive’s General Properties display.
Restore data from a BIG-IP system UCS 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.
Note The BIG-IP system replaces any existing configuration with the UCS archive file configuration.
To restore a configuration in a UCS archive using the Configuration utility
2. 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.
3. 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.
4. To return to the Archive List page, click OK.
If you restore a UCS archive on a different device and receive activation errors, you need to
reactivate the BIG-IP system license. To ensure that the configuration is fully loaded after
relicensing, restart the system by navigating to System > Configuration, then click Reboot.
If the system you restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World.
For additional information about recovering FIPS information after a system recovery, refer to Configuring and
Maintaining a FIPS Security Domain chapter in Platform Guide: 6900 or Platform Guide: 8900.
To restore configuration data using tmsh at the command line
tmsh
2. Restore the UCS archive file by using the following command syntax:
Replace <path/to/ucs>
3. Use the full path of the UCS archive file you want to restore using the following command syntax:
load /sys UCS <path/to/ucs>
77
Note If you do not specify the path, the BIG-IP system looks for the UCS archive file in the default /var/
local/ucs directory.
If the UCS archive file was encrypted during backup, you are prompted to type the passphrase for
the archive file.
Optional: If you are running your BIG-IP system on 6400, 6800, 8400, or 8800 hardware platform,
type the following command to switch to the bash shell:
run /util bash
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) type the following
command:
keyswap.sh sccp
4. At the command line, type to switch back to tmsh:
exit
5. 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 a reactivation
error, 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.
If the system you restored contains the FIPS 140 HSM, you must configure the FIPS 140 HSM Security World. For
additional information about recovering FIPS information after a system recovery, refer to Configuring and
Maintaining a FIPS Security Domain in Platform Guide: 6900 or Platform Guide: 8900.
Restore a UCS 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.
To restore configuration data on a replacement RMA unit using tmsh at the command line
1. Activate the license on the unit according to the steps detailed AskF5 article: K7752: Overview of
78
licensing the BIG-IP system.
tmsh
3. Restore the UCS archive file by using the following command syntax.
load /sys UCS <path/to/ucs> no-license
4. Replace <path/to/ucs> with the full path of the UCS archive file you want to restore.
5. If the UCS archive file was encrypted with a passphrase during the backup, you are prompted to
type the passphrase for the archive file.
6. If you are running the BIG-IP system on a 6400, 6800, 8400, or 8800 hardware platform, switch to
the bash utility by typing the following command:
run /util bash
7. To verify that the new or replaced SSH keys from the UCS file are synchronized between the
BIG-IP and the SCCP, type the following command:
keyswap.sh sccp
8. To switch back to tmsh, type the following command:
exit
9. Restart the system by typing the following command:
reboot
Note If you do not specify the path, the BIG-IP system does as if the UCS archive file is located in the
default /var/local/ucs directory.
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 Configuring and Maintaining a FIPS Security Domain in Platform Guide: 6900 and 8900.
Restoring UCS archives on BIG-IP systems running newer software versions
F5 recommends that you restore a UCS archive on a system running the same BIG-IP software version as the
system you used to create it. It is possible to restore a UCS archive on a system running a newer software version,
if the older version is supported by the upgrade.
For example: there is a supported upgrade path between BIG-IP 10.x and BIG-IP 11.x, so you can successfully
restore a BIG-IP 10.x UCS archive file on a BIG-IP system running v11.x. However, there is no supported upgrade
path between BIG-IP 9.x and BIG-IP 11.x, so you cannot restore a BIG-IP 9.x UCS archive file on a BIG-IP system
running v11.x.
For information about supported upgrade paths, refer to the product release notes for your specific software
79
version.
To restore UCS archives on BIG-IP systems running newer software versions
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.
2. Manually copy the UCS archive file to the /var/local/ucs/ directory on the target system.
3. Restore the UCS archive on the BIG-IP system.
Important The BIG-IP system replaces any existing configuration with the UCS archive file configuration.
Downloading a UCS archive to a remote system
You can download a copy of an existing archive to a remote system. This feature protects the configuration data in
the unlikely event you need to restore your BIG-IP system and are unable to access the /var /loca/ucs directory
on your BIG-IP system.
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 where you want to save the archive copy.
To download an archive using the Configuration utility
2. Click the name of the archive that you want to view.
The General Properties for that archive display.
3. Click Download: <ucs filename>.
4. Click Save.
The BIG-IP system downloads a copy of the UCS file to the system from which you initiated the
download.
Uploading a UCS archive from a remote system
If a UCS archive on your BIG-IP system is unavailable or corrupted for some reason, you can upload a previously
created archive copy from a remote or backup system to replace it.
To upload an archive using the Configuration utility
2. Click Upload.
3. Type the complete path and file name of the archive that you want to upload onto the BIG-IP
80
system.
If you do not know the path or file name, click Browse and navigate to the location.
4. For the Options setting, click the Overwrite existing archive file field if you want the BIG-IP
system to overwrite any existing archive file.
5. Click Upload.
The specified archive uploads to the /var/local/ucs directory on the BIG-IP system.
Note The BIG-IP system overwrites an existing file with the uploaded file only when the name of the archive
you are uploading exactly matches the name of an archive on the BIG-IP system.
Deleting a UCS 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 using the Configuration utility
2. Select the check box next to the name of the file you want to delete.
3. Click Delete.
4. Click Delete again.
The archive is deleted from the /var/local/ucs directory on the BIG-IP system.
Managing UCS files for a VIPRION
When managing UCS archives for the VIPRION® platform, F5 recommends that you create the UCS archive while
connected to the management port. Doing so ensures that the UCS contains configuration data from all VIPRION
blades in the chassis.
Restoring a UCS archive to a different hardware platform
Restoring a UCS archive to a hardware platform other than the one used to create the archive is not supported. F5
recommends using an SCF instead.
Working with SCFs
To view a list of the existing SCFs on the BIG-IP system using tmsh at the command line
81
tmsh
2. To display the list of SFC files, type the following command:
list /sys config file.
To create and save an SCF on the BIG-IP system using tmsh at the command line
tmsh
4. To save the running configuration to an SCF, type the following command syntax:
save /sys config file <name>
The SCF is saved to the /var/local/scf/ directory.
Important Store the backup SCFs containing sensitive information in a secure location.
To view the properties and contents of the SCF at the command line
• Type a Linux command such as cat to view the contents of the SCF.
Example:
cat the /var/local/scf/scf _ filename
To restore data from an SCF using tmsh at the command line
tmsh
2. To install an SCF on a BIG-IP system, type the following command syntax:
load /sys config file <name>
3. Type Y at the following prompt to load the SCF:
Replace the running configuration? (y/n)
To copy configuration data to a different platform using SCF
1. Build a BIG-IP LTM template configuration by configuring a system using the Configuration utility
or tmsh.
2. Save an SCF from the fully-configured system using the tmsh save /sys command.
3. Store the SCF in a secure location.

The SCF can be used as a template to configure future BIG-IP systems.
82
4. When you are ready to use the SCF to configure a new BIG-IP system, copy the SCF to the new
BIG-IP system, then edit the SCF using a text editor prior to importing it.
For example: Change the IP addresses, routing information, interface settings and other common
settings, as needed.
Note SCFs are version-specific. In versions 11.5.0 and later, there are version-specific parsers for all
supported versions. For previous versions, you may need to note both syntax and semantic differences
when migrating between versions.
5. To install the SCF into a new system using the tmsh load /sys command.
To delete an SCF using tmsh at the command line
tmsh
2. To delete the SCF, use the following syntax:
delete /sys config file <file _ name>
For example, to delete the SCF named bigip1, type the following command:
delete /sys config file bigip1
Using the SCF to restore the factory default settings
To restore the BIG-IP configuration to the factory default setting using tmsh at the command line
tmsh
load sys config default
3. Type Y at the following prompt:
Reset the system configuration to factory defaults? (y/n)
4. Save the change by typing the following command:
save sys config partitions all
Note When managing SCFs for the VIPRION platform F5 recommends that you create the SCF while
connected to the management port.
83
BACKUP AND DATA RECOVERY—Additional resources
Table 7.2 Additional backup and data recovery resources

UCS archives K4423: Overview of UCS archives
K13132: Backing up and restoring BIG-IP
Backing up and restoring UCS files
configuration files (11.x - 12.x)
K8465: Viewing and extracting the contents of an
Working with encrypted UCS files
encrypted UCS archive file
Working with files configured for inclusion in a UCS K4422: Viewing and modifying the files that are
file configured for inclusion in a UCS archive
K13408: Overview of single configuration files (11.x
Working with SCFs
- 12.x)
84
SOFTWARE UPDATES—Procedures
Software Updates
F5® has identified the following software update recommendations:
• Subscribe to F5 TechNews and Security mailing lists.
• Check for software updates.
• Find the latest software.
• Check for OPSWAT downloads.
• Download and install updates to the IP geolocation database.
• Check for BIG-IP® Application Security Manager™ ASM® and DPI signatures.
Background
information.
In BIG-IP® 11.5.0 and later, F5 the Automatic Update Check (phone home) feature is enabled by default.
If your device has access to the F5 software download servers using the internet, this feature automatically checks
for BIG-IP software updates on a weekly basis and lists the updates in the Configuration utility, including relevant
links.
If you use this feature, you d not have to check for the latest software updates manually. For more information
refer to AskF5™ article: K15000 Using the Automatic Update Check feature.
In addition to updates to the BIG-IP operating software, F5 provides additional updates for features like the IP
Geolocation database, OPSWAT, and BIG-IP ASM security updates. Updates for these features are managed
separately from the core BIG-IP updates. F5 recommends that administrators keep these features updated to
ensure your BIG-IP system has current information and protection against the latest security threats.
Note You can only do major software upgrades if the BIG-IP system is entitled under a current technical
support contract. For more information about entitlement, refer to “Licenses and Entitlement”.
Procedures
This section details how to complete the following software update tasks:
Getting security updates
F5 recommends regular and timely acquisition of F5 security updates, BIG-IP ASM attack signature updates, and
OPSWAT updates.
85
When F5 discovers remote vulnerabilities, F5 implements, tests, and releases security hotfixes for any vulnerable,
supported version and sends an email alert to the F5 Security mailing list. F5 encourages customers with an active
support account to subscribe to this list. For more information, refer to AskF5 article: K4602: Overview of the F5
security vulnerability response policy.
To sign up for security mail lists
1. Navigate to AskF5 (support.f5.com).
2. From the Self-Help menu, click Subscribe: Mailing Lists.
3. Type your email address.
4. Select Security Updates, and click Submit.
Subscribing to TechNews
AskF5 Publications Preference Center provides email publications to help keep administrators up-to-date on
various F5 updates and other offerings:
• TechNews Weekly eNewsletter Up-to-date information about product and hotfix releases, new and
updated articles, and new feature notices.
• TechNews Notifications Do you want to get release information, but not a weekly eNewsletter? Sign up to
get an HTML notification email any time F5 releases a product or hotfix.
• Security Alerts Receive timely security updates and ASM attack signature updates from F5.
AskF5 recent additions and updates
You can subscribe to F5 RSS feeds to stay informed about new documents pertaining to your installed products or
products of interest. The Recent additions and updates page on AskF5 provides an overview of all the documents
recently added to AskF5.
New and updated articles are published over RSS. You can configure feeds that pertain to specific products,
product versions, and/or document sets. You can also aggregate multiple feeds into your RSS reader to display
one unified list of all selected documents.
Finding the latest software
Release notes for the version of software you want to install are contain instructions for the specific installation.
To find the latest software version for your F5 product
1. Navigate to F5 Downloads (downloads.f5.com).
3. Find the product you want to download and click the link for the appropriate version.
86
4. Find and click the link for the update you want to download.
5. Read and accept the End User Software license agreement.
6. Click the file name, choose a download location, and then save the file to your computer.
Before upgrading your BIG-IP software
Before you upgrade the BIG-IP software, review the release notes on AskF5 (support.f5.com) in the
Documentation section for your product and version. Pay close attention to the following items:
• Ensure that the new version supports your hardware.
• Review the Known issues list.
• Review the Behavior change section(s).
• Review the Upgrading from earlier versions section.
• Review the Upgrading from earlier configurations section.
• Review the installation checklist.
Updating OPSWAT packages for BIG-IP Access Policy Manager
The BIG-IP Access Policy Manager® (APM®) antivirus and firewall client-side checks use software libraries from a
software development kit (SDK) created by OPSWAT, Inc. OPSWAT periodically issues new versions of the SDK
libraries to support new security products and resolve bugs in the software. F5 distributes these updates in the
form of hotfixes.
To view OPSWAT version information using the Configuration utility (BIG-IP 11.2.1 and later)
1. Navigate to System > Software Management.
2. Under Antivirus Check Updates click Device EPSEC Status.
3. From local device / device group, click the local device or a device group you want to check:
To view OPSWAT version information using the TMOS® Shell (tmsh) at the command line
tmsh
2. Display the version by typing the following command:
show apm epsec software-status
87
+---------------------------------------------------------------------------------+
| Epsec:: Software Device OESIS Previous Previous

Status Version OESIS Version Installed OESIS
version Installed Version
+----------------------------------------------------------------------------------+
| /common/
1.0.0-192.0 3.6.5595.2 1.0.0-192.0 3.6.5595.2 success | bigip1121.test.lab

+-----------------------------------------------------------------------------------+
To view OPSWAT version information at the command line
epsec version
2. Output appears similar to the following example:
Version: 1.0.0-160.
OSDK Version: 3.5.2461.2
Installation Date: Thu Dec 6 16:25:57 PST 2014
#APM Endpoint Inspection Plugin for Linux
#APM Endpoint Inspection Plugin for Mac OS X
#APM Endpoint Inspection Libraries for Windows
To view OPSWAT versions available at the command line
epsec version
Version: 1.0.0-160.
0SDK Version: 3.5.2461.2
Installation Date: Thu Dec 6 16:25:57 PST 2012
#APM Endpoint Inspection Plugin for Linux
#APM Endpoint Inspection Plugin for Mac OS X
#APM Endpoint Inspection Libraries for Windows
To view available OPSWAT versions at the command line
88
epsec list
No updated endpoint security packages available.
Package: epsec-1.0.0-283.0.iso(installed)
Version:1.0.0-283.0
SDK Version:3.6.8392.2
To install an OPSWAT hotfix from the Configuration utility (BIG-IP APM 11.2.1 and later)
1. Download the OPSWAT hotfix from F5 Downloads (downloads.f5.com).
Note For instructions about how to obtain a hotfix, refer to AskF5 article: K167: Downloading software
from F5.
2. Log in to the BIG-IP Configuration utility.
3. Navigate to System > Software Management.
4. Click Antivirus Check Updates.
5. Click Upload Package.
6. Click Browse.
7. Select the hotfix file you downloaded.
8. On the Install Option menu, click the appropriate installation option.
Note The Do Not Install option uploads the EPSEC package without installing it.
9. If you clicked the Install on Autosync enabled Device Group option, on the Device Group
89
menu, click the device group.
10. Click Upload.
11. After the software uploads, click OK.
Note The upload process may take a couple of minutes.
BIG-IP Access Policy Manager® (APM®) is now running the OPSWAT package.
12. To confirm that the installation was successful, review the Installed Version field under the
Device EPSEC Status tab.
To install an OPSWAT hotfix using tmsh at the command line (BIG-IP APM 11.0 and later)
1. Download the OPSWAT hotfix from the F5 Downloads page (downloads.f5.com).
Note For instructions about obtaining a hotfix, refer to AskF5 article: K167: Downloading software from F5.
2. Use a secure copy (SCP) utility to copy the file you downloaded in step 1 to the BIG-IP system’s /
shared/apm/images folder.
tmsh
4. Create a new package by typing the following command:
create apm epsec epsec-package <package name> local-path <path/filename>
Replace the <package name> variable with the name the BIG-IP system uses to identify the
package and <path/filename> with the path and name of the EPSEC file copied to the BIG-IP
device.
Example:
create apm epsec epsec-package epsec-1.0.0- 196.0.iso local-path /shared/apm/

images/epsec- 1.0.0-196.0.iso
Note When using the Configuration utility, the BIG-IP system uses the file name as the package name by
default. You may rename the package.
5. Install the new package by using the following command syntax:
install apm epsec epsec-package <package name>
Replace the <package name> with the name of the package you created in the previous step.
Example:
install apm epsec epsec-package epsec-1.0.0- 196.0.iso
90
6. To validate the package was installed, type the following command:
show apm epsec software-status
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 You can only access the ISP and organization-level geolocation data for IPv4 addresses using the
iRules® where is command. For more information, about iRules, search DevCentral™.
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 sales representative to purchase
additional database files.
You can download a monthly update to the IP geolocation database from F5.
To download and install an update to the IP geolocation database
1. Navigate to F5 Downloads (downloads.f5.com).
3. Under Product Line, click the appropriate BIG-IP software branch (for example, BIG-IP 11.x).
4. Select your BIG-IP version.
5. Click GeoLocationUpdates.
6. Read and accept the license agreement.
7. Click the ip-geolocation zip file.
8. Select a download location.
9. Save the file to your computer.
To install the geolocation database update at the command line
1. Copy the ip-geolocation zip and MD5 files you downloaded from F5 Downloads (downloads.f5.
com) to the /shared/tmp directory on the BIG-IP system.
2. Log in to the command line.
3. Change the working directory to the /shared/tmp directory by typing the following command:
91
cd /shared/tmp
4. Open and extract the RPM files by typing the following command syntax:
unzip </path/to/zipfile>
Replace </path/to/zipfile> with the path to the zip file on the BIG-IP system:
Example:
unzip /shared/tmp/ip-geolocation-1.0.1- 20140627.30.0.zip
The output appears similar to the following example:
Archive: ip-geolocation-1.0.1-20140627.30.0.zip
inflating: geoip-data-Region2-1.01.- 20140627.30.0.i686.rpm
inflating: geoip-data-ISP-2.0.1-20140627.30.0.i686.rpm
inflating: geoip-data-Org-1.0.1-20140627.30.0.i686 rpm
5. For each RPM file you extracted, type the following command syntax:
geoip _ update _ data -f </path/to/rpm>
Replace </path/to/rpm> with the path to the RPM file.
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.
Verify that the geolocation database was loaded with a 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
The output appears similar to the following example:
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
92
For information about transferring files to the F5 system, refer to AskF5 article: K175: Transferring files to or from an
F5 system.
Fixing issues with incorrect IP geolocation installations
If you install the IP geolocation database files incorrectly, the incorrect installation might change the SELinux
security context for the database files.
The BIG-IP system uses an IP geolocation database to determine the origin of an IP address. F5 releases the
updates to the database in the GeoLocationUpdates container on F5 Downloads (downloads.f5.com). When
installing or updating the IP geolocation database files, you should upload the IP geolocation ZIP archive file to the
/shared/tmp directory on the BIG-IP system.
When you extract the database files, the BIG-IP access control mechanism (SELinux) applies the appropriate
security context to the database files, and the system installs the files to the /shared/GeoIP directory.
If you upload the IP geolocation ZIP archive file to a different directory on the BIG-IP system (for example, /root/)
and then extract the database files, the SELinux module may apply the incorrect security context to the files. When
this occurs, the system may fail to load the IP geolocation database properly.
Restoring the proper security context to the IP geolocation database files
To restore property security context to the IP geolocation database files, you need compare the inode numbers to
verify that the Traffic Management Microkernel (TMM) and gtmd processes have loaded the correct database files.
To compare inode numbers at the command line
ls -i /shared/GeoIP/F5GeoIPISP.dat ; lsof 2>/dev/null | grep F5GeoIP
If the gtmd (1376259) and TMM (80575) inode numbers do not match for the F5GeoIPISP.dat
database file, the output appears similar to the following example:
1376259 /shared/GeoIP/F5GeoIPISP.dat
gtmd 5871 root mem REG 9,0 66127452
966660 /shared/GeoIP/F5GeoIPRegion2.dat
gtmd 5871 root mem REG 9,0 567630 3915778
/shared/GeoIP/F5GeoIPv6.dat
gtmd 5871 root mem REG 9,0 194864440
966658 /shared/GeoIP/F5GeoIPOrg.dat
gtmd 5871 root mem REG 9,0 5373413
1376259 /shared/GeoIP/F5GeoIPISP.dat
tmm10612 root mem REG 9,0 66127452
93
SOFTWARE UPDATES—
/shared/GeoIP/F5GeoIPRegion2.dat
966660
tmm10612 root mem REG 9,0 567630
/shared/GeoIP/F5GeoIPv6.dat
3915778
tmm10612 root mem REG 9,0 194864440
966658/shared/GeoIP/F5GeoIPOrg.dat
tmm10612 root mem REG 9,4 3993525 80575
/usr/share/GeoIP/F5GeoIPISP.dat
Note In this case, TMM has loaded the incorrect database file from /usr/share/GeoIP/F5GeoIPISP.dat.
To verify the security context of the database files in the /shared/GeoIP directory at the command line
ls -Z /shared/GeoIP/
If the security context for the F5GeoIPISP.dat file is root:object_r:default_t, which is preventing
the system from properly loading the IP geolocation database, the following output appears similar
to the following example:
lrwxrwxrwx root root root:object _ r:shared _ geoip _ t F5GeoIP.dat -> /shared/

GeoIP/F5GeoIPRegion2.dat
-rw-r--r-- root root root:object _ r:default _ t F5GeoIPISP.dat
-rw-r--r-- root root system _ u:object _ r:shared _ geoip _ t F5GeoIPOrg.dat
-rw-r--r-- root root system _ u:object _ r:shared _ geoip _ t F5GeoIPRegion2.dat
-rw-r--r-- root root system _ u:object _ r:shared _ geoip _ t F5GeoIPv6.dat
To restore the proper SELinux security context to the geolocation database files
restorecon -Rv /shared/GeoIP/ ; tmsh load sys geoip
EUD
The EUD software is installed with the BIG-IP software on hardware platforms. From time to time, F5 releases
updates to the EUD software. For information about the EUD tool and updating the EUD software installed on the
BIG-IP system, refer to “Hardware Diagnostics”.
94
SOFTWARE UPDATES—Additional resources
Table 8.1 Additional software updates resources

Phone home K15000: Using the Automatic Update Check feature
K4602: Overview of the F5 security vulnerability
Security updates
response policy
Software downloads K167: Downloading software and firmware from F5
Transferring file to or from the BIG-IP system K175: Transferring files to or from an F5 system
K10942: Installing OPSWAT hotfixes on BIG-IP APM

OPSWAT systems
K14207: Determining the active OPSWAT version
EUD “Hardware Diagnostics”
95
NETWORKING AND CLUSTER HEALTH—Background
Networking and Cluster Health

F5® has identified the following networking and cluster health recommendations:
• Monitor the system (SNMP, Statistics, and AVR) for any changes in normal network performance.
• Follow suggested practices for configuring communication channels between BIG-IP systems in device
services clustering high availability (HA) configurations.
• Configure the BIG-IP® system to synchronize its clock with an NTP server.
Background
information.
Network health
Monitoring network operations on the BIG-IP system and collecting statistical data for use in network traffic
analysis are important practices. Information derived from these tasks can provide vital insights into the overall
health of your BIG-IP system as a member of your network.
F5 provides several tools for monitoring the status of the BIG-IP system’s network functionality.
Statistics dashboard in the Configuration utility
The Statistics dashboard, available by going to Statistics > Dashboard, provides an overview of critical BIG-IP
statistics, such as CPU and memory usage, total connections, SSL transactions per second (TPS), compression,
and throughput statistics.
Performance graphs in the Configuration utility
Performance graphs, available by going to Statistics > Performance, provide detailed visuals representing
various BIG-IP system and network statistics.
Snapshots of many of these same performance graphs can also be viewed within BIG-IP iHealth by uploading a
qkview file. For more information about qkview files refer to ”BIG-IP iHealth”.
BIG-IP analytics
BIG-IP Analytics, also known as Application Visibility and Reporting (AVR), is a module for the BIG-IP system, in
BIG-IP 11.0 and later, that lets you analyze performance of web applications. AVR provides detailed metrics such
as transactions per second (TPS), server latency, page load time, request and response throughput, and sessions.
You can view metrics for applications, virtual servers, pool members, URLs, specific countries, and additional
detailed statistics about an application.
96
Configuring the AVR module is beyond the scope in this guide. For more information, refer to BIG-IP Analytics:
Implementations for your software version.
Note In BIG-IP TMOS 12.1 and later, AVR can deliver statistics on TCP round-trip times.
Note For information about how to locate F5 product guides, refer to AskF5 article K12453464: Finding
product documentation on AskF5™.
SNMP
The BIG-IP system also allows for statistics gathering using SNMP, an industry-standard protocol for polling
networked devices for statistical data. F5 recommends that you implement some form of SNMP data collection,
preferably using a tool to automate, parse, and alert on trending data. Doing so can provide much-needed
historical reference into network operations, as well as help identify abnormal traffic patterns that might be
indicative of potential problems.
Interfaces
Every BIG-IP system includes multiple interfaces. The exact number of interfaces that you have on the BIG-IP
system depends on the platform type. For information on BIG-IP platform types, refer to the appropriate platform
guide.
Auto MDI/MDIX behavior for BIG-IP interfaces
An auto MDI/MDIX port detects straight through or crossover Ethernet cable connection types and automatically
configures the connection. This behavior eliminates the need for crossover cables when connecting LAN devices.
BIG-IP system interfaces support auto MDI/MDIX as follows:
• The BIG-IP system management port supports auto MDI/MDIX. The management port is a special interface
dedicated to doing a specific set of system management functions. The MDI/MDIX functionality is retained
when you manually configure the management interface to use specific speed and duplex settings.
• The BIG-IP system Traffic Managment Microkernel (TMM) supports auto MDI/MDIX functionality MDI/MDIX
is retained when you manually configure an interface to use specific speed and duplex settings. You can use
either a straight-through cable or a crossover cable when media settings are forced, and you can
successfully link to either data terminal equipment (DTE) or data circuit-terminating equipment (DCE)
devices.
• The BIG-IP system TMM switch interfaces are used to send and receive application traffic slated for load
balancing. TMM switch interfaces are typically named in the format of 1.1, 1.2, and so on. In the case of
VIPRION® systems, the blade number is prepended (2/1.1, for example). With respect to Virtual Clustered
Multiprocessing™ (vCMP®) guests, TMM switch interfaces are managed internally by the vCMP hypervisor,
and are delineated as 0.x, prepended with the slot ID on VIPRION systems. For example, 1/0.25, 2/0.25, and
so on.
For more information, refer to BIG-IP TMOS: Concepts for your software version.
97
Trunks suggested practices
F5 recommends that you assign trunks to VLANs in “tagged” mode (IEEE 802.1q Tagged VLANs) whenever
possible. This mode allows each interface to potentially be a member of more than one logical network.
Trunks that are “untagged” are dedicated to the single network segment of the VLAN of which they are a member.
For more information about using trunks in VLANs, refer to the BIG-IP TMOS: Concepts for your software version.
F5 also recommends that on VIPRION systems, you configure trunks that include interfaces from every blade to
ensure traffic is not interrupted in the event of a single blade failure. For more information about VIPRION
deployment, refer to VIPRION Platform Guide.
VLANs
A virtual local area network (VLAN) is a logical subset of hosts on a local area network (LAN) that operate in the
same IP address space. Grouping hosts together in a VLAN has distinct advantages.
For example, with VLANs, you can do the following:
• Reduce the size of broadcast domains, thereby enhancing overall network performance.
• Substantially reduce system and network maintenance tasks. Functionally related hosts no longer need to
physically reside together to achieve optimal network performance.
• Enhance security on your network by segmenting hosts that must transmit sensitive data.
You can group hosts into VLANs by with the Configuration utility to create a VLAN and associate physical
interfaces with that VLAN. As a result, any host that sends traffic to a BIG-IP system interface is logically a member
of the VLAN or VLANs to which that interface belongs.
For more information about VLANs, refer to BIG-IP TMOS: Concepts for your software version.
VLAN suggested practices
F5 recommends you use VLANs to segregate traffic on different network IP ranges.
When configuring BIG-IP systems in any type of high availability (HA) configuration, F5 recommends configuring a
dedicated VLAN for high availability communications. For more information for VIPRION systems, refer to AskF5
article: K13915: Configuring network failover for redundant VIPRION systems (11.x - 12.x).
Self IP addresses
A self IP address is an IP address on the BIG-IP system that you associate with a VLAN to access hosts in that
VLAN. By virtue of its netmask, a self IP address represents a range of IP addresses spanning the hosts in the
VLAN, rather than a single host address. You can associate self IP addresses not only with VLANs, but also with
VLAN groups.
Self IP addresses serve two purposes:
1. The BIG-IP system uses the self IP addresses of its VLANs when sending a message to a destination server
98
to determine the specific VLAN in which a destination server resides.
For example, if a VLAN has a self-IP address of 10.10.10.100 with a netmask of 255.255.255.0 and the destination
server’s IP address is 10.10.10.20 with a netmask of 255.255.255.255, the BIG-IP system recognizes that the
destination server’s IP address falls within the range of VLAN internal’s self IP address.
Because of this, the BIG IP system sends the message to the interface that you assigned to that VLAN. If
more than one interface is assigned to the VLAN, the BIG-IP system takes additional steps to determine the
correct interface, such as checking the Layer2 forwarding table.
2. A self IP address can serve as the default route for each destination server in the corresponding VLAN. The
self IP address of a VLAN appears as the destination IP address in the packet header when the server sends
a response to the BIG-IP system.
Normally, you assign self IP addresses to a VLAN when you initially run the Setup utility on a BIG-IP system.
You assign one static self IP address and one floating self- IP address to each of the default VLANs (internal
and external).
You can later create self IP addresses for other VLANs that you create using the Configuration utility.
For more information about self IP addresses, refer to BIG-IP TMOS: Concepts for your software version.
TMM routes
The BIG-IP system must communicate with other routers, servers, and firewalls in a networked environment.
Before you put the BIG-IP system into production, we recommend that you carefully review the router and server
configurations in your network. By doing so, you can properly configure routing on the BIG-IP system and adjust
the routing configurations on other network devices to include various BIG-IP system IP addresses.  Depending on
how you configure routing, the BIG-IP system can forward packets to a specified network device (such as a
next-hop router or a destination server), or the system can drop packets altogether.
For more information about BIG-IP routing options, refer to BIG-IP TMOS: IP Routing Administration for your
software version.
ARP
The BIG-IP system supports Address Resolution Protocol (ARP), an industry-standard Layer 3 protocol to find
MAC addresses.
The BIG-IP system is a multi-layer network device, and as such, needs to do routing functions. To do this, the
BIG-IP system must be able to find destination MAC addresses on the network, based on known IP addresses.
For more information about BIG-IP system’s use of ARP, refer to BIG-IP TMOS: IP Routing Administration for
your software version.
Management IPs and routing
Every BIG-IP system has a management port. The management port is a special interface that the BIG-IP system
uses to receive or send certain types of administrative traffic.
99
NETWORKING AND CLUSTER HEALTH—Local Authentication Fallback
You cannot use the management port for normal traffic that is slated for load balancing. Instead, the BIG- IP
system uses TMM switch interfaces for that type of traffic. TMM switch interfaces are those interfaces controlled
by TMM service.
Configuring the management port of a BIG-IP system means assigning an IP address to the port, supplying a
netmask for the IP address, and specifying an IP address for the BIG-IP system to use as a default route. The IP
address that you assign to the management port must be on a different network than the self IP addresses that
you assign to VLANs.
Note Specifying a default route for the management port is only necessary if you intend to manage the BIG-
IP system from a node on a different subnet.
Local Authentication Fallback

You can configure the BIG-IP system to authenticate from a remote server.
In BIG-IP 12.x and earlier, all users are considered remote, except for the local-only users (root and admin).
The remote server is available under the following conditions:
• Local-only users (root and admin) can log in only with local authentication.
• Local users with remote credentials can log in only with remote credentials.
• Local users without remote credentials can’t log in.
• Remote-only users can log in.
As a result, the following conditions apply:
• Local-only users (root and admin) can log in.
• Local users, with or without remote credentials, can’t log in.
• Remote-only users cannot log in.
In BIG-IP 13.0 and later, the following settings are available to modify local authentication fallback.
Note Updated authentication settings are disabled by default. If you are using BIG-IP 13.0 and later, you
must enable these settings.
• Allow remote authentication to fall back to local authentication when remote authentication is unavailable.
Note For fallback to work as expected, your user account should exist both locally and remotely.
Remote authentication credentials are allowed for the root and admin credentials. Enabling No Local Only causes
the BIG-IP system to authenticate all users remotely.
Important In BIG-IP 13.0 and later, the No Local Only setting does not exempt the root and admin
credentials. If the setting is not combined with the setting to allow remote authentication fallback, you can
be locked out of your BIG-IP system. To ensure against accidental lockout, F5 requires you to set a
database key that is not exposed in the Configuration utility or through a direct TMOS® Shell (tmsh)
100
command.
For more information about the Management Port, refer to AskF5 article: K15040: Configuring and displaying the
management IP address for the BIG-IP system.
For more information about Management Routing, refer to AskF5 article: K13284: Overview of management
interface routing (11.x - 12.x).
Centralized Management Infrastructure/HA health
Centralized management infrastructure (CMI), formerly known as device service clustering (DSC) allows device
clustering in a trust domain. It allows for basic clustering and the creation of device and traffic groups.
When running BIG-IP systems in any type of redundancy scenario, several suggested practices can be followed to
help ensure smooth operation between members of an HA implementation.
When configuring Network Failover, select self IPs to use as Failover Unicast Addresses on each unit, and use the
Management IP as Failover Multicast Addresses on each unit. This configuration provides redundant
communication channels over separate distinct network segments to ensure that a failed network link cannot
cause an erroneous failover event.
For more information, refer to AskF5 article: K14135: Defining network resources for BIG-IP, high-availability
features (11.x - 12.x).
When configuring BIG-IP systems in any type of high availability configuration, F5 recommends configuring a
dedicated VLAN for high availability communications.
For more information, refer to AskF5 article: K13915: Configuring network failover for redundant VIPRION systems
(11.x - 12.x).
F5 recommends that you assign static IP addresses to the management ports, which ensures consistent ability to
access and prevents any possible failover events caused by DHCP offering a different address for the
Management Port than expected.
If you must use DHCP, F5 recommends setting up the DHCP server to always assign the same IP address to the
BIG-IP Management Port for consistency.
In addition, CMI requires that all BIG-IP systems configured into a redundant configuration must use NTP to
prevent any issues caused by mismatched timestamps between units.
Device management HA groups with HA order failover method
In BIG-IP 13.x and later, you can use the HA score failover method (HA groups method in previous versions) in
association with the HA order failover method. Updates include the following:
• HA group failover method is called HA score failover method.
• HA group monitor is a separate option in the configuration.
• HA order can be associated with the HA Group Monitor.
101
You can configure the HA Group Monitor to monitor either the number of working trunk members, the number of
pool members marked up, or a combination of the two. The monitor bases an HA score value based on the health
monitor, and in BIG-IP 13.x and later, the score produces a binary up or down value that the system can use for
HA order. If the monitor reads down, HA order fails over to the active traffic group to the next active device.
When using HA order, devices not in the HA order list fall into a “Load Aware” category and are considered
fallback devices in the traffic group if all devices in the HA order list are marked down. This improves fault
tolerance for the cluster.
In previous versions, the HA score does not associate with HA order and devices not listed in the HA order list are
not available to become active.  
Invalid centralized management infrastructure tmsh command cleanup (BIG-IP 13.x)
Keep in mind the following centralized management infrastructure (CMI) restrictions:
• The BIG-IP system CMI automatically creates trust domains. You cannot create them.
• Only one trust domain exists. If you rename it and delete the default domain, the BIG-IP system recreates
the default domain with the default options.
• Only CMI can join or remove a peer device from a trust domain. You cannot do it yourself.
• If you modify attributes for a CMI device, you may break the device trust.
In versions prior to BIG-IP 13.0, several invalid CMI tmsh commands exist to accomplish the previously listed
actions. F5 strongly advises against using them.
The following tmsh clean-up actions are introduced in BIG-IP 13.0:
• Remove root keyword (multiple trust domains are not supported).
• Remove create cm trust-domain command (multiple trust domains are not supported).
• Remove create cm device, delete cm device, and edit cm trust-domain commands (only CMI can
perform these functions).
• Update mv cm device command to work consistently.
• Modify cm device command to support more aggressive validation to ensure you cannot modify an
attribute that may cause problems.
• Broken commands that run in previous versions exit without running and generate an error.
• Update help cm command to improve help text.
• Update list cm command to improve output format.
• Update mv cm <device> command to enable renaming of self device.
• Update restart cm command to not require root or all keyword.
• Change modify cm device [attributes] command so that only comment, description, and location
102
NETWORKING AND CLUSTER HEALTH—
attributes may be modified for remote devices.
• Change modify cm device-group < name > command so that you cannot modify the automatically
greated trust groups, device_trust_group and gtm.
• Change modify cm trust-domain to remove the root keyword. md5-fingerprint, serial, sha1-fingerprint,
and signature are read-only values.
VIPRION systems
On VIPRION® systems, F5 recommends that you wire up and configure all management IPs and routes to allow
redundant management access into the system.
Interfaces additional suggested practices
By default, BIG-IP interfaces are configured to auto-negotiate media settings. F5 recommends that you allow this
behavior whenever possible. If media settings must be manually set, refer to AskF5 article: K14107: Configuring the
media speed and duplex settings for network interfaces (11.x - 13.x).
F5 recommends that you assign interfaces to VLANs in “tagged” mode (IEEE 802.1q Tagged VLANs) whenever
possible. This mode allows each interface to potentially be a member of more than one logical network.
Interfaces that are “untagged” are dedicated to the single network segment of the VLAN of which they are a
member.
For more information about using interfaces in VLANs, refer to BIG-IP TMOS: Concepts for your software version.
Trunks
A trunk is a logical grouping of interfaces on the BIG-IP system. A trunk increases bandwidth without upgrading
hardware and provides link failover if a member link becomes unavailable. You can use trunks to transmit traffic
from a BIG-IP system to another vendor switch. Two systems that use trunks to exchange frames are known as
peer systems.
When you create a trunk, this logical group of interfaces functions as a single interface. The BIG-IP system uses a
trunk to distribute traffic across multiple links, in a process known as link aggregation. With link aggregation, a
trunk increases the bandwidth of a link by adding the bandwidth of multiple links together. For example, four fast
Ethernet (100 Mbps) links, if aggregated, create a single 400 Mbps link.
With one trunk, you can aggregate a maximum of eight links. For optimal performance, aggregate links in powers
of two (two, four, or eight links).
For more information about Trunks, refer to BIG-IP TMOS: Concepts for your software version.
103
NETWORKING AND CLUSTER HEALTH—Procedures
Procedures
This section details how to complete the following networking and cluster health tasks.
Viewing interface configuration
You can view configuration details for the interfaces with the Configuration utility or at the command line.
To view configuration details with the Configuration utility
• Navigate to Network > Interfaces : Interface List.
To view configuration details at the command line
tmsh list /net interface <interface _ name>
Viewing statistics on physical interfaces
You can display information about link status, throughput, errors, and drops for the various interfaces on your
platform with the Configuration utility or the command line.
To view the statistics on the physical interfaces from the Configuration utility
1. Navigate to Statistics > Module Statistics : Network > Interfaces.
2. In Statistics Type, click to Interfaces (default setting).
To view statistics information on the physical interfaces at the command line
tmsh show /net interface
Viewing VLAN configuration information with SNMP
You can configure the BIG-IP system with SNMP traps and an SNMP agent that sends data to an SNMP manager.
You can then use the collected data to help you troubleshoot the BIG-IP system.
To view VLAN configuration information through Simple Network Management Protocol (SNMP)
• Navigate to object identifier:
F5-BIGIP-SYSTEM-MIB::sysVlan
For more information, refer to Monitoring BIG-IP System Traffic with SNMP.
104
Viewing TMM routes configuration
You can view statically configured Traffic Management Microkernel (TMM) routes using the Configuration utility or
at the command line.
To view TMM routes configuration using the Configuration utility
• Navigate to Network > Routes
To view TMM routes configuration at the command line
tmsh list /net route
To view the entire TMM routing table at the command line
tmsh show /net route
Viewing TMM information with SNMP
To view TMM routes configuration through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysRoute
Viewing TMM information with SNMP
To view ARP configuration through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysArpNdp
105
Viewing ARP configuration
You can view configured ARP entries with the Configuration utility or at the command line.
To view statically generated ARP entries with the Configuration utility
• Navigate to Network > ARP : Static List.
To view dynamically generated entries with the Configuration utility
• Navigate to Network > ARP : Dynamic List.
To view statically configured ARP entries at the command line
tmsh list /net arp
ARP monitoring
To view the entire ARP table at the command line
tmsh show /net arp
Viewing IP configuration details
You can view the IP configuration details with the Configuration utility or at the command line.
To view IP configuration with the Configuration utility
• Navigate to System > Platform.
To view IP configuration at the command line
tmsh list /sys management-ip
To view configured management routing at the command line
tmsh list /sys management-route
106
Monitoring IP configuration
To view the management routing table
ip route show table 245
Viewing IP configuration information with SNMP
To view IP configuration information through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysAdminIp
Viewing self IP configuration
You can view the configuration details with the Configuration utility or at the command line.
To view network configuration with the Configuration utility
• Navigate to Network > Self IPs.
To view network configuration at the command line
tmsh list /net self
Viewing self IP configuration information with SNMP
To view self IP configuration information through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysSelfIps
107
Viewing interface information with SNMP
To view interface information through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysInterfaces
Viewing VLAN configuration details
You can view VLAN configuration details with the Configuration utility or at the command line:
To view VLAN configuration details with the Configuration utility
• Navigate to Network > VLANs : VLAN List.
To view configuration at the command line
tmsh list /net vlan
To view statistics information for the interfaces assigned to the VLAN on the command line
tmsh show /net vlan
To configure Network Failover with the Configuration utility
• Navigate to Device Management > Devices : Device Connectivity > Network Failover.
Viewing trunk details
If you have configured trunks, you can view the configuration details with the Configuration utility or the command
line.
To view trunk details with the Configuration utility
• Navigate to Network > Trunks : Trunk List.
108
To view trunk details at the command line
tmsh list /net trunk
Monitoring trunks
You can view information about link status, throughput, errors and drops for trunks on your platform. You can view
these statistics with the Configuration utility or at the command line.
Note vCMP guests inherit VLAN tags from the vCMP hypervisor, so there is no way for guest admins to
manage guest VLAN tags directly.
To view trunk statistics with the Configuration utility
1. Go to: Statistics > Module Statistics : Network > Interaces.
2. In Statistics Type, click Trunks.
To view trunk statistics at the command line
tmsh show /net trunk
Viewing trunks information with SNMP
To view trunks information through Simple Network Management Protocol (SNMP)
F5-BIGIP-SYSTEM-MIB::sysTrunks
Configuring the BIG-IP system to synchronize its clock with an NTP server
F5 recommends configuring the BIG-IP system to synchronize its clock with an NTP server. You can use tmsh to
modify or list the NTP settings, as appropriate, for your installation. To do so, configure the BIG-IP system to use
an NTP server, list the NTP servers configured on the BIG-IP system, or remove the NTP server configuration.
To configure the BIG-IP system to use an NTP server using tmsh at the command line
109
tmsh
2. Configure one or more NTP servers for the BIG-IP system using the following command syntax:
modify /sys ntp servers add {hostname hostname....}
or
modify /sys ntp servers add {ip _ addr ip _ addr....}
For example, to add NTP servers with the 192.168.1.245 and 192.168.1.246 IP addresses, enter
the following command syntax:
modify /sys ntp servers add {192.0.2.5 192.0.2.6}
save /sys config
Verifying NTP peer server communications
To use the ntpq utility to query the NTP server and print a summary of the NTP server’s state
ntpq -np
The command returns the fields listed in the following table.
Table 9.1 Ntpq command returns
Field Definition
An asterisk ({}{*}) character indicates that the peer has been declared the system peer
and lends its variables to the system variables.
A plus sign (+) indicates that the peer is a survivor and a candidate for the combining
prefix to the
algorithm.
remote field
A space, x, period (.), dash (—), or hash (#) character indicates that this peer is not
being used for synchronization because it does not meet the requirements, is
unreachable, or is not needed.
remote The remote field is the address of the remote peer.
The refid field is the Reference ID, which identifies the server, or reference clock with
which the remote peer synchronizes, and its interpretation depends on the value of
the stratum field (explained in the st definition).
For stratum 0 (unspecified or invalid), the refid is an ASCII value used for debugging.
refid
Example: INIT or STEP. For stratum 1 (reference clock), the refid is an ASCII value
used to specify the type of external clock source. Example: NIST refers to NIST
telephone modem. For strata 2 through 15, the refid is the address of the next lower
stratum server used for synchronization.
110
Field Definition
The st field is the stratum of the remote peer. Primary servers (servers with an
external reference clock such as GPS) are assigned stratum 1. A secondary NTP
server, which synchronizes with a stratum 1 server, is assigned stratum 2. A
st secondary NTP server, which synchronizes with a stratum 2 server, is assigned
stratum 3.
Stratum 16 is referred to as “MAXSTRAT,” is customarily mapped to stratum value 0,

and therefore indicates being unsynchronized. Strata 17 through 255 are reserved.
t The t field is the type of peer: local, unicast, multicast, or broadcast.
when The when field is the time since the last response to a poll was received (in seconds).
The poll field is the polling interval (in seconds). This value starts low (example: 64)
poll and over time, as no changes are detected, this polling value increases incrementally
to the configured max polling value (example: 1024).
The reach field is the reachability register. The octal shift register records results of
reach
the last eight poll attempts.
The delay field is the current estimated delay; the transit time between these peers in
delay
milliseconds.
The offset field is the current estimated offset; the time difference between these
offset
peers in milliseconds.
The jitter field is the current estimated dispersion; the variation in delay between
jitter
these peers in milliseconds.
If the local ntpd process fails to communicate with a peer NTP server, the output from the ntpq
command appears similar to the following example:
#ntpq -np
remote refid st t when poll reach delay offset jitter
192.0.2.13 .INIT. 16 u64 0 0.000 0.000 0.000 0000.00 ++
In the previous example, the remote server information (refid, stratum, delay, offset, and jitter) is not available. The
value.INIT. in the refid column indicates that NTP is initializing, and the server has not yet been reached. The value
of 0 (zero) in the reach column indicates that the server has not been reached during any of the last eight attempts.
The absence of a value in the when column indicates that no data has been received from the remote peer since
the local ntpd process was started. The poll value of 64 is still at the MINPOLL value, which indicates that NTP
was recently restarted.
NTP has a MINPOLL and MAXPOLL value, which it uses to determine the optimal time between updates with the
reference server. If jitter is low, and there are no changes in data received, NTP automatically incrementally
increases the poll value until it reaches MAXPOLL, or 1024 seconds.
If the local ntpd process can communicate or attempts to communicate with a declared peer NTP server, the
output from the ntpq command appears similar to the following example:
#ntpq -np
remote refid st t when poll reach delay offset jitter
192.0.2.13 .10.10.10.2514. 2514 u 482 1024 377 0.815 10.010 0.345
111
NETWORKING AND CLUSTER HEALTH—Troubleshooting enhancements (BIG-IP 13.x and later)
In the previous example, the remote server information (refid, stratum, delay, offset, and jitter) displays, which
indicates that the servers are successfully exchanging information. The value of 377 in the reach column indicates
that the server is successfully reached during each of the last eight attempts, and the value of 482 in the when
column indicates that the last response was received from the remote peer 482 seconds ago, which is within the
polling interval of 1024 seconds.
Troubleshooting NTP connectivity
If the system is unable to establish communication with the configured remote peer NTP server, you can do the
following actions to verify network connectivity:
• Ensure that no firewall rules prevent access to the remote NTP server.
• Ensure that locally-managed time servers are functioning properly.
• Restart the NTP daemon by typing the following command:
tmsh restart /sys service ntpd
To list the NTP servers configured on the BIG-IP system at the command line
tmsh
2. List the NTP servers that are currently defined on the BIG-IP system by typing the following
command:
list /sys ntp servers
To remove the NTP server configuration at the command line
tmsh
2. Remove the NTP servers that are currently defined on the BIG-IP system by typing the following
command:
modify /sys ntp servers none
save /sys config
Troubleshooting enhancements (BIG-IP 13.x and later)

In BIG-IP 13.x and later, many existing tmsh commands for device management are improved to provide extended
cluster information. Command syntax remains unchanged but listings show items such as time out of sync, failover
reason, and improved device and traffic group status.
112
NETWORKING AND CLUSTER HEALTH—Troubleshooting enhancements (BIG-IP 13.x and later)
Additionally, the tmsh displays the following message if time drifts more than the acceptable value of three (3)
seconds:
Peer Time Out of Sync
The following list includes improved tmsh commands:
• tmsh show cm device
• tmsh show cm device <devicename>
• tmsh show cm device-group <devicegroupname>
• tmsh show cm sync-status
• tmsh show cm failover-status
• tmsh show cm traffic-group
• tmsh show cm traffic-group <name> all-properties
• tmsh show sys ha-status all-properties
The following list includes new tmcti commands:
• tmctl sod_tg_conn_stat
• tmctl sod_tg_msg_stat
The following list includes new db variables:
• failover.debugsteadystate (Disabled by default. When enabled, it turns on sod debugging, which logs to /
var/log/sodlog.)
• config.timesync.threshold (Out-of-sync threshold. Once reached, the BIG-IP system displays a warning.
Default value is three (3) seconds.)
• configsync.hotfixversionmatch (Disabled by default. When enabled, it prevents config sync from running
if the hotfix version for all systems within the cluster is not identical.)
The following list includes new /var/log/ltm messages:
• Error: Peer %s time exceeds threshold %d sec - difference %d sec
• Error: Could not add device (error from devmgmtd): The device (/Common/<device name>) certificate
expired on <date>
• Error: Could not add device (error from devmgmtd): Device name /Common/<device name> is already in use
in this device trust
• Warning: NTP not configured on device %s - within a trust
• Error: Could not add ca-device (error from devmgmtd): 01070276:3: The requested device (/
Common/<device name>) has a non-matching software version, <version>.
113
NETWORKING AND CLUSTER HEALTH—Additional resources
• Error: Unable to add peer. This device time or time zone does not match the remote one. Update the time
zone for this device
• Warning: Unicast IP address %s does not allow service on UDP port 1026, network failover may not work
Table 9.2 Additional networking and cluster health resources

K3122: Using the BIG-IP Configuration utility to add
NTP configurations
an NTP server
114
LOG FILES AND ALERTS—Background
Log Files and Alerts

F5® has identified the following log file and alerts recommendations:
• Check available log files for messages pertaining to system stability and health.
• Configure logging to a remote log server(s).
• Review log files to identify and prevent excessive logging.
• Check debug modes to identify excessive logging.
• Configure SNMP traps.
Background
information, including the following topics:
• BIG-IP® system logging
• Send BIG-IP logs to a remote system
• Causes of excessive logging
• Security Information and Event Management (SIEM)
• Custom SNMP traps
BIG-IP system logging
Viewing and managing log messages are an important part of maintaining your 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.
You can log events either locally on the BIG-IP system or remotely by configuring a remote syslog server using the
TMOS® Shell (tmsh) or using the high-speed logging (HSL) mechanism. F5 recommends that you store logs on a
pool of remote logging servers using HSL.
For local logging, the HSL mechanism can store the logs in either the syslog or the MySQL database on the BIG-IP
system, depending on the destination you define. For remote logging, the HSL mechanism sends log messages to
a pool of logging servers that you define.
115
The BIG-IP system uses the Linux utility syslog-ng to log events. This utility is an enhanced version of the
standard UNIX and Linux logging utility syslog.
The BIG-IP system logs several types of events:
• System events are based on Linux events, and are not specific to the BIG-IP system.
• Packet filter events are those that result from the implementation of packet filters and packet-filter rules.
• Local traffic events pertain specifically to the local traffic management system.
• Audit events are those that the BIG-IP system logs as a result of changes to the BIG-IP system
configuration. Logging audit events is optional.
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.
You can 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 also 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.
When setting up logging on the BIG-IP system, you can customize the logs by designating the minimum severity
level or log level at which you want the BIG-IP system to report when a type of event occurs. The possible security
levels, from least to most severe are Debut, Informational, Notice, Warning, Error, Critical, Alert, and
Emergency. Not all security level options are available for each type of event. Whatever your setting, the system
logs events at or more severe than what you set.
For example, if you specify Warning for the logging level when a user makes to the bigdb database, 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.
Viewing logs
You can 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.
You can view historical logs using tmsh. For more information, refer to the Traffic Management Shell (tmsh)
Reference Guide.
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.
Tip You can also configure the system to send email or activate pager notification based on the priority of
the logged event.
116
Log content
The logs that the BIG-IP system generates include several types of information. For example, some logs show a
time stamp, host name, and service for each event. 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 one-line
description of each event.
The following table lists the categories of information contained in the logs and the specific logs in which the
information is displayed.
Table 10.1 Log information categories and their descriptions
Information type Explanation Log type

The time and date that the system
Time stamp.System Packet Filter, Local Traffic, Audit.
logged the event message.
The host name of the system that
logged the event message.
Host name Because this is typically the host System, Packet Filter, Local Traffic.
name of the local machine, the
appearance of a remote host name
could be of interest.
The service that generated the
Service System, Packet Filter, Local Traffic.
event.
The status code associated with
the event. Note that only events
Status code logged by BIG-IP system Packet Filter, Local Traffic.
components, and not Linux system
services, have status codes.
The description of the event that
Description caused the system to log the System, Packet filter, Local traffic.
message.
The name of the user who made
User name Audit.
the configuration change.
The identification number of the
Transaction ID Audit.
configuration change.
A description of the configuration
Event change that caused the system to Audit.
log the message.
Local syslog logging
If you are using the syslog utility for local logging, whether or not you are using the high-speed logging
mechanism, you can view and manage the log messages, using the BIG-IP Configuration utility.
The local syslog logs that the BIG-IP system can generate include several types of information. For example,
some logs show a time stamp, host name, and service for each event. 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 one-line description of each event.
117
For local log messages that the BIG-IP system stores in the local syslog database, the BIG-IP system
automatically stores and displays log messages in these categories:
• System messages packet filter messages
• Local Traffic messages
• Global Traffic messages
• BIG-IP system configuration (audit) messages
Each type of event is stored locally in a separate log file, and the information stored in each log file varies
depending on the event type. All log files for these event types are in the directory /var/log.
Logging system events
Many events that occur on the BIG-IP system are Linux-related events, and do not specifically apply to the BIG-IP
system. Using the Configuration utility, you can display these local system messages. The system logs the
messages for these events in the /var/log/messages file.
Logging packet filter events
Some of the events that the BIG-IP system logs are related to packet filtering. The system logs the messages for
these events in the /var/log/pktfilter file.
Logging local traffic events
Many of the events that the BIG-IP system logs are related to local area traffic passing through the BIG-IP system.
The BIG-IP system logs the messages for these events in the /var/log/ltm file.
Logging of BIG-IP system configuration (audit) events
The BIG-IP system logs the messages for these events in the /var/log/audit file.
Manage logging levels
The BIG-IP system uses the standard UNIX logging utility, syslog-ng, to deliver system messages to log files. You
can configure the level of information that syslog-ng delivers to log files.
Note Log messages for events related to TMM are controlled by the alertd process. For detailed
information about configuring the level of information logged for TMM events refer to AskF5™ article: K5532:
Configuring the level of information logged for TMM specific events.
118
Syslog-ng uses facilities and levels to describe system messages. Facilities describe the specific element of the
system generating the message. Levels describe the severity of the message.
Facilities
The following facilities are available on the BIG-IP system. Each facility handles messages for specific elements of
the system:
Table 10.2 Available facilities

Facility Description Default log file
local0 BIG-IP specific messages /var/log/ltm
EM specific messages /var/log/em
local1
BIG-IP APM specific messages /var/log/apm
local2 BIG-IP DNS and BIG-IP Link Controller specific messages /var/log/gtm
local3 BIG-IP ASM specific messages /var/log/asm
local4 ITCM portal and server (iControl) specific messages /var/log/ltm
local5 Packet Filtering specific messages /var/log/pktfilter
/var/log/httpd/
local6 HTTPD specific messages
httpd_errors
local7 Linux specific boot messages /var/log/bootlog
cron Messages related to the cron daemon /var/log/cron
Messages related to system daemons (including named and
daemon /var/log/daemon.log
ntpd)
kern Kernel messages /var/log/kern.log
mail Mail system messages /var/log/maillog
User authentication messages that do not contain sensitive
auth /var/log/secure
information
User authentication messages that contain sensitive
authpriv /var/log/secure
information
ftp Unused, messages for FTP are reported under daemon N/A
lpr Unused, printing support is not provided N/A
mark A facility that produces time-stamps at regular intervals N/A
news Unused, news server support is not provided N/A
ntp Unused, messages for ntpd are reported under daemon N/A
user Messages related to user processes /var/log/user.log
uucp Unused None
Levels
The following table lists available levels for each facility in order of the severity of the messages they handle.
Generally, higher levels contain all the messages for lower levels. For example, the alert level generally reports all
messages from the emerg level, and the debug level generally reports all messages for all levels.
119
LOG FILES AND ALERTS—Procedures
Table 10.3 Emerg level report messages
Level Description Verbosity

emerg Emergency system panic messages Minimum
alert Serious errors that require administrator intervention Low
crit Critical errors, including hardware and filesystem failures Low
err Non-critical, but possibly very important, error messages Low
warning Warning messages that should at least be logged for review Medium
notice Messages that contain useful information, but may be ignored Medium
info Messages that contain useful information, but may be ignored High
debug Messages that are only necessary for troubleshooting Maximum
Note The BIG-IP system is not a logging server and has limited capacity for storing, archiving, and analyzing
logs. A dedicated logging server is recommended for extensive logging functions. The BIG-IP system is
configured by default to provide the most relevant log information to administrators.
Changing the default log levels to a higher level increases the amount of data stored on the device. If the default
levels are changed for troubleshooting purposes, remember to set the level back to its default setting.
Display the level of information that syslog-ng sends to log files
Before you change a specific syslog facility level, you may want to display the current levels.
Procedures
This section details how to complete the following log file- and alert-related tasks.
SysLog
To display the current syslog facility levels
1. Log in to tmsh at the command line by typing the following command:
tmsh
2. Change to the /sys module by typing the following command:
/sys
3. To list the level of information that syslog-ng sends to the log files, type the following command:
list syslog all-properties
To configure the level of information, syslog-ng sends to log files
tmsh
120
2. Change to the /sys module by typing the following command:
/sys
3. Use the following syntax to modify the level of information that syslog-ng sends to log files:
modify syslog <option>
For example, the default log level range for the authpriv syslog facility is from notice to emerg.
4. To change the authpriv syslog facility range from warning to emerg, type the following command:
modify syslog auth-priv-from warning
Note For other syslog options, use the help /sys syslog command from the tmsh shell.
save sys config
Managing log files on the BIG-IP system
Log files allow one to track usage or troubleshoot issues. If left unmanaged, they can grow to an unwieldy size.
The BIG-IP system uses a utility called logrotate to manage the local log files. The default settings suffice for
most systems. If it is determined that the current system is logging at a high level, the following sections describe
how to modify the default settings.
Changing the age at which log files become eligible for removal
The logrotate script deletes log files older than the number of days specified by the Logrotate.LogAge database
variable. By default, the variable is set to 8. Therefore, the system is configured to delete archive copies that are
older than eight days.
To modify the Logrotate.LogAge database variable
tmsh
2. Modify the age at which log files are eligible for deletion, by using the following command syntax:
modify /sys db logrotate.logage value <value>
In this command syntax, note the following: Legal values range from 0 to 100.
save /sys config
121
Change the number of archive copies that the system retains
The tmsh log-rotate common-backlogs option specifies the maximum number of log files that the system
retains for each log file. By default, the BIG-IP system is configured to retain up to a maximum of 24 archive copies
of each log file.
Note The system is unlikely to reach the maximum of 24 archive copies for a log file unless you change the
log rotation frequency or the Logrota te.LogAge database variable.
To modify the number of archived log files
tmsh
2. Modify the number of archived logs that the system retains by using the following command
syntax:
modify /sys log-rotate common-backlogs <value>
In this command syntax, note the following: Legal values range from 0 to 100.
3. To save the changes at the command line, type the following command:
save /sys config
Sending BIG-IP logs to a remote system
You can log events locally on the BIG-IP system or remotely by configuring a remote syslog server using tmsh or
using the BIG-IP system’s high-speed logging (HSL) mechanism.
To configure a remote syslog system at the command line
1. At the command line, type the following command syntax:
modify /sys syslog remote-servers add {<server name> {host <server IP

address> remote-port <port number>}}
For example:
modify /sys syslog remote-servers add {server{host 10.1.1.1 remote-port 514}}
Changes made with the tmsh syslog commands must be saved in order to persist after a
configuration reload.
2. To save changes At the command line, type the following command:
save /sys config
For more advanced configurations, like sending logs to multiple remote syslog servers, refer to AskF5 article:
K13080: Configuring the BIG-IP system to log to a remote syslog server (10.x - 13.x).
122
To implement high-speed remote logging of BIG-IP system processes, refer to Configuring Remote high-speed
logging in the BIG-IP TMOS: Implementations Guide for the software version you are running.
Comparing remote logging and remote high-speed logging configurations
If you want to configure remote logging using syslog-ng, do not use high-speed logging (HSL). Remote logging
syslog-ng has some key differences compared to a remote HSL configuration. With remote logging syslog-ng,
you do not configure log destinations, publishers, or a logging profile or log filter. Instead of creating a pool of
remote logging servers (as you do with high-speed logging), you specify the IP addresses of the servers using the
Remote Logging page of the BIG-IP Configuration utility. If you want to ensure that the syslog-ng remotely
logged messages are encrypted, you must first establish a secure tunnel.
HSL mechanism can log BIG-IP system-level events, DNS events (for local traffic and global traffic) , Network
Firewall events, and Protocol Security Manager™ events, carrier-grade NAT (CGNAT) events, and distributed denial
of service (DDoS) protection events.
To set up remote HSL, first define a pool of logging servers, and then create an unformatted, remote high-speed
log destination that references the pool. If you are using ArcSight, Splunk, or Remote Syslog logging servers that
require a formatted destination, you can also create a formatted log destination for one of those server types.
Once you set up those objects, create a publisher and a custom logging profile pertaining to the type of message
you want to log. Then assign the logging profile to a relevant virtual server. The profile, in turn, references the
publisher.
The following figure shows BIG-IP objects that you configure for remote high-speed logging and the ways in which
these objects reference one another from a configuration perspective.
123
Figure 11.1: BIG-IP objects configured for remote high-speed logging
Table 10.4 Description of high-speed logging configuration objects
Configuration object Description

A remote logging pool is a BIG-IP load balancing pool that contains
Remote logging pool
the remote logging servers as members.
An unformatted log destination references the pool of remote logging
Unformatted log destination
servers.
A formatted log destination pertains to a specific type of remote
Formatted log destination logging server (ArcSight, Splunk, or Remote Syslog) and references
an unformatted log destination.
A log publisher references the formatted and unformatted log
Log publisher
destinations for log messages.
A logging profile pertains to the type of events that you want to log.
For example, for logging Protocol Security events, you create a
Logging profile Protocol Security logging profile. For Network Firewall events, you
create a Network Firewall profile. A logging profile references a log
publisher.
A log filter is a mechanism for setting minimum log levels for various
Log filter
system-level events. A log filter references a log publisher.
A virtual server or listener listens for the type of traffic for which you
BIG-IP LTM virtual server or
want to log messages. If you have created a logging profile, you
BIG-IP DNS listener
assign the profile to the virtual server or listener.
Example: In configuring a remote, high-speed logging, you want to send all Protocol Security messages to a group
124
of remote ArcSight servers. You create the following:
• A load balancing pool for the ArcSight logging servers.
• An unformatted Remote High-Speed Log destination that references the pool of ArcSight logging servers.
• A formatted ArcSight log destination that references an unformatted log destination.
• A publisher that references the formatted and unformatted log destinations.
• A Protocol Security logging profile that references the publisher.
• A BIG-IP LTM® virtual server or DNS listener that references the logging profile and the load balancing pool.
• An unformatted Remote High-Speed Log destination that references the pool of ArcSight logging servers.
Tip For step-by-step information on configuring basic remote high-speed logging, refer to BIG-IP TMOS:
Implementations.
Audit logging
Audit logging is an optional type of logging which logs messages pertaining to configuration changes that users or
services make to the BIG-IP system configuration. This type of audit logging is known as master control program
(MCP) audit logging. Optionally, you can set up audit logging for any tmsh commands that users type on the
command line.
For both MCP and tmsh audit logging, you can choose a log level. In these types of logging, log levels do not
affect the severity of the log messages. Instead, the log levels affect the initiator of the audit event.
The log levels for MCP logging are described in the following table.
Table 10.5 MCP logging levels

Level Description
Disable Turns off audit logging (Default)
Enable Causes the system to log messages for user- initiated configuration changes only
Causes the system to log messages for user- initiated configuration changes and any
Verbose
loading of configuration data
Causes the system to log messages for all user- initiated and system-initiated
Debug
configuration changes
The following table describes log levels for tmsh logging.
125
Table 10.6 tmsh logging levels
Level Description
Disable Turns off audit logging (Default)
Enable Causes the system to log messages for user-initiated configuration changes only
Causes of excessive logging
A variety of things can cause excessive logging. Among these are iRules® logging functionality and debug modes.
iRules
Logging functionality within iRules can cause excess logging to the system. F5 recommends you check system log
load after editing or adding iRules.
Debug modes
Depending on the level of debug information turned on in debug mode, significant impact on the system CPU load
may result. Fpr an overview of BIG-IP database keys that control debug logging, refer to AskF5 article: K13455:
Overview of BIG-IP logging BigDB database keys (11.x - 12.x).
Security information and event management
Security information and event management (SIEM) is a term for software and products services combining
security information management (SIM) and security event manager (SEM). SIEM can centralize the storage and
interpretation of logs, or events, generated by software running on the network. As a network security device, the
BIG-IP device can be configured to send log data and SNMP traps to a SIEM device to help provide real-time
analysis of security events and generate reports for compliance purposes.
You can configure the BIG-IP system to log information about protocol security, network firewall, and denial-of-
service (DoS) events and send the log messages to remote high-speed log servers.
Important The BIG-IP Advanced Firewall Manager™ (AFM™) must be licensed and provisioned before you
can configure DoS protection, network firewall and protocol security event logging. Additionally, for high-
volume logging requirements, such as DoS, ensure that the BIG-IP system sends the event logs to a remote
log server.
Refer to the following chapters in External Monitoring of BIG-IP Systems: Implementations Guide for the
software version you are currently running:
• Configuring Remote high-speed logging of Protocol Security Events
• Configuring Remote high-speed logging of Network Firewall Events
• Configuring Remote high-speed logging of DoS Protection Events
You can use BIG-IP ASM® to configure a remote logging profile to send request data for an associated web
application to a remote system such as Splunk or ArcSight. A remote management system allows you to store
126
data in a central location for multiple appliances/applications for archival and reporting purposes.
For more information about configuring the remote-logging profile for use with remote management systems, refer
to Configuration Guide for BIG-IP Application Security Manager for your software version.
For more information about ArcSight Remote Logging with BIG-IP ASM, refer to AskF5 article: K11995: Data field
definitions for ArcSight Remote Logging.
For information on reporting and analytics for Splunk, refer to the following Splunk Apps at http://apps.splunk.com
(This link takes you to an outside resource.):
• Splunk for F5 is a collection of field extractions, saved searches, reports dashboards, and web access
iRules for BIG-IP Local Traffic Manager.
• Splunk for F5 Access is a collection of field extractions, saved searches, reports, and dashboards for BIG-IP
Access Policy Manager and FirePass™ SSL VPN.
• Splunk for F5 Security is a collection of field extractions, saved searches, reports, and dashboards for
BIG-IP Access Security Manager and Protocol Security Manager
Custom SNMP traps
SNMP traps are definitions of unsolicited notification messages that the BIG-IP alert system and the SNMP agent
send to the SNMP manager when certain events occur on the BIG-IP system. Configuring SNMP traps on a
BIG-IP system means configuring how the BIG-IP system handles traps, as well as setting the destination to which
the notifications are sent.
All BIG-IP systems are pre-configured with a set of trap definitions which are helpful for managing the hardware
and software components of the device. In most cases, default traps are sufficient for monitoring and managing
the system. However, some deployments require custom SNMP traps on other logged events.
The BIG-IP system uses a standard syslog-ng / alertd framework for generating alerts, including SNMP traps.
SNMP traps are triggered when the alertd process receives input from the syslog-ng utility that matches an alert
code or match string. The alertd process then does the action specified in the /etc/alertd/alert.conf or /config/
user_alert.conf file, such as sending an SNMP trap.
Before you attempt to define a custom SNMP trap, you should already have SNMP configured on the BIG-IP
system with at least one trapsink destination. If not, refer to External Monitoring of BIG-IP Systems
Implementation Guide for your software version.
The BIG-IP system stores SNMP traps in two specific files:
• /etc/alertd/alert.conf, which contains default SNMP traps
• /config/user_alert.conf, which contains user-defined SNMP traps
Important Do not add or remove traps from the /etc/alertd/alert.conf file.
F5 does not recommend or support modifications to the /etc/alertd/alert.conf file. The /etc/alertd/alert.
conf file is not stored in UCS archives, and it may be overwritten during hotfix installations and software
upgrades. All custom alerts should be defined in the /config/user_alert.conf file.
127
For information about determining the format of the syslog-ng message strings sent with an SNMP trap, refer to
AskF5 article: K6420: The /var/run/bigip_error_maps.dat file maps the alertd process input from the syslog-ng
utility to an alert name.
SNMP trap definitions
You can determine which alerts trigger an SNMP trap by viewing /etc/alertd/alert.conf. The /etc/alertd/alert.
conf file contains the alert definitions, which instruct the system on what actions to take when the alert is
triggered.
An alert definition appears similar to the following example:
alert BIGIP _ MCPD _ MCPDERR _ POOL _ MEMBER _ MON _ STATUS
{snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.10” }
Alert definitions configured to trigger an SNMP trap contains the snmptrap command, as in the previous example:
snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.10”;
The first line always contains the alert name:
alert BIGIP _ MCPD _ MCPDERR _ POOL _ MEMBER _ MON _ STATUS
The first line of an alert definition may also contain the match string, as in the following example, which uses a
regular expression to catch all local authentication failure log messages:
alert BIGIP _ AUTH _ FAIL “FAILED LOGIN (.) FROM (.) FOR
(.*), Authentication failure” { snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.27” }
When the alertd process starts, the /var/run/bigip_error_maps.dat file is dynamically generated using entries
from all of the map files in the /etc/alertd/ directory that end with the _maps.h file extension.
The alertd process uses the /var/run/bigip_error_maps.dat file to map input it receives from the syslog-ng
utility to an alert name. When alertd receives input from syslog-ng utility that matches an alert code, the alert
code is mapped to the alert name. The alertd process then does the alert actions specified for that alert name in
the /etc/alertd/alert.conf file, such as issuing an LCD warning, or sending an SNMP trap.
Important Modifications to the /config/user_alert.conf file may not be preserved after system upgrades
or hotfix installations. F5 recommends that you create an updated UCS archive immediately before an
upgrade operation if you want to maintain the customizations in the file.
SNMP trap configuration files
Standard pre-configured SNMP traps are contained in the /etc/alertd/alert.conf file. F5 does not recommend or
support the addition or removal of traps or any other changes to the alert.conf file.
Custom, user-defined SNMP traps should be defined in the /config/user_alert.conf file.
When the alertd process starts, it creates a dynamic configuration file by appending the /config/user_alert.conf
file to the /etc/alertd/alert.conf file. The system searches the dynamic configuration file sequentially for matches.
128
Once a match is found, the trap is generated and no further matches are attempted.
All files in the /config directory, including any customizations to the /config/user_alert.conf file, are automatically
included in the UCS archive by default. For more information, refer to AskF5 article: K4422: Viewing and modifying
the files that are configured for inclusion in a UCS archive.
Creating custom SNMP traps
Before you create a custom trap, you must determine the unique syslog message(s) for which you want the system
to send alerts. The first matched message value generates an alert, so the message must not match the matched_
message value of any other SNMP trap already defined in the /etc/alertd/alert.conf file or the /config/user_alert.
conf file.
For information about how to determine which alerts are pre-configured to trigger an SNMP trap or to view alerts
from the /etc/alertd/alert.conf file, refer to AskF5 article: K6414: Determining which alerts are pre-configured to
trigger an SNMP trap.
To create a custom SNMP trap at the command line
1. Back up your /config/user_alert.conf file by typing the following command:
cp /config/user _ alert.conf/config/user _ alert.conf.SOL3727
2. Edit the /config/user_alert.conf file.
3. Add a new SNMP trap using the following syntax:
alert <alert _ name> “<matched message>” { snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0

.XXX”}
Refer to Custom SNMP trap naming for information on how to name custom traps.
4. Save the file and close the text editor.
Custom SNMP trap naming
When you add a new SNMP trap, use the following syntax:
alert <alert _ name> “<matched message>” { snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.XXX”}
• Replace XXX with a number unique to this object ID.
• Replace the <alert_name> with a descriptive name. Do not use an alert name that exactly
matches one already used in the /etc/alertd/al ert.conf file or the /config/user_alert.conf file.
• Replace the <matched_message> with text that matches the syslog message that triggers the
custom trap. You can specify a portion of the syslog message text or use a regular expression.
F5 recommends that you do not include the syslog prefix information in the match string, such as
the date stamp and process ID. Including information of a variable nature in the match string or
129
LOG FILES AND ALERTS—Additional resources
regular expression may result in unexpected false positives or result in no matches at all.
You can use any object ID that meets all of the following criteria:
• The object ID (OID) is in standard OID format and within the range .1.3.6.1.4.1.3375.2.4.0.300 through
.1.3.6.1.4.1.3375.2.4.0.999
• If the OID value is outside the range listed above, a trap is sent with the OID specified, but it does not contain
any text within the trap body.
• The object ID is in a numeric range that can be processed by your trap receiving tool.
• The object ID does not already exist in the /usr/share/snmp/mibs/F5-BIGIP- COMMON-MIB.txt MIB file.
• The object ID is not already used in another custom trap.
Note If the alertd process fails to start, examine the newly added entry to ensure it contains all of the
required elements and punctuation.
To test the newly created trap, refer to AskF5 article: K11127: Testing SNMP traps on BIG-IP (9.4x–12.x).
Custom SNMP trap example
When switchboard failsafe is enabled, the system logs a message to the /var/log/ltm file which appears similar to
the following:
Sep 23 11:51:40 bigip1.askf5.com lacpd[27753]: 01160016:6: Switchboard Failsafe

enabled
To create a custom SNMP trap that the system triggers whenever it logs switchboard failsafe status changes, add
the following trap definition to the /config/user_alert.conf file:
alert SWITCHBOARD _ FAILSAFE _ STATUS “Switchboard Failsafe (.*)”
snmptrap OID=.”1.3.6.1.4.1.3375.2.4.0.500”
Table 10.7 Additional log files and alerts resources

Configuring alerts to send email notifications K3667: Configuring alerts to send email notifications
External Monitoring of BIG-IP Systems:
External monitoring
Implementations
130
LOG FILES AND ALERTS—Additional resources

Custom SNMP Traps on DevCentral (Log in
SNMP traps
required)
Configuring the level of information that syslog-ng K13317: Configuring the level of information that
sends to log files (11.x - 12.x) syslog-ng sends to log files (11.x - 12.x)
Configuring the level of information logged for K5532: Configuring the level of information logged
TMM-specific events for TMM- specific events
Configuring syslog settings at the command line K13083: Configuring syslog settings at the
(11.x - 12.x) command line (11.x - 12.x)
131
MODULES—Background
Modules
F5® has identified the following module recommendations:
• Determine which modules are system on your BIG-IP® system.
• Check pool load balancing statistics and verify pool member availability.
• Ensure ZoneRunner™ configuration matches the BIND configuration files after a BIND restart or crash.
• Check expiration dates of your domain names.
• Reactivate service license to update service check date.
• Test BIG-IP Application Security Manager™ (ASM®) sync and failover capabilities (High availability
configurations only).
• Review attack signatures and policies.
• Review logged violations for accuracy.
• Perform regular penetration testing.
• Set up remote logging for violations.
• Set up Simple Network Management Protocol (SNMP) traps for violations.
• Turn off learning for policies in blocking mode.
• Protect application from DDoS attacks.
• Delay access or drop connections and increase data storage WAN Optimization Manager™ uses for
deduplication if a DDoS attack is suspected.
• Monitor solid state drives use.
Background
information.
It includes general information on the following BIG-IP system modules:
• BIG-IP DNS™ (formerly Global Traffic Manager™/GTM™)
• BIG-IP Local Traffic Manager™ (LTM®)
• BIG-IP Advanced Firewall Manager™ (AFM™)
• BIG-IP Access Policy Manager® (APM®)
132
• BIG-IP Application Security Manager (ASM)
• BIG-IP Application Acceleration Manager® (AAM™)
• BIG-IP Policy Enforcement Manager™ (PEM™)
• BIG-IP Carrier-Grade NAT BIG-IP Link Controller
• BIG-IP Enterprise Manager™ (EM™)
• BIG-IP Protocol Security Module™ (PSM™)
For more information about the key benefits for each of the F5 modules, refer to The BIG-IP Modules Datasheet
(f5.com/pdf/products/big-ip-modules-ds.pdf).
Modules
F5 BIG-IP devices work on a modular system, so you can add new functions as necessary to adapt quickly to
changing application and business needs. F5 offers a range of feature modules users can activate on demand.
BIG-IP software modules offer advanced security, performance and availability features allowing customization of
BIG-IP to your unique data environment.
You can provision modules for which you are not licensed. This enables you to configure the system prior to
obtaining a license. If you provision modules without a valid license, the system posts the following alert in the
Configuration utility:
Provisioned yet unlicensed: <modulename>
Although you can provision an unlicensed module, associated modules features are not operable.
Note Check your license to determine which modules you have activated on your system. Trial licenses, can
expire without warning. For more information, refer to “Licenses and Entitlement”.
BIG-IP DNS
BIG-IP DNS, formerly BIG-IP Global Traffic Manager (GTM), improves the performance and availability of your
applications by directing users to the closest or best physical, virtual, or cloud environment. Using high-
performance DNS services, BIG-IP GTM scales and secures your DNS infrastructure from DDoS attacks and
delivers a complete, real-time DNSSEC solution that protects against hijacking attacks.
For more information refer to the BIG-IP DNS/Global Traffic Manager page (f5.com/products/modules/global-
traffic-manager).
Wide IP misses/fallback to BIND
BIG-IP DNS attempts to load balance a name resolution request using the preferred load balancing method
configured for the pool. If the preferred load-balancing method fails, the system attempts to use the alternate and
fallback methods. If all load balancing methods configured for a pool fail, then the request fails, or the system falls
back to BIND.
Wide IP misses/falls back to BIND may occur for a variety of reasons. For example, a wide IP may fall back to
133
BIND if all pool members are marked down in the pool. In addition, the wide IP may fall back to BIND when an
AAAA or A6 query is received by BIG-IP DNS and no IPv6 pool members exist for the wide IP.
ZoneRunner data matches BIND zone files
BIG-IP DNS uses ZoneRunner™ to manage DNS zone files and the BIND configuration. The ZoneRunner utility
uses Dynamic DNS Update to update the resource record data to BIND. BIND does not write the updates to the
associated zone file immediately. Instead, it stores the updates in a journal file, with a .jnl file name extension. If
BIND is restarted after a shutdown or crash, it replays the journal file and attempts to incorporate the zone data. In
the event the replay fails, the ZoneRunner data may not match the BIND files.
Domain name expiration
Once a domain name expires, it goes through many stages before being released to the open market. Most
domain name registrars send renewal emails to domain name administrators prior to the expiration date.
BIG-IP Local Traffic Manager
BIG-IP Local Traffic Manager (LTM) increases your operational efficiency and ensures peak network performance
by providing a flexible, high-performance application delivery system. With its application-centric perspective,
BIG-IP LTM optimizes your network infrastructure to deliver availability, security, and performance for critical
business applications. For more information refer to the BIG-IP Local Traffic Manager page (f5.com/products/
modules/local-traffic-manager).
BIG-IP Advanced Firewall Manager
BIG-IP Advanced Firewall Manager (AFM) is a high-performance, stateful, full-proxy network firewall. It is designed
to guard data centers against incoming threats that enter the network on the most widely deployed protocols,
including HTTP/S, SMTP, DNS, and FTP. By aligning firewall policies with the applications they protect, BIG-IP
AFM streamlines application deployment, security, and monitoring. With its scalability, security, and simplicity,
BIG-IP AFM forms the core of the F5 application delivery firewall solution.
Note IPFIX is a generic logging capability used by carrier-grade NAT (CGNAT), BIG-IP AFM, and BIG-IP
PEM. In terms of transport, you can specify UDP, TCP, or TLS with TCP. If your IP Flow Information Export
(IPFIX) collector is capable of TLS, F5 recommends specifying one of these terms of transport as the
preferred transport when security is an issue.
BIG-IP Access Policy Manager
BIG-IP Access Policy Manager (APM) is a flexible, high-performance access and security solution that provides
unified global access to your applications and network. By converging and consolidating remote access, LAN
access, and wireless connections within a single management interface, and providing easy-to-manage access
policies, BIG-IP APM helps you free up valuable IT resources and scale cost-effectively.
For more information, refer to the BIG-IP Access Policy Manager page (f5.com/products/modules/access-policy-
manager).
134
Syncing using NTP with Remote Authentication Server
F5 recommends all BIG-IP systems have NTP configured for time consistency. Additionally, in BIG-IP APM, if the
time stamp on an authentication request varies too far from the time on a remote authentication server, the request
is likely be denied.
F5 recommends configuring BIG-IP APM to use the same NTP server(s) as any authentication servers that they are
communicating with to reduce the chances of users being denied due to time drift.
For more information about NTP, refer to ”Networking and Cluster Health”.
Configuration of Certificate for Access Virtual Server
As a security measure, F5 strongly recommends using a certificate from a trusted certification authority (CA) when
providing client access in BIG-IP APM through a virtual server using a self-signed certificate.
Table 11.1 Recommended maintenance for BIG-IP APM

Task Frequency
Check for OPSWAT updates Monthly
BIG-IP Application Security Manager
BIG-IP Application Security Manager (ASM) is a flexible web application firewall that secures web applications in
traditional, virtual, and private cloud environments. BIG-IP ASM provides unmatched web application and website
protection, helps secure deployed applications against unknown vulnerabilities, and enables compliance for key
regulatory mandates—all on a platform that consolidates application delivery with a data center firewall solution,
and network and application access control.
For more information refer to the BIG-IP Application Security Manager page (f5.com/products/modules/
application-security-manager).
F5 recommends checking for updates to the OPSWAT libraries on a monthly basis to ensure clients are only
connecting with verified secure systems.
For more information, refer to ”Software Updates”, or refer to AskF5™ article: K10942: Installing OPSWAT hotfixes
on BIG-IP APM systems.
Table 11.2 Recommended maintenance for BIG-IP ASM
Task Frequency
Check for attack signature. Monthly
Update license service check date. Yearly
Test high availability configuration and fail over under Every six months or before major application or
controlled environment. configuration changes.
Review attack signature and policy settings. Monthly or before major application changes.
Review policy violations on public networks. Daily
Perform penetration testing. Routinely
135
Updating Attack Signatures
F5 recommends checking for new attack signature releases on a monthly basis to ensure you are always running
the most up-to-date protection. This either can be a manual task, or scheduled automatically in the BIG-IP ASM
configuration.
F5 releases a new attack signature update for BIG-IP ASM about every six weeks. These update include new
attack signatures as well as enhancements to existing attack signatures. For more information, refer to “Software
Updates”, or refer to AskF5 article: K8217: Updating the BIG-IP ASM attack signatures.
Updating license service check date
F5 recommends updating the service check date for the BIG-IP APM module by reactivating the license on a
yearly basis to ensure smooth installation of new attack signatures.
You can only update BIG-IP ASM attack signatures on a BIG-IP system that has a valid support contract, active
within the last 18 months.
For more information, refer to ”Licenses and Entitlement” and AskF5 article K8217: Updating the BIG-IP ASM
attack signatures.
Testing BIG-IP ASM sync and failover capabilities (high availability configurations only)
F5 recommends testing your high availability (HA) configuration and failing over under controlled conditions every
six months or before major application or configuration changes to ensure application delivery continues
uninterrupted in the event of a real failure.
For more information, refer to Automatically Synchronizing Application Security Configurations in BIG-IP
Application Security Manager: Implementations for your software version.
Reviewing attack signature and policy settings
F5 recommends routine evaluation of application security needs and policies on a monthly basis or before major
application changes to prevent unwanted behaviors from policies that no longer match their applications.
Applications grow and change as the needs of your business and customers do. A policy that was created for an
application’s release may no longer meet the security needs of that application as new features are added, or may
contain orphaned configuration for application features that have changed or been removed. BIG-IP ASM
administrators work with application developers to evaluate routinely the security needs of the application and how
the policies are meeting those needs.
Reviewing logged violations for accuracy
F5 recommends review of policy violations on a public network on a daily basis to gain insight into ongoing attacks
or simple misconfigurations that may cause erroneously blocked traffic or log violations.
136
For a properly configured security policy on a public network, it’s not uncommon for BIG-IP ASM to block traffic
and log violations.
For more information, refer to ”Log Files and Alerts”, and Working with Violations in BIG-IP Application
Security Manager: Implementations for your software version.
Performing regular penetration testing
F5 recommends penetration testing against your security policies on a routine basis to ensure that your application
is secure against malicious attackers.
Because of the variability of applications, environments, and security needs, F5 cannot recommend a specific
period, but implementing a routine testing plan as part of your regular operations can help you identify and correct
gaps in your Security Policy before an attacker does.
Remote logging for violations
F5 recommends setting up remote logging to provide historical archiving of violation data and to ensure that no
important data is lost due to the limited violation storage constraints of BIG-IP ASM.
For more information, refer to ”Log Files and Alerts” and Configuring Application Security Event Logging in
BIG-IP Application Security Manager: Implementations for your software version.
Setting up SNMP traps for violations
F5 recommends setting up SNMP traps to alert on you to attacks in progress. For more information, refer to the
Log Files and Alerts chapter in this guide, or AskF5 article: K7738: Configuring the BIG-IP ASM to send SNMP
traps to communicate a blocked request and request violation.
Turning off learning for policies in blocking mode
F5 recommends turning off learning policies in blocking mode because these policies consume resources that can
be better devoted to processing and securing traffic.
When set to blocking mode, a security policy is intended to protect your application, not learn about it. Freeing up
resources spent on learning helps better and more efficiently protect your system.
For more information, refer to Refining Security Policies with Learning and Configuring Security Policy
Blocking in BIG-IP Application Security Manager: Implementations for your software version.
Protecting against application distributed denial-of-service (DDoS) attacks with BIG-IP ASM
Today’s security threats increasingly involve application-layer distributed denial-of-service DDoS attacks mounted
by organized groups of attackers to damage web-facing applications by exhausting resources. BIG-IP ASM
provides application-layer protection against DDoS attacks.
BIG-IP ASM resides between applications and users and can detect and protect against an attack in real-time by:
• Detect an application is under attack.
137
• Identify attacker information.
• Mitigate the attack.
By controlling access, implementing challenge/response and anomaly detection engines, and applying the ability
to understand application behavior, BIG-IP ASM defends against malicious connections and keeps attackers from
overwhelming applications.
Detecting an application attack

Recent application-level DDoS incidents show that such an attack can be described as a mass of HTTP requests
to the web application from as many sources as possible.
Before DDoS was the common, the standard, single-point denial-of-service (DoS) attack prevailed. DoS attack
uses a single source that sends as many requests as possible to affect application availability. A DDoS attack is
mounted from multiple, geographically distributed locations as it tries to bypass traditional protection methods.
A security filter can easily detect an abnormal rate of HTTP requests sent from one source, as happens in a
traditional DoS attack. Once detected, the attack can be mitigated easily by blocking access from the single
source. DDoS is much more complex since it includes a multi-source attack with each source sending many HTTP
requests. These attacks are usually conducted by ranks of ‘zombie’ PCs: devices infected by malware and
controlled remotely by an anonymous attacker, often without the machine owners having any knowledge that an
attack is underway.
To detect DDoS attacks, protection policies need to study how the attacked application is legitimately used, which
can only be done by learning how the application is accessed over time, including all the characteristics of valid
traffic. These characteristics typically include the following:
• Access rate over time. This identifies access rate to the application during different hours and days of the
week. For example, some applications may draw Monday morning rush-hour traffic levels significantly
differently from their traffic at other hours and on other days of the week.
• Rate per application resource. An application is not one organism but a collection of resources and each
resource has its own characteristics. For example, there is no doubt that the access rate for an application
login page is greater than for other pages in the application.
• Response latency. Application response latency for each application resource (and for the entire application)
indicates when a resource is being exhausted.
• Rate of application responses. The rate of application responses such as 404 (page not found errors) and
500 (application errors) changes according to how the application is used.
• Geographical locations. User access rate can be segregated according to the users’ geographical location,
and in many cases, web application administrators can predict their users’ location(s). For example, United
States government web application administrators might anticipate that most users for most applications are
accessing those applications from within the U.S.
The detection of these traffic characteristics should be based on changes in the application behavior. For example,
if the access rate of an application’s search page is typically 500 transactions per second and suddenly that rate
jumps to 5000 transactions per second, it is usually safe to assume that the search page is being abused and
138
possibly attacked. Depending on the source locations of each of those requests, the application may be subject to
DDoS attack. In this example, the security filter should monitor the resource under attack rather than the source of
the attack itself.
BIG-IP ASM detects such attacks by learning how the application is normally accessed. Depending on
configuration, BIG-IP ASM generally accomplishes this by collecting the following information:
• Transactions per second for each URL in the application.
• Web server latency for each URL in the application.
• Transactions per second for each source IP that accesses the application.
BIG-IP ASM detects an attack when there is a change in the way an application is being accessed compared to
the normative values it has already learned.
Identifying attacker information

After detecting that an application is under DDoS attack, the next step in defense is to determine who is attacking
the application—or at least, what information can be discovered about the attacker(s). The challenge is to
differentiate between the legitimate traffic and the attackers. By definition, a DDoS attack is mounted by many
sources, so in the example of sudden jump to a high number of unusual search page requests, there are likely
multiple users trying to do valid searches on the application while others are participants in the attack.
The best way to differentiate legitimate from illegitimate traffic is to challenge users by distinguishing between
normal users who work with browsers and malicious automatic tools that send requests directly to the application.
One example for such a challenge is the CAPTCHA authentication test, which is used on many application login
pages and attempts to repel brute-force attacks by requiring the user to respond to a random or personal
challenge.
Another example of an effective challenge, and one used by BIG-IP ASM, is the injection of JavaScript to the user.
Only clients who use a browser pass this challenge, while malicious automated tools fail it. As a result, BIG-IP
ASM can selectively pinpoint and block those automated tools.
Detection and attacker identification are not always decisive. The complexity of the scenario affects the accuracy
of detection efforts, and challenging detection tasks may result in false positives. In addition, failure to respond to
a security challenge does not necessarily indicate an attack. For example, a challenge can fail to receive a
response because of the users’ browser limitations or configurations. Nevertheless, security measures with the
ability to discern information about potential attackers and pose one or more challenges to suspicious users can
more effectively detect and thus mitigate threats.
Mitigating an attack
As noted, application delivery is often a primary business goal and may be an organization’s dominant—or only—
customer interaction. In such cases, dropping application users’ transactions is unacceptable, even when
suspicious users fail to respond to a security challenge. Instead, efforts should be made to protect the application
from DDoS attacks without denying legitimate traffic.
During a potential attack, several mitigation options are available:
139
• Delay access from suspicious source IP addresses.
• Delay access to URLs that are under attack.
• Drop connections for suspicious source IP addresses.
• Drop connections for URLs that are under attack.
Protecting the application

If an attack occurs, it is important to mitigate the attack’s effects on the application while preserving availability to
legitimate traffic. One approach is to increase overall availability of an attacked resource by lowering the
application access rate from suspicious sources. This has the effect of maintaining application quality of service
while reducing service availability for suspicious users based on total available resources for the application. This
approach has the added advantage of making it less likely that attackers recognizes that the attack is being
mitigated. Using this approach, the application is protected while the worst case scenario for the legitimate user is
that traffic slows.
BIG-IP Application Accelerator Manager
BIG-IP Application Acceleration Manager (AAM) combines the application delivery features previously available in
BIG-IP WAN Optimization Manager™ (WOM®) and BIG-IP WebAccelerator.
You may run BIG-IP AAM on hardware appliances or VIPRION modular chassis and blade systems designed
specifically for application delivery, or you may run BIG-IP AAM Virtual Edition (VE) on your choice of hypervisor
and hardware.
For more information see the BIG-IP Application Acceleration Manager page (f5.com/products/modules/
application-acceleration-manager).
Increasing data storage for BIG-IP AAM
You can use disk management to allocate dedicated disk space for the datastor service, which increases the data
storage that BIG-IP AAM uses. Additional disk space is available in the following deployments.
Selected higher-end BIG-IP AAM 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 AAM Virtual Edition, you can select an extra disk deployment configuration. Systems
with more than one drive or array may not come configured to use the additional storage.
Provisioning solid-state drives for datastor
Datastor is the data storage used for optimization. By default, it is provisioned on the primary hard disk drive
(HDD). To use solid-state drives (SSDs) on BIG-IP AAM, you must manually allocate the disk space on each SSD to
the datastor service.
If you install SSDs after you have provisioned BIG-IP AAM, you must first disable BIG-IP AAM, then delete the
datastor application volume from the primary disk before you assign the datastor service to the SSD volume. You
140
then will have to re-enable BIG-IP AAM.
BIG-IP Policy Enforcement Manager
BIG-IP Policy Enforcement Manager (PEM) delivers the insight you need to understand subscriber behavior and
effectively manage network traffic with a wide range of policy enforcement capabilities. BIG-IP PEM provides
intelligent layer 4–7 traffic steering, network intelligence, and dynamic control of network resources through
subscriber- and context-aware solutions. It also provides deep reporting, which you can capitalize on to build
tailored services and packages based on subscribers’ application usage and traffic classification and patterns to
increase average revenue per user (ARPU).
Note IPFIX is a generic logging capability used by CGNAT, BIG-IP AFM, and PEM. If your IP Flow
Information Export (IPFIX) collector is capable of TLS, F5 recommends specifying one of these terms of
transport as the preferred transport when security is an issue.
For more information, refer to the Policy Enforcement Manager page (f5.com/products/service-provider-products/
policy-enforcement-manager).
Enterprise Manager
Enterprise Manager significantly reduces the cost and complexity of managing multiple F5 devices. You gain a
single-pane view of your entire application delivery infrastructure and the tools you need to automate common
tasks, ensure optimized application performance, and improve budgeting and forecasting to meet changing
business needs.
For more information, refer to the Enterprise Manager page (f5.com/products/modules/enterprise-manager).
BIG-IP Link Controller
BIG-IP Link Controller puts the management of ISP links under your control. It monitors the performance and
availability of each link and directs connections—both inbound and outbound—over the best possible link. It also
improves application performance by prioritizing and optimizing traffic. BIG-IP Link Controller gives you the tools
to direct traffic over the most cost-effective connections first so you can keep your ISP costs at a minimum.
For more information, refer to the BIG-IP Link Controller page (f5.com/products/modules/link-controller).
Carrier-Grade NAT
Carrier-Grade NAT (CGNAT) offers a broad set of tools that service providers (SPs) can use to migrate successfully
to IPv6 while continuing to support and inter-operate with existing IPv4 devices and content. BIG-IP CGNAT offers
SPs tunneling solutions such as Dual-Stack Lite and MAP along with native network address translation solutions
such as NAT44 and NAT64. Carrier-grade scalability and performance is achieved by supporting a large number of
IP address translations, very fast NAT translation setup rates, high throughput and flexible logging for subscriber
traceability.
F5 recommends that you not deploy CGNAT with only a small address translation pool. The SP-DAG constraints of
a source IP hash could result in some Traffic Management Microkernel (TMM) instances prematurely exhausting
their quota of addresses and having to solicit help from a different TMM, which impairs performance. Generally,
141
MODULES—Procedures
you need three times the number of translation addresses as TMMs to have a 90 percent chance of each TMM
owning at least one address.
It is not advisable to enable CGNAT inbound connections unless absolutely necessary. The additional mapping
constraints it imposes means more Public IP addresses are consumed. An external listener must also be created
for each entry in the session database to check whether each inbound connection conforms.
In Deterministic NAT (DNAT), mappings between the NAT subscribers and outside IP addresses and port ranges
are allocated at the time of configuration. To ensure service continuity when deploying DNAT, it is advisable to
configure a backup (NAPT) source translation pool.
Avoid small block sizes when deploying CGNAT Port Block Allocation. If the size is set lower than the default of 64
you could jeopardize performance because the maximum connection rate and maximum number of concurrent
connections suffers.
Although the BIG-IP system supports a wide range of CGNAT logging options, for performance considerations you
should only enable options you really need.
Note With the introduction of an off-box version of dnatutil, customers who want to use DNAT mode must
keep this version of the tool current since it can only interpret logs generated up to its current release. The
latest version of the tool can be obtained from F5 Downloads (downloads.f5.com). If you use DNAT in BIG-IP
12.1 through 13.0, you can expect your system to experience performance degradation. Beginning in BIG-IP
13.1, the DNAT algorithm is improved to help mitigate performance degradation by approximately 50
percent compared with BIG-IP 12.1 through 13.0.
IPFIX is a generic logging capability used by CGNAT, BIG-IP AFM, and PEM. If your IP Flow Information
Export (IPFIX) collector is capable of TLS, F5 recommends specifying one of these terms of transport as the
preferred transport when security is an issue.
For more information, refer to the Carrier-Grade NAT page (f5.com/products/service-provider-products/carrier-

grade-nat).
Viewing valid and expired licenses
For information about license status for your purchased modules, refer to “Licenses and Entitlement”.
Procedures
This section details how to complete the following module-related tasks
To delete datastor application volume using the Configuration utility
1. Navigate to System > Disk Management.
datastor allocation appears on one of the hard drives (for example HD1).
If it doesn’t, you can skip the rest of this procedure.
2. Click the disk label for the drive containing the datastor allocation.
142
MODULES—Procedures
3. Under Contained Software Volumes, select Datastor.
4. Click Delete.
To provision SSDs for datastor using the Configuration utility
2. Click the SSD disk label (for example, SSD1).
The General Properties page opens for the logical disk you selected.
3. Under General Properties, for Mode, select Datastor.
4. Click Update.
5. Repeat for each SSD displayed on the System > Disk Management page.
To disable BIG-IP AAM using the Configuration utility
2. Find the Acceleration Manager (AM) list and note its current setting.
3. Select None (Disabled).
4. Click Submit.
5. Click OK.
The BIG-IP system restarts without BIG-IP AAM provisioned.
6. Click Continue.
To delete datastor application volume using the Configuration utility
datastor allocation appears on one of the hard drives (for example HD1).
If it doesn’t, you can skip the rest of this procedure.
2. Click the disk label for the drive containing the datastor allocation.
3. Under Contained Software Volumes, select Datastor.
4. Click Delete.
143
To provision SSDs for datastor using the Configuration utility
2. Click the SSD disk label (for example, SSD1).
The General Properties page opens for the logical disk you selected.
3. Under General Properties, for Mode, select Datastor.
4. Click Update.
5. Repeat for each SSD displayed on the System > Disk Management page.
To re-enable BIG-IP AAM using the Configuration utility
2. From the Acceleration Manager (AM) list, click Nominal (or its previous setting, which you noted
when you disabled it).
3. Click Update.
4. Click OK.
The BIG-IP system restarts with BIG-IP AAM provisioned. This may take a minute or so.
5. 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 page. The logical view displays the
datastor allocation for each disk.
Monitoring SSD use
If you are using solid-state drives (SSDs) for datastor, you can view the SSD allocation and monitor the SSD
lifespan.
To monitor the SSD lifespan using the Configuration utility
2. Click the disk label for the disk you want to monitor.
3. Note which bays contain SSDs.
4. View the Media Wearout Indicator to monitor disk usage.
144
MODULES—Additional resources
mentioned in this chapter. You can find solution articles and the right product manuals for your software version by
searching (support.f5.com).
Table 11.3 Additional modules resources

BIG-IP PSM product page (https://support.f5.com/kb/
BIG-IP Protocol Security Module (PSM) en-us/products/big-ip_psm/manuals/product/psm_config_
guide_10_2/psm_introduction.html).
BIG-IP DNS/GTM product page (support.f5.com/kb/

BIG-IP DNS
en-us/products/big-ip_gtm.html).
BIG-IP LTM product page (support.f5.com/kb/en-us/
BIG-IP Local Traffic Manager (LTM)
products/big-ip_ltm.html).
BIG-IP AFM datasheet (f5.com/pdf/products/big-ip-
BIG-IP Advanced Firewall Manager (BIG-IP AFM)
advanced-firewall-manager-datasheet.pdf).
BIG-IP APM product page (support.f5.com/kb/en-us/
BIG-IP Access Policy Manager (APM)
products/big-ip_apm.html).
BIG-IP ASM product page (support.f5.com/kb/en-us/
BIG-IP Application Security Manager (ASM)
products/big-ip_asm.html).
BIG-IP AAM product page (support.f5.com/kb/en-us/
BIG-IP Application Acceleration Manager (AAM)
products/big-ip-aam.html).
PEM product page (support.f5.com/kb/en-us/
BIG-IP Policy Enforcement Manager (PEM)
products/big-ip-pem.html).
Carrier-Grade NAT product page (f5.com/products/
Carrier-Grade NAT
service-provider-products/carrier-grade-nat).
BIG-IP Link Controller product page (support.f5.com/
BIG-IP Link Controller
kb/en-us/products/lc_9_x.html).
Enterprise Manager product page (support.f5.com/
Enterprise Manager (EM)
kb/en-us/products/em.html).
145
MYSQL—
MySQL
Background
Important
It is not necessary to do any optimization or maintenance tasks for a MySQL deployment.
F5 does not support direct manipulation of the MySQL database.
Do not do operations on the MySQL database unless directed to do so by F5® Support.
Even for extremely busy BIG-IP® systems, use of the MySQL database by the BIG-IP system is typically
very light.
MySQL database daemon
Your BIG-IP system includes the MySQL database daemon. This daemon is always running and tracks the
following:
• BIG-IP Advanced Firewall Manager™ (AFM™) DoS/DDoS information and policy logs.
• BIG-IP Application Security Module™ (ASM®) policies.
• Application Visibility and Reporting (AVR) statistics.
• BIG-IP Access Policy Manager® (APM®) request logging.
F5 has implemented the following measures by default:
• BIG-IP ASM policies are automatically exported and included in a UCS backup. For more information, refer
to “Backup and Data Recovery”.
• AVR statistics are regularly purged to keep the size of the tables under a million records, and the overall size
of the database under 2GB.
• BIG-IP APM log data is regularly purged to keep the maximum number of entries under 5 million records.
Special requirements
If you have special requirements of the MySQL database, such as exporting of the data to long-term storage, it is
best to contact F5 Consulting (f5.com/support/professional-services) for assistance in creating a supported
solution.
146
MYSQL—Additional resources
version by searching AskF5™ (support.f5.com).
Table 12.1 Additional MySQL resources

Troubleshooting the BIG-IP ASM MySQL K4194: Troubleshooting the BIG-IP ASM MySQL
database database.
147
CACHES—At a glance–Recommendations
Caches
F5® has identified the following cache recommendations:
• Let cache objects time out and expire without intervention.
• Manage and maintain the contents that are stored in cache.
• View cache utilization on a weekly basis if memory and disk utilization is higher than normal.
• Determine DNS cache performance and statistics.
• Invalidate cached content for an application and node when updating content every hour or every day.
• Manage BIG-IP® AAM® caching behavior by examining the X-WA-info debug headers and the BIG-IP AAM
dashboard.
Background
information.
BIG-IP cache feature
The BIG-IP Cache Setting feature, formerly known as RAM Cache, uses the information from the Vary header to
cache responses from the origin web server (OWS). OWS can include information within the Vary header to
determine which resource the server returns in its response.
For example, if a page is optimized for a particular web browser, OWS response may return the Vary: User-Agent
HTTP header. The proxy server then uses this information to determine whether to return a cached copy of the
response to subsequent requests, or to query the OWS for the resource again (a subsequent client request
containing a different User-Agent value forces the proxy to query the OWS for the resource again).
An HTTP cache is a collection of HTTP objects stored in the BIG-IP system memory which subsequent
connections can reuse to reduce traffic load on the origin web servers. The goal of caching is to reduce the need
to send frequent requests for the same object, and eliminate the need to send full responses in many cases. You
can enable HTTP caching on the BIG-IP system by associating a Web Acceleration profile with a virtual server.
Note Web Accelerator is not supported in BIG-IP 11.4 and later.
148
CACHES—
Cacheable content
The BIG-IP cache feature complies with the cache specifications described in RFC 2616. You can configure the
BIG-IP system to cache the following content types:
• 200, 203, 206, 300, 301, and 410 HTTP responses.
• Responses to HTTP GET requests.
• Other HTTP methods for uniform resource identifiers (URIs) specified for inclusion in cached content, or
specified in iRules™.
• Content based on the User-Agent and Accept-Encoding values. The cache feature holds different content for
Vary headers.
The default cache configuration caches only responses to HTTP GET requests. However, you can configure the
Web Acceleration profile to cache other requests, including non-HTTP requests. To do this, you can specify a URI
in the URI Include or Pin List within an HTTP profile, or write an iRule.
Non-cacheable content
The cache feature does not cache the following items:
• Private data specified by cache control headers.
• Action-oriented HTTP methods such as HEAD, PUT, DELETE, TRACE, and CONNECT.
• Set-Cookie headers sent by the origin web server.
BIG-IP DNS cache feature
You can configure a transparent cache on the BIG-IP system to use external DNS resolvers to resolve queries and
then cache the responses from the resolvers. The next time the system receives a query for a response that exists
in the cache, the system immediately returns the response from the cache. The transparent cache contains
messages and resource records.
A transparent cache in the BIG-IP system consolidates content that would otherwise be cached across multiple
external resolvers. When a consolidated cache is in front of external resolvers (each with their own cache), it can
produce a much higher cache hit percentage.
BIG-IP AAM optimization cache feature
BIG-IP AAM optimization cache is a self-managing feature. A small amount of TMM memory is used together with
a disk-based datastor/metastore database. The two ways to view BIG-IP AAM caching behavior are by using
X-WA-Info debug headers and through the dashboard in the Configuration utility.
149
CACHES—Procedures
Procedures
This section details how to complete the following cache-related tasks:
Displaying cache setting entries at the command line
You can display the contents of the Cache Setting feature with the command line using the tmsh ramcache
command. The ramcache command includes a number of other options that you can use to display only those
Cache Setting entries corresponding to specific uniform resource identifiers (URIs), URI branches, or hosts.
For more information about using tmsh to manipulate Cache Setting entries, refer to Traffic Management Shell
(tmsh) Reference Guide.
Note For information about how to locate F5 product guides, refer to AskF5™ article: K12453464: Finding
To display the Cache Setting entries for a particular profile at the command line
tmsh
show ltm profile ramcache <profilename>
All of the HTTP cache entries on the BIG-IP system displays.
To display the Cache Setting entries on BIG-IP AAM at the command line
tmsh
show ltm profile web-acceleration <profilename>
To determine percentage of memory used by each TMM process at the command line
tmctl -d blade tmm/pagemem
To view DNS cache statistics using tmsh at the command line
tmsh
150
CACHES—Procedures
show ltm dns cache
Statistics for all of the DNS caches on the BIG-IP system display.
show ltm dns cache <cache-type>
To display statistics for each transparent cache using tmsh at the command line
tmsh
2. At the command line, type syntax:
show ltm dns cache <cache type> <cache name>
Example:
show ltm dns cache transparent test
Statistics for the transparent cache on the system named test display.
To view DNS cache statistics using the Configuration utility
1. Go Statistics > Module Statistics > Local Traffic.
2. For Statistics Type, select DNS Cache.
3. Click View.
To view DNS cache records using tmsh at the command line
tmsh
show ltm dns cache <cache type> <cache name>
Example:
show ltm dns cache transparent test
Managing transparent cache size
To determines the amount memory a BIG-IP system has installed and how much of that memory to commit to
DNS caching, you can view the statistics for a cache to determine how well the cache is working. You can also
change the size of a DNS cache to fix cache performance issues.
151
CACHES—Procedures
To modify cache statistics using the Configuration utility
1. Navigate to DNS > Caches : Cache List.
2. Click the name of the cache you want to modify.
3. In Message Cache Size, type the maximum size in bytes for the DNS message cache.
The BIG-IP system caches the messages in a DNS response in the message cache. A larger
maximum size makes it possible for more DNS responses to be cached and increases the cache
hit percentage. A smaller maximum size forces earlier eviction of cached content, but can reduce
the cache hit percentage.
4. In Resource Record Cache Size, type the maximum size in bytes for the DNS resource record
cache.
The BIG-IP system caches the supporting records in a DNS response in the Resource Record
cache. A larger maximum size makes it possible for more DNS responses to be cached and
increases the cache-hit percentage. A smaller maximum size forces earlier eviction of cached
content, but can reduce the cache hit percentage.
Note The message caches size include all TMMs on the BIG-IP system. If there are eight TMMs, multiply
the size by eight and put that value in this field.
Invalidating cached content
Cache invalidation is a powerful tool that you can use to maintain tight coherence between the content on your
origin web servers and the content that the BIG-IP system caches.
If you update content for your site at regular intervals, such as every day or every hour, you can use lifetime rules
to ensure that the system’s cache is refreshed with the same frequency.
Invalidation rules allow you to “expire” cached content before it has reached its time to live (TTL) value. Invalidation
rules are good to use when content updates are event-driven, such as when an item is added to a shopping cart, a
request contains a new auction bid, or a poster has submitted content on a forum thread.
Note Invalidating the cached content on the BIG-IP system temporarily increases traffic to the origin web
servers until the BIG-IP module repopulates the cache.
To invalidate cache content using the Configuration utility
1. Navigate to Acceleration > Web Application : Invalidate Content.
2. For the application cache you want to invalidate, select the check box.
3. Click Invalidate.
152
CACHES—Procedures
Enabling X-WA-Info headers for testing or troubleshooting
WA-Info HTTP headers are headers that are optionally inserted into responses to the client by the BIG-IP AAM
system to provide information on how the response was processed. This facility and the Dashboard provide the
only facilities to track the behavior of BIG-IP AAM web optimization cache.
Note The X-WA-Info headers feature should only be active in testing or troubleshooting and usually will be
requested by F5 Support. It should not be left on in a production environment as there is an associated
processing overhead providing this information in every transaction in the network traffic.
To enable X-WA-Info headers using the Configuration utility
1. Navigate to Acceleration > Web Applications : Applications.
2. Choose the appropriate application, then navigate to Advanced.
3. Navigate to Debug Options.
4. For X-WA-Info Header option, click Standard or Debug.
Using the BIG-IP AAM dashboard utility
The dashboard default reporting page summarize information about the memory, performance, throughput, and
cache behavior of BIG-IP AAM. These include the following:
• Web Optimized
• Transactions Web Image
• Optimization Optimized
• Web Throughput Web
• Cache Effectiveness
• Web Cache Invalidations
• Memory Usage
Web optimized transactions
This page displays performance metrics for cached transactions in tabbed views, including From cache, Proxied,
and Errors. A combined view is also available.
From cache shows cached transactions per second against time, collected in increments of 5 minutes, 3 hours,
24 hours, 1 week, or 1 month. You can point to the line in the graph to display a specific time and number of
cached transactions per second. If configuration changes were made, a red circle appears in the graph, which you
can click to view additional details.
153
CACHES—
Optimized Web Throughput
This page displays selectable throughput metrics in tabbed views, including From cache and Proxied. A combined
view is also available.
From cache shows cached bytes per second against time, collected in increments of 5 minutes, 3 hours, 24
hours, 1 week, or 1 month. You can point to the line in the graph to display a specific time and number of cached
bytes per second. If configuration changes were made, a red circle appears in the graph, which you can click to
view additional details.
Web Cache Effectiveness
This page displays selectable cache metrics in tabbed view, including Entries, Bytes, and Evictions. A combined
view is also available.
• Entries shows the number of cached entries against time, collected in increments of 5 Minutes, 3 Hours, 24
Hours, 1 Week, or 1 Month. You can point to the line in the graph to display a specific time and number of
cached entries. If configuration changes were made, a red circle appears in the graph, which you can click
to view additional details.
• Bytes shows the total size of cached entries (in bytes) against time, collected in increments of 5 Minutes, 3
Hours, 24 Hours, 1 Week, or 1 Month. You can point to the line in the graph to display a specific time and
total size of entries in bytes. If configuration changes were made, a red circle appears in the graph, which
you can click to view additional details.
• Evictions shows the number of cached evictions against time, collected in increments of 5 Minutes, 3
Hours, 24 Hours, 1 Week, or 1 Month. You can point to the line in the graph to display a specific time and
number of evictions. If configuration changes were made, a red circle appears in the graph, which you can
click to view additional details.
Web Image Optimization
This page displays selectable image metrics in tabbed view, including Current Reduced, Total Reduced,
Current Savings, Total Saving, Average Size, and Images Optimized. A combined view is also available.
Web Cache Invalidations
This page displays selectable invalidations metrics in a tabbed view, including Triggered Sourced, Triggered
Received, ESI Sourced, and ESI Received. A combined view is also available.
To easily check for an Invalidation trigger, set the time period to 3 Hours and watch the far right of the page for a
small peak to appear. Wait a few moments, then switch the time period to 5 Minutes. The page takes time
collecting and adjusting the display of the data over the entire page time axis.
154
CACHES—Additional resources
Table 13.1 Additional caches resources

Overview of the Web Acceleration profile. K4903: Overview of the Web Acceleration profile
Displaying cache setting entries using command- K13255: Displaying and deleting Cache Setting entries
line interface. at the command line (11.x - 12.x)
DNS Cache: Implementations in the BIG-IP LTM
DNS Caches.
Guide.
SNMP MIB files. K13322: Overview of BIG-IP MIB files (10.x - 12.x)
K13878: The ‘ramcache.maxmemorypercent’ variable

Memory allocation for the BIG-IP Cache Setting
controls memory allocation for the BIG-IP Cache
feature.
Setting feature (11.x - 12.x)
K5157: BIG-IP LTM Cache Setting feature and HTTP
HTTP Vary header functionality.
Vary header functionality
155
EXTERNAL APIS—Background
External APIs
F5® has not identified any recommendations for this section.
Background
information.
BIG-IP APIs and automation interfaces
The BIG-IP® system has a number of external APIs and interfaces, which are useful for a wide range of
administrative functions, including configuration, monitoring, and reporting. These APIs and interfaces do not
need to be maintained.
The BIG-IP system contains or uses the following APIs and programming/automation interfaces:
• TMOS Shell (tmsh)
• iControl®
• iApps®
• iCall®
• iRules®
• iControl® REST
• iControl® SOAP
• SNMP
tmsh
tmsh is the BIG-IP command-line interface (CLI). It shares many of the same properties and features of other
networking and systems industry shells, such as GNU Bourne Again Shell (BASH), Cisco IOS, and Juniper JunOS.
tmsh uses a Tool Command Language (Tcl) syntax and command-set, which has been expanded and extended
by F5 for tmsh.
• BIG-IP single configuration file (SCF) and on-disk configuration files are all written in native tmsh syntax and
have advanced scripting capabilities, all based on F5 enhancements to Tcl.
• tmsh is the basis for other interfaces, such as iApps and iCall, and is the base mapping for iControl REST.
• tmsh can be used to automate any tmsh commands.
156
Example:
tmsh help /cli script
• tmsh contains a built-in help system.
Files related to tmsh
• /config/bigip_script.conf — Stores tmsh scripts added to the system
• /config/bigip_user.conf — User configuration, including shell preference
• /config/bigip_base.conf — Management interface configuration
• /config/bigip.conf — Self-IP configuration
Logs related to tmsh
• /var/log/ltm — Default location for most core BIG-IP messages
• /var/log/audit.log — Audit logging, if auditing is enabled
iControl
iControl is the open, web services-based API used by the BIG-IP system that allows complete, dynamic,
programmatic control of F5 configuration objects. It enables applications to work in concert with the underlying
network based on true software integration.
iControl comes in two forms, iControl SOAP and its successor iControl REST. While both forms are supported,
iControl SOAP is no longer being fully developed and is in the process of being deprecated. New implementations
should use iControl REST.
iControl SOAP is based on Simple Object Access Protocol (SOAP), a legacy protocol which was once very popular
for web-based APIs. iControl SOAP was released in BIG-IP 9.0. It is more difficult to program in than iControl
REST, but external libraries are available to assist in writing code.
iControl REST uses modern web standards in the form of Representational State Transfer (REST) and JavaScript
Object Notation (JSON). iControl REST is used in BIG-IP systems 11.4 and later. Its API is based on tmsh, sharing
the same overall layout and structure. It is essentially a JSON version of tmsh that adheres to REST standards.
iControl REST complies with modern web-based programming paradigms and is easier to use and implement than
iControl SOAP.
iControl automation is generally written using systems and languages external to the BIG-IP system. It is your
responsibility to ensure they are properly versioned and backed up.
Logs related to iControl
• /var/log/ltm — Default location for most core BIG-IP messages
• /var/log/audit.log — Audit logging, if auditing is enabled
157
iApps
iApps is the BIG-IP system framework for deploying services-based, template-driven configurations on BIG-IP
systems running TMOS 11.0.0 and later. iApps allows creation of application-centric deployment interfaces on
BIG-IP systems, reducing configuration time and increasing accuracy of complex traffic management
implementations. The goal of iApps is to enable Subject-Matter Experts (SME) to build finely tuned configurations
that can be deployed by administrators who possess application-level expertise without requiring them to be
concerned about lower-level networking details.
The iApps is primarily used to package and deliver expert-created configurations to a non-expert audience. Its
implementation language is standard tmsh scripting with environmental variables for Application Presentation
Language (APL) user selections. It uses the F5-specific APL to render a user-facing presentation interface. It
allows prescriptive abstraction of repeatable configurations based on user-facing input.
Configuration information is stored in UCS/SCF backups by default, with no special action required. For more
information, refer to “Backup and Data Recovery”.
Files related to iApps
• /config/bigip_script.conf — Stores iApp Templates added to the system.
Logs related to iApps
• /var/tmp/script.log — All non-APL output from iApp Templates goes to this file.
iCall
iCall is an event-based automation system for the BIG-IP control plane, introduced in BIG-IP 11.4. It can send and
receive external events using any ports or protocols and can be useful for integration into upstream orchestration,
or for driving orchestration directly from the BIG-IP system.
It uses standard tmsh syntax and is still in the early phases of development, so there is minimal documentation.
All events are user-defined and none of the internal events are currently exposed.
Files related to iCall
• /config/bigip_script.conf — Stores all iCall configuration and scripts added to the system.
Logs related to iCall
• /var/tmp/script.log — All output from iCall scripts goes to this file.
iRules
iRules is a powerful and flexible feature within BIG-IP Local Traffic Manager™ (LTM®) that you can use to manage
158
your network traffic. Using syntax based on the industry-standard Tools Command Language (Tcl), greatly
enhanced by F5, iRules not only allows you to select pools based on header data, but also allows you to direct
traffic by searching on any type of content data that you define. Thus, the iRules feature significantly enhances
your ability to customize your content switching to suit your exact needs.
iRules fully exposes BIG-IP internal Traffic Management Microkernel (TMM) packet/data processing, allowing
inspection, manipulation and optimization and contains a number of mechanisms for exporting information out of
the data-plane.
Out-of-band/side-band connections: Enable asynchronous communication with outside hosts from within TMM/
iRules. (For more information, refer to iRules Sideband documentation on DevCentral™ (devcentral.f5.com/wiki/
iRules.SIDEBAND.ashx).
Important iRules terms
• iFiles: Stores data/content files and external class-lists for use by iRules.
• iStats: iRules variables that are accessible in tmsh and the other control-plane languages (iApps, iCall, and
so on.). It is the primary vehicle for information sharing between control-plane and data-plane.
iRules management
Files related to iRules
• /config/bigip.conf — Stores all iRules added to the system.
Logs related to iRules
• /var/log/ltm — All logging output from iRules goes to this file.
SNMP
SNMP is an industry-standard application-layer protocol, most commonly used by centralized monitoring and
automation systems. It is a part of the TCP/IP protocol suite.
SNMP Management
The supported method for modifying the SNMP configuration is using tmsh. Editing the SNMP configuration files
directly is not supported and likely results in loss of configuration changes.
159
EXTERNAL APIS—Procedures
Files related to SNMP
• /config/bigip_base.conf — Stores SNMP configuration, as configured using tmsh.
Logs related to SNMP
• /var/log/snmpd.log — All logging output from SNMP goes to this file.
Procedures
There are no specific procedures required for maintaining the operational efficiency of these interfaces. However,
there are some recommended practices to keep in mind when implementing them.
Recommended practices
The BIG-IP system APIs and interfaces are powerful tools and must be created and maintained with the same care
as any other software development project. Inconsistent naming conventions, missing code comments, and
unreviewed code combined with weak change management are the source of many upgrade and maintenance
issues.
Coding best practices with BIG-IP APIs
• Use port lockdown to limit access to necessary interfaces/ports.
• Always develop and test in a non-production environment (BIG-IP VE, for example).
• Use consistent syntax and style.
• Be sure to comment effectively and implement revision control.
• Audit all BIG-IQ® system automation and scripting prior to upgrade to determine ongoing support
for the APIs and interfaces employed.
For more information, refer to “Appendix B: Deployment and Response Methodologies”.
Upgrades
• Before upgrading, verify there are no behavior changes when upgrading in a lab or pre-production
environment.
• After upgrading, confirm operation and functionality of each interface.
For more information, refer to “Appendix B: Deployment and Response Methodologies”.
Log review
• Regularly review logs for alerts or errors.
160
• Investigate and document all alert and error messages.
• Investigate warnings to determine their relevance and any necessary actions.
• Use debug logging only during troubleshooting. This is especially true when using iRules, which can
influence production traffic negatively.
• Use debug logging for specific investigation. Due to verbose logging, the system can generate high volume
of messages.
For more information, refer to “Log Files and Alerts”.
tmsh authentication and authorization configuration
Each user can individually configure their tmsh default shell.
To configure a user’s tmsh default shell at the command line
• At the command line, type the following command syntax:
tmsh: modify auth user [username] shell tmsh
To configure a user’s tmsh default shell using the Configuration utility
1. Navigate to System > Users : User List.
2. Click the user name.
3. In Terminal Access, select tmsh.
4. Click Update.
Setting up self IP port lockdown to accept tmsh traffic on port 22
Port lockdown specifies the protocols and services from which a self IP address can accept traffic. It is a security
feature that allows you to specify particular UDP and TCP protocols and services from which the self IP address
can accept traffic. By default, a self IP address accepts traffic from these protocols and services:
• For UDP, the allowed protocols and services are: DNS (53), SNMP (161), RIP (520).
• For TCP, the allowed protocols and services are: SSH (22), DNS (53), SNMP (161), HTTPS (443), 4353
(iQuery®).
tmsh uses Secure Shell (SSH) on port 22. management port 22 is available on the management interface by
default. To allow self IP addresses to receive traffic for tmsh, you need to configure port lockdown.
161
To configure self IP port lockdown at the command line
• At the command line, type the following command syntax:
modify net self <ip address> allow-service add { tcp:22 }
To configure self IP port lockdown using the Configuration utility
1. Navigate to Network > Self IPs.
2. Click the IP address you want to configure.
3. In Port Lockdown, click the port and protocol that you want to allow.
4. Click Finished.
For more information, refer to Configuring Self IP Addresses in TMOS Management Guide for BIG-IP
Systems.
iControl authentication and authorization configuration
iControl uses the same user role as tmsh and the BIG-IP Configuration utility.
To assign iControl administrative rights to a user at the command line
tmsh
modify auth user <username> role admin
To assign iControl administrative rights to a user using the Configuration utility
2. Click the user name of the user you want to modify.
3. In the Role menu, click Administrator.
4. Click Update.
Self IP port lockdown
Set up self IP port lockdown to limit access to necessary interfaces and ports
162
• For UDP, the allowed protocols and services are: DNS (53), SNMP (161), RIP (520)
(iQuery)
Note Management port 443 is available on the management interface by default. BIG-IP 11.6.0 and earlier
do not support port filtering on the management port interface.
To configure self IP port lockdown at the command line
tmsh
3. In Port Lockdown, select the port and protocol that you want to allow.
4. Click Finished.
Systems.
iApps authentication and authorization configuration
To assign iApps administrative rights to a user at the command line
tmsh
To assign iApps administrative rights to a user using the Configuration utility
163
4. Click Update.
• For UDP, the allowed protocols and services are: DNS (53), SNMP (161), RIP (520).
(iQuery).
Note Management port 443 is available on the management interface by default. BIG-IP 11.6.0 and earlier
do not support port filtering on the management port interface.
tmsh
4. Click Finished.
Systems.
Note For information about how to locate F5 product guides, refer to AskF5™ article: K12453464: Finding
iCall authentication and authorization configuration
To assign iCall administrative rights to a user at the command line
tmsh
164
To assign iCall administrative rights to a user using the Configuration utility
4. Click Update.
iCall access
iCall is a local event system for the BIG-IP system. It does not have any ports available.
• For UDP, the allowed protocols and services are: DNS (53), SNMP (161), RIP (520)
(iQuery)tmsh uses SNMP on ports 161 and 162 (traps).
• To configure self IP port lockdown at the command line
tmsh
modify net self <ip address> allow-service add { tcp:161 tcp:162 }
4. Click Finished.
165
EXTERNAL APIS—Additional resources
Systems.
SNMP authentication and authorization configuration
To configure SNMP at the command line
tmsh
tmsh help /sys snmp
SNMP automation includes systems and languages external to the BIG-IP system.
Important There is no user-based authentication or authorization for SNMP. Anyone with access to the port
can send and receive information. Do not expose SNMP to uncontrolled networks.
Table 14.1 Additional external APIs resources

Searching BIG-IP iHealth results BIG-IP iHealth User Guide
iApps DevCentral™ iApps (devcentral.f5.com/iApps)
DevCentral iControl (devcentral.f5.com/wiki/iControl.
iControl
HomePage.ashx)
iCall DevCentral iCall (devcentral.f5.com/iCall)
iRules DevCentral iRules (devcentral.f5.com/iRules)
166
SECURITY—Background
Security
F5® has identified the following security recommendations:
• Develop system access policy.
• Develop user and password management.
• Policy monitoring for login failures.
• Monitor indications of DoS/DDoS attacks.
• Join the DevCentral Security Compliance Forum.
• Join the security mailing list.
Background
information.
It includes the following topics:
• Develop a system access policy.
• Develop user and password management.
• Policy monitoring system login activity.
• Monitoring and mitigating DoS/DDoS attacks.
F5 security overview
F5 adheres to industry standard software practices in order to provide software and configurations that are secure
by default. F5 investigates and prioritizes security vulnerability reports based on their potential exploitability.
Security hotfixes released by F5 for version 9.x and later are cumulative.
When a security hotfix is released, it contains all other security-related hotfixes and stability-related hotfixes since
the last software release. F5 is committed to staying up-to-date on all of the known security vulnerabilities and
actively monitors and participates in the following vulnerability databases, all of which it has full membership.
These include:
• CERT Coordination Center (CERT/CC).
• CVE (Common Vulnerabilities and Exposures).
F5 actively monitors and responds to the following databases:
• Bugtraq database.
167
• Redhat Security Mailing List.
• CentOS Security.
Security Updates mailing list
F5 maintains a mailing list for announcements that relate to security issues.
CVE vulnerability
If you would like to determine if your BIG-IP system is vulnerable to a particular CVE, search for the CVE or VU
number on AskF5 it the best place to start. F5 Global Support also can field questions about vulnerabilities not
covered on AskF5.
If you become aware of a new potential vulnerability in a F5 product, contact F5 Global Support.
In addition, F5 accepts security reports using email at security-reporting@f5.com.
Developing system access policy
F5 recommends the development of a system access policy. This should include, but not be limited to the
implementation of a physical security access policy and network access policy.
Physical access policy
F5 recommends operating and housing the BIG-IP system in a secure, access-controlled location, such as a
datacenter.
Network access policy
F5 recommends frequent network access policy reviews. At a minimum, the following elements should be verified
quarterly or when making changes to the network environment or BIG-IP devices:
Management interface. F5 recommends that you use the management port to provide administrative access to the
BIG-IP system. F5 recommends the management interface be connected to only a secure, management-only
network, such as one that uses a non-routable RFC1918 private IP address space. Refer to AskF5 article: K7312:
Overview of the management port.
Port lockdown. The port lockdown security feature allows you to specify particular protocols and services from
which the self-IP address defined on the BIG-IP system can accept traffic. The default port lockdown setting is
None, which specifies that no connections are allowed on the self-IP address. Refer to AskF5 article: K13250:
Overview of port lockdown behavior (10.x - 11.x). Ensure that the port lockdown feature only allows access to ports
that are necessary for BIG-IP system operation.
Specifying allowable IP ranges for SSH access. You can update the secure shell (SSH) access list from the
Configuration utility and at the command line. Refer to AskF5 article: K5380: Specifying allowable IP ranges for
SSH access. Note that SSH access should only be granted to administrative user networks.
Configuring an automatic logout for idle sessions. F5 recommends you configure automatic logout for idle
168
sessions for the Configuration utility and SSH. Refer to AskF5 article: K9908: Configuring an automatic logout for
idle sessions.
Developing user and password management policy
The BIG-IP system provides methods to control and manage user roles, authentication, and passwords. F5
recommends establishing a password policy for the BIG-IP system. This should include strong password
requirements and regular audit and removal of inactive accounts in agreement with your corporate policies. For
more information about developing a strong password policy refer to the following AskF5 articles:
K13092: Overview of securing access to the BIG-IP system
K12173: Overview of BIG-IP administrative access controls
K13121: Changing system maintenance account passwords (11.x - 13.x)
K4139: Configuring the BIG-IP system to enforce the use of strict passwords
K5962: Configuring a Secure Password Policy for the BIG-IP System
K2873: Characters that should not be used in passwords on F5 products
K13426: Monitoring Login Attempts
Monitoring system login activity
Monitoring login attempts is an important part of network security. Successful and failed login attempts are
recorded in the BIG-IP system audit log.
Reviewing system login activity log messages
You can view BIG-IP system login attempts in the Configuration utility and at the command line. For more
information, refer to Event Logging in BIG-IP TMOS: Concepts.
Interpreting the audit log
Successful command-line login attempts appear similar to the following example:
Mon Jul 6 10:17:38 BST 2014 root 0-0 sshd(pam _ audit): user=root(root) partition=All
level=Administrator
tty=/dev/pts/1 host=192.168.10.10 attempts=1 start=”Mon Jul 6 10:17:38 2014.”
When the user logs out, information that appears similar to the following example is reported:
Mon Jul 6 10:18:30 BST 2014 root 0-0 sshd(pam _ audit): user=root(root) partition=All
level=Administrator
tty=/dev/pts/1 host=192.168.10.10 attempts=1 start=”Mon Jul 6 10:17:38 2014” end=”Mon

169
Jul 6 10:18:30 2014.”:
Unsuccessful command-line login attempts simultaneously generate two messages, as follows: Logged to the /
var/log/audit file:
root 0-0 sshd(pam _ audit): User=root tty=ssh host=192.168.10.10 failed to login after
1 attempts (start=”Mon Jul 6 10:19:10 2014” end=”Mon Jul 6 10:19:14 2013”).:
Logged to the /var/log/secure file:
Jul 6 10:19:14 local/abasm err sshd[24600]: error: PAM: Authentication failure for
root from 192.0.2.10
Successful Configuration utility login attempts appear similar to the following example:
Mon Jul 6 10:23:23 BST 2014 admin 0-0 httpd(mod _ auth _ pam): user=admin(admin)
partition=[All]
level=Administrator tty=1 host=192.0.2.10 attempts=1 start=”Mon Jul 6 10:23:23 2014.”
Unsuccessful Configuration utility login attempts appear similar to the following example:
Mon Jul 6 10:21:03 BST 2014 bob 0-0 httpd(pam _ audit):
User=bob tty=(unknown) host=192.0.2.10 failed to login after 1 attempts start=”Mon

Jul 6 10:21:01 2014” end=”Mon Jul 6 10:21:03 2014”).:
To determine why a Configuration utility login attempt failed, log in at the command line and examine the /var/log/
secure file for a corresponding log entry, similar to the following example:
Jul 6 10:21:03 local/abasm err httpd[4133]: [error] [client 192.168.10.10] AUTHCACHE

PAM: user ‘bob’
- not authenticated: Authentication failure, referer: https://172.16.10.10/tmui/login.

jsp
The previous log entry indicates that the user Bob attempted to log in from 192.168.10.10, but failed to
authenticate. If your organization has a SIEM or central monitoring infrastructure this data may be of great use to
your corporate security team.
Related products
Advanced Firewall Manager can detect and mitigate many DoS/DDoS attack vectors. For more information refer to
BIG-IP Systems: DoS Protection and Protocol Firewall Implementations for your software version.
Application Security Manager can detect and mitigate many application targeted DoS/DDoS attacks. For more
information refer to the BIG-IP Application Security Manager: Implementations.
Monitoring and mitigating DoS/DDoS attacks
The BIG-IP system default configuration is secure; the system denies all traffic except for traffic types that you
specifically configure the system to accept.
Although the deny-by-default approach protects the resources managed by the BIG-IP system against attacks,
170
remote attackers can initiate DoS / DDoS attacks. DoS and DDoS attacks attempt to make a machine or network
resource unavailable to its intended users.
The BIG-IP system provides methods to detect ongoing or previous DoS and DDoS attacks on the system. To
detect these attacks, use the procedures described in the following sections.
SYN flood protection
The BIG-IP system includes a feature known as SYN Check, which helps prevent the BIG-IP SYN queue from
becoming full during a SYN flood attack. The SYN Check Activation Threshold setting indicates the number of new
TCP connections that can be established before the BIG-IP LTM activates the SYN Cookies authentication method
for subsequent TCP connections.
When the BIG-IP LTM activates the SYN Cookies authentication method, the system does not need to keep the
SYN-RECEIVED state that is normally stored in the connection table for the initiated session. Because the SYN-
RECEIVED state is not kept for a connection, the SYN queue cannot be exhausted and normal TCP
communication can continue.
Reviewing SYN cookie threshold log messages
The BIG-IP system may log one or more error messages that relate to SYN cookie protection to the /var/log/ltm
file. Messages that relate to SYN cookie protection appear similar to the following examples:
When the virtual server exceeds the SYN Check Activation Threshold, the system logs an error message similar to
the following example:
warning tmm5[18388]: 01010038:4: Syncookie threshold 0 exceeded, virtual =

10.11.16.238:80
When hardware SYN cookie mode is active for a virtual server, the system logs an error message similar to the
following example:
notice tmm5[18388]: 01010240:5: Syncookie HW mode activated, server = 10.11.16.238:80,

HSB modId = 1
When hardware SYN cookie mode is not active for a virtual server, the system logs an error message similar to the
following example:
notice tmm5[18388]: 01010241:5: Syncookie HW mode exited, server = 10.11.16.238:80,

HSB modId = 1 from HSB
Modification of SYN cookie threshold
For more information about modifying SYN Cookie Protection configuration refer to AskF5 articles: K7847:
Overview of BIG-IP SYN cookie protection (9.x - 11.2.x) and K14779: Overview of BIG-IP SYN cookie protection
(11.3.x - 12.x).
General DoS/DDoS attack vectors
While there are many different DoS/DDoS attack vectors the BIG-IP system protects against without manual
171
configuration, some vectors may require administrative actions to successfully mitigate. This may include but is
not limited to the following:
• Configure protocol profile Idle Timeouts.
• Configure TCP profile settings.
• Configure an IP rate class.
• Configure virtual server connection limits Development of iRules for mitigation Modification of other
configuration relating to DoS/DDoS mitigation.
For more information about detecting and mitigating DoS/DDoS attacks refer to AskF5 article: K14813: Detecting
and mitigating DoS/DDoS attacks (11.4.x - 12.x).
Adaptive reaper
When a connection is opened to a BIG-IP NAT, SNAT, or virtual server, the BIG-IP unit allocates a chunk of
memory for the connection. In order to prevent flooding the BIG-IP unit and to preserve memory, the Adaptive
connection reaper closes idle connections when memory usage on the BIG-IP unit increases. The adaptive
reaping feature allows the BIG-IP system to aggressively reap connections when the system memory utilization
reaches the low-water mark, and stop establishing new connections when the system memory utilization reaches
the high- water mark percentage.
Adaptive reaping may be activated by events or conditions that increase memory utilization, including, but not
limited to the following:
• Dos/DDoS attacks, in which an attacker attempting to increase BIG-IP memory utilization by sending a large
number of connections over a short period of time can cause the system to enter aggressive reaping mode.
• RAM Cache memory allocation.
• Allocating too much system memory for the RAM Cache feature can potentially cause the system to enter
aggressive reaping mode to free memory.
• Memory leaks. If a memory leak persists for an extended period of time, the system may enter aggressive
reaping mode to free memory.
Review adaptive reaper messages
These events are marked in the /var/log/ltm file with messages similar to the following examples:
tmm tmm[<PID>]: 011e0002:4: sweeper _ update: aggressive mode activated.

(117504/138240 pages)
tmm tmm[<PID>]: 011e0002:4: sweeper _ update: aggressive mode deactivated.

(117503/138240 pages)
The BIG-IP system also generates the following SNMP trap when this event occurs:
bigipAggrReaperStateChange.1.3.6.1.4.1.3375.2.4.0.22
172
TMOS based systems do not use Linux memory management for handling traffic, TMM maintains its own memory
that should be monitored separately. You can determine the percentage of memory being used by each TMM
process on the BIG-IP system using the following command:
tmctl -d blade tmm/pagemem
Modification of adaptive reaper thresholds
There is generally no need to change these values as they represent an optimal solution for most BIG-IP
deployments. Contact F5 Support for assistance in determining the best settings for your solution.
Maximum reject rate log messages
The tm.maxrejectrate db key allows you to adjust the number of TCP reset (RST) packets or Internet control
message protocol (ICMP) unreachable packets that the BIG-IP system sends in response to incoming client-side
or server- side packets that cannot be matched with existing connections to BIG-IP virtual servers, self-IP
addresses, or Secure Network Address Translations (SNATs). A high number of maximum reject rate messages
may indicate that the BIG-IP system is experiencing a DoS/DDoS attack.
Review maximum reject rate log messages TCP
When the number of TCP packets exceeds the tm.maxrejectrate threshold, the BIG-IP system stops sending TCP
RST packets in response to unmatched packets, and logs an error message.
For example, when the number of packets matching a local traffic IP address (a virtual IP address) or a self-IP
address exceeds the tm.maxrejectrate threshold, but specify an invalid port; the system stops sending RST
packets in response to the unmatched packets and logs an error message to the /var/log/ltm file that appears
011e0001:4: Limiting closed port RST response from 299 to 250 packets/sec
When the number of packets that match a local traffic IP address (a virtual IP address) and port, or a self-IP
address and port, exceeds the tm.ma xrejectrate threshold, but the packet is not a TCP synchronize sequence
number (SYN) packet and does not match an established connection, the system stops sending RST packets in
response to the unmatched packets. The system also logs an error message to the /var/log/ltm file that appears
011e0001:4: Limiting open port RST response from 251 to 250 packets/sec
Internet Control Message Protocol
When Internet Control Message Protocol (ICMP) exceeds the tm.maxrejectrate threshold, the BIG-IP system stops
sending ICMP unreachable packets in response to unmatched packets, and logs a message to the /var/log/ltm
file that appears similar to the following example:
011e0001:4: Limiting icmp unreach response from 299 to 250 packets/sec
Mitigating DoS/DDoS attacks
The BIG-IP system provides features that allow you to mitigate Dos/DDoS attacks on the system. F5 recommends
173
SECURITY—Additional resources
leaving most of the settings at the default levels. However, in the event that you detect an ongoing DoS/DDoS
attack, you can adjust the settings using the recommendations in the following sections.
Modifying reject rate thresholds
For more information about modifying Reject Rate configuration refer to AskF5 article: K13151: Configuring the rate
at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets (11.x - 12.x).
Procedures
In addition to maintaining strong authentication and password standards, monitoring login attempts can assist in
tracking both authorized and unauthorized attempts to access a BIG-IP controller, giving administrators vital
information for formulating a security policy and reacting to threats.
To subscribe to the Security Updates mailing list
1. Navigate to the AskF5 Publication Preference Center (interact.f5.com/technews.html).
2. Type your email address.
3. Select the Security Updates check box.
4. Click Submit.
Configuration utility
To view login attempts using the Configuration utility
• Navigate to System > Logs : Audit : List.
To view login attempts at the command line
• View the audit log at the command line in the /var/log/audit file.
version by searching AskF5 (support.f5.com)
Table 15.1 Additional security resources

BIG-IP third-party software matrix. K14457: BIG-IP third-party software matrix (11.x)
174
SECURITY—Additional resources

K4602: Overview of the F5 security vulnerability
response policy
Overview of the F5 security vulnerability response
policy. This document show how vulnerabilities are assessed
by F5 and give pointers on F5 Response policies and
communication.
K4918: Overview of the F5 critical issue hotfix policy
This document covers the policy F5 uses to ensure

Overview of the F5 critical issue hotfix policy. that fixes for critical issues are disseminated quickly
to F5 customers. It also contains links on how to
determine which versions of software are currently
supported for security fixes.
175
OPTIMIZING THE SUPPORT EXPERIENCE—F5 technical support commitment
Optimizing the Support Experience

F5 technical support commitment
F5® strives to continuously improve its support service and create closer customer relationships. Designed to
provide assistance with specific break-fix issues and ongoing maintenance of F5 products, F5 professional
support services are consistently high-quality.
This means:
• F5 network support engineers conduct themselves professionally at all times.
• F5 is committed to providing the best customer experience possible.
• F5 treats customers are with respect and give them every consideration possible.
• F5 aims to provide resolutions the first time, every time.
• You can ask for manager escalation for unresolved or “site down” issues.
Some technical support issues arise from configuration errors, either within the BIG-IP® system or with other
devices in the network. In other cases, a misunderstanding of BIG-IP capabilities can lead to support questions
and issues. Although F5 does everything possible to prevent defects in BIG-IP hardware and software, these
issues may still arise periodically. Regardless of the root cause of a problem, the goal is to resolve any issues
quickly.
F5 technical support offerings
A variety of technical support offerings are available to provide the right level of support for any organization.
F5 Standard and Premium Support include remote assistance from F5 network support engineers, both online
and over the phone.
Premium Plus customers receive priority status at F5, with fast, easy access to a dedicated team of senior-level,
F5-certified network support engineers and a Technical Account Manager.
To learn more, refer to F5 Technical Support Offerings or send email to services@f5.com.
Professional services
Take advantage of the full range of F5 Professional Services to help you design, customize, and implement a
solution that is right for your IT infrastructure and which supports your business goals.
Professional Services (f5.com/support/professional-services) provides information on a wide range of F5

Professional Services offerings and Professional Services Partners. You can use our online forms to request
Consulting Services OnDemand for custom, shorter scope consulting engagements, or iRules® OnDemand to get
fast access to iRules scripts tailored to your specific needs.
You can make an online request for specific support services by filling out a request form:
176
OPTIMIZING THE SUPPORT EXPERIENCE—F5 certification
• Consulting request form (f5.com/support/professional-services/consulting-request-form).
• iRules consulting request form (f5.com/support/professional-services/irules-consulting-request-form).
GUARDIAN Professional Services Partners
F5 GUARDIAN® Professional Services Partners are authorized as installation providers and are also available to
assist you. F5 GUARDIANs are selected because they have the skills and experience required to ensure successful
implementations of F5 BIG-IP installations.
Refer to F5 GUARDIAN Professional Service Partners (f5.com/support/professional-services#guardian) for a

complete list of partners.
F5 certification
F5 Certified® exams test the skills and knowledge necessary to be successful when working with today’s
application delivery challenges. Our technically relevant and appropriate exams deliver consistently reproducible
results that guarantee excellence in those that achieve certification.
Certification levels
F5 Certified! is the F5 certification program, with a progressive program of four levels (Administrator, Specialist,
Expert, and Professional), each of which build on the skills and knowledge demonstrated on previous exams.
C1 – F5 Certified BIG-IP Administrator (F5-CA)
The starting point for all certifications: a certified BIG-IP Administrator has basic network and application
knowledge to be successful in application delivery.
C2 – F5 Certified Technology Specialists (F5-CTS)
The Technology Specialist certification assures employers that the candidate is fully qualified to design,
implement, and maintain that specific product and its advanced features.
C3 – F5 Certified Solution Expert (F5-CSE)
The Solution Expert focuses on how F5 technologies combine with industry technology to create real-world
business solutions.
C4 – F5 Certified Application Delivery Engineer (F5-CADE)
The Application Delivery Engineer certification exam and requirements are still under development.
C5 – F5 Certified Application Delivery Architect (F5-CADA)
The Application Delivery Architect certification exam and requirements are still under development.
Certificate expiration
F5 certifications are valid for two (2) years. Three months before the expiration date, the holder becomes
177
OPTIMIZING THE SUPPORT EXPERIENCE—Self-help
recertification-eligible and can register for the exam necessary to re-certify. Only the last exam in the highest level
certification achieved needs to be retaken.
Certification beta program
F5 uses beta exams in the creation of all our exams and to maintain their relevancy and accuracy after production.
Beta exams are open to all and give candidates an opportunity to have an impact on the F5 Certified program.
While beta exams are twice as long, they cost less than regular exams and give candidates the chance to leave
feedback on the exam. Beta exams are critical to our exam development process and a great way to change the
F5 Certified program for the better.
Get involved
There are a several ways to get involved with the F5 certification beta program:
• Beta participation. Interested in taking our beta exams? Contact us at F5Certification@f5.com to learn
more.
• Exam development. Contact us at F5Certification@f5.com if you’re interested in helping us create our

Certified exams.
• LinkedIn community. Join us on LinkedIn for answers to frequently asked questions, community developed
resources, and more.
Note: This link takes you to a resource outside of F5, and it is possible that the document may be removed
without our knowledge.
Visit F5 Credential Manager System (certification.f5.com) for information or follow the steps to get registered.
Self-help
F5 offers a number of resources to assist in managing and supporting your F5 systems:
• AskF5™ (support.f5.com)
• Downloads (downloads.f5.com) User name and password required.
• Security Updates (interact.f5.com/AskF5-SubscriptionCenter.html)
• BIG-IP iHealth® (f5.com/support/tools/ihealth)
• TechNews (interact.f5.com/AskF5-SubscriptionCenter.html)
• RSS feeds (https://support.f5.com/csp/article/K9957)
• DevCentral (devcentral.f5.com/) User name and password required.
• F5 Training Programs and Education (f5.com/education/training)
178
AskF5
AskF5 (support.f5.com) is a great resource for thousands of articles and other documents to help you manage your
F5 products more effectively. Step-by-step instructions, downloads, and links to additional resources give you the
means to solve known issues quickly and without delay, and to address potential issues before they become
reality.
Whether you want to search the knowledge base to research an issue, or you need the most recent news on your
F5 products, AskF5 is your source for product manuals, operations guides, and release notes, including the
following:
• F5 announcements
• Known issues
• Security advisories
• Recommended practices
• Troubleshooting tips
• How-to documents
• Changes in behavior
• Diagnostic and firmware upgrades
• Hotfix information
• Product life cycle information
Downloads
Downloads are available from the F5 website. F5 strongly recommends that you keep your F5 software up-to-date,
including hotfixes, security updates, OPSWAT updates, BIG-IP Application Security Manager™ (ASM®) signature
files, and geolocation database updates. All software downloads are available from F5 Downloads (https://
downloads.f5.com).
Security updates
You can receive timely security updates and BIG-IP ASM attack signature updates from F5. When remote
vulnerabilities are discovered, F5 implements, tests, and releases security hotfixes for any vulnerable supported
version, and sends an email alert to the F5 Security mailing list. F5 encourages customers with an active support
account to subscribe to this list. For more information, refer to AskF5 article: K41942608: Overview of AskF5
security advisory articles.
179
BIG-IP iHealth
The BIG-IP iHealth® (iHealth.f5.com) diagnostic viewer is among the most important preventative tools to verify the
proper operation of your BIG-IP system. It ensures hardware and software are functioning at peak efficiency and
helps detect and address issues that may potentially affect F5 systems. BIG-IP iHealth is not integrated within the
BIG-IP system. It is hosted by F5 and can be accessed with any web browser.
F5 recommends you generate a BIG-IP iHealth QKView file on the BIG-IP system and upload it to iHealth on a
weekly basis in order to benefit from the many regularly occurring diagnostic updates. Uploading QKView files to
iHealth also provides F5 technical support with access to your QKView files if you open a support case.
By reviewing the iHealth output, many of the issues commonly experienced by customers can be resolved without
the need for opening a support case with F5.
TechNews
AskF5 Publications Preference Center provides two email publications to help keep administrators up-to-date on
various F5 updates and other offerings:
• TechNews Weekly eNewsletter Up-to-date information about product and hotfix releases, new and
updated articles, and new feature notices.
• TechNews Notifications Do you want to get release information, but not a weekly eNewsletter? Sign up to
get an HTML notification email any time F5 releases a product or hotfix.
• Security Alerts Receive timely security updates and ASM attack signature updates from F5.
AskF5 recent additions and updates
You can subscribe to F5 RSS feeds to stay informed about new documents pertaining to your installed products or
products of interest. The New and Updated Articles page on AskF5 provides an overview of all the documents
recently added to AskF5.
New and updated articles are published over RSS. You can configure feeds that pertain to specific products,
product versions, and/or document sets. You can also aggregate multiple feeds into your RSS reader to display
one unified list of all selected documents.
DevCentral
DevCentral™ (devcentral.f5.com) is an online forum of F5 employees and customers that provides technical
documentation, discussion forums, blogs, media and more, related to application delivery networking. DevCentral
is a resource for education and advice on F5 technologies and is especially helpful for iRules and iApps®
developers. Access to DevCentral is free, but registration is required.
180
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
As a DevCentral member, you can do the following:
• Ask forum questions.
• Rate and comment on content.
• Contribute to “wikis.”
• Download lab projects.
• Join community interest groups.
• Solve problems and search for information.
• Attend online community events.
• View educational videos.
F5 training programs and education

F5 provides training programs and education, including traditional classroom learning opportunities, live online
training, and free, self-paced online courses to help you get the most out of your investment. F5 Training and
Education (f5.com/education/training) provides links to course schedules, pricing, and registration details. It also
has information about alternative training solutions such as virtual and web-based training for those who cannot
attend training in person.
• In-person courses: F5 courses are available in multiple training facilities across five continents. Each one
combines instructor presentations, classroom discussions, and interactive labs. The hands-on learning
environment helps provide a fast track to accomplishing your goals.
• Virtual instructor-led training: Remote on-line courses mirror classroom training. Participants watch the
remote instructors’ live lecture online, participate in discussions, and perform lab exercises using remote
desktop control.
• Free online training: You can use the self-paced Getting Started series of free, web-based courses to learn
how to deploy F5 solutions to address your most common application delivery problems.
Links to more information are provided on F5 Training and Education for those interested in F5 Professional
Certification or a non-accredited Application Delivery Networking Certificate through F5 and the University of
Phoenix.
Note: This link takes you to a resource outside of F5, and it is possible that the document may be removed
without our knowledge.
Engage F5 Support
F5 Support is designed to provide support for specific break-fix issues for customers with active support
contracts. For more information about F5 scope of support, refer to Support Policies.
181
F5 Support resources
F5 Support resources are available 24 hours a day, seven days a week, and are distributed around the world in
multiple support centers. Live support is provided by our professional network support engineers. Hours of
availability may vary depending on the service contract with F5.
Contact numbers
Standard, Premium, and Premium Plus Support customers can open and manage cases by calling one of the
contact numbers listed below.
North America
North America: 1-888-882-7535 or (206) 272-6500
Traffix® Support Only: 1-855-849-5673 or (206) 272-5774
Outside North America
Outside North America, Universal Toll-Free: +800 11 ASK 4 F5 or (800 11275 435)
Additional contact numbers by country
Australia: 1800 784 977
China: 010 5923 4123
Egypt: 0800-000-0537
Greece: 00-800-11275435
Hong Kong: 001-800-11275435
India: 000-800-650-1448; 000-800-650-0356 (Bharti Air users)
Indonesia: 001-803-657-904
Israel: 972-37630516
Japan: 81-3-5114-3260 or 0066-33-812670
Malaysia: 1-800-814994
New Zealand: 0800-44-9151
Philippines: 1-800-1-114-2564
Saudi Arabia: 800-844-7835
Singapore: 6411-1800
South Africa: 080-09-88889
182
South Korea: 002-800-11275435
Taiwan: 00-800-11275435
Thailand: 001-800-12-0666763
United Arab Emirates: 8000-3570-2437
United Kingdom: 44-(0)8707-744-655
Vietnam: 120-11585
Open a support case
F5 provides several resources to help find solutions to problems. Before opening a support case with F5 technical
support, check to see if the issue you are encountering is already documented.
The following is a list of resources to consult before opening a support case with F5:
• Deployment guides and white papers provide information about specific deployment configurations.
• AskF5 provides many articles including known issues, how-to guides, security issues, release notes, and
general information about products. Many of the issues customers encounter are already documented on
this site.
• BIG-IP iHealth enables customers to upload QKView files in order to verify operation of any BIG-IP system.
Gather information to open a support case
If your issue cannot be solved using the resources listed, and you need to open a support case, you must first
gather several pieces of important information about your issue. Providing full and accurate information helps
speed the path to resolution. The required information for the majority of situations is summarized below:
• The serial number or base registration key of the specific BIG-IP system requiring support. For more
information, refer to AskF5 article: K917: Finding the serial number or registration key of your F5 device.
• A full description of the issue. A clear problem statement is the best tool in helping to troubleshoot issues.
Your description should include as much of the following information as you can provide.
• Occurrences and changes: The date and times of initial and subsequent recurrences. Did this issue arise at
implementation or later? Were there any changes or updates made to the BIG-IP system prior to the issue
arising? If so, what were they?
• Symptoms: Ensuring your list of symptoms is as detailed as possible gives more information for support
personnel to correlate with.
• Scope of the problem: Note whether the problem is system-wide or limited to a particular configuration
feature, service, or element (such as VLAN, interface, application service, virtual server, pool, and so on).
• BIG-IP component: The feature, configuration element, or service being used when the problem occurred
(for example: portal access, network access, authentication services, VDI, Exchange).
183
• Steps to reproduce: The steps to reproduce the problem as accurately and in as much detail as possible.
Include expected behavior (what should happen) as well as actual behavior (what does happen).
• Errors: Complete text of any error messages produced.
• Environment: Current usage of the system. (Is this unit in production? If so, is there currently a workaround
in place?)
• Browsers: Types and versions, if applicable.
• Changes: System changes made immediately prior to the problem’s first occurrence. This may include
upgrades, hardware changes, network maintenance, and so on. Have any changes been made to resolve
the problem? If so, what were they?
• Issue Severity: A description of the impact the issue is having on your site or case severity
• Severity 1: Software or hardware conditions on your F5 device are preventing the execution of critical
business activities. The device does not power up or is not passing traffic.
• Severity 2: Software or hardware conditions on your F5 device are preventing or significantly impairing
high-level commerce or business activities.
• Severity 3: Software or hardware conditions on your F5 device are creating degradation of service or
functionality in normal business or commerce activities.
• Severity 4: Questions regarding configurations (“how to”), troubleshooting non-critical issues, or requests
for product functionality that are not part of the current product feature set.
• Contact and availability information including alternate contacts authorized to work on the problem with F5
Support. When there are more personnel available to work with F5 Support, the resolution of your issue may
be expedited.
• Remote access information, if possible.
• A QKView file obtained while problem symptoms are manifesting. A QKView of the system before the
occurrence is also useful. F5 recommends archiving QKView files regularly. For more information, refer to
BIG-IP iHealth in the TMOS Operations Guide.
• Product-specific information: Software versions and types of equipment in use.
• Platform and system. Version and provisioned software modules of the affected system.
To locate platform and system information using tmsh at the command line
• Type the following command:
tmsh show /sys hardware
<SNIP some of the output>
Platform
184
Name BIG-IP 3900
BIOS Revision F5 Platform: C106 OBJ-0314-03 BIOS (build: 010) Date: 02/15/12
Base MAC 00:01:d7:be:bf:80
System Information
Type C106
Chassis Serial f5-jspv-lzxw
Level 200/400 Part 200-0322-02 REV C
Switchboard Serial
Switchboard Part Revision
Host Board Serial
Host Board Part Revision
To copy software version and build number information at the command line
1. Type the following command:
cat /VERSION
Product: BIG-IP
Version: 11.6.0
Build: 0.0.401
Sequence: 11.6.0.0.0.401.0
BaseBuild: 0.0.401
Edition: Final
Date: Mon Aug 11 21:08:03 PDT 2014
Built: 140811210803
Changelist: 1255500
JobID: 386543
2. Highlight and copy the output information and include it with your support case.
To copy provisioned module information at the command line
1. Type the following command:
tmsh list /sys provision
185
sys provision afm { }
sys provision am { }
sys provision apm {
level nominal
sys provision asm { }
sys provision avr { }
sys provision fps { }
sys provision gtm { }
sys provision lc { }
sys provision ltm {
level minimum
sys provision pem { }
sys provision swg { }
2. Highlight and copy the output information and include it with your support case.
Open a support case
If you cannot find the answer to your problem using the resources listed above, you can open a support case
online, using F5 Support (f5.com/support).
Before you open a support case, you need to log in to F5. If you do not have an F5 login, you’ll need to register for
one.
To register for support access
1. Navigate to login.f5.com.
2. Click Register for an F5 Support Account.
3. Enter your email address.
4. Enter your contact information. If you have a support contract, click I have a support contract
and need access to MySupport.
5. Enter your serial number or registration key in the Serial Number or Registration Key (optional)
field.
186
Once you’ve submitted your information, your service contract is reviewed. If your information is
accurate you receive an email from MySupport, and you can use this to open your case.
Send information to Support
Once you have the information listed in “Gather information to open a support case”, transfer it to F5 technical
support following the steps in “Share diagnostic files with F5 technical support”. For more information, refer to
AskF5 article: K2486: Providing files to F5 Technical Support.
Share diagnostic files with F5 technical support
You can provide files to F5 Support using BIG-IP iHealth or Support Files, the F5 file transfer tool. Support Files
complies with global data protection standards to safeguard the data you send.
Prerequisites
Two categories of customers provide files to F5 Technical Support:
• Permanent account holders—Customers who have an F5 support account, including a user email and
password for the AskF5 website
• Temporary users—Associates of permanent account holders who assist them with uploading or
downloading files for an F5 service request
Obtaining a Support Files tool user name and password for a temporary user
If you are a permanent account holder who wants a temporary user to upload or download files for one of your
service requests, you must provide them with a user name and password for logging in to the Support Files
website.
The user name is the case ID from your service request, and the password is in the activity notes of your service
request. You can also request the password directly from F5 Technical Support via email. Temporary passwords
cannot be provided over the phone.
Note Temporary user credentials are only active for a specific service request.
To locate a password for a temporary user in the activity notes of your service request
1. Open the Service Request Details view.
2. In the Activities section, locate the temporary password which should appear in the following
format:
Case file access password : XXyy=zZzZ123
187
Uploading QKView files to BIG-IP iHealth
BIG-IP iHealth allows you to quickly diagnose the health and proper operation of your BIG-IP system, and provides
a convenient location for you to send diagnostic data for case resolution with F5 Technical Support.
If you are running BIG-IP 10.x or later and need to provide a QKView file to F5, the preferred way to do so is to
upload the file to the BIG-IP iHealth website. For more information, refer to K12878: Generating diagnostic data
using the qkview utility.
Uploading and downloading files using support files
Accessing support files
To access Support Files as a permanent account holder
1. In the upper-right corner of the AskF5 home page, click My Support.
If you have not already logged in, you are prompted to do so.
2. Under Service Requests, click the service request for which you want to upload or download
files.
3. On the right side of the Service Request Details section, click Manage Attachments.
The F5 Support Files site opens in a new window.
To access Support Files as a temporary user
• Navigate to the Support Files website and log in using the user name and password provided by a
permanent account holder.
Uploading files using a web browser
1. On the Home folder page, click the folder for the service request you want.
2. Click Incoming (upload to F5).
3. In the upper-right corner of the Upload to F5 page, click the Upload files icon.
4. In the Upload files dialog box, click Browse.
5. In the Open dialog box, navigate to each file you want to upload, point at it with your cursor, select
the check box that displays, and when you are finished selecting files, click Open.
Either a success or failure notification displays. When an upload fails, close the notification and try
again.
188
6. In the Upload Files dialog box, click Done.
Note You cannot see the files in the folder after uploading them.
Downloading files using a web browser
1. On the Home folder page, click the folder for the service request you want.
2. Click Outgoing (download from F5).
3. Select the check box next to the files you want to download.
4. In the upper-right corner of the Download from F5 page, click the Download selected items
icon.
5. Depending on which browser you have, you may be prompted to save your files to the location of
your choice, or they may simply download to your Downloads folder.
Uploading files using SFTP

For permanent account holders, your user name and password are the same as your AskF5 credentials. For
temporary users, your user name is the service request number, and your password must be the correct
passphrase for that service request.
Important Support Files does not support the Secure Copy (SCP) protocol.
Note Support Files 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 supportfiles.f5.com RSA server key MD5 fingerprint is MD5: 04:a6:4b:9b:d4:eb:48:97:15:e6:7f:90
:64:bf:35:96 and the SHA256 fingerprint is SHA256:stQCq50hEwDPfRMeRf/
Ya9dXcm1KCdx5I5llOwODgNU.
1. From the F5 device, SFTP to the supportfiles.f5.com site using the following syntax:
sftp user@host
For example:
sftp c123456@supportfiles.f5.com
or
sftp 1-12345678@supportfiles.f5.com
Note On the first attempt to connect, you must accept the host key. You should compare that output
189
with the fingerprints listed in this article.
2. When prompted for the password, enter the email address of the user associated with the case.
3. To upload the requested files, use the following command syntax for each file:
put <name _ of _ file> <SR _ number>/INCOMING/
For example:
put mybigip.conf C123456/INCOMING/
4. To exit the SFTP utility when all files have been uploaded, type the following command:
quit
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.
Downloading files using SFTP

To download a file from Support Files, you must use the exact file name and location (path) provided by your F5
Technical Support representative.
Important Support Files does not support the SCP protocol.
Note Support Files 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.
1. From the F5 device, SFTP to the supportfiles.f5.com site using the following syntax:
sftp user@host
For example:
sftp C123456@supportfiles.f5.com
or
sftp 1-12345678@supportfiles.f5.com
2. When prompted for the password, enter the password.
3. To list the files available for download, type the following command:
ls C123456/OUTGOING
190
4. To download the requested files, use 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 C123456/OUTGOING/ Hotfix-BIGIP-12.1.0.0.40.1434-ENG.iso
5. To exit the SFTP utility when all files have been downloaded, type the following command:
quit
You may also use external SFTP applications to download files if the files are on a workstation or on another
system.
191
APPENDIX A: OUTSIDE THE BOX—Front panel characteristics
Appendix A: Outside the Box

The following appendices, while not directly relevant to BIG-IP® operations and maintenance, detail features of
BIG-IP system and recommended data center practices.
Front panel characteristics
Figure A.1: BIG-IP 5000 series platform front panel
Although the physical layout of F5® application delivery controllers varies, they typically share some common front
panel features, as shown in the previous figure.
These features include:
1. Management interface
2. USB ports
3. Console port
4. Failover port
5. Indicator LEDs
6. LCD panel
7. LCD control buttons
8. Traffic Management Microkernel (TMM) switch interfaces
On newer application delivery controllers, the serial number is on the front panel, underneath the LCD display. On
older devices, it is located on the back or side panel.
Note The VIPRION 2000 Series platform features an external USB LCD module.
Network connection entry points and traffic types
The BIG-IP system uses two types of network connection entry points:
• Management interface
192
• TMM switch interfaces
Either TMM switch interfaces or the management interface can provide administrative access to the BIG-IP
system. However, F5 recommends that you use the management port. The TMM switch ports are the interfaces
that the BIG-IP system uses to process application traffic. The management interface is intended for administrative
traffic only, and cannot be used for application traffic.
Note For more information about operational activities relating to the management interface and TMM
switch interfaces, refer to “Networking and Cluster Health”.
Console port
On older platforms, the console port is configured with a 9-pin serial port; on new platforms, the console port is
configured with an RJ-45 port.
On 9-pin serial port platforms, you must use a properly constructed null modem cable to connect the 9-pin serial
port to a serial console device. Prefabricated null modem cables with various connectors are available from many
sources, but you must verify the pinouts on each to ensure that they comply with the established standards.
For more information on both pinouts refer to AskF5™ articles:
• K587: Pinouts for serial terminal cables used to connect the 9-pin serial port on F5 products
• K13644: Pinouts for the RJ-45-based console cable and adapter for F5 products
• K13885: Setting the baud rate of the serial console port (11.x - 13.x)
Note F5 recommends that you connect to the console port for administrative access and console logging.
When connected to the console port, you can still monitor activity on the system and carry out
troubleshooting activities should you lose network access to your BIG-IP system or experience daemon
failures.
Failover port (hardwired failover)
In a device service cluster, up to eight BIG-IP systems (hardware or VE) can be connected together for the
purposes of synchronizing their configurations and failing over to one another under certain conditions. By default,
the BIG-IP systems use heartbeat packets sent over the network to communicate their availability and their active
or standby status.
BIG-IP hardware platforms offer the option to connect two devices together in an active-standby device service
cluster (redundant pair), and to allow hardwired failover to occur between the devices. (A VIPRION® platform does
not support hardwired failover, nor is hardwired failover available for any device service cluster with more than two
devices.) Hardwired failover is also based on heartbeat detection, where the standby BIG-IP unit continuously
sends a signal to the active unit in the pair along an RJ-45 or 9-pin serial cable strung between the two units. If a
response does not initiate from the active BIG-IP unit, failover is triggered. When BIG-IP redundant devices
connect using a hardwired failover cable; the system automatically enables hardwired failover.
193
Note Network failover is a requirement for an active-active device service cluster. An active-active pair must
communicate over the network to indicate the objects and resources they service. Otherwise, if network
communications fail, the two systems may attempt to service the same traffic management objects, which
could result in duplicate IP addresses on the network.
Even if you configure hardwired failover, communication over the network is necessary for certain features to
function properly, for example, the communication that occurs over the network during failover mirroring.
Note On active-standby device service clusters (two devices only), F5 recommends that you use hardwired
failover in tandem with network failover wherever possible. For more information, refer to AskF5 article:
K2397: Comparison of hardwired failover and network failover features.
LCD panel and LED indicators
Using the LCD panel and its associated control buttons, you can do management tasks on a BIG-IP or VIPRION
platform without attaching a console or a network cable. Refer to the following figure.
Figure A.2: LCD panel on a BIG-IP 7000 series application delivery controller
The functionality of the LCD menus varies from platform to platform, but the following parameters apply:
• You can use the Options or Config menu to adjust the display properties of the LCD panel.
• On BIG-IP platforms, you can use the System menu to view options for rebooting, halting, and “netbooting”
the hardware, and for configuring the management interface.
• On VIPRION platforms, you can use the System menu to configure the management interface on both
clusters and blades, and to configure various options for the hardware.
• You can use the Screens menu to specify the information that is displayed on the default screens.
BIG-IP systems generally have four indicator LEDs on the LCD panel, while VIPRION platforms include indicator
LEDs in many locations.
For example, the VIPRION 4800 platform includes indicator LEDs on the LCD panel, on the individual blades, on
the power supplies, on the fan tray, and on the annunciator cards. The meaning of each indicator LED can vary
from platform to platform, and details are provided in the associated platform guide.
194
APPENDIX A: OUTSIDE THE BOX—Back panel characteristics
Find a platform guide
To find the appropriate guide for your BIG-IP or VIPRION platform
1. Find platform number on the front panel of the device.
2. Go to AskF5™ (support.f5.com).
3. In the Search field, type:
<platform number> platform guide
Clear the LCD and the alarm LED remotely
In some cases, it may be desirable to clear LCD warnings and the Alarm LED remotely. Performing this action may
prevent on-site personnel from discovering and reporting an old warning, or having to teach the on-site personnel
how to clear the LCD.
Note For instructions on how to clear the LCD and the Alarm LED remotely, refer to AskF5 article: K11094:
Clearing the LCD and the Alarm LED remotely.
Back panel characteristics
Figure A.3: BIG-IP 5000 series platform back panel
As with the front panel, the back panel layout varies from platform to platform. The previous figure shows the back
panel on a BIG-IP 5000 series, which features:
1. Power input panel 1 (power switch and power receptacle)
2. Power blank
3. Chassis ground lug
Some platforms, such as the BIG-IP 7000 Series, feature dual power inputs (switches and receptacles), as shown
in the following figure.
Note Platforms with no power switches are powered on/off by connecting/disconnecting the power plug.
195
APPENDIX A: OUTSIDE THE BOX—VIPRION chassis characteristics
Some platforms, such as the BIG-IP 10000 Series, have power receptacles but no power switches, as shown in
the following figure.
VIPRION chassis characteristics

The VIPRION platform includes two primary components: the chassis and blades, which reside within the chassis
and provide the hardware and software needed to manage network traffic.
196
Figure A.6: VIPRION 4800 Platform chassis components
Although the location varies from chassis to chassis, in general a VIPRION chassis includes:
1. Indicator LEDs (system and power status)
2. LCD display
3. LCD control buttons
4. Blanks for blades
Note The VIPRION 2000 Series platform features an external USB LCD module.
VIPRION blade characteristics
A blade is the primary component that handles the traffic management within the VIPRION platform and the
number of blades supported varies by VIPRION chassis. For example, you can install up to eight blades in a
VIPRION 4800 Series chassis. These blades comprise a group, known as a cluster. The chassis includes blanks in
the slots where blades are not installed.
Blanks must be installed in all unused slots, as they help ensure proper airflow within the chassis and EMI
197
compliance of the unit.
Figure A.7: VIPRION B4300 blade components
A VIPRION blade contains many of the same elements as a BIG-IP platform front panel, including:
1. Compression screw
2. Blade indicator LEDs
3. Management port
4. USB ports (2)
5. Console port
6. Serial (hard-wired) failover port
7. SFP+ ports (8)
8. 40GbE ports (2)
9. Interface indicator LEDs
198
APPENDIX B: DEPLOYMENT AND RESPONSE METHODOLOGIES—Background
Appendix B: Deployment and Response Methodologies

This appendix outlines strategies for managing updates and handling issues for your BIG-IP systems, including:
• Change and revision control
• Testing and validation
• Response methodologies
• Incident handling
• Root-cause analysis (RCA)
This chapter focuses on providing an overview of processes and tools that you can employ to make working with
BIG-IP systems and your application delivery environment more manageable.
Important This appendix provides general guidance and recommendations, but details are up to the
individual customer. There is no one way to identify, step-by-step deployment and response methodologies
in all cases. It is up to you to determine the methods that provide the best fit for your organization. For
assistance with deployment, contact F5 Consulting Services or your F5 sales representative.
Background
information.
Change and revision control
Throughout this section, the term “environment” represents all systems and components that are involved in the
delivery of essential business processes or services.
This section briefly covers practices for configuration management, which are not necessarily specific to BIG-IP
systems. They are based on common methodologies and tools widely used in computer networking.
Unfortunately, inadequate or poorly-documented change control practices are common. F5 strongly recommends
that you employ strong regulation and environmental change tracking for your environment. Good change and
revision control of information aids troubleshooting efforts and is essential in cases where a root-cause analysis
(RCA) is necessary. For more information, refer to “Root-cause analysis”.
Change control
Change control is a strategic and proactive process designed to ensure system changes are carried out in a
controlled and coordinated manner. It is the process of peer-based review and approval of changes to the
environment. Change control is implemented in the form of business processes and driven by people and not
technology.
199
The benefits of an effective change control process include:
• Organizing and monitoring changes during deployment
• Clarifying the possible impacts of changes to your production environment
• Making and documenting decisions based on repeatable and accountable data that considers all changes
made to the environment
• Consolidating changes into a single maintenance period reduces the frequency and impact of service
interruptions
Although change control processes vary by software development lifecycle (SDLC) methodology, industry
standards, and organizational maturity, most contain one or more of the following phases:
• Request: Record who is requesting the change and why (importance, impact, and complexity).
• Evaluation/triage: A formal stakeholder review of the requests with evaluation of risks, business benefits,
impact and so on. Document results of evaluations and make them public for broader review.
• Planning/scheduling: Schedule approved requests to maintenance period and published to stakeholders.
• Testing: Deploy new processes in a non-production environment. If such an environment is not available,
document, peer review, and evaluate code for system impact. Retain formal sign-off of such testing and
reviews.
• Implementation: Prior to implementation, archive images and backups of data, logs, and so on and take
system health baselines, such as BIG-IP iHealth qkviews. Record all changes in a change log, along with
and any observed anomalies.
• Acceptance and close: Conduct acceptance testing or some other method of evaluating the success of the
change. Document completion of changes and regularly conduct post-mortems for both successful and
less- successful maintenance activities.
Revision control
Revision control is a tactical and reactive process of tracking the history of changes made to the environment, but
unlike change control, technology rather than people drive revision control.
Effective revision control process includes:
• Define a clear historical record of changes to provide faster identification, diagnosis, and resolution of
change-related issues.
• Define multiple levels of “roll-back” capability defined for immediate circumvention of unforeseen change-
related issues.
Revision control is particularly important when you employ BIG-IP APIs and automation interfaces and when you
make changes to configuration templates and files. You should hold this work product to the same standards of
any other software development project.
Some customers accidentally deploy differing versions of the same code in their various BIG-IP environments.
200
Such occurrences can negatively affect the BIG-IP system’s performance and thwart the intent of the
customization.
Some revision control systems also provide methods for preventing “concurrent access” problems by simply
locking files so that only one developer has write access to the central repository. Although potentially
controversial, this measure can prevent problems such as one developer overwriting the changes made by
another, which can result in unintended consequences.
Your revision control process should at minimum require developers and system administrators to do the following
when making changes:
• Retain multiple copies of each version of a script or file
• Appropriately label all scripts and files
• Archive all scripts and files in a secure location
Change control compared to revision control
You may have a change control process but not necessarily a revision control process, or vice versa. There are
clear benefits to using both processes in tandem. Change control implies that you have revision control in place
since the effort required to record the history of changes after taking the time to review and validate them is
insignificant. However, it is possible and even desirable in some circumstances to have revision control
implemented without any change control.
F5 strongly recommends using revision control when administering BIG-IP systems. Ideally, all other systems on
the networks with which your BIG-IP devices communicates, such as routers, switches and servers, should also
employ revision control. Having a history of changes to your BIG-IP system(s) and the wider environment provides
essential diagnostic and troubleshooting information. Without this information, you cannot fully investigate many
types of issues and events or fully understand their potential impact since there is no way to correlate changes in
behavior or service with changes in configuration of the systems involved.
In all cases, revision control increases the speed and effectiveness of investigative efforts. However, the most
valuable gain is the ability to roll-back or revert previous changes, which can be vital if a change becomes the
source or trigger of an issue.
Depending on the needs of your organization, you can implement change control as a process around the revision
control system. While revision control tracks the history of changes and provides a better system for recovery from
erroneous changes, change control acts as a gatekeeper, providing a “go/no-go” decision, determining whether
changes are deployed into the environment.
For example, you can simultaneously consolidate and implement minor changes (those with little or no business or
technical impact to the environment) within a maintenance period without the need for a rigorous approval
process. Meanwhile, you can peer-review approve significant changes (those with greater business and/or
technical impact) using a change control or gatekeeper function before they are allowed into the environment.
Having a controlled stream of changes into the environment helps make it very clear whether issues or undesirable
events are related to a specific change or set of changes, and serves to remove all randomization from the
environment.
201
F5 recommends that you use change or revision, individually or in concert when you administer BIG-IP products;
however, F5 does not advocate any particular system or process. Every environment is unique, and only you know
what is best for your application delivery needs.
Revision control systems
While the following revision tools are primarily for source code management, they have the ability to track changes
to data of all kinds.
• Git
• Mercurial
• PERFORCE
• SVN
Change control process example
For this example, assume a team of three administrators: Alice, Bob, and Charlie.
Alice has finished testing a new configuration on a test BIG-IP system and decides the configuration is ready for
introduction into the production environment. Alice checks her change into the revision control system so that it
can be moved into production.
Once a week, on Thursdays, Alice, Bob, and Charlie review and triage all unimplemented changes in revision
control. They discuss each revision and make a collective decision as to whether to a) approve each change and
allow it into the environment, b) defer the change to a later date pending specific updates or modifications for
further review, or c) reject the change.
Simple peer-review is an alternative to a team triage. As implemented in source code development, Alice asks Bob
or Charlie to review and sign-off on her changes. In both processes, the objective is for each change to be double-
checked before it can move on.
Once a week, on Monday mornings, as they push all approved changes into production, Alice, Bob, and Charlie
are all on hand to monitor the deployment. Any new issues they find throughout the week are thus easily tracked
back to a specific change since there is a clear history of what they modified.
Testing and validation
As important as change and revision control are to the application deployment life cycle, proper testing and
validation of environment changes are equally vital. Configuration changes to a BIG-IP system are no exception.
This section provides some high-level recommended practices, along with examples of what these practices might
look like.
There are many different ways to ensure proper vetting of configuration changes before deploying them. All of
methods require some type of tiered environment in which testing can be done.
202
Levels in a tiered deployment environment
Production
The production environment directly serves customers, employees, and other users of your business processes
and application services. Sometimes called the “live” or “production” environment, it is the top tier in the
application delivery environment. F5 strongly suggests that you never make changes directly in the production
environment.
Staging
The staging environment is secondary to the production environment, and it is generally the last stop in any testing
tier. Sometimes referred to as “pre-production,” it may support a subset of production users who are involved in
acceptance testing, or serve as a standby or overflow area for the production environment. It is the last stop for
validating changes before they are introduced into production. As such, the staging environment should be a
direct clone or “mirror” of the production environment in order to mimic the complete production application
delivery experience.
Sandbox
The sandbox environment, one of the lower tiers in testing, is also frequently modeled after the production
environment, but is closer to the developers and administrator than the user. It is often implemented as a virtual
machine or as an isolated lab network.
Tiered environment benefits

Having separate tiered environments for testing, pre-production validation (staging), and production deployment
helps check changes before they reach your critical business users, dramatically decreasing the impact on
business processes and other technology systems. Such a system also reduces the time required for problem
resolution as problems can be reproduced and diagnosed external to your production application delivery
network.
Change deployment lifecycle
Development sandbox
The lifecycle for changes actually begins in the sandbox, which can be as simple as a BIG-IP virtual machine on an
individual workstation or as complex as a small-scale duplication of the production environment, complete with
performance and functional testing suites. The sandbox is where you can evaluate changes free of consequence
to critical production business processes, and where you can control the number of variables for detailed analysis
of behavior.
Application design and testing often occurs on an isolated network in a very specific, non-user environment. All
too often, applications behave completely differently in production simply because they were not tested or built in
the same environment where they are ultimately deployed. In a perfect world, all deployments would have a
complete sandbox that mirrors production, and performance/functional testing would be ongoing. However, due to
203
capital and operational constraints, this is not always possible. Having a minimal sandbox capability, even as basic
as BIG-IP VE on individual workstations, provides significant benefit as a testing and experimentation area.
As portable virtual machines running on any VMware server-based platform, virtual BIG-IP instances can be
integrated into application architecture planning and design stages. This gives application architects access to the
application tools available in all BIG-IP appliances—such as application acceleration and optimization policies,
security policies, and F5 iRules control language.
In this model, BIG-IP virtual edition products can be used as a “pre-development” tool for new applications. Many
parts of the organization may not have access to physical BIG-IP hardware during application design and testing,
but anyone can download trial versions of virtual BIG-IP instances and deploy them with their application as part
of design and testing. This means that designers and integrators can evaluate the interaction between the BIG-IP
devices and the new application to assess and maximize the benefits long before application staging and
production. Downloads of trial F5 project can be found at F5 Product Trials (f5.com/products/trials/product-trials).
Note F5 also offers BIG-IP VE in the cloud through the Amazon Market Place. VMs are available on a “Bring
Your Own License” (BYOL) or hourly/annual subscription basis.
Staging in pre-production
Much like the design stage, testing is usually done in a quarantined part of the network called the staging
environment. In a staging environment, however, applications often act differently than they do production
because they are tested under artificial, simulated circumstances.
Staging provides similar functions to the sandbox, but instead of being a confined environment is reachable
directly along-side production. This is often accomplished using a more-or-less full- scale duplication of the
production network, and then exposed using a separate DNS zone. Beta versions of websites are a good example
of this concept in action. Administrators can do functional testing as though they were a real client, or it can be
used as part of a “phased deployment” paradigm.
In some operational models, a purely virtual solution is most practical. By building BIG-IP Virtual Edition products
into the staging environment during quality assurance (QA) testing, IT staff can more accurately measure and size
the application for real-world deployment, in essence, mirroring the production deployment without negatively
affecting production traffic and applications.
Testing and QA is the best time to customize BIG-IP application policies. BIG-IP applications and policy templates
start with customized network delivery configurations for well-known applications such as Microsoft Exchange
Server, SAP Dynamics, LDAP, and RADIUS. Using BIG-IP LTM VE, for example, the templates can be further
refined to provide a specific delivery environment for the application before it is moved into production. During this
time, iRules can be written and tested with the application to measure the effect on both the application and on
BIG-IP Virtual Edition products.
With easy access to a full-featured, portable BIG-IP virtual platform, everyone involved in the application design
and deployment has the opportunity to build application delivery networking features into the application life cycle
from the beginning.
Going live
Finally, changes make their way into the production environment, and are “live.” This can come in the form of
204
changes being pushed from staging or the revision control system to production, or as a migration of the staging
environment into production as shown in the Phased Deployment example.
As the application is moved into production, BIG-IP Virtual Edition products enable the application delivery life
cycle to be completed under two different models. In both, successful production deployments for BIG-IP virtual
instances depend on deploying the BIG-IP virtual environment along with the physical environment, either in a
stand-alone architecture or as part of a larger enterprise cloud deployment.
Test and development configurations, settings, iRules, and templates for virtual BIG-IP instances can be moved
onto physical BIG-IP appliances as new applications are rolled into production. These application-specific
configuration changes can be quickly tested and validated to work in a production environment, drastically
reducing the time needed to build new production configurations.
In a truly fluid and agile environment, especially one where the new applications are also running on virtual
platforms, BIG-IP virtual instances can be bundled with the application and pushed live to production at the same
time. This model treats BIG-IP virtual instances as an integral and required part of the application rollout, pushing
the vADC as well as the pre- configured application policy templates—fine-tuned during development, test, and
staging—into production together.
By incorporating BIG-IP, virtual edition products into planning for deployments of production applications,
application architects, designers, and developers can see real-world production scenarios at every step of the
application life cycle.
Example: phased deployment

Alice, Bob, and Charlie are the three network administrators of a small website application. They manage the entire
infrastructure, but the content is delivered by a different team that has direct access to the servers for publication.
Alice tests her optimizations of one of the core iRules using a BIG-IP VE in a shared lab environment that is
configured to be equivalent to production.
Once Alice has finished testing her modifications, she publishes them to the revision control system. Simple
repository automation immediately publishes her updates to their staging network, which they call pre-production.
It is a portion of their production environment dedicated to staging. Upstream DNS/routing (or a BIG-IP using
iRules) begins to slowly migrate production traffic into pre-production at a controlled rate; Alice and her team let
it “bleed over” 10 percent of pre-production capacity every 5 minutes. Alice and her team observe their monitoring
and logging systems during this time, looking for any errors, alerts or unexpected behavior. Once the pre-
production environment has sustained production traffic levels for a set length of time, the change is deemed
stable.
Traffic is migrated out of pre-production until the staging network is once again free of production traffic. Alice’s
change is published to production, and the pre-production environment is re-cloned from production. Alice and
her team are ready to submit and validate further changes.
Response methodologies
In the previous section, we explored proactive processes and tools that can be used to help avoid being surprised
by issues and to aid in troubleshooting and resolution when they do arise. This section focuses on what processes
can be put in place to streamline response to issues once they’ve occurred.
205
Incident handling
Incident handling is a very broad topic, with a wide range of implementations and areas of expertise. It is beyond
the scope of this document to cover even a fraction of them. The goal is to introduce the concept at a high-level,
for further exploration and consideration.
Incident handling is defined as the business process by which incoming issues/tickets are triaged, assigned,
investigated, and mitigated. Most organizations have an incident handling process, whether formalized or not. The
advantage of a formalized process, with roles and responsibilities, troubleshooting parameters, and checklists, is
to provide needed structure during difficult situations.
At a minimum, you should consider formalizing:
• Point of contact lists
• Emergency change/revision control
• Data gathering
• Roll back policies and procedures
• Escalation guidelines
Point-of-contact lists
There should always be a clear and singular owner for individual application delivery components or areas of
expertise. It is very common to have an on-call rotation per network, server, application, team, and so on, and for
these rotations to hold true during business hours. A single point-of-contact for each problem domain makes
communication much easier, and provides clear ownership and accountability. It also helps minimize chaos during
incident handling.
It is also a good practice to have a list of backup names for each role and responsibility. Thought should also be
given to vacation coverage and this list should be updated on a regular basis.
Emergency change/revision control
It is possible that the normal process for graduating changes into production is not realistic when troubleshooting
an event real-time. A secondary process for migrating emergency changes made to production into the change/
revision control process is a prudent measure, so that administrators can focus on troubleshooting measures,
while easily capturing their modifications after everything is resolved.
Data gathering
The vast majority of the time, the same data sources is used repeatedly, regardless of the nature of the event
encountered. Prescribing a tailored list of data to gather at the onset of any issue can further minimize chaos by
providing a clear sense of direction, while ensuring that critical data is captured in a time-sensitive manner. Time-
based events are extremely difficult to analyze after the fact without the right supporting documentation. (Refer to
“Root-cause analysis”.)
206
The “Optimizing the Support Experience” contains a comprehensive list of the information and supporting
documentation needed when engaging F5 Support, along with the circumstances under which each is required.
Roll back policy and procedure
For each maintenance period or upgrade, there should be a well-understood path back to a previous version,
environment, or configuration. Ideally, this policy and process should be standard, and include clear criteria and
decision points for whether to fall back or fix forward. If the decision is to fall back, there should be a standard
process for doing so. If the decision is to fix forward, then there should be established escalation procedures to
ensure the issue is resolved quickly. For more information, refer to ”Escalation guidelines”.
Escalation guidelines
Documenting the steps that should be taken before engaging F5 Support for assistance, along with what
conditions warrant immediate engagement of F5 Support, can help minimize disruption and maximize
responsiveness when it is most needed.
Designate a primary representative (“point person”), along with infrastructure and instructions for collaboration by
the points-of-contact. This small step can dramatically improve communication and minimize confusion.
Root-cause analysis
This section covers the steps you can take to ensure a successful investigation of your problem and may speed its
resolution by F5 Support. Although it is impossible to trace every problem back to its original (root) cause, there
are certain steps you can take to maximize the chances of success.
Root-cause analysis (RCA) is the process of reviewing all available forensic and diagnostic information from a
problem to determine the order of events that led to the failure, and to identify the original (root) event that
triggered these downstream events. Determining the conditions that led to a problem may prevent it from
recurring.
RCAs are very difficult to do, even under the best of circumstances. The more comprehensive the information
gathering process is, the better the odds of success. It is your responsibility to ensure that you are capturing
sufficient data should a RCA become necessary. The Optimizing the Support Experience chapter contains a
wealth of information on this subject. A lack of sufficient information or details can make an accurate and complete
RCA difficult or impossible.
Gathering relevant information is useful when conducting a RCA, but at a minimum, it is desirable to have:
• A detailed description of the event
• Date and time of occurrence(s)
• Any recent changes to the overall environment
• Diagnostic and forensic data
For more information, refer to “Optimizing the Support Experience””.
207
Proactive steps to aid future RCAs
Implement some form of change and revision control. Knowing what changed, when, and by whom, is critical to
doing an effective RCA. The absence of this information is, by far, the most common reason RCAs are incomplete
or not possible.
Invest in network monitoring/capturing tools. External information collection from the entire environment can be
essential to correlation. Having multiple sources of similar information goes a long way to forming more concrete
conclusions and can expose inaccurate or compromised data sources. Multiple data sources can be used to
reinforce or refute each other.
Implementing centralized logging
Sending log messages off-device into a central system can preserve historical data for much longer periods. It
also enables correlation with other logging sources in the environment, and makes tampering with the information
more difficult in the case of an intrusion.
Enabling audit logging
The extent to which audit logging is implemented can be determined by operational requirements and industry
standards, but should be considered required if change/revision control is not implemented.
208
APPENDIX C: SUPPORT INCIDENT REPORT—Support Incident Report
Appendix C: Support Incident Report

Support Incident Report
F5 Support may be able to resolve your support issues more quickly when provided with the data they need for
troubleshooting. The worksheet below can help you prepare for opening a case.
Support contract details
• License number(s) of affected hardware
• Your “Point of Contract” details
• Alternative contacts available to work on the issue if you are not available
• Hours you are available to work on the issues
• Remote access availability
Issue details
• Issue symptoms
• Date and time of first issue
• Number of times of issue recurrence
• Error output provided by system
• Steps to reproduce the issue
• Changes made to the system before the issue first occurred
• Steps taken to resolve the issue
• Age of implementation
• Number of datacenters and devices applicable to the configuration
• Devices affected by the issue
• Review of uploaded qkview to BIG-IP iHealth® (Ensure that any qkviews uploaded to BIG-IP iHealth are
linked to the support case.)
209
APPENDIX C: SUPPORT INCIDENT REPORT—Opening a Support Case
Impact of the issue on your site (Choose one)
• Site down: All network traffic has ceased, causing a critical impact to your business.
• Site at risk: Primary unit has failed resulting in no redundancy. Site is at risk of going down.
• Performance degraded: Network traffic is partially functional causing some applications to be

unreachable.
• General assistance required: Questions regarding configurations. Troubleshooting non-critical issue or

request for product functionality that is not part of the current product feature set.
Opening a Support Case

Refer to the following product-specific articles for details about the information you need to provide when opening
a product-specific support case:
Table B.1 Articles to assist with assembling your support case
Product AskF5 article

K135: Information required when opening a support
BIG-IP LTM®, AFM™, DNS™, Link Controller, and PEM™ case for BIG-IP LTM, AFM, DNS, Link Controller, and
PEM
BIG-IP WebAccelerator™
case for BIG-IP WebAccelerator
BIG-IP AAM®
case for BIG-IP AAM
BIG-IP APM® / Edge Gateway®
case for BIG-IP APM / Edge Gateway
BIG-IP ASM®
case for BIG-IP ASM
BIG-IP PSM™
case for BIG-IP PSM
BIG-IP Analytics
case for BIG-IP Analytics
FirePass™
case for FirePass
Enterprise Manager™
case for Enterprise Manager
ARX®
case for ARX®
Traffix SDC™
case for Traffix SDC
210
LEGAL NOTICES—
Legal Notices
Trademarks
AAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced Routing,
AFM, APM, Application Acceleration Manager, Application Security Manager, Applications without Constraints,
ARX, AskF5, ASM, BIG-IP, BIG-IP EDGE GATEWAY, BIG-IQ, BIG-IP iControl, Cloud Extender, CloudFucious,
Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DDoS Frontline, DDoS Hybrid
Defender, DDoS SWAT, Defense.net, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client,
Edge Gateway, EDGE MOBILE, EDGE MOBILITY, EdgePortal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5,
F5 Agility, F5 iApps, F5[DESIGN], F5 Certified [DESIGN], F5 iControl, F5 LINK CONTROLLER, F5 Networks,
F5SalesXchange [DESIGN], F5Synthesis, f5Synthesis, F5Synthesis[DESIGN], F5 TechXchange [DESIGN], F5
TMOS, Fast Application Proxy, Fast Cache, FCINCO, Global Traffic Manager, GTM, GUARDIAN, Herculon, iApps,
IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iCall, iControl, iHealth, iQuery,
iRules, iRules OnDemand, iSeries, iSession, L7 RateShaping, LC, Link Controller, Local Traffic Manager, LTM,
LineRate Operating System, LineRate Point, LineRate Precision, LineRate Systems [DESIGN], LROS, LTM,
Message Security Manager, MSM, OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol
Security Manager, PSM, Real Traffic Policy Builder, Ready Defense, SalesXchange, ScaleN, Signalling Delivery
Controller, Silverline, Silverline Threat Intelligence, SDC, SSL Acceleration, SSL Everywhere, SSL Orchestrator,
SDAC (except in Japan), StrongBox, SuperVIP, SYN Check, SYNTHESIS, TCP Express, TDR, TechXchange,
TMOS, TotALL, Traffic Management Operating System, Traffix Systems, Traffix Systems (DESIGN), Transparent
Data Reduction, UNITY, VAULT, vCMP, VE F5 [DESIGN], Versafe, Versafe [DESIGN], VIPRION, Virtual Clustered
Multiprocessing, WAF Express, WebSafe, We Make Apps Go [DESIGN], We Make Apps GO, and ZoneRunner, are
trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without
express written consent.
All other product and company names herein may be trademarks of their respective owners.
Patents
This product may be protected by one or more patents. See the F5 Patents page (https://www.f5.com/about/
guidelines-policies/patents).
Notice
THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE, SCRIPTING AND COMMAND EXAMPLES, OR THE USE OR OTHER
DEALINGS WITH THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES.
211
LEGAL NOTICES—Copyright
Publication Date
This document was published in April 2018.
Copyright
Copyright © 2013-2018, F5 Networks®, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no
responsibility for the use of this information, nor any infringement of patents or other rights of third parties which
may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other
intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right
to change specifications at any time without notice.
212
CHANGE LIST—
Change List
Date Chapter/Section Change Reason
August 2015 All Updates to formatting New style
November 2015 All Updates to content BIG-IP 12.x release
All Updates to content BIG-IP 13.x release
Updates to cloud
June 2017 environments are too
BIG-IP VE Chapter removed
varied and frequent to
document in ops guides
Optimizing the Support Remove reference to F5
August 2017 Dropbox use discontinued
Experience Dropbox
Add section on providing
Optimize the Support files to F5 Technical
September 2017 New
Experience Support using F5 Support
Files
Removed interface and
procedures and refer to Changes to BIG-IP iHealth
BIG-IP iHealth
AskF5 documentation for interface
details
Changes to interface. See
Removed Attack Signature
Software Updates BIG-IP ASM Operations
information
Guide.
Remove info on platform_
April 2018 check and platform_diag
Hardware Diagnostics utilities to refer to detailed BIG-IP 13.1.x release
documentation in other
manuals.
Add section on moving BIG-IP 12.1.3.3 release
Licenses and Entitlement
BIG-IP VE licenses and 13.1.x release
Add DNAT 13.1.x algorithm
Modules information to Note on BIG-IP 13.1.x release
page 152.
213

f5 Tmos Operations Guide

Uploaded by

Copyright:

Available Formats

f5 Tmos Operations Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

f5 Tmos Operations Guide

Uploaded by

Copyright:

Available Formats

TMOS Operations Guide

Unified intelligence, flexibility,

Maintenance checklist xiii

Upgrade checklist xiv

Upgrade tasks reporting (BIG-IP 13.x and later) xiv

About This Guide 1

Limits of this guide 1

Feedback and notifications 3

Finding other documents 4

Licenses and Entitlement 57

Backup and Data Recovery 67

Networking and Cluster Health 96

Local Authentication Fallback 100

Troubleshooting enhancements (BIG-IP 13.x and later) 112

Additional resources 114

Log Files and Alerts 115

Additional resources 130

Additional resources 145

Additional resources 147

Additional resources 155

External APIs 156

Additional resources 166

Additional resources 174

Optimizing the Support Experience 176

F5 training programs and education 181

Engage F5 Support 181

Appendix A: Outside the Box 192

Back panel characteristics 195

VIPRION chassis characteristics 196

Appendix B: Deployment and Response Methodologies 199

Appendix C: Support Incident Report 209

Opening a Support Case 210

Legal Notices 211

Publication Date 212

Change List 213

Figure A.1: BIG-IP 5000 series platform front panel 192

Figure A.3: BIG-IP 5000 series platform back panel 195

Figure A.4: BIG-IP 7000 series platform back panel 196

Figure A.5: BIG-IP 10000 series platform back panel 196

Figure A.6: VIPRION 4800 Platform chassis components 197

Figure A.7: VIPRION B4300 blade components 198

Table 1.1 Quick information bar items 6

Table 1.3 Additional iHealth resources 9

Table 2.1 General platform environmental operating specifications 11

Table 2.2 Additional Operational Environment Resources 14

Table 3.1 File types available for EUD download 19

Table 3.2 Possible tasks with downloaded EUD files 21

Table 3.3 Options for running EUD tests 22

Table 3.4 EUD test suite 22

Table 3.5 EUD options 25

Table 3.6 Additional hardware diagnostics resources 26

Table 4.1 LED indicators for chassis standard operating states 29

Table 4.2 LED indicators for blade standard operating states 30

Table 4.3 Additional VIPRION resources 44

Table 5.1 Logging and error conditions 50

Table 5.2 Additional drive maintenance resources 55

Table 6.1 Additional licensing and entitlement resources 66

Table 7.1 Default UCS archive encryption values 74

Table 7.2 Additional backup and data recovery resources 84

Table 8.1 Additional software updates resources 95