Global Server Load Balancing – FortiBalancer

Chapter 14 Global Server Load Balancing (GSLB)

14.1 Overview

GSLB (Global Server Load Balance) is also known as Smart DNS (SDNS). This function allows you to distribute Web traffic among a collection of servers deployed in multiple geographic locations. We will cover introduction of GSLB and the examples of GSLB configuration in this chapter.

14.2 Understanding Global Server Load Balance

In GSLB solution, the FortiBalancer appliance works as a complementary DNS server which is able to resolve a set of defined domain names based on load balancing methods. When DNS queries (typically forwarded by corporate DNS server or ISP DNS server) for the domain name are received, GSLB function will resolve the domain name with IP addresses selected from its Domain Name and IP Service Database with configured load balancing method.

SDNS maintains a local Domain Name and IP Service Database by continuously exchanging their local load (Hello message) and domain name/IP address information (Report message) with other members (also FortiBalancer appliances) in the GSLB network. For example, when an FortiBalancer appliance joins the SDNS network, the FortiBalancer appliance will continuously send its local domain name/IP address information to all other participating members (see LLB configuration). For each message transmitted, a confirmation message is expected in return. If a confirmation message is missed or a message is not updated for a period of time (3 tries), GSLB will mark the non-responsive member as down and all the domain name/IP addresses that are hosted by that FortiBalancer appliance will be removed from its local Domain Name and IP Service Database.

The SDNS process works as follows:

 

Figure 14-1 SDNS Working Mechanism

As shown in the above figure, the SDNS module will process a normal DNS request from the client as follows:

  1. The client’s browser generates a DNS request for the domain name of the Web site he wants to visit, and sends the request to its local DNS server.
  2. The local DNS server receives the request and searches in its local cache. If no cache entry hits, it will forward the request to the upper-level SDNS device. In the above example figure, the request is sent to an SDNS server at Beijing according to configurations on the local DNS server.
  3. The SDNS server at Beijing continuously collects the status information of all the application servers in its local Domain Name and IP Service Database, and then forwards the request to a proper application server based on pre-configured load balancing algorithms. In the above example, the application server at New York is selected.
  4. The SDNS server at Beijing returns back the IP addresses of the application server at New York to the local application server of the client.
  5. Upon receiving the response, the local application server forwards IP address to the client directly.
  6. The client’s browser uses the IP address in the response to open an HTTP connection with the corresponding FortiBalancer appliance and proceeds to download the Web page.

In this process, the response is cached on both the client’s local DNS server and the client’s browser.

Note: In this chapter, we will use the term “member” or “SDNS member” frequently. Either

“member” or “SDNS member” is an FortiBalancer appliance which participates in the GSLB management.

14.2.1 SDNS Member Reporter-Receiver Hierarchy

All SDNS members can be divided into two groups: SDNS server and HTTP proxy cache server. They are all FortiBalancer appliances, while HTTP proxy cache servers serve as the “reporter” and SDNS servers serve as the “receiver”.

 

Figure 14-2 SDNS Reporter-Receiver Hierarchy

SDNS Servers

SDNS servers are responsible for DNS resolving. Every HTTP proxy cache server will report its status information to SDNS servers. The status information includes:

  • The domain name configured on proxy cache servers
  • The IPs which are configured for a domain name and their status (“UP” or “DOWN”)
  • The domain name traffic on proxy servers, IP traffic and proxy traffic
  • The status of proxy cache servers (“UP” or “DOWN”)

HTTP Proxy Cache Servers

HTTP proxy cache servers are responsible for HTTP services. All kinds of HTTP requests will be directed to HTTP proxy cache servers, mostly by the SDNS servers. The HTTP proxy cache servers will collect the local status information and send it to SDNS servers at specified frequency. If an FortiBalancer appliance is a DNS server and a proxy cache server at the same time, it will report its local status information to all the SDNS servers (including itself) and collect the status information from all the proxy cache servers.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Link Load Balancing – FortiBalancer

