Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 1.0.6
7
Statements and Comments
Statements
A top-level 3DNS Controller statement begins with a keyword and may be followed by either a value, or by a block of sub-statements enclosed in braces {}.
You can find an example of a complete configuration file in Appendix C, The wideip.conf File .
The 3DNS platform supports the following top-level statements:
- globals
Controls global 3DNS Controller configuration options and sets defaults for other statements. This statement may be used only once per configuration. - bigip
Defines a BIG/ip® Server Array Controller managed by the 3DNS Controller. - host
Defines a single network server or other server array controller. - wideip
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 and/or other host machines). - topology
Implements and defines topology-based access control, and makes it possible for you to use the new topology load balancing mode (on its own and as part of the QOS mode).
Syntax rules
Keep the following rules in mind when creating and editing statements in your wideip.conf file:
- Statement order
The globals statement should appear first in the wideip.conf file, followed by bigip and host statements. The wideip statements should appear next, following by the topology statement. - Address specification
Wherever an address is required in a statement, the address must precede all other possible sub-statements. - Port specification
Wherever a port specification is required in a statement, it must immediately follow the address specification. The exception is the host statement, where the port specification follows the probe_protocol sub-statement. In all other cases, the port specification 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.
- Pool specification
A pool is a set of virtual servers defined and owned by a BIG/ip Controller or other host machine. Acceptable values are vsb (virtual servers owned by a BIG/ip Controller) and vsh (virtual servers owned by a host machine). The default is vsb. You can have both types of virtual servers in the same vsh pool definition, but you can only include virtual servers owned by a BIG/ip Controller in a vsb pool. Note that vsh pools can only use static load balancing modes. - cur_ values
You may notice several cur_ values in your wideip.conf file; do not edit them unless you are instructed to do so by F5 technical support. For more information, see Understanding cur_ values, on page C-16 .
The globals statement
The globals statement sets up global options to be used by the 3DNS Controller, and must appear before any bigip, host, or wideip statements in the wideip.conf file. Each globals sub-statement has a default setting. You do not need to edit the globals statement unless you want to change a sub-statement's default setting. If the 3DNS Controller does not find a globals statement in the configuration file, the 3DNS Controller uses a globals block, with each option set to its default.
The globals statement should appear only once in a configuration file; if the 3DNS Controller finds more than one occurrence, the 3DNS Controller generates an error, alerting you that your configuration contains multiple globals statements.
However, if you use a globals sub-statement more than once within the globals block, the 3DNS Controller uses the last listed value and does not generate an error. For example, if your globals block contains the following lines, the 3DNS Controller uses the value 50:
globals {
host_ttl 100
host_ttl 50
}
Syntax for 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 {
[ primary_ip <ip_addr> ]
[ sync_db_interval <number> ]
[ check_static_depends < yes | no> ]
[ timer_get_bigip_data <number> ]
[ timer_get_host_data <number> ]
[ timer_get_vs_data <number> ]
[ timer_get_path_data <number> ]
[ bigip_ttl <number> ]
[ host_ttl <number> ]
[ vs_ttl <number> ]
[ path_ttl <number> ]
[ rtt_timeout <number> ]
[ rtt_sample_count <number> ]
[ rtt_packet_length <number> ]
[ rtt_probe_protocol < icmp | tcp > ]
[ rx_buf_size <number> ]
[ tx_buf_size <number> ]
[ timer_check_keep_alive <number> ]
[ qos_coeff_rtt <number> ]
[ qos_coeff_completion_rate <number> ]
[ qos_coeff_packet_rate <number> ]
[ qos_coeff_topology <number> ]
[ default_alternate < rr | ratio | ga | random | return_to_dns
| topology | null > ]
[ default_fallback < rr | ratio | ga | random | return_to_dns
| topology | null > ]
Figure 7.1 Syntax for globals statement (continued on next page)
[ fb_respect_depends < yes | no > ]
[ fb_respect_acl < yes | no > ]
[ encryption < yes | no > ]
[ encryption_key_file <string> ]
[ path_hi_water <number> ]
[ path_lo_water <number> ]
[ path_duration <number> ]
[ path_reap_alg < 0 | 1 > ]
[ 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 > ]
[ check_dynamic_depends < yes | no > ]
[ rtt_probe_dynamic < yes | no > ]
[ rtt_port_discovery < yes | no > ]
[ rtt_discovery_method < short | wks | full | all > ]
[ path_max_refreshes <number> ]
}
Figure 7.2 Syntax for globals statement (continued from previous page)
Example
globals {
prober 192.168.101.2 // Default prober is New York 3DNS
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 to tcp probing if icmp
// fails
multiplex_iq yes // Source port is the same as
// destination port for iQuery
use_alternate_iq_port yes // Use IANA registered port for
// iQuery
}
Figure 7.3 Example syntax for globals statement
Definition of globals sub-statements
Each globals sub-statement supports the parameters described below.
Primary IP address
You include this sub-statement only when configuring a 3DNS Controller as a data copier.
| Parameter | Description | Default |
| primary_ip | Specifies the IP address of the data collector from which the current data copier retrieves metrics information. | 0 |
Synchronization
The synchronization sub-statement specifies how the current 3DNS Controller handles synchronizing its database with the other 3DNS Controllers in the network.
| Parameter | Description | Default |
| sync_db_interval | On a data collector, specifies the amount of time (in seconds) between updates to the database. On a data copier, specifies how often to copy and read the data collector's database file. You can enter a value between 60 and 4294967295. | 600 |
Dependencies
The dependencies sub-statement specifies whether the 3DNS Controller checks the availability of virtual servers on BIG/ip Controllers or hosts before the 3DNS Controller sends a connection to the virtual server. This check is performed only when the 3DNS Controller uses a static load balancing mode. If the 3DNS Controller is using a dynamic load balancing mode, an availability check is always performed.
| Parameter | Description | Default |
| check_static_depends | Specifies whether to check the availability of virtual servers on BIG/ip Controllers and hosts. Change this option to no if you want to test your configuration. | yes |
Periodic task intervals
These sub-statements define the frequency at which the 3DNS Controller refreshes the metrics information it collects.
| Parameter | Description | Default |
| timer_get_bigip_data | The 3DNS Controller refreshes the BIG/ip Controller information at intervals determined by timer_get_bigip_data. You can enter a value between 0 and 4294967295 seconds. | 20 |
| timer_get_host_data | The 3DNS Controller refreshes other host machine information at intervals determined by timer_get_host_data. You can enter a value between 0 and 4294967295 seconds. | 90 |
| timer_get_vs_data | The 3DNS Controller refreshes virtual server information at intervals determined by timer_get_vs_data. You can enter a value between 0 and 4294967295 seconds. | 30 |
| timer_get_path_data | The 3DNS Controller refreshes path information (for example, round trip time or ping packet completion rate) at intervals determined by timer_get_path_data. You can enter a value between 0 and 4294967295 seconds. | 120 |
| timer_check_keep_alive | The 3DNS Controller queries remote BIG/ip Controllers every timer_check_keep_alive seconds. You can enter a value between 0 and 4294967295. | 60 |
Data timeouts
These sub-statements set the amount of time for which metrics information is considered valid. Once a timeout is reached, the 3DNS Controller refreshes the information. Note that on a data copier, it is important that you set all TTL values to be greater than the value set for sync_db_interval.
| Parameter | Description | Default |
| bigip_ttl | The amount of time (in seconds) that BIG/ip Controller information is to be used by the 3DNS Controller for name resolution and load balancing. You can enter a value between 1 and 4294967295. The following relationship should be maintained: bigip_ttl > timer_get_bigip_data. A 2:1 ratio is the optimal setting for this relationship. |
60 |
| host_ttl | The amount of time (in seconds) that other host machine information is to be used by the 3DNS Controller for name resolution and load balancing. You can enter a value between 1 and 4294967295. The following relationship should be maintained: host_ttl > timer_get_host_data. |
240 |
| vs_ttl | The amount of time (in seconds) that virtual server information (data acquired from a BIG/ip Controller or other host machine about a virtual server) is to be used by the 3DNS Controller for name resolution and load balancing. You can enter a value between 1 and 4294967295. The following relationship should be maintained: vs_ttl > timer_get_vs_data. |
120 |
| path_ttl | The amount of time (in seconds) that path information is to be used by the 3DNS Controller for name resolution and load balancing. You can enter a value between 1 and 4294967295. The following relationship should be maintained: path_ttl > timer_get_vs_data. |
600 |
Metrics collection
The metrics collection sub-statements define how the 3DNS Controller collects path information.
| Parameter | Description | Default |
| rtt_timeout | Specifies how long the big3d listener waits for a probe. You can enter a value between 1 and 4294967295 seconds. | 5 |
| rtt_sample_count | To determine path information between a local DNS and a BIG/ip Controller, the number of packets (specified by rtt_sample_count) of certain length (specified by rtt_packet_length) is sent via ping from the BIG/ip Controller to the local DNS. You can enter a value between 1 and 25. | 3 |
| rtt_packet_length | To determine path information between a local DNS and a BIG/ip Controller, the number of packets (specified by rtt_sample_count) of certain length (specified by rtt_packet_length) is sent via ping from the BIG/ip Controller to the local DNS. You can enter a value between 64 and 500. | 64 |
| rtt_probe_protocol | Specifies a probe method to calculate RTT times. You can specify the ICMP or TCP protocol. | icmp |
Resource limits
The resource limits sub-statements define the amount of memory allocated to sending and receiving metrics information.
| Parameter | Description | Default |
| rx_buf_size | Specifies the maximum amount of socket buffer data memory the server can use when receiving data. You can enter a value between 8192 and 4294967295. | 16384 |
| tx_buf_size | Specifies the maximum amount of socket buffer data memory the server can use when transmitting data. You can enter a value between 8192 and 4294967295. | 8192 |
QOS values
The Quality of Service (QOS) load balancing mode distributes connections based on a path evaluation score. Using the equation below, the QOS mode compares paths between the local DNS and each virtual server included in the wideip statement. The 3DNS Controller load balances each new connection to the virtual server associated with the best 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)]
The coefficients for the score computation are defined as globals, but may be overridden within a wideip statement.
| Parameter | Description | Default |
| qos_coeff_rtt | 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 100. | 20 |
| qos_coeff_completion_rate | 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 100. | 5 |
| qos_coeff_packet_rate | Relative weighting for BIG/ip Controller packet rate when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 100. | 3 |
| qos_coeff_topology | Relative weighting for topology when the load balancing mode is set to Quality of Service. You can enter a value between 0 and 100. | 0 |
Load balancing
| Parameter | Description | Default |
| default_ alternate |
Defines the default load balancing mode used for the alternate method (formerly default_static). You can override this setting in the wideip statement. | rr |
| default_fallback | Defines the default load balancing mode used for the fall-back method. You can override this setting in the wideip statement. | return_to_dns |
| fb_respect_ depends |
Determines whether the 3DNS Controller respects virtual server status when load balancing switches to the specified fall-back mode. | no |
| fb_respect_acl | Determines whether the 3DNS Controller imposes access control when load balancing switches to the specified fall-back mode. | no |
For more information on selecting a load balancing mode, see Chapter 5 .
Encryption
The encryption sub-statements specify whether the communication between the 3DNS Controller and a BIG/ip Controller is encrypted.
| Parameter | Description | Default |
| encryption | Specifies whether to enable encryption for iQuery events. | no |
| encryption_key_file | Specifies the location and name of the iQuery encryption key file. | etc/F5key.dat |
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 3DNS Controller itself, but you can use other network servers.
| Parameter | Description | Default |
| prober | The default prober for host status, usually the 3DNS Controller IP address. Using this sub-statement is not necessary if the 3DNS Controller only manages the BIG/ip Controller. This sub-statement can be overridden within the host statement. | 0.0.0.0 |
Warning: We recommend that you define a default prober if the 3DNS Controller manages virtual servers on hosts. If you do not define a default prober, and you do not define probers for all hosts, you may encounter validation errors.
Buffer size
The buffer size sub-statements specify the maximum amount of UDP data that the 3DNS Controller can receive, and also specify the maximum amount of TCP data that the 3DNS Controller can send.
| Parameter | Description | Default |
| resolver_rx_buf_size | The UDP receive buffer size. The value is overridden only if it is larger than the one first assigned by the kernel. | 8192 |
| resolver_tx_buf_size | The TCP send buffer size. | 16384 |
Reaping
The default reaping values are adequate for most configurations. Contact F5 technical support if you want to make changes to them.
Note: The default values for path_hi_water and path_lo_water vary depending on available memory and are automatically established during the startup process.
| Parameter | Description | Default |
| path_hi_water | Specifies the high water mark for reaping. | varies |
| path_lo_water | Specifies the low water mark for reaping. | varies |
| path_duration | An event is triggered every path_duration seconds that calls the reaping function. You can enter a value between 3600 and 2419200 seconds. | 345600 |
| path_reap_alg | Specifies the method by which unexpired paths are reaped during the general reap process. You can enter 0, which corresponds to least recently used, or 1, which corresponds to least number of hits. | 0 |
iQuery port options
| Parameter | Description | Default |
| use_ alternate_ iq_port |
Determines whether the 3DNS Controller runs iQuery traffic on port 245 (the port used in older configurations), or on the new registered iQuery port, 4353. The default setting, no, uses port 245. To use port 4353, change this setting to yes. | no |
| multiplex_ iq |
Determines whether the 3DNS Controller uses the ephemeral ports for iQuery traffic returned from the big3d utility. To force iQuery traffic to use port 4353 for all incoming iQuery traffic, change this setting to yes. | no |
Probing
| Parameter | Description | Default |
| paths_never_ die |
Specifies that dynamic load balancing modes can use path data even after the TTL for the path data has expired. We recommend that you change this setting to yes, which has the effect of requiring that the 3DNS Controller always uses path data even if the path's TTL expires. | no |
| paths_ noclobber |
Specifies whether the 3DNS Controller overwrites existing path data with blank data when a path probe fails. We recommend that you change this setting to yes, which has the effect of requiring that the 3DNS Controller does not overwrite existing path data with blank data when a path probe fails. | no |
| check_dynamic_ depends |
Specifies that the 3DNS Controller checks the availability of a path before it uses the path for load balancing. | yes |
| rtt_probe_ dynamic |
Determines whether the 3DNS Controller attempts a second probe using the alternate probe protocol if the probe protocol specified by rtt_probe_protocol fails during the first probe. | no |
| rtt_port_ discovery |
Determines whether the 3DNS Controller uses the discovery factory to find an alternate port to be used by the probing factory, if probing on port 53 fails. | no |
| rtt_ discovery_ method |
Determines which ports to scan. | short |
| path_max_ refreshes |
Determines the maximum number of times the 3DNS Controller requests new data for the path. | 0 (no limit) |
The bigip statement
The bigip statement defines the characteristics associated with a particular BIG/ip Controller.
A bigip statement contains the following information:
- The IP address of the BIG/ip Controller.
- The set of virtual servers that are available on the specified BIG/ip Controller.
- Dynamically collected information about the BIG/ip Controller, its virtual servers and ports, and the paths between the BIG/ip Controller and local DNS.
Syntax for bigip statement
The bigip statement syntax includes the following sub-statements.
bigip {
address <ip_addr>
vs {
address <ip_addr>:<port_number>
port <port_number> | service <"service_name">
[ ratio <number> ]
[ translate {
address <ip_addr>
port <port_number>|service <"service_name">
}
}
}
Figure 7.4 Syntax for bigip statement
Example
bigip {
// New York
address 192.168.101.40
vs {
address 192.168.101.50
port 80
translate {
address 10.0.0.50
port 80
}
}
}
Figure 7.5 Example syntax for bigip statement
Definition of bigip sub-statements
The bigip sub-statements specify information about the virtual servers managed by a BIG/ip Controller.
| Parameter | Description |
| address | In the context of a bigip statement, address specifies the IP address of the BIG/ip Controller. |
| vs | Indicates the start of a virtual server definition. Once you define a virtual server here (including specifying the address and port), you can then use this virtual server in a wideip definition. |
| address | As part of a virtual server (vs) definition, address specifies the IP address of a virtual server owned by this BIG/ip Controller. Note that the virtual server's address must be listed first, before port, service, or ratio values. |
| port or service | The virtual server's port number or service name. You can add the port number, preceded by a colon, on the same line as the virtual server's address, or you can enter it on the next line. You can use the service name if it is a WKS (well known service) and you enclose it in quotation marks. |
| translate | Specifies that iQuery packets sent to the BIG/ip Controller include translated IP addresses (required if the packets must pass through a firewall). When you use this keyword, you must then include name and port/service information for the translated IP addresses. |
The host statement
The host statement defines information about the host itself, including its IP address, and also defines information about the individual virtual servers associated with it.
Syntax for host statement
host {
address <ip_addr>
probe_protocol <tcp | icmp>
port <port>
[prober <ip_addr>]
vs {
address <ip_addr>:<port_number>
port <port_number> | service <"service_name">
probe_protocol <tcp | icmp>
}
}
Figure 7.6 Syntax for host statement
Example
host {
// Tokyo
address 192.168.104.40
vs {
address 192.168.104.50:80
probe_protocol tcp
}
}
Figure 7.7 Example syntax for host statement
Definition of host sub-statements
The host sub-statements define information about the virtual servers managed by a host server. The host sub-statements also define the method used to ping the host server to verify if it is available.
| Parameter | Description |
| address | In the context of a host statement, address specifies the host machine's IP address. |
| probe_protocol | The protocol method to use for probing this host: TCP or ICMP. |
| port | The port used to probe this host if probe_protocol is set to TCP. |
| prober | The IP address of the machine probing the host. This IP address points to either a BIG/ip Controller or a 3DNS Controller that runs the big3d utility. The big3d utility actually probes the host and virtual servers to verify whether the host or a particular virtual server is currently available to accept connections. If you omit this parameter in the host sub-statement, the 3DNS Controller uses the prober <ip_addr> parameter defined in the globals statement. |
| vs | Indicates the start of a virtual server definition. Once you define a virtual server here (including specifying the address, port, and probe_protocol values), you can then use this virtual server in a wide IP definition. Each host statement can include multiple virtual servers, but must always include at least one virtual server. |
| address | As part of a virtual server (vs) definition, address specifies the IP address of a virtual server owned by this host machine. |
| port or service | The virtual server's port number or service name. You can add the port number, preceded by a colon, on the same line as the virtual server's address, or you can enter it on the next line. You can use the service name if it is a WKS (well known service) and you enclose it in quotation marks. |
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 and/or other host machines).
A wide IP contains one or more pool sub-statements that define individual load balancing pools. A load balancing pool is a group of virtual servers that the 3DNS Controller load balances, and it is limited only in that the virtual servers included in the pool must be of the same type (either BIG/ip virtual servers or host virtual servers).
A wideip statement specifies the following:
- A domain name and a key.
- A set of virtual servers accessing all the instances of a mirrored service.
- Parameters configuring the algorithm which chooses the best virtual server for each transaction.
Syntax for wide IP statement
wideip {
address <ip_addr>
port <port_number> | <"service name">
name <"domain_name">
[ alias <"alias_name"> ]
[ ttl <number> ]
[ port_list <port_number> <port_number> ... ]
[ qos_coeff {
rtt <n>
completion_rate <n>
packet_rate <n>
topology <n>
} ]
[ pool_lbmode <rr | ratio | ga | random> ]
pool {
name <"pool_name">
type <vsb | vsh>
[ ratio <pool_ratio> ]
[ preferred <rr | ratio | ga | topology |
random | leastconn | packet_rate |
completion_rate | rtt | qos> ]
[ alternate <rr | ratio | ga | topology |
random | return_to_dns | null> ]
[ fallback <rr | ratio | ga | topology |
random | leastconn | packet_rate |
completion_rate | rtt | qos> ]
address <vs_addr>[:<port>] [ratio <weight>]
}
}
Figure 7.8 Syntax for wideip statement
Example
//
wideip {
address 192.168.101.50
service "http"
name "www.wip.domain.com"
qos_coeff {
rtt 21
completion_rate 7
packet_rate 5
topology 1
}
pool {
name "pool_1"
type vsb
ratio 2
preferred qos
address 192.168.101.50 ratio 2
address 192.168.102.50 ratio 1
address 192.168.103.50 ratio 1
}
pool {
name "pool_2"
type vsb
ratio 1
preferred rr
address 192.168.102.60 ratio 2
address 192.168.103.60 ratio 1
}
}
Figure 7.9 Example syntax for wideip statement
Definition of wideip sub-statements
Wide IP sub-statements defines groups 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 specifies the wide IP key (see Understanding the wide IP key, on page 4-28 ). They also specify the pool of virtual servers that the wide IP load balances.
| Parameter | Description |
| address | A key that represents one valid virtual server IP address from the set which services this wide IP. This key is also listed as the A record in the zone file for the domain. See Understanding the wide IP key, on page 4-28 . |
| port or service | The virtual server's default port number or service name. You can use the service name if it is a WKS (well known service) and you enclose it in quotation marks. |
| name | The domain name for this wide IP (for example, "www.wip.f5.com"). All names must be enclosed in quotation marks. |
| alias | An alternate name for this wide IP. All names must be enclosed in quotation marks. Alias names are treated the same as the domain name. You can specify up to 200 alias names for each wide IP. |
| ttl | The amount of time (in seconds) that the specified wide IP's information is used by the 3DNS Controller for name resolution and load balancing. |
| port_list | Specifies a list of ports that must be available before the 3DNS Controller can send connections to the specified address. |
| qos_coeff | Relative weighting for each load balancing method in calculating the Quality of Service mode. Each load balancing mode is described in the next table. |
| pool_lbmode | The load balancing mode to use to balance requests over all pools. |
| pool | 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 or other host machine. |
| name | As part of a pool definition, defines the name of this pool. All names must be enclosed in quotation marks. |
| type | The type of pool: vsb (virtual servers owned by a BIG/ip Controller) and vsh (virtual servers owned by a host machine). The default is vsb. You cannot include both types of virtual servers in the same pool definition. |
| ratio | As part of a pool definition, ratio specifies the default weighting to use with respect to other pool types. |
| preferred | The load balancing mode to use for the specified pool. Each acceptable value is described in the next table. |
| alternate | The load balancing mode to use for the specified pool if the preferred mode fails. The default is rr. Also see the description of default_alternate, a globals sub-statement, on page 7-13 . |
| fallback | The load balancing mode to use for the specified pool if the alternate mode fails. If the fallback mode fails, the 3DNS 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 7-13 . |
| address | As part of a pool definition, address specifies the IP address of each virtual server in this pool. You can use the same virtual server in multiple pools, but not within the same pool. |
| port | An optional part of specifying a virtual server. 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 mode
The load balancing sub-statements specify the load balancing modes to use for the wide IP in this order:
- The 3DNS Controller attempts to load balance requests using the preferred mode.
- If the preferred mode fails, the 3DNS Controller tries the alternate mode.
- If the alternate mode fails, the 3DNS Controller tries the fallback mode.
- If the fallback mode fails, the request is returned to DNS.
As noted in the table below, 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, the wide IP uses the load balancing mode defined in the globals statement (see page 7-13 ).
Parameter Description completion_rate Least packets dropped (or timed out). Valid for vsb pools only, and only in a preferred or fallback sub-statement. global_availability First virtual server listed in the wide IP definition. Valid for both vsb and vsh pools. leastconn Least number of current connections for a virtual server. Valid for vsb pools only, and only in a preferred or fallback sub-statement. null Bypasses the current load balancing method and forces the 3DNS 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 only in an alternate or fallback sub-statement. packet_rate Least packets per second the BIG/ip Controller is processing. Valid for vsb pools only, and only in a preferred or fallback sub-statement. qos User definable metric that includes a combination of packet rate, completion rate, RTT, and topology. Valid for vsb pools only, and only in a preferred or fallback sub-statement. random Virtual server chosen at random from the wide IP set of virtual servers. Valid for both vsb and vsh pools. ratio Distributed percentages. Valid for both vsb and vsh pools. return_to_dns Returns the resolution request to DNS, preventing the 3DNS Controller from using the next load balancing method or using the next available pool. Valid only in an alternate or fallback sub-statement. rr Circular and sequential. Valid for both vsb and vsh pools. rtt Shortest timed ICMP packet from a virtual server's BIG/ip Controller to the requestor's local DNS. Valid for vsb pools only, and only in a preferred or fallback sub-statement. topology Distributes connections based on the proximity of a local DNS to a particular data center. Use the following equation to configure the QOS load balancing mode:
A (1/packet rate) + B (1/rtt) + C (completion rate) + D (topology)
For more information on each mode and some load balancing examples, see Chapter 5, Load Balancing .
The topology statement
The topology statement implements a form of wide-area IP filtering. Topology-based access control allows you to specify which data centers are acceptable for a given resolution request, based on the proximity of the data center's IP address to the requesting IP address of the local DNS server. For example, you can specify that requesting local DNS 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 also use the topology load balancing mode, both on its own and as part of the QOS mode.
For more information and an example of a topology statement, see Topology-based access control, on page 5-15 .
Syntax for topology statement
topology {
acl_threshold <1 | 0>
limit_probes <yes |no>
longest_match <yes | no>
<server cidr> <LDNS cidr> <score>
}
Figure 7.10 Syntax for topology statement
Definition of topology sub-statements
| Parameter | Description |
| acl_threshold | Provides a hook for administrators to set up access control to data centers based on local DNS IP addresses by specifying a score threshold. Any server/local DNS matching a list record with a score below this threshold is interpreted as if the virtual server were unavailable. |
| limit_probes | Specifies whether to apply access control to the probing of paths. If this parameter is set to yes, the 3DNS Controller requests a given BIG/ip Controller to probe only those local DNS servers that can connect to it according to the acl_threshold value and the topology map scores. |
| longest_match | In cases where there are several IP/mask items that match a particular IP address, longest_match specifies whether the 3DNS Controller selects the record that is most specific, and thus has the longest mask. |
| mask virtual server | The server mask for a given data center. This is one of two values used to determine the longest match. |
| mask LDNS | The local DNS mask. This is one of two values used to determine the longest match. |
| mask score | The mask score, which is used for the comparison of virtual servers when the topology load balancing mode is employed. |
Comments
You can insert comments anywhere you would otherwise see white space in the 3DNS Controller configuration file.
Syntax
Note that the comment syntax depends on the environment in which you use the configuration file.
For example:
/* This is a 3DNS comment as in C */
// This is a 3DNS comment as in C++
# This is a 3DNS 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 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. */
Figure 7.12 Syntax for C style comments
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.
For example:
// 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.
Figure 7.13 Syntax for C++ style comments
Shell style comments
Shell style (also known as Perl style) comments start with the # character and are no longer than one line in length.
For example:
# 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.
