WEBVTT

1
00:00.000 --> 00:04.350
Well, we've brought up the data center a few different times, and that's

2
00:04.350 --> 00:04.640
because the

3
00:04.640 --> 00:08.360
data center is a critical part of our network.

4
00:08.360 --> 00:12.160
And yeah, I'll admit that I think data center technology is really cool.

5
00:12.160 --> 00:13.840
I really like it a lot.

6
00:13.840 --> 00:17.440
In fact, if you search for data center technology here at CBT Nuggets, you'll

7
00:17.440 --> 00:18.080
find that I teach

8
00:18.080 --> 00:19.760
a lot of the content.

9
00:19.760 --> 00:21.920
And we all have our passions in life.

10
00:21.920 --> 00:26.860
And I love the Nexus switches and UCS servers and storage networking that Cisco

11
00:26.860 --> 00:27.560
brings to

12
00:27.560 --> 00:28.560
the table.

13
00:28.560 --> 00:31.880
But there's a better reason to bring it up than just because I like it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.560 --> 00:31.880
But there's a better reason to bring it up than just because I like it.

14
00:31.880 --> 00:34.920
And it's the fact that when we're talking about network redundancy, the data

15
00:34.920 --> 00:35.560
center really

16
00:35.560 --> 00:40.080
is arguably the most critical component of the entire network.

17
00:40.080 --> 00:44.050
Yes, the core of the network matters as much as anything because if the core

18
00:44.050 --> 00:44.680
goes down,

19
00:44.680 --> 00:46.680
we lose access to the data center.

20
00:46.680 --> 00:50.320
But the reason why it's so critical is because of what we just said before.

21
00:50.320 --> 00:56.680
A lot of our users' jobs are tied to their ability to access applications.

22
00:56.680 --> 01:00.360
And if we lose access to the applications, they can't do their jobs.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:56.680 --> 01:00.360
And if we lose access to the applications, they can't do their jobs.

23
01:00.360 --> 01:01.760
They might as well go home.

24
01:01.760 --> 01:07.290
And even though people might like to have that excuse, very rarely does it ever

25
01:07.290 --> 01:07.920
result in

26
01:07.920 --> 01:09.920
anybody actually getting to go home instead.

27
01:09.920 --> 01:13.680
They have to very awkwardly deal with customers and deal with all of the

28
01:13.680 --> 01:14.920
headaches that result

29
01:14.920 --> 01:18.560
of them not having access to their critical applications.

30
01:18.560 --> 01:23.680
So we need to provide a lot of redundancy in the data center because what the

31
01:23.680 --> 01:24.560
applications

32
01:24.560 --> 01:31.440
reside on are servers that connect into our access layer switches, as well as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:24.560 --> 01:31.440
reside on are servers that connect into our access layer switches, as well as

33
01:31.440 --> 01:32.600
our storage

34
01:32.600 --> 01:39.160
arrays and other appliances that all exist there inside the data center.

35
01:39.160 --> 01:43.180
And as a result, even though this looks like an access layer because it lives

36
01:43.180 --> 01:43.840
at the edge

37
01:43.840 --> 01:48.400
of the network, it actually, and by the way, we do call it the access layer

38
01:48.400 --> 01:49.120
outside of

39
01:49.120 --> 01:54.550
the spine and leaf fabrics, but it provides a lot more resiliency, or at least

40
01:54.550 --> 01:55.200
it needs

41
01:55.200 --> 01:59.850
to provide a lot more resiliency than a campus access layer that shares the

42
01:59.850 --> 02:00.760
same name.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:59.850 --> 02:00.760
same name.

43
02:00.760 --> 02:05.130
So the first thing we're going to do when we design a data center network,

44
02:05.130 --> 02:05.880
especially

45
02:05.880 --> 02:11.830
with a two tier or three tier model, is we're going to deploy a pair of aggreg

46
02:11.830 --> 02:14.160
ation switches,

47
02:14.160 --> 02:18.080
which behave very similarly to our distribution switches.

48
02:18.080 --> 02:20.840
And then we are going to deploy access switches.

49
02:20.840 --> 02:25.190
The difference here is that when I deploy access switches like this, and I

50
02:25.190 --> 02:26.040
connect them

