Applies To:
Show VersionsBIG-IP versions 1.x - 4.x
- 4.6.4, 4.6.3, 4.6.2
6
Virtual Servers
- Introducing virtual servers
- Virtual server types
- Virtual server options
- Using other BIG-IP system features
Introducing 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 associated pools.)
Before creating a virtual server, you must configure a load balancing pool. You can then create the virtual server, specifying that pool as the destination for any traffic coming from that virtual server. Furthermore, if you want some of the traffic from that virtual server to go to a pool other than the one specified, you can create a rule that directs certain types of traffic to that other pool.
In order to configure virtual servers, you need to know:
- Which virtual server type meets your needs
- Whether you need to enable certain virtual server options
Once you know which virtual server options are useful in your network, you can define any one of the four types of virtual servers.
Virtual server types
You can configure various types of virtual servers, depending on your needs. Table 6.1 shows the types of virtual servers that you can create.
Virtual Server Type |
Description |
---|---|
Standard virtual server |
A standard virtual server is a virtual server with a full IP address. For example: 192.168.200.30:http |
Wildcard virtual server |
There are two types of wildcard servers: A port-specific wildcard virtual server is a virtual server with a port specified. A port-specific wildcard virtual server is used to accept all traffic for a specific service. A default wildcard virtual server is a wildcard virtual server with the service 0, *, or any. A default wildcard server acts like a default router, accepting all traffic that does not match a standard, network, or port-specific wildcard server. |
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 |
Forwarding virtual server |
A forwarding virtual server is a virtual server without a pool that simply forwards traffic to the destination node. |
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.
If you are using a 3-DNS Controller in conjunction with the BIG-IP system, 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
- In the navigation pane, click Virtual Servers.
- Click the Add button.
The Add Virtual Server screen opens. - In the Address box, type the virtual server's IP address or host name.
- In the Port box, either type a port number or select a service name from the list.
- 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. - In the Pool list, select the pool you want to apply to the virtual server.
- Click the Apply button.
To define a standard virtual server 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>
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
If a virtual server is to have the the same IP address as a node in an associated VLAN, you must perform some additional configuration tasks. These tasks consist of: creating a VLAN group that includes the VLAN in which the node resides, assigning self-IP addresses to the VLAN group, and disabling the virtual server on the relevant VLAN. For information on creating VLAN groups and assigning self IP addresses to them, see Chapter 3, Post-Setup Tasks . For information on disabling a virtual server for a specific VLAN, see Enabling or disabling a virtual server .
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 system. 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 system receives a connection request for that site, the BIG-IP system 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 system 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 system. For example, when the BIG-IP system does not find a specific virtual server match for a client's destination IP address, it matches the client's destination IP address to a wildcard virtual server. The BIG-IP system 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.
Default vs. port-specific wildcard servers
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.
A wildcard virtual server is enabled for all VLANs by default. However, you can specifically disable any VLANs that you do not want the default wildcard virtual server to support. Disabling VLANs for the default wildcard virtual server is done by creating a VLAN disabled list. Note that a VLAN disabled list applies to default wildcard virtual servers only. You cannot create a VLAN disabled list for a wildcard virtual server that is associated with one VLAN only.
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.
For the procedure to create a default wildcard server, see To create a default wildcard virtual server using the Configuration utility .
Creating wildcard virtual servers
Creating a wildcard virtual server requires two tasks. First, you must create a pool that contains the addresses of the transparent devices. Then, you must create the wildcard virtual server. The following procedures describe these tasks, using both the Configuration utility and the command line.
To create a pool of transparent devices using the Configuration utility
To create a pool of transparent devices, use the Add Pool wizard, available from the Pools screen. For more information, see Chapter 4, Pools .
To create a wildcard virtual server using the Configuration utility
- In the navigation pane, click Virtual Servers.
- Click the Add button.
The Add Virtual Server screen opens. - In the Address box, type the wildcard IP address 0.0.0.0.
- In the Port box, type a port number, or select a service name from the 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 handles traffic only for the port specified. For more information, see Default vs. port-specific wildcard servers .
- In Resources, click the Pool button.
- In the Pool list, select the pool you want to apply to the virtual server.
- Click the Apply button.
To create a wildcard virtual server from the command line
- Create the pool of transparent devices, using 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 10.10.10.101:80 member 10.10.10.102:80 member 10.10.10.103:80 }
- 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. For example:
b virtual 0.0.0.0:0 use pool transparent_pool
When you create a wildcard virtual server, you should retain the default setting for port translation (disable).
To create a default wildcard virtual server using the Configuration utility
- In the navigation pane, click Virtual Servers.
The Virtual Servers screen displays. - Click the Add button.
- In the Address field, type the IP address 0.0.0.0.
- Click Next.
- From the VLAN box, select all.
- Click Done.
To create a default wildcard virtual server from the command line
To create a default wildcard virtual server from the command line, use the bigpipe virtual command with the following syntax:
b virtual *:* use pool <pool_name>
Creating multiple wildcard servers
You can define multiple wildcard virtual servers that run simultaneously. Each wildcard virtual server must be assigned to an individual VLAN, and therefore can handle packets for that VLAN only.
To create multiple wildcard virtual servers, you can use either the Configuration utility or the bigpipe virtual command.
To create multiple wildcard virtual servers using the Configuration utility
- In the navigation pane, click Virtual Servers.
The Virtual Servers screen displays. - Click the Add button.
- In the Address field, type the IP address 0.0.0.0.
- In the Service field, type the name of a service or select a service from the list box.
- Click Next.
- From the VLAN box, choose a VLAN name. Selecting all creates a default wildcard virtual server.
- Click Next.
- Continue configuring all properties for the wildcard virtual server. Note that on the Configure Basic Properties screen, if you are creating a default wildcard virtual server, you can disable any VLANs associated with that wildcard virtual server.
- Click Done.
Repeat for each wildcard virtual server that you want to create.
To create multiple wildcard virtual servers from the command line
To create a separate wildcard virtual server per VLAN from the command line, use the following command-line syntax:
b virtual <vlan_name> use pool <pool_name>
For example, the following commands define two wildcard virtual servers, the first for VLAN internal, and the second for VLAN external:
b virtual internal use pool my_pool
b virtual external use pool my_pool
Network virtual servers
You can configure a network virtual server to handle a whole network range, instead of just one IP address, or all IP addresses (a wildcard virtual server). For example, the virtual server in Figure 6.1 handles all traffic addresses in the 192.168.1.0 network.
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 system 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, shown in Figure 6.2 .
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.
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
- In the navigation pane, click Virtual Servers.
The Virtual Servers screen opens. - Click the Add button.
The Add Virtual Server screen opens. - Type the virtual server attributes, including the address and port number.
- Under Configure Basic Properties, clear the Enable Arp check box.
- On the Select Physical Resources screen, click the Forwarding button.
- 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> [netmask <ipmask>] 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
In some of the configurations described here, you need to set up a wildcard virtual server on one side of the BIG-IP system to load balance connections across transparent devices. You can create another wildcard virtual server on the other side of the BIG-IP system to forward packets to virtual servers receiving connections from the transparent devices and forwarding them to their destination.
If you do not want the BIG-IP system to load balance your traffic but do want to take advantage of certain pool attributes, you can instead use a feature called a forwarding pool. For more information on forwarding pools, see Chapter 4, Pools .
If a forwarding virtual server is to have the the same IP address as a node in an associated VLAN, you must perform some additional configuration tasks. These tasks consist of: creating a VLAN group that includes the VLAN in which the node resides, assigning self-IP addresses to the VLAN group, and disabling the virtual server on the relevant VLAN. For information on creating VLAN groups and assigning self IP addresses to them, see Chapter 3, Post-Setup Tasks . For information on disabling a virtual server for a specific VLAN, see Enabling or disabling a virtual server .
Virtual server options
For each type of virtual server, you can configure several options. These options are shown in Table 6.2 .
Option |
Description |
---|---|
Display virtual server information |
Using the bigpipe virtual show command, you can display information about one or more virtual servers. |
Enable/disable a virtual server |
By default, a virtual server is enabled. If you want to disable a virtual server, you can do so. |
Enable/disable a virtual address |
By default, a virtual address is enabled. If you want to disable a virtual address, you can do so. |
*Override netmask and broadcast |
*You can override the default netmask and broadcast for a network virtual address. |
Enable/disable address and port translation |
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. |
Reset connections when service is down |
You can cause the BIG-IP system to immediately reap all connections for a node that transitions to a down state. When this attribute is disabled (the default setting), the BIG-IP system allows currently-active connections to proceed. Note that currently-active connections are those that are shown in the connection table, at the time that a node transitions to the down state, as being connected to that node. |
Enable/disable dynamic connection rebinding |
You can cause any connections that were made to a node address or service to be redirected to another node, if the original node transitions to a down state. |
Disable ARP requests |
You can control gratuitous ARPs and ARP requests. |
Enable/disable TCP Resets on timeout |
When you enable this option, the virtual server sends a TCP Reset when a TCP connection is timed out. The default setting for this option is Enabled. |
Set FastFlow packet acceleration |
You can speed up packet flow for TCP connections when the packets are not fragmented. |
Set a connection limit |
You can set a concurrent connection limit on one or more virtual servers. |
Mirror state 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. |
Define a last hop pool |
You can direct reply traffic to the last hop router using a last hop pool. This overrides the auto_lasthop setting. |
Define resources |
You can configure a virtual server to use a pool or reference a rule. You can also specify that the virtual server is to function as a forwarding virtual server. |
Load balance traffic for any IP protocol |
You can configure a virtual server to load balance traffic that uses IP protocols other than TCP and UDP. For example, you can load balance IPSEC traffic from virtual private networks (VPNs). |
Delete a virtual server |
You can delete an existing virtual server. |
Reset virtual server statistics |
You can reset virtual server statistics. |
Alleviate SYN flooding |
You can configure a virtual server to alleviate SYN flooding with the SYN Check feature. |
Displaying information about virtual addresses
You can 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 system was last rebooted, or since the BIG-IP system became the active unit (redundant configurations only).
Enabling or disabling 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. As an option, you can enable or disable a virtual server for a specific VLAN only.
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 to a down state.
To disable or enable a virtual server using the Configuration utility
- In the navigation pane, click Virtual Servers.
The list of virtual servers displays. - Click on the virtual server that you want to disable or enable.
This displays the properties for that virtual server. - If you want to disable the virtual server for all VLANs, clear the Enabled check box. If you want to disable the virtual server for a specific VLAN, locate the VLANs Disabled box and move the relevant VLAN name from the Existing list to the Disabled list, using the arrows (>>).
- If you want to enable the virtual server for all VLANs, click the Enabled check box (if not already checked). If you want to enable the virtual server for a specific VLAN, locate the VLANs Disabled box and move the relevant VLAN name from the Disabled list to the Existing list, using the arrows (>>).
- Click Done.
If the Enabled check box is checked and no VLANs are listed in the Disabled list of the VLANs Disabled box, the virtual server is enabled for all VLANs. If the Enabled check box is not checked, the virtual server is disabled for all VLANs.
To disable or enable a virtual server from the command line
Use the following syntax to disable a virtual server from network service:
b virtual <virt_ip>:<service> [...<virt_ip>:<service>] disable
If you want to disable or enable a virtual server for one or more specific VLANs only, use the following syntax:
b virtual <virt_ip>:<service> vlans <vlan_list> disable | enable
Use the following syntax to return a virtual server to network service:
b virtual <virt_ip>:<service> enable
If you do not specify a VLAN name with the b virtual command, the virtual server is enabled or disabled on all VLANs.
Enabling or disabling 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
Setting 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 system, 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.
To set a custom netmask and broadcast
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>
The BIG-IP system 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.
Setting 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.
You can also configure the translation properties for a virtual server address. This option is useful when the BIG-IP system is load balancing devices that 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 enable or disable port translation
Use the following syntax to enable or disable port translation for a virtual server:
b virtual <virt_ip>:<service> translate port enable | disable | show
To enable or disable address translation
Use the following syntax to enable or disable address translation for a virtual server:
b virtual <virt_ip>:<service> translate addr enable | disable | show
Resetting connections when a service is down
Using either the Configuration utility or the bigpipe virtual command, you can configure the BIG-IP system to immediately reap all connections for a node that transitions to a down state. When this option is disabled (the default setting), the BIG-IP system allows all currently-active connections to proceed.
To reset connections using the Configuration utility
- In the navigation pane, click Virtual Servers.
- In the list of virtual servers, click a virtual server name.
- Click the Virtual Server Properties tab.
- Click the Enable Reset on Service Down check box.
- Click the Apply button.
To reset connections from the command line
Use the following command-line syntax:
b virtual <ip address>:<service> svc_down reset enable
Setting dynamic connection rebinding
Dynamic connection rebinding is a feature for those virtual servers that are load balancing transparent devices such as firewalls or routers. Dynamic connection rebinding causes any connections that were made to a node address or service to be redirected to another node, if the original node transitions to a down state. In this case, all connections to the failed node that were made through the virtual server are moved to a newly-selected node from the virtual server's pool. The new node is selected using the pool's load-balancing algorithm. By default, dynamic connection rebinding is disabled.
This feature does not apply to virtual servers for non-transparent devices because they usually involve application state between the client and server node. This state cannot be recreated with a newly-selected node.
To enable, disable, or show the status of dynamic connection rebinding, you can use either the Configuration utility or the bigpipe virtual command.
To set dynamic connection rebinding using the Configuration utility >
- In the navigation pane, click Virtual Servers.
The Virtual Servers screen opens. - Select the IP address for the virtual server.
This displays the Properties page for that server. - Check the Enable Connection Rebind check box.
- Click the Apply button.
To set dynamic connection rebinding from the command line
To manage dynamic connection rebinding using the bigpipe virtual command, type one of the following commands.
b virtual <ip>:<service> conn rebind enable
b virtual <ip>:<service> conn rebind disable
b virtual <ip>:<service> conn rebind show
Disabling ARP requests
By default, the BIG-IP system responds to ARP requests for the virtual server address and sends a gratuitous ARP request for router table updates.
To disable ARP requests using the Configuration utility
- In the navigation pane, click Virtual Servers.
The list of virtual servers displays. - Click on the virtual server that you want to disable or enable.
This displays the properties for that virtual server. - Clear the Enable ARP check box.
- Click the Apply button.
To disable ARP requests from the command line
To disable ARP requests from the command line, use the following command-line syntax:
b virtual <ip address>:<service> arp disable
Disabling software acceleration 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 enabled by default by giving the global variable fastflow_active a default value of auto. The variable 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
Setting a connection limit
The default setting is to have no limit to the number of concurrent connections allowed on a virtual server.
To set a concurrent connection limit
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 off the connection limit
To turn off the connection limit, set the <max conn> variable to zero:
b virtual <virt_ip>[:<service>] [...<virt_ip>[:<service>] ] limit 0
Mirroring virtual server state
Mirroring provides seamless recovery for current connections when a BIG-IP system 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.
Mirroring slows BIG-IP system performance and is primarily useful for long-lived services like FTP and Telnet. Mirroring is not as useful for short-lived connections like HTTP.
Since mirroring is not intended to be used for all connections, it must be specifically enabled for each virtual server.
Connection mirroring is not supported on virtual servers that are the targets of an SSL or Akamaizer Proxy.
To control mirroring for a virtual server
Use the bigpipe virtual mirror command to enable or disable mirroring of connections. The syntax of the command is:
b virtual <virt addr>:<service> mirror conn enable | disable
To display 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 conn show
If you do not specify conn for connection information, the BIG-IP system assumes that you want to display that information.
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
Setting up last hop pools for virtual servers
In cases where you have more than one router sending connections to a BIG-IP system, 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 takes 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
Referencing BIG-IP system resources
Once you have created a pool or a rule, you must configure the virtual server to reference the pool or rule. You can configure a virtual server to reference a pool or rule by using either the Configuration utility or the bigpipe command.
To configure a virtual server that references a pool or rule using the Configuration utility
- In the navigation pane, click Virtual Servers.
The Virtual Servers screen opens. - Add the attributes you want for the virtual server such as address, port, unit ID, and interface.
- In the Resources section, click Pool or Rule.
- In the list of pools or rules, select the pool or rule you want to apply to the virtual server.
- 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 6.3 .
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 server options . |
<rule_name_reference> |
A rule name reference. Rule names are strings of 1 to 31 characters. use rule <rule_name> |
Load balancing traffic for any IP protocol
With the BIG-IP system, you can configure a virtual server to load balance IP traffic other than TCP and UDP traffic. This option can be configured on both translating and non-translating virtual servers.
One benefit of this feature is that you can load balance virtual private network (VPN) client connections across several VPNs, eliminating the possibility of a single point of failure. A typical use of this feature is for load balancing multiple VPN gateways in an IPSEC VPN sandwich, using non-translating virtual servers.
An important point to note, however, is that although address translation of such protocols can be optionally activated, some protocols, such as IPSEC in AH mode, rely on the IP headers remaining unchanged. In such cases, you should use non-translating network virtual servers.
By default, this feature is disabled on a virtual server.
To enable load balancing for any IP protocol using the Configuration utility
- In the navigation pane, click Virtual Servers.
- In the Virtual Server list, click the virtual server for which you want to enable any IP load balancing.
- Click the Virtual Address Properties tab.
- In the Any IP Traffic box, click the Enable check box.
- Click Apply.
To enable load balancing for any IP protocol from the command line
Use the any_ip option with the bigpipe virtual command, as shown in the following syntax:
b virtual <ip address:service> any_ip enable
Deleting 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
Resetting 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
Configuring SYN Check activation
To activate the SYN Check feature, you can configure two basic settings: a setting at the global level, and a setting for each virtual server. These values are the global variable syncookie_threshold and the virtual server attribute syncookie_threshold. The threshold numbers that you assign to the global variable and the virtual server attribute specify the number of concurrent connections that can be made to one or more virtual servers prior to the SYN Check feature being activated.
You can configure either a global threshold or a virtual server threshold, or both. When both the global and virtual server thresholds are defined, the lower threshold always takes precedence. Thus, if a virtual server's SYN Check threshold is set to 10,000, and the global threshold is set to 2,000, the BIG-IP system generates SYN cookies when 2,000 concurrent connections have been established.
Activating SYN Check based on a connection threshold
You can configure the BIG-IP system to activate the SYN Check feature when some threshold of connections has been reached on one or all virtual servers. To set the threshold on an individual virtual server, you use the bigpipe virtual command. To set the threshold on all virtual servers, you use the bigpipe global command.
The default global value for the SYN Check threshold is 150,000. For individual virtual servers, SYN Check thresholds are disabled by default.
For example, to set the SYN Check threshold on a global basis to 300,000 concurrent connections, you type the following command:
bigpipe global syncookie_threshold 300000
Running this command causes the BIG-IP system to activate SYN Check when the number of concurrent connections on all virtual servers exceeds 300,000.
To set the SYN Check threshold on an individual virtual server to 10,000 concurrent connections, you type the following command:
bigpipe virtual 10.1.2.3:80 syncookie_threshold 10000
Typing this command causes the BIG-IP system to activate SYN Check when the number of concurrent connections for that virtual server exceeds 10,000.
Activating SYN Check for all connections
Rather than activating SYN Check by defining a specific threshold of connections, you can configure the BIG-IP system to activate SYN Check for all connections, for an individual virtual server only.
You do this by setting the virtual server SYN Check threshold to 0. For example:
bigpipe virtual 10.1.2.3:80 syncookie_threshold 0
By setting the SYN Check threshold on virtual server 10.1.2.3:80 to 0, you effectively cause the BIG-IP system to always send SYN cookies after the very first connection is established.
While activating SYN Check for all concurrent connections seems to have its advantages, system performance is improved if you define a threshold other than 0. This is because when SYN Check is activated, the client, in response to the target system, is required to return the SYN cookie, incremented by 1, as the acknowledgement number in the ACK flag. This causes some latency that can be avoided if you set a threshold of connections that is considerably higher than 0.
Using other BIG-IP system features
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 (NATs) or extended content verification (ECV). For details on network address translations, see Chapter 10, Address Translation: SNATs, NATs, and IP Forwarding . For details on persistence for connections that should return to the node to which they last connected, see Chapter 4, Pools .