Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 4.5.14, 4.5.13, 4.5.12, 4.5.11, 4.5.10
A
3-DNS Configuration File
Overview of the 3-DNS configuration file
The 3-DNS configuration file, wideip.conf, describes the components in a global network, and the services that are available on those components. Note that when you use the browser-based Configuration utility, all components of the 3-DNS configuration file are automatically generated and parsed.
If you use the Configuration utility to configure the 3-DNS Controller, and you want to see the wideip.conf configuration for a specific component, click the Configuration View button (
) when you see it in the Configuration utility.
The wideip.conf file consists of two types of information: statements and comments. The wideip.conf file should include at least the following definitions.
- A datacenter statement
- At least one box statement
- At least one server statement defining a 3-DNS Controller
- At least one virtual server, which is defined as part of a server statement for one of these objects: BIG-IP system, EDGE-FX system, or host
- A wideip statement, for load balancing
If the wideip.conf file lacks complete definitions, one of the following happens:
- If the file cannot be parsed, 3dnsd does not start.
- If the file can be parsed, the 3-DNS Controller reverts to standard DNS behavior.
To edit the 3-DNS configuration file, wideip.conf
- To ensure that the configuration files contain the same information as the memory cache, type the following command:
3ndc dumpdb
- Open the wideip.conf file in a text editor (either vi or pico).
- Make any changes to the configuration that you want to make.
- Save and close the file.
- Commit the changes to the configuration by typing:
3ndc reload
Using include files
Include files are files that contain configuration information about one aspect of your network, and are listed in the wideip.conf configuration file. For example, you can have one include file that defines the topology records for load balancing, and another include file that contains local DNS server and path information.
Using include files reduces the size of the wideip.conf file and makes it easier to manage your configuration. The 3-DNS Controller automatically creates and implements include files whenever you configure your network setup using the Configuration utility.
When the wideip.conf file is generated by the Configuration utility, any comments you incorporated from the command line are deleted.
Syntax for include files
Use the syntax shown in Figure A.1 when incorporating include files into a wideip.conf file.
include root_in "/config/3dns/include" include root_out "/config/3dns/include" include topology "topology.inc" include geoloc "netIana.inc" include ldns "ldns.inc" include region "region.inc" |
Definitions of include statements
Table A.1 lists the include statements in the wideip.conf file, their descriptions, and their default file names.
|
Parameter |
Description |
Default file name |
|---|---|---|
|
include root_in |
Specifies the root directory from which to get include files. Enclose all file names in quotation marks. |
/config/3dns/include |
|
include root_out |
Specifies the root directory in which to dump include files. |
/config/3dns/include |
|
include topology |
Specifies the name of the file that contains the topology statement. |
topology.inc |
|
include geoloc |
Specifies the name of the file that contains the IP geo-classification database. It is important that you do not edit this statement. |
netIana.inc |
|
include ldns |
Specifies the name of the file that contains information about local DNS servers and path information. |
ldns.inc |
|
include region |
Specifies the name of the file that contains any region definitions statements. |
region.inc |
Working with statements
A top-level statement in the wideip.conf file begins with a keyword, and may be followed either by a value or by a block of sub-statements enclosed in braces ( {} ).
The 3-DNS platform supports the following top-level statements.
- include
The include statement lists any include files that are configured on the 3-DNS Controller. - globals
The globals statement defines system-level settings for any 3-DNS Controller configuration options, and sets the defaults for other statements. - datacenter
The datacenter statement defines the group of 3-DNS Controllers, BIG-IP systems, EDGE-FX systems, routers, and hosts that reside in a single physical location. - box
The box statement defines the attributes of the physical device that the 3-DNS software, BIG-IP software, EDGE-FX software, router, or host runs on. - server
The server statement defines any of the following objects: a 3-DNS Controller, a BIG-IP system, an EDGE-FX system, a router, or a host. - sync_group
The sync_group statement defines the group of 3-DNS Controllers and Link Controllers that synchronize their configuration settings and metrics data. - wideip
The wideip statement defines a wide IP and the pool or pools that are used for load balancing. A wide IP maps a domain name (for example, stocks.siterequest.com) to a load balancing mode and a set of virtual servers that serve the content for the domain. - topology
The topology statement contains the topology records that facilitate the topology load balancing mode (on its own and as part of the Quality of Service mode). Note that the topology statement is the preferred location for topology configuration information.
Syntax rules
Keep the following rules in mind when creating and editing statements in the wideip.conf file.
- Statement order
Statements should appear in this order in the wideip.conf file:
- globals statement
- include statement
- datacenter statement
- box statement
- server statement
- sync_group statement
- wideip statement
- globals statement
- Address and port specification
For virtual servers, the port specification must immediately follow the IP address specification. For the port specification, you can use either a port number, or a service name. For example, you can use "http" instead of 80 to represent the HTTP protocol. The address and port specification can take any of the following forms:
address <ip_address>:<port>
address <ip_address>
port <port>address <ip_address>
service <"http">
This chapter contains several syntax examples. For an overview of the typography conventions in the syntax examples, see Identifying command syntax .
The globals statement
The globals statement contains the global options that are used by the 3-DNS Controller, and must appear before any other statements in the wideip.conf file. Each globals sub-statement has a default setting, and you do not need to edit the globals statement unless you want to change a default setting.
If you use a globals sub-statement more than once, the 3-DNS Controller uses the last listed value, and does not generate an error message. For example, if your globals statement contains the parameters shown in Figure A.2 , the 3-DNS Controller uses the value 50 for the time-to-live for metrics collected from a BIG-IP system.
Syntax for the globals statement
The globals statement supports the following sub-statements. When you define a globals statement, you need to include only those sub-statements that you want to change from the default.
globals { [ time_tolerance <number> ] [ autosync < yes | no > ] [ autoconf <yes | no> ] [ encryption < yes | no > ] [ encryption_key_file <string> ] [ check_static_depends < yes | no > ] [ check_dynamic_depends < yes | no > ] [ default_persist_ttl < <number> s | m | h | d | w | M | y > ] [ default_probe_limit <number> ] [ persist_ldns < yes | no > ] [ persist_mask <ip_address> ] [ drain_requests < yes | no > [ timer_get_3dns_data <number> ] [ timer_get_server_data <number> ] [ timer_get_host_data <number> ] [ timer_get_vs_data <number> ] [ timer_get_ecv_data <number> ] [ timer_get_path_data <number> ] [ timer_get_trace_data <number> ] [ timer_get_link_data <number> ] [ timer_get_link_status <number> ] [ timer_get_autoconfig_data <number> ] [ timer_check_keep_alive <number> ] [ timer_persist_cache <number> ] [ timer_sync_state <number> ] [ dc_prefix <string> ] [ 3dns_ttl <number> ] [ bigip_ttl <number> ] [ edgefx_ttl <number> ] [ host_ttl <number> ] [ vs_ttl <number> ] [ path_ttl <number> ] [ trace_ttl <number> ] [ link_ttl <number> ] [ default_ttl <number> ] [ rtt_timeout <number> ] [ rtt_sample_count <number> ] [ rtt_packet_length <number> ] [ rx_buf_size <number> ] [ tx_buf_size <number> ] [ dump_topology < yes | no > ] |
[ qos_coeff_rtt <number> ] [ qos_coeff_completion_rate <number> ] [ qos_coeff_packet_rate <number> ] [ qos_coeff_topology <number> ] [ qos_coeff_hops <number> ] [ qos_coeff_vs_capacity <number> ] [ qos_coeff_kbps <number> ] [ qos_coeff_lcs <number> ] [ qos_factor_rtt <number> ] [ qos_factor_completion_rate <number> ] [ qos_factor_packet_rate <number> ] [ qos_factor_topology <number> ] [ qos_factor_hops <number> ] [ qos_factor_vs_capacity <number> ] [ qos_factor_kbps <number> [ qos_factor_lcs <number> [ default_alternate < ga | null | random | ratio | static_persist | packet_rate | leastconn | return_to_dns | rr | topology | vs_capacity | kbps | drop_packet | explicit_ip > ] [ default_fallback < completion_rate | ga | hops | leastconn | null | packet_rate | qos | random | ratio | return_to_dns | rr | rtt | topology | vs_capacity | static_persist | kbps | drop_packet | explicit_ip > ] [ fb_respect_depends < yes | no > ] [ fb_respect_acl < yes | no > ] [ aol_aware < yes | no > [ path_duration <number> ] [ ldns_duration <number> ] [ prober <ip_address> ] [ resolver_tx_buf_size <number> ] [ resolver_rx_buf_size <number> ] [ use_alternate_iq_port < yes | no > ] [ multiplex_iq < yes | no > ] [ paths_never_die < yes | no > ] [ rtt_allow_probe < yes | no > ] [ rtt_allow_hops < yes | no > ] [ probe_protocol { [ dns_rev ] [ dns_dot ] [ udp ] [ tcp ] [ icmp ] } ] [ datasize_system <number> ] [ datasize_reap_pct <number> ] [ default_iquery_protocol < udp | tcp > ] [ traceroute_port <number> ] } |
Figure A.4 shows an example of a valid globals statement.
globals { autoconf yes //Auto-discovery is available for servers autosync yes //Synchronization is on time_tolerance 10 //Ten seconds is maximum variance for 3-DNS Controllers times prober 192.168.101.2 // Default prober is New York 3-DNS Controller encryption yes // Encrypt iQuery path_ttl 2400 // Extend the life of path metrics } |
Definition of globals sub-statements
The globals statement can contain some or all of the parameters that are described in the following sections.
Auto-discovery
The auto-discovery sub-statement, autoconf, specifies whether the 3-DNS Controller can gather virtual server information for any servers you define. You can also specify, for individual servers, whether auto-discovery is on. (See Auto-discovery for servers , for more information.) If you disable auto-discovery in the globals statement, you override the autoconf setting in the server statements.
|
Parameter |
Description |
Default |
|---|---|---|
|
autoconf |
Specifies whether the auto-discovery option is available for servers. Note that setting this global variable to no disables auto-discovery for any servers that you may configure. |
yes |
In the Configuration utility, the list of self IPs reported by auto-discovery may not include all self IPs on the system. Auto-discovery reports only public or external addresses, and any associated address translation will not show up in the Configuration utility's self-IP list.
In the Configuration utility, auto-discovery is labeled Discovery.
Synchronization
The synchronization sub-statements specify how the current 3-DNS Controller handles synchronizing its configuration with the other 3-DNS Controllers in the network.
|
Parameter |
Description |
Default |
|---|---|---|
|
autosync |
When autosync is on, the 3-DNS Controller compares file time stamps among the 3-DNS Controllers in your network. When a controller has a file that has a more recent time stamp than the same file on the other 3-DNS Controllers in the network, the controller with the most current file synchronizes that file to the other controllers. |
yes |
|
time_tolerance |
Specifies the variation of time allowed (in seconds) when comparing time stamps on files. File time stamps are included in iQuery messages when they are passed among the 3-DNS Controllers in the network. When a file's time stamp is more than time_tolerance seconds ahead of the time stamp for the same file on another controller, the 3-DNS Controller updates the older file's time stamp with the more recent time stamp. If the difference between the two time stamps falls within the time_tolerance setting, the controller considers the files to be the same and does not overwrite one with the other. Set the time_tolerance global to 0 if you want to disable it. |
10 |
|
sync_gui_rules |
Specifies whether the 3-DNS Controller synchronizes production rules with the other 3-DNS Controllers in the network. |
no |
|
sync_named_conf |
Specifies whether the 3-DNS Controller synchronizes the DNS zone files with the other 3-DNS Controllers in the network. |
yes |
|
sync_timeout |
Specifies the amount of time the controller waits for the synchronization to complete, after the synchronization process for configuration data starts. If the synchronization process does not complete in this time, the controller stops the process, logs an error, and retries the synchronization at the next interval. |
180 |
|
sync_zones_timeout |
Specifies the amount of time the controller waits for the synchronization to complete, after the synchronization process for zone files starts. If the synchronization process does not complete in this time, the controller stops the process, logs an error, and retries the synchronization at the next interval. |
300 |
Encryption
The encryption sub-statements specify whether the communication between the 3-DNS Controller and a BIG-IP system is encrypted.
|
Parameter |
Description |
Default |
|---|---|---|
|
encryption |
Specifies whether to enable encryption for iQuery messages. |
no |
|
encryption_key_file |
Specifies the location and name of the iQuery encryption key file. |
"/etc/F5key.dat" |
Dependencies
The dependencies sub-statements specify whether the 3-DNS Controller checks the availability of virtual servers or paths before the system sends a connection to a virtual server.
|
Parameter |
Description |
Default |
|---|---|---|
|
check_static_depends |
Specifies that the 3-DNS Controller checks the availability of virtual servers on BIG-IP systems, EDGE-FX systems, and hosts before it uses the virtual servers for load balancing. Change this option to no if you want to test your configuration. Setting this option to no forces the virtual servers to have green (up) status indicators on the Virtual Server Statistics screen in the Configuration utility. |
yes |
|
check_dynamic_depends |
Specifies that the 3-DNS Controller checks the availability of a path before it uses the path for load balancing. Changing this option to no overrides the path_ttl and whether the last probe attempt was successful. |
yes |
LDNS persistence
Dynamic load balancing modes and wide IP persistence depend on path information to resolve requests. The value for persist_ldns must be set to yes (the default) so that the 3-DNS Controller stores and uses path information. If you use only static load balancing modes and are not using persistence, you can set persist_ldns to no to conserve memory.
|
Parameter |
Description |
Default |
|---|---|---|
|
persist_ldns |
Specifies whether the 3-DNS Controller records in its cache the IP addresses of all LDNS servers that make resolution requests. |
yes |
Load balancing persistence
The load balancing persistence sub-statements define how the 3-DNS Controller load balances persistent connections.
|
Parameter |
Description |
Default |
|---|---|---|
|
default_persist_ttl |
Specifies the length of time the 3-DNS Controller retains persistent connections information before the information is purged. |
3600 |
|
persist_mask |
Specifies the significant bits of an LDNS IP address to use with the static_persist load balancing mode. The default setting indicates that all 32 bits are significant. |
0xFFFFFFFF |
|
drain_requests |
Specifies whether load-balanced persistent connections are allowed to remain connected, until the TTL expires, when you disable a pool. When set to no, the connections are terminated immediately when the pool is disabled. This variable affects the persist setting in the load balancing sub-statement. See Table A.30 , for more information. |
yes |
Periodic task intervals
The periodic task interval sub-statements define the frequency at which the 3-DNS Controller refreshes the metrics information it collects.
|
Parameter |
Description |
Default |
|---|---|---|
|
timer_get_3dns_data |
Specifies how often the 3-DNS Controller retrieves availability data for other 3-DNS Controllers in the network. You can enter a value between 1 and 3600 seconds. |
20 |
|
timer_get_server_data |
Specifies how often the 3-DNS Controller refreshes 3-DNS Controller, BIG-IP system, and EDGE-FX system information. You can enter a value between 1 and 3600 seconds. |
20 |
|
timer_get_host_data |
Specifies how often the 3-DNS Controller refreshes other host machine information. You can enter a value between 1 and 3600 seconds. |
90 |
|
timer_get_vs_data |
Specifies how often the 3-DNS Controller refreshes virtual server information. You can enter a value between 1 and 3600 seconds. |
30 |
|
timer_get_path_data |
Specifies the minimum interval at which the 3-DNS Controller sends requests for new or updated path information (for example, round trip time or ping packet completion rate) to the big3d agents in the network. Note that if the controller is monitoring a large number of paths, the controller sends the requests to the big3d agents more frequently. You can enter a value between 1 and 600 seconds. |
120 |
|
timer_get_ecv_data |
Specifies how often the 3-DNS Controller refreshes ECV information. You can enter a value between 5 and 3600 seconds. |
90 |
|
timer_get_trace_data |
Specifies how often the 3-DNS Controller retrieves traceroute data (the traceroute utility collects information on router hops between each data center and each LDNS). You can enter a value between 1 and 3600 seconds. |
60 |
|
timer_get_autoconfig_data |
Specifies how often the 3-DNS Controller checks for updated virtual server configuration information, when auto-discovery is enabled. |
30 |
|
timer_get_link_data |
Specifies how often the 3-DNS Controller refreshes link metrics information. |
10 |
|
timer_get_link_status |
Specifies how often the 3-DNS Controller refreshes link availability information. |
2 |
|
timer_check_keep_alive |
Specifies how often the 3-DNS Controller queries remote 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems. This value determines how often 3dnsd sends hello packets to each big3d agent in its configuration. You can enter a value between 1 and 3600 seconds. |
60 |
|
timer_persist_cache |
Specifies how often the 3-DNS Controller writes the wideip.conf file from memory. You can enter a value between 1 and 604800 seconds. |
3600 |
Data time-outs
The data time-out sub-statements set the amount of time for which metrics information is considered valid. After a time-out is reached, the 3-DNS Controller refreshes the information.
|
Parameter |
Description |
Default |
|---|---|---|
|
default_ttl |
Specifies the default number of seconds that the 3-DNS Controller considers a wide IP A record to be valid. If you do not specify a wide IP TTL value when you define a wide IP pool, the wide IP definition uses the default_ttl value. |
30 |
|
3dns_ttl |
Specifies the number of seconds that the 3-DNS Controller considers performance data for the other 3-DNS Controllers to be valid. |
60 |
|
bigip_ttl |
Specifies the number of seconds that the 3-DNS Controller can use BIG-IP system information for name resolution and load balancing. You can enter a value between 1 and 10800. The following relationship should be maintained: |
60 |
|
edgefx_ttl |
Specifies the number of seconds that the 3-DNS Controller can use EDGE-FX system information for name resolution and load balancing. You can enter a value between 1 and 10800. The following relationship should be maintained: |
60 |
|
host_ttl |
Specifies the number of seconds that the 3-DNS Controller can use host information for name resolution and load balancing. You can enter a value between 1 and 10800. The following relationship should be maintained: |
240 |
|
vs_ttl |
Specifies the number of seconds that the 3-DNS Controller can use virtual server information (data acquired about a virtual server from a BIG-IP system, an EDGE-FX system, or host) for name resolution and load balancing. You can enter a value between 1 and 10800. The following relationship should be maintained: |
120 |
|
link_ttl |
Specifies the number of seconds that the 3-DNS Controller can use link information for link load balancing. You can enter a value between 1 and 10800. The following relationship should be maintained: |
31 |
|
path_ttl |
Specifies the number of seconds that the 3-DNS Controller can use path information for name resolution and load balancing. You can enter a value between 1 and 2419200. The following relationship should be maintained: |
2400 |
|
trace_ttl |
Specifies the amount of time (in seconds) that the 3-DNS Controller considers traceroute data, for router hops, to be valid. You can enter a value between 1 and 2419200. |
604800 (seven days) |
Probing and metrics collection
The probing and metrics collection sub-statements define how the 3-DNS Controller collects path information.
|
Parameter |
Description |
Default |
|---|---|---|
|
rtt_timeout |
Specifies, in seconds, how long the big3d agent waits for a response to a probe. You can enter a value between 1 and 10. |
3 |
|
rtt_sample_count |
Specifies the number of packets to send from the big3d agent to the LDNS, host, or host virtual server to determine the path information between those two systems. You can type a value between 1 and 10. |
3 |
|
rtt_packet_length |
Specifies the length of packets, in bytes, to send from the big3d agent to the LDNS to determine the path information between those two machines. You can type a value between 64 and 500; the default value for this setting is 64. |
64 |
|
probe_protocol |
Determines which protocols the 3-DNS Controller uses to probe LDNS servers to calculate path round trip times, and in what order the protocols are used. You can specify one or more of the following protocols: icmp, udp, tcp, dns_dot, and dns_rev. |
icmp |
|
default_probe_limit |
Specifies the number of times that the 3-DNS Controller attempts to probe a failed path before continuing. |
12 |
|
paths_never_die |
Specifies that the 3-DNS Controller should not attempt to refresh path data for a path that has been successfully probed. |
no |
|
check_dynamic_depends |
Specifies that the 3-DNS Controller checks the availability of a path before it uses the path for load balancing. Changing this option to no overrides the path_ttl and whether the last probe attempt was successful. This parameter does not prevent the refreshing of path metrics. |
yes |
|
rtt_allow_probe |
Specifies that the 3-DNS Controller issues probe requests for path metrics to local DNS servers. You can change this setting to no to turn off path probing. |
yes |
|
rtt_allow_hops |
Specifies that the 3-DNS Controller should collect hops metrics when probing paths. |
yes |
|
prober |
Specifies the default prober to perform availability service checks on hosts and host virtual servers. When this option is set to 127.0.0.1, the controller chooses the best big3d agent to probe the host or host virtual server. The best big3d agent is defined as the agent that is closest to the host (for example, a big3d agent on the same link is closer than in the same data center, which is closer than any big3d agent in the network), and has the least number of outstanding probe requests compared to the agent's probe capacity. |
127.0.0.1 |
Resource limits
The resource limits sub-statements define the amount of memory on the 3-DNS Controller that is allocated to sending and receiving metrics information.
|
Parameter |
Description |
Default |
|---|---|---|
|
rx_buf_size |
Specifies the maximum amount of socket buffer data memory the 3-DNS Controller can use when receiving iQuery data. You can enter a value between 8192 and 262144. |
262144 |
|
tx_buf_size |
Specifies the maximum amount of socket buffer data memory the 3-DNS Controller can use when transmitting iQuery data. You can enter a value between 8192 and 262144. |
262144 |
Topology settings
The Topology load balancing mode uses geographic data to determine the best virtual server to send in response to a request. The topology globals affect how the 3-DNS Controller uses the topology and regions include files. For more information about include files, see Using include files . For more information about the Topology load balancing mode, see Chapter 3, Topology .
|
Parameter |
Description |
Default |
|---|---|---|
|
dump_topology |
Specifies whether the 3-DNS Controller writes out the topology statement whenever a configuration change occurs. |
yes |
QOS values
The Quality of Service (QOS) load balancing mode distributes connections based on a path evaluation score. Using the QOS equation shown in Figure A.5 , the Quality of Service mode compares paths between the LDNS and each virtual server included in the wideip statement. When you specify the Quality of Service load balancing mode, the 3-DNS Controller load balances each new connection to the virtual server associated with the best (highest) path score.
score_path = [(qos_coeff_packet_rate) * (1 / score_packet_rate)] + (qos_coeff_rtt) * (1 / score_rtt)] + [(qos_coeff_completion_rate) * (score_completion_rate)] + [(qos_coeff_topology) * (score_topology)] + [(qos_coeff_hops) * (score_hops)] + [(qos_coeff_vs_capacity) * (score_vs_capacity)] + [(qos_coeff_kbps) * (score_kbps)] + [(qos_coeff_lcs) * (score_lcs)] |
The coefficients for the QOS score computation are defined in the globals statement, but you can override them within a wideip statement.
|
Parameter |
Description |
Default |
|---|---|---|
|
qos_coeff_rtt |
Specifies the relative weighting for round trip time when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
50 |
|
qos_coeff_completion_rate |
Specifies the relative weighting for ping packet completion rate when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
5 |
|
qos_coeff_packet_rate |
Specifies the relative weighting for BIG-IP packet rate when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
1 |
|
qos_coeff_topology |
Specifies the relative weighting for topology when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
0 |
|
qos_coeff_hops |
Specifies the relative weighting for hops when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
0 |
|
qos_coeff_vs_capacity |
Specifies the relative weighting for virtual server capacity when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
0 |
|
qos_coeff_kbps |
Specifies the relative weighting for kilobytes per second when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
3 |
|
qos_coeff_lcs |
Specifies the relative weighting for link capacity when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 4294967295. |
30 |
|
qos_factor_rtt |
Specifies the factor used to normalize raw round trip time values when computing the QOS score. |
10000 |
|
qos_factor_completion_rate |
Specifies the factor used to normalize raw completion rate values when computing the QOS score. |
10000 |
|
qos_factor_packet_rate |
Specifies the factor used to normalize raw packet rate values when computing the QOS score. |
10000 |
|
qos_factor_topology |
Specifies the factor used to normalize raw topology values when computing the QOS score. |
10 |
|
qos_factor_hops |
Specifies the factor used to normalize raw hops values when computing the QOS score. |
25 |
|
qos_factor_vs_capacity |
Specifies the factor used to normalize raw virtual server capacity values when computing the QOS score. |
1 |
|
qos_factor_kbps |
Specifies the factor used to normalize raw kilobytes per second values when computing the QOS score. |
1000 |
|
qos_factor_lcs |
Specifies the factor used to normalize raw link capacity values when computing the QOS score. |
1 |
Load balancing
The load balancing sub-statement defines the alternate and fallback load balancing modes.
|
Parameter |
Description |
Default |
|---|---|---|
|
default_alternate |
Defines the default alternate load balancing mode used when the preferred load balancing mode does not provide a resolution. You can override this setting in the wideip statement. |
rr |
|
default_fallback |
Defines the default fallback load balancing mode used when the preferred and alternate load balancing modes do not provide a resolution. You can override this setting in the wideip statement. |
return_to_dns |
|
fb_respect_depends |
Determines whether the 3-DNS Controller respects virtual server status when load balancing switches to the specified fallback mode. |
no |
|
fb_respect_acl |
Determines whether the 3-DNS Controller imposes topology access control when load balancing switches to the specified fallback mode. |
no |
|
aol_aware |
Determines whether the 3-DNS Controller recognizes local DNS servers that belong to the Internet service provider, America Online (AOL). |
yes |
Buffer size
The buffer size sub-statements specify the maximum amount of UDP data that the 3-DNS Controller can receive for wide IP DNS messages.
|
Parameter |
Description |
Default |
|---|---|---|
|
resolver_rx_buf_size |
Specifies the wide IP receive buffer size. The value is overridden only if it is larger than the one first assigned by the kernel. |
262144 |
|
resolver_tx_buf_size |
Specifies the wide IP send buffer size. |
262144 |
Reaping
The 3-DNS Controller stores local DNS server and network path data in memory. The amount of data that can be held in memory at any given time is based on the amount of memory in the 3-DNS Controller. Reaping is the process of finding the least-used data in memory and deleting it.
The default reaping values are adequate for most configurations. Contact your technical support representative if you want to make changes to them.
|
Parameter |
Description |
Default |
|---|---|---|
|
datasize_system |
Specifies the amount of RAM that the 3-DNS Controller reserves for system usage, such as non-3-DNS specific processes. Note that the system determines the value for this variable. |
varies by system |
|
datasize_reap_pct |
Specifies what percentage of memory that the 3-DNS Controller frees up during the reap process. |
15 |
|
path_duration |
Specifies the number of seconds that a path remains cached after its last access. You can type a value between 60 and 31536000 (one year). |
604800 (7 days) |
|
ldns_duration |
Specifies the number of seconds that an inactive LDNS remains cached. Each time an LDNS makes a request, the clock starts again. You can type a value between 60 and 31536000 (one year). |
2419200 |
iQuery port options
The iQuery port options determine which port (or ports) the 3-DNS Controller uses to send and receive iQuery traffic.
|
Parameter |
Description |
Default |
|---|---|---|
|
use_alternate_iq_port |
Determines whether the 3-DNS Controller runs iQuery traffic on port 245 (the port used in older configurations), or on port 4353, the iQuery port registered with IANA. The default setting, yes, uses port 4353. To use port 245, change this setting to no. This setting is used only by UDP-based traffic. |
yes |
|
multiplex_iq |
Determines whether the 3-DNS Controller uses the ephemeral ports for iQuery traffic returned from the big3d agent. The default setting forces iQuery traffic to use a single port defined by use_alternate_iq_port for all iQuery traffic. |
yes |
The datacenter statement
A datacenter statement defines the group of 3-DNS Controllers, BIG-IP systems, EDGE-FX systems, routers, and hosts that reside in a single physical location.
Syntax for the datacenter statement
The datacenter statement uses the following syntax.
datacenter { name <"data center name"> [ location <"location info"> ] [ contact <"contact info"> ] [ 3dns <ip_address | "name"> ] [ bigip <ip_address | "name"> ] [ edgefx <ip_address | "name"> ] [ router <ip_address | "name"> ] [ host <ip_address | "name"> ] } |
Figure A.7 shows an example of a valid datacenter statement.
datacenter { name "New York" location "NYC" contact "3DNS_Admin" 3dns 192.168.101.2 bigip 192.168.101.40 edgefx 192.168.101.50 router 192.168.101.254 host 192.168.105.40 } |
Definition of datacenter sub-statements
The datacenter sub-statements specify a name for the data center and the machines it contains.
|
Parameter |
Description |
|---|---|
|
name |
Specifies the name of this data center. This parameter must be enclosed in quotation marks. |
|
location |
Specifies the location of the data center. This parameter must be enclosed in quotation marks. This sub-statement is not required, but this information can be useful if problems later arise or changes are required. |
|
contact |
Identifies the administrator of the data center. This parameter must be enclosed in quotation marks. This sub-statement is not required, but this information can be useful if problems later arise or changes are required. |
|
3dns |
Specifies the IP address or name of a 3-DNS Controller in this data center. If you have a redundant system, you need to specify only one controller's IP address. |
|
bigip |
Specifies the IP address or name of a BIG-IP system in this data center. If you have a redundant system, you need to specify only one controller's IP address. |
|
edgefx |
Specifies the IP address or name of an EDGE-FX system in this data center. |
|
router |
Specifies the IP address or name of a router in this data center. |
|
host |
Specifies the IP address or name of a host in this data center. |
The box statement
The box statement defines the name, IP addresses, remote user, big3d factories, and iQuery protocol associated with an actual physical system. The physical system can have one or more servers running on it. For example, if you have a BIG-IP system running the 3-DNS Controller module, you define one physical system (a box), and two server types (the 3-DNS Controller and the BIG-IP system) in the wideip.conf file.
Syntax for the box statement
Figure A.8 shows the syntax for a box statement.
box { [ name <"box name"> ] address <ip_address> [ translates to <ip_address> ] [ address <ip_address> [ translates to <ip_address> ]]... iquery_protocol < udp | tcp > [ remote { [ user <"user_name"> ] [ secure <yes | no> ] } ] [ factories { [ prober <number> ] [ hops <number> ] [ ecv <number> ] [ snmp <number> ] } ] } |
Definitions of box sub-statements
The box statement can contain some or all of the parameters that are described in the following sections.
Address information
The address information sub-statements provide the basic attributes of a box. Note that if you are defining a 3-DNS Controller, a BIG-IP system, an Link Controller, or an EDGE-FX system, you can define the iQuery protocol and factories for the big3d agent, in addition to the name and IP addresses for the box.
|
Parameter |
Description |
|---|---|
|
name |
Specifies the name of the physical unit that the server type runs on. You must enclose all names in quotation marks. This is an optional setting. |
|
address |
Specifies the public IP address of the interface in the physical unit. Note that you can have several addresses for one box. |
|
translates to |
Specifies the private IP address the physical unit. If you have firewalls in your network, the translates_to address is the IP address that is on your internal network. This is an optional parameter for the address parameter, and you can use either syntax format. |
|
iquery_protocol |
Specifies the iQuery transport option, tcp or udp. Applies to 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems only. |
Remote connections
You use the remote sub-statement only if you want to specify a different login name for a 3-DNS Controller, BIG-IP system, or EDGE-FX system.
|
Parameter |
Description |
|---|---|
|
remote |
Indicates the start of a remote sub-statement. Applies to 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems only. |
|
user |
Specifies the "superuser" name that is used to allow a remote user to log on to the system. Enclose this name in quotation marks. If you omit this parameter, the default, root, is used. Applies to 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems only. |
|
secure |
Specifies whether the communications with the remote system are encrypted. The default setting is yes. We recommend that you do not change this setting. |
Factories
For any box that is running a 3-DNS Controller, BIG-IP system, or EDGE-FX system, you can change the number and types of probing factories by using the factories sub-statement. If you omit this sub-statement, the 3-DNS Controller uses the default settings. For more information on factories and probing, see Working with the big3d agent . For information on configuring probing and metrics collection in the wideip.conf file, see Probing and metrics collection .
|
Parameter |
Description |
|---|---|
|
factories |
Indicates the start of the factories definition. Applies to 3-DNS Controller, BIG-IP systems, and EDGE-FX systems. |
|
prober |
Specifies the number of prober factories to use. The default setting is 5. |
|
snmp |
Specifies the number of SNMP factories to use. Note that you must use an SNMP factory to collect metrics from an EDGE-FX Cache. The default setting is 0. |
|
hops |
Specifies the number of hops factories to use. The default setting is 0. |
|
ecv |
Specifies the number of ECV factories to use. The default setting is 5. |
In previous releases, you configured the factories sub-statement within a server statement. With this release, you now define factories within a box statement. Note that is still valid to define factories in a server statement, but we recommend that you define factories in the box statement.
The server statement
The server statement defines the characteristics associated with a particular 3-DNS Controller, BIG-IP system, EDGE-FX system, host, or router. A basic server statement contains the following information:
- The type of server: 3-DNS Controller, BIG-IP system, EDGE-FX system, router, or host
- One of the IP addresses, or the name, of the physical unit that the server is running on
- If the server is a BIG-IP system, EDGE-FX Cache, or host, the set of virtual servers that is available on it
- If the server is a router, the link or links managed by the router
You can also define several parameters that are applicable to the specific server type. As such, the syntax and examples for each server type are listed separately in the following sections of this chapter. All sub-statements for the server statement are defined in the Definition of server sub-statements section.
Syntax for the server statement (3-DNS Controller)
The following server statement syntax applies to 3-DNS Controllers only. Note that this server statement does not define virtual servers; the purpose of defining a 3-DNS Controller is to set up the big3d agent to obtain path probing information.
Figure A.10 shows an example of a 3-DNS Controller definition in the wideip.conf file.
// 3-DNS Controller in New York data center server { type 3dns name "3dns-newyork" box 192.168.101.2 } |
Syntax for the server statement (BIG-IP system)
The following server statement syntax applies only to BIG-IP systems and their virtual servers.
Figure A.12 shows an example definition of a BIG-IP non-redundant system that is behind a firewall, and that has two virtual servers.
server { type bigip box 192.168.101.40 name "bigip-newyork" iquery_protocol udp autoconf enable vs 192.168.101.50:80 translates to 10.0.0.50:80 vs 192.168.101.50:25 translates to 10.0.0.50:25 } |
Syntax for the server statement (EDGE-FX system)
This server statement syntax applies to EDGE-FX systems only.
server { type edgefx [ name <"edgefx_name"> ] box <ip_address | "name"> [ autoconf <disable | enable_with_auto_delete_disabled | enable> ] [ disabled_until [<time in seconds> [<by_whom>]]] [ limit { [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number ] [ cpu_avail <number> ] [ disk_avail <number> ] [ mem_avail <number> ] } ] [ iquery_protocol [ udp | tcp ] ] [ snmp { //required agent edgefx version 2 community <"public"> } ] vs { //applicable only to EDGE-FX Cache address <ip_address>:<port number> [ translates to <ip_address:port> ] [ ratio <number> ] [ depends_on { <ip_address>:<port number> [ <ip_address>:<port number> ] } [ limit { [ cpu_avail <number> ] [ disk_avail <number> ] [ mem_avail <number> ] [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number> ] } ] [ disabled_until [<time in seconds> [<by_whom>]]] } [ vs address <ip_address>:<port number> [ translates to <ip_address:port> ]] } |
An EDGE-FX system can be either an EDGE-FX Cache or a GLOBAL-SITE Controller, however, only an EDGE-FX Cache can manage virtual servers.
Syntax for the server statement (host)
The following server statement syntax applies to hosts only. Note that the snmp sub-statement is necessary only if you want the big3d agent to use an SNMP agent on the host to collect additional metrics information. For more information on configuring these settings, see Working with SNMP on the 3-DNS Controller .
server { type host [ name <"host_name"> ] box <ip_address | "name"> [ probe_protocol <tcp | icmp | dns_rev | dns_dot> ] [ prober <ip_address> ] [ port <port number> | service <"service name"> ] [ autoconf <disable | enable_with_auto_delete_disabled | enable> ] [ snmp { agent <generic | ucd | solstice | ntserv | win2kserv | ciscold | ciscold2 | ciscold3 | foundry | arrowpoint | alteon | cacheflow | netapp> port <port number> community <"community string"> timeout <seconds> retries <number> version <SNMP version> } ] [ limit { [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number> ] [ cpu_avail <number> ] [ disk_avail <number> ] [ mem_avail <number> ] } ] [ disabled_until [<time in seconds> [<by_whom>]]] vs { address <ip_address>:<port number> [ translates to <ip_address>:<port number> ] [ probe_protocol <tcp | icmp | dns_rev | dns_dot> ] [ ratio <number> ] [ limit { [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number> ] [ cpu_avail <number> ] [ disk_avail <number> ] [ mem_avail <number> ] } ] [ depends_on { <ip_address>:<port number> //example 10.10.10.10:443 } ] [ disabled_until [<time in seconds> [<by_whom>]]] } [ vs address <ip_address>:<port number> [ translates to <ip_address>:<port number> ] } |
Figure A.15 shows an example definition of a load balancing host with two virtual servers.
server { type host name "host-tokyo" box 192.168.104.40 probe_protocol icmp snmp { agent ucd community "public" version 1 } vs { address 192.168.104.50:25 limit { kbytes_per_second 15000 } } vs { address 192.168.104.50:80 limit { kbytes_per_second 15000 } } } |
Syntax for the server statement (router)
The following server statement syntax applies to routers only. When you define a router, you also define the router's links.
server { type router [ name "router_name" } box <ip_address | "name"> [ port <port number> ] snmp { agent router version <number> community "public" } link { name "link_name" address <ip_address> [ address <ip_address> ] [ uplink_address <ip_address> ] //use only with SNMP [ isp <"isp_name"> ] [ duplex <yes | no> ] [ cost { ratio <number> [ prepaid <number>Kb ] [ rate { //Up to $/Mb/Sec <number>Kb <number> [ <number>Kb <number> ] } ] } ] [ in { limit { kbytes_per_sec <number> } } ] [ out { limit { kbytes_per_sec <number> } } ] [ total { limit { kbytes_per_sec <number> } } ] } [ link { ... } ] } |
Figure A.17 shows an example definition of a router with one link.
server { type router name "my_router" box "my_router" port 0 duplex yes link { name "Link_1" address 192.168.104.50 isp "My_ISP" cost { ratio 1 prepaid 0Kb } } } |
Definition of server sub-statements
The server statement supports the following sub-statements. Note that available sub-statements vary by server type.
Address information
The address information sub-statements specify the name, address, and type of each server. Depending on the type of server you are configuring, you may need to specify a probe protocol, prober IP address, and port number.
Table A.22 lists the parameters of the address information sub-statement.
|
Parameter |
Description |
|---|---|
|
type |
Indicates whether the specified server is a 3-DNS Controller, BIG-IP system, EDGE-FX system, router, or host. |
|
box |
Specifies the IP address of the 3-DNS Controller, BIG-IP system, EDGE-FX system, router, or host. If you have a redundant system, you specify two box IP addresses, one for each unit. If you are defining a multi-homed system, then you specify only one IP address using this parameter. |
|
name |
Specifies the name of the 3-DNS Controller, BIG-IP system, EDGE-FX system, router, or host. You must enclose all names in quotation marks. |
|
probe_protocol |
Specifies the protocol method to use for probing: icmp, tcp, dns_rev, or dns_dot. Applies to hosts only. |
|
prober |
Specifies the IP address of the system probing the host or router. This IP address points to a BIG-IP system, a 3-DNS Controller, or an EDGE-FX system that runs the big3d agent. If you omit this parameter, the 3-DNS Controller uses the prober <ip_address> parameter defined in the globals statement. The big3d agent probes the host and virtual servers to verify whether the host or a particular virtual server is currently available to accept connections. Note that if you are configuring a prober for a router, the prober system (that is, the BIG-IP system or the 3-DNS Controller) must be in the same data center as the router. |
|
port |
Specifies the port used to probe the host or router if the probe_protocol parameter is set to TCP. This applies to hosts and routers only. |
Auto-discovery for servers
Once you have added the address information for a server, you can enable the auto-discovery option (autoconf), and the 3-DNS Controller automatically gathers virtual server information (for servers). You can also enable the link_autoconf option to automatically gather link and router information for the server's data center. Note that if you have disabled the global variable autoconf, then these parameters in the server statement is inoperative. (See Auto-discovery , for more information.)
|
Parameter |
Description |
|---|---|
|
autoconf |
Specifies whether the 3-DNS Controller initially gathers, and then maintains, the virtual server information for the server. There are three settings for this parameter: disable, enable_with_auto_delete_disabled, and enable. The default setting is disable. |
|
link_autoconf |
Specifies whether the 3-DNS Controller initially gathers, and then maintains, the router and link information for the server's data center. There are three settings for this parameter: disable, enable_with_auto_delete_disabled, and enable. The default setting is disable. Note that if you do not enable the autoconf parameter, the link_autoconf parameter remains disabled regardless of the setting you specify. |
In the Configuration utility, the list of self IPs reported by auto-discovery may not include all self IPs on the system. Auto-discovery reports only public or external addresses, and any associated address translation does not show up in the Configuration utility's self-IP list.
In the Configuration utility, the auto-discovery options are labeled Discovery and Link Discovery.
Limit settings
Using the limit sub-statement, you can manage the physical and throughput resources of your BIG-IP systems, EDGE-FX systems, hosts, and their respective virtual servers. If you omit this sub-statement, the 3-DNS Controller does not use resource thresholds to monitor the availability of the BIG-IP systems, EDGE-FX systems, or hosts, and their respective virtual servers.
|
Parameter |
Description |
|---|---|
|
limits |
Indicates the start of the limits definition. Applies to BIG-IP systems and their virtual servers, EDGE-FX systems and their virtual servers, and hosts and their virtual servers. |
|
cpu_avail |
Specifies, in percentage, how much CPU processing must remain available on the server or virtual server. The cpu_avail parameter applies to hosts and EDGE-FX systems only. |
|
mem_avail |
Specifies, in kilobytes, how much memory must remain available on the server or virtual server. The mem_avail parameter applies to hosts and EDGE-FX systems only. |
|
disk_avail |
Specifies, in kilobytes, how much disk space must remain available on the server or virtual server. The disk_avail parameter applies to hosts and EDGE-FX systems only. |
|
kbytes_per_sec |
Specifies, in kilobytes per second, the maximum allowable throughput rate for the server or virtual server. |
|
pkts_per_sec |
Specifies, in packets per second, the maximum allowable data transfer rate for the server or virtual server |
|
current_conn |
Specifies the maximum number of current connections for the server or virtual server. |
SNMP settings
The snmp sub-statement is valid for hosts, EDGE-FX Caches, and routers only. This sub-statement instructs the big3d agent to use an SNMP agent on the host or the cache to collect additional metrics information.
If you need help configuring the SNMP agent on the EDGE-FX Cache, refer to the EDGE-FX Administrator Guide. If you need help configuring the SNMP agent on a host or router, refer to the documentation provided with that system.
|
Parameter |
Description |
|---|---|
|
snmp |
Specifies the start of an SNMP definition. |
|
agent |
Specifies the SNMP agent type. If you omit this parameter for hosts, the big3d agent uses the generic SNMP agent. |
|
port |
Specifies the port the SNMP agent runs on. |
|
community |
Specifies the password for basic SNMP security and for grouping SNMP hosts. Enclose this string in quotation marks. |
|
timeout |
Specifies the amount of time (in seconds) for the timeout. The default is appropriate in most cases. If you are contacting a host through a very slow network, you can try increasing the timeout and retries values to improve performance. However, the problem with increasing these values is that a host that is down may hold up other SNMP responses for an excessive amount of time. Applies to hosts only. |
|
retries |
Specifies the number of times requests should be retried. The default is appropriate in most cases. If you are contacting a host through a very slow network, you can try increasing the timeout and retries values to improve performance. However, the problem with increasing these values is that a host that is down may hold up other SNMP responses for an excessive amount of time. Applies to hosts and routers only. |
|
version |
Specifies the SNMP agent version. Applies to hosts and routers only. |
Virtual server definitions
Part of defining a BIG-IP system, EDGE-FX system, or host server type is defining the virtual servers that the server manages. You can then use the virtual servers that you define as part of the server statement in a wideip definition for load balancing.
|
Parameter |
Description |
|---|---|
|
vs |
Indicates the start of a virtual server definition. |
|
address |
Specifies the IP address of the virtual server. Note that the virtual server's address must be listed first, before port or service values. |
|
port |
Specifies the virtual server's port number. You can add the port number, preceded by a colon, on the same line as the virtual server's address. You can also use the service name if it is a WKS (well known service) and you enclose it in quotation marks. |
|
limit |
Specifies resource thresholds for the virtual server. Note that if a virtual server reaches a limit, the virtual server is marked as unavailable for load balancing. |
|
depends_on |
Specifies the IP address and port of other virtual servers that must also be available for load balancing (up status) before the 3-DNS Controller uses this virtual server for load balancing. |
|
probe_protocol |
Specifies the protocol to use for probing this virtual server: ICMP or TCP. |
|
translates to |
Specifies that iQuery packets sent to the big3d agent include translated IP addresses (required if the packets must pass through a firewall). When you use this keyword, you must then include address and port/service information for the translated IP addresses. |
Link definitions
When you define a router in the configuration, you also define at least one link for the router. Table A.27 lists the available parameters for a link definition.
|
Parameter |
Definition |
|---|---|
|
link |
Indicates the start of a link definition. |
|
name |
Specifies the name of the link. Names must be enclosed in quotation marks. |
|
address |
Specifies the IP address associated with the link. |
|
isp |
Specifies the name of the Internet service provider (ISP) associated with the link. Note that this is an optional parameter. |
|
duplex |
Specifies whether the ISP uses the duplex billing method for your bandwidth usage. The default setting is yes. |
|
uplink_address |
Specifies the IP address on the router that is associated with the ISP. Note that the uplink IP address is used for SNMP metrics gathering only. |
|
cost |
Indicates the start of the link load balancing parameters. |
|
ratio |
Specifies the volume of link traffic that should use this link in comparison to other configured links. Note that links are load balanced either by using the ratio parameter, or by using the prepaid and incremental parameters. |
|
prepaid |
Specifies, in kilobits (Kb), the amount of bandwidth that is paid for each month, regardless of usage. |
|
rate |
Specifies, in kilobits (Kb), a segment of bandwidth and its associated cost. |
|
in |
Specifies a limit, in kilobits, on the inbound traffic on the link. |
|
out |
Specifies a limit, in kilobits, on the outbound traffic on the link. |
|
total |
Specifies a limit, in kilobits, on the total of inbound and outbound traffic on the link. |
The sync_group statement
The sync_group statement defines the group of 3-DNS Controllers that synchronize their configuration settings and metrics data. You configure this statement in the wideip.conf file of the principal 3-DNS Controller.
Syntax for the sync_group statement
The sync_group statement uses the following syntax.
sync_group { name <"name"> 3dns <ip_address | "name"> [ 3dns <ip_address | "name"> ] } |
Note that the sync_group statement does not support location or contact sub-statements.
Figure A.19 shows an example of a valid sync_group statement.
sync_group { name "sync" 3dns 192.168.101.2 // New York - this is the principal system 3dns 192.168.102.2 // Los Angeles - this is a receiver system 3dns 192.168.103.2 // Madrid - this is also a receiver system } |
Definition of sync_group sub-statements
The sync_group sub-statements define the members of the sync group.
|
Parameter |
Description |
|---|---|
|
name |
Specifies the name of this sync group. |
|
3dns |
Specifies the IP address or name of a 3-DNS Controller in the group. First list the IP address of the principal system. Then list all other 3-DNS Controllers, in the order that they should become a principal system, if the previously listed principal 3-DNS Controller fails. Note that there can only be one principal system in a sync group at any time. |
The wideip statement
The wideip statement defines a wide IP. A wide IP maps a domain name to a load balancing mode and a set of virtual servers.
Syntax for the wideip statement
The wideip statement uses the following syntax.
wideip { address <ip_address> port <port_number> | <"service name"> name <"domain_name"> [ alias <"alias_name"> ... ] [ ttl <number> ] [ persist < yes | no > ] [ persist_ttl <number> ] [ port_list <port_number> <port_number> ... ] [ manual_resume < yes | no > ] [ disabled_until [<time in seconds> [<by_whom>]]] [ qos_coeff { rtt <number> hops <number> completion_rate <number> packet_rate <number> vs_capacity <number> topology <number> kbps <number> lcs <number> } ] [ pool_lbmode <rr | ratio | ga | random | topology> [ ecv { [ protocol <none | ftp | http | https> [ file_name <"string"> ] [ user <"string"> ] [ password <"string"> ] [ hashed_password <"string"> ] [ scan_level <none | all | first> ] [ transfer_amount <number> ] [ connection_timeout <number> ] [ transfer_timeout <number> ] [ search_string <"string"> ] } ] pool { name <"pool_name"> [ disabled_until [<time in seconds> [<by_whom>]]] [ ttl <number> ] [ ratio <number> ] [ last_resort <yes | no> ] [ check_static_depends < yes | no > ] [ check_dynamic_depends < yes | no > ] [ limit { [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number> ] [ cpu_avail <number> ] [ disk_avail <number> ] [ mem_avail <number> ] } ] [ type < A | CNAME > ] [ cname <"canonical name"> ] |
[ dynamic_ratio < yes | no > ] [ rr_ldns < yes | no > ] [ rr_ldns_limit <number> ] preferred < completion_rate | ga | hops | leastconn | packet_rate | qos | random | ratio | return_to_dns | rr | rtt | topology | vs_capacity | null | static_persist | kbps | drop_packet | explicit_ip > [ alternate < ga | null | random | ratio | return_to_dns | rr | topology | packet_rate | leastconn | vs_capacity | static_persist | drop_packet | explicit_ip > ] [ fallback < completion_rate | ga | hops | leastconn | packet_rate | qos | random | ratio | return_to_dns | rr | rtt | topology | vs_capacity | null | static_persist | kbps | drop_packet | explicit_ip > ] [ fallback_ip <ip_address> ] vs { //CNAME pools do not require virtual servers address <ip_address>:<port number> [ ratio <number> ] [ limit { [ kbytes_per_sec <number> ] [ pkts_per_sec <number> ] [ current_conns <number> ] } ] [ depends_on { <ip_address>:<port number> [ <ip_address>:<port number> ] } [ disabled_until [<time in seconds> [<by_whom>]]] } [ vs { address <ip_address>:<port number> } ] } |
Figure A.21 shows an example of a valid wideip statement.
wideip { address 192.168.102.50 service "http" name "http.wip.siterequest.com" alias "store.wip.siterequest.com" alias "*.wip.siterequest.com" alias "http.wip.domain.???" pool_lbmode ratio pool { name "pool_1" ratio 3 limit { kbytes_per_second 10000 } preferred rtt alternate random address 192.168.101.50 address 192.168.102.50 address 192.168.103.50 } pool { name "pool_2" ratio 1 limit { kbytes_per_second 10000 } preferred ratio vs { address 192.168.104.50 ratio 2 } vs { address 192.168.105.50 ratio 1 } } } |
Definition of wideip sub-statements
The wideip sub-statements define pools of virtual servers to be load balanced, and they assign load balancing characteristics, such as the load balancing mode, to each pool. When you have more than one pool configured in a wide IP, the controller first determines the pool that can best respond to a request, and then determines the specific virtual server within the pool that is the best virtual server to send as a response.
Address information
The address information sub-statements specify the IP address, name, and alias of the wide IP. They also specify the pool of virtual servers that the wide IP load balances.
|
Parameter |
Description |
|---|---|
|
address |
Specifies a unique number, in the IP address format, to identify the wide IP. |
|
port or service |
Specifies the default port number or service name for the wide IP. You can use the service name if it is a well known service (WKS) and you enclose it in quotation marks. |
|
name |
Specifies the fully qualified domain name for the wide IP (for example, "www.wip.siterequest.com"). You must enclose all names in quotation marks. Note that you can use two wildcard characters, the asterisk ( * ) and the question mark ( ? ), in wide IP names. The asterisk ( * ) can represent multiple characters, and the question mark ( ? ) can represent a single character. Any of the following examples are valid for the name or alias parameter in a wideip statement: " www.*.com", "*.siterequest.com", "*.domain.???", and so on. |
|
alias |
Specifies an alternate name for the wide IP. The conventions for name also apply to alias. You can specify an unlimited number of alias names for each wide IP. |
Load balancing sub-statements
The load balancing sub-statements denote the general load balancing attributes for all pools in the wideip.conf file.
|
Parameter |
Description |
|---|---|
|
ttl |
Specifies the amount of time (in seconds) that the A record is used by the LDNS after resolving the wide IP. If you specify a pool TTL (pool_ttl), it overrides the TTL that you specify here. If you do not define either the TTL for the wide IP, or the TTL for the pool, then the controller uses the default TTL (default_ttl) that is specified in the globals statement. |
|
persist |
Specifies whether to maintain a persistent connection between an LDNS and a particular virtual server in the wide IP (rather than load-balancing the connection to any available virtual server). Note that the variables drain_requests and default_persist_ttl, in the globals statement, affect this setting. See page A-11 for more information. |
|
persist_ttl |
Specifies the number of seconds to maintain a persistent connection between an LDNS and a particular virtual server in this wide IP; this setting is valid only if you have configured the persist parameter. |
|
port_list |
Specifies a list of ports that must be available before the 3-DNS Controller can send connections to the specified address. |
|
qos_coeff |
Specifies the relative weighting for each load balancing method in calculating the Quality of Service mode. Before you adjust any QOS coefficients, you may want to review Chapter 8, Working with Quality of Service, in the 3-DNS Administrator Guide. |
|
pool_lbmode |
Specifies the load balancing mode to use to balance requests over all pools. |
|
manual_resume |
Specifies whether disabled virtual servers must be brought back into service manually when they are once again available for load balancing, rather than resuming availability automatically. The default setting is no, which indicates that disabled virtual servers resume availability automatically, once the virtual server has successfully responded to service check. |
ECV sub-statements
The ECV sub-statements define the components of an extended content verification (ECV) monitor. Use the ECV sub-statement if you want the 3-DNS Controller to verify the presence of a file, or certain content, on the servers or virtual servers that host the content mapped to the wide IP, before the wide IP is considered up for load balancing.
|
Parameter |
Description |
|---|---|
|
ecv |
Specifies an extended content verification (ECV) monitor for a virtual server in a pool. |
|
protocol |
Specifies the protocol to use for the ECV. You can use only http, https, or ftp. |
|
file_name |
Specifies the name of the object to retrieve. |
|
user |
Specifies the user name that you use to log in to the service. |
|
password |
Specifies the password that corresponds to the user account. |
|
hashed_password |
Specifies the password in encrypted characters. |
|
scan_level |
Specifies whether you want to scan just through the configured wide IP names, or through the wide IP names and aliases. Use only with the ecv sub-statement. Note that if you use wildcard characters in the wide IP name or alias parameters, those names and aliases are ignored by the ECV scans. |
|
transfer_amount |
Specifies the number of bytes to transfer. |
|
transfer_timeout |
Specifies the maximum amount of time the file information transfer should take. |
|
connection_timeout |
Specifies the maximum amount of time to connect to a service. |
|
search_string |
Specifies a regular expression that you want the ECV monitor to locate within the scanned file. |
Pool sub-statements
The pool sub-statements define the virtual servers, and the load balancing modes within the pool, that the 3-DNS Controller uses to respond to DNS requests. Note that you can have one or more pools in a wide IP definition.
|
Parameter |
Description |
|---|---|
|
pool |
Indicates the start of the pool definition for this wide IP. A pool is a set of virtual servers defined and owned by a BIG-IP system, an EDGE-FX system, or a host. |
|
name |
As part of a pool definition, defines the name of the pool. All names must be enclosed in quotation marks, and must be unique within the wideip statement. |
|
ttl |
Specifies the amount of time (in seconds) that the A record is used by the LDNS after resolving the wide IP. This is the TTL associated with the A record as specified by RFC 1035. |
|
ratio |
As part of a pool definition, ratio specifies the default weighting to use, with respect to other pool types, when the pool_lbmode is ratio. |
|
last_resort |
Specifies whether the 3-DNS Controller directs LDNS requests to this pool when no other pools in the wide IP successfully respond to the request. The default setting is no. |
|
check_static_depends |
Specifies whether the 3-DNS Controller checks availability before returning a virtual server in the pool. (Note that this parameter does not affect the status of the virtual server on the Virtual Server Statistics screen, in the Configuration utility, while the global variable of the same name does affect the status.) |
|
check_dynamic_depends |
Specifies whether the 3-DNS Controller checks paths before returning a virtual server in the pool. |
|
type |
Specifies the type of pool. The default is A. You can also use CNAME to redirect LDNS requests to another DNS server. |
|
cname |
Specifies the canonical name (cname) for the pool. Use this attribute with the pool type CNAME to redirect LDNS requests to a name server in another network, or to a CDN provider. Enclose the cname in quotation marks. |
|
dynamic_ratio |
Specifies whether the 3-DNS Controller treats QOS scores as ratios, and uses each server in proportion to the ratio determined by the QOS calculation. The default is no. |
|
rr_ldns |
Specifies whether the 3-DNS Controller returns a list of available virtual servers available for load balancing to a client and stores the list in the browser cache. The default is no, which specifies that the 3-DNS Controller returns only one A record per query. |
|
rr_ldns_limit |
The maximum number of A records to return when rr_ldns is set to yes. You can enter a value between 0 and 16. The default is 0, which specifies that the 3-DNS Controller returns the IP addresses of all (up to 16) available virtual servers. |
|
preferred |
Specifies the load balancing mode to use for the specified pool. Each acceptable value is described in the next table. The default is rr (Round Robin). |
|
alternate |
Specifies the load balancing mode to use for the specified pool if the preferred mode fails. The default is rr (Round Robin). Also see the description of default_alternate in Table A.14 . |
|
fallback |
Specifies the load balancing mode to use for the specified pool if the alternate mode fails. If the fallback mode fails, the 3-DNS Controller returns the request to DNS. The default is return_to_dns. Also see the description of default_fallback in Table A.14 |
|
fallback_ip |
If you specify the explicit_ip load balancing mode for the alternate or fallback method, you must also specify the IP address that the controller sends back as the answer to a query. You can use this option to direct traffic to a disaster recovery site. |
|
vs |
Specifies the start of a pool virtual server definition. The vs sub-statement within the pool sub-statement must refer to a virtual server that you defined within a server statement. You can use the same virtual server in multiple pools, but not within the same pool. |
|
address |
Specifies specifies the IP address and port of the virtual server. The default port is the port of the wide IP, if you do not define a port as part of the address parameter. |
|
ratio |
Specifies the default weighting to use with respect to all virtual servers in this pool when the Ratio load balancing mode is configured. The default is 1. |
|
limit |
Specifies resource thresholds for the virtual server. Note that if a virtual server reaches a limit, the virtual server is marked as unavailable for load balancing. See Limit settings , for an explanation of the limits you can set. |
|
depends_on |
Specifies the IP address and port of other virtual servers that must also be available for load balancing (within this pool) before the 3-DNS Controller uses this virtual server for load balancing. |
Load balancing modes
The load balancing sub-statements specify the load balancing modes to use for the wide IP in this order:
- The 3-DNS Controller attempts to load balance requests using the preferred mode.
- If the preferred mode fails, the 3-DNS Controller tries the alternate mode.
- If the alternate mode fails, the 3-DNS Controller tries the fallback mode.
- If the fallback mode fails, the controller tries the next pool. If there are no more pools available, the controller returns the request to DNS.
DNS attempts to resolve the request based on the contents of the zone files.
As noted in Table A.33 , not all modes are valid for the alternate sub-statement. Also note that the alternate and fallback sub-statements accept two additional values, return_to_dns and null.
If you do not specify a load balancing mode within a pool, the wide IP uses the default load balancing mode defined in the globals statement. For information on the globals statement, see page A-6 .
|
Parameter |
Description |
|---|---|
|
completion_rate |
Sends each new connection to the server that has the fewest number of dropped packets. Valid in a preferred or fallback sub-statement. |
|
drop_packet |
The controller drops the request if it cannot find a virtual server to send as a response. We recommend that you use this load balancing mode only in the fallback statement. |
|
explicit_ip |
Forwards the request to the IP address that you specify in the fallback_ip parameter, for example, the IP address for a disaster recovery site. We recommend that you use this load balancing mode only in the fallback statement. |
|
global_availability (ga) |
Distributes requests to a list of servers, always sending a new request to the first available server in the list. |
|
hops |
Sends each new request to the server that has the fewest number of network hops between the server and the client LDNS. Valid in a preferred or fallback sub-statement. |
|
leastconn |
Sends each new request to the server that currently hosts the fewest current connections. |
|
null |
Bypasses the current load balancing method and forces the 3-DNS Controller to use the next load balancing method or, if it has cycled through all load balancing sub-statements for the pool, to the next pool. Valid in an alternate or fallback sub-statement. |
|
packet_rate |
Sends each new request to the server that is managed by a BIG-IP system currently handling the least amount of network traffic (determined by the fewest number of packets currently processed by the system). |
|
qos |
Takes these performance factors into account when determining how to distribute request: hops, packet rate, completion rate, round trip time, kbps, link capacity, virtual server capacity, and topology. You can configure how much emphasis to place on each performance factor, or you can configure the Quality of Service mode to treat all factors as being equally important. Valid in a preferred or fallback sub-statement. |
|
random |
Distributes each new request to a server chosen at random from the pool's virtual servers. |
|
ratio |
Distributes new requests across servers in proportion to a user-defined ratio. |
|
return_to_dns |
Returns the resolution request to DNS, preventing the 3-DNS Controller from using the next load balancing method or using the next available pool. |
|
rr |
Distributes request evenly across all servers, passing each new connection to the next virtual server in line. |
|
rtt |
Sends each new request to the server that demonstrates the fastest round trip time between the server and the client LDNS. Valid in a preferred or fallback sub-statement. |
|
topology |
Distributes requests based on the proximity of an LDNS to a particular data center. You must also configure a topology statement before this load balancing mode works. |
|
static_persist |
Distributes requests to a virtual server based on IP address only. The 3-DNS Controller always returns the same virtual server to the same client, if the virtual server is available. |
|
vs_capacity |
Distributes requests based on the overall available capacity of the virtual server. Over time all virtual servers in the pool receive requests, but the virtual server with the most capacity receives the highest percentage of requests. |
|
kbps |
Distributes requests to the virtual server with the lowest kilobytes per second throughput rate. |
Use the following equation to configure the Quality of Service load balancing mode:
A (1/packet rate) + B (1/rtt) + C (completion rate) +
D (topology) + E (1/hops) + F (1/kbps) + G (vs_capacity) +
H (link capacity score)
For more information about load balancing modes, see Chapter 2, Load Balancing .
The topology statement
The topology statement implements a form of wide-area IP filtering, based on the geographic attributes of the DNS message. For example, you can specify that requesting LDNS clients in North America are allowed access to data centers in North America, but are not allowed access to data centers in South America.
By including a topology statement in your wideip.conf file, you can use the topology load balancing mode, both on its own and as part of the Quality of Service mode.
For more information on using the Topology load balancing mode, see Chapter 7, Configuring a Globally Distributed Network , and in the 3-DNS Administrator Guide, Chapter 8, Configuring a Content Delivery Network . For more information on topology in general, see Chapter 3, Topology , in this guide.
Syntax for the topology statement
Figure A.22 contains examples of the syntax used in the topology statement. Note that the object names are in quotation marks.
topology { [ longest_match <yes | no> ] // server ldns score [ pool.<"pool_name"> cont.<"continent_name"> <number> ] [ datacenter.<"dc_name"> !country.<"2-letter_code"> <number> ] [ pool.<"pool_name"> user.<"region_name"> <number> ] [ pool.<"pool_name"> isp."AOL" <number> ] [ <vs_ip_address>/<netmask> <ldns_ip_address> <number> ] } |
In a topology statement, use the not operator (!) to negate the meaning of an element, as shown in the example in Figure A.22 .
Definition of topology sub-statements
The topology sub-statements define the topology records that the 3-DNS Controller uses for Topology load balancing.
|
Parameter |
Description |
|---|---|
|
longest_match |
In cases where there are topology records that match a particular IP address, longest_match specifies whether the 3-DNS Controller selects the record that is most specific, and thus has the longest match. When longest_match is set to yes, the topology records are sorted according to the longest match criteria. |
|
<vs_ip_address>/<netmask> |
Specifies a virtual server or group of virtual server, in CIDR format. |
|
<ldns_ip_address> |
Specifies a local DNS server. |
|
pool.<"pool_name"> |
Specifies a wide-IP pool for load balancing. Note that pool names can be duplicated across wide IPs. The name must be in quotation marks. Use this for server in a topology record. |
|
datacenter.<"datacenter_name"> |
Specifies a data center for load balancing. The name must be in quotation marks. Use this for server in a topology record. |
|
continent.<"continent_name"> |
Specifies one of the continents for load balancing: "North America", "South America", "Europe", "Asia", "Australia", "Africa", or "Antarctica". The name must be in quotation marks. Use this for ldns in a topology record. |
|
country.<"2-letter_code"> |
Specifies a country for load balancing using one of the two-letter country codes found in the file /var/3dns/include/net.ccdb. The name must be in quotation marks. Use this for ldns in a topology record. |
|
isp."AOL" |
For local DNS servers only, specifies the Internet service provider, America Online (AOL). The name must be in quotation marks. |
|
user.<"region_name"> |
Specifies a user-defined region. The name must be in quotation marks. |
|
! |
The not ( ! ) operator negates the meaning of an element in a topology record. |
|
score |
Specifies the relative weight, or score, for the topology record, which allows the 3-DNS Controller to evaluate the best resolution option for a DNS request. |
Access control lists
You can create access control lists (ACLs) that contain a group of LDNS IP addresses whose paths the 3-DNS Controller will not probe. The two types of ACLs are:
- Prober
- Hops
Syntax for the access control lists
The access control lists use the following syntax.
region_db ACL { region { name "probe_acl" <ldns cidr> <ldns cidr> } region { name "hops_acl" region "probe_acl" <ldns cidr> <ldns cidr> } } |
Definition of the access control list sub-statements
The access control list sub-statements define local DNS servers that should not be probed.
|
Parameter |
Description |
|---|---|
|
region_db ACL |
Specifies that ACLs are being created. |
|
region |
Specifies groups of CIDRs by probe type. |
|
name |
Specifies the name of the ACL. |
|
probe_acl |
The 3-DNS Controller restricts any big3d agent from probing the defined group of local DNS servers. |
|
hops_acl |
The 3-DNS Controller restricts any big3d agent from tracerouting the defined group of local DNS servers |
For more information on ACLs, refer to Working with access control lists, .
Working with comments
You can insert comments anywhere you would otherwise see white space in the 3-DNS configuration file.
Syntax
Note that the comment syntax depends on the environment in which you use the configuration file.
/* This is a 3-DNS comment as in C */ // This is a 3-DNS comment as in C++ # This is a 3-DNS comment as in common UNIX shells and Perl |
Definition and usage
The format for comments varies by programming language; each format is described below. To avoid comment nesting problems, we recommend that you use only one comment style in your wideip.conf file. However, all styles may be used in a single wideip.conf file.
C style comments
C style comments start with the slash character, followed by the asterisk character (/*), and end with the asterisk character, followed with the slash character (*/). Because the comment is completely delimited with these characters, a comment can span multiple lines.
Note that C style comments cannot be nested. For example, the following syntax is not valid because the entire comment ends with the first */.
/* This is the start of a comment. This is still part of the comment. /* This is an incorrect attempt to nest a comment. */ This is no longer in any comment. */ |
C++ style comments
C++ style comments start with two slash characters (//) and are no longer than one line in length. To have one logical comment span multiple lines, each line must start with the // pair.
// This is the start of a comment. The next line // is a new comment line, even though it is // logically part of the previous comment. |
Shell style comments
Shell style (also known as Perl style) comments start with the number character ( # ) and are no longer than one line in length.
# This is the start of a comment. The next line # is a new comment line, even though it is logically # part of the previous comment. |
