WEBVTT

1
00:00:00.120 --> 00:00:03.720
<v Speaker 1>Imagine stepping behind the curtain of the digital world, not

2
00:00:03.839 --> 00:00:07.960
<v Speaker 1>just you know, seeing the data flowing, but truly understanding

3
00:00:07.960 --> 00:00:12.199
<v Speaker 1>the blueprints how networks are actually built, why they're designed

4
00:00:12.199 --> 00:00:16.600
<v Speaker 1>that way, and how they connect well everything. Right today,

5
00:00:16.800 --> 00:00:20.199
<v Speaker 1>we're doing just that, a deep dive into the let's say,

6
00:00:20.359 --> 00:00:22.839
<v Speaker 1>art and science of enterprise network design.

7
00:00:22.600 --> 00:00:24.920
<v Speaker 2>And we're using a pretty serious guide for this journey.

8
00:00:24.920 --> 00:00:30.280
<v Speaker 2>It's an official certification resource, basically the playbook network architects use.

9
00:00:30.399 --> 00:00:33.039
<v Speaker 1>Yeah, packed up the fundamentals, but also the really cutting

10
00:00:33.119 --> 00:00:36.000
<v Speaker 1>edge stuff that makes today's networks teck exactly.

11
00:00:36.320 --> 00:00:38.000
<v Speaker 2>So our mission here is to pull out the most

12
00:00:38.159 --> 00:00:41.039
<v Speaker 2>vital bits of knowledge from all this material. We want

13
00:00:41.079 --> 00:00:45.520
<v Speaker 2>you to walk away not just informed, but really getting

14
00:00:45.560 --> 00:00:48.159
<v Speaker 2>what it takes to build a network that's stable, secure,

15
00:00:48.359 --> 00:00:50.439
<v Speaker 2>and crucially scalable.

16
00:00:50.119 --> 00:00:54.000
<v Speaker 1>Connecting the dots basically theory to practice. That's the plan. Okay,

17
00:00:54.280 --> 00:00:57.920
<v Speaker 1>let's dive in, starting right at the foundation ip addressing.

18
00:00:58.280 --> 00:01:01.759
<v Speaker 1>It's kind of a story of well scarcity leading eventually

19
00:01:01.799 --> 00:01:03.039
<v Speaker 1>to abundance, it really is.

20
00:01:03.119 --> 00:01:06.439
<v Speaker 2>It all kicked off with IPv four way back in nineteen.

21
00:01:06.159 --> 00:01:08.480
<v Speaker 1>Eighty one ancient history and tech terms.

22
00:01:08.400 --> 00:01:11.239
<v Speaker 2>Pretty much, but by the mid nineties people were already

23
00:01:11.280 --> 00:01:15.120
<v Speaker 2>talking about apparent exhaustion running out of addresses. It seemed

24
00:01:15.200 --> 00:01:16.920
<v Speaker 2>like a potential crisis.

25
00:01:16.439 --> 00:01:18.480
<v Speaker 1>A major roadblock for the Internet's growth.

26
00:01:18.200 --> 00:01:22.719
<v Speaker 2>Surely, absolutely, and that pressure it sparked some incredible ingenuity

27
00:01:23.280 --> 00:01:25.719
<v Speaker 2>to cope with this dwindling supply. We got things like

28
00:01:25.840 --> 00:01:28.519
<v Speaker 2>CIDR classless inner domain routing.

29
00:01:28.400 --> 00:01:30.079
<v Speaker 1>Which made address allocation more.

30
00:01:30.000 --> 00:01:35.280
<v Speaker 2>Flexible, right exactly, and NAT network address translation, letting many

31
00:01:35.280 --> 00:01:38.879
<v Speaker 2>devices hide behind one public IP and of course RFC

32
00:01:39.000 --> 00:01:40.959
<v Speaker 2>nineteen eighteen private address space.

33
00:01:41.159 --> 00:01:45.200
<v Speaker 1>These weren't just technical tricks, they were fundamental design strategies totally.

34
00:01:45.319 --> 00:01:48.000
<v Speaker 2>They had to be think about. ITA gave out the

35
00:01:48.079 --> 00:01:51.480
<v Speaker 2>last main IPv four blocks in twenty eleven, am in

36
00:01:51.480 --> 00:01:54.840
<v Speaker 2>in twenty fifteen, so even now, being smart about how

37
00:01:54.879 --> 00:01:58.640
<v Speaker 2>you allocate those remaining IPv four addresses is still a

38
00:01:58.680 --> 00:02:01.200
<v Speaker 2>critical design task thinking about that scarcity.

39
00:02:01.319 --> 00:02:04.480
<v Speaker 1>Yeah, it was a really clever, maybe less obvious design

40
00:02:04.519 --> 00:02:06.760
<v Speaker 1>workaround that came out of it, beyond just you know,

41
00:02:06.799 --> 00:02:08.280
<v Speaker 1>the basic NAT definition.

42
00:02:08.400 --> 00:02:10.960
<v Speaker 2>That's a good point. NAT often gets criticized right for

43
00:02:11.120 --> 00:02:12.400
<v Speaker 2>breaking end to end stuff.

44
00:02:12.479 --> 00:02:14.879
<v Speaker 1>Yeah, network peerists aren't always fans, but.

45
00:02:15.039 --> 00:02:17.919
<v Speaker 2>Its ability to let companies merge even if they happened

46
00:02:17.919 --> 00:02:21.639
<v Speaker 2>to be using the same private IP ranges internally. That

47
00:02:21.800 --> 00:02:26.319
<v Speaker 2>was a lifesaver. Ah the overlapping networks problem precisely imagine

48
00:02:26.360 --> 00:02:30.039
<v Speaker 2>trying to readdress thousands, maybe tens of thousands of devices

49
00:02:30.120 --> 00:02:35.520
<v Speaker 2>during a merger, hugely expensive, risky nightmare. NAT provided a practical,

50
00:02:35.599 --> 00:02:39.759
<v Speaker 2>if not perfectly elegant workaround. It kept businesses running and

51
00:02:39.840 --> 00:02:44.120
<v Speaker 2>related to that efficiency, understanding subnetting and VLSU variable length

52
00:02:44.159 --> 00:02:47.719
<v Speaker 2>subnet masking is just essential for designers.

53
00:02:47.120 --> 00:02:48.439
<v Speaker 1>Not just chopping up networks.

54
00:02:48.520 --> 00:02:52.560
<v Speaker 2>No, it's about precision. Assigning just enough addresses, like using

55
00:02:52.599 --> 00:02:56.199
<v Speaker 2>a tiny thirty mask only two usable IPS for a

56
00:02:56.280 --> 00:02:59.120
<v Speaker 2>point to point link between routers, minimal.

57
00:02:58.800 --> 00:03:01.120
<v Speaker 1>Waste, or thirty two for a address.

58
00:03:00.879 --> 00:03:03.879
<v Speaker 2>Exactly gives the router a stable identity that's always up,

59
00:03:04.000 --> 00:03:06.719
<v Speaker 2>perfect for management using just one address. It's all about

60
00:03:06.759 --> 00:03:09.479
<v Speaker 2>efficiency and enabling good route summarization later.

61
00:03:09.599 --> 00:03:13.240
<v Speaker 1>Okay, addresses assigned, But for any of this to actually work,

62
00:03:13.599 --> 00:03:16.719
<v Speaker 1>we need ways to translate names people use into these numbers,

63
00:03:17.000 --> 00:03:19.599
<v Speaker 1>and for devices on the same network to find each

64
00:03:19.599 --> 00:03:20.759
<v Speaker 1>other's hardware addresses.

65
00:03:21.120 --> 00:03:25.039
<v Speaker 2>Absolutely essential. Plumbing DNS, the Domain Name system does the

66
00:03:25.080 --> 00:03:29.080
<v Speaker 2>heavy lifting translating website names into IP addresses so routers

67
00:03:29.120 --> 00:03:30.080
<v Speaker 2>know where to send stuff.

68
00:03:30.199 --> 00:03:32.400
<v Speaker 1>The Internet's phone book basically.

69
00:03:32.000 --> 00:03:35.879
<v Speaker 2>Kind of yeah, and then locally on the same network segment,

70
00:03:35.919 --> 00:03:39.919
<v Speaker 2>you've got ARP Address resolution protocol that's mapping the known

71
00:03:39.960 --> 00:03:42.599
<v Speaker 2>IP address to the physical MIS address needed for the

72
00:03:42.639 --> 00:03:43.479
<v Speaker 2>final delivery.

73
00:03:43.560 --> 00:03:45.919
<v Speaker 1>They seeing basic, but if they fail.

74
00:03:45.840 --> 00:03:49.240
<v Speaker 2>Everything grinds to a halt. Their robust design is fundamental.

75
00:03:49.319 --> 00:03:52.159
<v Speaker 1>Okay. So if IPv four was this story of scarcity,

76
00:03:52.599 --> 00:03:55.840
<v Speaker 1>then IPv six that's about abundance, right, A huge lead

77
00:03:55.840 --> 00:03:57.960
<v Speaker 1>from thirty two bids to one hundred and twenty eight bits.

78
00:03:58.199 --> 00:04:00.199
<v Speaker 1>How does that change the design thinking.

79
00:04:00.240 --> 00:04:03.240
<v Speaker 2>Oh, it's night and day. That vast address space, I mean,

80
00:04:03.240 --> 00:04:06.280
<v Speaker 2>it's almost unfathomably large. Let's designers ditch many of the

81
00:04:06.319 --> 00:04:09.319
<v Speaker 2>complex workarounds that IPv four scarcity forced on us. Like

82
00:04:09.439 --> 00:04:13.560
<v Speaker 2>Matt potentially, yes, but beyond just more addresses, IPv six

83
00:04:13.639 --> 00:04:16.399
<v Speaker 2>was designed with improvements. It has a simpler header, which

84
00:04:16.439 --> 00:04:20.199
<v Speaker 2>routers can process faster less overhead. Right, security is built in.

85
00:04:20.480 --> 00:04:24.000
<v Speaker 2>iPSC is an optional, it's a requirement, and path MTU

86
00:04:24.079 --> 00:04:27.120
<v Speaker 2>discovery is standard, which eliminates the need for routers to

