Manual Chapter : 3-DNS Reference Guide v4.5.10: Probing and Metrics Collection

Applies To:

Show Versions Show Versions

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

  • 4.5.14, 4.5.13, 4.5.12, 4.5.11, 4.5.10
Manual Chapter


5

 

Probing and Metrics Collection


Overview of probing and metrics collection

The 3-DNS Controller can collect server availability and capacity information from any server or appliance in the network using the big3d agent. The big3d agent can also collect path information (router hops, round trip times, and completion rates) from local DNS servers. This data collecting is known as probing. The 3-DNS Controller uses the big3d agent to probe all BIG-IP systems and EDGE-FX systems in the controller's network. The big3d agent uses SNMP to probe any hosts or routers in the controller's network. Alternately, if you do not want the big3d agent to probe certain servers, for example, America Online (AOL) local DNS servers, you can create access control lists (ACLs).


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 systems, and EDGE-FX systems. The default setting is to run a big3d agent on all of these systems in the network, but you can turn off the big3d agent on any system at any time. If you turn off the big3d agent on a server, the 3-DNS Controller can no longer check the availability of the server or its virtual servers, and the statistics screens display the status as unknown (blue ball).

Note


We recommend that you have a big3d agent running on at least one system in each data center in your network.

 


Collecting path data and server performance metrics

A big3d agent collects the following types of performance information used for load balancing. The big3d agent broadcasts this information to all 3-DNS Controllers in your network.

  • Network path round trip time
    The big3d agent calculates the round trip time for the network path between the agent's data center and the client's LDNS server that is making the resolution request. The 3-DNS Controller uses round trip time to determine the best virtual server to answer the request when a pool uses a dynamic load balancing mode, such as Round Trip Time, or Quality of Service.

  • Network path packet loss
    The big3d agent calculates the packet completion percentage for the network path between the agent's data center and the client's LDNS server that is making the resolution request. The 3-DNS Controller uses the packet completion rate to determine the best virtual server to answer the request when a wide IP or pool uses either the Completion Rate or the Quality of Service load balancing modes.

  • Router hops along the network path
    The big3d agent calculates the number of intermediate system transitions (router hops) between the agent's data center and the client's LDNS server. The 3-DNS Controller uses hops to determine the best virtual server to answer the request when a pool uses the Hops or the Quality of Service load balancing modes.

  • Server performance
    The big3d agent returns server metrics, such as the packet rate, for BIG-IP systems or SNMP-enabled hosts. The 3-DNS Controller uses packet rate to determine the best virtual server to answer the request when a pool uses the Packet Rate, KBPS, Least Connections, or Quality of Service load balancing modes.

  • Virtual server availability and performance
    The big3d agent queries virtual servers to verify whether they are up and available to receive connections, and uses only those virtual servers that are up for load balancing. The big3d agent also determines the number of current connections to virtual servers that are defined on BIG-IP systems or SNMP-enabled hosts. The 3-DNS Controller uses the number of current connections to determine the best virtual server when a pool uses the Least Connections or VS Capacity load balancing mode.


Setting up data collection with the big3d agent

Setting up the big3d agents involves the following tasks:

  • Installing big3d agents on BIG-IP systems and EDGE-FX systems
    Each new version of the 3-DNS software includes the latest version of the big3d agent. You need to distribute that copy of the big3d agent to each BIG-IP system and EDGE-FX system in the network. See the release notes provided with the 3-DNS software for information about which versions of the BIG-IP software and the EDGE-FX software the current big3d agent supports. For details on installing the big3d agent, see Installing the big3d agent .

  • Specifying which factories a specific big3d agent manages
    When you define 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems in the configuration, you can change the default big3d agent settings by changing the factories settings on a specific system. You can change the number of factories the big3d agent runs, and turn specific factories on and off. For more information on factories, see Understanding factories run by big3d agents .

  • Setting up communications between big3d agents and other systems
    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 servers .


Installing the big3d agent

You can use the 3-DNS Maintenance menu to easily install the big3d agent on the BIG-IP systems and EDGE-FX systems in your network.

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 system.

  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 the following factory types:

  • Prober factory
    A prober factory collects several types of information using the DNS_DOT, DNS_REV, ICMP, TCP, or UDP protocols. (Note that the prober factory uses the protocols in the listed order.) The prober 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 calculates the round trip time and packet loss rate between the LDNS and the data center.

  • Hops factory
    A hops factory uses the traceroute method to calculate the number of intermediate systems transitions (or router hops) along the network path between a specific data center and a client LDNS.

  • SNMP factory
    An SNMP factory queries the SNMP agents that run on host servers to collect performance metrics for the host.

  • ECV factory
    When you have set up extended content verification (ECV) service monitors for wide IPs, an ECV factory performs a more extensive availability check than the prober factories. (For more information on ECV service monitors, see Working with the ECV service monitor .

The standard configuration specifies that each 3-DNS system, BIG-IP system, and EDGE-FX system in the network run a big3d agent using five prober factories, one SNMP factory, no hops factories, and five ECV factories. You can change the number of factories that the big3d agent runs either by using the Configuration utility, or by editing the server definition in the wideip.conf file. Note also that the controller dynamically increases the number of factories if needed.

     

To edit the factory settings for a 3-DNS system using the Configuration utility

  1. In the navigation pane, click Servers, and then click 3-DNS.
    The 3-DNS List screen opens.

  2. In the list, click the name of the 3-DNS Controller that you want to modify.
    The Modify 3-DNS screen opens.

  3. Make the changes to the factory settings that you want to make, and click Update. For more information on the settings on this screen, click Help on the toolbar.

To edit the factory settings for a BIG-IP system using the Configuration utility

  1. In the navigation pane, click Servers, and then click BIG-IP.
    The BIG-IP List screen opens.

  2. In the list, click the name of the BIG-IP system that you want to modify.
    The Modify BIG-IP screen opens.

  3. Make the changes to the factory settings that you want to make, and click Update. For more information on the settings on this screen, click Help on the toolbar.

To edit the factory settings for an EDGE-FX system using the Configuration utility

  1. In the navigation pane, click Servers, and then click EDGE-FX.
    The EDGE-FX List screen opens.

  2. In the list, click the name of the EDGE-FX system that you want to modify.
    The Modify EDGE-FX screen opens.

  3. Make the changes to the factory settings that you want to make, and click Update. For more information on the settings on this screen, click Help on the toolbar.


Understanding the data collection and broadcasting sequence

The big3d agents collect and broadcast information on demand. The principal 3-DNS Controller in a 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 factories, and then broadcast that data to all 3-DNS Controllers running in the network, including the principal 3-DNS system 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 system. Table 5.1 shows the 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.

 

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.

 

Evaluating big3d agent configuration trade-offs

You must run a big3d agent on each BIG-IP system, 3-DNS system, and EDGE-FX system in your network if you use dynamic load balancing modes (those that rely on path data) on the 3-DNS Controller. (For information about dynamic load balancing, see Using dynamic load balancing modes .) You must have a big3d agent running on at least one system 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 big3d 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 path data that the big3d agents have 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 servers

In order to copy big3d agents from a 3-DNS Controller to BIG-IP systems and EDGE-FX systems, the 3-DNS Controller must be able to communicate with the other systems. If you use exclusively crypto systems, or exclusively non-crypto systems, the communication tools you configure when you run the Setup utility are all you need. Crypto systems all use ssh and scp, and non-crypto systems all use rsh and rcp.

However, if your network is a mixed environment, where some systems are crypto and other systems are non-crypto, you need to enable the rsh and rcp tools on the crypto systems so that they can communicate with the non-crypto systems. These tools are pre-installed on all crypto systems, however, you must explicitly enable them.

To enable rsh on a crypto system from the command line

  1. Type setup, and press Enter.
    The Setup utility opens.

  2. From the menu, choose (U) Configure RSH, and press Enter.

  3. Follow the onscreen instructions to enable the rsh and rcp tools.

Important:
As of 3-DNS Controller, version 4.5, we no longer distribute non-crypto systems. You may, however, want to enable rsh if you have older, non-crypto systems in your network.

Table 5.2 shows the ports and protocols that a 3-DNS system uses to communicate with crypto and non-crypto BIG-IP systems and EDGE-FX systems.

 

 

From

To

Protocol

From Port

To Port

Purpose

Crypto 3-DNS Controllers

Crypto BIG-IP systems, crypto EDGE-FX systems

TCP

<1024

22

SSH/SCP

Non-crypto 3-DNS Controllers

Non-crypto BIG-IP systems, Non-crypto EDGE-FX systems

TCP

<1024

514

RSH/RCP

Crypto 3-DNS Controllers

Non-crypto BIG-IP systems, Non-crypto EDGE-FX systems

TCP

<1024

514

RSH/RCP

Non-crypto BIG-IP systems, Non-crypto EDGE-FX systems

Crypto 3-DNS Controllers

N/A

N/A

N/A

N/A

 

 

Note that if you run big3d agents in a mixed crypto/non-crypto environment, the crypto systems automatically turn off Blowfish encryption when communicating with non-crypto systems. When communicating with other crypto systems, however, crypto 3-DNS Controllers use Blowfish encryption after the iQuery encryption key has been copied to all crypto 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems.

     

To create and distribute the iQuery encryption key from the command line

  1. From the command line, type 3dnsmaint.
    The 3-DNS Maintenance menu opens.

  2. Select Generate and Copy iQuery Encryption Key, and press Enter.

  3. Follow the onscreen instructions to generate and copy the iQuery encryption key to the crypto systems in your network.


Setting up iQuery communications for the big3d agent

The iQuery protocol uses one of two ports to communicate between the big3d agents throughout the network and 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 5.3 shows the protocols, ports, and iQuery settings for both inbound and outbound iQuery communications between 3-DNS Controllers and big3d agents distributed in your network.

 

From

To

Protocol

From Port

To Port

Multiplex?

Use Alternate Port?

3-DNS system

big3d agent

UDP

4353

4353

Yes

Yes

3-DNS system

big3d agent

UDP

4354

4353

No

Yes

3-DNS system

big3d agent

UDP

245

245

Yes

No

3-DNS system

big3d agent

UDP

4354

245

No

No

3-DNS system

big3d agent

TCP

4354

4353

Yes

Yes or No

3-DNS system

big3d agent

TCP

>1023

4353

No

Yes or No

big3d agent

3-DNS system

UDP

4353

4353

Yes

Yes

big3d agent

3-DNS system

UDP

4353

4354

No

Yes

big3d agent

3-DNS system

UDP

245

245

Yes

No

big3d agent

3-DNS system

UDP

245

4354

No

No

big3d agent

3-DNS system

TCP

4353

4354

Yes

Yes or No

big3d agent

3-DNS system

TCP

4353

>1023

No

Yes or No

 

You can configure the multiplex and alternate port globals using the Configuration utility.

To configure the multiplex and alternate port settings using the Configuration utility

  1. In the navigation pane, click System.
    The System - General screen opens.

  2. Check the iQuery Settings, Use Alternate Port (port 4353) box to specify that iQuery traffic use port 4353 (the preferred, registered port). Clear the check box if you want iQuery traffic to use the old port, 245.

  3. Check the iQuery Settings, Multiplex box if you want UDP-based iQuery traffic to be sent and received on the same port (245 or 4353), and you want traffic from the big3d agent to use port 4354.

  4. For more information, click Help on the toolbar.

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

 

From

To

Protocol

From Port

To Port

Purpose

big3d agent

host SNMP agent

UDP

>1023

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

 

If you run a big3d agent on a 3-DNS system or a BIG-IP system, and you set the SNMP prober factory count to 1 or higher, the big3d agent automatically opens the appropriate UDP ports to allow for SNMP communications. If you do not want to open the UDP ports for this purpose, you need to set the SNMP factory count to 0.

     

Allowing iQuery communications to pass through firewalls

The payload information of an iQuery packet contains information that potentially requires network address translation when there is a firewall in the path between the big3d agent and the 3-DNS Controller. The firewall translates only the packet headers, not the payloads.

The virtual server translation option resolves this issue. When you configure address translation for virtual servers, 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 5.1 , a firewall separates the path between a BIG-IP system 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 system in their original states.

Figure 5.1 Translating packet address through the firewall


Communications between 3-DNS Controllers, big3d agents, and local DNS servers

Table 5.5 shows the ports on which the 3-DNS Controller receives and responds to DNS resolution requests issued by local DNS servers.

 

From

To

Protocol

From Port

To Port

Purpose

LDNS

3-DNS

UDP

53 or >1024

53

DNS resolution requests

3-DNS

LDNS

UDP

53

53 or >1024

DNS resolution responses

 

Table 5.6 shows the protocols and ports that the big3d agent uses when collecting path data for local DNS servers.

 

From

To

Protocol

From Port

To Port

Purpose

big3d

LDNS

ICMP

N/A

N/A

Probe using ICMP pings

big3d

LDNS

TCP

>1023

53

Probe using TCP (Cisco routers: allow establish)

LDNS

big3d

TCP

53

>1023

Replies using TCP (Cisco routers: allow establish)

big3d

LDNS

UDP

53

33434

Probe using UDP or traceroute utility

LDNS

big3d

ICMP

N/A

N/A

Replies to ICMP, UDP pings, or traceroute probes

big3d

LDNS

dns_rev
dns_dot

>1023

53

Probe using DNS version or DNS dot

LDNS

big3d

dns_rev
dns_dot

53

>1023

Replies to DNS version or DNS dot probes

 

Working with SNMP on the 3-DNS Controller

The 3-DNS Controller ships with a customized simple network management protocol (SNMP) agent and management information base (MIB). This section describes the management and configuration tasks with which you can configure the 3-DNS SNMP agent.

The 3-DNS SNMP agent and 3-DNS MIB allow you to monitor the 3-DNS Controller by configuring traps for the SNMP agent or by polling the system with a standard network management station. The 3-DNS SNMP agent has the following options to ensure secure management:

  • Community names

  • TCP wrappers

  • View access control mechanism (VACM)
     

Using the Configuration utility, you can configure the 3-DNS SNMP agent to send traps to your network management system. You can also set up custom traps by editing several configuration files.

Note


If you want to monitor the 3-DNS Controller using the SEE-IT Network Manager, you must configure the SNMP agent on the 3-DNS Controller.

 


Configuring SNMP on the 3-DNS Controller

To use SNMP on the 3-DNS Controller, you must complete the following tasks:

  • Download the 3-DNS MIBs and load them into your network management station

  • Modify the following configuration files:

    • /etc/hosts.allow

    • /etc/snmpd.conf

    • /etc/3dns_snmptrap.conf

    • /etc/syslog.conf

  • Configure options for the checktrap.pl script

Important:
If you are configuring the 3-DNS Controller module on a BIG-IP system, you configure any SNMP settings using the BIG-IP Configuration utility. For information about working with SNMP on a BIG-IP system, refer to the BIG-IP Reference Guide .

Downloading the MIBs

The 3-DNS Controller includes a proprietary 3-DNS SNMP MIB. This MIB is specifically designed for use with the 3-DNS Controller. You can configure the SNMP settings in the Configuration utility or on the command line.

SNMP management software requires that you use the MIB files associated with the device. You can obtain the following three MIB files from the /usr/local/share/snmp/mibs directory on the controller, or you can download the files from the Additional Software Downloads section of the Configuration utility home screen. The files you need are:

  • 3dns.my
    This is a vendor MIB that contains specific information for properties associated with specific 3-DNS functionality, such as load balancing.

  • rfc1611.my
    This is a DNS server MIB (RFC 1611) that provides standard management information.

  • UCD-SNMP-MIB.txt
    This is a MIB-II (RFC 1213) that contains specific management information for the UC-Davis SNMP agent.

For information about the objects defined in 3dns.my, refer to the descriptions in the object identifier (OID) section of the MIB file. For information about the objects defined in rfc1611.my, refer to RFC 1611.

     

Understanding configuration file requirements

Before using the SNMP agent, you need to make changes to several configuration files on the 3-DNS Controller. You can make these changes either by using the Configuration utility or by modifying the files from the command line. Once you change these configuration files, you must restart the SNMP agent. The files are discussed in the following sections.

/etc/hosts.allow

The /etc/hosts.allow file specifies the hosts that are allowed to access the SNMP agent. You can configure access to the SNMP agent with the /etc/hosts.allow file in one of two ways:

  • By typing in an IP address, or list of IP addresses, that are allowed to access the SNMP agent.

  • By typing in a network address and mask to allow a range of addresses in a subnet to access the SNMP agent.

Warning:
The /etc/hosts.allow file must contain the following entry, which is in the file by default: snmpd : 127.0.0.1. If you remove this entry, the 3-DNS Controller cannot properly poll using SNMP.


Adding a list of specific IP addresses to the etc/hosts.allow file

You can specify a list of addresses that you want to allow access to the SNMP agent. Addresses in the list must be separated by blank space or by commas. Use the following syntax:

daemon: <IP address> <IP address> <IP address>

In the following example, the SNMP agent accepts connections from the specified IP addresses only:

snmpd: 128.95.46.5 128.95.46.6 128.95.46.7


Adding an address range to the etc/hosts.allow file

For a range of addresses, the basic syntax is as follows, where daemon is the name of the daemon, and NETWORKADDRESS/MASK specifies the network that is allowed access:

daemon: NETWORKADDRESS/MASK

For example, the following syntax sets the snmpd daemon to allow connections from the 128.95.46.0/255.255.255.0 address range:

snmpd: 128.95.46.0/255.255.255.0

The previous example allows the 256 possible hosts from the network address 128.95.46.0 to access the SNMP daemon. You may also use the keyword ALL to allow access for all hosts or all daemons.

Note


If you prefer, instead of modifying this file from the command line, you can use the Configuration utility to specify the hosts that are allowed to access the SNMP agent. See To set SNMP properties using the Configuration utility .

 

/etc/hosts.deny

The /etc/hosts.deny file must be present to deny, by default, all UDP connections to the SNMP agent. The contents of this file are as follows:

ALL : ALL

/etc/snmpd.conf

The /etc/snmpd.conf file controls most aspects of the SNMP agent. This file is used to set up and configure certain traps, passwords, and general SNMP variable names.

The following list contains a few of the necessary variables:

  • System Contact Name
    The System Contact is a MIB-II simple string variable defined by almost all SNMP systems. It usually contains a user name and an email address. This is set by the syscontact key.

  • Machine Location (string)
    The Machine Location is a MIB-II variable that is supported by almost all systems. It is a simple string that defines the physical location of the system. This is set by the syslocation key.

  • Community String
    The community string clear text password is used for basic SNMP security. This also maps to VACM groups, but for initial read-only access, it is limited to only one group.

  • Trap Configuration
    Trap configuration is controlled by these entries in the /etc/snmpd.conf file:

    • trapsink <host>
      This sets the host to receive trap information. The <host> variable is an IP address.

    • trapport <port>
      This sets the port on which traps are sent. There must be one trapport line for each trapsink host.

    • trapcommunity <community string>
      This sets the community string (password) for sending traps. Once set, it also sends a trap upon startup: coldStart(0).

    • authtrapenable <integer>
      Set this variable to 1 so that traps can be sent for authentication warnings. Set the variable to 2 to disable it.
      Note: To change the trap port, be sure the trapport line precedes the trapsink line. If you use more than one trapsink line, there must be one trapport line before each trapsink line. The same is true for trapcommunity; if you use more than one trapcommunity line, there must be one trapcommunity line before each trapsink line.

  • System IP Setting
    You must set the system IP address using the sysip command; if this setting is not present, the checktrap.pl script fails to send all 3-DNS-specific traps. Use the following syntax to set the system IP address:

    sysip <3-DNS IP address>

Note


If you prefer, instead of modifying this file from the command line, you can use the Configuration utility to set these SNMP properties. See To set SNMP properties using the Configuration utility .

 

/etc/3dns_snmptrap.conf

The configuration in the /etc/3dns_snmptrap.conf file determines which messages generate traps and what those traps are. The file includes OIDS, traps, and regular expression mappings. The configuration file specifies whether to send a specific trap based on a regular expression. An excerpt of the configuration file is shown in Figure 5.2

Figure 5.2 Excerpt from the /etc/3dns_snmptrap.conf file


# Default traps.
.1.3.6.1.4.1.3375.1.2.2.2.0.1 (SNMP_TRAP: VS.*?state change green.*?red) VIRTUAL SERVER GREEN TO RED

.1.3.6.1.4.1.3375.1.2.2.2.0.2 (SNMP_TRAP: VS.*?state change red.*?green) VIRTUAL SERVER RED TO GREEN

.1.3.6.1.4.1.3375.1.2.2.2.0.3 (SNMP_TRAP: SERVER.*?state change green.*?red) SERVER GREEN TO RED

.1.3.6.1.4.1.3375.1.2.2.2.0.4 (SNMP_TRAP: SERVER.*?state change red.*?green) SERVER RED TO GREEN

.1.3.6.1.4.1.3375.1.2.2.2.0.5 (SNMP_TRAP: iQuery message from big3d) CRC FAILURE
 
.

Some of the OIDs have been permanently mapped to specific 3-DNS events. The OIDs that are permanently mapped for the 3-DNS Controller include:

  • Virtual server green to red

  • Virtual server red to green

  • Server green to red

  • Server red to green

  • CRC failure

  • Pool green to red

  • Pool red to green

  • 3-DNS Controller active to standby

  • 3-DNS Controller standby to active

To see events that are triggering an SNMP trap, look in the var/log/3dns directory.

     

/etc/syslog.conf

To generate traps, you must configure syslog to send syslog lines to checktrap.pl. If the syslog lines match a specified regular expression in the 3dns_snmptrap.conf file, the checktrap.pl script generates a valid SNMP trap. The following line in the /etc/syslog.conf file causes the syslog utility to send the specified log output to the checktrap.pl script. The checktrap.pl script then compares the logged information to the 3dns_snmptrap.conf file to determine if a trap should be generated.

local2.warning | exec /sbin/checktrap.pl.

Note


If you uncomment this line, make sure you restart syslogd.

 


Configuring options for the checktrap.pl script

The checktrap.pl script reads a set of lines from standard input. The script checks each line against a set of regular expressions. If a line matches a regular expression, the script sends an SNMP trap.

The following options are available for the checktrap.pl script.

  • SNMP configuration file
    This file contains the SNMP variables. The checktrap.pl script gets trap configuration information from this file. The default is /etc/snmpd.conf.

    snmpd_conf_file=<snmp configuration file>

  • SNMP trap configuration file
    This file contains the regular expression to SNMP trap OID mappings. It also contains a description string that is added to the trap message. The default is /etc/3dns_snmptrap.conf.

    trapd_conf_file=<snmp trap configuration file>

  • SNMP trap program
    This program sends the SNMP trap. This program should be the snmptrap program included with the 3-DNS Controller. The default is /usr/local/bin/snmptrap.

    trap_program=<snmp trap program>

  • Date removal
    This option turns off automatic date removal. Normally, each input line is expected to begin with a date. Typically, this date is removed before the trap is sent. This option keeps the date information in the trap. If you do not add this option, the date is removed from the trap by default.

    no_date_strip

  • Usage
    This option prints a usage string.

    usage


Configuring the 3-DNS SNMP agent using the Configuration utility

You can use the Configuration utility to configure the following aspects of the 3-DNS SNMP agent:

  • Client access
    You can define a specific network address or an address range from which SNMP requests are accepted. The Configuration utility adds the client access entries to the etc/hosts.allow file.

  • System information
    You can define a system contact, a machine location, and a community string. The Configuration utility adds the system information to the /etc/snmpd.conf file.

  • Trap configuration
    You can enter a trap sink and a trap community. The Configuration utility adds the trap configuration information to the /etc/snmpd.conf file.

Note


If you are configuring the 3-DNS Controller module on a BIG-IP system, you configure the SNMP settings in the BIG-IP Configuration utility.

 

 

To set SNMP properties using the Configuration utility

The Configuration utility provides sample SNMP settings for your reference. To use the 3-DNS SNMP MIB, you must replace these sample settings with settings appropriate to your environment and your specific SNMP management software.

  1. In the navigation pane, click SNMP.
    The SNMP Configuration screen opens.

  2. Add the SNMP settings.

  3. For help on configuring the SNMP settings, click Help on the toolbar.

Warning:
The /etc/hosts.allow file must contain the following entry, which is in the file by default: snmpd : 127.0.0.1. If you remove this entry, the 3-DNS Controller cannot properly poll using SNMP. When you use the Configuration utility to configure the systems's SNMP properties, this address is already listed in the Allow List box.

Configuring SNMP settings to probe hosts

After defining a host server or router, you need to configure its SNMP settings if you want to use SNMP to probe that host or router. Remember that you must first set up at least one SNMP prober factory on any 3-DNS Controller, BIG-IP system, or EDGE-FX system that runs the big3d agent and is in the same data center as the host or router.

The SNMP factory can collect some or all of the following information from a host or router:

  • Memory utilization

  • CPU utilization

  • Disk space utilization

  • Kilobytes/second throughput

  • Current connections

  • Packet rate

The 3-DNS Controller gathers metrics for BIG-IP systems, EDGE-FX Caches, and several host servers. Refer to Table 5.7 for information on the host server types and the specific metrics that can be collected for each host type. To see the current performance of any of these server metrics, review the Metrics statistics screen.

 

 

Server Type or Operating System

Metrics collected:

Kilobytes/
Second

Packets/
Second

CPU

Memory

Disk

Current Connections

Nodes Up

BIG-IP system

X

X

 

 

 

X

X

EDGE-FX Cache

X

X

 

 

 

X

 

Alteon® Ace Director

X

 

 

 

 

X

X

BSD, UC Davis

X

X

X

X

X

X

 

CacheFlow

X

X

X

 

 

X

 

Cisco® CSS series

X

X

 

 

 

X

X

Cisco LocalDirector

X

X

 

 

 

X

 

Cisco LocalDirector

X

X

 

 

 

X

 

Cisco SLB

 

 

 

 

 

X

X

Extreme

X

X

 

 

 

X

X

Foundry® ServerIron

X

X

 

 

 

X

X

Linux, UC Davis

X

X

 

X

X

X

 

NetApp® appliance

X

X

X

X

X

X

 

Sun® Solaris

X

X

X

 

 

X

 

Windows® 2000 Server

X

X

X

 

 

X

 

Windows NT® 4.0

X

X

X

X

 

X

 

 

 

Note


The Cisco LocalDirector metric shows new connections per second rather than current connections.

 

     

To configure host SNMP settings using the Configuration utility

  1. In the navigation pane, expand the Servers item, and click Host.

  2. From the Host column, click a host server.
    The Modify Host screen opens.

  3. On the toolbar, click SNMP Configuration.
    The Host SNMP Configuration screen opens.

  4. Add the SNMP settings for the host. For help on configuring the SNMP settings for a host, click Help on the toolbar.

To configure host SNMP settings from the command line

  1. Type the following command to ensure that the configuration files contain the same information as the memory cache.

    3ndc dumpdb

  2. Open the wideip.conf file in a text editor (either vi or pico).

  3. Locate or add the host server statement. (All server statements should appear after the globals statement and before wideip statements.)

  4. Define the server type, address, name, prober, probe protocol, and port information as usual.

  5. Add the snmp statement.

  6. Define the virtual server information as usual.

  7. Save and close the file.

  8. Commit the changes to the configuration by typing:

    3ndc reload

Figure 5.3 shows the SNMP syntax for a host server, in bold.

Figure 5.3 Configuring host SNMP settings


server {
  type host
  box <IP address>
  name <"host_name">
  probe_protocol <dns_dot | dns_rev | tcp | icmp>
[ prober <IP address> ]
port <port number> | service <"service name">
   [ snmp {
     agent <generic | ucd | solstice | ntserv | win2kserv | ciscold | ciscold2 | ciscold3 | foundry | arrowpoint | alteon | cacheflow | netapp>
     port <port number>
     community <"community string">
     timeout <seconds>
     retries <number>
     version <SNMP version>
     } ]
  vs {
    address <virtual server IP address>
    port <port number> | service <"service name">
    [ probe_protocol <dns_dot | dns_rev | tcp | icmp> ]
  }
}
 


Configuring the SNMP agent on host servers

For host probing to work properly, you need to verify that the SNMP agent is properly configured on the host itself. We recommend that you refer to the documentation provided with your host SNMP software for complete configuration information.


Working with access control lists

With access control lists (ACLs), you can block probing for members of the ACL when you use dynamic LDNS probing on the 3-DNS Controller. Table 5.8 lists the ACL types and describes their functions.


 

ACL Type

Description

Prober

Prober ACLs limit round-trip time probes.

Hops

Hops ACLs limit traceroute probes.

 

 

To define ACLs using the Configuration utility

  1. In the navigation pane, click System.
    The System - General screen opens.

  2. On the toolbar, click ACL.
    The ACL Configuration screen opens.

  3. Add the settings for the ACLs you want to create, and click Update. For more information on this screen, click Help on the toolbar.

To define ACLs from the command line

  1. If one does not already exist, create a file called region.ACL in the /config/3dns/include directory. You must add the include file at the beginning of the wideip.conf file.

  2. Add the file to /etc/wideip.conf by typing, at the command line:

    include "region.ACL"

Tip


When you create ACLs by editing the wideip.conf file from the command line, we strongly recommend that you put the ACLs in a separate include file.

 

The ACLs you can create are probe_acl, and hops_acl. Figure 5.4 is an example of the syntax for a region.ACL file with definitions for the two ACL types.

Figure 5.4 Sample region.ACL file


}
region_db ACL {
  region {
    name "probe_acl"
    region "probe_acl"
    192.168.4.0/24
  }
  region {
    name "hops_acl"
    192.168.2.0/16
  }
}