The big3d agent collects performance information on behalf of the 3-DNS Controller. The big3d agent runs on 3-DNS Controllers, BIG-IP Controllers, and EDGE-FX Caches. The default setting is to run a big3d agent on all F5 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 3-DNS Controllers in your network.
You can easily install the big3d agent on the BIG-IP Controllers and EDGE-FX Caches in your network by using the 3dnsmaint command line utility.
To gather performance information, the big3d agent uses different types of factories. A factory is a process which collects different types of data. The big3d agent currently supports five factory types:
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.
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.
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 page in the 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 probing.|
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.
In order to copy big3d agents from the 3-DNS Controllers to the BIG-IP Controllers and the 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 and BIG-IP Controllers, but you must explicitly enable them.
From the command line, run the rsetup script.
Table 3.2 shows the ports and protocols that 3-DNS Controllers use to communicate with BIG-IP Controllers and EDGE-FX Caches.
|From||To||Protocol||From Port||To Port||Purpose|
|Crypto 3-DNS Controller||Crypto BIG-IP Controller||TCP||<1023||22||SSH/SCP|
|Crypto 3-DNS Controller||Non-crypto
|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.
The iQuery protocol can use one of two ports to communicate between the big3d agents and the 3-DNS Controllers. The ports used by iQuery traffic change, depending on whether the traffic is inbound from the big3d agent or outbound from the 3-DNS Controller.
Figure 3.1 shows the ports necessary for iQuery communication between 3-DNS Controllers and big3d agents that run on 3-DNS Controllers, BIG-IP Controllers, or EDGE-FX Caches.
Table 3.3 shows the port numbers and corresponding protocols used for iQuery traffic.
|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)|
|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|
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.2 , 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.
The following tables show the other ports and protocols that 3-DNS Controllers use for communication. Table 3.4 shows the ports that 3-DNS Controllers use for remote administrative connections to the 3-DNS web server.
|Remote Workstation||Crypto 3-DNS Controller||TCP||443||Connection to secure web server|
|Remote Workstation||Non-crypto 3-DNS Controller||TCP||80||Connection to standard web server|
Figure 3.3 shows the ports necessary for administrative communication between individual 3-DNS Controllers, and also between 3-DNS Controllers and administrative workstations.
Table 3.5 shows the ports on which the 3-DNS Controller receives and responds to DNS resolution requests issued by LDNS servers.
|LDNS||3-DNS Controller||UDP||53 or >1024||53||DNS resolution requests|
|3-DNS Controller||LDNS||UDP||53||53 or >1024||DNS resolution answers|
Figure 3.4 shows the ports necessary for path probing between 3-DNS Controllers and local DNS servers.
Table 3.6 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|
|big3d agent||LDNS||dns_rev dns_dot||>1024||53||DNS version or dot queries|
|LDNS||big3d agent||dns_rev dns_dot||53||>1024||DNS version or dot response|
The big3d agent can run on a 3-DNS Controller, a BIG-IP Controller, or an EDGE-FX Cache. 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.