The complete guide to Mapping the OSI Model to Hyper-V

After storage, Hyper-V’s next most confusing subject is networking. There are a dizzying array of choices and possibilities. To make matters worse, many administrators don’t actually understand that much about the fundamentals because, up until now, they’ve never really had to.

• Part 1 – Mapping the OSI Model
• Part 2 – VLANs
• Part 3 – IP Routing
• Part 4 – Link Aggregation and Teaming
• Part 5 – DNS
• Part 6 – Ports, Sockets, and Applications
• Part 7 – Bindings
• Part 8 – Load-Balancing Algorithms

Why It Matters

In the Windows NT 4.0 days, the Microsoft Certified Systems Engineer exam track required passage of “Networking Essentials” and the electives included a TCP/IP exam. Neither of these exams had a corollary in the Windows 2000 track and, although I haven’t kept up much with the world of certification since the Windows 2003 series, I’m fairly certain that networking has largely disappeared from Microsoft certifications. That’s both a blessing and a curse. Basic networking isn’t overly difficult and a working knowledge can be absorbed through simple hands-on experience. More advanced, and sometimes even intermediate skills, can be involved and require a fair level of dedication. If all you really need to do is plug a Windows Server into an existing network and get it going, then a lot of that is probably excess detail that you can leave to someone else. There are certification, expertise, and career tracks available just for networking, and the network engineers and administrators that earn them deserve to have their own world separate from system engineering and administration. Learning all of that is burdensome for systems administrators and is unlikely to pay dividends, especially with the risk of skill rot. The downside is that it’s no longer good enough to know how to set up a vendor team and slam in some basic IP information. Too many systems people have ignored the networking stacks in favor of their servers and applications and are now playing catch-up as integrated teaming, datacenter bridging, software-defined networking, and other technologies escape the confines of netops and intrude into the formerly tidy world of sysops.

The first post of this series will (re)introduce you to the fundamentals of networking that you will build the rest of your Hyper-V networking understanding upon.

The OSI Model

If you’ve never heard the phrases “All People Seem To Need Data Processing” or “Please Do Not Throw Sausage Pizza Away”, then someone along your technical education path has done you a great disservice (or you learned the OSI model in a non-English language). These are mnemonics used by students to drill for exams that test on the seven layers of the OSI model, which obviously worked because I can still recall them fifteen years later:

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

Oddly enough, I’ve never been asked on any test what “OSI” stands for and I had to look that up: Open Systems Interconnection. Now you know what to put on that blank Apples to Apples card if you want to never be invited to a party again.

The reason that we have two mnemonics is because traffic travels both ways in the model. If your application is Skype, then the model covers your voice being broken into a rush of electrons (from seventh down to first layer) and back into something that might sound almost like you on the other side of an ocean (from first up to seventh layer).

The OSI model is a true model in that it does nothing but describe how a complete networking stack might look. In practice, there is nothing that perfectly matches to this model. The idea is that each of the seven layers performs a particular function in network communications, but only knows enough to interoperate with the layer immediately above and immediately below. So, no jumping from the physical layer to the presentation layer, for instance.

I’m not going to spend a bunch of time on the seven layers. There are a lot of great references and guides available on the Internet, so if you really care, do some searching and find the resource that suits your learning model. If you’re in systems or network administration/engineering, layers six and seven will likely never be of any real concern to you. You might occasionally care about layer five. We’re really focused on layers one through four, and that’s what we’ll talk about.

Use the following diagram as a visual reference for the upcoming sections:

Layer One

In theory, layer one is extremely easy to understand; it’s all in the name: “physical”. This is the electrons and the wires and fiber and switch ports and network adapters and such. It’s the world of twisted pairs and CAT-5e and crossover. In practice, it’s always messier. This is also the world of crosstalk and interference and phrases like, “Hey, we can use the ballasts in these fluorescent lights as anchors for the network cable, right?” and, “I only use cables with red jackets because they have better throughput than the blue ones,” and all sorts of other things that are pretty maddening if you spend too much time thinking about them. We’ll move along quickly. Just be aware that cables and switches are important, and they break, and they need to be cared for.

