BIG-IP® TMOS®: Concepts
Version 11.2
MAN-0378-02
Product Version
This manual applies to version 11.2 of the BIG-IP® product family.
Publication Date
This manual was published on May 7, 2012.
Legal Notices
Copyright
Copyright 2008- 2012, 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.
Trademarks
3DNS, Access Policy Manager, Acopia, Acopia Networks, Advanced Client Authentication, Advanced
Routing, APM, Application Security Manager, ARX, AskF5, ASM, BIG-IP, Cloud Extender,
CloudFucious, CMP, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge
Client, Edge Gateway, Edge Portal, EM, Enterprise Manager, F5, F5 [DESIGN], F5 Management Pack, F5
Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, IBR,
Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iApps, iControl, iHealth,
iQuery, iRules, iRules OnDemand, iSession, IT agility. Your way., L7 Rate Shaping, LC, Link Controller,
Local Traffic Manager, LTM, Message Security Module, MSM, Netcelera, OneConnect, Packet Velocity,
Protocol Security Module, PSM, Real Traffic Policy Builder, ScaleN, SSL Acceleration, StrongBox,
SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System,
TrafficShield, Transparent Data Reduction, VIPRION, vCMP, WA, WAN Optimization Manager,
WANJet, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc.,
in the U.S. and other countries, and may not be used without F5's express written consent.
All other product and company names herein may be trademarks of their respective owners.
Export Regulation Notice
This product may include cryptographic software. Under the Export Administration Act, the United States
government may consider it a criminal offense to export this product from the United States.
RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which
case the user may be required to take adequate measures.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant
to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This unit generates, uses, and
can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential area
is likely to cause harmful interference, in which case the user, at his own expense, will be required to take
whatever measures may be required to correct the interference.
Any modifications to this device, unless expressly approved by the manufacturer, can void the user's
authority to operate this equipment under part 15 of the FCC rules.
BIG-IP® TMOS®: Concepts
i
Canadian Regulatory Compliance
This class A digital apparatus complies with Canadian I CES-003.
Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to
Information Technology products at the time of manufacture.
Acknowledgments
This product includes software developed by Bill Paul.
This product includes software developed by Jonathan Stone.
This product includes software developed by Manuel Bouyer.
This product includes software developed by Paul Richards.
This product includes software developed by the NetBSD Foundation, Inc. and its contributors.
This product includes software developed by the Politecnico di Torino, and its contributors.
This product includes software developed by the Swedish Institute of Computer Science and its
contributors.
This product includes software developed by the University of California, Berkeley and its contributors.
This product includes software developed by the Computer Systems Engineering Group at the Lawrence
Berkeley Laboratory.
This product includes software developed by Christopher G. Demetriou for the NetBSD Project.
This product includes software developed by Adam Glass.
This product includes software developed by Christian E. Hopps.
This product includes software developed by Dean Huxley.
This product includes software developed by John Kohl.
This product includes software developed by Paul Kranenburg.
This product includes software developed by Terrence R. Lambert.
This product includes software developed by Philip A. Nelson.
This product includes software developed by Herb Peyerl.
This product includes software developed by Jochen Pohl for the NetBSD Project.
This product includes software developed by Chris Provenzano.
This product includes software developed by Theo de Raadt.
This product includes software developed by David Muir Sharnoff.
This product includes software developed by SigmaSoft, Th. Lockert.
This product includes software developed for the NetBSD Project by Jason R. Thorpe.
This product includes software developed by Jason R. Thorpe for And Communications,
http://www.and.com.
This product includes software developed for the NetBSD Project by Frank Van der Linden.
This product includes software developed for the NetBSD Project by John M. Vinopal.
This product includes software developed by Christos Zoulas.
This product includes software developed by the University of Vermont and State Agricultural College and
Garrett A. Wollman.
This product includes software developed by Balazs Scheidler (bazsi@balabit.hu), which is protected
under the GNU Public License.
This product includes software developed by Niels Mueller (nisse@lysator.liu.se), which is protected
under the GNU Public License.
In the following statement, This software refers to the Mitsumi CD-ROM driver: This software was
developed by Holger Veit and Brian Moore for use with 386BSD and similar operating systems. Similar
operating systems includes mainly non-profit oriented systems for research and education, including but
not restricted to NetBSD, FreeBSD, Mach (by CMU).
This product includes software developed by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/).
This product includes software licensed from Richard H. Porter under the GNU Library General Public
License (© 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html.
ii
This product includes the standard version of Perl software licensed under the Perl Artistic License (©
1997,
1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current
standard version of Perl at http://www.perl.com.
This product includes software developed by Jared Minch.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/).
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).
This product contains software based on oprofile, which is protected under the GNU Public License.
This product includes RRDtool software developed by Tobi Oetiker (http://www.rrdtool.com/index.html)
and licensed under the GNU General Public License.
This product contains software licensed from Dr. Brian Gladman under the GNU General Public License
(GPL).
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).
This product includes Hypersonic SQL
This product contains software developed by the Regents of the University of California, Sun
Microsystems, Inc., Scriptics Corporation, and others.
This product includes software developed by the Internet Software Consortium.
This product includes software developed by Nominum, Inc. (http://www.nominum.com).
This product contains software developed by Broadcom Corporation, which is protected under the GNU
Public License.
This product contains software developed by MaxMind LLC, and is protected under the GNU Lesser
General Public License, as published by the Free Software Foundation.
This product includes software developed by the Computer Systems Engineering Group at Lawrence
Berkeley Laboratory. Copyright ©1990-1994 Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following
acknowledgement:
This product includes software developed by the Computer Systems Engineering Group at Lawrence
Berkeley Laboratory.
4. Neither the name of the University nor of the Laboratory may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
This product includes software developed by Sony Computer Science Laboratories Inc. Copyright ©
1997-2003 Sony Computer Science Laboratories Inc. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
BIG-IP® TMOS®: Concepts
iii
THIS SOFTWARE IS PROVIDED BY SONY CSL AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL SONY CSL OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
iv
Table of Contents
Table of Contents
1
Introducing the Traffic Management Operating System
What is the BIG-IP system? ..........................................................................................................1-1
What is TMOS? ...............................................................................................................................1-2
Stylistic conventions .......................................................................................................................1-3
Finding help and technical support resources ..........................................................................1-4
2
The BIG-IP System Configuration State
Introduction to the BIG-IP system configuration state ..........................................................2-1
Storage of BIG-IP configuration data .................................................................................2-1
Loading of configuration data ..............................................................................................2-2
Understanding the stored configuration files ...........................................................................2-2
3
Single Configuration Files (SCF)
Introduction to the single configuration file .............................................................................3-1
Summary of tmsh commands to save and load an SCF .........................................................3-2
Creating and saving an SCF .................................................................................................3-2
Replicating configurations using an SCF ...........................................................................3-3
Restoring a BIG-IP system configuration using SCF ......................................................3-3
4
General Configuration Properties
Introduction .....................................................................................................................................4-1
About device properties ..............................................................................................................4-2
General device properties ...................................................................................................4-2
Updates to the IP geolocation database ...........................................................................4-2
About NTP ..............................................................................................................................4-3
Configuring DNS ....................................................................................................................4-3
The hosts file ...........................................................................................................................4-3
About local-traffic properties .......................................................................................................4-4
General local-traffic properties ..........................................................................................4-4
Configuring general local-traffic properties .....................................................................4-4
Configuring persistence properties ...................................................................................4-6
5
SSL Certificates for BIG-IP Devices
Introduction .....................................................................................................................................5-1
Device certificates ..........................................................................................................................5-2
Trusted device certificates ............................................................................................................5-2
6
External File Management
Introduction to external file management ................................................................................6-1
Data group files ...............................................................................................................................6-1
iFiles ....................................................................................................................................................6-3
External monitor program files ...................................................................................................6-4
SSL certificate files ..........................................................................................................................6-5
BIG-IP® TMOS®: Concepts
vii
Table of Contents
7
BIG-IP Platform Properties
Introduction to platform properties ..........................................................................................7-1
General properties .........................................................................................................................7-1
Management port configuration .........................................................................................7-1
The management port ..........................................................................................................7-1
Host name ..............................................................................................................................7-2
Host IP address ......................................................................................................................7-2
Time zone ................................................................................................................................7-2
Redundant device configuration ..................................................................................................7-3
User administration properties ...................................................................................................7-3
Administrative account passwords ....................................................................................7-3
Configuring SSH access ........................................................................................................7-3
8
Fail-Safe and Fast Failover
Introduction .....................................................................................................................................8-1
Understanding fail-safe ...................................................................................................................8-1
Configuring system fail-safe .................................................................................................8-1
Configuring VLAN fail-safe ..................................................................................................8-3
Understanding fast failover ...........................................................................................................8-4
Understanding HA score calculation .................................................................................8-4
9
Archives
Introducing archives .......................................................................................................................9-1
What is an archive? .........................................................................................................................9-1
Working with archives ...................................................................................................................9-2
Saving archives ........................................................................................................................9-2
Restoring archives .................................................................................................................9-3
10
BIG-IP System Services
Managing BIG-IP System Services ............................................................................................. 10-1
Viewing the status of a service ........................................................................................ 10-1
11
SNMP
Introduction to SNMP administration ..................................................................................... 11-1
Reviewing an industry-standard SNMP implementation ............................................ 11-1
Reviewing the BIG-IP system SNMP implementation ................................................ 11-1
Summarizing SNMP configuration on the BIG-IP system .......................................... 11-2
SNMP agent configuration ......................................................................................................... 11-2
Controlling access to SNMP data ................................................................................... 11-3
Working with SNMP MIB files .................................................................................................. 11-4
Overview of F5 enterprise MIB files ........................................................................................ 11-5
Using the F5-BIGIP-COMMON-MIB.txt file ................................................................. 11-5
Using the F5-BIGIP-LOCAL-MIB.txt file ........................................................................ 11-5
Using the F5-BIGIP-SYSTEM-MIB.txt file ....................................................................... 11-6
Using the F5-BIGIP-GLOBAL-MIB.txt ........................................................................... 11-6
Overview of the RMON MIB file ............................................................................................. 11-6
Using the RMON-MIB.txt file .......................................................................................... 11-6
viii
Table of Contents
Collecting performance data ..................................................................................................... 11-7
Collecting data on memory use ...................................................................................... 11-8
Collecting data on active connections ........................................................................... 11-8
Collecting data on new connections .............................................................................. 11-9
Collecting data on throughput rates ............................................................................ 11-10
Collecting data on HTTP requests ............................................................................... 11-12
Collecting data on RAM Cache use .............................................................................. 11-13
Collecting data on CPU use ........................................................................................... 11-15
Collecting data on SSL transactions per second ....................................................... 11-19
12
Administrative Partitions and Folders
About administrative partitions ................................................................................................ 12-1
The partition Common ..................................................................................................... 12-2
The current partition ......................................................................................................... 12-2
Referencing objects in partitions ..................................................................................... 12-3
Partitions and user accounts ............................................................................................ 12-5
Partition summary .............................................................................................................. 12-5
Implementation considerations ....................................................................................... 12-7
About folders ................................................................................................................................ 12-8
13
BIG-IP User Accounts
Introduction to user account management ........................................................................... 13-1
Understanding user account types ................................................................................. 13-1
Understanding administrative partitions ........................................................................ 13-2
Understanding user roles .................................................................................................. 13-4
Managing local user accounts .................................................................................................... 13-7
Configuring the admin account ........................................................................................ 13-8
Configuring a secure password policy ........................................................................... 13-8
User authentication lockout ........................................................................................... 13-11
Configuring local user accounts .................................................................................... 13-11
Managing remote user accounts ............................................................................................. 13-14
Specifying a remote user-account server .................................................................... 13-15
Configuring authorization for remote accounts ........................................................ 13-15
Auditing user access to the system ....................................................................................... 13-19
14
Event Logging
Introducing BIG-IP system logging ........................................................................................... 14-1
Summarizing logging features ........................................................................................... 14-1
Understanding log content ............................................................................................... 14-2
Viewing and filtering log messages .................................................................................. 14-3
Understanding log types ............................................................................................................. 14-5
Logging system events ....................................................................................................... 14-6
Logging packet filter events .............................................................................................. 14-6
Logging local traffic events ................................................................................................ 14-6
Auditing configuration changes ........................................................................................ 14-7
Setting log levels ........................................................................................................................... 14-8
Setting log access ................................................................................................................ 14-8
Setting log levels for local traffic events ........................................................................ 14-8
Setting log levels for auditing events ............................................................................ 14-10
Viewing and searching the audit log ............................................................................. 14-10
BIG-IP® TMOS®: Concepts
ix
Table of Contents
Configuring encrypted remote logging ................................................................................. 14-11
Before you begin ............................................................................................................... 14-11
Creating the remote encrypted logging configuration ............................................. 14-11
Reviewing the SSH syntax required to create this configuration .......................... 14-12
Creating an SSH key to identify and authorize the BIG-IP system ....................... 14-12
Editing the syslog-ng start script to open and close the tunnel ............................. 14-13
Setting up message logging on a remote logging host .............................................. 14-14
Copying the SSH identity to the remote logging host ............................................. 14-15
Verifying the logging configuration and restarting syslog-ng ................................... 14-15
15
Interfaces
Introduction to BIG-IP system interfaces ............................................................................... 15-1
About Link Layer Discovery Protocol .................................................................................... 15-2
Interface properties ..................................................................................................................... 15-3
Understanding interface naming conventions .............................................................. 15-3
Viewing interface information and media properties ................................................. 15-3
Interface mirroring ...................................................................................................................... 15-7
LLDP ............................................................................................................................................... 15-8
General settings .................................................................................................................. 15-8
Neighbor settings ................................................................................................................ 15-9
Interface statistics ...................................................................................................................... 15-10
Related configuration tasks ...................................................................................................... 15-10
16
Self IP Addresses
Introduction to self IP addresses .............................................................................................. 16-1
Types of self IP addresses .......................................................................................................... 16-2
Self IP addresses and MAC addresses ..................................................................................... 16-2
Self IP addresses for SNATs ...................................................................................................... 16-2
Self IP address properties .......................................................................................................... 16-3
17
Traffic Groups
Traffic group overview ............................................................................................................... 17-1
Types of traffic groups ................................................................................................................ 17-1
For more information ................................................................................................................. 17-2
18
Packet Filters
Introduction to packet filtering ................................................................................................. 18-1
Global settings .............................................................................................................................. 18-2
Global properties ................................................................................................................ 18-2
Global exemptions .............................................................................................................. 18-3
Packet filter rules ......................................................................................................................... 18-4
Configuring settings for packet filter rules ................................................................... 18-5
Creating a filter expression .............................................................................................. 18-7
x
Table of Contents
19
Rate Shaping
Introduction to rate shaping ...................................................................................................... 19-1
About rate classes ........................................................................................................................ 19-2
Rate class properties ................................................................................................................... 19-2
Rate class name ................................................................................................................... 19-2
Base rate ............................................................................................................................... 19-3
Ceiling rate ........................................................................................................................... 19-3
Burst size .............................................................................................................................. 19-3
Direction ............................................................................................................................... 19-6
Parent class ........................................................................................................................... 19-6
Shaping policy ....................................................................................................................... 19-7
Queue method .................................................................................................................... 19-7
Drop policy .......................................................................................................................... 19-7
20
Spanning Tree Protocols
Introduction to spanning tree protocols ................................................................................ 20-1
Spanning tree protocol types ........................................................................................... 20-1
Using spanning tree with legacy bridges ........................................................................ 20-3
Configuration overview ..................................................................................................... 20-4
Global spanning tree properties ............................................................................................... 20-5
Spanning tree mode ............................................................................................................ 20-5
Global timers ....................................................................................................................... 20-6
Transmit Hold Count option ........................................................................................... 20-7
MSTP-specific global properties ...................................................................................... 20-7
Management of spanning tree instances ................................................................................. 20-8
Viewing a list of spanning tree instances ....................................................................... 20-8
Creating a spanning tree instance (MSTP-only) ........................................................... 20-8
Viewing and modifying a spanning tree instance ........................................................ 20-12
Deleting a spanning tree instance or its members (MSTP-only) ............................ 20-12
Interfaces for spanning tree ..................................................................................................... 20-12
Configuring spanning tree settings on an interface ................................................... 20-12
Managing interfaces for a specific instance .................................................................. 20-14
21
Trunks
Introduction to trunks ................................................................................................................ 21-1
How do trunks work? ........................................................................................................ 21-1
Overview of LACP ............................................................................................................. 21-2
Trunk properties .......................................................................................................................... 21-2
Trunk name .......................................................................................................................... 21-2
Interfaces for a trunk ......................................................................................................... 21-3
Enabling LACP ..................................................................................................................... 21-3
LACP mode .......................................................................................................................... 21-4
LACP timeout ...................................................................................................................... 21-5
Link selection policy ........................................................................................................... 21-5
Frame distribution hash ..................................................................................................... 21-7
BIG-IP® TMOS®: Concepts
xi
Table of Contents
22
VLANs and VLAN Groups
Introduction to virtual LANs .................................................................................................... 22-1
VLANs on a BIG-IP system ........................................................................................................ 22-2
Understanding the default VLAN configuration .......................................................... 22-2
VLAN groups ................................................................................................................................ 22-9
VLAN group name ............................................................................................................ 22-10
VLAN group ID ................................................................................................................. 22-10
Transparency mode .......................................................................................................... 22-10
Traffic bridging ................................................................................................................... 22-11
Traffic bridging with standby units ................................................................................ 22-11
Host exclusion from proxy ARP forwarding .............................................................. 22-11
VLAN association with a self IP address .............................................................................. 22-12
VLAN assignment to route domains ..................................................................................... 22-12
A
Troubleshooting SNMP Traps
Understanding F5-specific traps ..................................................................................................A-1
General traps .........................................................................................................................A-1
Hardware-related traps .......................................................................................................A-2
License-related traps ............................................................................................................A-3
TMOS-related traps .............................................................................................................A-3
Authentication-related traps ..............................................................................................A-4
DoS-related traps .................................................................................................................A-5
Network-related traps ........................................................................................................A-5
Logging-related traps ............................................................................................................A-6
Application Security Manager-related traps ...................................................................A-7
Global Traffic Manager-related traps ...............................................................................A-7
Other traps ..........................................................................................................................A-10
Glossary
Index
xii
Table of Contents
BIG-IP® TMOS®: Concepts
xiii
1
Introducing the Traffic Management
Operating System
• What is the BIG-IP system?
• What is TMOS?
• Stylistic conventions
• Finding help and technical support resources
Introducing the Traffic Management Operating System
What is the BIG-IP system?
The BIG-IP® system is a set of application delivery products that work
together to ensure high availability, improved performance, application
security, and access control.
One of the primary functions of the BIG-IP system is to direct different
types of protocol and application traffic to an appropriate destination server.
The system accomplishes this through its Local Traffic Manager™ module,
which can forward traffic directly to a load balancing server pool, or send
traffic to a next-hop router, a pool of routers, or directly to a selected node
on the network.
Other modules available on the BIG-IP system provide critical functions
such as applying security policies to network traffic, accelerating HTTP
connections, and optimizing connections across a wide-area network.
Figure 1.1 shows an example of the most basic BIG-IP system
configuration.
Figure 1.1 A basic BIG-IP system configuration
The foundation of the BIG-IP system from a software perspective is the F5
Networks® Traffic Management Operation System® (TMOS®).
BIG-IP® TMOS®: Concepts
1-1
Chapter 1
What is TMOS?
TMOS is a real-time, event-driven operating system designed specifically
for application delivery networking. Through TMOS, you can configure all
of the basic BIG-IP system routing and switching functions, as well as
enhancements such as clusters, user roles, and administrative partitions.
On top of TMOS runs a set of independent modules that you can configure
TMOS is designed to meet the performance, security, availability, and
management needs of applications, as enterprises conduct business through
the Internet. To successfully meet these needs, TMOS features the following
architectural elements:
◆
Proxy architecture
Through the TMOS proxy architecture, the BIG-IP system can inspect
traffic, optimize application performance, and off load downstream
servers.
◆
High-speed performance
TMOS is specifically designed for high performance. For example,
TMOS separates client-side flows from server-side flows for customized
acceleration, and minimizes overhead energy spent on process context
switching and resource allocation.
◆
Modular functionality
Through TMOS, you can readily add features without embarking on
costly network infrastructure upgrades.
After completing the initial configuration, you can configure TMOS to
further customize the system. For example, the most basic system
configuration that results from running the Setup utility includes two virtual
local area networks (VLANs) with one or more BIG-IP system interfaces
(ports) assigned to each VLAN. Using the BIG-IP system’s browser-based
Configuration utility, you can customize this configuration by assigning
additional interfaces to each VLAN or configuring the BIG-IP system to
send traffic for multiple VLANs through the same interface.
A key feature of TMOS is a feature known as device service clustering, or
DSCTM. With DSC, you can configure multiple BIG-IP devices to share
their device properties, synchronize their configuration data at user-defined
levels of granularity, and fail over to one another if an active device in the
device group becomes unavailable. For more information, see these guides:
• BIG-IP® Redundant Systems Configuration Guide
• BIG-IP® TMOS®: Implementations
1-2
Introducing the Traffic Management Operating System
Stylistic conventions
To help you easily identify and understand important information, all of our
documentation uses the stylistic conventions described here.
Using the examples
All examples in this document use only private class IP addresses. When
you set up the configurations we describe, you must use valid IP addresses
suitable to your own network in place of our sample addresses.
Identifying new terms
To help you identify sections where a term is defined, the term itself is
shown in bold italic text. For example, a floating IP address is an IP address
assigned to a VLAN and shared between two computer systems.
Identifying references to objects, names, and commands
We apply bold text to a variety of items to help you easily pick them out of a
block of text. These items include web addresses, IP addresses, utility
names, and portions of commands, such as variables and keywords. For
example, with the tmsh save sys config file <user_filename>
command, you can define a filename to by specifying it for the
<user_filename> variable.
Identifying references to other documents
We use italic text to denote a reference to another document or section of a
document. We use bold, italic text to denote a reference to a book title. For
example, for installation instructions, see the guide titled BIG-IP® Systems:
Getting Started Guide.
Identifying command syntax
We show complete commands in bold Courier text. Note that we do not
include the corresponding screen prompt, unless the command is shown in a
figure that depicts an entire command line screen. For example, to save your
configuration in all partitions, type the following command:
tmsh save sys config partitions all
BIG-IP® TMOS®: Concepts
1-3
Chapter 1
Table 1.1 explains additional special conventions used in command line
syntax.
Item in text
...
Description
\
Indicates that the command continues on the following line, and that users should type the entire
command without typing a line break.
< >
Identifies a user-defined parameter. For example, if the command has <your name>, type in your
name, but do not include the brackets.
|
Separates parts of a command.
[]
Indicates that syntax inside the brackets is optional.
Indicates that you can type a series of items.
Table 1.1 Command line syntax conventions
Finding help and technical support resources
You can find additional technical documentation and product information in
the following locations:
◆
Online help
The Configuration utility has online help for each screen. The online help
contains descriptions of each control and setting on the screen. Click the
Help tab in the left navigation pane to view the online help for a screen.
◆
Welcome screen in the Configuration utility
The Welcome screen in the Configuration utility contains links to many
useful web sites and resources, including:
• The F5 Networks Technical Support web site
• The F5 Solution Center
• The F5 DevCentralSM web site
• Plug-ins, SNMP MIBs, and SSH clients
◆
F5 Networks Technical Support web site
The F5 Networks Technical Support web site, http://support.f5.com,
provides the latest documentation for the product, including:
• Release notes for the BIG-IP system, current and past
• Updates for guides (in PDF form)
• Technical notes
• Answers to frequently asked questions
• The AskF5TM Knowledge Base
1-4
2
The BIG-IP System Configuration State
• Introduction to the BIG-IP system configuration
state
• Understanding the stored configuration files
The BIG-IP System Configuration State
Introduction to the BIG-IP system configuration state
When you perform configuration tasks on the BIG-IP® system, the system
generates underlying configuration data. The system must store this data so
that the data is not lost when an unexpected system event occurs, or you
restart the system. Before the system can store this data, however, the data
must be saved.
More specifically, the BIG-IP system configuration data exists in two
different states: the stored configuration and the running configuration:
• The stored configuration comprises all of the configuration tasks that
you have performed on the system and saved to the system configuration
files.
• The running configuration comprises the stored configuration and all of
the changes that you have made to the system since the last save
operation. The BIG-IP system operates based on the running
configuration.
Storage of BIG-IP configuration data
The way that BIG-IP system configuration data is saved depends on which
tool you are using to configure the system:
◆
Configuration utility
If you are using the browser-based BIG-IP Configuration utility, the
utility automatically saves the configuration data for you as you complete
each configuration task; you do not need to perform any additional steps
to save configuration data. For this reason, this chapter serves primarily
as background information and is not required for you to configure the
system successfully.
◆
tmsh
If you are using this command line tool to configure the system, you
must explicitly issue a save command to store the configuration data you
have generated. Otherwise, the newly-generated configuration data is not
actually stored on the system.
The command tmsh sys save [base-config | config] writes the running
configuration to the stored configuration files. This ensures that recent
configuration changes are retained.
WARNING
If multiple users are making changes to the system, and one user runs the
command sequence tmsh sys save config, the system saves the changes
made by all of the users.
BIG-IP® TMOS®: Concepts
2-1
Chapter 2
Important
Only users assigned the Administrator or Resource Administrator user role
can run the command sequence tmsh sys save config. Users assigned other
roles receive an error when they run these commands.
Loading of configuration data
The command tmsh sys load [base-config | config] resets the running
configuration with the values that are contained in the stored configuration.
Therefore, when you are modifying the system configuration, if you run any
of the load commands before you save your changes to the stored
configuration, the changes are lost. Similarly, if you restart the system
before saving any recent changes, the changes are lost, because restarting
the system utilizes the stored configuration.
Understanding the stored configuration files
The BIG-IP system has numerous stored configuration files. You can make
changes to the BIG-IP system by configuring these files. While some of
these files can actually be configured manually by editing the files directly,
other files require you to use the tmsh command to make changes to the
files.
Note
The objects in these files reside in partition Common. Consequently, the
objects have limited protection by partition access control.
2-2
3
Single Configuration Files (SCF)
• Introduction to the single configuration file
• Summary of tmsh commands to save and load an
SCF
Single Configuration Files (SCF)
Introduction to the single configuration file
A single configuration file (SCF) is a flat, text file that contains a series of
tmsh commands, and the attributes and values of those commands, that
reflect the configuration of the BIG-IP system. Specifically, the SCF
contains the LTM® and TMOS® configurations of the BIG-IP system.
Figure 3.1 shows a small part of a sample SCF.
vlan external {
tag 4093
interfaces 1.3
}
vlan internal {
tag 4094
interfaces 1.10
}
pool dev_https3 {
members {
10.60.10.105:https{}
10.60.10.106:https{}
}
}
Figure 3.1 Portion of a sample SCF
The single configuration file feature allows you to save the configuration of
a BIG-IP® system in a text file. You can then use the text file to easily
replicate the configuration across multiple BIG-IP systems. This not only
saves you time, but also allows you to create a consistent, secure,
comprehensive local traffic management environment on your network.
BIG-IP® TMOS®: Concepts
3-1
Chapter 3
Summary of tmsh commands to save and load an SCF
You use the tmsh utility to perform the basic management of a single
configuration file (SCF). Table 3.1 contains an overview of the commands
to accomplish this. For information about the additional parameters for each
command, see the Traffic Management Shell (tmsh) Reference Guide.
tmsh command
Usage
save /sys config file
[filename] tar-file
[filename]
Use this command to save a copy of the currently running configuration to an SCF.
load sys config file
[filename] tar-file
[filename]
Use this command to replace or restore an SCF with a saved configuration.
load sys config
default
Use this command to restore the factory default settings of the configuration file, while
retaining the management IP address and the administrator user name and password.
It is important to note that saving a configuration to an SCF does not affect the running
configuration or the stored configuration of the BIG-IP system upon which you run the
command.
When you use this command, the system saves any previously running configuration to
/var/local/scf/, by default.
Table 3.1 Overview of the tmsh commands used to manage an SCF
More detailed information about how these commands are used to manage
an SCF is provided in the following sections.
Creating and saving an SCF
When you use the tmsh command save /sys config file [filename] tar-file
[filename] to create an SCF, the command prompts the tmsh utility to
gather all of the commands (and their attributes and values) that compose
the running configuration. Once gathered, the system saves the
configuration to a flat file with the name you specify and the extension of
.scf. By default, the system stores this file in the /var/local/scf directory, but
you can specify a different path if you prefer.
Note that when you use the save command to create an SCF, you include the
name of a tar file as well.
For example, the following command saves the running configuration to the
specified file, my_config.scf, and saves all user-provided disk files referred
to by the configuration into my_config.tar:
tmsh save /sys config file my_config.scf tar-file my_config.tar
3-2
Single Configuration Files (SCF)
When you load the configuration later, you system uses the tar file. For
more information, see Restoring a BIG-IP system configuration using SCF,
on page 3-3.
Note
A tar file contains objects such as trusted device certificates, device
certificates, device keys, CRLs, external data group files, external monitor
program files, iFiles, and so on.
Note
If you include the .scf extension in the file name, the system does not add
additional extension.
Tip
If you create an SCF file twice (on two different occasions), you can
compare the contents of the two files.
Replicating configurations using an SCF
The primary benefit of the SCF feature is that it gives you the ability to
create a configuration on one BIG-IP system that you can load onto other
BIG-IP systems (hereafter referred to as the target BIG-IP system), rather
than having to recreate the configuration multiple times.
After you have created and saved the SCF using the save sys config file
[filename] command, you can modify any data unique to the specific target
BIG-IP system, then load the configuration on that system.
Important
To successfully load a configuration you have replicated, no line of the
configuration can be longer than 4096 characters. If there are more than
4096 characters in a single line, the system reverts to the previous running
configuration.
Restoring a BIG-IP system configuration using SCF
The BIG-IP system ships with a default SCF. Depending on whether you
want to restore the factory default configuration or load a specific
configuration, use one of the following commands.
◆
BIG-IP® TMOS®: Concepts
tmsh load /sys config default
This command restores a system to the factory default configuration,
while retaining the management IP and the assigned root and
administrator passwords. When you use this command, the system first
3-3
Chapter 3
saves the running configuration in the backup.scf file and then resets the
local traffic management and the operating system configuration to the
factory default settings by loading the SCF, /defaults/defaults.scf.
◆
tmsh load /sys config file [filename] tar-file [filename]
This command restores the configuration of a system with values defined
in the specified SCF and tar files. When you use this command, the
system first saves the running configuration in the backup.scf file, and
then resets the running configuration to the values contained in the
specified SCF and tar files.
For example, the following command replaces the running configuration
with the configuration stored in the file my_config.scf and retrieves the disk
files referred to in the configuration from the file my_config.tar:
tmsh load /sys config file my_config.scf tar-file my_config.tar
You must run the command save /sys config partitions all to save the
running configuration in the stored configuration files.
3-4
4
General Configuration Properties
• Introduction
• About device properties
• About local-traffic properties
General Configuration Properties
Introduction
Part of managing the BIG-IP® system involves configuring and maintaining
a set of global system properties. These properties allow you to configure:
• General device features, such as NTP and DNS
• General local traffic features, including some global persistence settings
• General global traffic features, including load balancing and metric
collection
When you configure general device properties, you are affecting the
operation of the BIG-IP system as a whole, rather than just one aspect of it.
Similarly, when you configure the general properties related to local traffic
or global traffic, you are globally affecting the operation of the local traffic
management and global traffic management systems.
BIG-IP® TMOS®: Concepts
4-1
Chapter 4
About device properties
The BIG-IP system includes some general properties that you can configure,
as well as properties related to Network Time Protocol (NTP), Domain
Name System (DNS), and host names on the network.
To manage these properties, log in to the BIG-IP Configuration utility, and
on the Main tab, expand System, and click Configuration.
General device properties
The BIG-IP system general device properties that you can view or configure
are:
• The host name
• The BIG-IP software version number
• The number of CPUs available
• The number of CPUs that are active
You can also perform operations such as reboot or force the system into an
OFFLINE state.
The BIG-IP system general device properties that you can configure are:
• Network boot
• Quiet boot
You can also reload the default geolocation data files that the BIG-IP system
uses to source the origin of a name resolution request.
Updates to the IP geolocation database
The BIG-IP system uses an IP geolocation database to determine 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. The default database also
provides geolocation data for IPv6 addresses at the continent and country
levels.
Note
You can access the ISP and organization-level geolocation data for IPv4
and IPv6 addresses using the iRules® whereis command.
Tip
If you require geolocation data at the city-level, contact your F5 Networks
sales representative to purchase additional database files.
4-2
General Configuration Properties
You can download a monthly update to the IP geolocation database from F5
Networks.
About NTP
Network Time Protocol (NTP) is a protocol that synchronizes the clocks on
a network. You can use the Configuration utility to specify a list of IP
addresses of the servers that you want the BIG-IP system to use when
updating the time on network systems. You can also edit or delete the entries
in the server list.
Configuring DNS
Domain Name System (DNS) is an industry-standard distributed internet
directory service that resolves domain names to IP addresses. If you plan to
use DNS in your network, you can use the Configuration utility to configure
DNS for the BIG-IP system.
When you configure DNS, you create two lists: a DNS lookup server list,
and a BIND forwarder server list. The DNS lookup server list allows
BIG-IP system users to use IP addresses, host names, or fully-qualified
domain names (FQDNs) to access virtual servers, nodes, or other network
objects.
The BIND forwarder server list provides DNS resolution for servers and
other equipment load balanced by the BIG-IP system, that is, for the servers
that the BIG-IP system uses for DNS proxy services.
Note
To use DNS Proxy services, you must enable the named service.
The hosts file
You can create and manage a list of IP addresses and their associated host
names, to identify and locate hosts on the network.
BIG-IP® TMOS®: Concepts
4-3
Chapter 4
About local-traffic properties
The BIG-IP system includes a set of properties that apply globally to the
local traffic management system. These properties fall into two main
categories: general local-traffic properties, and persistence properties. You
can use the Configuration utility to configure and maintain these properties.
General local-traffic properties
You can configure a number of properties that affect the general behavior of
the BIG-IP local traffic management system. In most cases, these properties
are not directly related to any one type of local traffic management object,
such as a virtual server or a load balancing pool.
Configuring general local-traffic properties
Table 4.1 lists and describes the properties that you can configure to manage
the behavior of the local traffic management system.
Property
Description
Default Value
Auto Last Hop
Specifies, when checked (enabled), that the system
automatically maps the last hop for pools.
Enabled (checked)
Maintenance Mode
Specifies, when checked (enabled), that the unit is in
maintenance mode. In maintenance mode, the system stops
accepting new connections and slowly completes the
processing of existing connections.
Disabled
(unchecked)
VLAN-Keyed Connections
Check this setting to enable VLAN-keyed connections.
VLAN-keyed connections are used when traffic for the same
connection must pass through the system several times, on
multiple pairs of VLANs (or in different VLAN groups).
Enabled (checked)
Path MTU Discovery
Specifies, when checked (enabled), that the system discovers
the maximum transmission unit (MTU) that it can send over a
path without fragmenting TCP packets.
Enabled (checked)
Reject Unmatched Packets
Specifies that the BIG-IP system sends a TCP RST packet in
response to a non-SYN packet that matches a virtual server
address and port or self IP address and port, but does not
match an established connection. The BIG-IP system also
sends a TCP RST packet in response to a packet matching a
virtual server address or self IP address but specifying an
invalid port. The TCP RST packet is sent on the client-side of
the connection, and the source IP address of the reset is the
relevant BIG-IP LTM object address or self IP address for
which the packet was destined. If you disable this setting, the
system silently drops unmatched packets.
Enabled (checked)
Table 4.1 General properties for globally managing local traffic
4-4
General Configuration Properties
Property
Description
Default Value
Maximum Node Idle Time
Specifies the number of seconds a node can be left idle by the
Fastest load balancing mode. The system sends fewer
connections to a node that is responding slowly, and
periodically recalculates the response time of the slow node.
0 (disabled)
Reaper High-water Mark
Specifies, in percent, the memory usage at which the system
silently purges stale connections, without sending reset
packets (RST) to the client. If the memory usage remains
above the low-water mark after the purge, then the system
starts purging established connections closest to their service
timeout. To disable the adaptive reaper, set the high-water
mark to 100.
95
Reaper Low-water Mark
Specifies, in percent, the memory usage at which the system
starts establishing new connections. Once the system meets
the reaper high-water mark, the system does not establish new
connections until the memory usage drops below the reaper
low-water mark. To disable the adaptive reaper, set the
low-water mark to 100.
85
Note: This setting helps to mitigate the effects of a
denial-of-service attack.
SYN CheckTM Activation
Threshold
Specifies the number of new or untrusted TCP connections
that can be established before the system activates the SYN
Cookies authentication method for subsequent TCP
connections.
16384
Layer 2 Cache Aging Time
Specifies, in seconds, the amount of time that records remain
in the Layer 2 forwarding table, when the MAC address of the
record is no longer detected on the network.
300
Share Single MAC Address
Specifies, when checked (enabled), that all VLANs share a
single MAC address. If you use the default value (unchecked),
the BIG-IP gives each VLAN the MAC address of the VLAN’s
lowest-numbered interface. Use this setting when configuring
an active/standby redundant system.
Disabled
(unchecked)
SNAT Packet Forwarding
Specifies the type of traffic for which the system attempts to
forward (instead of reject) Any-IP packets, when the traffic
originates from a member of a SNAT. There are two possible
values:
TCP and UDP Only
TCP and UDP Only: Specifies that the system forwards, for
TCP and UDP traffic only, Any-IP packets originating from a
SNAT member.
All Traffic: Specifies that the system forwards, for all traffic
types, Any-IP packets originating from a SNAT member.
Table 4.1 General properties for globally managing local traffic
BIG-IP® TMOS®: Concepts
4-5
Chapter 4
Configuring persistence properties
Using the Configuration utility, you can perform certain persistence-related
tasks such as managing the way that destination IP addresses are stored in
the persistence table, and specifying a data group that contains proxy IP
addresses.
Table 4.2, on page 4-6, lists and describes the properties that you can
configure to manage general persistence-related properties.
Property
Description
Default Value
Management of Destination
Address Entries
Specifies how the system manages the destination IP address
entries in the persistence table. Note that when either the
timeout value or the maximum number of persistence entries is
reached, the BIG-IP system no longer adds destination
address entries to the persistence table. To ensure that the
BIG-IP system can always add entries to the persistence table,
either increase the timeout value in the Destination Address
Affinity persistence profile, or increase the maximum number
of entries allowed.
Timeout
Timeout: Specifies that entries remain in the persistence table
until the BIG-IP system times them out, based on the timeout
value configured in the corresponding persistence profile.
Maximum Entries: Specifies that the system stops adding
entries to the persistence table when the number of entries
reaches the value specified in the Maximum Entries setting,
following.
Maximum Entries
Specifies the maximum entries allowed in the persistence table
before the BIG-IP system stops adding entries. Note that you
can increase this value with no significant impact to the
amount of memory consumed.
2048
Proxy Address Data Group
Specifies the data group that contains proxy IP addresses.
You use this data group to identify the addresses that are to be
treated as proxies when you enable the Map Proxies option
on a persistence profile.
aol
Table 4.2 General properties for controlling session persistence
4-6
5
SSL Certificates for BIG-IP Devices
• Introduction
• Device certificates
• Trusted device certificates
SSL Certificates for BIG-IP Devices
Introduction
In some cases, BIG-IP® systems need to exchange device certificates, that
is, Secure Sockets Layer (SSL) certificates and keys used to verify each
others’ credentials before exchanging data. For example, multiple BIG-IP
systems might need to verify credentials before communicating with each
other to collect performance data over a wide area network, for global traffic
management.
Note
If you are using the device service clustering feature (DSCTM), see the
BIG-IP® Redundant Systems Configuration Guide. If you are using SSL
certificates to terminate and initiate local SSL traffic, see the guides
BIG-IP® Local Traffic Manager™: Concepts and BIG-IP® Local Traffic
Manager™: Implementations.
To perform mutual authentication, BIG-IP systems can use either
self-signed certificates or CA-signed certificates:
◆
Self-signed certificates
When you install BIG-IP software, the application includes a self-signed
SSL certificate. A self-signed certificate is an authentication mechanism
that is created and authenticated by the system on which it resides.
◆
CA-signed certificates
If your network includes one or more certificate authority (CA) servers,
you can replace the self-signed certificate on each BIG-IP system with a
CA-signed certificate, that is, a certificate that is signed by a third party.
Authenticating BIG-IP systems using CA-signed certificates is more
secure than using self-signed certificates.
BIG-IP systems on the network uses self-signed or CA-signed certificates
for these reasons:
BIG-IP® TMOS®: Concepts
◆
To request authentication
A BIG-IP system can send a certificate to another (target) BIG-IP system
to request authentication by that target BIG-IP system. In this context,
the certificate is referred to as a device certificate.
◆
To grant authentication
A BIG-IP system can store one or more certificates that it trusts, to check
when receiving a device certificate from another BIG-IP system during a
request for authentication.
5-1
Chapter 5
Device certificates
When requesting SSL authentication from another system, the BIG-IP
system need to present its device certificate. On the BIG-IP system, a device
certificate is an SSL certificate that a BIG-IP system presents to another
device on the network, for authentication purposes. A device certificate can
be either a self-signed certificate or a CA-signed certificate.
Using the Configuration utility, you can view, import, renew, or export a
device certificate.
You can also import or export a device key. The properties of a device key
are:
• Key type (such as KTYPE_RSA_PRIVATE)
• Key size (such as 1024 bits)
• Security type, either Normal or FIPS (FIPS-enabled systems only)
Trusted device certificates
The BIG-IP system uses a trusted device certificate or a certificate chain to
authenticate another system. For example, a BIG-IP system running Global
Traffic ManagerTM system might send a request to a Local Traffic
ManagerTM system. In this case, the Local Traffic Manager system receiving
the request checks its trusted device certificate or certificate chain in its
attempt to authenticate the request.
The SSL protocol supports ten levels of authentication:
◆
Level 0
Certificates are verified by the system to which they belong. These types
of certificates are also known as self-signed certificates.
◆
Level 1
Certificates are authenticated by a Certificate Authority server that is
separate from the system.
◆
Levels 2 through 9
Certificates are authenticated by additional CA servers, which verify the
authenticity of other servers. These multiple levels of authentication are
referred to as certificate chains, and allow for a tiered verification
system that ensures that only authorized communications occur between
servers.
To configure multi-level certificate authentication, you must:
• Import on to each BIG-IP system the trusted device certificates that are
necessary to authenticate communications with other BIG-IP systems.
• Specify the depth of the certificate chain that the BIG-IP system must
traverse.
5-2
SSL Certificates for BIG-IP Devices
You can view, import, or export a trusted device certificate or certificate
chain.
To manage device certificates, log in to the BIG-IP Configuration utility,
and on the Main tab, expand System, and click Device Certificates.
BIG-IP® TMOS®: Concepts
5-3
Chapter 5
5-4
6
External File Management
• Introduction to external file management
• Data group files
• iFiles
• External monitor program files
• SSL certificate files
External File Management
Introduction to external file management
You can import certain external files for use by iRules®, or you can import
or create SSL certificates. The external files that iRules can use can be data
group files and iFiles. Using the BIG-IP Configuration utility, you can
manage these external files or SSL certificates from a central location.
To use this feature, log in to the BIG-IP Configuration utility, and on the
Main tab, expand System, and click File Management.
Data group files
Using the BIG-IP Configuration utility, you can import an existing file from
another system to the BIG-IP system with content that you want to reference
in an iRule.
There are three possible types of data group files: address, integer, and
string.
Figure 6.1 shows an example of an address data group. This example shows
host and network entries that have or lack corresponding values.
class addr_testclass {
{
host 192.168.1.1
host 192.168.1.2 { "host 2" }
network 192.168.2.0/24
network 192.168.3.0/24 { "network 2" }
}
}
Figure 6.1 Example of an address data group
Figure 6.2 shows an example of an integer data group. This example shows
integer entries that have corresponding values.
class int_testclass {
{
1 { "test 1" }
2 { "test 2" }
}
}
Figure 6.2 Example of an integer data group
BIG-IP® TMOS®: Concepts
6-1
Chapter 6
Figure 6.3 shows an example of a string data group. This example shows
string entries that have or lack corresponding values.
class str_testclass {
{
"str1" { "value 1" }
"str2" { "value 2" }
}
}
Figure 6.3 Example of a string data group
To use this feature, you first import an existing file to the BIG-IP system
and then assign a new name to the file. To import a file and assign it a new
name, log in to the BIG-IP Configuration utility, and on the Main tab,
expand System, and click File Management.
The imported file has these attributes:
File Properties
Description
Type
The type of file contents. Possible types are address, string,
or integer.
Size
The size, in bytes, of the imported.
Version
The version of the imported file.
Referenced
An indicator of whether the file references another file.
Last Update Date
The time that the file was created.
Created By
The name of the user account that created the file.
Partition / Path
The path name to the administrative partition on the BIG-IP
system in which the file resides.
Table 6.1 External data group file attributes and their descriptions
After importing the file, you use the Local Traffic area of the Configuration
utility to create a new data group based on the imported file. You can then
reference the new data group from within an iRule. For more information,
see the guide titled BIG-IP® Local Traffic ManagerTM: Concepts.
6-2
External File Management
iFiles
Using the BIG-IP Configuration utility, you can import an existing file or
URL from another system to the BIG-IP system, with content that you want
an iRule to return to a client based on some iRule event.
To use this feature, you first import an existing file or URL to the BIG-IP
system and then assign a new name to the file. To import a file with the
Configuration utility and assign it a new name, you use the System area of
the navigation pane. This imported file has these attributes:
File Properties
Description
Size
The size, in bytes, of the iFile.
Version
The version of the iFile.
Referenced
An indicator of whether the iFile references another file.
Created
The time that the iFile was created.
Created By
The name of the user account that created the iFile.
Partition / Path
The path name to the administrative partition on the BIG-IP
system in which the iFile resides.
Table 6.2 External file attributes and their descriptions
Note
The maximum allowed size of a file that you import is 4MB.
Next, you associate the newly-named imported file with an iFile, which is a
file you create for referencing within an iRule. For more information, see
the guide titled BIG-IP® Local Traffic ManagerTM: Concepts.
BIG-IP® TMOS®: Concepts
6-3
Chapter 6
External monitor program files
Using the BIG-IP Configuration utility, you can import an existing external
program monitor file to the BIG-IP system, with content that an external
monitor can reference.
To use this feature, you first import an existing file from another system to
the BIG-IP system and then assign a new name to the file. To import a file
and assign it a new name, log in to the BIG-IP Configuration Utility®, and
on the Main tab, expand System, and click File Management.
The imported file has these attributes:
File Properties
Description
Size
The size, in bytes, of the imported.
Version
The version of the imported file.
Referenced
An indicator of whether the external monitor references the
external monitor program file.
Last Update Date
The time that the file was created.
Created By
The name of the user account that created the file.
Partition / Path
The path name to the administrative partition on the BIG-IP
system in which the file resides.
Table 6.3 External monitor program file attributes and their descriptions
After importing the file, you use the Local Traffic area of the Configuration
utility to create a new external monitor program based on the imported file.
For more information, see the guide titled BIG-IP® Local Traffic
ManagerTM: Concepts.
6-4
External File Management
SSL certificate files
Using the BIG-IP Configuration utility, you can import an existing
certificate file from another system to the BIG-IP system, or you can create
a new SSL certificate. To import or create an SSL certificate, log in to the
BIG-IP Configuration utility, and on the Main tab, expand System, and
click File Management.
An imported certificate file has these attributes:
• Contents
• Common Name
• Organization
• Expiration date
• Partition / Path
Using the Configuration utility, you can view, import, renew, or export a
device certificate.
You can also import or export a device key. The properties of a device key
are:
• Key type (such as KTYPE_RSA_PRIVATE)
• Key size (such as 1024 bits)
• Security type, either Normal or FIPS (FIPS-enabled systems only)
There are several types of files that you can import using the File
Management screens of the BIG-IP Configuration utility. These file types
are:
• Key files
• Certificate files
• PKCS 12 (IIS) files
• Archive files
• Certificate Revocation List (CRL) files
Note
Do not attempt to manage certificates by copying SSL certificate files into
the /config/ssl/* directory and then reloading the system configuration.
Certificate-related files are not stored in that location. Therefore, you must
use the BIG-IP Configuration utility or tmsh to manage certificate files, key
files, and CRL files.
BIG-IP® TMOS®: Concepts
6-5
Chapter 6
6-6
7
BIG-IP Platform Properties
• Introduction to platform properties
• General properties
• Redundant device configuration
• User administration properties
BIG-IP Platform Properties
Introduction to platform properties
Part of managing a BIG-IP® system involves configuring and maintaining a
certain set of system properties. These properties consist of general platform
properties such as the BIG-IP system host name, IP address, and passwords
for its system administrative accounts.
To manage these properties, log in to the BIG-IP Configuration utility, and
on the Main tab, expand System, and click Platform.
General properties
You can configure these general properties for the BIG-IP system platform:
• An IP address, netmask, and route for the management port
• The host name for the BIG-IP system
• The host IP address for the BIG-IP system
• The time zone in which the BIG-IP system operates
Management port configuration
To assign an IP address to the management port, you can either use the
Dynamic Host Configuration Protocol (DHCP), or you can specify an IP
address manually, using the BIG-IP Configuration utility.
The management port
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. You cannot use the management port for normal
traffic that is slated for load balancing. Instead, the BIG-IP system uses the
TMM switch interfaces for that type of traffic. TMM switch interfaces are
those interfaces controlled by the Traffic Management Microkernel (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 that 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.
Note
The IP address for the management port must be in IPv4 format.
BIG-IP® TMOS®: Concepts
7-1
Chapter 7
Host name
Every BIG-IP system must have a host name that is a fully qualified domain
name. An example of a host name is mybigip.win.net.
Host IP address
Every BIG-IP system must have a host IP address. This IP address can be
the same as the address that you used for the management port, or you can
assign a unique address. The default value is Use Management Port IP
Address.
Time zone
Another of the general platform properties that you can specify is the time
zone. The many time zones that you can choose from are grouped into these
categories: Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia,
Europe, Indian, and Pacific. You should specify the time zone that most
closely represents the location of the BIG-IP system you are configuring.
7-2
BIG-IP Platform Properties
Redundant device configuration
A BIG-IP system is typically part of a device group that synchronizes
configuration data across two or more BIG-IP devices and provides high
availability (failover and connection mirroring).
To ensure that this operates successfully, you assign a device group, to the
root folder, to which you want to synchronize configuration data. All
folders and sub-folders in the folder hierarchy inherit this device group as a
folder attribute.
You also assign a floating traffic group to the root folder. All folders and
sub-folders in the folder hierarchy inherit this traffic group as a folder
attribute.
For detailed information on redundant system configuration, see the
BIG-IP® Redundant Systems Configuration Guide.
User administration properties
Part of managing platform-related properties is maintaining passwords for
the system account. You can also configure the system to allow certain IP
addresses to access the BIG-IP system through SSH.
Administrative account passwords
When you ran the Setup utility on the BIG-IP system, you set up some
administrative accounts. Specifically, you set up the root and admin
accounts. The root and admin accounts are for use by BIG-IP system
administrators.
Users logging in with the root account have terminal and browser access to
the BIG-IP system. By default, users logging in with the admin account
have browser-only access to the BIG-IP system. You can use the General
screen of the platform properties to change the passwords for root and
admin accounts on a regular basis. To change a password, locate the Root
Account or Admin Account setting, and in the Password box, type a new
password. In the Confirm box, re-type the same password.
Configuring SSH access
When you configure SSH access, you enable user access to the BIG-IP
system through SSH. Also, only the IP addresses that you specify are
allowed access to the system using SSH.
To configure SSH access, locate the SSH Access setting and click the
Enabled box. Then use the SSH IP Allow setting to select either * All
Addresses or Specify Range, which allows you to specify a range of
addresses for which access is allowed.
BIG-IP® TMOS®: Concepts
7-3
Chapter 7
7-4
8
Fail-Safe and Fast Failover
• Introduction
• Understanding fail-safe
• Understanding fast failover
Fail-Safe and Fast Failover
Introduction
Two features of high availability are fail-safe and HA groups. The
remainder of this chapter describes these features.
Important
For information on implementing configuration synchronization, failover,
and connection mirroring, see the BIG-IP® Redundant Systems
Configuration Guide and BIG-IP® TMOS®: Implementations.
Understanding fail-safe
Fail-safe is the ability of a BIG-IP® system to monitor certain aspects of the
system or network, detect interruptions, and consequently take some action.
More specifically:
• In the case of a redundant system, a device can detect a problem with a
service or VLAN, and initiate failover to a peer device.
• In the case of a single device (non-redundant system), the system can
detect a problem with a service or VLAN, and take some action, such as
restarting the service.
The BIG-IP system offers these types of fail-safe:
◆
System fail-safe
Monitors the switch board component and a set of key system services.
◆
VLAN fail-safe
Monitors traffic on a VLAN.
Note
Only users with either the Administrator or Resource Administrator user
role can configure fail-safe.
To configure and manage fail-safe, log in to the BIG-IP Configuration
utility, and on the Main tab, expand System, and click High Availability.
Configuring system fail-safe
When you configure system fail-safe, the BIG-IP system monitors various
hardware components, as well as the heartbeat of various system services,
and can take action if the system detects a heartbeat failure.
BIG-IP® TMOS®: Concepts
8-1
Chapter 8
Configuring hardware-component monitoring
You can configure the BIG-IP system to monitor the switch board
component and then take some action if the BIG-IP system detects a failure.
Using the Configuration utility, you can specify the action that you want the
BIG-IP system to take when the component fails. Possible actions that the
BIG-IP system can take are:
• Reboot the BIG-IP system.
• Restart all system services.
• Go offline.
• Go offline and abort the TMM service.
• Fail Over and Restart TM.
Configuring system-service monitoring
You can specify the particular action that you want the BIG-IP system to
take when the heartbeat of a system service fails. The following table lists
each system service, and shows the possible actions that the BIG-IP system
can take in the event of a heartbeat failure.
System Service
Possible actions
BIGD
Restart the system service.
Restart all system services.
MCPD
GTMD
Reboot the BIG-IP system.
Go offline.
Go offline and abort the TMM service.
TMROUTED
(Single device only)
Take no action.
BCM56XXD
Restart
No action
TMM
Go offline and down links and restart.
Restart the system service.
Restart all system services.
Reboot the BIG-IP system.
Go offline.
Go offline and restart.
SOD
Reboot the system.
Restart all system services.
Take no action.
CBRD
Restart the system service.
Take no action.
Table 8.1 Possible actions in response to heartbeat failure
8-2
Fail-Safe and Fast Failover
System Service
Possible actions
SCRIPTD
Restart the system service.
Restart all system services.
Reboot the BIG-IP system.
Go offline.
Go offline and restart.
Take no action.
DEDUP_ADMIN
Restart the system service.
Take no action.
Table 8.1 Possible actions in response to heartbeat failure
Configuring VLAN fail-safe
For maximum reliability, the BIG-IP system supports failure detection on all
VLANs. When you configure the fail-safe option on a VLAN, the BIG-IP
system monitors network traffic going through that VLAN. If the BIG-IP
system detects a loss of traffic on the VLAN and the fail-safe timeout period
has elapsed, the BIG-IP system attempts to generate traffic by issuing ARP
requests to nodes accessible through the VLAN. The BIG-IP system also
generates an ARP request for the default route, if the default router is
accessible from the VLAN. Failover is averted if the BIG-IP system is able
to send and receive any traffic on the VLAN, including a response to its
ARP request.
For a redundant system configuration, if the BIG-IP system does not receive
traffic on the VLAN before the timeout period expires, the system can
initiate failover and switch control to the standby device, reboot, or restart
all system services. The default action is Reboot.
For a single device, the system can either reboot or restart all system
services. The default action is Reboot.
WARNING
You should configure the fail-safe option on a VLAN only after the BIG-IP
system is in a stable production environment. Otherwise, routine network
changes might cause failover unnecessarily.
Each interface card installed on the BIG-IP system is typically mapped to a
different VLAN. Thus, when you set the fail-safe option on a particular
VLAN, you need to know the interface to which the VLAN is mapped. You
can use the Configuration utility to view VLAN names and their associated
interfaces.
There are two ways to configure VLAN fail-safe: from the Redundancy
Properties screen, or from the VLANs screen.
BIG-IP® TMOS®: Concepts
8-3
Chapter 8
Understanding fast failover
The BIG-IP system includes a feature known as fast failover. Fast failover
is a feature that is based on the concept of an HA group. An HA group is a
set of trunks, pools, or clusters (or any combination of these) that you want
the BIG-IP system to use to calculate an overall health score for a device in
a redundant system configuration. A health score is based on the number of
members that are currently available for any trunks, pools, and clusters in
the HA group, combined with a weight that you assign to each trunk, pool,
and cluster. The device that has the best overall score at any given time
becomes or remains the active device.
To configure and manage fast failover, log in to the BIG-IP Configuration
utility, and on the Main tab, expand System, and click High Availability.
Note
To use the fast failover feature, you must first create a redundant system
configuration.
The fast failover feature is designed for a redundant configuration that
contains a maximum of two devices in a device group.
Note
Only VIPRION® systems can have a cluster as an object in an HA group.
For all other platforms, HA group members consist of pools and trunks
only.
An HA group is typically configured to fail over based on trunk health in
particular. Trunk configurations are not synchronized between units, which
means that the number of trunk members on the two units often differs
whenever a trunk loses or gains members. The HA group feature allows
failover to occur based on changes to trunk health instead of on system or
VLAN failure.
Only one HA group can exist on the BIG-IP system. By default, the HA
group feature is disabled.
To summarize, when you configure the HA group, the process of one
BIG-IP device failing over to the other based on HA scores is noticeably
faster than if failover occurs due to a hardware or daemon failure.
Understanding HA score calculation
The BIG-IP system calculates an HA score based on these criteria:
• The number of available members for each object (such as a trunk)
• The weight that you assign to each object in the HA group
• The threshold you specify for each object (optional)
• The active bonus value that you specify for the HA group
8-4
Fail-Safe and Fast Failover
Specifying a weight
A weight is a health value that you assign to each object in the HA group
(that is, pool, trunk, and cluster). The weight that you assign to each object
must be in the range of 10 through 100. The maximum overall score that the
BIG-IP system can potentially calculate for a device is the sum of the
individual weights for the HA group objects, plus the active bonus value.
(For information on the Active Bonus setting, see Specifying an active
bonus, on page 8-6.)
Table 8.2, on page 8-5 shows an example of how the system calculates a
score for the device, based solely on the weight of objects in the HA group.
In this example, the HA group contains two pools (my_http_pool and
my_ftp_pool) and one trunk (my_trunk1). A user has assigned a weight to
each object.
Available
Members
User-assigned
Weight
Object Name
Members
HA Score
my_http_pool
8
5 (62.5%)
50
31
(60% x 50)
my_ftp_pool
6
6 (100%)
20
20
(100% x 20)
my_trunk1
4
3 (75%)
30
23
(75% x 30)
Total device score = 74
Table 8.2 Example of an HA score calculation for a device
On each device, the system uses each weight, along with a percentage that
the system derives for each object (the percentage of the object’s members
that are available), to calculate a score for each object.
The system then adds the scores to determine a total score for the device.
The device with the highest score becomes or remains the active device in
the redundant system configuration.
Note that if you have configured VLAN fail-safe, and the VLAN fails on an
active device, the device goes offline regardless of its score, and its peer
becomes active.
Specifying a threshold
For each object in an HA group, you can specify an optional setting known
as a threshold. A threshold is a value that specifies the number of object
members that must be available to prevent failover. If the number of
available members dips below the threshold, the BIG-IP system assigns a
score of 0 to the object, so that the score of that object no longer contributes
to the overall score of the device.
BIG-IP® TMOS®: Concepts
8-5
Chapter 8
For example, if a trunk in the HA group has four members and you specify a
threshold value of 3, and the number of available trunk members falls to 2,
then the trunk contributes a score of 0 to the total device score.
If the number of available object members equals or exceeds the threshold
value, or you do not specify a threshold, the BIG-IP system calculates the
score as described previously, by multiplying the percentage of available
object members by the weight for each object and then adding the scores to
determine the overall device score.
Tip
Do not configure the tmsh attribute min-up-members on any pool that you
intend to include in the HA group.
Specifying an active bonus
An active bonus is an amount that the BIG-IP system automatically adds to
the overall score of the active device. An active bonus ensures that the active
device remains active when the device’s score would otherwise temporarily
fall below the score of the standby device.
A common reason to specify an active bonus is to prevent failover due to
flapping, the condition where failover occurs frequently as a trunk member
toggles between availability and unavailability. In this case, you might want
to prevent the HA scoring feature from triggering failover each time a trunk
member is lost. You might also want to prevent the HA scoring feature from
triggering failover when you make minor changes to the BIG-IP system
configuration, such as adding or removing a trunk member.
Suppose that the HA group on each device contains a trunk with four
members, and you assign a weight of 30 to each trunk. Without an active
bonus defined, if the trunk on device 1 loses some number of members,
failover occurs because the overall calculated score for device 1 becomes
lower than that of device 2. Table 8.3 shows the scores that could result if
the trunk on device 1 loses one trunk member and no active bonus is
specified.
Event
Members Available
Trunk score
Device Score
Failover?
Device 1
Device 2
Device
1
Device
2
Device
1
Device
2
Device 1 is active (initial state)
4 (100%)
4 (100%)
30
30
30
30
No
Device 1 loses a trunk member
3 (75%)
4 (100%)
30
23
30
Yes
23
(75% of 30)
Table 8.3 Failover when no active bonus is specified
8-6
(100% of 30)
Fail-Safe and Fast Failover
You can prevent this failover from occur i ng by specifying an active bonus
value. In our example, if we specify an active bonus of 10 (the default
value), the score of the active device changes from 23 to 33, thereby
ensuring that the score of the active device remains equal to or higher than
that of the standby device (30).
Although you specify an active bonus value on each device, the BIG-IP
system uses the active bonus specified on the active device only, to
contribute to the score of the active device. The BIG-IP system never uses
the active bonus on the standby device to contribute to the score of the
standby device.
Important
An exception to this behavior is when the active device score is 0. If the
score of the active device is 0, the system does not add the active bonus to
the active device score.
To decide on an active bonus value, calculate the trunk score for some
number of failed members (such as one of four members), and then specify
an active bonus that results in a trunk score that is greater than or equal to
the weight that you assigned to the trunk.
For example, if you assigned a weight of 30 to the trunk, and one of the four
trunk members fails, the trunk score becomes 23 (75% of 30), putting the
device at risk for failover. However, if you specified an active bonus of 7 or
higher, failover would not actually occur, because a score of 7 or higher,
when added to the score of 23, is greater than or equal to 30.
For the procedure on specifying an active bonus, see 6 Device 1 regains two
trunk member Device 2 remains the active device even when one trunk
member is unavailable, due to the active bonus., on page 8-9.
Example
You can prevent failover from occur i ng by specifying an active bonus
value. Table 8.4, on page 8-8, and the list that follows, show how
configuring an active bonus for the active device can affect failover.
BIG-IP® TMOS®: Concepts
8-7
Chapter 8
Event
Trunk Members
Available
Device 1
1
2
3
4
5
6
Device 2
Device 1 is
active
(initial
state)
4 (100%) 4 (100%)
Device 1
loses a
trunk
member
3 (75%)
Device 1
loses
another
trunk
member
2 (50%)
Device 1
goes to
standby.
Device 2
goes
active.
2 (50%)
4 (100%)
Device Score
Trunk Score
Device 1
Device 2
Device
1
30
30
10
(100% of 30)
(100% of 30)
23
(75% of 30)
4 (100%)
15
(50% of 30)
4 (100%)
15
(50% of 30)
Device 2
loses a
trunk
member
2 (50%)
Device 1
regains two
trunk
members
4 (100%)
3 (75%)
15
(50% of 30)
3 (75%)
Active Bonus
30
(100% of 30)
30
Device
2
(Trunk Score +
Active Bonus)
Fail
over?
Device
1
Device
2
0
40
30
No
10
0
33
30
No
10
0
25
30
Yes
0
10
15
40
N/A
0
10
15
33
No
0
10
30
33
No
(100% of 30)
30
(100% of 30)
30
(100% of 30)
23
(75% of 30)
23
(75% of 30)
Table 8.4 Example of configuring an active bonus to prevent failover
To help understand Table 8.4, the row numbers in the left column of the
table correspond to the explanations below:
8-8
1
Device 1 is active (initial state)
With all trunk members available on both units, and the active bonus
configured, the active device (device 1) retains the higher device score
and therefore remains active.
2
Device 1 loses a trunk member
The device score for device 1 is still higher than the score for device 2,
due to an active bonus value of 10.
Fail-Safe and Fast Failover
BIG-IP® TMOS®: Concepts
3
Device 1 loses another trunk member
With an active bonus of 10, failover occurs when 50% of the members
are lost.
4
Device 1 switches to standby mode and device 2 becomes active
Once the active device (device 1) has failed over to device 2, the active
bonus on device 1 no longer applies, thus reducing its score from 25 to
15. The active bonus on device 2 is then applied, increasing device 2’s
score from 30 to 40.
5
Device 2 loses a trunk member
If the active device (device 2) loses a trunk member, the score on device
2 is still higher than device 1 (with two unavailable members), due to
the active bonus.
6
Device 1 regains two trunk member
Device 2 remains the active device even when one trunk member is
unavailable, due to the active bonus.
8-9
Chapter 8
8 - 10
9
Archives
• Introducing archives
• What is an archive?
• Working with archives
Archives
Introducing archives
On any BIG-IP® system, you have a set of data that you created when you
initially configured the system, using the Setup utility and the Configuration
utility or tmsh. This data consists of traffic management elements such as
virtual servers, pools, and profiles. Configuration data also consists of
system and network definitions such as interface properties, self IP
addresses, VLANs, and more.
Once you have created the configuration data for the BIG-IP system, you
can replicate all of this set of data in a separate file. You can then use this
replicated data later, for these reasons:
◆
As an archive for disaster recovery
Using the Archives feature, you can back up the current configuration
data, and if necessary, restore the data at a later time. We highly
recommend that you use this feature to mitigate the potential loss of
BIG-IP system configuration data. To create an archive, you can use the
Configuration utility, which stores the configuration data in a special file
known as a user configuration set, or UCS file. You can then use the
UCS file to recover from any loss of data, in the unlikely event that you
need to do so. For more information about creating and managing
archives, see the remainder of this chapter.
◆
As a way to propagate data to other systems
Using the single configuration file feature, you can easily and quickly
propagate the exact configuration of the BIG-IP system to other BIG-IP
systems. To create a single configuration file, you export the
configuration data to a special file known as an .scf file. You can then
use the .scf file to configure another system in one simple operation. For
details about using a single configuration file, see Chapter 3, Single
Configuration Files (SCF).
To configure and manage archives, log in to the BIG-IP Configuration
utility, and on the Main tab, expand System, and click Archives.
What is an archive?
Before you replace a version of the BIG-IP system with a newer version,
you should always create an archive, which is a backup copy of the
configuration data. This archive is in the form of a user configuration set,
or UCS. Then, if you need to recover that data later, you can restore the data
from the archive that you created.
A UCS contains the following types of BIG-IP system configuration data:
• System-specific configuration files
• Product licenses
• User accounts and password information
• Domain Name Service (DNS) zone files
BIG-IP® TMOS®: Concepts
9-1
Chapter 9
• Installed SSL keys and certificates
Each time you back up the configuration data, the BIG-IP system creates a
new file with a .ucs extension. Each UCS file contains various configuration
files needed for the BIG-IP system to operate correctly, as well as the
configuration data.
Important
To create, delete, upload, or download an archive, you must have either the
Administrator or Resource Administrator role assigned to your user
account.
Working with archives
Using the Configuration utility, you can save and restore archives that are
stored on the BIG-IP system. Furthermore, for added security, you can save
archives to and restore archives from a remote system, that is, the system on
which you are running the Configuration utility.
Saving archives
By default, the system stores all archives in the directory /var/local/ucs.
You can specify a different location, but in this case, the Configuration
utility does not display the UCS files when you view the list of archives
After you create an archive on the BIG-IP system, you can download a copy
of the UCS file to the system from which you are running the Configuration
utility (a secure remote system). This provides an extra level of protection
by preserving the configuration data on a remote system. In the unlikely
event that you need to restore the data, and a BIG-IP system event prevents
you from accessing the archive in the BIG-IP system directory in which you
saved the archive, you still have a backup copy of the data.
Important
Any UCS file that you create includes the host name of the BIG-IP system as
part of the data stored in that file. When you later specify this UCS file
during the process of restoring configuration data to a BIG-IP system, the
host name stored in this UCS file must match the host name of the system to
which you are restoring the configuration data. Otherwise, the system does
not fully restore the data.
Important
If your configuration data includes SSL keys and certificates, be sure to
store the archive file in a secure environment.
9-2
Archives
Restoring archives
Not only is the /var/local/ucs directory the only location on the BIG-IP
system in which you can save an archive, but it is also the only location on
the BIG-IP system from which you can restore an archive. However, if you
previously downloaded an archive to a remote system, and a BIG-IP system
event prevents you from accessing the /var/local/ucs directory, you can
upload the archive from that remote system.
BIG-IP® TMOS®: Concepts
9-3
Chapter 9
9-4
10
BIG-IP System Services
• Managing BIG-IP System Services
BIG-IP System Services
Managing BIG-IP System Services
The BIG-IP® system includes a number of services that you can start, stop,
or restart using the Configuration utility. This ability to start or stop services
from within the Configuration utility is useful when you want to run only
those services that you need to successfully manage network traffic.
The Configuration utility screen for managing services lists the name of
each service and its current status. At a minimum, the services that you can
stop or start with the Configuration utility are:
◆
ntpd
Sets and maintains the system time of day.
◆
snmpd
Receives and processes SNMP requests, and sends trap notifications.
Note that you must stop this service before updating the SNMP v3 file
/config/net-snmp/snmpd.conf, which specifies SNMP user names.
◆
sshd
Provides secure remote login between untrusted hosts.
If you have other BIG-IP product modules running on the BIG-IP system,
such as Global Traffic Manager™, you might see other services listed on the
Services screen.
Important
You must have either the Administrator or Resource Administrator user
role assigned to your user account to stop, start, or restart a service.
To configure and manage system services, log in to the BIG-IP
Configuration utility, and on the Main tab, expand System and click
Services.
Viewing the status of a service
When you view the list of services available on the BIG-IP system, you can
also view current status. In the Configuration utility, you can see this status
in the History column. Examples of status for a service are: Running for 6
days, Running, and down, not configured.
BIG-IP® TMOS®: Concepts
10 - 1
Chapter 10
10 - 2
11
SNMP
• Introduction to SNMP administration
• SNMP agent configuration
• Working with SNMP MIB files
• Overview of F5 enterprise MIB files
• Overview of the RMON MIB file
• Collecting performance data
SNMP
Introduction to SNMP administration
Simple Network Management Protocol (SNMP) is an industry-standard
protocol that gives a standard SNMP management system the ability to
remotely manage a device on the network. One of the devices that an SNMP
management system can manage is a BIG-IP® system. The SNMP versions
that the BIG-IP system supports are: SNMP v1, SNMP v2c, and SNMP v3.
The BIG-IP system implementation of SNMP is based on a well-known
SNMP package, Net-SNMP, which was formerly known as UCD-SNMP.
To configure and manage SNMP, log in to the BIG-IP Configuration utility,
and on the Main tab, expand Network, and click SNMP.
Reviewing an industry-standard SNMP implementation
A standard SNMP implementation consists of an SNMP manager, which
runs on a management system and makes requests to a device, and an
SNMP agent, which runs on the managed device and fulfills those requests.
SNMP device management is based on the standard management
information base (MIB) known as MIB-II, as well as object IDs and MIB
files.
• The MIB defines the standard objects that you can manage for a device,
presenting those objects in a hierarchical, tree structure.
• Each object defined in the MIB has a unique object ID (OID), written as
a series of integers. An OID indicates the location of the object within
the MIB tree.
• A set of MIB files resides on both the SNMP manager system and the
managed device. MIB files specify values for the data objects defined in
the MIB. This set of MIB files consists of standard SNMP MIB files and
enterprise MIB files. Enterprise MIB files are those MIB files that
pertain to a particular company, such as F5 Networks®, Inc.
Typical SNMP tasks that an SNMP manager performs include polling for
data about a device, receiving notifications from a device about specific
events, and modifying writable object data.
Reviewing the BIG-IP system SNMP implementation
To comply with the standard SNMP implementation, the BIG-IP system
includes both an SNMP agent, a set of standard SNMP MIB files, and a set
of enterprise MIB files (those that are specific to the BIG-IP system). The
enterprise MIB files typically reside on both the BIG-IP system and system
running the SNMP manager. Fortunately, you can use the browser-based
Configuration utility to download the enterprise MIB files to your SNMP
manager.
BIG-IP® TMOS®: Concepts
11 - 1
Chapter 11
Using the BIG-IP system implementation of SNMP, the SNMP manager can
perform these distinct functions:
• Poll for information (such as performance metrics)
• Receive notification of specific events that occur on the BIG-IP system
• Set data for SNMP objects that have a read/write access type
Summarizing SNMP configuration on the BIG-IP system
Before you can use an SNMP manager system to manage a BIG-IP system
remotely, you must perform the following procedures on the BIG-IP system,
using the BIG-IP® Configuration utility.
◆
Configuring the SNMP agent
There are a number of ways to configure the SNMP agent on the BIG-IP
system. For example, you can allow client access to information that the
SNMP agent collects, and you can configure the way that the SNMP
agent handles SNMP traps. (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.)
◆
Downloading MIB files
You can download two sets of MIB files to your remote manager system:
the standard SNMP MIB files and the enterprise MIB files.
Note
An alternate way to configure SNMP is to use tmsh. For more information,
see the Traffic Management Shell (tmsh) Reference Guide.
SNMP agent configuration
You configure the SNMP agent by performing the following tasks:
11 - 2
◆
Configuring BIG-IP system information
Specify a system contact name and the location of the BIG-IP system.
◆
Configuring client access to the SNMP agent
Configure the BIG-IP system to allow access to the SNMP agent from an
SNMP manager system.
◆
Controlling access to SNMP data
Assign access levels to SNMP communities or users, to control access to
SNMP data.
SNMP
◆
Configuring traps
Enable or disable traps and specify the destination SNMP manager
system for SNMP traps.
Note
Only users with either the Administrator or Resource Administrator user
role can configure SNMP on the BIG-IP system.
Controlling access to SNMP data
To better control access to SNMP data, you can assign an access level to an
SNMP v1 or v2c community, or to an SNMP v3 user.
There is a default access level for communities, and this access level is
read-only. This means that you cannot write to an individual data object that
has a read/write access type until you change the default read-only access
level of the community or user.
When you set the access level of a community or user to read/write, and an
individual data object has a read-only access type, access to the object
remains read-only. In short, the access level or type that is the most secure
takes precedence when there is a conflict. Table 11.1 illustrates this point.
If the access type of an
object is...
And you set the access
level of a community or
user to...
Then access to the
object is...
Read-only
Read-only
Read/write
Read-only
Read-only
Read-only
Read/write
Read/write
Read-only
Read/write
Table 11.1 Access control for SNMP data
BIG-IP® TMOS®: Concepts
11 - 3
Chapter 11
Working with SNMP MIB files
There are two sets of MIB files that typically reside on the BIG-IP system
and the SNMP manager system: enterprise MIB files (that is, F5®-specific
MIB files) and standard SNMP MIB files.
Both sets of MIB files are present on the BIG-IP system, in the directory
/usr/share/snmp/mibs. However, you still need to download them to your
SNMP manager system. You can download these MIB files from the
Welcome screen of the browser-based Configuration utility.
The implementation of the Packet Velocity® ASIC (PVA) feature affects the
ability for users to use MIB-II to gather certain kinds of data. For example,
with a PVA system, you can use MIB-II to collect statistics on physical
system interfaces, but not on logical interfaces (that is, VLANs).
The BIG-IP system uses MIB-II for gathering standard Linux data only.
You cannot use MIB-II to gather data that is specific to the BIG-IP system
and instead must use the F5 enterprise MIB files. All OIDS for BIG-IP
system data are contained in the F5 enterprise MIB files, including all
interface statistics (1.3.6.1.4.1.3375.2.1.2.4 (sysNetwork.sysInterfaces)).
If you want to use SNMP to monitor a specific process on the BIG-IP
system, you can use the HOST-RESOURCES MIB and then write a script to
monitor that process. Then, for example, to determine the number of TMM
processes currently running on the system, you can use a command such as
the following:
snmpwalk -v2c -c public localhost hrSWRunName | egrep
"\"tmm(.[0-9]+)?\"" | wc -l
Note
All BIG-IP system statistics are defined by 64-bit counters. Thus, because
only SNMP v2c supports 64-bit counters, your management system needs to
use SNMP v2c to query BIG-IP system statistics data.
11 - 4
SNMP
Overview of F5 enterprise MIB files
The F5 enterprise MIB files contain information that you can use for your
remote management station to: poll the SNMP agent for BIG-IP
system-specific information, receive BIG-IP system-specific notifications,
or set BIG-IP system data.
To perform remote management, download the following F5 enterprise MIB
files to the SNMP manager system:
• F5-BIGIP-COMMON-MIB.txt
• F5-BIGIP-LOCAL-MIB.txt
• F5-BIGIP-SYSTEM-MIB.txt
• F5-BIGIP-GLOBAL-MIB.txt
Once you have downloaded all of the necessary MIB files, you should
familiarize yourself with the contents of the enterprise MIBs, for purposes
of managing the BIG-IP system and troubleshooting BIG-IP system events.
Note
To manage a BIG-IP system with SNMP, you need to use the standard set of
SNMP commands. For information about SNMP commands, consult your
favorite third-party SNMP documentation, or visit the web site
http://net-snmp.sourceforge.net.
Using the F5-BIGIP-COMMON-MIB.txt file
The F5-BIGIP-COMMON-MIB.txt file contains objects pertaining to any
common information, as well as all F5-specific notifications (SNMP traps).
This MIB file specifies and defines objects for which all other BIG-IP MIB
files reference. You can identify the traps within this MIB file by viewing
the file and finding object names that show the designation
NOTIFICATION-TYPE.
When an F5-specific trap sends a notification to the SNMP manager system,
the SNMP manager system receives a text message describing the event or
problem that has occurred. For troubleshooting assistance regarding
F5-specific traps, see Appendix A, Troubleshooting SNMP Traps.
Using the F5-BIGIP-LOCAL-MIB.txt file
The F5-BIGIP-LOCAL-MIB.txt file contains information about the
properties associated with any local traffic management object (virtual
servers, pools, nodes, profiles, SNATs, health monitors, and iRules®). An
SNMP manager system can access and use this information to help you
manage local application traffic.
For example, you can:
BIG-IP® TMOS®: Concepts
11 - 5
Chapter 11
• View the maximum number of entries that a node can have open at any
given time.
• Get a pool name.
• View the current active members for a load balancing pool.
• Reset pool statistics
• Get profile information such as the total number of concurrent
authentication sessions.
You can also reset statistics for any of these objects.
Using the F5-BIGIP-SYSTEM-MIB.txt file
The F5-BIGIP-SYSTEM-MIB.txt file describes objects representing
common BIG-IP system information. Examples of information in this MIB
file are global statistic data, network information, and platform information.
Some of the data in this MIB file is similar to that defined in MIB-II, but is
not exactly the same.
Using the F5-BIGIP-GLOBAL-MIB.txt
The F5-BIGIP-GLOBAL-MIB.txt file contains information that an SNMP
manager system can use to help manage global application traffic objects,
such as wide IPs, virtual servers, pools, links, servers, and data centers. You
can reset statistics for any of these objects.
Overview of the RMON MIB file
In addition to the F5 enterprise MIB files, the BIG-IP system also provides
the remote network monitoring (RMON) MIB file, RMON-MIB.txt.
Using the RMON-MIB.txt file
The implementation of RMON on the BIG-IP system differs slightly from
the standard RMON implementation, in the following ways:
• The BIG-IP system implementation of RMON supports four of the nine
RMON groups. The four supported RMON groups are: statistics, history,
alarms, and events.
• The RMON-MIB.txt file monitors the BIG-IP system interfaces (that is,
sysIfIndex), and not the standard Linux interfaces.
• For hardware reasons, the packet-length-specific statistics in the RMON
statistics group offer combined transmission and receiving statistics only.
This behavior differs from the behavior described in the definitions of the
corresponding object IDs.
11 - 6
SNMP
Collecting performance data
The Configuration utility on the BIG-IP system displays graphs showing
performance metrics for the system. However, you can also use SNMP to
collect the same information.
The types of performance metrics that you can gather using SNMP are:
• Memory use
• Number of active connections
• Number of new connections
• Throughput in bits per second
• Number of HTTP requests
• RAM Cache use
• CPU use
• Number of SSL transactions
Each type of metric has one or more SNMP object IDs (OIDs) associated
with it. To gather performance data, you specify these OIDs with the
appropriate SNMP command.
For example, the following SNMP command collects data on current
memory use, where public is the community name and bigip is the host
name of the BIG-IP system:
snmpget -c public bigip sysGlobalStat.sysStatMemoryUsed.0
For some types of metrics, such as memory use, simply issuing an SNMP
command with an OID gives you the information you need. For other types
of metrics, the data that you collect with SNMP is not useful until you
perform a calculation on it to interpret the data.
For example, to determine the throughput rate of client bits coming into the
BIG-IP system, you must you must use the relevant OID
(sysStatClientBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.3)) to take two polls at a
certain interval (such as ten seconds), calculate the delta of the two polls,
and then perform the following calculation on that delta value:
( <DeltaStatClientBytesIn>*8 ) / <interval>
Important
For calculations that include a polling interval, the interval can be any
amount of time that you choose, as long as you use that same number as the
value for <interval> in your calculations. Note that the performance graphs
that the Configuration utility displays are based on a polling interval of ten
seconds.
BIG-IP® TMOS®: Concepts
11 - 7
Chapter 11
The following sections contain tables that list:
• The OIDs that you can use to collect the performance data
• The calculations that you must perform to interpret the performance data
that you collect (not required for interpreting data on memory use and
active connections).
Collecting data on memory use
You can use an SNMP command with OIDs to gather data on the number of
bytes of memory currently being used on the BIG-IP system. Table 11.2
shows the OIDs that you need to specify to gather data on current memory
use. To interpret data on memory use, you do not need to perform a
calculation on the collected data.
Performance Graph
(Configuration utility)
Graph Metric
Required SNMP OIDs
Memory Used
TMM Mem Usage
sysStatMemoryUsed (.1.3.6.1.4.1.3375.2.1.1.2.1.45)
Host Mem Usage
sysHostMemoryUsed (.1.3.6.1.4.1.3375.2.1.7.1.2)
Table 11.2 Required OIDs for collecting metrics on memory use
Collecting data on active connections
You can use SNMP commands with various OIDs to gather data on the
number of active connections on the BIG-IP system. Table 11.3 shows the
OIDs that you need to specify to gather data on active connections. To
interpret data on active connections, you do not need to perform any
calculations on the collected data.
Performance Graph
(Configuration utility)
Active Connections
(summary graph)
Active Connections
(detailed graph)
Graph Metrics
Required SNMP OIDs
Connections
sysStatClientCurConns (.1.3.6.1.4.1.3375.2.1.1.2.1.8)
client
sysStatClientCurConns (.1.3.6.1.4.1.3375.2.1.1.2.1.8)
server
sysStatServerCurConns (.1.3.6.1.4.1.3375.2.1.1.2.1.15)
pva client
sysStatPvaClientCurConns (.1.3.6.1.4.1.3375.2.1.1.2.1.22)
pva server
sysStatPvaServerCurConns (.1.3.6.1.4.1.3375.2.1.1.2.1.29)
ssl client
sysClientsslStatCurConns (.1.3.6.1.4.1.3375.2.1.1.2.9.2)
ssl server
sysServersslStatCurConns (.1.3.6.1.4.1.3375.2.1.1.2.10.2)
Table 11.3 Required OIDs for collecting metrics on active connections
11 - 8
SNMP
Collecting data on new connections
You can use SNMP commands with various OIDs to gather and interpret
data on the number of new connections on the BIG-IP system.
To gather and interpret the data for each of these metrics, you must perform
some polling and calculations:
• First, for each OID, you must perform two separate polls, at a time
interval of your choice.
• Next, you calculate the delta of the two poll values.
• Finally, for each graph metric, you perform a calculation on those OID
deltas.
Table 11.4 shows the individual OIDS that you must poll to retrieve two
separate poll values for each OID.
Performance Graph
(Configuration utility)
New Connections
(summary graph)
Total New Connections
(detailed graph)
New PVA Connections
(detailed graph)
New Client SSL Profile
Connections
(detailed graph)
New Accepts/Connects
(detailed graph)
Graph Metrics
Required SNMP OIDs
Client Accepts
sysTcpStatAccepts (.1.3.6.1.4.1.3375.2.1.1.2.12.6)
Server Connects
sysStatServerTotConns (.1.3.6.1.4.1.3375.2.1.1.2.1.14)
Client Connects
sysStatClientTotConns (.1.3.6.1.4.1.3375.2.1.1.2.1.7)
Server Connects
sysStatServerTotConns (.1.3.6.1.4.1.3375.2.1.1.2.1.14)
pva client
sysStatPvaClientTotConns (.1.3.6.1.4.1.3375.2.1.1.2.1.21)
pva server
sysStatPvaServerTotConns (.1.3.6.1.4.1.3375.2.1.1.2.1.28)
SSL Client
sysClientsslStatTotNativeConns (.1.3.6.1.4.1.3375.2.1.1.2.9.6)
sysClientsslStatTotCompatConns (.1.3.6.1.4.1.3375.2.1.1.2.9.9)
SSL Server
sysServersslStatTotNativeConns (.1.3.6.1.4.1.3375.2.1.1.2.10.6)
sysServersslStatTotCompatConns (.1.3.6.1.4.1.3375.2.1.1.2.10.9)
Client Accepts
sysTcpStatAccepts (.1.3.6.1.4.1.3375.2.1.1.2.12.6)
Server Connects
sysTcpStatConnects (.1.3.6.1.4.1.3375.2.1.1.2.12.8)
Table 11.4 Required OIDs for polling for data on new connections
For example, the following steps show how to collect data for the Client
Accepts graph metric:
1. Poll OID sysTcpStatAccepts (.1.3.6.1.4.1.3375.2.1.1.2.12.6) twice,
at a 10-second interval.
This results in two values, <sysTcpStatAccepts1> and
<sysTcpStatAccepts2>.
Note: Although this example uses an interval of ten seconds, the
interval can actually be any duration that you choose.
BIG-IP® TMOS®: Concepts
11 - 9
Chapter 11
2. Calculate the delta of the two poll values:
<DeltaTcpStatAccepts> = <sysTcpStatAccepts2> <sysTcpStatAccepts1>
3. Calculate the value of the Client Accepts graph metric using the
calculation shown in Table 11.5 (<DeltaTcpStatAccepts> /
<interval>), where the value of <interval> is 10.
Performance Graph
(Configuration utility)
New Connections
(summary graph)
Total New Connections
(detailed graph)
New PVA Connections
(detailed graph)
New SSL Connections
(detailed graph)
New Accepts/Connects
(detailed graph)
Graph Metrics
Required calculations for new connection metrics
Client Accepts
<DeltaTcpStatAccept> / <interval>
Server Connects
<DeltaStatServerTotConns> / <interval>
Client Connects
<DeltaStatClientTotConns> / <interval>
Server Connects
<DeltaStatServerTotConns> / <interval>
pva client
<DeltaStatPvaClientTotConns> / <interval>
pva server
<DeltaStatPvaServerTotConns> / <interval>
SSL Client
( <DeltaClientsslStatTotNativeConns> +
<DeltaClientsslStatTotCompatConns>) / <interval>
SSL Server
(<DeltaServersslStatTotNativeConns> +
<DeltaServersslStatTotCompatConns>) / <interval>
Client Accepts
<DeltaTcpStatAccepts> / <interval>
Server Connects
<DeltaTcpStatConnects> / <interval>
Table 11.5 Required calculations for interpreting metrics on new connections
Collecting data on throughput rates
You can use SNMP commands with various OIDs to gather and interpret
data on the throughput rate on the BIG-IP system, in terms of bits per
second.
To gather and interpret the data for each of these metrics, you must perform
some polling and calculations:
• First, for each OID, you must perform two separate polls, at an interval
of your choice.
• Next, you calculate the delta of the two poll values.
• Finally, for each graph metric, you perform a calculation on those OID
deltas.
11 - 10
SNMP
Table 11.6 shows the individual OIDS that you must poll, retrieving two
separate poll values for each OID.
Performance Graph
(Configuration utility)
Graph Metrics
Required SNMP OIDs
Client Bits
sysStatClientBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.3)
sysStatClientBytesOut (.1.3.6.1.4.1.3375.2.1.1.2.1.5)
Server Bits
sysStatServerBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.10)
sysStatServerBytesOut (.1.3.6.1.4.1.3375.2.1.1.2.1.12)
Client Bits In
sysStatClientBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.3)
Client Bits Out
sysStatClientBytesOut (.1.3.6.1.4.1.3375.2.1.1.2.1.5)
Server-side
Throughput
(detailed graph)
Server Bits In
sysStatServerBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.10)
Server Bits Out
sysStatServerBytesOut (.1.3.6.1.4.1.3375.2.1.1.2.1.12)
HTTP Compression
Rate
(detailed graph)
Compression
sysHttpStatPrecompresssBytes (.3375.2.1.1.2.4.21)
Throughput
(summary graph)
Client-side Throughput
(detailed graph)
Table 11.6 Required OIDs for polling for data on throughput rates
For example, the following steps show how to collect data on throughput
rates for the Server Bits In graph metric:
1. Poll OID sysStatServerBytesIn (.1.3.6.1.4.1.3375.2.1.1.2.1.10)
twice, at a 10-second interval.
This results in two values, <sysStatServerBytesIn1> and
<sysStatServerBytesIn2>.
Note: Although this example uses an interval of ten seconds, the
interval can actually be any duration that you choose.
2. Calculate the delta of the two poll values:
<DeltaStatServerBytesIn> = <sysStatServerBytesIn2> <sysStatServerBytesIn1>
3. Calculate the value of the Server Bits In graph metric using the
calculation shown in Table 11.7, on page 11-12
(<DeltaStatServerBytesIn> / <interval>), where the value of
<interval> is 10.
BIG-IP® TMOS®: Concepts
11 - 11
Chapter 11
Performance Graph
(Configuration utility)
Graph Metrics
Required calculations for throughput rates
Client Bits
( (<DeltaStatClientBytesIn> + <DeltasysStatClientBytesOut> )*8 ) /
<interval>
Server Bits
( (<DeltaStatServerBytesIn> + <DeltasysStatServerBytesOut> )*8 ) /
<interval>
Compression
( <DeltaHttpStatPrecompressBytes>*8 ) / <interval>
Client Bits In
( <DeltaStatClientBytesIn>*8 ) / <interval>
Client Bits Out
( <DeltaStatClientBytesOut>*8 ) / <interval>
Server Bits In
( <DeltaStatServerBytesIn>*8 ) / <interval>
Server Bits Out
( <DeltaStatServerBytesOut>*8 ) / <interval>
Compression
( <DeltaHttpStatPrecompressBytes>*8 ) / <interval>
Throughput
(summary graph)
Throughput
(detailed graph)
Table 11.7 Required calculations for interpreting metrics on throughput rates
Collecting data on HTTP requests
You can use SNMP commands with an OID to gather and interpret data on
the number of current HTTP requests on the BIG-IP system, in terms of
requests per second.
To gather and interpret the data for this metric, you must perform some
polling and calculations:
• First, you must use the OID to perform two separate polls, at an interval
of your choice.
• Next, you calculate the delta of the two poll values.
• Finally, you perform a calculation on the OID delta.
Table 11.8 shows the OID that you must poll, retrieving two separate poll
values for this OID.
Performance Graph
(Configuration utility)
Graph Metric
Required SNMP OIDs
HTTP Requests
HTTP Requests
sysStatHttpRequests (.1.3.6.1.4.1.3375.2.1.1.2.1.56)
Table 11.8 Required OIDs for polling for data on HTTP requests
11 - 12
SNMP
For example, to collect data on HTTP requests for the HTTP Requests
graph metric, follow these steps.
1. Poll OID sysStatHttpRequests (.1.3.6.1.4.1.3375.2.1.1.2.1.56)
twice, at a 10-second interval.
This results in two values, <sysStatHttpRequests1> and
<sysStatHttpRequests2>.
Note: Although this example uses an interval of ten seconds, the
interval can actually be any duration that you choose.
2. Calculate the delta of the two poll values:
<DeltaStatHttpRequests> = <sysStatHttpRequests2> <sysStatHttpRequests1>
3. Calculate the value of the HTTP Requests graph metric using the
calculation shown in Table 11.9, where the value of <interval> is
10.
Performance Graph
(Configuration utility)
Graph Metric
Required calculations for HTTP requests
HTTP Requests
HTTP Requests
<DeltaStatHttpRequests> / <interval>
Table 11.9 Required calculations for interpreting metrics on HTTP requests
Collecting data on RAM Cache use
You can use an SNMP command with various OIDs to gather and interpret
data on RAM cache use.
To gather and interpret the data for each of these metrics, you must perform
some polling and calculations:
• First, for each OID, you must poll for data.
• Then, for each graph metric, you perform a calculation using the OID
data.
BIG-IP® TMOS®: Concepts
11 - 13
Chapter 11
Table 11.10 shows the individual OIDS that you must use to poll for RAM
Cache data.
Performance Graph
(Configuration utility)
RAM Cache Utilization
Graph Metric
Required SNMP OID
Hit Rate
sysHttpStatRamcacheHits (.1.3.6.1.4.1.3375.2.1.1.2.4.46)
sysHttpStatRamcacheMisses (.1.3.6.1.4.1.3375.2.1.1.2.4.47)
Byte Rate
sysHttpStatRamcacheHitBytes (.1.3.6.1.4.1.3375.2.1.1.2.4.49)
sysHttpStatRamcacheMissBytes (.1.3.6.1.4.1.3375.2.1.1.2.4.50)
Eviction Rate
sysHttpStatRamcacheEvictions (.1.3.6.1.4.1.3375.2.1.1.2.4.54)
sysHttpStatRamcacheHits (.1.3.6.1.4.1.3375.2.1.1.2.4.46)
sysHttpStatRamcacheMisses (.1.3.6.1.4.1.3375.2.1.1.2.4.47)
Table 11.10 Required OIDs for polling for data on RAM Cache use
For example, the following steps show how to collect data on RAM Cache
use for the Hit Rate graph metric:
1. Poll the OID sysHttpStatRamcacheHits
(.1.3.6.1.4.1.3375.2.1.1.2.4.46). This results in a value of
<sysHttpStatRamcacheHits1>.
2. Poll the OID sysHttpStatRamcacheMisses
(.1.3.6.1.4.1.3375.2.1.1.2.4.47). This results in a value of
<sysHttpStatRamcacheMisses1>.
3. Calculate the value of the Hit Rate graph metric using the
calculation shown in Table 11.11 (<sysHttpStatRamcacheHits1> /
(<sysHttpStatRamcacheHits1> +
<sysHttpStatRamcacheMisses1>) *100).
Performance Graph
(Configuration utility)
RAM Cache Utilization
Graph Metric
Required SNMP OID
Hit Rate
<sysHttpStatRamcacheHits1> / (<sysHttpStatRamcacheHits1> +
<sysHttpStatRamcacheMisses1>) *100
Byte Rate
<sysHttpStatRamcacheHitBytes1> /
(<sysHttpStatRamcacheHitBytes1> +
<sysHttpStatRamcacheMissBytes1> ) *100
Eviction Rate
<sysHttpStatRamcacheEvictions1> / (<sysHttpStatRamcacheHits1> +
<sysHttpStatRamcacheMisses1>) *100
Table 11.11 Required calculations for interpreting metrics on RAM Cache use
11 - 14
SNMP
Collecting data on CPU use
You can use SNMP commands to gather and interpret data on CPU use on
the BIG-IP system. Specifically, you can gather and interpret data for these
types of graph metrics:
◆
CPU[0-n] and Global Host CPU Usage
For these graph metrics, you can either instruct the BIG-IP system to
collect the data automatically, based on a predefined polling interval, or
you can use a polling interval of your choice. In either case, you use the
MIBs named sysMultiHostCpu and sysGlobalHostCpu, respectively.
Collecting data based on a predefined polling interval is the
recommended way to collect CPU[0-n] and Global Host CPU Usage
graph metrics. However, you can also perform the calculation manually,
if you want to use a polling interval other than 5 seconds, one minute, or
five minutes.
For the procedure about collecting CPU[0-n] and Global Host CPU
Usage graph metrics based on a predefined polling interval, see Using a
predefined polling interval, on this page. For the procedure about
collecting this performance data manually, see Using a custom polling
interval, on page 11-18.
◆
TMM CPU Usage
For these graph metrics, there is no predefined polling interval for this
MIB; therefore, you must choose a polling interval and perform the
calculations manually. To perform the calculations, you use the MIB
sysStatTm. For more information, see Using a custom polling interval,
on page 11-18.
Using a predefined polling interval
The sysMultiHostCpu and sysGlobalHostCpu MIBs include some special
CPU usage ratio OIDs that cause the BIG-IP system to automatically
calculate graph metrics for you. The particular CPU usage ratio OID that
you use is based on a predefined polling interval that you want the BIG-IP
system to use when performing the calculation: five seconds, one minute, or
five minutes. Specifically, a CPU usage ratio OID:
• Polls each individual CPU OID twice
• Calculates the delta of the two polls
• Performs a calculation using all delta values (that is, delta values from all
OIDs polled)
The sysMultiHostCpu usage ratio OIDs available for you to use are:
• sysMultiHostCpuUsageRatio (uses a 5-second polling interval)
• sysMultiHostCpuUsageRatio5s (also uses a 5-second polling interval)
• sysMultiHostCpuUsageRatio1m (uses a 1-minute polling interval)
• sysMultiHostCpuUsageRatio5m (uses a 5-minute polling interval)
BIG-IP® TMOS®: Concepts
11 - 15
Chapter 11
The sysGlobalHostCpu usage ratio OIDs available for you to use are:
• sysGlobalHostCpuUsageRatio (uses a 5-second polling interval)
• sysGlobalHostCpuUsageRatio5s (also uses a 5-second polling interval)
• sysGlobalHostCpuUsageRatio1m (uses a 1-minute polling interval)
• sysGlobalHostCpuUsageRatio5m (uses a 5-minute polling interval)
Table 11.12 shows the individual OIDS that the BIG-IP system polls for
CPU[0-n] graph metrics, based on 5-second, 1-minute, or 5-minute
intervals. Note that for each polling interval, the MIB also includes the
pertinent CPU usage ratio OID or OIDs that you use to initiate the automatic
polling and resulting delta calculations.
Performance Graph
(Configuration utility)
Graph
Metric
Required SNMP OIDs
5-second Polling Interval
sysMultiHostCpuUser5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.12)
sysMultiHostCpuNice5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.13)
sysMultiHostCpuSystem5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.14)
sysMultiHostCpuIdle5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.15)
sysMultiHostCpuIrq5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.16)
sysMultiHostCpuSoftirq5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.17)
sysMultiHostCpuIowait5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.18)
sysMultiHostCpuUsageRatio5s (.1.3.6.1.4.1.3375.2.1.7.5.2.1.19)
sysMultiHostCpuUsageRatio (.1.3.6.1.4.1.3375.2.1.7.5.2.1.11)
CPU Usage
CPU[0-n]
1-minute Polling Interval
sysMultiHostCpuUser1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.20)
sysMultiHostCpuNice1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.21)
sysMultiHostCpuSystem1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.22)
sysMultiHostCpuIdle1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.23)
sysMultiHostCpuIrq 1m(.1.3.6.1.4.1.3375.2.1.7.5.2.1.24)
sysMultiHostCpuSoftirq1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.25
sysMultiHostCpuIowait1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.26)
sysMultiHostCpuUsageRatio1m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.26)
5-minute Polling Interval
sysMultiHostCpuUse5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.28)
sysMultiHostCpuNice5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.29)
sysMultiHostCpuSystem5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.30)
sysMultiHostCpuIdle5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.31)
sysMultiHostCpuIrq5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.32
sysMultiHostCpuSoftirq5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.33)
sysMultiHostCpuIowait5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.34)
sysMultiHostCpuUsageRatio5m (.1.3.6.1.4.1.3375.2.1.7.5.2.1.35)
Table 11.12 Required OIDs for automatic collection of CPU[0-n] graph metrics
11 - 16
SNMP
Table 11.13 shows the individual OIDS that the BIG-IP system polls for
Global Host CPU Usage graph metrics, based on five-second, 1-minute, or
5-minute intervals. Note that for each polling interval, the MIB also includes
the pertinent CPU usage ratio OID or OIDs that you use to initiate the
automatic polling and resulting delta calculations.
Performance Graph
(Configuration utility)
Graph
Metric
Required SNMP OIDs
5-second Polling Interval
sysGlobalHostCpuUser5s (.1.3.6.1.4.1.3375.2.1.1.2.20.14)
sysGlobalHostCpuNice5s (.1.3.6.1.4.1.3375.2.1.1.2.20.15)
sysGlobalHostCpuSystem5s (.1.3.6.1.4.1.3375.2.1.1.2.20.16)
sysGlobalHostCpuIdle5s (.1.3.6.1.4.1.3375.2.1.1.2.20.17)
sysGlobalHostCpuIrq5s (.1.3.6.1.4.1.3375.2.1.1.2.20.18)
sysGlobalHostCpuSoftirq5s (.1.3.6.1.4.1.3375.2.1.1.2.20.19)
sysGlobalHostCpuIowait5s (.1.3.6.1.4.1.3375.2.1.1.2.20.20)
sysGlobalHostCpuUsageRatio5s (.1.3.6.1.4.1.3375.2.1.1.2.20.21)
sysGlobalHostCpuUsageRatio (.1.3.6.1.4.1.3375.2.1.1.2.20.13)
CPU Usage
Gobal Host
CPU Usage
1-minute Polling Interval
sysGlobalHostCpuUser1m (.1.3.6.1.4.1.3375.2.1.1.2.20.22)
sysGlobalHostCpuNice1m (.1.3.6.1.4.1.3375.2.1.1.2.20.23)
sysGlobalHostCpuSystem1m (.1.3.6.1.4.1.3375.2.1.1.2.20.24)
sysGlobalHostCpuIdle1m (.1.3.6.1.4.1.3375.2.1.1.2.20.25)
sysGlobalHostCpuIrq1m (.1.3.6.1.4.1.3375.2.1.1.2.20.26)
sysGlobalHostCpuSoftirq1m (.1.3.6.1.4.1.3375.2.1.1.2.20.27)
sysGlobalHostCpuIowait1m (.1.3.6.1.4.1.3375.2.1.1.2.20.28)
sysGlobalHostCpuUsageRatio1m (.1.3.6.1.4.1.3375.2.1.1.2.20.29)
5-minute Polling Interval
sysGlobalHostCpuUser5m (.1.3.6.1.4.1.3375.2.1.1.2.20.30)
sysGlobalHostCpuNice5m (.1.3.6.1.4.1.3375.2.1.1.2.20.31)
sysGlobalHostCpuSystem5m (.1.3.6.1.4.1.3375.2.1.1.2.20.32)
sysGlobalHostCpuIdle5m (.1.3.6.1.4.1.3375.2.1.1.2.20.33)
sysGlobalHostCpuIrq5m (.1.3.6.1.4.1.3375.2.1.1.2.20.34)
sysGlobalHostCpuSoftirq5m (.1.3.6.1.4.1.3375.2.1.1.2.20.35)
sysGlobalHostCpuIowait5m (.1.3.6.1.4.1.3375.2.1.1.2.20.36)
sysGlobalHostCpuUsageRatio5m (.1.3.6.1.4.1.3375.2.1.1.2.20.37)
Table 11.13 Required OIDs for automatic collection of Global Host CPU Usage graph metrics
BIG-IP® TMOS®: Concepts
11 - 17
Chapter 11
Using a custom polling interval
The sysMultiHostCpu and sysGlobalHostCpu MIBs include additional
OIDs that you can use to calculate CPU performance data based on a custom
polling interval, that is, a polling interval that you choose. Using a custom
polling interval requires you to poll each individual OID twice at an interval
of your choice, calculate the delta of the two polls, and then perform a
calculation according to a predefined formula.
Table 11.14 includes a list of OIDs to use when collecting CPU performance
data with a custom polling interval. Included are the OIDs for polling for
TMM CPU usage graph metrics, based on five-second, 1-minute, or
5-minute intervals.
Performance Graph
(Configuration utility)
CPU Usage
Graph
Metric
Required SNMP OIDs
CPU[0-n]
sysMultiHostCpuUser (.1.3.6.1.4.1.3375.2.1.7.5.2.1.4)
sysMultiHostCpuNice (.1.3.6.1.4.1.3375.2.1.7.5.2.1.5)
sysMultiHostCpuSystem (.1.3.6.1.4.1.3375.2.1.7.5.2.1.6)
sysMultiHostCpuIdle (.1.3.6.1.4.1.3375.2.1.7.5.2.1.7)
sysMultiHostCpuIrq (.1.3.6.1.4.1.3375.2.1.7.5.2.1.8)
sysMultiHostCpuSoftirq (.1.3.6.1.4.1.3375.2.1.7.5.2.1.9)
sysMultiHostCpuIowait (.1.3.6.1.4.1.3375.2.1.7.5.2.1.10)
Global
Host CPU
Usage
sysGlobalHostCpuCount (.1.3.6.1.4.1.3375.2.1.1.2.20.4)
sysGlobalHostActiveCpu (.1.3.6.1.4.1.3375.2.1.1.2.20.5)
sysGlobalHostCpuUser (.1.3.6.1.4.1.3375.2.1.1.2.20.6)
sysGlobalHostCpuNice (.1.3.6.1.4.1.3375.2.1.1.2.20.7)
sysGlobalHostCpuSystem (.1.3.6.1.4.1.3375.2.1.1.2.20.8)
sysGlobalHostCpuIdle (.1.3.6.1.4.1.3375.2.1.1.2.20.9)
sysGlobalHostCpuIrq (.1.3.6.1.4.1.3375.2.1.1.2.20.10)
sysGlobalHostCpuSoftirq (.1.3.6.1.4.1.3375.2.1.1.2.20.11)
sysGlobalHostCpuIowait (.1.3.6.1.4.1.3375.2.1.1.2.20.12)
TMM CPU
Usage
sysStatTmTotalCycles (.1.3.6.1.4.1.3375.2.1.1.2.1.41)
sysStatTmIdleCycles (.1.3.6.1.4.1.3375.2.1.1.2.1.42)
sysStatTmSleepCycles (.1.3.6.1.4.1.3375.2.1.1.2.1.43)
sysTmmStatTmUsageRatio5s (.1.3.6.1.4.1.3375.2.1.8.2.3.1.37.[tmm_id])
sysTmmStatTmUsageRatio1m (.1.3.6.1.4.1.3375.2.1.8.2.3.1.38.[tmm_id])
sysTmmStatTmUsageRatio5m (.1.3.6.1.4.1.3375.2.1.8.2.3.1.39.[tmm_id]
Table 11.14 Required SNMP OIDs for collecting CPU data manually
Note
TMM IDs within the TMM CPU usage OIDs are used to index the
SysTmmStatEntry table. These TMM IDs vary by platform. An example of an
OID for sysTmmStatTmUsageRatio5s is
.1.3.6.1.4.1.3375.2.1.8.2.3.1.37.3.48.46.49.
11 - 18
SNMP
To calculate CPU usage data manually
1. Poll the OID sysMultiHostCpuUser
(.1.3.6.1.4.1.3375.2.1.7.5.2.1.4) twice, at a 10-second interval.
This results in two values, <sysMultiHostCpuUser1> and
<sysMultiHostCpuUser2>.
Note: Although this example uses an interval of ten seconds, the
interval can actually be any duration that you choose.
2. Calculate the delta of the two poll values:
<DeltaCpuUser> = <sysMultiHostCpuUser2> <sysMultiHostCpuUser1>
3. Repeat steps one and two for each OID pertaining to the CPU[0-n]
graph metric.
4. Repeat steps 1 and 2 again, using the OIDs from the MIBs
sysStatTm and sysGlobalHostCpu.
5. Calculate the values of the graph metrics, using the formulas shown
in Table 11.15.
Performance Graph
(Configuration utility)
CPU Usage
Graph Metric
Required calculations for CPU use
CPU[0-n]
(<DeltaCpuUser> + <DeltaCpuNice> + <DeltaCpuSystem>) /
(<DeltaCpuUser> + <DeltaCpuNice> + <Delta CpuIdle> +
<DeltaCpuSystem> + <DeltaCpuIrq> + <DeltaCpuSoftirq> +
<DeltaCpuIowait>) *100
Global Host CPU
Usage
(<DeltaCpuUser> + <DeltaCpuNice> + <DeltaCpuSystem>) /
(<DeltaCpuUser> + <DeltaCpuNice> + <Delta CpuIdle> +
<DeltaCpuSystem> + <DeltaCpuIrq> + <DeltaCpuSoftirq> +
<DeltaCpuIowait>) *100
TMM CPU Usage
((<DeltaTmTotalCycles> - (<DeltaTmIdleCycles> +
<DeltaTmSleepCycles>)) / <DeltaTmTotalCycles>) *100
Table 11.15 Formulas for calculating metrics on CPU use
Collecting data on SSL transactions per second
You can use SNMP commands with an OID to gather and interpret data on
SSL performance, in terms of transactions per second.
To gather and interpret the data for this metric, you must perform some
polling and calculations:
• First, you must poll two OIDs separately and then add the two poll values
together.
• Next, you must repeat the first two steps at some time interval (such as
ten seconds) from the first two polls. Again, you add the two poll values
together.
• Next, you calculate the delta of the two sums.
BIG-IP® TMOS®: Concepts
11 - 19
Chapter 11
• Finally, you perform a calculation on the OID delta.
Table 11.16 shows the OID that you must poll, retrieving two separate poll
values for this OID.
Performance Graph
(Configuration utility)
Graph Metrics
Required SNMP OIDs
SSL TPS
SSL TPS
sysClientsslStatTotNativeConns (.1.3.6.1.4.1.3375.2.1.1.2.9.6)
SSL TPS
SSL TPS
sysClientsslStatTotCompatConns (.1.3.6.1.4.1.3375.2.1.1.2.9.9)
SSL TPS
SSL TPS
sysServersslStatTotNativeConns (.1.3.6.1.4.1.3375.2.1.1.2.10.6)
SSL TPS
SSL TPS
sysServersslStatTotCompatConns (.1.3.6.1.4.1.3375.2.1.1.2.10.9)
Table 11.16 Required OIDs for polling for data on SSL TPS
For example, the following steps show how to collect data on SSL
transactions for the SSL TPS graph metric:
1. Poll the OID sysClientsslStatTotNativeConns
(.1.3.6.1.4.1.3375.2.1.1.2.9.6).
2. Poll the OID sysClientsslStatTotCompatConns
(.1.3.6.1.4.1.3375.2.1.1.2.9.9).
3. Add the two values together.
This results in the value sysClientsslStatTotConns1.
4. Poll the two OIDs again, within ten seconds of the previous polls
(shown in steps 1 and 2).
Note: Although this example uses an interval of ten seconds, the
interval can actually be any duration that you choose.
5. Again, add the two values together.
This results in the value sysClientsslStatTotConns2.
6. Calculate the delta of the two sums:
<DeltaClientsslStatTotConns> =
<sysClientsslStatTotConns2> - <sysClientsslStatTotConns1>
7. Calculate the actual value of the SSL TPS graph metric using the
calculation shown in Table 11.17. An example of the <interval>
value is 10.
Performance Graph
(Configuration utility)
Graph Metric
Required calculations for SSL TPS
SSL TPS
SSL TPS
<DeltaClientsslStatClientTotConns> / <interval>
Table 11.17 Required calculations for interpreting metrics on SSL TPS
11 - 20
12
Administrative Partitions and Folders
• About administrative partitions
• About folders
Administrative Partitions and Folders
About administrative partitions
If you have the Administrator or User Manager user role assigned to your
BIG-IP® system user account, you can control other users’ access to objects
by using a feature known as administrative partitions. An administrative
partition is a logical container that you create, containing a defined set of
BIG-IP system objects.
When a specific set of objects resides in a partition, you can then give
certain users the authority to view and manage the objects in that partition
only, rather than to all objects on the BIG-IP system. This gives a finer
granularity of administrative control.
A significant benefit to administrative partitions is that they allow you to
place administrative ownership of an application into the hands of the
business units that actually run the applications.
To configure and manage administrative partitions, log in to the BIG-IP
Configuration utility, and on the Main tab, expand System, and click Users.
Figure 12.1, on page 12-1, shows an example of partitions that you can
create on a BIG-IP system. Partition App1 contains objects that pertain to an
HTTP application, partition App2 contains objects that pertain to traffic
utilizing Packet Velocity® ASIC (PVA), and partition Users contains local
user accounts on the BIG-IP system.
Figure 12.1 Sample partitions on the BIG-IP system
BIG-IP® TMOS®: Concepts
12 - 1
Chapter 12
In short, partitions affect the way that you manage configurable objects on
the BIG-IP system, including user accounts.
The partition Common
During BIG-IP system installation, the system automatically creates a
partition known as partition Common (often referred to as the Common
partition). At a minimum, this partition contains all of the BIG-IP system
objects that the system creates during installation.
Note
Until you create other partitions on the system, all objects that you or other
users create automatically reside in partition Common. If you create other
partitions later, you cannot move an object in Common to one of the new
partitions. Instead, you must delete the object from Common and recreate it
in the new partition.
With respect to permissions, all users on the system except those with a user
role of No Access have read access to objects in the Common partition, and
by default, the Common partition is their current partition. (For information
on the current partition, see The current partition, following.)
Some users, such as those with the user role of Administrator, can also
create, update, and delete objects in the Common partition. No user can
delete the Common partition itself. For information about the permissions
of each user role with respect to viewing and managing objects in partition
Common, see Chapter 13, BIG-IP User Accounts.
One of the objects that the BIG-IP system creates in partition Common
during installation is a route domain with an ID of 0. Route domain 0 is the
default route domain on the BIG-IP system. For more information about
route domains, see the guide titled BIG-IP® TMOS: IP Routing
Administration.
The current partition
The current partition is the specific partition to which a logged-in user
currently has access, as determined by the properties of that user’s account.
Whenever a user performs an action on the BIG-IP system, the system
automatically performs that action within the current partition.
As described in Chapter 13, BIG-IP User Accounts, a user account grants
permission to access either a single partition (other than partition Common)
or all partitions. If a user has permission to access one partition only, the
user cannot select the current partition. Instead, the BIG-IP system
establishes the user’s current partition at login time, based on the particular
partition access that is specified in the properties of that user account.
Users who have permission to access all partitions can actively select the
current partition, that is, the specific partition they want to view or manage.
12 - 2
Administrative Partitions and Folders
For example, suppose user rsmith has a role of Manager, and a user with
an Administrator role has given user rsmith access to all partitions on the
system (for example, partitions A, B, C, and Common). In this case, before
creating or managing any object on the BIG-IP system, user rsmith must
select the partition (A, B, or C) that she wants to be the current partition.
After selecting the current partition, any object that she creates will reside in
that partition, and she can modify or delete only those objects that reside in
the current partition. If she fails to select partition A, B, or C, the current
partition is Common, by default. User rsmith selects a partition using either
the Configuration utility or a command line interface.
Conversely, if user rsmith has the role of Manager and she is granted
access to partition A only, then any object that she creates while logged into
the BIG-IP system automatically becomes a member of partition A.
Although she can view objects in partition Common, she cannot select
Common as her current partition because she has read access only for that
partition. For user rsmith, partition A is automatically her current partition,
and she cannot change the current partition to create objects in another
partition.
For more information about user roles and the relationship of user roles to
partitions, see Partitions and user accounts, on page 12-5.
Referencing objects in partitions
Certain BIG-IP system objects, such as virtual servers, always reference
other objects. Examples of objects that a virtual server can reference are
pools, profiles, and iRules®. When you create objects, a referenced object
must reside either in the same partition as the object that is referencing it, or
in the Common partition.
For example, if a virtual server such as my_vs resides in partition my_app
and references the pool my_pool, then the object my_pool must reside
either in partition my_app or in partition Common.
Figure 12.2 shows an example of an allowed configuration, where a virtual
server and the pool it references reside in the same partition my_app).
BIG-IP® TMOS®: Concepts
12 - 3
Chapter 12
Figure 12.2 A virtual server referencing a pool in the same partition
The other case in which one object can reference another is when the object
resides in one partition, while the object it references resides in partition
Common. Figure 12.3, shows an example of this configuration, where a
virtual server in partition my_app references a pool in partition Common.
Figure 12.3 Allowed object referencing across partitions
Note in this illustration that direction is important; the referencing object
(the virtual server) must be in a user-created partition (my_app), while the
referenced object (the pool) must reside in partition Common. As shown in
Figure 12.4, the virtual server cannot reside in partition Common and
reference a pool that resides in partition my_app.
12 - 4
Administrative Partitions and Folders
Figure 12.4 Object referencing across partitions that is not allowed
Partitions and user accounts
Partitions have a special relationship to user accounts. With respect to
partitions and user accounts, you can:
◆
Assign partition access to user accounts
You can assign an authorized partition (known as partition access) to a
user account. A partition access assignment gives a user some level of
authority over the specified partition. As an option, for all user roles you
can assign universal access to partitions, which grants users permission
to access all partitions instead of one non-Common partition only. Note
that assigning partition access to a user does not make the user a member
of that partition, nor does it necessarily give the user full access to all
objects in the partition.
◆
Create user accounts as partitioned objects
As described earlier, when you create a user account, you assign partition
access for that account as a way to define the scope of that user’s access
control. However, like many other object types, user accounts also reside
in partitions. This controls other users’ administrative access to those
user accounts. Also like other object types, a BIG-IP system user account
cannot belong to more than one partition simultaneously. Note that when
you first install the BIG-IP system, every existing user account (root and
admin) belongs to partition Common.
For detailed information on creating and managing user accounts and
assigning user roles to them, see Chapter 13, BIG-IP User Accounts.
Partition summary
To see the relationship of partitions to objects, consider the following
example. This example shows how you can configure the BIG-IP system to
grant a particular BIG-IP system administrator, Jane Smith, permission to
BIG-IP® TMOS®: Concepts
12 - 5
Chapter 12
manage all objects in a specific partition pertaining to the management of
HTTP traffic. Note that to perform this task successfully, your own user
account must have the role of Administrator assigned to it.
1. Create a new partition named vendor_appl.
2. Select the vendor_appl partition to be the current partition.
3. Create any HTTP-related objects that you want to reside in that
partition, such as a virtual server, a load balancing pool, and an
HTTP profile.
4. Select an existing partition in which you want Jane’s user account to
reside, such as IT_users.
This is now your current partition.
5. Create a user account for Jane as follows:
a) Assign the name jsmith to the user account.
Note that this account resides in the current partition, IT_users.
b) Create a password for the jsmith user account.
c) Assign the user role of Manager to the jsmith account.
This role allows Jane to control all resources in the partition to
which she is given access (see the following step).
d) Designate the vendor_appl partition as the partition to which
user jsmith has access.
6. Instruct Jane to log in to the BIG-IP system using her new user
account jsmith.
When Jane logs into the system as jsmith, the system sets her current
partition to vendor_appl because this is the partition you assigned to her
when you created her user account (see step 5d). Because you assigned her a
user role of Manager, Jane can fully manage all objects in partition
vendor_appl, as well as create new objects. Note, however, that the user
account object jsmith resides in partition IT_users.
Important
As shown in this example, there is no relation between the partition in which
the jsmith user account resides (IT_users) and the partition to which the
jsmith account has access (vendor_appl).
12 - 6
Administrative Partitions and Folders
Implementation considerations
When implementing the partitions feature, there are some specific aspects of
the feature that you should consider, with corresponding recommendations.
See Table 12.1 for more informationn.
Considerations
Recommendations
An object can only reference another object if both
objects are in the same partition, or if the referenced
object is in partition Common.
When you create objects, ensure that the referencing
object and its referenced object reside in the same
partition, or that the referenced object resides in partition
Common.
Users cannot move objects from one partition to another.
If you want to change the partition in which an object
resides, delete the object from the old partition, and
recreate the object in the new partition.
Note that if the object you want to delete and recreate in
another partition is a pool that resides in partition
Common, you should not only delete the pool, but also
delete any nodes associated with that pool. Otherwise,
pools in other partitions can reference those nodes that
are in partition Common.
The same BIG-IP system object cannot be a member of
more than one partition simultaneously.
No recommendation needed.
If an authorized user modifies a parent object, the system
propagates the changes to all child objects, regardless of
the partition in which the child object resides.
Be aware that modifications to a child object that other
administrators implemented might appear.
If a user with permission to manage objects in partition
Common disables a monitor that is designated as the
default monitor for nodes (such as the icmp monitor), this
affects all nodes on the system.
Ensure that a default monitor for nodes is enabled and
always resides in partition Common.
An iRule can reference any object, regardless of the
partition in which the referenced object resides. For
example, an iRule that resides in partition A can contain a
pool statement that specifies a pool residing in partition
B.
No recommendation needed.
For objects that cannot reside in partitions (such as
packet filters), only users with the Administrator or
Resource Administrator role have full access to these
objects. Users with a role other than Administrator,
Resource Administrator can view these objects, but
they cannot create, modify, or delete them.
Verify that each user account has the appropriate user
role assigned to it.
When attempting to create an object, the user might see
an error message stating that the object already exists,
even though the object name does not appear on the list
screen. This is because the existing object resides in a
partition that the user has no permission to access.
Every object on the system must have a unique name,
regardless of the partition in which the object
resides.Therefore, when creating an object on the
system, be sure to assign a unique name to the object.
Table 12.1 Considerations and recommendations for implementing administrative partitions
BIG-IP® TMOS®: Concepts
12 - 7
Chapter 12
About folders
For every partition on the BIG-IP system, there is an equivalent folder. In
the context of the BIG-IP system, a folder is a container for BIG-IP system
objects. Folders resemble standard directories, in that the system includes a
root folder (represented by the / symbol) that is the parent for other folders
on the system.
You can use folders to set up granular synchronization and failover of
BIG-IP configuration data in a device group. Instead of synchronizing or
failing over all configuration data on a BIG-IP device to the same device
group, the BIG-IP system can synchronize or fail over objects within a
specific folder only to a different device group.
You can implement granular synchronization and failover in two ways:
◆
You can use tmsh to set a folder’s device group to the name of the device
group to which you want to synchronize the contents of that folder. You
can also set the folder’s traffic group attribute to the name of the traffic
group that you want to associate with the contents of that folder.
◆
You can use the BIG-IP Configuration utility to associate a device and
traffic group with an administrative partition. This sets the device and
traffic group attributes on the corresponding folder.
Folders have important characteristics:
• The root folder
The BIG-IP system includes a root folder. When you assign a device
group to the root folder, all configuration data on the device, by default,
is synchronized to the devices in that device group.
• Folder-partition association
A high-level folder exists on the system within the root folder for each
administrative partition. For example, for the Common partition, there is
a corresponding high-level folder named /Common. If you create
another administrative partition, such as partition App_A, the BIG-IP
system automatically creates another high-level folder named /App_A.
• Folders and the current partition
The close association of administrative partitions to folders means that
when you use the BIG-IP Configuration utility to create objects on a
BIG-IP device, the system puts those objects in the folder corresponding
to the current partition. For example, if your current partition is partition
Common, any objects you create reside in folder /Common. Examples
of BIG-IP objects that reside in folders are virtual servers, pools, and self
IP addresses.
• BIG-IP object names
The folder in which an object resides becomes part of the name of that
object. For example, if you create a pool in partition Common and name
the pool my_pool, the complete name of the pool on the system is
/Common/my_pool. If you create the pool in partition App_A, the
complete name of the pool on the system is /App_A/my_pool.
12 - 8
Administrative Partitions and Folders
• Sub-folders
You can create sub-folders within a high-level folder, using tmsh. For
example, if you have a high-level folder (partition) within the root folder
named Customer1, you can use tmsh to create a sub-folder, such as
App_B, within Customer1. If you create a pool named my_pool within
the sub-folder, the name of the pool is /Customer1/App_B/my_pool.
• Viewing folder contents
When you use tmsh to view the contents of any folder on the system, the
system also shows the objects in folder /Common.
BIG-IP® TMOS®: Concepts
12 - 9
Chapter 12
12 - 10
13
BIG-IP User Accounts
• Introduction to user account management
• Managing local user accounts
• Managing remote user accounts
• Auditing user access to the system
BIG-IP User Accounts
Introduction to user account management
An important part of managing the BIG-IP® system is creating and
managing user accounts for BIG-IP system administrators. By creating user
accounts for system administrators, you provide additional layers of
security. User accounts ensure that the system:
• Verifies the identity of users logging into the system (authentication)
• Controls user access to system resources (authorization)
To enable user authentication and authorization, you assign passwords and
user roles to your user accounts. Passwords allow you to authenticate your
users when they attempt to log in to the BIG-IP system. User roles allow
you to control user access to BIG-IP system resources.
You can create and store your BIG-IP administrative accounts either locally
on the BIG-IP system, or remotely on a separate authentication server. If
you want your user accounts to reside locally on the BIG-IP system, you
create those user accounts on the BIG-IP system and assign user roles to
them.
If you want your user accounts to reside remotely on a separate
authentication server, you do not use the BIG-IP system to create the
accounts. Instead, you use the mechanism provided by the server vendor,
and you use the BIG-IP system strictly to assign user roles to those remote
accounts and to maintain those user role assignments over time. The types of
servers that you can use to remotely store BIG-IP system user accounts are:
• Lightweight Directory Access Protocol (LDAP) servers
• Active Directory servers
• Remote Authentication Dial-in User Service (RADIUS) servers
To manage user accounts, including user roles, on the BIG-IP system, log in
to the BIG-IP Configuration utility, and on the Main tab, expand System,
and click Users.
Important
For information on managing remote user accounts, see Managing remote
user accounts, on page 13-14, and the guide titled BIG-IP® Local Traffic
Manager™: Implementations.
Understanding user account types
There are two types of user accounts on the BIG-IP system: The system
maintenance account and a set of standard user accounts.
◆
BIG-IP® TMOS®: Concepts
The system maintenance account
The system maintenance account is a user account that you maintain
using the Setup utility. The name of the system maintenance account is
root. This account resides locally on the BIG-IP system and grants full
access to BIG-IP system resources. You configure and maintain this
account using the Setup utility and the Configuration utility, respectively.
13 - 1
Chapter 13
◆
Standard user accounts
Standard user accounts are user accounts that you create for other
BIG-IP system administrators to use. Standard user accounts can reside
either locally on the BIG-IP system, or remotely on a remote
authentication server. You create and maintain these accounts using the
browser-based Configuration utility or the command line interface.
Creating standard user accounts allows you to assign various user roles to
those accounts as a way to control system administrator access to BIG-IP
system resources. A special standard user account is the admin account,
which automatically exists on any BIG-IP system. For more information
on the admin account, see Configuring the admin account, on page 13-8.
For more information on user roles, see Understanding user roles, on
page 13-4.
Note
Excluding the admin account, the entire set of standard user accounts that
you create for BIG-IP system administrators must reside either locally on
the BIG-IP system, or remotely on another type of authentication server.
You are not required to have any user accounts other than the root and
admin accounts, but F5 Networks® recommends that you create other user
accounts, as a way to intelligently control administrator access to system
resources.
The tools you use to create and maintain user accounts vary according to the
type of account you are managing. Table 13.1 lists the various user accounts
for the BIG-IP system and the tools you use to manage them.
Account Name
Creation/Configuration
Tools
The admin account
Setup utility
Maintenance Tools
Configuration utility
(Users screen)
Command line interface
Other user accounts
Configuration utility
Command line interface
Configuration utility
(Users screen)
Command line interface
Table 13.1 Tools for managing user accounts
Understanding administrative partitions
When you create configurable objects for the BIG-IP system, you have the
option of putting those objects into administrative partitions. An
administrative partition is a logical container of BIG-IP system objects such
as virtual servers, pools, and monitors. When you first install the BIG-IP
system, a default partition already exists named Common.
13 - 2
BIG-IP User Accounts
By putting objects into partitions, you establish a finer granularity of access
control. Rather than having control over all resources on the BIG-IP system
or no resources whatsoever, users with certain permissions can control
resources within a designated partition only. For example, users with the
role of Operator can mark nodes up or down, but can only mark those
nodes that reside within their designated partition.
User accounts are another type of object that you can put into a partition.
You put user accounts into administrative partitions strictly for the purpose
of giving other users administrative access to those accounts. For example,
you can put user accounts into partition B, and then assign a set of
permissions (known as a user role) to user Jane so that she is allowed to
modify user accounts in partition B.
Each user account on the BIG-IP system has a property known as Partition
Access. The Partition Access property defines the partitions that the user
can access. A user account can have access to either one partition or all
partitions. Access to all partitions is known as universal access.
Figure 13.1, on page 13-3, shows how partition access can differ for
different user accounts on the BIG-IP system.
Figure 13.1 The Partition Access property for user accounts
BIG-IP® TMOS®: Concepts
13 - 3
Chapter 13
In this example, the BIG-IP system objects reside in multiple partitions.
Note that user accounts are also a type of BIG-IP system object, and as such,
reside in a partition named Users. (Although you are not required to group
user accounts together in a separate partition, for security purposes we
highly recommend that you do so.)
To continue with the example, each user account in partition Users has
access to specific, but different, partitions. Note that user accounts sjones,
cjohnson, and gnelson can access one partition only, while the tbrown
account has universal access.
To summarize, an administrative partition defines a set of objects, including
user accounts, that other administrative users can potentially manage. This
gives computing organizations greater control over user access to specific
objects on the BIG-IP system.
Understanding user roles
To use the powerful user-roles feature, you should understand the available
user roles and the ways that a user role affects a user’s access to objects
residing within partitions.
What are user roles?
User roles are a means of controlling user access to BIG-IP system
resources. You assign a user role to each administrative user, and in so
doing, you grant the user a set of permissions for accessing BIG-IP system
resources.
The BIG-IP system offers several different user roles that you can choose
from when assigning a role to an administrative user. Valid user roles are
listed in Table 13.2, on page 13-5.
A user role is a property of a user account. Each user role grants a different
set of permissions. More specifically, a user role defines:
13 - 4
◆
The resources that a user can manage
User roles define the types of resources, or objects, that a user can
manage. For example, a user with the role of Operator can enable or
disable nodes and pool members only. By contrast, a user with the Guest
role cannot manage any BIG-IP system resources.
◆
The tasks that a user can perform
For example, a user with the role of Operator can enable or disable
nodes and pool members, but cannot create, modify, or delete them.
Conversely, a user with the Manager role can perform all tasks related to
partitioned objects (except for user accounts), including nodes and pool
members.
BIG-IP User Accounts
Table 13.2, on page 13-5, lists and describes the various user roles that you
can assign to a user account.
Important
A role defines the type of objects that a user can manage and the tasks that a
user can perform on those object types. A role does not define the set of
specific, existing objects that the user can access. For information on
defining user access to specific objects on the system, see Effect of user
roles on objects within partitions, on page 13-7.
User Role
Description
Administrator
This role grants users complete access to all partitioned and non-partitioned objects on the
system. In addition, accounts with the Administrator role can change their own passwords.
Resource
Administrator
This role grants users complete access to all partitioned and non-partitioned objects on the
system, except user account objects. In addition, accounts with the Resource Administrator
role can change their own passwords.
User Manager
Users with the User Manager role that have access to all partitions can create, modify,
delete, and view all user accounts except those that are assigned the Administrator role, or
the User Manager role with different partition access. Accounts with the User Manager role
that have access to all partitions can also change their own passwords.
Users with the User Manager role that have access only to a single partition can create,
modify, delete, and view only those user accounts that are in that partition and that have
access to that partition only. For example, if your user account has a User Manager role and
has access to Partition A only, then you can manage only those user accounts that both
reside in and have access to Partition A only.
User accounts with the User Manager role can change their own passwords.
Manager
This role grants users permission to create, modify, and delete virtual servers, pools, pool
members, nodes, custom profiles, custom monitors, and iRules®. These users can view all
objects on the system and change their own passwords.
Certificate Manager
This role grants users permission to manage device certificates and keys, as well as perform
Federal Information Processing Standard (FIPS) operations.
iRule Manager
This role grants users permission to create, modify, and delete iRules. Users with this role
cannot affect the way that an iRule is deployed. For example, a user with this role can create
an iRule but cannot assign it to a virtual server or move the iRule from one virtual server to
another. A user with this role can be assigned universal access to administrative partitions.
Application Editor
This role grants users permission to modify nodes, pools, pool members, and monitors.
These users can view all objects on the system and change their own passwords.
Acceleration Policy
Editor
This role allows users to view, create, modify, and delete all WebAccelerator™ policy objects
in all administrative partitions. Users can also view, create, update, and delete LTM Web
Acceleration and HTTP Class profiles.
Table 13.2 The various roles for user accounts
BIG-IP® TMOS®: Concepts
13 - 5
Chapter 13
User Role
Description
Web Application
Security
Administrator
This role grants users access to Application Security Manager™ security policy objects, in
one or all administrative partitions. These users can modify HTTP Class profiles, but cannot
create or delete them. More specifically, these users can access LTM objects in these ways:
• Ability to enable or disable application security from within an HTTP Class profile.
• Read-only permission for these profile types: HTTP, FTP, and SMTP.
These users have no access to other LTM objects, nor to any TMOS objects. They can,
however, change their own passwords. With respect to security policy objects, this role is
similar to the Administrator role. You can assign this role only when the BIG-IP system
includes the Application Security Manager component.
Web Application
Security Editor
This role allows a user to configure or view most parts of the ASM module, in a specified
administrative partition only. Specifically, these users have limited access to LTM objects,
namely read-only permission for these profile types: HTTP, FTP, SMTP, and HTTP Class.
These users have no access to other LTM objects, nor to any TMOS objects. They can,
however, change their own passwords.
You can assign this role only when the BIG-IP system includes the Application Security
Manager component.
Operator
This role grants users permission to enable or disable nodes and pool members. These users
can view all objects and change their own passwords.
Auditor
This role grants users permission to view all configuration data on the system, including logs
and archives. Users with this role cannot create, modify, or delete any data, nor can they view
SSL keys or user passwords.
Guest
This role grants users permission to view all objects on the system except for sensitive data
such as logs and archives. Users with this role can change their own passwords.
No Access
This role prevents users from accessing the system.
Table 13.2 The various roles for user accounts
Understanding default user roles
The BIG-IP system automatically assigns a user role to an account when
you create that account. The user role that the system assigns to a user
account by default depends on the type of account:
13 - 6
◆
root and admin accounts
The BIG-IP system automatically assigns the Administrator user role to
the system maintenance root account and the admin account. You
cannot change this user-role assignment. Thus, any user who successfully
logs into the BIG-IP system using the root or admin account has full
access to system resources and can perform all administrative tasks.
◆
Other user accounts
The BIG-IP system automatically assigns the No Access user role to all
standard user accounts other than the root and admin accounts. If the
user account you are using has the Administrator role assigned to it, you
are allowed to change another account’s user role from the default No
Access role to any other user role, including Administrator. For remote
user accounts, if you know that most of your administrative users need
BIG-IP User Accounts
some amount of access to BIG-IP system resources, you can configure
the BIG-IP system to use a role other than No Access as the default user
role.
Effect of user roles on objects within partitions
A user role defines the access level that a user has for each object in the
user’s assigned partition. An access level refers to the type of task that a user
can perform on an object. Possible access levels are:
◆
Write
Grants full access, that is, the ability to create, modify, enable and
disable, and delete an object.
◆
Update
Grants the ability to modify, enable, and disable an object.
◆
Enable/disable
Grants the ability to enable or disable an object.
◆
Read
Grants the ability to view an object.
Managing local user accounts
Managing local user accounts refers to the tasks of creating, viewing,
modifying, and deleting user accounts that reside on the BIG-IP system,
using the browser-based Configuration utility.
The Configuration utility stores local user accounts (including user names,
passwords, and user roles) in a local user-account database. When a user
logs into the BIG-IP system using one of these locally-stored accounts, the
BIG-IP system checks the account to determine the user role assigned to that
user account.
You assign a user role to an account at the time that you create the account,
or by changing the properties of an existing account.
Important
Only users with the role of Administrator and User Manager can create
and manage local user accounts. However, users with any role can change
their own passwords. Also, if a user with a local user account is logged on
to the BIG-IP system, and you subsequently switch the system from local
authentication to remote authentication, the local user remains
authenticated until the user’s logon session terminates.
BIG-IP® TMOS®: Concepts
13 - 7
Chapter 13
Configuring the admin account
A user account called admin resides on every BIG-IP system. Although the
BIG-IP system creates this account automatically, you must still assign a
password to the account before you can use it. To initially set the password
for the admin account, you must run the Setup utility. To change its
password later, you use the Configuration utility’s Users screens.
The admin account resides in the local user account database on the BIG-IP
system. By default, the BIG-IP system assigns the Administrator user role,
which gives the user of this account full access to all BIG-IP system
resources. You cannot change the user role on this account. For detailed on
user roles, see Understanding user roles, on page 13-4.
Configuring a secure password policy
The BIG-IP system includes an optional administrative feature: a security
policy for creating passwords for local BIG-IP system user accounts. A
secure password policy ensures that BIG-IP system users that have local
user accounts create and maintain passwords that are as secure as possible.
The secure password policy feature includes two distinct types of password
restrictions:
◆
Enforcement restrictions
These are, specifically, character restrictions that you can enable or
disable. They consist of the minimum password length and the required
character types (numeric, uppercase, lowercase, and other kinds of
characters). When enabled, the BIG-IP system never enforces restrictions
on user accounts that have the Administrator role assigned to them.
Consequently, a user with Administrator permissions does not need to
adhere to these restrictions when either changing his or her own
password, or changing the passwords of other user accounts.
◆
Policy restrictions
These restrictions represent the minimum and maximum lengths of time
that passwords can be in effect. Also included in this type of policy
restriction are the number of days prior to password expiration that users
are warned, and the number of previous passwords that the BIG-IP
system should store, to prevent users from re-using former passwords.
When you have configured policy restrictions using the BIG-IP
Configuration utility, policy restrictions apply to all user accounts,
regardless of user role, except for user accounts with the Administrator
role assigned to them. These restrictions are always enabled, although
using the default values provides a minimal amount of restriction.
Note
The value of the Maximum Duration setting determines when users receive
warning messages to change their passwords. If you change the value of this
setting, any subsequent warning messages that users receive indicate the
13 - 8
BIG-IP User Accounts
previous maximum duration value, rather than the new value. Once a user
changes the password, however, subsequent reminder messages show the
new value.
The password policy feature affects passwords for local user accounts only.
Passwords for remotely-stored user accounts are not subject to this local
password policy, but might be subject to a separate password policy defined
on the remote system.
Important
You must have the user role of Administrator assigned to your account to
configure this feature.
Table 13.3, on page 13-10, shows the settings that you can configure, along
with their descriptions and default values.
BIG-IP® TMOS®: Concepts
13 - 9
Chapter 13
Setting
Description
Default Value
Secure Password
Enforcement
Enables or disables character restrictions, that is, a policy for
minimum password length and required characters. When you
enable this setting, the Configuration utility displays the Minimum
Length and Required Characters settings.
Disabled
Minimum Length
Specifies the minimum number of characters required for a
password, and the allowed range of values is 6 to 255. This setting
appears only when you enable the Secure Password
Enforcement setting.
6
Important: When enabled, the BIG-IP system enforces this setting
on user accounts with the Guest and Operator roles assigned to
them; any user account with the Administrator role assigned to it
(including the root and admin accounts) is not subject to the
restrictions imposed by this setting.
Required Characters
Specifies the number of numeric, uppercase, lowercase, and other
characters required for a password. The allowed range of values is
0 to 127. This setting appears only when you enable the Secure
Password Enforcement setting.
0
Important: Any user account with the Administrator role assigned
to it (including the root and admin accounts) is not subject to the
restrictions imposed by this setting.
Password Memory
Specifies, for each user account, the number of former passwords
that the BIG-IP system retains to prevent the user from re-using a
recent password. The range of allowed values is 0 to 127. This
setting applies to all user accounts.
0
Minimum Duration
Specifies the minimum number of days before a user can change a
password. The range of allowed values is 0 to 255. This setting
applies to all user accounts.
0
Maximum Duration
Specifies the maximum number of days that a user's password can
be valid. The range of allowed values is 1 to 99999. This setting
applies to all user accounts. For more information, see the note on
the previous page.
99999
Expiration Warning
Specifies the number of days prior to password expiration that the
system sends a warning message to a user. The range of allowed
values is 1 to 255. This setting applies to all user accounts.
7
Maximum Login Failures
Denies access to a user after the specified number of failed
authentication attempts. The administrator can then reset the lock
to re-enable access for the user.
0
Table 13.3 Configuration settings for a secure password policy
Note
Whenever you change the secure password policy, the new configuration
values, such as password expiration, do not apply to passwords that were
created prior to the policy change. However, the new password policy takes
effect the next time that the user changes his or her password.
13 - 10
BIG-IP User Accounts
User authentication lockout
You can deny access to a user after a configured number of failed
authentication attempts. You can then reset the lock to re-enable access for
the user.
To configure the maximum number of failures before user lockout, use the
BIG-IP Configuration utility to locate the Users screen and then navigate to
the Authentication screen. You can then specify a value for the Maximum
Login Failures setting.
If a user becomes locked out, you can use the Unlock button on the User
List screen to unlock the user.
Configuring local user accounts
A local user account stored on the BIG-IP system has several properties.
Table 13.4 lists and describes these properties, along with their default
values.
Property
Description
Default Value
User Name
Specifies the name of the user account. The BIG-IP system is
case-sensitive, which means that names such as JONES and
Jones are treated as separate user accounts.
No default value
Partition
When viewing the properties of an existing user account, displays
the name of the partition in which the user account resides. All
partitionable BIG-IP system objects (including user account objects)
have the Partition property. Note that you cannot edit the value of
this setting.
No default value
Password
Specifies a password that the user will use to log in to the BIG-IP
system.
No default value
Role
Specifies the user role that you want to assign to the user account.
For more information on these user roles, see Table 13.2, on page
13-5.
No Access
Partition Access
Specifies the partition to which the user has access when logged on
to the BIG-IP system. If you have permission to do so, you can
assign this value to a new user account, or change this value on an
existing user account.
All
This setting appears only when the user role for the account is not
Administrator. (Accounts with the Administrator role always have
universal partition access, that is, access to all partitions.)
Terminal Access
Specifies the level of access to the BIG-IP system command line
interface. Possible values are: Disabled and Advanced shell.
Disabled
Users with the Administrator or Resource Administrator role
assigned to their accounts can have advanced shell access, that is,
permission to use all BIG-IP system command line utilities, as well
as any Linux commands.
Table 13.4 Properties of a local BIG-IP system user account
BIG-IP® TMOS®: Concepts
13 - 11
Chapter 13
Depending on the user role assigned to your account (other than the No
Access role), you can either create, view, modify, or delete local user
accounts. Users with the Administrator user role assigned to their own
accounts can perform all of these tasks with respect to user account objects.
Creating local user accounts
When you create a local user account, you must give the account a name and
a password. You must also set the user role, either by retaining the default
user role or by assigning a new one. The default user role for local,
non-system maintenance accounts is No Access.
Only users who have been granted the Administrator or User Manager
role can create user accounts. If the user role assigned to your account is
Administrator, you can create a user account in any partition on the
system. If the user role assigned to your account is User Manager, you can
create a user account in any partition to which you have access.
Note
User accounts on the BIG-IP system are case-sensitive. Thus, the system
treats user accounts such as JONES and Jones as two separate user
accounts. Note, however, that certain user names, such as admin, are
reserved, and are therefore exempt from case-sensitivity. For example, you
cannot create a user account named Admin, aDmin, or ADMIN.
Viewing local user accounts
Using the Configuration utility, you can easily display a list of existing local
user accounts and view the properties of an individual account. Only users
who have been granted the Administrator or User Manager roles can view
the settings of other user accounts.
If the user role assigned to your account is Administrator, you can view
any user account on the BIG-IP system, in any partition. If the user role
assigned to your account is User Manager, you can view any user account
in any partition to which you have access on the BIG-IP system.
To summarize, depending on their own partition access, users with a User
Manager role can do some or all of the following:
• Change another user’s password
• Change another user’s user role
• Change the partition in which the user can access objects (applies only to
users who have both a User Manager role and access to all partitions)
• Enable or disable terminal access
Modifying local user accounts
You use the Configuration utility to modify the properties of any existing
local user account, other than the root account. When modifying user
accounts, consider the following:
13 - 12
BIG-IP User Accounts
• Only users who have been granted either the Administrator or User
Manager role can modify user accounts other than their own account.
• A user with the User Manager role can modify only those accounts that
reside in the partition to which that user has access. For example, if user
nelson has a User Manager role and has access to partition B only, he
can modify only those user accounts that reside in partition B. Even in
this case, however, for user accounts in partition B, user nelson cannot
modify a user’s Partition Access property.
If, however, user nelson has a User Manager role and has access to all
partitions, he can modify all user accounts on the system. This includes
changing another user’s Partition Access property.
• Users with any role but No Access can modify their own user accounts to
change the password. These users cannot modify any other properties of
their own user accounts.
Note: When a user changes their own password, the system
automatically logs the user off of the Configuration utility. The system
then requires the user to use the new password for subsequent logons.
This behavior applies even when the new password matches the old
password.
• Users with the role of User Manager can modify all of the properties of
their own user accounts, except their user role and partition access.
If you have an Administrator user role, you can also change some
properties of the root account. Specifically, you can change the password of
the root account, and you can enable or disable access to the BIG-IP system
through SSH.
WARNING
The Administrator user role provides access to the BIG-IP system prompt.
If a user with the Administrator user role is currently logged on to the
system and you change the user role to a role other than Administrator or
Resource Administrator, the user can still run commands at the BIG-IP
system prompt until he or she logs off of the system.
Deleting local user accounts
If the account you are using has the Administrator or User Manager user
role, you can delete other local user accounts. A user with the
Administrator role can delete any user account on the BIG-IP system in
any partition. A user with the User Manager role can delete user accounts
on the BIG-IP system in only those partitions to which she has access.
BIG-IP® TMOS®: Concepts
13 - 13
Chapter 13
When you delete a local user account, you remove it permanently from the
local user-account database on the BIG-IP system.
Note
You cannot delete the admin user account, nor can you delete the user
account with which you are logged on.
WARNING
The Administrator user role provides access to the BIG-IP system prompt.
If a user with the Administrator user role is currently logged on to the
system and you delete the user account, the user can still run commands at
the BIG-IP system prompt until he or she logs off of the system.
Managing remote user accounts
Rather than store user accounts locally on the BIG-IP system, you can store
them on a remote authentication server. In this case, you create all of your
standard user accounts (including user names and passwords) on that remote
server, using the mechanism supplied by that server’s vendor.
Once you have created each user account on the remote server, you can then
use the BIG-IP system to assign authorization properties (user role, partition
access, and terminal access) for each account, for the purpose of controlling
user access to BIG-IP system resources.
Important
You can assign authorization properties to remotely-stored user accounts on
a group basis. You can then use the single configuration file (SCF) feature
to propagate those properties to other BIG-IP devices on the network. For
more information, see Assigning authorization for groups of user
accounts, on page 13-18, and the guide titled BIG-IP® Local Traffic
Manager™: Implementations.
The Configuration utility stores all local and remote access control
information in the BIG-IP system’s local user-account database. When a
user whose account information is stored remotely logs into the BIG-IP
13 - 14
BIG-IP User Accounts
system and is granted authentication, the BIG-IP system then checks its
local database to determine the access control properties that you assigned to
that user.
Note
The Configuration utility refers to remote user accounts as external users.
An external user is any user account that is stored on a remote
authentication server.
Important
Only users with the role of Administrator can manage user roles for remote
user accounts. Also, if a user with a local user account is logged on to the
BIG-IP system, and you subsequently switch the system from local
authentication to remote authentication, the local user remains
authenticated until the user’s logon session terminates.
Specifying a remote user-account server
One of the tasks you perform with the Configuration utility is to specify the
type of remote user-account server that currently stores your remote user
accounts. The available server types that you can specify are:
• Active Directory or Lightweight Directory Access Protocol (LDAP)
• Remote Authentication Dial-In User Service (RADIUS)
• Terminal Access Controller Access-Control System Plus (TACACS+)
When you specify the type of remote server, you can also configure some
server settings. For example, you can specify the user role you would like
the BIG-IP system to assign to a remote account if you do not explicitly
assign one.
Once you have configured the remote server, if you want any of the remote
accounts to have a non-default user role, you can explicitly assign a user role
to those accounts. For more information on user roles, see Understanding
user roles, on page 13-4.
If the remote authentication server is an Active Directory or LDAP server
and is set up to authenticate SSL traffic, there is an additional feature that
you can enable. You can configure the BIG-IP system to perform the
server-side SSL handshake that the remote server would normally perform
when authenticating client traffic. In this case, there are some preliminary
steps you must perform to prepare for remote authentication using SSL.
Configuring authorization for remote accounts
You create BIG-IP system user accounts on your remote server using the
mechanism provided by the vendor of your remote server. Then, as
described in Specifying a remote user-account server, on page 13-15, you
use the Configuration utility to specify the remote authentication server that
BIG-IP® TMOS®: Concepts
13 - 15
Chapter 13
you are using to store those BIG-IP system user accounts. (Valid remote
authentication servers for storing BIG-IP system user accounts are Active
Directory, LDAP, RADIUS, and TACACS+.)
Once you have used the Configuration utility to specify the remote
authentication server, you can configure authorization properties for the
remote BIG-IP system user accounts. Specifically, you can do the following:
• Assign a single set of default authorization properties to all
remotely-stored user accounts. For more information, see Understanding
default remote-account authorization, on page 13-16.
• Assign unique authorization properties to an individual remote user
account by creating a corresponding local user account, with the same
user name, on the BIG-IP system and assigning access-control properties
to it. For more information, see Assigning authorization to an individual
user account, on page 13-17.
• Change the authorization properties of an individual remote account. For
more information, see Changing authorization for an individual user
account, on page 13-18.
• Assign access-control properties on a group basis (that is, based on
groups of users defined on a remote authentication server). For more
information, see Assigning authorization for groups of user accounts, on
page 13-18.
For descriptions of the user roles that you can assign to accounts, see
Understanding user roles, on page 13-4.
Understanding default remote-account authorization
The Authentication screen that you used to specify the type of remote
authentication server also includes some default authorization values (for
the Role, Partition Access, and Terminal Access settings). Therefore, if
you do not explicitly configure these authorization settings for an individual
BIG-IP system user account, the BIG-IP system assigns the default values to
that account. This ensures that all remote user accounts have valid
authorization settings assigned to them.
The default values for the Role, Partition Access, and Terminal Access
settings are as follows:
• Role--No Access
• Partition Access--All
• Terminal Access--Disabled
When you use these default values for a user account, the user account
appears in the list of BIG-IP user accounts as Other External Users.
You can change the values that the BIG-IP system automatically uses as the
default values for the Role, Partition Access, and Terminal Access
settings.
13 - 16
BIG-IP User Accounts
To change the default authorization properties for remote user accounts, you
configure the Role, Partition Access, and Terminal Access settings on the
same Authentication screen that you used to specify the type of remote
authentication server you are using.
Important
For the Other External Users user account, you can modify the Role,
Partition Access, and Terminal Access settings only when your current
partition on the BIG-IP system is set to Common. If you attempt to modify
these settings when your current partition is other than Common, the system
displays an error message.
Note that you can sometimes inadvertently affect your own user account, if
the BIG-IP system is configured to perform remote user authentication, and
you or another system administrator changes the default role or partition
assigned to all external user accounts:
◆
If you log on to the BIG-IP system using one of these
remotely-authenticated Administrator accounts, and you or another
Administrator user modifies the default role of all external accounts
from Administrator to a lesser role, the system modifies the user role of
your own account to the lesser role. However, the change to your own
account does not actually occur until you log off and log on again to the
BIG-IP system, thus allowing you to complete any tasks you initiated
that still require the Administrator role.
◆
Similarly, your user account can be affected if the BIG-IP system is
configured to perform remote user authentication, and the default
partition assigned to all external user accounts is a specific partition. In
this case, if you are logged on to the BIG-IP system through the
command line using one of the remotely-authenticated accounts, and
another user who is logged on through the Configuration utility modifies
the default partition for external users, the BIG-IP system immediately
logs you off when you attempt to issue another command.
Important
If a BIG-IP system administrator changes the user role or partition
assignment (or both) for any remote user account, the BIG-IP system logs
off all users immediately. (A remote user account in this case refers to
Other External Users.)
Assigning authorization to an individual user account
As stated in the previous section, you do not use the Configuration utility to
create remote user accounts (user name and password) for the BIG-IP
system. Instead, you create those user accounts on the remote server, using
the mechanism provided by the remote server vendor. For authorization
BIG-IP® TMOS®: Concepts
13 - 17
Chapter 13
(access control) data, however, if you have the Administrator role assigned
to your own user account, you can use the Configuration utility to explicitly
assign access control properties to existing remote accounts.
Note
The BIG-IP system automatically assigns a default user role and other
authorization properties to an existing remote account if you do not
explicitly do so.
Remote user account names do not appear in the Configuration utility on the
User List screen. Therefore, to assign non-default authorization properties to
an existing remote account, you must simulate the creation of a new account
on the BIG-IP system, configuring the User Name setting with the precise
name of the existing remote account. You then configure the other
properties on the Create screen as well. In this way, you assign authorization
properties to an existing remote user account.
Use the following procedure to assign non-default authorization properties
to an existing remote user account. (If you have already configured
authorization properties of an individual account and want to change them
again, see Changing authorization for an individual user account, on page
13-18.)
Important
If you want to assign non-default access-control properties to remote user
accounts on a group-wise basis, see Assigning authorization for groups of
user accounts, on page 13-18.
Changing authorization for an individual user account
Sometimes you might want to change the user role, partition access, and
terminal access that you previously assigned to a remote account. To do so,
you must change the properties of that account by clicking the account name
on the User List screen. Only those remote user accounts to which you have
explicitly assigned a user role appear in the list of user accounts.
Remote user accounts that simply inherit the default user role (configured
when you specified the remote authentication server) appear in the list of
remote user accounts under the name Other External Users. For more
information about default authorization properties, see Understanding
default remote-account authorization, on page 13-16.
Assigning authorization for groups of user accounts
If you want to assign the same non-default access control properties to a
group of remotely-stored user accounts, you can use the remote role groups
feature. This feature stores all access control information on a group-wide
basis for remotely-stored user accounts.
After using the remote role groups feature, you can propagate that
access-control information to all BIG-IP devices on the network, using the
single configuration file (SCF) feature. The remote role groups feature,
13 - 18
BIG-IP User Accounts
combined with the SCF feature, removes the need to manually assign access
control properties to each individual BIG-IP user within a group, on each
BIG-IP device on your network.
Granting partition access
When you initially configure a remote server for authentication of BIG-IP
system users, all remote user accounts have access to the Common
partition. If you want a specific remote account to have access to a partition
other than Common, you can specify a different partition when you
configure the authorization properties for that account. Remote accounts that
have the Administrator user role assigned to them automatically have full
access to all partitions on the BIG-IP system,
Viewing remote user accounts
Using the Configuration utility, you can display a list of those remote user
accounts to which you explicitly assigned a non-default user role. If a
remote user account has the default role assigned to it, you cannot see that
account in the list of remote user accounts.
Any users who have access to a partition in which remote accounts reside
can view a list of remote user accounts.
Deleting authorization for an individual user account
When you use the Configuration utility to delete a remote user account, you
are not actually deleting the account from the remote server. Instead, you are
changing the values of the user’s authorization properties back to the default
values. For more information on default authorization values, see
Understanding default remote-account authorization, on page 13-16.
Auditing user access to the system
The BIG-IP system generates a log message whenever a user or an
application attempts to log on to or log off of the system. The system logs
both successful and unsuccessful logon attempts. The system stores these
log messages in the /var/log/secure file.
When the system logs an authentication message in the /var/log/secure file,
the message can contain the following types of information:
• The connecting user's ID
• The IP address or host name of the user's interface
• The time of each logon attempt
• Successful logon attempts for command line interface sessions only
• Failed logon attempts for command line interface, Configuration utility,
and iControl sessions
BIG-IP® TMOS®: Concepts
13 - 19
Chapter 13
• The time of the logoff for command line interface sessions only
Figure 13.2 shows examples of log messages for both successful and failed
logon attempts made by user jsmith.
May 10 16:25:25 jsmith-dev sshd[13272]: pam_audit: user: jsmith(jsmith) from: /dev/pts/10 at jsmith-dev attempts: 1 in:
[Thu May 10 16:25:23 2007 ] out: [Thu May 10 16:25:25 2007 ]
May 10 16:14:56 jsmith-dev sshd[716]: pam_audit: User jsmith from ssh at jsmith-dev failed to login after 1 attempts
(start: [Thu May 10 16:14:53 2007 ] end: [Thu May 10 16:14:56 2007 ]).
Figure 13.2 Sample log messages related to logon attempts
13 - 20
14
Event Logging
• Introducing BIG-IP system logging
• Understanding log types
• Setting log levels
• Configuring encrypted remote logging
Event Logging
Introducing BIG-IP system logging
Viewing and managing log messages is an important part of maintaining a
BIG-IP® system. Log messages inform you on a regular basis of the events
that are happening on the system. Some of these events pertain to general
events happening within the operating system, while other events are
specific to the BIG-IP system, such as the stopping and starting of BIG-IP
system services.
The mechanism that the BIG-IP system uses to log events is the Linux
utility syslog-ng. The syslog-ng utility is an enhanced version of the
standard UNIX and Linux logging utility syslog.
The types of events that the BIG-IP system logs are:
◆
System events
System event messages are based on Linux events, and are not specific to
the BIG-IP system.
◆
Packet filter events
Packet filter messages are those that result from the implementation of
packet filters and packet-filter rules.
◆
Local traffic events
Local-traffic event messages pertain specifically to the local traffic
management system.
◆
Audit events
Audit event messages are those that the BIG-IP system logs as a result of
changes to the BIG-IP system configuration. Logging audit events is
optional.
To configure and manage event logging, log in to the BIG-IP Configuration
utility, and on the Main tab, expand System, and click Logs.
Summarizing logging features
The logging mechanism on a BIG-IP system includes several features
designed to keep you informed of system events in the most effective way
possible:
BIG-IP® TMOS®: Concepts
◆
One of the primary features of the logging feature is its ability to log
different types of events, ranging from Linux system events, to packet
filtering events, to local traffic events. Through the BIG-IP system
auditing feature, you can even track and report changes that users make
to the BIG-IP system configuration, such as adding a virtual server. For
more information, see Understanding log content, on page 14-2, and
Understanding log types, on page 14-5.
◆
When setting up logging on the BIG-IP system, you can customize the
logs by designating the minimum severity level, or log level, that you
want the BIG-IP system to report when a type of event occurs. The
minimum log level indicates the minimum severity level at which the
BIG-IP system logs that type of event. For example, you can specify that,
14 - 1
Chapter 14
for any change a user makes to the bigdb database, the minimum severity
level for which the BIG-IP system logs messages is Warning. This means
that the BIG-IP system logs Warning and more severe messages such as
Error and Critical messages, but not less severe ones such as Notice,
Informational, or Debug messages. For more information, see Setting log
levels, on page 14-8.
◆
You can also use the Configuration utility to search for a string within a
log event, that is, filter the display of the log messages according to the
string you provide. For more information, see Viewing and filtering log
messages, on page 14-3.
◆
You can view historical logs using the Traffic Management shell (tmsh).
For more information, see the Traffic Management Shell (tmsh)
Reference Guide.
◆
You can implement HTTP request logging, For more information, see
the HTTP Request Logging profile from within BIG-IP® Local Traffic
ManagerTM.
◆
Finally, you can log BIG-IP system events to a remote logging server.
You do this by identifying the IP address or host name of the remote
logging server, and creating an encrypted network connection, or tunnel,
for sending log information to that remote server.
Tip
You can also configure the system to send email or activate pager
notification based on the priority of the logged event.
Understanding log content
The logs that the BIG-IP system generates include several types of
information. For example, some logs show a timestamp, host name, and
service for each event. Moreover, logs sometimes include a status code,
while the audit log shows a user name and a transaction ID corresponding to
each configuration change. All logs contain a 1-line description of each
event.
Table 14.1 lists the categories of information contained in the logs and the
specific logs in which the information is displayed.
Information Type
Explanation
Log Type
Timestamp
The time and date that the system logged the event message.
System
Packet Filter
Local Traffic
Audit
Host name
The host name of the system that logged the event message.
Because this is typically the host name of the local machine, the
appearance of a remote host name could be of interest.
System
Packet Filter
Local Traffic
Table 14.1 Log information categories and their descriptions
14 - 2
Event Logging
Information Type
Explanation
Log Type
Service
The service that generated the event.
System
Packet Filter
Local Traffic
Status code
The status code associated with the event. Note that only events
logged by BIG-IP system components, and not Linux system
services, have status codes.
Packet Filter
Local Traffic
Description
The description of the event that caused the system to log the
message.
System
Packet Filter
Local Traffic
User Name
The name of the user who made the configuration change.
Audit
Transaction ID
The identification number of the configuration change.
Audit
Event
A description of the configuration change that caused the system
to log the message.
Audit
Table 14.1 Log information categories and their descriptions
Viewing and filtering log messages
Use the Configuration utility for an easy way to view the log files that the
system generates. You can also control which messages the Configuration
utility displays, by typing a search string.
Note
An alternate way to view and filter log messages is to use tmsh. For more
information, see the Traffic Management Shell (tmsh) Reference Guide.
BIG-IP® TMOS®: Concepts
14 - 3
Chapter 14
Viewing standard log messages
On the BIG-IP system, you can use the Configuration utility to view
standard system, packet filter, local traffic, or audit messages.
To view standard log messages
1. On the Main tab of the navigation pane, expand System, and click
Logs.
The Logs screen opens.
2. On the menu bar, click System, Packet Filter, Local Traffic, or
Audit, depending on the type of log messages you want to view.
This displays a list of this type of log message.
3. If you want to advance to another screen of messages, first locate
the page list at the lower-right corner of the screen. You can either:
• Display the list and select a page number or Show All.
• Click the right arrow to advance to the next page of messages.
Expanding codes in log messages
The BIG-IP system log messages contain codes that provide information
about the system. You can run the Linux zcat command at the system
prompt to expand the codes in log messages to provide more information. In
Figure 14.1, the bold text is the expansion of the log code 012c0012.
Jun 14 14:28:03 sccp bcm56xxd [ 226 ] : 012c0012 : (Product=BIGIP Subset=BCM565XXD) : 6: 4.1 rx [ OK 171009
Bad 0 ] tx [ OK 171014 Bad 0 ]
Figure 14.1 Example of an expanded code in a log message
To expand a code in a log message
At the BIG-IP system prompt, type the Linux zcat command, using this
syntax:
zcat /var/log/<log_file> | bigcodes | less
For example, the following command sequences show two ways to expand a
code in a local traffic log message:
zcat /var/log/ltm | bigcodes | less
zcat /var/log/ltm.1.gz | bigcodes | less
The system displays the log file with the codes expanded.
Viewing historical log files
You can view log files for a specific range of dates. To do this, you use the
show log command within the sys module of the Traffic Management shell
(tmsh). For more information, see the Traffic Management Shell (tmsh)
Reference Guide.
14 - 4
Event Logging
Viewing the command audit log
You can view the command audit log by date range, using the Traffic
Management shell (tmsh). For more information, see the Traffic
Management Shell (tmsh) Reference Guide.
Filtering log messages
By supplying a text string, you can filter the log messages to suit your needs.
To filter log messages based on a search string
1. On the Main tab of the navigation pane, expand System, and click
Logs.
The Logs screen opens.
2. On the menu bar, click System, Packet Filter, Local Traffic, or
Audit, depending on the type of log messages you want to view.
This displays log messages of the type you selected.
3. In the Search box (directly above the Timestamp column), type a
string, optionally using the asterisk as a wildcard character.
4. Click Search.
This displays only those messages containing the string you
specified.
Understanding log types
As described in Introducing BIG-IP system logging, on page 14-1, the
BIG-IP system automatically logs four main event types: system, packet
filter, local traffic, and configuration changes (audit). Each type of event is
stored 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.
BIG-IP® TMOS®: Concepts
14 - 5
Chapter 14
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 system messages.
Table 14.2 shows some sample system log entries.
Timestamp
Host
Service
Event
Mon Feb 14 03:34:45 PST 2005
bigip3
syslog-ng[5494]
new configuration initialized
Mon Feb 14 03:35:06 PST 2005
bigip3
syslog-ng[5494]
kjournald starting. Commit interval 5
seconds.
Mon Feb 14 04:38:06 PST 2005
bigip3
EXT3-fs
mounted filesystem with ordered data
mode.
Table 14.2 Sample system log entries
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 file
/var/log/pktfilter.
Using the Configuration utility, you can display these packet filter
messages.
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 file /var/log/ltm.
Using the Configuration utility, you can display these local-traffic messages.
Table 14.3 shows some sample local-traffic log entries.
Timestamp
Host
Service
Status
Code
Event
Mon Feb 14 03:34:45 PST 2005
bigip2
bcm56xxd(785)
00010013
Starting packet registry event timer
Mon Feb 14 03:35:06 PST 2005
bigip2
bcm56xxd(785)
00010013
Starting HA heartbeat timer tick
Mon Feb 14 04:38:06 PST 2005
bigip2
bcm56xxd(785)
00010013
Successful start. Entering main
message loop
Mon Feb 14 o4:36:06 PST 2005
bigip2
bcm56xxd(785)
00010012
Link 2.5 is up
Table 14.3 Sample local-traffic log entries
14 - 6
Event Logging
Some of the specific types of events that the BIG-IP system displays on the
Local Traffic logging screen are:
• Address Resolution Protocol (ARP) packet and ARP cache events
• bigdb database events (such as populating and persisting bigdb variables)
• HTTP protocol events
• HTTP compression events
• IP packet discard events due to exceptional circumstances or invalid
parameters (such as a bad checksum)
• Layer 4 events (events related to TCP, UDP, and Fast L4 processing)
• MCP/TMM configuration events
• Monitor configuration events
• Network events (Layers 1 and 2)
• Packet Velocity® ASIC (PVA) configuration events
• iRule events related to run-time iRule processing
• SSL traffic processing events
• General TMM events such as TMM startup and shutdown
Note
For information on setting a minimum log level on each of these event types,
see Setting log access, on page 14-8.
Auditing configuration changes
Audit logging is an optional feature that logs messages whenever a BIG-IP
system object, such as a virtual server or a load balancing pool, is
configured (that is, created, modified, or deleted).
The BIG-IP system logs the messages for these auditing events in the file
/var/log/ltm.
Using the Configuration utility, you can display audit log messages. Table
14.4 shows a sample audit log entry. This example shows that user janet
enabled the audit logging feature.
Timestamp
User Name
Transaction ID
Event
Mon Feb 14 03:34:45 PST 2005
janet
79255-1
DB_VARIABLE modified:
name="config.auditing"
Table 14.4 Sample audit log entries
BIG-IP® TMOS®: Concepts
14 - 7
Chapter 14
There are three ways that objects can be configured:
• By user action
• By system action
• By loading configuration data
Whenever an object is configured in one of these ways, the BIG-IP system
logs a message to the audit log.
Setting log levels
Using the Configuration utility, you can set log levels on both local traffic
and auditing events. For each type of local traffic event, you can set a
minimum log level. The minimum log level indicates the minimum severity
level at which the BIG-IP system logs that type of event. For more
information, see Setting log access, following.
For auditing events, you can set a log level that indicates the type of event
that the system logs, such as the user-initiated loading of BIG-IP system
configurations, or system-initiated configuration changes. For more
information, see Setting log levels for auditing events, on page 14-10.
Note
An alternate way to set log levels is to use tmsh. For more information, see
the Traffic Management Shell (tmsh) Reference Guide.
Setting log access
You can control a user’s access to the logs by setting the user’s user role to
either Allow or Deny. On the Main tab, expand System, click Logs, and on
the menu bar, click Options.
Setting log levels for local traffic events
For local traffic events, you can set a minimum log level. Thus, for different
kinds of local traffic events, such as bigdb configuration events or events
related to HTTP compression, you can set different minimum log levels.
The log levels that you can set on certain types of events, ordered from
highest severity to lowest severity, are:
• Emergency
• Alert
• Critical
• Error
• Warning
14 - 8
Event Logging
• Notice
• Informational
• Debug
For example, if you set the minimum log level for bigdb events to Error,
then the system only logs messages that have a severity of Error or higher
for those events. If you retain the default minimum log level
(Informational), then the system logs all messages that have a severity of
Informational or higher (that is, all messages except Debug messages).
There are many different types of local traffic events for which you can set a
minimum log level. Table 14.5, on page 14-9, shows the types of local
traffic events and the minimum log levels that you can configure for them.
Because not all log levels are available for every local-traffic event type, the
table shows the specific log levels you can set on each event type. Following
the table is the procedure for setting the minimum log level on a local traffic
event type.
Local-Traffic Event Type
Available Minimum Log Levels
Default Value
ARP/NDP
Error, Warning, Notice, Informational, Debug
Warning
HTTP
Error, Debug
Error
HTTP Compression
Error, Debug
Error
IP
Warning, Notice
Warning
Layer 4
Notice, Informational, Debug
Notice
MCP
Emergency, Alert, Critical, Error, Warning, Notice, Informational,
Debug
Notice
Network
Critical, Error, Warning, Notice, Informational, Debug
Warning
Packet Velocity® ASIC
Informational, Debug
Informational
iRules®
Error, Informational, Debug
Informational
SSL
Error, Warning
Warning
Traffic Management OS
Emergency, Critical, Error, Notice, Informational
Notice
LIND
Emergency, Alert, Critical, Error, Warning, Notice, Informational,
Debug
Notice
CSYNCD
Emergency, Alert, Critical, Error, Warning, Notice, Informational,
Debug
Notice
CLUSTERD
Emergency, Alert, Critical, Error, Warning, Notice, Informational,
Debug
Notice
Table 14.5 Local-traffic event types and their available log levels
BIG-IP® TMOS®: Concepts
14 - 9
Chapter 14
Note
For more information on local traffic event types, see Logging local traffic
events, on page 14-6.
Setting log levels for auditing events
An optional type of logging that you can enable is audit logging. Audit
logging logs messages that pertain to configuration changes that users or
services make to the BIG-IP system configuration. This type of audit
logging is known as MCP audit logging. (For more information, see
Auditing configuration changes, on page 14-7.) 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 one of four log
levels. In this case, the log levels do not affect the severity of the log
messages; instead, they affect the initiator of the audit event.
The log levels for MCP and tmsh audit logging are:
◆
Disable
This turns audit logging off. This is the default value.
◆
Enable
This causes the system to log messages for user-initiated configuration
changes only.
◆
Verbose
This causes the system to log messages for user-initiated configuration
changes and any loading of configuration data.
◆
Debug
This causes the system to log messages for all user-initiated and
system-initiated configuration changes.
Note
For more information on local traffic event types, see Logging local traffic
events, on page 14-6.
Viewing and searching the audit log
You can view the contents of the audit log, or you can search an audit log
based on user name, time period, or specific content.
On the Main tab, expand System, click Logs, and on the menu bar, click
Audit.
14 - 10
Event Logging
Configuring encrypted remote logging
You can configure the syslog-ng utility on the BIG-IP system to send
BIG-IP system log information to a remote logging host, using an encrypted
network connection. To do this, you create a port-forwarding SSH tunnel to
the remote logging host, and configure the syslog-ng utility on the BIG-IP
system to send log messages through the SSH tunnel.
Before you begin
Before you attempt to configure encrypted remote logging, you must meet
the following conditions on the BIG-IP system and your remote logging
host:
◆
On the BIG-IP system
You must have a console with root access to the BIG-IP system.
◆
On the remote logging host
You must have a console with root access to the remote logging host, the
IP address, or the host name of the remote logging host.
◆
For both systems
You must have both systems connected to the same subnetwork.
WARNING
Attempt this configuration only if you understand the risks associated with
making changes to daemon startup scripts.
Creating the remote encrypted logging configuration
When creating an encrypted remote logging configuration, you must
complete the following tasks:
• Review the SSH syntax required to create this configuration.
• Create a unique SSH identity key to identify and authorize the BIG-IP
system.
• Edit the syslog-ng utility startup script to create and destroy the SSH
tunnels.
• Edit the remote logging host to accept syslog-ng messages through the
SSH tunnel.
• Copy the unique SSH identity key to the remote logging host and append
it to the authorized key file.
• Verify the logging configuration and restart the syslog-ng utility.
BIG-IP® TMOS®: Concepts
14 - 11
Chapter 14
Reviewing the SSH syntax required to create this configuration
This configuration requires that the BIG-IP system is able to establish an
SSH connection to the remote logging host. On the BIG-IP system, use the
ssh command to create the tunnel. Figure 14.2 is an example of the syntax
required to create an SSH tunnel.
$ ssh -L <local tunnel port>:<remote log hostname>:<remote
tunnel port> \
<remote user>@<remote log hostname> \
-nNCxf \
-i <key identity file>
Figure 14.2 Syntax to establish an SSH tunnel from the BIG-IP system
Table 14.6 contains detailed descriptions of the ssh syntax elements shown
in Figure 14.2.
SSH syntax
Description
<local tunnel port>
The port SSH listens on for connections in order to
forward them to <remote log hostname>:<remote
tunnel port>.
<remote log
hostname>
The IP address or FQDN of the remote logging server.
<remote tunnel port>
The port to which you want the SSH daemon on the
remote logging server to forward connections.
<remote user>
The user name that SSH attempts to authenticate, as
on <remote log hostname>.
<key identity file>
A file name from which the identity (private key) for
authentication is read.
Table 14.6 Detailed syntax elements for configuring SSH
Creating an SSH key to identify and authorize the BIG-IP system
After you have reviewed the ssh command syntax, use the ssh command to
create the encrypted tunnel on the BIG-IP system. You must create a unique
key on the BIG-IP system. The unique key is used to identify and authorize
the BIG-IP system to the remote logging host.
To create the file syslog_tunnel_ID and syslog_tunnel_ID.pub, use the
following command sequence:
$ ssh -b 2048 -f syslog_tunnel_ID -t rsa -N "" -P ""
To make syslog_tunnel_ID readable only by the root account, use the
following command sequence:
$ chmod 600 syslog_tunnel_ID
14 - 12
Event Logging
To make the public portion of the unique SSH ID named
syslog_tunnel_ID.pub readable by all accounts, use the following
command sequence:
$ chmod 644 syslog_tunnel_ID.pub
Copy syslog_tunnel_ID and syslog_tunnel_ID.pub into /var/ssh with the
following command:
$ cp syslog_tunnel_ID* /var/ssh
Editing the syslog-ng start script to open and close the tunnel
Next, you must change the syslog-ng utility startup script,
/etc/init.d/syslog-ng, so that the encrypted tunnel is opened when the
syslog-ng script starts up, and is closed when the script is restarted or
stopped.
Before you edit the syslog-ng utility startup script, save a backup copy to the
root directory. Use the following command to save the backup to the root
directory:
$ cp /etc/init.d/syslog-ng /root/syslog-ng.backup
After you save a backup of the syslog-ng utility startup script,
/etc/init.d/syslog-ng, edit it to automatically create SSH tunnels when the
syslog-ng utility is started, or close the SSH tunnels when the syslog-ng
utility is restarted or stopped.
The example configuration in this document demonstrates how to create a
tunnel to a host using the following IP addresses and ports:
• IP address of 10.0.0.100
• Local tunnel port of 5140
• Remote tunnel port of 5140
• User name logger on host 10.0.0.100
Start by adding syntax below the line that reads start). Figure 14.3 is an
example of what the section of the syslog-ng start script looks like after you
add the new syntax. In this example, the syntax you need to add is shown
with bold text.
start)
ssh -L 5140:10.0.0.100:5140 \
logger@10.0.0.100 -nNCxf \
-i var/ssh/syslog_tunnel_ID
echo -n "Starting $INIT_NAME: "
daemon --check $INIT_PROG "$INIT_PROG $INIT_OPTS"
Figure 14.3 The syntax to add below the start) line
BIG-IP® TMOS®: Concepts
14 - 13
Chapter 14
Next, add syntax below the line that reads stop). Figure 14.4 shows the
syntax you need to add in bold text.
stop)
for sshTunnel in \
`ps -ewo "%p!%a" | \
grep ssh | \
grep syslog_tunnel_ID | \
grep -v grep | \
cut -f 1 -d !`; do
if [ -n "$sshTunnel" -a $sshTunnel -gt 10 ]; then
echo " -- Shutting down SSH tunnel with process $sshTunnel"
kill -TERM $sshTunnel
fi
done
echo -n "Stopping $INIT_NAME: "
Figure 14.4 The syntax to add below the stop) line
Setting up message logging on a remote logging host
After you add the syntax to open and close SSH tunnels, you can modify the
configuration of the syslog-ng utility to log messages to a remote syslog-ng
server. To do this, you can use either the BIG-IP Configuration utility or the
tmsh command line interface.
Logging to a remote logging server using the Configuration
utility
1. From the Main tab, expand System, and click Logs.
2. From the Configuration menu, choose Remote Logging.
The Remote Logging screen appears.
3. In the Remote IP box, type the IP address of the remote logging
server.
4. In the Remote Port box, retain the default port number or type a
different port number.
5. In the Local IP box, type the IP address of the local BIG-IP system
that is sending the log messages.
This step is optional.
6. Click Add.
7. Repeat steps 3 through 6 for each remote logging server to which
you want the BIG-IP system to send log messages.
8. Click Update.
14 - 14
Event Logging
Logging to a remote logging server using tmsh
To send log messages to a remove logging server, use the following
command at the tmsh prompt:
modify sys syslog remote-servers add{ remotesyslog1 { host
<host> remote-port <port> local-ip <local-ip> } }
Note
The syslog-ng daemon on the local BIG-IP system automatically restarts
whenever you update the remote server configuration. This restart occurs
whether you perform the update through the Configuration utility or tmsh.
Copying the SSH identity to the remote logging host
After you have used the syslog command to set up the remote logging host
to log messages, you must copy the unique SSH identity to the remote
logging host. To do this, copy the syslog_tunnel_ID.pub identity to the
remote syslog server, and append this key to the authorized_keys file found
in the .ssh folder under the home directory of the user that you want to use
to capture remote log messages.
$ cat syslog_tunnel_ID.pub >> ~logger/.ssh/authorized_keys
Verify that the logging facility is configured and ready to receive syslog-ng
messages on the <remote tunnel port>. If the remote logging host uses the
syslog-ng utility, you need to add a source configuration block such as the
example shown in Figure 14.5.
source remote {
tcp(ip(10.0.0.100) port(5140));
};
Figure 14.5 Remote logging host source identification block
In addition to the source identification block, you also need to add filter,
destination, and log configuration blocks to use the data from the source
remote as required by your application.
Verifying the logging configuration and restarting syslog-ng
Finally, verify that the SSH connection is functional and restart the
syslog-ng utility.
To verify the configuration and restart the syslog-ng utility
1. Log on as root to the BIG-IP system.
2. Make an SSH connection to the remote logging host using the new
identity key you created.
# ssh logger@10.0.0.100 -i /var/shh/syslog_tunnel_ID
BIG-IP® TMOS®: Concepts
14 - 15
Chapter 14
If everything is configured correctly, you should be able to get shell
access to the remote logging host without being challenged for a
password. (When you add the new identity key to the remote host's
authorized_keys file, the key is used to authenticate the BIG-IP
system.)
3. Exit from the SSH session to the BIG-IP system command line.
4. Restart the syslog-ng utility by typing the following command:
$ /etc/init.d/syslog-ng restart
The BIG-IP system should now be sending log messages to your
remote host.
14 - 16
15
Interfaces
• Introduction to BIG-IP system interfaces
• Interface properties
• LLDP
• Interface statistics
• Related configuration tasks
Interfaces
Introduction to BIG-IP system interfaces
A key task of the BIG-IP® system configuration is the configuration of
BIG-IP system interfaces. The interfaces on a BIG-IP system are the
physical ports that you use to connect the BIG-IP system to other devices on
the network. These other devices can be next-hop routers, Layer 2 devices,
destination servers, and so on. Through its interfaces, the BIG-IP system can
forward traffic to or from other network devices.
Note
Throughout this guide, the term interface refers to the physical ports on the
BIG-IP system.
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, see the relevant platform guide.
A BIG-IP system has two types of interfaces:
• A management interface
The management interface is a special interface dedicated to performing
a specific set of system management functions.
• TMM switch interfaces
TMM switch interfaces are those interfaces that the BIG-IP system uses
to send or receive application traffic, that is, traffic slated for application
delivery.
Each of the interfaces on the BIG-IP system has unique properties, such as
the MAC address, media speed, duplex mode, and support for Link Layer
Discovery Protocol (LLDP).
In addition to configuring interface properties, you can implement a feature
known as interface mirroring, which you can use to duplicate traffic from
one or more interfaces to another. You can also view statistics about the
traffic on each interface.
Once you have configured the properties of each interface, you can
configure several other features of the BIG-IP system that control the way
that interfaces operate. For example, by creating a virtual local area network
(VLAN) and assigning interfaces to it, the BIG-IP system can insert a
VLAN ID, or tag, into frames passing through those interfaces. In this way,
a single interface can forward traffic for multiple VLANs.
To configure and manage BIG-IP system interfaces, log in to the BIG-IP
Configuration utility, and on the Main tab, expand Network, and click
Interfaces.
BIG-IP® TMOS®: Concepts
15 - 1
Chapter 15
About Link Layer Discovery Protocol
The BIG-IP system supports Link Layer Discovery Protocol (LLDP). LLDP
is a Layer 2 industry-standard protocol (IEEE 802.1AB) that enables a
network device such as the BIG-IP system to advertise its identity and
capabilities to multi-vendor neighbor devices on a network. The protocol
also enables a network device to receive information from neighbor devices.
LLDP transmits device information in the form of LLDP messages known
as LLDP Data Units (LLDPDUs). In general, this protocol:
◆
Advertises connectivity and management information about the local
BIG-IP device to neighbor devices on the same IEEE 802 LAN.
◆
Receives network management information from neighbor devices on the
same IEEE 802 LAN.
• Operates with all IEEE 802 access protocols and network media.
Using the BIG-IP Configuration utility or tmsh, you can configure the
BIG-IP system interfaces to transmit or receive LLDPDUs. More
specifically, you can:
◆
Specify the exact content of LLDPDUs that a BIG-IP system interface
transmits to a neighbor device. You specify this content by configuring
the LLDP Attributes setting on each individual interface.
◆
Globally specify the frequencies of various message transmittal
properties, and specify the number of neighbors from which each
interface can receive messages. These properties apply to all interfaces
on the BIG-IP system.
Figure 15.1 shows a local LLDP-enabled BIG-IP system, configured to both
transmit and receive LLDP messages from neighbor devices on a LAN.
Figure 15.1 A local BIG-IP system that transmits and receives LLDPUs
15 - 2
Interfaces
Interface properties
Each interface on the BIG-IP system has a set of properties that you can
configure, such as enabling or disabling the interface, setting the requested
media type and duplex mode, and configuring flow control. Configuring the
properties of each interface is one of the first tasks you do after running the
Setup utility on the BIG-IP system. While you can change some of these
properties, such as media speed and duplex mode, you cannot change other
properties, such as the media access control (MAC) address.
Note
You can configure STP-related properties on an interface by configuring
one of the Spanning Tree protocols.
Before configuring interface properties, it is helpful to understand interface
naming conventions.
Note
Only users with either the Administrator or Resource Administrator user
role can create and manage interfaces.
Understanding interface naming conventions
By convention, the names of the interfaces on the BIG-IP system use the
format <s>.<p> where s is the slot number of the network interface card
(NIC), and p is the port number on the NIC. Examples of interface names
are 1.1, 1.2, and 2.1. BIG-IP system interfaces already have names assigned
to them; you do not explicitly assign them.
An exception to the interface naming convention is the management
interface, which has the special name MGMT.
Viewing interface information and media properties
Using the Configuration utility, you can display a screen that lists all of the
BIG-IP system interfaces, as well as their current status (UP or DOWN).
You can also view other information about each interface:
• MAC address of the interface
• Interface availability
• Media type
• Media speed
• Active mode (such as full)
BIG-IP® TMOS®: Concepts
15 - 3
Chapter 15
This information is useful when you want to assess the way that a particular
interface is forwarding traffic. For example, you can use this information to
determine the specific VLANs for which an interface is currently
forwarding traffic. You can also use this information to determine the speed
at which an interface is currently operating.
Interface state
You can either enable or disable an interface on the BIG-IP system. By
default, each interface is set to Enabled, where it can accept ingress or
egress traffic. When you set the interface to Disabled, the interface cannot
accept ingress or egress traffic.
Fixed Requested Media
The Fixed Requested Media property shows that the interface auto-detects
the duplex mode of the interface.
Flow control
You can configure the Flow Control property to manage the way that an
interface handles pause frames for flow control. Pause frames are frames
that an interface sends to a peer interface as a way to control frame
transmission from that peer interface. Pausing a peer’s frame transmissions
prevents an interface’s First-in, First-out (FIFO) queue from filling up and
resulting in a loss of data. Possible values for this property are:
◆
Pause None
Disables flow control.
◆
Pause TX/RX
Specifies that the interface honors pause frames from its peer, and also
generates pause frames when necessary. This is the default value.
◆
Pause TX
Specifies that the interface ignores pause frames from its peer, and
generates pause frames when necessary.
◆
Pause RX
Specifies that the interface honors pause frames from its peer, but does
not generate pause frames.
LLDP
The LLDP property is one of two properties related to LLDP that you can
configure for a specific interface. The possible values for this setting are:
• Disabled
When set to this value, the interface neither transmits (sends) LLDP
messages to nor receives LLDP messages from neighboring devices.
15 - 4
Interfaces
• Transmit Only
When set to this value, the interface transmits LLDP messages to
neighbor devices but does not receive LLDP messages from neighbor
devices.
• Receive Only
When set to this value, the interface receives LLDP messages from
neighbor devices but does not transmit LLDP messages to neighbor
devices.
• Transmit and Receive
When set to this value, the interface transmits LLDP messages to and
receives LLDP messages from neighboring devices.
LLDP Attributes
The LLDP Attributes setting is one of two settings related to LLDP that
you can configure for a specific interface. You use this interface setting to
specify the content of an LLDP message being sent or received. Each LLDP
attribute that you specify with this setting is optional and is in the form of
Type, Length, Value (TLV).
Table l15.1 lists and describes the optional TLVs that the interface can send
or receive in an LLDP message. Note that there are three mandatory TLVs,
which are not listed here: Chassis ID, Port ID, and Time-to-Live (TTL).
Port Description
Contains an alpha-numeric string that describes the interface. If RFC 2863 is implemented,
use the ifDescr object for this field.
System Name
Contains an alpha-numeric string that indicates the system’s administratively-assigned
name. The system name should be the system’s fully qualified domain name (FQDN). If
implementations support IETF RFC 3418, use the sysName object for this field.
System Description
Contains an alpha-numeric string that is the textual description of the network entity. The
system description should include the full name and version identification of the system's
hardware type, software operating system, and networking software. If implementations
support IETF RFC 3418, use the sysDescr object for this field.
System Capabilities
Identifies the primary functions of the system and whether these primary functions are
enabled. This field is optional.
Management Address
Identifies an address associated with the local LLDP agent used to reach higher layer
entities, to assist discovery by network management. This TLV also provides room for the
inclusion of the system interface number that is associated with this management address,
if known.
Port VLAN ID
(untagged VLAN ID)
Allows a VLAN bridge port to advertise the port’s VLAN identifier (PVID) that is associated
with untagged or priority tagged frames (see IEEE 802.1Q-1998, 8.4.4). This field is an
optional, fixed-length TLV.
Table 15.1 Optional LLDP TLVs for an interface
BIG-IP® TMOS®: Concepts
15 - 5
Chapter 15
Port and protocol VLAN
ID
Allows a bridge port to advertise a port and protocol VLAN ID. The port and protocol VLAN
ID field shall contain the PPVID number for this IEEE 802 LAN station. If the port is not
capable of supporting port and protocol VLANs and/or the port is not enabled with any port
and protocol VLAN, the PPVID number should be zero. This field is optional.
VLAN Name (complete
list of tagged/untagged
VLANs)
Allows an IEEE 802.1Q-compatible IEEE 802 LAN station to advertise the assigned name
of any VLAN with which it is configured. The VLAN name field must contain the VLAN’s
name. If implementations support IETF RFC 2674, use the dot1QVLANStaticName object
for this field. This field is optional.
Protocol Identify
Allows an IEEE 802 LAN station to advertise particular protocols that are accessible
through the port. The protocol identity field must contain the first n octets of the protocol
after the Layer 2 addresses (for example, starting with the Ethertype field) that the sender
needs to advertise. The value of n is determined by the need for the protocol to
disambiguate itself. The protocol information string must include enough octets to allow the
receiver to correctly identify the protocol and its version. To advertise Spanning Tree
protocols, for example, the Protocol Identity field must include at least eight octets: IEEE
802.3 length (two octets), LLC addresses (two octets), IEEE 802.3 control (one octet),
Protocol ID (two octets), and the protocol version (one octet). This field is optional.
MAC/PHY
Configuration Status
Identifies the following information:
Link Aggregation
Contains a bit map of the link aggregation capabilities and the current aggregation status of
the link.
Maximum Frame Size
Indicates the maximum frame size capability of the implemented MAC and PHY. The
maximum frame size field must contain an integer value indicating the maximum supported
frame size in octets, as determined by the following:
• The duplex and bit-rate capability of the sending IEEE 802.3 LAN node that is connected
to the physical medium.
• The current duplex and bit-rate settings of the sending IEEE 802.3 LAN node.
• Whether these settings are the result of auto-negotiation during link initiation or of manual
set override action.
This field is optional.
• If the MAC/PHY supports only the basic MAC frame format as defined in 3.1.1 of IEEE
Std 802.3-2002, set the maximum frame size field to 1518.
• If the MAC/PHY supports an extension of the basic MAC frame format for tagged MAC
frames as defined in IEEE 802.3-2002, set the maximum frame size field to 1522.
• If the MAC/PHY supports an extension of the MAC frame format that is different from
either of the above, set the maximum frame size field to the maximum value supported.
Product model
[TBD]
Table 15.1 Optional LLDP TLVs for an interface
15 - 6
Interfaces
Interface mirroring
For reliability reasons, you can configure a feature known as interface
mirroring. When you configure interface mirroring, you cause the BIG-IP
system to copy the traffic on one or more interfaces to another interface that
you specify. By default, the interface mirroring feature is disabled.
The settings you configure to implement the interface mirroring feature are
shown in Table 15.2.
Setting
Description
Interface Mirroring
State
Enables or disables interface mirroring.
Destination Interface
Specifies the interface on which traffic from other
interfaces is to be mirrored.
Mirrored Interfaces
Specifies one or more interfaces for which you want to
mirror traffic on the destination interface.
Table 15.2 Configuration settings for enabling interface mirroring
BIG-IP® TMOS®: Concepts
15 - 7
Chapter 15
LLDP
In addition to the LLDP-related settings that you can configure per interface,
you can configure some global LLDP settings that apply to all interfaces on
the system.
Moreover, you can view statistics pertaining to any neighbor devices that
have transmitted LLDP messages to the local BIG-IP system.
To configure these settings using the BIG-IP Configuration utility, locate
the Main tab, expand Network, and click Interfaces. Then from the LLDP
menu item, choose General or Neighbors.
General settings
To control the frequency of LLDP messages, you can configure the
following settings. Note that these settings are global settings that apply to
all interfaces on the system.
Table 15.3 lists and describes general settings that apply to all
LLDP-enabled interfaces on the BIG-IP system.
LLDP
The control to enable or disable LLDP for all interfaces
on the BIG-IP system. The default value is Disabled.
Message Transmit
Interval
The interval in seconds between successive transmit
cycles.
Message Transmit Hold
A multiplier on the value of the Message Transmit
Interval setting, used to compute the TTL value of
txTTL.
Reinit Delay
The delay in seconds, after adminStatus becomes
disable, before re-initialization is attempted.
Transmit Delay
The minimum delay in seconds between successive
LLDP frame transmissions.
Maximum Neighbors
per Port
The maximum number of neighbors from which each
interface can receive messages. If the BIG-IP receives
messages from more than 10 neighbors on one port,
the system discards the messages, thus protecting the
system from flooding (whether accidental or malicious)
Table 15.3 LLDP settings that apply to all LLDP-enabled interfaces
15 - 8
Interfaces
Neighbor settings
When a BIG-IP system interface receives LLDP messages from neighbor
devices, the BIG-IP system displays chassis, port, and system information
about the content of those messages. Specifically, the system displays values
for the standard TLVs for each neighbor. These TLVs are:
• Chassis ID
Identifies the chassis containing the IEEE 802 LAN station associated
with the transmitting LLDP agent.
• Port ID
Identifies the port component of the media service access point (MSAP)
identifier associated with the transmitting LLDP agent.
• Port description
An alpha-numeric string that describes the interface.
• System name
An alpha-numeric string that indicates the administratively-assigned
name of the neighbor device.
• System description
An alpha-numeric string that is the textual description of the network
entity. The system description should include the full name and version
identification of the hardware type, software operating system, and
networking software of the neighbor device.
• System capabilities
The primary functions of the system and whether these primary functions
are enabled.
• Management address
An address associated with the local LLDP agent used to reach higher
layer entities. This TLV might also include the system interface number
that is associated with the management address, if known.
Note that you can use the Auto Refresh setting to either automatically or
manually refresh TLV information that the BIG-IP system receives from
neighbor devices.
BIG-IP® TMOS®: Concepts
15 - 9
Chapter 15
Interface statistics
You can display a variety of statistics about the interfaces on the BIG-IP
system.
Tip
For descriptions of each type of statistic, see the online help.
Related configuration tasks
After you have configured the interfaces on the BIG-IP system, one of the
primary tasks you perform is to assign those interfaces to the virtual LANs
(VLANs) that you create. A VLAN is a logical subset of hosts on a local
area network (LAN) that reside in the same IP address space. When you
assign multiple interfaces to a single VLAN, traffic destined for a host in
that VLAN can travel through any one of these interfaces to reach its
destination. Conversely, when you assign a single interface to multiple
VLANs, the BIG-IP system can use that single interface for any traffic that
is intended for hosts in those VLANs.
Another powerful feature that you can use for BIG-IP system interfaces is
trunking, with link aggregation. A trunk is an object that logically groups
physical interfaces together to increase bandwidth. Link aggregation,
through the use of the industry-standard Link Aggregation Control Protocol
(LACP), provides regular monitoring of link status, as well as failover if an
interface becomes unavailable.
Finally, you can configure your BIG-IP system interfaces to work with one
of the spanning tree protocols (STP, RSTP, and MSTP). Spanning tree
protocols reduce traffic on your internal network by blocking duplicate
routes to prevent bridging loops. Chapter 20, Spanning Tree Protocols,
describes the spanning tree protocols and the procedure for configuring
these protocols on the BIG-IP system. The chapter also includes information
on setting spanning tree-related properties on individual interfaces.
15 - 10
16
Self IP Addresses
• Introduction to self IP addresses
• Types of self IP addresses
• Self IP addresses and MAC addresses
• Self IP addresses for SNATs
• Self IP address properties
Self IP Addresses
Introduction to 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 an address space, that is, 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:
• First, when sending a message to a destination server, the BIG-IP system
uses the self IP addresses of its VLANs to determine the specific VLAN
in which a destination server resides. For example, if VLAN internal 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 server’s IP
address falls within the range of VLAN internal’s self IP address, and
therefore sends the message to that VLAN. More specifically, 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.
• Second, a self IP address can serve as the default route for each
destination server in the corresponding VLAN. In this case, 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.
You normally assign self IP addresses to a VLAN when you initially run the
Setup utility on a BIG-IP system. More specifically, you assign one static
self IP address and one floating self IP address to each of the default VLANs
(internal and external). Later, using the Configuration utility, you can
create self IP addresses for other VLANs that you create.
Self IP addresses reside in administrative partitions/folders and are
associated with traffic groups. The self IP addresses that you create when
you run the Setup utility reside in partition Common (that is folder
/Common).
To configure and manage self IP addresses, log in to the BIG-IP
Configuration utility, and on the Main tab, expand Network, and click Self
IPs.
BIG-IP® TMOS®: Concepts
16 - 1
Chapter 16
Types of self IP addresses
There are two types of self IP addresses that you can create:
• A static self IP address is an IP address that the BIG-IP system does not
share with another BIG-IP system. Any self IP address that you assign to
the default traffic group traffic-group-local-only is a static self IP
address.
• A floating self IP address is an IP address that two BIG-IP systems
share. Any self IP address that you assign to the default traffic group
traffic-group-1 is a floating self IP address.
Self IP addresses and MAC addresses
For each self IP address that you create for a VLAN, the BIG-IP system
automatically assigns a media access control (MAC) address. By default, the
BIG-IP system assigns the same MAC address that is assigned to the
lowest-numbered interface of the VLAN.
As an alternative, you can globally configure the BIG-IP system to assign
the same MAC address to all VLANs. This feature is useful if your network
includes a type of switch that does not keep a separate Layer 2 forwarding
table for each VLAN on that switch.
To configure a global MAC address for VLANs, log in to the BIG-IP
Configuration utility, and on the Main tab, expand System, click
Configuration, and click Local Traffic.
Self IP addresses for SNATs
When you configure the BIG-IP system to manage local area traffic, you can
implement a feature known as a secure network address translation (SNAT).
A SNAT is an object that causes the BIG-IP system to translate the original
source IP address of a packet to an IP address that you specify. A SNAT
ensures that the target server sends its response back through the BIG-IP
system rather than to the original client IP address directly.
When you create a SNAT, you can configure the BIG-IP system to
automatically choose a translation address. This ability of the BIG-IP
system to automatically choose a translation address is known as SNAT
automapping, and in this case, the translation address that the system
chooses is always an existing self IP address. Thus, for traffic going from
the BIG-IP system to a destination server, configuring SNAT automapping
ensures that the source IP address in the header of a packet is a self IP
address.
When you create an automapped SNAT, the BIG-IP system actually creates
a SNAT pool consisting of the system’s internal self IP addresses, and then
uses an algorithm to select and assign an address from that SNAT pool.
16 - 2
Self IP Addresses
Self IP address properties
As stated previously, it is when you initially run the Setup utility on a
BIG-IP system that you normally create any static and floating self IP
addresses and assign them to VLANs. However, if you want to create
additional self IP addresses later, you can do so using the Configuration
utility.
Note
Only users with either the Administrator or Resource Administrator user
role can create and manage self IP addresses.
Note
A self IP address can be in either IPv4 or IPv6 format.
IP address
As described in Introduction to self IP addresses, on page 16-1, a self IP
address, combined with a netmask, typically represents a range of host IP
addresses in a VLAN. If you are assigning a self IP address to a VLAN
group, the self IP address represents the range of self IP addresses assigned
to the VLANs in that group.
Netmask
When you specify a netmask for a self IP address, the self IP address can
represent a range of IP addresses, rather than a single host address. For
example, a self IP address of 10.0.0.100 can represent several host IP
addresses if you specify a netmask of 255.255.0.0.
VLAN/Tunnel assignment
You assign a unique self IP address to a specific VLAN or a VLAN group:
BIG-IP® TMOS®: Concepts
◆
Assigning a self IP address to a VLAN
The self IP address that you assign to a VLAN should represent an
address space that includes the self IP addresses of the hosts that the
VLAN contains. For example, if the address of one destination server in
a VLAN is 10.0.0.1 and the address of another server in the VLAN is
10.0.0.2, you could assign a self IP address of 10.0.0.100, with a netmask
of 255.255.0.0, to the VLAN.
◆
Assigning a self IP address to a VLAN group
The self IP address that you assign to a VLAN group should represent an
address space that includes the self IP addresses of the VLANs that you
assigned to the group. For example, if the self IP address of one VLAN
in a VLAN group is 10.0.20.100 and the address of the other VLAN in a
VLAN group is 10.0.30.100,you could assign an address of 10.0.0.100,
with a netmask of 255.255.0.0, to the VLAN group.
16 - 3
Chapter 16
The VLAN/Tunnel list in the BIG-IP Configuration utility displays the
names of all existing VLANs and VLAN groups.
Port lockdown
Each self IP address has a feature known as port lockdown. Port lockdown
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)
If you do not want to use the default setting (Allow Default), you can
configure port lockdown to allow either all UDP and TCP protocols and
services (Allow All), no UDP protocols and services (Allow None), or only
those that you specify (Allow Custom).
Traffic groups
If you want the self IP address to be a floating IP address, that is, an address
shared between two or more BIG-IP devices in a device group, you can
assign a floating traffic group to the self IP address. A floating traffic group
causes the self IP address to become a floating self IP address.
A floating self IP address ensures that application traffic reaches its
destination. More specifically, a floating self IP address enables a source
node to successfully send a request, and a destination node to successfully
send a response, when the relevant BIG-IP device is unavailable.
If you want the self IP address to be a static (non-floating) IP address (used
mostly for standalone devices), you can assign a non-floating traffic group
to the self IP address. A non-floating traffic group causes the self IP
address to become a non-floating self IP address. An example of a
non-floating self IP address is the address that you assign to the default
VLAN named HA, which is used strictly to process failover
communications between BIG-IP devices, instead of processing application
traffic.
16 - 4
17
Traffic Groups
• Traffic group overview
• Types of traffic groups
• For more information
Traffic Groups
Traffic group overview
A traffic group is a collection of related configuration objects that run on a
BIG-IP device. Together, these objects process a particular type of traffic on
that device. When a BIG-IP device becomes unavailable, a traffic group can
float to another device in a device group to ensure that the traffic for that
application continues to be processed with little to no interruption in service.
In general, a traffic group ensures that when a device becomes unavailable,
all of the failover objects in the traffic group fail over to any one of the
devices in the device group, based on the current workload of those devices.
Only certain types of configuration objects can belong to a traffic group.
Examples of traffic group objects are floating self IP addresses and floating
virtual IP addresses.
Another example of a type of object in a traffic group is an iAppsTM
application service. If a device with this traffic group is a member of a
device group and the device becomes unavailable, the traffic group floats, or
fails over, to another member of the device group, and that member
becomes the device that processes the application traffic.
When a traffic group fails over to another device in the device group, the
device that the system selects to run the traffic group is normally the device
that is most available from a workload perspective. However, when you
initially create the traffic group on a device, you can specify the device in
the group that you prefer that traffic group to run on whenever possible.
Note
You can assign a unique MAC masquerade address to each traffic group
that you create. Assigning a MAC masquerade address reduces the risk of
dropped connections or additional ARP messages during failover.
Types of traffic groups
There are two types of traffic groups, floating and non-floating:
◆
A default floating traffic group exists on every BIG-IP device. With a
floating traffic group, the associated failover objects float to another
device in a Sync-Failover device group whenever the device becomes
unavailable. Every BIG-IP device contains a default floating traffic
group named traffic-group-1 that contains all eligible configuration
objects. Configuration objects that belong to a floating traffic group are
known as failover objects.
Note
Whenever you assign a floating traffic group to a self IP address, a virtual
IP address, or a SNAT translation address, those addresses become floating
addresses.
BIG-IP® TMOS®: Concepts
17 - 1
Chapter 17
◆
A default non-floating traffic group named traffic-group-local-only
exists on every BIG-IP device. With a non-floating traffic group, the
associated configuration objects do not float because the device is not
part of a device group.
Note
Whenever you assign a non-floating traffic group to a self IP address, a
virtual IP address, or a SNAT translation address, those addresses become
non-floating addresses.
For more information
To configure and manage traffic groups, log in to the BIG-IP Configuration
utility, and on the Main tab, expand Network, and click Traffic Groups.
For detailed information on traffic groups and device groups, see the
BIG-IP® Redundant Systems Configuration Guide.
17 - 2
18
Packet Filters
• Introduction to packet filtering
• Global settings
• Packet filter rules
Packet Filters
Introduction to packet filtering
Packet filters enhance network security by specifying whether a BIG-IP®
system interface should accept or reject certain packets based on criteria that
you specify. Packet filters enforce an access policy on incoming traffic.
They apply to incoming traffic only.
You implement packet filtering by creating packet filter rules, using the
BIG-IP® Configuration utility. The primary purpose of a packet filter rule is
to define the criteria that you want the BIG-IP system to use when filtering
packets. Examples of criteria that you can specify in a packet filter rule are:
• The source IP address of a packet
• The destination IP address of a packet
• The destination port of a packet
You specify the criteria for applying packet filter rules within an expression.
When creating a packet filter rule, you can instruct the BIG-IP system to
build an expression for you, in which case you need only choose the criteria
from predefined lists, or you can write your own expression text, using the
syntax of the tcpdump utility. For more information on the tcpdump utility,
see the online man page for the tcpdump command.
Note
Packet filter rules are unrelated to iRules®.
You can also configure global packet filtering that applies to all packet filter
rules that you create. The following sections describe how to use the
Configuration utility to set global packet filtering options, as well as create
and manage individual packet filters rules.
To configure and manage packet filtering, log in to the BIG-IP
Configuration utility, and on the Main tab, expand Network, and click
Packet Filters.
BIG-IP® TMOS®: Concepts
18 - 1
Chapter 18
Global settings
Global settings for packet filtering are divided into two categories:
Properties and Exemptions. The BIG-IP system applies global settings to all
packets coming into the BIG-IP system.
Important
Note that one of the global settings, Packet Filtering, enables packet
filtering. When you disable this setting, no packet filter settings or packet
filter rules operate, and the BIG-IP system allows all traffic by default.
Global properties
You can configure three specific global properties for packet filtering.
Packet filter enabling
Before you can implement packet filtering on the BIG-IP system, you must
enable the packet filter feature. You do this by changing the Packet
Filtering setting to Enabled. The default setting for packet filtering is
Disabled.
Control of unhandled packets
Sometimes a packet does not match any of the criteria that you have
specified in the packet filter rules that you have created. For this reason, you
must configure the Unhandled Packet Action property, which specifies the
action that the BIG-IP system should take when the packet does not match
packet filter rule criteria.
Possible values for this setting are Accept, Discard, and Reject. The default
value is Accept.
WARNING
Changing the default value of the Unhandled Packet Action property can
produce unwanted consequences. Before changing this value to Discard or
Reject, make sure that any traffic that you want the BIG-IP system to accept
meets the criteria specified in your packet filter rules.
Other options
Using the Options property, you can configure two other options:
◆
18 - 2
Filter established connections
When you enable (check) this option, the BIG-IP system filters all
ingress packets, even if the packets are part of an existing connection.
The default setting is disabled (unchecked). Note that checking this
option does not typically enhance security, and can impact system
performance.
Packet Filters
◆
Send ICMP error on packet reject
When you enable (check) this option, the system sends, an ICMP type 3
(destination unreachable), code 13 (administratively prohibited) packet
when an ingress packet is rejected. When you disable (uncheck) this
option, the BIG-IP system sends an ICMP reject packet that is
protocol-dependent. The default setting for this option is disabled
(unchecked).
Global exemptions
There are a number of exemptions you can set for packet filtering. When
filtering packets, the BIG-IP system always applies these exemptions,
effectively overriding certain criteria you might have previously set within
an individual packet filter rule.
Protocols
With the Protocols setting, you can specify whether ARP and certain ICMP
messages are exempt from packet filtering. The individual settings are:
◆
Always accept ARP
When you enable (check) this setting, the system automatically accepts
all ARP packets and therefore does not subject them to packet filtering.
The default setting is enabled (checked).
◆
Always accept important ICMP
When you enable (check) this setting, the system automatically accepts
the following ICMP packet types for IPv4, and therefore does not subject
them to packet filtering:
• UNREACH
• SOURCEQUENCH
• REDIRECT
• TIMEXCEED
The default setting is enabled.
MAC addresses
You can use the MAC Addresses setting to exempt traffic from certain
MAC addresses from packet filtering. Possible values are:
BIG-IP® TMOS®: Concepts
◆
Always Accept
When you select this value, a MAC Address List setting appears. You
can then specify one or more MAC addresses from which traffic should
be exempt from packet filtering.
◆
None
When you select this value, traffic from all MAC addresses is subject to
packet filtering, according to existing packet filter rule criteria. This is
the default value.
18 - 3
Chapter 18
IP addresses
You can use the IP Addresses setting to exempt traffic from certain IP
addresses from packet filtering. Possible values are:
◆
Always Accept
When you select this value, an IP Address List setting appears. You can
then specify one or more IP addresses from which traffic should be
exempt from packet filtering.
◆
None
When you select this value, traffic from all IP addresses is subject to
packet filtering, according to existing packet filter rule criteria. This is
the default value.
VLANs
Using the VLANs setting, you can configure the BIG-IP system so that
traffic from one or more specified VLANs is exempt from packet filtering.
In this case, the system does not attempt to match packets from the specified
VLAN or VLANs to any packet filter rule. Instead, the BIG-IP system
always accepts traffic from the specified VLAN or VLANs.
For example, if you specify VLAN internal, then no incoming packets from
VLAN internal are subject to packet filtering, even if a packet matches the
criteria of a packet filter rule.
Possible values are:
◆
Always Accept
When you select this value, a VLAN List setting appears. You can then
specify one or more VLANs from which traffic should be exempt from
packet filtering.
◆
None
When you select this value, traffic from all VLANs is subject to packet
filtering, according to existing packet filter rule criteria. This is the
default value.
Packet filter rules
Packet filter rules are criteria statements that the BIG-IP system uses for
filtering packets. The BIG-IP system attempts to match packet filter rules
with an incoming packet, and if a match exists, determines whether or not to
accept or reject the packet.
When you create a packet filter rule, you configure several settings, and then
you define the criteria that you want the BIG-IP system to use to filter the
traffic.
18 - 4
Packet Filters
Configuring settings for packet filter rules
You can configure a number of different settings when you create a packet
filter rule. Specifying a name.
Order of packet filter rules
You use the Order setting to specify the order in which you want the
BIG-IP system to apply existing packet filter rules. This setting is required.
Possible values for this setting are:
◆
First
Select this value if you want this packet filter rule to be the first rule that
the BIG-IP system applies.
◆
Last
Select this value if you want this packet filter rule to be the last rule that
the BIG-IP system applies.
◆
After
Select this value, and then select a packet filter rule from the list, if you
want the system to apply this packet filter after the packet filter that you
select from the list. Note that this setting is most useful when you have
more than three packet filter rules configured.
Action
When a packet matches the criteria that you have specified in a packet filter
rule, the BIG-IP system can take a specific action. You define this action
using the Action setting.
BIG-IP® TMOS®: Concepts
18 - 5
Chapter 18
You can choose one of these actions:
◆
Accept
Select Accept if you want the system to accept the packet, and stop
processing additional packet filter rules, if any exist. This is the default
setting.
◆
Discard
Select Discard if you want the system to drop the packet, and stop
processing additional packet filter rules, if any exist.
◆
Reject
Select Reject if you want the system to drop the packet, and also send a
rejection packet to the sender, indicating that the packet was refused.
Note that the behavior of the system when you select the Reject action
depends on how you configured the general packet filter Options
property Send ICMP Error on Packet Reject.
◆
Continue
Select Continue if you simply want the system to acknowledge the
packet for logging or statistical purposes. Setting the Action value to
Continue does not affect the way that the BIG-IP system handles the
packet; the system continues to evaluate traffic matching a rule, starting
with the next packet filter rule in the list.
Rate class assignment
Using the Rate Class setting, you can assign a rate class to traffic that
matches the criteria defined in a packet filter rule. Note that this setting
applies only when you have the rate shaping feature enabled.
The default value for this setting is None. If you previously created rate
classes using the rate shaping feature, you can choose one of those rate
classes from the Rate Class list.
For more information on rate shaping, see the Configuration Guide for
BIG-IP® Local Traffic Manager™.
One or more VLANs
You use the Apply to VLAN setting to display a list of VLANs and then
select a VLAN or VLAN group name. Selecting a VLAN from the list
means that the packet filter rule filters ingress traffic from that VLAN only.
For example, if you select the value *All VLANS, the BIG-IP system
applies the packet filter rule to all traffic coming into the BIG-IP system.
Similarly, if you select the VLAN internal, the BIG-IP system applies the
packet filter rule to traffic from VLAN internal only. The default value is
*All VLANS.
If you select the name of a VLAN group instead of an individual VLAN, the
packet filter rule applies to all VLANs in that VLAN group.
18 - 6
Packet Filters
Logging
If you want to generate a log message each time a packet matches a rule,
you can enable logging for the packet filter rule. With this configuration,
you can then display the Logging screen in the Configuration utility and
view events related to packet filtering. For more information about logging
packet filter events, see Chapter 14, Event Logging.
Creating a filter expression
To match incoming packets, the BIG-IP system must use a filter expression.
A filter expression specifies the criteria that you want the BIG-IP system to
use when filtering packets. For example, the BIG-IP system can filter
packets based on the source or destination IP address in the header of a
packet.
Using the Configuration utility, you can create a filter expression in either of
two ways:
• You can write your own expression, using a Filter Expression box.
• You can specify a set of criteria (such as source or destination IP
addresses) that you want the BIG-IP system to use when filtering
packets. When you use this method, the BIG-IP system builds a filter
expression for you.
You can have as many rules as you want, limited only by the available
memory. Of course, the more statements you have, the more challenging it
is to understand and maintain your packet filters.
BIG-IP® TMOS®: Concepts
18 - 7
Chapter 18
18 - 8
19
Rate Shaping
• Introduction to rate shaping
• About rate classes
• Rate class properties
Rate Shaping
Introduction to rate shaping
The BIG-IP® system includes a feature called rate shaping. Rate shaping
allows you to enforce a throughput policy on incoming traffic. Throughput
policies are useful for prioritizing and restricting bandwidth on selected
traffic patterns.
Rate shaping can be useful for an e-commerce site that has preferred clients.
For example, the site might want to offer higher throughput for preferred
customers, and lower throughput for other site traffic.
The rate shaping feature works by first queuing selected packets under a rate
class, and then dequeuing the packets at the indicated rate and in the
indicated order specified by the rate class. A rate class is a rate-shaping
policy that defines throughput limitations and a packet scheduling method to
be applied to all traffic handled by the rate class.
You configure rate shaping by creating one or more rate classes and then
assigning the rate class to a packet filter or to a virtual server. You can also
use the iRules® feature to instruct the BIG-IP system to apply a rate class to
a particular connection.
You can apply a rate class specifically to traffic from a server to a client or
from a client to a server. If you configure the rate class for traffic that is
going to a client, the BIG-IP system does not apply the throughput policy to
traffic destined for the server. Conversely, if you configure the rate class for
traffic that is going to a server, the BIG-IP system does not apply the
throughput policy to traffic destined for the client.
To configure and manage ARP entries, log in to the BIG-IP Configuration
utility, and on the Main tab, expand Network, and click Rate Shaping.
BIG-IP® TMOS®: Concepts
19 - 1
Chapter 19
About rate classes
A rate class defines the throughput limitations and packet scheduling
method that you want the BIG-IP system to apply to all traffic that the rate
class handles. You assign rate classes to virtual servers and packet filter
rules, as well as through iRules®.
If the same traffic is subject to rate classes that you have assigned from more
than one location, the BIG-IP system applies the last-assigned rate class
only. The BIG-IP system applies rate classes in the following order:
• The first rate class that the BIG-IP system assigns is from the last packet
filter rule that matched the traffic and specified a rate class.
• The next rate class that the BIG-IP system assigns is from the virtual
server; if the virtual server specifies a rate class, the rate class overrides
any rate class that the packet filter selects.
• The last rate class assigned is from the iRule; if the iRule specifies a rate
class, this rate class overrides any previously-selected rate class.
Note
Rate classes cannot reside in partitions. Therefore, a user’s ability to create
and manage rate classes is defined by user role, rather than partition-access
assignment.
You can create a rate class using the BIG-IP Configuration utility. After you
have created a rate class, you must assign it to a virtual server or a packet
filter rule, or you must specify the rate class from within an iRule.
Rate class properties
When you create a rate class, the BIG-IP system assigns some default
settings to the rate class. You can retain these default settings or modify
them to suit your needs.
Rate class name
The first setting you configure for a rate class is the rate class name. Rate
class names are case-sensitive and may contain letters, numbers, and
underscores (_) only. Reserved keywords are not allowed.
Each rate class that you define must have a unique name. This setting is
required.
To specify a rate class name, locate the Name box on the New Rate Class
screen and type a unique name for the rate class.
19 - 2
Rate Shaping
Base rate
The Base Rate setting specifies the base throughput rate allowed for traffic
that the rate class handles. The sum of the base rates of all child rate classes
attached to a parent rate class, plus the base rate of the parent rate class,
cannot exceed the ceiling of the parent rate class. For this reason, F5
Networks® recommends that you always set the base rate of a parent rate
class to 0 (the default value).
You can specify the base rate in bits per second (bps), kilobits per second
(Kbps), megabits per second (Mbps), or gigabits per second (Gbps). The
default unit is bits per second. This setting is required.
Note
These numbers are powers of 10, not powers of 2.
Ceiling rate
The Ceiling Rate setting specifies the absolute limit at which traffic is
allowed to flow when bursting or borrowing. You can specify the ceiling in
bits per second (bps), kilobits per second (Kbps), megabits per second
(Mbps), or gigabits per second (Gbps). The default unit is bits per second.
If the rate class is a parent rate class, the value of the ceiling defines the
maximum rate allowed for the sum of the base rates of all child rate classes
attached to the parent rate class, plus the base rate of the parent rate class.
Note
A child rate class can borrow from the ceiling of its parent rate class. For
more information, see Parent class, on page 19-6.
Burst size
You use the Burst Size setting when you want to allow the rate of traffic
flow that a rate class controls to exceed the base rate. Exceeding the base
rate is known as bursting. When you configure a rate class to allow bursting
(by specifying a value other than 0), the BIG-IP system saves any unused
bandwidth and uses that bandwidth later to enable the rate of traffic flow to
temporarily exceed the base rate. Specifying a burst size is useful for
smoothing out traffic patterns that tend to fluctuate or exceed the base rate,
such as HTTP traffic.
The value of the Burst Size setting defines the maximum number of bytes
that you want to allow for bursting. Thus, if you set the burst size to 5,000
bytes, and the rate of traffic flow exceeds the base rate by 1,000 bytes per
second, then the BIG-IP system allows the traffic to burst for a maximum of
five seconds.
BIG-IP® TMOS®: Concepts
19 - 3
Chapter 19
When you specify a burst size, the BIG-IP system creates a burst reservoir
of that size. A burst reservoir stores bandwidth that the BIG-IP system uses
for bursting later. The burst reservoir becomes depleted as the rate of traffic
flow exceeds the base rate, and is replenished as the rate of traffic falls
below the base rate. The Burst Size value that you configure in a rate class
thus represents:
• The maximum number of bytes that the rate class is allowed to transmit
when the traffic-flow rate exceeds the base rate
• The maximum number of bytes that the BIG-IP system can replenish into
the burst reservoir
• The amount of bandwidth initially available for bursting beyond the base
rate
The burst size is measured in bytes. For example, a value of either 10000 or
10K equals 10,000 bytes. The default value is 0.
Depleting the burst reservoir
When the rate of traffic flow exceeds the base rate, the BIG-IP system
automatically depletes the burst reservoir, at a rate determined by the
number of bytes per second that the traffic flow exceeds the base rate.
Continuing with our previous example in which traffic flow exceeds the
base rate by 1,000 bytes per second, if the traffic-flow rate only exceeds the
base rate for two seconds, then 2,000 bytes are depleted from the burst size
and the maximum bytes available for bursting decreases to 3,000.
Replenishing the burst reservoir
When the rate of traffic flow falls below the base rate, the BIG-IP system
stores the unused bandwidth (that is, the difference between the base rate
and the actual traffic-flow rate) in the burst reservoir. Later, the BIG-IP
system uses this bandwidth when traffic flow exceeds the base rate. Thus,
the BIG-IP system replenishes the burst reservoir whenever it becomes
depleted due to traffic flow exceeding the base rate.
The size of the burst reservoir cannot exceed the specified burst size. For
this reason, the BIG-IP system replenishes the reservoir with unused
bandwidth only until the reservoir reaches the amount specified by the
Burst Size setting. Thus, if the burst size is set to 5,000, then the BIG-IP
system can store only 5,000 bytes of unused bandwidth for later use when
the rate of traffic flow exceeds the base rate.
Note
Specifying a burst size does not allow the rate class to exceed its ceiling.
Specifying a non-zero burst size
The following example illustrates the behavior of the BIG-IP system when
you set the Burst Size setting to a value other than 0.
19 - 4
Rate Shaping
This example shows throughput rates in units of bytes-per-second instead of
the default bits-per-second. This is only to simplify the example. You can
derive bytes-per-second from bits-per-second by dividing the
bits-per-second amount by 8.
Suppose you configure the rate class settings with these values:
• Base rate: 1,000 bytes per second
• Ceiling rate: 4,000 bytes per second
• Burst size: 5,000 bytes
Consider the following scenario:
◆
If traffic is currently flowing at 800 bytes per second
No bursting is necessary because the rate of traffic flow is below the base
rate defined in the rate class.
Because the traffic is flowing at 200 bytes per second less than the base
rate, the BIG-IP system can potentially add 200 bytes of unused
bandwidth to the burst reservoir. However, because no bursting has
occurred yet, the reservoir is already full at the specified 5,000 bytes,
thus preventing the BIG-IP system from storing the 200 bytes of unused
bandwidth in the reservoir. In this case, the BIG-IP system simply
discards the unused bandwidth.
◆
If traffic climbs to 1,000 bytes per second (equal to the base rate)
Still no bursting occurs, and there is no unused bandwidth.
◆
If traffic jumps to 2,500 bytes per second
For each second that the traffic continues to flow at 2,500 bytes per
second, the BIG-IP system empties 1,500 bytes from the burst reservoir
(the difference between the traffic flow rate and the base rate). This
allows just over three seconds of bursting at this rate before the burst
reservoir of 5,000 bytes is depleted. Once the reservoir is depleted, the
BIG-IP system reduces the traffic flow rate to the base rate of 1,000 bytes
per second, with no bursting allowed.
◆
If traffic drops back down to 800 bytes per second
No bursting is necessary, but now the BIG-IP system can add the 200
bytes per second of unused bandwidth back into the burst reservoir
because the reservoir is empty. If traffic continues to flow at 800 bytes
per second, the burst reservoir becomes fully replenished from 0 to 5,000
bytes in 25 seconds (at a rate of 200 bytes per second). If traffic stops
flowing altogether, creating 1,000 bytes per second of unused bandwidth,
then the BIG-IP system adds 1,000 bytes per second into the burst
reservoir, thus replenishing the reservoir from 0 to 5,000 bytes in only 5
seconds.
Borrowing bandwidth
In some cases, a rate class can borrow bandwidth from the burst reservoir of
its parent class. For more information, see Parent class, following.
BIG-IP® TMOS®: Concepts
19 - 5
Chapter 19
Direction
Using the Direction setting, you can apply a rate class to client or server
traffic. Thus, you can apply a rate class to traffic going to a client, to a
server, or to both client and server. Possible values are Any, Client, and
Server. The default value is Any.
Specifying direction is useful in cases where the nature of the traffic is
directionally-biased. For example, if you offer an FTP service to external
clients, you might be more interested in limiting throughput for those clients
uploading files to your site than you are for clients downloading files from
your site. In this case, you would select Server as the direction for your FTP
rate class, because the Server value only applies your throughput restriction
to traffic going from the client to the server.
Parent class
When you create a rate class, you can use the Parent Class setting to
specify that the rate class has a parent class. This allows the child rate class
to borrow unused bandwidth from the ceiling of the parent class. A child
class can borrow unused bandwidth from the ceiling of its parent, but a
parent class cannot borrow from a child class. Borrowing is also not possible
between two child classes of the same parent class or between two unrelated
rate classes.
You specify a parent class by displaying the New Rate Class screen and
selecting Advanced, and then selecting a rate class name in the Parent
Class setting.
A parent class can itself have a parent, provided that you do not create a
circular dependency. A circular dependency is a relationship where a rate
class is a child of itself, directly or indirectly.
If a rate class has a parent class, the child class can take unused bandwidth
from the ceiling of the parent class. The process occurs in this way:
• If the rate of traffic flow to which the child class is applied exceeds its
base rate, the child class begins to deplete its burst reservoir as described
previously.
• If the reservoir is empty (or no burst size is defined for the rate class),
then the BIG-IP system takes unused base-rate bandwidth from the
ceiling of the parent class and gives it to the child class.
• If the unused bandwidth from the parent class is depleted, then the child
class begins to use the reservoir of the parent class.
• If the reservoir of the parent class is empty (or no burst size is defined for
the parent class), then the child class attempts to borrow bandwidth from
the parent of the parent class, if the parent class has a parent class.
• This process continues until there is no remaining bandwidth to borrow
or there is no parent from which to borrow.
19 - 6
Rate Shaping
Borrowing only allows the child to extend its burst duration; the child class
cannot exceed the ceiling under any circumstance.
Note
Although the above description uses the term “borrowing”, bandwidth that
a child class borrows is not paid back to the parent class later, nor is
unused bandwidth of a child class returned to its parent class.
Shaping policy
Specifies a shaping policy that includes customized values for drop policy
and queue method. The default value is None.
You can create additional shaping policies using the Traffic Management
shell (tmsh).
Queue method
The Queue Method setting determines the method and order in which the
BIG-IP system dequeues packets.
A rate class supports two queue methods:
◆
Stochastic Fair Queue
Stochastic Fair Queueing (SFQ) is a queueing method that queues
traffic under a set of many lists, choosing the specific list based on a
periodically-changing hash of the connection information. This results in
traffic from the same connection always being queued in the same list.
SFQ then dequeues traffic from the set of the lists in a round-robin
fashion. The overall effect is that fairness of dequeueing is achieved
because one high-speed connection cannot monopolize the queue at the
expense of slower connections.
◆
Priority FIFO
The Priority FIFO (PFIFO) queueing method queues all traffic under a
set of five lists based on the Type of Service (ToS) field of the traffic.
Four of the lists correspond to the four possible ToS values (Minimum
delay, Maximum throughput, Maximum reliability, and Minimum
cost). The fifth list represents traffic with no ToS value. The PFIFO
method then processes these five lists in a way that attempts to preserve
the meaning of the ToS field as much as possible. For example, a packet
with the ToS field set to Minimum cost might yield dequeuing to a
packet with the ToS field set to Minimum delay.
Drop policy
The BIG-IP system drops packets whenever the specified rate limit is
exceeded. A drop policy specifies the way that you want the system to drop
packets. The default value is tail.
BIG-IP® TMOS®: Concepts
19 - 7
Chapter 19
Possible values are:
◆
fred
Specifies that the system drops packets according to the type of traffic in
the flow.
◆
red
Specifies that the system randomly drops packets.
◆
tail
Specifies that the system drops the end of the traffic stream.
You can create additional drop policies using the Traffic Management shell
(tmsh).
19 - 8
20
Spanning Tree Protocols
• Introduction to spanning tree protocols
• Global spanning tree properties
• Management of spanning tree instances
• Interfaces for spanning tree
Spanning Tree Protocols
Introduction to spanning tree protocols
On networks that contain redundant paths between Layer 2 devices, a
common problem is bridging loops. Bridging loops occur because Layer 2
devices do not create boundaries for broadcasts or packet floods.
Consequently, Layer 2 devices can use redundant paths to forward the same
frames to each other continuously, eventually causing the network to fail.
To solve this problem, the BIG-IP® system supports a set of
industry-standard, Layer 2 protocols known as spanning tree protocols.
Spanning tree protocols block redundant paths on a network, thus
preventing bridging loops. If a blocked, redundant path is needed later
because another path has failed, the spanning tree protocols clear the path
again for traffic. The spanning tree protocols that the BIG-IP system
supports are Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol
(RSTP), and Multiple Spanning Tree Protocol (MSTP).
Central to the way that spanning tree protocols operate is the use of bridge
protocol data units (BPDUs). When you enable spanning tree protocols on
Layer 2 devices on a network, the devices send BPDUs to each other, for the
purpose of learning the redundant paths and updating their L2 forwarding
tables accordingly, electing a root bridge, building a spanning tree, and
notifying each other about changes in interface status.
To configure and manage spanning tree protocols, log in to the BIG-IP
Configuration utility, and on the Main tab, expand Network, and click
Spanning Tree.
Note
Throughout this chapter, the term bridge refers to a Layer 2 device such as
a switch, bridge, or hub.
Spanning tree protocol types
The BIG-IP system supports three different spanning tree protocols: STP,
RSTP, and MSTP. Table 20.1 lists the protocols and their IEEE
specifications. Following the table is a brief summary of each protocol.
Protocol Name
IEEE Specification
Spanning Tree Protocol (STP)
802.1D-1998
Rapid Spanning Tree Protocol (RSTP)
802.1w, 802.1t, and 802.1D-2004
Multiple Spanning Tree Protocol (MSTP)
802.1s
Table 20.1 The spanning tree protocols that the BIG-IP system supports
BIG-IP® TMOS®: Concepts
20 - 1
Chapter 20
The STP protocol
STP is the original spanning tree protocol, designed to block redundant
paths as a way to prevent bridging loops. The STP algorithm creates one,
and only one, spanning tree for the entire network. A spanning tree is a
logical tree-like depiction of the bridges on a network and the paths that
connect them.
Because STP is unable to recognize VLANs and usually exhibits poor
performance overall, STP is not the preferred spanning tree protocol to use
in VLAN-rich environments. However, all participating interfaces in the
spanning tree must use the same spanning tree protocol at any given time.
Thus, when you have legacy bridges in your environment that are running
STP, interfaces on the BIG-IP system must have the ability to automatically
degrade to STP. For more information on protocol degradation, see Using
spanning tree with legacy bridges, on page 20-3.
Because STP has no knowledge of VLANs, you can have only one spanning
tree instance on the BIG-IP system when using STP. For more information
on spanning tree instances, see Management of spanning tree instances, on
page 20-8.
The RSTP protocol
RSTP is an enhancement to STP, and was designed specifically to improve
spanning tree performance. Like STP, RSTP can create only one spanning
tree (instance 0), and therefore cannot take VLANs into account when
managing redundant paths. However, RSTP’s performance improvements
generally make it preferable to STP in non-VLAN environments.
In the case where legacy RSTP bridges are on the network, BIG-IP system
interfaces running MSTP can degrade to RSTP, just as they can degrade to
STP. For more information on protocol degradation, see Using spanning
tree with legacy bridges, on page 20-3.
Like STP, RSTP allows only one spanning tree instance on the BIG-IP
system. For more information on spanning tree instances, see Management
of spanning tree instances, on page 20-8.
The MSTP protocol
MSTP is an enhancement to RSTP and is the preferred spanning tree
protocol for the BIG-IP system. MSTP is specifically designed to
understand VLANs and VLAN tagging (specified in IEEE 802.1q). Unlike
STP and RSTP, which allow only one spanning tree instance per system,
MSTP allows multiple spanning tree instances. Each instance corresponds to
a spanning tree, and can control one or more VLANs that you specify when
you create the instance. Thus, for any BIG-IP system interface that you
assigned to multiple VLANs, MSTP can block a path on one VLAN, while
still keeping a path in another VLAN open for traffic. Neither STP nor
RSTP has this capability.
A unique feature of MSTP is the concept of spanning tree regions. A
spanning tree region is a logical set of bridges on the network that share the
same values for certain MSTP configuration settings. These configuration
20 - 2
Spanning Tree Protocols
settings are: The MSTP configuration name, the MSTP configuration
number, the instance numbers, and the VLAN members of each instance.
When the values of these settings are identical on two or more bridges, the
spanning tree algorithm considers these bridges to constitute an MSTP
region. An MSTP region indicates to the spanning tree algorithm that it can
use MSTP for all bridges in that region, and thus take VLANs into account
when blocking and unblocking redundant paths.
You do not explicitly create a region. The spanning tree algorithm
automatically groups bridges into regions, based on the values you assign to
the MSTP configuration name, revision number, instance numbers, and
instance members.
MSTP can only operate on bridges that are within a region. However, if the
BIG-IP system connects to a bridge in a different MSTP region or outside of
an MSTP region, the system still participates in spanning tree. In this case,
the system is part of the spanning tree instance 0, also known as the
Common and Internal Spanning Tree (CIST).
Note
BIG-IP systems released prior to version 9.0 do not support MSTP.
Using spanning tree with legacy bridges
A key concept about spanning tree protocols on the BIG-IP system is the
concept of protocol degradation. Protocol degradation occurs when the
spanning tree mode on the BIG-IP system is set to MSTP or RSTP, but the
system detects legacy bridges (that is, bridges running an older protocol
type) on the network. In this case, the BIG-IP system automatically degrades
the spanning tree protocol that is running on each applicable interface to
match the protocol running on the legacy device.
For example, suppose you set the BIG-IP system to run in MSTP mode.
Later, if a bridge running STP is added to the network, the BIG-IP system
will detect the legacy device and automatically degrade the protocol running
on the BIG-IP system interfaces from MSTP to STP. The mode is still set to
MSTP, but the interfaces actually run STP.
If the legacy device is later removed from the network, you can choose, for
each BIG-IP system interface, to manually reset the spanning tree protocol
back to MSTP.
The basic principle of protocol degradation is that each BIG-IP system
interface in a spanning tree runs the oldest protocol that the system detects
on the Layer 2 devices of the network. Thus, if a legacy bridge running STP
is added to the network, BIG-IP system interfaces running MSTP or RSTP
degrade to STP. Similarly, if a legacy bridge is running RSTP (and no
bridges are running STP), interfaces running MSTP degrade to RSTP.
Note that when a bridge running MSTP must degrade to RSTP, the spanning
tree algorithm automatically puts the degraded bridge into a separate MSTP
region.
BIG-IP® TMOS®: Concepts
20 - 3
Chapter 20
Configuration overview
Regardless of which spanning tree protocol you choose to use, the BIG-IP®
Configuration utility offers a complete set of default configuration settings.
Except for choosing a preferred spanning tree protocol to use, there are very
few configuration settings that you need to modify to use the spanning tree
feature effectively.
Note
An alternate way to configure spanning tree protocols is to use tmsh. For
more information, see the Traffic Management Shell (tmsh) Reference
Guide.
When you configure spanning tree on a BIG-IP system, you must first
decide which protocol, or mode, you want to enable. Because MSTP
recognizes VLANs, using MSTP is preferable for the BIG-IP system.
However, all bridges in a network environment that want to use spanning
tree must run the same spanning tree protocol. If a legacy bridge running
RSTP or STP is added to the network, the BIG-IP system must switch to
that same protocol.
Fortunately, you do not need to continually reconfigure the BIG-IP system
spanning tree mode whenever a legacy bridge is added to the network.
Instead, a BIG-IP system interface can detect the addition of a legacy bridge
and automatically fall back to either RSTP or STP mode. If the legacy
bridge is later removed from the network, you can use the Configuration
utility to manually reset the interface back to running MSTP. For more
information on legacy bridges, see Using spanning tree with legacy bridges,
on page 20-3.
Once you have enabled a spanning tree mode, you can configure a set of
global options. These options are the same options that are defined in the
IEEE standards for the spanning tree protocols. While you can use the
default settings in most cases, a few settings require user input. For more
information, see Global spanning tree properties, on page 20-5.
20 - 4
Spanning Tree Protocols
Global spanning tree properties
There are several properties you can configure on the BIG-IP system that
affect the behavior of all spanning tree protocols. These global properties
apply to all spanning instances and all network interfaces. In most cases,
you can use the default values for these properties.
Spanning tree mode
The Mode option specifies the particular spanning tree protocol that you
want to use on the BIG-IP system. The default value is Pass Through. The
possible values are:
◆
Disabled
Specifies that when the BIG-IP system receives spanning tree frames
(BPDUs), it discards the frames.
◆
Pass Through
Specifies that when the BIG-IP system receives spanning tree frames
(BPDUs), it forwards them to all other interfaces. This is the default
setting. When you use Pass Through mode, the BIG-IP system is
transparent to spanning tree BPDUs. When set to Pass Through mode,
the BIG-IP system is not part of any spanning tree. Note that Pass
Through mode is not part of the IEEE spanning tree protocol
specifications.
◆
STP
Specifies that the BIG-IP system handles spanning tree frames (BPDUs)
in accordance with the STP protocol. This mode allows for legacy
systems on the network. For more information on STP, see Introduction
to spanning tree protocols, on page 20-1.
◆
RSTP
Specifies that the BIG-IP system handles spanning tree frames (BPDUs)
in accordance with the RSTP protocol. For more information on RSTP,
see Introduction to spanning tree protocols, on page 20-1.
◆
MSTP
Specifies that the BIG-IP system handles spanning tree frames (BPDUs)
in accordance with the MSTP protocol. For more information on MSTP,
see Introduction to spanning tree protocols, on page 20-1.
When you set the mode to MSTP or RSTP, and a legacy bridge running STP
is subsequently added to the spanning tree, the applicable BIG-IP system
interface automatically changes to running STP. However, you can
manually reset an interface to resume operation in RSTP or MSTP mode if
the legacy bridge is later removed from the spanning tree.
BIG-IP® TMOS®: Concepts
20 - 5
Chapter 20
Global timers
All three spanning tree protocols, have the same three global timer values
that you can specify: Hello Time, Maximum Age, and Forward Delay.
Specifying the Hello Time option
When you change the value of the Hello Time option, you change the time
interval, in seconds, that the BIG-IP system transmits spanning tree
information (through BPDUs) to adjacent bridges in the network. The
default value for this option is 2.
WARNING
Although valid values are in the range of 1 to 10 seconds, we highly
recommend that you use the default value (2 seconds). This value is optimal
for almost all configurations.
Note that when running RSTP, you must maintain the following relationship
between the Maximum Age and Hello Time options:
Maximum Age >= 2 * (Hello Time + 1)
Specifying the Maximum Age option
When you change the value of the Maximum Age option, you change the
amount of time, in seconds, that spanning tree information received from
other bridges is considered valid. The default value is 20, and the valid
range is 6 to 40.
Note that when running RSTP, you must maintain the following
relationships between the Maximum Age and the Hello Time and Forward
Delay options:
Maximum Age >= 2 * (Hello Time + 1)
Maximum Age <= 2 * (Forward Delay - 1)
Specifying the Forward Delay option
Primarily used for STP, the Forward Delay option specifies the amount of
time, in seconds, that the system blocks an interface from forwarding
network traffic when the spanning tree algorithm reconfigures a spanning
tree. The default value is 15, and the valid range is 4 to 30.
This option has no effect on the BIG-IP system when running in RSTP or
MSTP mode, as long as all bridges in the spanning tree use the RSTP or
MSTP protocol. However, if the addition of legacy STP bridges causes
neighboring bridges to fall back to running the STP protocol, then the
spanning tree algorithm uses the Forward Delay option when reconfiguring
the spanning tree.
Note that when running RSTP, you must maintain the following relationship
between the Forward Delay and Maximum Age options:
Maximum Age <= 2 * (Forward Delay - 1)
20 - 6
Spanning Tree Protocols
Transmit Hold Count option
When you change the value of the Transmit Hold Count option, you
change the maximum number of spanning tree frames (BPDUs) that the
system can transmit on a port within the Hello Time interval. This setting
ensures that the spanning tree frames do not overload the network, even in
unstable network conditions. The default value is 6, and the valid range is 1
to 10.
MSTP-specific global properties
If you are running MSTP, you can configure three additional global
properties: An MSTP configuration name, an MSTP configuration revision,
and a maximum hop number.
MSTP configuration name
Applicable to MSTP only, the MSTP Configuration Name setting
represents a global name that you assign to all bridges in a spanning tree
region. A spanning tree region is a group of bridges with identical MSTP
configuration names and MSTP configuration revision levels, as well as
identical assignment of VLANs to spanning tree instances.
All bridges in the same region must have this same configuration name. The
name must contain from 1 to 32 characters. This option only appears on the
screen when you set the Mode property to MSTP.
For more information on MSTP regions, see The MSTP protocol, on page
20-2.
MSTP configuration revision
Applicable to MSTP only, the MSTP Configuration Revision setting
represents a global revision number that you assign to all bridges in a
spanning tree region. All bridges in the same region must have this same
configuration revision number. The default value is 0. You can type any
value between 0 and 65535. This option only appears on the screen when
you set the Mode property to MSTP.
For more information on MSTP regions, see The MSTP protocol, on page
20-2.
Maximum hop number
Applicable to MSTP only, this global property specifies the maximum
number of hops that a spanning tree frame (BPDU) can traverse before it is
discarded. The default value is 20. You can specify a value between 1 and
255. This option only appears on the screen when you set the Mode property
to MSTP.
BIG-IP® TMOS®: Concepts
20 - 7
Chapter 20
Management of spanning tree instances
By default, the spanning tree protocol STP is enabled on all of the interfaces
of the BIG-IP system. The default spanning tree configuration includes a
single spanning tree instance, named 0. A spanning tree instance is a
discrete spanning tree for a network. While STP and RSTP allow only one
spanning tree instance (instance 0), MSTP allows you to create multiple
spanning tree instances, to manage redundant paths for specific VLANs on
the network.
When running MSTP, instances that you create have instance members. An
instance member is a VLAN that you assign to an instance when you create
that instance. You can assign as many or as few members to an instance as
you deem necessary. By default, all VLANs on the BIG-IP system are
members of instance 0.
If you create an instance and attempt to add a VLAN that is already a
member of another instance, the BIG-IP system deletes the VLAN from the
existing instance and adds the VLAN to the new instance.
Each instance name must be a numeric value that you assign when you
create the instance.
Note
Only users with either the Administrator or Resource Administrator role
can manage spanning tree instances.
Viewing a list of spanning tree instances
You can view a list of existing spanning tree instances using the
Configuration utility. For STP and RSTP, the only instance in the list is
instance 0. For MSTP, the list shows instance 0, plus any other instances
that you have explicitly created. For information on creating a spanning tree
instance, see Interfaces for spanning tree, on page 20-12.
When you view a list of instances, you can see the following information for
each instance:
• The name of the instance
• The bridge priority number
• The MAC address of the root bridge
• The MAC address of the regional root bridge
• The number of instance members
Creating a spanning tree instance (MSTP-only)
The STP and RSTP protocols allow only one spanning tree instance,
instance 0, which the BIG-IP system creates automatically when you enable
spanning tree. When running STP or RSTP, you can modify the properties
of instance 0, but you cannot create additional instances. For information on
20 - 8
Spanning Tree Protocols
modifying the properties of an instance, see Viewing and modifying a
spanning tree instance, on page 20-12.
When you are running MSTP, however, the MSTP algorithm can explicitly
create instances. The reason that you can create instances is that MSTP
recognizes VLANs. By creating an instance and assigning one or more
VLANs to it, you can control bridge loops and redundant paths within those
VLANs.
For example, suppose you have two interfaces. One interface is assigned to
VLAN A, while the other interface is assigned to VLANs A and B. If you
are using the STP or RSTP protocol, both of which disregard VLANs, the
protocol might block traffic for both VLANs, as shown in Figure 20.1.
Figure 20.1 Using STP or RSTP to block redundant paths
BIG-IP® TMOS®: Concepts
20 - 9
Chapter 20
By contrast, the MSTP protocol can make blocking decisions on a
per-VLAN basis. In our example, on the interface that carries traffic for two
VLANs, you can block traffic for VLAN A, but leave a path open for
VLAN B traffic. This is shown in Figure 20.2.
Figure 20.2 Using MSTP to block redundant paths
Because all BPDUs exchanged within a region always reference instance 0,
instance 0 is active on all interfaces. This, in turn, can cause blocking
problems. To avoid this, make sure that each VLAN on a BIG-IP system is a
member of an instance that you explicitly create, rather than a member of
instance 0 only. For example, suppose you create the following:
• Instance 1 with VLAN A as a member, where VLAN A is associated
with interface 1.2
• Instance 2 with VLAN B as a member, where VLAN B is associated
with interface 1.4
In this case, neither interface will be blocked, because the BPDUs sent from
each interface reference a unique instance (either instance 1 or instance 2).
Tip
Because all BPDUs exchanged within a region always reference instance 0,
thereby causing instance 0 to be active on all interfaces, unwanted blocking
problems can occur. To avoid this, make sure that each VLAN on a BIG-IP
system is a member of an instance that you explicitly create, rather than a
member of instance 0 only.
20 - 10
Spanning Tree Protocols
Instance ID assignment
When you configure the Instance ID setting, you specify a numeric value
for the instance, in the range of 1 to 255. The reason that instance names
must be numeric is to handle the requirement that all cooperating bridges
agree on the assignment of VLANs to instance IDs. Using numeric values
instead of names makes this requirement easier to manage.
Bridge priority
The bridge in the spanning tree with the lowest relative priority becomes the
root bridge. A root bridge represents the root of a spanning tree, and is
responsible for managing loop resolution on the network. F5 Networks®
recommends that you configure this setting so that the BIG-IP system never
becomes the root bridge. For this reason, the default value for the Bridge
Priority setting is 61440, the highest value that you can select. Note that a
bridge priority must be in increments of 4096.
VLAN assignment
If you are running MSTP, you can add members to a spanning tree instance.
An instance member is a VLAN. You add members to an instance by
associating one or more VLANs with the instance. The interfaces or trunks
associated with each VLAN automatically become part of the spanning tree
corresponding to that instance.
For two or more bridges to operate in the same spanning tree, all of those
bridges must be in the same region, and therefore must have the same
instance numbers, instance members, and VLAN tags.
For example, if a bridge has instance 1, with two VLAN members whose
tags are 1000 and 2000, then any other bridges that you want to operate in
that spanning tree must also have instance 1 with two VLAN members
whose tags are 1000 and 2000. For more information on MSTP regions, see
The MSTP protocol, on page 20-2.
A particular VLAN cannot be associated with more than one spanning tree
instance. For example, if you have two instances named 0 and 1, you can
only associate VLAN external with one of those instances, not both.
Therefore, before creating an instance, verify that each VLAN you intend to
associate with the instance is not a member of another instance.
Tip
If no VLANs appear in the Available box when creating an instance, it is
likely that all VLANs on the BIG-IP system are members of other instances.
You can verify this by viewing the members of other instances.
BIG-IP® TMOS®: Concepts
20 - 11
Chapter 20
Viewing and modifying a spanning tree instance
Using the Configuration utility, you can view and modify properties of any
instance, including instance 0. If you are running MSTP, you can modify the
Bridge Priority and VLANs properties. If you are running RSTP or STP,
you can modify only the Bridge Priority property. In no case can you
modify the instance ID.
Deleting a spanning tree instance or its members (MSTP-only)
If you are running MSTP, you might have explicitly created some spanning
tree instances. If so, you can delete any spanning tree instance except
instance 0.
You can also remove VLAN members from an instance. When you remove
a VLAN from an instance, the VLAN automatically becomes a member of
instance 0. (By default, instance 0 includes any VLAN that is not a member
of another instance.)
If you remove all members from an instance, the BIG-IP system
automatically deletes the instance.
Note
If you are running RSTP or STP, you cannot delete instance 0 or remove
members from it.
Interfaces for spanning tree
Some of the configuration tasks you perform when managing a spanning
tree protocol pertain to BIG-IP system interfaces. The interface-related tasks
you perform are:
• Configuring settings on each interface that is to be part of the spanning
tree
• Managing interfaces per spanning tree instance
Configuring spanning tree settings on an interface
For each interface on the BIG-IP system, there are several STP-related
settings that you can configure.
Note
There are additional interface properties and settings that apply to specific
spanning tree instances only.
20 - 12
Spanning Tree Protocols
Enabling and disabling Spanning Tree
When you check the box for the STP setting, you are specifying that the
interface can become part of a spanning tree. Once the interface becomes
part of the spanning tree, the spanning tree protocol takes control of all
learning and frame forwarding on that interface.
If you disable this setting, the spanning tree protocol treats the interface as
non-existent, and does not send BPDUs to that interface. Also, the interface,
and not the spanning tree protocol, controls all learning and frame
forwarding for that interface.
Note that you can also enable or disable spanning tree for a trunk. If
spanning tree is enabled on the reference link of a trunk (that is, the
lowest-numbered interface of the trunk), then spanning tree is automatically
enabled on that trunk. To disable spanning tree for a trunk, simply disable
spanning tree on the reference link.
STP link type
When you specify an STP link type, you ensure that STP uses the correct
optimizations for the interface. Possible values are:
◆
auto
When you set the STP link type to auto, the BIG-IP system determines
the spanning tree link type, which is based on the Active Duplex
interface property.
◆
p2p
When you set the STP link type to p2p, the BIG-IP system uses the
optimizations for point-to-point spanning tree links. Point-to-point links
connect two spanning tree bridges only. For example, a point-to-point
link might connect a 10 Gigabit link to another bridge. For point-to-point
links, the Active Duplex property interface should be set to full. Note
that p2p is the only valid STP link type for a trunk.
◆
shared
When you set the STP link type to shared, the BIG-IP system uses the
optimizations for shared spanning tree links. Shared links connect two or
more spanning tree bridges. For example, a shared link might be a 10
Megabit hub. Note that for shared links, the Active Duplex interface
property should be set to half.
STP edge port
When you enable the STP Edge Port setting, you are explicitly designating
the interface as an edge port. An edge port is an interface that connects to an
end station rather than to another spanning tree bridge. The default setting is
disabled (not checked).
If you would rather have the system automatically designate the interface as
an edge port, you can enable the STP Edge Port Detection setting instead,
described in the following section.
BIG-IP® TMOS®: Concepts
20 - 13
Chapter 20
If you enable (check) the STP Edge Port setting and the interface
subsequently receives STP, RSTP, or MSTP frames (BPDUs), the system
disables the setting automatically, because only non-edge interfaces receive
BPDUs.
Detection of an STP edge port
When you enable the STP Edge Port Detection setting, the system
determines whether the interface is an edge port, and if so, automatically
designates the interface as an edge port. The system determines edge port
status by monitoring the interface and verifying that it does not receive any
incoming STP, RSTP, or MSTP frames (BPDUs).
If the system determines that the interface is not an edge port, but you
enabled the STP Edge Port setting to explicitly designate the interface as an
edge port, the system removes the edge port designation from the interface.
No interface that receives BPDUs from a bridge can have edge port status,
despite the values of the STP Edge Port and STP Edge Port Detection
settings.
Spanning tree protocol reset
As described in Global spanning tree properties, on page 20-5, the spanning
tree algorithm automatically detects the presence of legacy STP bridges on
the network, and falls back to STP mode when communicating with those
bridges. Because legacy STP bridges do not send spanning tree BPDUs
periodically in all circumstances, the BIG-IP system cannot detect when a
legacy STP bridge has been removed from the network. Therefore, it is
necessary to manually notify the BIG-IP system that the algorithm can
switch to the RSTP or MSTP protocol again, whenever a legacy bridge has
been removed.
Managing interfaces for a specific instance
When you manage an interface for a specific spanning tree instance, you
can:
• View a list of interfaces for an instance
• View instance-specific properties of an interface
• Configure instance-specific settings for an interface
Viewing a list of interface IDs for an instance
Using the Configuration utility, you can view a list of the interface IDs
associated with a specific spanning tree instance.
If you are using MSTP, the interface IDs that appear in the list are the
interfaces assigned to the VLANs that you specified when you created the
instance. If you are using STP or RSTP, the interface IDs in the list are those
that the BIG-IP system automatically assigned to instance 0.
20 - 14
Spanning Tree Protocols
The list of interface IDs also displays the following information for each
interface:
• The STP instance ID
• The priority
• The external path cost
• The port role
Viewing instance-specific properties of an interface
Once you have used the previous procedure to view the list of interfaces
associated with a particular spanning tree instance, you can view the
properties associated with that interface. Some of these properties are those
that you configured using the Interfaces screen.
Understanding the port roles
The Port Role property of a per-instance interface specifies the interface’s
role in the spanning tree instance. You cannot specify a value for this
property; the BIG-IP system automatically assigns a role to the interface.
The BIG-IP system can assign one of the following roles to an instance
interface:
◆
Disabled
The interface has no active role in the spanning tree instance.
◆
Root
The interface provides a path to a root bridge.
◆
Alternate
The interface provides an alternate path to a root bridge, if the root
interface is unavailable.
◆
Designated
The interface provides a path away from the root bridge.
◆
Backup
The interface provides an alternate path away from the root bridge, if an
interface with a port role of Designated is unavailable. The Backup role
assignment is rare.
Understanding port states
The Port State property of an interface specifies the way that the interface
processes normal data packets. You cannot specify a value for this property;
the BIG-IP system automatically assigns a state to the interface.
An interface can be in one of the following states at any given time:
BIG-IP® TMOS®: Concepts
◆
Blocking
The interface disregards any incoming frames, and does not send any
outgoing frames.
◆
Forwarding
The interface passes frames as needed.
20 - 15
Chapter 20
◆
Learning
The interface is determining information about MAC addresses, and is
not yet forwarding frames.
Configuring instance-specific settings for an interface
There are a few settings that you configure for an interface that only pertain
to a specific instance.
Selecting an interface priority
Each interface has an associated priority within a spanning tree instance.
The relative values of the interface priorities affect which interfaces the
system chooses to carry network traffic. Using the Interface Priority
setting, you can select the interface's priority in relation to the other
interfaces that are members of the spanning tree instance.
Typically, the system is more likely to select interfaces with lower numeric
values to carry network traffic. A priority value that you assign to an
interface can be in the range of 0 to 240, in increments of 16. Thus, the value
you assign to an interface can be 0, 16, 32, 64, and so on, up to 240.
The default priority for an interface is 128, the middle of the valid range.
Specifying path cost
Each interface has an associated path cost within a spanning tree instance.
The path cost represents the relative cost of sending network traffic through
that interface. When calculating the spanning tree, the spanning tree
algorithm attempts to minimize the total path cost between each point of the
tree and the root bridge. By manipulating the path costs of different
interfaces, you can steer traffic toward paths that are either faster, more
reliable, more economical, or have all of these qualities.
The value of a path cost can be in the range of 1 to 200,000,000, unless you
have legacy STP bridges. In that case, because some legacy
implementations support a range of only 1 to 65535, you should use this
more restricted range when setting path costs on interfaces.
The default path cost for an interface is based on the maximum speed of the
interface rather than the actual speed, as shown in Table 20.2.
Maximum Interface Speed
Default Path Cost
10 Gb/s
2,000
1 Gb/s
20,000
100 Mb/s
200,000
10 Mb/s
2,000,000
Table 20.2 Default path costs based on interface speeds
20 - 16
Spanning Tree Protocols
For example, an interface that has a maximum speed of 1000 Mb/s (1 Gb/s),
but is currently running at a speed of 10 Mb/s, has a default path cost of
20,000.
Link aggregation does not affect the default path cost. For example, if a
trunk has four 1 Gb/s interfaces, the default path cost is 20,000.
For MSTP, you can set two kinds of path costs, external and internal. For
STP and RSTP, you can set an external path cost only.
◆
External Path Cost
The External Path Cost setting is used to calculate the cost of sending
spanning tree traffic through the interface to reach an adjacent spanning
tree region. The spanning tree algorithm tries to minimize the total path
cost between each point of the tree and the root bridge. The external path
cost applies only to those interfaces (and trunks) that are members of
instance 0.
◆
Internal Path Cost
The Internal Path Cost setting allows you to specify the relative cost of
sending spanning tree traffic through the interface to adjacent bridges
within a spanning tree region. Note that the internal path cost applies
only to bridges that support the MSTP mode. The internal path cost
applies to those interfaces (and trunks) that are members of any instance,
including instance 0.
To summarize, STP and RSTP use external path costs only, and the costs
apply to instance 0 interfaces only. MSTP uses both external and internal
path costs, and the internal costs apply to interfaces in all spanning tree
instances, including instance 0.
BIG-IP® TMOS®: Concepts
20 - 17
Chapter 20
20 - 18
21
Trunks
• Introduction to trunks
• Trunk properties
Trunks
Introduction to trunks
A trunk is a logical grouping of interfaces on the BIG-IP® system. 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, you should aggregate links in powers of two. Thus, you
ideally aggregate two, four, or eight links.
The purpose of a trunk is two-fold: To increase bandwidth without
upgrading hardware, and to provide 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.
To configure and manage trunks, log in to the BIG-IP Configuration utility,
and on the Main tab, expand Network, and click Trunks.
How do trunks work?
In a typical configuration where trunks are configured, the member links of
the trunk are connected through Ethernet cables to corresponding links on a
peer system. Figure 21.1 shows an example of a typical trunk configuration
with two peers and three member links on each peer.
Figure 21.1 Example of a trunk configured for two switches
A primary goal of the trunks feature is to ensure that frames exchanged
between peer systems are never sent out of order or duplicated on the
receiving end. The BIG-IP system is able to maintain frame order by using
the source and destination addresses in each frame to calculate a hash value,
and then transmitting all frames with that hash value on the same member
link.
BIG-IP® TMOS®: Concepts
21 - 1
Chapter 21
The BIG-IP system automatically assigns a unique MAC address to a trunk.
However, by default, the MAC address that the system uses as the source
and destination address for frames that the system transmits and receives
(respectively), is the MAC address of the lowest-numbered interface of the
trunk.
The BIG-IP system also uses the lowest-numbered interface of a trunk as a
reference link. The BIG-IP system uses the reference link to take certain
aggregation actions, such as implementing the automatic link selection
policy. For frames coming into the reference link, the BIG-IP system load
balances the frames across all member links that the BIG-IP system knows
to be available. For frames going from any link in the trunk to a destination
host, the BIG-IP system treats those frames as if they came from the
reference link.
Finally, the BIG-IP system uses the MAC address of an individual member
link as the source address for any LACP control frames. For more
information on LACP, see Overview of LACP, following.
Overview of LACP
A key aspect of trunks is Link Aggregation Control Protocol, or LACP.
Defined by IEEE standard 802.3ad, LACP is a protocol that detects error
conditions on member links and redistributes traffic to other member links,
thus preventing any loss of traffic on the failed link. On a BIG-IP system,
LACP is an optional feature that you can configure.
You can also customize LACP behavior. For example, you can specify the
way that LACP communicates its control messages from the BIG-IP system
to a peer system. You can also specify the rate at which the peer system
sends LACP packets to the BIG-IP system. If you want to affect the way
that the BIG-IP system chooses links for link aggregation, you can specify a
link control policy. For more information, see Trunk properties, on page
21-2.
Trunk properties
You can configure several properties related to trunks.
Trunk name
You can use the Name setting to specify a unique name for the trunk. This
setting is required.
21 - 2
Trunks
Interfaces for a trunk
Using the Interfaces setting, you specify the interfaces that you want the
BIG-IP system to use as member links for the trunk. Once you have created
the trunk, the BIG-IP system uses these interfaces to perform link
aggregation.
Tip
To optimize bandwidth utilization, F5 Networks® recommends that, if
possible, the number of links in the trunk be a power of 2 (for example, 2, 4,
or 8). This is due to the frame balancing algorithms that the system uses to
map data streams to links. Regardless of the hashing algorithm, a trunk that
has 2, 4, or 8 links prevents the possibility of skewing, which can adversely
affect data throughput.
The BIG-IP system uses the lowest-numbered interface as the reference
link. The system uses the reference link to negotiate links for aggregation.
The interfaces that you specify for the trunk must operate at the same media
speed, and must be set at full-duplex mode. Otherwise, the BIG-IP system
cannot aggregate the links. Because these media properties are dynamic
rather than static (due to auto-negotiation), the lacpd service routinely
monitors the current status of these properties and negotiates the links for
aggregation accordingly. Thus, when the status of these properties qualifies
a link to become a working member link, the system adds the link to the
aggregation, and the link can begin accepting traffic. For information on
setting media properties for an interface, see Platform Guide: 1500, 3400,
6400, and 6800 or Platform Guide: 8400 and 8800.
Any interface that you assign to a trunk must be an untagged interface.
Furthermore, you can assign an interface to one trunk only; that is, you
cannot assign the same interface to multiple trunks. Because of these
restrictions, the only interfaces that appear in the Interfaces list in the
Configuration utility are untagged interfaces that are not assigned to another
trunk. Therefore, before creating a trunk and assigning any interfaces to it,
you should verify that each interface for the trunk is an untagged interface.
After creating the trunk, you assign the trunk to one or more VLANs, using
the same VLAN screen that you normally use to assign an individual
interface to a VLAN.
If you are using one of the spanning tree protocols (STP, RSTP, or MSTP),
the BIG-IP system sends and receives spanning tree protocol packets on a
trunk, rather than on individual member links. Likewise, use of a spanning
tree protocol to enable or disable learning or forwarding on a trunk operates
on all member links together, as a single unit.
Enabling LACP
As an option, you can enable LACP on a trunk. Containing a service called
lacpd, LACP is an IEEE-defined protocol that exchanges control packets
over member links. The purpose of LACP is to detect link error conditions
BIG-IP® TMOS®: Concepts
21 - 3
Chapter 21
such as faulty MAC devices and link loopbacks. If LCAP detects an error on
a member link, the BIG-IP system removes the member link from the link
aggregation and redistributes the traffic for that link to the remaining links
of the trunk. In this way, no traffic destined for the removed link is lost.
LACP then continues to monitor the member links to ensure that
aggregation of those links remains valid.
By default, the LACP feature is disabled, to ensure backward compatibility
with previous versions of the BIG-IP system. If you create a trunk and do
not enable the LACP feature, the BIG-IP system does not detect link error
conditions, and therefore cannot remove the member link from link
aggregation. The result is that the system cannot redistribute the traffic
destined for that link to the remaining links in the trunk, thereby causing
traffic on the failed member link to be lost.
Important
To use LACP successfully, you must enable LACP on both peer systems.
LACP mode
The LACP Mode setting appears on the Trunks screen only when you
check the LACP setting. You use the LACP mode setting to specify the
method that LACP uses to send control packets to the peer system. The two
possible modes are:
◆
Active mode
You specify Active mode if you want the system to periodically send
control packets, regardless of whether the peer system has issued a
request. This is the default setting.
◆
Passive mode
You specify Passive mode if you want the system to send control packets
only when the peer system issues a request, that is, when the LACP mode
of the peer system is set to Active.
If you set only one of the peer systems to Active mode, the BIG-IP system
uses Active mode for both systems. Also, whenever you change the LACP
mode on a trunk, LACP renegotiates the links that it uses for aggregation on
that trunk.
Tip
We recommend that you set the LACP mode to Passive on one peer system
only. If you set both systems to Passive mode, LACP does not send control
packets.
21 - 4
Trunks
LACP timeout
The LACP Timeout setting appears on the Trunks screen only when you
check the LACP setting. You use the LACP Timeout setting to indicate to
the BIG-IP system the interval in seconds at which the peer system should
send control packets. The timeout value applies only when the LACP mode
is set to Active on at least one of the switch systems. If both systems are set
to Passive mode, LACP does not send control packets.
If LACP sends three consecutive control packets without receiving a
response from the peer system, LACP removes that member link from link
aggregation.
The two possible timeout values are:
◆
Short
When you set the timeout value to Short, the peer system sends LACP
control packets once every second. If this value is set to Short and LACP
receives no peer response after sending three consecutive packets, LACP
removes the link from aggregation in three seconds.
◆
Long
When you set the timeout value to Long, the peer system sends LACP
control packets once every 30 seconds. A timeout value of Long is the
default setting. If set to Long and LACP receives no peer response after
sending three consecutive packets, LACP removes the link from
aggregation in ninety seconds.
Whenever you change the LACP timeout value on a trunk, LACP
renegotiates the links that it uses for aggregation on that trunk.
Link selection policy
In order for the BIG-IP system to aggregate links, the media speed and
duplex mode of each link must be the same on both peer systems. Because
media properties can change dynamically, the BIG-IP system monitors these
properties regularly, and if it finds that the media properties of a link are
mismatched on the peer systems, the BIG-IP system must determine which
links are eligible for aggregation.
The way the system determines eligible links depends on a link selection
policy that you choose for the trunk. When you create a trunk, you can
choose one of two possible policy settings: Auto and Maximum
Bandwidth.
Note
The link selection policy feature represents an F5 Networks enhancement to
the standard IEEE 802.3ad specification for LACP.
BIG-IP® TMOS®: Concepts
21 - 5
Chapter 21
Automatic link selection
When you set the link selection policy to Auto (the default setting), the
BIG-IP system uses the lowest-numbered interface of the trunk as a
reference link. (A reference link is a link that the BIG-IP system uses to
make a link aggregation decision.) The system then aggregates any links
that have the same media properties and are connected to the same peer as
the reference link.
For example, using Figure 21.1, on page 21-1, suppose that you created a
trunk to include interfaces 1.2 and 1.3, each with a media speeds of 100
Mbps, and interface 1.4, with a different media speed of 1 Gbps. If you set
the link selection policy to Auto, the BIG-IP system uses the
lowest-numbered interface, 1.2, as a reference link. The reference link
operates at a media speed of 100 Mbps, which means that the system
aggregates all links with that media speed (interfaces 1.2 and 1.3). The
media speed of interface 1.4 is different (1 Gbps), and therefore is not
considered for link aggregation. Only interfaces 1.2 and 1.3 become
working member links and start carrying traffic.
If the media speed of interface 1.4 changes to 100 Mbps, the system adds
that interface to the aggregation. Conversely, if the media speed of interface
1.4 remains at 1 Gbps, and the speed of the reference link changes to 1
Gbps, then interfaces 1.2 and 1.4 become working members, and 1.3 is now
excluded from the aggregation and no longer carries traffic.
Maximum bandwidth link selection
When you set the link selection policy to Maximum Bandwidth, the
BIG-IP system aggregates the subset of member links that provide the
maximum amount of bandwidth to the trunk.
Continuing with our previous example, if interfaces 1.2 and 1.3 each operate
at a media speed of 100 Mbps, and interface 1.4 operates at speed of 1 Gbps,
then the system selects only interface 1.4 as a working member link,
providing 1 Gbps of bandwidth to the trunk. If the speed of interface 1.4
drops to 10 Mbps, the system then aggregates links 1.2 and 1.3, to provide a
total bandwidth to the trunk of 200 Mbps. The peer system detects any
non-working member links and configures its aggregation accordingly.
Tip
To ensure that link aggregation operates properly, make sure that both peer
systems agree on the link membership of their trunks.
21 - 6
Trunks
Frame distribution hash
When frames are transmitted on a trunk, they are distributed across the
working member links. The distribution function ensures that the frames
belonging to a particular conversation are neither mis-ordered nor
duplicated at the receiving end.
The BIG-IP system distributes frames by calculating a hash value based on
the source and destination addresses (or the destination address only) carried
in the frame, and associating the hash value with a link. All frames with a
particular hash value are transmitted on the same link, thereby maintaining
frame order. Thus, the system uses the resulting hash to determine which
interface to use for forwarding traffic.
The Frame Distribution Hash setting specifies the basis for the hash that
the system uses as the frame distribution algorithm.
The default value is Source/Destination IP address.
Possible values for this setting are:
BIG-IP® TMOS®: Concepts
◆
Source/Destination MAC address
This value specifies that the system bases the hash on the combined
MAC addresses of the source and the destination.
◆
Destination MAC address
This value specifies that the system bases the hash on the MAC address
of the destination.
◆
Source/Destination IP address
This value specifies that the system bases the hash on the combined IP
addresses of the source and the destination.
21 - 7
Chapter 21
21 - 8
22
VLANs and VLAN Groups
• Introduction to virtual LANs
• VLANs on a BIG-IP system
• VLAN groups
• VLAN association with a self IP address
• VLAN assignment to route domains
VLANs and VLAN Groups
Introduction to virtual LANs
A 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:
• Reduce the size of broadcast domains, thereby enhancing overall
network performance.
• Reduce system and network maintenance tasks substantially.
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.
The way that you group hosts into VLANs is by using the Configuration
utility to create a VLAN and associate physical interfaces with that VLAN.
In this way, 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.
To configure and manage VLANs and VLAN groups, log in to the BIG-IP
Configuration utility, and on the Main tab, expand Network, and click
VLANs.
BIG-IP® TMOS®: Concepts
22 - 1
Chapter 22
VLANs on a BIG-IP system
The BIG-IP system is a port-based switch that includes multilayer
processing capabilities. These capabilities enhance standard VLAN
behavior, in these ways:
• You can associate physical interfaces on the BIG-IP system directly with
VLANs. In this way, you can associate multiple interfaces with a single
VLAN, or you can associate a single interface with multiple VLANs.
• You do not need physical routers to establish communication between
separate VLANs. Instead, the BIG-IP system can process messages
between VLANs.
• You can incorporate a BIG-IP system into existing, multi-vendor
switched environments, due to the BIG-IP system’s compliance with the
IEEE 802.1q VLAN standard.
• You can combine two or more VLANs into an object known as a VLAN
group. With a VLAN group, a host in one VLAN can communicate with
a host in another VLAN using a combination of Layer 2 forwarding and
IP routing. This offers both performance and reliability benefits.
Understanding the default VLAN configuration
By default, the BIG-IP system includes two VLANs, named internal and
external. When you initially ran the Setup utility, you assigned the
following to each of these VLANs:
• A static and a floating self IP address
• A VLAN tag
• One or more BIG-IP system interfaces
A typical VLAN configuration is one in which you create the two VLANs
external and internal, and one or more BIG-IP system interfaces assigned
to each VLAN. You then create a virtual server, and associate a default load
balancing pool with that virtual server. Figure 22.1, on page 22-3, shows a
typical configuration using the default VLANs external and internal.
22 - 2
VLANs and VLAN Groups
Figure 22.1 A typical configuration using the default VLANs
Note
VLANs internal and external reside in partition Common.
Every VLAN must have a static self IP address associated with it. The self
IP address of a VLAN represents an address space, that is, the range of IP
addresses pertaining to the hosts in that VLAN. When you ran the Setup
utility earlier, you assigned one static self IP address to the VLAN external,
and one static self IP address to the VLAN internal. When sending a
request to a destination server, the BIG-IP system can use these self IP
addresses to determine the specific VLAN that contains the destination
server.
For example, suppose the self IP address of VLAN external is 12.1.0.100,
and the self IP address of the VLAN internal is 11.1.0.100, and both self IP
addresses have a netmask of 255.255.0.0. If the IP address of the destination
server is 11.1.0.20, then the BIG-IP system can compare the self IP
addresses to the host’s IP address to determine that the destination server is
BIG-IP® TMOS®: Concepts
22 - 3
Chapter 22
in the VLAN internal. This process, combined with checking the ARP
cache and a VLAN’s L2 forwarding table, ensures that the BIG-IP system
successfully sends the request to the destination server.
Note
By default, the MAC address that the BIG-IP system assigns to a VLAN self
IP address is the MAC address of the lowest-numbered interface associated
with that VLAN. You can change this behavior by configuring the bigdb
configuration key Vlan.MacAssignment.
VLANs reside in administrative partitions. To create a VLAN, first set the
current partition to the partition in which you want the VLAN to reside.
Important
In addition to configuring VLAN properties, you must also assign a self IP
address to the VLAN.
VLAN name
When creating a VLAN, you must assign it a unique name. Once you have
finished creating the VLAN, the VLAN name appears in the list of existing
VLANs.
VLAN tags
A VLAN tag is a unique ID number that you assign to a VLAN. If you do
not explicitly assign a tag to a VLAN, the BIG-IP system assigns a tag
automatically. The value of a VLAN tag can be between 1 and 4094. Once
you or the BIG-IP assigns a tag to a VLAN, any message sent from a host in
that VLAN includes this VLAN tag as a header in the message.
A VLAN tag is useful when an interface has multiple VLANs associated
with it; that is, when the interfaces you assigned to the VLAN are assigned
as tagged interfaces. In this case, the BIG-IP system can read the VLAN tag
in the header of a message to determine the specific VLAN in which the
source or destination host resides. For more information on tagged
interfaces, see Tag-based access to VLANs, on page 22-5.
Important
If the device connected to a BIG-IP system interface is another switch, the
VLAN tag that you assign to the VLAN on the BIG-IP system interface must
match the VLAN tag assigned to the VLAN on the interface of the other
switch.
22 - 4
VLANs and VLAN Groups
Interface assignments
For each VLAN that you create, you must assign one or more BIG-IP
system interfaces to that VLAN, using the Interfaces setting. When you
assign an interface to a VLAN, you indirectly control the hosts from which
the BIG-IP system interface sends or receives messages.
Tip
You can assign not only individual interfaces to the VLAN, but also trunks.
For example, if you assign interface 1.11 to VLAN A, and you then
associate VLAN A with a virtual server, then the virtual server sends its
outgoing traffic through interface 1.11, to a destination host in VLAN A.
Similarly, when a destination host sends a message to the BIG-IP system,
the host’s VLAN membership determines the BIG-IP system interface that
should receive the incoming traffic.
Each VLAN has a MAC address. The MAC address of a VLAN is the same
MAC address of the lowest-numbered interface assigned to that VLAN.
The BIG-IP system supports two methods for sending and receiving
messages through an interface that is a member of one or more VLANs.
These two methods are port-based access to VLANs and tag-based access to
VLANs. The method used by a VLAN is determined by the way that you
add a member interface to a VLAN.
Port-based access to VLANs
With port-based access to VLANs, the BIG-IP system accepts frames for a
VLAN simply because they are received on an interface that is a member of
that VLAN. With this method, an interface is an untagged member of the
VLAN. Frames sent out through untagged interfaces contain no tag in their
header.
Port-based access to VLANs occurs when you add an interface to a VLAN
as an untagged interface. In this case, the VLAN is the only VLAN that you
can associate with that interface. This limits the interface to accepting traffic
only from that VLAN, instead of from multiple VLANs. If you want to give
an interface the ability to accept and receive traffic for multiple VLANs, you
add the same interface to each VLAN as a tagged interface. The following
section describes tagged interfaces.
Tag-based access to VLANs
With tag-based access to VLANs, the BIG-IP system accepts frames for a
VLAN because the frames have tags in their headers and the tag matches the
VLAN identification number for the VLAN. An interface that accepts
frames containing VLAN tags is a tagged member of the VLAN. Frames
sent out through tagged interfaces contain a tag in their header.
Tag-based access to VLANs occurs when you add an interface to a VLAN
as a tagged interface. You can add the same tagged interface to multiple
VLANs, thereby allowing the interface to accept traffic from each VLAN
with which the interface is associated.
BIG-IP® TMOS®: Concepts
22 - 5
Chapter 22
When you add an interface to a VLAN as a tagged interface, the BIG-IP
system associates the interface with the VLAN identification number, or
tag, which becomes embedded in a header of a frame.
Note
Every VLAN has a tag. You can assign the tag explicitly when creating the
VLAN, or the BIG-IP system assigns it automatically if you do not supply
one.
Each time you add an interface to a VLAN, either when creating a VLAN or
modifying its properties, you can designate that interface as a tagged
interface. A single interface can therefore have multiple tags associated with
it.
The result is that whenever a frame comes into that interface, the interface
reads the tag that is embedded in a header of the frame. If the tag in the
frame matches any of the tags associated with the interface, the interface
accepts the frame. If the tag in the frame does not match any of the tags
associated with the interface, the interface rejects the frame.
Example
Figure 22.2, on page 22-6, shows the difference between using three
untagged interfaces (where each interface must belong to a separate VLAN)
versus one tagged interface (which belongs to multiple VLANs).
Figure 22.2 Solutions using untagged (left) and tagged interfaces (right)
The configuration on the left shows a BIG-IP system with three internal
interfaces, each a separate, untagged interface. This is a typical solution for
supporting three separate customer sites. In this scenario, each interface can
accept traffic only from its own VLAN.
22 - 6
VLANs and VLAN Groups
Conversely, the configuration on the right shows a BIG-IP system with one
internal interface and an external switch. The switch places the internal
interface on three separate VLANs. The interface is configured on each
VLAN as a tagged interface. In this way, the single interface becomes a
tagged member of all three VLANs, and accepts traffic from all three. The
configuration on the right is the functional equivalent of the configuration
on the left.
Important
If you are connecting another switch into a BIG-IP system interface, the
VLAN tag that you assign to the VLAN on the BIG-IP system must match the
VLAN tag on the interface of the other switch.
Source checking
When you enable source checking, the BIG-IP system verifies that the
return path for an initial packet is through the same VLAN from which the
packet originated. Note that the system only enables source checking if the
global setting Auto Last Hop is disabled.
Maximum transmission units
The value of the maximum transmission unit, or MTU, is the largest size
that the BIG-IP system allows for an IP datagram passing through a BIG-IP
system interface. The default value is 1500.
VLAN-based fail-safe
VLAN fail-safe is a feature you enable when you want to base
redundant-system failover on VLAN-related events. To configure VLAN
fail-safe, you specify a timeout value and the action that you want the
system to take when the timeout period expires.
Auto last hop
When you create a VLAN, you can designate the VLAN as the last hop for
TMM traffic.
BIG-IP® TMOS®: Concepts
22 - 7
Chapter 22
Maintaining the L2 forwarding table
Layer 2 forwarding is the means by which frames are exchanged directly
between hosts, with no IP routing required. This is accomplished using a
simple forwarding table for each VLAN. The L2 forwarding table is a list
that shows, for each host in the VLAN, the MAC address of the host, along
with the interface that the BIG-IP system needs for sending frames to that
host. The intent of the L2 forwarding table is to help the BIG-IP system
determine the correct interface for sending frames, when the system
determines that no routing is required.
The format of an entry in the L2 forwarding table is:
<MAC address> -> <if>
For example, an entry for a host in the VLAN might look like this:
00:a0:c9:9e:1e:2f -> 2.1
The BIG-IP system learns the interfaces that correspond to various MAC
entries as frames pass through the system, and automatically adds entries to
the table accordingly. These entries are known as dynamic entries. You can
also add entries to the table manually, and these are known as static entries.
Entering static entries is useful if you have network devices that do not
advertise their MAC addresses. The system does not automatically update
static entries.
The BIG-IP system does not always need to use the L2 forwarding table to
find an interface for frame transmission. For instance, if a VLAN has only
one interface assigned to it, then the BIG-IP system automatically uses that
interface.
Occasionally, the L2 forwarding table does not include an entry for the
destination MAC address and its corresponding BIG-IP system interface. In
this case, the BIG-IP system floods the frame through all interfaces
associated with the VLAN, until a reply creates an entry in the L2
forwarding table.
22 - 8
VLANs and VLAN Groups
VLAN groups
A VLAN group is a logical container that includes two or more distinct
VLANs. VLAN groups are intended for load balancing traffic in a Layer 2
network, when you want to minimize the reconfiguration of hosts on that
network. Figure 22.3 shows an example of a VLAN group.
Figure 22.3 Example of a VLAN group
A VLAN group also ensures that the BIG-IP system can process traffic
successfully between a client and server when the two hosts reside in the
same address space. Without a VLAN group, when the client and server
both reside in the same address space, the client request goes through the
virtual server, but instead of sending its response back through the virtual
server, the server attempts to send its response directly to the client,
bypassing the virtual server altogether. As a result, the client cannot receive
the response, because the client expects the address of the response to be the
virtual server IP address, not the server IP address.
Tip
You can configure the behavior of the BIG-IP system so that it always
creates a proxy for any ARP requests between VLANs.
When you create a VLAN group, the two existing VLANs become child
VLANs of the VLAN group.
BIG-IP® TMOS®: Concepts
22 - 9
Chapter 22
VLAN groups reside in administrative partitions. To create a VLAN group,
you must first set the current partition to the partition in which you want the
VLAN group to reside.
Note
Only users with the Administrator user role can create and manage VLAN
groups.
VLAN group name
When creating a VLAN group, you must assign it a unique name. Once you
have finished creating the VLAN group, the VLAN group name appears in
the list of existing VLANs groups.
VLAN group ID
A VLAN group ID is a tag for the VLAN group. Every VLAN group needs
a unique ID number. If you do not specify an ID for the VLAN group, the
BIG-IP system automatically assigns one. The value of a VLAN group ID
can be between 1 and 4094. For more information on VLAN tags, see
Tag-based access to VLANs, on page 22-5.
Transparency mode
The BIG-IP system is capable of processing traffic using a combination of
Layer 2 and Layer 3 forwarding, that is, switching and IP routing. When you
set the transparency mode, you specify the type of forwarding that the
BIG-IP system performs when forwarding a message to a host in a VLAN.
The default setting is translucent, which means that the BIG-IP system uses
a mix of Layer 2 and Layer 3 processing. Table 22.1 lists the allowed
values.
Value
Description
opaque
A proxy ARP with Layer 3 forwarding.
Table 22.1 Modes for VLAN group forwarding
22 - 10
VLANs and VLAN Groups
Value
Description
translucent
Layer 2 forwarding with a locally-unique bit, toggled in ARP
response across VLANs. This is the default setting. When you
choose this value and you have a virtual server that references
a Fast L4 profile, the BIG-IP system automatically changes the
PVA Acceleration setting to None.
transparent
Layer 2 forwarding with the original MAC address of the
remote system preserved across VLANs. When you choose
this value and you have a virtual server that references a Fast
L4 profile, the BIG-IP system automatically changes the PVA
Acceleration setting to None.
Table 22.1 Modes for VLAN group forwarding
Traffic bridging
When you enable this option, you are instructing the VLAN group to
forward all non-IP traffic. Note that IP traffic is bridged by default. The
default value for this setting is disabled (unchecked).
Traffic bridging with standby units
When enabled, the Bridge in Standby setting ensures that the VLAN group
can forward packets when the system is the standby device of a redundant
system configuration. Note that this setting applies to non-IP and non-ARP
frames only, such as Bridge Protocol Data Units (BPDUs).
This setting is designed for deployments in which the VLAN group is
defined on a redundant system. You can use the Bridge in Standby setting
in transparent or translucent modes, or in opaque mode when the global
variable Failover.Standby.LinkDownTime is set to 0.
WARNING
This setting can cause adverse effects if the VLAN group exists on more than
one device in a device group. The setting is intended for configurations
where the VLAN group exists on one device only. The default setting is
enabled (checked).
Host exclusion from proxy ARP forwarding
A host in a VLAN cannot normally communicate to a host in another
VLAN. This rule applies to ARP requests as well. However, if you put the
VLANs into a single VLAN group, the BIG-IP system can perform a
proxied ARP request.
A proxied ARP request is an ARP request that the BIG-IP system can send,
on behalf of a host in a VLAN, to hosts in another VLAN. A proxied ARP
request requires that both VLANs belong to the same VLAN group.
BIG-IP® TMOS®: Concepts
22 - 11
Chapter 22
In some cases, you might not want a host to forward proxied ARP requests
to a specific host, or to other hosts in the configuration. To exclude specific
hosts from receiving forwarded proxied ARP requests, you use the
Configuration utility and specify the IP addresses that you want to exclude.
WARNING
Although hosts on an ARP exclusion list are specified using their IP
addresses, this does not prevent the BIG-IP system from routing traffic to
those hosts. A more secure way to prevent traffic from passing between
hosts in separate VLANs is to create a packet filter for each VLAN.
VLAN association with a self IP address
After you create a VLAN or a VLAN group, you must associate it with a
self IP address. You associate a VLAN or VLAN group with a self IP
address using the New Self IPs screens of the Configuration utility:
◆
Associating a VLAN with a self IP address
The self IP address with which you associate a VLAN should represent
an address space that includes the IP addresses of the hosts that the
VLAN contains. For example, if the address of one host is 11.0.0.1 and
the address of the other host is 11.0.0.2, you could associate the VLAN
with a self IP address of 11.0.0.100, with a netmask of 255.255.255.0.
◆
Associating a VLAN group with a self IP address
The self IP address with which you associate a VLAN group should
represent an address space that includes the self IP addresses of the
VLANs that you assigned to the group. For example, if the address of
one VLAN is 10.0.0.1 and the address of the other VLAN is 10.0.0.2,
you could associate the VLAN group with a self IP address of
10.0.0.100, with a netmask of 255.255.255.0.
VLAN assignment to route domains
If you explicitly create route domains, you should consider the following:
• You can assign VLANs (and VLAN groups) to route domain objects that
you create. Traffic pertaining to that route domain uses those assigned
VLANs,
• During BIG-IP system installation, the system automatically creates a
default route domain, with an ID of 0. Route domain 0 has two VLANs
assigned to it, VLAN internal and VLAN external.
• If you create one or more VLANs in an administrative partition other
than Common, but do not create a route domain in that partition, then the
VLANs you create in that partition are automatically assigned to route
domain 0.
22 - 12
A
Troubleshooting SNMP Traps
• Understanding F5-specific traps
Troubleshooting SNMP Traps
Understanding F5-specific traps
The alert system and the SNMP agent on the BIG-IP® system can send a
number of notifications about the current operation of the BIG-IP system.
The definitions of these notifications are known as traps, and are contained
in the MIB file F5-BIGIP-COMMON-MIB.txt.
The types of notifications that the BIG-IP system can send to an SNMP
manager are:
• General traps
• Hardware-related traps
• License-related traps
• Traffic management operating system® (TMOS®)-related traps
• Authentication-related traps
• Denial of Service (DoS)-related traps
• Network-related traps
• Logging-related traps
• Application Security ManagerTM-related traps
• Global Traffic Manager™-related traps
• Other traps
The remainder of this appendix contains tables that list the trap names
contained in the MIB file F5-BIGIP-COMMON-MIB.txt, their
descriptions, and the recommended action to take if you receive one of these
notifications on your SNMP manager system.
General traps
The general notifications that you might receive on an SNMP manager
system are listed and described in Table A.1.
Trap Name
Description
bigipAgentStart
The SNMP agent on the BIG-IP
system has been started.
bigipAgentShutdown
The SNMP agent on the BIG-IP
system is in the process of being
shut down.
bigipAgentRestart
The SNMP agent on the BIG-IP
system has been restarted.
Recommended Action
For your information only. No action
required.
This trap is for future use only.
Table A.1 General traps and recommended actions
BIG-IP® TMOS®: Concepts
A-1
Appendix A
Trap Name
Description
Recommended Action
bigipDiskPartitionWarn
Free space on the disk partition is
limited, that is, less than a specified
limit. By default, the limit is set to
30% of total disk space.
Increase the available disk space.
bigipDiskPartitionGrowth
The disk partition use exceeds the
specified growth limit. By default, the
limit is set to 5% of the total disk
space.
Table A.1 General traps and recommended actions
Hardware-related traps
The hardware-related notifications that you might receive on an SNMP
manager system are listed and described in Table A.2.
Trap Name
Description
Recommended Action
bigipCpuTempHigh
The CPU temperature is too high.
Check the CPU and air temperatures. For
BIG-IP platforms C36, D39, D44, D45,
D50, D51, D51C, and D62, the threshold
is 75 degrees Celsius. For the BIG-IP
platform C62, the threshold is 80 degrees
Celsius. If the condition persists, contact
F5 Networks® technical support.
bigipCpuFanSpeedLow
The CPU fan speed is too low.
Check the CPU temperature. If the CPU
temperature is normal, the condition is not
critical. For BIG-IP platforms C36, C62,
D39, D44, D45, D50, D51, D51C, and
D62, the threshold is 3000 RPM.
bigipCpuFanSpeedBad
The CPU fan is not receiving a
signal.
Check the CPU temperature and verify
that the CPU fan is plugged in and
receiving power. If the CPU temperature is
normal, the condition is not critical.
bigipChassisTempHigh
The temperature of the chassis is too
high.
Check the chassis and air temperatures.
For BIG-IP platforms C36, D39, D44, D45,
D50, D51, D51C, D62, and C62
switchboard, the threshold is 75 degrees
Celsius. For the BIG-IP platform C62
non-switchboard, the threshold is 95
degrees Celsius for one chassis and 80
degrees Celsius for the other chassis. If
the condition persists, contact F5
Networks technical support.
bigipChassisFanBad
The chassis fan is not operating
properly.
Check the chassis temperature. Also
check that the fan is receiving power, or
replace the fan.
Table A.2 Hardware-related traps and recommended actions
A-2
Troubleshooting SNMP Traps
Trap Name
Description
Recommended Action
bigipChassisPowerSupplyBad
The chassis power supply is not
functioning properly.
Verify that the power supply is plugged in,
or contact F5 Networks technical support.
For a dual-power-supply system, one
power supply might not be plugged in.
bigipHardDiskFailure
The hard disk is failing.
Power off the system and replace the hard
disk. Contact F5 Networks technical
support.
Table A.2 Hardware-related traps and recommended actions
License-related traps
The notifications related to licensing that you might receive on an SNMP
manager system are listed and described in Table A.3.
Trap Name
Description
Recommended Action
bigipLicenseFailed
Validation of a BIG-IP system license
has failed, or the dossier has errors.
Occurs only when first licensing the
system or adding a module key (such
as HTTP compression) to an existing
system.
If using automatic licensing, verify
connectivity to the outside world, fix the
dossier if needed, and try again.
bigipLicenseExpired
The BIG-IP license has expired.
Call F5 Networks technical support.
Table A.3 License traps and recommended actions
TMOS-related traps
The TMOS-related notifications that you might receive on an SNMP
manager system are listed and described in Table A.4.
Trap Name
Description
Recommended Action
bigipServiceDown
A BIG-IP system health monitor has
detected a service on a node to be
stopped and has therefore marked
the node as down.
Restart the service on the node.
bigipServiceUp
A BIG-IP system health monitor has
detected a service on a node to be
running and has therefore marked
the node as up.
For your information only. No action
required./
bigipNodeDown
A BIG-IP system health monitor has
marked a node as down.
Check the node and the cable connection.
Table A.4 TMOS-related traps and recommended actions
BIG-IP® TMOS®: Concepts
A-3
Appendix A
Trap Name
Description
Recommended Action
bigipNodeUp
A BIG-IP system health monitor has
marked a node as up.
For your information only. No action
required.
bigipStandby
The BIG-IP system has switched to
standby mode.
Review the log files in the /var/log
directory and then search for core files in
the /var/core directory. If you find a core
file, or find text similar to fault at location
xxxx stack trace:, contact F5 Networks
technical support.
bigipStandByFail
In failover condition, this standby
system cannot become active.
Investigate failover condition on the
standby system.
bigipActive
The BIG-IP system has switched to
active mode.
For your information only. No action
required.
bigipActiveActive
The BIG-IP system is in
active-active mode.
bigipFeatureFailed
A high-availability feature has failed.
View high-availability processes and their
current status.
bigipFeatureOnline
A high-availability feature is
responding.
For your information only. No action
required.
bigipPacketRejected
The BIG-IP system has rejected
some packets.
Check the detailed message within this
trap and act accordingly.
bigipInetPortExhaustion
Signifies that the TMM has run out of
source ports and cannot open new
communications channels with other
machines.
Either increase the number of addresses
available for SNAT automapping or SNAT
pools, or lower the idle timeout value if the
value is excessively high.
Table A.4 TMOS-related traps and recommended actions
Authentication-related traps
The notifications related to authentication that you might receive on an
SNMP manager system are listed and described in Table A.5.
Trap Name
Description
Recommended Action
bigipTamdAlert
More than 60 authentication attempts
have failed within one second, for a
given virtual server.
Investigate for a possible intruder.
bigipAuthFailed
A login attempt failed.
Check the user name and password.
Table A.5 Authentication traps and recommended actions
A-4
Troubleshooting SNMP Traps
DoS-related traps
The notifications related to denial of service that you might receive on an
SNMP manager system are listed and described in Table A.6.
Trap Name
Description
Recommended Action
bigipAggrReaperStateChange
The state of the aggressive reaper
has changed, indicating that the
BIG-IP system is moving to a
distress mode.
We recommend that you use our default
Denial of Service settings. However, you
can add rate filters to survive the attack.
Table A.6 Denial of Service traps and recommended actions
Network-related traps
The network-related notifications that you might receive on an SNMP
manager system are listed and described in Table A.7.
Trap Name
Description
Recommended Action
bigipARPConflict
The BIG-IP system has detected an
ARP advertisement for any of its own
ARP-enabled addresses. This can
occur for a virtual server address or a
self IP address.
Check IP addresses and routes.
bigipNetLinkDown
An interface link is down. This
applies to L1 and L2, which are
internal links within the box
connecting the CPU and Switch
subsystems. These links should
never be down. If this occurs, the
condition is serious.
Contact F5 Networks technical support.
Table A.7 Network traps and recommended actions
BIG-IP® TMOS®: Concepts
A-5
Appendix A
Logging-related traps
The notifications related to logging that you might receive on an SNMP
manager system are listed and described in Table A.8.
Trap Name
Description
Recommended Action
bigipLogEmerg
The BIG-IP system is unusable. This
notification occurs when the system
logs a message with the log level
LOG_EMERG.
Check the detailed message within this
trap and within the /var/log files to
determine which process has the
emergency.
Then act accordingly.
bigipLogAlert
bigipLogCrit
You must take action immediately for
the BIG-IP system to function
properly. This notification occurs
when the system logs a message
with the log level LOG_ALERT.
Check the detailed message within this
trap and within the /var/log files to
determine which process has the alert
situation.
The BIG-IP system is in a critical
condition. This notification occurs
when the system logs a message
with the log level LOG_CRIT.
Check the detailed message within this
trap and within the /var/log files to
determine which process has the critical
situation.
Then act accordingly.
Then act accordingly.
bigipLogErr
The BIG-IP system has some error
conditions. This notification occurs
when the system logs a message
with the log level LOG_ERR.
Check the detailed message within this
trap and within the /var/log files to
determine which processes have the error
conditions.
Then act accordingly.
bigipLogWarning
The BIG-IP system is experiencing
some warning conditions. This
notification occurs when the system
logs a message with the log level
LOG_WARNING.
Check the detailed message within this
trap and within the /var/log files to
determine which processes have the
warning conditions.
Then act accordingly.
Table A.8 Logging-related traps and recommended actions
Note
You can also view logging information using the Logs screen of the
Configuration utility.
A-6
Troubleshooting SNMP Traps
Application Security Manager-related traps
The notifications related to Application Security Manager that you might
receive on an SNMP manager system are listed and described in Table A.9.
Trap Name
Description
Recommended Action
bigipAsmRequestBlocked
The system blocked an HTTP
request because the request
contained at least one violation to the
active security policy.
Check the HTTP request to determine the
cause of the violation.
bigipAsmRequestViolation
The system issued an alert because
an HTTP request violated the active
security policy.
Check the HTTP request to determine the
cause of the violation.
Table A.9 Application Security Manager traps and recommended actions
Global Traffic Manager-related traps
The notifications related to BIG-IP Global Traffic Manager that you might
receive on an SNMP manager system are listed and described in Table A.10.
Trap Name
Description
Recommended Action
bigipGtmBoxAvail
A Global Traffic Manager system
(which equals an iquery connection to
a server box) has gone UP.
For your information only.
bigipGtmBoxNotAvail
A Global Traffic Manager system
(which equals an iquery connection to
a server box) has gone DOWN.
For your information only.
bigipGtmBig3dSslCertExpired
The certificate
/config/big3d/client.crt has expired.
Replace the certificate.
bigipGtmBig3dSslCertWillExpire
The certificate
/config/big3d/client.crt will expire
soon.
Replace the certificate.
bigipGtmSslCertExpired
The certificate /config/gtm/server.crt
has expired.
Replace the certificate.
bigipGtmSslCertWillExpire
The certificate /config/gtm/server.crt
will expire soon.
Replace the certificate.
bigipGtmPoolAvail
A pool is becoming available in the
Global Traffic Manager module.
For your information only. No action
required.
bigipGtmPoolNotAvail
A pool is becoming unavailable in the
Global Traffic Manager module.
Check the status of the pool, as well as
the relevant detailed log message.
Table A.10 Global Traffic Manager traps and recommended actions
BIG-IP® TMOS®: Concepts
A-7
Appendix A
Trap Name
Description
Recommended Action
bigipGtmPoolDisabled
A pool is disabled in the Global Traffic
Manager module.
Check the status of the pool.
bigipGtmPoolEnabled
A pool is enabled in the Global Traffic
Manager module.
For your information only. No action
required.
bigipGtmLinkAvail
A link is becoming available in the
Global Traffic Manager module.
bigipGtmLinkNotAvail
A link is becoming unavailable in the
Global Traffic Manager module.
Check the status of the link, as well as
the relevant detailed log message.
bigipGtmLinkDisabled
A link is disabled in the Global Traffic
Manager module.
Check the status of the link.
bigipGtmLinkEnabled
A link is enabled in the Global Traffic
Manager module.
For your information only. No action
required.
bigipGtmWideIpAvail
A wide IP is becoming available in the
Global Traffic Manager module.
bigipGtmWideIpNotAvail
A wide IP is becoming unavailable in
the Global Traffic Manager module.
Check the status of the wide IP, as well
as the relevant detailed log message.
bigipGtmWideIpDisabled
A wide IP is disabled in the Global
Traffic Manager module.
Check the status of the wide IP.
bigipGtmWideIpEnabled
A wide IP is enabled in the Global
Traffic Manager module.
For your information only. No action
required.
bigipGtmPoolMbrAvail
A pool member is becoming available
in the Global Traffic Manager module.
bigipGtmPoolMbrNotAvail
A pool member is becoming
unavailable in the Global Traffic
Manager module.
Check the status of the pool member,
as well as the relevant detailed log
message.
bigipGtmPoolMbrDisabled
A pool member is disabled in the
Global Traffic Manager module.
Check the status of the pool member.
bigipGtmPoolMbrEnabled
A pool member is enabled in the
Global Traffic Manager module.
For your information only. No action
required.
bigipGtmServerAvail
A server is becoming available in the
Global Traffic Manager module.
bigipGtmServerNotAvail
A server is becoming unavailable in
the Global Traffic Manager module.
Check the status of the server, as well
as the relevant detailed log message.
bigipGtmServerDisabled
A server is disabled in the Global
Traffic Manager module.
Check the status of the server.
Table A.10 Global Traffic Manager traps and recommended actions
A-8
Troubleshooting SNMP Traps
Trap Name
Description
bigipGtmServerEnabled
A server is enabled in the Global
Traffic Manager module.
Recommended Action
For your information only. No action
required.
bigipGtmVsAvail
A virtual server is becoming available
in the Global Traffic Manager module.
bigipGtmVsNotAvail
A virtual server is becoming
unavailable in the Global Traffic
Manager module.
Check the status of the virtual server,
as well as the relevant detailed log
message.
bigipGtmVsDisabled
A virtual server is disabled in the
Global Traffic Manager module.
Check the status of the virtual server.
bigipGtmVsEnabled
A virtual server is enabled in the
Global Traffic Manager module.
For your information only. No action
required.
bigipGtmDcAvail
A data center is becoming available in
the Global Traffic Manager module.
bigipGtmDcNotAvail
A data center is becoming unavailable
in the Global Traffic Manager module.
Check the status of the data center, as
well as the relevant detailed log
message.
bigipGtmDcDisabled
A data center is disabled in the Global
Traffic Manager module.
Check the status of the data center.
bigipGtmDcEnabled
A data center is enabled in the Global
Traffic Manager module.
For your information only. No action
required.
bigipGtmAppObjAvail
An application object is becoming
available in the Global Traffic Manager
module.
bigipGtmAppObjNotAvail
An application object is becoming
unavailable in the Global Traffic
Manager module.
Check the status of the application
object, as well as the relevant detailed
log message.
bigipGtmAppAvail
An application is becoming available in
the Global Traffic Manager module.
For your information only. No action
required.
bigipGtmAppNotAvail
An application is becoming
unavailable in the Global Traffic
Manager module.
Check the status of the application, as
well as the relevant detailed log
message.
bigipGtmJoinedGroup
The Global Traffic Manager module
joined a sync group.
bigipGtmLeftGroup
For your information only. No action
required.
The Global Traffic Manager module
left a sync group.
Table A.10 Global Traffic Manager traps and recommended actions
BIG-IP® TMOS®: Concepts
A-9
Appendix A
Other traps
Other notifications that you might receive on an SNMP manager system are
listed and described in Table A.11.
Trap Name
Description
Recommended Action
bigipCompLimitExceeded
The compression license limit is
exceeded.
Purchase additional compression
licensing from F5 Networks.
bigipSslLimitExceeded
The SSL license limit is exceeded,
either for transactions per second
(TPS) or for megabits per second
(MPS).
Purchase additional SSL licensing from
F5 Networks.
bigipExternalLinkChange
The status of an external interface
link has changed to either DOWN or
UP. This occurs when network
cables are added or removed, and
the network is reconfigured.
Determine whether the link should be
down or up, and then take the appropriate
action.
Table A.11 Other traps and recommended actions
A - 10
Glossary
Glossary
active bonus
An active bonus is an amount that the BIG-IP system automatically adds to
the overall score of the active device. An active bonus ensures that the active
device remains active when the device’s score would otherwise cause
failover because the score temporarily fell below the score of the standby
device. See also HA group.
active device
In a redundant system configuration, an active device is a BIG-IP device on
which at least one traffic group is in an active state.
advanced routing module
This is an industry-standard routing protocol, designed to automatically
update a routing table. The three advanced routing modules are BGP, RIP,
and OSPF. See also BGP (Border Gateway Protocol), RIP (Routing
Information Protocol), OSPF (Open Shortest Path First).
archive
An archive is a backup copy of the BIG-IP system configuration data. This
archive is in the form of a user configuration set, or UCS. See also UCS
(user configuration set).
ARP (Address Resolution Protocol)
ARP is an industry-standard protocol that determines a host’s Media Access
Control (MAC) address based on its IP address.
ARP cache
The ARP (address resolution protocol) cache is the mechanism that a device
on a network uses to determine the MAC address of another device, when
only the IP address of that other device is known.
authentication
Authentication is the process of verifying a user’s identity when the user is
attempting to log on to a system.
authentication iRule
An authentication iRule is a system-supplied or user-created iRule that is
necessary for implementing a PAM authentication module on the BIG-IP
system. See also iRule, PAM (Pluggable Authentication Module).
authentication module
An authentication module is a PAM module that you create to perform
authentication or authorization of client traffic. See also PAM (Pluggable
Authentication Module).
BIG-IP® TMOS®: Concepts
Glossary - 1
Glossary
authentication profile
An authentication profile is a configuration tool that you use to implement a
PAM authentication module. Types of authentication modules that you can
implement with an authentication profile are: LDAP, RADIUS, TACACS+,
SSL Client Certificate LDAP, and OCSP. See also PAM (Pluggable
Authentication Module).
authorization
Authorization is the process of identifying the level of access that a
logged-on user has been granted to system resources.
BGP (Border Gateway Protocol)
A dynamic routing protocol for external networks. See also advanced
routing module.
bigtop
The bigtop utility is a statistical monitoring utility that ships on the BIG-IP
system. This utility provides real-time statistical information.
BIND (Berkeley Internet Name Domain)
BIND is the most common implementation of the Domain Name System
(DNS). BIND provides a system for matching domain names to IP
addresses. For more information, refer to
http://www.isc.org/products/BIND.
Border Gateway Protocol (BGP)
See BGP (Border Gateway Protocol).
BPDU (bridge protocol data unit)
A BPDU is a special packet that a spanning tree protocol sends between
Layer 2 devices to determine redundant paths, and provide loop resolution.
See also STP (Spanning Tree Protocol), RSTP (Rapid Spanning Tree
Protocol), MSTP (Multiple Spanning Tree Protocol).
bridge
A bridge is a Layer 2 networking device that defines a collision domain.
bursting
Bursting is an aspect of rate shaping and occurs when the rate of traffic flow
exceeds the base rate defined.
certificate
A certificate is an online credential signed by a trusted certificate authority
and used for SSL network traffic as a method of authentication.
Glossary - 2
Glossary
certificate authority (CA)
A certificate authority is an external, trusted organization that issues a
signed digital certificate to a requesting computer system for use as a
credential to obtain authentication for SSL network traffic.
certificate revocation list (CRL)
See CRL (certificate revocation list).
Certificate Revocation List Distribution Point (CRLDP)
See CRLDP (Certificate Revocation List Distribution Point).
certificate verification
Certificate verification is the part of an SSL handshake that verifies that a
client’s SSL credentials have been signed by a trusted certificate authority.
chain
A chain is a series of filtering criteria used to restrict access to an IP address.
The order of the criteria in the chain determines how the filter is applied,
from the general criteria first, to the more detailed criteria at the end of the
chain.
chunking
See HTTP chunking.
cipher
A cipher is an encryption/decryption algorithm that computer systems use
when transmitting data using the SSL protocol.
client-side SSL profile
A client-side SSL profile is an SSL profile that controls the behavior of SSL
traffic going from a client system to the BIG-IP system.
clone pool
This feature causes a pool to replicate all traffic coming into it and send that
traffic to a duplicate pool.
CMP (clustered multi-processing)
CMP is an internal performance-enhancement feature available on certain
multi-processor BIG-IP systems. With CMP, the BIG-IP system creates
multiple instances of the TMM service to process application traffic
simultaneously.
BIG-IP® TMOS®: Concepts
Glossary - 3
Glossary
configuration object
A configuration object is a user-created object that the BIG-IP system uses
to implement a PAM authentication module. There is one type of
configuration object for each type of authentication module that you create.
See also PAM (Pluggable Authentication Module).
configuration synchronization
Configuration synchronization is the task of duplicating a BIG-IP system’s
configuration data onto a peer device in a redundant system.
Configuration utility
The Configuration utility is the browser-based application that you use to
configure the BIG-IP system.
connection mirroring
Connection mirroring is a feature that causes all connections coming
through the active device of a redundant system to be replicated on the
standby device. This prevents any interruption in service when failover
occurs.
connection persistence
Connection persistence is an optimization technique whereby a network
connection is intentionally kept open for the purpose of reducing
handshaking.
connection pooling
Connection pooling is an optimization feature that pools server-side
connections for re-use by other client requests. Connection pooling reduces
the number of new connections that must be opened for server-side client
requests.
content switching
Content switching is the ability to select a pool based on data contained
within a packet.
cookie persistence
Cookie persistence is a mode of persistence where the BIG-IP system stores
persistent connection information in a cookie.
CRL (certificate revocation list)
A certificate revocation list is an industry-standard technology. An
authenticating system checks a CRL to see if the SSL certificate that the
requesting system presents for authentication has been revoked.
Glossary - 4
Glossary
CRLDP (Certificate Revocation List Distribution Point)
CRLDP is an industry-standard protocol designed to manage SSL certificate
revocation on a network of systems.
CRLDP authentication module
A CRLDP authentication module is a user-configured module that you
implement on an BIG-IP system to authenticate client traffic using the
CRLDP protocol. The purpose of a CRLDP authentication module is to
manage the revocation of SSL certificates on a network.
custom profile
A custom profile is a profile that you create. A custom profile can inherit its
default settings from a parent profile that you specify. See also parent
profile, profile.
data group
A data group is a group of related elements, such as a set of IP addresses for
AOL clients. When you specify a data group along with the matchclass
command or the contains operator, you eliminate the need to list multiple
values as arguments in an iRule expression.
default profile
A default profile is a profile that the BIG-IP system supplies with default
setting values. You can use a default profile as is, or you can modify it. You
can also specify it as a parent profile when you create a custom profile. You
cannot create or delete a default profile. See also profile, custom profile.
default route
A default route is the route that the system uses when no other route
specified in the routing table matches the destination address or network of
the packet to be routed.
default route domain
A default route domain is a route domain that the system administrator
designates as the default route domain within an administrative partition.
When creating IP addresses that are associated with a default route domain,
users do not need to include the %ID route domain notation in those
addresses. See also route domain 0.
default VLAN
The BIG-IP system is configured with two default VLANs, one for each
interface. One default VLAN is named internal and one is named external.
See also VLAN (virtual local area network).
BIG-IP® TMOS®: Concepts
Glossary - 5
Glossary
default wildcard virtual server
A default wildcard virtual server has an IP address and port number of
0.0.0.0:0. or *:* or "any":"any". This virtual server accepts all traffic that
does not match any other virtual server defined in the configuration.
destination address affinity persistence
Also known as sticky persistence, destination address affinity persistence
supports TCP and UDP protocols, and directs session requests to the same
server based solely on the destination IP address of a packet.
device certificate
A device certificate is an SSL certificate that a BIG-IP system presents to
another device on the network, for authentication purposes. A device
certificate can be either a self-signed certificate or a CA-signed certificate.
domain name
A domain name is a unique name that is associated with one or more IP
addresses. Domain names are used in URLs to identify particular Web
pages. For example, in the URL http://www.siterequest.com/index.html,
the domain name is siterequest.com.
Dynamic Ratio load balancing method
Dynamic Ratio mode is like Ratio mode (see Ratio method), except that
ratio weights are based on continuous monitoring of the servers and are
therefore continually changing. Dynamic Ratio load balancing can be
implemented on RealNetworks® RealServer platforms, on Microsoft®
Windows® platforms equipped with Windows Management Instrumentation
(WMI), or on a server equipped with either the UC Davis SNMP agent or
Windows 2000 Server SNMP agent.
dynamic route
A dynamic route is a route that an advanced routing protocol such as RIP
adds dynamically to a routing table. See also static route.
dynamic routing
Dynamic routing is the automatic updating of a routing table that advanced
routing modules can perform. See also advanced routing module.
EAV (Extended Application Verification)
EAV is a health check that verifies an application on a node by running that
application remotely. EAV health check is only one of the three types of
health checks available on an BIG-IP system. See also health check, health
monitor, external monitor.
Glossary - 6
Glossary
ECV (Extended Content Verification)
ECV is a health check that allows you to determine if a node is up or down
based on whether the node returns specific content. ECV health check is
only one of the three types of health checks available on an BIG-IP system.
See also health check.
external authentication
External authentication refers to the process of using a remote server to store
data for the purpose of authenticating users or applications attempting to
access the BIG-IP system.
external monitor
An external monitor is a user-supplied health monitor. See also health
check, health monitor.
external VLAN
The external VLAN is a default VLAN on the BIG-IP system. In a basic
configuration, this VLAN has the administration ports locked down. In a
normal configuration, this is typically a VLAN on which external clients
request connections to internal servers.
failback
Failback is the process whereby an active device relinquishes processing to
a previously-failed device that is now available.
failover
Failover is the process whereby a standby device in a redundant system
takes over when a software failure or a hardware failure is detected on the
active device.
failover cable
The failover cable directly connects the two units together in a redundant
system.
Fastest method
The Fastest load balancing method is a load balancing method that passes a
new connection based on the fastest response of all currently active nodes.
FDDI (Fiber Distributed Data Interface)
FDDI is a multi-mode protocol used for transmitting data on optical-fiber
cables at speeds up to 100 Mbps.
floating self IP address
A floating self IP address is an additional self IP address for a VLAN that
serves as a shared address by both units of a BIG-IP redundant system.
BIG-IP® TMOS®: Concepts
Glossary - 7
Glossary
forwarding virtual server
A forwarding virtual server is a virtual server that has no pool members to
load balance. The virtual server simply forwards the packet directly to the
destination IP address specified in the client request. See also virtual server.
gateway pool
A gateway pool is a pool of routers that you can create to forward traffic.
After creating a gateway pool, you can specify the pool as a gateway, within
a TMM routing table entry.
HA group
An HA group is a group of objects that the BIG-IP system uses to calculate a
health score for each device in a redundant system configuration. The
system compares the scores of the two units to determine which device
should be the active device. See also active bonus.
hard-wired failover
Hard-wired failover is the process whereby a device of a redundant system
configuration uses a serial connection to its peer to initiate failover. See also
network failover.
hash persistence
Hash persistence allows you to create a persistence hash based on an
existing iRule.
health check
A health check is an BIG-IP system feature that determines whether a node
is up or down. Health checks are implemented through health monitors. See
also health monitor, ECV (Extended Content Verification), EAV (Extended
Application Verification), external monitor.
health monitor
A health monitor checks a node to see if it is up and functioning for a given
service. If the node fails the check, it is marked down. Different monitors
exist for checking different services. See also health check, EAV (Extended
Application Verification), ECV (Extended Content Verification), and
external monitor.
host virtual server
A host virtual server is a virtual server that represents a specific site, such as
an Internet web site or an FTP site, and it load balances traffic targeted to
content servers that are members of a pool.
Glossary - 8
Glossary
HTTP chunking
HTTP chunking refers to the HTTP/ 1.1 feature known as chunked
encoding, which allows HTTP messages to be broken up into several parts.
Chunking is most often used by servers when sending responses.
HTTP redirect
An HTTP redirect sends an HTTP 302 Object Found message to clients.
You can configure a pool with an HTTP redirect to send clients to another
node or virtual server if the members of the pool are marked down.
HTTP transformation
When the BIG-IP system performs an HTTP transformation, the system
manipulates the Connection header of a server-side HTTP request, to
ensure that the connection stays open. See also connection persistence.
ICMP (Internet Control Message Protocol)
ICMP is an Internet communications protocol used to determine information
about routes to destination addresses.
i-mode
i-mode® is a service created by NTT DoCoMo, Inc., that allows mobile
phone users access to the Internet.
intelligent SNAT
An intelligent SNAT is the mapping of one or more original client IP
addresses to a translation address from within an iRule. Before writing an
iRule to create an intelligent SNAT, you must create a SNAT pool. See also
SNAT pool.
interface
A physical port on a BIG-IP system is called an interface.
internal VLAN
The internal VLAN is a default VLAN on the BIG-IP system. In a basic
configuration, this VLAN has the administration ports open. In a normal
configuration, this is a network interface that handles connections from
internal servers.
IPsec
IPsec (IP Security) is a communications protocol that provides security for
the network layer of the Internet without imposing requirements on
applications running above it.
BIG-IP® TMOS®: Concepts
Glossary - 9
Glossary
iRule
An iRule is a user-written script that controls the behavior of a connection
passing through the BIG-IP system. iRules® are an F5 Networks® feature
and are frequently used to direct certain connections to a non-default load
balancing pool. However, iRules can perform other tasks, such as
implementing secure network address translation and enabling session
persistence.
IS-IS (intermediate system to intermediate system)
IS-IS is a dynamic routing protocol used by routers to determine the best
way to forward datagrams through a packet-switched network. See also
advanced routing module.
JAR file
A JAR file is a file in JavaTM Archive (JAR) file format that enables you to
bundle multiple files into a single archive file. Typically, a JAR file contains
the class files and auxiliary resources associated with applets and
applications.
JDBC
JDBC is a JavaTM technology. It is an application programming interface
that provides database management system (DBMS) connectivity across a
wide range of SQL databases, as well as access to other tabular data sources,
such as spreadsheets or flat files.
Kilobytes/Second mode
The Kilobytes/Second mode is a dynamic load balancing mode that
distributes connections based on which available server currently processes
the fewest kilobytes per second.
LACP (Link Aggregation Control Protocol)
LACP is an industry-standard protocol that aggregates links in a trunk, to
increase bandwidth and provide for link failover.
last hop
A last hop is the final hop a connection takes to get to the BIG-IP system.
You can allow the BIG-IP system to determine the last hop automatically to
send packets back to the device from which they originated. You can also
specify the last hop manually by making it a member of a last hop pool.
Layer 1 through Layer 7
Layers 1 through 7 refer to the seven layers of the Open System
Interconnection (OSI) model. Thus, Layer 2 represents the data-link layer,
Layer 3 represents the IP layer, and Layer 4 represents the transport layer
(TCP and UDP). Layer 7 represents the application layer, handling traffic
such as HTTP and SSL.
Glossary - 10
Glossary
Layer 2 forwarding table
A Layer 2 forwarding table correlates MAC addresses of network devices to
the BIG-IP system interfaces through which those devices are accessible.
On a BIG-IP system, each VLAN has its own Layer 2 forwarding table.
LDAP (Lightweight Directory Access Protocol)
LDAP is an Internet protocol that email programs use to look up contact
information from a server.
LDAP authentication module
An LDAP authentication module is a user-configured module that you
implement on an BIG-IP system to authenticate client traffic using a remote
LDAP server.
LDAP client certificate SSL authentication module
An LDAP client certificate SSL authentication module is a user-configured
module that you implement on an BIG-IP system to authorize client traffic
using SSL client credentials and a remote LDAP server.
Least Connections method
The Least Connections method is a load balancing method that bases
connection distribution on which server currently manages the fewest open
connections.
link aggregation
Link aggregation is the process of combining multiple links in order to
function as though it were a single link with higher bandwidth. Link
aggregation occurs when you create a trunk. See also trunk and LACP (Link
Aggregation Control Protocol).
Link Aggregation Control Protocol (LACP)
See LACP (Link Aggregation Control Protocol).
load balancing method
A load balancing method is a particular algorithm that the BIG-IP system
uses for determining how to distribute connections across a load balancing
pool.
load balancing pool
See pool.
local traffic management
Local traffic management is the process of managing network traffic that
comes into or goes out of a local area network (LAN), including an intranet.
BIG-IP® TMOS®: Concepts
Glossary - 11
Glossary
loopback adapter
A loopback adapter is a software interface that is not associated with an
actual network card. The nPath routing configuration requires you to
configure loopback adapters on servers.
MAC (Media Access Control)
MAC is a protocol that defines the way workstations gain access to
transmission media, and is most widely used in reference to LANs. For
IEEE LANs, the MAC layer is the lower sublayer of the data link layer
protocol.
MAC address
A MAC address is used to represent hardware devices on an Ethernet
network.
management interface
The management interface is a special port on the BIG-IP system, used for
managing administrative traffic. Named MGMT, the management interface
does not forward user application traffic, such as traffic slated for load
balancing. See also TMM switch interface.
management route
A management route is a route that forwards traffic through the special
management (MGMT) interface.
MCPD service
The Master Control Program Daemon (MCPD) service manages the
configuration data on a BIG-IP system.
MindTerm SSH
MindTerm SSH is the third-party application on 3-DNS Controllers that
uses SSH for secure remote communications. SSH encrypts all network
traffic (including passwords) to effectively eliminate eavesdropping,
connection hijacking, and other network-level attacks. SSH also provides
secure tunneling capabilities and a variety of authentication methods.
minimum active members
The minimum active members is the number of members that must be active
in a priority group in order for the BIG-IP system to send its requests to that
group. If the number of active members falls below this number, requests
are sent to the next highest priority group (the priority group with the next
lowest priority number).
Glossary - 12
Glossary
monitor
The BIG-IP system uses monitors to determine whether nodes are up or
down. There are several different types of monitors and they use various
methods to determine the status of a server or service. See also node, pool,
pool member.
monitor association
A monitor association is an association that a user makes between a health
or performance monitor and a pool, pool member, or node.
monitor instance
You create a monitor instance when a health monitor is associated with a
pool member or node. It is the monitor instance that actually performs the
health check, not the monitor.
monitor template
A monitor template is an internal mechanism that the BIG-IP system uses to
provide default values for a custom monitor when no pre-configured
monitor exists.
MSRDP persistence
MSRDP persistence tracks sessions between clients and servers running the
Microsoft® Remote Desktop Protocol (RDP) service.
MSTP (Multiple Spanning Tree Protocol)
Defined by IEEE, MSTP is an enhanced spanning tree protocol. Unlike STP
and RSTP, MSTP is VLAN-aware and therefore incorporates the concept of
MSTP regions. See also STP (Spanning Tree Protocol), RSTP (Rapid
Spanning Tree Protocol).
MSTP region
An MSTP region is a group of Layer 2 devices that have identical values for
certain configuration settings. When devices constitute a region, the
spanning tree algorithm takes VLANs into account when blocking and
unblocking redundant paths.
name resolution
Name resolution is the process by which a name server matches a domain
name request to an IP address, and sends the information to the client
requesting the resolution.
NAT (Network Address Translation)
A NAT is an alias IP address that identifies a specific node managed by the
BIG-IP system to the external network.
BIG-IP® TMOS®: Concepts
Glossary - 13
Glossary
network failover
Network failover is the process whereby a device of a redundant system
configuration uses the network to initiate failover. See also hard-wired
failover.
network virtual server
A network virtual server is a virtual server whose IP address has no bits set
in the host portion of the IP address (that is, the host portion of its IP address
is 0). There are two kinds of network virtual servers: those that direct client
traffic based on a range of destination IP addresses, and those that direct
client traffic based on specific destination IP addresses that the BIG-IP
system does not recognize.
node
A node is a logical object on the BIG-IP system that identifies the IP address
of a physical resource on the network. Nodes are directly associated with
pool members and monitors. See also pool member and monitor.
node address
A node address is the IP address associated with one or more nodes. This IP
address can be the real IP address of a network server, or it can be an alias IP
address on a network server. See also pool member, monitor.
node alias
A node alias is a node address that the BIG-IP system uses to verify the
status of multiple nodes. When the BIG-IP system uses a node alias to check
node status, it pings the node alias. If the BIG-IP system receives a response
to the ping, it marks all nodes associated with the node alias as up. If the
BIG-IP system does not receive a response to the ping, it marks all nodes
associated with the node alias as down.
node port
A node port is the port number or service name that is hosted by a specific
node.
node status
Node status indicates whether a node is up and available to receive
connections, or down and unavailable. The BIG-IP system uses the node
ping and health check features to determine node status.
Observed method
The Observed load balancing method bases connection distribution on a
combination of two factors: the server that currently hosts the fewest
connections and also has the fastest response time.
Glossary - 14
Glossary
OCSP (Online Certificate Status Protocol)
OCSP is a protocol that authenticating systems can use to check on the
revocation status of digitally-signed SSL certificates. The use of OCSP is an
alternative to the use of a certificate revocation list (CRL). See also CRL
(certificate revocation list).
OCSP authentication module
An OCSP authentication module is a user-configured module that you
implement on an BIG-IP system to authenticate client traffic using a remote
OCSP responder. The purpose of an OCSP authentication module is to
check on the revocation status of a client SSL certificate.
OCSP responder
An OCSP responder is an external server used for communicating SSL
certificate revocation status to an authentication server such as the BIG-IP
system.
OCSP responder object
A responder object is a software application on the BIG-IP system that
communicates with an OCSP responder, for the purpose of checking
revocation status of a client or server SSL certificate.
OneConnectTM
The F5 Networks® OneConnectTM feature optimizes the use of network
connections by keeping server-side connections open and pooling them for
re-use.
Open Shortest Path First (OSPF)
See OSPF (Open Shortest Path First).
optimization profile
An optimization profile is a custom profile that the BIG-IP system creates
for you automatically during installation. Optimization profiles have default
settings that are ideal for satisfying specific TCP and HTTP
traffic-management requirements such as caching and data compression.
OSPF (Open Shortest Path First)
OSPF is a dynamic routing protocol for internal networks, based on a
link-state algorithm. OSPF is generally considered to be more suitable than
RIP for large-scale, complex internal networks. See also advanced routing
module.
packet rate
The packet rate is the number of data packets per second processed by a
server.
BIG-IP® TMOS®: Concepts
Glossary - 15
Glossary
PAM (Pluggable Authentication Module)
PAM is a software module that a server application uses to authenticate
client traffic. The modular design of PAM allows an organization to add,
replace, or remove that authentication mechanism from a server application
with minimal impact to that application. An example of PAM is an
application that uses a remote Lightweight Directory Access Protocol
(LDAP) server to authenticate client traffic. See also LDAP (Lightweight
Directory Access Protocol).
parent profile
A parent profile is a profile that can propagate its values to another profile.
A parent profile can be either a default profile or a custom profile. See also
profile.
partition
A partition is a logical container that you create, containing a defined set of
BIG-IP system objects. You use partitions to control user access to the
BIG-IP system. See also user role.
partition default route domain
See default route domain.
performance monitor
A performance monitor gathers statistics and checks the state of a target
device.
persistence
See connection persistence or session persistence.
persistence profile
A persistence profile is a configuration tool for implementing a specific type
of session persistence. An example of a persistence profile type is a cookie
persistence profile.
pipelining
Pipelining is a feature of HTTP/1.1 that allows clients to make requests even
when prior requests have not yet received a response from the server.
pool
A pool is composed of a group of network devices (called members). The
BIG-IP system load balances requests to the nodes within a pool based on
the load balancing method and persistence method you choose when you
create the pool or edit its properties.
Glossary - 16
Glossary
pool member
A pool member is a logical object that represents a node IP address and a
service. A pool member is a member of a load balancing pool. See also
node, pool.
port
A port can be represented by a number that is associated with a specific
service supported by a host. Refer to the Services and Port Index for a list of
port numbers and corresponding services.
port lockdown
Port lockdown 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.
port mirroring
Port mirroring is a feature that allows you to copy traffic from any port or
set of ports to a single, separate port where a sniffing device is attached.
port-specific wildcard virtual server
A port-specific wildcard virtual server is a wildcard virtual server that uses a
port number other than 0. See wildcard virtual server.
pre-configured monitor
A pre-configured monitor is a system-supplied health or performance
monitor. You can use a pre-configured monitor as is, but you cannot modify
or delete one. See also monitor.
Predictive method
The Predictive method is a load balancing method similar to the Observed
method. However, with the Predictive method, the BIG-IP system analyzes
the trend of the ranking over time, determining whether a node’s
performance is currently improving or declining. The nodes with better
performance rankings that are currently improving, rather than declining,
receive a higher proportion of the connections.
profile
A profile is a configuration tool containing settings for defining the behavior
of network traffic. The BIG-IP system contains profiles for managing
Fast L4, HTTP, FTP, UDP, and SSL traffic, as well as for implementing
session persistence, server-side connection pooling, and remote application
authentication.
profile setting
A profile setting is a configuration attribute within a profile that has a value
associated with it. You can configure a profile setting to customize the way
that the BIG-IP system manages a type of traffic.
BIG-IP® TMOS®: Concepts
Glossary - 17
Glossary
profile type
A profile type is a category of profile that you use for a specific purpose. An
example of a profile type is an HTTP profile, which you configure to
manage HTTP network traffic.
protocol profile
A protocol profile is a profile that you create for controlling the behavior of
FastL4, TCP, UDP, OneConnect, and RTSP traffic.
Quality of Service (QoS) level
The Quality of Service (QoS) level is a means by which network equipment
can identify and treat traffic differently based on an identifier. Essentially,
the QoS level specified in a packet enforces a throughput policy for that
packet.
RADIUS (Remote Authentication Dial-in User Service)
RADIUS is a service that performs remote user authentication and
accounting. Its primary use is for Internet Service Providers, though it can
also be used on any network that needs a centralized authentication and/or
accounting service for its workstations.
RADIUS authentication module
A RADIUS authentication module is a user-configured module that you
implement on a BIG-IP system to authenticate client traffic using a remote
RADIUS server.
RAM cache
A RAM cache is a cache of HTTP objects stored in the BIG-IP system’s
RAM that subsequent connections reuse to reduce the amount of load on the
back-end servers.
rate class
You create a rate filter from the Configuration utility or command line
utility. When you assign a rate class to a rate filter, a rate class determines
the volume of traffic allowed through a rate filter. See also rate shaping.
rate shaping
Rate shaping is a type of extended IP filter. Rate shaping uses the same IP
filter method but applies a rate class, which determines the volume of
network traffic allowed. See also rate class.
ratio
A ratio is a parameter that assigns a weight to a virtual server for load
balancing purposes.
Glossary - 18
Glossary
Ratio method
The Ratio load balancing method distributes connections across an array of
virtual servers in proportion to the ratio weights assigned to each individual
virtual server.
receive string
A receive string is the text string that the BIG-IP system looks for in the web
page returned by a web server during an extended content verification
(ECV) health check.
redundant system
Redundant system refers to a group of devices that are configured for
failover. If an active device fails, another device processes connection
requests.
reference link
A reference link is the lowest-numbered interface in a trunk and is used for
link aggregation.
remote administrative IP address
A remote administrative IP address is an IP address from which a BIG-IP
system allows shell connections, such as Telnet or SSH.
responder object
See OCSP responder object.
RFC 1918 addresses
An RFC 1918 address is an address that is within the range of private class
IP addresses described in the IETF RFC 1918.
RIP (Routing Information Protocol)
RIP is a dynamic routing protocol for internal networks, based on a
distance-vector algorithm (number of hops). See also advanced routing
module.
Round Robin mode
Round Robin mode is a static load balancing mode that bases connection
distribution on a set server order. Round Robin mode sends a connection
request to the next available server in the order.
route domain
A route domain is a BIG-IP system object that provides the capability to
segment network traffic and define separate routing paths for different
network objects and applications. Because route domains segment the
network traffic, they also provide the capability to have separate IP
networks on the same device, where each route domain uses the same IPv4
BIG-IP® TMOS®: Concepts
Glossary - 19
Glossary
address space. See also default route domain and route domain 0.
route domain 0
Route domain 0 is a special route domain that the BIG-IP system creates
during installation. Route domain 0 resides in partition Common and
functions as the default route domain when no other route domains exist on
the system. See also default route domain and route domain.
router
A router is a Layer 3 networking device. If no VLANs are defined on the
network, a router defines a broadcast domain.
Routing Information Protocol (RIP)
See RIP (Routing Information Protocol).
RSTP (Rapid Spanning Tree Protocol)
Defined by IEEE, RSTP is an enhanced version of STP (Spanning Tree
Protocol). RSTP provides faster spanning tree performance compared to
STP. See also STP (Spanning Tree Protocol), MSTP (Multiple Spanning
Tree Protocol).
Secure Network Address Translation (SNAT)
See SNAT (Secure Network Address Translation). See also intelligent SNAT.
self IP address
Self IP addresses are the IP addresses owned by the BIG-IP system that you
use to access devices in VLANs. You assign self IP addresses to VLANs.
send string
A send string is the request that the BIG-IP system sends to the web server
during an extended content verification (ECV) health check.
server-side SSL profile
A server-side SSL profile is an SSL profile that controls SSL traffic going
between an BIG-IP system and a destination server system.
service
Service refers to services such as TCP, UDP, HTTP, and FTP.
services profile
A services profile is a configuration tool on the BIG-IP system for managing
either HTTP or FTP network traffic.
Glossary - 20
Glossary
session persistence
Session persistence is a series of related connections received from the same
client, having the same session ID. When persistence is enabled, an BIG-IP
system sends all connections having the same session ID to the same node,
instead of load balancing the connections. Session persistence is not to be
confused with connection persistence.
Setup utility
The Setup utility guides you through the initial system configuration
process. You can run the Setup utility from the Configuration utility start
page.
simple persistence
See source address affinity persistence.
single configuration file (SCF)
An SCF is a file that you create using the tmsh. The purpose of this file is to
store an entire BIG-IP system configuration that you can then easily
replicate on another BIG-IP system.
SIP persistence
SIP persistence is a type of persistence used for servers that receive Session
Initiation Protocol (SIP) messages sent through UDP. SIP is a protocol that
enables real-time messaging, voice, data, and video.
SNAT (Secure Network Address Translation)
A SNAT is a feature you can configure on the BIG-IP system. A SNAT
defines a routable alias IP address that one or more nodes can use as a
source IP address when making connections to hosts on the network. See
also standard SNAT and intelligent SNAT.
SNAT pool
A SNAT pool is a pool of translation addresses that you can map to one or
more original IP addresses. Translation addresses in a SNAT pool are not
self-IP addresses.
SNMP (Simple Network Management Protocol)
SNMP is the Internet standard protocol, defined in STD 15, RFC 1157,
developed to manage nodes on an IP network.
source address affinity persistence
Also known as simple persistence, source address affinity persistence
supports TCP and UDP protocols, and directs session requests to the same
server based solely on the source IP address of a packet.
BIG-IP® TMOS®: Concepts
Glossary - 21
Glossary
source processing
Source processing means that the interface rewrites the source of an
incoming packet.
spanning tree
A spanning tree is a logical tree structure of Layer 2 devices on a network,
created by a spanning tree protocol algorithm and used for resolving
network loops.
spanning tree instance
A spanning tree instance is a specific, named spanning tree that a spanning
tree protocol creates. See also spanning tree protocols.
spanning tree protocols
Spanning tree protocols are the IEEE-specified set of protocols known as
Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and
Multiple Spanning Tree Protocol (MSTP). The BIG-IP system includes
support for all of these protocols. See also STP (Spanning Tree Protocol),
RSTP (Rapid Spanning Tree Protocol), and MSTP (Multiple Spanning Tree
Protocol).
SSH
SSH is a protocol for secure remote login and other secure network services
over a non-secure network.
SSL (Secure Sockets Layer)
SSL is a network communications protocol that uses public-key technology
as a way to transmit data in a secure manner.
SSL persistence
SSL persistence is a type of persistence that tracks non-terminated SSL
sessions, using the SSL session ID.
SSL profile
An SSL profile is a configuration tool that you use to terminate and initiate
SSL connections from clients and servers.
standard SNAT
A standard SNAT is a SNAT that you implement by using the SNAT
screens of the Configuration utility. See also SNAT (Secure Network
Address Translation), intelligent SNAT.
standby device
A standby device in a redundant system configuration is a BIG-IP device on
which all traffic groups are in a standby state.
Glossary - 22
Glossary
state mirroring
State mirroring is a feature on the BIG-IP system that preserves connection
and persistence information in a redundant system.
static route
A static route is a route that you must explicitly configure on a Layer 3
device in its routing table. See also dynamic route.
static self IP address
A static self IP address is a self IP address that is not shared between two
units of a redundant system.
sticky persistence
See destination address affinity persistence.
STP (Spanning Tree Protocol)
Defined by IEEE, STP is a protocol that provides loop resolution in
configurations where one or more external switches are connected in
parallel with the BIG-IP system. See also RSTP (Rapid Spanning Tree
Protocol) and MSTP (Multiple Spanning Tree Protocol).
subdomain
A subdomain is a sub-section of a higher level domain. For example, .com is
a high level domain, and F5.com is a subdomain within the .com domain.
TACACS (Terminal Access Controller Access Control System)
TACACS is an older authentication protocol common to UNIX systems.
TACACS allows a remote access server to forward a user’s logon password
to an authentication server.
TACACS+
TACACS+ is an authentication mechanism designed as a replacement for
the older TACACS protocol. There is little similarity between the two
protocols, however, and they are therefore not compatible.
TACACS+ authentication module
A TACACS+ authentication module is a user-configured module that you
implement on an BIG-IP system to authenticate client traffic using a remote
TACACS+ server.
tagged interface
A tagged interface is an interface that you assign to a VLAN in a way that
causes the system to add a VLAN tag into the header of any frame passing
through that interface. Tagged interfaces are used when you want to assign a
single interface to multiple VLANs. See also VLAN (virtual local area
network).
BIG-IP® TMOS®: Concepts
Glossary - 23
Glossary
Tcl
Tcl (Tools Command Language) is an industry-standard scripting language.
On the BIG-IP system, users use Tcl to write iRules®.
threshold
A threshold is a value that specifies the number of object members in an HA
group that must be available to prevent failover. See also HA group.
TMM (Traffic Management Microkernel) service
The TMM service is the process running on the BIG-IP system that
performs most traffic management for the product.
TMM switch interface
A TMM switch interface is an interface that the BIG-IP system uses to
forward user application traffic such as HTTP or SSL traffic. Thus, when
load balancing application traffic, the BIG-IP system uses TMM switch
interfaces. See also management interface.
TMM switch route
A Traffic Management Microkernel (TMM) switch route is a route that
forwards traffic through the TMM switch interfaces and not the
management interface.
TMOS® (Traffic Management Operating System®)
The Traffic Management Operating System is the internal mechanism
within the BIG-IP system that is responsible for all traffic-management
functions.
traffic group
A traffic group is a collection of related configuration objects that run on a
BIG-IP device. When a BIG-IP device becomes unavailable, a traffic group
can float to another device in a device group to ensure that the traffic for that
application continues to be processed.
transparent node
A transparent node appears as a router to other network devices, including
the BIG-IP system.
trunk
A trunk is a logical group of BIG-IP system interfaces. When you create a
trunk, the BIG-IP system can aggregate the corresponding links as a way to
increase bandwidth.
Glossary - 24
Glossary
trusted CA file
A trusted CA file is a file containing a list of certificate authorities that an
authenticating system can trust when processing client requests for
authentication. A trusted CA file resides on the authenticating system and is
used for authenticating SSL network traffic.
trusted device certificate
The BIG-IP system uses a trusted device certificate or a certificate chain to
authenticate another system.
Type of Service (ToS) level
The Type of Service (ToS) level is another means, in addition to the Quality
of Service (QoS) level, by which network equipment can identify and treat
traffic differently based on an identifier.
Universal Inspection Engine (UIE)
The Universal Inspection Engine (UIE) is a feature that offers universal
persistence and universal content switching, to enhance your load balancing
capabilities. The UIE contains a set of rule variables and functions for
building expressions that you can specify in pool definitions and rules.
universal persistence
Universal persistence gives you the ability to persist on any string found
within a packet. Also, you can directly select the pool member to which you
want to persist.
user configuration set (UCS)
A user configuration set is a backup file that you create for the BIG-IP
system configuration data. When you create a UCS, the BIG-IP system
assigns a .ucs extension to the file name. See also archive.
user role
A user role is a type and level of access that you assign to a BIG-IP system
user account. By assigning user roles, you can control the extent to which
BIG-IP system administrators can view or modify the BIG-IP system
configuration. See also partition.
virtual address
A virtual address is an IP address associated with one or more virtual servers
managed by the BIG-IP system.
virtual port
A virtual port is the port number or service name associated with one or
more virtual servers managed by the BIG-IP system. A virtual port number
should be the same port number to which client programs expect to connect.
BIG-IP® TMOS®: Concepts
Glossary - 25
Glossary
virtual server
A virtual server is a traffic-management object on the BIG-IP system that is
represented by an IP address and a service. Clients on a network can send
application traffic to a virtual server, which then directs the traffic according
to your configuration instructions. The primary use of a virtual server is to
balance traffic load across a pool of servers on an internal network.
VLAN (virtual local area network)
A VLAN is a logical grouping of interfaces connected to network devices.
You can use a VLAN to logically group devices that are on different
network segments. Devices within a VLAN use Layer 2 networking to
communicate and define a broadcast domain.
VLAN group
A VLAN group is a logical container that includes two or more distinct
VLANs. VLAN groups are intended for load balancing traffic in a Layer 2
network, when you want to minimize the reconfiguration of hosts on that
network. See also VLAN (virtual local area network).
VLAN name
A VLAN name is the symbolic name used to identify a VLAN. For
example, you might configure a VLAN named marketing, or a VLAN
named development. See also VLAN (virtual local area network).
VLAN tag
An IEEE standard, a VLAN tag is an identification number inserted into the
header of a frame that indicates the VLAN to which the destination device
belongs. VLAN tags are used when a single interface forwards traffic for
multiple VLANs.
WAP (Wireless Application Protocol)
WAP is an application environment and set of communication protocols for
wireless devices designed to enable manufacturer-, vendor-, and
technology-independent access to the Internet and advanced telephony
services.
watchdog timer card
A watchdog timer card is a hardware device that monitors the BIG-IP
system for hardware failure.
Weighted Least Connections method
Weight Least Connections method is a load balancing method that bases
connection distribution on which server currently manages the fewest
number of active connections, while also factoring in server capacity. A
server with more active connections can therefore receive the next
connection if that server has greater capacity than a server with fewer
connections but smaller capacity. See also Least Connections method.
Glossary - 26
Glossary
wildcard virtual server
A wildcard virtual server is a virtual server that uses an IP address of
0.0.0.0, * or "any". A wildcard virtual server accepts connection requests
for destinations outside of the local network. Wildcard virtual servers are
included only in Transparent Node Mode configurations.
WKS (well-known services)
Well-known services are protocols on ports 0 through 1023 that are widely
used for certain types of data. Some examples of some well-known services
(and their corresponding ports) are: HTTP (port 80), HTTPS (port 443), and
FTP (port 20).
BIG-IP® TMOS®: Concepts
Glossary - 27
Glossary
Glossary - 28
Index
Index
.ucs files
defined 9-1
downloading and uploading 9-3
/etc/init.d/syslog-ng script 14-13
/var/local/ucs directory 9-2
/var/log/ltm directory 14-6
/var/log/messages directory 14-6
/var/log/pktfilter directory 14-6
A
access control
on multiple devices 13-18
through user accounts 13-14
to SNMP data 11-2
access levels
managing 11-3, 13-7
account names 13-12
accounts
creating and storing 13-14
managing 13-7
actions
at failover 8-2
for traps A-1
active bonus
defined 8-6, 0-1
example of 8-6
active connection statistics 11-7, 11-8
active devices
and HA scores 8-5
Active Directory authentication servers 13-15
active/standby status
and HA scores 8-5
address space 16-1, 22-9
admin account
and partitions 12-5
and user roles 13-5, 13-6
configuring and managing 13-8
described 13-2
administrative partitions
and folders 12-8
See partitions.
Administrator user role
and non-partitioned objects 12-7
and partition Common 12-2
and passwords 13-8, 13-13
and system services 10-1
described 13-5, 13-8
for account modification 13-12
for system and other accounts 13-6
for user accounts 13-6, 13-12, 13-15
managing archives with 9-2
viewing accounts with 13-12, 13-19
alarm RMON group 11-6
Alert log level 14-8
BIG-IP® TMOS®: Concepts
alert system A-1
Alternate port role 20-15
Application Editor user role 13-5
application-specific MIB files 11-1
See also enterprise MIB files.
archive storage location 9-2
archives
purpose of 9-1
saving and restoring 9-2, 9-3
uploading and downloading 9-3
ARP forwarding 22-11
ARP logging events 14-7
assignments
See object referencing.
audit events
defined 14-1
audit logging
and /var/log/ltm directory 14-7
enabling and disabling 14-10
audit logs
user access to 14-8
viewing and searching 14-10
auditing events
and log levels 14-10
authentication 13-1
authentication server types 13-1
authentication-related traps A-4
authorization
defined 13-1
remote 13-15
authorization properties 13-16
authorized_keys file 14-15
auto link type 20-13
automatic link selection 21-6
B
Backup port role 20-15
bandwidth
borrowing 19-5, 19-6, 19-7
increasing 15-10, 21-1
maximum 21-6
replenishing 19-4
saving 19-4
base packet rates 19-3, 19-6
Base Rate setting, configuring 19-3
base throughput rate 19-3
bigdb logging events 14-7
BIG-IP alert system 11-2
BIG-IP system information 11-2
BIND forwarder server list 4-3
Blocking port state 20-15
BPDUs
and interfaces 20-13
defined 20-1
Index - 1
Index
maximum transmittal of 20-7
receiving 20-14
bridge priorities 20-11
bridge protocol data units
See BPDUs.
bridging loops
preventing 20-1
burst reservoirs 19-4
Burst Size setting, configuring 19-3
bursting restrictions 19-4
C
calculations 11-7
for HA scoring 8-5
Ceiling Rate setting, configuring 19-3
ceiling rates 19-4, 19-7
certificate chains 5-2
Certificate Manager user role 13-5
character restrictions
for passwords 13-10
child rate classes 19-6
client access
allowing 11-2
configuring 11-2
client traffic
and rate classes 19-6
Common partition
and default monitor 12-7
and partition access 12-5
contents of 12-2
communities
and access levels 11-3
company-specific MIB files 11-1
configuration
loading from SCF 3-2
saving to an SCF 3-2
configuration data
backing up 9-2
defined 9-1
loading 2-2
propagating to multiple devices 3-1
saving 2-1
configuration data loads
logging of 14-10
configuration settings, global 20-5
configuration states 2-1
configuration task summary 11-2
Configuration utility
about online help 1-4
and configuration storage 2-1
and Welcome screen 1-4
connection queueing 19-7
connection statistics 11-7, 11-9
console access 13-12
control packets 21-4, 21-5
Index - 2
CPU use statistics 11-7, 11-15
criteria
for packet filtering 18-5
Critical log level 14-8
current partition
defined 12-2
selecting 12-2
D
daemons
See services.
data
backing up 9-2
data access control, SNMP 11-2
data backup 9-1
data group files 6-1
data groups 4-6
data loads
logging 14-10
data object values, SNMP 11-1
data objects
in MIB files 11-4
modifying 11-3
See also access levels.
data restore 9-1
data validity 20-6
data, MIB files 11-6
Debug log level 14-9
default access levels
modifying 11-3
default configuration 3-3
restoring 3-2
default monitor 12-7
default partition access 13-19
default routes
and ARP requests 8-3
for management ports 7-1
default user authorization
deleting 13-19
default user roles
and Administrator role 13-6
for local accounts 13-12
for remote accounts 13-16
defined 8-5
Designated port role 20-15
destination IP addresses
and packet filtering 18-7
and persistence 4-6
device group inheritance 7-3
device groups
and root folder 12-8
and traffic groups 17-1
device scores
calculating 8-5
Direction setting, configuring 19-6
Index
Disabled mode, for spanning tree 20-5
Disabled port role 20-15
DNS (Domain Name System) 4-3
DNS lookup server list 4-3
DNS proxy services 4-3
duplex modes 21-3
duration
of passwords 13-10
dynamic l2 forwarding entries 22-8
E
edge ports 20-13, 20-14
email, sending 14-2
Emergency log level 14-8
encrypted remote logging
prerequisites and tasks 14-11
encrypted tunnels, opening and closing 14-13
enterprise MIB files
and Configuration utility 11-1
content of 11-5
defined 11-1
downloading 11-2, 11-5
Error log level 14-8
error messages
and object creation 12-7
event notifications, SNMP 11-2
event RMON group 11-6
events, redundant systems 8-1
expiration
of passwords 13-10
external file management 6-1
external monitor files 6-1
external path cost 20-17
F
F5-BIGIP-COMMON-MIB.txt file 11-5, A-1
F5-BIGIP-GLOBAL-MIB.txt file 11-5
F5-BIGIP-LOCAL-MIB.txt file 11-5
F5-BIGIP-SYSTEM-MIB.txt file 11-5, 11-6
factory settings
restoring 3-2
failover
initiating 8-1, 8-3
preventing 8-5
triggering 8-1
failover actions 8-2
fail-safe 8-1, 22-7
fail-safe timeout period 8-3
failure detections
for switch board components 8-2
for VLANs 8-3
Fast L4 logging events 14-7
Fastest load balancing mode 4-5
file management 6-1
BIG-IP® TMOS®: Concepts
filter expressions
defined 18-7
flapping
and HA scores 8-6, 0-1
defined 8-6
flat file
for configuration data 3-1
floating self IP addresses
and traffic groups 16-4
defined 16-2
floods 20-1
flow control 15-4
folder inheritance 7-3
folders
about 12-8
formatting conventions 1-3
Forward Delay option 20-6
Forwarding port state 20-15
frame control 15-4
frame order 21-1
G
general traps A-1
global statistics data 11-6
graphs, SNMP 11-7
group-based accounts
and privileges 13-14
Guest user role 13-5, 13-6, 13-13
H
HA group
defined 8-4
HA group weights
specifying 8-5
HA scores
adding to 8-6, 0-1
calculating 8-4, 8-5
HA threshold 8-5
hardware components 8-1
hardware-related traps A-2
heartbeat failures 8-2
Hello Time option 20-6
help, online 1-4
history RMON group 11-6
host IP addresses 7-1
host names
as general property 7-1
in logs 14-2
hosts
and VLANs 22-5
HTTP logging events 14-7
HTTP request logging profile 14-2
HTTP request statistics 11-7, 11-12
Index - 3
Index
I
IDs
for Spanning Tree instances 20-11
for transactions 14-2
for VLANs 22-6
IEEE specifications 20-1
information collection 11-2
Information log level 14-9
information polling 11-2
information validity 20-6
information, SNMP 11-2
inheritance 7-3
and partitions 12-7
instance IDs 20-11
instance members
defined 20-8
deleting 20-12
instances
and protocol types 20-2
creating and modifying 20-8
defined 20-8
viewing interfaces for 20-14
viewing, modifying, and deleting 20-12
interface access methods 22-5
interface cards 8-3
interface costs 20-16
interface mirroring 15-7
interface naming conventions 15-3
interface priorities 20-16
interface state 15-4
interface statistics 15-10
interfaces
and frames 15-4
and instance settings 20-16
and multiple VLANs 22-5
and VLAN traffic 15-10
as edge ports 20-13
assigning 22-5
blocking 20-6
choosing for traffic 20-16
configuring for spanning tree 20-12
defined 15-1
enabling and disabling 20-13
enabling STP on 20-8
for trunks 21-1, 21-3
monitoring 11-6
viewing per instance 20-14
internal path cost 20-17
interruptions
detecting 8-1
IP addresses
as filtering criterion 18-4
IP logging events 14-7
IPv4 addressing format 7-1
iRule logging events 14-7
Index - 4
iRules
and partitions 12-7
L
L2 forwarding
See Layer 2 forwarding.
L2 forwarding entries 22-8
LACP control packets 21-2, 21-4
LACP protocol 21-2
LACP timeout values 21-5
last hops 4-4
Layer 1 logging events 14-7
Layer 2 forwarding 22-8
Layer 2 forwarding tables 4-5
Layer 2 logging events 14-7
Layer 2 protocols 20-1
Layer 4 logging events 14-7
LDAP authentication servers 13-1, 13-15
LDAP database 13-8
learning port state 20-16
legacy bridges
and BPDUs 20-14
and MSTP 20-2
and STP 20-2
length
of passwords 13-10
license-related traps A-3
link aggregation
and path costs 20-17
defined 15-10, 21-1
Link Aggregation Control Protocol
See LACP protocol.
link aggregation policy 21-5
link selection policy 21-5
link types, for STP 20-13
Linux-related events
logging 14-6
load sys config default command 3-2
load sys config file command 3-2
local application traffic 11-5
local traffic events
defined 14-1
logging 14-6
local traffic management information 11-5
local traffic types
and log levels 14-9
local user accounts
and password policy 13-9
managing 13-1, 13-7
log contents 14-2
log information, sending 14-11
log levels
defined 14-8
setting 14-8
Index
log messages
viewing and filtering 14-3
logging
of monitor events 14-7
logging event types 14-7
logging feature
summarized 14-1
logging-related traps A-6
logs
viewing and searching 14-10
long timeout value 21-5
loops 20-1
M
MAC addresses
as filtering criterion 18-3
assigning 16-2
for trunks 21-2
for VLANs 22-5
MAC masquerade addresses 17-1
maintenance mode 4-4
management information base (MIB)
See also MIB.
See MIB-II MIB.
management interface
defined 15-1
management port route 7-1
Manager user role 13-5
Maximum Age option 20-6
MCP logging events 14-7
media properties
monitoring 21-5
media speed 21-3
member availability
and score calculation 8-4
members, MSTP 20-12
memory use 4-5
memory use statistics 11-7, 11-8, 11-13
messages
and VLANs 22-5
logging to remote machine 14-14
viewing and filtering 14-3
metrics collection 11-7
MGMT interface
defined 15-1
MIB
and device management 11-1
defined 11-1
See also MIB-II MIB.
MIB file contents 11-5
MIB file locations 11-1
MIB file types 11-4
BIG-IP® TMOS®: Concepts
MIB files
defined 11-4
described 11-1
downloading 11-2
MIB files location 11-4
MIB-II MIB 11-1
minimum log levels
defined 14-8
setting 14-8
mirroring
See also interface mirroring. 15-7
modes, duplex 21-3
monitor events
logging 14-7
MSTP
and VLANs 20-2, 20-9
defined 20-2
MSTP Configuration Name setting 20-7
MSTP Configuration Revision setting 20-7
MSTP Maximum Hop Number setting 20-7
MSTP mode, for spanning tree 20-5
MSTP regions 20-2, 20-7
MTUs 4-4
Multiple Spanning Tree Protocol
See MSTP.
N
name resolution 4-3
named service 4-3
naming conventions, interfaces 15-3
netmasks 16-3
Net-SNMP package 11-1
network failure 20-1
network information 11-6
network monitoring 8-1
Network Time Protocol (NTP) 4-3
network traffic
and packet filters 18-1
monitoring 8-3
network-related traps A-5
new connection statistics 11-7, 11-9
No Access user role 12-2, 13-5, 13-6
nodes
and default monitor 12-7
non-floating self IP addresses
and traffic groups 16-4
Notice log level 14-9
notification messages 11-2
See also traps.
notification types A-1
notifications, SNMP 11-5
NOTIFICATION-TYPE designation 11-5
NTP protocol 4-3
ntpd service 10-1
Index - 5
Index
O
object creation
and error messages 12-7
object data, SNMP 11-2
object ID definitions, RMON 11-6
object membership 12-7
object presentation 11-1
object referencing
and iRules 12-7
and partitions 12-3, 12-7
object values, SNMP 11-1
objects
and user roles 12-7
moving 12-7
OIDs 11-7, 11-8
online help 1-4
opaque mode 22-10
Operator user role 13-5, 13-6, 13-13
order, of packets 19-1
P
p2p link type 20-13
packet filter events
defined 14-1
logging 14-6
packet filter rules
creating 18-4
logging of 18-7
ordering 18-5
packet filters
controlling packet access 18-1
packet floods 20-1
packet forwarding 4-5, 18-1
packet order 19-1, 19-7
packet rate limit, specifying 19-3
packet rate, exceeding 19-3
packet rejection 18-1, 18-4
packet scheduling methods 19-2
packet throughput, enforcing 19-1
packets
and access to VLANs 22-5
packets, queuing and dequeuing 19-1, 19-7
pager notifications, activating 14-2
Parent Class setting, configuring 19-6
parent rate classes 19-5
parent-child propagation 12-7
partition access
and current partition 12-2
defined 12-5
partition objects
moving 12-2
partitions
and folders 12-8
and iRules 12-7
and object referencing 12-3
Index - 6
and rate classes 19-2
and user accounts 12-5
defined 12-1
example of 12-5
Pass Through mode, for spanning tree 20-5
password duration 13-10
password expiration 13-8, 13-10
password length 13-10
password policy 13-8
password restrictions 13-8, 13-10
passwords
assigning 13-8, 13-12
changing 13-12
defined 13-1
previous 13-10
path costs 20-16
paths
blocking and clearing 20-1
Pause frames 15-4
performance improvements
for RSTP protocol 20-2
performance metrics, SNMP 11-2, 11-7
permissions
and local accounts 13-7
and partition access 12-2
persistence table 4-6
PFIFO, defined 19-7
platform information 11-6
policy
for passwords 13-8
pool member thresholds 8-3
pool members
losing 8-4
pools
and HA group 8-4
port lockdown 16-4
port roles 20-15
port states 20-15
ports
and VLANs 22-5
postfix service 10-1
Priority FIFO
See PFIFO.
privileges
on multiple devices 13-18
propagating to other devices 13-18
properties, local traffic 4-4
protocol degradation legacy bridges 20-3
protocol versions 20-3
protocols
accepting traffic from 16-4
proxied ARP requests 22-11
proxy IP addresses 4-6
PVA logging events 14-7
Index
Q
Queue Discipline setting, configuring 19-7
R
RADIUS authentication servers 13-1, 13-15
rate class assignment 18-6
rate class example 19-5
rate class settings 19-2
rate classes
and direction 19-6
assigning 19-2
defined 19-1, 19-2
naming 19-2
rate shaping, defined 19-1
rate statistics 11-10, 11-19
rate, of packets 19-1
read access 12-2
reaper high-water mark 4-5
reaper low-water mark 4-5
redundant paths
blocking and clearing 20-1
redundant system configuration
about 7-3
redundant systems
See also fail-safe.
reference links 21-2
referencing
See object referencing.
regions 20-2
remote authentication server types 13-1
remote authentication servers 13-14
remote authorization 13-18
remote hosts, and logging 14-11
remote logging tasks 14-11
remote logging, encrypted 14-11
Remote Network Monitoring (RMON)
See RMON implementation.
remote server types 13-15
remote systems
using for backup and restore 9-2
remote user accounts
and group-wide privileges 13-18
and password policy 13-9
assigning privileges to 13-14
assigning user roles to 13-15
creating and storing 13-14
viewing 13-19
remote user authorization
changing 13-18
configuring 13-18
deleting 13-19
remote user roles
assigning 13-15
changing 13-18
remoterole command 13-18
BIG-IP® TMOS®: Concepts
reservoirs
See burst reservoirs.
Resource Administrator user role 13-5
restrictions
for passwords 13-8
RMON groups 11-6
RMON implementation 11-6
RMON-MIB.txt file 11-6
root account
and partitions 12-5
and user roles 13-6
modifying 13-12
root account requirements 13-2
root bridges 20-11
root folder
about 12-8
and redundancy 7-3
Root port role 20-15
routes
blocking 15-10
RSTP mode, for spanning tree 20-5
RTSP protocol
described 20-2
running configurations
defined 2-1
S
save sys config file command 3-2
saving an SCF 3-2
SCFs
benefits of 3-3
comparing 3-3
defined 3-1
for configuring other systems 3-3
for data propagation 9-1
for propagation of privileges 13-18
using to restore a system 3-3
scores
calculating for HA 8-5
search strings
for logging 14-3
secure password policy 13-8
security
and passwords 13-8
security restrictions 13-8
security, adding 13-1
self IP addresses
and traffic groups 16-4
assigning to VLANs 22-4, 22-12
defined 16-1
for SNATs 16-2
self-signed certificates 5-1
server availability 0-26
server traffic, and rate classes 19-6
Index - 7
Index
service names
in logs 14-2
services
monitoring 8-2
starting and stopping 10-1
user role for 10-1
Setup utility
and user accounts 13-1
severity log levels
defined 14-8
setting 14-8
SFQ queueing method
defined 19-7
shared link type 20-13
shared MAC addresses 4-5
short timeout value 21-5
single configuration files
See SCFs.
SNAT automapping 16-2
SNAT information 11-5
SNAT packet forwarding 4-5
SNAT pools 16-2
SNATs
defined 16-2
SNMP
and syslog 11-4
See also SNMP agent.
See also SNMP managers.
SNMP agent
and trap notifications A-1
configuring 11-2
defined 11-1
SNMP commands
for collecting statistics 11-7
using 11-2, 11-5
SNMP data access control 11-2
SNMP manager functions 11-2
SNMP managers
defined 11-1
SNMP MIB files
See MIB files.
SNMP object data 11-2
SNMP tasks 11-1, 11-2
SNMP traps
handling 11-2
See also traps.
SNMP users 11-3
snmpd service 10-1
snmpget command 11-7
source IP addresses
and packet filtering 18-7
spanning tree instances
defined 20-8
viewing, modifying, and deleting 20-12
Spanning Tree Protocol (STP)
See STP protocol.
Index - 8
spanning tree protocols
and trunks 21-3
changing 20-5
resetting 20-14
spanning tree regions
See MSTP regions.
spanning trees 20-2
SSH 7-3
SSH access 13-12
ssh command 14-12
SSH connection, establishing 14-12
SSH identity, copying 14-15
ssh syntax 14-12
SSH tunnel, and logging 14-11
sshd service
listed 10-1
SSL authentication 5-1
SSL certificate files 6-1
SSL certificates
and BIG-IP systems 5-1
and levels 5-2
SSL logging events 14-7
static l2 forwarding entries 22-8
static self IP addresses
and traffic groups 16-4
defined 16-2
statistical data 11-6
statistics 15-10
statistics RMON group 11-6
statistics, SNMP 11-6
status codes
in logs 14-2
Stochastic Fair Queueing
See SFQ queueing method.
stored configuration, defined 2-1
STP mode, for spanning tree 20-5
STP protocol 20-2
style conventions 1-3
support account
and partitions 12-5
requiring 13-2
switch board monitoring 8-2
SYN Check 4-5
syslog-ng script
editing 14-13
syslog-ng service
restarting 14-15
syslog-ng utility
configuring 14-11
system access control 13-2, 13-14
system account management 13-8
system data, SNMP 11-5
system events
defined 14-1
system fail-safe
and hardware components 8-1
Index
system information
configuring 11-2
polling for 11-5
system interface monitoring 11-6
system location 11-2
System maintenance account types 13-2
system maintenance accounts 13-1
system monitoring 8-1
system operation, SNMP A-1
system restoration 3-3
system services
monitoring 8-1, 8-2
restarting 8-3
See services.
system time 4-3
system-initiated changes
logging 14-10
T
tagged interfaces, defined 22-5
tags
embedding in packet headers 22-6
See VLAN tags.
task summary
for SNMP 11-2
TCP logging events 14-7
text file
for configuration data 3-1
threshold
for HA scores 8-5
thresholds 8-3
throughput
enforcing 19-1
throughput limitations 19-1, 19-2
throughput policies 19-1
throughput policy, enforcing 19-1
throughput rate statistics 11-7, 11-10, 11-19
throughput rates 19-3
throughput restrictions, applying 19-6
time interval, changing 20-6
time protocol 4-3
time zones 7-1
timeout periods, fail-safe 8-3
timer values 20-6
timestamps
in logs 14-2
TMM logging events 14-7
TMOS-related traps A-3
tmsh utility
and configuration storage 2-1
and SCFs 3-2
ToS field
and queueing 19-7
BIG-IP® TMOS®: Concepts
traffic
blocking 20-6
queueing 19-7
restricting through tagged interfaces 22-5
restricting through untagged interfaces 22-5
traffic direction, and rate classes 19-1
traffic distribution 21-1
traffic flow limits 19-3
traffic flow rates 19-3, 19-4, 19-6
traffic group inheritance 7-3
traffic groups
and self IP addresses 16-4
defined 17-1
traffic queueing 19-7
traffic rates, bursting 19-3
transaction IDs
in logs 14-2
translucent mode 22-10
Transmit Hold Count option 20-7
transparency mode 22-10
transparent mode 22-10
trap destinations
configuring 11-3
trap locations 11-5
trap names A-1
traps
and recommended actions A-1
configuring 11-3
defined 11-2
handling 11-2
identifying 11-5
See also notification types.
tree structure 11-1
trunk members
losing 8-4
trunk names 21-2
trunks
and configuration synchronization 8-4
and failover 8-4
and HA group 8-4
and spanning tree protocols 21-3
and VLANs 22-5
defined 15-10, 21-1
enabling and disabling 20-13
Type of Service field
See ToS field.
U
UCD-SNMP package 11-1
UCS
See user configuration sets.
UDP logging events 14-7
unit weights
for HA group 8-5
universal partition access 12-5
Index - 9
Index
untagged interfaces 21-3, 22-5
unused bandwidth
borrowing 19-6
replenishing 19-4
saving 19-3
user access 12-2
user account configuration tools 13-2
user account location 13-2
user account properties
viewing 13-19
user account types 13-1, 13-2
user accounts
and partition access 12-5
and passwords 13-8
and tools 13-2
as partitioned objects 12-5
assigning privileges to 13-14
changing 13-18
creating 13-2, 13-14
defined 13-2
managing 13-7
purpose of 13-1
See also local user accounts.
See also remote user accounts.
storing 13-14
user authorization
configuring 13-18
user changes
logging 14-10
user configuration sets
defined 9-1
See also .ucs files.
User Manager user role 13-5
user names
for user accounts 13-12
in logs 14-2
user privileges
on multiple devices 13-18
user role categories 13-4
user roles
and account creation 13-7
and audit log access 14-8
and non-partitioned objects 12-7
and passwords 13-8
and rate classes 19-2
and read access 12-2
and user accounts 13-2
as authorization 13-4
assigning 13-15
changing 13-12, 13-18
defined 13-1, 13-4
deleting 13-19
described 13-5
for remote accounts 13-14
Index - 10
users
See SNMP users.
See also user accounts.
V
virtual server information 11-5
virtual servers
and destination addresses 4-4
defined 0-26
VLAN access methods 22-5
VLAN fail-safe 8-3
VLAN failure 8-4, 8-5
VLAN group IDs
defined 22-10
VLAN groups
and self IP addresses 16-3
defined 22-2, 22-9
VLAN IDs 22-6
VLAN members
adding 20-8
removing 20-12
VLAN names 8-3
VLAN tags 20-11, 22-5
VLAN traffic 15-10
VLAN-keyed connections 4-4
VLANs
adding as instance members 20-11
and connections 4-4
and fail-safe 8-3
and failure detection 8-3
and interfaces 15-1
and MSTP 20-2
and self IP addresses 16-3
and STP 20-2
and trunks 21-3
as filtering criterion 18-4
benefits of 22-1
defined 22-1
example of 22-3
W
Warning log level 14-8
Web Application Security Administrator user role 13-6
weights
for an HA group 8-5
Welcome screen 1-4