University of North Carolina at Chapel Hill
School of Information and Library Science
INLS 184 - Protocols and Network Management
Team: Alberti, Eberline, Madariage, Yi

Section 2 - Testing Process

The team utilized all of the available software for this project in analyzing the network. At various stages in the process, we used Ethereal, EtherPeek, NetSight Element Manager, and InterMapper.

Ethereal and EtherPeek

To analyze the traffic generated by the network, we asked ITS to mirror the uplink port on the main switch to a port within the building. We connected a laptop to this port and then ran scans using Ethereal at various times during the week. We scanned different days of the week, at different times of day, for different lengths of time. The table below summarizes our scans.

ScanDayDateTimeLengthTotal Packets
1MondayApril 24, 20066:45pm15 min.516,549
2TuesdayApril 25, 200612:10pm10 min. 398,626
3TuesdayApril 25, 20061:00pm15 min. 4,401,148
4TuesdayApril 25, 20064:50pm5 min. 339,113
5WednesdayApril 26, 20065:05pm7 min. 546,556
6WednesdayApril 26, 20065:45pm3 min. 159,708
7ThursdayApril 27, 200611:45am4 min. 411,814

Following the captures, we used the capabilities of both Ethereal and EtherPeek to analyze the captured data. In Ethereal we viewed each file individually, but we wanted to examine the entire data set as one piece. To find overall statistics we used mergecap, (included with Ethereal) to combine all of the .dmp files into a single file.

mergecap.exe -s 68 -F libpcap -w done\merged.dmp 1.dmp 2.dmp 3.dmp 4.dmp 5.dmp 6.dmp 7.dmp

Since some of our data was not uniform, we used the -s option to limit the packet size to 68 bytes.

We had to use EtherPeek to analyze the resulting data as the capture file was too large (500 MB). Trying to open the file in Ethereal resulted in the consumption of all available RAM and a general crash before opening. Etherpeek was a good alternative because it never used more than 450 MB of RAM while opening any file, and had the added benefit of additional visualization features.


InterMapper shows the health of a network at a glance. Maps present all routers, switches, servers, LAN and WAN links, and connections between elements. Status Windows and Strip Charts detail device status and performance trends. Using InterMapper, our group set up two network node maps and four charts to monitor the health of the network.

The first map recorded information about machines using static IP addresses inside Peabody Hall. Our map indicated 50 devices. Map 2 was used to monitor the three blades of Peabody's main switch. Each blade has a unique static IP address with blade 1 using, blade 2 using, and blade 3 using Blade 1 contains the main uplink on port 17, a gigabit Ethernet VHSIM port.

Charts 1 and 2 were created to analyze the usage, utilization and error percentage of port 17 (main uplink) on blade 1 (, which is a gigabit Ethernet VHSIM port. Chart 1 recorded percent utilization versus percent error. Chart 2 recorded outgoing bytes per second versus incoming bytes per second. The information recorded on the charts comes from Tuesday, April 25 to Thursday, April 27.

Charts 3 and 4 were created to analyze the usage, utilization, and error percentage of port 5 on blade 1 (, which is a Fast Ethernet Frontpanel Port. Chart 3 recorded percent utilization versus percent error. Chart 4 recorded outgoing bytes per second versus incoming bytes per second. The information recorded on the charts comes from Tuesday, April 25 to Thursday, April 27.

NetSight Element Manager

NetSight Element Manager is an easy-to-use network management application that provides comprehensive remote management support for intelligent network management devices as well as any SNMP MIB I or MIB II manageable devices.

Our group used Netsight Element manager to get an idea of what kind of traffic was passing through the Peabody uplink. We set up probes for the three blades of the main switch,, and The most important functions of the Element Manger were its abilities to display configuration information about the switch ports and statistics of types of traffic occurring on the network. For the purpose of our project, the most important port to examine was the uplink (port 17,


We experienced one major problem in conducting our tests. Initially, we had one laptop setup to monitor the network, but found this would not work because of the port mirroring. To remedy this, the helpful staff gave us a second laptop to use. The first ran InterMapper and NetSight Element Manager. The second we used to attach to the mirrored port and sniff packets on the uplink. We ran an entire series of packet captures on the second laptop over the course of a week, but when we went to analyze them we saw little or no HTTP traffic and almost all broadcast traffic. This certainly was not representative of the type of traffic we should have seen, so we realized there was a problem in the setup. Despite being disappointed with our data being rendered useless, we communicated extensively with both SOE staff and ITS staff to try and determine the problem and a solution. Initially we focused on the port mirroring setup, assuming that might be incorrect. Eventually we found out that the setup was right, but the second laptop would not accept packets in promiscuous mode. We ran some tests on our own laptops to see the packets they were getting. There was much more traffic overall, with mostly HTTP packets and a far lower percentage of broadcasts. We had found a solution. We collected an entire new set of data, using the new laptops which would operate in promiscuous mode, over a second week and used this for our analysis.

Section 1 | Section 2 | Section 3 | Section 4 | Contents