BIG-IP® TMOS®: Implementations

Version 11.2
 Table of Contents

Table of Contents
Legal Notices...................................................................................................................................11
Acknowledgments..........................................................................................................................13

Chapter 1: Customizing the BIG-IP Dashboard................................................17

Overview: BIG-IP dashboard customization...........................................................................18
Customizing the BIG-IP dashboard........................................................................................18

Chapter 2:
Creating an Active-Standby Configuration Using the Setup Utility............19
Overview: Creating a basic active-standby configuration.......................................................20
Task summary........................................................................................................................20
Licensing and provisioning the BIG-IP system............................................................20
Configuring the management port and administrative user accounts.........................21
Enabling ConfigSync and high availability...................................................................21
Configuring the internal network..................................................................................22
Configuring the external network.................................................................................22
Configuring the network for high availability................................................................23
Configuring a ConfigSync address..............................................................................23
Configuring failover and mirroring addresses..............................................................23
Discovering a peer device...........................................................................................24
Implementation result.............................................................................................................24

Chapter 3:
Creating an Active-Active Configuration Using the Setup Utility...............27
Overview: Creating a basic active-active configuration..........................................................28
Task summary........................................................................................................................29
Licensing and provisioning the BIG-IP system............................................................30
Configuring the management port and administrative user accounts.........................30
Enabling ConfigSync and high availability...................................................................31
Configuring the internal network..................................................................................31
Configuring the external network.................................................................................31
Configuring the network for high availability................................................................32
Configuring a ConfigSync address..............................................................................32
Configuring failover and mirroring addresses..............................................................32
Establishing device trust..............................................................................................33
Creating a Sync-Failover device group........................................................................33
Creating an iApp application for the local device.........................................................34

3
Table of Contents

Creating a traffic group for a remote device................................................................34

Creating an iApp application for a remote device........................................................35
Forcing a traffic group to a standby state....................................................................35
Syncing the BIG-IP configuration to the device group.................................................36
Implementation Results..........................................................................................................36

Chapter 4: Upgrading Active-Standby Systems...............................................39

Overview: Upgrading BIG-IP active-standby systems............................................................40
About new BIG-IP system configuration components.................................................42
About traffic groups.....................................................................................................44
Task summary........................................................................................................................44
Preparing BIG-IP modules for an upgrade from version 10.x to version 11.x..............45
Preparing BIG-IP active-standby systems for an upgrade...........................................49
Upgrading the standby BIG-IP 2 system.....................................................................50
Upgrading the active BIG-IP 1 system.........................................................................50
Verifying a BIG-IP active-standby upgrade..................................................................52
Implementation result.............................................................................................................52

Chapter 5: Configuring a Sync-Failover Device Group....................................55

Overview: Configuring a Sync-Failover device group.............................................................56
Task summary........................................................................................................................56
Before you begin..........................................................................................................57
Specifying an IP address for config sync.....................................................................57
Specifying IP addresses for connection mirroring.......................................................58
Establishing device trust..............................................................................................58
Creating a Sync-Failover device group........................................................................59
Syncing the BIG-IP configuration to the device group.................................................59
Specifying IP addresses for failover.............................................................................60
Creating a second traffic group for the device group...................................................60
Assigning traffic-group-2 to a floating virtual IP address.............................................61
Assigning traffic-group-2 to a floating self IP address.................................................61
Syncing the BIG-IP configuration to the device group.................................................61
Forcing a traffic group to a standby state....................................................................62
Implementation result.............................................................................................................62

Chapter 6: Configuring DNS Express................................................................63

How do I configure DNS Express?.........................................................................................64
What is DNS Express?................................................................................................64
Task summary........................................................................................................................64
Configuring a back-end DNS server to allow zone file transfers.................................64
Creating a DNS Express TSIG key..............................................................................64
Creating a DNS Express zone.....................................................................................65

4
 Table of Contents

Enabling DNS Express ...............................................................................................66

Viewing information about DNS Express zones..........................................................67
Implementation result.............................................................................................................67

Chapter 7:
Load Balancing DNS Traffic Between IPv-6 Only and IPv-4 Only Clouds...69
Overview: Handling IPv6-only connection requests to IPv4-only servers..............................70
Task summary........................................................................................................................70
Creating a custom DNS profile ...................................................................................70
Assigning a DNS profile to a virtual server..................................................................72
Implementation result.............................................................................................................72

Chapter 8: Implementing the Link Layer Discovery Protocol..........................73

Overview: Implementing Link Layer Discovery Protocol.........................................................74
Task summary........................................................................................................................75
Configuring global LLDP properties............................................................................75
Configuring LLDP settings for an individual interface..................................................75
Implementation result.............................................................................................................76

Chapter 9:
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems..............77
Overview: Configuring IPsec between two BIG-IP systems...................................................78
About negotiation of security associations..................................................................78
About IPsec Tunnel mode............................................................................................78
About BIG-IP components of the IPsec protocol suite................................................79
Task summary........................................................................................................................79
Creating a forwarding virtual server for IPsec.............................................................80
Creating an IKE peer...................................................................................................80
Creating a custom IPsec policy...................................................................................81
Creating a bidirectional IPsec traffic selector..............................................................82
Verifying IPsec connectivity for Tunnel mode...............................................................83
Implementation result.............................................................................................................87

Chapter 10:
Configuring IPsec in Transport Mode between Two BIG-IP Systems.........89
Overview: Configuring IPsec in Transport mode between two BIG-IP systems.....................90
About negotiation of security associations..................................................................90
About IPsec Transport mode.......................................................................................90
About BIG-IP components of the IPsec protocol suite................................................91
Task summary........................................................................................................................91

5
Table of Contents

Creating a forwarding virtual server for IPsec.............................................................92

Creating an IKE peer...................................................................................................92
Creating a bidirectional IPsec policy............................................................................93
Creating a bidirectional IPsec traffic selector..............................................................93
Verifying IPsec connectivity for Transport mode..........................................................95
Implementation result.............................................................................................................99

Chapter 11:
Configuring IPsec between a BIG-IP System and a Third-Party Device....101
Overview: Configuring IPsec between a BIG-IP system and a third-party device................102
About negotiation of security associations................................................................102
About IPsec Tunnel mode..........................................................................................103
About BIG-IP components of the IPsec protocol suite..............................................103
Task summary......................................................................................................................103
Creating a forwarding virtual server for IPsec...........................................................104
Creating an IKE peer.................................................................................................104
Creating a custom IPsec policy.................................................................................106
Creating a bidirectional IPsec traffic selector............................................................107
Verifying IPsec connectivity for Tunnel mode.............................................................108
Implementation result...........................................................................................................112

Chapter 12:
Configuring IPsec Using Manually Keyed Security Associations............113
Overview: Configuring IPsec using manual security associations........................................114
About IPsec Tunnel mode..........................................................................................115
Task summary......................................................................................................................115
Creating a forwarding virtual server for IPsec...........................................................115
Creating a manual IPsec security association...........................................................116
Creating a custom IPsec policy.................................................................................116
Creating a bidirectional IPsec traffic selector............................................................117
Verifying IPsec connectivity for Tunnel mode.............................................................118

Chapter 13:
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN..........123
Overview: Setting up IPsec to use NAT traversal on both sides of the WAN........................124
Before you begin IPsec configuration...................................................................................124
Task summary......................................................................................................................124
Creating a forwarding virtual server for IPsec...........................................................125
Creating an IPsec tunnel with NAT-T on both sides...................................................125
Verifying IPsec connectivity for Tunnel mode.............................................................129

6
 Table of Contents

Chapter 14:
Setting Up IPsec To Use NAT Traversal on One Side of the WAN.............135
Overview: Setting up IPsec to use NAT traversal on one side of the WAN...........................136
Before you begin IPsec configuration...................................................................................136
Task summary......................................................................................................................136
Creating a forwarding virtual server for IPsec...........................................................137
Creating an IPsec tunnel with NAT-T on both sides...................................................137
Verifying IPsec connectivity for Tunnel mode.............................................................141

Chapter 15:
Using Link Aggregation with Tagged VLANs for One-Network Topology.147
Overview: Configuring link aggregation using tagged VLANs on one network.....................148
Illustration of link aggregation for a one-network topology...................................................148
Task summary......................................................................................................................149
Creating a trunk.........................................................................................................149
Adding a tagged interface to a VLAN........................................................................149
Creating a load balancing pool..................................................................................150
Creating a virtual server with source address affinity persistence............................150
Removing the self IP addresses from the default VLANs..........................................151
Creating a VLAN group..............................................................................................151
Creating a self IP for a VLAN group..........................................................................151

Chapter 16:
Using Link Aggregation with Tagged VLANs for Two-Network Topology..153
Overview: Configuring link aggregation of two interfaces using tagged VLANs on two networks.154
Illustration of link aggregation for a two-network topology.........................................154
Task summary......................................................................................................................154
Creating a trunk.........................................................................................................155
Adding a tagged interface to a VLAN........................................................................155
Creating a load balancing pool..................................................................................155
Creating a virtual server with source address affinity persistence............................156

Chapter 17: Configuring Packet Filtering........................................................157

Overview: Setting up packet filtering....................................................................................158
Task summary......................................................................................................................158
Enabling SNAT automap for internal and external VLANs.........................................158
Creating a default gateway pool................................................................................159
Creating a forwarding virtual server...........................................................................159
Enabling packet filtering on the BIG-IP system.........................................................160

7
Table of Contents

Creating a packet filter rule........................................................................................160

Chapter 18: Referencing an External File from within an iRule....................161

Overview: Referencing an external file from an iRule...........................................................162
iRule commands for iFiles.........................................................................................162
Task summary......................................................................................................................163
Importing a file to the BIG-IP system.........................................................................163
Creating an iFile........................................................................................................163
Writing an iRule that references an iFile....................................................................164
Implementation result...........................................................................................................164

Chapter 19: Configuring Remote User Authentication and Authorization....165

Overview: Remote authentication and authorization of BIG-IP user accounts.....................166
Task summary......................................................................................................................166
Specifying LDAP or Active Directory server information............................................167
Specifying client certificate LDAP server information................................................168
Specifying RADIUS server information......................................................................170
Specifying TACACS+ server information...................................................................171
Assigning access control properties to user groups..................................................172
Saving access control settings to a file......................................................................173
Importing BIG-IP configuration data onto other BIG-IP systems...............................174

Chapter 20:
Configuring Administrative Partitions to Control User Access................175
Overview: Administrative partitions for user access control.................................................176
Task summary......................................................................................................................176
Creating an administrative partition...........................................................................176
Configuring user access to a partition.......................................................................177

Chapter 21:
Implementing BIG-IP Local Traffic Manager on a vCMP System..............179
Overview: Initial vCMP setup................................................................................................180
Task summary......................................................................................................................180
Creating a vCMP guest.............................................................................................180
Setting a vCMP guest to the Deployed state.............................................................182
Provisioning a BIG-IP module within a guest............................................................182
Creating a custom HTTP profile................................................................................182
Creating a pool to manage HTTP traffic....................................................................183
Creating a virtual server to manage HTTP traffic......................................................184
Viewing host properties for slots..........................................................................................184

8
 Table of Contents

Chapter 22: Working with Single Configuration Files....................................185

Overview: Working with single configuration files.................................................................186
tmsh commands for single configuration files.......................................................................186
Task summary......................................................................................................................187
Creating and saving an SCF.....................................................................................187
Loading an SCF onto a target BIG-IP system...........................................................187
Using an SCF to restore a BIG-IP system configuration...........................................188

Chapter 23: Configuring Performance Monitoring.........................................189

Overview: Configuring performance monitoring...................................................................190
Task summary......................................................................................................................190
Adding a performance monitoring sFlow receiver.....................................................190
Implementation result...........................................................................................................192

Chapter 24: SNMP Agent Configuration..........................................................193

Overview: Configuration the SNMP agent............................................................................194
Task summary......................................................................................................................194
Specifying BIG-IP system information.......................................................................194
Configuring client access...........................................................................................194
Controlling access to SNMP data..............................................................................195
Implementation result...........................................................................................................196

Chapter 25: SNMP Trap Configuration.............................................................199

Overview: SNMP trap configuration.....................................................................................200
Task summary......................................................................................................................200
Enabling traps for specific events..............................................................................200
Setting v1 and v2c trap destination...........................................................................201
Setting v3 trap destination.........................................................................................201

Chapter 26: Using the Request Logging Profile.............................................203

Overview: Configuring a request logging profile...................................................................204
Task summary......................................................................................................................204
Creating a pool with request logging to manage HTTP traffic...................................204
Creating a request logging profile..............................................................................205
Configuring a virtual server for request logging.........................................................206
Deleting a request logging profile..............................................................................207
Request logging profile settings...........................................................................................207
Request logging parameters................................................................................................209

9
Table of Contents

10
Legal Notices

Publication Date
This document was published on April 4, 2013.

Publication Number
MAN-0379-02

Copyright
Copyright © 2012-2013, 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
Legal Notices

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.

Canadian Regulatory Compliance

This Class A digital apparatus complies with Canadian ICES-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.

12
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, [Link]
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@[Link]), which is protected under
the GNU Public License.
Acknowledgments

This product includes software developed by Niels Mueller (nisse@[Link]), 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
([Link]
This product includes software licensed from Richard H. Porter under the GNU Library General Public
License (© 1998, Red Hat Software), [Link]/copyleft/[Link].
This product includes the standard version of Perl software licensed under the PerlArtistic License (© 1997,
1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard
version of Perl at [Link]
This product includes software developed by Jared Minch.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
([Link]
This product includes cryptographic software written by Eric Young (eay@[Link]).
This product contains software based on oprofile, which is protected under the GNU Public License.
This product includes RRDtool software developed by Tobi Oetiker ([Link]
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 ([Link]
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. ([Link]
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
acknowledgment: This product includes software developed by the Computer Systems Engineering
Group at Lawrence Berkeley Laboratory.

14
 BIG-IP® TMOS®: Implementations

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.
THIS SOFTWARE IS PROVIDED BY SONY CSLAND 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.

15
Acknowledgments

16
Chapter
1
Customizing the BIG-IP Dashboard
Topics:

• Overview: BIG-IP dashboard customization

• Customizing the BIG-IP dashboard
Customizing the BIG-IP Dashboard

Overview: BIG-IP dashboard customization

The BIG-IP® dashboard displays system statistics in selectable graphs, gauges, and tables. In addition to
the pre-defined views, you can create custom combinations of the dashboard windows, called views, and
save them in groups, called view sets. You can combine windows from different BIG-IP modules in a single
view, or use just the windows you want for a single module. Windows are available only for those modules
that you have licensed and provisioned.

Note: The view set name for all pre-defined views is standard.

Customizing the BIG-IP dashboard

You can create custom dashboard displays using the windows for any modules that are available on the
BIG-IP® system.

1. On the Main tab, expand Overview, and click Dashboard.

A separate window opens for the BIG-IP dashboard.
2. On the Views control bar, click the Create custom view icon.
A blank canvas opens in design [Link] Dashboard Windows Chooser displays the available windows,
grouped by module. You can click a module to display the available windows.
3. From the Dashboard Windows Chooser, drag and drop the windows you want onto the canvas.
After you drag a window to the canvas, you can resize it or change it to display the information you
want by clicking a tab or filter.

Note: The windows are not active when in design mode, so the data does not update in real
time.

4. When you have placed the windows you want onto the canvas, click the Save icon on the Custom Views
control bar.
The Save View popup window opens.
5. Type a name for the view.
6. Type a new name for the view set, or select from the list.
7. Click OK.
The new view is saved, and appears in the Views list.
8. Click the double-gear icon on the Custom Views control bar to return to active mode.
The dashboard displays the custom view you just created, and updates the display with real-time data.

18
Chapter
2
Creating an Active-Standby Configuration Using the Setup
Utility
Topics:

• Overview: Creating a basic active-standby

configuration
• Task summary
• Implementation result
Creating an Active-Standby Configuration Using the Setup Utility

Overview: Creating a basic active-standby configuration

This implementation describes how to configure two new BIG-IP® devices that function as an active-standby
pair. An active-standby pair is a pair of BIG-IP devices configured so that one device is actively processing
traffic while the other device remains ready to take over if failover occurs. The two devices synchronize
their configuration data and can fail over to one another in the event that one of the devices becomes
unavailable.

Important: The same version of BIG-IP system software must be running on all devices in the
device group.

First, you can run the Setup utility on each device to configure base network components (that is, a
management port, administrative passwords, and the default VLANs and their associated self IP addresses).
Continue running it on each device to establish a trust relationship between the two devices, and create a
Sync-Failover type of device group that contains two member devices.
After the Setup utility is run on both devices, each device contains the default traffic group that the BIG-IP
system automatically created during setup. A traffic group represents a set of configuration objects (such
as floating self IP addresses and virtual IP addresses) that process application traffic. This traffic group
actively processes traffic on one of the two devices, making that device the active device. When failover
occurs, the traffic group will become active on (that is, float to) the peer BIG-IP device.
By default, the traffic group contains the floating self IP addresses of the default VLANs. Whenever you
create additional configuration objects such as self IP addresses, virtual IP addresses, and SNATs, the system
automatically adds these objects to the default traffic group.

Task summary
The configuration process for a BIG-IP® system entails running the Setup utility on each of the two BIG-IP
devices. When you run the Setup utility, you perform several tasks. Completing these tasks results in both
BIG-IP devices being configured properly for an active/standby implementation.
Licensing and provisioning the BIG-IP system
Configuring the management port and administrative user accounts
Enabling ConfigSync and high availability
Configuring the internal network
Configuring the external network
Configuring the network for high availability
Configuring a ConfigSync address
Configuring failover and mirroring addresses
Discovering a peer device

Licensing and provisioning the BIG-IP system

Using the Setup utility, you can activate the license and provision the BIG-IP® system.

20
 BIG-IP® TMOS®: Implementations

1. In a browser window, type the URL that specifies the management IP address of the BIG-IP® device:
[Link]
The login screen for the Configuration utility opens.
2. At the login prompt, type user name admin, and password admin, and click Log in.

Tip: admin/admin are the default login values.

The Setup utility screen opens.

3. Click Next.
4. Click Activate.
The License screen opens.
5. In the Base Registration Key field, paste the registration key.
6. Click Next and follow the process for licensing and provisioning the BIG-IP system.
7. Click Next.
This displays the screen for configuring general properties and user administration settings.

The BIG-IP system license is now activated, and the relevant BIG-IP modules are provisioned.

Configuring the management port and administrative user accounts

Configure the management port, time zone, and the administrative user names and passwords.

1. On the screen for configuring general properties, for the Management Port Configuration setting,
select Manual and specify the IP address, network mask, and default gateway.
2. In the Host Name field, type a fully-qualified domain name (FQDN) for the system.
You must type letters, numbers, and/or the characters underscore ( _ ), dash ( - ) and period ( . ).
3. For the Host IP Address setting, retain the default value Use Management Port IP Address.
4. From the Time Zone list, select a time zone.
The time zone you select typically reflects the location of the BIG-IP® system.
5. For the Root Account setting, type and confirm a password for the root account.
The root account provides console access only.
6. For the Admin Account setting, type and confirm a password.
Typing a password for the admin account causes the system to terminate the login session. When this
happens, log in to the BIG-IP Configuration utility again, using the new password. The system returns
to the appropriate screen in the Setup utility.
7. For the SSH Access setting, select or clear the check box.
8. Click Next.
9. In the Standard Network Configuration area of the screen, click Next.
This displays the screen for enabling configuration synchronization and high availability.

Enabling ConfigSync and high availability

When you perform this task, the Setup utility enables ConfigSync and connection mirroring, and allows
you to specify the failover method (network, serial, or both).

1. For the Config Sync setting, select the Display configuration synchronization options check box.
This causes an additional ConfigSync screen to be displayed later.

21
Creating an Active-Standby Configuration Using the Setup Utility

2. For the High Availability setting, select the Display failover and mirroring options check box.
This displays the Failover Method list and causes additional failover screens to be displayed later.
3. From the Failover Method list, select Network and serial cable.
If you have a VIPRION® system, select Network.
4. Click Next.
This displays the screen for configuring the default VLAN internal.

Configuring the internal network

Specify self IP addresses and settings for VLAN internal, which is the default VLAN for the internal
network.

1. Specify the Self IP setting for the internal network:

a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
c) For the Port Lockdown setting, retain the default value.
2. Specify the Floating IP setting:
a) In the Address field, type a floating IP address.
This address should be distinct from the address you type for the Self IP setting.
b) For the Port Lockdown setting, retain the default value.
3. For the VLAN Tag ID setting, retain the default value, auto.
This is the recommended value.
4. For the VLAN Interfaces setting, click the interface 1.1 and, using the Move button, move the interface
number from the Available list to the Untagged list.
5. Click Next.
This completes the configuration of the internal self IP addresses and VLAN, and displays the screen
for configuring the default VLAN external.

Configuring the external network

Specify self IP addresses and settings for VLAN external, which is the default VLAN for the external
network.

1. Specify the Self IP setting for the external network:

a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
c) For the Port Lockdown setting, retain the default value.
2. In the Default Gateway field, type the IP address that you want to use as the default gateway to VLAN
external.
3. Specify the Floating IP setting:
a) In the Address field, type a floating IP address.
This address should be distinct from the address you type for the Self IP setting.
b) For the Port Lockdown setting, retain the default value.
4. For the VLAN Tag ID setting, retain the default value, auto.

22
 BIG-IP® TMOS®: Implementations

This is the recommended value.

5. For the VLAN Interfaces setting, click the interface 1.2 and, using the Move button, move the interface
number from the Available list to the Untagged list.
6. Click Next.
This completes the configuration of the external self IP addresses and VLAN, and displays the screen
for configuring the default VLAN HA.

Configuring the network for high availability

To configure a network for high availability, specify self IP addresses and settings for VLAN HA, which is
the VLAN that the system will use for failover and connection mirroring.

1. For the High Availability VLAN setting, retain the default value, Create VLAN HA.
2. Specify the Self IP setting for VLAN HA:
a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
3. For the VLAN Tag ID setting, retain the default value, auto.
This is the recommended value.
4. For the VLAN Interfaces setting, click an interface number, and using the Move button, move the
interface number from the Available list to the Untagged list.
5. Click Next.
This configures the self IP address and VLAN that the system will use for high availability and displays
the default IP address that the system will use for configuration synchronization.

Configuring a ConfigSync address

Use this task to specify the address that you want the system to use for configuration synchronization.

1. From the Local Address list, select a self IP address.

Do not select a management IP address.
2. Click Next.
This displays the screen for configuring unicast and multicast failover addresses.

Configuring failover and mirroring addresses

Follow these steps to specify the local unicast and mirroring addresses that you want the BIG-IP® system
to use for high availability. During the final step of running the Setup utility, the system exchanges these
addresses with its trusted peer. If you are configuring a VIPRION® system, configure a multicast failover
address as well.

1. Locate the Failover Unicast Configuration area of the screen.

2. Under Local Address, confirm that there are entries for the self IP address that is assigned to the HA
and internal and VLANs and for the local management IP address for this device. If these entries are
not absent, click the Add button to add the missing entries to the list of Failover Unicast Addresses.
a) For the Address setting, select the self IP address for the VLAN you need to add (either HA or
internal).

23
Creating an Active-Standby Configuration Using the Setup Utility

b) In the Port field, type a port number or retain the default port number, 1026.
c) Either click Repeat to add additional addresses, or click Finished.
3. Click Next.
4. From the Primary Local Mirror Address list, retain the default value, which is the self IP address for
VLAN HA.
5. From the Secondary Local Mirror Address list, select the address for VLAN internal.
6. Click Finished.

Discovering a peer device

You can use the Setup utility to discover a peer device for the purpose of exchanging failover and mirroring
information.

1. Under Standard Pair Configuration, click Next.

2. If this is the first device of the pair that you are setting up, then under Configure Peer Device, click
Finished.
To activate device discovery, you must first run the Setup utility on the peer device.
3. If this is the second device of the pair that you are setting up:
a) Under Discover Configured Peer Device, click Next.
b) Under Remote Device Credentials, specify the Management IP address, Administrator
Username, and Administrator Password.
c) Click Retrieve Device Information.
4. Click Finished.

After the second device has discovered the first device, the two devices have a trust relationship and constitute
a two-member device group. Also, each device in the pair contains a default traffic group named
Traffic-Group-1. By default, this traffic group contains the floating IP addresses that you defined for
VLANs internaland external.

Implementation result
To summarize, you now have the following BIG-IP® configuration on each device of the pair:
• A management port, management route, and administrative passwords defined.
• A VLAN named internal, with one static and one floating IP address.
• A VLAN named external, with one static and one floating IP address.
• A VLAN named HA with a static IP address.
• Configuration synchronization, failover, and mirroring enabled.
• Failover methods of serial cable and network (or network-only, for a VIPRION® platform.
• A designation as an authority device, where trust was established with the peer device.
• A Sync-Failover type of device group with two members defined.
• A default traffic group that floats to the peer device to process application traffic when this device
becomes unavailable. This traffic group contains two floating self IP addresses for VLANs internal
and external.

24
 BIG-IP® TMOS®: Implementations

On either device in the device group, you can create additional configuration objects, such as virtual IP
addresses and SNATs. The system automatically adds these objects to Traffic-Group-1.

25
Creating an Active-Standby Configuration Using the Setup Utility

26
Chapter
3
Creating an Active-Active Configuration Using the Setup
Utility
Topics:

• Overview: Creating a basic active-active

configuration
• Task summary
• Implementation Results
Creating an Active-Active Configuration Using the Setup Utility

Overview: Creating a basic active-active configuration

This implementation describes how to configure two new BIG-IP® devices that function as an active-active
pair. An active-active pair is a pair of BIG-IP devices configured so that both devices are actively processing
traffic and are ready to take over one another if failover occurs. The two devices synchronize their
configuration data to one another.

Important: The same version of BIG-IP system software must be running on all devices in the
device group.

Using this implementation, you begin by running the Setup utility on each device to configure its base
network components. Base network components include a management port, administrative passwords,
and default VLANs and their associated self IP addresses. You also use Setup to configure configuration
synchronization and high availability.
You then use the BIG-IP® Configuration utility to:
• Establish trust between the two devices
• Create a Sync-Failover type of device group that contains two member devices
• Create a second traffic group
• Create two applications with iApps™
In this configuration, both devices actively process application traffic, each for a different application. One
device processes its application traffic using the configuration objects associated with the default floating
traffic group, traffic-group-1. By default, this traffic group contains the floating self IP addresses of
the default VLANs. The other device processes its application traffic using a second traffic group that you
create.
If one of the devices becomes unavailable for any reason, the other device automatically begins processing
traffic for the unavailable peer, while continuing to process the traffic for its own application.
This illustration shows an example of the device group that this implementation creates, named Device
Group A. This device group contains two BIG-IP devices, Device 1 and Device 2.

The configuration shows two traffic groups, traffic-group-1 and traffic-group-2, each containing
failover objects. For traffic-group-1, Device 1 is the default device. For traffic-group-2, Device
2 is the default device. If Device 1 becomes unavailable, traffic-group-1 floats to Device 2. If
Device 2 becomes unavailable, traffic-group-2 floats to Device 1.

28
 BIG-IP® TMOS®: Implementations

Figure 1: Device group with active-active configuration

By implementing this configuration, you ensure that:

• Each device has base network components configured.
• Any objects on a BIG-IP device that you configure for synchronization remain synchronized between
the two devices.
• Failover capability and connection mirroring are enabled on each device.

Task summary
The BIG-IP® configuration process begins with running the Setup utility on each of the two BIG-IP devices.
Once you have completed that task, you can log into either of the BIG-IP devices and perform all of the
remaining tasks, on that device only. This results in both BIG-IP devices being configured properly for an
active-active implementation.
Licensing and provisioning the BIG-IP system
Configuring the management port and administrative user accounts
Enabling ConfigSync and high availability
Configuring the internal network
Configuring the external network
Configuring the network for high availability
Configuring a ConfigSync address
Configuring failover and mirroring addresses
Establishing device trust
Creating a Sync-Failover device group
Creating an iApp application for the local device
Creating a traffic group for a remote device
Creating an iApp application for a remote device
Forcing a traffic group to a standby state
Syncing the BIG-IP configuration to the device group

29
Creating an Active-Active Configuration Using the Setup Utility

Licensing and provisioning the BIG-IP system

Using the Setup utility, you can activate the license and provision the BIG-IP® system.

1. In a browser window, type the URL that specifies the management IP address of the BIG-IP® device:
[Link]
The login screen for the Configuration utility opens.
2. At the login prompt, type user name admin, and password admin, and click Log in.

Tip: admin/admin are the default login values.

The Setup utility screen opens.

3. Click Next.
4. Click Activate.
The License screen opens.
5. In the Base Registration Key field, paste the registration key.
6. Click Next and follow the process for licensing and provisioning the BIG-IP system.
7. Click Next.
This displays the screen for configuring general properties and user administration settings.

The BIG-IP system license is now activated, and the relevant BIG-IP modules are provisioned.

Configuring the management port and administrative user accounts

Configure the management port, time zone, and the administrative user names and passwords.

1. On the screen for configuring general properties, for the Management Port Configuration setting,
select Manual and specify the IP address, network mask, and default gateway.
2. In the Host Name field, type a fully-qualified domain name (FQDN) for the system.
You must type letters, numbers, and/or the characters underscore ( _ ), dash ( - ) and period ( . ).
3. For the Host IP Address setting, retain the default value Use Management Port IP Address.
4. From the Time Zone list, select a time zone.
The time zone you select typically reflects the location of the BIG-IP® system.
5. For the Root Account setting, type and confirm a password for the root account.
The root account provides console access only.
6. For the Admin Account setting, type and confirm a password.
Typing a password for the admin account causes the system to terminate the login session. When this
happens, log in to the BIG-IP Configuration utility again, using the new password. The system returns
to the appropriate screen in the Setup utility.
7. For the SSH Access setting, select or clear the check box.
8. Click Next.
9. In the Standard Network Configuration area of the screen, click Next.
This displays the screen for enabling configuration synchronization and high availability.

30
 BIG-IP® TMOS®: Implementations

Enabling ConfigSync and high availability

When you perform this task, the Setup utility enables ConfigSync and connection mirroring, and allows
you to specify the failover method (network, serial, or both).

1. For the Config Sync setting, select the Display configuration synchronization options check box.
This causes an additional ConfigSync screen to be displayed later.
2. For the High Availability setting, select the Display failover and mirroring options check box.
This displays the Failover Method list and causes additional failover screens to be displayed later.
3. From the Failover Method list, select Network and serial cable.
If you have a VIPRION® system, select Network.
4. Click Next.
This displays the screen for configuring the default VLAN internal.

Configuring the internal network

Specify self IP addresses and settings for VLAN internal, which is the default VLAN for the internal
network.

1. Specify the Self IP setting for the internal network:

a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
c) For the Port Lockdown setting, retain the default value.
2. Specify the Floating IP setting:
a) In the Address field, type a floating IP address.
This address should be distinct from the address you type for the Self IP setting.
b) For the Port Lockdown setting, retain the default value.
3. For the VLAN Tag ID setting, retain the default value, auto.
This is the recommended value.
4. For the VLAN Interfaces setting, click the interface 1.1 and, using the Move button, move the interface
number from the Available list to the Untagged list.
5. Click Next.
This completes the configuration of the internal self IP addresses and VLAN, and displays the screen
for configuring the default VLAN external.

