SOL7595: Overview of IP forwarding virtual servers

SOL7595: Overview of IP forwarding virtual servers

---

Updated: 7/6/09 3:41 PM

IP forwarding virtual servers are similar to Layer 2 forwarding virtual servers because they do not have pool members to load balance. An IP forwarding virtual server forwards the packet directly to the destination IP address specified in the client request. Therefore, when the BIG-IP LTM system evaluates the packet for processing, the system looks only at the destination IP address.

For example, in the following configuration the host forwarding virtual server allows all service ports and all valid TCP/IP protocols to be forwarded from the external VLAN to the internal destination of 10.0.0.1:

virtual forward_vs {
destination 10.0.0.1:any
ip forward
translate address disable
vlans external enable

In the following configuration example, the network forwarding virtual server allows connections for service port 22 to be forwarded from the external VLAN to any host on the internal VLAN that resides in the 10.0.0.0/24 network:

virtual forward_vs {
destination 10.0.0.0:22
mask 255.255.255.0
ip forward
translate address disable
vlans external enable

Note: For information about Layer 2 forwarding virtual servers, refer to SOL4362: Overview of Layer 2 forwarding virtual servers.

An IP forwarding virtual server is useful when you want to configure the BIG-IP system to pass infrastructure-related traffic, such as ICMP traffic.

Creating an IP forwarding virtual server

To create an IP forwarding virtual server, perform the following procedure:

1. Log in to the Configuration utility.
2. Click Local Traffic.
3. Click Virtual Servers.
4. Click Create.
5. Enter a name and an IP address for the virtual server.
6. Select Forwarding (IP) from the Type drop-down box.
7. Click Finished.

Note: For more information, refer to SOL5017: Overview of virtual server types.

Emulating stateless IP routing with BIG-IP LTM forwarding virtual servers

The TMOS based full-proxy model is stateful and connection-orientated by nature, in contrast to the stateless IP forwarding typically provided by L3 routers. The BIG-IP LTM must be specifically configured to more closely emulate a standard router's stateless routing behavior by adjusting the virtual server and protocol profile configurations to match your requirements.

For the closest approximation of stateless IP forwarding, F5 recommends creating an IP forwarding wildcard virtual similar to the following example:

virtual vs_wildcard_forwarding {
destination any:any
ip forward
vlans internal enable
profile my_route_friendly_fastl4
}

profile fastL4 route_friendly_fastl4 {
defaults from fastL4
reset on timeout disable
idle timeout 300
loose initiation enable
loose close enable ### Optional (see below) ###
}

This configuration accepts traffic arriving on the internal VLAN and forwards it using the information contained in the system routing table, regardless of whether it is associated with an established connection.

Note: The VLANs on which the forwarding virtual server is enabled may vary depending on your routing requirements and restrictions. The virtual server should be enabled on all VLANs from which it will accept and route traffic.

The FastL4 profile determines how the system handles the connection table entries. Enabling the Loose Initiation option allows the system to initialize a connection when it receives any TCP packet, rather than requiring a SYN packet for connection initiation. It also provides a good alternative to the high overhead of connection mirroring. In the event of a failover, with the Loose Initiation option enabled, the standby BIG-IP system will accept connections midflow and forward as expected. The Loose Close option allows the system to remove a connection when the system receives the first FIN packet from either the client or the server. This will help trim connection table entries as the connection entry can be removed as soon as the connection officially closes and the system need not maintain the connectin table entry.

Note: The Loose Close feature is optional, and may impact system performance since it disables PVA acceleration for the virtual server.

Setting the Idle Timeout allows connections to be removed from the connection table when they are no longer active. F5 Networks recommends using the default timeout of 300 seconds. By disabling Reset on Timeout, connection entries are removed from the connection table once the idle timeout expires, but does not reset the connection. Since this setting prevents the BIG-IP LTM from sending resets when closing an idle connection, it also helps reduce the need of using long idle timeouts for long-lived TCP connections, which may go idle for extended periods of time. For instance, if an application allows for long periods of inactivity (greater than the configured Idle Timeout) with no traffic being exchanged), without this setting, the BIG-IP LTM would close both sides of the connection upon expiration of the timeout. Any subsequent packets sent by the client or server in the same TCP connection would be rejected since the connection is no longer valid on the BIG-IP LTM. However, with Reset on Timeout disabled, the BIG-IP LTM will quietly remove the connection entry and neither the client or server will be aware the communication channel has timed out. When the client or server commences communicating again, the Loose Initiation setting allows the BIG-IP LTM to re-add the connection to the connection table, and the newly arrived packets are forwarded as expected.

Note: F5 Networks does not recommend setting the idle timeout for any virtual server to immediate or indefinite. Setting the timeout to immediate results in constant writing and deletion of connection entries for each datagram, creating undesirable overhead. Setting the timeout to indefinite (or to very large values) results in a connection table that grows until all available memory is consumed, and typically results in an unplanned failover upon memory exhaustion.

Some protocols have different requirements than others. In that case, a more specific virtual server allows you to control traffic handling for specific protocols. A protocol specific virtual can help keep connection table sizes down and if Last Hop is still used, help reduce stale Last Hop information for short-lived connections. For instance, UDP is less stateful than TCP, and does not typically require as long an idle timeout. To set a specific timeout for UDP traffic, you can create the wildcard forwarding virtual server described above, and a protocol-specific forwarding virtual server and profile similar to the following example:

virtual vs_wildcard_forwarding_udp {
destination any:any
ip forward
ip protocol udp
profile udp_fastL4
}

profile fastL4 udp_fastl4 {
defaults from fastL4
idle timeout 5
}

This virtual server only listens for UDP traffic. All other IP protocols will be processed by the more general wildcard forwarding virtual defined previously.