Manual Chapter : 3-DNS Administrator Guide v2.1: Controlling Network Traffic Patterns

Applies To:

Show Versions Show Versions

3-DNS Controller versions 1.x - 4.x

  • 2.1 PTF-01, 2.1.2, 2.1.0
Manual Chapter


9

Controlling Network Traffic Patterns



Controlling network traffic patterns with production rules

Production rules are a policy-based management tool that you can use to dynamically change how the 3-DNS Controller distributes connections across the network. You can also use production rules to send system administrators notifications of specific events. Production rules are based on triggers, such as time of day, current traffic patterns, or current traffic volume. For example, you can configure a production rule that changes the load balancing mode to QOS during your peak business hours, and you can configure a production rule that notifies you when the number of name resolution requests exceeds a specific number.

You can create production rules that apply to the system in general, or you can create production rules for specific wide IPs.

If you want to configure basic production rules, we recommend that you use the Configuration utility. If you want to create custom production rules, you should review the following section, Working with the production rules scripting language, on page 9-7 , which describes the scripting language you use to configure production rules manually. You may also want to contact a technical support engineer for additional assistance with complex configurations.

Setting up production rules in the Configuration utility

The Configuration utility uses a wizard-style format to help you set up production rules. The screen prompts that you see during the configuration process vary, depending on the items you select in each screen. However, to configure any production rule, you perform three basic steps:

  • Define the type of rule
    There are two types of rules: global production rules and wide IP production rules.
  • Define the rule trigger
    There are two types of rule triggers: a set time or time interval, and specific system events.
  • Define the action taken
    There are two basic types of rule actions: sending user-definable messages to log files or email accounts, and changing specific load balancing settings.

    The following sections discuss each production rule option in detail, and provide all of the information you need to complete the production rule using the wizard.

Viewing, adding, and deleting production rules

When you click Production Rules in the Configuration utility, the Production Rules wizard screen opens. The screen displays the list of existing global and wide IP production rules. You can add a new rule by clicking the Add Production Rule toolbar button, which starts the production rule wizard. The wizard prompts you to specify the various production rule options, and then allows you to review your selections before you save the production rule to the configuration.

Note that you can modify existing production rules by clicking the rule name in the list, and you can delete a production rule at any time by clicking the Delete button (trash can icon) next to the rule name.

Choosing the rule type

The first step in the production rule wizard is to choose whether the production rule is a global production rule or a wide IP production rule.

  • Global production rules
    Global production rules send messages to log files or to specific email accounts, based on a set time interval or on standard events. The standard events are listed and described in the following section.
  • Wide IP production rules
    Wide IP production rules are based either on the time of day, or on standard events. Wide IP production rules can change the current load balancing modes for the preferred, alternate, or fallback methods; they can reconfigure ratio settings for individual virtual servers; and they can reconfigure the coefficients for Quality of Service mode. Wide IP production rules can also send messages to log files or email accounts.

    After you choose a rule type, the wizard prompts you to name the rule and allows you to add a brief description of the rule.

Defining time-based triggers

The next step in the wizard prompts you to choose a trigger for the production rule. There are two basic types of triggers that you can set up: time-based triggers and event-based triggers. This section describes the options for the time-based triggers, and the following section describes options for the event-based triggers. Once you review the information for the type of trigger you want to set up, you can skip to the section about choosing an action on page 9-7 .

Time-based triggers include two types: global production rules trigger on set time intervals, while wide IP production rules trigger at specific times on specific days. To set a time interval for a global production rule, you define the number of seconds that elapse between each action the production rule executes.

A wide IP production rule can trigger at a specific time of day, on a specific day of the week, on a specific date, or at a specific time on a specific date. The following procedures explain how to set up each type of time trigger for wide IP production rules.

To apply a time of day variable

  1. From the Time Variable table, select Time.
  2. From the Start Time, Hour box, select the hour you want the production rule action to begin.
  3. From the Start Time, Minutes box, select the minute you want the production rule action to begin.
  4. From the Stop Time, Hour box, select the hour you want the production rule action to stop.
  5. From the Stop Time, Minutes box, select the minute you want the production rule action to stop.

    Once you define the time of day that triggers the production rule, you continue with the wizard and begin to define the production rule action.

To apply a day of the week variable

  1. From the Time Variable table, select Day. A table appears from which you select the day to start and stop the action.
  2. From the Start Day box, select the day you want the production rule action to begin.
  3. From the Stop Day box, select the day you want the production rule action to stop.

    Once you define the day of the week that triggers the production rule, you continue with the wizard and begin to define the production rule action.

To apply a date variable

  1. From the Time Variable table, select Date. A table opens from which you select the date to start and stop the action.
  2. In the Start Date box, type the date you want the production rule action to begin (mm/dd/yyyy).
  3. In the Stop Date box, type the date you want the production rule action to stop (mm/dd/yyyy).

    Once you define the date that triggers the production rule, you continue with the wizard and begin to define the production rule action.

To apply a combined date and time variable

  1. From the Time Variable table, select Date/Time.
    Two tables open and you select the start and stop dates and times.
  2. In the Start Date box, type the date you want the production rule action to begin (mm/dd/yyyy).
  3. In the Stop Date box, type the date you want the production rule action to stop (mm/dd/yyyy).
  4. From the Start Time, Hour box, select the hour you want the production rule action to begin.
  5. From the Start Time, Minutes box, select the minute you want the production rule action to begin.
  6. From the Stop Time, Hour box, select the hour you want the production rule action to stop.
  7. From the Stop Time, Minutes box, select the minute you want the production rule action to stop.

    Once you define the date and time that triggers the production rule, you continue with the wizard and begin to define the production rule action.

Defining event-based triggers

Both global production rules and wide IP production rules can trigger on standard events, such as when a name resolution process begins. Wide IP production rules support two additional types of event-based triggers. You can set a wide IP production rule to trigger when a specific LDNS server makes a name resolution request, or to trigger when a user-specified number of name resolution requests are received by the 3-DNS Controller.

Standard events that can trigger both global and wide IP production rules includes:

  • ResolveNameBegin
    The production rule takes action each time the 3-DNS Controller receives a new resolution request.
  • ResolveNameEnd
    The production rule takes action each time the 3-DNS Controller completes a name resolution.
  • FallbackToStatic
    The production rule takes action each time the fallback load balancing method is used in a wide IP.
  • SIGINT
    The production rule takes action each time the 3-DNS Controller receives a SIGINT command.
  • SIGHUP
    The production rule takes action each time the 3-DNS Controller receives a SIGHUP command.
  • ReapPaths
    The production rule takes action each time the 3-DNS Controller reaps obsolete path information.
  • CRC_Failure
    The production rule takes action each time iQuery communication on the 3-DNS Controller experiences a CRC failure.
  • DownServer
    The production rule takes action each time the 3-DNS Controller detects that another 3-DNS Controller, BIG-IP Controller, or host server becomes unavailable.
  • DownVS
    The production rule takes action each time the 3-DNS Controller detects that a virtual server becomes unavailable.
  • DoneINT
    The production rule takes action after the wideip.conf file is read on startup (a one-time event).
  • DoneConfigFile
    The production rule takes action each time the 3-DNS Controller configuration is re-read (for example, when an ndc reload command is issued).

Choosing the action

After you specify the production rule trigger, the wizard prompts you to choose the action that the production rule takes. Note that the actions that a production rule can take depend in part on whether the production rule is a global rule or a wide IP rule. For example, both global production rules and wide IP production rules can send user-defined messages to log files, or to specific email accounts, but only wide IP production rules can alter load balancing modes.

  • Sending user-defined messages
    Both global and wide IP production rules can send user-defined messages to the syslog file, or to a specific email account.
  • Changing the load balancing mode settings
    Wide IP production rules can change load balancing mode settings for the wide IP. You can change the preferred, alternate, and fallback methods, and you can change QOS coefficient settings.
  • Changing virtual server ratios
    You can change virtual server ratios to alter the distribution load when the load balancing mode is set to Ratio.
  • Specifying a virtual server to return
    You can specify that the 3-DNS Controller return a specific virtual server, rather than choosing a virtual server using load balancing.

    Once you specify an action, the production rules wizard prompts you to review all of the production rule settings, and then saves the production rule to the configuration.

Working with the production rules scripting language

The production rules scripting language uses constructs and statements that are similar in syntax to Perl script and the C programming language. If you have a good working knowledge of Perl or C, you may want to create your own custom production rules. You can use the guidelines in this section in conjunction with the examples provided both here and in the sample wideip.conf file (installed on the 3-DNS Controller and also available in Appendix A).

If you need to add custom production rules to your configuration, but you do not want to work out the implementation yourself, you can contact a professional services representative for assistance.

Inserting production rules in the wideip.conf file

Production rules are part of the wideip.conf file, and you can either insert them directly in the file, or you can store them in a separate file and include them by reference. If you want to use the Configuration utility to manage the 3-DNS Controller configuration, you must store manually configured production rules in a separate file and include them by reference. If you attempt to use custom production rules in a file that you edit using the Configuration utility, the production rule syntax may become corrupt.

If you include custom production rules directly in the wideip.conf file, you must manually edit and maintain the wideip.conf file; you cannot use the Configuration utility for configuration administration.

Executing and managing production rules

