WEBVTT

1
00:00:00.080 --> 00:00:04.440
<v Speaker 1>Okay, let's unpack this. In today's hyper connected world, our businesses,

2
00:00:04.559 --> 00:00:07.360
<v Speaker 1>our work, and pretty much our entire social fabric are

3
00:00:07.440 --> 00:00:11.439
<v Speaker 1>utterly reliant on one thing, the Internet. It's the invisible

4
00:00:11.519 --> 00:00:15.519
<v Speaker 1>super highway connecting everything. But what happens when that backbone

5
00:00:15.720 --> 00:00:18.679
<v Speaker 1>gets a little unpredictable, when traffic jams appear out of

6
00:00:18.679 --> 00:00:22.079
<v Speaker 1>nowhere or a critical exit closes down. How do we

7
00:00:22.160 --> 00:00:24.719
<v Speaker 1>even begin to figure out what's going on out there?

8
00:00:25.039 --> 00:00:28.519
<v Speaker 2>It's a massive challenge, isn't it. Companies today operate across

9
00:00:28.559 --> 00:00:33.119
<v Speaker 2>this incredibly vast, unregulated tapestry of independent networks, and that

10
00:00:33.240 --> 00:00:36.560
<v Speaker 2>lack of clear visibility creates immense risk for applications that

11
00:00:36.600 --> 00:00:40.039
<v Speaker 2>are absolutely critical to their operation. Today, we're taking a

12
00:00:40.039 --> 00:00:43.000
<v Speaker 2>deep dive into Cisco thousand Eyes, often affectionately called the

13
00:00:43.039 --> 00:00:45.719
<v Speaker 2>Google Maps for the Internet, to uncover how it brings

14
00:00:45.840 --> 00:00:49.159
<v Speaker 2>much needed clarity to that chaos and helps pinpoint issues

15
00:00:49.200 --> 00:00:51.359
<v Speaker 2>with well astonishing speed.

16
00:00:51.679 --> 00:00:54.520
<v Speaker 1>Exactly so, our mission today is to give you a

17
00:00:54.560 --> 00:00:58.000
<v Speaker 1>real shortcut to being well informed about how thousand Eyes

18
00:00:58.079 --> 00:01:03.840
<v Speaker 1>helps monitor, troubleshoot and truly optimized digital experiences. Get ready

19
00:01:03.880 --> 00:01:06.719
<v Speaker 1>for those aha moments that cut through the nors and

20
00:01:06.719 --> 00:01:09.959
<v Speaker 1>show you the hidden paths your data actually travels. Let's

21
00:01:10.000 --> 00:01:13.200
<v Speaker 1>rewind a bit though, to the genesis of all this picture.

22
00:01:13.239 --> 00:01:16.799
<v Speaker 1>The late two thousands, inside the UCLA Internet Research Lab,

23
00:01:17.439 --> 00:01:21.040
<v Speaker 1>two PhD students Moheite Lad and Ricardo Olivera made a

24
00:01:21.079 --> 00:01:24.200
<v Speaker 1>profound prediction. What was their big bet about the future

25
00:01:24.239 --> 00:01:26.439
<v Speaker 1>of the Internet and what problem did they see emerging?

26
00:01:27.000 --> 00:01:30.280
<v Speaker 2>Yeah, they had incredible foresight. Lad and Olivera saw a

27
00:01:30.319 --> 00:01:32.480
<v Speaker 2>future where the Internet wouldn't just be a way to connect,

28
00:01:32.719 --> 00:01:36.159
<v Speaker 2>it would become the de facto enterprise backbone. They envisioned

29
00:01:36.159 --> 00:01:40.079
<v Speaker 2>a world where every single transaction, every application, every employee communication,

30
00:01:40.400 --> 00:01:44.439
<v Speaker 2>every critical business function would rely entirely on this external network.

31
00:01:44.560 --> 00:01:45.000
<v Speaker 1>Wow.

32
00:01:45.200 --> 00:01:47.439
<v Speaker 2>The profound problem they identified was that if this prediction

33
00:01:47.519 --> 00:01:51.159
<v Speaker 2>came true, businesses would be relying on a vast external system,

