Virtual Servers

There are two distinct types of virtual servers that you can create: virtual servers that listen for a host destination address and virtual servers that listen for a network destination address. For both types of virtual servers, you can also specify a source IP address.

You can configure a virtual server so that the status of the virtual server contributes to the associated virtual address status. When disabled, the status of the virtual server does not contribute to the associated virtual address status. This status, in turn, affects the behavior of the system when you enable route advertisement of virtual addresses.

Not only do virtual servers distribute traffic across multiple servers, they also treat varying types of traffic differently, depending on your traffic-management needs. For example, a virtual server can enable compression on HTTP request data as it passes through the BIG-IP system, or decrypt and re-encrypt SSL connections and verify SSL certificates. For each type of traffic destined for a specific virtual server, the virtual server can apply an entire group of settings (known as a profile) to affect the way that the BIG-IP system manages that traffic type.

In addition to compression and SSL profiles, you can configure a virtual server to apply profiles such as TCP, UDP, SPDY, SIP, FTP, and many more.

When you configure a virtual server, you can specify one or more VLANs, tunnels, or both, using the VLAN and Tunnel Traffic and VLANs and Tunnels settings. Configuring this feature specifies the VLANs or tunnels from which the virtual server will accept traffic. In a common configuration, the VLANs and tunnels selected reside on the external network.

When the default route on the servers does not route responses back through the BIG-IP system, you can create a secure network address translation (SNAT). A secure network address translation (SNAT) ensures that server responses always return through the BIG-IP^® system. You can also use a SNAT to hide the source addresses of server-initiated requests from external devices.

For inbound connections from a client, a SNAT translates the source IP address within packets to a BIG-IP system IP address that you or the BIG-IP system defines. The destination node then uses that new source address as its destination address when responding to the request.

For outbound connections, SNATs ensure that the internal IP address of the server node remains hidden to an external host when the server initiates a connection to that host.

If you want the system to choose a SNAT translation address for you, you can select the Auto Map feature. If you prefer to define your own address, you can create a SNAT pool and assign it to the virtual server.

You can specify an existing static bandwidth control policy for the system to use to enforce a throughput policy for incoming network traffic. A static bandwidth control policy controls the aggregate rate for a group of applications or a network path. The bandwidth control policy enforces the total amount of bandwidth that can be used, specified as the maximum rate of the resource you are managing. The rate can be the total bandwidth of the BIG-IP^® device, or it might be a group of traffic flows.

When you create or modify a virtual server, you can assign one or more existing traffic classes to the virtual server. A traffic class allows you to classify traffic according to a set of criteria that you define, such as source and destination IP addresses. Traffic classes define not only classification criteria, but also a classification ID. Once you have defined the traffic class and assigned the class to a virtual server, the BIG-IP system associates the classification ID to each traffic flow. In this way, the BIG-IP system can regulate the flow of traffic based on that classification.

When attempting to match traffic flows to a traffic class, the BIG-IP system uses the most specific match possible.

A virtual server, pool member, or node can prevent an excessive number of connection requests, such as during a Denial of Service (DoS) attack or during a high-demand shopping event. To ensure the availability of a virtual server, pool member, or node, you can use the BIG-IP^® Local Traffic Manager™ to manage the total number of connections and the rate at which connections are made.

When you specify a connection limit, the system prevents the total number of concurrent connections to the virtual server, pool member, or node from exceeding the specified number.

When you specify a connection rate limit, the system controls the number of allowed new connections per second, thus providing a manageable increase in connections without compromising availability.

BIG-IP^® system redundancy includes the ability for a device to mirror connection and persistence information to another device, to prevent interruption in service during failover. The BIG-IP system mirrors connection and persistence data over TCP port 1028 with every packet or flow state update.

Connection mirroring operates at the traffic group level. That is, each device in a device group has a specific mirroring peer device for each traffic group. The mirroring peer device is the traffic group's next-active device.

For example, if device Bigip_A is active for traffic group traffic-group-1, and the next-active device for that traffic group is Bigip_C, then the traffic group on the active device mirrors its in-process connections to traffic-group-1 on Bigip_C.

If Bigip_A becomes unavailable and failover occurs, traffic-group-1 on Bigip_C becomes active and continues the processing of any current connections.

When you enable address translation on a virtual server, the BIG-IP system translates the destination address of the virtual server to the node address of a pool member. When you disable address translation, the system uses the virtual server destination address without translation. The default is enabled.

When you enable port translation on a virtual server, the BIG-IP system translates the port of the virtual server. When you disable port translation, the system uses the port without translation. 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. The default is enabled.

On a virtual server, you can specify whether the BIG-IP system preserves the source port of the connection. You can instruct the BIG-IP system to either preserve the source port in certain or all cases, or change the source port for all connections. The default behavior is to attempt to preserve the source port but use a different port if the source port from a particular SNAT is already in use.

Alternatively, you can instruct the system to always preserve the source port. In this case, if the port is in use, the system does not process the connection. F5 Networks recommends that you restrict use of this setting to cases that meet at least one of the following conditions:

• The port is configured for UDP traffic.
• The system is configured for nPath routing or is running in transparent mode (that is, there is no translation of any other Layer 3 or Layer 4 field).
• There is a one-to-one relationship between virtual IP addresses and node addresses, or clustered multi-processing (CMP) is disabled.

Instructing the system to change instead of preserve the source port of the connection is useful for obfuscating internal network addresses.

You use a clone pool when you want to configure the BIG-IP system to send traffic to a pool of intrusion detection systems (IDSs). An intrusion detection system (IDS) is a device that monitors inbound and outbound network traffic and identifies suspicious patterns that might indicate malicious activities or a network attack. You can use the clone pool feature of a BIG-IP system to copy traffic to a dedicated IDS or a sniffer device.

To configure a clone pool, you first create the clone pool of IDS or sniffer devices and then assign the clone pool to a virtual server. The clone pool feature is the recommended method for copying production traffic to IDS systems or sniffer devices. Note that when you create the clone pool, the service port that you assign to each node is irrelevant; you can choose any service port. Also, when you add a clone pool to a virtual server, the system copies only new connections; existing connections are not copied.

You can configure a virtual server to copy client-side traffic, server-side traffic, or both:

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

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

When you enable the Auto Last Hop setting, the BIG-IP system can send any return traffic to the MAC address that transmitted the request, even if the routing table points to a different network or interface. As a result, the system can send return traffic to clients even when there is no matching route, such as when the system does not have a default route configured and the client is located on a remote network.

This setting is also useful when the system is load balancing transparent devices that do not modify the source IP address of the packet. Without the Auto Last Hop setting enabled, the system could return connections to a different transparent node, resulting in asymmetric routing.

You can configure this setting globally and on an object level. You set the global Auto Last Hop value on the System >> Configuration >> Local Traffic >> General screen. In this case, users typically retain the default setting, Enabled. When you configure Auto Last Hop at the object level with a value other than Default, the value you configure takes precedence over the global setting. This enables you to configure Auto Last Hop on a per-pool member basis. The default value for the virtual server Auto Last Hop setting is Default, which causes the system to use the global Auto Last Hop setting to send back the request.

You can instruct the BIG-IP system to allow IPv6 hosts to communicate with IPv4 servers. This setting is disabled by default.

When you create a virtual server, one of the resources that you can specify for a virtual server to use is a default server pool that you want to serve as the destination for any traffic coming from that virtual server. The system uses this pool, unless you have specified a different pool in another configuration object such as an iRule.

You can also assign other resources to a virtual server, such as iRules, policies, and persistence profiles.

You can enable an Auto Delete setting on a virtual address so that BIG-IP system automatically deletes the virtual address last associated virtual server is deleted. If you disable this setting, the system retains the virtual address, even when all associated virtual servers have been deleted. The default value is enabled.

If you want the virtual address to be a floating IP address, that is, an address shared between two or more BIG-IP devices in a device group, you can assign a floating traffic group to the virtual address. A floating traffic group causes the virtual address to become a floating self IP address. A floating virtual address ensures that application traffic reaches its destination when the relevant BIG-IP device becomes unavailable.

If you want the virtual address to be a static (non-floating) IP address (used mostly for standalone devices), you can assign a non-floating traffic group to the virtual address. A non-floating traffic group causes the virtual address to become a non-floating self IP address.

You can enable route advertisement for a specific virtual address. When you enable route advertisement, the BIG-IP system advertises routes to the virtual address for the purpose of dynamic routing. The system can advertise a route to the virtual address under any one of these conditions:

• When any virtual server is available. Additionally, when the ICMP Echo setting is set to Selective, the BIG-IP system sends an ICMP echo response for a request sent to the virtual address, if one or more virtual severs associated with the virtual address is in an Up or Unknown state.
• When all virtual servers are available. Additionally, when the ICMP Echo setting is set to Selective, the BIG-IP system always sends an ICMP echo response for a request sent to the virtual address, but only when all virtual servers are available.
• Always advertises the route regardless of the virtual servers available. Additionally, when the ICMP Echo setting is set to Selective, the BIG-IP system always sends an ICMP echo response for a request sent to the virtual address, regardless of the state of any virtual servers associated with the virtual address.

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

You can control whether the BIG-IP system sends responses to Internet Control Message Protocol (ICMP) echo requests, on a per-virtual address basis. Specifically, you can:

• Disable ICMP echo responses. This causes the BIG-IP system to never send an ICMP echo response for ICMP request packets sent to the virtual address, regardless of the state of any virtual servers associated with the virtual address.
• Enable ICMP echo responses. This causes the BIG-IP system to always send an ICMP echo response for ICMP request packets sent to the virtual address, regardless of the state of any virtual servers associated with the virtual address.
• Selectively enable ICMP echo responses. This causes the BIG-IP system to internally enable or disable ICMP responses for the virtual address based on node status for any associated virtual servers. This value affects the behavior of the system in different ways, depending on the value of the Advertise Route setting.