87
00:04:27.160 --> 00:04:30.639
<v Speaker 2>fragment packets. That's a big deal for efficiency and reliability.

88
00:04:30.759 --> 00:04:34.240
<v Speaker 1>So a cleaner, potentially faster, more secure foundation.

89
00:04:34.680 --> 00:04:38.079
<v Speaker 2>That's the idea, and think about land design. The recommendation

90
00:04:38.240 --> 00:04:40.399
<v Speaker 2>is to use a sixty four subnet for pretty much

91
00:04:40.399 --> 00:04:41.199
<v Speaker 2>every land segment.

92
00:04:41.439 --> 00:04:45.279
<v Speaker 1>Sixty four. That's billions upon billions of addresses for one

93
00:04:45.399 --> 00:04:46.480
<v Speaker 1>network segment.

94
00:04:46.319 --> 00:04:49.199
<v Speaker 2>Exactly more than you could ever possibly use. But it

95
00:04:49.279 --> 00:04:53.519
<v Speaker 2>massively simplifies adjusts planning, and it enables things like SLA

96
00:04:53.639 --> 00:04:57.560
<v Speaker 2>stateless Address autoconfiguration where devices can essentially give themselves a

97
00:04:57.600 --> 00:04:59.720
<v Speaker 2>unique address without needing a DHCP server.

98
00:05:00.079 --> 00:05:03.439
<v Speaker 1>That's a huge shift from meticulously planning every single IPv

99
00:05:03.519 --> 00:05:06.800
<v Speaker 1>four subnet. And you mentioned a really key design practice

100
00:05:06.800 --> 00:05:09.639
<v Speaker 1>for getting IPv six addresses to avoid future pain.

101
00:05:09.879 --> 00:05:12.759
<v Speaker 2>Yes, this is crucial for long term stability, to avoid

102
00:05:12.839 --> 00:05:16.160
<v Speaker 2>the massive renumbering projects that plagued IPv four networks when

103
00:05:16.160 --> 00:05:19.079
<v Speaker 2>you changed ISPs. The strong recommendation is to get your

104
00:05:19.079 --> 00:05:22.759
<v Speaker 2>IPv six address blocks directly from a regional Internet registry

105
00:05:22.800 --> 00:05:24.120
<v Speaker 2>and RIR.

106
00:05:24.000 --> 00:05:28.120
<v Speaker 1>Like Elion in North America or apn EK in Asia Pacific.

107
00:05:28.000 --> 00:05:31.000
<v Speaker 2>Exactly, rather than just getting a block from your service provider.

108
00:05:31.199 --> 00:05:35.319
<v Speaker 2>This makes your address based portable independent. It's a foundational

109
00:05:35.319 --> 00:05:37.040
<v Speaker 2>decision for future proofing in.

110
00:05:37.000 --> 00:05:40.959
<v Speaker 1>This structure from INA down to RIRs than ISPs. Then

111
00:05:41.040 --> 00:05:45.439
<v Speaker 1>companies that helps keep the global Internet routing table manageable.

112
00:05:45.800 --> 00:05:49.120
<v Speaker 2>It does. It allows for massive route summarization at the

113
00:05:49.199 --> 00:05:53.000
<v Speaker 2>higher levels, even with the colossal number of potential networks.

114
00:05:53.319 --> 00:05:56.079
<v Speaker 1>Okay, so we've got this amazing IPv six world, but

115
00:05:56.399 --> 00:05:59.240
<v Speaker 1>let's face it, IPv four isn't going away overnight. How

116
00:05:59.319 --> 00:06:01.959
<v Speaker 1>do network our caitects designed for this transition? How do

117
00:06:02.040 --> 00:06:03.839
<v Speaker 1>they bridge that gap? Good question.

118
00:06:04.240 --> 00:06:07.160
<v Speaker 2>The preferred method, the gold standard, really is dual stack,

119
00:06:07.480 --> 00:06:11.000
<v Speaker 2>running both IPv four and IPv six protocols simultaneously on

120
00:06:11.079 --> 00:06:14.759
<v Speaker 2>all your devices and network segments. Everything speaks both languages.

121
00:06:14.360 --> 00:06:17.199
<v Speaker 1>So new stuff uses IPv six. Old stuff still works

122
00:06:17.199 --> 00:06:18.560
<v Speaker 1>on IPv four pretty much.

123
00:06:18.879 --> 00:06:22.319
<v Speaker 2>But sometimes a full dual stack rollout isn't immediately feasible,

124
00:06:22.360 --> 00:06:24.720
<v Speaker 2>so designers have other tools, transitional tools.

125
00:06:24.759 --> 00:06:27.600
<v Speaker 1>Tunneling is one option, like six to four or isotap.

126
00:06:27.399 --> 00:06:31.240
<v Speaker 2>Right encapsulating IPv six packets inside ipp four packets to

127
00:06:31.279 --> 00:06:34.240
<v Speaker 2>cross parts of the network that only understand IPv four.

128
00:06:34.519 --> 00:06:36.519
<v Speaker 2>And then there are translation mechanisms.

129
00:06:36.160 --> 00:06:38.720
<v Speaker 1>INDs sixty four and DNS sixty four exactly.

130
00:06:39.120 --> 00:06:42.639
<v Speaker 2>They allow IPv six only clients to talk to IPv

131
00:06:42.720 --> 00:06:46.319
<v Speaker 2>four only servers by translating addresses and protocols at the boundary.

132
00:06:46.800 --> 00:06:50.319
<v Speaker 2>These are definitely migration tools, not usually the desired end state,

133
00:06:50.439 --> 00:06:52.480
<v Speaker 2>but vital for the transition period.

134
00:06:52.720 --> 00:06:57.240
<v Speaker 1>Okay, so addressing is clearly the beddrog. But once devices

135
00:06:57.279 --> 00:07:00.000
<v Speaker 1>have addresses, how does the traffic figure out the best

136
00:07:00.120 --> 00:07:02.480
<v Speaker 1>way to get from A to B? Especially in a big,

137
00:07:02.560 --> 00:07:04.079
<v Speaker 1>complex enterprise network.

138
00:07:04.120 --> 00:07:07.399
<v Speaker 2>Oh now we're talking about the network's GPS routing protocols

139
00:07:07.480 --> 00:07:09.040
<v Speaker 2>guiding that traffic efficiently.

140
00:07:09.240 --> 00:07:11.120
<v Speaker 1>And the first big design choice here seems to be

141
00:07:11.120 --> 00:07:14.839
<v Speaker 1>this fundamental split distance vector versus link state protocols. What's

142
00:07:14.879 --> 00:07:15.639
<v Speaker 1>the core difference.

143
00:07:15.680 --> 00:07:18.720
<v Speaker 2>It's a huge difference, and it impacts scalability. How fast

144
00:07:18.720 --> 00:07:21.279
<v Speaker 2>the network recovers from chain is convergent speed and just

145
00:07:21.360 --> 00:07:25.639
<v Speaker 2>general complexity. Distance vector protocols like the classic RIP.

146
00:07:25.600 --> 00:07:28.120
<v Speaker 1>Routing information protocol showing its age a bit.

147
00:07:28.000 --> 00:07:33.240
<v Speaker 2>Now, Definitely they're simpler. Conceptually, Routers basically learn from their

148
00:07:33.279 --> 00:07:37.920
<v Speaker 2>immediate neighbors, sharing their entire routing table periodically, routing by

149
00:07:38.000 --> 00:07:39.360
<v Speaker 2>rumor some call it, which.

150
00:07:39.240 --> 00:07:42.120
<v Speaker 1>Sounds like it could be slow. If something changes far away.

151
00:07:42.000 --> 00:07:44.839
<v Speaker 2>It can be, and it can lead to more overhead

152
00:07:45.000 --> 00:07:49.079
<v Speaker 2>sending those full tables around. Link state protocols like OSPF

153
00:07:49.079 --> 00:07:53.040
<v Speaker 2>for ISIS work very differently. Also, each router builds a

154
00:07:53.079 --> 00:07:56.519
<v Speaker 2>complete map, a topology of the entire network area it's in.

155
00:07:57.120 --> 00:08:00.439
<v Speaker 2>They achieve this by flooding information about their own direct

156
00:08:00.439 --> 00:08:01.399
<v Speaker 2>connections their.

157
00:08:01.199 --> 00:08:03.519
<v Speaker 1>Link states, so everyone gets the same map.

158
00:08:03.480 --> 00:08:06.399
<v Speaker 2>Within an area. Yes, and with that map, each router

159
00:08:06.639 --> 00:08:10.480
<v Speaker 2>independently calculates the shortest path to every destination using an

160
00:08:10.480 --> 00:08:12.279
<v Speaker 2>algorithm like diykstras.

161
00:08:11.920 --> 00:08:16.319
<v Speaker 1>Which means faster convergence. Right yeah, if LINKO down, everyone recalculates.

162
00:08:15.759 --> 00:08:18.759
<v Speaker 2>Quickly, much faster typically, and they only send updates when

163
00:08:18.839 --> 00:08:22.199
<v Speaker 2>something actually changes, not the whole table periodically, so less

164
00:08:22.279 --> 00:08:25.279
<v Speaker 2>routine overhead. The trade off is they generally need more

165
00:08:25.319 --> 00:08:27.959
<v Speaker 2>memory and CPU power on the router and can be

166
00:08:28.000 --> 00:08:29.920
<v Speaker 2>more complex to configure initially.

167
00:08:30.040 --> 00:08:32.600
<v Speaker 1>And then there are hybrids like eig.

168
00:08:32.440 --> 00:08:36.799
<v Speaker 2>RP right Enhanced Interior Gateway Routing Protocol. Cisco developed it

169
00:08:36.840 --> 00:08:39.159
<v Speaker 2>to try and get the best of both worlds. Faster

170
00:08:39.279 --> 00:08:43.559
<v Speaker 2>convergence than RIP, but maybe less complex than OSPF. In

171
00:08:43.600 --> 00:08:46.600
<v Speaker 2>some ways, it uses aspects of both approaches.

172
00:08:46.799 --> 00:08:50.000
<v Speaker 1>Okay, so you might have multiple protocols running, maybe some

173
00:08:50.080 --> 00:08:53.919
<v Speaker 1>static routes someone configured manually. How does a router decide

174
00:08:53.919 --> 00:08:56.360
<v Speaker 1>which route to actually believe or trust the most.

175
00:08:56.559 --> 00:09:00.320
<v Speaker 2>That's where administrative distance or AD comes in. It's a

176
00:09:00.320 --> 00:09:03.159
<v Speaker 2>critical concept for designers to master. Think of it as

177
00:09:03.159 --> 00:09:06.679
<v Speaker 2>a trustworthiness score. Lower AD wins, So a.

178
00:09:06.679 --> 00:09:10.799
<v Speaker 1>Route learned via EIGRP with its default eight of ninety.

179
00:09:10.639 --> 00:09:13.879
<v Speaker 2>Is considered more trustworthy than an OSPF route default one

180
00:09:14.000 --> 00:09:15.879
<v Speaker 2>ten or a RIP route.

181
00:09:15.639 --> 00:09:17.360
<v Speaker 1>At one twenty than static routes.

182
00:09:17.240 --> 00:09:20.720
<v Speaker 2>Default eighty of one, usually the most trusted because presumably

183
00:09:20.759 --> 00:09:23.759
<v Speaker 2>the administrator put it there for a specific reason. Understanding

184
00:09:23.799 --> 00:09:26.960
<v Speaker 2>AD is absolutely key to predicting and controlling how traffic

185
00:09:27.000 --> 00:09:29.919
<v Speaker 2>actually flows, especially when you start mixing routing sources like

186
00:09:30.000 --> 00:09:33.000
<v Speaker 2>redistributing routes between OSPF and EIGRP.

187
00:09:33.240 --> 00:09:36.559
<v Speaker 1>Got it trustworthiness first, but then among routes from the

188
00:09:36.600 --> 00:09:39.440
<v Speaker 1>same protocol, how does it pick the best path. It's

189
00:09:39.480 --> 00:09:41.799
<v Speaker 1>got to be more than just counting routers like RIP does.

190
00:09:42.039 --> 00:09:46.120
<v Speaker 2>Oh Absolutely, hopcount is a very crude metric. Modern protocols

191
00:09:46.120 --> 00:09:50.399
<v Speaker 2>are much more sophisticated. OSPF uses cost, which by default

192
00:09:50.480 --> 00:09:53.240
<v Speaker 2>is calculated based on the bandwidth of the link. Faster

193
00:09:53.320 --> 00:09:55.080
<v Speaker 2>links get a lower cost, making them more.

194
00:09:54.960 --> 00:09:58.480
<v Speaker 1>Profitable, so ten giglink beats a one giglink exactly.

195
00:09:58.919 --> 00:10:02.200
<v Speaker 2>EIGRP is e and more complex. Its metric can factor

196
00:10:02.240 --> 00:10:06.720
<v Speaker 2>in bandwidth, delay, interface load, and even reliability. This allows

197
00:10:06.759 --> 00:10:09.600
<v Speaker 2>designers to really fine tune path selection based on what

198
00:10:09.679 --> 00:10:12.960
<v Speaker 2>matters most for the application. Maybe lowest delay for voice,

199
00:10:13.039 --> 00:10:14.360
<v Speaker 2>highest bandwidth for file.

200
00:10:14.200 --> 00:10:18.000
<v Speaker 1>Transfers, and the big nightmare for routing loops, right traffic

201
00:10:18.039 --> 00:10:21.000
<v Speaker 1>going round and round forever. How do designers prevent.

202
00:10:20.799 --> 00:10:24.080
<v Speaker 2>That routing loops are definitely catastrophic? They can melt down

203
00:10:24.120 --> 00:10:28.039
<v Speaker 2>a network segment. Fast protocols have built in loop prevention mechanisms,

204
00:10:28.120 --> 00:10:29.799
<v Speaker 2>things like split horizon.

205
00:10:29.480 --> 00:10:32.000
<v Speaker 1>Don't advertise a route back out the same way you learned.

206
00:10:31.759 --> 00:10:34.879
<v Speaker 2>It precisely simple but effective. Poison reverse is a more

207
00:10:34.919 --> 00:10:38.519
<v Speaker 2>aggressive version. Then there are mechanisms like maximum hopcounts RAP

208
00:10:38.639 --> 00:10:41.720
<v Speaker 2>gives up after fifteen hops EGRP typically defaults to one

209
00:10:41.799 --> 00:10:45.480
<v Speaker 2>hundred and fundamentally good route summarization is also a loop

210
00:10:45.519 --> 00:10:50.080
<v Speaker 2>mitigation technique. How does summarization help with loops by hiding

211
00:10:50.159 --> 00:10:54.360
<v Speaker 2>detailed topology information. If a specific link flaps up and

212
00:10:54.399 --> 00:10:57.159
<v Speaker 2>down within a summarized block, the rest of the network

213
00:10:57.200 --> 00:11:01.080
<v Speaker 2>doesn't necessarily need to know or react, using instability and

214
00:11:01.120 --> 00:11:05.320
<v Speaker 2>preventing potential transient loops during convergence. It shrinks routing tables

215
00:11:05.320 --> 00:11:08.559
<v Speaker 2>and limits the scope of changes, crucial for scalability.

216
00:11:08.759 --> 00:11:11.200
<v Speaker 1>Makes sense, Let's dive into some of these protocols a

217
00:11:11.279 --> 00:11:15.320
<v Speaker 1>bit more. EIGRP, what's a key design advantage it offers.

218
00:11:15.080 --> 00:11:19.519
<v Speaker 2>Well beyond its fast convergence using the DAL algorithm. A

219
00:11:19.639 --> 00:11:22.799
<v Speaker 2>really powerful and somewhat unique feature for designers is its

220
00:11:22.799 --> 00:11:27.000
<v Speaker 2>ability to do unequal cost load sharing, Meaning most protocols,

221
00:11:27.039 --> 00:11:29.480
<v Speaker 2>if they load balance, only do it across paths that

222
00:11:29.519 --> 00:11:33.879
<v Speaker 2>have the exact same metric the same cost. EIGRP using

223
00:11:33.919 --> 00:11:36.919
<v Speaker 2>the variance command, can be configured to send traffic across

224
00:11:37.000 --> 00:11:40.039
<v Speaker 2>multiple paths, even if one path is say slightly slower

225
00:11:40.159 --> 00:11:42.399
<v Speaker 2>or has a higher metric than the best path.

226
00:11:42.279 --> 00:11:44.320
<v Speaker 1>So you can use links that might otherwise sit idle.

227
00:11:44.440 --> 00:11:48.120
<v Speaker 2>Exactly, you can get better overall bandwidth utilization out of

228
00:11:48.159 --> 00:11:52.879
<v Speaker 2>your network infrastructure. That's a significant practical advantage in many designs.

229
00:11:53.200 --> 00:11:57.399
<v Speaker 1>Okay, what about IASSI Intermediate system to intermediate system sounds

230
00:11:57.399 --> 00:12:01.200
<v Speaker 1>a bit old school OSI, but service love it. Why.

231
00:12:01.600 --> 00:12:05.320
<v Speaker 2>It is based on OSI principles running directly over layer two,

232
00:12:05.360 --> 00:12:09.159
<v Speaker 2>but It's incredibly robust and scalable for enterprise designers who

233
00:12:09.279 --> 00:12:12.720
<v Speaker 2>might encounter it or consider it. Its inherent hierarchical nature

234
00:12:12.759 --> 00:12:15.720
<v Speaker 2>is a plus for very large networks, but maybe more

235
00:12:15.759 --> 00:12:18.720
<v Speaker 2>relevant today is its early adoption and strong support for

236
00:12:18.759 --> 00:12:22.440
<v Speaker 2>things like wide metrics. Wide metrics using a larger field

237
00:12:22.480 --> 00:12:25.679
<v Speaker 2>like twenty four bits for the metric calculation. This gives

238
00:12:25.720 --> 00:12:29.879
<v Speaker 2>extremely fine grained control over path selection compared to say

239
00:12:30.320 --> 00:12:34.720
<v Speaker 2>OSPF's default cost calculation. It's ideal for sophisticated traffic engineering

240
00:12:34.720 --> 00:12:37.399
<v Speaker 2>where you need to precisely steer different types of traffic

241
00:12:37.440 --> 00:12:40.639
<v Speaker 2>down specific paths based on very subtle differences.

242
00:12:40.759 --> 00:12:45.039
<v Speaker 1>Interesting and OSPF open shortest path first probably the most

243
00:12:45.080 --> 00:12:48.440
<v Speaker 1>common interior gateway protocol and enterprises key design points.

244
00:12:48.639 --> 00:12:52.399
<v Speaker 2>It's the workhorse for sure. Uses Dykstra's SPF algorithm cost

245
00:12:52.480 --> 00:12:56.159
<v Speaker 2>based on bandwidth. Designers need to understand the neighbor relationship requirements,

246
00:12:56.200 --> 00:13:00.000
<v Speaker 2>things like matching area IDs timers MTU sizes must match

247
00:13:00.080 --> 00:13:01.519
<v Speaker 2>for two routers to become neighbors.

248
00:13:01.840 --> 00:13:06.720
<v Speaker 1>In the concept of areas area zero the backbone stub areas.

249
00:13:06.360 --> 00:13:10.720
<v Speaker 2>Yes OSTF areas are fundamental to its scalability, breaking a

250
00:13:10.840 --> 00:13:13.720
<v Speaker 2>large network into areas limits the scope of the SPF

251
00:13:13.759 --> 00:13:17.159
<v Speaker 2>calculation and the amount of routing information routers need to handle.

252
00:13:17.600 --> 00:13:19.759
<v Speaker 2>For designers, a common insight is that while the different

253
00:13:19.759 --> 00:13:24.480
<v Speaker 2>area types STUB, totally stubby, NSSA offer flexibility, sometimes simpler

254
00:13:24.559 --> 00:13:25.480
<v Speaker 2>is better, like.

255
00:13:25.559 --> 00:13:27.759
<v Speaker 1>Using totally stubby areas for remote sites.

256
00:13:27.879 --> 00:13:30.960
<v Speaker 2>Exactly, a totally stubby area gets only a default route

257
00:13:30.960 --> 00:13:33.919
<v Speaker 2>from its area border router ABR. It hides all the

258
00:13:33.960 --> 00:13:37.600
<v Speaker 2>complexity of the rest of the network. This dramatically simplifies

259
00:13:37.600 --> 00:13:40.440
<v Speaker 2>the riting table on the remote routers, saving resources and

260
00:13:40.519 --> 00:13:44.080
<v Speaker 2>often making troubleshooting easier. And OSPF three just adapts this

261
00:13:44.159 --> 00:13:45.720
<v Speaker 2>whole structure for IPv six.

262
00:13:45.840 --> 00:13:49.960
<v Speaker 1>Right. Finally, the Big one BGP Border Gateway Protocol. This

263
00:13:50.000 --> 00:13:52.200
<v Speaker 1>connects the Internet right. Enterprises use it to talk to

264
00:13:52.200 --> 00:13:52.960
<v Speaker 1>their ISPs.

265
00:13:53.159 --> 00:13:56.679
<v Speaker 2>That's its main role. Yes, BGP is fundamentally different. It's

266
00:13:56.720 --> 00:13:59.720
<v Speaker 2>a path vector protocol. It's less concerned with the shortest

267
00:13:59.720 --> 00:14:02.879
<v Speaker 2>path and more concerned with the best policy compliant path

268
00:14:02.960 --> 00:14:06.519
<v Speaker 2>between different organizations, different autonomous systems or asns.

269
00:14:06.759 --> 00:14:09.559
<v Speaker 1>So it's about business relationships and routing policies as much

270
00:14:09.559 --> 00:14:10.519
<v Speaker 1>as technical metrics.

271
00:14:10.840 --> 00:14:15.399
<v Speaker 2>Very much so. Enterprises mainly deal with EBGP external BTP

272
00:14:15.639 --> 00:14:19.120
<v Speaker 2>for AP peering with ISPs or other companies, and sometimes

273
00:14:19.159 --> 00:14:22.720
<v Speaker 2>IBGP internal BGP to carry those external routes within their

274
00:14:22.759 --> 00:14:24.080
<v Speaker 2>own network, and.

275
00:14:23.960 --> 00:14:26.960
<v Speaker 1>That IBGP I hear it has a scaling challenge the

276
00:14:27.000 --> 00:14:28.639
<v Speaker 1>full mesh requirement.

277
00:14:28.320 --> 00:14:32.320
<v Speaker 2>It does by default, every IBGP router needs to peer

278
00:14:32.440 --> 00:14:35.600
<v Speaker 2>directly with every other IBGP router in the same as

279
00:14:36.080 --> 00:14:39.039
<v Speaker 2>in a large network. That's a lot of connections to manage.

280
00:14:39.440 --> 00:14:42.120
<v Speaker 2>That's where design solutions like root reflectors come in.

281
00:14:42.240 --> 00:14:42.960
<v Speaker 1>How do they help?

282
00:14:43.200 --> 00:14:45.960
<v Speaker 2>A root reflector acts like a central point. Routers peer

283
00:14:45.960 --> 00:14:48.440
<v Speaker 2>with the reflector and the reflector reflects the routes it

284
00:14:48.519 --> 00:14:51.159
<v Speaker 2>learns to its other peers. This breaks the need for

285
00:14:51.200 --> 00:14:55.039
<v Speaker 2>that full mesh, making IBGP much more scalable in large designs.

286
00:14:55.320 --> 00:14:58.279
<v Speaker 2>Confederations are another more complex solution.

287
00:14:58.519 --> 00:15:03.639
<v Speaker 1>And BGP paths selectction. It's complicated with all those attributes

288
00:15:03.679 --> 00:15:07.960
<v Speaker 1>like aspath med local preference, which one do Enterprise designers

289
00:15:07.960 --> 00:15:09.679
<v Speaker 1>often manipulate for practical outcomes.

290
00:15:10.000 --> 00:15:13.159
<v Speaker 2>Local preference is a really common and powerful one. It's

291
00:15:13.200 --> 00:15:16.840
<v Speaker 2>an attribute used inside your own autonomous system. You set

292
00:15:16.879 --> 00:15:19.639
<v Speaker 2>a higher local preference value on the routes coming in

293
00:15:19.720 --> 00:15:22.639
<v Speaker 2>from the ISP connection you prefer to use for outbound traffic.

294
00:15:22.679 --> 00:15:25.240
<v Speaker 1>So you tell your internal routers, hey, use this Internet

295
00:15:25.240 --> 00:15:26.559
<v Speaker 1>link first if it's available.

296
00:15:26.679 --> 00:15:30.519
<v Speaker 2>Exactly. It's a primary tool for influencing your outbound traffic

297
00:15:30.559 --> 00:15:33.720
<v Speaker 2>flow when you have multiple Internet connections. A very important

298
00:15:33.720 --> 00:15:37.519
<v Speaker 2>for traffic engineering and ensuring you use your primary maybe

299
00:15:37.679 --> 00:15:40.639
<v Speaker 2>higher bandwidth or lower cost link effectively.

300
00:15:40.759 --> 00:15:45.919
<v Speaker 1>Okay, routing protocols chosen, paths selected, but architects need more

301
00:15:45.960 --> 00:15:48.960
<v Speaker 1>granular control ye right and faster failure detection.

302
00:15:49.120 --> 00:15:53.799
<v Speaker 2>Absolutely. That gets us into route manipulation redistribution. Taking routes

303
00:15:53.840 --> 00:15:57.960
<v Speaker 2>from one protocol say OSPF and injecting them into another

304
00:15:58.080 --> 00:16:00.879
<v Speaker 2>like BGP is powerful for connecting different parts of a network,

305
00:16:01.240 --> 00:16:04.320
<v Speaker 2>but it's also risky. Also, you can easily create routing

306
00:16:04.320 --> 00:16:08.240
<v Speaker 2>loops or suboptimal paths if you're not careful. So designers

307
00:16:08.320 --> 00:16:10.840
<v Speaker 2>must use right filtering with things like route maps or

308
00:16:10.840 --> 00:16:14.240
<v Speaker 2>distribute lists to control exactly which routes get redistributed and

309
00:16:14.320 --> 00:16:16.279
<v Speaker 2>prevent feedback. It's essential and.

310
00:16:16.360 --> 00:16:20.440
<v Speaker 1>Policy based routing PBR. That sounds like overriding the routing table,

311
00:16:20.559 --> 00:16:21.519
<v Speaker 1>it is essentially.

312
00:16:21.759 --> 00:16:25.039
<v Speaker 2>PBR lets you make routing decisions based on criteria other

313
00:16:25.080 --> 00:16:27.960
<v Speaker 2>than just the destination address, like the source IP address

314
00:16:28.080 --> 00:16:31.120
<v Speaker 2>or even application type, so a designer could say all

315
00:16:31.120 --> 00:16:34.320
<v Speaker 2>traffic from the guests Wi Fi network, regardless of destination,

316
00:16:34.639 --> 00:16:37.919
<v Speaker 2>should be sent out this specific maybe cheaper internet link.

317
00:16:38.240 --> 00:16:41.600
<v Speaker 2>It allows for very granular policy enforcement.

318
00:16:41.360 --> 00:16:45.360
<v Speaker 1>Very handy, and for failures, waiting for routing protocol timers

319
00:16:45.360 --> 00:16:46.080
<v Speaker 1>could be slow.

320
00:16:45.960 --> 00:16:49.279
<v Speaker 2>Way too slow sometimes, especially for real time applications. That's

321
00:16:49.320 --> 00:16:53.080
<v Speaker 2>where BFD BI Directional Forwarding Detection is a game changer.

322
00:16:53.399 --> 00:16:57.039
<v Speaker 2>It's a lightweight protocol designed purely for super fast failure detection,

323
00:16:57.320 --> 00:16:59.440
<v Speaker 2>often in subsecond timeframes.

324
00:16:58.960 --> 00:17:00.480
<v Speaker 1>Works across different links types.

325
00:17:00.320 --> 00:17:02.799
<v Speaker 2>YEP, any media type, and it integrates with most routing

326
00:17:02.840 --> 00:17:08.799
<v Speaker 2>protocols BGP, eigrp ospf isis. When BFD detects a link failure,

327
00:17:08.880 --> 00:17:11.960
<v Speaker 2>it immediately tolls the routing protocol, which can then converge

328
00:17:12.119 --> 00:17:14.680
<v Speaker 2>much much faster than waiting for its own HELLO timers

329
00:17:14.759 --> 00:17:18.359
<v Speaker 2>or hold timers to expire. Critical design element for high availability.

330
00:17:18.559 --> 00:17:22.559
<v Speaker 1>Okay, infrastructure addressed, traffic routed and controlled. But how do

331
00:17:22.599 --> 00:17:26.680
<v Speaker 1>you actually watch all this? Keep tabs on performance health issues?

332
00:17:26.839 --> 00:17:29.200
<v Speaker 2>Right? You need the eyes and ears network management and

333
00:17:29.279 --> 00:17:34.759
<v Speaker 2>monitoring and the cornerstone protocol here is SNMP Simple Network Management.

334
00:17:34.359 --> 00:17:36.680
<v Speaker 1>Protocol still simple after all these years.

335
00:17:36.839 --> 00:17:39.640
<v Speaker 2>Oh well, the name's stuck. It's the industry's standard way

336
00:17:39.680 --> 00:17:42.599
<v Speaker 2>for a network management system and NMS to query devices

337
00:17:42.599 --> 00:17:46.799
<v Speaker 2>for information like CPU load, interface errors, or for devices

338
00:17:46.839 --> 00:17:48.480
<v Speaker 2>to send alerts called traps.

339
00:17:48.759 --> 00:17:51.240
<v Speaker 1>But security was an issue with early versions, wasn't.

340
00:17:51.079 --> 00:17:55.759
<v Speaker 2>It huge issue? SNMPv one and v twoc used community strings,

341
00:17:55.759 --> 00:17:59.640
<v Speaker 2>which were basically just plaintext passwords. Anyone sniffing the network

342
00:17:59.640 --> 00:18:02.559
<v Speaker 2>could right them. That's why the critical design decision today

343
00:18:02.680 --> 00:18:05.240
<v Speaker 2>is to use smmpv three. What is V three ad

344
00:18:05.480 --> 00:18:09.279
<v Speaker 2>robust security? It provides authentication verifying who is asking and

345
00:18:09.400 --> 00:18:12.079
<v Speaker 2>encryption scrambling the data. You can have different levels like

346
00:18:12.119 --> 00:18:16.519
<v Speaker 2>off nopriv authentication no encryption or off PREV both. Deploying

347
00:18:16.640 --> 00:18:20.440
<v Speaker 2>SNMPv three securely is non negotiable for modern network management

348
00:18:20.480 --> 00:18:21.079
<v Speaker 2>plane design.

349
00:18:21.319 --> 00:18:25.319
<v Speaker 1>Okay, so SNMP tells you device status, but what about

350
00:18:25.319 --> 00:18:28.799
<v Speaker 1>the traffic itself? What's actually flowing across the network?

351
00:18:28.920 --> 00:18:32.680
<v Speaker 2>For that level of detail, NetFlow is invaluable or its

352
00:18:32.680 --> 00:18:34.799
<v Speaker 2>standardized version ipfax.

353
00:18:35.119 --> 00:18:35.720
<v Speaker 1>How does it work?

354
00:18:36.039 --> 00:18:39.599
<v Speaker 2>It collects metadata about IP flows. A flow is basically

355
00:18:39.759 --> 00:18:42.720
<v Speaker 2>a sequence of packets going between the same source and

356
00:18:42.759 --> 00:18:47.160
<v Speaker 2>destination ips and ports using the same protocol. NetFlow records

357
00:18:47.160 --> 00:18:50.240
<v Speaker 2>details like how many packets, how many bytes, timestamps to

358
00:18:50.440 --> 00:18:51.559
<v Speaker 2>s markings, so you.

359
00:18:51.480 --> 00:18:53.759
<v Speaker 1>Can see who's talking to whom and how much data

360
00:18:53.799 --> 00:18:54.960
<v Speaker 1>they're sending exactly.

361
00:18:55.200 --> 00:18:58.119
<v Speaker 2>But the surprising insight for designers is how versatile this

362
00:18:58.200 --> 00:19:00.640
<v Speaker 2>data is. Yes, it's great for troubleshoot why is the

363
00:19:00.640 --> 00:19:04.240
<v Speaker 2>network slow, or capacity planning, or even billing. But it's

364
00:19:04.279 --> 00:19:08.359
<v Speaker 2>also incredibly powerful for security spotting, denial of service attacks,

365
00:19:08.440 --> 00:19:11.680
<v Speaker 2>or unusual traffic patterns that might indicate malware, and for

366
00:19:11.720 --> 00:19:13.559
<v Speaker 2>application performance monitoring too.

367
00:19:13.680 --> 00:19:15.799
<v Speaker 1>Though it's more than just counting bytes much more.

368
00:19:15.839 --> 00:19:18.759
<v Speaker 2>It gives deep visibility with relatively low impact on the

369
00:19:18.759 --> 00:19:20.119
<v Speaker 2>network devices themselves.

370
00:19:20.319 --> 00:19:23.200
<v Speaker 1>What about other data to aid tools network teams rely

371
00:19:23.319 --> 00:19:24.119
<v Speaker 1>on well.

372
00:19:24.440 --> 00:19:29.039
<v Speaker 2>CDP Cisco Discovery Protocol is ubiquitous in Cisco environments. Layer

373
00:19:29.079 --> 00:19:33.440
<v Speaker 2>two protocol lets Cisco devices automatically find their neighbors.

374
00:19:32.839 --> 00:19:34.839
<v Speaker 1>Super useful for mapping things out quickly.

375
00:19:35.000 --> 00:19:38.759
<v Speaker 2>Incredibly useful shows you the neighbor's device type, IP address,

376
00:19:38.920 --> 00:19:41.680
<v Speaker 2>the specific port you're connected to. But and this is

377
00:19:41.720 --> 00:19:45.680
<v Speaker 2>a key security design point, you absolutely must disable CDP

378
00:19:45.880 --> 00:19:48.240
<v Speaker 2>on interfaces facing untrusted.

379
00:19:47.759 --> 00:19:49.960
<v Speaker 1>Networks like the Internet connections exactly.

380
00:19:50.079 --> 00:19:52.599
<v Speaker 2>You don't want to be broadcasting details about your internal

381
00:19:52.599 --> 00:19:55.240
<v Speaker 2>devices to the outside world. And then there's cislog for

382
00:19:55.319 --> 00:19:59.799
<v Speaker 2>logging events, right, it's the standard way for devices, routers, switches, firewalls,

383
00:19:59.799 --> 00:20:02.960
<v Speaker 2>s first to send event messages to a central cislog server.

384
00:20:03.599 --> 00:20:07.319
<v Speaker 2>Messages are categorized by a facility like OSPF for system

385
00:20:07.599 --> 00:20:11.839
<v Speaker 2>and severity level from debugging up to emergency for designers,

386
00:20:12.039 --> 00:20:15.759
<v Speaker 2>Ensuring consistent and useful logging is configured across the infrastructure

387
00:20:16.079 --> 00:20:18.160
<v Speaker 2>is crucial for troubleshooting and auditing.

388
00:20:18.319 --> 00:20:21.000
<v Speaker 1>Got it eyes and ears covered. Now let's get into

389
00:20:21.000 --> 00:20:25.680
<v Speaker 1>actually building the structures land one and cloud design. Starting

390
00:20:25.680 --> 00:20:29.160
<v Speaker 1>with a campus land that classic three layer model core distribution,

391
00:20:29.319 --> 00:20:30.839
<v Speaker 1>access is that's still the way to go.

392
00:20:31.119 --> 00:20:35.039
<v Speaker 2>It absolutely still is, maybe with some variations. That hierarchical

393
00:20:35.079 --> 00:20:38.799
<v Speaker 2>model provides a really solid framework for designing scalable, resilient,

394
00:20:38.880 --> 00:20:40.599
<v Speaker 2>and manageable campus networks.

395
00:20:40.680 --> 00:20:42.200
<v Speaker 1>Can you break down the rolls quickly?

396
00:20:42.599 --> 00:20:46.279
<v Speaker 2>Sure? Access layer is where your end users and devices connect,

397
00:20:46.599 --> 00:20:50.720
<v Speaker 2>think switches and wiring closets, provides port security power over

398
00:20:50.799 --> 00:20:55.799
<v Speaker 2>Ethernet for phones and aps. VLAN assignments not sare the edge. Right,

399
00:20:56.039 --> 00:21:00.160
<v Speaker 2>Then the distribution layer aggregates the connections from multiple access switches.

400
00:21:00.480 --> 00:21:03.440
<v Speaker 2>This is a really critical layer. It often handles routing

401
00:21:03.480 --> 00:21:08.880
<v Speaker 2>between vlands, intervland routing, enforces access control policies, defines broadcast

402
00:21:08.920 --> 00:21:13.640
<v Speaker 2>domain boundaries, and aggregates wiring closet uplinks. It's the policy

403
00:21:13.680 --> 00:21:16.319
<v Speaker 2>and aggregation point and the core. The core is all

404
00:21:16.319 --> 00:21:19.640
<v Speaker 2>about speed and reliability. Its job is simply to switch

405
00:21:19.640 --> 00:21:23.599
<v Speaker 2>traffic between distribution blocks as fast as possible. No complex

406
00:21:23.640 --> 00:21:27.279
<v Speaker 2>policies here, just high speed transport, usually a pair of powerful,

407
00:21:27.440 --> 00:21:28.440
<v Speaker 2>redundant switches.

408
00:21:28.720 --> 00:21:33.200
<v Speaker 1>And this separation helps with what troubleshooting, scaling both.

409
00:21:33.559 --> 00:21:35.920
<v Speaker 2>If there's a problem in one access block, it's less

410
00:21:36.000 --> 00:21:38.920
<v Speaker 2>likely to impact the whole network. Need to add more users,

411
00:21:39.240 --> 00:21:42.160
<v Speaker 2>you add access switches and connect them to distribution. Need

412
00:21:42.200 --> 00:21:45.680
<v Speaker 2>more capacity between buildings, you upgrade the core. It provides

413
00:21:45.799 --> 00:21:49.880
<v Speaker 2>clear boundaries and predictable performance. For smaller sites, you might

414
00:21:49.920 --> 00:21:53.079
<v Speaker 2>see a collapsed core where distribution and core functions are

415
00:21:53.079 --> 00:21:55.759
<v Speaker 2>done on the same switches to save cost makes.

416
00:21:55.640 --> 00:21:59.839
<v Speaker 1>Sense, and connecting these layers providing enough bandwidth and redundancy.

417
00:22:00.319 --> 00:22:01.440
<v Speaker 1>What are the key tools?

418
00:22:01.559 --> 00:22:05.240
<v Speaker 2>Ether channel is a big one. Bundling multiple physical links,

419
00:22:05.240 --> 00:22:08.119
<v Speaker 2>say four to one gig links into one logical four

420
00:22:08.160 --> 00:22:08.839
<v Speaker 2>gig link.

421
00:22:08.799 --> 00:22:11.480
<v Speaker 1>Increases bandwidth and provides redundancy.

422
00:22:11.000 --> 00:22:14.119
<v Speaker 2>Exactly if one physical link in the bundle fails, traffic

423
00:22:14.160 --> 00:22:18.279
<v Speaker 2>automatically uses the remaining links huge for resilient uplinks between

424
00:22:18.359 --> 00:22:21.440
<v Speaker 2>layers and at the access layer. POE power over Ethernet

425
00:22:21.480 --> 00:22:23.279
<v Speaker 2>is just fundamental.

426
00:22:22.599 --> 00:22:26.880
<v Speaker 1>Now powering phones, cameras, wireless aps directly through the network.

427
00:22:26.519 --> 00:22:31.079
<v Speaker 2>Cable YEP simplifies wiring massively. You have different standards now, POE,

428
00:22:31.359 --> 00:22:36.000
<v Speaker 2>POE plus eight, Cisco's UPOE offering even more power. Designers

429
00:22:36.039 --> 00:22:38.440
<v Speaker 2>need to calculate power budgets for their access switches.

430
00:22:38.799 --> 00:22:41.960
<v Speaker 1>Okay, Layer two loops are the enemy in switch networks.

431
00:22:42.240 --> 00:22:45.920
<v Speaker 1>Spanding Tree Protocol STP prevents them, but it could be

432
00:22:45.960 --> 00:22:47.119
<v Speaker 1>slow to converge right.

433
00:22:47.079 --> 00:22:49.640
<v Speaker 2>The original STPA. Yes, that's why we have a whole

434
00:22:49.680 --> 00:22:53.599
<v Speaker 2>toolkit of enhancements. Port Fast is essential on ports connecting

435
00:22:53.599 --> 00:22:57.200
<v Speaker 2>to end devices like PCs or servers. It skips the

436
00:22:57.279 --> 00:23:00.319
<v Speaker 2>sup listening learning phases, so the port comes up.

437
00:23:00.200 --> 00:23:03.599
<v Speaker 1>Immediately, no waiting thirty fifty seconds for the port to work. Right.

438
00:23:04.000 --> 00:23:07.680
<v Speaker 2>Then you have security features built around STP. Bpdu guard

439
00:23:07.759 --> 00:23:10.720
<v Speaker 2>is critical. You put that on port fast enabled ports.

440
00:23:10.960 --> 00:23:14.480
<v Speaker 2>If that port ever receives an BTDU packet, which it

441
00:23:14.519 --> 00:23:16.079
<v Speaker 2>never should from an end device, it.

442
00:23:16.039 --> 00:23:17.640
<v Speaker 1>Means someone plugged in a switch where they.

443
00:23:17.559 --> 00:23:21.160
<v Speaker 2>Shouldn't have exactly a potential rogue switch trying to participate

444
00:23:21.200 --> 00:23:24.599
<v Speaker 2>in STP. BBDU guard instantly shuts down the port to

445
00:23:24.599 --> 00:23:27.759
<v Speaker 2>protect the network. Root guard is another one prevents a

446
00:23:27.799 --> 00:23:30.799
<v Speaker 2>switch on a specific port from becoming the STP root bridge.

447
00:23:30.960 --> 00:23:32.200
<v Speaker 2>Maintaining your design.

448
00:23:31.960 --> 00:23:34.279
<v Speaker 1>Topology and UDLD for fiber.

449
00:23:33.960 --> 00:23:37.559
<v Speaker 2>Links, Unidirectional link detection very important for fiber where you

450
00:23:37.599 --> 00:23:40.240
<v Speaker 2>can have a situation where transmit works but receive fails

451
00:23:40.519 --> 00:23:44.759
<v Speaker 2>or vice versa, STP might not detect that, potentially causing loops.

452
00:23:45.480 --> 00:23:49.039
<v Speaker 2>UDLD specifically checks for this two way communication.

453
00:23:49.519 --> 00:23:52.400
<v Speaker 1>Moving up the stack to layer three availability, keeping that

454
00:23:52.480 --> 00:23:56.440
<v Speaker 1>default gateway always reachable. That's where fhrps come in.

455
00:23:56.799 --> 00:24:00.319
<v Speaker 2>First hop redundancy protocols absolutely vital. The idea is to

456
00:24:00.359 --> 00:24:03.000
<v Speaker 2>have two or more routers share a virtual IP address

457
00:24:03.039 --> 00:24:06.960
<v Speaker 2>and MSS address, presenting themselves as a single logical default

458
00:24:06.960 --> 00:24:08.400
<v Speaker 2>gateway to end devices.

459
00:24:08.480 --> 00:24:10.880
<v Speaker 1>So if one router fails, the other takes over seamlessly.

460
00:24:11.000 --> 00:24:14.519
<v Speaker 2>That's the goal. HSRP hot stand by Router Protocol is Cisco's.

461
00:24:14.839 --> 00:24:17.599
<v Speaker 2>It has one active rider and one or more standby riders.

462
00:24:17.920 --> 00:24:22.519
<v Speaker 2>VRRP Virtual Router Redundancy Protocol is the IETF standard. Similar

463
00:24:22.559 --> 00:24:26.039
<v Speaker 2>concepts with the Master and Backups and GLBP Gateway load

464
00:24:26.079 --> 00:24:29.400
<v Speaker 2>Balancing Protocol also ciscers. The unique thing here is that

465
00:24:29.440 --> 00:24:33.039
<v Speaker 2>it allows all participating routers to be active simultaneously, load

466
00:24:33.079 --> 00:24:36.839
<v Speaker 2>balancing traffic across them using different virtual MS addresses can

467
00:24:36.880 --> 00:24:40.599
<v Speaker 2>provide better resource utilization than active standby models.

468
00:24:40.400 --> 00:24:42.480
<v Speaker 1>And for even higher levels of switch redundancy.

469
00:24:42.599 --> 00:24:47.279
<v Speaker 2>Technologies like Cisco's VSS Virtual Switching System or the newer

470
00:24:47.359 --> 00:24:51.119
<v Speaker 2>Stackwise Virtual and Catalyst nine thousands are game changers. They

471
00:24:51.160 --> 00:24:53.920
<v Speaker 2>allow you to merge two physical switches into a single

472
00:24:54.000 --> 00:24:56.960
<v Speaker 2>logical switch from a management and control plane.

473
00:24:56.680 --> 00:24:59.480
<v Speaker 1>Perspective, so they appears one big switch exactly.

474
00:25:00.000 --> 00:25:02.599
<v Speaker 2>This eliminates the need for STP between them, allows for

475
00:25:02.759 --> 00:25:07.799
<v Speaker 2>true active ether channel links to downstream devices, multi chassis

476
00:25:07.839 --> 00:25:13.079
<v Speaker 2>ether channel, and simplifies configuration significantly, huge boost for core

477
00:25:13.160 --> 00:25:15.480
<v Speaker 2>and distribution layer resilience in bandwidth.

478
00:25:15.559 --> 00:25:19.200
<v Speaker 1>Okay, connectivity sorted, but what about application performance? Making sure

479
00:25:19.279 --> 00:25:20.880
<v Speaker 1>voice and video calls don't break.

480
00:25:20.680 --> 00:25:24.559
<v Speaker 2>Up quality of service QoS? It's not an optional extra anymore.

481
00:25:24.599 --> 00:25:27.200
<v Speaker 2>It's a core design requirement, especially if you have limited

482
00:25:27.200 --> 00:25:29.400
<v Speaker 2>bandwidth like over a whan link, or if you run

483
00:25:29.480 --> 00:25:30.680
<v Speaker 2>real time applications.

484
00:25:30.759 --> 00:25:31.960
<v Speaker 1>So how does it work? Generally?

485
00:25:32.319 --> 00:25:36.359
<v Speaker 2>The dominant model today is diffserve differentiated services. You first

486
00:25:36.359 --> 00:25:39.960
<v Speaker 2>classified traffic, identify what it is, voice, video, book data

487
00:25:40.039 --> 00:25:43.119
<v Speaker 2>best effort. Then you mark it, usually by setting the

488
00:25:43.200 --> 00:25:46.240
<v Speaker 2>DSCP value in the IP header like a priority tag

489
00:25:46.640 --> 00:25:50.079
<v Speaker 2>sort of yeah. Then at congested points in the network,

490
00:25:50.359 --> 00:25:54.720
<v Speaker 2>routers use that marking to apply policies. This usually involves queuing,

491
00:25:54.880 --> 00:25:58.640
<v Speaker 2>putting different traffic types into different cueues. Voice goes in

492
00:25:58.680 --> 00:26:02.000
<v Speaker 2>a high priority low length and CQ bulk data might

493
00:26:02.039 --> 00:26:05.599
<v Speaker 2>go in a lower priority queue. Then scheduling mechanisms decide

494
00:26:05.640 --> 00:26:09.440
<v Speaker 2>which queue gets serviced next, ensuring the important traffic gets.

495
00:26:09.319 --> 00:26:13.160
<v Speaker 1>Through, so you guarantee performance for critical apps even when

496
00:26:13.200 --> 00:26:14.079
<v Speaker 1>the network is busy.

497
00:26:14.240 --> 00:26:17.640
<v Speaker 2>That's the objective. You might also use policing or shaping

498
00:26:17.680 --> 00:26:20.640
<v Speaker 2>to rate limit less important traffic. It's a whole discipline,

499
00:26:20.880 --> 00:26:22.920
<v Speaker 2>but essential for good user experience.

500
00:26:23.119 --> 00:26:26.279
<v Speaker 1>Right shifting gears. Now to the wide area network the

501
00:26:26.319 --> 00:26:29.880
<v Speaker 1>WAN connecting different sites maybe across the country or the globe.

502
00:26:30.200 --> 00:26:30.759
<v Speaker 1>What drives.

503
00:26:30.799 --> 00:26:34.920
<v Speaker 2>WAN design three main things, usually service level agreements SLAS

504
00:26:35.240 --> 00:26:38.759
<v Speaker 2>What performance and availability does the business need? Cost WAN

505
00:26:38.839 --> 00:26:42.400
<v Speaker 2>links can be expensive in usage. What applications need to

506
00:26:42.480 --> 00:26:44.519
<v Speaker 2>run over the WAN? The overall goal is always to

507
00:26:44.519 --> 00:26:48.000
<v Speaker 2>support the business meet application needs, stay secure and fit

508
00:26:48.039 --> 00:26:48.480
<v Speaker 2>the budget.

509
00:26:48.599 --> 00:26:51.000
<v Speaker 1>What are the traditional ways companies build WANs.

510
00:26:51.480 --> 00:26:55.519
<v Speaker 2>Historically you had options like dedicated lease lines, frame relay

511
00:26:55.640 --> 00:26:59.200
<v Speaker 2>ATM More commonly now you see layer two VPNs from

512
00:26:59.319 --> 00:27:03.160
<v Speaker 2>service provider, which can give you Ethernet like connectivity between sites,

513
00:27:03.160 --> 00:27:06.640
<v Speaker 2>but can be pricey. MPLS layer three VPNs are very