34
00:01:51.280 --> 00:01:53.799
<v Speaker 2>a collection of independent networks they had no control over

35
00:01:54.319 --> 00:01:59.359
<v Speaker 2>and crucially no visibility into. It. Begged the question, Yeah,

36
00:01:59.439 --> 00:02:02.599
<v Speaker 2>how do you manage and fix something so vital yet

37
00:02:02.680 --> 00:02:03.959
<v Speaker 2>so completely opaque?

38
00:02:04.120 --> 00:02:06.400
<v Speaker 1>And that's where the famous Google Maps for the Internet

39
00:02:06.439 --> 00:02:10.080
<v Speaker 1>comparison really shines. I guess they realized businesses needed a

40
00:02:10.120 --> 00:02:14.039
<v Speaker 1>platform that could map every single handoff every segment of

41
00:02:14.080 --> 00:02:17.439
<v Speaker 1>the Internet from one service provider to the next, not

42
00:02:17.520 --> 00:02:21.120
<v Speaker 1>just your internal network, but the entire digital journey, allowing

43
00:02:21.159 --> 00:02:24.719
<v Speaker 1>you to understand exactly where performance issues or breaks in

44
00:02:24.759 --> 00:02:25.759
<v Speaker 1>the chain were occurring.

45
00:02:26.000 --> 00:02:27.919
<v Speaker 2>That's spot on. And you know, when we talk about

46
00:02:27.919 --> 00:02:31.280
<v Speaker 2>network performance, it often conjures up images of bandwidth. But

47
00:02:31.639 --> 00:02:35.240
<v Speaker 2>here's a critical insight. Most engineers are quite surprised when

48
00:02:35.280 --> 00:02:37.680
<v Speaker 2>we say there are only two network metrics that truly

49
00:02:37.719 --> 00:02:41.560
<v Speaker 2>impact TCP application performance back at loss and latency.

50
00:02:41.639 --> 00:02:42.120
<v Speaker 1>Only two.

51
00:02:42.439 --> 00:02:45.319
<v Speaker 2>Really, Yeah, if your application is slow and neither of

52
00:02:45.360 --> 00:02:48.400
<v Speaker 2>these has changed, then the network probably isn't the cultrit

53
00:02:49.240 --> 00:02:52.599
<v Speaker 2>For real time UDP applications like voice and video, jitter

54
00:02:52.680 --> 00:02:57.000
<v Speaker 2>is also crucial, of course, Okay, But bandwidth surprisingly only

55
00:02:57.039 --> 00:02:59.919
<v Speaker 2>matters when a lack of it causes loss or latency,

56
00:03:00.360 --> 00:03:03.639
<v Speaker 2>not as a primary measure of performance itself. It's not

57
00:03:03.680 --> 00:03:06.599
<v Speaker 2>about how wide the pipe is, but how smoothly data

58
00:03:06.639 --> 00:03:07.759
<v Speaker 2>flows through it, you know, And.

59
00:03:07.639 --> 00:03:09.879
<v Speaker 1>That latency it's not just one big number, is it.

60
00:03:10.000 --> 00:03:13.639
<v Speaker 2>Not at all? It's a sum of many tiny delays

61
00:03:13.680 --> 00:03:16.159
<v Speaker 2>along the path, from the time a packet gets put

62
00:03:16.199 --> 00:03:20.639
<v Speaker 2>on the wire serialization delay to waiting in line at

63
00:03:20.680 --> 00:03:24.319
<v Speaker 2>a router that's queuing delay think airport security, but the

64
00:03:24.439 --> 00:03:27.280
<v Speaker 2>pure distance it travels at lightspeed across fiber, which is

65
00:03:27.280 --> 00:03:30.639
<v Speaker 2>an instant and rarely straight distance delay plus forwarding delay,

66
00:03:30.759 --> 00:03:34.199
<v Speaker 2>even protocol delays. Thousand Eyes helps you pinpoint which of

67
00:03:34.240 --> 00:03:36.879
<v Speaker 2>these specific slowdowns is actually causing the problem.

