WEBVTT

1
00:00:00.160 --> 00:00:03.080
<v Speaker 1>Welcome to the deep dive. We're here to pull back

2
00:00:03.080 --> 00:00:05.960
<v Speaker 1>the curtain on the tech that powers our world, giving

3
00:00:06.000 --> 00:00:09.119
<v Speaker 1>you the real story. Today, we're plunging right into the

4
00:00:09.160 --> 00:00:11.599
<v Speaker 1>heart of it all data centers, I mean think about it.

5
00:00:11.640 --> 00:00:16.920
<v Speaker 1>Everything you do online, streaming, banking, work apps, it all

6
00:00:16.960 --> 00:00:20.679
<v Speaker 1>relies on this massive hidden infrastructure. And for that to

7
00:00:20.719 --> 00:00:23.440
<v Speaker 1>work without a hitch, the network underneath it needs to

8
00:00:23.480 --> 00:00:27.679
<v Speaker 1>be incredibly resilient, like rock solid, but also super agile.

9
00:00:28.120 --> 00:00:30.800
<v Speaker 1>So our mission today is to unpack how these data centers,

10
00:00:30.839 --> 00:00:34.039
<v Speaker 1>socially using Cisco tech, managed to keep data flowing NonStop

11
00:00:34.039 --> 00:00:35.200
<v Speaker 1>and adapt really fast.

12
00:00:35.399 --> 00:00:37.679
<v Speaker 2>And that's the real challenge is int it getting both

13
00:00:37.719 --> 00:00:40.960
<v Speaker 2>high availability like zero downtime, and that flexibility in these

14
00:00:40.960 --> 00:00:44.359
<v Speaker 2>I mean really complex networks. It's a tough balancing act.

15
00:00:44.399 --> 00:00:46.240
<v Speaker 2>So what we'll do is kind of trace how the

16
00:00:46.280 --> 00:00:49.439
<v Speaker 2>solutions evolved. We'll start with the basics, the early protocols

17
00:00:49.439 --> 00:00:52.200
<v Speaker 2>tackling those single points of failure, and then we'll journey

18
00:00:52.280 --> 00:00:55.679
<v Speaker 2>up to the more advanced stuff, the policy driven architectures.

19
00:00:55.960 --> 00:00:58.640
<v Speaker 2>It's actually a fascinating look at the engineering that makes

20
00:00:58.719 --> 00:01:00.000
<v Speaker 2>these always on networks possible.

21
00:01:00.439 --> 00:01:02.719
<v Speaker 1>Okay, so let's start at the beginning in layer three,

22
00:01:02.960 --> 00:01:05.480
<v Speaker 1>where traffic first tries to get off the local network

23
00:01:05.879 --> 00:01:08.840
<v Speaker 1>for anything important. Any business relying on just one single

24
00:01:08.920 --> 00:01:11.120
<v Speaker 1>router to get out, that's just not going to fly.

25
00:01:11.719 --> 00:01:14.760
<v Speaker 1>Before we had these specific protocols. If that one router failed,

26
00:01:15.239 --> 00:01:18.439
<v Speaker 1>disaster complete stop, not just a bit slow.

27
00:01:18.560 --> 00:01:21.079
<v Speaker 2>Oh yeah, serious disruption costly too.

28
00:01:21.079 --> 00:01:23.640
<v Speaker 1>Right, So engineers came up with these things called first

29
00:01:23.640 --> 00:01:27.120
<v Speaker 1>hop redundancy protocols fhrps. Basically, they make sure if one

30
00:01:27.200 --> 00:01:31.040
<v Speaker 1>rider bites the dust, your traffic just almost instantly finds

31
00:01:31.040 --> 00:01:31.840
<v Speaker 1>another way out.

32
00:01:31.879 --> 00:01:34.640
<v Speaker 2>Magic sort of okay. So one of the big ones,

33
00:01:34.719 --> 00:01:38.079
<v Speaker 2>especially here in a Cisco shop, is HSRP hot standby

34
00:01:38.159 --> 00:01:41.640
<v Speaker 2>Router Protocol. The idea behind HSRP is actually pretty smart

35
00:01:41.640 --> 00:01:45.200
<v Speaker 2>in its simplicity. You take two or more actual routers

36
00:01:45.200 --> 00:01:47.480
<v Speaker 2>and you make them look like one single virtual router

37
00:01:47.560 --> 00:01:50.000
<v Speaker 2>to the network. One router is active doing all the

38
00:01:50.040 --> 00:01:53.120
<v Speaker 2>work forwarding traffic. The other is stand by, just waiting,

39
00:01:53.239 --> 00:01:54.000
<v Speaker 2>ready to jump in.

40
00:01:54.159 --> 00:01:54.560
<v Speaker 1>Uh huh.

41
00:01:54.560 --> 00:01:57.319
<v Speaker 2>But the crucial bit. They share a virtual IP address

42
00:01:57.400 --> 00:02:00.519
<v Speaker 2>and a virtual MC address, so your server it just

43
00:02:00.560 --> 00:02:03.319
<v Speaker 2>sees one gateway. It has no idea if the underlying

44
00:02:03.359 --> 00:02:06.840
<v Speaker 2>active router changes completely transparent failover.

45
00:02:07.040 --> 00:02:10.680
<v Speaker 1>That's the goal exactly. Now, speed is obviously key here.

46
00:02:10.719 --> 00:02:14.159
<v Speaker 1>How fast does it switch over? HSRP uses these Hello

47
00:02:14.240 --> 00:02:18.159
<v Speaker 1>messages by default like every three seconds. Hey you still there, right,

48
00:02:18.319 --> 00:02:19.919
<v Speaker 1>And if one router doesn't hear from the other for

49
00:02:20.000 --> 00:02:23.879
<v Speaker 1>ten seconds, that's the default dead timer. Boom. The standby takes.

50
00:02:23.639 --> 00:02:25.960
<v Speaker 2>Over ten seconds, which you know, sounds like a long

51
00:02:26.000 --> 00:02:26.919
<v Speaker 2>time now maybe.

52
00:02:27.000 --> 00:02:30.280
<v Speaker 1>Today it does. But back then that was a huge improvement.

53
00:02:30.439 --> 00:02:32.960
<v Speaker 1>It meant core services could recover pretty quickly from a

54
00:02:32.960 --> 00:02:38.639
<v Speaker 1>hardware failure. Okay, Then there's VRP Virtual Router Redundancy Protocol

55
00:02:38.960 --> 00:02:41.560
<v Speaker 1>works on a really similar principle, aiming for that same

56
00:02:41.599 --> 00:02:45.240
<v Speaker 1>transparent failover. But the key difference is VRRP is an

57
00:02:45.240 --> 00:02:46.759
<v Speaker 1>open standard, not just.

58
00:02:46.719 --> 00:02:50.000
<v Speaker 2>Cisco right interoperability, which is important.

59
00:02:50.080 --> 00:02:53.000
<v Speaker 1>Yeah. So with VRP, you've got a master router handling

60
00:02:53.080 --> 00:02:56.159
<v Speaker 1>things and backup router is ready. The master usually gets

61
00:02:56.199 --> 00:02:59.400
<v Speaker 1>the highest priority two fifty five backups default to one hundred.

62
00:03:00.120 --> 00:03:03.319
<v Speaker 1>VRP has this feature called preemption, which means if a

63
00:03:03.319 --> 00:03:06.800
<v Speaker 1>backup router with a higher priority comes online or recovers,

64
00:03:07.240 --> 00:03:10.080
<v Speaker 1>it can actually take back control become the master again.

65
00:03:10.319 --> 00:03:14.159
<v Speaker 2>Yeah, ensuring the preferred path is used when available.

66
00:03:13.800 --> 00:03:15.800
<v Speaker 1>Right, And there's a neat little detail on how they

67
00:03:15.800 --> 00:03:18.960
<v Speaker 1>talk to each other. They use a specific multicast address

68
00:03:19.280 --> 00:03:21.520
<v Speaker 1>to two two yeer ol point zero point zero point one.

69
00:03:21.400 --> 00:03:25.199
<v Speaker 2>And using multicasts there. That's not just like a random choice.

70
00:03:25.240 --> 00:03:28.240
<v Speaker 2>It's efficient how so well, instead of the master sending

71
00:03:28.240 --> 00:03:31.800
<v Speaker 2>individual updates to every single backup router or flooding the

72
00:03:31.800 --> 00:03:35.360
<v Speaker 2>whole network, multicast lets all the backups listen in on

73
00:03:35.360 --> 00:03:39.240
<v Speaker 2>that one address, they get the updates simultaneously, uses wayless

74
00:03:39.280 --> 00:03:43.319
<v Speaker 2>network resources. It's just smarter, scalable, ah, okay, clever. So yeah,

75
00:03:43.439 --> 00:03:48.159
<v Speaker 2>HSRP VRRP. They might seem basic now, but honestly they

