Slashdot Mirror
Ask Slashdot: Documenting a Tangle of Network Devices?
LoudMusic writes "One of the many tasks of a network administrator is documenting the network so that other members of the administration and support teams can find devices on the network. Currently my organization uses Excel spreadsheets to handle this, and it's invariably error ridden. We also save a new file with the date in the name each time an update is made. I'd like to move this to a more intelligent database system, but the driving force for keeping it in spreadsheets is the ability to take the document offline, edit it, then upload this new revision to the file server when we have a connection again. Our clients often don't have reliable internet connections, especially when we're tearing their network apart and rebuilding it. The information we're currently documenting about an individual device are: device name, device model, description, IP address, MAC address, physical location, uplink switch & port, and VLAN. What tools exist that would allow us to have multiple users make updates both online and offline simultaneously, and synchronize changes into both the online and offline copies?"
I use wiki software for network documentation. Tied it in to nagios, actually, so on the device listing page I can jump right to the documentation page.
Not offline, I know, so it doesn't directly match the job requirements. But I think "offline" is a bad requirement anyway.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Currently my organization uses Excel spreadsheets to handle this, and it's invariably error ridden.
In the real world, away from press releases, sadly, Excel is the real world enterprise DBMS for almost all corporations.
I also worked for a place that used a word processor for DBMS.
No codd normal forms, and joins/selects are done completely by intern / human power.
Basically all the "paperless office" did was make it slightly easier to do existing paper processes. No core technological/process changes.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Instead of file name encoded versioning system, use a distributed version control system: Git, Mercurial, Bazaar. It solves your offline problem too and you can keep committing changes when the network is down... And you keep track of who did what.
Those could be handy with the right smartphone app. Shoot the QR and the app finds it in the database (not spreadsheet) and shows you the network diagram around it (as last known to be wired or scanned).
A tiny QR printer could be nice.
now we need to go OSS in diesel cars
Have you tried Google Docs?
-Free
-Easy to use and familiar look to "office" users
-Only requires a web browser or a smartphone
-Automatically saves revisions of the same file so you don't have to manually version
(Come on! It's 2012 out there and IT people are still manually versioning files? Have you been trapped in a time loop?)
-Collaborative so allows simultaneous edits of the same document (yes, simultaneous. No weird concept of lock-and-release queue.)
-Now has an offline mode that automatically reconciles edits when online again
I suppose that fits the bill for your description. Have fun.
... you need to have in your toolkit a nice set of very durable wire cutters.
now we need to go OSS in diesel cars
For most small businesses an excel file is fine. Medium business, use a wiki or something. Large enterprise networks need some kind of CMDB. I use Racktables, but other ones like iTop exist too. There are also paid offerings like Cisco Prime, or Orion. One really interesting offering is this software called Blueprints by pathway systems. It's more about dependency mapping, but it does network documentation too.
this is an internet classic that should be a Right of Passage for any budding network admin.
http://www.vibrant.com/images/cables/lopsa/do-not-touch.jpg
And not once, not twice, but thrice I've had to deal with said tangles. My solution was the same in all cases. Set aside some time and COMPLETELY document it. I use excel and conditional formulas to create cross lists for separate panels, to catch errors while trying to document.
Then once I'm certain I have it right, develop a new organization, then pull everything and start over.
My first experience with this removed multiple token rings, at least FOUR loops, and consolidated twelve hubs (not switches) and installed a master switch. Boot times on the floor went from 30 minutes to 45 seconds, and daily network problems vanished never to return. The morning after the rebuild we experienced an entire day of jaw-dropping throughout the building.
Do it. It's so worth it.
Also another hint. If you have to deal with a lot of unmarked jacks throughout the building, enlist a helper or two and use wireless headsets. One person at the rack with a keen eye for a light going out, and another one or two elsewhere briefly unplugging ethernet cables from live machines. Makes identification of jacks actually quick and easy.
I work for the Department of Redundancy Department.
OCS Inventory is a database and reporting interface that will keep an up-to-date database of the devices on your network(s). It's got a server component that runs on Linux or Windows (Linux is recommended) and client agents that run on Windows, *nix, and MacOS X. The client agents also use nmap to scan for other types of nodes, such as routers and printers. It's very slick; I've used it for six years for my job, and we currently track over 500 computers plus a few other devices through nmap.
The whole thing is GPL, and you can opt for a support contract.
It can also integrate with another package called GLPI, which among other things handles trouble tickets and is also Free.
Hail Eris, full of mischief...
E pluribus sanguinem
Um, you're a technologist in charge of a network of computers, and you want to use a manual system to document your own network so that "other members of the administration and support teams can find devices on the network"?
This is like some dystopian sic-fi satire.
That "network" thing you have, with all its "devices," can actually tell you what it's doing! Better yet, some of those devices can "execute code," which is technology talk for stuff like generating lists of devices and their attributes, putting the results in a spreadsheet, etc.
Google "ping" and "traceroute." Then work your way into the 1990s, then the 2000s, then take a look at some of the tools we have today.
I'm reading all the recommendations, and it's giving me a case of Tourette's. Haven't any of these people actually had to DO what they're talking about? There's a whole realm of software meant just for this purpose: it's called IPAM, or "IP Address Management." The proper solutions also contain exactly the information you're looking to capture in addition as well, and integrate with DNS (or, in some cases, include robust DNS capability) so that they are accurate and you don't need to update the database when you set a new DNS entry. Infoblox makes one of the better implementations that I've seen, but since I don't know your exact needs in detail, I would simply look at IPAM solutions in general.
For your security, this post has been encrypted with ROT-13, twice.
Disclaimer, I'm biased because I work on the product, but this is the exact use case we've designed the product for. http://www.infoblox.com/en/products/netmri.html?utm_expid=7390868-7&utm_referrer=http%3A%2F%2Fwww.website-unavailable.com%2Fmain%3Fq%3Dnetmri%26d%3Dwww.infoblox.comhttp%26oq%3DInfo%2BBlox%2BCom%2BHTTP%2BInfo%2BBlox%2BComen%2BResource%2BProduct%2BDemo%2BNet%2BMRI%2BDownload%2BHTML%2BNet%2BProduct%2BDemos%2BResources%2BInfo%2BBlox%2BCom
MediaWiki is your friend. I set up one for a company a few years ago any later started using it to document my responsibilities there, which cover almost the entire ICT system.
My part of the wiki starts on an ICT page, which is divided into sections for Hardware, Software and Telecom. Each contains a number of links to articles with table overviews that contain links to further, more specific articles. The Hardware section has links to eight articles: Servers, Workstations, Monitors, Ethernet networks, Printers Scanners, Wi-Fi and Ethernet switches. The Software section has links to seven articles: Software packages, Scripts, Domain names, IP subnets, Websites, Cronjobs and AFS volumes. The Telecom section has links to six articles: Phone numbers, telecom subscriptions, Modems, Faxes, Telephones and PBXs. For each of the articles mentioned I also created index pages and every single article has various external and internal links for easy navigation. I even created a series of terminology articles to explain various concepts and how they are important to the site.
With several years of Wikipedia experience, the idea of using a wiki for this purpose seemed obvious to me. However, what was not easy was coming up with the structure outlined above. I had first tried out a deeper hierarchy based on the various geographical locations involved, but backed out of that idea when it was clear that it would be too much work.
Producing this kind of documentation in as much detail as I have represents a lot of work, but it has its advantages. For example, it not only means that critical knowledge about the system is now much harder to lose and easier to share, I've also learned many new things about the system (such as all the hardware specs) and it has also forced me to research areas that I wasn't completely sure about.
I have to agree with this. Sharepoint is actually a pretty darn good CMS / collaboration tool. What's great about it is that is a large complex framework that offers tons of flexibility what's terrible about it is that is a large complex system.
There is another problem with Sharepoint, its way to easy to get started with and not know anything about it. This is typical of most Microsoft Solutions actually. If you are never going to have more than 20 people using it occasional it probably run fine forever, but as we all know things rarely stay that way. If its good for your group some other group in your org will want to start using it, than another and so on and so forth. Pretty soon your basic point click one box deployment on SQL Express is in real trouble.
Don't kid yourself Sharepoint aint easy. Good Sharepoint support and development people have lots of knowledge about Sharepoint, and they will have worked pretty hard to get it, it won't have come with trial and error running a box part time. You most likely won't have time to just pick it up yourself. You are going to end up hiring people to run it. Sharepoint is only a good solution if you have people to support it or your really know and I mean really know that its going to stay a small simple environment.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html