2

Working with Special Features

Introducing special features

In addition to the basic setup features available on the BIG-IP Controller, a number of special setup features can be used to optimize your network. This chapter describes special setup options available on the BIG-IP Controller. These features are optional, and may not be required in your implementation of the BIG-IP Controller. The following topics are described in this chapter:

• Using specialized load balancing modes
• Controlling network access and traffic flow with filters
• Working with more than two interface cards
• Optimizing large configurations
• Using the versatile interface configuration options
• Configuring RADIUS authentication

Using specialized load balancing modes

Load balancing is an integral part of the BIG-IP Controller. A load balancing mode defines, in part, the logic that a BIG-IP Controller uses to determine which node should receive a connection hosted by a particular virtual server. The BIG-IP Controller supports specialized load balancing modes that dynamically distribute the connection load, rather than following a static distribution pattern such as Round Robin. Dynamic distribution of the connection load is based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. The following section describes how each load balancing mode distributes connections, as well as how to set the load balancing mode on the BIG-IP Controller. The global load balancing method is not saved as part of BIG-IP Controller configuration. When you define a global method, the global method is set for all pools without a load balancing method, and any pool with an appgen_ name prefix.

Note: These load balancing modes apply globally. For information about the specific load balancing methods designed for use with pools, see Chapter 3, Working with Intelligent Traffic Control.

Understanding individual load balancing modes

Individual load balancing modes take into account one or more dynamic factors, such as current connection count. Because each application of the BIG-IP Controller is unique, and node performance depends on a number of different factors, we recommend that you experiment with different load balancing modes, and choose the one that offers the best performance in your particular environment.

Note: It is important to note that the load balancing methods described in this section are the advanced load balancing modes. For more information about Round Robin or Ratio mode, see the BIG-IP Controller Getting Started Guide.

Fastest mode

Fastest mode passes a new connection based on the fastest response of all currently active nodes. Fastest mode may be particularly useful in environments where nodes are distributed across different logical networks.

Least Connections mode

Least Connections mode is relatively simple in that the BIG-IP Controller passes a new connection to the node with the least number of current connections. Least Connections mode works best in environments where the servers or other equipment you are load balancing have similar capabilities.

Observed mode

Observed mode uses a combination of the logic used in the Least Connection and Fastest modes. In Observed mode, nodes are ranked based on a combination of the number of current connections and the response time. Nodes that have a better balance of fewest connections and fastest response time receive the a greater proportion of the connections. Observed mode also works well in any environment, but may be particularly useful in environments where node performance varies significantly.

Predictive mode

Predictive mode also uses the ranking methods used by Observed mode, where nodes are rated according to a combination of the number of current connections and the response time. However, in Predictive mode, the BIG-IP Controller analyzes the trend of the ranking over time, determining whether a node's performance is currently improving or declining. The nodes with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. Predictive mode works well in any environment.

Priority mode

Priority mode is a special type of round robin load balancing. In Priority mode, you define groups of nodes and assign a priority level to each group. The BIG-IP Controller begins distributing connections in a round robin fashion to all nodes in the highest priority group. If all the nodes in the highest priority group go down or hit a connection limit maximum, the BIG-IP Controller begins to pass connections on to nodes in the next lower priority group.

For example, in a configuration that has three priority groups, connections are first distributed to all nodes set as priority 3. If all priority 3 nodes are down, connections begin to be distributed to priority 2 nodes. If both the priority 3 nodes and the priority 2 nodes are down, connections then begin to be distributed to priority 1 nodes, and so on. Note, however, that the BIG-IP Controller continuously monitors the higher priority nodes, and each time a higher priority node becomes available, the BIG-IP Controller passes the next connection to that node.

Setting the global load balancing mode

The load balancing mode is a system property of the BIG-IP Controller, and it applies to all standard and wildcard virtual servers defined in the configuration.

To set the global load balancing mode in the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the Node List Load Balance Method box, choose the desired load balancing mode.
3. Click Apply.

Warning: If you select Ratio mode or Priority mode, be sure to set the ratio weight or priority level for each node address in the configuration.

To set the load balancing mode on the command line

The command syntax for setting the load balancing mode is:

  bigpipe lb <mode name>

Table 2.1 describes the valid options for the <mode name> parameter.

Options for the <mode name> parameter.

Mode Name	Description
priority	Sets load balancing to Priority mode.
least_conn	Sets load balancing to Least Connections mode.
fastest	Sets load balancing to Fastest mode.
observed	Sets load balancing to Observed mode.
predictive	Sets load balancing to Predictive mode.

Note: It is important to note that the load balancing methods described in this section are the advanced load balancing modes. For more information about Round Robin or Ratio mode, see the BIG-IP Controller Getting Started Guide.

Setting ratio weights and priority levels for node addresses

If you set the load balancing mode to either Ratio mode or Priority mode, you need to set a special property on each node address.

• Ratio weight
  The ratio weight is the proportion of total connections that the node address should receive. The default ratio weight for a given node address is 1. If all node addresses use this default weight, the connections are distributed equally among the nodes.
• Priority level
  The priority level assigns the node address to a specific priority group.

To set ratio weights and priority levels in the Configuration utility

1. In the navigation pane, click Nodes.
2. In the Nodes list, click the node for which you want to set the ratio weight.
   The Node Properties screen opens.