76
00:03:48.240 --> 00:03:51.280
<v Speaker 2>laid the groundwork for everything else. They solved that fundamental problem.

77
00:03:51.400 --> 00:03:53.680
<v Speaker 2>What happens if my main gateway fails? Without them, we

78
00:03:53.719 --> 00:03:56.120
<v Speaker 2>wouldn't be talking about the fancy stuff, because you know,

79
00:03:56.199 --> 00:03:58.400
<v Speaker 2>the network edge would still be super fragile. You'd still

80
00:03:58.400 --> 00:03:59.520
<v Speaker 2>have those nightmare outages.

81
00:03:59.639 --> 00:04:03.039
<v Speaker 1>Totally. It's hard to imagine networks without that basic protection. Now.

82
00:04:03.719 --> 00:04:06.599
<v Speaker 2>Okay, so that handles layer three making sure traffic can

83
00:04:06.639 --> 00:04:09.840
<v Speaker 2>get out, But what about layer two inside the switching network?

84
00:04:09.879 --> 00:04:15.080
<v Speaker 2>We also want redundancy there, right, multiple paths between switches. Absolutely,

85
00:04:15.080 --> 00:04:19.079
<v Speaker 2>you need redundant links for resilience there too, But and

86
00:04:19.120 --> 00:04:19.480
<v Speaker 2>this is a.

87
00:04:19.399 --> 00:04:23.319
<v Speaker 1>Big butt layer two. Redundancy if you're not careful, creates

88
00:04:23.360 --> 00:04:29.120
<v Speaker 1>loops network loops. Oh yeah, the ultimate network killer, right,

89
00:04:29.240 --> 00:04:32.480
<v Speaker 1>broadcast storms, Yeah, Maxi tables going crazy.

90
00:04:32.639 --> 00:04:33.319
<v Speaker 2>Yeah.

91
00:04:33.360 --> 00:04:36.920
<v Speaker 1>Basically total network meltdown brings everything grinding to a halt.

92
00:04:37.519 --> 00:04:39.480
<v Speaker 1>Horrible to troubleshoot.

93
00:04:38.920 --> 00:04:40.680
<v Speaker 2>Too, been there, It's not fun.

94
00:04:41.279 --> 00:04:45.160
<v Speaker 1>So the classic way to solve this spanning tree Protocol STP.

95
00:04:45.839 --> 00:04:49.040
<v Speaker 1>STP's job is basically simple. It finds redundant paths and

96
00:04:49.040 --> 00:04:52.399
<v Speaker 1>blocks them intelligently, hopefully. It figures out the best loop

97
00:04:52.399 --> 00:04:54.680
<v Speaker 1>free path and any other links that could cause a loop.

98
00:04:54.959 --> 00:04:56.879
<v Speaker 1>It puts those ports into a blocking state.

99
00:04:57.199 --> 00:04:58.000
<v Speaker 2>Problem solved.

100
00:04:58.120 --> 00:05:01.600
<v Speaker 1>No loops exactly, no loops. But there's that trade off again,

101
00:05:01.639 --> 00:05:04.920
<v Speaker 1>those block ports, they're just sitting there idle, perfectly good links,

102
00:05:04.920 --> 00:05:06.560
<v Speaker 1>expensive fiber maybe doing.

103
00:05:06.319 --> 00:05:09.839
<v Speaker 2>Nothing, Wasted bandwidth, which nobody likes, especially in a data center.

104
00:05:09.879 --> 00:05:11.959
<v Speaker 2>It's like having that four lane highway the two lanes

105
00:05:11.959 --> 00:05:13.439
<v Speaker 2>are always coned off precisely.

106
00:05:13.519 --> 00:05:15.319
<v Speaker 1>Now, SDP itself got better over time.

107
00:05:15.319 --> 00:05:18.560
<v Speaker 2>They added features, right, Oh yeah, things like btdu guard

108
00:05:18.800 --> 00:05:21.199
<v Speaker 2>that helps stop someone plugging in a rogue switch and

109
00:05:21.199 --> 00:05:23.920
<v Speaker 2>messing up your whole spanning tree. It shuts the port down.

110
00:05:23.920 --> 00:05:25.000
<v Speaker 1>Okay, good safety neck.

111
00:05:25.000 --> 00:05:28.959
<v Speaker 2>And BPDU filter which just stops bpdu's entirely on certain

112
00:05:29.000 --> 00:05:32.480
<v Speaker 2>ports maybe facing servers. And root guard that lets you

113
00:05:32.519 --> 00:05:35.439
<v Speaker 2>control where the root bridge, the sort of central point

