Beyond network uptime: Measure, validate, and improve network services

Hello, good morning, everyone. Welcome to this new new expert insights series and network assurance. Today we have Marco Sanchez and he's the.00:10Going to to be with us during these three sessions that we have will guide us to the demos and to the the presentation about it. So the floor is yours, Marcos, please.00:20Oh. Thank you thank you everyone for joining and alright, so let me start presenting my slide, my.00:31Screen just give me one moment and we're gonna be waiting for a couple of minutes, maybe 3 min for more people to join and.00:46Oh While they join and while we wait, I just want to introduce the briefly Cisco IQ. I don't know if you have heard about it, if you know what it is.01:03But Cisco IQ is a AI powered digital interface that brings real time insights, on demand assessments, troubleshooting, personalized learning, automation, all of this powered by.01:20AI and this session is not about Cisco IQ, so if you require more information about Cisco IQ, feel free to contact your accounting. They will be able to.01:38Get you in touch, put in contact with the right people for you to know and to learn more about Cisco IQ. However, right now Cisco IQ is open to all customers. All you have to do is to go to iQ.cisco.com and begin with the registration process.01:54Feel free to explore this and see what it has to offer you and to give you. Alright, and let's just give it one more minute and then we'll start the presentation.02:15Yeah me also see if, Yeah, the meeting is recording, it's being recorded Okay.02:37So it's been a minute. So let's start because we have a lot of things to talk about today and this is the 1st of three sessions. The title of the 1st session is Beyond Network uptime.02:56Measure, validate and improve network services. This is the 1st of three sessions related to network assurance. My name is Marco Sanchez. I'm part of the customer success specialist team and.03:12Feel free to ask questions during the presentation using the chat here in the, in the in Webex with me I have Derek. I'm sure many of you know him or you have worked with him.03:31He's part of the professional services team. He will be helping in answering or providing, documentation to answer your questions in the chat. And I also have other colleagues joining me here from my team. They will also be providing answers to your question.03:47Let's see if you have any.04:07As I was saying, this is the 1st of three sessions. This session is an introductory session to the world of Network assurance. I will be talking about cross work assurance and 2nd session next week.04:10I will be doing a deep dive into the analytics platform. We'll be learning more in detail about the analytics platform. Today I will introduce the platform briefly.04:28And next week we'll do a deep dive into the platform and then in the last session in two weeks, we will see how is it that Crosswork Assurance integrates with Cisco's portfolio. How is it that Crosswork Assurance is now integrating with solutions such as, e.g..04:44Splunk or NSO. So that's roughly what we will be seeing in the upcoming sessions. The agenda for today will start with network assurance fundaments. We'll start with an introduction to Cisco Crosswork assurance.05:03A solution overview will go through assurance sensory capabilities and then a demo. Okay, so let's start with the fundaments, the basics. It's important to understand here because.05:22This will help us build our knowledge or understanding of what I will be discussing in during the presentation today and in the upcoming sessions in the next weeks. But 1st.05:40Let's address the elephant in the room because maybe you saw in the title cross work assurance, and you ask yourself, what is Crosswork assurance? Is this a new solution? Is this a new platform?05:57A new product, what's cross work assurance or maybe you also saw in the title provider Connectivity assurance PCA, and you asked what happened to PCA? Where is it going? What about it, right?06:14Well, let me tell you that they're the same. Provider connectivity assurance is now Crosswork assurance. It's been renamed as cross work assurance. About two weeks ago, this change happened.06:32If you go to the documentation for provider connectivity assurance, you will see that now it says cross work assurance. So they're the same solution. It's just a name change. The same features that you have, you still have them.06:49From a technical point of view, everything is the the same benefits that you had, they remain. It's just the name that it is changing. So this is a brand alignment because we have a lot of.07:07Cross work products. You might have heard of them such as e.g. cross work network controller, Crosswork AI, Crosswork workflow manager. We have different, we have several products and now cross work assurance previously known as provider connectivity.07:24The assurance is part of the cross work family. So this means that from now on, assurance is an is a key element from the cross work portfolio. In the future, we will see interesting things coming up.07:43In regards to features, but for now is just a name change, so everything remains as it was for you. And habits are hard to break, I know. So I apologize in advance. If you hear me say sometimes PCA your provider connectivity.08:03The assurance. Know that I'm referring to the same cross work assurance. So they're the same. I will do my best to only say cross work assurance, but if it happens and if I say BCA, please know that I'm referring to the same solution. All right.08:23The need for performance data. Why do we need networking performance data? So I've been, I've had different lives here in Cisco and a couple of years I was part of Cisco.08:41The technical assistance center. So when you open a case, a troubleshooting case, my team was handling issues related to network slowness and packet loss.09:00In the routers. So I understand the pain of investigating such issues. And let me start with the small, with a small demo. Now this what I will be showing you today.09:13Now this what I will be showing you is the final demo. This demo will be looking at it in more detail in the last session, in the 3rd session. So don't worry if you don't understand certain parts of the demo or certain things that I say.09:34But I want to start with this to showcase the need for a performance data. Here I'm using a website to showcase a service. The ser the service could be.09:52Voice could be gaming, could be whichever the service that you might that you that you think of. I'm using a web service because it's easy to use it as an example.10:08And what happens when someone starts to report slowness in the website? Notice how is it loading slow. I hope you're able to see that moving through the pages is taking some time.10:23Right? And I say, well, I don't worry because I have a backup of this and I have another one in here. And then I go to the backup, notice that it is a different website, web service because it's a different port and also to help this in a visual way.10:40I have used a different background color, but the backup is also having some type of slowness, see both are having some type of slowness Moving through the pages is taking time.10:58And when I used to work in tech and Cisco tech, this is sometimes all the information that we received from customers. They said, users are starting to complain about a website that it is taking a web service that it is taking a high time to reply.11:17How do you start troubleshooting an issue like this? So let me ask you, how do you start troubleshooting an issue like this? You have two different scenarios for this. The scenario in which you don't have network performance data, the scenario in which you don't have a network.11:37Network assurance platform.11:57And the scenario in which you do have a network assurance platform and you are collecting network performance data, very likely, most of the customers that had some type of assurance platform, they didn't open tack cases for me to help them in the investigation because.11:58From what I recall, all of the customers opening that cases with my team, they didn't have performance data or network assurance platforms. So we have to do a lot of manual investigation to troubleshoot issues like this.12:17And roughly the path that I would take to troubleshoot an issue of this nature is I will start with a trace route. You you might agree or disagree with my path, but let me outline the path that I would take in a scenario like this. I will start with a trace route.12:34From the place where the issue is being reported all the way up to the place where I have this web service running. And again, the service could be anything. For now I have used a web service because it is an easy example to show.12:54So I would do a trace route. I will look at the hops, and if I see a hop that it is taking a long time to reply, it would be a safe assumption to go to the hop and investigate that device, see if something is wrong with the device.13:11When I go to the device, I look at different data in the device. E.g., I look at the uptime of the device. Maybe the device had an unexpected reload and that is what triggered the cost. If the uptime is ok, I investigate, e.g., the interfaces in the device to see if there is any.13:27The interface congestion, any packet loss in the interface.13:47I look at the syslog within the device to see if there's any errors. And if I don't see anything, then I move ahead and then I start to investigate using tools like packet captures, e.g..13:53Traffic mirroring, I would use things like that. And the scenario could be even more complex because what if the issues are intermittent? What if they're happening from time to time?14:09Right? And we don't know when this loness in the website is going to happen and that was very frequently the the scenario. Customers calling us and telling me telling my team, the issue is not happening right now, but it happened 2 h ago.14:26How do you investigate an issue like that when you don't have a network assurance platform? Let me tell you, it's complicated, it is a process that takes hours or even days. And if you've been in that position, I understand.14:42What you might be going through. And let's move to the other scenario. Let's move to the scenario in which I do have networking performance data. I have an assurance platform. In this case I have crosswork assurance.14:59And I have integrated cross work Assurance with Splunk. So in Splunk I'm receiving alerts from Crosswork Assurance and I'm also receiving in Splunk information about the performance of the website. So I'm collecting all of that data.15:15In Splunk. Now, this is not a training on Splunk or this is not a meeting on Splunk, but, you know that you might know that in the Splunk to investigate data, you need to use its query language.15:35For the purpose of today's session, I am using AI capabilities in Splunk to interact with the data in Splunk. And let me ask Splunk the following questions. So I have here an AI assistant tool that I have integrated with Splunk, and let me ask my AI.15:54Assistant based on the PCA alerts and web browser performance performance data received over the past 1 h.16:14Which are both sites, websites affected by a networking issue?16:33Or which one, if not, which one it is? If not, which one it is? So this is interacting with Splunk, it's doing some queries with the data that I have in Splunk and let's see what the answer will be.16:50And again in Splunk, what I'm doing is I'm collecting the alerts from PCA and I'm also collecting performance data from my web service. Here it says NO, only side one is affected by a network issue. Pcras PCA raised one alert.17:11Related to site one, site one network issue confirmed, site two also slow, but non network alerts whatsoever. And spoiler alert, this is actually true because I am the one who created the scenario. The slowness cost in this website, website one.17:31It's because of a network slowness that I have introduced. The slowness cost in this website, in the copy of the website is not caused by the network. And sometimes what you want is that you want a way to prove innocence of network.17:51When an issue like this happens, you need a way to prove, hey, my network is fine. Here I have the, the, the performance data and I can show you that the network is performing as expected. So the answer with the data that I collecting in Splunk is correct. And again.18:11And the final session, in the 3rd session, I will go, I will cover this in more detail to understand better what happened, how is it that we arrived to this conclusion, but it is right. This one is affected by a network issue, right?18:30So when we don't, when we don't have performance data, when we don't have a network assurance platform, and when an issue like this is reported, we start to act.18:47As crime scene investigators, we're trying to piece together what happened, where using tools like probing tools, packet sniffer, CLI commands, and all of this is a reactive approach we are reacting to the problem.19:02We want to move to a proactive approach. We want to have a way to ingest enrich and correlate networking data from multiple source sources to uncover network issues and identify the root cause of a network.19:21Problem. In the struggle to to to assure it network quality, the secret weapon is networking performance data. And we want to be able to explore this data when we need it, not only when the issue is happening.19:39But when we need it and I'll elaborate on this as I move forward. So you, you will, you're starting to hear the word assurance, but what is assurance? Let's define assurance. So network assurance defines and focuses on the performance and general health.19:58Health of a network to ensure reliable, uninterrupted operation. Network assurance monitor the hardware, software, protocol, devices, network assurance can detect false, identify issues, and optimize performance.20:18Service assurance looks at the network from the user experience point of view. Network assurance is a key part of the user digital experience, so it is important to monitor network performance.20:38The service is the product and the network enables the service. Service assurance includes network assurance plus end to end delivery of services.20:54If you have an assurance platform, if you are using a network assurance software, your software, your solution, whichever it is, should be able to answer the following questions. How do I understand the current state of the network?21:11How do I guarantee that I have not introduced errors while specifying configuration of network devices? How do I rapidly diagnose the network when an issue arise? By being able to answer these questions, you are moving from a reactive approach.21:29To a proactive approach and cross work assurance helps to answer these questions. With network assurance software, you can predict network issues before they impact your business. And how is it that a network assurance solution is capable of answering.21:48Doing this question. Well, it does it with KPIs by measuring KPIs. Kpis are measurable performance benchmarks that identify areas that you need to understand, control.22:08Measure, visualize, report, and optimize to keep your business on track. Evaluating KPIs and performance monitoring data can tell you what needs to be improved or fixed.22:26And when it comes to network performance, we have different KPIs. You are familiar very likely with all of them. We have KPIs such as delay. How long it takes for a packet to go from point A to point B?22:42We have throughput. What is the amount of data passing through a network link over a specific period of time? We have packet loss, number or percentage of packets that didn't arrive at the destination when it was expected.23:00We have jitter, which is a delay, it's a fluctuation in the delays of the packets. So low jitter provides more predictable and consistent packet delivery times.23:16And high jitter indicates more variability in the in the in the delivery times of the packets. But we have many many KPIs and likely you're already collecting these KPIs because there isn't a unique way.23:31To collect these KPIs. You can collect these KPIs not only with cross work assurance, but with many other tools, right? But why collecting these KPIs with cross work assurance is different, right? Let's go ahead.23:51And answer that. We have two ways for the purpose of the, of the session and and for the purpose of cross work assurance, we have two ways to monitor network performance. Passive.24:10Monitoring and active monitoring. With passive monitoring, you are observing user generated traffic passing through the devices. Passive monitoring can can inspect packets.24:26In real time and to and to derive KPIs from those packets traversing the devices. Then you have a system that it is pulling those devices periodically and collecting this information to assess.24:42Network performance and is presenting to you these KPIs in time windows of one to 5 min. The level of detail of information with passive monitoring depends on the network metrics of interest.25:00How the metrics are being processed and something important, keep this in mind. The level of detail of information that passive monitoring will give you, depends on the volume of traffic passing through the device.25:18So let's say that it is 03:00 A.M. in the ne in the morning, and your network only offers services to a single time zone, just one time zone. Let's simplify the example.25:36So let's say it's 03:00 A.M. in the morning, you have passive monitoring, which depends on the volume of traffic passing through the monitoring device, and then something goes wrong because even if it is 3aM. In the morning and you don't have that many users using your network.25:50Things can go wrong. Let's say, layer one link breaks and packet loss starts to happen because of that link breaking because there's not a lot of user data at that time, volume of traffic, maybe NO impact will be seen.26:09Because not a lot of people are using data, not a lot of traffic passing through the network. So your passive monitoring tools might miss this scenario because passive monitoring tools depend on the volume.26:28Passing through the money passing through the device. We will see how is it that active measurement covers this gap. We have different protocols for passive monitoring, we have.26:44SNMP, we have NetFlow, and with these protocols, as I was saying, you are collecting similar KPIs, delay, jitter packet loss, et cetera.26:59And now let's see, active monitoring, active measurement, and keep in mind that both solutions both approaches passive and active, they allow you to identify problems.27:16And another one is better than the other and or and you can have both because bone allow you to identify problems. However, let's understand the advantages of of active monitoring, and maybe for your use case, active monitoring is a best.27:30Fit. So with active monitoring, what you're using or what you're doing is you're actively inserting test traffic. Passive monitoring is a little bit limited in its ability to emulate error scenarios.27:48With active monitoring, because you get to define the characteristics of the traffic that you will be injecting, you will be able to define different scenarios. E.g., you are able to define the packet size, the class of service.28:08The VLAN over the traffic because you want the traffic that you will be injecting to mirror the scenario that you are, that you want to monitor. Artificially injecting traffic usually does not distroy.28:26The traffic, so NO need to worry about that. And what it is a good a great advantage of active monitoring is that you can monitor traffic even in the absence of actual user traffic, right?28:44With active monitoring, we have different technologies. For layer two, we have protocol Y 1731. This is for layer two and for layer three we have E12 way active measurement protocol. This is the protocol that we will be using.29:02In the presentations. Now, once you start collecting data, I've been also on the other spectrum, on the other side of the spectrum over the past couple of years I have been part of the observability.29:21The landscape. So I've also I have also seen the other side of the spectrum going from having NO data or NO performance data to having a lot of KPIs and having a lot of KPIs.29:41Without a purpose is not necessarily good because clarity in our data leads to clarity in our actions. Make those KPIs that you are collecting meaningful.29:57Focus not only on what you are measuring, but the reason that you are measuring it because we might be ending up providing too many KPIs to stakeholders and producing statistics without a clear purpose. So when you choose a KPI to monitor, ask yourself.30:16What message does this KPI deliver? A KPI is only useful if you consider the action that you might take when it tells you that something is good or bad. You should have a clear understanding of what the message the KPI will communicate.30:35We will see how is it that with cross work assurance. This is something that we will see in 2nd session.30:56We will see that how we see that with cross work assurance we are going to be able to build network health dashboards and reports. And we need to make sure to refine, we need to make sure to refine the message to avoid inflicting information overload.31:02On the recipient, whoever is looking at the dashboard or at the or at the report. Also, the schedule their KPIs that you are collecting on a schedule because what it is important to you to you today might not be important to you in one year.31:18So if you configure your tool to collect certain KPIs five years ago, review that those KPIs that you have in your reports, in your dashboards are still relevant to you because maybe it changed.31:38And predictive assurance is a journey. You don't start and not just because you have a software assurance solution, that's it. It's finished. It's a journey, it's a progressive journey. I'm sure most of you in this session are either in level two to four.31:58And I'm sure all of the customers that I helped when I was in Cisco tech, they were at level one. I can tell you that for sure. They had what I what it is called chaotic monitoring. They have a lot of tools.32:19To troubleshoot all of them working in silos, they have some basic event monitoring and they rely a lot on manual methods to find the root cause of an issue. If you move one step above chaotic monitoring to level two, reactive.32:35Monitoring. This means that you're already monitoring static SLAs, manual thresholds, you have alerts based on those SLAs, those thresholds. You already have dashboards that help you minimize mean time to resolution and filter noise by selecting the right KPIs.32:55If you have moved one step forward and you're at level three, maybe you're already in proactive monitoring. So you are able to detect and resolve issues before they have a business impact. You have added.33:16Metadata or business context to the KPIs that you are collecting. You have end to end service visibility and you are capable of real time SLA monitoring. Usually level three is.33:32Enough for most customers and if you're in level three perfect. But if you still want to move one level above to predictive monitoring, then maybe you have dashboards that are business centric that can re correlate.33:49Network performance KPIs with business performance KPI. What happens in my business when my network is slow? Is it impacting my revenue? Maybe I have a dashboard that can answer that for me. I'm also leveraging AI.34:08Tools or machine learning tools to predict faults. And I'm using the analytics to drive new revenue. So we can, we will be understanding and we will discovery how is it that PCA can help you move from.34:24The different levels. And let's move to Crosswork assurance that just as a reminder in case you were late, Crosswork assurance is PCA provided connectivity assurance. It's been renamed.34:42It's just a name change. So if you have been saying provider connectivity assurance or PCA, moving on, you will start to hear cross work assurance and keep in mind that they refer to the same. They're the same. Crosswork assurance is a network assurance platform that provides.35:01Provides real time end to end monitoring, and it allows us to monitor from the access layer to the aggregation layer, to the core, to the cloud with micro second granularity. It all starts at stage one with the use of sensors.35:21Crosswork Assurance has both software based and hardware based sensors, hardware based sensors such as sfps. The sensors, they can sample data at the millisecond level.35:41And the sensors will be doing active proving in the real time, 2047, right? So this is not only when an issue is detected or when you click on the button, that's not it.35:56The sensors are doing proving 2047. The data is streamed from the sensors is streamed into the analytics platform. The analytics platform is an analytics engine.36:12Which can collect over 50 KPIs coming from the measurements that the sensors are performing to proactively predict and investigate issues. And it is important to mention that.36:28The analytics platform of Crosswork Assurance not only is capable of ingesting data coming from the sensors, it is from the test of the sensors, it can also ingest other type of data, e.g., Cisco telemetry data, and it can also collect 3rd party data.36:43So if you have any data that it is presented in a time series format.37:03The Crosswork Assurance Analytics platform is capable of consuming that data. With the data that you have in the analytics platform, you are gonna be able to take to to make decision to make decisions.37:08The analytic platform helping this process because it is able to trigger alerts. It is able to integrate with other solutions such as Splunk as I showed you at the very beginning or NSO.37:25And then once you have that, you are gonna be able to take an action based on the, the, the alerts or the data that you're collecting with the analytics. So this will help you transform overwhelming data into actionable insights ensuring that you can.37:44Maintain and improve network.38:02Performance. PCA is a multi vendor, multi domain multi layer platform because having a network that it is a multi vendor network, multi domain network, a multi layer platform means that there are multiple places where.38:05Things can go wrong.38:25Crosswork Assurance will help you in this process because it is, it covers all of these scenarios. It is not specific to your Cisco devices anywhere in the network where you can place a software sensory or a hardware sensory.38:28That's enough for cross work assurance to collect data. Doesn't matter what, if, whether it's Cisco or not the device or or the devices that you want to measure its performance, it doesn't matter. Crosswork Assurance will be able to do it for you.38:46Doesn't matter if it is a device at the access layer, at the aggregation layer, it doesn't matter. And the information shown in cross work assurance can be presented to different stakeholders, e.g., can be used by the engineering team for activation testing, can be used by the network operation.39:02Team to detect issues to or to troubleshoot issues.39:22Or it can be presented to business stakeholders in executive dashboards. You can do all of this with cross work assurance. And you might be thinking, is cross work assurance.39:26Enough for my scenario is Crosswork assurance going to help me in my use case. So let's simplify this idea. Whether you are going through a migration.39:43You are going through an implementation, maybe you are going through an equipment upgrade, you are going through an increasing capacity of a link, e.g.. And it doesn't matter if you're a service provider, a retail company, a finance, entity.39:58And it doesn't matter if you are dealing with a wide area network with a metropolitan area network or a data center. Let's simplify all of this into one concept. Network help us move data from one point.40:18To another point, that's the purpose of networking, moving data from point A to point B And you get to define those points across multiple places in your network at the access layer, at the aggregation layer.40:36If you're able to simply to understand your use case from this point of view, moving data from one point to another point, and then what you want to monitor is the path that this data will be taken.40:56Then PCA can help you do it. How is it that it can do it? Let's see an overview of the architecture of PCA. It all starts with sensories. So we have.41:12Software sensors and we have hardware sensors. By among the hardware sensors we have sfps and modules. The sensors, they provide sampling sub second sampling data.41:28And the sensors allow you to monitor a network in real time. Regardless of the replacement, we can achieve end to end visibility or focus on a specific network segment. The sensors are in charge of initiating the test, the of the monitoring session.41:48The sensors can collect one way metrics because you might be able you might be experiencing packet loss from point A to point B, but maybe you are not experiencing packet loss from point B.42:09To point A on the way back. So the sensors are able to collect to to produce data in one way, or in as as round trip, round trip as well. The sensors, as I was saying, they run the tests 2047.42:24And since you are able to put the sensors at any location across any segment, you are going to gain a comprehensive visibility. The sensors support multiple type of tests and multiple configuration to meetor the traffic that you are.42:45That you want to measure because you get to define the characteristics of the traffic of the synthetic traffic such as, e.g., the D the the QoS marking or the size of the packet, e.g., to cover the different use cases that you might have.43:04For the sensors to work, what you need is one sensor acting as the initiator of the monitoring test and then a reflectory. A reflector can be another sensory or any device, whether it is Cisco or not.43:24Capable of reflecting the traffic from the sensors. So if you have devices supporting the T one protocol, you are gonna be able to use any of the sensors. If they don't support the T one protocol, we have other tests such as ICMP.43:43For UDP ICMP that can also collect and perform tests to measure the path from point A to point B The data generated by the sensors is dense.44:01Sent to a collector, which is another component. The collector is collectors are capable of receiving data from multiple sensors. And then the collector will stream data.44:17To the analytics platform, to the analytics engine. This will provide a single pane of glas glass for all the monitoring data being collected. Now, those of you who are more familiar with cross work assurance.44:33We'll know that I'm missing two components of the solution. These two components, they come into the picture if you are using hardware sensors. If you're using hardware sensors, you will need two other components.44:53One is the sensory management. It was previously called the orchestrator and sensory control. Those are the two components that you need if you're using hardware sensors.45:08Because the focus of the presentation that I will be delivering is on the data rather than on the way that the data is being generated, I'm not covering neither the orchestrator or the.45:26Sensor management as it as it is called now or the sensor control. However, last year my my teammates, they deliver a similar session to this one that I'm delivering today in which they talked about those two components that I'm not going to be mentioning.45:40That I will not be covering. If you want to know more about the sensor management orchestrator and the sensor control, at the end of the presentation, I have put a link to the recording from the session of last year in which those two components were discussed. Again, those.45:58They come into the picture if you are using hardware sensors. Sampling matters when it comes to network performance. Look at the graph above. Here we have a growth, that.46:19It's where it's showing measurements that it is taken every minute. This infrequent sampling results in a misleading graph because you see that the SLA is never getting crossed.46:38Since data is being averaged over 1 min of data, if you had a microburst, the microburst, it was averaged down and it seems that you're always below the threshold that you are monitoring.46:56When we move to high resolution sampling, we discover that maybe our network is not performing as we thought that it was performing, and assurance crosswork assurance sensors, they do high resolution sampling.47:14They're able to send up to ten packets per second. That's the default ten packets per second. So it means that if the sensors are sending ten packets per second, you are taking measurements every 100.47:34Millisecond. So that's why we have a high resolution sampling. With the high resolution sampling, you are able to detect.47:51Microburst and you will see that sometimes you are crossing the threshold, the SLA threshold that you have defined. And you might be thinking, well, it's just a microburst. What's the worst thing, I I don't care about that. It's not causing anything. Well.48:00Micro events can be the cause of problems. E.g., let's use or let's think of the following scenario. Suppose that your network starts to introduce one additional millisecond of latency.48:20Over an acceptable existing delay of milliseconds. So going from five milliseconds to six milliseconds delay, from the service provider point of view, the performance indicator hasn't changed a lot.48:36However, this additional millisecond can be the cost of, let's say, TCP retransmission. TCP retransmissions that will translate into reestablishing of server connections.48:52And this additional millisecond can turn into megabytes of lost throughput, and at the end for the end customer, what they will have is a poor experience. So microevens matter and a way to measure those or to find those microevens is.49:07Through high resolution sampling, which the cross work assurance sensors are capable of doing.49:27As I was mentioning, the sensors can be placed anywhere in your network from the access layer to the aggregation layer to the core layer. And by looking at this picture, you might be asking yourself, so do I need.49:37To place sensors all over my network. E.g., let's say that I have a sensory here in this switch. The switch is connecting to this other switch and this other switch, and I want to monitor both connections.49:54From here to here and from here to here. You might be thinking, well, I will need to place a lot of sensories in the network and and yes and NO, because one single sensory.50:11He's capable of handling multiple monitoring sessions. I will discuss the capabilities of the sensors in a moment, but here you only need, let's say, one single sensor here, only one sensor.50:27We'll keep, will be capable of performing tests towards this switch, towards this switch and let's even go further and let's say that you want to test from this point A to this point B, to this point as well.50:44The same sensor is going to be able to perform those tests from here to here, from here to here, from here to here, from here to here. So you only need one sensor, but what you need is multiple sessions and one single sensor is capable of handling.51:00Multiple sessions, right? And, again, the sensors are multi vendor, so it doesn't matter whether you have a Cisco device or not. As long as you are able to put one of the sensors.51:17Hardware or software, we are gonna be able to do and take measurements. Having this type of segregation, meaning measuring in between, different paths and links, it enables you it enables you to rapidly move traffic and react.51:33Back to the issues before the impact is is higher.51:53The sensors are standard based, so that's why that's what makes those sensors multi vendor sensors, not, not specific to, to Cisco. And we have multiple sensors, I will be covering them in a moment. All you have to do is to pay.51:58Be the best one for your use case.52:17So moving on to the sensory capabilities. We, so as I was mentioning, we have software sensors and hardware sensors. Within the software sensors and for the purpose of today's session, the one that I will be showing is the.52:24Actuator sensor. The actuator sensor is capable of performing different.52:44Monitoring tests, such as T wamp, UDP echo or ICMP echo. But we also have other software sensors such as the trace sensor, the trace sensor is capable of doing.52:51Trace route for layer three throughput for a TCP speed test. And in the next session, I will be covering as well the transfer agent. The transfer agent is capable of implementing an HTTP client.53:08For testing the availability and responsiveness of a web service.53:28All of these sensors, all they need is a docker container. So anywhere where you can place a docker container within your network, you are gonna be able to place one of these sensors.53:36That's all it requires being capable of running a docker containers and they're low footprint, so they don't take a lot of resources from the machine or from the environment where you install the sensories.53:51And you might be thinking, it seems that the software sensors are good enough. Why would I need a hardware sensor, let's say? Well.54:08For certain scenarios and for certain your use cases, you do need a hardware sensory. E.g., software sensors are capable of doing layer 3D1 testing sessions.54:21But if you want to do layer two sessions or layer two performance monitoring sessions using the protocol Y 1731 for layer two, you will need a hardware sensor. That's one of the scenarios in which you will need a hardware sensor.54:40If you need to do service activation testing, you will need a hardware sensor because the software sensors are don't have this feature. Also the sfps, the hardware sfps, they provide a hardware.54:57Timestamping accuracy, which is higher than the software timestamping accuracy of the software sensory. So if you have a scenario in which you want millimetric hardware timestamping accuracy.55:16The sfps or the hardware modules capable of doing, or or or having these features, you will require a hardware module. And whether you're using a hardware sensor or a software sensor.55:32They will both collect the same metrics. Here is a list of the metrics that will be collected by the sensors. It's over 50.55:50KPIs, you'll see them, I'll show them in the platform in a, in a moment. And you might be seeing, e.g., that you have metrics such as percentile, right? And you might be saying, well, I don't really need percentile metrics.56:07Percentile metrics are very useful are are extremely useful. E.g., the the 95 percentile metric, they they help you, remove the outliers.56:25So P 95 focused on the sustained conditions by removing the outliers in the metrics, the outlier for and it provides and PCA provides these metrics for jitter delay, so each delay jitter that you metric that you.56:41Collect, you'll see the percentile metrics in.57:01PCA. And I'll show you them in a moment. So moving on to the demo section of the presentation, this is the scenario. I have one sender, one actuator sender here.57:05With this IP address and then I have a, well I have a device here and another device here. The device here, it has this IP address and the reflector device here on the other end. It has this IP address.57:25The reflectory device that I hear that I have here, it supports T one reflection. And it is a good opportunity to talk about T one, briefly talk about T one.57:42T one comes in two flavors, both supported by the assurance sensories of Crosswork assurance, hardware or software. T one comes in two flavors. T one stateless and T one.57:57Stateful. With stateful T one, you are capable of collecting one way metrics because I might have, as I said in a previous scenario, I might have lost packet loss from.58:13The sender, the reflector, but maybe I don't have packet loss on the way back. With T wamp stateful, I will be able to collect one way matrix. With T one stateless.58:29I collect only round trip metrics. And you might be thinking why then would I use T one stateless if it seems that it provides less accuracy or less information?58:45And well, it is because not all vendors, not all devices support D one stateful. So for those scenarios in which they don't support D one stateful, you have D one stateless and if.59:01The device that you are, that it is that or the point that you want to measure does not support T one or you don't have access because maybe you don't manage this device in here. You can still do testing because you have ICMP testing and you have.59:18UDP and, and ICMP testing. And it's not a simple ping because a simple ping is very basic, but it is a ping that will collect all of the same metrics that you see here such as percentiles, minimum.59:39The Maximum average.59:58So you can gain a lot of insights using Crosswork assurance just from a simple thing. So it's a it's a powerful pink, the one that you are capable of doing with cross work assurance. Okay, so I have the following scenario. I have one device.01:00:01In which I have an actuator software center and then I have another device with this IP address in which I have configured as a reflector. And not only that, I have also configured QoS in my link. So I have three classes.01:00:21Of service. I have.01:00:41Best effort, assurance forwarding and express forwarding. And I want to measure all those three classes of service individually and independently. I'm capable of doing that with a single sensor in here.01:00:43And I will be able to configure multiple sessions towards the reflector. And I forgot to mention this actually. Software sensors, they can run up to 500 sessions. One single sensor can run up to 500 sensors.01:01:02The hardware sensors, they increase this capability and one hardware sensor is capable of running up to 2000 sessions. So if you want, if you have a scenario in which you do.01:01:23Need to test for multiple use cases for multiple types of traffic, and you need more than, because remember what I said, going to this with one single sensor, let's say we have a sensor in here and.01:01:39Just from this picture, which is very simple, only, a couple of devices, if I want to configure a session from here, from this access switch to this point, to this point, to this point, and to this point, I will need four sessions running in one single sensor.01:01:56One single sensory. So imagine as a network gets more and more complex, that's the reason I might end up having a lot of sessions running in one single sensory.01:02:16And that's why software sensors, they support up to 500 sessions and hardware sensors, they support up to 2000 sessions. Okay, so let's go ahead to the demo and move forward to the demo.01:02:28I have an actuator sender, an actuator sender in here and I have configured this device as the reflector, and I have, let me.01:02:48Refresh, this. Okay, here I have my cross work assurance platform. In the next session in a week, I will be covering the platform in more detail. I will be going through the all of the features.01:03:02Series of the crosswork platform will be seen.01:03:21We will be seeing the platform in in more detail. For now what I want to show you is, and let me go back briefly to this presentation for you to keep in mind.01:03:24Once I have a sensory, the sensors are going to be sending that data to a collectory. And I can use one collector to collect data from multiple sensors, right?01:03:42But I need the collector because the collector is the one that will be streaming the data.01:04:02To my analytics platform. So somewhere in my environment, I have a collector configured. It is actually this one. I have placed the collector. This is the collector that will be gathering the data from.01:04:07The sensor agent, and here I have multiple agents. In this case, there's only one single agent, let me.01:04:25So this single agent represents here, this point in the network. From this point in the network, I want to configure multiple tests towards one reflector. In this case, it is this one, but if I had more paths and more reflectors placed in other parts of the.01:04:46Network, I could also configure them in the same sensor. So here I have this agent, this sensor agent, and it is running as a docker container that I have installed in a, in a.01:05:06In a, in a Linux environment that supports a Docker container, I have already configured two, two sessions. One session for a best effort and the other session for express forwarding. So best effort is actually the default. When I do not specify a.01:05:23The SSCP marking, the default is zero. I just added or put the zero, to make it more clear, but if I do not specify it, it's zero. And when I configure a session, I click here under the agent and then under sessions in the plus icon.01:05:43And I have, I am presented with different options. This is an actuator sensory. Remember that I have multiple sensors and depending on my use case is what I will be the, this type of sensor that I will be deploying. The one that I have.01:06:03That's an actual sensory.01:06:22I also have a trace or we also have available a trace sensor, a throughput sensor, and a transfer sensor offering other type of testing. In the next session in a week, I will be discussing the transfer a agent. But the one that I'm using now is an actuate.01:06:25Sensory here in the title it even says actuate sensory. The actual sensor can perform stateless and stateful. If T one is not available for any reason, I also can do a.01:06:43Echo ICMP or echo UDP. If I had other type of sensor installed, the other options would be available, but in this case since this is an actuate agent, only these are available. When I select stateful.01:06:59And then I click session configuration. I define a couple of values and the mandatory values are the name of the session, the reflectory address, and here is where I get to def to de to define the.01:07:15The the the the nature of the traffic. Let's remember that what we want is to mirror the real network traffic. So if I have a specific requirement when it comes to a, a QS marking, a packet size.01:07:35I get to define that in here. In my scenario, in the scenario that I'm testing, I want to test for, assured for awarding marking 2026, so I will here enter 26. Let's.01:07:54See the configuration for the other two for the best effort.01:08:14All I did is I defined the reflector address, which is shown here in the presentation, that's the IP address of the reflector and the marking zero, which is the default. If I don't specify any QoS marking, the default is zero.01:08:18For express forwarding, I did the same. I have my reflector address, which is the same IP address because I'm testing toward the same device. But the QS code is different in this case for express forwarding is 46. So I will be now configuring.01:08:34Doing a 3rd session using the same sensor agent, the same actuator agent. It will be a stateful session.01:08:54And let me copy the IP address from the reflector, I want to assign a meaningful name to.01:09:04To the session I'm gonna call it assurance for assurance forwarding and the marking is 26. If I wanted to modify something else within the traffic such as the packet.01:09:24The the the the the the packet size, I could do it. And also I can, I get to change the sampling if I need more, a higher sampling, e.g., Notice how the default is 10:10 packets per second. When we choose ten or when we leave ten, it means that the.01:09:39Test is going to be performing tests every 100 milliseconds because he's sending ten packets per second.01:09:59So that's the reflector, the QS code, and that's it. I don't need to enter any other information. So I'm gonna just save the changes. This session appears here now listed.01:10:09And let me start the session. We'll have to wait a few moments. Now the session starts to run.01:10:22While we wait for data to show in cross work assurance because at at the during the 1st delay deployment, it takes a while, a couple of minutes for data to start showing up in PCA. Crosswork assurance. I want to show you something else.01:10:40And if you go here under ingestion, you will see the different type of testings available within the platform and in this case T one stateful, notice the number of KPIs being collected.01:10:58Here you get the list of all the KPIs and a little bit of a description and whether it is a KPI that can be obtained from source to destination, destination to source or a round trip.01:11:16Oh, I've only, I'm only showing in the performance test that I'm that I'm doing that I have configured. I'm only testing the ones that I have enabled. But if I wanted to show another of these KPIs, I just have to enable it and it will show.01:11:35In the list of performance data. Where do I see these KPIs? So if I come here to my inventory, I have multiple sessions.01:11:55As I showed before, actually this is the one that I just configured. If I open it, I don't think I will have any data yet. Yeah, I don't have any data yet because it takes a while, a couple of minutes, but for the other two because I have those running for longer.01:12:06I already have data for these other two for best effort and for express forwarding. And here under performance for both, this is express forwarding, this is best effort. Here I see the list of metrics that I have enabled.01:12:26In the previous window that I show you where I had all the list of metrics, here I have, I have them shown in, in the platform.01:12:46And I get to select which metrics I want to see and in which direction. E.g., here I'm just showing under performance too delay max and delete delay P 95. Remember that what delay, what P 95 does is it removes the.01:12:54Outliers.01:13:14That's what P 95 does. And I get to compare the metrics from a single session in here in this window, so e.g., if I want to compare the delay from source to destination destination to source, I just select the metric and it will show here in the window on the, on the right.01:13:16Let's say that I also want to see the packet loss.01:13:36And in both directions from source to destination, destination to source, notice e.g. that according to the test, there is NO packet loss from destination to source, from the from there is NO packet loss from.01:13:40Here to here, but from point A to point B, there is some packet loss and I see it in here. The packet loss is shown as percentage, Notice how the other one is showing zero. The deal, I see the delay for source to destination, destination to source.01:14:00And so this is for best effort, and what do I expect with express forwarding? I expect a a better condition. So notice how this actually helps me prove that's the case. This is express forwarding and traffic.01:14:18Notice how the delay values are lower than for best effort. Notice the value for best effort. It is across, well at this point that I'm selecting 90 milliseconds.01:14:38For express forwarding in the same direction, 1st two destination where express forwarding, notice that the delay is lower, right? So I get to see the data in this window, again, selecting the metrics that I'm that are of interest to me I get to.01:14:54To play which data I want to see. E.g., I've shown delay packet loss, I also, let's see jitter, and let's also select jitter for the other one.01:15:14Jitter, so jitter for best effort and yeah notice also this, this jitter for a best effort I have higher jitter values for.01:15:26Express express forwarding I have lower jitter values. And let's go back to the other session here, shares forwarding. I'm starting to see some data points.01:15:43Because the test just started now while you were here with me in the session. Let me move the time frame in PCA because this is by default showing me the past data over the past 8 h because this is a test that I started just now. Let me put this in 1 h.01:15:59Okay, and I see data in here and I will talk about, I will introduce a feature that very likely maybe you've seen before. Let's say that I want this data to start showing faster because I'm in a rush, I implemented the test and I I.01:16:20I have NO time, extra time to wait until this start to show data.01:16:40So here under performance, if I click live ingested data, what it will do is it will start to show me data as it comes into the platform. This is its purpose is only if you're e.g. troubleshooting and you configure a test, then you want.01:16:46To receive the data right away and start seeing it, then you click here, you come under performance live ingested data, and then this graph will start to show data as quickly as it comes into the platform. Data is being collected every.01:17:0630 s in the platform, so you will start to see it right away. So notice how it's now starting to show more data points in in here. So it is not recommended to have this.01:17:24Always on. It's only on the certain specific scenarios because, once you disable it, it will go back as before and frequently not necessarily.01:17:43Something that you have to always have on because as a test continues, data will start to show here in in in the platform. And I want to show also something here in the platform. This is a test that I configured before.01:18:00Yesterday or the day before yesterday, so it's been running for a while. I have data for a sustained period of time and during my presentation during the PowerPoint presentation, I said that with cross work assurance or with assurance, we want to.01:18:19Make to see data when we need it. Because what happened, I mentioned this scenario a couple of times, what happens when an issue starts or it happens at 03:00 a.m.. In the morning? It is an intermittent.01:18:36Problem that you don't discover until hours later. If you were running passive monitoring and if you only had or maybe not even passive monitoring, if you didn't have any type of assurance within your network, how do you investigate an issue that happened hours.01:18:51Goal.01:19:11When there's NO data, it's very difficult on this there is a log in the device itself unless there's clear errors in the device itself in the interface of the device that you're troubleshooting. It's very difficult to troubleshoot an issue that happened hours ago and you didn't know.01:19:12Until hours later. With Crosswork assurance, you're able to investigate data.01:19:32Whenever you want it, because let's say that the issue happened at 03:00 A.M. in the morning. So here around this time, I get to choose the data from this time and see if something happened in my data at that point in time.01:19:39And I can see any of the metrics that were collected. Such as e.g. delay, jitter, and I get to see if there was anything at 03:00 A.M. in the morning that might have been.01:19:58That might have been given me a clue whether this device is the root cause of the issue or not because with cross work assurance, I'm able to investigate the data when I need it. So this is a.01:20:13This is one of the key advantages of having a cross work assurance solution. And so that's it for the the demo. I just wanted to show how to configure a session.01:20:28As you saw is not complex, and just to summarize what we needed was an actuator sensor placed at any point, a reflectory, the reflector can be a sensor as well, but it can be any device.01:20:45Guys capable of reflecting.01:21:04Traffic, and then you get to define the, the, the nature of the traffic. If if the traffic that you're going to be testing should have any, any characteristics such as packet size or QoS marking, you configure the session and.01:21:07As work assurance, you start the session and the session starts to run 2047. This is an active monitoring session injecting active active injecting probe traffic into the network.01:21:26E one traffic. And to finish the presentation, I have a couple of resources here and I mentioned last year similar sessions were delivered by my teammates and one of those sessions.01:21:43They discussed the two elements that I will not be covering in the presentations, which are the network orchestrator and the sensor control. Those two elements they come into the picture if you are using hardware.01:22:02Sensories. So if you want to know more about those elements, feel free to watch the recording from the the session that was delivered last year. And remember, PCA has been renamed as Crosswork assurance. So if you go to the documentation for cross for PCA, you will see now.01:22:19Those work assurance.01:22:39Everywhere. And with that question here in the chat before we close, if could you please share the links that you presented in the presentation? Here I put only the community page, so this community page that I, that is here in the chat.01:22:41Will be the recordings of this specific series together with the registration link. So feel free to share within your organization to increase the impact, right, of this knowledge sharing. For the previous one, Marcus helped me to, ok, we have them. That is the link from the.01:23:01We use community page where we had other expert series. Let me see if I can open just to verify, give me a second. Okay. Yes, that's the correct link. Perfect. So that is the link for 2nd.01:23:212nd 2nd, the previous expert series regarding PCA. Yes, yeah. All right. And, in the next session I will be covering the analytics platform, a deep dive into the platform and.01:23:41Feel free to forward the invitation to anyone you think, this might be of interest. I don't know if there are any questions just to use the remaining minutes of the session, but if.01:23:58There's are NO further questions, that would be it from our end. Okay, thank you Marcus, I see the the chat is clean, I know we have NO more questions. Just a quick reminder for the people that is connected. At the moment you will have a survey after the session. Please help us to answer.01:24:15That will, that will be very useful for us to gather information and and to see what you think about this, this content that we are bringing to you, right? So thank you very much everyone for your attending Derek and Jan. Thank you also very much for being here and supporting and see you next week. Thank you Marcus. Next week.01:24:34Okay. Bye here everyone.01:24:54