Configuring the external network

Specify self IP addresses and settings for VLAN external, which is the default VLAN for the external
network.

1. Specify the Self IP setting for the external network:

a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
c) For the Port Lockdown setting, retain the default value.

31
Creating an Active-Active Configuration Using the Setup Utility

2. In the Default Gateway field, type the IP address that you want to use as the default gateway to VLAN
external.
3. Specify the Floating IP setting:
a) In the Address field, type a floating IP address.
This address should be distinct from the address you type for the Self IP setting.
b) For the Port Lockdown setting, retain the default value.
4. For the VLAN Tag ID setting, retain the default value, auto.
This is the recommended value.
5. For the VLAN Interfaces setting, click the interface 1.2 and, using the Move button, move the interface
number from the Available list to the Untagged list.
6. Click Next.
This completes the configuration of the external self IP addresses and VLAN, and displays the screen
for configuring the default VLAN HA.

Configuring the network for high availability

To configure a network for high availability, specify self IP addresses and settings for VLAN HA, which is
the VLAN that the system will use for failover and connection mirroring.

1. For the High Availability VLAN setting, retain the default value, Create VLAN HA.
2. Specify the Self IP setting for VLAN HA:
a) In the Address field, type a self IP address.
b) In the Netmask field, type a network mask for the self IP address.
3. For the VLAN Tag ID setting, retain the default value, auto.
This is the recommended value.
4. For the VLAN Interfaces setting, click an interface number, and using the Move button, move the
interface number from the Available list to the Untagged list.
5. Click Next.
This configures the self IP address and VLAN that the system will use for high availability and displays
the default IP address that the system will use for configuration synchronization.

Configuring a ConfigSync address

Use this task to specify the address that you want the system to use for configuration synchronization.

1. From the Local Address list, select a self IP address.

Do not select a management IP address.
2. Click Next.
This displays the screen for configuring unicast and multicast failover addresses.

Configuring failover and mirroring addresses

Follow these task steps to specify the unicast IP addresses of the local device that you want the system to
use for failover. Typically, you specify the self IP address for the local VLAN HA, as well as the IP address

32
 BIG-IP® TMOS®: Implementations

for the management port of the local device. If you are configuring a VIPRION® system, configure a
multicast failover address as well.

Important: When configuring failover and mirroring IP addresses, you select addresses of the
local device only. Later, during the process of device discovery, the two devices in the device group
discover each other's addresses.

1. Locate the Failover Unicast Configuration area of the screen.

2. Under Local Address, confirm that there are entries for the self IP address that is assigned to the HA
and internal and VLANs and for the local management IP address for this device. If these entries are
not absent, click the Add button to add the missing entries to the list of Failover Unicast Addresses.
a) For the Address setting, select the self IP address for the VLAN you need to add (either HA or
internal).
b) In the Port field, type a port number or retain the default port number, 1026.
c) Either click Repeat to add additional addresses, or click Finished.
3. Click Next.
4. From the Primary Local Mirror Address list, retain the default value, which is the self IP address for
VLAN HA.
5. From the Secondary Local Mirror Address list, select the address for VLAN internal.
6. Click Finished.
This exits the Setup utility.

Establishing device trust

Verify that each BIG-IP® device that is to be part of a local trust domain has a device certificate installed
on it.
This task establishes a local trust domain between the local device (that is, the device you are logged in to)
and devices you specify during the process.A local trust domain is any number of BIG-IP devices that have
a trust relationship with one another. Perform this task on any one of the BIG-IP devices that will be in the
same device group.

1. On the Main tab, click Device Management/Device Trust, and then either Peer List or Subordinate
List.
2. In the Peer Authority Devices or the Subordinate Non-Authority Devices area of the screen, click Add.
3. Type an IP address, administrator user name, and administrator password for the remote BIG-IP® device.
This IP address can be either a management IP address or a self IP address.
4. Click Retrieve Device Information.
5. Verify that the certificate of the remote device is correct.
6. Verify that the name of the remote device is correct.
7. Verify that the management IP address and name of the remote device are correct.
8. Click Finished.

Creating a Sync-Failover device group

This task establishes failover capability between two BIG-IP® devices. If the active device in a Sync-Failover
device group becomes unavailable, the configuration objects fail over to another member of the device

33
Creating an Active-Active Configuration Using the Setup Utility

group and traffic processing is unaffected. You can perform this task on any authority device within the
local trust domain.

1. On the Main tab, click Device Management > Device Groups.

The Device Groups screen displays a list of existing device groups.
2. On the Device Group List screen, click Create.
3. Type a name for the device group, select the device group type Sync-Failover, and type a description
for the device group.
4. In the Configuration area of the screen, select a host name from the Available list for each BIG-IP device
that you want to include in the device group. Use the Move button to move the host name to theSelected
list.
The Available list shows any devices that are members of the device's local trust domain but not currently
members of a Sync-Failover device group. A device can be a member of one Sync-Failover group only.
5. For Network Failover, select the Enabled check box.
6. Click Finished.

You now have a Sync-Failover device group containing two BIG-IP devices as members.

Creating an iApp application for the local device

Use this procedure to create a set of related configuration objects on the system (that is, an application).

1. On the Main tab, click iApp > Application Services.

2. Click Create.
3. In the Name field, type the name for your application service.
4. From the Template List tab, select a template.
5. From the Template Selection list, select Advanced.
This causes additional settings to appear.
6. For the Configure Sync and/or Failover for this application? setting, select Yes.
7. For the Traffic Group setting, ensure that the Inherit traffic group from current partition / path
field and traffic-group-1 are selected.
8. Configure remaining settings as needed.
9. At the bottom of the screen click Finished to save your changes.

You now have an iApp application, which is associated with the traffic group assigned to the root folder,
traffic-group-1.

Creating a traffic group for a remote device

Prerequisite: If you intend to specify a MAC masquerade address when creating a traffic group, you must
first create the address, using an industry-standard method for creating a locally-administered MA
C address.
Perform this procedure to create a traffic group to run on the remote BIG-IP ®device. You create this traffic
group on the local device. Later, you move the traffic group to the remote device by forcing this traffic
group on the local device to a standby state.

1. On the Main tab, click Network > Traffic Groups.

2. On the lower half of the screen, verify that the list shows the default floating traffic group (traffic-group-1)
for the local device.
3. On the Traffic Group List screen, click Create.

34
 BIG-IP® TMOS®: Implementations

4. Type the name traffic-group-2 for the new traffic group.

5. Type a description of the new traffic group.
6. Click Next.
7. In the MAC Masquerade Address field, type a MAC masquerade address.
When you specify a MAC masquerade address, you reduce the risk of dropped connections when ailover
f
occurs. This setting is optional.
8. Click Next.
9. Select or clear the check box for the Auto Failback option.
• Select causes the traffic group to be active on its default device whenever that device is as available,
or more available, than another device in the group.
• Clear causes the traffic group to remain active on its current device until failover occurs again.

10. Click Next.

11. Confirm that the displayed traffic group settings are correct.
12. Click Finished.

You now have a floating traffic group for which the default device is the peer device.

Creating an iApp application for a remote device

Use this procedure when you want to create an application to run on a remote device and associate it with
the traffic group named traffic-group-2 that you previously created.

1. On the Main tab, click iApp > Application Services.

2. Click Create.
3. From the Template List tab, select a template.
4. From the Template Selection list, select Advanced.
This causes additional settings to appear.
5. In the Name field, type the name for your application service.
6. For the Configure Sync and/or Failover for this application? setting, select Yes.
7. For the Traffic Group setting, clear the Inherit traffic group from current partition / path field
and from the list, select traffic-group-2.
8. Configure remaining settings as needed.
9. At the bottom of the screen click Finished to save your changes.

You now have an iApp application associated with traffic-group-2.

Forcing a traffic group to a standby state

This task causes the selected traffic group on the local device to switch to a standby state. By forcing the
traffic group into a standby state, the traffic group becomes active on another device in the device group.
For device groups with more than two members, you can choose the specific device to which the traffic
group fails over. This task is optional.

1. Log in to the device on which the traffic group is currently active.

2. On the Main tab, click Network > Traffic Groups.
3. In the Name column, locate the name of the traffic group that you want to run on the peer device.
4. Select the check box to the left of the traffic group name.

35
Creating an Active-Active Configuration Using the Setup Utility

If the check box is unavailable, the traffic group is not active on the device to which you are currently
logged in. Perform this task on the device on which the traffic group is active.
5. Click Force to Standby.
This displays target device options.
6. Choose one of these actions:
• If the device group has two members only, click Force to Standby. This displays the list of traffic
groups for the device group and causes the local device to appear in the Next Active Device column.
• If the device group has more than two members, then from the Target Device list, select a value
and click Force to Standby.

The selected traffic group is now active on another device in the device group.

Syncing the BIG-IP configuration to the device group

Before starting this task, verify that all devices targeted for ConfigSync are members of a device group and
that device trust has been established.
This task synchronizes the BIG-IP® configuration data from the local device to all devices in the group.
This synchronization ensures that the entire redundant system configuration operates properly within the
device group. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP
addresses only.

Important: Perform the following procedure on only one of the two devices.

1. On the Main tab, click Device Management > Device Groups.

The Device Groups screen displays a list of existing device groups.
2. In the Group Name column, click the name of the relevant device group.
3. On the menu bar, click ConfigSync.
4. Click Synchronize To Group.

Except for non-floating self IP addresses, the entire set of BIG-IP configuration data is replicated on each
device in the device group.

Implementation Results
To summarize, you now have the following BIG-IP® configuration on each device of the pair:
• A management port, management route, and administrative passwords defined
• A VLAN named internal, with one static and one floating IP address
• A VLAN named external, with one static and one floating IP address
• A VLAN named HA with a static IP address
• Configuration synchronization, failover, and mirroring enabled
• Failover methods of serial cable and network
• Local IP addresses defined for failover and connection mirroring
• A designation as an authority device, where trust is established with the peer device
• A Sync-Failover type of device group with two members
• The default traffic group named traffic-group-1 with Device 1 as the default device

36
 BIG-IP® TMOS®: Implementations

• An iApp application associated with traffic-group-1

• A traffic group named traffic-group-2 with Device 2 as the default device
• An iApp application associated with traffic-group-2

37
Creating an Active-Active Configuration Using the Setup Utility

38
Chapter
4
Upgrading Active-Standby Systems
Topics:

• Overview: Upgrading BIG-IP active-standby

systems
• Task summary
• Implementation result
Upgrading Active-Standby Systems

Overview: Upgrading BIG-IP active-standby systems

A BIG-IP® system active-standby pair for version 10.x includes one BIG-IP system operating in active
mode (Device A) and one BIG-IP system operating in standby mode (Device B).

Figure 2: A version 10.x active-standby pair

After preparing the devices for an upgrade to version 11.x, you install version 11.x onto Device B (the
standby device). When you finish the installation of version 11.x onto Device B, it creates a traffic group
called traffic-group-1. The version 11.x traffic group is in standby state on Device B, and Device A
(the version 10.x device) is in active mode. Note that the Unit ID that was used in version 10.x becomes
obsolete in version 11.x.

40
 BIG-IP® TMOS®: Implementations

Figure 3: A version 10.x device in active mode and a version 11.x traffic group in standby
state

With version 11.x installed on Device B and traffic-group-1 in standby state, you can install version 11.x
onto Device A, force Device A to standby mode, which changes Device B to active state so that it can pass
traffic, and reboot Device A to the location of the 11.x software image. When you complete upgrading both
devices to version 11.x, the BIG-IP configuration includes a traffic group in active state on Device B, a
traffic group in standby state on Device A, and a device group that includes both devices.

41
Upgrading Active-Standby Systems

Figure 4: A version 11.x traffic group in active and standby states

An upgrade of BIG-IP active-standby systems to version 11.x involves the following tasks.

Task Description
Preparing Device A (the active mode BIG-IP 1 In preparing to upgrade the active-standby BIG-IP
system) and Device B (the standby mode BIG-IP 2 systems to version 11.x, you need to understand any
system) specific configuration or functional changes from
the previous version, and prepare the systems. You
also download the new version of software from the
AskF5 web site ([Link]) and import the
files onto each device.
Upgrading Device B (the standby mode BIG-IP 2 When you complete preparation of Device B, you
system) can upgrade the software on that device.
Upgrading Device A (the standby mode BIG-IP 1 When you complete upgrading Device B, you can
system) prepare Device A and upgrade the software on
Device A.
Verifying the upgrade Finally, you should verify that your active and
standby BIG-IP systems are functioning properly.
Configuring module-specific settings According to your understanding of the configuration
and functional changes from the previous version,
you can reconfigure any customized module settings.

About new BIG-IP system configuration components

BIG-IP® redundant system configuration is based on a few key components.

42
 BIG-IP® TMOS®: Implementations

Devices
A device is a physical or virtual BIG-IP system, as well as a member of a local trust domain and a device
group. Each device member has a set of unique identification properties that the BIG-IP® system generates.

Device groups
A device group is a collection of BIG-IP® devices that trust each other and can synchronize, and sometimes
fail over, their BIG-IP configuration data.

Important: To configure redundancy on a device, you do not need to explicitly specify that you
want the BIG-IP device to be part of a redundant configuration. Instead, this occurs automatically
when you add the device to an existing device group.

You can create two types of devices groups:

Sync-Failover
A Sync-Failover device group contains devices that synchronize configuration data and support traffic
groups for failover purposes when a device becomes unavailable.
Sync-Only
A Sync-Only device group contains devices that synchronize configuration data, such as policy data,
but do not synchronize failover objects.
A BIG-IP device can be a member of only one Sync-Failover group. However, a device can be a member
of both a Sync-Failover device group and a Sync-Only device group.
To minimize issues with config sync, failover, or mirroring, F5 Networks recommends as a best practice
that devices in a device group match as closely as possible with respect to hardware platform, product
licensing, and module provisioning. At a minimum, mirroring requires that the hardware platforms of the
mirrored devices match, and config sync between devices requires that the devices are running the same
version of BIG-IP system software.

Traffic groups
A traffic group is a collection of related configuration objects (such as a virtual IP address and a self IP
address) that run on a BIG-IP device and process a particular type of application traffic. When a BIG-IP
device becomes unavailable, a traffic group can float to another device in a device group to ensure that
application traffic continues to be processed with little to no interruption in service.

Device trust and trust domains

Underlying successful operation of device groups and traffic groups is a feature known as device trust.
Device trust establishes trust relationships between BIG-IP devices on the network, through mutual
certificate-based authentication. A trust domain is a collection of BIG-IP devices that trust one another and
can therefore synchronize and fail over their BIG-IP configuration data, as well as exchange status and
failover messages on a regular basis. A local trust domain is a trust domain that includes the local device,
that is, the device you are currently logged in to.

Folders and sub folders

Folders and sub-folders are containers for the configuration objects on a BIG-IP device. For every
administrative partition on the BIG-IP system, there is a high-level folder. At the highest level of the folder
hierarchy is a folder named root. The BIG-IP system uses folders to affect the level of granularity to which
it synchronizes configuration data to other devices in the device group. You can create sub-folders within
a high-level folder, using tmsh.

43
Upgrading Active-Standby Systems

Note: In most cases, you can manage redundancy for all device group members remotely from one
specific member. However, there are cases when you must log in locally to a device group member
to perform a task. An example is when resetting device trust on a device.

About traffic groups

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 floats (that is, fails over) to another device in a device group to ensure that application traffic
continues to be processed with little to no interruption in service. 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 number of active traffic groups on each device.
A traffic group is initially active on the device on which you create it, until the traffic group fails over to
another device. For example, if you initially create three traffic groups on Device A, these traffic groups
remain active on Device A until one or more traffic groups fail over to another device. If you want to balance
the traffic group load among all devices in the device group, you can intentionally cause a traffic group to
fail over to another device. You do this using the Force to Standby option of the Configuration utility.

Important: Although a specific traffic group can be active on only one device in a device group,
the traffic group actually resides and is in a standby state on all other device group members, due
to configuration synchronization.

Only certain types of configuration objects can belong to a traffic group. Examples of traffic group objects
are self IP addresses and virtual IP addresses.
An example of a set of objects in a traffic group is an iApps™ 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 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 is
normally the device with the least number of active traffic groups. When you initially create the traffic
group on a device, however, you specify the device in the group that you prefer that traffic group to run on
in the event that the available devices have an equal number of active traffic groups (that is, no device has
fewer active traffic groups than another). Note that, in general, the system considers the most available
device in a device group to be the device that contains the fewest active traffic groups at any given time.

Note: A Sync-Failover device group can support a maximum of 15 traffic groups.

Task summary
The upgrade process involves preparation of the two BIG-IP® devices (Device A and Device B) configured
in an active-standby implementation, followed by the installation and verification of version 11.x on each
device. When you upgrade each device, you perform several tasks. Completing these tasks results in a
successful upgrade to version 11.x on both BIG-IP devices, with a traffic group configured properly for an
active-standby implementation.
Preparing BIG-IP modules for an upgrade from version 10.x to version 11.x
Preparing BIG-IP active-standby systems for an upgrade

44
 BIG-IP® TMOS®: Implementations

Upgrading the standby BIG-IP 2 system

Upgrading the active BIG-IP 1 system
Verifying a BIG-IP active-standby upgrade

Preparing BIG-IP modules for an upgrade from version 10.x to version 11.x
Before you upgrade the BIG-IP® system from version 10.x to version 11.x, you might need to manually
prepare settings or configurations for specific modules.

Access Policy Manager system preparation

The Access Policy Manager® system does not require specific preparation when upgrading from version
10.x to version 11.x. However, additional configuration might be required after completing the upgrade to
version 11.x.

Post-upgrade activities
When you complete upgrading to version 11.x, you should consider the following feature or functionality
changes that occur for the Access Policy Manager systems. Depending upon your configuration, you might
need to perform these changes after you upgrade your systems.

Feature or Functionality Description

Sessions All users currently logged in while the upgrade
occurs will need to log in again.
Authentication agents and SSO methods If you have deployments using ActiveSync or
Outlook Anywhere, where the domain name is part
of the username, you should enable theSplit domain
from username option in the login page agent if the
authentication method used in the access policy
requires just the username for authentication. In
BIG-IP® APM™ 11.x.x, authentication agents and
SSO methods no longer separates the domain name
from the username internally.
iRule for processing URI If you have deployments where an iRule is used to
perform processing on internal access control URI,
for example, /[Link], /myvpn or other URIs
like APM system's logon page request, you need to
enable the iRule events for internal access control
URIs because by default, BIG-IP APM 11.x.x does
not raise iRule events for internal access control
URIs. However, this can be achieved by adding the
following code to the iRule:
when CLIENT_ACCEPTED {

ACCESS::restrict_irule_events
disable
}

OAM support Manually remove all the OAM server-related

configurations and reconfigure OAM on BIG-IP

45
Upgrading Active-Standby Systems

Feature or Functionality Description

APM 11.x.x. OAM configuration has been modified
to support various OAM 11G related use-cases.
Citrix support functionality The Citrix iRule is no longer visible to the
administrator because it is integrated natively in
BIG-IP APM 11.x.x. If you have not modified the
iRule, then you have to enable the Citrix Support
setting on the virtual server to use Citrix. If you
modified the F5 provided Citrix support iRule and
want to use the modified iRule, you need to contact
F5 support and work with them to replace natively
integrated iRules® with your own version of Citrix
supported iRules®.
Reporting functionality If you used the [Link] script for your
logging or reporting purposes, this script is no longer
available in BIG-IP APM 11.x.x. You need to
migrate to the new and enhanced reporting and
logging functionality available as a built-in
functionality on version 11.x.x.

Application Security Manager system preparation

The BIG-IP® Application Security Manager™(ASM™) system does not require specific preparation when
upgrading from version 10.x to version 11.x. No additional configuration is required after completing the
upgrade to version 11.x.

What to expect after upgrading a redundant system

If you update two redundant systems that are running as an active-standby pair with BIG-IP Application
Security Manager (ASM) and BIG-IP® Local Traffic Manager™(LTM®) provisioned, the system maintains
the active-standby status and automatically creates a Sync-Failover device group and a traffic group containing
both systems. The device group is enabled for BIG-IPASM (because both systems have ASM provisioned).
You can manually push or pull the updates (including BIG-IP LTM and ASM configurations and policies)
from one system to the other (Device Management > Device Groups, then click Config Sync and choose
Synchronize TO/FROM Group).

Global Traffic Manager system preparation and configuration

BIG-IP® Global Traffic Manager™ (GTM™) systems do not require any preparation to upgrade from version
10.x to version 11.x.
The following feature or functionality changes occur after you complete the upgrade process to version
11.x.

Feature or Functionality Description

Assigning a BIG-IP system to probe a server to Assigning a single BIG-IP system to probe a server
gather health and performance data to gather health and performance data, in version
10.x, is replaced by a Prober pool in version 11.x.

46
 BIG-IP® TMOS®: Implementations

Link Controller system preparation

The BIG-IP® Link Controller™ (LC™) system does not require specific preparation when upgrading from
version 10.x to version 11.x. No additional configuration is required after completing the upgrade to version
11.x.

Local Traffic Manager system preparation

The BIG-IP® Local Traffic Manager™ (LTM®) system does not require specific preparation when upgrading
from version 10.x to version 11.x. No additional configuration is required after completing the upgrade to
version 11.x.

Note: If you configured MAC Masquerade addresses for VLANs on the version 10.x devices, one
of the addresses will be included automatically in the MAC Masquerade Address field for
traffic-group-1 during the upgrade.

Protocol Security Module preparation

The BIG-IP® Protocol Security Module™ (PSM)™does not require specific preparation when upgrading
from version 10.x to version 11.x. No additional configuration is required after completing the upgrade to
version 11.x.

WebAccelerator system preparation and configuration

BIG-IP® WebAccelerator™ systems require specific preparation tasks and changes to upgrade from version
10.x to version 11.x.

Preparation activities
Before you upgrade the WebAccelerator™ systems from version 10.x to version 11.x, you need to prepare
the systems, based on your configuration. The following table summarizes the applicable tasks that you
need to complete.

Feature or Functionality Preparation Task

Symmetric deployment You must reconfigure symmetric WebAccelerator
systems as asymmetric systems before you upgrade
them from version 10.x to version 11.x.

Important: Version 11.x does not support

symmetric WebAccelerator systems.

Unpublished policies You must publish any policies that you want to
migrate to version 11.x. Only published policies are
migrated into version 11.x.
Signed policies Signed policies are not supported in version 11.x. If
you use signed policies, you must replace them with
predefined or user-defined policies before upgrading.
Configuration files Upgrading from version 10.x to version 11.x does
not include custom changes to configuration files.
After upgrading to version 11.x, you need to
manually restore any customizations made to your

47
Upgrading Active-Standby Systems

Feature or Functionality Preparation Task

configuration files by using the Configuration utility
or Traffic Management Shell (tmsh). The following
list includes examples of configuration files that
might have been customized:
• /config/wa/[Link].10.x.0;
in version 11.x, all objtype entries are provided
in tmsh.
• /config/wa/[Link].10.x.0
• /config/wa/[Link].10.x.0
• /config/wa/transforms/[Link].10.x.0;
version 11.x does not include transforms.

Debug Options X-PV-Info response headers in version 10.x are

changed to X-WA-Info response headers in version
11.x. The default setting for X-WA-Info Headers
is None (disabled). To use X-WA-Info response
headers, you will need to change this setting, and
update any associated iRules® or scripts, accordingly.

Post-upgrade activities
When you complete upgrading to version 11.x, you should consider the following feature or functionality
changes that occur for the WebAccelerator systems. Depending upon your configuration, you might need
to perform these changes after you upgrade the systems.

Feature or Functionality Description

Web acceleration Web acceleration functionality requires configuration
of the Web Acceleration profile.

Important: You must enable a

WebAccelerator application in the Web
Acceleration profile to enable the
WebAccelerator system.

Compression Compression functionality requires configuration of

the HTTP Compression profile in version 11.x.
Request logging Request logging does not migrate to version 11.x.
You must recreate the configuration after upgrading
by using the Request Logging profile.
Policy logging Policy logging does not migrate to version 11.x. You
must recreate the configuration after upgrading by
using the Request Logging profile.
URL normalization URL normalization is not supported in version 11.x.
®
iControl backward compatibility Backward compatibility for iControl Compression
and RAM Cache API settings in the HTTP profile
is not supported in version 11.x. These settings
appear in the HTTP Compression and Web
Acceleration profiles in version 11.x.

48
 BIG-IP® TMOS®: Implementations

WAN Optimization Manager preparation

BIG-IP® WAN Optimization Manager™ (WOM®) systems do not require specific preparation when upgrading
from version 10.x to version 11.x. However, in a redundant system configuration, you must upgrade the
standby system first (to avoid interrupting traffic on the active system), and then upgrade the other system.
No additional configuration is required after completing the upgrade to version 11.x.

Preparing BIG-IP active-standby systems for an upgrade

The following prerequisites apply when you upgradeBIG-IP® active and standby devices from version 10.x
to 11.x.
• The BIG-IP systems (Device A and Device B) are configured as an active-standby pair.
• Each BIG-IP device is running the same version of 10.x software.
• The BIG-IP active-standby devices are the same model of hardware.
When you upgrade a BIG-IP active-standby pair from version 10.x to 11.x, you begin by preparing the
devices.

Note: If you prefer to closely observe the upgrade of each device, you can optionally connect to
the serial console port of the device that you are upgrading.

1. For each device, complete the following steps to prepare the configuration and settings.
a) Examine the Release Notes for specific configuration requirements, and reconfigure the systems, as
necessary.
For example, you must reconfigure version 10.x symmetric WebAccelerator modules as asymmetric
systems before upgrading to version 11.x.
b) Examine the Release Notes for specific changes to settings that occur when upgrading from version
10.x to 11.x, and complete any in-process settings.
For example, you must publish any unpublished BIG-IP® WebAccelerator™ module policies in order
for them to migrate to version 11.x.

2. From the device that is running the latest configuration, synchronize the configuration to the peer unit.
a) On the Main menu, click System > High Availability > ConfigSync.
A message appears for the Status Message.
b) Click Synchronize TO Peer.
3. For each device, reactivate the license.
a) On the Main menu, click System > License.
b) Click Re-activate.
c) In the Activation Method area, select the Automatic (requires outbound connectivity) option.
d) Click Next.
The BIG-IP software license renews automatically.

4. For each device, click System > High Availability > Redundancy, and, from the Redundancy State
Preference list, select None.
5. For each device, create a backup file.
a) Access the tmsh command line utility.
b) At the prompt, type save /sys ucs /shared/[Link].
c) Copy the backup file to a safe location on your network.

49
Upgrading Active-Standby Systems

6. Download the BIG-IP version 11.x .iso file from the AskF5 downloads web site
([Link] to a preferred location.
7. Using a tool or utility that computes an md5 checksum, verify the integrity of the BIG-IP version 11.x
.iso file.
8. Import the version 11.x software image file to each device.
a) On the Main menu, click System > Software Management > Image List > Import.
b) Click Choose File, locate and click the image file, click Open, and click Import.
c) When the software image file completes uploading to the BIG-IP device, click OK.
A link to the image file, but not to the .md5 file, appears in the Software Image list.

The BIG-IP devices are prepared to install the version 11.x software onto Device B (the standby BIG-IP 2
device).

Upgrading the standby BIG-IP 2 system

The following prerequisites apply for this task.
• Device A (the active BIG-IP® 1 system) and Device B (the standby BIG-IP 2 system) must be prepared
to upgrade Device B with version 11.x software.
• The version 11.x software image and MD5 files are downloaded and available.
After you prepare Device A (the active BIG-IP 1 system) and Device B (the standby BIG-IP 2 system) for
upgrading the software, you can perform these steps to install the version 11.x software onto Device B.

1. On the Main menu, click System > Software Management > Image List.
2. In the Available Images area, select the check box for the version 11.x software image.
3. Select a location to install the image, and click Install.

Important: In the Install Status list for the specified location, a progress bar indicates the
status of the installation. Ensure that installation successfully completes, as indicated by the
progress bar, before proceeding.

4. Reboot the device to the location of the installed version 11.x software image.
a) On the Main menu, click System > Software Management > Boot Locations.
b) In the Boot Location list, click the boot location of the installed version 11.x software image.
c) Click Activate.
The BIG-IP device reboots to the version 11.x boot location with traffic-group-1 in standby state.

Note: If the device appears to be taking a long time to reboot, do not cycle the power off
and on. Instead, verify the status of the device by connecting to its serial console port. The
device might be performing firmware upgrades.

Version 11.x software is installed on Device B, with traffic-group-1 in standby state.

Upgrading the active BIG-IP 1 system

The following prerequisites apply in upgrading Device A (the BIG-IP® 1 system).
• Device A (the version 10.x BIG-IP 1 system) must be prepared to upgrade the software to version 11.x.
• Device A is in active mode.