114
00:05:35.439 --> 00:05:38.519
<v Speaker 2>of the spanning tree should be, prevents unexpected shifts and

115
00:05:38.560 --> 00:05:39.240
<v Speaker 2>traffic flow.

116
00:05:39.480 --> 00:05:42.720
<v Speaker 1>So these definitely make STP more stable and more secure,

117
00:05:43.079 --> 00:05:45.480
<v Speaker 1>but they don't fix that core problem. Do they the

118
00:05:45.680 --> 00:05:46.720
<v Speaker 1>wasted bandwidth?

119
00:05:47.040 --> 00:05:49.800
<v Speaker 2>No, they don't. They manage the downsides, but the fundamental

120
00:05:49.800 --> 00:05:53.560
<v Speaker 2>inefficiency of blocked ports remains, and that really sets up

121
00:05:53.600 --> 00:05:55.240
<v Speaker 2>the next big question, doesn't it. How do we get

122
00:05:55.279 --> 00:05:57.279
<v Speaker 2>past that? How do we use all our links that

123
00:05:57.360 --> 00:06:01.199
<v Speaker 2>layer to get that active goodness without bringing back those

124
00:06:01.360 --> 00:06:02.519
<v Speaker 2>terrible loops exactly?

125
00:06:02.560 --> 00:06:04.639
<v Speaker 1>And that's where things get really interesting, moving from just

126
00:06:05.040 --> 00:06:08.879
<v Speaker 1>preventing bad stuff to actually optimizing the good stuff. Enter

127
00:06:09.160 --> 00:06:13.560
<v Speaker 1>virtualport Channels dot vpcs. This was I mean a massive

128
00:06:13.600 --> 00:06:16.480
<v Speaker 1>deal for Cisco Nexus switches in the data center because

129
00:06:16.480 --> 00:06:19.639
<v Speaker 1>it directly tackled that STP problem. I'll let you use

130
00:06:19.680 --> 00:06:21.879
<v Speaker 1>all your layer two links, no more blocked ports.

131
00:06:21.959 --> 00:06:26.079
<v Speaker 2>Essentially a fundamental shift from block for safety to use

132
00:06:26.120 --> 00:06:27.040
<v Speaker 2>everything efficiently.

133
00:06:27.319 --> 00:06:31.560
<v Speaker 1>Totally. So the core idea of VPC, it's pretty cool

134
00:06:31.600 --> 00:06:35.680
<v Speaker 1>unless you take a port channel, you know, bundling multiple

135
00:06:35.680 --> 00:06:39.000
<v Speaker 1>physical links into one logical one and stretch it across

136
00:06:39.040 --> 00:06:40.879
<v Speaker 1>two different physical nexus switches.

137
00:06:41.000 --> 00:06:43.720
<v Speaker 2>Right, so one logical link spanning two boxes.

138
00:06:43.839 --> 00:06:47.480
<v Speaker 1>Yeah, so picture your server with two network cards for redundancy,

139
00:06:47.959 --> 00:06:50.600
<v Speaker 1>instead of plugging into two switches and having STP block

140
00:06:50.639 --> 00:06:53.439
<v Speaker 1>one link. Yeah, you plug into two different switches, but

141
00:06:53.519 --> 00:06:56.279
<v Speaker 1>because they're part of a VPC domain, the server just

142
00:06:56.360 --> 00:06:58.319
<v Speaker 1>sees one big bundled link.

143
00:06:58.920 --> 00:07:02.040
<v Speaker 2>Both paths are acting and that's the magic. No SDP

144
00:07:02.160 --> 00:07:05.680
<v Speaker 2>blocking on that link. The downstream device, server, storage, whatever,

145
00:07:05.720 --> 00:07:08.800
<v Speaker 2>gets to use all its bandwidth. Plus if one link fails,

146
00:07:08.879 --> 00:07:11.360
<v Speaker 2>or even if one entire switch fails, the traffic just

147
00:07:11.439 --> 00:07:14.800
<v Speaker 2>keeps flowing over the remaining path. Convergence is super fast.

148
00:07:14.879 --> 00:07:16.839
<v Speaker 1>Okay, so how does this work behind the scenes? What

149
00:07:16.879 --> 00:07:19.319
<v Speaker 1>makes it tick? Well, you have the VPC domain. That's

150
00:07:19.360 --> 00:07:21.639
<v Speaker 1>the logical thing formed by the two switches.

151
00:07:21.240 --> 00:07:22.439
<v Speaker 2>Working to get you peer switches.

