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!
and what about the offline part?
... currently broken network trying to fix it, you should be using a smartphone app to access the database (not spreadsheet) of network configuration info.
now we need to go OSS in diesel cars
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.
From map loggers to whatever else.
http://sydiproject.com/
Visio
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I recommend the self-documenting approach. You already have to map name and MAC in dhcpd.conf (assuming you use DHCP reservations), so just put some extra comments in there (what the device actually is). That way you can be fairly sure that the docs will remain in sync with reality. However, that approach only works for relatively small networks.
In general, avoid the "split brain" approach where you have independenytly generated documentation AND config files. Make one generate the other.
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.
Its a cms setup for this task.
We input machine name, make, model, serial number, host name, IP, physical location, wall port #, where the funding comes.from, role of the machine, and it allows.you to attach devices together (say you have a monitor in epic and a scanner, and a PC... and the monitor is attached to the PC as is the scanner.. epic allows.you to add those devices to.the base unit).
Every piece of equipment at the 6 libraries on the main campus as well as all the branch campuses of Penn state are in the database. We also have it linked to big fix so it will list any machines big fix finds that isn't in our epic database as well as the other way around.
You can then search and filter via criteria and download any "reports" via a csv file.
We log more.info.than I listed (like Mac address etc) but that gives you an idea
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
Bullcrap. I'm a moron and yet I can differentiate between the two. QED
Only if you want it to fail completely at the worst possible moments, buy expensive clients, and run headlong into the built-in limitations with no possibility to extend or work around them without hiring 3 people to support Sharepoint. I just dealt with a company that had gone this route, and it was very difficult to extract any information to usable configuration or scanning information, especially for security surveys.
What you need depends on the scale. Large environments might benefit from commercial tools like OpsManager, which is quite expensive, and for which 90% of the features are unwanted and not useful. But the 10% that are useful include very effective configurable auto-mapping and Visio plugins for shops that like Visio.
Indeed, router configurations should be stored in git or similar rcs.
What hasn't really been mentioned is the use of cdp. If your switches and routers (both Cisco and some non-cisco) support this information it can be very useful to inventory connections. Checkin scripts can update an endpoint with the port information. Then simply tracking the physical location of resources by either asset id and mac address ties the network topology to a physical locality.
Labeling wall jacks to punch down block ports is handy for tracking cabling issues, but not mandatory for identifying port to port connectivity.
However, depending on the skill level involved it might not be trivial and the deployment itself could be time consuming. However, the whole package can be put together in a few days. I worked at one place where someone had the right idea and the implementation was mostly there. (albeit broken) It was fairly easy to fix it up and push out the changes via their deployment process. Physically performing inventory on the network did take some time, but we sent teams to each location for asset identification. If there had not been a desire to actually store rack unit ids we would have never had to perform physical scanning. (Completely worthless for our needs, but mother corporate wanted it down to the RU.)
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
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.
Uhmm, there are automated tools for that... Zabbix, OpenSNMP and many more.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
"Netdot is an open source tool designed to help network administrators collect, organize and maintain network documentation."
https://osl.uoregon.edu/redmine/projects/netdot
https://osl.uoregon.edu/redmine/projects/netdot/wiki
No, but it's webscale, agile, and all the cool kids are using it.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I've seen dozens of methods at different companies, but I've only ever seen one that works and it works really well. Many of the top ISP's use a variant of it.
Let the network self document.
What does that mean? Well, typically it means some discipline in how descriptions are written. For instance ISP's will use a standard customer identifier on all ports. An enterprise might just use hostname. From there, tools like Rancid can poll router and switch configs, store them in a version control system, and mail out changes to the entire staff. Rancid is great to use, because it reduces the human work load down to entering a single line for each device (name and OS type), and making sure that the device accepts logins.
Now that all the configs are archived and you have the one true list of devices it's trivial to take that list of devices and feed it to other tools. One of the first might be NetDisco which probes the devices with SNMP and builds adjacency tables, tracks MAC addresses, and so on. From it's database you should be able to locate anything on the network in seconds.
Now that there is a complete picture of the network, it's time for a little scripting. Take the output of Rancid and/or Netdisco, and use it to for instance build an MRTG configuration file, or a list of things for Nagios to probe. It's fairly easy to take the NetDisco adjacencies and run them into a tool like GraphViz to produce a network diagram.
I know of at least two ISP's using this basic formula, and it works really well. Going to an internal web site they can bring up diagrams, usage graphs, MAC tables, IP information and all sorts of other things about any device in the network in seconds. Once devices are in the system it is 100% automated, turn on a new port and it is magically graphed, MAC tracked, and added to the diagrams. Turn it off, it magically goes away. Everything is in version control so old state can be reconstructed. The only human manual intervention is adding/removing one line to the Rancid config when a device is turned up or turned down. I have even seen folks automate that with Netdisco (but, I think that can be problematic, as it's almost circular).
Spreadsheets, Visio diagrams, and the like are always out of date. Someone will always make a change and forget to update it. Some places are only a little out of date, most places are downright wrong. Self documenting is achievable, and always 100% current.
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