Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 2.0.1 PTF-01, 2.0.1, 2.0.0
2
Preparing for Installation
- Reviewing the installation tasks
- Planning issues for the hardware setup
- Planning issues for the network setup
- Planning issues for the load balancing configuration
- Using advanced traffic control features
- Planning DNS zone file management
Reviewing the installation tasks
This chapter covers the planning issues that you need to address before you install and set up the 3DNS Controller. It explains the three different phases on an installation, along with load balancing configuration options and important DNS planning issues. If you are planning to do a simple configuration, briefly review the hardware setup and network setup requirements, along with the load balancing options. If you are planning 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 3DNS Controller that runs as a master DNS server, as well as integrating 3DNS Controllers into networks that have an existing master DNS server.
Understanding the installation phases
You can set up a basic 3DNS Controller configuration, or an advanced 3DNS 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 3DNS web server which hosts the F5 Configuration utility. You need to do the hardware setup on all 3DNS Controllers in your network. - Network setup
During the network setup phase, you define the network layout of the servers that the 3DNS 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 3DNS Controllers that share system configurations. Note that at this point, you can define the configuration on the 3DNS 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 3DNS 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 3DNS Controllers in your network, or upgrading existing 3DNS Controllers in your network. Issues relating to DNS zone file management are covered in detail in Planning DNS zone file management , on page 2-38.
Working with configuration tools
When you configure the 3DNS 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 3DNS Controller in the network, the sync feature automatically broadcasts the changes to all other 3DNS 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 do the configuration manually using the Edit 3DNS Configuration command on the 3DNS 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 3DNS Controller in the network.
If you have worked with previous versions of the 3DNS Controller, you can view statement syntax in the Configuration utility. As you define various aspects of the product, use the View Conf button to display the existing configuration.
Warning: We do not recommend that you switch between using the Configuration utility, and manually configuring the 3DNS Controller. If you manually configure a 3DNS 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 3DNS Controller hardware to the network, and you run the First-Time Boot utility on each of the 3DNS 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 3DNS 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 3DNS Controllers and BIG/ip Controllers in the network configuration
- Authentication certificate settings (company name, address, etc.) for 3DNS web servers that run on US 3DNS 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 3DNS 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 3DNS 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 3DNS Controller treats this as system failure and initiates a fail-over.
- If the 3DNS 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 3DNS 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 3DNS 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 a 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 F5 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 are planning on transferring existing BIND files from a master DNS server to the 3DNS 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-38.
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 3DNS 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 3DNS Controllers, BIG/ip Controllers, and host machines that you use for load balancing. - Sync group
A sync group defines the group of 3DNS Controllers that shares configuration settings and path data.
Note: During the network setup phase of configuration, we recommend that you connect to the 3DNS Controller from a remote workstation where you can do the remaining configuration tasks using the web- based F5 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 (3DNS 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 3DNS 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 and Setting up communications between 3DNS Controllers, BIG/ip Controllers, and big3d agents , 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 3DNS Controller's time setting is allowed to be out of sync with another 3DNS Controller's time setting. If the difference between the times on the controllers is higher 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 3DNS 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 3DNS Controllers is important because a 3DNS Controller compares time stamps on files when deciding whether to synchronize files with other 3DNS Controllers in the sync group.
Setting up data collection with the big3d agent
The big3d agent collects performance information on behalf of the 3DNS Controller. The big3d agent runs on both 3DNS 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 3DNS 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 3DNS 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 3DNS 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 3DNS Controllers in the network, you need to configure the appropriate ports and tools to allow communication between the BIG/ip Controllers and 3DNS Controllers in the network. These planning issues are discussed in Setting up communications between 3DNS Controllers, BIG/ip Controllers, and big3d agents , on page 2-16.
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 3DNS 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 3DNS 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 local DNS server making the resolution request. Round trip time is used in determining the best virtual server when utilizing 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 local DNS server making the resolution request. Packet completion is used in determining the best virtual server when utilizing the Completion Rate or the Quality of Service modes. - Hops along the network path
The big3d agent calculates the number of intermediate systems between the data center and the client's local DNS server. Hops are used in determining the best virtual server when utilizing the Hops or the Quality of Service 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 utilizing the Packet Rate or the Quality of Service 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 utilizing the Least Connections 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 3DNS 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 3DNS 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 four factory types:
- Probing factory
A probing factory collects several types of information using ICMP, TCP, or UDP. 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 hops 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 3DNS 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 3DNS Controller in the network runs a big3d agent using five prober factories, no SNMP factories, one discovery factory, no hops factories, and the two default factories. In the BIG/ip Controller or 3DNS 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 3DNS 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 its factories, and then broadcasts that data to all 3DNS Controllers running in the network, including the principal controller that issued the request.
Important notes about tracking LDNS probe states
The 3DNS 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 statistics area of the F5 Configuration utility.
Evaluating big3d agent configuration trade-offs
You must run a big3d agent on each BIG/ip and 3DNS Controller. If you are using dynamic load balancing modes, you must have a big3d agent running on at least one controller in each data center in order 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 agents 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 3DNS 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 ttls for round trip time data so that it refreshes more often, but set high ttls 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 3DNS Control uses the performance data for dynamic load balancing modes such as Packet Rate and Quality of Service. The big3d agent actually 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
- Bytes in/out
- Packet rate
The Configuration utility displays the host metrics in the Host statistics screen. The 3DNS Controller bases the dynamic load balancing decisions on the packet rate metrics, but the Host screen displays all of the metrics 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 3DNS Controller supports the following common SNMP agents for host probing:
- Generic
The 3DNS Controller can work with a generic SNMP agent running on a host. - UCD SNMPD
The UCD SNMPD is a free SNMP agent provided by the University of California at Davis. It is freely available on the web at http://ucd-snmp.ucdavis.edu, ftp://ucd-snmp.ucdomain.edu/ucd-snmp.tar.gz. - Solstice Enterprise
The Solstice Enterprise agent is a product of SunSoft. - Windows NT 4.0 SNMP
The Windows NT 4.0 SNMP matrix agent is distributed with the Microsoft Windows NT 4.0 server.In addition to properly configuring these agents on the hosts themselves, you need to specify SNMP host probing settings in two places in the 3DNS Controller configuration. First, when you define a BIG/ip Controller or 3DNS 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 3DNS Controllers that share information. In a sync group, a principal 3DNS Controller issues requests to the big3d agents to gather metrics data. Both the principal controller and the receiver 3DNS 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 3DNS Controller that has the latest configuration changes.
When you define the sync group, select 3DNS 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 3DNS Controller. The remaining controllers in the list are receiver 3DNS Controllers. If the principal controller goes down, the next controller in the list becomes the principal 3DNS 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 actually operate as peer servers. At set intervals, the sync daemon compares the timestamps of the config files earmarked for synchronization on all of the controllers. If the timestamps on a specific file differ between controllers, the controller with the latest file broadcasts the file to all of the other controllers in the group.
Setting up communications between 3DNS 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:
- 3DNS Controllers communicating with other 3DNS Controllers
To allow 3DNS Controllers to communicate with each other, you need to set up ssh and scp tools for controllers that communicate with other controllers within the US, and rsh and rcp tools for controllers that communicate with other controllers outside the US. - 3DNS Controllers communicating with BIG/ip Controllers
To allow 3DNS Controllers to communicate with BIG/ip Controllers, you address the same ssh and rsh issues. Controllers communicating within the US can use ssh and scp, but controllers communicating outside the US require rsh and rcp. - 3DNS Controllers communicating with big3d agents
To allow communications between big3d agents and the 3DNS Controller, you need to configure iQuery ports on both the 3DNS Controllers and the BIG/ip Controllers that run the big3d agent.
Note: Enabling rsh and rcp does not prevent US 3DNS Controllers from using encryption when they communicate with other US 3DNS Controllers.
Figure 2.1 illustrates the communication links between 3DNS Controllers and other machines in your network. The following sections describe in detail which ports and protocols are used for specific communication links.
Figure 2.1 Communication ports
Setting up communication between 3DNS Controllers
3DNS Controllers need to communicate with each other in order to synchronize configuration and performance data. If you use 3DNS Controllers exclusively inside the US, or exclusively outside the US, the communication tools set up by the First-Time Boot utility are all you need. US controllers all use ssh and scp, and international controllers all use rsh and rcp.
If you work in a mixed environment where some 3DNS Controllers are in the US and other 3DNS Controllers are outside the US, you need to enable the rsh and rcp tools on the US 3DNS Controllers. These tools come pre-installed on the US 3DNS Controllers, but you must explicitly enable the rsh and rcp tools on the US 3DNS Controllers. You can easily enable these tools by running the rsetup script from the command line, by running config-rsd script, or when you run the First-Time Boot utility.
Table 2.2 shows the ports and protocols that 3DNS Controllers use to communicate with each other.
Setting up communication between 3DNS Controllers and BIG/ip Controllers
3DNS Controllers need to communicate with BIG/ip Controllers in order to copy big3d agents from the 3DNS Controllers to the BIG/ip Controllers. If you use 3DNS Controllers and BIG/ip Controllers exclusively inside the US, or exclusively outside the US, the communication tools set up by the First-Time Boot utility are all you need. US controllers always use ssh and scp, and international controllers always use rsh and rcp.
However, if you work in a mixed environment where some controllers are in the US and other controllers are outside the US, you need to enable the rsh and rcp tools on the US controllers. These tools come pre-installed on both US 3DNS Controllers and US BIG/ip Controllers, but you must explicitly enable them as described below.
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 the 3DNS Controller uses 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 3DNS Controllers. The ports used by iQuery traffic change, depending on whether the traffic is inbound from the big3d agent or outbound from the 3DNS 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 US/international environment, the US controllers automatically turn off Blowfish encryption when communicating with international big3d agents. When communicating with US big3d agents, however, US 3DNS Controllers always use Blowfish encryption by default, though 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 3DNS 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 3DNS 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.2 , a firewall separates the path between a BIG/ip Controller running a big3d agent and the 3DNS 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.2 Translating packet address the firewall
Communications between 3DNS Controllers and other machines in the network
The following tables show the other ports and protocols that 3DNS Controller uses for communication. Table 2.5 shows the ports that the 3DNS Controller uses for remote administrative connections to the 3DNS web server.
Table 2.6 shows the ports on which the 3DNS Controller receives and responds to DNS resolution requests issued by local DNS 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 3DNS 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 3DNS Controllers is setting up the load balancing configuration. Load balancing configurations are based on pools of virtual servers. When the 3DNS 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 3DNS 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 that does not require significant additional configuration steps, such as Round Robin or Hops. 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 wideip key
The wideip key is the same address as the domain name. The wide IP key binds the information from DNS to the 3DNS Controller and indicates to DNS that the 3DNS Controller (within the named process) should attempt to handle requests to this domain name. This allows the 3DNS 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 wideip definition) fail, the 3DNS 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 3DNS Controller performs load balancing by selecting one server from a pool of servers available for load balancing. When the 3DNS Controller receives a name resolution request, the controller uses a load balancing mode to select the best available virtual server from the pool. Once the 3DNS Controller selects the virtual server, it constructs the DNS answer, an A record, and sends the answer back to the requesting client's local DNS server.
The 3DNS Controller can choose virtual servers from the pool using either a static load balancing mode, which selects a server based on a pre-defined pattern, or a dynamic load balancing mode, which selects a server based on current performance.
The 3DNS Controller uses load balancing modes in two places:
- Load balancing within a pool
Within each pool, the 3DNS Controller allows you to specify three different load balancing modes that the controller uses in sequential order. The 3DNS Controller first uses the load balancing mode specified as the preferred method. If this load balancing mode fails, the 3DNS Controller then uses the load balancing mode specified as the alternate method. If that load balancing mode fails as well, the 3DNS Controller uses the load balancing mode specified as the fallback method. Only if the fallback method fails does the 3DNS Controller return the client to standard DNS for resolution. - Load balancing among multiple pools
The 3DNS Controller supports multiple pools. Configurations that contain two or more pools use a load balancing mode between the different pools. Once a pool has been selected, the 3DNS Controller uses a load balancing mode to choose a virtual server within the selected pool.Table 2.8 shows a complete list of supported load balancing modes, and where you can use each mode in the 3DNS Controller configuration. Note that the following sections describe how each of these load balancing modes works.
Using static modes
Static load balancing modes distribute connections across the network according to predefined patterns, and take server availability into account. The 3DNS Controller supports the following static load balancing modes:
- Round Robin
- Ratio
- Random
- Global Availability
- Topology
- Null
- Return to DNS
The Null and Return to DNS load balancing modes are special modes that you can use to skip load balancing under certain conditions. The remaining static load balancing modes perform true load balancing as described in the following sections.
Round Robin mode
Round Robin mode distributes connections in a circular and sequential pattern among the virtual servers in a pool. Over time, each virtual server receives an equal number of connections.
Figure 2.3 shows a sample of the connection distribution pattern for Round Robin mode.
Ratio mode
Ratio mode distributes connections among a pool of virtual servers as a weighted Round Robin. For example, you can set up Ratio mode to send twice as many connections to a fast, new server, and only half as many connections to an older, slower server.
This load balancing mode requires that you define a ratio weight for each virtual server in a pool, or for each pool if you are using Ratio mode to do load balancing among multiple pools. The default ratio weight for a server or a pool is set to 1.
Figure 2.4 shows a sample connection distribution for Ratio mode.
Random mode
Random mode sends connections to virtual servers in a random pattern.
Global Availability mode
Global Availability mode uses the virtual servers included in the pool in the order in which they are listed. For each connection request, this mode starts at the top of the list and sends the connection to the first available virtual server in the list. Global Availability mode moves to the next virtual server in the list only when the current virtual server is full or otherwise unavailable. Over time, the first virtual server in the list receives the most connections and the last virtual server in the list receives the least number of connections.
Topology mode
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 servers within that same region. The 3DNS Controller determines the proximity of servers by comparing the client's LDNS IP address to the IP address of the available servers.
This load balancing mode requires you to do some advanced configuration planning, such as gathering the information you need to define the topology records which determine proximity of client LDNS servers to the various virtual servers.
The Topology load balancing mode is different from the topology-based access control feature. Topology-based access control actually prevents clients from connecting to specific virtual servers. You can use the topology-based access control feature in conjunction with the Topology load balancing mode. See Chapter 6 , Configuring Specialized Load Balancing , for detailed information about working with this and other topology features.
Null mode
The Null load balancing mode is a special mode that you can use if you want to skip the current load balancing method, or skip to the next pool in a multiple pool configuration. For example, if you set an alternate method to Null in a pool, the 3DNS Controller skips the alternate method and immediately tries the load balancing mode specified as the fallback method. If the fallback method is set to Null, the 3DNS Controller either uses the next pool, if you have multiple pools, or it returns the connection request to DNS for resolution.
This mode is most useful for multiple pool configurations. For example, you can temporarily remove a specific pool from service by setting each of the methods (preferred, alternate, and fallback) to Null. You could also use the mode to limit each pool to a single load balancing mode. For example, you would set the preferred method in each pool to the desired load balancing mode, and then you would set both the alternate and fallback methods to Null in each pool. If the preferred method failed, the Null mode in both the alternate and fallback methods would force the 3DNS Controller to go to the next pool for a load balancing answer.
Return to DNS mode
The Return to DNS mode is another special load balancing mode that you can use to immediately return connection requests to DNS for resolution. This mode is particularly useful if you want to temporarily remove a pool from service, or if you want to limit a pool in a single pool configuration to only one or two load balancing attempts.
Using dynamic load balancing modes
Dynamic load balancing modes distribute connections to servers that show the best current performance. The performance taken into account depends on the particular dynamic mode you are using.
All dynamic load balancing modes make load balancing decisions based on the metrics collected by the big3d agents running in each data center. The big3d agents collect the information at set intervals that you can define when you set the global ttl variables.
The 3DNS Controller supports the following dynamic load balancing modes:
- Completion Rate
- Least Connections
- Packet Rate
- Round Trip Times (RTT)
- Hops
- Quality of Service
Completion Rate mode
Completion Rate mode selects a virtual server that currently maintains the least number of dropped or timed out packets for transactions between a data center and the client LDNS.
Figure 2.5 shows a sample connection distribution pattern for Completion Rate mode.
Figure 2.5 Completion Rate mode
Least Connections mode
Least Connections mode is also used for load balancing virtual servers managed by BIG/ip Controllers. Least Connections mode simply selects a virtual server on the BIG/ip Controller that currently hosts the fewest connections.
Packet Rate mode
Packet Rate mode selects a virtual server that is currently processing the fewest number of packets per second.
Figure 2.6 shows a sample connection distribution for Packet Rate mode.
Round Trip Times mode
Round Trip Times (RTT) mode selects the virtual server with the fastest measured round trip time between the data center and the client LDNS. This load balancing mode requires that you run one or more big3d agents in each data center to collect the required metrics.
Figure 2.7 shows a sample connection distribution for Round Trip Times mode.
Figure 2.7 Round Trip Times mode
Hops mode
Hops mode is based on the traceroute utility, and it tracks the number of intermediate system transitions between the client LDNS and each data center. Hops mode selects a virtual server in the data center that has the fewest network hops.
Quality of Service mode
Quality of Service mode uses the current performance information, calculates an overall score for each virtual server, and then distributes connections based on each virtual server's score. The performance factors that it takes into account include:
- Round trip time
- Hops
- Completion rate
- Packet rate
- Topology
Quality of Service mode is a customizable load balancing mode. For simple configurations, you can easily use the mode with its default settings where all the factors are weighted equally. For more advanced configurations, you can specify different weights for each performance factor in the equation.
You can also configure the Quality of Service load balancing mode to use the dynamic ratio feature. With the dynamic ratio feature turned on, the Quality of Service mode becomes similar to the Ratio mode where the connections are distributed in proportion to ratio weights assigned to each virtual server. The ratio weights are based on the qos scores; the better the score, the higher percentage of connections the virtual server receives.
For details about customizing Quality of Service mode, see Chapter 6 , Configuring Specialized Load Balancing .
Ensuring availability for e-commerce, FTP, and other services that use multiple ports
Before the 3DNS Controller selects a server to receive a connection, it verifies that the 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 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 3DNS 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 3DNS 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 3DNS Controller offers three advanced features that you can configure to further control the distribution and flow of network traffic:
- Topology-based access control
Topology-based access control allows you to restrict clients from connecting to virtual servers in specific data centers. - IP packet filtering
You can use IP packet filtering on the 3DNS Controller to reject connection requests from certain source IP addresses. - Production rules
The production rules feature allows you to change the load balancing configuration, as well as other system settings, based on dynamic factors such as current network performance, as well as 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 3DNS 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 3DNS 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 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 3DNS Controller is based on BSD IP packet filtering. You can configure IP filters manually, but we recommend that you define IP filters in the F5 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 configuring 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 F5 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 3DNS Controllers in your network is planning which servers should be master for a given DNS zone. When you initially set up a 3DNS Controller in your network, you have two basic options for setting up DNS zone masters:
- You can use the 3DNS Controller as the master DNS server for your domain.
- You can use an existing master DNS for your domain, and use the 3DNS Controller only as the master DNS for your wide IP sub-domains.
- The 3DNS 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 3DNS Controller to run as a master DNS and manage your domain.
One major benefit of setting up the 3DNS 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 3DNS Controller. You can also easily transfer your existing zone files to the 3DNS Controller after the initial installation.
When you define wide IPs in the F5 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 files changes manually.
If you choose to use the advanced synchronization features of 3DNS, we strongly recommend that you configure each 3DNS 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 3DNS Controllers in the network and have those changes automatically broadcast to all of the other controllers in the network.
- Each 3DNS 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 3DNS Controllers as master DNS servers for your domain
Figure 2.8 shows an implementation where both 3DNS Controllers in the network act as master DNS servers for the domain, domain.com.
Figure 2.8 3DNS Controllers as DNS masters for your domain
Converting existing BIND files during an initial installation
After you initially install the 3DNS 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.
Running 3DNS Controllers as DNS masters only for wide IP sub-domains
At a minimum, all 3DNS Controllers must be the DNS masters for the zone files associated with wide IP definitions. When you set up a configuration where the 3DNS Controllers are DNS master only for those sub-domains, you need to make a few changes to the zone files on the master DNS for your domain after the configuring your 3DNS Controller.
Figure 2.9 shows an example where both 3DNS 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.9 3DNS Controllers managing sub-domains
Note that you 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 3DNS Controller, but in this configuration the zone files contain only those records associated with wide IPs configured on the 3DNS Controller. When you configure wide IPs in the F5 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, all changes to any NameSurfer files are automatically updated to the other 3DNS Controllers.