152
00:07:22.519 --> 00:07:26.439
<v Speaker 1>Yeah, then absolutely critical is the peer link. This is

153
00:07:26.439 --> 00:07:30.040
<v Speaker 1>a connection usually pretty high bandwidth, directly between those two

154
00:07:30.160 --> 00:07:33.399
<v Speaker 1>VPC switches and it's not just for data. It's like

155
00:07:33.439 --> 00:07:35.879
<v Speaker 1>their lifeline. They use it to sync up important stuff,

156
00:07:36.079 --> 00:07:38.600
<v Speaker 1>MC addresses, they've learned, multicast.

157
00:07:38.079 --> 00:07:41.720
<v Speaker 2>Info, even Layer three gateway info like HSRP states keeps

158
00:07:41.720 --> 00:07:43.199
<v Speaker 2>them both on the same page for forwarding.

159
00:07:43.360 --> 00:07:46.560
<v Speaker 1>Right. Then there's the keep alive link, usually a separate

160
00:07:46.759 --> 00:07:49.040
<v Speaker 1>maybe even out of band connection. It's like a heartbeat

161
00:07:49.120 --> 00:07:50.399
<v Speaker 1>check uh huh.

162
00:07:50.279 --> 00:07:52.480
<v Speaker 2>Just to make sure the other peer switch is actually

163
00:07:52.560 --> 00:07:55.680
<v Speaker 2>alive even if the main peer link goes down. Important

164
00:07:55.720 --> 00:07:56.720
<v Speaker 2>sanity check.

165
00:07:56.759 --> 00:08:00.199
<v Speaker 1>Yeah, prevents split brain scenarios. And finally, you have the

166
00:08:00.319 --> 00:08:03.000
<v Speaker 1>VPC member ports. Those are the actual ports on each

167
00:08:03.000 --> 00:08:06.079
<v Speaker 1>switch that you bundle into the VPC connecting down to

168
00:08:06.120 --> 00:08:07.480
<v Speaker 1>your servers or other devices.

169
00:08:07.560 --> 00:08:10.800
<v Speaker 2>Got it, domain peerlink, keep alive member.

170
00:08:10.480 --> 00:08:14.120
<v Speaker 1>Ports now operationally this is pretty neat too. Even though

171
00:08:14.160 --> 00:08:17.000
<v Speaker 1>they act like one logical switch for layer two traffic, yeah,

172
00:08:17.199 --> 00:08:19.160
<v Speaker 1>you still manage them as two separate switches.

173
00:08:19.240 --> 00:08:20.600
<v Speaker 2>Right, independent control planes.

174
00:08:20.639 --> 00:08:23.839
<v Speaker 1>That's key, and for spanning tree it gets simpler for

175
00:08:23.879 --> 00:08:28.319
<v Speaker 1>the downstream device. By default, only the primary VPC switch

176
00:08:28.639 --> 00:08:32.279
<v Speaker 1>sends outvpdus on those VPC member ports.

177
00:08:32.120 --> 00:08:34.759
<v Speaker 2>So the attached server just sees one logical switch talking

178
00:08:34.840 --> 00:08:36.720
<v Speaker 2>SDP much cleaner.

179
00:08:36.879 --> 00:08:39.159
<v Speaker 1>But for this whole thing to work smoothly, they have

180
00:08:39.200 --> 00:08:40.320
<v Speaker 1>to be configured.

181
00:08:39.919 --> 00:08:43.720
<v Speaker 2>Consistently, right, Oh, absolutely, Consistency checks are built in things

182
00:08:43.799 --> 00:08:46.840
<v Speaker 2>like MTU size, certain spanning tree settings. How the port

183
00:08:46.919 --> 00:08:50.720
<v Speaker 2>channels are configured. They have to match on both peer switches.

184
00:08:50.840 --> 00:08:52.960
<v Speaker 1>What happens if they don't match depends.

185
00:08:53.120 --> 00:08:56.440
<v Speaker 2>There are different types. Type one inconsistencies are critical things

186
00:08:56.480 --> 00:08:59.879
<v Speaker 2>that could break forwarding. If those mismatch, the VPC link

187
00:08:59.879 --> 00:09:02.080
<v Speaker 2>it self will often be suspended, alarms go.

188
00:09:02.080 --> 00:09:03.840
<v Speaker 1>Off, okay, forces you to fix it. Yeah.

189
00:09:03.960 --> 00:09:07.440
<v Speaker 2>Type two inconsistencies are usually less severe, maybe QS settings

190
00:09:07.440 --> 00:09:09.639
<v Speaker 2>in some cases they might just log a warning but

191
00:09:09.759 --> 00:09:12.639
<v Speaker 2>let the VPC stay up. It's quite sophisticated. And what's

192
00:09:12.639 --> 00:09:16.559
<v Speaker 2>really amazing technically is how vpcs pull off that active,

193
00:09:16.600 --> 00:09:19.559
<v Speaker 2>active layer two forwarding while still having those two separate

194
00:09:19.600 --> 00:09:23.279
<v Speaker 2>control planes. It's not creating a single massive point of failure.

195
00:09:23.960 --> 00:09:26.159
<v Speaker 2>So what does this mean for you, the person managing

196
00:09:26.159 --> 00:09:29.519
<v Speaker 2>the network? Well, better use of your expensive links. Obviously,

197
00:09:30.120 --> 00:09:32.120
<v Speaker 2>simpler can fig for the servers plugged in. They just

198
00:09:32.159 --> 00:09:35.759
<v Speaker 2>see one big pipe and way way better resilience than

199
00:09:35.799 --> 00:09:38.960
<v Speaker 2>old school STP with all its blocked ports. I remember

200
00:09:39.039 --> 00:09:42.840
<v Speaker 2>spending ages explaining why half a server's NICs were dark.

201
00:09:43.279 --> 00:09:44.399
<v Speaker 2>Vpcs just fix that.

202
00:09:44.600 --> 00:09:47.080
<v Speaker 1>Yeah, sounds like a huge quality of life improvement. Besides

203
00:09:47.120 --> 00:09:50.919
<v Speaker 1>the performance. Okay, VPC solved a major Layer two bottleneck.

204
00:09:51.279 --> 00:09:54.279
<v Speaker 1>Huge step. But let's zoom out even further. What if

205
00:09:54.320 --> 00:09:57.120
<v Speaker 1>the network could just adapt automatically based on what the

206
00:09:57.120 --> 00:09:59.960
<v Speaker 1>applications need. What if instead of typing commands on boxes,

207
00:10:00.080 --> 00:10:02.480
<v Speaker 1>you just described the policy, the intent, and the network

208
00:10:02.480 --> 00:10:03.039
<v Speaker 1>figured it out.

209
00:10:03.120 --> 00:10:05.919
<v Speaker 2>Ah. Now you're talking about a real paradigm shift exactly.

210
00:10:06.240 --> 00:10:09.679
<v Speaker 1>That's the idea behind Cisco Application Centric Infrastructure or ACI,

211
00:10:10.600 --> 00:10:14.559
<v Speaker 1>moving away from device canfig towards defining application needs. The

212
00:10:14.559 --> 00:10:18.440
<v Speaker 1>whole philosophy of ACI is building this distributed, scalable network

213
00:10:18.480 --> 00:10:21.559
<v Speaker 1>works great for multiple tenants too, where everything is driven

214
00:10:21.559 --> 00:10:22.639
<v Speaker 1>by application.

215
00:10:22.240 --> 00:10:25.879
<v Speaker 2>Policies, designing the network around the app, not forcing the

216
00:10:25.879 --> 00:10:26.720
<v Speaker 2>app onto the.

217
00:10:26.679 --> 00:10:30.360
<v Speaker 1>Network precisely and under the hood. A key technology is

218
00:10:30.480 --> 00:10:34.759
<v Speaker 1>vx LAN. Basically, all traffic inside the ACI fabric gets

219
00:10:34.799 --> 00:10:37.440
<v Speaker 1>wrapped up in a vx LAN header. Doesn't matter if

220
00:10:37.480 --> 00:10:39.679
<v Speaker 1>it came in as a standard vland packet or even

221
00:10:39.720 --> 00:10:44.159
<v Speaker 1>another vx line packet. ACI normalizes it all internally.

222
00:10:43.720 --> 00:10:47.159
<v Speaker 2>Using vx LAN like a universal translator for the fabric.

223
00:10:46.879 --> 00:10:49.559
<v Speaker 1>Kind of yeah. And here's the really cool part. For agility,

224
00:10:49.759 --> 00:10:53.600
<v Speaker 1>vxland lets, ACI stretch layer two networks virtually anywhere across

225
00:10:53.639 --> 00:10:56.559
<v Speaker 1>the underlying layer three infrastructure. And crucially, it does this

226
00:10:56.600 --> 00:10:59.240
<v Speaker 1>without needing spanning tree protocol to stop loops within the

227
00:10:59.240 --> 00:11:02.159
<v Speaker 1>fabric itself. The architecture inherently prevents them.

228
00:11:02.240 --> 00:11:07.200
<v Speaker 2>That's massive, decoupling the logical network from the physical location freedom.

229
00:11:07.039 --> 00:11:11.480
<v Speaker 1>Total freedom. A server can move physically, but its network

230
00:11:11.519 --> 00:11:15.799
<v Speaker 1>identity and policies just follow it. No recabling, no complex

231
00:11:15.879 --> 00:11:20.120
<v Speaker 1>vland changes. So instead of configuring ports and vlands in ACI,

232
00:11:20.240 --> 00:11:23.679
<v Speaker 1>you think in terms of endpoint groups EPGs.

233
00:11:23.279 --> 00:11:24.840
<v Speaker 2>Right, logical containers.

234
00:11:24.960 --> 00:11:27.399
<v Speaker 1>Yeah, you group things logically like here are all my

235
00:11:27.440 --> 00:11:30.440
<v Speaker 1>web servers, that's the WEBPG. Here are my databases that's

236
00:11:30.480 --> 00:11:32.759
<v Speaker 1>the DBEPG. They share common needs.

237
00:11:32.919 --> 00:11:33.399
<v Speaker 2>Makes sense.

238
00:11:33.440 --> 00:11:35.720
<v Speaker 1>And then this is the policy part. How these groups

239
00:11:35.720 --> 00:11:39.159
<v Speaker 1>talk to each other is defined by contracts.

240
00:11:38.600 --> 00:11:42.519
<v Speaker 2>Not IP addresses and acls, but contracts policy rule.

241
00:11:42.639 --> 00:11:46.120
<v Speaker 1>Exactly, you define a contract saying okay, the WEBPG is

242
00:11:46.159 --> 00:11:48.960
<v Speaker 1>allowed to talk to the DBEPG, but only on the

243
00:11:48.960 --> 00:11:52.000
<v Speaker 1>specific sequel port for example, nothing else.

244
00:11:51.919 --> 00:11:54.360
<v Speaker 2>And that policy that contract gets tied to the EPG

245
00:11:54.480 --> 00:11:57.360
<v Speaker 2>is the identity of those application parts, not where they

246
00:11:57.399 --> 00:11:59.200
<v Speaker 2>physically live on the network.

247
00:11:58.840 --> 00:12:01.879
<v Speaker 1>Which is incredibly powerful for security and automation totally.

248
00:12:01.919 --> 00:12:05.120
<v Speaker 2>It means consistent security, consistent connectivity, no matter how dynamic

249
00:12:05.159 --> 00:12:08.759
<v Speaker 2>or environment gets and the underlying fabric usually a spine

250
00:12:08.799 --> 00:12:09.360
<v Speaker 2>leaf design.

251
00:12:09.480 --> 00:12:11.559
<v Speaker 1>Ah yeah, the physical topology.

252
00:12:11.279 --> 00:12:14.399
<v Speaker 2>Right, Every loof switch connects to every spine. It creates

253
00:12:14.399 --> 00:12:17.879
<v Speaker 2>this high bandwidth, low latency mesh. All links are active,

254
00:12:17.960 --> 00:12:21.320
<v Speaker 2>all paths are used. VX land handles the overlay, the

255
00:12:21.360 --> 00:12:25.159
<v Speaker 2>policy handles the control, no STP needed inside.

256
00:12:25.559 --> 00:12:29.120
<v Speaker 1>So for you the network engineer, it means less time

257
00:12:29.240 --> 00:12:31.879
<v Speaker 1>down in the weeds configuring individual.

258
00:12:31.360 --> 00:12:34.799
<v Speaker 2>Boxes, definitely more time thinking about the bigger picture. What

259
00:12:34.879 --> 00:12:37.440
<v Speaker 2>does this application actually need to do? How should it

260
00:12:37.440 --> 00:12:40.120
<v Speaker 2>be secured? Designing the intent That.

261
00:12:40.039 --> 00:12:42.519
<v Speaker 1>Really is a different way of thinking. So for our listener,

262
00:12:42.600 --> 00:12:45.039
<v Speaker 1>the payoff is what faster app rollouts?

263
00:12:45.159 --> 00:12:49.399
<v Speaker 2>Faster apps? Yeah, the network can adapt dynamically if workloads change.

264
00:12:49.559 --> 00:12:52.759
<v Speaker 2>Management gets simpler because it's policy driven, not box by box.

265
00:12:52.879 --> 00:12:55.759
<v Speaker 1>It lets the network actually help the business move faster

266
00:12:56.080 --> 00:12:58.279
<v Speaker 1>instead of sometimes being the thing slowing it down.

267
00:12:58.639 --> 00:13:02.080
<v Speaker 2>Exactly, It becomes an enabler, not a bottleneck. And if

268
00:13:02.120 --> 00:13:05.679
<v Speaker 2>you connect all this to the bigger picture ACI, it's

269
00:13:05.759 --> 00:13:08.600
<v Speaker 2>more than just another product. It really represents this big

270
00:13:08.720 --> 00:13:13.600
<v Speaker 2>leap towards you know, network intelligence automation. It's about making

271
00:13:13.600 --> 00:13:16.960
<v Speaker 2>the network serve the application truly instead of us always

272
00:13:16.960 --> 00:13:19.919
<v Speaker 2>trying to fit apps into these rigid network boxes we built.

273
00:13:20.159 --> 00:13:23.240
<v Speaker 2>It fundamentally changes the conversation from how do I configure

274
00:13:23.279 --> 00:13:26.360
<v Speaker 2>this VLAN to what does this application need to do?

275
00:13:26.559 --> 00:13:28.960
<v Speaker 2>And how do I express that as policy? That level

276
00:13:28.960 --> 00:13:31.759
<v Speaker 2>of abstraction game changing for speed and scale.

277
00:13:31.840 --> 00:13:35.679
<v Speaker 1>Wow, what a journey we've covered today. Seriously, we started

278
00:13:35.679 --> 00:13:39.200
<v Speaker 1>way back with the basics HSRP and VRP at layer three,

279
00:13:39.679 --> 00:13:42.879
<v Speaker 1>solving those fundamental single point of failure issues, keeping the.

280
00:13:42.799 --> 00:13:45.200
<v Speaker 2>Gateway up, foundational stuff still critical.

281
00:13:45.399 --> 00:13:48.039
<v Speaker 1>Then we hit layer two, saw how STP stopped loops,

282
00:13:48.080 --> 00:13:49.639
<v Speaker 1>but UH blocked.

283
00:13:49.320 --> 00:13:52.279
<v Speaker 2>All that bandwidth and necessary evil back then, right then.

284
00:13:52.159 --> 00:13:54.679
<v Speaker 1>The evolution with VPC is finally unlocking all that Layer

285
00:13:54.720 --> 00:13:57.039
<v Speaker 1>two bandwidth, getting true active active paths.

286
00:13:57.600 --> 00:14:00.679
<v Speaker 2>Big step forward, huge made data centers much more efficient.

287
00:14:00.879 --> 00:14:03.879
<v Speaker 1>And then we looked ahead into this policy driven world

288
00:14:03.919 --> 00:14:08.440
<v Speaker 1>with ACI and vx land where the network becomes intelligent. Automated,

289
00:14:08.919 --> 00:14:10.960
<v Speaker 1>really built around the application's needs.

290
00:14:11.200 --> 00:14:15.120
<v Speaker 2>Yeah, moving towards that intent based networking future. So what

291
00:14:15.159 --> 00:14:18.080
<v Speaker 2>does all this actually mean for you listening in, whether

292
00:14:18.159 --> 00:14:20.919
<v Speaker 2>you're building these things, managing them, or just using the

293
00:14:20.960 --> 00:14:24.360
<v Speaker 2>apps they run. Well. As these data centers get smarter,

294
00:14:24.639 --> 00:14:29.200
<v Speaker 2>more automated, more self aware, the job changes, right, the

295
00:14:29.200 --> 00:14:32.480
<v Speaker 2>focus shifts. It's becoming less about manual typing on keyboards

296
00:14:32.679 --> 00:14:36.879
<v Speaker 2>and more about understanding application intent designing smart policies, which

297
00:14:36.919 --> 00:14:39.360
<v Speaker 2>leaves us with a pretty interesting question to think about.

298
00:14:39.679 --> 00:14:42.960
<v Speaker 2>In this world of smarter, more programmable networks. How does

299
00:14:42.960 --> 00:14:45.440
<v Speaker 2>the role of us network folks keep evolving and what

300
00:14:45.480 --> 00:14:49.279
<v Speaker 2>incredible new things will this network intelligence make possible next?

301
00:14:49.759 --> 00:14:51.879
<v Speaker 1>Definitely something to chew on. Thanks for joining us on

302
00:14:51.919 --> 00:14:52.519
<v Speaker 1>this deep dive.