To implement our intended solution, we needed to increase our background knowledge on the technologies and techniques involved. This type of advanced networking was new to everyone in our group, so much research was required before we could even begin to make decisions.
We spent many hours reading various sections of the Cisco web site. We read over the manuals for the Cisco 2820 switch, and the Cisco 3600 router. We read application documents about setting up networks using VLANs, documents about how switches and routers communicate over ISL, and about the various methods of monitoring traffic and usage in those cases.
After doing our background research, we realized that we needed long-term access to the switch. We emailed Some Person about this, and thus found out that the switch had a non-routed IP address and thus was inaccessible from outside the SomeLondonISP network. We suggested the possibility of co-locating a machine for the duration of our project which would have both a routed IP address and access to the internal SomeLondonISP network. This was acceptable to Some Person.
One of our group members prepared a machine for co-location. It was set up with the latest versions of NetBSD, Perl, ucd-snmp, libgd, and mrtg before it was installed. Our entire group met at SomeLondonISP to drop off the machine and discuss some more detailed implementation questions with Some Person. The installation of the machine did not present any difficulties, and our meeting used only a few minutes of Some Person's valuable time.
Upon returning back to school, we discovered that the machine could not communicate with the switch. We emailed Some Person, and provided him with a login and password on our machine so he could test it for himself. He was able to locate the problem (something to do with ARP and the router, not our machine) and get us talking to the switch.
We then scheduled a marathon group meeting to download the appropriate MIBs and explore the switch's statistical data with the ucd-snmp tools. Due to poor network connectivity between UWO and SomeLondonISP, the interactive telnet sessions to our machine were painfully slow, but we were at least able to get our work done.
Our first task was to determine the VLAN configuration. We probably could have just asked Some Person about this, but we felt that we should be able to figure it out for ourselves. Through much reading of the MIBs, and many calls to snmpwalk, we were able to determine the VLAN numbers in use, the names assigned to these VLANs, and the switch ports assigned to these VLANs.
We found that only three of the VLANs were assigned to switch ports! Those three would be easy to monitor. The other VLANs, however, were nowhere to be seen; they had numbers but did not seem to be bound to any ports, and there did not seem to be any statistical information in the switch relating to them.
We configured mrtg on our co-located machine to retrieve the data for at least these three VLANs.
This is when we realized the specific nature of our task -- to get this mystery information out of the switch or ATM card. We went back to the books and the Cisco website, searching for information on the ATM card and VLANs. We found this information to be sparse, especially for the combination of switch and ATM interface in use at SomeLondonISP. Our information search continued until we ran out of time in the implementation phase of our project schedule. We had to stop our research and begin writing our report.
Next: The Results