3. In the Node Properties screen, click the Address of the node.
   The Global Node Address Properties screen opens.
4. In the Ratio or Priority box, type the ratio weight of your choice.
5. Click the Apply button to save your changes.

To set ratio weights on the command line

The bigpipe ratio command sets the ratio weight for one or more node addresses:

  bigpipe ratio <node IP> [<node IP>...] <ratio weight>

The following example defines ratio weights and priority for three node addresses. The first command sets the first node to receive half of the connection load. The second command sets the two remaining node addresses to each receive one quarter of the connection load.

  bigpipe ratio 192.168.10.01  2

  bigpipe ratio 192.168.10.02  192.168.10.03  1

Warning: If you set the load balancing mode to Ratio or Priority, you must define the ratio or priority settings for each node address. The value you define using the bigpipe ratio command is used as the ratio value if Ratio is the currently selected load balancing mode, and the same value is used as the priority level if Priority is the currently selected load balancing mode.

Controlling network access and traffic flow with filters

Filters control network traffic by setting whether packets are forwarded or rejected at the external network interface. Filters apply to both incoming and outgoing traffic. When creating a filter, you define criteria which are applied to each packet that is processed by the BIG-IP Controller. You can configure the BIG-IP Controller to forward or block each packet based on whether or not the packet matches the criteria.

The BIG-IP Controller supports two types of filters, IP filters and rate filters.

IP filters

Typical criteria that you define in IP filters are packet source IP addresses, packet destination IP addresses, and upper-layer protocol of the packet. However, each protocol has its own specific set of criteria that can be defined.

For a single filter, you can define multiple criteria in multiple, separate statements. Each of these statements should reference the same identifying name or number, to tie the statements to the same filter. You can have as many criteria statements as you want, limited only by the available memory. Of course, the more statements you have, the more difficult it is to understand and maintain your filters.

Configuring IP filters

When you define an IP filter, you can filter traffic in two ways:

• You can filter traffic going to a specific destination or coming from a specific destination, or both.
• The filter can allow network traffic through, or it can reject network traffic.

Defining an IP filter in the Configuration utility

1. In the navigation pane, click IP Filters.
   The IP Filters screen opens.
2. In the IP Filters screen, click Add Filter.
   The Add IP Filter screen opens.
3. On the Add IP Filter screen, in the Name box, type a filter name.
4. From the Type list, choose Accept Packet to allow traffic, or Deny Packet to reject traffic.
5. In the Source IP Address box, only if you want the filter to be applied to network traffic based on its source, enter the IP address from which you want to filter traffic.
6. In the Source Port box, only if you want the filter to be applied to network traffic based on its source, enter the port number from which you want to filter traffic.
7. In the Destination IP Address box, enter the IP address to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
8. In the Destination Port box, enter the port number to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
9. Click Add to add the IP filter to the system.

Note: For information on configuring IP filters and rate filter on the command line, refer to the IPFW man page by typing man ipfw on the command line. You can configure more complex filtering through the IPFW command line interface.

Rate filters and rate classes

In addition to IP filters, you can also define rates of access by using a rate filter. Rate filters consist of the basic filter and a rate class. Rate classes define how many bits per second are allowed per connection and the number of packets in a queue.

Configuring rate filters and rate classes

Rate filters are a type of extended IP filter. They use the same IP filter method, but they apply a rate class which determines the volume of network traffic allowed through the filter.

Tip: You must define at least one rate class in order to apply a rate filter.

Rate filters are useful for sites that have preferred clients. For example, an e-commerce site may want to set a higher throughput for preferred customers, and a lower throughput for random site traffic.

Configuring rate filters involves both creating a rate filter and a rate class. When you configure rate filters, you can use existing rate classes. However, if you want a new rate filter to use a new rate class, you must configure the new rate class before you configure the new rate filter.

To configure a new rate class in the Configuration utility

1. In the navigation pane, click Rate Filters.
   The Rate Filters screen opens.
2. In the Rate Filters screen, click Add Class.
   The Rate Class screen opens.
3. On the Rate Class screen, in the Name box, type a rate class name.
4. In the Bits Per Second Allowed box, enter the maximum number of bits per second that you want the class to allow.
5. In the Minimum Number of Bits Outstanding box, enter the minimum number of bits required to be sent for processing from the queue at one time.
6. In the Queue Length (in Packets) box, enter the maximum number of packets allowed in the queue. Once the BIG-IP Controller fills the queue, it begins to drop subsequent packets received.
7. Click Add to add the rate class to the system.

Note: For information on configuring IP filters and rate filters on the command line, refer to the IPFW man page.

After you have added a rate class, you can configure rate filters for your system.

To configure a rate filter in the Configuration utility

1. Click Rate Filters in the navigation pane.
   The Rate Filters screen opens.
2. In the Rate Filters screen, click Add Class.
   The Add Class screen opens.
3. On the Rate Filter screen, in the Name box, type a name for the rate filter.
4. From the Rate Class list, choose a rate class. Note that you must have a rate class defined before you can proceed.
5. In the Source IP Address box, enter the IP address from which you want to filter traffic, only if you want the filter to be applied to network traffic based on its source.
6. In the Source Port box, enter the port number from which you want to filter traffic, only if you want the filter to be applied to network traffic based on its source.
7. In the Destination IP Address box, enter the IP address to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
8. In the Destination Port box, enter the port number to which you want to filter traffic, only if you want the filter to be applied to network traffic based on its destination.
9. Click the Add button.

