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.
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:
- Physical
- Data Link
- Network
- Transport
- Session
- Presentation
- 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.
The first thing of note is the source and destination 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.
No comments: