F5 BIG-IP

 

 

---

Contents

1. F5 BIG-IP LTM proxy load balancing
2. iRules
3. Local traffic management
4. Network map
5. Virtual servers
   • Types
   • Destination address
   • Connection rate limiting
   • Wildcard servers
6. Virtual addresses
7. Route domain IDs
8. Virtual address status
9. Clustered Multiprocessing
10. Nodes
    • Create a node
    • Node address
    • Status
    • State
    • Configuration
    • FQDN
11. Pools
    • Status
    • Pool Features
    • Pool member features
12. Local traffic operations
    • Server node state
    • Pool member state
    • Virtual address state
    • Virtual server state
13. Traffic classes
14. Dynamic ratio load balancing
    • RealServer monitor
    • WMI monitor
15. DNS Troubleshooting
16. tcpdump

F5 BIG-IP LTM proxy load balancing

Use the Local Traffic Manager (LTM) proxy to enable several load balancing methods

BIG-IP LTM load balancing methods are available when attaching server nodes to pools. Nodes allow global distribution of traffic to the servers in a pool, based on server metrics. Alternatively, member load balancing decisions are made from within a particular pool.

Clustered Multiprocessing (CMP), when enabled, creates separate Traffic Management Microkernel (TMM) instances for each CPU, sharing the workload among all CPUs.

• Static load balancing methods such as round-robin do not use traffic metrics from the pool members.

• Dynamic load balancing methods such as Least Connections, do use traffic metrics from the pool members, which can be used by the Performance monitors to send more or less traffic to hosts in the pool. Can be applied at the node level only (the nodes list not attached to a pool).

Health monitors are applied at the node level or at the pool level

The GTM (DNS) module also provides load balancing using name resolution.

Load Balancing Methods

Method	Description
Round Robin	Default. Pass new connection requests to the next server in the pool, distributing connections evenly across the array of machines. Useful for identifying if the application is stateful, requiring a persistence profile. If so round robin would break the app.
Ratio (member) Ratio (node)	Static load balanacing method that distribute connections among pool members or nodes in a static rotation according to ratio weights. The higher the weight, the more traffic. Set a ratio weight when creating a pool member or node. Useful for things not easily measured or that are more static, such as gateway pool with two circuits, one 1gb and the 100mb.
Dynamic Ratio (member) Dynamic Ratio (node)	Dynamic Ratio load balancing selects servers based on server performance analysis. Ratio weights are system-generated. Requires continuous monitoring of the servers. To implement, install the appropriate performance monitor Server type Monitor plug-in Monitor Type RealServer Win F5RealMon.dll Real Server RealServer UNIX f5realmon.so Real Server Windows Server WMI f5isapi.dll or F5Isapi64.dll or F5.IsHandler.dll WMI / SNMP DCA & SNMP DCA Base Windows 2000 Server SNMP agent SNMP DCA & SNMP DCA Base UNIX Server UC Davis SNMP agent SNMP DCA & SNMP DCA Base
Fastest (node) Fastest (application)	Select servers based on the least number of current outstanding requests (no response received). Requires assignment of an L7 Services profile and a TCP profile. The BIG-IP has a counter on each pool member that increments when it receives a L7 request, and decrements those counters as soon as the response is received. Useful if pool members are located in different data centers where there is latency. If OneConnect is enabled, does not include idle connections. Traffic is distributed to pool members based on least connection methods: Least Connections, Weighted Least Connections, Fastest, Observed, and Predictive.
Least Connections (member) Least Connections (node)	Pass a new connection to the pool member or node with the least number of active connections. If OneConnect is enabled, does not include idle connections. Useful if servers have similar performance capabilities and the application traffic on the servers does not vary greatly from user to user.
Weighted Least Connections (member) Weighted Least Connections (node)	Distribute connections to the pool member with the fewest open connections. Requires all pool members to have a non-zero connection limit specified. The member method uses the Connection Limit value to establish a proportional algorithm for each pool member. The node method uses the node Connection Limit setting and the number of current connections. If OneConnect is enabled, does not include idle connections. Limits can be skewed if the application has dynamic traffic varying from user to user. Works best for servers with different capacities and a relatively static app. Not ideal for adaptive traffic distribution.
Observed (member) Observed (node)	The BIG-IP system observes the number of L4 connections to each pool member and assigns a ratio value to each pool member. For new connections the pool member with the greatest ratio value is preferred. Works well for small pools with varying server speeds. Does not perform well in large pools. .
Predictive (member) Predictive (node)	Servers are rated according to the number of current connections. BIG-IP analyzes the trends over time. Servers with improving performance rankings receive a higher proportion of the connections.
Least Sessions	Select the server with the least number of entries in the persistence table. Requires a profile that tracks persistence connections, such as the Source Address Affinity or Universal profile. Incompatible with cookie persistence. Universal persistence stores traffic based on header or content data in the client request and server response, which is specified in an iRule.
Ratio Least Connections	Select pool members according to the ratio of the number of active connections per pool member. If a ratio weight is not specified, it will be treated as a default value of 1. Not widely used.

Priority-based member activation

Priority-based member activation categorizes pool members into priority groups Pool members in higher priority groups accept traffic before pool members in lower priority groups. There are two configuration settings:

Priority group activation

Minimum number of members that must remain available in each priority group in order for traffic to remain confined to that group. Allowed value range from 0 to 65535. Setting to 0 disables the feature (equivalent to default value of Disabled).

Priority group

Specify a priority group for each member added to the pool. Default of 0 for a pool member means that the member is in the lowest priority group and only receives traffic when all pool members in higher priority groups are unavailable.

If the number of available members assigned to the highest priority group drops below the specified number, the BIG-IP system distributes traffic to the next highest priority group, and so on. For example, this configuration has three priority groups, 3, 2, and 1, with the priority group activation value (shown here as min active members) set to 2.

pool my_pool 
{
   lb_mode fastest
   min active members 2
   member 10.12.10.7:80 priority 3
   member 10.12.10.8:80 priority 3
   member 10.12.10.9:80 priority 3
   member 10.12.10.4:80 priority 2
   member 10.12.10.5:80 priority 2
   member 10.12.10.6:80 priority 2
   member 10.12.10.1:80 priority 1
   member 10.12.10.2:80 priority 1
   member 10.12.10.3:80 priority 1
}

Connections are first distributed to all pool members with priority 3 (the highest priority group). If fewer than two priority 3 members are available, traffic is directed to the priority 2 members as well. If both the priority 3 group and the priority 2 group have fewer than two members available, traffic is directed to the priority 1 group. The BIG-IP system continuously monitors the priority groups, and whenever a higher priority group once again has the minimum number of available members, the BIG-IP system limits traffic to that group.

iRules

iRules use Tcl scripts to select pools based on headers and type of content. We can send traffic to pools and individual pool members, ports, or URIs.

The Local Traffic Manager (LTM) triggers an iRule based on an event declaration specified in the iRule. For example, if the client's address matches 10.10.10.10, to send the packet to the my_pool pool.

when CLIENT_ACCEPTED 
{
   if { [IP::addr [IP::client_addr] equals 10.10.10.10] } {
   pool my_pool
   }
}
  

An HTTP_REQUEST declaration triggers an iRule whenever the system receives an HTTP request:

when HTTP_REQUEST 
{
  if { [HTTP::uri] contains "aol" } 
  {
     pool aol_pool
  } 
  else 
  {
     pool all_pool
 }
}
  

Use the Universal Inspection Engine to write an iRule that searches either the header of a packet, or actual packet content, and then direct the packet based on the result of that search. iRules can also direct packets based on the result of a client authentication attempt.

iRule commands

An iRule command causes LTM to take some action, such as querying for data, manipulating data, or specifying a traffic destination. Command types include:

Statement commands

Cause actions such as selecting a traffic destination or assigning a SNAT translation address. For example use pool <name>, to direct traffic to the named load balancing pool.

Commands that query or manipulate data

Commands that search for header and content data and optionally perform data manipulation such as inserting headers into HTTP requests. An example query command is IP::remote_addr, which searches for and returns the remote IP address of a connection. An example data manipulation command is HTTP::header remove <name>, which removes the last occurrence of the named header from a request or response.

Utility commands

Useful for parsing and manipulating content. An example of a utility command is decode_uri <string>, which decodes the named string using HTTP URI encoding and returns the result.

The pool command

Once a query is specified, we can use the pool command to select a load balancing pool. For example:

when HTTP_REQUEST 
{
  set uri [HTTP::uri]
  if { $uri ends_with ".gif" } 
  {
     pool my_pool
  } 
  elseif { $uri ends_with ".jpg" } 
  {
     pool your_pool
 }
}
  

The node command

We can write an iRule that directs traffic to a specific server using the node command.

when HTTP_REQUEST 
{
  if { [HTTP::uri] ends_with ".gif" } 
  {
     node 10.1.2.200 80
  }
}
  

Select a pool of cache servers

Create an iRule that selects a server from a pool of cache servers. For example:

when HTTP_REQUEST 
{
   if { [HTTP::uri] ends_with "html" or [HTTP::uri] ends_with "gif" } 
   {
      pool cache_pool 
      set key [crc32 [concat [domain [HTTP::host] 2] [HTTP::uri]]] 
      set cache_mbr [persist lookup hash $key node] 
      if { $cache_mbr ne "" } 
      { 
        # Verify the request is not coming from the cache:
        if { [IP::addr [IP::remote_addr] equals $cache_mbr] } 
          # Send the request from the cache to the origin pool:
          pool origin_pool
          return 
      } 
   } 
      # Ensure that the persistence record is added for this host/URI:
      persist hash $key
   } 
   else 
   { 
       pool origin_pool 
   } 
}

LTM redirects URIs to a new cache member at the time that the BIG-IP system receives a request for the URI, rather than when the pool member becomes unavailable.

The HTTP::redirect command

Use the HTTP::redirect iRule command to redirect HTTP requests to a host name or a URI.

For example, to redirect an HTTP response.

when HTTP_RESPONSE 
{
  if { [HTTP::status] contains "404"} 
  {
    HTTP::redirect "http://www.siterequest.com/"
  }
}
  

