Applies To:

Show Versions Show Versions

Archived Manual Chapter: 3-DNS Administrator Guide v1.0.6: Statements and Comments
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



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

Figure 7.11 Comment syntax

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.

Figure 7.14 Syntax for shell style comments

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)