50
 BIG-IP® TMOS®: Implementations

• Device B (the version 11.x BIG-IP device with traffic-group-1) is in standby state.
After you prepare Device A (the standby BIG-IP 1 system) for upgrading the software, you can perform
these steps to upgrade the software to version 11.x.

1. On the Main menu, click System > Software Management > Image List.
2. In the Available Images area, select the check box for the version 11.x software image.
3. Select a location to install the image, and click Install.

Important: In the Install Status list for the specified location, a progress bar indicates the
status of the installation. Ensure that installation successfully completes, as indicated by the
progress bar, before proceding.

4. Force the BIG-IP device (Device A) to standby mode.

a) On the Main menu, click System > High Availability > Redundancy
b) Click Force to Standby
The BIG-IP device (Device A) changes to standby mode and the peer BIG-IP device (Device B)
changes to active state.

Important: Once the peer BIG-IP device (Device B) changes to active state, ensure that it
passes traffic normally.

5. Reboot the BIG-IP device (Device A) to the location of the installed version 11.x software image.
a) On the Main menu, click System > Software Management > Boot Locations.
b) In the Boot Location list, click the boot location of the installed version 11.x software image.
c) Click Activate.
The BIG-IP device (Device A) reboots to the version 11.x boot location with traffic-group-1 in
standby state.

Note: If the device appears to be taking a long time to reboot, do not cycle the power off
and on. Instead, verify the status of the device by connecting to its serial console port. The
device might be performing firmware upgrades.

6. Synchronize the configuration.

a) On the Main tab, click Device Management > Device Groups
b) Click the name of a device group.
c) On the menu bar, click Config Sync.
The Config Sync screen appears, displaying the status for each member.
d) As indicated by the Status Message, click one of the following buttons.
• Synchronize TO Group
• Synchronize FROM Group

Version 11.x software is installed on Device A (the BIG-IP system with traffic-group-1 in standby state).

51
Upgrading Active-Standby Systems

Verifying a BIG-IP active-standby upgrade

When you have completed upgrading the BIG-IP active-standby pair from version 10.x to version 11.x,
you should verify that the upgraded configuration is working properly. Perform the following steps to verify
the version 11.x upgrade.

1. Verify the Platform configuration for each device.

a) On the Main menu, click System > Platform.
b) From the Root Folder Device Group setting, verify that the device group is identical on the pair of
devices.
c) From the Root Folder Traffic Group list, verify that the correct traffic group (traffic-group-1) is
selected.
2. Verify the configuration for each device.
a) On the Main menu, click Device Management > Devices.
b) Verify the information for the device and the peer device.
c) On the Main menu, click Device Management > Device Trust.
d) In the Peer Authority Devices area, verify that the peer device is specified.

Note: Ensure that all information for the peer device appears correctly and complete.

3. Verify the traffic groups for each device.

a) On the Main menu, click Network > Traffic Groups.
b) Click traffic-group-1.
c) If you configured MAC Masquerade addresses for VLANs on the version 10.x devices, verify that
the traffic-group-1 includes an address in the MAC Masquerade Address field.
d) Verify that the floating traffic group is correct.
e) Verify that the failover objects are correct.
4. Verify the Current ConfigSync State for each device.
a) On the Main menu, click Device Management > Devices.
b) In the Device List, in the Status column, verify that each device shows a sync status of green.

Implementation result
Your upgrade of the BIG-IP® active-standby pair from version 10.x to version 11.x is now complete. The
version 11.x configuration includes a device group with two devices (Device A and Device B) and a traffic
group (traffic-group-1), with the traffic group on one device (Device B) in active state and the traffic
group on the other device (Device A) in standby state.

52
 BIG-IP® TMOS®: Implementations

Figure 5: A version 11.x device group and traffic group

53
Upgrading Active-Standby Systems

54
Chapter
5
Configuring a Sync-Failover Device Group
Topics:

• Overview: Configuring a Sync-Failover

device group
• Task summary
• Implementation result
Configuring a Sync-Failover Device Group

Overview: Configuring a Sync-Failover device group

A Sync-Failover device group with two members and two traffic groups provides configuration
synchronization and device failover. It can also provide connection mirroring between the two devices.
Application traffic in a Sync-Failover device group is processed by IP addresses that are configured to float
from one device to the other. The floating IP addresses are assigned to a traffic group that resides on each
device in the group. The traffic group is active on only one device at a time.
If the active device goes offline, the traffic group becomes active on a Sync-Failover peer in the group and
application processing is handled by that device. The process of taking over these functions is known as
failover.

Figure 6: Failover device groups

Task summary
Each BIG-IP device in a device group has a default traffic group (traffic group 1). Floating IP addresses
are assigned to traffic group 1 and that traffic group processes application traffic.

56
 BIG-IP® TMOS®: Implementations

To process traffic for additional applications with Sync-Failover capability, create a second device group
and a second traffic group.
Use the tasks in this implementation to create a new device group to which you can assign a second traffic
group. In this active-active configuration, each device in the group has one active traffic group.

Task list
Before you begin
Specifying an IP address for config sync
Specifying IP addresses for connection mirroring
Establishing device trust
Creating a Sync-Failover device group
Syncing the BIG-IP configuration to the device group
Specifying IP addresses for failover
Creating a second traffic group for the device group
Assigning traffic-group-2 to a floating virtual IP address
Assigning traffic-group-2 to a floating self IP address
Syncing the BIG-IP configuration to the device group
Forcing a traffic group to a standby state

Before you begin

Verify that the following configuration objects are defined on each device in the device group.
Three VLANs
One VLAN is internal, one is external, and one is HA. Each VLAN is assigned to an interface.
Three non-floating self IP addresses
One non-floating self IP is associated with the internal VLAN, one is associated with the external VLAN,
and one is associated with the HA VLAN.

Important: Self IPs that you create for this device group must support Port Lockdown. You
can specify All, Custom, or Default, but not None.

Two floating self IP addresses

One floating self IP is associated with the internal VLAN and the other is associated with the external
VLAN.
A virtual server
The virtual server IP addresses are used to process application traffic. Because the virtual IP addresses
are configured to float between devices in the device group, traffic can failover when necessary.

Specifying an IP address for config sync

Before configuring the config sync address, verify that all devices in the device group are running the same
version of BIG-IP® system software.
This task identifies the IP address that devices in the device group will use to synchronize their configuration
objects. Use the BIG-IP Configuration utility to set up config sync.

Important: You must perform this task on each device in the device group.

57
Configuring a Sync-Failover Device Group

1. Confirm that you are logged in to the actual device you want to configure.
2. On the Main tab, click Device Management > Devices.
This displays a list of device objects discovered by the local device.
3. In the Name column, click the name of the device to which you are currently logged in.
4. From the Device Connectivity menu, choose ConfigSync.
5. For the Local Address setting, retain the displayed IP address or select another address from the list.
F5 Networks recommends that you use the default value, which is the self IP address for VLAN
internal. This address must be a non-floating self IP address and not a management IP address.

6. Click Update.

Specifying IP addresses for connection mirroring

Before configuring mirroring addresses, verify that the mirroring peers have the same hardware platform.
This task configures connection mirroring between two devices to ensure that in-process connections are
not dropped when failover occurs. You can mirror connections between a maximum of two devices in a
device group.

Important: You must perform this task on each device in the device group.

1. Confirm that you are logged in to the actual device you want to configure.
2. On the Main tab, click Device Management > Devices.
This displays a list of device objects discovered by the local device.
3. In the Name column, click the name of the device to which you are currently logged in.
4. From the Device Connectivity menu, choose Mirroring.
5. For the Primary Local Mirror Address setting, retain the displayed IP address or select another address
from the list.
The recommended IP address is the self IP address for either VLAN HA or VLAN internal.
6. For the Secondary Local Mirror Address setting, retain the default value of None, or select an address
from the list.
This setting is optional. The system uses the selected IP address in the event that the primary mirroring
address becomes unavailable.
7. Click Update.

Establishing device trust

Verify that each BIG-IP® device that is to be part of a local trust domain has a device certificate installed
on it.
This task establishes a local trust domain between the local device (that is, the device you are logged in to)
and devices you specify during the process.A local trust domain is any number of BIG-IP devices that have
a trust relationship with one another. Perform this task on any one of the BIG-IP devices that will be in the
same device group.

1. On the Main tab, click Device Management/Device Trust, and then either Peer List or Subordinate
List.
2. In the Peer Authority Devices or the Subordinate Non-Authority Devices area of the screen, click Add.

58
 BIG-IP® TMOS®: Implementations

3. Type an IP address, administrator user name, and administrator password for the remote BIG-IP® device.
This IP address can be either a management IP address or a self IP address.
4. Click Retrieve Device Information.
5. Verify that the certificate of the remote device is correct.
6. Verify that the name of the remote device is correct.
7. Verify that the management IP address and name of the remote device are correct.
8. Click Finished.

Creating a Sync-Failover device group

This task establishes failover capability between two BIG-IP® devices. If the active device in a Sync-Failover
device group becomes unavailable, the configuration objects fail over to another member of the device
group and traffic processing is unaffected. You can perform this task on any authority device within the
local trust domain.

1. On the Main tab, click Device Management > Device Groups.

The Device Groups screen displays a list of existing device groups.
2. On the Device Group List screen, click Create.
3. Type a name for the device group, select the device group type Sync-Failover, and type a description
for the device group.
4. In the Configuration area of the screen, select a host name from the Available list for each BIG-IP device
that you want to include in the device group. Use the Move button to move the host name to theSelected
list.
The Available list shows any devices that are members of the device's local trust domain but not currently
members of a Sync-Failover device group. A device can be a member of one Sync-Failover group only.
5. For Network Failover, select the Enabled check box.
6. Click Finished.

You now have a Sync-Failover device group containing two BIG-IP devices as members.

Syncing the BIG-IP configuration to the device group

Before starting this task, verify that all devices targeted for ConfigSync are members of a device group and
that device trust has been established.
This task synchronizes the BIG-IP® configuration data from the local device to all devices in the group.
This synchronization ensures that the entire redundant system configuration operates properly within the
device group. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP
addresses only.

Important: Perform the following procedure on only one of the two devices.

1. On the Main tab, click Device Management > Device Groups.

The Device Groups screen displays a list of existing device groups.
2. In the Group Name column, click the name of the relevant device group.
3. On the menu bar, click ConfigSync.
4. Click Synchronize To Group.

59
Configuring a Sync-Failover Device Group

Except for non-floating self IP addresses, the entire set of BIG-IP configuration data is replicated on each
device in the device group.

Specifying IP addresses for failover

This task specifies the local IP addresses that you want other devices in the device group to use for failover
communications with the local device. You must perform this task on each device in the device group.

Note: The failover addresses that you specify must belong to route domain 0.

1. Confirm that you are logged in to the actual device you want to configure.
2. On the Main tab, click Device Management > Devices.
This displays a list of device objects discovered by the local device.
3. In the Name column, click the name of the device to which you are currently logged in.
4. From the Device Connectivity menu, choose Failover.
5. For the Failover Unicast Configuration settings, retain the displayed IP addresses.
You can also click Add to specify additional IP addresses that the system can use for failover
communications. F5 Networks recommends that you use the self IP address assigned to the HA VLAN.
6. If the BIG-IP® system is running on aVIPRION® platform, then for the Use Failover Multicast Address
setting, select the Enabled check box.
7. If you enable Use Failover Multicast Address, either accept the default Address and Port values, or
specify values appropriate for the device.
If you revise the default Address and Port values, but then decide to revert back to the default values,
click Reset Defaults.
8. Click Update.

After you perform this task, other devices in the device group can send failover messages to the local device
using the specified IP addresses.

Creating a second traffic group for the device group

This task creates a second active floating traffic group to process application traffic. The default floating
traffic group (traffic-group-1) processes application traffic for the local device.

Note: For this implementation, name this traffic group traffic-group-2.

1. On the Main tab, click Network > Traffic Groups.

2. On the Traffic Group List screen, click Create.
3. Type the name traffic-group-2 for the new traffic group.
4. Select the remote device as the default device for the new traffic group, and optionally specify a MAC
masquerade address.
5. Select or clear the check box for the Auto Failback option.
• Select causes the traffic group to be active on its default device whenever that device is as available,
or more available, than another device in the group.
• Clear causes the traffic group to remain active on its current device until failover occurs again.

6. Confirm that the displayed traffic group settings are correct.

60
 BIG-IP® TMOS®: Implementations

7. Click Finished.

You now have a second floating traffic group on the local device (in addition to the default floating traffic
group) so that once the traffic group is activated on the remote devices, devices in the device group can
process traffic for different applications.

Assigning traffic-group-2 to a floating virtual IP address

This task assigns your new traffic group to the device group's internal virtual IP address.

1. On the Main tab, click Local Traffic > Virtual Servers > Virtual Address List.
The Virtual Address List screen opens.
2. In the Name column, click the virtual address that you want to assign to the traffic group.
This displays the properties of that virtual address.
3. From the Traffic Group list, select traffic-group-2 (floating).
4. Click Update.

The device's floating virtual IP address is now a member of your second traffic group. The virtual IP address
can now fail over to other devices in the traffic group.

Assigning traffic-group-2 to a floating self IP address

This task assigns your floating self IP address to traffic-group-2.

1. On the Main tab, click Network > Self IPs.

The Self IPs screen opens.
2. In the Name column, click the floating self IP address assigned to VLAN internal.
This displays the properties of that self IP address.
3. From the Traffic Group list, select traffic-group-2 (floating).
4. Click Update.

The device's floating self IP address is now a member of your second traffic group. The self IP address can
now fail over to other devices in the traffic group.

Syncing the BIG-IP configuration to the device group

Before starting this task, verify that all devices targeted for ConfigSync are members of a device group and
that device trust has been established.
This task synchronizes the BIG-IP® configuration data from the local device to all devices in the group.
This synchronization ensures that the entire redundant system configuration operates properly within the
device group. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP
addresses only.

Important: Perform the following procedure on only one of the two devices.

1. On the Main tab, click Device Management > Device Groups.

The Device Groups screen displays a list of existing device groups.
2. In the Group Name column, click the name of the relevant device group.
3. On the menu bar, click ConfigSync.
4. Click Synchronize To Group.

61
Configuring a Sync-Failover Device Group

Except for non-floating self IP addresses, the entire set of BIG-IP configuration data is replicated on each
device in the device group.

Forcing a traffic group to a standby state

This task causes the selected traffic group on the local device to switch to a standby state. By forcing the
traffic group into a standby state, the traffic group becomes active on another device in the device group.
For device groups with more than two members, you can choose the specific device to which the traffic
group fails over. This task is optional.

1. Log in to the device on which the traffic group is currently active.

2. On the Main tab, click Network > Traffic Groups.
3. In the Name column, locate the name of the traffic group that you want to run on the peer device.
4. Select the check box to the left of the traffic group name.
If the check box is unavailable, the traffic group is not active on the device to which you are currently
logged in. Perform this task on the device on which the traffic group is active.
5. Click Force to Standby.
This displays target device options.
6. Choose one of these actions:
• If the device group has two members only, click Force to Standby. This displays the list of traffic
groups for the device group and causes the local device to appear in the Next Active Device column.
• If the device group has more than two members, then from the Target Device list, select a value
and click Force to Standby.

The selected traffic group is now active on another device in the device group.

Implementation result
You now have a Sync-Failover device group set up with an active-active configuration. In this configuration,
each traffic group is initially configured to be active on one device. If one device goes offline, the traffic
group that was active on that device becomes active on the other device in the group. Application processing
for both traffic groups continues without interruption.

62
Chapter
6
Configuring DNS Express
Topics:

• How do I configure DNS Express?

• Task summary
• Implementation result
Configuring DNS Express

How do I configure DNS Express?

You can configure DNS Express™ on BIG-IP® systems to mitigate distributed denial-of-service attacks
(DDoS) and increase the volume of DNS request resolutions on both the local BIND server on the BIG-IP
system and any back-end DNS servers.

What is DNS Express?

DNS Express™ provides the ability for a BIG-IP® system to act as a high-speed, authoritative secondary
DNS server. This makes if possible for the system to:
• Perform zone transfers from multiple primary DNS servers that are responsible for different zones.
• Perform a zone transfer from the local BIND server on the BIG-IP system.
• Serve DNS records faster than the primary DNS servers.

Task summary
Perform these tasks to configure DNS Express™ on your BIG-IP® system.
Configuring a back-end DNS server to allow zone file transfers
Creating a DNS Express TSIG key
Creating a DNS Express zone
Enabling DNS Express
Viewing information about DNS Express zones

Configuring a back-end DNS server to allow zone file transfers

If you are unfamiliar with how to modify DNS server files, review the fifth edition of DNS and BIND,
available from O’Reilly Media.
To configure a back-end DNS server to allow zone file transfers to the BIG-IP® system, add to the DNS
server an allow-transfer statement that specifies a self IP address on the BIG-IP system.

You can modify the following allow-transfer statement to use a self IP address on the
BIG-IP system:
allow-transfer { localhost; <self IP address of BIG-IP
system>; };

Creating a DNS Express TSIG key

Ensure that your back-end DNS servers are configured for zone file transfers using TSIG keys.
When you want to verify the identity of the authoritative server that is sending information about the zone,
create a DNS Express™ TSIG key.

64
 BIG-IP® TMOS®: Implementations

Note: This step is optional.

1. On the Main tab, click Local Traffic > DNS Express Zones > DNS Express TSIG Key List.
The DNS Express TSIG Key List screen opens.
2. Click Create.
The New DNS Express TSIG Key screen opens.
3. In the Name field, type a name for the key.
4. From the Algorithm list, select one of the following.
The system uses the algorithm that you select to authenticate updates from an approved client and
responses from an approved recursive nameserver. The algorithm is a hash function in combination with
the secret key.
Algorithm Name Description
HMAC MD5 Produces a 128-bit hash sequence
HMAC SHA-1 Produces a 160-bit hash sequence
HMAC SHA-256 Produces a 256-bit hash sequence

5. In the Secret field, type the phrase required for authentication of the key.

Note: The secret key is created by a third party tool such as BIND’s keygen utility.

6. Click Finished.

Creating a DNS Express zone

If you are using back-end DNS servers, ensure that those servers are configured for zone transfers.
To implement DNS Express™ on a BIG-IP® system, create a DNS Express zone.

1. On the Main tab, click Local Traffic > DNS Express Zones > DNS Express Zone List.
The DNS Express Zone List screen opens.
2. Click Create.
The New DNS Express Zone screen opens.
3. In the Name field, type a name for the DNS Express zone.
4. In the Target IP Address field, type the IP address of the current master DNS server for the zone from
which you want to transfer records.
The default value [Link] is for the BIND server on the BIG-IP system.
5. To configure the system to verify the identity of the authoritative server that is sending information
about the zone, from the TSIG Key list, select a key.
6. To specify an action for the BIG-IP system to take when a NOTIFY query is received for a configured
DNS Express zone, from the Notify Action list, select one of the following.
Action Description
Consume The NOTIFY query is seen only by DNS Express. This is the default value.
Bypass Queries do not go to DNS Express, but instead go to any backend DNS
resource (subject to DNS profile unhandled-query-action).

65
Configuring DNS Express

Action Description
Repeat The NOTIFY query goes to both DNS Express and any backend DNS
resource.

Tip: If a TSIG Key is configured, the signature is only validated for Consume and Repeat
actions. NOTIFY responses are assumed to be sent by a backend DNS resource, except when
the action is Consume and DNS Express generates a response.

7. Click Finished.

Enabling DNS Express

Create a custom DNS profile and assign to a listener or virtual server to enable DNS Express™, only if you
want to use a back-end DNS server for name resolution while the BIG-IP system handles queries for wide
IPs and DNS Express zones.

Note: If you plan to use the BIND server on BIG-IP GTM™, you can use the default dns profile.

1. On the Main tab, click Local Traffic > Profiles > Services > DNS.
The DNS profile list screen opens.
2. Click Create.
The New DNS Profile screen opens.
3. Name the profile dns_express.
4. In the Parent Profile list, accept the default dns profile.
5. Select the Custom check box.
The fields in the Settings area become available for revision.
6. In the Global Traffic Management list, accept the default value Enabled.
7. From the DNS Express list, select Enabled.
8. From the Unhandled Query Actions list, select how you want the BIG-IP system to handle a query
that is not for a wide IP or DNS Express zone.
Option Description
Allow The BIG-IP system forwards the connection request to another DNS server or
DNS server pool. Note that if a DNS server pool is not associated with a listener
and the Use BIND Server on BIG-IP option is set to enabled, connection
requests are forwarded to the local BIND server. (Allow is the default value.)
Drop The BIG-IP system does not respond to the query.
Reject The BIG-IP system returns the query with the REFUSED return code.
Hint The BIG-IP system returns the query with a list of root name servers.
No Error The BIG-IP system returns the query with the NOERROR return code.

9. From the Use BIND Server on BIG-IP list, select Disabled.

10. Click Finished.

Assign the profile to virtual servers or listeners.

66
 BIG-IP® TMOS®: Implementations

Viewing information about DNS Express zones

You can view information about the zones that are protected by DNS Express™.

1. On the Main tab, click Statistics > Module Statistics > Local Traffic.
The Local Traffic Statistics screen opens.
2. From the Statistics Type list, select DNS Express Zones.
Information displays about the DNS Express zones.

Record type Description

SOA Records Displays start of authority record information.
Resource Records Displays the number of resource records for the
zone.

Task summary
Enabling DNS Express
Task summary

Implementation result
You now have an implementation in which the BIG-IP® system helps to mitigate DDoS attacks on your
network and to resolve more DNS queries faster.

67
Configuring DNS Express

68
Chapter
7
Load Balancing DNS Traffic Between IPv-6 Only and IPv-4
Only Clouds
Topics:

• Overview: Handling IPv6-only connection

requests to IPv4-only servers
• Task summary
• Implementation result
Load Balancing DNS Traffic Between IPv-6 Only and IPv-4 Only Clouds

Overview: Handling IPv6-only connection requests to IPv4-only servers

You can configure BIG-IP® Local Traffic Manager™ (LTM) and BIG-IP® Global Traffic Manager™ (GTM)
systems to handle IPv6-only client connection requests to IPv4-only servers on your network by returning
an AAAA record response to the client.

Figure 7: Mapping IPv6 addresses to IPv4 addresses

Task summary
Perform these tasks to configure BIG-IP systems to handle DNS queries from IPv6-only clients to IPv4-only
servers on your network.
Creating a custom DNS profile
Assigning a DNS profile to a virtual server

Creating a custom DNS profile

You can create a custom DNS profile to configure how the BIG-IP® system handles DNS connection
requests.

1. On the Main tab, click Local Traffic > Profiles > Services > DNS.
The DNS profile list screen opens.
2. Click Create.
The New DNS Profile screen opens.

70
 BIG-IP® TMOS®: Implementations

3. In the Name field, type a name for the profile.

4. In the Parent Profile list, accept the default dns profile.
5. Select the Custom check box.
The fields in the Settings area become available for revision.
6. In the Global Traffic Management list, accept the default value Enabled.
7. From the DNS IPv6 to IPv4 list, select how you want the system to handle IPv6 to IPv4 address mapping
in DNS queries and responses.
Option Description
Disabled The BIG-IP system does not map IPv4 addresses to IPv6 addresses.
Immediate The BIG-IP system receives an AAAA query and forwards the query to a DNS server. The
BIG-IP system then forwards the first good response from the DNS server to the client. If
the system receives an A response first, it appends a 96-bit prefix to the record and forwards
it to the client. If the system receives an AAAA response first, it simply forwards the
response to the client. The system disregards the second response from the DNS server.
Secondary The BIG-IP system receives an AAAA query and forwards the query to a DNS server.
Only if the server fails to return a response does the BIG-IP system send anA query. If the
BIG-IP system receives an A response, it appends a 96-bit user-configured prefix to the
record and forwards it to the client.
v4 Only The BIG-IP system receives an AAAA query, but forwards an A query to a DNS server.
After receiving an A response from the server, the BIG-IP system appends a 96-bit
user-configured prefix to the record and forwards it to the client.

Important: Select this option only if you know that all your DNS servers are IPv4
only servers.

If you selected Immediate, Secondary, or V4 Only two new fields display.

8. In the IPv6 to IPv4 Prefix field, specify the prefix the BIG-IP system appends to all A query responses
to an IPv6 request.
9. From the IPv6 to IPv4 Additional Section Rewrite list, select an option to allow improved network
efficiency for both Unicast and Multicast DNS-SD responses.
Option Description
Disabled The BIG-IP system does not perform additional rewrite.
v4 Only The BIG-IP system accepts only A records. The system appends the 96-bit
user-configured prefix to a record and returns an IPv6 response to the client.
v6 Only The BIG-IP system accepts only AAAA records and returns an IPv6 response to
the client.
Any The BIG-IP system accepts and returns both A and AAAA records. If the DNS
server returns an A record in the Additional section of a DNS message, the BIG-IP
system appends the 96-bit user-configured prefix to the record and returns an
IPv6 response to the client.

10. From the Use BIND Server on BIG-IP list, select Enabled.

Note: Enable this setting only when you want the system to forward non-wide IP queries to the
local BIND server on BIG-IP GTM.

71
Load Balancing DNS Traffic Between IPv-6 Only and IPv-4 Only Clouds

11. Click Finished.

Assigning a DNS profile to a virtual server

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the name of the virtual server you want to modify.
3. From the DNS Profile list, select the profile you created to manage IPv6 to IPv4 address mapping.
4. Click Update.

This virtual server can now pass traffic between an IPv6-only client and an IPv4-only DNS server.

Implementation result
You now have an implementation in which the BIG-IP® system handles connection requests from an
IPv6-only client to an IPv4-only server.

72
Chapter
8
Implementing the Link Layer Discovery Protocol
Topics:

• Overview: Implementing Link Layer

Discovery Protocol
• Task summary
• Implementation result
Implementing the Link Layer Discovery Protocol

Overview: Implementing 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 Packet 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 use this particular implementation to configure
BIG-IP system interfaces to transmit LLDPDUs to neighbor devices. 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 interfaces can receive messages. These properties apply to all interfaces on the
BIG-IP system.
The following illustration shows a BIG-IP system that transmits LLDP messages to three neighbor devices:
another BIG-IP system, an external switch, and an external router. Note that LLDP is enabled on all of the
devices.

Figure 8: The BIG-IP system and LLDP transmittal

74
 BIG-IP® TMOS®: Implementations

Task summary
Perform these tasks to implement Link Layer Discovery Protocol (LLDP) on selected BIG-IP system
interfaces.

Task list
Configuring global LLDP properties
Configuring LLDP settings for an individual interface

Configuring global LLDP properties

You can configure a set of general LLDP properties that apply to all interfaces on the BIG-IP system. These
settings pertain to LLDP message transmission frequencies and the maximum number of neighbors to which
each interface can send LLDP messages.

Note: Although you use this procedure to globally enable the LLDP feature on the BIG-IP system,
you can also disable LLDP for any individual interface. You do this by configuring the specific
properties of that interface.

1. On the Main tab, click Network > Interfaces > LLDP > General.
This displays the general LLDP properties that you can configure on the system.
2. From the LLDP list, select Enabled.
3. For the remainder of the settings, retain or change the default values.
4. Click Update.

This enables support for the LLDP protocol on the BIG-IP system, and configures the system to transmit
LLDPDUs according to the specified frequencies.

Configuring LLDP settings for an individual interface

You can use this procedure to configure the settings for an individual interface on the BIG-IP system.

1. On the Main tab, click Network > Interfaces > Interface List.
This displays the list of interfaces on the system.
2. In the Name column, click an interface number.
This displays the properties of the interface.
3. For the State setting, verify that the interface is set to Enabled.
4. For the LLDP setting, verify that the property is set to Transmit Only.
5. For the LLDP Attributes setting, verify that the list of attributes in the Send box includes all Time
Length Values (TLVs) that you want the BIG-IP system interface to send to neighbor devices.
6. Click Update.

This enables the selected interface and configures the interface to send the specified LLDP information to
neighbor devices.

75
Implementing the Link Layer Discovery Protocol

Implementation result
This implementation results in this LLDP configuration:
• Support for the LLDP protocol is enabled on the BIG-IP system.
• For all BIG-IP system interfaces, the BIG-IP system attempts to transmit LLDPDUs to neighbor de
vices
every 30 seconds, with a minimum delay between transmissions of 2 seconds.
• The maximum number of neighbors to which each BIG-IP system interface can send LLDPDUs is 10.
• Every BIG-IP system interface can send LLDPDUs to its neighbors.
• No BIG-IP system interface can receive LLDPDUs from its neighbors.
In addition, the content of the LLDPDUs that each BIG-IP system interface sends to its neighbors contains
this information:
• Chassis ID
• Port ID
• Time-to-Live value
• Port description
• System name
• System description
• System capabilities
• Port VLAN ID
• Port and protocol VLAN ID
• VLAN name
• Protocol identity
• MAC/PHY config status
• Link aggregation
• Max frame size
• Product model

76
Chapter
9
Configuring IPsec in Tunnel Mode between Two BIG-IP
Systems
Topics:

• Overview: Configuring IPsec between two

BIG-IP systems
• Task summary
• Implementation result
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

Overview: Configuring IPsec between two BIG-IP systems

You can configure an IPsec tunnel when you want to use a protocol other than SSL to secure traffic that
traverses a wide area network (WAN), from one BIG-IP ®system to another. By following this procedure,
you can configure an IKE peer to negotiate Phase 1 Internet Security Association and Key Management
Protocol (ISAKMP) security associations for the secure channel between two systems. You can also configure
a custom traffic selector and a custom IPsec policy that use this secure channel to generate IPsec Tunnel
mode (Phase 2) security associations (SAs).

Figure 9: Example of an IPsec deployment

About negotiation of security associations

The way to dynamically negotiate security associations is to configure the Internet Key Exchange (IKE)
protocol, which is included in the IPsec protocol suite. When you configure the IKE protocol, two IPsec
tunnel endpoints (IKE peers) open a secure channel using an ISAKMP security association (ISAKMP-SA)
to initially negotiate the exchange of peer-to-peer authentication data. This exchange is known as Phase 1
negotiation.
After Phase 1 is complete and the secure channel is established, Phase 2 negotiation begins, in which the
IKE peers dynamically negotiate the authentication and encryption algorithms to use to secure the payload.
Without IKE, the system cannot dynamically negotiate these security algorithms.

