rule cgi_rule {    
       if (http_uri ends_with "cgi") {    
          use ( cgi_pool )    
       }    
       else {     
          use ( default_pool )    
       }    
   }  

 rule clients_from_206_rule {    
       if ( client_addr equals 206.0.0.0 netmask 255.0.0.0 ) {    
          use ( clients_from_206 )    
       }    
       else {    
          use ( other_clients_pool )    
       }    
   }   

The relational operators

Expression	Relational Operator
Are two IP addresses equal?	<address> equals <address>
Do a string and a regular expression match?	<variable_operand> matches_regex <regular_expression>
Are two strings identical?	<string> equals <string>
Is the second string a suffix of the first string?	<variable_operand> ends_with <string>
Is the second string a prefix of the first string?	<variable_operand> starts_with <string>
Does the first string contain the second string?	<variable_operand> contains <literal_string>

In a rule, logical operators modify an expression or connect two expressions together to form a logical expression. Possible logical operators and expressions are described in Table 3.10.

The logical operators

Expression	Logical Operator
Is the expression not true?	not <expression>
Are both expressions true?	<expression> and <expression>
Is either expression true?	<expression> or <expression>

HTTP request string variables

HTTP request variables are referred to in command line syntax by a predefined set of names. Internally, an HTTP request variable points to a method for extracting the desired string from the current HTTP request header data. Before an HTTP request variable is used in a relational expression, it is replaced with the extracted string. The allowed variable names are:

• http_method
  The http_method is the action of the HTTP request. Common values are GET or POST.
• http_uri
  The http_uri is the URL, but does not include the protocol and the fully qualified domain name (FQDN). For example, if the URL is "http://www.url.com/buy.asp", then the URI is "/buy.asp".
• http_version
  The http_version is the HTTP protocol version string. Possible values are HTTP/1.0 or HTTP/1.1.
• http_host
  The http_host is the value in the Host: header of the HTTP request. It indicates the actual FQDN that the client requested. Possible values are a FQDN or a host IP address in dot notation.
• http_cookie <cookie name>
  The HTTP cookie header is value in the Cookie: for the specified cookie name. An HTTP cookie header line can contain one or more cookie name value pairs. The http_cookie <cookie name> variable evaluates to the value of the cookie with the name <cookie name>. For example, given a request with the following cookie header line:
  
  Cookie: green-cookie=4; blue-cookie=horses
  
  The variable http_cookie blue-cookie evaluates to the string horses. The variable http_cookie green-cookie evaluates to the string 4.
• http_header <header_tag_string>
  The variable http_header evaluates the string following an HTTP header tag that you specify. For example, you can specify the http_host variable with the http_header variable. In a rule specification, if you wanted to load balance based on the host name "andrew" it might look like this:
  
  

  if ( http_header "Host" starts_with "andrew" ) { use ( andrew_pool ) } else { use ( main_pool ) }

Configuring rules

You can create rules from the command line or with the Configuration utility. Each of these methods is described in this section.

To add a rule using the Configuration utility

1. In the navigation pane, click Rules.
   This opens the Rules screen.
2. Click the Add button.
   The Add Rule screen opens.
3. In the Add Rule screen, fill in the fields to add a rule.
   You can type in the rule as an unbroken line, or you can use the Enter key to add line breaks. For additional information about configuring rules, click the Help button.

To define a rule from the command line

To define a rule from the command line, use the following syntax:

b rule <rule_name> '{ <if statement> | <cache_statement }'

For more information about the elements of a rule, see Table 3.12, on page 3-40.

Configuring virtual servers that reference rules

You can define a virtual server that references a rule using the Configuration utility or from the command line.

Note: You must define a pool before you can define a rule that references the pool.

To configure a virtual server that references a rule using the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. Add the attributes you want for the virtual server such as Address, Port, Unit ID, and Interface.
3. In the Resources section, click Rule.
4. In the list of rules, select the rule you want to apply to the virtual server.
5. Click the Apply button.

To configure a virtual server that references a rule from the command line

There are several elements required for defining a virtual server that references a rule from the command line:

b virtual <virt_serv_key> { <virt_options> <rule_name_reference> }

Each of these elements is described in Table 3.11.

The command line rule elements

Rule element	Description
<virt_serv_key>	A virtual server key definition: <virtual_address>:<virt_port> [unit <ID>]
<virt_options>	Virtual server options. For more information, see virtual, on page 7-79.
<rule_name_reference>	A rule name reference. Rule names are strings of 1 to 31 characters. use rule <rule_name>

Table 3.12 contains descriptions of all the elements you can use to create rules.

The elements you can use to construct rules

Element	Description
rule definition	rule <rule_name { <if_statement> | <cache_statement>}
if statement	if ( <expression> ) { <statement> } [ { else <statement> } ] [ { else if <statement> } ]
expression	<literal> <variable> ( <expression> ) exists <variable> not <expression> <expression> <binary_operator> <expression>
statement	<use_statement> <if_statement> discard <cache_statement>
cache statement	cache ( <expression> ) { origin_pool <pool_name> cache_pool <pool_name> [ hot_pool <pool_name> ] [ hot_threshold <hit_rate> ] [ cool_threshold <hit_rate> ] [ hit_period <seconds> ][ content_hash_size <sets_in_content_hash> ] }
use statement	use ( <pool_name> )
IP protocol constants	UDP TCP
literal	<regex_literal> <string_literal> <address_literal>
regular expression literal	Is a string of 1 to 63 characters enclosed in quotes that may contain regular expressions
string literal	Is a string of 1 to 63 characters enclosed in quotes
address literal	<dot_notation_longword> [netmask <dot_notation_longword>]
Dot notation longword	<0-255>.<0-255>.<0-255>.<0-255>
variable	http_method http_header <header tag> http_version http_uri http_host http_cookie <cookie_name> client_addr ip_protocol
binary operator	or and contains matches equals starts_with ends_with matches_regex

Cache statement syntax

A cache statement may be either the only statement in a rule or it may be nested within an if statement. The syntax of a cache statement is shown in Figure 3.8.

Figure 3.8 An example of cache statement syntax

 cache ( <expression> ) {    
       origin_pool <pool_name>    
       cache_pool <pool_name>    
       [ hot_pool <pool_name> ]    
       [ hot_threshold <hit_rate> ]    
       [ cool_threshold <hit_rate> ]    
       [ hit_period <seconds> ]    
       [ content_hash_size <sets_in_content_hash> ]    
    }  

The following table describes the cache statement syntax.

Description of cache statement syntax

Rule Syntax	Description
expression	A Boolean expression setting the condition or conditions under which the rule applies.
origin_pool <pool_name>	This required attribute specifies a pool of servers with all the content to which requests are load balanced when the requested content is not cacheable or when all the cache servers are unavailable or when you use a BIG-IP to redirect a miss request from a cache.
cache_pool <pool_name>	This required attribute specifies a pool of cache servers to which requests are directed to optimize cache performance.
hot_pool <pool_name>	This optional attribute specifies a pool of servers that contain content to which requests are load balanced when the requested content is frequently requested (hot). If you specify any of the following attributes in this table, the hot_pool attribute is required.
hot_threshold <hit_rate>	This optional attribute specifies the minimum number of requests for content that cause the content to change from cool to hot at the end of the period (hit_period).
cool_threshold <hit_rate>	This optional attribute specifies the maximum number of requests for specified content that cause the content to change from hot to cool at the end of the period.
hit_period <seconds>	This optional attribute specifies the period in seconds over which to count requests for particular content before deciding whether to change the hot or cool state of the content.
content_hash_size <sets_in_content_hash>	This optional attribute specifies the number subsets into which the content is divided when calculating whether content is hot or cool. The requests for all content in the same subset are summed and a single hot or cool state is assigned to each subset. This attribute should be within the same order of magnitude as the actual number of requests possible. For example, if the entire site is composed of 500,000 pieces of content, a content_hash_size of 100,000 would be typical.

A cache statement returns either the origin pool, the hot pool, or the cache pool. When the cache pool is selected, it is accompanied by the indicated node address and port. When a rule returns both a pool and a node, the BIG-IP does not do any additional load balancing or persistence processing.

Figure 3.9 shows an example of a rule containing a cache statement.

Figure 3.9 An example of a cache load balancing rule

 rule my_rule {    
       if ( http_host starts_with "dogfood" ) {    
           cache ( http_uri ends_with "html" or http_uri ends_with "gif" ) {    
           origin_pool origin_server    
           cache_pool cache_servers    
           hot_pool cache_servers    
           hot_threshold 100    
           cool_threshold 10    
           hit_period 60    
           content_hash_size 1024    
           }    
       }    
       else {    
           use ( catfood_servers )    
       }    
   }  

Configuring a remote origin server

To ensure that a remote origin server or cache server responds to the BIG-IP rather than to the original cache server that generated the miss request, the BIG-IP also translates the source of the miss request to the translated address and port of the associated SNAT connection.

In order to enable these scenarios, you must:

• Create a SNAT for each cache server.
• Create a SNAT auto-mapping for bounceback.

Configuring a SNAT for each origin server

The SNAT translates the address of a packet from the cache server to the address you specify. For more information about SNATs, see SNATs, on page 3-74.

To configure a SNAT mapping using the Configuration utility

1. In the navigation pane, click SNATs.
   The SNATs screen opens.
2. Click the Add button.
   The Add SNAT screen opens.
3. In the Add SNAT screen, configure the attributes required for the SNAT you want to add. For additional information about configuring a pool, click the Help button.

To configure a SNAT mapping on the command line

The bigpipe snat command defines one SNAT for one or more node addresses.

b snat map <orig_ip>...to <snat_ip>

Creating a SNAT automap for bounceback

You must now configure a second SNAT mapping, in this case with the SNAT automap feature, so that when requests are directed to the origin server, the server will reply through the BIG-IP and not directly to the client. (If the BIG-IP replied directly to the client, the next request would then go directly to the origin server, removing the BIG-IP from the loop.)

To configure a SNAT automap from the command line

Configure the existing SNAT address on the external interface as a self address using this syntax:

b self <snat_addr? vlan external snat automap enable

To enable SNAT automap on the external VLAN, use this syntax:

b vlan external snat automap enable

Additional rule examples

This section contains additional examples of rules including:

• Cookie rule
• Language rule
• Cache rule
• AOL rule
• Protocol specific rule

Cookie rule

Figure 3.10 shows a cookie rule that load balances based on the user ID that contains the word VIRTUAL.

Figure 3.10 Cookie rule example

 if ( exists http_cookie "user-id" and    
        http_cookie "user-id" contains "VIRTUAL" ) {    
      use ( virtual_pool )    
   }    
   else {    
      use ( other_pool )    
   }  

Language rule

Figure 3.11 shows a rule that load balances based on the language requested by the browser.

Figure 3.11 Sample rule that load balances based on the language requested by the browser

 if ( exists http_header "Accept-Language" ) {    
      if ( http_header "Accept-Language" equals "fr" ) {    
         use ( french_pool )    
      }    
      else if ( http_header "Accept-Language" equals "sp" ) {    
            use (spanish_pool )    
      }    
      else {    
      use ( english_pool )    
   }  

Cache rule

Figure 3.12 shows an example of a rule that you can use to send cache content, such as .gifs, to a specific pool.

Figure 3.12 An example of a cache rule

 if ( http_uri ends_with "gif" or    
        http_uri ends_with "html" ) {    
      use ( cache_pool )    
   }    
   else {    
      use ( server_pool )    
   }  

AOL rule

Figure 3.13 is an example of a rule that you can use to load balance incoming AOL connections.

Figure 3.13 An example of an AOL rule

 port 80 443 enable    
   pool aol_pool {    
      min_active_members 1
   member 12.0.0.31:80 priority 4    
      member 12.0.0.32:80 priority 3    
      member 12.0.0.33:80 priority 2    
      member 12.0.0.3:80 priority 1    
   }    
   pool other_pool {    
      member 12.0.0.31:80    
      member 12.0.0.32:80    
      member 12.0.0.33:80    
      member 12.0.0.3:80     
   }    
   pool aol_pool_https {    
      min_active_members 1
   member 12.0.0.31:443 priority 4    
      member 12.0.0.32:443 priority 3    
      member 12.0.0.33:443 priority 2    
      member 12.0.0.3:443 priority 1    
   }    
   pool other_pool_https{    
      member 12.0.0.31:443    
      member 12.0.0.32:443    
      member 12.0.0.33:443    
      member 12.0.0.3:443    
   }    
   rule aol_rule {    
      if (    client_addr equals 152.163.128.0 netmask 255.255.128.0    
           or client_addr equals 195.93.0.0    netmask 255.255.254.0    
           or client_addr equals 205.188.128.0 netmask 255.255.128.0 ) {    
         use ( aol_pool )    
      }    
      else {    
         use ( other_pool)    
      }    
   }   

Figure 3.13 An example of an AOL rule

 rule aol_rule_https {    
      if (    client_addr equals 152.163.128.0 netmask 255.255.128.0    
           or client_addr equals 195.93.0.0    netmask 255.255.254.0    
           or client_addr equals 205.188.128.0 netmask 255.255.128.0 ) {    
         use ( aol_pool_https )    
      }    
      else {    
         use ( other_pool_https)    
      }    
   }    
   virtual 15.0.140.1:80  { use rule aol_rule }    
   virtual 15.0.140.1:443 { use rule aol_rule_https special ssl 30 }  

IP protocol specific rule

Figure 3.14 shows a rule that you can use to send TCP DNS to the pool tcp_pool and UDP DNS to the pool udp_pool.

Figure 3.14 An example of an IP protocol rule

 rule myrule {     
      if ( ip_protocol equals UDP ) {    
        use ( udp_pool )    
      }    
      else {     
         use ( tcp_pool )    
      }  

Virtual servers

A virtual server with its virtual address is the visible, routable entity through which nodes in a load balancing pool are made available to a client, either directly or indirectly through a rule. (The exception is the forwarding virtual server, which simply forwards traffic and has no pools associated.)

You must configure a pool of servers before you can create a virtual server that references the pool. Before you configure virtual servers, you need to know:

• Which virtual server type meets you needs
• Whether you need to activate optional virtual server properties
  
  

  Once you know which virtual server options are useful in your network, you can define any one of the following types of virtual server:

• Standard virtual server
• Network virtual server
• Port-specific wildcard virtual server
• Default wildcard virtual server
• Forwarding virtual server

Table 3.14 shows the virtual server types.

The attributes you can configure for a virtual server

Options	Description
Standard virtual server	A standard virtual server is a virtual server with a full IP address. For example: 192.168.200.30:http
Network virtual server	A network virtual server is a virtual server with a network IP address, allowing it to handle a whole range of addresses in a network. For example: 192.168.200.0:http
Port-specific wildcard virtual server	A port-specific wildcard virtual server is a virtual server with a port specified. For example: 0.0.0.0:80 A port-specific wildcard virtual server is used to accept all traffic for a specific service.
Default wildcard virtual server	A default wildcard virtual server is a wildcard virtual server with the service 0, "*", or "any". For example: 0.0.0.0:0 A default wildcard server acts like a default router, accepting all traffic that does not match a standard, network, or port-specific wildcard server.
Forwarding virtual server	A forwarding virtual server is a virtual server without a pool that simply forwards traffic to the destination node.

Virtual server options are shown in Table 3.15.

The attributes you can configure for a virtual server

Options	Description
Connection limits	You can set a concurrent connection limit on one or more virtual servers.
Translation properties	You can turn port translation off for a virtual server if you want to use the virtual server to load balance connections to any service.
Last hop pools	You can direct reply traffic to the last hop router using a last hop pool. This overrides the auto_lasthop setting.
Mirroring information	You can use mirroring to maintain the same state information in the standby unit that is in the active unit, allowing transactions such as FTP file transfers to continue as though uninterrupted.

Defining standard virtual servers

A standard virtual server represents a specific site, such as an Internet web site or an FTP site, and it load balances content servers that are members of a pool. The IP address that you use for a standard virtual server should match the IP address that DNS associates with the site's domain name.

Note: If you are using a 3-DNS Controller in conjunction with the BIG-IP, the 3-DNS Controller uses the IP address associated with the registered domain name in its own configuration. For details, refer to the 3-DNS Administrator Guide.

To define a standard virtual server using the Configuration utility

1. In the navigation pane, click Virtual Servers.
2. Click the Add button.
   The Add Virtual Server screen opens.
3. In the Address box, type the virtual server's IP address or host name.
4. In the Port box, either type a port number, or select a service name from the drop-down list.
5. In the Select Physical Resources screen, click the Pool button.
   If you want to assign a load balancing rule to the virtual server, click Rule and select a rule you have configured.
6. In the Pool list, select the pool you want to apply to the virtual server.
7. Click the Apply button.

To define a standard virtual server mapping from the command line

Type the bigpipe virtual command as shown below. Also, remember that you can use host names in place of IP addresses, and that you can use standard service names in place of port numbers.

b virtual <virt_ip>:<service> use pool <pool_name>

b virtual <virt_ip>:<service> use rule <rule_name>

For example, the following command defines a virtual server that maps to the pool my_pool:

b virtual 192.200.100.25:80 use pool my_pool

Defining wildcard virtual servers

Wildcard virtual servers are a special type of virtual server designed to manage network traffic for transparent network devices, such as transparent firewalls, routers, proxy servers, or cache servers. A wildcard virtual server manages network traffic that has a destination IP address unknown to the BIG-IP. A standard virtual server typically represents a specific site, such as an Internet web site, and its IP address matches the IP address that DNS associates with the site's domain name. When the BIG-IP receives a connection request for that site, the BIG-IP recognizes that the client's destination IP address matches the IP address of the virtual server, and it subsequently forwards the client to one of the content servers that the virtual server load balances.

However, when you are load balancing transparent nodes, a client's destination IP address is going to seem random. The client is connecting to an IP address on the other side of the firewall, router, or proxy server. In this situation, the BIG-IP cannot match the client's destination IP address to a virtual server IP address. Wildcard virtual servers resolve this problem by not translating the incoming IP address at the virtual server level on the BIG-IP. For example, when the BIG-IP does not find a specific virtual server match for a client's destination IP address, it matches the client's IP address to a wildcard virtual server. The BIG-IP then forwards the client's packet to one of the firewalls or routers that the wildcard virtual server load balances, which in turn forwards the client's packet to the actual destination IP address.

A note about wildcard ports

When you configure wildcard virtual servers and the nodes that they load balance, you can use a wildcard port (port 0) in place of a real port number or service name. A wildcard port handles any and all types of network services.

A wildcard virtual server that uses port 0 is referred to as a default wildcard virtual server, and it handles traffic for all services. A port-specific wildcard virtual server handles traffic only for a particular service, and you define it using a service name or a port number. If you 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.

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

We recommend that when you define transparent nodes that need to handle more than one type of service, such as a firewall or a router, you specify an actual port for the node and turn off port translation for the virtual server.

Defining the wildcard virtual server mappings

There are two procedures required to set up a wildcard virtual server. First, you must define the wildcard virtual server. Then you must turn port translation off for the virtual server.

To define a wildcard virtual server using the Configuration utility

1. In the navigation pane, click Virtual Servers.
2. Click the Add button.
   The Add Virtual Server screen opens.
3. In the Address box, type the wildcard IP address 0.0.0.0.
4. In the Port box, type a port number, or select a service name from the drop-down list. Note that port 0 defines a wildcard virtual server that handles all types of services. If you specify a port number, you create a port-specific wildcard virtual server. The wildcard virtual server only handles traffic for the port specified.
5. In Resources, click the Pool button.
6. In the Pool list, select the pool you want to apply to the virtual server.
7. Click the Apply button.

To turn off port translation for a wildcard virtual server using the Configuration utility

After you define the wildcard virtual server with a wildcard port, you must disable port translation for the virtual server.

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the virtual server list, click the virtual server for which you want to turn off port translation.
   The Virtual Server Properties screen opens.
3. In the Enable Translation section, clear the Port box.
4. Click the Apply button.

To define a wildcard virtual server mapping from the command line

There are three commands required to set up a wildcard virtual server. First, you must define a pool that contains the addresses of the transparent devices. Next, you must define the wildcard virtual server. Then you must turn port translation off for the virtual server. To define the pool of transparent devices, use the bigpipe pool command. For example, you can create a pool of transparent devices called transparent_pool that uses the Round Robin load balancing mode:

b pool transparent_pool { \

member <member_definition>... \

member <member_definition> }

To define the virtual server, use the bigpipe virtual command:

b virtual <virt_ip>:<service> use pool <pool_name>

After you define the virtual server, you can enable or disable port translation using the following command:

b virtual <virt_ip>:<service> translate port enable | disable

For example, you can create a pool of transparent devices called transparent_pool:

b pool transparent_pool { \

member 10.10.10.101:80 member 10.10.10.102:80 \

member 10.10.10.103:80 }

After you create the pool of transparent nodes, use the following command to create a wildcard virtual server that maps to the pool transparent_pool. Because the members are firewalls and need to handle a variety of services, the virtual server is defined using port 0 (or * or any). You can specify any valid non-zero port for the node port and then turn off port translation for that port. In this example, service checks ping port 80.

b virtual 0.0.0.0:0 use pool transparent_pool

After you define the virtual server, turn off port translation for the port in the virtual server definition. In this example, port 80 is used for service checking. If you do not turn off port translation, all incoming traffic would be translated to port 80.

b virtual 0.0.0.0:0 translate port disable

Configuring a network virtual server

You can configure a network virtual server to handle a whole network range, instead of just one IP address, or all IP addresses (wildcard virtual servers). For example, the virtual server in Figure 3.15 handles all traffic addresses in the 192.168.1.0 network.

Figure 3.15 A sample network virtual server

 bigpipe virtual 192.168.1.0:0 {    
         netmask 255.255.255.0 use pool ingress_firewalls    
   }   

A network virtual server is a virtual server that has no bits set in the host portion of the IP address. The example above directs all traffic destined to the subnet 192.168.1.0/24 through the BIG-IP to the ingress_firewalls pool.

The netmask of a network virtual server establishes which portion of the address is actually the network of a network virtual server. (By default, this is the netmask of the self IP address. In the example, the network mask of 255.255.255.0 states that the network portion of the address is 192.168.1, which in this case is obvious because only the last octet has a zero value. A less obvious case would be the network virtual server 10.0.0.0:0. Here, the zero in the second octet is ambiguous: it could be a wildcard or it could be a literal zero. If it is a wildcard, this would be established by a netmask of 255.0.0.0. If it is a literal zero, this would be established by a netmask of 255.255.0.0.

Another way you can use this feature is to create a catch-all web server for an entire subnet. For example, you could create the following network virtual server (Figure 3.16).

Figure 3.16 A catch-all web server configuration.

 bigpipe virtual 192.168.1.0:http {    
       netmask 255.255.255.0 broadcast 192.168.1.255    
       use pool default_webservers    
   }   

This configuration directs a web connection destined to any address within the subnet 192.168.1.0/24 to the default_webservers pool.

Mirroring virtual server state

Mirroring provides seamless recovery for current connections, persistence information, SSL persistence, or sticky persistence when a BIG-IP fails. When you use the mirroring feature, the standby unit maintains the same state information as the active unit. Transactions such as FTP file transfers continue as though uninterrupted.

Note: Mirroring slows BIG-IP performance and is primarily for long-lived services like FTP and Telnet. Mirroring is not useful for short-lived connections like HTTP.

Since mirroring is not intended to be used for all connections and persistence, it must be specifically enabled for each virtual server.

To control mirroring for a virtual server, use the bigpipe virtual mirror command to enable or disable mirroring of persistence information, or connections, or both. The syntax of the command is:

b virtual <virt addr>:<service> mirror [persist|conn] enable|disable

Use persist to mirror persistence information for the virtual server. Use conn to mirror connection information for the virtual server. To display the current mirroring setting for a virtual server, use the following syntax:

b virtual <virt addr>:<service> mirror [persist|conn] show

If you do not specify either persist, for persistent information, or conn, for connection information, the BIG-IP assumes that you want to display both types of information.

Note: If you set up mirroring on a virtual server that supports FTP connections, you need to mirror the control port virtual server, and the data port virtual server.

The following example shows the two commands used to enable mirroring for virtual server v1 on the FTP control and data ports:

b virtual v1:21 mirror conn enable

b virtual v1:20 mirror conn enable

Additional virtual server options

This section contains information on the following features you can use to manage virtual servers:

• Display information about a virtual server
• Set a netmask and broadcast
• Set a connection limit
• Set translation properties for virtual addresses and ports
• Set up a last hop pool for a virtual server
• Enable or disable a virtual address
• Display information about a virtual address
• Delete a virtual server
• Reset statistics for a virtual server
• Set software acceleration properties for virtual server with IPFW turned on

To display information about virtual servers

Use the following syntax to display information about all virtual servers included in the configuration:

b virtual show

Use the following syntax to display information about one or more virtual servers included in the configuration:

b virtual <virt_ip>:<service> [...<virt_ip>:<service>] show

The command displays information such as the nodes associated with each virtual server, the nodes' status, and the current, total, and maximum number of connections managed by the virtual server since the BIG-IP was last rebooted.

To set a user-defined netmask and broadcast

The default netmask for a virtual address, and for each virtual server hosted by that virtual address, is determined by the network class of the IP address entered for the virtual server. The default broadcast is automatically determined by the BIG-IP, and it is based on the virtual address and the current netmask. You can override the default netmask and broadcast for a network virtual address only.

All virtual servers hosted by the virtual address use the netmask and broadcast of the virtual address, whether they are default values or they are user-defined values.

If you want to use a custom netmask and broadcast, you define both when you define the network virtual server:

b virtual <virt_ip>[:<service>] [vlan <vlan_name> disable | enable] [netmask <ip>] [broadcast <ip>] use pool <pool_name>

Note: The BIG-IP calculates the broadcast based on the IP address and the netmask. In most cases, a user-defined broadcast address is not necessary.

Again, even when you define a custom netmask and broadcast in a specific network virtual server definition, the settings apply to all virtual servers that use the same virtual address. The following sample command shows a user-defined netmask and broadcast:

b virtual www.SiteOne.com:http \

netmask 255.255.0.0 \

broadcast 10.0.140.255 \

use pool my_pool

The /bitmask option shown in the following example applies network and broadcast address masks. In this example, a 24-bit bitmask sets the network mask and broadcast address for the virtual server:

b virtual 206.168.225.0:80/24 use pool my_pool

You can generate the same broadcast address by applying the 255.255.255.0 netmask. The effect of the bitmask is the same as applying the 255.255.255.0 netmask. The broadcast address is derived as 206.168.225.255 from the network mask for this virtual server.

To set a connection limit

The default setting is to have no limit to the number of concurrent connections allowed on a virtual server. You can set a concurrent connection limit on one or more virtual servers using the following command:

b virtual <virt_ip> [:<service>] \ [...<virt_ip>[:<service>]] limit <max_conn>

The following example shows two virtual servers set to have a concurrent connection limit of 5000 each:

b virtual www.SiteOne.com:http www.SiteTwo.com:ssl limit 5000

To turn the limit off, set the <max conn> variable to zero:

b virtual <virt_ip>[:<service>] [...<virt_ip>[:<service>] ] limit 0

To set translation properties for virtual addresses and ports

Turning off port translation for a virtual server is useful if you want to use the virtual server to load balance connections to any service. Use the following syntax to enable or disable port translation for a virtual server:

b virtual <virt_ip>:<service> translate port enable | disable | show

You can also configure the translation properties for a virtual server address. This option is useful when the BIG-IP is load balancing devices which have the same IP address. This is typical with the nPath routing configuration where duplicate IP addresses are configured on the loopback device of several servers. Use the following syntax to enable or disable address translation for a virtual server:

b virtual <virt_ip>:<service> translate addr enable | disable | show

To set up last hop pools for virtual servers

In cases where you have more than one router sending connections to a BIG-IP, connections are automatically sent back through the same router from which they were received when the auto_lasthop global variable is enabled, as it is by default. If you want to exclude one or more routers from auto-lasthop, or if the global auto_lasthop is disabled for any reason (for example, you may not want it for an SSL gateway), you can use a last hop pool instead. (If auto_lasthop is enabled, the last hop pool will take precedence over it.)

To configure a last hop pool, you must first create a pool containing the router inside addresses. After you create the pool, use the following syntax to configure a last hop pool for a virtual server:

b virtual <virt_ip>:<service> lasthop pool <pool_name> | none | show

To enable or disable a virtual server

You can remove an existing virtual server from network service, or return the virtual server to service, using the disable and enable keywords. When you disable a virtual server, the virtual server no longer accepts new connection requests, but it allows current connections to finish processing before the virtual server goes down.

Use the following syntax to remove a virtual server from network service:

b virtual <virt_ip>:<service> [...<virt_ip>:<service>] disable

Use the following syntax to return a virtual server to network service:

b virtual <virt_ip>:<service> enable

To enable or disable a virtual address

You can remove an existing virtual address from network service, or return the virtual address to service, using the disable and enable keywords. Note that when you enable or disable a virtual address, you inherently enable or disable all of the virtual servers that use the virtual address.

b virtual <virt_ip> disable

Use the following syntax to return a virtual address to network service:

b virtual <virt_ip> enable

To display information about virtual addresses

You can also display information about the virtual addresses that host individual virtual servers. Use the following syntax to display information about one or more virtual addresses included in the configuration:

b virtual <virt_ip> [... <virt_ip> ] show

The command displays information such as the virtual servers associated with each virtual address, the status, and the current, total, and maximum number of connections managed by the virtual address since the BIG-IP was last rebooted, or since the BIG-IP became the active unit (redundant configurations only).

To delete a virtual server

Use the following syntax to permanently delete one or more virtual servers from the BIG-IP configuration:

b virtual <virt_ip>:<service> [... <virt_ip>:<service>] delete

To reset statistics for a virtual server

Use the following command to reset the statistics for an individual virtual server:

b virtual [<virt_ip:port>] stats reset

Turning software acceleration off for virtual servers using IPFW rate filters

The software acceleration feature speeds packet flow for TCP connections when the packets are not fragmented. For configurations with no IPFW rate filter present, software acceleration is turned on by default by giving the global variable fastflow_active a default value of auto. fastflow_active auto enables acceleration globally if IPFW filters are not present and disables it globally if IPFW filters are present. (This is because, with acceleration on, IPFW only examines the first SYN packet in any given connection, rather than filtering all packets). If you want to turn on acceleration globally but turn it off for the specific virtual servers that use IPFW rate filters, you must change the fastflow_active setting from auto to on, then disable the virtual servers individually using the bigpipe virtual <ip>:<service> accelerate disable command.

To set software acceleration controls from the command line

To enable software acceleration globally in a way that can be overridden for individual virtual servers, set the bigpipe global variable fastflow_active to on with the following command:

b global fastflow_active on

Then, to disable software acceleration for individual virtual servers that use IPFW rate filtering, use the following bigpipe command:

b virtual <ip>:<service> accelerate disable

For example, if you want to turn acceleration off for the virtual server 10.10.10.50:80, type the following command:

b virtual 10.10.10.50:80 accelerate disable

You can define a virtual server with acceleration disabled using the following syntax:

b virtual <ip>:<service> use pool the_pool accelerate disable

For example, if you want to define the virtual server 10.10.10.50:80 with the pool IPFW_pool and acceleration turned off, type the following command:

b virtual 10.10.10.50:80 use pool IPFW_pool accelerate disable

Using additional BIG-IP features with virtual servers

After you create a pool and define a virtual server that references the pool, you can set up additional features, such as network address translation (NAT) or extended content verification (ECV). For details on Network address translations, see NATs, on page 3-80. For details on persistence for connections that should return to the node to which they last connected, see Persistence, on page 3-18.

Proxies

Use the proxy command to create, delete, modify, or display the SSL or content converter gateway definitions on the BIG-IP. For detailed information about setting up the SSL Accelerator feature, see the BIG-IP Solutions Guide, Chapter 9, Configuring an SSL Accelerator. For detailed information about setting up the content converter feature, see the BIG-IP Solutions Guide, Chapter 14, Configuring a Content Converter.

The SSL Accelerator proxy

The SSL Accelerator feature allows the BIG-IP to accept HTTPS connections (HTTP over SSL), connect to a web server, retrieve the page, and then send the page to the client.

A key component of the SSL Accelerator feature is that the BIG-IP can retrieve the web page using an unencrypted HTTP request to the content server. With the SSL Accelerator feature, you can configure an SSL gateway on the BIG-IP that decrypts HTTP requests that are encrypted with SSL. Decrypting the request offloads SSL processing from the servers to the BIG-IP. This also allows the BIG-IP to use the header of the HTTP request to intelligently control how the request is handled. (You can optionally configure requests to the servers to be re-encrypted to maintain security on the server side of the BIG-IP as well, using a feature called SSL-to-server. While the servers must now handle the final decryption and re-encryption, SSL processing is still faster than if the entire task were left to the servers.)

When the SSL gateway on the BIG-IP connects to the content server, it uses the original client's IP address and port as its source address and port, so that it appears to be the client (for logging purposes).

To create an SSL gateway using the Configuration utility

1. In the navigation pane, click Proxies.
   The Proxies screen opens.
2. Click the ADD button.
   The Add Proxy screen opens.
3. In the Add Proxy screen, configure the attributes you want to use with the proxy. For additional information about configuring a proxy, click the Help button.

To create a client-side SSL gateway from the command line

Use the following command syntax to create an SSL gateway:

b proxy <ip>:<service> [unit <unit_id>] \

target <server|virtual> <ip>:<service> \

clientssl enable \

clientssl key <clientssl_key> \

clientssl cert <clientssl_cert> \

For example, from the command line you can create an SSL gateway that looks like this:

b proxy 10.1.1.1:443 unit 1 \

target virtual 20.1.1.1:80 \

clientssl enable \

clientssl key my.server.net.key \

clientssl cert my.server.net.crt

When the SSL gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 3.17.

Figure 3.17 An example SSL gateway configuration

 proxy 10.1.1.1:443 unit 1 {     
       target virtual 20.1.1.1:http     
       clientssl enable     
       key my.server.net.key    
       cert my.server.net.crt    
   }   

To create a client-side and server-side SSL gateway from the command line

Use the following command syntax to create an SSL gateway:

b proxy <ip>:<service> \

unit <unit_id> \

target virtual <ip>:<service> \

clientssl enable \

clientssl key <clientssl_key> \

clientssl cert <clinetssl_cert> \

serverssl enable

Optionally, you may specify a key file and a certificate file for the proxy as a client. This is done as follows:

b proxy <ip>:<service> \

unit <unit_id> \

target virtual <ip>:<service> \

clientssl enable \

clientssl key <clientssl_key> \

clientssl cert <clinetssl_cert> \

serverssl enable \

serverssl key <serverssl_key> \

serverssl cert <serverssl_cert>

When the SSL gateway is written in the /config/bigip.conf file with SSL-to-Server enabled, it looks like the sample in Figure 3.18.

Figure 3.18 An example SSL gateway configuration

 proxy 10.1.1.1:443 unit 1 {     
       target virtual 20.1.1.1:https     
       clientssl enable     
       clientssl key my.server.net.key    
       clientssl cert my.server.net.crt    
       serverssl enable     
       serverssl key my.client.net.key        
       serverssl cert my.client.net.key      
   }   

The content converter proxy

The content converter proxy performs conversion of URLs to ARLs (Akamai Resource Locators). ARLs point to copies of URL targets that are stored on geographically nearby servers on the Akamai Freeflow NetworkTM for greater speed of access. The conversion from URL to ARL is performed whenever a client accesses a web page on a customer site containing a URL with an ARL counterpart, giving it the name on-the-fly content conversion. On-the-fly content conversion has the advantage that the HTML source does not need to be updated each time a new ARL is added.

Note: The content converter feature is usable only by customers of the Akamai Freeflow Network. In addition, the features required to configure this option are available only on the BIG-IP HA and Enterprise software versions.

Creating a content converter gateway

Configuring a content converter consists of two steps. First, configure the Akamai on-the-fly conversion software for your network. Second, create the content converter gateway using the proxy command. (If the software is not configured first, the attempt to create a proxy will fail.)

To configure the on-the-fly conversion software

1. On the BIG-IP, bring up the Akamai configuration file /etc/config/akamai.conf in an editor like vi or pico.
2. Under the heading [CpCode] you will find the text default=XXXXX. Replace the Xs with the CP code provided by your Akamai Integration Consultant. (If contacting your consultant, specify that you are using the BIG-IP on-the-fly akamaizer based on Akamai's 1.0 source code.) Example:
   
   

   default=773

3. Under the heading [Serial Number] you will find the text staticSerialNumber=XXXXX. Replace the Xs with the static serial number provided by your Akamai Integration Consultant. Example:
   
   

   staticSerialNumber=1025

   Note: This value needs to be set only if the algorithm under [Serial Number] is set to static, as it is in the default file. If you choose to set the algorithm to deterministicHash or deterministicHashBounded, the static serial number is not applicable. If you are unsure what method to select, contact your Akamai Integration Consultant.

4. Under the heading [URLMetaData] you will find the text httpGetDomains=XXXXX. Replace the Xs with domain name of the content to be converted. Example:
   
   

   httpGetDomains=www.f5.com

5. Save and exit the file.

To create a content converter gateway using the Configuration utility

1. In the navigation pane, click Proxies
   The Proxies screen opens.
2. Click the Add button.
3. In the Add Proxy screen, configure the attributes you want to use with the proxy. For additional information about configuring a Proxy, click the Help button.

To configure the content converter gateway at the command line

Use the following command syntax to create a content converter gateway:

b proxy <ip>:<service> [unit <unit_id>] \

target server|virtual <ip>:<service> \

akamaize enable

For example, from the command line you can create a gateway that looks like this:

b proxy 10.1.1.1:80 unit 1 \

target virtual 20.1.1.1:80 \

akamaize enable

When the content converter gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 3.19.

Figure 3.19 An example content converter gateway configuration

 proxy 10.1.1.1:http unit 1 {     
          target virtual 20.1.1.1:http     
       akamaize enable     
       }   

To enable, disable, or delete a gateway from the command line

You can enable, disable, or delete a gateway with the following syntax:

b proxy <ip>:<service> enable

b proxy <ip>:<service> disable

b proxy <ip>:<service> delete

If you want to enable the gateway 209.100.19.22:80, you might type the following command:

b proxy 209.100.19.22:443 enable

If you want to disable the gateway 209.100.19.22:80, you could type the following command:

b proxy 209.100.19.22:443 disable

For example, if you want to delete the SSL gateway 209.100.19.22:80, type the following command:

b proxy 209.100.19.22:443 delete

Disabling VLANs for a gateway

A gateway is mapped by default to all VLANs on the internal and external networks of the BIG-IP. You must disable any VLANs to which you do not want the gateway mapped using the bigpipe proxy vlans <vlan_list> disable syntax:

b proxy vlans <vlan_name> disable

To display configuration information for a gateway from the command line

Use the following syntax to view the configuration for the specified gateway:

b proxy <ip>:<service> show

For example, if you want to view configuration information for the SSL gateway 209.100.19.22:443, type the following command:

b proxy 209.100.19.22:443 show

Nodes

Nodes are the network devices to which the BIG-IP passes traffic. A network device becomes a node when it is added as a member to a load balancing pool. You can display information about nodes and set properties for nodes.

The attributes you can configure for a node are in Table 3.16.

The attributes you can configure for a node.

Node Attributes	Description
Enable/Disable nodes	You can enable or disable nodes independently from a load balancing pool.
Set node up/down	You can set a node up or down.
Connection limit	You can place a connection limit on a node.
Associate a node with a monitor	You can associate a health monitor with a node, creating an instance of that monitor.
Add a node as a member of a pool	You can add a node to a pool as a member. This allows you to use the load balancing and persistence methods defined in the pool to control connections handled by the node.

To enable and disable nodes and node addresses

A node must be enabled in order to accept traffic. When a node is disabled, it allows existing connections to time out or end normally and accept new connections only if they belong to an existing persistence session. (In this way a disabled node differs from a node that is set down. The down node allows existing connections to time out, but accepts no new connections.)

To enable a node or node address, use the node command with the enable option:

b node 192.168.21.1 enable

To disable a node or node address, use the node command with the disable option:

b node 192.168.21.1 disable

To enable one or more nodes or node addresses, use the node command with and the enable option:

b node 192.168.21.1:80 enable

To disable one or more node or node addresses, use the node command with disable option:

b node 192.168.21.1:80 disable

To mark nodes and node ports up or down

A node must be marked up in order to accept traffic. When a node is marked down it allows existing connections to time out but accepts no new connections.

To mark a node down, use the node command with a node and the down option. (Note that marking a node down prevents the node from accepting new connections. Existing connections are allowed to complete.)

b node 192.168.21.1 down

To mark a node up, use the node command with the up option:

b node 192.168.21.1 up

To mark a particular service down, use the node command with a node and port, and the down option. (Note that marking a port down prevents the port from accepting new connections. Existing connections are allowed to complete.)

b node 192.168.21.1:80 down

To mark a particular port up, use the node command with up option:

b node 192.168.21.1:80 up

To set connection limits for nodes

Use the following command to set the maximum number of concurrent connections allowed on a node:

b node <node_ip>[:<service>][...<node_ip>[:<service>]] limit <max conn>

Note that to remove a connection limit, you also issue the preceding command, but set the <max conn> variable to 0 (zero). For example:

b node 192.168.21.1:80 limit 0

To set connection limits for nodes

The following example shows how to set the maximum number of concurrent connections to 100 for a list of nodes:

b node 192.168.21.1 192.168.21.1 192.168.21.1 limit 100

To remove a connection limit, you also issue this command, but set the <max conn> variable to 0 (zero).

To associate a health monitor with a node

Use the following command to associate a health monitor with a node:

node <node> monitor use <monitor>

A monitor can be placed on multiple nodes and a node can have multiple monitors placed on it. To place a monitor on multiple nodes:

node <node_list> monitor use <monitor>

To place multiple monitors on a node:

node <node> monitor use <monitor1> and <monitor2>...

For more information on using the node command with health monitors, refer to Health monitors, on page 3-87.

To display status of all nodes

When you issue the node show command, the BIG-IP displays the node status (up or down, or unchecked), and a node summary of connection statistics, which is further broken down to show statistics by port. To display the status of a node from the command line, type the following command:

b node show

The report shows the following information:

• Current number of connections
• Total number of connections made to the node since last boot
• Maximum number of concurrent connections since the last boot
• Concurrent connection limit on the node
• The total number of connections made to the node since last boot
• Total number of inbound and outbound packets and bits
  
  

  Figure 3.20 shows the output of this command.

  Figure 3.20 Node status and statistics

   bigpipe node 192.168.200.50:20    
     NODE 192.168.200.50    UP      
     |    (cur, max, limit, tot) = (0, 0, 0, 0)    
     |    (pckts,bits) in = (0, 0), out = (0, 0)    
     +-   PORT 20           UP      
          (cur, max, limit, tot) = (0, 0, 0, 0)    
          (pckts,bits) in = (0, 0), out = (0, 0)  

To display the status of individual nodes and node addresses

Use the following command to display status and statistical information for one or more node addresses:

b node 192.168.21.1 show

The command reads the status of each node address, the number of current connections, total connections, and connections allowed, and the number of cumulative packets and bits sent and received.

Use the following command to display status and statistical information for one or more specific nodes:

b node 192.168.21.1:80 show

To reset statistics for a node

Use the following command to reset the statistics for an individual node address:

b node [<node_ip>:<service>] stats reset

To add a node as a member to a pool

You can add a node as a member to a load balancing pool. For detailed information about how to do this, see Proxies, on page 3-61.

Services

Services are the standard Internet applications supported by BIG-IP, such as HTTP, HTTPs, FTP, and POP3, which are known by that name and also by well-known or reserved port numbers such as 80 or 443. (Specifically, a service is any valid service name in the /etc/services file or any valid port number between 0 and 65535.) The bigpipe service command allows you to enable and disable network traffic on services, and also set connection limits and timeouts. You can use the service name or the port number for the <service> parameter. Note that the settings you define with this command control the service for all virtual servers that use it. By default, all services are disabled.

Tip: Virtual servers using the same service actually share a port on the BIG-IP. This command is global, you only need to open access to a port once; you do not need to open access to a port for each instance of a virtual server that uses it.

The attributes you can configure for a port are shown in Table 3.17

The attributes you can configure for a service.

Attributes	Description
Allow access to services	As a security measure, all services are locked down on the BIG-IP. In order for the BIG-IP to load balance traffic, you must enable access to the service on which the BIG-IP will receive traffic.
Connection limits	You can define a connection limit for a service so that a flood of connections does not overload the BIG-IP.
Set idle connection timeouts	You can set the idle connection timeout to close idle connections.

To allow access to services using the Configuration utility

Any time you create a virtual server and define a port or service with the Configuration utility, the port or service is automatically enabled.

To allow access to services from the command line

Using the bigpipe service command, you can allow access to one or more services at a time.

b service <service>...<service> enable

For example, in order to enable HTTP (service 80) and Telnet (service 23) services, you can enter the following bigpipe service command:

b service 80 23 443 enable

To set connection limits on services

Use the following syntax to set the maximum number of concurrent connections allowed on a service. Note that you can configure this setting for one or more services.

b service <service> [...<service>] limit <max conn>

To turn off a connection limit for one or more services, use the same command, setting the <max conn> parameter to 0 (zero) like this:

b service <service> [...<service>] limit 0

To enable or disable TCP for services

You can enable or disable TCP for specific services. The default setting for all services is enabled. Use the following syntax to disable TCP for one or more services:

b service <service> [...<service>] tcp disable

To re-enable TCP, use this syntax:

b service <service> [...<service>] tcp enable

To enable or disable UDP for services

You can enable or disable UDP for specific services. The default setting for all services is disabled. Use the following syntax to enable UDP for one or more services:

b service <service> [...<service>] udp enable

To disable UDP, use this syntax:

b service <service> [...<service>] udp disable

To set the idle connection timeout for TCP traffic

To set the TCP timeout on one or more services, where the <seconds> parameter is the number of seconds before an idle connection is dropped, use the following syntax:

b service <service> [<service>...] timeout tcp <seconds>

For example, the following command sets the TCP timeout to 300 seconds for port 53:

b service 53 timeout tcp 300

To turn off TCP timeout for a service, use the above command, setting the <seconds> parameter to zero:

b service 53 timeout tcp 0

To set the idle connection timeout for UDP traffic

To set the UDP timeout on one or more services, where the <seconds> parameter is the number of seconds before an idle connection is dropped, use the following syntax:

b service <service> [<service>...] timeout udp <seconds>

For example, the following command sets the UDP timeout to 300 seconds for port 53:

b service 53 timeout udp 300

To turn off UDP timeout for a service, use the above command, setting the <seconds> parameter to zero:

b service 53 timeout udp 0

To display service settings

Use the following command to display the settings for all services:

b service show

Use the following syntax to display the settings for a specific service of services:

b service <service> [...<service>] show

The system displays the output shown in Figure 3.21.

Figure 3.21 Sample output of the service show command

 SERVICE 80 http tcp enabled timeout 1005 udp disabled timeout 60
         	 	 	 (cur, max, limit, tot, reaped) = (0, 0, 0, 0, 0)
	 	 	 (pckts,bits) in = (0, 0), out = (0, 0)  

Figure 3.22 shows a sample of formatted output of the port command.

Figure 3.22 Formatted output of port command showing the Telnet port statistics

 bigpipe port telnet show    
       
   PORT 	 23	 telnet	 enable
(cur, max, limit, tot, reaped) = (37,73,100,691,29)
	 (pckts,bits) in = (2541, 2515600), out = (2331, 2731687)  

Address translation: SNATs, NATs, and IP forwarding

The BIG-IP uses address translation and forwarding in various ways to make nodes accessible that would otherwise be hidden on its internal VLAN.

• A virtual server translates the destination address of an inbound packet from its own address (the virtual server's) to the address of the node to which it load balances the packet. It then translates the origin address of the reply back to its own address so the originating host will not try to address the member node directly. This translation is basic to the way the virtual server works in most configurations and it is enabled by default.
• You can configure a SNAT (Secure Network Address Translation) or NAT (Network Address Translation) to give a node that is a member of a load balancing pool a routable address as an origin address for purposes of generating its own outbound traffic. A SNAT can be configured manually, or automatically using the SNAT auto-map feature.
• You can configure forwarding virtual server to expose selected nodes to the external network.
• You can configure IP forwarding globally to expose all internal nodes to the external network
  
  

  For more information on enabling address translation for virtual servers, refer to Virtual servers, on page 3-49. The following sections describe how to configure NATS, SNATS, forwarding virtual servers, and IP forwarding.

SNATs

A secure network translation address (SNAT) provides a routable alias IP address that a node can use as its source IP address when making connections to clients on the external network. Unlike a simple network translation address (NAT), a SNAT does not accept inbound traffic, and this is where its security lies. When you define a SNAT, you can use it in any of the following ways:

• Assign a single SNAT address to a single node
• Assign a single SNAT address to multiple nodes
• Enable a SNAT for a VLAN (using vlan command) for SNAT auto-mapping
  
  

  Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server.

The attributes you can configure for a SNAT are shown in Table 3.18.

The attributes you can configure for a SNAT

Attributes	Description
Global SNAT properties	Before you can configure a SNAT, you must configure global properties for all SNATs on the BIG-IP.
Default SNAT	If you do not wish to configure specific SNATs, you can configure a default SNAT.
Individual SNAT	You can configure individual SNATs for specific hosts in the network.
SNAT auto-map	You can map a VLAN automatically to a SNAT address

Setting SNAT global properties

The SNAT feature supports three global properties that apply to all SNAT addresses:

• Connection limits
  The connection limit applies to each node that uses a SNAT.
• TCP idle connection timeout
  This timer defines the number of seconds that TCP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected.
• UDP idle connection timeout
  This timer defines the number of seconds that UDP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected. This value should not be set to 0.

To configure SNAT global properties using the Configuration utility

1. In the navigation pane, click SNATs.
   The SNATs screen opens.
2. In the Connection Limit box, type the maximum number of connections you want to allow for each node using a SNAT. To turn connection limits off, set the limit to 0.
3. In the TCP Idle Timeout box, type the number of seconds that TCP connections initiated by a node using a SNAT are allowed to remain idle.
4. In the UDP Idle Timeout box, type the number of seconds that UDP connections initiated by a node using a SNAT are allowed to remain idle. This value should not be set to 0.
5. Click the Apply button.

To configure SNAT global properties from the command line

Configuring global properties for a SNAT requires that you enter three bigpipe commands. The following command sets the maximum number of connections you want to allow for each node using a SNAT.

b snat limit <value>

The following commands set the TCP and UDP idle connection timeouts:

b snat timeout tcp <seconds>

b snat timeout udp <seconds>

Configuring SNAT address mappings

Once you have configured the SNAT global properties, you can configure SNAT address mappings. The SNAT address mappings define each SNAT address, and also define the node or group of nodes that uses the SNAT address. Note that a SNAT address does not necessarily have to be unique; for example, it can match the IP address of a virtual server. A SNAT address cannot match an address already in use by a NAT or another SNAT address.

SNAT mapping is done manually or automatically. A SNAT is mapped manually using Add SNAT in the Configuration utility or using the bigpipe snat map command. A SNAT is mapped automatically (to VLANs only) by enabling the snat automap flag on a VLAN using the vlan command.

To configure a SNAT mapping using the Configuration utility

1. In the navigation pane, click SNATs.
   The SNATs screen opens.
2. Click the Add button.
   The Add SNAT screen opens.
3. To Configure the SNAT, fill in the fields on the screen. For additional information about the options on this screen, click the Help button.

To configure a SNAT mapping from the command line

The bigpipe snat command defines one SNAT for one or more node addresses.

b snat map <orig_ip>... to <snat_ip>

For example, the command below defines a SNAT for two nodes:

b snat map 192.168.75.50 192.168.75.51 to 192.168.100.10

To define the default SNAT

Use the following syntax to define the default SNAT. If you use the netmask parameter and it is different from the external interface default netmask, the command sets the netmask and derives the broadcast address.

You can use the unit <unit ID> parameter to specify a unit in an active-active redundant configuration.

b snat map default to <snat_ip> \

[vlan <vlan_name> disable|enable] \

[unit <unit ID>] \

[netmask <ip>]

To create individual SNAT addresses

Use the following command syntax to create a SNAT mapping:

b snat map <orig_ip> [...<orig_ip>] to \
<snat_ip> [vlan <vlan_name> disable | enable] [unit <unit ID>] [netmask <ip>]

If the netmask is different from the external interface default netmask, the command sets the netmask and derives the broadcast address.

Enabling or disabling SNAT automap

A VLAN may be mapped automatically to a SNAT address. This means that if you enable snat automap on an internal VLAN, a SNAT is performed on any connection made from that VLAN. If the external VLAN has one self IP address enabled for snat automap, the translation address will be that self IP address. For VLANs external and internal, this would be implemented as follows:

b vlan internal snat automap enable

b self 10.0.0.1 vlan external snat automap enable

If the external VLAN has more than one self IP address enabled for snat automap (implying more than one IP network), the following rules apply:

• If the connection is handled by a non-forwarding virtual server, the translation address is the self IP address that matches the IP network of the node selected by load balancing.
• If the connection is handled by a forwarding virtual server or no virtual server, the translation address is the self IP address that matches the IP network of the next hop to the destination.
• If there are no self addresses that match the IP network of the node or the next hop, any self IP address on the VLAN is eligible.
  
  

  The SNAT automap feature is useful in the following cases:

• Where there is a need to ensure that outbound traffic returning through ISPs or NAT-less firewalls returns through the same ISP or firewall.
• Where a traditional single SNAT address would quickly exhaust the number of ephemeral ports available. As long as there is more than one eligible self IP address, SNAT auto-mapping can increase the number of simultaneous connections possible by using the same ephemeral port on multiple addresses.
• When the equivalent of a default SNAT is required for BIG-IP units in active-active mode, in other words, a SNAT that will continue to work in the event of a failure in one BIG-IP. (The conventional default SNAT does not work in active-active mode.)
  
  

  To create the equivalent of a default SNAT for BIG-IP units in active-active mode, it is necessary to assign each unit its own floating self IP address on the external interface. This is done for the same reason that separate aliases are assigned to the internal network as part of routine active-active setup. (Refer to Configuring an active-active system, on page 5-12.) Since you already have a floating self IP address for the external interface that is configured as belonging to unit one on unit one and unit two on unit two, the recommended way to create two unit-specific IP aliases is as follows.

To create two unit-specific IP aliases is as follows

1. On unit two, re-assign the existing internal floating self IP address to unit one. Example:
   b self 11.11.11.3 delete
   b self 11.11.11.3 vlan internal unit 1 floating enable
2. On unit two, create the second internal floating self IP address and assign it to unit two:
   b self 11.11.11.4 vlan internal unit 1 floating enable
3. Repeat the same command on unit one:
   b self 11.11.11.4 vlan internal unit 1 floating enable
   
   

   Then set up SNAT automap as you would for an active/standby system, only enable both external aliases:

   b self 11.11.11.3 vlan external snat automap enable

   b self 11.11.11.4 vlan external snat automap enable

   b vlan internal snat automap enable

   ISPs and NAT-less firewalls are handled in the following manner:

• If multiple external interfaces are available, the inside addresses of the firewalls in the load balancing pool may each be connected to different interfaces and assigned to different VLANs.
• Each VLAN is then automatically mapped to a SNAT when the snat automap flag is enabled.
• The snat automap flag must also be enabled for the internal VLAN.
  
  

  For example, if the internal VLAN is named internal and the external VLANs are named external1 and external2, you would type the following commands:

  b vlan internal snat_automap enable

  b vlan external1 snat_automap enable

  b vlan external2 snat_automap enable

• If multiple external interfaces are not available, the ISP routers or firewalls are assigned to different IP networks. This will already be the case for ISPs.
• For firewalls, the separate IP address ranges must be established on the inside and outside interfaces of each firewall. The separate networks are then assigned separate self addresses, for example, 10.0.0.1 and 11.0.0.1.
  
  

  Thus, if the internal and external VLANs are named internal and external, you would type the following commands:

  b self 10.0.0.1 vlan external snat automap enable

  b self 11.0.0.1 vlan external snat automap enable

  b vlan internal snat automap enable

To delete SNAT addresses

The following syntax deletes a specific SNAT:

b snat <snat_ip> | default delete

To show SNAT mappings

The following bigpipe command shows mappings:

b snat [<snat_ip>] [...<snat_ip>] show

b snat default show

The <snat_ip> can be either the translated or original IP address of the SNAT.

The following command shows the current SNAT connections:

b snat [<snat_ip>] [...<snat_ip>] dump [ verbose ]

b snat default dump [ verbose ]

The optional verbose keyword provides more detailed output.

The following command prints the global SNAT settings:

b snat globals show

To enable mirroring for redundant systems

The following example sets SNAT mirroring for all SNAT connections originating at 192.168.225.100:

b snat 192.168.225.100 mirror enable

To clear statistics

You can reset statistics by node or by SNAT address. Use the following syntax to clear all statistics for one or more nodes:

b snat <node_ip> [ ...<node_ip> ] stats reset

Use the following syntax to clear all statistics for one or more SNAT addresses:

b snat <snat_ip> [ ...<snat_ip> ] stats reset

Use the following command to reset the statistics to zero for the default:

b snat default stats reset

NATs

A network translation address (NAT) provides a routable alias IP address that a node can use as its source IP address when making or receiving connections to clients on the external network. (This distinguishes it from a SNAT, which can make outbound connections but refuses inbound connections.) You can configure a unique NAT for each node address included in a virtual server mapping.

Note: Note that NATs do not support port translation, and are not appropriate for protocols that embed IP addresses in the packet, such as FTP, NT Domain or CORBA IIOP. You cannot define any NAT if you configure a default SNAT.

The attributes you can configure for a NAT are shown in Table 3.19.

The attributes you can configure for a NAT

NAT Attributes	Description
Original address	The original address is the node IP address of a host that you want to be able to connect to through the NAT.
Translated address	The translated address is an IP address that is routable on the external network of the BIG-IP. This IP address is the NAT address.
Disabled VLAN list	VLANs to which the NAT is not to be mapped can be explicitly disabled, as when there is more than one internal VLAN.
Unit ID	You can specify a unit ID for a NAT if the BIG-IP is configured to run in active-active mode.

The IP addresses that identify nodes on the BIG-IP internal network need not be routable on the external network. This protects nodes from illegal connection attempts, but it also prevents nodes (and other hosts on the internal network) from receiving direct administrative connections, or from initiating connections to clients, such as mail servers or databases, on the BIG-IP external interface.

Using network address translation resolves this problem. Network address translations (NATs) assign to a particular node a routable IP address that the node can use as its source IP address when connecting to servers on the BIG-IP external interface. You can use the NAT IP address to connect directly to the node through the BIG-IP, rather than having the BIG-IP send you to a random node according to the load balancing mode.

Note: In addition to these options, you can set up forwarding virtual servers which allow you to selectively forward traffic to specific addresses. The BIG-IP maintains statistics for forwarding virtual servers.

Defining a network address translation (NAT)

When you define standard network address translations (NATs), you need to create a separate NAT for each node that requires a NAT. You also need to use unique IP addresses for NAT addresses; a NAT IP address cannot match an IP address used by any virtual or physical servers in your network. You can configure a NAT with the Configuration utility or from the command line.

To configure a NAT using the Configuration utility

1. In the navigation pane, click NATs.
   The NATs screen opens.
2. Click the Add button.
   The Add NAT screen opens.
3. In the Add NAT screen, fill in the fields to configure the NAT. For additional information configuring a NAT, click the Help button.

To configure a NAT from the command line

A NAT definition maps the IP address of a node <orig_addr> to a routable address on the external interface <trans_addr>. Use the following syntax to define a NAT:

b nat <orig_addr> to <trans_addr> [vlans <vlan_list> disable | enable] [unit <unit ID>]

The vlans <vlan_list> parameter is used to disable the specified VLANs for translation. By default, all VLANs are enabled.

Use the unit <unit ID> parameter to specify the BIG-IP to which this NAT applies in an active-active redundant system.

The following example shows a NAT definition:

b nat 10.10.10.10 to 10.12.10.10/24

To delete NATs

Use the following syntax to delete one or more NATs from the system:

b nat <orig_addr> [...<orig_addr>] delete

To display status of NATs

Use the following command to display the status of all NATs included in the configuration:

b nat show

Use the following syntax to display the status of one or more selected NATs (see Figure 3.23).

b nat <orig_addr> [...<orig_addr>] show

Figure 3.23 Output when you display the status of a NAT

 NAT { 10.10.10.3 to 9.9.9.9 }    
   	  (pckts,bits) in = (0, 0), out = (0, 0)    
   NAT { 10.10.10.4 to 12.12.12.12     
   	 netmask 255.255.255.0 broadcast 12.12.12.255 }    
   	  (pckts,bits) in = (0, 0), out = (0, 0)  

To reset statistics for a NAT

Use the following command to reset the statistics for an individual NAT:

b nat [<orig_addr>] stats reset

Use the following command to reset the statistics for all NATs:

b nat stats reset

Additional restrictions

The nat command has the following additional restrictions:

• The IP address defined in the <orig_addr> parameter must be routable to a specific server behind the BIG-IP.
• You must delete a NAT before you can redefine it.

Forwarding

Forwarding is the direct exposure of internal nodes to the external network. Because forwarding is inherently not secure, the use of NATs and SNATs is generally preferred to forwarding for the purpose of making hidden nodes accessible. By the same token, use of forwarding virtual servers, in which only selected nodes are exposed, is preferable to global IP forwarding.

Forwarding virtual servers

A forwarding virtual server is just like other virtual servers, except that the virtual server has no nodes to load balance. It simply forwards the packet directly to the node. Connections are added, tracked, and reaped just as with other virtual servers. You can also view statistics for forwarding virtual servers.

To configure forwarding virtual servers using the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. Click the Add button.
   The Add Virtual Server screen opens.
   Type the virtual server attributes including address and port.
3. In the Configure Basic Properties box, clear the check from Enable Arp.
4. On the Select Physical Resources screen, click the Forwarding button.
5. Click the Apply button.

To configure a forwarding virtual server from the command line

Use the following syntax to configure forwarding virtual servers:

b virtual <virt_ip>:<service> forward

b virtual <virt_ip>:<service> arp disable

For example, to allow only one service in:

b virtual 206.32.11.6:80 forward

b virtual <virt_ip>:<service> arp disable

Use the following command to allow only one server in:

b virtual 206.32.11.5:0 forward

b virtual <virt_ip>:<service> arp disable

To forward all traffic, use the following command:

b virtual 0.0.0.0:0 forward

Currently, there can be only one wildcard virtual server, whether that is a forwarding virtual server or not. In some of the configurations described here, you need to set up a wildcard virtual server on one side of the BIG-IP to load balance connections across transparent devices. Another wildcard virtual server is required on the other side of the BIG-IP to forward packets to virtual servers receiving connections from the transparent devices and forward them to their destination. You can use per-connection routing, with forwarding virtual servers, to route connections back through the device from which the connection originated. In these configurations, you need to create a forwarding virtual server for each possible destination network or host if a wildcard virtual server is already defined to handle traffic coming from the other direction.

IP forwarding

IP forwarding is a global setting that exposes the IP address of all internal nodes to the BIG-IP external network, and clients can use it as a standard routable address. When you turn IP forwarding on, the BIG-IP acts as a router when it receives connection requests for node addresses. You can use the IP filter feature to implement a layer of security that can help protect your nodes.

Options associated with IP forwarding are shown in Table 3.20.

The attributes you can configure for IP forwarding

Option	Description
Enable IP forwarding globally	You can turn IP forwarding on for the BIG-IP globally either with the Configuration utility, or by turning on the sysctl variable net.inet.ip.forwarding.
Addressing routing issues	If you turn on IP forwarding, you need to route packets to the node addresses through the BIG-IP.
Enable IP forwarding for a virtual server	Instead of turning IP forwarding on globally, you can create a special virtual server with IP forwarding on.

Setting up IP forwarding

If you do not want to translate addresses with a NAT or SNAT or use a forwarding virtual server, you can use the IP forwarding configuration option. IP forwarding is an alternate way of allowing nodes to initiate or receive direct connections from the BIG-IP external network. IP forwarding exposes all of the node IP addresses to the external network, making them routable on that network. If your network uses the NT Domain or CORBA IIOP protocols, IP forwarding is an option for direct access to nodes.

To set up IP forwarding, you need to complete two tasks:

• Turn IP forwarding on
  The BIG-IP uses a system control variable to control IP forwarding, and its default setting is off.
• Verify the routing configuration
  You probably have to change the routing table for the router on the BIG-IP external network. The router needs to direct packets for nodes to the BIG-IP, which in turn directs the packets to the nodes themselves.

Turning on IP forwarding

IP forwarding is a global property of the BIG-IP system.

To set IP forwarding using the Configuration utility

1. In the navigation pane, click System.
   The Network Map screen opens.
2. Click the Advanced Properties tab.
   The Advanced Properties screen opens.
3. Check the Allow IP Forwarding box.
4. Click Apply.

To set the IP forwarding global property from the command line

Use the bigpipe global ip_forwarding command to set the variable. The default setting for the variable is disabled. You want to change the setting to enabled:

b global ip_forwarding enabled

To permanently set this value, you can use a text editor, such as vi or pico, to manually edit the /etc/rc.sysctl file.

Addressing routing issues for IP forwarding

Once you turn on IP forwarding, you probably need to change the routing table on the default router. Packets for the node addresses need to be routed through the BIG-IP. For details about changing the routing table, refer to your router's documentation.

Health monitors

Health monitors verify connections and services on nodes that are members of load balancing pools. The monitor checks the node at a set interval. If the node does not respond within a specified timeout period, the node is marked down and traffic is no longer directed to it.

By default, an icmp (Internet Control Message Protocol) monitor is associated with every node that is a member of a load balancing pool. This monitor is of the simplest type, checking only the node address and checking only for a ping response. To change the interval and timeout values of this default check, or to check specific services on a node, you need to configure a custom monitor or monitors to add to the default monitor. The BIG-IP provides a variety of service-specific monitors in template form. Some of these monitors are usable as is (assuming their default values are acceptable) and may be put in service simply by associating them with the nodes to be monitored. In most cases, however, the template is used purely as a template for configuring custom monitors. Configuring custom monitors and placing them in service is a three-step process:

• Selecting the template
• Configuring the monitor from the template
• Associating the monitor with the node or nodes
  
  

  For example, for the default icmp monitor, we selected the icmp monitor template, as shown in Figure 3.24.

  Figure 3.24 The icmp monitor template

   monitor type icmp {
  	 interval 5
  	 timeout 16
  	 dest *	 
  }  

  The icmp monitor template has three attributes, interval, timeout, and dest, each with a default value. (All monitor templates have these three basic attributes. Other monitor templates have additional attributes as required by the service type.) These attributes are inherited by the custom monitor when it is configured and can be left at their default values or assigned new values as required.

  For the default monitor, template icmp is used as is, that is, as monitor icmp with its default attribute values. To change any of these default values, you need to create a custom monitor based upon icmp, for example, my_icmp. Only the values that are actually to be changed would need to be specified in the definition of the custom monitor. Therefore, if you wanted to change the timeout values only, you define the custom monitor as follows:

  b monitor my_icmp '{ use icmp timeout 20 }'

  This creates a new monitor in /config/bigip.conf, as shown in Figure 3.25. You can display this monitor using the command b monitor my_icmp show.

  Figure 3.25 Custom icmp monitor

   monitor my_icmp{
  	 #type icmp
  	 use "icmp"
  	 interval 5
  	 timeout 20
  	 }  

  Once the custom monitor exists, you associate it with a node or nodes using the Configuration utility or the bigpipe node command as follows.

  b node 11.11.11.1 11.11.11.2 11.11.11.3 monitor use my_icmp

  Note: The nodes are identified by IP address only. icmp can ping addresses only, not specific ports on addresses. This creates three instances of monitor my_icmp, one for each address. You can display the instances using the command b node monitor my_icmp show.

  Figure 3.26 Output for the command b node monitor show

   +- NODE  ADDRESS 11.11.11.1   UP
  |    |
  |    +- icmp
  |       11.11.11.1 up enabled 
  |
  +- NODE  ADDRESS 11.11.11.2   UP
  |    |
  |    +- icmp
  |       11.11.11.2 up enabled 
  |
  +- NODE ADDRESS 11.11.11.3  UP
       |
       +- icmp
          11.11.11.3 up enabled 
    

  Note that each instance takes as its destination the selfsame node it is associated with. This is because the dest value in my_icmp was left at the default *, which tells the instance to use the associated node as its destination. Assigning a specific address to dest, such as 11.11.11.1, would cause the monitor to verify all three addresses by checking that one address, making 11.11.11.2 and 11.11.11.3 dependent on 11.11.11.1.

Selecting the monitor template

Selecting a template is straightforward. Like icmp, each of the templates has a type based on the type of service it checks, for example, http, https, ftp, pop3, and takes that type as its name. (Exceptions are port-specific templates, like https_443, and the external template, which calls a user-supplied program.) To select a template, simply choose the one that corresponds in name and/or type to the service you want to check. If more than one service is to be checked, for example http and https, more than one monitor can be placed on the node. (This creates a rule, namely that the node will not be considered up unless both monitors run successful checks.) You may not want to check all services available on a node specifically. If you want to verify only that the destination IP address is alive, or that the path to it through a transparent node is alive, use one of the simple templates, icmp or tcp_echo. If you want to verify TCP only, use the monitor template tcp.

All monitor templates are contained in the read-only file /etc/base_monitors.conf. The following sections describe each of the monitor templates, its function, and the information required to configure a monitor from it. The templates are divided into three groups based on the types of monitors they support: simple monitors, ECV (Extended Content Verification) monitors, and EAV (Extended Application Verification) monitors. Also described are the port-specific monitor templates, which are derived from the other types.

Working with templates for simple monitors

Simple monitors are those that check node addresses only and verify simple connections only. Templates for these monitors are icmp and tcp_echo.

Note: The templates icmp and tcp_echo are both usable as is, that is, they may be associated with nodes. It is important to understand, however, that using a template as is means that you are using the default attribute values. To change any of these values, you have to configure a custom monitor based on the template.

Using icmp

The icmp template uses Internet Control Message Protocol to make a simple node check. The check is successful if a response to an ICMP_ECHO datagram is received. icmp has no attributes other than the standard interval, timeout, and dest.

Figure 3.27 The icmp monitor template

 monitor icmp {
	 type icmp
	 interval 5
	 timeout 16
	 dest *
	 }  

Using tcp_echo

The tcp_echo template uses Transmission Control Protocol. The check is successful if a response to a TCP ECHO message is received. tcp_echo also supports transparent mode. In this mode, the node with which the monitor is associated is pinged through to the destination node. (For more information about transparent mode, refer to Using transparent and reverse modes, on page 3-101.)

To use tcp_echo, you must ensure that TCP ECHO is enabled on the nodes being monitored.

Figure 3.28 The tcp_echo monitor template

 monitor tcp_echo  {
	 type tcp_echo
	 interval 5
	 timeout 16
	 dest *	 
    //transparent
    }  

Working with templates for ECV monitors

ECV monitors attempt to retrieve explicit content from nodes using send and recv statements. These include http, https and tcp.

Note: The templates http, https, and tcp are all usable as is, and you may associate them with nodes. It is important to understand, however, that using a template as is means that you are using the default attribute values. To change any of these values, you have to configure a custom monitor based on the template.

Using tcp

The tcp template is for Transmission Control Protocol. A tcp monitor attempts to receive specific content. The check is successful when the content matches the recv expression. A tcp monitor takes a send string and a recv expression. If the send string is left blank, the service is considered up if a connection can be made. A blank recv string matches any response. Both transparent and reverse modes are options. (For more information about transparent and reverse modes, refer to Using transparent and reverse modes, on page 3-101.)

Figure 3.29 The tcp monitor template

 monitor tcp  {
	 #  type tcp
	 interval 5
	 timeout 16
	 dest *:*	 
	 send ""
	 recv ""
	 //reverse
	 //transparent
	 }  

Using http

The http template is for HyperText Transfer Protocol. Like a tcp monitor, an http monitor attempts to receive specific content from a web page, and unlike a tcp monitor, sends a user name and password. The check is successful when the content matches the recv expression. An http monitor uses a send string, a recv expression, username, password, and optional get, url, transparent and reverse statements. (If there is no password security, use blank strings [""] for username and password.) The optional get statement replaces the send statement, automatically filling in the string "GET". Thus the following two statements are equivalent:

send "GET/"
get "/"

The optional url statement takes the HTTP URL as a value and automatically fills in the dest value with the address the URL resolves to. (For more information about transparent and reverse modes, refer to Using transparent and reverse modes, on page 3-101.) Both transparent and reverse modes are also options. (For more information about the get and url statements, refer to Using send, receive, url, and get statements, on page 3-100.)

Figure 3.30 The http monitor template

 monitor http {
	 type http
	 interval 5
	 timeout 16
	 dest *:*
	 send "GET /"
	 recv ""
	 username ""
	 password ""
	 //get
	 //url
	 //reverse
	 //transparent
	 }  

Using https

The https template is for Hypertext Transfer Protocol Secure. An https monitor attempts to receive specific content from a web page protected by SSL security. The check is successful when the content matches the recv expression. An https monitor uses a send string, a recv expression, and a username and password (If there is no password security, use blank strings [""] for username and password.) The optional get statement replaces the send statement, automatically filling in the string "GET". Thus, the following two statements are equivalent:

send "GET/"
get "/"

The optional url statement takes the HTTPS URL as a value and automatically fills in the dest value with the address the URL resolves to

Figure 3.31 The https monitor template

 monitor https {
	 type https
	 interval 5
	 timeout 16
	 dest *:*	 
	 send "GET /"
	 recv ""
	 //get
	 //url
	 username ""
	 password ""
	 }   

Working with templates for EAV monitors

EAV monitors verify applications on the node by running those applications remotely, using an external service checker program located in the directory /user/local/lib/pingers. These include ftp, pop3, smtp, sq., nntp, imap, ldap, and radius. Also included is the template external, which has a run attribute to specify a user-added external monitor.

Using ftp

The ftp template is for File Transfer Protocol. The monitor attempts to download a specified file to the /var/tmp directory. The check is successful if the file is retrieved. The ftp monitor takes a get statement, username, and password. The get statement takes the full path to the file as a value. The optional url statement may be used in place of get. The url takes the FTP URL as a value and automatically fills in the dest value with the address the URL resolves to. (For more information about the get and url statements, refer to Using send, receive, url, and get statements, on page 3-100.)

Figure 3.32 The ftp monitor template

 monitor ftp {
	 type ftp
	 interval 5
	 timeout 16
	 dest *:*
	 username ""
	 password ""
	 get ""
	 //url
	 }   

Using pop3

The pop3 template is for Post Office Protocol. The check is successful if the monitor is able to connect to the server, log in as the indicated user, and log out. The pop3 monitor requires username and password.

Figure 3.33 The pop3 monitor template

 monitor pop3 {
	 type pop3
	 interval 5
	 timeout 16
	 dest *:*
	 username ""
	 password ""
	 }  

Using smtp

The smtp template is for Simple Mail Transport Protocol servers. An smtp monitor is an extremely simple monitor that checks only that the server is up and responding to commands. The check is successful if the mail server responds to the standard SMTP HELO and QUIT commands. An smtp monitor requires a domain name.

Figure 3.34 The smtp monitor template

 monitor smtp {
	 type smtp
	 interval 5
	 timeout 16
	 dest *:*
	 domain ""
	 }     

Using nntp

The nntp template is for Usenet News. The check is successful if the monitor retrieves a newsgroup identification line from the server. An nntp monitor requires a newsgroup name (for example, "alt.cars.mercedes") and, if necessary, username and password.

Figure 3.35 The nntp monitor template

 monitor nntp {
	 type nntp
	 interval 5
	 timeout 16
	 dest *:*	 
	 username ""
	 password ""
	 newsgroup ""
	 }  

Using sql

The sql template is for service checks on SQL-based services such as Microsoft SQL Server versions 6.5 and 7.0, and also Sybase. The service checking is accomplished by performing an SQL login to the service. An executable program, tdslogin performs the actual login. The check is successful if the login succeeds.

An sql monitor requires a database (for example, "server_db"), username, and password.

Figure 3.36 The sql monitor template

 monitor sql {
	 type sql
	 interval 5
	 timeout 16
	 dest *:*	 
	 username ""
	 password ""
	 database ""
	 }   

Using imap

The imap template is for Internet Message Access Protocol. The imap monitor is essentially a pop3 monitor with the addition of the attribute folder, which takes the optional key message_num. The check is successful if the specified message number is retrieved. An imap monitor requires username, password, and a folder. It also takes an optional message number, message_num.

Figure 3.37 The imap monitor template

 monitor imap {
	 type imap
	 interval 5
	 timeout 16
	 dest *:*
	 username ""
	 password ""
	 folder ""
	 /message_num ""
	 }   

Using radius

The radius template is for Remote Access Dial-in User Service servers. The check is successful if the server authenticates the requesting user. A radius monitor requires a username, a password, and a shared secret string secret for the code number.

Note: Servers to be checked by a radius monitor typically require special configuration to maintain a high level of security while also allowing for monitor authentication.

Figure 3.38 The radius monitor template

 monitor radius {
	 type radius
	 interval 5
	 timeout 16
	 dest *	 
	 username ""
	 password ""
	 secret ""
	 }   

Using ldap

The ldap template is for Lightweight Directory Access Protocol, which implements standard X.500 for e-mail directory consolidation. A check is successful if entries are returned for the base and filter specified. An ldap monitor requires a username, a password, and a base and a filter string. The username is a distinguished name, that is, an LDAP-format user name. The base is the starting place in the LDAP hierarchy from which to begin the query. The filter is an LDAP-format key of what is to be searched for.

Note: Servers to be checked by an imap monitor typically require special configuration to maintain a high level of security while also allowing for monitor authentication.

Figure 3.39 A Sample monitor template

 monitor ldap {
	 type ldap
	 interval 5
	 timeout 16
	 dest *:*	 
	 username ""
	 password ""
	 base ""
	 filter ""
	 }    

Using external

The external template is for a user-supplied monitor. An external monitor requires the executable name (run) of that monitor and any command line arguments (args) required.

Figure 3.40 The external monitor template

 monitor external {
	 type external
	 interval 5
	 timeout 16
	 dest *:*	 
	 run ""
	 args ""
	 }   

Configuring a monitor

The second step in creating a monitor and placing it in service is to configure the monitor from the monitor template. Configuring a monitor consists of giving it a name distinct from the monitor template name and assigning values to all attributes that are not to be left at their default values (and adding any optional attributes that are not present by default, like reverse or transparent). You can do this using the Configuration utility or at the command line using the bigpipe monitor command.

To configure a monitor using the Configuration utility

1. In the navigation pane, click Monitors.
   The Network Monitors screen opens.
2. Click the Add button.
   The Add Monitor screen opens.
3. In the Add Monitor screen, type in the name of your monitor (it must be different from the monitor template name), and choose the monitor template you want to use.
4. Click the Next button and you will be guided through the configuration of your monitor.
   For additional information configuring a Monitor, click the Help button.

To configure a monitor from the command line

Use the bigpipe monitor command to configure the monitor at the command line. If the monitor is to be defined with all attributes set to their default values, type:

b monitor <name> '{ use <template_name> }'

If you want to set one or more attributes to a new value, specify only those attributes and their values. For example, to create a tcp_echo monitor my_tcp_echo in bigpipe using the default values for the attributes interval, timeout, and dest, you would type:

b monitor my_tcp '{ use tcp_echo }'

If any of the default values are to be changed, only these changes need to be specified. For example:

b monitor my_tcp-echo '{ use tcp_echo interval 10 timeout 20 }'

If an optional attribute is to be used, like transparent, add it to the list:

b monitor my_tcp-echo '{ use tcp_echo interval 10 timeout 20 transparent }'

Table 3.21 provides a summary of the monitor attributes and their definitions. For more information on the monitor templates and attributes, refer to Selecting the monitor template, on page 3-89

Monitor attributes

Attribute	Definition
interval <seconds>	Ping frequency time interval in seconds.
timeout <seconds>	Ping timeout in seconds.
dest <node_addr>	Ping destination node. <node_address> Usually *:* for simple monitors, *:* for all others, causing the monitor instance to ping the address or address:port for which it is instantiated. Specifying address and/or port forces the destination to that address/port.
send <string>	Send string for ECV. Default send and recv values are empty (""), matching any string.
recv <string>	Receive expression for ECV. Default send and recv values are empty (""), matching any string.
get <string>	For the http and https monitors get replaces the recv statement, automatically filling in "GET". For the ftp monitor get can be used to specify a full path to a file. This automatically fills in dest.
url	For the http and https, and ftp monitors, url replaces the recv statement, supplies a URL and automatically fills in dest with the URL address.
reverse	A mode that sets the node down if the received content matches the recv string.
transparent	A mode that forces pinging through the node to the dest address for transparent nodes, such as firewalls.
run <program>	An external user-added EAV program.
args <program_args>	List of command line arguments for external program. The args are quoted strings set apart by spaces.
username <username>	User name for services with password security. For ldap this is a distinguished, that is, LDAP-format user name.
password <password>	Password for services with password security.
newsgroup <newsgroup>	Newsgroup, for type nntp EAV checking only
database <database>	Database name, for type sql EAV checking only.
domain <domain_name>	Domain name, for type smtp EAV checking only
secret	Shared secret for radius EAV checking only.
folder	Folder name for imap EAV checking only.
message_num	Optional message number for imap EAV.
base	Starting place in the LDAP hierarchy from which to begin the query, for ldap EAV checking only.
filter	LDAP- format key of what is to be searched for, for ldap EAV checking only.

Entering string values

Except for interval, timeout, and dest, you should enter all attribute values as quoted strings, even if they are numeric, as in the case of code numbers.

Setting destinations

By default, all dest values are set to the wildcard "*" or "*:*". This causes the monitor instance created for a node to take that node's address or address and port as its destination. An explicit dest value is used only to force the instance destination to a specific address and/or port which may not be that of the node. For more information about setting destinations, refer to Associating the monitor with a node or nodes, on page 3-105.

Using send, receive, url, and get statements

The ECV monitor templates http, https, and tcp have the attributes send and recv for the send string and receive expression, respectively.

The most common send string is "GET /" which simply retrieves a default HTML page for a web site. To retrieve a specific page from a web site, simply enter a fully qualified path name:

"GET /www/support/customer_info_form.html"

The receive expression is the text string the monitor looks for in the returned resource. The most common receive expressions contain a text string that would be included in a particular HTML page on your site. The text string can be regular text, HTML tags, or image names.

The sample receive expression below searches for a standard HTML tag.

"<HEAD>"

You can also use the default null recv value "". In this case, any content retrieved is considered a match. If both send and recv are left empty, only a simple connection check is performed.

For http and ftp, the special attributes get or url may be used in place of send and recv statements. The attribute get takes the full path to the file as a value and automatically fills in the dest value with the address the path resolves to. The following two statements are equivalent:

send "GET/"
get "/"

The attribute url takes the URL as a value and automatically fills in the dest value with the address the URL resolves to. The URL is then resolved to supply the dest address automatically. The third statement below is equivalent to the first two combined:

dest 198.192.112.13:22
get "/"

url "ftp://www.my_domain.com/"

Using transparent and reverse modes

The ECV monitors have optional keywords transparent and reverse. (The keyword transparent may also be used by tcp_echo.) The normal and default mode for a monitor is to ping the dest node by an unspecified route and to mark the node up if the test is successful. There are two other modes, transparent and reverse.

In transparent mode, the monitor is forced to ping through the node it is associated with, usually a firewall, to the dest node. (In other words, if there are two firewalls in a load balancing pool, the destination node will always be pinged through the one specified and not through the one picked by the load balancing method.) In this way, the transparent node is tested as well: if there is no response, the transparent node is marked down. For more information about transparent mode, refer to Using transparent mode, on page 3-108.

In reverse mode, the monitor marks the node down when the test is successful. For example, if the content on your web site home page is dynamic and changes frequently, you may want to set up a reverse ECV service check that looks for the string "Error". A match for this string would mean that the web server was down. Transparent mode can also be used with tcp_echo.

Transparent and reverse modes cannot be used on the same monitor.

Testing SQL service checks

SQL service checks may require manual testing before being implemented in a monitor, as follows:

cd /usr/local/lib/pingers

./tdslogin 192.168.1.1 1433 mydata user1 mypass1

Replace the IP address, port, database, user, and password in this example with your own information.

You should receive the message:

Login succeeded!

If you receive the connection refused message, verify that the IP and port are correct.

If you are still having trouble, you should verify that you can log in using another tool. For example, if you have Microsoft NT SQL Server version 6.5, there is a client program ISQL/w included with the SQL software. This client program performs simple logins to SQL servers. Use this program to test whether you can login using the ISQL/w program before attempting logins from the BIG-IP.

On the SQL Server, you can run the SQL Enterprise Manager to add logins. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server to manage.

You can register servers by entering the machine name, user name, and password. If these names are correct, the server will be registered and you will be able to click an icon for the server. When you expand the subtree for the server, there will be an icon for Logins.

Underneath this subtree, you can find the SQL logins. Here, you can change passwords or add new logins by right-clicking the Logins icon. Click this icon to open an option to Add login. After you open this option, enter the user name and password for the new login, as well as which databases the login is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.

Running user-added EAVs

You may add your own monitors to those contained in /user/local/lib/pingers. For running these added programs, the monitor template external is used. The executable program is specified as the value of the attribute run. By default, the monitor looks for the run program in /user/local/lib/pingers. If the program resides elsewhere, a fully qualified path name must be entered. Any command line arguments to be used with the program are entered as args values. For example, suppose the program my_pinger is to be run with a -q option, so that it would be entered on the command line as follows:

my_pinger -q

This monitor might be specified as follows:

b monitor custom '{ use external run "my_pinger" args "-q" }'

Alternatively, you may pass arguments to the external monitor as environment variables. For example, you might want to enter this command:

/var/my_pinger /www/test_files/first_test

This could be specified in the conventional manner:

b monitor custom '{ use external run "/var/my_pinger" args "www/test_files/first_test" }'

It could also be specified in this way:

b monitor custom '{ use external run "/var/my_pinger" DIRECTORY " "www/test_files" FILE "first_test" }'

This defines the monitor as shown in Figure 3.41.

Figure 3.41 Monitor template for an external monitor

 monitor custom { 
	 use external
	 run "/var/my_pinger"
	 DIRECTORY "www/test_files" 
	 FILE "first_test" }  

This frees the monitor definition from the rigidity of a strictly ordered command line entry. The arguments are now order-independent and may be used or ignored by the external executable.

Showing, disabling, and deleting monitors

Showing, disabling, and deleting monitors can be performed in the Configuration utility or at the command line. Deleting a monitor removes it from the /config/bigip.conf file. Disabling a monitor instance simply removes that instance from service until it is re-enabled. Disabling a monitor (which can be performed only at the command line) disables all instances of the monitor. All monitor instances are enabled by default.

To show or delete a monitor using the Configuration utility

1. In the navigation pane, click Monitors.
   A screen opens that lists monitors in two columns, System Supplied and User Defined.
2. To show a monitor, simply click the monitor name.
3. To delete a monitor, click the Delete button for the monitor. Note that only user-defined monitors can be deleted.

To show a monitor from the command line

You can display a selected monitor or all monitors using the bigpipe monitor show command:

b monitor <name> show

b monitor show all

To delete a monitor from the command line

You can delete a selected monitor using the bigpipe monitor delete command:

b monitor <name> delete

To disable a monitor instance using the Configuration utility

1. In the navigation pane, click Monitors.
   The Monitors screen opens.
2. Click the appropriate tab for the monitor instances: Basic Associations, Node Associations, or Node Address Associations. The resulting screen shows the existing associations (monitor instances).
3. Click the node you want to disable.
   The Properties screen for that node opens.
4. In the Monitor Instances portion of the screen, clear the Enable check box.
5. Click Apply.
   The monitor instance is now disabled.

To disable a monitor or monitor instance from the command line

To disable a monitor, use the bigpipe monitor <name> disable command:

b monitor <name> disable

This has the effect of disabling all instances of the monitor, as shown in Figure 3.42.

Figure 3.42 All monitor instances disabled

 +- NODE  11.12.11.20:80   UP
|    |
|    +- http
|       11.12.11.20:80 up disabled 
|
+- NODE  11.12.11.21:80   UP
|    |
|    +- http
|       11.12.11.21:80 up disabled 
|
+- NODE  11.12.11.22:80   UP
     |
     +- http
        11.12.11.22:80 ip disabled 
   

To disable a monitor instance, use the bigpipe monitor instance <addr:port> disable command:

b monitor instance <addr:port> disable

Disabled monitors and instances may be re-enabled as follows:

b monitor <name> enable

b monitor instance <addr:port> enable

To delete a monitor from the command line

You can delete a monitor with no existing node associations and no references in a monitor rule. To delete a monitor, use the bigpipe monitor <name> delete command:

b monitor my_http delete

If the monitor has instances, the instances must first be deleted using the bigpipe node <addr:port> monitor delete command. (Refer to Showing and deleting associations, on page 3-110.)

Associating the monitor with a node or nodes

Now that your monitor exists, the final step is to associate it with the nodes to be monitored. This creates an instance of the monitor for each node. At the command line, association is done using bigpipe node command:

b node <addr_list> monitor use <name>

For example, to associate monitor http with nodes 11.12.11.20:80, 11.12.11.21:80, and 11.12.11.22:80, the bigpipe node command would be as follows:

b node 11.12.11.20:80 11.12.11.21:80 11.12.11.22:80 monitor use http

This creates a monitor instance of http for each of these nodes. You can verify this association using the bigpipe monitor show command:

b node monitor show

This would produce the output shown in Figure 3.43.

Figure 3.43 The output of the b node monitor show command

 +- NODE  11.12.11.20:80   UP
|    |
|    +- http
|       11.12.11.20:80 up enabled 
|
+- NODE  11.12.11.21:80   UP
|    |
|    +- http
|       11.12.11.21:80 up enabled 
|
+- NODE  11.12.11.22:80   UP
     |
     +- http
        11.12.11.22:80 ip enabled 
  

The actual monitor instance for each node is represented by the output lines highlighted with bold text in Figure 3.43.

Reviewing types of association

While the term node association is applied generally, there are three types of association based on whether the monitor is associated with an address and a port, address(es) only, or port only. These are node association, address association, and port association.

• Node association, strictly defined, is the association of a monitor with an address and port.
• Address association is the association of a monitor with an address only.
• Port association is the association of a monitor with a port only. For a port association, a wildcard character (*) is used to represent all addresses.
  
  

  Once a monitor has been associated with a node, address, or port, no other monitor can be associated with the same node, address or port. However, an address association does not prevent a monitor from being associated with a node of the same address, or vice versa.

Using a simple association

The http example given above is the simplest kind of association, a node association performed using a monitor with a dest value of *:*. It can be seen in Figure 3.30, on page 3-92, that in each case the instance destination node is identical to the node the monitor has been associated with. This is because the template http, shown in Figure 3.30, was used as is, with a dest value of *:*. Either or both wildcard symbols can be replaced by an explicit dest value by creating a new monitor based on http. This is referred to as node and port aliasing, described below.

Using node and port aliasing

Usually the health of a node is checked by pinging that node. For this reason the dest attribute in the monitor template is always set to "*" or "*:*". This causes the monitor instance created for a node to take that node's address or address and port as its destination. An explicit dest value forces the instance destination to a specific address and/or port which may not be that of the node. This causes the monitor to ping that forced destination by an unspecified path. Suppose, for example, that the association performed using http instead used a monitor my_http with a dest value of *:443. The node association command would be identical except that http is now replaced with my_http:

b node 11.12.11.20:80 11.12.11.21:80 11.12.11.22:80 monitor use my_http

This creates three instances of the monitor with the following dest values as shown in Figure 3.44.

Figure 3.44 Node ports aliased

 +- NODE  11.12.11.20:80   UP
|    |
|    +- my_http
|       11.12.11.20:443 up enabled 
|
+- NODE  11.12.11.21:80   UP
|    |
|    +- my_http
|       11.12.11.21:443 up enabled 
|
+- NODE  11.12.11.22:80   UP
     |
     +- my_http
        11.12.11.22:443 up enabled   

This is referred to as port aliasing. The node itself can also be aliased, by assigning an explicit address to dest. For example, dest could set to 11.11.11.1:80. This is called node aliasing and for the nodes 11.12.11.20:80, 11.12.11.21:80, and 11.12.11.21:80 it would produce the following instances, (which are in fact one instance associated with three different nodes) as shown in Figure 3.45.

Figure 3.45 Node addresses aliased

 +- NODE  11.12.11.20:80   ADDR UP
|    |
|    +- my_http
|       11.11.11.1:80 checking enabled 
|
+- NODE  11.12.11.21:80   ADDR UP
|    |
|    +- my_http
|       11.11.11.1:80 checking enabled 
|
+- NODE  11.12.11.22:80   ADDR UP
     |
     +- my_http
        11.11.11.1:80 checking enabled    

Using transparent mode

Sometimes it is necessary to ping the aliased destination through a transparent node. Common examples are checking a router, or checking a mail or FTP server through a firewall. For example, you might want to check the router address 10.10.10.53:80 through a transparent firewall 10.10.10.101:80. To do this, you would specify 10.10.10.53:80 as the monitor dest address (a node alias) and add the flag transparent:

b monitor http_trans '{ use http dest 10.10.10.53:80 transparent }'

Then you would associate the monitor http_trans with the transparent node:

b node 10.10.10.101:80 monitor use http_trans

This causes the address 10.10.10 53:80 to be checked through 10.10.10.101:80. (In other words, the check of 10.10.10.53:80 is routed through 10.10.10.101:80.) If the correct response is not received from 10.10.10.53:80, then 10.10.10.101:80 is marked down.

Note: Transparent mode applies only to the ECV monitors and to tcp_echo.

Using logical grouping

In the examples above, only one monitor has been associated with the nodes. You may associate more than one monitor with a node or nodes by joining them with the Boolean operator and. This creates a rule, and the node is marked down if the rule evaluates to false, that is, if not all the checks are successful. The most common example is use of an HTTP monitor and an HTTPS monitor:

b node 11.12.11.20:80 monitor use my_http and my_https

The monitors themselves must be configured with the grouping in mind. For example, if the dest values of both monitors were set to *:*, then both monitor instances would try to ping the default port 80. This would both defeat the purpose of the HTTPS monitor and cause an automatic failure, since two monitors would be trying to ping the same address and port simultaneously.

Instead, monitor my_http should be given a dest value of *:* and monitor my_https should be given a dest value of *:443. This causes only the my_http monitor instances to default to 80. The my_https monitor instances are forced to the explicit port 443, avoiding a conflict as shown in Figure 3.46.

Figure 3.46 Use of a rule

 MONITOR  my_http and https_443
|
+- NODE  11.12.11.20:80   UP
|    |
|    +- my_http
|    |  11.12.11.20:80 up enabled 
|    |
|    +- https_443
        11.12.11.20:443 up enabled   

Using wildcards to specify addresses

The wildcard * can be used to specify addresses. A wildcard address association creates instances of the monitor for all nodes load balanced by the BIG-IP:

b node * monitor use my_tcp_echo:

Figure 3.47 Wildcard address association

 MONITOR  my_tcp_echo  (default node address monitor)  

A wildcard with a port association creates instances of the monitor for every node configured to service that port:

b node *:80 monitor use my_http:

Figure 3.48 Wildcard address with port association

 MONITOR  my_http  (default port 80 monitor)  

To associate a monitor using the Configuration utility

1. In the navigation pane, click Monitors.
   The Network Monitors screen opens.
2. Click one of three tabs:
   
   
   • If you are associating the monitor with a node (the IP address plus the port) click the Node Associations tab.
   • If you are associating the monitor with a node address only (the IP address minus the port), click the Node Address Associations tab.
   • If you are associating the monitor with a port only (the port minus the IP address), click the Port Associations tab.
3. Regardless of the selection you made in step 2, a dialog box appears with the entry fields Choose Monitor and Monitor Rule. Enter the monitor or select one from the list.
4. If you want to associate more than one monitor, click the Move >> button to enter the monitor selected in the Monitor Rule box.
5. Repeat the previous two steps for each monitor you want to associate with a node.
6. Click Apply to associate the monitor(s).
   For additional information associating a monitor, click the Help button.

Showing and deleting associations

There are node commands for showing, and deleting node associations.

To show or delete associations using the Configuration utility

1. In the navigation pane, click Monitors.
   The Network Monitors screen opens.
2. Click one of three tabs:
   
   
   • If you are showing or deleting a node association (a node is the IP address plus the port) click the Node Associations tab.
   • If you are showing or deleting a node address association (the IP address minus the port), click the Node Address Associations tab.
   • If you are showing or deleting a port association (the port minus the IP address), click the Port Associations tab.
3. Regardless of the selection you made in step 2, a dialog box appears showing existing associations and with a Delete Existing Associations check box. Delete associations by checking the box, then clicking Apply. Note that for wildcard address associations, the wildcard (*) association itself is shown in addition to each of the individual associations it produces. To delete all these associations, it is necessary to delete the wildcard association.

To show associations from the command line

You can display a selected node association or all node associations using the bigpipe node monitor show command:

b node monitor show

b node <addr:port> monitor show

To delete associations from the command line

You can delete a selected node association or all node associations using the bigpipe node monitor delete command:

b node <addr:port> monitor delete

In deleting specific monitor instances, it is important to consider how the association was made. If a monitor instance was created using a wildcard address, the wildcard must be deleted. For example, if multiple associations were created by entering b node *:80 monitor use my_tcp_echo, you would delete it by typing:

b node *:80 monitor delete

If multiple associations were created by entering b node * monitor use my_tcp_echo, you would delete it by typing:

b node * monitor delete