Chapter 13 Link Load Balancing (LLB)

13.1 Overview

This chapter details the configuration of the following Inbound and Outbound Link Load Balancing implementations:

  • Single FortiBalancer appliance and two ISPs
  • Dual FortiBalancer appliances and two ISPs

13.2 Understanding LLB

LLB (Link Load Balancing) allows TCP/IP network traffic to be load balanced through up to 128 upstream Internet Service Providers (ISPs). Load balancing can be performed on egress to the Internet (outbound LLB) or on ingress from the Internet (inbound LLB). LLB methods include rr (Round Robin), wrr (Weighted Round Robin), sr (Shortest Response), dd (Dynamic Detecting) and hi (Hash IP). LLB also includes ISP/link failure detection through default gateway and link patch health checking.

The FortiBalancer appliance identifies links based on the logical port and peer MAC address. The statistics of LLB links are also collected based on the logical port and peer MAC address.

13.2.1 Outbound LLB

Outbound LLB provides optimized outbound link utilization for environments that have more than one default gateway. In essence, it allows outbound traffic to be distributed among multiple upstream/ISP routers.

For example, let’s say you have Internet connectivity provided by two ISPs: ISP1 and ISP2. ISP1 assigns address range 100.1.1.0/24 so that you may use them on your network devices. ISP2 assigns address range 200.1.1.0/24 so that you may use them on your network devices. Outbound LLB allows you to load balance outbound connections traffic through ISP1 and ISP2. Connections forwarded through ISP1 are NATTed to an address from the range assigned by ISP1. Connections forwarded through ISP2 are NATTed to an address from the range assigned by ISP2. Thus, inbound responses for those connections will return through the ISP that they were originally sent through. If Internet connectivity through one of the ISP links is lost or interrupted, the outbound traffic will no longer be sent through that ISP. All traffic will be distributed to the functional ISP.

FortiBalancer outbound LLB methods can work well on the data traffic based on TCP and UDP protocols. However, for the packets based on IP, IPsec or GRE protocols, FortiBalancer LLB methods cannot do load balancing well. To deal with this problem, FortiBalancer now supports LLB for the IP based packets so that the IP-based packets can be delivered to different links like the way the TCP/UDP packets are processed.

13.2.2 Inbound LLB

Inbound LLB provides service resiliency for inbound clients. Hosted services are visible to external clients via a separate IP address on the address space assigned by each ISP.

To illustrate, let’s use the same example ISPs as mentioned previously. All external clients trying to connect to the addresses assigned by ISP1 will be routed through ISP1’s backbone. All external clients trying to connect to addresses assigned by ISP2 will be routed through ISP2’s backbone. Inbound LLB allows you to advertise a device or Virtual IP (VIP) using two IP addresses: one from ISP1 and the other from ISP2. A DNS server on the FortiBalancer appliance will respond to queries for configured domain names. The responses will contain an IP address from ISP1 or ISP2, both representing the same device or VIP. If Internet connectivity through one of the ISP links is lost, the DNS server will not respond with the address from the failed ISP. Clients will receive only the address from the functional ISP.

13.2.3 LLB Health Check

LLB Health Check is used to check whether the link between the FortiBalancer interface and the upstream device is available. This can be accomplished by broadcasting ARP requests at regular intervals and pinging a user-defined upstream IP address. Besides, TCP-based and DNS-based health checks are also supported. The ICMP, TCP and DNS types of health check all work in the userland. This greatly improves the health check performance.

Broadcasting ARP requests at regular intervals can check the availability of the link path between FortiBalancer interface and the upstream ISP router. Pinging a user-defined upstream IP address not only can verify if the link path between FortiBalancer interface and the upstream ISP router is available, but also verify the link path between upstream ISP router and user-defined upstream IP address. Multiple upstream IP addresses can be defined for reliable checking. If any of check point is pingable, the related link is usable. This ensures that the WAN link is up before forwarding traffic across that link.

13.2.4 LLB Methods