To redirect an HTTP request.

when HTTP_REQUEST 
{
  if { [HTTP::uri] contains "secure"} 
  {
    HTTP::redirect "https://[HTTP::host][HTTP::uri]"
  }
}
  

The snat and snatpool commands

The snat command assigns a translation address to an IP address within the iRule, instead of using SNAT screens within the BIG-IP Configuration utility.

The snatpool command also assigns a translation address to an IP address. Unlike the snat command, the snatpool command causes LTM to select the translation address from a specified SNAT pool.

Administrative partitions

• iRules can reference any object, regardless of the partition in which the referenced object resides. For example, an iRule in partition_a can contain a pool statement that specifies a pool residing in partition_b.

• We can remove iRule assignments only from virtual servers that reside in the current Write partition or in partition Common.

• We can associate an iRule only with virtual servers that reside in the current Write partition or in partition Common.

• We can associate an existing iRule with multiple virtual servers. In this case, the iRule becomes the only iRule that is associated with each virtual server in the current Write partition. Because this command overwrites all previous iRule assignments, F5 does not recommend use of this command.

iRule evaluation

If no iRule exists, LTM directs incoming traffic to the default pool assigned to the virtual server that receives that traffic. To have LTM to direct certain kinds of connections to other destinations write an iRule. iRules are evaluated whenever an event occurs specified in the iRule. For example, if an iRule includes the event declaration CLIENT_ACCEPTED, the iRule is triggered whenever LTM accepts a client connection. LTM then follows the directions in the remainder of the iRule to determine the destination of the packet.

Event types

Event	Example
Global	CLIENT_ACCEPTED
HTTP	HTTP_REQUEST
SSL	CLIENTSSL_HANDSHAKE
Authentication	AUTH_SUCCESS

iRule context

To change the context from the default, for every event specified within an iRule, specify a context denoted by the keywords clientside or serverside.

The example shows my_iRule1, which includes the event declaration CLIENT_ACCEPTED, as well as the iRule command IP::remote_addr. The IP address returned by the iRule command is that of the client, because the default context of the event declaration CLIENT_ACCEPTED is clientside.

when CLIENT_ACCEPTED 
{
  if { [IP::addr [IP::remote_addr] equals 10.1.1.80] } 
  {
     pool my_pool1
  }
}

If the event declaration SERVER_CONNECTED is included in an iRule as well as the iRule command IP::remote_addr, the IP address that the iRule command returns is that of the server, because the default context of the event declaration SERVER_CONNECTED is serverside.

We can explicitly specify the clientside and serverside keywords to alter the behavior of iRule commands. The following example shows the event declaration SERVER_CONNECTED and explicitly specifies the clientside keyword for the iRule command IP::remote_addr. In this case, the IP address that the iRule command returns is that of the client, despite the server-side default context of the event declaration.

when SERVER_CONNECTED 
{
  if { [IP::addr [IP::addr [clientside {IP::remote_addr}] equals 10.1.1.80] } 
  {
     discard
  } 
 }

iRules assignment to a virtual server

The LTM processes duplicate iRule events in the order listed. An iRule event can therefore terminate the triggering of events, thus preventing LTM from triggering subsequent events.

If an iRule references a profile, LTM processes this type of iRule last, regardless of its order in the list of iRules assigned to a virtual server.

Statement commands

Statement commands enable LTM to perform different actions. For example:

• Specify the pools or servers to direct traffic
• Specify translation addresses for implementing SNAT connections
• Specify objects such as data groups or a persistence profiles

Query and manipulation commands

Query for specific data contained in the header or content of a request or response. We can manipulate that data by inserting, replacing, and removing data, as well as setting certain values found in headers and cookies.

For example, use IP::idle_timeout to query for the current idle timeout value set in a packet header, and then load balance the packet accordingly. We can also set the idle timeout to a specific value.

iRule query and manipulation commands are grouped into categories called namespaces. Except for commands in the global namespace, each iRule query or manipulation command includes the namespace in its command name. For example, one of the commands in the IP namespace is IP::idle_timeout. One of the commands in the HTTP namespace is HTTP::header.

Utility commands

Use utility commands to:

• parse and retrieve content
• encode data into ASCII format
• verify data integrity
• retrieve information about active pools and pool members

iRules and profiles

Read the value of profile settings specified within the iRule. iRules can also override values for certain settings. We can apply configuration values to individual connections that differ from the values LTM applies to most connections passing through a virtual server.

The profile command

When specifying the PROFILE command, name a profile type and setting. The iRule finds the named profile type assigned to the virtual server and reads the value of the setting specified in the PROFILE command sequence. The iRule can then use this information to manage traffic.

For example, we can specify the command PROFILE::tcp idle_timeout within the iRule. LTM finds the TCP profile that is assigned to the virtual server (for example, my_tcp) and queries for the value assigned to the Idle Timeout setting.

Commands that override profile settings

Some iRule commands for querying and manipulating header and content data have equivalent settings within various profiles. Using those commands in an iRule, and an event triggers that iRule, LTM overrides the values of those profile settings, using the value specified within the iRule instead.

For example, to specify a different buffer size for a particular type of HTTP connection, include the command HTTP::compress_buffer_size in the iRule, specifying a different value than the value in the HTTP profile.

Data groups

A data group is a group of related elements, such as a set of IP addresses for AOL clients. Specifying a data group along with the class match command or the contains operator eliminates the need to list multiple values as arguments in an iRule expression.

We can define three types of data groups:

• address
• integer
• string

Pre-configured data groups:

• private_net
• images
• aol

Do not attempt to modify or delete any of the pre-configured data groups. We can manage only those data groups we have permission to manage, based on the user role and partition access assignment.

Class match command

Select a pool based on whether the command being used in the iRule represents a member of a specific data group. For example, if the value of IP::remote_addr is a member of the data group AOL, load balance incoming AOL connections to the pool aol_pool.

when CLIENT_ACCEPTED 
{
  if { [class match [IP::remote_addr] equals aol] } 
  { 
     pool aol_pool
  } 
  else 
  {
     pool all_pool
  }
}

Storage options

We can store data groups in-line or externally.

With in-line storage, LTM automatically saves data groups in their entirety in the bigip.conf file.

In general, in-line storage uses additional system resources due to extensive searching requirements on large data groups. For this reason, LTM offers the ability to store the data groups externally, outside of the bigip.conf file. The bigip.conf file will contain only the filename and meta-data for the data group. The external data group file is stored as a comma-separated list of values (CSV format).

To create an external data group, first import a file from another location, using the System options of the BIG-IP Configuration utility. Then use the Local Traffic iRules screens to create an external data group that is based on the imported file.

External data groups can scale to greater than 10,000,000 entries, depending on platform hardware and available memory (8 GB, or more, memory is recommended). Data groups with larger data items can be supported with fewer entries. Updates to external data groups are completely atomic: for example, the system updates a data group only after the new data successfully completes loading. Use the command [class exists xyz] to check whether a data group has finished loading.

iFiles

We can reference an iFile from within an iRule, based on a specific iRule event.

To create an iFile,

• Import a file to the BIG-IP system from another system.
• From the BIG-IP Configuration utility go to the Local Traffic option on the Main tab.

iFile commands

To reference the iFiles from within an iRule:

• [ifile get IFILENAME]
• [ifile listall]
• [ifile attributes IFILENAME]
• [ifile size IFILENAME]
• [ifile last_updated_by IFILENAME]
• [ifile last_update_time IFILENAME]
• [ifile revision IFILENAME]
• [ifile checksum IFILENAME]
• array set [file attributes IFILENAME]

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"
  
     }
  }
}
  

Local traffic management

Local traffic management includes virtual servers, nodes, and server pools. Virtual servers receive incoming traffic, perform basic destination IP address translation, and direct traffic to server nodes, which are grouped together in pools.

To configure a basic local traffic management system, use the BIG-IP Configuration utility.

Network map

The Network Map provides a hierarchical, visual view of BIG-IP local traffic manager (LTM) components (virtual servers, pools, and pool members), their relationships, and respective statuses on the BIG-IP system.

• Sort by Status or Name
• Filter
• Filter - Advanced
• Sort by Partition
• View the details of a network object
• View advanced configuration details of a linked object in the Inspector
• View Network Statistics or a Map
• Refresh the Network Map

To view the network map, from the BIG-IP Configuration utility:

Main tab > Local Traffic > Network Map

Refresh the web browser to get the most up-to-date Network Map data.

Virtual servers

Virtual servers are traffic-management objects on the BIG-IP system. They are represented by a virtual IP address and a service, such as 192.168.20.10:80. The virtual server listens for traffic and, using destination address translation, directs traffic to pool destinations.

Assign profiles to a virtual server to customize traffic. For example:

• enable compression on HTTP request data
• decrypt and re-encrypt SSL connections
• verify SSL certificates

We can assign a custom profile to the virtual server for each type of traffic type (TCP, UDP, HTTP, SSL, SIP, and FTP)

When creating a virtual server, specify the pool or pools to use as the destination. Also configure:

• Profiles
• SNATs
• iRules
• Session persistence types

To ensure that a server response returns through the BIG-IP system, we can either configure the default route on the server to be a self IP address on an internal VLAN, or we can create a SNAT and assign it to a virtual server.

Types of virtual servers

