Hyper-V and Networking – Part 2: VLANs
In the first part of this series, we started with the foundational
concepts of networking in the OSI model and took a brief look at where
Hyper-V components live in that model. In this part, we’ll build on that
knowledge by looking at the operation of VLANs and how they work within
the context of a Hyper-V deployment.
- 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
VLANs
“VLAN” is an acronym for Virtual Local Area Network. This concept
predates most of the virtualization technologies that are common today
and should not be confused with anything in the computer virtualization
or software-defined networking worlds.
To recap the first post, the VLAN exists at layer 2 in the OSI model.
The significance is that this has nothing to do with IP addresses,
although some of the basic rules are similar. Everything at this level
is done by MAC address. Within any given Ethernet network, all endpoints
must have a MAC address and all MAC addresses must be unique. Usually
that’s not tough, given that any single prefix can have almost 17
million unique MAC addresses and manufacturers with that many devices
also have more than one prefix.
What a VLAN does is set up a unique Ethernet network. The definition
that I commonly see is that each VLAN represents a distinct “broadcast
network”. While this explanation is the simplest, I dislike it as it is
often confused with IP broadcasting. In Ethernet networking, a
“broadcast network” indicates all the endpoints that will receive a
frame transmitted to FF-FF-FF-FF-FF-FF. Even though it’s not a wonderful
definition, most of the others get so complicated that you forget the
question. So, rather than dig into it like that, just look at the
functionality.
In a simple network using very basic switches, that means every
single plugged-in and live endpoint will receive a broadcast. Switches
capable of setting up VLANs can specify that some of their switch ports
are members of a particular VLAN. So, an Ethernet frame
traveling on VLAN 1 will not be delivered to any switchport that is not
a member of VLAN 1. However, this distinction is entirely “virtual”.
The only thing that sets the frames apart is the value in the 802.1q tag
— and it might not even be there.
Many network devices can’t process an 802.1q tag at all. If an
Ethernet frame is received with this tag, a great many devices will
treat the frame as malformed. Most of the rest will ignore it. For this
reason, you rarely want to point frames with 802.1q tags at physical
devices other than switches. Usually, the tag is only present is when a
frame passes through a “trunk”. A trunk is a single connection that
carries multiple VLANs. In all other cases, switches keep track of which
VLAN that traffic for a given port should be in.
Access Mode/PVID
In Cisco and Microsoft networking, ports can be set in “access mode”. If they aren’t set with anything else, then they will always
communicate using untagged frames. In the Cisco world, this could be
subjected to the device’s default VLAN. The Hyper-V switch has no
default VLAN, or perhaps more properly, the default is always untagged.
If the port is set to a specific VLAN, then that port becomes a member
of that VLAN. Its frames are still untagged, but the
switch will only allow that port to communicate with other devices on
the same VLAN. The non-Microsoft/non-Cisco world corollary to an access
mode port is PVID (port VLAN identifier). Only the term is different.
Functionality is the same. To reiterate, access mode ports move traffic
untagged, but only within a single specified VLAN.
Trunk Mode/Tagged
In Cisco and Microsoft networking, ports can be set in “trunk mode”
instead of access mode. The purpose of trunk mode is to connect to
another switch. In trunk mode, the port can become a member of multiple
VLANs. VLANs that the trunk should process are added to the allowed list
for Cisco and Microsoft switches. On most other devices, a port is
considered to be in the equivalent of trunk mode by virtue of having one
or more VLANs specified in its “tagged” list. Frames with other tags
are discarded.
Native/Untagged VLANs
A trunk on a Cisco or Microsoft switch can be assigned a native VLAN.
It then becomes a member of the network shared by all ports on the
switch assigned to that VLAN just as it would if that were simply
another of the allowed VLANs. Only one VLAN can be configured on a trunk
in this method, or traffic in these VLANs would be inextricably
combined into a single network. This is because frames that this trunk
sends to the other switch travel without an 802.1q tag, and all incoming
frames without a tag are treated as members of this VLAN. For a
Cisco/Microsoft switch, this will be determined by the receiving trunk’s
native VLAN setting. For all others, the equivalent fo the native VLAN
is set by designating a single untagged VLAN for the trunk.
Comparing Cisco/Microsoft to other Manufacturers
The nice thing about the Cisco/Microsoft switches is that the usage
of “access mode” and “trunk mode” make it pretty clear what’s going on.
For everyone else, use “PVID” instead of “access mode” and “tagged”
and/or “untagged” instead of “trunk mode”.
Hypothetical VLAN Configuration
Let’s look at an example. I have one Cisco 20-port smart switch (or a
Microsoft Hyper-V external virtual switch) and one Netgear 20-port
smart switch. I’m going to configure them as identically as possible,
then plug them into each other.
In my network, I’ve decided that servers should participate in VLAN
10, desktops should participate in VLAN 20, and printers should
participate in VLAN 30. On each switch, I want to designate ports 1-6
for servers, 7-12 for desktops, 13-18 for printers, and 20 for the link
between switches. I will leave 19 unused.
Access Port Configurations
On the Cisco switch, I will set ports 1-6 in access mode
for VLAN 10. I will set ports 7-12 in access mode for VLAN 20. I will
set ports 13-18 in access mode for VLAN 30. I will plug in the devices
as normal and just give them IP addresses as normal.
On the Netgear switch, I will assign ports 1-6 a PVID of 10. I will
assign ports 7-12 a PVID of 20. I will assign ports 13-18 a PVID of 30.
Trunk Port Configurations
On the Cisco switch, I will set port 20 to trunk mode. I will give it a native VLAN of 10 and add 10, 20, and 30 to its allowed VLANs list.
On the Netgear switch, I will set port 20 so that it allows untagged
traffic for VLAN 10 and tagged traffic for VLANs 20 and 30. As a matter
of habit, I also usually set these with a PVID that matches the untagged
VLAN, but I don’t think that’s actually necessary.
Results
Now that this is done, I’ll plug in servers, desktops, and printers
to all these ports as indicated. I will use a standard patch cable to
connect port 20 on the Cisco switch to port 20 on the Netgear. Now, the
server plugged into port 1 on the Cisco switch will be able to send and
receive Ethernet frames directly to/from devices plugged into ports 2-6
and 20 on the Cisco switch and ports 1-6 and 20 on the Netgear switch.
Those frames will never be tagged.
A desktop plugged into port 7 on the Cisco switch will be able to
send and receive Ethernet frames directly to from devices in ports 8-12
on that switch and 7-12 on the other. However, unlike the VLAN 10 ports,
its frames will cross the inter-switch link with an 802.1q tag of 20.
Once these tagged frames arrive on the receiving switch, the tag is
removed. But, the switch will only allow those frames to be visible to
ports that are members of VLAN 10. This is the same behavior that will
be seen for members of VLAN 20.
Port Channels/Link Aggregation
I know that at least a few of you are looking at that diagram and
wondering why I wouldn’t put ports 19 and 20 on both switches into an
aggregated link. The answer is: actually, I would. That’s not what this
article is about though. We’ll revisit all that in a later installment.
Management VLANs
I haven’t talked about management VLANs, which is mostly because
they’re not really in-scope for Hyper-V. Hyper-V either tags a frame or
it doesn’t; it doesn’t really have a concept of a default VLAN or a
management VLAN.
The management VLAN is really just a VLAN that compliant network
devices will respond on. So, if I assign an IP of 192.168.75.100 to a
switch, it will give that IP address a presence inside its designated
management VLAN’s Ethernet space. The default for most devices is VLAN
1, and for security purposes, it’s usually recommended that you change
it. Since the Hyper-V switch has no IP address, it has no purpose for a
management VLAN. The management VLANs are trunked and (un)tagged and
accessed and PVID’d just like any other VLAN, although also for security
purposes, it’s best if only network infrastructure devices’ management
IPs are in it.
Hyper-V VLANs
The Hyper-V terminology usually lines up better with Cisco than with
the others (confusing or not, these others are actually following
standards most closely). The first difference is that you never really
see anything about virtual switch ports unless you travel deep down the
path where most are afraid to tread. Usually, you set these options
directly on the virtual network adapter. That’s works well in this case
because Hyper-V controls the switch, the switch ports, and the virtual
network adapters. So, it doesn’t really need to distinguish between the
port and the adapter.
When the Hyper-V virtual switch takes over a physical network
adapter, that network adapter become an “uplink”. So, instead of the
Cisco switch in our example network above, imagine that it’s a Hyper-V
switch. The host’s physical adapter it’s assigned to is plugged into
port 20 on the Netgear.
The big thing to be aware of is that we don’t, and can’t, configure
this particular trunk “port” in Hyper-V. So, no native/untagged VLAN
when connecting in to the physical network.
This just means that Hyper-V
isn’t going to be able to strip VLAN ID’s from traffic leaving virtual
machines. It will be able to accept incoming untagged traffic, of
course. Just leave the VLAN ID off of any virtual adapter you want to
receive from the incoming switch’s native VLAN ID. The Hyper-V switch’s
“uplink” port will send the outgoing traffic of any VM without a defined
VLAN without an 802.1q tag, so it will end up in the connected switch’s
native VLAN.
Besides that, the Hyper-V virtual switch behaves like any other
switch. Switch ports are set in access mode. As previously stated, any
port without a defined VLAN winds up in the connected switch’s native or
untagged VLAN. All other ports communicate on their designated VLAN,
which is analogous to Cisco’s access mode or a non-Cisco switch’s PVID.
VLAN Isolation
By their very nature, VLANs are isolated. You can’t move traffic from
one VLAN to another without communicating through a device that is
present on both VLANs. There is a capacity issue, however, as there is a
maximum of 4095 VLANs. There is a functionality issue if you need to
connect duplicate IP subnets to the same router. While exceedingly rare
in the SMB space, these situations are not uncommon at companies that
host networks for others. As an example, you might have two clients who
both use 192.168.0.0/24. The easiest way to deal with that is to simply
use a dedicated VLAN for each client and ensure that they can only
communicate off of their own VLANs by using a router that employs
network address translation (NAT). But, this is still subject to the
scalability issue.
The first option is to use Private VLANs. This requires nothing other
than what Hyper-V itself can provide. With this configuration, each
virtual adapter to use a private VLAN has three configuration steps.
First, it is set as promiscuous, community or isolated. Second, it is
given a primary VLAN. Finally, depending on the mode, it is given a
secondary VLAN or a list of allowed secondary VLANs. How it behaves
depends on the first option that was set. This isn’t something I want to
spend a lot of time on, first because I’m not very well-versed in it
myself and second, I expect that if you really need it, you have access
to a network engineer who can explain it to you and/or help you
configure it.
The second option is to use network virtualization. This requires
VMM, but it also allows you to create fully isolated networks. I also
won’t spend much time on this, partially because I feel it’s been done better elsewhere,
partially because I’m also not well-versed in it, and partially
because, just like private VLANs, I don’t see where the majority of
installations will have an immediate need for it. But, because I think
that the hybrid cloud will eventually encroach on most of our networks. I
do think this is something that’s worthwhile for most Hyper-V
administrators to learn in the long run. Just not necessarily right
away.
Hyper-V Switch Trunk Mode
The Hyper-V switch allows you to set a virtual adapter into trunk
mode. The usefulness of this is in the eye of the beholder, since unlike
a physical switch, a Hyper-V switch can only provide a connection
between virtual machines and a single physical switch. So, aside from
the trunk that exists on an external virtual switch represented by the
physical NIC, it can’t trunk to any other switch. Also, as you’ll
remember from the first post in this series,
VLANs exist at layer 2. IP addresses don’t appear until layer 3.
The
practical meaning of that is that all the things you’re used to
configuring inside virtual machines know nothing about VLANs. The frames
will arrive with the 802.1q tag intact, but you’ll need an application
inside the guest that knows what to do with it in order to make any use
of this feature. What I see people trying to do is set up the Windows
Remote Access Service (RAS, formerly Routing and Remote Access Service,
or RRAS) to process VLANs. RAS works at layer 3 and above, so it can’t
process these VLAN tags.
No comments: