Tag Archives: fortibalancer administrators guide

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

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.
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.
The Web server responds to the FortiBalancer appliance with the requested content.
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:

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

Pages: 1 2

Server Load Balancing – FortiBalancer

Leave a reply

Chapter 6 Server Load Balancing (SLB)

6.1 Overview

SLB (Server Load Balancing) allows you to distribute load and traffic to specific groups of servers or to a specific server. The FortiBalancer appliance supports server load balancing in Layers 2-7 of the OSI network model. Layer 2 SLB is based on network interfaces. Layer 3 SLB works on IP addresses. Layer 4 SLB is mostly concerned with port based load balancing. Layer 7 is used when you want to perform load balancing based on URLs, HTTP headers or Cookies. The basic steps for setting up SLB are:

Define the real servers.
Define a group load balancing method.
Add real servers to the group.
Define a Virtual IP to listen for requests.
Bind the group balancing method to the Virtual IP.

The real server, the VIP and the virtual service are the fundamental components of SLB deployment.

The real server is an application server hosting varied applications or services. It processes the requests from the client side.
The VIP in general is a public IP address that can be accessed from the external clients. As an entrance, it receives and forwards external requests, and sends the processed results from the real servers back to the client side.
For the Layer 4 and Layer 7 SLB, the virtual service is commonly represented with a VIP/port pair and can be accessed by the external clients to get their target network resources. For example, if a client wants to access some Web resources by a predefined VIP or a Web site name (with DNS), all the requests from this client will go through the VIP and be sent out to different real servers by the FortiBalancer appliance hosting the VIP and real servers. With the virtual service, the internal network architecture and backend real servers are hidden from the external clients by only exposing the VIP address.

The remainder of this chapter will cover these steps and cover some examples of Layer 2, Layer 3, Layer 4 and Layer 7 load balancing strategies.

This following figure is a logical overview of load balancing using the FortiBalancer appliance.

Figure 6-1 SLB Architecture

Pages: 1 2 3 4 5 6 7 8

Clustering – FortiBalancer

Leave a reply

Chapter 4 Clustering

4.1 Overview

The clustering function allows you to maintain high availability within a local site. With other options you can also distribute load across multiple boxes within a cluster.

4.2 Understanding Clustering

The Clustering function allows two or more FortiBalancer appliances to be grouped together to form a logical device, which provides scalability and high availability within a local site. Please refer to the following figure.

Figure 4-1 FortiBalancer Clustering

Clustering can be configured in Active-Standby (A/S) or Active-Active (A/A) mode:

Active-Standby mode – In Active-Standby mode, all VIPs on one FortiBalancer appliance in the cluster will be the master, and all VIPs on the other FortiBalancer appliances in the cluster are standby. In this mode, clustering supports fast failover.

Active-Active mode – In Active-Active mode, each FortiBalancer appliance in the cluster has a different master VIP or cluster ID.

4.2.1 Fast Failover

The Fast Failover (FFO) mechanism uses a new additional serial port (fast failover port on the FortiBalancer appliance mother board) to detect each other’s status transparently in a cluster (refer to the following figure). When one system powers off, panics, reboots or its interface losses carrier (link disconnection), all the traffic will be immediately switched to the other. The Clustering function with fast failover mechanism provides higher availability and much faster response time than the typical Clustering.

Figure 4-2 Clustering FFO Mode

4.2.2 Discreet Backup Mode

For traditional clustering, a backup and a master communicate each other’s state information through the network. If the backup does not receive the VRRP (Virtual Router Redundancy Protocol) multicast packets from the master within a specified time, it will mandatorily preempt the master. However, because of the network complexity, when something totally unexpected happens, this way may lead to a double-master state.

Discreet Backup mode is designed to prevent a double-master state. In this mode, the system determines whether a state transition is needed for the devices based on their state information detected by a heartbeat cable. This mode makes the state transition more reliable, and any VRRP packet loss will not result in double-master state.

The following shows how the Discreet Backup mode works.

Figure 4-3 Discreet Backup Mode Working Mechanism