Virtual server	Description
Standard	Directs client traffic to a load balancing pool. Upon create, assigned an existing default pool. Also known as a load balancing virtual server.
Forwarding (Layer 2)	Shares the same IP address as a node in an associated VLAN. Has no pool members to load balance. Additional configuration tasks required: Create a VLAN group that includes the VLAN in which the node resides Assign a self-IP address to the VLAN group Disable the virtual server on the relevant VLAN Address translation is disabled. The BIG-IP system preserves the source MAC address in the header.
Forwarding (IP)	Has no pool members to load balance. The virtual server simply forwards a packet directly to the configured destination IP address, based on what's defined in the BIG-IP system's routing table. The destination can be either a node address or a network address. Address translation is disabled. An example Forwarding (IP) virtual server is one that accepts all traffic on an external VLAN and forwards it to the virtual server destination IP address.
Performance (HTTP)	Associated with a Fast HTTP profile. Increases the speed at which the virtual server processes HTTP requests.
Performance (Layer 4)	Associated with a Fast L4 profile. Increases the speed at which the virtual server processes Layer 4 requests.
Stateless	Prevents the BIG-IP system from putting connections into the connection table for wildcard and forwarding destination IP addresses. We cannot configure SNAT automap, iRules, or port translation. We must configure a default load balancing pool. Applies to UDP traffic only.
Reject	Reject any traffic destined for the virtual server IP address.
DHCP	Relays DHCP messages between clients and servers residing on different IP networks. Known as a DHCP relay agent. Listens for DHCP client messages being broadcast on the subnet and then relays those messages to the DHCP server, which uses the BIG-IP system to send the responses back to the DHCP client. Relieves us of the tasks of installing a separate DHCP server on each subnet.
Internal	Send traffic to an intermediary server for specialized processing before the standard virtual server sends the traffic to its final destination. For example, to perform content adaptation on HTTP requests or responses, create an internal virtual server that load balances those requests or responses to a pool of ICAP servers before sending the traffic back to the standard virtual server. Supports both TCP and UDP traffic.
Message Routing	Peer-to-peer configurations. Fenefit are traffic flows using Diameter and SIP protocols.

Create a virtual server

Before creating a virtual server, create the pool to which the virtual server will send traffic. To specify a range of IP addresses as the destination IP address and to specify multiple service ports, confirm that an address list and port list already exist on the system. When creating a virtual server, specify a destination IP address and service port. All other settings on the virtual server have default values. We can change the default values of any settings to suit our needs.

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

2. In the Name field, type a unique name for the virtual server.

3. From the Type list, verify that Standard is selected.

4. In the Destination Address/Mask field:

   • To specify a single IP address, select the Host button, and type the IP address in CIDR format.

   • To specify multiple IP addresses, select the Address List button, and confirm the address list previously created appears in the box.

   The supported format is address/prefix, where the prefix length is in bits. For example, an IPv4 address/prefix is 10.0.0.1 or 10.0.0.0/24, and an IPv6 address/prefix is ffe1::0020/64 or 2001:ed8:77b5:2:10:10:100:42/64. When using an IPv4 address without specifying a prefix, the BIG-IP system automatically uses a /32 prefix. The IP address or addresses for this field must be on the same subnet as the external self-IP address.

5. In the Service Port field:

   • To specify a single service port or all ports, confirm the Port button is selected, and type or select a service port.

   • To specify multiple ports other than all ports, select the Port List button, and confirm the port list previously created appears in the box.

6. Retain the default values for all other settings.

7. From the Default Pool list, choose the pool we created.

After performing this task, we have a virtual server that listens for application traffic and acts according to the values configured within the virtual server.

Destination address

When creating a virtual server, specify a destination address. We can specify either a single IP address or a list of of IP addresses, or a range of addresses, in IPv4 or IPv6 format:

• When specifying a single IP address, a virtual server can listen for client connections destined for the address and then direct them to a server in a server pool. If we do not append a prefix (in CIDR notation) to the address, the default prefix is /32.

• When specifying a list of addresses, we must have previously created the address list, using the Shared Objects screens of the BIG-IP Configuration utility. Once created, the address list appears in the Address List box in the virtual server configuration. The virtual server can then listen for client connections destined for any address in the list of IP addresses and then direct the connections to a server in a server pool.

On a virtual server, we can also specify address lists and port lists for source addresses and ports.

Connection rate limiting

When creating a virtual server, we can configure a connection rate limit, in connections per second, that the BIG-IP system will allow for that virtual server. Setting a connection rate limit helps the system detect Denial of Service attacks, where too many connection requests can flood a virtual server. When the connection rate exceeds the configured connection rate limit, the system handles the excessive connections in different ways, depending on the connection type, either TCP or UDP:

• When the connection rate limit is exceeded for TCP connections, the BIG-IP system issues TCP resets and logs TCP reset messages, citing the exceeded connection rate limit as the cause for the resets.

• When the connection rate limit is exceeded for UDP connections, the BIG-IP system simply drops the connections.

Wildcard servers

Besides directing client connections destined for a specific network or subnet, a virtual server can also direct client connections that have a specific destination IP address that the virtual server does not recognize, such as a transparent device. This type of virtual server is known as a wildcard virtual server. Examples of transparent devices are firewalls, routers, proxy servers, and cache servers. Wildcard virtual servers are a special type of virtual server that have a network IP address as the specified destination address instead of a host IP address. When the BIG-IP system does not find a specific virtual server that matches a client's destination IP address, the BIG-IP system matches the client's destination IP address to a wildcard virtual server, designated by an IP address of 0.0.0.0. The BIG-IP system then forwards the client's packet to one of the firewalls or routers assigned to that virtual server. Wildcardvirtual servers do not translate the destination IP address of the incoming packet.

Default and port-specific wildcard virtual servers

There are two kinds of wildcard virtual servers:

Default wildcard virtual servers

Uses port 0 and handles traffic for all services. A wildcard virtual server allows traffic from all external VLANs by default. However, we can specifically disable any VLANs we do not want the default wildcard virtual server to support. Disabling VLANs for the default wildcard virtual server is done by creating a VLAN disabled list. Note that a VLAN disabled list applies to default wildcard virtual servers only. We cannot create a VLAN disabled list for a wildcard virtual server that is associated with one VLAN only.

Port-specific wildcard virtual servers

Handles traffic for a particular service only, and we define the virtual server using a service name or a port number. We can use port-specific wildcard virtual servers for tracking statistics for a particular type of network traffic, or for routing outgoing traffic, such as HTTP traffic, directly to a cache server rather than a firewall or router.

If we use both a default wildcard virtual server and port-specific wildcard virtual servers, any traffic that does not match either a standard virtual server or one of the port-specific wildcard virtual servers is handled by the default wildcard virtual server. F5 Networks recommends that when we define transparent nodes that need to handle more than one type of service, such as a firewall or a router, specify an actual port for the node and turn off port translation for the virtual server.

Multiple wildcard servers

We can define multiple wildcard virtual servers that run simultaneously. Each wildcard virtual server must be assigned to an individual VLAN, and therefore accepts packets from that VLAN only. In some configurations, we need to set up a wildcard virtual server on one side of the BIG-IP system to distribute connections across transparent devices. We can create another wildcard virtual server on the other side of the BIG-IP system to forward packets to virtual servers receiving connections from the transparent devices and forwarding them to their destination.

Virtual addresses

A virtual address is the specific node or network IP address with which we associate a virtual server. For example, if a virtual server's destination address and service port are 192.168.20.10:80, then the IP address 192.168.20.10 is a virtual address. We can create a many-to-one relationship between virtual servers and a virtual address. For example, we can create the three virtual servers 192.168.20.10:80, 192.168.20.10:443, and 192.168.20.10:161 for the same virtual address, 192.168.20.10.

We cannot explicitly create a virtual address; the BIG-IP system creates a virtual address whenever we create a virtual server, if the virtual address has not already been created. However, we can modify the properties of a virtual address, and we can enable and disable a virtual address. When we disable a virtual address, none of the virtual servers associated with that address can receive incoming network traffic.

When creating a virtual server, BIG-IP internally associates the virtual address with a MAC address. This in turn causes the BIG-IP system to respond to Address Resolution Protocol (ARP) requests for the virtual address, and to send gratuitous ARP requests and responses with respect to the virtual address. As an option, we can disable ARP activity for virtual addresses, in the rare case that ARP activity affects system performance. This most likely occurs only when we have a large number of virtual addresses defined on the system.

Virtual address creation

We create a virtual address indirectly when we create the first virtual server with a destination address that includes the virtual address. We do not explicitly create a virtual address. For example, if we create a virtual server with a destination address of 192.168.30.22:80, the BIG-IP system automatically creates the virtual address 192.168.30.22.

View virtual address properties

Use the BIG-IP Configuration utility to view the properties of an existing virtual address:

Local Traffic > Virtual Servers > Virtual Address List > virtual address

Modify a virtual address

We can assign a virtual address to a different traffic group, or change the conditions under which the system advertises the virtual address to dynamic routing protocols.

1. On the Main tab, click...
   Local Traffic > Virtual Servers > Virtual Address List > virtual address

2. From the Traffic Group list, select the traffic group we want the virtual address to belong to.

3. Select or clear the check box Availability to speciy the availability of the virtual address with respect to service checking.

4. From the State list, select the state of the virtual address, that is, enabled or disabled.

5. Check or clear the check box Auto Delete to configure whether the system should automatically delete the virtual address with the deletion of the last associated virtual server.

   When cleared (disabled), this setting specifies that the system should retain the virtual address, even when all associated virtual servers have been deleted.

6. To specify when the virtual address is considered available for route advertisement, select an option from the Availability Calculation list:
   • When any virtual server is available
   • When all virtual server(s) are available
   • Always

   When the virtual address is available and the Route Advertisement setting is set to Enabled, the BIG-IP system advertises the route for the virtual address.

7. Verify that the ARP check box is selected.

8. From the ICMP Echo list, select an option:

   Option	Description
   Disabled	Does not send ICMP responses.
   Always	Always sends ICMP responses, regardless of availability status. This requires an enabled virtual address.
   Selective	Internally enables or disables responses based on virtual server state: any virtual server, all virtual servers, or always, regardless of the state of any virtual server. For Selective, we must configure each relevant virtual server to notify the virtual address of its status.
   Any	Responds when any virtual server is available.
   All	Responds only when all virtual servers are available.

9. From the Route Advertisement list, select an option:

   Option	Description
   Disabled	Does not advertise the route for the virtual address, regardless of the availability status.
   Enabled	Advertises the route for the available virtual address, based on the calculation method selected in the Availability Calculation list.
   Always	Always advertises the route for the virtual address, regardless of availability status. This requires an enabled virtual address.
   Selective	We can also selectively enable ICMP echo responses, which causes the BIG-IP system to internally enable or disable responses based on virtual server state: any virtual server, all virtual servers, or always, regardless of the state of any virtual server.
   Any	Advertises the route for the virtual address when any virtual server is available.
   All	Advertises the route for the virtual address when all virtual servers are available.

