Comment You will never succeed. (Score 1) 165
Been there. Done that. Failed repeatedly, and for various interesting reasons, none of which are generalizable.
Your problem has several aspects to it, and as far as I can nobody's talked about them. Lots of the answers talk about specific parts of the problem but not in a general way.
Here's your problem:
- Figure out what you have: this is a basic inventory.
- Figure out how it is connected together: this is a wiring table. Some people will tell you that a wiring diagram is good enough, but after a certain point you can't use them because they get too big and the layout problems start to get non-trivial. So you need a table. Which means you need a way to identify each wire. At both ends. Uniquely. Accurately.
- Figure out how to store it all. Visio for simple, high-architecture diagrams, yes. We use Sharepoint and custom tables for the actual device and wiring tables, but Excel will do. There's a whole essay that could be written on this (and I feel like I've written parts of it repeatedly) but the #1 aspect to this issue is that WHATEVER YOU PICK HAS TO BE SIMPLE AND STAY OUT OF PEOPLE'S WAY OR THEY WON'T USE IT. You have to make it trivial to keep the data up to date. You have to somehow make it harder to not do the wrong thing -- but since the wrong thing is to ignore the documentation and just slap your wire in there, that's impossible. Which means you need:
- A way to detect changes that are made without authorization. I have a home grown collection of tools (rancid, nagios, arpwatch) and scripts that detect most of the day-to-day possible changes that happen on my particular network. I like the idea of NetDisco but have never achieved a working instance. The problem is that while detecting adds and moves is easy (because a move appears as an add) detecting decommissioning is hard. So the documentation rots. So you need:
- Tools that can detect the current state of the network. One of my copious-spare-time project (for the last ten years *sob*) has been writing a perl script that can query my snmp switches and tell me what port a particular MAC address is connected to, right now. I can't tell you how many times that script has saved hours of f---ing around at various places. But you need SNMP-manageable gear for something like that to work. So you need:
- Management that will support you in this endeavor. Management that will spend the extra bucks to ensure that equiptment can be monitored for changes by external systems. Management that understands that documentation needs periodic auditing and that the crazy guy ranting about unauthorized changes has been empowered by management to enforce documentation about these changes. (Which is hard when its your boss making the changes.)
Frankly the last issue is the most important. If you can get management to sign off on spending money (and really, your time is their money) then you are 50% of the way home. If you get sandbagged halfway through when you discover you need to unplug three linksys switches that happen to form the iSCSI core network that will take the world offline for six hours to sort out a spanning-tree loop, then you'll have other problems. But the technical ones are easy to sort out once management has committed to spending time and money to solve them.