Configuring anchors

You can configure anchors for discovery when a firewall is present.

IP devices must respond to pings from either the TADDM server or an anchor in order to be discovered. Because most firewalls are not configured to forward pings, the TADDM server is unable to ping systems behind a firewall and is unable to discover them. To enable discovery through a firewall, an anchor must be identified to assist the TADDM server with the discovery process.

The anchor must be located in the same network section as the target for discovery and meet the same software requirements as the TADDM server.

Before you can discover systems that have a firewall between them and the TADDM server, the TADDM server must allow SSH traffic to the anchor. Make sure that your network administrator configures the firewall to enable SSH traffic between the TADDM server and the anchor. You must use SSH version 2 network protocol when exchanging the data.

On Linux® and UNIX systems, the discovery service account must have root execution permission for the nmap command. Make sure that the following line exists in the /etc/sudoers configuration file:
TADDM_userid ALL=(ALL) NOPASSWD:nmap_path
where
  • TADDM_userid is the TADDM discovery service account on the anchor system.
  • nmap_path is the full path to the location of the nmap command.
If the sudoers file contains a Defaults requiretty line, comment it out.

The anchor is created by the AnchorSensor through an SSH session that connects to the system defined as the anchor. The user for the SSH session is the first Computer System (or Computer System (Windows)) entry in the Access List that completes a successful connection. On the anchor system, the home directory for this user must be writable by the user and have at least 1.2 GB of free space. The TADDM files, including the Java SDK, are transferred to this directory by using scp and extracted. Since these files contain executable code, you must either disable antivirus programs or configure them to allow the anchor user to transfer and extract this code. Anchors are also automatically redeployed by the AnchorSensor after TADDM maintenance changes, such as fix packs.

If the network connection between the TADDM server and the anchor system is slow, or if the TADDM server and the anchor server are far apart, the AnchorSensor might time out before it completes the creation of the anchor. The default timeout value is 20 minutes. To change the timeout value for the AnchorSensor to another value, modify the setting for com.collation.discover.agent.AnchorSensor.timeout value in the COLLATION_HOME/etc/collation.properties file. The value is in milliseconds, so the default value is 1200000, which equals 20 minutes.

After the firewall setup is complete, define the anchor by using the Discovery Management Console. When you define the anchor, you must include it in the scope of the root server. The scope of the anchor must be restricted to the systems in that network section. When discovery is initiated from the Discovery Management Console, the TADDM server deploys the necessary files to the anchor. After the files are deployed, the anchor runs the discovery and returns the results to the TADDM server.

If there are multiple zones or firewalls, you must specify at least one anchor in each adjacent zone so that communications can be relayed from each anchor across each firewall. To do this, SSH traffic must be enabled between each pair of adjacent anchors, starting with the root server. Each anchor in the next adjacent network subnet must be included in the scope of the anchor in the previous subnet. Anchors chained in this way must be running on the same operating system type.

Note: If more than one anchor is specified in a single scope, and there is connectivity between them, TADDM attempts to start anchor chains on these anchors. This behavior may result in various error messages on the GUI and in the logs, even if the anchor is deployed correctly.

See Adding an anchor or gateway for information about defining anchors using the Discovery Management Console.

Also note that the TADDM user interface does not indicate which NAT zone an object is in. To avoid confusion, make sure hosts with the same IP address in different NAT zones have different host names, which makes it possible to distinguish them. Assign different domains (for example, nat1.lab.company.com, nat2.lab.company.com) to each NAT zone. This ensures that the fully-qualified host names from different NAT zones are unique. Note that if the same DNS server is used for different NAT zones with identical subnet addresses, then different DNS views must be used for each zone.

Note: When an anchor or other dual-homed host is discovered through an L1 discovery, the host might be displayed as a duplicated entry in the physical infrastructure tree. This duplication occurs because the host is discovered twice, once by TADDM and once by the anchor, and the L1 discovery does not provide enough information to reconcile the two discoveries. To reconcile the two entries as one host, run an L2 or L3 discovery.
If more than one domain server, in synchronization server deployment, or discovery server, in streaming server deployment, use the same machine as an anchor on which to perform simultaneous discoveries, the following changes must be made:
  • Set the anchor port.
    1. In the Anchors and Gateways pane of the Discovery Management Console, click Set Anchor Port. The Edit Port Number window is displayed.
    2. In the Port No. field, type the port number. Ensure that the port number is different for each TADDM server.
    3. Click OK.
  • Set the anchor directory.
    1. Open the $COLLATION_HOME/etc/collation.properties file.
    2. Set the com.ibm.cdb.taddm.anchor.root property value to the anchor directory name. Ensure that the property is not commented out and that the directory is different for each TADDM server.
TADDM sets a location tag attribute for each configuration item (CI) that is created on the TADDM server. To set the location tag attribute for CIs that are created on an anchor, configure the anchor_location_n attribute in the $COLLATION_HOME/etc/anchor.properties file. The following sample entries from the anchor.properties file indicate how location information for anchors is set:
anchor_host_1=192.168.1.13
anchor_scope_1=FIRST_SCOPE
anchor_zone_1=FIRST_ZONE
anchor_location_1=FIRST_LOCATION
anchor_host_2=192.168.2.22
anchor_scope_2=SECOND_SCOPE
anchor_location_2=SECOND_LOCATION
Port=8497

If a location tag is not specified for an anchor, the location of each of the CIs that are created on the anchor is set to the location that is specified for the TADDM server to which the CIs are connected. If the location tag is not specified for the anchor or the TADDM server, no location information is set for that CI.