Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 4.0 PTF-01, 4.0.0
3
The big3d Agent
- Working with the big3d agent
- Installing the big3d agent
- Understanding factories run by big3d agents
- Understanding the data collection and broadcasting sequence
- Setting up communication between 3-DNS Controllers and other F5 servers
Working with the big3d agent
The big3d agent collects performance information on behalf of the 3-DNS Controller. The big3d agent runs on 3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, and GLOBAL-SITE Controllers; the default setting is to run a big3d agent on all of these controllers in the network, but you can turn off the big3d agent on any controller at any time.
Setting up data collection with the big3d agent
Setting up the big3d agents involves the following tasks:
- Installing big3d agents on BIG-IP Controllers and EDGE-FX Caches
Each new version of the 3-DNS Controller software includes the latest version of the big3d agent. You need to distribute that copy of the big3d agent to the BIG-IP Controllers and EDGE-FX Caches in the network. See the release notes provided with the 3-DNS Controller software for information about which BIG-IP Controller and EDGE-FX Cache versions the current big3d agent supports. For details on installing the big3d agent, see Installing the big3d agent, on page 3-3 . - Specifying which factories a specific big3d agent manages
When you define BIG-IP Controllers, EDGE-FX Caches, and 3-DNS Controller servers, you can change the default big3d agent settings on a specific controller. You can change the number of factories the big3d agent runs and turn specific factories on and off. - Setting up communications between big3d agents and controllers
Before the big3d agents can communicate with the 3-DNS Controllers in the network, you need to configure the appropriate ports and tools to allow communication between the devices running the big3d agent and 3-DNS Controllers in the network. These planning issues are discussed in Setting up communication between 3-DNS Controllers and other F5 servers, on page 3-6 .
Collecting path data and server performance metrics
A big3d agent collects the following types of performance information used for load balancing. This information is broadcast to all 3-DNS Controllers in your network.
- Virtual server availability
The big3d agent queries virtual servers to verify whether they are up and available to receive connections. For name resolution, the 3-DNS Controller uses only those virtual servers that are up. - Network path round trip time
The big3d agent calculates the round trip time for the network path between the data center and the client's LDNS server that is making the resolution request. Round trip time is used in determining the best virtual server when using the Round Trip Times or the Quality of Service modes. - Network path packet loss
The big3d agent calculates the packet completion percentage for the network path between the data center and the client's LDNS server that is making the resolution request. Packet completion is used in determining the best virtual server when using the Completion Rate or the Quality of Service modes. - Hops along the network path
The big3d agent calculates the number of intermediate systems transitions (hops) between the data center and the client's LDNS server. Hops are used in determining the best virtual server when using the Hops or the Quality of Service load balancing modes. - Server performance
The big3d agent calculates the packet rate of the BIG-IP Controller or SNMP-enabled hosts. Packet rate is used in determining the best virtual server when using the Packet Rate or the Quality of Service load balancing modes. - Virtual server performance
The big3d agent calculates the number of connections to virtual servers defined on BIG-IP Controllers or SNMP-enabled hosts. The number of connections is used to determine the best virtual server when using the Least Connections load balancing mode.
Installing the big3d agent
You can easily install the big3d agent on the BIG-IP Controllers, EDGE-FX Caches, and GLOBAL-SITE Controllers in your network by using the 3-DNS Maintenance menu.
To install the big3d agent from the command line
- Log on to the 3-DNS Controller using either a remote shell, a serial terminal, or a keyboard and monitor attached directly to the controller.
- At the command prompt, type 3dnsmaint.
The 3-DNS Maintenance menu opens. - Choose the Install and Start big3d command from the menu and press Enter.
Understanding factories run by big3d agents
To gather performance information, the big3d agent uses different types of factories. A factory is a process that collects different types of data. The big3d agent currently supports five factory types:
- Prober factory
A prober factory collects several types of information using ICMP, TCP, UDP, DNS_DOT, or DNS_REV protocols. This factory queries host virtual servers and local DNS servers. Host virtual servers are checked to determine their up or down state. For local DNS servers, the prober factory uses the response time to calculate the round trip time and packet loss between the LDNS and the data center. - Hops factory
A hops factory uses the traceroute method to calculate the number of intermediate systems transitions along the network path between a specific data center and a client LDNS. - SNMP factory
An SNMP factory uses conversations with SNMP agents that run on host servers to collect performance metrics for the host. - Discovery factory
A discovery factory acts as a backup to a prober factory. The big3d agent runs a discovery factory only when a prober 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 prober factory. If the discovery factory finds an open port, it returns the port number to the 3-DNS Controller, which stores the number to use for future path probe attempts. - Permanent factories
Two permanent factories collect performance information. One factory collects information from the BIG-IP Controller when it exists, the other collects the number of packets being processed per second. These factories are not configurable.
The standard configuration specifies that each BIG-IP Controller, EDGE-FX Cache, and 3-DNS Controller in the network run a big3d agent using five prober factories, one SNMP factory, one discovery factory, no hops factories, and the two permanent factories. In the BIG-IP Controller or 3-DNS Controller server definition, you can change the number of factories that the big3d agent runs. For example, the default number of hops factories is set to 0; if you want to run a hops factory, you change the setting to 1 or more.
Understanding the data collection and broadcasting sequence
The big3d agents collect and broadcast information on demand. The principal 3-DNS Controller in the sync group issues a data collection request to all big3d agents running in the network. In turn, the big3d agents collect the requested data using the factories, and then broadcast that data to all 3-DNS Controllers running in the network, including the principal controller that issued the request.
Tracking LDNS probe states
The 3-DNS Controller tracks the state of path data collection for each LDNS that has ever requested a name resolution from the controller. Table 3.1 shows the six states that can be assigned to an LDNS. Note that you can view the state of LDNS servers in the Local DNS Statistics screen in the Configuration utility.
Evaluating big3d agent configuration trade-offs
You must run a big3d agent on each BIG-IP Controller, 3-DNS Controller, and EDGE-FX Cache. If you are using advanced load balancing modes, you must have a big3d agent running on at least one controller in each data center to gather the necessary path metrics.
The load on the big3d agents depends on two factors: the timer settings that you assign to the different types of data the big3d agents collect, and the number of factories that each big3d agent runs. The shorter the timers, the more frequently the agent needs to refresh the data. While short timers guarantee that you always have valid data readily available for load balancing, they also increase the frequency of data collection. The more factories a big3d agent runs, the more metrics it can refresh at one time, and the more quickly it can refresh data for the 3-DNS Controller.
Another factor that can affect data collection is the number of client LDNS servers that make name resolution requests. The more LDNS servers that make resolution requests, the more paths that the big3d agent has to collect. While round trip time for a given path may vary constantly due to current network load, the number of hops along a network path between a data center and a specific LDNS does not often change. Consequently, you may want to set short timer settings for round trip time data so that it refreshes more often, but set high timer settings for hops data because it does not need to be refreshed often.
Setting up communication between 3-DNS Controllers and other F5 servers
In order to copy big3d agents from the 3-DNS Controllers to BIG-IP Controllers and EDGE-FX Caches, the 3-DNS Controllers need to communicate with BIG-IP Controllers. If you use exclusively crypto 3-DNS Controllers and crypto BIG-IP Controllers, or exclusively non-crypto 3-DNS Controllers and non-crypto BIG-IP Controllers, the communication tools set up by the First-Time Boot utility are all you need. Crypto controllers all use ssh and scp, and non-crypto controllers all use rsh and rcp.
However, if you work in a mixed environment where some controllers are crypto, and other controllers are non-crypto, you need to enable the rsh and rcp tools on the crypto controllers. These tools come pre-installed on all crypto 3-DNS Controllers and BIG-IP Controllers, but you must explicitly enable them.
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 either by running the config_rshd script, or by changing the bigip.open_rsh_ports system control variable to 0 in /etc/rc.sysctl.
Table 3.2 shows the ports and protocols that 3-DNS Controllers use to communicate with BIG-IP Controllers and EDGE-FX Caches.
Note that if you run big3d agents in a mixed crypto/non-crypto environment, the crypto controllers automatically turn off Blowfish encryption when communicating with non-crypto big3d agents. When communicating with crypto big3d agents, however, crypto 3-DNS Controllers always use Blowfish encryption by default, although you can manually disable it if you prefer.
Setting up iQuery communications for the big3d agent
The iQuery protocol uses one of two ports to communicate between the big3d agents and the 3-DNS Controllers. The ports used by iQuery traffic change, depending on whether the traffic is inbound from the big3d agent or outbound from the 3-DNS Controller.
Table 3.3 shows the protocols and corresponding port numbers used for iQuery communications between 3-DNS Controllers and big3d agents that run on 3-DNS Controllers, BIG-IP Controllers, or EDGE-FX Caches.
Table 3.4 shows the protocols and corresponding ports used for iQuery communications between big3d agents and SNMP agents that run on host servers.
Allowing iQuery communications to pass through firewalls
The payload information of an iQuery packet contains information that potentially requires translation when there is a firewall in the path between the big3d agent and the 3-DNS Controller. Only packet headers are translated by the firewall, payloads are not.
The iQuery translation option resolves this issue. With iQuery translation turned on, the iQuery packet stores the original IP address in the packet payload itself. When the packet passes through a firewall, the firewall translates the IP address in the packet header normally, but the IP address within the packet payload is preserved. The 3-DNS Controller reads the IP address out of the packet payload, rather than out of the packet header.
In the example configuration shown in Figure 3.1 , a firewall separates the path between a BIG-IP Controller running a big3d agent and the 3-DNS Controller. The packet addresses are translated at the firewall. However, addresses within the iQuery payload are not translated, and they arrive at the BIG-IP Controller in their original states.
Figure 3.1 Translating packet address through the firewall
Communications between 3-DNS Controllers and other machines in the network
The following tables show the other ports and protocols that 3-DNS Controllers use for communication. Table 3.5 shows the ports that 3-DNS Controllers use for remote administrative connections to the 3-DNS web server.
Figure 3.2 shows the ports necessary for administrative communication between individual 3-DNS Controllers, and also between 3-DNS Controllers and administrative workstations.
Figure 3.2 Administrative communications ports
Table 3.6 shows the ports on which the 3-DNS Controller receives and responds to DNS resolution requests issued by LDNS servers.
Figure 3.3 shows the ports necessary for path probing between 3-DNS Controllers and local DNS servers.
Figure 3.3 Path probe communications
Table 3.7 shows the protocols and ports that the big3d agent uses when collecting path data for local DNS servers.
The big3d agent can run on a 3-DNS Controller, a BIG-IP Controller, an EDGE-FX Cache, or a GLOBAL-SITE Controller. If you run a big3d agent on a BIG-IP Controller and you set the SNMP prober 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.
