Category Archives: FortiBalancer

System Management – FortiBalancer

Chapter 19 System Management

19.1 Administrative Tools

19.1.1 Overview

This chapter will focus on various configuration maintenance elements, such as downloading new OS software, rebooting your FortiBalancer appliance, reverting your configuration to a previously saved status or returning the FortiBalancer appliance to its factory default settings among other closing strategies.

The final series of configuration options concern the running operation of your FortiBalancer appliance and its relationship with the rest of the network architecture. Through the various subfolders (within the web UI) that are revealed once you click on the “Admin Tools” folder you will discover a series of sub-folders allowing you to set administrative passwords, perform configuration synchronization, set SNMP traps and define reboot strategies among other operations. Otherwise all of these features may be configured via the CLI.

19.1.2 Administrative Tools Configuration

19.1.2.1 Configuration Guidelines

Table 19-1 General Settings of Administrative Tools

Operation	Command
Configuring External Authentication	admin aaa {on\|off} admin aaa method [radius\|tac_x] admin aaa server <server_id> <host_name\|ip_address> <port> <secret>
System shutdown and reboot	system shutdown [halt\|poweroff] system reboot [interactive\|noninteractive]
Configuration file maintenance	clear config file clear config secondary clear config primary clear config all clear config factorydefault clear config timeout write memory write file <file_name> write net tftp <ip_tftp> <file_name> write net scp {remote_server_ip\|name} <user_name> <config_file_name> config memory config net tftp <tftp_server_ip> <config_file_name> config file <file_name>
Software upgrade	system update <url>
Configuration Synchronization	synconfig peer <peer_name> <peer_ip> synconfig to <name> synconfig from <name>
SDNS Synchronization	synconfig sdns peer <peer_name> <peer_ip> synconfig sdns to <peer_name>
Monitoring	graph name <new_name> graph rename <old_name> <new_name> graph settings displaymode {nostack\|stack} <graph_name> graph item <graph_name> <module_name> <type> [service] <scale> <color> [order] [legend_string]
NTP	ntp {on\|off} ntp server <ip> [version]
Operation	Command
	show ntp clear ntp
XML RPC	xmlrpc {on\|off} [https\|http] xmlrpc port <port> show xmlrpc clear xmlrpc
Remote access	ssh remote “user@hostname” telnet “host port”

19.1.2.2 Configuration Example via CLI

19.1.2.2.1 Configuring External Authentication

If you have an external authentication server (RADIUS/Tacacs), you may use these servers to authenticate the SSH/web UI logon request. The external authentication will be performed when the “admin aaa” command is set to ON and the logon user name does not exist in the FortiBalancer system.

FortiBalancer(config)#admin aaa on

FortiBalancer(config)#admin aaa method RADIUS

FortiBalancer(config)#admin aaa server es01 “10.1.1.1” 1812 radiussecret

FortiBalancer(config)#admin aaa server es02 radius_host 1812 radiussecret

19.1.2.2.2 System Maintenance

Simply enough, employing the “quit” command will allow you to exit the CLI. In the event you want to terminate all FortiBalancer appliance interactions with your network, you will need to use the “system shutdown” command.

FortiBalancer(config)#system shutdown

The FortiBalancer appliance will prompt you with an alert to verify the shutting down process. By entering “YES”, case sensitive, the FortiBalancer appliance will commence the shutting down operation. After a brief, 60-second period, users may turn off the appliance.

In some cases when dealing with configuration changes you might need to reboot the box.

FortiBalancer(config)#system reboot

19.1.2.2.3 Configuration File Maintenance

When working with configurations there may come a time that you want to experiment with a new configuration strategy, but not overwrite your known working configuration. The OS possesses several options for working with configurations files.

In general, you work with the running configuration and write it to disk by using the “write memory” command. You can also save the configuration to a file by using the “config file” command, on the FortiBalancer appliance. Finally, you may export and import the configuration by using TFTP.

To clear the running configuration on the FortiBalancer appliance:

FortiBalancer(config)#clear config all

Now the FortiBalancer appliance has been returned to its factory default settings.

When working with the “write memory” command, keep in mind that this is the configuration file that will be loaded when the FortiBalancer reboots. If you have made changes and want to clear the configuration currently running, use the “clear config” command.

At any point when you want to import a previously saved configuration, you will need to clear the current, running configuration as previously discussed in this chapter. Once this is completed, you can import the new configuration. The FortiBalancer appliance affords you the opportunity to save configurations to three separate places; the “memory” file which is where the FortiBalancer appliance calls up configuration settings upon reboot, the “file” where the FortiBalancer appliance can store several different configurations, and to the “net” which refers to saving a file to a remote location on the network. To save configuration files:

FortiBalancer(config)#write net tftp 10.10.0.3 default_config

To recall a previously saved configuration and merge it into the running parameters of the appliance:

FortiBalancer(config)#config memory

FortiBalancer(config)#config file new_lb

FortiBalancer(config)#config net tftp 10.10.0.3 default_config

When loading the configuration file while the box is running, it is important to remember that the configuration is merged with the running configuration. So you need to choose to clear the appropriate configuration from the FortiBalancer appliance before you load a configuration file. For example, if you have 5 real servers defined and execute the “config net tftp 10.10.0.3 default_config” command and if that configuration file has 5 real servers using the same real names you will get an error since you cannot have duplicate real server names.

19.1.2.2.4 Software Upgrade Procedure

To see the current version of OS software that is running, we use the “show version” command.

FortiBalancer(config)#show version

