WEBVTT

1
00:00:00.080 --> 00:00:03.200
<v Speaker 1>Welcome back to the deep dive. We are really getting

2
00:00:03.240 --> 00:00:06.400
<v Speaker 1>into the weeds today. Oh yeah, yeah, we're tackling vxland

3
00:00:06.440 --> 00:00:10.000
<v Speaker 1>BGP EVPN fabrics. I mean, this is the stuff running

4
00:00:10.039 --> 00:00:12.439
<v Speaker 1>modern data centers, the real backbone.

5
00:00:12.480 --> 00:00:15.720
<v Speaker 2>It definitely is. And you know, it's a huge shift

6
00:00:15.759 --> 00:00:17.839
<v Speaker 2>from how things used to be done totally.

7
00:00:17.839 --> 00:00:20.519
<v Speaker 1>We're talking about moving away from those older kind of

8
00:00:20.559 --> 00:00:22.359
<v Speaker 1>clunky three tier designs.

9
00:00:22.000 --> 00:00:24.800
<v Speaker 2>Right exactly. This is the fast track guide basically to

10
00:00:24.920 --> 00:00:28.960
<v Speaker 2>understanding that jump to well high speed, really scalable software

11
00:00:29.000 --> 00:00:29.879
<v Speaker 2>defined networks.

12
00:00:30.160 --> 00:00:33.119
<v Speaker 1>So what problem does VXLANT actually solve? Why do we

13
00:00:33.159 --> 00:00:33.920
<v Speaker 1>need this shift?

14
00:00:34.159 --> 00:00:37.560
<v Speaker 2>Well, the old way just hit a wall. Traditional campus designs,

15
00:00:37.679 --> 00:00:42.280
<v Speaker 2>heavy on layer two spanning tree, they just couldn't scale,

16
00:00:42.280 --> 00:00:45.920
<v Speaker 2>not for the kind of density and speed modern applications demand.

17
00:00:46.000 --> 00:00:49.520
<v Speaker 1>Yeah, you think about virtualization, multi gig traffic everywhere. The

18
00:00:49.560 --> 00:00:51.240
<v Speaker 1>old models just choked, didn't.

19
00:00:50.960 --> 00:00:54.240
<v Speaker 2>They They really did. You need a predictable performance, active

20
00:00:54.280 --> 00:00:57.000
<v Speaker 2>paths everywhere, not just stand by links, and that's what

21
00:00:57.039 --> 00:00:58.039
<v Speaker 2>this fabric is built for.

22
00:00:58.159 --> 00:01:00.560
<v Speaker 1>Okay, So let's unpack this, starting right the bottom, the

23
00:01:00.560 --> 00:01:03.280
<v Speaker 1>physical setup, the spine and leaf architecture.

24
00:01:03.600 --> 00:01:08.640
<v Speaker 2>Right. The keyword here is symmetry. Every leaf switch connects

25
00:01:08.680 --> 00:01:10.519
<v Speaker 2>to every spine switch.

26
00:01:10.280 --> 00:01:12.560
<v Speaker 1>Bull mesh between layers basically exactly.

27
00:01:12.760 --> 00:01:16.079
<v Speaker 2>And what that do you is a super predictable traffic pattern.

28
00:01:16.840 --> 00:01:19.519
<v Speaker 2>Any device connected to a leaf is always just two

29
00:01:19.560 --> 00:01:22.040
<v Speaker 2>hawks away from any other device source leaf.

30
00:01:21.879 --> 00:01:24.879
<v Speaker 1>To a spine to the destination leave always always.

31
00:01:25.120 --> 00:01:27.560
<v Speaker 2>That predictability is golden for performance.

32
00:01:27.680 --> 00:01:30.519
<v Speaker 1>Makes sense, Yeah, So let's define those roles a bit

33
00:01:30.519 --> 00:01:35.359
<v Speaker 1>more clearly. The spine layer it connects the leaves, aggregates traffic.

34
00:01:35.879 --> 00:01:38.200
<v Speaker 2>It connects the leaves, yes, but it's doing much more

35
00:01:38.239 --> 00:01:41.920
<v Speaker 2>than just layer two aggregation. Now, in these layer three fabrics,

36
00:01:41.959 --> 00:01:45.000
<v Speaker 2>the spines are pure routers. They are the high speed

37
00:01:45.079 --> 00:01:50.079
<v Speaker 2>core and crucially they act as the BGP EVPN route reflectors.

38
00:01:49.560 --> 00:01:51.120
<v Speaker 1>AH, reflecting the roots down to the.

39
00:01:51.159 --> 00:01:54.319
<v Speaker 2>Leaves precisely, and they often handle multicasts two acting as