The 3dscript utility manages and executes production rules according the following guidelines:

  • 3dscript supports conditional execution of production rules using the if statement. You can use if statements in wide IP production rules, and in global production rules only if they are embedded within a when or an every statement.
  • 3dscript supports event-driven execution of production rules using the when statement. You can use the when statement only in global production rules.
  • 3dscript supports periodic execution of production rules using the every statement. You can use the every statement only in global production rules.
  • Each production rule is uniquely identified by a label.
  • Each production rule can be deleted using its label.
  • All production rules at the global scope can be deleted.
  • All production rules at the wide IP-pool scope can be deleted.
  • Each production rule can be replaced.
  • Each production rule can be annotated with a character string.

The if statement

The if statement is a standard statement which defines an event condition that triggers a production rule action. Typically you use if statements in wide IP production rules. An if statement must adhere to the following guidelines:

  • The if statement can be specified in the scope of a wide IP pool statement.
  • The if statement can be nested in another if statement.
  • Multiple if statements can be specified in the same scope.
  • The nesting of if statements is unlimited except by the memory capacity of the 3-DNS Controller.
  • The first form of an if statement is:
  if(conditional-expression) { <action> ... }

  • The second form of an if statement is:
  if(conditional-expression) { <action> ... } else { <action> ... }

  • The conditional-expression is composed of one of these:
    • A primitive-expression
    • A primitive-expression followed by a relational-operator followed by a primitive-expression
    • A primitive-expression followed by an arithmetic-operator followed by a primitive-expression
    • Two conditional-expressions joined by a logical-operator
  • The primitive-expression can be one of these:
    • A keyword which is evaluated when the conditional expression is evaluated
    • An intrinsic function which is evaluated when the conditional expression is evaluated
    • A literal value enclosed in full quotes
    • A conditional-expression enclosed in parenthesis
    • A unary-operator followed by a conditional-expression enclosed in parenthesis

  • A logical-operator is either:
    • || (logical OR)
    • && (logical AND)
  • A relational-operator is one of these:
    • == (equality)
    • != (not equal)
    • > (greater than)
    • >= (greater than or equal to)
    • < (less than)
    • <= (less than or equal to)
  • An arithmetic-operator is:
    • mod (modulus)
  • A unary operator is either:
    • ! (unary negation)
    • (unary minus)
  • A keyword is one of the following:
    • day
    • time
    • date
    • datetime
    • ldns_ip
    • wip_ip
    • wip_name
    • wip_num_resolves
    • preferred
    • alternate
    • fallback
    • rtt
    • completion_rate
    • hops
    • packet_rate
    • topology
  • An intrinsic function is either:
    • isLdnsInNet(ip, mask)
    • isLdnsInAS(ip, mask)
  • The precedence of logical, relational, and unary operators is the same as in ANSI-c.

The when statement

The when statement is a standard statement which defines a specific event condition that triggers a production rule action. A when statement can be used only in global production rules, and it must adhere to the following guidelines:

  • The when statement can be specified at the top scope of wideip.conf, after the wide IP definition(s) and before the topology statement.
  • Multiple when statements can be specified in the same scope.
  • Nesting of when statements is not allowed.
  • The form of a when statement is:
  when(event) { <action> ... }

  • An event can be one of the following (see page 9-5 for detailed descriptions of each event):
    • ResolveNameBegin
    • ResolveNameEnd
    • FallbackToStatic
    • SIGINT
    • SIGHUP
    • SIGUSR1
    • SIGUSR2
    • SIGCHLD
    • ReapPaths
    • ReapLdns
    • CRC_Failure
    • DownServer
    • DownVS
    • DoneInit
    • DoneConfigFile

The every statement

The every statement is a standard statement that defines a time interval at which the production rule action triggers, such as every 60 seconds. An every statement can be used only for a global production rule, and it must adhere to the following guidelines:

  • The every statement can be specified at the top scope of wideip.conf, after the wide IP definition(s) and before the topology statement.
  • Multiple every statements can be specified in the same scope.
  • Nesting of every statements is not allowed.
  • The form of the every statement is:
  every(<seconds>) { <action> ... }

Production rule actions

The production rules language supports the following actions. Not all actions apply to all production rule types. For example, the actions that change load balancing settings are valid only for wide IP production rules. Actions such as defining a log string can be used in either global production rules or wide IP production rules. Each action below specifies which production rule types can use it.

  • preferred <lbmode>
    This action changes the preferred load balancing method in a wide IP. You can use this action only in a wide IP production rule.
  • alternate <lbmode>
    This action changes the alternate load balancing method in a wide IP. You can use it only in a wide IP production rule.
  • fallback <lbmode>
    This action changes the fallback load balancing method in a wide IP. You can use this action only in a wide IP production rule.
  • log(<string>)
    This action sends the specified string to the syslog utility, which writes the string to the syslog file. You can use this action in either a wide IP production rule or a global production rule.
  • log2mail(<string>)
    This action sends the specified string to the Sendmail utility, which creates a mail message and forwards it to the administrative email account specified for Sendmail (see the log2mail man page for details about log2mail syntax). You can use this action in either a wide IP production rule or a global production rule.
  • vs(<ip>:<port>).ratio <n>
    This action changes the ratio setting for a specific virtual server in a wide IP pool. You can use this action only in a wide IP production rule.
  • return_vs(<ip:port>)
    This action skips the load balancing process and instead returns the specified virtual server to the requesting client. You can use this action only in a wide IP production rule.