10. Click Update.

Virtual address settings

Property	Description	Default
Name	Name assigned to the virtual address. This name can match the virtual IP address itself.	No default value
Partition / Path	The pathname indicating the partition/folder in which the virtual address resides.	/Common
Address	The IP address of the virtual server, excluding the service.	No default value
Traffic Group	The traffic group that contains this virtual IP address.	traffic-group-1 traffic-group-local-only
Availability	The availability of the virtual address with respect to service checking.	No default value
State	The state of the virtual address, that is, enabled or disabled.	Enabled
Auto Delete	A directive that the system should automatically delete the virtual address with the deletion of the last associated virtual server. When cleared (disabled), this setting specifies that the system should retain the virtual address even when all associated virtual servers have been deleted.	Enabled
Availability Calculation	The virtual-server conditions for which the BIG-IP system should advertise this virtual address to an advanced routing module. This setting only applies when the Route Advertisement setting is enabled (checked). Possible values are: When any virtual server is available When all virtual server(s) are available Always	When any virtual server is available
Connection Limit	The number of concurrent connections that the BIG-IP system allows on this virtual address.	0
ARP	A setting that enables or disables ARP requests for the virtual address. When this setting is disabled, the BIG-IP system ignores ARP requests that other routers send for this virtual address.	Enabled (checked)
ICMP Echo	A setting that enables, selectively enables, or disables responses to ICMP echo requests on a per-virtual address basis. When this setting is disabled, the BIG-IP system drops any ICMP echo request packets sent to virtual addresses, including standard statistics and logging. Note that the resulting behavior is affected by the value we configure for the Availability Calculation setting.	Enabled
Route Advertisement	A setting that inserts a route to this virtual address into the kernel routing table so that an advanced routing module can redistribute that route to other routers on the network. Possible values are: Disabled Does not advertise the route for the virtual address, regardless of the availability status Enabled Advertises the route for the available virtual address, based on the calculation method selected in the Availability Calculation list. Always Always advertises the route for the virtual address, regardless of availability status. This requires an enabled virtual address. Selective We can also selectively enable ICMP echo responses, which causes the BIG-IP system to internally enable or disable responses based on virtual server state: any virtual server, all virtual servers, or always, regardless of the state of any virtual server. Any Advertises the route for the virtual address when any virtual server is available. All Advertises the route for the virtual address when all virtual servers are available.	Disabled

Virtual servers and route domain IDs

Whenever we configure the Source Address and Destination Address settings on a virtual server, the BIG-IP system requires that the route domain IDs match, if route domain IDs are specified. To ensure that this requirement is met, the BIG-IP system enforces specific rules, which vary depending on whether we are modifying an existing virtual server or creating a new virtual server.

User action	Result
In the destination address, change existing route domain ID.	The system automatically changes the route domain ID on the source address to match the new destination route domain ID.
In the source address, change existing route domain ID.	If the new route domain ID does not match the route domain ID in the destination address, the system displays an error message stating that the two route domain IDs must match.
Specify a destination IP address only, with a route domain ID. Do not specify a source IP address.	The source IP address defaults to 0.0.0.0 and inherits the route domain ID from the destination IP address.
Specify source and destination addresses but no route domain IDs.	Use the default route domain.
Specify source and destination addresses and a route domain ID on each of the IP addresses.	Verify that both route domain IDs match. Otherwise, the system displays an error message.
Specify source and destination addresses and a route domain ID on one of the addresses. Exclude an ID from the other address.	The system verifies that the specified route domain ID matches the ID of the default route domain. Specifically, when one address lacks an ID, the only valid configuration is one in which the ID specified on the other address is the ID of a default route domain. Otherwise, the system displays an error message.

Virtual server and virtual address status

We can determine the status of a virtual server or virtual address, using the BIG-IP Configuration utility:

• Display the list of virtual servers or virtual addresses and view the Status column

• View the Availability property of the object. The BIG-IP Configuration utility indicates status by displaying one of several icons, distinguished by shape and color:

  • The shape of the icon indicates the status that the monitor has reported for that node.

  • The color of the icon indicates the actual status of the node.

Whenever the state of a virtual address changes, the state change generates a set of log messages. If a virtual address changes its state multiple times rapidly (such as from UP to DOWN to UP), the logging of the messages from the second state change can be unexpectedly delayed by a few seconds (typically, 3 to 4 seconds).

Clustered multiprocessing

Clustered Multiprocessing (CMP) accelerates traffic by creating a separate instance of the Traffic Management Microkernel (TMM) service for each system CPU. CMP is enabled by default whenever we create a virtual server.

Connections with 2 pool members using round-robin:

Conn01 --> BIG-IP --> TMM0 --> 10.0.0.10:443
Conn02 --> BIG-IP --> TMM1 --> 10.0.0.10:443
Conn03 --> BIG-IP --> TMM2 --> 10.0.0.10:443
Conn04 --> BIG-IP --> TMM3 --> 10.0.0.10:443
Conn05 --> BIG-IP --> TMM0 --> 10.0.0.20:443
Conn06 --> BIG-IP --> TMM1 --> 10.0.0.20:443
Conn07 --> BIG-IP --> TMM2 --> 10.0.0.20:443
Conn08 --> BIG-IP --> TMM3 --> 10.0.0.20:443

BIG-IP Configuration utility performance graphs will show multiple instances of the TMM service (tmm0, tmm1, and so on). Some statistics are displayed individually for each TMM instance. Other statistics are the combined total of all TMM instances. Connection limits for a virtual server with CMP enabled are distributed evenly across all instances of the TMM service.

F5 recommends disabling the CMP feature if we set a small connection limit on pool members (for example, a connection limit of 2 for the 8400 platform or 4 for the 8800 platform). We can enable or disable CMP for a virtual server, or we can enable CMP for a specific CPU.

Nodes

A node is a logical object that identifies the IP address of a physical resource on the network. We can explicitly create a node, or we can instruct the BIG-IP system to automatically create one when we add a pool member to a load balancing pool.

The difference between a node and a pool member is that a node is designated by the device's IP address only (10.10.10.10), while designation of a pool member includes an IP address and a service (such as 10.10.10:8). A primary feature of nodes is their association with health monitors. Like pool members, nodes can be associated with health monitors as a way to determine server status. However, a health monitor for a pool member reports the status of a service running on the device, whereas a health monitor associated with a node reports status of the device itself.

Nodes are the basis for creating a load balancing pool. For any server to be part of a load balancing pool, first create a node, that is, designate that server as a node. After designating the server as node, we can add the node to a pool as a pool member. We can also associate a health monitor with the node, to report the status of that server.

Create a node

Local traffic pools use nodes as target resources for load balancing. A node is an IP address or a FQDN that represents a server resource that hosts applications. An alternate way to create a node is to create a pool member. When we create a pool member, the BIG-IP system creates the corresponding node for you.

1. On the Main tab, click:
   Local Traffic > Nodes > Create button

2. For the Address field:

   1. To specify the node by its IP address, click Nodes and type an IP address.

   2. To specify the node by a fully-qualifed domain name (FQDN), click FQDN and type the node's FQDN.

3. In the Configuration area of the screen, configure the settings as needed or retain the default values.

4. If we chose FQDN for the Address setting, then in the FQDN area of the screen, configure the settings as needed or retain the default values.

5. Click Finished. The screen refreshes, and the new node appears in the node list.

Node address setting

If we are using a route domain other than route domain 0, we can append a route domain ID to this node address. For example, if the node address applies to route domain 1, then we can specify a node address of 10.10.10.10.:%1.

Node status

At any time, we can determine the status of a node, using the BIG-IP Configuration utility. We can find this information by displaying the list of nodes and viewing the Status column, or by viewing the Availability property of a node. The BIG-IP Configuration utility indicates status by displaying one of several icons, distinguished by shape and color:

• The shape of the icon indicates the status that the monitor has reported for that node.
• The color of the icon indicates the actual status of the node.

We can manually set the availability of a node with the Manual Resume attribute of the associated health monitor.

Server node state

A node in a server pool must be enabled in order to accept traffic. A node is a logical object on the BIG-IP system that identifies the IP address of a physical resource on the network. When we disable a node, the BIG-IP system allows existing connections to time out or end normally. In this case, by default, the only new connections that the node accepts are those that belong to an existing persistence session.

Additional node configuration options

Associate a health monitor with a node

Use the BIG-IP system to monitor the health or performance of our nodes by associating monitors with those nodes. This is similar to associating a monitor with a load balancing pool, except that in the case of nodes, we are monitoring the IP address, whereas with pools, we are monitoring the services active on the pool members.

The BIG-IP system can associate pre-configured monitors with nodes, depending on the type of traffic. We can also create our own custom monitors and associate them with nodes. The only pre-configured monitors that are not available for associating with nodes are monitors specifically designed to monitor pools or pool members rather than nodes. Any monitor associated with a node must reside either in partition Common or in the partition that contains the node. There are two ways we can associate a monitor with a node: by assigning the same monitor (that is, a default monitor) to multiple nodes at the same time, or by explicitly associating a monitor with each node as we create it.

Automatic node creation

If we create a pool member without first creating the parent node,the BIG-IP system automatically creates the parent node for you. Fortunately, we can configure the BIG-IP system to automatically associate one or more monitor types with every node that the BIG-IP system creates. This eliminates the task of having to explicitly choose monitors for each node. Keep the following in mind when working with default monitors:

• If a user with permission to manage objects in partition Common disables a monitor that is designated as the default monitor for nodes (such as the icmp monitor), this affects all nodes on the system. Ensure that the default monitor for nodes always resides in partition Common.

• To specify default monitors, we must have the Administrator user role assigned to our user account.

• If all nodes reside in the same partition, the default monitor must reside in that partition or in partition Common. If nodes reside in separate partitions, then the default monitor must reside in partition Common.