Note: For information on configuring IP filters and rate filter on the command line, refer to the IPFW man page.

Working with more than two interface cards

When you configure a BIG-IP Controller with more than two interface cards installed, you need to address the following issues:

• Additional interfaces should be configured.
• You need to specify an interface for each virtual server.
• You need to define an interface for NATs.
• You need to define an interface for SNATs.
• Verify routing with multiple NICs.
• Edit httpd.conf for network administration with the BIG-IP web server.

Configuring additional interfaces with the First-Time Boot utility

The first step in configuring the BIG-IP Controller with additional interfaces is to run the First-Time Boot utility. This utility detects how many NICs are present in the BIG-IP Controller and displays a list of NICS detected. Choose the interface from the list that you want to configure.

You can also designate one of your additional internal NICs with the IP address for which access is permitted for network administration using SSH (or Telnet for international users).

The First-Time Boot utility, config, detects and configures additional interfaces if they are present in the BIG-IP Controller.

Running the First-Time Boot utility

As Administrator with root-level permission, enter the following command from the command line:

  config

When asked to configure the web server, you are prompted to define a domain name for the interface.

The First-Time Boot utility creates a new /etc/netstart script which supports more than two NICs. It also modifies the /etc/ethers and the interface entries in the BIG/db database.

Note: When you rerun the First-Time Boot utility, it does not replace or change your existing /etc/bigip.conf or your /etc/bigd.conf files.

You may need to edit the /etc/bigip.conf file using a text editor such as vi or pico to add the appropriate interface statements. For example, if you want to designate exp2 as an internal, destination processing interface, add the following lines to the /etc/bigip.conf file:

  interface exp0 dest enable

  interface exp0 source disable

  interface exp0 adminport lockdown

  interface exp2 failsafe disarm

  interface exp2 timeout 30

Once you are done editing the bigip.conf file, reboot the BIG-IP Controller, or restart bigd by typing bigd on the command line and pressing Enter, in order to implement your changes.

Specifying an interface for a virtual address

When you define a virtual server on a BIG-IP Controller that has more than one external interface (destination processing), you need to specify the external interface (destination processing) that the virtual server's address is associated with.

Warning: All virtual servers that share a virtual address must be associated with the same external interface.

To specify a virtual server interface in the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the toolbar, click Add Virtual Server.
   The Add Virtual Server screen opens.
3. In the Add Virtual Server screen, type in the properties for the virtual server you want to add including the address and port.
4. Click the Add button.

To specify a virtual server interface on the command line

You can define virtual servers with the bigpipe vip command. Normally, a virtual server is added to the external interface with a network address that matches the network of the virtual address. However, with multiple NICs you can specify which external interface (destination processing) a virtual server is added to using the bigpipe vip command. To do this, add the <ifname> argument to the command.

  bigpipe vip <virt addr>:<port>[/<bitmask>] [<ifname>] \
 [unit <ID>] define <node addr>:<port> ... <node addr>:<port>   
 

  bigpipe vip <virt addr>:<port> [<ifname>] [unit <ID>] [netmask \ 
<netmask> [broadcast <broadcast_ip>]] \
 define <node addr>:<port> ... \ <node addr>:<port>   
 

You can set the <ifname> parameter to none if you want to prevent BIG-IP from issuing ARP requests for a specific virtual server. The traffic for a virtual server is accepted on any interface with destination processing enabled, even if the BIG-IP Controller only responds to ARP requests on one interface or if you specify none.

Note: This has the same effect as using the sysctl variable bigip.vipnoarp, but on a server-by-server basis. The sysctl variable bigip.vipnoarp is deprecated. We recommend defining the interface none.

The following example shows how to define a virtual server that is added to a Gigabit Ethernet NIC.

  bigpipe vip 210.12.150.100:80/24 sk0 define 192.158.11.100:80 \ 
192.158.11.101:80 192.158.11.102:80

Specifying an interface for a NAT address

When you define a NAT address on a BIG-IP Controller that has more than one external interface, you need to specify the external interface that the virtual server's address is associated with.

To specify an interface for a NAT in the Configuration utility

1. In the navigation pane, click NATs.
   The Network Address Translations (NATs) screen opens.
2. Click the NAT you want to configure.
   The NAT Properties screen opens.
3. In the Interface list, choose the destination processing interface to which you want to assign this NAT.
4. Click the Apply button.

To specify an interface for a NAT on the command line

When mapping a network address translation with the bigpipe nat command, you must now specify which external interface a virtual IP address is added to by using the <ifname> parameter.

  bigpipe nat <internal_ip> to <external_ip> [/<bitmask>] \ 
[<ifname>] [unit <ID>]

  bigpipe nat <internal_ip> to <external_ip> [netmask \
 <netmask>] [broadcast <broadcast_ip>] |/<bitmask>] \
 [<ifname>] [unit <ID>]   
 

The following example shows how to define a NAT where the IP address represented by <external_ip> is added to an Intel NIC.

  bigpipe nat 11.0.0.100 to 10.0.140.100/24 exp0

