Lesson 2:Logs and Indicators

One of the first and most important factors in maintaining a network is knowing when there is something wrong. Networks perform many important processes automatically and in the background, and it's the job of the network administrator to make sure that what is supposed to have been done has been done, without error and without problems. This lesson examines some of the tools that network administrators routinely use to check on the performance of network components and provide indications of trouble.

---

After this lesson, you will be able to

• Understand the function of Ethernet link pulse light-emitting diodes (LEDs)
• List the various types of error messages and event logs used by networking equipment
• Monitor the status of a computer running Microsoft Windows 2000 by using the Performance console
• Examine network traffic using a protocol analyzer

Estimated lesson time: 40 minutes

---

Power and Drive Lights

One of the most basic signs that something has gone wrong on your network is when the lights signaling that a piece of equipment is switched on and operational are not lit. This could be caused by a power failure, a tripped circuit breaker, or something as mundane as the electrical plug falling out of the socket. However, it is also possible that the device has experienced a power supply failure, or a drive light is out because a drive inside the computer has failed or become disconnected. It's a good idea to become familiar with the LED displays of your equipment during normal operation so that you can quickly determine when something is not as it should be.

Link Pulse Lights

As mentioned in Chapter 15, "Installing a Network," most of the Ethernet network interface adapters designed to use unshielded twisted pair (UTP) cable have an LED on them, as shown in Figure 18.6, that is lit when the adapter is connected to a functioning hub. The hub usually has an LED for each port as well (see Figure 18.7), which enables you to tell from either end of the patch cable whether the devices are connected. However, although these link pulse lights can tell you whether a computer is wired to the hub properly, it's also important to know what these lights do not do.

Figure 18.6  The link pulse LED on an Ethernet network interface adapter

Figure 18.7  The link pulse LEDs on an Ethernet hub

When you connect a UTP network interface adapter to a hub, you should find that the link pulse lights on both devices are lit, as long as both are switched on. Note that the network interface adapter must be installed in the computer and the computer must be turned on, but you don't need to have the network interface adapter driver installed or be logged on to the network to activate the LED.

When an Ethernet adapter and a hub are properly connected, they exchange signals to test the connection. On 10Base-T and 10Base-FL equipment, the signal is called a normal link pulse (NLP). The NLP signals last for 2 milliseconds and are repeated at intervals of 16.8 milliseconds. These signals occur only when the network is not busy transmitting data, so they do not interfere with normal operations. When the LEDs at both ends of the connection are lit, this indicates that the NLP signals generated by each device are reaching the other device.

If you accidentally use a crossover cable to connect a computer to a hub, the signals sent over the transmit wires do not reach the receive contacts in the other device, and the LEDs will not light. For the same reason, if you connect two network interface adapters together using a straight-through cable and no hub, the LEDs will not light. If the LED lights on one device, but not on the other, then there is a fault in the cable connection. It could be that the cable itself is faulty, one of the devices' connectors is broken, or the cable is not properly seated into the jack at one or both ends. Try reseating the cable connectors into the jacks, or replace the cable with one that you know is functioning properly, and then see if both link pulse lights come on.

For more information about straight-through connections and crossover connections, see Lesson 2: Making Connections, in Chapter 15, "Installing a Network."

Fast Ethernet and Gigabit Ethernet equipment that supports multiple speeds uses fast link pulse (FLP) signals, which differ from NLP signals in that they include a 16-bit data packet that the devices use to autonegotiate their connection speed. The data packet contains a link code word that consists of a selector field and a technology ability field. The devices use these fields to advertise their capabilities, including the speeds they can run at and whether they support full-duplex (that is, simultaneous bidirectional) communications. By examining the link code word supplied by the other device, the network interface adapter and the hub both configure themselves to use the best transmission mode that they have in common according to the following priorities:

1. 1000Base-T (full-duplex)
2. 1000Base-T
3. 100Base-TX (full-duplex)
4. 100Base-T4
5. 100Base-TX
6. 10Base-T (full-duplex)
7. 10Base-T

Some dual-speed devices also have LEDs that light up to indicate the speed at which the device has configured itself to run. Do not confuse this with the link pulse LED.

FLP signals are fully compatible with the NLP signals that are used by devices that cannot operate at multiple speeds. If, for example, you connect a computer with a 10/100 dual-speed Fast Ethernet adapter to a standard 10Base-T hub, the adapter receives the NLP signal from the hub and determines that 10 Mbps half-duplex is the fastest speed they have in common, and configures itself accordingly. The 10Base-T hub, receiving the FLP signal from the adapter, cannot interpret the link code word and sees the signal only as a normal NLP link test. No autonegotiation occurs at the hub because none is possible.