About IPsec Tunnel mode

Tunnel mode causes the IPsec protocol to encrypt the entire packet (the payload plus the IP header). This
encrypted packet is then included as the payload in another outer packet with a new header. Traffic sent in
this mode is more secure than traffic sent in Transport mode, because the original IP header is encrypted
along with the original payload.

78
 BIG-IP® TMOS®: Implementations

About BIG-IP components of the IPsec protocol suite

The IPsec protocol suite on the BIG-IP® system consists of these configuration components:
IKE peers
An IKE peer is a configuration object of the IPsec protocol suite that represents a BIG-IP system on
each side of the IPsec tunnel. IKE peers allow two systems to authenticate each other (known as IKE
Phase 1). The BIG-IP system includes the default IKE peer, named anonymous.
IPsec policies
An IPsec policy is a set of information that defines the specific IPsec protocol to use (ESP or AH), and
the mode (Transport, Tunnel, or iSession). For Tunnel mode, the policy also specifies the endpoints for
the tunnel, and for IKE Phase 2 negotiation, the policy specifies the security parameters to be used in
that negotiation. The way that you configure the IPsec policy determines the way that the BIG-IP system
manipulates the IP headers in the packets. The BIG-IP system includes two default IPsec policies, named
default-ipsec-policy and default-ipsec-policy-isession. A common configuration
includes a bidirectional policy on each BIG-IP system.
Traffic selectors
A traffic selector is a packet filter that defines what traffic should be handled by a IPsec policy. You
define the traffic by source and destination IP addresses and port numbers. A common configuration
includes a bidirectional traffic selector on each BIG-IP system.

Task summary
You can configure the IPsec and IKE protocols to secure traffic that traverses a wide area network (WAN),
such as from one data center to another.
Before you begin configuring IPsec and IKE, verify that these modules, system objects, and connectivity
exist on the BIG-IP® systems in both the local and remote locations:
BIG-IP Local Traffic Manager™
This module directs traffic securely and efficiently to the appropriate destination on a network.
Self IP address
Each BIG-IP system must have at least one self IP address, to be used in specifying the ends of the IPsec
tunnel.
The default VLANs
These VLANs are named external and internal.
BIG-IP connectivity
Verify the connectivity between the client or server and its BIG-IP device, and between each BIG-IP
device and its gateway. For example, you can use ping to test this connectivity.

Task list
Creating a forwarding virtual server for IPsec
Creating an IKE peer
Creating a custom IPsec policy
Creating a bidirectional IPsec traffic selector
Verifying IPsec connectivity for Tunnel mode

79
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating an IKE peer

The IKE peer object identifies to the system you are configuring the other BIG-IP® system with which it
communicates during Phase 1 negotiations. The IKE peer object also specifies the specific algorithms and
credentials to be used for Phase 1 negotiation.

Important: You must perform this task on both BIG-IP systems.

1. On the Main tab, click Network > IPsec > IKE Peers.
2. Click the Create button.
The New IKE Peer screen opens.
3. In the Name field, type a unique name for the IKE peer.
4. In the Description field, type a brief description of the IKE peer.
5. In the Remote Address field, type the IP address of the BIG-IP system that is remote to the system you
are configuring.
This address must match the value of the Tunnel Remote Address setting in the relevant IPsec policy.
6. For the State setting, retain the default value, Enabled.
7. For the IKE Phase 1 Algorithms area, retain the default values, or select the options that are appropriate
for your deployment.
8. In the IKE Phase 1 Credentials area, for theAuthentication Method setting, select either RSA Signature
or Preshared Key.
• If you select RSA Signature (default), the Certificate, Key, and Verify Certificate settings are
available. If you have your own certificate file, key file, and certificate authority (CA), F5
recommends, for security purposes, that you specify these files in the appropriate fields. To reveal
all these fields, select the Verify Certificate check box. If you retain the default settings, leave the
check box cleared.

80
 BIG-IP® TMOS®: Implementations

Important: If you select the check box, you must provide a certificate file, key, and certificate
authority.

• If you select Preshared Key, type the key in the Preshared Key field that becomes available.

Note: The key you type must be the same at both ends of the tunnel.

9. For the Common Settings area, retain all default values.

10. Click Finished.
The page refreshes and displays the new IKE peer in the list.
11. Repeat this task on the BIG-IP system in the remote location.

You now have an IKE peer defined for establishing a secure channel.

Creating a custom IPsec policy

You create a custom IPsec policy when you want to use a policy other than the default IPsec policy
(default-ipsec-policy or default-ipsec-policy-isession). A typical reason for creating a
custom IPsec policy is to configure IPsec to operate in Tunnel rather than Transport mode.

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > IPsec Policies.
2. Click the Create button.
The New Policy screen opens.
3. In the Name field, type a unique name for the policy.
4. In the Description field, type a brief description of the policy.
5. For the IPsec Protocol setting, retain the default selection, ESP.
6. From the Mode list, select Tunnel.
The screen refreshes to show additional related settings.
7. In the Tunnel Local Address field, type the local IP address of the system you are configuring.
Sample tunnel local addresses for BIG-IP A and BIG-IP B are as follows.

System Name Tunnel Local Address

BIG-IP A [Link]

BIG-IP B [Link]

8. In the Tunnel Remote Address field, type the IP address that is remote to the system you are configuring.
This address must match the Remote Address setting for the relevant IKE peer.
Sample tunnel remote addresses for BIG-IP A and BIG-IP B are as follows.

System Name Tunnel Remote Address

BIG-IP A [Link]

BIG-IP B [Link]

81
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

9. For the Authentication Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.
10. For the Encryption Algorithm setting, retain the default value, or select the algorithm appropriate for
your deployment.
11. For the Perfect Forward Secrecy setting, retain the default value, or select the option appropriate for
your deployment.
12. For the Lifetime setting, retain the default value, 1440.
This is the length of time (in minutes) before the current security association expires.
13. Click Finished.
The screen refreshes and displays the new IPsec policy in the list.
14. Repeat this task on the BIG-IP system in the remote location.

Creating a bidirectional IPsec traffic selector

The traffic selector you create filters traffic based on the IP addresses and port numbers that you specify,
as well as the custom IPsec policy you assign.

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > Traffic Selectors.
2. Click Create.
The New Traffic Selector screen opens.
3. In the Name field, type a unique name for the traffic selector.
4. In the Description field, type a brief description of the traffic selector.
5. For the Order setting, retain the default value (First).
This setting specifies the order in which the traffic selector appears on the Traffic Selector List screen.
6. From the Configuration list, select Advanced.
7. For the Source IP Address setting, click Host or Network, and in the Address field, type an IP address.
This IP address should be the host or network address from which the application traffic originates.
Sample source IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Source IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

8. From the Source Port list, select the source port for which you want to filter traffic, or retain the default
value *All Ports.
9. For the Destination IP Address setting, click Host, and in the Address field, type an IP address.
This IP address should be the final host or network address to which the application traffic is destined.
Sample destination IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Destination IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

82
 BIG-IP® TMOS®: Implementations

10. From the Destination Port list, select the destination port for which you want to filter traffic, or retain
the default value * All Ports.
11. From the Protocol list, select the protocol for which you want to filter traffic.
You can select * All Protocols, TCP, UDP, ICMP, or Other. If you select Other, you must type a
protocol name.
12. From the Direction list, select Both.
13. From the Action list, select Protect.
The IPsec Policy Name setting appears.
14. From the IPsec Policy Name list, select the name of the custom IPsec policy that you created.
15. Click Finished.
The screen refreshes and displays the new IPsec traffic selector in the list.
16. Repeat this task on the BIG-IP system in the remote location.

Verifying IPsec connectivity for Tunnel mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic matching the traffic selector triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

2. Before sending traffic, type this command at the prompt.
tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the destination IP address specified in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp
This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

83
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

84
 BIG-IP® TMOS®: Implementations

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=tunnel spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=tunnel spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0

85
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 0 0 0 0
0 TRANSPORT 0 0 0 0
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 353.9K 252.4M 24.9K 1.8M
2 TUNNEL 117.9K 41.0M 163.3K 12.4M

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For protocol-level troubleshooting, you can increase the debug level by typing this command at the
prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.
tmsh modify ipsec ike-daemon ikedaemon log-level info

86
 BIG-IP® TMOS®: Implementations

Note: Using this command flushes existing SAs.

Implementation result
You now have an IPsec tunnel for securing traffic that traverses the WAN, from one BIG-IP® system to
another.

87
Configuring IPsec in Tunnel Mode between Two BIG-IP Systems

88
Chapter
10
Configuring IPsec in Transport Mode between Two BIG-IP
Systems
Topics:

• Overview: Configuring IPsec in Transport

mode between two BIG-IP systems
• Task summary
• Implementation result
Configuring IPsec in Transport Mode between Two BIG-IP Systems

Overview: Configuring IPsec in Transport mode between two BIG-IP systems

You can configure IPsec when you want to use a protocol other than SSL to secure traffic that traverses a
wide area network (WAN), from one BIG-IP® system to another. By following this procedure, you can
configure an IKE peer to negotiate Phase 1 Internet Security Association and Key Management Protocol
(ISAKMP) security associations for the secure channel between two systems. You can also configure a
custom traffic selector and a custom IPsec policy that use this secure channel to generate IPsec Transport
mode (Phase 2) security associations (SAs).

Figure 10: Example of an IPsec deployment

About negotiation of security associations

The way to dynamically negotiate security associations is to configure the Internet Key Exchange (IKE)
protocol, which is included in the IPsec protocol suite. When you configure the IKE protocol, two IPsec
tunnel endpoints (IKE peers) open a secure channel using an ISAKMP security association (ISAKMP-SA)
to initially negotiate the exchange of peer-to-peer authentication data. This exchange is known as Phase 1
negotiation.
After Phase 1 is complete and the secure channel is established, Phase 2 negotiation begins, in which the
IKE peers dynamically negotiate the authentication and encryption algorithms to use to secure the payload.
Without IKE, the system cannot dynamically negotiate these security algorithms.

About IPsec Transport mode

Transport mode causes the IPsec protocol to encrypt only the payload of an IP packet. The protocol then
encloses the encrypted payload in a normal IP packet. Traffic sent in Transport mode is less secure than
traffic sent in Tunnel mode, because the IP header in each packet is not encrypted.

90
 BIG-IP® TMOS®: Implementations

About BIG-IP components of the IPsec protocol suite

The IPsec protocol suite on the BIG-IP® system consists of these configuration components:
IKE peers
An IKE peer is a configuration object of the IPsec protocol suite that represents a BIG-IP system on
each side of the IPsec tunnel. IKE peers allow two systems to authenticate each other (known as IKE
Phase 1). The BIG-IP system includes the default IKE peer, named anonymous.
IPsec policies
An IPsec policy is a set of information that defines the specific IPsec protocol to use (ESP or AH), and
the mode (Transport, Tunnel, or iSession). For Tunnel mode, the policy also specifies the endpoints for
the tunnel, and for IKE Phase 2 negotiation, the policy specifies the security parameters to be used in
that negotiation. The way that you configure the IPsec policy determines the way that the BIG-IP system
manipulates the IP headers in the packets. The BIG-IP system includes two default IPsec policies, named
default-ipsec-policy and default-ipsec-policy-isession. A common configuration
includes a bidirectional policy on each BIG-IP system.
Traffic selectors
A traffic selector is a packet filter that defines what traffic should be handled by a IPsec policy. You
define the traffic by source and destination IP addresses and port numbers. A common configuration
includes a bidirectional traffic selector on each BIG-IP system.

Task summary
With this task, you can configure the IPsec and IKE protocols to secure traffic that traverses a wide area
network (WAN), such as from one data center to another.
Before you begin configuring IPsec and IKE, verify that these modules, system objects, and connectivity
exist on the BIG-IP® systems in both the local and remote locations:
BIG-IP Local Traffic Manager™
This module directs traffic securely and efficiently to the appropriate destination on a network.
Self IP address
Each BIG-IP system must have at least one self IP address, to be used in specifying the ends of the IPsec
tunnel.
The default VLANs
These VLANs are named external and internal.
BIG-IP connectivity
Verify the connectivity between the client or server and its BIG-IP device, and between each BIG-IP
device and its gateway. For example, you can use ping to test this connectivity.

Task list
Creating a forwarding virtual server for IPsec
Creating an IKE peer
Creating a bidirectional IPsec policy
Creating a bidirectional IPsec traffic selector
Verifying IPsec connectivity for Transport mode

91
Configuring IPsec in Transport Mode between Two BIG-IP Systems

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating an IKE peer

The IKE peer object identifies to the system you are configuring the other BIG-IP® system with which it
communicates during Phase 1 negotiations. The IKE peer object also specifies the specific algorithms and
credentials to be used for Phase 1 negotiation.

Important: You must perform this task on both BIG-IP systems.

1. On the Main tab, click Network > IPsec > IKE Peers.
2. Click the Create button.
The New IKE Peer screen opens.
3. In the Name field, type a unique name for the IKE peer.
4. In the Description field, type a brief description of the IKE peer.
5. In the Remote Address field, type the IP address of the BIG-IP system that is remote to the system you
are configuring.
This address must match the value of the Tunnel Remote Address setting in the relevant IPsec policy.
6. For the State setting, retain the default value, Enabled.
7. For the IKE Phase 1 Algorithms area, retain the default values, or select the options that are appropriate
for your deployment.
8. In the IKE Phase 1 Credentials area, for theAuthentication Method setting, select either RSA Signature
or Preshared Key.
• If you select RSA Signature (default), the Certificate, Key, and Verify Certificate settings are
available. If you have your own certificate file, key file, and certificate authority (CA), F5
recommends, for security purposes, that you specify these files in the appropriate fields. To reveal
all these fields, select the Verify Certificate check box. If you retain the default settings, leave the
check box cleared.

92
 BIG-IP® TMOS®: Implementations

Important: If you select the check box, you must provide a certificate file, key, and certificate
authority.

• If you select Preshared Key, type the key in the Preshared Key field that becomes available.

Note: The key you type must be the same at both ends of the tunnel.

9. For the Common Settings area, retain all default values.

10. Click Finished.
The page refreshes and displays the new IKE peer in the list.
11. Repeat this task on the BIG-IP system in the remote location.

You now have an IKE peer defined for establishing a secure channel.

Creating a bidirectional IPsec policy

You create a custom IPsec policy when you want to use a policy other than the default IPsec policy
(default-ipsec-policy or default-ipsec-policy-isession). A typical reason for creating a
custom IPsec policy is to configure IPsec to operate in Tunnel rather than Transport mode.

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > IPsec Policies.
2. Click the Create button.
The New Policy screen opens.
3. In the Name field, type a unique name for the policy.
4. In the Description field, type a brief description of the policy.
5. For the IPsec Protocol setting, retain the default selection, ESP.
6. From the Mode list, select Transport.
7. For the Authentication Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.
8. For the Encryption Algorithm setting, retain the default value, or select the algorithm appropriate for
your deployment.
9. For the Perfect Forward Secrecy setting, retain the default value, or select the option appropriate for
your deployment.
10. For the Lifetime setting, retain the default value, 1440.
This is the length of time (in minutes) before the current security association expires.
11. Click Finished.
The screen refreshes and displays the new IPsec policy in the list.
12. Repeat this task on the BIG-IP system in the remote location.

Creating a bidirectional IPsec traffic selector

The traffic selector you create filters traffic based on the IP addresses and port numbers that you specify,
as well as the custom IPsec policy you assign.

93
Configuring IPsec in Transport Mode between Two BIG-IP Systems

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > Traffic Selectors.
2. Click Create.
The New Traffic Selector screen opens.
3. In the Name field, type a unique name for the traffic selector.
4. In the Description field, type a brief description of the traffic selector.
5. For the Order setting, retain the default value (First).
This setting specifies the order in which the traffic selector appears on the Traffic Selector List screen.
6. From the Configuration list, select Advanced.
7. For the Source IP Address setting, click Host or Network, and in the Address field, type an IP address.
This IP address should be the host or network address from which the application traffic originates.
Sample source IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Source IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

8. From the Source Port list, select the source port for which you want to filter traffic, or retain the default
value *All Ports.
9. For the Destination IP Address setting, click Host, and in the Address field, type an IP address.
This IP address should be the final host or network address to which the application traffic is destined.
Sample destination IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Destination IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

10. From the Destination Port list, select the destination port for which you want to filter traffic, or retain
the default value * All Ports.
11. From the Protocol list, select the protocol for which you want to filter traffic.
You can select * All Protocols, TCP, UDP, ICMP, or Other. If you select Other, you must type a
protocol name.
12. From the Direction list, select Both.
13. From the Action list, select Protect.
The IPsec Policy Name setting appears.
14. From the IPsec Policy Name list, select the name of the custom IPsec policy that you created.
15. Click Finished.
The screen refreshes and displays the new IPsec traffic selector in the list.
16. Repeat this task on the BIG-IP system in the remote location.

94
 BIG-IP® TMOS®: Implementations

Verifying IPsec connectivity for Transport mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

2. Before sending traffic, type this command at the prompt.
tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the Destination IP Address in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp
This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

95
Configuring IPsec in Transport Mode between Two BIG-IP Systems

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

96
 BIG-IP® TMOS®: Implementations

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=transport spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=transport spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0

97
Configuring IPsec in Transport Mode between Two BIG-IP Systems

sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 353.9K 252.4M 24.9K 1.8M
0 TRANSPORT 117.9K 41.0M 163.3K 12.4M
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 0 0 0 0
2 TUNNEL 0 0 0 0

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Transport
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Transport
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For troubleshooting, increase the debug level by typing this command at the prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.
tmsh modify ipsec ike-daemon ikedaemon log-level info

98
 BIG-IP® TMOS®: Implementations

Note: Using this command flushes existing SAs.

Implementation result
You now have a secure IPsec channel for securing traffic that traverses the WAN, from one BIG-IP® system
to another.

99
Configuring IPsec in Transport Mode between Two BIG-IP Systems

100
Chapter
11
Configuring IPsec between a BIG-IP System and a
Third-Party Device
Topics:

• Overview: Configuring IPsec between a

BIG-IP system and a third-party device
• Task summary
• Implementation result
Configuring IPsec between a BIG-IP System and a Third-Party Device

Overview: Configuring IPsec between a BIG-IP system and a third-party

device
You can configure an IPsec tunnel when you want to use a protocol other than SSL to secure traffic that
traverses a wide area network (WAN), from a BIG-IP® system to third-party device. By following this
process, you can configure an IKE peer to negotiate Phase 1 Internet Security Association and Key
Management Protocol (ISAKMP) security associations for the secure channel between two systems. You
can also configure a custom traffic selector and a custom IPsec policy that use this secure channel to generate
IPsec Tunnel mode (Phase 2) security associations (SAs).
This implementation describes the tasks for setting up the IPsec tunnel on the BIG-IP system. You must
also configure the third-party device at the other end of the tunnel. For those instructions, refer to the
manufacturer's documentation for your device.

Figure 11: Example of an IPsec tunnel between a BIG-IP system and a third-party device

About negotiation of security associations

The way to dynamically negotiate security associations is to configure the Internet Key Exchange (IKE)
protocol, which is included in the IPsec protocol suite. When you configure the IKE protocol, two IPsec
tunnel endpoints (IKE peers) open a secure channel using an ISAKMP security association (ISAKMP-SA)
to initially negotiate the exchange of peer-to-peer authentication data. This exchange is known as Phase 1
negotiation.
After Phase 1 is complete and the secure channel is established, Phase 2 negotiation begins, in which the
IKE peers dynamically negotiate the authentication and encryption algorithms to use to secure the payload.
Without IKE, the system cannot dynamically negotiate these security algorithms.

102
 BIG-IP® TMOS®: Implementations

About IPsec Tunnel mode

Tunnel mode causes the IPsec protocol to encrypt the entire packet (the payload plus the IP header). This
encrypted packet is then included as the payload in another outer packet with a new header. Traffic sent in
this mode is more secure than traffic sent in Transport mode, because the original IP header is encrypted
along with the original payload.

About BIG-IP components of the IPsec protocol suite

The IPsec protocol suite on the BIG-IP® system consists of these configuration components:
IKE peers
An IKE peer is a configuration object of the IPsec protocol suite that represents a BIG-IP system on
each side of the IPsec tunnel. IKE peers allow two systems to authenticate each other (known as IKE
Phase 1). The BIG-IP system includes the default IKE peer, named anonymous.
IPsec policies
An IPsec policy is a set of information that defines the specific IPsec protocol to use (ESP or AH), and
the mode (Transport, Tunnel, or iSession). For Tunnel mode, the policy also specifies the endpoints for
the tunnel, and for IKE Phase 2 negotiation, the policy specifies the security parameters to be used in
that negotiation. The way that you configure the IPsec policy determines the way that the BIG-IP system
manipulates the IP headers in the packets. The BIG-IP system includes two default IPsec policies, named
default-ipsec-policy and default-ipsec-policy-isession. A common configuration
includes a bidirectional policy on each BIG-IP system.
Traffic selectors
A traffic selector is a packet filter that defines what traffic should be handled by a IPsec policy. You
define the traffic by source and destination IP addresses and port numbers. A common configuration
includes a bidirectional traffic selector on each BIG-IP system.

Task summary
You can configure the IPsec and IKE protocols to secure traffic that traverses a wide area network (WAN),
such as from one data center to another.
Before you begin configuring IPsec and IKE, verify that this module, system objects, and connectivity exist
on the BIG-IP® system:
BIG-IP Local Traffic Manager™
This module directs traffic securely and efficiently to the appropriate destination on a network.
Self IP address
The BIG-IP system must have at least one self IP address, to be used in specifying the end of the IPsec
tunnel.
The default VLANs
These VLANs are named external and internal.
BIG-IP connectivity
Verify the connectivity between the client or server and its BIG-IP device, and between the BIG-IP
device and its gateway. For example, you can use ping to test this connectivity.

103
Configuring IPsec between a BIG-IP System and a Third-Party Device

Task list
Creating a forwarding virtual server for IPsec
Creating an IKE peer
Creating a custom IPsec policy
Creating a bidirectional IPsec traffic selector
Verifying IPsec connectivity for Tunnel mode

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating an IKE peer

The IKE peer object identifies to the system you are configuring the other device with which it communicates
during Phase 1 negotiations. The IKE peer object also specifies the specific algorithms and credentials to
be used for Phase 1 negotiation.

Important: You must also configure the device at the other end of the IPsec tunnel.

1. On the Main tab, click Network > IPsec > IKE Peers.
2. Click the Create button.
The New IKE Peer screen opens.
3. In the Name field, type a unique name for the IKE peer.
4. In the Description field, type a brief description of the IKE peer.
5. In the Remote Address field, type the IP address of the device that is remote to the system you are
configuring.
This address must match the value of the Tunnel Remote Address setting in the relevant IPsec policy.
6. For the State setting, retain the default value, Enabled.
7. For the IKE Phase 1 Algorithms area, retain the default values, or select the options that are appropriate
for your deployment.

104
 BIG-IP® TMOS®: Implementations

Important: The values you select must match the IKE Phase 1 settings on the remote device.

Setting Options
Authentication Algorithm
MD5

SHA-1 (default)

SHA-256

SHA-384

SHA-512

Encryption Algorithm
DES

3 DES (default)

BLOWFISH

CAST128

AES

CAMELLIA

Perfect Forward Secrecy

MODP768

MODP1024 (default)

MODP1536

MODP2048

MODP3072

MODP4096

MODP6144

MODP8192

Lifetime Length of time, in minutes, before the IKE security association

expires. The range is

8. In the IKE Phase 1 Credentials area, for theAuthentication Method setting, select either RSA Signature
or Preshared Key.
• If you select RSA Signature (default), the Certificate, Key, and Verify Certificate settings are
available. If you have your own certificate file, key file, and certificate authority (CA), F5
recommends, for security purposes, that you specify these files in the appropriate fields. To reveal
all these fields, select the Verify Certificate check box. If you retain the default settings, leave the
check box cleared.

Important: If you select the check box, you must provide a certificate file, key, and certificate
authority.

105
Configuring IPsec between a BIG-IP System and a Third-Party Device

• If you select Preshared Key, type the key in the Preshared Key field that becomes available.

Note: The key you type must be the same at both ends of the tunnel.

9. For the Common Settings area, retain all default values.

10. Click Finished.
The page refreshes and displays the new IKE peer in the list.

You now have an IKE peer defined for establishing a secure channel.

Creating a custom IPsec policy

You create a custom IPsec policy when you want to use a policy other than the default IPsec policy
(default-ipsec-policy or default-ipsec-policy-isession). A typical reason for creating a
custom IPsec policy is to configure IPsec to operate in Tunnel rather than Transport mode.

Important: You must also configure the device at the other end of the IPsec tunnel.

1. On the Main tab, click Network > IPsec > IPsec Policies.
2. Click the Create button.
The New Policy screen opens.
3. In the Name field, type a unique name for the policy.
4. In the Description field, type a brief description of the policy.
5. For the IPsec Protocol setting, retain the default selection, ESP.
6. From the Mode list, select Tunnel.
The screen refreshes to show additional related settings.
7. In the Tunnel Local Address field, type the local IP address of the system you are configuring.
For example, the tunnel local IP address for BIG-IP A is [Link].
8. In the Tunnel Remote Address field, type the IP address that is remote to the system you are configuring.
This address must match the Remote Address setting for the relevant IKE peer.
For example, the tunnel remote IP address configured on BIG-IP A is the IP address of Router B, which
is [Link].
9. For the IKE Phase 2 area, retain the default values, or select the options that are appropriate for your
deployment.

Important: The values you select must match the IKE Phase 2 settings on the remote device.

Setting Options
Authentication Algorithm
SHA-1

AES-GCM128 (default)

AES-GCM192

AES-GCM256

AES-GMAC128

AES-GMAC192

106
 BIG-IP® TMOS®: Implementations

Setting Options
AES-GMAC256

Encryption Algorithm
AES-GCM128 (default)

Perfect Forward Secrecy

MODP768

MODP1024 (default)

MODP1536

MODP2048

MODP3072

MODP4096

MODP6144

MODP8192

Lifetime Length of time, in minutes, before the IKE security association

expires. The range is

10. Click Finished.

The screen refreshes and displays the new IPsec policy in the list.

Creating a bidirectional IPsec traffic selector

The traffic selector you create filters traffic based on the IP addresses and port numbers that you specify,
as well as the custom IPsec policy you assign.

Important: You must also configure the device at the other end of the IPsec tunnel.

1. On the Main tab, click Network > IPsec > Traffic Selectors.
2. Click Create.
The New Traffic Selector screen opens.
3. In the Name field, type a unique name for the traffic selector.
4. In the Description field, type a brief description of the traffic selector.
5. For the Order setting, retain the default value (First).
This setting specifies the order in which the traffic selector appears on the Traffic Selector List screen.
6. From the Configuration list, select Advanced.
7. For the Source IP Address setting, click Host or Network, and in the Address field, type an IP address.
This IP address should be the host or network address from which the application traffic originates.

107
Configuring IPsec between a BIG-IP System and a Third-Party Device

Sample source IP addresses for BIG-IP A and Router B are as follows.

System Name Source IP Address

BIG-IP A [Link]/24

Router B [Link]/24

8. From the Source Port list, select the source port for which you want to filter traffic, or retain the default
value *All Ports.
9. For the Destination IP Address setting, click Host, and in the Address field, type an IP address.
This IP address should be the final host or network address to which the application traffic is destined.
Sample destination IP addresses for BIG-IP A and BIG-IP B are as follows.

System Name Destination IP Address

BIG-IP A [Link]/24

Router B [Link]/24

10. From the Destination Port list, select the destination port for which you want to filter traffic, or retain
the default value * All Ports.
11. From the Protocol list, select the protocol for which you want to filter traffic.
You can select * All Protocols, TCP, UDP, ICMP, or Other. If you select Other, you must type a
protocol name.
12. From the Direction list, select Both.
13. From the Action list, select Protect.
The IPsec Policy Name setting appears.
14. From the IPsec Policy Name list, select the name of the custom IPsec policy that you created.
15. Click Finished.
The screen refreshes and displays the new IPsec traffic selector in the list.

Verifying IPsec connectivity for Tunnel mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic matching the traffic selector triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

2. Before sending traffic, type this command at the prompt.
tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the destination IP address specified in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp

108
 BIG-IP® TMOS®: Implementations

This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

109
Configuring IPsec between a BIG-IP System and a Third-Party Device

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=tunnel spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=tunnel spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0

110
 BIG-IP® TMOS®: Implementations

sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 0 0 0 0
0 TRANSPORT 0 0 0 0
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 353.9K 252.4M 24.9K 1.8M
2 TUNNEL 117.9K 41.0M 163.3K 12.4M

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For protocol-level troubleshooting, you can increase the debug level by typing this command at the
prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.
tmsh modify ipsec ike-daemon ikedaemon log-level info

111
Configuring IPsec between a BIG-IP System and a Third-Party Device

Note: Using this command flushes existing SAs.

Implementation result
You now have an IPsec tunnel for securing traffic that traverses the WAN, from one BIG-IP® system to a
third-party device.

112
Chapter
12
Configuring IPsec Using Manually Keyed Security
Associations
Topics:

• Overview: Configuring IPsec using manual

security associations
• Task summary
Configuring IPsec Using Manually Keyed Security Associations

Overview: Configuring IPsec using manual security associations

You can configure an IPsec tunnel when you want to use a protocol other than SSL to secure traffic that
traverses a wide area network (WAN), from one BIG-IP ®system to another. Typically, you would use the
Internet Key Exchange (IKE) protocol to negotiate the secure channel between the two systems. If you
choose not to use IKE, you must create manual security associations for IPsec security. A manual security
association statically defines the specific attribute values that IPsec should use for the authentication and
encryption of data flowing through the tunnel.

Figure 12: Illustration of an IPsec deployment