40
00:01:54.319 --> 00:01:57.680
<v Speaker 2>rendezvous points or oreps for the underlay network and.

41
00:01:57.599 --> 00:02:00.239
<v Speaker 1>The leaf layer. This is where things really change. The

42
00:02:00.280 --> 00:02:02.120
<v Speaker 1>traditional core functions move down here.

43
00:02:02.359 --> 00:02:06.519
<v Speaker 2>That's the fundamental shift. The leaves are where your servers,

44
00:02:06.560 --> 00:02:09.520
<v Speaker 2>your device is connect but they're also making the main

45
00:02:09.639 --> 00:02:12.919
<v Speaker 2>routing decisions. Now. They are the layer three cores distributed

46
00:02:12.960 --> 00:02:14.039
<v Speaker 2>across the whole fabric.

47
00:02:14.120 --> 00:02:16.199
<v Speaker 1>So Instead of one big core, you have lots of

48
00:02:16.400 --> 00:02:17.840
<v Speaker 1>smaller active.

49
00:02:17.520 --> 00:02:19.840
<v Speaker 2>Course exactly, all working together.

50
00:02:19.919 --> 00:02:23.000
<v Speaker 1>Okay, quick question. Then, if the spines are central for

51
00:02:23.080 --> 00:02:28.039
<v Speaker 1>commutation like those route reflectors, what happens if one fails?

52
00:02:28.560 --> 00:02:29.800
<v Speaker 1>Doesn't that break things?

53
00:02:30.159 --> 00:02:32.400
<v Speaker 2>That's where the design shines. You always have at least

54
00:02:32.400 --> 00:02:35.360
<v Speaker 2>two spines, since every leaf connects to all of them.

55
00:02:35.800 --> 00:02:39.639
<v Speaker 2>If one spine goes down, traffic just instantly moves over

56
00:02:39.719 --> 00:02:42.360
<v Speaker 2>the links to the other active spine or spines.

57
00:02:42.639 --> 00:02:44.639
<v Speaker 1>Okay, built in redundancy totally.

58
00:02:44.439 --> 00:02:47.000
<v Speaker 2>Built in, and you get redundancy at the leaf level

59
00:02:47.000 --> 00:02:50.439
<v Speaker 2>too for servers connecting to multiple leaves using things like VPC.

60
00:02:50.800 --> 00:02:52.840
<v Speaker 2>The physical resilience is just inherent.

61
00:02:52.919 --> 00:02:55.879
<v Speaker 1>Okay, physical structure makes sense. Now, This is where my

62
00:02:55.919 --> 00:02:58.400
<v Speaker 1>brain starts to hurt a little. The underlay and the overlay.

63
00:02:58.560 --> 00:03:01.400
<v Speaker 2>Ha. Yeah, let's use that roller coaster analogy. It actually

64
00:03:01.439 --> 00:03:02.080
<v Speaker 2>works pretty well.

65
00:03:02.120 --> 00:03:02.960
<v Speaker 1>Okay, hit me with it.

66
00:03:03.159 --> 00:03:06.599
<v Speaker 2>So the underlay, think of it as the physical roller

67
00:03:06.599 --> 00:03:11.039
<v Speaker 2>coaster track, the motors, the breaks. It's the foundation the

68
00:03:11.039 --> 00:03:14.039
<v Speaker 2>physical links between spines and leaves exactly. Its only job

69
00:03:14.120 --> 00:03:18.120
<v Speaker 2>is basic IP reachability, making sure all the key interfaces

70
00:03:18.120 --> 00:03:20.000
<v Speaker 2>on the leaves and spines can talk to each other.

71
00:03:20.280 --> 00:03:23.879
<v Speaker 2>It usually runs a simple routing protocol like OSPF or

72
00:03:24.039 --> 00:03:25.240
<v Speaker 2>isis just to.

73
00:03:25.199 --> 00:03:27.479
<v Speaker 1>Build that basic connectivity.

74
00:03:26.879 --> 00:03:29.960
<v Speaker 2>Map, right, And because of that spine and leaf connection pattern,

75
00:03:30.199 --> 00:03:34.039
<v Speaker 2>we get to use equal cost multipath routing ECMP. All

76
00:03:34.080 --> 00:03:36.560
<v Speaker 2>those links between a leaf and the multiple spines, they're

77
00:03:36.599 --> 00:03:39.240
<v Speaker 2>all active, all forwarding traffic at the same time.

78
00:03:39.360 --> 00:03:42.680
<v Speaker 1>So it's like layer three link aggregation, super fast.

79
00:03:42.479 --> 00:03:45.599
<v Speaker 2>Super fast, and super resilient. That's the underlay, the solid