Explicit node creation

We can explicitly create a node, rather than having LTM create the node automatically. When we create the node, we can either associate non-default monitors with the node, or associate the default monitors with the node.

Node availability

Specify the minimum number of health monitors that must report a node as being available to receive traffic before the BIG-IP system reports that node as being in an up state.

Ratio weight setting

When we are using the Ratio load balancing method, we can assign a ratio weight to each node in a pool. The BIG-IP system uses this ratio weight to determine the correct node for load balancing. Note that at least one node in the pool must have a ratio value greater than 1. Otherwise, the effect equals that of the Round Robin load balancing method.

Connection rate limit setting

The connection rate limit setting specifies the maximum rate of new connections allowed for the node. When specify a connection rate limit, the system controls the number of allowed new connections per second, thus providing a manageable increase in connections without compromising availability. The default value of 0 specifies that there is no limit on the number of connections allowed per second.

Additional FQDN options

A node object has some optional FQDN settings we can configure.

FQDN address types

When we use FQDNs to identify nodes, we must specify whether the FQDN of the node resolves to an IPv4 or IPv6 address.

Auto Populate option

Specifies whether the system automatically creates ephemeral nodes using the IP addresses returned by the resolution of a DNS query for a node defined by an FQDN. The default value is Enabled. When set to Enabled, the system generates an ephemeral node for each IP address returned in response to a DNS query for the FQDN of the node. Additionally, when a DNS response indicates the IP address of an ephemeral node no longer exists, the system deletes the ephemeral node. When set to Disabled, the system resolves a DNS query for the FQDN of the node with the single IP address associated with the FQDN.

Query intervals

Specify intervals for when a query occurs. When the DNS server is up, the monitor probes three times, and marks the server down if there is no response within the span of three times the interval value, in seconds. The default value is 3600 seconds.

Instead of typing an interval, we can enable the Time to Live (Use TTL) option. When the DNS server is down, the associated monitor continues polling as long as the server is down. The default value, in seconds, is 5.

Pools

A pool is a logical set of devices, such as web servers, grouped together to receive and process traffic. Instead of sending client traffic to the destination IP address specified in the client request, the BIG-IP system sends the request to any of the nodes that are members of that pool. A pool consists of pool members. A pool member is a logical object that represents a physical node on the network. Once we have assigned a pool to a virtual server, the BIG-IP system directs traffic coming into the virtual server to a member of that pool. An individual pool member can belong to one or multiple pools.

We can create three types of pools on the system:

Server pools	Contains server nodes that process application traffic. The most common type of server pool contains web servers. One of the properties of a server pool is a load balancing method used to select a pool member for processing a request. The default load balancing method is Round Robin, which sends each incoming request to the next available member of the pool, distributing requests evenly across the servers in the pool.
Gateway pools:	A gateway pool is a pool of routers.
Clone pools	Use a clone pool to send traffic to a pool of intrusion detection systems (IDSs) or sniffer devices, which monitor network traffic and identify suspicious patterns. A clone pool receives all of the same traffic that the server pool receives.

Create a server pool

The server pool identifies which servers we want the virtual server to send client requests to. Optionally, we can identify the servers by their FQDNs instead of their IP addresses. In this way, the system automatically updates pool members whenever we make changes to their corresponding server IP addresses.

1. Decide on the IP addresses or FQDNs for the servers to include in the server pool.

2. If our system is using DHCP, make sure our DNS servers are not configured for round robin DNS resolutions; instead, they should be configured to return all available IP addresses in a resolution.

3. From the BIG-IP Configuration Utility,click...
   Main tab > Local Traffic > Pools > Create

4. In the Name field, type a unique name for the pool.

5. For the Health Monitors setting, from the Available list, select a monitor and move the monitor to the Active list. A pool containing nodes represented by FQDNs cannot be monitored by inband or sasp monitors.

6. From the Load Balancing Method list, select how the system distributes traffic to members of this pool. The default is Round Robin.

7. For the New Members setting, add each server to include in the pool:

   1. Select New Node or New FQDN Node.

   2. (Optional) In the Node Name field, type a name for the node.

   3. If we chose New Node, then in the Address field, type the IP address of the server. If we chose New FQDN Node, then in the FQDNfield, type the FQDN of the server. To use FQDNs instead of IP addresses, we should still type at least one IP address. Typing one IP address ensures that the system can find a pool member if a DNS server is not available.

   4. For the Service Port option, pick a service from the list.

   5. If we are using FQDNs for the server names, then for Auto Populate, keep the default value of Enabled. When we leave Auto Populate turned on, the system creates an ephemeral node for each IP address returned as an answer to a DNS query. Also, when a DNS answer shows that the IP address of an ephemeral node no longer exists, the system deletes the ephemeral node.

   6. Click Add.

   7. Do this step again for each node.

8. Click Finished.

Create a clone pool

To configure a clone pool:

1. Create a pool of IDS or sniffer devices

2. Assign the pool as a clone pool to a virtual server.

The clone pool feature is the recommended method for copying production traffic to IDS systems or sniffer devices. Note that when we create the clone pool, the service port assigned to each node is irrelevant; we can choose any service port. Also, when we add a clone pool to a virtual server, the system copies only new connections; existing connections are not copied. We can configure a virtual server to copy client-side traffic, server-side traffic, or both:

• A client-side clone pool causes the virtual server to replicate client-side traffic (prior to address translation) to the specified clone pool.
• A server-side clone pool causes the virtual server to replicate server-side traffic (after address translation) to the specified clone pool.

We can configure an unlimited number of clone pools on the BIG-IP system.

Pool and pool member status

The BIG-IP Configuration utility indicates status by displaying one of several icons, distinguished by shape and color, for each pool or pool member:

• The shape of the icon indicates the status that the monitor has reported for that pool or pool member. For example, a circle-shaped icon indicates that the monitor has reported the pool member as being up, whereas a diamond-shaped icon indicates that the monitor has reported the pool member as being down.

• The color of the icon indicates the actual status of the node itself. For example, a green shape indicates that the node is up, whereas a red shape indicates that the node is down. A black shape indicates that user-intervention is required.

At any time, we can determine the status of a pool. The status of a pool is based solely on the status of its members. Use the BIG-IP Configuration utility to find this information by viewing the Availability property of the pool. We can also find this information by displaying the list of pools and checking the Status column.

Pool features

We can configure the BIG-IP system to perform a number of different operations for a pool. For example, we can:

• Associate health monitors with pools and pool members
• Enable or disable SNAT connections
• Rebind a connection to a different pool member if the originally-targeted pool member becomes unavailable
• Specify a load balancing algorithm for a pool
• Set the Quality of Service or Type of Service level within a packet
• Assign pool members to priority groups within a pool

We use the BIG-IP Configuration utility to create a load balancing pool, or to modify a pool and its members. When creating a pool, the BIG-IP system automatically assigns a group of default settings to that pool and its members. We can retain these default settings or modify them. Also, we can modify the settings at a later time, after we have created the pool.

Associate a health monitor with a pool

Health monitors ensure a server is in an up state and is able to receive traffic. To associate a monitor with an entire pool of servers, we do not need to explicitly associate that monitor with each individual server. Instead, we can simply assign the monitor to the pool itself. the BIG-IP system then automatically monitors each member of the pool. The BIG-IP system can associate pre-configured monitors with pools, depending on the type of traffic. We can also create our own custom monitors and associate them with pools. The only monitor types that are not available for associating with pools are monitors specifically designed to monitor nodes and not pools or pool members. That is, the destination address in the monitor specifies an IP address only, rather than an IP address and a service port.

These monitor types are:

• ICMP
• TCP Echo
• Real Server
• SNMP DCA
• SNMP DCA Base
• WMI

With the BIG-IP system, we can configure our monitor associations in many useful ways:

• We can associate a health monitor with an entire pool instead of an individual server. In this case, the BIG-IP system automatically associates that monitor with all pool members, including those we add later. When we remove a member from a pool, the BIG-IP system no longer monitors that server.

• When a server that is designated as a pool member allows multiple processes to exist on the same IP address and port, we can check the health or status of each process. To do this, we can add the server to multiple pools, and then within each pool, associate a monitor with the that server. The monitor we associate with each server checks the health of the process running on that server.

• When associating a monitor with an entire pool, we can exclude an individual pool member from being associated with that monitor. In this case, we can associate a different monitor for that particular pool member, or we can exclude that pool member from health monitoring altogether. For example, we can associate pool members A, B, and D with the http monitor, while we associate pool member C with the https monitor.

• We can associate multiple monitors with the same pool. For instance, we can associate both the http and https monitors with the same pool.

Pool member availability

Minimum number of health monitors. Before Local Traffic Manager can report the pool member as being in an up state, this number of monitors, at a minimum, must report a pool member as being available to receive traffic.

SNATs and NATs

When configuring a pool, we can disable any secure network address translations (SNATs) or network address translations (NATs) connections that use the pool. By default, these settings are enabled. We change this setting by displaying the Properties screen for that pool. We can configure a pool to disable SNAT or NAT connections for a specific service. In this case, we could create a separate pool to handle all connections for that service, and then disable the SNAT or NAT for that pool.

Action when a service becomes unavailable

Action to take when the service on a pool member becomes unavailable. Possible actions are:

• None. Default action.
• The BIG-IP system sends an RST (TCP-only) or ICMP message.
• the BIG-IP system simply cleans up the connection.
• the BIG-IP system selects a different node.

We should configure the system to select a different node in certain cases only, such as:

• When the relevant virtual server is a Performance (Layer 4) virtual server with address translation disabled.
• When the relevant virtual server's Protocol setting is set to UDP.
• When the pool is a gateway pool (that is, a pool or routers)

Slow ramp time

When we take a pool member offline, and then bring it back online, the pool member can become overloaded with connection requests, depending on the load balancing method for the pool. For example, if we use the Least Connections load balancing method, the system sends all new connections to the newly-enabled pool member (because, technically, that member has the least amount of connections). With the slow ramp time feature, we can specify the number of seconds that the system waits before sending traffic to the newly-enabled pool member. The amount of traffic is based on the ratio of how long the pool member is available compared to the slow ramp time, in seconds. Once the pool member is online for a time greater than the slow ramp time, the pool member receives a full proportion of the incoming traffic.