51
02:26.040 --> 02:30.740
up to my aggregation layer, I'm going to ensure that my critical devices like
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:26.040 --> 02:30.740
up to my aggregation layer, I'm going to ensure that my critical devices like

52
02:30.740 --> 02:31.520
my servers

53
02:31.520 --> 02:36.860
and my storage arrays and my appliances that they actually have redundant

54
02:36.860 --> 02:39.000
connections upstream

55
02:39.000 --> 02:41.760
to the access switches.

56
02:41.760 --> 02:47.330
Now this upstream access is going to be a consideration logically, but also

57
02:47.330 --> 02:48.520
physically,

58
02:48.520 --> 02:53.760
because these devices are all in a rack somewhere inside of the data center.

59
02:53.760 --> 02:57.410
And so if they're in the same physical rack, then how do they access both

60
02:57.410 --> 02:58.160
switches?

61
02:58.160 --> 03:00.280
Do they both go into the same rack?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:58.160 --> 03:00.280
Do they both go into the same rack?

62
03:00.280 --> 03:04.240
Do we put a second rack over here?

63
03:04.240 --> 03:08.480
And these switches have to connect down to all of those devices as well.

64
03:08.480 --> 03:12.080
And this switch goes into this rack, and this switch goes into the rack over

65
03:12.080 --> 03:12.600
here.

66
03:12.600 --> 03:17.830
We've got some conversations to have there, but we do need redundancy from the

67
03:17.830 --> 03:18.600
endpoints

68
03:18.600 --> 03:24.180
here and the access layer, which is something we don't see in the campus

69
03:24.180 --> 03:25.600
environment.

70
03:25.600 --> 03:30.290
But it goes beyond just having redundant access switches, because the data
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:25.600 --> 03:30.290
But it goes beyond just having redundant access switches, because the data

71
03:30.290 --> 03:32.200
center and specifically

72
03:32.200 --> 03:41.000
Cisco Nexus switches, they give us a technology known as virtual port channels.

73
03:41.000 --> 03:45.060
Now if we only live in the Cisco world, we probably again are going to use the

74
03:45.060 --> 03:45.600
term Ether

75
03:45.600 --> 03:49.380
channel, but the industry likes to use the word port channel because Ether

76
03:49.380 --> 03:50.080
channel is a

77
03:50.080 --> 03:51.480
Cisco word.

78
03:51.480 --> 03:55.270
So when I talk about a virtual port channel, it's essentially just saying it's

79
03:55.270 --> 03:55.880
a virtual

80
03:55.880 --> 04:00.200
Ether channel, but it does get abbreviated as a VPC.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:55.880 --> 04:00.200
Ether channel, but it does get abbreviated as a VPC.

81
04:00.200 --> 04:01.840
Here's the idea of the VPC.

82
04:01.840 --> 04:05.780
If I have two switches like this and they're connected together, and I have

83
04:05.780 --> 04:06.480
another switch

84
04:06.480 --> 04:12.170
down here, looking like an aggregation access or distribution access to apology

85
04:12.170 --> 04:13.080
, I can connect

86
04:13.080 --> 04:18.200
down like this and we know spanning tree would require us to block one of those

87
04:18.200 --> 04:19.400
connections.

88
04:19.400 --> 04:23.810
Now if this was only going to one of these devices, then I could port channel

89
04:23.810 --> 04:24.280
it and we

90
04:24.280 --> 04:27.940
lose the redundancy of, you know, if this switch goes down again, that's a

91
04:27.940 --> 04:28.680
single point

92
04:28.680 --> 04:32.090
of failure, so we lose some redundancy, but at least we're not blocking
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:28.680 --> 04:32.090
of failure, so we lose some redundancy, but at least we're not blocking

93
04:32.090 --> 04:33.040
spanning tree.

94
04:33.040 --> 04:37.960
Well, usually we still go back to the old topology, which is to allow spanning

95
04:37.960 --> 04:38.680
tree to block

96
04:38.680 --> 04:42.640
a link because we need that redundancy in place.

97
04:42.640 --> 04:45.600
Virtual port channeling aims to accomplish the benefits of both.

98
04:45.600 --> 04:52.680
I'm going to put special configuration on these two devices, call them VPC

99
04:52.680 --> 04:53.600
peers, and

