Describe ThousandEyes Platform Architecture

0:00Well, as we mentioned previously, we are going to configure tests, and these tests are going to leverage the agents that we specify, whether those are endpoint agents or enterprise or cloud agents. And this is going to produce a whole lot of information. So we're collecting a bunch of data, and that data gets placed into the thousandized platform for tracking. And we are going to be able to go and look at this data ourselves so we can pull up our views and click through there, we can pull up our dashboards.

0:36And from here we can go out and see when there might be some issues. Now that's great and all except as we pointed out, we might want to get pro actively notified. Let's say there's a big issue that happens. And I don't want to have to wait for me or somebody on my team to go out and check out a view or check out a dashboard in order to see that an issue has occurred. We would hope that we can use this data to create notifications. And there are two ways to create notifications, alerts and events.

1:09Primarily we are going to be using alerts, which is what we're going to start out talking about here. So an alert is going to create this type of notification. And the idea here is that it's something that we know we want to know. What we're saying essentially is that I know I want to know something specific about an environment. So for example, maybe I want to say that a particular site has a round trip time of 100 milliseconds.

1:44So I'm going to make sure that it always stays below 100 milliseconds as soon as this resource, maybe it's a website, maybe it's a node on my network, but either way, as soon as the threshold drops before 100 milliseconds, I might want to know about that. And so alerts are explicitly configured. This is why I need to know exactly what I want to know. Now the reason I'm pointing out that this is something that I know I want to know is because there might just be issues on the network and I didn't know that I would care about that.

2:19And hopefully events are going to catch that for us. Events are configured automatically and they will just alert us when something goes south, as we like to say, as something has gone wrong and event is supposed to tell us with that. So I lay that foundation as we talk about alerts to really emphasize that alerts are things that I know that this is going to be a problem if a particular metric is met or maybe not met. And so I need to know when that occurs. So we can go out and we can configure these alerts and we can probably assume that as we continue to use the Thousand Eyes platform, that we're going to have more and more alerts that we configure in the environment.

2:58So again, alerts are going to create notifications and we have three different types of notifications that we're going to be able to take advantage of here. These notifications are emails, which are going to be a primary point of notification for us. We can also take advantage of webhooks. And specifically when Thousand Eyes takes advantage of a webhook, meaning that it's just going to use HTTP messaging, probably communicating with a web server on some level, we are going to be processing this via JSON.

3:33So we're going to wrap our notification up in JSON encoding, format that and send it off. And make sure we're expecting to receive JSON information and be able to interpret what exactly we're sending. And then we also have other integrations. So those integrations might be app dynamics. Cisco has made another acquisition called app dynamics. This is something that ties into our development of applications.

4:04So we might take advantage of that. But then we might take advantage of another alerting mechanism. Specifically, we think about applications such as pager duty and service now, both of which support integrations and a lot of help desks rely on these types of applications. And for that matter, we can actually integrate into Slack. So at the time of this video, these are the four main integrations that are available. I would expect that maybe over time, Cisco adds more integrations into Thousand Eyes.

4:37But these are the primary ways that we're going to go about creating these notifications. Now one thing that probably immediately jumps out at us is the concept of texting and the fact that it is missing. So why is there no texting option? And oftentimes we refer to texting as SMS notifications. Well, there are two primary reasons for this or maybe I should say two different workarounds that we have. And since we have workarounds, we haven't created native texting from Thousand Eyes, again, at the time of this video.

5:09The first reason is that there are some of these applications down here that will support texting. And so for using an existing service type of application, we probably have the capability of texting individuals on an as needed basis. But the other option here is simply to take advantage of emails. Most of our mobile providers or mobile service providers or mobile SPs will support an email address that basically converts the email into a texting to a phone number.

5:42So what we might find is that it's the phone number one, two, three, four, five , six, however long our phone number is. And then we put the @ sign and then whatever the mobile service provider has as a domain that will allow us to send a text. So I know that pretty much every mobile service provider I've ever used has had this as an option. It's one that we don't take advantage of too often in our day to day lives. But something like this would be perfect for this. I can send myself an email to my phone number at whatever domain my service provider supports.

6:15And as soon as Thousand Eyes sends that email, I will get a text on my phone. So we can absolutely take advantage of texting via one of these two mechanisms, which is why we don't see a native texting option listed here in our notifications. So from here, we might want to at least talk about the concept of quieting our alerts. How do we go about quieting alerts when they come in? Because we might actually have a couple of situations come up.

