Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 4.1.1, 4.1.0
13
wideip.conf Configuration
- Overview of the wideip.conf file
- Working with statements
- Working with comments
- Understanding current values
Overview of the wideip.conf file
The 3-DNS Controller configuration file is called /etc/wideip.conf. The wideip.conf file describes a network's data centers, servers (3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, GLOBAL-SITE Controllers, and hosts), and wide IPs. The wideip.conf file consists of two types of information: statements and comments.
Your wideip.conf file must include at least the following definitions.
- A datacenter statement
- At least one server statement defining a 3-DNS Controller
- At least one virtual server, which is defined as part of a BIG-IP Controller, EDGE-FX Cache, or host server statement
- A wideip statement, for load balancing
If a 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, 3-DNS Controllers revert to standard DNS behavior.
To open the wideip.conf file
- At the command line, type 3dnsmaint.
The 3-DNS Maintenance menu opens. - On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration.
Warning: We do not recommend opening the wideip.conf file in a text editor. Instead, use the Edit 3-DNS Configuration command on the 3-DNS Maintenance menu. This command allows you to edit and save the configuration file. This command also parses the configuration file and alerts you to any syntax errors.
Using include files
Include files are files that contain configuration information about one aspect of your network, and are listed in the main configuration file (wideip.conf). For example, you can have one include file that defines the BIG-IP Controllers in your network, and another include file that defines all wide IPs. Both files are listed in the wideip.conf file in place of the actual server and wideip statements.
Using include files reduces the size of the wideip.conf file and makes it easier to manage your configuration. Include files are automatically created and implemented whenever one of the following occurs:
- You configure your network setup using the Configuration utility.
- You perform any type of dumping operation. By default, dumping operations are on. To turn dumping off, set the global sub-statement timer_persist_cache to 0.
Note: When include files are generated, any comments you incorporated are deleted.
Syntax for include files
The following syntax is used when incorporating include files into a wideip.conf file.
Figure 13.1 Syntax for include files
include root_in "/config/3dns/include"
include root_out "/config/3dns/include"
include global <"file_name.inc">
include server <"file_name.inc">
include bigip <"file_name.inc">
include host <"file_name.inc">
include 3dns <"file_name.inc">
include datacenter <"file_name.inc">
include sync_group <"file_name.inc">
include wideip <"file_name.inc">
include 3dscript <"file_name.inc">
include topology <"file_name.inc">
include geoloc <"netIana.inc">
include cdn <"cdn.inc">
include ldns <"ldns.inc">
include region <"file_name.inc">
include manifest <"file_name.inc">
Definitions of include statements
Table 13.1 lists the include statements, their descriptions, and their default file names.
Working with statements
A top-level 3-DNS Controller statement begins with a keyword, and may be followed either by a value or by a block of sub-statements enclosed in brackets ( {}).
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 defaults for other statements. - server
The server statement defines a 3-DNS Controller, a BIG-IP Controller, an EDGE-FX Cache, a GLOBAL-SITE Controller, or a host machine. - datacenter
The datacenter statement defines the group of 3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, GLOBAL-SITE Controllers, and hosts that reside in a single physical location. - sync_group
The sync_group statement defines the group of 3-DNS Controllers that synchronize their configuration settings and metrics data. - wideip
The wideip statement defines a wide IP. Wide IPs map a domain name to a load balancing mode and a set of virtual servers (on BIG-IP Controllers, EDGE-FX Caches, and other host machines). - 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 while 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
- most include statements (except the include ldns statement)
- server
- datacenter
- sync_group
- wideip
- include ldns
- Port specification
When you define 3-DNS Controllers or hosts, the port specification must follow the probe_protocol sub-statement. When you define a BIG-IP Controller, EDGE-FX Cache, or virtual server (on a BIG-IP Controller, an EDGE-FX Cache, or a host), the port specification must immediately follow the address specification, and can take any of the following forms:
address <ip_addr>:<port>
address <ip_addr>
port <port>address <ip_addr>
service <"wks">In the above example, <"wks"> stands for well-known service and is a quoted string representing the name of a WKS defined in the /etc/services file. For example, you can use "http" instead of 80 to represent the HTTP protocol.
- cur_values
You may notice several cur_values in the wideip.conf file; do not edit them unless you are instructed to do so by your vendor's technical support. For more information, see Understanding current values, on page 13-47 .
Typography in syntax examples
Certain characters are used to indicate whether a parameter is mandatory or optional, or whether you can use one parameter or another.
- Mandatory parameters
Angle brackets ( < > ) enclose mandatory parameters where you must type the data associated with a command. - Optional parameters
Brackets ( [ ] ) enclose optional parameters. - Brackets
Brackets ( { } ) include the options available in a statement or sub-statement. - Choice of parameters
A vertical bar ( | ) between two values means that either value is acceptable.
The globals statement
The globals statement sets up global options to be 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 the 3-DNS Controller does not find a globals statement in the configuration file, the 3-DNS Controller uses a globals block, with each option set to its default.
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 lines shown in the following figure, the 3-DNS Controller uses the value 50.
Figure 13.2 Multiple globals sub-statements
globals {
bigip_ttl 100
bigip_ttl 50
}
Syntax for the globals statement
The globals statement supports the following sub-statements. When you define a globals statement, you need only include those sub-statements that you want to change from the default.
Figure 13.3 Syntax for the globals statement
globals {
[ time_tolerance <number> ]
[ 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> ]
[ bleed_requests < yes | no >
[ persist_nonwipnames < 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_check_keep_alive <number> ]
[ timer_persist_cache <number> ]
[ timer_sync_state <number> ]
[ dc_prefix <string> ]
[ dns_ttl <number> ]
[ 3dns_ttl <number> ]
[ bigip_ttl <number> ]
[ edgefx_ttl <number> ]
[ host_ttl <number> ]
[ vs_ttl <number> ]
[ path_ttl <number> ]
[ trace_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_region < yes | no > ]
[ dump_topology < yes | no > ]
[ filter_ip < cidr block | ip address >
[ filter_mask <ip address> ]
[ 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 ]
[ qos_coeff_kbps <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>
[ default_alternate < ga | null | random | ratio | static_persist |
packet_rate | leastconn | return_to_dns | rr | topology | vs_capacity
| kbps > ]
[ default_fallback < completion_rate | ga | hops | leastconn |
null | packet_rate | qos | random | ratio | return_to_dns |
rr | rtt | topology | vs_capacity | static_persist | kbps > ]
[ fb_respect_depends < yes | no > ]
[ fb_respect_acl < yes | no > ]
[ aol_aware < yes | no >
[ path_duration <number> ]
[ ldns_duration <number> ]
[ prober <ip_addr> ]
[ 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 > ]
[ paths_noclobber < yes | no > ]
[ rtt_probe_dynamic < yes | no > ]
[ rtt_port_discovery < yes | no > ]
[ rtt_autorecover_discovery < yes | no > ]
[ rtt_discovery_method < short | wks | full > ]
[ discovery_portlist {
method < short | wks | all >
[ portlist { <number> <number> ... } ]
[ randomize < yes | no > ]
} ]
[ rtt_allow_probe < yes | no > ]
[ rtt_allow_hops < yes | no > ]
[ rtt_allow_frag < yes | no > ]
[ rtt_probe_protocol < dns_rev | dns_dot | udp | tcp | icmp >
[ datasize_system <number> ]
[ datasize_reap_pct <number> ]
[ default_iquery_protocol < udp | tcp > ]
[ traceroute_port <number> ]
[ do_dynamic < yes | no > ]
}
Figure 13.4 shows an example of a valid globals statement.
Figure 13.4 Example syntax for the globals statement
globals {
prober 192.168.101.2 // Default prober is New York 3-DNS Controller
encryption yes // Encrypt iQuery
paths_noclobber yes // Don't overwrite metrics with zeroed results
path_ttl 2400 // Extend the life of path metrics
rtt_probe_dynamic yes // Switch probing method if current fails
}
Definition of globals sub-statements
The globals sub-statements and their parameters are described in the following sections.
Synchronization
The synchronization sub-statement specifies how the current 3-DNS Controller handles synchronizing its database with the other 3-DNS Controllers in the network.
Encryption
The encryption sub-statements specify whether the communication between the 3-DNS Controller and a BIG-IP Controller is encrypted.
Dependencies
The dependencies sub-statements specifies whether the 3-DNS Controller checks the availability of virtual servers or paths before the controller sends a connection to a virtual server.
LDNS persistence
Dynamic load balancing modes 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, you can set persist_ldns to no to conserve memory.
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. |
0xFFFFFFFF |
|
bleed_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 page 13-38 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.
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.
Metrics collection
The metrics collection sub-statements define how the 3-DNS Controller collects path information.
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.
QOS values
The Quality of Service load balancing mode distributes connections based on a path evaluation score. Using the equation below, the Quality of Service mode compares paths between the LDNS and each virtual server included in the wideip statement. 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)]
The coefficients for the score computation are defined as globals, but you can override them within a wideip statement.
Load balancing
The load balancing sub-statement defines the alternate and fallback load balancing modes.
Prober
The prober sub-statement defines the IP address of the machine that pings a host system to verify whether it is available. Typically, you use the IP address of the 3-DNS Controller itself, but you can use other network servers.
Warning: You must define a prober if the 3-DNS Controller manages virtual servers on hosts. If you do not define a default prober in the globals statement, or probers in the host statements for all hosts, you will encounter validation errors.
Buffer size
The buffer size sub-statements specify the maximum amount of UDP data that the 3-DNS Controller can receive, and also specify the maximum amount of TCP data that the 3-DNS Controller can send.
Reaping
The 3-DNS Controller stores dynamic LDNS 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.
iQuery port options
Probing
The 3-DNS Controller uses probing to collect path metrics. The 3-DNS Controller then uses the metrics to make traffic distribution and load balancing decisions.
The server statement
The server statement defines the characteristics associated with a particular 3-DNS Controller, BIG-IP Controller, EDGE-FX Cache, GLOBAL-SITE Controller, or host.
Note: The server statement replaces the bigip and host statements used in earlier versions of 3-DNS Controller. Although this version of 3-DNS Controller provides backward compatibility with the earlier bigip and host statements, we recommend that you use the newer syntax.
A server statement contains the following information:
- The type of server: 3-DNS Controller, BIG-IP Controller, EDGE-FX Cache, GLOBAL-SITE Controller, or host
- The IP address and host name of the server
- If the server is a BIG-IP Controller, EDGE-FX Cache, or host, the set of virtual servers that is available on it
- Dynamically collected information about the server, its virtual servers and ports, and the paths between the server and LDNS
Because available sub-statements vary by server type, the syntax and examples for each type are listed separately. All sub-statements are defined in the table starting on page 13-27 .
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 13.6 Server statement syntax for defining a 3-DNS Controller
server {
type 3dns
address <IP address>
name <"3dns_name">
iquery_protocol [ udp | tcp ]
[ remote {
secure <yes | no>
user <"user name">
} ]
[ interface {
address <NIC IP address>
address <NIC IP address>
} ]
[ factories {
prober <number>
discovery <number>
snmp <number>
hops <number>
} ]
[ prober <IP address> ]
probe_protocol < icmp | udp | tcp | dns_rev | dns_dot >
port <port to probe>
[ discovery_portlist {
method < short | wks | all >
[portlist { <number> <number> ... }
[randomize < yes | no >
} ]
}
Figure 13.7 shows an example of the syntax to use in defining a 3-DNS Controller.
Figure 13.7 Example syntax for defining a 3-DNS Controller
// New York
server {
type 3dns
address 192.168.101.2
name "3dns-newyork"
iquery_protocol udp
remote {
secure no
user "root"
}
probe_protocol icmp
port 53
}
Syntax for the server statement (BIG-IP Controller)
The following server statement syntax applies to BIG-IP Controllers and their virtual servers only.
Figure 13.8 Server statement syntax for defining a BIG-IP Controller
server {
type bigip
address <IP address>
name <"bigip_name">
iquery_protocol [ udp | tcp ]
[ vsmetrics < yes | no > ]
[ remote {
secure <yes | no>
user <"user name">
} ]
[ interface {
address <NIC IP address>
address <NIC IP address>
} ]
[ limit {
[ kbytes_per_sec <number> ]
[ pkts_per_sec <number> ]
[ current_conns <number ]
} ]
[ probe_protocol < icmp | ucp | tcp | dns_dot | dns_rev > ]
[ ratio <number> ]
[ factories {
prober <number>
discovery <number>
snmp <number>
hops <number>
} ]
vs {
address <virtual server IP address>
port <port number> | service <"service name">
[ limit {
[ kbytes_per_sec <number> ]
[ pkts_per_sec <number> ]
[ current_conns <number> ]
} ]
[ depends_on {
<IP address>:<port number> //example 10.10.10.10:443
} ]
[ translate {
<IP address>:<port number>
} ]
probe_protocol <tcp | udp>
}
Figure 13.9 shows an example of the syntax to use in defining a BIG-IP Controller.
Figure 13.9 Example syntax for defining a BIG-IP Controller
server {
type bigip
address 192.168.101.40
name "bigip-newyork"
iquery_protocol udp
remote {
secure yes
user "administrator"
}
# Tell 3-DNS about the 2 interfaces on a BIG-IP HA Controller
interface {
address 192.168.101.41
address 192.168.101.42
}
# Change the number of factories doing the work at big3d
factories {
prober 6
discovery 1
snmp 1
hops 2
}
vs {
address 192.168.101.50
service "http"
translate {
address 10.0.0.50
port 80
}
}
vs {
address 192.168.101.50:25 // smtp
translate {
address 10.0.0.50:25
}
}
}
Syntax for the server statement (EDGE-FX Cache)
This server statement syntax applies to EDGE-FX Caches only.
Figure 13.10 Example syntax for defining an EDGE-FX Cache
server {
type edgefx
address <IP address>
name <"edgefx_name">
[ 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 ]
[ remote {
secure <yes | no>
user <"user name">
} ]
[ ratio <number> ]
[ factories {
prober <number>
discovery <number>
hops <number>
snmp <1> { //required
agent edgefx
version 2
community <"public">
}
} ]
vs {
address <virtual server IP address>
port <port number> | service <"service name">
[ limit {
[ cpu_avail <number> ]
[ disk_avail <number> ]
[ mem_avail <number> ]
[ kbytes_per_sec <number> ]
[ pkts_per_sec <number> ]
[ current_conns <number> ]
} ]
}
}
Syntax for the server statement (GLOBAL-SITE Controller)
The following server statement syntax applies to GLOBAL-SITE Controllers only.
Figure 13.11 Example syntax for defining a GLOBAL-SITE Controller
server {
type gsite
address <IP address>
name <"gsite_name">
iquery_protocol [ udp | tcp ]
[ remote {
secure <yes | no>
user <"user name">
} ]
[ probe_protocol < icmp | ucp | tcp | dns_dot | dns_rev > ]
[ factories {
prober <number>
discovery <number>
hops <number>
snmp <number>
} ]
}
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 Chapter 10, SNMP .
Figure 13.12 Server statement syntax for defining a host
server {
type host
address <IP address>
name <"host_name">
probe_protocol <tcp | icmp | dns_rev | dns_dot>
[ prober <IP address> ]
port <port number> | service <"service name">
[ snmp {
agent <generic | ucd | solstice | ntserv | win2kserv | ciscold | ciscold2
| ciscold3 | foundry
| arrowpoint | alteon | cacheflow>
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> ]
} ]
vs {
address <virtual server IP address>
port <port number> | service <"service name">
[ probe_protocol <tcp | icmp | dns_rev | dns_dot> ]
}
[ limit {
[ kbytes_per_sec <number> ]
[ pkts_per_sec <number> ]
[ current_conns <number> ]
[ cpu_avail <number> ]
[ disk_avail <number> ]
[ mem_avail <number> ]
} ]
}
Figure 13.13 shows an example of the syntax to use in defining a host.
Figure 13.13 Example syntax for defining a host
server {
type host
address 192.168.104.40
name "host-tokyo"
probe_protocol icmp
port 53
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
}
}
}
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 13.18 lists the parameters of the address information sub-statement.
Limit settings
Using the limit sub-statement, you can manage the physical and throughput resources of your BIG-IP Controllers, EDGE-FX Caches, 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 Controllers, EDGE-FX Caches, hosts, and their respective virtual servers.
Remote connections
It is necessary to use the remote sub-statement only if you want to specify a different login name or specifically use SSH or RSH on 3-DNS Controllers, BIG-IP Controllers, or EDGE-FX Caches.
Hardware redundancy
If you have hardware-redundant 3-DNS Controllers and BIG-IP Controllers, you must configure the interface sub-statement for the 3-DNS Controller to work properly with BIG-IP Controllers in Active-Active mode. This sub-statement is also required in using the standby BIG-IP Controller or 3-DNS Controller for probing.
Factories
With 3-DNS Controllers, BIG-IP Controllers, GLOBAL-SITE Controllers, and EDGE-FX Caches, you can change the number and types of probing factories by using the factories sub-statement. If you omit this sub-statement, the defaults are used. For more information on probing, see Chapter 3, The big3d Agent .
SNMP settings
The snmp sub-statement is valid for hosts and EDGE-FX Caches only. This sub-statement instructs the big3d agent to use an SNMP agent on the host or 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 the host, refer to the documentation provided with the host.
Virtual server definitions
Part of defining a BIG-IP Controller, EDGE-FX Cache, or host is defining the virtual servers that the server manages. After you define a virtual server here (including specifying the address and port), you can use this virtual server in a wideip definition.
The datacenter statement
A datacenter statement defines the group of 3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, GLOBAL-SITE Controllers, and hosts that reside in a single physical location.
Syntax for the datacenter statement
The datacenter statement uses the following syntax.
Figure 13.14 Syntax for the datacenter statement
datacenter {
name <"data center name">
[ location <"location info"> ]
[ contact <"contact info"> ]
[ 3dns <IP address | name> ]
[ bigip <IP address | name> ]
[ host <IP address | name> ]
[ edgefx <IP address | name> ]
[ gsite <IP address | name> ]
}
Figure 13.15 shows an example of a valid datacenter statement.
Figure 13.15 Example syntax for the 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
host 192.168.105.40
gsite 192.168.101.70
}
Definition of datacenter sub-statements
The datacenter sub-statements specify a name for the data center and the machines it contains.
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.
Figure 13.16 Syntax for the sync_group statement
sync_group {
name <"name">
3dns <ip_address | "domain_name">
[ 3dns <ip_address | "domain_name"> ]
}
Note that the sync_group statement does not support location or contact sub-statements.
Figure 13.17 shows an example of a valid sync_group statement.
Figure 13.17 Example syntax for the sync_group statement
sync_group {
name "sync"
3dns 192.168.101.2 // New York - this is the principal controller
3dns 192.168.102.2 // Los Angeles - this is a receiver controller
3dns 192.168.103.2 // Madrid - this is also a receiver controller
}
Definition of sync_group sub-statements
The sync_group sub-statements define the members of the sync group.
The wide IP 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 (on BIG-IP Controllers, EDGE-FX Caches, and/or other host machines).
Syntax for the wideip statement
The wideip statement uses the following syntax.
Figure 13.18 Syntax for the wideip statement
wideip {
address <ip_address>
port <port_number> | <"service name">
[ ttl <number> ]
[ persist < yes | no > ]
[ persist_ttl <number> ]
name <"domain_name">
[ alias <"alias_name"> ]
[ port_list <port_number> <port_number> ... ]
[ qos_coeff {
rtt <number>
hops <number>
completion_rate <number>
packet_rate <number>
vs_capacity <number>
topology <number>
kbps <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>
} ]
pool {
name <"pool_name">
[ 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 | NS | CDN>
[ CDN <string> ]
[ CNAME <canonical name> ]
[ ZNAME <zone name> ]
[ ratio <pool_ratio> ]
[ 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>]
[ alternate < ga | null | random | ratio | return_to_dns | rr | topology
| packet_rate| leastconn | vs_capacity | static_persist> ]
[ fallback < completion_rate | ga | hops | leastconn | packet_rate | qos
| random | ratio | return_to_dns | rr | rtt | topology | vs_capacity
| null | static_persist | kbps> ]
address <vs IP address:port> [ratio <weight>]
}
}
Figure 13.19 shows an example of a valid wideip statement.
Figure 13.19 Example syntax for the wideip statement
wideip {
address 192.168.102.50
service "http"
name "http.wip.domain.com"
alias "store.wip.domain.com"
"*.wip.domain.com
"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
address 192.168.104.50 ratio 2
address 192.168.105.50 ratio 1
}
}
Definition of wideip sub-statements
The wideip sub-statements define groups of virtual servers to be load balanced, and they assign load balancing characteristics, such as the load balancing mode, to each group.
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.
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. This is the TTL associated with the A record as specified by RFC 1035. |
|
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 bleed_requests and default_persist_ttl, in the globals statement, affect this setting. See page 13-10 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 7, Additional Load Balancing Options, in the 3-DNS Administrator Guide. |
|
pool_lbmode |
Specifies the load balancing mode to use to balance requests over all pools. |
|
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. Use only with the ecv sub-statement. |
|
file_name |
Specifies the name of the object to retrieve. Use only with the ecv sub-statement. |
|
user |
Specifies the user name that you use to log in to the service. Use only with the ecv sub-statement. |
|
password |
Specifies the password that corresponds to the user account. Use only with the ecv sub-statement. |
|
hashed_password |
Specifies the password in encrypted characters. Use only with the ecv sub-statement. |
|
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. Use only with the ecv sub-statement. |
|
transfer_timeout |
Specifies the maximum amount of time the file information transfer should take. Use only with the ecv sub-statement. |
|
connection_timeout |
Specifies the maximum amount of time to connect to a service. Use only with the ecv sub-statement. |
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 Controller, EDGE-FX Cache, or host machine. |
|
name |
As part of a pool definition, defines the name of the pool. All names must be enclosed in quotation marks. |
|
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. However, you can specify NS if you want to redirect LDNS requests to other name servers. You can also use CDN to redirect LDNS requests to a CDN provider in the cdn.inc file. |
|
cdn |
Specifies the name of the CDN provider to redirect LDNS requests to, as listed in the cdn.inc file. Use this attribute only if you specify the pool type as CDN. |
|
cname |
Specifies the canonical name (cname) for the pool. Use this attribute with the pool type NS or CDN to redirect LDNS requests to a name server in another network, or to a CDN provider in the cdn.inc file. Enclose the cname in quotation marks. |
|
zname |
Specifies the zone name (zname), or domain name, for the CDN pool. Use this attribute with the pool type CDN. Enclose the zname 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, a globals sub-statement, on page 13-9 . |
|
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, a globals sub-statement, on page 13-9 . |
|
address |
As part of a pool definition, address specifies the IP address of each virtual server in the pool. You can use the same virtual server in multiple pools, but not within the same pool. |
|
port |
Specifies a specific port to use for the specified virtual server. This sub-statement is optional. A port specified here overrides the wide IP's port setting. If a port is not specified here, the wide IP's port value is assumed. |
|
ratio |
As part of a virtual server's address specification, ratio defines the default weighting to use with respect to all virtual servers in this pool when the Ratio load balancing mode is employed. The default is 1. |
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 request is returned to DNS.
DNS attempts to resolve the request based on the contents of the zone files.
As noted in Table 13.30 , 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 (see page 13-6 ).
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)
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 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 3, Configuring a Globally Distributed Network, and Chapter 4, Configuring a Content Delivery Network, in the 3-DNS Administrator Guide. For more information on topology in general, see Chapter 11, Topology .
Syntax for the topology statement
The topology statement uses the following syntax.
Figure 13.20 Syntax for the topology statement
topology {
longest_match <yes | no>
// server ldns score
"pool.origin" cont."North America" 100
"pool.cache_farm" !cont."North America" 100
}
Definition of topology sub-statements
The topology sub-statements define the topology records that the 3-DNS Controller uses for Topology load balancing.
Access control lists
You can now create access control lists (ACLs) that contain a group of LDNS IP addresses whose paths the 3-DNS Controller will not probe. The three different types of ACLs are:
- Prober
- Hops
- Discovery
Syntax for the access control lists
The access control lists use the following syntax.
Figure 13.21 Syntax for the access control lists
actions {
NO_RELAY
delete rdb ACL region "probe_acl"
delete rdb ACL region "hops_acl"
delete rdb ACL region "discovery_acl"
}
region_db ACL {
region {
name "probe_acl"
<ldns cidr>
<ldns cidr>
}
region {
name "hops_acl"
region "probe_acl"
<ldns cidr>
<ldns cidr>
}
region {
name "discovery_acl"
<ldns cidr>
<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.
Note: For more information on ACLs, refer to Chapter 2, Access Control Lists .
Working with comments
You can insert comments anywhere you would otherwise see white space in the 3-DNS Controller configuration file.
Syntax
Note that the comment syntax depends on the environment in which you use the configuration file.
Figure 13.22 Syntax for comments
/* 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 */.
Figure 13.23 Syntax for C style comments
/* 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.
Figure 13.24 Syntax for C++ style comments
// 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.
Figure 13.25 Syntax for shell style comments
# 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.
Understanding current values
You may notice several current values in the wideip.conf file. Current values are preceded by the cur_ prefix in the wideip.conf file. The purpose of current values is to pre-load the database with previously collected statistics and metrics. The collected statistics and metrics are useful if you want to quickly restart a 3-DNS Controller without a temporary loss of intelligence.
You may notice current values associated with server, vs, path, or wideip definitions. (You can also view current values by clicking the Conf button 
in the Configuration utility.) The current values parameters show the real-time status of the servers, virtual servers, local DNS server paths, and wide IPs that make up your configuration. Examples of current values for each type of definition follow.
Warning: Do not edit the current values statements unless you are a very experienced 3-DNS Controller user, or you are instructed to do so by your vendor.
Server definition current values
Server definitions may contain several current values, as shown in
Figure 13.26 .
Figure 13.26 Example of current values in a server definition
// New York BIG-IP Controller
server {
type bigip
address 192.168.101.40
cur_ok 1 //Up
cur_packet_rate 6
cur_packet_in 1872
cur_packet_out 1812
cur_uptime 3615 //60 mins 15 Secs
[virtual server definitions]
}
The current values parameters that are shown in Figure 13.26 are defined in Table 13.33 . Note that you may see more current values than those listed here.
Virtual server definition current values
Virtual server definitions may contain several current values, as shown in Figure 13.27 .
Figure 13.27 Example of current values in a virtual server definition
vs {
address 192.168.102.50:80 //http
[ depends_on {
address 109.168.102.50:20 //ftp-data
address 192.168.102.50:443 //https
} ]
limit { /* none */ }
probe_protocol tcp
cur_state 1 // green
cur_nodes_up 3
cur_connections 0
...
cur_picks 0
cur_refreshes 41
}
The current values parameters that are shown in Figure 13.27 are defined in Table 13.34 . Note that you may see more current values than those listed here.
Local DNS server paths current values
Path definitions for local DNS servers may contain several current values, as shown in Figure 13.28 .
Figure 13.28 Example of current values in a path definition
path {
address 10.25.50.100 // LDNS
cur_rtt 102382
cur_completion_rate 10000
cur_picks 239
cur_accesses 302
}
The current values parameters that are shown in Figure 13.28 are defined in Table 13.35 . Note that you may see more current values than those listed here.
Wide IP definition current values
Wide IP definitions may contain several current values, as shown in
Figure 13.29 .
Figure 13.29 Example of current values in a wide IP definition
wideip {
address 192.168.102.70
name "www.domain.com"
port 80
cur_preferred 143982
cur_alternate 108090
cur_fallback 130094
cur_returned_to_dns 23872
[pool definitions]
}
The current values parameters that are shown in Figure 13.29 are defined in Table 13.36 . Note that you may see more current values than those listed here.
Tip: To find out how many times the 3-DNS Controller has received resolution requests for a wide IP, add the values for cur_preferred, cur_alternate, and cur_fallback.
