Manual Chapter : 3-DNS Module for BIG-IP Reference guide, v4.0: The big3d Agent

Applies To:

Show Versions Show Versions

3-DNS Controller versions 1.x - 4.x

  • 4.0 PTF-01, 4.0.0
Manual Chapter


3

The big3d Agent



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

  1. 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.
  2. At the command prompt, type 3dnsmaint.
    The 3-DNS Maintenance menu opens.
  3. 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.

Probe and discovery states for individual client LDNS servers
State Description
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 probing.

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.

Communications between 3-DNS Controllers, BIG-IP Controllers, and EDGE-FX Caches
From To Protocol From Port To Port Purpose
Crypto 3-DNS Controller Crypto BIG-IP Controller, Crypto EDGE-FX Cache TCP <1023 22 SSH/SCP
Non-crypto
3-DNS Controller
Non-crypto
BIG-IP Controller, Non-crypto EDGE-FX Cache
TCP >1024 514 RSH/RCP
Crypto 3-DNS Controller Non-crypto
BIG-IP Controller, Non-crypto EDGE-FX Cache
TCP >1024 514 RSH/RCP
Non-crypto
BIG-IP Controller, Non-crypto EDGE-FX Cache
Crypto 3-DNS Controller N/A N/A N/A N/A

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.

Communication protocols and ports between 3-DNS Controllers and big3d agents
From To Protocol From Port To Port Purpose
3-DNS Controller big3d agent UDP 245, 4354 245 Old standard iQuery port for outbound traffic
3-DNS Controller big3d agent UDP TCP 4353 or 4354 4354 or 4353 Alternate iQuery port for outbound traffic (open this port only when the use_alternate_iq global variable is set to yes)
big3d agent 3-DNS Controller UDP TCP 245 or 4353 4354 Ephemeral port used for inbound iQuery traffic (when multiplex_iq is set to no)
big3d agent 3-DNS 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 3-DNS Controller UDP TCP 4353 4354 4353 4353 4353 4354 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)

Table 3.4 shows the protocols and corresponding ports used for iQuery communications between big3d agents and SNMP agents that run on host servers.

Communication protocols and ports between big3d agents and SNMP agents
From To Protocol From Port To Port Purpose
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 using SNMP

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.

Communications between 3-DNS Controllers and remote workstations
From To Protocol Port Purpose
Configuration utility on a remote workstation Crypto 3-DNS Controller https over TCP 443 Connection to secure web server
Configuration utility on a remote workstation Non-crypto 3-DNS Controller http over TCP 80 Connection to standard 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.

DNS communications on the 3-DNS Controller
From To Protocol From
Port
To Port Purpose
LDNS 3-DNS Controller UDP 53 or >1024 53 DNS resolution requests
3-DNS Controller LDNS UDP 53 53 or >1024 DNS resolution responses

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.

Communications between big3d agents and local DNS servers
From To Protocol From Port To
Port
Purpose
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
big3d agent LDNS dns_rev dns_dot >1024 53 DNS version or DNS dot queries
LDNS big3d agent dns_rev dns_dot 53 >1024 DNS version or DNS dot responses

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.