FortiBalancerOS Rel.TM.8.4.0.1 build on Mon Mar 18 18:12:09 2013

Host name : FortiBalancer

System CPU : Intel(R) Core(TM)2 Quad CPU System RAM : 3842964 kbytes.

System boot time : Mon Mar 18 19:10:19 GMT (+0000) 2013

Current time : Tue Mar 19 19:54:09 GMT (+0000) 2013

System up time : 1 day, 00:44

Platform Bld Date : Mon Mar 18 18:12:09 CST 2013 SSL HW : HW ( 1X16C ) Initialized

Compression HW : No HW Available

Power supply : 2U, AC, 2-cords, Redundancy

Network Interface : 4 x Gigabit Ethernet copper

Model : FortiBalancer 2000

Serial Number : 0437A3345200010003011044316464

Licensed Features : WebWall Clustering L4SLB L7SLB Caching

SSL tProxy AppGateway SwCompression LLB GSLB

QoS MultiLang DynRoute FFO REDUNDANT IPv6

License Key : f1bd6e06-d29016c1-c053e5eb-00d27cb7-d3f75a85-00000000-05d5d9

ab-99999999

Fortinet Customer Support

Update : please contact support for instructions

Website : http://www.fortinet.com

Other Root

Version

Rel.FBLOS.8.3.2.3 build on Fri Feb 22 17:35:11 2013

To upgrade to a newer release there are several steps to take.

First, contact Customer Support to gain access to the software and documentation repository.

Contact your customer support representative or send email to: support@fortinet.com

Once you have received a password and verified with a customer support engineer that the OS needs upgrade, you can download the software image using the Fortinet website. You should download the image to either a local Web server or anonymous FTP server.

It is recommended that you use the serial console to upgrade the OS. Once you have a console connection you can upgrade the appliance by using the “system update” command. Currently the upgrade procedure supports two upgrade methods: HTTP or FTP. The commands are identical except from the URL.

For example, use the command to upgrade the appliance from 192.168.10.10:

FortiBalancer(config)#system update http://192.168.10.10/FortiOS_rel_FBL_8_4_0_1.fn

This will upgrade your system from http://192.168.10.10/ FortiOS_rel_FBL_8_4_0_1.fn Power outages or other systems failures may corrupt the system. It is highly recommended that you save your configuration on an external system prior to upgrading or downgrading.

Any configuration changes that have not been “saved” will be lost. After a successful patch the system will be rebooted. Fortinet, Inc.

Type “YES” to confirm upgrade: YES

Note: If you are to use a DNS name like: system-update http://s5.sj.example.com, make sure that you have correctly setup the resolving on the FortiBalancer appliance, using the “ip nameserver” command to define your DNS server for the “s5” host or use the “ip host” command to locally define the IP address of the “s5” host. Otherwise you will get an error when you try to download the software image.

The OS will then shutdown all load balancing features and download the software image, verify that the software is produced at Fortinet and then install it. If there is any problem with the software image, the CLI will abort the upgrade and display a prompt on the screen. Otherwise you should get a prompt on the console stating that the upgrade was successful and the FortiBalancer appliance will reboot. Upon reboot, you should use the “show version” command to verify that the upgrade is successful.

Caution:

If executing this command via an SSH connection and if the connection is lost during update procedure, the FortiBalancer appliance will not be able to complete the update process.
Do not disconnect the connections to the FortiBalancer appliance during the system updating process.

Software Licenses

