Tag Archives: fortibalancer administrators guide

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

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

Secure Sockets Layer – FortiBalancer

Leave a reply

Chapter 11 Secure Sockets Layer (SSL)

11.1 Overview

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

Pages: 1 2 3

DNS Cache – FortiBalancer

Leave a reply

Chapter 9 DNS Cache

9.1 Overview

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

Pages: 1 2