Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 2.1 PTF-01, 2.1.2, 2.1.0
2
Preparing for Installation
Reviewing the installation tasks
This chapter covers the planning issues that you need to address before you install and set up the 3-DNS Controller. It explains the three different phases of an installation, along with load balancing configuration options and important DNS planning issues. If you plan to do a simple configuration, briefly review the hardware setup and network setup requirements, along with the load balancing options. If you plan to do a more advanced configuration, we recommend that you read about each advanced feature you want to work with in Chapter 6 before you begin the installation.
Be sure to review the DNS zone file management section included later in this chapter. It provides an important overview of the process involved in setting up a 3-DNS Controller that runs as a master DNS server, as well as integrating 3-DNS Controllers into networks that have an existing master DNS server.
Understanding the installation phases
You can set up a basic 3-DNS Controller configuration, or an advanced 3-DNS Controller configuration. Regardless of whether you are creating a basic or an advanced configuration, you always go through three installation phases:
- Hardware setup
The hardware setup phase simply gets the hardware up and running, and connected to the network. This includes completing the configuration settings that allow remote access for command line access via a UNIX shell, and for the 3-DNS web server which hosts the Configuration utility. You must do the hardware setup on all 3-DNS Controllers in your network. - Network setup
During the network setup phase, you define the network layout of the servers that the 3-DNS Controller uses for load balancing and path probing. You define the different data centers in the network, as well as the equipment that runs in each data center. You also set up a sync group, which is a group of 3-DNS Controllers that share system configurations. Note that at this point, you can define the configuration on the 3-DNS Controller that is the principal controller in the sync group, and then all other controllers in the sync group automatically copy the configuration from the principal controller. - Load balancing configuration
The load balancing configuration is the last phase of a 3-DNS Controller installation. This phase can be simple and fast if you are setting up a very basic configuration, particularly if you allow the NameSurfer application to handle the DNS zone file management for you. If you are planning to use a more advanced load balancing configuration, however, you may need to do some additional planning.DNS zone file integration happens at different times, depending on how you decide to handle DNS zone file management, and depending on whether you are installing new 3-DNS Controllers in your network, or upgrading existing 3-DNS Controllers in your network. Issues relating to DNS zone file management are covered in Planning DNS zone file management, on page 2-32 .
Working with configuration tools
When you configure the 3-DNS Controller, you have two configuration tool options:
- We recommend that you use the browser-based Configuration utility in conjunction with the NameSurfer application. Using these tools together provides two significant benefits that make for simplified system administration. First, when you make configuration changes to any 3-DNS Controller in the network, the sync feature automatically broadcasts the changes to all other 3-DNS Controllers in the network. Second, when you add or modify wide IP definitions in the Configuration utility, the NameSurfer application automatically makes the appropriate updates to the DNS zone files. You do not need to do any DNS zone file maintenance yourself.
- If you prefer, you can manually configure the 3-DNS Controller using the Edit 3-DNS Configuration command on the 3-DNS Maintenance menu (a command line tool). However, this method requires that you make corresponding changes to DNS zone files manually, which can be quite complex. It also requires that you individually configure each 3-DNS Controller in the network.
If you have worked with previous versions of the 3-DNS Controller, you can view statement syntax in the Configuration utility. To display the existing configuration at any time, click the View Configuration button in the Conf column of certain screens in the configuration utility.
Warning: We recommend that you do not switch between using the Configuration utility and manually configuring the 3-DNS Controller. If you manually configure a 3-DNS Controller and then attempt to use the Configuration utility to modify the configuration, you risk losing custom configuration settings not supported by the Configuration utility.
Planning issues for the hardware setup
In the hardware setup phase, you connect the 3-DNS Controller hardware to the network, and run the First-Time Boot utility on each of the 3-DNS Controllers in the network. The First-Time Boot utility is a command line wizard that helps you define basic required system settings such as the IP address, host name, root user ID, and other information necessary for the controller and its web server to be accessible over the network.
When you run the First-Time Boot utility, you must work on a keyboard and monitor, or a serial terminal, connected directly to the 3-DNS Controller. However, after you complete the hardware setup phase, you can finish the remaining installation tasks from a remote administrative workstation.
Gathering basic information
The prompts in the First-Time Boot utility are generally self-explanatory, and you should be able to answer them as long as you prepare the following information before you start running the utility:
- Root administration password for each controller
- IP addresses for each network interface, and a shared IP alias for each redundant system
- Host names used on each network interface
- IP addresses of remote workstations that need to access the controllers
- Time zones for each controller
- IP addresses and remote connection requirements (ssh versus rsh) for all 3-DNS Controllers and BIG-IP Controllers in the network configuration
- Authentication certificate settings (company name, address, etc.) for 3-DNS web servers that run on crypto 3-DNS Controllers
Addressing special hardware configuration issues
Before you start the hardware setup, you may want to review the following items which address configuration and management issues for redundant systems, systems that use more than one network interface, and DNS zone file management.
Are you setting up a stand-alone unit or a redundant system?
If you are setting up a stand-alone unit, you need one IP address and host name for each of the interfaces you plan to connect to the network. If you are setting up a redundant system, you need one IP address for each network interface card in each unit, as well as a shared IP alias for the primary network interface, and a shared IP alias for the secondary network interface (if you are connecting the redundant system to more than one network).
If you are setting up a redundant system, are you using hardware-based fail-over or network-based fail-over?
Hardware-based fail-over is a redundant system that connects two 3-DNS Controller units directly to each other using a fail-over serial cable. Network-based fail-over is a redundant system where two units are either connected to each other directly using an Ethernet cable, or they are connected indirectly via an Ethernet network. Of the two units in a redundant system, one runs as the active unit, managing all DNS resolution requests, and the other runs as the standby unit, waiting to take over in case the active unit fails and reboots. The communication between the units, such as fail-over notification, runs across either the fail-over cable in the hardware-base redundant system, or the network in the network-based redundant system.
When you run the First-Time Boot utility, it prompts you to enter the IP address of the other unit in the system.
What events trigger a fail-over in a redundant system?
The 3-DNS Controller tracks two key aspects of the system to validate system performance. In a redundant system, there are two events that indicate a system failure and trigger a fail-over.
- If the named daemon becomes unresponsive, or if you manually stop the daemon using the ndc stop or ndc restart commands, the 3-DNS Controller treats this as system failure and initiates a fail-over.
- If the 3-DNS Controller fails to detect any traffic on its network interfaces, it attempts to create traffic to test the integrity of the interface. If the test fails, the 3-DNS Controller treats this as a system failure and initiates a fail-over.
How do redundant systems work with the sync group feature?
If you include a redundant system in a sync group, you include the system by specifying the system's shared IP alias. When a controller in the sync group broadcasts new information to the redundant system, only the active unit receives the updated information. The moment a fail-over occurs and the standby unit becomes active, the next synchronization check compares timestamps on the configuration files and immediately updates the unit with the current system configuration, path metrics, and DNS zone files.
If you have a sync group that includes a redundant system, you may want to make test changes to the configuration on the standby unit, without having those changes synchronized to the other controllers in the group. As long as the unit runs as a standby, the changes remain local. Once you validate your changes and you are ready to broadcast them to the other controllers in the group, you can run the bigpipe fo command on the active unit to force a fail-over. After the system fails over to the standby unit with your new configuration changes, those changes broadcast to the other controllers in the group during the next synchronization pass.
Note that you always run the risk of having the active unit initiate a fail-over to the standby unit before you can verify that the configuration changes are complete. Although the 3-DNS Controller does not commit any configuration changes that violate syntax rules, there is always the possibility that a fail-over may occur before you complete your configuration changes.
Are you planning on using more than one network interface?
The First-Time Boot utility prompts you to configure the primary network interface, and then asks if you want to configure more interfaces, or if you want to skip to the next section of the utility. If you want to configure another network interface, you simply enter the same type of information you entered for the first interface. The other interfaces can connect to a separate network, or they can act as redundant paths to the same network that the first interface is connected to.
Do you want to set up automatic DNS zone file management?
The First-Time Boot utility asks you if you want to use the NameSurfer application as the master for DNS zone files. We recommend that you always run NameSurfer as the master for DNS zone files. When you define or modify wide IPs in the Configuration utility, NameSurfer automatically makes the corresponding changes to the DNS zone files. The NameSurfer application also provides you with easy management of high-level domain zone files unrelated to the wide IP configuration.
If you plan on transferring existing BIND files from a master DNS server to the 3-DNS Controller, you do not configure NameSurfer when you run the First-Time Boot utility; you configure the application later on in the installation process. For more details about this and other DNS zone file management issues, see Planning DNS zone file management, on page 2-32 .
Planning issues for the network setup
After you finish running the First-Time Boot utility and get each controller connected to the network, you can do the network setup and load balancing configuration on one controller, and let the sync group feature automatically broadcast the configuration to the other controllers in the network. You do not have to configure 3-DNS Controllers individually, unless you are planning an advanced configuration that requires different configurations for different data centers, or you are doing the configuration manually.
During the network setup phase, you define three basic aspects of the network layout, in the following order:
- Data centers
Data centers are the physical locations that house the equipment you use for load balancing. - Servers
The servers you define in the network setup include only the 3-DNS Controllers, BIG-IP Controllers, and host machines that you use for load balancing. - Sync group
A sync group defines the group of 3-DNS Controllers that shares configuration settings and path data.
Note: During the network setup phase of configuration, we recommend that you connect to the 3-DNS Controller from a remote workstation where you can complete the remaining configuration tasks using the web-based Configuration utility.
Defining data centers and servers
It is important that you define all of your data centers before you begin defining servers. When you define a server, you specify the data center where the server runs by choosing a data center from the list of data centers you have already defined.
To define a data center, you need only specify the data center name. To define a server, however, you need to specify the following items:
- Server type (3-DNS Controller, BIG-IP Controller, or host)
- Server IP address (or shared IP alias for redundant systems)
- Name of the data center where the server runs
- big3d agent settings (BIG-IP Controllers and 3-DNS Controllers only)
- Virtual servers managed by the server (BIG-IP Controllers and hosts only)
- SNMP host probing settings (hosts only)
The most important part of planning data centers and servers is to decide how to set up the big3d agent, and which ports you need to open for communications between the controllers in your network. The following sections in this chapter, Setting up data collection with the big3d agent, on page 2-9 , and Setting up communications between 3-DNS Controllers, BIG-IP Controllers, and big3d agents, on page 2-17 , provide help with determining how both of these issues affect your installation.
Understanding how the time tolerance variable affects sync groups
The time tolerance value is a global variable that defines the number of seconds that one 3-DNS Controller's time setting is allowed to be out of sync with another 3-DNS Controller's time setting. If the difference between the times on the controllers is greater than the time tolerance, the time setting on the controller running behind is reset to match the controller with the most recent time. For example, if the time tolerance is 5 seconds, and one 3-DNS Controller is running 10 seconds ahead of the other, the controller running behind has its time reset to match the one running 10 seconds ahead. If the second controller was running only 2 seconds ahead of the other, the time settings would remain unchanged. The values are 0, 5, and higher (values of 1-4 are automatically set to 5, and 0 turns off time syncing). The default setting is 10 seconds.
The time setting on 3-DNS Controllers is important because a 3-DNS Controller compares time stamps on files when deciding whether to synchronize files with other 3-DNS Controllers in the sync group.
Setting up data collection with the big3d agent
The big3d agent collects performance information on behalf of the 3-DNS Controller. The big3d agent runs on both 3-DNS Controllers and BIG-IP Controllers. The default setting is to run a big3d agent on all controllers in the network, but you can turn off the big3d agent on any controller at any time.
Setting up the big3d agents involves the following tasks:
- Installing big3d agents on BIG-IP Controllers
Each time you receive new 3-DNS Controller software, the software includes the latest version of the big3d agent. You need to distribute that copy of the big3d agent to the BIG-IP Controllers in the network. Use the 3dnsmaint menu item to automatically install the appropriate version of the big3d agent for each version of the BIG-IP Controller. See the release notes provided with the 3-DNS Controller software for information about which BIG-IP Controller versions the current big3d agent supports. - Specifying which factories a specific big3d agent manages
When you define BIG-IP Controller and 3-DNS Controller servers, you can change the default big3d agent settings on a specific controller. You can change the number of factories the big3d agent runs and turn specific factories on and off. - Setting up communications between big3d agents and controllers
Before the big3d agents can communicate with the 3-DNS Controllers in the network, you need to configure the appropriate ports and tools to allow communication between the BIG-IP Controllers and 3-DNS Controllers in the network. These planning issues are discussed in Setting up communications between 3-DNS Controllers, BIG-IP Controllers, and big3d agents, on page 2-17 .
Path data and server performance
A big3d agent collects the following types of performance information used for load balancing. This information is broadcast to all 3-DNS Controllers in your network.
- Virtual server availability
The big3d agent queries virtual servers to verify whether they are up and available to receive connections. For name resolution, the 3-DNS Controller uses only those virtual servers that are up. - Network path round trip time
The big3d agent calculates the round trip time for the network path between the data center and the client's LDNS server that is making the resolution request. Round trip time is used in determining the best virtual server when using the Round Trip Times or the Quality of Service modes. - Network path packet loss
The big3d agent calculates the packet completion percentage for the network path between the data center and the client's LDNS server that is making the resolution request. Packet completion is used in determining the best virtual server when using the Completion Rate or the Quality of Service modes. - Hops along the network path
The big3d agent calculates the number of intermediate systems transitions (hops) between the data center and the client's LDNS server. Hops are used in determining the best virtual server when using the Hops or the Quality of Service load balancing modes. - Server performance
The big3d agent calculates the packet rate of the BIG-IP Controller or SNMP-enabled hosts. Packet rate is used in determining the best virtual server when using the Packet Rate or the Quality of Service load balancing modes - BIG-IP virtual server performance
The big3d agent calculates the number of connections to a virtual server defined on a BIG-IP Controller. The number of connections is used to determine the best virtual server when using the Least Connections load balancing mode.
Installing the big3d agent on BIG-IP Controllers
To install the big3d agent on the BIG-IP Controllers in your network, log on to the 3-DNS Controller using either a remote shell, or the serial terminal or keyboard and monitor attached directly to the controller. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu and choose the Install and Start big3d command.
Understanding factories run by big3d agents
To gather performance information, the big3d agent uses different types of factories. A factory is a process which collects different types of data. The big3d agent currently supports five factory types:
- Probing factory
A probing factory collects several types of information using ICMP, TCP, UDP, DNS_DOT, or DNS_VER protocols. This factory queries host virtual servers and LDNSs. Host virtual servers are checked to determine their up or down state. For LDNSs, the probing factory uses the response to calculate the round trip time and packet loss between the LDNS and the data center. - Hops factory
A hops factory uses the traceroute method to calculate the number of intermediate systems transitions along the network path between a specific data center and a client LDNS. - SNMP factory
An SNMP factory uses conversations with SNMP agents that run on host servers to collect performance metrics for the host. - Discovery factory
A discovery factory acts as a backup to a probing factory, and the big3d agent runs a discovery factory only when a probing factory fails to get a response from a specific LDNS. The big3d agent uses the discovery factory to look for an alternate port on an LDNS that can respond to the queries issued by a probing factory. If the discovery factory finds an open port, it returns the port number to the 3-DNS Controller, which stores the number to use for future path probe attempts. - Permanent factories
Two permanent factories collect performance information. One factory collects information from the BIG-IP Controller when it exists, the other collects the number of packets being processed per second. These factories are not configurable.The standard configuration specifies that each BIG-IP Controller and 3-DNS Controller in the network runs a big3d agent using five prober factories, one SNMP factory, one discovery factory, no hops factories, and the two default factories. In the BIG-IP Controller or 3-DNS Controller server definition, you can change the number of factories that the big3d agent runs. For example, the default number of hops factories is set to 0; if you want to run a hops factory, you change the setting to 1 or more.
Understanding the data collection and broadcasting sequence
The big3d agents collect and broadcast information on demand. The principal 3-DNS Controller in the sync group issues a data collection request to all big3d agents running in the network. In turn, the big3d agents collect the requested data using the factories, and then broadcast that data to all 3-DNS Controllers running in the network, including the principal controller that issued the request.
Important notes about tracking LDNS probe states
The 3-DNS Controller tracks the state of path data collection for each LDNS that has ever requested a name resolution from the controller. Table 2.1 shows the six states that can be assigned to an LDNS. Note that you can view the state of LDNS servers in the Local DNS Statistics page in the Configuration utility.
Evaluating big3d agent configuration trade-offs
You must run a big3d agent on each BIG-IP and 3-DNS Controller. If you are using advanced load balancing modes, you must have a big3d agent running on at least one controller in each data center to gather the necessary path metrics.
The load on the big3d agents depends on two factors: the time-to-live (TTL) settings that you assign to the different types of data the agents collect, and the number of factories that each agent runs. The shorter the TTLs, the more frequently the agent needs to refresh the data. While short TTLs guarantee that you always have valid data readily available for load balancing, they also increase the frequency of data collection. The more factories a big3d agent runs, the more metrics it can refresh at one time, and the more quickly it can refresh data for the 3-DNS Controller.
Another factor that can affect data collection is the number of client LDNS servers that make name resolution requests. The more LDNS servers that make resolution requests, the more paths that the big3d agent has to collect. While round trip time for a given path may vary constantly due to current network load, the number of hops along a network path between a data center and a specific LDNS does not often change. Consequently, you may want to set short TTL settings for round trip time data so that it refreshes more often, but set high TTL settings for hops data because it does not need to be refreshed often.
Setting up SNMP probing for hosts
The host probing feature uses SNMP conversations to collect performance data for the host. The 3-DNS Controller uses this performance data for advanced load balancing modes such as Packet Rate and Quality of Service. The big3d agent uses a special SNMP factory to collect metrics from host servers. The SNMP factory establishes a conversation with an SNMP agent running on a given host server. From the SNMP conversation, the factory determines the following types of information about the host:
- Memory utilization
- CPU utilization
- Disk space utilization
- Packet rate
The Configuration utility displays the host metrics in the Host statistics screen. The 3-DNS Controller bases the advanced load balancing decisions on the packet rate metrics, but the Host screen displays the other metrics as well, for your convenience.
Configuration issues
The SNMP probing feature requires that each host run an SNMP agent, and that there is open network communication between the hosts and the big3d agents in the data centers. Certain firewall configurations block SNMP communications, and you may need to verify that the firewalls in your network allow SNMP traffic to pass through. The 3-DNS Controller supports the following common SNMP agents for host probing:
- Generic
A generic SNMP agent is an SNMP agent that provides OIDS as specified in the RFC1213 document. - UCD SNMPD
This free SNMP agent is provided by the University of California at Davis. It is available on the web at http://ucd-snmp.ucdavis.edu, or you can download the ucd-snmp.tar.gz file from ftp://ucd-snmp.ucdavis.edu. - Solstice Enterprise
This SNMP agent is a product of Sun Microsystems. - Windows NT 4.0 SNMP
This SNMP matrix agent is a product of Microsoft and is distributed with the Microsoft Windows NT 4.0 server. - Cisco LDV2
This SNMP agent is a product of Cisco and is distributed with the Cisco LocalDirector, version 2.X. - Cisco LDV3
This SNMP agent is a product of Cisco and is distributed with the Cisco LocalDirector, version 3.X.In addition to properly configuring these agents on the hosts themselves, you need to specify SNMP host probing settings in two places in the 3-DNS Controller configuration. First, when you define a BIG-IP Controller or 3-DNS Controller server, you set the big3d agent to run at least one SNMP factory. Second, when you define the host servers, you configure specific SNMP agent settings for each host. For example, you need to specify the type of agent running on the host as well as the community string that allows access to the SNMP agent.
Planning sync groups
A sync group is a group of 3-DNS Controllers that share information. In a sync group, a principal 3-DNS Controller issues requests to the big3d agents to gather metrics data. Both the principal controller and the receiver 3-DNS Controllers in the group receive broadcasts of metrics data from the big3d agents. All controllers in the group also receive broadcasts of updated configuration settings from the 3-DNS Controller that has the latest configuration changes.
When you define the sync group, select 3-DNS Controllers from the list of servers you have already defined. The sync group lists the controllers in the order in which you selected them. The first controller in the list is the principal 3-DNS Controller. The remaining controllers in the list are receiver 3-DNS Controllers. If the principal controller becomes disabled, the next controller in the list becomes the principal 3-DNS Controller until the original principal controller comes back online.
Understanding how sync groups work
The sync group feature synchronizes individual configuration files, such as wideip.conf and other files that store system settings. You have the option of adding files to the synchronization list.
The controllers in a sync group operate as peer servers. At set intervals, the sync daemon compares the timestamps of the configuration files earmarked for synchronization on all of the controllers. If the timestamp on a specific file differs between controllers, the controller with the latest file broadcasts the file to all of the other controllers in the group.
Setting up communications between 3-DNS Controllers, BIG-IP Controllers, and big3d agents
There are three different communication issues that you need to resolve when you set up communication between controllers running in your network:
- 3-DNS Controllers communicating with other 3-DNS Controllers
To allow 3-DNS Controllers to communicate with each other, you must set up ssh and scp tools for crypto controllers (those which use ssh and scp) that communicate with other crypto controllers, and you must set up rsh and rcp tools for controllers that communicate with non-crypto controllers (those which do not use ssh and scp). - 3-DNS Controllers communicating with BIG-IP Controllers
To allow 3-DNS Controllers to communicate with BIG-IP Controllers, you address the same ssh and rsh issues. Crypto controllers communicating with other crypto controllers can use ssh and scp, but controllers communicating with non-crypto controllers require rsh and rcp. - 3-DNS Controllers communicating with big3d agents
To allow communications between big3d agents and the 3-DNS Controller, you need to configure iQuery ports on both the 3-DNS Controllers and the BIG-IP Controllers that run the big3d agent.
Note: Enabling rsh and rcp does not prevent crypto 3-DNS Controllers from using encryption when they communicate with other crypto 3-DNS Controllers.
Figure 2.1 shows the ports necessary for administrative communication between individual 3-DNS Controllers, and also between 3-DNS Controllers and administrative workstations.
Figure 2.1 Administrative communications
Figure 2.2 shows the ports necessary for iQuery communication between 3-DNS Controllers and big3d agents that run on 3-DNS or BIG-IP Controllers.
Figure 2.2 iQuery communication
Figure 2.3 shows the ports necessary for path probing between 3-DNS Controllers and LDNS servers.
Figure 2.3 Path probe communications
Setting up communication between 3-DNS Controllers
The 3-DNS Controllers need to communicate with each other in order to synchronize configuration and performance data. If you use exclusively crypto 3-DNS Controllers (those which use ssh and scp), or exclusively non-crypto 3-DNS Controllers (those which do not use ssh and scp), the communication tools set up by the First-Time Boot utility are all you need. Crypto controllers all use ssh and scp, and non-crypto controllers all use rsh and rcp.
If you work in a mixed environment where some 3-DNS Controllers are crypto, and other 3-DNS Controllers are non-crypto, you need to enable the rsh and rcp tools on the crypto 3-DNS Controllers. Though the rsh and rcp tools come pre-installed on the crypto 3-DNS Controllers, you must explicitly enable these tools on the crypto 3-DNS Controllers. You can easily do this by running the rsetup script or the config_rshd script from the command line, or you can enable the tools when you run the First-Time Boot utility.
Table 2.2 shows the ports and protocols that 3-DNS Controllers use to communicate with each other.
Setting up communication between 3-DNS Controllers and BIG-IP Controllers
In order to copy big3d agents from the 3-DNS Controllers to the BIG-IP Controllers, the 3-DNS Controllers need to communicate with BIG-IP Controllers. If you use exclusively crypto 3-DNS Controllers and crypto BIG-IP Controllers, or exclusively non-crypto 3-DNS Controllers and non-crypto BIG-IP Controllers, the communication tools set up by the First-Time Boot utility are all you need. Crypto controllers all use ssh and scp, and non-crypto controllers all use rsh and rcp.
However, if you work in a mixed environment where some controllers are crypto, and other controllers are non-crypto, you need to enable the rsh and rcp tools on the crypto controllers. These tools come pre-installed on all crypto 3-DNS and BIG-IP Controllers, but you must explicitly enable them as described following.
To enable the rlogin tools on a BIG-IP Controller
From the command line, run the rsetup script.
Note: You can disable rsh and rcp access at any time by changing the bigip.open_rsh_ports system control variable to 0 in /etc/rc.sysctl.
Table 2.3 shows the ports and protocols that 3-DNS Controllers use to communicate with BIG-IP Controllers. For more information about using rsh and rcp tools on the BIG-IP Controller, refer to the BIG-IP Controller Administrator Guide.
Setting up iQuery communications for the big3d agent
The iQuery protocol can use one of two ports to communicate between the big3d agents and the 3-DNS Controllers. The ports used by iQuery traffic change, depending on whether the traffic is inbound from the big3d agent or outbound from the 3-DNS Controller.
Table 2.4 shows the port numbers and corresponding protocols used for iQuery traffic.
Note that if you run big3d agents in a mixed crypto/non-crypto environment, the crypto controllers automatically turn off Blowfish encryption when communicating with non-crypto big3d agents. When communicating with crypto big3d agents, however, crypto 3-DNS Controllers always use Blowfish encryption by default, although you can manually disable it if you prefer.
Allowing iQuery communications to pass through firewalls
The payload information of an iQuery packet contains information that potentially requires translation when there is a firewall in the path between the big3d agent and the 3-DNS Controller. Only packet headers are translated by the firewall, payloads are not.
The iQuery translation option resolves this issue. With iQuery translation turned on, the iQuery packet stores the original IP address in the packet payload itself. When the packet passes through a firewall, the firewall translates the IP address in the packet header normally, but the IP address within the packet payload is preserved. The 3-DNS Controller reads the IP address out of the packet payload, rather than out of the packet header.
In the example configuration shown in Figure 2.4 , a firewall separates the path between a BIG-IP Controller running a big3d agent and the 3-DNS Controller. The packet addresses are translated at the firewall. However, addresses within the iQuery payload are not translated, and they arrive at the BIG-IP Controller in their original states.
Figure 2.4 Translating packet address through the firewall
Communications between 3-DNS Controllers and other machines in the network
The following tables show the other ports and protocols that 3-DNS Controllers use for communication. Table 2.5 shows the ports that 3-DNS Controllers use for remote administrative connections to the 3-DNS web server.
Table 2.6 shows the ports on which the 3-DNS Controller receives and responds to DNS resolution requests issued by LDNS servers.
Table 2.7 shows the ports that the big3d agent uses when collecting path data for LDNS servers.
The big3d agent can run on either a 3-DNS Controller or a BIG-IP Controller. If you run a big3d agent on a BIG-IP Controller and you set the SNMP probing factory count to 1 or higher, the big3d agent automatically opens UDP ports to allow for SNMP communications. If you do not want to open UDP ports for this purpose, you need to set the SNMP factory count to 0.
Planning issues for the load balancing configuration
The final phase of installing 3-DNS Controllers is setting up the load balancing configuration. Load balancing configurations are based on pools of virtual servers. When the 3-DNS Controller receives a connection request, it uses a load balancing mode to determine which virtual server in a given pool should receive the connection. The virtual servers in the pool can be the virtual servers managed by BIG-IP Controllers, or virtual servers managed by a generic host server, or they can be individual host servers themselves. Note that the 3-DNS Controller continuously verifies which virtual servers in the pool are currently available to accept load balanced connections.
Simple configurations typically use a single pool of virtual servers and a load balancing mode, such as Round Robin or Hops, that does not require significant additional configuration steps. More advanced load balancing configurations can use multiple pools, customizable load balancing modes, and other advanced traffic control features, such as topology-based access control and production rules. If you plan on implementing a more complex configuration, you may want to refer to Chapter 6 for additional details about advanced load balancing features.
Understanding the wide IP key
The wide IP key is the same address as the domain name. The wide IP key binds the information from DNS to the 3-DNS Controller, and indicates to DNS that the 3-DNS Controller (within the named process) should attempt to handle requests to this domain name. This allows the 3-DNS Controller to resolve the request by making a decision based upon its metric database and returning a better answer. Each wide IP definition must have its own unique address.
The wide IP key is sometimes referred to as the fallback address. When the preferred, alternate, and fallback load balancing modes (as specified in the wide IP definition) fail, the 3-DNS Controller instructs the DNS to issue its original answer. When this happens, the wide IP key is called the fallback address.
Choosing a load balancing mode
The 3-DNS Controller offers several different load balancing modes. Basic, static modes base load balancing on a pre-defined distribution pattern. More advanced, dynamic modes base load balancing on current network information such as the round trip time between a requesting client and a web server.
Basic load balancing
Basic load balancing modes distribute connections based on pre-defined distribution patterns, and do not take current server or network performance into account. The 3-DNS Controller supports the following basic load balancing modes:
- Static Persist
Static Persist mode provides static persistence of LDNS servers to virtual servers; it consistently maps an LDNS IP address to the same available virtual server. This mode guarantees that certain transactions will be routed through a single transaction manager (for example, a BIG-IP Controller or other server array controller); this is beneficial for transaction-oriented traffic such as e-commerce shopping carts or online trading. - Round Robin
Round Robin mode distributes connections evenly across all virtual servers, passing each new connection to the next virtual server in line. - Ratio
Ratio mode distributes connections across virtual servers in proportion to a user-defined ratio. The distribution of replies is weighted Round Robin. For example, if one virtual server runs on a new, high-speed machine, and two other virtual servers run on older machines, you could set the ratio so that the high-speed virtual server receives twice as many connections as either of the two older virtual servers. - Global Availability
Global Availability mode distributes connections to a list of virtual servers, always sending a connection to the first available virtual server on the list. - Random
Random mode distributes connections in a random pattern. - Topology
Topology allows you to direct or restrict traffic flow by entering network information into the configuration file. This allows you to develop proximity-based mapping. For example, customers in a particular geographic region can be sent to virtual servers within that same region. The 3-DNS Controller determines the proximity of virtual servers by comparing the client's LDNS IP address to the IP address of the available virtual servers.
Advanced load balancing
Advanced load balancing bases connection distribution on current server and network performance information gathered by the big3d agent. The different dynamic load balancing modes incorporate different performance factors.
- Quality of Service
Quality of Service (QOS) mode takes a variety of performance factors into account. You can configure the QOS mode to rate different performance factors higher or lower than others, or you can configure the QOS mode to treat all factors as being equally important. The quality of the service equation calculates a performance score based on the following factors:- Round trip time between the virtual server and the client LDNS
- Number of intermediate systems transitions between the virtual server and the client LDNS
- Number of packets currently being processed
- Percentage of packets completed
- Topological distribution
- Number of nodes currently up in the virtual server
- Round Trip Times
Round Trip Times mode sends each new connection to the virtual server that demonstrates the best round trip time between the virtual server and the client LDNS. - Hops
Hops mode sends each new connection to the virtual server that has the fewest number of intermediate systems transitions between the virtual server and the client LDNS. - Packet Rate
Packet Rate mode sends each new connection to the virtual server that has the least amount of network traffic. - Completion Rate
Completion Rate mode sends each new connection to the virtual server that has the fewest number of dropped packets. - Least Connections
Least Connections mode sends each new connection to the virtual server that currently hosts the fewest current connections. Note that you can use Least Connections mode only to load balance virtual servers managed by BIG-IP Controllers. - VS Capacity mode
VS Capacity mode sends each new connection to the virtual server which has the most nodes up.
Ensuring availability for e-commerce, FTP, and other services that use multiple ports
Before the 3-DNS Controller selects a virtual server to receive a connection, it verifies that the virtual server is up and available. Certain types of network traffic, such as FTP traffic or e-commerce traffic, require that more than one port be available in order for the client's requests to be properly handled. For example, FTP servers use both ports 20 and 21, while e-commerce sites typically require that both ports 80 and 443 are available to handle HTTP and SSL traffic.
When you set up a load balancing configuration, you can define a list of ports that are verified on each virtual server before the virtual server is made available to receive load balanced connections.
Using the LDNS round robin wide IP attribute
LDNS round robin is an attribute that you can use in conjunction with any load balancing mode. The LDNS round robin attribute allows the 3-DNS Controller to return a list of available virtual servers, instead of a single virtual server. Certain browsers keep the answer returned by DNS servers. By enabling this attribute, the 3-DNS Controller returns a maximum of 16 virtual servers as the answer to a DNS resolution request. This provides browsers with alternate answers when a virtual server becomes unavailable.
Using advanced traffic control features
The 3-DNS Controller offers three advanced features that you can configure to further control the distribution and flow of network traffic.
- Topology-based access control
With topology-based access control, you can restrict clients from connecting to virtual servers in specific data centers. - IP packet filtering
You can use IP packet filtering on the 3-DNS Controller to reject connection requests from certain source IP addresses. - Production rules
Use the production rules feature to change the load balancing configuration, as well as other system settings, based on dynamic factors such as current network performance, and time of day.
Configuring topology-based access control
Topology-based access control limits users to a subset of available servers based on their proximity to the servers. You can use topology-based access control to force European clients to connect only to servers also in Europe, rather than connecting to servers in South America.
The 3-DNS Controller uses topology-based access control in conjunction with load balancing modes. For example, even though topology-based access control may force a European client to connect to a server in Europe, the 3-DNS Controller still uses the load balancing modes specified for the preferred, alternate, and fallback methods to choose the best European server that should receive the connection.
For details about working with topology-based features and creating the necessary topology records, see Chapter 6 , Configuring Specialized Load Balancing .
Setting up IP packet filtering
You can use the IP packet filtering feature to reject unwanted connection requests that may bog down your site and compromise performance. For example, if you detect an attack on your site, such as when your system is suddenly flooded with DNS requests from a single client, you can block that client's connection requests by defining an IP filter that rejects all packets containing that client's source IP address.
Note that the IP packet filtering supported on the 3-DNS Controller is based on BSD IP packet filtering. You can configure IP filters manually, but we recommend that you define IP filters in the Configuration utility, which greatly simplifies the process. To define a new IP filter in the Configuration utility, you specify one of three filter criteria:
- Source IP address only
- Destination IP address only
- Combination of source and destination IP address
Note that you can use IP address ranges when you define IP filters. You can find details about how to configure IP filters in Chapter 7 , Monitoring and Administration .
Defining production rules
Production rules are a policy-based management feature that you can use to dynamically change the load balancing configuration and the system settings based on specific triggers, such as the time of day, or the current network traffic flow. You can set up standard production rules using the Configuration utility, or you can define custom production rules using the production rules scripting language.
Refer to Chapter 7 , Monitoring and Administration , for information about setting up production rules.
Planning DNS zone file management
An important part of installing 3-DNS Controllers in your network is planning which servers should be master for a given DNS zone. When you initially set up a 3-DNS Controller in your network, you have two basic options for setting up DNS zone masters:
- You can use the 3-DNS Controller as the master DNS server for your domain.
- You can use an existing master DNS for your domain, and use the 3-DNS Controller only as the master DNS for your wide IP sub-domains.
The 3-DNS Controller must always be the DNS master for your wide IP sub-domains, regardless of which server is the master DNS in your network. We strongly recommend that you set up the 3-DNS Controller to run as a master DNS that manages your domain.
One major benefit of setting up the 3-DNS Controller to be the master DNS for your domain is that you can easily manage DNS zone files using NameSurfer, a browser-based, third-party application included on the 3-DNS Controller. You can also easily transfer your existing zone files to the 3-DNS Controller after the initial installation.
When you define wide IPs in the Configuration utility, the NameSurfer application automatically makes the appropriate additions to the zone files, and broadcasts the new zone files to the other DNS servers in your network. If you configure wide IPs manually, however, you need to make the corresponding zone file changes manually.
If you use the advanced synchronization features of the 3-DNS Controller, we strongly recommend that you configure each 3-DNS Controller to run as a master DNS. This effectively creates a group of peer/master DNS servers. This type of configuration offers the following advantages:
- You can change zone files on any one of the 3-DNS Controllers in the network and have those changes automatically broadcast to all of the other controllers in the network.
- Each 3-DNS Controller has the most up-to-date zone files, providing you one or more layers of redundancy.
- The NameSurfer application automatically controls the addition, configuration, and deletion of zone files.
Replacing your DNS servers with 3-DNS Controllers as master DNS servers for your domain
Figure 2.5 shows an implementation where both 3-DNS Controllers in the network act as master DNS servers for the domain, domain.com.
Figure 2.5 Using 3-DNS Controllers as DNS masters for your domain
Converting existing BIND files during an initial installation
After you initially install the 3-DNS Controller, you need to transfer existing BIND files, and then convert them to the NameSurfer format.
One option for converting your existing BIND files is to skip the NameSurfer configuration when you run the First-Time Boot utility. You transfer the zone files and named.conf file after the system has rebooted, and then run the config_namesurfer script that configures, converts, and starts the NameSurfer application. For more information, see Appendix C, BIND 8 Information .
The second option for importing your existing BIND files is to zone transfer from your current name server to NameSurfer. After configuring NameSurfer during the First-Time Boot utility and connecting to the Configuration utility, use the Copy from other name server option in the NameSurfer UI. For more information, refer to the NameSurfer documentation available from the splash screen in the Configuration utility.
Running 3-DNS Controllers as DNS masters for only wide IP sub-domains
At a minimum, all 3-DNS Controllers must be the DNS masters for the zones associated with wide IP definitions. When you set up a configuration where the 3-DNS Controllers are DNS masters for only those sub-domains, you need to make a few changes to the zone files on the master DNS for your domain after you configure the 3-DNS Controller.
Figure 2.6 shows an example where both 3-DNS Controllers are DNS masters for the wide IP sub-domains, and a generic name server in the Tokyo data center is the master DNS server for the domain, domain.com.
Figure 2.6 The 3-DNS Controllers managing sub-domains
Note that you should still set NameSurfer to be the master during the First-Time Boot utility for initial installations, or during the NameSurfer configuration script for upgrade installations. Remember that NameSurfer is the master for the zone files on the 3-DNS Controller, but in this configuration the zone files contain only those records associated with wide IPs configured on the 3-DNS Controller. When you configure wide IPs in the Configuration utility, the NameSurfer application automatically updates the corresponding sub-domain zones and broadcasts them to the other DNS servers in the network. For configurations where synchronization is enabled, changes to any NameSurfer files are automatically updated to the other 3-DNS Controllers.
