Departmental Network Analysis Project

Departmental Network Analysis Project

Part I: Network Architecture

1. Description and diagram of the network; type of network; how it's wired

2. How the network is used; types of hosts/computers/network nodes in use

3. Analysis of adherence to Ethernet standards/specifications

Part II: Network Utilization Patterns

Our utilization data comes from the combination of several long term Sniffer Monitor samples with many short term Sniffer Capture Samples. Also, the RMON data, accessible from the switch using NetSight Element Manager helped fill in the gaps as far as Actual Utilization and Broadcast Percentages. Our schedule of Sniffer Monitor samples is detailed in the table below:

Start Date	Start Time	End Date	End Time	Notes
4/16	11:54a	4/16	220p
4/16	2:30p	4/17	542p
4/17	7:10p	4/20	304p
4/20	4:07p	4/25	422p	(server switch port)
4/25	5:55p	4/27	220p
4/27	2:54p	5/7	5:00p

In between the consecutive Monitor samples above, we used Sniffer to Capture samples of traffic that we discovered in the Monitor sample, including AppleTalk, ICMP, IP_ARP, TCP/IP/UDP, IPX, NetBEUI, and NetBIOS.

As described in Part I, the building network is connected to the campus at large through a 100Mbit/sec fiber connection to Kenan Labs. Though we used this point as the basis for much of our utilization data, we realize that in an switched network, there is no single point in the building that all traffic passes. This is particularly true for the School of Social Work, which maintains a number of servers in the building (for file, print, database, and application services) used by primarily (if not solely) by hosts in the building. Conveniently all of these servers are located in the same room on the fifth floor, so with a little detective work (crawling on hands and knees behind the servers) we were able to figure out that the majority connect to the 152.19.129.116 switch, and 2 others connect to the 152.19.129.115 switch. Thus on the basis that most of the intra-building data flows to and from the servers, we could monitor all the traffic going to and leaving from 152.19.129.116 by mirroring the port it connects to on the first floor switches. With the exception of hosts on the 152.19.129.116 switch any computer in the building would have go through the port 1 of 152.19.129.52 on the first floor to get to 152.19.129.116. For the most part, the data we collected from the building uplink port aligned with what we saw from the server switch port. One notable exception was that IPX lead in the protocol distribution sample, presumably do to the two Novell Servers that use IPX to communicate with printers in the building, using older IPX-only HP JetDirect network servers.

1. Distribution of Traffic by Protocol

The network layer protocol distribution was not too surprising. We arrived at the rough percentages below by simply aggregating the protocol distributions from each of our Sniffer Monitor sample periods. We knew in advance that the School of Social Work was using IPX devices, so the high occurrence of IPX was to be expected. We did find the high occurrence of “Others” a bit disturbing, particularly because we had not way to determine from the Monitor sample what comprised “Others.” In addition to the four protocol catagories below, we did also see a smattering of AppleTalk, NetBEUI, XNS, IP_V6, and SNA, though not enough to write home about. Manuel Garcia did not believe any AppleTalk or NetBEUI, etc devices were running on his network, though he mentioned that the School of Public Health, which occupies one or two suites in the building may have a Apple computer.

Protocol	Percent of Traffic
IP	40%
Others	35%
IPX	22%
IP_ARP	3%

The question remained what to make of “Other” which accounted for more than a 3^rd of the traffic. Clearly “Others” is an ad hoc category created by sniffer for protocols it does not recognize. By its very nature, there is no explicit way to filter for it. One solution would be to filter for all traffic that is not IP, IPX, or IP_ARP, but Sniffer’s built in filters did not allow “not” ability. So not only did we not know what we were looking for, but we had no way to figure out what we were looking for.

The breakthrough in this frustration came when we realized that we could filter and analyze captured traffic with Sniffer after it had been captured. To start, we’d need a sample of traffic that hadn’t been filtered, to represent actual data passing through that port. As it turned out, even a short sample (5 to 42 seconds) of “Default” traffic exhibited the protocol breakdown shown above. Not only could define positive filters for IP or IPX, but we could create negative byte-level filters to exclude things like IP and IPX using their appropriate Ethertypes. And because we could compare the negative filters to the original source of data, we would be sure that we hadn’t mistakenly filtered out some of the “Others” category.

So we created a filter that would eliminate IP, IP_ARP, and IPX by filtering for 08 00, 08 06, and 81 37 respectively at byte C in the packet. Much to our delight, we were left with a Capture sample of only “Others” packets, which happened to be primarily ethertype 81FF and 81FD. Even more surprising was that the packets were originating from only a dozen MAC addresses and were destined for 2 MAC addresses. Upon further examination of the packet contents, many of which contained intelligible ASCII, the word “VLAN” appeared again and again, along with potential building and area names.

