Equalizer Administration Guide

The recognized leader in proven and affordable load
balancing and application delivery solutions
Application Delivery Controller
EQ/OS 10
Administration Guide
for Equalizer™ LX and GX Series
OS Version 10.3.2
August 11, 2015
Copyright© 2015 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and
FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., in the
U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or
common law trademarks of Fortinet. All other product or company names may be
trademarks of their respective owners. Performance and other metrics contained herein
were attained in internal lab tests under ideal conditions, and actual performance and other
results may vary. Network variables, different network environments and other conditions
may affect performance results. Nothing herein represents any binding commitment by
Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the
extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with
a purchaser that expressly warrants that the identified product will perform according to
certain expressly-identified performance metrics and, in such event, only the specific
performance metrics expressly identified in such binding written contract shall be binding
on Fortinet. For absolute clarity, any such warranty will be limited to performance in the
same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features or development, and circumstances
may change such that any forward-looking statements herein are not accurate. Fortinet
disclaims in full any covenants, representations, and guarantees pursuant hereto, whether
express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise
revise this publication without notice, and the most current version of the publication shall
be applicable.
Coyote Point Systems
A subsidiary of Fortinet, Inc.
56 Main Street
Millerton, NY 12546
Equalizer Administration Guide
Table of Contents
Table of Contents
Introduction
3
19
About Equalizer
20
Typographical Conventions
21
Attributions
21
Where to Go for More Help
22
Overview
23
Intelligent Load Balancing
24
Real-Time Server Status Information
25
Network Address Translation and Spoofing
26
Load Balancing
28
How a Server is Selected
30
Layer 7 Load Balancing and Server Selection
32
Persistence
33
Why a Server May Not Be Selected
36
What's New
What's New
Installation
37
38
41
Hardware Installation
42
UL/cUL & CE/CB Safety Warnings and Precautions
43
Power Requirements
45
Operating Environment
45
Regulatory Certification
45
Setting Up a Terminal or Terminal Emulator
46
Configuring Access
47
Default Login
48
Serial Access
48
Upgrading and Downgrading
49
EQ/OS 8.6 Upgrade Procedure
50
Upgrading to the Latest Firmware Release
56
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
3
Table of Contents
Downgrading to an Earlier Firmware Release
Basic Configuration
61
Basic Configuration
62
Replacing the Default Certificate, Key, and Cipherspec
65
Enabling Network Services
69
Enabling Global Network Services
70
Enabling VLAN Subnet Network Services
72
Registering Your Product
75
Registering Your Product
76
Sample Configuration
79
Sample Configuration
80
Load Balancing & Networking
87
Networking Routing Description
88
Networking Conventions
92
How Packets are Routed
93
Typical Equalizer Networking Scenarios
95
Blank Configuration
95
Single VLAN/Subnet
96
Single VLAN/Subnet with a Default Gateway
98
Dual VLAN/Network
100
Dual VLAN/Network with 2 Gateways
103
Dual VLAN/Network with Outbound NAT
106
Configuring Network Interfaces
109
Configuring Phyiscal Interfaces
110
Configuring Front Panel Ports
110
Viewing Link Status and Port Settings
111
Viewing Link Status and Port Settings (E350GX, E450GX, E650GX Only)
Displaying Port Statistics
Configuring VLAN Interfaces
4
57
113
115
118
Configuring VLANs
120
Configuring Subnets
125
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
About Permitted Subnets
128
Configuring Outbound NAT
129
Configuring Aggregated Interfaces
131
Configuring Static Routes
137
Policy Routing
140
Source Based Routing Scenarios
141
Source Selection
142
Source Routing Scenarios
144
Spoof Load Balancing Toward Server
145
Spoof Load Balancing Toward Client
147
Non-Spoof Load Balancing Toward Client
149
Non Spoof Load Balancing Toward Server
149
Source, Destination Specified
150
Generated by Equalizer
151
Source Routing Tables & Rules
152
Source Routing Table
153
IP Filter Rules
154
IP NAT Rules
157
IPv6 Tunnel Overview
Configuring an IPv6 Tunnel
Network Troubleshooting Tools
Working in the CLI
Starting the CLI
158
160
165
167
168
Logging In to the CLI Over a Serial Connection
168
Logging In to the CLI Over an SSH Connection
169
Exiting the CLI
170
Working in the CLI
171
CLI Contexts and Objects
171
Object Relationships
173
Command Line Editing
174
Entering Names for Equalizer Objects
175
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
5
Table of Contents
Using White Space in a Command Line
175
Enabling and Disabling Flags
176
Command Abbreviation and Completion
177
Detection of Invalid Commands and Arguments
178
Specifying Multiple Server Instances
178
Using the no Form of a Command
179
Queued Commands
180
Context Help
182
Global Parameters
183
Show Configuration Command
184
Debug Commands
186
Context Command Summaries
189
Global Commands
190
Certificate Commands
194
Certificate Revocation List Commands
197
Cluster and Match Rule Commands
198
Diagnostic Commands
207
External Services Commands
208
Failover Commands
210
File Commands
210
Firewall Commands
211
GeoCluster and GeoSite Instance Commands
212
GeoSite and GeoSite Resource Commands
215
Health Check Commands
217
Interface Commands
223
Interface Command Notes
224
Link Aggregation Commands
225
Link Load Balancing Commands
226
Object List Commands
228
Peer Commands
229
Protection Commands
233
Remote Management Commands
235
Responder Commands
236
Regular Expressions in Redirect Responders
Server Commands
6
237
238
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Pool, Server Instance, and Caching Commands
239
Server Side Encryption Commands
246
Smart Control Commands
247
SNMP Commands
249
Tunnel Commands
251
User Commands
252
User Flags
256
Setting the Locale
256
Creating a User
257
Deleting a User
257
User Passwords
257
User Permissions
257
User Permissions Assigned on Object Creation
260
Displaying User Information
260
VLAN and Subnet Commands
VLAN and Subnet Command Notes
Using the GUI
261
265
267
Logging In
268
Navigating Through the Interface
269
Entering Names for Load Balancing Objects
276
Using the WebHelp
277
System Settings
279
Global Settings
280
Dashboard
281
Alerts
283
Certificates
283
Replacing the Default Certificate, Key, and Cipherspec
285
Certificate Revocation Lists
288
Parameters
290
Server Side Encryption
291
Smart Control
292
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
7
Table of Contents
SNMP
293
External Services
297
SMTP Relay
297
VLB Manager
297
Maintenance
300
Date and Time
300
Enabling DNS
301
Configuring NTP
302
NTP and Plotting
302
Default NTP Configuration
302
Selecting an NTP Server
303
Managing NTP
304
Backup and Restore
305
Licensing
310
Manage Software
311
Tools
312
Failover
315
Working with Clusters and Match Rules
8
317
Overview
318
Cluster Summary
320
Cluster Connection Timeouts
324
HTTP and HTTPS Connection Timeouts
324
Once Only Option and HTTP / HTTPS Timeouts
327
Layer 4 Connection Timeouts
328
Application Server Timeouts
329
Connection Timeout Kernel Variables
330
Adding and Deleting Clusters
331
Modifying a Layer 4 TCP or UDP Cluster
333
TCP Cluster Configuration Summary
333
TCP Cluster Configuration Settings
335
TCP Cluster Persistence
338
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
TCP Cluster Timeouts
340
UDP Cluster Configuration Summary
342
UDP Cluster Configuration Settings
344
UDP Cluster Persistence
348
UDP Cluster Timeouts
350
UDP Cluster Limitations
352
Modifying a Layer 7 HTTP or HTTPS Cluster
353
Layer 7 Cluster Configuration Summary
354
Layer 7 HTTP and HTTPS Cluster Settings
356
Layer 7 Security Certificate Screen (HTTPS Clusters)
361
Layer 7 SSL Security (HTTPS Clusters)
365
Layer 7 HTTP and HTTPS Cluster Persistence
370
Fallback Persistence Scenarios
376
Server Side Encryption
379
Layer 7 Cluster Reporting
383
Layer 7 Cluster Timeouts
383
Server Name Indication
385
Header Editing
389
Layer 7 TCP Cluster Settings
390
Layer 7 TCP Cluster Persistence
Additional Cluster Configuration
394
395
About Passive FTP Translation
395
Enabling Cookies for Persistent Connections
395
Enabling Persistent Server Connections
395
Enabling Sticky Connections
395
Enabling the Once Only and Persist Options
397
Enabling Both the Once Only and Always Options
400
Enabling Once Only and Compression
401
Enabling Once Only and No Header Rewrite for HTTPS
401
Specifying a Custom Header for HTTP/HTTPS Clusters
401
Performance Considerations for HTTPS Clusters
402
HTTPS Performance and Xcel SSL Acceleration
402
HTTPS Header Injection
404
Providing FTP Services on a Virtual Cluster
404
FTP Cluster Configuration
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
405
9
Table of Contents
Configuring Direct Server Return
406
Testing Your Basic Configuration
409
Using Match Rules
410
How Match Rules are Processed
411
Match Rule Order
412
Match Rule Expressions and Bodies
413
Match Rule Expressions
414
Match Bodies
415
Match Rule Functions
417
Match Rule Operators
420
Match Rule Definitions
421
Match Rule Expression Examples
421
Match Rule Expression Notes
422
Using Responders in Match Rules
425
Managing Match Rules
426
Displaying Match Rules
427
Default Match Rule
427
Creating a New Match Rule
428
Modifying a Match Rule
434
Removing a Match Rule
434
Using the Match Rule Expression Editor
Operating within the Expression Editor
436
Example Match Rules
437
Cluster and Match Rule Statistics and Reporting
Server Pools and Server Instances
10
435
446
455
Managing Server Pools
456
Server Pool Summary
457
Configuring Server Pool Load-Balancing Options
459
Using Active Content Verification (ACV)
461
Adding and Configuring Server Pools
463
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding Server Instances
466
Server Instance Summary Screen
470
Associating a Server Pool with a Cluster
471
Deleting Server Pools
472
Server Pool and Server Instance Reporting
473
HTTP Caching
481
Caching Overview
482
HTTP Caching Functional Description
483
HTTP Caching Configuration Overview
485
Using the CLI and GUI to Configure Caching
487
Managing Servers
503
Server Summary
504
Adding and Modifying Servers
506
Server Software Configuration
510
Adjusting a Server’s Initial Weight
511
Setting Initial Weights for Homogenous Clusters
512
Maximum Connections Limits, Responders, and Hot Spares
513
Setting Initial Weights for Mixed Clusters
514
Interaction of Server Options and Connection Processing
Shutting Down a Server Gracefully
515
516
Server Configuration Constraints
517
Configuring Routing on Servers
518
Spoof Controls SNAT
518
How Spoof Influences Routing
518
Server Statistics and Reporting
Health Checks
520
525
Overview of Health Checks
526
Key Terms
529
Health Check Constraints
530
Health Check Probing Ports
530
System Health Checks
531
Firmware Upgrade Notes
532
Health Check Configuration Process
534
Configuring ICMP Health Checks
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
535
11
Table of Contents
Configuring TCP & UDP Health Checks
539
Configuring ACV Health Checks
544
Configuring HTTP and HTTPS Application Health Checks
554
Configuring VLB Health Checks
573
Configuring Server Agent Health Checks
584
Attaching Health Checks to Load Balancing Objects
591
Attached ACV and TCP Health Checks and the Test Function
595
Displaying Configured Health Checks
597
Disabling Health Checks
602
Deleting Health Checks
605
Probe Coalescing
607
Health Check Timeouts
609
Automatic Cluster Responders
613
Automatic Cluster Resopnder Overview
614
Responder Summary
615
Managing Responders
616
Adding a Responder
616
Modifying a Responder
619
Using Regular Expressions in Redirect Responders
619
Using Responders in Match Rules
622
Creating a Match Rule for a “Sorry Page”
622
Creating a Match Rule to Redirect All Traffic for a Specific URL
624
Responders and Hot Spares
626
Responder Statistics and Reporting
627
Link Load Balancing
629
Link Load Balancing
630
Outbound Link Load Balancing
631
Configuring Outbound Link Load Balancing
Inbound Link Load Balancing
637
Configuring Inbound Link Load Balancing
Global Load Balance
12
638
643
Overview of Envoy Geographic Load Balancing
Envoy Configuration Summary
632
644
645
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
DNS Configuration
645
Using Envoy with Firewalled Networks
648
Using Envoy with NAT Devices
648
Configuring GeoClusters
649
Configuring GeoSites
654
Geosite Instance Parameters
655
GeoSite Resources and GeoSite Instance Resources
FortiDirector™ GSLB
Using the Equalizer GUI to Interface with FortiDirector
Security and Protection
660
662
662
667
Equalizer‘s Security and Protection System
668
DDoS Protection
669
How Equalizer‘s DDoS Protection Works
671
Equalizer‘s DDoS Protection Features
673
First Time Deployment
674
Some Key Concepts
675
Attack Types Prevented
676
Feature Usage Workflow
680
Setting Up Equalizer‘s Service Protection Profiles
681
Global SPPs
683
Cluster SPPs
686
How Mitigation Works with Thresholds
699
Monitoring Attack Activity and Other System Information
701
Using the IP Reputation Database
704
Using Access Control Lists
716
Logs and Reports
725
Filter Status Details on GUI Log Displays
726
Event Log
727
System Log
729
Audit Log
731
Export to CSV
733
Upgrade Log
734
Remote System Logging
735
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
13
Table of Contents
Usage Reporting and Alert Notifications
737
Failover
741
Understanding Failover
742
Types of Failover
742
How a Failover Peer Determines if it Should Assume the Primary Role
745
Guidelines for Upgrading a Failover Pair with the Latest Firmware
746
Configuring Failover Between Systems
747
Failover Constraints
747
Setting Subnets Up for Failover
749
Configuring Active/Passive Failover Between Two Systems
755
General Configuration Process
755
Networking Considerations
755
Configuration
756
Monitoring Active/Passive Failover
771
Rebalancing
775
Configuring Active/Active Failover Between Two Systems
General Configuration
776
Networking Considerations
776
Using Failover Groups
777
Configuration
778
Monitoring Active/Active Failover
787
Rebalancing
795
Configuring N+1 Failover Between Two Systems
14
776
796
General Configuration
796
Networking Considerations
796
How a Peer is Chosen for Failover in N+1 Configuration
797
Configuring N + 1 Failover with 3 ADCs
799
Monitoring N+1 Failover
812
Rebalancing
817
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Failover Peer Probes and Timeouts
819
Server / Gateway Availability Constraint
821
Configuring Failover Between EQ/OS 8.6 and EQ/OS 10
822
Guidelines for Upgrading a Failover Pair from EQ/OS 8.6 to EQ/OS 10
822
EQ/OS 8.6 Failover Constraints
822
Failover Between EQ/OS 8 and EQ/OS 10
823
Configuring Server Connections
HTTP Multiplexing
831
832
Enabling HTTP Multiplexing
833
Disabling "spoof" for HTTP Multiplexing
834
Server Options for HTTP Multiplexing
835
Direct Server Return (DSR)
836
Configuring a Cluster for Direct Server Return
837
Configuring Servers for Direct Server Return
838
Configuring Windows Server 2003 and IIS for DSR
838
Adjusting ARP Behavior on Linux Servers
839
Configuring a Linux System running Apache for DSR
839
Configuring a Loopback Interface on Other Systems for DSR
840
Weak and Strong Host Models and DSR
841
Smart Control
Smart Control Overview
Why PHP?
843
844
844
How Smart Control Works
845
Smart Control Types
846
Smart Control Configuration Guidelines
847
Smart Control Classes
848
Server Pool Class (srvpool)
849
Server Class (server)
853
Server Instance Class (si)
856
ADC Class (adc)
859
Sample Trigger Script for the Configuration of Multiple Hot Spare Servers
861
Sample Trigger Script for Rebooting the System
862
Adding Smart Controls
863
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
15
Table of Contents
If Using a Smart Control to Create "eqcollect" Archives
Alerts
879
Configuring Alerts
880
Using Wild Card Characters to Configure Alerts
Configuring an SMTP Relay
896
901
Using SNMP Traps
903
Setting Up SNMP Traps
904
Setting Up an SNMP Management Station
905
Enabling SNMP
906
Enabling SNMP Traps
907
Creating SNMP Trap Alerts
908
File Management
910
Using File Management Commands in the CLI
911
Displaying the Files in Equalizer's File Store
912
Deleting Files from the File Store
912
Copying Files to an FTP Server
913
Editing Files in the Datastore
914
Copying Files Between a USB Flash Drive and the File Store
915
How to Use Regular Expressions
919
Regular Expression Terms
920
Learning About Atoms
921
Creating a Bracket Expression
922
Escape Sequences
923
Matching in Regular Expressions
924
Using Regular Expressions in Responders
925
Troubleshooting
16
878
927
Connectivity and Configuration Issues
928
Using Diagnostic Commands
931
Using tcpdump
944
Using Watchdog Timers
949
Configuring the Baseboard Management Controller (BMC)
954
Prerequisites
954
Configuration
954
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using IPMI to Power Servers On/Off
Equalizer OnDemand
962
965
What is Equalizer OnDemand?
966
Differences from Equalizer Hardware
967
Installing and Upgrading Equalizer OnDemand
970
VMware Host Requirements
970
Installing EQOD Using OVF
971
Installing EQOD from a ZIP file
973
VMware vSphere or vCenter Clients
973
VMware Player and VMware Fusion
974
Licensing EQOD
975
Upgrading EQOD
977
Using Certificates in HTTPS Clusters
979
Using Certificates in HTTPS Clusters
980
Configuring Cipher Suites
984
Enabling HTTPS with a Server Certificate
992
Enabling HTTPS with Server and Client Certificates
993
Generating a CSR and Getting It Signed by a CA
995
Generating a Self-Signed Certificate
997
Installing Certificates for an HTTPS Cluster
998
Converting a Certificate from PEM to PKCS12 Format
999
Using the File Editor
1001
Editing Files
1002
Port Numbers
1005
Port Numbers
Networking Translation Between EQ/OS 10.1.x and 10.2.x
Networking Translation Between 10.1.x and 10.2.x Systems
HTTP and HTTPS Header Editing Feature
1006
1009
1010
1015
Header Editing
1016
Functional Description
1017
Header Editing Basics
1018
Header Editing Function Definitions
1019
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
17
Table of Contents
Header Editing Variables
1029
User-Defined Variables
1029
System Variables
1031
Operators
1032
Using the && and || Logical Operators
1034
Use of White Space
1037
Using Flow Control in Header Edit Scripts
Using Flow Control in Header Edit Scripts
1047
Expression Syntax
1052
Using Variables in Replacement Strings
1053
Locating, Inserting, Replacing, and Deleting Headers
1054
Locating Headers
1054
Inserting, Replacing and Deleting Entire Headers
1055
Searching Within a Header or URI Component
1057
Editing Within a Header or URI Component
1058
Using the CLI and GUI to Configure Header Editing Rules
Using Comments with Header Editing Scripts
18
1038
1062
1065
Header Editing Reporting
1068
Debugging Aids for Header Editing Scripts
1071
Header Editing Examples
1079
Maximum Configuration Values
1093
Glossary
1095
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 1
Introduction
Subsections in this chapter include:
About Equalizer
Typographical Conventions
Attributions
Where to Go for More Help
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
20
21
21
22
19
Introduction
About Equalizer
The Equalizer Application Delivery Controller (ADC) is a high-performance switch that offers
optimized availability, user experience, and performance of mobile, cloud-based and enterprise
applications while increasing server efficiency and reducing cost and complexity in the data
center. It features:
l
l
20
Intelligent load balancing based on multiple, user-configurable criteria
Non-stop availability with no single point of failure, through the use of redundant servers in
a cluster and the optional addition of a failover (or backup) Equalizer
l
Layer 7 content-sensitive routing
l
Connection persistence using cookies or IP addresses
l
Real-time server and cluster performance monitoring
l
Server and cluster administration from a single interface
l
SSL acceleration (on Equalizer models with Xcel SSL Hardware Acceleration)
l
Data compression (on Equalizer models with Express Hardware GZIP Compression)
l
Geographic load balancing
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Typographical Conventions
The following typographical conventions appear throughout this guide:
l
l
l
Text in “double quotes” indicates the introduction of a new term.
Italic text is used primarily to indicate variables in command lines, and is also used to
emphasize concepts while discussing Equalizer operation.
Boldface text highlights GUI interface screen elements: labels, buttons, tabs, icons, etc., as
well as data the user must type into a GUI element.
l
Courier text denotes computer output: messages, commands, file names, directory
names, keywords, and syntax exactly as displayed by the system.
l
l
Bold courier text is text the user must type at the CLI prompt. Bold courier text in
brackets -- indicates a keyboard key or key sequence that must be typed.
Bold text sequences such as “Cluster > Configuration > Settings” are used to indicate the GUI
controls a user needs to click to display the GUI form relevant to the task at hand. In the
above example, the user would click on the Equalizer host name displayed at the top of the
left navigational tree , click on the Configuration tab in the right pane, and then click on the
Settings tab.
1. Numbered lists show steps that you must complete in the numbered order.
l
Bulleted lists identify items that you can address in any order.
Note - A note box in the margin cites the source of information or provides a brief explanation that supports a specific
statement but is not integral to the logical flow of the text.
The symbol on the left emphasizes a critical note or caution.
Attributions
Many of the icons used in the Web UI and reproduced in this manual are © Copyright 2013
FatCow Web Hosting. All rights reserved. These icons are licensed under a Creative Commons
Attribution 3.0 License (http://creativecommons.org/licenses/by/3.0/us/) and are used without
modification.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
21
Introduction
Where to Go for More Help
These instructions are part of the product documentation delivered with Equalizer’s browserbased GUI. You can display the appropriate manual section for any interface screen by selecting
Help > Context help from the menu at the top of the interface. The Help menu also contains links to
the Release Notes for the currently running software version, and other documentation.
Hard copy documentation provided with every Equalizer includes the Quick Start Guide and the
Basic Configuration Guide. These two documents are designed to help you get Equalizer out of the
box and working with your first virtual clusters. The Basic Configuration Guide also contains a
Resource CD with copies of all product documentation, including support documents that help you
configure Equalizer for a variety of environments.
Register today to get access to the Fortinet Support Portal:
https://support.fortinet.com
Registration provides you with a login so you can access these benefits:
l
l
l
l
l
Support FAQs: answers to our customer's most common questions.
Moderated Customer Support Forum: ask questions and get answers from our support staff
and other Equalizer users.
Software upgrades and security patches: access to the latest software updates to keep your
Equalizer current and secure.
Online device manuals, supplements, and release notes: the latest Equalizer documentation
and updates.
Links to additional resources, and more.
Registration details can be found in "Registering Your Product" on page 76.
22
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
FortiADC E Series Handbook
Chapter 2
Overview
Sections within this chapter include:
Intelligent Load Balancing
Real-Time Server Status Information
Network Address Translation and Spoofing
Load Balancing
How a Server is Selected
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
24
25
26
28
30
23
Overview
Intelligent Load Balancing
The Equalizer appliance functions as a gateway to one or more sets of servers organized into
virtual clusters. When a client submits a request to a site that the appliance manages, it identifies
the virtual cluster for which the request is intended, determines the server in the cluster that will
be best able to handle the request, and forwards the request to that server for processing.
To route the request, the appliance modifies the header of the request packet with the appropriate
server information and forwards the modified packet to the selected server. Depending on the
cluster options chosen, it may also modify the headers in server responses on the way back to the
client.
Equalizer supports clusters that route requests based on either Layer 4 (TCP or UDP) or Layer 7
(HTTP or HTTPS) protocols. Layer 4 is also referred to as the Transport Layer, while Layer 7 is
referred to as the Application Layer. These terms come from the OSI and TCP/IP Reference
Models, abstract models for network protocol design.
In general, Layer 4 clusters are intended for configurations where routing by the destination IP
address of the request is sufficient and no examination of the request headers is required. Layer 7
clusters are intended for configurations where routing decisions need to be made based on the
content of the request headers. the appliance evaluates and can modify the content of request
headers as it routes packets to servers; in some cases, it can also modify headers in server
responses on their way back to the client.
Basic Capabilities of Cluster Types Supported by Equalizer
Cluster Type
Feature
L4 UDP
Load balancing
policies
Server failure
detection (probes)
Persistence
Server selection by
request content
(i.e., Match Rules)
Load balanced
protocols
NAT and spoofing
24
L4, L7 TCP
L7 HTTP
L7 HTTPS
Round Robin, Static Weight, Adaptive, Fastest response,
Least Connections, Server Agent, Custom
ICMP, TCP, Health Check
ICMP, TCP, ACV, Health Check
Based on IP
Using Cookies
No; load is balanced according to current load balancing policy.
Yes; load is balanced
according to decisions
made by examining request
content.
Ideal for stateless UDPbased protocols, such as
DNS and RADIUS; WAP
gateways; NFS server
clusters that provide a
single-system image.
Ideal for stateful TCP-based
protocols, such as HTTP,
HTTPS, SMTP, FTP,
LDAP/LDAPS
and others.
HTTP
HTTPS
Yes
Copyright © 2015 Fortinet, Inc.
FortiADC E Series Handbook
Regardless of cluster type, the appliance uses intelligent load balancing algorithms to determine
the best server to receive a request. These algorithms take into account the configuration options
set for the cluster and servers, real-time server status information, and information from the
request itself. For Layer 7 clusters, user-defined match rules can also be used to determine the
route a packet should take.
Real-Time Server Status Information
Equalizer gathers real-time information about a server’s status using ICMP Probes, TCP Probes,
Active Content Verification (ACV), and Server Agents. ICMP and TCP Probes are the default
probing methods.
ICMP Probes use Internet Control Message Protocol to send an "Echo request" to the server, and
then wait for the server to respond with an ICMP "Echo reply" message (i.e., the Unix ping
command). ICMP is a Layer 3 protocol. ICMP probes can be disabled via a global flag.
TCP Probes establish (and tear down) a TCP connection between the appliance and the server in a
typical Layer 4 exchange of TCP SYN, ACK, and FIN packets. If the connection cannot be
completed, the appliance considers the server down and stops routing requests to it. TCP probes
cannot be disabled.
Active Content Verification (ACV) provides an optional method for checking the validity of a
server’s response using Layer 7 network services that support a text-based request/response
protocol, such as HTTP. When you enable ACV for a cluster, the appliance requests data from each
server in the cluster (using an ACV Probe string)and verifies the returned data (against anACV
Response string). If it receives no response or the response string is not in the response, the
verification fails and it stops routing new requests to that server. See "Configuring ACV Health
Checks" on page 544 for more information.
Note - ACV is not supported for Layer 4 UDP clusters.
Server Agent Probes enable the appliance to communicate with a user-written program (the
agent) running on the server. A server agent is written to open a server port and, when the
appliance connects to the port, the server agent responds with an indication of the current server
load and performance. This enables adjustment of the dynamic weights of the server according to
detailed performance measurements performed by the agent, based on any metrics available on
the server. If the server is overloaded and you have enabled server agent load balancing, the
appliance reduces the server’s dynamic weight so that the server receives fewer requests. The
interface between the appliance and server agents is simple and well-defined. Agents can be
written in any language supported on the server (e.g., perl, C, shell script, javascript, etc.). See
"Configuring Server Agent Health Checks" on page 584for more information.
For those who have one or more VMware ESX Servers, VLB can be configured to use VMware’s
status reporting to determine server status, and can also be configured to automatically manage
VMware servers based on status information obtained from VMware.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
25
Overview
Network Address Translation and Spoofing
The servers load balanced by Equalizer provide applications or services on specific IP addresses
and ports, and are organized into virtual clusters, each with its own IP address. Clients send
requests to the cluster IP addresses on the appliance instead of sending them to the IP addresses
of the servers.
Central to the operation of any load balancer is the Network Address Translation (NAT)
subsystem. On Equalizer, NAT is used as follows:
1. When Equalizer receives a client packet, it always translates the destination IP (the cluster
IP) to the IP address of one of the server instances in a server pool. The server IP used is
determined by the cluster’s load balancing settings.
2. Depending on the setting of the cluster spoof option, Equalizer may also perform Source
NAT, or SNAT.
When the spoof option is enabled on a cluster, then SNAT is disabled: the NAT subsystem
leaves the client IP address as the source IP address in the packet it forwards to the server.
For this reason, the servers in a cluster with spoof enabled are usually configured to use
Equalizer’s IP address as their default gateway to ensure that all responses go through the
appliance (otherwise, the server would attempt to respond directly to the client IP).
When the spoof option is disabled on a cluster, then SNAT is enabled. Equalizer translates
the source IP (the client IP) to one of the appliance’s IP addresses before forwarding
packets to a server. The servers will send responses back to the appliance’s IP (so it is
usually not necessary to set the appliance as the default gateway on the servers when spoof
is disabled).
Match rules can be used to selectively apply the spoof option to client requests. This is
sometimes called selective SNAT. See "Creating a New Match Rule" on page 428.
3. When a server sends a response to a client request through Equalizer, the NAT subsystem
always translates the source IP in the response packets (that is, the server IP) to the cluster
IP to which the client originally sent the request. This is necessary since the client sent its
original request to the cluster IP and will not recognize the server’s IP address as a
response to its request -- instead, it will drop the packet.
26
Copyright © 2015 Fortinet, Inc.
FortiADC E Series Handbook
4. NAT can also be enabled for packets that originate on the servers behind Equalizer and are
destined for subnets other than the subnet on which the servers reside -- on the appliance,
this is called outbound NAT. This is usually required in dual network mode when reserved IP
addresses (e.g., 10.x.x.x, 192.168.x.x) are being used on the internal interface, so that the
recipients do not see reserved IP addresses in packets originating from the servers. When
the global outbound NAT option is enabled, the appliance translates the source IP in packets
from the servers that are not part of a client connection to the the appliance’s Default VLAN
IP address (the external interface IP address on the E250GX and legacy ‘si’ systems), or to
the address specified in the server’s Outbound NAT tab. Enabling outbound NAT, as a result,
has a performance cost since the appliance is examining every outbound packet.
Note - When Equalizer is in single network mode, outbound NAT should be disabled. Since Equalizer resides on a
single subnet, outbound NAT is not needed, and may cause unexpected behavior.
When Equalizer receives a packet that is not destined for a virtual cluster IP address, a failover IP
address, a client IP address on an open connection, or one of its own IP addresses, the appliance
passes the packet through to the destination network unaltered.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
27
Overview
Load Balancing
Load balancing is based on the policy selected. The policies can be split up into two categories:
1. round robin
2. everything else
Round robin simply selects the next server in the list with no regard for how busy that server may
be.
Other load balancing policies use proprietary algorithms to compute the load of a server and then
select the server with the least load server.
Although the load balancing policies are proprietary, they use the following factors in their
calculation:
l
Active connections - The number of connections a server currently has active and the number
of connections that it tends to have open.
l
l
Connection latency - The amount of time that it takes a server to respond to a client request.
Health check performance values - Depending on the health checks configured, this may be not
used at all, or it can completely define how the load is calculated.
Once a load is calculated, Equalizer distributes incoming requests using the relative loads as
weights.
sv00
Load = 50
sv01
Load = 50
sv02
Load = 50
Equalizer calculated loads, so the request distribution will be approximately equal
sv00
Load = 100
sv01
Load = 50
sv02
Load = 25
sv01 and sv02 above are uneven loads. sv01 is twice as loaded as sv02, so it will receive about
half the requests.
The load calculations happen approximately every 10 seconds and server weights are adjusted
accordingly. During that 10 second interval, the relative server loads remain the same, but probe
and health check information is collected about the servers so that it can be used for the next
calculation.
The load calculation works the same for Layer 4 and Layer 7 clusters (at the server-pool level –
and these can be shared between all cluster types).
28
Copyright © 2015 Fortinet, Inc.
FortiADC E Series Handbook
There are two additional variables for load balancing:
l
Hot spare - if a server instance (in a server pool) is marked as a Hot Spare, it is not included in
the pool of servers to select from unless every other non-hot-spare server is down. If a
connection persists to this server, it will be placed back on this server.
l
Quiesce - If a server instance (in a server pool) has been marked as Quiesce, it will not be
included in the pool of servers to select from. Only previously existing (persistent)
connections will be made to this server.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
29
Overview
How a Server is Selected
The main functionality of Equalizer is to load-balance-- that is that when a request is received
from a client an appropriate server for to connect the request with. The "appropriate" server is
usually selected as part of a proprietary load balancing algorithm or via round-robin. Another
factor in server selection is "persistence". If a client connection has persistence associated with it,
the server to which the persists should be selected for load balancing If the server selected by
persistence is not available, the appliance uses load balancing policy to select an alternate server.
Server Selection Process Flow
The figure below shows the server selection process. As describe above, this process depends on
whether persistence is in use. Once a server is selected, Equalizer verifies that it isn’t too busy
(based on max_connections) and that it has been probed up. Then Equalizer tries to connect to it.
The figure below shows the connection establishment and server failover mechanism.
30
Copyright © 2015 Fortinet, Inc.
FortiADC E Series Handbook
For Layer 7 clusters, the connection must be established within the connect_timeout . If we receive
an active refusal (RST) from a server, we will repeat the load balancing process and choose
another server. Otherwise we will continue trying to connect to the same server until the connect
timeout expires.
Fore Layer 4 clusters, the connection must be established within the stale_timeout . Here, the
appliance retries the same server 3 times, and then chooses another server on the 4th attempt. If
the appliance receives an active refusal (RST) from a server, the connection is dropped.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
31
Overview
Layer 7 Load Balancing and Server Selection
Equalizer’s support for Layer 7 content-sensitive load balancing enables administrators to define
rules for routing HTTP, HTTPS, and special Layer 7 TCP requests, depending on the content of the
request. Layer 7 load balancing routes requests based on information from the application layer.
This provides access to the actual data payloads of the TCP/UDP packets exchanged between a
client and server. For example, by examining the payloads, a program can base load-balancing
decisions for HTTP requests on information in client request headers and methods, server
response headers, and page data.
Equalizer’s Layer 7 load balancing allows administrators to define rules in the administration
interface for routing HTTP and HTTPS requests according to the request content. These rules are
called match rules. A match rule might, for example, route requests based on whether the request
is for a text file or a graphics file. For example, you may want to:
l
load balance all requests for text files (html, etc.) across servers A and B
l
load balance all requests for graphics files across servers C, D, and E
l
load balance all other requests across all of the servers
Match Rules are constructed using match functions that make decisions based on the following:
l
HTTP protocol version; for HTTPS connections, the SSL protocol level the client uses to
connect.
l
Client IP address
l
Request method (GET, POST, etc.)
l
All elements of the request URI (host name, path, file name, query, etc.)
l
Pattern matches against request headers
Match functions can be combined using logical constructs (AND, OR, NOT, etc.) to create
extremely flexible cluster configurations. See "Managing Match Rules" on page 426 for an
overview of Match Rules, a complete list of match functions, and usage examples.
32
Copyright © 2015 Fortinet, Inc.
Equalizer Administration Guide
Persistence
Persistence refers to the ability of a load-balancer (or other traffic management solution) to
maintain a virtual connection between a client and a specific server.It is often referred to in the
application delivery networking world as "stickiness" .The persistence of session data is important
when a client and server need to refer to data previously generated again and again as they
interact over more than one transaction, possibly more than one connection. Whenever a client
places an item in a shopping cart, for example, session data (the item in the cart, customer
information, etc.) is created that potentially needs to persist across many individual TCP
connections before the data is no longer needed and the session is complete.
It’s important to note that session persistence is managed by the server application, not
Equalizer. the appliance provides server persistence so that a persistent connection between a
particular client and a particular server can be maintained; this supports a client-server session
where session data is being maintained on the server for the life of the connection. In other
words, whether you need to enable persistence on the appliance depends on the application you
are load balancing.
Equalizers have no knowledge of the fact that the user has placed something in a shopping cart,
logged into a web application, requested a file from shared storage, or made a "post" in a front
end presentation server that has been written to a database. Basically, a "state" has been created
in the load balanced application of which Equalizer is not aware. What the appliance does know is
that a specific client has been load balanced to a specific server in one of its virtual clusters. With
this knowledge, it can track that information and send that client back to the same server they
were connected the first time.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
33
Overview
Layer 7 Persistence
Equalizer provides server or connection persistence using cookies in Layer 7 HTTP and HTTPS
clusters. The following paragraphs explain connection persistence provided by the appliance, and
its relationship to session persistence.
When a request from a client that has not previously connected to the cluster is received by
Equalizer, it is load balanced according to the current server load values as described in "Load
Balancing" on page 28.
However, when a client has existing persistence to a server, Equalizer attempts to put the client
back on that server.
Equalizer can use cookies or a server’s IP address to maintain a persistent session between a
client and a particular server. A cookie, used in Equalizer HTTP and HTTPS clusters contains the
identity of the server that should be used. When a client connects to the cluster for the first time,
Equalizer injects this cookie into the response data. The client’s browser is then responsible for
presenting this cookie back to Equalizer. If Equalizer finds this cookie in the client’s request, it
connects to the server listed.
EQ/OS 10 features "fallback persistence" where Equalizer provide a secondary persistence option
where if, for example, a cookie response is not received, a secondary, or "fallback" option can be
used. As an example, if two persist methods are listed (e.g., Cookie 1:Cluster IP, Server IP /Port
and Source IP)- if a cookie is found- the cookie will be used, otherwise the Source IP of the
incoming connection will be used. If the server with which a client has an unavailable persistent
session, Equalizer automatically selects a different server. Then, the client must establish a new
session; Equalizer stuffs a new cookie in the next response. Details and scenarios are presented
in "Fallback Persistence Scenarios" on page 376.
34
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 4 Persistence
For Layer 4 TCP and UDP clusters, Equalizer support IP address-based persistent connections.
With a sticky connection option enabled, Equalizer identifies clients by their IP addresses when
they connect to a cluster. It then routes requests received from a particular client during a
specified period of time to the same server pool in the cluster.
A sticky timer measures the amount of time that has passed since there was a connection from a
particular IP address to a specific cluster. The sticky time period begins to expire as soon as there
are no longer any active connections between the client and the selected cluster. Equalizer resets
the timer whenever a new connection occurs. If the client does not establish any new connections
to the same cluster, the timer continues to run until the sticky time period expires. At expiration,
Equalizer handles any new connection from that client like any other incoming connection and
routes it to an available server based on the current load balancing policy.
To correctly handle sticky connections from ISPs that use multiple proxy servers to direct user
connections, Equalizer supports sticky network aggregation, which uses only the network portion
of a client's IP address to maintain a persistent connection. Sticky network aggregation directs
the user to the same server no matter which proxy he or she connects through.
Equalizer can also be configured to ensure that it directs requests from a particular client to the
same server pool even if the incoming connection is to a different cluster. When you enable inter
cluster stickiness for a Layer 4 cluster, Equalizer checks the cluster for a sticky record as it
receives each connection request, just like it does for ordinary sticky connections. If the appliance
does not find a sticky record, it proceeds to check all of the other clusters that have the same IP
address. If it still does not find a sticky record, it connects the user based on the current load
balancing policy.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
35
Overview
Why a Server May Not Be Selected
There are several reasons that a server may not be selected by Equalizer:
1. The various configured health checks within Equalizer have detected that a server is
"down". If a server is marked "down" by a health check, it is immediately removed from the
pool of servers available for load balancing.
2. For Layer 4 clusters, if health checks have not yet detected that a server is "down", and
Equalizer is unable to establish a cluster connection with the server, it will keep retrying the
same server until the 4th SYN packet received from the client and then use the load
balancing policy to select a new server. The whole connection establishment must complete
within the configured stale_timeout time frame or the connection will be dropped. If Equalizer
chooses a different server than the persistence record, it overwrites the persistence record
to use the new server for next time.
Note - Most clients will not have time to retry 3 times (send a 4th SYN packet) within the default 10 second stale
timeout window. Therefore the connection will be dropped and the process will be started over again when the next
SYN is received. (The 1st SYN would be at time 0, the 2nd at time 3, the 3rd at time 9… so the 4th would not happen
before 10 seconds).
3. For Layer 7 clusters, if health checks have not yet detected that the server is "down" but
Equalizer is unable to establish a cluster connection with the server, it will wait the
configured connect_timeout time frame and then drop the connection so that the client can
retry. If it receives an active refusal from the server (RST packet), Equalizer will choose a
different server and overwrite the persistence record to use the new server for next time.
4. Maximum connections - If the Maximum Connections option is used for a server instance, and
the server already has that many active connections, it will not be used. This means that it
will not be included in the list of servers to select for load balancing. If persistence is in use,
the strict_max_connections flag specifies whether to persist to a server which already has more
active connections than max_connections or to load balance to a new server.
5. If the persist_override flag is selected in a server instance, and that server is selected by the
load balancing policy, the client will not persist to this server even if persistence is enabled
at the cluster level.
36
Copyright © 2015 Fortinet, Inc.
Equalizer Administration Guide
Chapter 3
What's New
Subsections in this chapter include:
What's New
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
38
37
What's New
What's New
The list below contains changes in this documentation since the previous release. For additional
upgrade information, refer to the Release Notes available with the firmware.
For 10.3.2f:
1. Documentation Enhancements:
l
l
l
Load Balancing Networking is a reorganized version of the previous
Network Configuration Chapter with a better flow of networking details.
Failover is a reorganized version of the previous Failover chapter that
provides a better flow of failover and configuration information.
A new Security and Protection chapter provides details on the new DDoS
feature. In addition, the IP Reputation subsection has been moved to this
chapter.
2. New Feature Descriptions:
l
l
DDoS -- A new Distributed Denial of Service (DDoS) protection feature has
been added to Equalizer. Details on the deployment of this feature with
Equalizer and can be found in the new Security and Protection chapter. In
addition to DDoS, the IP Reputation feature is added as part of the new
Protection chapter as well as Access Control List configuration.
HTTP and HTTPS Application Health Checks- Equalizer now features HTTP
and HTTPS application health check. These are “liveness” health checks that
probe server applications for specific data. They can be thought of as enhanced
HTTP-specific versions of Active Content Verification (ACV) health checks with
built-in knowledge of HTTP-protocol-specific parameters. With HTTP and HTTPS
health checks, an application's availability status is determined by examining
specific attributes of the response received for the values specified in the health
check.
3. Feature Update Descriptions:
Additional Header Editing Functions have been added to the "HTTP and HTTPS
Header Editing" appendix. The new functions include the use of && /OR operators as
well as a new statistical feature that tracks how the header editing scripts are
processed.
38
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
4. Command, Configuration, and Miscellaneous Change Descriptions:
Cluster CLI Command Summary Changes -- the CLI Cluster Command Summary
section has been updated to include the new commands used with Cluster Service
Protection Profiles.
Header Editing CLI Command Summary -- a new Header Editing CLI Command
Summary has been added.
Health Check CLI Command Summary -- the Health Check CLI Command
Summary has been updated to reflect the commands used with the new HTTP and
HTTPS Application Health Checks.
Protection CLI Command Summary -- a new Protection CLI Command Summary
has been added showing the commands used with DDoS, Service Protection Profile, IP
Reputation, and Access Control list commands. The previous IP Reputation Command
Summary has been integrated in this summary.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
39
Equalizer Administration Guide
Chapter 4
Installation
Sections within this chapter include:
Hardware Installation
UL/cUL & CE/CB Safety Warnings and Precautions
Power Requirements
Operating Environment
Regulatory Certification
Setting Up a Terminal or Terminal Emulator
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
42
43
45
45
45
46
41
Installation
Hardware Installation
To install Equalizer, proceed with the following:
1. Carefully remove the rack-mount enclosure and cables from the shipping container.
Save the original packaging in case you need to ship the appliance for any reason, such as
sending it in for warranty service. The chassis does not contain any parts that you can
service. If you open the chassis or attempt to make repairs, you may void your warranty.
2. Place the appliance in its intended position in an EIA equipment rack or on a flat surface.
3. Connect a serial terminal or a workstation running terminal emulator software to the serial
port on the front panel of appliance. The serial cable is supplied with the unit.
4. Connect the appliance to the network with a quality category 5 (Cat 5E) network cable:
To use Equalizer as an intermediary between an external and internal network, connect it to the
external network using one of the RJ-45 ports labeled 1 or 2 on the front panel. Connect the
appliance to the internal network using one or more of the ports numbered 3 and above.
For a single-network (one subnet) topology, connect Equalizer to the network and the servers
using one of the numbered RJ-45 ports numbered 3 and above on the front panel.
5. Connect the appliance to an appropriate power source using the supplied power cord, which
plugs into the 3-pin connector on the rear of the enclosure. This system uses an autosensing power supply that can operate at 50Hz or 60Hz, 110-240 VAC input.
6. Turn on the power using the switch on the rear panel.
42
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
UL/cUL & CE/CB Safety Warnings and Precautions
Risk of explosion if battery is replaced by an incorrect type. Dispose of used batteries
according to your local regulations.
Switzerland: Annex 4.10 of SR814.013 applies to batteries.
Statement in Chinese text:
警告
本電池如果更換不正確會有爆炸的危險
請依製造商說明書處理用過之電池
Rack mount instructions:
Elevated Operating Ambient - If installed in a closed or multi-unit rack assembly, the operating
ambient temperature of the rack environment may be greater than room ambient. Therefore,
consideration should be given to installing the equipment in an environment compatible with the
maximum ambient temperature (Tma) specified by the manufacturer.
Reduced Air Flow - Installation of the equipment in a rack should be such that the amount of air flow
required for safe operation of the equipment is not compromised.
Mechanical Loading - Mounting of the equipment in the rack should be such that a hazardous
condition is not achieved due to uneven mechanical loading.
Circuit Overloading - Consideration should be given to the connection of the equipment to the supply
circuit and the effect that overloading of the circuits might have on overcurrent protection and
supply wiring. Appropriate consideration of equipment nameplate ratings should be used when
addressing this concern.
Reliable Earthing - Reliable earthing of rack-mounted equipment should be maintained. Particular
attention should be given to supply connections other than direct connections to the branch circuit
(e.g. use of power strips).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
43
Installation
Grounding:
Ensure your product is connected and properly grounded to a lightning and surge protector.
WAN or LAN connections that enter the premises from outside the building should be connected to
an Ethernet CAT5 (10/100 Mb/s) surge protector.
Shielded Twisted Pair (STP) Ethernet cables should be used whenever possible rather
than Unshielded Twisted Pair (UTP).
Do not connect or disconnect cables during lightning activity to avoid damage to your
product or personal injury.
Electrostatic discharge (ESD) can damage equipment. Only perform the procedures described in
this document from an ESD workstation. If no such station is available, you can provide some ESD
protection by wearing an anti-static wrist strap and attaching it to an available ESD connector or
other bare metal object.
Regulatory Notices
For Class A – Regular ITE products
Federal Communication Commission (FCC) – USA
This device complies with Part 15 of FCC Rules. Operation is subject to the following two
conditions:
This device may not cause harmful interference, and
This device must accept any interference received, including interference that may cause
undesired operation.
This equipment has been tested and found to comply with the limits for a Class A digital device,
pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection
against harmful interference when the equipment is operated in a commercial environment. This
equipment generates, uses, and can radiate radio frequency energy, and if it is not installed and
used in accordance with the instruction manual, it may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful
interference, in which case the user will be required to correct the interference at his own
expense.
Warning: Any changes or modifications to this product not expressly approved by the party
responsible for compliance could void the user’s authority to operate the equipment.
Industry Canada Equipment Standard for Digital Equipment (ICES) –
Canada
CAN ICES-3 (A) / NMB-3 (A)
This digital apparatus does not exceed the Class A limits for radio noise emissions from digital
apparatus set out in the Radio Interference Regulations of the Canadian Department of
Communications.
Le présent appareil numérique n’emet pas de bruits radioélectriques dépassant les limites
applicables aux appareils numeriques de la classe A préscrites dans le Règlement sur le brouillage
radioélectrique édicte par le ministère des Communications du Canada.
44
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Voluntary Control Council for Interference (VCCI) – Japan
この装 置 は、クラスA情 報 技 術 装 置 です。この装 置 を 家 庭 環 境 で使 用 すると電 波 妨 害 を引 き起 こすことが あります。この場 合 には使 用 者 が
適 切 な対 策 を講 ずるよう要 求 されることがあります。VCCI
-A
Bureau of Standards Metrology and Inspection (BSMI) – Taiwan
這 是 甲 類 的 資 訊 產 品 ,在 居 住 的 環 境 中 使 用 時 ,可 能 會 造 成 射 頻 干 擾 ,在 這 種 情 況 下 ,使 用 者 會 被 要 求 採 取 某 些 適 當 的 對 策 。
China
此 为 A级 产 品 ,在 生 活 环 境 中 ,该 产 品 可 能 会 造 成 无 线 电 干 扰 。在 这 种 情 况 下 ,可 能 需 要 用 户 对 其 采 取 切 实 可 行 的 措 施 。
European Conformity (CE) – EU
This is a Class A product. In a domestic environment, this product may cause radio interference,
in which case the user may be required to take adequate measures.
IMPORTANT: Switzerland: Annex 4.10 of SR814.013 applies to batteries.
Power Requirements
The unit’s power supply is rated at 100-240 VAC auto selecting 60/50 Hz @ 4.0A.
Operating Environment
l
Temperature: 40 - 105 °F, 5 - 40 °C. (GX Series)| 32 - 104°F, 0 - 40°C (LX Series)
l
Humidity: 5 - 90%, non-condensing.
Regulatory Certification
Please see the product data sheets on the Coyote Point Website (www.coyotepoint.com) for
product certification details.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
45
Installation
Setting Up a Terminal or Terminal Emulator
When you set up Equalizer for the first time, you must use a serial connection in order to
configure the appliance's network with the eqcli interface. Connect the serial port on the to the
serial port on a terminal, or any system (such as a Windows or Unix PC) running terminal
emulation software.
Configure your terminal or terminal emulator software to use the following settings:
l
9600 baud (GX Series) 38400 (LX Series)
l
8 data bits
l
no parity
l
one stop bit
l
VT100 terminal emulation
l
ignore hang-ups (if supported); this allows a single terminal session to continue running
even if the appliance restarts
On Windows systems, you can use the Windows built-in terminal emulator, HyperTerminal, or the
Tera Term Pro terminal emulator to log in over the serial port. On Unix systems, you can use the cu
(1) command or any other Unix serial communication program.
If you use HyperTerminal, in addition to the settings shown above, select File > Properties > Settings
from HyperTerminal’s menu, select VT100 in the Emulation drop-down box, and then Terminal Setup
to enable these options:
l
keyboard application mode
l
cursor keypad mode
Tera Term is freely available at:
http://hp.vector.co.jp/authors/VA002416/teraterm.html
Terminal Sizing
The Equalizer CLI has a fixed idea of the size (lines, columns) of the terminal to which it is
connected. This could possibly cause lines to wrap at inconvenient places. The eqcli > resize
command determines the size of the terminal and updates the environment. This command is
useful when logged in via console and the window size changes.
46
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 5
Configuring Access
Sections within this chapter include:
Default Login
Serial Access
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
48
48
47
Configuring Access
Default Login
Equalizer's default login credentials for both the CLI and GUI are:
Username: touch
Password: touch
For security, you should change the login for the touch user the first time you log in. You can do
this by logging into the CLI, entering the following command, and following the command
prompts:
eqcli > user touch password
Creating Additional Logins
You can create additional administrative logins and assign specific permissions to individual
logins, if desired.
Serial Access
Serial access is provided via the serial port on Equalizer’s front panel. A serial connection is
required for activities during which the appliance may lose network connectivity. This includes:
l
Configuring network connectivity for the first time
l
Performing upgrades of the EQ/OS software and switch firmware
l
48
Re-configuring network access for services such as HTTP and SSH, when you cannot login
over the network interfaces currently configured or you are changing the network interfaces
that will provide those services.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 6
Upgrading and Downgrading
Sections within this chapter include:
EQ/OS 8.6 Upgrade Procedure
Upgrading to the Latest Firmware Release
Downgrading to an Earlier Firmware Release
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
50
56
57
49
Upgrading and Downgrading
EQ/OS 8.6 Upgrade Procedure
To upgrade your EQ/OS 8.6 Equalizer to EQ/OS 10:
1. Connect Equalizer with a serial console. Refer to "Setting Up a Terminal or Terminal
Emulator" on page 46.
2. Set up a local FTP server that can be accessed by Equalizer. This will be used during the
upgrade process to save a EQ/OS 8.6 system image that can be used to restore Equalizer to
EQ/OS 8.6. The creation of the restore image is required in order to be able to downgrade
Equalizer back to EQ/OS 8.6.
Important - The EQ/OS 8.6 system must have the latest release of EQ/OS 8.6 on both disk
partitions, running the same configuration. To accomplish this, do one of the following:
• If you are already running the latest EQ/OS 8.6 release, upgrade to the same version of
EQ/OS 8.6 again.
• If you are not running the latest EQ/OS 8.6 release, upgrade to the latest EQ/OS 8.6
release, reboot, and then upgrade to the latest 8.6 release again.
3. Equalizer must be running from the first disk partition when you begin the upgrade. The easiest way to
ensure this is to reboot the unit and press F1 (the first function key on the keyboard) when
the following prompt appears:
F1
FreeBSD
F2
FreeBSD
Default: F1
The "Default:" line above may contain "F1" or "F2". Press F1 regardless of what
is displayed on the "Default:" line.
4. Log into the EQ/OS 8.6 console as root using the serial port on Equalizer’s front panel. [An
upgrade to EQ/OS 10 cannot be performed using the EQ/OS 8.6 GUI, nor can it be
performed over an SSH connection. You must login using the serial console interface.
5. At the system prompt, enter:
eqadmin
The eqadmin interface menu is displayed.
6. Select option "8 Upgrade" by pressing the "8" key followed by "Enter" on the console
keyboard.
50
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
7. Do one of the following:
l
Press "1" followed by "Enter" to download the upgrade image from the Coyote Point web site.
l
Press "2" followed by "Enter" to download the upgrade image from a local server.
8. Enter the upgrade URL using the EQ/OS 8.6 syntax and press "Enter". For example, the
following URL downloads the image from a local server:
ftp://10.0.0.121/pub/patches/upgrades/10.0.0/os8upgrade/upgrade.tgz
9. Once the upgrade image is downloaded, the following prompt is displayed:
Equalizer OS 8.6 -> OS 10.x UPGRADE SCRIPT
This script will COMPLETELY REMOVE your existing Equalizer configuration
and replace it with a blank (unconfigured) installation of EQ/OS version
10.
If you proceed further, load balancing will be disabled on this
Equalizer until it is next rebooted, even if the upgrade fails.
Continue with upgrade [Y/N]?
Press "Y" and then "Enter".
Note - You may see the following messages during an upgrade:
tar: Unable to access licenses (No such file or directory)
tar: WARNING! These file names were not selected:licenses
The 'licenses' directory is an artifact of earlier releases and is no longer needed (licenses are now stored in the
configuration file). The upgrade script, however, still expects it to be there; this will be fixed in a future release. This
issue is benign and does not indicate any problem with Equalizer upgrade, licensing,configuration, or behavior.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
51
Upgrading and Downgrading
10. The following prompt is displayed:
Requesting pid 460 to terminate.
It is safest to proceed only on a system with an active support
contract. It is recommended that you verify that your support
status by re-licensing this system using the online license
server now.
If this is not possible because your system does not have
Internet access, please contact Coyote Point or your Coyote
Point distributor to confirm active support status.
This Equalizer has serial number A09BA-16003.
Re-license system now [Y/N]?
Do one of the following:
If your network configuration will not allow Equalizer to contact the Coyote Point
license server over an internet connection, please call Coyote Point Support or your
local distributor to confirm your support status. Then, press "N" and "Enter" to proceed
with the upgrade. Two confirmation messages are displayed; to proceed, press "Y"
and then "Enter" at each prompt to proceed with the upgrade.
Otherwise, press "Y" and then "Enter" to request a new license. If successful, the
following message is displayed and contains Equalizer’s serial number:
Successfully re-licensed e450gx-1 serial_number.
11. The following message is displayed:
PERMANENTLY upgrade this system to EQ/OS 10 [Y/N]?
Press "Y" and then "Enter" to proceed with the upgrade.
52
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
12. The user is now prompted for the second stage upgrade URL:
This installer uses a 2-stage process. You must enter the URL for
the second-stage install bundle. It is usually the same URL from
which you retrieved the first-stage installer, except without the
last component.
For example, if you retrieved this installer from:
http://www.coyotepoint.com/example/upgrade.tgz
Then the second-stage install bundle URL would be:
http://www.coyotepoint.com/example/
Enter the URL:
Enter the second stage URL and press "Enter" to continue with the upgrade. In our
example, the second stage URL would be:
ftp://10.0.0.121/pub/patches/upgrades/10.0.0/os8upgrade
13. After the second stage upgrade files are downloaded, verified, and unpacked, you are asked
to create a restore image:
Upgrade bundle is EQ/OS 10.0.2a.
Checking that bundle is EQ/OS 8 to EQ/OS 10 type.
Retrieving autobuilds/folsomBuilds/18288/i386/binary/os8upgrade//is-os8
100%
11
00:00 ETA
It is very important to create a restore image of this Equalizer
running the current EQ/OS 8 software. This is not a standard
backup of the EQ/OS 8 system but an image which will allow you
to downgrade this particular system from EQ/OS 10 should you
so desire.
Without a restore image, this system can not be downgraded to
EQ/OS 8.
The restore image will require approximately 200MB of free space
on an FTP server to which you can upload files.
Do you want to create a restore image [Y/N]?
Press "Y" and then "Enter" to create a restore image.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
53
Upgrading and Downgrading
14. The system then prompts you to enter a URL for the restore image as well as a username
and password to :
Do you want to create a restore image [Y/N]?
^Cy
Cleaning up log and temporary files before restore imaging process.
Flushing disk write cache.
Building restore image.
3891+0 records in.1 MiB / 242.1 MiB = 0.348
1.2 MiB/s
3:23
3891+0 records out
255000576 bytes transferred in 204.873566 secs (1244673 bytes/sec)
100 %
85.3 MiB / 243.2 MiB = 0.351
1.2 MiB/s
3:24
Taking fingerprint of restore image.
Sending restore image to remote FTP server.
Enter URL for path to which to send restore image.
Example: ftp://ftp.coyotepoint.com/my_images/
15. You are now prompted for an FTP server to which the encrypted restore image can be
transferred:
Sending restore image to remote FTP server.
Enter URL for path to which to send restore image.
Example: ftp://ftp.coyotepoint.com/my_images/
Enter URL:
Enter Username for file upload:
Enter Password for file upload:
Enter the URL, and then a Username and Password to log into the FTP server.
16. After you supply the FTP login information, Equalizer uploads the image to the FTP server,
and then downloads it to verify that it is correct. If the verification succeeds, Equalizer
continues with the upgrade and reboots automatically after displaying this prompt:
Activating second stage install partition for next reboot.
rebooting -- this may take up to a full minute.
54
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
17. After rebooting, the system will automatically continue the upgrade by booting from the
second partition. DO NOT PRESS ANY KEYS WHEN THE BOOT MENU IS DISPLAYED. Wait for
the system to boot automatically. Once the system boots, it unpacks the EQ/OS 10 upgrade
image and creates the appropriate file systems. When it is done, the following prompts are
displayed:
The operating system has halted.
Please press any key to reboot.
18. Press any key to reboot the system.
19. As the system reboots, you may see prompts indicating that the front panel switch firmware
needs to be upgraded:
Switch firmware is down-level.
WARNING: This upgrade contains firmware which requires
an immediate reboot after installation, which will be
automatically performed.
The switch firmware is automatically upgraded if required. This process can take
several minutes.
Caution - DO NOT INTERRUPT THE SWITCH FIRMWARE UPGRADE IN ANY WAY. This includes
power cycling the unit. Interrupting the switch firmware upgrade can leave your system in
an inoperable state.
l
After successfully upgrading and validating the switch firmware, the system reboots
automatically. Once the system finishes rebooting, the console displays the EQ/OS 10 CLI
"Username:" prompt. You can now log into the CLI and configure Equalizer into your
network.
See "Basic Configuration" on page 62 for the basics of creating a VLAN over which you
can access the GUI and use SSH to log into the console.
See "Sample Configuration" on page 80 for a brief tutorial that explains how to
perform additional configuration tasks (creating servers, clusters, etc.) using the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
55
Upgrading and Downgrading
Upgrading to the Latest Firmware Release
Upgrade Path
The current Equalizer uses configuration file version 8. You can upgrade to any higher version of
the OS regardless of the version you are currently running.
Upgrade using the CLI
To upgrade a system that is already running EQ/OS 10 to the latest release using the CLI, do the
following:
1. Ensure that the upgrade image is available on an FTP or HTTP server that is accessible to
Equalizer. This can be either the Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Upgrade server or a local server.
2. Log in to the Equalizer CLI using the serial console or via SSH on a VLAN that is configured
for SSH access.
3. At the eqcli >prompt, enter:
eqcli > upgrade URL
The URL is an unadorned ftp:// or http:// URL that completely specifies the path to the
upgrade image directory, as in this example:
eqcli > upgrade ftp://X.X.X.X/pub/patches/upgrades/10.X.X/upgrade
4. Equalizer downloads the upgrade files automatically, unpacks them, and then begins the
upgrade. No user intervention is required.
When the upgrade is complete, the following messages are displayed:
Upgrade successfully completed. New version is default at next system boot.
5. To reboot the system and run the newly installed version, enter:
eqcli > reboot
Upgrade using the GUI
Refer to "Manage Software" on page 311 for instructions on upgrading using the GUI. After
upgrading, you should clear your browser cache before using the new version of the software.
56
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Downgrading to an Earlier Firmware Release
Refer to the following to downgrade the firmware on a system that is already running EQ/OS 10 to
an earlier release.
Refer to the Downgrade Path guidelines below before beginning.
Downgrade using the CLI
1. Ensure that the upgrade image is available on an FTP or HTTP server that is accessible to
Equalizer. This can be either the Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Upgrade server or a local server.
2. Log in to the Equalizer CLI using the serial console or via SSH on a VLAN that is configured
for SSH access.
3. At the eqcli >prompt, enter:
eqcli > upgrade URL
The URL is an unadorned ftp:// or http:// URL that completely specifies the path to the
downgrade image directory, as in this example:
eqcli > upgrade ftp://X.X.X.X/pub/patches/upgrades/10.X.X/upgrade
4. Equalizer downloads the upgrade files automatically, unpacks them, and then begins the
downgrade. No user intervention is required.
When the upgrade is complete, the following messages are displayed:
Upgrade successfully completed. New version is default at next system boot.
5. To reboot the system and run the newly installed version, enter:
eqcli > reboot
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
57
Upgrading and Downgrading
Downgrade using the GUI.
Refer to "Manage Software" on page 311 for instructions on downgrading the firmware using the
GUI. After downgrading, you should clear your browser cache before using the new version of the
software.
Downgrade Path
The table below shows the configuration file versions and their associated EQ/OS 10 releases.
Configuration file version 6 is the latest configuration file used. When you downgrade, you must
downgrade one configuration version at a time. For example, if you want to downgrade from
EQ/OS 10.3.1a to EQ/OS 10.1.0a, you must use the following downgrade sequence: 10.3.0a >
10.2.0a > 10.1.0a.
Configuration File Version
Equalizer LX/GX Releases
Version 1
All releases prior to 10.1.0a
Version 2
10.1.0a
Version 3
10.2.0a
Version 4
10.3.0a
Version 5
10.3.0e
Version 6
10.3.2a
Version 7
10.3.2d
Version 8
10.3.2e
58
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Downgrading from Releases that Support DDoS Protection
The downgrade process will not permit downgrade to proceed from a DDoS supported release to a
non-DDoS supported release if there are any entries in the blacklist. If you attempt to downgrade,
the following error message will appear in both the CLI and the GUI:
"The upgrade process has stopped because you are attempting to downgrade to a release that
does not support DDoS Protection. To successfully downgrade, you must first delete all entries in
the Access Control Lists (both the Blacklist and Whitelist).
Please see the “Upgrade and Downgrade” chapter in WebHelp for more information. This can be
viewed by opening the Web UI, pressing “F1”, and navigating to the chapter using the table of
contents on the left side of the WebHelp interface."
Recommended Procedure
1. Follow the procedures in "Backup and Restore" on page 305 and perform a backup.
2. Use the procedures in "Using Access Control Lists" on page 716 to display the current
Blacklist/Whitelist. When the IP addresses of the whitelisted/blacklisted entries are
displayed and you want to save them to use on the downgraded system, copy and paste the
list to a text file and save.
3. Delete all of the entries in the blacklist and blacklist using the CLI or GUI as described in
"Using Access Control Lists" on page 716.
4. Follow the procedures above to downgrade your firmware.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
59
Equalizer Administration Guide
Chapter 7
Basic Configuration
Subsections include:
Basic Configuration
Replacing the Default Certificate, Key, and Cipherspec
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
62
65
61
Basic Configuration
Basic Configuration
The following procedure is an example of how to configure VLANs using the Equalizer CLI. You
must configure VLANs using the CLI so that you can ultimately use the GUI. Follow the steps
below to get Equalizer onto your network .
1. Log in using the default administrative user name, touch:
Username: touch
Password: touch
Login successful.
EQ/OS 10.3.2f
Copyright 2015 Fortinet, Inc.
Welcome to Equalizer!
eqcli >
2. Change the password for the "touch" login. Enter:
eqcli > user touch passwd
Follow the command prompts to create a new password.
3. Create a VLAN , enter a command like the following:
eqcli > vlan vlname vid vlan_ID
Replace vlname with the VLAN name and vlan_ID with the VLAN ID number (14094). If you are using untagged VLANs (common in many sites), the VLAN ID can be
any number not used on another VLAN. If you are using tagged VLANs, check with
your network Administrator for the correct vid to specify.
62
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
4. Add a subnet to the VLAN you just created. You’ll need to specify the subnet IP address,
which is the load balancer's address on this network. It must be an IPv4 or IPv6 address in
CIDR format (e.g., 172.16.0.200/21).
Enter the following command syntax:
eqcli > vlan vlname subnet subnetname ip cidr_ip
In the command above, vlname is the VLAN name, netname is the name of the
subnet, cidr_ip is the CIDR format IP address. For example:
eqcli > vlan 172net subnet sn01 ip 172.16.0.200/21
5. Configure services on thesubnet. For our example, we’ll enable SSH login and the GUI over
HTTP on the 172net VLAN.
eqcli > vlan 172net subnet sn01 services http,https,ssh
6. Configure routing on the VLAN including a default route and gateway routes. In the example
below, 0/0 is the default route and 172.16.0.1 is the gateway, which is an unadorned
IP addresses. In this scenario, all packets fordestinations are to be sent via this routes.
eqcli > vlan 172net subnet sn01 route 0/0 gw 172.16.0.1
Refer to the webhelp if you need more help setting up your initial VLAN and subnet: go
to www.coyotepoint.com, move your mouse over the Support link near the top of the
screen, and choose Manuals from the drop down list.
5. Associate an interface instance with the VLAN. Here we assume that you are using the port
labeled "1" on the front panel. Enter one of the following commands, depending on whether
the VLAN you created above is untagged or tagged (ask your network administrator if you
are unsure).
eqcli > vlan vlname ifi if01 type untagged or eqcli > vlan vlname ifi if01
type tagged
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
63
Basic Configuration
6. Connect the port or ports you configured on the VLAN to the network using a standard
Ethernet cable with RJ-45 connectors. To confirm that the interface has come up, use the
following command:
eqcli > show interface
Interface Duplex Mode
ge01
NA
ge02
NA
ge03
NA
ge04
NA
ge05
NA
ge06
NA
ge07
NA
ge08
NA
xe01
full
xe02
full
mgmt
full
eqcli >
Speed
NA
NA
NA
NA
NA
NA
NA
NA
10G
10G
100M
Status
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Up
Link Up
Link Up
The above example shows the appropriate output assuming that you are using the
port labeled “1” on the front panel.
You should now be able to use the “ping” command from a workstation on the same
subnet to reach the subnet IP address configured above.
7. Connect the appliance to your network using the VLAN ports that you set up above. You
should now be able to display the GUI by pointing a browser at this URL:
http://VLAN_IP_addr
Substitute the VLAN IP address, as in this example using the IP address from Step 3.
64
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Replacing the Default Certificate, Key, and Cipherspec
Using Equalizer's Remote Management commands in the CLI, you can replace the default
certificate, key, and cipher spec that are used with HTTPS services on subnets with custom
certificates, keys and cipher specs.
The process includes:
l
Uploading the custom certificate and key file to the file store.
l
Entering the certificate (and key file) to be used with HTTPS services.
l
Replacing the default cipherspec with the a custom cipher spec.
l
Setting the encryption level to use in the communications between the client and the ADC.
Uploading the Custom Certificate and Key File
Enter the following to upload a certificate and key file:
1. Enter the name of the new certificate and upload it as follows:
eqcli > certificate certificatename certfile URL
where URL downloads the certfile using ftp:// or http:// protocol.
2. Upload the new key file. The key file must have the same name as the certificate.
eqcli > certificate certificatename keyfile URL
where URL downloads the keyfile using ftp:// or http:// protocol.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
65
Basic Configuration
Entering the Certificate and Key file to be Used with HTTPS Services
3. Set the certfile and keyfile to use using the CLI remote management commands. The
keyfile has the same name as the certfile and will be used automatically.
eqcli remote-mgmt certificate certificatename
4. Now view the remote management configuration. The example that follows shows that the
custom certificate has been added:
eqcli > show remote-mgmt
Options
Cipherspec
Certificate
Protocols
Value
AES128-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:AES256-SHA:!SSLv2
custom certificate
tls10
eqcli >
Replacing the Default Cipherspec with a Custom Cipherspec
5. Enter the custom cipherspec as follows:
eqcli > remote-mgmt cipherspec cipherspec
where cipherspec is the new, custom cipherspec to be used.
Setting the Encryption Levels
6. Configure the encryption levels that will be used in communications between the client and
the ADC. The default encryption level is TLSv1.0 (tls10).
eqcli > protocol protocol
where protocol can be sslv3, tls10(default), tls11, or tls12. The protocols in
the syntax can be delimited by "," or "|".
You can also turn off one of the protocols in the list by prefixing with "!". For example
if you have configured all of the encryption levels to be used and want to remove
tls12, enter eqcli > protocol !tls12. tls12 would then be removed from the
list. The client and ADP will use the highest level available when multiple formats are
specified.
66
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Reapplying the Default Certificate, Cipherspec and Protocols
To reapply the defaults for Cipherspec, Certificate or Protocol, enter any of the following:
eqcli > no remote-mgmt {cipherspec|certificate|protocol}
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
67
Equalizer Administration Guide
Chapter 8
Enabling Network Services
Subsections include:
Enabling Global Network Services
Enabling VLAN Subnet Network Services
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
70
72
69
Enabling Network Services
Enabling Global Network Services
In order to access Equalizer over the network, network services must be enabled globally (that is,
for all subnets) and on the specific subnets over which you want to provide access.
The Global Services settings provide a convenient way to enable and disable services on all
subnets, should the need arise. For example, when you are upgrading or performing a system
backup, it may be desirable to use the serial connection and disable all network services to ensure
that no other administrative users are accessing the system.
By default, all services are enabled globally:
Global Services Using the CLI
In the CLI, global services settings are managed using the global services parameter (see "Global
Commands" on page 190).
Global Services Using the GUI
Follow these steps to set the system Hostname, Date & Time, and DNS in the GUI:
1. Log into the GUI to perform additional configuration. On a workstation that is on the same
subnet that you configured above, or on a network that can route to and from the subnet
you configured above, open a web browser and enter Equalizer’s IP address into the
browser’s address bar. At the GUI login screen, enter the touch user name and the
password that you assigned earlier, and click Login. The Welcome screen for the Equalizer
GUI appears on the right pane.
2. On the left navigational pane, select System > Global > Parametersconfiguration tab in the left
pane. The Global Parameters screen will be displayed on the right pane.
a. Set the system Hostname to a name that is unique on your network.
b. Optionally set up to three Domain Name Servers.
c. Click on Commit .to save the settings.
3. Click on the arrow (u) beside Maintenance to expand the branch and select Date & Time to
display the Data & Time display on the right pane. In the Set Timezone field, locate your time
zone in the drop-down box and click Commit .
4. Do one of the following:
a. If Equalizercan connect to the Internet and you defined at least one DNS server
above, you can configure the Network Time Protocol (NTP). In the Automatically Set Date
and Time field, type the name of an NTP Server into the text box and turn on the Enable
NTP Synchronization check box. Click Commit .
b. Otherwise, set the date and time manually by modifying the contents of the Date field.
Click Commit .
70
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
The following global services settings are supported:
GUI
Global Service
(CLI)
HTTP
(http)
HTTP GUI service; when enabled, the Equalizer GUI will listen on all subnets on which HTTP
services are enabled.
HTTPS
(https)
HTTPS GUI service; when enabled, the Equalizer GUI will listen on all subnets on which HTTPS
services are enabled.
SSH
(ssh)
SSH login service; when enabled, SSH login will be permitted on all subnets on which SSH
services are enabled.
SNMP
(snmp)
SNMP (Simple Network Management Protocol) service; when enabled, SNMP will accept
connections on all subnets on which SNMP services are enabled.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
71
Enabling Network Services
Enabling VLAN Subnet Network Services
By default, no network services are enabled when a VLAN subnet is created. They must be
specifically enabled before you can access Equalizer over a subnet:
VLAN Subnet Network Services using the CLI
In the CLI, subnet network services are enabled using the services parameter in the subnet context.
See "VLAN and Subnet Commands" on page 261.
VLAN Subnet Network Services using the GUI
In the GUI, click on the System configuration tab on the left pane.
l
l
l
Clicking on the arrow (u) next to Network expands the branch and provides access to
Interfaces, VLANs, and Tunnels displays on the right pane.
Clicking on the arrow (u) next to VLANs expands the branch to display all configured VLANs.
Clicking on the arrow (u) for each VLAN expands the branch to display the configured
subnets. Click on each subnet to display the subnet Configuration screen on the right pane for
the selected subnet. Failover subnet services are configured for the selected subnet as well
by clicking on the Failover tab on the right pane.
The following subnet network services settings are supported:
CLI
GUI
Network Service
http
HTTP
HTTP GUI service; when enabled, the Equalizer will listen for
HTTP connections on Equalizer’s IP address on the subnet. The
global HTTP GUI service must also be enabled.
https
HTTPS
HTTPS GUI service; when enabled, the Equalizer will listen for
HTTPS connections on Equalizer’s IP address on the subnet.
The global HTTPS GUI service must also be enabled.
ssh
SSH
SSH log in service; when enabled, SSH log in will be permitted
on Equalizer’s IP address on the subnet. The global SSH service
must also be enabled.
snmp
SNMP
SNMP (Simple Network Management Protocol) service; when
enabled, SNMP will accept connections on Equalizer’s IP
address on the subnet. The global SNMP service must also be
enabled.
envoy
Envoy
Envoy DNS service; when enabled, Envoy will accept DNS
lookup connections on Equalizer’s IP address on the subnet.
The global Envoy service must also be enabled.
Envoy Agent
Envoy Agent health check service; when enabled, Envoy health
checks will be performed on the subnet using Equalizer’s IP
address on the subnet as the source IP. The global Envoy Agent
service must also be enabled.
envoy_agent
72
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
CLI
fo_http
GUI
Network Service
Failover HTTP
Failover HTTP GUI service; when enabled, the Equalizer will
listen for HTTP connections on Equalizer’s Failover IP address
(if configured) on the subnet. The global HTTP GUI service
must also be enabled.
Click on the Failover tab to enable or disable the following services:
fo_https
Failover HTTPS
Failover HTTPS GUI service; when enabled, the Equalizer will
listen for HTTPS connections on Equalizer’s Failover IP address
(if configured) on the subnet. The global HTTPS GUI service
must also be enabled.
fo_ssh
Failover SSH
Failover SSH log in service; when enabled, SSH log in will be
permitted on Equalizer’s Failover IP address (if configured) on
the subnet. The global SSH service must also be enabled.
fo_snmp
Failover SNMP
Failover SNMP service; when enabled, SNMP will accept
connections on Equalizer’s Failover IP address (if configured)
on the subnet. The global SNMP service must also be enabled.
fo_envoy
Failover Envoy
Failover Envoy DNS service; when enabled, Envoy will accept
DNS lookup connections on Equalizer’s Failover IP address (if
configured) on the subnet. The global Envoy service must also
be enabled.
fo_envoy_agent
Failover Envoy
Agent
Failover Envoy Agent health check service; when enabled,
Envoy health checks will be performed on the subnet using
Equalizer’s Failover IP address on the subnet as the source IP.
The global Envoy Agent service must also be enabled.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
73
Equalizer Administration Guide
Chapter 9
Registering Your Product
Sections within this chapter include:
Registering Your Product
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
76
75
Registering Your Product
Registering Your Product
Fortinet customer services (such as firmware updates and technical support) require product
registration. Take a moment now to register your product at the Fortinet Customer Service and
Support web site:
https://support.fortinet.com
Before you can register, you will need:
1. Access to a new or existing Support Account. Information on how to create and
manage a support account is provided in the Fortinet Support Portal User Guide. If your
organization already has an account, obtain the user name and password information from
your local account administrator to log in.
2. The serial number of the unit you want to register. You can find this information
using either the CLI or the GUI after powering up your appliance:
a. To use the CLI, log in to the CLI (over the serial console or, if networking is
configured, using SSH over an appropriately configured subnet) and enter the
following CLI command:
eqcli > version.
Record the System Serial Number from the command output.
b. If networking is configured and the GUI has been enabled on a subnet., you can
also get the serial number from the System Information widget on the GUI
dashboard. The Dashboard appears automatically when you log into the GUI.
Once you have obtained both the login credentials of a support account and the System Serial
Number of the unit to register, do the following:
1. Log in to https://support.fortinet.com using the login credentials obtained above.
2. Follow the instructions provided in the Registration Frequently Asked Questions under the
heading “How do I register a Fortinet device?” to register your Equalizer. When requested,
enter the System Serial Number you obtained above into the appropriate form. Once
registration is completed, the appliance serial number and other information will appear in
the FortiCare Registration area.
76
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
3. Your Equalizer system is now registered. If your system can connect to the internet, you
can now update the support information displayed in the CLI and GUI by doing one of the
following:
a. In the CLI, enter the following to update the support information on your unit:
eqcli > forticare registration
View the updated Support information (including Last refresh date,
Support end, and Email) by entering:
eqcli >
version
b. In the GUI, select the System configuration tab on the left navigational pane and
then click on Global > Dashboard. The System Information widget on the right pane
will indicate the Support information (including Last refresh date, Support end, and
Email). Click on the Refresh button to update the registration information.
Note - FortiCare information is not provided with E250GX systems in either the CLI or GUI.
Note - The registration information does not update automatically in either the CLI or the GUI; you must
use either the CLI "forticare registration" command or the Refresh button in the
Dashboard’s System Information widget to update.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
77
Equalizer Administration Guide
Chapter 10
Sample Configuration
Sections within this chapter include:
Sample Configuration
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
80
79
Sample Configuration
Sample Configuration
The following is an example of basic Equalizer configuration. It includes the configuration VLANs
and other load balancing objects such as servers, server pools, clusters and responders. The
example assumes that Equalizer is in a “factory installed” state: no customer configuration has
been performed on the unit. The sample configuration we’ll create is pictured in the illustration
below.
Note - The IP addresses shown in the sample configuration below are for demonstration purposes only! Consult with
your network administrator for the proper IP addresses to use in your configuration.
80
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
The procedure below shows you how to use one line commands in the global context to set up the
configuration illustrated above.
1. Power on Equalizer and enter the CLI, as shown in "Starting the CLI" on page 168.
2. Configure a VLAN for the GUI, SSH, and cluster IP addresses using the format:
eqcli > vlan vlname vid vlan_ID
Replace vlname with the VLAN name and vlan_ID with the VLAN ID number (14094). If you are using untagged VLANs (common in many sites), the VLAN ID can be
any number not used on another VLAN. If you are using tagged VLANs, ask your
network Administrator for the correct VLAN ID to specify.
eqcli > vlan 172net vid 2
3. Create a VLAN for servers on the remaining ports:
eqcli > vlan 192net vid 3
4. Add subnets to both of the VLANs. You’ll need to specify the subnet IP address, which is the
load balancer's address on this network. It must be an IPv4 or IPv6 address in CIDR format
(e.g., 172.16.0.200/21).
Enter the following command syntax, all on one line:
eqcli > vlan vlname subnet subnetname ip cidr_ip
In the command above, vlname is the VLAN name, netname is the name of the
subnet, cidr_ip is the CIDR format IP address. For example:
eqcli > vlan 172net subnet sn01 ip 172.16.0.200/21
eqcli > vlan 192net subnet sn01 ip 192.168.0.200/21
5. Configure services on each subnet of each VLAN. For our example, we’ll enable SSH login
and the GUI over HTTP on the 172net VLAN.
eqcli > vlan 172net subnet sn01 services http,https,ssh
eqcli > vlan 192net subnet sn01 services http,https,ssh
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
81
Sample Configuration
6. Configure routing on the VLANs including a default route and gateway routes. In the
example below, 0/0 is the default route and 172.16.0.1 and 192.168.0.1 are the
gateways, which are unadorned IP addresses. In this scenario, all packets for destinations
are to be sent via these routes.
eqcli > vlan 172net subnet sn01 route 0/0 gw 172.16.0.1
eqcli > vlan 192net subnet sn01 route 0/0 gw 192.168.0.1
7. Associate an interface instance with the VLAN. In the example below we assume that you
are using the port labeled "1" on the front panel. Enter one of the following commands,
depending on whether the VLAN you created above is untagged or tagged (ask your network
administrator if you are unsure):
eqcli > vlan vlname ifi if01 type untagged
or
eqcli > vlan vlname ifi if01 type tagged
8. Connect Equalizer to your network on the VLANs that you set up in the previous steps, using
the appropriate front panel ports. You should now be able to ping Equalizer’s IP address on
each VLAN. If it does not respond on a VLAN, you may need special routes on the default
router, or on the next-hop gateway for a particular VLAN.
9. Set the timezone. Enter:
eqcli > timezone?
10. Locate your timezone in the displayed list and press q to quit out of the list. Then, type in
your timezone number and press <Enter>, as in this example for the "America/New York’"
time zone:
eqcli > timezone 161
11. If Equalizer can reach the Internet, add a name server so that NTP will work and time will
be the same across all Equalizers:
eqcli > name-server IP_address
Otherwise, set the time manually on all systems to the current time:
eqcli > date HHmmss
82
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
12. Create two real servers:
eqcli > server sv01 proto tcp ip 192.168.0.5 port 80
eqcli > server sv02 proto tcp ip 192.168.0.6 port 80
13. Create a server pool:
eqcli > srvpool sp01 policy adaptive respv 3
14. In server pool sp01, create server instances for the servers created in Step 6.
eqcli > srvpool sp01 si sv01 weight 100
eqcli > srvpool sp01 si sv02 weight 100
15. Create a Layer 7 HTTP cluster:
eqcli > cluster cl01 proto http ip 172.16.0.201 port 80 srvpool sp01
16. Create a Layer 4 TCP cluster using server pool sp01, with DSR enabled:
eqcli > cluster cl02 proto tcp ip 172.16.0.202 port 80 srvpool sp01 flags dsr
17. Add an SSL certificate store (for the HTTPS cluster we’ll create later). Enter:
eqcli > certificate ct01
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
83
Sample Configuration
18. Import the certificate and its associated private key using either of the following methods:
If the certificate resides on an FTP site, enter commands like the following,
substituting the IP address and path on your FTP site from which the certificate and
private key can be downloaded:
eqcli > certificate ct01
eqcli-cert> certfile ftp://10.0.0.21/certfile.pem
eqcli-cert> keyfile ftp://10.0.0.21/keyfile.pem
If you want to cut and paste the certificate and key using an editor, use commands
like the following:
eqcli > certificate ct01 certfile edit
eqcli > certificate ct01 keyfile edit
Certificates and keys must be downloaded separately, in PEM format. If a chain of
certificates and keys must be uploaded, ensure that all the certificates are in one file
and all the private keys are in another.
19. Create a Layer 7 HTTPS cluster using server pool sp02 and associate certificate ct01 with
the cluster:
eqcli > cluster cl03 proto https ip 172.16.0.203 port 443 srvpool sp01
certificate ct01
20. Create a Layer 7 HTTP cluster -- do not specify a server pool, since this cluster will be used
only to redirect clients to cl03:
eqcli > cluster cl04 proto http ip 172.16.0.203 port 80
21. Add a "sorry" responder that will be used to display a web page that asks the user to try
again later:
eqcli > resp Sorrycl01 type sorry html edit
An editor is launched so that you can enter the HTML for the responder page. For
example, you can enter Once you are done, type <Esc><Enter> and then <Enter> to
save the HTML you entered.
84
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
22. Add the responder created in the previous step to cluster cl01:
eqcli > cluster cl01 resp Sorrycl01
The effect of adding this responder to cl01 is that if all the servers in server pool
sp01 are unavailable, clients making requests to cluster cl01 will receive an
automatic response asking them to try again later.
23. Add a redirect responder that will redirect all requests coming into the same cluster IP as
cl03 on port 80 (via HTTP); the responder will be configured to redirect these requests to
cl03 on port 443 (via HTTPS).
Since some of the arguments to this command are longer than one line, we’ll add the
responder using multiple command lines to make the input clearer:
eqcli
eqcli
eqcli
eqcli
eqcli
eqcli
eqcli
> resp Redircl04
rsp-Red*> type redirect
rsp-Red*> statcode 301
rsp-Red*> statdesc "Moved Permanently"
rsp-Red*> regex “http://clustercl03.example.com/([^ \r]+)?”
rsp-Red*> url "https://clustercl03.example.com/$1"
rsp-Red*> exit
eqcli: 12200287: Operation successful
eqcli >
Note the following:
The regular expression used in the regex parameter contains a single space between
the caret (^) and backslash (\) characters.
The FQDN used in the regex and url parameters (e.g., cluster-cl03.example.com)
must match the FQDN used by clients to connect to cluster cl03.
24. Add the responder created in the previous step to cluster cl01:
eqcli > cluster cl04 resp Redircl04
Since cl04 has no associated server pool specified in its configuration, all requests
coming in to cl04 will be redirected to cl03 by the responder.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
85
Equalizer Administration Guide
Chapter 11
Load Balancing & Networking
Sections in this chapter include:
Networking Routing Description
Networking Conventions
How Packets are Routed
Typical Equalizer Networking Scenarios
Blank Configuration
Single VLAN/Subnet
Single VLAN/Subnet with a Default Gateway
Dual VLAN/Network
Dual VLAN/Network with 2 Gateways
Dual VLAN/Network with Outbound NAT
Configuring Network Interfaces
Configuring Phyiscal Interfaces
Configuring VLAN Interfaces
Configuring Aggregated Interfaces
Configuring Static Routes
Policy Routing
Source Based Routing Scenarios
Source Selection
Source Routing Scenarios
Source Routing Tables & Rules
IPv6 Tunnel Overview
Network Troubleshooting Tools
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
88
92
93
95
95
96
98
100
103
106
109
110
118
131
137
140
141
142
144
152
158
165
87
Load Balancing & Networking
Networking Routing Description
The network routing described applies to Equalizer installations. As each routing type is described
in detail, specific rules and commands are described further
Destination Routing
This is standard routing that is performed by any networking device. The device determines how
to send a packet to its destination by evaluating the destination IP address to see if it is on a local
network.
l
l
It if is, the device sends the packet directly using the Ethernet layer.
If, the IP address is on a remote network, the device evaluates its routing table to
determine how to send it. The routing table consists of a set of entries in the form:
IP/NETMASK || GATEWAY
The device searches the routing table in a most specific to least specific manner in order to find
the most appropriate route to use. For example, if one entry is for the network 10.0.0.0/8 and
another is for the network 10.0.0.0/24, a packet destined for the IP address 10.0.0.1 would use
the /24 entry because it is more specific. However, a packet destined for 10.0.1.1 would use the
/8 entry because the /24 entry does not apply to this destination. Once a matching route is found,
the device sends the packet on to the gateway (or router) that is specified in the route. It is then
this gateway's task to move the packet closer to its final destination.
Source-Based Routing
This concept is not unique to Equalizer, however the behavior of each device that implements
Source-based Routing can be different. Source-based routing simply means that the source IP
address is used in the routing decision. For Equalizer, this means that rather than having a single
destination routing table, the system actually has a set of destination routing tables; each used
only when the source IP address of a packet matches a particular network. A source-based
routing table contains entries in the form:
(SOURCE IP/NETMASK,DESTINATION IP/NETMASK) || GATEWAY
l
l
88
If the destination IP address is on a local network, source-based routing is not used. The
packet is sent to the destination system via Ethernet.
If the destination IP address is on a local network, source-based routing is not used by
default. The packet is sent to the destination system via Ethernet. However, administrators
can configure their routing tables to override the local entries for particular networks, in
which case Equalizer will prefer a source route over a local network route. If configured in
this manner, Equalizer will send the packet to an IP gateway associated with the source
route rather than simply using the ARP address of the destination system to send the packet
over Ethernet directly.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
If the destination IP address is on a remote network, the device trying to send a packet performs
a most-specific to least-specific search for the source IP network. If a matching source route is
found within the routing table, any routing table entries that contain that source IP network are
used as a destination routing table. For example:
This source-based routing table shows three source routes.
l
l
If a packet sent to 10.0.0.100 originates from the 192.168.0.0/24 network, Equalizer will
use 10.0.0.1 as the gateway.
If it originates from the 192.168.1.0/24 network, Equalizer will use 10.0.0.2 as the gateway.
If it originates from any other network, Equalizer will use 10.0.0.3 as the gateway.
The IP 0.0.0.0/0 is the least specific that a network entry can be - it matches every IP address.
However, because of the most-specific to least-specific search that Equalizer performs, the
0.0.0.0/0 source route is not used unless none of the other routes match.
Also note that in this configuration, any packets that have a destination IP address other than a
network local to Equalizer (presumably 192.168.0.0/24, 192.168.1.0/24 and 10.0.0.0/8), a route
would not be found and the packet would be dropped by the system. To prevent this from
happening, most configurations include a default route in the form (0.0.0.0/0, 0.0.0.0/0) ||
GATEWAY.
Local Networks
Any network that has been added as a subnet in the configuration is considered local to Equalizer.
When a subnet is configured, an Administrator assigns an IP address (potentially more than one)
that is Equalizer's IP presence on this subnet. When an Equalizer is referred to as being in singlenetwork mode or dual-network mode, this refers to the number of local networks.
Remote Networks
Any network that is not a local network. This means that Equalizer needs to perform routing to
communicate with a device on this network.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
89
Load Balancing & Networking
Destination Networks
A specific remote network that has been configured by the Administrator as connected to a local
network of Equalizer. This means that if Equalizer needs to send packets to this network, it should
do so from an IP address on the local network and use the router of the local network. For
example:
In this configuration, 192.168.211.0/24 is a local network for Equalizer, configured by adding a
subnet to the configuration. 192.168.105.0/24 can be configured as a destination network of the
192.168.211.0/24 network. When adding a destination network, the administrator is configuring
several things:
l
l
l
l
90
In order to send packets from Equalizer to the destination network, Equalizer should use its
IP address on the local network. This how Equalizer selects an IP address to use when
sending a packet to the destination network. In order to do this, Equalizer actually sorts all
of the destination networks it knows about in most-specific to least-specific order. It then
chooses an appropriate IP address to use based on the first destination network to match.
Normally, Equalizer would not allow any packets that do not have a source IP address on
the local network. Adding the destination network means that Equalizer will now allow
packets from this network to be routed with the same rules as packets from the local
network.
Similarly, Equalizer will automatically add source routes for packets from the destination
network that match existing source routes for the local network.
If outbound NAT has been configured for the local network, analogous rules are added for
the destination network.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Outbound NAT
Network Address Translation (NAT), is a common concept for most network administrators.
Equalizer administrators usually need to enable NAT when a server on an "internal" (non-public,
DMZ) network needs to access resources on the Internet or another public network. This internal
network can be either a local network or a destination network for Equalizer. In this scenario, the
administrator enables outbound NAT and selects the local network that should be used to NAT
packets from the internal network. For example:
In this example, neither the 192.168.211.0/24 nor the 192.168.105.0/24 networks can access the
Internet directly. The administrator configures Equalizer to provide outbound NAT service for
these networks by using an IP address on the 10.0.0.0/24 network when these internal networks
need to talk to the Internet.
When configuring outbound NAT, the internal local network that is being configured for outbound
NAT must use the routing information for the external network which it is using NAT through. In
the example above, the default gateway for the 192.168.211.0/24 network will really be on the
10.0.0.0/24 network.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
91
Load Balancing & Networking
This is logical when you remember it this way: If Equalizer is sending a packet from the
192.168.211.0/24 network to a host on the Internet, it has to be sent through the gateway of the
external network, rather than the internal network.
When Outbound NAT is enabled for a local network that contains attached destination networks,
the destination networks automatically inherit the same outbound NAT configuration.
Note - Outbound NAT is not supported for IPv6.
Network Permissions
Local networks configured in Equalizer use a default/deny permission scheme. This means that if
an Administrator wants to route between two networks using Equalizer, they must explicitly
enable permissions between that pair of networks.
Note that permissions are not symmetrical: it is possible to configure a solution where one
network can talk to another but not vice-versa. For most configurations, permissions are
necessary on both networks: if network "A" needs to route to network "B", a permission must be
added to "A" for "B" and another permission must be added to "B" for "A".
Permissions are only necessary when using Equalizer to route packets. They are not required for
Application Traffic Management. That is, when an Equalizer cluster is paired with a server (by
adding a server pool containing that server to the cluster), Equalizer knows that any packets
associated with a connection for that cluster should be allowed on the server network.
Networking Conventions
Several conventions are used within this section:
l
l
l
l
l
92
Network addresses are represented in Classless Inter-Domain Routing (CIDR) notation, an
IP addressing scheme in the form A.B.C.D/X where X is the number of bits in the subnet
mask.
Subnets are referenced by the name of the VLAN which contains them, followed by the
subnet name. For example, internal:net means VLAN internal, subnet net.
All VLAN configurations presented are untagged. The configurations and concepts in this
document applies for tagged VLANs as well.
This section uses examples that are for IPv4 networking. However, the configuration for
IPv6 networking would be identical- with a couple of exceptions. These exceptions are
identified - where applicable.
This section uses examples from an Equalizer OnDemand system using untagged VLANs. If
your configuration uses tagged networks or Equalizer physical appliances, the network
interfaces displayed here will not match your configuration. This is normal and remainder of
the section still applies.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
How Packets are Routed
When an ADC sends out a packet, it determines how to send it as follows:
1. The ADC determines whether the packet destined for a system is directly attached to one of
the configured networks.
a. If "Yes", then it needs to determine whether there is a preferred route that
specifies how to send it.
l
l
If "Yes", it uses that route.This means that the ADC will send the
packet to the router-- using whatever method it has of
communicating with the router. If you use a router that's on one
network, it will send out that packet through the interface
connected to that network.. If you use a router on another
configured network with another IP address, it will send it out of the
interface attached to that address.
If "No", it sends directly (ARP for the address and then send to the
MAC address via Ethernet)
b. If "No," it searches the routes present for the source network that this packet
has in "most-specific" to "least-specific" order. It determines whether a route
exists that matches both the packet's source network and the destination
network.
l
If "Yes," it uses that route.
l
If "No", it drops the packet and returns an error.
Consider the following example using the illustration below. In the example, two subnets are
used. The "10net" (IP 10.10.10./24) and the "11net" (IP 10.10.11/24).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
93
Load Balancing & Networking
94
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Typical Equalizer Networking Scenarios
This section describes individual networking scenarios that can be used to build up a large, more
complicated configuration for Equalizer . Each section starts at a specific pre-configured
configuration, and references the section which helps set up that configuration.
Blank Configuration
When the Equalizer configuration does not contain any subnets, the networking configuration
should also be blank. To demonstrate this enter the following:
eqcli > show sbr
IPv4 Default Source Selection Table:
IPv6 Default Source Selection Table:
Source Routing Table:
IP Filter Rules:
empty list
IP NAT Rules:
List of active MAP/Redirect filters:
List of active sessions:
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
95
Load Balancing & Networking
Single VLAN/Subnet
A Single VLAN/subnet configuration is one of the most common networking scenarios used. In this
setup, Equalizer is placed into an existing network so that all servers, internal clients, and
external routers are on the same VLAN. (This usually means special routing on the servers or the
use of no spoof for Equalizer clusters.
Here a single VLAN is added , and a subnet is configured on the VLAN. For example:
eqcli > vlan internal vid 1
eqcli: 12000287: Operation successful
eqcli > vlan internal subnet net ip 192.168.211.8/24
eqcli: 12000287: Operation successful
The DSS (Default Source Selection table) is a listing of all destination networks configured in the
load balancer. There are not differences in the routing and the NAT tables, since no new entries
have been added to them. However, the IP Filters table has been updated by the system. For
example, when you use the show sbr command the following will be displayed (partial display
shown)
IP Filter Rules:
IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 227 bytes: 7025
From
To
192.168.211.0/24
->
192.168.211.0/24
3: block all hits: 26 bytes: 2579
IPv6 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass hits: 0 bytes: 0
From
To
fe80::/10
->
any
3: block all hits: 0 bytes: 0
96
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
The new rule shows that packets from internal are allowed into the system if they are being
sent to the same network. Without this rule, the newly added IP address could not be reached
from the rest of the network.
IPv4/6 rule 1 allows Equalizer traffic if it is on the local host interface (lo0), and IPv4/6 rule 3
blocks all traffic which didn't fall into one of the previous rules. This is the default deny rule. IPv6
rule 2 is an automatically-added rule for link-local IPv6 addresses, which is always there if any
networks are configured.
If all of the clients and servers for this Equalizer are on the internal network, we're done,
however, most installations have customers which are on a different network, usually the
Internet.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
97
Load Balancing & Networking
Single VLAN/Subnet with a Default Gateway
A system can be connected to the internet by adding a default route because there is only a single
Equalizer local network. The following shows the newly-added rules ( in italics)
eqcli > vlan internal subnet net default_route 192.168.211.1
eqcli: 12000287: Operation successful
Source Routing Table:
192.168.211.0/24:
default
IP Filter Rules:
via 192.168.211.1
IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 32 bytes: 1368
From
To
192.168.211.0/24 -> 192.168.211.0/24
3: block on interface wm1 hits: 0 bytes: 0
From
To
192.168.211.0/24 -> 192.168.211.0/24
4: pass on interface wm1 hits: 0 bytes: 0
From
To
192.168.211.0/24 ->
any
5: pass on interface wm1 hits: 0 bytes: 0
From
To any ->
192.168.211.0/24
6: block all hits: 7 bytes: 799
IPv6 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass hits: 0 bytes: 0
From
fe80::/10
98
->
To
any
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Now that we have a non-blank routing configuration, we can see that the source routing table
reflects the change, and that we have a couple of routing-specific IP Filter rules:
l
l
Rule 3 is inserted immediately after any 'pass' rules for this subnet. Because there aren't
any other subnets except this one, this rule will not be used (the previous rule allows all
packets that this rule would block).
Rules 4 and 5 allow traffic from non-Equalizer networks into Equalizer and from Equalizer to
non-Equalizer networks. These are the rules that allow routing through the default gateway
to work.
The configuration presented in this section corresponds to the following scenario:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
99
Load Balancing & Networking
Dual VLAN/Network
Another typical configuration is to have two networks connected to Equalizer:
1. One for external connectivity (this is where the Equalizerclients and clusters are)
2. One for internal resources (this is where the servers are)
We start with a single-VLAN configuration with no default route (See "Single VLAN/Subnet" on
page 96) and add a second network for external connectivity, along with a default route for that
network, as shown below.
eqcli > vlan external untagged_ports 1 vid 2
eqcli: 12000287: Operation successful
eqcli > vlan external subnet net ip 10.0.0.68/24 default_route 10.0.0.254
eqcli: 12000287: Operation successful
The IP Filter configuration is updated as shown below:
Source Routing Table:
10.0.0.0/24:
default
IP Filter Rules:
via 10.0.0.254
IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 36 bytes: 1608
From
To
192.168.211.0/24 -> 192.168.211.0/24
3: pass on interface wm0 hits: 48 bytes: 2926
From
To
10.0.0.0/24 -> 10.0.0.0/24
4: block on interface wm0 hits: 0 bytes: 0
From
To
5: pass on interface wm0 hits: 27 bytes: 4916
From
To
10.0.0.0/24 ->
any
6: pass on interface wm0 hits: 0 bytes: 0
From
To
any -> 10.0.0.0/24
7: block all hits: 1 bytes: 328
The 192.168.211.0 network rules remain unchanged. We have new rules for the 10.0.0.0 network:
Rule 3 is for sending packets on the external network interface (wm0 in this case) to the 10.0.0.0
network from the 10.0.0.0 network.
100
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Rules 5 and 6 for packets between the 10.0.0.0 network to any other network.
Note that Rule 4 is a block rule which prevents traffic between the 10.0.0.0 network and all
subnets known to the system. Such a rule doesn't exist for the 192.168.211.0 network because we
have not enabled routing for it.
Since the new external network is the one is used for sending packets to the Internet, we also
make it the default network for sourcing packets.
We see that setting this flag has created a DSS table entry. This entry is a definition for the 0/0
destination network, which specifies that the external VLAN is the one connected to this network,
and when Equalizer needs to send packets to this network, it should use the 10.0.0.68 IP address.
This setup is sufficient for most dual-network configurations:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
101
Load Balancing & Networking
With this configuration, clients can connect to cluster IP addresses on the 10.0.0.0 network, and
Equalizer will send the requests to the servers on the 192.168.211.0 network.
Source Routing Table:
0.0.0.0/00:
default via 10.0.0.254
10.0.0.0/24:
default via 10.0.0.254
IP Filter Rules: IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 141 bytes: 7025
From
To
192.168.211.0/24 ->
192.168.211.0/24
3: pass on interface wm0 hits: 5 bytes: 399
From
To
10.0.0.0/24 -> 10.0.0.0/24
0.0.0.0/0
0.0.0.0/0
4: block on interface wm0 hits: 0 bytes: 0
From
To
10.0.0.0/24 -> 192.168.211.0/24
10.0.0.0/24
0.0.0.0/0
5: pass on interface wm0 hits: 4 bytes: 756
From
To
10.0.0.0/24 ->
any
6: pass on interface wm0 hits: 0 bytes: 0
From
To
any ->
10.0.0.0/24
0.0.0.0/0
7: block all hits: 0 bytes: 0
102
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Dual VLAN/Network with 2 Gateways
Imagine a scenario very similar to the one described in Dual VLAN/Network, however, the
internal network is also able to route to the internet:
As far as Equalizer is concerned, the configuration doesn't have to change at all from the previous
scenario. There is still a single destination network (the Internet), and Equalizer is statically
configured to use the 10.0.0.0 network to communicate with this destination network.
The administrator can set up the servers on the 192.168.211.0 network to use their router when
sending packets to the Internet, and to use Equalizer whenever sending packets to clients.
However, in order to do this on a server, the administrator would need to statically define which
portions of the Internet should use which gateway (the router or the Equalizer). This can be
configured very simply on Equalizer, instead:
eqcli > vlan internal subnet net default_route 192.168.211.2
eqcli: 12000287: Operation successful
This command adds a default route for the internal network that is different than the external
default route. This means that any traffic coming from the internal network will be source routed
through the 192.168.211.2 gateway, while any other traffic will still be routed through the
10.0.0.254 gateway as configured for the external network.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
103
Load Balancing & Networking
This can be verified by looking at a partial eqcli > show sbr output:
Pv4 Default Source Selection Table:
0.0.0.0/00:
default
via 10.0.0.254
192.168.211.0/24:
default
via 192.168.211.2
10.0.0.0/24:
default
via 10.0.0.254
The IP Filter rules are updated as well, analogous to the rules which were created when we added
routing in Single VLAN/Subnet with a Default Gateway. The new rules allow routing from the
internal network.
IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 39 bytes: 1368
From
To
192.168.211.0/24
192.168.211.0/24
3: pass on interface wm0 hits: 12 bytes: 624
From
10.0.0.0/24
To
10.0.0.0/24
0.0.0.0/0
0.0.0.0/0
4: block on interface wm1 hits: 0 bytes: 0
From
To
192.168.211.0/24
192.168.211.0/24
10.0.0.0/24
0.0.0.0/0
5: pass on interface wm1 hits: 0 bytes: 0
104
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
From
To
192.168.211.0/24
any
6: block on interface wm0 hits: 0 bytes: 0
From
10.0.0.0/24
To
192.168.211.0/24
10.0.0.0/24
0.0.0.0/0
7: pass on interface wm0 hits: 4 bytes: 756
From
To
10.0.0.0/24
any
8: pass on interface wm1 hits: 0 bytes: 0
From
To
any
192.168.211.0/24
9: pass on interface wm0 hits: 0 bytes: 0
From
To
any
10.0.0.0/24
0.0.0.0/0
10: block all hits: 1 bytes: 328
It can also be verified using the traceroute tool, available in most Operating Systems. If a
traceroute is performed from the server, a different second-hop gateway is used than the firsthop gateway on the Equalizer traceroute:
freebsd# traceroute 64.13.152.126
traceroute to 64.13.152.126 (64.13.152.126), 64 hops max, 40 byte
packets
1 192.168.211.8 (192.168.211.8) 0.576 ms 0.799 ms 0.241 ms
2 192.168.211.2 (192.168.211.2) 0.522 ms 0.547 ms 0.334 ms
Equalizer# traceroute -n 64.13.152.126
traceroute to 64.13.152.126 (64.13.152.126), 64 hops max, 40 byte
packets
1 192.168.8.2 1.653 ms 1.342 ms 1.225 ms
In the example above, the server (freebsd) uses the Equalizer (192.168.211.8) as its gateway,
and the Equalizer sends the packet on the 192.168.211.2 gateway. However, when the Equalizer
performs a traceroute to the same location, it uses the 192.168.8.2 gateway.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
105
Load Balancing & Networking
Dual VLAN/Network with Outbound NAT
If we start with the configuration in Dual VLAN/Network, it should be noted that this configuration
is not sufficient if the servers on the internal network require internet connectivity. Equalizer will
properly send traffic from the internal network to the internet, but because the internal network is
non-routable, hosts on the internet will not be able to respond. One way to solve this problem is to
have a separate NAT gateway for the server network, as described in Dual VLAN/Network with 2
Gateways. However, because most locations have a single outbound link, configurations with only
a single gateway must use Outbound NAT.
Note - The Outbound NAT feature is not available for IPv6 on Equalizer.
Outbound NAT allows the administrator to associate two subnets together using the nat
parameter. The from address is the source IP address (or range of addresses) to which this NAT
rule applies. Use a CIDR-format IP address to specify a range. If the source IP address of an
outbound packet matches this IP address (or falls within the specified range), then the packet is
modified to use the IP address specified by the out parameter as the source IP.
The out address specifies that if the source IP address of an outbound packet matches the IP
address (or IP address range) specified by the from parameter, then the packet is modified to
use this IP address as the source IP.
eqcli> vlan vlan-name subnet subnet-name nat from ip_cidr out 1.2.3.33 nat subnetname out gw 10.0.0.254
Outbound NAT means that now we are taking packets from the internal network and sending them
out of the external network. This means that the packets are routed, and we need to enable
permissions between the networks:
eqcli > vlan internal subnet net permit external:net
eqcli: 12000287: Operation successful
eqcli > vlan external subnet net permit internal:net
eqcli: 12000287: Operation successful
Note that the permissions need to be set on both sides - the internal network is configured to
allow traffic from the external network, and the external network is configured to allow traffic
from the internal network.
Now we can analyze the changes to the running configuration that we have made. First, we
enabled Outbound NAT:
IP NAT Rules:
106
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
List of
map wm0
map wm0
map wm0
active MAP/Redirect
192.168.211.0/24 ->
192.168.211.0/24 ->
192.168.211.0/24 ->
filters:
10.0.0.68/32 proxy port ftp ftp/tcp
10.0.0.68/32 portmap tcp/udp auto
10.0.0.68/32
All three rules are created for the single NAT change that we made. They can be read as
"whenever traffic is leaving through the wm0 interface, if it has a 192.168.211.0 network source
IP address, change the source IP address to 10.0.0.68".
Second, we changed the default gateway:
Source Routing Table:
0.0.0.0/00:
default
via 10.0.0.254
192.168.211.0/24:
default
via 10.0.0.254
10.0.0.0/24:
default
via 10.0.0.254
Both networks now use the same default gateway, since all traffic will be sent through that router.
Third, we added permit rules for the networks:
IPv4 Rules:
1: pass on interface lo0 all hits: 0 bytes: 0
2: pass on interface wm1 hits: 90 bytes: 4156
From
To
192.168.211.0/24
192.168.211.0/24
->
10.0.0.0/24
0.0.0.0/0
3: pass on interface wm0 hits: 6 bytes: 295
From
To
10.0.0.0/24
10.0.0.0/24
0.0.0.0/0
->
0.0.0.0/0
192.168.211.0/24
4: block on interface wm1 hits: 0 bytes: 0
From To
192.168.211.0/24 192.168.211.0/24
-> 10.0.0.0/24
0.0.0.0/0
5: pass on interface wm1 hits: 0 bytes: 0
From To
192.168.211.0/24 -> any
6: block on interface wm0 hits: 0 bytes: 0
From To
10.0.0.0/24 192.168.211.0/24
-> 10.0.0.0/24
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
107
Load Balancing & Networking
0.0.0.0/0
7: pass on interface wm0 hits: 3 bytes: 517
From To
10.0.0.0/24 -> any
8: pass on interface wm0 hits: 0 bytes: 0
From To
any 192.168.211.0/24
-> 10.0.0.0/24
0.0.0.0/0
9: block all hits: 0 bytes: 0
The main difference between these rules and those in Dual VLAN/Network with 2 gateways is that
because of the new permissions, Rules 2 and 3 now include both networks in them, meaning that
traffic can be sent to either network rather than just one. Additionally, rule 8 has replaced two
separate rules, because all traffic coming from the Internet will now enter Equalizer through the
wm0 interface.
This configuration corresponds to the same scenario as Standard Dual Network configuration, but
with the requirement that the internal servers are required to be able to access the Internet.
108
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Network Interfaces
Each physical network port has a network interface that directly corresponds to it - that is, a
“physical network interface.”
Physical ports server three purposes:
l
l
l
Management - The network interface named Mgmt is typically used as the management
interface.
Failover - If you utilize failover configurations, you must use a physical port for
heartbeating and synchronization.
Traffic - The remaining physical ports can be used for your target traffic—these are your
“traffic interfaces.” Traffic interfaces can be associated with logical interfaces which
include:
l
VLAN interfaces
l
Aggregated interfaces
The figure below illustrates how physical ports are associated with physical and logical interfaces.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
109
Load Balancing & Networking
Configuring Phyiscal Interfaces
Configuring Front Panel Ports
Front panel ports are configured using either the CLI or GUI.
By default, all switch ports are configured as follows:
l
l
full duplex
full autonegotiation (Equalizer will attempt to auto negotiate the highest available speed
with the unit on the other end of the connection)
If needed, ports can be configured to match specific port settings required by the server
connection. For example, you could use the switch interface to configure a particular switch port
to be 100Mb/s and half-duplex to accommodate older hardware.
Supported 10Gb Media Subtypes
10Gb ports are available on Equalizer E670LX and E970LX. The following media subtypes are
supported:
10GbaseLR - single-mode fiber
10GBase-SR 850nm Multi-mode
10GBase CX4 copper
10GBase Twinax copper
10GBase Twinax Long copper
10GBase-LRM 850nm Multi-mode
10GBase-T - RJ45
110
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Viewing Link Status and Port Settings
Refer to "Interface Commands" on page 223 for a complete listing of the CLI Interface commands.
Link Values
Interface Parameter
Description
Interface
The interface for which status is being displayed.
Duplex Mode
If the port status is Link Up, this is the current port duplex setting. If the status is
Link Down, this is either the highest duplex that can be negotiated, or the force
setting. Can be set to full or half.
Link Speed
If the port status is LinkUp, this is the current port speed. If the status is Link
Down, this is the highest speed that can be negotiated, or the Force setting. Can be
set to 10, 100, or 1000 Mbits.
Status
The status of the link (Link UP or Link DOWN)
Viewing Link Status and Port Settings(CLI)
The current link status of each port as well as the current settings, use the "show interface"
command as in this example below:
eqcli > show interface
Interface Duplex Mode
ge01
NA
ge02
NA
ge03
NA
ge04
NA
ge05
NA
ge06
NA
ge07
NA
ge08
NA
xe01
full
xe02
full
mgmt
full
eqcli >
Speed
NA
NA
NA
NA
NA
NA
NA
NA
10G
10G
100M
Status
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Up
Link Up
Link Up
The same information for a single port can be displayed by specifying the port name:
eqcli > show interface ge01
Interface Number
: ge01
Duplex mode
: NA
Link Speed
: NA
Actual Link Status
: Link Down
Configured Link Status : Link Up
Maximum MTU
: 9000
Maximum Speed
: 1G
eqcli >
Viewing Link Status and Port Settings(GUI)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
111
Load Balancing & Networking
1. Log in to the GUI
2. Select System > Network > Interface on the left navigational pane.
3. On the right, click on the Select a Port drop down list to select an interface to view port
settings.
112
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Viewing Link Status and Port Settings (E350GX, E450GX, E650GX Only)
Viewing Link Status and Port Settings(CLI)
The current link status of each port as well as the current settings, use the "show interface"
command as in this example below:
eqcli > show interface
Interface Autonegotiation Mode
if01
full
if02
NA
if03
NA
if04
NA
if05
NA
if06
NA
if07
NA
if08
NA
if09
NA
if10
NA
if11
NA
if12
NA
Duplex Mode
full
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Speed
1G
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Status
Link Up
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
Link Down
The same information for a single port can be displayed by specifying the port name:
eqcli > show interface if01
Interface Number
: if01
Autonegotiation mode
: full
Duplex mode
: full
Link Speed
: 1G
Actual Link Status
: Link Up
Configured Link Status : Link Up
Maximum MTU
: 1500
Maximum Speed
: 1G
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
113
Load Balancing & Networking
Port settings are as follows:
l
Autonegotiation mode - Use one of the following:
full - Full autonegotiation at all supported speed and duplex settings.
select - Autonegotiation at the current speed and duplex parameter settings only.
force - Set the port to the current speed and duplex parameter settings with no
autonegotiation.
Whether you choose full, select , or force depends on the operating characteristics of the
device on the other end of the connection. Check the documentation for the other device and
try to match the settings as much as possible on both sides of the connection.
l
Duplex Mode - If the port status is Link Up, this is the current port duplex setting. If the status
is Link Down, this is either the highest duplex that can be negotiated, or the force setting.
Can be set to full or half.
l
Link Speed - If the port status is Link Up, this is the current port speed. If the status is Link
Down, this is the highest speed that can be negotiated, or the Force setting. Can be set to 10,
100, or 1000 Mbits.
114
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying Port Statistics
Port statistics can be viewed using either the CLI or the GUI.
Viewing Port Statistics using the CLI
Enter the following to display statistics using the CLI, substituting the name of the interface (e.g.
if01, ge01) for interface-name:
eqcli > interface interface-name stats
The table below shows a typical port statistics display.
eqcli > interface if01 stats
Current
IF_IRQ
0
IF_QUEUE
1499
IF_START
385
IF_KICK
1134
IF_EEE_ACTIVE
1
IF_TX_WQ_RAN
1500
IF_CPU0_RSS
0
IF_CPU1_RSS
0
IF_CPU0_RXWQ
1526
IF_CPU1_RXWQ
0
IF_CPU2_RXWQ
0
IF_CPU3_RXWQ
0
IF_CPU0_TXS_DONE
5356
IF_TXDW
1
IF_RXINTR
1526
IF_RXREAP
4568
IF_LINKINTR
2
IF_TXIPSUM
680
IF_EEE_TXWAIT
1
IF_EEE_TXWAKE
1
IF_RXT0
1526
IF_RXNOWORK
3051
IF_RXWORK
1517
IF_RXHANDLED
1650
IF_INTR
1528
IF_RXREPEATS
1
IF_SOFT_INTR
2
IF_TX_DMA_MAP_STALL 0
IF_EEE_TXQ_FULL
0
IF_EEE_TXS_STALL
0
IF_EEE_TXD_STALL
0
IF_EEE_TX_FIFO_STA 0
IF_EEE_TX_DROP
0
IF_EEE_TX_DMAMAP
0
IF_EEE_RX_ADD_BUF
0
IF_EEE_RX_MEDIA_ERR 0
IF_EEE_LATE_COLL
0
IF_EEE_EX_COLL
0
IF_EEE_COLLISION
0
60 sec
0
2
0.20
2
0
2
0
0
3
0
0
0
2
0
3
9
0
1
0
0
3
6
3
3
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
10 min
0
1
0.20
0.85
0
1
0
0
1
0
0
0
0.86
0
1
4
0
0.52
0
0
1
3
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
60 min
0
0.85
0.20
0.65
0
0.85
0
0
0.87
0
0
0
0.72
0
0.87
3
0
0.39
0
0
0.87
2
0.87
0.94
0.87
0
0
0
0
0
0
0
0
0
0
0
0
0
0
115
Load Balancing & Networking
IF_EEE_WDOG_RESET
IF_EEE_RXO
IF_EEE_RXDROPS
IF_EEE_WATCHDOG
IF_RNBC
IF_EEE_ICR_XOC
IF_IPKTS
IF_IERRS
IF_OPKTS
IF_OERRS
IF_COLLS
eqcli >
116
0
0
0
0
0
0
1650
0
5356
0
0
0
0
0
0
0
0
3
0
2
0
0
0
0
0
0
0
0
1
0
0.86
0
0
0
0
0
0
0
0
0.94
0
0.72
0
0
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Viewing Port Statistics using the GUI
To view statistics for an interface in the GUI:
1. Log in to the GUI.
2. Select System > Network > Interface on the left navigational pane.
3. On the right Interface tab on the right, select a port to view statistics for. The following is an
example:
Transmitted Counters
Packets
The total number of transmitted packets on this interface.
bytes
The total number of bytes transmitted on this interface
multicasts
The total number of good broadcast/multicast (e.g., ARP) packets transmitted by this interface.
errors
The total number of bad packets transmitted by this interface.
collisions
The total number of packets that were dropped (e.g., lack of transmit buffer , collision
detection). These packets are not transmitted by the interface.
Received Counters
Packets
The total number of packets received on this interface.
bytes
The total number of bytes received on this interface.
multicasts
The total number of good broadcast/multicast (e.g., ARP) packets received on this interface.
errors
The total number of bad packets (e.g., CRC errors,, alignment errors) received on this interface.
drops
The total number of packets that were dropped (e.g., lack of receive buffer, congestion, invalid
classification, e.g., tagged frame received on untagged port) by the receiving interface.
unknown
protocol
Tot total number of packets received on this interface that used an unknown protocol.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
117
Load Balancing & Networking
Configuring VLAN Interfaces
Many networking technologies use a technique called broadcasting to provide services on a Local
Area Network (LAN). Like traditional television or radio signals that are broadcast over the
airwaves, broadcast network transmissions are received by every node on the same LAN
segment, or broadcast domain. The Address Resolution Protocol (ARP), the Dynamic Host
Configuration Protocol (DHCP), and the Router Information Protocol (RIP) are all examples of
protocols that provide network services through broadcasting.
A LAN is a single broadcast domain composed of all the systems that are physically connected to
the same switches, hubs, and other devices that communicate at the Data Link Layer (Layer 2) of
the OSI Networking Model. These devices communicate using Layer 2 protocols, like Ethernet and
ARP.
Virtual Local Area Network (VLAN) technology was developed to overcome these physical
limitations of traditional LAN technology. A VLAN is essentially a means of grouping systems at
the Data Link Layer (Layer 2 of the OSI networking model), using methods that are independent of
the physical connection of the device to the network.
By exchanging broadcast packets -- packets that are essentially sent to all systems connected to a
Layer 2 switching device -- switches can maintain a list of all MAC addresses connected to them
and to the other switches to which they are connected. A set of Layer 2 devices and the systems
connected to them form a broadcast domain -- meaning that all the systems can talk to one
another using broadcast packets.
Conversely, broadcast packets are not forwarded beyond the boundaries of the broadcast domain.
For example: if two LANs are connected by a router (a Network Layer, or Layer 3, device), the
broadcast traffic for one LAN is never forwarded to the other LAN. The layout of a traditional LAN
is therefore restricted to those systems that can be wired together using Layer 2 devices -- a
physically distant system that requires connectivity to the LAN would require special routing and
address translation (at Layer 3) in order to reach the LAN.
The dependence of LAN technology on physical connectivity at Layer 2 leads to two basic
difficulties:
l
l
118
Broadcasts are received by all systems in the broadcast domain - and if there is sufficient
broadcast traffic, it can significantly reduce the overall performance of the LAN, to the point
where some services may simply not be able to function properly due to latency or other
factors introduced by a high level of broadcast traffic.
If you want to include a system that is not physically connected to the LAN in the LAN’s
broadcast domain, you need to physically connect the system to the LAN.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
One problem with broadcasting is that lots of broadcast traffic on a LAN can slow network traffic
down, as well as slow individual systems down. If there is so much broadcast traffic on the LAN
that other non-broadcast traffic is significantly delayed (or never delivered), this is called a
broadcast storm. Broadcast storms typically arise when network loops are created through faulty
network configuration, but can also happen as the result of a malicious attack. For example, a
classic Denial of Service attack is to send an ICMP echo request ("ping") over the LAN that
specifies the source address of a system and a broadcast address for the destination. Every
system receiving the ping will respond to it -- flooding the system specified as the source of the
ping with ICMP echo replies.
There are also other security concerns associated with broadcasting. Since all the systems in the
broadcast domain can see broadcast packets, the information in them is susceptible to discovery,
intercept, and modification. This is of particular concern in industrial Ethernet environments
(where, for example, manufacturing processes are controlled directly by computers) and in any
environment (such as government and finance) where sensitive data is regularly transmitted over
the LAN.
A number of methods can be used to mitigate problems and threats associated with large
broadcast domains, including broadcast filtering and physically separating large broadcast
domains into smaller domains. The problem with these solutions is that the are typically
implemented at the Network Layer (Layer 3), and require Layer 3 devices (such as routers and
firewalls) to implement them. These Layer 3 devices require separate subnets, and themselves
emit a significant amount of broadcast traffic.
What we really want is a way of abstracting the idea of a LAN so that large broadcast domains can
be separated into smaller domains without requiring any network rewiring or physical movement
of systems. We’d also like the ability to extend broadcast domains across Layer 3 devices to
physically remote systems.
With a VLAN, the broadcast domain for a particular system is determined by the software settings
on the Layer 2 switch port to which the system is connected.
So, for example, in a traditional LAN, all the systems connected to Switch A would be part of
Broadcast Domain A. If the switch is a VLAN-capable switch, then it is possible to configure
several ports on the switch for VLAN A, several others to VLAN B, others to VLAN C, and so on.
This allows you to both:
l
reduce the number of devices in local broadcast domains
l
extend broadcast domains across devices separated by more than one switch
The predominant VLAN standard is 802.1q. This standard adds a VLAN tag to the information in the
Ethernet packet. Since they operate at the switching level, VLANs are Layer 2 technologies -though they are often confused with Layer 3 subnetting, because in many configurations there is
one VLAN configured per subnet. This is usually done for the practical purpose of allowing the
systems on a VLAN to be managed as a group by other network management devices/software
that work by IP address ranges, for example, rather than VLAN tags.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
119
Load Balancing & Networking
Configuring VLANs
The following table shows you how to perform VLAN tasks using the CLI and the GUI:
It should be noted that on switch less system only one port can be assigned to a VLAN. On
Equalizers with a front-panel switch (E350GX, E450GX, E650GX), multiple ports can be assigned to
a VLAN.
Note - The VID values must be between 1 and 4094.
Adding a removing VLANs
Adding a VLAN using the CLI
Create a VLAN , enter a command as follows:
eqcli > vlan vlname vid vlan_ID
Replace vlname with the VLAN name and vlan_ID with the VLAN ID number (1- 4094). If you are
using untagged VLANs (common in many sites), the VLAN ID can be any number not used on
another VLAN. If you are using tagged VLANs, check with your network Administrator for the
correct VLAN ID to specify.
Adding a VLAN using the GUI
1. Right-click VLANs in the left frame.
2. Select Add VLAN from the pop up command menu.
3. Enter a VLAN Name and VID (VLAN ID).
4. Click Commit .
120
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Modifying VLANs
Modifying a VLAN using the CLI
eqcli > vlan name [parameters]
where:
name - is the name of the VLAN
Parameters - are the values and flags assigned to the VLAN (Refer to "VLAN and Subnet
Commands" on page 261)
Modifying a VLAN using the GUI
1. Expand the VLANs node in the left frame.
2. Click the name of the VLAN you want to modify. The VLAN configuration tabs appear in the
right frame.
3. Edit the VLAN configuration using the radio buttons.
4. Click Commit before navigating away from a tab to apply your changes.
Displaying VLAN Details
Displaying VLAN Details using the CLI
To display the status of all configured VLANS enter:
eqcli
Name
v2
v3
eqcli
> show vlan
VID
2
3
>
To display the details of a specific VLAN enter the following with the VLAN name in the syntax.
eqcli > show
This vlan is
VLAN Name :
VID
:
MTU
:
Subnets
:
Interfaces :
eqcli >
vlan v2
enabled.
v2
2
1500
sn172
if01 (untagged)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
121
Load Balancing & Networking
Displaying VLAN Details using the GUI
1. Select System > Network > VLANs on the left navigational pane on the GUI.
2. To display details of a specific VLAN, click a VLAN name to display the configuration tab for
that VLAN in the right frame.
VLAN Port Assignment Using the GUI
The VLAN Port Assignment Configuration Screen is used to assign ports, specify whether a VLAN is
tagged or untagged and specify MTU. It is accessed by clicking on a VLAN on the left navigational
pane of on the GUI. Consider the following example:
The GUI displays an icon in the left navigational pane next to the name of any VLAN if it does not
have any assigned interfaces. Moving the mouse over the icon displays text indicating that the
VLAN configuration is incomplete.
The VLAN Port configuration on the E670LX and E970LX displays
l
8-1GB ports
l
1-1GB management port
l
2-10GB ports and.as many aggregated ports as are currently configured by the user.
The E470LX and E370LX do not have 10GB ports so the 10 GB pane is not displayed on the VLAN
Port configuration screen.
The E370LX does not have a MGMT port and does not appear in the 1GB pane.
122
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
On the LX Series of Equalizers, only 1 port can be assigned to a VLAN. Aggregated ports, however,
can be configured. Refer to "Configuring Aggregated Interfaces" on page 131for details.
VID
A unique integer identifier for the VLAN, between 1 and 4094.
MTU can be specified for tagged and untagged VLANs on all switched systems
(E350GX, E450GX, E650GX)for tagged VLANs on non-switched systems
(E250GX,LX Series, Equalizer OnDemand. The MTU is set on the VLAN, and the
values you can set depend on the Equalizer model and the subnet configuration of
the VLAN, as follows:
For the E350GX, E450GX, E650GX, and E370LX, the maximum
MTU value is 4839.
MTU
For E250GX models and Equalizer OnDemand, the maximum MTU
is 9000.
For VLANs with only IPv4 subnets, the minimum MTU is 576.
For VLANs with an IPv6 subnet, the minimum MTU is 1280.
If you modify the MTU on a VLAN to a value that is lower than the currently set
value, you must reboot Equalizer to ensure proper network interface operation.
Status
Assign a port status on the VLAN using the radio buttons.
VLANs can either be tagged or untagged and set for the port on the VLAN using
the appropriate radio button:
Type
Tagged ports can be assigned to more than one VLAN.
Untagged ports can be assigned to exactly one VLAN.
Click on Commit to save your settings or Reset to revert to the previous settings.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
123
Load Balancing & Networking
VLAN Port Assignment Using the CLI
Create a VLAN and subnet over which you can log into Equalizer. If you want to license Equalizer
online, the subnet you create should also be able to reach the Internet.
1. Create a VLAN as described previously.
2. Add a subnet to the VLAN you just created. You’ll need to specify the following:
l
l
l
The subnet IP address, which is the ADCs address on this network. It must be an IPv4 or
IPv6 address in CIDR (Classless Inter-Domain Routing) format (e.g., 172.16.0.123/21).
The default route IP address for the subnet gateway. This is an unadorned IP address (e.g.,
172.16.0.1).
The HTTP and SSH services, so that you can log in to the Graphical User Interface (GUI) and
Command Line Interface (CLI) on this subnet.
Enter the following command, all on one line:
eqcli > vlan vlname subnet subnet name ip CIDR format IP address route dest_
cidr src src cidr gw ip_addr
In the command above,vlname is the VLAN name from the previous step, subnet
name is the name of the subnet, ipis the CIDR format IP address, routeis the
destination network in CIDR notation, src is the source network in CIDR notation
(optional), and gw is IP address of the gateway for the route.
Refer to the webhelp if you need more help setting up your initial VLAN and subnet: go
to www.coyotepoint.com, move your mouse over the Support link near the top of the
screen, and choose Manuals from the drop down list.
3. Associate an interface instance with the VLAN. Here we assume that you are using the port
labelled ‘1’ on the front panel. Enter one of the following commands, depending on whether
the VLAN you created above is untagged or tagged (ask your network administrator if you
are unsure):
eqcli > vlan vlname ifi ge01 type untagged
eqcli > vlan vlname ifi ge01 type tagged
4. Connect the port or ports you configured on the VLAN to the network using a standard
Ethernet cable with RJ-45 connectors. You should now be able to use the "ping" command
from a workstation on the same subnet to reach the subnet IP address configured above.
124
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Subnets
Adding and Removing Subnets
To add a subnet using the CLI
Add a subnet to a VLAN. You’ll need to specify the following:
l
l
l
The subnet IP address, which is the ADCs address on this network. It must be an IPv4 or
IPv6 address in CIDR (Classless Inter-Domain Routing) format (e.g., 172.16.0.123/21).
The default route IP address for the subnet gateway. This is an unadorned IP address (e.g.,
172.16.0.1).
The HTTP and SSH services, so that you can log in to the Graphical User Interface (GUI) and
Command Line Interface (CLI) on this subnet.
Enter the following command, all on one line:
eqcli > vlan vlname subnet subnet name ip CIDR format IP address route dest_
cidr src src cidr gw ip_addr
In the command above,vlname is the VLAN name from the previous step, subnet
name is the name of the subnet, ipis the CIDR format IP address, routeis the
destination network in CIDR notation, src is the source network in CIDR notation
(optional), and gw is IP address of the gateway for the route.
To remove a subnet using the CLI
eqcli > no vlan name subnet name
where:
name - is the name of the subnet being deleted.
To add a subnet using the GUI:
1. Select System > Network > VLANs on the left pane.
2. Select Add Subnet from the pop up command menu.
3. Enter a Subnet Name,and IP Address in the pop up window on the right.
4. Click Commit .
To remove a subnet using the GUI;
1. Select System > Network > VLANs on the left pane.
2. Click on the arrow (u) next to a specific VLAN to expand the branch to display all configured
subnets .
3. Right-click the name of the subnet you want to delete.
4. Select Delete Subnet from the popup command menu.
5. Click Confirm.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
125
Load Balancing & Networking
Modifying a Subnets
Modifying a subnet using the CLI
eqcli > vlan name subnet subnet_ame [parameters]
where:
name - is the name of the vlan
subnet_name - is the name of the subnet
parameters - is the name of the parameter to be modified.
Modifying a subnet using the GUI
1. Select System > Network > VLANs on the left pane.
2. Click on the arrow (u) next to a specific VLAN to expand the branch to display all configured
subnets .
3. Click the name of the subnet you want to modify. The configuration displays appear in the
right pane.
4. Edit the subnet configuration using the controls on each tab.
5. Click Commit before navigating away to apply your changes.
Displaying a Summary of All Subnets in a VLAN
Displaying a Summary of All Subnets in a VLAN using the CLI
eqcli > show vlan name subnet
eqcli > show vlan v2 subnet
Name
IP Address
sn172 172.16.6.1/21
eqcli >
Displaying a Summary of All Subnets in a VLAN using the GUI
N/A
126
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying Subnet Details
Displaying subnet details using the CLI
eqcli > show vlan name subnet subnet_name
where:
name - is the name of the VLAN.
subnet_name - is the name of the subnet.
eqcli > show vlan v2 subnet sn172
This subnet is enabled.
Subnet Name
: sn172
Subnet Flags
: heartbeat, command
Services Flags
: http, https, ssh, fo_http, fo_https, fo_ssh
IP Address
: 172.16.6.1/21
Virtual IP Address
: 172.16.6.100
Subnet Heartbeat Interval : 2
Subnet Strike Count
: 3
Permitted subnets
:
Routes
: 2 routes
NAT
: 0 NATs
eqcli >
Displaying subnet details using the GUI
1. Select System > Network > VLANs on the left pane.
2. Click on the arrow (u) next to VLANs to expand the branch to display all configured VLANs
3. Click on the arrow (u) next to a specific VLAN to expand the branch to display all configured
subnets .
4. Click a subnet name to display the configuration displays for that subnet in the right pane.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
127
Load Balancing & Networking
About Permitted Subnets
By default, each VLAN will not forward packets for any other subnet unless they are specifically
designated in the Permitted Subnets screen-- sometimes referred to as a "subnet access control
list". When a new subnet is added it will be automatically be added to the Deny pane on this
screen.
If you would like to allow packets from any other subnet to be forwarded they must be added to
the Permit pane on this screen. Using drag and drop functionality, drag a Subnet from the Deny pane
and drop it in the Permit pane to allow packet forwarding on the subnet. Similarly, if you would like
to remove a subnet from the Permit pane, you can drag and drop to the Deny pane.
Click on Reset to revert to the default permissions. Click on Commit to save any subnet permission
changes made.
See "VLAN and Subnet Commands" on page 261 for commands used in permitted subnets using
the CLI.
128
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Outbound NAT
Enabling outbound NAT allows servers on a non-routable network to communicate with hosts on
the internet by mapping the server's IP address to another IP address that is routable on the
internet. On Equalizer, this is disabled by default. Enabling this option has a performance impact,
since Equalizer needs to modify every packet sent and received on server subnets.
Outbound NAT can be configured to map a server's IP address to any IP address in the IP
address range defined for that subnet. The IP address can be either:
l
l
An already instantiated IP address on that subnet for a system object, such as:
o
the subnet IP address
o
the failover IP address
o
any cluster IP address
An IP address that is not already instantiated on that subnet.
If the NAT address that you enter is not already instantiated on the outbound subnet, it will
be instantiated. Therefore, you need to make sure that no other device on the subnet is
using the NAT IP address you specify, or there will be duplicate IP addresses on the subnet
that will cause connectivity issues.
Note - Because outbound NAT is configured on a subnet basis, individual servers cannot be set up for different
outbound NAT IP addresses unless they are in different subnets.
When outbound NAT rules are configured for a subnet, the system treats packets on that subnet as
if they are part of the external subnet through which they are being NAT'd.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
129
Load Balancing & Networking
Configuring outbound NAT using the CLI
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. NAT can be set up by entering a from parameter in CIDR format that specifies the IP range.
The from address is the source IP address (or range of addresses) to which this NAT
rule applies. Use a CIDR-format IP address to specify a range. If the source IP
address of an outbound packet matches this IP address (or falls within the specified
range), then the packet is modified to use the IP address specified by the out
parameter as the source IP.
The out address specifies that if the source IP address of an outbound packet
matches the IP address (or IP address range) specified by the from parameter, then
the packet is modified to use this IP address as the source IP.
eqcli> vlan vlan-name subnet subnet-name nat from ip_cidr out 1.2.3.33 nat
subnet-name out gw gateway ip
Configuring outbound NAT using the GUI
1. Log into the GUI.
2. Click on System > Network > VLAN on the left navigational pane.
3. Select a subnet and click on the NAT tab on the right. All configured NAT rules will be
displayed.
4. Click on + to activate the Add NAT Rule dialogue.
5. Configure outbound NAT using either of the following methods:
l
l
Enter a From IP and the Up To IP which specifies the IP range. Also enter the Out
(outbound NAT IP) address.
Enter a from IP, without the Up To IP.Also enter the Out (outbound NAT IP)
address.
The From address is the source IP address (or range of addresses) to which this NAT
rule applies. Use a CIDR-format IP address to specify a range. If the source IP
address of an outbound packet matches this IP address (or falls within the specified
range), then the packet is modified to use the IP address specified by the Out
parameter as the source IP.
The Out address specifies that if the source IP address of an outbound packet matches
the IP address (or IP address range) specified by the From parameter, then the packet
is modified to use this IP address as the source IP.
6. Click on Commit to save your settings. The new NAT Rule will appear in the Subnet NAT
display on the right.
130
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Aggregated Interfaces
Note -Link Aggregation is supported on the LX series, all virtual platforms, and on legacy E250GX systems only.
Link aggregation combines multiple physical interfaces into a single aggregated (or, logical)
interface, providing increased bandwidth as well as link redundancy. Traffic is distributed evenly
over the physical links of the aggregation group; and, if one of the links in the aggregated
interface becomes unavailable, traffic will continue to flow over the available interfaces in the
group.
Link Aggregation Protocol (LACP)
LACP is a protocol used between network devices to automatically bundle links between the
devices, and is supported by link aggregation. Once you configure an aggregated interface with
LACP enabled, LACP packets are broadcast to other directly connected devices (such as switches
and routers), which will create the necessary aggregated links (if they are also enabled for LACP).
Aggregated links on other network devices must be manually created on those devices if either
LACP is disabled on the aggregated interface you create, or if a network device does not support
LACP.
LACP supports active mode only; passive mode LACP is not supported.
General Process for Creating Aggregated Interfaces
1. Configuration of aggregated interfaces via the CLI/GUI by specifying:
a. A unique aggregated interface name.
b. The physical interfaces (ports) to be configured as members of the aggregated
interface.
c. A flag indicating whether LACP is to be enabled or disabled (it is enabled by default).
2. Assign the aggregated interface to a VLAN by adding an interface instance of the
aggregation group to the VLAN
Limitations
1. A maximum of 4 physical interfaces may be combined into one aggregated interface.
2. A physical interface may belong to no more than 1 aggregated interface.
3. An aggregated interface may be specified as an untagged interface in no more than one
VLAN. (There are no limitations for aggregated interfaces used as tagged interfaces; in
other words, an aggregated interface may be specified as a tagged interface in multiple
VLANs).
4. When assigning interfaces (physical or aggregated) to a VLAN, only one interface (physical
or aggregated) can be assigned to a VLAN. In other words, if you want to assign two
physical interfaces to the same VLAN, you must first create an aggregated interface
containing those two physical interfaces, and then assign the aggregated interface to the
VLAN.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
131
Load Balancing & Networking
Configuring Link Aggregation using the CLI
To create a link aggregation group and assign it to a VLAN using the CLI, do the following:
1. Create an aggregation group as follows.
eqcli > agr agr00
2. Specify the physical interfaces to be added to the aggregation group:
eqcli > agr agr00 ifi ge01,ge02
In the command line above, agr00 is the name assigned to the aggregation group;
ge01 and ge01 are the physical interfaces (front panel ports) assigned as interfaces
instances (ifi) to the group.
3. Verify the aggregation configuration by entering:
eqcli > show agr agr00
AGR Name
: agr00
Flags
: lacp
Interfaces
: ge01, ge02
ge01 Partner : 08:9e:01:ba:51:61
ge02 Partner : 08:9e:01:ba:51:61
eqcli >
The status of each physical interface in the interface instance is displayed as a
"Partner" in the aggregation summary display.(e.g., ge01 Partner, ge02
Partner).
l
l
l
When link aggregation is enabled, a MAC address of a "partner" is reported in
the show display The MAC address will be that of the first member of the
aggregated link on the "partner" side.
If no link is established, Not Present will be displayed. This indicates that the
other (partner) side of the aggregated interface is not configured or that it is
configured as "static". When both sides configure the aggregated link as
dynamic, link aggregation is enabled. This means that MAC addresses are
exchanged.
When "Link down" is reported as the "partner" status there is a problem
connecting to a port on the partner side of the aggregated link.
Note - The lacp flag is enabled by default.
4. If you have not done so already, create a VLAN and do not assign any interfaces to it. See
"Configuring VLANs" on page 120 for how to create a VLAN.
132
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
5. Add an instance of the new link aggregation group created above. In the example below, an
interface instance of the agr00 aggregated link created above is added to the VLAN vl00
as a tagged interface.
eqcli > vlan vl00 ifi agr00 type tagged
6. Verify the new VLAN configuration and associated interfaces by entering:
eqcli > show vlan v100
VLAN Name
VID
MTU
Subnets
Interfaces
:
:
:
:
:
v100
1
1500
sn02
agr00
Removing an Aggregated Interface from a VLAN using the CLI
To remove an aggregated interface from the VLAN used in the previous example above, enter the
following command:
eqcli > no vlan vl00 ifi agrname
Removing an Aggregated Interface from the System using the CLI
To delete an aggregated interface from the system, you should first remove it from all VLANs that
use it (see above), and then enter the following command:
eqcli > no agr agrname
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
133
Load Balancing & Networking
Configuring Link Aggregation using the GUI
To create a link aggregation group and assign it to a VLAN using the GUI, do the following:
1. Click on the System configuration tab on the left pane of the GUI if it is not already selected.
2. Click on the arrow (u) beside Network to expand the branch.
3. Click on Aggregation to display the Aggregation configuration screen. The screen features
accordian tabs that will display the configured Aggregated Interfaces when clicked. The
example below shows E670LX/E970LX.
134
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
4. Click on
on the Aggregated Interfaces configuration screen. The Add Aggregated Interfaces
dialogue shown below will be displayed. (E670LX/E970LX shown)
5. Enter a name in the Aggregated Interface Name field and select the assigned radio button on ports
to be included in the aggregated interface.
Note - The Link Aggregation Control Protocol (LACP) flag is enabled by default.
6. Click on Commit to save the new aggregated interface.
7. Click on a VLAN on the left navigational pane and the aggregated interfaces that have been
created will be displayed as shown below on the VLAN Configuration screen. Add Aggregated
interfaces to the VLAN by selecting radio buttons . VLANs can either be tagged or untagged.
tagged ports can be assigned to more than one VLAN. untagged interfaces can be assigned to
exactly one VLAN. Select an appropriate radio button in Type. (E670LX/E970LX shown)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
135
Load Balancing & Networking
8. Click on Commit to save assignments.
Removing an Aggregated Interface from a VLAN using the GUI
To remove an aggregated interface from a VLAN:
1. Select a VLAN from the left navigational pane to display the VLAN Configuration screen.
2. Select the unassigned radio button from the Aggregated Interfaces pane at the bottom of the
screen.
3. Click on Commit to complete the process.
Removing an Aggregated Interface from the system using the GUI
1. Click on the System configuration tab on the left pane of the GUI if it is not already selected.
2. Click on the arrow (u) beside Network to expand the branch.
3. Click on Aggregation to display the Aggregated Interfaces screen.
4. Select the Aggregated Interfaces accordian tab that you want to remove from the system.
5. Click on
to remove the interface.
6. Click on Commit to complete the process.
136
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Static Routes
Subnet destination routes are commonly called "static routes" and are commonly used to specify
routes to destination IP addresses via gateways other than the subnet’s default route (also called
a default gateway). They are called destination routes, since they are used to make routing
decisions based on a packet’s destination IP address.
default route can be specified for every subnet (previous releases supported a single global
default route). If you need to access systems on another subnet that cannot be reached via this
gateway, then you need to specify a static route to those systems through the gateway for that
subnet.
subnet also has its own subnet-specific static route table. Subnet static routes can be specified via
the CLI or the GUI.
Also refer to "Source Based Routing Scenarios" on page 141 for a description of source-based
routing scenarios.
Configuring Subnet Static Routes using the GUI
Do one of the following:
1. In the GUI, click on the System configuration tab if it is not already selected. Then click on
the arrow (u) beside VLANs to expand the branch. Click on the arrow (u)beside a VLAN to
expand the branch to display the subnets. Right-click on the name of a subnet and select Add
Static Route.
or
2. In the GUI, click on the System configuration tab if it is not already selected. Then click on
the arrow (u) beside VLANs to expand the branch. Click on the arrow (u)beside a VLAN to
expand the branch to display the subnets and select a subnet.
The following will be displayed.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
137
Load Balancing & Networking
Specify the Destination IP Address, Gateway, and Source IP address. This determines the route to
be used. For example, you may want a set of routes on a subnet such as the following:
1. Destination IP Address: 0/0, Gateway: 172.16.0.1, Source IP: 188.161.0.118.32
2. Destination IP Address: 0/0, Gateway: 192.168.0., Source IP: sn (subnet)
This routing scenario says:If a packet destined to "anywhere" (Destination IP Address 0/0) is from
Source IP 188.161.0.118/32, use Gateway 172.16.0.1. Otherwise, use Gateway 192.168.0.1.
GUI Parameters
Description
Destination IP Address
The IP address for the host or subnet. For IPv4, specified as a Classless Internet
Domain Routing (CIDR) address (e.g. 192.168.1.0/24). For IPv6, specified using
IPv6 subnet notation.
Gateway
The IP address of the gateway used to reach the host or subnet.
Source IP
The IP address of where a packet originates.
Prefer
Enabling this flag allows you to specify the “preferred” route to be used for any
matching destination - even if the destination address is on a subnet that is
defined on Equalizer. One Prefer flag is allowed for each subnet is allowed at this
time, however, this can be enabled on as many static routes as necessary.
To modify a static route, highlight the route in the table and click the Modify icon
parameters and click Commit.
To delete a static route, highlight the route in the table and click the Delete icon
138
. Change the
.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Subnet Static Routes using the CLI
Static routes are specified in the subnet context (See "VLAN and Subnet Commands" on page
261).
To display the static route for a subnet, use the show command:
eqcli > show vlan vlan_name subnet subnet_name
To add a static route from the global context, enter:
eqcli > vlan vlan_name subnet subnet_name dest destination IP src source IP gw
gateway IP
The parameters are explained as follows:
CLI Parameters
Description
vlan_name
The name of the VLAN.
subnet_name
The name of the subnet.
dest
The IP address for the host or subnet. For IPv4, specified as a Classless Internet
Domain Routing (CIDR) address (e.g. 192.168.1.0/24). For IPv6, specified using
IPv6 subnet notation.
gw
The IP address of the gateway used to reach the host or subnet.
src
The IP address of where a packet originates.
Prefer
Enabling this flag allows you to specify the “preferred” route to be used for any
matching destination - even if the destination address is on a subnet that is
defined on Equalizer. One Prefer flag is allowed for each subnet is allowed at this
time, however, this can be enabled on as many static routes as necessary.
Note - the “prefer” flag, which allows you to specify the “preferred” route to be used for any matching destination even if the destination address is on a subnet that is defined on Equalizer- is not available using eqcli at this time.
To delete a static route, use the no form of the route command.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
139
Load Balancing & Networking
Policy Routing
Routing is the process of selecting the network path to use when one device (the source) sends a
packet to another device (the destination) on the network. The other device can be on a subnet
that is directly connected to the appliance, or it may be on a remote subnet.
To communicate with a device that resides on a directly connected IP subnet (that is, both devices
are in the same broadcast domain), any network device uses the information in its Address
Resolution Protocol (ARP) table to send packets directly to the destination IP address.
In order to send packets to a destination on a different network, the packet is instead sent a
“next-hop” device, usually a router, that determines how to forward it further. If the routing
device is present on the same network as the destination, it can send the packet directly to the
destination. Otherwise, it forwards it on to another router, and the process continues.
Equalizer provides the ability to configure routing to match network topologies from the simplest
to the very complex through policy routing. Policy routing gives the administrator the ability to
completely define routing behavior for each subnet, based on either the destination IP address or
the source IP address of the packet leaving.
140
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Source Based Routing Scenarios
Source routing allows the originator of a packet to partially or completely specify the path that a
packet will take through a network, as well as the return path. In contrast, non-source-routing
devices determine that path based on the packet’s destination. Source routing allows:
l
Easier troubleshooting
l
Improved traceroute
l
Enables a node to discover all the possible routes to a host.
l
Allows a source to directly manage network performance by forcing packets to travel over
one path to prevent congestion on another.
Source routing requires careful management by the administrator when building the source
address selection and source routing tables to ensure a coherent overall routing strategy. For this
reason, it is often called policy routing, since routing behavior is determined by a collection of
routing tables built by the administrator.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
141
Load Balancing & Networking
Source Selection
As a load balancing device Equalizer may change the source address in a packet, the destination
address in a packet, or both, before sending a packet on to the next-hop gateway. In doing so, it
will perform source address selection to determine the appropriate source address to use when a
packet is sent out on the network. (Refer to the illustration on the next page.)
Equalizer is frequently required to choose from a number of possible source addresses when
sending packets. An example is when it sends a probe to a server behind it. Some servers will be
on a network that is local to Equalizer, and so it will chose its IP address on the appropriate VLAN
to use as the source address in a probe packet. If the server is not located on a network that is
local to Equalizer, then Equalizer will consult the source address selection table to choose a source
address, and route the packet according to the information in the source routing table.
Refer to "Load Balancing & Networking" on page 87for a detailed discussion of VLANs and
configuration with Equalizer.
The figure below shows the general flow of a packet through Equalizer, demonstrating the various
check points and destination selection techniques that are used. In "Source Routing Scenarios" on
page 144 practical scenarios are presented in “Road Map” style to demonstrate the routing
selection used.
142
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
143
Load Balancing & Networking
Source Routing Scenarios
The following are possible scenarios for load balancing source-based routing through Equalizer:
Scenario
Source
Destination
DSS Used
Spoof Load Balancing Toward Server
1. Local Server, Local Client
2. Routed Server, Local Client
Client
Server
No
Equalizer
Server
Yes
Cluster
Client
No
Cluster
Client
No
Source
Destination
No
Equalizer
Destination
Yes
3. Local Server, Remote Client
4. Remote Server, Remote Client
Non-Spoof Load Balancing Toward Server
Spoof Load balancing Toward Client
1. Local Destination
2. Remote Destination
Non-Spoof Load Balancing Toward Client
Source, Destination Specified
1. Equalizer as Router
Generated by Equalizer
1.IP Generated by Equalizer
144
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Spoof Load Balancing Toward Server
In the load balancing source-based routing scenario presented below, spoofing is enabled so that
the source is specified by a client IP and the destination is a server IP. (Refer to the illustration on
the next page)
As indicated in the table above, four scenarios are possible:
1. Local Server, Local Client - In this case the server is local and the client is local so no
routing will be required. Since the packet has a source address and destination address has
either an alias on Equalizer or is on the local network, the packets will be sent to the
destination without routing.
2. Remote Server, Local Client - In this case the server is outside of the local network with a
client that is local. The packet has a local source IP address. The server is not on the local
network and therefore needs to be evaluated by the routing table to determine if the
destination IP address is within the source routing table block. If it does lie within the block
it will have a specific routing gateway associated with that block and will be routed using
that gateway. If the destination does not lie within the source routing table block it will be
dropped.
3. Local Server, Remote Client - In this case a server IP address lies within the local network
while the client IP address is not within the local network.
4. Remote Server, Remote Client - In this case both the server and the client lie outside of the
local VLAN.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
145
Load Balancing & Networking
146
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Spoof Load Balancing Toward Client
In the load balancing source-based routing scenario presented below, spoofing is enabled so that
the source is specified by a cluster and the destination is a client. (Refer to the illustration on the
next page) Two scenarios are possible:
1. Local Destination- in this case the packets originating from a cluster and destined for a
client has both a source IP address and a destination IP address that is on a local subnet. No
routing is required for the packet. It is simply sent to the local address on the subnet.
2. Remote Destination- in this case a packet originating from a cluster and destined for a
remote client does have a local source IP address yet the destination is not on a local
subnet. The packet will be evaluated to see whether the source address/destination pairing
is identified in a source routing table block. if it is not in the routing table the packet will be
dropped. If the destination IP is identified in the source routing table then the packet will be
sent using the gateway associated with the entry in the routing table.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
147
Load Balancing & Networking
148
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Non-Spoof Load Balancing Toward Client
This scenario is the same as "Spoof Load Balancing Toward Client" on page 147 however, spoofing
is disabled and the source is a cluster IP address and the destination is the load balancer's IP . The
routing possibilities are the same as "Spoof" load balancing except that the remote clients are not
applicable as the IP address is guaranteed to be "local".
Non Spoof Load Balancing Toward Server
This scenario is the same as "Spoof Load Balancing Toward Server" on page 145 except that in
this scenario the source IP address is the load balancer's IP address. The routing possibilities are
the same as "Spoof" load balancing except that the remote clients are not applicable as the IP
address is guaranteed to be "local".
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
149
Load Balancing & Networking
Source, Destination Specified
In this scenario, the source and destination are both specified by the client. Equalizer will function
as a router to send the packet directly to the addresses specified. (Refer to the illustration on the
next page.)
150
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Generated by Equalizer
This scenario is typically used for administrative and probing purposes. It can also be used for
upgrades, pinging and Equalizer image updates. As shown below, a packet will be dropped if no
source IP address is found. As shown below, the packet routing will be determined by the default
gateway specified in the DSS table. (Refer to the illustration on the next page.)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
151
Load Balancing & Networking
Source Routing Tables & Rules
A "Source Routing Table" on page 153 is a table that identifies how a packet should be sent by the
system based on incoming route information.
Rules in include "IP Filter Rules" on page 154, which govern the IP traffic flow into and out of the
system and includes IPv4 or IPv6 Rules, and "IP NAT Rules" on page 157, which are processed
when a packet is exiting the system.
All of this information can be viewed on the same CLI output by entering the following:
152
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Source Routing Table
The sroute table, or Source Routing Table is an excellent tool for identifying how a packet should
be sent by the system. It is an aggregation of routing or all subnets and destination networks that
you configure.
The Source Routing table is displayed as part of the CLI output when using the show sbr
command. An example is shown below:
Note - The example below is a truncated example of the show
sbr command display showing the Source Routing
Table display only.
In the example above traffic that is sourced from all local networks is sent through the 10.0.0.254
gateway, unless it is destined for the 192.168.105.0/24 destination network. Because the default
gateway for the 192.168.211.0/24 local network is on the 10.0.0/24 local network, there is an
outbound NAT configuration between these two networks.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
153
Load Balancing & Networking
IP Filter Rules
The current IP Filter rules are displayed as part of the CLI output when using the show
sbrcommand. An example is shown below. The example is shortened due to its length.
Note - The example below is a truncated example of the show
sbr command display. In addition to the IP Filter
Rules, Default Source Selection Table, the IPv6 Default Selection Table, IPv6 Rules, and IP NAT rules will also be
displayed.
IP Filter Rules:
IPv4 Rules:
1: pass on interface lo0 all hits: 287 bytes: 14900
2: pass on interface wm1 hits: 11394 bytes: 326068
From
To
192.168.211.0/24
192.168.211.0/24
192.168.105.0/24 ->
192.168.105.0/24
10.0.0.0/24
0.0.0.0/0
3: pass on interface wm0 hits: 120406 bytes: 7689819
From
To
10.0.0.0/24
10.0.0.0/24
0.0.0.0/0
->
0.0.0.0/0
192.168.211.0/24
192.168.105.0/24
4: block on interface wm1 hits: 0 bytes: 0
From
To
192.168.211.0/24
192.168.211.0/24
->
192.168.105.0/24
10.0.0.0/24
0.0.0.0/0
The example above shows each filter rule, along with the groups of networks that the rule applies
to, and the number of times each rule has been used (and bytes that have been received using
this rule).
Each column of From and To addresses can be viewed as an "or" group. For example, rule #3 can
be read as:
“Allow traffic on interface wm0 which is from either the 10.0.0.0/24 network or the 0.0.0.0/0
network, and is destined for either the 10.0.0.0/24, the 0.0.0.0/0, the 192.168.211.0/24, or the
192.168.105.0/24 network.”
Rules are processed (and must be read) in order, from first to last. This means that as soon as a
packet matches a particular rule it is used and Equalizer either passes or allows that packet,
depending on the rule.
154
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
To summarize, rules are processed in numerical order by the packet filter. Pass rules cause
packets to be allowed into the system and block rules are ones that explicitly block traffic from
entering the system. The last rule is block in all which means that if a pass rule has not yet
matched this particular packet, it will be dropped.
Using this command while trying to establish a connection that may not be working can be a good
method of finding out what is wrong. In this example, 0 packets were blocked by the filter in rule
4 because rules 2 and 3 allowed all packets needed. If there is a misconfiguration, seeing packets
being blocked can be a hint of what is wrong.
Enabling/Disabling IP Filter Rules
When you create a subnet, IP Filter (firewall) rules are automatically generated. An example is
shown above. An option is available to disable these rules that may be used for troubleshooting or
diagnostic purposes. Disabling the firewall turns off all system packet filtering . Any subnet
permit/deny rules are ignored and all traffic will be routed between subnets.
l
If you use the GUI, you will note that if you disable these rules and you navigate to System >
Network > VLANs > {any subnet} >Permitted Subnets the following message will be displayed in red
text at the top of the tab:
"Firewall rules are currently disabled. Any 'Permit' and 'Deny' selections made below
will be ignored until firewall rules are enabled."
l
If you use the CLI, you will note that when you enter eqcli > show firewall,the state will
be Disabled.
The rules are enabled by default.
To disable in the CLI, enter the following:
eqcli > firewall disable
eqcli: 12000287: Operation successful
To verify that the firewall (IPv4 Rules) have been disabled, enter the following:
eqcli > show firewall
Variable
state
Value
Disabled
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
155
Load Balancing & Networking
To disable using the GUI:
1. Log in to the GUI.
2. In the left navigational pane, select System > Global > Parameters.
3. Click on Global to expand the branch and then select Parameters to display the Parameters
configuration screen on the right.
4. Select the Disable option in the Firewall Rules group.
5. Click on Commit to save the change.
Verify that the rules have been disabled by checking the subnets, as shown above, and verify that
the disabled message appears.
Note - This is not related to the IP Reputation ( Refer to "Using the IP Reputation Database" on page 704) filtering or
any white/blacklists that may exist as part of that configuration.
156
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
IP NAT Rules
Equalizer performs outbound NAT by creating IP NAT rules. These rules are processed when a
packet is exiting the system -unlike IP Filter rules which are processed when a packet is entering
the system. When NAT is enabled, the system automatically generates NAT rules to support the
specified configuration. The rule types are labeled proxy port, ftp, ftp/tcp, tcp/udp, etc.
These rules can are also displayed as part of the CLI output when using the show sbr command.
An example is shown below:
Note - The example below is a truncated example of the show
sbr command display. In addition to the IP NAT rules,
Default Source Selection Table, the IPv6 Default Selection Table, IP Filter Rules, and IPv6 Rules will be displayed.
IP NAT Rules:
List of
map wm0
map wm0
map wm0
map wm0
map wm0
map wm0
active MAP/Redirect
192.168.211.0/24 ->
192.168.211.0/24 ->
192.168.211.0/24 ->
192.168.105.0/24 ->
192.168.105.0/24 ->
192.168.105.0/24 ->
filters:
10.0.0.68/32
10.0.0.68/32
10.0.0.68/32
10.0.0.68/32
10.0.0.68/32
10.0.0.68/32
proxy port ftp ftp/tcp
portmap tcp/udp auto
proxy port ftp ftp/tcp
portmap tcp/udp auto
List of active sessions:
Three rules are added for each outbound NAT mapping. In this example, there are two mappings:
one for the 192.168.211.0/24 local network and the other for the 192.168.105.0/24 destination
network.
In this example, the rules specify that any packets that are leaving the system through the wm0
interface with a source IP address on either the 192.168.211.0/24 or 192.168.105.0/24 network
should instead be sent with a source IP address of 10.0.0.68.
If there are any NAT connections active, they will be displayed in the list of active sessions.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
157
Load Balancing & Networking
IPv6 Tunnel Overview
Every network administrator needs to have a strategy to address the transition to the IPv6
Internet. Various transition mechanisms have been defined that are intended to make it as easy
as possible for organizations to get on the IPv6 Internet using their current IPv4 network
infrastructure. For many organizations, the easiest and fastest way to get applications up and
running on the IPv6 Internet is to use a transition mechanism called an IPv6 tunnel.
One of the most common issues when an organization begins to support IPv6 is how to allow IPv6
enabled devices to communicate over those portions of the network that are not IPv6 enabled.
This can include both portions of a corporate intranet as well as Internet connections managed by
an Internet Service Provider (ISP) that does not yet provide IPv6 connectivity.
An IPv6 tunnel solves this issue by encapsulating IPv6 packets inside IPv4 packets for
transmission over IPv4-only connections.
An IPv6 tunnel is obtained through an IPv6 tunnel broker. An IPv4 connection is established
between a system at your site (in this case, an Equalizer) and a system at the tunnel broker’s site.
Clusters on Equalizer are assigned IPv6 addresses within the subnet assigned by the tunnel
broker. Clients can then access the IPv6 cluster address through the tunnel.
There are a number of tunnel brokers providing IPv6 tunnels to various geographical regions. In
general, you should pick a tunnel broker that maintains tunnel servers that are geographically
close to your location for best performance.
This chapter describes how you can set up an IPv6 tunnel. Hurricane Electric (HE), one of the
leading IPv6 tunnel brokers, provides an easy way to configure a tunnel that uses the
6in4tunneling protocol. Note that a 6in4 tunnel from any tunnel broker can be used and requires
the same basic commands on Equalizer to establish your tunnel -- only the required setup on the
tunnel broker’s website will be different. Hurricane Electric offers an easy to use web interface
that allows you to request and configure a tunnel usually within a few hours.
Note that a number of different tunneling protocols exist, and the tunneling protocols supported
vary between tunnel brokers, so check a tunnel broker’s website to be sure they support 6in4
tunnels before you request one.
158
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
For example, Hurricane Electric provides what they call “regular” tunnels and “BGP” tunnels. For
Equalizer, you would choose a “regular” Hurricane Electric tunnel, which is a 6in4 tunnel.
A 6in4 tunnel allows a user to access the IPv6 internet by tunneling over an existing IPv4
connection from an IPv6-enabled host to one of Hurricane Electric's IPv6 routers on the internet.
Once a tunnel is established, the IPv6 enabled host sends IPv6 traffic over the local IPv4 network
by encapsulating IPv6 packets inside IPv4 packets. These packets are sent to the IPv6 routers
operated by the tunnel broker, unencapsulated, and then the IPv6 packets are forwarded to the
IPv6 internet.
Note - You can use IPv6 cluster addresses without establishing a tunnel on Equalizer if your organization already has
established an IPv6 tunnel and Equalizer can send IPv6 traffic through the local tunnel endpoint. In this configuration,
you would simply assign cluster IPv6 addresses from the subnet associated with the already established tunnel and
route the IPv6 traffic through the tunnel endpoint. This is done with the standard subnet configuration commands.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
159
Load Balancing & Networking
Configuring an IPv6 Tunnel
Setting up an IPv6 tunnel on Equalizer is basically a two step process:
1. Configure a VLAN over which Equalizer can reach the IPv4 Internet, and request a "6in4"
tunnel from a tunnel broker.
2. After you receive the tunnel configuration information from the broker, set up the tunnel
endpoint on Equalizer.
Once the tunnel is configured, you can perform additional tasks required to get Equalizer clusters
on the IPv6 Internet, including:
l
l
Assigning cluster IPv6 addresses from the subnet address range provided by the tunnel
broker.
Updating DNS to point to the tunnel broker’s DNS servers.
Parameters
Parameter
Description
type
Currently, ipip is the only permitted tunnel type.
local_endpoint -
The IPv4 address provided to the tunnel broker as the Equalizer endpoint for the
tunnel. It is the IP address that the tunnel broker will use to reach Equalizer. This
is either ’s VLAN IP on the subnet created in Step 1 or the IP address with which
Equalizer’s VLAN IP is associated via Network Address Translation (NAT).
remote_endpoint -
The IPv4 address of the tunnel broker side of the tunnel as provided by the tunnel
broker.
local_address
The IPv6 address of the Equalizer side of the tunnel; this is assigned by the user
and must be within the address range provided by the tunnel broker.
remote_address
The IPv6 address of the tunnel broker side of the tunnel as provided by the tunnel
broker.
160
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Creating a "6in4" IPv6 Tunnel using the CLI
1. Configure a VLAN and subnet to use as the local IPv4 endpoint for the tunnel using VLAN
context commands (See VLAN and Subnet Commands). Note the following:
l
l
l
The IPv4 address assigned to the subnet must either be a routable IPv4 address or resolve
to a routable IPv4 address via Network Address Translation (NAT) on another device.
The routable IPv4 address associated with this VLAN is the one that is supplied to the tunnel
broker as the local endpoint of the tunnel. Changes to this address must be coordinated with
the tunnel broker.
The ports (both tagged and untagged) that are assigned to this VLAN are the ports on which
the IPv6 address block assigned by the tunnel broker will be accessible.
2. Request a "regular" tunnel using Hurricane Electric’s website at:
http://www.tunnelbroker.net
When providing the local IPv4 endpoint address, use the IPv4 address assigned to the
VLAN subnet created in Step 1, or its routable NAT address.
Hurricane Electric will set up the tunnel and provide you with the following
information:
l
The IPv4 and IPv6 addresses for the Hurricane Electric tunnel endpoint.
l
The IPv6 address of the default route for the tunnel.
l
The IPv6 address block assigned by Hurricane Electric (a /64 prefix subnet).
l
The IP addresses of Hurricane Electric's IPv6 and IPv4 DNS servers. (See below)
3. Create the tunnel on Equalizer using the information from the previous step. [For
illustration, we use the multi-line command format below; the tunnel command can also be
entered on a single line.] Enter:
eqcli> tunnel
eqcli tl-HE1>
eqcli tl-HE1>
eqcli tl-HE1>
eqcli tl-HE1>
eqcli tl-HE1>
eqcli tl-HE1>
HE1
type ipip
local_endpoint ipv4_addr
remote_endpoint ipv4_addr
local_address ipv6_addr
remote_address ipv6_addr
commit
The parameter arguments are as follows:
4. If it does not already exist, configure the VLAN presence on the Equalizer for this tunnel:
eqcli> vlan vlan_name vid VLAN_ID flags tunnel
eqcli> vlan vlan_name subnet subnet_name ip local_address default_route ipv6_addr
Note the following:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
161
Load Balancing & Networking
l
You can choose any names for the VLAN and subnet.
l
The VLAN ID (vid) supplied must be appropriate for your network configuration.
l
l
l
The IPv6 address used for the subnet ip parameter must be the same as the local_address
specified for the tunnel command in the previous step.
The default_route parameter must be set to the IPv6 address provided by the tunnel broker
as the default tunnel route.
The VLAN parameters untagged_ports and tagged_ports are not required when the tunnel flag
is specified on the vlan command line. If they are specified, they will be ignored. [The front
panel ports on which the tunnel is accessible are the ports defined for the VLAN that we set
up in Step 1.]
You should now be able to assign IPv6 addresses from the tunnel’s IPv6 address block as cluster
IP addresses on Equalizer, and clients from the IPv6 Internet should be able to connect to them
using the cluster’s IPv6 address.
162
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Creating a "6in4" IPv6 Tunnel using the GUI
1. Configure a VLAN and subnet to use as the local IPv4 endpoint for the tunnel using VLAN
context commands (See VLAN and Subnet Commands). Note the following:
l
l
l
The IPv4 address assigned to the subnet must either be a routable IPv4 address or resolve
to a routable IPv4 address via Network Address Translation (NAT) on another device.
The routable IPv4 address associated with this VLAN is the one that is supplied to the tunnel
broker as the local endpoint of the tunnel. Changes to this address must be coordinated with
the tunnel broker.
The ports (both tagged and untagged) that are assigned to this VLAN are the ports on which
the IPv6 address block assigned by the tunnel broker will be accessible.
2. Request a "regular" tunnel using Hurricane Electric’s website at:
http://www.tunnelbroker.net
When providing the local IPv4 endpoint address, use the IPv4 address assigned to the
VLAN subnet created in Step 1, or its routable NAT address.
Hurricane Electric will set up the tunnel and provide you with the following
information:
l
The IPv4 and IPv6 addresses for the Hurricane Electric tunnel endpoint.
l
The IPv6 address of the default route for the tunnel.
l
The IPv6 address block assigned by Hurricane Electric (a /64 prefix subnet).
l
The IP addresses of Hurricane Electric's IPv6 and IPv4 DNS servers. (See below)
5. Select System > Network on the left navigational pane.
6. Right click on Tunnels and select Add Tunnel.
7. Use the Add Tunnel pop up as shown below to create the tunnel on Equalizer using the
information from the previous step.
8. Enter parameters as described above in "IPv6 Tunnel Overview" on page 160. Note the
following:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
163
Load Balancing & Networking
l
You can choose any names for the VLAN and subnet.
l
The VLAN ID (vid) supplied must be appropriate for your network configuration.
l
l
l
The IPv6 address used for the subnet ip parameter must be the same as the local_address
specified for the tunnel command in the previous step.
The default_route parameter must be set to the IPv6 address provided by the tunnel broker
as the default tunnel route.
The VLAN parameters untagged_ports and tagged_ports are not required when the tunnel flag
is specified on the vlan command line. If they are specified, they will be ignored. [The front
panel ports on which the tunnel is accessible are the ports defined for the VLAN that we set
up in Step 1.]
You should now be able to assign IPv6 addresses from the tunnel’s IPv6 address block as cluster
IP addresses on Equalizer, and clients from the IPv6 Internet should be able to connect to them
using the cluster’s IPv6 address.
9. Click on Commit to save the Tunnel.
Configuring DNS for IPv6 Tunnels
The Domain Name System (DNS) is used by both IPv4 and IPv6 systems to provide name to
address mapping, and address to name mapping. Systems that support both IPv4 and IPv6 will
require DNS entries that describe the mappings for each protocol.
A new DNS record type, AAAA (sometime referred to as "quad-A"), has been defined for IPv6
name to address mappings (see RFC 3596). AAAA records contain a single IPv6 address mapped
to a fully qualified domain name (FQDN). The assigned value for this record type is 28 (decimal).
You will need to create AAAA records on your authoritative DNS server in order to access IPv6enabled systems using their FQDN.
In addition, a special domain rooted at “.IP6.ARPA” is defined in RFC 3596 to provide a way of
mapping an IPv6 address to a host name. This is commonly called "DNS reverse lookup", and is
specified in your authoritative DNS server’s reverse lookup files using PTR (or "pointer") records.
Please refer to the DNS documentation appropriate for your network configuration for more
information on adding IPv6 AAAA and PTR records.
164
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Network Troubleshooting Tools
There are several tools useful for troubleshooting networking configurations on Equalizer. To
simplify troubleshooting, Equalizer includes a single eqcli command (show sbr) that displays the
output of these tools.
There are other ways to view the same information in eqcli, however, the show sbr command
displays the actual running state of the system, whereas commands such as show vlan [X] subnet
[Y] show the configuration information and not necessarily the running data if there is a problem.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
165
Equalizer Administration Guide
Chapter 12
Working in the CLI
Sections in this chapter include:
Starting the CLI
Exiting the CLI
Working in the CLI
Global Parameters
Show Configuration Command
Debug Commands
Context Command Summaries
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
168
170
171
183
184
186
189
167
Working in the CLI
Starting the CLI
The Equalizer Command Line Interface, CLI, gives you complete administrative control over
Equalizer and is one of the major new features in EQ/OS 10. The GUI is also available to view and
modify the configuration, however, not all administrative options have been enabled in the GUI.
The CLI can be used over either a serial connection or an SSH connection.
Logging In to the CLI Over a Serial Connection
To start the Equalizer CLI over a serial connection:
1. Connect the supplied serial cable to Equalizer’s front panel serial port and to a properly
configured terminal or terminal emulator, as described in "Basic Configuration" on page 62.
2. Press the <Enter> key to display the login prompt:
Equalizer -- EQ/OS 10
Username:
3. Log in using an Equalizer user name and password. If this is the first time you are logging
in, use the default administrative user name and password as shown below:
Username: touch
Password: touch
Login successful.
EQ/OS 10
Copyright 2013 Fortinet, Inc.
Welcome to Equalizer!
eqcli >
See the section "Working in the CLI" on page 171 to begin familiarizing yourself with the CLI
command environment.
168
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Logging In to the CLI Over an SSH Connection
To start the Equalizer CLI over an SSH connection:
1. Ensure that SSH login is enabled for the VLAN and subnet over which you want to establish
an SSH connection.
2. Use SSH client software to open a connection with Equalizer using the enabled VLAN IP
address and port 22. Specify the login eqadmin, as shown in the example command line
below:
$ssh eqadmin@172.16.0.200
3. Upon successful SSH login, Equalizer displays the Username prompt. Enter an Equalizer login,
such as the default login, touch:
Username: touch
4. Enter the password for the user name specified in the previous step:
Password: touch
1. If the user name and password is correct, Equalizer responds with:
Login successful.
EQ/OS 10
Copyright 2015 Fortinet, Inc.
Welcome to Equalizer!
eqcli >
See "Working in the CLI" on page 171 to begin familiarizing yourself with the CLI command
environment.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
169
Working in the CLI
Exiting the CLI
You must exit the CLI from the global context prompt (eqcli >):
l
Enter exit or <ctrl-d> to exit and commit any queued changes.
l
Enter quit to exit and discard all queued changes.
If you are in a lower context, repeatedly enter one of the above commands, as appropriate, until
you exit the CLI. Once you exit the CLI, the login prompt is displayed.
170
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Working in the CLI
The Equalizer command line interface, or CLI, was developed to be an easy to use, intuitive, and
flexible command line interface. It was patterned after CLIs used in other common networking
equipment, so if you’ve used a CLI on another network device (such as a router), you should
quickly feel comfortable using eqcli.
The CLI provides a number of features that are designed to make working at the command line
easier and more effective, as described in this section.
CLI Contexts and Objects
The Equalizer CLI is a context oriented command interface. This means that the commands
available at any time (and the objects they affect) depend on the current context. The current
command context is always indicated in the CLI prompt. When you start the CLI, the command
prompt looks like this:
eqcli >
This indicates that you are in the global context -- all commands available in the CLI for all objects
can be executed from this context, and you can also set parameters for global services (such as
NTP, DNS, etc.). You can also change to other contexts, whose scope is limited to a specific
object. For example, you can enter the cluster specific context for a cluster named cl01 by typing:
eqcli > cluster cl01
eqcli cl-cl01>
The prompt above indicates that the cluster specific context for cl01 is the current context. In this
context, the only commands available are those that affect cluster cl01.
Note that only the first 4 characters of an object name appear in the eqcli prompt. For example, if
you have a cluster named mycluster, then you would enter the cluster specific context for this
cluster by typing:
eqcli > cluster mycluster
eqcli cl-myc*>
The asterisk (*) in the prompt indicates that there are more than 4 characters in the cluster
name. To display the complete object name in any context, use the context command:
eqcli cl-myc*> context
The current context is: ‘mycluster’
eqcli cl-myc*>
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
171
Working in the CLI
In each context, you can perform operations on the objects and parameters that exist in that
context (e.g., create, delete, modify, display, set). When you change to another context, the eqcli
prompt changes to include the suffix indicated in the chart above for each context. For example,
when you change to the server context, the eqcli prompt changes from “eqcli >” to “eqcli
sv>”.
Within each context shown above, you can also type in the name of an object (existing or new) to
enter an object specific context that will allow you to edit only that object’s settings.
So, for example, you can start eqcli and type server to change to the server context -- as indicated
by the prompt, which changes to “eqcli sv>”. Now, you can use the list command to list all the
existing servers. If you then type in the name of one of the existing servers while in the server
context, you will enter the server specific context for that existing server -- the prompt changes
to “eqcli sv-server_name>” to indicate that you are in the server specific context for the
server with the name server_name. You could also do this directly from the global context by
typing:
eqcli > show server
eqcli > sv-server_name show
Note that the eqcli prompt reserves only four characters for object names. So, for example, if you
have a server named sv02, the entire server name will be displayed in the prompt, as shown in
this example:
eqcli > server sv02
eqcli sv-sv02>
If the object name is longer than four characters, eqcli displays the first three characters and an
asterisk (*) to show that the name is longer than four characters. For example, if you have a
server named Server2, the prompt will look as follows when you change to the Server2 specific
context:
eqcli > server Server2
eqcli sv-Ser*>
The complete current context can always be displayed using the context command, as in this
example:
eqcli > server Server2
eqcli sv-Ser*> context
The current context is: Server2
eqcli sv-Ser*>
172
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Object Relationships
Most contexts in the CLI correspond to an Equalizer object -- servers, server instances, server pools,
clusters, match rules, responders, CRLs, certificates. The following diagram shows the relationships
among these objects.
On Equalizer, a server corresponds to a real server hosting an application behind Equalizer. Each
server has an IP address that Equalizer uses to send client requests to the server. This IP address
is sometimes called a “real IP” because it corresponds to a real server.
A server must be assigned to a server pool before it can be associated with a cluster. When you
assign a server to a server pool, you create a server instance of that server in the server pool. The
server instance definition specifies operating parameters for the real server that are effective
only within that server pool. This allows you the flexibility to associate a single physical server
with multiple server pools, and set different server instance options within each server pool.
A server pool in turn is assigned to a cluster. Client requests are sent to a cluster IP address (often
called a “virtual IP”) assigned to Equalizer and then routed to the server pool instance selected by
the load balancing algorithm and other options. In all clusters, a server pool is assigned directly to
the cluster. For Layer 7 clusters, additional alternate server pools, as well as other objects and
options, can be assigned to one or more match rules.
A match rule is processed before cluster settings are processed, and behaves like an if-then
statement: if a client request’s content matches the conditional expression set in the match rule,
then the options and objects specified in the match rule are used. If the expression in the match
rule is not matched by the client request, then the next match rule is processed. If all match rules
defined in the cluster are processed and none of them match the incoming request, then the
objects and options set on the cluster are used to process the request.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
173
Working in the CLI
The objects that can be selected by match rules include server pools, responders (used when no
servers in a server pool are available), SSL certificates, and certificate revocation lists (CRLs).
Many cluster options can also be specified in a match rule, including persistence settings and load
balancing policy.
Supported operations on all objects are explained in "Context Command Summaries" on page
189.
Command Line Editing
Use the key sequences below to edit the current command line
ctrl–a
ctrl–e
ctrl–b
ctrl–f
esc–b
esc–f
Move the cursor to the beginning of the line
Move the cursor to the end of the line
Move the cursor one character to the left
Move the cursor one character to the right
Move the cursor one word to the left (also left arrow)
Move the cursor one word to the right (also right arrow)
ctrl–h
ctrl-k
esc-d
Delete the character to the left of the cursor
Delete all characters from the cursor to the end of the line
Delete the word to the right of the cursor
Delete the entire line
ctrl-u
ctrl-y
Inserts previously deleted text starting at the cursor
ctrl-t
Transpose the character under the cursor and the character to the left of the cursor
ctrl-l
Redraw the line
ctrl–n
Display next command from history (also up arrow)
Display last command from history (also down arrow)
ctrl–p
174
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Entering Names for Equalizer Objects
Equalizer identifies administrative objects, such as clusters and servers, by name. The characters
used in names are limited to standard ASCII letters ("A" through "Z" and "a" through "z"),
numbers (0 through 9), and the characters "." (period), "-" (dash) and "_" (underscore), (*)
asterisk, (@) "at" sign, and (/) backslash.
l
The first character in a name must be a letter.
l
Names can be at most 65 characters long.
l
The readability of lists presented in the interface is increased by using short names that use
as many unique characters at the beginning of the name as possible.
Using White Space in a Command Line
The CLI uses white space (i.e., one or more tab or space characters) as a delimiter between
command line elements. To include spaces within a command line element (such as a string, a list
of objects, or multiple flags), the entire element must be contained in double quotes. For
example, this command line uses a space between the two server instances and two flags
specified:
eqcli > srvpool sp01 si “sv01, sv02” flags “hot_spare, quiesce”
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
175
Working in the CLI
Enabling and Disabling Flags
Most objects have a flags keyword that is followed by one or more keywords that enable and
disable particular object behavior. A single flag is specified as in this example:
eqcli> srvpool sp01 si sv01 flags hot_spare
Multiple flags in a command line can be separated using either a comma (,) or a vertical bar (| )
between each flag. For example, all the following commands turn on the hot_spare and quiesce flags
on a server instance:
eqcli>
eqcli>
eqcli>
eqcli>
srvpool
srvpool
srvpool
srvpool
sp01
sp01
sp01
sp01
si
si
si
si
sv01
sv01
sv01
sv01
flags
flags
flags
flags
hot_spare,quiesce
“hot_spare, quiesce”
hot_spare|quiesce
“hot_spare | quiesce”
Flags are disabled using the negate operator (the exclamation point character):
! Negates (turns off) the option that immediately follows it. No spaces are allowed between the
negation operator and the option that follows.
For example, the following command disables the hot_spare option and quiesce options:
eqcli> srvpool sp01 si sv01 flags !hot_spare,!quiesce
A flag can be enabled and disabled in the object specific context or from any higher context. For
example, you can type any of the following three command sequences to disable the spoof option
on match rule ma00 in cluster cl00:
eqcli
eqcli
eqcli
eqcli
eqcli
176
> cluster cl00 match ma00
cl-cl00-match-ma00> flags !spoof# match rule specific context
> cluster cl00
cl-cl00> match ma00 flags !spoof# cluster context
> cluster cl00 match ma00 flags !spoof # global context
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Command Abbreviation and Completion
You do not need to type an entire command name in order to execute a command. If you type
enough characters to uniquely identify a command and then type a <space> or <tab> character,
eqcli will automatically display the remainder of the command name.
For example, if in the global context you type cert and then press the space bar:
eqcli > cert<space>
The CLI fills in the rest of the command line for you, followed by a space:
eqcli > certificate<space>
This also works with multiple keywords on the same command line. So, for example, you can type
the following:
eqcli > sh<space>cl<space>
And the CLI will expand this to:
eqcli > show<space>cluster<space>
If the string that you type before pressing <space> or <tab> does not uniquely identify a
command, then the CLI displays a list of all the commands that match the string you entered, and
then re-displays the string that you typed. For example:
eqcli > c<space>
certificate cluster context crl
eqcli > c
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
177
Working in the CLI
Detection of Invalid Commands and Arguments
Invalid commands and invalid arguments for specific commands are detected before they are
committed and appropriate error messages are displayed.
Specifying Multiple Server Instances
When specifying server instances on the command line, the user can specify either a single object
or a comma separated list of objects. For example, to create server instances of two servers (sv01
and sv02) in an existing server pool (sp01), you could enter:
eqcli> srvpool sp01 si sv01,sv02
eqcli sp-sp01-si-sv01*>
When you enter multiple server instances as in the command above, eqcli enters a special
combined context that applies commands to all of the specified objects. For example, after
entering the example command above, eqcli enters the “sv01,sv02” context and the CLI prompt
changes to include the first four letters of the combined context, “sv01*”. To display the full
current context, use the following command:
eqcli sp-sp01-si-sv01*> context
The current context is: 'sv01,sv02'
eqcli sp-sp01-si-sv01*>
178
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the no Form of a Command
Most commands that create objects and set parameters have a no form that you can use to delete
an object or reset a parameter to its default value. The general format of the no command is:
no [keywords] {object|parameter}
The no keyword must be followed by a complete object context that specifies the object to delete
or the parameter to reset:
l
l
If the object or parameter is defined in the current context, then you do not need to specify
any keywords.
If the object or parameter is defined in a lower level context, then specify the appropriate
contexts before the object or parameter name.
So, for example, type the following to delete cluster cl00:
eqcli > no cluster cl00
For objects and parameters that have lower object contexts (i.e., match rules, server instances,
and subnets), you can use the no form at either the global context or in the lower object specific
context:
eqcli > no cluster cl00 match ma00
eqcli > cluster cl00
eqcli cl-cl00> no match ma00
For parameters, the no form requires the complete command used to set the parameter, minus
the argument setting the value. So, for example, to reset the value of the resp (responder)
parameter on match rule ma00 in cluster cl00, you can type any of the following:
eqcli
eqcli
eqcli
eqcli
eqcli
> no cluster cl00 match ma00 resp
> cluster cl00
cl-cl00> no match ma00 resp
> cluster cl00 match ma00
cl-cl00-ma-ma00> no resp
The operation specified by the no form of a command takes effect immediately, even in explicit
commit mode. In other words, a no command form never needs to be followed by a commit , exit , or
<ctrl-d> command; it is committed to the configuration file immediately.
In all cases, the no form of a command always returns to the current context after completion.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
179
Working in the CLI
Queued Commands
CLI commands that specify changes to the current configuration will either be committed to the
configuration file as soon as they are entered, or queued to be committed using the commit , exit , or
<ctrl-d> commands.
l
If a complete command is executed for an object in a lower context, the command is
committed to the configuration immediately. The current command context is not changed
after the command is entered. A “complete” command is one that specifies all parameters
required to add or modify the object.
For example, entering the following command to create a server creates the server immediately,
and leaves eqcli in the global context:
eqcli > server sv01 proto tcp ip 192.168.0.210 port 80
eqcli: 12000287: Operation successful
eqcli >
l
If an incomplete command is executed for an object in a lower context, the command is
queued to be committed to the configuration until a commit , exit , or <ctrl-d> command is
entered. The current command context changes to the context of the object argument of the
incomplete command. An “incomplete" command is one does not include one or more
parameters required to add or modify the object.
For example, if the server sv01 does not exist, entering the following server command in the global
context queues the command and leaves eqcli in the relevant context:
eqcli > server sv01
eqcli sv-sv01>
l
If a command is entered that affects only the object associated with the current context, the
command is queued to be committed to the configuration until a commit , exit , or <ctrl-d>
command is entered. The current command context does not change.
For example, if sv01 exists and the current context is “sv-sv01”, then the following commands are
queued until a commit , exit , or <ctrl-d> command is entered:
eqcli
eqcli
eqcli
eqcli
180
> server
sv-sv01>
sv-sv01>
sv-sv01>
sv01
ip 192.168.0.211
port 8080
commit
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Queued commands can be committed or discarded using the following commands:
l
commit - Commits all queued commands; does not change the current context.
l
exit <ctrl-d> - Commits all queued commands and changes to the next highest context in the
hierarchy (if executed in the global context, either of these commands exits eqcli).
l
discard -Discards all queued commands; does not change the current context.
l
quit -Discards all queued commands and changes to the next highest context in the hierarchy
(if executed in the global context, this command exits eqcli).
Note that the following commands always take effect immediately and do not change the current
command context:
l
A command that sets a global parameter (see Global Commands).
l
The no form of a command (see Using the "no" Form of a Command.
l
The show command in any context.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
181
Working in the CLI
Context Help
You can type <?> in a number of situations to display context help:
l
If you type <?> at the CLI prompt, a list of commands that are valid in the current context is
displayed. For example, this command displays help for all global commands as shown in
"Global Commands" on page 190:
eqcli >?
Entering the following two commands displays help for all the commands available in the cluster
cl01 specific context, as shown in "Cluster and Match Rule Commands" on page 198.
eqcli > cluster cl01
eqcli cl-cl01>?
l
If you type the complete name of a command that is valid in the current context and type
<?>, context help for that command is displayed. For example:
eqcli > cluster cl01
eqcli cl-cl01> clientto?
clientto: Set the client timeout for this cluster.
Syntax: cluster <cluster name> clientto <value>
Warning: Only valid for proto http or https.
l
If you type a partial command name and type <?>:
If there is only one command that matches the string entered, context help for that command is
displayed.
If there are multiple commands that begin with the string entered, the names of all the matching
commands are displayed.
182
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Global Parameters
Global or System Parameters include Probes and Networking. Most clusters will work with the
default values on these tabs. To view or modify the default global parameter values:
1. Start the Equalizer CLI and log in.
2. Enter the following:
eqcli > show
The following will summary will be displayed that shows the global parameters that
are configured on Equalizer. Refer to "Global Commands" on page 190 for descriptions
of each parameter.
eqcli > show
Variable
Value
icmp_interval
icmp_maxtries
icmp_relax_probe
hostname
date
timezone
locale
global services
15
3
disabled
NAME
Mon Jun 17 18:15:40 UTC 2013
UTC
en
http, https, ssh, snmp, Envoy,
Envoy_agent
None
pool.ntp.org - Unavailable: name-server undefined
None
Enabled
Enabled
Fortinet, Inc.
Equalizer Image A Version 10.2.1b (Build 23796)
Equalizer Image A SB/OS-10
name-servers
ntp-server
syslog-server
alerts
extended audit
GUI logo
boot image
boot image
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
183
Working in the CLI
Show Configuration Command
The show configuration command can be used to display all current configuration data from the
CLI. Enter the following. The display shown is an abridged version of an actual output:
eqcli > show config
sequence = 60
locale = "en"
watchdog = 30
version = 3
extended_audit = true
customer {
sequence = "0"
# last_refresh_date = ""
# support_email = ""
# support_enddate = ""
# hw_support_level = ""
# fw_support_enddate = ""
# fw_support_level = ""
# en_support_enddate = ""
# en_support_level = ""
}
}
ntp {
sequence = "0"
enable = true
server = "pool.ntp.org"
}
syslog {
sequence = "0"
enable = false
# server = ""
}
alerts {
sequence = "0"
enable = true
}
services {
sequence = "0"
http = true
https = true
ssh = true
snmp = true
envoy = true
envoy_agent = true
fo_http = true
fo_https = true
184
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
fo_ssh = true
fo_snmp = true
fo_envoy = true
fo_envoy_agent = true
}
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
185
Working in the CLI
Debug Commands
The debug mode can display hidden commands for the following functions and can be accessed
using the CLI only. You can access it when booting your appliance and entering CTRL+C when
prompted for a username. The following commands are available.
Debug Commands
debug > boot image
: Set the EQ/OS image (A or B) to use at next boot.
debug > exit
: Halt the system.
debug > halt
: Halt the system.
debug > help
: Displays this text.
debug > login
: Log in as a system user using stored passwords.
debug > nodog
: Disable system watchdog timer for current boot.
debug > reboot
: Reboot the system.
debug > reset config
: Reset the configuration to factory defaults.
debug > reset forsupport
: Reset the configuration to factory defaults.
Keeps core files and files that are currently in
the file store. A backup file is also generated
and stored in the file store.
debug > reset keeplicense
: Reset the configuration to factory defaults and
retain the license data in the configuration.
debug > reset passwd
: Reset the 'touch' user password.
debug > shell
: Obtain non-privileged shell access. Requires onetime password from Support.
debug > shell admin
: Obtain privileged shell access.
debug > show boot
: Display the available EQ/OS boot images.
debug > version
: Displays the running system version information.
186
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Resetting Your Password
You can reset your password to the default by entering the following when your unit is rebooting:
1. Enter CTRL+C when prompted for a username. This will enter the debug mode.
2. Enter the following:
debug > reset passwd
Reset password successful.
debug >
3. Enter exit to return to eqcli login prompt.
Note - The "reset passwd" command may fail with the following error message:
cli_reset_passwd: 68400010: Could not complete 'get user' request.:
Connection refused
Unable to reset 'touch' password.
This indicates that the configuration management daemon is not available to process the command. If successive
attempts to run this command fail with the above error message, contact technical support.
Resetting the Configuration
This command resets Equalizer configuration to a factory installed condition. All VLANs, subnets,
clusters, servers, SSL certificates, and other user-supplied objects and settings will be removed.
After the configuration has been reset, the system will be rebooted. 1. Enter CTRL+C when prompted for a username. This will enter the debug mode.
2. Enter the following:
debug > reset config
WARNING! This command resets the Equalizer configuration to a
factory installed condition. All VLANs, subnets, clusters, servers,
SSL certificates, and other user-supplied objects and settings will
be removed. After the configuration has been reset, the system will
be rebooted. Do you want to continue (Y/N)?
3. Select Y or N.
4. Enter exit to return to eqcli login prompt.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
187
Working in the CLI
Using the reset keep-filestore Command
This command resets Equalizer configuration to a factory installed condition. All VLANs, subnets,
clusters, servers, SSL certificates, and other user-supplied objects and settings will be removed.
After the configuration has been reset, the system will be rebooted. This command saves all of the files that are currently in the files store as well as the core files. A
backup file will be generated and may be removed if necessary.
1. Enter CTRL+C when prompted for a username. This will enter the debug mode.
2. Enter the following:
eqcli hidden reset keep-filestore
WARNING! This command resets the Equalizer configuration to a
factory installed condition. All VLANs, subnets, clusters, servers,
SSL certificates, and other user-supplied objects and settings will
be removed. After the configuration has been reset, the system will
be rebooted. Do you want to continue (Y/N)?
3. Select Y or N.
4. Enter exit to return to eqcli login prompt.
188
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Context Command Summaries
This section contains a table for each CLI context that summarizes all the commands that can be
executed in each context. The following typographical conventions are used when describing
command syntax and usage.
eqcli>
Regular constant width type is used for the eqcli
eqcli> vlan list
Bold constant width type is used for commands you type.
command prompt and messages.
Bold italic constant width type is used for command
eqcli> vlan vlname show
elements that you must specify, such as an object name or a parameter
value.
{option | option...}
A series of elements in braces (“{“, “}”), separated by vertical bars (“|”),
means you must choose one of the options between the braces. The braces
are not typed on the command line.
{option,option...}
A series of elements in braces (“{“, “}”), separated by commas (“,”),
means you may chose more than one of the options between the braces.
Separate multiple options on the command line using either commas or
vertical bars. If you use white space in the string of options, the entire
string must be surrounded by quotes. The braces are not typed on the
command line.
[option]
Square brackets (“[“, “]”) indicate optional command elements. The
brackets are not specified on the command line.
eqcli vlan> *ip ip_addr
An asterisk (*) before a parameter indicates that the parameter must be set
before the associated object can be created.
# Text in the right margin
Text in italic font following the pound character (#) in the right margin is a
comment indicating the purpose of the command and should not be typed
onto the command line. Details appear in notes following each table.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
189
Working in the CLI
Global Commands
The table below lists the global configuration commands that are available in the global context of
the CLI. These commands allow you to:
l
Configure, enable, and disable settings such as hostname, NTP, and DNS.
l
Perform system operations, such as upgrading and rebooting.
Global Commands
eqcli > alerts
: Global Enable/Disable alerts.
eqcli > agr
: Add or modify an AGR or interface
instance.
eqcli > backup
: Upload a system backup to remote FTP.
eqcli > boot
: Set the OS image (A or B) to use on at
next boot.
eqcli > certificate
: Add or modify an SSL certificate.
eqcli > cluster
: Add or modify a cluster or a match rule.
eqcli > context
: Display the current command context.
eqcli > crl
: Add or modify a Certificate Revocation
List (CRL).
eqcli > date
: Set the system time.
Date [[[[[CC]yy]mm]dd]HH]MM[.SS], where
cc = century;
yy = last two digits of the current
year (e.g., 11, 12, etc.);
mm = the number of the month, specified
as two digits;
dd = the number of the day, specified
as two digits;
HH = the hour on which to filter, in
two digits;
MM = the minutes on which to filter, in
two digits; required.
ss = the number of seconds.
eqcli > diags
: Run the system utilities commands in the
'diags' context.
eqcli > edit
: Edit a file in the datastore.
eqcli > ext_services
: Add or modify a mail server in the 'ext_
services' context.
eqcli > exit
: Commit all pending configuration changes
and exit eqcli.
eqcli > extended_services
: Add or modify a mail server in the 'ext_
services' context.
eqcli > extended_audit
: Enable or disable extended audit logging.
eqcli > failover
: Enter 'failover' context.
190
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Global Commands
eqcli > files download
: Download a file onto the Equalizer. <url>
:= url of file to download.
eqcli > files edit
: Edit a datastore file.
eqcli > files ftp
: file is the file name. server - url of
the FTP server onto which the file should
be copied. ftp://[username:password@]
hostname[/path]/
eqcli > firewall
: Enter firewall conext.
eqcli > forticare registration
: Load the Forticare registration
information.
eqcli > geocluster name parameter
value
: Add or modify a GeoCluster or a GeoSite
instance.
eqcli > geosite name parameter
value
: Add or modify a GeoSite.
eqcli > guilogo
: Change the GUI logo of the Equalizer.
eqcli > halt
: Shutdown Equalizer.
eqcli > health_check
: Change to the command context for the
specified health check.
eqcli > hostname
: Set the system hostname.
eqcli > illb-grp
: Add or modify the illb group.
eqcli > llb-gw
: Add or modify the llb gateway.
eqcli > ollb-grp
: Add or modify the ollb group.
eqcli > interface
: Modify an interface.
eqcli > license upload
: Load an upgrade image.
eqcli > locale
: Set the locale of the system.
<locale> := en | ja
'en' - to set English locale
'ja' - to set Japanese locale
eqcli > name-server
: Add a DNS name server entry. One IP
address can be specified on the command
line. A total of 3 IP addresses can be
added. DNS is enabled as long as there is
one entry in the list.
primary : Add a primary name-server
secondary: Add a secondary name-server
tertiary : Add a tertiary name-server
eqcli > no
: Reset a parameter or delete an object.
eqcli > ntp
: Enable or disable NTP (without changing
the NTP configuration).
eqcli > ntp-server
: Set the NTP server name.
eqcli > peer
: Add or modify a failover peer.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
191
Working in the CLI
Global Commands
eqcli > ping
: Send ICMP or ICMPv6 ECHO_REQUEST packets
to a host.
eqcli > quit
: Discards the entered configuration
changes and exits eqcli.
eqcli > rebalance
: Rebalance clusters among failover group
members. Each cluster will be re-started
on its 'preferred peer'.
eqcli > reboot
: Reboot Equalizer.
eqcli > remote-mgmt
: Set the remote management options.
eqcli > resize
: Set the terminal size to the current
window size.
eqcli > resp
: Add or modify responders.
eqcli > restore
: Restore a system backup from remote FTP.
eqcli > run_script
: Run an eqcli command script.
eqcli > server
: Add or modify a server.
eqcli > services
[!]http,[!]https,
{!]ssh,[!]snmp
: Set the default GUI and SSH access. These
settings apply if ‘services' is not set
in a VLAN configuration.
eqcli > show
: Display configuration information. With
no arguments, displays global parameters.
Otherwise, displays either a list of all
objects of one type (for example,
'cluster', 'srvpool', 'vlan') or the
configuration of a specific object.
eqcli > smart_control
: Add or modify a Smart Control.
eqcli > snmp
: Add SNMP parameters.
eqcli > srvpool
: Add or modify a server pool.
eqcli > sse
: Modify global server-side encryption
parameters.
eqcli > stats
: Display global statistics.
eqcli > syslog
: Enable or disable remote logging.
eqcli > syslog-server
: Set the syslog server IP address
eqcli > timezone
: Set the system timezone.
eqcli > traceroute
: Trace the network path to a host using
UDP packets.
eqcli > tunnel
: Set the tunnel.
eqcli > upgrade
: Load an upgrade image.
eqcli > user
: Create or modify a user object.
192
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Global Commands
eqcli > version
: Show detailed system and version
information.
eqcli > vlan
: Add or modify a VLAN or subnet.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
193
Working in the CLI
Certificate Commands
Each SSL certificate installed on Equalizer has a CLI context that provides commands for
managing the certificate and its associated private key. Certificates, private keys, and CRLs (see
the following section) are used by Equalizer to provide SSL offloading for HTTPS clusters.
In SSL offloading, Equalizer terminates the SSL connection with the client, decrypts the client
request using a certificate and key, sends the request on to the appropriate server, and encrypts
the server response before forwarding it on to the client.
Certificates are uploaded to Equalizer and then associated with one or more clusters. Two types of
certificates may be used to authenticate HTTPS cluster connections:
l
l
A cluster certificate is required to authenticate the cluster to the client and to decrypt the
client request (these are also called server certificates). For cluster certificates, both a
certificate file and a private key file must be uploaded to Equalizer.
A cluster may also be configured to ask for, or require, a client certificate -- a certificate
used to authenticate the client to Equalizer. For client certificates, only a certificate file is
uploaded to Equalizer(no keyfile is used).
Supported certificate commands are shown in the following tables.
Using Certificate Commands in Global Context
eqcli > certificate certname [cmd ...]
: Create certname (req_cmds = *
commands below)
eqcli > certificate certname cmd ...
: Modify certname (cmd = any commands
below)
eqcli > no certificate certname
: Delete certname
eqcli > show certificate [certname]
: Display all certificates or
certname
eqcli > certificate certname
: Change to "cert-certname" context
(see below)
194
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Certificate Commands in Certificate Context
eqcli cert-certname> certfile
{edit|url}
: Upload SSL certificate
edit ::= invokes an editor to enter
the certificate content.
url ::= fetches the certificate
from the specified URL, which must
point to a file on a FTP or HTTP
server.
Example:
certfile edit
certfile
ftp://[<username>[:<password>]@]
www.example.com/certfile.pem
certfile
http://www.example.com/certfile.pem
eqcli cert-certname> genscr
: Create a CSR.
eqcli cert-certname> keyfile {edit|url}
: Upload private key
edit ::= invokes an editor to enter
the private key content.
url ::= fetches the private key
from the specified URL, which must
point to a file on a FTP or HTTP
server.
Example:
keyfile edit
keyfile
ftp://[<username>[:<password>]@]
www.example.com/keyfile.pem
keyfile
http://www.example.com/keyfile.pem
eqcli cert-certname> show
: Display the certificate
configuration.
eqcli cert-certname> signcsr
{days|force}
: Create a self-signed certificate.
days ::= State name (SN) for the
CSR.
force ::= Force overwrite of
existing self-signed certificate.
The arguments to the certfile and keyfile commands are:
edit - Launch an editor to supply the content of the certificate or key file.
url - Download the certificate or key file using ftp:// or http:// protocol.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
195
Working in the CLI
Using Certificate Commands in CSR Context
Using Certificate Commands in CSR Context
eqcli cert-certname-csr > common
: Common Name (CN) for the CSR
(Required).
eqcli cert-certname-csr > country
: Country name (C) for the CSR
(Default is 'US').
eqcli cert-certname-csr > force
: Force overwrite of existing
CSR.
eqcli cert-certname-csr > keylen
: The length for the generated
private key (Default is 2048).
eqcli cert-certname-csr > locality
: Locality (L) for the CSR.
eqcli cert-certname-csr > method
Encryption method to be used
for the private key (Default
is 'rsa').
eqcli cert-certname-csr > org
Organization (O) for the CSR.
eqcli cert-certname-csr > orgunit
Organizational Unit (OU) for
the CSR.
eqcli cert-certname-csr > state
State name (SN) for the CSR.
196
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Certificate Revocation List Commands
The crl context provides commands for managing Certificate Revocation Lists (or CRLs). CRLs can
be used to verify that the certificates used by Equalizer are valid and have not been compromised.
A CRL is uploaded to Equalizer using commands in the crl context, and then associated with one or
more clusters in the cluster specific context. Whenever a certificate is used to authenticate a
connection to the cluster, the CRL is checked to make sure the certificate being used has not been
revoked. The supported commands in the crl context are shown in the following tables.
Note - If a CRL attached to a cluster was generated by a Certificate Authority (CA) different from the CA used to
generate a client certificate presented when connecting to the cluster, an error occurs. The CRL and client certificate
must be signed by the same CA.
Using CRL Commands in the Global Context
eqcli > certificate certname [cmd ...]
: Create certname (req_cmds = *
commands below)
eqcli > certificate certname cmd ...
: Modify certname (cmd = any
commands below)
eqcli > no certificate certname
: Delete certname
eqcli > show certificate [certname]
: Display all certificates or
certname
eqcli > certificate certname
: Change to "cert-certname"
context (see below)
Using CRL Commands in a CRL specific Context
eqcli crl-crlname> crlfile {edit|url}
: Upload the CRL
eqcli crl-crlname> show
: Display CRL crlname
The arguments to the crlfile command are:
l
edit - Launch an editor to supply the content of the CRL file.
l
url - Download the CRL file from the ftp:// or http:// protocol URL supplied on the command line.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
197
Working in the CLI
Cluster and Match Rule Commands
Each cluster has its own context and the settings available in the cluster’s context depends on the
cluster’s proto parameter -- this parameter must be specified first on the command line when
creating a cluster. A Layer 7 cluster may have one or more match rules associated with it, each
with its own context. Cluster and match rule commands are summarized in the tables below.
Using Cluster Commands in the Global Context
eqcli > cluster clname req_cmds
: Create clname (req_cmds = * commands
below)
eqcli > cluster clname cmds ...
: Modify clname (cmds = any commands
below)
eqcli > no cluster clname
: Delete clname
eqcli > show cluster [clname]
: Display all clusters or clname
eqcli > cluster clname
: Change to the "cl-clname" context(see
below)
Using Cluster Commands in a Cluster Specific Context
For all Clusters:
eqcli cl-clname> *ip ip_addr
: Cluster IP address
eqcli cl-clname> *proto
{http|https|tcp|udp}
: Protocol -- MUST SET proto
FIRST
eqcli cl-clname> *port integer
: Cluster port
eqcli cl-clname> show
: Show the cluster
configuration
eqcli cl-clname> stats
: Display cluster statistics
For Layer 7Clusters:
eqcli cl-clname> age integer
: Cookie age in seconds (0
[default] to 31536000 -- one
year)
eqcli cl-clname> clientto integer
: Client connection timeout
eqcli cl-clname> compress_min
integer
: Set the minimum file size
for compression in bytes
when compression is enabled
for Layer HTTP and HTTPS
clusters. Valid values range
from 0 to 1073741824 bytes.
The default is 1024 bytes.
eqcli cl-clname> compress_types
string
: Mime types to compress
eqcli cl-clname> connto integer
: Server connection timeout
198
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Cluster Commands in a Cluster Specific Context
eqcli cl-clname> custhdr string
: Custom request header
eqcli cl-clname> domain string
: Cookie domain
eqcli cl-clname> flags
: Disable and enable flags
For Layer 7 Http Clusters:
{[!]always,[!]compress,
[!]disable,[!}allow_utf8
[!]ignore_case,[!]insert_client_ip,
[!]no_header_rewrite, [!]once_only,
[!]spoof,[!]tcp_mux}
For Layer 7 https clusters:
{[!]ics,[!]allow_sslv3,
[!]push_client_cert,
[!]require_client_cert,[!]rewrite_redirects,
[!]strict_crl_chain,[!]ignore_critical_extns,
[!]software_ssl_only,[!]allow_tls10,
[!]allow_tls11 [!]allow tls12}
eqcli cl-clname> gen integer
: Cookie generation (0 to
65535).
eqcli cl-clname > hdredit
edit|url
: Set the header edit
expression for a cluster.
<mode> ::= edit | <url>
edit ::= invokes an editor
to enter the desired header
edit script.
url ::= fetches the header
edit script from the entered
fully qualified ftp/http
site or from the file store
with the path to the header
edit script file starting
with 'file://'.
Note: Only valid when
cluster 'proto' = 'http' or
'https'.
eqcli cl-clname> match maname
: Change to the maname match
context
eqcli cl-clname> match cmds
: Execute match commands
eqcli cl-clname> no match maname
: Delete match maname
eqcli cl-clname> no
{age|clientto|connto
|custhdr|domain
|gen|path|resp|scheme
|serverto|srvpool}
: Reset the specified
parameter
eqcli cl-clname> path string
: Cookie path
eqcli cl-clname> range
: Set the cluster port range.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
199
Working in the CLI
Using Cluster Commands in a Cluster Specific Context
eqcli cl-clname> resp rname
: Responder name
eqcli cl-clname> scheme integer
: Cookie scheme (0,1,2)
eqcli cl-clname> serverto integer
: Server response timeout
eqcli cl-clname> sni sni-name
: Server Name Indication name
eqcli cl-clname> sni-name sni_
svname servername
: Add the server name or list
of server names in sni.
eqcli cl-clname> srvpool spname
: Server pool name
eqcli cl-clname> stats
: Display the statistics for
cluster
eqcli cl-clname> staleto
: Set the stale timeout for a
cluster.
eqcli cl-clname> stickyto
: Set the sticky timeout for a
cluster.
eqcli cl-clname> stickynetmask
: Set the sticky netmask for a
cluster.
eqcli cl-clname> cipherspec
{url|edit|enter}
: Set the cipherspec for an
HTTPS cluster.
eqcli cl-clname> clientca
certname
: Attach a client certificate
to an HTTPS cluster.
eqcli cl-clname> clflags
{[!]allow_sslv2,[!]allow_sslv3,
[!]push_client_cert,[!]require_client_cert,
[!]strict_crl_chain}
eqcli cl-clname> crl crlname
eqcli cl-clname> no
{cert|cipherspec
|clientca|crl|valdepth}
: Reset the parameter to its
default value
eqcli cl-clname> valdepth}
: Set validation depth for
cluster.
eqcli cl-clname> preferred_peer
: Set the preferred peer
eqcli cl-clname> persist type
: Set the persist type
{[!]none,[!]source_ip,
[!]Coyote_cookie_0,
[!]Coyote_cookie_1,
!]Coyote_cookie_2
For Layer 7 TCP Clusters (proto = tcp):
eqcli cl-clname> flags
{[!]disable,[!]spoof,
[!]delayed_binding,[!]abort_server,
[!]ics
200
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Cluster Commands in a Cluster Specific Context
eqcli cl-clname> stickyto
: Set the sticky timeout for a
cluster.
eqcli cl-clname> stickynetmask
: Set the sticky netmask for a
cluster.
eqcli cl-clname> srvpool spname
: Server pool name
eqcli cl-clname> preferred_peer
: Set the preferred peer
eqcli cl-clname> clientto integer
: Client connection timeout
eqcli cl-clname> serverto integer
: Server response timeout
eqcli cl-clname> connto integer
: Server connection timeout
For Layer 4 Clusters (proto = tcp or udp):
eqcli cl-clname> eqcli cl-clname>
flags
{[!]dsr,[!]ics!]spoof,
[!]disable}
eqcli cl-clname> idleto value_in_
seconds
: Set the connection idle
timeout
eqcli cl-clname> no idleto
: Reset specified parameter to
default value
eqcli cl-clname> range value
: Upper limit of port range
eqcli cl-clname> stickyto value_
in_seconds
: Set the connection sticky
timeout
eqcli cl-clname> stickynetmask
: Set the sticky netmask for a
cluster.
Note - Match Rules are not supported on E250GX model Equalizers.
Using Match Rule Commands in the Global Context
eqcli > cluster clname match maname req_cmds
: Create maname (req_cmds = *
commands below)
eqcli > cluster clname match maname cmd ...
: Modify maname (cmds = any
commands below)
eqcli > no cluster clname match maname
: Delete match rule maname
eqcli > show cluster [clname]
: isplay all match rules or
maname
eqcli > cluster clname match maname
: Change context to a match rule
context
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
201
Working in the CLI
Using Match Rule Commands in a Match Rule Specific Context
eqcli cl-clname-ma-maname>
{disable|enable}
: Disable match rule
eqcli cl-clname-ma-maname> age integer
: Cookie age in seconds (0 to
31536000 -- one year)
eqcli cl-clname-ma-maname> compress_min
integer
: Minimum bytes to compress (0 to
1073741824 -- default 1024)
eqcli cl-clname-ma-maname> compress_types
string
: Mime types to compress
eqcli cl-clname-ma-maname> domain string
: Cookie domain
eqcli cl-clname-ma-maname> expression
string
: Match expression
eqcli cl-clname-ma-maname> flags
: Enable/disable Flags
[!]abort_server,[!]always,
[!]client_ip,[!]compress,
[!]ignore_case,[!]no_header_rewrite,
[!]once_only,[!]persist,
[!]spoof,[!]tcp_mux}
:
eqcli cl-clname-ma-maname> gen integer
: Cookie generation (0 to 65535)
eqcli cl-clname-ma-maname> hredit
{edit|url}
: Set the match rule header edit
expression.
edit ::= invokes an editor to
enter the desired header edit
script.
url ::= fetches the header edit
script from the entered fully
qualified ftp/http site or from
the file store with the path to
the header edit script file
starting with 'file://'.
eqcli cl-clname-ma-maname> *nextmatch
maname
: Next match in list
eqcli cl-clname-ma-maname> no
{age|domain|expression|gen
|path|resp|scheme|srvpool}
: Reset parameter
eqcli cl-clname-ma-maname> path string
: Cookie path
eqcli cl-clname-ma-maname> resp rname
: Set Responder name
eqcli cl-clname-ma-maname> scheme integer
: Cookie scheme (0, 1, 2)
eqcli cl-clname-ma-maname> show
: Show configuration
eqcli cl-clname-ma-maname> srvpool spname
: Server Pool name
eqcli cl-clname-ma-maname> stats
: Display statistics
202
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Header Editing Rules in Cluster or Match Rule Specific Context
Header edit commands can be used in either Cluster or Match Rule context, depending whether
you’ve applied header editing rules on whether the client request is selected by a cluster or match
rule. Refer to "Header Editing" on page 1016 for details.
The commands below are shown on match rule specific context.
Using Header Editing Rules in Cluster or Match Rule Specific Context
eqcli cl-clname-ma-maname> hdredit script
{edit|URL}
: Edit a header edit script in
the editor or fetch one from a
specified location.
edit = Invokes an editor to
enter the desired header edit
script.
URL = Fetches the header edit
script with a URL that
identifies a fully qualified
FTP or HTTP site or a file
store location with the file
path starting with 'file://'.
eqcli cl-clname-ma-maname> hdredit show
: Display header edit trace data
(if enabled) or header edit
script.
eqcli cl-clname-ma-maname> hdredit stats
: Display header edit script
statistics.
eqcli cl-clname-ma-maname> hdredit trace_
lvl {errors|off|on}
: Enable tracing for header edit
script errors only.
errors = enable tracing for
header edit script errors
only.
off = disable header edit
script tracing.
all = enable all tracing for
the header edit script.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
203
Working in the CLI
Cluster and Match Rule Command Notes
l
l
l
When creating a cluster, the list of available parameters depends on the protocol selected
for the cluster. As a result, the proto parameter must be specified before any other cluster
parameters on the command line.
Layer 7 clusters can have one or more match rules that override the options set on the
cluster when the expression specified in the match rule matches an incoming client request.
(Layer 4 clusters do not support match rules.)
The cluster flags supported for a particular cluster depend on the setting of the cluster proto
parameter, as shown in the table below.
Cluster Flags
A flag may be turned off by prefixing with "!".
Cluster 'proto'
Flag
Description
tcp and udp
dsr
Enables “direct server return" -- servers respond directly
to clients rather than through Equalizer.
ics
Enables “inter-cluster sticky” -- Layer 4 persistence is
preserved across clusters and server ports.
spoof
Disables Source NAT (SNAT) -- the client IP address is
used as the source IP in packets sent to servers.
abort_server
Close server connections without waiting.
always
Always insert a cookie into server responses.
client_ip
Include the client IP address in headers.
compress
Compress server responses.(Not valid for E250GX)
ignore_case
Do not consider case when evaluating a match rule.
no_header_rewrite
Do not rewrite Location headers in server responses.
once_only
Evaluate the first set of headers in a client connection
only.
persist
Insert a cookie in server responses if the server did not.
spoof
Use the client IP as source IP in packets sent to servers.
tcp_mux
Enables TCP multiplexing for a cluster. TCP multiplexing
must also be enabled on at least one server instance in the
server pool assigned to the cluster (or one of its match
rules). See the section.
allow_sslv2
Enable SSLv2 for client connections.
http and https
https only
204
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Cluster 'proto'
Flag
Description
allow_sslv3
Enable SSLv3 for client connections. This option is
enabled by default.
push_client_cert
Send the entire client certificate to the back-end server.
This allows the server to confirm that the client connection
is authenticated without having to do a complete SSL
renegotiation.
require_client_cert
Require that clients present certificates.
This flag appears only on systems that are equipped with
Hardware SSL Acceleration. When enabled, it specifies
that all SSL operations will be performed in software,
instead of being performed using the SSL accelerator
hardware. This flag does not appear on systems that are
not equipped with Hardware SSL Acceleration, since on
these units SSL operations are always performed in
software. This flag is disabled by default.
software_ssl_only
All units with Hardware SSL Acceleration can process the
TLSv1.0, TLSv1.1, and TLSv1.2 protocols in both
hardware and software, except for legacy GX hardware.
On legacy GX hardware, only TLSv1.0 is supported by
Hardware SSL Acceleration; if you want to enable TLSv1.1
or TLSv1.2 on GX hardware, you must first enable this
flag.
Please note that enabling this option will reduce the
processor and memory resources generally available for
processing cluster traffic, since performing SSL
operations in software requires use of the system CPU and
system memory (instead of the dedicated SSL acceleration
hardware CPU and memory).
allow_tls10
This option enables and disables support for the TLSv1.0
protocol. Enabled by default. If multiple TLS versions are
enabled, the first supported TLS version negotiated by a
client will be used.
allow_tls11
This option enables and disables support for the TLSv1.1
protocol. Disabled by default. If multiple TLS versions are
enabled, the first supported TLS version negotiated by a
client will be used.
allow_tls12
This option enables and disables support for the TLSv1.1
protocol. Disabled by default. If multiple TLS versions are
enabled, the first supported TLS version negotiated by a
client will be used.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
205
Working in the CLI
Cluster 'proto'
Flag
Description
rewrite_redirects
When enabled, forces Equalizer to pass responses from
an HTTPS cluster’s servers without rewriting them. In the
typical Equalizer setup, you configure servers in an HTTPS
cluster to listen and respond using HTTP; Equalizer
communicates with the clients using SSL. If a server
sends an HTTP redirect using the Location: header, this
URL most likely will not include the https: protocol.
Equalizer rewrites responses from the server so that they
are HTTPS. You can direct Equalizer to pass responses
from the server without rewriting them by enabling this
option.
Control whether Equalizer will process "CRL Distribution
Point" extensions in client certificates. This option only
affects the processing of the "CRL Distribution Point"
extension in client certificates:
ignore_critical_extns
When Ignore Critical Extensions is disabled, a client
certificate presented to Equalizer that includes any
extension will be rejected by Equalizer. This is the
behavior in previous releases.
When Ignore Critical Extensions is enabled (the
default), a client certificate presented to Equalizer that
has a CRL Distribution Point extension will be processed
and the CRL critical extension will be ignored. Note,
however, that if other extensions are present in a client
certificate they are not ignored and will cause the client
certificate to be rejected by Equalizer.
strict_crl_chain
206
Check the validity of all certificates in a certificate chain
against the CRL associated with the cluster. If any of the
certificates in the chain cannot be validated, return an
error. If this option is disabled (the default), only the last
certificate in the chain is checked for validity.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Diagnostic Commands
Using Diagnostic Commands in a Global Context
eqcli > diags arp
: Display the ARP entries.
eqcli diags > cache
srvpool sp_name id id
flush
: Flush a single entry from the server pool cache
using an ID (obtained by displaying all cache
entries).
eqcli diags > cache
srvpool sp_spname flush
: Flush all entries from a server pool cache.
eqcli diags > cache flush
: Flush all entries from all server pool caches.
eqcli diags > cache
srvpool srvplname flush
: Deletes all the cache entries of a particular
server pool
eqcli diags > show cache
srvpool srvplname
: Display all the cache entries of a particular
server pool
eqcli diags > context
: Displays the current command context.
eqcli > diags df
: Display the disk space on the file system.
eqcli > diags dig server
ip_address hostname
hostname
: Display the DNS look up information.
eqcli > diags eqcollect
: Download eqcollect on the local filesystem or
upload it to a FTP server.
local: Perform the eqcollect on the local
system.
name : Specify the file name to be embedded in
eqcollect file name as an identifier.
url : Specify the URL for the eqcollect.
eqcli > diags exit
: Commit all pending configuration changes and
change to the global context.
eqcli > diags ifconfig
: Display the state of all interfaces.
eqcli > diags ipmi
: Issue a power on, power off, shutdown or power
reset command to a server.
eqcli > diags netstat
: Display the network status information.
eqcli > diags ps
: Display the information about all the processes.
eqcli > diags quit
: Discard all pending configuration changes and
change to the global context.
eqcli > diags top
: Display the top processes on the system.
eqcli > diags tcpdump fg
count pkt_count capture
|server server_name
|cluster cluster_name |
iface iface_name | vlan
vlan_name | agr agr_name
expr expression
: Save the description of the content of packets
on the network.
(i.e. tcpdump fg count 100 capture vlan vl01
expr "tcp[13] = 2")
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
207
Working in the CLI
External Services Commands
Using External Services Commands in the Global Context
eqcli > ext_services
: Add or modify a mail server in
the'ext_services' context.
eqcli > show ext_services
: Display the configured
external services.
External Services Context Commands
eqcli xs> no smtp_relay name
: Delete the specified SMTP
Relay mail server.
eqcli xs> show smtp_relay name
: Display a list of SMTP Relay
mail servers, or detail for
the specified SMTP Relay mail
server.
eqcli xs> smtp_relay name
: Add or modify a SMTP Relay
(mail server).
eqcli xs> no vlb_manager name
: Delete the specified VLB
Manager.
eqcli xs> show vlb_manager name
: Display a list of VLB Managers
eqcli xs> vlb_manager name
: Add or modify a VLB Manager.
Using SMTP Relay Commands in SMTP Relay Context
eqcli xs-smtp-smtpname > Port
: Set the SMTP mail server port
eqcli xs-smtp-smtpname > Server
: Set the SMTP mail server IP
address. Required.
208
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using VLB Manager Commands in VLB Manager Context
eqcli xs-vlb-vlbmgrname > flags
{[!]disable}
eqcli xs-vlb-vlbmgrname > password
: Set the password for
authenticating a user.
eqcli xs-vlb-vlbmgrname > timeout
: Set number of elapsed seconds
for connection timeout.
eqcli xs-vlb-vlbmgrname > url
: Set the URL used to connect to
the VLB Manager.
eqcli xs-vlb-vlbmgrname > username
: Set the user name for
authenticating a user.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
209
Working in the CLI
Failover Commands
The table below lists the failover global configuration commands that are available in the global
context of the CLI.
Global Commands
eqcli > commit
: Commit all pending alert configuration changes.
eqcli > context
Display the current command context.
eqcli > cmd_subnet
vlanname:subnetname
Set the designated vlan:subnet as the command
subnet.
eqcli > exit
Commit all pending alert configuration changes
and exit to the user context.
eqcli > rebalance
For A/A Failover configurations = Rebalance
clusters among failover group members. Each
cluster will be re-started on its 'preferred
peer'.
For A/P Failover configurations = if the
preferred_primary peer is in Backup mode and
the rebalance command is used, the preferred_
primary will become Primary.
eqcli > quit
Discard all pending alert configuration changes
and exit to the user context.
eqcli > show failover
Display the failover details.
File Commands
Using File Commands in the Global Context
Using File Commands in the Global Context
eqcli > context
: Displays the current command context.
eqcli > exit
: Commit all pending configuration changes and
change to the global context.
eqcli > files ftp file_name
server_URL
: Copy a file to an FTP server.
eqcli > files download URL
: Download a file onto the load balancer.
eqcli > files edit file_name
: Edit a datastore file using the file editor.
eqcli > no file_name
: Delete the specified file.
eqcli > files quit
: Discard all pending files configuration
changes and change to the global context.
eqcli > files show
: List all files in the file store or a
locally mounted USB flash drive.
eqcli > usbdrive
: Enter the USB context to copy files between
the file store and a locally attached USB
flash drive.
Using File commands USB Drive Context
210
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using File Commands in USB Drive Context
eqcli fiusdb> context
: Displays the current command context.
eqcli fiusdb> download
source_file {target
file|directory}
: Download a file from a USB flash drive to
the file store.
eqcli fiusdb> exit
: Change to the global context.
eqcli fiusdb> mount
: Mount a locally attached USB flash drive
filesystem.
eqcli fiusdb> upload source_
file {target file|directory}
: Upload a file from the file store to a USB
flash drive.
Firewall Commands
When you create a subnet, IP Filter (firewall) rules are automatically generated.The Firewall
commands can disable these rules that may be used for troubleshooting or diagnostic purposes.
Disabling the firewall turns off all system packet filtering . Any subnet permit/deny rules are
ignored and all traffic will be routed between subnets.
Firewall Commands in Global Context
eqcli > firewall context
: Display the current command context.
eqcli > firewall disable
: Disable system firewall.
eqcli > firewall enable
: Enable system firewall.
eqcli > firewall exit
: Commit all pending configuration changes
and change to the global context.
eqcli > firewall quit
: Discard all pending configuration changes
and change to the global context.
eqcli > firewall show
: Show firewall configuration
Firewall Commands in Firewall Context
eqcli fw> commit
: Commit all pending configuration changes
and do not change context.
eqcli fw> context
: Display the current command context.
eqcli fw> disable
: Disable system firewall.
eqcli fw> enable
: Enable system firewall.
eqcli fw> exit
: Enable system firewall. Commit all
pending configuration changes and change
to the global context.
eqcli fw> quit
Discard all pending configuration changes
and change to the global context.
eqcli fw> show
Show firewall configuration.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
211
Working in the CLI
GeoCluster and GeoSite Instance Commands
Envoy provides cluster load balancing between Equalizers running at two or more geographically
distributed locations -- called GeoSites. Each GeoSite is configured with a cluster that is capable
of responding to requests for the same content. A GeoCluster is a collection of GeoSites that act
together to determine the “best” GeoSite to respond to a particular request.
Envoy works together with special entries in the Domain Name System (DNS) configuration of the
authoritative name server for a website.
Both GeoClusters and GeoSites are top-level objects in the CLI. In general:
1. Create a GeoCluster for your website (see below).
2. Create GeoSites
3. Add GeoSite Instances to GeoClusters (see below).
Using GeoCluster Commands in the Global Context
eqcli > geocluster gcname req_cmds
: Create geocluster (see below for
cmds)
eqcli > geocluster gcname cmds
: Modify geocluster (see below for
cmds)
eqcli > no geocluster gcname
: Delete geocluster
eqcli > show geocluster
: Display geocluster summary
eqcli > show geocluster gcname
: Display geocluster details
eqcli > geocluster gcname
: Change context to “gcl-gcname"
GeoCluster Context Commands
eqcli gcl-gclname> flags {[!]icmp}
: geocluster flags
eqcli gcl-gclname> fqdnfqdn name
: FQDN for the geocluster website
eqcli gcl-gclname> gsi gsiname
: Change to the geosite instance
context
eqcli gcl-gclname> gsi gsiname cmds
: Execute geosite instance commands
eqcli gcl-gclname> mx
: Set the GeoCluster Mail Exchange
FQDN.
eqcli gcl-gclname> mrmax
: Maximum number of allowable
resource records that will be
returned in a DNS response
eqcli gcl-gclname> policy policy
: GeoCluster Load Balancing policy
eqcli gcl-gclname> stats
: Display the statistics for the
GeoCluster.
eqcli gcl-gclname> respv integer
: Load balancing policy
responsiveness
212
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GeoCluster Context Commands
eqcli gcl-gclname> ttl integer
: DNS cache lifetime for Envoy
responses
Using Geosite Instance Commands in the Global Context
eqcli > geocluster gclname gsi gsiname req_cmds
: Create a geosite instance
eqcli > geocluster gclname gsi gsiname cmds
: Modify a geosite instance
eqcli > no geocluster gclname gsi gsimaname
: Delete a geosite instance
eqcli > show geocluster gsi
: Display geosite instance
summary
eqcli > show geocluster gclname gsi
: Display geosite instance
details
eqcli > cluster clname match maname
: Change to geosite
instance context
Geosite Instance Context Commands
eqcli gcl-gclname-gsi-gsiname> load_weight
: GeoSite Instance weight (0-200)
eqcli gcl-gclname-gsi-gsiname> flags
[!]default,[!]disable,
[!]hot_spare,[!]preferred}
GeoCluster flags can be either icmp (enable ICMP triangulation) or autof (automatic fallback).
[The autof option is not yet implemented.]
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
213
Working in the CLI
Geosite Instance Flags
A flag may be turned off by prefixing with "!".
default
When enabled, designates this GeoSite instance as the default GeoSite instance
for the GeoCluster. Envoy load balances to the default GeoSite instance whenever
it cannot choose a GeoSite instance based on probe responses. [This can
happen, for example, when probe responses are not received from any site,
when the resource (cluster) is down at all available sites, etc.]
If no default GeoSite instance is selected for a GeoCluster and all GeoSites are
down, then Envoy sends a null response to the client DNS.
disabled
When enabled, this GeoSite instance will not be selected as a response to a DNS
query.
hot_spare -
When enabled, indicates that this GeoSite instance will be selected only when no
other sites are available.
preferred
When enabled, indicates that this GeoSite instance will always be selected if it is
available.
214
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GeoSite and GeoSite Resource Commands
A GeoSite definition points to running Envoy and a cluster defined on that a GeoCluster defined on
the Equalizer. GeoSites are associated with GeoClusters by using the GeoSite name when creating
a GeoSite Instance. See "GeoCluster and GeoSite Instance Commands" on page 212.
Using GeoSite Commands in the Global Context
eqcli > geosite gsname req_cmds
: Create geosite (see below for req_
cmds)
eqcli > geosite gsname cmds
: Modify geosite (see below for cmds)
eqcli > no geosite gsname
: Delete geosite
eqcli > show geosite gsname
: Display one or all geosites
eqcli > geosite gsname
: Change to geosite instance context
GeoSite Commands in GeoSite Context
eqcli gs-gsname> address addr[,addr]
: GeoSite address (max: 1 IPv4
and 1 IPv6)
eqcli gs-gsname> agent addr
: IP address of Envoy site
eqcli gs-gsname> resource clname
: Cluster name at GeoSite
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
215
Working in the CLI
GeoSite Commands in the GeoSite Context
eqcli gs-gsname> agent addr
: Set the agent IP address for a
GeoSite.
eqcli gs-gsname> commit
: Commit all pending GeoSite
configuration changes and do
not change context.
eqcli gs-gsname> context
: Display the current command
context.
eqcli gs-gsname> exit
: Commit all pending GeoSite
configuration changes and
change to the global context.
eqcli gs-gsname> noresource name
: Delete a resource.
eqcli gs-gsname> quit
: Discard all pending GeoSite
configuration changes and
change to the global context.
eqcli gs-gsname> resource resource name
: Create a resource or change to
the command context for the
specified resource.
eqcli gs-gsname> show
: Display the GeoSite
configuration, list all
resources, or display details
for the specified resource.
eqcli gs-gsname> type
[remote]
: Set the type for this geosite.
GeoSite agent is located on a
remote machine.
GeoSite agent is located on
this local machine.
[local]
GeoSite Resource Commands in the GeoSite Resource Context
eqcli gs-gsname-rsrc-resource name>
healthchk
216
: Attach one or more health
checks to this resource.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Health Check Commands
Health checks to determine the health of your servers and applications is an important benefit
provided by Equalizer. Without health checking, a client may send a request to a "dead" server
without knowing it. An administrator would need to manually intervene to replace the server.
With Equalizer, health checks can be attached to servers, server instances, server pools, geosite
resources, and LLB gateways. They assist Equalizer in making server load balancing decisions.
Supported health check commands are shown in the following tables.
Refer to "Health Checks" on page 525 for detailed descriptions of the health check configuration.
Using Health Check Commands in a Global Context
eqcli > health_check health_check_name
health_check_type
{acv|http|https|icmp|tcp|udp|srvag|vlb}
: Create a health_check(commands
below)
eqcli > health_check health_check_name
cmds
: Modify health_check(cmds = any
commands below)
eqcli > no health_check health_check_name
: Delete health_check
eqcli > show health_check health_check_
name
: Display all health check for
health_check_name.
eqcli > health_check health_check_name
: Change to the “hc-hcname”
context (see below)
Using Health Check Commands in Health Check Context
eqcli-hc-hcname > access_parms
: Set the access parameters for the
health check probes.Can either be
'Self', indicating that the
parameters required to access the
object to be health-checked are in
the health check definition, or
"Parent", indicating that the
parameters are taken from the object
to which the health check is
attached if not available in the
health check definition.
eqcli-hc-hcname > auth {http_basic
|none}
: HTTP/HTTPS authentication mechanism.
Default is none.
eqcli-hc-hcname > commit
: Commit all pending health check
configuration changes.
eqcli-hc-hcname > context
: Display the current command context.
eqcli-hc-hcname > exit
: Commit all pending health check
configuration changes and exit to
the top level context.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
217
Working in the CLI
Using Health Check Commands in Health Check Context
eqcli-hc-hcname > flags
: Set the health check flags.
disable = disables the health check
on a global level.
For All health checks
{disable}
For ICMP and UDP health checks
relaxed_probe (ICMP) = When enabled,
if a server is DOWN, but has not
previously been UP, it will be
marked UP. Setting of this flag
prevents the sudden reporting of
servers as being DOWN following an
upgrade.
{[!]relaxed_probe}
relaxed_probe (UDP) = Determines
what happens when no response is
received to a UDP health check
probe. If this flag is enabled, the
object is marked UP. If this flag is
disabled, the object is marked DOWN.
probe_ssl= If enabled, the probe
exchange between Equalizer and a
server instance will be performed
over an encrypted SSL connection.
For ACV , L4 TCP, and Server Agent health checks
{[!]probe_ssl,[!]highest_tls_
version}
highest_tls_version = Set the health
check highest TLS version. Used when
the probe_ssl option is enabled.
Sets the health check highest TLS
version. It specifies the highest
TLS version that will be offered in
the SSL probe sent to servers The
probe can use levels from SSLv3 and
the highest probe levels of TLS 1.0,
1.1, or 1.2
Valid values are:
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
(Default: 4)
eqcli-hc-hcname > heavy_load
value
eqcli-hc-hcname > highest_tls_version
value
: Set the heavy_load value for the
health check. 'heavy_load' is a
floating-point value.
: Valid values are:
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
Note: Only valid on ACV, TCP and
Server Agent health checks.
eqcli-hc-hcname > ip IP address
218
: Set the server IP address
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Health Check Commands in Health Check Context
eqcli-hc-hcname > light_load value
: Set the light_load value for the
health check. 'light_load' is a
floating-point value.
eqcli-hc-hcname > http_method
{POST|GET|HEAD}
: HTTP/HTTPS method.
eqcli-hc-hcname > no
: Delete a health check or reset a
health check parameter to its
default value.
eqcli-hc-hcname > probe_cto Connection
timeout
: Set the health check probe connect
timeout (in seconds).
eqcli-hc-hcname > probe_dto data
timeout
: Set the health check probe data
timeout (in seconds).
eqcli-hc-hcname > probe_gto global
timeout
: Set the health check probe global
timeout (in seconds).
eqcli-hc-hcname > probe_interval probe
interval
: Set the interval between health
check probes (in seconds).
eqcli-hc-hcname > probe_maxtries max
tries per interval
: Set the maximum number of attempts
per interval before marking a server
'down'.
eqcli-hc-hcname > pw password
: Password for HTTP authentication.
eqcli-hc-hcname > port port number
: Set the port number for probing the
server.
eqcli-hc-hcname > send_data (edit|URL}
: Data to be sent after connection.
For HTTP/HTTPS this is the message
body. For ACV this is the query.
1024 bytes maximum.
edit- invokes an editor to enter
the desired send data.
URL - fetches the send data from
the entered fully qualified
ftp/http site or from the file
store with the path to the data
file starting with file://'.
May include escape characters
(e.g., '\n')
eqcli-hc-hcname > quit
: Discard all pending health check
configuration changes and exit to
the top level context.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
219
Working in the CLI
Using Health Check Commands in Health Check Context
eqcli-hc-hcname > recv_data {edit|url}
: Set an expected receive string for
the ACV or HTTP/HTTPS health check.
For HTTP/HTTPS health checks, the
received response is only checked
against the recv_data string if the
returned status code falls within
the set of status codes defined as
success (or not within the set of
status codes defined as failure).
1024 bytes maximum.
edit := invokes an editor to enter
the desired receive data.
url := fetches the receive data from
the entered fully qualified ftp/http
site or from the file store with the
path to the data file starting with
file://'.
May include escape characters (e.g.,
'\n')
eqcli-hc-hcname > send_hdr (edit|url}
: HTTP/HTTPS send header. Up to 10
headers may be specified.
edit := invokes an editor to enter
the desired send header or set of
send headers in the format:
name:value"[,"name:value"][...] .
url := fetches the send header(s)
from the entered fully qualified
ftp/http site or from the file store
with the path to the data file
starting with file://'. Each
"name:value" string may contain at
most 1024 characters.
eqcli-hc-hcname > show
: Display the health check details.
eqcli-hc-hcname > stat_codes hc_
state:value,value
: Status codes. The value must consist
of either the word "up" or the word
"down", followed by a ":",followed
by one or more comma-separated
values or value ranges. The up/down
term describes whether the
healthcheck should be considered up
or down if any of the following
status codes is received. Example:
stat_codes up:200-226,301.
hc_state := up|down
value := number|number-number
(number := 3-digit numerical value.)
eqcli-hc-hcname > vlb_mgr vlb manager
(Only valid when health check 'type'
= 'vlb'.)
220
: Set the VLB Manager for the health
check.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Health Check Commands in Health Check Context
eqcli-hc-hcname > vlb_param vlb_param
{vm_cpu|vm_ram}
: Set the VLB Parameter for the health
check.
(Only valid when health check 'type'
= 'vlb'.)
eqcli-hc-hcname > vlb_uuid vlb_uuid
(Only valid when health check 'type'
= 'vlb'.)
: Set the VLB UUID for the target
server.
eqcli-hc-hcname > vms
: List all the virtual machines from
the VLB Manager. Valid only for VLB
health check.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
221
Working in the CLI
Using Health Check Commands in Health Check Instance Context
eqcli obj-obn*-hc-hcn*> commit
: Commit all pending health check
instance configuration changes.
eqcli obj-obn*-hc-hcn*> context
: Display the current command
context.
eqcli obj-obn*-hc-hcn*> exit
: Commit all pending health check
instance configuration changes and
exit to the server instance
context.
eqcli obj-obn*-hc-hcn*> flags : Set the health check instance
flags.
[!]disable],[!]optional
"optional" - If other health checks
are up, a failure of this health
check will not mark the object as
'down'.
For attached ACV Health Checks:
eqcli sp-srv*-hc-hcn*> test
serverinstancename
: Test the health check on the
referenced object. If the object is
a server pool, and a server name is
specified after the "test" keyword,
only that server instance will be
tested. If no server name is
specified, all server instances
will be tested.
NOTE: Currently test is only
supported on TCP/ACV healthchecks
attached to server pools and server
instances.
222
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Interface Commands
The interface context commands let you configure and manage Equalizer’s front panel interface
ports. There is a separate context corresponding to each front panel port. Ports are created
automatically by the system and cannot be deleted. To view a summary of the current port
configuration and status, enter:
eqcli > show interface
The name of each port is displayed, along with the port’s current autonegotiation, duplex, speed,
and link status.
Refer to "Viewing Link Status and Port Settings" on page 111 for additional information about
using the Interface commands as well as a description of the statistical information available for
each port.
Using Interface Commands in the Global Context
eqcli > interface port cmds
eqcli > show interface
eqcli > show interface port
eqcli > interface port
Port Context Commands
eqcli if-port> autonegotiation {force|full|select}
eqcli if-port> duplex {full|half}
eqcli if-port> speed {10|100|1000}
eqcli if-port> show
eqcli if-port> stats
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
223
Working in the CLI
Interface Command Notes
The following statistics can be displayed for a selected port using the stats command. Select a
port on the Equalizer display to display statistics the port. The tables below shows a typical port
statistics display.
Transmit Counters
Packets
The total number of transmitted packets on this
interface.
bytes
The total number of bytes transmitted on this
interface
multicasts
The total number of good broadcast/multicast (e.g.,
ARP) packets transmitted by this interface.
errors
The total number of bad packets transmitted by this
interface.
collisions
The total number of packets that were dropped (e.g.,
lack of transmit buffer , collision detection). These
packets are not transmitted by the interface.
Receive Counters
Packets
The total number of packets received on this
interface.
bytes
The total number of bytes received on this interface.
multicasts
The total number of good broadcast/multicast (e.g.,
ARP) packets received on this interface.
errors
The total number of bad packets (e.g., CRC errors,,
alignment errors) received on this interface.
drops
The total number of packets that were dropped (e.g.,
lack of receive buffer, congestion, invalid
classification, e.g., tagged frame received on
untagged port) by the receiving interface.
unknown protocol
Tot total number of packets received on this interface
that used an unknown protocol.
224
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Link Aggregation Commands
Link aggregation is a means by which multiple physical interfaces are combined into a single
logical (aggregated) interface, providing increased bandwidth and failover. The following are
CLI commands.
Using Link Aggregation Commands in Global Context
eqcli > agr name
: Add or modify an AGR or interface
instance.
eqcli > show agr
: Display a list of AGRs or interface
instances.
eqcli > show agr name
: Display details for the specified
AGR or interface instance
Using Link Aggregation Commands in an Interface Instance Context
eqcli > agr-name> flags
[!lacp]
eqcli > agr-name>ifi
: Change to the command context for
the specified interface instance.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
225
Working in the CLI
Link Load Balancing Commands
Using Link Load Balancing Commands in the Global Context
eqcli > illb-grpillb-grp name
: Change to the illb group name
context.
eqcli > illb-grp illb-grp commands
: Modify the illb group
eqcli > no illb-grp illb-grp name
: Delete illb-grp name
eqcli > show illb-grp]illb-grp name
: Display all illb groups or
illb-grp name
eqcli > ollb-grpllb-grp name
: Change to the illb group name
context.
eqcli > ollb-grp ollb-grp commands
: Modify the ollb group
eqcli > no ollb-grp ollb-grp name
: Delete ollb-grp name
eqcli > show ollb-grp]ollb-grp name
: Display all ollb groups or
ollb-grp name
eqcli > llb-gwllb-gw name
: Change to the llb gateway name
context.
eqcli > llb-gw llb-gw commands
: Modify the llb gateway
eqcli > no llb-gw llb-gw name
: Delete llb-gw name
eqcli > show llb-gw]llb-gw name
: Display all llb gateways or
llb-gw name
226
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
LLB Specific Context Commands
Inbound LLB Group Context Commands
eqcli > illb-grp-illbgrpname*> flags
: Set illb group flags.
{enable|disable}
eqcli > illb-grp-illbgrpname*> fqdn fully
qualified domain name
eqcli > illb-grp-illbgrpname*>
policypoltype
: Set the illb group Full
Qualified Domain Name.
Required.
Set the illb group policy.
eqcli > illb-grp-illbgrpname*> show
: Display the illb group
configuration.
eqcli > illb-grp-illbgrpname*> target
: Change to the command context
for the specified illb target.
eqcli > illb-grp-name*> ttl
: Set the illb group TTL.
Outbound LLB Group Context Commands
eqcli > ollb-grp-ollbgrpname > flags
{enable|disable}
: Set ollb group flags.
eqcli > ollb-grp-ollbgrpname > gwips
: Set the ollb group gateway(s).
This is a comma-delimited list
of LLB gateway IPs.
eqcli > ollb-grp-ollbgrpname > no
: Reset a ollb group parameter
to its default value.
eqcli > ollb-grp-ollbgrpname > show
: Display the ollb group
configuration.
LLB Gateway Context Commands
eqcli > llb-gw-gwname > flags
: Set llb gateway flags.
{enable|disable}
eqcli > llb-gw-gwname > gw-hcobjects
: Set the llb gateway health_
check(s). This is a commadelimited list of health_check
objects.
eqcli > llb-gw-gwname > no
: Reset an llb gateway parameter
to its default value.
eqcli > llb-gw-gwname > show
: Display the llb gateway
configuration.
eqcli > llb-gw-gwname > weightvalue
: Set llb gateway weight.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
227
Working in the CLI
Object List Commands
Object lists make it easier to manage user permissions by allowing an administrator to assign
user permissions via list of objects.
An entry in an object list is an “object type” and “object name” pair. Once an object list is created,
object list names are used as arguments to user context commands (see "User Commands" on
page 252) to give a user permission to access objects in the list.
Using Object List Commands in the Global Context
eqcli > objlist olname
: Create an object list, or if it
exists change context
eqcli > objlist olname cmds
: Modify an object list (see below for
cmds)
eqcli > no objlist olname [force]
: Delete an object list
eqcli > show objlist [olname]
: Display all object lists, or the one
specified
Object List Context Commands
eqcli obj-olname> type object
: Remove the specified object
eqcli obj-olname> no type object
: Add an object to the list
eqcli obj-olname> show
: Display object list
Object List Notes
l
l
l
l
Only a user with the admin flag enabled can create, modify, or delete object lists.
The type argument must be one of the following object types: cert , cluster, crl, geocluster,
geosite, port , responder, server, srvpool, subnet , or vlan.
The object argument must be the name of an existing object of the specified type. (Object
list names and the keyword all are not allowed.)
The no form of the objlist command is immediately executed; no commit is required.
Specifying an Object List When Creating or Modifying an Object
An objlist argument is optional when creating (or modifying) an Equalizer object, and adds an entry
for the object to the specified object list. To add an entry to an object list, the user must have
permission to create objects of the specified type in that object list.
Permission to create objects in an object list is given by the permit_objlist command, as
outlined in "User Permissions" on page 257.
read and write permissions on both the object list and the object to be added to the list (or have the
admin flag set on the user definition).
Note - When a user creates an object, that user is given read, write, and delete permissions on that object.
228
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Peer Commands
Peer context commands are used to manage the configuration of failover peers, including the
failover peer configuration for this Equalizer, which is created when the system is booted for the
first time. The default peer name for the Equalizer you are logged into is of the form:
eq_sysid
The sysid above is Equalizer’s “Peer sysid” (or system ID), as displayed in the peer configuration;
for example:
eqcli > show peer
-----------------------------------Configuration Sequence Number: 53
-----------------------------------Peer Name
Message(s)
eq_880A4D0B5C94A611CB927D44BED75F20C7BE7D8C (Local)
Standalone-Owner None
Type
Flags
OS/10
xfr
F/O Mode
Flags Key:
F/O => failover
A/A => active-active
P/P => preferred_primary
xfr => fo_config_xfer
ssl => use_ssl
eqcli > show peer eq_880A4D0B5C94A611CB927D44BED75F20C7BE7D8C
Peer Name
: eq_880A4D0B5C94A611CB927D44BED75F20C7BE7D8C
Peer signature
:
1RBC880A4D0B5C94A611CB927D44BED75F20C7BE7D8CAC100602
Peer sysid
: 880A4D0B5C94A611CB927D44BED75F20C7BE7D8C
Receive Timeout
: 2
Connect Timeout
: 1
Probe Interval
: 2
Retry Interval
: 5
Strike Count
: 3
Flags
: fo_config_xfer, local
OS/8 Internal IP
:
Number of Interfaces : 2
Member of Failover Group
: No
Failover Enabled/Disabled
: Disabled (No remote Peers)
Local/Remote Peer
: Local
Interface
: v2
State
: Configure
Substate
: Object Unchanged
Subnet
: sn172
State
: Configure
Substate
: Object Unchanged
Interface
: v3
State
: Configure
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
229
Working in the CLI
Substate
Subnet
State
Substate
: Object Unchanged
: sn192
: Configure
: Object Unchanged
eqcli >
Using Peer Commands in the Global Context
eqcli > peer peername [cmds]
: Create peer (see below for cmds)
eqcli > peer peername cmds
: Modify peer (see below for cmds
eqcli > no peer peername [force
: Delete peer
eqcli > show peer [peername]
: Display all peers or a specific peer
eqcli > peer peername
: Change to a peer-specific context
230
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Peer Context Commands
eqcli > conn_retry_count value
: Set the Failover connectivity
retry count. This controls the
number of times that a peer will
try to re-gain connectivity with
a remote peer before becoming the
primary peer for any failover
groups running on the remote
peer. The default value is 8.
eqcli peer-peer> conn_timeout value
: Set the Failover connect timeout
(sec)
eqcli peer-peer> debug
: Set the debug level
eqcli peer-peer> flags
[!]failover|fo_config_xfer
[!]os8|[!]preferred_primary
[!]active-active [!]ssl
: Set peer flags (see below)
eqcli peer-peer> hb_interval value
: Set the Failover heartbeat
interval (seconds).
eqcli peer-peer> ipstate
: Only valid for local Peer.
Displays peer IP states.
eqcli peer-peer> os8_intip internal ip
: Set the 'Internal' IP address for
an appliance running Version 8
with two VLANs.
eqcli peer-peer> name peer name
: Set the peer name.
eqcli peer-peer> recv_timeout value
: Set the Failover receive timeout
(sec)
eqcli peer-peer> retry_interval value
: Set the Failover retry interval
(sec)
eqcli peer-peer> show
: Display the peer configuration.
eqcli peer-peer> signature signature
: Set the peer signature.
eqcli peer-peer> stats
: Display object list
eqcli peer-peer> strike_count value
: Set the Failover strike count
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
231
Working in the CLI
Peer Context Command Flags
A flag may be turned off by prefixing with "!".
232
failover
Adds peer to failover group
fo_config_xfer
Enable configuration transfer between peers
os8
Defines peer as OS8 peer
Preferred_primary
Sets peer as preferred primary
active-active
Enable active/active failover mode
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Protection Commands
Protection Commands are used in Access Control List (Blacklist/Whitelist) configuration and IP
Reputation Commands.
Protection Commands in Global Context
eqcli > protection acl
: Enter the Access Control List
(blacklist & whitelist) context.
eqcli > protection reputation
: Enter IP Reputation context.
Access Control List Commands in Protection Context
eqcli prot> acl blacklist
: Enter the Blacklist context
eqcli prot> acl flags disable
: Disables the Access Control list.
(Enabled by default)
eqcli prot> acl whitelist
: Enter the Whitelist context
Blacklist Commands in Blacklist Context
eqcli prot acl bl> dst_ip ip_address
: Set the destination IP. The
destination address is a single IP
address.
eqcli prot acl bl> dst_port port
: Set the destination port.
eqcli prot acl bl> src_ip {IP list|IP
Specification|IP address|IP network|IP
range}
: Set the source IP(s) to the
blacklist to be blocked.
IP list = comma-separated list of
IP addresses.
IP specification = <IP
address>|<IP network>|<IP range>.
IP address = a single address.
IP network = an IP address in
CIDR format.
IP range = <start IP address><end IP address>.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
233
Working in the CLI
Whitelist Commands in Whitelist Context
eqcli prot acl wh> src_ip ip_address
: Set the source IP(s) of the IP
addresses to be whitelisted, or
allowed.
IP list = comma-separated list of
IP addresses.
IP specification = <IP
address>|<IP network>|<IP range>.
IP address = a single address.
IP network = an IP address in
CIDR format.
IP range = <start IP address><end IP address>.
Using IP Reputation Commands in Protection Context
eqcli prot> reputation block
category|IP list
: Set a category or list of IPs to
block.
eqcli prot> reputation disable
: Disable IP Reputation processing.
eqcli prot> reputation enable
: Enable IP Reputation processing.
eqcli prot> reputation fetch
: Fetch the current IRDB.
eqcli prot> reputation load
: Fetch pkg file and load IRDB from
it.
eqcli prot> reputation pass anonymous_
proxy|botnet|phishing|spam
: Allow connections from all IP
addresses in the specified
category.
eqcli prot> show reputation anonymous_
proxy|botnet|phishing|spam
: Show the list of categories or the
IP addresses within a category.
eqcli prot> reputation stats
anonymous_
proxy|botnet|phishing|spam|reset|IP
list
: Show Blocked IP counters.
An IP list can be entered. This is
a comma separated list of IP
addresses. If an IP, or a list of
IPs is entered, the counters for
the specified IPs will be
displayed.
234
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Remote Management Commands
Remote Management commands are used to specify cipher suites, certificates, and the allowable
protocols to use for connection with HTTPS clusters.
Refer to "Using Certificates in HTTPS Clusters" on page 980 for additional information and
descriptions on using these commands.
Remote Management Commands in Global Context
eqcli > show remote-mgmt
: Display the remote management
options.
eqcli > no remote-mgmt
: Delete a specifc remote management
option.
eqcli > remote-mgmt certificate
certificatename
: Set the https server certificate to
use.
eqcli > remote-mgmt cipherspec
cipherspec
: Set the cipherspec to use.
eqcli > remote-mgmt protocol protocol
[!]sslv3,[!]tls10,[!]tls11,
: Set the allowed SSL/TLS protocols.
[!]tls12
NOTE:
The protocol specification must be
enclosed by double quotes if there
are any spaces.
Remote Management Commands in Remote Management Context
eqcli rm> show
: Display the remote management
options.
eqcli rm> no remotemgmtoption
: Delete a specific remote
management option.
eqcli rm> certificate certificatename
: Set the https server certificate
to use.
eqcli rm> protocol protocol
[!]sslv3,[!]tls10,[!]tls11,
: Set the allowed SSL/TLS protocols.
NOTE:
[!]tls12
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
The protocol specification must be
enclosed by double quotes if there
are any spaces.
235
Working in the CLI
Responder Commands
Note -Responders are not supported on E250GX model Equalizers.
Responders are global objects in the sense that a single responder can be assigned to multiple
clusters. They are used when no servers in the associated server pool are available:
l
l
A responder can be added in the cluster context, in which case it is used when no servers in
the server pool defined for the cluster are available.
A responder can also be assigned to a cluster in a match rule context, in which case the
responder is used when no servers in the server pool defined for the match rule are
available.
Using Responder Commands in the Global Context
eqcli > resp rname req_cmds
: Create rname (req_cmds = * commands below)
eqcli > resp rname cmd ...
: Modify rname (cmds = any commands below)
eqcli > no resp rname
: Delete rname
eqcli > show resp [rname]
: Display all responders or rname
eqcli > resp rname
: Change to the “rsp-rname" context (see below)
Using Responder Commands in a Responder Specific Context
eqcli rsp-rname> stats
: Display responder statistics
eqcli rsp-rname> *type {sorry|redirect}
: (R) MUST SET type FIRST
type = redirect:
eqcli rsp-rname> regex “expr”
: Set redirect regular
expression
eqcli rsp-rname> *statcode {301|302|303|307}
: Set redirect status code
eqcli rsp-rname> *statdesc “desc”
: Set redirect status
description
eqcli rsp-rname> *url “url”
: Set redirect URL
type = sorry:
eqcli rsp-rname> *html {edit|url}
236
: Set HTML for “sorry”
responder
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
When creating a responder, you must specify the type parameter first on the command line, and
then the parameters required for that type. The supported responder types are:
l
l
redirect - A standard “HTTP Redirect" response that specifies a return code (statcode),
description (statdesc), and redirect URL (url). When the client receives this page, it is
automatically redirected to the redirect URL. Redirect pages can be configured to use parts
of the request URL in the HTTP Redirect response (using an optional regular expression).
sorry - A customized HTML “sorry page” that can, for example, ask the client to retry later
or go to another URL
For example, the following command creates a sorry responder named Sorry01, and downloads the
redirect URL from the URL specified on the command line:
eqcli > resp Sorry01 type sorry html ftp://mylocalftpserver/redirect.html
The contents of the file redirect.html will be used as the redirect URL for the responder.
The html parameter can be specified on the command line as follows:
edit
Launch an editor to supply the HTML for the sorry page.
“url”
Download the redirect URL from the ftp:// or http:// protocol URL supplied on the
command line (quotes are optional).
html
Regular Expressions in Redirect Responders
For a discussion of regular expressions and how they can be used in redirect type responders, see
"How to Use Regular Expressions" on page 919
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
237
Working in the CLI
Server Commands
In the server context, you define a real server using a minimal set of parameters (IP address,
port, protocol, etc.). Once defined, a real server can then be associated with one or more server
pools, which in turn are associated with one or more Layer 4 clusters or Layer 7 match rules.
Using Server Commands in the Global Context
eqcli > server svname req_cmds
: Create svname (req_cmds = * commands
below)
eqcli > server svname cmds
: Modify svname (cmds = any commands
below)
eqcli > no server svname
: Delete svname
eqcli > show server [svname]
: Display all servers or svname
eqcli > server svname
: Change to the “sv-svname” context(see
below)
Using Server Commands in a Server Specific Context
eqcli sv-svname> hc health check name
: Change to the command context
for the specified health check
instance.
eqcli sv-svname> *ip ip_addr
: Server IP address
eqcli sv-svname> no {max_reuse_
conn|reuse_conn_to}
: Reset the parameter to its
default value
eqcli sv-svname> *proto {tcp|udp}
: Server protocol
eqcli sv-svname> *port integer
: Server port
eqcli sv-svname> show
: Show server configuration
eqcli sv-svname> stats
: Display server statistics
eqcli sv-svname> max_reuse_conn integer
: Maximum number of connections
to this server
eqcli sv-svname> reuse_conn_to integer
: Timeout for connection re-use
eqcli sv-svanme> uuiduuidname
: Associate a virtual machine
with the server.
eqcli sv-svanme> vlb_manager vlbmgrname
: Attach a VLB Manager for the
associated virtual machine.
eqcli sv-svanme> vms
: List all the virtual machines
from the VLB Manager.
The max_reuse_conn and reuse_conn_to are used to set operating parameters for HTTP
multiplexing. HTTP multiplexing is disabled by default, and is turned on/off using the tcp_mux
cluster flag. Refer to "HTTP Multiplexing" on page 832 for additional information.
238
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Pool, Server Instance, and Caching Commands
A server is attached to a cluster via a server pool. A server pool is a collection of server
definitions, each of which has additional parameters assigned to it in the server pool -- these
additional parameters are organized by the server’s name and are referred to as server instances
within the server pool context. This allows you to associated a distinct set of server instance
options (weight, flags, maximum number of connections), to multiple instances of the same real
server in different server pools.
Using Server Pool Commands in the Global Context
eqcli > srvpool spname commit
: Commit all pending server pool
configuration changes and do not
change the command context.
eqcli > srvpool spname context
: Displays the current command context.
eqcli > srvpool spname custom_actconn
0-100
: Set the active connections weight for
the custom load balancing policy.
eqcli > srvpool spname custom_delay
0-100
: Set the delay weight for the custom
load balancing policy.
eqcli > srvpool spname
: Set the server pool flags.
flags flag
{[!]disable}
eqcli > srvpool spname policy roundrobin|static|adaptive|response|leastcxns|server-agent
: Set the load balancing policy for a
server pool. Required. (see below)
eqcli > srvpool spname quit
: Discard all pending server pool
configuration changes and exit to the
global context.
eqcli > srvpool spname respv load
balancing responsiveness
: Set the load balancing responsiveness
for a server pool. Required.
eqcli > srvpool spname si siname
: Change to the command context for the
specified server instance.
eqcli > srvpool spname stats
: Display server pool statistics.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
239
Working in the CLI
Using Server Pool Commands in a Server Pool Specific Context
eqcli sp-spname> custom_actconn percent
: Custom LB policy - active
connections percentage
eqcli sp-spname> custom_delay percent
: Custom LB policy - server
delay percentage
eqcli sp-spname> no {si|srvpool|} name
parameter
: Delete a server instance or
reset a server pool or server
instance parameter.
eqcli sp-spname> policy policyname
: Set the load balancing policy
for a server pool. Required.
eqcli sp-spname> quit
: Discard all pending server
pool configuration changes and
exit to the global context.
eqcli sp-spname> respv load balancing
responsiveness
: Set the load balancing
responsiveness for a server
pool. Required.
eqcli sp-spname> show si
: Display the current server
pool configuration, list all
server instances or display
details for the specified
server instance
eqcli sp-spname> si server instance name
: Change to the command context
for the specified server
instance.
eqcli sp-spname> stats
: Display server pool
statistics.
240
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Caching Commands Server Pool Specific Context
eqcli sp-spname-cache> age value
: Set the age (in seconds)at which an
item in the cache is marked 'stale',
and is therefore a candidate for
removal or replacement. If the cached
object reaches this age limit, it
becomes 'stale'.(Default: 24
hours/86400 seconds)
eqcli sp-spname-cache> flags
: Set the cache flags
disable := Disable the cache
(all existing cache will be flushed)
{[!]disable}
enable := Enable the cache
(Default: enable)
eqcli sp-spname-cache> max_object_
size integer
: Set the maximum object size (in MB)to
cache. If the response is larger than
the value set, it will not be cached.
Minimum: 0.
Maximum: The maximum cache size is
platform-dependent as follows:
E370LX -- 100MB
E470LX -- 200MB
E670LX -- 300MB
E970LX -- 500MB
EQOD -- 50MB
eqcli sp-spname-cache> max_
sizeinteger
: Set the maximum amount of memory
allocated, in bytes, to the server pool
cache
Minimum: 0
Maximum: 10MB max (10485760 bytes)
(Default: 2KB (2048 bytes)
eqcli sp-spname-cache> policy
policy
: Set the replacement policy for the
cache.
policy := oldest, largest
oldest := the entry with the oldest
freshness time will be removed.
largest := the largest item will be
removed from the cache.
(Default: oldest)
eqcli sp-spname-cache> show
: Display all cache parameters
eqcli sp-spname-cache> stats
: Display all of cache statistics on this
server pool.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
241
Working in the CLI
Using Server Instance Commands in the Server Instance Context
eqcli sp-srv*-si-siname > flags flag
{[!]hot_spare, [!]persist_override,
[!]quiesce, [!]strict_maxconn,
[!]delete}
: Set the server instance
flags.(see below)
eqcli sp-srv*-si-siname > maxconn maxconn
: Set the number of maximum
connections for a server
instance.
eqcli sp-srv*-si-siname > stats
: Display server instance
statistics.
eqcli sp-srv*-si-siname > weight value
Set the server instance
initial weight. Required.
Server Instance Flags
A flag may be turned off by prefixing with "!".
Flag
Description
delete
Disables the server connection.
hot_spare
Enable the hot spare check box if you plan to use this server as a backup server,
in case the other server instances in a server pool on the cluster fail. Enabling
hot spare forces Equalizer to direct incoming connections to this server only if all
the other servers in the cluster are down. You should only configure one server
in a cluster as a hot spare.
persist_override
Disables persistence for the server when the persist flag (Layer 7 cluster) or a
non-zero sticky time (Layer 4 cluster) is set on a cluster. For a Layer 7 cluster,
this means that a cookie will not be inserted into the response header when
returned to the client. No sticky record is set for a Layer 4 cluster. This flag is
usually used to disable persistence for a hot spare.
When enabled, Layer 4 sticky records and Layer 7 cookies are ignored for the
server instance.
quiesce
242
When enabled, Equalizer avoids sending new requests to the server. This is
usually used in preparation for shutting down an HTTP or HTTPS server, and is
sometimes also called “server draining”.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Flag
Description
This flag allows you to customize the behavior of the max connections parameter
(see above).
When Strict Max Cx is enabled (the default), the max connections parameter is
interpreted as a strict maximum and is never overridden. If a client attempts to
connect to a server that has a number of connections equal to the max
connections setting, then the connection is refused.
strict_maxconn
When Strict Max Cx is disabled, the max connections setting will be overridden
in any of the following circumstances:
A client attempts to connect to a server with the hot spare flag
enabled - this allows hot spares to service more than the max
connections setting of connections.
A client attempting to connect to a Layer 7 cluster has a
persistence cookie and the server identified in the cookie has
already reached its max connections limit.
A client attempting to connect to a Layer 4 cluster has an existing
sticky persistence connection to a server and that server has
already reached its max connections limit.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
243
Working in the CLI
Load Balancing Policies
Equalizer supports the following load balancing policies, each of which is associated with a
particular algorithm that Equalizer uses to determine how to distribute requests on a server pool
in the cluster:
l
Round-robin load balancing - distributes requests equally on the server pool in the cluster.
Equalizer dispatches the first incoming request to the first server, the second to the second
server, and so on. When Equalizer reaches the last server, it repeats the cycle. If a server
in the cluster is down, Equalizer does not send requests to that server. This is the default
method.
The round robin method does not support Equalizer’s adaptive load balancing feature; so,
Equalizer ignores the servers’ initial weights and does not attempt to dynamically adjust
server weights based on server performance.
l
Static load balancing - distributes requests among the servers depending on their assigned
initial weights. A server with a higher initial weight gets a higher percentage of the incoming
requests. Think of this method as a weighted round robin implementation. Static weight
load balancing does not support Equalizer’s adaptive load balancing feature; Equalizer does
not dynamically adjust server weights based on server performance.
l
Adaptive load balancing - distributes the load according to the following performance
indicators for each server.
l
Response is the length of time for the server to begin sending reply packets after Equalizer
sends a request.
l
Least Cxns (least connections) load balancing - dispatches the highest percentage of requests
to the server with the least number of active connections. In the same way as Fastest
Response, Equalizer tries to avoid overloading the server so it checks the server’s response
time and server agent value. Least Connections optimizes the balance of connections to
servers in the cluster.
l
l
Server Agent load balancing - dispatches the highest percentage of requests to the server
with the lowest server agent value. In a similar way to Fastest Response, Equalizer tries to
avoid overloading the server by checking the number of connections and response time.
This method only works if the server agents are running on every server instance in the
server pool.
Custom load balancing - If custom is selected, you can adjust the load balancing policy
parameters:
o
Connections - The relative influence on the policy of the number of active
connections currently open to a server
244
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
o
Response Timeload balancing -dispatches the highest percentage of requests to
the server with the shortest response time. Equalizer does this carefully: if
Equalizer sends too many requests to a server, the result can be an overloaded
server with slower response time. The fastest response policy optimizes the
cluster-wide response time. The fastest response policy also checks the number
of active connections and server agent values (if configured); but both of these
have less of an influence than they do under the adaptive load balancing policy.
For example, if a server’s active connection count and server agent values are
high, Equalizer might not dispatch new requests to that server even if that
server’s response time is the fastest in the cluster.
o
Responsiveness - Determines how aggressively server dynamic weights are
optimized as a cluster load changes.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
245
Working in the CLI
Server Side Encryption Commands
Using Server Side Encryption Commands in Global Context
eqcli > show sse
: Display the sse configuration.
eqcli > sse cipherspec cipherstring
: Set the sse cipherspec
eqcli > no sse
: Reset one or more sse parameters.
eqcli >sse flags
: Set the sse flags
{[!]allow_tls10,
[!]allow_tls11, [!]allow_tls12}
246
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Smart Control Commands
The smart_control commands let you configure and manage Smart Controls.
Refer to "Adding Smart Controls" on page 863 for a description of the process for adding Smart
Controls.
To view a summary of the currently configured Smart Controls:
eqcli > show smart_control smart_control_name
The names of all of the currently configured Smart Controls will be displayed.
Using Smart Control Commands in the Global Context
eqcli > smart_controls name
eqcli > show smart_controls name
eqcli > no smart_controls name
eqcli > show smart_controls
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
247
Working in the CLI
Smart Control Context Commands
eqcli sc-scname > flags
{[!]disable}
: Set Smart Control flags.
eqcli sc-scname > interval
seconds
: Set the Smart Control interval.
eqcli sc-scname > lastrun
: Display the first 1023 characters of the
output generated during the last
execution of this smart control.
eqcli sc-scname > run_limit
seconds
: Set the Smart Control run limit.
(default: 10 seconds)
eqcli sc-scname > run
: Run Smart Control now.
eqcli sc-scname >
scheduleschedule string
: Set the Smart Control schedule.
The string is in the standard cron
format, but with an additional first
column -- second:
second 0-59
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use
names)
Lists and ranges are supported (use ','
as a list delimiter or '-' as a range
delimiter), but steps are not.
White space (' ' or ) is a column break,
and consecutive white spaces are treated
as one.
Fields which are an asterisk ('*') are
skipped.
Day names:
'Mon','Tue','Wed','Thu','Fri','Sat','Sun'
Month names: 'Jan', 'Feb', 'Mar', 'Apr',
'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct',
'Nov', 'Dec'
Note: The schedule string must be
enclosed in quotes.
i.e.: "* 0,30 * * * Mon" would be
translated as 'Every Monday, run this
every 30 seconds'.
eqcli sc-scname > script mode
edit|URL
: edit invokes an editor to enter the
desired script.
<URL> fetches the script from the entered
fully qualified ftp/http site.
eqcli sc-scname > stats
248
: Display Smart Control statistics.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
SNMP Commands
The parameters in the SNMP context specify return values for the following Object IDs (OIDs) in
the Equalizer SNMP Management Information Base (MIB):
OID
Parameter
Default
Value
Description
community
Equalizer
Any SNMP management console needs to send the correct community string
along with all SNMP requests. If the sent community string is not correct,
Equalizer discards the request and will not respond.
contact
public
Contact is the name of the person responsible for this unit.
description
Equalizer
This is the user-assigned description of the Equalizer.
location
location
Location describes Equalizer’s physical location.
name
Equalizer
This is the name assigned to the system. By default it is Equalizer .
server
VLAN IP
To configure the SNMP agent to listen and respond on a particular IP
address, enter the address.
162
This is optional. If not entered, the default trap server port (162) will be
used.
serverport
(optional)
The following tables list the SNMP context commands:
Using SNMP Commands in the Global Context
eqcli > no snmp cmd
: Reset the specified parameter to its default
value
eqcli > show snmp
: Display SNMP parameter settings
eqcli > snmp
: Change to the “snmp" context (see below)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
249
Working in the CLI
SNMP Context Commands
eqcli snmp> community string
: Set the SNMP community address.
eqcli snmp> contact string
: Set the SNMP contact address.
eqcli snmp> description string
: Set the SNMP description
eqcli snmp> location string
: Set the SNMP location.
eqcli snmp> name string
: Set the SNMP name.
eqcli snmp> server server list
: A single trap server or a list of
trap servers in <IP:port> format.
Examples:
server 10.0.0.121:80
server 10.0.0.121,10.0.0.120:162
Note: If 'port' is not specified,
it defaults to 162.
eqcli snmp> show
: Display SNMP parameter
configuration
Downloading Equalizer MIB Files
The MIB files can be downloaded from Equalizer using a browser pointed at:
http://<Equalizer>/eqmanual/<mibname>.my
250
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Tunnel Commands
Use tunnel context commands to configure Equalizer to access the IPv6 Internet via an IPv6
“6in4” tunnel. Note that you must first request a tunnel configuration from a tunnel broker before
setting up the tunnel endpoint on Equalizer. See "IPv6 Tunnel Overview" on page 158 for more
information.
Using Tunnel Commands in the Global Context
eqcli > tunnel tname [cmds]
: Create tunnel tname (see below for cmds)
eqcli > tunnel tname cmds
: Modify tunnel tname (see below for cmds)
eqcli >
no tunnel tname
: Delete tunnel tname
eqcli > show tunnel[tname]
: Display all tunnels or a specific tunnel
eqcli > tunnel tname
: Change to a tunnel context (see below)
Tunnel Context Commands
eqcli tl-tname> *local_address ipv6_addr
: Local IPv6 address from
broker
eqcli tl-tname> *local_endpoint ipv4_addr
: Local IPv4 address
eqcli tl-tname> *remote_address ipv6_addr
: Remote IPv6 address from
broker
eqcli tl-tname>
*remot_endpoint ipv4_addr
: Remote IPv4 address from
broker
eqcli tl-tname> show
: Display tunnel settings
eqcli tl-tname> *type ipip
: Tunnel type (only ipip
supported)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
251
Working in the CLI
User Commands
Using "User" Comands in the Global Context
eqcli > user uname [cmds]
: Create user uname (see below
for cmds)
eqcli > user uname cmds
: Modify user uname (see below
for cmds)
eqcli > no user uname
: Delete user uname
eqcli > show user [uname]
: Display all users or a
specific user
eqcli > user uname
: Change to the "user-login"
context (see below)
"User" Context Comands
eqcli user-uname > alert alert name
: Set a user alert.
eqcli user-uname > duration seconds
: Set the idle login timeout
eqcli user-uname > flags
{[!]admin,
[!]read_global,
[!]write_global
[!]primary}
: Permission Flags:
admin = read/write all objects
& parameters
read_global = read global
parameters
write_global = modify global
parameters
Failover Flag:
primary = When in failover,
controls whether the system
will generate alerts only for
failover groups that are in
primary mode on the system, or
for all failover groups. (See
"User Flags" on page 256 for
additional details)
eqcli user-uname > no duration
: Set default duration (0)
eqcli user-uname > no permit_object perm
type object
: Remove permission on object
eqcli user-uname > no permit_objlist perm
type objlist
: Remove perm from objlist
eqcli user-uname > password
: Change user password
eqcli user-uname > permit_object perm
type object
: Add permission on object
eqcli user-uname > locale
{[!]en,
[!]ja}
252
: To set English locale
: To set Japanese locale
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
"User" Context Comands
eqcli user-uname > show
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
: Display user settings
253
Working in the CLI
User-Alert Context Commands
eqcli > user-uname-alertname > alert_type
alert flags
[!] exception [!] state_change
: Set the alert type. Required.
The alert flags specification
must be enclosed by double
quotes if there are any spaces.
eqcli > user-uname-alertname > from
email-address
: Set the from email address.
eqcli > user-uname-alertname > no smart_
control
: Delete the specified smart
control name(s)
eqcli > user-uname-alertname > notify_
type notify notify flags
: Set the alert notify flags.
Required. The notify flags may
be delimited by ',' or '|'.
[!]email,[!]ui,[!]snmp,[!]syslog,
[!]smartd
WARNING: The notify flags
specification must be enclosed
by double quotes if there are
any spaces.
eqcli > user-uname-alertname > object
fully-qualified object name
: Set the object fully-qualified
object name. Required. The
object name is the name of an
object, existing in the
configuration, for which this
alert definition is to be
applied. The 'fully-qualified
object name' is a semi-colon
delimited list describing the
object hierarchy. For example,
to set an alert for vlan vl01,
subnet sn00, the user would
specify: object vl01:sn00, and
the object_type would be
'subnet'.
For another example, to set an
alert for peer eq-A, F/O Group
fo_group1, the user would
specify:
object eq-A:fo_group1, and the
object_type would be 'fogrp'.
Note: The last object name in
the hierarchy may contain one
or more wildcard (*)
characters. For example, to
configure an alert for all
subnets of vlan vl01, specify:
'object vl01:*' Also, an object
hierchary of 'vl01:sn*1' would
configure alerts for subnets:
sn1, sn01, sn11, etc.
254
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
User-Alert Context Commands
eqcli > user-uname-alertname > object_
type object-type
: Set the object type. Required.
Object type can be server,
cluster, match, srvpool, si,
resp, peer, vlan, subnet,
geocluster, geosite, gsi,
interface, user, certificate,
crl, route, tunel, license,
health_check, hci, vlb_manager,
resource, ri, external_
services, smtp_relay,
fogrp
eqcli > user-uname-alertname > quit
: Discard all pending alert
configuration changes and exit
to the user context.
eqcli > user-uname-alertname > show
: Display the alert details.
eqcli > user-uname-alertname > smart_
control name
: Add one or more smart_control
objects to the alert where
'name' is the name of a single
smart_control name, or a commaseparated list of smart_control
names
eqcli > user-uname-alertname > state
: Set the alert state flag.
enable/disable
eqcli > user-uname-alertname > subject
user string
: Set the subject.
User string is any (up to 256)
characters the user wishes to
enter. It must be surrounded by
quotes if it has embedded
blanks. Its usage depends upon
the notify_type.
eqcli > user-uname-alertname > to to
email addresses
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
: Set the email address(es).
Email addresses are
email1,email2,...emailx, where:
email= user@<domain
255
Working in the CLI
User Alert Notify Type Flags
A flag may be turned off by prefixing with "!".
email
When enabled, sends an email to the specified recipients, using a specified
SMTP relay mail server. When this notification type is used, an email
address is also required. A subject line for the email is optional
ui
When enabled this notifies users of an alert in the CLI.
snmp
When enabled, allows SNMP traps to enable an agent to notify a
management station of significant events by way of unsolicited SNMP
messages.
syslog
When enabled, sends an alert message to the system log
User Flags
User flags are used to override permissions checks, as follows:
Flag
Description
All permissions checks are overridden for the user (including read_global
and write_global). The user has complete administrative control over the
system. Only users with the admin flag can:
admin
read, write, and delete any object on which they do not have explicit
permission
write, create, and delete object lists and user definitions (with the
exception of a user changing their own password)
read_global - User can do a show in the global context.
write_global
User can modify global parameters and execute global commands other than
show in the global context.
read_global
User can read all global parameters.
When in failover, controls whether the system will generate alerts only for
failover groups that are in primary mode on the system, or for all failover groups.
primary
If enabled, alerts for load balancing objects will only be generated for the
associated failover groups that are in "Primary" mode.
If disabled, alerts for load balancing objects will be generated for all failover
groups,regardless of mode.
If not in failover, this flag has no effect.
Setting the Locale
You can set the locale for Equalizer to either English or Japanese (2 available options at this time).
The default locale is “en” for English.
For English enter the following:
256
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
eqcli user-uname> locale en
For Japanese enter the following:
eqcli user-uname> locale ja
Creating a User
When a user name is created:
l
l
A default user (i.e. "touch") is assigned a duration of 0 seconds . When additional users are
created the default duration value is 3600 seconds.
The user creating the new user name is prompted for a password (regardless of whether
they specified the password keyword on the command line).
Deleting a User
The no user command is immediately executed and the user name is removed, with one
exception: if the user name is the only one with the admin flag enabled, the user name is not
removed.
User Passwords
The password command allows a logged in user to change the password for their user name. A
user name with the admin flag can modify the password for any user name. The password itself is
not permitted on the command line, and is not displayed by a user context show command (or any
eqcli command).
User Permissions
When a user attempts to access an object (cluster, server, server pool, VLAN, etc.) on Equalizer,
the system determines whether the user has permission to access the object as follows:
1. If the user’s definition has the admin flag enabled, then access is granted.
2. Otherwise, the user must have specific permission granted on the object for the access
mode being attempted. For example, if the user attempts to display a cluster, then the user
must have read permission on the cluster.
Permission to access an object is granted in one of two ways:
l
l
The permit_object command gives the user the specified access permissions on the
specified object.
The permit_objlist command gives the user access permissions on all objects of a
particular type as listed in the object list specified on the command line.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
257
Working in the CLI
Note - The permit_object and permit_objlist commands:
- can be used only on existing user logins.
- must be entered one at a time, on a line by themselves, with no other user context commands on the command line
So, for example, you cannot modify a user’s duration parameter and in the same command line include a permit_
object or permit_objlist command.
258
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using permit_object to Assign User Permissions on a Single Object
The user context permit_object command has the following syntax:
permit_object perm type object_name
The command assigns the given permission on the given object in the user context. The command
arguments are as follows:
l
l
l
perm - One or more of the following permissions: read, write, delete. Multiple
permissions must be separated by commas. If spaces are included, the entire list of
permissions must be enclosed in quotes.
type - One of the following object types:
cert,cluster,crl,geocluster,geosite,port,server,srvpool,subnet,user,vlan.
object_name - The name of an existing object of the type given on the command line.
For example, the following command executed in the global context assigns read and write
permission to the server sv00 for the existing login user1:
eqcli > user user1 permit_object read,write server sv00
Using permit_objlist to Assign User Permissions on a Group of Objects
The user context permit_objlist command has the following syntax for assigning read, write,
and delete permissions:
permit_objlist perm type objlist_name
This form of the permit_objlist command assigns the given permission (perm) on all objects of
the specified type that appear in the object list specified by objlist_name. The command
arguments for assigning permission to objects in an object list are as follows:
l
l
l
perm - One or more of the following permissions: read, write, delete. Multiple
permissions must be separated by commas. If spaces are included, the entire list of
permissions must be enclosed in quotes.
type - One of the following object types: cert,cluster,
crl,geocluster,geosite,port,server,srvpool,subnet,user,vlan.
objlist_name - The name of an existing object list.
For example, the following command executed in the global context assigns read and write
permission to all of the servers listed in the object list objlist1 for the login user1:
eqcli > user user1 permit_objlist read,write server objlist1
For more information on object lists, please see "Object List Commands" on page 228.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
259
Working in the CLI
Using permit_objlist to Allow a User to Create Objects
The user context permit_objlist command has the following syntax for assigning the create
permission to a user:
permit_objlist create type {default | objlist_name}
l
l
l
l
This form of the permit_objlist command allows the user to create objects of the
specified type. The command arguments for assigning permission to objects in an object
list are as follows:
type - One of the following object types:
cert,cluster,crl,geocluster,geosite,port,server, srvpool,subnet,user,vlan.
default - Specifies that objects created by this user will only be visible to the user creating
the object and any user with the admin flag set.
objlist_name - Specifies that the user can supply the given object list name as an
argument when creating objects of the specified type. An entry for the created object is
placed in the object list. Objects created in this manner will be visible to other users who
have permission to use this object list.
For example, the following command executed in the global context allows user1 to create
servers that other non-admin users cannot access:
eqcli > user user1 permit_objlist create server default
The following command allows user1 to create servers and specify the objlist1 object list when
creating a server, thus adding the new server to objlist1:
eqcli > user user1 permit_objlist create server objlist1
User Permissions Assigned on Object Creation
When an object is created, the user creating the object is given read, write, and delete
permissions for the object.
Displaying User Information
In the user context, a show command displays the user settings for duration and flags, followed
by the user permission list.
260
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
VLAN and Subnet Commands
Using VLAN Commands in the Global Context
eqcli > vlan vlname req_cmds
: Create vlname (req_cmds = *
commands below)
eqcli > vlan vlname cmds
: Modify vlname (cmds = any
commands below)
eqcli > no vlan vlname
: Delete vlname
eqcli > show vlan [vlname]
: Display all VLANs or vlname
eqcli > vlan vlname
: Change to the “vl-vlname”
context (see below)
VLAN Specific Context Commands
eqcli vl-vlname> ifi
: Change to the command context
for the specified interface
instance.
eqcli vl-vlname> show
: Display VLAN configuration
eqcli vl-vlname> subnet subname
: Change to subnet specific
context
eqcli vl-vlname> subnet subname cmd
: Execute subnet specific
command
eqcli vl-vlname> mtu [mtuvalue]
: Set the vlan MTU.
eqcli vl-vlname> *vid integer
: Set VLAN ID.(Value between 1
and 4094)
VLAN Commands in the ifi Context
eqcli vl-vlname-ifi-ifiname > type
: Set the interface instance
vlan type <tagged|untagged>
eqcli vl-vlname-ifi-ifiname > show
: Display the ifi configuration
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
261
Working in the CLI
Using Subnet Commands in the Global Context
eqcli > vlan vlname subnet subname req_cmds
: Create subname (req_cmds = *
commands below)
eqcli > vlan vlname subnet subname cmds
: Modify subname (cmds = any
commands below)
eqcli > no vlan vlname subnet subname
: Delete subname
eqcli > show vlan vlname subnet [subname]
: Display all subnets or
subname
eqcli > vlan vlname subnet subname
: Change to a subnet context.
Subnet Specific Context Commands
eqcli vl-vlname-sn-subname> flags
[!]heartbeat}
: Set subnet flags
eqcli vl-vlname-sn-subname> force
: Force the subnet modification,
ignoring any conflicts.
eqcli vl-vlname-sn-subname> from ip_addr
: Set NAT from IP (with or
without CIDR notation).
eqcli vl-vlname-sn-subname> hb_interval
: Set the heartbeat probe
interval for a subnet.
eqcli vl-vlname-sn-subname> ip
: Set the subnet IP address.
Required.
eqcli vl-vlname-sn-subname> nat
: Add or modify a subnet nat.
eqcli vl-vlname-sn-subname> no parameter
: Delete a route or reset a
subnet parameter to its
default value.
eqcli vl-vlname-sn-subname> no route src
dest
: Remove a route
eqcli vl-vlname-sn-subname> outip_addr
: Set NAT out IP.
eqcli vl-vlname-sn-subname> permit
: Set the list of permitted
subnets on a subnet.
eqcli vl-vlname-sn-subname> route
: Add or modify a subnet route.
eqcli vl-vlname-sn-subname> services
http,[!]https,
[!]ssh, [!]snmp,
[!]envoy, [!]envoy_agent,
[!]fo_http, [!]fo_https,
[!]fo_ssh,[!]fo_snmp,
[!]fo_envoy,[!]fo_envoy_agent}
eqcli vl-vlname-sn-subname> show
262
{!]
: Subnet Services (see below)
: Display subnet
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Subnet Specific Context Commands
eqcli vl-vlname-sn-subname> strike_count
integer
: Set the strike count threshold
for a subnet. When the number
of strikes detected on this
subnet exceeds this value, the
subnet has failed. A value of
0 indicates this subnet will
never be considered failed.
eqcli vl-vlname-sn-subname> virt_addr cidr_
addr
: Set the subnet Failover IP
address.
VLAN Subnet Flags
A flag may be turned off by prefixing with "!".
Flag
Description
heartbeat
Allows the failover peers to probe one another over the subnet. At least one
subnet must have a Heartbeat flag enabled.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
263
Working in the CLI
VLAN Subnet Services
Services may be turned off by prefixing with "!".
Service
Description
http
When enabled, the Equalizer will listen for HTTP connections on Equalizer’s IP
address on the subnet. The global HTTP GUI service must also be enabled.
https
When enabled, the Equalizer will listen for HTTPS connections on Equalizer’s IP
address on the subnet. The global HTTPS GUI service must also be enabled.
ssh
When enabled, SSH login will be permitted on Equalizer’s IP address on the
subnet. The global SSH service must also be enabled.
snmp
When enabled, SNMP will accept connections on Equalizer’s IP address on the
subnet. The global SNMP service must also be enabled.
envoy
When enabled, Envoy will accept DNS lookup connections on Equalizer’s IP
address on the subnet. The global Envoy service must also be enabled.
envoy_agent
When enabled, Envoy health checks will be performed on the subnet using
Equalizer’s IP address on the subnet as the source IP. The global Envoy Agent
service must also be enabled.
fo_http
When enabled, the Equalizer will listen for HTTP connections on Equalizer’s
Failover IP address (if configured) on the subnet. The global HTTP GUI service
must also be enabled.
fo_https
When enabled, the Equalizer will listen for HTTPS connections on Equalizer’s
Failover IP address (if configured) on the subnet. The global HTTPS GUI service
must also be enabled.
fo_ssh
When enabled, SSH login will be permitted on Equalizer’s Failover IP address (if
configured) on the subnet. The global SSH service must also be enabled.
fo_snmp
When enabled, SNMP will accept connections on Equalizer’s Failover IP address
(if configured) on the subnet. The global SNMP service must also be enabled.
fo_envoy
When enabled, Envoy will accept DNS lookup connections on Equalizer’s Failover
IP address (if configured) on the subnet. The global Envoy service must also be
enabled.
fo_envoy_agent
When enabled, Envoy health checks will be performed on the subnet using
Equalizer’s Failover IP address on the subnet as the source IP. The global Envoy
Agent service must also be enabled.
264
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
VLAN and Subnet Command Notes
The vlan context defines Equalizer’s network connectivity. Each VLAN definition defines the front
panel ports that are configured for the VLAN, the VLAN ID (VID), and the subnets that belong to
the VLAN.
VLAN Subnets
A single VLAN can have more than one subnet assigned to it. In most configurations, there is a
one-to-one relationship between VLANs and subnets, but some practical problems are sometimes
solved by adding an additional subnet to a VLAN. For example, if all the IP addresses on the
subnet assigned to a VLAN are exhausted, the easiest way to add more IP addresses without
reconfiguring the network is to add an additional subnet to the VLAN.
VLAN IP Addresses
A VLAN IP address is defined on all subnets in a VLAN and is Equalizer’s IP address on that subnet.
Subnet IP addresses must be specified in CIDR format (e.g. 172.16.0.200/21). A VLAN can contain
multiple subnets with a mix of IPv4 and IPv6 addresses on different subnets in the same VLAN.
VLAN Services
A VLAN can have several services running on it: the GUI can be available on the VLAN IP address
via HTTP and/or HTTPS; and, SSH login on the VLAN IP can be enabled as well. It is not required
that any of these services be enabled on any VLAN.
If services are enabled on the VLAN, they must also be enabled in the global context in order to be
functional on the VLAN. See the services command in "Global Commands" on page 190.
Routing Between VLANs
By default, packets are not routed between VLANs. In other words, if a packet for a destination
address that is configured on vlan2 arrives at a port that is configured for vlan1 only, the packet is
dropped. Routing from vlan1 to vlan2 is configured by adding vlan2 to the list of permitted VLANs for
vlan1.
For example, let’s say port 1 is configured for vlan1 and subnet 10.10.10.0/24; port 2 is configured
for vlan2 and subnet 172.16.0.0/24. If servers are connected to both ports, and these servers need
to communicate with one another through Equalizer, you would execute the following commands
to enable routing between vlan1 and vlan2:
eqcli > vlan vlan1 permit vlan2
eqcli > vlan vlan2 permit vlan1
Using the permit command in the vlan context, as above, enables packet forwarding between all the
subnets defined in the current VLAN context, and the VLAN specified as an argument to permit .
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
265
Working in the CLI
Routing Between Specific VLAN Subnets
In most cases, there is a one-to-one relationship between VLANs and subnets -- i.e., a VLAN in
most configurations is associated with one subnet. There are, however, situations in which an
administrator will associate more than one subnet with a VLAN. If multiple subnets are defined
within a VLAN, you can optionally specify a subnet as an additional argument to the permit
command, as in this example:
eqcli > vlan vlan1 permit vlan2:sn03
The above command enables ports configured for vlan1 to route packets with a destination address
on subnet sn03 defined in vlan2. Packets addressed to other subnets configured on vlan2 will be
dropped.
Similarly, you’ll need to specify the reverse route: let’s say you only want to route packets to
vlan1 from ports configured for vlan2 if they originated on subnet sn03. To accomplish this, you’ll
need to specifically add that VLAN/subnet combination to the permitted VLAN list for vlan2:
eqcli > vlan vlan2 subnet sn03 permit vlan1
Source IP Address for Outbound Packets
When Equalizer originates connections to other hosts (for example, when Equalizer sends out
probes, queries an NTP or DNS server, etc.), the source IP address for outbound packets will be
the source network that was specified in the route configured for the subnet.
Subnet Routes and Global Default Route
Each subnet has a complete routing table. There is no explicit global default route setting that
applies to all subnets. To configure a global default route, you must define the same default route
on all subnets.
266
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 10
Using the GUI
Sections in this chapter include:
Logging In
Navigating Through the Interface
Entering Names for Load Balancing Objects
Using the WebHelp
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
268
269
276
277
267
Using the GUI
Logging In
The Equalizer Administrative Interface, the “GUI”, is a browser based interface. In general, the
GUI should function properly using any browser that is enabled for JavaScript (required). Safari®
for Windows®, however, is not supported.
1. Using your browser, type one of the following into the browser’s address bar:
http://<Equalizer_IP_address>
https://<Load
Balancer_IP_address>
Substitute the load balancer’s IP address on a VLAN subnet that is enabled for HTTP or
HTTPS, as appropriate. (see
Equalizer displays the login screen.
2. Enter an existing login as well as the login password, and click Login. The System
configuration tab on the left pane will be be expanded and the Dashboard screen will be
displayed.
268
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Navigating Through the Interface
The browser-based Administrative Interface (GUI), capable of operating with all commonly used
web browsers, can be used to configure most of Equalizer load balancing and networking
operations. If an operation can only be modified using the command line interface (CLI) it will be
noted in the context of the procedures.
Some of the features and configuration screens may not be available on the following
browsers:
• Internet Explorer (Verified on IE 7, 10 and 11).
• Safari for Windows
The Equalizer GUI features:
A tabbed pane on the left features groups of objects arranged in grouped hierarchical object trees.
These include Equalizer’s System, Load Balance, and Log & Reports features and functions.
System
Clicking on the System configuration tab on the left pane provides access to Global,External Services,
Maintenance, Network, and Failover parameters:
l
l
l
l
Clicking on the arrow (u) next to Global expands the branch and provides access to the
Dashboard, Alert Configuration, Certificate, CRL, IP Reputation, (Global) Parameters, Server Side
Encryption, Smart Control, and SNMP configuration displays on the right pane.
Clicking on the arrow (u) next to External Services expands the branch and provides access to
SMTP Relay and VLB Manager configuration displays on the right pane.
Clicking on the arrow (u) next to Maintenance expands the branch and provides access to
system Date & Time, Backup & Restore, Licensing, Manage Software (upgrade), and system Tools
displays on the right pane.
Clicking on the arrow (u) next to Network expands the branch and provides access to
Interfaces,(Link) Aggregation, VLANs, and Tunnels displays on the right pane.
o
Clicking on each VLAN will display the Number of Subnets, VID, and MTU as well
as the Interface Ports currently being used.
o
Clicking on the arrow (u) for each VLAN expands the branch to display the
configured subnets.
o
Click on each subnet to display the subnet configuration for each.
o
Right-clicking on the VLAN label displays the Add VLAN command.
o
Clicking on the arrow (u) beside Tunnels displays all of the defined IPv6 tunnels.
o
Clicking on each Tunnel displays the Tunnel Configuration display on the right
pane.
o
Right-clicking on the Tunnel label displays the Add Tunnel command.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
269
Using the GUI
l
Clicking on the arrow (u) next to Failover expands the branch and displays the Peer > Summary
screen on the right pane which displays failover status as well as a tab that displays VLAN
subnet heartbeating status. Clicking each peer in the expanded branch will display each
Peer’s configuration display on the right pane. Right-clicking on Peers displays the Add New
Failover Peer command.
Load Balance
Clicking on the Load Balance configuration tab on the left pane provides access to Equalizer’s load
balancing objects and their parameters:
Clusters
l
l
l
Clicking on the Clusters label displays the Cluster Summary screen that features an
configuration tab listing of all configured clusters on the right pane. Clicking the plus sign
(+) next to a cluster name displays summary information about the cluster including
connection information for L4 clusters and connection and transaction information for L7
clusters.
Clicking on the arrow (u) expands the branch to display all configured clusters. Click on
each cluster and the Configuration > Summary screens are displayed on the right pane.
Right-clicking on the Cluster label displays the Add Cluster command.
Server Pools
l
l
l
l
Clicking on the Server Pools label displays the Server Pool Summary screen that features an
configuration tab listing of the configured server pools and their status. Double clicking the
a server pool name opens a list of the currently defined server pools and status.
Clicking on the arrow (u) expands the branch to display all configured server pools. Click on
each server pool and the configuration displays are available on the right pane.
Clicking on the arrow (u) for each Server Pool expands the branch to display all configured
server instances. Click on each server instance to display the Server Instance Configuration
Summary display on the right pane that displays active connection information as well as
parameters and a graphical display of Server Pool traffic from the previous thirty minutes.
Right-clicking on the Server Pool label displays the Add Server Pool command.
Servers
l
l
l
270
Clicking on the arrow (u) expands the branch to display all configured servers. Click on each
server and the configuration displays are available on the right pane.
Click on each server to display the Server Configuration Summary screen that displays active
connection information as well as parameters and a graphical display of Server traffic from
the previous thirty minutes.
Right-clicking on the Server label displays the Add Server command.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Health Checks
l
l
Clicking on the arrow (u) expands the branch to display all configured health checks. Click
on each health check and the configuration displays are available on the right pane.
Click on each health check to display the Configuration Settings screen that displays
parameters that displays the configured parameters and timers as well as a Disable option.
l
Right-clicking on the Health Checkslabel displays the Add Health Check command.
l
Right-clicking on each health check displays the Delete Health Check command.
Responders
l
Clicking on the arrow (u) expands this branch to display all of the configured Responders.
l
Right-clicking on the Responders label displays the Add Responder command.
Link Load Balance
Clicking on the Link Load Balance configuration tab provides access to the Outbound and Inbound Link
Load Balancing configuration screens on the right pane.
Outbound
l
l
l
Clicking on the arrow (u) beside Outbound expands the branch to display Gateways and Groups.
Clicking on Gateways displays the list of configured Link Load Balancing Gateways on the right
pane.
Clicking on Groups displays the list of Outbound Link Load Balancing Groups on the right pane.
Inbound
l
Clicking on the arrow (u) beside Inbound expands the branch to display the list of Inbound Link
Load Balancing Groups.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
271
Using the GUI
Global Load Balance
Clicking on the Global Load Balance configuration tab provides access to the Envoy geographic load
balancing feature parameters and access to FortiDirector GSLB statistsics:
Envoy GSLB
GeoClusters
l
l
l
l
Clicking on the arrow (u) expands this branch to display all of the configured
GeoClusters.
Right-clicking on the GeoCluster label displays the Add GeoCluster command.
Clicking on the arrow (u) beside GeoClusters expands the branch to display all of
the defined GeoSite Instances for the GeoCluster.
Right-clicking on each defined GeoCluster displays the Add GeoSite Instance
command.
GeoSites
l
l
l
l
l
Clicking on the arrow (u) expands this branch to display all of the configured
GeoSites.
Clicking on each GeoSite displays the GeoSite Configuration screen on the right
pane.
Clicking on the arrow (u) beside each GeoSite expands this branch to display all
of the configured GeoSite Resources.
Right-clicking on any GeoSite label displays the Add GeoSite Resource command.
Clicking on each GeoSite Resource displays the GeoSite Resource Configuration
Required screen on the right pane.
FortiDirector GSLB
l
l
l
272
Clicking on the arrow (u) expands this branch to display either the Log In
command or the Usage Information command (if you have previously logged on to
FortiDirector).
Clicking on the Log In command will display the FortiDirector Login page on the
right.
Clicking on the Usage Information command will display HTTP and DNS redirect
statistics on the right.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Protection
Clicking on the Protectionconfiguration tab on the left pane provides access to DDoS, IP Reputation,
and Access Control Lists, configuration screens:
DDoS
l
l
l
l
Clicking on the arrow (u) beside DDoS expands this branch to display Global SPP and Cluster
SPP (Service Protection Profiles).
Clicking on DDoS displays the DDoS Summary display on the right. This is a display of the
configured SPPs and their status.
Clicking on Global SPP displays the Configuration Summary on the right. This shows the
Operational Mode and Threshold settings. Clicking on the Reporting tab will display a graphical
plot of traffic statistics for traffic passing through the network on which the appliance
resides.
Clicking on Cluster SPP displays the Cluster SPP Summary on the right. This is a display of the
configured Cluster SPPs and a summary of activity. Clicking on any of the configured SPPs
on the branch will display the Configuration Summary on the right that displays the Operational
Mode and Threshold setttings for traffic statistics of traffic passing through the cluster to
which the SPP is attached. Clicking on the Reporting tab will display a graphical plot of traffic
statistics passing through the cluster.
IP Reputation
l
Clicking on IP Reputation displays the IP Reputation tab (used for database refresh), the
Inbound Blocking tab (used for turning IP Reputation on or off and to allow or block categories)
and the Statistics tab (used to display the blocked IP addresses) on the right.
Access Control Lists
l
Clicking on Access Control Lists displays the list of whitelisted and blacklisted IP addresses on
the right.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
273
Using the GUI
Log & Reports
Clicking on the Log & Reports configuration tab provides access to Equalizer’s Event Log and Remote
Sys log and CPU & Memory usage displays:
Logging
l
l
l
l
l
l
Clicking on the arrow (u) beside Logging expands the branch to display Event Log, System Log,
Audit Log, Upgrade Log, and Remote System Log.
Clicking Event Log displays events for each element configured on Equalizer on the right
pane. This includes Clusters, Server Pools, Servers and Responders.
Clicking on System Log display all events.
Clicking on Audit Log displays the contents of the audit log showing all user activity
performed on the appliance.
Clicking on Upgrade log display the contents of the upgrade log with upgrade details of
previous software upgrades on your appliance.
Clicking Remote Syslog displays the Remote Syslog screen on the right pane. It allows you to
specify a remote Syslog Server and to enable the logging of events for this remote host.
Reporting
l
l
l
274
Clicking on the arrow (u) beside Reporting expands the branch to access CPU & Memory and
Alert Notification displays.
Clicking CPU & Memory displays the current and 60-minute averages of CPU Consumption
percentage and Memory Utilization in Mb on the right pane
Clicking on Alert Notification displays a list of all of the alerts that have been generated.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Help Buttons/Options
Log Out
Logs you out of the GUI.
Help
Displays a sub-menu of commands
About
Opens the Welcome screen (also displayed when you first log into the GUI).
Context Help
Displays the section in the Help that corresponds to the screen currently displayed in
the right frame.
Refresh
Refeshes the GUI screen.
Management Tabs/Dialogue Area
The right hand side of the GUI initially displays the Welcome screen however it is designed to
display all configuration, management and dialogue associated with the objects in the left
navigational pane.
Click on any item in the left pane, or right click to choose a command for that object. The right
pane will display the management details for the object or the appropriate command dialog.
The easy-to-use management tabs organize configuration information into forms and tables that
make configuring Equalizer simple.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
275
Using the GUI
Entering Names for Load Balancing Objects
Equalizer identifies administrative objects, such as clusters and servers, by name. For example,
object names and icons are displayed in a hierarchy in the GUIs left frame as described earlier in
this chapter. Keep in mind the following guidelines when typing in a name for an object:
l
l
The first character in a name must be a letter.
l
Names can be at most 47 characters long.
l
276
The characters used in names are limited to standard ASCII letters ("A" through "Z" and "a"
through "z"), numbers (0 through 9), and the characters "." (period), "-" (dash) and "_"
(underscore).
The readability of lists presented in the interface is increased by using short names that use
as many unique characters at the beginning of the name as possible.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the WebHelp
Installed on your Equalizer is an HTML-based WebHelp system that is fully functional in all web
browsers. It provides descriptions of how to manage EQ/OS 10 through the Command Line
Interface (CLI) and the Graphical User Interface (GUI).
The PDF file of the Equalizer Administration Guide is still available for download from the EQ OS
10 Support Page. It is synchronized with the same revision as the WebHelp and contains the same
information.
The Equalizer GUI features context-sensitive help. When you click on the Help button and select
Context Help, or simply press F1 on your keyboard, this WebHelp system will be activated in a new
browser window. If you are currently browsing an Equalizer configuration screen and select
Context Help or press F1, the help topic associated with the configuration screen will be displayed.
The following is an overall description of the WebHelp workspace and instructions for its use.
Table of Contents
Select the Table of Contents configuration tab to display of Table of Context. Click on the
expand each branch.
icon to
Breadcrumb Trail
Displays a "trail of breadcrumbs" composed of the table of contents (Table of Contents) entries
above the current topic in the Table of Contents hierarchy.
Search Open Topic
This text entry box is where you can enter a search term to search the open topic for specific
details. Click on
after you have entered a search term.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
277
Using the GUI
Toolbar
The toolbar contains buttons for quick navigation, display options, topic printing, highlighting and
a search area. Enter a search term in this box and the open topic will be searched. If the search
yields results, they will be highlighted on the page.
l
l
Click on
after you have entered a Topic Search item in the search box.
Click on
if you would like to remove the search highlighting after you have used the
search feature
l
Click on
or
to navigate to the previous or next topic of a viewing sequence.
l
Click on
to return to the WebHelp home page.
l
Click on
or
l
Click on
to hide the navigation panel on the left.
l
Click on
or
l
Click on
to print the selected topic.
to navigate to the previous or next topic in the Table of Contents.
to collapse or expand to topic branches in the Table of Contents.
Help Topic Display
This is the area where the selected topic's content is displayed.
Glossary
Select the Glossary configuration tab to access a glossary of load balancing and Equalizer-specific
terminology. Click on each term to display a definition.
Search All Topics
Click on the Search All Topics configuration tab to open a Search pane. Enter a term in the at the top
of the pane and click on Search. A list of results from the entire WebHelp system will be displayed.
Click on each item in the list to navigate to the applicable topic in the WebHelp. All of the found
terms will be highlighted.
278
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 11
System Settings
Sections in this chapter include:
Global Settings
External Services
Maintenance
Failover
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
280
297
300
315
279
System Settings
Global Settings
The Global grouping of parameters is available within the System configuration tab. After logging
into the GUI, Click on the System configuration tab which should be open by default. Then click on
the arrow (►) beside Global to expand the branch. The parameters that can be
viewed/added/modified on this branch include:
1. Dashboard
2. Alert Configuration
3. Certificate
4. CRL
5. Parameters
6. Server Side Encryption
7. Smart Control
8. SNMP
When you select each item a different displayed will be visible in the right frame of the GUI.
Refer to "Global Parameters" on page 183 and "Global Commands" on page 190 for Global
Parameter details using the CLI.
280
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Dashboard
The Dashboard is the initial screen displayed after logging in to the GUI. If it is not displayed you
can also access it by clicking on the System configuration tab on the right navigational pane and
then the arrow (u) beside Global to expand the branch. When you click on Dashboard it will be
display on the right frame.
The Dashboard contains expandable/collapsible tabs/widgets that can be removed from the
display if desired.
By default, all of the widgets are expanded. Click on q in the upper right corner of each tab to
expand or collapse the tab. Click on the X to remove the tab from the Dashboard.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
281
System Settings
Virtual Server Summary
Displays a summary of the configured servers on the appliance as well as
their availability and the associated server pools.
Event Log Console
Displays events for each element configured on the Equalizer. This
includes Clusters, Server Pools, Servers, Peers, and Responders.
Most CLI functions can be performed at this console .
Note: At this time, the following commands are not available with this
Dashboard widget:
CLI Console
show boot
boot boot options
hidden reset config
hidden reset keep-license
hidden show config
hidden shell
hidden shell admin
hidden eqcollect url url [name name]
hidden eqcollect local
backup url url
restore url url name name
show sbr
show files
no files filename
cfg_convert file file name [outfile
outfile name]
certificate cert name certfile edit
certificate cert name keyfile edit
resp resp name html edit
files edit
upgrade upgrade path
files download
files ftp
certfile url
keyfile url
show log eq [[reverse] [lines number of
lines]]
show log sys [[reverse] [lines number of
lines]]
hidden show log dbg [[reverse] [lines
number of lines]]
Note: You cannot enter into sub-contexts from this widget. Only global
context is available. Commands must be entered in a single line.
282
License Information
Displays Firmware Version used, the System Type you are using, the
Serial Number of the appliance, and specific features on the appliance
such as Software-based SSL or hardware-based SSL
Virtual Server network
Throughput
A visual display of the appliance throughput showing Active
Connections, Connections/second and Transactions/second.This
monitors the configured clusters. The drop down list selects the cluster to
monitor.
System Resources
Displays CPU Consumption and Memory Utilization data. It displays
maximums and the averages for the previous 60 minutes in addition to the
real time traffic currently moving through the appliance.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Alerts
Refer to "Configuring Alerts" on page 880 for a description of alerts and setups.
Certificates
Each SSL certificate installed on Equalizer includes a certificate and its associated private key.
In SSL offloading, Equalizer terminates the SSL connection with the client, decrypts the client
request using a certificate and key, sends the request onto the appropriate server, and encrypts
the server response before forwarding it on to the client.
Certificates are uploaded to Equalizer and then associated with one or more clusters. Two types of
certificates may be used to authenticate HTTPS cluster connections:
l
l
A cluster certificate is required to authenticate the cluster to the client and to decrypt the
client request (these are also called server certificates). For cluster certificates, both a
certificate file and a private key file must be uploaded to Equalizer.
A cluster may also be configured to ask for, or require, a client certificate -- a certificate
used to authenticate the client to Equalizer. For client certificates, only a certificate file is
uploaded to Equalizer (no keyfile is used).
Installing an SSL Certificate using the GUI
1. Click on the host name at the top of the left navigational pane and then click on Global
Certificates to display the following.
2. Click on Add Certificate to display the Add Certificate dialogue form .
3. Click on Choose File to select a locally stored Certificate File. Repeat the same for adding a
locally stored Key File.
4. Click on Commit to save the upload the new Certificate File and Key File.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
283
System Settings
Installing an SSL Certificate using the CLI
Refer to "Certificate Commands" on page 194 for Certificate commands.
1. Create a certificate using the certificate command as follows:
eqcli > certificate certname
eqcli: 12000287: Operation successful
eqcli >
where:
certname - is the name of the certificate.
2. Add a locally stored certificate file and key file.
3.
Commit to upload the new Certificate File and Key File.
Deleting a Certificate in Use
If you attempt to delete a certificate that is in use, an error will occur. You can, however use the
force command, to remove the certificate and revert to a system certificate (server.crt) which
is shipped with systems and cannot be deleted. This will prevent losing connectivity with the GUI.
Use the force command as follows:
eqcli > no certificate certname force
eqcli: 12000287: Operation successful
284
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Replacing the Default Certificate, Key, and Cipherspec
Using Equalizer's Remote Management commands in the CLI, you can replace the default
certificate, key, and cipher spec that are used with HTTPS services on subnets with custom
certificates, keys and cipher specs.
The process includes:
l
Uploading the custom certificate and key file to the file store.
l
Entering the certificate (and key file) to be used with HTTPS services.
l
Replacing the default cipherspec with the a custom cipher spec.
l
Setting the encryption level to use in the communications between the client and the ADC.
Uploading the Custom Certificate and Key File
Enter the following to upload a certificate and key file:
1. Enter the name of the new certificate and upload it as follows:
eqcli > certificate certificatename certfile URL
where URL downloads the certfile using ftp:// or http:// protocol.
2. Upload the new key file. The key file must have the same name as the certificate.
eqcli > certificate certificatename keyfile URL
where URL downloads the keyfile using ftp:// or http:// protocol.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
285
System Settings
Entering the Certificate and Key file to be Used with HTTPS Services
3. Set the certfile and keyfile to use using the CLI remote management commands. The
keyfile has the same name as the certfile and will be used automatically.
eqcli remote-mgmt certificate certificatename
4. Now view the remote management configuration. The example that follows shows that the
custom certificate has been added:
eqcli > show remote-mgmt
Options
Cipherspec
Certificate
Protocols
Value
AES128-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:AES256-SHA:!SSLv2
custom certificate
tls10
eqcli >
Replacing the Default Cipherspec with a Custom Cipherspec
5. Enter the custom cipherspec as follows:
eqcli > remote-mgmt cipherspec cipherspec
where cipherspec is the new, custom cipherspec to be used.
Setting the Encryption Levels
6. Configure the encryption levels that will be used in communications between the client and
the ADC. The default encryption level is TLSv1.0 (tls10).
eqcli > protocol protocol
where protocol can be sslv3, tls10(default), tls11, or tls12. The protocols in
the syntax can be delimited by "," or "|".
You can also turn off one of the protocols in the list by prefixing with "!". For example
if you have configured all of the encryption levels to be used and want to remove
tls12, enter eqcli > protocol !tls12. tls12 would then be removed from the
list. The client and ADP will use the highest level available when multiple formats are
specified.
286
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Reapplying the Default Certificate, Cipherspec and Protocols
To reapply the defaults for Cipherspec, Certificate or Protocol, enter any of the following:
eqcli > no remote-mgmt {cipherspec|certificate|protocol}
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
287
System Settings
Certificate Revocation Lists
The Certificate Revocation List (CRL) can be used to verify that the certificates used are valid and
have not been compromised. A CRL is uploaded to and then associated with one or more clusters
in the cluster specific context. Whenever a certificate is used to authenticate a connection to the
cluster, the CRL is checked to make sure the certificate being used has not been revoked.
Equalizer provides support for Certificate Revocation Lists (CRLs) using a central CRL store to
which CRLs can be uploaded and then associated with as many clusters as required.
If a CRL attached to a cluster was generated by a Certificate Authority (CA) different from
the CA used to generate a client certificate presented when connecting to the cluster, an
error will occur, The CRL and client certificate must be signed by the same CA.
Installed CRLs will be displayed in an accordion style list. Click on each list item to expand it and
display the contents of the CRL.
Installing a CRL using the GUI
1. Click on the host name at the top of the left navigational pane and then click on Global CRL
to display the following.
2. Click on Add CRL to display the Add CRL dialogue screen.
288
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
3. Click on Choose File to select a CRL file to upload to Equalizer. Select a *.crl file to upload,
enter a Name, and then click on Commit . A confirmation screen will appear as follows:
Click on Commit if the CRL is the one you would like to upload to Equalizer. The CRL file
will be uploaded to Equalizer and will appear on the Global > CRL screen as shown
above.
Installing a CRL using the CLI
Refer to "Certificate Revocation List Commands" on page 197 for details on using the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
289
System Settings
Parameters
1. Click on the System configuration tab.
2. Click on the arrow (►) beside Global to expand the branch.
3. Click on Parameters to display the Global Parameters screen on the right frame.
The following Global Parameters are configured on this screen (tab). Click on Commit to save your
parameters or Reset to return the default values.
Hostname
This is Equalizer’s host name (default: ).
Locale
Sets the Equalizer locale. en to set English locale. ja to set
Japanese locale.
Firewall Rules
Enable/Disable
This is Enabled by default. If Disable is selected Any Permit
and Deny selections on subnets in your configuration will be
ignored. Refer to "IP Filter Rules" on page 154 for
additional information.
DNS Section
Domain Name Server
(Primary, Secondary, or
Tertiary)
If using a Domain Name Server, the Domain Name Server Equalizer will
use.
Global Service Settings Flags
The permitted VLAN services are HTTP, HTTPS, SNMP, SSH are set globally, here. Use the check
boxes to enable.
290
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Side Encryption
Server Side Encryption (SSE) provides the ability to configure a cluster, server, or match rule so
that traffic between the Equalizer and servers is encrypted using SSL/TLS.
Refer to "Server Side Encryption" on page 379 for a description of configuring SSE using the GUI
and the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
291
System Settings
Smart Control
The Smart Control feature allows you to define a common administrative function or, Smart Event
that executes the function based on pre-set threshold values for system parameters and
statistics. It is a method for administrators to configure the system to automatically perform
functions that may be dependent on threshold values or timing.
Refer to "Smart Control Overview" on page 844 for complete descriptions of this function.
292
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
SNMP
The Simple Network Management Protocol (SNMP) is an internet standard that allows a
management station to monitor the status of a device over the network. SNMP organizes
information about the Equalizer and provides a standard way to help gather that information.
Using SNMP requires:
l
l
l
An SNMP agent running on the system to be monitored.
A Management information Base (MIB) database on the system to be monitored.
An SNMP management station running on the same or another system.
An SNMP agent and MIB databases are provided for SNMPv1 and SNMPv2c. If using a MIB
browser, use SNMPv2c to ensure returned statistics.
A management station is not provided with Equalizer and must be obtained from a third party
supplier. The management station is often used primarily to browse through the MIB tree, and so
is sometimes called a MIB browser. One such management station that is available in a free
personal edition is the iReasoning MIB Browser, available from www.ireasoning.com.
A MIB database is a hierarchical tree of variables whose values describe the state of the
monitored device. A management station that want to browse the MIB database on a device sends
a request to the SNMP agent running on the device. The agent queries the MIB database for the
variables requested by the management station, and then sends a reply to the management
station.
With SNMP, you can monitor the following information from the Equalizer MIBs:
Static configuration information, such as:
l
l
l
l
l
Device name and Model
Software version
Internal and External IP addresses and netmasks
Default gateway
Failover alias
Equalizer failover details
l
l
Sibling Name
Sibling Status (Primary or Secondary)
Dynamic configuration information, such as:
l
l
l
l
l
l
l
l
l
l
l
Failover Status (Primary or Secondary)
NAT enabled
L4 configuration state
L7 configuration state
Server Health check status
Email status notification
Cluster parameters (timeouts, buffers)
Server parameters Equalizer status
L4 Statistics
L7 Statistics Equalizer cluster
L4 or L7 protocol of cluster
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
293
System Settings
l
l
l
l
Load balancing policy for cluster
IP address and port (or range)
Sticky time and inter cluster sticky
Cookie On or Off
By default, SNMP is a globally enabled service -- meaning that it will run on any subnet that is
configured to offer the SNMP service. You must specifically enable SNMP on the subnet or subnets
on which you want it to listen for SNMP MIB browser and management station connections.
SNMP Parameters using the GUI
SNMP parameters are displayed on the GUI by clicking on the System configuration tab on the left
navigational pane and then selecting Global to expand the branch. Click on SNMP to display the
following:
The parameters are as follows:
System Name - this is the name assigned to the system.
Community String - Any SNMP management console needs to send the correct
community string along with all SNMP requests. If the sent community string is not
correct, Equalizer discards the request and will not respond.
System Contact - Contact is the name of the person responsible for this unit.
System Location - Location describes Equalizer’s physical location.
System Descriptions - this is the user-assigned description of Equalizer.
Click on Commit to save your changes.
SNMP Parameters using the CLI
Refer to "SNMP Commands" on page 249 for details.
294
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
MIB Compliance
EQ/OS 10 fully supports these proprietary Equalizer MIBs:
l
CPS-EQUALIZER-v10-MIB
l
CPS-REGISTRATIONS-v10-MIB
Note - In Equalizer EQ/OS 8.6 the names of the MIBs were CPS-REGISTRATIONS-MIB and CPS-Equalizer-MIB; their
filenames were cpsreg.my and cpsequal.my, respectively. Substantial changes were made to the MIBs for EQ/OS 10.
Therefore, the MIB names and filenames are changed for EQ/OS 10. EQ/OS 8.6 MIBS will not work with EQ/OS 10 MIBS.
EQ/OS 10 provides partial support for these standard MIBs:
RFC1213-MIB (RFC1213)
System
Interfaces
tcp: tcpInSegs, tcpOutSegs, tcpRetransSegs,
tcpInErrs, tcpOutRsts; and tcpConnTable
udp
IP: ipForwarding, ipDefaultTTL, ipInReceives,
ipInHdrErrors, ipInAddrErrors, ipForwDatagrams,
ipInUnknownProtos, ipInDiscards, ipInDelivers,
ipOutRequests, ipOutDiscards, ipOutNoRoutes,
ipReasmReqds, ipReasmOKs, ipReasmFails,
ipFragOKs, ipFragFails, ipFragCreates; ipAddrTable
and ipNetToMediaTable
icmp
snmp
The remaining objects are not supported
HOST-RESOURCES-MIB (RFC2790)
hrSystemUptime
hrProcessorLoad
hrSystemDate
hrNetworkTable
hrStorage
The remaining objects are not supported.
hrDeviceTable
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
295
System Settings
MIB Files
MIBs are included with your appliance and updated when the firmware is updated. It is
recommended that you update your SNMP Management station (MIB Browser) after updating
the firmware to insure that you are browsing the current MIB tree.
All MIBs referenced by the supported MIBs are included on Equalizer.
The MIB filenames comprise the MIB name plus the filename extension ”.my”:
CPS-EQUALIZER-v10-MIB.my
CPS-REGISTRATIONS-v10-MIB.my
HOST-RESOURCES-MIB.my
HOST-RESOURCES-TYPES.my
IANAifType-MIB.my
IF-MIB.my
INET-ADDRESS-MIB.my
IP-MIB.my
RFC1155-SMI.my
RFC1213-MIB.my
SNMPv2-CONF.my
SNMPv2-MIB.my
SNMPv2-SMI.my
SNMPv2-TC.my
TCP-MIB.my
UDP-MIB.my
The MIB files can be downloaded from Equalizer using a browser pointed at:
http://<Equalizer>/eqmanual/<mibname>.my
296
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
External Services
SMTP Relay
SMTP Relays are commonly used when you want to configure email alerts.
With email alerts, you be adding email addresses to the alert. Refer to "Configuring an SMTP
Relay" on page 901 for additional information.
VLB Manager
In order to obtain VMware virtual machine information, Equalizer needs access information for
the vCenter console (or ESX server) managing the virtual machines. To enable communication
between Equalizer and a vCenter console, External Services VLB Manager configuration is required.
Parameters
VLB Managers are configured using the parameters described in the VLB Manager Parameters
table below.
VLB Manager Parameters
GUI Parameters (CLI Parameter)
Description
VLB Manager Name (name)
A name for the VLB Manager. This can be up to 51 ASCII
characters that includes: letters, numbers, period (.),
dash (-), asterisk (*), collon (:), "at" sign (@), or
underscore (_).
VLB Manager URL (URL)
The URL configured on the system running vCenter (or on
an ESX Server) for VMware API connections. By default,
this is an https:// URL using the IP address of the vCenter
system followed by /sdk, as in:
https://192.168.1.50/sdk
The VLB Manager URL parameter cannot contain (or
resolve to) an IPv6 address. Only an IPv4 address can be
used.
Username (username)
The VMware user account that you normally use to log
into the vCenter or ESX Server that manages your VMware
configuration.
Password (password)
The password for your VMware user account. (Note that
this text box is blank when you open the tab, even if a
password has been previously saved.)
Flags
Enable/Disable
(enable/disable)
When enabled, this allows Equalizer to communicate with
virtual machines and to log into VMware automatically and
enable virtual machines in clusters. If the Disable option
is selected, no connections to Virtual Center will be made.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
297
System Settings
VLB Manager using the GUI
Create a VLB Manager as an External Service as follows:
1. Log in to the GUI.
2. Select System > External Services > VLB Manager.
3. Click on the "+" sign on the right configuration pane to add a new VLB Manager. The Add VLB
Manager screen is used to set up communication login credentials to VMware using saved
configurations that allow easy communication between Equalizer and VMware.
4. Configure the parameters as described in the "VLB Manager" on page 297 table above.
5. Click on Commit to save the new VLB Manager. The new VLB Manager will appear on the right
configuration pane list. You can edit it by double-clicking it.
298
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
VLB Manager using the CLI
Create a VLB Manager as an External Service as follows:
1. Log in to the CLI.
2. A VLB Manager is a saved configuration by which Equalizer communicates with VMware.
Enter the following at the eqcli command prompt to create a VLB Manager as an External
Service:
eqcli > ext_services vlb_manager <name>
where:
name - is the name of the vlb manager
3. Enter the new VLB Manager, adding a URL, username, password, Connect Timeout
parameters and flags. Enter:
eqcli
eqcli
eqcli
eqcli
xs
xs
xs
xs
vlb-nam*
vlb-nam*
vlb-nam*
vlb-nam*
>
>
>
>
URL value
username name
password name
flags disablea
a. The only flag used is disable which would disable the VLB Manager if necessary.
eqcli
eqcli
eqcli
eqcli
xs
xs
xs
xs
vlb-nam*
vlb-nam*
vlb-nam*
vlb-nam*
>
>
>
>
URL value
username name
password name
flags disablea
a. The only flag used is disable which would disable the VLB Manager if necessary.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
299
System Settings
Maintenance
The Maintenance screen (tab) allows you to access the sections in the related topics.
Date and Time
Setting Data and Time using the GUI
The System time setting screen is used to manually enter the current system date and time. This
is accessed by selecting Equalizer on the left navigational pane and selecting the Maintenance (tab)
and then selecting Date & Time to display the following.
Set Time Zone
Use the Time Zone drop down list to set the Time Zone. Click on Commit to save the settings. Click
on Reset to reset all the newly entered values to the previous values.
Manually Set Date and Time
Enter the current date and time in the Date field in the format: mm/dd/yyyy hh:mm:ss Click on
Commit to save the settings.Click on Reset to reset all the newly entered values to the previous
values.
Automatically Set Date and Time
Network Time Protocol (NTP) is a protocol and software implementation for synchronizing the
clocks of computer systems. It provides Coordinated Universal Time (UTC) including scheduled
leap second adjustments and will be used to synchronize the clock in Equalizer. Select the Enable
NTP Synchronization option to enable this feature. Click on Commit to save the settings.
Refer to Selecting an NTP Server for additional information about the NTP servers.
300
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Setting Date and Time using the CLI
Refer to "Global Commands" on page 190 to set up date and time using the CLI.
Enabling DNS
To enable the Domain Name Service (DNS), add a name server to the configuration. Name
servers are added to the name-server list one at a time, with a maximum of three name servers
in the list (Primary, Secondary, Tertiary). The following table shows you how to perform DNS
tasks using the CLI and the GUI:
Task
Command / Procedure
Add a DNS
server
Remove an
DNS server
Remove all
DNS servers
CLI
12eqcli > name-server [primary|secondary|tertiary]ip-address
GUI
See "Parameters"
CLI
eqcli > no name-server ip-address
GUI
See "Parameters"
CLI
eqcli > no name-server
GUI
See "Parameters"
CLI
eqcli > no name-server
GUI
See "Parameters"
CLI
eqcli > show
GUI
See "Parameters"
on page 290
on page 290
on page 290
Disable DNS
Display DNS
servers
on page 290
on page 290
1 The IP addresses of the primary, secondary, and tertiary name-servers can be added on the same line in CLI syntax. For
example:
eqcli
>
name-server primary ip secondary ip tertiary ip
2Note that removing all the servers from the name server list disables DNS.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
301
System Settings
Configuring NTP
Network Time Protocol, or NTP is a protocol designed to synchronize the clocks of computers over
a network. NTP on Equalizer is compatible with servers running versions 1, 2, 3, or 4 of the NTP
protocol. An RFC for NTPv4 has not been written; NTPv3 is described in RFC 1305.
On Equalizer, NTP is used primarily to time various operations, to ensure accurate timestamps on
log entries (with respect to server and client log timing), and to allow for examination of the
timing of log entries on two Equalizers in a failover configuration.
NTP on Equalizer works by polling an NTP server defined through the GUI. The time between polls
of the NTP server is controlled by the minpoll and maxpoll NTP parameters, which default to 64
seconds (1 min 4 sec) and 1024 seconds (~17 mins), respectively. The behavior of NTP is to poll
with a frequency starting at minpoll and then decrease polling frequency over time to maxpoll,
as the accuracy of the local clock approaches the accuracy of the remote server clock. The time it
takes for the polling delay to increase from minpoll to maxpoll will vary based on a number of
factors, including the accuracy of the clocks on the client and server, network latency, and other
timing factors.
NTP calculates when the local and remote system clocks are sufficiently in sync to begin
increasing the polling delay towards maxpoll. When the accuracy of the two clocks is significantly
different, or there is significant latency, for example, the two clocks may never be in sufficient
agreement to increase the delay towards maxpoll. In this case, Equalizer will continue to sync
approximately every 64 seconds. This behavior indicates that a different NTP server should be
chosen.
NTP packets are very small and should not cause any problems with Equalizer or network
operation, except as described in the following section on NTP and plotting.
NTP and Plotting
When you initially configure NTP, this may effectively disable plotting until NTP completes the
initial synchronization of Equalizer’s system clock with the NTP server -- which may take from
several hours to several days. This is because plotting depends on accurate timestamps in the plot
log. Since initially NTP is adjusting the time at frequent intervals, the timestamps in the plot log
may become out of sync with the system clock, and so no plot data may be returned. Once NTP is
no longer making adjustments to the system clock, plotting will function normally.
Default NTP Configuration
Equalizer is delivered with a default Network Time Protocol (NTP) configuration: the NTP daemon
(ntpd) is enabled by default and the NTP server is set to pool.ntp.org. However, NTP will not be
able to synchronize time with an NTP server until DNS is configured and working.
Rather than point at a single NTP server, most organizations use an NTP server pool defined by
the NTP Pool Project.
302
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Selecting an NTP Server
We recommend that you specify NTP pool servers appropriate for your geographic location.
Selecting a pool server means that you are specifying an alias that is assigned by the NTP Pool
Project to a list of time servers for a region. Thus, NTP pool servers are specified by geography.
The following table shows the naming convention for servers specified by continent:
Worldwide - pool.ntp.org
Asia - asia.pool.ntp.org
Europe - europe.pool.ntp.org
North America - north-america.pool.ntp.org
Oceania - oceania.pool.ntp.org
South America - south-america.pool.ntp.org
To use the continent-based NTP pool servers for Europe, for example, you could specify the
following pool servers in Equalizer’s time Configuration screen (tab):
0.europe.pool.ntp.org
1.europe.pool.ntp.org
2.europe.pool.ntp.org
You can also specify servers by country. So, for example, to specify a UK based time server pool,
you would use:
0.uk.pool.ntp.org
1.uk.pool.ntp.org
2.uk.pool.ntp.org
Or, for the US, you would use:
0.us.pool.ntp.org
1.us.pool.ntp.org
2.us.pool.ntp.org
Be careful when using country based NTP pool servers, since some countries contain a very
limited number of time servers. In these cases, it is best to use a mix of country and continent
based pool servers. If a country has only one time server, then it is recommended you use a time
server pool based in another nearby country that supports more servers, or use the continent
based server pools.
For example, Japan has 6 (six) time servers as of the date this document was published. The
organization that maintains time server pools recommends using the following to specify time
server pools for Japanese locations:
2.jp.pool.ntp.org
0.asia.pool.ntp.org
2.asia.pool.ntp.org
For more information on choosing NTP pool servers, please see the NTP pool server web pages at:
http://support.ntp.org/bin/view/Servers/NTPPoolServers
For general information on the NTP Pool Project, please go to the project home page:
http://www.pool.ntp.org/
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
303
System Settings
Managing NTP
The following table shows you how to perform NTP tasks using the CLI and the GUI:
Task
Command / Procedure
eqcli > ntp-server name
CLI
The name parameter can be an NTP server name or an NTP pool
name.
Add an NTP server
Remove the NTP
server
GUI
Click Hostname> Maintenance > NTP.
Enter an NTP Server or pool name.
Click Commit.
CLI
eqcli > no ntp-server
GUI
Not implemented.
CLI
eqcli > ntp disable
GUI
Not implemented.
CLI
eqcli > ntp enable
GUI
Not implemented.
CLI
eqcli > show
GUI
Not implemented.
Disable NTP
Enable NTP
Display NTP server
304
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Backup and Restore
The Backup and Restore feature is used to backup your system configuration into a restorable file
and provide you with the ability to re-install the cluster/server pool/server configuration, Envoy
configuration, networking details, licensing and certificates on your appliance if necessary. For
example, if you purchase a new appliance or need a unit to be configured in failover, and you
need the same configuration to be quickly implemented on the new system; the Restore feature
could set up the same configuration as your current system.
Using the CLI or GUI, a backup file can be generated that contains the following Equalizer
information:
l
l
l
l
A snapshot of all load balancing objects in the configuration: including clusters, server
pools, servers, health checks, responders, failover peers, LLB gateways, GeoClusters and
GeoSites, etc.
All login and authentication information, the VLAN and subnet configuration, logging, remote
access, etc.
Licensing information (if present).
SSL Certificates used by the GUI. (Cluster SSL certificates are not backed up for security
reasons)
The backup file can be uploaded to an FTP site or saved locally.
Using the CLI or GUI, the Restore feature allows you to restore the backup file, with configured
objects and parameters to Equalizer. You can transfer the backup file to Equalizer using FTP or by
uploading a backup file through the browser. Using FTP requires that you first make the backup
file available for download from a local FTP server.
Be aware that when restoring a backup file, the configuration existing on your Equalizer will
be overwritten and the system will be rebooted. Your SSL certificates (if any) will be erased
and need to be reinstalled. You will be prompted to continue with the restore after a warning
is displayed.
You must have Administrator permissions on Equalizer to perform backup/restore.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
305
System Settings
Backup/Restore and Failover Configurations
When applying a backup file to a replace a unit that is in a failover configuration, it is possible that
the peer definitions restored from the backup file may be removed from the running system the
next time the system boots. This is because of the way the system ensures the integrity of the
local peer information in the configuration file. Each time the system boots, it looks for a local
peer definition in the configuration whose System ID number matches the System ID of the
hardware on which the system is running. It then does one of the following:
l
l
If a unique local peer definition is found, the System ID found in the local peer definition is
compared against the System ID being used by the running system. If they do not match
(as in the case where a backup file from one Equalizer is being restored on another), the
configuration file is modified to reflect the System ID of the running system and the
signature is re-generated. If they do match, the configuration is not modified.
If a unique local peer definition is not found, then all peer definitions are removed from the
configuration file and a new local peer definition is generated. This behavior is the same
behavior that occurs if Equalizeris booted and there are no peer definitions found in the
configuration file - such as when the system is reset to factory defaults.
"Failover" on page 741 for additional information.
Restore Notes
1. Using the CLI, restore a backup archive from a local directory is not supported.
2. When restoring a backup archive created on an Equalizer other than the one you are
restoring, all IP addresses (clusters, servers, failover IP addresses, VLAN IP addresses,
etc.) will be instantiated as-is from the backup archive. Consequently, if the unit on which
the backup archive was created is connected to the network, IP conflicts will arise. You
must correct the IP address conflicts before configuring the restored unit into failover, or
issues will occur.
3. If a backup was performed on a system with more interfaces than exist on the system on
which it is being restored, full connectivity will not be restored if a VLAN specifies a port
that does not exist on the system on which it is being restored. Connectivity can only be
restored for VLANs that specify ports that exist on the system on which they are being
restored. Contact Support if you continue to see networking issues.
4. Any valid licenses present on the running system are preserved and the licenses in the
backup file are discarded. If there are no valid licenses on the running system, any licenses
in the backup file are restored.
5. When restoring a backup archive on GX Series Equalizers, all existing var/crash files will be
deleted in the partition in which you are restoring the backup archive.
306
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Backup using the GUI
Follow the steps below to create a backup archive of your current system configuration using the
GUI.
1. Log in to the GUI as described in "Logging In" on page 268.
2. Click on the Maintenance tab and then select Backup and Restore. The following will be
displayed.
3. In the Backup pane enter a File Name which is built from the optionally specified Tag. In the
example above, voodoo is used. The Tag is used in addition to the default file name, which is
of the format:
system_name>[-<tag>]-<date>_<time>-backup.tbz
As the Tag is typed, it is added to the File Name or, at least, when the focus leaves the Tag, the tag should be
added to the File Name - which is read-only.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
307
System Settings
4. In the Destination section, select either FTP URL to upload to an FTP site or Local File to save
the file locally.
a. For FTP URL, you must type the full FTP URL path to the backup file leaving off
the file name. A terminating slash (/) is required. The italic text shown indicates
the required URL format. Entry of an FTP URL will replace the italic text.
b. If the Local File option is selected when you click on the Backup button a save
location dialogue box will be displayed. Select a location to save the file and
enter a file name. Click Save to save the file locally.
5. Click on the Backup button to create the backup file either save it to the specified local
directory or transfers the file to the FTP server via the URL entered.
Backup using the CLI
The backup archive is created and then uploaded to a URL that specifies an FTP site that can be
reached by Equalizer.
To create a backup and upload to a specific URL, enter the following:
eqcli > backup url URL name
where:
name is a string that will be used in the backup file name. The default name is of the form:
ftp://[user[:password]@]server[/path]
The backup file will be in the following format:
systemname-date_time-backup.tbz
When you restore , the name is required and must match the name of the backup archive to be
downloaded.
Note - You will be prompted to enter a password if it is not supplied in the URL
Note - If the system you are restoring is not the system on which the backup archive you are using was created, there
may be issues to address after the restore is complete and the system reboots. See Restore Notes.
308
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Restore using the GUI
Follow the steps below to restore a backup file containing all user-configured objects and
parameters through the GUI:
1. Log in to the GUI as described in "Logging In" on page 268.
2. Click on the Maintenance tab and then select Backup and Restore. The following will be
displayed.
3. In the Restore section select either FTP URL or Local File.
For FTP URL you must type in the full path name (including the file name) into the
text box. The italic text shown indicates the required format. Entry of an FTP URL will
replace the italic text. When the Restore button is clicked, the file is downloaded from
the specified FTP site and a pop up displays a summary of the configuration in the
archive. A notification SSL Certificates for HTTPS cluster notification will be displayed.
Click on Continue or Cancel. If Continue is selected the archive is restored and the
system is rebooted.
For Local File click on the Restore button to display a file selection dialogue to select a
file from local storage. Once the file is selected, it is transferred to Equalizer and a
popup displays a summary of the configuration in the archive. A notification SSL
Certificates for HTTPS cluster notification will be displayed. Click on Continue or
Cancel. If Continue is selected the archive is restored and the system is rebooted.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
309
System Settings
Restore using the CLI
The previously archived backup is uploaded from a URL that specifies an FTP site that can be
reached by Equalizer.
To restore a previously backed up file from a specified URL (location) enter the following:
eqcli > restore url URL name
Where:
name must match the name of the backup archive to be downloaded.
URL is the path to the previously backed up file and must be of the form:
ftp://[user[:password]@]server[/path]
Note - You will be prompted to enter a password if it is not supplied in the URL
Licensing
Refer to "Registering Your Product" on page 75 for descriptions of the licensing process.
310
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Manage Software
You can upgrade your version of the operating system using the Manage Software screen on the
GUI.
1. Click on the System configuration tab.
2. Click on the arrow (u) beside Maintenance to expand the branch.
3. Select Manage Software to display the following.
Current Boot Image
The current boot image and the partition where it resides is displayed.
Firmware Release Status
If the release running on your EQ/OS is older than the latest version available, then the red bold
text with a message “A software update is available” will be displayed. If your browser cannot
download the well-known page, then the Latest available release is indication will display
“Connection to CPS website unsuccessful.” and a URL to the download site will be displayed in the
CPS download URL space.
Upgrade
To download and install an image, select the Download location using the drop down list.
If Local File is selected you will be prompted for the location of the local file. When a file is selected
the path and file name will be displayed.
If CPS URL is selected the CPS download URL pointing to the latest available release shown in the
EQ/OS Release Status pane will automatically be displayed on the right.
If User URL is selected enter a URL in the text box on the right that points to a single-file download
image. The file path should be in the format: ftp://[user[:password]@]<IP_
address/upgrade.tgz>
After entering the Download location click on Go to begin the upgrade. If successful a "GUI
Installation successfully completed" message will be displayed.
If the upgrade does not complete successfully, verify your network connectivity and the location
of the upgrade file and attempt the upgrade again.
Note - After upgrading, you should clear your browser cache before using the new version of the software.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
311
System Settings
Tools
The Tools screen provides useful utilities that includes:
l
A Configuration Converter that allows you to create an EQ/OS 10 configuration that is
functionally equivalent to the EQ/OS 8.6 configuration from a supplied backup archive.
l
A Halt/Shutdown command, allows you to turn your Equalizer "off" from directly in the GUI.
l
A Reboot System command, allows you to reboot your Equalizer from directly in the GUI.
l
A Save System State feature, that allows you to create an archive of your various configuration
files, logs and other details used to help in diagnosing any issues that may arise.
Access any of the tools by selecting the appropriate accordion tab to display the
commands/details.
Halt/Shutdown System
Click on the Halt/Shutdown System configuration tab to display the following. Click on the Halt button
to shut down your Equalizer.
312
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Reboot System
Click on the Reboot System configuration tab to display the following. Click on the Reboot button to
reboot your Equalizer.
Save System State
Click on the Save System State configuration tab to display the following. In this screen you can set
up a Save State or system information archive that contains various configuration files, logs, and
other information used by Support to help diagnose problems you are having with Equalizer. The
file can be saved locally or uploaded to an FTP server.
1. Click on the Maintenance tab and then Save State to display the following:
2. Enter a File Name for the archive. This should be in the format: hostname-tag-date_timecollect.tbz If desired, enter a unique tag for the archive file name in the Tag field which
will be included in the archive file name. If a tag is not entered, the file name will be in the
format specified, however, without that tag element.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
313
System Settings
3. Select either the Local or FTPURL option in the Destination pane.
a. If you select Local, the archive will be saved in the default “save” directory
specified in your web browser options.
b. If you select FTP URL, enter the URL of the FTP site on which you will upload the
archive file.The URL should be in the format: ftp://[user[:password]@]
server/[path/].
4. Select the Save State button to create the archive. Once Equalizer collects the information
for the archive, a dialog box is displayed by your browser to open or save the archive.
5. If you require technical support, open your email client and send the file you saved to
support@coyotepoint.com as an attachment or provide the URL (with credentials) for the
FTP site on which the archive now resides. Explain the nature of your problem in the email,
or just include the support ticket number you were given previously by Coyote Point
Support.
314
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Failover
Refer to "Failover" on page 741 for complete descriptions of failover configurations and setups.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
315
Equalizer Administration Guide
Chapter 12
Working with Clusters and Match Rules
Sections in this chapter include:
Overview
Cluster Summary
Cluster Connection Timeouts
Adding and Deleting Clusters
Modifying a Layer 4 TCP or UDP Cluster
Modifying a Layer 7 HTTP or HTTPS Cluster
Header Editing
Layer 7 TCP Cluster Settings
Additional Cluster Configuration
Configuring Direct Server Return
Testing Your Basic Configuration
Using Match Rules
Cluster and Match Rule Statistics and Reporting
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
318
320
324
331
333
353
389
390
395
406
409
410
446
317
Working with Clusters and Match Rules
Overview
A cluster is a collection of server pools with a single network-visible IP address. All client requests
come into Equalizer through a cluster IP address, and are routed by Equalizer to an appropriate
server, according to the load balancing options set on the cluster. The figure below shows a
conceptual diagram of an Equalizer with three clusters.
Each cluster must be assigned at least one server pool, a grouping of real servers that will be
used to respond to incoming client requests. Servers in a server pool are called 'server instances',
to distinguish them from the real server definitions with which they are associated (refer to
"Managing Server Pools" on page 456 for more information).
The parameters you specify when setting up a virtual cluster determine how client and server
connections are managed, and how requests are load balanced among the server instances in a
server pool.
Before beginning to define a cluster, you need to do the following:
1. Determine the IP addresses to use for each cluster, and the IP addresses to use for all of your
real servers.
2. Determine the cluster types appropriate for your configuration.
318
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Notes:
l
l
l
l
The Layer 4 TCP and UDP clusters can use only IPv4 cluster addresses and can only be used
with servers that have IPv4 addresses.
The Layer 7 TCP cluster is used to provide IPv6 addressing for Layer 4 protocols, and can
support IPv4 and IPv6 addressing for clusters and servers. The functionality is very much
like Layer 4 TCP clusters. This type of cluster should be used when IPv6 addressing is
required for a TCP protocol other than HTTP or HTTPS.
L4 UDP clusters are appropriate for connectionless (stateless) applications, such as DNS,
TFTP, Voice over IP (VoIP), and streaming applications -- any application that exchanges
short packets with many clients, and where dropped packets are preferred to delayed
packets (i.e., the highest possible network performance is required). Layer 4 UDP clusters
do not currently support IPv6 addressing.
Layer 7 HTTPS clusters also provide SSL Offloading: all SSL certificate operations are
performed by the cluster, not by the servers behind the cluster, thus improving overall
cluster performance.
After you decide on the cluster types you need, you'll then need to determine the additional
settings and flags to be used on the cluster and its server pools. For most configuration, it is often
a good idea to start with the defaults and make incremental changes as you examine traffic
passing through your clusters.
Match Rules
Layer 7 HTTP and HTTPS clusters can use logical constructs called “Match Rules” to control the
processing of the incoming data stream from clients. Match rules extend the Layer 7 load
balancing capabilities of HTTP and HTTPS clusters by allowing you to define a set of logical
conditions which, when met by the contents of the request, trigger the load balancing behavior
specified in the match rule.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
319
Working with Clusters and Match Rules
Cluster Summary
A summary of cluster connection statistics can be displayed using either the GUI or CLI:
Cluster Summary using the GUI
The example of a Cluster Summary screen shown below displays an expandable, sortable
summary listing of all of the clusters configured on your Equalizer.This table displays basic status
and statistics for the currently configured clusters, their associated server pools, and Layer 7
match rules. Click on the Load Balance configuration tab on the left navigational pane if it is not
already selected. Then click on Clusters to display this summary screen.
Status Indicators
These icons provide status of the server instances in the attached server pools.
This icon indicates that the server instances in the attached server pool are up and running.
This icon indicates that one or more of the server instances in the attached server pool are
down.
This icon indicates that a server instance has been probed DOWN.
Numerical Statistics Displayed
Connections - The number of active (current) connections to this cluster.
TPS - The number of Transactions Per Second being processed by the cluster or match rule.
Sticky - For Layer 4 clusters only. This is the number of entries in the "sticky table" for each server.
320
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Customizing the Display
The cluster summary has 3 display options as shown below:
No Filter - selecting this option will display a cluster summary for all of the clusters configured on
your Equalizer.
Filter by Cluster Name - selecting this option will display the cluster summary based on the cluster
names that you select with the check boxes. Use the Select All or Unselect All buttons as necessary.
Filter by IP Address - selecting this option will display the entered IP address of the cluster(s) that
you would like displayed. For example if you would like to display cluster summary for IPv4
clusters with IP addresses beginning with "172" you would enter "172.*.*.*" - using a wildcard
character (*). For IPv6 clusters you would enter prefix specification such as "2001:218:420::/64".
After clicking on the Set button, the details for those clusters alone will be displayed.
Filter by Status - selecting this option will activate the Enable/Disable options. Selecting Enable will
display only those clusters that do not have problem icons associated with them. Selecting Disable
will display only those clusters that have problem icons associated with them.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
321
Working with Clusters and Match Rules
Cluster Summary using the CLI
The Cluster Summary screen shown below displays a summary listing of all of the clusters
configured on your Equalizer.
Enter the following:
eqcli > show cluster
Name
IP Address
Port
Proto
testUDP
Test-http
Test_https
4.6.8.9
1.3.5.7
2.4.6.8
80
80
80
udp
http
https
eqcli >
To display the cluster summary for specific clusters enter the show cluster summary display. It
is different than the GUI display in that it reflects only information such as the cluster settings,
timeouts, responders and persistence.
eqcli > show cluster Test_https
L7 Cluster Name
Protocol
IP Address
Port
Preferred Peer
VID
Client Timeout
Server Timeout
Connection Timeout
Sticky Timeout
Sticky Netmask
Custom Header
CRL
CA Certificate
Cipher Spec
Validation Depth
Flags
Default Certificate
SNI Certificate Objects
Server Pool
Responder
Cookie Path
Cookie Domain
322
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Test_https
https
2.4.6.8
80
1
10
60
10
0
32
AES128-SHA:DES-CBC3-SHA:RC4-SHA:
RC4-MD5:AES256-SHA:!SSLv2
: 9
: allow_utf8, allow_sslv3,
ignore_critical_extns,
allow_t-- press space for mls10,
rewrite_redirects, insert_client_ip
:
:
:
:
:
:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Cookie Age
Cookie Generation
Persist Type
: 0
: 0
: coyote_cookie_2
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
323
Working with Clusters and Match Rules
Cluster Connection Timeouts
Layer 7 clusters (HTTP / HTTPS) and Layer 4 clusters (TCP / UDP) each use a different set of
timeout parameters as described below.
Note - Setting cluster timeouts to arbitrarily high values can have an adverse effect on cluster performance, and can
result in the cluster no longer processing traffic. We recommend that you start with default timeout values and adjust
the timeouts one by one, in small increments, until you get the timeout behavior that you desire.
HTTP and HTTPS Connection Timeouts
Connections to HTTP and HTTPS clusters are managed closely by Equalizer from the client request
to the response from the server. Equalizer needs to manage two connections for every Layer 7
connection request: the client connection from which the request originates, and the connection to
the server that is the final destination of the request (as determined by the load balancing policy).
1. Equalizer has an idle timer for the established client connection, a connect timer to establish
a server connection, and an idle timer for the established server connection. Only one
timeout is in use at any given time. This is a summary of how timeouts are used when a
client connects to Equalizer:
2. When a client successfully connects to a Virtual Cluster IP, the client timeout applies from
the time the connection is established until the client request headers are completely
transmitted. Equalizer parses the client's request, and verifies that the request is a valid
HTTP request and that the information needed for load balancing is obtained. In general,
this happens at the time that the client headers are completed -- which is indicated by the
client sending two blank lines for HTTP 1.0 or 1.1; one blank line for HTTP 0.9. Once the
headers are completely transmitted to Equalizer, the client timeout is no longer used.
3. As soon as the Equalizer is done examining the header data, it makes a connection to a
server, as determined by the load balancing policy, persistence, or a match rule hit. The
amount of time that the Equalizer tries to establish a connection to the server is the connect
timeout. Once the server connection is established, the connect timeout is no longer used.
4. After Equalizer establishes a connection with a server, the server timeout is the amount of
time Equalizer waits for the next bit of data from the server. Any response from the server
restarts the server timeout.
The important distinction between the client timeout and the server timeout is that the client
timeout is a “hard” timeout -- the client has the number of seconds specified to transmit all of its
headers to Equalizer before Equalizer times out. This is done mainly for security considerations to
prevent malicious clients from creating a large number of partial connections and leaking data
slowly over the connection, possibly causing resource exhaustion or other undesirable effects on
Equalizer.
The server timeout by contrast is a “soft” timeout -- the server has the number of seconds specified
to send the next piece of information (e.g., the next packet in the sequence). Whenever the client
or the server sends a piece of data on the connection, the server timeout is reset. This allows the
server to send large data streams in small pieces without timing out, and then close the
connection once all the data is sent.
324
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
For example, when a client sends a POST operation in a request, the client timeout is used up until
the time that the POST headers have all been received. The connect timeout is used until a
connection with the server is established. Then, once the connection is established, the server
timeout is used for the POST data itself and the subsequent response from the server.
Note that there is the chance that a client will connect, send its headers, and then send continuous
data to Equalizer that repeatedly resets the server timeout. This vulnerability is usually avoided
by setting a hard client timeout on the application server itself (see "Cluster Connection Timeouts"
on page 324).
The figure below summarizes the connection timeout parameters Equalizer uses for Layer 7 client
and server connections.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
325
Working with Clusters and Match Rules
The timeline below shows the sequence of timeout events when a new connection is received by
Equalizer.
The following table shows the value range for the Layer 7 HTTP / HTTPS connection timeouts.
Parameter
Minimum
Default
Maximum
Units
client timeout
1.0
5.0
65535.0
seconds
server timeout
1.0
60.0
65535.0
seconds
connect timeout
1.0
10.0
60.0
seconds
326
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
The default timeout values are sufficient for many common applications. If timeouts are occurring
using the default values, adjust the server timeout to the amount of time you expect your
application server to respond to a client request, plus 1 second. If there is high latency between
Equalizer and the servers in your cluster, then you may need to increase the connect timeout. The
client timeout usually does not need to be changed, but in some situations, HTTPS clusters will
require a client timeout between 15 and 30 seconds for best performance. If you do need to
increase the client timeout, use the lowest value possible for your configuration to perform well;
high values for client timeout increase the risk of denial of service (DoS) attacks.
Once Only Option and HTTP / HTTPS Timeouts
The previous sections describe how the connection timeouts work when the once only flag is
disabled on a cluster; that is, when Equalizer is examining every set of headers received on a
connection. The once only option, when enabled, specifies that Equalizer will examine only the
first set of headers received on a connection. This has the following effects on connection
timeouts:
l
l
If you have once only enabled, as soon as the initial transaction (client request and server
response) on a connection completes, the connection goes into “streaming” mode and the
client timeout is no longer used for this connection. Equalizer does not parse any additional
client requests received on the connection. The server timeout is used for the remainder of
the connection, and is reset whenever data is received from either side of the connection.
If you have once only disabled as described in the previous sections, and multiple requests
are being sent on the same connection, the client timeout starts counting down again as
soon as a new request is received from the client.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
327
Working with Clusters and Match Rules
Layer 4 Connection Timeouts
Connections to Layer 4 clusters are received by Equalizer and forwarded with little processing.
Equalizer simply rewrites the source and/or the destination IP addresses, as appropriate for the
cluster, and sends the packet to the server specified by the cluster’s load balancing policy. For
Layer 4 TCP clusters, a connection record is kept for each connection so that address translation
can be done on the packets going between the servers and clients. The Layer 4 connection
timeouts specify how long a connection record is kept by Equalizer.
Layer 4 TCP clusters use the idle timeout and stale timeout parameters that set at cluster levels.
The parameters affect how Equalizer manages Layer 4 connection records:
l
Connection records need to be removed in cases where the connection is not closed by the
client or server, and is left idle. If no data has been received on a connection from either
the client or the server after the time period specified by the idle timeout has elapsed, then
Equalizer removes the connection record for that connection. Any data received from either
client or server resets the idle timer.
Note that when using Direct Server Return (DSR), the time that a connection record is
maintained is determined by adding the idle timeout for the cluster to the sticky time . This
additional time is necessary when using DSR, since no server responses are routed through
Equalizer (and therefore cannot restart the idle timeout to keep the connection open). For
more information on DSR, see "Configuring Direct Server Return" on page 406.
l
In other cases, a connection may be initiated but never established, so the connection
record goes “stale” and must be removed. If a client fails to complete the TCP connection
termination handshake sequence or sends a SYN packet but does not respond to the
server’s SYN/ACK, Equalizer marks the connection as incomplete. The stale timeout is the
length of time that a connection record for an incomplete connection is maintained.
When Equalizer reclaims a connection, it sends a TCP RST (reset) packet to the server, enabling
the server to free any resources associated with the connection. (Equalizer does not send a TCP
RST to the client when reclaiming a connection.)
Reducing the stale timeout can be an effective way to counter the effects of SYN flood Denial of
Service attacks on server resources. A stale timeout of 10.0 (see table below) would be an
appropriate value for a site under SYN flood attack.
Parameter
Minimum
Default
Maximum
Units
idle timeout
1.0
60.0
65535.0
seconds
stale timeout
1.0
30.0
120.0
seconds
Note that if you change the stale timeout setting while partially established Layer 4 connections
are currently in the queue, those connections will be affected by the new setting.
328
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Application Server Timeouts
Keep in mind that the application server running on the physical servers in your cluster may have
its own timeout parameters that will affect the length of time the server keeps connections to
Equalizer and the client open. For example, an Apache 2 server has two related timeout
directives: TimeOut and KeepAliveTimeout :
1. The TimeOut directive currently defines the amount of time Apache will wait for three things:
a. The total amount of time it takes to receive a GET request.
b. The amount of time between receipt of TCP packets on a POST or PUT request.
c. The amount of time between ACKs on transmissions of TCP packets in
responses.
2. The KeepAliveTimeout directive specifies the number of seconds Apache will wait for a
subsequent request before closing the connection. Once a request has been received, the
timeout value specified by the Timeout directive applies.
In general, if you want Equalizer to control connection timeouts, you must make sure that any
timeouts set on the application server are of longer duration than the values set on Equalizer.
For example, with respect to the Apache server timeouts above, the client timeout (for Layer 7
connections) or the idle timeout (for Layer 4 connections) should be of shorter duration than the
timeouts set for Apache.
Similarly, the Layer 7 server timeout and connect timeout on Equalizer should be of shorter
duration than the TCP connection timeouts set on the servers.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
329
Working with Clusters and Match Rules
Connection Timeout Kernel Variables
Equalizer uses a number of kernel variables to track connection timeouts, as shown in the table
below. You can use the sysctl command to display kernel variables. The two basic formats of this
command are:
sysctl variable_name
sysctl -a > file
capturing the list to a file.
Displays the kernel variable variable_name.
Displays all kernel statistics. This is a long list, so we recommend
eq.idle_timeout
The current setting of the Layer 4 global networking idle timeout
parameter.
eq.idle_timedout_count
A Layer 4 counter incremented when a connection is terminated because
the idle timeout expired.
eq.stale_timeout
The current setting of the Layer 4 global networking stale timeout
parameter.
eq.l7lb.timeouts
The total number of Layer 7 connections dropped because a connection
timer expired.
eq.l7lb.http.client_timeouts
The total number of Layer 7 (HTTP and HTTPS) connections that were
terminated because the client timeout expired.
eq.l7lb.http.connect_timeouts
The total number of Layer 7 (HTTP and HTTPS) connections that were
terminated because the connect timeout expired.
eq.l7lb.http.server_timeouts
The total number of Layer 7 (HTTP and HTTPS) connections that were
terminated because the server timeout expired.
Note that there are also some kernel variables associated with Secure Socket Layer (ssl) client
connections, such as when someone logs into Equalizer over an SSH connection. These variables
are not incremented by HTTPS connections:
eq.l7lb.ssl.total_clients
eq.l7lb.ssl.current_clients
eq.l7lb.ssl.max_clients
eq.l7lb.ssl.requests
330
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding and Deleting Clusters
You can add and delete clusters using either the CLI or the GUI.
Using the GUI
Follow these steps to add a new Layer 7 or Layer 4 virtual cluster using the GUI:
1. Log into the GUI using a log in that has add/del access for global parameters (See "Logging
In" on page 268)
2. Select Load Balance > Clusters on the left navigational pane. Right click and select Add Cluster
from the menu that appears. The Add Cluster form appears as shown below.
3. Select http, https, tcp, L7tcp or udp from the Protocol drop down list.
4. Enter the following on the form:
Cluster Name - The logical name for the cluster, or accept Equalizer’s default. Each
cluster must have a unique name that begins with an alphabetical character. The
cluster name is limited to 63 characters.
IP - Enter the cluster IP address, which is the dotted decimal IP address of the cluster.
The IP address of the cluster is the external address (for example, 172.16.0.201) with
which clients connect to the cluster.
Port - Enter the cluster port: the numeric port number on the Equalizer to be used for
traffic between the clients and the cluster. For HTTP clusters, the cluster port defaults
to 80. For HTTPS clusters, the cluster port defaults to 443. For TCP ports the cluster
port defaults to 88. For UDP ports the cluster port defaults to 53.
5. Click on Commit to save the cluster. The new cluster will appear on the Cluster branch of the
left navigation pane of the GUI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
331
Working with Clusters and Match Rules
6. Clicking on each cluster on the Cluster branch of the navigation pane will display the
Configuration Summary.
Deleting clusters using the GUI
1. Log into the GUI using a login that has add/del access for global parameters (See "Logging
In" on page 268)
2. Do one of the following:
a. Right click on a cluster on the left navigational pane and select Delete Cluster.
b. Click on a cluster on the left navigational pane and drag to the Delete (Trash)
icon.
Using the CLI
Adding a Cluster
Add a cluster using eqcli as follows. In this example a Layer 7 HTTPS cluster is created. Since the
protocol is HTTPS, port 443 is used.
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the following at the CLI prompt:
eqcli >cluster [clustername] proto protocol ip [xxx.xx.x.xxx] port xxx
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on cluster
commands in the CLI.
Deleting a Cluster
Do the following to delete a cluster using eqcli as follows:
1. Enter the following at the CLI prompt:
eqcli > no cluster [clustername]
332
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Modifying a Layer 4 TCP or UDP Cluster
The configuration tabs for a cluster are displayed automatically when a cluster is added to the
system, or by selecting the cluster name from the left frame Configuration Tree.
To update the settings on any tab, make changes and select the Commit button to save them.
TCP Cluster Configuration Summary
The TCP Cluster Configuration Summary screen is displayed automatically when a cluster is added to
the system, or by selecting the cluster name from the Cluster branch on the left navigation pane
and selecting the Configuration Summary tabs. This screen displays a snapshot of the cluster and all
of its associated objects (i.e., server pools, server instances and responders), the status of the
objects, the Active Connections, Connections/Second and Transactions/Second.
A graphical plot is also displayed showing the traffic flow through the cluster from the past 30
minutes.
In addition you have the option to Disable the cluster by selecting the Disable check box.
Sample of a TCP Cluster Configuration Summary (GUI)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
333
Working with Clusters and Match Rules
Sample of a TCP Cluster Configuration Summary (CLI)
The following is an example of a Cluster configuration display using the CLI. Enter eqcli > show
cluster clustername .
eqcli > show cluster cluster_tcp
L4 Cluster Name : cluster_tcp
Protocol
: tcp
IP Address
: 1.4.7.10
Port
: 80
Port Range
: 0
Preferred Peer
:
VID
: unassigned
Server Pool
: testserverpool
Sticky Timeout
: 0
Sticky Netmask
: 32
Idle Timeout
: 60
Stale Timeout
: 30
Flags
:
eqcli >
334
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
TCP Cluster Configuration Settings
The following describes the process of entering TCP cluster configuration settings.
Parameters
The table below shows the parameters used with the configuration of a TCP cluster.
GUI Parameter (CLI Parameter)
Description
Protocol
(proto)
The protocol used for the cluster.
VID
(vid)
The VLAN ID number. This is an integer between 1 and 4095.
IP
(ip)
Enter the IP address, which is the dotted decimal IP address of the cluster.
The IP address of the cluster is the external address (for example,
199.146.85.0) with which clients connect to the cluster.
Port
(port)
For TCP protocol clusters the numeric port number on the Equalizer to be
used for traffic between the clients and the cluster. This port also becomes
the default port for servers added to the cluster (though servers can use a
different port number than the one used by the cluster).
Preferred Peer
(preferred_peer)
Used with N+1 Failover Configuration. (See "Configuring
N+1 Failover
Server Pool
(srvpool)
The drop down list selects the Server Pool (grouping of server instances)
to be associated with the TCP cluster.
Service Protection Profile
(cl_spp)
The drop down lists selects the Service Protection Profile to use for
monitoring traffic statistics through the cluster to prevent Denial of Service
attacks. Refer to "Setting Up" on page 681 for details on how the cluster SPP
is configured and how it works in preventing Denial of Service attacks.
Range
(range)
For L4 UDP and L4 TCP protocol clusters, a port Range can be defined by
entering a value higher than the L4 port configured for the cluster. This
range allows Equalizer users to create a single cluster to control the traffic
for multiple, contiguous ports.
Between Two Systems" on page 796)
Flags
Direct Server Return
(dsr)
When enabled, Equalizer forwards packets to the server in such a way that
the server responds directly to the client, rather than through Equalizer.
This option requires special configuration on the cluster; see "Configuring
Direct Server Return" on page 406 before enabling this option. The
spoof option must also be enabled when this option is enabled.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
335
Working with Clusters and Match Rules
GUI Parameter (CLI Parameter)
Description
When the Spoof option is enabled on a cluster, Equalizer uses the client’s IP
address as the source IP address in all packets sent to a server in that
cluster.
When Spoof is enabled, all server responses to client requests that came
through the Equalizer cluster IP address must be routed by the server back
to the client through Equalizer. In many cases, the easiest way to do this is to
set the default gateway on the server instances in the server pool on a
cluster to Equalizer’s IP address on the server VLAN. If this is not possible,
you can establish static routes on the server to send responses to specific
client IP addresses to Equalizer’s IP address on the VLAN.
Spoof
(spoof)
If you disable Spoof, the server receiving the request will see Equalizer’s IP
address as the client address because the TCP connection to the client is
terminated when the request is routed. The server will therefore send its
response back to Equalizer’s IP address.
When the Spoof flag is disabled on a Layer 4 cluster:
If there is more than one VLAN defined, all server instances on a server pool
must be located on the second defined VLAN in the configuration (the VLAN
that appears after the Default VLAN in the GUI, in ifconfig output, and in
the configuration file), so that source NAT will work correctly. This is
because the source IP address used when spoof is disabled is the Equalizer
IP address on that VLAN.
336
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
TCP Cluster Configuration Settings using the GUI
The TCP Cluster Settings screen for a TCP cluster is displayed by selecting a cluster and from the
left navigational pane and then selecting the Configuration Settings tabs.
Click on the Commit button after making changes.
TCP Cluster Configuration Settings Using the CLI
TCP Cluster configuration settings can be configured after creating a TCP Cluster. At the CLI
prompt you can enter parameters either globally or in cluster context. The following format
should be used.
eqcli > cluster clustername parameter value flags flag
Use the table above to configure the parameters that can be used.
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
337
Working with Clusters and Match Rules
TCP Cluster Persistence
The TCP Cluster Configuration Persistence screen is used to configure Sticky Netmask values,
Timeouts and assign the Inter Cluster sticky flag to the selected TCP cluster.
Parameters
The table below shows the persistence parameters used with TCP clusters.
GUI Parameter (CLI Parameter)
Sticky Netmask
(sticky_netmask)
Description
Enables sticky network aggregation for a subnet. Sticky network
aggregation is applicable for Layer 4 and Layer 7 clusters. Sticky network
aggregation enables Equalizer to correctly handle sticky connections from
ISPs that use multiple proxy servers to direct user connections. When you
enable sticky network aggregation, all the connections coming from a
particular network are directed to the same server. (Typically, all the
servers in a proxy farm are on the same network.) The sticky netmask
value indicates which portion of the address Equalizer should use to
identify particular networks. Values are:
0-32 for IPV4 clusters (default=32)
0-128 for IPV6 clusters
Sticky Time Out
(stickyto)
Sticky Timeout is the number of seconds that Equalizer should
“remember” connections from clients. Valid values are from 0 (which
disables sticky connections) to 1073741823 seconds (or over 34 years).
For more information, refer to "Enabling Sticky Connections" on
page 395.
Flags
Inter-Cluster Sticky
(ics)
338
With the inter-cluster sticky option, you can configure Equalizer to direct
requests from a client to the same server on any available port that has a
current persistent connection in any cluster.Inter-Cluster Sticky is a Layer
4 option that allows you to extend Layer 4 persistence across multiple
server ports.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configure TCP Cluster Persistence Using the GUI:
TCP Cluster Persistence can be accessed by selecting a cluster from the left navigational pane and
selecting the Configuration > Persistence tab. The following will be displayed.
Configured TCP Cluster Persistence parameters using the table above. Click on the Commit button
after making changes to the settings.
Configure TCP Cluster Persistence Using the CLI
TCP Cluster Persistence can be accessed by selecting configuring a cluster and configuring
parameters on the CLI command line either globally or in cluster context. Use the following
format:
eqcli > cluster cluster clustername parameter value flags flag
Where:
clustername - is the the name fo the cluster.
parameter - is the parameter.
value - is the value associated with the parameter.
flag - is the flag to be associated with the cluster.
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
339
Working with Clusters and Match Rules
TCP Cluster Timeouts
The TCP Cluster Configuration Timeouts screen is used to configure the various timeouts shown
below for the selected TCP cluster.
Parameters
The table below shows the cluster timeouts used with the configuration of a TCP cluster.
GUI Parameter (CLI Parameter)
Description
Idle Timeout
(idleto)
The idle timeout (default:60) can be set at the global and cluster levels,
while stale timeout can be set at the global level only. Connection records
need to be removed in cases where the connection is not closed by the
client or server, and is left idle. If no data has been received on a
connection from either the client or the server after the time period
specified by the idle timeout has elapsed, then the connection record for
that connection is removed. Any data received from either client or server
resets the idle timer.(1-65535)
Stale Timeout
(staleto)
The stale timeout (default:30) is the length of time that a connection record
for an incomplete connection is maintained. (1-120)
TCP Cluster Timeouts Using the GUI
The TCP Cluster Timeout screen can be accessed by selecting a cluster from the left navigational
pane and selecting the Configuration > Timeouts tabs.
Use the table above for parameters and values. Click on the Commit button after making changes
to the settings.
340
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
TCP Cluster Timeouts Using the CLI
The TCP Cluster Timeouts can be configured using the CLI either globally or in cluster context.
Configure the timeouts using the following format:
eqcli > cluster clustername {idleto|staleto} value
Use the parameters table above for values.
Where:
clustername - is the the name of the cluster.
value - is the value associated with the timeout.
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
341
Working with Clusters and Match Rules
UDP Cluster Configuration Summary
UDP Cluster Configuration Summary can be displayed using either the GUI or the CLI.
Sample of UDP Cluster Configuration Summary on the GUI
The UDP Cluster Configuration Summary screen is displayed automatically when a UDP cluster is added
to the system, or by selecting the cluster name from the Cluster branch on the left navigation pane.
This screen displays a snapshot of the cluster and all of its associated objects (i.e., server pools,
server instances and responders) and the status of the objects.
A graphical plot is also displayed showing the traffic flow through the cluster from the past 30
minutes.
In addition you have the option to Disable the cluster by selecting the Disable check box.Note that if
a connection is active and the cluster is disabled, then any packets received are dropped. The
connection will eventually timeout and be removed.
342
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Sample of UDP Cluster Summary Using the CLI
Select a UDP Cluster and enter the following in the CLI.either globally or in cluster context.
eqcli > show cluster cluster_udp
L4 Cluster Name : cluster_udp
Protocol
: udp
IP Address
: 5.7.3.2
Port
: 80
Port Range
: 0
Preferred Peer
:
VID
: unassigned
Server Pool
: srvplUDP
Sticky Timeout
: 0
Sticky Netmask
: 32
Stale Timeout
: 30
Flags
:
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
343
Working with Clusters and Match Rules
UDP Cluster Configuration Settings
You can configure UDP Clusters using either the GUI or the CLI.
Parameters
The table below shows the parameters and values used with the configuration of a UDP cluster.
GUI Parameter
(CLI Parameter)
Description
Protocol
(proto)
The protocol used for the cluster.
VID
(vid)
The VLAN ID number. This is an integer between 1 and 4095.
IP
(ip)
Enter the IP address, which is the dotted decimal IP address of the cluster.
Port
(port)
For TCP protocol clusters the numeric port number on the Equalizer to be used
for traffic between the clients and the cluster. For TCP clusters, the port
defaults to 80. This port also becomes the default port for servers added to the
cluster (though servers can use a different port number than the one used by
the cluster).
Preferred Peer
(preferred_peer)
Used with N+1 Failover Configuration. Refer to "Configuring
N+1
Server Pool
(srvpool)
The drop down list selects the Server Pool (grouping of server instances) to
be associated with the TCP cluster.
Service Protection Profile
(cl_spp)
The drop down lists selects the Service Protection Profile to use for monitoring
traffic statistics through the cluster to prevent Denial of Service attacks. Refer
to "Setting Up" on page 681 for details on how the cluster SPP is configured
and how it works in preventing Denial of Service attacks.
Range
(range)
For L4 UDP and L4 TCP protocol clusters, a port Range can be defined by
entering a value higher than the L4 port configured for the cluster. This range
allows Equalizer users to create a single cluster to control the traffic for
multiple, contiguous ports.
Failover Between Two Systems" on page 796.
Flags
Direct Server Return
(dsr)
When enabled, Equalizer forwards packets to the server in such a way that the
server responds directly to the client, rather than through Equalizer. This
option requires special configuration on the cluster; see "Configuring
Direct Server Return" on page 406 before enabling this option. The
spoof option must also be enabled when this option is enabled.
344
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter
(CLI Parameter)
Description
When the Spoof option is enabled on a cluster, Equalizer uses the client’s IP
address as the source IP address in all packets sent to a server in that cluster.
When Spoof is enabled, all server responses to client requests that came
through the Equalizer cluster IP address must be routed by the server back to
the client through Equalizer. In many cases, the easiest way to do this is to set
the default gateway on the server instances in the server pool on a cluster to
Equalizer’s IP address on the server VLAN. If this is not possible, you can
establish static routes on the server to send responses to specific client IP
addresses to Equalizer’s IP address on the VLAN.
Spoof
(spoof)
If you disable Spoof, the server receiving the request will see Equalizer’s IP
address as the client address because the TCP connection to the client is
terminated when the request is routed. The server will therefore send its
response back to Equalizer’s IP address.
When the Spoof flag is disabled on a Layer 4 cluster:
If there is more than one VLAN defined, all server instances on a server pool
must be located on the second defined VLAN in the configuration (the VLAN
that appears after the Default VLAN in the GUI, in ifconfig output, and in the
configuration file), so that source NAT will work correctly. This is because the
source IP address used when spoof is disabled is the Equalizer IP address on
that VLAN.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
345
Working with Clusters and Match Rules
UDP Cluster Configuration Using the GUI
The UDP Cluster Configuration Settings screen shown below is displayed automatically when the
cluster is added to the system, or by selecting the cluster from the left navigational pane on the
GUI and selecting the Configuration Settings tabs.
Use the table above for descriptions of the parameters and values. Click on the Commit button after
making changes.
346
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
UDP Cluster Configuration Using the CLI
UDP Clusters can be configured in the CLI either globally or in cluster context. Enter parameters
using the following format. eqcli > cluster clustername parameter value flags flag
Use the table above for descriptions of the parameters and values.
Where:
clustername - is the name of the cluster.
parameter - is the parameter.
value - is the value associated with the parameter.
flag - is the flag to be associated with the cluster.
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
347
Working with Clusters and Match Rules
UDP Cluster Persistence
UDP Cluster persistence includes the configuration of Sticky Netmask values, timeouts, and the
assignment of an Inter Cluster Sticky flag on the cluster, if necessary.
Parameters
The table below shows the Cluster Persistence parameters and values used with the configuration
of a UDP cluster.
GUI Parameter (CLI Parameter)
Sticky Netmask
(sticky_netmask)
Description
Enables sticky network aggregation for a subnet. Sticky network aggregation
is applicable for Layer 4 and Layer 7 clusters. Sticky network aggregation
enables Equalizer to correctly handle sticky connections from ISPs that use
multiple proxy servers to direct user connections. When you enable sticky
network aggregation, all the connections coming from a particular network
are directed to the same server. (Typically, all the servers in a proxy farm are
on the same network.) The sticky netmask value indicates which portion of
the address Equalizer should use to identify particular networks. Values are:
0-32 for IPV4 clusters (default=32)
0-128 for IPV6 clusters
Sticky Time Out
(stickyto)
Sticky Timeout is the number of seconds that Equalizer should “remember”
connections from clients. Valid values are from 0 (which disables sticky
connections) to 1073741823 seconds (or over 34 years). For more
information, refer to "Enabling
Sticky Connections" on page 395.
Flags
Inter-Cluster Sticky
(ics)
348
With the inter-cluster sticky option, you can configure Equalizer to direct
requests from a client to the same server on any available port that has a
current persistent connection in any cluster.Inter-Cluster Sticky is a Layer 4
option that allows you to extend Layer 4 persistence across multiple server
ports.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
UDP Cluster Persistence Using the GUI
The UDP Cluster Configuration >Persistence screen can be accessed by selecting a cluster from the
left navigational pane and selecting the Configuration > Persistence tab.
Configure using the table above for parameters and values. Click on the Commit button after
making changes to the settings.
Configuring UDP Cluster Persistence Using the CLI
UDP Cluster persistence can be configured using the CLI in either global format or within the
cluster context. Use the following format.
eqcli > cluster clustername parameter value flags flag
Configure using the table above for parameters and values.
Where:
clustername - is the the name fo the cluster.
parameter - is the parameter.
value - is the value associated with the parameter.
flag - is the flag to be associated with the cluster.
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
349
Working with Clusters and Match Rules
UDP Cluster Timeouts
UDP Cluster Timeouts involve the configuration of a state timeout. A Stale Timeout is the length of
time in seconds that a partially open or closed Layer 4 connection is maintained. If a client fails to
complete the TCP connection termination handshake sequence or sends a SYN packet but does not
respond to the server’s SYN/ACK, Equalizer marks the connection as incomplete.
Configuring UDP Cluster Timeouts Using the GUI
The UDP Cluster Configuration Timeouts screen can be accessed by selecting a cluster from the left
navigational pane and selecting the Configuration Timeouts tab.
Configure the Stale Timeout and click on the Commit button after making changes to the settings.
350
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring UDP Cluster Timeouts Using the CLI
Configure the Stale Timeout for the UDP cluster using the CLI either globally or in the cluster
context.
eqcli > cluster clustername staleto value
Where:
clustername - is the the name fo the cluster.
value - is the value associated with the stale timeout
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
351
Working with Clusters and Match Rules
UDP Cluster Limitations
Layer 4 UDP clusters are appropriate for connectionless (stateless) applications, such as DNS,
TFTP, Voice over IP (VoIP), and streaming applications. UDP applications typically exchange short
packets with many clients, and typically provide faster network performance over TCP
applications, because UDP applications do not re-transmit dropped packets and do not perform
error checking.
Compared to Layer 7 clusters, UDP clusters share the same general limitations of Layer 4 TCP
clusters, the most important being:
1. SSL offload is not supported for UDP clusters. If you would like to use a secure UDP
application, you must install certificates directly on your physical servers rather than in the
UDP cluster.
2. IP-address based persistence is the only persistence type supported.
3. Match Rules are not supported.
There are also several limitations that apply only to UDP clusters and servers:
1. A UDP server can be used in exactly one UDP cluster. This means that all server pools
attached to all UDP clusters must contain UDP servers that each have a unique IP address.
2. UDP clusters can use only IPv4 addresses; all servers used by a UDP cluster must have IPv4
addresses.
3. You can't use ACV probes with UDP servers.
352
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Modifying a Layer 7 HTTP or HTTPS Cluster
On the GUI, the Configuration Summary for a layer 7 cluster is displayed automatically when a cluster
is added to the system, or by selecting the cluster from Cluster branch on the left navigation pane.
HTTP and HTTPS clusters parameters are modified using the following tabs:
l
Configuration including:Summary, Settings, Persistence , Timeouts, and Header Editing.
l
Reporting including:Statistics and Plotting
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
353
Working with Clusters and Match Rules
Layer 7 Cluster Configuration Summary
Layer 7 Cluster Summary is a snapshot of the cluster and all of its associated objects and the
status of the objects, as well as configured settings. It can be displayed using either the GUI or
the CLI.
Layer 7 HTTP, HTTPS, and TCP Cluster Configuration Summary Using the GUI
The Layer 7 Cluster Configuration Summary screen is displayed automatically as described in
"Modifying a Layer 7 HTTP or HTTPS Cluster" on page 353; when a cluster is added to the system,
or by selecting the cluster from the Cluster branch on the left navigation pane. This screen displays
a snapshot of the cluster and all of its associated objects (i.e., server pools, server instances and
responders), the status of the objects, the Active Connections, Connections/Second and
Transactions/Second.
A graphical plot is also displayed showing the traffic flow through the cluster from the past 30
minutes.
In addition you have the option to Disable the cluster by removing its IP address alias from the
interface in addition to disabling cluster traffic.
The sample below shows a sample of the Configuration Summary Screen for an HTTP cluster. The
Summary Screens for the HTTPS and Layer 7 TCP clusters are similar.
354
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 HTTP, HTTPS, and TCP Cluster Configuration Summary Using the CLI
Layer 7 HTTP, HTTPS, and TCP Cluster summary can be displayed using the CLI for either globally
or in the cluster context. The following is an example:
eqcli > show cluster cluster_http
L7 Cluster Name
: cluster_http
Protocol
: http
IP Address
: 4.8.12.16
Port
: 80
Preferred Peer
:
VID
: unassigned
Client Timeout
: 10
Server Timeout
: 60
Connection Timeout
: 10
Sticky Timeout
: 0
Sticky Netmask
: 32
Custom Header
:
Flags
: allow_utf8
Server Pool
: srvpool1
Responder
:
Cookie Path
:
Cookie Domain
:
Cookie Age
: 0
Cookie Generation
: 0
Persist Type
: coyote_cookie_2
Minimum Compression
: 1024
Compression mime_type : text/
*:application/msword:application/postscript:application/rtf:application/xcsh:application/x-javascript:application/x-sh:application/xshar:application/x-tar:application/xtcl:application/xslt+xml:audio/midi:audio/32kadpcm:audio/xwav:image/bmp:image/tiff:image/x-rgb
Config Header Edit Script :
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
355
Working with Clusters and Match Rules
Layer 7 HTTP and HTTPS Cluster Settings
The following are descriptions of the functionality and configuration parameters used with Layer 7
HTTP and HTTPS Clusters.
Parameters
The table below shows the parameters, values, and flags used in the configuration of HTTP and
HTTPS clusters.
GUI Parameter (CLI Parameter)
Description
Protocol
(proto)
The protocol selected in the Add Cluster form will be displayed “grayed
out”.
VID
(vid)
The VLAN ID number assigned to the VLAN on which the cluster resides.
Refer to Common Networking Scenarios for details.
IP
(ip)
Enter the IP address, which is the dotted decimal IP address of the
cluster. The IP address of the cluster is the external address (for
example, 172.16.0.201) with which clients connect to the cluster.
Port
(port)
For HTTP and HTTPS protocol clusters, enter the port: the numeric port
number on the Equalizer to be used for traffic between the clients and the
cluster. For HTTP clusters, the port is normally 80. For HTTPS clusters,
the port is normally 443. This port also becomes the default port for
servers added to the cluster (though servers can use a different port
number than the one used by the cluster).
Preferred Peer
(preferred_peer)
Used with Active-Active Failover. Refer to Configuring Active/Active
Failover Between Two Systems.
Server Pool
(srvpool)
A drop down list used to select a Server Pool, or grouping of servers, to
which the cluster will communicate with.
Responder
(resp)
A Responder is a server-like object that can be associated with a Match
Rule. If an incoming request satisfies a Match Rule expression and all of
the servers specified in the Match Rule are down, a Responder definition
in the Match Rule (if present) tells Equalizerto send one of two automatic
responses to the client.
Service Protection Profile
(cl_spp)
The drop down lists selects the Service Protection Profile to use for
monitoring traffic statistics through the cluster to prevent Denial of
Service attacks. Refer to "Setting Up" on page 681 for details on how the
cluster SPP is configured and how it works in preventing Denial of Service
attacks.
Custom Header
(custhdr)
A custom HTTP header that Equalizerinserts into all client requests before
they are sent to the server. The format of the string is text:text. Also see
Specifying a Custom Header for HTTP/HTTPS Clusters.
356
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
Compression Minimum Size
(ADCs with Hardware Acceleration)
(compress_min)
The minimum file size in bytes required for GZIP compression, if enabled.
Equalizeruses GZIP to compress the payload (or content) of the server
response before sending it back to the client. This is typically done for 2
reasons: faster client response and better user experience. In addition.
less ISP bandwidth is used in sending smaller files back to clients. Files
smaller than the minimum specified are not compressed. Default:1024
bytes.
Specifies the mime-types that will be compressed when the Compress
option is enabled for the cluster. The value of this parameter is a string
(maximum length: 512 characters) with valid mime-type names
separated by a colon (:). The default compress mime-types string
specifies the following mime-types
Compression MIME Types (ADCs
with Hardware Acceleration)
(compress_types)
Config Header Edit Script
(hdredit)
text/* application/msword
application/postscript
application/rtf
application/x-csh
application/x-javascript
application/x-sh
application/x-shar
application/x-tar
application/x-tcl
application/xslt+xml
audio/midi audio/32kadpcm
audio/x-wav
image/bmp
image/tiff
image/x-rgb
When you create header edits, you place the search and edit functions
within one of two meta-functions ( client_request_edit or server_
response_edit) the script will be displayed here.
Flags
Abort server
(abort_server)
By default, when a client closes a connection, Equalizerwaits for a
response from the server before closing the server connection. If this flag
is enabled, Equalizer will not wait for a response before closing the
connection to the server; instead it sends a TCP RST (reset) to the server
when the client closes the connection. This option will typically reduce the
number of server connections in the TIME_WAIT state, as shown by the
netstat console command.
Insert client IP
(insert_client_ip)
When this flag is enabled, Equalizer inserts an X-forwarded-for: header
with the client's IP address into all client requests before they are sent to
the server. This flag is disabled by default for HTTP clusters and enabled
by default for HTTPS clusters.
TCP Multiplexing
(tcp_mux)
This selection enables TCP multiplexing for a cluster. TCP multiplexing
must also be enabled on at least one server instance in the server pool
assigned to the cluster (or one of its match rules).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
357
Working with Clusters and Match Rules
GUI Parameter (CLI Parameter)
Description
Allow Multibyte Characters
(allow_utf8)
By default, support for extended characters (8-bit ASCII and multibyte
UTF characters) in URIs is disabled. Equalizer returns a 400 Bad Request
error when a request URI contains 8-bit or multibyte characters. To
enable support for 8-bit and multibyte characters in URIs, click this
checkbox. There are potential risks to enabling this option, because it
allows Equalizer to pass requests that violate RFC2396; load-balanced
servers may be running software that is incapable of handling such
requests. Therefore, ensure that your server software is capable of
handling URIs containing extended characters and will not serve as a
potential weak point in your network before you enable extended
characters.
When this option is enabled, Equalizer automatically detects requests to
the cluster from compression-capable browser clients and performs GZIP
compression on all cluster responses sent to that client. The cluster IP
address will not accept requests when this flag is enabled.
When enabled, hardware compression will be used on ADCs with
compression hardware on board and software compression will be used
on ADCs without compression hardware.
Compress (Not applicable to
E250GX)
(compress)
To view the compression type used on your appliance, do one of the
following:
1. At the CLI prompt, enter; eqcli > version . The compression type
used is displayed beside Features.
2. In the GUI, click on the System configuration tab, expand the Global
branch and click on Dashboard. The compression type will be displayed
beside Features in the System Information widget on the right.
NOTE: If downgrading to a version less than 10.3.x, and the compress
option is enabled, the compress flag will be disabled when downgrading
Once only
(once_only)
Limits Equalizer to parsing headers (and executing match rules) for only
the first request of any client making multiple requests across a single
TCP connection. This option is off by default: meaning that Equalizer will
parse the headers of every client request.
Rewrite Redirects (HTTPS Only)
(rewrite_redirects)
When enabled, forces Equalizer to pass responses from an HTTPS
cluster’s servers without rewriting them. In the typical Equalizer setup,
you configure servers in an HTTPS cluster to listen and respond using
HTTP; Equalizer communicates with the clients using SSL. If a server
sends an HTTP redirect using the Location: header, this URL most likely
will not include the https: protocol. Equalizer rewrites responses from the
server so that they are HTTPS. You can direct Equalizer to pass responses
from the server without rewriting them by enabling this option.
Ignore case
(ignore_case)
Applies to L7 clusters and is the global setting to ignore case in match
expressions. You can override this value per cluster and per match rule .
358
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
When the spoof option is enabled on a cluster, Equalizer uses the client’s
IP address as the source IP address in all packets sent to a server in that
cluster. This option is enabled by default.
Spoof
(spoof)
When spoof is enabled, all server responses to client requests that came
through the Equalizer cluster IP address must be routed by the server
back to the client through Equalizer. In many cases, the easiest way to do
this is to set the default gateway on the server with a server instance in a
server pool to Equalizer’s IP address on the server VLAN. If this is not
possible, you can establish static routes on the server to send responses
to specific client IP addresses to Equalizer’s IP address on the VLAN.
If you disable spoof, the server receiving the request will see Equalizer’s
IP address as the client address because the TCP connection to the client
is terminated when the request is routed. The server will therefore send
its response back to Equalizer’s IP address. Disabling the spoof option
enables Source Network Address Translation (SNAT).
Control whether Equalizer will process "CRL Distribution Point" extensions
in client certificates. This option only affects the processing of the "CRL
Distribution Point" extension in client certificates:
Ignore Critical Extensions (HTTPS
only- not shown above)
(ignore_critical_extns)
Server Side Encryption
(sse)
When Ignore Critical Extensions is disabled, a client certificate
presented to Equalizer that includes any extension will be rejected by
Equalizer . This is the behavior in previous releases.
When Ignore Critical Extensions is enabled (the default), a client
certificate presented to Equalizer that has a CRL Distribution Point
extension will be processed and the CRL critical extension will be ignored.
Note, however, that if other extensions are present in a client certificate
they are not ignored and will cause the client certificate to be rejected by
Equalizer.
Enables the Server Side Encryption option for the Cluster. By enabling
this option, Equalizer will encrypt packets to back end servers using the
SSL/TLS specifications in the Server Side Encryption Global Parameters
(See "Server Side Encryption" on page 291)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
359
Working with Clusters and Match Rules
Configuring Layer 7 HTTP or HTTPS Clusters Using the GUI
The Layer 7 Cluster Configuration Screen, as shown below, is displayed whey you select Load
Balance > Clusters and select a cluster from the branch. When you click on the Configuration tab,
the following will be displayed.
Use the table above for parameters, values, and flags for the configuration of an HTTP or HTTPS
cluster. Click on the Commit button after making changes to the settings.
Configuring Layer 7 HTTP or HTTPS Clusters Using the CLI
Layer 7 HTTP and HTTPS Clusters can be configured in the CLI either globally or in cluster context.
Enter parameters using the following format. eqcli > cluster clustername parameter value flags flag
Use the table above for descriptions of the parameters and values.
Where:
clustername - is the the name fo the cluster.
parameter - is the parameter.
value - is the value associated with the parameter.
flag - is the flag to be associated with the cluster.
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
360
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 Security Certificate Screen (HTTPS Clusters)
The HTTPS protocol supports encrypted, secure communication between clients and servers. It
requires that a Secure Sockets Layer (SSL) authentication handshake occur between a client and a
server in order for a connection request to succeed.
Certificates are loaded using either the GUI or the CLI.
Parameters
The table below shows the parameters, values, and flags that are used in the configuration of
Layer 7 HTTPS Cluster security.
GUI Parameter (CLI Parameter)
Descriptions
Default Certificate
(certificate)
Use the drop down list to select a default SSL certificate that clients will use
to validate a connection to this HTTPS cluster.
The Client CA is used to authenticate the SSL client certificate if the
Require Client Certificate option is enabled or if a CRL selection is
made.
Client CA
(clientca)
CRL
(crl)
Use the drop down list to select the name of a client certificate authority
(CA).This is the certificate of an authority in a network that issues and
manages security credentials and public keys for message encryption. It
must be uploaded to Equalizer's certificated store. As part of a public key
infrastructure, a CA checks with a registration authority to verify
information provided by the requester of a digital certificate. If the
registration authority verifies the requester's information, the CA can then
issue a certificate. The certificate usually includes the owner's public key,
the expiration date of the certificate, the owner's name, and other
information about the public key owner.
A Certificate Revocation List CRL is used to check if the SSL certificates
provided by the SSL client during the SSL handshake are not in the CRL
list. It requires the Client CA to be specified.
Use the drop down list to select a CRL.
Validation Depth
(valdepth)
The depth to which certificate checking is done on the client certificate
chain. The default of 2 indicates that the client certificate (level 0) and two
levels above it (levels 1 and 2) are checked; any certificates above level 2
in the chain are ignored. You should only need to increase this value if the
Certificate Authority that issued your certificate provided you with more
than 2 chained certificates in addition to your client certificate.
Flags
Push Client Certificate
(push_client_cert)
Enabling this option sends the client certificate to the back-end server.
Require Client Certificate
(require_client_cert)
Enabling this option requires that client's present certificates. The client
CA, if configured, validates the SSL certificate presented by the SSL client.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
361
Working with Clusters and Match Rules
GUI Parameter (CLI Parameter)
Descriptions
Strict CRL Chain
(strict_crl_chain)
This option requires the Client CA and CRL to be specified. If it is enabled
then it ensures that none of the certificates in the certificate chain of the
SSL client certificate are in the CRL. If the client CA and CRL are specified,
yet this option is not enabled, then only the last certificate in the certificate
chain of the SSL client certificate is checked against the specified CRL.
GUI Parameter (CLI Parameter)
Descriptions
Default Certificate
(certificate)
Use the drop down list to select a default SSL certificate that clients will use
to validate a connection to this HTTPS cluster.
The Client CA is used to authenticate the SSL client certificate if the
Require Client Certificate option is enabled or if a CRL selection is
made.
Client CA
(clientca)
CRL
(crl)
Use the drop down list to select the name of a client certificate authority
(CA).This is the certificate of an authority in a network that issues and
manages security credentials and public keys for message encryption. It
must be uploaded to Equalizer's certificated store. As part of a public key
infrastructure, a CA checks with a registration authority to verify
information provided by the requester of a digital certificate. If the
registration authority verifies the requester's information, the CA can then
issue a certificate. The certificate usually includes the owner's public key,
the expiration date of the certificate, the owner's name, and other
information about the public key owner.
A Certificate Revocation List CRL is used to check if the SSL certificates
provided by the SSL client during the SSL handshake are not in the CRL
list. It requires the Client CA to be specified.
Use the drop down list to select a CRL.
Validation Depth
(valdepth)
The depth to which certificate checking is done on the client certificate
chain. The default of 2 indicates that the client certificate (level 0) and two
levels above it (levels 1 and 2) are checked; any certificates above level 2
in the chain are ignored. You should only need to increase this value if the
Certificate Authority that issued your certificate provided you with more
than 2 chained certificates in addition to your client certificate.
Flags
Push Client Certificate
(push_client_cert)
Enabling this option sends the client certificate to the back-end server.
Require Client Certificate
(require_client_cert)
Enabling this option requires that client's present certificates. The client
CA, if configured, validates the SSL certificate presented by the SSL client.
Strict CRL Chain
(strict_crl_chain)
This option requires the Client CA and CRL to be specified. If it is enabled
then it ensures that none of the certificates in the certificate chain of the
SSL client certificate are in the CRL. If the client CA and CRL are specified,
yet this option is not enabled, then only the last certificate in the certificate
chain of the SSL client certificate is checked against the specified CRL.
362
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
If you have uploaded a certificate that doesn't match the cipher suite that is configured for
the HTTPS cluster, you will no longer be able to log into the GUI. You will need to supply the
correct certificate/key pairing. In the meantime, you can enable HTTP access to the GUI
temporarily to enter the proper certificate/key pairing to enable HTTPS access.
Loading Certificates Using the GUI
The Layer 7 Security > Certificate screen shown below is available when an HTTPS cluster is selected
from the Cluster branch on the left navigational pane.
Use the Security > Certificate tab to select a default SSL certificate that clients will use to validate a
connection to an HTTPS cluster (a cluster certificate).
Use the table above for parameters, values, and flags for the configuration of HTTPS cluster
certificates. Click on the Commit button after making changes to the settings.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
363
Working with Clusters and Match Rules
Loading Certificates Using the CLI
Layer 7 HTTPS cluster certificates can be configured in the CLI either globally or in cluster
context. Enter parameters using the following format. eqcli > cluster clustername certificate certificate name flags flag
Use the table above for descriptions of the parameters and values. The certicate commands can
only be entered if the protocol (proto) is https.
clustername - is the the name fo the cluster.
certificate name - is the name of the certificate being uploaded.
flag - is the flag to be associated with the cluster.
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
364
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 SSL Security (HTTPS Clusters)
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are
cryptographic protocols that provide secure communications across HTTPS clusters.
A cipher is an algorithm that performs encryption or decryption. It transforms plain text into a
coded set of data (cipher text) that is not reversible without a key. For example, AES and DES are
examples of secret key block ciphers. The complete encryption algorithm is the cipher plus the
protocol used to apply the cipher to the message.
The Cipher Suites for an HTTPS cluster lists all of the ciphers that can be negotiated between
Equalizer and an incoming client attempting to connect to an HTTPS cluster. Similarly, the client
application will have its own list of ciphers that it supports. The client and Equalizer need to go
through a process of negotiating the cipher that will be used for the client connection -- if they
cannot find a match, the connection will fail. The process of negotiating a cipher for a client
connection is as follows:
1. During the SSL handshake phase of the connection, the client sends Equalizer a list of the
ciphers it supports.
2. Equalizer examines the client cipher list in the order it is specified, chooses the first cipher
that matches a cipher specified in the cluster’s cipher suite parameter, and responds to the
client. If none of the ciphers offered by the client are in the cipher suite list for the cluster,
the SSL handshake fails.
It is therefore vital that you ensure that there is at least one match between the list of ciphers
supported by clients connecting to an HTTPS cluster and the cipher suite list for the cluster.
List of Configured Ciphers
The following is list of the default configured ciphers that are presented to clients:
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-DES-CBC3-SHA
AES128-SHA
DES-CB3-SHA
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
365
Working with Clusters and Match Rules
The following is a list of available cipher strings that can be added to the configured ciphers list
and made available to the clients:
Available Ciphers
3DES
ADH-AES128-GCM-SHA256
ADH-AES128-SHA
ADH-AES128-SHA256
ADH-AES256-GCM-SHA384
ADH-AES256-SHA
ADH-AES256-SHA256
ADH-CAMELLIA128-SHA
ADH-CAMELLIA256-SHA
ADH-DES-CBC-SHA
ADH-DES-CBC3-SHA
ADH-RC4-MD5
ADH-SEED-SHA
AECDH-AES128-SHA
AECDH-AES256-SHA
AECDH-DES-CBC3-SHA
AECDH-RC4-SHA
AES
AES128
AES128-GCM-SHA256
AES128-SHA256
AES256
AES256-GCM-SHA384
AES256-SHA256
AESGCM
ALL
CAMELLIA
CAMELLIA128-SHA
CAMELLIA256-SHA
DES
DES-CBC-MD5
DES-CBC-SHA
DES-CBC3-MD5
DHE
DHE-DSS-AES128-GCMSHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
DHE-DSS-AES256-GCMSHA384
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
DHE-DSS-CAMELLIA128-SHA
DHE-DSS-CAMELLIA256-SHA
DHE-DSS-SEED-SHA
DHE-RSA-AES128-GCMSHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-GCMSHA384
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DHE-RSA-CAMELLIA128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-SEED-SHA
ECDH
ECDH-ECDSA-AES128-GCMSHA256
ECDH-ECDSA-AES128-SHA
ECDH-ECDSA-AES128SHA256
ECDH-ECDSA-AES256-GCMSHA384
ECDH-ECDSA-AES256-SHA
ECDH-ECDSA-AES256-SHA384
ECDH-ECDSA-DES-CBC3SHA
ECDH-ECDSA-RC4-SHA
ECDH-RSA-AES128-GCMSHA256
ECDH-RSA-AES128-SHA
ECDH-RSA-AES128-SHA256
ECDH-RSA-AES256-GCMSHA384
ECDH-RSA-AES256-SHA
ECDH-RSA-AES256-SHA384
ECDH-RSA-DES-CBC3-SHA
ECDH-RSA-RC4-SHA
ECDHE
ECDHE-ECDSA-AES128-GCMSHA256
ECDHE-ECDSA-AES128SHA
ECDHE-ECDSA-AES128SHA256
ECDHE-ECDSA-AES256-GCMSHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256SHA384
ECDHE-ECDSA-DES-CBC3SHA
ECDHE-ECDSA-RC4-SHA
ECDHE-RSA-AES128-GCMSHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCMSHA384
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES256SHA384
ECDHE-RSA-DES-CBC3-SHA
ECDHE-RSA-RC4-SHA
ECDSA
EDH
EDH-DSS-DES-CBC-SHA
EDH-DSS-DES-CBC3-SHA
EDH-RSA-DES-CBC-SHA
EDH-RSA-DES-CBC3-SHA
EXP
EXP-ADH-DES-CBC-SHA
EXP-ADH-RC4-MD5
EXP-DES-CBC-SHA
EXP-EDH-DSS-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-RC2-CBC-MD5
EXP-RC4-MD5
EXPORT
HIGH
IDEA-CBC-MD5
IDEA-CBC-SHA
LOW
MD5
MEDIUM
PSK-3DES-EDE-CBC-SHA
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
PSK-RC4-SHA
RC2-CBC-MD5
RC4
RSA
SEED-SHA
SHA
SHA1
SHA256
SHA384
SRP-3DES-EDE-CBC-SHA
SRP-AES-128-CBC-SHA
SRP-AES-256-CBC-SHA
SRP-DSS-3DES-EDE-CBC-SHA
SRP-DSS-AES-128-CBCSHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-RSA-AES-256-CBC-SHA
TLSv1
TLSv1.2
366
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Parameters
The table below shows the parameters and values used in the configuration of HTTPS cluster
security.
GUI Parameter (CLI Parameter)
Description
Configured Cipher List
(cipherspec)
This is used to set the cipher spec for an HTTPS cluster.
In the GUI, this is the list of ciphers presented to clients for encrypted
cluster connections. (see "Configuring Layer 7 SSL Security Using
the GUI" on the next page)
In the CLI, this is used to enter cipher specs.(see "Configuring Layer 7
SSL Security Using the CLI" on the next page)
The order of the suites in the ciphers list indicates the order in which a
cipher is selected for the incoming connection. During the SSL handshake
phase of the connection, the client sends a list of the ciphers it supports. The
ADC chooses the first cipher in the cluster's configured cipher list that
matches a cipher specified by the client. If none of the ciphers offered by the
client are in the cluster's configured cipher list, the SSL handshake fails.
Flags
This flag appears only on systems that are equipped with Hardware SSL
Acceleration. When enabled, it specifies that all SSL operations will be
performed in software, instead of being performed using the SSL accelerator
hardware. This flag does not appear on systems that are not equipped with
Hardware SSL Acceleration, since on these units SSL operations are always
performed in software. This flag is disabled by default.
Software SSL Only
(software_ssl_only)
(not applicable on E250GX)
All units with Hardware SSL Acceleration can process the TLSv1.0, TLSv1.1,
and TLSv1.2 protocols in both hardware and software, except for legacy GX
hardware. On legacy GX hardware, only TLSv1.0 is supported by Hardware
SSL Acceleration; if you want to enable TLSv1.1 or TLSv1.2 on GX hardware,
you must first enable this flag.
Please note that enabling this option will reduce the processor and memory
resources generally available for processing cluster traffic, since performing
SSL operations in software requires use of the system CPU and system
memory (instead of the dedicated SSL acceleration hardware CPU and
memory).
Allow SSLv3
(allow_sslv3)
Enables SSLv3 for client connections. This option is enabled by default.
Allow TLS 1.0
(allow_tls10)
This option enables and disables support for the TLSv1.0 protocol. Enabled
by default. If multiple TLS versions are enabled, the first supported TLS
version negotiated by a client will be used.
Allow TLS 1.1
(allow_tls11)
This option enables and disables support for the TLSv1.1 protocol. Disabled
by default. If multiple TLS versions are enabled, the first supported TLS
version negotiated by a client will be used. (Enabled by default on LX Series)
Allow TLS 1.2
(allow_tls12)
This option enables and disables support for the TLSv1.2 protocol. Disabled
by default. If multiple TLS versions are enabled, the first supported TLS
version negotiated by a client will be used. (Enabled by default on LX Series
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
367
Working with Clusters and Match Rules
Configuring Layer 7 SSL Security Using the GUI
The Layer 7 SSL Security screen is used to configure TLS/SSL protocol and ciphers that are used by
Equalizer to communicate with clients over HTTPS clusters. Select Load Balance > Clusters > HTTPS
Cluster > Security > SSL from the left navigational pane to display it. The purpose of this screen is to
select the cryptographic protocol to use with the cluster and to select the cipher suite
authentication that Equalizer will present to clients (Configured Ciphers List ). A list of additional
ciphers is available in Available Cipher Strings that can be dragged into the Configured Cipher List and
presented to clients.
The screen below is an example of a Security > SSL screen on an ADC that is equipped with
Hardware SSL Acceleration. When enabled, it specifies that all SSL operations will be performed
in software, instead of being performed using the SSL accelerator hardware. This option does not
appear on systems that are not equipped with Hardware SSL Acceleration, since on these units
SSL operations are always performed in software.
The Software SSL Only option is disabled by default on ADC's with Hardware SSL Acceleration.
The Allow TLSv1.2, Allow TLSv1.1, and Allow TLSv1.0. options are all enabled by default on ADC's with
Hardware SSL Acceleration. If multiple TLS versions are enabled, the first supported TLS version
negotiated by a client will be used.
The Allow TLSv1.0 and Allow SSLv3 options are enabled by default on ADC's without Hardware SSL
Acceleration.
To add ciphers to the Configured Cipher List , select a cipher from the Available Cipher Strings list and
drag it to the Configured Ciphers List . Hold down the Shift key to select multiple ciphers.
Use the table above for additional information on the parameters, values, and flags for the SSL
configuration of an HTTPS cluster. Click on the Commit button after making changes to the settings.
Configuring Layer 7 SSL Security Using the CLI
368
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 HTTPS Security can be configured in the CLI either globally or in cluster context. Enter
parameters using the following format. eqcli > cluster cipherspec cipherspec flags flag
Use the table above for descriptions of the parameters and values.
Where:
cluster_name - is the name of the cluster.
cipherspec- is the cipherspec that Equalizer will present to clients. To specifically exclude a
cipher suite, use an exclamation point (!). For example, SSLv2 encryption is supported by default.
If your servers are required to support medium and high encryption using SSLv3 only, you can
add “!SSLv2” to the cipher suite. For example:
ES128-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:AES256-SHA:!SSLv2:SSLv3
flag - is the flag to be associated with the cluster. When configuring Layer 7 SSL security, this
option is used to select the cryptographic protocol (allow_tls10, allow_tls11, allow_tls12,
allow_sslv3) As described above, the allow_tls12, allow_tls11, and allow_tLSv10 options
are all enabled by default on ADC's with Hardware SSL Acceleration. If multiple TLS versions are
enabled, the first supported TLS version negotiated by a client will be used. The allow_tls1.0
and allow_sslv3 options are enabled by default on ADC's without Hardware SSL Acceleration.
Use the table above for additional information on the parameters, values, and flags for the SSL
configuration of an HTTPS cluster.
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
369
Working with Clusters and Match Rules
Layer 7 HTTP and HTTPS Cluster Persistence
Equalizer can use cookies or a server’s IP address to maintain a persistent session between a
client and a particular server. A cookie is included with the server’s response header on its way
back to the client. This cookie uniquely identifies the server to which the client was just
connected. Equalizer routes the first request from a client using load balancing criteria;
subsequent client requests are routed to the same selected server for the entire session (while
the cookie is valid -- see Cookie Age, above). In that way, a server’s IP address can alternately be
embedded into a response header that identifies the server.
You can also configure both cookie and source IP persistence on a cluster, which provides
"fallback persistence". Fallback persistence allows you to provide a secondary method of
persistence to use, in case the first method fails. For example, let's say you have Cookie
persistence followed by Source IP persistence defined on a cluster. Let's also say that the client's
browser has been configured by the user to block cookies received from websites. When the client
sends its first request, a cookie is added to the request by the ADC before it is sent to the server.
The server then responds back, and that cookie goes back to the client in the server response.
When the client sends its next request to the cluster, the client browser strips the cookie from the
request. When the client request is received by the cluster, it expects there to be a cookie, but
there is none. Because the cluster is configured with fallback persistence, it will now use Source
IP persistence instead.
Persistence options on an HTTP or HTTPS cluster are configured using either the GUI or the CLI.
Persistence Parameters
The table below shows the parameters, values, and flags used in the configuration of HTTP and
HTTPS cluster persistence.
Cookie Type
Description
Cookie 0:Cluster IP/Port, Server IP/Port
Constructs a cookie which will be named in such a way that so
as long as the cluster maintains the same IP address, servers
can be added to and removed from the cluster without
invalidating all of the existing cookies. This cookie stores
the cluster IP and port, and the server IP and port.
Cookie 1:Cluster IP, Server IP /Port
Constructs a cookie which will be valid across all clusters with
the same IP address (not port specific). A requirement for
this to be useful is that all clusters on that IP address share
the same set of servers. This cookie stores the Cluster
IP, and Server IP and port.
Cookie 2:Cluster IP, Server IP
Constructs a cookie which will be valid across all clusters with
the same IP address (using any port), and the same server
within those clusters (with the server using any port). A
requirement for this to be useful is that all clusters on that IP
address share the same set of servers. This cookie stores
the Cluster IP and Server IP.
Source IP
The Source IP address of the server will be embedded in the
response header back to the client.
370
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Cookie Type
Description
Cookie Parameters
(The Cookie Parameters pane will expand if a cookie scheme is enabled.)
Cookie Parameter
Description
Cookie age
The Cookie age sets the time, in seconds, over which the
client browser maintains the cookie (“0” means the cookie
never expires). After the specified number of seconds have
elapsed, the browser deletes the cookie and any subsequent
client requests will be handled by Equalizer’s load-balancing
algorithms
Cookie path
If a Cookie Path is specified, Equalizer honors cookies in a
client requests only when the path component of the request
URI has the same prefix as that of the specified Cookie Path.
For example, if the cookie path is /store/, Equalizer presents
the cookie to the server only if the request URI includes a path
such as /store/ mypage.html.
Cookie Domain -
If a cookie domain is specified, then Equalizer will honor
cookies in client requests only if the server’s host name is
within the specified domain. For example, if the cookie
domain is website.com, then Equalizer will only present the
cookie to servers in the website.com domain (for example
www.website.com). Wildcards are not supported in the
cookie domain.
Cookie Generation -
A value added to cookies when the cookie scheme is 2. In
order for cookies to be valid, the specified Cookie
Generation must match the equivalent number embedded in
the cookie. Conversely, if you need to invalidate old cookies,
increment this number.
Always
When this flag is disabled Equalizer will insert a cookie if a
server was not selected based on a cookie received from the
client. A cookie would only be inserted when a new client is
seen or if cookie is received or if a cookie received cannot
validate a server.
If the Always flag is enabled, Equalizer includes a cookie in
the response regardless of whether the server sent a cookie.
Source IP Parameters
(The Source IP pane will expand if Source IP is moved to the Enabled pane.)
Sticky Timeout
The number of seconds that Equalizer should “remember”
connections from clients) Valid values are from 0 (which
disables sticky connections) to 1073741823 seconds (or over
34 years).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
371
Working with Clusters and Match Rules
Cookie Type
Sticky Netmask
Description
Enables sticky network aggregation for a subnet. Sticky
network aggregation is applicable for Layer 4 and Layer 7
clusters. Sticky network aggregation enables Equalizer to
correctly handle sticky connections from ISPs that use
multiple proxy servers to direct user connections. When you
enable sticky network aggregation, all the connections
coming from a particular network are directed to the same
server. (Typically, all the servers in a proxy farm are on the
same network.) The sticky netmask value indicates which
portion of the address Equalizer should use to identify
particular networks. Values are:
0-32 for IPV4 clusters (default=32)
0-128 for IPV6 clusters
Inter cluster Sticky
With the inter-cluster sticky option, you can configure
Equalizer to direct requests from a client to the same server
on any available port that has a current persistent connection
in any cluster. Inter-Cluster Sticky is a Layer 4 or Layer7
option that allows you to extend Layer 4 or Layer 7
persistence across multiple server ports.
Note - Inter-Cluster Sticky does not work for stickiness between a Layer 4 and a Layer 7 cluster only between a Layer
4/Layer 4 cluster or a Layer7/Layer 7 cluster.
Note - If you are using two Equalizer in a failover configuration, you must set the sticky network aggregation mask
identically on both Equalizers.
372
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Selecting a cluster from the left navigational pane on the GUI and selecting the Persistence tab to
display the screen shown below.
There are three configuration panes on this screen. Persistence Methods, Cookie Parameters and Source
IP Parameters.
Persistence Methods
In the Persistence Methods pane area, an Enabled area and a Disabled area are used. One
Persistence Type method and one Fallback Persistence Type only can be enabled. Enable and
order persistence methods by dragging and dropping from between the Disabled area and the
Enabled area. Arrange the order between the primary persistence method and the “fallback”
persistence method by dragging and dropping as well. As indicated previously, with “fallback
persistence” Equalizer provides a secondary option where if, for example, a cookie response is
not received, a secondary, or “fallback” option such as Source IP can be used.
The cookie scheme specifies the format of the cookie to be used for the cluster as an integer
between 0 and 2 (default is 2).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
373
Working with Clusters and Match Rules
Sticky Record Behavior
"Sticky" connections are managed on Equalizer using "Sticky Records" that record the IP address,
port and other information for the client-server connection. When you enable sticky connections,
the memory and CPU overhead for a connection increase. Sticky records are deleted as follows:
1. If cluster is deleted, the IP changes, or the port changes-- all source IP sticky records for
that cluster are deleted.
2. If server is deleted -- all source IP sticky records for the server are deleted.
3. If server is marked down -- all source IP sticky records for the server are deleted .
4. If server instance weight is set to "0" -- all source IP sticky records for the server are
deleted.
5. If server instance is marked "DOWN" -- all source IP sticky records for the server are
deleted.
To verify that sticky records have been removed after any of the above scenarios were done,
view the statistics in either the CLI or the GUI and observe the CURRSTKY (Current Sticky Records in
the GUI) statistic to verify that the sticky records value is "0".
The following is an example of an https cluster using the CLI:
eqcli > cluster cl-https stats
Current
TOTALPRCSD
3
TOTALRESPPRCSD
3
TIMESPENT
78
ACTIVECONX
1
BYTERCVD
97
BYTESEND
993
DROPNOSRVR
0
TOTALSTKY
0
CURRSTKY
1
374
60 sec
0.02
0.02
N/A
0.17
N/A
N/A
N/A
N/A
0.17
10 min
0.01
0.01
N/A
0.05
N/A
N/A
N/A
N/A
0.17
60 min
0.01
0.01
N/A
0.05
N/A
N/A
N/A
N/A
0.17
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Change the Cluster IP from 172.16.165.11 to 172.16.165.12:
eqcli > cluster cl-https ip 172.16.165.12
eqcli: 12000287: Operation successful
eqcli > cluster cl-https stats
Current
60 sec
TOTALPRCSD
3
0.02
TOTALRESPPRCSD
3
0.02
TIMESPENT
78
N/A
ACTIVECONX
0
0.17
BYTERCVD
97
N/A
BYTESEND
993
N/A
DROPNOSRVR
0
N/A
TOTALSTKY
0
N/A
CURRSTKY
0
0.33
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
10 min
0.00
0.00
N/A
0.05
N/A
N/A
N/A
N/A
0.19
60 min
0.00
0.00
N/A
0.05
N/A
N/A
N/A
N/A
0.19
375
Working with Clusters and Match Rules
Fallback Persistence Scenarios
The table below shows all of the possible persistence scenarios and the resulting load balancing
server selections based on the persist types and fallback persist types that are “enabled”.
Persist Type
Fallback Persist Type
Result
[none]
[none]
The server is selected on the load balancing
Policy/Algorithm.
[none]
Source IP
invalid configuration
[none]
Cookie 0:Cluster IP/Port,
Server IP/Port
invalid configuration
[none]
Cookie 1:Cluster IP,
Server IP /Port
invalid configuration
[none]
Cookie 2:Cluster IP,
Server IP
invalid configuration
Source IP
[none]
A server is selected on a sticky record (Source IP).
If no records are found a server is selected and a
new sticky record is created.
Source IP
Source IP
invalid configuration
Cookie 0:Cluster IP/Port,
Server IP/Port
A server is selected on a sticky record(Source IP).
If no records are found a server is selected on the
basis of the cookie and if the cookie is anything other
than Cookie 0:Cluster IP/Port, Server IP/Port a server
is selected using the Load balancing
Policy/Algorithm.
Cookie 1:Cluster IP,
Server IP /Port
A server is selected on a sticky record(Source IP).
If no records are found a server is selected on the
basis of the cookie and if the cookie is anything other
than Cookie 1:Cluster IP, Server IP /Port a server is
selected using the Load balancing Policy/Algorithm.
Cookie 2:Cluster IP,
Server IP
A server is selected on a sticky record(Source IP).
If no records are found a server is selected on the
basis of the cookie and if the cookie is anything other
than Cookie 2:Cluster IP, Server IP a server is
selected using the Load balancing Policy/Algorithm.
[none]
A server is selected based on the cookie
If no cookie or a cookie other then Cookie 0:Cluster
IP/Port, Server IP/Port is in the request the server is
selected using the Load balancing Policy/Algorithm.
Source IP
Source IP
Source IP
Cookie 0:Cluster IP/Port,
Server IP/Port
376
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Persist Type
Fallback Persist Type
Result
Cookie 0:Cluster IP/Port,
Server IP/Port
Source IP
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 0:Cluster
IP/Port, Server IP/Port is in the request, a server is
selected on the basis of the sticky record(Source IP).
If no records are found a server is selected and a
new sticky record is created.
Cookie 0:Cluster IP/Port,
Server IP/Port
Cookie 0:Cluster IP/Port,
Server IP/Port
invalid configuration
Cookie 1:Cluster IP,
Server IP /Port
A server is selected based on the cookie.
If no cookie or a cookie other then coyote_cooke_0 or
Cookie 1:Cluster IP, Server IP /Port is in the request
the server is selected using the Load balancing
Policy/Algorithm.
Cookie 0:Cluster IP/Port,
Server IP/Port
Cookie 2:Cluster IP,
Server IP
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 0:Cluster
IP/Port, Server IP/Port or Cookie 2:Cluster IP, Server
IP is in the request the server is selected using the
Load balancing Policy/Algorithm.
Cookie 1:Cluster IP,
Server IP /Port
[[none]]
A server is selected based on the cookie.
If no cookie is in the request the server is selected
using the Load balancing Policy/Algorithm.
Cookie 1:Cluster IP,
Server IP /Port
Source IP
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 1:Cluster
IP, Server IP /Port is in the request, a server is
selected based on the sticky record(Source IP).
If no records are found a server is selected and a
new sticky record is created.
Cookie 1:Cluster IP,
Server IP /Port
Cookie 0:Cluster IP/Port,
Server IP/Port
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 1:Cluster
IP, Server IP /Port, Server IP/Port or Cookie 0:Cluster
IP/Port, Server IP/Port is in the request a server is
selected using the Load balancing Policy/Algorithm.
Cookie 1:Cluster IP,
Server IP /Port
Cookie 1:Cluster IP,
Server IP /Port
invalid configuration
Cookie 1:Cluster IP,
Server IP /Port
Cookie 2:Cluster IP,
Server IP
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 1:Cluster
IP, Server IP /Port or Cookie 2:Cluster IP, Server IP is
in the request a server is selected using the Load
balancing Policy/Algorithm.
Cookie 2:Cluster IP,
Server IP
[none]
A server is selected based on the cookie.
If no cookie is in the request a server is selected
using the Load balancing Policy/Algorithm.
Cookie 0:Cluster IP/Port,
Server IP/Port
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
377
Working with Clusters and Match Rules
Persist Type
Fallback Persist Type
Result
Source IP
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 2:Cluster
IP, Server IP is in the request, a server is selected
based on the on sticky record(Source IP).
If no records are found a server is selected and a
new sticky record is created.
Cookie 0:Cluster IP/Port,
Server IP/Port
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 2:Cluster
IP, Server IP or Cookie 0:Cluster IP/Port, Server
IP/Port is in the request a server is selected using
the Load balancing Policy/Algorithm.
Cookie 2:Cluster IP,
Server IP
Cookie 1:Cluster IP,
Server IP /Port
A server is selected based on the cookie.
If no cookie or a cookie other then Cookie 2:Cluster
IP, Server IP or Cookie 1:Cluster IP, Server IP /Port is
in the request a server is selected using the Load
balancing Policy/Algorithm.
Cookie 2:Cluster IP,
Server IP
Cookie 2:Cluster IP,
Server IP
invalid configuration
Cookie 2:Cluster IP,
Server IP
Cookie 2:Cluster IP,
Server IP
378
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Side Encryption
Note - Server Side Encryption is not supported on GX Series Equalizers.
In a potentially dangerous scenario, you may be load balancing traffic and forwarding it to backend servers along untrusted paths. Vital credit card and personally identifying information could
be vulnerable during its back-end transit to clients unless you-encrypt it. Server Side Encryption
(SSE) provides you with the ability to configure a cluster and/or match rule so that traffic between
Equalizer and back end servers is encrypted using SSL/TLS, eliminating the untrusted paths.
A client’s HTTPS request is encrypted along its path from the client to Equalizer. Equalizer
terminates the SSL/TLS connection with the client, decrypts the client request using a certificate
and key and then forwards unencrypted HTTP traffic to the servers. When the server replies, the
server connects with Equalizer via clear text HTTP. Equalizer, then encrypts the response and
forwards it via HTTPS back to the client. Using SSE, the vulnerable path between your appliance
and servers can be encrypted by enabling cluster options.
With Equalizer, Match Rules extend the Layer 7 load balancing capabilities of HTTP and HTTPS
clusters by allowing you to define a set of logical conditions which, when met by the contents of
the request, trigger the load balancing behavior specified in the match rule.You have the option of
utilizing this intelligence as you have the capability of encrypting packets specifically identified by
the match rule definitions.
The illustration below shows the SSL/TLS handshake process used with an encrypted connection
between a client and Equalizer and the same process with SSE enabled between Equalizer and
servers.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
379
Working with Clusters and Match Rules
Equalizer provides configuration options, whereby you could encrypt all traffic between the
servers and your appliance or content-specific traffic, based on a match rule.The table below
explains possible Cluster/Match Rule encryption scenarios:
Cluster/Match Rule Encryption Enabled
Usage
Cluster Enabled/Match Rule Enabled
Used to encrypt all packet transfers between Equalizer and all of your
servers.
Cluster Enabled/Match Rule Disabled
Used to encrypt all packet transfers from Equalizer, regardless of
match rule definitions.
Cluster Disabled/Match Rule Enabled
Used to encrypt only those packets specified by the enabled match
rule definition.
General Configuration Process
Note - Server Side Encryption is not supported with servers using IPv6.
The general configuration process for configuring your appliance for SSE is:
1. Set the listening port on your servers.
2. Configure Equalizer's Global > Server Side Encryption Cipher Suite and TLS parameters.
3. Configure cluster options for SSE.
4. Configure match rule options for SSE.
Note -The spoof and TCP Multiplexing (tcp_mux) options will not be available on http or https clusters or match
rules if the Server Side Encryption (sse) option is enabled on the cluster and/or match rule
Proceed with the following to configure your appliance for SSE using the CLI and GUI:
380
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring SSE Using the GUI
1. Log in to the GUI.
Global Cipher Suite and TLS Configuration
First, you will need to enable SSE on your Equalizer on a global level.
2. Select System > Global > Server Side Encryption on the left navigational pane.The following will be
displayed on the right configuration pane.
3. Enter the cipher suite (set of cipher specifications) to use in the encryption in the Cipher
Suites box. A default cipher suite is used by default (AES128-SHA:DES-CBC3-SHA:RC4SHA:RC4-MD5:AES256-SHA:!SSLv2).
Note - SSLv2 is not supported as Equalizer will not negotiate with packets using SSLv2 encyrption.
4. Add additional Cipher Suites as described in "Layer 7 SSL Security (HTTPS Clusters)" on page
365 as necessary.
5. Enable each TLS version that you wish to use. For example, if you select only Allow TLSv1.1,
this will be the only allowable TLS version used with the Cipher Suite. Select Allow TLSv1.0
and/or Allow TLSv1.2 as needed. At least one encryption type must be selected.
6. Click on Commit to save your settings.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
381
Working with Clusters and Match Rules
Configuring SSE Using the CLI
Set the Server Listening Port
1. Verify that your back-end servers are configured for encrypted connections — if they are
not, the connection will fail. Configure the listening port number (typically port 443 for
HTTPS) for each server. Refer to "Adding and Modifying Servers" on page 506 for details.
Global Cipher Suite and TLS Configuration
First, you will need to enable SSE on your Equalizer on a global level.
2. Enter the cipher suite (set of cipher specifications) to use in the encryption.
eqcli > sse cipherspec cipher_spec
cipher_spec is the cipher suite to use. This is passed from the client to the server in
the Client Hello message. It contains the combinations of cryptographic algorithms
supported by the client in order of the client's preference (first choice first). Each
cipher suite defines both a key exchange algorithm and a cipher spec. The server
selects a cipher suite or, if no acceptable choices are presented, returns a handshake
failure alert and closes the connection.Once you add an https cluster, a default cipher
suite will be added (AES128-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:AES256SHA:!SSLv2).
Note - SSLv2 is not supported as Equalizer will not negotiate with packets using SSLv2 encyrption.
Add additional cipher specs as described in "Cluster and Match Rule Commands" on
page 198 and "Layer 7 SSL Security (HTTPS Clusters)" on page 365 as necessary.
3. Now, enter the allowable TLS versions for use with the cipher_spec.
eqcli > sse flags tls_flags
where tls_flags can be allow_tls10 (TLS version 1.0), allow_tls11 (TLS version
1.1) or allow_tls12 (TLS version 1.2). You must add each TLS version that you wish
to use. For example, if you add only TLS version 1.1, this will be the only allowable
TLS version used with the cipher spec.
382
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 Cluster Reporting
Refer to "Cluster and Match Rule Statistics and Reporting (CLI and GUI)" on page 446 for details.
Layer 7 Cluster Timeouts
The Layer 7 Cluster Timeouts screen is used to configure timeouts used in cluster connection with
clients and servers.
Timeouts can be configured using either the GUI or the CLI.
Parameters
The table below shows the timeouts used in the configuration of Layer 7 clusters.
GUI Parameter (CLI Parameter)
Description
Client Timeout (clientto)
The time in seconds that Equalizer waits before closing an idle client
connection. The default is the global value. (between 1 and 65535 seconds)
Server Timeout (serverto)
The time in seconds that Equalizer waits before closing an idle server
connection. The default is the global value. (between 1 and 65535 seconds)
Connect Timeout (connto)
The time in seconds that Equalizer waits for a server to respond to a
connection request. The default is the global value.
Configuring Layer 7 Cluster Timeouts Using the GUI
Layer 7 Cluster timeouts are configured on the Timeouts screen. This can be accessed by selecting
Load Balance > Clusters and then selecting a cluster. Clicking on the Timeouts tab will display the
following.
Use the table above for timeout parameters. Click on the Commit button after making changes to
the settings.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
383
Working with Clusters and Match Rules
Configuring Layer 7 Cluster Timeouts Using the CLI
Cluster timeouts can be configured in the CLI either globally or in cluster context. Enter
parameters using the following format. eqcli > cluster clustername {cliento|serverto|connto value
Use the table above for descriptions of the parameters and values.
Where:
clustername - is the name of the cluster.
value - is the value associated with the client timeout, server timeout, or connection timeout.
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
384
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Name Indication
Server Name Indication (SNI) is an extension to the SSL and TLS protocols that indicates a server
name or website that a client is attempting to connect with at the start of the handshake process.
It allows a server to present multiple certificates on the same IP address and port number, thus
allowing multiple secure (HTTPS) websites to be server of the same IP address while allowing all
of those sites to have unique certificates all serviced on the same cluster/IP address.
SNI objects are added to certificates that are in the certificate store on Equalizer and are
configured on HTTPS clusters.After a client connects with a TCP port on the load balancer, it
searches it's certificate store for the website name that was exchanged as part of the HTTPS
packet header. If the website is NOT presented on a certificate, the cluster's default certificate
will be returned to the client. If the website IS presented on a certificate, that certificate will be
returned to the client. Using SNI, additional websites are associated with certificates allowing a
certificate to be returned to a client for multiple website requests, thus minimizing the need to
purchase costly wild card certificates.
The following illustration shows the connection and certificate process with Equalizer and an
HTTPS cluster:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
385
Working with Clusters and Match Rules
Server Name Indication Using the GUI
Proceed with the following to configure SNI certificates on an HTTPS cluster using the GUI:
1. Configure an HTTPS cluster on Equalizer. Use the GUI as described in "Adding and Deleting
Clusters" on page 331
2. Add a default certificate to the cluster.as described in "Layer 7 Security Certificate Screen
(HTTPS Clusters)" on page 361 if one has not been added previously.
3. Upload additional certificates and their associated key files to Equalizer's file store as
described in "Certificates" on page 283.
4. Select the HTTPS cluster from the left navigational pane if it is not already selected. Select
the Security SNI tab to display the list of configured SNI as shown below. All previously
configured SNI will be listed on accordion tabs.
5. To add an SNI click on
to add a new SNI. The following will be displayed.
6. Configure SNI parameters as follows:
Parameter
Description
SNI Certificate Name
The name of the SNI object. (up to 47 ASCII characters and can include period
(.), dash (-), and underscore (_))
Server Name
The name of the website that you would like the SNI certificate to be associated
with
Certificate
Use the drop down list to select the name of a certificate that you would like to
associate the SNI with.
7. Click on Commit to save the SNI where it will be displayed on the accordion list on the SNI
tab.
8. Add additional SNI objects to certificates as necessary.There is no maximum limit to the
number of SNI objects that can be associated with each certificate. If you would like to
remove an SNI, select the accordion tab on the SNI screen and click on the
button.
386
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Name Indication Using the CLI
Proceed with the following to configure SNI certificates on an HTTPS cluster using the CLI:
1. Configure an HTTPS cluster on Equalizer. Use the CLI syntax described in "Cluster and Match
Rule Commands" on page 198.
2. Add a default certificate to the cluster if one has not been added previously. Use the CLI
syntax described in "Cluster and Match Rule Commands" on page 198.
3. Use the following CLI syntax to upload other certificates and the associated key files to
Equalizer's file store.
eqcli > cert certname
eqcli cert-certname> certfile {edit|url}
Do the same for the associated key files:
eqcli > cert certname
eqcli cert-certname> keyfile {edit|url}
4. Add an SNI object by entering the following in the HTTPS cluster context. The SNI name can
be up to 47 ASCII characters and can include period (.), dash (-), and underscore (_).
eqcli cl-HTTPS*> sni testsni
eqcli cl-HTTPS*-sni-tes*>
5. Now associate certificates with the new SNI by entering the following in the SNI context:
eqcli cl-NEW* > sni testsni
eqcli cl-NEW*-sni-tes*> certificate snicertificate1
eqcli cl-NEW*-sni-tes*>
where:
testsni is the name of the SNI
snicertificate1 is the name of the certificate being added to the SNI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
387
Working with Clusters and Match Rules
6. Display the contents of the new certificate by entering the following. Note that the
SNI svname has not yet been entered.
eqcli cl-NEW*-sni-testsni> show
SNI Name : test
Certificate : snicertificate1
Flags :
SNI svname :
eqcli cl-NEW*-sni-test>
7. Add the name of the website that you would like the SNI certificate to be associated with by
entering the following in the SNI context:
eqcli cl-NEW*-sni-testsni> sni_svname www.march22.com
eqcli cl-NEW*-sni-testsni> commit
eqcli: 12000287: Operation successful
8. Now verify the SNI to be sure that it is associated with a server name.
eqcli cl-NEW*-sni-testsni> show
SNI Name : test
Certificate : snicertificate1
Flags :
SNI svname : www.march22.com
eqcli cl-NEW*-sni-testsni>
9. Add additional SNI objects to certificates as necessary. There is no maximum limit to the
number of SNI objects that can be associated with each certificate.
388
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Header Editing
Header editing allows you to add, modify, and delete Layer 7 packet header data contained in
client requests and server responses. You can choose to apply header editing rules on every
request or response, or you can selectively apply header edits based on whether or not the client
request is selected by a match rule.
Refer to "HTTP and HTTPS Header Editing Feature" on page 1015 for a complete description of this
feature along with examples that demonstrate how to use header editing functions in real-world
scenarios.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
389
Working with Clusters and Match Rules
Layer 7 TCP Cluster Settings
Layer 7 TCP clusters are used to provide IPv6 addressing for generic Layer 4 protocols, and
can support IPv4 and IPv6 addressing for clusters and servers.
A key feature of EQ/OS 10 is that it is designed to allow L7 HTTP & HTTPS clusters to work with
IPv6. In addition a solution is available that makes L4 clusters also work with IPv6. Although
somewhat misleading in name, an L7 cluster is available for use with IPv6 called "L7 TCP". L7 TCP
really has very little to do with HTTP or HTTPS, however, and functions as an L4 cluster.
L4 TCP clusters have special code which deals with the fact that FTP involves two TCP connections
and IP addresses that are passed over the wire. The L4 code is able to rewrite those IP addresses.
The L7 TCP code cannot do that, so it is NOT recommended for FTP.
The L7 TCP cluster:
l
Cannot process match rules the way L7 HTTP & HTTPS clusters do.
l
Cannot examine or manipulate headers
l
Cannot do anything protocol-specific.
This type of cluster is essentially used to:
1. Get a TCP connection on the cluster
2. Pick a server
3. Connect the client to server
In general, the basic function of the Layer 7 TCP cluster is to provide IPv6 addressing for generic
Layer 4 protocols, and support IPv4 and IPv6 addressing for clusters and servers. The
functionality is very much like Layer 4 TCP cluster and should be used when IPv6 addressing is
required for a TCP protocol other than HTTP or HTTPS. (The Layer 4 TCP and UDP clusters can use
only IPv4 cluster addresses and can only be used with servers that have IPv4 addresses.)
For additional information on cluster types used with Equalizer refer to Cluster Types for a
summary of cluster types.
The following are descriptions of the functionality and configuration parameters used with Layer 7
TCP Clusters.
Parameters
GUI Parameter (CLI Parameter)
Description
Protocol
(proto)
The protocol selected in the Add Cluster form will be displayed “grayed out”.
VID
(vid)
The VLAN ID number assigned to the VLAN on which the cluster resides.
Refer to Common Networking Scenarios for details.
390
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
IP
(ip)
Enter the IP address, which is the dotted decimal IP address of the cluster.
The IP address of the cluster is the external address with which clients
connect to the cluster.
Port
(port)
For TCP protocol clusters the numeric port number on the Equalizer to be
used for traffic between the clients and the cluster. For TCP clusters, the port
defaults to 80. This port also becomes the default port for servers added to
the cluster (though servers can use a different port number than the one
used by the cluster).
Preferred Peer
(preferred_peer)
Used with Active-Active Failover. Refer to Configuring Active/Active Failover
Between Two Systems for details.
Server Pool
(srvpool)
A drop down list used to select a Server Pool, or grouping of servers, to which
the cluster will communicate with.
Flags
Abort server
(abort_server)
By default, when a client closes a connection, Equalizer waits for a response
from the server before closing the server connection. If this flag is enabled,
Equalizer will not wait for a response before closing the connection to the
server; instead it sends a TCP RST (reset) to the server when the client closes
the connection. This option will typically reduce the number of server
connections in the TIME_WAIT state, as shown by the netstat console
command.
Delayed Binding
(delayed_binding)
If this option is selected, the client must send the first byte of data on newly
established connection.
When the spoof option is enabled on a cluster, Equalizer uses the client’s IP
address as the source IP address in all packets sent to a server in that
cluster. This option is enabled by default.
Spoof
(spoof)
When spoof is enabled, all server responses to client requests that came
through the Equalizer cluster IP address must be routed by the server back
to the client through Equalizer. In many cases, the easiest way to do this is to
set the default gateway on the server with a server instance in a server pool
to Equalizer’s IP address on the server VLAN. If this is not possible, you can
establish static routes on the server to send responses to specific client IP
addresses to Equalizer’s IP address on the VLAN.
If you disable spoof, the server receiving the request will see Equalizer’s IP
address as the client address because the TCP connection to the client is
terminated when the request is routed. The server will therefore send its
response back to Equalizers IP address. Disabling the spoof option enables
Source Network Address Translation (SNAT).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
391
Working with Clusters and Match Rules
Configuring a Layer 7 TCP Cluster Using the GUI
The Layer 7 TCP Cluster configuration screen can be accessed by adding a new Layer 7 TCP cluster
or by selecting Load Balance > Clusters and then selecting the Settings tab on the right configuration
pane. The figure below shows a Layer 7 TCPConfiguration Settings screen.
Use the table above for parameters, values, and flags for the configuration of a Layer 7 TCP
cluster. Click on the Commit button after making changes to the settings.
392
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring a Layer 7 TCP Cluster Using the CLI
Layer 7 TCP Clusters can be configured in the CLI either globally or in cluster context. Enter
parameters using the following format. eqcli > cluster clustername parameter value flags flag
Use the table above for descriptions of the parameters and values.
Where:
clustername - is the name of the cluster.
parameter - is the parameter.
value - is the value associated with the parameter.
flag - is the flag to be associated with the cluster.
Use the table above for parameters and values .
Refer to "Cluster and Match Rule Commands" on page 198 for additional information on using
cluster commands in the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
393
Working with Clusters and Match Rules
Layer 7 TCP Cluster Persistence
Layer 7 TCP cluster persistence is the same as Layer 4 TCP cluster persistence. Refer to "TCP
Cluster Persistence" on page 338 for details.
394
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Additional Cluster Configuration
The Related Topics describe additional cluster configuration.
About Passive FTP Translation
In EQ/OS 8.6 if your servers were on a network that the outside world could not reach, you were
provided the capability of enabling a passive FTP translation option. This option caused Equalizer
to rewrite outgoing FTP PASV control messages from the servers so they could contain the IP
address of the virtual cluster rather than that of the server. This was a global option.
In previous releases, an FTP cluster was required to have the "Spoof" option enabled, which
means that the ADC would use the client’s IP address as the source IP address in all packets sent
to the servers in the cluster. Spoof can now be disabled on an FTP cluster that uses passive FTP
connections to servers – which means that the ADC’s subnet IP address will be used as the source
IP in all packets sent to servers.
Contact customer support for instructions if you require this feature to be turned OFF.
Enabling Cookies for Persistent Connections
For Layer 7 HTTP and HTTPS clusters, you can enable the persist check box to use cookies to
maintain a persistent session between a client and a particular server for the duration of the
session.
When you use cookie-based persistence, Equalizer inserts a cookie into the server’s response
header on its way back to the client. This cookie uniquely identifies the server to which the client
was connected and is included automatically in subsequent requests from the client to the same
cluster. Equalizer can use the information in the cookie to route the requests to the same server.
If the server is unavailable, Equalizer automatically selects a different server.
This option is enabled by default. Also see the descriptions of the always, cookie age, cookie domain,
and cookie path cluster parameters under "Modifying a Layer 7 HTTP or HTTPS Cluster" on page
353.
Enabling Persistent Server Connections
Equalizer provides several methods by which connections between clients and servers can be
made persistent; that is, it is possible to route a series of requests from a particular client to the
same server, rather than have the Equalizer load balance each request in the series -- potentially
sending each request to a different server.
l
l
For Layer 4 clusters, persistent server connections are enabled using the Sticky Time
cluster parameter and (optionally) the Inter-Cluster Sticky cluster flag.
For Layer 7 clusters, persistent server connections are enabled using the Persist and Always
cluster flags.
Enabling Sticky Connections
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
395
Working with Clusters and Match Rules
For Layer 4 TCP and UDP clusters, you can use IP-address based sticky connections to maintain
persistent sessions.
The sticky time period is the length of time over which Equalizer ensures that it directs new
connections from a particular client to the same server. The timer for the sticky time period
begins to expire as soon as there are no active connections between the client and the cluster. If
Equalizer establishes a new connection to the cluster, Equalizer resets the timer for the sticky
time period.
Sticky connections are managed on Equalizer using sticky records that record the IP address, port
and other information for the client-server connection. When you enable sticky connections, the
memory and CPU overhead for a connection increase. This overhead increases as the sticky time
period increases.
Consequently, you should use the shortest reasonable period for your application and avoid
enabling sticky connections for applications unless they need it. For most clusters, a reasonable
value for the sticky time period is 600 seconds (that is, 10 minutes). If your site is extremely
busy, consider using a shorter sticky time period.
With the inter-cluster sticky option, you can configure Equalizer to direct requests from a client to the
same server on any available port that has a current persistent connection in any cluster.
When Equalizer receives a client request for a Layer 4 cluster with inter-cluster sticky enabled and
the client does not have a sticky record for the cluster, then Equalizer will check other clusters
that have inter-cluster sticky enabled for a sticky record for the same client and server -- but on a
different server port than the one originally used in the client request.
If such a sticky record is found and the server IP/port in the sticky record is configured as a
server in the current cluster, then the sticky record is used to send the client request to that
server IP/port. Otherwise, the client request is load balanced across the server pool in the cluster.
In order for the inter-cluster sticky option to work:
l
l
The two clusters must have the same cluster IP address and different ports.
At least one server in each of the two clusters must be configured with the same IP address
and different ports.
Inter-cluster stickiness is provided for the case where you have similar services running on the
same server IP on two or more ports. Using port ranges for a cluster achieves essentially the
same effect, without using another cluster IP address (See "TCP Cluster Configuration Settings"
on page 335). Using inter-cluster sticky is preferable in situations where you’d like the service
available on multiple cluster IPs as well as multiple ports.
To enable sticky connections for a cluster, follow these steps:
1. Log into the GUI using a login that has add/del access for the cluster (See "Logging In" on
page 268)
2. In the left frame, click the name of the Layer 4 TCP or UDP cluster to be configured. The
cluster’s parameters appear in the right frame.
3. Select the Persistence tab in the right frame.
4. In the sticky time field, specify the sticky time period in seconds greater than zero.
396
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
5. To direct all requests from a particular client to the same server even if the connection is to
a different virtual cluster, check the inter-cluster sticky checkbox. You can turn on inter-cluster
stickiness only if you have enabled sticky connections by specifying a sticky time greater than
zero.
6. Click the commit button.
Enabling the Once Only and Persist Options
Since HTTP 1.0, web browsers and servers have been able to negotiate persistent connections
over which multiple HTTP transactions could take place. This is useful when several TCP
connections are required in order to satisfy a single client request.
For example, before HTTP 1.1, if a browser wished to retrieve the file index.html from the server
www.coyotepoint.com, the browser would take the following actions:
1.
Browser opens TCP connection to www.coyotepoint.com.
2. Browser sends request to server “GET /index.html”.
3. Server responds with the content of the page (HTML).
4. Server closes connection.
5. Browser determines that there are objects (images) in the HTML document that need to be
retrieved, so the browser repeats Steps 1 to 4 for each of the objects.
There is a lot of overhead associated with opening and closing the TCP connections for each
image. The way HTTP 1.0 optimizes this is to allow multiple objects (pages, images, etc) to be
fetched and returned across one TCP socket connection. The client requests that the server keep
the connection open by adding the request header Connection: keep-alive to the request. If the server
agrees, the server will also include Connection: keep-alive in its response headers, and the client is
able to send the next request over the persistent HTTP connection without the bother of opening
additional connections.
For HTTP/1.1, persistent connections are the default.
For a Layer 7 cluster, Equalizer evaluates (and possibly changes) both the request and response
headers that flow between the client and server (the request and response bodies are not
examined). Match rules are applied to each client header, cookies may be inserted, and headers
may be rewritten. When a client includes keep-alive in its headers, there is a fair amount of work
required by the Equalizer to determine when the next set of request headers is ready to be parsed
(evaluated), since there may be quite a lot of data going across the connection between sets of
headers.
To reduce this workload, the once only flag instructs the Equalizer to evaluate (and potentially
modify) only the first set of headers in a connection. So, in our example above, only the headers
in the request for the index.html file are evaluated; the subsequent requests to obtain the images
are not load balanced, but sent to the same server as the first request.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
397
Working with Clusters and Match Rules
Enabling once only can be incompatible with persistence and Layer 7 HTTPS clusters (which
rewrite HTTP to HTTPS links in server response headers), since in these cases we generally want
to examine every request in a connection. However, in configurations where examining the
headers in every transaction in a connection is not required, enabling once only can significantly
improve performance.
Whether once only is enabled or not has a significant effect on how Equalizer routes requests, as
summarized in the following table:
Requests
in a single
keep-alive
connection
once only enabled
once only disabled
persist
enabled
If request contains a cookie and there is no
match rule hit, send request to the server in
the cookie.
If request contains a cookie and there is a
match rule hit, send the request to the server
in the cookie only if it is in the list of servers
selected in the match rule definition.
Otherwise, ignore the cookie.
If there is no cookie, load balance the request
and send to the server chosen.
If request contains a cookie and there is no
match rule hit, send request to the server in
the cookie.
If request contains a cookie and there is a
match rule hit, send the request to the server
in the cookie only if it is in the list of servers
selected in the match rule definition.
Otherwise, ignore the cookie.
If there is no cookie, load balance the request
and send to the server chosen.
persist
disabled
Load balance the request and send to the
server chosen.
Load balance the request and send to the
server chosen.
match rule
hit
Send to the server chosen by the match rule.
Send to the server chosen by the match rule.
First Request
Subsequent Requests
398
persist
enabled
Send to same server as first request (any
cookie in request is ignored).
If request contains a cookie, send request to
the server in the cookie.
If there is no cookie, load balance request and
send to server chosen by policy.
persist
disabled
Send to same server as first request.
Load balance the request and send to the
server chosen.
match rule
hit
Send to same server as first request.
Send to the server chosen by the match rule.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
For example, let’s look at how Equalizer processes HTTPS requests. For an HTTPS cluster,
Equalizer off loads SSL processing from the server pool in the cluster; that is, Equalizer does all
the SSL related processing itself, and then forwards the request in HTTP to the server. When it
does this, it inserts special headers into the request to indicate that the request was received by
Equalizer in HTTPS and processed into HTTP (see "HTTPS Header Injection" on page 404). If once
only is set, these special headers are only inserted into the first request in a connection; the
remainder of the requests in the connection are still processed, but no headers are inserted. Most
servers that support SSL off loading require that every request contain the special headers -therefore, in most cases like this you need to disable the once only flag for the cluster if you want
to be able to parse for these headers in every request on the server end.
The once only flag is enabled by default when adding an L7 cluster. In general, it is more efficient to
enable once only; but, in situations where load balancing decisions need to be made for every
request or where any of the above effects are undesirable, once only should be disabled.
Note - Although it is permitted by the software, it is not recommended to define a Layer 7 cluster with persist and
once only both turned off, and with no match rules. By defining a Layer 7 cluster in such a way, you are essentially
disabling Layer 7 processing, while still incurring extra overhead for the Layer 7 cluster. If your application requires a
cluster with no persistence, header processing, or match rules, then we recommend that you define a Layer 4 UDP or
TCP cluster for the best performance.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
399
Working with Clusters and Match Rules
Enabling Both the Once Only and Always Options
The always flag influences when Equalizer inserts cookies into server responses; it in turn is
affected by the setting of the once only flag, as shown in the following table:
always
enabled
always
disabled
once only enabled
once only disabled
Equalizer always inserts a cookie into the first set
of response headers on a connection only. The
cookie is inserted regardless of whether the
server included one in the response.
Subsequent responses on the same connection
are forwarded to the client unchanged by
Equalizer.
Equalizer inserts its own cookie
into all server responses on a
connection. The cookie is
inserted regardless of whether
the server included one in the
response.
If the first server response on a connection
already has a server cookie in it, Equalizer
inserts its own cookie into the first set of
response headers on the connection. If the
response has no cookie in it, Equalizer does not
insert one of its own.
Subsequent responses on the same connection
are forwarded to the client unchanged by
Equalizer.
If the first server response on a
connection already has a server
cookie in it, Equalizer inserts its
own cookie into the first set of
response headers on the
connection.
Equalizer will insert a cookie into
subsequent responses on the
same connection if:
they do not contain a valid cookie
the cookie generation has
changed
the server in the cookie has the
quiesce flag enabled
Note - the cluster parameters cookie path, cookie age, cookie generation, and cookie domain specify cookie content for
the cluster. If any of these parameters are updated, this changes the information used in the cookies that Equalizer
inserts into server responses.
400
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
FortiADC E Series Handbook
Enabling Once Only and Compression
Enabling both the once only and compress options is not allowed by the GUI. These two options are
not compatible, since setting them both would mean that only the first response in a connection
would be compressed and not the remainder of the responses, which would likely cause client
errors.
Enabling Once Only and No Header Rewrite for HTTPS
In a Layer 7 HTTPS cluster, clients connect to the cluster IP using HTTPS connections. Equalizer
terminates the HTTPS connection and communicates with the server pool in the cluster using the
HTTP protocol. By default, Equalizer examines server responses for http://URLs and rewrites
them as https:// URLs, so that these URLs work properly on the client. If, for example, a server
sends an HTTP redirect using the Location: header, this URL most likely will include the http://
protocol. Equalizer rewrites this response so that the URL uses https://.
For server connections that contain multiple server responses, the setting of the once only flag
determines whether Location: headers in all server responses are rewritten. This is shown in the
table below.
Note that the GUI does not permit you to enable once only and disable no header rewrite -- this
option combination would rewrite the Location: header in only the first response in the
connection, and not rewrite the headers in subsequent responses in the same connection. Doing
so would produce errors on the client.
Of course, you can also direct Equalizer to pass responses from the server without rewriting URLs
by enabling the no header rewrite flag on the cluster.
once only
enabled
once only
disabled
no header rewrite
disabled
Not supported.
The Location: headers of every response in a connection
are rewritten.
no header rewrite
enabled
No headers are
rewritten.
No headers are rewritten.
Specifying a Custom Header for HTTP/HTTPS Clusters
Some applications require specific headers in incoming client requests, and Equalizer provides the
custom header field in HTTP and HTTPS clusters to allow you to inject a custom header into the
client request before it is sent to a server behind Equalizer.
An example is the Exchange 2003 version of Microsoft Outlook Web Access (OWA). OWA 2003
normally requires that all incoming client requests use the Secure Sockets Layer (SSL) protocol.
This means that all client requests must have the https:// protocol in the URI. If, however, OWA
is running on a server in an Equalizer Layer 7 HTTPS cluster, then OWA will receive all requests
with http:// in the URI, since Equalizer performs SSL processing before passing the requests on
to the server.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
401
Working with Clusters and Match Rules
OWA 2003 allows for SSL off loading through the use of a special header, as explained in the
following Microsoft technical article:
http://technet.microsoft.com/en-us/library/578a8973-dc2f-4fff-83c639b1d771514c.aspx
Two things are necessary when running OWA 2003 behind Equalizer:
1. Configure OWA to watch HTTP traffic for requests containing a custom header that indicates
that the request was originally an SSL request that was processed by SSL off loading
hardware (i.e., Equalizer) before reaching OWA (see the above article for instructions)
2. Configure the Equalizer cluster to add the custom header to all requests before sending
them on to the OWA server (this is explained below)
The following procedure shows you how to add a custom header to an existing HTTPS cluster
definition, using the header required for an OWA 2003 server as an example.
3. Log into the GUI using a login that has add/del access for the cluster (See "Logging In" on
page 268.)
4. In the left navigational pane, Load Balance > Clusters > Cluster name and then the Configuration >
Settings tab.
5. Type the following in the Customer Header field.
Front-End-Https: on
1. Click on Commit to modify the cluster.
Performance Considerations for HTTPS Clusters
Layer 7 HTTPS clusters have several options that can have a significant impact on the
performance and behavior of the cluster:
1. The injection of a customheader to provide transaction-specific information to the server. For
example, to tell the server that Equalizer terminated the HTTPS connection and performed
SSL processing on the incoming request (see the previous section, above).
2. The "munging", or translation, of HTTP redirects to HTTPS redirects (see the description of
the no header rewrite flag under Modifying a Layer 7 Virtual Cluster).
3. The once only flag. This flag is present to speed up processing of HTTP requests by only
looking at the first request, but since HTTPS has a lot of overhead associated with it
anyway, turning this flag off does not reduce HTTPS performance. Furthermore, having this
flag on for HTTPS clusters causes some applications to not function as needed.
In general, it is recommended to turn the once only flag off for HTTPS clusters. In order to inject
custom headers and rewrite headers in every transaction in a connection, turning off once only is
required.
HTTPS Performance and Xcel SSL Acceleration
402
Copyright © 2015 Fortinet, Inc.
FortiADC E Series Handbook
The E650GX and E450GX include the Xcel SSL Accelerator Card. Equalizer models without Xcel
(E250GX and E350GX) performs all SSL processing in software using the system CPU. Equalizers
with Xcel perform all SSL processing using the dedicated processor on the Xcel card. This allows
the system CPU to concentrate on non-SSL traffic. For most applications, Xcel will process several
hundred HTTPS transactions per second with no noticeable degradation in performance either for
the HTTPS cluster or for Equalizer as a whole.
In terms of bulk data throughput, the theoretical maximum throughput for Xcel/HTTPS is roughly
50% of that for the Equalizer in HTTP mode: Equalizer models with gigabit Ethernet can move
HTTP traffic at wire speed (1Gbit/s) for large transfers, while Xcel can encrypt only approximately
400Mbit/s with 3DES/SHA1 or 600Mbit/s with RC4/MD5. This reflects the fact that Xcel is primarily
a transaction accelerator, not a bulk data encryption device. It is noteworthy, however, that even
when moving bulk data at 600Mbit/s, Xcel removes the entire load of HTTPS/SSL processing from
the server pool in the cluster.
One final issue to be aware of is that Xcel supports only 3DES and RC4 encryption; it does not
support AES. It also does not support SSL or TLS cipher suites that use ephemeral or anonymous
Diffie-Hellman exchange (cipher suites whose names contain "EDH", "DHE", or "ADH").
The default configuration for HTTPS clusters created with Xcel enabled will not use the modes
described above. If, however, one either modifies the cluster’s cipher suite string to use them, it
is possible that they may be negotiated with clients. This will not lead to incorrect operation of the
system, but encryption for these cipher suites will occur in software instead of taking advantage
of the improved performance provided by the Xcel hardware.
Copyright © 2015 Fortinet, Inc.
All Rights Reserved.
403
Working with Clusters and Match Rules
HTTPS Header Injection
When a connection is established by a client for an HTTPS cluster, Equalizer performs the SSL
processing on the request (this is called SSL off loading), and adds some additional headers to the
client's request before forwarding the request on to a server:
X-LoadBalancer: Equalizer
X-Forwarded-For: (client's IP address)
If the client provides an SSL certificate, the following are also added:
X-SSL-Subject: (certificate's X509 subject)
X-SSL-Issuer: (certificate's X509 issuer)
X-SSL-notBefore: (certificate not valid before info)
X-SSL-notAfter: (certificate not valid after info)
X-SSL-serial: (certs serial number)
X-SSL-cipher: (cipher spec)
If these headers are present in a request received by a server, then the server knows that the
request was originally an HTTPS request and was processed by Equalizer before being forwarded
to the server.
These headers are inserted into every request if the once only flag is disabled; if once only is
enabled, then only the first request in a connection will have these headers inserted.
Some application may require a special header in the request, and the following section describes
how Equalizer can be configured to provide a custom HTTPS header for such applications.
Providing FTP Services on a Virtual Cluster
The FTP protocol dates from the 1970s, and was designed to be used in an environment where:
l
the network topology is simple
l
the FTP server and client communicate directly with one another
l
l
the addresses used by the client and server for active FTP data connections can be
negotiated over the FTP control connection
the FTP server is able to make connections back to the FTP client
These operational characteristics of FTP require special configuration for load balancers (as well
as firewalls and NAT devices) that pass traffic between FTP servers and FTP clients:
l
l
404
NAT devices and routers (including load balancers like Equalizer) on the client and server
sides must be configured to monitor FTP transactions and provide appropriate address
translation and packet rewriting.
Firewalls on the client and server sides must be configured to let traffic on the ports used
for FTP through the firewall.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Consult the documentation for the firewalls and NAT devices used at your site to determine how to
set up those devices appropriately for FTP transfers. See the next section for how to configure an
Equalizer cluster for responding to FTP requests from clients.
FTP Cluster Configuration
When configuring an FTP cluster on Equalizer, the following guidelines must be followed:
l
l
l
The protocol for the cluster must be Layer 4 TCP.
The start port parameter for the cluster must be set to port 21. (Note that port 20 is also used,
but you do not specify it when adding the cluster.)
The spoof flag must be set according to whether FTP clients connecting to the cluster will be
using ACTIVE or PASSIVE mode:
o
If all clients will be connecting using PASSIVE mode, then the spoof flag can be
either enabled or disabled as desired.
o
If some or all clients will be connecting using ACTIVE mode, then the spoof flag
must be enabled. ACTIVE mode will not work if the spoof flag is disabled.
FTP data connections are automatically configured (internally) with a sticky time of one second. This
is necessary to support the passive mode FTP data connection that most web browsers use. This
means that there will be one sticky record kept for each FTP data connection. For an explanation
of sticky records, see "Enabling Sticky Connections" on page 395"Enabling Sticky Connections" on
page 395
l
l
FTP clusters occupy two internal virtual cluster slots, even though only one appears in the
interface. This permits Equalizer’s NAT subsystem to rewrite server-originated FTP data
connections as they are forwarded to the external network.
You cannot enable the direct server return option on an FTP cluster.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
405
Working with Clusters and Match Rules
Configuring Direct Server Return
In a typical load balancing scenario, server responses to client requests are routed through
Equalizer on their way back to the client. Equalizer examines the headers of each response and
may insert a cookie, before sending the server response on to the client.
In a Direct Server Return (DSR) configuration, the server receiving a client request responds
directly to the client IP, bypassing Equalizer. Because Equalizer only processes incoming
requests, cluster performance is dramatically improved when using DSR in high bandwidth
applications, especially those that deliver a significant amount of streaming content. In such
applications, it is not necessary for Equalizer to receive and examine the server’s responses: the
client makes a request and the server simply streams a large amount of data to the client.
DSR is supported on Layer 4 TCP and UDP clusters only, and is not supported for FTP clusters
(Layer 4 TCP clusters with a start port of 21). Port translation or port mapping is not supported in
DSR configurations.
DSR configurations are usually configured in single network mode, where the cluster IP and the
server IPs are all on the internal interface. An example single network mode DSR configuration is
shown below:
DSR can also be used in dual network mode, although this is a less common configuration than
single network mode. Cluster IPs are on the external interface, and server IPs are on the internal
interface. An example of a dual network mode DSR configuration is shown below.
406
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Note - In both configurations that the incoming client traffic is assumed to originate on the other side of the gateway
device for the subnets on which Equalizer and the servers reside. The servers will usually have their default gateway
set to something other than Equalizer so that they can respond directly to client requests.
The cluster parameters Direct Server Return, Spoof, and Idle Timeout are directly related to direct
server return connections:
l
l
l
Direct Server Return - this option enables Direct Server Return. All requests to this cluster IP
will be forwarded to the server with the client IP as the source IP, and the cluster IP as the
destination IP. The loopback interface of the server must be configured with the cluster IP
to receive the requests. See “Configuring Servers for Direct Server Return” on page 183.
Spoof - this option causes Equalizer to spoof the client IP address when Equalizer routes a
request to a server in a virtual cluster; that is, the IP address of the client is sent to the
server, not the IP address of the Equalizer. This flag must be enabled for DSR.
Idle Timeout - The is the time in seconds before reclaiming idle Layer 4 connection records.
Applies to Layer 4 TCP clusters only. For DSR the Idle timeout slider must be set to a nonzero value, or Equalizer will never reclaim connection records for connections terminated
by the server. The cluster's Idle Timeout should be set to the longest period within your
application that you would like Equalizer to wait for consecutive messages from the client
(since the Equalizer does not see server packets on DSR connections). For example, if the
longest expected server response time and the longest expected delay between client
responses on active connections are both 60 seconds, then set the Idle Timeout slider to 120
seconds.
To create a new cluster or modify an existing one for DSR, do the following:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
407
Working with Clusters and Match Rules
1. Log into the GUI using a login that has add/del access for the cluster (See "Logging In" on
page 268.)
2. Do one of the following:
a. Create a new Layer 4 TCP or UDP cluster: right-click Equalizer in the left
navigational pane and select Add Cluster. After you enter and commit the basic
information, you’ll be taken to the server Configuration tab.
b. Modify an existing Layer 4 TCP or UDP cluster: click on the cluster name in the
left frame to display the cluster’s Configuration tab in the right frame.
3. Enable the Direct Server Return and Spoof check boxes.
4. If the cluster is a Layer 4 TCP cluster and the idle timeout parameter is set to 0, increase it
as described in the table above. Skip this step for Layer 4 UDP clusters.
5. Click on Commit to save your changes to the cluster configuration.
6. If you need to add server instances to a server pool, add them by doing the following:
a. Right-click the server pool name in the left navigational pane frame and select
Add Server Pool.
b. Fill in the remainder of the required information.
c. Click on the Commit button to save your entries.
7. Perform the procedure in the following section on each server that you add to the cluster.
408
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Testing Your Basic Configuration
Once you have installed and configured Equalizer and your servers, perform tests to verify that
Equalizer is working properly.
To perform these tests, you need the following:
l
l
l
A test machine on the internal network (the same physical network as the servers; one of
the server machines can be used for this purpose).
If you have a two-network configuration, a test machine on the external network.
A client machine somewhere on the Internet, to simulate a “real-world” client. This machine
should be set up so that the only way it can communicate with your servers or Equalizer is
through your Internet router.
Then follow these steps:
1. Ping Equalizer’s external address (if configured) from a host on the external network
interface address.
2. Ping Equalizer’s internal address from a host on the internal network interface address.
3. If DNS is configured, ping a host on the Internet (e.g., www.coyotepoint.com) from
Equalizerto ensure that DNS and the network gateway are functioning properly.
4. From the internal-network test machine, ping the physical IP address of each server. You
should be able to successfully ping all of the servers from the test machine.
5. From the internal-network test machine, ping the server aliases on each of the servers. You
should be able to successfully ping all of the servers from the test machine using their
aliases.
6. From the internal test machine and each of the servers, ping the Equalizer address that you
use as the default gateway on your servers. (If you use a two-network topology, this will be
Equalizer’s internal address or failover alias.)
7. From the internal-network test machine, connect to the server aliases on service ports of
running daemons (you may need to configure telnet or ssh services on Windows servers).
You should be able to connect successfully to the server aliases.
8. If you use a two-network configuration: From the external-network test machine, ping a
physical server IP address using ping -R to trace the route of the ping. The EqualizerIP
address should appear in the list of interfaces that the ping packet traverses. You can also
use the traceroute (UNIX) or tracert (Windows) tools to perform this test.
9. Log into the GUI on either the external (if configured) or internal interfaces, as described in
"Logging In" on page 268.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
409
Working with Clusters and Match Rules
Using Match Rules
Note - Match Rules are not supported on E250GX model Equalizers.
The ability to make load balancing decisions based on the content of a client request is what
separates Layer 7 processing from the processing options available at Layer 4. For Layer 7 HTTP
and HTTPS clusters, Match Rules provide fine-grained control over load balancing decisions based
on the content of the client request. If you need to be able to route requests to the servers in a
cluster based on the content of the request, Match Rules are the answer.
Layer 7 HTTP and HTTPS clusters can use logical constructs called “Match Rules” to control the
processing of the incoming data stream from clients. Match rules extend the Layer 7 load
balancing capabilities of HTTP and HTTPS clusters by allowing you to define a set of logical
conditions which, when met by the contents of the request, trigger the load balancing behavior
specified in the match rule.
Typically, a match rule selects the subset of servers that the load balancing algorithms will use for
a particular request. By default, a request is load balanced over all the available non-spare
servers in a cluster. Match rules allow you to select the group of servers, or server pools, that will
be used to load balance the request.
For each virtual cluster, you can specify any number of match rules. For each match rule, you
specify the subset of servers or server pools that can handle requests that meet the rule criteria.
A match rule provides custom processing of requests within connections. Equalizer provides
common and protocol-specific match functions that enable dynamic matching based on a
request’s contents. Protocol-specific match functions typically test for the presence of particular
attributes in the current request.
For example, a Layer 7 HTTP virtual cluster can specify matching on specific path name attributes
to direct requests to subsets of servers or server pools so that all requests for images are sent to
the image servers. The difference between load balancing with and without match rules in such a
situation is illustrated in the following figure.
410
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Most client requests are a mix of requests for text and graphics. Layer 7 processing without Match
Rules balances requests across the specified server pool so that each server instance in the
server pool will see a mix of text and graphics requests. This means that all text and graphics
must be available on each server pool.
Some sites may want to have one system serve only requests for graphics, and one system serve
only text requests.
By adding appropriate Match Rules, Equalizer can examine each request to determine if the
content requested is Text or Graphics, and send the request to the appropriate server pool. In this
example, the servers need only hold the content they are serving, text or graphics.
How Match Rules are Processed
A match rule is like an if-then statement: an expression is evaluated and if it evaluates to true the
body of the match rule applies to the request.
A match expression is a combination of match functions with logical operators, and can be
arbitrarily complex. This allows for matching requests that have, for example:
(attribute A) AND NOT (attribute B)
If a match expression evaluates to true, then the data in the request has selected the match rule,
and the match body applies. The match body contains statements that affect the subsequent
handling of the request.
Multiple match rules are checked in order. Once the data in the request selects a match rule -that is, the match rule expression evaluates to true -- no further match rules are checked against
the request.
Equalizer makes a load balancing decision as follows:
1. If the request headers contain a cookie that specifies a server pool for the match rule,
Equalizer sends the request to the server in the cookie.
Otherwise:
2. Equalizer sends the request to the server pool specified in the match rule that is selected by
the load balancing policy in effect for the match rule.
This process applies even if all the servers selected for the match rule are unavailable. In this
case, when the match rule expression matches the request and all the servers in the match rule
server list are unavailable, no reply is sent to the client. Eventually, the client sees a connection
timeout.
If the match expression evaluates to false, then each subsequent match rule in the list of match
rules for the virtual cluster is processed until a match occurs. All clusters have a Default Match
rule, which always evaluates to true and which will use the entire set of servers for load
balancing. The Default Match rule is always processed last.
Each cluster can have any number of match rules, and each match rule can have arbitrarily
complex match expressions. Keep in mind that Equalizer interprets match rules for every Layer 7
cluster connection, so it is a good idea to keep match rules as simple as possible.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
411
Working with Clusters and Match Rules
Match Rule Order
When you add more than one match rule to a cluster, the order in which the match rules are
processed is important to system performance. Since processing a match rule requires system
CPU and memory, the most efficient way of ordering match rules is from the most common case
to the least common case. In this way, you ensure that the greatest number of client connections
possible will process the first match rule and, if it matches the request, stop processing match
rules for that request.
In other words, the goal is to load balance the highest possible number of requests according to
the settings in the first match rule, which has the effect of reducing to a minimum the amount of
match rule processing required for requests to that cluster.
This is best illustrated by an example. Let’s say you want to construct a set of match rules that
achieves these goals:
l
Direct all requests whose URL contains one of two specific directories to specific server
pools. Assume these two directories are.../support and.../engineering.
l
Of the two directories above, we expect more requests to contain.../support.
l
Load balance requests whose URL does not contain a directory across all servers.
l
We want to process requests that do not contain a directory the fastest, since we expect
that 75% of requests to this cluster will NOT contain a directory in the URL.
The set of match rules that achieves this, their order, and how the match rules are evaluated, is
described in the following figure.
412
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
At left in the figure above are the expressions for the three match rules, shown in the order in
which they are configured in the cluster. At right, the decision tree describes how the match rules
are evaluated for every client request that comes into this cluster.
As described previously, the first match rule (ma01) is meant to match any request that does not
have a directory in it. Since this is our most common case, match rule evaluation will stop after
the first match rule is evaluated for the majority of incoming requests.
The second and third rules, ma02 and ma03, match for specific directory names. We match for the
most common directory name first, then the less common directory name.
Finally, if all three of the match rule expressions for ma01, ma02, and ma03 fail to match an
incoming request, then that request is load balanced across the server pool in the cluster using
the options set on the cluster (and mirrored in the Default match rule).
Match Rule Expressions and Bodies
Match functions and operators are used to construct the expression parameter found in a match
rule. The expression parameter selects the requests to be processed using the parameters
specified in the remainder of the match rule.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
413
Working with Clusters and Match Rules
Match Rule Expressions
Match rules consists of a match expression and a match body, which identifies the operations to
perform if the expression is satisfied by the request. Match syntax is as follows:
match name {expression} then {body}
Each match has a name, which is simply a label. The name must follow the same restrictions as
those for cluster names and server pool names. All match names within a cluster must be unique.
Match expressions affect the subsequent processing of the request stream using URI, host, or
other information. They are made up of match functions, most of which are protocol-specific,
joined by logical operators, optionally preceded by the negation operator, with sets of beginning
and end parentheses for grouping where required. This may sound complex, and it can be, but
typical match expressions are simple; it is usually best from a performance perspective to keep
them simple.
The most simple match expression is one made up solely of a single match function. The truth
value (true or false) of this expression is then returned by the match function. For example, a
match function common to all Layer 7 protocols is the any() function, which always returns true,
independent of the contents of the request data. So, the most simple match expression is:
any()
which will always result in the match rule being selected.
Use the logical NOT operator to invert the sense of the truth value of the expression. So, you can
use the NOT operator to logically invert a match expression, as follows:
!expression
giving rise to the next simplest example:
!any()
which always evaluates to false and always results in the match rule not being selected.
With the addition of the logical OR (||) and logical AND (&&) operators, you can specify complex
expressions, selecting precise attributes from the request, as in this:
!happy() || (round() && happy())
414
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Match expressions are read from left to right. Expressions contained within parentheses get
evaluated before other parts of the expression. The previous expression would match anything
that was not happy or that was round and happy.
Unlike the previous example, match functions correspond to certain attributes in a request
header.
For example, a request URI for a web page might look like this:
\Get /somedir/somepage.html http/1.1
Accept: text/html, text/*, *.*
Accept-Encoding: gzip
Host: www.website.com
User-Agent: Mozilla/4.7 [en] (Win98; U)
Various functions return true when their arguments match certain components of the request URI.
Using the above request URI, for example, you could use several match functions:
l
pathname() returns true if its argument matches /somedir/somepage.html
l
dirname() returns true if its argument matches /somedir/
l
filename() returns true if its argument matches somepage.html
Other functions can evaluate the contents of the Host header in the request URI above:
host (www.website.com)
host_prefix (www)
host_suffix (website.com).
Some function arguments can take the form of a regular expression1. Note that you cannot put
regular expressions.
Matching regular expressions (using *_regex() functions) is many times more
processing-intensive than using other match functions. It is usually possible to
avoid using regular expressions by carefully crafting match expressions using
other functions. For example, the following regular expression match:
dirname_regex("(two|four|six|eight)")
Can be replaced by the more efficient:
dirname_substr("two") ||
dirname_substr("four") ||
dirname_substr("six") ||
dirname_substr("eight")
Match Bodies
1Regular expressions are specified according to IEEE Std 1003.2 (“POSIX.2”).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
415
Working with Clusters and Match Rules
Match bodies specify the actions to take if the match expression selects the request. This is
specified in the form of statements that provide values to variables used by the load balancer to
process the request. The most common (and most useful) match body selects the set of servers
(server pool) over which to apply the load balancing.
The servers assignment statement takes a comma-separated list of server names, which specifies
the set of servers to be used for load balancing all requests that match the expression in the
match rule. The reserved server names all and none specify respectively the set of all servers in
the virtual cluster and none of the servers in the virtual cluster. If you do not assign servers, none
will be available for load balancing; as a result, the connection to the client will be dropped.
In general, you can override most cluster-specific variables in a match body. One useful example
of overriding variables is as follows:
flags =!once_only;
which would load-balance across the specified server pool (which first must be defined in the
virtual cluster) and also turn off the once_only flag for the duration of processing of that
connection.
416
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Match Rule Functions
Match rule functions generally test for certain strings or settings in the headers and URI of a client
request. In the table below, we first discuss match rule functions that examine information in the
request other than the URI, and then we discuss the URI related functions.
The following table lists the non-URI functions supported by Equalizer match rules:
any()
This function always evaluates to true -- that is, this function matches
any incoming request.
This function evaluates to true only if the IP address of the client machine
making the connection matches the string argument.
client_ip(string)
The string can be a simple IP address (e.g., “192.168.1.110”), or an IP
address in Classless Inter-Domain Routing (CIDR) notation (e.g.,
“192.168.1.0/24”). This function can be useful in restricting match
expressions to a particular client or group of clients, which can aid in
debugging a new match rule when a cluster is in production. Only the
specified clients match the rule, leaving other clients to be handled by
other match rules
debug_message(string)
This function always evaluates to true. It writes the string argument to
the Event Log for the cluster (View > Event Log). This function can be
logically ANDed and ORed with other functions to write debug messages.
Use this function for testing and debugging only. Do not use it in
production environments, since it has a negative impact on performance.
ignore_case()
This function always evaluates to true, and is intended to be used to apply
the ignore_case flag for comparisons when it is not set on the cluster.
When this function is ANDed with other functions, it has the effect of
forcing case to be ignored for any comparisons done by the match rule.
observe_case()
This function always evaluates to true, and is intended to be used to
override the ignore_case flag for comparisons when it is set on a cluster.
When this function is ANDed with other functions, it has the effect of
forcing case to be honored for any comparisons done by the match rule.
http_09()
This function takes no arguments and evaluates to true if the HTTP
protocol used by the request appears to be HTTP 0.9. This is done by
inference: if an explicit protocol level is absent after the request URI, then
the request is considered HTTP 0.9.
method(string)
This function evaluates to true if the string argument exactly matches the
Request Method (e.g., GET, POST, etc.) specified in the request. Note that
by default Equalizer forwards packets to servers without determining
whether or not the method specified in the request is valid (i.e., is a
method specified in Section 9 of RFC2616). One use of the method()
function is to be able to override this default behavior and prevent invalid
requests from being forwarded to a server.
ssl2()
HTTPS only. This function evaluates to true if the client negotiated the
encrypted connection using SSL version 2.0.
ssl3()
HTTPS only. This function evaluates to true if the client negotiated the
encrypted connection using SSL version 3.0.
tls1()
HTTPS only. This function evaluates to true if the client negotiated the
encrypted connection using TLS version 1.0.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
417
Working with Clusters and Match Rules
Non-URI header match functions
See Match Bodies, for the headers that can be specified in these functions.
header_prefix(header, string)
This function evaluates to true if the selected header is present and
if the string-valued argument string is a prefix of the associated
header text.
header_suffix(header, string)
This function evaluates to true if the selected header is present and
if the argument string is a suffix of the header text.
header_substr(header, string)
This function evaluates to true if the selected header is present and
if the string-valued argument string is a sub-string of the
associated header text.
header_regex(header, string)
This function evaluates to true if the selected header is present and
if the string-valued argument string, interpreted as a regular
expression, matches the associated header text.
In addition to the functions in the preceding table, a set of functions is provided that allows you to
process requests based on the various components of a request’s destination URI.
A URI has the following parts (as defined in RFC1808):
<scheme>://<hostname>/<path>;<params>?<query>#<fragment>
In addition, Equalizer further breaks up the <path> component of the URI into the following
components:
<directory><filename>
The following figure illustrates how Equalizer breaks up a URI into the supported components:
Note that the following components of the URI do not have corresponding match functions:
l
l
418
Match functions for the <scheme> component are not necessary, since a cluster must be
configured to accept only one protocol: HTTP or HTTPS.
Match functions for the optional <params> component are not provided. Use the pathname*
() and filename*() functions to match characters at the end of the path and filename
components.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
l
Match functions for the optional <fragment> component are not provided. The fragment
portion of a URI is not transmitted by the browser to the server, but is instead retained by
the client and applied after the reply from the server is received.
The following lists the URI matching functions that match text in the URI components shown.
URI Function
Description
host(string)
This function evaluates to true if the string argument exactly matches the
hostname portion of the request. In the case of HTTP 0.9, the host is a portion of
the request URI. All other HTTP protocol versions require a Host header to
specify the host, which would be compared to the string.
host_prefix(string)
This function evaluates to true if the string argument is a prefix of the hostname
portion of the URI path. The prefix of the hostname includes all text up to the first
period; for eample, “www” in “www.example.com”.
host_suffix(string)
This function evaluates to true if the string argument is a suffix of the hostname
portion of the URI path. The suffix of the hostname includes all text after the first
period in the hostname; for example, “example.com” in “www.example.com”.
pathname(string)
This function evaluates to true if the string argument exactly matches the path
component of the request URI.
pathname_prefix(string)
This function evaluates to true if the string argument is a prefix of the path
component of the request URI.
pathname_suffix(string)
This function evaluates to true if the string argument is a suffix of the path
component of the request URI.
pathname_substr(string)
This function evaluates to true if the string argument is a substring of the path
component of the request URI.
pathname_regex(string)
This function evaluates to true if the string argument, interpreted as a regular
expression, matches the path component of the request URI.
dirname(string)
This function evaluates to true if the string argument exactly matches the
directory portion of the path component of the request URI. The path component
is the entire directory path, including the trailing slash. For example, “/foo/bar/”
is the directory portion of “/foo/bar/file.html”.
dirname_prefix(string)
This function evaluates to true if the string argument is a prefix of the directory
portion of the path component of the request URI. The leading slash must be
included in the string (for example, “/fo” is a prefix of “/foo/bar/file.html”).
dirname_suffix(string)
This function evaluates to true if the string argument is a suffix of the directory
portion of the path component of the request URI. The trailing slash must be
included in the string (for example, “ar/” is a suffix of the directory portion of
“/foo/bar/file.html”).
dirname_substr(string)
This function evaluates to true if the string argument is a substring of the
directory portion of the path component of the request URI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
419
Working with Clusters and Match Rules
URI Function
Description
dirname_regex(string)
This function evaluates to true if the string argument, interpreted as a regular
expression, matches the directory portion of the path component of the request
URI.
filename(string)
This function evaluates to true if the string argument exactly matches the
filename portion of the URI path. This portion includes only the text after the last
trailing path component separator (/), as that is considered part of the directory
(for example, “file.html” is the filename portion of “/foo/bar/file.html”).
filename_prefix(string)
This function evaluates to true if the string argument is a prefix of the filename
portion of the URI path.
filename_suffix(string)
This function evaluates to true if the string argument is a suffix of the filename
portion of the URI path.
filename_substr(string)
This function evaluates to true if the string argument is a substring of the
filename portion of the URI path.
filename_regex(string)
This function evaluates to true if the string argument, interpreted as a regular
expression, matches the filename portion of the URI path.
query(string)
This function evaluates to true if the string argument exactly matches the
(optional) query component of the request URI. The query, if present, appears in
a URI following a question mark (?). The syntax of a query is application specific,
but generally is a sequence of key/value pairs separated by an ampersand (&).
query_prefix(string)
This function evaluates to true if the string argument is a prefix of the query
portion of the URI path.
query_suffix(string)
This function evaluates to true if the string argument is a suffix of the query
portion of the URI path.
query_substr(string)
This function evaluates to true if the string argument is a substring of the query
portion of the URI path.
query_regex(string)
This function evaluates to true if the string argument, interpreted as a regular
expression, matches the query portion of the URI path.
Match Rule Operators
Match Rule Operators are as follows:
420
l
II - logical OR operator
l
&& - logical AND operator
l
! - logical NOT operator
l
() - used to group functions and operators
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Match Rule Definitions
Match rules are defined in the file /var/eq/eq.conf with the definition of the cluster to which the
match rule applies. A match rule as it appears in eq.conf looks like the following example:
match ma01 {
client_ip("10.0.0.19")
} then {
flags =!spoof;
srvpool = sv_01;
}
In this example (the match rule is named “ma01”), the match function, client_ip, has an argument
that matches all requests from IP address 10.0.0.19, which are all sent to server sv_01.
Additionally, this rule disables the spoof flag (that is, when the connection is made to the server,
the server sees a connection to the Equalizer, not to the client). This is displayed as follows:
The Expression field shows the expression that is evaluated against the incoming request. If the
expression evaluates to true, the Server Pool field specifies the "pool" of servers that will be used to
satisfy the incoming request, as well as the options that will be set for the request.
Refer to "Managing Server Pools" on page 456
Match Rule Expression Examples
A match rule expression must be specified in double quotes, so any quotes used in a function to
delineate strings must be escaped with a backslash character (\), as in this example that matches
all client requests with a source IP on the 10.10.10/24 network:
expression “client_ip(\“10.10.10/24\”)”
Functions can be negated using the “!” operator. To change the above example to match all client
requests with a source IP not on the 10.10.10/24 network, use this expression:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
421
Working with Clusters and Match Rules
expression “!client_ip(\“10.10.10/24\”)”
Functions can be combined using the logical operators shown in the previous section. For
example, to match a client request for any file with two different file suffixes, you could use an
expression like this:
expression “filename_suffix(\“jpg”) or filename_suffix(\“gif”)”
Functions and operators can be grouped using parentheses to create complex expressions. For
example, to match a client request with a source IP on the 10.10.10/24 network and a URI whose
filename suffix is not “jpg” or “gif”, use the following expression:
expression “client_ip(\“10.10.10/24\”) and!(filename_suffix(\“jpg”) or filename_
suffix(\“gif”))”
Match Rule Expression Notes
Observe the following when constructing match rule expressions:
Match Rule Behavior When Server Status is Not "Up"
When a match rule expression matches a client request, the request is load balanced using the
server pools, parameters, and flags specified in the match rule. The server pools specified in the
match rule may be in a number of “states” that affect the load balancing behavior: the servers
within the sever pools may be up or down, and may have one or both of the quiesce and hot spare
options enabled.
server up
The request is routed to the selected server.
up/quiesce enabled
The request is routed to the selected server.
up/hot spare enabled
The request is routed to the selected server.
server down
If no Responder is selected in the match rule, then the request is sent to
the selected server and, eventually, the client times out. If a Responder is
selected, the Equalizer sends the configured response to the client.
The reason match rules behave as shown above is because the purpose of a match rule is to send
a request that matches an expression to a particular server that can (presumably) better satisfy
the request. In some cases, sending the request to a particular server may be required behavior
for a particular configuration.
422
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
With this in mind, it does not make sense to skip a match rule because the server (or servers)
named in the rule are down, hot spared, or quiesced -- rather, since the server in the rule is
presumably critical to satisfying the request, it makes sense to route the request to the (for
example) down server, and have the client receive an appropriate error -- so that the request can
be retried.
If we instead were to skip a match rule because, for example, the server selected by the match
rule is down, the request would be evaluated by the next match rule -- or the default match rule.
The request, therefore, could potentially be sent to a server in the cluster that does not have the
requested content. This means that the client would receive a “not found” error, instead of an
error indicating that the appropriate server is not currently available.
Considering Case in String Comparisons
String comparisons performed by match functions honor the setting of the ignore case cluster
parameter: if it is set on the cluster (the default), then all match rule functions used for that
cluster are case insensitive; that is, the case of strings is ignored. For example, the string “ab”
will match occurrences of “ab”, “Ab”, “aB”, and “AB”. If ignore case is not set on the cluster, then
all string comparisons are by default case sensitive (the string “ab” will match only “ab”).
To override the ignore case flag setting on the cluster for a match function or block of functions,
you must logically AND the observe_case() or ignore_case() functions with the match function or
block. For example, if ignore case is set on the cluster, you would use the following expression to
force the header_substr() function to make case sensitive string comparisons:
(observe_case() and header_substr(\"host\", \"MySystem\"))
Regular Expressions
Some match functions have prefix, suffix, substr, or regex variants. The regex variants interpret
an argument as a regular expression to match against requests. Regular expressions can be very
costly to compute, so use the prefix, suffix, or substr variants of functions (or Boolean
combinations of prefix and suffix testing), rather than the regex function variants, for best
performance. For example, the following regular expression match:
dirname_regex(\"(two|four|six|eight)\")
Can be replaced by the more efficient:
dirname_substr(\"two\") OR
dirname_substr(\"four\") OR
dirname_substr(\"six\") OR
dirname_substr(\"eight\")
Note that Equalizer match rule expressions support POSIX regular expression syntax only.
Supported Headers
All of the header_*match functions take a header argument, which selects the header of interest. If
this header is not present in the request, the match function evaluates to false.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
423
Working with Clusters and Match Rules
Although HTTP permits a header to span multiple request lines, none of the functions match text
on more than one line. In addition, Equalizer will only parse the first instance of a header. If, for
example, a request has multiple cookie headers, Equalizer will only match against the first cookie
header in the request.
Any text that you enter will be accepted as the header text.
HTTPS Protocol Matching
Equalizer permits the construction of virtual clusters running the HTTPS protocol. HTTPS is HTTP running over
an encrypted transport, typically SSL version 2.0 or 3.0 or TLS version 1.0. All of the functions available for load
balancing HTTP clusters are available for HTTPS clusters. In addition, there are some additional match
functions [ssl2(), ssl3(), and tls1()], that match against the protocol specified in an HTTPS request.
Supported Characters in URIs
The characters permitted in a URI are defined in RFC2396. Equalizer supports all characters
defined in the standard for all Match Functions that have a URI as an argument. Note in particular
that the ASCII space character is not permitted in URIs -- it is required to be encoded by all
conforming browsers as “%20” (see Section 2.4 of RFC2396).
424
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Match Rules, the Once Only Flag, and Cookies
Since multiple client requests may be received on a single TCP/IP connection, Equalizer has a flag
(once only) that specifies whether to check the headers in every request received on a connection,
or to load balance based solely upon the first set of headers received on a connection (and ignore
the headers in subsequent requests on the same connection).
The once only flag is a cluster parameter on the Networking tab. When using Match Rules, it is
usually desirable to turn off the once only flag for the cluster so that Equalizer matches against
each individual request in a connection, not just the first one.
You can also enable or disable once only flag in the match rule Configuration screen (tab), to
override the setting on the cluster for any request that matches that rule. For example, if once
only is enabled on a cluster and disabled on a match rule, any request that matches that match
rule’s expression will be load balanced as if once only were disabled on the cluster.
The following table shows how the setting of once only affects load balancing when a match rule
hit occurs:
match rule hit
on...
once only disabled
once only enabled
...the first request
on a connection
If the request headers contain a cookie
specifying a server in the match rule’s
server list, send the request to the server
in the cookie.
Otherwise, send the request to the server
in the match rule’s server list that is
selected by the load balancing policy in
effect for the match rule.
Same as at left.
Same as above.
If the request headers contain a cookie
specifying a server in the match rule’s
server list, send the request to the
server in the cookie.
Otherwise, send the request to the
server that was selected by the first
request.
...second and
subsequent
requests on the
same connection
Note that Equalizer always honors a cookie that specifies a server in the match rule’s server pool
list, regardless of the setting of the once only flag: the request is sent to the server pool specified
by the cookie. If, however, the cookie specifies a server pool that is not in the match rule’s server
list, the cookie is ignored.
Using Responders in Match Rules
Responders are used to send automated responses to clients when all the server pools in a match
rule are down. See "Modifying a Responder" on page 619 for a complete description of Responders
as well as examples of using Responders in Match Rules.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
425
Working with Clusters and Match Rules
Managing Match Rules
The EQ/OS 10 Administration Interface allows you to create and modify match rules, without
requiring a detailed knowledge of the configuration language syntax used in the eq.conf file. The
interface validates match rules before saving them so that all saved rules are syntactically
correct. For this reason, we recommend you use the interface to create and edit match rules,
rather than editing the configuration file.
The interface does not, however, test the behavior of match rules. Match rules must be tested
against a flow of incoming requests in order to determine if the behavior of the rule is what you
expect.
Before constructing a match rule, you should first understand the general concepts of match rules
covered in "Match Rule Expressions and Bodies" on page 413.
In the Match Rule descriptions herein, instructions are provided for using the GUI first, followed
by instructions for accomplishing the same task using the CLI. Refer to "Working in the CLI" on
page 167 for details on using the CLI commands.
426
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying Match Rules
On the GUI, click on a cluster name in the navigation pane and then click on any of the Match
Rules associated with any of the HTTP or HTTPS clusters to display the match rules defined for
that cluster.
On eqcli, enter the following:
eqcli > cluster clname match
In the example below the Match Rules on the cluster "SP-fe_http" are displayed:
eqcli cl-SP-*> show match
Name Server Pool Responder Expression
nopersist serverool1 responder1 *
images *
test *
ma01 adp_tcp *
New_Match_Rule *
Default Match Rule
All Layer 7 clusters created via the Equalizer Administration Interface start with a single match
rule (named Default) that matches all requests and selects all servers.
match Default {
any()
} then {
servers = all;
}
When displayed any() appears in the Expression field in the GUI as shown below.
The default rule specifies that all server pools defined in the cluster should be used for load
balancing the request, and that all flag settings for the request will be inherited from the cluster
flag settings.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
427
Working with Clusters and Match Rules
Creating a New Match Rule
Match rules can be created using either the CLI or the GUI.
Parameters
The table below shows the parameters, values, and flags used in the configuration of match rules
GUI Parameter (CLI Parameter)
Description
Expression
(expression)
Refer to "Match
Next Match Rule
(nextmatch)
The Next Match Rule field determines the order of processing. For
example, if you were to configure a Match Rule 2 with a Next Match Rule
parameter of Match Rule 1, it would be placed before Match Rule 1 in the
order of processing.
Server Pool
(srvpool)
The ServerPool field determines the server pool to which a match rule
applies its specified conditions and parameters.
Responder
(resp)
The Responderfield allows you to specify an automatic responder for client
requests that match this rule when none of the servers selected in the rule
are available. The responder must already be configured. For a description of
responders as well as examples of using responders in match rules, see
Rule Expression Notes" on page 422.
"Adding a Responder" on page 616.
Compression Minimum Size
(compress_min)
(ADCs with Hardware
Acceleration)
Compression MIME Types
(compress_types)
(ADCs with Hardware
Acceleration)
The minimum file size in bytes required for GZIP compression, if enabled.
Equalizer uses GZIP to compress the payload (or content) of the server
response before sending it back to the client. This is typically done for 2
reasons: faster client response and better user experience. In addition. less
ISP bandwidth is used in sending smaller files back to clients. Files smaller
than the minimum specified are not compressed. Default:1024
bytes.cceleration)
Specifies the mime-types that will be compressed when the Compress
option is enabled for the match rule. The value of this parameter is a string
(maximum length: 512 characters) with valid mime-type names separated
by a colon (:). The default compress mime-types string specifies the
following mime-types
Flags
Spoof
(spoof)
428
Spoofcauses Equalizer to spoof the client IP address when Equalizer routes a
request to a server in a virtual cluster; that is, the IP address of the client is
sent to the server, not the IP address of the Equalizer. This option is on by
default. If you disable this option, the server receiving the request will see
the Equalizer’s address as the client address because the TCP connection to
the client is terminated when the request is routed. When spoof is enabled,
the server pool in the cluster must use the Equalizer as the default gateway
for routing.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
Abort Server
(abort_server)
By default, when a client closes a connection, Equalizer waits for a response
from the server before closing the server connection. If this flag is enabled,
Equalizer will not wait for a response before closing the connection to the
server; instead it sends a TCP RST (reset) to the server when the client
closes the connection.
Ignore Case
(ignore_case)
This function always evaluates to true, and is intended to be used to apply
the Ignore Caseflag for comparisons when it is not set on the cluster. When
this function is ANDed with other functions, it has the effect of forcing case to
be ignored for any comparisons done by the match rule.
Insert Client IP
(insert_client_ip)(HTTPS
only)
When this flag is enabled, Equalizer inserts an X-forwarded-for:header
with the client's IP address into all client requests before they are sent to the
server. This flag is disabled by default for HTTP clusters and enabled by
default for HTTPS clusters.
Once Only
(once_only)
Limits Equalizer to parsing headers (and executing match rules) for only the
first request of any client making multiple requests across a single TCP
connection. This option is off by default: meaning that Equalizer will parse
the headers of every client request.
Disable
(disable)
Enable this flag to disable this match rule without deleting it. This can be
useful when testing new match rules.
TCP Multiplexing
(tcp_mux)
Enables TCP multiplexing for a cluster. TCP multiplexing must also be
enabled on at least one server instance in the server pool assigned to the
cluster (or one of its match rules).
Compress
(compress)
When this option is enabled, Equalizer automatically detects requests to the
cluster/match rule from compression-capable browser clients and performs
GZIP compression on all responses sent to that client. The cluster IP address
will not accept requests when this flag is enabled. When enabled, hardware
compression will be used on ADCs with compression hardware on board and
software compression will be used on ADCs without compression hardware.
Server Side Encryption
(sse)
Enables the Server Side Encryption option for the Match Rule. By enabling
this option, Equalizer will encrypt packets to back end servers using the
SSL/TLS specifications in the Server Side Encryption Global Parameters (See
"Server Side Encryption" on page 291)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
429
Working with Clusters and Match Rules
Creating Match Rules using the GUI
Proceed with the following to add a match rule to a virtual cluster using the GUI:
1. Log into the GUI using a login that has add/del access for the cluster. See Logging in on
page.
2. In the navigation pane on the left, right-click the name of the Layer 7 cluster to which you
want to add a match rule, and select Add New Match Rule to display the following:
3. Enter a name for the new rule in the Match Rule Namefield. All match names within a cluster
must be unique.
4. Make a selection for the Next Match Rule using the drop-down list. When you select Next Match
Rule, the new match rule you are creating will be placed before the Next MatchRule and will be
evaluated in that sequence in load balancing.
5. Click Commit when are finished. The Configuration screen (tab) will be displayed as shown
below.
Note - If you do not enable a check box for at least one server pool, Equalizer will drop the connection for any request
that matches the rule. You must also associate a server pool with the match rule on the Configuration screen (tab).
6. Use the Expression Editor to build your match expression. Refer to"Match Rule Expression
Examples" on page 421 for details on using this feature.
430
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
7. Use the Server Pool drop down list to select a Server Pool to direct Layer 7 traffic if it
complies with the match rule conditions specified. Refer to "Managing Server Pools" on page
456 for instructions on configuring Server Pools.
8. Configure the other parameters for the Match Ruleas necessary. Use the table above for
parameters, values, and flags for the configuration of the match rule.
9. Click on the Commit button after making changes to the settings.
6. Use the Expression Editor to build your match expression. Refer to"Match Rule Expression
Examples" on page 421 for details on using this feature.
7. Use the Server Pool drop down list to select a Server Pool to direct Layer 7 traffic if it
complies with the match rule conditions specified. Refer to "Managing Server Pools" on page
456 for instructions on configuring Server Pools.
8. Configure the other parameters for the Match Ruleas necessary. The following table
describes each of the selections.Changing these parameters will override the cluster
setting.
9. The ordering of match rules is important, as they are processed from first to last until one
of them evaluates to true, at which time the match body is processed. The initial match
expression of a new rule, any() is one that will always evaluate to true, meaning that this
match rule will always be selected. It is good practice to be cautious when adding new
match rules to ensure that all the traffic to a cluster does not get mishandled. Use the
Disable flag to skip a match rule that is still being developed.
10. Click on the Commit button to Commit the parameter selections.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
431
Working with Clusters and Match Rules
Adding Match Rules using the CLI
1. Log into the CLI using a login that has add/del access for the cluster. (See "Starting the CLI"
on page 168.)
2. At the eqcli prompt enter the cluster name followed by "match maname". In the example
below a Match Rule test is added to the Layer 7 cluster Sp-fe_http.
Match Rule Name : test
Next Match Rule : ma01
Cluster Name : SP-fe_http
Server Pool :
Responder :
Cookie Path :
Cookie Domain :
Cookie Scheme : 0
Cookie Age : 0
Cookie Generation : 0
Flags : disable
Expression :
any()
Match Rule Name : test
Next Match Rule : ma01
Cluster Name : SP-fe_http
Server Pool :
Responder :
Cookie Path :
Cookie Domain :
Cookie Scheme : 0
Cookie Age : 0
Cookie Generation : 0
Flags : disable
Expression :
any()
432
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
3. Assign a Server Pool to the newly created Match Rule by entering:
eqcli cl-clname-ma-maname> srvpool spname
4. Add or remove Responder, CookiePath, CookieDomain, CookieScheme, CookieAge and
CookieGeneration and Flags using the Parameters table above as a reference.
5. Configure the Match Expressions using the following at the eqcli prompt. Descriptions of the
Expressions are provided in "Match Rule Functions" on page 417.
eqcli cl-clname-ma-maname> expression string
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
433
Working with Clusters and Match Rules
Modifying a Match Rule
To edit a match rule using the GUI, follow these steps:
1. Log into the GUI using a login that has write access for the cluster (See "Logging In" on page
268).
2. In the navigation pane on the left click the name of the match rule to be changed.
3. Make the desired changes to the match rule, as shown in the procedure in the previous
section, starting at Step 5.
To edit a match rule using eqcli follow these steps:
1. Log into eqcli using a login that has add/del access for the cluster (See "Starting the CLI" on
page 168)
2. Make the desired changes using eqcli as shown in the procedures beginning with step 1.
Removing a Match Rule
To delete a match rule using the GUI, follow these steps:
1. Log into the GUI using a login that has add/del access for the cluster (See "Logging In" on
page 268).
2. In the navigation pane on the left, right-click the name of the match rule to be deleted and
select Delete Match Rule.
3. Click delete to confirm that you want to delete the match rule.
To delete a match rule using eqcli, follow these steps:
1. Log into eqcli using a login that has add/del access for the cluster (See "Starting the CLI" on
page 168).
2. Enter the following at the eqcli prompt:
eqcli > cluster clname no match maname
434
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the Match Rule Expression Editor
The Match Rule Expression Editor shown below is a feature of the GUI that allows the user an easy
method of building Match Expressions. As described in "Match Rule Expressions and Bodies" on
page 413, Match Expressions are made up of match functions, most of which are protocol-specific,
joined by logical operators, optionally preceded by the negation operator, with sets of beginning
and end parentheses for grouping where Match Bodies required. The Expression editor allows the
user to drag and drop functions and operators to build the desired expressions.
The Match Rule Expression Editor is separated into 3 panes.
l
The Operators pane displays the available operators:
“$$” is used for the logical AND operator.
“!” is used for the logical NOT operator.
“ll” is used for the logical OR operator.
“()” is used to group functions and operators
l
l
The Functions (refer to "Match Rule Functions" on page 417 ) are displayed on the right pane
displays a list of all of the available functions.
The Expression Workbench is the work area used to build the expressions.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
435
Working with Clusters and Match Rules
Operating within the Expression Editor
You can drag Functions and Operators into the Expressions Workbench. If you drag a new element onto
the top of an existing element, the new element will be place before the existing element. If you
drag the new element onto the bottom of en existing element, the new element will be placed
after the existing element.
Elements can also be dragged/moved within the Expressions Workbench or to the trash
.
in many cases, Functions require a value such as shown below where the input of a path is
required. Click on the Function to display the input field to enter the required details. Click on the
Accept button to add the details to the Function or Cancel to discard the details.
Clicking on the continue or cancel button will close the Expression Editor.
Clicking on the Reset button will remove all of your configured parameters and return to the
default screen.
Clicking on the Commit button will assign all of your match rule configurations to the cluster.
The figure below shows an example of a completed Match Rule configuration. In this example a
match rule is configured so that the incoming URL will be analyzed for the file extensions.jpg,.gif
and.png. It this suffix is found, the incoming graphical files will be directed by Equalizer to a Server
Pool called Images.
Note - If a new Server Pool is required in the match rule for redirection by Equalizer it must be configured prior to
creating the match rule. Refer to "Managing Server Pools" on page 456 to configure a new Server Pool if a
new one is required.
436
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Example Match Rules
The Related Topics navigate to examples of how to create a few of the most commonly used types
of match rules.
Parsing the URI Using Match Rules
In this example, we want to direct requests to a pool of specific server pools based on the
hostname used in the URI contained in the request. We want all requests for URIs that start with
“support” to go to one server pool, and all other requests that do not match this rule to be load
balanced across all server pools in the cluster.
To do this, we will construct one match rule that parses the URI; if the URI contains the string
“support”, it forwards the request to the server pool sv_support. For this example, we assume that
a cluster with server pools has already been defined.
1. Log into the GUI using a login that has add/del access for the cluster.
2. In the left frame, right-click the name of the Layer 7 cluster to which you want to add the
rule, and select Add Match Rule. The Add Match Rule dialog appears:
a. Type a name into the Match Rule Name field. In this case New Match Rule was
added.
b. Select the Next Match Rule from the drop-down list to determine the placement
of New Match Rule in the order of processing. In this case test was selected.
c. Click on Commit. If test was selected as the Next Match Rule it will appear
beneath Test in the navigation pane on the left.
The match rule is created, added to the navigation pane on the left, and its Configuration tab is
opened. Refer to "Using the Match Rule Expression Editor" on page 435 for further descriptions on
using the Expression Editor.
3. Click on the Expression Editor button and drag and drop host_prefix from the drop-down box
in the Functions pane into the Expression Workbench pane.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
437
Working with Clusters and Match Rules
4. Type “support” into the hostname prefix text box as follows:
5. Click on accept after entering “support” and then click on the continue button at the bottom of
the Expression Editor to save the expression.
Now, all requests for URIs that start with “support” should go to the sv_support server pool, and all
other requests that do not match this rule to be load balanced across all server pools in the
cluster.
438
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Changing Persistence Settings Using Match Rules
By default, a client request that matches a match rule expression is load balanced using the same
load balancing parameters and options that are currently set on the cluster. The following
describes how to change load balancing parameters and flags in a match rule.
For example, persistent connections to server pools are enabled by the Persist cluster flag, which
is enabled by default when you create a cluster. Let’s assume that you only want to disable
persistence for incoming requests that have a URI containing a hostname in the following format:
xxx.testdonotpersistexample.com
We’ll use the host_suffix() match rule function to test for the above hostname format. For this
example, we assume that a cluster with three server pools has already been defined. We will
construct a match rule that will turn off Persist for any request that contains the host suffix
“testdonotpersistexample.com”; this request will be balanced across all of the server pools in the
cluster.
1. Log into the GUI using a login that has add/del access for the cluster.
2. In the navigation pane on the left, right-click the name of the Layer 7 cluster to which you
want to add the rule, and select Add Match Rule. The Add Match Rule dialog appears:
a. Type nopersist into the match name text box.
b. Select the server pool that this new rule will precede using the Next Match Rule
drop-down list and click on Commit. The new rule will appear on the navigation
tree in within the cluster from which is was created.
c. On the match rule Configuration screen (tab) select the Server Pool that will be
used for load balancing with the Persist checkbox disabled.
3. Click on the Expression Editor button to display the Expression editor.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
439
Working with Clusters and Match Rules
a. Leaving the any() expression in place, drag and drop the host_suffix from the
Functions pane to the Expression Workbox beside the any() expression.
b. Type “testdonotpersisteexample.com” into the hostname suffix() function . The new
expression should appear as follows.
c. Click on continue.
4. Uncheck the Persist checkbox and Disable checkboxes on the Configuration tab.
5. Click on Commit to save your changes to the nopersist rule.
You have now disabled persistence for incoming requests that have a URI containing the
hostname "testexample.com".
Using Persistence with Match Rules
When a match rule is configured you can specify that persistence methods for that match rule -which supercede those the persistence method specified for a cluster. This is the persistence type
to be used when the match rules conditions are met. For example, if you configured a match rule
expression to redirect requests to Server A based on the criteria configured in an expression, you
can also configure the persistence type to be used when that criteria is met.
To configure persistence with match rules select a configured match rule on the left navigational
pane of the GUI. Select the Persistence tab to display the configuration screen. It is configured
the same as the configuration of HTTP and HTTPS cluster persistence.
440
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Changing the Spoof (SNAT) Setting Using Match Rules
By default, Equalizer uses the client IP address as the source address in the packets it forwards to
server pools, and then translates the server IP in server responses to Equalizer’s cluster IP. This
is commonly called a Half-NAT configuration, since Equalizer is not performing Network Address
translation (or NAT) on client requests. Because the server pools behind Equalizer see the source
IP of the client, the server pools need to be configured to route client requests back through
Equalizer -- either by making Equalizer the default. This behavior is controlled by the Spoof
option, which is enabled by default. Half-NAT configurations are only a problem when a client is
on the same subnet as the servers behind Equalizer, since the servers will try to respond directly
back to the client -- which will not recognize the server connection as a response to it’s original
request and so refuse the connection.
This "local client" problem is solved by disabling the Spoof option. When Spoof is disabled,
Equalizer translates the source IP address in the request to one of Equalizer’s IP addresses before
sending it on to the server. This is called Source Network Address Translation, or SNAT -- and this
configuration is often called Full-NAT, since Equalizer is translating the client IP in packets from
clients, as well as the server IP in packets from servers. In this case, servers will send responses
to Equalizer’s IP address, so no special routing or gateway is needed on the server.
So, clusters with clients on a different subnet than the server pools behind it can have the spoof
option enabled, while clusters with only local clients should have spoof disabled.
But what do you do if you expect client requests to come to the cluster from the local server
subnet as well as other subnets?
In network configurations where Equalizer needs to be able to forward server responses to clients
on the server subnet as well as other subnets for the same virtual cluster IP, the Spoof option can
be selectively enabled or disabled by creating a Layer 7 match rule that looks for specific client IP
addresses in incoming requests. When an incoming request’s source IP matches the rule, Spoof
will be set as appropriate for that connection. This is commonly called Selective SNAT.
On Equalizer, implementing Selective SNAT using a Match Rule is the recommended method to
allow local access to Layer 7 clusters with Spoof enabled; other alternatives include:
l
l
adding static routes on all your server pools to clients on the server’s local subnet
creating two clusters -- one on the non-server subnet with spoof enabled, and one on the
server subnet with spoof disabled
Selective SNAT using a match rule is more easily implemented and maintained than either of the
above methods, but can be configured only for Layer 7 clusters. If you require Selective SNAT
with a Layer 4 cluster, you’ll need to use one of the above methods.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
441
Working with Clusters and Match Rules
Selective SNAT Example
The procedure below shows you how to create a match rule that selectively disables the cluster
Spoof option based on the client IP address of an incoming connection. It is assumed that the
cluster for which the match rule is created has Spoof enabled on the cluster Configuration screen
(tab), and that the cluster works properly for clients on subnets other than the subnet to which the
server pools in the cluster are connected.
1. Right-click the name of the cluster for which you want to implement selective SNAT, and
select Add Match Rule.
2. On the Add New Match Rule form:
a. Type in a Match Name or accept the default.
b. Select the Next Match Rule from the drop down list to place the new match rule
in the desired order on the cluster.
c. Click on Commit.
The new match rule is created and its Configuration Screen (tab) is opened.
3. Leave any() in the expression field.
4. In the Expression Editor:
a. Drag and drop the client_ip function from the Functions pane to the Expression
Workbench.
b. Specify a simple IP address (e.g., “192.168.0.240”), or an IP address in
Classless Inter- Domain Routing (CIDR) notation (e.g., “192.168.0.0/24”) to
specify an entire subnet in the client_ip function. Click on the Continue button
when finished.
The Expression field should now contain the client_ip function with the ip argument you specified
above.
5. Uncheck both the Spoof checkbox and the Disable checkbox on the Configuration Screen
(tab).
6. Click on Commit.
Clients whose IP addresses are selected by the new match rule should now be able to connect
successfully to the cluster IP. Right-click the name of the match rule in the left frame; the
Processed counter in the popup menu should increase as clients are selected by the match rule.
Select Match Rule Plots from the popup menu to display a history of the number of connections
processed by the match rule.
442
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Selection Based on Content Type Using Match Rules
In this example, assume a configuration that has dedicated one or more server pools to return
only image files (.gif,.jpg, etc.), while the remainder of the server pools return all the other
content for client requests.
We want to direct all requests for images to a particular server pool, and balance the remainder
of requests across the other server pools in the cluster. The image server pool is connected to a
common storage device that contains the images. The remaining server pools are all dedicated to
serving particular content for different web sites. For this example, we assume that a cluster has
already been defined.
We want to maintain persistent connections for the web site servers, assuming that some of the
websites may need to maintain sessions for applications such as shopping carts, email, etc.
Persistent connections are not necessary for the image servers, since they access the images
from common storage and have no need to maintain client sessions, so there is no need to incur
the performance impact of maintaining session information.
To do this, we’ll create two match rules, as follows:
1. Log into the GUI using a login that has add/del access for the cluster.
2. In the navigation pane on the left, click the name of the Layer 7 cluster to which you want to
add the rule. The cluster Configuration screen (tab) will appear on the right:
a. Make sure that the Once Only checkbox is not checked; otherwise, uncheck it
and click Commit.
b. Make sure the Persist checkbox is not checked; otherwise, uncheck it and click
Commit.
These steps are necessary because these flags, if enabled, cause only the first request in a
connection to be evaluated. Since we want content to come from one server pool and images from
another, we want the server pools that will have persistent connections to be chosen by the match
rules.
3. Right-click the cluster name in the left frame and select Add Match Rule. The Add Match Rule
form appears:
a. Type images into the Match Name text box and use the Next Match Rule dropdown list to specify the match rule order for this match rule on the selected
cluster. Click on Commit. In this match rule, we’ll construct an expression that
will match all the filename extensions of the images to be served. These
requests will go to the image servers.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
443
Working with Clusters and Match Rules
The match rule is created, added to the object tree, and its Configuration tab is opened:
4. Click on the Expression Editor button:
a. Drag and drop the filename_suffix function from the from Functions pane to the
ExpressionWorkbench.
b. Type “jpg” into the filename suffix text box.
c. Select continue.
5. Repeat Step 4 for each of the other filename suffixes on our example servers -- gif, bmp, tif
and png.
6. In our example, we want all the images to be served from sp01. On the imagesConfiguration
screen (tab), select sp01 from the Server Pool drop-down list. When you are done, the match
expression should look like this:
444
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
7. Click on Commit.
The images rule we created selects all the requests for image files; now we need a rule to
determine which servers will receive all the other requests. The Default rule is not sufficient, and
in fact we don’t want it to be reached, since it could send a request for content to one of the image
servers. So, we’ll create another rule with the same match expression as the Default [any()], but a
restricted list of servers. This effectively replaces the Default match rule with one of our own.
8. In the left frame, right-click the name of the cluster and select Add Match Rule. The Add
Match Rule screen appears:
a. Type “content” into the match name text box and use the Next Match Rule dropdown list to specify the match rule order for this match rule on the selected
cluster. Click on Commit.
b. On the Configuration screen (tab) use the drop-down list to select the server
pool in which all other content is to be sent.
c. Select Commit.
The match rule is created, added to the object tree, and its Configuration Screen (tab) is opened:
9. Check the Persist check box. (Remember that in our example we’re enabling Persist for the
content servers, so that persistent sessions can be maintained by the applications that run
on these servers.)
10. Select the Commit button to save your changes to the Content rule.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
445
Working with Clusters and Match Rules
Cluster and Match Rule Statistics and Reporting
The CLI display of Statistics can be seen by entering the following within the cluster or match rule
context:
Sample of Layer 7 Cluster Statistical Display
Note - Refer to "Header
Editing Reporting" on page 1068 for a description of the Header Editing Statistics.
eqcli cl-Tes*> stats
Current
TOTALPRCSD
50891
TOTALRESPPRCSD 68535
TIMESPENT
45526
ACTIVECONX
242
BYTERCVD
20354896
BYTESEND
146733440
DROPNOSRVR
0
TOTALSTKY
0
CURRSTKY
0
REQPARSED
68535
REQFAILED
0
REQFAILHDR
0
RSPPARSED
0
RSPFAILED
0
RSPFAILHDR
0
CLNTTO
68111
SRVRTO
0
CONNTO
0
SELPERSIST
0
SPLICE
50891
CURCLNTWAITQ
0
CURCLNTWAITSRVR 0
CURCOMP
0
TOTALCOMP
0
INBYTECOMP
0
OUTBYTECOMP
0
60 sec
34
60
N/A
0
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
10 min
37
63
N/A
256
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
60 min
27
43
N/A
186
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
Header Edit Statistic
Count
---------------------------------------------------------------------Number of times client_request_edit() executed successfully:
2
Number of times client_request_edit() executed with errors:
0
Number of times server_response_edit() executed successfully:
2
Number of times server_response_edit() executed with errors:
0
eqcli cl-Tes*>
446
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Sample of Layer 7 HTTP and HTTPS Match Rule Statistical Display
Note - Refer to "Header
Editing Reporting" on page 1068 for a description of the Header Editing Statistics.
eqcli cl-htt*-ma-Tes*> stats
TOTALPRCSD
Current
6157678
60sec
4218
10min
3028
60min
2479
Header Edit Statistic
Count
---------------------------------------------------------------------Number of times client_request_edit() executed successfully:
2
Number of times client_request_edit() executed with errors:
0
Number of times server_response_edit() executed successfully:
2
Number of times server_response_edit() executed with errors:
0
eqcli cl-htt*-ma-Tes*>
Sample of Layer 4 Cluster Statistical Display
eqcli cl-tes*> stats
Current
BYTERCVD
27781404
BYTESEND
138862736
DROPNOSRVR
0
TOTALSTKY
0
CURRSTKY
0
60 sec
N/A
N/A
N/A
N/A
0
10 min
N/A
N/A
N/A
N/A
0
60 min
N/A
N/A
N/A
N/A
0
eqcli cl-tes*>
To view the GUI display:
1. Verify that you are logged into the GUI. (Refer to "Logging In" on page 268.)
2. Select the Load Balance configuration tab is it is not already selected.
3. Click on the arrow (u) beside Clusters to expand the branch.
4. Select a cluster or responder Server on the left navigational pane and click on the Reporting
tab to display statistics. The following is an example of the statistics displayed.
A Layer 4 statistical display is similar however it displays Connections/second (CPS), Throughput , Bytes
Received, Bytes Sent , Total Sticky Records, Current Sticky Records, and Total Time for Server Responses.
A Layer 7 Http and Https Match Rule statistical display is also similar however, it displays
Connections /second (CPS) and Total Connections.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
447
Working with Clusters and Match Rules
Sample Layer 7 Cluster GUI Statistical Displays
The following are definitions for the statistical terms shown on both the CLI and GUI:
448
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 Cluster Statistic Definitions
CLI Term
GUI Term
Definition
TOTALPRCSD
Total Connections
Connections Processed.
TOTALRESPPRCSD
Total Transactions
The total responses processed.
TIMESPENT
Total Time For Server
Responses
The total time spent on this object.
ACTIVECONX
Active Connections
Active Connections.
BYTERCVD
Bytes Received
Bytes received.
BYTESEND
Bytes Sent
Bytes transmitted.
REQPARSED
Number of Request Headers
Parsed
This is the total number of times that an HTTP
request header was parsed.
REQFAILED
Number of Request Headers
The number of request header failed
REQFAILHDR
Number of Request Headers
Failed Parsing
The number of requests dropped for exceeding
header limit.
RSPPARSED
Response Header Parse
Successful
Total number of times HTTP response headers
was parsed.
RSPFAILED
Response Header Parse failed
The number of response headers failed.
RSPFAILHDR
Too Many Response Headers
Too many response header.
CLNTTO
Cx dropped due to Client
Timeout
Connections dropped due to client timeout.
SRVRTO
Cx Dropped due to Server
Timeout
Connections dropped due to server timeout.
CONNTO
Cx Dropped Due to Connect
Timeout
Connections dropped due to connect timeout
SELPERSIST
Server Selected By Cookie
The number of times the server was selected by a
cookie.
SPLICE
Current Client Cx Waiting for
Server Cx
Total client-server connections linked.
CURCLNTWAITQ
Client Cx in Wait Queue
The client connections in the queue.
CURCLNTWAITSRVR
Current Client Cx Waiting for
Server Cx
The number of client connections waiting for
server connections.
CURCOMP
Current Responses Being
Compressed
The current responses being compressed.
TOTALCOMP
Total Responses Compressed
The total responses being compressed.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
449
Working with Clusters and Match Rules
CLI Term
GUI Term
Definition
INBYTECOMP
Input Bytes to Compress
Input bytes to compress.
OUTBYTECOMP
Output Bytes after
Compressions
Output byte after compression.
Layer 7 HTTP and HTTPS Match Rule Statistic Definitions
CLI Term
GUI Term
Definition
TOTALPRCSD
Connections/second (CSP)
Connections Processed.
N/A
Transactions/second (TPS)
The total responses processed.
N/A
Throughput
Throughput
N/A
Total Connections
Total connections.
N/A
Total Transactions
Total transactions.
N/A
Active Connections
Active connections.
N/A
Bytes Received
Bytes received.
N/A
Bytes Sent
Bytes transmitted.
N/A
Total Time For Server
Responses
Total time for server responses
N/A
Connections Dropped Due To
No Server
Connections dropped due to no server
450
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 4 Cluster Statistic Definitions
CLI Term
GUI Term
Definition
BYTERCVD
Bytes Received
Bytes received.
BYTESEND
Bytes Sent
Bytes transmitted.
N/A
Connections/second (CPS)
Connections per second.
DROPNOSRVR
N/A
Connections dropped due to no server.
TOTALSTKY
Total Sticky Records
Total sticky connections.
N/A
Throughput
Throughput.
CURRSTKY
Current Sticky Records
The current sticky record.
N/A
Total Time For
Server Responses
Total time for server responses.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
451
Working with Clusters and Match Rules
The following is an example of a graphical plot that can be displayed on the GUI. Select a Cluster
or Match Rule on the left navigational pane and click on the Reporting tab and then Plotting. The
following will be displayed:
Sample Layer 7 Cluster Graphical Plot
The specific types of statistics that are displayed are determined by the selections on the Statistics
pane on the upper right corner of the GUI.Make selections based on the data that you require.
The Plot Type selection determines whether the display shown reflects a Static Time Span which is
configured using the slider or whether a real time duration is display. If Real Time Duration is
selected the slider controls will change to Duration and Refresh controls as shown below. In this case
set the Duration of time in which you would like to review statistics and the Refresh rate desired.
452
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Sample Match Rule Graphical Plot
Sample Layer 4 Cluster Graphical Plot
The specific types of statistics that are displayed are determined by the selections on the Statistics
pane on the upper right corner of the GUI.Make selections based on the data that you require.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
453
Working with Clusters and Match Rules
The Plot Type selection determines whether the display shown reflects a Static Time Span which is
configured using the slider or whether a real time duration is display. If Real Time Duration is
selected the slider controls will change to Duration and Refresh controls as shown below. In this case
set the Duration of time in which you would like to review statistics and the Refresh rate desired.
454
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 13
Server Pools and Server Instances
Sections in this chapter include:
Managing Server Pools
Server Pool Summary
Configuring Server Pool Load-Balancing Options
Using Active Content Verification (ACV)
Adding and Configuring Server Pools
Adding Server Instances
Server Instance Summary Screen
Associating a Server Pool with a Cluster
Deleting Server Pools
Server Pool and Server Instance Reporting
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
456
457
459
461
463
466
470
471
472
473
455
Server Pools and Server Instances
Managing Server Pools
A server is attached to a cluster via a server pool. A server pool is a collection of server
definitions, each of which has additional parameters assigned to it in the server pool -- these
additional parameters are organized by the server’s name and are referred to as server instances
within the server pool context. This allows you to associate a distinct set of server instance
options (weight, flags, maximum number of connections), to multiple instances of the same real
server in different server pools.
The following subsections describe Server Pool management using both the GUI and CLI.
456
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Pool Summary
Server Pool Summary Screen on the GUI
The Server Pool Summary screen shown below will be displayed when you select the Load Balance
configuration tab in the left navigational pane and then click on Server Pools. It displays the
configured server pools, Load Balancing Policy, Status and the Clusters associated with them.
Double click on any of the Server Pools in the list to and the screen will expand to display the Server
Pool Settings configuration screen.
Status Indicators
These icons provide status of the server instances in the server pools.
This icon indicates that the server instances in the server pool are up and running.
This icon indicates that one or more of the server instances in the server pool are down.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
457
Server Pools and Server Instances
Server Pool Summary using the CLI
To view server pool parameters and properties using the GUI use the following example,
replacing srvpool1 with the name of the server pool that you would like to view:
eqcli > show srvpool srvpool1
Server Pool Name
Load balancing Policy
Load balancing Responsiveness
Flags
Custom lb: healthcheck weight
Custom lb: connection weight
Custom lb: delay weight
:
:
:
:
:
:
:
srvpool1
round-robin
3
33
33
33
eqcli >
458
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Server Pool Load-Balancing Options
Configure load balancing policy and response settings for each server pool independently. Multiple
clusters do not need to use the same load balancing configuration even if the same physical
server machines host them. For example, if one cluster on port 80 handles HTML traffic and one
on port 8000 serves images, you can configure different load balancing policies for each server
pool.
When you use adaptive load balancing (that is, you have not set the cluster’s load balancing policy
to round robin or static weight), you can adjust Equalizer to optimize performance.
Equalizer’s Load Balancing Policies
Equalizer supports the following load balancing policies, each of which is associated with a
particular algorithm that Equalizer uses to determine how to distribute requests among the
servers in the server pool:
l
Round-robin load balancing - distributes requests equally on the server pool in the cluster.
Equalizer dispatches the first incoming request to the first server, the second to the second
server, and so on. When Equalizer reaches the last server, it repeats the cycle. If a server
in the cluster is down, Equalizer does not send requests to that server. This is the default
method.
The round robin method does not support Equalizer’s adaptive load balancing feature; so,
Equalizer ignores the servers’ initial weights and does not attempt to dynamically adjust
server weights based on server performance.
l
Static load balancing - distributes requests among the servers depending on their assigned
initial weights. A server with a higher initial weight gets a higher percentage of the incoming
requests. Think of this method as a weighted round robin implementation. Static weight
load balancing does not support Equalizer’s adaptive load balancing feature; Equalizer does
not dynamically adjust server weights based on server performance.
l
Adaptive load balancing - distributes the load according to the following performance
indicators for each server.
l
Response is the length of time for the server to begin sending reply packets after Equalizer
sends a request.
l
l
Least Cxns (least connections) load balancing - dispatches the highest percentage of
requests to the server with the least number of active connections. In the same way as
Fastest Response, Equalizer tries to avoid overloading the server so it checks the server’s
response time and server agent value. Least Connections optimizes the balance of
connections to servers in the cluster.
Server Agent load balancing - dispatches the highest percentage of requests to the server
with the lowest server agent value. In a similar way to Fastest Response, Equalizer tries to
avoid overloading the server by checking the number of connections and response time.
This method only works if the server agents are running on every server instance in the
server pool.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
459
Server Pools and Server Instances
l
Custom load balancing - If custom is selected, you can adjust the load balancing policy
parameters:
o
Connections - The relative influence on the policy of the number of active
connections currently open to a server
o
Response Timeload balancing - dispatches the highest percentage of requests to
the server with the shortest response time. Equalizer does this carefully: if
Equalizer sends too many requests to a server, the result can be an overloaded
server with slower response time. The fastest response policy optimizes the
cluster-wide response time. The fastest response policy also checks the number
of active connections and server agent values (if configured); but both of these
have less of an influence than they do under the adaptive load balancing policy.
For example, if a server’s active connection count and server agent values are
high, Equalizer might not dispatch new requests to that server even if that
server’s response time is the fastest in the cluster.
o
Health Checks - This is the relative weight for the aggregate health check
response value in load balancing calculations.
o
Responsiveness - Determines how aggressively server dynamic weights are
optimized as a cluster load changes.
Aggressive Load Balancing
After you fine-tune the initial weights of each server in the cluster, you might discover that
Equalizer is not adjusting the dynamic weights of the servers at all: the dynamic weights are very
stable, even under a heavy load. In this case, you might want to set the cluster’s load balancing
response parameter to fast. Then Equalizer tries to optimize the performance of your servers
more aggressively; this should improve the overall cluster performance. For more information
about setting server weights, see "Adjusting a Server’s Initial Weight" on page 511.
Dynamic Weight Oscillations
If you notice a particular server’s dynamic weight oscillates (for example, the dynamic weight
varies from far below 100 to far above 100 and back again), you might benefit by choosing slow
response for the cluster. You should also investigate the reason for this behavior; it is possible
that the server application is behaving erratically.
460
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using Active Content Verification (ACV)
Active Content Verification (ACV) is a mechanism for checking the validity of a server. When you
enable ACV for a server pool, Equalizer requests data from each server instance in the server pool
and verifies that the returned data contains a character string that indicates that the data is valid.
You can use ACV with most network services that support a text-based request/response protocol,
such as HTTP. Note, however, that you cannot use ACV with Layer 4 UDP clusters.
ACV checking is performed as part of the high-level TCP probes that Equalizer sends to every
server by default. To enable ACV, you specify an ACV response string for a server pool. Equalizer
which will then search for the ACV response string in the first 1024 characters of the server’s
response to the high-level TCP probes. If the ACV response string is not found, the server is
marked down. An ACV probe can be specified if the service running on the server’s probe port
requires input in order to respond.
How ACV works is best explained using a simple example. The HTTP protocol enables you to
establish a connection to a server, request a file, and read the result.
> telnet www.myserver.com 80 >>>>
User requests connection to server.
Connected to www.myserver.com >>>>
Telnet indicates connection is established.
> GET /index.html >>>>
User sends request for HTML page.
<HTML> >>>>>
Server responds with requested page.
<TITLE>Welcome to our Home Page </TITLE>
</HTML>
Connection closed by foreign host >>>>
Telnet indicates server connection closed.
Equalizer can perform the same exchange automatically and verify the server’s response by
checking the returned data against an expected result.
Specifying an ACV probe string and an ACV response string basically automates the above exchange.
Equalizer uses the probe string to request data from each server. To verify the server’s content,
Equalizer searches the returned data for the response string. For example, you can use “GET
/index.html” as the ACV probe string and you can set the response string to some text, such as
“Welcome” appears on the home page.
Similarly, if you have a Web server with a PHP application that accesses a database, you can use
ACV to ensure that all the components of the application are working. You could set up a PHP page
called test.php that accesses the database and returns a page containing “ALL OK” if there are no
problems.
Then you would enter and ACV Query and an ACV Response String using either the CLI or GUI. :
If the page that is returned contains the correct response string in the first 1000 characters,
including headers) the server is marked “up”; if “ALL OK” were not present, the server is marked
down.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
461
Server Pools and Server Instances
The response string should be text that appears only in a valid response. This string is casesensitive. An example of a poorly chosen string would be “HTML”, since most web servers
automatically generate error pages that contain valid HTML.
For more information on probing, see "Configuring ACV Health Checks" on page 544.
462
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding and Configuring Server Pools
Add and configure Server Pools using the GUI or CLI as follows:
Server Pool Parameters
GUI Parameter (CLI Parameter)
Description
Disable
(disable)
Selecting the Disable option will disable the Server Pool
The Responsiveness setting controls how aggressively Equalizer adjusts
the servers’ dynamic weights. Equalizer provides five response settings:
Slowest, Slow, Medium, Fast, and Fastest. The response setting
affects the dynamic weight spread, weight spread coefficient, and
optimization threshold that Equalizer uses when it performs adaptive load
balancing:
Dynamic Weight Spread indicates how far a server’s dynamic
weight can vary (or spread) from its initial weight.
Responsiveness
(respv)
Weight Spread Coefficient regulates the speed of change to a
server’s dynamic weight. The weight spread coefficient causes
dynamic weight changes to happen more slowly as the difference
between the dynamic weight and the initial weight increases.
Optimization Threshold controls how frequently Equalizer adjusts
dynamic weights. If Equalizer adjusts server weights too aggressively,
oscillations in server weights can occur and cluster-wide performance
can suffer. On the other hand, if Equalizer does not adjust weights
often enough, server overloads might not be compensated for quickly
enough and cluster-wide performance can suffer.
For Custom Load Balancing Policy:
Connections
(custom_actconn)
The active connections weight for the custom load balancing policy.
Response Time
(custom_delay)
The delay weight for the custom load balancing policy.
Health Checks
(custom_hc)
The health check weight for the custom load balancing policy.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
463
Server Pools and Server Instances
Adding and Configuring a Server Pool (GUI)
To add and configure a server pool using the GUI proceed with the following:
1. Log in to the GUI as described in "Logging In" on page 268.
2. Select the Load Balance configuration tab is it is not already selected.
3. Right click on Server Pools on the object tree and select Add Server Pool. The following will be
displayed.
4. Add a name for the server pool in the Server Pool Name field and select the load balancing
policy using the Policy drop-down list. Click on Commit to save the Server Pool. It will appear
on the Server Pool tree on the left navigational pane and the Server Pool Configuration > Settings
screen will appear on the right. Note that if you select a Custom Policy you will have the
option of configuring the Custom Load Balancing policies discussed in "Configuring Server
Pool Load-Balancing Options" on page 459.
Server pool caching is disabled, by default. When the Disable Caching check box is un-checked to
enable caching, additional parameter configuration is required. Refer to "Using the CLI and GUI to
Configure Caching" on page 487 for descriptions of the caching function and configuration.
5. Configure Server Pool parameters using the table above.
6. Click on Commit to save the configuration.
464
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding and Configuring a Server Pool (CLI)
To add and configure a server pool using the CLI proceed with the following:
1. Log in to the CLI as described in "Starting the CLI" on page 168 .
2. Enter the new server pool details in the following format at the command line to create a
server pool:
eqcli > srvpool spname req_cmds
3. Use the load balancing options as described above in "Configuring Server Pool LoadBalancing Options" on page 459 and the "Server Pool, Server Instance, and Caching
Commands" on page 239 to configure the other server pool parameters.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
465
Server Pools and Server Instances
Adding Server Instances
A server pool is a collection of server definitions, each of which has additional parameters
assigned to it in the server pool -- these additional parameters are organized by the server’s
name and are referred to as server instances.
Parameters
GUI Parameter (CLI Parameter)
Description
Disable
(disable)
If selected, this option closes connections to the server.
Initial Weight
(weight)
A number between 0 and 200 that indicates a server’s processing power
relative to the other servers in a cluster. The default is 100. A value of 0
disables the server (no traffic will be routed to the server). For information
about selecting an appropriate initial weight, refer to "Adjusting a
Server’s Initial Weight" on page 511.
Maximum Connections
(maxconn )
Sets the maximum number of permitted open connections for the server.
Once this limit is reached, no more traffic is routed to the server until the
number of open connections falls below this limit. This limit is set by
default to 0, which means that there is no maximum connections limit on
the server.
Enable the hot spare check box if you plan to use this server as a backup
server, in case the other server instances in a server pool on the cluster
fail. Checking hot spare forces Equalizer to direct incoming connections to
this server only if all the other servers in the cluster are down. You should
only configure one server in a cluster as a hot spare.
Hot Spare
(hot_spare)
For example, you might configure a server as a hot spare if you are using
licensed software on your servers and the license allows you to run the
software only on one node at a time. In this situation, you could configure
the software on two servers in the cluster and then configure one of those
servers as a hot spare. Equalizer will use the second server only if the first
goes down, enabling you to make your application available without
violating the licensing terms or having to purchase two software licenses.
Override Persistence
(persist_override)
Disables persistence for the server when the persist flag (Layer 7 cluster)
or a non-zero sticky time (Layer 4 cluster) is set on a cluster. For a Layer 7
cluster, this means that a cookie will not be inserted into the response
header when returned to the client. No sticky record is set for a Layer 4
cluster. This flag is usually used to disable persistence for a hot spare.
Quiesce
(quiesce)
When enabled, Equalizer avoids sending new requests to the server. This
is usually used in preparation for shutting down an HTTP or HTTPS server,
and is sometimes also called “server draining”. Refer to "Shutting Down
a Server Gracefully" on page 516.
466
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
This flag allows you to customize the behavior of the max connections
parameter (see above).
When Strict Max Cx is enabled (the default), the max connections
parameter is interpreted as a strict maximum and is never overridden. If a
client attempts to connect to a server that has a number of connections
equal to the max connections setting, then the connection is refused.
Strict Max Cx
(strict_maxconn)
When Strict Max Cx is disabled, the max connections setting will be
overridden in any of the following circumstances:
A client attempts to connect to a server with the hot spare
flag enabled - this allows hot spares to service more than
the max connections setting of connections.
A client attempting to connect to a Layer 7 cluster has a
persistence cookie and the server identified in the cookie
has already reached its max connections limit.
A client attempting to connect to a Layer 4 cluster has an
existing sticky persistence connection to a server and that
server has already reached its max connections limit.
Adding Server Instances(GUI)
Add server instances as follows:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Click on the arrow (u) beside Server Pools to expand the branch.
4. Click on the arrow (u) beside Servers to expand the branch.
5. Select one of the servers in the list of Servers on the tree on left navigational pane. While
holding your mouse key down, drag and drop the server into the desired server pool on the
server pool branch of the tree. The figure below will be displayed.
6. Select a Server Instance to use from the Server Instance Name drop down list.
7. Select the Initial Weight for the server instance using the slider control.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
467
Server Pools and Server Instances
8. Disable the Quiesce check box, if desired. By default, this option is enabled and causes
server pool to ignore this server for new connections. If the server is already configured
and ready to accept connections, disable this option. Otherwise, leave this option enabled
and disable it once the server is ready. Click Commit . The figure below will be displayed.
9. Configure the server instance using the parameters in the table above.
Note - For servers in Layer 7 HTTPS clusters, set the probe port to something other than 443, since Equalizer
communicates with the servers via HTTP. In many configurations, it is set to the server port. The server agent port, set
on the cluster, remains a separate port that is used only for server agent communication.)
8. Repeat step 5 to add additional server instances to a server pool.
9. Click on Commit to save the Server Pool configuration.
Adding Server Instances (CLI)
Server instance specific commands can be applied to multiple server instances by entering a
comma-separated list of server instance names on the command line. For example, to set the
weight to 125 on three server instances (sv01, sv02, sv03) in server pool sp01, you could enter a
command like this:
eqcli > srvpool sp01 si sv01,sv02,sv03 weight 125
You can also change to an aggregate context that applies to multiple server instances, that allows
you to display and modify the parameters for all the server instances. For example, you could
change to an aggregate context for the three server instances in the previous example above
using a command like the following:
eqcli > srvpool sp01 si sv01,sv02,sv03
eqcli sp-sp01-si-sv0*>
468
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
The CLI is now in the aggregate server instance context “sv01,sv02,sv03” -- only the first three
characters of which are displayed in the command line. To see the entire context name, use the
context command:
eqcli sp-sp01-si-sv0*> context
The context is “sv01,sv02,sv03”.
eqcli sp-sp01-si-sv0*>
In an aggregate server instance context, the show command will display the configuration of all
the server instances in the context.
Configure the server instance using the parameters in the table above
Note - For servers in Layer 7 HTTPS clusters, set the probe port to something other than 443, since Equalizer
communicates with the servers via HTTP. In many configurations, it is set to the server port. The server agent port, set
on the cluster, remains a separate port that is used only for server agent communication.)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
469
Server Pools and Server Instances
Server Instance Summary Screen
The Server Instance Summary Screen is displayed when a server instance is selected from the left
navigational pane. It displays server instance details such as Active Connections, Connections/second
and Transactions per second as well as server pool configuration parameters and a graphical
representation of performance history from the last 30 minutes.
470
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Associating a Server Pool with a Cluster
Server Pools can be associated with clusters using either the GUI or the CLI>
Using the GUI
To associate a server pool with a cluster proceed with the following:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Click on the arrow (u)beside Clusters to expand the branch.
4. Select a Cluster and the Configuration Required screen will be displayed.
5. Select a server pool from the Server Pool drop down list.
6. Refer to "Overview" on page 318and make any additional changes to the cluster
configuration if necessary.
7. Click on Commit to save new server pool association with the cluster.
Using the CLI
To associate a server pool with a cluster proceed with the following:
1. Access the CLI as described in "Starting the CLI" on page 168.
2. Use the following format to enter the cluster context.
eqcli> cluster clname
3. In the cluster context enter details in the following format:
eqcli cl-clname> srvpool spname
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
471
Server Pools and Server Instances
Deleting Server Pools
Server Pools can be deleted using either the GUI or the CLI.
Delete Using the GUI
Proceed with the following to remove a server pool using the GUI:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268
2. Click on the Load Balance configuration tab if it is not already selected.
3. Click on the arrow (u) beside Server Pools to expand the branch.
4. Right click on the server pool to be deleted from the Server Pool branch of the tree on the left
navigational pane and select Delete Server Pool.
5. Click on Confirm when prompted on the Delete Server Pool dialogue form.
Delete Using the CLI
Proceed with the following to remove a server pool using the CLI:
1. Access eqcli as described in "Starting the CLI" on page 168 .
2. Use the following format to enter the cluster context.
eqcli> cluster clname
3. In the cluster context enter details in the following format:
eqcli cl-clname> no
472
srvpool spname
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Pool and Server Instance Reporting
The CLI display of Statistics can be seen by entering the following within the server pool context:
Sample Server Pool or Server Instance Statistical Display
eqcli sp-srv*> stats
TOTALPRCSD
TOTALRESPPRCSD
TIMESPENT
ACTIVECONX
BYTERCVD
BYTESEND
TOTALSTKY
IDLECONXDROPED
STALECONXDROPED
FAILTHRICE
NEWFAILTHRICE
RSPPARSED
RSPFAILED
RSPFAILHDR
CLNTTO
SRVRTO
CONNTO
SELPERSIST
SPLICE
CURCLNTWAITQ
REUSEOF
REUSESRVR
REUSETO
CURCOMP
TOTALCOMP
INBYTECOMP
OUTBYTECOMP
eqcli sp-srv*>
Current
391468
562924
159054
747
1397537644
215641616
0
0
0
0
0
483043
0
0
104511
0
0
0
311587
0
0
0
0
0
0
0
0
60 sec
94
125
N/A
741
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
10 min
97
128
N/A
766
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
60 min
78
127
N/A
535
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
N/A
473
Server Pools and Server Instances
To view the GUI display:
1. Verify that you are logged into the GUI. (Refer to "Logging In" on page 268.)
2. Select the Load Balance configuration tab on the left navigational pane if it is not already
selected.
3. Click on the arrow (u) beside Server Poolsto expand the branch.
4. Select a Server Pool or Server Instance Server on the branch and click on the Reporting tab
to display statistics. The following is an example of the statistics displayed.
Sample Server Pool and Server Instance GUI Statistical Display
The following are definitions for the statistical terms shown on both the CLI and GUI:
474
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Pool Statistic Definitions
CLI Term
GUI Term
Definition
Total connections processed
Total Connections
Connections Processed.
Total response processed
Total Transactions
Responses Processed.
Total time taken for server to
respond
Total Time For Server
Responses
Total Time For Server Responses
Current Active Connections
Active Connections
Active Connections.
No of Times Server Selected By
Sticky
Total Sticky Records
Total Sticky Records.
Total New Server Selected
after 3 Retries
New Server Selected After 3
Client Tries
New Server Selected After 3 Client Tries.
Total Same Server Selected
after 3 Retries
Same Server Selected After 3
Client Tries
Same Server Selected After 3 Client Tries.
Total Connections Dropped for
Stale Timeout
Cx Dropped Due To Stale
Timeout
Connections dropped due to stale timeout.
Total Connections Dropped for
Idle Timeout
Cx Dropped Due To Idle
Timeout
Total Connections Dropped for Idle Timeout.
Number of Request Headers
Failed Parsing
Number of Request Headers
Failed Parsing
Number of Request Headers Failed Parsing.
Total Responses Failed Header
Parsing
Number of Request Headers
Failed Parsing
Number of Request Headers Failed Parsing.
Total Responses Dropped for
Exceeding Header Limit
Total Responses Dropped for
Exceeding Header Limit
Total Responses Dropped for Exceeding Header
Limit.
No of Times Server Selected By
Cookie
Server Selected By Cookie
No of Times Server Selected By Cookie.
Cx Dropped Due To Client
Timeout
Cx Dropped Due To Client
Timeout
Connections dropped due to client timeout.
Cx Dropped Due To Server
Timeout
Cx Dropped Due To Server
Timeout
Connections dropped due to server timeout
Cx Dropped Due To Connect
Timeout
Cx Dropped Due To Connect
Timeout
Connections dropped due tto connect timeout.
Current Connections in TCP
MUX Reuse Pool
Cx Dropped Due To Reuse Pool
Timeout
Connections dropped due to reuse pool timeout.
Total Client-Server
Connections Linked
Current Client Cx Waiting for
Server Cx
Total client-server connections linked
Total Connections Timed Out
in TCP MUX Reuse Pool
Cx Dropped Due To Reuse Pool
Timeout
Total connections timed out in TCP MUX reuse
pool.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
475
Server Pools and Server Instances
CLI Term
GUI Term
Definition
Total Connections Terminated
for TCP MUX Reuse Pool
Overflow
Cx Dropped Due To Reuse Pool
Overflow
Total connections timed out in TCP MUX reuse
pool.
Total Connections Closed by
Server in TCP MUX Reuse Pool
Overflow
Cx Dropped Due To Server
Closed Cx In Reuse Pool
Total connections closed by server in TCP MUX
reuse pool overflow.
Current Client Connections
Waiting for Server Connection
Current Client Cx Waiting for
Server Cx
Current client connections waiting for server
connection
Total Responses Compressed
Total Responses Compressed
Total responses compressed.
Current Responses Being
Compressed
Current Responses Being
Compressed
Current responses being compressed.
Total Plain Text Bytes Before
Compression
Input Bytes To Compress
Total plain text bytes before compression
Total Compressed Response
Bytes
Total Responses Compressed
Total responses compressed.
476
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Instance Statistic Definitions
CLI Term
GUI Term
Definition
TOTALPRCSD
Total Connections
Connections Processed.
TOTALRESPPRCSD
Total Transactions
Responses Processed.
TIMESPENT
Total Time For Server
Responses
Total time for server responses.
ACTIVECONX
Active Connections
Active Connections.
BYTERCVD
Bytes Received
Bytes received from peer.
BYTESEND
Bytes Sent
Bytes transmitted to peer.
TOTALSTKY
Total Sticky Records
Total sticky connections
IDLECONXDROPED
Cx Dropped Due To Idle
Timeout
Connections dropped for idle timeout.
STALECONXDROPED
Cx Dropped Due To Stale
Timeout
Connections dropped for stale timeout.
FAILTHRICE
Same Server Selected After 3
Client Tries
Same server selected after 3 retries.
NEWFAILTHRICE
New Server Selected After 3
Client Tries
New server selected after 3 retries.
RSPPARSED
Number of Request Headers
Parsed
Response headers parsed.
RSPFAILED
Number of Request Headers
Failed Parsing
Responses failed header parsing.
RSPFAILHDR
Total Responses Dropped for
Exceeding Header Limit
Responses dropped for exceeding header limit.
CLNTTO
Cx Dropped Due To Client
Timeout
Connections dropped due to client timeout.
SRVRTO
Cx Dropped Due To Server
Timeout
Connections dropped due to server timeout
CONNTO
Cx Dropped Due To Connect
Timeout
Connections dropped due to connect timeout.
SELPERSIST
Server Selected By Cookie
No of Times Server Selected By Cookie.
SPLICE
Total Connections
Total client-server connections linked.
CURCLNTWAITQ
Current Client Cx Waiting for
Server Cx
Client connections waiting for server connection.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
477
Server Pools and Server Instances
CLI Term
GUI Term
Definition
REUSEOF
Cx Dropped Due To Reuse Pool
Overflow
Connection dropped due to reuse pool overflow
REUSESRVR
Cx Dropped Due To Server
Closed Cx In Reuse Pool
Connection dropped due to server closed
connection in reuse pool.
REUSETO
Cx Dropped Due To Reuse Pool
Timeout
Total connections timed out in TCP MUX reuse
pool.
CURCOMP
Current Responses Being
Compressed
Current responses being compressed.
TOTALCOMP
Total Responses Compressed
Total responses compressed.
INBYTECOMP
Input Bytes To Compress
Total plain text bytes before compression.
OUTBYTECOMP
Output Bytes After
Compression
Total compressed response bytes.
The following is a graphical plot that can be displayed on the GUI. Select a server pool or server
instance on the left navigational pane and click on the Reporting tab and then Plotting. The following
will be displayed.
478
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Sample Server Pool and Server Instance Graphical Plot
The specific types of statistics that are displayed are determined by the selections on the Statistics
pane on the upper right corner of the GUI.Make selections based on the data that you require.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
479
Server Pools and Server Instances
The Plot Type selection determines whether the display shown reflects a Static Time Span which is
configured using the slider or whether a real time duration is display. If Real Time Duration is
selected the slider controls will change to Duration and Refresh controls as shown below. In this case
set the Duration of time in which you would like to review statistics and the Refresh rate desired.
480
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 14
HTTP Caching
Sections in this chapter include:
Caching Overview
HTTP Caching Functional Description
HTTP Caching Configuration Overview
Using the CLI and GUI to Configure Caching
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
482
483
485
487
481
HTTP Caching
Caching Overview
Note - HTTP Caching is not available on legacy Equalizer GX models.
HTTP caching stores content previously received from servers in a special region of memory
known as the cache. The goals of caching are:
l
to provide a better client experience when accessing a cluster
l
to reduce congestion and response times between the ADC and the servers behind it
l
to reduce overall server load
The following illustration shows the impact of caching on the flow of content between clients and
servers.
482
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
HTTP Caching Functional Description
When a server response is received by the ADC, it is evaluated to determine if it is cacheable.
Whether or not a specific response is cacheable is determined by certain attributes of the
response:
l
l
l
The status code of the response must be 200, 203, 300, 301, or 400.
The file type of the response must be configured for caching. By default all file types are
cacheable (text, graphics, videos, javascript, style sheets, etc.), but you can configure
caching to exclude specific file types.
The size of the item to be cached must not be above the configured maximum cached item
size.
Once a response has been cached, it is classified as either fresh or stale. A response is fresh if its
age hasn't exceeded the configured maximum cached item age parameter (Maximum Cached Item
Age in the GUI); otherwise, the item is considered stale. When an item in the cache becomes
stale, it means that it must be re-validated (and possibly re-fetched from the server) before it can
be returned to the client.
Cached server responses are stored in memory. You can limit the amount of memory consumed
by the cache using the CLI max_size parameter (Maximum Cached Item Size in the GUI). Once the
total amount of cache memory reaches this limit, new entries will not be created until previous
entries are deleted. Entries are chosen for deletion using the algorithm specified by the CLI
policy parameter (Replacement Policy in the GUI).
Caching and Persistence
Persistence can have a substantial impact on caching performance. This is best explained by
comparing what happens in the cache when persistence is not enabled vs. enabled.
Let’s say we have 3 servers in a cache-enabled server pool that is attached to a Layer 7 HTTP
cluster, and all 3 servers return exactly the same content:
l
l
When persistence is disabled on the cluster, then a single copy of any server response will
be cached and will be returned to a client from the cache regardless of the server to which
the client request was load balanced.
When persistence is enabled on the cluster, then a copy of each server’s response will be
cached even if the response is already cached due to another server returning that content.
In this case, since there are 3 servers in the pool, you could have as many as 3 copies of the
same content in the cache at any given time.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
483
HTTP Caching
Because of the inefficiencies related to caching static content when persistence is enabled, it is
recommended that you disable caching for static file types on server pools that are used by
clusters that have persistence enabled. This can be done in either of two ways:
l
l
Creating a match rule whose expression selects content that should not be cached, and
attaching to the match rule a server pool that has caching disabled. This would be followed
by a match rule that selects all other content and uses a server pool that has caching
enabled.
Creating a match rule whose expression selects content that should be cached, and
attaching to the match rule a server pool that has caching enabled. This would be followed
by a match rule that selects all other content and uses a server pool that has caching
disabled.
See the section "Caching Specific File Types" on page 494 for more information.
Caching and Failover
The caching configuration is synchronized across all failover peers. Cached content is not. When a
failover occurs, the peer taking over as the primary peer for a failover group will begin caching
server responses using the same settings that were used on the previous peer.
484
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
HTTP Caching Configuration Overview
As mentioned above, caching is configured on server pool objects. There is one HTTP cache
allocated in memory for every server pool on the system for which caching is enabled. Server
pools can be attached to both clusters and match rules:
l
l
l
When you attach a cache-enabled server pool to a Layer 7 HTTP or HTTPS cluster, server
responses delivered to clients through that cluster will be cached according to the caching
parameter settings on that server pool.
If a Layer 7 HTTP or HTTPS cluster has match rules, and a client request is load balanced to
a server via a match rule, then it is the server pool attached to the match rule that caches
the server responses (assuming caching is enabled on that server pool). Thus, match rules
offer the ability to fine-tune your caching configuration by caching specific types of content
in specific server pool caches.
Cache-enabled server pools can be attached at the cluster level only, at the match rule level
only, or both.
For example, the illustration below shows two clusters and their server pool/caching
configuration:
In the example above:
l
l
l
Both Cluster1 and Cluster2 have (different) server pools attached to them at the cluster level
(Server Pool 3 and Server Pool 4), and these server pools are configured with caching disabled.
Both Match Rule 1 (on Cluster1) and Match Rule 3 (on Cluster2) send client requests to servers in
Server Pool 1, and make use of its cache.
Both Match Rule 2 (on Cluster1) and Match Rule 4 (on Cluster2) send client requests to servers in
Server Pool 2, and make use of its cache.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
485
HTTP Caching
When a server response is sent to either of these clusters from the back-end servers, the
response is evaluated against the match rules as follows:
1. If the original client request matched the expression in Match Rule 1 or 3, then the response
is stored in the cache for Server Pool 1.
2. If the original client request matched the expression in Match Rule 2 or 4, then the response
is stored in the cache for Server Pool 2.
3. If the original client request did not match any of the match rule expressions above, then it
is not cached, since caching is disabled on the server pool attached to the cluster.
Cache-enabled Server Pools and TCP/UDP Clusters
As stated above, caching is only performed for Layer 7 HTTP and HTTPS clusters. Caching is not
supported for the following cluster types:
l
Layer 4 TCP
l
Layer 4 UDP
l
Layer 7 TCP
If a cache-enabled server pool is attached to any of the above clusters types, the cache is simply
ignored – that is, no server responses will be returned from the cache to the client and no server
responses will be inserted into the cache.
The same cache-enabled server pool can be used in both a cluster that supports caching and one
that does not; for example: in both a Layer 7 cluster and a Layer 4 TCP cluster. In this case, the
cache will be used for the Layer 7 cluster and ignored for the Layer 4 cluster.
486
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the CLI and GUI to Configure Caching
In the CLI, caching parameters are configured in the server pool context. In the GUI, caching
parameters are set on the Load Balance > server pool name > Configuration > Settings tab. All cachingrelated parameters are set on server pools.
While match rules are used in specific situations to determine what content is cached, there are
no caching-specific parameters set on match rule objects. It is recommended that you familiarize
yourself with server pool configuration as well as match rule configuration before you configure
caching. For more information on these topics refer to "Adding and Configuring Server Pools" on
page 463 and "Creating a New Match Rule" on page 428
In order to configure caching, you must log in as a user that has the admin flag enabled. Refer to
"User Flags" on page 1 for more information.
Caching Parameters
The table below describes the parameters used by the CLI and the GUI to configure caching on the
server pool being modified:
Caching Parameters
GUI Parameter
(CLI Parameter)
Description
Replacement Policy
(policy)
This parameter sets the replacement policy for caching. When the cache is full,
Equalizer chooses which items to discard to make room for the new ones using
this policy.
Oldest First: The oldest entry (meaning it has been in the cache the longest)
will be removed first.
Largest First: The largest item will be removed first.
(Default: Oldest First)
Maximum Cached Item Age
(age)
This parameter specifies the maximum age of a cached item (in seconds) before
it is counted as "stale".
Minimum: 0 seconds
Maximum: 86400 seconds (24 hours)
(Default: 86400 seconds (24 hours)
Maximum Cached Item Size
(max_object_size)
This parameter sets the maximum cached item size (in bytes). If a response is
larger than this value, it will not be cached.
Minimum: 0.bytes
Maximum: 10485760 bytes (10MB)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
487
HTTP Caching
Caching Parameters
GUI Parameter
(CLI Parameter)
Maximum Cache Size
(max_size)
Description
This parameter sets the maximum total size of the cache (in bytes), and is
platform-dependent (see below). Once the total cache size reaches this size,
new entries will not be created until some are deleted based on the replacement
algorithm (Replacement Policy).
Minimum: 1024 bytes
Maximum: the maximum cache size (in bytes) is platform-dependent as show
below.
(Default:See Maximum below
E370LX -- 104857600 bytes (100MB)
E470LX -- 209715200 bytes (200MB)
E670LX -- 307200 bytes (300MB)
E970LX -- 524288000 bytes (500MB)
Equalizer OnDemand-- 52428800 bytes (50MB)
Note: HTTP Caching is not available on Equalizer GX systems.
Flags
Disable
([!]disable)
488
Disables caching on the server pool. Since caching is disabled by default, you
will need to enable it on the server pool using the CLI or the GUI.
!disable enables caching on the server pool when using the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Enabling and Disabling Caching
Caching is disabled by default on all new server pools, and on all existing server pools after an
upgrade. No content will be cached for a server pool until you explicitly enable it.
To enable caching using the CLI enter:
eqcli > server pool server_pool_name cache flags !disable
where:
server_pool_name is the name of the server pool.
For example:
eqcli > srvpool srvpool1 cache flags !disable
eqcli > show srvpool srvpool1 cache
Cache is enabled.
Policy
: Oldest
Max Size
: 0
Max Object Size : 2048
Age
: 86400
Flags
:
eqcli >
To disable caching using the CLI enter:
eqcli > srvpool server_pool_name cache flags disable
where:
server_pool_name is the name of the server pool.
For example:
eqcli > srvpool srvpool1 cache flags disable
eqcli > show srvpool srvpool1 cache
Cache is disabled.
Policy
: Oldest
Max Size
: 0
Max Object Size : 2048
Age
: 86400
Flags
: disabled
eqcli >
If caching is disabled on the server pool, a Cache is disabled message will be displayed and
disabled will appear in the Flags field. If enabled, a Cache is enabled message will be
displayed and the Flags field will be empty.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
489
HTTP Caching
To enable caching using the GUI:
1. Log in to the GUI.
2. Select Load Balance > Server Pool on the left navigational pane and select the server pool on
which you want to enable caching.
3. When the Server Pool > Configuration > Required tab is displayed on the right configuration pane,
the Disable option is selected by default. Click on the checked box to remove the check and
enable caching.
4. Click on Commit to save the option on the server pool.
To disable caching using the GUI:
Since caching is disabled by default, you do not need to disabled it unless it has been enabled.
1. Log in to the GUI
2. Select Load Balance > Server Pool on the left navigational pane and select the server pool on
which you want to enable caching.
3. When the Server Pool > Configuration > Required tab is displayed on the right configuration pane,
the Disable option is selected by default. Click on the checked box to remove the check and
enable caching.
4. Click on Commit to save the option on the server pool.
All existing cached content will be flushed if you disable server pool caching.
490
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying Parameters of the Cache Attached to Server Pools
To view server pool caching parameteters in the CLI, enter:
eqcli > show srvpool server_pool_name cache
where:
server_pool_name is the name of the server pool.
An example is shown below:
eqcli > show srvpool server_pool_name cache
Cache is enabled.
Policy
: Oldest
Max Size
: 0
Max Object Size : 2048
Age
: 86400
Flags
:
eqcli >
To view server pool caching parameters in the GUI:
1. Log in to the GUI.
2. Select Load Balance > Server Pools on the left navigational pane to expand the branch and select
the server pool. The parameters will be displayed on the right configuration pane as shown
below.
Note - If caching is disabled, the Replacement Policy, Maximum Cached Item Age, Maximum Cache Size, and
Maximum Cached Item Size parameters will not be displayed.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
491
HTTP Caching
Configuring Caching Parameters
All of the caching configuration parameters have default values as shown in the section "Caching
Parameters" on page 487. Should you need to configure non-default values, you can do so using
either the CLI or the GUI as shown in the following sections.
Using the CLI
Configure caching parameters in the CLI using the following format.
eqcli >server pool server_pool_name cache parameter parameter_value
where:
parameter can be policy, age, max_object_size, or max_size.
parameter_value is the value assigned to the parameter.
For example:
eqcli >server pool srvpool1 cache policy oldest
You could also configure caching parameters in the server pool context or cache context. For
example:
eqcli sp-srv*> cache policy oldest
or
eqcli sp-srv*-cache> policy oldest
492
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the GUI
Caching parameters are configured on the server pool configuration screen on the GUI.
1. Log in to the GUI.
2. Access the Server Pool > Configuration > Settings display for the caching server pool.
3. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.
4. Click on Commit to save the parameters.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
493
HTTP Caching
Caching Specific File Types
Match rules provide finer granularity in caching content in that they provide a means of excluding
or including certain file types in the cache. For example, you may want to cache only graphical
files (e.g.,.png, .gif, ,jpg, .jpeg, .ico), video files (e.g.,.mp4, .flv, .mov, .mpeg, .swf), javascript
files, or cascading style sheets (css). Using match rules, you can customize which server content
is cached, based on your needs.
To demonstrate this feature, we'll configure an example that will tell Equalizer to cache only
graphical content with *.png, *.jpg, or *.gif file extensions. We'll configure a cluster with a match
rule that uses expressions that identify file suffixes. When a filename_suffix (string) is used in the
expression, it will evaluate to true if the string argument that you specify is a suffix of the file
name portion of the URI path- in this case *.png, *.jpg, or *.gif . The content specified by the
match rule expression will then be cached.
Using the CLI
1. Verify that caching is disabled on a server pool so that caching will not begin until you
configure a match rule. Refer to"Enabling and Disabling Caching" on page 489 for a
description of the procedure.
2. Create a match rule (using an existing cluster of your choice) and add an appropriate server
pool to it at the same time. Use the following format:
eqcli > cluster clustername match match_name.srvpool server_pool_name
For example:
eqcli > cluster cluster_http match test srvpool srvpool1
494
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
3. Display the match rule to confirm that it is disabled. We do not want this match rule to be
used until the configuration is complete.
eqcli > show cluster_http match test
Match Rule Name
: test
Next Match Rule
: none
Cluster Name
: cluster_http
Server Pool
: srvpool1
Responder
:
Cookie Path
:
Cookie Domain
:
Cookie Age
: 0
Cookie Generation
: 0
Persist Type
: coyote_cookie_2
Minimum Compression
: 1024
Compression mime_type
:
text/*:application/msword:application/postscript:
application/rtf:application/x-csh:
application/x-javascript:application/x-sh:application/
x-shar:application/xtar:
application/x-tcl:
application/xslt+xml:audio/midi:audio/32kadpcm:audio/xwav:
image/bmp:image/tiff:image/x-rgb
Flags : disable
Expression :
Config Header Edit Script :
eqcli cl-clu*-ma-test>
4. Configure a match rule expression. The expressions that you will need to configure are
filename_suffix (\".gidf\"), filename_suffix(\".jpg\"), and filename_suffix
(\".png\"). As you can see in the example below, "||" are logical "OR" operators added to
the expression. This means that the match rule will parse .gif OR .jpg OR .png files.
eqcli > cluster cluster_http match test expression filename_suffix
(\".gif\")||filename_suffix(\".jpg\")||filename_suffix(\".png\")
eqcli > commit
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
495
HTTP Caching
5. Verify that the new match rule includes the expression that you created. The expression
used in our example is highlighted below.
eqcli > show cluster_http match test
Match Rule Name
: test
Next Match Rule
: none
Cluster Name
: cluster_http
Server Pool
: srvpool1
Responder
:
Cookie Path
:
Cookie Domain
:
Cookie Age
: 0
Cookie Generation
: 0
Persist Type
: coyote_cookie_2
Minimum Compression
: 1024
Compression mime_type
:
text/*:application/msword:application/postscript:
application/rtf:application/x-csh:
application/x-javascript:application/x-sh:application/
x-shar:application/xtar:
application/x-tcl:
application/xslt+xml:audio/midi:audio/32kadpcm:audio/xwav:
image/bmp:image/tiff:image/x-rgb
Flags : disable
Expression :
filename_suffix(\".gif\") || filename_suffix(\".jpg\") || filename_suffix
(\".png\")
Config Header Edit Script :
eqcli cl-clu*-ma-test>
6. Enable caching on the server pool. For example:
eqcli > srvpool srvool1 cache !disable
eqcli > show srvpool srvpool1 cache
Cache is enabled.
Policy
: Oldest
Max Size
: 3000
Max Object Size : 2048
Age
: 86400
Flags
:
eqcli >
7. Enable the match rule.
eqcli cl-clu*-ma-test> flags enable
eqcli cl-clu*-ma-test> flags commit
496
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Using the GUI
1. Log in to the GUI.
2. Verify that caching is disabled on the caching server pool so that caching will not begin until
you configure a match rule. Refer to "Enabling and Disabling Caching" on page 489 for a
description of the procedure.
3. Select the HTTP cluster to which the caching server pool is attached. Right click on it and
select Add Match Rule.
4. Enter a Match Rule Name and click on Commit . The new match rule will be displayed on the
cluster branch on the left navigational pane and the match rule Configuration > Required screen
will appear on the right.
5. Verify that the Disable option is enabled for the match rule. We don’t want this match rule to
be used until the configuration is complete.
6. Select the caching server pool from the Server Pool drop down list. If you do not select the
caching server pool, the match rule will not be used for caching.
7. Click on the Expression Editor button to display the Match Rule Expression Editor. Drag the any()
button to the trash can icon below.
8. Select filename_suffix from the URI functions on the right and drag it to the Expression
Workbench. Click on the filename_suffix button on the Workbench and add ".gif" in the space
provided.
9. Drag the || button from the Operators pane above the Expression Workbench to the space after
your first filename_suffix(".gif") expression. This is a logical "OR" operator.This is added to the
expression so that the match rule will parse .gif OR .jpg OR .png files.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
497
HTTP Caching
10. Repeat steps 8 and 9, for both .jpg and .png file suffixes. When complete, your expression
should be as follows:
11. Click on Continue to return to the match rule Configuration > Required screen.
12. Click on Commit to save the match rule.
13. Verify that caching is enabled on the caching server pool used by the match rule. Select Load
Balance > Server Pools > server pool name > Configuration tab. Verify that Disable Caching is NOT
checked in the caching group.
14. Enable the Match Rule. Select Load Balance > Clusters > cluster name > match rule name on the left
navigational pane to display the match rule Configuration tab. Uncheck the Disable option.
498
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Testing the Caching Configuration
Test the match rule and caching configuration above by sending traffic through a cluster. Using
the statistics displays in the GUI and CLI, (See "Show Caching Statistics" on page 501) verify that,
for example, retrieving a graphical file increases the relevant counters and a .txt file does not.
1. Verify that there are ".txt", ".gif", ".gif", and ".jpg" files on a server. For this example, we
will retrieve "Test.jpg" and "Test.txt" from a server.
2. Add the server to the configuration on the Server branch on the left navigational pane.on the
GUI. (Refer to "Adding and Modifying Servers" on page 506.)
3. Add the server instance to the caching server pool.and enable caching. (Refer to "Enabling
and Disabling Caching" on page 489
4. Select the cluster from the left navigational pane and verify that the caching server pool is
selected from the Server Pool drop down list.
5. View and make note of your current caching statistics. Select the caching server pool from
the left navigational pane and click on the Reporting tab on the right. Make a note of the
current Number Entries, Total hits, and Total misses statistics.
6. Open a new browser window, enter http:/ /cluster_ip_address/Test.txt in your browser's address
bar and ENTER.
7. Select Load Balance > Server Pools > server pool name on the GUI left navigational pane.
8. Select the Reporting tab on the right configuration pane and note the Server Pool Caching
Statistics. When you entered the "Test.txt", Equalizer made the request to the server. Since
the match rule in the configuration specifies that you want to cache ".jpg", ".png", or ".gif"
files only, the .txt file was not cached and the Number entries or Total hits caching statistics did
not increase from the values that you noted from step 5. Also, the Total misses statistic
should increase as the "Test.txt" file did not meet the match rule stipulations for caching.
9. Open a new browser window, enter http:/ /cluster_ip_address/Test.jpg in your browser's address
bar and ENTER.
10. Select Load Balance > Server Pools > server pool name on the GUI left navigational pane.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
499
HTTP Caching
11. Select the Reporting tab on the right configuration pane and note the Server Pool Caching
Statistics. When you entered "Test.jpg" on your browser's address bar, Equalizer made the
request to the server. Since the match rule in the configuration specifies that you want to
cache only .jpg, .png, or .gif graphical files, "Test.jpg" was cached and the Number entries or
Total hits caching statistics increased.
l
l
If an item was not previously cached, the Number entries statistic will increase.
If an item was previously cached, the Number entries statistic will remain the same,
however, the Total hits statistic will increase as the request matched a cached entry in
the ADC.
Each time that you attempt to retrieve "Test.jpg" the Number entries caching statistic
will remain the same and the Total hits statistic will increase. An example is shown
below. Refer to "Show Caching Statistics" on the facing page for descriptions of the
statistics.
500
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Show Caching Statistics
The caching statistics displayed for a server pool represent all requests that have been
received/responded since the cache was instantiated, either when it was configured or the system
started up or rebooted. These statistics are not saved between system reboots.
Statistic
Description
Total bytes
The total number of bytes of response data stored in the cache. Does not include
request header size.
The total number of entries currently cached. It is possible that some entries may
not be usable if they are:
incomplete - the ADC started creating an entry but never finished, possibly
because the server didn’t respond
Number entries
invalid - data exists for the entry, however the headers disallow the entry from
being returned without revalidation
deleting - an entry may be in the process of being deleted, but hasn’t been as
yet
Total hits
A cache hit is recorded when cached data can be returned to the client.
Total misses
The total number of unsuccessful cache requests since start of cache service.
Total hits revalidated
A cached entry was found, however, was not fresh - we had to check with the
server to revalidate.
Total revalidated 304 responses
The total number of times that a server responded with a 304 response. A
returned 304 status code means the content is still fresh.
Total missed due to incomplete
The total number of times that a cached entry was found, however, it was not
complete so it could not be used.
Total missed due to revalidating
The total number of times that a cached entry was found, however, it was in the
process of being revalidated for another client and could not be used.
Total missed due to dying
The total number of times that a cached entry was found, however,it was in the
process of being removed and could not be used.
Total missed due to busy
The total number of times that a cached entry was found, however, could not be
used because the system was too busy to return it.
Total entries evicted
The number of cached items that have been evicted from the cache in order to
make room for newer cached items.
Total entries deleted because
none left to evict
When an entry is evicted because the cache is out of space, it is marked for
deletion - but doesn’t actually get deleted until the system has time to do so. If
every entry has been marked for deletion, but the cache is still full, there will be
no room to create more entries.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
501
HTTP Caching
To display caching statistics for an enabled server pool using the CLI enter:
eqcli > server pool serverpoolname cache stats
where:
serverpoolname is the name of the server pool.
The following is an example of the display.
eqcli > srvpool srvpool1 cache stats
Statistics
Total bytes
Number entries
Total hits
Total misses
Total hits revalidated
Total revalidated 304 responses
Total missed due to incomplete
Total missed due to revalidating
Total missed due to dying
Total missed due to busy
Total entries evicted
Total entries deleted because none left to evict
eqcli >
:
:
:
:
:
:
:
:
:
:
:
:
Value
35566
42
87
33
2
2
2
4
0
1
7
4
To display the caching statistics for an enabled server pool using the GUI:
1. Log in to the GUI.
2. Select Load Balance > Server Pool from the left navigational pane.
3. Select the server pool and then select Reporting > Statistics on the right configuration pane.
The following will be displayed on the right side of the display.
502
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 15
Managing Servers
Sections within this chapter include:
Server Summary
Adding and Modifying Servers
Server Software Configuration
Adjusting a Server’s Initial Weight
Interaction of Server Options and Connection Processing
Server Configuration Constraints
Configuring Routing on Servers
Server Statistics and Reporting
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
504
506
510
511
515
517
518
520
503
Managing Servers
Server Summary
A summary of the servers configured on your Equalizer be viewed using either the GUI or the CLI.
Server Summary Using the GUI
The Server Summary screen displays the names of configured servers, IP address, Ports, Protocol, VID
, and associated Server Pools.
1. Log in to the GUI.
2. Select the Load Balance > Servers to display the Server Summary screen.
+
From this screen you can add a new server by clicking on " " .
You can delete a server by selecting a server and clicking on
.
You can modify server configuration by selecting a server and clicking on
and Modifying Servers" on page 506
504
. Refer to "Adding
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Summary Using the CLI
The server summary shown below displays a summary listing of all of the servers, protocol, IP
addresses, ports, and any options (flags) configured on your Equalizer.
Enter the following:
eqcli > show server
Name
Protocol IP Address Port Flags
srv1
tcp
2.4.6.8
80
srvudp
udp
3.6.9.12
80
servertcp
tcp
2.5.7.9
80
testing123 tcp
6.7.8.9
80
12000003: You have 1 pending alert notification.
eqcli >
To display the summary for a specific server use the format: eqcli > show server server_
name, where server_name is the name of the server that you want to view. For example:
eqcli > show server srv1
This server is enabled.
Server Name
IP Address
Port
Protocol
VID
Max Reuse Connections
Reuse Connections Timeout
VLB Manager
UUID
eqcli >
:
:
:
:
:
:
:
:
:
srv1
2.4.6.8
80
tcp
2
0
0
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
505
Managing Servers
Adding and Modifying Servers
Servers can be added and modified using either the GUI or the CLI.
Parameters
The table below shows the parameters, values, and flags used in the configuration Servers.
GUI Parameter (CLI Parameter)
Description
IP
(ip)
The dotted decimal IP address of the server. This is the address Equalizer
uses to communicate with the server.
Enter the numeric port number on the Equalizer to be used for traffic
between Equalizer and the server. The default is port 80. (Note that in Layer
7 HTTPS clusters, the server port should be set to something other than 443
since Equalizer communicates with servers in an HTTPS cluster via HTTP.)
Port
(port)
For L4 UDP and L4 TCP protocol clusters, a cluster port range can be
defined. These are the ports on the Equalizer to be used to send traffic to the
server pool in the cluster. Port ranges allow Equalizer users to create a
single cluster to control the traffic for multiple, contiguous ports. The Port
defined for a server in the cluster for which a port range is defined indicates
the port on the server that starts the range of ports to be opened.
By default, the Maximum Reused Connections server option is set to 0,
which means that Equalizer will route traffic to the server whenever the
server is selected by the current load balancing settings. If Maximum
Reused Connections is set to a value greater than 0, then Equalizer limits
the total number of simultaneously open connections to the server to that
value. This restriction applies regardless of the persistence options set on
the cluster.
Maximum Reused Connections
(max_reuse_conn)
When a server reaches the specified limit, requests will not be routed to that
server until the number of active connections falls below the limit.Typical
reasons to set a maximum number of connections include:
•Implementing a connection limit that is required due to software
limitations, such as an application that can service a limited number of
concurrent requests.
•Implementing license restrictions that are not enforced by software;
such as limiting the number of active connections to an application that
is licensed for a limited number of concurrent connections.
•Setting a threshold that will limit resource utilization on the server.
Reused Connection Timeout
(reuse_conn_to)
506
The number of seconds after which a connection record for an idle server
connection in the reusable connection pool is removed, and the connection
closed. The default value is 0 seconds, which means that records in the
reusable connections pool never expire.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding and Modifying Servers Using the GUI
Adding Servers
Perform this procedure once for each real server that you want to add to Equalizer.
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Right-click on Servers and select Add Server. This will open the Add Server dialogue as follows:
4. Select UDP or TCP from the drop down list and enter a descriptive Server Name.
5. Enter an IP address for the server.
6. Enter a Port for the server. For HTTP, this is typically port 80. For HTTPS, port 443. For
generic TCP and UDP services, use the port appropriate for that service. Whatever port you
enter, it must match the port set on the real server.
7. Click on Commit to confirm the values you selected. You will be taken to the Server
Configuration tab and the new server will appear on the Server branch on the left
navigational pane. The server I P address and Port will be visible in the Server Configuration
screen.
Modifying Servers
The configuration tabs for a server are displayed automatically when a server is added to the
system, or by selecting the server name from the left navigational pane.
1. Log into the GUI using a log in that has at least write access for the cluster that contains the
server.
2. In the left navigational pane, select the Load Balance > Servers > Server Name > Configuration >
Settings to display the following.
Note - For servers in Layer 7 HTTPS clusters, set Port to something other than 443, since Equalizer communicates
with the servers via HTTP. In many configurations, it is set to the server Port.
Clicking on the Reset button will remove anything that you've entered and return the screen to the
default display. If you made any changes to the default configuration values, click on the Commit
button to save your changes.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
507
Managing Servers
Adding and Modifying Servers using the CLI
Adding Servers
Perform this procedure once for each real server that you want to add to Equalizer.
Enter the following:
eqcli > server [server name] proto tcp ip xxx.xxx.x.x port xx
where:
proto - is the server protocol
ip - is the dotted decimal IP address of the server. This is the address Equalizer
uses to communicate with the server.
port - is the numeric port number on the Equalizer to be used for traffic between
Equalizer and the server. The default is port 80. (Note that in Layer 7 HTTPS clusters,
the server port should be set to something other than 443 since Equalizer
communicates with servers in an HTTPS cluster via HTTP.) For L4 UDP and L4 TCP
protocol clusters, a cluster port range can be defined. These are the ports on the
Equalizer to be used to send traffic to the server pool in the cluster. Port ranges allow
Equalizer users to create a single cluster to control the traffic for multiple, contiguous
ports. The Port defined for a server in the cluster for which a port range is defined
indicates the port on the server that starts the range of ports to be opened.
Note - For servers in Layer 7 HTTPS clusters, set Port to something other than 443, since Equalizer communicates
with the servers via HTTP. In many configurations, it is set to the server Port.
The server agent port, set on the cluster, remains a separate port that is used only for server agent communication.)
508
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Modifying Servers
Servers can be configured in the CLI either globally or in cluster context. Enter parameters using
the following format. eqcli > server servername parameter value
where:
servername - is the name of the server
parameter - is the parameter to be configured
value - is the value associated with the parameter.
For example:
eqcli > server srv1 max_reuse_conn 5
Refer to "Parameters" on page 506 above for details about server parameters.
Refer to "Server Commands" on page 238 for additional information on using server commands in
the CLI.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
509
Managing Servers
Server Software Configuration
Please observe the following guidelines and restrictions when configuring the software on your
servers:
Spoof
If the spoof flag is turned on for a cluster (the default), you should configure your network
topology so that Equalizer is the gateway for all traffic for its virtual clusters. In most cases, this
means that each server in a cluster should be configured to use Equalizer as its default gateway,
so that all packets that come through Equalizer from clients will pass back through Equalizer and
then to the clients.
You do not need to configure Equalizer as the gateway for the servers if you have disabled the IP
spoof flag for the cluster.
Header Limit
Server responses (and client requests) must contain 64 or fewer headers; any packet that
contains more than 64 headers is dropped by Equalizer (along with the connection), and a
message like the following is printed to Equalizer’s event log:
Warning: Dropping connection from ip-address -- too many headers
Make sure that your server software is configured to return 64 headers or less in any response it
sends back through Equalizer. Be aware, however, that this has no effect on the client side; any
packets from the client with more than 64 headers will still be dropped by Equalizer (and a
warning appended to the event log). In most cases, client requests do not include that many
headers.
510
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adjusting a Server’s Initial Weight
Equalizer uses a server’s initial weight as the starting point for determining the percentage of
requests to route to that server. As Equalizer gathers information about the actual performance of
a server against client requests, it adjusts the server’s current weight so that servers that are
performing well receive a higher percentage of the cluster load than servers that are performing
at a slower rate.
When you install servers, set each server's initial weight value in proportion to its “horsepower.”
All the initial weights in a cluster do not need to add up to any particular number; it’s the ratio of
the assigned server weight for a server to the total of all the server weights that determines the
amount of traffic sent to a server.
For example, you might assign a server with 4 dual-core 64-bit processors operating at 3.40GHz a
value of 100 and a server with 2 dual-core 64-bit processors operating at 1.86GHz a value of 50.
The first server will initially receive approximately 66% (100 divided by 150) of the traffic. The
second server will initially get about 33% (50 divided by 150) of the traffic. It’s important to note
that setting the initial weights of these servers to 100 and 50 is equivalent to setting the initial
weights to 180 and 90.
Values for server weights can be in the range 0-200, with 0 meaning that no new requests will be
routed to the server, essentially disabling the server for subsequent requests. In general, you
should use higher initial weights. When the load balancing policy is not set to round robin or static
weight, using higher initial weights will produce finer-grained load balancing. Higher weights
enable Equalizer to adjust server weights more gradually; increasing the weight by 1 produces a
smaller change if the starting weight is 100 than it does if the starting weight is 50.
However you set the initial weights, Equalizer will adjust the weight of servers dynamically as
traffic goes through the cluster. Dynamic server weights might vary from 50-150% of the
statically assigned values. To optimize cluster performance, you might need to adjust the initial
weights of the server instance in a server pool based on their performance.
Note - Equalizer stops dynamically adjusting server weights if the load on the cluster drops below a certain threshold.
For example, if web traffic slows significantly at 4:00 AM PST, Equalizer will not modify server weights until traffic
increases again. Because a server’s performance characteristics can be very different under low and high loads,
Equalizer optimizes only for the high-load case. Keep this in mind when you configure new Equalizer installations; to
test Equalizer’s ALB performance, you’ll need to simulate expected loads.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
511
Managing Servers
Setting Initial Weights for Homogenous Clusters
If all the servers in a cluster have the same hardware and software configurations, you should set
their initial weights to the same value initially. We recommend that you use a initial weight of 100
and set the load-balancing response parameter to medium.
As with any new configuration, you will need to monitor the performance of the servers under
load for two to three hours. If you observe that the servers differ in the load they can handle,
adjust their initial weights accordingly and again monitor their performance. You should adjust
server weights by small increments; for example, you might set the initial weight of one server to
110 and the other to 90. Fine-tuning server weights to match each server’s actual capability can
easily improve your cluster’s response time by 5 to 10%.
Note - A change to a server’s initial weight is reflected in cluster performance only after Equalizer has load balanced a
significant number of new client requests for up to 30 minutes against the cluster in which the servers reside. When
testing initial weights, it is most useful to use a load-generating tool to run typical client requests against the cluster to
determine appropriate server initial weights.
512
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Maximum Connections Limits, Responders, and Hot Spares
When a maximum connections limit is set on all the servers in a cluster, it is often desirable to
define either a responder or a hot spare server for the cluster, so that any attempted connections
to the cluster that occur after the Maximum Reused Connections limit has been reached are directed to
the responder or hot spare instead of being refused or sent to the server anyway because of a
persistent connection.
In general, a Responder is easier to configure than setting up a separate server as a hot spare,
since the responder runs on Equalizer. However, while Responders are capable of returning only a
single HTML page, a hot spare can be configured to return multiple HTML pages and images. See
"Adding a Responder" on page 616for information on configuring a responder.
To use a hot spare, you would usually configure it on Equalizer as follows:
1. Set Maximum Reused Connections to zero (0), so that all connection requests sent to the hot
spare are accepted.
2. Enable the Hot Spare flag. This specifies that any requests refused by all the other server
instances in a server pool because they reached their Maximum Reused Connections limit (or
are down) will be forwarded to the hot spare server.
3. Enable the Dont Persist flag so that connections made to the hot spare don’t persist. Each
connection to the cluster must first be load balanced amongst the other servers in the
cluster and only go to the hot spare if all the other servers have reached their Maximum
Reused Connections limit.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
513
Managing Servers
Setting Initial Weights for Mixed Clusters
Equalizer enables you to build heterogeneous clusters using servers of widely varying capabilities.
Adjust for the differences by assigning initial weights that correspond to the relative capabilities
of the available servers. This enables you to get the most out of existing hardware, so you can use
an older server side-by-side with a new one.
After you assign relative initial weights, monitor cluster performance for two to three hours under
load. You will probably fine-tune the weights and optimize performance of your cluster two or
three times.
Continue monitoring the performance of your cluster and servers and watch for any trends. For
example, if you notice that Equalizer always adjusts the dynamic weights so that the weight of
one server is far below 100 and the weight of another is far above 100, the server whose dynamic
weight is consistently being reduced might have a problem.
514
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Interaction of Server Options and Connection
Processing
Server option settings have a direct influence on connection and request processing, particularly
Layer 4 and Layer 7 persistence. (Note that persistence is set at the cluster level, but can be
disabled for individual servers using the Dont Persist option.) The hierarchy of server option
settings is shown in the table below:
Server Option
Description
Server disabled
An initial weight of 0 tells Equalizer that no traffic should be sent to the server,
disabling the server. This option setting takes precedence over all other options
(including persistence, hot spare, etc.).
Max Connections (> 0)
If set to a non-zero value, Equalizer limits the total number of simultaneously
open connections to the server to that value. This limit is not overridden if the
Hot Spare option is enabled on a server, and is not overridden by a Layer 4
sticky record or Layer 7 persistence cookie for the server in an incoming request.
Quiesce Enabled
The server is not included in load balancing decisions, so that no new
connections will be made to this server. If a request in an incoming connection
has an existing Layer 4 sticky record or Layer 7 cookie for a server, however, the
request will be sent to that server even when Quiesce is enabled.
If dont persist is also enabled on the server, the sticky record or cookie is
ignored.
Hot Spare Enabled
The server is not included in load balancing decisions, so that traffic is sent to
this server only when no other server in the cluster is available to accept client
connections. If a request in an incoming connection has an existing Layer 4
sticky record or Layer 7 cookie for a server, however, the request will be sent to
that server even when hot spare is enabled.
If dont persist is also enabled on the server, the sticky record or cookie is
ignored.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
515
Managing Servers
Shutting Down a Server Gracefully
To avoid interrupting user sessions, make sure that a server to be shut down or deleted from a
cluster no longer has any active connections. When a server’s initial weight is zero, Equalizer will
not send new requests to that server. Connections that are already established continue to exist
until the client and server application end them or they time out because they are idle.
To shut down servers in a generic TCP or UDP (L4) cluster, you can set the server’s weight to zero
and wait for the existing connections to terminate. However, you need to quiesce servers in HTTP
and HTTPS (L7) clusters to enable servers to finish processing requests for clients that have a
persistent session with the server.
When you quiesce a server, Equalizer does not route new connections from new clients to the
server, but will still send requests from clients with a persistent session to the quiescing server.
Once all the persistent sessions on the server have expired, you can set the server’s initial weight
to zero; then Equalizer will not send additional requests to the server.
Note that while a server instance is quiescing, it will still receive new requests if all of the other
server instances in a server pool are unavailable. This behavior prevents any new requests from
being refused, but may lengthen the time needed to terminate all active persistent connections.
516
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Configuration Constraints
When configuring servers on Equalizer, you must observe the following constraints:
l
l
l
In general, there must be no Layer 3 devices (e.g., such as a router) between a server and
Equalizer in order for health check probes to work correctly.
Equalizer operation depends on reliable communication between Equalizer and the servers
behind it. The latency introduced by Layer 3 devices such as routers can, for example,
result in connection time-outs even when the server is available.
If you require remote servers in your clusters, you must be very careful to configure
network routes that allow Equalizer and the server to communicate. It may also be
necessary to reconfigure probe time-outs in order to account for network latency.
An example of a configuration with both directly connected servers and remotely accessible
servers is illustrated in the diagram below.
The configuration shown above is an example of a single VLAN configuration, where Equalizer
communicates with all servers and clients via the same subnet. The example cluster shown above
contains three servers, two on the local 10.0.0.0 subnet, and one on another subnet.
In this example, a static route would be needed on Equalizer to forward all packets for the
172.16.0.0 network to the gateway at 10.0.0.172. Similarly, the server at 172.16.0.33 would need
a static route that forwards all traffic for the 10.0.0.0 network through 172.16.0.10, the gateway
address for the 10.0.0.0 network.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
517
Managing Servers
Configuring Routing on Servers
The way you configure routing on servers behind Equalizer depends largely on whether Equalizer’s
spoof option is enabled on a cluster.
Spoof Controls SNAT
If spoof is disabled, SNAT (Source Network Address Translation) is performed on client requests
before sending them on to the server -- the source address used in the packet sent to the server is
Equalizer’s IP address on the VLAN used to communicate with the server.
If spoof is enabled, SNAT is not performed on client requests before sending them on to the server
-- the source address used in the packet sent to the server is the client’s IP address.
How Spoof Influences Routing
When spoof is disabled, special routing is usually not required on servers, since they will respond
to Equalizer’s IP address on the appropriate VLAN.
When spoof is enabled, you should configure your servers so that Equalizer gateways the packets
the servers send to clients. If you do not adjust the routing on your servers when the spoof option
is enabled, servers will not route responses through Equalizer and clients receiving such
responses directly from servers will drop the responses and the client connection will time out. An
easy way to do this is to configure the server's default gateway to be an address on an Equalizer
subnet. If this is not possible, then static routes should be used to properly route client requests
back to Equalizer.
Direct Server Return (DSR) configurations with Layer 4 clusters are an exception to this rule. In
DSR configurations, client requests coming through Equalizer are routed to servers, which then
respond directly back to the clients without going through Equalizer. Therefore, servers in a DSR
configuration typically have a default gateway other than Equalizer.
In non-DSR clusters with spoof enabled, you should use one of the following Equalizer addresses
as the default gateway on the server (for the server instance on the server pool in the cluster):
l
l
If the servers are connected to a single (standalone) Equalizer, the default
gateway IP address that you should use on the server is Equalizer’s IP address on the VLAN
associated with the Equalizer front-panel port to which the server is connected.
If the servers are connected to two Equalizers in a failover configuration, the
default gateway IP address that you should use on the server is always Equalizer’s failover
IP address on the VLAN associated with the Equalizer front-panel port to which the server is
connected.
The commands or utilities that you use to configure routing on a server depends on the server’s
operating system, but usually involves some form of the route command. Check your server
operating system documentation. To verify that you have configured a server’s routing correctly,
trace the route from the server to a destination address outside the internal network to ensure
that Equalizer gets used as a gateway. On UNIX systems, use the traceroute utility; on Windows,
use tracert.
518
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Note that you should configure routing on each server from the server’s system console, not
through a telnet session. This will avoid any disconnects that might otherwise occur as you adjust
the network settings on the server.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
519
Managing Servers
Server Statistics and Reporting
The CLI display of Statistics can be seen by entering the following within the server context:
Sample Server Statistics Display (CLI)
eqcli sv-spi*> stats
TOTALPRCSD
TOTALRESPPRCSD
TIMESPENT
ACTIVECONX
BYTERCVD
BYTESEND
TOTALSTKY
CURRSTKY
IDLECONXDROPED
STALECONXDROPED
FAILTHRICE
NEWFAILTHRICE
RSPPARSED
RSPFAILED
RSPFAILHDR
CLNTTO
SRVRTO
CONNTO
SELPERSIST
SPLICE
CURSRVERUSE
CURCLNTWAITQ
REUSEOF
REUSESRVR
REUSETO
CURCOMP
TOTALCOMP
eqcli sv-spi*>
520
Current
133250
281157
146728992
0
4251815936
72129144
0
0
0
0
0
0
281157
0
0
734
41182
63477
0
69772
0
0
0
0
0
0
0
60 sec
0
0
N/A
0
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
0
N/A
N/A
N/A
0
N/A
10 min
0
0
N/A
0
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
0
N/A
N/A
N/A
0
N/A
60 min
0
0
N/A
0
N/A
N/A
N/A
0
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
0
N/A
N/A
N/A
0
N/A
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
To view the GUI display:
1. Verify that you are logged into the GUI. (Refer to "Logging In" on page 268.)
2. Select the Load Balance configuration tab on the left navigational pane if it is not already
selected.
3. Click on the arrow (u) beside Serversto expand the branch.
4. Select a Server and click on the Reporting tab to display statistics. The following is an
example of the statistics displayed.
Sample Server Statistics GUI Display (GUI)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
521
Managing Servers
Server Statistic Definitions
CLI Term
GUI Term
Definition
TOTALPRCSD
N/A
Connections processed.
TOTALRESPPRCSD
Total Transactions
Responses processed.
TIMESPENT
Total Time For Server Responses
The total time spent on this object.
ACTIVECONX
Active Connections
Active connections.
BYTERCVD
Bytes Received
Bytes received.
BYTESEND
Bytes Sent
Bytes transmitted.
TOTALSTKY
Total Sticky Records
Total sticky connections.
CURRSTKY
Current Sticky Records
Current sticky records.
IDLECONXDROPED
Cx Dropped Due To Idle Timeout
Connections dropped for idle timeout.
STALECONXDROPED
Cx Dropped Due To Stale Timeout
Connections dropped for stale timeout.
FAILTHRICE
Same Server Selected After 3
Client Tries
Same server selected after 3 retries.
NEWFAILTHRICE
New Server Selected After 3
Client Tries
New server selected after 3 retries.
RSPPARSED
Number of Request Headers
Parsed
Response headers parsed.
RSPFAILED
Number of Request Headers
Failed Parsing
Responses failed header parsing.
RSPFAILHDR
Total Responses Dropped for
Exceeding Header Limit
Responses dropped for exceeding the header limit.
CLNTTO
Cx Dropped Due To Client
Timeout
Connections dropped due to client timeout.
SRVRTO
Cx Dropped Due To Server
Timeout
Connections dropped due to server timeout.
CONNTO
Cx Dropped Due To Connect
Timeout
Connections dropped due to connect timeout.
SELPERSIST
Cx Dropped Due To Reuse Pool
Timeout
The number of times the server was selected by a
cookie.
SPLICE
Server Selected By Cookie
The total number of client-server connections linked.
CURSRVERUSE
Server Cx In Reuse Pool
The number of connections in the TCP MUX reuse pool.
522
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
CLI Term
GUI Term
Definition
CURCLNTWAITQ
Client Cx In Wait Queue
The number of client connections in the wait queue.
REUSEOF
Cx Dropped Due To Reuse Pool
Overflow
The number of connections dropped due to reuse pool
overflow.
REUSESRVR
Cx Dropped Due To Server Closed
Cx In Reuse Pool
The number of connections dropped due to server
closing a connection in the reuse pool.
REUSETO
Current Client Cx Waiting for
Server Cx
Total connections timed out in TCP MUX reuse pool.
CURCOMP
Current Responses Being
Compressed
Current responses being compressed.
TOTALCOMP
Total Responses Compressed
Total responses compressed.
N/A
Input Bytes To Compress
Input Bytes To Compress
N/A
Output Bytes After Compression
Output Bytes After Compression
The following is a graphical plot that can be displayed on the GUI. Select a server on the left
navigational pane and click on the Reporting tab and then Plotting. The following will be displayed:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
523
Managing Servers
Sample Server Plot
The specific types of statistics that are displayed are determined by the selections on the Statistics
pane on the upper right corner of the GUI.Make selections based on the data that you require.
The Plot Type selection determines whether the display shown reflects a Static Time Span which is
configured using the slider or whether a real time duration is display. If Real Time Duration is
selected the slider controls will change to Duration and Refresh controls as shown below. In this case
set the Duration of time in which you would like to review statistics and the Refresh rate desired.
524
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 16
Health Checks
Sections within this chapter include:
Overview of Health Checks
Key Terms
Health Check Constraints
Health Check Probing Ports
System Health Checks
Firmware Upgrade Notes
Health Check Configuration Process
Configuring ICMP Health Checks
Configuring TCP & UDP Health Checks
Configuring ACV Health Checks
Configuring HTTP and HTTPS Application Health Checks
Configuring VLB Health Checks
Configuring Server Agent Health Checks
Attaching Health Checks to Load Balancing Objects
Attached ACV and TCP Health Checks and the Test Function
Displaying Configured Health Checks
Disabling Health Checks
Deleting Health Checks
Probe Coalescing
Health Check Timeouts
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
526
529
530
530
531
532
534
535
539
544
554
573
584
591
595
597
602
605
607
609
525
Health Checks
Overview of Health Checks
Health Checks are a series of timed probes sent by Equalizer to connected objects. The probe
responses influence load balancing decisions and determine the pool of possible load balancing
targets. The responses can be in either of two forms: they can simply let Equalizer know whether
a server is UP or DOWN. These are called liveness checks. They can also be in the form of a
returned load value from a server agent or VMware's status reporting. These are called load
checks.
Liveness checks are health checks that can be attached to servers, server pools, server instances,
and Link Load Balancing (LLB) Gateways. If, based on attached liveness checks, an object is
determined to be DOWN, it is removed from the pool of possible load balancing targets.
Load checks evaluate returned probing results to determine load on a server instance. Using
server instance delay, active connections, individual load check loads, and server pool average
load check loads, a single load value is produced for each server instance. This load value is then
utilized to influence load balancing decisions.
Health checks are configurable load balancing objects on Equalizer. Each health check features its
own set of options, parameters, and timers that are used in the probing process. After
configuration, the health checks are used by "attaching" them to servers, server pools, server
instances, or LLB gateways. When attached, the configured health checks will probe the target
objects (to which they are attached) using the configured parameters and timers.
When the health checks are attached to objects they are enabled by default, and can be disabled if
necessary.
Health checks are configured using various protocols. The following are the health checks
supported by Equalizer:
Layer 3 ICMP Health Checks
Layer 3 ICMP health checks are liveness checks that involve a "ping" to the server IP address to
determine whether or not the host is UP.
Layer 4 TCP/UDP Health Checks
Layer 4 TCP/UDP health checks are liveness checks. At Layer 4, Equalizer attempts to connect to a
specific TCP or UDP port. A TCP SYN request to port 80, for example, would be sent and checks for
a TCP SYN ACK in return. If the response is not received within the configured timeout intervals,
port 80 would be marked DOWN for that server.
Active Content Verification (ACV) Health Checks
ACV health checks are liveness checks. They are a mechanism for checking the validity of
servers, server pools, and server instances. When you attach an ACV health check to an object,
Equalizer requests data from the object and verifies that the returned data contains a character
string that indicates that the data is valid. You can use ACV with most network services that
support a text-based request/response protocol, such as HTTP. They occur as part of a TCP
handshake; this means that an ACV health check can only be attached to an object that supports
TCP connections. For example: you can attach an ACV health check to a TCP type server, but not
to a UDP type server.
HTTP and HTTPS Health Checks
526
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
HTTP and HTTPS health checks are liveness checks. They are a mechanism for checking the
validity of servers, server pools, and server instances. When you attach an HTTP or HTTP health
check to an object, Equalizer requests header data from the object and verifies that the returned
header data contains an expected status code and optional expected header strings that indicates
that the data is valid.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
527
Health Checks
Server Agent Health Checks
Server Agent health checks are load checks. In Server Agent health checking, the load on a target
is measured by a user-supplied "agent", running on the target server. The server responds to
health check queries with load "values", describing its current level of load. Since the "agent" runs
on the target, it has access to a wealth of information used to determine the system's load, thus
providing an accurate picture of the target's load.
VLB Health Checks
VLB health checks are load checks. They are used when you have one or more VMware ESX
Servers. You can configure health checks to use VMware’s status reporting to determine server,
and server instance status.
About this Chapter
This chapter features:
l
l
Definitions of key terms used throughout the chapter.
l
Health check constraints.
l
Ports used for health check probes.
l
How health checks are displayed in both the CLI and the GUI.
l
A discussion of the System Health Checks.
l
Firmware upgrade notes.
l
l
528
A discussion on the different types of health checks and how they are used in load balancing
decisions.
Instructions for creating health checks, attaching them to the load balancing objects,
disabling , deleting, and configuring them.
A discussion of the health check timeouts.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Key Terms
The following terms will be used extensively throughout this chapter. It is recommended that you
become familiar with the terminology prior to configuring any of the health checks described.
Key Term
Definition
Load Balancing Object
A general term that can refer to a server, server instance, server pool, or LLB
Gateway.
Liveness Check
A Liveness Check is a health check that reports or is utilized only to assess
UP/DOWN status. L3 (Ping), L4 (UDP and TCP), and ACV are liveness checks.
Load
Load is a measure of activity level, used for making load balancing decisions. The
term Load is used in the following contexts:
Health Check -- The Load on associated server instance is the value
reported in the response to the health check query. There is no load
associated with a liveness check. A liveness check reflects only UP/DOWN
status.
Server Instance -- The Load on a server instance is calculated using 3
types of measure: delay, active connections, and health check load(s).
Load Check
A Load Check is a health check that reports a load value, and may also (directly
or indirectly) indicate UP/DOWN status. VLB and Server Agent are types of Load
Checks.
ACV
Active Content Verification. Used to check the validity of a load balancing object
based on the validity of returned character strings
ICMP
Layer 3 ICMP Probes.
TCP
Layer 4 TCP Probes.
UDP
Layer 4 UDP Probes.
srvagt
Server Agent Probes.
VLB
VLB Health Checks.
Attached Health Check
The health checks that are attached to load balancing objects.
Target Object Parameter
(also access_parms)
Can either be 'Self', indicating that the parameters required to access the object
to be health-checked are in the health check definition, or "Parent", indicating
that the parameters are taken from the object to which the health check is
attached if not available in the health check definition.
LLB Gateway
Refers to Link Load Balancing Gateway.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
529
Health Checks
Health Check Constraints
The following table shows the load balancing objects and the health checks that can be attached to
each:
Load Balancing Objects
Types of health check that can be attached
Liveness Checks (UP/DOWN)--ONLY. These health checks can be attached to a
server, or server instance. In addition, Equalizer will enforce the following
restrictions:
•a Layer 4 TCP health check can only be attached to a TCP-type server (or
server instance)
Servers
Server Instances
•a Layer 4 UDP health check can only be attached to a UDP type server (or
server instance)
Server Agent and VLB Health Checks CANNOT be used with these objects.
Any health check can be attached to a server pool. All server instances in the pool
are probed as specified by the health check attached to the server pool. Equalizer
will enforce the following restrictions on combinations that do not make sense:
•You cannot add an L4 TCP health check to a server pool of UDP servers
Server Pools
•You cannot add an L4 UDP health check to a server pool of TCP servers
•You cannot add a VLB health check to a server pool of mixed virtual machines
and real servers
LLB Gateways
ICMP Health Checks only.
Health Check Probing Ports
The table below summarizes the health checking probes and ports used with Equalizer:
Layer
Protocol
Port
Details
Layer 3
ICMP
N/A
Echo request/reply
53
DNS
111
(RPC4) Portmap
2049
(RPC4) NFS
User supplied
TCP (connect only)
User supplied
ACV (Plaintext)
Use supplied
ACV (SSL)
1510 (default)
Server Agent Health Check
N/A
VLB Health Check
Layer 4
UDP/IP
Layer 4
TCP/IP
Layer 7
530
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
System Health Checks
There are three pre-defined System Health checks that are automatically attached to load
balancing objects:
l
ICMP-Default - attached to servers when they are created.
l
TCP-Default - attached to a TCP server pools when the first TCP server instance is added.
l
UDP-Default - attached to a UDP server pool when the first UDP server instance is added.
System Health Check Notes
1. The System Health Checks are assigned to new objects as described above. Instances of the
health checks can be added to servers, server pools, and server instances.
2. Whenever a server instance is attached to server pool without existing server instances, a
TCP or UDP default health check is automatically assigned to the server pool, based on the
server protocol.
l
l
If you delete a system health check attached to a server pool, a new TCP or UDP
system health check will be automatically attached to the server pool when you add
the first server instance to the server pool. This will occur even if you deleted a
previously existing system health check.
If you delete a system health check attached to a server pool and custom health
checks remain attached, a new TCP or UDP system health check will be automatically
attached to the server pool when you add the first server instance. This will occur
even if you deleted a previously existing system health check. The existing custom
health checks will be unaffected.
3. The System Health Checks cannot be deleted.
4. The System Health Checks can be disabled at a global level or individually, on an attached
instance.
5. The IP(ip), Port (port) (TCP and UDP) and Use Parent Parameters (access_parm) parameters
on the default health checks are NOT modifiable.
6. When you upgrade from a release prior to EQ/OS 10.3.2 the health checks will be configured
identically with the L3 and L4 Health Checks from previous releases. In previous EQ/OS
releases, the system automatically enabled an L3 (ICMP) health check on a server on
creation and an L4 TCP health check on server instances on creation.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
531
Health Checks
Firmware Upgrade Notes
When upgrading or downgrading, it is HIGHLY RECOMMENDED that you create a backup of
your current configuration. Refer to "Backup and Restore" on page 305 for instructions on
creating backups and restoring previous configurations.
For Layer 4 TCP and ACV Health Checks Upgrading to EQ/OS 10.3.2 or higher
In previous OS releases, custom L4 TCP/ACV probe parameters could be configured on a Server
Pool. When your system is upgraded to EQ/OS 10.3.2 or higher, the non-default probe parameters
will be copied to the new health check configuration IF AND ONLY IF the '"Probe Layer 4"' option is
ENABLED on the Server Instance in the Server Pool (in the older configuration). If this flag is
DISABLED in the older configuration, the non-default parameters will be lost and will revert to the
default values on any Layer 4 TCP health checks added to that Server Pool on the upgraded
system.
For Layer 4 UDP Health Checks Upgrading to EQ/OS 10.3.2 or higher
If there are UDP health checks attached to server instances when your system is upgraded to
EQ/OS 10, the health checks will copied to the new health check configuration IF AND ONLY IF the
'"Probe Layer 4"' option is ENABLED on the Server Instance in the Server Pool (in the older
configuration). If this flag is DISABLED in the older configuration, the health check WILL NOT be
copied.
If all of the server instances in a server pool have the same UDP health check attached with the
"Probe Layer 4" option enabled, a new UDP health check will be attached to the server pool when
upgrading. This means that the health check will apply to all server instances.
For Server Agent and VLB Health Checks Upgrading to EQ/OS 10.3.2 or higher
If a VLB or Server Agent health check was not previously attached to each of the server instances
in a server pool, a new VLB or Server Agent health check object will be created when upgrading.
The new health check objects will maintain the same parameters as your previous configuration,
however, they will not be attached to the server instances as they were before upgrading. You
then have the option of attaching the newly created health check object to Server Pools or Server
Instances.
If a VLB or Server Agent health check was previously attached to each server instance in a server
pool, the health checks will be attached to the Server Pool when upgrading. They will maintain the
same parameters as your previous configuration. In this case, the health checks will apply to all
server instances in the server pool.
532
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
For Server Agent and VLB Health Checks upgrading to EQ/OS 10.3.2b or higher
If you are upgrading from a firmware version prior to EQ/OS 10.3.2b and VLB or Server Agent
health checks with the same parameters are attached to server instances prior to upgrade, the
same health checks will be generated with an appended name and attached to the server pools in
the new configuration.
The figure below shows the health check conversion during upgrade. In the example, a Server
Agent health check is used. The process is the same for VLB health checks.
1. All Server Agent or VLB Health checks having the same configuration and were previously
attached to server instances as "health check instances" in the older configuration will be
converted to load balancing objects in the new configuration. They can be displayed in the
CLI by entering eqcli > show health_check or in the GUI by selecting Load Balance > Health
Check on the left navigational pane.
2. The health checks will be attached to the server pools and not the server instances they
were attached to previously, however, they will be renamed as shown in the figure above.
The naming convention used is:
SERVERPOOLNAME- HEALTHCHECKNAME
3. Note that the health check attached to ServerPool2 > ServerInstance3 above (ServerPool1SvAgent1) uses the same naming convention, even though it is attached to ServerPool 2. You
cannot "rename" the health check. If this name is unacceptable, you can create a new
health check (See "Health Check Configuration Process" on page 534) using the same
parameters as the converted health check and attach it to server instances as necessary.
Remove the converted health check from the server pool as well.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
533
Health Checks
Health Check Configuration Process
The health check configuration process uses the same basic steps for all health check types.
These include:
1. Creating the health check.
2. Configuring health check parameters using the CLI or GUI.
3. Attaching health checks to load balancing objects (servers, server pools, server instances,
and LLB gateways).
All health checks are enabled, by default. They can be disabled either globally or for a single,
attached health check as necessary. Refer to "Disabling Health Checks" on page 602 for
instructions.
534
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring ICMP Health Checks
ICMP (Layer 3 Internet Control Message Protocol) health check probes are "liveness" checks. This
means that if a response is not received to an ICMP echo request, and no other health check
probes are configured, the object is marked DOWN. However, Equalizer will continue to send
ICMP requests to the IP address and, if an ICMP echo response is subsequently received, the
object will be marked UP.
The number of times that a server is probed before being marked DOWN is determined by the
Maximum Tries per Interval parameter. The ICMP Probe Interval parameter is a timer and when it starts,
the first ICMP probe is sent. If the value of Maximum Tries per Interval is greater than 1, the next
probe is sent a number of seconds later equal to:
(ICMP Probe Interval) / (ICMP Probe Maximum Tries)
For example, the default Probe Interval is "15" and the default Maximum Tries per Interval is "3". So, by
default, an ICMP probe is sent every 5 seconds.
When the Probe Interval timer expires, an object is marked UP if a response to any probe sent
during the Probe Interval was received. An object is marked DOWN by lack of a response to an ICMP
probe during the probe interval. (Refer to the description of the Relaxed probe interval in the table
below)
The ICMP-Default health will be attached to servers when they are created.
ICMP health checks can be disabled either globally or by attached health checks using either the
CLI or the GUI. Refer to "Disabling Health Checks" on page 602 for procedures.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
535
Health Checks
Parameters
ICMP probes are configured using the parameters described in the ICMP Health Check Probe
Parameters table below.
Further descriptions about the health check timers and intervals and how they work together are
provided in "Health Check Timeouts" on page 609.
ICMP Health Check Probe Parameters
GUI Parameters (CLI Parameter)
Description
Target Object Parameters (Cannot be modified on ICMP-Default Health Checks)
The Use Parent Parameters flag in the GUI (same as
the access_parms parameter in the CLI) determines
where we obtain the IP address and port to use for the
health check:
l
If Use Parent Parameters is enabled (or set to
parent in the CLI), then if either the IP address
or port is not specified in the health check, they
will be taken from the attached object (the
“parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set to
self in the CLI), then the IP address and port
must be specified in the health check.
If any of the above parameters cannot be determined
from either the health check or the attached object, the
GUI and CLI will report that the health check
configuration is incomplete.
Target Object IP
(ip)
The IP address of the health check target.
Health Check Timers
Max Tries per Interval
(probe_maxtries)
The maximum number of times per Probe Interval that
Equalizer will attempt to probe the object.(default: 3) It
is recommended that this parameter be set to 3 or greater
in configurations where a physical server appears in
multiple server pools.
Probe Interval
(probe_interval)
A timer specifying the length of time (in seconds) during
which a successful server probe must occur, or the
server is marked DOWN. At least one L3 ICMP probe for
the server must have succeeded since the last Equalizer
reboot, or failed ICMP probes for the server will be
ignored and the server will be marked UP.(default: 15)
Flags
Disable
(disable)
Disables the health check on a global level.
Relaxed
(relaxed_probe)
When enabled, if a server is DOWN, but has not
previously been UP, it will be marked UP. Enabling this
option prevents the sudden reporting of servers being
DOWN following an upgrade.
536
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring an ICMP Health Check Using the CLI
1. Log in to the CLI.
2. Create a new ICMP health check using the following format:
eqcli > health_check health_check_nametype icmpparameter_name value [...]
where:
health_check_name - is the name of the health check.
parameter_name and value - is the health check parameter and the value assigned
to it.
For example:
eqcli > health_check icmp_test type icmp ip 1.3.5.7
eqcli: 12000287: Operation successful
eqcli > show health_check icmp_test
Health Check Name
: icmp_test
Type
: icmp
Access Parameter
: parent
IP
: 1.3.5.7
Probe Interval
: 15
Max Tries/Interval
: 3
Flags
:
eqcli >
3. Enter additional parameter_names and values described in the ICMP Health Check Probe
Parameters table above. Use the following format:
eqcli > health_check health_check_name parameter_name value
Additional information on using the health check CLI commands can be found in "Health Check
Commands" on page 217.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
537
Health Checks
Configuring an ICMP Health Check Using the GUI
If not using the ICMP-Default health check, you can create an ICMP health check as follows:
1. Log in to the GUI.
2. Click on the Load Balance configuration tab.
3. Do either of the following to display the Add Health Check form:
a. Right click on the Health Checks branch and select Add Health Check.
b. Select the Health Checks branch on the left navigational pane to display the list of
configured health checks on the right configuration pane. Click on the
+ icon.
4. Enter a name in the Health Check Name box and select ICMP from the drop down list.
5. Click on the Commit button to save the health check. The Configuration > Settings screen will
appear on the right configuration pane.
4. Modify the ICMP health check probe parameter shown in the ICMP Health Check Probe
Parameters table above as necessary. Clicking on the Reset button will remove anything that
you've entered and return the screen to the default display.
5. Click on Commit.
Refer to "Attaching Health Checks to Load Balancing Objects" on page 591 for instructions on
attaching the health check.
538
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring TCP & UDP Health Checks
Layer 4 TCP and UDP health checks are "liveness" checks. At Layer 4, Equalizer sends health
check probes and attempts to connect to a specific TCP or UDP port. A TCP SYN request to port 80,
for example, would expect a TCP SYN ACK response in return. If the response is not received
within the configured timeouts and intervals, port 80 would be marked DOWN for that server, or
server instance.
L4 UDP probes are performed on UDP protocol servers and are valid for IPv4 addresses only.
For specific Remote Procedure Call (RPC) services running on well-known ports - Network File
System (NFS) and portmap - an RPC call is sent to the server. If no response is received the
server is marked DOWN.
For the Domain Name System (DNS), a DNS request is sent to the server. If no response is
received the server is marked DOWN.
For all other UDP services, a UDP datagram is sent to the server probe port and if no response is
received the server is marked DOWN.
Layer 4 TCP and UDP health checks can be disabled either globally or by attached health check
using either the CLI or the GUI. Refer to "Disabling Health Checks" on page 602 for procedures.
When you configure a server pool with TCP server instances, the server pools will have one TCPDefault health check. (See "System Health Checks" on page 531). Likewise, when you configure a
server pool using UDP server instances, a UDP-Default health check will be attached to the server
instance.
UDP Probing Behavior
UDP probes are sent via ports 53, 111, and 2049. On all other ports, a “dummy” probe, which
would not be recognizable to a receiving service, is also transmitted.
l
l
l
l
l
If a UDP response is received, the probe is considered UP.
If an ICMP "destination unreachable" response is received for either port or protocol, the
probe is considered “DOWN”.
If no response is received, the UP/DOWN determination depends on the health check’s Relax
(relaxed_probein the CLI ) option:
o
If the Relax (relaxed_probe) option is enabled, the probe is considered “UP”.
o
If the Relax (relaxed_probe) option is not enabled, the probe is considered “DOWN”.
In all cases, the state of a probe or the object to which it is attached will not change until
one probe interval has passed since the probe began. This prevents spurious UP/DOWN
indications and alerts.
UDP probing is only valid for IPv4 addresses.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
539
Health Checks
Parameters
The table below describes the TCP and UDP health check parameters used in the configuration
process.
Further descriptions about the health check timeouts and intervals and how they work together
are provided in "Health Check Timeouts" on page 609.
L4 Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Target Object Parameters (Cannot be modified on TCP-Default Health Checks)
The Use Parent Parameters flag in the GUI (same as
the access_parms parameter in the CLI) determines
where we obtain the IP address and port to use for the
health check:
l
If Use Parent Parameters is enabled (or set to
parent in the CLI), then if either the IP address
or port is not specified in the health check, they
will be taken from the attached object (the
“parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set to
self in the CLI), then the IP address and port
must be specified in the health check.
If any of the above parameters cannot be determined
from either the health check or the attached object, the
GUI and CLI will report that the health check
configuration is incomplete.
Target Object IP
(ip)
Protocol
(proto)
(For UDP only)
Port
(port)
The IP address of the health check target.
This drop down list specifies the Layer 4 health check
protocol. (default: DNS)
This is the port to use for the port number for probing the
server.
SSL Parameters (For TCP only)
Highest TLS Version
(highest_tls_version)
540
Used when the Use SSL (probe_ssl) option is enabled.
Sets the health check highest TLS version. It specifies the
highest TLS version that will be offered in the SSL probe
sent to servers The probe can use levels from SSLv3 and
the highest probe levels of TLS v1.0, v1.1, or v1.2.
(default:TLS v1.2)
In the CLI, values are used to assign the TLS versions as
follows:
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
(Default: 4)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
Health Check Timers
Probe Interval (seconds)
(probe_interval)
A timer specifying the length of time (in seconds) during
which a successful server probe must occur, or the
server is marked DOWN. (default: 15)
Max Tries Per Interval
(probe_maxtries)
The maximum number of times per Probe Interval that
Equalizer will attempt to probe an object.(default: 3)
It is recommended that this parameter be set to 3 or
greater in configurations where a physical server appears
in multiple server pools.
Probe Global Timeout (seconds)
(probe_gto)
The health check probe global timeout (in seconds).
(default: 5)
Probe Connect Timeout (seconds)
(probe_cto)
The health check connection timeout. The number of
seconds (default: 1) that Equalizer will wait for a
connection attempt to the health check server application
to succeed before marking the object UP or DOWN.
(For TCP only)
Probe Data Timeout (seconds)
(probe_dto)
(For TCP only)
The health check data timeout. Once a connection is
established, this parameter indicates the number of
seconds (default: 2) Equalizer will wait for the first byte
of the health check server application response before
marking the object DOWN.
Flags
Disable
(disable)
Use SSL
(probe_ssl)
(ACV, Server Agent, and TCP only)
Relaxed
(relaxed_probe)
(UDP only)
Disables the health check on a global level.
If enabled, the probe exchange between Equalizer and a
server instance will be performed over an encrypted SSL
connection. The Highest Version drop down list will
display a list of the highest TLS version to use. (default:
Enabled )
When this option is enabled, if the probe receives either
no response or an ICMP response other than port or
protocol unreachable, the probe will be marked UP. ICMP
responses of port or protocol unreachable always cause
the probe to be considered down.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
541
Health Checks
Configuring TCP and UDP Health Checks Using the CLI
If not using the TCP-Default or UDP-Default health check, you can create one as follows:
1. Log in to the CLI.
2. Create a new L4 health check using the following format:
eqcli > health_check healthcheckname type [tcp|udp] parameter_name value [...]
where:
healthcheckname - is the name of the health check.
parameter_name and value - is the health check parameter and the value assigned
to it. Refer to the L4 Health Check Parameters table above.
For example:
eqcli > health_check TCP_test type tcp ip 2.5.7.9 probe_maxtries 2
eqcli: 12000287: Operation successful
eqcli > show health_check TCP_test
Health Check Name
Type
Access Parameter
IP
Port
Probe Interval
Max Tries/Interval
Global Timeout
Connection Timeout
Data Timeout
Highest TLS Version
Flags
eqcli >
:
:
:
:
:
:
:
:
:
:
:
:
TCP_test
tcp
parent
2.5.7.9
0
15
2
5
1
2
4
probe_ssl
Additional information on using the health check CLI commands can be found in "Health Check
Commands" on page 217.
542
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring TCP and UDP Health Checks Using the GUI
If not using the TCP-Default or UDP-Default health check, you can create one as follows:
1. Log in to the GUI.
2. Click on the Load Balance configuration tab.
3. Do either of the following to display the Add Health Check form:
a. Right click on the Health Checks branch and select Add Health Check.
b. Select the Health Checks branch on the left navigational pane to display the list of
configured health checks on the right configuration pane. Click on the
+ icon.
4. Enter a name in the Health Check Name box and select UDP or TCPfrom the drop down list.
5. Click on the Commit button to save the health check. The Configuration > Settings screen will
appear on the right configuration pane. The TCP health check and UDP health check
configuration screens are shown.
6. Modify the parameters as shown in the L4 Health Check Parameters and Configuring TCP &
UDP Health Checks tables above as necessary.
7. Click on Commit .
Refer to "Attaching Health Checks to Load Balancing Objects" on page 591 for instructions on
attaching the health check. In addition attached Layer 4 health checks can check the UP/DOWN
status of the selected server, or servers, where server instances are attached. Refer to "Attached
ACV and TCP Health Checks and the Test Function" on page 595 for details.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
543
Health Checks
Configuring ACV Health Checks
Active Content Verification (ACV) is a "liveness" health check that serves two purposes: Layer 4
probing and Layer 7 probing. It is a mechanism used to check the validity of a server instance.
When an ACV health check is attached to a server instance (in a server pool), Equalizer requests
data from the server and verifies that the returned data contains a character string that indicates
that the data is valid. If the returned data matches the character string configured in the health
check, the server is considered to be UP. If the character string is not found or does not match the
configured health check, the server is marked DOWN.
A Send Data String can be specified if the service running if a server’s probe port requires input in
order to respond. If the TCP probe connection is not established ACV probing will fail as well.
You can use ACV with most network services that support a text-based request/response protocol,
such as HTTP.
ACV health checks occur as part of a TCP handshake; this means that an ACV health check
can only be attached to an object that supports TCP connections. For example: you can attach
an ACV health check to a TCP type server, but not to a UDP type server.
ACV probes are limited to 99 characters, and must use only the printable ASCII characters
(decimal 32 to 126). Equalizer searches for Receive Data strings in the first 1024 characters of the
server’s response to high-level TCP probes. If a Receive Data string is not found in the first 1024
characters of the server response, the server is marked DOWN.
ACV is best explained using a simple example. HTTP protocol enables you to establish a
connection to a server, request a file, and read the result. The example below shows the
connection process when a user requests a telnet connection to an HTTP server and requests an
HTML page.
> telnet www.myserver.com 80
>>>>>>>>>>>>
Connected to www.myserver.com
>>>>>>>>>>>>
> GET /index.html
>>>>>>>>>>>>>>>>>>>>
<HTML> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<TITLE>Welcome to our Home Page </TITLE>
</HTML>
Connection closed by foreign host
>>>>
User requests connection to server.
Telnet indicates connection is established.
User sends request for HTML page.
Server responds with requested page.
Telnet indicates server connection closed.
Equalizer can perform the same exchange automatically and verify the server pool’s response by
checking the returned data against an expected result.
Send Data and Receive Data Strings
Specifying Send Data and Receive Data strings basically automates the exchange shown above. In
web applications requiring input, Equalizer uses Send Data probe strings to request data from
each server. To verify the server’s content, it searches the returned data for the Receive Data
string configured in the health check. For example, you can use “GET /index.html” as Send Data
and you can set the Receive Data to some text, such as “Welcome” in the example shown above,
which appears on the home page.When the Received Data string matches the string that you
configure in the health check, the server is considered to be UP.
544
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Similarly, if you have a web server with a PHP application that accesses a database, you can use
ACV to ensure that all of the components in the application are working. You could set up a PHP
page called test.php that accesses the database and returns a page containing ALL OK if there are
no problems.
For most applications, only a Receive Data string is needed - Equalizer connects to the probe port
on the server instance and waits for a response, looking for the Receive Data string configured in
the health check.
Some applications may require input on the connection before a response is sent back to
Equalizer. This is where a Send Data string is used - if it is non-empty, the Send Data string is
sent after the server instance connection is established.
The Send Data or Receive Data string:
l
l
Must be enclosed in single or double quotes if it contains a space character.
Any single or double quotes included within the string must be preceded by the backslash
character (\).
Note -In Send Data strings character escapes such as “\n” for new-line, “\r” for carriage return and “\t” for tab are
supported and must be manually entered. For Receive Data strings Regular Expression matching is supported.
Attached ACV health checks can run a "test" on Send Data and Receive Data strings configured
into the health check to check the UP/DOWN status of the selected server, or servers, where
server instances are configured in the server pool. Refer to "Attached ACV and TCP Health Checks
and the Test Function" on page 595 for instructions on using this feature.
ACV health checks can be disabled either globally by attached health check using either the CLI or
the GUI. Refer to "Disabling Health Checks" on page 602 for procedures.
ACV Health Check vs. HTTP/S Application Health Checks
There are distinct differences between ACV health checking and HTTP/S health checking (See
"Configuring HTTP and HTTPS Application Health Checks" on page 554 for details.):
1. ACV health checks provide a generic ability to specify Send Data and Receive Data for the
health check probing process. It requires an understanding of HTTP at a level which allows
you to retrieve web page using telnet. .You can specify Send Data strings that the probe
uses to elicit a response from servers requiring input after a TCP connection is made. In the
example shown above it was shown that you can use “GET /index.html” as the Send Data
to elicit a server response and you could specify "Welcome" in the response data from the
content returned.
2. HTTP/S application health checking provides a more customized and flexible method of
probing web servers:
l
They provide you with the ability to select commonly used parameters and supplement
them as necessary. For example, "GET /\r\n" (in an ACV health check) would be
configured by simply configuring the GET method directly into the health check. In
addition, you have the ability to also probe web servers using HEAD or POST requests.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
545
Health Checks
l
l
l
546
Some web servers require specific headers in the request to elicit responses. With
HTTP/S Application health checking, you could specify the header fields to send to the
servers and details of the header that would elicit the response if required.
Status codes returned by web servers could be used as means of determining UP/DOWN
status. You could specify UP status codes or, alternatively, a set of DOWN status codes.
For example, a status code "200" means that the server is UP.
Some web applications require authentication before responses are returned.
HTTP/S application health checking provides you with the ability of configuring user name
and password information directly into the health check if necessary.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Parameters
The table below describes the ACV health check parameters that are used in the configuration
process.
Further descriptions about the health check timers and intervals and how they work together are
provided in "Health Check Timeouts" on page 609.
ACV Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Target Object Parameters
The Use Parent Parameters flag in the GUI (same as
the access_parms parameter in the CLI) determines
where we obtain the IP address and port to use for the
health check:
l
If Use Parent Parameters is enabled (or set to
parent in the CLI), then if either the IP address
or port is not specified in the health check, they
will be taken from the attached object (the
“parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set to
self in the CLI), then the IP address and port
must be specified in the health check.
If any of the above parameters cannot be determined
from either the health check or the attached object, the
GUI and CLI will report that the health check
configuration is incomplete.
Target Object IP
(ip)
The IP address of the health check target.
Port
(port)
This is the port to use for the port number for probing the
server.
ACV Parameters
For most applications, only an ACV response string is
needed - It connects to the probe port on the server
instance and waits for a response. Some applications may
require input on the connection before a response is sent
back. The Send Data string is used for this purpose - if
it is non-empty, the Send Data string is sent after the
server instance connection is established.
Send Data
(send_data)
An Send Data string:
Must be enclosed in single or double quotes if it
contains a space character.
Any single or double quotes included within the string
must be preceded by the backslash character (\).
Character escapes such as “\n” for new-line, “\r” for
carriage return and “\t” for Tab are supported. "\r" and
"\n" must be manually inserted at the end of all HTTP and
HTTPS ACV probes.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
547
Health Checks
GUI Parameter (CLI Parameter)
Description
The Receive Data string should be text that appears only
in a valid response. This string is also case-sensitive. An
example of a poorly chosen string would be HTML , since
most web servers automatically generate error pages that
contain valid HTML.
A Receive Data string:
Must be enclosed in single or double quotes if it
contains a space character.
Receive Data
(recv_data)
Any single or double quotes included within the string
must be preceded by the backslash character (\).
Character escapes such as “\n” for new-line, “\r” for
carriage return and “\t” for Tab are supported. "\r" and
"\n" must be manually inserted at the end of all HTTP and
HTTPS ACV probes. Regular Expression matching is
supported.
If the page that is returned contains the correct receive
data string (in the first 1024 characters, including
headers) the server is marked “UP”; if ALL OK were not
present, the server is marked “DOWN”.
SSL Parameters
Highest Version
(highest_tls_version)
Used when the Use SSL (probe_ssl) option is enabled.
Sets the health check highest TLS version. It specifies the
highest TLS version that will be offered in the SSL probe
sent to servers The probe can use levels from SSLv3 and
the highest probe levels of TLS v1.0, v1.1, or v1.2.
(default:TLS v1.2)
In the CLI, values are used to assign the TLS versions as
follows:
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
(Default: 4)
Health Check Timers
Probe Interval (seconds)
(probe_interval)
Max Tries Per Interval
(probe_maxtries)
Probe Global Timeout (seconds)
(probe_gto)
548
A timer specifying the length of time (in seconds) during
which a successful server probe must occur, or the
server is marked "down". (default: 15)
The maximum number of times per Probe Interval that
Equalizer will attempt to probe an object.(default: 3)
It is recommended that this parameter be set to 3 or
greater in configurations where a physical server appears
in multiple server pools.
The health check probe global timeout (in seconds).
(default: 5)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
Probe Connect Timeout (seconds)
(probe_cto)
The health check connection timeout. The number of
seconds (default: 1) that Equalizer will wait for a
connection attempt to the health check server application
to succeed before marking the object UP or DOWN.
Probe Data Timeout (seconds)
(probe_dto)
The health check data timeout. Once a connection is
established, this parameter indicates the number of
seconds (default: 2) Equalizer will wait for the first byte
of the health check server application response before
marking the object DOWN.
Flags
Disable
(disable)
Disables the health check on a global level.
Use SSL
(probe_ssl)
If enabled, the TCP probe exchange between Equalizer
and a server instance will be performed over an
encrypted SSL connection. The Highest Version drop
down list will display a list of the highest TLS version to
use. Enabled by default.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
549
Health Checks
Configuring ACV Health Checks using the CLI
Configure an ACV health check using the CLI as follows:.
1. Log in to the CLI.
2. Create a new ACV health check using the following format:
eqcli > health_check health_check_name type acv parameter_name value [...]recv_data
Receive_data_string send_data
send_data_string flags flag
where:
health_check_name - is the name of the health check.
parameter_name and value - is the health check parameter and the value assigned
to it. Refer to the ACV Health Check Parameters table above.
Receive_data_string - is the response string configured into the health check that
must be matched by a server response for the server to be considered UP.1
Send_data_string - is the send string configured into the health check that the
probe uses to elicit a response from servers requiring input after a TCP connection is
made.2
For example:
eqcli > health_check ACV_test type acv ip 5.6.7.9 recv_data XXXXXX send_
data XXXXXX
eqcli > show health_check ACV_test
Health Check Name
Type
Access Parameter
IP
Port
Probe Interval
Max Tries/Interval
Global Timeout
Connection Timeout
Data Timeout
Highest TLS Version
Send Data
Recv Data
Flags
eqcli >
:
:
:
:
:
:
:
:
:
:
:
:
:
:
ACV_test
acv
parent
5.6.7.9
0
15
3
5
1
2
4
XXXXXX
XXXXXX
probe_ssl
1The Receive Data string shown below is for demonstration purposes only.
2The Send Data string shown below is for demonstration purposes only.
550
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Additional information on using the health check CLI commands can be found in"Health Check
Commands" on page 217.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
551
Health Checks
Configuring ACV Health Checks using the GUI
Configure an ACV health check using the GUI as follows:
1. Log in to the GUI.
2. Click on the Load Balance configuration tab.
3. Do either of the following to display the Add Health Check form:
a. Right click on the Health Checks branch and select Add Health Check.
b. Select the Health Checks branch on the left navigational pane to display the list of
configured health checks on the right configuration pane. Click on the
+ icon.
4. Enter a name in the Health Check Name box and select a ACVfrom the drop down list.
5. Click on the Commit button to save the health check. The Configuration > Settings screen will
appear on the right configuration pane.1
1The Send Data and Receive Data strings shown in the screen capture below is for demonstration purposes only.
552
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
6. Configure the ACV health check using the parameters in the ACV Health Check Parameters
table above. Clicking on the Reset button will remove anything that you've entered and
return the screen to the default display. Clicking on the Reset button will remove anything
that you've entered and return the screen to the default display.
7. Click on the Commit button to save the health check.
Refer to "Attaching Health Checks to Load Balancing Objects" on page 591 for instructions on
attaching the health check.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
553
Health Checks
Configuring HTTP and HTTPS Application Health Checks
HTTP and HTTPS application health checks are “liveness” health checks that probe server
applications for specific data. They can be thought of as enhanced HTTP-specific versions of Active
Content Verification (ACV) health checks with built-in knowledge of HTTP-protocol-specific
parameters. With HTTP and HTTPS health checks, an application's availability status is
determined by examining specific attributes of the response received for the values specified in
the health check.
HTTP and HTTPS health checks have similar configuration options, the only difference being that
HTTPS health checks use “https://” in the URL and also specify the protocol level supported for the
SSL handshake between the ADC and the server. Because of their similarities, we'll refer to these
two health check types generally as “HTTP health checks” for simplicity, and refer to “HTTPS
health checks” only when describing parameters and functionality specific to HTTPS.
HTTP health checks allow you to specify the following HTTP-specific data with the request sent to
the server application:
l
The HTTP method (GET, POST, or HEAD) and associated required data (such as the URL and
POST data)
l
Specific HTTP header values
l
HTTP basic authentication parameters
l
The SSL protocol level used when connecting to the application server (HTTPS only)
HTTP health checks can be configured to look for the following in the server response:
l
Specific HTTP status codes
l
Application-specific data in the server response
Finally, a set of timers allows you to specifically configure the time span over which the health
check will wait for a server response before regarding the server application as unavailable.
HTTP and HTTPS Application health checks can be attached to servers, server pools, and server
instances using TCP protocol. Refer to "Displaying Configured Health Checks" on page 597 for
descriptions of how to display the status of the HTTP and HTTPS health checks and the objects to
which they are attached.
554
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
General Probing Process
In general, the HTTP/HTTPS health checking process is as follows:
1. Equalizer sends an HTTP/HTTPS request to the port on the web server that a
service/application is running on. The IP address and port number are either specified in the
health check parameters, or will be taken from the object to which the health check is
attached, depending on the setting of the “Use Parent Parameters” flag.
If the application running on a web server requires specific header fields to be sent in
order to operate properly, the health check will need to have the required header
fields configured in the health check so that they are sent in the request.
2. The server then returns a response that includes a status line, a success or error code, and
possibly additional server information.
3. The response is then evaluated against the configured health check:
a. If the returned response status code matches the health check configuration
and indicates that the probe is considered UP, then receive data (if specified)
will be compared with the response.If the first 1024 bytes of content returned
from the probed object (e.g. server instance) is found to contain the receive
string specified in the health check, the server is considered UP. If the content
does not match the configured receive strings in the health check, the server is
marked DOWN.
b. If no receive data is specified then the status code is the only indicator that is
checked.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
555
Health Checks
General Configuration
Health checks are configured using basic EQ/OS 10 health checking parameters such as the Target
Object parameters and SSL Parameters (for HTTPS health checks). In addition to the basic health
check parameters, Method, Send and Receive data, Send Header details, UP/DOWN status codes,
and Authentication parameters may also need to be configured. The following order of
configuration should be used as a guideline.
1. Configure the basic health check and the “Use Parent Parameters” option.
2. Specify Send/Receive data (if applicable)
3. Specify Send Header (if applicable)
4. Specify UP/DOWN status code specifications
5. Specify the type of Authentication (if applicable)
6. Specify Health Check Timers and Intervals
Before You Begin
l
l
You must know the IP address, port, and configuration details for the applications running
on your web servers. For some application protocol checks, you may need to specify user
credentials (See "Configuring HTTP and HTTPS Application Health Checks" on page 554).
You must have Administrative permissions on Equalizer. (Refer to "User Permissions" on
page 257).
Parameters
The following parameters are used when configuring HTTP and HTTPS Application Health Checks
using the configuration procedures that follow. GUI parameter names are presented along with
the corresponding CLI command names.
Target Object Parameters
GUI Parameter
(CLI Parameter)
Description
The Use Parent Parameters flag in the GUI (same as the access_parms
parameter in the CLI) determines where we obtain the IP address and port to use for
the health check:
l
If Use Parent Parameters is enabled (or set to parent in the CLI), then if
either the IP address or port is not specified in the health check, they will be
taken from the attached object (the “parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set to self in the CLI), then the
IP address and port must be specified in the health check.
If any of the above parameters cannot be determined from either the health check or
the attached object, the GUI and CLI will report that the health check configuration is
incomplete.
Target Object IP
(ip)
556
This is the IP address of the health check target.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Target Object Parameters
GUI Parameter
(CLI Parameter)
Description
Port
(port)
This is the port to use when probing the heath check target. It is the port on which
the application or service that you want to probe is running.
SSL Parameters (For HTTPS Health Checks only)
GUI Parameter
(CLI Parameter)
Description
Highest TLS
Version
(highest_tls_
version)
This specifies the highest TLS version that will be offered in the SSL probe sent to servers.
In the CLI, an integer is used to specify the protocol level, while in the GUI the strings shown
at right below are used::
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
Default CLI: (4)
Default GUI:(TLS 1.2)
Send/Receive Data
GUI Parameter
(CLI Parameter)
Description
URL
(url)
This is the target of the HTTP or HTTPS request When entering the URL in both the CLI and
GUI, use the format:
http://<host>/ absolute_path/ or https://<host>/absolute_path/
A “/” character is required as a minimum absolute path following the host..
This parameter populates the "host" header field in the request. . The content specified after
the "/", such as an absolute_path, will be requested. This is usually a file name.
Refer to RFC7230 for additional information on URLs.
HTTP Method
(http_method)
GET : Gets data from a web server by specifying parameters in the URL portion of the
request.
HEAD : Same as GET requests but returns only the HTTP headers without a message body.
POST : Uses a program on the server that handles the data that you are sending.
POST Data
(send_data)
POST Data is the message body, which follows the request line and headers.
Receive Data
(recv_data)
This is a configured string that, if a matching string is present within the first 1024 bytes of
the HTTP response, the health check probe is considered UP.
If a Receive Data string is not specified, then the availability of the application will be
determined solely on the basis of the HTTP status code returned by the application.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
557
Health Checks
Headers
GUI Parameter
(CLI Parameter)
Description
The Headers (send_hdr) parameter allows you to specify specific HTTP header-value
Headers
(send_hdr)
pairs as required by the applications running on the HTTP health check target. All standard
headers required by RFC7231 are supported, as well as custom headers that are applicationspecific. Up to 10 headers can be specified. In the CLI, headers are specified as colon
separated name-value pairs. In the GUI, a drop-down list is provided, with the following
headers supplied:
Accept, Accept-Charset, Accept-Encoding, Cache-Control, Content-Type, Expect,
Host, Range, Referer, User-Agent, X-Forwarded-For, Custom
The Custom selection allows you to enter a header name not provided in the drop-down list.
In both the CLI and the GUI, the value string provided cannot exceed 1000 characters.
Status Codes
GUI Parameter
(CLI Parameter)
Status Codes
(stat_codes)
Description
HTTP status codes are 3-digit codes returned by servers to describe if a request was
processed and how it was processed. Refer to RFC7230 for detailed information on status
codes and their definitions. The first digit identifies the general category of response:
1xx indicates an informational message
2xx indicates success of some kind
3xx redirects the client to another URL
4xx indicates a client error
5xx indicates server error
UP/DOWN describes whether the health check should be considered UP or DOWN if any of
the specified status codes is received.
In the GUI, status codes are entered by selecting the UP Status Codes or DOWN Status
Codes options on the Health Check's Configuration > Status Codes screen. Unused
Status Codes can be dragged and dropped to the Used Status Codes pane, and vice
versa.
When using the CLI, status codes are entered using the format:
eqcli-hc-HTT*> stat_codes hc_state:value
where:
hc_state - up or down.
value - a number or range of numbers - 3 digit numerical value.
For example, you could enter a status code as follows:
eqcli-hc-HTT*> stat_codes up:200-226,301
This would result in the UP status codes specified as 200-226 as well as 301.
558
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Authentication
GUI Parameter
(CLI Parameter)
Description
Authentication
(auth)
The HTTP/HTTPS Authentication mechanism.
None: No authentication is to be included in requests.
Basic: A client request to servers includes the user name and password as unencrypted
base64 encoded text in an "Authorization" request header. Basic authentication is typically
used with HTTPS, since a password can be easily captured and reused over HTTP. The
encrypted authentication is sent to servers in the format "username:password".
Username
(user)
User name for HTTP authentication.
Password
(pw)
Password for HTTP authentication.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
559
Health Checks
Configuring HTTP and HTTPS Application Health Checks using the CLI
Configure the Basic Health Check
Basic health check configuration includes the creation of the health check object and entering the
Target Object Parameters and the URL information.
Throughout these procedures, we’ll also be configuring an actual health check example.
Create the health check as follows:
1. Log in to the CLI.
2. Create a new health check using the following format:
eqcli > health_check health_check_name type http url http://host_name/absolute_path
where:
health_check_name - is the name of the health check.
url - is the target of the HTTP or HTTPS request. An absolute_path can be entered
which refers to the path and the resource on the host. For example, you could enter
www.website.com/mypath/mypathfle.html. This means that you are attempting to
probe mypathfile.html in the mypath directory on your host www.website.com.At a
minimum, you must enter a "/" character following the URL host name as an absolute
path.
You could also use a wild card character “*”. in the host part of the URL. When you do
this, the host header will be populated with either the Target Object IP address (ip)
entered in the health check configuration or the attached object. This depends on if
you select the Use Parent Parameters (access_parms) option. (See "Use Parent
Parameters " on page 556)
You could similarly create an HTTPS health check by using https as the type and
https in the server URL. For example:
eqcli > health_check health_check_name type https https_url/host_name/absolute_path
Let’s create a health check example called “HTTP_Example”.
eqcli > health_check HTTP_Example type http url http://10.0.0.135/
eqcli: 12000287: Operation successful
eqcli >
560
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
3. Configure access_parms. If this option is set to parent, this indicates that any access
parameters needed for the health check probe that are not available in the health check
definition will be taken from the object to which the health check is attached. The ip is the
IP address of the server. Let’s configure this on the example:
eqcli > health_check HTTP_Example access_parms parent
eqcli: 12000287: Operation successful
eqcli >
Specify the Method
4. After creating the health check, enter a Method. The Method tells the server what to do with
the data identified by the URL. Available selections are GET , POST , and HEAD. For our
example:
eqcli > health_check HTTP_Example http_method GET
eqcli: 12000287: Operation successful
eqcli >
Specify Send/Receive Data
5. If using the POST method, you’ll need to enter send_data. This is the message body to be
sent following the headers. When entering in the CLI, you can enter either edit, which
invokes an editor to enter the data, or a url, which fetches the send data from the entered
fully qualified ftp/http site or from the file store with the path to the data file starting with
file://'. For example:
eqcli hc-hcname*> send_data http://172.16.6.1/runscipt.cgi
eqcli hc-hcname*> send_data ftp://120.0.0.1/file.html
eqcli hc-hcname*> send_data http://www.website.com/files/file.html
eqcli hc-hcname*> send_data edit(Refer to "Editing Files" on page 1002)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
561
Health Checks
6. Enter recv_data. recv_data is a string that must be present in the data returned by the
server in order for the health check to be considered UP. This is checked if the returned
status code indicates that the health check is probing UP. When entering, you can enter
either edit, which invokes an editor to enter data or url, which fetches the recv_data
from the fully qualified ftp/http site or from the file store with the path to the data files
starting with “file://”. For example:
eqcli hc-hcname*> recv_data file://muyfile.html
eqcli hc-hcname*> recv_data ftp://120.0.0.1/myfile.html
eqcli hc-hcname*> recv_data http://www.coyote.com/files/myfile.html
eqcli hc-hcname*> recv_data edit (Refer to "Editing Files" on page 1002)
Specify Send Header Information
In many cases, specific header information is required by the application(s) running on a server.
For this purpose, you can enter any specific header details as required by these servers. The
send_hdr parameters are header specifics that are sent as part of the HTTP request. Up to 10
headers can be specified.
Note -CR and LF characters are automatically inserted by the ADC at the end of the header lines.
7. Enter Send Header parameters using the following format:
eqcli hc-hcname*> send_hdr {new|all|num} mode edit
where:
new - adds a new header at the end of the current set of headers.
all - indicates that all existing headers should be edited simultaneously. mode must
be edit.
num - is a number from 0 - 9 to edit an existing header. mode must be edit.
mode can be :
edit - invokes the editor to enter a send header or set of send headers.
url - fetches the send header from the entered fully qualified ftp/http
site or from the file store with the path to the data file starting with
file://'. Each "name:value" string may contain a maximum of 1024
characters.
562
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
For our example, we’ll configure 6 send headers using the file editor. They are as
follows:
Send Header 0 : Cookie: a1=71800; a1v=
Send Header 1 : Accept-Language: en-US,en;q=0.8
Send Header 2 : Accept-Encoding: gzip, deflate, sdch
Send Header 3 : Connection: keep-alive
Send Header 4 : Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Send Header 5 : User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36
Note - It is highly recommended that you refer to RFC7230 and have a thorough understanding of the various header
fields in HTTP 1.1 and that you are familiar with the applications and the request header requirements for the
applications running on the web servers being probed.
Specify UP/DOWN Status Codes
Configure UP/DOWN Status codes in the health check to determine if a returned status code
indicates that a server is UP or DOWN.
8. Enter Status Codes( stat_codes). HTTP status codes are returned by servers to describe if
and how a request was processed. The status code is a three-digit integer. The first digit
identifies the general category of the response. For example, 1xx indicates an informational
message only, 2xx indicates success of some kind, 3xx redirects the client to another URL
4xx indicates an error on the client's part, and 5xx indicates a server error.
The entered value must consist of either the word "up" or the word "down", followed by a
":", followed by one or more comma-separated values or value ranges. The up/down term
describes whether the health check should be considered UP or DOWN if any of the status
codes are received.
For our example, we’ll create UP status codes using a range of status codes (200-226)
and a single status code (301):
eqcli > health_check HTTP_Example stat_codes up:200-226,301
eqcli: 12000287: Operation successful
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
563
Health Checks
Specify the Type of Authentication Used
9. Set the HTTP/HTTPS authentication mechanism. When none is selected, no authentication is
to be included in requests. http_basic authentication is typically used with HTTPS, since a
password can be easily captured and reused over HTTP. When using http_basic
authentication, the client sends the entered User Name and Password as unencrypted text in
the request. Decrypted, the authentication would be in the "username:password" format. If
using the default None, no User Name or Password will be used in the request. For our
example, we’ll use basic authentication:
eqcli > health_check HTTP_Example auth http_basic
eqcli: 12000287: Operation successful
eqcli >
10. If using http_basic, enter a username (user) and password (pw). For our example we’ll
create authentication as follows:
eqcli > health_check HTTP_Example user testuser
eqcli: 12000287: Operation successful
eqcli >
eqcli > health_check HTTP_Example pw testuser
eqcli: 12000287: Operation successful
eqcli >
Specify Health Check Timers and Intervals
11. Configure the health check timers and intervals using "Health Check Timeouts" on page 609
as reference. Use the format:
eqcli-hc-hcname> parameter value
where:
parameter is the timeout or interval.
value is the length of time.
We’ll use the defaults for our example.
564
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Review the Health Check
12. Review the health check parameters using the show command. Here is what our example
health check looks like. Note the if the health check is not attached to an object, a
notification will appear as shown below:
eqcli > show health_check HTTP_Example
This health check has a problem:
Health check is not attached to any object
Health Check Name
: HTTP_Example
Type
: http
Access Parameter
: parent
IP
:
Port
: 0
Probe Interval
: 15
Max Tries/Interval
: 3
Global Timeout
: 5
Connection Timeout
: 1
Data Timeout
: 2
Recv Data
:
Flags
:
HTTP Method
: GET
URL
: http://10.0.0.135/
Health Check Status Codes : up:200-226,301
Authentication
: http_basic
Username
: testuser
Password
: testuser
Send Header 0
: Cookie: a1=71800; a1v=
Send Header 1
: Accept-Language: en-US,en;q=0.8
Send Header 2
: Accept-Encoding: gzip, deflate, sdch
Send Header 3
: Connection: keep-alive
Send Header 4
: Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Send Header 5
: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac
OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89
Safari/537.36
eqcli >
Additional information on using the health check CLI commands can be found in"Health Check
Commands" on page 217.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
565
Health Checks
Configuring HTTP and HTTP Application Health Checks using the GUI
Basic Health Check Configuration
Basic health check configuration includes the creation of the health check, the Target Object
Parameters, and Send and Receive information.
Throughout these procedures, we’ll also be configuring an actual health check example.
1. Log in to the GUI.
2. Click on the Load Balance configuration tab.
3. Do either of the following to display the Add Health Check form:
a. Right click on the Health Checks branch on the left navigational pane and select
Add Health Check.
b. Select the Health Checks branch on the left navigational pane to display the list of
configured health checks on the right configuration pane. Click on the
+ icon.
4. We’ll create an example health check called “HTTP_Example”. Enter a name in the Health
Check Name box and select HTTP or HTTPS from the drop down list. Click on Commit to save
the health check.
The Configuration > Basic tab will be displayed as shown below.
566
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
5. Configure Target Object Parameters. If this option is set to Use Parent Parameters, this indicates
that any access parameters needed for the health check probe that are not available in the
health check definition will be taken from the object to which the health check is attached.
The Target Object IP is the IP address of the health check target. If this option not selected,
and some or all of the required probe parameters are missing, then the health check will be
marked as incomplete unless parameters are entered.
In our example, we’ll enable the User Parent Parameters option.
6. Enter a URL. This is the target of the HTTP or HTTPS request. An absolute path can be
entered which refers to the path and the resource on the host. For example, you could enter
www.website.com/mypath/mypathfle.html. This means that you are attempting to probe
mypathfile.html in the mypath directory on your host www.website.com. You must enter a "/"
character at the end of URL address at a minimum when no absolute path is entered.
You could also use a wild card character “*”. in the host part of the URL. When you do this,
the host header will be populated with either the Target Object IP address entered in the
health check configuration or the attached object. This depends on if you select the Use
Parent Parameters option. (See "Use Parent Parameters " on page 556)
For our example, we’ve used “http://10.0.0.135/”
Specify the Method
7. After creating the health check, enter a Method as follows. The Method tells the server what
to do with the data identified by the URL. Select an HTTP Method using the drop down list.
Available selections are GET , POST , and HEAD. (Refer to "Configuring HTTP and HTTPS
Application Health Checks" on page 554). GET is the default.
If you select POST , a POST Data entry box will be displayed. Enter POST Data in the
space provided. This is the data to be sent after a connection is made. For
HTTP/HTTPS this is the message body and available only when POST is selected as the
HTTP Method.
Specify Send/Receive Data
8. Receive Data is an optional field of an expected receive string for the HTTP/HTTPS health
check. The received response is only checked against the Receive Data string if the returned
status code falls within the set of status codes configured as UP (or not within the set of
status codes defined as failure). If the configured Receive Data is found within the first 1024
bytes of the received response, the servers are marked UP. If this field is left blank and the
status code returned indicates UP, the server will be considered UP.
9. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.Click on Commit to save the parameters.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
567
Health Checks
Specify Send Header Strings
In many cases, specific header information is required by the application(s) running on a server.
For this purpose, you can enter any specific header details to enable communications with these
servers. Send header parameters are HTTP/HTTPS headers that are added to the request.
10. Select the Headers tab to display the following. If a required header field is not included with
the health check, a connection will not be made.
a. Click on the + icon to add a new header field.
b. Select a header field from the drop down list. Note that all headers are
supported and these are provided for convenience. If you require a header not
in the drop down list, , proceed to Step 11 and enter a Custom header.
c. Enter header details in the space provided. It is not necessary to enter CR or LF
characters at the end of the header string as the ADC will insert them
automatically.
d. Click on the + icon to add another header field.
Note - It is highly recommended that you refer to RFC7230 and have a thorough understanding of the various header
fields in HTTP 1.1 and that you are familiar with the applications and the request header requirements for the
applications running on the web servers being probed.
For our example we’ve entered the following headers:
11. If entering a Custom header:
a. Click on the + icon to add a new header field.
b. Select Custom from the drop down list. An entry box will appear under Custom
when selected.
c. Enter a name for the Custom header in the space provided.
d. Enter header details in the space provided.
12. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.Click on Commit to save the headers.
568
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Specify UP/DOWN Status Codes
Configure UP/DOWN Status codes in the health check to specify when a returned status code
indicates that a server is UP or DOWN.
13. Select the Status Codes tab. HTTP status codes are returned by servers to describe if and how
a request was processed. The screen shown below is used to enter the Status Codes
received from servers that will determine UP or DOWN status. The list will change when you
use the option buttons to select UP Status Codes or DOWN Status Codes.
A status code is a three-digit integer. The first digit identifies the general category of
the response. for example, 1xx indicates an informational message only, 2xx
indicates success of some kind, 3xx redirects the client to another URL 4xx indicates
an error on the client's part, and 5xx indicates a server error.
Drag and drop Status Codes from the Unused Status Codes list on the right to the
UP or DOWN Status code area on the right. For our example, we’ll create UP status
code 200-226 and 301 as follows:
14. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.Click on Commit to save the Status Codes.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
569
Health Checks
Specify the Type of Authentication to Use
Set the HTTP/HTTPS authentication mechanism. When none is selected, no authentication is to be
included in requests. basic authentication is typically used with HTTPS, since a password can be
easily captured and reused over HTTP. When using basic authentication, the client sends the
entered User Name and Password as unencrypted text in the request. Decrypted, the
authentication would be in the "username:password" format. If using the default None, no User
Name or Password will be used in the request.
15. Select the Authentication tab. Select either None or Basic from the Authentication drop down list.
When using Basic authentication, the client sends the entered User Name and Password as
unencrypted text in the request. If using None, no User Name or Password will be used in the
request. For our example, we’ll use Basic Authentication and enter a User Name of “testuser”
and a Password.”testuser”.
16. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.Click on Commit to save the Authentication.
570
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Specify Health Check Timers and Intervals
Configure the health check timers and intervals.
17. Click on the Timers tab to access the health check timers. Configure the health check timers
and intervals using "Configuring HTTP and HTTPS Application Health Checks" on page 572 as
reference. We’ll use the defaults for in our example.
18. Click on the Reset button to remove anything that you've entered and return the screen to
the default display.Click on Commit to save the Timers.
Review the Health Check
19. Review the health check by selecting Load Balance > Health Checks > HTTP_Example on the left
navigational pane and the clicking on each of the tabs on the right configuration pane.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
571
Health Checks
Health Check Timers and Intervals
GUI (CLI)
Parameter
Description
Minimum
Default
Maximum
Units
Max Tries Per
Interval
(max_tries)
The maximum number of times per
Probe Interval that Equalizer will
attempt to probe an object.
It is recommended that this parameter
be set to 3 or greater in configurations
where a physical server appears in
multiple server pools.
>1
3
30
integer
Probe Interval
(probe_
interval)
A timer specifying the length of time (in
seconds) during which a successful
server probe must occur, or the server
is marked DOWN.
1
15
60
seconds
Probe Global
Timeout
(probe_gto)
This is the time in seconds that the ADC
waits for a response from the health
check probe before marking the server
DOWN.
0
5
120
seconds
Probe Connect
Timeout
(probe_cto)
The health check connection timeout.
The number of seconds that Equalizer
will wait for a connection attempt to the
health check server application to
succeed before marking the object UP or
DOWN.
0
1
60
seconds
Probe Data
Timeout
(probe_dto)
The health check data timeout. Once a
connection is established, this
parameter indicates the number of
seconds Equalizer will wait for the first
byte of the health check server
application response before marking the
object DOWN.
0
2
60
seconds
Checking the Status of HTTP and HTTPS Application Health Checks
The status of HTTP and HTTPS health checks can be viewed using either the CLI or the GUI. Refer
to "Displaying Configured Health Checks" on page 597 for examples.
Now that you’ve configured an HTTP/HTTPS health check, refer to "Attaching Health Checks to
Load Balancing Objects" on page 591 for information on using the health check with servers,
server pools, and server instances.
572
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring VLB Health Checks
All Equalizers support basic load balancing of VMware servers through VMware vConsole
integration. Equalizer uses VMware's management API to retrieve real-time virtual server
performance information from a VMware vCenter console that manages virtual machines running
on ESX Server (or from a single ESX Server directly). The additional server availability and
resource utilization information obtained from VMware allows Equalizer to more efficiently direct
the traffic flowing to VMware virtual machines.
VLB health checks can be configured on server pools only.
Messages will appear in the Equalizer log (on the global Logging > Event Log tab) when Equalizer
communicates with VMware, and when the state of a VM server changes. Otherwise, VLB works
behind the scenes to provide accurate and detailed VM server status information that Equalizer
uses to make well-informed load balancing decisions.
VLB health checks can be disabled either globally or by attached health check using either the CLI
or the GUI. Refer to"Disabling Health Checks" on page 602 for procedures.
The basic process for configuring a VLB health check is as follows:
1. Create a VLB Manager as an External Service.
2. Associate a server with a Virtual Machine on VMware.
3. Create the health check
4. Configure VLB health check parameters.
5. Attach the health check.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
573
Health Checks
Parameters
The table below describes the VLB health check parameters that are used in the configuration
process.
Further descriptions about the health check timers and intervals and how they work together are
provided in "Health Check Timeouts" on page 609.
VLB Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Target Object Parameters
The Use Parent Parameters flag in the GUI (same as the
access_parms parameter in the CLI) determines
where we obtain the IP address and port to use for the
health check:
l
If Use Parent Parameters is enabled (or set to
parent in the CLI), then if either the IP address
or port is not specified in the health check, they
will be taken from the attached object (the
“parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set to
self in the CLI), then the IP address and port
must be specified in the health check.
If any of the above parameters cannot be determined from
either the health check or the attached object, the GUI and
CLI will report that the health check configuration is
incomplete.
VLB Manager
(vlb_mgr)
Sets the VLB Manager for the health check.
UUID
(vlb_uuid)
Universally Unique Identifier (UUID) Sets the VLB UUID for
a target server.
VM Resource to Check
Options are vm_cpu or vm_ram.
VLB Parameter
(vlb_param)
vm_cpu: Selects the CPU load value for monitoring
vm_ram: Selects the RAM usage value for monitoring.
Health Check Timers
Probe Interval
(probe_interval)
The number of seconds (default: 15 ) Equalizer will wait
for a health check attempt to succeed before marking a
server down.
Max Tries per Interval
(probe_maxtries)
The maximum number of health check connection
attempts per probe interval before marking a server down.
(default: 3) It is recommended that this parameter be set
to 3 or greater in configurations where a physical server
appears in multiple server pools.
574
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
GUI Parameter (CLI Parameter)
Description
Flags
Disable
(disable)
Disables the health check on a global level.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
575
Health Checks
Configuring VLB Health Checks Using the CLI
Configure a VLB health check using the CLI as follows:
Create a VLB Manager as an External Service
1. Log in to the CLI.
2. A VLB Manager is a saved configuration by which Equalizer communicates with VMware.
Enter the following command at the eqcli eqcli prompt to create a VLB Manager as an
External Service:
eqcli > ext_services vlb_manager <name>
where:
name - is the name of the vlb manager
3. Enter the new VLB Manager, adding a URL, username, password, Connect Timeout
parameters and flags. Enter:
eqcli
eqcli
eqcli
eqcli
xs
xs
xs
xs
vlb-nam*
vlb-nam*
vlb-nam*
vlb-nam*
>
>
>
>
URL value
username name
password name
flags disablea
a. The only flag used is disable which would disable the VLB Manager if necessary.
4. Enter the following to verify the new VLB Manager and parameters. In the example below, a
VLB manager “esxi-01” is created.
eqcli > ext_services vlb_manager esxi-01
eqcli xs-vlb-esx*> show
VLB Manager Name : esxi-01
URL : https://192.168.213.196/sdk
Username : root
Timeout : 0
Flags :
Note - For security reasons, a Password value is not displayed.
576
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Associate a Equalizer server with a Virtual Machine on VMware
5. Show the configured server by entering the server context and then entering:
eqcli > server server_name show
where
server_name - is the name of the server. An example with a server “centos216” is
shown below.
This server is enabled.
Server Name : centos216
IP Address : 192.168.213.216
Port : 22
Protocol : tcp
VID : 1
Max Reuse Connections : 0
Reuse Connections Timeout : 0
VLB Manager :
UUID :
Flags : probe_l3
6. Enter the server context and set the vlb_manager value by entering the following. In this
example the vlb_manager is “esxi-01” on a server “centos216”:
eqcli sv-cen*> vlb_manager esxi-01
eqcli sv-cen*> commit
eqcli: 12000287: Operation successful
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
577
Health Checks
Create a Health Check object
7. The next step is to create a VLB health check. Use the following format:
eqcli > health_check health_check_name type vlb
where:
health_check_name - is the name of the health check
For example:
eqcli > health_check VLB_Test type vlb
eqcli > show health_check VLB_test
Health Check Name
Type
Access Parameter
VLB Manager
VM UUID
VLB Parameter
Probe Interval
Max Tries/Interval
Flags
eqcli >
:
:
:
:
:
:
:
:
:
VLB_Test
vlb
parent
esxi-01
vm_cpu
15
3
By default, the access_parm parameter will be enabled so that the parameters of the
VM will be inherited.
578
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configure additional health check parameters
8. Configure additional VLB health check parameters using the "Configuring VLB Health
Checks" on page 574 table above as reference. Refer to "Health Check Commands" on page
217 for additional information on entering parameters. Use the format:
eqcli > health_check healthcheckname parameter_name value [...]
where:
healthcheckname - is the name of the health check.
parameter_name and value [...] are health check parameters that can be found on
the "Configuring VLB Health Checks" on page 574 table above.
Attach the health check to a server pool
9. Attach the VLB health check to a server pool. Refer to "Attaching Health Checks to Load
Balancing Objects" on page 591"Attaching Health Checks to Load Balancing Objects" on page
591for instructions.
Additional information on using the health check CLI commands can be found in "Health Check
Commands" on page 217.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
579
Health Checks
Configuring VLB Health Checks Using the GUI
Configure a VLB health check using the GUI as follows:
Create a VLB Manager as an External Service
A VLB Manager is a saved configuration by which Equalizer communicates with VMware.
1. Click on
+ on the right configuration pane to add a VLB Manager.The figure below will be
displayed. The screen features accordion panes for the existing and the VLB managers that
are labeled. Clicking on the delete icon will delete the health check whose accordion pane is
currently open.
2. Log in to the GUI.
3. Select the System > External Services > VLB Manager on the left navigational pane.
4. Enter a URL for the VLB Manager you would like to connect with in the VLB Manager URL field.
Add Username/Password credentials for login as well.
5. Click on Commit to continue.
580
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Associate a Server with a Virtual Machine on VMware
6. Associate an Equalizer server with a Virtual Machine on VMware by selecting the desired
Equalizer Server on the left navigational pane and then selecting Configuration > VLB to display
the figure below.
The VLB Manager drop-down list lists all the VLB managers defined in the External
Services context. [Default None] Select a VLB Manager from the drop-down list above
and click Get VMList. The figure below will be displayed.
The pop up contains the list of the Virtual Machines (VMs) retrieved from the VLB
Manager. The VM with the matching IP address (if found) is pre-chosen (highlighted)
in the list. Click on Select to select the pre-highlighted VM, or choose another before
clicking Select.
The tab is then redisplayed with the Virtual Server ID of the selected VM.
7. Click on Commit to save the setting.
Note - If getting the VM list from the VLB Manager fails, an Error popup is displayed with the message: “Failed to
associate virtual server on VLB manager <name>.” plus the detailed message returned from VMware.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
581
Health Checks
Create the Health Check
8. Log in to the GUI.
9. Click on the Load Balance configuration tab.
10. Do either of the following to display the Add Health Check form:
a. Right click on the Health Checks branch and select Add Health Check.
b. Select the Health Checks branch on the left navigational pane to display the list of
configured health checks on the right configuration pane. Click on the
+ icon.
11. Enter a name in the Health Check Name box and select VLBfrom the drop down list.
12. Click on the Commit button to save the health check. The Configuration > Settings screen will
appear on the right configuration pane.
By default, the Use Parent Parameters option will be enabled so that he parameters of the
VM will be inherited
582
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Select a VLB Manager and UUID for the Health Check
13. Click on the VLB health check on the left navigational pane to display the configuration
screen on the right.
14. Click on the VLB Manager drop down list and select a VLB Manager to use for this health
check. The associated UUID will be displayed when a selection is made. Clicking on the
Reset button will remove anything that you've entered and return the screen to the default
display
15. Click on Commit. to save the health check.
Configure additional VLB health check parameters
16. Configure additional VLB parameters using the VLB Health Check Parameters table above
as reference.
Attach the health check to a server pool
17. Attach the VLB health check to a server pool. "Attaching Health Checks to Load Balancing
Objects" on page 591 for instructions.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
583
Health Checks
Configuring Server Agent Health Checks
A Server Agent health check is a "load check" health check that provides a load measurement
(response) to indicate a server's UP/DOWN status. It is used with server pools.
A user-supplied "server agent" must be running at the target, which supplies a load value in
response to a query from Equalizer. This information is obtained by the server agent by any
means available at the target server. For example, if supported by the target, the server agent
program could check current CPU or memory allocation to determine a load value.The only
requirement from Equalizer's perspective is that the server agent's response must be in the form
of a single integer or floating point value. The server agent may either return the load value
immediately upon accepting a connection on the configured port, or it may require a stimulus
string before returning the value. After returning the value, the server agent closes the connection
and waits for another connection.
Server Agent health checks can be disabled either globally or by attached health check using
either the CLI or the GUI. Refer to "Disabling Health Checks" on page 602 for procedures.
Server Agents
A server agent is a custom written application that runs on a server and listens on a specific port
(default: 1510). When a connection request is received on that port, the server agent returns an
integer value between -1 and 100 that indicates the relative load on the server (-1 meaning the
server should be considered unavailable, 0 meaning very lightly loaded, and 100 meaning heavily
loaded). Server agents can be used with any cluster type, and have an effect on all load balancing
policies except round robin, and static, which ignore server agent return values.
Agent Probe Process
When Equalizer connects to the port on which a server agent is running, it uses the number
returned by the agent in its load balancing calculations, with the server agent policy giving highest
preference to the server agent’s return value over other factors.
The number returned by the agent to Equalizer is intended to indicate the current load on the
server. The agent application that runs on the server can be written in any available scripting or
programming language and can use any appropriate method to determine server load.
Server agents should be running on all server instances in the server pool. However, a server is
not marked DOWN when an agent value is not returned and the attached health check instance
flag is set to Optional .
Sample Server Agent
You can create custom Server Agents as shell scripts, or in Java, Perl, C, or other languages. The
code snippet below is an example of a simple server agent example written in Perl. This code
assumes that an integer response value is supplied on the command line and returns that value
when a connection is made on port 1510 (configurable via the server instance Probe Port (probe_
port) variable).
This sample agent is intended for testing purposes only. In a real deployment, the
server agent would determine the response value to return by polling system
resources, or some other real-time method.
584
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
#!/usr/bin/perl -w
# serveragent.pl
#-------------------#(c) Copyright 2014 Fortinet, Inc.
use strict;
use Socket;
# use port 1510 as default
my $port = 1510;
my $proto = getprotobyname('tcp');
# take the server agent response value from the command line
my $value = shift;
my $response = "$value\n";
# response has to be a valid server agent response
$response==-1 or ($response > 0 and $response<101)
or die "Response must be between -1 and 100";
# create a socket and set the options, set up listen port
socket(SERVER, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, 1) or die "setsock: $!";
my $paddr = sockaddr_in($port, INADDR_ANY);
# bind to the port, then listen on it
bind(SERVER, $paddr) or die "bind: $!";
listen(SERVER, SOMAXCONN) or die "listen: $!";
print "Server agent started on port $port\n";
# accepting a connection
my $client_addr;
while ($client_addr = accept(CLIENT, SERVER)) {
# find out who connected
my ($client_port, $client_ip) = sockaddr_in($client_addr);
my $client_ipnum = inet_ntoa($client_ip);
# print who has connected -- this is for debugging only
print "Connection from: [$client_ipnum]\n";
# send the server agent response value
print CLIENT $response;
# close connection
close CLIENT;
}
Here is the output of the server program when it is started on the server:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
585
Health Checks
$ ./serveragent.pl 50
Server agent started on port 1510
Connection from: [10.0.0.32]
Another “Connection” line prints each time the server agent is probed by Equalizer.
From Equalizer’s perspective, the only value returned by the server agent is the integer set on the
command line. For example, if you use the example server agent above and set the response to
“50”, here is what you will see if you use the telnet command to open the server agent IP and port:
$ telnet 10.0.0.120 1510
50
Connection to host lost.
Parameters
Note - Server Agent health checks work with load balancing policies other than round robin and static. Round
robinand static ignore any agent response for all server instances in a server pool. All other policies use the integer
returned by the agent as one factor in determining the server to which a new request is sent.
The table below describes the Server Agent health check parameters used in the configuration
process.
Further descriptions about the health check timers and intervals and how they work together are
provided in "Health Check Timeouts" on page 609.
Server Agent Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Target Object Parameters
The Use Parent Parameters flag in the GUI (same as
the access_parms parameter in the CLI)
determines where we obtain the IP address and port to
use for the health check:
l
If Use Parent Parameters is enabled (or set to
parent in the CLI), then if either the IP
address or port is not specified in the health
check, they will be taken from the attached
object (the “parent”).
Use Parent Parameters
(access_parms)
l
If Use Parent Parameters is disabled (or set
to self in the CLI), then the IP address and
port must be specified in the health check.
If any of the above parameters cannot be determined
from either the health check or the attached object, the
GUI and CLI will report that the health check
configuration is incomplete.
586
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Agent Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Target Object IP
(ip)
This is the IP address of the health check target.
Port
(port)
This is the port to use for the port number for probing
the server.
Server Agent Parameters
Lightest Load Value
(light_load)
A floating point value that is the ‘healthiest’ (or least
busy) load value that can be returned by the health
check server application. For example: if the application
returns a value of -1 to indicate that it is DOWN, then
set light_load to -1. (default: 0.000000)
Heaviest Load Value
(heavy_load)
A floating point value that is the busiest (or most highly
loaded) load value that can be returned by the health
check server application for the health check. For
example: if the application returns a value of 100 to
indicate that it is very heavily loaded, then set heavy_
load to 100. (default: 100.000000)
Health Check Query
(query)
A string sent to the server agent after a connection is
established. For example: a server agent health check
application may require a string such as get load \r \n
before it will send a load value. This parameter is
optional.
SSL Parameters
Highest Version
(highest_tls_version)
Used when the Use SSL (probe_ssl) option is
enabled. Sets the health check highest TLS version. It
specifies the highest TLS version that will be offered in
the SSL probe sent to servers The probe can use levels
from SSLv3 and the highest probe levels of TLS v1.0,
v1.1, or v1.2. (default: TLS v1.2)
In the CLI, values are used to assign the TLS versions
as follows:
1 = SSL v3
2 = TLS v1
3 = TLS v1.1
4 = TLS v1.2
(Default: 4)
Health Check Timers
Probe Interval
(probe_interval)
The number of seconds (default: 15) Equalizer will
wait for a health check attempt to succeed before
marking a server down.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
587
Health Checks
Server Agent Health Check Parameters
GUI Parameter (CLI Parameter)
Description
Max Tries Per Interval
(probe_maxtries)
The maximum number of health check connection
attempts per probe interval before marking a server
down. (default: 3)
It is recommended that this parameter be set to 3 or
greater in configurations where a physical server
appears in multiple server pools.
Probe Global Timeout
(probe_gto)
The health check global timeout. The number of
seconds (default: 5) Equalizer waits for a connection to
the health check server application to complete before
marking the server down.
Probe Connect Timeout
(probe_cto)
The health check connection timeout. The number of
seconds (default: 1) that Equalizer will wait for a
connection attempt to the health check server
application to succeed before marking the server down.
Probe Data Timeout
(probe_dto)
The health check data timeout. Once a connection is
established, this parameter indicates the number of
seconds (default: 2) Equalizer will wait for the first
byte of the health check server application response
before marking the server down.
Flags
Disable
(disable)
Disables the health check on a global level.
Use SSL
(probe_ssl)
If enabled, the probe exchange between Equalizer and
a server instance will be performed over an encrypted
SSL connection. The Highest Version drop down list
will display a list of the highest TLS version to use.
(default: Enabled )
Configuring Server Agent Health Checks Using the CLI
1. Log in to the CLI.
2. Create a new Server Agegnt health check using the the following format:
eqcli > health_check health_check_name type srvagt parameter_name value [...]
where:
health_check_name - is the name of the health check.
parameter_name and value - is the health check parameter and the value assigned
to it. Refer to Server Agent Health Check Parameters table above.
For example:
588
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
eqcli > health_check ServerAgent_test type srvagt ip 1.3.55.3 query
#@#^&#@ flags probe_ssl
eqcli: 12000287: Operation successful
eqcli > show health_check ServerAgent_test
Health Check Name
: ServerAgent_test
Type
: srvagt
Access Parameter
: parent
IP
: 1.3.55.3
Port
: 1510
Light Load
: 0
Heavy Load
: 100
Probe Interval
: 15
Max Tries/Interval
: 3
Global Timeout
: 5
Connection Timeout
: 1
Data Timeout
: 2
Highest TLS Version : 4
Query
: #@#^&#@
Flags
: probe_ssl
eqcli >
3. Enter additional parameter_names and values described in the Server Agent Health Check
Parameters table above.
Additional information on using the health check CLI commands can be found in "Health Check
Commands" on page 217.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
589
Health Checks
Configuring Server Agent Health Checks Using the GUI
5. Modify the Server Agent probe parameter shown in the Server Agent Health Check
Parameters table above as necessary.
6. Click on Commit .
Refer to "Attaching Health Checks to Load Balancing Objects" on page 591 for instructions on
attaching the health check.
590
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Attaching Health Checks to Load Balancing Objects
Health checks can be attached to Servers, Server Pools, Server Instances and LLB Gateways
using either the CLI or the GUI.
Each attached health check features an Optional option. This is typically used when multiple health
checks are attached to an object. For example, if you have an ACV and a VLB health check
attached to a server pool, and one of the health checks on a particular server instance probes
DOWN, the server instance will be marked DOWN. If the Optional flag is enabled on the attached
health check, and the other attached health check is NOT failing, the server instance will be
marked UP.
Each attached health check also features a Disable option. Enabling this option will disable the
attached health check only, and NOT the configured health check that may be attached with other
load balancing objects.
You must have previously created the health check or use one of the default health checks (See
"System Health Checks" on page 531).
Attaching a Health Check using the CLI
Enter the following in the CLI in the global context. Use a configured health check or one of the
system health checks:
eqcli > object objectname hc healthcheckname
where:
objectname - is the name of the object.
healthcheckname - is the name of the configured health check.
For example:
eqcli > srvpool srvpool1 hc icmp
Name
Flags
ICMP
disable, optional
eqcli >
Additional information on using the health check CLI commands can be found in the "Health Check
Commands" on page 217.
Displaying an Attached Health Check using the CLI
You can display the attached health check by using the following format:
eqcli > show object objectname hchealthcheckname
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
591
Health Checks
where:
objectname - is the name of the object.
healthcheckname - is the name of the health check.
For example, the following is an example of a CLI display with the health checks attached to a
server instance (srv1) in a server pool (srvpool1):
eqcli > show srvpool srvpool1 si srv1 hc
Name
Test_TCP
TestICMP
Flags
disable, optional
eqcli >
Note - Attached ACV and TCP Health Check displays are different. Refer to "Attached
Checks and the Test Function" on page 595.
592
ACV and TCP Health
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Attaching a Health Check using the GUI
1. Click on the Load Balance configuration tab on the left navigational pane on the GUI. If you
want to attach an ICMP health check to an LLB Gateway, select the Link Load Balance
configuration tab, expand the Outbound branch and select a configured LLB Gateway.
Perform either step 2 or step 3.
2. Do the following to use the drag and drop functionality:
a. Select either Servers, Server Pools, a Server Instance, or an Outbound Gateway from
the left navigational pane. Right click on the Health Checks branch of the object
and select Add Health Check.
b. From the Health Checks branch on the left navigational pane, select a
configured health check and drag and drop it on a Server, Server Pool, Server
Instance, or Outbound Gateway.
c. Click on Commit to attach the selected health check(s). It should appear on the
object's Health Checks branch on the left navigational pane.
3. Do the following to attach a health check using the summary screen:
a. Click on the object's Health Checks branch on the left navigational pane to display
the Health Checks Summary screen on the right.
b. Click on + to display a pop up list of configured health checks. The health
checks listed are available, yet NOT attached to the object select
c. Using the check boxes, select one more of the health checks from the Attach
Health Check screen.
d. Click on Commit to attach the selected health check(s). It should appear on the
object's Health Checks branch on the left navigational pane and also in the
summary screen.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
593
Health Checks
Displaying an Attached Health Check in the GUI
After you attach the health checks to the load balancing objects you can be view the Attached Health
Check screen on the GUI by selecting Load Balance > [object] > [object] Health Checks and then selecting
the health check on the left navigational pane. When a health check is selected, its "instance" is
displayed on the right configuration pane. An example of an ICMP Attached Health Check is displayed
as follows:
The attached Health Check screen can be used to:
l
l
Disable the health check for the object (not globally)
Set an Optional flag, where if the health check returns a DOWN response, servers will not be
marked DOWN if other attached health checks return UP responses.
Click on Commit to save your selections or Reset to remove any changes.
Note - Attached ACV and TCP Health Check screens are different. Refer to "Attached
Checks and the Test Function" on page 595.
594
ACV and TCP Health
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Attached ACV and TCP Health Checks and the Test Function
In addition to the Disable and Optional attached health check options, attached ACV and TCP health
checks feature a test feature. The ACV Test feature utilizes the query and response strings
configured in the health check to check the UP/DOWN status of the selected server, or servers,
where server instances are configured in the server pool. The TCP Test feature probes the server
instance selected and returns UP/DOWN status of the server.
This feature is available on health checks attached to Server Pools or Server Instances.
Using the ACV and TCP Health Check Instance Test Feature in the CLI
When a health check is attached to a server pool, the server name can be specified after test in
the CLI syntax. This represents a server instance. If a server name is specified, only that server
instance on the server pool will be tested. If no server name is specified, all server instances will
be tested.
The following is an example of an attached ACV health check:
eqcli sp-srv*> show hc ACV
This health check instance is enabled.
Health Check Name : ACV
Flags
: optional
Server Instance HC Status
srv1
Up
eqcli sp-srv*>
When a health check is attached to a server instance in a server pool, the server name does not
need to be entered as the test will be performed on the server instance to which it is attached.
To use the ACV and TCP Test feature in the CLI enter the following.
eqcli > sp-srv*-hc-nam*> test server_name
where:
server_name - is the name of the server to which the health check is attached.
If the health check is attached to a server instance, the test command would be used in the
health check context for the server instance.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
595
Health Checks
Using the ACV and TCP Health Check Instance Test Feature in the GUI
Select an attached ACV or TCP health check instance on the left navigational pane on the GUI. The
health check instance Configuration Settings screen will be displayed on the right configuration pane.
If an ACV or TCP health check is attached to a server pool, use the Test This Server drop down list to
select a server instance or all of the server instances on the server pool.. Click on the Test button
to begin the test.
If an ACV health check is attached to a server instance, the Test button only will be available as
the test will be performed on the server instance to which it is attached.
A result pop up will be displayed upon completion of the test that displays the status of the
selected server(s).
Click on Commit to save your selections or Reset to remove any changes.
596
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying Configured Health Checks
All of your configured ICMP, TCP, UDP, ACV, Server Agent, VLB, and HTTP and HTTPS Application
health checks and their status can be displayed either globally or on the objects to which they are
attached using either the CLI or the GUI.
Viewing All Configured Health Checks using the CLI
To view the status of all of the configured health checks on the ADC using the CLI enter the
following :
eqcli > show health_check
Name
Type
ICMP-Default
TCP-Default
UDP-Default
ACV
ICMP
Server_Agent
VLB
icmp_test
TCP_test
ServerAgent_test
HTTP_Example
eqcli >
icmp
tcp
udp
acv
icmp
srvagt
vlb
icmp
tcp
srvagt
http
IP
N/A
1.3.5.7
2.5.7.9
1.3.55.3
Status
In
In
-In
In
In
----In
Use
Use
Use
Use
Use
Use
where:
Name - is the name that you assigned to the health check
Type - is the type of health check (i.e., icmp, vlb,acv)
IP- is the IP address of the object being queried, if it is specified in the health check
configuration..
Status - is the status of the health check. Options are:
incomplete - indicates that the health check has been created, however
it is missing parameters such as ip or port.
disabled, attached - indicates that the health check has been globally
disabled, however, a health check instance is attached to a load balancing
object.
disabled -indicates that the health check is globally disabled. All
attached health check instances of this health check will also be disabled.
In use - indicates that the health check is configured and one or more
instances of the health check are attached to a load balancing object.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
597
Health Checks
To view all of the ADC’s configured health checks using the GUI:
1. Log in to the GUI.
2. Select the Load Balance configuration tab on the left navigational pane if it is not already
selected.
3. Click on Health Checks on the left navigational pane to expand the branch. This displays all of
the configured health checks. For example:
4. View the configuration summary of all of the ADC’s configured health checks by selecting
Health Check on the left navigational pane. The following will be displayed on the right.
598
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Double clicking on any of the configured health checks will display the health check configuration
screens for each health check, where you can modify it. You can also select the health check and
then click on the
icon.
You can delete a health check by selecting the health check and clicking on the
icon, or
dragging and dropping the health check to the icon.
You can add a new health check from this screen by selecting the +.
Viewing Attached Health Checks using the GUI
Click on any of the Load Balance objects on the tree to expand the branch. All of the health checks
that are attached to the object will be displayed in the object's Health Checks branch. For example:
Displaying the Status of Attached Health Checks using the GUI
Use the instructions that follow to isplay summaries of the attached health checks that indicate
whether they are enabled or disabled and if the the health check is probing UP or DOWN. Select
the object's Health Checks branch in the left navigational pane. The Health Check Summary screen will
appear on the right configuration pane.
The following are examples of health check summary displays for health checks attached to
server pools, server instances, servers, and LLB gateways.
For each of the health check displays described below:
l
The
icon in the Status column indicates that the health check probe is UP.
l
The
icon in the Status column indicates that the health check probe is DOWN.
l
Double click on any of the attached health checks to display the attached health check
screen where you can set the optional and disable flags. You can also select the health
check and then click on the
l
icon.
Delete an attached health check by selecting the attached health check and clicking on the
icon, or dragging and dropping the health check to the icon.
l
Attach a new health check from this screen by selecting the + icon. (Refer to"Attaching
Health Checks to Load Balancing Objects" on page 591 for more information).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
599
Health Checks
Displaying the Status of Attached Server Pool Health Checks
Select Load Balance > Server Pool > Health Checks on the left navigational pane. The following is an
example of the display on the right configuration pane. The + icon in the first column expands to
present the status/load of each health check on each server instance.
Displaying the Status of Attached Server Instance Health Checks
Select Load Balance > Server Pools> Server Instance > [Select a Server Instance] > SI Health Checks on the left
navigational pane. The following is an example of the display on the right configuration pane.
Displaying the Status of Attached Server Health Checks
Select Load Balance > Servers > [Select a Server] > Server Health Checks on the left navigational pane. The
following is an example of the display on the right configuration pane.
600
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Displaying the Status of Attached LLB Gateway Health Checks
Select Link Load Balance > Outbound > Gateways . > [Select a Gateway] > Gateway Health Checks on the left
navigational pane. The following is an example of the display on the right configuration pane:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
601
Health Checks
Disabling Health Checks
By default, all health checks are enabled when a health check instance is added to a server,
server pool, server instance, or LLB Gateway.
Health checks can be disabled by either:
l
l
Disabling a health check attached to a server, server pool, server instance, or LLB Gateway
or
Disabling globally by accessing the health check object and selecting the "disable" option.
You can use the CLI or the GUI to disable health checks.
Disabling Using the CLI
To disable the health check on a global level using the following syntax:
eqcli > health_check health_check_name flags disable
where:
health_check_name - is the name of the health check to globally disable.
For example:
eqcli > health_check ICMP flags disable
eqcli > show health_check ICMP
Health Check Name
: ICMP
Type
: icmp
Access Parameter
: parent
IP
:
Probe Interval
: 15
Max Tries/Interval
: 3
Flags
: disable
eqcli >
602
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
To disable an attached health check enter the following:
eqcli > object object_name hc health_check_name flags disable
where:
object_name - is the name of the load balancing object
health_check_name - is the name of the health check to be globally disabled.
For example:
eqcli > show srvpool srvpool1 hc ICMP flags disable
eqcli: 12000287: Operation successful
eqcli > show srvpool srvpool1 hc ICMP
Attached Health Check is disabled
Health Check Name : ICMP
Flags
: disable
Server Instance
srv1
eqcli >
HC Status
N/A
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
603
Health Checks
Disabling Using the GUI
Disable the health check globally in the GUI as follows:
1. Log in to the GUI.
2. Click on the Load Balance > Health Checks on the left navigational pane.
3. Select a health check to display the Settings screen on the right configuration pane.
4. Select the Disable check box.
5. Click on the Commit button to save the change.
Disable attached health checks in the GUI as follows:
1. Log in to the GUI.
2. If a health check instance is attached to a server, server pool, or server instance, click on
the Load Balance configuration tab on the left navigational pane. If a health check instance is
attached to an LLB Gateway, click on the Link Load Balance tab.
3. On the left navigational pane, expand the branch for the object to display the health check
instance icon.
4. Click on the health check instance to display the Settings display on the right configuration
display.
5. Click on the Disable check box.
6. Click on the Commit button to save the change.
604
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Deleting Health Checks
Health checks can be deleted using the CLI or the GUI. They can be deleted by either:
l
l
Deleting a health check attached to a server, server pool, server instance, or LLB Gateway
or
Deleting the health check object
The ICMP-Default, TCP-Default, or UDP-Default System health checks cannot be deleted.
Delete Using the CLI
To delete an attached health check using the CLI, use the following format:
eqcli > object objectname no health_check healthcheckname
where:
objectname- is the name of the load balancing object to which the health check is
attached.
healthcheckname - is the name of the attached health check.
For example
eqcli > srvpool srvpool1 no health_check TCP_Test
eqcli: 12000287: Operation successful
eqcli >
To delete a health check object using the CLI,
eqcli > no health_check healthcheckname
where:
healthcheckname - is the name of the health check being deleted.
For example:
eqcli > no health_check TCP_Test
eqcli: 12000287: Operation successful
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
605
Health Checks
Delete Using the GUI
Delete a health check using the GUI from either the left navigational pane or the right
configuration pane:
To delete an attached health check:
From the left navigational pane:
1. Select Load Balance > Health Checks.
2. Select a health check that you would like to delete.
3. Right click and select Delete Health Check.
From the Health Checks list on the right configuration pane:
1. Select Load Balance > Health Checks.on the left navigational pane.
2. Select a health check from the list on the right configuration pane.
3. Click on the
icon.
To delete a health check object:
1. Select the load balancing object on the left navigational pane.
From the left navigational pane:
2. Select an attached health check that you would like to delete.
3. Right click and select Delete Health Check.
From the Health Checks list on the right configuration pane:
1. Select an attached health check on the left navigational pane.
2. From the list on the right configuration pane, select the attached health check.
3. Click on the
606
icon.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Probe Coalescing
If two or more attached health checks of the same type have the same probe parameters
described below, they will coalesce into a single probe.
ICMP Health Checks
All ICMP probing occurs at the same frequency, which is the highest frequency needed to satisfy
the highest probe interval/tries combination of all ICMP probes across all objects. If the Target IP
Addresses (ip) of two attached ICMP health checks are the same, they will be combined into a
single probe.
TCP Health Checks
If the Target Object IP (ip) Port (port),Probe Global Timeout (probe_gto), Probe Connect Timeout
(probe_cto), Probe Data Timeout (probe_dto) parameters, and Use SSL (probe_ssl) option of two
attached TCP health checks are the same, they will be combined into a single probe. If the Probe
Interval (probe_interval) and Max Tries per Interval (probe_maxtries) parameters are different,
probing will occur at the highest frequency of all health checks that are being serviced by the
probe.
UDP Health Checks
If the Target Object IP (ip) Port (port), and Probe Global Timeout (probe_gto)parameters of two
attached health checks are the same, they will be combined into a single probe. If the Probe Interval
(probe_interval) and Max Tries per Interval (probe_maxtries) parameters are different, probing
will occur at the highest frequency of all health checks that are being serviced by the probe.
ACV Health Checks
If the Target Object IP (ip) Port (port),Probe Global Timeout (probe_gto), Probe Connect Timeout
(probe_cto), Probe Data Timeout (probe_dto) parameters are the same, the Use SSL (probe_ssl)
option of two attached ACV health checks are the same, and the ACV Query (query) and ACV
Response (response) parameters of the two attached ACV health checks are the same.they will be
combined into a single probe. If the Probe Interval (probe_interval) and Max Tries per Interval
(probe_maxtries) parameters are different, probing will occur at the highest frequency of all
health checks that are being serviced by the probe. .
VLB Health Checks
If the VLB Manager (vlb_mgr) and UUID (vlb_uuid) parameters on two attached VLB health checks
are the same, they will be combined into a single probe. A single probe can access both the VMs
CPU and RAM information, and appropriately manage either CPU or RAM (or both) VLB health
check instances . If the Probe Interval (probe_interval) and Max Tries per Interval (probe_maxtries)
parameters are different, probing will occur at the highest frequency of all health checks that are
being serviced by the probe.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
607
Health Checks
Server Agent Health Checks
If the Target Object IP (ip) Port (port),Probe Global Timeout (probe_gto), Probe Connect Timeout
(probe_cto), Probe Data Timeout (probe_dto) parameters are the same, and the Use SSL (probe_
ssl) option and Health Check Query (query) parameters of the two attached Server Agent health
checks are the same for two attached Server Agent health checks, they will be combined into a
single probe. If the Probe Interval (probe_interval) and Max Tries per Interval (probe_maxtries)
parameters are different, probing will occur at the highest frequency of all health checks that are
being serviced by the probe.
When a single probe probes on behalf of more than one attached health check, an individual
attached health check is marked DOWN according to the interval value associated with it. If the
time stamp on the last good probe has not occurred within the last interval seconds, then the
probe will be marked DOWN. For example, if two TCP health checks attached to two server
instances have the same Target Object IP (ip) Port (port),Probe Global Timeout (probe_gto), Probe
Connect Timeout (probe_cto), Probe Data Timeout (probe_dto) parameters and the Max Tries per
Interval (probe_maxtries) parameter is 3, yet one has probe Probe Interval (probe_interval) of 60
seconds and the other 15 seconds. They will be combined into a single probe that sends a probe
every 5 seconds (Prove interval=15/Max tries per interval =3). If the probe fails, 15 seconds later
one of the two attached health checks will be marked DOWN (because its interval is 15), and 60
seconds after the probe fails, the 2nd attached health check will be marked down (because its
interval is 60).
608
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Health Check Timeouts
Health check timeouts are configured as part of each health check's configuration. The types of
timeouts vary, based on the health check protocol, however, their basic functionality is the same.
Timeouts were discussed previously in the health check configuration parameters. The purpose of
this section is to provide further descriptions for better understanding of how the timeouts and
intervals work with one another.
ICMP Health Check Timeouts
By default, Equalizer sends an Internet Control Message Protocol (ICMP) echo request (commonly
called a “ping”) to the IP address of every configured server object. The timeouts that control
ICMP health check probes are determined by the health check definition.
ICMP Health Check Parameters
(CLI Parameter)
Minimum
Default
Maximum
Units
Max Tries Per Interval(probe_maxtries)
>1
3
30
integer
Probe Interval (probe_interval)
0
15.0
60.0
seconds
By default, ICMP health check probes are sent a maximum of 3 times every 15 seconds to every
configured server that has Layer 3 probes enabled. Within a 15-second probe interval, the delay
between successive ping requests to the same server is determined internally -- it can be as short
as one second to a server that is not responding to ICMP requests and can be 5 seconds or longer
when a server is responding to ICMP echo requests, depending on the amount of traffic that
Equalizer is currently processing.
If a server responds to an ICMP Health Check, it is marked "Layer 3 UP". If a server does not
respond to an ICMP echo request, it will be marked "Layer 3 DOWN" by Equalizer only if the
server has responded to at least one ICMP echo request since Equalizer was last rebooted. This
behavior accounts for the fact that many servers are configured by default to never respond to
ICMP echo requests as a security precaution. In other words, if a server has never responded to a
Layer 3 health check probe since the last reboot, it is never marked "Layer 3 Down".
Note - Responding to ICMP echo requests is an option on most server platforms. If ICMP echo reply is disabled on one
or more of the servers in your configuration, then you may want to disable ICMP echo requests on Equalizer to reduce
traffic between Equalizer and the servers, and rely solely on the other probing mechanisms.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
609
Health Checks
Layer 4 TCP, ACV, and HTTP/HTTPS Health Check Timeouts
By default, Equalizer sends TCP Health Checks to every server instance in a TCP server pool.
Equalizer and the server exchange a three-way TCP handshake to open a TCP connection. If ACV
is also configured, the ACV probe takes place after the TCP connection is established. Once the
handshake is complete and ACV data is optionally exchanged, the probe connection is closed.Once
enabled, TCP and ACV probe behavior is determined by the timeouts determined by the health
check definition.
GUI Parameter (CLI Parameter)
Minimum
Default
Maximum
Units
Max Tries Per Interval (max_tries)
>1
3
30
integer
Probe Interval (probe_interval)
1
15
60
seconds
Probe Global Timeout (probe_gto)
0
5
120
seconds
Probe Connect Timeout (probe_cto)
0
1
60
seconds
Probe Data Timeout (probe_dto)
0
2
60
seconds
By default, Equalizer sends Layer 4 health check probes to a server instance at most 3 times (the
Max Tries Per Interval setting), every 15 seconds (the Probe Interval). Exactly how many probes
are sent in any given probe interval is determined by how long it takes each probe to complete
and whether any of the timeouts listed above expire while Layer 4 health checks are being sent
and received. Both TCP and ACV probes are subject to the same set of timeout values, as
summarized in the following flowchart.
610
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Server Agent and VLB Health Check Timeouts
Server Agent and VLB health checks behave the same as the timeouts for Layer 4 TCP and ACV
health checks in the previous sections, with the exception that the Probe Data Timeout (probe_dto)
is the timeout for the server response for these health checks rather than ACV. This affects only
the part of the flowchart that is outlined in the previous sections.
VLB health checks use the VLB Manager timeout value.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
611
Equalizer Administration Guide
Chapter 17
Automatic Cluster Responders
Note - Responders are not supported on E250GX model Equalizers.
Sections within this chapter include:
Automatic Cluster Resopnder Overview
Responder Summary
Managing Responders
Responder Statistics and Reporting
614
615
616
627
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
613
Automatic Cluster Responders
Automatic Cluster Resopnder Overview
Note -Responders are not supported on E250GX model Equalizers.
A Responder is a server-like object that can be associated with a Match Rule. It provides you with
the ability to cleanly load balance traffic where server pools associated with a cluster are not
available to satisfy a client's request. The feature extends Cluster Match Rules to allow them to
specify a target Responder which is used to provide a response to the client when the server pool
in the match rule is not available. If an incoming request matches a Match Rule expression and
the server pool specified in the Match Rule is down, a Responder definition in the Match Rule (if
present) tells Equalizer to send one of two automatic responses to the client:
l
l
614
A customized HTML “sorry page” that can, for example, ask the client to retry later or go to
another URL.
A standard HTTP Redirect response that specifies a return code and redirect URL. When the
client receives this page, it is automatically redirected to the redirect URL. Redirect pages
can be configured to use parts of the request URL in the HTTP Redirect response (using a
regular expression).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Responder Summary
The Responder Summary screen displays the names of configured responders, Type,associated
Clusters and Match Rules.
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Click on Respondersto display the Responder Summary screen.
+
From this screen you can add a new responder by clicking on " " .
You can delete a server by selecting a responder and clicking on
.
You can modify server configuration by selecting a responder and clicking on
. This will
activate expand the Responders summary screen to include Responder Configuration details
described in "Adding a Responder" on page 616.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
615
Automatic Cluster Responders
Managing Responders
To display a list of all currently defined Responders, select the Load Balance configuration tab on
the left navigational pane and click on the arrow (u) beside Respondersto expand the branch.
Select any of the Responders on the tree to display their configuration on the right pane.
l
l
l
To add a Responder, right click on Responders on the left navigational pane and select Add
Responder.
To edit a Responder’s configuration, click on the specific Responder on the Responder branch
on the navigational pane to display the configuration on the right.
To delete a Responder, click on the specific Responder on the Responder branch on the left
navigational pane and select Delete Responder A Responder cannot be deleted if it is
currently used in a match rule definition.
Adding a Responder
Responders are a “global” resource: once created, they can be individually assigned to one or
more match rules in one or more clusters. Up to 8192 Responders can be created.
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Right click on Responder on the left navigational pane and select Add Responder. The Add New
Responder dialog appears. By default, the form for creating a Redirect Responder is displayed:
2. Type a Name for the Responder or leave the default name provided.
3. Do one of the following:
l
616
Create a custom HTML page by selecting Sorry Server. The dialog changes to a
text entry box, into which you can type the HTML that Equalizer will return to
clients. The text size limit is 4096 bytes.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
l
Create a standard Redirect page by supplying the following information in the
pop up screen:
Status
The HTTP status code to return to the client. The default return code is 307 (Temporary
Redirect). Use the drop-down box to choose a different return code:
301 (Moved Permanently)
302 (Found)
303 (See Other)
The HTTP Redirect URL: the full URL of the page to which the client will be redirected, as in the
following example:
http://www.sitename.com/redirect/redirect.html
URL
If a Regular Expression is used to split the client URL into string variables,
any variables appearing in the URL are replaced with strings from the request
URL. The following is an example of a Redirect URL with named variables:
http://$1.$2.net$3$4
The maximum size of a redirect URL is 1200 characters
See "Using
Regular
Expression
Regular Expressions in Redirect Responders" on page 619.
An optional POSIX-style regular expression that splits the incoming request URL into variables
that can be used for string replacement in the HTTP Redirect URL (see above). See "Using
Regular Expressions in Redirect Responders" on page 619.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
617
Automatic Cluster Responders
When you are done, click on Commit .
4. In the screen that follows, you can optionally test your responder. Do one of the following:
l
For a Sorry Server responder, click the test button to see a preview of the page. Click the
close button to close the preview.
l
l
For a Redirect responder, enter a Test URL (or use the default) and click the test button
to see how the regular expression breaks the test URL into variables for re-use in the
URL you supplied in the previous step.
Click the Next icon (>) at the top of the dialog to skip testing.
5. On the next screen, do one of the following:
l
Click the Back icon (>) at the top of the screen to review the responder configuration.
l
l
For a Sorry Server, click commit to add this responder or cancel to close the dialog
without adding the responder.
For a Redirect responder, this screen displays the responder Redirect URL and the
Regular Expression (if supplied).
If you clicked the test button on the previous screen, the Match Components and
Resulting Redirect produced by matching the Test URL against the Regular Expression are
also displayed (any variables appearing in the Redirect URL are replaced with strings
from the Test URL).
6. Click Commit to add the responder or Cancel to close the dialog without adding the responder.
618
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Modifying a Responder
1. To modify the configuration of an existing Responder, click on a Responder on the Responder
branch of the left navigational pane in the left frame.The Responder’s Configuration tab
appears.
2. Update the Responder configuration as desired; see "Adding a Responder" on page 616 for a
description of all Responder parameters.
3. Click Commit to save your changes.
Using Regular Expressions in Redirect Responders
In some cases, it may be desirable to examine the URL of an incoming request and re-use parts of
it in the URL returned to the client by a Redirect Responder. This is the purpose of the Regex field:
specify a custom regular expression that is used to:
l
l
l
parse the URL of an incoming request
break it down into separate strings (based on the positions of literal characters in the
expression)
assign each string to a named variable
These named variables can then be used in the URL field of the Redirect Responder. When the
Responder replies to a client, it performs string substitution on the URL.
Because the purpose of using regular expressions to perform string substitution in Redirect URLs
is to parse request URLs into strings, constructing an appropriate regular expression requires an
exact knowledge of the format of the request URLs that will typically be coming in to the cluster
IP.
Equalizer supports POSIX-style extended regular expressions.
See the examples that follow below to help you understand how regular expressions are
constructed and interpreted by Responders.
Example 1 - HTTPS Redirect
The simplest form of HTTPS redirect involves simply referring the user to the top level of the
https:// site, regardless of the path information that may have been included in the original
request URL. For example, we could direct all requests for:
http://www.example.com/<path>
to:
https://www.example.com
But, this forces the client to re-specify the <path> after the redirect. It would be better to redirect
to a URL that includes the path information:
https://www.example.com/<path>
The following regular expression:
^(([^ :/?#]+):)?//(.*)
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
619
Automatic Cluster Responders
breaks a request URL into the following named variables:
$0
$1
$2
$3
http://www.example.com/<path>
http
http:
www.example.com/<path>
We can then use these variables in the URL field as shown in the following Responder
Configuration screen (tab):
This Responder can be used in any cluster where a Redirect to an HTTPS cluster is desired.
Example 2 - Multi-Hostname Redirect
Let’s assume that we have a set of ".com" host names, all of which resolve to the same cluster IP,
and we need a Responder that redirects requests to the same hostname prefixes with a ".net"
suffix. We also want to include the rest of the URL exactly as specified by the client. For example,
we want requests to URLs in these formats:
http://www.example.com/<path>
http://www.example2.com/<path>
http://www.example3.com/<path>
to be redirected to the following URLs:
http://www.example.net/<path>
http://www.example2.net/<path>
http://www.example3.net/<path>
The following regular expression:
^(([^ :/?#]+):)?//([^ \r/?#.]+)?\.([^ \r/?#.]+)?\.([^ \r/?#]+)?(/[^ \r]+)?
breaks the request URL into the following named variables:
$0
$1
$2
$3
$4
$5
$6
http://www.example.com/<path>
http:
http
www
example
com
/<path>
We can then use these variables in the URL field as shown in the following Responder
Configuration screen (tab):
620
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
It should be noted that this example will not work for requests with destination URLs specified
with an IP address for a hostname (e.g.,"12.34.56.78" instead of "www.example.com"). Providing
support for IP addresses in URLs as well as DNS host names would involve either: a more
complex regular expression that matches both; or, an additional Responder with a regular
expression that matches IP addresses, as well as two match rules to match the two types of host
names (so that the appropriate Responder replies to the client).
Example 3 - Directory Redirect
The next example involves redirecting requests that include a particular directory to a different
domain, omitting the directory from the redirect URL’s path. Let’s say we want all requests for:
http://www.example.com/images/<path>
to be redirected to:
http://images.example.com/<path>
The following regular expression:
(([^ :/?#]+):)?//([^ \r/?#.]+)?.([^ \r/?#.]+)?.([^ \r/?#]+)?(/[^ \r]+)?(/[^ \r]+)
breaks the request URL into the following named variables:
$0
$1
$2
$3
$4
$5
$6
$7
http://www.example.com/images/<path>
http
http:
www
example
com
/images
/<path>
We can then use these variables in the URL field as shown in the following Responder
Configuration screen (tab):
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
621
Automatic Cluster Responders
This Responder can be used in a Match Rule in any cluster where a similar directory name based
redirect is required.
Using Responders in Match Rules
Once a responder is created, it can be associated with a cluster using a match rule (See "Using
Match Rules" on page 410). When adding a responder to a match Rule, the way the match rule is
configured has a direct effect on the conditions under which the responder is used:
expression:
The default match rule expression [any()] matches all incoming requests.
If you want the responder to be used only for specific requests, then create
an appropriate match rule expression to match those requests; See
"Using Match Rules" on page 410.
server selection:
By default, no servers are selected in a match rule. This means that any
incoming request URL that matches the match rule expression will be
handled by the responder specified in the match rule. If you want the
responder to be used only if no servers (or particular servers) are
available, select all (or some) of the servers listed in the match rule
Configuration screen (tab).
Once a responder is created, it can then be selected in a match rule’s response list. The following
sections show some common match rule and Responder configurations.
Creating a Match Rule for a “Sorry Page”
The most common use of a responder is to change the default match rule behavior when no server
pools are available in a cluster. By default, every HTTP and HTTPS cluster is created with a Default
match rule that does not specify a Responder -- thus, if all the server pools in the Default match
rule are down, Equalizer drops the client connection to the cluster.
In order to change the default behavior and supply a “sorry page” or redirect for a cluster, you
need to add a new match rule that:
622
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
l
matches any incoming request
l
selects the server pool specified
l
has a Sorry Server Responder selected
For example, let’s say you have two Responders defined and there is an existing cluster that you
would like to redirect to http://www.example.com when no server pools in the cluster are
available. To accomplish this, we need to create a new Responder and then add a match rule to
the cluster:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Right click on Responder on the left navigational pane and select AddResponder. The Add New
Responder dialog appears.
4. Type Sorry_Example into the Name field and select Sorry Server.
5. Type the HTML content for the page to display into the text box that appears, as shown in
the following example.:
6. Click Commit to save the new Responder.
7. Right-click on the name of the cluster for which you want to display the sorry page in the
left frame and select Add Match Rule.
8. Refer to "Creating a New Match Rule" on page 428 to configure the match rule. Leave the
match rule expression set to the default [any()] -- the rule will match all incoming requests.
Note - The Responder will only be used if none of the server instances in the server pool is available.
9. Select Sorry_Example in the response drop-down list on the Configuration tab as shown below.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
623
Automatic Cluster Responders
10. Click Commit to save the match rule.
Creating a Match Rule to Redirect All Traffic for a Specific URL
Another common cluster configuration requirement is to be able to automatically redirect all
traffic that uses a specific URL. To do this, you need to add a new match rule that:
l
matches any incoming request
l
has a Redirect Responder selected
For example, let’s say that we want all traffic to a cluster that uses the URL
http://cluster/special/ to be redirected to https://www.example.com/special/. The
following procedure shows you how to add the appropriate Responder and Match Rule:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Load Balance configuration tab if it is not already selected.
3. Right click on Responder on the left navigational pane and select AddResponder. The Add New
Responder dialog appears.
4. Type Redirect_Example into the Name field and select Redirect .
5. Type https://www.example.com/special/ into the URL field.
6. Click Commit to save the new Responder.
7. Right-click on the name of the cluster for which you want to display the sorry page in the
left frame and select Add Match Rule from the menu.
8. Refer to "Creating a New Match Rule" on page 428 to configure the match rule. Leave the
match rule expression set to the default [any()] -- the rule will match all incoming requests.
Do not select any server pools from the Server Pool drop down list. This means that if this
match rule’s expression selects a request, the Responder we select will respond to the
selected request regardless of the status of the server pools in the cluster.
9. Click Commit to create the match rule.
10. Select Redirect_Example in the Responder drop-down list as shown below.
11. Click commit to save the match rule.
624
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
After completing the above procedure, all client requests to http://cluster/special/ will be
redirected to https://www.example.com/special/, even when all the server instances in a server
pool are available.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
625
Automatic Cluster Responders
Responders and Hot Spares
Responders provide functionality that automates the very basic functions of a hot spare server,
and off loads them onto Equalizer. If more functionality is desired, than a separate real server
should be used as a hot spare for the cluster.
It should also be noted that resources Equalizer uses to service client requests via the Responder
feature are resources potentially taken away from processing other client requests. In most
cases, Responders might possibly have an effect on performance if all the servers in one or more
clusters are down during periods of peak usage.
626
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Responder Statistics and Reporting
The CLI display of Statistics can be seen by entering the following within the responder context:
Sample Responder Statistics Display
To view the GUI display:
1. Verify that you are logged into the GUI. (Refer to "Logging In" on page 268.)
2. Select the Load Balance configuration tab on the left navigational pane if it is not already
selected.
3. Click on the arrow (u) beside Respondersto expand the branch.
4. Select a Responder and click on the Reporting tab to display statistics. The following is an
example of the statistics displayed.
Sample Responder GUI Statistics Display
The following are definitions for the statistical terms shown on both the CLI and GUI:
Responder Statistics Definitions
CLI Term
GUI Term
Definition
N/A
Connections/second (CPS)
Connections/second
N/A
Transactions/second (TPS)
Transactions/second
N/A
Throughput
Throughput.
N/A
Total Connections
Total connections.
N/A
Active Connections
Active connections.
N/A
Bytes Received
Bytes received.
N/A
Bytes Sent
Bytes sent.
TOTALPRCSD
N/A
Connections Processed
The following is a graphical plot that can be displayed on the GUI. Select a Responder on the left
navigational pane and click on the Reporting tab and then Plotting. The following will be displayed:
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
627
Automatic Cluster Responders
Sample Responder Plot
The specific types of statistics that are graphically displayed are determined by the selections on
the Statistics pane on the upper right corner of the GUI.Make selections based on the data that you
require. As you can see from the figure above, the Responder statistic displays only
Transactions/second.
The Plot Type selection determines whether the display shown reflects a Static Time Span which is
configured using the slider or whether a real time duration is display. If Real Time Duration is
selected the slider controls will change to Duration and Refresh controls as shown below. In this case
set the Duration of time in which you would like to review statistics and the Refresh rate desired.
628
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 18
Link Load Balancing
Sections in this chapter include:
Link Load Balancing
Outbound Link Load Balancing
Inbound Link Load Balancing
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
630
631
637
629
Link Load Balancing
Link Load Balancing
Multiple ISP connections at each point of presence help to guarantee the availability of your
services by building redundancy. Link Load Balancing (LLB) functionality allows your ADC
appliance to support multiple upstream links across infrastructure that supports them. If a
primary ISP link fails, LLB enables the seamless redirection of traffic through a backup link.
Similar to GSLB, inbound LLB avoids the need for failover via Border Gateway Protocol (BGP) by
using DNS-based load balancing and gateways instead. LLB also adds the capability of clients
reaching each of your points of presence through multiple paths. It is typically configured for both
outbound and inbound traffic.
630
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Outbound Link Load Balancing
Outbound LLB (OLLB) is used when you want redundancy across multiple routes for traffic leaving
the ADC. One prerequisite for OLLB is that all gateways configured into an OLLB group must be
able to route traffic to the same set of destinations.
In order to distribute outbound traffic from your servers, you must define links by defining its
gateway. You will also need to configure one or more health checks that will monitor the
availability of the link so that Equalizer can avoid links that are down.
The illustration below shows how OLLB functions:
If you want Equalizer to avoid links that are not available, or links that do not have complete
routes to crucial IP addresses, you will need to enable link health checks. Each link health check
will periodically send Layer 3 ICMP ECHO probe (pings) from the Equalizer interface IP to an IP
address that must be reachable in order for the link to be determined to be available. This can be
any IP address, such as a main office, core router, server, cluster or virtual server at another
data center.These probes are configured on the gateways (See "Configuring Outbound Link Load
Balancing" on page 632 and "Configuring Inbound Link Load Balancing" on page 638).
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
631
Link Load Balancing
Configuring Outbound Link Load Balancing
Note - The Link Load Balancing feature supports up to 16 links per OLLB group.
Configuration of OLLB consists of the following:
1. Adding VLANs with subnets
2. Configuring gateways
3. Configuring OLLB groups
4. Configuring NAT
5. Configuring subnet routes
Configuring Outbound Link Load Balancing Using the GUI
1. Log in to the GUI
Configuring VLANs with Subnets
2. Configure VLANs as described in "Configuring VLAN Interfaces" on page 118.
3. Add subnets to the VLANs as described in "Configuring Subnets" on page 125. Configure the
subnets over which your internal and link traffic and health checking probes will traverse.
Enter a name (maximum of 47 characters).
4. Click on the Link Load Balance configuration tab on the left navigational pane.
Configuring Gateway
5. Click on the arrow beside Outbound to expand the branch and then click on Gateways to
display the Link Load Balancing Gateways display on the right.
6. Click on + to display on the LLB Gateway dialogue screen as shown below.
7. Enter the IP address of the gateway in the Gateway text box. Enter the IP addresses of the
links to be health checked. Use a “,” to separate the IP addresses. You have the option of
disabling the Gateway by selecting the Disable check box. By default, the options are not set.
By default, the Weight is set to 50. The weight specified in the gateway object applies
to outbound LLB only. When an OLLB route is specified on a subnet, Equalizer will
select, from among all that are up, the gateway with the highest weight.
632
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
8. Click on Commit to save the LLB Gateway.
9. Repeat steps 5, 6, 7, and 8 for additional LLB Gateways. When the LLB Gateways are
configured, they will appear on a list on the right configuration pane.
To edit LLB Gateways, either double click a Gateway on the list or select a Gateway
using the check box and selecting the edit
icon. Both methods will display the LLB
Gateway dialogue screen where changes can be made as necessary.
To delete an LLB Gateway, use the check box to select a Gateway and then click on
the trash (delete) icon.
Configure an OLLB Group
10. Click on Outbound > Groups from the left navigational pane to display the Outbound Link Load
Balancing Groups display on the right.
11. Click on + to display the Add Outbound LLB Group dialogue. An example is shown below.
The group modification dialogue is the same, although the existing name of the Group
will be displayed. Either double click on a group or select a group and then the edit
icon to modify an existing group.
Note - Gateways must have been previously configured.
12. Enter a Name for the group in the space provided.
You also have the option of disabling the group by selecting the Disable check box.
The Gateways Used and Gateways Not Used unused panes list all existing Gateways. You
can associate one or more with the group by dragging and dropping the gateways.
13. Click on Commit to save the OLLB Group.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
633
Link Load Balancing
Set Up NAT
14. If needed, set up NAT. Select a subnet from the left navigational pane and click on the NAT
tab on the right.
15. Click on + to activate the Add NAT Rule dialogue.
16. Configure outbound NAT by entering a from IP and an Out (outbound NAT IP) address.
17. Click on Commit to save the NAT rule. The rules will appear on the Subnet NAT display.
Set Up Subnet Routes
18. Select the System configuration tab if it has not already been selected.
19. Click on the arrow (►) beside Network to expand the branch.
20. Select a VLAN and then select a subnet.
21. Select the Static Route tab and click on + to add a new route.
22. In the dialogue displayed add a Destination IP Address in CIDR format. For example, if you
enter an address of 0/0, this would indicate that any destination can be used. Also enter a
Gateway. The Gateway is the packet destination. Enter an LLB Group name that you configured
in steps 10-13.
23. Click on Commit to save the route. The Static Route will be displayed. In the example below, 2
static routes are configured on a subnet 192.4. Both use a Destination IP of 0/0. Note the llbg1
gateway group name on the second routing entry. This indicates that this subnet (192.4) will
be routed outbound through LLB group llbg1.
634
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring Outbound Link Load Balancing Using the CLI
Configuration of OLLB consists of the following:
l
Adding VLANs with subnets
l
Configuring gateways
l
Configuring OLLB groups
l
Configuring NAT
l
Configuring subnet routes
The following is an example of an ILLB configuration using the CLI.
Adding VLANs with Subnets
1. Set up one or more VLANs that will use internal subnets for communication between servers
and the ADC, and one or more VLANs that will use external subnets to communicate with the
outbound gateways as shown. In the example int is used for the internal VLAN and ext is
used for the external VLAN:
eqcli>
eqcli>
eqcli>
eqcli>
eqcli>
eqcli>
vlan
vlan
vlan
vlan
vlan
vlan
int
int
int
ext
ext
ext
subnet
subnet
subnet
subnet
subnet
subnet
sn0
sn1
sn2
sn3
sn4
sn5
ip
ip
ip
ip
ip
ip
1.1.0.2/24
1.1.1.2/24
1.1.2.2/24
1.2.3.4/24
1.4.5.6/24
1.6.7.8/24
Configuring Gateways
2. Set up LLB Gateways and assign health checks as shown. You can enter up to 16 gateway
health checks. By default, the health checks are enabled.
eqcli>llb-gw 1.2.3.1 hc 8.8.8.8,173.14.44.43
eqcli>llb-gw 1.4.5.1 hc 8.8.2.2,173.14.32.21
3. View the configured gateway using the show command. A message indicating whether the
LLB Gateway is enabled is displayed.
eqcli > show llb-gw 1.2.3.1
This LLB Gateway is enabled.
LLB Gateway Name
Weight
Health Check
Flags
:1.2.3.1
:50
:8.8.8.8, 173.14.44.43
:
a. By default, the gateway’s weight value is 50. If you would like to change the
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
635
Link Load Balancing
weight, enter the following and enter a value:
eqcli > llb-gw 1.2.3.1 weight value
b. By default, when you create a gateway it is enabled. If necessary, you can
disable the gateway by entering:
eqcli > llb-gw 1.2.3.1 flags disable
c. By default, LLB gateway health checks are enabled. To disable health checks,
enter:
eqcli > llb-gw 1.2.3.1 flags disable_hc
Configuring OLLB Groups
4. The gateways set up from the previous step are grouped into an OLLB Group (group1) in the
example shown.
eqcli> ollb-grp group1 gw 1.2.3.1, 1.4.5.1
Configuring NAT
5. If needed, set up NAT as shown. Outbound NAT can be set up by entering a from parameter
in CIDR format that specifies the IP range.
eqcli>
eqcli>
eqcli>
eqcli>
vlan
vlan
vlan
vlan
int
int
int
int
subnet
subnet
subnet
subnet
sn0
sn0
sn1
sn1
nat
nat
nat
nat
from
from
from
from
1.1.0.0/24
1.1.0.0/24
1.1.1.0/24
1.1.1.0/24
out
out
out
out
1.2.3.33
1.4.5.33
1.2.3.34
1.4.5.34
nat
nat
nat
nat
sn0
sn0
sn1
sn1
out
out
out
out
gw
gw
gw
gw
1.2.3.1
1.4.5.1
1.2.3.1
1.4.5.1
Configuring Subnet Routes
6. In the example shown below subnets sn0 and sn1 will be routed through the outbound LLB
group1 (from step 3 above).
eqcli> vlan int subnet sn0 route 0/0 gw group1
eqcli> vlan int subnet sn1 route 0/0 gw group1
636
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Inbound Link Load Balancing
Similar to GSLB, Inbound Link Load Balancing (ILLB) is DNS-based, in that a client makes a DNS
query to resolve the IP address of an FQDN. However, unlike GSLB, the IP address returned in the
DNS reply does not represent a geographic location, but rather one of several links available on a
single Equalizer.
The illustration below shows how ILLB functions.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
637
Link Load Balancing
Configuring Inbound Link Load Balancing
In this process, you will be need to specify a Fully Qualified Domain Name (FQDN) that is
associated with an ILLB group, and a set of link/IP pairs. The load balancer will, based on the
policy in effect (e.g., round robin) and link state, select the appropriate link to use, and return the
associated IP address. This IP address may be that of a server or a cluster (or anything else). You
must always specify in the configuration that IP which is publicly accessible (e.g., NAT address).
If the ILLB group represents a cluster, in order to have a cluster “presence” on multiple subnets,
you must create “copies” of a single cluster such that one exists on each LLB link subnet. The only
difference among the clusters will be the IP address. This creates, in effect, a “cluster of
clusters”. This “cluster of clusters” will be bound together with the ILLB group object.
Configuration of OLLB consists of the following:
1. Adding VLANs with subnets
2. Configuring gateways
3. Configuring ILLB groups
4. Add Targets to the ILLB groups
Using the GUI
1. Log in to the GUI
Configuring VLANs with Subnets
2. Configure VLANs as described in "Configuring VLANs" on page 120.
3. Add subnets to the VLANs as described in "Configuring Subnets" on page 125. Configure the
subnets over which your internal and link traffic and health checking probes will traverse.
Enter a name (maximum of 47 characters)
4. Click on the Link Load Balance configuration tab on the left navigational pane.
638
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring ILLB Groups
5. The ILLB group is analogous to a geocluster in GSLB. Click on Inbound > Groups on the left
navigational pane. The Inbound Link Load Balancing Groups list will be displayed. Click on + to
activate the Add Inbound LLB Group dialogue as shown below. Note that you can also modify an
existing ILLB group by selecting it from the list and either double clicking it or selecting it
and clicking the
edit icon.
Name- a name for the IILLB group
FQDN –Fully Qualified Domain Name. Must include all name components up to the top
level (com, net, org, etc). Do not include the trailing period.
TTL - the Time To Live, is the length of time (in seconds) that the client’s DNS resolver
should cache the resolved IP address. The default is 120 (that is, 2 minutes).
Policy options are:
rr (round robin policy)— causes the load balancer to send a DNS reply with the IP
address associated with each available gateway in turn. This is equivalent to
traditional “round-robin DNS” load balancing.
Prefer – if more than one gateway is available, this policy selects the gateway with the
highest weight and returns the IP associated with that gateway.
flags – by default, the group is enabled
6. Click on Commit after entering the ILLB Group information.
Note - You will not be able to enter Target information on this dialogue prior to committing the ILLB Group information.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
639
Link Load Balancing
Add Targets to the OLLB Groups
7. The target describes an IP-gateway pair. If the gateway of the pair is selected as the “best”
available gateway according to the policy in effect, the associated IP will be returned in a
DNS response. Click on Inbound > Groups on the left navigational pane. The Inbound Link Load
Balancing Groups list will be displayed. Modify an existing ILLB group to add targets by
selecting it from the list and either double clicking it or selecting it and clicking the edit
icon.
8. Click on + to add a new target. By default, the name of the target will be target_1, (or target_
2, etc.) Click in each field to change the Name, IP Address Gateway, Weight and if you would like
the target to be enabled (true).
Note - A Gateway must have been previously configured.
9. Click on Commit to save the target.
Using the CLI
Adding VLANs with Subnets
1. Configure VLANs as described in "Configuring VLAN Interfaces" on page 118.
2. Configure subnets as described in "Configuring Subnets" on page 125. Configure the subnets
over which your internal and link traffic and health checking probes will traverse. An
example is shown below:
eqcli> vlan int subnet sn0 ip 1.1.0.2/24
eqcli> vlan int subnet sn1 ip 1.1.1.2/24
eqcli> vlan int subnet sn2 ip 1.1.2.2/24
eqcli> vlan ext subnet sn3 ip 1.2.3.4/24
eqcli> vlan ext subnet sn4 ip 1.4.5.6/24
eqcli> vlan ext subnet sn5 ip 1.6.7.8/24
640
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring ILLB Groups
3. The ILLB group is analogous to a geocluster in GSLB. Enter the following:
eqcli> illb-grp illb1 fqdn www.test.com ttl 60
The fqdn must include all name components up to the top level (com, net, org, etc).
Do not include the trailing period.
The ttl (Time To Live), is the length of time (in seconds) that the client’s DNS server
should cache the resolved IP address. The default is 60 (that is, 1 minute).
4. Add a weight and policy to the ILLB group.
eqcli> illb-grp illb1 weight 50
weight-by default, the gateway’s weight value is 50. If you would like to change the
weight, enter the following and enter a value.
eqcli > illb-grp illb1 weight value
flags – by default, the illb-grp is enabled. To disable it, enter:
eqcli > illb-grp name flags disable
5. Display the new illb-grp by entering:
eqcli > show illb-grp illb1
ILLB Group Name
: name
FQDN : www.test.com
Policy
: rr
TTL
: 60
Flags :
eqcli >
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
641
Link Load Balancing
Add Targets to the ILLB Groups
6. Add a target to the illb-grp. This describes which IP address to return in an A/AAAA record
if the specified gateway is selected, or a gateway to consider for the FQDN.
eqcli > illb-grp newllb target t1 ip 172.16.191.34 gw 172.16.128.1 weight
50
7. Show the new illb-grp target by entering:
eqcli > show illb-grp newllb target t1
ILLB Target Name
: t1
IP Address : 172.16.191.34
Gateway
: 172.16.128.1
Weight :
Flags :
eqcli >
8. Display the list of ILLB group targets by entering:
eqcli > show illb-grp illb1 target
Name IP Gateway
t1
172.16.191.34
172.16.128.1
eqcli > 642
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 19
Global Load Balance
Sections in this chapter include:
Overview of Envoy Geographic Load Balancing
FortiDirector™ GSLB
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
644
662
643
Global Load Balance
Overview of Envoy Geographic Load Balancing
Geographic load balancing increases availability by allowing regional server clusters to share
workload transparently, maximizing overall resource utilization. The Envoy® Geographic load
balancer is an optional software add-on for the Equalizer product line that supports load balancing
requests across servers in different physical locations or on different networks.
An Envoy-enabled web site is a geographic server cluster, composed of regional clusters. Each
regional cluster is composed of servers that provide a common service, supervised by an
Equalizer running Envoy. For example, the web site www.coyotepoint.com might be supported by
three regional clusters, located in California, New York City, and London. An Equalizer running
Envoy software and web servers with similar content are deployed at each of these locations.
In non-Envoy Equalizer configurations, there is a one-to-one correspondence between a cluster
and a website: when a client makes a request for a website (say, www.example.com), the client
uses the Domain Name Service (DNS) to resolve the website name to an IP address. For a
website that is load balanced by an Equalizer, the IP address returned is the IP address of an
Equalizer cluster. After resolving the name, the client sends the request to the cluster IP. When
Equalizer receives the client request, it load balances the request across the server pool in the
cluster, based on the current load balancing policy and parameters.
In an Envoy conversation, you have two or more Equalizers located in separate locations. Each
Equalizer and its set of clusters and servers forms a site (or Envoy site). With Envoy, the website
name in the client request is resolved to a GeoCluster IP. A GeoCluster is analogous to a cluster,
but one level above it: in other words, a GeoCluster actually points to two or more clusters that
are defined on separate Equalizers.
In the same way that Equalizer balances requests for a cluster IP across the server pool in the
cluster, Equalizer load balances a request for a GeoCluster IP across the clusters in the
GeoCluster configuration. Once a site is chosen and the client request arrives at that site, the
request is load balanced across the servers in the appropriate cluster. In this way, you can set up
geographically distant Equalizer's to cooperatively load balance client requests.
Envoy on EQ/OS 10 can only interoperate with Envoy running on other units running EQ/OS
10, and does NOT interoperate with Envoy running on EQ/OS 8.6 (or earlier).
644
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Envoy Configuration Summary
Follow this general procedure when setting up Envoy for the first time:
1. Configure appropriate clusters (and servers) on all of the Equalizers to be included as Envoy
sites in the GeoCluster.
2. Configure the GeoCluster on each Equalizer; the parameters used should be the same on all
sites. This includes creating GeoSites and adding GeoSite Instances to the GeoCluster.
(Refer to "Configuring GeoClusters" on page 649 and "Configuring GeoSites" on page 654 for
details.)
3. Configure the authoritative DNS server for your website’s domain with DNS records for all
Equalizers in the GeoCluster. The DNS server returns these records to clients in response to
DNS requests to resolve the website (GeoCluster) name.
DNS Configuration
Every Web site is assigned a unique IP address. To access a website, a client needs to know what
the site IP address is. Users don't usually enter an IP address into their Web browser, but rather
enter a site's domain name instead. In order to access a requested website, a Web browser needs
to be able to convert the site's domain name into the corresponding IP address. This is where DNS
comes into play.
1. A client computer is configured with the address of a preferred DNS server.
2. A requested URL is forwarded to the DNS server, and the DNS server returns the IP address
for the requested website.
3. The client is then able to access the requested site.
Local (Caching) DNS Server
In a typical GSLB configuration a local, or caching DNS server resides in the client's LAN
environment. When the client directs the browser to get to a URL (i.e., www.coyotepoint.com) the
browser requests the local DNS to resolve the name (i.e. www.coyotepoint.com) to an IP address.
Once local DNS server resolves the name to an ip address, it will first check a root name server,
which returns a list of name servers for, say, the .com domain. The name servers for the domain
name space return the IP addresses of an Authoritative DNS server for the domain name. Finally,
the Authoritative DNS for the domain name returns the IP address of the web server, or in Envoy
SAE, the FQDN of a GeoCluster. For each GeoCluster to be balanced, an Authoritative Name
Server must be configured to return name server and alias records for Envoy SAE’s at every
regional site
Configuring an Authoritative DNS Name Server for Envoy
You must configure an Authoritative DNS Name Server(s) for the domains that are to be
geographically load balanced to delegate authority to the Envoy sites. You need to delegate each
of the fully-qualified subdomains to be balanced. If your DNS server is run by an Internet Service
Provider (ISP), then you need to ask the ISP to reconfigure the DNS server for Envoy. If you are
running your own local DNS server, then you need to update the DNS server’s zone file for your
Envoy configuration.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
645
Global Load Balance
This is usually the last step performed when configuring Envoy. It is recommended to set up
Envoy and test your Envoy configuration thoroughly before making changes on the Authoritative
Name Server.
For example, assume you must balance www.coyotepoint.com across a GeoCluster containing
two Envoy sites, east.coyotepoint.com (at 192.168.2.44) and west.coyotepoint.com (at 10.0.0.5).
In this case, you must configure the name servers that will handle the coyotepoint.com domain to
delegate authority for www.coyotepoint.com to both east.coyotepoint.com and
west.coyotepoint.com. When queried to resolve www.coyotepoint.com, coyotepoint.com's name
servers should return name server (NS) and alias (A) address or glue records for both Envoy
sites.
An example of a DNS zone file for this configuration is shown below. In this example, the systems
ns1 and ns2 are assumed to be the authoritative name servers (master and slave) for the
coyotepoint.com domain.
$TTL 86400
remotesite.com. IN SOA ns1.remotesite.com.
hostmaster.remotesite.com. (
0000000000
00000
0000
000000
00000 )
646
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
remotesite.com. IN NS ns1.remotesite.com.
remotesite.com. IN NS ns2.remotesite.com.
www.remotesite.com. IN NS east.remotesite.com.
www.remotesite.com. IN NS west.remotesite.com.
ns1 IN A ns1-IP-address
ns2 IN A ns2-IP-address
east IN A 192.168.2.44
west IN A 10.0.0.5
In the example above, we left the domain parameters as zeros, since these vary widely between
DNS installations. Please see the documentation for the version of DNS that you are using for
more information on the zone file content and format.
Envoy also supports AAAA (also called "quad-A" records) for IPv6 addresses.
To ensure that you have properly configured DNS for Envoy, you can use the nslookup command
(supported on most OS platforms) to confirm that the DNS server is returning appropriate
records, as in this example:
nslookup www.remotesite.com
Server: ns1.remotesite.com
Address: ns1-IP-address
Name: www.remotesite.com
Address: 192.168.2.44
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
647
Global Load Balance
Using Envoy with Firewalled Networks
Envoy sites communicate with each other using UDP-based Geographic Query Protocol (GQP).
Similarly, Envoy sites communicate with clients using the DNS protocol. If you protect one or
more of your Envoy sites with a network firewall, you must configure the firewall to permit the
Envoy packets to pass through.
To use Envoy with firewalled networks, you need to configure the firewalls so that the following
actions occur:
l
l
l
Envoy sites communicate with each other on UDP ports 5300 and 5301. The firewall must
allow traffic on these ports to pass between Envoy sites.
Envoy sites and clients can exchange packets on UDP port 53. The firewall must allow traffic
on this port to flow freely between an Envoy site and any Internet clients so that clients
trying to resolve host names via the Envoy DNS server can exchange packets with the
Envoy sites.
Envoy sites can send ICMP echo request packets out through the firewall and receive ICMP
echo response packets from clients outside the firewall. When a client attempts a DNS
resolution, Envoy sites send an ICMP echo request (ping) packet to the client and the client
might respond with an ICMP echo response packet.
Using Envoy with NAT Devices
If an Envoy site is located behind a device (such as a firewall) that is performing Network Address
Translation (NAT) on incoming IP addresses, then you must specify the public (non-translated) IP
as the Site IP, and use the translated IP (the non-public IP) as the resource (cluster) IP in the
Envoy configuration.
This is because Envoy must return the public cluster IP to a requesting client in order for the client
to be able to contact that cluster -- since the request goes through the NAT device before it
reaches Equalizer. The NAT device translates the public cluster IP in the request to the non-public
cluster IP that is defined on Equalizer, and then forwards the packet to Equalizer.
The non-public cluster IP must still be specified as the resource IP for the site, as this is the IP
that Envoy will use internally to probe the availability of the resource (cluster) on the site.
648
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Configuring GeoClusters
This section shows you how to add or delete a GeoCluster and how to configure a GeoCluster’s
load-balancing options. Configuring a GeoCluster and its sites is analogous to configuring a virtual
cluster and its servers.
There are two parts to configuring GeoClusters. The first is to Add a GeoCluster and the second is
to modify the GeoCluster parameters.
Adding a GeoCluster (GUI)
When Envoy is first enabled, there are no GeoClusters defined. To add a GeoCluster:
1. Log in to the GUI(See "Logging In" on page 268).
2. Right click on the GeoClusters in the left navigational pane and the Add GeoCluster form will be
displayed.
3. Enter a GeoCluster Name in the space provided.
4. Enter a FQDN in the space provided. This is the Fully Qualified Domain Name of the
GeoCluster (for example, www.coyotepoint.com). The FQDN must include all name
components up to the top level (com, net, org, etc). Do not include the trailing period.
5. Click on Commit to add the GeoCluster. The new GeoCluster will appear on the left
navigational pane.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
649
Global Load Balance
Deleting a GeoCluster (GUI)
1. Log in to the GUI (See "Logging In" on page 268 ).
2. Right-click on the GeoCluster on the left navigational pane and select Delete GeoCluster.
Viewing and Modifying GeoCluster Parameters (GUI)
To view or modify a GeoCluster’s load-balancing options, proceed with the following:
1. Log in to the GUI (See "Logging In" on page 268).
2. Click on the GeoCluster on the left navigation pane. The figure below will be displayed:
3. View and Modify parameters using the following guidelines:
FQDN
650
The GeoCluster name which is the fully-qualified domain name (FQDN) of the
GeoCluster (for example, www.coyotepoint.com). The FQDN must
include all name components up to the top level (com, net, org, etc). Do not
include the trailing period
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Three basic metrics are used by the policy to load balance requests among sites:
the current load on the site, the initial weight setting of the site, and ICMP
triangulation responses. The policy setting tells Envoy the relative weight to
assign to each metric when choosing a site:
round robin causes Envoy to send requests to each available site, in turn, in
the order they are listed in the configuration. This is equivalent to traditional
‘round-robin DNS’ load balancing.
Policy
round trip weights the ICMP triangulation information received from each site
more heavily than other criteria.
adaptive give roughly equal weights to the site load and ICMP triangulation
responses, and gives less weight to the initial weight for the site.
site load weights the current load at each site more heavily than other criteria.
This is the default setting.
site weight weights the user-defined initial weight for each site more heavily
than other criteria.
Mail Exchanger FQDN
The fully qualified domain name (e.g., "mail.example.com") to be returned if
Equalizer receives a “mail exchanger” request for this GeoCluster. The mail
exchanger is the host responsible for handling email sent to users in the
domain. This field is not required.
Responsiveness
This value controls how aggressively Equalizer adjusts the site’s dynamic
weights. Equalizer provides five response settings: slowest, slow, medium,
fast, and fastest. Faster settings enable Equalizer to adjust its load balancing
criteria more frequently and permit a greater variance in the relative weights
assigned to sites. Slower settings cause site measurements to be averaged over
a longer period of time before Equalizer applies them to the cluster-wide load
balancing; slower settings also tend to ignore spikes in cluster measurements
caused by intermittent network glitches. Use the slider to make your selection.
We recommend that you select the medium setting as a starting point.
Time To Live
The cache time-to-live, which is the length of time (in seconds) that the client’s
DNS server should cache the resolved IP address. Longer times will result in
increased failover times in the event of a site failure, but are more efficient in
terms of network Resources. Use the selector to adjust the timing. The default is
120 (that is, 2 minutes).
Maximum Number of
Responses
This is the maximum number of Resource records returned in a DNS response
that will be allowed in this GeoCluster. The first address will be the actual
selected GeoSite. Those that follow will be any site which is up in the list of
GeoSites.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
651
Global Load Balance
When a request for name resolution is received by Envoy from a client’s local
DNS, this option (if enabled) tells Envoy to request network latency information
from all sites in order to make load balancing decisions based on the proximity of
each site to the client’s DNS server.
To do this, all Envoy sites send an ICMP echo request (“ping") to the client’s DNS
server. The reply from the DNS server allows Equalizer to select a site using the
length of time it takes for the DNS server’s reply to reach the site.
(Consequently, this method assumes that the client’s DNS server is
geographically close to the client -- which is usually the case.)
ICMP Triangulation (option)
If you do not want Envoy GeoSites to ping client DNS servers, disable this flag
(this is the default setting).
Please note that in order for ICMP triangulation data to be collected at each
GeoSite:
The client’s DNS server must be configured to respond to ICMPv4
echo requests (ICMPv6 is not currently supported for Envoy
triangulation).
The client’s DNS server must be allowed to respond through any
firewalls between it and the Envoy GeoSites.
Note - For all policies, the current site load metric is ignored for the first 10 minutes that the site is up, so that the
metric value is a meaningful measure of the site load before it is used.
Note - In Version 10, if ICMP triangulation is enabled and all GeoSites report that triangulation failed, then ICMP
triangulation is ignored for GeoSite selection. That is, Envoy geographic load balancing will proceed as if ICMP
triangulation were disabled. [In Version 8.6, if no GeoSites successfully completed ICMP triangulation then Envoy would
send a NULL response.]
If only some GeoSites report failed triangulation, and there are others that did not fail and that are not down, then
GeoSite selection will only include those sites that successfully completed ICMP triangualtion. [This is the same as the
Version 8.6 behavior.]
Adding a GeoCluster (CLI)
To add a GeoCluster using eqcli as follows:
1. Log in to eqcli as described in Starting the CLI.
2. Enter the following at the CLI prompt:
eqcli > geocluster gcname req_cmds
Deleting a GeoCluster (CLI)
Delete a GeoCluster using eqcli as follows:
1. Log in to eqcli as described in Starting the CLI.
2. Enter the following at the CLI prompt:
652
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
eqcli > no geocluster gcname
Viewing and Modifying GeoCluster Parameters (CLI)
To add a GeoCluster using eqcli as follows:
1. Log in to eqcli as described in Starting the CLI.
2. Use the parameter descriptions above and the command line sequences described in
GeoCluster and GeoSite Instance Commands to view and modify GeoCluster parameters
using eqcli.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
653
Global Load Balance
Configuring GeoSites
In EQ/OS 10, GeoSites are defined separately (like Servers) and then added to GeoClusters as
GeoSite Instances. This section describes how to add, delete and configure GeoSites and includes
descriptions of the parameters used by GeoSites.
Adding a GeoSite (GUI)
To add a GeoSite using the GUI proceed with the following:
1. Verify that you are logged into the GUI. If not, log in as described in "Logging In" on page
268.
2. Select the Global Load Balance configuration tab on the left navigational pane if it is not
already selected.
3. Right-click on GeoSites and select Add GeoSite. The Add GeoSite form will be displayed.
4. Enter a GeoSite Name and an Agent IP. The Agent IP is the IP address of the GeoSite’s Envoy
Agent. This is the subnet IP address of Envoy at this site on which the Envoy Agent is
running. On EQ/OS 10, you can enable the Envoy Agent on any subnet’s VLAN IP address or
Failover IP address.
5. Click on Commit to add the GeoSite.The new GeoSite will appear on the left navigational pane
.You can view the GeoSite configuration by clicking on the GeoSite in the left navigational
pane which will display the GeoSite > Configuration > Required screen on the right.
Deleting a GeoSite (GUI)
To delete a GeoSite using the GUI proceed with the following:
1. Log in to the GUI (See "Logging In" on page 268).
2. Right-click on a GeoSite on the left navigational pane and select Delete GeoSite.
654
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Adding a GeoSite (CLI)
Too add a GeoSite using eqcli as follows:
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the following at the CLI prompt:
eqcli > geosite gsnamereq_cmds
Deleting a GeoSite (CLI)
Too delete a GeoSite using eqcli as follows:
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the following at the CLI prompt:
eqcli > no geosite gsname
Geosite Instance Parameters
The following procedures describe the process of adding and configuring GeoSite Instance
parameters.
Adding and Configuring a GeoSite Instance (GUI)
To add a GeoSite instance to a GeoCluster using the GUI proceed with the following:
1. Log in to the GUI (See "Logging In" on page 268).
2. Refer to "Configuring GeoClusters" on page 649 to configure a GeoCluster.
3. Add a GeoSite instance to a GeoCluster using one of the following methods:
a. Using the GUI drag and drop functionality, click on a GeoSite on the left
navigational pane and drag it to the desired GeoCluster on the tree. The GeoSite
instance weight form will be displayed.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
655
Global Load Balance
b. Right click on a GeoCluster on the left navigational pane and select Add GeoSite
Instance. The Add GeoSite Instance form will be displayed. If this method is
used, you will need to enter the GeoSite IP Address and select the desired GeoSite
using the GeoSite Name drop down list.
656
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
4. In both methods of creating GeoSite Instances the GeoSite IP Address is required. This is the
IP address returned by DNS to a client when the GeoCluster is accessed. For example, when
a client opens www.coyotepoint.com, the local DNS server returns an A record that
contains the IP address for www.coyotepoint.com. This is usually the address of an
Equalizer cluster and in this case is also used as the resource IP. However, the site’s A
record IP may be different from the cluster (resource) IP if the A record IP address is
NAT’ed to an internal address (the actual cluster IP). In this case, you specify the A record
IP as the site IP and the cluster IP as the resource IP.
5. Using the slider on either form, adjust the Weight , which is an integer that represents the
site’s capacity. (This value is similar to a server’s initial weight.) Valid values range
between 0 and 200. Use the default of 100 if all sites are configured similarly; otherwise,
adjust higher or lower for sites that have more or less capacity.
Equalizer uses a site’s initial weight as the starting point for determining what percentage of
requests to route to that site. Equalizer assigns sites with a higher initial weight a higher
percentage of the load. The relative values of site initial weights are more important than
the actual values. For example, if two sites are in a GeoCluster and one has roughly twice
the capacity of the other, setting the initial weights to 50 and 100 is equivalent to setting the
initial weights to 100 and 200.
Dynamic site weights can vary from 50% to 150% of the assigned initial weights. To
optimize GeoCluster performance, you might need to adjust the initial weights of the sites in
the cluster based on their performance.
Site weights can range from 0 to 200. When you set up sites in a GeoCluster, you should set
each site’s initial weight value in proportion to its capacity for handling requests. It is not
necessary for all of the initial weights in a cluster to add up to any particular number.
6. Click on Commit to add the GeoSite instance. The instance will appear beneath the
GeoCluster on the left navigational pane .
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
657
Global Load Balance
7. Select additional options for the GeoSite instance by clicking the GeoSite instance from the
left navigational pane to display the Configuration > Required screen.From this screen all
configuration options can be modified.
l
Default - Designates this site as the default site for the GeoCluster. Envoy load
balances to the default site whenever it cannot choose a site based on the GQP
probe information it gets from the sites. This can happen, for example, when
GQP probe responses are not received from any site, when the resource
(cluster) is down at all available sites, etc. If no default site is selected for a
GeoCluster and all sites are down, then Envoy sends a null response to the
client DNS.
l
Hot Spare - When enabled, no traffic will be routed to the site unless there are no
other sites available. Default value is disabled.
l
Disabled - When turned on, no traffic will be routed to the site. Default value is
off.
Deleting a GeoSite Instance (GUI)
To remove a GeoSite instance from a GeoCluster using the GUI proceed with the following:
1. Log in to the GUI (See "Logging In" on page 268).
2. Click on the GeoSite Instance on a GeoCluster branch on the left navigational pane and
select Delete GeoSite Instance.
Adding and Configuring a GeoSite Instance (CLI)
To add and configure a GeoSite instance using eqcli proceed with the following:
1. Log in to eqcli as described in "Starting the CLI" on page 168
2. Use the parameter descriptions above and the command line sequences described in
"GeoSite and GeoSite Resource Commands" on page 215 to view and modify GeoSite
parameters using eqcli.
658
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Deleting a GeoSite Instance (CLI)
To remove a GeoSite instance from a GeoCluster using eqcli proceed with the following:
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the following at the CLI prompt:
eqcli > no geocluster
geocluster_name gsi gsi_name
where:
geocluster_name is the name of the GeoCluster
gsi_name is the name of the GeoSite instance.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
659
Global Load Balance
GeoSite Resources and GeoSite Instance Resources
GeoSite Resources are named clusters defined within a GeoSite. They are assigned a name so
that they can be configured into a GeoCluster. For example a GeoSite in New York may have a
cluster “CLNY1” defined. Another GeoSite located in San Jose may have a cluster “CLSJ1” defined.
In order to load balance between the New York and San Jose GeoSites the Resources of each will
be defined as GeoSite Resource Instances in a GeoCluster.
Name a GeoSite Resource (GUI)
1. Log in to the GUI (See "Logging In" on page 268).
2. Select a GeoSite from the left navigational pane.
3. Right-click on the GeoSite and select Add GeoSite Resource and the following will be displayed.
4. Enter a name for the Resource and click on Commit . The GeoSite Resource will appear on the
left navigation pane.
Add a GeoSite Instance Resource to a GeoCluster (GUI)
1. Log in to the GUI (See "Logging In" on page 268).
2. Right click the GeoSite Instance within a GeoCluster on the left navigation pane an select
Add GeoSite Instance Resource. The following will be displayed:
3. Use the Resource Name drop down list to select one of the previously defined GeoSite
Resources.
660
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
4. Click on Commit to add the Resource Instance. It will be displayed on the left navigation
tree .
Name a GeoSite Resource (CLI)
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the GeoSite context and add the following at the CLI prompt:
eqcli ga-gsname> resource clname
where:
clname
is the cluster name at the GeoSite.
Add a GeoSite Resource Instance to a GeoCluster (CLI)
1. Log in to eqcli as described in "Starting the CLI" on page 168.
2. Enter the GeoCluster context and following at the CLI prompt:
eqcli > gcl-gclname> geosite geosite_name resource geosite_
resource_name
where:
geosite_nameis the name of the GeoSite
geosite_resource_name is the name of the GeoSite Resource
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
661
Global Load Balance
FortiDirector™ GSLB
FortiDirector™ is a Global Service Load Balancing (GSLB) service that provides a cloud-based
alternative to the native Envoy GSLB service installed with Equalizer. FortiDirector is completely
cloud-based and requires no additional software to be installed on monitored devices. It takes
inbound queries and responds with DNS or HTTP redirect responses that are determined by userdefined health checks. These health checks specify how each network resource is to be
monitored, and what the thresholds are for considering the network resource to be “UP” or
“DOWN” for the purpose of making GSLB decisions.
The Equalizer GUI includes an interface to FortiDirector that allows you to:
l
l
Sign up for a free FortiDirector trial account. As part of the sign up process, a network
resource for the ADC on which you sign up is automatically created within FortiDirector.
Monitor HTTP and DNS redirect statistics generated by the FortiDirector service for devices
connected to your account.
Other activities associated with FortiDirector must be performed on the FortiDirector website.
These include:
l
Setting up health checks for monitoring the network resource associated with your free trial
account.
l
Creating additional network resources.
l
Managing your FortiDirector account.
For additional information about FortiDirector, follow this link to the FortiDirector Documentation
Page which provides a full documentation set and videos about the service.
Using the Equalizer GUI to Interface with FortiDirector
The following sections describe:
l
l
l
Creating and Activating a Free FortiDirector Account using the GUI.
Logging in to an Existing FortiDirector Account and Registering a Network Resource using
the GUI.
Viewing FortiDirector Account Statistics.
Note - DNS must be configured on Equalizer prior to interfacing with FortiDirector. Refer to "Parameters" on page 290
for descriptions.
Creating and Activating a Free FortiDirector Account using the GUI
Follow this procedure if you want to create and activate a free FortiDirector Account.
1. Select Global Load Balance > FortiDirector GSLB > Log In on the left navigational pane to display
the FortiDirector Login screen as shown below. You should note that the FortiDirector Login screen
is only displayed when your Equalizer is not registered with FortiDirector.
662
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
2. Click on the "Sign up for free" hyperlink on the login page. This will display the Create
FortiDirector Account page as shown below. The sign up procedure creates the association
between your ADC and FortiDirector. The information required for activation are First Name,
Last Name, Email Address, Company and Phone. Website can be your company's URL. This is an
optional, information field that has no effect on the functionality of FortiDirector.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
663
Global Load Balance
IPv4 Address / FQDN information is required to create a network resource on
FortiDirector that is capable of servicing user requests. This is the IP address of the
Equalizer cluster that FortiDirector will monitor. It can also be an external IP which
NATS to a cluster IP.
3. Click on the Create Free Account button after entering the required information. The FortiDirector
login screen will be redisplayed and you will receive a confirmation email to the address that
you provided.
4. When you receive the confirmation email, follow the link in the email to complete the sign
up process and set a Password. This is the password that you will use to access FortiDirector
statistics through the Equalizer GUI, or to log in directly on the FortiDirector website. After
entering a password and clicking on the Set Password button, you will be prompted to log in to
FortiDirector.
5. When you receive the confirmation email, follow the link in the email to complete the sign
up process and set a Password. This is the password that you will use to access FortiDirector
statistics through the Equalizer GUI or to log in directly on the FortiDirector website. After
entering a password and clicking on the Set Password button, you will be prompted to log in to
FortiDirector.
664
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
6. After you log in, the FortiDirector dashboard will be displayed. Click on the Network Resources
tab at the top of the FortiDirector Dashboard. Note that a new DNS Network Resource has been
added, based on the information that you provided on the Create FortiDirector Account page.
7. Configure health checks for monitoring the network resource associated with your free trial
account. Refer to the FortiDirector Documentation Page to view documentation that
describes the health check configuration process.
8. Note that the Log In icon on the left navigational pane is changed to Usage Information. Each
time that you click on the Usage Information icon, statistical information will be downloaded
from FortiDirector and you will be able to view DNS or HTTP redirect statistics.
Logging in to an Existing FortiDirector Account and Registering a Network Resource using the GUI
Use this procedure if you have an existing FortiDirector account with resources that have been
configured with health checks. Refer to the FortiDirector Documentation Page to view
documentation that describes the health check configuration process.
1. Select Global Load Balance > FortiDirector GSLB > Log In on the left navigational pane to display
the FortiDirector Login screen as shown below.
2. Enter your Email Address and Password in the space provided and click on the Login button.
These are the log in credentials that you obtained from previously subscribing directly on
the FortiDirector website .
3. Enter an IPv4 Address/FQDN in the space provided. This information is required to associate
an existing network resource on FortiDirector that is capable of servicing user requests.
This is the IP address of the Equalizer cluster that FortiDirector will monitor. It can also be
an external IP which NATS to a cluster IP.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
665
Global Load Balance
4. Click on the Login button. The Log In icon on the left navigational pane is changed to Usage
Information. Each time that you click on the Usage Information icon, statistical information will
be downloaded from FortiDirector and you will be able to view DNS or HTTP redirect
statistics.
Viewing FortiDirector Account Statistics.
If a network resource does not have health checks associated with it, statistics will not be
available. You will need to configure health checks on the network resource. You must specify how
each network resource is to be monitored, and what the thresholds are for considering the
network resource to be “UP” or “DOWN” for the purposes of inclusion or exclusion from load
balancing. Follow the procedures described in the documentation provided on the FortiDirector
Documentation Page.
1. Register your Equalizer and create network resources on FortiDirector by either:
a. Logging in to an Existing FortiDirector Account and Registering a Network
Resource using the GUI
b. Creating and Activating a Free FortiDirector Account using the GUI
2. Configure the network resources with health checks on the FortiDirector website.
3. Display DNS Redirect and HTTP Redirect statistics by selecting Global Load Balance >
FortiDirector GSLB > Usage Information on the left navigational pane. The following is an example
of the display. Each time that you click in the icon, the information on the right pane will be
refreshed.
A slider, beneath the plot allows your set a time frame to monitor HTTP and DNS
Redirect statistics. Click on Set when you move the slider.
666
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Chapter 20
Security and Protection
Sections in this chapter include:
Equalizer‘s Security and Protection System
DDoS Protection
How Equalizer‘s DDoS Protection Works
Equalizer‘s DDoS Protection Features
First Time Deployment
Some Key Concepts
Attack Types Prevented
Feature Usage Workflow
Setting Up Equalizer‘s Service Protection Profiles
Global SPPs
Cluster SPPs
How Mitigation Works with Thresholds
Monitoring Attack Activity and Other System Information
Using the IP Reputation Database
Using Access Control Lists
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
668
669
671
673
674
675
676
680
681
683
686
699
701
704
716
667
Security and Protection
Equalizer‘s Security and Protection System
Equalizer’s security and protection system uses three methods of protecting your appliance from
targeted cyber attacks that can prevent delivery of data and applications and compromise the
data on your back end servers. The three types of protection available are:
1. DDoS (Distributed Denial of Service) Protection - this feature prevents attacks that
can drain your appliance’s resources and prevent access to backend servers and
applications.
2.
IP Reputation Database- this feature allows you to compare incoming packet IP
addresses against a vigorously maintained database of suspicious IP addresses and to block
the compromised and malicious clients contained in the database.
3. Access Control Lists - this flexible feature allows you to configure blacklists that enable
your appliance to block suspicious incoming packets, based on a combination of IP
addresses, destination addresses, or destination ports. It also allows you to configure
whitelists that enable packets to pass, when specific IP source addressing is specified.
The following subsections describe the operation and configuration of each of the three protection
systems.
668
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
DDoS Protection
Note - DDoS Protection is not supported on Equalizer E250GX, E350GX, E450GX, E650GX, and Equalizer OnDemand.
Your ADC can be victim of a deliberate attack that can prevent your clients from accessing data
and applications from backend servers. A hacker can make your life miserable by sending a flood
of traffic from multiple, unsuspecting computers that can overwhelm your ADC’s resources. When
a hacker maliciously uses several computers to do this it is known as a Distributed Denial of
Server (DDoS) attack.
To start an attack, the hacker builds a network of infected computers, known as a “botnet”.
Unbeknownst to these computers, they are “recruited” into the botnet when they are infected with
malicious software through email, websites, and social media. The hacker can then direct the
botnet to send a resource-draining flood of traffic to his intended target that can take an ADC
offline, preventing access to backend servers and applications.
There are serious consequences to DDoS attacks that can include:
Financial Losses - hackers often plan their attacks to maximize financial damage. For example,
online retailers could be targeted during holiday shopping season. Financial losses may include
the cost of investigating an attack and expenses related to customer support and even financial
penalties or legal action.
Legal Action - a customer may try to prove that they suffered damages by the unavailability of
data and applications and may pursue financial restitution by filing lawsuits. They could claim that
an ADC did not have enough protective features to prevent attacks.
Damaged Reputation - public news about a company falling victim to a cyber attack and
compromised customer data can be devastating to your reputation. The resultant bad publicity
can have serious effects on the company’s reputation and future sales. Regaining the trust of your
customers will take longer and will require much more effort.
Customer Attrition - Clients require quick access to information so they may be less likely to
visit a website if it is slower than a competitor site and if data and applications are not readily
available. If applications and data are consistently unavailable or work slowly, customers will
complain or simply switch to another ADC product.
Since the incoming botnet traffic flooding a victimized ADC originates from many different
sources, it effectively makes it impossible to stop the attack simply by blocking a single IP
address and to distinguish legitimate user traffic from attack traffic when spread across a wide
array of incoming traffic. To combat this, a protection system that uses a variety of statistical
techniques to distinguish malicious traffic from legitimate traffic, and provide nonstop protection
against attacks is needed. The protection system needs to be focused on intent- rather than the
content of the attacks.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
669
Security and Protection
Two categories of DoS attacks are faced by administrators:
l
l
670
Network Level Attacks - network-level attacks typically involve a flood of similar traffic
that follows a discernible pattern. The traffic appears in statistically unusual quantities and
looks very different from "normal" traffic, making it more easily identifiable. Equalizer‘s
DDoS protection includes the use of a default Global SPP that applies to all traffic and
features a collection of traffic statistics and the configuration of Soft and Hard thresholds
the number of outstanding fragments and the number of outstanding fragmented packets.
Application Layer Attacks - these types of attacks include online services and Web
applications attacks. They require a more sophisticated mechanism to detect and
distinguish malicious traffic from legitimate traffic. Equalizer‘s application layer DDoS
detection provides early detection of DDoS attacks, such as low-and-slow attacks like
Slowloris.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
How Equalizer‘s DDoS Protection Works
So how can you protect your system from being the victim of malicious, resource-consuming
traffic that could take down your business? Equalizer‘s DDoS protection is a Network Behavior
Anomaly (NBA) prevention system that detects and blocks network attacks that are characterized
by excessive use of network resources. Equalizer uses a variety of schemes, including anomaly
detection and statistical techniques, that provide nonstop protection that focuses on intent rather
than content of network attacks. When it detects a malicious intrusion, Equalizer immediately
blocks the malicious traffic, thus protecting the network and clusters it defends from being
flooded.
Equalizer‘s DDoS protection is based on the collection of traffic statistics in Service
Protection Profiles (SPP). An SPP is essentially an instruction mechanism that “learns” what your
“normal” traffic patterns are on the network or cluster to which it is attached and then processes
the statistical information using proprietary algorithms. It then provides recommendations for
what the upper and lower ranges (thresholds) should be for various packet details for what it sees
as “normal” traffic flow. When the SPPs are set to “Mitigate” mode, they then instruct the system
to drop traffic if the values of the incoming traffic statistics do not fall within the threshold ranges
specified.
How does the SPP learn what your “normal” traffic patterns are? Network level SPPs are Global
SPPs in Equalizer‘s DDoS protection and monitor your entire network to gather traffic statistics.
Application level SPPs must be configured, associated with Equalizer clusters, and then gather
statistics about the traffic flow through the cluster to which it is attached. Initially, both Global and
Cluster SPPs are run in ”Monitor” mode and gather traffic statistics for a period of time that
usually encompasses peak operating times and could be a week, a month, or longer. After you
determine that a sufficient monitoring period has elapsed, you can evaluate the recommended
threshold values generated by the SPPs to determine the Soft/Hard (Minimum/Maximum)
threshold values that you could use to mitigate various types of DDoS attacks. After you set the
thresholds in the SPP, you can then switch to Mitigate mode - allowing the DDoS subsystem to
watch the configured threshold values and determine whether or not to take action to mitigate
attacks when the observed real-time threshold values are between (or above) the Soft/Hard
threshold values.
Equalizer‘s DDoS implementation features the use of an adaptive threshold. The adaptive
threshold is essentially a running “average” of the accumulated traffic history from both monitor
and mitigate modes. This “average” is generated by the DDoS subsystem and used to identify
malicious traffic, for example, when a spike in traffic occurs that may still fall between the soft
and hard thresholds, yet goes above the “averages” on the adaptive threshold.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
671
Security and Protection
The illustration below is a representation of application layer attacks. It shows unsuspecting
computers infected with a virus and networked into a botnet by a hacker. The botnet is then
instructed to flood clusters with malicious traffic, causing a Denial of Service. SPPs are assigned
to clusters, monitor traffic, dynamically update recommended operating thresholds and mitigate
attacks, based on the threshold values configured in the SPPs.
The following subsections provide information on Equalizer‘s DDoS protection including:
l
The features of Equalizer‘s DDoS protection system
l
A discussion of important steps in your initial DDoS deployment
l
Some of the key concepts
l
A discussion of the types of DoS attacks that can be prevented
l
Feature usage work flow
l
Setting up Service Protection Profiles
l
A description of how mitigation works with thresholds
l
672
A discussion of how to monitor activity interpreting the statistical information gathered by
the SPPs.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Equalizer‘s DDoS Protection Features
Equalizer‘s DDoS protection features the following:
Service Protection Profiles (SPPs)
Equalizer uses network (Global) level and application level protection. A global SPP is configured
by default by your system. It continually collects traffic statistics and, in Mitigate mode, monitors
Soft and Hard thresholds for the number of outstanding fragments and the number of outstanding
fragmented packets, and tells the system to drop traffic that falls out of the configured threshold
ranges. Application level SPPs maintain up to 8 sets of counters and thresholds. Each of these
SPPs monitors traffic patterns, computes recommended and adaptive thresholds, and mitigates
traffic based on the configured thresholds. Each application level SPP can be assigned to one or
more clusters.
Traffic Monitoring Graphical Plots
In the GUI, traffic monitoring graphical plots are available for viewing for each SPP and on the
Dashboard display. Monitoring the trends in throughput rates and drop counts is useful as you
fine-tune your detection thresholds.
Initial Monitoring Phase
SPPs “learn” based on inbound and outbound traffic patterns. When both Global and Cluster SPP’s
are in “monitor” mode, they learn about normal traffic patterns. The DDoS subsystem then
processes the statistics to generate recommended soft and hard threshold recommendations. At
the end of the initial monitoring period, you can adopt the system-recommended thresholds
(usually lower than the factory default), as needed. You can then continuously fine tune thresholds
and monitor the results.
Continuous Learning
DDoS prevention begins learning traffic patterns as soon as SPPs are attached to clusters. When
they are in their default monitor mode or if they are in mitigation mode, they never stop
“learning”. They continuously analyze traffic rates and patterns and dynamically adjust the
recommended thresholds that differentiate between legitimate traffic volume and malicious
traffic.
Granular Attack Detection Thresholds
The DDoS subsystem is designed to monitor thresholds for all network level traffic it sees at Layer
3 and application level traffic it sees at Layer 4 and Layer 7. It tracks throughput, packet rate,
new connections, TCP state transitions, and fragments among other statistics. You can set
thresholds on the appropriate traffic parameter to limit traffic for particular systems or
applications.
Slow Connection Detection
Slow connection build up is used as a mechanism to overload backend servers. Equalizer‘s DDoS
subsystem can identify these types of attacks by monitoring thresholds for partial requests. When
an attack is detected, the system “aggressively ages” the connections, recovering resources for
protected servers.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
673
Security and Protection
First Time Deployment
There are several things to consider in the first time deployment of DDoS with Equalizer.
Determine an Appropriate Monitoring Period
It is extremely important to utilize the monitoring period to where traffic history and statistics
that are accumulated by SPPs establish a strong baseline on which to base recommended soft and
hard thresholds. It is recommended that the period of time used to monitor statistics
encompasses peak operating times. This period could be a week, a month, or longer.
Deciding on Threshold Values
After the monitor period has concluded and you are ready to start mitigation, unless your are
thoroughly familiar with the traffic patterns through your appliance, it is recommended that you
use the recommended soft and hard threshold values for the specific type of traffic statistics in
each SPP.
There is, of course, the possibility that you observe an anomaly during the monitor period such as
a spike in traffic during a certain time frame. You could then note the value of the traffic
parameter in the SPP graphical plot and adjust the hard threshold parameter accordingly in the
threshold settings.
Activating Mitigation
After mitigation is turned ON, it is recommended that you review traffic statistics regularly and
observe any anomalies that may appear in the plots on the GUI’s SPP Reporting screen and on the
dashboard.
674
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Some Key Concepts
Is your system vulnerable to a DDoS Attack?
In a DDoS attack, a program is covertly sent to other, unsuspecting computers. Although their
owners are unaware of it, they have been set up to forward malicious transmissions to other
computers.These computers, called "agents" or "zombies", act on behalf of the sender to launch
attacks against targeted systems. A network of these agents or zombie computers is called a
"botnet".
To avoid detection,the attackers try to mimic the behavior of a large number of clients so that
they appear inconspicuous. The resulting attacks are hard to defend against using standard
techniques, because the malicious requests may seem legitimate, however, their intent is very,
very different.
At a predetermined time, all of the zombie computers can be made to attempt repeated
connections to the hacker’s targets. If the attack is successful, it can deplete system or network
resources, thereby denying service to legitimate users.
E-commerce sites, domain name servers, web servers, and email servers are all vulnerable to
these types of attacks.
What is Network Behavioral Analysis
Network Behavior Analysis (NBA) is a method of enhancing the security of a network by
monitoring traffic and noting unusual actions or departures from normal operation. A detailed
analysis and/or control of traffic flow is generated to effectively mitigate attacks. A baseline of
traffic patterns is established, during monitor mode in which Equalizer only “listens” or monitors
without acting on any conditions. The monitoring period is required to learn what “normal” traffic
behavior is for your system. The listening period should be typical, in the sense that no attacks or
unusual traffic patterns should be present. For example, weekends are probably not good days to
build a baseline for a corporate server that is much busier during the work week. Periods of
unusually high or low traffic also make poor monitoring periods, such as holiday weeks.
Once a baseline is established and SPPs are placed in mitigate mode, Equalizer watches for
deviations from the known traffic patterns to detect anomalies.
Adaptive Threshold
SPPs continually monitor traffic activity, whether in the monitoring period of during mitigation.
The monitoring period should be typical, in the sense that no attacks or unusual traffic patterns
should be present. During the monitoring period Equalizer “learns” normal traffic patterns and
establishes hard and soft threshold values it determines are “normal” and “recommends” them for
each SPP. It also establishes an “average” of the traffic activity over the same time frame. This is
the “Adaptive Threshold”. If, for example, there is a spike in traffic activity that exceeds the
adaptive threshold value, yet still falls below the hard threshold, this is identified as potentially
malicious traffic and will be dropped if in mitigation mode.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
675
Security and Protection
Attack Types Prevented
Network Level Attack Types
These types of attacks affect the entire IP stack on a global level and include:
Layer 3 (IP) attacks
1. IP Fragmentation - IP Packet fragmentation assures that IP datagrams can flow through
any other type of network. It allows datagrams created as a single packet to be split into
many smaller packets for transmission and reassembled at a receiving host. A DDoS attack
can deny services to the network by creating a fragmented datagram of a large enough size
to overrun the buffers in your router.
2. IP Reputation - See "Using the IP Reputation Database" on page 704
3. Access Control Lists - See "Using Access Control Lists" on page 716
Application Level Attack Types
These types of attacks types are specific to Layer 4 or Layer 7 clusters and include:
Layer 4 (TCP/UDP) attacks
1. SYN Flood - In a SYN Flood, a cluster receives an overwhelming number of SYN packets
but the TCP connections are never closed! In the TCP handshake process, a client sends the
SYN request and receives a SYN-ACK response from the server. To complete the
connection, the server requires the client to respond with an ACK request. In a SYN flood
attack, that ACK response will not be coming! SYN requests will just continue and can
consume the target‘s resources in order to process incoming SYN packets.
2. Slow Data - A Slow Data attack sends legitimate application layer requests but reads
responses very slowly. With that, it may attempt to exhaust the target’s connection pool.
Slow reading advertises a very small number for the TCP Receive Window size and at the
same time by emptying the client’s TCP receive buffers slowly. That ensures a very low
data flow rate.
3. Connection Flood - A Connection Flood refers to an overwhelming amount of connections
attempting to flood a victimized Equalizer at the same time. This can be from a single IP
address or from a botnet.
676
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Layer 7 (HTTP) attacks
These types of attacks are specific to Layer 7 HTTP and HTTPS and include:
1.
Slowloris -A Slowloris attack attempts to keep many connections to the target open, and
keep them open for as long as possible. It accomplishes this by opening connections and
sending partial requests. Periodically, it sends subsequent HTTP headers, adding to—but
never completing the request. The target will keep these connections open, filling the
maximum concurrent connection pool, eventually denying additional connection attempts
from clients. Each Layer 7 connection maintains a minimum header throughout.
2. HTTP Method Flood - When an HTTP client talks to an HTTP server, it sends requests
which may use GET and POST methods. A GET request is what is used for "normal links",
including images; such requests are meant to retrieve a static piece of data. The URL points
to that piece of data. When you enter a URL, a GET request is made. POST requests are used
with forms. A POST request includes parameters, which are usually taken from input fields
on a page. When flooding, an attacker wants to overwhelm the target server with many
requests, to saturate the target’s resources.
3. Slow POST - Slow POST attacks are where the attacker slowly sends HTTP requests, one at
a time, to a web server. If an HTTP request is not complete, or if the transfer rate is very
low, the server keeps its resources busy waiting for the rest of the data. When the server’s
concurrent connection pool reaches its maximum, this creates a denial of service.
4. Slow Read - In a Slow Read attack, the attacker sends legitimate HTTP requests, and read
responses slowly aiming to keep as many connections as possible in an active state.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
677
Security and Protection
Recorded and Analyzed Packet Details
The following packet information is collected in both monitor and mitigation modes in order to
analyze, detect and mitigate an attack:
l
Source IP
l
Destination IP
l
Destination Port
l
Protocol: UDP/TCP/ICMP
l
IP Fragmentation (global rate)
l
ICMP- specific
l
Type rate (global, per-source, per-destination)
l
678
Code rate (global, per-source, per-destination)
l
Packet rate (per-source, per-destination)
l
Bit rate (per-source, per-destination)
l
Connection rate (per--source, per-destination)
l
Established connections
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Global and Cluster Traffic Statistic Thresholds
Traffic statistic thresholds used in preventing attacks that affect the entire IP stack are
configurable on a global level SPP. Mitigation for global level SPPs can include up to three
thresholds and can include the following types of packet statistics:
l
l
Outstanding Fragments - IP fragmentation breaks up a single IP datagram into multiple
packets of smaller size. These thresholds represents the number of fragments contained in
a packet that have not been reassembled.
Outstanding Fragmented Packets - these thresholds represent the number of IP datagrams
that cannot be fully reassembled due to missing data.
Refer to "Setting Up Equalizer‘s Service Protection Profiles" on page 681 for details on configuring
global level SPPs.
Attack prevention that is specific to TCP and is configurable in an SPP is attachable to Layer 4 or
Layer 7 clusters. Mitigation for each SPP can include using up to eight thresholds. They include
following types of traffic statistics:
l
l
l
l
l
l
l
l
SYN rate/client (SYN/sec) - this threshold represent the number of TCP packet synch
requests from a client per second.
Active Conn/client - these thresholds represent the allowable open connections per client.
Active Conn/SPP - these thresholds represent the number of open connections per SPP
attached to clusters, regardless of client.
Conn rate/SPP (conn/sec) - these thresholds represent the number of allowable connections
per second on an SPP attached to a cluster.
Conn rate/client (conn/sec) - these thresholds represent the number of allowable
connections per second on a client, regardless of SPP.
HTTP header min tput (Kbps) - these thresholds represent the minimum number of kilobits
(1000 bits) that you need to be receiving for an HTTP header before a connection is allowed.
HTTP data min tput (Kbps) - these thresholds represent the minimum number of kilobits
(1000 bits) in a HTTP request payload (such as POST) in order to allow requests.
Conn Quality Ratio - these thresholds represent the ratio of Layer 7 Bad connections vs.
Total Number of connections.
Refer to "Setting Up Equalizer‘s Service Protection Profiles" on page 681
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
679
Security and Protection
Feature Usage Workflow
The following are the basic feature usage phases when using Equalizer‘s DDoS protection.
Initial Setup
In the initial setup a global SPP is configured by default. The global SPP is always enabled and
always gathers statistics. You can choose to use only the global SPP, or add additional cluster
SPPs that can be attached to more than one cluster. DDoS works through a single global SPP and
one or more cluster SPPs.
Monitoring
Initially, all SPPs are set to monitor mode (gathering statistics only) for a period of time that
encompasses peak operating times. This period could be a week, a month, or longer.
Setting Thresholds
After an initial monitoring period has elapsed, recommended soft and hard threshold values
reported by the SPPs should be examined and a determination as to whether the recommended
settings should be used to mitigate malicious traffic is made.
Initiating Mitigation
Once all desired thresholds are set to the desired values, you can switch to mitigate mode. In this
mode, the DDoS subsystem watches the threshold values that you set and takes action to mitigate
attacks when the observed real-‐time threshold values are between (or above) the Hard or Soft
values.
Log Analysis
All DDoS-related activity over time should be monitored using the GUI’s dashboard and the SPP
Reporting graphical plots. Adjustments should be made to the threshold values, as needed.
680
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Setting Up Equalizer‘s Service Protection Profiles
Service Protection Profiles (SPP) serve four purposes:
1. Setting Monitor or Mitigate Mode
2. Configuring Threshold Values
3. Reporting for Threshold Fine Tuning. (See "Monitoring Attack Activity and Other System
Information" on page 701)
4. Instructing the system to watch the configured threshold values and to take action when
statistical values fall out of the threshold ranges configured.
By default, a Global level SPP is available and provides network level attack prevention when in
Mitigate mode. The packet statistics compiled with Global SPPs includes:
l
Outstanding Fragments
l
Outstanding Fragmented Packets
The Global SPP is in Monitor mode, by default, and continually accumulates and analyzes traffic
statistics unless statistical compilation has been disabled on either of the two types of statistics.
Cluster level SPPs can be attached to UDP, TCP, L7TCP, L7 HTTP, and L7 HTTPS clusters. The
cluster packet statistics compiled with the cluster SPPs can include:
l
SYN rate/client (SYN/sec)
l
Active Conn/client
l
Active Conn/SPP
l
Conn rate/client (conn/sec)
l
Conn rate/SPP (conn/sec)
l
HTTP header min tput (Kbps)
l
HTTP data min tput (Kbps)
l
Conn Quality Ratio
Each of the statistical types are configured with Soft Limits (Lower value threshold)and Hard
limits (Higher value threshold). As statistics are compiled during the monitor phase, Equalizer will
suggest Recommended Soft and Hard limits, based on the traffic patterns. These statistical types
will also continually accumulate and analyze traffic all the time. A disable flag determines if that
threshold will be used to drop traffic when the SPP is in mitigate mode.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
681
Security and Protection
Operational Modes
The following two operational modes are used with DDoS protection and are enabled or disabled
on each Global or Cluster SPP.
Mode
Description
Monitor
Once a cluster SPP is attached to a cluster (or clusters) in the default Monitor
mode, the DDoS subsystem monitors system (or cluster) operations,
determining each threshold’s recommended settings based on the statistics
that it gathers.
Mitigate
When the Mitigate option is selected, the DDoS subsystem examines traffic
violates the configured soft and hard threshold settings, the system can then
drop malicious traffic.
682
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Global SPPs
A global SPP is available by default on your system. It continually collects traffic statistics and, in
Mitigate mode, enforces Soft and Hard thresholds for number of outstanding fragments and the
number of outstanding fragments per packet, and tells the system to drop traffic that falls out of
the configured threshold ranges.
The procedures that follow discuss what the types of global traffic statistics are and how threshold
values, based on the collected traffic statistics, are configured.
Global SPP Thresholds
The following thresholds* are used the Global SPPs.
Threshold Value
Outstanding Fragments
Type
Attack type
Layer 3
These thresholds monitor Outstanding
Global Fragments and Outstanding
Fragmented packets to prevent
Fragmentation Flood attacks. It
mitigates many clients (botnet) sending
enough fragments to create a
processing backlog across the system,
as well as low number of clients sending
packets with a lot of fragments.
Outstanding Fragmented Packets
Layer 3
Description
This threshold value is
the minimum and
maximum allowable
fragments in a packet. If
the maximum threshold
is reached, a packet is
dropped.
Soft Limit: 32,000
Hard Limit: 32,000
Mitigation if hard
threshold exceeded:
Packet is dropped. If the
threshold is exceeded at
the time that the system
detects it , packets will
be dropped. If the
current value for one of
these thresholds spikes
and then goes back
under in the course of
the sampling interval, no
packets will be dropped.
This threshold value is
the total outstanding
IPv4 fragmented
packets.
Soft Limit: 200
Hard Limit: 200
Mitigation if hard
threshold exceeded: No
new fragmented packets
will be accepted.
* Hard and soft limits are provided. These represent the minimum (soft limit) and maximum (hard limit) values that can be used
when configuring the traffic parameter in the SPP.
Setting Up Global SPPs in the GUI
By default, the Global SPP already exists on the left navigational pane. You will not need to create
a new SPP, but you will need to configure the Global SPP parameters after a monitoring phase.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
683
Security and Protection
1. Do one of the following to display the Global SPP Summary display on the right:
a. Select Protection > DDoS> Global Service Protection Profile from the left navigational
pane.
b. Select Protection > DDoS on the left navigational pane, select Global SPP on the
DDoS Summary on the right and click on the wrench icon.
The Global Configuration Summary screen will be displayed in Monitor Operational Mode.
2. Use the descriptions in the Global SPPs and the Recommended settings to configure Soft
and Hard threshold settings after the monitoring phase. If you click on the Disable option for
any of the configured thresholds, they will not be used in mitigation.
3. Click on Commit to save the threshold settings.
Enabling and Disabling Mitigation
To enable mitigation for the entire global SPP:
1. Select Protection > Global SPP on the left navigational pane.
2. Select the Mitigate option in the Operational Mode pane on the Configuration Summary screen on
the right configuration pane.
3. Click on Commit to save the change.
If the SPP is set to mitigate and you want to disable individual thresholds on the global SPP
1. Select Protection > Global SPP > on the left navigational pane.
2. Click on Disable for the Threshold that you want to disable.
3. Click on Commit to save the change.
Setting Up Global SPPs in the CLI
By default, the Global SPP already exists. You will not need to create a new SPP, but you will need
to configure the Global SPP parameters after a monitoring phase.
1. Log in to the CLI.
2. View the Global SPP by entering:
684
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
eqcli > show protection gl_spp
Mode
: Monitor
Fragments outstanding (frags):
Soft
: 0
Hard
: 0
Recommended : N/A (soft), N/A (hard)
Adaptive
: 0
Status
:
Fragmented packets outstanding (frag_packets):
Soft
: 0
Hard
: 0
Recommended : N/A (soft), N/A (hard)
Adaptive
: 0
Status
:
eqcli >
You will see that when you initially view the Global SPP and your system has yet to
traverse through a monitoring phase, the Recommended values for soft and hard
thresholds will be “N/A”. In addition, an Adaptive threshold will not be established.
3. Use the descriptions in the Global SPPs and the Recommended settings to configure
Soft and Hard threshold settings after the monitoring phase.
Enabling and Disabling Mitigation
To enable mitigation for the entire Global SPP, enter the following:
eqcli > protection gl_spp flags mitigate
If the Global SPP is set to mitigate and you want to disable either of the thresholds, enter the
following, replacing threshold_name with the name of the threshold to disable.
eqcli > protection gl_spp threshold threshold_name flags disable
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
685
Security and Protection
Cluster SPPs
Cluster SPPs can be attached to one or more UDP, TCP, L7TCP, L7HTTP, and L7HTTPS clusters. The
packet statistics that are compiled by the SPP are based on traffic through the cluster during a
monitoring phase. The threshold descriptions and procedures that follow discuss the types of
traffic statistics and how threshold values, based on the statistics, are configured in a Cluster SPP.
Cluster SPP Thresholds
The following traffic statistic thresholds* are used with Cluster SPPs.
Threshold Value
GUI (CLI)
SYN rate/client (SYN/sec)
(client_syn_rate)
Active Conn/client
(client_active_conx)
686
Cluster
Type
Layer 4
Layer 4
Attack type
Description
This threshold monitors Client SYN
Rate for malicious clients
attempting a SYN Flood Attack.
Only “bad” clients are blocked.
This threshold value
specifies the minimum and
maximum allowable TCP
packet synch requests from a
client per second.
Soft Limit: 10,000,000
Hard Limit: 10,000,000
Mitigation if the hard
threshold is exceeded.
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
This threshold monitors Client
Active Connections and Client
Connection rate for malicious
clients attempting a connection
flood attack. Only “bad” clients are
blocked.
This threshold value
specifies the minimum and
maximum allowable open
connections per client.
Soft Limit: 10,000,000
Hard Limit: 10,000,000
Mitigation if the hard
threshold is exceeded.
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Threshold Value
GUI (CLI)
Active Conn/SPP
(spp_active_conx)
Conn rate/SPP (conn/sec)
(spp_conx_rate)
Conn rate/client (conn/sec)
(client_conx_rate)
Cluster
Type
Layer 4
Layer 4
Layer 7
Attack type
Description
This threshold monitors the SPP
Active Connections of all clients to
the entire SPP during a botnet
connection flood attack. The
purpose is to protect the ADC from
becoming overloaded. The clusters
are unavailable during the attack
as all clients are blocked.
This threshold value
specifies that minimum and
maximum open connections
per SPP attached to a cluster,
regardless of client.
Soft Limit: 10,000,000
Hard Limit: 10,000,000
Mitigation if hard threshold
exceeded.
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
This threshold monitors SPP
Connection rate of all clients to the
entire SPP during a botnet
connection flood attack. The
purpose is to protect the ADC from
becoming overloaded. The clusters
are unavailable during the attack
as all clients are blocked.
This threshold value
specifies the minimum and
maximum allowable
connections per second on
an attached SPP.
Soft Limit: 1,000,000
Hard Limit: 1,000,000
Mitigation if the hard
threshold exceeded.
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
This threshold monitors the SPP
connection rate in connections per
second on clients to detect Slow
Loris attacks. Only malicious
connections are dropped.
This threshold value
specifies the minimum and
maximum allowable
connections per second on a
client, regardless of the
attached SPP.
Soft Limit: 1,000,000
Hard Limit: 1,000,000
Mitigation if hard threshold
exceeded.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
687
Security and Protection
Threshold Value
GUI (CLI)
Cluster
Type
Attack type
Description
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
HTTP header min tput (Kbps)
(header_tput)
HTTP data min tput (Kbps)
(data_tput)
Conn Quality Ratio
(conx_quality)
688
Layer 7
Layer 7
Layer 7
This threshold monitors the HTTP
GET data rate for Slow Read attacks
in kilobits per second.
This threshold value
specifies the minimum
number of bytes per second
that you need to be receiving
for an HTTP (GET) header
before a connection is
allowed.
Soft Limit: 40 Gbps or
(40,000,000 Kbps)
Hard Limit: 40 Gbps or
(40,000,000 Kbps)
Mitigation if below the soft
threshold : Connection is
dropped.
This threshold monitors the HTTP
POST data rate and drops
connections attempting a Slow
Body/Are You Dead Yet attacks in
kilobits per second. Only malicious
connections are dropped
This threshold value
specifies the minimum
number of bytes per second
in a HTTP request payload
(such as POST) in order to
allow requests.
Soft Limit: 40 Gbps or
(40,000,000 Kbps)
Hard Limit: 40 Gbps or
(40,000,000 Kbps)
Mitigation if below the soft
threshold: Connection is
dropped.
This threshold monitors Client
Connection Quality Ratio to block
malicious HTTP clients. It
differentiates malicious clients
from “unlucky” clients by looking at
the quality of all client connections
and not just an individual
connection. Only malicious clients
are blocked.
This is the ratio of Bad
Connections/Total Number of
Connections.
Soft Limit: 100
Hard Limit: 100
Mitigation if the maximum
threshold is exceeded.
The client will not be blacklist
at the first occurrence. For
each following occurrence,
the client will be blacklisted
for 15 seconds per
occurrence. For example, if a
threshold is exceeded 3
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Threshold Value
GUI (CLI)
Cluster
Type
Attack type
Description
times, the first occurrence
will not result in blacklisting.
45 seconds of blacklisting
will occur when the two
additional threshold
infractions occur.
* Hard and soft limits are provided. These represent the minimum (soft limit) and maximum (hard limit) values that can be used
when configuring the traffic parameter in the SPP.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
689
Security and Protection
Setting up Cluster SPPs using the GUI
The process includes these basic steps:
1. Creating the SPP
2. Attaching the SPP to a cluster
3. Configuring SPP threshold values (After a monitoring phase)
4. Enabling or Disabling mitigation
Creating an SPP
1. Log in to the GUI.
2. Select Protection > DDoS from the left navigational pane. A DDoS Summary will appear on the
right. Click on the + icon to add a new Cluster SPP.
3. Enter a name in the Profile Name box on the Add Cluster Service Protection Profile window. The
name can be up to 51 ASCII characters long.
4. Click on Commit to save the new SPP. The new SPP will also appear when you expand the
Cluster Service Protection Profile branch on the left navigational pane.
690
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
Equalizer Administration Guide
Attaching Cluster SPPs to a Cluster
Now that you have created a new SPP, you will need to attach it to a cluster in order for traffic
statistics through the cluster to begin to accumulate and be analyzed. To do this, you will use the
cluster configuration screens. This is applicable to all UDP, TCP, L7TCP, L7 HTTP, and L7 HTTPS
clusters.
A cluster can have exactly one SPP associated with it, in much the same way as a single Server
Pool is associated with a cluster.
5. Select the cluster from the left navigational pane.
6. Select the Configuration Settings tab on the right configuration pane. The following will be
displayed. The example below is of an L7 HTTPS cluster. The other configuration screens
are similar.
7. Use the Service Protection Profile drop down list to select an SPP to attach to the cluster.
8. Click on Commit to attach the SPP to the cluster.
Copyright © 2015 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
691
Security and Protection
Configuring Cluster SPP Threshold Values
Note - The SPP will be in Monitor operational mode when first created. You must first collect traffic statistics in this
mode before setting soft and hard limit thresholds.
When entering threshold values, you