The order of virtual server
precedence (from the highest precedence to the lowest precedence) is as
follows:
·
ip:port
·
ip:any
·
network:port
·
any:port
·
network:any
·
vlan:port
·
vlan:any
·
any:any
Once a packet is sent to a specific
virtual server, it is added to the connection table for that virtual server.
From that point forward, packets that come in from the same connection will
always go to the virtual server that contains the connection in its connection
table, ignoring virtual server precedence.
The order of precedence has changed
in BIG-IP version 9.x. For more information, refer to SOL6459:
Order of precedence for virtual server matching.
sol411:
Overview of packet tracing with the
tcpdump utility
Running
the tcpdump utility
Selecting an Interface or VLAN
Disabling name resolution
Saving tcpdump output to a file
Binary file
Text file
Reading tcpdump binary file output
Filters
Filtering on a host address
Filtering on a port
Filtering on a tcp flag
Combining filters with the and operator
Capturing packet data
Suppressing hostname and port resolution
Combining tcpdump options
Advanced tcpdump topics
Supplemental Information
Selecting an Interface or VLAN
Disabling name resolution
Saving tcpdump output to a file
Binary file
Text file
Reading tcpdump binary file output
Filters
Filtering on a host address
Filtering on a port
Filtering on a tcp flag
Combining filters with the and operator
Capturing packet data
Suppressing hostname and port resolution
Combining tcpdump options
Advanced tcpdump topics
Supplemental Information
The tcpdump utility is a
command line packet sniffer with many features and options. For a full
description, refer to the tcpdump man pages by typing the following
command:
man tcpdump
Following are examples of commands
used to run the tcpdump utility:
The tcpdump utility is able
to sniff for packets on only one interface or VLAN. By default, it selects the
lowest numbered interface.
To select an interface, use the -i
flag, as follows:
tcpdump -i
For example:
To tcpdump a specific
interface:
tcpdump -i 2.1
tcpdump -i 1.10
To tcpdump a specific vlan:
tcpdump -i internal
tcpdump -i external
To tcpdump the management
interface:
tcpdump -i eth0
Note: Do not attempt to run tcpdump
on an interface that contains a colon.
For example:
eth0:mgmt
For example:
eth0:mgmt
By default, tcpdump attempts
to look up IP addresses and use names, rather than numbers, in the output. The
BIG-IP system must wait for a response from the DNS server, so the lookups can
be time consuming and the output may be confusing.
To disable name resolution, use the -n
flag as in the following examples:
tcpdump -n
tcpdump -ni internal
You can save the tcpdump data
to one of the following file formats:
·
A binary file that contains all the
information collected by the tcpdump and is readable by the tcpdump
utility as well as many other traffic analysis packages.
·
A text file that contains a subset
of the full tcpdump data, but is readable only as plain text.
When working with F5
Technical Support, you must provide the tcpdump
output in the binary file format.
To save the tcpdump output to
a binary file, type the following command:
tcpdump -w
For example:
tcpdump -w dump1.bin
Note: The tcpdump utility does not print
data to the screen while it is capturing to a file. To stop the capture, press CTRL-C.
To save the tcpdump output to
a text file, type the following command:
tcpdump >
For example:
tcpdump >dump1.txt
To read data from a binary tcpdump
file (that you saved by using the tcpdump -w command), type the
following command:
tcpdump -r
For example:
tcpdump -r dump1.bin
In this mode, the tcpdump
utility reads stored packets from the file, but otherwise operates just as it
would if it were reading from the network interface. As a result, you can use
formatting commands and filters.
Beginning in BIG-IP 11.2.0-HF3, 11.2.1-HF3, and 11.3.0, a pseudo header which includes the following parameters is added to the start of each binary tcpdump capture:
Beginning in BIG-IP 11.2.0-HF3, 11.2.1-HF3, and 11.3.0, a pseudo header which includes the following parameters is added to the start of each binary tcpdump capture:
·
The tcpdump command syntax used,
including all options
·
Version of software
·
Hostname of the system
·
Platform ID
·
Product
The tcpdump utility allows
you to use filters to, among other things, restrict the output to specified
addresses, ports, and tcp flags.
·
To view all packets that are
traveling to or from a specific IP address, type the following command:
tcpdump
host
For
example:
tcpdump host
10.90.100.1
·
To view all packets that are
traveling from a specific IP address, type the following command:
tcpdump
src host
For
example:
tcpdump src host
10.90.100.1
·
To view all packets that are
traveling to a particular IP address, type the following command:
tcpdump
dst host
For
example:
tcpdump dst host
10.90.100.1
·
To view all packets that are
traveling through the BIG-IP system and are either sourced from or destined to
a specific port, type the following command:
tcpdump
port
For
example:
tcpdump
port 80
·
To view all packets that are
traveling through the BIG-IP system and sourced from a specific port, type the
following command:
tcpdump
src port
For
example:
tcpdump
src port 80
·
To view all packets that are
traveling through the BIG-IP system and destined to a specific port, type the
following command:
tcpdump
dst port
For
example:
tcpdump
dst port 80
·
To view all packets that are
traveling through the BIG-IP system that contain the SYN flag, type the following
command:
tcpdump
'tcp[tcpflags] & (tcp-syn) != 0'
·
To view all packets that are
traveling through the BIG-IP system that contain the RST flag, type the
following command:
tcpdump
'tcp[tcpflags] & (tcp-rst) != 0'
You can use the and operator
to filter for a mixture of output.
Following are some examples of
useful combinations:
tcpdump host 10.90.100.1 and port 80
tcpdump src host 172.16.101.20 and
dst port 80
tcpdump src host 172.16.101.20 and
dst host 10.90.100.1
The tcpdump utility provides
an option that allows you to specify the amount of each packet to capture.
You can use the -s (snarf/snaplen)
option to specify the amount of each packet to capture. To capture the entire
packet, use a value of 0 (zero).
For example:
For example:
tcpdump -s0 src host 172.16.101.20
and dst port 80
Alternatively, you can specify a
length large enough to capture the packet data you need to examine.
For example:
For example:
tcpdump -s200 src host 172.16.101.20
and dst port 80
If you are using the tcpdump
utility to examine the output on the console during capture or by reading
from an input file with the -r option, you should also use the -X
flag to display ASCII encoded output along with the default HEX encoded output.
For example:
For example:
tcpdump -r dump1.bin -X -s200 src
host 172.16.101.20 and dst port 80
The tcpdump utility provides
an option that allows you to specify whether IP addresses and service
ports are translated to their corresponding hostnames and service names.
Since performing multiple name
lookups during a packet capture may be resource intensive, you should disable
name resolution while capturing on a busy system using the -n option.
For example:
For example:
tcpdump -n src host 172.16.101.20
and dst port 80
Service port lookups incur less
overhead than DNS-based name resolutions, but still are usually unnecessary
while performing a capture. You can disable both name and service port
resolution while performing a capture, by using the -nn option.
For example:
For example:
tcpdump -nn src host 172.16.101.20
and dst port 80
This article contains the most
essential tcpdump options. You will generally need to use most of the
options in combination.
Following are examples of how to
combine the tcpdump options to provide the most meaningful output:
tcpdump -ni internal -w dump1.bin
tcpdump -ni internal -r dump1.bin
host 10.90.100.1
tcpdump -ni 2.1 host
10.90.100.1 and port 80
tcpdump -ni 1.10 src host
172.16.101.20 and dst port 80 >dump1.txt
tcpdump -Xs200 -nni eth0 -w
/var/tmp/mgmt.cap dst host 172.16.101.20 and dst port 162
The BIG-IP virtual server type specifies
the attributes for a virtual server. For example, a Standard virtual server has
a different set of attributes and is used to process traffic differently than a
Forwarding virtual server. The virtual server type can be found in the
Configuration utility by navigating to Local Traffic > Virtual
Servers, clicking a specific virtual server, and then viewing the Type
drop-down box. The following is a description of the connection setup
characteristics for BIG-IP LTM virtual server types:
The BIG-IP LTM TMOS operating system
implements a full proxy architecture for virtual servers configured with a TCP
profile. By assigning a custom TCP profile to the virtual server, you can
configure the BIG-IP LTM system to maintain compatibility to disparate server
operating systems in the data center. At the same time, the BIG-IP LTM system
can leverage its TCP/IP stack on the client side of the connection to provide
independent and optimized TCP connections to client systems.
In a full proxy architecture, the
BIG-IP LTM system appears as a TCP peer to both the client and the server by
associating two independent TCP connections with the end-to-end session.
Although certain client information, such as the source IP address or source
TCP port, may be re-used on the server side of the connection, the BIG-IP LTM
system manages the two sessions independently, making itself transparent to the
client and server.
The Standard virtual server requires
a TCP or UDP profile, and may optionally be configured with HTTP, FTP, or SSL
profiles if Layer 7 or SSL processing is required.
The TCP connection setup behavior for a Standard
virtual server varies depending on whether a TCP profile or a TCP and Layer 7
profile, such as HTTP, is associated with the virtual server
Creating packet
filter rules
Packet
filter rules are criteria statements that the
BIG-IP system uses for filtering packets. The BIG-IP system attempts to match
packet filter rules with an incoming packet, and if a match exists, determines
whether or not to accept or reject the packet.
When you create
a packet filter rule, you configure several settings, and then you define the
criteria that you want the BIG-IP system to use to filter the traffic.
1.
|
On the Main tab of the navigation pane, expand Network, and click Packet Filters.
The Packet Filters screen opens. |
Note:
If you have not enabled the Packet Filter feature, you can still
create a packet filter rule. However, the BIG-IP system cannot use the packet
filter rule until you have enabled the Packet Filter feature. For more
information, see Enabling
packet filtering.
2.
|
|
3.
|
Note: If the Create button is unavailable, you
do not have permission to create a packet filter rule. You must have either the
Administrator or Resource Administrator role
assigned to your user account.
4.
|
|
5.
|
Configuring
settings for packet filter rules
You can
configure a number of different settings when you create a packet filter rule.
Table 12.3 lists and describes the settings that you can configure.
Following the table are sections that provide more detail on each setting.
Specifies a number that you assign to a rule, which determines
when the packet filter is processed. Low
numbers take priority over higher ones.
|
||
Specifies the action that BIG-IP system should take when a match
is found. Possible values are: Accept, Discard, Reject, and Continue.
|
||
Lists one or more existing rate classes that you assign to the
packet filter. This setting applies only when you
have enabled the rate shaping feature. For more information on rate classes,
see the Configuration Guide for BIG-IP® Local Traffic Management.
|
||
Using the Name setting, you can specify a unique name for the packet filter
rule. This setting is required.
An LDAP authentication module is a mechanism for authenticating or
authorizing client connections passing through a BIG-IP system.
This module is useful when your authentication or authorization data is stored
on a remote LDAP server or a Microsoft® Windows
Active Directory server, and you want the client credentials to be based on
basic HTTP authentication (that is, user name and password).
With the LDAP authentication module, Local Traffic Manager can
indicate that the authentication was a success or
failure, or that the LDAP server needs a credential of some sort.
Additionally, the system can take some action based on certain
information that the server returns in the
LDAP query response. For example, LDAP response information can indicate the
users group membership, or it can indicate that the users password has expired.
To configure Local Traffic Manager to return specific data in an LDAP response,
you can write an iRule, using the commands AUTH::subscribe,
AUTH::unsubscribe, and AUTH::response_data.
For more information, see Chapter 18,
iRules, and the F5
Networks DevCentral web site, http://devcentral.f5.com.
Backing up customized configuration
files
If your system configuration has
been customized to reference files that are not included in the default BIG-IP
installation, refer to SOL4422:
Viewing and modifying the files that are configured for inclusion in a UCS
archive.
File names and location
By default, the BIG-IP system saves
the UCS archive file with a .ucs extension if you do not include it in
the file name. You can also specify a full path to the archive file, and then
the archive file is saved to the specified location. If you do not include a
path, the file is saved to the default archive directory, /var/local/ucs.
Archives located in a directory other than the default do not appear in the
list of available archives when using the Configuration utility to create or
restore a UCS archive, or when using the list /sys ucs command in the tmsh
utility. To easily identify the file, F5 recommends that you include the BIG-IP
host name and current timestamp as part of the file name.
Secure Storage
Ensure that you have access to a
secure location for storage of your UCS archive files. A typical UCS archive
contains user accounts, passwords, critical system files, and SSL private keys.
However, you can explicitly exclude SSL private keys from a UCS archive during
the backup process. It is important to store the backup UCS archives containing
sensitive information in a secure location. For instructions, refer to SOL175:
Transferring files to or from an F5 system.
BIG-IP software version and platform
·
F5 recommends that you run the same
version of the BIG-IP software on the BIG-IP system from which it was backed
up. However, you can restore a BIG-IP 10.x UCS archive on a system running
BIG-IP 11.x software.
·
Due to an issue in BIG-IP 11.0.0,
you must perform a configuration restoration using a configuration archive that
is taken from the same hardware platform. For more information, refer to SOL13136:
The UCS configuration archive cannot be restored on a platform other than the
one on which the archive was created.
·
The UCS archive is intended to back
up and restore the configuration of a specific platform. When installing a UCS
archive on a dissimilar platform, the configuration may fail to load due to the
differing hardware components. These failures require that you intervene
manually, and identify and resolve each error that the system presents when you
attempt to load the configuration.
Licensing
The BIG-IP license is associated
with a specific hardware serial number. The UCS archive contains the license of
the file from which the configuration was saved. To successfully install a UCS
archive file on a BIG-IP system, you must perform one of the following actions:
·
Restore the UCS archive to the same
system from which it was saved.
·
Have the license associated with the
serial number of a new system. To do so, contact F5
Technical Support.
Note: F5 Technical Support will associate a license file with a
new serial number only on an as-needed basis, in the event of a Return
Materials Authorization (RMA).
·
Relicense the BIG-IP system after
restoring the UCS archive.
·
Save the license file prior to
restoring the configuration from another system, and then copy the license file
back.
·
Install the UCS archive by using the
tmsh no-license option. For the command syntax, refer to the following
example:
tmsh load sys ucs [ucs file name] no-license
tmsh load sys ucs [ucs file name] no-license
Important: If you use a different license than the
one contained in a restored UCS archive, the replacement license must include
authorization for the same options and add-on modules, such as BIG-IP
WebAccelerator or BIG-IP ASM. If you attempt to restore a UCS configuration
referencing an unlicensed module, the BIG-IP system does not properly restore the
UCS archive. Additionally, the BIG-IP system reports a Provisioning
Warning message in the Configuration utility, as well as the status of ModuleNotLicensed
in its command-line prompt.
UCS files
If necessary, copy the UCS archive
file you want to restore to the BIG-IP filesystem.
Host name and base configuration
The UCS restore operation restores
the full configuration to the target system, including the host name and the
base configuration.
Note: This behavior has changed from previous
versions of the BIG-IP system.
SSL private keys with passphrases
If you are restoring on a new
system, a UCS archive that includes SSL private keys with encrypted passphrases
cannot be decrypted by the new system. This format is an intentional security
measure.
When replacing one system of a
failover pair, F5 recommends that you configure basic networking on the
replacement unit and synchronize the configuration from its peer instead of
restoring the configuration by installing the UCS archive. Because the master
key is shared between units of a redundant pair, the configuration
synchronization process synchronizes the original master key to the
newly-installed device. If you cannot synchronize the original master key to
the new system from its peer, but you know the original unencrypted
passphrases, you can install the UCS file to restore the configuration, modify
the affected SSL profiles to replace the encrypted passphrases with unencrypted
versions, and save the resulting configuration.
If you are restoring a backup that
contains SSL private key passphrases after reinstalling the operating system,
replacing a failed system with a new system, or otherwise moving an existing
configuration to a new system, the encrypted passphrases for SSL private keys
used in the configuration cannot be decrypted. An error message similar to the
following example appears:
BIGpipe client SSL profile creation
error:
01070937:3: Master Key decrypt failure - decrypt failure
01070937:3: Master Key decrypt failure - decrypt failure
If you receive this error message
when installing the UCS archive, refer to SOL9420:
Installing a UCS file containing an encrypted passphrase before proceeding.
SSL private keys with passphrases
When restoring on a new system, a
UCS archive that includes SSL private keys with encrypted passphrases cannot be
decrypted by the new system. This format is an intentional security measure.
When replacing one system of a
failover pair, instead of restoring the configuration by installing the UCS
archive, F5 recommends that you configure basic networking on the replacement
unit and synchronize the configuration from its peer. Because the master key is
shared between units of a redundant pair, the configuration synchronization
process synchronizes the original master key to the newly-installed device.
If you cannot synchronize the
original master key to the new system from its peer, but you know the original
unencrypted passphrases, you can install the UCS file to restore the
configuration, modify the affected SSL profiles to replace the encrypted
passphrases with unencrypted versions, and save the resulting configuration.
GTM consideration
For a BIG-IP GTM RMA unit that is
licensed and provisioned with the GTM module and the DNSSEC feature, refer to SOL13542:
Restoring DNSSEC configuration data to a BIG-IP GTM RMA unit.
For BIG-IP GTM 10.1.0 through
10.2.4, the BIG-IP GTM system updates the timestamp of the restored wideip.conf
file during the UCS archive restoration process. As a result, the restored
BIG-IP GTM configuration will overwrite the configuration on the remaining
systems in the same synchronization group. For information about preventing
this behavior, refer to SOL12679:
The gtmparse utility now updates the timestamp of the wideip.conf file before
reloading the configuration from disk or UCS archive.
Installing a hotfix image using the
tmsh utility
Impact of procedure: Performing the following procedure should not have a
negative impact on your system.
To install the hotfix using the tmsh
utility, perform the following procedure:
1.
Log in to tmsh by typing the
following command:
tmsh
2.
To install the hotfix image, use the
following tmsh syntax:
install sys software
hotfix .iso volume
For example, to install a hotfix on HD1.1, the syntax
appears similar to the following example:
install sys software
hotfix Hotfix-BIGIP-11.0.0-1234.0-HF1.iso volume HD1.1
3.
To show the status of the hotfix
installation, type the following command:
show sys
software status
For example, the following output indicates that hotfix
build 8120.0 is installing on volume HD1.1:
-----------------------------------------------------------
Sys::Software Status
Volume Product Version Build Active Status
-----------------------------------------------------------
HD1.1 BIG-IP 11.0.0 8120.0 no installing hotfix
HD1.2 BIG-IP 11.0.0 8120.0 yes complete
HD1.3 BIG-IP 11.0.0 8037.0 no complete
Sys::Software Status
Volume Product Version Build Active Status
-----------------------------------------------------------
HD1.1 BIG-IP 11.0.0 8120.0 no installing hotfix
HD1.2 BIG-IP 11.0.0 8120.0 yes complete
HD1.3 BIG-IP 11.0.0 8037.0 no complete
If you need to revert to the
previous hotfix version, you can boot to the formerly-active boot location that
contains the previous hotfix installation.
If you need to remove a hotfix
installation, you must restore the BIG-IP base build on the boot location from
the Software Management screen in the Configuration utility or the tmsh
utility. For example, if the BIG-IP system runs BIG-IP 11.0.0 HF1 on HD1.2,
and you want to remove the hotfix, you must back up the configuration, change
to a different boot location (for example, HD1.1), and then use the
Configuration utility, or the tmsh utility, to reinstall the base
version 11.0.0 build on HD1.2.