After turning on clustering, the device enters into Init state. Then, in order to check the health of the heartbeat cable, the Init device switches to FFO state.
The device collected the health information of the heartbeat cable. If the heartbeat cable is well connected, it will switch to Backup state.
Note: Even though the heartbeat cable is disconnected, the device will still switch to Backup state, and clustering will work well. However, the discreet mode is invalid.
If the backup receives a higher priority VRRP packet, it will switch to Discreet Backup state.
In the following events, the discreet backup will switch to Backup state:
The device in Discreet Backup state receives a lower priority VRRP packet (after the successful state transition, the backup will go on to switch to Master state.).
The device in Discreet Backup state will check the heartbeat cable health. If the heartbeat cable is disconnected, it will log out to Backup state.
In the following events, the backup will switch to Master state:
The backup receives a lower priority VRRP packet (in Preemption mode).
In three continuous broadcast intervals (the default interval is 5 seconds, three intervals are 15 seconds), the backup does not receive the VRRP packet from the master.
If the master receives a higher priority VRRP packet, it will switch to Backup state.
If the heartbeat cable detected the master’s NIC is down, the discreet backup will switch to Master state directly.

Note: All cluster state transitions can be traced by the command “show cluster virtual transition”.

By default, discreet backup mode is turned off.

To configure the discreet backup mode, the following two commands MUST be configured first to turn on the discreet backup mode.

FortiBalancer(config)#cluster virtual ffo on

FortiBalancer(config)#cluster virtual discreet on

4.2.3 IPv6 Support for Clustering

The FortiBalancer Clustering function now supports IPv6 VIPs switchover. Both IPv4 and IPv6-based VRRP packets can be processed by the FortiBalancer appliance.

If the interface for Clustering is configured with both the IPv4 and IPv6 addresses or with only the

IPv4 address, then the IPv4-based VRRP packets will be used for communication between the FortiBalancer appliances. If only the IPv6 address is configured on the interface for Clustering, then the IPv6-based VRRP packets will be used.

Note: The VRRP packets are incompatible with each other among different OS versions. So please use the same OS version for the FortiBalancer appliances in a cluster.

4.3 Clustering Configuration

4.3.1 Clustering SLB VIPs

When using the clustering capabilities of the FortiBalancer appliance, we will first define our SLB virtual IPs that we want to use in the cluster. Each of the following sections will define the virtual IPs that we will use.

For information about SLB, please refer to the chapter Server Load Balancing (SLB).

4.3.1.1 Active-Standby: Two Nodes

Configuration Guidelines

In Active-Standby mode, one node in the cluster will be the master of the VIP, and thus active. The other node in the cluster will be in standby mode. Upon failure of the active node, the standby node will take over the VIP and become master. If preemption has been enabled on the initial master node, it will reassume mastership when it returns to a working state. Otherwise, the VIP will stay with the new master node until the node fails.

Refer to the following figure for the typical layout of Active-Standby architecture, in which:

FortiBalancer1 is the current master, and handles SLB traffic for VIP.
FortiBalancer2 is the backup, and listens for advertisements from the master. It will resume master status if FortiBalancer1 stops sending advertisements (i.e. FortiBalancer1 fails).

Figure 4-4 Active-Standby Two-Node Architecture

Table 4-1 General Settings of Active-Standby Two-Node Clustering

Operation	Command
Configure SLB	Refer to the SLB Configuration section.
Configure a virtual interface	cluster virtual ifname <interface_name> <cluster_id>
Configure virtual cluster authentication	cluster virtual auth <interface_name> <cluster_id> {0\|1} [password]
Configure preemption	cluster virtual preempt <interface_name> <cluster_id> <mode>
Configure virtual IP	cluster virtual vip <interface_name> <cluster_id> <vip>
Configure priority	cluster virtual priority <interface_name> <cluster_id> <priority> [synconfig_peer_name]
Enable the virtual cluster	cluster virtual {on\|off} [cluster_id\|0] [interface_name]
Enable fast failover feature	cluster virtual ffo {on\|off} cluster virtual ffo interface carrier loss timeout <interface_timeout>

Configuration Example for Active-Standby SLB Clustering via CLI Now let’s start to configure FortiBalancer1 and FortiBalancer2:

Ø Step 1 Configure SLB for both FortiBalancer1 and FortiBalancer2

