Ethernet in a Nutshell

By Patrick Hunter

The last two installments of “IP address” were geared toward end-to-end IP communication across our networks. Understanding the difference between how traffic is switched across local networks and routed across many remote networks was an important distinction. After thinking it over, I decided that I wanted to take a deeper dive into the local aspects of network transmission and get a deeper sense of how devices at the data link layer perform their assigned functions.

For a refresher, Ethernet was standardized as IEEE 802.3 in 1983. Remember, the standard covers both physical wiring and signaling standards at Layer 1 of the OSI model as well as functionality at Layer 2, the data link layer. Now let’s dive in.

First, recall that all of our devices connected to today’s networks are equipped with network adapters, which include those ubiquitous “Ethernet” ports but also the all-important media access control (MAC) address. Remember that each network adapter should have a unique MAC address assigned to it and that this address is the identifier for the local network. Any other network adapter that is attempting to forward information to a particular computer must have the MAC address associated with the device. Also, recall that MAC addresses are 48-bit addresses (think binary, so 48 ones and zeros in a row), typically represented as a hexadecimal number similar to this example address: 001c.3452.ed2c.

So, in today’s Ethernet networks, how exactly do the nuts and bolts really fit together and work? Let’s dive in to this discussion by first examining the MAC addresses and their structure. There are technically three different types of MAC addresses that can be used when an Ethernet-compliant device is forwarding information. The unicast MAC address is exactly what we’ve been describing here for network adapters; it’s the one unique address that represents one unique host (thus, “uni”cast). There are also multicast MAC addresses, but they aren’t as commonly used in a typical local area network (LAN), so we won’t go into great detail on those here. Lastly, the broadcast MAC address is common and important. The broadcast MAC address is indicated as all ones in the binary form, which is equal to ffff.ffff.ffff in our traditional hexadecimal notation. Later, we’ll cover more on why unicast versus broadcast addressing is relevant and how they are handled.

We just noted above that any network adapter that is attempting to forward information to a particular computer must know the MAC address associated with that device. But, how exactly can our network adapter find that information? In the IPv4 world, this is accomplished through a process known as Address Resolution Protocol (ARP). The rules of ARP tell us that if an IP address is known (we can safely assume that it is known here), an Ethernet-compliant network adapter can “ask” everyone in its LAN to tell it which adapter has a particular IP address. Let’s walk through that process.

Computer “A” needs to send an Ethernet frame to another computer, and A only knows the IP address, not the MAC address. Since A doesn’t have the destination MAC address, it sets the original frame aside so that it can seek out the missing information. A constructs an ARP frame to find out the MAC address it needs. The contents of the ARP frame essentially asks everyone on the LAN, “Who has IP address x.x.x.x? Tell me.” The source MAC address of the ARP request is A’s MAC address, and the destination MAC address is… you guessed it, the broadcast MAC address ffff.ffff.ffff! When every network adapter in the LAN receives the frame, because it is addressed to ffff.ffff.ffff, everyone will open the frame up and see that it is intended for whichever computer has IP address x.x.x.x. Since only one of the computers should have x.x.x.x, only one of them will answer while all the others in the LAN will simply ignore the ARP request since it wasn’t intended for them anyway. Essentially, when computer “B” answers the ARP request, because its reply will include its MAC address as the source address in the ARP reply frame, computer A will clearly have learned the MAC address it needed to send the original message. After that, the newly-learned destination MAC address will be added to the previously queued frame and sent toward the correct computer’s network adapter for processing.

Now that we know what types of MAC addresses there are, and we understand how different network adapters can “learn” MAC addresses of devices on their local network, we still need to discuss the function of an Ethernet bridge or switch. Remember, an Ethernet switch is just a multiport bridge. Also recall that an Ethernet bridge does exactly what its name implies: it bridges different segments of a local network together. Now, one point that really had me confused as I learned about this technology was the fact that each port on a switch has its own MAC address and switches can even have more MAC addresses than that! So, naturally in my head, I tried to figure out what relevance those MAC addresses had, and how they played into the overall LAN communication, like our ARP discussion, for example.