Some software features of the FortiBalancer appliance may be under software license key control. If you need these software features, please contact customer support (https://support.fortinet.com ) to obtain a new license key.

19.1.2.2.5 Configuration Synchronization

The Configuration Synchronization feature of the FortiBalancer appliance allows administrators to transfer configuration information among FortiBalancer appliances within the same network. Configuration Synchronization is a set of commands that allow you to manage and configure boxes within a network. You may transfer configuration information from one FortiBalancer appliance in a network to other FortiBalancer appliances within the same network. By using configuration synchronization, you can quickly setup an Active-Standby configuration. The rest of the section will cover how to use this feature.

Note: Synconfig commands are executed via SSH, therefore SSH must be enabled.

Step 1 Configure configuration synchronization on FortiBalancer1

FortiBalancer1(config)#synconfig peer FortiBalancer1 192.168.1.1 FortiBalancer1(config)#synconfig to FortiBalancer2

Step 2 Configure configuration synchronization on FortiBalancer2

FortiBalancer2(config)#synconfig peer FortiBalancer1 192.168.1.1

FortiBalancer2(config)#synconfig peer FortiBalancer2 192.168.1.2

FortiBalancer2(config)#synconfig from FortiBalancer1

Note: If WebWall is turned on for the interface which the “synconfig” command uses to synchronize with peer, you need to add the corresponding accesslist rules to allow the traffic to come in through SSH port 22 on both FortiBalancer machines (FortiBalancer appliance and the sync peer).

19.1.2.2.6 SDNS Configuration Synchronization

Administrators can synchronize SDNS configurations and BIND9 zone files except SDNS member configurations from a local FortiBalancer appliance to remote peers.

In the following example, SDNS configurations and BIND9 zone files except SDNS member configurations on FortiBalancer1 are synchronized to remote FortiBalancer2. Ø Step 1 Configure SDNS configuration synchronization on FortiBalancer1

FortiBalancer1(config)#synconfig sdns peer peerlocal 172.16.83.180

FortiBalancer1(config)#synconfig sdns peer peerremote 172.16.83.120

Step 2 Start SDNS configuration synchronization from FortiBalancer1 to FortiBalancer2

FortiBalancer1(config)#synconfig sdns to peerremote

19.1.2.2.7 Monitoring

The FortiBalancer appliance allows the administrator to view a wide range of pertinent network data through a series of pre-designed and custom (administrator defined) graphs.

Step 1 Establish custom graph items

FortiBalancer(config)#graph name aa

FortiBalancer(config)#graph rename aa bb

FortiBalancer(config)#graph settings displaymode stack bb

FortiBalancer(config)#graph item bb “System” “CPU Utilization” “1” “red” “2”

19.1.2.2.8 Component Update

Component update allows for the update of many components on the FortiBalancer appliances without requiring a reboot. The effect of the component update is instantaneous. Any number of component patches can be applied to the FortiBalancer appliances. However, only the most recent component update can be reverted. The list of patches applied using component update is visible in the output of “show version” command.

Component patches can only be generated by Fortinet. These are in the same “.click” format as the regular OS updates, but they are much smaller in size.

19.1.2.2.9 NTP Time Synchronizer

The Network Time Protocol (NTP) time synchronizer enables the FortiBalancer appliance to synchronize the system time with the specified NTP server.

After the NTP time synchronizer is enabled, the FortiBalancer appliance will automatically synchronize the system time with the specified NTP server at the interval of about 15 minutes.

Attention:

It is recommended that you change the time difference between the system time of the FortiBalancer appliance and the time of the NTP server to less than 1000s before enabling the NTP time synchronizer.
Do not change the system time of the FortiBalancer appliance after enabling the NTP time synchronizer.

FortiBalancer appliance should be used as the NTP client rather than the NTP server.

If multiple NTP servers are configured, the FortiBalancer appliance will calculate the round-trip delays according to the time information in the response packet from each NTP server, and synchronize its system time with the NTP server with the minimum delay. Ø Step 1 Configure an NTP server

FortiBalancer1(config)#ntp server 207.46.197.32 4

Ø Step 2 Turn on NTP time synchronizer

FortiBalancer1(config)#ntp on

Users also can use the command “show ntp” to view the current NTP configuration.

FortiBalancer1(config)#show ntp ntp server 207.46.197.32 4 ntp on

time since restart: 1481 time since reset: 1481 packets received: 21 packets processed: 0 current version: 0 previous version: 0 bad version: 0 access denied: 0 bad length or format: 0 bad authentication: 0 rate exceeded: 0

The following explains the items in the output information:

Time since restart: The time in hours since the system was last rebooted.

Time since reset: The time since the statistics were reset and the system statistics monitoring file was updated. This is designed for busy servers, such as those operated by NIST, USNO, and intended as early warning detector of clogging attacks.

Packets received:	The total number of packets received.
Packets processed:	The number of packets received in response to previous packets sent.
Current version:	The number of packets matching the current NTP version.
Previous version:	The number of packets matching the previous NTP version.
Bad version:	The number of packets matching neither NTP version.

Access denied: The number of packets denied access for any reason.

Bad length or format: The number of packets with invalid length, format or port number.

Bad authentication: The number of packets not verified as authentic.

Rate exceeded: The number of packets discarded due to rate limitation.

19.1.2.2.10 XML RPC

XML RPC allows clients to run some CLI commands remotely in the OS. This enables system programmers to automate remote configuration which is difficult with web UI.

XML RPC is a Remote Procedure Calling protocol that works over the Internet, which uses HTTP as a transport mechanism and XML as an encoding.

As shown in the figure below, Client sends an HTTP POST Request to FortiBalancer. XML RPC message is the body of the HTTP Request, in which the commands to run and the commands’ parameters are specified. Then, FortiBalancer decodes the XML PRC message and executes the called commands. At last it returns the results formatted in XML to Client.

Figure 19-1 XML RPC Working Mechanism

To realize the communication between the Client and the FortiBalancer appliance, a Perl script, called fortibalancer_xmlrpc.pl, MUST be first executed on Client. The command executed the script is:

fortibalancer_xmlrpc.pl –d <address> -p <port> -f <data_file>

In this command, <address> specifies the FortiBalancer IP address. <port> specifies the port on which the HTTP server is listening. <data_file> specifies the full path and filename of XML RPC message.

XML RPC message is formatted in XML and contains a <methodCall> tag in which <methodName> and <params> tags are embedded.

The following is an HTTP POST Request whose body is an XML RPC message:

POST /cgi-bin/xmlrpc_server HTTP/1.1

Content-Type: text/xml

Content-Length: xxx

<?xml version=’1.0′ ?>

<param>

<value>

<name>enable_passwd</name>

<value>

</value>

</member>

<name>protocol</name>

<value>

</value>

</member>

<value>

<string>fortibalancer</string>

</value>

</member>

<value>

</value>

</member>

<value>

</value>

</member>

<name>maxconns</name>

<value>

</value>

</member>

<name>hctype</name>

<value>

</value>

</member>

<value>

</value>

</member>

<name>hcdown</name>

<value>

</value>

</member>

</struct>

</value>

</param>

</params>

</methodCall>

In this example, the first three lines (as below) constitute the HTTP Request Header, and the remaining part HTTP Request body.

POST /cgi-bin/xmlrpc_server HTTP/1.1

Content-Type: text/xml

Content-Length: xxx

In the first three lines of XML RPC message (as below), “slb_real” is the XML RPC method of the called command “slb real <protocol> <name> <ip> [port] [maxconns] [hc_type] [hc_up] [hc_down]”. XML PRC method is embedded in a <methodName> tag (Please refer to Appendix III, in which all XML RPC methods supported by FortiBalancer are listed.).

<?xml version=’1.0′ ?>

The following part specifies the Enable mode and its password, which indicates the user will log in the Enable mode. “enable_password” is the keyword. The actual password value is embedded in a <string> tag. Enable password is included in every XML RPC message.

<name>enable_passwd</name>

<value>

</value> </member>

This portion (as below) specifies the “protocol” parameter of the called “slb_real” method. “protocol” is the keyword， whose value is embedded in a <string> tag.

<name>protocol</name>

<value>

</value>

</member>

In this example, the parameters of the “slb_real” method include protocol, name, ip, port, maxconns, hctype, hcup and hcdown。Protocol, name and ip are required, while port, maxconns, hctype, hcup and hcdown are optional.

Note: In an HTTP Request, more than one XML RPC method can be called.

If the calling is successful, FortiBalancer will return an HTTP Response formatted in as follows:

<?xml version=’1.0’ ?>

<param>

<value>

<string>xmlrpc command successful</string>

</value>

</param>

</params>

</methodResponse>

If the called command is a “show” command, its output will be displayed in the place of “xmlrpc command successful”. If there is any error, the error is displayed.

To configure the XML PRC function on FortiBalancer, you need to configure two commands:

Step 1 Turn on XML RPC

FortiBalancer1(config)#xml on https

Step 2 Set the port for XML RPC to listen

FortiBalancer1(config)#xml port 9999

19.1.2.2.11 Remote Management

The Remote Management feature of the FortiBalancer appliance allows administrators to access remote devices via Telnet & SSH.

To use the Telnet feature on the FortiBalancer appliance, users can execute the command “telnet “host port”” as follows:

FortiBalancer#telnet “‘172.16.2.182 -4’” Trying 172.16.2.182…

Connected to 172.16.2.182 -4.

Escape character is ‘^]’.

Trying SRA secure login: User (root): admin Password:

[ SRA accepts you ]……………..succeed

To use the SSH feature on the FortiBalancer appliance, users can execute the command “ssh remote “user@hostname”” as follows:

FortiBalancer#ssh remote “root@172.16.85.240” root@172.16.85.240’s password:

Linux libh-server1 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux

Welcome to Ylmf_OS!

* Information: http://www.ylmf.com/

0 packages can be updated.

0 updates are security updates.

Last login: Wed Apr 20 00:39:35 2011 from 10.3.46.1 root@libh-server1:~#

19.1.2.2.12 FortiBalancer Flight Deck

The FortiBalancer appliance monitors a variety of useful statistics that provide a good indication of performance, user and network activity. The FortiBalancer appliance provides a graphical interface that can be used to easily monitor various statistics and get a comprehensive picture of the status of the FortiBalancer appliance. This graphical interface is called the Flight Deck.

The Flight Deck is an additional pop up browser window that, once set, can display a wide range of real time network operational data. Across the top of the browser window, you will discover readouts concerning the server health, request rate, cache hits and system usage. Moving to the left side of the window, you will find reading for the TCP, HTTP and SSL connections. The three connection figures sum up to total used “TCP pcb” displayed in the output of the “show memory” command. Sometimes, a pair of TCP connections is created for the same client request, e.g. an SLB client request normally will generate two connections, one is from the client to FortiBalancer appliance, and the other is from the FortiBalancer appliance to the server.

The central portion of the Flight Deck is occupied by two configurable graphs. Simply use the pull-down menu to choose the desired data you wish to track in the real time graphical output.

You can access the Flight Deck from the FortiBalancer appliance web UI by clicking the “Flight Deck” node at the bottom of the web UI Home configuration tree.

There exists two drop down menus above each graph. The first menu, called “Graph Type” contains a list of the statistics that can be displayed in the graph. Note that the list is identical for each graph. The second menu, called “Interval”, is used to control the granularity of the time units shown on the horizontal axis of the graph, and how often the FortiBalancer appliance will update the graph. The default menu option is 5 seconds, which is also the smallest value that can be chosen. When the value is 5 seconds, the FortiBalancer appliance will update the graph display every 5 seconds, and the time will be shown on the horizontal axis in multiples of 5.

For some statistics, it makes sense to use a smaller interval. For example, it might be useful to see how the number of packets processed by the FortiBalancer appliance varies in 30 sec. intervals. On the other hand, you may want to view some statistics over a wider interval. For example, you may want to look at how the number of concurrent sessions varies from hour to hour, to get a feel for when most of your end users are logging in.

It is important to note that in order to view any of the statistics in the graphs, you must enable

SNMP. This can be done via the web UI from the “Graph SNMP Monitoring” page under the “Admin Tools” node. Some of the statistics also require additional configuration, which will be described below.

Note: For the sake of security, it is strongly recommended to modify the default SNMP community string to avoid possible system information interception.

Pages: 1 2 3

Logging – FortiBalancer

Leave a reply

Chapter 18 Logging

18.1 Overview

The Logging mechanism used by the FortiBalancer appliance is Syslog compliant. System error and HTTP access information during proxy application are logged by using the logging subsystem. Syslog is a standard program for Unix and there are also Syslog implementations for Windows. On the Unix platform, syslog is started by the syslogd daemon. The syslogd daemon takes charge of receiving and storing log messages from local machine or remote machine, which listens at UDP 514 port. FortiBalancer appliance supports three remote log servers.

18.2 Understanding Logging

18.2.1 Syslog