100
04:53.600 --> 04:57.810
this allows them to work some back end control plane magic with each other to

101
04:57.810 --> 04:58.560
coordinate

102
04:58.560 --> 05:02.440
turning this into a bundled connection.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
04:58.560 --> 05:02.440
turning this into a bundled connection.

103
05:02.440 --> 05:05.600
And we refer to this as the VPC.

104
05:05.600 --> 05:09.820
As we see, it's a port channel that goes to two different devices which can

105
05:09.820 --> 05:10.480
kind of break

106
05:10.480 --> 05:15.600
our brains at first because I'm used to it being a one to one relationship.

107
05:15.600 --> 05:19.560
Well it is one to one from the downstream perspective because this device

108
05:19.560 --> 05:20.480
thinks that there's

109
05:20.480 --> 05:24.490
this single device upstream that it's connecting to and so it's going to send

110
05:24.490 --> 05:25.280
some traffic

111
05:25.280 --> 05:28.480
out this way and some traffic out that way.

112
05:28.480 --> 05:33.670
And this is again a wonderful way to achieve not only redundancy, but also
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
05:28.480 --> 05:33.670
And this is again a wonderful way to achieve not only redundancy, but also

113
05:33.670 --> 05:35.000
efficiency, especially

114
05:35.000 --> 05:38.560
since data centers often have, there might be 40 gig connections.

115
05:38.560 --> 05:44.240
I'd really hate to spanning tree block of 40 gig or 100 gig or 200 gig

116
05:44.240 --> 05:45.440
connection, and

117
05:45.440 --> 05:47.760
that's going to be very costly.

118
05:47.760 --> 05:52.020
Now this creates an interesting scenario with our first hop redundancy

119
05:52.020 --> 05:53.240
protocols because

120
05:53.240 --> 05:59.250
when we look at FHRP's in a VPC environment, here's what we might end up

121
05:59.250 --> 06:00.600
happening or what
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
05:59.250 --> 06:00.600
happening or what

122
06:00.600 --> 06:01.800
we might end up seeing.

123
06:01.800 --> 06:07.060
At the aggregation layer, I might have VLAN interfaces here, got a layer to

124
06:07.060 --> 06:08.040
connection,

125
06:08.040 --> 06:13.010
and so I'm going to deploy an FHRP because these servers and storage arrays,

126
06:13.010 --> 06:13.560
they need to

127
06:13.560 --> 06:18.230
get off their own subnet just like any other laptop or endpoint would need to

128
06:18.230 --> 06:18.680
do.

129
06:18.680 --> 06:24.060
So I wanted to play gateway redundancy, I deploy HSRP, I have an active over on

130
06:24.060 --> 06:24.920
the left,

131
06:24.920 --> 06:30.290
I have a standby over on the right, and then I'm going to turn these into VPC
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:24.920 --> 06:30.290
I have a standby over on the right, and then I'm going to turn these into VPC

132
06:30.290 --> 06:30.960
peers and

133
06:30.960 --> 06:34.960
connect down to this access switch.

134
06:34.960 --> 06:37.200
And I'll create a VPC.

135
06:37.200 --> 06:40.240
So so far so good, everything is perfectly fine.

136
06:40.240 --> 06:43.870
So think about the traffic flow here, I just said that some traffic will get

137
06:43.870 --> 06:44.600
load balanced

138
06:44.600 --> 06:47.880
out this link, some will get load balanced out this link.

139
06:47.880 --> 06:53.480
So if it gets sent out the first link, no problem, it arrives on the HSRP

140
06:53.480 --> 06:54.040
active and it

141
06:54.040 --> 06:58.400
gets processed and sent upstream because there's some upstream layer three

142
06:58.400 --> 06:59.360
network above

143
06:59.360 --> 07:02.320
the aggregation switch, usually the core layer.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
06:59.360 --> 07:02.320
the aggregation switch, usually the core layer.

144
07:02.320 --> 07:04.120
So that looks great.

145
07:04.120 --> 07:06.760
What if it gets sent out this other link?

146
07:06.760 --> 07:09.240
Now it's landing on the standby.

147
07:09.240 --> 07:13.720
And so it's going to have to get processed by the interface, well, it can't

148
07:13.720 --> 07:14.520
because it's

149
07:14.520 --> 07:15.520
the standby.

