- 12 iPhones Apps That Will Make You a Networking Star
- 10 Careers Robots Are Taking From You
- Big Data Gold Isn't Always Where You Would Expect It
- 6 Tips to Build Your Social Media Strategy
Network World - 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.