80
00:03:45.639 --> 00:03:46.800
<v Speaker 2>fast foundation.

81
00:03:46.560 --> 00:03:50.080
<v Speaker 1>Okay, foundation lay. Now the overlay the roller coaster cars

82
00:03:50.080 --> 00:03:50.680
<v Speaker 1>and the riders.

83
00:03:51.000 --> 00:03:53.680
<v Speaker 2>That's it. This is where the vxcellent magic happens. The

84
00:03:53.719 --> 00:03:56.759
<v Speaker 2>overlay runs on top of that physical underlay. Vxcel An

85
00:03:56.840 --> 00:03:59.199
<v Speaker 2>takes your normal layer two frame like an Ethernet frame

86
00:03:59.240 --> 00:04:01.840
<v Speaker 2>from a server, and wraps it up inside a layer

87
00:04:01.919 --> 00:04:05.520
<v Speaker 2>three UDP packet. It tunnels L two over L three.

88
00:04:05.520 --> 00:04:11.840
<v Speaker 1>Okay, and it uses BGP EVPN to manage all this exactly.

89
00:04:12.919 --> 00:04:16.439
<v Speaker 2>EVPN is the control plane for this overlay. But the

90
00:04:16.480 --> 00:04:21.160
<v Speaker 2>real game changer vx land brings is multi tenancy AH.

91
00:04:20.839 --> 00:04:24.800
<v Speaker 1>Separating different customers or departments. So in the analogy, each

92
00:04:24.920 --> 00:04:28.720
<v Speaker 1>roller coaster car is a tenant like a VRF.

93
00:04:28.439 --> 00:04:31.680
<v Speaker 2>Perfect Each car is a VRS a separate routing world,

94
00:04:32.240 --> 00:04:35.079
<v Speaker 2>and the riders in that car are the vlands belonging

95
00:04:35.120 --> 00:04:35.800
<v Speaker 2>to that tenant.

96
00:04:36.040 --> 00:04:38.199
<v Speaker 1>And riders in different cars can't just talk to each other.

97
00:04:38.360 --> 00:04:42.600
<v Speaker 2>Nope, completely isolated by default unless you specifically build bridges

98
00:04:43.519 --> 00:04:45.040
<v Speaker 2>can figure route leaking between them.

99
00:04:45.040 --> 00:04:48.160
<v Speaker 1>Okay, that isolation is huge now practical point. Yeah that wrapping,

100
00:04:48.279 --> 00:04:51.360
<v Speaker 1>that encapsulation adds overhead, right, yeah.

101
00:04:51.040 --> 00:04:53.879
<v Speaker 2>Big time, about fifty bytes or so. So so you

102
00:04:54.040 --> 00:04:57.199
<v Speaker 2>absolutely must enable jembo frames on all those underlay links.

103
00:04:57.240 --> 00:04:58.759
<v Speaker 2>And to you nine thousand maybe.

104
00:04:58.560 --> 00:05:01.399
<v Speaker 1>Higher, right, because if you don't, what happens.

105
00:05:01.040 --> 00:05:03.759
<v Speaker 2>Fragmentation city small pings might work, but try moving a

106
00:05:03.800 --> 00:05:06.279
<v Speaker 2>real file. Packets get chopped up performance tanks. It's like

107
00:05:06.360 --> 00:05:07.519
<v Speaker 2>the number one deployment.

108
00:05:07.560 --> 00:05:11.439
<v Speaker 1>Gotcha, good tip, don't forget the mtumm. Okay, So moving

109
00:05:11.519 --> 00:05:13.519
<v Speaker 1>up to the control plane. This is really the heart

110
00:05:13.560 --> 00:05:16.800
<v Speaker 1>of EVPN, isn't it. Shifting from data plane learning.

111
00:05:16.800 --> 00:05:18.720
<v Speaker 2>Like flooding and praying with spanning tree.

112
00:05:18.920 --> 00:05:22.319
<v Speaker 1>Yeah, that mess, shifting that intelligence to the control plane

113
00:05:22.319 --> 00:05:26.000
<v Speaker 1>with BGPEVPN. What's the big win there? Operationally?

114
00:05:26.079 --> 00:05:29.279
<v Speaker 2>Oh, operationally it's night and day. Think about troubleshooting layer

115
00:05:29.319 --> 00:05:30.519
<v Speaker 2>two loops before it.

116
00:05:30.439 --> 00:05:32.800
<v Speaker 1>Was awful, tell me about it.

117
00:05:32.879 --> 00:05:36.959
<v Speaker 2>With EVPN, the local leaf sees m address, learns its

118
00:05:37.000 --> 00:05:40.519
<v Speaker 2>IP and bang, it advertises that MSEP pair as a

119
00:05:40.519 --> 00:05:41.560
<v Speaker 2>BGP route to.

120
00:05:41.560 --> 00:05:43.319
<v Speaker 1>The route reflectors the spines right.

121
00:05:43.399 --> 00:05:45.600
<v Speaker 2>The spines reflected to other leaves that need it. No

122
00:05:45.680 --> 00:05:48.160
<v Speaker 2>more network wide flooding to learn max CS.

123
00:05:48.399 --> 00:05:51.160
<v Speaker 1>So finding where a device is becomes a routing lookup,

124
00:05:51.199 --> 00:05:54.800
<v Speaker 1>not a frantic MP table search across dozens.

125
00:05:54.480 --> 00:05:58.920
<v Speaker 2>Of switches exactly. Troubleshooting L two problems becomes essentially L

126
00:05:58.959 --> 00:06:01.120
<v Speaker 2>three troubleshooting, much much easier.

127
00:06:01.199 --> 00:06:04.040
<v Speaker 1>Okay, so we've killed most broadcast issues, but what about

128
00:06:04.120 --> 00:06:09.279
<v Speaker 1>necessary evils like you know, ARP broadcast, unknown unicast, multicast

129
00:06:09.279 --> 00:06:10.600
<v Speaker 1>the bum traffic.

130
00:06:10.319 --> 00:06:12.079
<v Speaker 2>Right, you still need some way to handle that. VX

131
00:06:12.199 --> 00:06:15.839
<v Speaker 2>lane uses multicast in the underlay for this, Basically bum

132
00:06:15.879 --> 00:06:18.480
<v Speaker 2>traffic for a specific VX line segment of V and

133
00:06:18.560 --> 00:06:22.600
<v Speaker 2>I gets mapped to a specific multicast group in the underlay, and.

134
00:06:22.600 --> 00:06:26.120
<v Speaker 1>The spines act as the rps for those multicast groups.

135
00:06:26.199 --> 00:06:29.639
<v Speaker 2>Usually, yeah, you'd configure the spines as the rendezvous points,

136
00:06:29.920 --> 00:06:32.839
<v Speaker 2>and you'd want redundancy there too, using something like any

137
00:06:32.879 --> 00:06:36.199
<v Speaker 2>cast RP. So both spines can handle it actively makes sense.

138
00:06:36.959 --> 00:06:40.120
<v Speaker 1>Let's nail down a couple of interface terms, NVE and VTT.

139
00:06:40.399 --> 00:06:42.040
<v Speaker 1>They sound similar, they work together.

140
00:06:42.279 --> 00:06:45.920
<v Speaker 2>The NVE Network Virtual Interface is kind of the logical

141
00:06:45.959 --> 00:06:49.120
<v Speaker 2>engine on the leaf switch that does the actual vx

142
00:06:49.199 --> 00:06:51.639
<v Speaker 2>land encapsulation and decapsulation.

143
00:06:51.079 --> 00:06:52.959
<v Speaker 1>Thing, doing the wrapping and n wrapping right.

144
00:06:53.279 --> 00:06:56.439
<v Speaker 2>And the VTT Virtual Tunnel end point is the IP

145
00:06:56.519 --> 00:07:00.199
<v Speaker 2>address used as the source and destination for those vxland tunnels.

146
00:07:00.399 --> 00:07:04.879
<v Speaker 1>And that VTTPIP. It's usually a special loopback interface.

147
00:07:04.560 --> 00:07:07.600
<v Speaker 2>Always typically loop back one, and this is important. It's

148
00:07:07.639 --> 00:07:10.079
<v Speaker 2>different from the loopback you might use for the underlay

149
00:07:10.120 --> 00:07:12.319
<v Speaker 2>BGP peering, which is often loopback zero.

150
00:07:12.480 --> 00:07:15.839
<v Speaker 1>Why the separation why two loopbacks stability?

151
00:07:16.040 --> 00:07:20.160
<v Speaker 2>Mainly loopback zero is for the underlay riding protocol itself

152
00:07:20.680 --> 00:07:24.959
<v Speaker 2>rock solid reachability loop back one. The VTT address is

153
00:07:25.000 --> 00:07:28.360
<v Speaker 2>what the overlay tunnels use. Keeping them separate means if

154
00:07:28.360 --> 00:07:31.079
<v Speaker 2>something weird happens with your BGP peering, it doesn't necessarily

155
00:07:31.120 --> 00:07:34.319
<v Speaker 2>break your established vx land tunnels. It isolates the planes.

156
00:07:34.600 --> 00:07:37.519
<v Speaker 1>H good design practice. Okay, and we mentioned the spines

157
00:07:37.560 --> 00:07:40.000
<v Speaker 1>are rote reflekers. Why is that so vital for scaling?

158
00:07:40.920 --> 00:07:43.800
<v Speaker 2>Imagine if they weren't, every leaf switch would need a

159
00:07:43.839 --> 00:07:46.439
<v Speaker 2>direct BGP peering with every other leaf switch.

160
00:07:46.519 --> 00:07:48.439
<v Speaker 1>The full mesh Nightmare.

161
00:07:48.160 --> 00:07:52.160
<v Speaker 2>Total nightmare ten leaves forty five BGP sessions, twenty leaves,

162
00:07:52.319 --> 00:07:55.600
<v Speaker 2>one hundred and ninety sessions with route reflectors on the spines.

163
00:07:55.639 --> 00:07:57.519
<v Speaker 2>You add a new leaf, it just peers with the

164
00:07:57.920 --> 00:07:59.319
<v Speaker 2>say two spines, two new sessions.

165
00:07:59.399 --> 00:08:01.720
<v Speaker 1>That's it. That makes adding capacity way.

166
00:08:01.519 --> 00:08:03.920
<v Speaker 2>Way easier, massively easier. It's built for scale.

167
00:08:04.000 --> 00:08:06.399
<v Speaker 1>All right. Let's dig into that multi tenancy piece more

168
00:08:06.600 --> 00:08:09.680
<v Speaker 1>separation and routing between tenants. You mentioned. Roade targets are ts.

169
00:08:09.759 --> 00:08:12.199
<v Speaker 2>Yeah. Root targets are basically tags we attached to the

170
00:08:12.240 --> 00:08:14.839
<v Speaker 2>EVPN routes. Think of them like labels. They usually look

171
00:08:14.920 --> 00:08:17.279
<v Speaker 2>like as number, dot, I D maybe six five five

172
00:08:17.360 --> 00:08:19.920
<v Speaker 2>five zero one point one zero zero one or something.

173
00:08:20.199 --> 00:08:23.439
<v Speaker 1>And these tags control who gets witch routes exactly.

174
00:08:23.639 --> 00:08:27.519
<v Speaker 2>Each VRF each tenant has specific root targets. It exports

175
00:08:27.920 --> 00:08:30.879
<v Speaker 2>tags its routes with and imports accepts routes tagged with.

176
00:08:31.160 --> 00:08:34.600
<v Speaker 2>It's the BGP way of controlling visibility between virtual networks.

177
00:08:34.600 --> 00:08:36.799
<v Speaker 1>Okay, and we have two kinds of v and ies involved,

178
00:08:36.960 --> 00:08:38.360
<v Speaker 1>L two v and I and L three V and

179
00:08:38.399 --> 00:08:39.919
<v Speaker 1>I back to the roller custom let's do it.

180
00:08:39.960 --> 00:08:41.960
<v Speaker 2>The L two V and I. Think of that as

181
00:08:41.960 --> 00:08:45.519
<v Speaker 2>the identifier for a specific group of riders within one car.

182
00:08:45.840 --> 00:08:48.200
<v Speaker 2>It maps directly to a traditional VLAN So.

183
00:08:48.200 --> 00:08:50.759
<v Speaker 1>VLAN ten might become L two v and I one

184
00:08:50.840 --> 00:08:51.879
<v Speaker 1>zero ten something like that.

185
00:08:51.960 --> 00:08:54.840
<v Speaker 2>Yeah, it carries that layer two traffic across the fabric

186
00:08:55.360 --> 00:08:58.480
<v Speaker 2>and the big plus you can have over sixteen million

187
00:08:58.559 --> 00:09:01.759
<v Speaker 2>v and ees, way past the old four thousand VLAN.

188
00:09:01.600 --> 00:09:04.399
<v Speaker 1>Limit, huge scale increase. Okay, So that's L two V

189
00:09:04.480 --> 00:09:06.279
<v Speaker 1>and I for L two traffic within a tenant. What

190
00:09:06.320 --> 00:09:07.399
<v Speaker 1>about the L three V and I.

191
00:09:07.720 --> 00:09:09.279
<v Speaker 2>The L three V and I is different. It's not

192
00:09:09.320 --> 00:09:12.720
<v Speaker 2>for carrying VLAN traffic directly. It's the dedicated routing interface

193
00:09:12.799 --> 00:09:15.240
<v Speaker 2>for the entire VRF, the whole tenant car.

194
00:09:15.440 --> 00:09:16.840
<v Speaker 1>Okay, so what's its job?

195
00:09:16.960 --> 00:09:19.840
<v Speaker 2>Its only job is Layer three routing interviewland routing for

196
00:09:19.960 --> 00:09:22.600
<v Speaker 2>devices within that tenant, especially when they live on different