While it may be obvious to some, it wasn’t so obvious to me that the MAC addresses on the different interfaces, or ports, on the switch weren’t really all that relevant at all. I mean, think about it.

If a computer wants to send a packet (and thus an Ethernet frame) to another computer, does it really need to know or care about some Ethernet hub, bridge, or switch in order to do that?

As it turns out, the creators of the Ethernet protocol decided that it didn’t! I didn’t see the brilliance in that until I looked closer at how a switch operates. Let’s do that now.

At this point, a quick review of the rules (think, protocol) for Ethernet tells network adapters associated with different computers to do a couple of things. (1) If we receive a valid, error-free Ethernet frame, check the destination MAC address. (2) If it is our MAC address OR the broadcast address, it may be for us, so “decapsulate” the frame and pass it on to the higher layer process (typically the IP process at OSI Layer 3). If it is not, then it must not be for us, so we will discard the frame.

So, a switch, which you might remember is simply a very specialized computer with specialized hardware serving a very specialized purpose (switch Ethernet frames reliably and quickly), has its own set of rules to follow when receiving an Ethernet frame. (Step 0) Place the incoming frame into a special buffer for examination. (1) If we receive a valid, error-free Ethernet frame, check the source MAC address of the frame. (2) Note the physical interface on which we received that frame and the source address in a table. This table mapping source MAC addresses to physical ports is known as the “MAC address table” (super original, I know). (3) Examine the destination MAC address. Based on that information, proceed to either step 4 (unicast MAC address) or step 5 (broadcast MAC address). (4) If the destination address is unicast, then we have to look in our MAC address table to see if we know off of which port that device lives. (4a) If we know, then we switch the frame out with the appropriate interface and proceed to step 6. (4b) If we don’t know, then make a copy of the frame to send out every active interface in this broadcast domain, except the interface from which the frame originated (this process is known as “flooding”) and proceed to step 6. (5) If the destination address is broadcast, then we can safely assume it is intended for every network adapter on the LAN and we make a copy of the frame to send out every active interface in this broadcast domain, except the interface from which the frame originated. (6) Flush any copies of the frame and wait for the next incoming frame.

Now, notice for a minute that once a frame has passed through the switch or even if it failed to pass through because it was invalid or erroneous, the switch does not keep track of the conversation nor worry about whether the destination ever received that frame. That’s not its job. Ethernet is concerned with making sure the frames get passed onto the wire, hopefully to end up at the correct destination. When something goes wrong, other higher-layer protocols do the work to attempt to correct the problem. That’s a great picture of what’s happening at the cable modem all the time: it’s just a high-powered Ethernet bridge doing its job for the customer’s Internet connection.

This is certainly a lot to take in the first time you read it. But a simple flowchart helps to create the idea. The switch just has two important jobs: populate its MAC address table and decide whether or not to forward the frame out to one specific interface or to flood a copy of the frame out to all active interfaces. That’s really the basic job of a switch. There are certainly more features and functions involved for a modern high-availability, high-throughput Ethernet switch, but the basis of its function has never really changed for the most part. It and the protocol (Ethernet) continue to be the foundation of nearly every bit of electronic communication, wired and wireless, local area and wide area, across the globe. A technician or engineer in this business should have the hunger to learn the basics like this until they are deeply ingrained in his or her brain. The value for this knowledge will never stop paying off.


Patrick Hunter Charter CommunicationsPatrick Hunter — “Hunter”

Director, IT Enterprise Network and Telecom,
Charter Communications
hunter.hunter@charter.com

Hunter has been employed with Charter since 2000 and has held numerous positions, from Installer, System Technician, Technical Operations management, Sales Engineer, and Network Engineer. His responsibilities include providing IP connectivity to all users in Charter’s approximately 4,000 facilities, including executive and regional offices, technical centers, call centers, stores, headends, hubsites, and data centers. Mr. Hunter has served on the SCTE Gateway Chapter Board of Directors since 2005. He spends his spare time mentoring, teaching, and speaking on IP and Ethernet networks as well as careers in the network field.


Credit: Shutterstock
Credit: Cartoonstock.com