68
00:03:37.360 --> 00:03:41.080
<v Speaker 1>Okay, So if the Internet is this vast, opaque system,

69
00:03:41.439 --> 00:03:44.240
<v Speaker 1>how do we actually get eyes on what's happening? What's

70
00:03:44.280 --> 00:03:47.439
<v Speaker 1>the core mechanism thousand Eyes uses to bring this digital

71
00:03:47.439 --> 00:03:48.199
<v Speaker 1>world into view.

72
00:03:48.479 --> 00:03:52.080
<v Speaker 2>Well, we deploy compact pieces of code, our agents as

73
00:03:52.080 --> 00:03:55.319
<v Speaker 2>your eyes and ears, your vantage points into this digital world.

74
00:03:55.599 --> 00:03:58.439
<v Speaker 2>We have three main types, each strategically placed for a

75
00:03:58.479 --> 00:04:02.800
<v Speaker 2>different perspective. Enterprise agents deployed inside your network, behind your.

76
00:04:02.680 --> 00:04:05.080
<v Speaker 1>Firewall okay, internal view exactly.

77
00:04:05.439 --> 00:04:08.879
<v Speaker 2>These give you crucial visibility into your internal infrastructure, your

78
00:04:08.960 --> 00:04:13.400
<v Speaker 2>data centers, your branch offices, even running on Cisco devices themselves.

79
00:04:13.960 --> 00:04:18.839
<v Speaker 2>Then to monitor everything external, your sauce applications, public cloud services,

80
00:04:18.839 --> 00:04:21.319
<v Speaker 2>and the Internet itself, seeing how your services look to

81
00:04:21.360 --> 00:04:22.319
<v Speaker 2>the rest of the world.

82
00:04:22.399 --> 00:04:25.319
<v Speaker 1>We use cloud agents, which thousandized managers.

83
00:04:25.079 --> 00:04:28.319
<v Speaker 2>Right, thousandnized manages those globally and for the ultimate user

84
00:04:28.319 --> 00:04:32.199
<v Speaker 2>centric view. Endpoint agents sit directly on your user's devices

85
00:04:32.279 --> 00:04:34.560
<v Speaker 2>like their laptops, Windows or mac.

86
00:04:34.360 --> 00:04:36.920
<v Speaker 1>Os ah, so right on the machine.

87
00:04:36.560 --> 00:04:40.519
<v Speaker 2>Itself, precisely capturing their actual experience from their machine, over

88
00:04:40.560 --> 00:04:43.199
<v Speaker 2>the local Wi Fi all the way to your applications.

89
00:04:43.439 --> 00:04:45.120
<v Speaker 2>It's at end to end user perspective.

90
00:04:45.480 --> 00:04:47.920
<v Speaker 1>That's a really comprehensive view. But what if you have

91
00:04:48.000 --> 00:04:52.120
<v Speaker 1>a massive organization or I don't know, a single agent

92
00:04:52.199 --> 00:04:56.439
<v Speaker 1>gets swamped with too many tests, you risk incomplete or

93
00:04:56.519 --> 00:04:57.759
<v Speaker 1>missed data. Right.

94
00:04:57.759 --> 00:05:00.920
<v Speaker 2>Absolutely, that's a really important point about skin ability, and

95
00:05:00.959 --> 00:05:03.920
<v Speaker 2>it's precisely why thousand eyes uses agent clusters.

96
00:05:04.000 --> 00:05:04.480
<v Speaker 1>Clusters.

97
00:05:04.560 --> 00:05:06.639
<v Speaker 2>Yeah, think of it like a team of agents working

98
00:05:06.720 --> 00:05:10.480
<v Speaker 2>together sharing the workload. You aggregate multiple agents into one

99
00:05:10.560 --> 00:05:14.040
<v Speaker 2>logical entity and they distribute the testing amongst themselves. This

100
00:05:14.160 --> 00:05:17.600
<v Speaker 2>ensures you're monitoring is always consistent and reliable, even during

101
00:05:17.639 --> 00:05:21.360
<v Speaker 2>traffic spikes, delivering a complete picture without any dropped insights

102
00:05:21.439 --> 00:05:22.319
<v Speaker 2>or skip test rounds.

103
00:05:22.399 --> 00:05:25.920
<v Speaker 1>Okay, that makes sense. So with all this visibility, what

104
00:05:25.920 --> 00:05:28.319
<v Speaker 1>does it mean for actually solving problems and getting to

105
00:05:28.399 --> 00:05:32.639
<v Speaker 1>those critical aha moments you mentioned? Thousand Eyes breaks down

106
00:05:32.680 --> 00:05:37.120
<v Speaker 1>monitoring into five key layers routing, network, DNS, web, and voice.

107
00:05:37.439 --> 00:05:39.600
<v Speaker 1>Let's dig into a few examples that really bring these

108
00:05:39.680 --> 00:05:40.600
<v Speaker 1>layers to life.

109
00:05:40.639 --> 00:05:43.759
<v Speaker 2>Sure, A crucial detail here is the ability to monitor

110
00:05:43.800 --> 00:05:47.439
<v Speaker 2>the Internet's literal directions. At the routing layer. Thousand Eyes

111
00:05:47.480 --> 00:05:50.800
<v Speaker 2>tracks BGP data, which is like the Internet's postal service.

112
00:05:50.839 --> 00:05:54.279
<v Speaker 2>You know. This lets you detect serious issues like BGP

113
00:05:54.439 --> 00:05:58.959
<v Speaker 2>root leaks akin to a mistake in sharing directions unintentionally

114
00:05:59.040 --> 00:06:03.800
<v Speaker 2>sending traffic where shouldn't go, or even worse, BGP route hijacking.

115
00:06:03.920 --> 00:06:06.240
<v Speaker 1>Hijacking that sounds bad, it is.

116
00:06:06.439 --> 00:06:09.959
<v Speaker 2>It's the unauthorized takeover of IP address blocks to divert traffic,

117
00:06:10.120 --> 00:06:13.959
<v Speaker 2>maybe maliciously. So it's about ensuring your traffic reaches its

118
00:06:13.959 --> 00:06:18.319
<v Speaker 2>intended destinations securely and along the intended path, and immediately

119
00:06:18.319 --> 00:06:20.920
<v Speaker 2>alerting you when those fundamental directions go awry.

120
00:06:21.120 --> 00:06:24.720
<v Speaker 1>Got it critical for security and just basic connectivity absolutely.

121
00:06:25.120 --> 00:06:27.360
<v Speaker 2>Then moving up to the weblayer, you can certainly do

122
00:06:27.439 --> 00:06:31.000
<v Speaker 2>basic HTTP server tests for simple availability and response time

123
00:06:31.120 --> 00:06:36.639
<v Speaker 2>standard stuff. But here's where it gets truly powerful. Pageload tests.

124
00:06:37.319 --> 00:06:39.839
<v Speaker 2>These simulate a real user visiting a website and give

125
00:06:39.839 --> 00:06:43.439
<v Speaker 2>you an incredibly detailed user centric perspective. And detailed you

126
00:06:43.480 --> 00:06:46.120
<v Speaker 2>get this amazing waterfall chart that visionally shows you the

127
00:06:46.160 --> 00:06:48.560
<v Speaker 2>sequence and timing of every single element loading on a

128
00:06:48.600 --> 00:06:51.439
<v Speaker 2>web page, images, scripts, CSS, everything.

129
00:06:51.480 --> 00:06:53.759
<v Speaker 1>Ah, so you see exactly what's slow exactly.

130
00:06:53.800 --> 00:06:56.560
<v Speaker 2>It's like seeing why a page feels slow, element by element,

131
00:06:56.759 --> 00:06:58.560
<v Speaker 2>not just getting a single load time number.

132
00:06:58.720 --> 00:07:02.279
<v Speaker 1>That sounds incredibly useful, But many user journeys aren't just

133
00:07:02.319 --> 00:07:05.399
<v Speaker 1>a single pageload, are they. What if a user's experience

134
00:07:05.480 --> 00:07:08.600
<v Speaker 1>involves multiple steps, like a checkout process.