Type of Service (ToS) level

Another pool feature is the Type of Service (ToS) level. The ToS level is one means by which network equipment can identify and treat traffic differently based on an identifier. As traffic enters the site, the BIG-IP system can set the ToS level on a packet. Using the IP ToS to Server ToS level defined for the pool to which the packet is sent. the BIG-IP system can apply an iRule and send the traffic to different pools of servers based on that ToS level. The BIG-IP system can also tag outbound traffic (that is, the return packets based on an HTTP GET) based on the IP ToS to Client ToS value set in the pool. That value is then inspected by upstream devices and given appropriate priority. For example, to configure a pool so that a ToS level is set for a packet sent to that pool, we can set both the IP ToS to Client level and the IP ToS to Server levels to 16. In this case, the ToS level is set to 16 when sending packets to the client and when sending packets to the server. If we change the ToS level on a pool for a client or a server, existing connections continue to use the previous setting.

Quality of Service (QoS) level

In addition to the ToS level, the QoS level is a means by which network equipment can identify and treat traffic differently based on an identifier. The QoS level specified in a packet enforces a throughput policy for that packet. As traffic enters the site, the BIG-IP system can set the QoS level on a packet. Using the Link QoS to Server QoS level defined for the pool to which the packet is sent, the BIG-IP system can apply an iRule that sends the traffic to different pools of servers based on that QoS level.

The BIG-IP system can also tag outbound traffic (that is, the return packets based on an HTTP GET) based on the Link QoS to Client QoS value set in the pool. That value is then inspected by upstream devices and given appropriate priority. For example, to configure a pool so that a QoS level is set for a packet sent to that pool, we can set the Link QoS to Client level to 3 and the Link QoS to Server level to 4. In this case, the QoS level is set to 3 when sending packets to the client, and set to 4 when sending packets to the server.

Number of reselect tries

Number of times that the system tries to contact a new pool member after a passive failure. A passive failure consists of a server-connect failure or a failure to receive a data response within a user-specified interval. The default value of 0 indicates no reselects. This setting is for use primarily with TCP profiles. Using this setting with a Fast L4 profile is not recommended.

TCP request queue

TCP request queuing provides the ability to queue connection requests that exceed the capacity of connections for a pool, pool member, or node, as determined by the connection limit. Consequently, instead of dropping connection requests that exceed the capacity of a pool, pool member, or node, TCP request queuing enables those connection requests to reside within a queue in accordance with defined conditions until capacity becomes available. When using session persistence, a request becomes queued when the pool member connection limit is reached. Without session persistence, when all pool members have a specified connection limit, a request becomes queued when the total number of connection limits for all pool members is reached. Conditions for queuing connection requests include:

• The maximum number of connection requests within the queue, which equates to the maximum number of connections within the pool, pool member, or node. Specifically, the maximum number of connection requests within the queue cannot exceed the cumulative total number of connections for each pool member or node. Any connection requests that exceed the capacity of the request queue are dropped.

• The availability of server connections for reuse. When a server connection becomes available for reuse, the next available connection request in the queue becomes dequeued, thus allowing additional connection requests to be queued.

• The expiration rate of connection requests within the queue. As queue entries expire, they are removed from the queue, thus allowing additional connection requests to be queued.

Connection requests within the queue become dequeued when:

• The connection limit of the pool is increased.
• A pool member's slow ramp time limit permits a new connection to be made.
• The number of concurrent connections to the virtual server decreases below the connection limit.
• The connection request within the queue expires.

Pool member features

A pool member consists of a server's IP address and service port number. An example of a pool member is 10.10.10.1:80. Pool members have a number of features we can configure when we create the pool. By design, a pool and its members always reside in the same administrative partition.

Ratio weights

When using a ratio-based load balancing method for distributing traffic to servers within a pool, we can assign a ratio weight to the corresponding pool members. The ratio weight determines the amount of traffic that the pool member receives. The ratio-based load balancing methods are: Ratio (node, member, and sessions), Dynamic Ratio (node and member), and Ratio Least Connections (node and member).

Priority group numbers

Assign a priority number to the pool member. The BIG-IP system distributes traffic in the pool according to the priority number assigned to the pool member. For example, pool members assigned to group 3, instead of pool members in group 2 or group 1, normally receive all traffic. Thus, members that are assigned a high priority receive all traffic until the load reaches a certain level or some number of members in the group become unavailable. If either of these events occurs, some of the traffic goes to members assigned to the next higher priority group.

This setting is used in tandem with the pool feature known as priority group activation. We use the priority group activation feature to configure the minimum number of members that must be available before the BIG-IP system begins directing traffic to members in a lower priority group.

Connection limits

Connection limits

Maximum number of concurrent connections allowed for a pool member. Note that the default value of 0 (zero) means that there is no limit to the number of concurrent connections that the pool member can receive.

Connection rate limits

Maximum rate of new connections allowed for the pool member. When specify a connection rate limit, the system controls the number of allowed new connections per second, thus providing a manageable increase in connections without compromising availability. The default value of 0 specifies that there is no limit on the number of connections allowed per second. The optimal value to specify for a pool member is between 300 and 5000 connections. The maximum valued allowed is 100000.

Health monitors

Explicit monitor associations

Once we have associated a monitor with a pool, the BIG-IP system automatically associates that monitor with every pool member, including those members add to the pool later. However, in some cases we might want the monitor for a specific pool member to be different from that assigned to the pool. In this case, we must specify to explicitly associate a specific monitor with the individual pool member. We can also prevent the BIG-IP system from associating any monitor with that pool member.

Explicit monitor association for a pool member

The BIG-IP system contains many different monitors can associate with a pool member, depending on the type of traffic to monitor. We can also create our own custom monitors and associate them with pool members. The only monitor types that are not available for associating with pool members are monitors that are specifically designed to monitor nodes and not pools or pool members. These monitor types are:

• ICMP
• TCP Echo
• Real Server
• SNMP DCA
• SNMP DCA Base
• WMI

Multiple monitor association for a pool member

• Associate more than one monitor with a member of a single pool. For example, we can create monitors http1, http2, and http3, where each monitor is configured differently, and associate all three monitors with the same pool member. In this case, the pool member is marked as down if any of the checks is unsuccessful.

• Assign one IP address and service to be a member of multiple pools. Then, within each pool, we can associate a different monitor with that pool member. For example, suppose we assign the pool member 10.10.10.20:80 to three separate pools: my_pool1, my_pool2, and my_pool3. We can then associate all three custom HTTP monitors to that same pool member. The result is that the BIG-IP system uses the http1 monitor to check the health of pool member 10.10.10.20:80 in my_pool1, the http2 monitor to check the health of pool member 10.10.10.20:80 in my_pool2, and the http3 monitor to check the health of pool member 10.10.10.20:80 in my_pool3.

We can make multiple-monitor associations either at the time we add the pool member to each pool, or by later modifying a pool member's properties.

Availability requirement

We can specify a minimum number of health monitors. Before the BIG-IP system can report the pool member as being in an up state, this number of monitors, at a minimum, must report a pool member as being available to receive traffic.

Pool member state

We can enable or disable individual pool members. A pool member is a logical object on the BIG-IP system that represents a specific server node and service. For example, a node with an IP address of 12.10.10.3 can have a corresponding pool member 12.10.10.3:80. When we disable a pool member, the node continues to process any active connections or any connections for the current persistence session.

Local traffic operations

Use BIG-IP Configuration utility to manage the availability of server resources on the network by enabling and disabling certain local traffic server objects. These objects consist of server nodes and pool members, as well as virtual servers and their associated virtual addresses.

Server node state

A node in a server pool must be enabled in order to accept traffic. A node is a logical object on the BIG-IP system that identifies the IP address of a physical resource on the network. When we disable a node, the BIG-IP system allows existing connections to time out or end normally. In this case, by default, the only new connections that the node accepts are those that belong to an existing persistence session.

View the state of a node

To determine whether a node is currently enabled or disabled.

1. Click:
   Main table > Local Traffic > Nodes > node name

2. Locate the State property and view the selected value.

3. Click Cancel.

Enable a node

When we enable a node, the BIG-IP system allows all types of connections, including persistent connections.

To enable a disabled local traffic node:

Main tab > Local Traffic > Nodes > node name (check box) > Enable

After performing this task, the selected node is available to process application traffic.

Disable a node except for persistent/active connections

When we disable a node, the BIG-IP system disallows any incoming connections, but continues to process any persistent or active connections.

Disable an enabled local traffic node:

Main tab > Local Traffic > Nodes > node name (check box) > Disable button

After performing this task, the selected node is disabled.

Force a node with active connections offline

Disable a local traffic node to disallow all connections except for active connections. The BIG-IP system disallows any incoming connections (including persistent connections), but continues to process active connections. When all active connections have been processed, the node is fully offline.

1. On the Main tab, click...
   Local Traffic > Nodes > node name

2. For the State property, click...
   Forced Offline (Only active connections allowed)

3. At the bottom of the screen, click Update.

After performing this task, the selected node will be offline when all active connections have finished processing.

Pool member state

We can enable or disable individual pool members. A pool member is a logical object on the BIG-IP system that represents a specific server node and service. For example, a node with an IP address of 12.10.10.3 can have a corresponding pool member 12.10.10.3:80. When we disable a pool member, the node continues to process any active connections or any connections for the current persistence session.

View the state of a pool member

Before performing this task, determine the pool member to force offline. We can force a pool member, while allowing active connections to be completed before the BIG-IP system takes the member offline.

1. On the Main tab, click...
   Local Traffic > Pools > Pool List > pool name > Members > Member list > pool member.

2. Locate the State property and view the selected value.

3. Click Cancel.

Enable a pool member

