SOL9812: Overview of BIG-IP TCP RST behavior
Updated: 7/7/09 4:10 PM
The BIG-IP system will close a TCP connection by sending a TCP RST packet to a client and/or pool member under a variety of circumstances. Depending on the specific BIG-IP LTM object, the BIG-IP reset behavior can be adjusted from the default settings by using the Configuration utility or command line.
The BIG-IP LTM may send a TCP RST packet for the following reasons:
Global Settings
- Adaptive Reaping
In order to prevent SYN flood attacks, and to preserve memory, the BIG-IP system can prevent new connections by sending a TCP RST packet to the client when memory usage increases beyond the reaper high-water mark setting. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object IP address for which the SYN request was destined.
Note: For more information, refer to SOL5670: Overview of adaptive connection reaping and SOL7301: Protecting the BIG-IP LTM against denial of service attacks.
- TM.MaxRejectRate
The BIG-IP system sends a TCP RST packet in response to a non-SYN packet which matches a virtual server address and port or self IP address and port, but does not match an established connection. The BIG-IP system also sends a TCP RST packet in response to a packet matching a virtual server address or self IP address, but specifying an invalid port. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object address or self IP address for which the packet was destined.
Note: For more information, refer to SOL9259: Limiting the rate at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets and SOL7317: Overview of port lockdown behavior.
Virtual servers
- Virtual server connection limits
When a virtual server connection limit is configured, and the maximum number of concurrent connections is exceeded for the virtual server, the BIG-IP sends a TCP RST packet in response to connection attempts. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL5067: The BIG-IP sends a reset when a virtual server connection limit is reached.
- Reject virtual servers
A Reject virtual server always sends a TCP RST packet in response to a connection attempt. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types.
Pools
- No available pool members
When all pool members are unavailable due to being disabled, forced offline, or down, the BIG-IP system sends a TCP RST packet in response to a connection attempt to the virtual server. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL7586: The BIG-IP LTM resets the connection and generates an error message when no members are available for a pool.
- Pool member or node connection limits
When a pool member or node connection limit is configured, and the maximum number of concurrent connections is exceeded for the virtual server, the BIG-IP resets the connection attempt. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL9849: The BIG-IP sends a TCP reset when a pool member or node connection limit is reached.
Profiles
- Protocol profile idle timeouts (if the Reset On Timeout setting is enabled)
The BIG-IP system tracks connection flows by adding an entry to the connection table. When the connection flow becomes idle, the BIG-IP starts a timer and closes the connection with a TCP RST packet when the connection reaches the idle session timeout. The TCP RST packet is sent on the client and server side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL7606: Overview of BIG-IP LTM idle session timeouts and SOL7166: Changing the idle timeout for a protocol profile.
- Maximum Segment Retransmission
The BIG-IP LTM resets TCP connections after sending eight retransmissions for a connection. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant virtual server IP address.
Note: For more information, refer to SOL7301: Protecting the BIG-IP LTM against denial of service attacks and SOL7381: The BIG-IP LTM resets TCP connections after sending eight retransmissions for a connection.
SNATs
- Unacknowledged SYN requests for SNAT objects
The BIG-IP LTM system terminates a SNAT flow with a TCP RST packet after processing three unacknowledged SYN requests for the connection.
Note: For more information, refer to SOL7829: Connections processed by a SNAT are terminated after three unacknowledged SYN requests.
- Idle connection timeouts for SNAT objects
When a SNAT connection flow becomes idle and reaches the idle session timeout, the BIG-IP closes the connection with a TCP RST packet.
Note: For more information, refer to SOL7606: Overview of BIG-IP LTM idle session timeouts.
- SNAT port exhaustion
A SNAT supports approximately 64,000 concurrent connections. A high volume of requests can exceed the 64,000 connection limit and result in TCP port exhaustion.
Note: For more information, refer to SOL2561: Selecting SNAT or SNAT automap.
Note: Connections processed by a SNAT object are also frequently processed by a virtual server object. The source address of the TCP RST packet will vary depending on whether the connection is processed by a SNAT object alone, or whether the connection is also processed by a virtual server.
Monitors
- BIG-IP health monitors
Certain BIG-IP monitors use a TCP RST packet to close the monitor connection quickly. For example, the tcp_half_open monitor performs a simple check on the pool member service by sending a TCP SYN packet to the service port. When the monitor receives the SYN-ACK packet from the pool member, the monitor considers the service to be up, and sends a TCP RST packet to the service instead of completing the three-way handshake. The TCP RST packet is typically sent on the server side of the connection, and the source IP address of the reset is the relevant self IP address of the VLAN.
iRules
- iRule commands
An iRule can be configured to close TCP connections using a TCP RST packet. For example, the reject iRule command closes the TCP connection by sending a TCP RST packet to the TCP peer as appropriate for the protocol. The TCP RST packet is sent on the client side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object address with which the iRule is associated.
Note: For more information, refer to the DevCentral iRule wiki. A separate DevCentral login is required to access this content; you will be redirected to authenticate or register (if necessary).
VLAN groups
- L2 forwarding proxy (VLAN groups)
In a VLAN group configuration, traffic that does not match a configuration object, such as a virtual server or SNAT, is handled by the Layer 2 (L2) forwarding proxy. The L2 proxy default will send a TCP RST packet to close L2 forwarding sessions after 300 seconds. The TCP RST packet is sent on the client and/or server side of the connection, and the source IP address of the reset is the self IP address of the VLAN.
Note: For more information, refer to SOL7606: Overview of BIG-IP LTM idle session timeouts.
沒有留言:
張貼留言