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.
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:
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.
When you configure the 3DNS Controller, you have two configuration tool options:
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.
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.
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:
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.
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).
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.
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 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.
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.
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.
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:
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.
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:
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.
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.
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:
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.
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.
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:
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.
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.
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.
|Needs Probe||The big3d agent has never collected data for the LDNS, or the data has expired.|
|Idle||The big3d agent successfully collected data for the LDNS, and is waiting for the next collection request.|
|In Probe||The big3d agent is currently collecting data for the LDNS.|
|Needs Discovery||The big3d agent failed to collect data for the LDNS using its standard protocols and ports, and now needs to run the LDNS through a discovery factory.|
|In Discovery||The big3d agent is currently running the LDNS through a discovery factory to look for an alternate available port.|
|Suspended||The big3d agent failed to discover a port open for data collection, and the LDNS is no longer eligible for data collection requests.|
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.
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:
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.
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:
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.
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.
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.
There are three different communication issues that you need to resolve when you set up communication between controllers running in your network:
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.
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.
|US 3DNS Controller||US 3DNS Controller||tcp||<1023||22||SSH/SCP|
|US 3DNS Controller||International
|US 3DNS Controller||tcp||>1024||514||RSH/RCP|
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.
From the command line, run the rsetup script.
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.
|US 3DNS Controller||US BIG/ip Controller||tcp||<1023||22||SSH/SCP|
|US 3DNS Controller||International
|US 3DNS Controller||N/A||N/A||N/A||N/A|
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.
|From||To||Protocol||From Port||To Port||Purpose|
|3DNS Controller||big3d agent||udp||245, 4354||245||Standard iQuery port for outbound traffic|
|3DNS Controller||big3d agent||udp||4353 or 4354||4353||Alternate iQuery port for outbound traffic (open this port only when the use_alternate_iq global variable is set to yes)|
|big3d agent||3DNS Controller||udp||245 or 4353||4354||Ephemeral port used for inbound iQuery traffic|
|big3d agent||3DNS Controller||udp||245||245||Single port used for multiplexed inbound iQuery traffic (open this port only when the multiplex_iq global variable is set to yes)|
|big3d agent||3DNS Controller||udp||4353||4353||Single port used for multiplexed inbound iQuery traffic (open this port only when both the use_alternate_iq and the multiplex_iq global variables are set to yes)|
|big3d agent||host SNMP agent||udp||>1024||161||Ephemeral ports used to make SNMP queries for host statistics|
|host SNMP agent||big3d agent||udp||161||>1024||Ephemeral ports used to receive host statistics via SNMP|
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.
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.
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.
|Remote Workstation||US 3DNS Controller||tcp||443||Connection to secure web server|
|Remote Workstation||Int'l 3DNS Controller||tcp||80||Connection to standard 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.
|LDNS||3DNS Controller||udp||53 or >1024||53||DNS resolution requests|
|3DNS Controller||LDNS||udp||53||53 or >1024||DNS resolution answers|
Table 2.7 shows the ports that the big3d agent uses when collecting path data for LDNS servers.
|big3d agent||LDNS||icmp||N/A||N/A||Probing using ICMP pings|
|big3d agent||LDNS||tcp||2000-12000||53||Probing using TCP (CISCO routers should "allow establish")|
|LDNS||big3d agent||tcp||53||2000-12000||Probing using TCP (CISCO routers should "allow establish")|
|big3d agent||LDNS||udp||2000-12000||33434||UDP probing and traceroute|
|LDNS||big3d agent||icmp||N/A||N/A||Replies from ICMP, UDP pings, or traceroute probes|
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.
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.
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.
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:
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.
|Load Balancing mode||Pool load balancing||Preferred||Alternate||Fallback|
|Quality of Service||x||x|
|Return to DNS||x*||x||x|
|Round trip time||x||x|
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:
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 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 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 sends connections to virtual servers in a random pattern.
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 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.
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.
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.
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 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.
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 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 (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.
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 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:
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.
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.
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.
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 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.
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:
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.
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:
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:
Figure 2.8 shows an implementation where both 3DNS Controllers in the network act as master DNS servers for the domain, domain.com.
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.
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.
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.