It's important to understand that the link pulse LEDs are only an indication that the network connection is wired properly. Just because the LEDs are lit does not necessarily mean that the connection is capable of carrying actual Ethernet traffic. Link pulse signals run far more slowly than Ethernet data signals and are not affected by electromagnetic interference, such as crosstalk, the way that actual Ethernet data signals are. For example, if you use a "silver satin"–type telephone cable to connect a network interface adapter to a hub, the link pulse LEDs will usually light. However, in this type of cable, the wire pairs are not twisted, which results in high levels of crosstalk. When Ethernet signals are transmitted over this type of cable, crosstalk causes the signals to bleed over from one wire pair to the others, causing the network interface adapters to receive signals over both the transmit and receive wire pairs simultaneously.

UTP Ethernet adapters interpret simultaneous signals on both wire pairs as an indication that a collision has occurred. In fact, even though there has been no real collision, the adapters behave as though there has been one. They discard the supposedly damaged packets and begin the data retransmission process. This is called a phantom collision, and if it occurs frequently enough, it can seriously degrade the efficiency of the network. Thus, you can use the link pulse LEDs as an indication that you have wired your network correctly. Don't mistake them, however, for a true diagnostic test of the network's transmission capabilities.

Error Displays

The most obvious indication that a problem has occurred on a computer is an error message that appears on the screen. Error messages are generated primarily by applications and operating systems. They can inform you when something has gone wrong with a computer or the software running on it. In most cases, error messages can't give you specific information about a problem with the network itself because, except in special circumstances, there is usually no way for the computer to test or communicate with network components except for other computers. For example, an error message generated by an operating system might tell you that the computer was unable to communicate with another computer on the network, but it usually can't tell you why unless the problem is with the computer generating the message.

Error messages can be helpful or they can just add to your confusion, depending on the information they provide. Many operating systems and applications have error messages that are ambiguous or misleading, so you might need help interpreting them, either from the product documentation or from the manufacturer. The most important thing to do if you are faced with an error message you don't understand is to write down the exact message, including all number and letter codes, memory addresses, and other types of information, even if you don't know what they mean. What might appear to be nonsense to you can, when reported to the manufacturer's technical support department, make the difference between successfully resolving the problem or not. You should also inform all network users to do the same thing for any error messages they receive.

One of the easiest ways to preserve a complex error message is to save an image of the entire screen. On a Windows system, pressing the Print Screen (PrtSc) key copies the current screen image to the clipboard. If you open the Windows Paint program and select Paste from the Edit menu, the image is pasted into the program, and you can print it or save it to a bitmap file. This technique works as long as the computer is still capable of running programs. If the problem halts the system, typically generating a fatal system error (know to some as the "blue screen of death") in Microsoft Windows NT or Windows 2000, you have no recourse other than to write down the error information.

When you're faced with error messages that you don't understand, having the documentation for the products involved on a searchable medium, such as a CD-ROM or a Web site, comes in handy. You can search for the entire message or for keywords or phrases much more easily than you could by poring through a printed manual.

Event Logs

An event log is a running record of processes that functions as an operational history of the product involved. Many applications, operating systems, and networking components are capable of maintaining logs of their activities, and as a network administrator, part of your job is to check the logs on a regular basis for problems or even just for informational messages. Some products keep logs as text files and may or may not supply the means for you to view them. You might have to open the log file in a separate application to read the contents. In many cases, log files can grow very large, so to read them you might have to find a text editor that can handle large files.

Logging Options

In some cases, applications enable you to specify whether you want them to log their activities and, if so, how much detail you want in the logs. When you're working with a newly installed or reconfigured application or device, it's always a good idea to keep logs for a while. However, the amount of detail you want in the logs is an important consideration. You want to have an accurate picture of the product's activities, but you also don't want to spend hours poring through log files, so selecting the most detailed option might not always be best. For example, most backup programs have a full detail logging option, which means that the log maintains a complete listing of every file that the program backs up. This might be useful in some instances, but it makes for an enormously large log file that is difficult to scan for basic information, such as whether a backup job has completed successfully. In a case like this, you're better off selecting a less detailed log unless you suspect a problem that requires more specific information.

Highly detailed log files can also take up a lot of disk space, and you have to be careful that you don't let them grow unchecked. Many applications that keep logs enable you to set parameters that limit the size to which the files grow. For example, the Internet Information Services (IIS) included with Windows 2000 Server enable you to specify when each service should create a new log file—hourly, daily, weekly, or monthly—using the dialog box shown in Figure 18.8. You can also specify a maximum size for the log file or leave it with no limitations. By clicking the Extended Properties tab, you can select what information the service should include in the log, as shown in Figure 18.9.

Figure 18.8  The IIS Extended Logging Properties dialog box

Figure 18.9  The IIS Extended Logging options

Event Viewer

In some cases, logs are maintained and displayed by a separate application, such as the Event Viewer included in Windows 2000 and Windows NT. To launch Event Viewer in Windows 2000, from the Start menu's Programs/Administrative Tools group, select Event Viewer. By default, the application displays the logs for the current system, but you can also view the logs of another computer running Windows 2000 by selecting Event Viewer in the left window, then selecting Connect To Another Computer from the Action menu.

Event Viewer maintains lists of messages generated by various elements of the operating system. Each log entry is listed as a separate item with the date and time that it was generated, the process that generated it, the event ID, and other important information, as shown in Figure 18.10. By default, Windows 2000 Professional contains three different logs—an Application Log, a Security Log, and a System Log—all of which are maintained independently. The Windows 2000 Server products include these three logs, plus others, depending on the services installed. An Active Directory service domain controller, for example, also has Directory Service, DNS Server, and File Replication Service logs.

Figure 18.10  The Windows 2000 Event Viewer

Each event in each log is assigned one of the following classifications and marked with a corresponding icon:

• Information.  This indicates the successful completion of an event, such as the launching of a server application or the loading of a device driver. Information messages are a normal by-product of the computer's operations and are not to be considered problematic.
• Warning.  This indicates a condition that is not necessarily a problem now, but might become a problem in the future, such as when available memory or disk space drops below a certain level.
• Error.  This indicates the occurrence of a significant problem that has caused a loss of system functionality or a loss of data, and requires immediate attention, such as when a service fails to load or a drive goes offline.

When you double-click one of the log entries in Event Viewer's main display, you see an Event Properties dialog box, like that shown in Figure 18.11. This dialog box contains more detailed information about the entry, including a description and any data generated by the event. Using the arrow buttons in the upper right of the dialog box, you can scroll up and down through the events in the log. The entries stored in Event Viewer are sometimes also displayed as pop-up error messages. One of the advantages of using the Event Viewer application is that you don't have to write down most error messages, because you can always view or print them later. Clicking the third button in the upper right corner copies the contents of the entry to the Windows clipboard. You can then paste it into Notepad or another application for printing or faxing to a technical support representative.

Figure 18.11  An Event Properties dialog box

Network Management Products

Error messages generated by operating systems and applications are usually easy to monitor, but receiving error messages from other network components, such as routers or computers at remote locations, can be more difficult. A stand-alone router doesn't have a screen on which it can display error messages, but it is possible to arrange for many networking devices to supply you with information about their status. Network management products, such as Hewlett Packard's OpenView, are designed to provide network administrators with a comprehensive view of network systems and processes, using a distributed architecture based on a specialized management protocol, such as the Simple Network Management Protocol (SNMP) or the Remote Monitoring (RMON) protocol.

SNMP is a TCP/IP application layer protocol and query language that specially equipped networking devices use to communicate with a central console. Many networking hardware and software products on the market, including routers, switches, hubs, operating systems, and applications, are equipped with SNMP agents. An SNMP agent is a software module that is responsible for gathering information about the product and delivering it to one computer that has been designated as the network management console. The agents gather specific information about the network devices and store them as managed objects in a management information base (MIB). At regular intervals, the agents transmit their MIBs to the console using SNMP messages, which are carried inside User Datagram Protocol (UDP) datagrams.

The console collates the information that it receives from the agents and provides the administrator with a composite picture of the network and its processes. The console software can usually create a map of the interconnections between network devices and display detailed log information for each device. In the event of a serious problem, an agent can generate a special message called a trap, which it transmits immediately to the console, causing it to alert the administrator to a potentially dangerous condition. In many cases, you can configure the console software to send alerts to administrators in a variety of ways, including pop-up messages, e-mails, faxes, and even pager signals.

In addition to network reporting capabilities, network management products often include a large collection of other functions as well, including the following:

• Software distribution and metering
• Network diagnostics
• Network traffic monitoring
• Report generation

Network management products are not designed for small networks, and they are certainly not cheap. Deploying a network management system is a complex undertaking that is intended for administrators of large networks who can't possibly monitor all their network devices individually. To use a product like this effectively, you must be sure that, when designing and building your network, all the equipment you purchase supports the network management protocol you intend to use. However, products like these can greatly simplify the tasks of network administrators and can often bring significant problems to an administrator's attention before causing serious outages.

Performance Monitors

Error messages, logs, and network management products generally inform you about what has already happened on your network. However, there are also products that can help you to know what is currently happening on your network. Network monitoring tools, like the Windows 2000 Performance console, display activities as they are occurring. The Performance console is designed to display ongoing information about the processes running on that individual computer, but many of these processes can involve network activities. Other operating systems have their own monitoring applications. The Novell NetWare MONITOR.NLM (shown in Figure 18.12) is one such application, and there are also third-party products that enable you to continually observe the status of your network.

Figure 18.12  The Novell NetWare MONITOR.NLM application enables you to view network statistics, such as the number of packets transmitted over a particular interface

The Windows 2000 Performance console is a graphical application that displays real-time statistics about a computer's activities. It can also maintain logs of those statistics and generate alerts when their values reach certain levels. The System Monitor component of the Performance console, shown in Figure 18.13, is where you can select the statistics you want to monitor and view them in a dynamic display.

Figure 18.13  The Windows 2000 System Monitor

The various elements that the program can monitor are called counters. Windows 2000 includes dozens of counters for many different hardware and software components, such as the processor, the memory, and the network interface, as well as individual services and applications running on the computer. Third-party software products can also add their own counters to System Monitor, enabling you to track their specific activities. To add counters to the display, click the Add button on the toolbar to display the dialog box shown in Figure 18.14. You can select as many counters as you want from each of the categories in the Performance Object list, and for any computer on the network. Remember, however, that selecting too many counters at once makes for a confusing display that's difficult to read. The Explain button provides a brief definition of what the highlighted counter is designed to measure.

Figure 18.14  System Monitor enables you to add as many counters to the graphical display as you want

After you've selected all the counters that you want to display in the Add Counters dialog box, click Close. The main System Monitor screen immediately begins graphing the values of the counters you selected. By clicking Properties, you can change the nature of the display from a line graph to a histogram or to a numerical report, as shown in Figure 18.15. To display information in a graph effectively, you might also have to modify the scale used in the y axis, so that all of your counters are not piled on top of each other at the bottom of the graph. You can also change the colors used in the graph, the interval at which the information is updated, and other display characteristics.

Figure 18.15  System Monitor can also display statistics numerically

The System Monitor console is a useful tool, as long as you are looking at the display. You can also use the Performance Logs and Alerts feature of the Performance console to create log files containing the statistics of particular counters over a period of time. You can create alerts that are triggered when the value of a particular counter reaches a level that you specify, using the dialog box shown in Figure 18.16. You can then configure the alert to notify you of the situation by adding an entry to the event log, sending a network message, starting a performance data log, or executing a program that you specify. The Performance console and other similar tools can provide you with a wealth of information that you can use to monitor and diagnose problems on your network.

Figure 18.16  Creating alerts enables the Windows 2000 Performance console to notify you when specified conditions are met

Protocol Analyzers

A protocol analyzer is one of the most powerful tools for learning about, understanding, and monitoring network communications. A protocol analyzer is a tool that captures a sample of the traffic passing over the network, decodes the packets into the language of the individual protocols they contain, and lets you examine them in minute detail. Protocol analyzers often compile network traffic statistics, such as the number of packets utilizing each protocol and the number of collisions that are occurring on the network. Using the protocol analyzer to capture and display network traffic is relatively easy, but interpreting the information that the analyzer presents and using it to troubleshoot your installation requires a detailed understanding of the protocols running on the network. However, there is no better way to acquire this type of knowledge than to examine the actual data transmitted over a live network.

Protocol analyzers are useful tools in the hands of an experienced network administrator, but they can also be used for malicious purposes. In addition to displaying the information in the captured packets' protocol headers, the analyzer can also display the data carried inside the packets. This can sometimes include confidential information, such as unencrypted passwords and personal correspondence. If you can avoid it, do not permit your users to run protocol analyzers unsupervised.