The implementation of the IPsec protocol suite with a manual security association consists of these
components:
IPsec policy
An IPsec policy is a set of information that defines the specific IPsec protocol to use (ESP or AH), and
the mode (Transport, Tunnel, or iSession). For Tunnel mode, the policy also specifies the endpoints for
the tunnel. The way that you configure the IPsec policy determines the way that the BIG-IP system
manipulates the IP headers in the packets. The BIG-IP system includes two default IPsec policies, named
default-ipsec-policy and default-ipsec-policy-isession. A common configuration
includes a bidirectional policy on each BIG-IP system.
Manual security association
A manual security association is set of information that the IPsec protocol uses to authenticate and
encrypt application traffic.

Note: When you create a manual security association instead of using IKE, the peer systems
do not negotiate these attributes. Peers can communicate only when they share the same
configured attributes.

Traffic selector
A traffic selector is a packet filter that defines what traffic should be handled by a IPsec policy. You
define the traffic by source and destination IP addresses and port numbers. A common configuration
includes a bidirectional traffic selector on each BIG-IP system.

114
 BIG-IP® TMOS®: Implementations

About IPsec Tunnel mode

Tunnel mode causes the IPsec protocol to encrypt the entire packet (the payload plus the IP header). This
encrypted packet is then included as the payload in another outer packet with a new header. Traffic sent in
this mode is more secure than traffic sent in Transport mode, because the original IP header is encrypted
along with the original payload.

Task summary
You can configure an IPsec tunnel to secure traffic that traverses a wide area network (WAN), such as from
one data center to another.
Before you begin configuring IPsec, verify that these modules, system objects, and connectivity exist on
the BIG-IP® systems in both the local and remote locations:
BIG-IP Local Traffic Manager™
This module directs traffic securely and efficiently to the appropriate destination on a network.
Self IP address
Each BIG-IP system must have at least one self IP address, to be used in specifying the ends of the IPsec
tunnel.
The default VLANs
These VLANs are named external and internal.
BIG-IP connectivity
Verify the connectivity between the client or server and its BIG-IP device, and between each BIG-IP
device and its gateway. For example, you can use ping to test this connectivity.

Task list
Creating a forwarding virtual server for IPsec
Creating a manual IPsec security association
Creating a custom IPsec policy
Creating a bidirectional IPsec traffic selector
Verifying IPsec connectivity for Tunnel mode

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.

115
Configuring IPsec Using Manually Keyed Security Associations

b) In the Address field, type the IP address [Link].

c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating a manual IPsec security association

Before starting this task, determine the source and destination IP addresses for theBIG-IP® systems in your
network that will direct the application traffic.
You create a manual security association to specify the security attributes for a given IPsec communication
session. These attributes include the specific source and destination IP addresses of the communicating
devices, the authentication algorithm, and the encryption algorithm that the IPsec protocol should use.

Important: You must perform this task on both BIG-IP systems.

1. On the Main tab, click Network > IPsec > Manual Security Associations.
2. Click the Create button.
The New Security Association screen opens.
3. In the Name field, type a unique name for the security association.
4. In the Description field, type a brief description of the security setting.
5. In the SPI field, type a unique number for the security parameter index.
This number must be an integer between 256 and 4294967296.
6. In the Source Address field, type the source IP address.
7. In the Destination Address field, type the destination IP address.
8. In the Authentication Key field, type a key value.
This value can by any double-quoted character string up to a maximum of 128 characters
9. From the Encryption Algorithm list, select the algorithm appropriate to your deployment.
10. In the Encryption Key field, type a key value.
This value can by any double-quoted character string up to a maximum of 128 characters
11. Click Finished.
The screen refreshes and displays the new IPsec security association in the list.
12. Repeat this task on the BIG-IP system in the remote location.

Creating a custom IPsec policy

You create a custom IPsec policy when you want to use a policy other than the default IPsec policy
(default-ipsec-policy or default-ipsec-policy-isession). A typical reason for creating a
custom IPsec policy is to configure IPsec to operate in Tunnel rather than Transport mode.

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > IPsec Policies.

116
 BIG-IP® TMOS®: Implementations

2. Click the Create button.

The New Policy screen opens.
3. In the Name field, type a unique name for the policy.
4. In the Description field, type a brief description of the policy.
5. For the IPsec Protocol setting, retain the default selection, ESP.
6. From the Mode list, select Tunnel.
The screen refreshes to show additional related settings.
7. In the Tunnel Local Address field, type the local IP address of the system you are configuring.
Sample tunnel local addresses for BIG-IP A and BIG-IP B are as follows.

System Name Tunnel Local Address

BIG-IP A [Link]

BIG-IP B [Link]

8. In the Tunnel Remote Address field, type the IP address that is remote to the system you are configuring.
This address must match the Remote Address setting for the relevant IKE peer.
Sample tunnel remote addresses for BIG-IP A and BIG-IP B are as follows.

System Name Tunnel Remote Address

BIG-IP A [Link]

BIG-IP B [Link]

9. For the Authentication Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.
10. For the Encryption Algorithm setting, retain the default value, or select the algorithm appropriate for
your deployment.
11. For the Perfect Forward Secrecy setting, retain the default value, or select the option appropriate for
your deployment.
12. For the Lifetime setting, retain the default value, 1440.
This is the length of time (in minutes) before the current security association expires.
13. Click Finished.
The screen refreshes and displays the new IPsec policy in the list.
14. Repeat this task on the BIG-IP system in the remote location.

Creating a bidirectional IPsec traffic selector

The traffic selector you create filters traffic based on the IP addresses and port numbers that you specify,
as well as the custom IPsec policy you assign.

Important: You must perform this task on both BIG-IP® systems.

1. On the Main tab, click Network > IPsec > Traffic Selectors.
2. Click Create.
The New Traffic Selector screen opens.
3. In the Name field, type a unique name for the traffic selector.

117
Configuring IPsec Using Manually Keyed Security Associations

4. In the Description field, type a brief description of the traffic selector.

5. For the Order setting, retain the default value (First).
This setting specifies the order in which the traffic selector appears on the Traffic Selector List screen.
6. From the Configuration list, select Advanced.
7. For the Source IP Address setting, click Host or Network, and in the Address field, type an IP address.
This IP address should be the host or network address from which the application traffic originates.
Sample source IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Source IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

8. From the Source Port list, select the source port for which you want to filter traffic, or retain the default
value *All Ports.
9. For the Destination IP Address setting, click Host, and in the Address field, type an IP address.
This IP address should be the final host or network address to which the application traffic is destined.
Sample destination IP addresses for BIG-IP A and BIG-IP B are as follows:

System Name Destination IP Address

BIG-IP A [Link]/24

BIG-IP B [Link]/24

10. From the Destination Port list, select the destination port for which you want to filter traffic, or retain
the default value * All Ports.
11. From the Protocol list, select the protocol for which you want to filter traffic.
You can select * All Protocols, TCP, UDP, ICMP, or Other. If you select Other, you must type a
protocol name.
12. From the Direction list, select Both.
13. From the Action list, select Protect.
The IPsec Policy Name setting appears.
14. From the IPsec Policy Name list, select the name of the custom IPsec policy that you created.
15. Click Finished.
The screen refreshes and displays the new IPsec traffic selector in the list.
16. Repeat this task on the BIG-IP system in the remote location.

Verifying IPsec connectivity for Tunnel mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic matching the traffic selector triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

118
 BIG-IP® TMOS®: Implementations

2. Before sending traffic, type this command at the prompt.

tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the destination IP address specified in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp
This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

119
Configuring IPsec Using Manually Keyed Security Associations

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=tunnel spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=tunnel spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)

120
 BIG-IP® TMOS®: Implementations

current: 0(bytes) hard: 0(bytes) soft: 0(bytes)

allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 0 0 0 0
0 TRANSPORT 0 0 0 0
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 353.9K 252.4M 24.9K 1.8M
2 TUNNEL 117.9K 41.0M 163.3K 12.4M

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For protocol-level troubleshooting, you can increase the debug level by typing this command at the
prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.

121
Configuring IPsec Using Manually Keyed Security Associations

tmsh modify ipsec ike-daemon ikedaemon log-level info

Note: Using this command flushes existing SAs.

122
Chapter
13
Setting Up IPsec To Use NAT Traversal on Both Sides of
the WAN
Topics:

• Overview: Setting up IPsec to use NAT

traversal on both sides of the WAN
• Before you begin IPsec configuration
• Task summary
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

Overview: Setting up IPsec to use NAT traversal on both sides of the WAN
When you are using IPsec to secureWAN traffic, you can set up an IPsec tunnel with NAT traversal (NAT-T)
to get around a firewall or other NAT device. This implementation describes how to set up the IPsec tunnel
when you have a NAT device on both sides of the tunnel.
The following illustration shows a network configuration with a firewall on both sides of the WAN.

Figure 13: Example of an IPsec deployment with NAT-T on both sides of the WAN

Before you begin IPsec configuration

Before you configure IPsec on a BIG-IP® device, make sure that you have completed the following general
prerequisites.
• You must have an existing routed IP network between the two locations where the BIG-IP devices will
be installed.
• The BIG-IP hardware is installed with an initial network configuration applied. The two BIG-IP devices
must be running on one of the following platforms: 1600, 3600, 3900, 6900, 8900, 8950 or 11000,
VIPRION 4400/2400, or BIG-IP Virtual Edition (VE).
• The management IP address is configured on the BIG-IP system.
• If you are using NAT traversal, forward UDP ports 500 and 4500 to the BIG-IP system behind each
firewall.
• Verify the connectivity between the client or server and its BIG-IP device, and between each BIG-IP
device and its gateway. You can use ping to test connectivity.

Task summary
When you are configuring an IPsec tunnel, you must repeat the configuration tasks on the BIG-IP systems
on both sides of the WAN.

124
 BIG-IP® TMOS®: Implementations

Creating a forwarding virtual server for IPsec

Creating an IPsec tunnel with NAT-T on both sides
Verifying IPsec connectivity for Tunnel mode
Creating a forwarding virtual server for IPsec
Creating an IPsec tunnel with NAT-T on both sides
Verifying IPsec connectivity for Tunnel mode

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating an IPsec tunnel with NAT-T on both sides

You can create an IPsec tunnel to securely transport application traffic across the WAN. You must configure
the IPsec tunnel on the BIG-IP systems on both sides of the WAN.
When you create an IKE peer for NAT traversal (NAT-T), the key configuration detail is that the Remote
Address setting is the public IP address of the firewall or other NAT device (not the IP address of the remote
BIG-IP system). Also, you must turn on NAT traversal. You can customize the remaining settings to conform
to your network.

Important: For the IKE peer negotiations to be successful, the IKE Phase 1 and IKE Phase 2
settings must be the same on the BIG-IP systems at both ends of the IPsec tunnel.

1. Create an IKE peer that specifies the other end of the IPsec tunnel.
a) On the Main tab, click Network > IPsec > IKE Peers.
b) Click the Create button.
c) In the Name field, type a unique name for the IKE peer.
d) In the Remote Address field, type the public IP address of the firewall or other NAT device that is
between the WAN and the remote BIG-IP system.
This address is the IP address of the remote peer, and must match the value of the Tunnel Remote
Address setting in the relevant IPsec policy.

125
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

For example, the peer remote addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Remote (Peer) Address

Site A [Link]

Site B [Link]

This screen snippet shows the peer Remote Address setting at Site A.

e) For the IKE Phase 1Algorithms area, retain the default values, or select the options that are appropriate
for your deployment.
f) In the IKE Phase 1 Credentials area, for theAuthentication Method setting, select either Preshared
Key or RSA Signature, and specify additional information in the fields that appear.
For example, if you select Preshared Key, type the key in the Preshared Key field that becomes
available.

Note: The key you type must be the same at both ends of the tunnel.

g) From the NAT Traversal list, select On.

h) Click Finished.

126
 BIG-IP® TMOS®: Implementations

2. Create a custom IPsec policy that uses Tunnel mode and has the same remote IP address as the IKE
peer.
a) On the Main tab, click Network > IPsec > IPsec Policies.
b) Click the Create button.
c) In the Name field, type a unique name for the policy.
d) For the IPsec Protocol setting, retain the default selection, ESP.
e) From the Mode list, select Tunnel.
The screen refreshes to show additional related settings.
f) In the Tunnel Local Address field, type the local IP address of the system you are configuring.
For example, the tunnel local addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Tunnel Local Address

Site A [Link]

Site B [Link]

g) In the Tunnel Remote Address field, type the public IP address of the firewall or other NAT device
that is between the WAN and the remote BIG-IP system.
This address must match the value of the Remote Address setting for the relevant IKE peer.
For example, the tunnel remote addresses for the BIG-IP systems in SiteA and Site B are as follows.

Location Tunnel Remote Address

Site A [Link]

Site B [Link]

This screen snippet shows the tunnel settings at Site A.

h) For the Authentication Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.

127
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

i) For the Encryption Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.
j) For the Perfect Forward Secrecy setting, retain the default value, or select the option appropriate
for your deployment.
k) Click Finished.
3. Create a bidirectional traffic selector that uses the custom IPsec policy you created.
The traffic selector filters the application traffic based on the source and destination IP addresses you
specify.
a) On the Main tab, click Network > IPsec > Traffic Selectors.
b) Click Create.
c) In the Name field, type a unique name for the traffic selector.
d) For the Order setting, retain the default value (First).
e) For the Source IP Address setting, in the Address field, type the IP address from which the
application traffic originates.
For example, the source IP addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Source IP Address

Site A [Link]

Site B [Link]

f) In the Destination IP Address setting Address field, type the final IP address for which the
application traffic is destined.
For example, the source IP addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Destination IP Address

Site A [Link]

Site B [Link]

g) For the Action setting, retain the default value, Protect.

h) From the IPsec Policy Name list, select the name of the custom IPsec policy that you just created.

128
 BIG-IP® TMOS®: Implementations

This portion of a screen is an example of the completed Traffic Selector screen at Site A.

i) Click Finished.

You have now created an IPsec tunnel through which traffic travels in both directions across the WAN
through firewalls on both sides.

Verifying IPsec connectivity for Tunnel mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic matching the traffic selector triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

2. Before sending traffic, type this command at the prompt.
tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the destination IP address specified in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp

129
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

130
 BIG-IP® TMOS®: Implementations

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=tunnel spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=tunnel spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0

131
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 0 0 0 0
0 TRANSPORT 0 0 0 0
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 353.9K 252.4M 24.9K 1.8M
2 TUNNEL 117.9K 41.0M 163.3K 12.4M

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For protocol-level troubleshooting, you can increase the debug level by typing this command at the
prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.
tmsh modify ipsec ike-daemon ikedaemon log-level info

132
 BIG-IP® TMOS®: Implementations

Note: Using this command flushes existing SAs.

133
Setting Up IPsec To Use NAT Traversal on Both Sides of the WAN

134
Chapter
14
Setting Up IPsec To Use NAT Traversal on One Side of the
WAN
Topics:

• Overview: Setting up IPsec to use NAT

traversal on one side of the WAN
• Before you begin IPsec configuration
• Task summary
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

Overview: Setting up IPsec to use NAT traversal on one side of the WAN
When you are using IPsec to secureWAN traffic, you can set up an IPsec tunnel with NAT traversal (NAT-T)
to get around a firewall or other NAT device. This implementation describes how to set up the IPsec tunnel
when you have a NAT device on one side of the tunnel.
The following illustration shows a network configuration with a firewall on one side of the WAN.

Figure 14: Example of an IPsec deployment with NAT-T on one side of the WAN

Before you begin IPsec configuration

Before you configure IPsec on a BIG-IP® device, make sure that you have completed the following general
prerequisites.
• You must have an existing routed IP network between the two locations where the BIG-IP devices will
be installed.
• The BIG-IP hardware is installed with an initial network configuration applied. The two BIG-IP devices
must be running on one of the following platforms: 1600, 3600, 3900, 6900, 8900, 8950 or 11000,
VIPRION 4400/2400, or BIG-IP Virtual Edition (VE).
• The management IP address is configured on the BIG-IP system.
• If you are using NAT traversal, forward UDP ports 500 and 4500 to the BIG-IP system behind each
firewall.
• Verify the connectivity between the client or server and its BIG-IP device, and between each BIG-IP
device and its gateway. You can use ping to test connectivity.

Task summary
When you are configuring an IPsec tunnel, you must repeat the configuration tasks on the BIG-IP systems
on both sides of the WAN.
Creating a forwarding virtual server for IPsec

136
 BIG-IP® TMOS®: Implementations

Creating an IPsec tunnel with NAT-T on both sides

Verifying IPsec connectivity for Tunnel mode
Creating a forwarding virtual server for IPsec
Creating an IPsec tunnel with NAT-T on both sides
Verifying IPsec connectivity for Tunnel mode

Creating a forwarding virtual server for IPsec

For IPsec, you create a forwarding virtual server to intercept IP traffic and direct it over the tunnel.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
6. From the Service Port list, select *All Ports.
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
9. Click Finished.

Creating an IPsec tunnel with NAT-T on both sides

You can create an IPsec tunnel to securely transport application traffic across the WAN. You must configure
the IPsec tunnel on the BIG-IP systems on both sides of the WAN.
When you create an IKE peer for NAT traversal (NAT-T), the key configuration detail is that the Remote
Address setting is the public IP address of the firewall or other NAT device (not the IP address of the remote
BIG-IP system). Also, you must turn on NAT traversal. You can customize the remaining settings to conform
to your network.

Important: For the IKE peer negotiations to be successful, the IKE Phase 1 and IKE Phase 2
settings must be the same on the BIG-IP systems at both ends of the IPsec tunnel.

1. Create an IKE peer that specifies the other end of the IPsec tunnel.
a) On the Main tab, click Network > IPsec > IKE Peers.
b) Click the Create button.
c) In the Name field, type a unique name for the IKE peer.
d) In the Remote Address field, type the public IP address of the firewall or other NAT device that is
between the WAN and the remote BIG-IP system.
This address is the IP address of the remote peer, and must match the value of the Tunnel Remote
Address setting in the relevant IPsec policy.

137
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

For example, the peer remote addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Remote (Peer) Address

Site A [Link]

Site B [Link]

This screen snippet shows the peer Remote Address setting at Site A.

e) For the IKE Phase 1Algorithms area, retain the default values, or select the options that are appropriate
for your deployment.
f) In the IKE Phase 1 Credentials area, for theAuthentication Method setting, select either Preshared
Key or RSA Signature, and specify additional information in the fields that appear.
For example, if you select Preshared Key, type the key in the Preshared Key field that becomes
available.

Note: The key you type must be the same at both ends of the tunnel.

g) From the NAT Traversal list, select On.

h) Click Finished.

138
 BIG-IP® TMOS®: Implementations

2. Create a custom IPsec policy that uses Tunnel mode and has the same remote IP address as the IKE
peer.
a) On the Main tab, click Network > IPsec > IPsec Policies.
b) Click the Create button.
c) In the Name field, type a unique name for the policy.
d) For the IPsec Protocol setting, retain the default selection, ESP.
e) From the Mode list, select Tunnel.
The screen refreshes to show additional related settings.
f) In the Tunnel Local Address field, type the local IP address of the system you are configuring.
For example, the tunnel local addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Tunnel Local Address

Site A [Link]

Site B [Link]

g) In the Tunnel Remote Address field, type the public IP address of the firewall or other NAT device
that is between the WAN and the remote BIG-IP system.
This address must match the value of the Remote Address setting for the relevant IKE peer.
For example, the tunnel remote addresses for the BIG-IP systems in SiteA and Site B are as follows.

Location Tunnel Remote Address

Site A [Link]

Site B [Link]

This screen snippet shows the tunnel settings at Site A.

h) For the Authentication Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.

139
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

i) For the Encryption Algorithm setting, retain the default value, or select the algorithm appropriate
for your deployment.
j) For the Perfect Forward Secrecy setting, retain the default value, or select the option appropriate
for your deployment.
k) Click Finished.
3. Create a bidirectional traffic selector that uses the custom IPsec policy you created.
The traffic selector filters the application traffic based on the source and destination IP addresses you
specify.
a) On the Main tab, click Network > IPsec > Traffic Selectors.
b) Click Create.
c) In the Name field, type a unique name for the traffic selector.
d) For the Order setting, retain the default value (First).
e) For the Source IP Address setting, in the Address field, type the IP address from which the
application traffic originates.
For example, the source IP addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Source IP Address

Site A [Link]

Site B [Link]

f) In the Destination IP Address setting Address field, type the final IP address for which the
application traffic is destined.
For example, the source IP addresses for the BIG-IP systems in Site A and Site B are as follows.

Location Destination IP Address

Site A [Link]

Site B [Link]

g) For the Action setting, retain the default value, Protect.

h) From the IPsec Policy Name list, select the name of the custom IPsec policy that you just created.

140
 BIG-IP® TMOS®: Implementations

This portion of a screen is an example of the completed Traffic Selector screen at Site A.

i) Click Finished.

You have now created an IPsec tunnel through which traffic travels in both directions across the WAN
through firewalls on both sides.

Verifying IPsec connectivity for Tunnel mode

After you have configured an IPsec tunnel and before you configure additional functionality, you can verify
that the tunnel is passing traffic.

Note: Only data traffic matching the traffic selector triggers the establishment of the tunnel.

1. Access the tmsh command-line utility.

2. Before sending traffic, type this command at the prompt.
tmsh modify ipsec ike-daemon log-level info
This command increases the logging level to display the INFO messages that you want to view.
3. Send data traffic to the destination IP address specified in the traffic selector.
4. Check the IKE Phase 1 negotiation status by typing this command at the prompt.
racoonctl -l show-sa isakmp

141
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

This example shows a result of the command. Destination is the tunnel remote IP address.

Destination Cookies ST S V E Created

Phase2
[Link].500 98993e6 . . . 22c87f1 9 I 10 M 2012-06-27 [Link]
1

This table shows the legend for interpreting the result.

Column Displayed Description

ST (Tunnel Status) 1 Start Phase 1 negotiation
2 msg 1 received
3 msg 1 sent
4 msg 2 received
5 msg 2 sent
6 msg 3 received
7 msg 3 sent
8 msg 4 received
9 isakmp tunnel established
10 isakmp tunnel expired
S I Initiator
R Responder
V (Version Number) 10 ISAKMP version 1.0
E (Exchange Mode) M Main (Identity Protection)
A Aggressive
Phase2 <n> Number of Phase 2 tunnels negotiated with this IKE
peer

5. Check the IKE Phase 2 negotiation status by typing this command at the prompt.
racoonctl -l1 show-sa internal
This example shows a result of this command. Source is the tunnel local IP address. Destination is
the tunnel remote IP address.

Source Destination Status Side

[Link] [Link] sa established [R]

142
 BIG-IP® TMOS®: Implementations

This table shows the legend for interpreting the result.

Column Displayed
Side I (Initiator)
R (Responder)
Status init
start
acquire
getspi sent
getspi done
1st msg sent
1st msg recvd
commit bit
sa added
sa established
sa expired

6. To verify the establishment of dynamic negotiated Security Associations (SAs), type this command at
the prompt.
racoonctl -l show-sa ipsec
For each tunnel, the output displays IP addresses and information for two IPsec SAs, one for each
direction, as shown in the example.

[Link] [Link]
esp mode=tunnel spi=2068022822(0x7b438626)
reqid=26781(0x0000689d)
E: null
A: hmac-sha1 9669c37c 4c83c096 beeddbde ef74d61a 2acf37ef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=21100 refcnt=512
[Link] [Link]
esp mode=tunnel spi=1582473691(0x5e52a1db)
reqid=26780(0x0000689c)
E: null
A: hmac-sha1 8a1b7f19 3085a5ca d0190805 18125e19 e6bda3d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 31 [Link] 1969 current: Jun 29 [Link] 2012

diff: 1341012135(s) hard: 864000(s) soft: 864000(s)

last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0

143
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

sadb_seq=0 pid=21100 refcnt=512

7. Check the IPsec stats by typing this command at the prompt.

tmsh show net ipsec-stat
If traffic is passing through the IPsec tunnel, the stats will increment.

-------------------------------------------------------------------
Net::Ipsec
Cmd Id Mode Packets In Bytes In Packets Out Bytes Out
-------------------------------------------------------------------
0 TRANSPORT 0 0 0 0
0 TRANSPORT 0 0 0 0
0 TUNNEL 0 0 0 0
0 TUNNEL 0 0 0 0
1 TUNNEL 353.9K 252.4M 24.9K 1.8M
2 TUNNEL 117.9K 41.0M 163.3K 12.4M

8. If the SAs are established, but traffic is not passing, type these commands at the prompt.

racoonctl flush-sa isakmp

racoonctl flush-sa ipsec
This action forces the system to flush the existing SAs. Sending new traffic triggers SA negotiation and
establishment.
9. View the /var/log/[Link] to verify that the IPsec tunnel is up.
These lines are examples of the messages you are looking for.

2012-06-29 [Link] INFO: ISAKMP-SA established

[Link][500]-[Link][500]
spi:3840191bd045fa51:673828cf6adc5c61
2012-06-29 [Link] INFO: initiate new phase 2 negotiation:
[Link][500]<=>[Link][500]
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=2403416622(0x8f413a2e)
2012-06-29 [Link] INFO: IPsec-SA established: ESP/Tunnel
[Link][0]->[Link][0] spi=4573766(0x45ca46

10. For protocol-level troubleshooting, you can increase the debug level by typing this command at the
prompt.
tmsh modify net ipsec ike-daemon ikedaemon log-level debug2

Important: Use this command only for debugging. It creates a large log file, and can slow the
tunnel negotiation.

Note: Using this command flushes existing SAs.

11. After you view the results, return the debug level to normal to avoid excessive logging by typing this
command at the prompt.
tmsh modify ipsec ike-daemon ikedaemon log-level info

144
 BIG-IP® TMOS®: Implementations

Note: Using this command flushes existing SAs.

145
Setting Up IPsec To Use NAT Traversal on One Side of the WAN

146
Chapter
15
Using Link Aggregation with Tagged VLANs for One-Network
Topology
Topics:

• Overview: Configuring link aggregation using

tagged VLANs on one network
• Illustration of link aggregation for a
one-network topology
• Task summary
Using Link Aggregation with Tagged VLANs for One-Network Topology

Overview: Configuring link aggregation using tagged VLANs on one network

You can use the BIG-IP® system in an aggregated two-interface load balancing topology. Link aggregation
is the process of combining multiple links so that the links function as a single link with higher bandwidth.
Aggregating multiple interfaces into a trunk to create a link has the following advantages:
• Link aggregation increases the bandwidth of the individual network interface cards (NICs) in an additive
manner.
• If one link goes down, the other link can handle the traffic by itself.
Link aggregation occurs when you create a trunk. A trunk is a combination of two or more interfaces and
cables configured as one link.
The examples in this implementation show a trunk that includes two tagged interfaces aggregated together.
A tagged interface is an interface that is configured to process traffic for multiple VLANs. A VLAN tag
identifies the specific VLAN and enables traffic to pass through that specific VLAN. To cause traffic for
multiple VLANs to be passed through a single trunk, you must assign the same trunk to each VLAN.
In the example, we create a trunk (trunk1) that includes two interfaces, 1.1 and 1.2, and then assign trunk1
as a tagged interface to both VLAN external and VLAN internal. Both VLANs (external and internal)
reside on the same network, and are combined to form a VLAN group.
With this configuration, inbound and outbound traffic passing between the BIG-IP system and the vendor
switch can use either interface. For example, traffic destined for VLAN externall can pass through either
interface, 1.1 or 1.2.

Illustration of link aggregation for a one-network topology

148
 BIG-IP® TMOS®: Implementations

Task summary
Perform the following tasks to configure two interfaces (tagged VLANs) to function as a single link with
higher bandwidth. In this implementation, you combine the two tagged VLANs into one VLAN group,
where the two VLANs are on the same IP network.

Task list
Creating a trunk
Adding a tagged interface to a VLAN
Creating a load balancing pool
Creating a virtual server with source address affinity persistence
Removing the self IP addresses from the default VLANs
Creating a VLAN group
Creating a self IP for a VLAN group

Creating a trunk
To configure the BIG-IP® system for the two-network implementation, you must first create a trunk to
aggregate the links.

1. On the Main tab, click Network > Trunks.

The Trunk List screen opens.
2. Click Create.
3. Name the trunk.
4. For the Interfaces setting, in the Available field, select an interface, and using the Move button, move
the interface to the Members field.
Do this for each interface that you want to include as a trunk member.
5. Select the LACP check box.
6. Click Finished.

A trunk is available to aggregate links.

Adding a tagged interface to a VLAN

After you aggregate the links, you assign the trunk to the VLAN as a tagged interface.

1. On the Main tab, click Network > VLANs.

The VLAN List screen opens.
2. Perform the following for the external and internal VLANs:
a) Click the VLAN name.
b) For the Interfaces setting, in the Available field, select a trunk, and using the Move button, move
the trunk that you created to the Tagged field.
c) Click Update.

The trunk is assigned to the external and internal VLAN as a tagged interface.

149
Using Link Aggregation with Tagged VLANs for One-Network Topology

Creating a load balancing pool

You can create a load balancing pool (a logical set of devices such as web servers that you group together
to receive and process traffic) to efficiently distribute the load on your server resources.

Note: You must create the pool before you create the corresponding virtual server.

1. On the Main tab, click Local Traffic > Pools.

The Pool List screen opens.
2. Click Create.
The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. For the Health Monitors setting, in the Available list, select a monitor type, and click << to move the
monitor to the Active list.

Tip: Hold the Shift or Ctrl key to select more than one monitor at a time.

5. From the Load Balancing Method list, select how the system distributes traffic to members of this
pool.
The default is Round Robin.
6. For the Priority Group Activation setting, specify how to handle priority groups:
• Select Disabled to disable priority groups. This is the default option.
• Select Less than, and in the Available Members field, type the minimum number of members that
must remain available in each priority group in order for traffic to remain confined to that group.

7. Using the New Members setting, add each resource that you want to include in the pool:
a) Either type an IP address in the Address field, or select a node address from the Node List.
b) Type a port number in the Service Port field, or select a service name from the list.
c) To specify a priority group, type a priority number in the Priority field.
d) Click Add.
8. Click Finished.

The load balancing pool appears in the Pools list.

Creating a virtual server with source address affinity persistence

A virtual server represents a destination IP address for application traffic.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. Specify the Destination setting, using the Address field; type the IP address you want to use for the
virtual server.
The IP address you type must be available and not in the loopback network.
5. For the Service Port setting, type a port number in the field, or select a service name from the list.

150
 BIG-IP® TMOS®: Implementations

6. Locate the relevant profile type for the traffic being managed, and either retain the default value or select
a custom profile name.
7. In the Resources area of the screen, from the Default Pool list, select a pool name.
8. For the Default Persistence Profile setting, select source_addr.
This implements simple persistence, using the default source address affinity profile.

A client system now has a destination IP address on the BIG-IP system.

Removing the self IP addresses from the default VLANs

Remove the self IP addresses from the individual VLANs. After you create the VLAN group, you will
create another self IP address for the VLAN group for routing purposes. The individual VLANs no longer
need their own self IP addresses.

1. On the Main tab, click Network > Self IPs.

The Self IPs screen opens.
2. Select the check box for each IP address and VLAN that you want to delete.
3. Click Delete.
4. Click Delete.

The self IP address is removed from the Self IP list.

Creating a VLAN group

Create a VLAN group that includes the internal and external VLANs. Packets received by a VLAN in the
VLAN group are copied onto the other VLAN. This allows traffic to pass through the BIG-IP® system on
the same IP network.

1. On the Main tab, click Network > VLANs > VLAN Groups.
The VLAN Groups list screen opens.
2. Click Create.
The New VLAN Group screen opens.
3. In the Name field, type the name myvlangroup.
4. For the VLANs setting, use the Move button to move the internal and external VLAN names from
the Available field to the Members field.
5. Click Finished.

Creating a self IP for a VLAN group

You need at least one VLAN or VLAN group configured before you create a self IP address.
After you have created the VLAN group, create a self IP address for the VLAN group. The self IP address
for the VLAN group provides a route for packets destined for the network. With the BIG-IP® system, the
path to an IP network is a VLAN. However, with the VLAN group feature used in this procedure, the path
to the IP network [Link] is actually through more than one VLAN. As IP routers are designed to have
only one physical route to a network, a routing conflict can occur. The self IP address feature on the BIG-IP
system allows you to resolve the routing conflict by associating a self IP address with the VLAN group.

1. On the Main tab, click Network > Self IPs.

The Self IPs screen opens.

151
Using Link Aggregation with Tagged VLANs for One-Network Topology

2. Click Create.
The New Self IP screen opens.
3. In the IP Address field, type an IP address.
This IP address should represent the address space of the VLAN group that you specify with the
VLAN/Tunnel setting.
The system accepts IP addresses in both the IPv4 and IPv6 formats.
4. In the Netmask field, type the network mask for the specified IP address.
5. From the VLAN/Tunnel list, select the VLAN group with which to associate this self IP address.
6. From the Port Lockdown list, select Allow Default.
7. Click Finished.
The screen refreshes, and displays the new self IP address in the list.

The BIG-IP system can send and receive traffic through the specified VLAN or VLAN group.

152
Chapter
16
Using Link Aggregation with Tagged VLANs for
Two-Network Topology
Topics:

• Overview: Configuring link aggregation of

two interfaces using tagged VLANs on two
networks
• Task summary
Using Link Aggregation with Tagged VLANs for Two-Network Topology

Overview: Configuring link aggregation of two interfaces using tagged VLANs

on two networks
You can use the BIG-IP® system in an aggregated two-interface load balancing topology. Link aggregation
is the process of combining multiple links so that the links function as a single link with higher bandwidth.
Aggregating multiple interfaces into a trunk to create a link has the following advantages:
• Link aggregation increases the bandwidth of the individual network interface cards (NICs) in an additive
manner.
• If one link goes down, the other link can handle the traffic by itself.
Link aggregation occurs when you create a trunk. A trunk is a combination of two or more interfaces and
cables configured as one link.
The examples in this implementation show a trunk that includes two tagged interfaces aggregated together.
A tagged interface is an interface that is configured to process traffic for multiple VLANs. A VLAN tag
identifies the specific VLAN and allows traffic to be passed through that specific VLAN. To cause traffic
for multiple VLANs to be passed through a single trunk, you must assign the same trunk to each VLAN.
In the examples, we create a trunk (trunk1) that includes two interfaces, 1.1 and 1.2, and then assign trunk1
as a tagged interface to both VLAN external and VLAN internal. One network is connected to VLAN
external, and a separate network is connected to VLAN internal. Consequently, inbound and outbound
traffic passing between the BIG-IP system and the vendor switch can use either interface. For example,
traffic destined for VLAN externall can pass through either interface, 1.1 or 1.2.

Illustration of link aggregation for a two-network topology

Task summary
Perform the following tasks to configure two interfaces (tagged VLANs) to function as a single link with
higher bandwidth. In this implementation, each tagged VLAN is on a separate network.

Task list
Creating a trunk
Adding a tagged interface to a VLAN
Creating a load balancing pool

154
 BIG-IP® TMOS®: Implementations

Creating a virtual server with source address affinity persistence

Creating a trunk
To configure the BIG-IP® system for the two-network implementation, you must first create a trunk to
aggregate the links.

1. On the Main tab, click Network > Trunks.

The Trunk List screen opens.
2. Click Create.
3. Name the trunk.
4. For the Interfaces setting, in the Available field, select an interface, and using the Move button, move
the interface to the Members field.
Do this for each interface that you want to include as a trunk member.
5. Select the LACP check box.
6. Click Finished.

A trunk is available to aggregate links.

Adding a tagged interface to a VLAN

After you aggregate the links, you assign the trunk to the VLAN as a tagged interface.

1. On the Main tab, click Network > VLANs.

The VLAN List screen opens.
2. Perform the following for the external and internal VLANs:
a) Click the VLAN name.
b) For the Interfaces setting, in the Available field, select a trunk, and using the Move button, move
the trunk that you created to the Tagged field.
c) Click Update.

The trunk is assigned to the external and internal VLAN as a tagged interface.

Creating a load balancing pool

You can create a load balancing pool (a logical set of devices such as web servers that you group together
to receive and process traffic) to efficiently distribute the load on your server resources.

Note: You must create the pool before you create the corresponding virtual server.

1. On the Main tab, click Local Traffic > Pools.

The Pool List screen opens.
2. Click Create.
The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. For the Health Monitors setting, in the Available list, select a monitor type, and click << to move the
monitor to the Active list.

155
Using Link Aggregation with Tagged VLANs for Two-Network Topology

Tip: Hold the Shift or Ctrl key to select more than one monitor at a time.

5. From the Load Balancing Method list, select how the system distributes traffic to members of this
pool.
The default is Round Robin.
6. For the Priority Group Activation setting, specify how to handle priority groups:
• Select Disabled to disable priority groups. This is the default option.
• Select Less than, and in the Available Members field, type the minimum number of members that
must remain available in each priority group in order for traffic to remain confined to that group.

7. Using the New Members setting, add each resource that you want to include in the pool:
a) Either type an IP address in the Address field, or select a node address from the Node List.
b) Type a port number in the Service Port field, or select a service name from the list.
c) To specify a priority group, type a priority number in the Priority field.
d) Click Add.
8. Click Finished.

The load balancing pool appears in the Pools list.

Creating a virtual server with source address affinity persistence

A virtual server represents a destination IP address for application traffic.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. Specify the Destination setting, using the Address field; type the IP address you want to use for the
virtual server.
The IP address you type must be available and not in the loopback network.
5. For the Service Port setting, type a port number in the field, or select a service name from the list.
6. Locate the relevant profile type for the traffic being managed, and either retain the default value or select
a custom profile name.
7. In the Resources area of the screen, from the Default Pool list, select a pool name.
8. For the Default Persistence Profile setting, select source_addr.
This implements simple persistence, using the default source address affinity profile.

A client system now has a destination IP address on the BIG-IP system.

156
Chapter
17
Configuring Packet Filtering
Topics:

• Overview: Setting up packet filtering

• Task summary
Configuring Packet Filtering

Overview: Setting up 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. 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 Configuration utility 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.

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.

Task summary
By setting up some basic IP routing and configuring packet filtering, specific hosts on the internal VLAN
can connect to the internalVLAN's self IP address. These hosts can also use common Internet services such
as HTTP, HTTPS, DNS, FTP, and SSH. Traffic from all other hosts in the internal VLAN is rejected.

Task list
Enabling SNAT automap for internal and external VLANs
Creating a default gateway pool
Creating a forwarding virtual server
Enabling packet filtering on the BIG-IP system
Creating a packet filter rule

Enabling SNAT automap for internal and external VLANs

You can configure SNAT automapping on the BIG-IP system for internal and external VLANs.

1. On the Main tab, click Local Traffic > SNATs.

The SNAT List screen displays a list of existing SNATs.
2. Click Create.
3. Name the new SNAT.
4. From the Translation list, select automap.

158
 BIG-IP® TMOS®: Implementations

5. For the VLAN List setting, in the Available field, select external and external, and using the Move
button, move the VLANs to the Selected field.
6. Click Finished.

SNAT automapping on the BIG-IP system is configured for internal and external VLANs.

Creating a default gateway pool

Create a default gateway pool for the system to use to forward traffic.

1. On the Main tab, click Local Traffic > Pools.

The Pool List screen opens.
2. Click Create.
The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. For the Health Monitors setting, from the Available list, select the gateway_icmp monitor, and click
<< to move the monitor to the Active list.
5. Using the New Members setting, add each router that you want to include in the default gateway pool:
a) Type the IP address of a router in the Address field.
b) Type an asterisk * in the Service Port field, or select * All Services from the list.
c) Click Add.
6. Click Finished.

Creating a forwarding virtual server

A virtual server represents a destination IP address for application traffic.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. For the Destination setting:
a) For Type, select Network.
b) In the Address field, type the IP address [Link].
c) In the Mask field, type the netmask [Link].
5. From the Service Port list, select *All Ports.
6. In the Configuration area of the screen, from the Type list, select Forwarding (IP).
7. From the Protocol list, select *All Protocols.
8. From the VLAN and Tunnel Traffic list, select Enabled On.
9. For the VLAN and Tunnels setting, from the Available box, select internal, and click the Move button
to move the VLAN name to the Selected box.
10. In the Resources area of the screen, locate the Default Pool setting and select the pool you created
previously.
11. Click Finished.

You now have a destination IP address on the BIG-IP system for application traffic.

159
Configuring Packet Filtering

Enabling packet filtering on the BIG-IP system

Before creating a packet filtering rule, you must enable packet filtering.

1. On the Main tab, click Network > Packet Filters.

The Packet Filters screen opens.
2. From the Packet Filtering list, select Enabled.
3. From the Unhandled Packet Action list, select Accept.
4. Click Update.

Packet filtering is enabled.

Creating a packet filter rule

When implementing packet filtering, you need to create a packet filter rule.

1. On the Main tab, click Network > Packet Filters.

The Packet Filters screen opens.
2. Click Rules.
3. Click Create.
4. Name the rule.
5. From the Order list, select First.
6. From the Action list, select Reject.
7. From the Apply to VLAN list, select internal.
8. From the Logging list, select Enabled.
9. From the Filter Expression Method list, select Enter Expression Text.
10. In the Filter Expression field, type an expression.
For example: not dst port 80 and not dst port 443 and not dst port 53 and no dst
port 22 and not dst port 20 and not dst port 21 and not dst host <internal
self IP address>

Note: Replace <internal self IP address> with the actual self IP address of VLAN internal.

11. Click Finished.

The packet filter rule is available.

160
Chapter
18
Referencing an External File from within an iRule
Topics:

• Overview: Referencing an external file from

an iRule
• Task summary
• Implementation result
Referencing an External File from within an iRule

Overview: Referencing an external file from an iRule

Using the BIG-IP® Configuration utility or tmsh, you can import a 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 vent.
e Possible
uses for this feature are:
• To send a web page other than the page that the client requested. For example, you might want the
system to send a maintenance page instead of the requested page.
• To send an image.
• To use a file as a template and modify the file in the iRule before sending the file.
• To download policy information from an external server and merge that data with a locally-stored policy.
The file that an iRule accesses is known as an iFile, and can be any type of file, such as a binary file or a
text file. These files are read-only files.
This example shows an iRule that references an iFile named ifileURL, in partition Common:

ltm rule ifile_rule {

when HTTP_RESPONSE {
# return a list of iFiles in all partitions
set listifiles [ifile listall]

log local0. "list of ifiles: $listifiles"

# return the attributes of an iFile specified

array set array_attributes [ifile attributes "/Common/ifileURL"]

foreach {array attr} [array get array_attributes ] {

log local0. "$array : $attr"
}

# serve an iFile when http status is 404.

set file [ifile get "Common/ifileURL"]
log local0. "file: $ifile"
if { [HTTP::status] equals "404" } {
HTTP:Respond 200 ifile "/Common/ifileURL"

}
}
}

iRule commands for iFiles

This list shows the commands available for referencing an iFile within an iRule. All of these commands
return a string, except for the command [ifile attributes IFILENAME], which returns an array.

[ifile get IFILENAME]

[ifile listall]
[ifile attributes IFILENAME]
[ifile size IFILENAME]
[ifile last_updated_by IFILENAME]
[ifile last_update_time IFILENAME]
[ifile revision IFILENAME]

162
 BIG-IP® TMOS®: Implementations

[ifile checksum IFILENAME]

[ifile attributes IFILENAME]

Task summary
You can import an existing file to the BIG-IP® system, create an iFile that is based on the imported file,
and then write an iRule that returns the content of that file to a client system, based on an iRule event.

Task list
Importing a file to the BIG-IP system
Creating an iFile
Writing an iRule that references an iFile

Importing a file to the BIG-IP system

As a prerequisite, the file you want to import must reside on the BIG-IP® system you specify.
You can import a file from another system onto the BIG-IP system, as the first step in writing an iRule that
references that file.

1. On the Main tab, click System > File Management > iFile List > Import.
2. For the File Name setting, click Choose File.
The system opens a browse window so you can locate the file that you want to import to the BIG-IP
system.
3. Browse for the file and click Open.
The name of the file you select appears in the File Name setting.
4. In the Name field, type a new name for the file, such as [Link].
The new file name appears in the list of imported files.

The result of this task is that the file you selected now resides on the BIG-IP system.

Creating an iFile
As a prerequisite, ensure that the current administrative partition is set to the partition in which you want
the iFile to reside.
You perform this task to create an iFile that you can then reference in an iRule.

1. On the Main tab, click Local Traffic > iRules > iFile List.
2. Click Create.
3. In the Name field, type a new name for the iFile, such as ifileURL.
4. From the File Name list, select the name of the imported file object, such as [Link].
5. Click Finished.
The new iFile appears in the list of iFiles.

The result of this task is that you now have a file that an iRule can reference.

163
Referencing an External File from within an iRule

Writing an iRule that references an iFile

You perform this task to create an iRule that references an iFile.

Note: If the iFile resides in partition /Common, then specifying the partition when referencing the
iFile is optional. If the iFile resides in a partition other than /Common, such as /Partition_A,
you must include the partition name in the iFile path name within the iRule.

1. On the Main tab, click Local Traffic > iRules.

The iRule List screen opens, displaying any existing iRules.
2. Click Create.
The New iRule screen opens.
3. In the Name field, type a name between 1 and 31 characters, such as my_iRule.
4. In the Definition field, type the syntax for the iRule using Tool Command Language (Tcl) syntax.
For complete and detailed information iRules syntax, see the F5 Networks DevCentral web site
([Link]
5. Click Finished.
The new iRule appears in the list of iRules on the system.

Implementation result
You now have an iRule that accesses a file on the BIG-IP® system, based on a particular iRule event.

164
Chapter
19
Configuring Remote User Authentication and Authorization
Topics:

• Overview: Remote authentication and

authorization of BIG-IP user accounts
• Task summary
Configuring Remote User Authentication and Authorization

Overview: Remote authentication and authorization of BIG-IP user accounts

The BIG-IP® system includes a comprehensive solution for managing BIG-IP administrative accounts on
your network. With this solution, you can:
Use a remote server to store BIG-IP system user accounts.
The BIG-IP system includes support for using a remote authentication server to store BIG-IP system
user accounts. After creating BIG-IP system accounts on the remote server (using the server vendor's
instructions), you can configure the BIG-IP system to use remote user authentication and authorization
(access control) for that server type.
Assign group-based access.
The BIG-IP system includes an optional feature known as remote role groups. With the remote role
groups feature, you can use existing group definitions on the remote server to define the access control
properties for users in a group. This feature not only provides more granularity in assigning user
privileges, but also removes any need to duplicate remote user accounts on the BIG-IP system for the
purpose of assigning those privileges.
Propagate a set of authorization data to multiple BIG-IP systems.
The BIG-IP system includes a tool for propagating BIG-IP system configuration data to multiple BIG-IP
devices on the network. This tool is known as the Single Configuration File (SCF) feature.

Task summary
You can configure the BIG-IP® system to authorize user accounts that are stored on a remote authentication
server.

Important: If you configure access control settings for group-based accounts (using the remote
role groups feature), the BIG-IP system always applies those settings, rather than the default access
control settings, to group-based accounts.

The BIG-IP® system supports several types of authentication servers for storing BIG-IP system administrative
user accounts. The actual procedure you use to specify the type of remote server differs, depending on the
server type.

Task list
Specifying LDAP or Active Directory server information
Specifying client certificate LDAP server information
Specifying RADIUS server information
Specifying TACACS+ server information
Assigning access control properties to user groups
Saving access control settings to a file
Importing BIG-IP configuration data onto other BIG-IP systems

166
 BIG-IP® TMOS®: Implementations

Specifying LDAP or Active Directory server information

Before you begin:
• Verify that the BIG-IP® system user accounts have been created on the remote authentication server.
• Verify that the appropriate user groups, if any, are defined on the remote authentication server.
• If you want to verify the certificate of the authentication server, import one or more SSL certificates.
You can configure the BIG-IP system to use an LDAP or Microsoft® Windows® Active Directory ®server
for authenticating BIG-IP system user accounts, that is, traffic that passes through the management interface
(MGMT).

Important: The values you specify in this procedure for the Role, Partition Access, and Terminal
Access settings do not apply to group-based authorization. These values represent the default values
that the BIG-IP system applies to any user account that is not part of a remote role group.

1. On the Main tab, click System > Users.

2. On the menu bar, click Authentication.
3. Click Change.
4. From the User Directory list, select Remote - LDAP or Remote - Active Directory.
5. In the Host field, type the IP address of the remote server.
The route domain to which this address pertains must be route domain 0.
6. For the Port setting, retain the default port number (389) or type a new port number.
This number represents the port number that the BIG-IP system uses to access the remote server.
7. In the Remote Directory Tree field, type the file location (tree) of the user authentication database on
the LDAP or Active Directory server.
At minimum, you must specify a domain component (that is, dc=[value]).
8. For the Scope setting, retain the default value (Sub) or select a new value.
This setting specifies the level of the remote server database that the BIG-IP system should search for
user authentication.
9. For the Bind setting, specify a user ID login for the remote server:
a) In the DN field, type the distinguished name for the remote user ID.
b) In the Password field, type the password for the remote user ID.
c) In the Confirm field, re-type the password that you typed in the Password field.
10. To enable SSL-based authentication, from theSSL list select Enabled and, if necessary, configure these
settings:
a) From the SSL CA Certificate list, select the name of a chain certificate, that is, the third-party CA
or self-signed certificate that normally resides on the remote authentication server.
b) From the SSL Client Key list, select the name of the client SSL key.
Use this setting only when the remote server requires that the client present a certificate.
c) From the SSL Client Certificate list, select the name of the client SSL certificate.
Use this setting only if the remote server requires that the client present a certificate.

11. From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP
user accounts authenticated on the remote server:

167
Configuring Remote User Authentication and Authorization

12. From the Partition Access list, select the default administrative partition that all remotely-authenticated
BIG-IP user accounts can access.
13. From the Terminal Access list, select one of the following as the default terminal access for
remotely-authenticated user accounts:
Options Description
Disabled Choose this option when you do not want the remotely-stored user accounts
to have terminal access to the BIG-IP system.
tmsh Choose this option when you want the remotely-stored user accounts to have
only tmsh access to the BIG-IP system.
Advanced Shell Choose this option when you want the remotely-stored user accounts to have
access to the BIG-IP system using the advanced shell (at the command
prompt).

You can only select Advanced Shell when the Role setting is set to Administrator or Resource
Administrator.
14. Click Finished.

You can now authenticate administrative traffic for user accounts that are stored on a remote LDAP or
Active Directory server. If you have no need to configure group-based user authorization, your configuration
tasks are complete.

Specifying client certificate LDAP server information

Verify that the required user accounts for the BIG-IP® system exist on the remote authentication server.
For authenticating BIG-IP system user accounts (that is, traffic that passes through the management interface
[MGMT]), you can configure the BIG-IP system to authenticate certificates issued by a certificate authority's
Online Certificate Status Protocol (OCSP) responder.

Important: The values you specify in this procedure for the Role, Partition Access, and Terminal
Access settings do not apply to group-based authorization. These values represent the default values
or locally configured user accounts (which override the default role) that the BIG-IP system applies
to any user account that is not part of a remote role group.

1. On the Main tab, click System > File Management > Apache Certificate List > Import, browse for
the certificate file to import, type a name, and click Import.
The certificate will be added to the Apache Certificate list.
2. On the Main tab, click System > Users.
3. On the menu bar, click Authentication.
4. Click Change.
5. From the User Directory list, select Remote - ClientCert LDAP.
6. In the Host field, type the IP address of the remote server.
The route domain to which this address pertains must be route domain 0.
7. For the Port setting, retain the default port number (389) or type a new port number.
This number represents the port number that the BIG-IP system uses to access the remote server.
8. In the Remote Directory Tree field, type the file location (tree) of the user authentication database on
the client certificate server.
At minimum, you must specify a domain component (that is, dc=[value]).

168
 BIG-IP® TMOS®: Implementations

9. For the Scope setting, retain the default value (Sub) or select a new value.
This setting specifies the level of the remote server database that the BIG-IP system should search for
user authentication.
10. For the Bind setting, specify a user ID login for the remote server:
a) In the DN field, type the distinguished name for the remote user ID.
b) In the Password field, type the password for the remote user ID.
c) In the Confirm field, re-type the password that you typed in the Password field.
11. To enable SSL-based authentication, from theSSL list select Enabled and, if necessary, configure these
settings:
a) From the SSL CA Certificate list, select the name of a chain certificate; that is, the third-party CA
or self-signed certificate that normally resides on the remote authentication server.
b) From the SSL Client Key list, select the name of the client SSL key.
Use this setting only when the remote server requires that the client present a certificate.
c) From the SSL Client Certificate list, select the name of the client SSL certificate.
Use this setting only if the remote server requires that the client present a certificate.

12. In the CA Certificate field, type the absolute folder path of apache-ssl-cert fileobject for the
CA signing authority.
The absolute folder path is /Common/<folder path>/<certificate name>. To determine the
absolute folder path of the apache-ssl-cert fileobject, click System > File Management >
Apache Certificate List and note the target certificate's partition and path.

Important: Apache certificates can only be stored within /Common.

/>
13. In the Login Name field, type an LDAP search prefix that will contain the distinguished name (DN)
from the user certificate, such as CN.
This specifies the LDAP attribute to be used as a login name. The default is disabled.
14. In the Login LDAP Attribute field, type the account name for the LDAP server.
The value for this option is normally the user ID. However, if the server is a Microsoft® Windows®
Active Directory®server, the value must be the account name sAMAccountName (case-sensitive). The
default value is none.
15. In the Login Filter field, type the LDAP attribute that contains the short name of the user.
This specifies the filter to be applied on the common name (CN) of the client certificate and usually this
is the user ID or sAMAccountName. The filter is a regular expression used to extract required information
from the CN of the client certificate that is matched against the LDAP search results. The default is
disabled.
16. For the Depth setting, retain the default value (10) or type a new value for verification depth.
17. From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP
system user accounts authenticated on the remote server.
18. From the Partition Access list, select the default administrative partition that all remotely-authenticated
BIG-IP system user accounts can access.
19. From the Terminal Access list, select either of these as the default terminal access option for
remotely-authenticated user accounts:

169
Configuring Remote User Authentication and Authorization

Options Description
Disabled Choose this option when you do not want the remotely-stored user accounts
to have terminal access to the BIG-IP system.
tmsh Choose this option when you want the remotely-stored user accounts to have
only tmsh access to the BIG-IP system.

20. Click Finished.

You can now authenticate administrative traffic for user accounts that are stored on a remote client certificate
server. If you have no need to configure group-based user authorization, your configuration tasks are
complete.

Specifying RADIUS server information

Prerequisites:
• Verify that the BIG-IP® system user accounts have been created on the remote authentication server.
• Verify that the appropriate user groups, if any, are defined on the remote authentication server.
You can configure the BIG-IP system to use a RADIUS server for authenticating BIG-IP system user
accounts, that is, traffic that passes through the management interface (MGMT).

Important: The values you specify in this procedure for the Role, Partition Access, and Terminal
Access settings do not apply to group-based authorization. These values represent the default values
that the BIG-IP system applies to any user account that is not part of a remote role group.

1. On the Main tab, click System > Users.

2. On the menu bar, click Authentication.
3. Click Change.
4. From the User Directory list, select Remote - RADIUS.
5. From the Server Configuration list, select one of the following options:
Options Description
Primary Only Specifies that you are using a single RADIUS server only for user
authentication.
Primary and Secondary Specifies that you are using a primary RADIUS server plus a
secondary RADIUS server, in case the primary server becomes
unavailable.

6. For the Primary setting:

a) In the Host field, type the name of the primary RADIUS server.
The route domain with which this host is associated must be route domain 0.
b) In the Secret field, type the password for access to the primary RADIUS server.
c) In the Confirm field, re-type the RADIUS secret.
7. If you set the Server Configuration setting to Primary and Secondary, then for the Secondary setting:
a) In the Host field, type the name of the secondary RADIUS server.
The route domain with which this host is associated must be route domain 0.
b) In the Secret field, type the password for access to the secondary RADIUS server.

170
 BIG-IP® TMOS®: Implementations

c) In the Confirm field, re-type the RADIUS secret.

8. From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP
user accounts stored on the remote server:
9. From the Partition Access list, select the administrative partition that all remotely-authenticated BIG-IP
user accounts can access.
10. From the Terminal Access list, select one of the following options as the default terminal access for
remotely-authenticated user accounts:
Options Description
Disabled Specifies that you do not want the remotely-stored user accounts to have
terminal access to the BIG-IP system.
tmsh Specifies that when you want the remotely-stored user accounts to have only
tmsh access to the BIG-IP system.

Advanced Shell Specifies that when you want the remotely-stored user accounts to have
access to the BIG-IP system using the advanced shell (at the system prompt).

You can select Advanced Shell only when the Role setting is set to Administrator or Resource
Administrator.
11. Click Finished.

You can now authenticate administrative traffic for BIG-IP system user accounts that are stored on a remote
RADIUS server. If you have no need to configure group-based user authorization, your configuration tasks
are complete.

Specifying TACACS+ server information

Prerequisites:
• Verify that the BIG-IP® system user accounts have been created on the remote authentication server.
• Verify that the appropriate user groups, if any, are defined on the remote authentication server.
You can configure the BIG-IP system to use a TACACS+ server for authenticating BIG-IP system user
accounts, that is, traffic that passes through the management interface (MGMT).

Important: The values you specify in this procedure for the Role, Partition Access, and Terminal
Access settings do not apply to group-based authorization. These values represent the default values
that the BIG-IP system applies to any user account that is not part of a remote role group.

1. On the Main tab, click System > Users.

2. On the menu bar, click Authentication.
3. Click Change.
4. From the User Directory list, select Remote - TACACS+.
5. For the Servers setting, type an IP address for the remote TACACS+ server.
The route domain to which this address pertains must be route domain 0.
6. Click Add.
The IP address for the remote TACACS+ server appears in the Servers list.
7. In the Secret field, type the password for access to the TACACS+ server.
8. In the Confirm Secret field, re-type the TACACS+ secret.
9. From the Encryption list, select an encryption option:

171
Configuring Remote User Authentication and Authorization

Options Description
Enabled Specifies that the system encrypts the TACACS+ packets.
Disabled Specifies that the system sends unencrypted TACACS+ packets.

10. In the Service Name field, type the name of the service that the user is requesting to be authenticated
to use (usually ppp).
Specifying the service causes the TACACS+ server to behave differently for different types of
authentication requests. Examples of service names that you can specify are:ppp, slip, arap, shell,
tty-daemon, connection, system, and firewall.

11. In the Protocol Name field, type the name of the protocol associated with the value specified in the
Service Name field.
This value is usually ip. Examples of protocol names that you can specify are: ip, lcp, ipx, atalk,
vines, lat, xremote, tn3270, telnet, rlogin, pad, vpdn, ftp, http, deccp, osicp, and unknown.

12. From the Role list, select the user role that you want the BIG-IP system to assign by default to all BIG-IP
user accounts stored on the remote server:
13. From the Partition Access list, select the default administrative partition that all remotely-authenticated
BIG-IP user accounts can access.
14. From the Terminal Access list, select one of the following options as the default terminal access for
remotely-authenticated user accounts:
Options Description
Disabled Specifies that the remotely-stored user accounts have no terminal access
to the BIG-IP system.
tmsh Specifies that the remotely-stored user accounts have only tmsh access to
the BIG-IP system.
Advanced Shell Specifies that the remotely-stored user accounts have access to the BIG-IP
system using the advanced shell (at the command prompt).

You can select Advanced Shell only when the Role setting is set to Administrator or Resource
Administrator.
15. Click Finished.

You can now authenticate administrative traffic for BIG-IP system user accounts that are stored on a remote
TACACS+ server. If you have no need to configure group-based user authorization, your configuration
tasks are complete.

Assigning access control properties to user groups

On the BIG-IP® system, you can configure access control properties (privileges) for existing user groups
that are defined on a remote authentication server. For example, if the configuration of a remote LDAP
authentication server includes the attribute string
memberOF=cn=BigIPOperatorsGroup,cn=users,dc=dev,dc=net, you can assign a specific set of
access control properties to all user accounts in the group BigIPOperatorsGroup.

1. On the Main tab, click System > Users.

2. On the menu bar, click Remote Role Groups.
3. Click Create.
4. In the Group Name field, type the group name that is defined on the remote authentication server.

172
 BIG-IP® TMOS®: Implementations

An example of a group name is BigIPOperatorsGroup.

5. In the Line Order field, type a number.
An example of a line order is 1.
6. In the Attribute String field, type an attribute.
An example of an attribute string is
memberOF=cn=BigIPOperatorsGroup,cn=users,dc=dev,dc=net.
The BIG-IP system attempts to match this attribute with an attribute on the remote authentication server.
On finding a match, the BIG-IP system applies the access control settings defined here to the users in
that group. If a match is not found, the system applies the default access control settings to all
remotely-stored user accounts (excluding any user account for which access control settings are
individually configured).
7. From the Remote Access list, select a value.
Options Description
Enabled Choose this value if you want to enable remote console access for the
defined user group.
Disabled Choose this value if you want to disable remote console access for the
defined user group.

8. From the Assigned Role list, select a user role for the remote user group.
9. From the Partition Access list, select an administrative partition value.
Options Description
All Choose this value to give users in the defined group access to their authorized
objects in all partitions on the BIG-IP system.
partition_name Choose a specific partition name to give users in the defined group access to
that partition only.
Common Choose this value to give users in the defined group access to partition
Common only.

10. From the Terminal Access list, select the type of command-line access you want to grant users in the
group, if any.
11. Click Finished.

The user group that you specified now has a set of access control properties assigned to it.

Saving access control settings to a file

You can save the running configuration of the system, including all settings for remote user authentication
and authorization, in a flat, text file with a specified name and the extension .scf.

1. On the BIG-IP® system, access a command-line prompt.

2. At the prompt, open the Traffic Management Shell by typing the command tmsh.
3. Type sys save filename.
sys save myConfiguration053107 creates the file [Link] in the
var/local/scf directory.
sys save /config/myConfiguration creates the file [Link] in the /config
directory.

173
Configuring Remote User Authentication and Authorization

You can now import this file onto other BIG-IP devices on the network.

Importing BIG-IP configuration data onto other BIG-IP systems

You can use the tmsh sys load command to import a single configuration file (SCF), including access
control data, onto other BIG-IP® devices on the network.

Note: This task is optional.

1. On the BIG-IP system on which you created the SCF, access a command-line prompt.
2. Copy the SCF that you previously created to a location on your network that you can access from the
system that you want to configure.
3. Edit the SCF to reflect the management routing and special passwords of the BIG-IP system that you
want to configure:
a) Open the SCF in an editor.
b) Where necessary, change the values of the management IP address, network mask, management
default route, self IP addresses, virtual server IP addresses, routes, default routes, and host name
fields to the values for the new system.
c) If necessary, change the passwords for the root and admin accounts using the command user
name password none newpassword password.

Important: When configuring a unit that is part of a redundant system configuration and
that is using the SCF from the peer unit, do not modify the root and admin accounts. These
accounts must be identical on both units of the redundant system.

d) Save the edited SCF.

4. On the BIG-IP system that you want to configure, open the Traffic Management Shell by typing the
command tmsh.
5. Type sys load scf_filename.
sys load [Link] saves a backup of the running configuration in the
/var/local/scf directory, and then resets the running configuration with the configuration contained
in the SCF you are loading.

174
Chapter
20
Configuring Administrative Partitions to Control User
Access
Topics:

• Overview: Administrative partitions for user

access control
• Task summary
Configuring Administrative Partitions to Control User Access

Overview: Administrative partitions for user access control

The BIG-IP® system includes a powerful authorization feature known as administrative partitions. Using
the administrative partitions feature, you ensure that BIG-IP system grants administrative users exactly the
right type and amount of access to BIG-IP system resources. As a result, you can tailor user access to
resources to exactly fit the needs of your organization.

Task summary
There are two main tasks for controlling user access to BIG-IP® system objects.

Task list
Creating an administrative partition
Configuring user access to a partition

Creating an administrative partition

An administrative partition creates an access control boundary for users and applications.

1. On the Main tab, expand System and click Users.

The Users List screen opens.
2. On the menu bar, click Partition List.
3. Click Create.
The New Partition screen opens.
4. Name the partition.
5. (Optional) Type a description in the Description field.
6. For the Device Group setting, choose an action:
Action Result
Retain the Choose this option if you want the folder corresponding to this partition to inherit
default value. the value of the device group attribute from folder root.
Clear the check Choose this option if you do not want the folder corresponding to this partition to
box and select inherit the value of the device group attribute from folder root.
the name of a
device group.

7. For the Traffic Group setting, choose an action:

Action Result
Retain the default Choose this option if you want the folder corresponding to this partition to inherit
value. the value of the traffic group attribute from folder root.
Clear the check Choose this option if you do not want the folder corresponding to this partition to
box and select the inherit the value of the traffic group attribute from folder root.

176
 BIG-IP® TMOS®: Implementations

Action Result
name of a traffic
group.

8. Click Finished.

The new partition appears in the partition list.

Configuring user access to a partition

You can configure user access to a partition either when you first create the user account or when you
modify the user account properties. This procedure shows how to configure partition access to an existing
user account.

1. On the Main tab, click System > Users.

2. In the User Name column, click the user account name.
3. To grant an access level other than No Access, use the Role list to select a user role.
4. From the Partition Access list, select a partition name.
You can select a single partition name, or All.
5. Click Update.

177
Configuring Administrative Partitions to Control User Access

178
Chapter
21
Implementing BIG-IP Local Traffic Manager on a vCMP
System
Topics:

• Overview: Initial vCMP setup

• Task summary
• Viewing host properties for slots
Implementing BIG-IP Local Traffic Manager on a vCMP System

Overview: Initial vCMP setup

Virtual Clustered Multi-Processing (vCMP) is a feature of the BIG-IP® system that makes it possible for
you to run multiple instances of the BIG-IP® software on a single hardware platform.
Using the following implementation, you can create one guest on a vCMP™ system, and then, within the
guest, configure the basic Local Traffic Manager™ objects for processing HTTP application traffic: a pool,
an HTTP profile, and a standard virtual server. A vCMP guest is a virtual BIG-IP® device.

Task summary
Before implementing the BIG-IP® LTM® module within a vCMP™ guest, verify that you have completed
the tasks from the appropriate Viprion Platform Guide. As part of the platform installation, you will have
assigned an IP address that provides access to the primary cluster and then licensed the platform.
The tasks involved in implementing the BIG-IP® LTM® module within a vCMP™ guest consist of configuring
the vCMP host, creating, provisioning, and deploying a guest, and finally using the BIG-IP® LTM®
Configuration Utility to create the required TMOS® and LTM objects within the guest.

Task list
Creating a vCMP guest
Setting a vCMP guest to the Deployed state
Provisioning a BIG-IP module within a guest
Creating a custom HTTP profile
Creating a pool to manage HTTP traffic
Creating a virtual server to manage HTTP traffic

Creating a vCMP guest

To create a vCMP® guest, you need a VIPRION® chassis system configured with a floating cluster
management IP address, some base network objects such as trunks and VLANs, and you must license and
provision the system to run the vCMP feature.
You create a vCMP guest when you want to configure and run one or more BIG-IP® modules as though
the modules were running together on their own BIG-IP device. For example, you can create a guest that
runs BIG-IP® Local Traffic Manager™ and BIG-IP® Global Traffic Manager™. A guest can run on one
available slot or all available slots of a chassis.

Note: This procedure creates a guest in Bridged mode.

Note: When creating a guest, if you see an error message such as Insufficient disk space
on /shared/vmdisks. Need 24354M additional space., you must delete existing
unattached virtual disks until you have freed up that amount of disk space.

1. Use a browser to log in to the VIPRION® chassis's management IP address.

180
 BIG-IP® TMOS®: Implementations

This logs you in to the floating IP address for the cluster.

2. On the Main tab, click vCMP > Guest List.
3. Click Create.
4. From the Properties list, select Advanced.
5. In the Name field, type a name for the guest.
6. In the Host Name field, type the host name of the BIG-IP system.
Assign a fully-qualified domain name (FQDN). If you assign a name that is not an FQDN, the system
might display an error message. If you leave this field blank, the system assigns the name
[Link].

7. From the Number of Slots list, select either Single Slot or All Slots.
This causes the guest to reside on one slot or to span all slots. Note that once you configure a guest to
span all slots, you cannot change this value later to Single Slot, unless you first change the state of the
guest to Configured. Also note that if you decide to reconfigure an all slot guest to a single slot guest,
you cannot specify on which available single slot the guest will reside.
8. From the Management Network list, select Bridged.
9. For the Cluster IP Address setting, fill in the required information:
a) In the IP Address field, type a unique management IP address that you want to assign to the guest.
You use this IP address to access the guest when you want to manage a module running within the
guest.
b) In the Network Mask field, type the network mask for the cluster IP address.
c) In the Management Route field, type a gateway address for the cluster IP address.
10. From the Initial Image list, select an ISO image file for installing TMOS® software and the BIG-IP
license onto the guest's virtual disk. The license associated with the selected image provides access to
the correct BIG-IP modules.
11. In the Virtual Disk list, retain the default value of None.
The BIG-IP system creates a virtual disk with a default name (the guest name plus the [Link], such
as [Link]). Note that if an unattached virtual disk file with that default name already exists, the
system displays a message, and you must manually attach the virtual disk. You can do this using the
tmsh command line interface, or use the Configuration utility to view and select from a list of available
unattached virtual disks.
12. For the VLAN List setting, select both an internal and an external VLAN name from the Available list,
and use the Move button to move the VLAN names to the Selected list.
13. From the Requested State list, select Provisioned.
This allocates all necessary resources to the guest, such as CPU cores, virtual disk, and so on.
14. Click Finish.

After clicking Finished, wait while the system installs the selected ISO image onto the guest's virtual disk.
When this process is complete, you can deploy the guest.

Note: You can also skip the Provisioned state and instead go straight to the Deployed state if you
are confident of your guest configuration. Provisioning first and then deploying makes it more
straightforward to make changes to the slots to which your guests are allocated if you find you need
to make changes.

181
Implementing BIG-IP Local Traffic Manager on a vCMP System

Setting a vCMP guest to the Deployed state

Until you deploy a vCMP® guest, your vCMP VIPRION has no medium for provisioning and running the
BIG-IP® modules that you can use to process traffic.

1. Ensure that you are still logged in to the vCMP host using the BIG-IP system's cluster IP address.
2. On the Main tab, click vCMP > Guest List.
3. In the Name column, click the name of the vCMP guest that you want to deploy.
4. From the Requested State list, select either Provisioned or Deployed.
5. Click Update.

After moving a vCMP guest to the Deployed state, wait while the guest boots and becomes accessible.
Then, you can log into the vCMP guest to provision specific BIG-IP modules.

Provisioning a BIG-IP module within a guest

Before you can access a guest to provision BIG-IP® modules, the vCMP® guest must be in the Deployed
state.
You determine which BIG-IP modules run within a guest by provisioning the modules. For example, if you
want guestA to run LTM® and GTM™, log into guestA and provision it with LTM and GTM. If you want
™
guestB to run LTM and ASM , log into guestB and provision it with BIG-IP LTM and BIG-IP ASM.
Bear in mind that guests inherit the licenses of the vCMP host on which they were created, so any BIG-IP
modules that you want to provision on a guest must be included in the license you installed with the vCMP
host.

Note: This procedure applies to guests in Bridged mode only. Guests in isolated mode can be
accessed only using vconsole and tmsh.

1. Use a browser and the management IP address that you configured for the guest to log in to the guest.
If the system prompts you to run the Setup Utility, do not. Instead, complete this task to produce an
initial configuration better suited for a vCMP guest.
The BIG-IP Configuration utility opens so that you can configure the guest.
2. On the Main tab, click System > Resource Provisioning.
3. In the Resource Provisioning (Licensed Modules) area, from the Local Traffic (LTM) list, select
Minimal, Nominal, or Dedicated, depending on your needs.
4. Click Update.

After provisioning the module from within the guest, create self IP addresses and assign a vCMP host
VLAN
to each one. The vCMP host VLANs that you assign to these self IP addresses are the VLANs you created
before creating the guest.

Creating a custom HTTP profile

Before configuring Local Traffic Manager™ (LTM®), verify that the guest is in the Deployed state.
An HTTP profile defines the way that you want the BIG-IP® system to manage HTTP traffic.

182
 BIG-IP® TMOS®: Implementations

Note: With other HTTP profile types (HTTP Compression and Web Acceleration), you can configure
compression and cache settings, as required. Use of these profile types is optional.

1. Use a browser and the management IP address that you configured for the guest to log in to the guest.
The BIG-IP Configuration utility opens so that you can configure the guest.
2. On the Main tab, click Local Traffic > Profiles > Services > HTTP.
The HTTP profile list screen opens.
3. Click Create.
The New HTTP Profile screen opens.
4. In the Name field, type a name for the profile.
5. From the Parent Profile list, retain the default value, http.
6. Select the Custom check box.
The fields in the Settings area become available for revision.
7. Modify or retain the settings to suit your needs.
8. Click Finished.

The custom HTTP profile appears in the list of HTTP profiles.

Creating a pool to manage HTTP traffic

You can create a pool to manage HTTP connections.

1. On the Main tab, click Local Traffic > Pools.

The Pool List screen opens.
2. Click Create.
The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. For the Health Monitors setting, from the Available list, select the http monitor, and click << to move
the monitor to the Active list.
5. From the Load Balancing Method list, select how the system distributes traffic to members of this
pool.
The default is Round Robin.
6. For the Priority Group Activation setting, specify how to handle priority groups:
• Select Disabled to disable priority groups. This is the default option.
• Select Less than, and in the Available Members field, type the minimum number of members that
must remain available in each priority group in order for traffic to remain confined to that group.

7. Using the New Members setting, add each resource that you want to include in the pool:
a) Type an IP address in the Address field, or select a node address from the Node List.
b) Type 80 in the Service Port field, or select HTTP from the list.
c) (Optional) Type a priority number in the Priority field.
d) Click Add.
8. Click Finished.

The new pool appears in the Pools list.

183
Implementing BIG-IP Local Traffic Manager on a vCMP System

Creating a virtual server to manage HTTP traffic

You can create a virtual server to manage HTTP traffic as either a host virtual server or a network virtual
server.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the Create button.
The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. Specify the Destination setting, using the Address field; type the IP address you want to use for the
virtual server.
The IP address you type must be available and not in the loopback network.
5. In the Service Port field, type 80, or select HTTP from the list.
6. From the HTTP Profile list, select http.
7. In the Resources area of the screen, from the Default Pool list, select a pool name.
8. Click Finished.

The HTTP virtual server appears in the list of existing virtual servers on the Virtual Server List screen.

Viewing host properties for slots

You must have created at least one vCMP® guest on the system to view host properties.
Use the BIG-IP® Configuration utility to view the host properties for all slots on the system or for a single
slot. The host properties that you can view are:
• The state of each guest
• The slot numbers on which each guest runs
• The number of CPU cores allocated to each guest

1. Use a browser to log in to the VIPRION® chassis's management IP address.

This logs you in to the floating IP address for the cluster.
2. On the Main tab, click vCMP > Host Properties.
3. View host properties for all slots, or in the upper right corner of the screen, from the View list, select a
slot number.

The screen displays the host properties for the chosen slots.

184
Chapter
22
Working with Single Configuration Files
Topics:

• Overview: Working with single configuration

files
• tmsh commands for single configuration files
• Task summary
Working with Single Configuration Files

Overview: Working with single configuration files

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 local traffic management and TMOS® configuration of the BIG-IP system. This figure 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 {
[Link]:https{}
[Link]:https{}
}
}

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.

tmsh commands for single configuration files

You use the tmsh utility to perform the basic management of a single configuration file (SCF). This table
contains an overview of the commands to accomplish this.

tmsh command Usage

save sys config file [filename] Use this command to save a copy of the currently
running configuration to an SCF. It is important to
note that saving a configuration to an SCF does not
affect the running or stored configuration of the
BIG-IP® system on which you run the command.
load sys config file [filename] Use this command to replace or restore an SCF with
a saved configuration. When you use this command,
the system saves any previously running
configuration to the directory /var/local/scf/,
by default.
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.

186
 BIG-IP® TMOS®: Implementations

Task summary
You can perform three main tasks with respect to single configuration files.

Task list
Creating and saving an SCF
Loading an SCF onto a target BIG-IP system
Using an SCF to restore a BIG-IP system configuration

Creating and saving an SCF

Use this procedure to create and save a single configuration file.

1. Access the tmsh utility.

2. Use the following syntax: save sys config file [filename]
If you include the .scf extension in the file name, the system does not add an additional file extension.
If you create an SCF file twice (on two different occasions), you can compare the contents of the two
files.

This procedure causes 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.

Loading an SCF onto a target BIG-IP system

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.

Note: To successfully load a configuration you have replicated, ensure that no line of the
configuration is longer than 4096 characters. If there are more than 4096 characters in a single
line, the system reverts to the previous running configuration.

1. On the target BIG-IP system, load the saved SCF file by typing the following command: tmsh load
sys config file [filename]
The tmsh utility first saves the system’s stored configuration in a backup file (named
/var/local/scf/[Link]), and then uses the configuration stored in the SCF that you are loading.
2. Use a text editor to open the SCF and edit any data that is unique to the target BIG-IP system, such as
the management IP address.
3. Save the SCF to the target BIG-IP system by typing the following command: sys save config file
[filename]

187
Working with Single Configuration Files

If a backup SCF already exists, the tmsh utility appends a number to the name of the existing backup
file, and then creates a new backup file. Thus:
• The first time the system backs up the running configuration during a load operation, the system
names the backup file /var/local/scf/[Link].
• The next time the system backs up the running configuration, the system renames the file from
/var/local/scf/[Link] to /var/local/scf/[Link] and creates a new file
named /var/local/scf/[Link].
• If you run the load command a third time, the system renames the file from
/var/local/scf/[Link] to /var/local/scf/[Link], renames the file
/var/local/scf/[Link] to /var/local/scf/[Link], and once again creates a
new file named /var/local/scf/[Link].

Using an SCF to restore a BIG-IP system configuration

You can use an SCF to restore a BIG-IP® system configuration. 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, perform this step.

1. From a console window, access the tmsh prompt.

2. Choose one of these options.
Options Description
Restore a system to the Type the command tmsh load sys config default. This command
factory default retains the management IP and the assignedroot and administrator passwords.
configuration When you use this command, the system first saves the running configuration
in the [Link] file and then resets the local traffic management and the
operating system configuration to the factory default settings by loading the
SCF, /defaults/[Link].
Restore a system with Type the command tmsh load sys config file [filename]. When
values defined in the you use this command, the system first saves the running configuration in
specified SCF the [Link] file, and then resets the running configuration to the values
contained in the specified SCF. You must run the save sys config
partitions all command to save the running configuration in the stored
configuration files.

188
Chapter
23
Configuring Performance Monitoring
Topics:

• Overview: Configuring performance

monitoring
• Task summary
• Implementation result
Configuring Performance Monitoring

Overview: Configuring performance monitoring

You can configure the BIG-IP® system to poll internal data sources and send data samples to an sFlow
receiver. (Currently, the BIG-IP system supports only counter sampling on only VLANs and interfaces.)
You can use the collected data to analyze the performance of the BIG-IP system.

Task summary
Perform this task to configure performance monitoring of the BIG-IP® system using an sFlow® device.

Adding a performance monitoring sFlow receiver

Gather the IP addresses of the sFlow® receivers that you want to add to the BIG-IP® system configuration.
You can use IPv4 and IPv6 addresses.

Note: You can add an sFlow receiver to the BIG-IP system, only if you are assigned either the
Resource Administrator or Administrator user role.

Add an sFlow receiver to the BIG-IP system when you want to use the receiver to monitor system
performance.

Important: When multiple sFlow receivers are configured on the BIG-IP system, only the lowest,
non-zero Poll Interval setting is used when polling for all configured sFlow receivers. Therefore,
if you delete the sFlow receiver with the lowest, non-zero poll interval, the system computes a new
poll interval based on the configured sFlow receivers, and uses that polling interval for all configured
sFlow receivers.

1. On the Main tab, click System > Performance > sFlow.

The sFlow screen opens.
2. Click Add.
The New sFlow Receiver screen opens.
3. In the Name field, type a name for the sFlow receiver.
4. In the Address field, type the IPv4 or IPv6 address on which the sFlow receiver listens for UDP
datagrams.
5. Click Finished.

sFlow counters and data

This table names and categorizes the sFlow® counters and informational data that theBIG-IP® system sends
to sFlow receivers. The table also includes the source of the data and an example value.

Name and type Source Example value

in_vlan (vlan) VLAN tag 1234 (This value is an integer
between 0 [zero] and 4095.)

190
 BIG-IP® TMOS®: Implementations

Name and type Source Example value

octets (vlan) ifc_stats.hc_in_octets + 107777746
ifc_stats.hc_out_octets
ucastPkts (vlan) ifc_stats.hc_in_ucast_pkts + 202314
ifc_stats.hc_out_ucast_pkts
multicastPkts (vlan) ifc_stats.hc_in_multicast_pkts + 12
ifc_stats.hc_out_multicast_pkts
broadcastPkts (vlan) ifc_stats.hc_in_broadcast_pkts + 6
ifc_stats.hc_out_broadcast_pkts
discards (vlan) ifc_stats.hc_in_discards + 0
ifc_stats.hc_out_discards
ifIndex (interface) interface_stat.if_index 64 (You can map this value to an
interface name by using snmpwalk
to query ifTable, for example,
snmpwalk -v 2c -c public
localhost ifTable.)

networkType (interface) Enumeration derived from the 6

IANAifType-MIB
([Link]
ifSpeed (interface) Media speed of the network interface 1000000000 (This value is in bits
per second.)
ifDirection (interface) Derived from MAU MIB (RFC 2668) 0 = 1
unknown, 1=full-duplex, 2=half-duplex, 3
= in, 4=out
ifStatus (interface) Bit field with the following bits assigned: 3
bit 0 = ifAdminStatus (0 = down, 1 = up),
bit 1 = ifOperStatus (0 = down, 1 = up)
ifInOctets (interface) interface_stat.counters.bytes_in 9501109483
ifInUcastPkts (interface) interface_stat.counters.pkts_in - 14373120
interface_stat.counters.mcast_in
ifInMulticastPkts interface_stat.counters.mcast_in 72
(interface)
ifInBroadcastPkts interface_stat.rx_broadcast 211
(interface)
ifInDiscards (interface) interface_stat.counters.drops_in 13
ifInErrors (interface) interface_stat.counters.errors_in 0
ifInUnknownProtos Not implemented This value will always be 0 (zero).
(interface)
ifOutOctets (interface) interface_stat.counters.bytes_out 9655448619
ifOutUcastPkts interface_stat.counters.pkts_out - 10838396
(interface) interface_stat.counters.mcast_out
ifOutMulticastPkts interface_stat.counters.mcast_out 72
(interface)

191
Configuring Performance Monitoring

Name and type Source Example value

ifOutBroadcastPkts interface_stat.tx_broadcast 211
(interface)
ifOutDiscards (interface) interface_stat.counters.drops_out 8
ifOutErrors (interface) interface_stat.counters.errors_out 0
ifPromiscuousMode Not implemented This value will always be 0 (zero).
(interface)
5s_cpu (processor) tmm_stat.cpu_usage_5secs .81 (This value is the average tmm
CPU usage in the last five
seconds.)
1m_cpu (processor) tmm_stat.cpu_usage_1min (This value is the average tmm
CPU usage in the last one minute.)
5m_cpu (processor) tmm_stat.cpu_usage_5mins (This value is the average tmm
CPU usage in the last five
minutes.)
total_memory_bytes tmm_stat.memory_total 5561647104 (This value is the total
(processor) tmm memory in bytes.)
free_memory_bytes tmm_stat.memory_total - 5363754680 (This value is the free
(processor) tmm_stat.memory_used (free tmm memory tmm memory in bytes.)
in bytes)

Implementation result
You now have an implementation in which theBIG-IP® system periodically sends data samples to ansFlow®
receiver.

192
Chapter
24
SNMP Agent Configuration
Topics:

• Overview: Configuration the SNMP agent

• Task summary
• Implementation result
SNMP Agent Configuration

Overview: Configuration the SNMP agent

You can use the industry-standard SNMP protocol to manage BIG-IP® devices on a network. To do this,
you must configure the SNMP agent on the BIG-IP system. The primary tasks in configuring the SNMP
agent are configuring client access to the SNMP agent, and 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.
The way to modify this default access level is by using the Configuration utility to grant read/write access
to either a community (for SNMP v1 and v2c) or a user (SNMP v3), for a given OID. 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.

Task summary
To configure SNMP on the BIG-IP® system, you must perform a series of small tasks.

Task list
Specifying BIG-IP system information
Configuring client access
Controlling access to SNMP data

Specifying BIG-IP system information

You can use the Configuration utility to specify some basic system information.

1. On the Main tab, click System > SNMP.

2. In the Global Setup area, in the Contact Information field, type contact information such as a name
and email address.
The contact information is a MIB-II simple string variable defined by almost all SNMP machines. The
contact name usually contains a user name, as well as an email address.
3. In the Machine Location field, type the location of the system, such as Network Closet 1.
The machine location is a MIB-II variable that almost all machines support. It is a simple string that
defines the location of the machine.

Configuring client access

An SNMP client refers to any system running the SNMP manager software for the purpose of remotely
managing the BIG-IP® system. To set up client access to the BIG-IP system, you specify the IP or network

194
 BIG-IP® TMOS®: Implementations

addresses (with netmask as required) from which the SNMP agent can accept requests. (By default, SNMP
is enabled only for the BIG-IP system loopback interface, [Link].)

Allowing access to the SNMP agent

Use this procedure to allow client access to an SNMP agent.

1. On the Main tab, click System > SNMP.

2. For the Client Allow List setting, Type option, select Host or Network, depending on whether the IP
address you specify is a host system or a subnet.
3. Specify the following information:
a) In the Address field, type an IP address or network address from which the SNMP agent can accept
requests.
b) If you selected Network in step 3, type the netmask in the Mask field.
4. Click the Add button to add the host or network address to the list of allowed clients.
5. Click Update.

After you perform this task, the BIG-IP system has a list of IP addresses from which the system can accept
SNMP requests.

Allowing monitoring of the SNMP agent

Use this procedure to configure the BIG-IP® system to create a self IP address. This makes it possible for
a client to monitor the SNMP agent.

1. On the Main tab, click Network > Self IPs.

2. If you have not configured the self IP address that you will use for monitoring the SNMP agent, click
Create. Otherwise, in the IP Address column, click a self IP address.
3. From the Port Lockdown list, select Allow Custom.
4. Select UDP.
5. Select Port, and in the field, type 161 (the well-known port number for SNMP).
6. Click Add.
7. Click Finished or Update.

After you perform this task, a client system can monitor an SNMP agent.

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.

Granting community access to v1 or v2c SNMP data

To better control access to SNMP data, you can assign an access level to an SNMP v1 or v2c community.

Note: SNMPv1 does not support Counter64 OIDs, which are used for accessing most statistics.
Therefore, for SNMPv1 clients, an snmp walk command skips any OIDs of type Counter64. F5
Networks recommends that you use only clients that support SNMPv2 or higher.

1. On the Main tab, click System > SNMP.

195
SNMP Agent Configuration

2. From the Agent menu, choose Access (v1, v2c).

3. In the upper-right corner of the screen, click Create.
4. Select the type of address to which the access record applies, either IPv4 or IPv6.
5. In the Community field, type the name of the SNMP community for which you are assigning an access
level.
6. In the Source field, type the source IP address.
7. In the OID field, type the OID for the top-most node of the SNMP tree to which the access applies.
8. For the Access setting, select an access level, either Read Only or Read/Write. (This access level
applies to the community name you specified previously.)
9. Click Finished.

When you use the Configuration utility to assign an access level to a community, the utility updates the
[Link] file, assigning only a single access setting to the community.

Granting user access to v3 SNMP data

To better control access to SNMP data, you can assign an access level to an SNMP v3 user.

1. On the Main tab, click System > SNMP.

2. From the Agent menu, choose Access (v3).
3. In the upper-right corner of the screen, click Create.
4. In the User Name field, type a user name for which you are assigning an access level.
5. For the Authentication setting, select a type of authentication to use, and then type and confirm the
user’s password.
6. For the Privacy setting, select a privacy protocol, and either type and confirm the user’s password, or
select the Use Authentication Password check box.
7. In the OID field, type the object identifier (OID) for the top-most node of the SNMP tree to which the
access applies.
8. For the Access setting, select an access level, either Read Only or Read/Write.
This access level applies to the user name that you specified previously.
9. Click Finished.

When you use the Configuration utility to assign an access level to a user, the utility updates the [Link]
file, assigning only a single access setting to the user.

Implementation result
When you use the Configuration utility to assign an access level to a community, the utility updates the
[Link] file, assigning only a single access setting to the community. This figure shows a sample
[Link] file when you use the Configuration utility to grant read/write access to a community:

rocommunity public default

rwcommunity public1 [Link] .[Link].4.1.3375.[Link]

In this example, the string rocommunity identifies a community named public as having the default
read-only access level (indicated by the strings ro and default). This read-only access level prevents any

196
 BIG-IP® TMOS®: Implementations

allowed SNMP manager in community public from modifying a data object, even if the object has an
access type of read/write.
The string rwcommunity identifies a community named public1 as having a read/write access level
(indicated by the string rw). This read/write access level allows any allowed SNMP manager in community
public1 to modify a data object under the tree node.[Link].4.1.3375.[Link] ( ltmVirtualServ)
on the local host [Link], if that data object has an access type of read/write.

197
SNMP Agent Configuration

198
Chapter
25
SNMP Trap Configuration
Topics:

• Overview: SNMP trap configuration

• Task summary
SNMP Trap Configuration

Overview: SNMP trap configuration

On the BIG-IP® system, traps are definitions of unsolicited notification messages that the BIG-IP alert
system and the SNMP agent send to the SNMP manager when certain events occur on the BIG-IP system.
Configuring SNMP traps on a BIG-IP system means configuring the way that the BIG-IP system handles
traps, as well as setting the destination for notifications that the alert system and the SNMP agent send to
an SNMP manager.
The BIG-IP system stores traps in two specific files:
/etc/alertd/[Link]
Contains default SNMP traps.

Important: Do not add or remove traps from the /etc/alertd/[Link] file.

/config/user_alert.conf
Contains user-defined SNMP traps.
You use the Configuration utility to enable traps and set trap destinations. When you configure traps, the
BIG-IP system automatically updates the [Link] and user_alert.conf files.

Task summary
You can enable traps for certain events and set trap destinations.

Task list
Enabling traps for specific events
Setting v1 and v2c trap destination
Setting v3 trap destination

Enabling traps for specific events

You can configure the SNMP agent on the BIG-IP® system to send, or refrain from sending, notifications
when the following events occur:
• The SNMP agent on the BIG-IP system stops or starts. By default, this trap is enabled.
• The BIG-IP system receives an authentication warning, generated when a client system attempts to
access the SNMP agent. By default, this trap is disabled.
• The BIG-IP system receives any type of warning. By default, this trap is enabled.

1. On the Main tab, click System > SNMP.

2. From the Traps menu, choose Configuration.
3. To send traps when someone starts or stops the SNMP agent, verify that the Agent Start/Stop check
box is selected.
4. To send notifications when authentication warnings occur, select the Agent Authentication check box.
5. To send notifications when certain warnings occur, verify that the Device check box is selected.

200
 BIG-IP® TMOS®: Implementations

6. Click Update.

Setting v1 and v2c trap destination

You must specify the destination SNMP manager to which the BIG-IP® system should send notifications.
For SNMP v1 and v2c only, you specify a destination system by providing the community name to which
the BIG-IP system belongs, the IP address of the SNMP manager, and the target port number of the SNMP
manager.

Important: This procedure applies to SNMP v1 and v2c only.

1. On the Main tab, click System > SNMP.

2. From the Traps menu, select Destination.
3. In the upper-right corner of the screen, click Create.
4. For the Version setting, select an SNMP version number.
5. In the Community field, type the community name for the SNMP agent running on the BIG-IP system.
6. In the Destination field, type the IP address of the SNMP management system.
7. In the Port field, type the SNMP management system port number that is to receive the traps.
8. Click Finished.

Setting v3 trap destination

You must specify the destination SNMP manager to which the BIG-IP® system should send notifications.
For SNMP v3 only, you specify a destination system by providing the IP address and target port number
of the SNMP manager, as well as authentication and security information for accessing the SNMP manager.

Important: This procedure applies to SNMP v3 only.

1. On the Main tab, click System > SNMP > Traps > Destination.
2. In the upper-right corner of the screen, click Create.
3. For the Version setting, select v3.
4. In the Destination field, type the IP address of the SNMP management system.
5. In the Port field, type the SNMP management system port number that is assigned to receive the traps.
6. From the Security Level list, select the level of security at which you want SNMP messages processed.
Options Description
Option Description
Auth, No Privacy Process SNMP messages using authentication but without encryption. When
you use this value, you must also provide values for the Security Name,
Authentication Protocol, and Authentication Password settings.
Auth and Privacy Process SNMP messages using authentication and [Link] you use
this value, you must also provide values for the Security Name,
Authentication Protocol, Authentication Password, Privacy Protocol,
and Privacy Password settings.

7. In the Security Name field, type the user name the system uses to handle SNMP v3 traps.

201
SNMP Trap Configuration

8. From the Authentication Protocol list, select the algorithm the system uses to authenticate SNMP v3
traps. Your options are MD5 or SHA.
When you set this value, you must also enter a value in the Authentication Password field.
9. In the Authentication Password field, type the password the system uses to handle an SNMP v3 trap.
When you set this value, you must also select a value from the Authentication Protocol list.

Note: The authentication password must be at least 8 characters long.

10. If you selected Auth and Privacy from the Security Level list, from the Privacy Protocol list, select
the algorithm the system uses to encrypt SNMP v3 traps. Your options are AES or DES. When you set
this value, you must also enter a value in the Privacy Password field.
11. If you selected Auth and Privacy from the Security Level list, in the Privacy Password field, type
the password the system uses to handle an encrypted SNMP v3 [Link] you set this value, you must
also select a value from the Privacy Protocol list.

Note: The authentication password must be at least 8 characters long.

12. Click Finished.

Task summary
Setting v1 and v2c trap destination
Task summary

202
Chapter
26
Using the Request Logging Profile
Topics:

• Overview: Configuring a request logging

profile
• Task summary
• Request logging profile settings
• Request logging parameters
Using the Request Logging Profile

Overview: Configuring a request logging profile

The request logging profile gives you the ability to configure data within a log file for requests and responses
in accordance with specified parameters.

Task summary
Perform these tasks to log request and response data.
Creating a pool with request logging to manage HTTP traffic
Creating a request logging profile
Configuring a virtual server for request logging
Deleting a request logging profile

Creating a pool with request logging to manage HTTP traffic

For a basic configuration, you need to create a pool to manage HTTP connections.

1. On the Main tab, click Local Traffic > Pools.

The Pool List screen opens.
2. Click Create.
The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. For the Health Monitors setting, from the Available list, select the http monitor, and click << to move
the monitor to the Active list.
5. From the Load Balancing Method list, select how the system distributes traffic to members of this
pool.
The default is Round Robin.
6. For the Priority Group Activation setting, specify how to handle priority groups:
• Select Disabled to disable priority groups. This is the default option.
• Select Less than, and in the Available Members field, type the minimum number of members that
must remain available in each priority group in order for traffic to remain confined to that group.

7. Add the IP address for each logging server that you want to include in the pool, using theNew Members
setting:
a) Type an IP address in the Address, field or select a node address from the Node List.
b) Type 80 in the Service Port field, or select HTTP from the list.
c) (Optional) Type a priority number in the Priority field.
d) Click Add.
8. Click Finished.

The new pool appears in the Pools list.

204
 BIG-IP® TMOS®: Implementations

Creating a request logging profile

You must have already created a pool that includes logging servers as pool members before you can create
a request logging profile.
With a request logging profile, you can log specified data for HTTP requests and responses, and then use
that information for analysis and troubleshooting.

1. On the Main tab, click Local Traffic > Profiles > Other > Request Logging.
The Request Logging profile list screen opens.
2. Click Create.
The New Request Logging Profile screen opens.
3. From the Parent Profile list, select a profile from which the new profile inherits properties.
4. Above the Request Settings area, select the Custom check box.
This enables all settings in the Request Settings area, making them available for change.
5. Configure the request settings, as necessary.
6. Select the Custom check box for the Response Settings area.
The settings in the Response Settings area become available for configuring.
7. Configure the response settings, as necessary.
8. Click Finished.

This makes a request logging profile available to log specified data for HTTP requests and responses.
You must configure a virtual server for request logging.

Configuring a request logging profile for requests

Ensure that the configuration includes a pool that includes logging servers as pool members.
You can use a request logging profile to log specified data for HTTP requests, and then use that information
for analysis and troubleshooting.

1. On the Main tab, click Local Traffic > Profiles > Other > Request Logging.
The Request Logging profile list screen opens.
2. Click Create.
The New Request Logging Profile screen opens.
3. From the Parent Profile list, select a profile from which the new profile inherits properties.
4. Above the Request Settings area, select the Custom check box.
This enables all settings in the Request Settings area, making them available for change.
5. From the Request Logging list, select Enabled.
6. In the Template field, type the request logging parameters for the entries that you want to include in
the log file.
7. From the HSL Protocol list, select a high-speed logging protocol.
8. From the Pool Name list, select the pool that includes the logging server as a pool member.
9. (Optional) You can also configure the error response settings.
a) From the Respond On Error list, select Enabled.
b) In the Error Response field, type the error response strings that you want to include in the log file.
These strings must be well-formed for the protocol serving the strings.
c) Select the Close On Error check box to drop the request and close the connection if logging fails.

205
Using the Request Logging Profile

10. (Optional) You can also configure the logging request errors settings.
a) From the Log Logging Errors list, select Enabled.
b) In the Error Template field, type the request logging parameters for the entries that you want to
include in the log file.
c) From the HSL Error Protocol list, select a high-speed logging error protocol.
d) From the Error Pool Name list, select a pool that includes the node for the error logging server as
a pool member.
11. Click Update.

This configures a request logging profile to log specified data for HTTP requests.

Configuring a request logging profile for responses

You must have already created a pool that includes logging servers as pool members before you can configure
a request logging profile for responses.
With a request logging profile, you can log specified data for HTTP requests and responses, and then use
that information for analysis and troubleshooting.

1. On the Main tab, click Local Traffic > Profiles > Other > Request Logging.
The Request Logging profile list screen opens.
2. From the Parent Profile list, select a profile from which the new profile inherits properties.
3. Select the Custom check box for the Response Settings area.
The settings in the Response Settings area become available for configuring.
4. In the Response Settings area, from the Response Logging list, select Enabled.
5. (Optional) Select the Log By Default check box.
The Log By Default check box is selected by default.
6. In the Template field, type the response logging parameters for the entries that you want to include in
the log file.
7. From the HSL Protocol list, select a high-speed logging protocol.
8. From the Pool Name list, select the pool that includes the node logging server as a pool member.
9. (Optional) Configure the logging request error settings.
a) From the Log Logging Errors list, select Enabled.
b) In the Error Template field, type the response logging parameters for the entries that you want to
include in the log file.
c) From the HSL Error Protocol list, select a high-speed logging error protocol.
d) From the Error Pool Name list, select a pool that includes the node for the error logging server as
a pool member.
10. Click Update to save your changes.

This configures a request logging profile to log specified data for HTTP responses.

Configuring a virtual server for request logging

You can configure a virtual server to pass traffic to logging servers.

1. On the Main tab, click Local Traffic > Virtual Servers.

The Virtual Server List screen displays a list of existing virtual servers.
2. Click the name of the virtual server you want to modify.

206
 BIG-IP® TMOS®: Implementations

3. Click the Resources tab.

4. From the Default Pool list, select a pool name that is configured with pool members for request logging.
5. Click the Properties tab.
6. From the Configuration list, select Advanced.
7. From the Request Logging Profile list, select the profile you want to assign to the virtual server.
8. Click Update.

This virtual server can now pass traffic to the configured logging servers.

Deleting a request logging profile

You can delete a user-defined request logging profile that is obsolete or no longer needed.

1. On the Main tab, click Local Traffic > Profiles > Other > Request Logging.
The Request Logging profile list screen opens.
2. Select the check box for the applicable profile.
3. Click Delete.
4. Click Delete.

The profile is deleted.

Request logging profile settings

With the request logging profile, you can specify the data and the format for HTTP requests and responses
that you want to include in a log file.

General Properties

Setting Value Description

Name No default
Parent Profile Selected predefined or user-defined Specifies the selected predefined or
profile user-defined profile.

Request Settings

Setting Value Description

Request Logging Disabled Enables logging for requests.
Template Specifies the directives and entries to be logged.
HSL Protocol UDP Specifies the protocol to be used for high-speed logging of
requests.
Pool Name None Defines the pool associated with the virtual server that is
logged.
Respond On Error Disabled Enables the ability to respond when an error occurs.

207
Using the Request Logging Profile

Setting Value Description

Error Response None Specifies the response text to be used when an error occurs.
For example, the following response text provides content
for a 503 error.

<html>
<head>
<title>ERROR</title>
</head>
<body>
<p>503 ERROR-Service Unavailable</p>
</body>
</html>

Close On Error Disabled When enabled, and logging fails, drops the request and
closes the connection.
Log Logging Errors Disabled Enables the ability to log any errors when logging requests.
Error Template None Defines the format for requests in an error log.
HSL Error Protocol UDP Defines the protocol to be used for high-speed logging of
request errors.
Error Pool Name None Specifies the name of the error logging pool for requests.

Response Settings

Setting Value Description

Response Logging Disabled Enables logging for responses.
Log By Default Enabled Defines whether to log the specified settings for
responses by default.
Template None Specifies the directives and entries to be logged.
HSL Protocol HSL Specifies the protocol to be used for high-speed logging
of responses.
Pool Name None Defines the pool name associated with the virtual server
that is logged.
Log Logging Errors Disabled Enables the ability to log any errors when logging
responses.
Error Template None Defines the format for responses in an error log.
HSL Error Protocol UDP Defines the protocol to be used for high-speed logging
of response errors.
Error Pool Name None Specifies the name of the error logging pool for
responses.

208
 BIG-IP® TMOS®: Implementations

Request logging parameters

This table lists all available parameters from which you can create a custom logging profile. These are used
to specify entries for the Template and Error Template settings For each parameter, the system writes to
the log the information described in the right column.

Table 1: Request logging parameters

Parameter Log file entry description

BIGIP_BLADE_ID An entry for the slot number of the blade that handled the request.
BIGIP_CACHED An entry of Cached status: true, if the response came from BIG-IP®
cache, or Cached status: false, if the response came from the server.
BIGIP_HOSTNAME An entry for the configured host name of the unit or chassis.
CLIENT_IP An entry for the IP address of a client, for example, [Link].
CLIENT_PORT An entry for the port of a client, for example, 80.
DATE_D A two-character entry for the day of the month, ranging from 1 (note the
leading space) through 31.
DATE_DAY An entry that spells out the name of the day.
DATE_DD A two-digit entry for the day of the month, ranging from 01 through 31.
DATE_DY A three-letter entry for the day, for example, Mon.
DATE_HTTP A date and time entry in an HTTP format, for xe ample, Tue, 5 Apr 2011
[Link] GMT.

DATE_MM A two-digit month entry, ranging from 01 through 12.

DATE_MON A three-letter abbreviation for a month entry, for example, APR.
DATE_MONTH An entry that spells out the name of the month.
DATE_NCSA A date and time entry in an NCSA format, for example,
dd/mm/yy:hh:mm:ss ZNE.

DATE_YY A two-digit year entry, ranging from 00 through 99.

DATE_YYYY A four-digit year entry.
HTTP_CLASS The name of the httpclass profile that matched the request, or an empty
entry if a profile name is not associated with the request.
HTTP_KEEPALIVE A flag summarizing the HTTP1.1 keep-alive status for the request:: aY
if the HTTP1.1 keep-alive header was sent, or an empty entry if not.
HTTP_METHOD An entry that defines the HTTP method, for example, GET, PUT, HEAD,
POST, DELETE, TRACE, or CONNECT.

HTTP_PATH An entry that defines the HTTP path.

HTTP_QUERY The text following the first ? in the URI.
HTTP_REQUEST The complete text of the request, for example, $METHOD $URI $VERSION.
HTTP_STATCODE The numerical response status code, that is, the status response code
excluding subsequent text.

209
Using the Request Logging Profile

Parameter Log file entry description

HTTP_STATUS The complete status response, that is, the number appended with any
subsequent text.
HTTP_URI An entry for the URI of the request.
HTTP_VERSION An entry that defines the HTTP version.
NCSA_COMBINED An NCSA Combined formatted log string, for example, $NCSA_COMMON
$Referer ${User-agent} $Cookie.

NCSA_COMMON An NCSA Common formatted log string, for example, $CLIENT_IP - -

$DATE_NCSA $HTTP_REQUEST $HTTP_STATCODE $RESPONSE_SIZE.

RESPONSE_MSECS The elapsed time in milliseconds (ms) between receiving the request and
sending the response.
RESPONSE_SIZE An entry for the size of response in bytes.
RESPONSE_USECS The elapsed time in microseconds (µs) between receiving the request and
sending the response.
SERVER_IP An entry for the IP address of a server, for example, [Link].
SERVER_PORT An entry for the port of a server, for example, 80.
SNAT_IP An entry for the self IP address of the BIG-IP-originated connection to the
server when SNAT is enabled, or an entry for the client IP address when
SNAT is not enabled.
SNAT_PORT An entry for the port of the BIG-IP-originated connection to the serv
er when
SNAT is enabled, or an entry for the client port when SNAT is not enabled.
TIME_AMPM A twelve-hour request-time qualifier, for example, AM or PM.
TIME_H12 A compact twelve-hour time entry for request-time hours, ranging from 1
through 12.
TIME_HRS A twelve-hour time entry for hours, for example, 12 AM.
TIME_HH12 A twelve hour entry for request-time hours, ranging from 01 through 12.
TIME_HMS An entry for a compact request time of H:M:S, for example, [Link].
TIME_HH24 A twenty-four hour entry for request-time hours, ranging from 00 through
23.

TIME_MM A two-digit entry for minutes, ranging from 00 through 59.

TIME_MSECS An entry for the request-time fraction in milliseconds (ms).
TIME_OFFSET An entry for the time zone, offset in hours from GMT, for example, -11.
TIME_SS A two-digit entry for seconds, ranging from 00 through 59.
TIME_UNIX A UNIX time entry for the number of seconds since the UNIX epoch, for
example, [Link] UTC, January 1st, 1970.
TIME_USECS An entry for the request-time fraction in microseconds (µs).
TIME_ZONE An entry for the current Olson database or tz database three-character time
zone, for example, PDT.
VIRTUAL_IP An entry for the IP address of a virtual server, for example, [Link].
VIRTUAL_NAME An entry for the name of a virtual server.

210
 BIG-IP® TMOS®: Implementations

Parameter Log file entry description

VIRTUAL_POOL_NAME An entry for the name of the pool containing the responding server.
VIRTUAL_PORT An entry for the port of a virtual server, for example, 80.
VIRTUAL_SNATPOOL_NAME The name of the Secure Network Address Translation pool associated with
the virtual server.
NULL Undelineated strings return the value of the respective header.

211
Using the Request Logging Profile

212
 Index

Index
A BIG-IP system information 194
BIG-IP system licenses 20, 30
access control BIG-IP systems
and SNMP data 195 provisioning 20, 30
configuring 177 BIG-IP system version 11.x upgrade
access control properties verifying 52
assigning to user groups 172
access control settings
saving 173
C
access levels CCLDAP, See remote server authentication
assigning 194, 195, 196 certificates, See x509 certificates.
assigning for SNMP 196 Cert-LDAP, See remote server authentication
active/standby configuration client access
creating 20 allowing 195
result of 24 configuring 194
active-active configuration clients
described 28 and SNMP agents 195
result of 36 community access levels
Active Directory server information 167 assigning 196
active-standby configuration config sync, See configuration synchronization.
described 20 config sync address
active-standby software upgrade specifying 57
overview 40 configuration data
results 52 copying 187
task summary 44 importing 174
address exchange 23 restoring 188
address mapping, about IPv6 to IPv4 70 configuration objects
administrative partitions and traffic groups 28
access to 177 configuration synchronization 23, 32
creating 176 and Setup utility 20
defined 176 syncing to group 36, 59, 61
administrative traffic configuration synchronization addresses 23, 32
authenticating 167, 168 See also configuration synchronization
administrative user accounts connection mirroring
configuring 21, 30 configuring 58
allow-transfer statement, modifying for zone file transfers 64 enabling 21, 31
applications connection mirroring addresses, See mirroring addresses
creating 34, 35 connections
application traffic creating pools for 183
isolating on network 176 preserving on failover 58
authentication algorithms content
negotiating 78, 90, 102 of LLDPDUs 75
availability core allocation 184
during failover 44 counters, sFlow 190
counter sampling, configuring on BIG-IP system 190
B CPU core allocation 184
creating second traffic group 56
base network components 20 custom DNS profiles
BIG-IP main dashboard enabling DNS Express 66
customizing 18
BIG-IP system
preparing for upgrade 49
D
restoring 188 dashboard, BIG-IP main
upgrading to version 11.x 50 customizing 18

213
Index

dashboard windows failover addresses

customizing 18 configuring 23
DDoS attacks, about mitigating 64 exchanging during discovery 24
default access levels specifying 32
modifying 194 failover IP addresses
default gateway pools specifying 60
creating 159 failover methods
default policies 93 specifying 21, 31
default traffic groups 20, 28 file import 162, 163
destination IP addresses files
for traffic selectors 82, 93, 107, 117, 125, 137 importing 163
destination SNMP managers renaming 187
specifying 201 file transfers, See zone file transfers. 64
device availability floating IP addresses
defined 44 configuring 22, 31
device discovery folders
for device trust 33, 58 defined 42
of peer devices 24 forwarding virtual servers
device groups creating 159
creating 33, 59 creating for IPsec 80, 92, 104, 115, 125, 137
defined 42 FQDN (fully-qualified domain name) 21, 30
device objects fully-qualified domain name (FQDN) 21, 30
defined 42
devices
and mirroring limit 58
G
selecting for failover 44 global LLDP properties
device trust configuring 75
defined 42 guests
establishing 33, 58 configuring LTM on 180
DNS Express creating 180
about 64 provisioning BIG-IP modules for 182
enabling 66 setting to Deployed state 182
DNS Express TSIG key, creating 64
DNS Express zones
and statistics 67 H
creating 65
DNS profiles health monitors
and IPv6 to IPv4 mapping 72 assigning to pools 150, 155
assigning to virtual servers 72 high availability
customizing to handle IPV6 to IPv4 address mapping 70 and VLANs 23, 32
enabling DNS Express 66 enabling 21, 31
DNS servers host properties 184
configuring to allow zone file transfers 64 HTTP traffic
managing 182

E
I
encryption algorithms
negotiating 78, 90, 102 iApp applications
encryption contents 78, 103, 115 creating 34, 35
events ifile commands 162
setting SNMP traps for 200 iFiles
external files creating 163
and iRules 162 IKE (Internet Key Exchange)
external network defined 78, 90, 102
configuring 22, 31 IKE peers
defined 79, 91, 103
for data exchange 78, 90, 102
F IKE Phase 1
configuring 80, 92, 104
failover
and traffic groups 44

214
 Index

imported files L
listing 163
interfaces LDAP server information
and external VLAN configuration 22, 31 client certificate 168
and HA VLAN configuration 23, 32 specifying 167
and internal VLAN configuration 22, 31 licenses
internal network activating 20, 30
configuring 22, 31 link aggregation
Internet Key Exchange, See IKE (Internet Key Exchange) creating 149, 155
IP header encryption 78, 90, 103, 115 described 148, 154
IPsec tasks for 149, 154
and NAT traversal 124, 136 Link Layer Discovery Protocol, See LLDP
IPsec configuration result 87, 99, 112 LLDP
IPsec configurations overview 74
prerequisites for 124, 136 LLDPDU contents 76
IPsec IKE peers LLDP messages
creating 80, 92, 104 sending and receiving 75
creating for NAT-T 125, 137 LLDP properties
IPsec policies global 75
creating 81, 93, 106, 116 per interface 75
creating for NAT-T 125, 137 LLDP tasks 75
defined 79, 91, 103 local trust domains
IPsec protocol and device groups 33, 59
prerequisites for configuring 79, 91, 103, 115 defined 33, 58
purpose of 79, 91, 103, 115 loopback interface
IPsec protocol suite and SNMP 194
components of 79, 91, 103
described 78, 90, 102, 114
IPsec security associations
M
creating 116 main BIG-IP dashboard
IPsec traffic selectors customizing 18
creating 82, 93, 107, 117 management IP addresses
creating for NAT-T 125, 137 and ConfigSync 23, 32
defined 79, 91, 103 management port
IPsec Transport mode, See Transport mode configuring 21, 30
IPsec tunnel specifying for failover 32
creating for NAT-T 125, 137 manual security associations
verifying connectivity 83, 108, 118, 129, 141 creating 116
IPsec Tunnel mode, See Tunnel mode message content
IPv4-only servers for LLDPDUs 75
and mapping to IPv6-only clients 70 messages
passing traffic from IPv6-only clients 72 transmitting and receiving 75
IPv6-only clients migration
about mapping to IPv4-only servers 70 preparation 46, 47
passing traffic to IPv4-only DNS servers 72 preparation for APM 45
IPv6 to IPv4 mapping WA preparation 47
and DNS profiles 70, 72 WOM preparation 49
configuring virtual servers 72 mirroring, See connection mirroring
iRule commands mirroring addresses
for iFiles 162 configuring 23
iRule events 163, 164 exchanging 24
iRules specifying 32
and external files 162 mitigation of DDoS attacks 64
and iFiles 164 monitors
ISAKMP-SA security association 78, 90, 102 assigning to pools 150, 155
iSession tunneling
default policy for 93
N
NAT traversal
and IPsec 124, 136

215
Index

NAT traversal (continued) remote server authentication 166

using IPsec 124 request logging
negotiation code elements 209
of security associations 78, 90, 102 request logging profile
network failover creating 205
configuring 33, 59 deleting 207
specifying 21, 31 enabling for requests 205
notifications enabling for responses 206
sending 201 overview 204
settings 207
task summary 204
O requests
OSCP, See remote server authentication accepting 194, 195

P S
packet encryption 78, 103, 115 SAs (security associations)
packet filtering creating 116
enabling 160 SCF configuration commands
packet filter rules listed 186
creating 160 SCF file configuration
parameters tasks for 187
for request logging 209 SCF files
partitions, See administrative partitions and access control 173
payload encryption 78, 90, 103, 115 creating 187
peer devices loading 187
and traffic groups 34 using 188
discovering 24 secure channels
performance monitoring, configuring on BIG-IP system 190 establishing 78, 90, 102, 114, 124, 136
performance monitors security associations
assigning to pools 150, 155 creating 116
persistence negotiating 78, 90, 102
and source address affinity 150, 156 self IP address
Phase 1 negotiation assigning to traffic group 61
and IKE protocol 78, 90, 102, 114 self IP addresses
defined 78, 90, 102 and VLAN groups 151
Phase 2 negotiation creating 151
defined 78, 90, 102 for external network 22, 31
policies for HA network 23, 32
defined for IPsec 79, 91, 103 for internal network 22, 31
polling, configuring on BIG-IP system 190 removing from VLANs 151
pools serial cable failover
creating 150, 155 specifying 21, 31
creating for HTTP traffic 183 session persistence 150, 156
creating with request logging 204 Setup utility
prerequisites and base network 28
for configuring IPsec 124, 136 and base network configuration 22, 23, 31, 32
profiles and device discovery 24
creating custom HTTP 182 for active/standby configurations 20
creating DNS 70 for active-standby configurations 20
creating for DNS Express 66 sFlow counters
defined 190
sFlow receiver, adding to BIG-IP configuration 190
R sFlow receiver, configuring on BIG-IP system 190
single configuration files, See SCF files
RADIUS protocol slots
for remote server authentication 170 viewing properties for 184
read/write access SNAT translation addresses
granting 196 and traffic groups 28
receiver, adding to BIG-IP configuration 190

216
 Index

SNMP access levels traffic groups

assigning 194, 196 and iApp applications 34, 35
SNMP agent configuration as defaults 28
overview of 194 default name of 20
tasks for 194 defined 42, 44
SNMP agents forcing to standby state 35, 62
allowing access to 195 for remote devices 34, 35, 62
monitoring 195 maximum number supported 44
SNMP alerts traffic selectors
sending 200 See also IPsec traffic selectors
SNMP client creating 82, 93, 107, 117
defined 194 defined 79, 91, 103
SNMP data See also IPsec traffic selectors
controlling access to 195, 196 transmission
SNMP events of LLDPDUs 75
setting traps for 200 Transport mode
SNMP notifications security implications of 90
sending 201 verifying connectivity 95
SNMP protocol traps
managing 194 defined 200
SNMP traps trunks 148, 154
defined 200 trust domains, See local trust domains
enabling 200 trusted peers
SNMP v1 and v2c trap destination and address exchange 23
setting 201 trust relationships
SNMP v1 and v2c traps establishing 20
setting destination 201 TSIG key, creating for DNS Express 64
SNMP v3 trap destination Tunnel mode
setting 201 defined 78, 103, 115
SNMP v3 traps verifying connectivity 83, 108, 118, 129, 141
setting destination 201
source address affinity persistence 150, 156
source ports
U
and traffic selectors 82, 93, 107, 117 unicast failover addresses, See unicast IP addresses
SSL protocol unicast IP addresses
alternative to 78, 90, 102, 114 specifying for failover 32
standby state upgrading
forcing to 35, 62 and ASM 46
statistics and PSM 47
viewing for DNS Express zones 67 and two redundant ASM systems 46
sync-failover preparation 46, 47
prerequisites for setting up 57 preparation for APM 45
Sync-Failover device groups WA preparation 47
creating 33, 59 WOM preparation 49
synchronization, See configuration synchronization user access control
system information 194 tasks for 176
system provisioning 20, 30 user accounts
authenticating 167, 168
T user authorization
granting 176
TACACS+ protocol user groups
for remote server authentication 171 assigning access control properties to 172
tagged interfaces 148, 154 user roles
term 60 for system access 177
TLVs 76
tmsh commands
for SCF files 186
V
traffic group vCMP guests, See guests
creating a second 56 vCMP host properties
creating non-default 56 viewing 184

217
Index

version 11.x upgrade VLANs

preparing BIG-IP modules 45 enabling SNAT automap 158
virtual address removing self IP addresses 151
assigning to traffic group 61 VLAN tags, See VLAN IDs
virtual IP addresses
and traffic groups 28
virtual servers
W
See also forwarding virtual servers WAN traversal
and IPv6 to IPv4 mapping 72 using IPsec 78, 90, 102, 114
and source address persistence 150, 156
assigning a Request Logging profile 206
assigning DNS profiles 72 X
creating for HTTP traffic 184
passing traffic between IPv6-only clients and IPv4-only DNS x509 certificates
servers 72 and IKE peers 80, 92, 104
See also forwarding virtual servers for device trust 33, 58
VLAN
adding tagged interface 149, 155 Z
VLAN groups
and self IP addresses 151 zone file transfers, and configuring DNS servers 64
creating 151 zones
VLAN IDs creating for DNS Express 65
configuring 22, 23, 31, 32

218