197
00:09:22.679 --> 00:09:23.279
<v Speaker 2>leaf switches.

198
00:09:23.519 --> 00:09:26.039
<v Speaker 1>Ah. So if a server on leaf one in VLAN

199
00:09:26.159 --> 00:09:28.039
<v Speaker 1>ten needs to talk to a server on Leaf five

200
00:09:28.159 --> 00:09:30.960
<v Speaker 1>in VLAN twenty, but they're in the same tenet VRF.

201
00:09:31.000 --> 00:09:33.720
<v Speaker 2>The traffic goes from the source server to its leaf.

202
00:09:33.960 --> 00:09:38.399
<v Speaker 2>Leaf one gets routed using the shared gateway, encapsulated using

203
00:09:38.399 --> 00:09:40.519
<v Speaker 2>the L three V and I tunnel, sent across the

204
00:09:40.559 --> 00:09:44.000
<v Speaker 2>underlay to Leaf five, decapsulated, and then routed to the

205
00:09:44.000 --> 00:09:45.919
<v Speaker 2>destination server in Vland twenty.

206
00:09:46.080 --> 00:09:48.200
<v Speaker 1>Got it. The L three V and I is the

207
00:09:48.320 --> 00:09:51.720
<v Speaker 1>dedicated interview land highway for that tenant across the fabric.

208
00:09:51.799 --> 00:09:53.120
<v Speaker 2>Perfect analogy, and.

209
00:09:53.120 --> 00:09:55.960
<v Speaker 1>This ties into that fabric any cast gateway feature right,

210
00:09:55.960 --> 00:09:57.639
<v Speaker 1>making every leaf an active router.

211
00:09:57.840 --> 00:10:01.559
<v Speaker 2>Absolutely Forget old HSRP or VA, where one router was

212
00:10:01.600 --> 00:10:03.559
<v Speaker 2>active and the other just sat there waiting to fail.

213
00:10:03.360 --> 00:10:04.919
<v Speaker 1>Over wasting half your capacity.

214
00:10:05.039 --> 00:10:08.039
<v Speaker 2>Right with any cast gateway, all the leaf switches share

215
00:10:08.080 --> 00:10:11.399
<v Speaker 2>the exact same virtual MAC address and the same default

216
00:10:11.480 --> 00:10:13.399
<v Speaker 2>gateway IP address for a given v Land.

217
00:10:13.519 --> 00:10:16.000
<v Speaker 1>So a server just sends traffic to its gateway.

218
00:10:15.679 --> 00:10:18.720
<v Speaker 2>IP and whichever leaf receives it can immediately route it,

219
00:10:19.080 --> 00:10:22.840
<v Speaker 2>no tromboning traffic to a specific active core switch. Every

220
00:10:22.919 --> 00:10:24.799
<v Speaker 2>leaf is an active Layer three core for the v

221
00:10:24.960 --> 00:10:27.840
<v Speaker 2>lands it serves. It distributes the routing load beautifully.

222
00:10:28.080 --> 00:10:32.120
<v Speaker 1>Very cool. Okay, final big section, getting traffic in and

223
00:10:32.159 --> 00:10:35.519
<v Speaker 1>out of this fancy fabric external connectivity. We need a

224
00:10:35.519 --> 00:10:37.039
<v Speaker 1>border leaf for that YEP.

225
00:10:38.039 --> 00:10:41.080
<v Speaker 2>One or more leaves need to be designated as border leafs.

226
00:10:41.679 --> 00:10:44.360
<v Speaker 2>They're the ones physically connected to the outside world, the wan,

227
00:10:44.639 --> 00:10:47.320
<v Speaker 2>maybe a firewall cluster, the rest of the campus network.

228
00:10:47.039 --> 00:10:48.960
<v Speaker 1>And they need some extra configuration.

229
00:10:48.480 --> 00:10:51.679
<v Speaker 2>Obviously for sure, because now you're bridging the BGPEVPN world

230
00:10:51.759 --> 00:10:55.639
<v Speaker 2>with you know, potentially OSPF static routes whatever is running externally.

231
00:10:55.840 --> 00:10:58.960
<v Speaker 1>So when that border leaf learns an external route, say

232
00:10:59.000 --> 00:11:01.559
<v Speaker 1>from OSTF, how does it tell the rest of the

233
00:11:01.559 --> 00:11:02.320
<v Speaker 1>fabric about it.

234
00:11:02.679 --> 00:11:07.240
<v Speaker 2>Inside EVPN, it advertises those external prefixes as EVPN Type

235
00:11:07.240 --> 00:11:10.000
<v Speaker 2>five routes. That's the key type for external.