Before performing this task, verify that the corresponding server node address is enabled. We can enable a pool member that was previously disabled and is currently in an Offline state. We typically enable a pool member when to allow the associated virtual server to send traffic to that service on the server node. For example, to allow the BIG-IP system to resume sending traffic to the http service on node 12.10.10.3, we can enable pool member 12.10.10.3:80.

On the Main tab, click...

Local Traffic > Pools > pool name > Members > pool member name (check box) > Enable

After performing this task, the service on the associated server node is available for processing traffic.

Disable a pool member except for persistent/active connections

Before performing this task, determine the pool member to disable. We can disable a pool member that was previously enabled and is currently in an Available state. We typically disable a pool member to prevent the associated virtual server from sending traffic to that service on the server node. For example, to prevent the BIG-IP system from sending traffic to the http service on node 12.10.10.3, we can disable pool member 12.10.10.3:80. When we perform this task, the BIG-IP system, by default, allows persistent and active connections to be completed before the BIG-IP system marks the pool member as Offline.

On the Main tab, click...

Local Traffic > Pools > pool name > Members > pool member name (check box) > Disable button

After performing this task, the service on the relevant node is unavailable for processing traffic, except for persistent and active connections.

Force a pool member with active connections offline

Before performing this task, determine the pool member to force offline. We can force a pool member to accept no new connections, while allowing active connections to be completed before the BIG-IP system takes the member offline.

1. On the Main tab, click...
   Local Traffic > Pools > pool name > Members > pool member name
   • For the State property, click...
     Forced Offline (Only active connections allowed)

   • Click Update. The screen refreshes, and the status in the Availability area changes.

Virtual address state

Enable or disable virtual addresses to manage virtual server availability to process traffic. Disable a virtual address to drop or redirect traffic destined for virtual servers associated with that virtual address.

To enable a virtual address, on the Main tab, click...

Local Traffic > Virtual Servers > Virtual Address List > virtual address (check box) > Enable button

After performing this task, we can enable any virtual servers corresponding to this virtual address.

Disable a virtual address

We can disable a virtual address that is currently enabled. When disabled, all associated virtual servers no longer listen for traffic destined for that virtual address.

On the Main tab, click...

Local Traffic > Virtual Servers > Virtual Address List > virtual address (check box) > Disable

View the state of a virtual address

We can view the state of a virtual address in preparation for managing virtual server availability to process traffic.

On the Main tab, click...

Local Traffic > Virtual Servers > Virtual Address List > virtual address

In the State column, view its state.

Virtual server state

We can enable or disable virtual servers to manage virtual server availability to process traffic. We typically disable a virtual server when to drop or redirect traffic destined for a specific IP address and service.

View the state of a virtual server

We view the state of a virtual server to determine whether a virtual server is currently enabled or disabled.

1. On the Main tab
   Local Traffic > Virtual Servers. virtual server

2. Locate the State property and view the selected value.

3. Click the Cancel button.

Enable a virtual server

Before enabling a virtual server, verify that the corresponding virtual address is enabled. Enable a virtual server that is currently disabled. When enabled, the virtual server listens for traffic destined for the virtual server's IP address and service and processes the traffic according to the virtual server configuration.

On the Main tab

Local Traffic > Virtual Servers virtual server > (check box) > Enable button

After performing this task, the virtual server listens for application traffic destined for both the virtual server IP address and service, and then processes the traffic accordingly.

Disable a virtual server

Disable a virtual server that is currently enabled. When disabled, the virtual server no longer listens for traffic destined for the IP address and port specified in the virtual server configuration.

On the Main tab, click...

Local Traffic > Virtual Servers > virtual server (check box) > Disable button

Traffic classes

Use when implementing optimization profiles for modules such as the Application Acceleration Manager. Classify traffic according to criteria such as source and destination IP addresses. We also define a classification ID. After defining the traffic class, and assigned the class to a virtual server, the system associates the classification ID to each traffic flow. The system regulates the flow of traffic based on the classification. When attempting to match traffic flows to a traffic class, the system uses the most specific match possible.

Create a traffic class:

1. On the Main tab, click...
   Local Traffic > Traffic Class > Create

   ...and set...

   Field	Description
   Name	Traffic class name. Case-sensitive. Letters, numbers, and underscores (_) only.
   Classification	Text string applied to data flows matching the traffic-class criteria. The system tags the traffic flow with this classification value.
   Source Address	IP address for the system to match against incoming traffic.
   Source Mask	Network mask for the specified source address.
   Source Port	Port number in the field
   Destination Address	IP address for the system to match against the traffic destination.
   Destination Mask	Network mask for the specified destination address.
   Destination Port	Port number in the field
   IP Protocol	Protocol number in the field

2. Click the Finished button.

3. Assign the class to a virtual server.

   The system associates the corresponding classification ID to traffic flows that match the specified criteria. In this way, the system can regulate the flow of traffic based on that classification.

Dynamic ratio load balancing

Configure pools that consist of either:

• RealNetworks RealServe servers
• Microsoft Windows servers equipped with Windows Management Instrumentation (WMI)
• Any server equipped with an SNMP agent such as the UC Davis SNMP agent or Windows 2000 Server SNMP agent

The BIG-IP Local Traffic Manager provides a monitor plug-in and a performance monitor for each type of server. The exception is a server equipped with an SNMP agent. In this case, the BIG-IP system provides the monitor only; no special plug-in file is required.

For each server type, this table shows the required monitor plug-in and the corresponding performance monitor types.

Server Type	Monitor plug-in	Monitor Type
RealServer Windows server	F5RealMon.dll	Real Server
RealServer UNIX server	f5realmon.so	Real Server
Windows server with WMI	f5isapi.dll or F5Isapi64.dll or F5.IsHandler.dll	WMI
Windows 2000 Server server	SNMP agent	SNMP DCA and SNMP DCA Base
UNIX server	UC Davis SNMP agent	SNMP DCA and SNMP DCA Base

Implement a RealServer monitor

For RealSystem Server systems, the BIG-I system provides a monitor plug-in that gathers the necessary metrics when we have installed the plug-in on the RealSystem Server system. Configuring a RealSystem Server for Dynamic Ratio load balancing consists of four tasks:

1. Download the monitor plug-in F5RealServerPlugin.dll from the BIG-IP system. The plug-in is located in the folder...
   /usr/local/www/docs/agents

