Dig deep beneath the surface of your network to understand frames, addressing, and multicast vs. unicast. You’ll be a better engineer for it.

Under the Surface of Internetworking

Dig deep beneath the surface of your network to understand frames, addressing, and multicast vs. unicast. You’ll be a better engineer for it.

• By Michael Chacon
• May 01, 1999

I’ve been discussing the many services that, when added together, make up the operating system known as Windows NT. It’s important to keep in mind that the practical work of the operating system is provided by the collection and interoperability of various services. This is why I continue to look at each service independently and try to break them down to their component levels. When the services “break,” this modular approach makes it easier to troubleshoot any particular problem down to the offending area. Too often we lose sight of what we’re actually trying to accomplish with these systems. This time I’m going to dig even deeper, below all of the services, to look at the networking foundation.

Regardless of the service—and, in fact, regardless of the operating system—the essence of our jobs is to provide a platform for the disassembly and reassembly of software instructions running between two or more machines. This is the heart of networking, and it’s usually discussed under the rubric of bandwidth. What exactly consumes bandwidth on an NT network?

What’s in a Network

At its most rudimentary level, network traffic is made up of frames. Frames are electrical signals, usually transmitted across physical wires and recognized by network interface cards (NICs). The NIC drivers pull the frames off the NIC and place them into a memory buffer, where the software making up the OSI layers of the particular operating system can manipulate it according to its needs. Directing, manipulating, and controlling these frames is the essence of any internetworking system engineer’s career. To the internetworking systems engineer, it often seems that the networking system engineer’s only desire is to generate the frames that chew up the bandwidth they’re forever trying to supply. To the LAN system engineers, the internetworking engineers just can’t seem to supply the bandwidth they need to provide services to end users. It’s a mutually adversarial relationship that’s sure to continue for the foreseeable future.

