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.
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:
The ports that InterMapper uses are:
161 - SNMP 162 - SNMP traps (only if this is enabled in the Server Settings) - can be changed in the Server Settings 23 - Telnet (only if this is enabled in the Server Settings) - can be changed in the Server Settings 80 - Web Server (only if this is enabled in the Server Settings) - can be changed in the Server Settings 8181 - RemoteAccess (can be changed in the Server Settings)
If two devices are added to two different maps, and they 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. Identical devices 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.
Please refer to this URL:
http://www.intermapper.com/products/intermapper/features/163-sql-database-and-reporting
Here is the answer.
In the Add Device(s)... window, enter the IP address or DNS Name of one or more of your routers/switches. Click Choose... and select the SNMP MIB-II probe type. Enter the SNMP version and the community string or authentication information. The devices will be added to your map, and their interfaces will be shown. InterMapper will query all the interfaces and collect traffic statistics.
Use the context menu to show the Status Window for a summary of the traffic on the interfaces. You can also create strip charts to keep a history of the traffic or any underlined value in the Status Window.
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.
There's a problem with the subnet mask reported by the device. The /2* indicates that the subnet mask has zero bits in the host part.
The Server Information pane of the Server Settings window shows the number of devices you are monitoring.
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.
Read the Enabling NetFlow on Cisco Equipment tech note for details on using IOS to configure Cisco gear.
The Cisco white paper NetFlow Performance Analysis contains a list of Cisco equipment that supports NetFlow. We have reproduced it here:
For the following selection of routers, tests were performed using Cisco IOS Software Release 12.0S. The platforms and configurations tested include:
For the following selection of routers an enhanced selection of tests were run using Cisco IOS Software Release 12.4T:
Yes. There are software-only NetFlow exporter packages. Some customers have used both the nProbe and softflowd packages with InterMapper Flows. Read the Configuring the nProbe NetFlow Exporter and Configuring the Softflowd NetFlow Exporter tech notes for an overview of the installation and configuration process.
Beginning with version 1.1, InterMapper Flows supports sFlow (sampled flow) data from HP, Extreme, Foundry, Force10 and other network equipment. sFlow provides information about the traffic through the network, including the sender and recipient of the traffic flows as well as the protocols involved. Read the Using InterMapper Flows with sFlow tech note for instructions on configuring InterMapper Flows to receive sFlow data.
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 — a NetFlow collector to be saved and analyzed.
In general equipment from the following vendors support sFlow. Some can be enabled through the built-in InterMapper Flows SNMP facility, others require CLI access to enable sFlow.
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.
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 — a NetFlow collector to be saved and analyzed.
A flow is a measure of data transferred between two particular hosts. It consists of all the traffic for a period of time that has these same characteristics:
They're similar, but slightly different:
InterMapper Flows uses a heuristic rule to determine whether a host is operating as a client or server:
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.
An InterMapper Flows chart can conceptually be seen as a bunch of buckets. These buckets are filled with sessions from the database. Since routers report sessions as a sequence of (start time, stop time, data volume) data points, it is not possible to know exactly how the transfers were distributed over the timeframe of the sessions. For instance, a webpage typically has the bulk of the traffic at the beginning of the session (when you load the page), and then very little the rest of the session (as you're reading it). This information is lost at the router level, before it reaches InterMapper Flows.
To better understand what happens in the charts, imagine each chart only consisted of 10 buckets. A chart that shows 10 minutes would divide all traffic into 1 minute buckets. This means that a session with a short, high spike will be "smoothed" out into a single-minute chunk. This has the effect of flattening the spike out.
When you drag across the chart to zoom into that minute, InterMapper Flows does something no other software does. It divides the new timeframe into another 10 (actually it's about 200) new buckets, which are then conceptually only 6 seconds wide. The spike will now be much more pronounced, as it falls in a much shorter timeframe, and its true height is much more accurate.
What happens here actually occurs with any network monitoring product. The reason you don't detect this elsewhere is that you generally cannot zoom in to get a more accurate view.
This is the same effect as the previous question. When you recenter, some larger flows will fall a little bit more in one bucket, and a little less in another. That can affect the peaks somewhat, although it shouldn't be very drastic.
The NetSAW server estimates the number of flows it will load into its cache, based on the flowrate that's learned from the actual records in the DB. Since this estimate is never perfect, you'll sometimes notice that the actual number of records exceeds the estimated records. Other times it'll fall short and finish early.
There are several sets of information available:
The Copy to Clipboard button of the About window collects a great deal of relevant information about the configuration of InterMapper Flows. You can paste this into an e-mail or a bug report (Help -> Report a bug...)
InterMapper can provide some debug information via the Telnet server. To do this, turn on the Telnet server in the InterMapper Settings. Then telnet to the InterMapper server and use the "flows" command to list the exporters that InterMapper knows about. Use the "ext" command to check that InterMapper has its own connection to the IMFlows server. You can copy/paste the output of these two commands into a bug report (Help -> Report a Bug...).
Yes, InterMapper Flows will work on any link where there's an "exporter" (the router/switch) to keep track of the traffic statistics. Many kinds of Cisco equipment can export flow records that summarize the data flowing through that device.
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).
It is easy to set up your Cisco gear to send flow records, so you can see the effect on the traffic. We have written a brief document at this URL that describes the commands:
Enabling NetFlow on Cisco Equipment
No. In our first release, all the flow records are must be sent to one InterMapper Flows machine (the "collector"). You can have multiple exporters sending flow records to the single collector, though.
The following features are not available in InterMapper Flows version 1.0. If you would like to help us design these features or suggest other capabilities, please contact support@dartware.com
InterMapper Flows 1.0 works with Cisco NetFlow versions 1, 5, and 9. InterMapper Flows 1.1 supports sFlow versions 2, 4, and 5. We will implement other protocols (cFlow, jFlow, IPFIX, others) as we get customer demand.
Not in version 1.0. We plan to make the charts/graphics and the table data available via a web GUI/API in a future version.
Yes. InterMapper Flows uses a high-performance database optimized to store hundreds of thousands of sessions. There is currently no public API for accessing the data.
Not in version 1.0. This will be added in a future version.
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/
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:
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 is 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.
As mentioned above, your computer delivers a packet directly to the destination computer or 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.
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. If your computer's IP 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.
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 "."