150
07:15.520 --> 07:19.180
So it's going to have to forward it over to the active to get processed and

151
07:19.180 --> 07:20.920
routed out.

152
07:20.920 --> 07:25.500
So our efficiency is going to look like this every other packet, let's say,

153
07:25.500 --> 07:26.160
whatever the

154
07:26.160 --> 07:29.520
load balancing is, that can be perfectly per packet.

155
07:29.520 --> 07:32.810
But some packets will get forwarded this way, some will get like this, some
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

155
07:29.520 --> 07:32.810
But some packets will get forwarded this way, some will get like this, some

156
07:32.810 --> 07:33.400
will get like

157
07:33.400 --> 07:34.600
that, some will go.

158
07:34.600 --> 07:39.120
So we see that the problem is that half of our traffic is getting looped around

159
07:39.120 --> 07:40.120
a very inefficient

160
07:40.120 --> 07:41.120
path.

161
07:41.120 --> 07:42.640
So what can you do here?

162
07:42.640 --> 07:46.400
Well, by the letter of the law, there's not much we can do about this.

163
07:46.400 --> 07:49.280
Fortunately, Cisco kind of breaks the law here.

164
07:49.280 --> 07:56.090
And Cisco has said that, you know what, in this case, the standby for both HSRP

165
07:56.090 --> 07:57.280
and VRRP.

166
07:57.280 --> 08:00.560
So yes, that would be a VRRP backup, not standby.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
07:57.280 --> 08:00.560
So yes, that would be a VRRP backup, not standby.

167
08:00.560 --> 08:09.220
But either way, the backup standby device is forward capable.

168
08:09.220 --> 08:10.220
So that's kind of cool.

169
08:10.220 --> 08:15.710
Basically what they're saying is, yeah, traffic might get sent to the HSRP

170
08:15.710 --> 08:16.600
active.

171
08:16.600 --> 08:18.360
It'll get processed and sent out.

172
08:18.360 --> 08:22.780
But now traffic that gets sent to the standby can also get processed and sent

173
08:22.780 --> 08:23.240
out.

174
08:23.240 --> 08:24.240
How about that?

175
08:24.240 --> 08:29.580
They can both respond when the destination Mac is the shared virtual Mac.

176
08:29.580 --> 08:32.180
So that's pretty cool from a data plane perspective.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
08:29.580 --> 08:32.180
So that's pretty cool from a data plane perspective.

177
08:32.180 --> 08:36.780
However, one caveat to that is that from a control plane perspective,

178
08:36.780 --> 08:38.940
especially with how

179
08:38.940 --> 08:44.980
our devices handle ARP responses, the ARP responses are still going to come

180
08:44.980 --> 08:48.100
from the active node.

181
08:48.100 --> 08:56.530
Meaning that if an ARP request gets sent here to the access switch, it might

182
08:56.530 --> 08:57.280
well get

183
08:57.280 --> 09:00.160
forwarded here to the standby.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
08:57.280 --> 09:00.160
forwarded here to the standby.

184
09:00.160 --> 09:02.240
I'll draw this in a different color here.

185
09:02.240 --> 09:06.520
So our ARP request might get sent to a different device or to the standby

186
09:06.520 --> 09:07.280
device.

187
09:07.280 --> 09:13.350
It is going to forward it over and allow the active to handle the ARP responses

188
09:13.350 --> 09:13.400
.

189
09:13.400 --> 09:16.120
So just one small caveat and all of that.

190
09:16.120 --> 09:19.560
But regardless, we do see how in the data center environment, if we're

191
09:19.560 --> 09:20.720
deploying our first

192
09:20.720 --> 09:26.680
top redundancy protocols to VPC peers, that fortunately we get this amazing

193
09:26.680 --> 09:27.360
active, active

194
09:27.360 --> 09:31.690
behavior that we will not get outside of the data center when we're deploying
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
09:27.360 --> 09:31.690
behavior that we will not get outside of the data center when we're deploying

195
09:31.690 --> 09:33.120
our FHRP's.

196
09:33.120 --> 09:38.110
And yes, that does apply both to Cisco's HSRP, but also when we deploy the VRRP

197
09:38.110 --> 09:38.520
onto

198
09:38.520 --> 09:39.920
the Cisco Nexus devices.