security 529 harm that can happen has already occurred and your actions from this point onward can prevent further harm from occurring. Unless the unwanted pro- gram has taken control of your computer and is writing continuously to disk, do not power off your computer. If you were not using a virus scanner and have a program available for use, run it. The chances are high that, if you have a virus or another type of attack program, its techniques may be recognized and the scanner can locate the program. If a scanner is not available or fails to locate any abnormal software, reboot your system using an original system diskette, which loads a good write-protected copy of the operating system, since the original system diskette is permanently write-protected. Using the newly loaded operating system, attempt to examine the files you used during the operating that resulted in an infection indicator. For example, did you previously execute a command stored as an .EXE file and a directory listing shows both .COM and .EXE files? If so, the obvious cause of the problem is now apparent. However, what happens if you cannot access your hard drive owing to the modification of your boot sector, FAT, or directory structure? Although it is probably preferable to have used a disk recover program which keeps an image of your key hard-drive sectors on another area of your drive to facilitate data recovery, you can also attempt to use an operating system command, such as the DOS command SYS C:, which will rewrite your DOS boot sector on your hard drive if that area was modified. If this still does not fix the problem and persons you consult shrug their shoulders when asked what you should do next, you may be faced with having to reformat your drive and reload your software, which was hopefully backed up on a regular basis. Although this represents a situation most of us will rarely have to encounter, if you have to reload previously backed-up software it is important to recognize that the cause of your problem may also have been placed on your backup tape during your last backup operation. However, since you were able to notice an infection symptom, you also noted an operation you performed which caused the symptom. Thus, after you reload your software, reboot from an original version of the operating system and attempt to locate and eliminate the cause of your problem. chapter ten Managing the Network With a little bit of luck, a small network without a significant amount of usage may require a limited amount of effort by the network manager or administrator to tailor the network to the requirements of the organization. As networks grow in complexity, the necessity to manage the network increases to the point where network management tools and techniques become indispensable for obtaining an efficiently and effectively run network. This chapter will focus upon the tools and techniques required to effectively manage a network. First, we will examine the Simple Network Management Protocol (SNMP) and its Remote Monitoring (RMON) management informa- tion base (MIB). Once this is accomplished, we will focus upon the use of products that can provide us with some of the tools we may require to both effectively manage the transmission of information on the network, as well as observe the operation of file servers attached to the network. Although an Ethernet network is a layer 2 transport facility, it is commonly used to transport a variety of higher-layer protocols. Thus, any discussion focused upon the management of Ethernet would be remiss if it did not cover at least one tool you can use to observe the state of higher-layer activity on an Ethernet network. Recognizing this fact, we will conclude this chapter by examining the use of several software products that can be used to provide a valuable insight concerning the utilization of an Ethernet network to include the type of traffic transported and status of different devices on the network. 10.1 SNMP The Simple Network Management Protocol (SNMP) was originally developed as a mechanism for managing TCP/IP and Ethernet networks. Since the first SNMP Internet Draft Standard was published in 1988, the application and utilization of SNMP has considerably expanded, and an enhanced version, 531 Ethernet Networks: Design, Implementation, Operation, Management. Gilbert Held Copyright  2003 John Wiley & Sons, Ltd. ISBN: 0-470-84476-0 532 chapter ten which was originally intended to add several security functions, but due to conflicts among members of the standardization committee wound up tailoring features in the first version of SNMP, was introduced in 1993. That version of SNMP is referred to as SNMPv2. A third version of SNMP, referred to as SNMPv3, was introduced during 2000 and added such security features as authentication and access control. Through the use of SNMP, you can address queries and commands to network n odes and devices that will return information concerning the p erformance and status of the network. Thus, SNMP provides a mechanism to isolate problems, as well as analyze network activity, which may be useful for observing trends that if unchecked could result in network problems. Basic Components SNMP is based upon three components — management software, agent software, and management information bases (MIB), the latter representing databases for managed devices. Management software operates on a network management station (NMS) and is responsible for querying agents using SNMP commands. Agent software represents one or more program modules that operate within a managed device, such as a workstation, bridge, router, or gateway. Each managed agent stores data and provides stored information to the manager upon the latter’s request. The MIB represents a database that provides a standard representation of collected data. This database is structured as a tree and includes groups of objects that can be managed. Concerning the latter, the first MIB, referred to as MIB-I, included 114 objects organized into eight groups. Table 10.1 lists the groups supported by the first MIB defined by the Internet Standards Organization to include a brief description of each group. In examining the MIB-I groups listed in Table 10.1, it is important to note that SNMP represents an application layer protocol. That protocol runs over the User Datagram Protocol (UDP), which resides on top of the Internet Protocol (IP) in the TCP/IP protocol stack. Figure 10.1 illustrates the rela- tionship of SNMP protocol elements to E thernet with respect to the OSI Reference Model. In examining Figure 10.1, note that SNMP represents the mechanism by which remote management operations are performed. Those operations are transported via UDP, which is a connectionless service that can be viewed as providing a parallel service to the Transmission Control Protocol (TCP), which also operates at layer 4 of the ISO Reference Model. At layer 3, the Internet Protocol provides for the delivery of SNMP, controlling fragmentation and managing the network 533 TABLE 10.1 MIB-I Groups Group Description System Provides vendor identification to include configuration in information and time since the management portion of the system was last reinitialized. Interfaces Provides single or multiple network interfaces that can be local or remote, and designates the operating rate of each interface. AddressTranslation Table Provides a translation between the network address and physical address equivalences. Internet Control Message Protocol (ICMP) Provides a count of ICMP messages and errors. Transmission Control Protocol (TCP) Provides information concerning TCP connections, transmissions, and retransmissions to include maintaining a list of active connections. User Datagram Protocol (UDP) Provides a count of UDP datagrams transmitted, received, or undelivered. Exterior Gateway Protocol (EGP) Provides a count of interrouter communications, such as EGP locally generated messages, EGP messages received with and without error, and information on EGP neighbors. reassembly of datagrams, the latter a term used to reference portions of a message. Located between IP and layer 4 is the Internet Control Message Protocol (ICMP). ICMP is responsible for communicating control messages and error reports between TCP, UDP, and IP. In addition to being transported via UDP, SNMP can be transported via Novell’s IPX, within Ethernet frames and through the use of AppleTalk and OSI transports. In 1992, a new MIB, referred to as MIB-II, became an Internet standard. MIB-II included the eight groups of MIB-I previously listed in Table 10.1, as well as two new groups — Common Management Information and Services Over TCP (CMOT) and SNMP. When the effort to run ISO’s management on top of TCP/IP was abandoned, CMOT was essentially dropped as an active group. The addition of an SNMP group permits SNMP to track everything to include its own traffic and errors. 534 chapter ten Application Presentation Session Transport Network Data link Physical SNMP User Datagram Protocol (UDP) ICMP Internet Protocol (IP) Ethernet Physical 7 6 5 4 3 2 1 Figure 10.1 Relationship of SNMP protocol elements to Ethernet. Operation SNMP has a core set of five commands referred to as protocol data units (PDUs). Those PDUs include GetRequest, GetNextRequest, SetRequest, GetResponse, and Trap. The Network Management Station (NMS) issues a GetRequest to retrieve a single value from an agent’s MIB, while a GetNextRequest is used to walk through the agent’s MIB table. When an agent responds to either request, it does so with a GetResponse. The SetRequest provides a manager with the ability to alter an agent’s MIB. Under SNMP Version 1, there was no method to restrict the use of this command, which if used improperly could corrupt configuration parameters and impair network services. Recognizing this problem, many vendors elected not to support the SetRequest command in their SNMP agent software. The introduction of SNMP Version 3 added authentication as well as encryption, resulting in a network management message received by an agent to be recognized if it was altered, as well as to be verified that it was issued by the appropriate manager. This permits the S etRequest to be supported without fear of an unauthorized person taking control of a portion of a network, or an agent returning false information. Since SNMP is a polling protocol, a mechanism was required to alert managers to a situation that requires their attention. Otherwise, a long polling managing the network 535 interval could result in the occurrence of a serious problem that might go undetected for a relatively long period of time on a large network. The mechanism used to alert a manager is a Trap command, issued by an agent to a manager. Under SNMP Version 2, two additional PDUs were added — GetBulkRequest and InformRequest. The GetBulkRequest command supports the retrieval of multiple rows of data from an agent’s MIB with one request. The InformRequest PDU enables one manager to transmit unsolicited information to another manager, permitting the support of distributed network management, which until SNMP V2, was performed in a proprietary manner. One of the problems associated with the development of MIBs was the provision within the standard that enables vendors to extend their database of collected information. Although the tree structure of the MIB enables software to be developed by one vendor to read another vendor’s extension, doing so requires some effort and on occasion results in interoperability problems. To reduce a degree of interoperability, the Remote Monitoring (RMON) MIB was developed as a standard for remote-LAN monitoring. RMON provides the infrastructure that enables products from different vendors to communicate with a common manager, permitting a single console to support a mixed vendor network. 10.2 Remote Monitoring Remote Monitoring (RMON) represents a logical evolution of the use of S NMP. RMON provides information required for managing network segments that can be located in your building or on the other side of the world. Operation RMON operations are based upon software or firmware operating either in managed devices or managed stand-alone hardware probes. Managed devices can include such programmable hardware products as bridges, routers, gate- ways, hubs, workstations, minicomputers, and mainframes that are connected to a network. Through appropriate software, each managed device responds to network management station (NMS) requests transported via the SNMP protocol. Although a stand-alone probe can be considered to represent a managed device, it differs slightly from the previously mentioned devices in that it is firmware-based and is restricted to performing one set of predefined tasks — RMON operations. 536 chapter ten Whether an RMON agent is a managed device or managed stand-alone probe, it captures predefined data elements and will either send statistics and alarms to a network management station upon request for statistics, or generate a trap command upon occurrence of a preset threshold being exceeded, resulting in the generation of an alarm condition that the NMS will then pool. Figure 10.2 illustrates the relationship between a network management station and a series of managed devices consisting of RMON agents or probes. The MIB provides a standard representation of collected data, as well as defines groups of objects that can be managed. At the NMS, one or more application programs control the interaction between the NMS and each managed device, as well as the display of information on the NMS and generation of reports. Other functions performed by NMS applications can include password protection to log on to and take control of the NMS, support for multiple operators at different locations, forwarding of critical event information via e-mail or beeper to facilitate unattended operations, and similar functions. The RMON MIB Remote network monitoring devices or probes represent hardware and software designed to provide network managers and administrators with information about different network segments to which they are attached. The remote networking monitoring MIB was originally defined in RFC 1271, which was obsoleted by RFC 1757, issued in 1995. Under both RFCs the MIB consists of objects arranged into nine groups. RMON agent MIB RMON agent MIB RMON agent MIB Network Management Station (NMS) SNMP protocol Managed device Managed device Managed device Figure 10.2 RMON operation. managing the network 537 The key difference between RFCs is the size of the counters, which were expanded from 32 to 64 bits under RFC 1757. This expansion was in recog- nition of the fact that, as users installed faster Ethernet networks, counters would reach their maximum value in a shorter period of time. Table 10.2 lists each MIB group and provides a brief d escription of the function of each group. All groups in the MIB listed in Table 10.2 are optional and may or may not be supported by a managed device. Both the statistics and history groups can provide valuable information concerning the state of the Ethernet segment being monitored. The statistics group contains 17 entries for which countervalues are maintained, while the history group contains 11 entries for which countervalues are maintained. In TABLE 10.2 Remote Network Monitoring MIB Groups Group Description Statistics Contains statistics measured by the RMON probe for each monitored interface. History Records statistical samples from a network for a selected time interval and stores them for later retrieval. Alarm Retrieves statistical samples on a periodic basis from variables stored in a managed device, and compares their values to predefined thresholds. If the monitored variable exceeds a threshold, an alarm event is generated. Host Contains statistics associated with each host discovered on a network. HostTopN A group used to prepare reports that describe the hosts that had the largest traffic or error counts over an interval of time. Matrix Stores statistics of traffic and errors between sets of two addresses. Filter Permits packets to be matched based upon a filter equation. Packet Capture Permits packets to be captured after they flow through a channel. Event Controls the generation and notification of events from the managed device. 538 chapter ten addition, the history group includes the real-time maintenance of an integer value that denotes the mean physical layer network utilization in hundredths of a percent. Table 10.3 provides a comparison of the measurements performed by the statistics and history RMON groups. Although both groups provide essentially the same information, there are some significant differences between the two. The first major difference is the fact that the statistics from the statistics group take the form of free-running counters that start from zero when a valid entry is received, and provide information concerning the recent operational state of the segment. In comparison, the statistics in the history group provide TABLE 10.3 Comparing Statistics and History Group Measurements Statistics History Drop Events Yes Yes Octets Yes No Packets Yes Yes Broadcast Packets Yes Yes Multicast Packets Yes Yes CRC Alignment Errors Yes Yes Undersize Packets Yes Yes Oversize Packets Yes Yes Fragments Yes Yes Jabbers Yes Yes Collisions Yes Yes Packets 64 octets in length Yes No Packets 65–127 octets in length Yes No Packets 128–255 octets in length Yes No Packets 256–511 octets in length Yes No Packets 512–1025 octets in length Yes No Packets 1024–1518 octets in length Yes No Utilization No Yes managing the network 539 information more useful for long-term segment trend analysis. Recognizing these differences, the statistics group tracks different packet lengths, while the history group ignores packet lengths and tracks network utilization. Since a managed device or probe is essentially useless if a segment becomes isolated from the organizational network due to a router or bridge failure or cabling problem, some vendors provide Ethernet RMON probes with redundant access capability. This capability is normally provided through the use of a built-in backup modem or ISDN support. Another common feature offered with some stand-alone p robes is a multisegment support capability. This feature enables a single probe to be used to provide support for up to four network segments, assuming cabling distances permit. Figure 10.3 illustrates the use of a multisegment RMON probe to capture and report statistics for two Ethernet segments at one location to an NMS at a remote location. Managing Remote Networks To illustrate the use of a network management platform to remotely mon- itor two Ethernet LANs, this author used Network General’s Foundation R R NMS Multisegment probe Legend: NMS = Network management station R = Router Figure 10.3 Using a multisegment RMON p robe. [...]... involve security management, it is mainly focused on the setting and distribution of network Network management Configuration management Performance management Physical configuration Logical configuration Network activity monitoring Resource use examination Bandwidth capacity determination Figure 10. 6 Fault management Problem detection Problem isolation Problem resolution Accounting management Data... Statistics display was 100 ,000,000 when the frame error count reached 100 and generated an alarm Also assume, for simplicity, that the average frame size in the Statistics display was 100 0 bytes An average of 100 ,000,000 /100 , or 1,000,000 frames, flowed on the network for each frame error Since we assumed that each frame has an average length of 100 0 bytes, 1,000,000 frames × 100 0 bytes per frame ×... Figure 10. 10 illustrates the display of EtherVision’s Statistics screen Note that this screen provides you with summary information concerning frame counts, distribution of frame sizes, network utilization, and frame errors Although this screen provides information similar to Foundation Manager’s QuickStats display previously shown in Figures 10. 4 and 10. 5, there are key differences Figure 10. 10 EtherVision... the use of several network management tools you can use to observe network performance There is a core set of five functions associated with network management Those functions are configuration, performance, fault, accounting, and security management Each functional area manages a set of activities Figure 10. 6 illustrates the functional areas commonly associated with network management and the set of... and the FPS carried by the monitored network Figure 10. 8 shows the EtherVision skyline display of network utilization, and Figure 10. 9 shows the skyline display with respect to the FPS rate of data flow on the network In examining Figure 10. 8, note that the display shows 548 chapter ten Figure 10. 8 EtherVision network utilization skyline display Figure 10. 9 EtherVision frames per second skyline display... network management Regardless of which management tool you use, you should always ensure that you have one available The periodic use of an appropriate network management tool provides you with a detailed view of network activity, which can be invaluable in performing your network management functions Cinco Network’s WebXRay As previously discussed in this chapter, it is important to note that Ethernet. .. third packet shown in Figure 10. 22 and is highlighted in the display 562 chapter ten Figure 10. 22 Using EtherPeek to select a packet for decoding Double-clicking on an entry in the packet capture window results in EtherPeek automatically decoding the packet Figure 10. 23 illustrates the decoding of the third packet captured that was summarized in Figure 10. 22 In examining Figure 10. 23 you will note that... remote networks LANs are being monitored Here the second QuickStat button is associated with an Ethernet LAN in San Antonio, and clicking on the first button would immediately bring up the statistics screen for Sacramento that was previously shown in Figure 10. 4 In examining the screens shown in Figures 10. 4 and 10. 5, you will note both provide the same key metrics for each monitored network Those metrics... closer examination 10. 3 Other Network Management Functions Now that we have an appreciation for SNMP and RMON, we can turn our attention to a detailed discussion of a core set of network management 542 chapter ten functions you can use as a mechanism to evaluate the suitability of different vendor products As we will shortly note, upon occasion no one product will satisfy all of your management requirements... usage collection Computation Report generation Network management functional areas Security management Physical security Logical security managing the network 543 passwords and the assignment of file permissions Thus, logical configuration management permits a user to reach a network facility once he or she is connected to the network, while security management involves the ability of a user to gain access . involve security management, it is mainly focused on the setting and distribution of network Network management Configuration management Performance management Fault management Accounting management Security management Physical configuration Logical configuration Network activity monitoring Problem detection Data. of SNMP has considerably expanded, and an enhanced version, 531 Ethernet Networks: Design, Implementation, Operation, Management. Gilbert Held Copyright  2003 John Wiley & Sons, Ltd. ISBN:. portion of Figure 10. 4. In fact, if you compare the last seven entries in Table 10. 3 with the contents of Figure 10. 4, you will note that the packet distribution shown in Figure 10. 4 and the usage