Specifying an interface for a SNAT address

When you define a SNAT address on a BIG-IP Controller that has more than one external interface, you need to specify the external interface that the virtual server's address is associated with.

Warning: All virtual servers that share a virtual address must be associated with the same external interface.

To specify an interface for a SNAT in the Configuration utility

1. In the navigation pane, click Secure NATs.
   The Secure Network Address Translations (SNATs) screen opens.
2. Click the SNAT you want to configure.
   The SNAT Properties screen opens.
3. In the Interface list, choose the destination processing interface to which you want to assign this SNAT.
4. Click Apply.

To specify an interface for a SNAT on the command line

When mapping a secure network address translation with the bigpipe snat command, you must specify which external interface a virtual IP address is added to by using the <ifname> parameter.

  bigpipe snat map <internal_ip> to <external_ip> [/<bitmask>] \ 
[<ifname>] [unit <ID>]

  bigpipe snat map <internal_ip> to <external_ip> [<ifname>] 
[netmask] <netmask> [broadcast <broadcast_ip>] | /<bitmask>] 
[unit <ID>]

The following example shows how to define a SNAT where the IP address represented by <external_ip> is added to an Intel NIC.

  bigpipe snat map 11.0.0.100 to 10.0.140.100/24 exp0

Routing with multiple NICs

Use Router Discovery Protocol (RDP) for routing on a BIG-IP Controller with more than one interface. For router configuration information, please refer to documentation included with your router.

Optimizing large configurations

The BIG-IP Controller supports up to 40,000 virtual servers and nodes combined. Larger configurations on a BIG-IP Controller, such as those that exceed 1,000 virtual servers or 1,000 nodes, introduce special configuration issues. To ensure a high performance level, you need to change certain aspects of the BIG-IP Controller's management of virtual servers and nodes. The following steps can be taken to optimize a large configuration.

• Reduce ARP traffic on the external network
• Reduce the number of node pings and service checks issued by the BIG-IP Controller

Reducing ARP traffic on the external network

The BIG-IP Controller maintains an IP alias on its external interface for each virtual address that it manages. IP aliases are broadcast on the network when a virtual server is defined, and also each time a BIG-IP Controller switches from standby mode to active mode in a redundant system. If you have defined thousands of virtual addresses in the BIG-IP Controller configuration, the corresponding ARP requests may lead to a significant increase in network traffic.

This type of configuration also increases fail-over recovery time in BIG-IP redundant systems. When a fail-over occurs, the BIG-IP Controller that becomes the active machine creates an IP alias for each virtual server that it manages. Normally, this process takes less than one second. However, if the BIG-IP Controller has 8,000 virtual servers, this process can take as long as 90 seconds. The active BIG-IP Controller is unresponsive during the time it creates the IP aliases, and it cannot begin processing connections until the IP aliasing is complete.

To ensure a fast fail-over process, and to help reduce the amount of ARP requests a router must make, you should run the BIG-IP Controller in bigip.vipnoarp mode. In bigip.vipnoarp mode, the BIG-IP Controller does not create IP aliases for virtual servers. Instead, network traffic bound for virtual servers configured on the BIG-IP Controller are routed using the BIG-IP Controller's external interface as a gateway. Configuring bigip.vipnoarp mode is a two-step process:

• On the router, you must configure a gateway route to the virtual servers using the BIG-IP Controller's external interface IP address.
• On the BIG-IP Controller itself, you must change the bigip.vipnoarp system control variable. Note that you can use either the Configuration utility, or the sysctl command, to change system control variables.

Note: You can enable the noarp option on a virtual server basis. For more information about enabling this option on an individual virtual server basis, see Specifying an interface for a virtual address, on page 2-13

Note: You can enable bigip.vipnoarp mode only if you have the ability to add a gateway route to your router. Note that in redundant systems, you need to use the shared external IP address as the gateway address for the virtual servers configured on the BIG-IP Controller.

Configuring the router

In the router configuration, you need to define a static route as the gateway for each virtual address managed by the BIG-IP Controller. The static route should set the gateway address to the IP address of the external interface on the BIG-IP Controller. For example, if the shared external address of a BIG-IP redundant system is 11.0.0.100, and all virtual servers configured on the BIG-IP redundant system use IP addresses 11.0.1.50 through 11.0.1.55, you need to configure the router to use 11.0.0.100 as a gateway to the 11.0.1.* subnet. Such a definition on a UNIX-like router would read:

  route add -net 11.0.1.0 gw 11.0.0.100 

Activating bigip.vipnoarp mode in Configuration utility

In the Configuration utility, the bigip.vipnoarp mode setting is under BIG-IP sysctl configuration. To turn this mode on, simply check the Disable IP Aliases on Virtual Servers box. To turn this mode off, clear the Disable IP Aliases on Virtual Servers box.

Warning: We recommend that you do not toggle this mode on or off while the virtual servers are defined. Resetting the variable at that time may result in system anomalies.

Activating bigip.vipnoarp mode on the command line

You can activate bigip.vipnoarp mode in one of two ways:

• You can edit the /etc/rc.sysctl file in a text editor, and then reboot the system.
• You can immediately enable or disable the mode using sysctl commands.

  If you choose to edit the /etc/rc.sysctl file, you simply need to add the following line to the file to activate vipnoarp mode:

  sysctl -w bigip.vipnoarp=1

To deactivate bigip.vipnoarp mode, you can either comment the line out, or delete it from the /etc/rc.sysctl file altogether. Once you edit the file, the changes do not take affect until you reboot the system.

To immediately activate bigip.vipnoarp mode, type the following on the command line:

  bigpipe -r

  sysctl -w bigip.vipnoarp=1

  bigpipe -f /etc/bigip.conf

To immediately deactivate bigip.vipnoarp mode, type the following on the command line:

  bigpipe -r

  sysctl -w bigip.vipnoarp=0

  bigpipe -f /etc/bigip.conf

Warning: We recommend that you do not toggle the bigip.vipnoarp mode on or off while the virtual servers are defined. Resetting the sysctl variable at that time may lead to a system crash.

Reducing the number of node pings and service checks issued by the BIG-IP Controller

The BIG-IP Controller checks node status at user-defined intervals in two different ways:

• The BIG-IP Controller can issue a node ping to all node addresses that it manages. If the BIG-IP Controller receives a response to a node ping from a specific node address, all nodes associated with that node address are marked up and available for connections. The node ping uses the ICMP protocol.
• The BIG-IP Controller can also perform a service check. For each node that uses service check, the BIG-IP Controller connects to the node and attempts to establish a connection with the service configured on the node port. If the BIG-IP Controller is able to establish a connection with the service, the BIG-IP Controller marks the node up. If the BIG-IP Controller cannot establish a connection with the service, the BIG-IP Controller marks the node down. It is important to note that the node is marked down, even if the node's address is able to respond to the BIG-IP Controller's simple node ping.

  If a BIG-IP Controller's configuration includes thousands of nodes, the node pings and service checks begin to take up more resources on both the BIG-IP Controller and the servers than is preferred. You can significantly reduce the number of node pings and service checks in configurations that have a group of node addresses which are all IP aliases on the same server. For each group of node addresses that points to a given server, you can select one node address out of the group to represent all node addresses in the group. The representative node address is referred to as the node alias. When the BIG-IP Controller issues a node ping or service check, it sends the ping or performs the service check only on the node alias, rather than on all nodes in the group. If the BIG-IP Controller receives a valid response before the time-out expires, it marks all nodes associated with the node alias as up and available to receive connections. If the BIG-IP Controller does not receive a valid response before the time-out expires, it marks all of the nodes associated with the node alias as down.

An important note about service checks

You can set the BIG-IP Controller to use a node alias for nodes that are configured for service checks; however, there are some limitations to this implementation. Service checks are port-specific, unlike node pings which are merely sent to a node address. If you assign a node alias to a node that uses service check, the node alias must be configured to support the port number associated with the node. If the node alias is not configured properly, the BIG-IP Controller can not establish a conversation with the service that the specific node supports, and the service check is invalid.

Note: If you have configured different ports on each node to handle a specific Internet service and you want to use IP aliases, you can use BIG/pipe commands to work around the situation. Refer to the BIG-IP Controller Reference Guide, BIG/pipe Command Reference for more information about the bigpipe alias command.

Setting up node aliases in the Configuration utility

In the Configuration utility, each node address has a set of properties associated with it, including the Node Alias property. Note that before you define a node alias for a specific node address, you may want to check the properties for each node that uses the node alias. The node alias must support each port used by a node that is configured for service check, otherwise the service check results are invalid.

1. In the navigation pane, click Nodes.
   The Virtual Servers screen opens.
2. In the Node Properties table, select the node address.
   The Node Address Properties page opens.
3. In the Node Alias box, type the node alias.
4. Click the Apply button.

Setting up node aliases using the BIG/pipe command line utility

The BIG/pipe command line utility allows you to set node aliases for multiple nodes at one time. With the bigpipe alias command, you can do three things:

• View all node aliases defined in the current configuration
• View the node alias associated with a specific node address
• Define a node alias for one or more node addresses

  For details about working with the bigpipe alias command, refer to the BIG-IP Controller Reference Guide, BIG/pipe Command Reference.

Using the versatile interface configuration options

The versatile interfaces option adds more flexibility for configuring interfaces. You can now change both the source address or destination address and/or route of an IP packet.

In previous versions of the BIG-IP Controller, interfaces were designated as internal or external. With this version of the BIG-IP Controller you can configure specific interface properties based on the properties in Table 2.2.

The properties for internal and external interfaces

Interface type	Interface properties
Internal	Processes source addresses Administrative ports open
External	Processes destination addresses Administrative ports locked down

The ability to change the source or destination can be turned on independently. Essentially, this means you can configure an interface so that it handles traffic going to virtual servers and, independently, you can configure the interface to handle traffic coming in from nodes. You can configure virtual servers and nodes on each interface installed on the BIG-IP Controller. This allows for the most flexible processing of packets by the BIG-IP Controller. When either the source or destination processing feature is turned off on an interface, there is a gain in performance.

When you enable destination processing on a BIG-IP Controller interface, the interface functions in the following manner:

• When the destination address on the packet is a virtual server, then the interface routes the packet to the Node that is handling the connection that the packet is a part of, picking one if necessary, and depending on how the virtual server is configured, the interface translates the destination address to the node address.
• When the destination address on the packet is the external address of a NAT, then the interface translates the destination address to the internal address of the NAT.
• When the destination address on the packet is the external address of a SNAT, then the interface translates the destination address to the internal address from which the SNAT connection originated.

  When you enable source processing on a BIG-IP Controller interface, the interface functions in the following manner:

• When the source address on the packet is a node, and the packets are destined to a client for whom there is an existing connection, and depending on how the virtual server is configured, the interface translates the source address to the address of the virtual server.
• When the source address on the packet is the internal address of a NAT, then the interface translates the source address to the external address of the NAT.
• When the source address on the packet is the internal address of a SNAT, then the interface translates the source address to the external address of the SNAT.

  You can turn on both source and destination processing for an interface. This is possible because their functions do not overlap. For example, a NAT changes the source address on packets coming from clients so that they look like they have a different IP address, and virtual servers change the destination address to load balance the destination. There is no reason why you cannot do both the NAT translation and the virtual server translation. There are some combinations of virtual server and NAT source processing and virtual server and NAT destination processing that do not make sense. For example, if a virtual server processes a packet during source processing, the packet is not handled by virtual server destination processing. Also, if a virtual server processes a packet during destination processing, the packet is not handled by virtual server source processing.

Destination route and translation processing

When destination processing is enabled on an interface, the BIG-IP Controller processes packets arriving at the interface when those packets are addressed to a virtual server, SNAT, or NAT external address.

It is useful to note that there are two independent activities associated with destination processing: routing and translation. For example, wildcard virtual servers load balance connections across transparent network devices (such as a router or firewall), but they do not perform translation. In fact, translation can be turned off for all virtual servers (see Configuring transparent virtual servers, on page 2-30). Also, with the new forwarding virtual servers, neither next hop load balancing nor translation will occur for connections. These virtual servers only forward packets and so connections can pass through BIG-IP Controller without being manipulated in any way.

When you plan which type of processing to use in the BIG-IP Controller configuration, consider these questions:

• What traffic is translated?
• When those packets reach the BIG-IP Controller interface, does the source IP address, or destination IP address need to be translated?
• Which connections are load balanced across multiple devices?

  These questions help identify what kind of processing is required for the network interfaces on the BIG-IP Controller.

Source translation processing

When source translation processing is enabled on an interface, then the BIG-IP Controller processes packets arriving at the interface when those packets are coming from a node, SNAT, or NAT internal address. In this situation, the interface rewrites the source address of the IP packet, changing it from the real server's IP address, or internal NAT address, to the virtual server or external NAT address, respectively. Also, when the new last hop feature is enabled on a virtual server (see Using per-connection routing, on page 2-27), the packet is routed back to the network device that first transmitted the connection request to the virtual server.

To configure source and destination processing in the Configuration utility

1. In the navigation pane, click NICs.
   The Network Interface Cards screen opens. You can view the current settings for each interface in the Network Interface Card table.
2. In the Network Interface Card table, click the name of the interface you want to configure.
   The Network Interface Card Properties screen opens.

   · To enable source processing for this interface, click the Enable Source Processing check box.

   · To enable destination processing for this interface, click the Enable Destination Processing check box.

3. Click the Apply button.

To configure source and destination processing from the command line

Use the following syntax to configure source and destination processing on the specified interface:

  bigpipe interface <interface> dest [ enable | 
disable ]

  bigpipe interface <interface> source [ enable | 
disable ] 

The following example command enables destination processing on the interface exp0:

  bigpipe interface exp0 dest enable

The following example command enables source processing on the interface exp1:

  bigpipe interface exp1 source enable

Interface security

You can use the adminport option to control the security on an interface. The lockdown keyword configures the port lockdown used in previous versions of the BIG-IP Controller on the specified interface. If you use this option when you configure an interface, only ports essential to the configuration and operation of BIG-IP Controller and 3DNS Controller are opened. The open keyword allows all connections to and from BIG-IP Controller through the interface you specify.

To configure interface security in the Configuration utility

1. In the navigation pane, click NICs.
   The Network Interface Cards screen opens. You can view the current settings for each interface in the Network Interface Card table.
2. In the Network Interface Card table, click the name of the interface you want to configure.
   The Network Interface Card Properties screen opens.
3. To set the administration properties, click the Enable Admin list. Choose one of the following options:

   · Lockdown
   Choose this option to lock down all ports except the ports used for administrative access on this interface.

   · Open
   Choose this option to open allow connections to all ports on this interface.

   Click the Apply button.

To configure interface security from the command line

Use the following syntax to configure interface security on the specified interface:

  bigpipe interface <interface> adminport lockdown

  bigpipe interface <interface> adminport open

Use the following example command to lock down connections to all ports except the administration ports on exp0:

  bigpipe interface exp0 adminport lockdown

Use the following example command to allow connections to all ports on exp1:

  bigpipe interface exp1 adminport open

Using advanced virtual server options

You can use the BIG-IP Controller virtual server options in combinations that match the hardware and load balancing needs of your network. This section describes how advanced virtual server configurations including:

• Using per-connection routing
• Configuring forwarding virtual servers
• Configuring transparent virtual servers
• Using virtual server port translation
• Resetting connections when a service is down

