The Barracuda Load Balancer supports multiple options to direct clients back to the same Real Server, depending on the Service type.
Layer 7 - HTTP(S)
There are a variety of supported persistence methods for HTTP sessions:
- HTTP Cookie - When a client initiates contact, the Barracuda Load Balancer inserts a cookie into the outgoing response. This cookie is returned by the client with each subsequent request. The Barracuda Load Balancer strips the cookie from the request and then directs the request to the same Real Server.
- Client IP Address - Subsequent requests from a client with a recurring IP address or systems from the same subnet go to the same Real Server.
- HTTP Header - All incoming HTTP requests are directed to the same Real Server based on the value of a header. The application (e.g., Microsoft Exchange) specifies the name of the header to be examined.
- URL Parameter - All incoming HTTP requests are directed to the same Real Server based on the value of the specified parameter in the URL.
Layer 4 -TCP, TCP Proxy, Secure TCP Proxy or Layer 4 - UDP
Only client IP address persistence is supported. An individual client IP address can be used or you can specify a subnet mask so that subsequent TCP connections or UDP datagrams from systems from the same subnet go to the same Real Server.
UDP Proxy
A UDP Proxy Service supports persistence using both client IP address and port to distribute the traffic across all of the Real Servers. This helps mitigate the fact that many UDP applications involve all client requests coming from one client IP address.
Layer 7 - FTP(S)
Persistence is not supported.
Layer 7 - RDP
Session persistence is achieved by querying Windows Server® 2003 Terminal Services Session Directory, Windows Server® 2008 Terminal Services Session Broker or Windows Server 2008® R2 Session Broker. See Remote Desktop Services Load Balancing.