Outbound LLB supports the following load balancing methods:

  • rr (Round Robin)
  • wrrr (Weighted Round Robin)
  • sr (Shortest Response Time)
  • dd (Dynamic Detecting)
  • hi (Hash IP)

Inbound LLB supports three load balancing methods:

  • rr (Round Robin)
  • wrrr (Weighted Round Robin)
  • proximity

Round Robin distributes each new session to gateways in an alternating (round robin) way. This is the default load balancing method.

Weighted Round Robin is similar to Round Robin except that a bias (or weight) may be assigned to each gateway so that some gateways may receive more sessions than others. This allows more traffic to be directed through an ISP with higher bandwidth capacity.

Shortest Response Time: The link with the shortest response time will get the next request. Calculation of shortest response time of a link is based on the initiation process of each TCP connection (both inbound and outbound connections). For the most accurate result, there should be enough TCP traffic instead of a few long existing TCP connections or only UDP traffic.

Note:

If neither SLB traffic nor NAT traffic goes through the system, the LLB SR method cannot work properly.

The “sr” method cannot be used to load balance IP fragments, non-TCP/UDP packets, and reassembled UDP packets.

Dynamic Detecting performs proximity calculations through all available ISP paths to the destinations. By using parallel probe arithmetic, a request from the client will be sent to a destination by different ISP paths at the same time. When the first response returns, the optimal ISP with the shortest response time will be selected for this request and other ISP connections will be failed. For future outbound traffic to the same destination, FortiBalancer appliance will choose the best ISP connection, according to the results derived from these proximity calculations. Hash IP distributes the outbound traffic among links in the way that the link with higher weight is routed with higher probability, by performing Hash operation on the source IP. When the chosen link is down, the system will carry another Hash operation on the links available. When HI is deployed as the LLB method, the IPflow function can be disabled.

Proximity: The IP address of the nearest DNS server will be sent to the client as the response. When a DNS request arrives, FortiBalancer will first search in the Eroute table reversely to find a proximity route matching the source address of the DNS request, and then give response to the client with the corresponding DNS server’s IP address (A record) according to the Eroute gateway.

13.2.5 Policy-based Routing (Eroute)

LLB policies provide the methods necessary to allow administrators to direct outbound traffic to a preferred route based on the IP address (source and destination) and service type (mail, FTP, Web, etc.).Policy based routing, unlike regular routing, allows the inclusion of the source IP, source port and destination port as well as the protocol into the route selection. For example, using routing policy can ensure that all the traffic generated by AOL instant messenger always uses the same link. If instant messenger client uses different destination IP addresses in its requests and these requests are sent through the different routes, this might confuse the server and cause login failure.

Configuring routing policy will prevent this problem. The CLI command for that would be:

FortiBalancer(config)#ip eroute aol_route 1500 0.0.0.0 0.0.0.0 0 0.0.0.0 0.0.0.0 5190 tcp gateway_ip 1

The FortiBalancer appliance supports at most 5000 eroutes.

IP region

Eroute supports IP region. Administrators are allowed to import pre-defined IP region table via HTTP, FTP or Local File method, and then execute the command “ipregion route” to apply the imported IP region table. This will generate a large number of Eroute configurations, without making complex configurations. Administrators are also allowed to export the IP region table via FTP URL or Local File method.

FortiBalancer appliance will check the contents of the file instead of the file type when an IP region file is imported. To ensure that the IP region file can be imported successfully, please pre-define the file contents strictly with the following items included in each entry:

  • IP subnet (in CIDR format)
  • Country name (optional, up to 7 bytes)
  • Brief description (optional, up to 63 bytes) These items must be separated with a “Tab”. For example:
27.8.0.0/13 CN China Unicom Chongqing Province network
27.36.0.0/14 CN China Unicom Guangdong province network

Note: 

  1. By default, there are three predefined IP region tables including “predefined_cernet”, “predefined_cnc” and “predefined_ct”. It is recommended not to use the same name with the default predefined IP region tables.
  2. The routes and proximity rules configured for IP region exist as a whole in the system.