6:46For example, I might be about to perform network maintenance. And so if I have network maintenance that's about to pop up, I probably want to make sure that I'm not notifying everybody that a particular network resource has gone down. I know it's going down. We all know it's going down. And so that might be a situation. We might also have a known issue. If we have a known issue on the network, I don't need Thousand Eyes constantly telling me that this issue exists. Maybe I'm trying to fix it or maybe it's not fixable and we're waiting for hardware to show up.

7:20It's going to be four hours or it's going to be two days before we can actually fix this issue. So there's reasons for us to disable alerts, even though I configured the alerts myself. I don't necessarily want to go in and say, all right, let's just delete this alert because once these scenarios have passed, I probably want to return to the system creating alerts for these scenarios. So what do we do? Well, we've got two options for this. We have the concept of alert suppression and alert suppression is a proactive concept.

7:56This is going to apply to the scheduled maintenance window concept. So if I know that tonight at midnight, I'm going to be resetting a bunch of network switches. I could probably get into Thousand Eyes configuration, find the appropriate alerts and suppress those alerts for the next several hours, knowing that I'm going to reset these devices. And then after a few hours have passed, that suppression can end and we can go back to alerting if those systems go down. The other option we have is the snooze.

8:27So think about hitting the snooze after the alarm has gone off in the morning. Maybe we've all been guilty of doing that a number of times in our lives. Maybe it's something we do every week. But either way, this is reactive, the alarm has already gone off. I'm not trying to prevent the alarm from going off. I'm trying to say, I know about this issue. Please tell me about it again in the future. And so that would be that scenario where I know that this issue is going to persist for a little while. So that's an overview of alerts.

8:58And again, as mentioned at the start here, alerting is when I know what I want to know. What about when I don't know what I want to know? Maybe there is a scenario where I'm not actually monitoring a particular link or a particular device, but the fact that this went down means that we have an outage. And because I don't actually have an alert, we might say, well, this is no good . Do I really have to manually configure every single alert for every single scenario so that I'm aware when something happens on my network?

9:29And the answer, fortunately, is no. We don't have to worry about that specifically. Plus, Thousand Eyes has a backup plan of sorts. This is known as the event. So when we're talking about events, there is not going to be any configuration involved. I don't need to worry about creating event configuration because ultimately, we 're not actually defining what it is that we want to be alerted on. Say, well, how can we then be alerted on it? Well, essentially what we're doing is we are running a baseline evaluation or status quo evaluation.

10:06I understand as the Thousand Eyes platform, Thousand Eyes itself is looking at this scenario and recognizing that normally this device is online. Now, a device going down is a little bit of an extreme example. Maybe it's more like we're used to seeing a 1% packet loss on this link. And now all of a sudden we have a 10% loss. Well, this is what's known as an anomaly. So an anomaly or anomaly detection when it comes to network assurance is saying that I know what's normal on my network.

10:41I've evaluated this network long enough to know what a normal amount of loss or latency looks like. Maybe I know about how long it normally takes for me to do a page load or something like that. And so I've established a baseline. Again, I know what's normal. And all of a sudden, there's an anomaly. So at this point, this can trigger an event. Now an event has exactly one notification option at this point in time.

11:13And that would be an email. So we don't have all of the same integrations. We can't use web hooks. But fortunately, we can not only send emails, but we can also send text alerts based on this type of event. Now there are a couple more details about events to be aware of. And this is just more information. We're just going to have to remember or memorize. But ultimately, events are going to assign an impact level. And this impact level is actually going to be based on our agent count.

11:45So let's just say the number of agents that are experiencing this particular issue. Now maybe we've got a bunch of agents, only half of them are seeing an issue. Well, that's still actually a lot. A lot of our agents are experiencing an issue, but maybe it's 1% of our agents or 5% of our agents. So based on that, we're going to assign either a low, medium, or high level of impact.

12:16Furthermore, we are going to see that there are five different types of events. These five different types are going to be a local network type where we're evaluating our own local network, a network outage, where something is actually experiencing an outage on the network. We also have a generic network type of event. And yes, we will see these in more detail later on. This is just for us to know what these different types are. We can also have a proxy issue and a server issue.