FortiBalancer1(config)#slb real http “server1” 192.168.1.50 80 1000 tcp 1 1

FortiBalancer1(config)#slb real http “server2” 192.168.1.51 80 1000 tcp 1 1

FortiBalancer1(config)#slb group method “group1” rr

FortiBalancer1(config)#slb group member “group1” “server1” 1

FortiBalancer1(config)#slb group member “group1” “server2” 1

FortiBalancer1(config)#slb virtual http “vip1” 192.168.2.100 80

FortiBalancer1(config)#slb policy default “vip1” “group1”

FortiBalancer2(config)#slb real http “server1” 192.168.1.50 80 1000 tcp 1 1 FortiBalancer2(config)#slb real http “server2” 192.168.1.51 80 1000 tcp 1 1

FortiBalancer2(config)#slb group method “group1” rr

FortiBalancer2(config)#slb group member “group1” “server1” 1

FortiBalancer2(config)#slb group member “group1” “server2” 1

FortiBalancer2(config)#slb virtual http “vip1” 192.168.2.100 80

FortiBalancer2(config)#slb policy default “vip1” “group1”

Step 2 Configure a virtual interface name

FortiBalancer1(config)#cluster virtual ifname “port1” 100

FortiBalancer2(config)#cluster virtual ifname “port1” 100

Step 3 Configure virtual cluster authentication

It is recommended that you run clustering with an authentication string to avoid unauthorized participation in your cluster.

FortiBalancer1(config)#cluster virtual auth port1 100 0

FortiBalancer2(config)#cluster virtual auth port1 100 0

Step 4 Configure virtual cluster preemption

Now we configure FortiBalancer1 to preempt the VIP when the initial master returns online. For FortiBalancer2, it will not preempt the VIP from the master node, but will take over if the master ceases operations.

FortiBalancer1(config)#cluster virtual preempt port1 100 1

FortiBalancer2(config)#cluster virtual preempt port1 100 0

Step 5 Define the VIP by the “cluster virtual vip” command

FortiBalancer1(config)#cluster virtual vip “port1” 100 192.168.2.100 FortiBalancer2(config)#cluster virtual vip “port1” 100 192.168.2.100

Step 6 Define the priority

Cluster priority determines which node becomes the master. The node with highest priority becomes the master. Since we want FortiBalancer1 to always be master of the VIP, we will set its priority to 255. For FortiBalancer2, we will leave its priority at 100. In a two-node cluster, this is permissible. Though, when you include more nodes in your cluster, you will need to set a unique priority for each VIP to properly communicate and fail-over. To do this, use the following command:

FortiBalancer1(config)#cluster virtual priority port1 100 255 FortiBalancer2(config)#cluster virtual priority port1 100 100

Note: The state is the backup on FortiBalancer2. This is expected since it is of lower priority than the master.

Step 7 Turn on the clustering

FortiBalancer1(config)#cluster virtual on

FortiBalancer2(config)#cluster virtual on

Step 8 Turn on fast failover

FortiBalancer1(config)#cluster virtual ffo on

FortiBalancer1(config)#cluster virtual ffo interface carrier loss timeout 1000

FortiBalancer2(config)#cluster virtual ffo on

FortiBalancer2(config)#cluster virtual ffo interface carrier loss timeout 1000

Pages: 1 2

Link Aggregation – FortiBalancer

Leave a reply

Chapter 3 Link Aggregation

3.1 Overview

This section describes link aggregation functionality of the network. Link Aggregation is also called trunking, which can greatly improve network performance and stability.

3.2 Understanding Link Aggregation

Link Aggregation or trunking is a method of combining physical network links into a single logical link for increased bandwidth. With Link Aggregation, we are able to increase the capacity and availability of the communication channel between devices. Two or more Gigabit Ethernet connections are combined in order to increase the bandwidth capability and create resilient and redundant links.

The FortiBalancer appliance supports at most 6 bond interfaces, and at most 12 system interfaces can be added to a bond interface. The bond interface will check the status of the system interfaces. If a system interface becomes down, the traffic processed by this interface will be directed to other working system interfaces in the bond interface.