Although most system engineers usually don’t deal with network traffic at this level, understanding how it behaves can be a big help when it comes to troubleshooting. And, of course, you may be interested in pursuing the internetworking career field. As has been pointed out in several articles, Cisco’s new certification program is providing a new direction for MCSEs. [To learn more about Cisco certification, see Eric Quinn’s article, "The Cisco Challenge,” in the January 1999 issue.—Ed.]

I have an Ethernet network in my house, so I’ll use it as my example for this discussion—but the principles apply to any other topology you may encounter.

Frames: The Basis for Communication

As I already mentioned, frames are the basis for communication across the wire. These frames are divided into three broad categories: broadcast, multicast, and unicast. Each frame has a source address and a destination address, which are referred to as Media Access Control (MAC) addresses. These addresses identify each node and are built into the NIC by the manufacturer. All network communication is ultimately accomplished through the discovery of and delivery to MAC addresses.

Broadcast frames are addressed to every node on a network segment, sort of like junk mail addressed to every occupant throughout a neighborhood. To send an Ethernet broadcast frame, the address FFFFFFFFFFFF is used, which means that every node will peer deeper into the frame to see if there’s any need to act on it. Almost all service discovery protocols will use this address to locate a service provider. It’s also at the core of IP and provides the basis for IP address resolution.

For example, Address Resolution Protocol (ARP) is the workhorse of IP. When a network node wants to communicate with another node on the same subnet using IP, the initiating node sends out a broadcast that contains the IP address of the desired target node. Because all network communication is based upon MAC addresses, the initiating node needs to acquire the MAC address of the target node. For instance, if the user JULIA (10.100.1.101) wants to communicate with ADAM (10.100.1.114), JULIA constructs an Ethernet broadcast frame with the destination of address FFFFFFFFFFFF. This frame also contains JULIA’s MAC address of 0020AFF86889, shown as the source address (see Figure 1).

Figure 1. In any network communication, the initiating node needs to acquire the MAC address of the target node. This Ethernet broadcast frame contains the initiating node's MAC address, shown as the source address.

Addressing

The frame is just a container. In this case, the container holds data that refers to ARP. The ARP information contains the sender’s MAC and IP address along with the target’s IP address. The desired hardware address entry is empty, because this is what ARP is requesting. Every node on this segment parses this frame until it discovers that the intended IP address doesn’t match its own IP address. These clients then discard the frame. The machine that has been assigned 10.100.1.114 will reply with a new Ethernet frame that also contains an ARP packet. However, as you can see in frame 6, it contains the MAC address 00A0C96D94BC, which is the address of the node with which JULIA wants to communicate (see Figure 2).

Figure 2. The target node replies to the initiating node with a new Ethernet frame that contains the MAC address and an ARP packet.

Now that both machines have the MAC address information they need to communicate with each other, they can begin to use individually addressed unicast frames. This reduces the need for other nodes to waste CPU cycles looking too deeply into the frame. They can now just look at the destination MAC address and discard those that don’t match their own. This information is stored in memory at each node, which is appropriately called the ARP cache. You can view the ARP cache on an NT machine by using the “ARP -a” command. As long as new frames are continuously created, the MAC addresses of intended nodes will remain in the ARP cache. When the MAC address is flushed from the ARP cache, after about two minutes this entire process repeats the next time JULIA wants to communicate with ADAM. The ARP process is the reason why IP segments are often referred to as broadcast domains.

Multicast Traffic

A multicast address is used to direct frames to a group of nodes on a segment. Each node on a segment that wants to receive multicast frames must register with the multicast group. Multicast frames are common on an NT network because of the NetBIOS workgroup and domain names that are used to identify collections of nodes. All of the browser traffic, which populates the network neighborhood, is multicast traffic. The nodes use NetBIOS registrations to become members of the multicast groups (see Figure 3).

Figure 3. Multicast addresses direct frames to a group of nodes on a segment. Nodes use NetBIOS registrations to become members of multicast groups.

The frames in Figure 3 are from the JULIA machine during the boot process. Notice the DHCP frames at the top used to deliver the IP address. The first two multicast frames are from the AUBRIE and MYLAN nodes on the network that are keeping their NetBIOS registrations active with HOST announcements. Then you can see JULIA come alive on the segment with an Ethernet frame and an ARP broadcast to her own machine as duplicate address checks. The next multicast frames are NetBIOS add commands. The <00> refers to the ComputerName and <03> to the Messenger service. The add group command refers to this node wanting to join the BATHURST domain/workgroup. One more interesting point is the ARP broadcast looking for the MAC address of the 10.100.1.1 IP address. This is the IP address of the WINS server, which this node wants to use for NetBIOS name registrations. The other common multicast implementation is with services such as streaming audio and video sites that can send one frame to many sites without the overhead of setting up individual sessions using unicast frames.

Unicast Frames

While multicast traffic is increasing, unicast frames still provide the bulk of network traffic on most networks. True to its label, unicast frames are intended for a specific node. All other nodes on the segment can discard the frame with a quick glimpse of the MAC address. Regardless of the frame type, each one has a rigid structure that allows the driver to recognize it and analyze each frame.

The beginning of each Ethernet frame is identified by eight bytes of leading ones called the preamble. When the eight bytes are seen, it’s accepted as a legitimate frame. The rest of the information is gleaned from its relative position within the frame. Immediately following the preamble is the destination MAC address. With unicast, this is all a NIC needs to process to determine if it needs to look deeper. The six bytes following the destination address are the source address. Then two bytes follow with either the length of the frame or an identification of the higher layer protocol that initiated the frame. At the tail end of each frame are four bytes used to perform a cyclic redundancy test to help verify that the frame hasn’t been damaged or tampered with during its travels.

The bulk of the frame is up to 1,500 bytes of data. This is the container of the frame. It holds the information needed by the protocol that initiated the frame. In our examples so far it, has been an IP or an ARP packet. The frame is essentially the shipping container that delivers the cargo of information used by the operating system. But it doesn’t stop here.

Each layer of the OSI model packages its relevant information as data in the layer directly below it. It’s very similar to those gift boxes that, when opened, reveal another box inside, and when that box is opened, it reveals yet another box. This creates the illusion to each layer in the protocol that it’s communicating to its direct counterpart across the network, oblivious to the underlying tasks associated with the process (see Figure 4).

Figure 4. Each protocol layer is stored as data in the layer below it.

This is also illustrated with the real example in Figure 5. As you can see, the Ethernet frame contains the IP packet, which contains the TCP packet, which contains the HTTP packet, which contains the information necessary to communicate across the Internet. At this level you can see that I was checking the weather at www.ocnow.com for the example.

Figure 5. The nesting relationships of the OSI model can be seen here, as the Ethernet frame contains the IP packet, which contains the TCP packet, which contains the HTTP packet, which contains the information necessary to communicate across the Internet.

What’s Next?

It’s important to understand what’s happening across the wire and what the expected “normal” network traffic flows are before you start troubleshooting your network. Otherwise, it’ll be like the proverbial needle in the haystack as you try to determine which packet is causing the problems or, alternatively, which packets are missing. Now that we’ve laid that groundwork, the next step is to look into the network. The answer, of course, is NETMON.EXE, otherwise known as Network Monitor. A basic version comes with every copy of Windows NT Workstation and Windows NT Server. Next month, I’ll explore this tool and show how you can use it to dig deeper into the network as well as into your technical career.