Google.com provided a dearth of information about 81FF and 81FD, so we turned to Jim Gogan, the campus network administrator for guidance, and he confirmed our suspicions. Ethertypes 81FF and 81FD relate to Cabletron’s SecureFast VLAN technology, and they represent such a high proportion of total traffic by encapsulating and streamlining the role of broadcasts at the switch level, which in turn alleviates the broadcast processing load on end hosts.

One last note: the Others category also contained maybe 0.5% of BPDU, CDP, and RPL packets. Therefore we can rediagram the protocol distribution with the following table.

Protocol	Percent of Traffic
IP	40%
81FF/81FD	35%
IPX	22%
IP_ARP	3%

2. Actual Utilization - a summary of the actual utilization over these samples, describing peak utilization times and periods of low utilization; does the utilization rate vary based on time of day or day of week?

3. Broadcast Traffic - a summary of the relative amount of traffic (%) coming from broadcast packets; based on discussions with others in the class, does this seem like an unusual or high percentage? does the amount of broadcast traffic seem to vary based on time of day or day or week?

4. Major Sources and Destinations

MAC Top Destination Addresses

1) 01001D000001 (destination only)

2) Broadcast (destination only)

3) 00D0000F3403 (number 1 below)

4) Intel 8AC39D (destination only)

5) 01001D000000

MAC Top Source Addresses

1) 00D0000F3403 (number 3 above)

2) 02001D000001 (source only)

3) 02001D000FF0 (source only)

4) Cbltr1CD4D3F

5) 02001D000FF6 (source only)

IP Top Destination Addresses

1) 152.2.255.255 (destination only)

2) BROADCAST (destination only)

3) 152.2.1.123 (number 2 below)

4) 152.2.39.27 (number 3 below)

5) OSPFIGP OSPFIGP All Routers (destination only)

6) 152.2.108.22 (number 1 below)

IP Top Source Addresses

1) 152.2.108.22 (number 6 above)

2) 152.2.1.123 (number 3 above)

3) 152.2.39.27 (number 3 above)

4) 152.2.39.204

5) 128.242.227.117

IPX Top Destination Addresses

1) 0B0D8366.000000000001

2) 0D81B2CA.000000000001

3) 00000000.BROADCAST

4) 9665625C.000000000001

5) 0A534BE2.000000000001

IPX Top Source Addresses

1) 0B0D8366.000000000001

1) 0D81B2CA.000000000001

2) 0927C0EE.000000000001

3) 09661325.00062950719C

4) 029FF234.000000000001

5) 0A534BE2.000000000001

5. ICMP Packets

- Our switches (152.2.129.xxx) are being polled by 152.2.21.163 (cujo.oit.unc.edu) and 152.2.21.164 (cujo-test.oit.unc.edu)

- in two icmp samples 152.2.38.88 and 152.2.38.64 were receiving the largest amount of ICMP traffic mostly from off-campus sites. perhaps icmp is being used by some application like gnutella or napster?

- a bunch of ICMP Sollicitation messages (type 10) to 224.0.0.2 as hosts all over campus boot up, supposedly looking for routers.

6. IP Traffic and Applications

The following accounts for 99.26% of traffic samples

NetBIOS_SSN_T29.03%

HTTP 24.02%

Others 18.25%

NetBIOS_DGM_T7.71%

IMAP 7.63%

SNMP 6.03%

NetBIOS_NS_T3.77%

SMTP 1.38%

HTTPS 0.91%

Bootps 0.54%

- We also saw, accounting for the remaining 0.74% of traffic samples: ICMP, DNS, FTP_Data, Telnet, RIP, POP3, XWin6000, FTP_Ctrl, LPD, NFS, TFTP, POP, NNTP, Bootpc, Gopher, IRC, SNMP_Trap, XWin6001

- “Others” included port 6970 (RealAudio), port 445 (SMB Windows 2000), OSPF, IGMP, SSH, SLP, RPC, NCP...

7. IPX Traffic and Applications

The following accounts for 99.34% of traffic samples

NCP 57.79% (NetWare Core Protocol)

Others 32.77%

SAP 6.31% (Service Advertising Protocol)

NLSP 1.46% (NetWare Link-Services Protocol)

NSNMP 1.02% (NetWare Simple Network Management Protocol)

- We also saw, accounting for the remaining 0.66% of traffic samples: NBIOS, Diagnostic, NRIP, Serialization, NMPI1361, MSG, NMPI1360

- The “Others” category includes SPX (Sequenced Packet Exchange) packets the majority of which (60%) are destined for two IPX addresses (0B0D8366.000000000001 and 0D81B2CA.000000000001)

8. Other Topics of Interest - any other characteristics or patterns of network traffic that you find of interest; various software related problems and issues (sniffer)

Part III: Network Recommendations

1. Recommendations - summary of recommendations in terms of how the network is designed or used that may improve performance.

2. Problems Making Recommendations - if you do not have any recommendations to make (due to lack of problems on the network or insufficient information), I would like to know what leads you to that decision; if it is due to inadequate information, what additional data would you need to make any recommendations?