Administrators cannot change or remove a single route or a rule.

13.2.6 LLB Session Timeout

After an ISP link has been selected for an IP flow (source IP and destination IP) pair, all traffic with the same source IP and destination IP will be sent to the same ISP. After an IP flow has been idle for a period of time, the session will be removed. Subsequent IP flows will once again be distributed based on the load-balancing algorithm.

13.2.7 Route Priority

The administrator will need to provide the method necessary to allow end-users to direct outbound traffic to a preferred route based on the IP address and protocol type. FortiBalancer appliance supports variant types of routing rules in which eroute priority is higher than priority of the default and static routes. Default routes will have priority 1 and static routes 101-132 depending on the netmask; i.e. the static route with 24-bit netmask will have priority 124 and with 32-bit netmask will have priority 132. The routes that correspond to the interfaces will have priority 2000. The routes created based on the traffic that come from the local subnet are called droutes (Direct Route) and will have priority 2000.

The following table shows the priority of different types of routes:

Table 13-1 Route Priority

Name of Route Priority
EROUTE-P 2001-2999
IROUTE, DROUTE 2000
RTS 1999
EROUTE-N 1001-1999
IPFLOW 1000-1999 (defaults to 1000)
STATIC ROUTE 101-132 (IPv4)

101-228 (IPv6)

DYNAMIC ROUTE 101-132 (IPv4)

101-228 (IPv6)

LLB LINK ROUTE 2
DEFAULT ROUTE 1

13.2.8 Link Bandwidth Management

For better link bandwidth management, the FortiBalancer appliance allows administrators to set a threshold value for the LLB link bandwidth.

When performing link selection for the outbound traffic, the system considers not only the routing policies configured for links but also the load status of each link. That is, when the current link has reached the configured bandwidth threshold, the FortiBalancer appliance will search for available links from matched routes according to the descending sequence of priorities. The FortiBalancer appliance first searches for available links from routes with the same priority as the current link. If all available links reach their bandwidth thresholds, the FortiBalancer appliance will search for available links from routes with lower priorities. If the gateways of all matched routes are down or reach the configured bandwidth thresholds, the FortiBalancer appliance will still choose the current link to transmit traffic.

In addition, the FortiBalancer appliance allows administrators to configure a priority for the LLB link bandwidth. If the priority of a matched route is higher than the LLB link bandwidth priority, the traffic will be directly forwarded through this route.

With the LLB bandwidth management function, you do not need to configure Eroutes with the same priorities for multiple links. This improves the efficiency and flexibility of link bandwidth configuration and management.

Note:

  1. If the traffic hits a RTS or IPflow route, the traffic will be directly forwarded through the relevant LLB link no matter whether the LLB link reaches the bandwidth threshold.
  2. If an Eroute has been configured with the source IP address, source mask, source port number, destination IP address, destination mask, and destination port number and these IP addresses and masks are set to 0.0.0.0 and port numbers are set to 0, the FortiBalancer appliance will not search for available links from the matched routes whose priorities are lower than 1000.

13.2.9 IPv6 Support for LLB

The FortiBalancer appliance provides broad IPv6 support for the LLB module, of which the Eroute, inbound and outbound LLB, link health check and IP region can all work in the IPv6 network environment. For the Eroute, the source IP, destination IP, gateway IP and IP region can all be configured with the IPv6 addresses. However, please note that only IPv4 or only IPv6 addresses can be configured in one IP region table. For outbound LLB, only route-based LLB supports IPv6 configurations, while NAT-based LLB does not.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Quality of Service – FortiBalancer

Chapter 12 Quality of Service (QoS)

12.1 Overview

This chapter introduces how to setup the QoS (Quality of Service) function on the FortiBalancer appliance. We setup the QoS functionality to provide administrators with the control over network bandwidth and allow them to manage the network from the business perspective, rather than the technical perspective.

12.2 Understanding QoS

QoS for networks is an industry-wide set of standards and mechanisms for ensuring high-quality performance for critical applications. By using QoS mechanisms, network administrators can use existing resources efficiently and ensure the required service level without reactively expanding or over-provisioning their networks.

QoS provides network administrators with the capacity of TCP, UDP and ICMP flow management by using queuing mechanism and packet filtering policies. By using queuing mechanism and filter rules, QoS supports both bandwidth management and priority control.

12.2.1 Queuing Mechanism

The FortiBalancer appliance has developed a queue-based QoS. Queue means a queue of network packet buffers. After the packet at the beginning of the queue has been processed, a new packet to be processed will be put at the end of the queue.

Each queue is bound with a particular network interface and controls either incoming or outgoing network traffic of that interface. QoS queues are organized in tree-like structures. On the top of a tree, a root queue is defined for either incoming or outgoing traffic of a network interface. Under the root queue, there can be multiple sub-queues. Sub-queues can also have their sub-queues. For each interface, at most two queue trees can be configured: one for the incoming traffic, and the other for the outgoing data.

Each queue is configured with bandwidth limit and priority for packet processing.

12.2.2 Packet Filter Rule

A QoS filter is a rule which associates particular network traffic with a QoS queue.

In filter rule, the network traffic is specified by five parameters: source IP subnet, source port, destination IP subnet, destination port and protocol. By this association, administrators can deploy either application-oriented or link-oriented QoS control. Normally, application-oriented filter rules have TCP or UDP ports defined while link-oriented filter rules focus on source or destination IP addresses.

12.2.3 Bandwidth Management

Bandwidth management is realized by a set of QoS filter rules which bind particular network traffic to pre-defined QoS queues with limited bandwidth settings. The QoS filter rules help FortiBalancer appliance servers to allocate appropriate bandwidth to satisfy the needs from various applications and links.

For more flexible bandwidth control, “BORROW/UNBORROW” strategy is applied to QoS queues in a tree-like structure. When a queue’s “BORROW” flag is turned on, its bandwidth can be expanded by borrowing from its parent queue. If the parent queue does not have extra bandwidth to share, it can also fall back on its parent, until the parent queue is the root queue.

12.2.4 Priority Control

Priority Control is accomplished by QoS queues in different priorities. All packets from different applications or links are firstly classified by QoS filter rules and then distributed to predefined queues enjoying the pre-configured priorities.

This priority mechanism works well especially when the network become crowded. If the traffic reaches a peak, packet loss will arise when the number of packets waiting for processing exceeds the maximum queuing buffers. Under such circumstance, the packets belonging to the queues with the highest priority will be processed in the first place, while other packets with lower priorities may be dropped. In this way, the mission-critical applications will be assigned with the highest priority, therefore the functionality of the most important transactions is guaranteed.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Secure Sockets Layer – FortiBalancer

Chapter 11 Secure Sockets Layer (SSL)

11.1 Overview

Now that the basic SLB and Caching are setup on the FortiBalancer appliance, we can set up the SSL (Secure Sockets Layer) acceleration functionality to provide secure transactions with your clients. The SSL Accelerator works by decrypting the secure traffic and passing the unencrypted traffic to the original server. In an alternative mode the SSL accelerator can be used to decrypt the secure traffic, apply traffic management (SLB, caching, etc.) processing on decrypted traffic and then encrypt it back before passing it to SSL enabled origin server.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

HTTP Compression – FortiBalancer

Chapter 10 HTTP Compression

10.1 Overview

The FortiBalancer appliance supports in-line compression of HTTP objects. By employing this licensed feature, administrators may maximize throughput to the desired site while end-users will experience quicker download speeds. This chapter describes the configuration of HTTP Compression capabilities which are part of the FortiBalancer platform. Configuration of HTTP Compression functionality can be divided into two main parts. The first part is the basic configuration and the second part is dedicated to advanced configuration.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

DNS Cache – FortiBalancer

Chapter 9 DNS Cache