Syslog is a protocol that is used for the transmission of event notification message across networks.

Syslog logging has eight valid levels of log message severity: emerg, alert, crit, err, warning, notice, info and debug. And the supported facilities are LOCAL0 to LOCAL7. Users can view the internal log buffer, select the transport protocol, and configure syslog source and destination ports and the alerts on log message string match.

18.2.2 RFC 5424 Syslog

RFC5424 defines the standard format of syslogs. The FortiBalancer appliance supports the RFC 5424 syslog function. When the RFC 5424 syslog function is enabled, the system will generate system logs in the standard format defined by RFC 5424. The format is “<PRI>VER

TIMESTAMP HOSTNAME APPNAME PROCID MSGID STRUCTURED-DATA MSG-CONTENT”. (The PROCID and STRUCTURED-DATA fields are not supported

temporarily and are displayed as “-”.) By default, the RFC 5424 syslog function is disabled. The configuration of “log rfc5424 on” takes effect only when the system logging function has been enabled by using the “log on” command.

18.2.3 HTTP Access Logging

HTTP Access Logging is the logging of information about every HTTP request and its response in a specific predefined format.

HTTP Access Logging supports four standard formats: Combined, WELF (WebTrends Enhanced Log), Common and Squid. And users can define their own logging format by using the “log http custom” command.

Note: The FortiBalancer appliance will record an HTTP access log only after the HTTP communication between the client and the Web server is completed successfully.

18.2.4 Log Filtering

Log filtering is designed to filter logs to different log servers by matching filter strings which are configured in the command “log filter”.

Log filtering in the OS allows administrators to collect only the logs that they are interested in instead of having to capture all the logs. For example, the administrator of “www.site1.com” may want to only collect the HTTP access logs for “www.site1.com”. Knowing if the logs contain a keyword “site1.com”, the administrator can create a filter for a log definition that captures only the logs which match the keyword. The administrator will now have a log file which contains only the desired logs.

If multiple log filters are set on a syslog host, the logs matching one of the filter strings will go to the syslog host.

18.3 Logging Configuration

18.3.1 Configuration Guidelines

Table 18-1 General Settings of Logging

Operation	Command
Enable the logging	log {on\|off}
Enable RFC 5424 Syslog	log rfc5424 {on\|off}
Configure the remote host	log host <host_ip> [port] [udp\|tcp] [host_id]
Set log filters	log filter <host_id> <filter_id> <filter_string>
Set log level	log level <level>
Change log facility	log facility <facility>
Set HTTP access logging format	log http {squid\|common\|combined\|welf} [vip\|novip] [host\|nohost] log http custom <format>

18.3.2 Configuration Example via CLI

Step 1 Enable Logging function The logging system is off by default.

FortiBalancer(config)#log on

Step 2 Enable the RFC 5424 Syslog function

FortiBalancer(config)#log rfc5424 on

Step 3 Set the remote host to which log messages will be sent

The remote host IP address must be specified in dotted IP format. The remote port is optional and the default value is 514. The transport protocol for the syslog messages can be either UDP or TCP and the default is UDP. In our example, the host of 10.2.37.1 is listening for log message at UDP 514 port.

FortiBalancer(config)#log host 10.2.37.1 514 udp 1

Step 4 Set log filters for the configured host

No more than 3 log filters can be set on one syslog host. Log filter canot be set on the syslog host whose ID is 0 (it is configured by the command “log host”). After this command is executed, only the logs matching this filter string go to the syslog host.

FortiBalancer(config)#log filter 1 1 “index”

Step 5 Change the minimum log level at which messages will be logged

Once a log level is set, messages with level below the configured level will be ignored. The default level is info.

FortiBalancer(config)#log level err

Step 6 Change the syslog facility The default facility is LOCAL0.

FortiBalancer(config)#log facility LOCAL0

Step 7 Configure the HTTP access logging format

HTTP access information can be logged in one of the standard formats Squid, WELF, Common and Combined, or it can be logged in a custom format specified by the user.

FortiBalancer(config)#log http squid

Step 8 Generate a test log

You can run the command “log test” to generate an emerg-level log.

FortiBalancer(config)#log test

Step 9 View and clear logs

You can run the following command “show log buff {forward|backward} [match_str]” to view logs in the log buffer. The parameters “backward” and “forward” are used to display the logs that are latest and first generated respectively.

FortiBalancer(config)#show log buffer backward start of buffer

<128>1 2012-07-17T06:35:26Z FortiBalancer – – 100021002 – Fortinet test message

You can run the command “clear log buff” to clear logs from the log buffer.

FortiBalancer(config)#clear log buffer

ePolicy – FortiBalancer

Leave a reply

Chapter 17 ePolicy

17.1 Overview

ePolicy is a script-based function for extending the capabilities of the FortiBalancer appliance. Using the scripts written in Tools Command Language (TCL), you can customize new features in addition to the existing functions on the FortiBalancer appliance. For example, the FortiBalancer appliance can be customized to support more application protocols, precisely control IP application traffic in both incoming and outgoing directions, or control the access of the specified client to real services.

17.2 ePolicy Elements

The elements of ePolicy are as follows:

Event
Command
Command invocation rule

17.2.1 Event

ePolicy uses an event-driven and message-response mechanism. The FortiBalancer appliance defines an event for every action occurring in each Client-FortiBalancer-Server connection. When such an event occurs, the FortiBalancer appliance will process traffic according to preconfigured ePolicy commands.

17.2.2 Command

