
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:
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.
l server up - The request is routed to the selected server.
l up/quiesce enabled - The request is routed to the selected server.
l up/hot spare enabled - The request is routed to the selected server.
l 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.
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.
Copyright © 2013 Coyote Point Systems. A subsidiary of Fortinet, Inc.
All Rights Reserved.
329
Equalizer Administration Guide
Kommentare zu diesen Handbüchern