Layer Two

Layer two is where things start to get fuzzy. From this point upward, everything exists because we say it does. It’s the first level at which those pulses of light and electron bursts take on some sort of meaning. For us in the Hyper-V world, it’s mostly going to be Ethernet. The unit of communication in Ethernet is the frame. In keeping with our layered model concept, the frame was a sequence of light or electric pulses that some physical device, like a network adapter, has re-interpreted into digital bits. The Ethernet specification says that a series of bits has a particular format and meaning. An incoming series of these bits starts with a header and is then followed by what is expected to be a data section (called the payload), and ends with a set of validation bits. This is the first demonstration point of the OSI model: layer one handles all the nasty parts of converting pulses to data bits and back. Layer two is only aware of and concerned with the ordering of these bits.

The Ethernet Frame

By tearing apart the Ethernet frame header, we can see most of the basic features that live in this layer.

Tagged Ethernet Frame

The first thing of note is the destination and source MAC addresses (“media access control address”). On any Windows machine, run IPCONFIG /ALL and you’ll find the MAC address in the Physical Address field. Run Get-NetAdapter in PowerShell and you can retrieve the value of the MacAddress field or the LinkLayerAddress field. The MAC address comes in six binary octets, usually represented in two-digit hexadecimal number groupings, like this: E0-06-E6-2A-CD-FB. In case it’s not obvious, the hyphens are only present to make it human readable. You’ll sometimes see colons used, or no delimiters at all. Every network device manufacturer and (some other entities) have their own prefix(-es), indicated in the first three octets. If you search the Internet for “MAC address prefix lookup”, you’ll find a number of sites that allow you to identify the actual manufacturer of the network chip on your branded adapter.

The presence of the MAC address in the Ethernet frame tells us that layer 2 is what deals with these addresses. Therefore, it could also be said that this is the level at which we will find ARP (address resolution protocol), although, as a tangent, it could also be considered as layer 3. Either way, all data that travels across an Ethernet network knows only about MAC addresses. There is no other addressing scheme available here. TCP/IP and its attendant IP addresses have no presence in Ethernet, and unless you get really deep into the technicalities, TCP/IP isn’t considered to be in layer two at all. It’s vital that you understand this, as it is a common stumbling point that presents a surprisingly high barrier to comprehension. As a bit of a trivia piece, the ability to manage MAC addresses and tables is what differentiates a switch from a hub.

Next, we might encounter the 802.1q tag. This is the technology that enables VLANs to work. This is a potentially confusing topic and will get its own section later. For now, just be aware that, if present, VLAN information lives in the Ethernet frame which means it is part of layer 2. Layer 3 and upward have no idea that VLANs even exist.

What puts layer two right in the face of the Windows administrator is the fact that the Hyper-V virtual switch and Windows network adapter teaming live at this level. Without an ability to parse the Ethernet frame, teaming cannot work at all. It must be able to work with MAC addresses. The Hyper-V virtual switch is a switch, and as such it must also be aware of MAC addresses. It also happens to be a smart switch, so it must also know how to work with 802.1q VLAN tags.

A fairly recent addition to the Ethernet specification is Datacenter Bridging (DCB). This is an advanced subject that I might write a dedicated article about, as it is a large and complex topic in its own right. The basic goal of DCB is to overcome the lossy nature of TCP/IP in the datacenter where data loss is both unnecessary and undesirable. There are a number of implementations, but the Ethernet versions include some way of tagging the frame. The significance is that Windows can apply a DCB tag to traffic and DCB-aware physical switches are able to process and prioritize traffic according to these tags. You need a fairly large TCP/IP network for this to be an issue of major concern as most LANs see so little contention that any data loss usually indicates a broken component.

The final thing we’re going to talk about here is the payload. In the modern Windows world, the content of this payload is a TCP/IP packet. It doesn’t have to be that, though. In days of yore, it might have been an IPX/SPX packet. Or a NetBEUI packet. Or anything. All that Ethernet cares about is the destination MAC address. Once the frame is delivered, layer two will unpackage the packet and deliver it up to layer three to deal with.

