svn co https://svn.sourceforge.net/svnroot/spongemonkee/trunk spongemonkee
For anyone who likes looking at perl (and who doesn't?), it could be an interesting read. It does need a little organizing, but as I said, work is ongoing.
SpongeMonkee, as it's querying, will update its network map (creating or dropping connections between switches) and will automatically find any new switches added to the network. It will also gather as much information as it can on clients (non-switch entities on the network), allowing a SpongeMonkee user to search for a specific MAC or IP address and find that client's current switch and interface.
SpongeMonkee polls switches serially, using Net-SNMP's snmpbulkwalk. Since this takes a bit of time, and since there's normally a good number of switches on the network, switch data is generally up-to-the-hour, but not much better. The daemon that polls switches has treading capabilities, so you can query any number of switches at a time, if you want. This will make your data more up to date, with the cost of more network traffic, more MySQL traffic, etc.
Basically, the backend of SpongeMonkee just grabs all the data it can and stores it in MySQL databases. What's the fun in that? Now that data's readily available for working with through a web frontend, GUI, or other data investigation and manipulation tool. I've built a web frontend to the whole project, and that's what will be presented next.
To get the most information from managed switches, it's usually a good
idea to be able to log in to those switches. That, of course, requires
storing authentication information for each switch. The following page
allows the creation of any number of authentication types, and the ability
to set any set of switches' auth types.
See picture HERE
By the way, some SNMP names can be pretty cryptic at times. SpongeMonkee
has a built-in aliasing frontend, so you can see and set human-readable
names for data, not SNMP names.
See picture HERE
So let's say your configuration's all set up, and SpongeMonkee is running
happily, querying all your switches and storing all its data in a
database. What can you do with all that? First of all, there's simple
searching.
See picture HERE
You can also, though, search based on ratios. We found this particularly
useful for tracking down duplex problems. If the errors/output ratio of
an interface is above some value, it's generally a duplex problem or some
other interface configuration error.
See picture HERE
You can, of course, view all information on a single interface...
See picture HERE
You can also view all information on a single switch. What's that graph
about half-way down? Well, it turns out that when all switch connections
are stored in a database, it's pretty simple to run that data through
'graphviz', an open source graphing utility, and create proximity maps for
each switch on the fly. This works great for following problems from a
single switch back to your network backbone.
As you can see, there's a lot of information gathered on each switch.
Note that not all interface data is shown here, just the data selected up
at the top of the page with the checkboxen.
See picture HERE
Hey, speaking of your 'network backbone', that's a pretty important part
of your network, right? But what, exactly, IS your network backbone?
What switches make it up? And wouldn't it be great to get information
directly from those switches? Well, SpongeMonkee lets you. With a pretty
simple algorithm, SpongeMonkee's web frontend will decide on-the-fly which
switches of those it queried are currently in your network backbone, and
display all the connections between them, again through 'graphviz'. And
since 'graphviz' can output imagemaps, you can click on any switch in
either the backbone graph or the switch proximity graphs and go directly
to information on that switch. This doesn't work in IE, by the way.
See picture HERE
Now comes some of the really cool stuff. We've got a database of all
switches on your network, and we've got data on which authentication data
works with each of the switches. Technically, we could log in to any
switch we want, and do whatever we want, right? Right. In fact,
SpongeMonkee allows you to run batch commands on multiple switches, either
serially or in parallel. So you can run a "show version" on all your
switches at once. Or shut off FastEthernet0/1 on ten different switches.
Or do whatever the heck you want. And you only have to type the command
once. And you don't have to authenticate to any switch.
See picture HERE
Here's the type of output you'd get from a batch command run. It's
specifically laid out to be easily parsable by other programs, if you
want to cut and paste.
See picture HERE
Now that we've got information on all switches, if we add in location
information we get a whole other realm to investigate. SpongeMonkee uses
the Google Maps API to allow users to create any number of locations, then
place all switches in to those locations. Once this is done, real-time
(or at least up-to-the-hour) traffic maps across your network can be
easily viewed. The following shows one such map. Line color and size
both show current input/output speed.
See picture HERE
If you'd like, you can check one checkbox and update the connections, and
the map will show current bandwith usage (the percentage of total
bandwidth used) instead of octets-per-second speed.
See picture HERE
Click on the little blue square at the midpoint of any connection, and
you'll see exact speed and bandwidth percentage use.
See picture HERE
Click on any actual location, and you'll see all the switches it currently
contains. You can move the location, rename it, or delete it. And you
can add or remove switches from it easily, as well.
See picture HERE
I hope you've enjoyed looking at SpongeMonkee. If you have any questions, please contact me at gscoNOSPAMnnell at gmail dot com. The source for this project will be available soon, once I clean up a few more things.
It should be noted that most of the pages in the Web frontend are, at least partially, AJAX enabled. So when you're at the switch page, and you just want to view different interface fields, you can check the boxen you want and click "Update Fields", and it won't reload the entire page. It'll just reload the interface table at the bottom, where the information will actually have changed. Also, on the map, all commands like moving, deleting, and adding locations are done through AJAX calls. It's nice to not require map reloading for every action you do. But I really wouldn't recommend two people modifying things on the map at once. Changes don't propogate between browsers until reload, when the MySQL database is fully reread.