ePolicy uses commands to instruct the FortiBalancer appliance to process traffic after an event occurs, such as rewriting packet contents, selecting real servers, selecting groups, or querying whether a group has valid real servers.

17.2.3 Command Invocation Rule

Command invocation rules indicate the relationship between events and commands. Based on the command invocation rules, you can flexibly combine the events and commands to intercept, detect, convert, or redirect the IP application traffic in both incoming and outgoing directions. For detailed information of events, commands, and command invocation rules, contact Fortinet Customer Support for related documents.

17.3 ePolicy Scripts

By functions, the scripts of ePolicy can be classified into the following:

Setting script: specifies the traffic type of a virtual service. The following table lists the setting scripts that are currently supported:

Table 17–1 Content of Setting Scripts

Traffic Type	Content of the Setting Script
HTTP	message::type http
Diameter	message::type binary binary_message::length_start_offset 1 binary_message::length_end_offset 3
Generic TCP	message::type binary

Runtime script: specifies the action of the FortiBalancer appliance for an event. The content of a runtime script should be written according to the actual requirement based on events, commands, and command invocation rules. For the examples of the runtime scripts, contact Customer Support for related documents.

Pages: 1 2

Advanced IPv6 Configuration – FortiBalancer

1 Reply

Chapter 16 Advanced IPv6 Configuration

16.1 Overview

As the IPv4 addresses exhaust, how to transit from the IPv4 network to the IPv6 network becomes a challenge for many enterprises and organizations.

The FortiBalancer appliance provides comprehensive support for IPv6 to help enterprises and organizations with the IPv4-to-IPv6 transition without any business interruption. With the IPv4/IPv6 dual stack support on FortiBalancer, the IPv4 resources can be delivered to the IPv6 users, and vice versa. As a result, the IPv4-based and IPv6-based networks can be easily interconnected and intercommunicated. What’s more, the FortiBalancer appliance in the IPv6 network can achieve the same level of secure and efficient application delivery as it does in the IPv4 network.

This chapter will introduce functions and configurations about IPv6 SLB, DNS64/NAT64, DNS46/NAT46, IPv6 NAT and NDP.

Pages: 1 2 3 4 5 6

Access Control – FortiBalancer

Leave a reply

Chapter 15 Access Control

15.1 WebWall

15.1.1 Overview

The WebWall functionality of the FortiBalancer appliance allows you to create permit/deny rules to filter packets passing through your network infrastructure. The WebWall supports the filtering of TCP, UDP and ICMP packets that are using the IPv4 or IPv6 address. To use access lists you will define these “permit” and “deny” rules and apply them to access groups. Once the access lists are configured, you may apply or bind the group to an interface within the network.

The steps for basic WebWall configurations are explained in this section, along with some advanced features and general knowledge of how WebWall works. For the OS, the WebWall feature can independently control each interface.

WebWall permits TCP and UDP health check traffic, but cannot permit ICMP health check traffic automatically.

15.1.2 Understanding WebWall

WebWall is a full-fledged stateful Firewall. It bridges the gap between speed and security. The FortiBalancer appliance houses and integrates the WebWall feature into a single platform, along with many of other features such as Layer 4-7 load balancing, caching, SSL acceleration, authentication and authorization.

Figure 15-1 WebWall

WebWall contains several security mechanisms to protect Web servers from attack, including:

ACL (Access Control List) filtering
Protection against Syn-Flood, Fragmentation and DoS (Denial Of Service) attacks
Stateful packet inspection
Single packet attack prevention

ACL Filtering provides tight control over who may and may not enter the network by utilizing FortiBalancer’s ultra-fast rules engine. WebWall access control list filtering mechanism ensures virtually no performance loss with up to 1,000 ACL rules, while never consuming more than one percent of OS capability.

In addition to ACL filtering, the WebWall provides stateful packet inspection and protects against Syn-Flood, fragmentation, DoS and single packet attacks.

The WebWall is a default-deny firewall. Default-Deny refers to the notion that if you do not have any permit rules in your access control lists, no packets will be allowed to pass through the appliance. During the initial installation of the box it might be helpful to leave the WebWall in the off or disengaged state until your total configuration is complete.

Note: By default the WebWall is turned off. The WebWall function will remain disabled until it is activated via the “webwall on” command.

15.1.3 WebWall Configuration

15.1.3.1 Configuration Guidelines

Let’s start with the basic step for configuring the WebWall. To better assist you with configuration strategies that maximize the power of the FortiBalancer appliance, please take a moment to familiarize yourself with basic network architecture.

Figure 15-2 WebWall Configuration

Then we must define what we want to deny and permit. Since “example.com” is a relatively small site, let’s begin with the following:

Permit port 80 to our VIP (10.10.0.10).
Permit port 22 to the Management IP of the FortiBalancer appliance (for SSH access).
Permit port 8888 to the Management IP of the FortiBalancer appliance for web UI access.
Deny network 10.10.20.0/255.255.255.0, since that network has been abusing its privileges.
Allow all inside hosts to ping the IP address of the interface “port2” (inside interface). Initially we will define our access groups as follows:
50 All miscellaneous rules
100 All Management IP related rules
150 All VIP (Virtual IP) related rules

Table 15-1 General Settings of WebWall

