Guide to Network Management and Troubleshooting

Guide to Network Management and Troubleshooting

by Greg Tomsho


13 New & Used Starting at $1.99


Text covers supporting and maintaining heterogeneous networking environments. Includes coverage of troubleshooting peer-to-peer and server-based networks, as well as hardware and transport layer problems.

Product Details

ISBN-13: 9780619035518
Publisher: Cengage Learning
Publication date: 01/31/2002
Edition description: BK&CD-ROM
Pages: 504
Product dimensions: 7.44(w) x 9.28(h) x 1.23(d)

Read an Excerpt

From Chapter 4: Supporting the Data Link Layer

I can hear you now: "Oh no, not the Data Link layer again! How much can we possibly talk about the Data Link layer? There isn't much to see or touch; all of the 'touchable' stuff is done at the Physical Layer, and all of the real configuration challenges occur at the Network layer where IP addressing and routers can be found. So why don't we just skip this chapter and move on to some more interesting subjects?"

Not so fast. The Data Link layer, while seemingly uninteresting, does a lot of work that you never see. In addition, its ability to recognize data delivery errors can bail you out when a boatload of trouble results from a hasty Physical layer implementation.

Let's elaborate on this idea. In a LAN, aside from the Physical layer, it is the Data Link layer where most network problems are going to occur. After all, data that travels along the Physical layer is wrapped in Data Link layer clothing, so when problems occur here, nothing moves or, if it does move, it moves slowly. In addition, when you need to expand or upgrade your network, Data Link layer issues will become a factor. Thus your thorough understanding of the components, common problems, and troubleshooting techniques at the Data Link layer will lead to a faster, more efficient network, which means much happier users.

Physical Addressing

For data to make it from a source computer to a destination computer, both computers must have physical addresses. In Ethernet networks, the physical address is a 48-bit value, expressed in hexadecimal, that is burned into the NIC. This address is referred to as the MAC address. Although many NICs allow this burned-in address to be overridden by a software assignment, this practice is not recommended because it can result in duplicate MAC addresses, which could have a disastrous effect on the network.

The MAC address is divided into two fields: the Organizationally Unique Identifier, which is 3 bytes or 24 bits in length, and the serial number, which is the remaining 24 bits. The OUI identifies the manufacturer of the NIC. The serial number portion of the MAC address uniquely identifies that NIC. The combination of OUI and unique serial number guarantees you will not have a duplicate MAC address on your network. If a company wants to manufacture Ethernet cards, it must purchase a 24-bit ID from the IEEE. As of this writing, the fee for your very own OUI is $1250.

So how is the OUI useful? Well, most protocol analyzers keep a table of current OUIs. If you are using an analyzer to capture frames, you can have the MAC addresses displayed with a vendor alphabetical code rather than with a 12-digit hexadecimal value. For example, a MAC address displayed using the 12-digit hex value for a 3Com Ethernet card might look like this: 00-20-AF-05-37-44

You can use the OUI identifier for 3Com, 00-20-AF, to display the address like this: 3Com-05-37-44

This different format can be useful in quickly identifying the type of device to which the address belongs. If you have hundreds of devices using 3Com cards, this information may not be so useful, but it would at least give you a start. For instance, if you saw a frame that a source MAC address of 00-00-81-53-9B-2C, the OUI code of 00-00-81 tells you that the address belongs to a device from Bay Networks (now part of Nortel Networks), a major manufacturer of hubs, switches, and routers. This information limits your search to these types of devices.

The first byte of the OUI also can tell you something significant about the MAC address when it is a destination address in a frame. The least significant bit (LSB) in the first byte of a MAC address is the Individual/Group (I/G) bit; it is also the rightmost bit in a byte. If this bit is 0, the frame is addressed to an individual station. If this bit is 1, the frame is a multicast or broadcast frame. If all bits in the destination MAC address are 1, the frame is an all-stations broadcast and will have the value FF-FF-FF-FF-FF-FF.

A multicast address will have the I/G bit set, but the states of the remaining bits will depend on the type of multicast. A multicast frame is one in which one or more stations should process the frame and typically is used for special applications such as routing protocol updates. A MAC address that corresponds to an IP multicast will look like this: 01-00-5e-xx-xx-xx. The 01 in the first byte shows the I/G bit is set to 1, and the 5e in the third byte specifies that this frame is an IP multicast message. The remaining bytes, designated with x's will vary depending on the specific type of IP multicast.

Errors That Occur in Frames
Ethernet provides error detection for transmitted frames by performing a CRC calculation on all bytes in the frame. The result of that calculation is 32 bit in length and is appended to a packet as the frame trailer. The trailer is called the FCS field.

When the frame is received by the destination, the destination device performs the identical calculation and compares its results with the FCS included in the frame. If the results do not match, the data was changed during transmission, and the frame is discarded.

CRC errors occur whenever data in the frame is corrupted during transmission. They can be caused by noise (Electromagnetic Interference [EMI] or radii frequency interference [RFI]), crosstalk, undetected collisions, signal reflections, and faulty hardware, to name a few.

CRC errors are not the only type of errors that can occur in an Ethernet frame. Other potential frame errors include giants, jabbers, runts, fragments, misaligned frames, and late collisions. After discussing each of these in more detail, we will look at a critical question for network administrators: How do I know when I have errors? ...

Table of Contents

1. Networking Concepts Review 2. Supporting Networks 3. Supporting the Physical Layer 4. Supporting the Data-Link Layer 5. Supporting the Network and Transport Layers 6. Supporting the Upper Layers 7. Supporting Network Operating Systems 8. Network Security 9. Network Documentation 10. Tools for Network Troubleshooting and Support

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews