Cisco SD-Access: Intelligent traffic redirection using Security Service Insertion (SSI)

Thank you everybody for joining. Good morning, good afternoon, good evening depending on where you are. We are here to talk about.00:09Security service insertion, a key capability of Cisco Catalyst Center and ICE and other components from the networking and security portfolio to talk about how Cisco can securely automate your network, right? Or how you can manage your network.00:17Work with security service insertion securely, right? We have Saravan and Mahesh on the call who will take us through. We have this session is for about 90 min.00:37We will leave the last 15 min for live question and answers. We will be sharing the slides and the recording with everybody after the session today. Very important on the right side, if you, if you're using Webex for the 1st time, maybe we would encourage all your feedback.00:48Questions through a Q and A panel, so on the right side, on the bottom.01:07If you see there are three dots, if you click there, it'll give you options of Q and A notes. So if you click on Q and A, that's the area where we want to make sure you ask your question, give us feedback, and we will try to answer all your questions right there. Any question that we are not able to answer there, we will make.01:12Make sure we answer them at the end of the call. So please use the.01:32Q and A section, not the chat section, there's another section which is called as chat, which can be also used. However, we encourage usage of the Q and A section that that's gonna be more valuable for all of us. So having said that, I think let's let's get started. Thank you for joining and over to you Mahesh and Sarah.01:38Thanks a lot Sumit, for the quick intro. Welcome everyone for today's session on security service in session. This is a capability that we are enabling on fabric deployments that comes along with catalyst center eyes and the switches like mentioned. I'm Sarvanan here, the product manager who's leading the security service insert.01:59Area and with me we have already who's.02:20Technical marketing expert I would say in this area and and without any further delay let's just quickly deep dive into this, right? So the 1st 15 20 min I'll be covering this part and then I'll handing over to Mahesh to do the deep dive and then we also have a demo available for today's session so that we will get to cover everything in the next 85 min.02:23So. So.02:43Let me start with this, right? So, network is in constant threat. We all know why, right? Because there is as technologies keeps growing and so does the threats as well, right? So if you look at it today, we are in a world where the CIOs and and the IT leaders are under tremendous pressure to.02:44Implement security measures that they have to take for.03:04Rogue AI agents that are getting deployed into their network, right? So their employees are going in installing these agents into the network without even getting approved by the netops or the secops team and that is becoming the most or the massive security vulnerability entry point for enterprise network customers.03:09That by when you have these vulnerabilities in your network, it's nothing but a taking time bomb where it can allow unauthorized access to an intruder and get as much intellectual data that they can steal from enterprise network, whatever you're governing today, right? And these rogue agents can cost more damage.03:28Needs what a typical cyber threat or attack can cause in weeks or months, right? So.03:48These agents are capable enough to cause a damage in just few minutes. So with that being said, let's just say how customers with their SD access fabric struggle today to keep up with such environment, right? Imagine you see a topology on the left, pretty much how exactly SD access customers deploy their fabric.03:55Requirements, right? They have catalyst center eyes to deliver micro segments and they go ahead and configure the secure group tags, what we call as sgts in short. So when they have to inspect any traffic going east west, it's a huge challenge for them. What I mean by that is they have to configure.04:15It's pretty much L two traffic, they have to configure the L two VN specifically and then they will extend the traffic to the L two VN and from there they have to manually send the traffic to the firewall and get that inspected and then send it back to the fabric, right? Imagine if you want to have such scenario for traffic going between different subnets, which is L three in this case.04:33Then I have to go configure extensive amount of PBR configurations throughout my fabric and then do route leaking from my border node and then send that traffic towards the firewall and bring that bring it back and then, you know, it it requires constant change as, as network demand grows, as business grows, it requires constant change.04:53In the network configurations and then as we keep doing all this manually, there are high chances that we may think that we are, we are covering everything, but we may cost whole in a lot of places, right?05:13Having said that, will I be able to cater all the traffic by having just one firewall managing multiple vns and and get that done with that? No, because customers have to think about having a2X or three X of firewall capacity so that they don't have to you know worry about any latency.05:27Challenges by having a single appliance to take care of the entire demand that is coming from the network, right? And so that puts a lot of stress on their CapEx and OpEx planning as well.05:47So if the traffic is not sent to the firewall, which means the threat surfaces as open for, for an intruder that they can move laterally without even getting undetected. So I in short, what we are saying is there is literally NO mechanism available today where I can selectively steer only the traffic that is of interest for me that I.05:57Everything should be inspected by a firewall for any of the SD access deployments today, right? With that being said, that is exactly where security service insertion comes into picture, but I don't have to worry about configuring this policies manually across everywhere in my network, right? Because the policies are tied to the secure group tags.06:17Zts, the moment there is an IPACT binding available on the switch, the switch will go ahead and request Cisco ICE for any policies that are configured and then it will immediately download those policies.06:37One thing we have to note down here is that unlike group based policy, which is egress enforced, these steering policies are ingress enforced, which means the moment the policies match with the criteria that is configured, it will immediately steer the traffic towards the firewall that is configured in the workflow. My will.06:49Give a complete demo on that where exactly we configure the firewall part and and that by what will happen is customers can quickly adjust to the thread whenever.07:10They think that the threat is moving laterally, the policies are also following because as and when there is an AZD available, the policy follows the sdts, right? So you don't have to go configure this everywhere. Once you configure it, you can just, you know, live with it for for all your network.07:19And one thing I want to highlight here is that it's vendor agnostic and what I mean by that is customers who have Cisco FTD, they have the advantage of retaining the AZD context to the FTD firewall. FTD supports AZD as a mechanism to be configured as a security policy on the firewalls. And I.07:35Other customers who, let's say customers who have Palo Alto or 3rd checkpoint or or other 3rd party firewalls, they can continue to use those firewalls to implement this feature in, in their existing hdxs fabric.07:55Which means they don't have to replace anything or spend any additional costs or you know incur any downtime. And all that they have to do is that upgrade to the minimum required version and then they will be able to set this up up and running at a minimal disruption, right? So.08:08This will allow customers to achieve zero cost incurred and close the blind spot what they have today with East west. I don't have to worry about I'm sending all my traffic to the firewall or bordering the firewall appliances.08:24I can do right size of firewall enhancement because I'm sending only the required traffic and then I don't have to always worry about doing a trade off between security and scalability part, right? I can achieve both at lower cost and zero disruption.08:42And with that being said, let me quickly flash some of the capabilities what we are bringing in for this initial phase of the launch. On the left, we have the features support that is coming in. The initial phase of support will provide ability to steer traffic going within a VN, but between two different subnets or between two different SGT.08:57These.09:17I can steer that traffic towards the firewall. At the same time, if I have any traffic that is going out of my fabric towards internet or data center, I can also configure steering policies for me to inspect that traffic through the steering policies. In this case, the orchestration is done by catalyst center, wherein the entire automatic.09:18As well as the policy workflow will reside on catalyst center and that way it requires the catalyst center to be the read write engine. In the future, we are also exploring to see if we can bring in the Cisco ICE as well as a read write engine pending to be roadmapped and prioritized.09:38Like I said in the previous slide, we also support this capability with Cisco as well as any non Cisco firewalls. And to start with, with 17 eighteen.one or later releases, we, we have the capability available on catalyst 9300 to all the way up to 9600 soup one platform. The support for catalyst.09:55The 290 200 CX is getting planned and and delivered in 20 six.two.one iOS six release targeted for August or September this year. And, and in terms of appliances when it comes to the center we support this with DN two or above or even the virtual appliance form factors.10:15Starting from catalyst center three.one.six or later version onwards, and this requires a specific version on Cisco ICE primarily for the factor that there is going to be a specific matrix that we create whenever we deploy security service in session at a particular site level.10:32And this matrix will be not at the global scope but at a side scope. Those implementation changes on the ICE were brought in from ice three.four patch two release and that the customers would require the three.four patch two or later versions only. At the center, what you see here is a scale, what we support across the catalyst center appliance.10:47Answers, we are trying to keep it as close as possible to the SD access fabric scale.11:07But as a part of the launch, we are supporting this across 500 fabric sites and in the near future we will expand this to the scale what the appliance supports. And with that, the feature roadmap that we are looking at is committed so far is for the 1st half of 2027 where we are trying to enable this.11:13For intra subnet, within a VN, customers have used a single large/sixteen IP pool or/eight IP pool and then they will have multiple azds to group the devices. So we can now.11:32Implement SSI for that feature for that kind of deployments as well, starting with calendar year 2027. And we are also seeing customers coming to us asking for deploying this in a branch network where they have a fiab only which is fabric in a box role.11:47Managed by a single stack of 9300 switches or 9500 series switches and they are they have requested to prioritize such a role as well. And if you look at traffic series support for policy extended node or supplicant based extended node.12:03This should be available even today. The only factor is that it requires a manual SXP configuration from node towards the edge node. Once we have that configured, we should be able to support this with the existing 17 eighteen.one node later release as well. So that way your traffic will be steered whenever you have pin or Sban node, even though.12:19Traffic will get steered towards the firewall. How do you want to route it?12:38One thing I want to call out here is that we don't support this with 9500 X or 9600 soup two variant of, product families today and we are planning to see how what can be done for those platforms in the, in the future. So.12:42At the same time, we have successfully completed a pretty good beta testing so far with close to ten customers completing their EFT trail, and then we are moving towards, we have already moved towards open beta phase in catalyst center three.one.six release. The 316 releases currently in canary mode, what we call as a restricted.12:59Access mode for certain customers. In case you are interested, please do drop a message in the chat here so that I can reach out to you and ensure that.13:19We can get you enrolled for doing a canary mode and and you can deploy this in live production environment and this gets complete Cisco tax support without any doubt. And without any further delay I would like to hand it over to Mahesh to get a deep dive into the topic.13:27Over to you Mahesh. Thank you. Good morning, good afternoon, everyone. My name is Mahesh Naghireddi. I'm a technical marketing engineer, and I predominantly focus on software defined access. So let me go ahead and share my screen.13:46Okay hope you all could see my screen share which is currently a PowerPoint. So with that introduction, what Saron just gave to us, let's dig a little bit deeper. This is the agenda I would be following for the next.14:0660 min or so, why SSI I think someone uncovered by SSI, but I'll just go into just a couple of slides to just reiterate couple of points there. And then what are the requirements and design consideration with respect to SSI?14:23How does the workflow look on the catalyst center? Because that's the controller which we'll be using for this particular feature, which is built on top of the SD access fabric. And what topologies we support with respect to the phase one launch, which we have come up with.14:38Feature support and scalability, I think someone had already covered about that. If anyone has any questions, you could certainly stop by or stop me when when I'm on those slides, if not we will just skip those slides and I've also added some packet walk slides, so we'll just look at how exactly the packet walk.14:57Happens when we enable this feature. And at the end, we look at a 10 min demo which I've recorded a couple of maybe a couple of months back with with the production image.15:16So with that, let's understand why SSI, again, there were, there are methods available in your traditional networks if you want to redirect traffic to a firewall. So let's look at how redirection works in a traditional network and what methods we could use.15:29And then we will see what benefits SSI provides to us. So if you look at this particular animation there, I have, you know, a couple of IoT endpoints which they want to communicate and currently since it's a flat routed access network, they'll be able to communicate across the.15:48The switch to which they're connected. Maybe they're on same switch, different switch doesn't matter, whether it's fabric, non fabric, this will be able to communicate with each other since they're part of the same subnet or or if they've been routed across a routed network. But let's see if our intention is to redirect this traffic to a firewall, there are couple of methods available.16:07One, we could do a hop by hop PBR, which is not new to us and most of the networks that's what would have been configured so far if you want to redirect to a specific destination, right? Or we could even do an IPsec or a GRE tunnel as well so that we could build a tunnel from the layer three switch to which these.16:27Hosts are connected so that the tunnel could just hand off the traffic to a firewall. If the firewall supports GRE, we could build the GRE directly to the firewall. If not, maybe a hop below the firewall and then do a pure IP handoff from the switch to which the firewall is connected, right? So, so there are methods available to to achieve this, but but what are the challenges.16:47Changes with these methods, right? Again, some of these methods are tightly coupled to your topology.17:07So which means you don't have the flexibility to, to change, you know, based on the intent what you want to deploy. Because this network is kind of static, the scalability is limited as well, right? Again, what I'm showing here with that animation.17:13It's just a one way flow, right? So, which is kind of slate stateless for us. If I want to do the same thing for the return, I have to make sure I have configured the similar traditional methods to get the traffic back to that robot arm what we have seen there, right?17:32So since, so, so scalability is limited here. If I want to do this for hundreds of endpoints or hundreds of switches, then I have to make sure I follow the same across my entire network. The since we are doing all these configurations manually, it's prone to errors, right? So that's the management challenges what we have.17:50And the policy here is based on either an IP address or a VLAN, and we, at Cisco with fabrics, we want to move away from this traditional IP addressing, you know, concepts. We want to just use something else instead of.18:07Instead of using IP addresses to configure maybe your actors, right? So we will see what mechanisms we are using for SSI instead of IP addresses or subnet to redirect this traffic. So that's the, that's the right part. Again.18:25With if you folks are already used or deployed as the access fabric, there are certain methods already built into the architecture itself to achieve this end goal of redirecting the traffic to a firewall. Again, fabric supports layer three overlays, layer two overlays, similar to your MPLS L three VPN.18:42Send into VPNs most of the fabrics today in enterprise networks do support both those architectures. So let's look at the layer three overlay part 1st. So, so let's say if you have couple of vrfs within within my fabric built in, we could certainly extend those words to the firewall.19:02So that any VRF A to VRF B traffic could certainly be sent through the firewall because that's where the route leaking is happening so that everything goes through the firewall. The challenge with this approach is you're carrying the entire VRF traffic to the firewall, right? Which is not our actual intent here. Our intent.19:21Point is to carry specific untrusted traffic to a firewall, right? And I should be able to.19:41Do that on demand as well. We have another option within the fabric itself with respect to L two overlays where the, even though the fabric is a routed access network, we could enable layer two functionality with flooding on top of the routed access network similar to how we run VPLS.19:47For an L three VPN. So even though the fabric is routed access here, we would enable flooding and we would create a VLAN.20:07So that we could have the gateways defined on the firewall instead of on those access switches. What is on the left hand side with L three overlays, the gateways are on the access switch, what we call it as edge nodes and fabric. But if you look at the right hand side, the gateway is now on the firewall, which means if I have, if I want to send, if I want to.20:13Inspect any traffic between let's say VLAN A VLAN B, we could certainly do that because it has to go through a layer three hop and here the layer three hop is the firewall, even though the fabric is routed access. Again, the challenge here is I'm carrying the entire VLAN traffic. In the 1st scenario I was carrying the entire VRF traffic, which means all VLANs.20:32Subnets.20:53Within that work are now being sent to the firewall. In 2nd option, I'm carrying a specific subnet or a VLAN to the firewall, right? Those are the those are the current restrictions what we have. But what we want to achieve with security service insertion is we want to inspect s specific untrusted traffic.20:54And we want to redirect only those specific untrusted traffic to a firewall, right? Again, the reasons maybe, you know, maybe different for each each and every customer for this, for some of them it might be compliance, right? For others, they want to inspect every traffic which goes across subnets, right? And we want to do this.21:13Set on a selective basis as well and it has to be stateful, right? We will look at how we were achieving that stateful inspection with security service insertion so that we send both the forward and the return traffic through the firewall. I'll just complete the animation here. So those are the benefits what you get with this particular feature.21:32It's centralized, it's entrally configured, so you just use catalyst center, we have workflows built into the catalyst center.21:52So that you do this or you deploy this intent once and irrespective of where those endpoints are connected in which fabric sites traffic will be redirected, definitely increase security because we're using ICE and we're using security group tags to redirect this traffic. We're NO more relying on IP addressing, NO more.21:59Relying on VLANs to redirect this. It's completely based on security group tags, so an endpoint authenticates.22:19When they authenticate with ICE, ICE pushes down a security group tag, what we call it as sgts, and we use those sgts to redirect this traffic, and the redirection happens at the ingress, at the source where the user is connected or an endpoint is connected. With trustsec usually enforcement happens at the egress.22:25But with since we're using sgts here for redirection, the redirection is happening at the ingress, right? That's the difference between traditional trust sec using sgts and sgts used here for security service insertion. And the deployment is per VN basis. You have an option to speak which VN within a fabric.22:44Site or which VRF within a fabric site you want to redirect this traffic for. Again, we're not redirecting the entire VN traffic, but you have an option to pick which.23:04Virtual network or which VRF within that particular site you want to use for traffic redirection, right? So that you have much more granular options available there. And the policy is it's a unified policy for both wired and wireless, so irrespective of whether it's a wired client wireless client.23:13If you're doing something called fabric enabled wireless or even flex connect, this particular feature should seamlessly work for both wired and wireless, right? So it's a single policy which you could configure irrespective of whether it's a wired endpoint or a wireless endpoint. Again, that's one of the benefits we provide with fabric today.23:29Like with with SD access, it's a single controller which is a catalyst center, which we would use to deploy both wired and wireless networks. So we are using a similar option here. Since this is built on top of SD access, we will, it's a unified policy for both wired wireless. I've already spoken about the policy part where we.23:47We are using sgts and.24:07Dgts for the redirection purpose instead of IP addressing. And you also can go much more granular, not just the source tag and the destination tag. You could also even pick what access contract or what application traffic you want to redirect, right? You could go all the way from L three to L seven in specifying that access contract. I could say.24:10I want to redirect all SSH traffic going from, you know, this particular source tag to this destination tag. I could pick a source port, destination port, applications, all those options are supported with this particular feature. And with all this, this certainly reduces your CapEx and OpEx because now we are not redirecting the.24:30Entire traffic to the firewall instead of that, you're just.24:50Redirecting specific untrusted traffic, so you don't need to go with a full high end firewalls to support that throughput what you what you need. Because today if you look at the switching environments, most of the switches could do, you know, terabytes of throughput, but the firewalls are not there yet until unless you upgrade your firewalls and you go with a very high end.24:54Firewall. So the switches have been upgraded, but if your firewall infrastructure is not and usually the firewall throughputs are much, much lesser than.25:14Any switching environment, so with this feature instead of sending your entire traffic, you could certainly send interesting untrusted traffic to the firewall. So again, someone uncovered this, the hardware and software, I just wanted to call out a couple of things.25:21When it comes to catalyst center, we have three types of appliances. DN one was the initial generation of our 1st generation of an appliance which we launched back in 2017 or 2016. We don't support that DN twos and DN threes.25:39DN twos are more or less I think end of sale, support is still there. DN threes are the newer appliances. So since D, we need three.one.six catalyst center release, so three.X release is only supported with DN two and DN three, it's not on DN ones, and that's the primary reason why we don't support this.25:54Feature.26:14If you're using the 1st generation of catalyst center. So you need to have DN twos or DN threes running 316 and above releases. The current shipping release is two, sorry, 322, which we just launched a couple of weeks back, but we started to support this from 313 as EFT and in 316 is.26:15It's it's an it's a it's a it's a beta release, so you could certainly use it but again none of these three.X releases are generally available yet.26:35The general availability might happen shortly, maybe a couple of months time, right? So current recommended and general available releases still 237X release on catalyst center. When it comes to ice, there are certain.26:42Enhancements which we have done on ICE to support this. I'll talk about that when I come to the specific slide, but on when it comes to ice, you need three.four patch two release and later. Now anything below that is not supported.26:58Even though it might work, we don't support anything less than this because that's the release onwards we have tested it because there are some API calls which we do at the backend and that's been fully tested and we officially support anything about three, four batch two onwards.27:13When it comes to cat nine case, we do support all the cat nine case other than the ones which are which I've listed here within within the parenthesis there. No support of 9200 someone had mentioned that's coming later. 93 fifties are new catalyst next generation switches, switching switches switch.27:29And that support is coming later. 9500 X is our cat nine case switch but running an ASIC other than the traditional cat nine case, so we're not supporting that yet on that platform and 9600 also has a similar ASIC as 9500. So those are the platforms which we don't support, but other than these parts.27:49Listed here all other cat nine K platforms are supported.28:09And the iOS XE version minimum required is 17 seventeen.one and above. I think the current one we're shipping is 20 six.X release. Prior to that it was 1718, so if you're using anything above 1717, you should be good to use this feature because there are a couple of new clis which we have added for this feature to work.28:12When it comes to firewall, you could either use Cisco ftds or any 3rd party firewalls. Again, you're not officially tested all every vendor firewall out there, but again it doesn't matter to us because we just do a pure IP handoff to the firewalls and whether could I have a standalone HA, none of those.28:33Matter to us, I have a specific slide which which I'll talk about, but again the firewalls could be either Cisco.28:53Or a 3rd party firewall. You certainly get benefits if you're using a Cisco FTD because Cisco ftds do understand sgts, which means you have a capability to hand off this traffic with an SGT tag to the Cisco FTD and the FTD could certainly use those tags to enforce it as well. That's the primary benefit to get if you go Cisco with Cisco.28:58But if not, we could certainly use any firewalls. Some of the firewalls do support htts as well, so you could certainly get the benefit of that.29:18Sure. When it comes to prerequisite, there are a couple which I'll go in much more detail, but 2nd bullet point is the primary one here. When it comes to SD access fabric, we do support two control plane architectures. One is called LISP publisher subscriber.29:27And the older one is Lisp Lisp BGP. So we're using BGP and Lisp together as a control plane protocols that was the older architecture which we still supported in the in the three.X releases, but all the developments are happening with LISP publisher subscriber because it's one protocol instead of.29:46Two protocols converging at the back end, right? So to keep the architecture much simpler, we fully converged or we moved away from BGP and we just use less.30:06Within the site and across sites with this publisher subscriber architecture, right? Again, there are lot of benefits all new developments are happening with list pubsub. So if you have, if you or any of your customers are using the older list BGP, we do have some workflows in three.X to migrate from a list BGP to pubsub, you could certainly leverage that workflow.30:16So that because that's the prerequisite for this feature, we have not developed this feature with lisp.30:36BGP architecture. It's only supported with list publisher subscribers. The remaining prerequisites I'll I'll talk about in when I go to the workflow section. So when it comes to workflow, there are five steps on catalyst center. We'll run through each step and what exactly we do at each and every step.30:42We will look into it, but there are five steps. Another thing I want to call out is this is the 1st time on where we are combining both automation and the policy in one single workflow.31:02If you folks have deployed SD access, you use a separate app or a workflow on catalyst center to deploy fabric 1st and then you use a policy app to deploy your trust sec or the micro segmentation. So it's two separate apps what what we're using for fabric, but with this workflow, we have combined.31:15Find that so that you run through this workflow, it's a five step workflow. Once you run through this workflow, catalyst centers should have done all the automation configurations, what's needed on all the switches. On top of that it should have pushed all the relevant configurations to ICE for that policy piece as well, right?31:35So let's look what happens in the 1st step. Step one is the pre check which we run and as part of this pre check, we do multiple checks at the back end, right? One, do we have the right packages installed, right? Yes, it's a catalyst center.31:54Is the catalyst center running SD access, is the SD access package installed, and for policy, we need this ACA package, is ACA package installed? That's the 1st precheck we do on the catalyst center when you go through this workflow, right? 2nd precheck is.32:09Yes, the packages are there but you have you configured fabric, right? If yes, have you configured virtual networks or vrfs? That's a second pre check we do because that's a prerequisite when you go through this workflow. The 3rd one is catalyst center device integration.32:26Right, so that's another important step because we need that integration without that, we would not be able to use those security group tags for policy piece, right? As I said, it's one single workflow on the catalyst center to deploy SSI or security service insertion, which means we need those security group tags.32:41To come into that workflow and for that, this integration piece is critical. So that's a pre check. The XE versions, we do check the ICE version, the iOS XE version, all those checks will be done at the backend. We will make sure you're running the right ICE version because as I said, three.four.32:59That specific patch, we, we will push certain configurations to ICE and due to which we need that particular release onward. And catalyst center to ice sync. So integrating catalyst center to ICE is one step on on on catalyst center, but once you integrate and if you need that policy matrix or the trust sync matrix to be available on catalyst center.33:18You need to do a sync in the policy page, right? That's another prerequisite. So we will check whether you have started that sync and with that sync, what happens usually is catalyst center will become the read write authority for that matrix, what we had on ice. ICE will become read only. Catalyst center becomes read write.33:38And for this feature, we need that capability on catalyst center because there are customers who are using this capability on ICE and to say even though they have fabric built, even though they have catalyst center integrated with ICE, since the security team manages ICE, they want that trust sec matrix.33:56You know, control with the security team, not with the network team who manages catalyst center. So we have an option in the UI on the catalyst center. When you integrate catalyst center with ICE, by default catalyst center takes over that rewrite privileges of that matrix so that you could create.34:14Sgts on catalyst center. You could create policies on catalyst center as part of the single plane of glass story what we have, but there are some customers who don't want that because of this network team and security team within their org due to which they want the privileges back on ICE. So there is an option to pass that privileges back from catalyst.34:30Center twice, but this feature needs that privilege on catalyst center, right? So that's another pre check we do at the backend.34:50And on top of that, have you configured security group tags, right? Our security group tags available on catalyst center because we need that in the workflow. And the last one which I've already spoke about SGTD management or trust sec policy management has to be on catalyst center. It can't be a nice.34:57At least for this 1st release what what we have what we have come up with. That's the that's the step one. The step two is where we select, we check, you have an option to select a fabric site. So the catalyst center could have fabric and non fabric sites. When you go through this workflow, the option will only show you.35:15The fabric sites which you have configured on that cluster. It doesn't even list the non fabric ones because this workflow doesn't support non fabric. So it will list down all the fabric sites which are already pre configured on the catalyst center so that you could select in which fabric site you want to deploy security service insertion, right?35:34So once you select a fabric site, this is where you, it'll also display what virtual networks have been associated to that fabric site. So in this example on the right hand side on the topology, I have a virtual network called campus, so you will have an option in the dropdown to, to pick.35:53What virtual network, you know, you want to use where you want to enable security service insertion. So as part of this pre check, we also do the iOS XE compatibility on all those devices which are in the fabric. So if you have any device, even let's say if you have ten devices in that site, one of the device is not running the right iOS.36:08C version or one of the devices not compatible with the matrix what we have already called out. Let's say we have a 9200 CX as an edge.36:28In the site, then the check fails, you'll not be able to proceed with this workflow. So you need to make sure you have all the supported devices in the site and all the devices are running the iOS XE version what we have called out. The next step is where we map.36:38The firewall to a virtual network. So as I said, you select a fabric site, you select a virtual network, and once you select a virtual network, you have an option to map what's the firewall VIP IP address. It's just an IP address which you just key in in the UI. The, as I said, the FTD or the or the firewall could be a standalone HA cluster.36:55The instance, any of those options, doesn't matter to us. It's something which the security team have configured and only thing we need is just a virtual IP address to which we could point this particular traffic to. So this is in the step three is where you map the the VRF for the vns.37:16To the virtual FTD, right? Step four is where you configure the actual policy, right? So if you look at the animation there, I have two hosts packet is going from host one to host two. And this is where I configure, ok, host one has, let's say host one is part of an employee STD Host two is part of a contractor is.37:35And I don't want to trust any traffic going between an employee and a contractor even though they are on the same virtual network, so I want to redirect this particular traffic to a firewall. That's my intent. So the policy I'm configuring there is.37:56Source employee destination contractor. The action is redirect instead of enforcement and you do you do enforcement, but your action is redirect. And the contract, what I'm specifying there, what do you see there as TCP redirection or reader.38:08That's the actual access contract where I'm specifying what ports and protocols I want to match to be sent to the firewall or or the traffic which has to match to be sent to the firewall. And by default, we configure a mirror policy, which means any traffic coming back from contractor to employee will also be subjected to the same firewall.38:23To inspect, right? So that's a mirror policy which we automatically push. So moment you deploy this particular policy or or or you go, once you go through the step five of deploying it, these are the things which happen at the backend, right? So 1st thing we do is we will log into the borders. Again, borders are.38:42A devices within the SD access fabric which runs Lisp and VXLAN on the southbound, and it runs BGP on the northbound, right? So they are kind of devices which talk pure IP on the on the northbound and and fabric on the southbound.39:03So we log into the borders, the 1st thing we push is an ice certificate, and why is that needed? If you, if you folks have worked on trust sec, trust sec uses radius with ICE, right? So any switch which has to download a policy.39:19Will or with even for authentication purpose, right? Your host gets connected, if a switch wants to authenticate that host, radius is the protocol used at the backend between switch and ice. So Trustsec by default will use radius. What we have done and radius is not secure today, it's a it's a UDP packet which will be sent and it's not secure.39:36No, because there's NO encryption built into radius. We have radsec as an option, but I don't think we are using that for now.39:56So what we have gone ahead with this feature is to make the feature more secure, we are using HTTPS as a communication protocol between a switch and ICE instead of radius. So for HTTPS, we need a certificate.40:01To be available on those switches. Again pushing certs to switches is not new in fabric. Today moment you discover a switch on catalyst center, catalyst center deploys a certificate to the switch so that all communication between the switch and catalyst center is secured through that HTTPS. So that architecture is already there.40:17Between any switches which catalyst center manages today in fabric or without even even in non fabric as well. So what we're doing here with respect to this feature is we are pushing an isert to those switches so that we secure that communication.40:37And we use HTTPS at the backend for all communication between that switch and ICE. So ICE certificate is pushed. 2nd config you push as part of this is a PBR. I'll explain why that PBR is needed.40:53Or maybe I'll I'll go ahead and do it right now. So when a traffic goes from an access switch, which we call it as an edge to the border, the border needs to identify whether this is a redirected traffic or a non redirected traffic. So to identify that the edge, when it sends a packet to the border, which means the next stop should be the fire.41:09Firewall.41:28The edge will add a selected bit and that bit tells the border that this is a redirected traffic. So any packet hitting the border without that big set, it's its traditional switching routing, right? Nothing will be sent to the firewall. But see for us to identify whether it's a redirected or not, non redirected traffic, we.41:29We have configured a PBR under the LISP interface on the border.41:49So that the border knows that it's a redirected traffic and it has to set the next hop to the firewall. So that's where that PBR comes in, right? The PBR matches that service selector bit and it will set the next hop to the firewall. And that's the only place place where we configure a PBR to identify the traffic. So that'll, that's the config which will be pushed on those two borders.41:53And we also push some router listed configurations because the firewall IP address has to be registered as a service within the list fabric due to which we need some additional clis to be pushed to register that particular firewall beep IP address. So those conflicts will be pushed to the border.42:13And last but not the least, the HTTPS configurations to make that communication between that switch and ICE much more secure. Next is we configure the edges similar to the borders, we will configure the edge, the conflicts looks more or less the same except the PBR part.42:29Right, so I've already explained what those conflicts are. The next step would be to configure ICE, so this is where use the REST APIs at the back end to create a couple of things. One a matrix. Why do we need this matrix?42:46Again, matrix or matrixes on ICE is not new. ICE supports multiple matrixes today, but most of the customers just stick to one which is a production matrix. The way we have implemented this is, let's say you have ten sites on a catalyst center.43:02You want to enable this and you are reusing those sgts across all ten sites. That's the scenario we are in, right? Because there are two options. One you could have per site sgts or you could just use common sgts across all the sites. Most of the customers stick to the common htts because they don't want to, you know.43:20Increase the number of sgts what they what they want to manage on that on on ice or on, on the matrix. So they just stick to the common sgts. So if I have ten sites and if I'm using common STDs, we wanted to give an option where you could select in which site you want to.43:36Have this redirection to be enabled. And the remaining nine sites, there shouldn't be any impact or there shouldn't be any redirection. So the way we are doing that is we are creating a separate matrix on ICE for this particular site, which you have selected and we will automatically add.43:51All the devices in this site to that matrix on ice, right? All this is taken care of the back end, you don't have to worry about any of those configurations which you have to do on ICE, right? So those are the conflicts which we would deploy through catalyst center on ICE, and for that we need that API communication going on and so that we create a separate matrix, we add all this.44:08Network access devices, what we call it on ice nads into that second matrix, which we'll be using only for redirection purpose, not for your trust set. The rust sec still relies on your production default matrix, but for security service insertion, we use that second matrix so that, you know. So if you, if you.44:28Run this workflow for ten sites, we will create ten separate matrix on ICE to differentiate each and every site on the catalyst center. Again, this matrix is not visible on the UI when you log into ICE, you will not see this matrix by default. It's, it's an hidden one.44:48But there are APIs to to see that matrix, which I'll show when I go through the demo part. And once we get the matrix, the next step or the next config will push is the steering policy. Since we created that employee sec contractor.45:05And an access contract we have to push that to ICE so that ICE is the single source of truth when it comes to policy, right? So all the policy deployments happens from ICE to all the switches, but the automation, all the configurations will be done by catalyst center on all the switches, right? Similar to how you want usec works today.45:20Yeah, so when the switches are all connected, fabric is built, they should be able to download all those steering policies from ICE using HTTPS as a protocol, right? And we NO more use radius for that. So if you have and SSI on the same switch.45:38Trustsec will continue to use radius. SSI will continue to use HTTPS. But again, we are coming out with another catalyst center release where we will combine both these you know features to use a common secure protocol which would be HTTPS. So we will give you a workflow or an option to migrate from your.45:57Additional radius to HTTPS, so that's coming, but in the current releases, we still have kept that too separate so that the customers who have already deployed micro segmentation or trust sec would continue with radius only for this particular feature we will enable SSI. So that's on the workflow.46:16Let me go ahead and complete the slides. If you have any questions, please post it on the Q and A chat or I'm happy to take any live questions at the end. I'm sure we'll have some time. So when it comes to topologies, here are all the topologies what we support with respect to security service insertion.46:35Right, I could have redundant borders, I could have a standalone firewall, that's one option, right? The, and the connectivity between the firewall and the borders could be a layer two or we also support layer three option as well, right? So both options are supported again I've just come out with this option with respect to ftds. If it's.46:51Follow any other vendor firewalls, whatever options they support, you could certainly go with those options there, right? So standalone firewalls, HA firewalls, layer two between firewalls and borders, layer three between firewalls and borders. Both options are supported. But what if the firewalls are not directly connected to the border, right? Which I'm sure some of you might have similar.47:11Designs in your, in your environment. So the if the firewall is not directly connected, the option what you have is a GRE tunnel to be built from the border to the firewall. Again, that is center doesn't build this GRE tunnel, it's up to the network administrator to build that tunnel from the border to the firewall.47:31And for this the firewall has to support GRE tunnels. With the current shipping firewall, the ftds, we don't support GRE tunneling on the ftds at least. So if you're using Apollo firewall, Apollo.47:50Firewalls do support GRE tunnel, so you could certainly get the benefit of using a configuring a GRE tunnel from the borders to the firewall. As I said, we are not automating this tunnel. It's up to the network admin and the security admin to configure it. If you're going with the options on the left and the middle, you're good with it because they're directly connected to the borders and we do a handoff to those firewalls.48:07It's not.48:27Then you have to deploy the GRE tunnel. If you, if the firewall doesn't support GRE, then it's up to the network admin to do a hop by hop VRF light handoff all the way up to the firewall so that you carry that VRF traffic up to the firewall with segmentation preserved up until the firewall, right? So those are the two options. I know it's not a.48:28Again but those are the two options what we have with the current shipping releases.48:48Okay, so I just added the slide so that you just get some inputs from you folks, leave your input on chat or if you want to verbally voice it out later. Happy to take that.48:52So what we've done with the current releases is if we have enabled redirection, right? So without redirection, that's how the animation is, right? The host will be able to communicate directly without going through the firewall. But moment you enable redirection, then the traffic will be subjected to the firewall for inspection purpose. But what happens if the.49:09Firewall goes down, it's unreachable, whatever the scenario maybe. So what we have done today with the current shipping releases is.49:29We have given precedence to security than routing or switching, right? So if the firewall is unreachable or down, then the traffic just gets dropped on the border, right? But if you, what we're thinking here is.49:36Instead of redropping the traffic on the border, we could give you an option in the UI so that you as an administrator could decide whether you want to drop this if you want to keep security on top or if you are, if you don't want, if you think that's a business impacting one.49:53Even the firewall is unreachable, if you want to just permit it, then you will have an option to forward the traffic to the destination, right? Without me dropping it on the border. So in the current shipping release, we don't support this, we just drop it, but let us know.50:10If you folks think that decision should be with the network or the security administrator, we could certainly give an option in the UI so that you take that decision or you make that decision whether you want to drop it or you want to forward that traffic, right? So currently it's not there. It we will just drop it by default.50:26Feature support, I think someone is on a high level mention but I'll just use some animations to to showcase that here. So there are east west and north south traffic what we support within the VRF. So what you see on the left hand side is a traffic going from.50:46Host one to host two.51:04Onward like the forward traffic, right? So you have enabled security service insertion, you have configured policies, the traffic is now subjected to the firewall for inspection, right? That's east west. And the return traffic will also be subjected to the firewall, right? As as they push a mirror policy, automatically the return traffic from the host two to host one will also be sent to.51:06The firewall by default, right? So that's your return. So this is for east west within the VRF. The 2nd use case what we support is north south. So let's say you have a server in your data center and the host is trying to communicate with the server and you want to subject this traffic.51:25Through the firewall. So we do support this, but again, if you look at the, if you, if you, you know, look at the topology what the way I've drawn it there, the VRF is campus or the virtual network is campus. I'm extending that VRF, the pink lines what you see towards the firewall. So I'm extending that VRF to the firewall.51:44So the firewall inspects it, it sends the traffic back to the border.52:04And on the once the traffic is received back on the border, the border will look at traditional routing and since the traffic is destained to the server and which is sitting outside the fabric, so somewhere someone has should have done a route leaking from a VRF campus if the server is sitting in, let's say a global routing table or.52:08If the VRF is not extended to your data center. So I'm going with an assumption here that that route clicking is done.52:28Maybe on a firewall or what I'm showing here is just a DC switch, what you see in between there, but I have done the route clicking, so I'm sending this traffic to the FTD on the VRF. Traffic comes back. Route clicking happens on the, on the peer device or the fusion what we call it and then traffic sent to the to the server. So with that assumption we.52:35Do support north south traffic workflow as well, right? Where we are subjecting the traffic.52:55To the firewall. That's forward. The same thing happens for reverse. The traffic comes back from the server, it hits the border. Border will knows that there's a match in the policy there and it will redirect the traffic to the FTD, right? So that's, that's your return.53:00Oh, the other deployment option support is intra, inter subnet intra VN, inter subnet and inter SGT. Someone had mentioned about this, so if you look at this animation here.53:17I have a host which is part of campus work, so like both the hosts are part of the campus work, which means it's intra VN within the same VN and inter subnet, if you look at the IP addresses on those hosts, one of the IP addresses 14410, another one is 14710, so they're part of two different subnets.53:31Which is inter subnet, and if you look at the hgts host one as an HTT employee host two as an HTT contractor, so it's inter SGT. This is what we support today with phase one. Interviewn, inter subnet and inter SGT. All of the combinations are planned for.53:52For future releases.54:12Right? And, inter VN through firewall, that's an option available, but again someone somewhere has to do a route leaking on the firewall, right? Or on the fusion what we call it. So in this, you could see I have a campus one, I have an IoT VRF.54:14But for this, you don't need a security service insertion as a feature because we're extending the vrfs to the firewall and by default anyway all the traffic between campus and IoT goes to the firewalls for this use case you don't actually have to enable security service insertion.54:33Feature support has gone through it. I've explained most of the things on a high level with slides, so I'll skip this. You folks will have the slides, you could certainly take a look at it. Scale is also being covered.54:50So i'll skip this slide as well. So let's quickly look at the packet walks before we jump into the demo. So I have two hosts. Host one is employee one, and he's he has got an HDT employee.55:03You can see the IP addresses there. Host two is a new endpoint getting connected. So if I go back host two gets connected, that's the 1st step. So as part of the, once it gets connected, switch will authenticate with ICE, right? As whatever, as part of the authentication ICE pushes down an authorization request or or.55:19Authorization profile back and let's say if the profile is permit, then the host will get onboarded to the network. The host will get a DHCP IP address and as part of the authorization policy from ICE, it has pushed down a VLAN, it has pushed down an HGT, so this particular con one who's a contractor, has got an HGT.55:39Contractor or con CONT what you see there, right? But in IP addresses is a different IP sixty.fifty. So employee one has an subnet fifty.hundred and contractor one has an IP address which is part of different subnet which is sixty.fifty. So.55:58We will certainly be able to redirect this traffic to the firewall because they're within the same work across, different subnets and different sgts as well. So once this happens, let's say, again, these steps are all.56:16How is the access fabric works. Host gets connected, gets authenticated with ice. ICE pushes down a dynamic VLAN, dynamic SGT, what we have seen in step one and step two. The next step is where we will, the switch, the edge switch will register this particular endpoint to the control plane node, right? So now you could see an entry in the control plane node where it says con.56:32One is now behind this edge two, right? What I see on the right hand side.56:52Is the switch which is edge two. So now, and that's the redirect policy, let's say we have enabled SSI, we have pushed this redirect policy to the to the to the to ice, where we are saying anything from employee to contractor or contractor to employee using that particular contract.56:57You know, redirect the traffic to the firewall, right? That's, that's the SSI feature which we have enabled and the policy is now pushed. So the policy is now downloaded to the edge because if you look at it, the policy which is downloaded to the respective edges is the policy relevant for those endpoints. On the left hand side switch you see a policy downlo.57:15For employee on the right hand side switch you see a policy downloaded for contractor, right?57:36But we had one both of them which, which were there available on ICE. So since those endpoints are active policy automatically gets downloaded again by using HTTPS, not radius here. Once the policy download happens, let's say if now contractor wants to send the traffic to the to employee, that's that's the next step. So once the traffic hits the edge.57:40The edge doesn't know how to reach this employee one. Let's assume this is the 1st time where this contractor is trying to communicate with the employee. So again, traditional LISP map request, the edge two will ask control how can I reach this endpoint employee one having an IP address fifty.hundred, right? So the control.58:00Plane node already has an entry for all these hosts in the network, so the control plane node responds back saying if you want to reach.58:21You know employee one send the traffic to edge node one and one enhancement we have done in this reply is we're also now pushing down an SGT for that destination, which is that employee SGT. Without SSI, we don't usually control plane doesn't usually maintain any of these SGT information.58:27Nor it shares any of this HTTP information to any of the edges. As part of SSI, this is an additional thing which we store on the control plane nodes where moment an edge gets onboarded and edge node gets registered or edge node registers this to the CP or the control plane node.58:47The edges will also share the SGT information to the CP and now the CPU would be able to share that back to anyone who needs that. So in this response back, you would see that if you want to reach employee one, send it to edge node one and the SGT for that particular endpoint is EMP. So now.59:06There's a policy match which happens on the edge node because the traffic is going from con one or the contractor to an employee and we have both source and destination tag, a match happened, and once a match happens.59:26The edge node will be able to build a VXLAN packet with source as edge node two, destination as border one because now it has to send it to the border as the firewall is outside and it will set that S bit to one. That's a service selector bit which I mentioned in my earlier slides. So once.59:38The traffic hits the border. We have a PBR on the list interface where the match happens, right?59:58The ACL is nothing but permit IP any any here. The S bit match happens and we set the next stop to the firewall, right? So the next stop is a firewall due to which we just do a pure IP handoff to the firewall. So once the traffic is handed on the firewall, the firewall inspects the traffic. If the firewall permits the traffic, it'll come back if the firewall.01:00:03Traffic is just dropped on the firewall. Let's assume that the firewall permits the traffic. I think there's some animation missing there, apologies for that. So once that let's say that the firewall permits the traffic, it comes back to the border, the border looks at the packet.01:00:24Again, the border doesn't have to, it just does a traditional LISP lookup, right? The source is this con one or the contractor one destination is employee one. It knows that how to reach the destination because of architecture what we have so that the border could build a VXLAN tunnel directly hand off the traffic to the edge one and the edge one will look at.01:00:37The Packet de encapsulate the outer headers, look at the inner headers, it knows that it's going from a source of sixty.fifty to a destination of fifty.hundred. It just sends the packet out through that particular port, right? So that's the packet walk for east west within the fabric.01:00:57Similar thing will also be for north South as well. It's just that instead of having the endpoint within the fabric, it's just outside the fabric. So with that, let me quickly move on to the demo. Before I move on to the demo, Servernon.01:01:14Sumit, any questions on the Webex or we could take that later? I I see Q and A is pretty lean so we can go forward. Okay perfect. Okay, let's look at this.01:01:29Demo so that most of the things will be clear. Again, this is something which I recorded in 316, as I said, the current shipping release is 322 which went out a couple of weeks back. So this cluster already has fabric site built, so I have just one fabric site.01:01:47Which is the site J And that's the topology what I have in this site, right? Three time architecture, two edges, two intermediates, two borders. Fabric's already built, so you could see all those fabric roles. Virtual networks are already added, so campus is my VRF for virtual network. I I've already added those subnets there, so 01:44.01:02:02Four is one of the endpoint which will be part of it and 01:47 is another endpoint, so we will redirect any traffic going between 01:44 to 01:47. And auth template for the site I've configured closed auth, which means every endpoint.01:02:22Connected to those access switches or edge nodes have to authenticate with ICE and ICE will push down a security group tag and a dynamic VLAN. Right, so this is a prerequisite Fabric is already built, all templates are already set. Vrfs and anycast gateways are already configured.01:02:41So let's quickly look at those endpoints, so I'll go on switch one. We look at the auth session on that port to which that endpoint is connected. So if you look at this, the 1st port on that switch, this is currently being that's the IP address, 14410, which is host one and it has.01:02:58Used a username called employee one and you could see the auth, the.the.1X authentication statuses is passed, right? And it also has an dynamic VLAN which is pushed by ice, which is 1021 and it will also push an HTT call four, right? We will look at.01:03:15What exactly is four HGT means. So show CTS environmental data that will show you what four means, four means employee, right? That's an AGGT which ICE has pushed down as part of the authentication request. So that's host one.01:03:34Connected to edge one. Let's look at edge two, another host, similar comment right so your the username is contractor one.01:03:53It has an IP address 4710, which is host two. It has also been authenticated via.1X VLAN is 1024, it's a different subnet and the HTTP pushed by ICE is five, right? So and five represents contractor.01:04:12Maybe I'll play this at little higher speed, right? So five represents contractor. So one endpoint employee another endpoint contractor, these are the two hosts, 1441014710.01:04:34We will initiate some continuous pings between these two endpoints. And again, the interesting traffic here is just pinged, but you could go much more granular if you have any here like if you have a traffic generator or if that endpoints could generate any traffic. So this is my FMC.01:04:50Where I'm managing my virtual FTD, that's the FTD. I've already pre configured that FTD which has a sub interface connecting to those borders against a standalone FTD here and the address is that 01:50 eight.four, right? That's the IP address.01:05:09We will use in our automation when we configure SSI, right? So nothing fancy here and we will also I'll also initiate some packet captures on this FTD so that we'll just monitor a protocol ICMP and we'll see. So currently nothing is redirected to the firewall, so NO packets are hitting the firewall. Once we.01:05:24We you know Enable that redirection, we will come back and look at that. So this is an API on ICE to show you that matrix, right? So.01:05:44Before we enable SSI, I just wanted to show you the default matrix on ICE. So that's the production default matrix which is used for your trust sec policies on ICE, right? And this matrix is completely visible on the UI. But what, we'll come back and run this command once I enable SSI, then we'll see.01:05:52What's the traditional matrix which catalyst center has created using the REST APIs, right? So production matrix used for trusted policies. Okay, with that, we will go enable SSI. So there's a, there's a.01:06:10There's a menus which we have added under the services called security service insertion. Once you click on that, this is where it will do all the pre checks, so this is your step one as part of the workflow where you do all the prechecks, whether application packages are available, the ICE versions is integrated, is ice synced, is security groups available on the catalyst center, all those precheck.01:06:27X will be taken care in the step one. And then you have that enabled security service insertion. So this is where it lists all the fabric sites. Again, this cluster has just one site due to which is just showing up one, but if you have multiple fabric sites, it will show up.01:06:47Multiple options there. And this site has two infra is nothing but global routing table, so ignore that we don't support security service insertion for infra VN because the only endpoints which can be part of infra in an SD access fabric are your access points.01:07:01And your extended nodes, what we call it. No users are part of infra VN, but again this site has both of these vns or vrfs defined. Campus is the user defined one which I have created. Infra is the one which comes by default when you install catalyst center.01:07:19So this is step three where you map, you know, a VN to a firewall, right? So campus is my virtual network, the firewall IP address is 01:50 eight.four. That's the bit configured on my standalone firewall and I select those two borders in the site JBN one and BA two. This is step four.01:07:35Where we configure the policy. So the.01:07:55Source tag is employee destination tag is contractor. Again, I could only have one source, but N number of destination tags, right? That's an option which we support today. And the contractor is employee to contractor, we will look at what exactly we have within that contract shortly and the VN is that campus VN which we.01:07:58You just selected earlier. So that's the contract what I have.01:08:18I'm seeing any ICMP traffic match it. And I also have some another application traffic which again I used to use iperf as a software in the past, but in this demo I'm not using Iperf to generate that specific traffic. So we'll just use ICMP for now in this demo. So that's the contract.01:08:21We'll click next. That's your summary. We are enabling SSI for site J And campus is your VRF, firewall IP address, the two borders, and that's your steering policy. Okay, so this goes through something called visibility control. So this is an, this is.01:08:38Another enhancement which we did as part of 237 release.01:08:58Where we show you what configurations get pushed. So let's spend some time here to look at the conflicts, so the 1st part what you see there on the top, that's your what we push to the borders. And the next one what you see row number five, that's your PBR, look at row number five interface list 4099.01:09:02The route map and we are matching a PBR and the PBR is matching an access list which is permit IP any any and if you look at this, the PBR also has this matched traffic service selector one which is row number 13.01:09:23And row number twelve is the next stop which we set to the towards the firewall, right? So that's the PBR on the border. And as I mentioned, we push some router related router list related configurations as well. And that's your group policy that's for your HTTPS, right? So anything below.01:09:3927 row number that's for your HTTPS communication between the switch and dice. This is on border two similar conflicts on the edge, more or less the same other than except the PBR.01:09:59Everything else remains the same. Okay, so once we deploy this again, the configurations are all pushed, but the policy is still not pushed to ICE, so for that we need to do one additional step.01:10:10So we go to policy and we go to this traffic stating policy under policy and we select the site, so that's the matrix for your redirection, and we have to deploy this policy here.01:10:27So the creation is part of one workflow, but the deploy is where you have to do one additional check under the policy page. So now you could see the packet capture which we had enabled on the firewall, the ICMP which was going between the two hosts are now being subjected to the firewall for inspection purpose. And if I come back on the host, when we enable.01:10:48Redirection we just saw one packet drop, and now I come back on the API for ICE, now I should be able to see a matrix which we have created and this matrix which is enabled for site J, this is specific to SSI or security service insertion, which is used only for traffic steering.01:11:09Okay, the remaining are all the checks, I don't want to spend time there. Again, we could share this presentation demo. Folks could certainly take a look at it. There are some CLI commands which I execute on all of on on those edge nodes of access which is to show.01:11:37You know, those configurations pushed to show that there's a match happening with respect to policy and all that. I'll leave the demo running. If there's any questions or if anyone wants to verbally ask any questions, feel free.01:11:52Yes there was a question on on the whether if we have plans for default rules, I don't think we have plans for default rule, so the only thing we allow right now is you user has to create a.01:12:10A rule or a policy and not as to what Mahesh showed you can have a single source HTT and have multiple destination htts, but that is what we support. If if you have any other questions on that can you.01:12:27He's saying can we configure a default rule so all traffic between all sgts will steer to firewall. You could certainly do that, but you have to go through this workflow to configure it, but by default there's nothing.01:12:44Enabled. But, but I just want to understand what exactly you meant by a default policy or a default rule. Is there a specific application you want to use in that?01:13:01Do you want to share your thoughts? So that you want to unmute if it's unmuted I'm trying. Give me a moment.01:13:21Maybe we just unmute all and we'll. And another thing I want to call out since this default will came in, we don't support.01:13:40IP to IP. Today the access contract, what we configure doesn't support IP to IP. You just can't say any IP going from this SGT to another SGT, sending everything to the firewall. We don't support that. You have to be more specific. It has to be TCP UDP ICMP, so you have to select.01:13:56Like one of those options.01:14:15But we don't have an option in the UI to select an IP as a protocol there, right? Today, trustsec doesn't support that due to which even SSI doesn't support it either. So you have to be much more granular in specifying what kind of traffic you want to redirect. I think I think he's he got his answer, I believe. Okay. I'll.01:14:17Another question Krishna was asking the catalyst center version. So the one that Mahesh showed is 316.01:14:37And he did share, he did have a slide here to talk about that if you can last that slide. Yeah, yeah, yeah. Let me go back and bringing up Sumit some of Arun was asking, are we going to publish the recorded video?01:14:44Yes, we will share the slides, the recording as well yes. It works from 313 but 313 we were just an EFT so I would recommend to just use 316.01:15:04Onwards or the latest is 322 if you want to use 322, absolutely. I think those were all the questions. Okay, sounds good. Another question that I had was.01:15:23While, is, is 322 generally available? A question basically is for anyone who would like to utilize this feature if they are, if it's not available, then what is the option on the existing 237 train? Yeah, they have to reach out to us.01:15:43Maybe they could talk to their sales representatives and someone has to reach out to us.01:16:03Provide their cluster member ID and serial number and the Cisco sales rep could certainly create a request for their cluster to, you know, for us to release a32322 image via cloud update.01:16:08That's an option available today. We, again, there's a form which we maintain internally, but I don't think that form is available for customers external to Cisco, so they have to come through a Cisco sales rep and we should be able to enable them to download 322. But again.01:16:24237 to three.X is not a straightforward cloud update like the way we used to support it in any of the 237 releases or even the older two.X releases.01:16:40Three.X has a, as a database changes which we have introduced due to which it has to go through some kind of a migration workflow, so it's, so we can't just provide them a cloud update option for them to update it.01:16:56But they have to, you know, go to that migration option and, and, and then they'll be able to use it. So, so for now, up until 322 beca 323 is the current GA target release what what what we're planning up until that goes.01:17:12Was GA in production at least it's not recommended to go three.X in lab definitely doesn't matter. We could help you out how to move if you have a lab cluster from 237 to three.332 or three one whatever.01:17:32But in production, let's hold on for a couple of more months. Once this release becomes generally available, then you could certainly go in production as well. But as I said, moving from 237 to three X is not straightforward. Okay.01:17:49Hi guys, can you hear me now? Yes, now we can. Oh, 1st of all, thank you. Thank you all for your for your time. We we have been a year ago when this was a new feature on development.01:18:07Yeah. And we raise a question, maybe today we can spread some light on on on when when it's more.01:18:26Have you have more info when it's the more developed. We have a lot of sgts, a lot of IP pools on the same VM. As for today I can see that.01:18:34If I want to build a policy as for our campus policy, I will need to configure a rule for each SGT. Okay, is there any possibility in the roadmap to configure only one.01:18:50The Rule that will be used as a default rule to to steer the traffic toward the firewall for all inside the this VM. Before I answer that, what is your use case? Like, is there a specific traffic?01:19:10From all the htts you want to redirect to the firewall due to which you're asking this or can you just elaborate more on your use case? Like what kind of traffic from all the hdts you're planning to redirect to a firewall? Today our policy we we move from traditional to SDA or almost the.01:19:29Is our migration.01:19:48Yeah, we have more two distribution there to go and be completely SDA network on our campus. On the traditional we had as as your 1st slide that you showed we we had a PBR that's two.01:19:50The traffic toward the firewall, this is our policy not as a port specific.01:20:10Not the feature specific and not application specific. All the traffic, all the Intel VLAN traffic should pass against firewall rules inside the, the same VM. All inter subnet, you may, did you say that inter subnet or interval. Okay.01:20:15Intervin, inter subnet all all IP pools in the same subnet if one IP pool should or want to speak with another endpoint on the on another IP pool it should pass against a.01:20:35Firewall what we did today, we just configured each IP pool on a different VN. We have a huge number of vns today. Why why don't you use 2nd option here? Gateway outside the fabric? What do you see on the right hand side?01:20:51So that anything between one subnet to another subnet will always be subjected to a firewall. And we are using a layer three inside the SDA. No, we don't want to stretch the layer two to toward the firewall.01:21:11Okay, because with this option you're ultimately achieving the same goal that everything between those subnets will go to the firewall, but the only downside with this option is even the.01:21:28There's NO gateway on the edge, so even we prefer to to have the flexibility if there is some some scenario to to preserve the flexibility to route the traffic inside the SDA but.01:21:45Okay, understood. Yeah, I got the use case we'll, we'll make a note anyways, is here as well. We will see how we could achieve this. I think the only challenge with this option too, what, what I have on this slide is you will enable flooding for that VLANs.01:22:05And I think in your case, you may have not enabled flooding today because you're using an L three pool without flooding, and the gateways are still on the edge, but you're saying anything inter subnet or inter VLAN, you want that to be redirected to the firewall. I would say.01:22:25Technically it's possible I don't see a challenge there, but but how we could achieve that in the UI is something we will look into it, yeah. Thank you. Thank you. Thanks for that. Okay, any other questions? We still have six more minutes.01:22:42Yeah, I think someone just posted the anycast gateway. I think blake, if you are referring to the option two that Mahesh was explaining earlier, the only two options available right now are either the.01:23:03Take the VRF all the way to the firewall and doing the VRF leaking as what was saying. The other one is where you can move the gateways, so currently the distributed anycast gateways are on the edges and they are moved to the firewall is what Mahesh is showing in the slide there. So you can move the gateways.01:23:18Outside of a fabric, as well depending on the use case if that is what you're referring to, yeah blake, if you need any further clarifications.01:23:35You could certainly.01:23:55Verbally ask it, you could unmute it or I'm sure it's everyone is unmuted now. Or if that, if that helped, then we are good.01:23:57I don't see any other.01:24:24Question. So yeah, we should be good. Sounds good. Thank you everyone. Thank you team. We will be, we will be sending the slides, the recording via email, the same email that you used to register for this webinar.01:24:26And that's where you will get all the details. Thanks. Thank you everybody.01:24:42