13

wideip.conf Configuration

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, and hosts), and wide IPs. The wideip.conf file consists of two types of information: statements and comments.

Your wideip.conf file should include at least the following definitions.

• A datacenter statement. If you do not create one, the 3-DNS Controller creates one for each configured server and names each as follows: generic-<server IP address>
• 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, named does not start.
• If the file can be parsed, 3-DNS Controllers revert to standard DNS behavior.

To open the /etc/wideip.conf file

1. At the command line, type 3dnsmaint.
   The 3-DNS Maintenance menu opens.
2. 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 in 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. In addition, include files lead to better system performance because metrics for each aspect of your network are collected and dumped only to the relevant file, instead of having all metrics collected and dumped in a single, potentially unwieldy, file.

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 1 Syntax for include files

 include root_in "/var/3dns/include"    
   include root_out "/var/3dns/include"    
   include global <"file_name.inc">    
   include datacenter <"file_name.inc">    
   include sync_group <"file_name.inc">    
   include server <"file_name.inc">    
   include bigip <"file_name.inc">    
   include host <"file_name.inc">    
   include 3dns <"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 <"file_name.inc">    
   include region <"file_name.inc">    
   include manifest <"file_name.inc">    

Definitions of include statements

Table 1 lists the include statements, their descriptions, and their default file names.

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 braces {}.

The 3-DNS platform supports the following top-level statements.

• include
  The include statement lists any include files that are configured on the 3-DNS Controller.
• globals
  The globals statement defines system-level settings for any 3-DNS Controller configuration options and sets defaults for other statements.
• datacenter
  The datacenter statement defines the group of 3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, 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.
• server
  The server statement defines a 3-DNS Controller, a BIG-IP Controller, an EDGE-FX Cache, or a host machine.
• 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 QOS mode). Note that while the topology statement is still valid, the topology.inc file is the preferred location for topology configuration information.

Syntax rules

Keep the following rules in mind when creating and editing statements in your wideip.conf file.

• Statement order
  Statements should appear in this order in the wideip.conf file:
  
  
  • globals
  • datacenter
  • sync_group
  • server
  • wideip
• 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.

• 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 your vendor's technical support. For more information, see Understanding cur_values .

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.
• 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 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 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> ]    
     [ 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 > ]     
   [ 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 4 shows an example of a valid globals statement.

Figure 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

Each globals sub-statement supports the parameters 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

The value for persist_ldns must be set to yes (the default) for the 3-DNS Controller to store and use path information. Dynamic load balancing modes depend on path information to resolve requests. If you use only static load balancing modes, you can set persist_ldns to no to conserve memory.

Periodic task intervals

These sub-statements define the frequency at which the 3-DNS Controller refreshes the metrics information it collects.

Data timeouts

These sub-statements set the amount of time for which metrics information is considered valid. After a timeout 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 (QOS) load balancing mode distributes connections based on a path evaluation score. Using the equation below, the QOS 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.

Figure 5 QOS equation

 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, 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

The iQuery port options determine which port (or ports) the 3-DNS Controller uses to send and receive iQuery traffic.

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 datacenter statement

A datacenter statement defines the group of 3-DNS Controllers, BIG-IP Controllers, and hosts that reside in a single physical location.

Syntax for the datacenter statement

The datacenter statement uses the following syntax.

Figure 6 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>    
   }    

Figure 7 shows an example of a valid datacenter statement.

Figure 7 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    
   }    

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 8 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 9 shows an example of a valid sync_group statement.

Figure 9 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 the 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 server statement

The server statement defines the characteristics associated with a particular 3-DNS Controller, BIG-IP Controller, EDGE-FX Cache, 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, or host
• The IP address 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 38 .

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 10 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 11 shows an example of the syntax to use in defining a 3-DNS Controller.

Figure 11 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 12 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 shows an example of the syntax to use in defining a BIG-IP Controller.

Figure 13 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)

The following server statement syntax applies to EDGE-FX Caches only.

Figure 14 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">    
       } ]    
     [ interface {    
         address <NIC IP address>    
         address <NIC IP address>    
       } ]    
       
     [ probe_protocol < icmp | ucp | tcp | dns_dot | dns_rev > ]    
     [ ratio <number> ]    
     [ factories {    
         prober <number>    
         discovery <number>    
         hops <number>    
         snmp <1>  {  //required    
            agent edgefx    
            version 2    
            community <"public">    
         }    
       } ]    
    [ vsmetrics < yes | no > ]    
    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 (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, in the 3-DNS Controller Reference Guide.

Figure 15 Server statement syntax for defining a host

 server {    
     type host    
     address <IP address>    
     name <"host_name">    
     probe_protocol <tcp | icmp | udp | 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 | udp| 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 16 shows an example of the syntax to use in defining a host.

Figure 16 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 19 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, 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, big3d Agent, in the 3-DNS Controller Reference Guide.

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 Cache 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 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 17 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 18 shows an example of a valid wideip statement.

Figure 18 Example syntax for the wideip statement

 wideip {    
      address           192.168.102.50    
      service           "smtp"    
      name              "mx.wip.domain.com"    
      alias             "mail.wip.domain.com"    
      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

Wide IP 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.

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.

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 29 , 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 7 ).

Use the following equation to configure the QOS 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 QOS 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 Controller Administrator Guide. For more information on topology in general, see Chapter 10, Topology, in the 3-DNS Controller Reference Guide.

Syntax for the topology statement

The topology statement uses the following syntax.

Figure 19 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 20 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"    
         region "probe_acl"    
         <ldns cidr>    
         <ldns cidr>    
      }    
      region {    
         name "hops_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.

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 21 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 22 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 23 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 24 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 cur_values

You may notice several cur_values in your wideip.conf file. The purpose of cur_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 cur_ values in server, vs, path, or wideip definitions. The cur_values parameters show the status of the servers, virtual servers, local DNS server paths, and wide IPs. Examples of cur_values for each type of definition follow.

Warning: Do not edit the cur_values statements unless you are a very experienced 3-DNS Controller user, or you are instructed to do so by your vendor.

Server definition cur_values

Figure 25 Example of cur_ values in a server definition

 // New York BIG-IP Controller    
   server {     
     type bigip    
     address 192.168.101.40    
     cur_packet_rate 139    
     cur_ok 1    
     [virtual server definitions]    
   }    

In the example shown in Figure 25 , the cur_ values parameters are defined as indicated in the following table.

Virtual server definition cur_values

Figure 26 Example of cur_ values in a virtual server definition

 vs {    
     address 192.168.102.50:80    
     cur_serv_cnt 1    
     cur_connections 0    
     cur_picks 39    
     cur_refreshes 783    
   }     

In the example shown in Figure 26 , the cur_ values parameters are defined as indicated in the following table.

 path {    
     address 10.25.50.100 // LDNS    
     cur_rtt 102382    
     cur_completion_rate 10000    
     cur_picks 239    
     cur_accesses 302    
   }   

 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    
     [virtual server definitions]    
   }