Operation	Command
Configure access group	accessgroup <accesslist_id> <interface>
Configure ACL rules	accesslist permit icmp echoreply <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist permit icmp echorequest <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist permit tcp <source_ip> <source_mask\|source_prefix> <source_port> <destination_ip> <destination_mask\|destination_prefix> <destination_port> <accesslist_id> accesslist permit udp <source_ip> <source_mask\|source_prefix> <source_port> <destination_ip> <destination_mask\|destination_prefix> <destination_port> <accesslist_id> accesslist permit esp <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist permit ah <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist deny icmp echoreply <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist deny icmp echorequest <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist deny tcp <source_ip> <source_mask\|source_prefix> <source_port> <destination_ip> <destination_mask\|destination_prefix> <destination_port> <accesslist_id> accesslist deny udp <source_ip> <source_mask\|source_prefix> <source_port> <destination_ip> <destination_mask\|destination_prefix> <destination_port> <accesslist_id> accesslist deny esp <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id> accesslist deny ah <source_ip> <source_mask\|source_prefix> <destination_ip> <destination_mask\|destination_prefix> <accesslist_id>
Enable/Disable WebWall	webwall <interface> on [mode] webwall <interface > off
View WebWall configurations	show interface show accesslist show accessgroup

15.1.3.2 Configuration Example via CLI

15.1.3.2.1 Configuring Access Groups

We may define any number of access groups and apply multiple groups to a designated interface via CLI. Pertaining to our example model, the command should be executed as such:

FortiBalancer(config)#accessgroup 100 port1

FortiBalancer(config)#accessgroup 150 port1

FortiBalancer(config)#accessgroup 50 port1

You might have noticed that we also have specified what interfaces these access groups will be applied to.

15.1.3.2.2 Configuring ACL Rules

Now we define the “permit” and “deny” rules based on these assumptions.

The first entry allows a single host with IP 10.10.10.30 to connect to the server using port 22:

FortiBalancer(config)#accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100

The second entry allows a C class subnet to connect to the server via port 8888.

FortiBalancer(config)#accesslist permit tcp 10.10.10.0 255.255.255.0 0 10.10.10.10 255.255.255.255 8888 100

The third allows any host to connect to the server using port 80.

FortiBalancer(config)#accesslist permit tcp 0.0.0.0 0.0.0.0 0 10.10.10.20 255.255.255.255 80

150

The first three rules are fairly straightforward, and they permit all TCP traffic to the destination IP/port specified and are tied to the access group (via the last argument to the command).

With the fourth entry, we are excluding one host from gaining access through the subnet. It is in access group 50 since it does not allow access to a specific destination IP. Logically the deny rule could fit into both access group 100 and 150, so for administrative ease we will make another group.

FortiBalancer(config)#accesslist deny tcp 10.10.10.33 255.255.255.255 0 10.10.10.10 255.255.255.255 0 50

The last two rules allow the inside hosts on the network to ping the “port2” interface when the WebWall function is on.

FortiBalancer(config)#accesslist permit icmp echorequest 192.168.10.0 255.255.255.0

192.168.10.1 255.255.255.255 50

FortiBalancer(config)#accesslist permit icmp echoreply 192.168.10.1 255.255.255.255 192.168.10.0 255.255.255.0 50

Note: The IP address is not an IP on the FortiBalancer appliance. It is the IP of the default gateway.

The priority of the command “accesslist deny” is higher than “accesslist permit”. If we configure

“permit” and “deny” rules for the port 22 to the Management IP of the FortiBalancer appliance (for SSH access) at the same time as follows:

FortiBalancer(config)#accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100

FortiBalancer(config)#accesslist deny tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100

When the administrators attempt to access the FortiBalancer appliance via the management IP through SSH, the access will be denied.

15.1.3.2.3 Configuring WebWall

At last once you complete the configuration of the other features of the FortiBalancer appliance, and you should turn the WebWall feature back on by issuing the command:

FortiBalancer(config)#webwall port2 on

FortiBalancer(config)#webwall port1 on

Notes:

You should exercise with caution when adjusting the WebWall rules. It is possible to deny yourself from accessing the appliance if you are logged in remotely through SSH or the web UI and your session can be interrupted before configuration is completed.
If you configure the DNS servers and have WebWall turned on for the destination interface through which the DNS requests/replies go, you need to add the corresponding accesslist rules to allow that traffic.
If WebWall is turned on for the interface for which the “synconfig” command uses to synchronize with peer(s), you will need to add the corresponding accesslist rules to allow that traffic to come in through SSH port 22 on the Fortinet machines (FortiBalancer appliance and the sync peers).

15.1.3.3 Verification and Troubleshooting of the WebWall

After adding all the rules it is helpful to display the current lists and groups. To do this, employ the following commands.

FortiBalancer(config)#show accesslist

accesslist deny tcp 10.10.10.33 255.255.255.255 0 10.10.10.10 255.255.255.255 0 50 accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100 accesslist permit tcp 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 8888 100 accesslist permit tcp 0.0.0.0 0.0.0.0 0 10.10.10.20 255.255.255.255 80 150

accesslist permit icmp echorequest 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 50 accesslist permit icmp echoreply 0.0.0.0 0.0.0.0 10.10.10.10 255.255.255.255 50

FortiBalancer(config)#show accessgroup accessgroup 50 port1 accessgroup 100 port1 accessgroup 150 port1

If you run into problems with access lists, keep your configurations simple. With multiple access groups, you can apply them once at a time and see which access list is causing problems. Of course you can turn the WebWall completely off to determine if the WebWall itself is indeed causing the problem.

To check the status of the firewall use the “show interface” command:

FortiBalancer(config)#show interface

port1(port1): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500

inet 10.3.20.100 netmask 0xffff0000 broadcast 10.3.255.255 inet 10.3.20.56 netmask 0xffffffff broadcast 10.3.20.56 ether 00:30:48:82:81:7a

