The proper syntax to use is $variable_name$. See the example below:

• $sourceip$ – The source IP address of the request
• $sourceport$ – The source port that was used
• $clientip$ – The IP address of the client
• $clientport$ – The port used by the client
• $host$ – The host named in the request
• $method$ – The method used: GET, POST etc
• $path$ – The path specified in the request
• $querystring$ – The querystring used in the request
• $version$ – The version of the HTTP request in the REQUEST.
• $resp$ – The RESPONSE from the server. eg. 200OK, 404 etc.
• $geolocation$ – The GEO location from where the request originated.

The Evaluation feature allows you to do that.

Let’s look at an example below:

• We have flightPATH rule called Log Spider.
• There is a CONDITION where we examine the REQUEST HEADER and it’s USER-AGENT property to see if it DOES MATCH REG_EX value of Googlebot|Slurp|bingbot|ia_archiver. The | character represents separation of a list of values, in this case, Googlebot, Slurp, bingBot and ia_archiver.
• The rule, through Evaluation, also extracts the USER-AGENT content into a variable called $crawler$.
• The rule then logs an event into the SystemLog with the information on the Spider type, the URL, and the query it used to crawl.

flightPATH Conditions

Condition

Match

Check

flightPATH Actions

The only thing you have to remember is that all operate on a boolean AND basis.

All you need to do is define them, and follow the procedure below.

• In the image above, you can see that we have assigned several flightPATH rules to a Virtual Service.
• All you have to do is highlight a flightPATH rule on the left panel, and then either drag it to the right side, or use the right arrow button to move it.
• Of course, to unassign it, you just do the opposite—drag it to the left panel or use the left arrow button.

You can have as many flightPATH rules assigned to a Virtual Service, and you can also use the flightPATH rule on as many other Virtual Services as you wish.

Also, you can move the assigned flightPATH rules up and down in order by dragging them or using the up and down arrow buttons.

However, we will describe what a flightPATH rule comprises of, and how to construct a simple one.

Let us take a simple problem.

• I have a three websites that are load-balanced across three sets of web servers.
• Site www.a.com is served by web server set A, www.b.com by web server set B, and www.c.com by web server set C.
• I have a single public IP coming into my firewall.
• The public IP is NAT’d from the firewall to the Virtual IP on the EdgeADC.
• I want traffic addressed to each host/domain to be sent to the respective web server set.
• I also want all traffic from Burundi to go to a third single web server.

To achieve this in flightPATH we would need to define three rules, one for each of the web server sets, plus one for redirecting requests from Burundi.

• Navigate to Library > flightPATH. It will look like the image below.

• There are four sections to a flightPATH Rule.
  • Detail – the name of the rule, which Virtual Service it is used in and a description.
  • Condition – These are the conditions that define whether the rule will apply. You can choose from several condition values with relevant Match values, followed by boolean Sense, what to check, and the value to check for. Full details are available in the Administration Guide.
    Multiple Conditions are are enacted on an ‘AND’ basis. Multiple rules should be defined for ‘OR’ usage.
  • Evaluation – Provides the ability to create variables for use in the rule.
  • Action – The actions that will be performed if the Condition is met.
• We will define the following Virtual IPs (VIP) in our ADC.
  • VIP1 = 10.0.0.100 to Real Server(s) 10.0.0.200 (this is a dummy address that must exist).
  • VIP2 = 10.0.0.102 to Real Servers 10.0.0.110,10.0.0.111, 10.0.0.112 (web servers for www.a.com)
  • VIP3 = 10.0.0.103 to Real Servers 10.0.0.114,10.0.0.115, 10.0.0.116 (web servers for www.b.com)
  • VIP2 = 10.0.0.104 to Real Servers 10.0.0.117,10.0.0.118, 10.0.0.119 (web servers for www.c.com)
• So, in our case we need to define the following rules:
  • IF HOST CONTAINS a.com USE SERVER 10.0.0.102
  • IF HOST CONTAINS b.com USE SERVER 10.0.0.103
  • IF HOST CONTAINS c,com USE SERVER 10.0.0.104
  • IF GEO LOCATION DOES EQUAL BURUNDI USE SERVER 10.0.0.120
• The first rule will look like the below image. We have removed the distracting information and only included the rule.

You will need to do the same with the other two rules for b.com and c.com.

Finally, we come to the Country redirection if the country is Burundi.

The final step is to add these to the 10.0.0.100 Virtual IP.

To do this:

• Go to IP Services
• Click on the 10.0.0.100 VIP/VS
• In the Real Servers section click on flightPATH.
• You will see the rules on the left-side scrolling container.
• Locate them and drag-and-drop them to the right-side, or use the right-arrow.
• The result should look like the image below:

The tool offers various functionalities that enhance application delivery and security. For instance, flightPATH can modify HTTP headers and manage redirections, enhancing security by masking sensitive information or preventing information leakage by removing certain HTTP headers. It also provides features like the ability to redirect traffic based on error codes, which helps maintain smooth and efficient web operations.

Furthermore, flightPATH’s advanced features include content switching at Layer 7, which allows decisions on traffic routing to be made based on the content of incoming requests, enhancing the adaptability and efficiency of the load-balancing process. This is particularly useful for applications requiring intelligent management of diverse and dynamic web traffic patterns. The integration of such features ensures that Edgenexus flightPATH provides not just load balancing but a comprehensive suite of tools for optimizing application delivery and security.