Using per-connection routing

In situations where the BIG-IP Controller accepts connections for virtual servers from more than one router or firewall, you can send the return data back through the same device from which the connection originated. You can use this option to spread the load among outbound routers or firewalls, or to ensure that connections go through the same device if that device is connection-oriented, such as a proxy, cache, or VPN router.

The device from which a connection originated is sometimes referred to as the last hop to the BIG-IP Controller. You can configure the BIG-IP Controller to send packets back to the device from which the connection originated when that device is part of a last hop pool of devices associated with a virtual server.

To set up per-connection routing, you must first set up a last hop pool. A last hop pool defines the list of routers as a pool from which the BIG-IP Controller receives packets. For detailed information about setting up a pool, see Chapter 3, Working with Intelligent Traffic Control.

The BIG-IP Controller determines the MAC address of the routers when the pool is defined. Then the pool is associated with the virtual server by using the lasthop keyword to specify the last hop pool for the virtual server. Then, when a packet arrives for the virtual server, the MAC address that the packet came from is matched up with the MAC address of the members of the last hop pool. The IP address of the matching member is stored with the connection as the last hop address. Then, connections coming from nodes and heading out towards the client are sent to the last hop address, instead of to the default route.

To configure last hop pools for virtual servers in the Configuration utility

Before you follow this procedure, you must configure at least one pool (for your routers) and one 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 set up a last hop pool.
   The properties screen for the virtual server you clicked opens.
3. Click the Last Hop Pool list. Select the pool you created containing your routers.
4. Click the Apply button.

To configure last hop pools for virtual servers from the command line

Use the following syntax to configure last hop pools for virtual servers:

  bigpipe vip <vip>:<port> lasthop pool <pool_name>

For example, you might use the following command:

  bigpipe vip 192.168.1.10:80 lasthop pool 
secure_routers

Configuring 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 in the Configuration utility

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the toolbar, click the Add Virtual Server button.
   The add virtual server screen opens.
   Type in the virtual server attributes including address and port. Use the IP address/port combination guidelines in the previous section, To configure a forwarding virtual server from the command line, to determine what these entries should be.
3. In Resources, click the Forwarding button.
4. Click the Apply button.

To configure a forwarding virtual server from the command line

Use the following syntax to configure forwarding virtual servers:

  bigpipe vip <vip>:<port> [ netmask <netmask> ] forward

For example, to allow only one service in:

  bigpipe vip 206.32.11.6:80 forward

Use the following command to allow only one server in:

  bigpipe vip 206.32.11.5:0 forward

To forward all traffic:

  bigpipe vip 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 Controller to load balance connections across transparent devices. Another wildcard virtual server is required on the other side of the BIG-IP Controller to forward packets to virtual servers receiving connections from the transparent devices and forward them to their destination. You can use another new feature, the transparent device persistence, with forwarding virtual servers, to route connections back through the device from which the connection originated. For more information about per-connection routing, see Using per-connection routing, on page 2-27. In these configurations, there you would 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. For an example of these configuration settings in a network, see VPN load balancing, on page 9-12.

Configuring transparent virtual servers

A new option for virtual servers adds the ability to control whether address translation is enabled for a virtual. By default, wildcard virtual servers have translation turned off. A new translate keyword allows you to turn off address translation for non-wildcard virtual servers. This option is useful when the BIG-IP Controller 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.

To configure address translation for virtual servers in the Configuration utility

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 set up a transparent virtual server.
   The properties screen for the virtual server you clicked opens.
3. In the Enable Translation options, clear the Address check box. This turns off address translation for the virtual server.
4. Click the Apply button.

To configure address translation for virtual servers from the command line

Use the following syntax to configure address translation for virtual servers:

  bigpipe vip <vip>:<port> translate addr [ enable | disable ]

For example, use the following syntax to configure address translation for a virtual server 209.43.224.213:80:

  bigpipe vip 209.43.224.213:80 translate addr disable

Using virtual server port translation

A new option for virtual servers adds the ability to control whether port translation is enabled for a virtual server except for wildcard virtual servers. Port translation is turned on by default. An exception to this is if the port defined for a member is port zero. Members with a zero port cannot do translation because zero is not a valid port.

To configure virtual server port translation in the Configuration utility

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 set up a transparent virtual server.
   The properties screen for the virtual server you clicked opens.
3. In the Enable Translation options, clear the Port check box. This turns off port translation for the virtual server.
4. Click the Apply button.

To configure virtual server port translation from the command line

Use the following syntax to configure virtual server port translation:

  bigpipe vip <vip>:<port> translate port [ enable | 
disable ]

For example, if you want to disable port translation for the virtual server/port combination 209.43.224.213:0, type the following command:

  bigpipe vip 209.43.224.213:0 translate port 
disable

Resetting connections on service down

A new option for virtual servers provides the ability to reset connections if a service is down. When this attribute is enabled for a virtual server, the BIG-IP Controller sends resets to the end points of TCP connections when it is determined that the service they are using has gone down.

This is currently only enabled for service checks that mark a node down. Node pings that time out do not cause resets to be sent.

Only TCP connections can receive a Reset. UDP connections are not aborted because there is no shutdown mechanism for UDP connections.

