Mastering Traffic Control with SD-WAN Policies

Oh, we'll go ahead and get started guys. Thanks for joining today. Welcome today to today's expert insight series session.00:00The topic we'll be covering today is gonna be mastering traffic controls or mastering traffic control with SD WAN policy. Over the next hour, we're going to take a deeper look at how policy works in Cisco Catalyst SD WAN with a focus on how you can use centralized policy.00:19Policy groups and the new UX two.O workflow to better control traffic across your network. The goal of this session is not just to show you where things are in the dashboard, but to help you understand how the policy architecture works. Why Cisco made the changes in the newer UX two.O and how you can design policies that scale.00:37In real environments. Today we'll walk through the concepts step by step, look at the difference between the older and newer workflows and then go through some configuration examples along the way. And with that we'll get started. Alright, so before we continue, I also wanted to highlight a couple of.00:58A couple of the upcoming sessions in the expert insight series. These sessions go into other areas of the catalyst SD WAN, including monitoring, troubleshooting.01:18And cloud on ramp for SAS multi cloud access. If today's topic is really useful to you, then I definitely recommend attending these as well since they build on the same concepts and go into more operational and design focused workflows. You can register you can register through the same portal where you, where you joined this session.01:27Just a quick introduction of the presenters for today. My name is Ryan Wilmer. I'm a customer success specialist focused on SD WAN, a little bit about bit about my background. I've been working at in the enterprise network.01:49And enterprise networking for a little over eight years and I spent a few years in SD WAN tech supporting real customer deployments and troubleshooting complex issues. Because of that experience, a lot of what we'll walk, we'll talk about today comes from real world scenarios, not just documentation.02:04I'm also CCMP and CSD WAN certified and my focus now is helping customers understand how to use policy templates in the newer UX two Dotto workflow more effectively. I also have my colleague Nestor Rayes here today. I'm gonna give him a chance to introduce himself. Hey team, well my name is like Ryan I am.02:20Customer success specialist here at Cisco have a little bit more than 13 years of experience on the field holding the CCIE certification plus the SD WAN certified specialty which enabled me to cover the topics on today's session. Awesome. Thank you, Esther.02:40Let's start by looking at the agenda for today's session. We'll begin with a quick overview of the SD WAN policy to set the foundation for the rest of the discussion. From there, we'll compare the UX one.O and UX two.O policy workflows since the newer interface changes how policies are created and managed.02:59Next, we'll go into policy groups followed by application priority and SLA configuration, which are used to control how traffic is steered across the fabric. Finally we'll look at topology policies where we can define how sites communicate with each other and control the overall traffic.03:16Flow in SD WAN network. By the end of this session, you should have a clear understanding of how these pieces fit together and how they are used when building as policies in SD WAN. Here will be a high level overview of SD WAN policy before we look at the UI or configuration steps, it's important to understand what policy actually does.03:33In the SD WAN architecture, policy is what allows you to control how traffic flows across the overlay network instead of relying on only on traditional routing decisions. This includes things like selecting which WAN path to use, controlling topology, segmenting traffic, and enforcing performance requirements.03:51Once we understand the role policy plays in the architecture, the rest of the configuration workflow makes a lot more sense. Alright, so what do we mean when we say SD WAN policy? Policy defines how traffic should behave across the overlay network. It allows centralized control of routing, forwarding, and segmentation instead of.04:10Configuring each device individually.04:30Policy can influence both the control plane which determines routing decisions and the data plane which determines how traffic is forwarded. All of the, all of this is configured centrally on the controllers and then pushed out to the edge devices. The key idea here is that policy lets you express intent.04:33You define what you want the network to do and SD WAN enforces it across the fabric. This diagram shows where policy fits in the SD WAN architecture. On the left side, we have centralized policies which are configured in Catalyst manager.04:50And typically enforced through the vsmarts, aka, the controllers, which are now refer right. These are, these are referenced as the controllers now in the new naming scheme. These include things like control policy, data policy, and application aware routing. On the right side, we have localized policies which are applied directly on the edge devices and control things like routing proto.05:06Calls ACL and QoS.05:26The important point is that centralized policy controls behavior across the entire fabric while a localized policy affects individual devices. Understanding this difference is important because the configuration workflow depends on which type of policy you are using. To understand centralized policy, it helps to think about it as being built from a few basic building.05:29Blocks. 1st we have lists or groups of interests such as prefix.05:49Sites VPNs, colors or SLAs classes. Next, we define the policy itself, which describes what should happen when traffic matches certain conditions. Finally, we apply the policy to specific locations using site lists or device groups, and all centralized policies are configured in catalyst manager. And depending on the type, it may.05:54Maybe be enforced by the controller or by the edge device. Once you understand these three pieces, groups of interests, policy definition, and policy application, the rest of the policy workflow becomes much easier to follow. Centralized policy is one of the main reasons SD WAN is more flexible than traditional WAN designs.06:14Instead of configuring each router individually, you can control traffic behavior across the entire fabric from one place. This makes it much easier to deploy consistent routing, enforcing performance requirements and managing larger environments. It also enables advanced features like application where routing, traffic engineering, and segmentation.06:33As the networks grow, centralized policy becomes more and more important because it allows you to scale without increasing complexity. There are several common use cases where centralized policy is used. Traffic engineering allows you to control which WAN transport is used for different types of traffic.06:53Application where routing lets the system automatically choose the best path based on performance for applications. Segmentation allows you to isolate traffic using VPNs for security or compliance. Topology control lets you design hub and spoke full mesh or custom overlay designs.07:11And performance optimization ensures that important applications meet their SLA requirements. Most real deployments use a combina combination of these rather than just one. So to summarize what policy allows you to do, it gives you very fine control over how traffic moves through the network.07:28You can steer traffic based on performance, pin applications to specific paths, block or allow traffic, and control overlay topology. You can also apply QoS actions like policing, shaping, marking, and queuing. And you can control whether traffic stays in the overlay or breaks out to the underlay.07:47All of these capabilities come from the same policy framework, which is why understanding the architecture is so important before we move into configuration. Next we're going to look at the differences between the UX one Dotto workflow and the newer UX two Dotto model.08:06If you work with Catalyst SD WAN for a while, you probably remember the old older template based workflow which relied heavily on device templates and policy attachments. If the newer, the newer UX two Dotto interface introduces a different approach that uses groups, workflows, and guided configuration to make policy deployments easier to manage.08:23Especially in larger environments. Understanding this change is important because the way policies are built and applied in catalyst Manager is different than it used to be. Starting with the version twenty.six, the catalyst SD WAN GUI began moving forward.08:41With the newer UX two Dotto workflow. The goal of these changes was to make the interface more intuitive and easier to use for day to day operations. Cisco introduced things like workflow libraries, improved monitoring reviews, tagging, topology visualization.08:56Customizable dashboards and reporting enhancements. One of the biggest change changes for configuration was the introduction of co configuration groups and policy groups, which allow settings to be reused and applied more consistently across devices. These changes were designed to make large deployments easier to manage without increasing complexity.09:12This slide shows how the look and feel of the interface has changed over time. Older versions of the interface were more template driven and required navigating through multiple menus to configure policy. The newer catalyst manager UI introduces a more workflow based layout or configuration, monitoring, analytics, and policy are organized in a more logical way.09:33This makes it easier to find features especially for users who are not working in the system every day. The goal here was not just a visual update, but a change in how configuration is organized and applied. Cisco was making an effort to unify the look and feel across its product portfolio.09:53This includes SD WAN. With UX two dotto, Cisco moved towards a workflow based configuration model that guides the users step by step and provides recommended defaults. Devices can now be grouped based on roles or functions which allow configurations to be reused across different device types.10:12Another improvement is that changes can be staged in catalyst Manager without having to immediately deploy them, which gives more flexibility during maintenance windows. Policies can also be deployed selectively to specific sites or regions instead of affecting the entire network. Overall, the new model makes troubleshooting easier, improves visibility and allows dashboard.10:28As and reports to be customized for different operational needs.10:48One of the bigger changes from UX two.oh is the move from device templates to configuration groups and policy groups. In UX one.o, most configuration and local policy deployment was tied directly to device templates. In the new UX two dotto, configuration groups allow the configuration to be shared across multiple devices.10:55And policy groups allows allow traffic policies to be managed separately from device configuration. These two pieces are linked together, but they don't have to be managed in the same place. This makes the deployment model more flexible and scalable, especially in large environments with many different device types.11:13It also simplifies policy management because you don't need to modify templates every time you need to change the policy behavior. This example here shows why the newer workflow is more efficient. In the older UX one.O model, making a change often required copying policies, modifying lists, updating templates, and redeploying multiple times.11:31In some cases a simple change required many different steps. With the UX two dotto, the same change can be usually be done by updating the policy group or configuration group and deploying it to the desired sites. Because policy and configuration are separated, you don't need to rebuild everything just to make a small change.11:51This reduce, this reduces the number of steps and lowers the risk of mistakes and makes large scale deployments much easier to manage. E.g., here we need to deploy a new custom application to 400 branch sites. This would normally take around 16 actions, but with the new model, it will only take us three.12:09This diagram shows the difference in how the architecture works between UX one.O and UX two.o. On the left side, in the older model localized policies were closely tied to device templates which made changes more rigid. On the right side, the UX two.O configuration groups.12:28Handle localized device policies, i. E. Acls, QoS route maps while policy groups handle policy features like security, application priority, and traffic control. Application SLA and security policies can all be managed inside policy groups and then apply to the appropriate devices within a configuration group.12:46This separation makes the system more modular and easier to scale especially when you have many sites or different device rules. Now we're going to move into one of the biggest changes in the newer catalyst SD WAN workflow, which is policy groups. Policy groups are part of the UX two.O configuration model.13:06And they change how policies are created organized, and deployed. Instead of attaching local localized policies directly to templates or configuring all traffic policies within one workflow, we now have group policy settings together and apply them in a more modular way.13:23Understanding policy groups is important because most policy configuration and newer catalyst manager interface happens here. Policy groups are the new way of configuring the policies, as we said before. A policy group is a logical grouping of different policy settings and parameters that can be managed together.13:38One advantage is that change one one advantage is that changes can be edited and saved immediately deploying them to devices, which makes it easier to stage updates. You can start with basic layout using default values or switch to the advanced layout if you need full control of parameters like SLA classes QA.13:57Test maps or match action rules. There is also a preview CLI option which allows you to see the generated configuration before deployment. Another useful feature is that policy groups can be exported and imported between catalyst manager instances which help the standardi standardization across different overlay environments.14:17Policy groups are the only, are only available starting with specific software versions. On the device side, support starts with the iOS XE catalyst SD WAN release seventeen.8.1A On the management side, support starts with catalyst SD WAN manager release 20 tw twenty.twelve.one.14:38There are also a couple of important requirements. To deploy a policy group to a device, that that device must be managed using a configuration group and controllers still need to be attached to a device or CLI template because policy groups do not replace templates for controllers. In the newer interface, there is an option to deploy.14:56A policy group or configuration group using guide guided workflow. The workflow approach is designed to guide the users step by step instead of requiring you to manually navigate through multiple menus. This makes configuration process easier and especially in larger deployments.15:15Before policy groups were introduced, controlled policy configuration were was organized differently. In the older UX one.O model, we had centralized policy, localized policy and security policy all managed separately. Policies were built using separate custom options which were then associated with with respect.15:34With their respective policies. From that point, they were deployed via catalyst manager. This worked, but it could become complicated especially when making changes across many devices. In UX two dotto, policy configuration is more modular.15:53Instead of building everything within the centralized policy template, policies are grouped into categories like application priority and SLA, firewall and security, secure internet gateway, and DNS security. These policy sections are managed inside policy groups and then apply to those selected devices.16:10This separation makes the system easier to scale and easier to maintain. A policy group contains several different types of policy sections. These include application priority and SLA which control the traffic policy decisions and QoS.16:28There's embedded security features such as firewall, IPS, and URL filtering, secure internet gateway integrations like umbrella or SSE and DNS security policies. Not every policy group needs all these, but all, but they all can be managed in one place.16:44We will cover the security topics in a separate dedicated section. In the older model localized policies were configured separately from centralized policies. These included things like local control policies, local data policies, otherwise like QoS ACL and route maps.17:00These policies were created in the localized localized policy section and then assigned to a device template weren't being applied to the device. This separation is important to understand because UX two Dotto changes where these settings are located. In UX two.O.17:20Localized policies did not disappear, but they were moved. Things like route policy ACLs, and QoS are NO longer configured in the old localized policy section. Instead, most of these settings are now part of configuration groups within their respective configuration profiles.17:39Configuration groups handle device level settings and policy groups handle the policy behavior. So the functionality is still there, but the workflow in the GUI has changed. If you look inside the menu for policy groups, you will notice that there is NO section for localized policies.17:56Most of those configurations are now found under configuration groups within the their respective profiles. This is one of the main differences that can confuse users when moving from UX one.O to UX two.o. Lists and object objects via custom options that use used to exist in localized policies.18:13Are now part of the policy profile instead of configuration groups. You can find these under configuration, then navigate to configuration groups, and then you'll see the policy profile. Under the policy profile from within the configuration groups, you can find the different objects.18:33That will be used for local localized policies. These objects are then referenced within the system transport or service profiles. There's only one policy profile which defines the local policy objects that can be used within a configuration group. You can however copy the objects themselves and reuse and edit what is needed.18:53Route policies are also configured differently in UX two dotto. Instead of being part of localized policy, they are now configured inside the transport and service profiles within a configuration group. From there we need to add the routing protocol feature to the VPN feature and select the plus icon to the right.19:16To the right to add our route policy. Any specific route policy fields that are not available in the route policy feature can be added via a CLI add on profile. So again, the feature didn't go away, it just moved into the new configuration model.19:36Access control lists follow the same pattern. They are now configured inside a transport or service profile within the configuration group. You can usually find them with the Ethernet interface feature by clicking on the plus icon to the right and adding your predefined ACL from the policy profile objects.19:53Or by creating a new ACL. This is another example of how UX two.O moves moves device level configuration into configuration groups while policy groups handle higher level policy behavior. Before we move fully into the policy groups demo, we're gonna, it's important to understand.20:10And how migration works.20:30If you already have a UX one.O centralized policy configured. When moving to policy groups, the 1st step is to create the required policy components. These components can be created manually or you can use the built in conversion tool located in your self service portal to help you migrate existing UX one.O policy configuration to the new UX two.O.20:32Next you would create the policy group itself and associate those components to the group. After that, the site IDs that were previously referenced in the UX one.O centralized policy need to be moved from the site lists that were used by the apple where routing or data policies.20:52This step is important because the devices cannot be controlled by both the old policy model and the policy group model at the same time. Once the configuration is ready, the devices are associated to policy group and the policy policy group is then saved and then deployed to the selected devices.21:09One important note here, when the new policy is pushed, the manager sends updated configuration to the controllers, otherwise known as this vsmarts, which can tempora temporarily remove active policy instructions from the WAN edge. Because of that, there is a possibility of unintended traffic flow changes during my during the migration.21:25So this process should always be done carefully and preferably during a maintenance window. At this point in the presentation, I would like to hand things off to my colleague Nester, who will walk us through some of the concepts in the lab. Right, thanks so much.21:45Ryan for covering those specific concepts that it was is gonna be something that we will use on the, on today's demo. So I wanna share my screen. So, I would like to deep dive into specific elements and objects required for these policies. We will compare the key.22:03Components so you will get confidence on configuring them regardless of which interface you are using, whether you are in the UX or on the two.oh interface, remember that the operational results will be exactly the same.22:22So let us start by reviewing the every element inside of the group of interests in the UX one.O and comparing those to the UX two.o. So remember that the classical or or the UX one.O policies are usually find under configuration and then you go.22:38To classic and inside of the classic you will see this button here which says policies.22:58It's gonna take you to this to the same classic look and feel of the Cisco SD one and where you have a separate tab for centralized and localized policy. Inside of this one, you will actually see you are already familiar with the custom auctions button where it actually is going to.23:04List all the elements that are required for the either the centralized or for the localized policy. So we're going to start reviewing the elements of the centralized policy to compare them and to do a real time comparison with the US to the to the raw locations. So let's start with the list.23:25Well, if we click on the custom option list on centralized, it's gonna take you to this screen where you will see basic elements like application lists, communication list and data prefix list, all these elements that we are already familiar with. This is in the UI Now let's see how where.23:44To find those on the UI. So, but 1st, go to configuration and inside of the configuration you will see a tab that says policy groups.24:03So we click on that one and it's gonna redirect you to this one. On this one, you will actually see a button that says group of interests instead of the custom option button. By clicking on this one, it's going to actually show you the same list that we saw well kind of the same. It's not exactly the same because there are so.24:14On minor changes difference like the forwarding class that wasn't before in the UI one.O.24:34But I would say that the majority of elements that you were already familiar with on the UX one.O is gonna appear here on this list. So, this is where you find the one that two.o, list of for the centralized policy.24:40Now, be aware that on this one, notice that we have a separate tab for security, ok? By clicking on this one, it's going to actually list all the elements that are going to be related to security policies. And don't remember that in the US one.O going back to the.24:57US one.O configuration.25:17Those policies, those lists are not going to be part of the same centralized list. The location of those were on the security tab, because they were as a dedicated security tab for the policies in US one.oh and that's one main difference, and that list is actually part of the.25:20Custom options inside of the security list in EOX one.O.25:39So I click on the list and it's gonna show you again of the same list that we have on the US two.oh. Now, important to notice as well that inside of the group of interest security in the US two.oh, we also have an additional tab here inside of the group of interest to security.25:45Which is profiles.26:05You click on profiles, you will see things like advanced inspection profiles settings, URL filtering, AMP protection, TLS and SSL profiles. Those advanced configuration settings for the security team is actually part of the same security policy, but in a different.26:07Options which were which was the policy and profiles inside of the custom options.26:27So as you can see here, by clicking on this one, it's gonna actually show us the same kind of menu and the list of elements very similar that we are actually seeing on the UI. I will say that this is a kind of merge because we don't actually need to go to different two locations.26:33To actually go into all the related security elements.26:53And one important thing also to be aware of is that, if you click here on the configuration, you don't actually see a separate tab for security policies. And that is because the security policies are now going to be divided in three different profiles, which is gonna be.26:58The next generation firewall.27:17Secure internet gateway and secure service age and DNS security. Please be aware that these three different profiles are now going to be part of what we call the policy group. So you can instead, instead of having a separate policy, security policy, those are going to be what we usually call.27:20Security policy in UX one.o1 other thing also to be aware of is that either any of these three profiles are going to actually use all of the elements only on the security tab options.27:41Alright, so let's continue with the other elements in our centralized policy to see, to start seeing more difference on the configuration. So I'm gonna go back to policies and we are going to continue with our topology on the centralized.27:58I click on topology and it's gonna show us now the the look and feel and the UX one.O for the topology, which we actually have two sessions which were was topology and VPN membership, and inside of the topology, we were given by three options which.28:15Mesh and custom control.28:36Now, let's review where are those now located in the US to two point oh look and feel. So if you go to configuration and you have a dedicated tab for topology and inside of this topology tab, the 1st things that you will notice is that.28:38There is not VPN membership anymore. And that is because this VPN membership is now gonna be part of our configuration groups and our policy groups. So there is NO actual need to have a separate tab for the VPN membership anymore.28:56And it's gonna be a more simple approach, which is just going to configure only the, the topology related stuff on here. One thing to notice as well is that whenever you do a push of that topology, it's going to actually just affect.29:12The configuration of your SD WAN controllers. And that is because the topology is actually intended to be used to affect what is actually being advertised by the SD WAN controllers and know they they don't need to have any relationship.29:29With your branch configuration devices. Now, let's review deeper on this one, which options we have inside of the topology profile on in in the US two point oh and you will notice that.29:47You were actually having the same three options that we saw on the US one.O configuration, which are hubspoke mesh and custom. So basically, there are not too many difference I will say on this one, despite with the fact of that we don't actually have there this dedicated VPN membership tab.30:02Now, let's move on with the other elements of the centralized, which is the traffic policy. While on the traffic policy, we have three different elements of sections which are application aware routing, traffic data, and the sea floating.30:23Where I would say that this one you will see a big difference on the US two point oh and and that's because those are going to be part of a same element. So let's let's take a look about where to find those on the US two point oh.30:41So on the US two point oh, you will actually find it on side of the policy groups definition. There is a dedicated profile which is the application priority and SLA, and inside of this one, is where you you will actually define all the settings for your application and we're routing.30:56For your traffic data and also for the C flow deconfiguration. In general, I would say that this is gonna be more an inline approach in the sense that if you require to configure any traffic data, you will do it here more natural without needs to have a separate element define it and then to invoke it in a.31:16On other location, what we usually do on the UX one.o. On here is gonna be a more natural in the sense that you just need to configure whatever is making sense or is needed on that specific requirement or in your infrastructure. So in this case, we were actually configured out to.31:36Application policy. I'm not gonna give dive on this one because it's gonna be part of 2nd demo, but I wanted to show you that once you start to define AIR elements, you will actually see that that summary of the SLA classes are going to be part of this tab.31:57Because there is a dedicated tab to actually show you what is the configuration of those class SLA class that are part of your application aware routing policy, and also you will have here a similar tab for the QoS and Q and queue.32:15That are going to dive deep on this one once we go on the localized and also for the seaboard, that part is actually inside of the additional settings button where you were given by the two toggle buttons to enable application visibility or disable it and be aware that at least for the.32:30This specific setting, you need to enable it globally under configuration network hierarchy.32:50Where you will specify the collector servers if any, and you will need to enable the C flow D as well for your entire topology if needed or for any specific site or location if you want to do it in that way. Alright.32:56So, this is for, the, this part of the centralized. I think that we have covered the centralized elements, so let's continue with the localized, but I want to mention something that Ryan already mentioned during the presentation, which was that there is NO such concept of.33:12Localized policy.33:32And this specific concept doesn't exist anymore on the US two.oh. Instead of that the elements are now integrated into different parts of the policy groups and configuration groups. So I'm going to deep dive on those to actually show you where those elements located because that's.33:33It sometimes it's a little bit confusing.33:53And most of the people will now gain better, but once they start to using the configuration groups and the policy groups, you will see that the the approach is not gonna be is gonna now gonna be more inline as part of the configuration and definition of those elements. So CLI, so let's just start with the.33:56CLI policy element. CLI policy is now gonna be part of inside of the UIs to do that all it's gonna be actually part of configuration groups. Remember, it's gonna be in some parts are gonna be part of configuration groups, some elements are now gonna be part of the policy group. So this one in a specific is gonna be part of configuration group.34:16And inside of the configuration group, you will see something called CLI add on profile. On those, this is actually an element where you define actually all the CLI commands for a given router for a given device, right? And.34:36I will I believe that this one is already familiar with you. The only thing that I wanted to mention here is that this CLI add on profile is actually intended to cover the use case on the clis under the clis policy on localized and also on the clis policy on centralized. So you don't actually need to have.34:53Are now separate elements for both is gonna be just in one single place. Now, let's talk about the list.35:13On the localized policy. So this actual list, the location where you will find it on the US to the row is gonna be on configurations and now you will have a dedicated out for policy profile, and inside this policy profile, once you define it.35:21You will get a menu like this where by clicking on the plus add new feature button, you will get the same list that we're given on the, on the localized policies list. As you can see here, you see elements like classmats, poly search.35:38Which are usually part of the localized policy. So be aware about it. Usually also one way thing to remember to to be aware of is that, and by default you will always have a default policy object profile created, which is going to basically carry over all.35:57All those policy elements that are going to be used.36:17For your configuration groups and for your policy groups, so be aware about it. Now, moving on, we also have the forwarding class and QoS by clicking on this one, it's going to take you to the definition elements of your regular forwarding class QoS maps.36:20And I just want to open this one to actually show you where we're there. Remember, this is the settings related to QoS configuration where you define things like the scheduling type, grouping time, the scheme, the forwarding class names and the respective action of those.36:40So where to find those settings on the US two.oh? Well, those are now going to be part of what we call on the policy groups and application priority and SLA, and I'm gonna use this one which has some QoS definition on it. So I'm gonna click on edit.36:57To actually show you where are those definitions now on the US to draw. So this element, this policy in a specific has some configuration for internet to use for 40 classes and QoS, and remember like I said before, that's once you start to define things on here, he's gonna actually.37:16Really show you a quick, a kind of summary view about the different working classes with the respecting values and settings.37:36And inside of this one you will get more or less the same settings that you were actually defining on your localized policy, the dropping scheme, the scheduling type. You can either also define the QoS interface and the policy map and the queuing module that can be used of.37:43Well, for that specific interface four queue five queues or the number of queues that you need.38:03You can find all of these settings on here. Okay, so moving on the localized, we are going to on the access control list and road policy list, which are the remaining two objects on inside of the localized policy. Well, I'm gonna use I'm gonna combine.38:09These two in the same in the same example to actually show you where are those located. But remember.38:29In in the past, we usually define those settings aside of the config of the templates and now and you actually just on the device template you just invoke that localized policy in order to be able to use those elements that were defined on these policies.38:37Now, the approach on the US to do is a game changer because you don't actually need to define those things aside of the template configuration is gonna be one more inline approach whenever you are configuring to the things are going to actually providing that option to configure those elements. So I'm going to actually.38:57Show you right now and that configuration is part of the configuration groups.39:17And, that elements like the grouping policies and, and also the the ACLs are usually part of the VPNs, either the transport VPNs or also the service VPNs.39:23So, instead of just configuring stuff under the under the transport under the VPNs itself, I just gonna show you very quickly where are those? So I'm gonna click on the service profile.39:39Gonna click on three buttons here and it's gonna actually give us the configuration for that service profile where we define the settings for that VPN. And in the case for the routing policy, e.g., as Ryan also mentioned show us in a slide.39:55It's gonna be part of the of that inside of the routing protocol which in this case is WESPF, you will actually see the route policy option coming from. Now, be aware that you cannot even define in the global VPN configuration.40:12Shareable feature which is can be the road policy because the road policy can use can be reused any in other routing protocol definition or in any other location on inside of the VPN configuration.40:29So that's, that's a kind of older option to see the role policy configuration. When it comes to the ACLs, remember that the ACLs are usually used whenever we're doing QoS. So, and that is part of the usual part of the interface configuration. So you click on the plus button inside of I.40:43Interface, you will actually see the ACL option IP four and IP six because it's now part of the interface. Like I told you, this is a game changer because it's now inside of an inline on the configuration definition for your configuration profiles or your feature profiles.41:03Now, I feel that we have covered the comparison. I just want to do a quick exercise to actually show you I'm wrapping up all the elements and concepts and to actually show you how easy it is to actually push a policy group configuration.41:21Before actually jumping into that, I wanted to just remember one specific thing that was mentioned earlier, which is remember if you already have a policy in UIs one.O applied to your devices.41:36On this case I have this per service VPN topologies and also I just created a copy of that one, to just I cannot making sure that it's gonna be applied just for the branch one, ok? So, remember that the approach to.41:52Be able to use or to migrate from US one.O to the two.O, you need to make sure that the site that is gonna be where you are intended to our planning to apply US two.O configuration should be exclude.42:12From the policy, the regular classical UX one.O policy. So in this case, I am applying this policy we're applying for all the branches, ok? So, the idea is to make a copy about that one.42:27And in that copy and then just instead of including all the branches I'm just affecting the branch one so I can start the migration with the branch two or branch three if necessary. Alright, so I'm gonna do the exercise.42:43So you go to configuration, then to policy groups, and then I'm going to push this policy group configuration. This says the menu for the policy group configuration where you will actually need just to use this drop list in order to select their correspect the corresponding.42:59Profiles that you work already defined. As you see here all of them are optional. I mean if you don't have a application priority on this profile on this policy group, that's fine. You don't have a next generation firewall on this one, you don't actually need to to select one. It's.43:21Completely optional because that's the beauty about the policy groups.43:40Everything here as as the classical is is completely optional. You don't actually need to carry over all the information at once. And the other thing about one the difference and I will say that the one the key difference is that you can actually select.43:45We're gonna be those associated devices in this case I'm going to select one, the branch one. I'm going to associate this guy, and it's gonna actually ask you if you want to provision the configuration of these devices and that's something that is gonna be just.44:02Available for the US to the option to do this provisioning push later on on time. If you want to do it in a specific maintenance window, you can actually do it. In our case, we are going to do it now because we have a lab and the time is running and.44:20I'm going to actually deploy it and you can monitor the status of that deployment going by checking on the build deployment status push. With that, I think that we can going back to Brian, thanks so much team for to show this demo.44:36Thanks Nestar. I really appreciate that. It was super helpful there to kind of see the concepts coming together in the lab. We'll be touching on some more of these topics as well in the next section just to to just to hit it home and, and, and go dive a little deeper here so.44:55With that we were gonna review the application priority and SLA. This, this is one of the core traffic engineering features in a Cisco Catalyst SD WAN and it allows the fabric to make intelligent forwarding decisions based on real time path.45:13Performance. Instead of simply sending traffic over a preferred instead of simply sending traffic over a static preferred path, the vanage can dynamically choose the best transport based on SLA metrics. Understanding these concepts is important because the application priority and SLA is the foundation.45:28For the configuring AAR and traffic policies that are configured inside policy groups. So in this section we'll focus on how to define SLA requirements for applications.45:49And how to control path selection and behavior using policy groups. As mentioned previously, right, the application priority section of policy groups is now responsible for defining the traffic rules. This includes appleware routing, which controls path selection based on those SLA metrics.45:58And at the same time data policy which can match and match and manipulate traffic within the fabric is also included in this section. As Nestor showed in the lab as well, and we'll show in the next couple of slides C flow D is also a part of this workflow which provides traffic statistics and visibility.46:19Once these policies are defined and deployed, then at that point they are distributed through the controllers AKAV smarts to the WAN edge devices. So this section of policy is where we control how traffic is actually steered across the environment.46:38Application aware routing allows the WAN edge to use multiple transport transports in an intelligent way. Instead of just active active forwarding, the device continuously measures performance across all available tunnels. These measurements include latency, jitter, and packet loss.46:54We then define SLA thresholds in the application priority section, which the router will then use to identify paths that meet those requirements. If a path NO longer meets the SLA, if the path NO longer meets the SLA, the traffic can automatically move to a better path without any manual intervention.47:11We can also define preferred paths or fallback paths depending on the application or whatever you have set in your policy. Here we can see how application route where routing works in practice. By default without any policy set.47:31SD WAN performs flow based load sharing across all transports available between the C edge routers. Each WAN edge router continuously monitors the performance of every active tunnel. E.g., we might say that an application requires latency under a hundred and 50 milliseconds and loss under 2 %. If one transport.47:48Or does not meet that requirement, the router will automatically choose another path that does.48:08Any path that is compliant to the SLA will will be an available path that the router can use for load balancing if NO other specific rules are set. This allows the network to react in real time to changing SD WAN conditions without manual changes.48:13So this slide represents the decision making process for application where routing. Now at 1st glance, this can look kinda complex, but we'll break it down step by step. Everything starts when traffic matches an application policy. Once that happens, the system checks. Is there an SLA class defined for this traffic?48:30If yes, it evaluates all available tunnels and identifies which ones meet the SLA thresholds. If multiple tunnels meet the SLA, then additional logic is applied such as preferred color path or preferred color or path selection. If NO tunnels meet the SLA, then the behavior depends on how the policy is configured.48:47If strict mode is enabled, the traffic maybe dropped. If not, it may fall back to the best past effort path. So the key takeaway here is all routing decisions are being driven by real real time SLA measurements. You're NO longer routing based on static metrics, you're routing based on actual performance.49:07To build an application aware routing policy, the 1st step is identifying the applications we care about. This can be done using L L layer three or layer four matching or using DPI signatures for application recognition, AKA n bar.49:28And once the applications are identified, we can create a traffic policy that defines the SLA requirements or and path preferences. The policy itself is building is built using matching action statements. After the traffic rules and policy groups are complete, it must be deployed so that it is pushed to the controllers and applied to the WAN edge routers.49:42When building traffic rules, the 1st step is classification. We need to define which traffics should receive special treatment or should follow a specific SLA. We can match traffic in several different ways. We can match on application lists, prefix.50:03Software as a service application list such as MS Teams, Zscaler, Webex, Cisco Webex, DNS, DSCP values, different protocols or source and destination information. This flexibly allows us to apply different routing behavior to different types of traffic depending on the.50:20Requirements. An app route policy is built using several different components as we see here, right? 1st, we define an application list which identifies the traffic we want to match. Next, we define SLA classes which specify the acceptable latency jitter and packet loss.50:40We talked about previously, then we create the app route policy itself, which defines how traffic should be handled for a given VPN or you know router. We can also enable logging if we want to see packet level information for troubleshooting.50:58These building blocks together define how application is steered across the SD WAN fabric. This is one of the most important concepts when working with centralized policy. The order of operations. Traffic is processed in a specific sequence as it enters and exits the WAN edge.51:151st local ingress policy is applied. Next, the app route policy is evaluated, which performs the SLA based path selection. Then traffic control or data policy may apply additional classification marking or service actions. After that, the router performs routing.51:32And forwarding decisions based on topology. On the transport side queuing, shaping, and scheduling are applied. And then finally, the local egress policy is enforced before traffic leaves the device. Understanding this order is critical because policy behavior depends on where in the flow the rule is applied.51:49This slide show, this slide shows how application aware routing and data policy interact when both policies match the same packet. The important thing to understand here is the guiding principle at the top. Data policy makes the final forwarding decision, but it still takes into account the SLA results from the application aware routing.52:09So when traffic arrives at the WAN edge, the device, the device 1st evaluates the app route policy to see if there's a valid path that meets the SLA requirements. If a matching else SLA path is found, the information is passed to the data policy. The data policy can then decide whether to use that path, override it or take a different.52:29Actions such as using a specific T lock.52:49If NO path, if NO valid path exists, the router evaluates backup SLA options, default SLA classes or routing decisions depending on how you have your policy configured. The key takeaway is that appleware routing determines which paths are acceptable, the data policy ultimately controls what action is taken.52:53So what do we actually mean by application priority in SLA? Well, at a high level, this is how we tell the SD WAN fabric what traffic matters most and what good performance looks like with that traffic. The question becomes how does SD WAN actually know whether our path is good or bad?53:11It comes down to three key metrics, as we spoke about before, latency jitter and packet loss are the three key ones there. Latency, as you know, a simple delay, how long traffic, how long it takes traffic to get from point A to point B Jitter is that variation and delay.53:31Which is especially important for important for real time apps like voice or video and packet loss is exactly what it sounds like. The traffic that never makes it to the destination. Now here's the important part. Every ran edge router is continuously measuring these metrics across every active tunnel.53:46MPLS, internet, LTE, all the time. This isn't an occasional testing, it's constant, and those real time measurements are compared directly against the SLA thresholds we defined earlier. So effectively every path is being scored in real time.54:04If a path meets the SLA, it's considered healthy. If it doesn't SD WAN will avoid it for that application depending on how you have your policy configured. That's what enables the intelligent path selection, not static routing, but the real time performance based decisions.54:19We understand how SD WAN defines performance. The next step is defining what acceptable performance actually looks like. We know SLA class is simply a set of thresholds for latency loss and jitter that define whether a path is usable for a specific type of application. And the key idea here is not all applications are, are created equal.54:37E.g., voice and video are very sensitive to delay in packet loss, so they require a tight SLA threshold. Transactional applications like database traffic are a bit more bit more tolerant but still need reliability. And then you have both traffic backups, file transfers or poor performance matters much less.54:56So what we do is we define different SLA profiles for each of these categories. You can use the predefined ones like voice and video or create your own custom SLA like this example here. And when SLA classes are, and these SLA classes are what AAR or application we're routing uses to evaluate every available path.55:15So when traffic matches an application, it gets tied to an SLA. And that SLA determines which paths are considered acceptable. Now that we've defined what an SLA is and what that good performance would look like for that specific application, the next logical question is.55:34How does SD WAN actually measure that in real time? And the answer is BFD bi directional forwarded detection. BFD is the lightweight protocol that runs between WAN edges and continuously sends probe packets across every tunnel. Try again. These probes allow the system to measure those three key metrics mentioned before.55:54And this has happened constantly in the background without any manual intervention. So instead of relying on static routing decisions or assumptions about path quality, SD WAN is making the decisions based on real live network conditions. That's what enables application aware routing to be dynamic and responsive.56:14BFD is doing two important jobs at the same time. 1st it determines path liveliness. In other words, it's the tunnel up or down, second it measures path quality using the BFD timers for AAR.56:35And this runs automatically inside every IPsec tunnel between WAN edges. So every tunnel between sites is constantly being tested. You don't need to configure pros manually, this is built into SD WAN. This is what gives the system the ability to detect failures very quickly, often in milliseconds instead of seconds.56:47And beyond just detecting failures, it also detect detects degradation and performance, which is just as important for application experience. So this is going over a little bit what we saw in the demo, right? And this is kind of where, what areas we go to for your reference and when we configure it in UX two dot.57:05This is all handled through application priority and SLA policies within the policy groups as showed earlier. This this simplifies what used to be a more complex policy configuration model. You can create a new policy or an existing one directly from this interface.57:26And instead of building everything manually, you're working with structured policy elements that guide you through the configuration. This makes it much easier to deploy consistent policies across multiple sites. One of the biggest improvements in the UX two.O is how policies are aligned to business intent.57:43Instead of thinking in terms of technical configurations, you're thinking in terms of application importance, gold represents business critical applications, things like voice, video or collaboration tools. These applications require strict SLA thresholds and the best possible path.58:00Silver is your default traffic standard applications that don't require strict guarantees and the bronze represents low priority or non business traffic, things like recreational background applications. These can tolerate higher latency and or packet loss. So this model allows you to quickly map business priorities to your network behavior without needing to build complex policies from.58:18Scratch. Again, this is the very basic default view of application priority and SLA whereas what next has showed earlier is a more advanced view. And we'll talk about that in this slide where, and you know, where C flowed.58:38C Fo D gets enabled here, right? C flow D provides the flow level visibility into your network traffic. It allows you to monitor which applications are being used, how much bandwidth they're consuming, and how how traffic is behaving across your network. You can enable visibility for IBV four, IBV six or both.58:55And this data can be exported to external collectors for analysis. So this isn't just about routing anymore, it's about understanding your traffic patterns and making the data driven decisions based on what you collect in the using app visibility. But the more advanced use cases, as Deskra had shown before.59:13Four right in UX two.o, we provide an advanced layout option. This allows you to define define more granular traffic policies, custom SLA classes, and more detailed QoS behavior.59:33However, there's important consideration. Once you do switch to this advanced view, you cannot revert back to the simplified view unless you try creating like a newer policy. So this is typically used in more complex environments where fine grain controls required. For most standard deployments, the default view provides you that basic SLA category conf.59:44Other configuration.01:00:04Finally, QS is fully integrated into the policy groups as showed earlier. This, this allows you to control how traffic is treated once it's on the network. You can define queuing behavior, bandwidth allocation, and prioritize act prioritization across different traffic classes.01:00:08So now you're not just deciding which which path traffic takes, you're also controlling how that traffic is handled right along with your, your QoS classes and and queues that you create. This ensures that critical applications to only take the best path, but also receive the appropriate priority and bandwidth.01:00:24Now that we've covered how SD WAN makes those intelligent routing decisions using SLA and application policies, let's shift gears slightly and talk about topology because topology defines how sites are even allowed to communicate in the 1st place. Up to this point we focused on how do we choose the best path.01:00:43Now we're answering what paths are even available between your sites. And in Cisco SD WAN, that's controlled through centralized policy and topology design. In UX two dotto, this becomes much more intuitive and workflow driven, which is what we'll talk, we'll walk through in this section.01:01:00This slide is important because it shows where the topology fits, right, and the overall policy model. Focus on the left side on the left hand side here, the topology and VPN membership are both part of the centralized control policy. This is where we define which sites can talk to each other and which VPNs they participate in.01:01:20So think of it like this. Topology defines the allowed communication paths. Traffic policy defines how the traffic behaves on those paths. And both of these are pushed essentially from be managed or AKA catalyst manager using that OMP. That's a key concept.01:01:37You're not configuring this locally on routers. You're defining intent centrally and the fabric then enforces it. And this is where UX two.O topology comes into play here. This slide shows the evolution right from UX one.O to UX two.O.01:01:53And this is where a lot of customers immediately see the benefit because in UX one auto policies were broken into separate components, topologies, lists traffic policies, and as Nestore showed, right, we saw all the different pieces that we had to navigate to for those, for those objects.01:02:11Whereas in UX two dotto, there's still those concepts still exist, but they're grouped in a way that aligns better with how people actually think about their network. E.g., topology becomes its own structured workflow. Application behavior is handled in policy groups and visibility is tied into.01:02:26The network hierarchy/C flow D function. So the big improvement here is less manual assembly, more guided configuration, and much lower chance of misconfiguration. It's not just changing what SD WAN does, it's just changing how easily we can deploy it.01:02:44Let's take a step back and talk about what centralized policy actually doing. Well at a high level centralized policy defines how traffic flows across the SD WAN overlay. Most specifically, control policy is what influences the route advertisements and path selections from vsmarts and the advertisements from those WAN edges. And then and this is.01:03:02Where topology comes into play. By using control policy, we can create different types of topologies. We can create hub and spoke, full mesh or even custom or partial mesh designs. So instead of every site talking to every other site by default, we can control exactly how sites discover each other and exchange routes.01:03:22This is especially important for security segmentation and traffic engineering. So topology is not just about connectivity, it's about the control you have. This is where UX two.O really simplifies things. Instead of manually building control policies.01:03:40You know, the, the different sections of like traffic, data and all that such, and you now have a dedicated topology workflow. This allows you to define common designs like hub and spoke or VPN membership without needing to write policy logic yourself piece by piece. Under the hood, the system is still generating control policy, but from a user's.01:03:58Perspective, you're working with a guided configuration. This reduces complexity significantly and especially for customers who are newer to SD WAN, and it also helps standardized deployments across environments. Let's talk about one of the most common topology designs and that's hub and spoke.01:04:19And this model branch sites are forced to communicate through centralized hub sites. This means NO direct branch to branch communication.01:04:39Now why would you want that? Well, in one use case, it's is to limit the amount of tunnels your branch routers are building in the network. Thus reducing the amount of hardware resources being used on the router. And because it allows you to centralize services, things like firewalls, security inspection, internet internet breakout can all happen.01:04:46And at the data center if you wanted to.01:05:05So instead of just deploying those site their services everywhere, you can kind of con concentrate them at the hub. This is very common, right? In enterprise environments, data center centric designs, and security focused architectures. The trade off is you sacrifice some direct path efficiency, but you gain control of visibility and security.01:05:07VPN membership policy is really about segmentation. It allows you to control which sites participate and which VPNs. So instead of every site having access to every VPN in your network, you can isolate traffic into separate segments.01:05:29E.g. e.g., you can segment traffic based on guest networks or IoT device network or different business units that you may have. It also limits route advertisements to all your other routers and.01:05:45And controls them within the controller, meaning only specific routes are shared with which sites you want them to be shared with. This helps enforce both security boundaries and routing boundaries. So while topology controls connectivity between sites, the VPN membership controls the connectivity within the segments of your network.01:06:01Now let's look at what this actually looks like in UX two dotto. When you configure a hub and spoke topology, you really just defining a few key concepts, right? Very simple topology policy name, you're the VPN, you're applying it to a list of hub sites and a list of spoke sites.01:06:25That's it. Behind the scenes, the systems is building the control policy and is required to enforce this behavior. So instead of writing complex route policies, you're simply defining the intent, right? These sites are hubs, these sites are spokes. This is what I want.01:06:42These are how I want my sites to communicate and the SD WAN takes fabric takes care of the rest. That's a big usability improvement, right? Compared to the UX one.O Now if you need more control, you, you can still build custom control policies. This is where you define the match conditions like routes or T.01:06:58Box and actions like accept reject or modify. This allows you to create the very granular topologies that you require, including partial mesh or highly specific routing behaviors. So the UX two dotto, gives you both options, right? Simple workflows for common designs and more advanced controls when you need them.01:07:17Most customers, right, start simple and then move to custom topologies however, you know, however they see fit or needed. Finally let's talk about migrating to new topologies, right? So just like policy groups, this is important because changes here directly impact connectivity.01:07:37The process is pretty straightforward. 1st, you're gonna create the new topology components. Second, you're gonna disassociate the old topology elements and 3rd, you're gonna activate and deploy the new configuration. So at that point, vmanage pushes the updates to the controllers and change it changes across the fabric.01:07:54This is actively modifying how your network communicates. So because of that, you always want to review your changes carefully for before deploying and especially in production environments. This is most mostly done also during maintenance windows, right? So at this point I'm gonna hand it off to Nestor to do a little bit of the demo of the top.01:08:14Apology section and some other features right that we discussed in our slides. Take it away Nester.01:08:34Alright, thanks so much, Ryan to cover those concepts. I think that we're getting to the end of the session and we wanted to make sure that you get clarity on all of those concepts that we have reviewed so far. So I want to share my screen.01:08:41Screen two, alright so I would like to start kind of commenting what we're going to review on this demo. We are going to this demo is divided in two parts. The 1st part is gonna be to.01:08:59To see a real time operation about an application our routing policy, and 2nd part is gonna be to actually push a topology policy to actually see what is going to actually happening under the policy level on the tunnels and has that respective behavior.01:09:17Is the difference.01:09:37So that's basically the intention of that second part demo. So I'm gonna start with the application aware routing one to actually show you what is, what is there, ok? So I'm gonna go to configuration, then to policy groups that as we talked earlier, we are, we are going to find the.01:09:38The application aware of the policy definition under the application priority and SLA profiles and I'm going to use this one, the VPN ten AIR, which is gonna be used in our policy group, the one that I'm going to use to push the template to the branch one.01:09:58And before to actually jumping into that, I wanted to very quick show you the topology, so you will have a better idea of what we are talking about. It's a very simple topology. I am using CML to test it out. In this case I'm going to send the apology the this policy.01:10:16To the branch 1H1, which have just two circuits, the internet circuit or this internet and also the MPLS and that's basically all. I'm going to also be generating traffic using the traffic.01:10:36Generator on here, I'm going to start sending packets through the SD WAN cloud all the way down to the DC one. So there is a host on the DC one that are going to receive those packets and those packet flows, and.01:10:56This is the actual flow scheme that I'm going to be sending. I'm going to send packets with different DSSCP values that are going to match the our application aware routing policy that we're just going to talk about it. And, that's everything on regards to the infrastructure for the lab. Now.01:11:14Now going back to the application aware policy.01:11:33Review. I'm going to open it and I'm going to actually explain all the different elements on here. So this is a regular application policy, nothing complicated, nothing fashioned at all. Very simple just to have a quick exercise.01:11:37This topolo this policy is componed by a five sequence. The 1st and the 1st sequence and the last sequence are more specific to in the sense that they are actually defined preferred color on this case e.g. for the DSSCP value.01:11:55The 46.01:12:14Which is the express forwarding one, we are actually referring the MPLS color, and as you can see here, this SLA class name is which is critical apps is giving these requirements lost 2 % like to see 50 milliseconds and.01:12:15No more than 100 milliseconds.01:12:35And on the other side, we have three other sequence which are the rule two, three and four. On these two on these three, we actually have that we are applying the priority apps SLA, which have a different set of requirements and lose 20 %.01:12:38Latency NO more than 150 milliseconds and jitter NO more than 100 milliseconds as maximum. One important thing here that is very important for the demo is that.01:12:58As you can see here, there is NO actual preferred color definition, and what is going to happen is every every color that meets this given criteria that we are defining here or the SLA number the SLA class.01:13:12Is going to be actually doing load balancing to all the circuits that meets with this criteria. If we're making some adjustments in the setup to make it one of the circuits to actually not classify on this to not be classified on these priority appsm.01:13:28Play definition. So, what is going to happen is that all the traffic is gonna fall back to a specific circuit, but we're going to see it on the on the real demo, but be aware about it. The default behavior is to actually do load balancing, at least for these three DSSCP values.01:13:48For the last one, which is not gonna be part of the demo, important just to mention here that just as an example, right? We are applying that we have a prefixer which is this internet and in case that the S internet is not available or NO, is not meeting the critical apps.01:14:05Requirements is gonna fall back to MPLS, ok? That's basically the details about these AAR policies. Now let's see how can we actually going to monitor that traffic packet exchange going.01:14:23Okay, so for that, we're going to use a helpful tool inside of the tools. There is a tool what they named network wide Path Insights, which is the we call as a NWPI. This is a very powerful tool, which actually actually help us to, be what.01:14:38Is the routing inside this issue that was taken by the router, right?01:14:58But, I wanted to just kind of show you very quick, which is the powerful details that this plan for offers and in the specific environment I wanted to show you that this is the packet flows that are being exchanged by the traffic generator.01:15:03And as you can see here, some of the packets have 41 has a DSCCP, 21, express forwarding, which is 46, and also some of them have the 31. So you can see here there has NO packets going, ok? Which is totally expected because I couldn't simulate those, but.01:15:20I think that with the packets that we have, there are around twelve packets, I think that those are more than enough to, to see what's going on. Important to notice here that at least for the two eh 31 we're doing a load balancing.01:15:39Actually, it's gonna do it load balancing for all the packets because until this moment there is NO applicing yet applied to the device. So, I will expect that perhaps to see some express forwarding packets still doing load balancing and that is totally expected at this moment because we.01:15:57Haven't yet applied the policy. Once we apply the policy, all the express forwarding packets should now come to the MPLS circuit only because that's the only one that is the the packet that is the preferred color in that.01:16:16According to the policy definition, ok? So, with NO more thoughts, I'm going to actually do a network change in the circuits so I'm going to actually, ok, but before to that sorry I'm going to push the policy 1st.01:16:30And then we are going to do the the change in the secret. So, I'm going to push the template that policing. I'm going to use this one, the SLA routing for critical apps, just gonna show you that you're gonna you push the VPN application our routing policy.01:16:49I'm going to associate that device, I wanna select the branch one, and it's actually telling me that it was applied for the default policy, which is ok and this go in this moment I want to associate it now with this policy and I'm going to provision right now.01:17:08And we are going to see at the moment where these are already applied and we start to see a change in the behavior change in the traffic packets.01:17:32Okay.01:17:52So I just gonna give you a little bit more of time for the NWPI to actually converge.01:17:59So, ok, so the express forwarding is still is is only time to MPLS, which is good. The other one is still doing both load balancing, which is totally expected at this point. So what I'm going to do is actually to make a network change in the network circuit on the internet circuit.01:18:15To make it less preferred and to actually oversease the numbers that we defined for that SLA class.01:18:35And, after applying the change, the expectation is to actually see that all the packets is now gonna be flowing through the MPLS circuit only. We just need to wait a little bit to actually the packets to be reflected on.01:18:54On the NWPI capture So far all of them are MPLS.01:19:14Which is a confirmation that the the application aware policy is actually working because we don't actually, we don't see any packet now using the base internet for any of the two classes, SLA classes.01:19:34Okay, so that confirms that it's actually working the application aware routing policy. Now, let's move on to the policy to the to 2nd demo which is topology. This one very quick, the idea here is to do a quick hawker spoke topology, but 1st I would like to show you the current states so you.01:19:53You will see the difference. So, this is a quick overview about the tunnels. As you can see here, there are some tunnels being formed and established between the branches. So in this case the branch one is established tunnel to the branch two router.01:20:13To the two branches to the routers in the branch three, because that particular location have two branches two routers. So it's gonna be three tunnels phone. What is the expectation? The expectation is that once I apply the policy, that tunnel should be down after I.01:20:28Apply the topology policy and also the traffic ponder, I'm making a trace route.01:20:48Between the branch one and the ranch two and should not take any any router inside of here or or in the middle because it's actually a direct connection between each other, ok? So I'm going to apply the topology, we are going to define it.01:20:55Only very quickly is not gonna take us too much that 2 min to define it.01:21:15So we created a topology, open spoke. We just put here open spoke, then VPN ten, we define where the those help sites, which is DC one and DC two.01:21:22We're going to define where those spoke sites which are branch one, branch two, and branch three. And you see here that you were you can have either if you have two data centers or two hubs or two pair of hubs, you can actually define a priority for those.01:21:42So I'm gonna do it just to.01:22:01I kind of make it the exercise, what it's going to do is basically to make the DC one the the main one and 2nd, the DC two as 2nd priority, so it's gonna see apply a difference in the the way that is actually going to.01:22:04Configure the routes coming. I just gonna have a preference, better preference for the ones coming from this one. And so I just need to save it. Okay, it seems that it's already there.01:22:22And we see it here, it's actually the same it's actually the same. I it's, it's exactly the same. I just wanted to show you that when we click on the custom, it's actually show you something like this.01:22:42Where you will see the better preference I can tell you for the DC one, ok? I'm gonna apply this one because we are running out of time. I just wanted to making sure that you will actually see it. So, I'm gonna apply this custom one, which is essentially the same. The only thing is that I use the custom view.01:22:59Which is a kind of a more advanced view. And as you can see here, the push is gonna happen just for the as I told you earlier, there is NO branch related configuration on this case because it's the topology policy.01:23:17We just click on deploy and, let's monitor what happened on the tunnel level on this particular branch. The expectation as I told you is to actually see does ok what happened?01:23:33Okay, so give me a second guys. So let's create a new one, sorry, very quick.01:23:50Focus back.01:24:09So I'm gonna select this and this is all branches. I just wanna use different names to make sure that we are not actually using something that was already used, so.01:24:25Branches, branch two branch three, want to save it, close it out, Activate that one.01:24:48Okay, so let's monitor the status.01:24:59So these two tunnels, these tunnels should be actually coming down. The only ones that should remain state are the ones towards the data center. So as you can see here, very quickly, the the those three tunnels start to going down.01:25:18Because this is total expected, we just expect to have T lock and tunnel established towards the DC rollers. So with that, we have finished with the two demos. Thanks so much for Washington and we can continue with Ryan to wrapping up our session of today's.01:25:34Thanks so much team. Thanks, appreciate it man. All right, just wrapping this up, guys. Just going over the such a recap. We started with the purpose of centralized policy and how it gives you control over how traffic flows across your SD WAN.01:25:52Then we compared UX one.O and UX two.O and saw how the newer workflow simplifies how policies are built and managed. We walked through the policy groups, and how they bring together the policy application SLA and traffic behavior.01:26:12We also covered how routing decisions are made using the real time performance data like latency loss and jitter. And finally, we looked at how the UX two.O simplifies large scale deployments by turning complex configurations into guided workflows. If there's one key takeaway, it's this. You're not configuring devices anymore, you're defining the intent.01:26:27For the network. And before we close, I just wanted to give you guys some resources to follow, right? These.01:26:47As we mentioned before, these slides and recording will be shared a couple weeks from now for your access. So these are all you know good links that you guys can use for references to the, to the content. Thanks for joining today guys. Really appreciate your time. Hope you took away something from it. And from that we'll we'll conclude the session and we look forward to seeing you guys in the next couple.01:26:54Of expert insight series sessions.01:27:14