InterMapper: Real-time Network Knowledge
Facebook Twitter
877.276.6903 | info@intermapper.com
 

Frequently Asked Questions

Categories of FAQs

The InterMapper 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.

FAQ InterMapper (15 Articles)
FAQ InterMapper Flows (17 Articles)
FAQ InterMapper RemoteAccess (7 Articles)
FAQ IP Address (5 Articles)
FAQ SNMP (10 Articles)
FAQ WINS Names (1 Articles)
FAQ DNS (3 Articles)
FAQ Multiple InterMapper Servers (8 Articles)


FAQ InterMapper

  • Why is my evaluation only able to monitor 25 devices?

    It can monitor more! The web download licence is limited to 25 devices. To obtain a key that can monitor your entire network please contact us for a full key. Email sales@intermapper.com and we will contact you.

  • Where do I register my InterMapper license?

    Edit > Server Settings > Server Information > Registration

  • Monitoring devices on multiple maps. How does that affect the license?

    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.

  • How do Vantage Points/Dependencies work?

    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.

  • How can I migrate InterMapper to a new server?

    In order to move InterMapper to another server, please follow the platform-specific instructions below:

    Ensure an active license key:

    Your InterMapper license key is limited to one activation. To obtain a new key, please contact sales@intermapper.com to obtain a key that will activate on your new server.

    Migrating to Mac OS X:

    1. Stop the InterMapper service/daemon on the old server and copy the InterMapper Settings folder to the /Library/Application Support folder on the OS X machine. Note: If you transfer the InterMapper Settings folder using FTP, ensure that the transfer is made in BINARY mode. Some FTP servers default to TEXT mode if BINARY mode is not explicitly set, and that can result in file corruption.
    2. Install InterMapper on the new server.

    Migrating to Windows/Linux:

    1. Install InterMapper on the new server, and stop the InterMapper service/daemon when installation is complete.
    2. Stop the InterMapper service/daemon on the old server and copy your InterMapper Settings folder to the new platform, replacing the one created when you installed InterMapper on the new server. Note: If you transfer the InterMapper Settings folder using FTP, ensure that the transfer is made in BINARY mode. Some FTP servers default to TEXT mode if BINARY mode is not explicitly set, and that can result in file corruption.
    3. If the new server is Linux, ensure that you set the file ownership of the InterMapper_Settings folder, using the /sbin/chown command:
      /sbin/chown/ -R <user> InterMapper_Settings
      In the above command, replace <user> with the desired InterMapper user name, which in most cases is 'intermapper'.
    4. On the new server, start the InterMapper service/daemon.

    The default location for the InterMapper Settings folder depends upon the platform where installed:

    • Mac OS X: /Library/Application Support/InterMapper Settings
    • UNIX/Linux: /var/local/InterMapper_Settings
    • Windows:

    InterMapper 5.5 and later
    Vista and beyond
    C:\ProgramData\InterMapper\InterMapper Settings
    (Note: Windows hides this folder by default)
    InterMapper 5.5 and later
    Windows XP and Server 2003
    C:\Documents and Settings\All Users\Application Data\InterMapper\InterMapper Settings
    Pre InterMapper 5.5
    All Windows version
    C:\Program Files\InterMapper\InterMapper Settings

    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:

    http://download.dartware.com/thirdparty/convert_chart_data.zip

    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: Ensure the InterMapper server is connected to the network before starting InterMapper.

    Note: If you also need to move the InterMapper DataCenter, please follow the instructions in this Knowledge Base entry:

    http://forums.dartware.com/viewtopic.php?t=332

    Note: If you also need to move InterMapper Flows to a new server, please follow the instructions in this Knowledge Base entry:

    http://forums.dartware.com/viewtopic.php?t=588

  • What ports does InterMapper use?

    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.
  • Reporting with InterMapper

    Does Intermapper provide any type of reporting functionality?
    See these URLs to see the different ways to view data about your network.

    SQL Database and Reporting

     

    Creating & Using Strip Charts (pg. 169 of InterMapper User Guide)
    http://download.dartware.com/docs/InterMapper_User_Guide.pdf

    InterMapper Flows (pg. 257-259 of InterMapper User Guide)
    http://download.dartware.com/docs/InterMapper_User_Guide.pdf

  • How can I find out how many devices I'm monitoring with InterMapper. Do I have to count all the boxes on each map?

    The Server Information pane of the Server Settings window shows the number of devices you are monitoring.

  • Alerts for the link utilization

    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.

  • Google Earth HowTo?

    There are two ways (or both on the same)

    1. Set individual lat/long on each device
    2. Set two 'benchmarks' on the map.

    Read the full forum article.
    Read about using geographic coordinates in InterMapper

  • Some network ovals have more than one IP network number...

    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 ( info@intermapper.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.

  • There are two separate network ovals on my map where I only expect one...

    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.

  • Why won't a device connect to the proper subnet oval?

    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.

  • Uninstall InterMapper from OSX

    The easiest thing to do is to run the installer again. On the first screen, you will see "To remove the InterMapper software, use the Uninstall InterMapper program located here." Click on "here", and it will reveal the uninstaller. Once you've run that, all binaries should be stopped and removed. It will leave behind the InterMapper Settings folder (so that you don't lose your configuration if you're planning to install another version.) To get rid of that, go to "/Library/Application Support" and throw the "InterMapper Settings" folder in the trash.

    Note: The Uninstall InterMapper program does not support 10.3.9 or earlier versions of OS X. You should manually uninstall InterMapper from these systems, as follows:

    Open the Terminal application and type:

    sudo/usr/local/share/intermapper/Uninstaller.sh

  • How to Create a Custom SNMP Probe

     

    Custom Probes provide a mini-report of the current status of a device. InterMapper retrieves certain data values from the device being tested, then displays the results in a Status Window. In addition, you can establish thresholds, and have InterMapper send alerts when the collected data value(s) fall outside those thresholds.

    Three Important Questions

    Before you begin to write an InterMapper probe, you should think about your equipment and how you want to test it:

    • What data values do you want InterMapper to retrieve? List the operational parameters that InterMapper will monitor and use as the basis for its alarms.
    • What limits/thresholds do you want to compare the values to? These are the high/medium/low settings against which InterMapper will compare the retrieved data.
    • How do you want to see the information displayed in the device's Status Window? Sketch out (even on paper) the order/placement of the data that is important to you.

    Once these answers are in hand, you've completed the design of the probe. Next, you need to retrieve the desired information from the device.

    For SNMP-speaking device, you'll need to know the SNMP OIDs ("Object IDentifiers") that correspond with the desired data values. The OIDs are defined in a MIB file that you can generally get from the vendor's web site or other MIB repository. (See below for various sources of MIBs.)

    You will also want a MIB browser program (see below) to make sense of the MIB. This will show the OIDs for the desired values, as well as their definitions and data formats.

    Getting Started

    Writing Custom SNMP probes for InterMapper is straightforward, and follows this basic process:

    • Start by making a probe using the Interactive Probe Builder. This creates a text file that you can save to your hard drive.
    • You can then import this file into InterMapper.
    • If you wish to make changes to the probe, you can edit the text file and re-import it.

    Each time you reprobe a device, InterMapper will retrieve the data values you specified (in the OIDs) and compare those values your thresholds. This will determine the status of the device (OK, warning, alarm, or critical state, etc.) Finally, InterMapper will format the data in a Status Window as specified in the probe.

    Each probe file has "sections" into which you enter the kinds of information listed above.

    • <snmp-device-variables> section: a place to enter the OIDs that you want to retrieve
    • <snmp-device-thresholds> section: a place to compare the retrieved values to your limits/thresholds
    • <snmp-device-display> section: a place to format the displayed values for the Status Window

    Read more about probe sections. These sections are further defined in the online InterMapper Developer Guide.

    After you've filled in these sections of the probe file, save it in the InterMapper Settings/Probes folder (be sure to change the file name to something unique), then Reload Probes to make it available to InterMapper. Use Set Info... -> Set Probe... to select your new probe.

    Once you've imported the probe, you can edit it with your favorite text editor, save the changes, Reload Probes, and you should see the changes reflected.

     



FAQ InterMapper Flows

  • What is NetFlow?

    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.

  • What is a flow?

    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:

    • Same Source IP address and port
    • Same Destination IP address and port
    • Same layer-3 protocol type (TCP, UDP, ICMP, etc.)
    • Same ToS (type of service)
    • Same input logical interface (e.g., ifIndex)
  • Where do I register the Flows license key?

    Open the InterMapper Flows window.

    Click on the Settings button (the gear at the upper right hand corner)

    Click the Registration Tab and then click Update License.

    Paste in the entire two lines and click ok

  • Cisco devices that support NetFlow.

    Almost all Cisco devices support NetFlow since its introduction in the 11.1 train of Cisco IOS Software and because of this, NetFlow is most likely available in any devices in the network. For specific information about your equipment, you can do a web search for "cisco model-number netflow".

    Cisco has written a white paper that has a list of Cisco equipment that supports NetFlow. Click on the URL to see the whole white paper.

     

  • Enabling NetFlow on Cisco equipment

    NetFlow provides detailed information about the sources and destinations of traffic flows on their network. InterMapper Flows acts as a NetFlow collector to receive the exported flow information and display it in an attractive user interface.

    Cisco has written a white paper that has a list of Cisco equipment that supports NetFlow.

    The Cisco Netflow Configuration Guide gives a detailed description of configuring Cisco gear. The section on NetFlow (URLs below) gives details on configuring NetFlow:

    Quick Guide to Configuring NetFlow

    As a quick guide, the following commands will generally configure a Cisco router or switch to send NetFlow "flow records" to InterMapper Flows. In this example, we configure:

    • NetFlow destination: the IP address/host name and the port of InterMapper Flows that will receive the flow records.
    • NetFlow source: is the IP address of the exporter itself, specified by the interface to be used. Flow records will appear to come from this source address; InterMapper Flows will show this as the address of the exporter.
    • NetFlow version: generally version 5 or 9. Version 7 is only for older Catalyst switches; version 1 is considered obsolete.
    • NetFlow timeouts: the router/switch will accumulate active and inactive flow information for the timeouts indicated, then forward the flow records to the specified destination.
    • Interfaces: You must configure every interface you want to report flow information with the ip route-cache flow command. The example shows Ethernet0 and Ethernet1 (eth0 & eth1).
    % telnet 192.168.1.1 <== telnet to the router/switch
         Trying 192.168.1.1...
         Connected to 192.168.1.1.
         Escape character is '^]'.
         User Access Verification
         Password: Kerberos: No default realm defined for Kerberos!
         <== Type router password here
         cisco2514> enable
         Password: <== Type router password again
         cisco2514#configure terminal
         Enter configuration commands, one per line. End with CNTL/Z.
         cisco2514(config)#ip flow-export destination IP/host port <== e.g., 192.168.1.5 2055 or nf.example.com 2055
         cisco2514(config)#ip flow-export source interface  <== e.g., Ethernet0 will be the "source"
         cisco2514(config)#ip flow-export version #  <== e.g., 1, 5, 7, or 9
         cisco2514(config)#ip flow-cache timeout active 1  <== Active flows time out in 1 minute
         cisco2514(config)#ip flow-cache timeout inactive 15 <== Inactive flows time out in 15 seconds
         cisco2514(config)#int eth0
         cisco2514(config-if)#ip route-cache flow
         cisco2514(config-if)#exit
         cisco2514(config)#int eth1
         cisco2514(config-if)#ip route-cache flow
         cisco2514(config-if)#exit
         cisco2514(config)#^Z  <== Type Control-Z here
         cisco2514#write
         Building configuration...
         [OK]
         cisco2514#exit
         Connection closed by foreign host.
         %
         

     

    Checking NetFlow Configuration

    You can use the following commands to check the NetFlow configuration. The show ip flow export command shows that NetFlow version 5 records are being sent from the source address of Ethernet0 to on port 2055.

    cisco2514#show ip flow export
         Flow export is enabled
         Exporting flows to 192.168.1.45 (2055)
         Exporting using source interface Ethernet0
         Version 5 flow records
         Cache for as aggregation:
         Exporting flows to 192.168.1.45 (2055)
         18911421 flows exported in 676473 udp datagrams
         0 flows failed due to lack of export packet
         357386 export packets were sent up to process level
         0 export packets were dropped due to no fib
         0 export packets were dropped due to adjacency issues
         0 export packets were dropped due to fragmentation failures
         0 export packets were dropped due to encapsulation fixup failures
         

     

    The show ip cache flow command shows information about the flows themselves, including the distribution of the packet sizes, number of flows seen, lost flow packets, and other statistics.

     

    cisco2514#show ip cache flow
         IP packet size distribution (55479535 total packets):
         1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
         .000 .882 .017 .023 .000 .001 .000 .001 .007 .011 .000 .000 .000 .000 .000
         512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
         .000 .000 .003 .000 .051 .000 .000 .000 .000 .000 .000
         IP Flow Switching Cache, 278544 bytes
         189 active, 3907 inactive, 18842664 added
         428276059 ager polls, 0 flow alloc failures
         Active flows timeout in 1 minutes
         Inactive flows timeout in 15 seconds
         last clearing of statistics never
         Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
         -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
         TCP-Telnet 23 0.0 108 40 0.0 26.0 12.3
         TCP-FTP 770 0.0 12 63 0.0 0.1 6.1
         TCP-WWW 40186 0.0 12 937 0.2 9.7 15.4
         TCP-SMTP 2197 0.0 4 210 0.0 9.8 14.6
         TCP-other 3939 0.0 956 1026 1.6 6.8 9.1
         UDP-DNS 9151 0.0 1 100 0.0 2.4 15.4
         UDP-NTP 380 0.0 1 76 0.0 1.3 15.5
         UDP-TFTP 17768 0.0 1 70 0.0 2.2 15.5
         UDP-other 1663272 0.7 2 177 1.6 2.2 15.4
         ICMP 17104789 7.5 2 48 20.8 5.3 15.5
         Total: 18842475 8.2 2 131 24.3 5.0 15.4
         SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
         Et0 192.168.1.23 Null 192.168.1.255 11 F1CB 00A1 2
         Et0 192.168.1.45 Et1 10.10.1.25 01 0000 0800 1
         Et0 192.168.1.45 Null 10.10.1.21 01 0000 0800 2
         Et0 192.168.1.45 Et1 10.10.1.23 01 0000 0800 2
         ... etc...
         

     

  • What are NetFlow exporters and collectors?

    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.

  • How do the NetFlow exporters and collectors work?

    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.

  • Where should I place flow exporters?

    Placement for the maximum benefit from flows exporters depends on what traffic you want to examine. If you want to see who on the local network is connecting with on the outside, an edge router or switch is usually best, although many firewalls are also capable of providing useful data. Internal traffic can be seen by looking at flows generated by a device on the network backbone.

    The other consideration is the flows exporting capability of the devices on your network, since not all devices support flows exports. This is a fairly recent service as compared with SNMP, for instance, and is typically supported on higher-end equipment. Summarizing the data passing through a device by dissecting the packet headers, then summarizing and exporting the results can be pretty intensive, resource-wise.

    It is possible to mirror traffic traversing a network device out of a mirror or span port and use a dedicated host connected to that running a flows-exporter application to generate the exports, if needed.

  • I am not seeing any Flows information in the Flows window

    1. First, check the firewall settings to make sure the correct ports are open.
      • 2055 - NetFlow
      • 6343 - sFlow

    2. Which type of Flows is being used?
      • Netflow
      • sFlow
      • jFlow
      • cFlow
      Which version?
    3. Which OS are you using?
    4. What kind of exporters are you using? Manufacturer/model?
    5. If not seeing data and exporters are configured, open the Flows Settings > Exporters window.
      Are any exporters listed there?
    6. If there are exporters listed in the Flows settings but no data is displayed:
      • - Get the 'Copy to Clipboard' output from the
        Flows settings > About tab
      • - Note which exporters and host filters that are being used
      • - Include a screenshot of the Top Hosts window
      • - Send to support@intermapper.com
  • Not Seeing Netflow Data on a Cisco ASA Firewall

    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: [URL]

    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.

    This means that NetFlow Secure Event Logging (NSEL) sends a flow record when a flow begins, when (if) a flow is denied, and when the flow is torn down. There are no intermediate flow records to show the progress of a transfer.

    Consequently, the NetFlow information will not be useful for long-duration flows, as there will be a huge spike in traffic shown at the end, with no traffic in the middle.

    *** Perhaps using a software exporter and a managed switch as a network tap could offer a solution. (see other FAQs)

  • What if I don't have Cisco/NetFlow-compatible Equipment? Use a Managed Switch as a Network "Tap"?

    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

    Read a Blog post on this topic

    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/resource/free-flow-exporter

  • How much bandwidth will NetFlow consume?

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

  • Server load and memory usage.

    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.

  • Can InterMapper Flows be installed on a different server than the InterMapper program?

    Yes. InterMapper and InterMapper Flows do not need to run on the same server. In fact, this may be necessary when InterMapper Flows is handling a lot of flow data. You can leave the InterMapper server running on its current hardware and use a higher performance system for the NetFlow analysis.

    The two servers communicate through a TCP connection. They default to connecting through localhost, but this can be changed via modifying two configuration files. You need to do the following:

    • Install InterMapper Flows on the InterMapper server. It can have a very small database size - this is only to get the proper files installed on that server. You will not need a serial number for it, as it will not be "in production." You can even stop the service/daemon by following the instructions on the ReadMe page.
    • On the InterMapper server, configure InterMapper to connect to the Flows server's IP address. To do this, edit the InterMapper Settings/Extensions/netsaw.xml to have an "address=" line, as shown:, where xxx.xxx.xxx.xxx is the address of the IM Flows server:

    • <extensionlist>
         <extension
           id='com.dartware.intermapper.flows'
           name='InterMapper Flows'
           client='netsaw.jar'
           address='xxx.xxx.xxx.xxx'
           port='8184'
           version='build????' >
            <netflowcontext
              name='NSPluginIMFlows'
              class='com.proquesys.netsaw.remote.NSPluginIMFlows' />
         </extension>
      </extensionlist>


    • Install InterMapper on your separate server. Configure Flows for a large database size.
    • On the InterMapper Flows server, edit the /ns2flows/netsaw.conf file to allow InterMapper Flows to accept connections from external servers. Add this line near the bottom (but above the "# EOF" line) of the netsaw.conf file: 

      localhostonly no
  • What is the difference between a flow, a conversation, and a session?

    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.
  • What versions of NetFlow are support by InterMapper Flows?

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

  • Troubleshooting Flows sources

     

    The most common cause of missing flow traffic is a firewall blocking the ports needed to receive flow updates.

    The firewall may be somewhere on the network or on the FlowTraq host itself. Most systems have host-based firewalls configured to block inbound traffic on certain ports. On some versions of Windows, Windows Firewall blocks flow ports by default; RedHat Enterprise Linux and CentOS also ship with a firewall configured by default. Take a look at your firewall configuration to see if you might have this problem.

    Make sure that traffic on UDP/2055 (NetFlow/IPFIX), UDP/9666 and UDP/9996 (cFlow/jFlow), UDP/6343 (sFlow), and any other ports on which you configured flow collection can reach FlowTraq Server.

    FlowTraq is unable to bind the required ports
    FlowTraq Server will not be able to collect any flow data if another flow collector is running on the same system because it will be unable to bind the required listen ports.

    The netstat tool can tell you which process id or executable has the required ports bound. On UNIX hosts (including Mac OS X),

     # netstat -a -p or, on Windows,

     # netstat -a -o -b will, if run with admin permissions, show which processes have bound which ports.

    If a process other than flowtraq has bound the required UDP ports, you will need to shut down that process or reconfigure both FlowTraq and your NetFlow exporter to use a different port.

    Significant system time skew between Client and Server
    If FlowTraq Client is running on a machine with a significantly different system clock time than the host running FlowTraq Server, a query for a recent time frame can cause the server to try to fetch sessions that it considers to be in the future or far in the past. In either case, the result set might be empty.

    If the cross-hatch area in the graph is covering the entire screen, as pictured below, the client clock is in the future compared to the server clock:
    Time skew between Client and Server

    If the cross-hatch area is not showing at all, the client is in the past:
    Client in the past

    In either case, try moving or extending your time selection back or forward in time until you see a graph showing sessions.

    We strongly recommend remedying time skew issues by adjusting system clocks; otherwise, alerts and reports may be also misconfigured. If clocks are aligned, the cross-hatch area should occupy a thin strip on the right only:
    Clocks aligned

    "Template Not Found" (NetFlow v9 and IPFIX only)
    The NetFlow v9 and IPFIX formats use a template-based system where the flow export datagram format is described by a template. This format can differ from exporter to exporter, and each exporter will publish a template record approximately every 10 minutes. The collector determines how to parse the NetFlow v9 datagrams from that particular exporter based on the published template. It is possible that flow records are arriving, but no template has yet been seen; in this case, FlowTraq must ignore the records until it receives a template in order to avoid interpreting a record incorrectly. In some cases it might take up to 20 minutes before a template is received.

    Check the Exporters tab in the configuration panel. If your NetFlow v9 or IPFIX exporter is shown there, it has successfully sent traffic to FlowTraq Server. However, it may still be waiting for a template record, and until that time, no sessions will appear.

    Incorrectly Configured Exporter
    It is possible that the configuration on your exporter is incorrect. For instance, you may have mistyped the destination IP or port, or enabled flow on an unused port.

    To verify that your exporter is working correctly, capture some traffic on the host running FlowTraq Server and confirm that flow traffic is arriving at the expected port.

    On Unix systems (including Mac OS X), you can use the following tcpdump command to capture UDP/2055 traffic on the interface called IFACE (typically, eth0 or en0):

     # tcpdump -i IFACE port 2055 (You may need to use the ifconfig command to determine which interface to capture on.)
    Which interface to capture on

    On Windows systems, we recommend the open-source packet-capture software Wireshark for this purpose. Wireshark is available at http://www.wireshark.org/.

    Unsupported Protocol (IPFIX only)
    FlowTraq currently supports IPFIX over UDP, and will not recognize IPFIX over TCP.


FAQ InterMapper RemoteAccess

  • Invalid username or password error

    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.

  • InterMapper Server not available error

    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.
  • Testing a connection to a remote InterMapper 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

    • Enter the command <KC_version id="0">0.9</KC_version>
    • If you have connected to an InterMapper server, you should see a KR response, such as:
      <KR id='0' response='200'>0.9</KR>.

    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 response to indicate that the server is responding.

  • I can't connect with InterMapper RemoteAccess even after I've created a user on the server...

    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:

    • Open the Server Settings --> Remote Server settings. Add one or more IP addresses or ranges corresponding to the Remote client's addresses.
    • Create one or more users or groups in the Server Settings --> Users settings: These users will be able to connect using their name and password.
    • Set the map access: In the Server Settings --> Map Access settings, be sure that the users or groups have access to the desired maps.
  • Where in the Windows Registry are the InterMapper RemoteAccess preferences kept?

    InterMapper RemoteAccess stores its preferences in the following Windows Registry keys:

    • HKLM\SOFTWARE\JavaSoft\Prefs\com\dartware
    • HKCU\Software\JavaSoft\Prefs\com\dartware
  • What is in the InterMapper RemoteAccess Preferences folder?

    The InterMapper RemoteAccess Preferences folder contains:

    • Certificates The signed certificates used to authenticate secure servers that have been accepted.
    • Local icon cache Instead of downloading device icons and background images every time a map is loaded, they are cached here for local access.
    • Sounds Similar to the icon cache, but for sound notifications.
  • Where are the InterMapper RemoteAccess preferences kept?

    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/



FAQ IP Address

  • What is a "private IP address range"?

    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.

    From the RFC:

    Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

    • 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)
  • What does the "/24" mean? How does that relate to my subnet mask?

    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.


    Subnet Mask # of Addresses
    Subnet Mask # of Addresses
    /1 128.0.0.0 2.1 billion /17 255.255.128.0 32,766
    /2 192.0.0.0 1 billion /18 255.255.192.0 16,382
    /3 224.0.0.0 536 million /19 255.255.224.0 8,190
    /4 240.0.0.0 268 million /20 255.255.240.0 4,094
    /5 248.0.0.0 134 million /21 255.255.248.0 2,046
    /6 252.0.0.0 67 million /22 255.255.252.0 1,022
    /7 254.0.0.0 34 million /23 255.255.254.0 510
    /8 255.0.0.0 17 million (Class A) /24 255.255.255.0 254 (Class C)
    /9 255.128.0.0 8.4 million /25 255.255.255.128 126
    /10 255.192.0.0 4.2 million /26 255.255.255.192 62
    /11 255.224.0.0 2.1 million /27 255.255.255.224 30
    /12 255.240.0.0 1 million /28 255.255.255.240 14
    /13 255.248.0.0 524 thousand /29 255.255.255.248 6
    /14 255.252.0.0 262 thousand /30 255.255.255.252 2
    /15 255.254.0.0 131 thousand /31 255.255.255.254 RFC 3021
    /16 255.255.0.0 65,534 (Class B) /32 255.255.255.255 A single address
  • What is a subnet? Why do I care?

    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.


    Subnet Mask # of Addresses
    Subnet Mask # of Addresses
    /1 128.0.0.0 2.1 billion /17 255.255.128.0 32,766
    /2 192.0.0.0 1 billion /18 255.255.192.0 16,382
    /3 224.0.0.0 536 million /19 255.255.224.0 8,190
    /4 240.0.0.0 268 million /20 255.255.240.0 4,094
    /5 248.0.0.0 134 million /21 255.255.248.0 2,046
    /6 252.0.0.0 67 million /22 255.255.252.0 1,022
    /7 254.0.0.0 34 million /23 255.255.254.0 510
    /8 255.0.0.0 17 million (Class A) /24 255.255.255.0 254 (Class C)
    /9 255.128.0.0 8.4 million /25 255.255.255.128 126
    /10 255.192.0.0 4.2 million /26 255.255.255.192 62
    /11 255.224.0.0 2.1 million /27 255.255.255.224 30
    /12 255.240.0.0 1 million /28 255.255.255.240 14
    /13 255.248.0.0 524 thousand /29 255.255.255.248 6
    /14 255.252.0.0 262 thousand /30 255.255.255.252 2
    /15 255.254.0.0 131 thousand /31 255.255.255.254 RFC 3021
    /16 255.255.0.0 65,534 (Class B) /32 255.255.255.255 A single address
  • How do computers send data through the Internet?

    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.

  • What is an IP address? How do I get one?

    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.



FAQ SNMP

  • What is SNMP?

    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

    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.

  • What is the 'Read-only Community String'?

    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.

  • Why can't I get SNMP information from a device?

    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:

    • Wrong DNS name/IP address - (not likely, but we have to mention it)
    • No connectivity - Can you ping the device from InterMapper?
    • No SNMP agent on the device - Many devices or computers have optional SNMP capabilities that must be installed separately.
    • Is the SNMP agent disabled? - Many devices allow you to disable the SNMP capability totally, or from certain ports.
    • If the SNMP agent is based on net-snmp or UCD-snmp package - be sure that the configuration file specifically lists InterMapper's IP address/subnet as an allowed client
    • In a custom probe, have you specified the OID properly? - (See the OID Format FAQ for details.)
    • Wrong Community string - A couple suggestions: Be sure to try 'public' (without the quotes); check your typing - community strings are case-sensitive.
    • Access lists: does the equipment only allow SNMP access from certain addresses?
    • 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!)

  • How can InterMapper query a particular MIB variable?

    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.

  • Do all tables have an index?

    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

  • Where can I read more information about SNMP?

    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

  • Is InterMapper vulnerable to SNMP attacks?

    No. Dartware has tested InterMapper against the test suite mentioned in CERT Advisory CA-2002-03. Neither of our packages are vulnerable to this attack. See our Vendor Statement.

  • How do I interpret an unknown enterprise number?

    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.

  • Is there a way to scan a network for all SNMP devices?

    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.

  • InterMapper doesn't show my xxxx device properly...

    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.

    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.