514
00:27:06.640 --> 00:27:11.880
<v Speaker 2>popular ympls, cost effective, scalable. The provider handles the complex

515
00:27:11.960 --> 00:27:15.960
<v Speaker 2>routing between sites using technologies like BGP and VRFs virtual

516
00:27:16.039 --> 00:27:20.160
<v Speaker 2>routing and forwarding instances to keep customer traffic separate. Plus

517
00:27:20.200 --> 00:27:23.799
<v Speaker 2>you can usually run QoS over mpls. Metro Ethernet is

518
00:27:23.839 --> 00:27:26.799
<v Speaker 2>also big for high speed connectivity within a city or region,

519
00:27:27.200 --> 00:27:30.200
<v Speaker 2>and some large enterprises might even use DWDM or at

520
00:27:30.240 --> 00:27:33.319
<v Speaker 2>least dark fiber for ultimate control and bandwidth, though that

521
00:27:33.359 --> 00:27:35.960
<v Speaker 2>requires designing external redundancy yourself.

522
00:27:36.119 --> 00:27:38.319
<v Speaker 1>And nowadays wireless is a bigger player.

523
00:27:38.000 --> 00:27:42.279
<v Speaker 2>Too, Definitely four G and increasingly five GLTE are becoming

524
00:27:42.359 --> 00:27:45.400
<v Speaker 2>viable not just as backup links, but sometimes as primary

525
00:27:45.440 --> 00:27:49.880
<v Speaker 2>WAN connectivity for smaller branches or retail locations, offering flexibility

526
00:27:49.920 --> 00:27:51.559
<v Speaker 2>and rapid deployment, Which brings us.

527
00:27:51.519 --> 00:27:54.519
<v Speaker 1>To the really big shift ST one Software defined one.

528
00:27:54.640 --> 00:27:56.440
<v Speaker 1>What's the hype? How does it change the game for

529
00:27:56.519 --> 00:27:57.319
<v Speaker 1>WAND designers?

530
00:27:57.640 --> 00:28:01.720
<v Speaker 2>SD one is genuinely transformative. It's an overlay architecture that

531
00:28:01.880 --> 00:28:07.079
<v Speaker 2>decouples the WAN services routing security policy from the underlying

532
00:28:07.079 --> 00:28:08.599
<v Speaker 2>physical transport links.

533
00:28:08.400 --> 00:28:12.039
<v Speaker 1>Meaning you can use any connection MPLS, Internet, broadband four

534
00:28:12.079 --> 00:28:13.160
<v Speaker 1>G exactly.

535
00:28:13.400 --> 00:28:17.200
<v Speaker 2>That's transport independence. Designers can mix and match links based

536
00:28:17.240 --> 00:28:21.759
<v Speaker 2>on cost, performance and reliability needs for different applications. SD

537
00:28:21.880 --> 00:28:26.119
<v Speaker 2>one provides centralized management and orchestration, zero touch provisioning for

538
00:28:26.200 --> 00:28:30.920
<v Speaker 2>new sites, integrated security features, and amazing visibility into application performance.

539
00:28:31.799 --> 00:28:34.880
<v Speaker 1>So instead of configuring each router individually.

540
00:28:34.319 --> 00:28:38.200
<v Speaker 2>You define policy centrally. Like salesforce, traffic prefers the MPLS

541
00:28:38.240 --> 00:28:41.279
<v Speaker 2>link but can fail over to broadband or guess Wi Fi.

542
00:28:41.279 --> 00:28:44.160
<v Speaker 2>Traffic goes direct to Internet, and the SD one controller

543
00:28:44.240 --> 00:28:47.559
<v Speaker 2>pushes that configuration out and manages the traffic flow automatically

544
00:28:47.599 --> 00:28:52.359
<v Speaker 2>across the entire fabric. It simplifies operations massively and optimizes performance.

545
00:28:53.279 --> 00:28:56.480
<v Speaker 1>How does this software defined approach actually work architecturally? What

546
00:28:56.519 --> 00:28:57.119
<v Speaker 1>are the pieces?

547
00:28:57.400 --> 00:29:01.799
<v Speaker 2>It's typically broken into logical planes. There's the orchestration plane

548
00:29:01.799 --> 00:29:06.319
<v Speaker 2>often called v bond and Cisco's Viptella solution, which authenticates

549
00:29:06.359 --> 00:29:08.680
<v Speaker 2>new SD one routers and tells them how to find

550
00:29:08.680 --> 00:29:09.240
<v Speaker 2>their controller.

551
00:29:09.279 --> 00:29:10.559
<v Speaker 1>Good onboarding part right.

552
00:29:11.200 --> 00:29:14.480
<v Speaker 2>Then the management plane vmanage is your single pane of

553
00:29:14.519 --> 00:29:20.160
<v Speaker 2>glass for configuration, monitoring, troubleshooting, analytics. The control plane V

554
00:29:20.279 --> 00:29:23.759
<v Speaker 2>smart is the brains. It learns the topology, distributes routing

555
00:29:23.799 --> 00:29:26.720
<v Speaker 2>and policy information between the SD one routers using a

556
00:29:26.759 --> 00:29:30.200
<v Speaker 2>protocol like OMP Overlay Management Protocol, so.

557
00:29:30.279 --> 00:29:32.640
<v Speaker 1>V smart tells everyone how to reach everyone else correct.

558
00:29:32.839 --> 00:29:35.200
<v Speaker 2>And finally, the data plane consists of the SD one

559
00:29:35.279 --> 00:29:39.680
<v Speaker 2>routers themselves vh or Cisco iOS S two one routers,

560
00:29:39.920 --> 00:29:43.279
<v Speaker 2>which actually builds secure tunnels between sites and ford user

561
00:29:43.319 --> 00:29:45.200
<v Speaker 2>traffic based on the decisions made by the.

562
00:29:45.160 --> 00:29:47.839
<v Speaker 1>V smart controller and bringing up new sites is easier.

563
00:29:47.519 --> 00:29:51.200
<v Speaker 2>Potentially much easier with zero touch provisioning ZTP. Ship a

564
00:29:51.240 --> 00:29:53.200
<v Speaker 2>router to a site, plug it in, It connects to

565
00:29:53.200 --> 00:29:56.039
<v Speaker 2>the orchestration plane, gets its configuration and joins the fabric

566
00:29:56.079 --> 00:29:58.279
<v Speaker 2>automatically huge time saver and.

567
00:29:58.279 --> 00:30:01.480
<v Speaker 1>With cloud adoption booming, what does SDWE fit in? Does

568
00:30:01.480 --> 00:30:03.880
<v Speaker 1>it help connect to AWS or Azure?

569
00:30:04.160 --> 00:30:08.880
<v Speaker 2>Absolutely? Most STWE solutions have specific cloud on ramp features.

570
00:30:09.279 --> 00:30:13.359
<v Speaker 2>These are designed to provide optimized, secure, and automated connectivity

571
00:30:13.640 --> 00:30:19.759
<v Speaker 2>directly into public cloud environments infrastructure as a service like AWS, Azure,

572
00:30:20.119 --> 00:30:21.160
<v Speaker 2>Google Cloud.

573
00:30:21.039 --> 00:30:23.039
<v Speaker 1>So extending the st one fabric into.

574
00:30:22.920 --> 00:30:26.880
<v Speaker 2>The cloud essentially yes, making the cloud, VPC or VNA

575
00:30:27.119 --> 00:30:30.000
<v Speaker 2>just another site on your when. They also often have

576
00:30:30.039 --> 00:30:33.559
<v Speaker 2>features to optimize performance for software as a service SAUCE

577
00:30:33.680 --> 00:30:37.640
<v Speaker 2>applications like Microsoft three sixty five or Salesforce. By intelligently

578
00:30:37.759 --> 00:30:41.279
<v Speaker 2>routing traffic directly to the closest SAUCE entry point, it

579
00:30:41.319 --> 00:30:45.160
<v Speaker 2>helps integrate the clouds seamlessly into the overall enterprise network design,

580
00:30:45.400 --> 00:30:48.240
<v Speaker 2>whether you're using public, private, or hybrid cloud models.

581
00:30:48.440 --> 00:30:51.440
<v Speaker 1>Okay, that covers a massive amount of ground on building networks. Yeah,

582
00:30:51.480 --> 00:30:53.519
<v Speaker 1>but the way we manage and interact with these networks

583
00:30:53.559 --> 00:30:56.720
<v Speaker 1>is changing rapidly to which leads to our final segment,

584
00:30:56.839 --> 00:31:00.559
<v Speaker 1>the future automation and programmability. We've definitely moved beyond just

585
00:31:00.599 --> 00:31:02.480
<v Speaker 1>typing commands into a CLI one by.

586
00:31:02.400 --> 00:31:05.480
<v Speaker 2>One right, oh massively. The shift towards automation is probably

587
00:31:05.519 --> 00:31:08.640
<v Speaker 2>the single biggest trend in network operations and design right now,

588
00:31:08.920 --> 00:31:11.960
<v Speaker 2>and it's all enabled by network APIs and new protocols

589
00:31:12.319 --> 00:31:13.319
<v Speaker 2>like rest APIs.

590
00:31:13.359 --> 00:31:15.079
<v Speaker 1>We hear about those everywhere right.

591
00:31:15.519 --> 00:31:21.839
<v Speaker 2>Rest representational state transfer using standard HTTP methods like get, post,

592
00:31:22.119 --> 00:31:26.400
<v Speaker 2>put delete. The cred operations provides a relatively simple, web

593
00:31:26.440 --> 00:31:30.519
<v Speaker 2>friendly way to interact with network devices programmatically. Many modern

594
00:31:30.599 --> 00:31:33.680
<v Speaker 2>devices offer rest APIs for configuration and monitoring.

595
00:31:33.839 --> 00:31:37.119
<v Speaker 1>But then there's netcom that sounds more network specific.

596
00:31:37.240 --> 00:31:41.400
<v Speaker 2>It is netcon Network Configuration Protocol is an IETF standard

597
00:31:41.400 --> 00:31:45.440
<v Speaker 2>specifically designed for network device management. It's more robust and

