Documenting your network may sound like a mundane task, but it’s vitally important for IT managers to keep their network documentation up to date for a number of reasons.
Documenting your network may sound like a mundane task, but it's vitally important for IT managers to keep their network documentation up to date for a number of reasons.
Troubleshooters will thank you when the documentation helps them understand the scope and breadth of a problem. Capacity planners will thank you because they'll have firm ground to stand on when they gauge usage trends and make recommendations. Budget people will thank you for finally giving them an accurate rendering of the network. And the CIO will thank you (and maybe give you a raise) for providing a clear picture of your company's network.
We tested IPsonar, a network documentation tool that Lumeta delivered to our lab pre-installed on an HP EliteBook computer running FreeBSD.
IPsonar is a great concept, and using it to document the labyrinths of a network is certainly far easier than documenting by hand. However, we found that IPsonar could use some interface improvements, a few new reports and slightly smarter device recognition.
IPsonar distinguishes between different types of scans – network, host, service, device and leak, and you can perform multiple types in a single run. A network scan reveals topology and generates network maps. A host scan probes open ports to locate Web servers, database servers, etc. A service scan identifies specific services (FTP, NNTP, etc.) running on network nodes. A device scan inventories all the network's nodes, querying for device type and device function along the way. If you strategically pepper your network with Lumeta Leak Sensors, a leak scan finds unauthorized Internet connection points.
Oddly, Lumeta didn't send us a Leak Sensor. Instead, the vendor gave us the IP address of a Lumeta-premised Leak Sensor. Our leak tests were satisfactory, but we regretted we didn't get some hands-on Leak Sensor experience.
IPsonar accurately detected all of the devices and links that we exposed it to on a variety of networks. For managed (SNMP-aware) devices for which we specified good community strings, it correctly identified the purpose, type, manufacturer and other details of each of those devices.
However, IPsonar struggled with unmanaged devices. For example, IPsonar characterized a Motorola 2210 DSL router as a "host" because the DSL router had a Web server (Port 80) interface. IPsonar even declared the DSL router's operating system was either NetBSD or OpenBSD 1.6. IPsonar should have noticed that the IP addresses on either side of the DSL router were different enough to call it a router, not a host.
In the same vein, IPsonar noted a device was manufactured by Cisco, was running the IOS 11.2 operating system and was bounded by dissimilar IP addresses, but, because we used an incorrect community string, IPsonar failed to identify the type of device (it was a router, of course). IPsonar also misidentified a 3Com OfficeConnect 802.11g access point.
We'd like to see IPsonar use smart heuristics to help document unmanaged devices on a network. It might deductively use, for instance, the presence of disparate IP addresses on either side of a device or specific Maximum Transmission Unit (MTU) values to help determine the nature of a device or link.
IPsonar could visually highlight these "guesses" – perhaps by using different colors or by outlining the information in dashed lines – to let us know it wasn't 100% positive. This approach would be extremely helpful in a network documentation effort, especially if we could edit and save the resulting device details.
We set up a variety of scan configurations, giving each a unique name. For each scan, we specified scan types, IP address blocks to scan (or avoid), SNMP community strings, sensors to use, packet rates and DNS servers (from which to obtain node names).
Another oddity: we could specify time periods in which IPsonar should perform a scan. However, IPsonar didn't let us choose a date/time frequency for actually running scans on a regular basis. We had to manually click a "Start Scan" button each time we wanted IPsonar to scan our network.
IPsonar has a Web browser interface. The upper left portion of IPsonar's "home page" – prime user interface real estate – displays, of all things, disk space usage on the IPsonar server, with a large "Update Now" button for bored people who want to see how often the numbers change.
We could also perform a "tactical scan" as well as see the updated-every-30-seconds progress indicators for currently running scans and reports. A tactical scan is a network scan, leak scan, service scan or ping of a specific IP address that you do after fixing something on the network.
The home page also has links to pages for setting up scans, performing administrative tasks and viewing reports.
Choosing the reports link and selecting a report for viewing transports you into another world. The report viewer is an interactive Adobe Flash environment that is, unlike IPsonar's other Web pages, easy to use, well-designed and almost intuitive.
Each report display is highly customizable and can include a dashboard, a node map, a list of nodes, a chart of SNMP-aware routers, leak detection results and a wealth of other information. Clicking on a node in the node map and it displays several categories of information about that node, and most report displays offer both PDF and format-for-printer options.
Unfortunately, Lumeta doesn't offer the means to combine reports (for example, consolidating Americas, Europe and Far East into one global view) or the means to reveal trends by comparing earlier reports with current ones via statistical analysis.
Outside the interactive reporting environment, IPsonar can be quite unfriendly. Initiating a scan without specifying a Leak Sensor produced the cryptic message, "Internal Error: Scan type leakDiscovery did not execute." Clicking on a button to get more information about a scan (or other activity) displayed log file entries that were mostly meaningful only to a programmer.
When we asked IPsonar to show its network map after a scan of just the local network, IPsonar produced a never-ending "Retrieving Map" display. (Bug cause: IPsonar assumes all scans look beyond the local network). After a few days of testing, IPsonar's internal Apache Web server began displaying "Internal Server Error" messages when we clicked on the home page link. (Bug workaround: We renamed the IPsonar server from "NTL" to "NTL2" and the "Internal Server Error" messages disappeared).
While its online help facility is context-sensitive and oftentimes helpful, IPsonar's Administrator Guide is a PDF file whose contents are, unfortunately, rather obscure.
IPsonar is a study in contrasts. While it certainly can ease the work of documenting a network, IPsonar's user interface issues and lack of "smart heuristics" detract from its highly creative reporting environment.
Nance runs Network Testing Labs and is the author of Introduction to Networking, 4th Edition and Client/Server LAN Programming. His e-mail address is email@example.com.
The attacks that overwhelmed the internet-address lookup service provided by Dyn today were well...
Amazon Web Services and Microsoft Azure, take very different approaches in how their data centers are...
By forcing Windows 10 on users, Microsoft has lost the tenuous trust and credibility users had in the...
Sponsored by AT&T
A Q&A on what caused the Dyn DDoS attacks and what to do to protect yourself and your network.
Poll results are supposed to be driven by opinions, but marketers, politicians and others know opinions...
What every citizen should know about the state of our voting systems and the security of our elections....
If you want to keep prying eyes away from your conversations, then these are the apps that you need to...