6.2.5 Transparent, Reverse Proxy and Triangle Transmission
6.2.5.1 Transparent Transmission
For transparent transmission, the FortiBalancer appliance will direct the connections toward specified real servers directly when forwarding requests from clients. That is, the server is aware of the client’s IP address and therefore knows which client accesses the server.
Figure 6‑3 Transparent Transmission
- The client sends a request to a virtual IP on the FortiBalancer appliance.
- The FortiBalancer appliance switches the destination address of the request into real server IP.
- The FortiBalancer appliance locates the optimal server available based on the policy and health check conditions, and then forwards the request to the server.
- After receiving the request, the server sends the response to the FortiBalancer appliance. 5. The FortiBalancer appliance switches the source address into virtual IP; 6. The FortiBalancer appliance sends the response to the client. Ø Advantages of transparent transmission:
The server can record the IP addresses of the clients.
Ø Limitations of transparent transmission:
Structure/router design requires responses from source servers to pass through the FortiBalancer appliance;
In the one-armed structure, transparent transmission through FortiBalancer appliance is not applicable when the client is at the same network segment with the real server.
Because requests have different IPs, the system performance cannot be enhanced through the connection pool.
6.2.5.2 Reverse Proxy Transmission
Reverse proxy transmission is used to forward requests to internal servers. The FortiBalancer appliance can distribute the requests evenly among internal servers to ensure server load balancing. As the name of reverse proxy mode indicates, the reverse proxy mode enables clients to access internal servers, whereas the normal proxy transmission enables clients to access external servers. The following figure shows how reverse proxy transmission works:
Figure 6‑4 Reverse Proxy Transmission
- The client sends a request to a virtual IP on the FortiBalancer appliance.
- The FortiBalancer appliance locates the optimal server based on the policy and health check conditions, and then forwards the request to the server.
- The server sends the response to the FortiBalancer appliance.
- The FortiBalancer appliance sends the response to the client.
- Advantages of reverse proxy transmission:
One-armed deployment is applicable.
Connection pool technology can be used to enhance system performance.
- Limitations of reverse proxy transmission:
The IPs of the client that have accessed the server cannot be recorded.
- Solution: The FortiBalancer appliance can insert a field “X-Forwarded-For” into the header of the HTTP request of the client to trace the client IP.
6.2.5.3 Triangle Transmission
Triangle Transmission is specially designed for low-inbound/high-outbound applications such as Video On Demand (VOD), and to accommodate requests in the quickest and most efficient manner. In addition to “reverse” and “transparent” modes, a new system mode “triangle” is added for this new feature.
For Triangle Transmisison, when selecting a proper real server from a group, administrators can use Round Robin (rr), Persistent IP (pi), Hash IP (hi), Consistent Hash IP (chi), Least connections (lc) and SNMP (snmp) group methods. In triangle mode, only TCP, UDP and IP virtual services are supported.
The following shows how the Triangle Transmisison works.
Figure 6-3 Triangle Transmission
- Client sends a request to a virtual IP on the FortiBalancer appliance via the router.
- The FortiBalancer appliance forwards the request to a real service.
- The real service returns a response to the router directly. Since the default route IP on the real service is set to be port2 interface IP of the router, the response will be sent to the router directly.
- The router forwards the response to the client.
In this packet flow, the request will pass through the FortiBalancer appliance, but the response will be sent from the real server to the client directly without hitting the FortiBalancer appliance.
Note: Triangle transmission SLB health check is based on the system IP addresses of the real servers, not the loopback IP addresses. This means when health check is up, the real service might not be available.
6.2.6 Packet based UDP Load Balancing
In FortiBalancer, UDP packets are distributed according to the four-tuple information. This means the UDP packets with the same source IP and port will be regarded as the same UDP flow and then be distributed to the same real server. However, under some circumstances (e.g. RADIUS applications), this method might cause uneven load balancing. To solve this problem, packet based UDP SLB can be used to support single UDP packet based application and more evenly spread load to different real servers.
6.2.7 SIP Load Balancing
What is SIP (Session Initiation Protocol) Load Balancing
FortiBalancer SIP Load Balancing intelligently distributes and balances SIP traffic among multiple SIP servers and provides application persistence based on the unique SIP caller ID to ensure application and transaction integrity. Additionally, to ensure reliability and availability of SIP services, SIP load balancing is able to perform advanced health checks on SIP devices, routing SIP clients away from unstable or unreliable devices. SIP load balancing is critically important for successful, scalable VoIP telephony environments.
Figure 6-4 SIP Load Balancing
SIP Load Balancing performs stateful inspection of SIP messages to scan and hash calls based on a SIP Call-ID header destined for a SIP server. Stateful inspection means that a packet is inspected not only for its source and destination information found in the header, but also packet contents found at Layer 7 (the Application Layer). Once the FortiBalancer appliance has identified the Call-ID which identifies a specific SIP session, it sends future messages from the same Call-ID to the same SIP server.
A SIP proxy server is implemented to NAT the session packets originated from inside real servers. By SIP NAT, real servers can reside in a private network and do not have to own global IP addresses.
Note: A SIP proxy server is the server controlling the management of connections and IP addresses in a SIP-enabled network.
To synchronize SIP registration information, SIP SLB supports the broadcasting of SIP registration requests to all the SIP register servers in the same SLB group.
6.2.8 RTSP Load Balancing
What is RTSP (Real Time Streaming Protocol)
RTSP (Real Time Streaming Protocol) is an application layer protocol which is used for real-time media traffic. Normally, an RTSP session includes two channels: control channel for control signals and data channel for media stream. The control channel is a TCP connection while the data channel can be either TCP or UDP connection.
What is RTSP Load Balancing
The use of streaming audio and video is growing among enterprises for applications such as eLearning and corporate communications. RTSP streaming delivers higher performance, and is more secure and easier to manage than HTTP streaming implementations. FortiBalancer appliance enables companies to optimize streaming media resources by intelligently and transparently switching requests to RTSP media servers or caches.
RTSP Load Balancing only supports filetype, default, backup and static policy. In filetype policy, the real service is selected based on the file extension names. For example, client request for
“rtsp://mp3.xyz.com/test.mp3” will hit the RTSP SLB group corresponding to “mp3” filetype.
Particularly, RTSP Load Balancing supports two working modes: “REDIRECT” and “Dynamic NAT”.
- Redirect mode
The media stream will not pass through FortiBalancer appliance. After FortiBalancer appliance retrieves Request-URL from the client request, it will select a real service according to the file type, and then send a “REDIRECT” response to inform the client to access the selected real service.
- Dynamic NAT mode
Media stream will pass through FortiBalancer appliance. After FortiBalancer appliance selects a real service according to the policy, it will retrieve the media transport information from the negotiation between the client and the real service. And then implement dynamic NAT for media streaming packets according to their requirement. All connections (TCP and UDP) of one RTSP session will be closed when the control connection tears down.
6.2.9 Layer 2 IP/MAC-based Load Balancing
Layer 2 IP/MAC-based SLB allows you to balance network traffic without changing the network packet’s source IP/MAC address and destination IP/MAC address. It is widely used in virus or mail scanner, content filter and triangle transmission.
Different from higher layer SLB (Layer 4 and Layer 7 SLB), the traffic to be balanced in Layer 2 does not need to access a particular IP address or “IP address + Port” pair defined in the interface (normally the port1 interface) on FortiBalancer appliance for balancing purpose. As long as the incoming traffic can be routed to FortiBalancer appliance’s interface with defined Layer 2 virtual services (e.g. virtual services are defined on FortiBalancer appliance’s port1 interface and FortiBalancer appliance port1 interface’s system IP address is set as the gateway of client machines), it will be balanced among a pool of Layer 2 real services according to configured load balance algorithms.
Layer 2 SLB feature has its own definitions for virtual service, real service, group method, health check and policy:
- Virtual service is defined by IP address. Internally, the associated input interface will be found;
- Real service can be defined by either IP or MAC address. Internally, the associated output interfaces will be discovered;
- Layer 2 SLB only supports default policy;
- Layer 2 SLB Health Check: Layer 2 SLB real services support all the health check methods available in Layer 4/Layer 7 SLB health check. Only the additional health check can be configured to the Layer 2 SLB real services.
- The supported groups methods are rr (Round Robin) and hi (Hash IP).
6.2.10 Layer 3 IP-based Load Balancing
Layer 3 IP based SLB balances all the TCP and UDP traffic from one global virtual IP address to multiple real servers. Unlike Layer 4 SLB, both the virtual service and real service in Layer 3 SLB are defined by single IP address without port number. Layer 3 SLB real services only support ICMP health check. Without specifying port number, Layer 3 SLB works for a much wider range of administrators, especially in the following scenarios:
- Cross-port applications: some session protocols bind multiple connections together, one is the initial connection, others could be generated from dynamic ports
- Cross-protocol applications: most streaming protocols use UDP connection for data transferring and TCP connection to transfer control information between the same client and server.
6.2.11 Port Range Load Balancing
Port range SLB allows us to define a virtual service with a range of ports so that theOS will listen for connections on all the ports in the range and distribute the requests to a group of real services that can be configured with either a port range or a static port.
Port range virtual service has lower priority than Layer 4 and Layer 7 virtual services. That means, if an input request hits both a Layer 4/Layer 7 virtual service and a port range virtual service, the Layer 4/Layer 7 virtual service will be matched first.
Port range real service and static port real service can not be configured in one group. Port range real service and port range group can only be associated with port range virtual service. However, port range virtual service can associate with static port real service. Port range SLB does not work for “FTP” type real services and virtual services.
The health check type of a port range real service can only be “none” or “ICMP” because its port is 0. If other health checks are needed, additional health checks can be used:
FortiBalancer(config)#slb real http rs1 10.3.0.20 0 1000 none FortiBalancer(config)#slb real health a1 rs1 10.3.0.20 80 http
6.2.12 Terminal Server Load Balancing
FortiBalancer provides session persistency to balance RDP (Remote Desktop Protocol) traffic load among a terminal server farm by using Terminal Services Session Directory Service. This enables a user to disconnect a session with running applications, whether intentional or because of a network failure, and then reconnect at a later time to the same session, with the same running application.
Terminal Services Session Directory Service is a database that keeps track of sessions on terminal servers in a load-balanced farm. The database maintains a list of the user names that are associated with the session IDs that are connected to the servers in a load-balanced terminal server farm. It can either reside on a server that is separate from the terminal servers in the farm, or be hosted on a member of the terminal server farm.
When a client sends an authentication request to FortiBalancer appliance, FortiBalancer appliance will forward the request to one of the terminal servers in the farm, for example TS1. TS1 prompts the client with a login screen. After the client enters the user name and password, TS1 validates the user name and password, and queries Session Directory database with the user name. If a session with the same user name already exists on one of the terminal servers in the farm, for example TS2, Session Directory will send the information (including TS2’s IP address and port number) to TS1, and TS1 will send a routing token with the TS2’s IP address and port to the client and drop the connection with the client. After that, the client sends FortiBalancer appliance another authentication request with the routing token. FortiBalancer appliance will reconnect the client to TS2 according to the IP address and port in the routing token.
6.2.13 RADIUS Server Load Balancing
In RADIUS (Remote Authentication Dial-In User Service) Load Balancing solution, when the RADIUS request packets go through the FortiBalancer appliance before they are forwarded to the backend RADIUS servers, the FortiBalancer appliance will first check the username or session ID field in the RADIUS request packets and employ relevant load balancing methods (“radchu” method for the “username” field and “radchs” method for the “session ID” field) to create a mapping between the RADIUS request packets and the hit RADIUS server. And then,
FortiBalancer will check if a connection with the RADIUS servers exists. If the connection exists, the RADIUS packets will be sent to that backend RADIUS server; otherwise, the connection will be created and saved (the connection is time limited and will be removed as soon as it times out) and then the request will be sent to the RADIUS server via the connection. In this way, the FortiBalancer appliance can implement even load balancing among the multiple RADIUS servers.
6.2.14 DirectFWD
DirectFWD is a new Layer 4 SLB function by utilizing a multi-thread and non-lock architecture based on a multi-core system. This new architecture has maximized the advantage of the multi-core system. Compared with the traditional Layer 4 SLB, DirectFWD provides remarkably better Layer 4 SLB performance. This function is controlled by the command “slb direcfwd {on|off}”.
DirectFWD supports both the IPv4 and IPv6-based TCP packets.
Since only limited functions are implemented in the new architecture now, the DirectFWD function still has some limitations as follows:
- It is only used for TCP SLB, and temporarily only supports static, default and backup policies. All the Layer 4 SLB methods, except Shortest Response Time, are supported. (Please refer to the policy-method supporting matrix to check the details about the Layer 4 SLB methods).
- It cannot be used in different MTU environments. In other words, all the interfaces must have the same MTU; otherwise, the connection may fail to handle the big packets.
- It cannot handle IP fragments.
Note: The more the interfaces used for DirectFWD, the better the performance.
DirectFWD Syncache
DirectFWD syncache effectively and efficiently protects the real servers from SYN flood DOS attacks. When DirectFWD syncache function is on, all the SYN packets from a client will not be forwarded to a real server directly. The FortiBalancer appliance will hold the useful information in those SYN packets firstly, and then send a SYN-ACK packet to the client. After that, the FortiBalancer appliance will receive an ACK packet from the client and setup a TCP connection with the real sever.
Note: When the DirectFWD syncache function is on, clients cannot negotiate MTU with real servers.
6.2.15 Real Service Graceful Shutdown and Warm-up Activation
6.2.15.1 Real Service Graceful Shutdown
By default, when a real service is disabled or deleted, the FortiBalancer appliance SLB shall not send session requests to the real service that has been disabled. However, for the real services using cookie-based group method and load balancing polices, such as pc (Persistent Cookie), ic (Insert Cookie), rc (Rewrite Cookie), SLB will still send the existing session requests that match the cookie to the disabled real service to ensure service persistence. While the new session requests will be sent to other working real services. This function is called “Graceful Shutdown”, as shown below.
Figure 6-5 Graceful Shutdown of Real Services The following gives an example of Graceful Shutdown:
FortiBalancer(config)#slb real disable service
After disabling the real service named “service”, users can check the status of the real service by using the command “show statistics slb real”.
FortiBalancer(config)#show statistics slb real http service
Real service service 10.8.6.42 80 DOWN INACTIVE(waiting)
Main health check: 10.8.6.42 80 tcp DOWN
Max Conn Count: 1000
Current Connection Count: 4572
Outstanding Request Count: 4215
Total Hits: 311
Total Bytes In: 39431
Total Bytes Out: 53466
Total Packets In: 7541
Total Packets Out: 3252
Average Response time: 32.000 ms
As shown in the above output information, the status of “service” is displayed as
“INACTIVE(waiting)”, which means the real service is still processing connection requests, i.e. it is in the process of “Gracefully Shutdown”. During this process, the session requests that match the cookie will still be forwarded to this real service, while the connection requests from new clients will be forwarded to other working real services.
After a while, users can run the command “show statistics slb real” again to check the status of the real service.
FortiBalancer(config)#show statistics slb real http service
Real service service 192.168.10.10 80 DOWN INACTIVE(suspend)
Main health check: 192.168.10.10 80 tcp DOWN
Max Conn Count: 1000
Current Connection Count: 0
Outstanding Request Count: 0
Total Hits: 0
Total Bytes In: 0
Total Bytes Out: 0
Total Packets In: 0
Total Packets Out: 0
Average Response time: 0.000 ms
As shown in the above output information, the status of “service” now is displayed as “INACTIVE(suspend)”, which means it is shut down completely.
6.2.15.2 Real Service Warm-up Activation
After a real service is enabled, it might receive a large number of requests immediately before getting fully prepared to work. The sudden increase of traffic on the real service might lead to failure of the service. To solve this problem, the FortiBalancer appliance supports warm-up activation of real services. Administrators can set recovery time and warm-up time for real services.
Right after a real service is enabled, no connection requests will be sent to the real service for a period of time. This period is called “recovery time”. When the recovery time ends, the real service enters the “warm-up time”. In this period of time, firstly only a small amount of connection requests are forwarded to the real service for processing. The number of the requests will be increased gradually. When it reaches the maximum number allowed for the real service, it means the real service works normally.
Administrators can use the command “show statistics slb real” to check the status of a real service. As shown in the following output information, the status of the real service in “recovery time” is displayed as “UP(softup)”. No connection requests will be sent to a real service in “softup” status.
FortiBalancer(config)#show statistics slb real http service Real service service 192.168.10.10 80 UP (softup) ACTIVE
Main health check: 192.168.10.10 80 tcp ACTIVE
Max Conn Count: 1000
Current Connection Count: 0
Outstanding Request Count: 0
Total Hits: 0
Total Bytes In: 0
Total Bytes Out: 0
Total Packets In: 0
Total Packets Out: 0
Average Response time: 0.000 ms