135
00:07:08.920 --> 00:07:11.480
<v Speaker 2>You're right, that's a common scenario, and for that we

136
00:07:11.600 --> 00:07:15.319
<v Speaker 2>have transaction tests. Okay. These are scripted multi step user

137
00:07:15.360 --> 00:07:20.199
<v Speaker 2>interactions that simulate an entire user journey. Imagine loading Amazon,

138
00:07:20.319 --> 00:07:22.839
<v Speaker 2>searching for a product, adding it to a cart, and

139
00:07:22.879 --> 00:07:24.079
<v Speaker 2>then completing the checkout.

140
00:07:24.120 --> 00:07:26.759
<v Speaker 1>So you script the whole flow correct.

141
00:07:27.480 --> 00:07:31.240
<v Speaker 2>This allows you to pinpoint performance issues across an entire workflow,

142
00:07:31.319 --> 00:07:34.600
<v Speaker 2>not just a single page load. You can find bottlenecks

143
00:07:34.600 --> 00:07:37.759
<v Speaker 2>in complex, multi stage applications that you'd otherwise miss.

144
00:07:37.839 --> 00:07:41.360
<v Speaker 1>And for those critical collaboration tools and VoIP calls that

145
00:07:41.360 --> 00:07:44.199
<v Speaker 1>have become so essential to our daily work, I assume

146
00:07:44.240 --> 00:07:45.240
<v Speaker 1>there's something for that too.

147
00:07:45.519 --> 00:07:49.439
<v Speaker 2>Absolutely. The voice layer offers SIP server tests for call

148
00:07:49.439 --> 00:07:53.120
<v Speaker 2>initiation and authentication. That's the setup phase of any VoIP

149
00:07:53.279 --> 00:07:53.879
<v Speaker 2>call it can the.

150
00:07:53.879 --> 00:07:56.839
<v Speaker 1>Call even connect right, the handshake exactly, and.

151
00:07:56.800 --> 00:07:59.360
<v Speaker 2>Then the RTP stream tests focus on the actual audio

152
00:07:59.399 --> 00:08:01.839
<v Speaker 2>and video CUI quality of the call itself. These go

153
00:08:01.959 --> 00:08:05.839
<v Speaker 2>far beyond general network performance, looking at specific metrics like

154
00:08:06.360 --> 00:08:09.399
<v Speaker 2>mean Opinion score MOS, basically how good the call.

155
00:08:09.279 --> 00:08:11.759
<v Speaker 1>Sounds, AH, the MS score YEP.

156
00:08:11.920 --> 00:08:15.279
<v Speaker 2>Plus packet loss and jitter all directly relevant to voice

157
00:08:15.319 --> 00:08:17.920
<v Speaker 2>and video codex. It's how you know if your video

158
00:08:17.920 --> 00:08:20.279
<v Speaker 2>conference call sounds like you're talking through a tin can,

159
00:08:20.720 --> 00:08:24.480
<v Speaker 2>and precisely why instead of just guessing it's the network.

160
00:08:24.759 --> 00:08:27.639
<v Speaker 1>It's incredible how often we hear it's the network, even

161
00:08:27.680 --> 00:08:31.079
<v Speaker 1>when traditional monitoring tools seem to disagree. Let's talk about

162
00:08:31.120 --> 00:08:34.039
<v Speaker 1>some real world examples. Remember the customer who spent two

163
00:08:34.120 --> 00:08:38.080
<v Speaker 1>million dollars overhauling their hosting architecture, but still had problems

164
00:08:38.080 --> 00:08:41.720
<v Speaker 1>on NFL game days. Their existing monitoring wasn't telling the

165
00:08:41.720 --> 00:08:42.320
<v Speaker 1>whole story.

166
00:08:42.440 --> 00:08:44.720
<v Speaker 2>Oh yeah, that's a classic. And what I find particularly

167
00:08:44.759 --> 00:08:48.039
<v Speaker 2>compelling about that story is how easily critical issues can

168
00:08:48.120 --> 00:08:51.600
<v Speaker 2>hide in plain sight. The team was monitoring bandwidth utilization

169
00:08:51.799 --> 00:08:54.720
<v Speaker 2>with five minute averages, which looks sline often peaking around

170
00:08:54.720 --> 00:08:57.440
<v Speaker 2>say twenty thirty percent, perfectly normal. Right, it seems okay,

171
00:08:57.720 --> 00:09:02.200
<v Speaker 2>But what they missed with the outbound discards tiny bursty

172
00:09:02.240 --> 00:09:06.200
<v Speaker 2>moments were over half a million users simultaneously updated for

173
00:09:06.240 --> 00:09:08.399
<v Speaker 2>an NFL play microbursts.

174
00:09:08.559 --> 00:09:11.240
<v Speaker 1>Ah, the averages smoothed it out exactly.

175
00:09:11.519 --> 00:09:17.039
<v Speaker 2>These microbursts overloaded the network interfaces, dropping packets silently. It

176
00:09:17.080 --> 00:09:20.440
<v Speaker 2>wasn't about the pipes overall size, but its inability to

177
00:09:20.519 --> 00:09:23.080
<v Speaker 2>handle these sudden spikes in demand. It really makes you

178
00:09:23.120 --> 00:09:26.799
<v Speaker 2>wonder how many organizations are still flying blind to these

179
00:09:26.879 --> 00:09:31.240
<v Speaker 2>kinds of subtle, bursty issues that cause severe operational impact.

180
00:09:31.559 --> 00:09:32.639
<v Speaker 1>It's a scary thought.

181
00:09:33.399 --> 00:09:36.559
<v Speaker 2>The solution, once identified with the right visibility, was a

182
00:09:36.600 --> 00:09:41.480
<v Speaker 2>simple engineered delay to stagger user updates, drastically reducing discards.

183
00:09:42.000 --> 00:09:44.519
<v Speaker 2>Thousand Eyes would have instantly shown the packet loss and

184
00:09:44.559 --> 00:09:47.840
<v Speaker 2>the application impact, avoiding a multimillion dollar headache.

185
00:09:48.200 --> 00:09:50.679
<v Speaker 1>That story really highlights how easy it is to miss

186
00:09:50.720 --> 00:09:54.559
<v Speaker 1>critical issues with traditional monitoring. What's another common but often

187
00:09:54.600 --> 00:09:57.519
<v Speaker 1>misdiagnosed problem that thousand Eyes helps untangle.

188
00:09:57.559 --> 00:10:00.559
<v Speaker 2>Here's another fascinating one, A severity one incident where a

189
00:10:00.600 --> 00:10:05.120
<v Speaker 2>company's largest customers couldn't log into a critical application I priority. Obviously,

190
00:10:05.360 --> 00:10:08.799
<v Speaker 2>the load balancer appeared overloaded, yet it was accepting other

191
00:10:08.840 --> 00:10:13.279
<v Speaker 2>sessions from smaller customers, so confusing signals weird. The real

192
00:10:13.320 --> 00:10:17.519
<v Speaker 2>mystery deepened when they found one specific web server rejecting

193
00:10:17.559 --> 00:10:20.559
<v Speaker 2>new connections while all the others were performing fine.

194
00:10:20.720 --> 00:10:23.200
<v Speaker 1>Okay, so one bad server sort of.

195
00:10:23.519 --> 00:10:26.840
<v Speaker 2>The core issue was a combination of network address translation

196
00:10:27.320 --> 00:10:31.399
<v Speaker 2>NETP where many users appear as one single IP to

197
00:10:31.480 --> 00:10:36.080
<v Speaker 2>the outside world, and a specific Layer three load balancing algorithm.

198
00:10:36.279 --> 00:10:38.240
<v Speaker 1>How did those interact well?

199
00:10:38.639 --> 00:10:41.039
<v Speaker 2>Because the load balancer was using that single source IP

200
00:10:41.200 --> 00:10:45.039
<v Speaker 2>from the neat device to distribute traffic, all thousands of

201
00:10:45.120 --> 00:10:48.200
<v Speaker 2>users from one big customer who were all needed behind

202
00:10:48.240 --> 00:10:51.039
<v Speaker 2>that same single IP, were always routed to the same

203
00:10:51.080 --> 00:10:51.840
<v Speaker 2>back end server.

204
00:10:52.039 --> 00:10:55.279
<v Speaker 1>Oh so one server got hammered by the biggest customer.

205
00:10:55.360 --> 00:10:57.480
<v Speaker 2>So I see. It was like a single massive customer

206
00:10:57.480 --> 00:11:01.000
<v Speaker 2>group always hitting the same small checkout counter completely overwhelming

207
00:11:01.000 --> 00:11:02.200
<v Speaker 2>its TCP session.

208
00:11:01.919 --> 00:11:03.639
<v Speaker 1>Limit while the other counters were fine.

209
00:11:03.879 --> 00:11:07.080
<v Speaker 2>Exactly, thousand eyes by monitoring both the load balancer and

210
00:11:07.159 --> 00:11:10.879
<v Speaker 2>the individual servers would have shown connection failures specifically to

211
00:11:10.960 --> 00:11:15.360
<v Speaker 2>that particular server long before customer escalation. It guides the

212
00:11:15.399 --> 00:11:16.639
<v Speaker 2>team directly to the source.

213
00:11:16.879 --> 00:11:19.320
<v Speaker 1>Wow, that's such a subtle interaction. To track down. And

214
00:11:19.360 --> 00:11:23.720
<v Speaker 1>then there's the unforgettable Hurricane Katrina scenario. This one sounds dramatic.

215
00:11:23.840 --> 00:11:27.240
<v Speaker 2>It was users in Gulf coast states suddenly started receiving

216
00:11:27.279 --> 00:11:30.279
<v Speaker 2>a half page of HTML when trying to access a

217
00:11:30.320 --> 00:11:34.240
<v Speaker 2>critical fuel purchase system. Just half the page, half a page.

218
00:11:34.559 --> 00:11:39.039
<v Speaker 2>That's bizarre, totally bizarre, and users elsewhere were perfectly fine.

219
00:11:39.120 --> 00:11:42.000
<v Speaker 2>Everyone initially assumed it was the storm or just the

220
00:11:42.159 --> 00:11:43.519
<v Speaker 2>entire network collapsing down.

221
00:11:43.399 --> 00:11:44.720
<v Speaker 1>There understandable assumption.

222
00:11:45.120 --> 00:11:48.320
<v Speaker 2>Indeed, the initial trigger was a storm induced routing change,

223
00:11:48.360 --> 00:11:52.000
<v Speaker 2>forcing traffic through a tunnel. This tunnel crucially reduced the

224
00:11:52.000 --> 00:11:56.519
<v Speaker 2>maximum segment size MSS, essentially making the allowed packet size

225
00:11:56.559 --> 00:11:57.639
<v Speaker 2>smaller along that path.

226
00:11:57.799 --> 00:11:59.879
<v Speaker 1>Okay, so smaller packets allowed the.

227
00:12:00.080 --> 00:12:04.679
<v Speaker 2>Root costs a bug in an unpatched firewall. When pages

228
00:12:04.720 --> 00:12:07.559
<v Speaker 2>came through that were larger than this new smaller MSS,

229
00:12:07.799 --> 00:12:10.720
<v Speaker 2>the firewall would prematurely cut them off, setting an fe.

230
00:12:10.480 --> 00:12:13.480
<v Speaker 1>In packet like tearing a page and half midprint.

231
00:12:13.200 --> 00:12:16.600
<v Speaker 2>Exactly like that, so users got only half the HTML.

232
00:12:17.159 --> 00:12:19.919
<v Speaker 2>It makes you wonder how many subtle configuration mismatches or

233
00:12:19.960 --> 00:12:22.519
<v Speaker 2>bugs like that hide in our networks, only to be

234
00:12:22.600 --> 00:12:26.440
<v Speaker 2>exposed by a major event. Yeah, thousand ice path visualization

235
00:12:26.480 --> 00:12:30.080
<v Speaker 2>would clearly show the MTU or MSS issues and package