To add a system interface into a bond interface, the administrator can further set the interface as the primary or backup interface in the bond. Multiple primary or backup interfaces can be set in a bond. When all the primary interfaces in the bond fail, the backup interfaces will take the place of primary interfaces to work.

Note: To bind a system interface with a bond interface, the system interface should be configured with no IP address information. If there is IP configuration on the system interface, the administrator needs to remove the IP configuration first. If otherwise, the system will refuse to add the system interface into the bond.

In addition, the FortiBalancer appliance also supports configuring MNET or VLAN on bond interface. The bond interface configuration must be performed before configuring MNET or VLAN on it.

3.3 Link Aggregation Configuration

3.3.1 Configuration Guidelines

Before you start to configure link aggregation, please take a moment to familiarize yourself with the network architecture for link aggregation configuration.

Figure 3-1 Link Aggregation Configuration

Table 3-1 General Settings of Link Aggregation

Operation	Command
Bond system interfaces	bond interface <bond_name> <interface_name> [1\|0]
Operation	Command
Assign a name for the bond interface	bond name <bond_id> <bond_name>
Assign IP address to the bond interface	ip address {system_ifname\|mnet_ifname\|vlan_ifname\|bond_ifname} <ip_address> {netmask\|prefix}
Assign default route	ip route default <gateway_ip>

3.3.2 Configuration Example via CLI

Step 1 Bind system interfaces with bond interface

In our example, we bind the “port1” interface and the “port4” interface with the bond interface bond1, and further set the “port1” interface as the primary, and “port4” as the backup in the bond interface.

FortiBalancer(config)#bond interface bond1 port1 1

FortiBalancer(config)#bond interface bond1 port4 0

Step 2 Assign a name for the bond interface

We can set the bond name for the configured bond interface by using the “bond name” command.

FortiBalancer(config)#bond name bond1 link1

Step 3 Assign an IP address and netmask to the bond interface

FortiBalancer(config)#ip address link1 10.10.0.2 255.255.255.0

Step 4 Set the gateway IP address

FortiBalancer(config)#ip route default 10.10.0.1

To verify that FortiBalancer appliance is indeed actively deployed within this network infrastructure, you may ping the gateway IP by using the “ping” command.

If these configurations are entered correctly, you will receive the following return messages.

FortiBalancer(config)#ping 10.10.0.1

PING 10.10.0.1(10.10.0.1): 56 data bytes

64 bytes from 10.10.0.1: icmp_seq=0 ttl=128 time=0.671 ms

64 bytes from 10.10.0.1: icmp_seq=1 ttl=128 time=0.580 ms

64 bytes from 10.10.0.1: icmp_seq=2 ttl=128 time=0.529 ms

64 bytes from 10.10.0.1: icmp_seq=3 ttl=128 time=0.486 ms

64 bytes from 10.10.0.1: icmp_seq=4 ttl=128 time=0.638 ms

— 10.10.0.1 ping statistics —

5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.486/0.581/0.671/0.068 ms

Initial System Setup & Configuration – FortiBalancer

Leave a reply

Chapter 1 Initial System Setup & Configuration

1.1 Overview

This section will outline the initial connection, basic setup and configuration of the FortiBalancer appliance. The easy to follow setup steps are introduced below.

1.1.1 Connecting to FortiBalancer

There are three ways to connect to the FortiBalancer appliance in order to begin the configuration:

Console (recommended)
SSH
Web UI

1.1.1.1 Console Connection

If you choose the console connection, first connect the console cable (supplied) to the System Console Port on the FortiBalancer appliance, and then set up your console as follows:

Table 1-1 Console Setup

Setting	Value
Emulation	VT 100
Baud	9600
Number of Bits	8
Parity	No
Stop Bits	1
Flow Control	No

Open a connection between the console and the FortiBalancer appliance. Once this connection is opened, users will see the FortiBalancer appliance prompt and may begin the configuration process.

1.1.1.2 SSH Connection

Once the IP parameters are configured and the SSH service is activated, the FortiBalancer appliance is prepared for custom configuration. You may access the command line interface (CLI) using SSH connection. Below gives an example.

Note: If you require SSH software for Windows, Mac OS X or UNIX, it is available on-line at http://www.openssh.com.