12:53So these are the five different types that we can expect to see. And once again, only email notifications are available for events. So one of our primary takeaways here should be making sure that we fully understand the difference between alerts and events, where events are based a little bit more on establishing a baseline and detecting anomalies. And fortunately, there's nothing I need to do to configure events and make sure that they happen. Now the focus of our conversation really ultimately is on alerts because we're going to spend a lot of time creating alerts in our environment, not just for practice for the exam, but in the real world production, thousandized deployments.

13:32Alerts are absolutely huge. They're a major part of this because again, we're collecting all of this data and it's great that I can see that data, but I need to create the notifications when there's a major issue. And so I define those thresholds myself. I create the different alert types and I get notified in whichever way I so choose based on the options available.

0:00When it comes to creating thousandize configuration, we have to manage a whole lot of things that we create in the configuration, especially a large number of endpoints and a large number of tests. So Cisco and Thousandize, they wanted to make it so that we could more easily manage all of these endpoints and tests. Because if we think about it, we might truly have tens of thousands of end points in our environment.

0:30If we're smaller infrastructure, smaller organization, then we probably won't have that many, but we could have tens of thousands, we could even go well above and beyond that for the right size organization. And even our tests here, we're probably going to have dozens, if not hundreds of different tests. And so how can we filter through all of these? Well this is the concept of the label. A label is truly an arbitrary designation. What I mean by that is that I'm going to assign a color to a label, I'm going to apply a name to a label, and the significance of the label is defined by, well, me, the person who is configuring this.

1:15So by the configurator, I'll just say the admin of this configured infrastructure. So basically, if I decide that a blue label named special gets to apply to a specific set of endpoints, maybe endpoints, 1, 100 and 10,322. These are my three favorite endpoints in the entire organization.

1:45I can create a label and put it on those three endpoints. And then at that point, I can maybe filter my endpoint list or otherwise apply tests just to that label. Now this is especially arbitrary. It doesn't actually provide much value. I guess I flagged my favorite endpoints. But maybe more likely what we'll do is we will flag different endpoints that have similar properties. So maybe these three are our executives in the organization.

2:18If there are executives, then we're going to care a whole lot about those user experiences because as soon as they hit problems with their user experience, we're all going to have to jump to fix it very, very quickly. That's just the way it works. So when we're looking at our different labels, there are two types of labels. We have endpoint labels. And we have labels for testing. So test labels. Now when we're talking about endpoint labels, this is pretty practical because what we might do is we might create a test.

2:56And for my test, what I want to do is I want to take a set of endpoints. And we're talking about ultimately endpoint agents. And I want to make a test that goes out to a particular website. So again, maybe I want to target these specific executives and I want to have a constant test to see how they are doing. So I can use my special label. I can say, all right, I want to apply this specific test. We're going to call it exec_experience.

3:27exp. And so that's the name of the test. And now I'm going to apply it to my label special. I'll just call it spec here. So at this point, that test is going to get applied to those agents. And I'm going to be able to look at the views and set up alarms or alerts rather. That are going to tell me what's happening with that group of endpoints. So that's the purpose of the endpoint labels. It's pretty practical. It allows us to apply tests to specific agents.

3:58When it comes to the test labels, this is a little bit more for ease of management, especially when it comes to filters. Because we might truly, again, have hundreds of tests configured. And so if I want to maybe just keep track of a specific set of tests, I can go through and maybe I can tag three of these tests or four of these tests as red, a red label. And so then I can go to my list of tests. It lists hundreds of tests.

4:30And I simply filter by the red label. And now I see the four tests that I care the most about. So these are the primary types of labels that we're going to see in our thousandized configuration. In fact, it probably makes it a little bit more clear if we just look at a demonstration. So let's flip over to our thousandized interface. And we're going to start by taking a look at our endpoint agents. So we're going to open up our endpoint agents option over here on the left. We're going to go to agent settings. And then up at the top, we see actually a bunch of tabs.

5:04So right here in the middle is this agent labels tab. We're going to click this. And now we see that I already have a label in here called CBT test. But let's go and ignore that. I'm just going to add a new label. By the way, you might notice that any time we're going to create a new anything in thousand ized that usually there's a blue button. I say usually, but really always there's a blue button. So if we ever just need to find how to create something, just sort of keep in mind there should be a blue button somewhere that allows me to create it.