2. Copy F5RealServerPlugin.dll to the RealServer plug-ins directory. (For example...
   C:\Program Files\RealServer\plug-ins

3. If the RealSystem Server process is running, restart it.

4. Configure a Real Server monitor

5. Associate the configured monitor with the node (a RealSystem Server)

   Set the load balancing method to Dynamic Ratio.

Install and compile a Linux or UNIX RealSystem server monitor plug-in

1. Using the .iso image, burn a CD-ROM of the BIG-IP system software.

2. On the CD:
   cd /downloads/rsplug-ins

3. On the BIG-IP system, copy file F5RealMon.src.tar.gz to /var/tmp

4. On the BIG-IP system:
   cd /var/tmp

5. Uncompress the file F5RealMon.src.tar.gz:
   tar -xvzf F5RealMon.src.tar

6. View the directory contents:
   cd F5RealMon.src
   ls -l

7. Compile the source using the instructions in the file build_unix_note.

8. Configure a Real Server monitor

9. Associate the configured monitor with the node (RealSystem Server)

10. Set the load balancing method to Dynamic Ratio.

11. Start RealSystem Server.

Implement a WMI monitor

For Windows running Windows Management Instrumentation (WMI), the BIG-IP® system provides a Data Gathering Agent for the IIS server. Configuring a Windows platform for Dynamic Ratio load balancing consists of these tasks:

• Installing the Data Gathering Agent on the IIS server
• Configuring a WMI monitor on the BIG-IP system
• Associating the monitor with the server to gather the metrics
• Creating or modifying the server pool to use the Dynamic Ratio load balancing method

To enable a user to access WMI metrics on a Windows server, we must configure the WMI monitor on the BIG-IP system correctly. The procedure for installing the Data Gathering Agent on an IIS server differs depending on whether the server is running IIS version 5.0, 6.0, or 7.0, and whether the Data Gathering Agent is the file f5isapi.dll (or f5isapi64.dll), or the file F5.IsHandler.dll. F5 Networks recommends installing only the Data Gathering Agent file that pertains to our specific configuration. Installing multiple Data Gathering Agent files could result in unwanted behavior.

IIS version support for the data gathering agent files

The procedure for installing the Data Gathering Agent on an IIS server differs depending on which IIS version the server is running and whether the Data Gathering Agent is the file f5isapi.dll, f5isapi64.dll, or F5.IsHandler.dll. This table shows each of the Data Gathering Agent files and the IIS versions that support each file.

Data Gathering Agent	IIS 5.0	IIS 6.0	IIS 7.0	IIS 7.5	IIS 8.0	IIS 8.5
f5isapi.dll (32-bit) and f5isapi64.dll (64-bit)	Yes	Yes	N/A	N/A	N/A	N/A
F5.IsHandler.dll (32-bit, 64-bit, and . NET)	N/A	Yes	Yes	Yes	Yes	Yes

Install the Data Gathering Agent F5.IsHandler.dll on an IIS 7.5 server

Do not install the files f5isapi.dll or f5isapi64.dll on IIS version 7.5. For IIS servers running version 7.5, always install the file F5.IsHandler.dll. This task installs the Data Gathering Agent F5.IsHandler.dll on an IIS 7.5 server.

1. Create a scripts directory under the directory C:\Inetpub (C:\Inetpub\scripts).
2. Create a \bin directory under the scripts directory (C:\Inetpub\scripts\bin).
3. Copy the file F5.IsHandler.dll to the directory C:\Inetpub\scripts\bin.
4. In the C:\Inetpub\scripts directory, create the file web.config.

   <?xml version="1.0" encoding="UTF-8"?>
       <configuration>
           <system.webServer>
   
               <handlers>
                   <clear />
                   <add name="F5IsHandler" 
                    path="f5isapi.dll" verb="*" 
                    type="F5.IsHandler"
                    modules="ManagedPipelineHandler" 
                    scriptProcessor="" 
                    resourceType="Unspecified"
                    requireAccess="Script" 
                    preCondition="" />
               </handlers>
   
               <security>
                   <authentication>
                       <anonymousAuthentication enabled="false" />
                   </authentication>
               </security>
           </system.webServer>
       </configuration>

   In this example, the path value f5isapi.dll appears to be a mistake but is actually correct. It is the type value F5.IsHandler that directs the server to the correct file.

5. Allow anonymous authentication to be overridden by using the appcmd command to set the override mode in the machine-level applicationHost.config file.
   appcmd set config "Default Web Site/scripts" /section:anonymousAuthentication /overrideMode:Allow /commit:APPHOST

   appcmd is located in \windows\system32\intesrv.

6. Set up a new application pool for the file F5.IsHandler.dll:

   1. From the Start menu, choose...
      Control Panel > Administrative Tools > Internet Information Services (IIS) Manager > Connections > MachineName (MachineName\UserName) > Application Pools (Right click) > Add Application Pool

   2. In the Name field, type F5 Application Pool.

   3. Click OK.

   4. From the Application Pools list, right click F5 Application Pool and choose Advanced Settings.

   5. Under the Process Model List, click Identity, and then click the button to the right of ApplicationPoolIdentity.

   6. From Built-in account select NetworkService.

   7. Click OK.

   8. Click OK.

7. Create a new application named scripts:

   1. Expand Sites.

   2. Right click Default Web Site and choose Add Application.

   3. In the Alias field, type scripts.

   4. Change the application pool, click Select, select F5 Application Pool from the Application Pool list, and click OK.

   5. For the physical path, type the directory we created in step 1 (C:\Inetpub\scripts\).

   6. Click OK.

8. Change the Authentication setting to Basic Authentication:

   1. Select scripts.

   2. In the center pane, double click Authentication.

   3. Verify that the status of all items under Authentication is Disabled, except for the Basic Authentication item. To enable or disable an authentication item, right click the name and choose Enable or Disable.

Once we have installed the plug-in, we must configure a WMI monitor, associate the configured monitor with the pool member, and set the load balancing method to Dynamic Ratio.

Install the Data Gathering Agent F5.IsHandler.dll on an IIS 8.0 or 8.5 server

Do not install the files f5isapi.dll or f5isapi64.dll on IIS version 8.0 or 8.5. For IIS servers running version 8.0 or 8.5, always install the file F5.IsHandler.dll. This task installs the Data Gathering Agent F5.IsHandler.dll on an IIS 8.0 or 8.5 server.

1. Create a scripts/bin directory:
   mkdir C:\Inetpub\scripts
   mkdir C:\Inetpub\scripts\bin

2. Copy the file F5.IsHandler.dll to: C:\Inetpub\scripts\bin

3. Allow anonymous authentication to be overridden by using the appcmd command to set the override mode in the machine-level applicationHost.config file.
   appcmd set config Default Web Site/scripts/section:anonymousAuthentication /overrideMode:Allow /commit:APPHOST

   appcmd is located in \windows\system32\intesrv.

4. Set up a new application pool for the file F5.IsHandler.dll:

   1. From the Start menu, choose:
      Control Panel > Administrative Tools > Internet Information Services (IIS) Manager > Connections > MachineName (MachineName\UserName)

   2. Right click the Application Pools menu and choose Add Application Pool.

   3. In the Name field, type F5 Application Pool.

   4. Click OK.

   5. From the Application Pools list, right click F5 Application Pool and choose Advanced Settings.

   6. Under the Process Model List, click Identity, and then click the button to the right of ApplicationPoolIdentity.

   7. From Built-in account select NetworkService.

   8. Click OK.

   9. Click OK.

5. Create a new application named scripts:

   1. Expand Sites.

   2. Right click Default Web Site and choose Add Application.

   3. In the Alias field, type scripts.

   4. Change the application pool, click Select, select F5 Application Pool from the Application Pool list, and click OK.

   5. For the physical path, type: C:\Inetpub\scripts\)

   6. Click OK.

6. Change the Authentication setting to Basic Authentication:

   1. Select scripts.

   2. In the center pane, double click Authentication.

   3. Verify that the status of all items under Authentication is Disabled, except for the Basic Authentication item. To enable or disable an authentication item, right click the name and choose Enable or Disable.

7. Add a handler mapping:

   1. Select scripts.

   2. Click Handler Mappings.

   3. In the Actions pane on the right side of the screen, click Add Managed Handler.

   4. In the Request Path field, type F5Isapi.dll. The Request Path value f5isapi.dll appears to be a mistake but is actually correct. It is the Type value F5.IsHandler that directs the server to the correct file.

   5. From the Type list, select F5.IsHandler.

   6. Type a name, such as F5 IsHandler.

   7. Click the Requested Restrictions button.

   8. Clear the check box labeled Invoke handler only if request is mapped to:

   9. Click OK.

   10. Click OK again.

   11. Configure a WMI monitor

   12. Associate the configured monitor with the pool member

   13. Set the load balancing method to Dynamic Ratio.

DNS Troubleshooting

DNS issues

• No security built in
• Malicious sites
• Malware vector
• Underprovisioning leads to distributed denial-of-service attacks on DNS.

DNS cache poisoning attack

The attacker inserts bad information in the DNS data cache. When visitors attempt to access a site, the DNS response sends them to a bogus version of the the site.

One fix is to use DNS Security Extensions (DNSSEC) to query whether an upstream DNS address is valid and digitally signs DNS data.

Tracking down DNS problems

First steps:

• Are cables connected?
• Are other people having the same problem?
• Is the domain name still registered?

Debugging steps:

• Use nslookup from your current machine to show the hostname and IP address of the DNS server configured for your computer.

• Use the BIND dig command
  • View the named site's IP address records
  • View the query route the DNS server uses to get answers from an authoritative nameserver

• Use Neustar UltraTools DNS tools

• View logs using grep on Linux and Event Viewer on Windows.

• Look in the DNS server configuration files. BIND servers have text-based config files.

• Turn on BIND debugging

• Look at the routing table with netstat -n

tcpdump

For a full description:

man tcpdump

The tcpdump utility's interface or -i option accepts only one option: Numbered interface or named VLAN.

View traffic:

tcpdump -i <option>

View the traffic on a single specific interface:

tcpdump -i 2.1

View the traffic on a specific VLAN called internal:

tcpdump -i internal

View the traffic on the management interface:

tcpdump -i eth0

View the traffic on TMM interfaces:

tcpdump -i 0.0

This can create very large files. Use filters to limit the size of the capture.

Do not attempt to run tcpdump on an interface that contains a colon.

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.

Disable name resolution:

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.

For submission to F5 Support, provide the tcpdump output in the binary file format.

Save the tcpdump output to a binary file,:

tcpdump -w <filename>

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.

Save the tcpdump output to a text file,:

tcpdump > <filename>

tcpdump > dump1.txt

Read data from a binary tcpdump file (saved using tcpdump -w):

tcpdump -r <filename>

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.

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
• Host name of the system
• Platform ID
• Product

Filters restrict the output to specified addresses, ports, and tcp flags.

• View all packets that are traveling to or from a specific IP address:

  tcpdump host <IP address>

  tcpdump host 10.90.100.1

• View all packets that are traveling from a specific IP address:

  tcpdump src host <IP address>

  tcpdump src host 10.90.100.1

• View all packets that are traveling to a particular IP address:

  tcpdump dst host <IP address>

  tcpdump dst host 10.90.100.1

Filtering on a port

• View all packets that are traveling through the BIG-IP system and are either sourced from or destined to a specific port:

  tcpdump port <port number>

  tcpdump port 80

• View all packets that are traveling through the BIG-IP system and sourced from a specific port:

  tcpdump src port <port number>

  tcpdump src port 80

• View all packets that are traveling through the BIG-IP system and destined to a specific port:

  tcpdump dst port <port number>

  tcpdump dst port 80

  Filtering on a tcp flag

  • View all packets that are traveling through the BIG-IP system that contain the SYN flag:

    tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'

  • View all packets that are traveling through the BIG-IP system that contain the RST flag:

    tcpdump 'tcp[tcpflags] & (tcp-rst) != 0'

  Use the and operator to filter for a mixture of output.

  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

Capturing packet data

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

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.

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, also use the -X flag to display ASCII encoded output along with the default HEX encoded output.

tcpdump -r dump1.bin -X src host 172.16.101.20 and dst port 80

Capture traffic from specific FQDNs or hostnames.

tcpdump -s0 -vni 0.0:nnnp host host1.example.com

Ensure that the BIG-IP system is able to resolve the FQDN or hostname to an IP address. If not, you can add a manual entry in the host file of the system.

We can specify whether IP addresses and service ports are translated to their corresponding hostnames and service names.

tcpdump -n src host 172.16.101.20 and dst port 80

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.

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.

tcpdump -nn src host 172.16.101.20 and dst port 80

Following are examples of how to combine the tcpdump options to provide the most meaningful output:

tcpdump -ni internal -w dump1.bin
tcpdump -n -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

Stopping the tcpdump utility

You can stop the tcpdump utility using the following methods:

• From an interactive session, press Ctrl + C

• If you run the tcpdump utility in the background, you can return the tcpdump session to the foreground by running: fg

• If you run multiple instances of tcpdump utility in the background, to terminate all instances at the same time:

  killall tcpdump

See also

• Packet trace analysis
• Capture internal TMM information with tcpdump
• Considerations when use the tcpdump utility with tagged VLAN traffic
• Troubleshoot LDAP authentication with tcpdump
• Overview of packet trace a BIG-IP APM Network Access tunnel with the tcpdump utility
• Troubleshoote and debugge Enterprise Manager iControl connectivity
• Save large tcpdump packet traces in limited disk space scenarios
• Use advanced tcpdump filters
• Use tcpdump to create rotating packet capture files
• Recommended methods and limitations for running tcpdump on a BIG-IP system
• Perform a packet trace and providing the results to F5 Support
• Use the tcpdump utility disables hardware checksum offloading

See also

• BIG-IP Local Traffic Management