236
00:11:09.559 --> 00:11:11.960
<v Speaker 1>Reachability, okay, type five. And what is that rout Perry.

237
00:11:12.240 --> 00:11:16.080
<v Speaker 2>It carries the external prefix like your WHAN subnet. And critically,

238
00:11:16.320 --> 00:11:18.639
<v Speaker 2>the next hop for that route is set to the

239
00:11:18.720 --> 00:11:21.000
<v Speaker 2>vtep ip address of the border leaf itself.

240
00:11:21.080 --> 00:11:23.679
<v Speaker 1>Ah. So if leaf seven needs to send traffic to

241
00:11:23.679 --> 00:11:24.200
<v Speaker 1>the one it.

242
00:11:24.120 --> 00:11:26.440
<v Speaker 2>Sees the type five route sees, the next hop is

243
00:11:26.440 --> 00:11:29.840
<v Speaker 2>the border leaf's VTEP encapsulates the packet using the L three,

244
00:11:29.919 --> 00:11:31.960
<v Speaker 2>V and I tunnel pointed at the border leaf and

245
00:11:32.080 --> 00:11:33.519
<v Speaker 2>fires it off slick.

246
00:11:34.480 --> 00:11:38.480
<v Speaker 1>Okay, But now the tricky part integrating OSPF for something externally.

247
00:11:39.759 --> 00:11:42.159
<v Speaker 1>Isn't there a big risk of asymmetric routing?

248
00:11:42.320 --> 00:11:45.440
<v Speaker 2>Huge risk. This is probably the second biggest deployment headache

249
00:11:45.519 --> 00:11:46.240
<v Speaker 2>after MTU.

250
00:11:46.440 --> 00:11:49.240
<v Speaker 1>Traffic goes out border leaf A tries to come back

251
00:11:49.240 --> 00:11:51.480
<v Speaker 1>in be a border leaf B, and the firewall freaks

252
00:11:51.480 --> 00:11:53.240
<v Speaker 1>out because it didn't see the outbound.

253
00:11:52.799 --> 00:11:57.559
<v Speaker 2>Flow exactly that scenario state mismatch, broken connections. So the

254
00:11:57.559 --> 00:11:59.000
<v Speaker 2>goal has to be symmetric routing.

255
00:11:59.159 --> 00:11:59.919
<v Speaker 1>How do you force that?

256
00:12:00.039 --> 00:12:01.879
<v Speaker 2>You have to play with the routing protocol metrics or

257
00:12:01.919 --> 00:12:05.279
<v Speaker 2>administrative distances. You need to make sure the path back

258
00:12:05.279 --> 00:12:07.720
<v Speaker 2>into the fabric from the external network prefers the same

259
00:12:07.759 --> 00:12:09.320
<v Speaker 2>border leaf the traffic went out on.

260
00:12:09.480 --> 00:12:13.519
<v Speaker 1>So maybe making the EVPN route learn via IBGP more

261
00:12:13.600 --> 00:12:15.360
<v Speaker 1>preferred than the OSPF route.

262
00:12:15.440 --> 00:12:18.919
<v Speaker 2>That's a very common way. Default IBGP eight is two hundred,

263
00:12:19.000 --> 00:12:22.159
<v Speaker 2>but you can lower it, say below OSPFS one ten.

264
00:12:22.639 --> 00:12:26.159
<v Speaker 2>That usually ensures return traffic prefers the EVPN path back

265
00:12:26.200 --> 00:12:27.919
<v Speaker 2>through the correct border leaf. You got to make sure

266
00:12:28.000 --> 00:12:29.559
<v Speaker 2>forward and return paths match.

267
00:12:29.879 --> 00:12:34.399
<v Speaker 1>Gotcha last detail, the default route getting zero points zero

268
00:12:34.480 --> 00:12:37.480
<v Speaker 1>point zero zero zero advertised across the fabric, so everything

269
00:12:37.480 --> 00:12:40.639
<v Speaker 1>can reach the Internet, presumably via the border leaf you

270
00:12:40.720 --> 00:12:42.960
<v Speaker 1>mentioned needing two BGP commands for this.

271
00:12:43.080 --> 00:12:45.799
<v Speaker 2>Yeah, people trip over this. Sometimes you need default information

272
00:12:45.919 --> 00:12:50.039
<v Speaker 2>originate under the BGP VRF canfig that tells BGP, hey,

273
00:12:50.080 --> 00:12:51.919
<v Speaker 2>I want to advertise a default route.

274
00:12:52.000 --> 00:12:52.759
<v Speaker 1>Okay, step one.

275
00:12:52.840 --> 00:12:55.799
<v Speaker 2>But BGP won't advertise a route unless it's actually in

276
00:12:55.840 --> 00:12:58.759
<v Speaker 2>its BGP table. So you also need the network point

