Case Study: Analyzing Local Area Networks activityIntroductionProtocol AnalyzersUsing EtherpeekMessage LogConversation StatisticsNode StatisticsProtocol StatisticsEthernet Type 2 PacketsProtocolDashboardSummary InformationError MessagePacket Size DistributionsAttack InformationUse in the College of Business AdministrationCase Study: Analyzing Local Area Networks activityDue date: Wed Apr 7th, 2004 (1:00 Class)Thu Apr 8th, 2004 (6:00 Class)IntroductionThe College of Business Administration’s shared 10 Mbps LAN suffered from high congestion in the1990s. To solve the problem, the college resegmented its LAN, breaking it into several smaller segments.However, resegmentation is no magic potion. It only works if a network can be logically broken into pieces thathave mostly internal traffic. For instance, if file service dominates LAN usage, then the student laboratories andtheir servers can be placed in one segment. Most of their traffic will stay within their network segment. In contrast,if most of the LANs’ traffic is Internet access, there may be so much cross-traffic to and from the segmentcontaining the router that resegmentation’s ability to reduce traffic in individual segments would be negligible.Before the College of Business Administration resegmented its LAN, it first examined traffic on the LAN, using aprotocol analyzer, Etherpeek.Protocol AnalyzersA protocol analyzer’s job is to study network traffic to see which protocols are being used in station-to-station communication within the LAN.To do this, a protocol analyzer first must capture a sample of frames flowingthrough the network. To do this, the protocol analyzer sets the NIC to what is known as promiscuous mode. Inthis mode, the NIC reads all frames regardless of their destination addresses. The next step for the protocolanalyzer is to decode each arriving frame. This requires the packet analyzer to look at all of the fields in the frame,in the frame’s embedded packet, and in the packet’s embedded transport layer message. Although the protocolanalyzer could simply dump information for each arriving frame in a file and let the network administrator deal withsummarizing the information, protocol analyzers also summarize the data in ways that make sense to networkmanagers.Using EtherpeekThe protocol analyzer used in the College of Business Administration was Etherpeek, which has an excellent graphical user interface that gives easy access to all of its functions.Message LogBy default, when the network administrator does a capture, Etherpeek shows frame contents one at a time in a table, in their order of arrival. This is a message log. Figure 1 illustrates the data presented in this table.Figure 1: Etherpeek Frame-by-Frame AnalysisThis table gives the essential information about each arriving frame, including what computer sent the frame, what computer received it, how long it was, and what transport or internet layer protocol it employed. Not shown is another somewhat cryptic column that presents other information about the packet.1Most of the addresses given are NIC MAC layer addresses. However, if the protocol analyzer knows the IP address or AppleTalk (AT) address of the station, it will present this address.This table offers no summaries. However, raw data is invaluable in many troubleshooting situations. For instance, if a computer or application program hangs (stops working), the contents of the last frame it sent or received may help diagnose the problem.Conversation StatisticsFigure 2 shows the conversations statistics that Etherpeek provides. For each conversation, this view gives the protocol used and the number of bytes sent. Note in the sixth line that this conversation is an HTTP interaction that generated four million bytes of information.Figure 2: Etherpeek Conversation StatisticsNode StatisticsA related view of the data shows node (station) statistics, which shows communication by station. This view is shown in Figure 3. In the first row, we have Station 00:A0:C9:AC:FE:B0. Eighty-one percent of the bytes it exchanged were transmissions from it to other stations. Below this row, we see the two stations with which the node communicated. The first has an IP address. The second is an AppleTalk node. Node statistics tell you about your server communication. If a client is a high-traffic node, this may indicate that it has a malfunctioning NIC that is jabbering (transmitting inappropriately and frequently).Figure 3: Etherpeek Node StatisticsProtocol StatisticsEthernet Type 2 PacketsFigure 4 looks at the data in terms of which protocols were used. Note that the first row shows that the data shown on the screen is for Ethernet Type 2 frames. The Ethernet Type 2 standard predates the 802.3 standards. It does not have an LLC frame embedded in it; its data field holds an IP packet, an IPX packet, or some other packet directly. In addition, in place of the 802.3 MAC frame’s length field, it has a two-octet Ethertype field that tells what type of packet is being carried.Figure 4: Etherpeek Protocol StatisticsLater in the scrollable window there is information about Ethernet 802.3 frames. The two types of Ethernetframes can exist on the same network because NICs are sufficiently intelligent to tell them apart and deal with them appropriately. Servers can be set to tell client NICs to use Ethernet Type 2 or 802.3 frames when they use that server.ProtocolThe first protocol shown in Figure 4 is IPX, indicating NetWare IPX/SPX traffic. Under this comes NCP traffic. NCP messages are embedded in IPX packets, so the figure essentially shows a progressively finer view of the packet’s contents. NCP is the NetWare transport–application layer standard for file and print service communication. Although information for other protocols is not shown in this screen shot, even the small amount of IPX data that is visible emphasizes the high importance of NetWare IPX/SPX communication on the LAN.2DashboardThe figure also shows the Etherpeek dashboard, which allows the network administrator to see how the network is doing at the moment using simulated analog meters.Summary InformationError MessageLast, but certainly not least, Figure 5 presents summaries of the decodes of the captured data. First, it shows that there were no Ethernet errors at all, including runt (too small) frames and oversize (too large) frames. This is good, because it indicates that no NICs appear to be malfunctioning. Later in the