A protocol analyzer can be a hardware or software product, either a device with a proprietary interface that you connect to a network to capture traffic, or a software program that runs on a computer that is already connected to the network. Some network consultants who frequently work at different sites install a software-based protocol analyzer on a portable computer and, by changing PC Card network interface adapters, are ready to connect to virtually any network. Protocol analyzers typically work by switching the network interface adapter they use to access the network into promiscuous mode. When in promiscuous mode, a network interface adapter reads and processes all the traffic that is transmitted over the network, not just the packets that are addressed to it. This means that you can examine all the traffic on the network from one computer.

The most commonly found protocol analyzer today is the Microsoft Network Monitor application, mostly because it's included with all the Windows 2000 Server and Windows NT Server products. The application is also included with the Microsoft Systems Management Server (SMS) product, but with an important difference. The version of Network Monitor in SMS supports promiscuous mode, but the version in Windows 2000 Server and Windows NT Server does not. This means that, with the server version, you can only capture traffic addressed to or transmitted by the server on which Network Monitor is running.

Running a protocol analyzer in promiscuous mode also requires a network interface adapter that is capable of being switched into that mode. Most, but not all, adapters can run in promiscuous mode.

Capturing Traffic

The first step of a protocol analysis is to capture a sample of the network traffic. Network Monitor uses the window shown in Figure 18.17 to control the sampling process. Starting a packet capture is a matter of selecting the network interface that you want to use (if there is more than one) and starting the capture process by clicking the Start Capture button on the toolbar. The program reads the packets that arrive over the network interface and stores them in a buffer for later examination. If necessary, you can increase the size of the buffer to capture a larger traffic sampling.

Figure 18.17  The Windows 2000 Server Network Monitor Capture window

Protocol analyzers, like detailed log files and performance monitors, offer a huge amount of information, and often the trick to using the tool effectively is zeroing in on what you actually need. On a busy network, a packet capture of only a few seconds can consist of thousands of packets, generated by dozens of different systems. Protocol analyzers have filters that enable you to select the packets that you want to capture using a number of different criteria, such as the source computer address, the destination computer address, the protocols used to build the packets, and the information found in the packets. For example, if you are having a problem establishing Hypertext Transfer Protocol (HTTP) connections to your Web server, you can use the Capture Filter SAPs And ETYPEs dialog box, shown in Figure 18.18, to enable the capture of IP packets only, because IP is the protocol used for HTTP connections. You can then use the Address Expression dialog box (shown in Figure 18.19) to specify that you only want to capture the traffic arriving at your server from the other computers on the network.

Figure 18.18  The Network Monitor Capture Filter SAPs And ETYPEs dialog box

Figure 18.19  The Network Monitor Address Expression dialog box

The result of specifying capture filters is that you have a much smaller traffic sample that contains less of the extraneous information generated by other network processes. If you want to learn how much network traffic is generated by Address Resolution Protocol (ARP) transactions, for example, you can create a filter configuration that captures only ARP traffic for a specific period of time, and work out the number of megabits per hour devoted to ARP from the size of your captured sample. The Capture Filter dialog box, shown in Figure 18.20, displays the combination of filters you've chosen, and enables you to save capture filter configurations to reuse later.

Other protocol analyzers offer more comprehensive capture filtering capabilities, such as selecting specific application layer protocols. When you start the capture, the software displays the number of packets passing over the network and the number that are being captured by the filter. When you have a sample of sufficient size, click Stop Capture.

Figure 18.20  The Network Monitor Capture Filter dialog box

Displaying Captured Traffic

When you've captured a network traffic sample, click Display Captured Data to show your sample in the Capture Summary window, as shown in Figure 18.21.

Figure 18.21  The Network Monitor Capture Summary window

This window displays a chronological list of the packets in your sample, including the following information:

• Frame.  This field shows the number of the frame (or packet) in the sample.
• Time.  This field indicates the time (in seconds) that the packet was captured, measured from the beginning of the sample.
• Src MAC Addr.  This field gives the hardware address of the network interface in the computer that transmitted the packet. For computers that the analyzer recognizes by a friendly name, such as a NetBIOS name, this field contains that name instead of the address. The computer on which the analyzer is running is identified as LOCAL.
• Dst MAC Addr.  This field gives the hardware address of the network interface in the computer that received the packet. Friendly names are substituted if available. By building up an address book of the computers on your network, you can eventually have captures that use only friendly names.
• Protocol.  This field shows the dominant protocol in the packet. Each packet contains information generated by protocols running at several different layers of the OSI reference model. The protocol specified here indicates the primary function of the packet. For example, an HTTP packet also uses the Transmission Control Protocol (TCP), IP, and Ethernet protocols, but the reason for the packet's existence is to deliver an HTTP message.
• Description.  This field indicates the function of the packet, using information specific to the protocol referenced in the Protocol field. For an HTTP packet, for example, this field indicates whether the packet contains an HTTP GET Request or a Response message.
• Src Other Addr.  This field specifies another address used to identify the computer that transmitted the packet. In the case of the TCP/IP protocols, this field contains the IP address.
• Dst Other Addr.  This field specifies another address (such as an IP address) used to identify the computer that received the packet.
• Type Other Addr.  This field specifies the type of address used in the Src Other Addr and Dst Other Addr fields.

From this main display, you can track the progress of transactions between specific pairs of computers on your network. For example, you can see that an exchange of messages between a Web browser and a Web server begins with the exchange of TCP messages that forms a three-way handshake and establishes a connection between the two computers. The browser then transmits an HTTP GET Request message, and the server replies with a series of responses. To zero in on a particular message exchange, Network Monitor enables you to apply filters to already-captured samples as well as during the capture. The interface you use to create the filters is the same one you use to select the desired capture filters. When you apply a filter, you see only the packets that conform to the parameters you've chosen. The other packets are still there in the sample; they're just not being displayed. You can modify the filter at any time to display more or less data.

When you double-click one of the packets listed in the main Capture Summary window, the display splits into three parts, as shown in Figure 18.22. The top section contains the original capture summary, with the selected packet highlighted. The middle section contains the contents of the selected packet, in a fully interpreted, expandable display. The bottom section contains the raw, uninterpreted contents of the packet in hexadecimal and alphanumeric form.

Figure 18.22  Network Monitor can display detailed information about each packet in both raw and interpreted forms

The center section of the display is where you can learn the most about the contents of each packet. The analyzer interprets the data in the packet and separates it into the headers for the protocols operating at the various layers. Clicking the plus sign next to a protocol expands it to display the contents of the various header fields. Figure 18.23, for example, shows the expanded TCP header of an HTTP GET Request packet. The header fields display the source port and destination port numbers, the latter of which contains the protocol code for HTTP, plus the sequence number and acknowledgment number values used to implement TCP's packet acknowledgment and error detection mechanisms, and the other header fields.

Figure 18.23  Network Monitor interprets the data in a packet and displays the contents of the header fields in each protocol

For more information about the structure of the TCP header and the functions of its fields, see Lesson 1: TCP and UDP, in Chapter 7, "Transport Layer Protocols."

The raw data display at the bottom of the window is used primarily to view the application layer data carried as the payload inside a packet. For example, when you look at an HTTP Response packet transmitted by a Web server to a browser, you see the HTML code of the Web page the server is sending to the browser, as shown in Figure 18.24.

Figure 18.24  Network Monitor's raw data display shows the actual contents of a packet

Exercise 1: Network Indicators

Define each of the following terms in relation to the concepts discussed in this lesson.

1. SNMP
2. NLP
3. Trap
4. Link code word
5. MIB

Lesson Review

1. How does the FLP signal used by Fast Ethernet equipment differ from the NLP signal used by standard Ethernet?
2. How does the performance of a network interface adapter differ in promiscuous mode?
3. Arrange the following Ethernet technologies in the order of priority established by the FLP signal.
   1. 100Base-T4
   2. 10Base-T full-duplex
   3. 100Base-TX
   4. 10Base-T
   5. 100Base-TX full-duplex
4. What are the individual elements measured by the Windows 2000 Performance console called?
   1. Counters
   2. Statistics
   3. Alerts
   4. Traps
5. Where do agents used by network management products store their information?
   1. SNMP
   2. MIB
   3. NNTP
   4. Console

Lesson Summary

• LEDs and other lights are frequently useful indicators of a piece of equipment's current status.
• The link pulse LEDs on Ethernet hubs and network interface adapters indicate when these devices are connected properly.
• Checking error messages and event logs should be a routine activity for the network administrator.
• Network management products provide a centralized, comprehensive resource for information about the devices connected to a large enterprise network.
• Tools like the Windows 2000 Performance console enable you to monitor ongoing computer and network operations in real time.
• Protocol analyzers capture network traffic and decode it for further study.