WEBVTT

1
00:00.000 --> 00:05.280
Well virtual technology is pretty cool except that we kind of created a mess

2
00:05.280 --> 00:11.560
around networking within the virtual space. For example, think about the fact

3
00:11.560 --> 00:16.480
that we've got this single host and now I have these two different virtual

4
00:16.480 --> 00:21.060
machines each one with their own MAC address, each one with their own IP

5
00:21.060 --> 00:27.640
address. Remember these are full operating system instances so if my home PC or

6
00:27.640 --> 00:32.640
physical device has network identities well so does each individual virtual
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

6
00:27.640 --> 00:32.640
physical device has network identities well so does each individual virtual

7
00:32.640 --> 00:37.920
machine. And now this physical host has a physical network connection going up

8
00:37.920 --> 00:44.280
to a switch. So how do these virtual machines communicate with one another? If

9
00:44.280 --> 00:44.400
I

10
00:44.400 --> 00:49.840
send a packet up to the switch and it's destined for this other virtual machine

11
00:49.840 --> 00:53.600
we might think okay well the switch just turns around and sends it back down

12
00:53.600 --> 00:53.880
and

13
00:53.880 --> 00:58.840
maybe that's inefficient but at least that would work right? Except it's not

14
00:58.840 --> 01:04.880
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

14
00:58.840 --> 01:04.880
going to work. This is trombone it's bringing it into the same interface and

15
01:04.880 --> 01:10.960
trying to send it back out the same interface and this is not allowed. The

16
01:10.960 --> 01:15.240
switch will never bring a packet into one interface and send it right back out

17
01:15.240 --> 01:20.280
the same interface. So how can these two virtual machines communicate with one

18
01:20.280 --> 01:24.720
another? If we have 20 virtual machines on this host how can they communicate

19
01:24.720 --> 01:24.920
with

20
01:24.920 --> 01:30.800
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

20
01:24.920 --> 01:30.800
one another? Well this is going to lead us to a conversation around virtual

21
01:30.800 --> 01:39.120
networking because we are going to have to deploy networking inside now of our

22
01:39.120 --> 01:45.120
physical server our virtual host. This server here that we've built out virtual

23
01:45.120 --> 01:51.400
machines on. So let's draw this out a little bit bigger. We have our virtual

24
01:51.400 --> 01:58.320
host here and let's just draw a handful of virtual machines and once again each

25
01:58.320 --> 02:01.720
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

25
01:58.320 --> 02:01.720
one of these virtual machines will have its own MAC addresses and IP addresses

26
02:01.720 --> 02:05.840
and such. Now we're still going to have physical uplinks in fact we might find

27
02:05.840 --> 02:11.600
that we have multiple physical uplinks coming into the host maybe this is

28
02:11.600 --> 02:15.480
for additional bandwidth maybe it's for traffic segmentation. There's actually

29
02:15.480 --> 02:20.480
it's not uncommon to see eight to ten connections going to a single host. So

30
02:20.480 --> 02:23.920
keep that in mind. But let's just draw four connections here maybe these are

31
02:23.920 --> 02:30.720
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

31
02:23.920 --> 02:30.720
each 25 gigabits per second and they're all going to this one virtual host. So

32
02:30.720 --> 02:34.080
now this host and by the way at this point we're really talking about the

33
02:34.080 --> 02:38.520
hypervisor because the responsibility of the hypervisors to manage all this but

34
02:38.520 --> 02:42.240
the hypervisor has to manage networking here. So how do we go about doing it?

35
02:42.240 --> 02:47.560
Well at the heart of it we're going to need to deploy what we call a virtual

36
02:47.560 --> 02:54.720
switch which is usually abbreviated as a V switch. This virtual switch is fully

37
02:54.720 --> 02:59.320
capable of switching packets in the same way that a physical layer to switch

38
02:59.320 --> 03:04.240
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

38
02:59.320 --> 03:04.240
would be capable of. In fact it can support things like VLANs. It can support

39
03:04.240 --> 03:11.920
things like trunks and we can even enable span on this to bridge traffic for

40
03:11.920 --> 03:12.080
the

41
03:12.080 --> 03:17.040
sake of traffic monitoring. And so these V switches even though they're virtual

42
03:17.040 --> 03:22.240
they're going to through software terminate these physical connections that

43
03:22.240 --> 03:27.920
go out to the rest of the world. And then internally we're going to connect to

44
03:27.920 --> 03:33.240
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

44
03:27.920 --> 03:33.240
the virtual nicks that exist on these virtual machines. So now we see exactly

45
03:33.240 --> 03:36.640
how these virtual machines are able to communicate with one another. They

46
03:36.640 --> 03:37.080
simply

47
03:37.080 --> 03:41.360
get switched through this software instance of a switch. So this virtual

48
03:41.360 --> 03:45.560
switch that lives inside of the hypervisor and now can switch traffic

49
03:45.560 --> 03:50.320
between them. So mission accomplished right? Except once again we keep coming

50
03:50.320 --> 03:54.520
back to some problems. For example look at what I just did. I just created a

51
03:54.520 --> 04:00.680
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

51
03:54.520 --> 04:00.680
network loop. That's not great. And so do we really want to extend spanning

52
04:00.680 --> 04:05.320
tree operation down into this virtual layer where we have to block one of

53
04:05.320 --> 04:09.280
these ports because we do want redundancy. We don't want to lose one of

54
04:09.280 --> 04:13.000
these connections and isolate the virtual switch for example. What are we

55
04:13.000 --> 04:17.370
going to do about this? Well to directly answer that we are not going to want

56
04:17.370 --> 04:17.480
to

57
04:17.480 --> 04:21.560
run spanning tree. We don't want to do it. That would create a very large mess

58
04:21.560 --> 04:25.920
for us in the networking world to to manage and maintain a spanning tree

59
04:25.920 --> 04:30.000
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

59
04:25.920 --> 04:30.000
topology that now goes all the way down into the virtual host. And again we

60
04:30.000 --> 04:30.200
might

61
04:30.200 --> 04:35.160
have dozens of these virtual hosts. So instead we're going to use a different

62
04:35.160 --> 04:42.040
concept that is known as pinning. This is a critical concept inside of data

63
04:42.040 --> 04:45.640
center networking. It's used at the virtual layer. It's also used in Cisco

64
04:45.640 --> 04:50.920
UCS quite a bit. And so it becomes very important inside of data center

65
04:50.920 --> 04:59.200
networking in general. The idea here is that outbound traffic gets pinned to a

66
04:59.200 --> 05:06.640
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

66
04:59.200 --> 05:06.640
specific uplink. So what this means is if a virtual machine wants to send a

67
05:06.640 --> 05:10.720
packet out to the rest of the network, well now it's going to have to go out

68
05:10.720 --> 05:16.080
the network but it gets pinned using dotted lines here to represent this to a

69
05:16.080 --> 05:19.760
specific uplink. So let's say these two virtual machines get pinned to

70
05:19.760 --> 05:20.120
different

71
05:20.120 --> 05:24.320
uplinks. So now the virtual machine on the left will send all of its traffic

72
05:24.320 --> 05:28.560
upstream on the port on the left. The virtual machine on the right is going to

73
05:28.560 --> 05:34.190
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

73
05:28.560 --> 05:34.190
use the port on the right. And it will always use that pinned uplink.

74
05:34.190 --> 05:34.640
Furthermore

75
05:34.640 --> 05:39.200
we're never going to bridge and loop traffic from one let's say we send a

76
05:39.200 --> 05:43.920
broadcast packet down one link. We're never going to loop it back around. This

77
05:43.920 --> 05:50.130
breaks the rules between pinned uplinks. Instead if I get a flooded packet, let

78
05:50.130 --> 05:50.200
's

79
05:50.200 --> 05:56.080
just change the colors here to make it clear. If I get a broadcast packet and

80
05:56.080 --> 05:58.960
it comes onto this switch it needs to get sent out. Well the switch is going to

81
05:58.960 --> 06:02.400
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

81
05:58.960 --> 06:02.400
view both of these links as any link. I'm going to have to send this broadcast

82
06:02.400 --> 06:06.240
packet out both of these connections. But that's a good thing because the

83
06:06.240 --> 06:10.320
broadcast that comes on the left will hit the virtual machine on the left. The

84
06:10.320 --> 06:14.840
broadcast that's on the right will hit the virtual machine on the right. And

85
06:14.840 --> 06:15.000
once

86
06:15.000 --> 06:19.840
again I'm not going to bridge the gap here. And as a result we do successfully

87
06:19.840 --> 06:24.640
deliver our broadcast packets to the virtual machines without looping traffic

88
06:24.640 --> 06:30.880
back around and duplicating packets. So this pinned nature also works from a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
06:24.640 --> 06:30.880
back around and duplicating packets. So this pinned nature also works from a

89
06:30.880 --> 06:38.160
broadcast perspective. So a broadcast inbound is going to get sent along the

90
06:38.160 --> 06:44.560
pinned link to the virtual machine as well. Now it is worth noting that we can

91
06:44.560 --> 06:50.330
actually support port channels here. But they're really not real needed. There

92
06:50.330 --> 06:50.400
's

93
06:50.400 --> 06:55.440
almost no benefit to doing so. So I could bundle these together for example and

94
06:55.440 --> 06:59.920
the switch would just see that as it may be an LACP port channel and we could

95
06:59.920 --> 07:04.010
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

95
06:59.920 --> 07:04.010
say that that's useful other than now we just have a single pinned up link. We

96
07:04.010 --> 07:04.120
're

97
07:04.120 --> 07:08.240
getting load balancing and redundancy through the port channel. But notice

98
07:08.240 --> 07:12.440
before we did this we already had redundancy. That's a great thing about

99
07:12.440 --> 07:17.320
pinning is we have redundancy and we have load balancing. And so there's not

100
07:17.320 --> 07:23.280
nearly as much value in deploying a port channel into this type of

101
07:23.280 --> 07:27.730
environment although some enterprises do choose to still deploy port channels.

102
07:27.730 --> 07:28.120
So

103
07:28.120 --> 07:33.080
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

103
07:28.120 --> 07:33.080
notice that I left a whole blank part of this hypervisor over on the right.

104
07:33.080 --> 07:37.120
Well that's because we might actually see that there's value in deploying a

105
07:37.120 --> 07:42.480
second V switch. So now the second V switch is going to communicate with all

106
07:42.480 --> 07:47.280
of the other connections that we see here. We use pinning in the same way. Then

107
07:47.280 --> 07:47.400
you

108
07:47.400 --> 07:50.360
say well why do we do this? Why wouldn't we just all connect all the virtual

109
07:50.360 --> 07:55.080
machines to the same V switch? Well this creates network segmentation. Now this

110
07:55.080 --> 07:58.720
means that if these two virtual machines want to communicate, I mean just look

111
07:58.720 --> 07:58.800
at

112
07:58.800 --> 08:02.920
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

112
07:58.800 --> 08:02.920
the network paths here. How do they communicate? Believe it or not it's going

113
08:02.920 --> 08:07.480
to have to send from one virtual machine up to the switch get sent back around

114
08:07.480 --> 08:07.920
on

115
08:07.920 --> 08:12.240
down. We said on the left here that we can't go in and out of the same

116
08:12.240 --> 08:16.200
interface but there's nothing saying we can't follow normal switching rules and

117
08:16.200 --> 08:20.560
use different interfaces. And so that's exactly what we do to communicate from

118
08:20.560 --> 08:25.200
one virtual machine on one V switch to a virtual machine on the other V switch.

119
08:25.200 --> 08:29.760
And so it's pretty common in virtual networking again to use a lot of

120
08:29.760 --> 08:33.160
different connections to create many different V switches on the hypervisor
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
08:29.760 --> 08:33.160
different connections to create many different V switches on the hypervisor

121
08:33.160 --> 08:37.880
and try to keep different network types isolated. For example storage

122
08:37.880 --> 08:42.220
networking probably shouldn't be on the same V switch as our DMZ type of

123
08:42.220 --> 08:42.720
traffic

124
08:42.720 --> 08:48.360
if we're extending that into our virtual environment. So we do have multiple

125
08:48.360 --> 08:53.920
different V switch types and it really just comes down to how we want to manage

126
08:53.920 --> 09:01.160
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

126
08:53.920 --> 09:01.160
this. So there is a standard V switch which we use in our smaller environments

127
09:01.160 --> 09:07.280
and it basically just indicates that we configure this on a per host basis.

128
09:07.280 --> 09:12.280
So I get onto my host I configure as many V switches as I want but then on the

129
09:12.280 --> 09:17.320
next host I have to also configure as many V switches as I want. So this can

130
09:17.320 --> 09:21.830
you know again scale out to maybe four or five six hosts and that's not that

131
09:21.830 --> 09:22.000
big

132
09:22.000 --> 09:26.920
of a deal. But what we might want to do in enterprise networks is use a

133
09:26.920 --> 09:32.880
distributed virtual switch. The distributed virtual switch sounds pretty
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
09:26.920 --> 09:32.880
distributed virtual switch. The distributed virtual switch sounds pretty

134
09:32.880 --> 09:40.440
fancy but it really is just a management format that applies things at a global

135
09:40.440 --> 09:46.080
level. So for example I can create a V switch a distributed V switch I can push

136
09:46.080 --> 09:52.920
it to many hosts. So it manages all of my networking from a single software

137
09:52.920 --> 09:58.040
package software package and it allows me to be a lot more clean in my design

138
09:58.040 --> 10:04.160
and how I understand everything is happening. But keep in mind that the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

138
09:58.040 --> 10:04.160
and how I understand everything is happening. But keep in mind that the

139
10:04.160 --> 10:09.160
function of the V switch regardless of whether it's standard or distributed the

140
10:09.160 --> 10:14.720
function is the same. It's going to perform switching downstream via just

141
10:14.720 --> 10:19.680
normal switching mechanisms. It's going to do upstream switching via pinning.

142
10:19.680 --> 10:19.680
All

143
10:19.680 --> 10:23.520
of that is the same between the two. It's just that the distributed V switch

144
10:23.520 --> 10:28.000
does scale a whole lot better because it allows me to push the same

145
10:28.000 --> 10:32.720
configurations out to my many virtual hosts.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
10:28.000 --> 10:32.720
configurations out to my many virtual hosts.