9.1 Overview

The DNS SLB mechanism used by FortiBalancer appliance supports DNS cache feature. Upon receiving any type “A” or “AAAA” DNS responses, which are mapping of host names to IP addresses, FortiBalancer will save them in SLB DNS cache. Then, when the FortiBalancer appliance receives any DNS requests for the cached “A” or “AAAA” records from clients, the appliance will directly send back the “A” or “AAAA” responses to the clients. If there is no records in cache that hit the requests, the FortiBalancer appliance will communicate with the remote DNS server(s) directly, and then save the server responses in cache for responding to the coming requests.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

HTTP Content Rewrite – FortiBalancer

Chapter 8 HTTP Content Rewrite

8.1 Overview

The HTTP Content Rewrite feature allows end users to visit the HTTP contents on the Web servers behind the FortiBalancer appliance. This feature aims to reduce network latency and improve user experience.

This chapter will cover the theories and configurations of the HTTP Content Rewrite feature.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Reverse Proxy Cache – FortiBalancer

Chapter 7 Reverse Proxy Cache

7.1 Overview

This chapter will cover the concepts and strategies of using the Reverse Proxy Cache to better enhance the overall speed and performance of your Web servers. Using the cache function will improve website performance and throughput, and will also reduce server load by caching heavily requested data in the temporary memory of the FortiBalancer appliance.

7.1 Understanding Reverse Proxy Cache

7.1.1 How Reverse Proxy Cache Works

The Reverse Proxy Cache is located right in front of Web servers. It receives the requests from clients all over the Internet and responds to these requests by working with the Web servers.

 

Figure 7-1 Reverse Proxy Cache Working Mechanism

  1. The client sends a request to the FortiBalancer appliance, requesting for a file on the Web server. The FortiBalancer appliance will forward the request to the cache module for processing.
  2. If the requested content has been cached on the FortiBalancer appliance and the cache does not expire (cache hit), the FortiBalancer appliance will send the file copy to the client directly without forwarding the request to the Web server. If the requested content does not exist in cache (cache miss), the request will be forwarded to the Web server for processing.
  3. The Web server responds to the FortiBalancer appliance with the requested content.
  4. The FortiBalancer appliance responds to the client with the requested content, and caches the content. Future requests for the same content will be responded directly from the FortiBalancer appliance cache module.

The default behavior of the cache is to send the cached object to the client while the cache is being filled with new objects.

The maximum size of the cache objects depends on different system memories of the FortiBalancer appliances. See the table below:

Table 7-1 Max Size of Cache Object

System Memory Max Size of Cache Object
4GB 10240KB (10MB)
8GB 20480KB (20MB)
16GB 40960KB (40MB)

 

7.1.2 Advantages of Reverse Proxy Cache

Compared with traditional cache functions, the Reverse Proxy Cache, without making any compromise on the overall stability and performance, provides a smarter, high-efficient and personalized configuration platform for administrators to more flexibly adjust the FortiBalancer appliances to addressing the demands of different websites. This helps administrators improves the response ability of the websites, reduces the load of Web servers and delivers perfect user experience of visiting the websites.

The Reverse Proxy Cache function is mainly featured with the following advantages: Ø Improved performance

  • The cache function is an independent module in the OS. Turning it off will not impact the functionality of other modules in the system.
  • The cache module strictly controls its memory consumption under 25% of the total system memory.
  • The ability to cache both the compressed and uncompressed contents allows the

FortiBalancer to send compressed contents to appropriate clients without having to involve the compression engine. This greatly enhances compression throughput.

Ø    Outstanding stability

  • If any error occurs to the cache module, administrators can turn off the module immediately, which will not affect the running of other system functions.
  • All cache tuning parameters now use the “cache filter” mechanism, and the global control parameters are reduced. This new approach gives administrators more flexibility and control and minimizes confusion during configuration.

Ø    Intelligent monitoring

Ÿ     The FortiBalancer process monitor also monitors the cache (in addition to the reverse proxy). If it detects any issues (or if the cache process crashes), it will restart the cache after appropriate cleanup.

Ø    Flexible configuration

  • Since the cache is a separate process, it can be updated in place using the “component update” mechanism.
  • The statistics from “show statistics cache” are more detailed and are designed to allow administrators to get data that would help them understand how the FortiBalancer is making caching decisions. This should help the customer tune the FortiBalancer or their website to optimize performance.
  • The “cache filter” mechanism reduces global control parameters, which increases the precision and flexibility of command control by administrators.
  • The cache can now be switched on/off on a per-virtual site basis.

7.1.3 Cacheability of Contents

The HTTP traffic falls into two categories: cacheable contents and non-cacheable contents. The cacheability of contents depends on the information within the HTTP headers. The reverse-proxy cache will check the request and response HTTP headers to make cache decisions. If the response for a request is cached, the subsequent request for the same object will be served from the cache instead of from a backend server.

By default, if there are no HTTP headers that restrict caching for an object, the reverse-proxy cache will cache the content. The following are the more popular cache-control headers that will control if the content will be cached and if so, for how long.

Cache-Control: public

The public keyword indicates that any available and configured cache may store the content. Cache-Control: private

This directive is intended for a single user and will not be cached by the reverse-proxy cache.

Cache-Control: no-cache

This directive lets the reverse-proxy cache know that it can cache the content and can only use the cached content if the appliance first re-validates the content with the origin server.

Expires: Tue, 30 Oct 2010 14:00:00 GMT

This header tells the cache when the content will expire and when to re-fetch it from an origin server when the request for that object is made. In this example it tells the cache to make the content expire on Tuesday, 30 Oct 2010 14:00:00 GMT.

7.1.3.1 Cacheable Contents

Any content with Cache-Control directives which allow caching of the content will always be cached. If the content does not contain a Cache-Control directive, then it will always be cached and will not be re-validated until it is manually flushed from the cache. If the content does not contain an “Expires” header, after it expires, the FortiBalancer appliance will re-validate the content with the origin server and update the content when it is requested next time.

7.1.3.2 Non-Cacheable Contents

Content that has Cache-Control headers which restrict caching of the content will not be cached. Responses to requests with cookies are not served from cache, unless configured by the user to do so.

7.1.4 Cache Filter

The Cache Filter mechanism helps administrators realize more precise control over the cache module with simple cache configurations, such as whether to cache the contents requested by a specific host or not and how long the cached content will live. The priority of the control parameters in cache filter is higher than the peer parameters defined in the Cache-Control header.

The following gives several application examples of cache filter. For detailed configuration examples, refer to the section Reverse Proxy Cache Configuration and the FortiBalancer CLI Reference.

  • Cache all “*.jpg” files from the host “www.xyz.com”, and the TTL of cache contents is 200,000 seconds.
  • Only cache the image files in common formats, such as JPG, GIF or BMP.
  • For the cache objects from the same host, some can be cached by following the cache filter rules, and others can be cached by following the definitions in the cache control header, such as the TTL of the cache.
  • Ignore the specific type of query strings in the request URL when looking up for an object in cache.

7.1.5 Cache Expiration Time

Three types of cache expiration time are involved during the cache process:

  • The expiration time defined by the “Expires” field in the HTTP header;
  • The global cache expiration time configured via the command “cache settings expire {hh:mm:ss|seconds}”;
  • The TTL time specified by the “ttl” parameter in the command “cache filter rule <host_name> <url> {cache|urlquery|ttl}”.

The priorities of the three expiration times are as follows:

  1. The expiration time configured in “cache filter rule” will be used first.
  2. If the “ttl” parameter is not specified, the global expiration time specified by “cache settings expire” command will apply.
  3. For the cache content that does not match any cache filter rule, the expiration time defined in the HTTP header will be applied.
  4. If no “Expires” field is available in the HTTP header to define the expiration time, just follow the configuration of “cache settings expire”.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!