Speaker 1: Okay, let's unpack this. In today's hyper connected world, our businesses,
Speaker 1: our work, and pretty much our entire social fabric are
Speaker 1: utterly reliant on one thing, the Internet. It's the invisible
Speaker 1: super highway connecting everything. But what happens when that backbone
Speaker 1: gets a little unpredictable, when traffic jams appear out of
Speaker 1: nowhere or a critical exit closes down. How do we
Speaker 1: even begin to figure out what's going on out there?
Speaker 2: It's a massive challenge, isn't it. Companies today operate across
Speaker 2: this incredibly vast, unregulated tapestry of independent networks, and that
Speaker 2: lack of clear visibility creates immense risk for applications that
Speaker 2: are absolutely critical to their operation. Today, we're taking a
Speaker 2: deep dive into Cisco thousand Eyes, often affectionately called the
Speaker 2: Google Maps for the Internet, to uncover how it brings
Speaker 2: much needed clarity to that chaos and helps pinpoint issues
Speaker 2: with well astonishing speed.
Speaker 1: Exactly so, our mission today is to give you a
Speaker 1: real shortcut to being well informed about how thousand Eyes
Speaker 1: helps monitor, troubleshoot and truly optimized digital experiences. Get ready
Speaker 1: for those aha moments that cut through the nors and
Speaker 1: show you the hidden paths your data actually travels. Let's
Speaker 1: rewind a bit though, to the genesis of all this picture.
Speaker 1: The late two thousands, inside the UCLA Internet Research Lab,
Speaker 1: two PhD students Moheite Lad and Ricardo Olivera made a
Speaker 1: profound prediction. What was their big bet about the future
Speaker 1: of the Internet and what problem did they see emerging?
Speaker 2: Yeah, they had incredible foresight. Lad and Olivera saw a
Speaker 2: future where the Internet wouldn't just be a way to connect,
Speaker 2: it would become the de facto enterprise backbone. They envisioned
Speaker 2: a world where every single transaction, every application, every employee communication,
Speaker 2: every critical business function would rely entirely on this external network.
Speaker 1: Wow.
Speaker 2: The profound problem they identified was that if this prediction
Speaker 2: came true, businesses would be relying on a vast external system,
Speaker 2: a collection of independent networks they had no control over
Speaker 2: and crucially no visibility into. It. Begged the question, Yeah,
Speaker 2: how do you manage and fix something so vital yet
Speaker 2: so completely opaque?
Speaker 1: And that's where the famous Google Maps for the Internet
Speaker 1: comparison really shines. I guess they realized businesses needed a
Speaker 1: platform that could map every single handoff every segment of
Speaker 1: the Internet from one service provider to the next, not
Speaker 1: just your internal network, but the entire digital journey, allowing
Speaker 1: you to understand exactly where performance issues or breaks in
Speaker 1: the chain were occurring.
Speaker 2: That's spot on. And you know, when we talk about
Speaker 2: network performance, it often conjures up images of bandwidth. But
Speaker 2: here's a critical insight. Most engineers are quite surprised when
Speaker 2: we say there are only two network metrics that truly
Speaker 2: impact TCP application performance back at loss and latency.
Speaker 1: Only two.
Speaker 2: Really, Yeah, if your application is slow and neither of
Speaker 2: these has changed, then the network probably isn't the cultrit
Speaker 2: For real time UDP applications like voice and video, jitter
Speaker 2: is also crucial, of course, Okay, But bandwidth surprisingly only
Speaker 2: matters when a lack of it causes loss or latency,
Speaker 2: not as a primary measure of performance itself. It's not
Speaker 2: about how wide the pipe is, but how smoothly data
Speaker 2: flows through it, you know, And.
Speaker 1: That latency it's not just one big number, is it.
Speaker 2: Not at all? It's a sum of many tiny delays
Speaker 2: along the path, from the time a packet gets put
Speaker 2: on the wire serialization delay to waiting in line at
Speaker 2: a router that's queuing delay think airport security, but the
Speaker 2: pure distance it travels at lightspeed across fiber, which is
Speaker 2: an instant and rarely straight distance delay plus forwarding delay,
Speaker 2: even protocol delays. Thousand Eyes helps you pinpoint which of
Speaker 2: these specific slowdowns is actually causing the problem.
Speaker 1: Okay, So if the Internet is this vast, opaque system,
Speaker 1: how do we actually get eyes on what's happening? What's
Speaker 1: the core mechanism thousand Eyes uses to bring this digital
Speaker 1: world into view.
Speaker 2: Well, we deploy compact pieces of code, our agents as
Speaker 2: your eyes and ears, your vantage points into this digital world.
Speaker 2: We have three main types, each strategically placed for a
Speaker 2: different perspective. Enterprise agents deployed inside your network, behind your.
Speaker 1: Firewall okay, internal view exactly.
Speaker 2: These give you crucial visibility into your internal infrastructure, your
Speaker 2: data centers, your branch offices, even running on Cisco devices themselves.
Speaker 2: Then to monitor everything external, your sauce applications, public cloud services,
Speaker 2: and the Internet itself, seeing how your services look to
Speaker 2: the rest of the world.
Speaker 1: We use cloud agents, which thousandized managers.
Speaker 2: Right, thousandnized manages those globally and for the ultimate user
Speaker 2: centric view. Endpoint agents sit directly on your user's devices
Speaker 2: like their laptops, Windows or mac.
Speaker 1: Os ah, so right on the machine.
Speaker 2: Itself, precisely capturing their actual experience from their machine, over
Speaker 2: the local Wi Fi all the way to your applications.
Speaker 2: It's at end to end user perspective.
Speaker 1: That's a really comprehensive view. But what if you have
Speaker 1: a massive organization or I don't know, a single agent
Speaker 1: gets swamped with too many tests, you risk incomplete or
Speaker 1: missed data. Right.
Speaker 2: Absolutely, that's a really important point about skin ability, and
Speaker 2: it's precisely why thousand eyes uses agent clusters.
Speaker 1: Clusters.
Speaker 2: Yeah, think of it like a team of agents working
Speaker 2: together sharing the workload. You aggregate multiple agents into one
Speaker 2: logical entity and they distribute the testing amongst themselves. This
Speaker 2: ensures you're monitoring is always consistent and reliable, even during
Speaker 2: traffic spikes, delivering a complete picture without any dropped insights
Speaker 2: or skip test rounds.
Speaker 1: Okay, that makes sense. So with all this visibility, what
Speaker 1: does it mean for actually solving problems and getting to
Speaker 1: those critical aha moments you mentioned? Thousand Eyes breaks down
Speaker 1: monitoring into five key layers routing, network, DNS, web, and voice.
Speaker 1: Let's dig into a few examples that really bring these
Speaker 1: layers to life.
Speaker 2: Sure, A crucial detail here is the ability to monitor
Speaker 2: the Internet's literal directions. At the routing layer. Thousand Eyes
Speaker 2: tracks BGP data, which is like the Internet's postal service.
Speaker 2: You know. This lets you detect serious issues like BGP
Speaker 2: root leaks akin to a mistake in sharing directions unintentionally
Speaker 2: sending traffic where shouldn't go, or even worse, BGP route hijacking.
Speaker 1: Hijacking that sounds bad, it is.
Speaker 2: It's the unauthorized takeover of IP address blocks to divert traffic,
Speaker 2: maybe maliciously. So it's about ensuring your traffic reaches its
Speaker 2: intended destinations securely and along the intended path, and immediately
Speaker 2: alerting you when those fundamental directions go awry.
Speaker 1: Got it critical for security and just basic connectivity absolutely.
Speaker 2: Then moving up to the weblayer, you can certainly do
Speaker 2: basic HTTP server tests for simple availability and response time
Speaker 2: standard stuff. But here's where it gets truly powerful. Pageload tests.
Speaker 2: These simulate a real user visiting a website and give
Speaker 2: you an incredibly detailed user centric perspective. And detailed you
Speaker 2: get this amazing waterfall chart that visionally shows you the
Speaker 2: sequence and timing of every single element loading on a
Speaker 2: web page, images, scripts, CSS, everything.
Speaker 1: Ah, so you see exactly what's slow exactly.
Speaker 2: It's like seeing why a page feels slow, element by element,
Speaker 2: not just getting a single load time number.
Speaker 1: That sounds incredibly useful, But many user journeys aren't just
Speaker 1: a single pageload, are they. What if a user's experience
Speaker 1: involves multiple steps, like a checkout process.
Speaker 2: You're right, that's a common scenario, and for that we
Speaker 2: have transaction tests. Okay. These are scripted multi step user
Speaker 2: interactions that simulate an entire user journey. Imagine loading Amazon,
Speaker 2: searching for a product, adding it to a cart, and
Speaker 2: then completing the checkout.
Speaker 1: So you script the whole flow correct.
Speaker 2: This allows you to pinpoint performance issues across an entire workflow,
Speaker 2: not just a single page load. You can find bottlenecks
Speaker 2: in complex, multi stage applications that you'd otherwise miss.
Speaker 1: And for those critical collaboration tools and VoIP calls that
Speaker 1: have become so essential to our daily work, I assume
Speaker 1: there's something for that too.
Speaker 2: Absolutely. The voice layer offers SIP server tests for call
Speaker 2: initiation and authentication. That's the setup phase of any VoIP
Speaker 2: call it can the.
Speaker 1: Call even connect right, the handshake exactly, and.
Speaker 2: Then the RTP stream tests focus on the actual audio
Speaker 2: and video CUI quality of the call itself. These go
Speaker 2: far beyond general network performance, looking at specific metrics like
Speaker 2: mean Opinion score MOS, basically how good the call.
Speaker 1: Sounds, AH, the MS score YEP.
Speaker 2: Plus packet loss and jitter all directly relevant to voice
Speaker 2: and video codex. It's how you know if your video
Speaker 2: conference call sounds like you're talking through a tin can,
Speaker 2: and precisely why instead of just guessing it's the network.
Speaker 1: It's incredible how often we hear it's the network, even
Speaker 1: when traditional monitoring tools seem to disagree. Let's talk about
Speaker 1: some real world examples. Remember the customer who spent two
Speaker 1: million dollars overhauling their hosting architecture, but still had problems
Speaker 1: on NFL game days. Their existing monitoring wasn't telling the
Speaker 1: whole story.
Speaker 2: Oh yeah, that's a classic. And what I find particularly
Speaker 2: compelling about that story is how easily critical issues can
Speaker 2: hide in plain sight. The team was monitoring bandwidth utilization
Speaker 2: with five minute averages, which looks sline often peaking around
Speaker 2: say twenty thirty percent, perfectly normal. Right, it seems okay,
Speaker 2: But what they missed with the outbound discards tiny bursty
Speaker 2: moments were over half a million users simultaneously updated for
Speaker 2: an NFL play microbursts.
Speaker 1: Ah, the averages smoothed it out exactly.
Speaker 2: These microbursts overloaded the network interfaces, dropping packets silently. It
Speaker 2: wasn't about the pipes overall size, but its inability to
Speaker 2: handle these sudden spikes in demand. It really makes you
Speaker 2: wonder how many organizations are still flying blind to these
Speaker 2: kinds of subtle, bursty issues that cause severe operational impact.
Speaker 1: It's a scary thought.
Speaker 2: The solution, once identified with the right visibility, was a
Speaker 2: simple engineered delay to stagger user updates, drastically reducing discards.
Speaker 2: Thousand Eyes would have instantly shown the packet loss and
Speaker 2: the application impact, avoiding a multimillion dollar headache.
Speaker 1: That story really highlights how easy it is to miss
Speaker 1: critical issues with traditional monitoring. What's another common but often
Speaker 1: misdiagnosed problem that thousand Eyes helps untangle.
Speaker 2: Here's another fascinating one, A severity one incident where a
Speaker 2: company's largest customers couldn't log into a critical application I priority. Obviously,
Speaker 2: the load balancer appeared overloaded, yet it was accepting other
Speaker 2: sessions from smaller customers, so confusing signals weird. The real
Speaker 2: mystery deepened when they found one specific web server rejecting
Speaker 2: new connections while all the others were performing fine.
Speaker 1: Okay, so one bad server sort of.
Speaker 2: The core issue was a combination of network address translation
Speaker 2: NETP where many users appear as one single IP to
Speaker 2: the outside world, and a specific Layer three load balancing algorithm.
Speaker 1: How did those interact well?
Speaker 2: Because the load balancer was using that single source IP
Speaker 2: from the neat device to distribute traffic, all thousands of
Speaker 2: users from one big customer who were all needed behind
Speaker 2: that same single IP, were always routed to the same
Speaker 2: back end server.
Speaker 1: Oh so one server got hammered by the biggest customer.
Speaker 2: So I see. It was like a single massive customer
Speaker 2: group always hitting the same small checkout counter completely overwhelming
Speaker 2: its TCP session.
Speaker 1: Limit while the other counters were fine.
Speaker 2: Exactly, thousand eyes by monitoring both the load balancer and
Speaker 2: the individual servers would have shown connection failures specifically to
Speaker 2: that particular server long before customer escalation. It guides the
Speaker 2: team directly to the source.
Speaker 1: Wow, that's such a subtle interaction. To track down. And
Speaker 1: then there's the unforgettable Hurricane Katrina scenario. This one sounds dramatic.
Speaker 2: It was users in Gulf coast states suddenly started receiving
Speaker 2: a half page of HTML when trying to access a
Speaker 2: critical fuel purchase system. Just half the page, half a page.
Speaker 2: That's bizarre, totally bizarre, and users elsewhere were perfectly fine.
Speaker 2: Everyone initially assumed it was the storm or just the
Speaker 2: entire network collapsing down.
Speaker 1: There understandable assumption.
Speaker 2: Indeed, the initial trigger was a storm induced routing change,
Speaker 2: forcing traffic through a tunnel. This tunnel crucially reduced the
Speaker 2: maximum segment size MSS, essentially making the allowed packet size
Speaker 2: smaller along that path.
Speaker 1: Okay, so smaller packets allowed the.
Speaker 2: Root costs a bug in an unpatched firewall. When pages
Speaker 2: came through that were larger than this new smaller MSS,
Speaker 2: the firewall would prematurely cut them off, setting an fe.
Speaker 1: In packet like tearing a page and half midprint.
Speaker 2: Exactly like that, so users got only half the HTML.
Speaker 2: It makes you wonder how many subtle configuration mismatches or
Speaker 2: bugs like that hide in our networks, only to be
Speaker 2: exposed by a major event. Yeah, thousand ice path visualization
Speaker 2: would clearly show the MTU or MSS issues and package
Speaker 2: drops occurring at the firewall, turning weeks of painstaking packet
Speaker 2: capture analysis into mere hours, a much faster resolution.
Speaker 1: Just incredible granularity. Beyond these powerful tests and troubleshooting capabilities
Speaker 1: you mentioned integrations, that's right.
Speaker 2: Thousand nine seamlessly integrates with a whole host of platforms
Speaker 2: you might already be using like service now for incident management,
Speaker 2: WebEx for collaboration insights, app dynamics for application performance correlation,
Speaker 2: connecting the dots exactly, creating a truly full stack observable
Speaker 2: environment and from monitoring the health of your own physical
Speaker 2: network devices. It leverages device monitoring with SNMP and protocols
Speaker 2: like CDPLLVP to build a comprehensive network topology.
Speaker 1: Map, so it sees the devices and the paths between them.
Speaker 2: Precisely, giving you visibility not just into the paths, but
Speaker 2: into your underlying infrastructure health as well. Ultimately, thousand nine
Speaker 2: gives you unparalleled visibility and control over a digital landscape
Speaker 2: that was once for many a black box. It shifts
Speaker 2: troubleshooting from reactive guesswork you know, finger pointing.
Speaker 1: Oh yeah, the war room finger pointing right.
Speaker 2: A proactive data driven insight and that impacts everything from
Speaker 2: operational efficiency and reducing meantime to resolution to protecting your
Speaker 2: business revenue and brand reputation. It empowers teams to speak
Speaker 2: a common language about performance backed by shared data.
Speaker 1: You've now taken a deep dive into how Cisco thousand
Speaker 1: nins acts as your compass and map, helping you navigate
Speaker 1: the complex digital paths your services travel. It's a powerful
Speaker 1: to for understanding not just what is happening, but why
Speaker 1: it's happening and precisely where to fix it fast. It
Speaker 1: seems like essentral visibility these days. So as you reflect
Speaker 1: on this deep dive, consider this in an increasingly interconnected world,
Speaker 1: where does your critical digital experience journey end and where
Speaker 1: do your blind spots begin? What critical hidden issues could
Speaker 1: you discover if you truly had a Google Maps for
Speaker 1: the Internet for your own organization