Well virtual technology is pretty cool except that we kind of created a mess
around networking within the virtual space. For example, think about the fact
that we've got this single host and now I have these two different virtual
machines each one with their own MAC address, each one with their own IP
address. Remember these are full operating system instances so if my home PC or
physical device has network identities well so does each individual virtual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
physical device has network identities well so does each individual virtual
machine. And now this physical host has a physical network connection going up
to a switch. So how do these virtual machines communicate with one another? If
I
send a packet up to the switch and it's destined for this other virtual machine
we might think okay well the switch just turns around and sends it back down
and
maybe that's inefficient but at least that would work right? Except it's not
going to work. This is trombone it's bringing it into the same interface and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to work. This is trombone it's bringing it into the same interface and
trying to send it back out the same interface and this is not allowed. The
switch will never bring a packet into one interface and send it right back out
the same interface. So how can these two virtual machines communicate with one
another? If we have 20 virtual machines on this host how can they communicate
with
one another? Well this is going to lead us to a conversation around virtual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one another? Well this is going to lead us to a conversation around virtual
networking because we are going to have to deploy networking inside now of our
physical server our virtual host. This server here that we've built out virtual
machines on. So let's draw this out a little bit bigger. We have our virtual
host here and let's just draw a handful of virtual machines and once again each
one of these virtual machines will have its own MAC addresses and IP addresses WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one of these virtual machines will have its own MAC addresses and IP addresses
and such. Now we're still going to have physical uplinks in fact we might find
that we have multiple physical uplinks coming into the host maybe this is
for additional bandwidth maybe it's for traffic segmentation. There's actually
it's not uncommon to see eight to ten connections going to a single host. So
keep that in mind. But let's just draw four connections here maybe these are
each 25 gigabits per second and they're all going to this one virtual host. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
each 25 gigabits per second and they're all going to this one virtual host. So
now this host and by the way at this point we're really talking about the
hypervisor because the responsibility of the hypervisors to manage all this but
the hypervisor has to manage networking here. So how do we go about doing it?
Well at the heart of it we're going to need to deploy what we call a virtual
switch which is usually abbreviated as a V switch. This virtual switch is fully
capable of switching packets in the same way that a physical layer to switch
would be capable of. In fact it can support things like VLANs. It can support WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
would be capable of. In fact it can support things like VLANs. It can support
things like trunks and we can even enable span on this to bridge traffic for
the
sake of traffic monitoring. And so these V switches even though they're virtual
they're going to through software terminate these physical connections that
go out to the rest of the world. And then internally we're going to connect to
the virtual nicks that exist on these virtual machines. So now we see exactly WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the virtual nicks that exist on these virtual machines. So now we see exactly
how these virtual machines are able to communicate with one another. They
simply
get switched through this software instance of a switch. So this virtual
switch that lives inside of the hypervisor and now can switch traffic
between them. So mission accomplished right? Except once again we keep coming
back to some problems. For example look at what I just did. I just created a
network loop. That's not great. And so do we really want to extend spanning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network loop. That's not great. And so do we really want to extend spanning
tree operation down into this virtual layer where we have to block one of
these ports because we do want redundancy. We don't want to lose one of
these connections and isolate the virtual switch for example. What are we
going to do about this? Well to directly answer that we are not going to want
to
run spanning tree. We don't want to do it. That would create a very large mess
for us in the networking world to to manage and maintain a spanning tree
topology that now goes all the way down into the virtual host. And again we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
topology that now goes all the way down into the virtual host. And again we
might
have dozens of these virtual hosts. So instead we're going to use a different
concept that is known as pinning. This is a critical concept inside of data
center networking. It's used at the virtual layer. It's also used in Cisco
UCS quite a bit. And so it becomes very important inside of data center
networking in general. The idea here is that outbound traffic gets pinned to a
specific uplink. So what this means is if a virtual machine wants to send a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specific uplink. So what this means is if a virtual machine wants to send a
packet out to the rest of the network, well now it's going to have to go out
the network but it gets pinned using dotted lines here to represent this to a
specific uplink. So let's say these two virtual machines get pinned to
different
uplinks. So now the virtual machine on the left will send all of its traffic
upstream on the port on the left. The virtual machine on the right is going to
use the port on the right. And it will always use that pinned uplink. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
use the port on the right. And it will always use that pinned uplink.
Furthermore
we're never going to bridge and loop traffic from one let's say we send a
broadcast packet down one link. We're never going to loop it back around. This
breaks the rules between pinned uplinks. Instead if I get a flooded packet, let
's
just change the colors here to make it clear. If I get a broadcast packet and
it comes onto this switch it needs to get sent out. Well the switch is going to
view both of these links as any link. I'm going to have to send this broadcast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
view both of these links as any link. I'm going to have to send this broadcast
packet out both of these connections. But that's a good thing because the
broadcast that comes on the left will hit the virtual machine on the left. The
broadcast that's on the right will hit the virtual machine on the right. And
once
again I'm not going to bridge the gap here. And as a result we do successfully
deliver our broadcast packets to the virtual machines without looping traffic
back around and duplicating packets. So this pinned nature also works from a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
back around and duplicating packets. So this pinned nature also works from a
broadcast perspective. So a broadcast inbound is going to get sent along the
pinned link to the virtual machine as well. Now it is worth noting that we can
actually support port channels here. But they're really not real needed. There
's
almost no benefit to doing so. So I could bundle these together for example and
the switch would just see that as it may be an LACP port channel and we could
say that that's useful other than now we just have a single pinned up link. We WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
say that that's useful other than now we just have a single pinned up link. We
're
getting load balancing and redundancy through the port channel. But notice
before we did this we already had redundancy. That's a great thing about
pinning is we have redundancy and we have load balancing. And so there's not
nearly as much value in deploying a port channel into this type of
environment although some enterprises do choose to still deploy port channels.
So
notice that I left a whole blank part of this hypervisor over on the right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
notice that I left a whole blank part of this hypervisor over on the right.
Well that's because we might actually see that there's value in deploying a
second V switch. So now the second V switch is going to communicate with all
of the other connections that we see here. We use pinning in the same way. Then
you
say well why do we do this? Why wouldn't we just all connect all the virtual
machines to the same V switch? Well this creates network segmentation. Now this
means that if these two virtual machines want to communicate, I mean just look
at
the network paths here. How do they communicate? Believe it or not it's going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the network paths here. How do they communicate? Believe it or not it's going
to have to send from one virtual machine up to the switch get sent back around
on
down. We said on the left here that we can't go in and out of the same
interface but there's nothing saying we can't follow normal switching rules and
use different interfaces. And so that's exactly what we do to communicate from
one virtual machine on one V switch to a virtual machine on the other V switch.
And so it's pretty common in virtual networking again to use a lot of
different connections to create many different V switches on the hypervisor WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
different connections to create many different V switches on the hypervisor
and try to keep different network types isolated. For example storage
networking probably shouldn't be on the same V switch as our DMZ type of
traffic
if we're extending that into our virtual environment. So we do have multiple
different V switch types and it really just comes down to how we want to manage
this. So there is a standard V switch which we use in our smaller environments WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this. So there is a standard V switch which we use in our smaller environments
and it basically just indicates that we configure this on a per host basis.
So I get onto my host I configure as many V switches as I want but then on the
next host I have to also configure as many V switches as I want. So this can
you know again scale out to maybe four or five six hosts and that's not that
big
of a deal. But what we might want to do in enterprise networks is use a
distributed virtual switch. The distributed virtual switch sounds pretty WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
distributed virtual switch. The distributed virtual switch sounds pretty
fancy but it really is just a management format that applies things at a global
level. So for example I can create a V switch a distributed V switch I can push
it to many hosts. So it manages all of my networking from a single software
package software package and it allows me to be a lot more clean in my design
and how I understand everything is happening. But keep in mind that the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and how I understand everything is happening. But keep in mind that the
function of the V switch regardless of whether it's standard or distributed the
function is the same. It's going to perform switching downstream via just
normal switching mechanisms. It's going to do upstream switching via pinning.
All
of that is the same between the two. It's just that the distributed V switch
does scale a whole lot better because it allows me to push the same
configurations out to my many virtual hosts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configurations out to my many virtual hosts.