As campus networks grow ever larger and more complex, monitoring them from centralized points — typically near a core router — is no longer able to determine all of the maladies which may afflict a network. This project aims to augment central network monitoring with easily and rapidly deployable network edge monitors based on a combination of proven open source packages.
Many universities have set out to develop advanced network monitoring tools both at the core and at the edge. Many students have set out to perform research work on the nature of network maladies. Making these tools readily available for deployment will give the universities more free time to enhance the tools and give their students more free time to analyze the outcome.
Flashable image of a pre-configured embedded open source os.
Build scripts and documentation for producing new images.
Readily installable modules for packages such as Ourmon, Smokeping, AMP, NetDisco.
Headend daemon to distribute configuration data and to collect statistics information from the remote nodes.
University networks are some of the most hostile places for a packet to travel. With network cores that often rival major NAPs, network edges of every type imaginable, and often confuzzled routing among them, it is a tribute to the internetwork architecture that any of this even works. But as with all things, sometimes networks break, or worse, exhibit inconsistent behavior. Because one could not possibly tap all links in such large networking, and certainly not over the open Internet, "network tomography" techniques must be employed to detect the nature of these great disturbances in the Ether.
Ourmon is an nms meant to reside near the core of a large network, on fairly heavy hardware. NetDisco, similarly, is able to detect and record the presence of network devices from a central location. Two other projects, SmokePing and AMP, work by placing test nodes at the edges of the network.
Using readily available embedded systems such as the Soekris 4801 and the WRAP 1-C, one need only to implement the flash firmware containing an open source operating system and the requisite software for performing the network analysis. I have a Soekris 4801 board on-hand for this project.
Since first trying to dig into this project earlier in the school year, I discovered that there really aren't any ready-to-roll operating system images that are built for easy customization. I found that I could build from source, but this was difficult and error prone and not conducive to passing on maintainer-ship to others. Some basic projects provided modular installation, but most were under maintained iterations of the build-from-source method. Finally, prebuilt images such as M0n0wall and pfSense were so highly integrated that adding new features would require substantial time invested in the package infrastructure of the project. I am not yet sure where in the spectrum I should begin.
The Summer of Code spans 3.5 months. To allow for schedule slips and days off to go out and play in the sun now and then, the schedule below has 10 weeks.
Week 1:
Investigate available embedded operating systems, focusing on their installation and packaging options.
Week 2:
Prepare an initial flash image to boot the system.
Develop a test harness to determine if we will hit the rewrite limits on the flash drive.
Make plans to mitigate the effects of blowing out the flash drives if indeed (as I expect) this will be a problem.
Week 3:
Make packages for the network monitoring tools listed above.
Build flash images containing the packages.
Identify configuration files that might need to be changed in the field.
Identify collected data files that need to be uploaded to a headend server.
Week 4-5:
Design and code a configuration and updates download mechanism.
Design and code a data collection upload mechanism.
Week 6-7:
Begin testbench deployments around my house: send updates, config file changes, collect data, abuse the software.
Hunt for bugs and fix 'em.
Week 8-9:
Deploy a box at UC Santa Cruz and begin collecting data.
Week 10:
Analyze the data and write up the results.
Make suggestions for future work on the project.
I am a fifth year student of Linguistics, Computer Science and Literature at the University of California at Santa Cruz. I've become increasingly involved in open source software since 1998, when I joined the TWIG project to develop features for online learning and classroom support. As TWIG features a mail user agent, I found that I wanted a better mail server, and came across DBMail, a SQL-backed mail delivery and storage system. That, in turn, led me to libSieve, an implementation of the Sieve mail sorting language in RFC 3028. I am now a core developer of each of those projects.
When I join a project and submit code that scratches my own itches, I always make a point to continue to contribute to the project in some way. Often it's answering questions on mailing lists, maintaining code that nobody wants to get their hands dirty with, and writing documentation. Incidentally, this document has been formatted for AsciiDoc, and generates a very pretty web page: http://hydricacid.com/SoC2006/