277
00:12:58.840 --> 00:13:01.159
<v Speaker 2>zero point zero point zero or a zero zero command

278
00:13:01.159 --> 00:13:04.200
<v Speaker 2>in that same VRF address family configuration.

279
00:13:03.799 --> 00:13:05.879
<v Speaker 1>To actually inject the route into BGP so it can

280
00:13:05.879 --> 00:13:06.879
<v Speaker 1>be originated exactly.

281
00:13:06.919 --> 00:13:10.000
<v Speaker 2>You need both default information originate enables it, networks point

282
00:13:10.080 --> 00:13:13.000
<v Speaker 2>zero point zero point zero zero zero, provides the route itself,

283
00:13:13.159 --> 00:13:15.360
<v Speaker 2>then the border LAFE advertises it as a Type five

284
00:13:15.639 --> 00:13:17.200
<v Speaker 2>and the whole fabric knows how to get out.

285
00:13:17.320 --> 00:13:19.919
<v Speaker 1>Makes perfect sense. Wow, Okay, we covered a lot of ground,

286
00:13:19.960 --> 00:13:22.320
<v Speaker 1>we really did, but the summary feels clear now. VX

287
00:13:22.399 --> 00:13:26.519
<v Speaker 1>land BGPEDPN. It smashes the old vland limits from massive scale,

288
00:13:26.759 --> 00:13:30.679
<v Speaker 1>gives you amazing performance with ECMP, and crucially uses that

289
00:13:30.720 --> 00:13:33.399
<v Speaker 1>smart control plane to dish the nightmare of layer two

290
00:13:33.399 --> 00:13:34.240
<v Speaker 1>loops and flooding.

291
00:13:34.519 --> 00:13:37.639
<v Speaker 2>Yeah, the big picture is this blend of layer two

292
00:13:37.759 --> 00:13:41.279
<v Speaker 2>VPN technology running over a solid layer three foundation. It's

293
00:13:41.279 --> 00:13:46.559
<v Speaker 2>all about flexibility, speed and making network deployments, especially using templates,

294
00:13:46.799 --> 00:13:48.720
<v Speaker 2>much faster and more reliable.

295
00:13:49.000 --> 00:13:50.960
<v Speaker 1>And for you listening, if you want to go even deeper.

296
00:13:51.320 --> 00:13:55.000
<v Speaker 1>The source material mentioned things like multipod and multi site,

297
00:13:55.480 --> 00:13:58.720
<v Speaker 1>extending this fabric idea across different data centers.

298
00:13:58.480 --> 00:14:02.399
<v Speaker 2>Right, making multiple physical sites look like one giant logical

299
00:14:02.399 --> 00:14:06.440
<v Speaker 2>fabric multipod more connecting separate fabrics together multi.

300
00:14:06.159 --> 00:14:07.720
<v Speaker 1>Site, which leads to our final thought.

301
00:14:08.000 --> 00:14:11.840
<v Speaker 2>If you're stretching one logical fabric across multiple physical locations,

302
00:14:11.879 --> 00:14:15.720
<v Speaker 2>maybe even miles apart, what's the absolute most critical routing

303
00:14:15.759 --> 00:14:19.240
<v Speaker 2>principle you have to maintain everywhere across all sites to

304
00:14:19.320 --> 00:14:20.480
<v Speaker 2>keep things working smoothly.

305
00:14:20.799 --> 00:14:23.120
<v Speaker 1>It's not just about can packets get there?

306
00:14:23.200 --> 00:14:26.360
<v Speaker 2>No, it comes back to symmetry and filtering, ensuring traffic

307
00:14:26.399 --> 00:14:28.879
<v Speaker 2>flows follow the same path out and back globally and

308
00:14:28.919 --> 00:14:32.000
<v Speaker 2>making sure your route filtering is consistent everywhere. That becomes

309
00:14:32.039 --> 00:14:35.080
<v Speaker 2>absolutely paramount. Get that wrong in a multi site setup

310
00:14:35.159 --> 00:14:36.679
<v Speaker 2>and you're in for a world of pain.

311
00:14:37.080 --> 00:14:39.960
<v Speaker 1>Something to definitely keep in mind. Okay, that was a

312
00:14:40.080 --> 00:14:43.039
<v Speaker 1>fantastic deep dive. Thanks for bringing this complex topic.

313
00:14:43.039 --> 00:14:44.120
<v Speaker 2>Glad we can unpack it.

314
00:14:44.039 --> 00:14:46.200
<v Speaker 1>And thank you for joining us. We'll Catch you next

315
00:14:46.240 --> 00:14:47.360
<v Speaker 1>time on the Deep Dive