To establish an SSH connection:

Step 1 Run the SSH program on your workstation

>> # ssh admin@10.3.55.251

10.3.55.251 is the FortiBalancer appliance’s IP address.

Step 2 After you establish a connection, the FortiBalancer appliance will ask you for a privilege password.

>> # ssh admin@10.3.55.251 >> # admin@10.3.55.251’s password:

Upon the first startup, the user will be prompted for login username and password. The default username is “admin”, and the default password is “admin”.

Note: You must have the IP information setup and basic network connectivity in order to access the box through SSH.

1.1.1.3 Web UI Connection

This section introduces the connection method via FortiBalancer web UI (Web User Interface). The FortiBalancer web UI can:

Improve user experience with fast response time
Maximize the functionality and performance of the FortiBalancer appliance
Simplify system management

If administrators want to take full advantage of the Web UI access to the FortiBalancer appliance, please first assign a valid and unique IP address and a port number to the web UI. For example:

FortiBalancer(config)#webui ip 10.10.0.2

FortiBalancer(config)#webui port 8888

On the FortiBalancer appliance, we use port1’s IP address as the default web UI IP address and the port 8888 as the default web UI port.

Then, turn on the web UI function:

FortiBalancer(config)#webui on

Now open your browser of choice and connect to the FortiBalancer appliance. To do this, simply type in the address bar as such:

https://10.10.0.2:8888

And now press “Enter”. The welcome screen should appear in your browser’s window, protected by the familiar prompt asking for user name and password. The default username and password is admin and admin, just as before. If this screen does not appear, verify the address and port designations for both the port1 interface and web UI port.

The FortiBalancer appliance web UI supports the following browsers:

IE (Recommended)

Firefox

Chrome

Browser resolution should be set to 1024×786 or higher.

1.1.2 Reading the LED

1.1.2.1 LEDs in the Front Panel

The FortiBalancer appliance possesses three LEDs in the front panel: one yellow, one green and one blue. The following is the usage description of each LED in the front panel.

Table 1-2 LEDs in the Front Panel

Color	Meaning	Description
Yellow	Fault	This light is always off when FortiBalancer appliance keeps normal. It means the following problems have come out if this light turns on: The CPU fan stops working.
Color	Meaning	Description
		The CPU is overheated (equal to or over 85℃). The system is overheated (equal to or over 75℃ on 1U appliances, or 85℃ on 2U appliances). One of the power supply modules breaks down (If the FortiBalancer appliance supports the dual power supply), the redundant power supply will turn on the Buzzer at the same time.
Green	Run	The green LED should blink each second when system is idle. CPU activity will be indicated by the blinking of this light; the faster the rate, the higher the CPU activity.
Blue	Power	Indication of power and the active state (off\|on) of the FortiBalancer appliance.

Note: If the yellow LED is lighted, please contact Customer Support. You can view system logs to get more information about the problem.

1.1.2.2 LEDs in the Rear Panel

The FortiBalancer appliance provides two LEDs for every Ethernet port in the rear panel:

Link LED: indicates the speed mode of the link, which can be 1 Gbps, 10 Mbps or 100 Mbps.
Activity LED: indicates the activity status of the network port.

The following table describes the meaning of each LED on the onboard and add-on NICs of the FortiBalancer appliance.

Table 1-3 LED for Ethernet Ports in Rear Panel

NIC Type	LED Name	Description
Onboard NIC	Link LED	The Link LED has the following indicator colors: Amber: The speed mode is 1 Gbps. Green: The speed mode is 100 Mbps. Off: No Connection or the speed mode is 10 Mbps.
Onboard NIC	Activity LED	The Activity LED has the following indicator colors: Yellow and blinking: Active Off: Inactive
Add-on NIC	Link LED	The Link LED has the Yellow indicator color, indicating 1 Gbps, 10 Mbps or 100 Mbps speed mode.
Add-on NIC	Activity LED	The Activity LED has the following indicator colors: Green and blinking: Active Off: Inactive

1.1.3 Command Line Interface Structure

In this section, you will be provided an overview of the Command Line Interface (CLI) covering the following topics:

Command Usage Breakdown
Levels of Access Control

1.1.3.1 Command Usage Breakdown

The CLI allows you to configure and control key functions of the FortiBalancer appliance to better manage the performance of your servers and the accessibility to the contents therein.

The FortiBalancer appliance software has been designed with specific enhancements to make interaction with the Appliance more user friendly, such as Shorthand. Shorthand is the intuitive method by which the Appliance completes CLI commands based on the first letters entered. Other user shortcuts are listed below:

Table 1-4 List of Shortcuts

CLI Shortcuts	Operation
^a/^e	Move the cursor to the beginning/end of a line.
^f/^b	Move the cursor forward/backward one character.
Esc-f	Move the cursor forward one word.
Esc-b	Move the cursor backward one word.
^d	Delete the character under the cursor.
^k	Delete from the cursor to the end of the line.
^u	Delete the entire line.

Note: The symbol “^” indicates holding down the Control (Ctrl) Key while pressing the letter that appears after the symbol.

The FortiBalancer CLI commands will generally adhere to the following style conventions: Table 1-5 FortiBalancer CLI Style Conventions

Style	Convention
Bold	The body of a CLI command is in Boldface.
Italic	CLI parameters are in Italic.
< >	Parameters in angle brackets < > are required.
[ ]	Parameters in square brackets [ ] are optional. Subcommand such as “no”, “show” and “clear” commands.
{x\|y\|…}	Alternative items are grouped in braces and separated by vertical bars. At least one should be selected.
[x\|y\|…]	Optional alternative items are grouped in square brackets and separated by vertical bars. One or none is selected.

For example:

ip address {system_ifname|mnet_ifname|vlan_ifname|bond_ifname} <ip_address> {netmask|prefix}

Note: If a string we input for configuring a parameter starts with figure, or the string contains spaces, we must put the configuration string within double quotes to make sure that we can configure the command correctly.

1.1.3.2 Levels of Access Control

The FortiBalancer appliance’s Command Line Interface offers three levels of configuration and access to the OS. The CLI prompt of each level consists of the host name of the FortiBalancer appliance followed by a unique cursor prompt, either “>”, “#” or “(config)#”.

The first level is for basic network troubleshooting and is called the User level. At this level, the user is only authorized to operate some very basic commands and non-critical functions such as ping and traceroute. Here is how the User level prompt appears in the CLI.

FortiBalancer>

The second level of administration is the Enable level. Users at this level have access to a majority of view only commands such as “show version”. Users in the Enable level may execute commands from both the User and Enable levels. In order to gain access to this level of appliance management, the user must employ the command “enable”. Once this command is entered, the FortiBalancer appliance prompts the user for the appropriate password. If correct password is entered, the CLI prompt will change from “FortiBalancer>” to “FortiBalancer#”, which means the user is granted access to the Enable level. The default password for the Enable level is null, i.e. users simply need to press “Enter”.

FortiBalancer>enable Enable password:

FortiBalancer#

The final access level is the Config level. It is with this level of authority that the user can make changes to the configuration of the box. No two users can access the Config level at the same time. Once a user has gained access to this level, he or she can implement commands in all three levels. To gain access to the full configurable functions of the FortiBalancer appliance, the user must use the following command:

FortiBalancer#config terminal

Once this command is entered, the CLI prompt will change to:

FortiBalancer(config)#

In the event that Config level is not available because another Config level session has been opened, the administrator can deploy the following command to gain access to the Config level:

FortiBalancer#config terminal force

WARNING:

You are forcing other user to exit configuration mode.

In case the other user is actively changing the system configuration, the result may be unpredictable.

Do you still want to force into Configuration Mode “YES” or “NO”:

Type “YES” and press “Enter”. You will enter the Config level successfully.

For each level the user can type “?” for available commands. For example, entering

“FortiBalancer(config)#slb real ?” will prompt users with all the possible parameters or protocols the CLI will accept with the “slb real” command.

FortiBalancer(config)#slb real ? [enter]

activation Recovery and warm-up time of real service disable Remove real service from load balancing dns Define SLB DNS real service enable Activate real service for load balancing ftp Define SLB FTP real service

Pages: 1 2