598
00:31:45.480 --> 00:31:49.319
<v Speaker 2>structured than just slinging CLI commands via SSH or using

599
00:31:49.359 --> 00:31:50.039
<v Speaker 2>basic REST.

600
00:31:50.200 --> 00:31:50.839
<v Speaker 1>How is it better?

601
00:31:50.960 --> 00:31:55.279
<v Speaker 2>It uses XML encoding over SSH, providing clear, standardized operations

602
00:31:55.319 --> 00:31:59.680
<v Speaker 2>like get config, edit, canfig commit. Crucially, it understands the

603
00:31:59.680 --> 00:32:02.680
<v Speaker 2>concept of different configuration data stores. The running canfig a

604
00:32:02.759 --> 00:32:05.759
<v Speaker 2>candidate config you can build and validate before applying, and

605
00:32:05.799 --> 00:32:10.160
<v Speaker 2>the startup CANFIG. This allows for more reliable transactional configuration changes.

606
00:32:10.279 --> 00:32:12.240
<v Speaker 2>You can make a bunch of changes, validate them, and

607
00:32:12.279 --> 00:32:13.839
<v Speaker 2>then commit them all at once, much.

608
00:32:13.640 --> 00:32:16.359
<v Speaker 1>Safer for automation, less chance of leaving a device half

609
00:32:16.400 --> 00:32:18.319
<v Speaker 1>configured exactly.

610
00:32:18.200 --> 00:32:21.119
<v Speaker 2>And restcon is basically a way to get rest like convenience,

611
00:32:21.480 --> 00:32:24.400
<v Speaker 2>but using the structured data models defined by YANG which

612
00:32:24.400 --> 00:32:27.640
<v Speaker 2>we'll get to and gRPC from Google is another option

613
00:32:28.000 --> 00:32:30.319
<v Speaker 2>often used for high performance streaming telemetry.

614
00:32:30.400 --> 00:32:33.480
<v Speaker 1>Okay, so those are the protocols for talking to the devices,

615
00:32:33.759 --> 00:32:36.599
<v Speaker 1>but the automation tools need a structured way to understand

616
00:32:36.640 --> 00:32:41.480
<v Speaker 1>the data itself, the configuration options, the status information precisely.

617
00:32:41.880 --> 00:32:44.759
<v Speaker 2>That's where data models and formats are key. The big

618
00:32:44.759 --> 00:32:48.400
<v Speaker 2>one here is YANG, yet another next generation. It's a

619
00:32:48.519 --> 00:32:49.640
<v Speaker 2>data modeling language.

620
00:32:49.680 --> 00:32:50.680
<v Speaker 1>So it defines the structure.

621
00:32:50.799 --> 00:32:53.799
<v Speaker 2>Yes, it defines the structure, syntax, and semantics of network

622
00:32:53.839 --> 00:32:56.759
<v Speaker 2>configuration and state data in a way that's independent of

623
00:32:56.839 --> 00:33:00.319
<v Speaker 2>any specific device, vendor or protocol. Think of it as

624
00:33:00.319 --> 00:33:03.359
<v Speaker 2>a standardized blueprint for what you can configure or monitor

625
00:33:03.400 --> 00:33:06.599
<v Speaker 2>on a device. Automation tools can read these young models

626
00:33:06.640 --> 00:33:09.119
<v Speaker 2>to understand exactly how to interact with the device via

627
00:33:09.200 --> 00:33:10.359
<v Speaker 2>netcon or rest coon.

628
00:33:10.599 --> 00:33:13.799
<v Speaker 1>And the actual data formats used Jason and XML.

629
00:33:13.720 --> 00:33:17.440
<v Speaker 2>Those are the main ones. JSON Jobscript Object notation is

630
00:33:17.640 --> 00:33:21.880
<v Speaker 2>very popular, lightweight, human readable, easy for machines to parse

631
00:33:22.119 --> 00:33:26.400
<v Speaker 2>often used with rest con XML extensible markup language is

632
00:33:26.519 --> 00:33:30.680
<v Speaker 2>more verbose but very structured. The standard format used by NETCN.

633
00:33:30.559 --> 00:33:33.480
<v Speaker 1>Got it, and this leads to something called model driven

634
00:33:33.519 --> 00:33:35.759
<v Speaker 1>te lemetry. Sounds futuristic.

635
00:33:35.839 --> 00:33:39.200
<v Speaker 2>It's the future of network monitoring happening now. Traditional monitoring

636
00:33:39.240 --> 00:33:42.279
<v Speaker 2>often uses S and m P polling. The NMS asks

637
00:33:42.319 --> 00:33:45.440
<v Speaker 2>the device for data every few minutes. Poll model model

638
00:33:45.480 --> 00:33:48.119
<v Speaker 2>driven to Lemontry flips that it's a push model. The

639
00:33:48.160 --> 00:33:52.119
<v Speaker 2>network device streams data continuously or whenever something changes to

640
00:33:52.200 --> 00:33:55.880
<v Speaker 2>subscribers like a monitoring system using those YANG models exactly.

641
00:33:55.920 --> 00:33:58.640
<v Speaker 2>It leverages standard YANG models to define what data to

642
00:33:58.720 --> 00:34:03.240
<v Speaker 2>stream and often uses efficient transports like gRPC or net conodifications.

643
00:34:03.480 --> 00:34:06.440
<v Speaker 2>You can subscribe to specific data points like interface counters,

644
00:34:06.559 --> 00:34:09.800
<v Speaker 2>CPU utilization, routing, neighbor states.

645
00:34:09.440 --> 00:34:11.079
<v Speaker 1>And get updates in near real time.

646
00:34:11.280 --> 00:34:15.119
<v Speaker 2>Potentially yes, you can configure periodic streaming every few seconds

647
00:34:15.239 --> 00:34:18.559
<v Speaker 2>or on change streaming only when a value changes. This

648
00:34:18.599 --> 00:34:21.960
<v Speaker 2>gives much more granular timely visibility into network health and

649
00:34:21.960 --> 00:34:26.719
<v Speaker 2>performance compared to slower polling cycles. It's fantastic for proactive troubleshooting,

650
00:34:26.880 --> 00:34:31.000
<v Speaker 2>capacity planning, and even feeding automation systems to react instantly

651
00:34:31.039 --> 00:34:31.880
<v Speaker 2>to network events.

652
00:34:32.320 --> 00:34:34.800
<v Speaker 1>Wow, that really changes the monitoring game.

653
00:34:34.880 --> 00:34:37.119
<v Speaker 2>It really does much more efficient and insightful.

654
00:34:37.159 --> 00:34:40.119
<v Speaker 1>Okay, incredible. We have covered so much ground from the

655
00:34:40.280 --> 00:34:44.400
<v Speaker 1>absolute basics of IP, addressing that journey from scarcity with

656
00:34:44.480 --> 00:34:49.159
<v Speaker 1>IPv four to the vastness of IPv six.

657
00:34:49.079 --> 00:34:51.679
<v Speaker 2>Right, and the design implications of that shift, through.

658
00:34:51.559 --> 00:34:55.239
<v Speaker 1>The intricate world of routing protocols, choosing between distance vector

659
00:34:55.320 --> 00:34:58.840
<v Speaker 1>link state, path vector, understanding metrics and ad all.

660
00:34:58.679 --> 00:35:01.599
<v Speaker 2>About guiding that traffic and in elligently and reliably.

661
00:35:01.239 --> 00:35:05.800
<v Speaker 1>To keeping watch with network management tools like SNNP, NetFlow, cyslog.

662
00:35:05.480 --> 00:35:07.159
<v Speaker 2>The essential eyes and ears.

663
00:35:07.280 --> 00:35:10.519
<v Speaker 1>Then diving deep into building resilient lands with hierarchical design

664
00:35:10.840 --> 00:35:14.480
<v Speaker 1>STP enhancements fhrps and the modern wan with mpls and

665
00:35:14.599 --> 00:35:16.400
<v Speaker 1>especially the rise of SD one.

666
00:35:16.239 --> 00:35:19.519
<v Speaker 2>And connecting that all seamlessly to the cloud.

667
00:35:19.599 --> 00:35:22.920
<v Speaker 1>And finally looking at the future with automation APIs like

668
00:35:23.000 --> 00:35:26.159
<v Speaker 1>net COF and rest cond data models like YANG, and

669
00:35:26.199 --> 00:35:29.559
<v Speaker 1>that real time view from model driven telemetry. You should

670
00:35:29.599 --> 00:35:32.719
<v Speaker 1>now have a much much deeper appreciation for all the

671
00:35:32.800 --> 00:35:35.880
<v Speaker 1>layers of thought and design that make our digital world function.

672
00:35:36.119 --> 00:35:39.599
<v Speaker 2>It's a constantly moving target too. The beauty of network

673
00:35:39.599 --> 00:35:42.559
<v Speaker 2>design is that it never stands still. Every single concept

674
00:35:42.599 --> 00:35:46.480
<v Speaker 2>we touched on is evolving, being refined. It keeps network

675
00:35:46.519 --> 00:35:48.320
<v Speaker 2>architects on their toes definitely.

676
00:35:48.800 --> 00:35:51.800
<v Speaker 1>We've seen how decades of problem solving shaped things, tackling

677
00:35:51.800 --> 00:35:55.880
<v Speaker 1>IPv for limits, building routing protocols moving towards this software

678
00:35:55.920 --> 00:36:00.000
<v Speaker 1>defined automated future. So as these technologies keep racing forward,

679
00:36:00.760 --> 00:36:04.480
<v Speaker 1>here's something to think about. We talked about core principles scalability,

680
00:36:04.639 --> 00:36:08.719
<v Speaker 1>high availability, security. How much further can these principles be pushed?

681
00:36:08.920 --> 00:36:13.199
<v Speaker 1>How might they be fundamentally redefined by the automation, the programmability,

682
00:36:13.280 --> 00:36:16.599
<v Speaker 1>the AI even that's starting to permeate network design. What

683
00:36:16.679 --> 00:36:20.199
<v Speaker 1>new challenges and what incredible new opportunities will emerge as

684
00:36:20.199 --> 00:36:22.920
<v Speaker 1>a network itself becomes even more intelligent and adaptable