media: autoselect (100baseTX <full-duplex>) status: active webwall status: OFF Hardware is i82547gi

Input queue: 435/512 (size/max)

total: 19376 packets, good: 19376 packets, 2053879 bytes broadcasts: 19130, multicasts: 2

11317 64 bytes, 4282 65-127 bytes,3242 128-255 bytes

522 255-511 bytes,13 512-1023 bytes,0 1024-1522 bytes

0 input errors

0 runts, 0 giants, 0 Jabbers, 0 CRCs

0 Flow Control, 0 Fragments, 0 Receive errors

0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers

0 overruns, Carrier extension errors: 0 Output queue: 0/512 (size/max)

total: 18444 packets, good: 18444 packets, 7182692 bytes broadcasts: 17, multicasts: 0

48 64 bytes, 6018 65-127 bytes,7512 128-255 bytes

785 255-511 bytes,1014 512-1023 bytes,3067 1024-1522 bytes

0 output errors

0 Collsions, 0 Late collisions, 0 Deferred

0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions

0 lost carrier, 0 WDT reset packet drop (not permit): 0

tcp 0 udp 0 icmp 0 ah 0 esp 0 packet drop (deny): 0

tcp 0 udp 0 icmp 0 ah 0 esp 0

5 minute input rate 2160 bits/sec, 2 packets/sec

5 minute output rate 80 bits/sec, 0 packets/sec

port2(port2): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500

inet 10.4.20.100 netmask 0xffff0000 broadcast 10.4.255.255 ether 00:30:48:82:81:7b

media: autoselect (100baseTX <full-duplex>) status: active webwall status: OFF Hardware is i82541gi

Input queue: 71/512 (size/max)

total: 38464 packets, good: 38464 packets, 9320519 bytes broadcasts: 18751, multicasts: 2

10779 64 bytes, 11545 65-127 bytes,10749 128-255 bytes

1305 255-511 bytes,1019 512-1023 bytes,3067 1024-1522 bytes

0 input errors

0 runts, 0 giants, 0 Jabbers, 0 CRCs

0 Flow Control, 0 Fragments, 0 Receive errors

0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers

0 overruns, Carrier extension errors: 0 Output queue: 0/512 (size/max)

total: 2094 packets, good: 2094 packets, 207035 bytes broadcasts: 396, multicasts: 0

399 64 bytes, 1681 65-127 bytes,0 128-255 bytes

0 255-511 bytes,14 512-1023 bytes,0 1024-1522 bytes

0 output errors

0 Collsions, 0 Late collisions, 0 Deferred

0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions

0 lost carrier, 0 WDT reset packet drop (not permit): 0

tcp 0 udp 0 icmp 0 ah 0 esp 0 packet drop (deny): 0

tcp 0 udp 0 icmp 0 ah 0 esp 0

5 minute input rate 2336 bits/sec, 3 packets/sec

5 minute output rate 224 bits/sec, 0 packets/sec

This command will also show if the interface is up and running and those IP addresses assigned to it. More detailed network information is also included, such as input queue and output queue information.

The following explains the terms and phrases used in the output:

Input queue size: the current occupied input.
Input queue max: the maximum items of input.
The numbers of different sizes: the counts of the packages of each size.
Runt: the number of received frames that have passed address filtering that are less than the minimum size (64 bytes from <Destination Address> through <CRC>, inclusively), and have a valid CRC.
Giant: the number of received frames with valid CRC field that have passed address filtering and are larger than the maximum size.
Jabber: the number of received frames that have passed address filtering that are greater than the maximum size and have a bad CRC. It may be the result of a bad NIC or electronic interfering.
CRC: the number of received packets with alignment errors.
Flow Control: the number of the received, unsupported flow control frames.
Fragments: the number of received frames that have passed address filtering, are less than the minimum size and have a bad CRC.
Frame: the number of received packets with alignment errors (the packet is not an integer number of bytes in length).
Lengths: the number of received length error events.
No Buffers: the number of times that frames are received when there are no available buffers in host memory to store those frames.
Overruns: the number of missed packets. Packets are missed when the received FIFO has insufficient space to store the incoming packets. This can be caused by too few allocated buffers, or insufficient bandwidth on the PCI bus.
Carrier extension errors: the number of received packets where the carrier extension error is signaled across the internal PHY interface.
Collisions: the total number of collisions that are not late collisions as seen by the transmitter.
Late collisions: late collisions are collisions that occur after 64-byte time into the transmission of the packet while working in 10-100 Mb/s data rate, and after 512-byte time into the transmission of the packet while working in the 1000 Mb/s data rate.
Deferred: a deferred event occurs when the transmitter cannot immediately send a packet because the medium is busy or another device is transmitting.
Single Collisions: the number of times that a successfully transmitted packet has encountered only one collision.
Multiple Collisions: the number of times that a successfully transmitted packet has encountered more than one collision but less than 16.
Excessive collisions: the number of times that 16 or more collisions have occurred on a packet.

Pages: 1 2

Global Server Load Balancing – FortiBalancer

Leave a reply

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:

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.
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.
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.
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.
Upon receiving the response, the local application server forwards IP address to the client directly.
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.

Pages: 1 2 3 4 5 6 7

Link Load Balancing – FortiBalancer

Leave a reply

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:

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.
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:

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.
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.

Pages: 1 2 3

Quality of Service – FortiBalancer

Leave a reply

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.

Pages: 1 2