To reset connections on service down in the Configuration utility

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 reset connections if the service is down.
   The properties screen for the virtual server you clicked opens.
3. Click the Enable Reset on Service Down check box. To disable this feature, clear the Enable Reset on Service Down check box.
4. Click the Apply button.

To configure reset connections on service down from the command line

Use the following syntax to reset connections when a service is down:

  bigpipe vip <vip:port> svcdown_reset [enable | 
disable] 

Configuring RADIUS authentication

You can configure the BIG-IP Controller to use a RADIUS server on your network to authenticate users attempting to access the controller with SSH. This allows you to use the RADIUS server as a central repository of users that can access the BIG-IP Controller for administrative purposes.

To do this, configure the BIG-IP Controller to act as a Network Access Server (NAS) for a RADIUS server in your network. When you set up this feature, client connections received by the BIG-IP Controller for users not listed in the local account database server are routed to the RADIUS server to be authenticated. If the user is authenticated, the user is logged in as the BIG-IP Controller user that you specify.

Note: RADIUS authentication through the BIG-IP Controller is based on the username/password only. Challenge-response authentication methods are not supported.

You can configure the BIG-IP Controller to use either version 1.3.7 or version 2.0.12.1, or both, of the sshd for SSH authentication.

Note: If you want to support only SSH version 1.x clients, configure sshd version 1.3.7. Do not configure sshd version 2.0.12.1. However, if you want to support version 1.x and version 2.x clients, configure sshd version 2.0.12.1.

RADIUS ports on the BIG-IP Controller

The BIG-IP Controller uses the ports 1645/udp for communicating with the RADIUS server. If your RADIUS server uses different ports, such as 1812/udp, you must change the ports used by the BIG-IP Controller to these ports. To do this, use a text editor such as vi or pico to change the existing RADIUS port entry in the /etc/services file on each BIG-IP Controller:

Figure 2.1 Alternative ports on the BIG-IP Controller for the RADIUS server

 radius          1812/tcp                      # Radius            
  radacct         1813/udp                      # Radius Accounting 

Configuring sshd version 1.3.7

You can configure version 1.3.7 of the sshd by editing the /etc/sshd_config on the BIG-IP Controller with pico or vi. The following entries must be in the sshd_config file:

• RadiusServer
  This entry is the host name or IP address of the RADIUS server.
• RadiusKey
  This entry is the shared secret key of the RADIUS server. This key should be at least 16 characters long.
• RadiusNasIP
  This is the host name or IP address of the interface on the BIG-IP Controller connected to the network that hosts the RADIUS server. Note that you can only use interfaces set to admin port open for RADIUS authentication.
• RadiusUser
  This entry is the user name of the local BIG-IP Controller user, such as root. When the RADIUS user is authenticated, the user is logged into the controller as this user.

Note: The most secure method for using RADIUS with the BIG-IP Controller is to create a RadiusUser entry that has a low level of priveledges. After you are authenticated and you log in to the BIG- IP Controller as the low priviledge user, use the su command to gain root priviledges.

Warning: For security reasons, we recommend that you use IP addresses instead of host names for the entries in this file. If you specify a host name for an entry, we recommend that you add the host name to the /etc/hosts file

For example, Figure 2.2 is an example of the entries you might make in the sshd_config file on the BIG-IP Controller:

Figure 2.2 Example entries from the sshd_config file

 RadiusServer 12.34.56.78 
  RadiusKey    my_radius_server.key 
  RadiusNasIP  172.16.42.200 
  RadiusUser   radius_user 

Configuring sshd version 2.0.12.1

You can configure version 2.0.12.1 of the sshd by editing the /etc/ssh2/sshd2_config on the BIG-IP Controller with pico or vi. The following entries must be in the sshd2_config file:

• RadiusServer
  This entry is the host name or IP address of the RADIUS server.
• RadiusKey
  This entry is the shared secret key of the RADIUS server. This key should be at least 16 characters long.
• RadiusNasIP
  This is the host name or IP address of the interface on the BIG-IP Controller connected to the network that hosts the RADIUS server. Note that you can only use interfaces set to admin port open for RADIUS authentication.
• RadiusUser
  This entry is the user name of the local BIG-IP Controller user, such as root. When the RADIUS user is authenticated, the user is logged into the controller as this user.

Note: The most secure method for using RADIUS with the BIG-IP Controller is to create a RadiusUser entry that has a low level of priveledges. After you are authenticated and you log in to the
BIG-IP Controller as the low priviledge user, use the su command to gain root priviledges.

To support SSH version 1.x clients, you must add the following entries to the /etc/ssh2/sshd2_config file.

• Ssh1Compatibility
  This paramter must be set to yes.
• Sshd1Path
  This entry is the path to sshd version 1. In this case, the path is /usr/local/sbin/sshd1.

  For example, Figure 2.2 is an example of the entries you might make in the sshd2_config file on the BIG-IP Controller:

  Figure 2.3 Example entries from the sshd2_config file

   RadiusServer 12.34.56.78 
    RadiusKey    my_radius_server.key 
    RadiusNasIP  172.16.42.200 
    RadiusUser   radius_user 
  
    Sshd1Compatibility yes 
    Sshd1Path /usr/local/bin/sshd1