236
00:12:30.120 --> 00:12:33.840
<v Speaker 2>drops occurring at the firewall, turning weeks of painstaking packet

237
00:12:33.840 --> 00:12:38.240
<v Speaker 2>capture analysis into mere hours, a much faster resolution.

238
00:12:38.240 --> 00:12:43.120
<v Speaker 1>Just incredible granularity. Beyond these powerful tests and troubleshooting capabilities

239
00:12:43.159 --> 00:12:44.720
<v Speaker 1>you mentioned integrations, that's right.

240
00:12:45.039 --> 00:12:47.799
<v Speaker 2>Thousand nine seamlessly integrates with a whole host of platforms

241
00:12:47.879 --> 00:12:50.639
<v Speaker 2>you might already be using like service now for incident management,

242
00:12:51.000 --> 00:12:55.639
<v Speaker 2>WebEx for collaboration insights, app dynamics for application performance correlation,

243
00:12:55.759 --> 00:12:59.440
<v Speaker 2>connecting the dots exactly, creating a truly full stack observable

244
00:12:59.519 --> 00:13:02.559
<v Speaker 2>environment and from monitoring the health of your own physical

245
00:13:02.559 --> 00:13:07.639
<v Speaker 2>network devices. It leverages device monitoring with SNMP and protocols

246
00:13:07.679 --> 00:13:12.559
<v Speaker 2>like CDPLLVP to build a comprehensive network topology.

247
00:13:12.039 --> 00:13:15.440
<v Speaker 1>Map, so it sees the devices and the paths between them.

248
00:13:15.240 --> 00:13:19.080
<v Speaker 2>Precisely, giving you visibility not just into the paths, but

249
00:13:19.159 --> 00:13:22.840
<v Speaker 2>into your underlying infrastructure health as well. Ultimately, thousand nine

250
00:13:22.879 --> 00:13:27.120
<v Speaker 2>gives you unparalleled visibility and control over a digital landscape

251
00:13:27.159 --> 00:13:30.360
<v Speaker 2>that was once for many a black box. It shifts

252
00:13:30.399 --> 00:13:34.279
<v Speaker 2>troubleshooting from reactive guesswork you know, finger pointing.

253
00:13:34.000 --> 00:13:35.840
<v Speaker 1>Oh yeah, the war room finger pointing right.

254
00:13:36.000 --> 00:13:39.039
<v Speaker 2>A proactive data driven insight and that impacts everything from

255
00:13:39.440 --> 00:13:43.480
<v Speaker 2>operational efficiency and reducing meantime to resolution to protecting your

256
00:13:43.480 --> 00:13:47.120
<v Speaker 2>business revenue and brand reputation. It empowers teams to speak

257
00:13:47.120 --> 00:13:50.159
<v Speaker 2>a common language about performance backed by shared data.

258
00:13:50.240 --> 00:13:52.720
<v Speaker 1>You've now taken a deep dive into how Cisco thousand

259
00:13:52.799 --> 00:13:55.799
<v Speaker 1>nins acts as your compass and map, helping you navigate

260
00:13:55.840 --> 00:13:59.759
<v Speaker 1>the complex digital paths your services travel. It's a powerful

261
00:13:59.799 --> 00:14:02.519
<v Speaker 1>to for understanding not just what is happening, but why

262
00:14:02.600 --> 00:14:06.679
<v Speaker 1>it's happening and precisely where to fix it fast. It

263
00:14:06.720 --> 00:14:09.600
<v Speaker 1>seems like essentral visibility these days. So as you reflect

264
00:14:09.639 --> 00:14:13.440
<v Speaker 1>on this deep dive, consider this in an increasingly interconnected world,

265
00:14:13.759 --> 00:14:16.840
<v Speaker 1>where does your critical digital experience journey end and where

266
00:14:16.840 --> 00:14:20.159
<v Speaker 1>do your blind spots begin? What critical hidden issues could

267
00:14:20.159 --> 00:14:22.559
<v Speaker 1>you discover if you truly had a Google Maps for

268
00:14:22.600 --> 00:14:24.200
<v Speaker 1>the Internet for your own organization