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.
03>00>