Production rule examples

There are a variety of custom production rules that you may want to implement or expand on for your own network. Other production rule examples are included in the sample wideip.conf file installed on the 3-DNS Controller (and available in Appendix A). Following are examples of these three custom production rules:

  • Load balancing according to time of day
  • Load balancing according to LDNS
  • Hacker detection

Load balancing according to time of day

You can set up production rules ahead of time to deal with future needs and client demands for events. For example, say your company has a software distribution scheduled for release next Tuesday at 5:00 p.m. Pacific Standard Time. The new software will be available for download from the FTP sites at that time, and you expect that during the first week, traffic will be 10 times what it normally is, with frequent bursts during standard work hours, 7 a.m. to 6 p.m. However, the client base spans four time zones with an FTP server farm on the east coast in New York (192.168.101.50), and another on the west coast in Los Angeles (192.168.102.50). The 3-DNS Controller is located on the east coast and runs on Eastern Standard Time. You are willing to accept some network latency in return for guaranteed connections.

Figure 9.1 shows a sample production rule that handles the connections according to the anticipated load at specific times of the day.

Figure 9.1 Load balancing by time of day

 wideip {    
address 192.168.101.50:21
name "ftp.domain.com"
pool {
preferred ratio
address 192.168.101.50 ratio 2
address 192.168.102.50 ratio 1
rule "ftp_balance"
// Night time: qos
if(time > "21:00" && time < "07:00") {
preferred leastconn
}
else {
preferred ratio
// East Coast
rule "east" if(time < "10:00") {
vs.(192.168.101.50).ratio 3
vs.(192.168.102.50).ratio 1
}
// Both coasts are at peak demand
else {
rule "both" if(time < "18:00") {
vs.(192.168.101.50).ratio 1
vs.(192.168.102.50).ratio 1
}
// West Coast
else {
vs.(192.168.101.50).ratio 1
vs.(192.168.102.50).ratio 3

}
}
}
}
}

Load balancing according to LDNS

One interesting application of production rules is when you create a rule that triggers based on a specific LDNS server making a name resolution request. The following example is based on a web site published in three languages: English, Spanish, and Japanese. Suppose that the addresses in the network 10.10.0.0 are allocated to Japanese speakers, and the addresses in the network 10.11.0.0 are allocated to Spanish speakers. The production rule shown in Figure 9.2 uses the address of the requesting LDNS to determine which virtual server should receive the connection.

Figure 9.2 Load balancing by IP address of LDNS

 wideip {    
address 192.168.101.50:80
name "www.domain.com"
pool {
rule "Japanese" if(isLdnsInNet(10.10.0.0, 255.255.0.0)) {
return_vs(192.168.103.50:80)
}
else {
rule "Spanish" if(isLdnsInNet(10.11.0.0, 255.255.0.0)) {
return_vs(192.168.102.50:80)
}
else { // assume English
return_vs(192.168.101.50:80)
}
}

address 192.168.101.50 // English
address 192.168.102.50 // Spanish
address 192.168.103.50 // Japanese
}
}

Hacker detection

Another interesting example of triggering a production rule based on the requesting LDNS server is to take evasive action against known hackers attempting to access your system. The production rule shown in Figure 9.3 sends the hacker to a special server, rather than flat out rejecting the connection. As an alternative, you could change the rule to return a non-routable or non-existent address.

Figure 9.3 Sending a hacker to a specific server

 when(ResolveNameBegin) {    
rule "roach_motel" if(isLdnsInNet(10.20.30.4, 255.255.255.0)) {
// Send this guy to our "roach motel" for hackers.
// This address doesn't need to be listed in any wideip pool.
// It's reserved for us to watch hackers under the microscope.
log2mail("Hacker $ldns_ip came back")
return_vs(192.168.1.46:80)
}
}

A related example, shown in Figure 9.4 , illustrates a production rule that deals with attacks against iQuery communications. The production rule would warn you if the 3-DNS Controller detected a hack attempt against the iQuery protocol, based on a communication failure.

Figure 9.4 Detecting an iQuery failure due to potential attack

 Rule "iQuery_hacked" when(CRC_Failure) {    
log2mail("Got CRC Failure")
}