FAQ WINS Names

  • What are WINS names?

    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.



FAQ DNS

  • What resolver does InterMapper OSX use for its DNS?

    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.

  • InterMapper sometimes won't show a device's DNS name...

    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.

  • What is a FQDN?

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



FAQ Multiple InterMapper Servers

  • In what situations should I use multiple InterMapper servers?

    Many organizations with a network at a single location use one InterMapper server to monitor their entire network and all of their important services. This solution is highly affordable and produces excellent results.

    Although a single monitoring server makes for simplicity, it does not meet the needs of all organizations. Organizations with very large networks or multiple locations often find that the best design involves using multiple InterMapper servers to deliver a robust and scalable network monitoring solution.

    You should consider using multiple InterMapper servers in the following situations:


    • Redundant monitoring is a requirement.
    • Your organization has a very large network (> 2000 devices being monitored).
    • Your organization’s network spans multiple campuses or is a large distributed network with multiple remote sites/regions.
  • Can I use virtual servers for my InterMapper servers?

    If your organization has only a single InterMapper server then, in general, this is not a good idea. The reason is your virtual server infrastructure is one of your most important resources, and you will want to monitor the elements of this infrastructure using InterMapper. If InterMapper is running on a virtual server inside this infrastructure, and your infrastructure fails, then you will lose your monitoring at the time when you need it most.

    If your organization has multiple InterMapper servers, then using virtual servers for your InterMapper servers is a good idea, as long as all of the InterMapper servers are not inside the same virtual server infrastructure.

    There are many compelling reasons to use virtual servers, including higher performance, being able to scale up CPU and disk on demand, improved reliability, and reduced costs.

  • What is redundant network monitoring and how can I achieve it?

    Redundant monitoring is achieved by having two InterMapper servers with an identical set of maps. If the primary InterMapper server fails or loses connectivity, the secondary InterMapper server continues to monitor the network. For optimal results the InterMapper servers should be connected to two different points on your network.

    Using two InterMapper Servers to achieve redundant monitoring requires regularly synchronizing the maps from the primary server to the secondary server. Day-to-day map editing and probe updates are done only on the primary server.

    The easiest way to synchronize is to use a script based on the InterMapper “HTTP API” which was introduced in release 5.2. The HTTP API is described in the InterMapper Developer Guide. There are example scripts available here:


    • http://download.dartware.com/sdk/scripts/clone_im.sh (Unix/Linux)
    • http://download.dartware.com/sdk/scripts/clone_im.vbs (Windows)
    • You run the script on the secondary server, say, once per day. The InterMapper on the secondary server must be stopped when you run the script, and restarted afterwards. The InterMapper on the primary server can be left running. The script copies the contents of the Custom Icons, Sounds, MIB Files, Probes, Tools, Web Pages, Fonts, Extensions, and Maps folders from the primary server to the secondary server. The contents of the Chart Data and InterMapper Logs are not copied.

      With this approach both the primary and secondary InterMapper servers are active, and both generate notifications. This may seem less than ideal, but it has an advantage. Since the primary and secondary servers are connected to different points on the network, they see things from different perspectives. From time to time one server will see problems the other doesn’t and vice versa, because of network vagaries occurring between the InterMapper servers and the devices that are being monitored. Having two perspectives is useful to help differentiate whether problems are caused by the network or by non-network-related issues.

  • Can InterMapper scale to monitor very large networks?

    Yes, it can.

    A single InterMapper server is capable of monitoring several thousand devices without degrading and without placing a significant monitoring traffic load on the network.

    Organizations with very large networks (> 2000 devices being monitored) can use multiple InterMapper servers to achieve scalable network monitoring.

    A very large campus might use several InterMapper servers to monitor tens of thousands of devices. This spreads the maps and the load over several servers, reducing the load on the main server.

  • Can InterMapper scale to monitor large distributed networks with many remote sites/regions?

    Yes, it can.

    An organization with a large distributed network can use a separate InterMapper server within each remote site/region. In essence, each site/region has its own InterMapper “polling engine”, putting the polling engine as close as possible to the devices being monitored.

    This design allows for monitoring of equipment behind corporate firewalls, and provides resiliency in the face of WAN outages. Network managers at the remote sites can continue to monitor their site/region even when WAN connectivity is down.

    The Map Status probe can be used to create top-level maps showing the summary status of the networks at all sites/regions. When network managers at the main site see a network problem on a top-level map they can drill down to open the maps on the InterMapper server for the site/region to diagnose the problem.

  • How do I use InterMapper RemoteAccess to connect to multiple InterMapper servers?

    The Map List window in InterMapper RemoteAccess displays a list of all available InterMapper servers within your organization, and displays a list of maps on each InterMapper server. Network managers have full visibility to all sites/regions, and can manage the network and diagnose problems at any site/region from any location.

    Communication between the InterMapper RemoteAccess client and the InterMapper servers is protected using SSL encryption. InterMapper RemoteAccess works through VPN servers or firewalls at the remote sites as long as there are rules to allow the InterMapper RemoteAccess traffic through. By default InterMapper RemoteAccess uses port 8181.

  • If I use multiple InterMapper servers, can I still have centralized trend analysis and reporting across my entire enterprise network using InterMapper Reports?

    Yes, you can, but you need to be aware of the considerations below.

    Organizations that use multiple InterMapper servers can collect device statistics, interface statistics, and event log records into a central InterMapper Database server. That is, each InterMapper server at each remote site/region can be configured to connect to a central InterMapper Database server, rather than the local bundled one. This allows for trend analysis and reporting across all InterMapper servers, across the entire enterprise network. InterMapper Reports can extract data from the central database, and create composite reports involving datasets collected from all InterMapper servers.

    This design is resilient. If an InterMapper server at a remote site loses its connection to the central InterMapper Database server, it saves the data locally until the connection is re-established, at which point data collection resumes. No data is lost.

    The volume of data transmitted from the InterMapper servers at the remote sites, across the WAN, to the central InterMapper Database server is proportional to the number of devices and interfaces for which data is being collected and the polling rate. The data is compressed before being sent. For most modern high-speed WAN networks the volume of data sent will be low enough to not be an issue.

    However, there are two scaling considerations to be aware of when using a central InterMapper Database server design.

    The first scaling consideration is that the performance of the InterMapper Reports reporting engine is inversely proportional to the size of the database. To mitigate, when setting up a central InterMapper Database it is important to design retention policies that keep the database manageable in size. Retention policies take raw data points received from the InterMapper servers, average them over 5-minute, hourly, and daily time intervals, and store the averaged samples in the database to reduce the amount of data stored. A good rule of thumb is to keep the raw data points for just one or two days, 5-minute averaged samples for 1-3 months, hourly averaged samples for 6-12 months, and daily averaged samples forever.

    If you want to look at historical charts of raw data points use the excellent InterMapper strip charts. InterMapper strip charts are designed to look at raw data points. InterMapper Reports is good for looking at averaged samples.

    The second scaling consideration is that there is a performance constraint in InterMapper Database that limits the number of datasets that can be processed per minute. To mitigate, it is important to apply retention policies wisely to interfaces. With InterMapper you can have per server, per map, and per device default retention policies. And, with release 5.5 there is a new “Dataset View” that lets you view and apply retention policies to interfaces. When setting up a central InterMapper Database server for your organization take the time to understand exactly how retention policies and datasets work, and to design appropriate retention policies, with a mind to keeping the number of datasets that the InterMapper Database server has to process to a manageable number.

    To summarize, yes, you can have centralized trend analysis and reporting if you have multiple InterMapper servers. This will work fine for many organizations without any scaling issues. If you have a very large network, then you need to be aware of the scaling considerations, and design and apply your retention policies accordingly. The best approach is to start with tight retention policies, monitor the performance of the server, and loosen up your retention polices over time.

    Communication between the InterMapper servers at the remote sites and the central InterMapper Database server is protected using SSL encryption, and by default uses port 8183.

  • How do I install InterMapper DataCenter on a central server, and do I need to buy a license to do that?

    Here we are assuming that you want to set up a separate server that will be dedicated to running InterMapper DataCenter, including the InterMapper Database, InterMapper Reports, and InterMapper Authentication Server modules. This server won’t be doing any network monitoring. Multiple InterMapper servers will connect to the central InterMapper Database, InterMapper Reports, and InterMapper Authentication Server modules running on the central server.

    Installation of InterMapper DataCenter on a Mac OS X or Windows Server

    For Mac OS X and Windows systems the InterMapper DataCenter software comes bundled with InterMapper — when you install InterMapper you automatically install the modules that comprise InterMapper DataCenter

    To install InterMapper DataCenter on the central server download and install InterMapper following the normal installation procedures. This will also download and install the bundled InterMapper DataCenter modules.

    In this scenario the InterMapper server won’t be doing any network monitoring, there will be no maps, and so you don’t need an InterMapper license. If you wish you can remove the startup of the InterMapper server from the system startup script.

    Installation of InterMapper DataCenter on a Linux or Solaris Server

    To install InterMapper DataCenter on the central server download and install InterMapper DataCenter following the normal installation procedures.

    No InterMapper license is required.

    Using a Virtual Server for InterMapper DataCenter

    This centralized design lends itself to using a high performance, high capacity virtual server in the enterprise data center. This provides the flexibility to add CPU and disk resources as necessary should performance become an issue. To optimize performance choose higher performance SAS disk storage for your server, rather than less expensive SATA disk storage, whenever possible.


  • Back to Top

Try Now!

Attend A Live Demo