5:35In this case, a new label. So I'm going to click the add new label creates this wonderful pop out. I can create whatever label I want. So let's just do a head or go ahead and to what I said before, we're going to call the label name special. I already used the color blue for a label. So let's just use purple this time. Use whatever of these colors that I want. And now what I want to do is figure out which agents and specifically which end points to give this label to. Now I could go to the trouble of just trying to find all of the endpoint agents which will show up down here.

6:13Now it's a little bit tricky because I only have a single endpoint in this lab environment. And so there's only one that shows up down here. But what's going to happen is this is going to list all of the agents that match this criteria up here. So long story short, let's do this. If I say filter all of these conditions. So first of all, I can create multiple filter conditions. So keep that in mind. Second, let's just go ahead and look at our options here. So we could stick with location. We could take a look at the agent or agent type.

6:45You can look at our gateways, VPNs, SSIDs. Maybe we would just want to target any agent or any endpoint that is connecting via a specific wireless SSID. We can search by IP addresses, host names, all kinds of things. Again, all I'm really looking for at this point is to create a batch of agents that can apply the label to. So if I say location is in and let's just say United here to find the United States, which is where this desktop of mine is.

7:20So I'll just check the United States box. And now we see that we have 361 locations selected and my agent, well, yeah, my endpoint agent does match this. Now notice this, if I use the dropdown, I say it's not in the United States at this point, notice that it goes away. So this is what we'd expect is we have hundreds of endpoints, then we're going to find different amounts of endpoints. And again, it's calling them agents here because we're talking about the endpoint agents, but a different amount of agents will show up based on our filter.

7:54So I might say it's in the United States, but then I could add another filter here and say that, I don't know, again, the SSID is going to match a specific, we're using a specific SSID. So that's the concept of adding a bunch of filters. And then again, using this dropdown, I can say any of these apply or all of these apply. So it's sort of that logical and or conversation. So do I want this and let's add another couple.

8:25So is it this and this and this or is it this or this or this? And again, ultimately, we see the results down here that we have all of the agents that are going to show up that get this label. So I'm just going to hit save changes. The ultimate result here is that the endpoint in question is going to be given the label that I give it. And so if I go back to my endpoint agents and I click on this, we're going to find the current label is CBT test.

8:58So let's go back and find out. Did it actually apply? Okay. Yeah, it did apply. So it just hasn't updated. This does actually sometimes take a moment to update. Let's go off of agent settings, go back to agent settings, go to agent label, no, click on this. Oh, it still says current labels. Well this one is not updating, but we can see from the other view, if I come over to agent labels, click on one of these and it shows that the desktop is part of this specific label.

9:30And we can see down here that we actually have both of those labels applied. So just every now and again, it takes a little bit to update, no worries. And we can click on any one of these labels to see all of the agents that are being matched to that specific label. So now what we can do is if we come over to test settings, I can first of all see that I can create some test labels. So I could create a label here, again blue button, test two, grab a green, let 's grab an orange label, and then I can apply this to any number of tests.

10:07So let's say I want it to apply to Google suite meet. So we're tracking Google meet, and then I go back to tests. So here's my list of tests. Again I've got four in my test environment. We might have hundreds here. I can say add filter agent labels, not agent labels, test labels. There we go. And I can grab again, it hasn't updated. So this is why I say it does take a little bit sometimes to update, try to be gracious and patient.

10:40Let's try this again, test labels, there it is. So now I apply my test label here. And even this is a little bit out of sync. So, yeah, this got backwards. Oh well, it's applied here and we see that it's the only test. So this is where if I have hundreds of these and I want to look for a specific set of tests, I can filter by a label. Now lastly, let's just say that I want to, let's just say create a test here.

11:14All right. So when I come to agents, I can say specific agents, and then I can add, actually let's see here, agent labels, there we go. And now I can specify which label I want. So whatever domain I'm going to track and monitor, I can apply the set of labels here. So I can say the CBT test label. And then it's going to get applied to all of the agents that have that specific label. So this is how labels can make our lives easier.

11:46This is something that as we get practice with, we're going to see more and more how useful they are for again, management of the system, just filtering out different tests when we have a bunch of tests there, but also applying a test to a group of agents via these labels can be very useful to us as well.

0:00As we delve deeper into the conversations around network assurance, we're going to need to understand that there is a difference between what we call active monitoring and passive monitoring. And the good news is that both have a place in the modern network. We just need to understand the difference as much as anything because Cisco wants us to know this. It's on the exam blueprint. But we're also going to need to know and understand these concepts as we look at applying different thousandized tests into our environment. So what is the difference between active monitoring and passive monitoring?

0:35Well, as the name implies, we're going to see a little bit more involvement on the active monitoring side, but it doesn't necessarily make it better. So let's just set some groundwork here as far as what the difference is. When we're talking about active monitoring, what we're saying is that we are generating traffic. And that's usually the biggest flag to tell whether this is an active monitoring type of situation or not. But ultimately what we're doing is we are allowing some form of an outside influence onto the network.

1:13In other words, the question we might ask is what happens if I were to not actually apply or maybe I should say, if I were to apply this monitoring to a network and compare it to what the network traffic looks like. If I'm not actually monitoring, is the situation the exact same? If I'm generating traffic as part of my monitoring, then the scenario where I'm monitoring is going to look different from the scenario where I'm not monitoring because there's going to be traffic here that wouldn't be there if I wasn't monitoring versus passive monitoring, which says that there is no outside influence on the network.

1:51And so from a practical perspective, usually what we're saying is that there is no extra traffic being generated. In other words, let's say that I want to find out what the latency is for a site. So I've got users on my network. Here's my network. And so we've got a bunch of these users. And then I've got this site out here in maybe it's on the internet, maybe it's in my data center, whatever the situation is.

2:27So here's the question. I want to know the latency, the response time, potentially, round trip time, whatever I want to describe it, but we want to test the responsiveness of this site. So let's say that I put a network device out on the network. And the purpose of this device is to serve as a network sensor for the sake of monitoring. At this point, I'm going to configure this to be sending a constant stream of p ings back and forth to this site to try to track the latency.

3:04And so I'm going to track and see that it was 30 milliseconds and 60 milliseconds and so on and so forth. But check out all of this traffic. This is an outside influence. I have deployed this device. It is generating all kinds of traffic on my network. This might well be creating a burden here on all of these network devices in the land. And it might be creating a burden on the site itself. We already had a bunch of users trying to use this site. Now I've got this other device that's just sending a bunch of traffic.

3:37As opposed to, let's say I have an agent on one of these users machines or maybe all of the user machines. And it's just passively listening. It listens to a request go out and it can tell when the request comes back. And so it logs that there was 30 milliseconds involved of latency. And so the end result is the same. But in this case, this traffic was happening anyways. We had no extra traffic generated and no outside influence. So this is the concept of active monitoring here. And this is the concept of passive monitoring up here.

4:15So there is a worthwhile conversation to have about the pros and cons of each solution. So we're looking at the pros and we're looking at the cons. And yes, there are pros and cons with each one. This is not again, not a situation where we look at this and say one of these is always better than the other. For example, with active monitoring, I might be sending these pings constantly, which could cause extra traffic. So we'll say that this is an increase in the burden on the network.

4:52We already said that that is certainly a downside. I'm going to add a burden to the network resources. Whether those are switches and routers or again servers or whatever the situation is. We've increased the burden to those resources. However, the upside is that we have also increased our ability to detect an issue. So this is going to actually create a situation where this is faster to detect.

5:30The reason why it's faster to detect is because this user here might have pointed themselves out to that website and then 10 minutes later, they point to the website again. And this is working great when they first send a request, but then the performance of the site goes way down for five whole minutes. And then it's back up. And then the next time this device tries to reach out to the website, the website is performing again. Whereas if we're sending this every one minute via the active monitoring, which is typically what we see, then we're going to notice that there was this outage here in the middle, or at least an increase in latency.

6:08And so we're more likely to detect issues. It's faster to detect issues with the downside being that we are constantly hitting that site with a bunch of traffic. Now, one other note in this is that we might also say that the downside to this is it could also be inaccurate. The reason why I say it might be inaccurate is because whatever we're doing with this active monitoring session, this is in some way supposed to be em ulating real traffic.

6:39Now, if we're just running pings, then there's not a whole lot of difference between the two. But what if we're running pings here to test latency, but up here we're testing actual HTTP sessions and actual HTTP exchanges? Well, this is probably a little bit more accurate to test latency of the server , which has to take the request in and process it and send information back versus a ping, which is relatively lightweight. So even though we're more likely to see the issue that occurs and we're likely to see it faster, it might not actually be as accurate as an actual or as a passive test, which is monitoring real traffic.

7:21Now, for passive monitoring, we basically flip these. The upside to this is that there is no additional burden, and it is extremely accurate. The problem with this, and by the way, it's accurate because again, it's looking at actual real traffic. The downside to this is that we are less likely to see an issue when it occurs, and it is going to be slower to detect it.

7:54So, which one is better? And as I said earlier, there isn't a better one. Both of these options, let's change color. Let's say the active monitoring and the passive monitoring, both of these are going to find purpose in the network. There might be a situation where what we really care about is just doing these lightweight pings to test latency or potentially even uptime and check in on the server regularly. And the users who are sporadically accessing the server, we might care a little bit more about how long it takes to load web pages.

8:29And so, we might do some form of network test via the active side, and on the passive side, we might look at actual HTTP page loads. And so, as we can tell, when it comes to thousand eyes, we are going to use both of these mechanisms. Our agents are going to allow for both active and passive monitoring, and it's going to depend on the test. As we saw earlier, when we talked about the different tests, we saw that there are real user tests that can be triggered.

9:03There are the dynamic tests that actually are monitoring real WebEx calls, for example. If I'm monitoring a real WebEx call, this is going to be a passive test. I don't need to generate additional traffic. I don't want to add burden to my WebEx servers. I just want to listen to the WebEx call, and at the end, evaluate whether it was a successful call, or if there's some issue on the network that might have caused a port call quality.

9:33Versus, if I just want to, again, test some form of uptime and do a network test, a lot of our network tests, are going to require constant pings and constant trace routes to be sent out. And so a lot of these are going to be active. And so, again, when we're looking at thousand eyes, when we're thinking about different tests to deploy, we should be thinking, is this an active test? Is this a passive test? Thousand eyes isn't going to call it this. But when we understand what the test is doing, we'll have a sense of whether this is active or passive, and from there, we're going to understand, is this going to be a problem when we evaluate the pros and cons?

10:12[BLANK_AUDIO]

0:00Well, certainly the primary scope of this course and exam is to look at thousand eyes. But when it comes to network assurance, Cisco has quite a few other products out there that can help us out, especially if we have a very specific use case. Now the advantage of thousand eyes is it provides more of an end-to-end approach to network monitoring, but it is important for us to know what other products Cisco has available for us. Now, a few of these we've already mentioned. Cisco's DNA center, which is now known as Catalyst Center, this is going to help us, especially when we're deploying software-defined access fabrics.

0:37So we are talking about campus networking. This is an SDN architecture. When we're talking about DNA and Catalyst Center, what we're really saying is that this is a software-defined networking controller. One of the advantages to software-defined networking controllers is the aggregation of data. So this is a powerful engine because we can take the data, we can run analytics , and from there we can run some amount of network assurance that's focused on this scope.

1:11Now the upside and downside to this is that we are again focusing on this scope , which means that we could get very granular very quickly when it comes to SDA and the campus environment, which by the way does include wireless. The downside of course is that it only covers SDXs and our campus environments with a few exceptions. But as we look at Cisco's other product portfolios, we start to see that their solutions are great, but they are generally speaking locked down to a specific part of our network.

1:44For example, if I look at Cisco's application-centric infrastructure, which is known as ACI, application-centric infrastructure is built for our data center infrastructures . So this is going to be inside the data center and only inside the data center. It requires a spine and leaf architecture, and once again this is an SDN solution, and we have a controller called the APIC, the application policy infrastructure controller, and this is going to largely accomplish the same thing we just talked about.

2:21It's going to aggregate data and it's going to lead to analytics and assurance within this specific scope. Now from here we have other products as well we could talk about. For example, we have SDWAN analytics for the SDWAN space. We also have Meraki Insight. This is an important one for our Meraki environments and specifically for our Meraki environments of course. And then we should also be aware of Cisco's acquisition of AppDynamics, which at this point is probably isn't even fair to call it an acquisition because it's been so long and eventually it just becomes a Cisco product.

3:00AppDynamics is a monitoring tool that actually goes inside of our code within our applications. It's a very fascinating product and we're actually going to find that Cisco 1000Is has integration with AppDynamics as well. But be aware that AppDynamics is intended for our developers more so than our network admins. In a lot of ways the things that these products do for us for monitoring our networks, AppDynamics does for the developers who are developing code where they can very quickly identify where there are issues in their code and especially if there's any kind of impact on user experience caused by the way an application has been developed.

3:46That's something that AppDynamics can very powerfully deliver. So when it comes to the scope of this course we again are focusing in on 1000Is . Now 1000Is is great because once again it's end to end. It starts with our endpoint agents. It can go all the way to a site or a service. Again, a software is a service potentially. It can go into the cloud. It can start in the cloud and it can look at even our ISP monitoring BGP routes and all kinds of things.

4:24So it provides a very powerful end to end and global view of the network. But it's not to say that any of these other solutions are worthless if we have 1000Is. I might want to drill into the details of my campus environment or my data center environment or my SD-WAN and certainly 1000Is isn't going to provide the same services that AppDynamics provides. So what exactly do we need to be aware of here? Well, again, for the scope of this course and the scope of this exam we absolutely are going to need to know how to configure 1000Is.

5:02We're going to spend pretty much the whole rest of the course talking about it. As for the rest of these solutions we don't need to worry about configuring them but we do need to understand their purpose and again these scopes. Where do they play? The SD-WAN and Maraki, it's sort of right there in the name. But where does AppDynamics play? Where does Catalyst Center play? Where does ACI and the APIC play? If we understand all of these different solutions then we can speak to ultimately what Cisco wants us to understand which is that they have a powerful portfolio around network assurance.

5:38Network assurance is not new. With 1000Is it was not something Cisco was unaware of until they acquired 1000 Is it's something they've been doing for a very long time with all of these other products. Now that we have 1000Is we have yet another network assurance product but one that is able to do something that none of these other products were able to do on their own which again is focusing in on this end to end global view of our networks.

0:00All right, let's bring it all together based on what we know. Let's look at this type of scenario where we have a network that's been established and we want to perform some amount of monitoring using 1000Is. So number one, for example, what are these things that are out on our network? Number two here, what happens when we're selecting those things and generating some amount of traffic when we detect an issue, what happens? I mean, ultimately, we should be going back through our terminology in our voc ab and thinking through all of the components and for that matter, the types of monitoring that we talked about throughout the last couple of skills to make sure that we see the end to end big picture of how 1000Is comes together.

0:44Once you're done, click the video and we will review this together.

0:00Well, hopefully you took the time with a piece of paper and a pencil to jot this all out, make sure we've got all of this terminology down because this is foundational knowledge. Now I do recognize that maybe my diagram is a little busy in places, but hopefully it was clear enough that we could figure out which components go where. So let's just go ahead and go through this. First of all, we have our agents. We absolutely need to know there are three different types of agents. We have the endpoint agents, the enterprise agents, and the cloud agents. If you didn't label the types, that's perfectly fine.

0:32Just recognizing that we have the agents out there on the network and we use tests to select agents and generate traffic. So that would be number two here. Number three, if we detect an issue, we are going to use our alerts in order to allow the admins to know that something is up. We might also, by the way, use events. Just keep in mind the difference there is that alerts are configured and events are more anomaly detection. We're not configuring events. Number four here is how do we filter all of these agents?

1:04How do we filter all of the tests? We can use labels for this. That's a very powerful tool that we're going to want to use when we're config uring thousand eyes. And then lastly, our two types of monitoring, we're just kind of going off of the color coating here. If we have generated traffic, we are creating that again, we have an outside impact or an outside influencer on our network, this would be active monitoring where we may be told this cloud agent to generate this traffic. That was the idea of this pointing in here is to say that this is generated traffic versus natural traffic or traffic that was occurring anyways.

1:43We're just going to listen to that. That would be passive monitoring. Again, there's no right or wrong answer objectively in every case between active and passive monitoring, but naturally thousand eyes with its many different testing types, some of them are active, some of them are passive. And once again, we need to understand the difference. So ultimately, this was a little bit of just hitting vocab hard, but it's more than just vocab. These are the fundamental building blocks of how thousand eyes operates. As we go into the configuration of thousand eyes, we must understand the different types of agents, the role of tests and alerts and all of this comes together.

2:21Ultimately, we'll also see views and dashboards. And without any of these components in place, we really can't have a successful thousand eyes deployment. I hope there's been informative for you and I'd like to thank you for viewing.