The Dartware Technical Support Team routinely reviews customer and evaluator questions and posts those that are most commonly asked on these pages. If you can't find answers to your questions on these pages, please refer to the Knowledge Base or contact us.
Edit > Server Settings > Server Information > Registration
If two devices are added which are identical in every way (IP address, probe type, parameter values, etc.), and the probe type is Ping or one of the SNMP family of probes, then they should be detected as being identical, in which case they will "share" polling and be counted together as only a single device against your license maximum. If they are not absolutely identical, or are some other type of probe, this does not apply and they will count individually against your license maximum.
InterMapper has the ability to suppress alerts for devices that are behind or "shadowed" by another device that has failed. These devices may or may not be operating, but InterMapper cannot determine their state because the down equipment blocks its "view". That is, the shadowed devices are "dependent" on their upstream equipment. InterMapper uses the links between the devices on the map to determine how devices are interconnected. Thus we can see in the diagram below that InterMapper is connected to device labelled #2, which then connects to the device labelled #1, and then to #3. Code: * [ InterMapper ] ----- [ #2 ] ------ [ #1 ] ------ [ #3 ] A Vantage Point indicates the icon that represents the InterMapper server on the network. In this case the asterisk at the left indicates which device is the InterMapper server. (In the event that the InterMapper server is not represented on the map, place the Vantage Point on the icon (device or network oval) that indicates the direction to the InterMapper server. If device #2 goes down, InterMapper can infer that there's no reason for reporting or alerting about the unresponsiveness of #1 and #3, because #2 is blocking their visibility. In practice, these dependencies will suppress most, but not necessarily all, alerts. InterMapper polls devices in an essentially random order. Let's assume that the devices in the diagram are polled in the order 1, 2. 3. If device #2 actually went down while InterMapper was polling/testing device #1, InterMapper would report that device #1 is down. It would then poll device #2, detect that it was down, and report it. Finally, it would detect that device #3 wasn't responding, but would suppress the outage because both #1 and #2 were down.
In order to move InterMapper to another server, please follow the platform-specific instructions below: Migrating to Mac OS X:
Migrating to Windows/Linux:
The default location for the InterMapper Settings folder depends upon the platform where installed:
Note: If you are migrating from a PowerPC or Sparc system to a non-Mac Intel-based system, you must run a chart data conversion script manually. For example, if you are migrating from Mac OS on PowerPC to Windows XP or Linux/x86, you must run a conversion script manually. Similarly, you must follow the same procedure if you are migrating from Solaris/Sparc to Linux/x86. You can download the chart data conversion script from this link:
Exception: Installing InterMapper on an Intel-based Mac OS X system will run the conversion process automatically as part of the installation process, if needed. Note: If you also need to move the InterMapper DataCenter, please follow the instructions in this Knowledge Base entry:
Note: If you also need to move InterMapper Flows to a new server, please follow the instructions in this Knowledge Base entry:
InterMapper uses any number of evanescent source ports when probing devices. Destination ports depend on what probes are being used and how they are configured. Ports InterMapper listens on: * Remote server port: 8181 by default * IMDC port: 8182 by default * IM Database port: 8183 by default * IM Flows ports: 8184, 2055, 6343 by default * Web server port: 80 or 443 by default if turned on, but commonly changed * Telnet server port: 23 by default if turned on, but commonly changed * SNMP trap ports: 162 by default; optionally 161 or some other port as well, depending on configuration.
The Server Information pane of the Server Settings window shows the number of devices you are monitoring.
You can use the SNMP - High Traffic probe to alert on link utilization. This probe monitors the ifInOctets and ifOutOctets traffic statistics of a particular interface on the device, and sets the device into alarm or warning when the traffic exceeds certain thresholds. It also gives a DOWN alarm if the interface's ifOperStatus is not equal to 1 (up).
You will find this probe in the Network Devices folder in the Set Probe window.
Read the full forum article
There are two ways (or both on the same)
2: Set two 'benchmarks' on the map.
Read about using geographic coordinates in InterMapper
It's possible for a router or host to have two or more configured IP addresses for a particular interface.
It's also possible that InterMapper is only reporting what it has been told by the router, and the information it is using is incomplete. This may be true of multi-point network technologies (like frame-relay clouds). If you find a situation where InterMapper is reporting multiple networks on a logical network and you know it's wrong, please send us mail (InterMapper@dartware.com) so we can figure out a way to make InterMapper's depictions more accurate.
We would also like to hear about a network with multiple IP network numbers where InterMapper does not show them correctly.
Examine the network status window (click and hold on a network, or select Status Window from the context menu) to determine whether the subnet masks are the same in both ovals. If the subnet masks are different, one of the devices connected to the oval with the "wrong" subnet mask may have a misconfigured subnet mask.
Note: For devices polled with ICMP echoes, InterMapper tries to guess whether it should draw a link to the network that contains the IP address. If both network ovals look equally good, it may draw a link to the "wrong" one, or alternate between them.
On an InterMapper map, devices attempt to connect themselves to a good subnet oval. (Each oval/subnet on a map contains one or more subnet ranges - that is, a range of IP addresses.) A device will attach itself by drawing a line to a subnet oval that contains its IP address.
If you add another subnet oval (Insert -> Add network...) with the same subnet, you can drag the line from one subnet to another.
If a device's link has been dragged to an oval that doesn't contain it's address, the link will jump back to another subnet that does.
If a device won't stay attached to a subnet that should contain its address, check the subnet mask of both the oval and the device. One may be misconfigured.
NetFlow is a Cisco protocol that lets a network manager get insight into the kind of traffic flowing on the network, and which computer(s) are sending it. NetFlow exporters (generally routers and switches) send information about the flows passing through them to a NetFlow collector for storage and analysis.
Cisco has written a white paper that has a list of Cisco equipment that supports NetFlow.
Table 1. NetFlow Recent Cisco Device Support Matrix
Device
Supported
Cisco 800, 1700, 2600
Yes
Cisco 1800, 2800, 3800
Cisco 4500
Cisco 6500
Cisco7200, 7300, 7500
Cisco 7600
Cisco 10000, 12000, CRS-1
Cisco 2900, 3500, 3660, 3750
No
Click on the URL to see the whole white paper.
www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html#wp9000320
We have written a brief document at this URL that describes the commands used to configure NetFlow on Cisco equipment:
www.intermapper.com/tech-notes-intermapper-flows/200-enabling-netflow-on-cisco-equipment
A NetFlow exporter is a router, switch, or piece of software that summarizes information about traffic flowing on a network/interface and exports the data to another computer, i.e., a NetFlow collector to be saved and analyzed.
The NetFlow exporter examines each packet going by. It categorizes the packet according to the criteria above, and updates an internal cache that retains the amount of data that has been seen in each flow. From time to time, the exporter sends (exports) the current set of flow records to the NetFlow collector and clears its cache.
I have configured a Cisco ASA firewall to send Netflow data to Intermapper Flows. No data appears in the table or the graph; however, the firewall is listed as an exporter in the Flows Settings and there is a value for total v9 flows. A tcpdump shows packets are arriving on UDP port 2055 on the Flows server. _____________________
It appears that this is a known problem with the Cisco ASA firewall. This link is helpful in explaining the problem: http://netflowninjas.typepad.com/blog/2009/05/firewalls-and-netflow-it-could-be-heaven.html Relevant quote: "1) The Content of NSEL provides no traditional NetFlow telemetry capabilities - This is a huge disappointment. The lack of bytes transferred, number of packets, TCP Flags and other data completely removes the possibility of performing Behavioral Analysis on the flows." Dartware engineers have found that there are large fields in the templates that contain log lines in plain text. We have no idea what they are, and they are missing critical numbers. It appears that the ASA actually cannot do Netflow v9, and Netflow v5 is not an option with this firewall.
*** Perhaps using a software exporter and a managed switch as a network tap could offer a solution. (see other FAQs)
Not all routers and switches support NetFlow. For example, only certain models of Cisco equipment provide NetFlow data; many other manufacturer's gear will not export NetFlow records, either. If none of your switches or routers support Netflow, sFlow or jFlow, then you could use a software exporter to "tap" the network. This Knowledge Base topic should help: http://forums.dartware.com/viewtopic.php?t=871 http://www.intermapper.com/resources/blogs/rich-brown?start=4 If you decide to use a software exporter, you can download a free one from our partner Process Query Systems: http://www.proquesys.com/corporate/products/flowexporter/
A quick answer is "not much". The switch/router summarizes the flow information, and typically will send an update about the flows it has seen every 60 or 120 seconds (this is configurable).
There are no hard and fast rules, but NetFlow processing takes considerably more horsepower than InterMapper's standard monitoring. In general, we don't recommend using a discarded piece of hardware found under a forgotten desk for InterMapper Flows. Receiving and processing flows deals with summaries of large volumes of packets, so the collection and storage process will usually not be the bottleneck. At one customer, where traffic peaks up to 3Gbps, the server could process every packet on an off-the-shelf laptop, while still having plenty of CPU time to spare. However, handling queries (e.g., reading the saved data to send information to the GUI) is real work for the server. Depending on the selection criteria, the server sometimes must process millions of records to create the summaries and the graphs. This goes faster if more RAM memory is configured for caching session records. Queries going farther back in time will have to read the session records from disk with resulting slower times. For example, say you have a 200MBps border, with 15,000 hosts inside, all serviced by netflow-capable equipment. If you use InterMapper Flows only at the border router, a capable modern desktop, dual-core CPU, 4GBytes of RAM would do nicely. However, if you do decide to turn on NetFlow on each of 1000 Cisco devices throughout the network, you might need to get some serious hardware, with 4 CPUs, several fast disks, and 16GB RAM. Another alternative would be to run multiple InterMapper Flows copies, each monitoring a subsection of the flow exporters. Another factor is what the administrator wants to see. If they only want to see the last hour of data, then the desktop might do fine to monitor all 15,000 hosts. If they need the ability to go back in time regularly (to last week, or even last month) they would be looking at expensive, top-of-the-line server hardware.
They're similar, but slightly different: * A flow is a uni-directional transfer between a pair of (IP Address, Port) using the same layer-3 protocol, type of service, and input interface. * In InterMapper Flows, a session is a bi-directional transfer between a pair of (IP Address, Port). It is the sum of the flow from A to B, plus the flow from B back to A. * Other NetFlow products define a conversation different ways, either as a session, in the InterMapper Flows sense, or as a uni-directional flow.
The initial release of InterMapper Flows handles Cisco Netflow v1, v5, and v9 flow packets. InterMapper Flows 1.1 and later supports sFlow versions 2, 4, and 5. InterMapper Flows 1.2 and later support NetFlow version 7, as well as Cflow and J-Flow (from Juniper).
Check the user name and password in the Server Settings.
Check the Remote Server firewall settings in the Server Settings > Remote Server settings. The IP address or IP address range needs to be added to the firewall settings with the "Allow" attribute set.
There are two reasons you might see this message displayed: 1. If the InterMapper server is running on Windows, you will need to add an exception for the Remote Server on port 8181 in the Windows firewall > Exceptions settings on the server. 2. Check that the InterMapper service/daemon is running on the server.
Q. I am using InterMapper RemoteAccess to establish a connection to the InterMapper server that is in a remote location behind a firewall. The firewall is configured with port forwarding to route all traffic for port 8181 to the InterMapper server's IP address. When I try to connect, I receive an error that the 'InterMapper server is not available'. If I use a VPN connection, I am able to connect successfully. Is there a way to test whether I am actually connected to the InterMapper server? A. You can test the connection to the InterMapper server as follows: Use telnet to connect to the InterMapper server: telnet xx.xx.xx.xx 8181
Note that this doesn't work if you are using a secure protocol for the Remote server. For encrypted connections, use OpenSSL to connect to the InterMapper server: openssl s_client -connect xx.xx.xx.xx:8181 Paste the <KC_version id="0">0.9</KC_version> command and type Return. You should see a <KR id=xxx> response to indicate that the server is responding.
There are a number of things to do when you want to enable InterMapper's RemoteAccess Server. All these are controlled in the Server Settings window.
Be sure that external IP addresses are enabled:
InterMapper RemoteAccess stores its preferences in the following Windows Registry keys:
HKLM\SOFTWARE\JavaSoft\Prefs\com\dartware
HKCU\Software\JavaSoft\Prefs\com\dartware
The InterMapper RemoteAccess Preferences folder contains:
InterMapper RemoteAccess keeps its preferences with the other user preferences on each platform. That is:
Mac OS X:
~userhome/Library/Preferences/com.dartware.Intermapper.client
~userhome/Library/Caches/com.dartware.Intermapper.client (icons, sounds, certificates)
Windows Vista\2003\XP\2000:
C:\Documents and Settings\user\IMRemote\
Unix/Linux:
~userhome/.imremote/
The Internet Assigned Numbers Authority (IANA) has reserved several blocks of IP addresses that an organization may assign for its own private internet. These blocks are defined in RFC 1918, http://tools.ietf.org/html/rfc1918.
From the RFC:
10.0.0.0 - 10.255.255.255 (10.0.0.0/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16.0.0/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168.0.0/16 prefix)
InterMapper uses the Classless Inter-Domain Routing (CIDR) notation to represent IP subnet information. The number in the "/xx" shorthand stands for the number of bits set to one in the subnet mask. The convention is always to start at the left end of the 32-bit subnet mask. The table below shows the correspondence between the "/xx" notation and the actual numeric representation.
A subnet specifies a range of IP addresses. The special attribute of a subnet is that all the computers within the subnet (a "sub-network") can talk directly to each other, and don't need a router to communicate.
When it's time to send a packet, your computer delivers a packet a) directly to the destination computer or b) sends it to the router for ultimate delivery.
But how does your computer know whether the packet's destination is within its subnet? The answer is that your computer uses the subnet mask to determine the members of the subnet. If your computer's address and the destination computer's IP addresses are in the same subnet address range, then they can send packets directly to each other. If they're not in the same range, then they must send their data through a router for delivery.
The chart below associates the number of IP addresses in a subnet to the subnet mask. For example, the subnet mask "255.255.255.0" represents 254 consecutive IP addresses.
Computers send information through the Internet by dividing the data to send into small chunks ("packets") and transmitting them to the other device. All this happens without your doing anything - the web browser, e-mail program, etc. all take care of these low level details.
When your computer wants to send to another computer, it creates the packet, then places the other computer's address in the destination address of the packet, places its own address in the source address of the packet, and then sends the packet off, either directly to the destination computer, or to a nearby router that takes responsibility for routing the packet.
There's an analogy with the post office here. Packets are like envelopes, with destination addresses and return addresses. Routers are like post offices: they check the destination address and have the responsibility for delivering the packet to the final destination computer or to another router that's closer to the destination.
An IP address ("Internet Protocol address") is a number that represents a single unique computer on the Internet. IP addresses are similar to telephone numbers, in that each computer (or telephone) must have its own unique IP address (telephone number.) Like telephones, there's a directory system - called the Domain Name System, or "DNS" - that can convert a name such as "www.apple.com" into a corresponding numeric IP address.
IP Addresses are written as a sequence of four numbers separated by ".", like this: 208.123.246.35. Each of the four numbers in the IP address can take the value between 0 and 255.
Every computer on the Internet must have a unique IP address. ISPs purchase large blocks of consecutive IP addresses, and then allocate smaller ranges of these addresses to their customers. Thus, a particular company might be assigned all the 254 IP addresses in the range 208.123.246.1 to 208.123.246.254. (The addresses ".0" and ".255" are not usually assigned.) Companies then assign the IP address to individual computers within the organization.
SNMP stands for the Simple Network Management Protocol. At its heart, SNMP is a set of rules that allows a computer to get statistics from another computer across the Internet.
Computers keep track of various statistics that measure what they're doing. For example, routers can keep track of the number of bytes, packets, and errors that were transmitted and received on each interface (port). Web servers might keep a tally of the number of hits they have received. Other kinds of equipment have configuration information that's available through SNMP.
Each of these pieces of information (packet statistics, page hits, configuration) is kept in a database described by a Management Information Base (a MIB in SNMP parlance.) There are a many different MIBs, describing many different aspects of a computer's operation.
The various values that can be retrieved from a MIB are called MIB variables. These variables are defined in the MIB for a device. Each MIB variable is named by an Object Identifier (OID), which usually has a name in the form of numbers separated by periods ("."), like this: 1.3.6.1.xxxx.x.x.x.x...
For example, the MIB-II (pronounced, "MIB two") has a variable that indicates the number of interfaces (ports) in a router. It's called the "ifNumber", and its OID is 1.3.6.1.2.1.2.1.0
SNMP Watcher and InterMapper, as well as many other network monitoring tools, can query a device for the MIB variables and display the results. When a device receives a SNMP Get-Request for this ifNumber OID, it responds with the count of interfaces.
Note: The trailing ".0" in the example above is technically part of the OID. Although you will often see OIDs written without it, InterMapper requires that it be present wherever you enter an OID.
The SNMP Read-Only Community String is like a password. It is sent along with each SNMP Get-Request and allows (or denies) access to device. Most network vendors ship their equipment with a default password of "public". (This is the so-called "default public community string".) Many network administrators will change the community string to keep intruders from getting information about the network setup. This is a good idea. Even if it's only read-access, SNMP can divulge a lot of information about the network that could be used to compromise it.
If there's a "read-only community string", you might expect that there is a"Write community string". You'd be correct. There is also a SNMP Set-Request, which is a command to set certain SNMP MIB variables (e.g., certain OIDs) to a specified value. These writes are protected by the write community string (which should never be set to 'public'!). Many SNMP-speaking devices also have IP address filters that ignore requests (read and write) unless the source address is on an access list.
There's also a SNMP Trap, which is an unsolicited message from a device to an SNMP console (for example, InterMapper) that the device is in an interesting state. Traps might indicate power-up or link-up/down conditions temperatures exceeding certain thresholds, high traffic, etc. Traps provide an immediate notification for an event that might otherwise be discovered only during occasional polling.
InterMapper requires that SNMP be available and configured to display traffic information. The most common cause of not being able to see traffic is that you haven't entered the SNMP Read-only community string. (This is like a password that controls whether another computer can retrieve SNMP information.)
In order of simplest to most complex, here is a list of reasons that InterMapper might not get SNMP information from a device:
Firewalls can interfere with InterMapper's traffic.
Does a firewall block the SNMP port between the InterMapper server and the equipment?
Certain firewalls may also block SNMP packets if it suspects that those packets are part of an attack. InterMapper may send and receive all its SNMP queries on the same port and after awhile the firewall may detect this.
Bugs in the SNMP agent on the equipment - InterMapper uses SNMP Get-Next-Requests in several places. We've seen certain equipment that fails when queried this way.
If you're sure that you've checked all these things and you still can't get SNMP information, please contact us. We may have some tricks up our sleeves. (Or we may wind up learning something!)
There are two kinds of MIB variables: scalar values and table entries.
Scalars have a single value, such as the interface number shown above. For example, the ifNumber MIB variable of a router is a single number that represents the total number of its interfaces (ports).
Table values, on the other hand, provide the same pieces of information for different items, such as the traffic for each of a router's ports, or information about each of the TCP connections in a device.
InterMapper can read and display both scalar variables and table variables in its custom SNMP probes.
Scalar values must have a ".0" suffix in their OIDs. For example, the OID for ifNumber in MIB-II is often written as "1.3.6.1.2.1.2.1". In custom probe files, it should be represented as "1.3.6.1.2.1.2.1.0". (This ".0" is technically part of the OID - it's convenient not to write it, though.)
Table variables are generally suffixed with the index of the row. (This isn't always true: see the note below). For example, the Cisco Environment Monitoring MIB defines two variables for the input air temperature and input voltage as the first rows in each of these tables:
ciscoEnvMonTemperatureStatusValue 1.3.6.1.4.1.9.9.13.1.3.1.3 ciscoEnvMonVoltageStatusValue 1.3.6.1.4.1.9.9.13.1.2.1.3
If you add a suffix ".1" to each of these, you'll get the value of the first row; add ".2" to as a suffix, you'll get the second row, etc.
As noted above, some tables don't have a separate index column. These rows are named (their OIDs are specified by) data in the row. For example, the OID for tcpConnState row, the status of a particular TCP connection is "1.3.6.1.2.1.6.13.1.1". Its index is the source and destination IP address and port (all four values) which are appended to the tcpConnState OID. Thus, the full OID for the state of a TCP connection from 9.8.7.6 port 543 to 123.45.67.89 port 8765 would be:
1.3.6.1.2.1.6.13.1.1.9.8.7.6.543.123.45.67.89.8765
Here's a great site to start learning about MIBs and all the cool things you can do with them:
http://www.snmpworld.com/
A great site pointing to various snmp products:
http://www.simpleweb.org/
MIB Depot is a huge source of standard and vendor MIBs.
http://www.mibdepot.com
No. Dartware has tested its InterMapper and SNMP Watcher software against the test suite mentioned in CERT Advisory CA-2002-03. Neither of our packages are vulnerable to this attack. See our Vendor Statement.
If your error log file shows the following lines:
14/02 15:13:07 TRAP CITRIX1:: coldStart14/02 15:13:07 TRAP CITRIX1:: linkUp, ifIndex = 114/02 15:13:07 TRAP CITRIX1:: linkUp, ifIndex = 1677721914/02 15:14:07 TRAP CITRIX1:: 1.3.6.1.4.1.3845.3.1.1 (8) { <no variables> }
The SNMP id is (1.3.6.1.4.1.3845.3.1.1 (8))
The "1.3.6.1.4.1..." prefix of the OID indicates that the trap is from a private enterprise MIB. You can find out what enterprise by downloading the Enterprise Numbers RFC from:
http://www.iana.org/assignments/enterprise-numbers
Reading through the file indicates this:
3845 Citrix Systems Keith Turnbull keitht@citrix.com
You should contact the Citrix company (or read their MIB) to find out the exact interpretation of the trap's OID.
InterMapper will do a very good job of finding SNMP-speaking devices if you know the devices' SNMP Read-only Community string. Detailed instructions for scanning a subnet are available from the network scanning page. Be sure to set the default SNMP Read-only Community String as shown in the SNMP Preferences.
However, InterMapper may not be able to find a device for any of these reasons.
Customers have sent us comments that InterMapper won't show certain kinds of equipment properly. We have investigated, and found a bug in the SNMP implementations of certain vendors. To determine if your equipment is susceptible to this bug, you may follow this procedure.
InterMapper uses Get-Next-Requests to retrieve data. To be more efficient, it sends several OIDs in each query. When we use the net-snmp "snmpgetnext" to retrieve single variables, the results come back properly. When we queue up multiple OIDs in a request, they come back wrong, in the same manner as SNMP Watcher.
First, download net-snmp from http://net-snmp.sourceforge.net. net-snmp is a highly-reliable, open-source snmp query tool and agent for Unix and Windows. Install net-snmp as described in its documentation.
Then use net-snmp's command-line tools to send Get-Next-Request queries to the device in question. For example:
# request ipAdEntAddr first, then ipAdEntifIndex [richb@jig ~]# snmpgetnext IPADDRESS COMMUNITY ipAdEntAddr ipAdEntifIndex ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = Wrong Type (should be INTEGER): IpAddress: 127.0.0.1 # other order: ipAdEntifIndex, then ipAdEntAddr [richb@jig ~]# snmpgetnext IPADDRESS COMMUNITY ipAdEntifIndex ipAdEntAddr ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = Wrong Type (should be IpAddress): 1
In the examples above, snmpgetnext requests two variables from the device at IPADDRESS, using the SNMP Read-only community string of COMMUNITY (you should substitute your values as needed). In the first case, the entity's address comes before the ifIndex in the query. Note that both responses have the value 127.0.0.1 (the latter is incorrect). In the second example, the ifIndex precedes the entity's address, and the result is "1" (again, the latter is incorrect).
If you see results like this, you should contact the vendor of your equipment to explain this problem and ask if a new release of firmware has fixed it.
Microsoft's Windows Internet Naming Service (WINS) is a name resolution service that resolves computer names to Internet Protocol (IP) address. Using WINS, the computer name can be resolved to a specific IP address.
InterMapper uses WINS names as follows:
InterMapper (all platforms) queries devices for a NetBIOS (WINS) name. This name is used as the device's smart name if the DNS name is unknown or contains the word "DHCP".
When adding a device that is in the same LAN as InterMapper server, you can use the device's NetBIOS/WINS name. To cause a name to be treated as a WINS name, place "\" in front of the name when adding a device. The name is not looked up in the DNS.
Note: Intermapper does not use the WINS server - it only resolves local device names.
InterMapper uses two different DNS resolvers. When you add a device using the Add Device... command, InterMapper uses the system's resolver. When InterMapper is monitoring DNS names and addresses as part of the "DNS Check" feature, InterMapper does its own DNS operations, via UDP packets, to the domain name servers listed in InterMapper's own DNS Monitor Preferences panel. InterMapper's built-in domain name resolver currently assumes that the domain name is fully-qualified. For each domain name, the interval for double-checking the domain name is determined by the TTL in each DNS response (with the minimum interval controlled by the DNS Monitor prefs panel).
When you discover devices, InterMapper initially looks up the FQDN name from the IP address (address --> name), then it settles down to monitoring the domain name (name --> address). InterMapper's built-in DNS resolver doesn't handle partially qualified domain names or things that aren't really domain names; hence, they will fail to resolve.
From the Edit menu, you can choose the Set Info submenu, then choose Set Address... to change the DNS option for each affected device from Resolve name to address to Resolve address to name. With this setting InterMapper always resolves the address to a name, and you don't see errors with names that aren't fully-qualified domain names.
This is an acronym for a "Fully-Qualified Domain Name." Within an organization, it's convenient to refer to a computer by the first part of its name, knowing that "everyone" will know that the remainder is the same as the other computers in the organization. Thus, you may speak of "sneezy" and "dopey", knowing that they're really two computers at "seven-dwarves.org".
But computers need the fully written-out name (the FQDN), such as "sneezy.seven-dwarves.org." or "dopey.seven-dwarves.org." to identify a computer. Most user software has the ability to add a "search domain" to all partially-qualified domain names, filling out the missing part of the FQDN. But some DNS servers require the FQDN to work properly with InterMapper. To be safe, it's always correct to enter the full domain name.
Tip: Even though you enter a FQDN when specifying a computer, you can use the Short, Smart Name when constructing a label for a device.
Tip: Technically, a FQDN requires a "." at the end. Just as the search domain is tacked onto the end of a partial domain name, most user software adds the trailing "."