Layer Three

Here is where we first begin to encounter TCP/IP. A couple of things to note here. First, TCP/IP is not really a protocol, but a protocol group. TCP is one of them, IP is another, so on and so forth. Second, it’s also where you really start to see that the layers of the OSI model are only conceptual, because a number of things could be considered to exist in multiple layers simultaneously.

Layer three is where we start talking about the packet as opposed to the frame. Ethernet (or Token Ring, or any other layer 2 protocol… it doesn’t really matter) has delivered the frame and the payload has been extracted for processing. Everything layer 2-related is now gone: no MAC address. No 802.1q tag. In general, the network adapter driver is the first and last thing in your Windows system to know anything about the Ethernet frame. After that, Windows takes over with the TCP/IP stack.

What we have at this level is IP. The stand-out feature of IP is, of course, the IP address. This is a four-octet binary number that is usually represented in dotted-decimal notation, like this: 192.168.25.37. IP is the addressing mechanism of layer three.

TCP/IP traffic is packaged in the packet. In many ways, it looks similar to the Ethernet frame. It has a defined sequence that includes a header and a data section. Inside the header, we find source and destination IP addresses. This is also the point at which we can start thinking about routing.

A very important fact to know when you’re testing a network is that ICMP (which means PING for most of us) lives in layer 3, not layer 4. You need to be aware of this because you will see behaviors in ICMP that don’t make a lot of sense when you try to think of them in terms of layer 4 behavior, especially in comparison to TCP and UDP. We’ll talk about this again once we are introduced to layer 4.

What’s not here is the Hyper-V virtual switch. It has no IP address of its own and is generally oblivious to the fact that IP addresses exist. When you “share” the physical adapter that a Hyper-V switch is assigned to, what actually happens is that a virtual network adapter is created for the management operating system. That virtual adapter “connects” to the Hyper-V virtual switch at layer one (which is, of course virtual). It does the work of bringing the layer two information off the Hyper-V switch into the layer three world of the management operating system. So, the virtual switch and virtual adapter are in layers one and two, but only the adapter can be said to meaningfully participate in layer three at all.

The Hyper-V Server/Windows Server team is also not really in level three. You do create a team interface, but it also works much like Hyper-V’s virtual adapter.

Layer Four

Layer four is where we find much more of the TCP/IP stack, particularly TCP and UDP. The OSI model is really fuzzy at this point, because these protocols are advertised right there in the TCP/IP packet header, which is definitely a layer three object. However, it is the TCP/IP control software operating in this layer that is responsible for the packaging and handling of these various packets, and the actual differences are seen inside the payload portion of the packet. For the most part, Hyper-V administrators don’t really need to think much about layer four operations, but having no understanding of them will hurt.

The features that we see in layer four are really what made TCP/IP the most popular protocol. This is especially true for TCP, which allows for packets to be lost while preventing data loss. TCP packets are tracked from source to destination, and if one never arrives, the recipient can signal for a retransmission. So, if a few packets in a stream happen to travel a different route and arrive out of order, this protocol can put them back into their original intended pattern. UDP does not do this, but it shares TCP’s ability to detect problems.

This capability is really what separates layer three from layer four, and why ICMP doesn’t behave like a layer four protocol. For instance, if you’re running a Live Migration and a ping is dropped, that doesn’t mean that TCP will be affected at all. I’ve heard it said that ICMP is designed to find network problems and that’s why it fails when other protocols don’t. That’s true to some degree, but it’s also because the functionality that allows TCP and UDP to deal with aberrations in the network are not layer 3 functions.

Encapsulation

The best summary of the process described by the OSI model is that networking is a series of encapsulation. The following illustration shows this at the levels we’ve discussed:

Each successive layer takes the output of the previous layer, and depending on the direction that the data is flowing, either encapsulates it with that layer’s information or unpacks the data for further processing.

What’s Next

In the next installment of this series, we’ll start to see application of these concepts by tearing into VLANs.