Cisco N9300 Smart Switch and Hypershield Security for AI Scale

Welcome to the Nexus, uh, uh, smart Switch and Hyper Shield update. Uh, this is the solution for data center. My name is Java Skar.

I have Jacob Rapp and Maurizio, uh, to, uh, as part of the presentation team. So, let's get started. We'll give you a very quick, uh, crash course because we have 30 minutes is compressed.

So let's get started. So the first thing is at Cisco Live, uh, what we have announced is, uh, uh, nexus Smart Switches for the data center. So the first switch, what you see over here is shipping.

It's 24 port hundred gig, uh, switch, and it has 800, uh, gigs of services throughput. The second switch is a top of rack switch we are introducing, it'll be audible in July and GA in August. And, uh, this one is, uh, is, uh, designed for, uh, a leaf or bottle leaf use cases.

And it is 48 port 25 gig, uh, six ports of, uh, 400 gig and two ports of a hundred gig. And it has 800 gigs of services throughput. Uh, the, uh, the services, uh, uh, the services that are offloaded are running in the DPU.

The DPU will run hyper shield, Cisco Hyper Shield security, and Will will go with that, uh, in, in the subsequent, uh, uh, part in the next part, the use cases we're covering are four use cases. Right now, we have three use cases in trials, and they're gonna be ga by end of, uh, August, early September. Uh, the first use case is cloud edge, zone based segmentation, and then data center interconnect.

The top of rack use case is something we are working on today. Uh, the, it's, uh, in execution, and we will launch this, uh, by end of the, towards the end of the year. So, a quick, uh, crash course.

So this is the, uh, the switch architecture. The left one is the first switch that is shipping 24 port, 24 gig. And the right one is the top rack, uh, switch.

So we have 24 ports directly attached to the network processor. Uh, and this, this is the network asic, the network chip that does all the routing, uh, uh, uh, switching VXLAN multicast and all those things. And then we have a, the DPU over here, the data processing unit, and that is where we offload hyper shield for scalable services.

The DPU are directly attached to the NPU, and the NPU is attached to the ports. The ports are not directly attached to the dpu. Okay.

So similarly, so we have four dpu. In the first switch, the top of rack will have two dpu and same 800 gig capacity. We'll have all the front panel ports will be attached to the NPU, that will do VA VX 90 VPN, uh, fabrics or BGP fabrics.

And then the DPU are for offloading of services. Okay. And please feel free to ask any questions you have.

Right? Can you make sure to stand on the next one? Oh, perfect.

Right there. Okay. So, uh, from a operating model, uh, perspective, uh, we want to carry the workflows that our existing customers have in their existing environments before they deploy smart switch and hyper shield.

Uh, today our customers have network personas set NetOps teams and SecOps teams. The NetOps teams will manage the lifecycle of the switch. They will manage the network policy and network telemetry and the NetOps tools.

We are, uh, we, we, we will have is a network management can be done through Nexus. Dashboard can be done through Nexus API or Nexus CLI. Uh, the NetOps team will only manage the lifecycle of the switch, meaning upgrading, downgrading, um, you know, rebooting the switch, those type of things, or, or, uh, it, or they can push network, do network policies by programming the, uh, network processor or the forwarding the network.

Uh, the, the forwarding asic, the security ops is going to have direct control, and they'll directly program the hyper shield software that is running in the DPU. And, uh, the net ops and SecOps teams are fully isolated from each other. Uh, the net net ops team cannot touch the DPU and the secure, uh, SecOps teams cannot program the NPU.

So we have full separation, not only from persona, like how you would manage, the network team would manage the switch the firewall team would manage, the SecOps team would manage the firewall. Uh, over here, we carry that model forward by introducing full isolation, not just at the management plane, but also at the, uh, uh, um, the switch level, uh, you know, uh, where each team touches their own respective components. Now, uh, this is a before and after view.

Uh, so on the left hand side is basically a traditional, uh, you have a traditional data center switch, and then you can have, let's say, four firewalls attached just as an illustration. And these can be deployed in one arm mode or two arm mode. Uh, and you can do service chaining, service graphs to redirect traffic to each of these, uh, firewalls.

The firewalls can be in L one mode, uh, LA bridge mode or routed mode. Uh, with the smart switch, you, you can consolidate all of these five devices into a single device. The network, the silicon one chip over there is a network processor that becomes the network.

And each of those DPU becomes a firewall. Each of those DPU becomes, uh, a 200 gig firewall, for example. Okay.

So that's the consolidation that we are introducing from, uh, uh, with the SMART switch. Now, let's get into a little bit of, uh, technical details of how you do provisioning. So when you do the provisioning, uh, the fir uh, uh, the first thing you'll, you'll type is the, the, the command feature service acceleration turned on.

What this means is it'll activate all the dpu, the DPU will get powered on by default. When we ship, it's says as a regular switch. So you can use it as a, in a networking mode.

And when, when you wanna turn on the services, you'll, you'll type that command and then you'll do, uh, uh, you then we want to make sure that the, uh, uh, switch has connectivity to the SecOps controller, which is hyper shield running in the public cloud, uh, uh, security cloud control. So, uh, these commands will make sure we can connect. The network team is gonna operate on this yellow, the yellow part.

So if you have, let's say, A-A-V-R-F or a vlan, you want to redirect to a, to for services, you can selectively pick A-A-V-R-F or set of VFS and send it to the DPU or services for firewalling. Okay? So if you, let's go through a basic packet flow, an example of what we just described.

So we, here, let's say you have a VR F1 and VRF two, VR F1 needs a firewall service and VRF two doesn't need a firewall service. The VRF two that doesn't need firewall service will go to the silicon one. We'll do a lookup and do the forwarding and, and send it back out on the egress port so it doesn't go to dpu.

Now, let's say VR F1 is where we want to redirect it to the dpu. So I, I will, we will configure a policy to say VR F1. I wanna send it to DP one or pin it to DP one, or I want to do load balancing across, uh, all the dpu.

It can be either that's just a config, uh, option, but let's say we want to pin it to DP one. In that case, the traffic will come, uh, into NPU, into the silicon one. And the silicon one, we'll do the packet lookup and we'll derive the worth.

And, and also based on the E BG P ping, we'll say, okay, this, this traffic belongs to VR F1. Now I will, uh, redirect all the traffic to, uh, the DPU one and the traffic will go, go into the DP one and it'll get firewalled. And then when it comes back out, we will re send, bring the traffic back into, uh, the network processor, uh, into silicon one, and where we will do a egress lookup, and then we'll route it to the right egress port.

So that is basically the network and security working together in the Smart switch. I have a question. Uh, so the last slide you just showed us the CLI commands, and yes, you broke it out, uh, by different groups.

I know that there are a lot of, uh, data center teams that are moving over to Nexus Dashboard and there's a GUI involved. Yes. Um, are the security team going to have their own instance of Nexus dashboard within to be able to do these commands?

Are they going to have to learn to get into the CLI in order to be able to, to do their management? Are they gonna have a separate platform? How does that look?

Yes. Figure that out For me. Yes.

So, uh, the network team will use Nexus dashboard mm-hmm. Or Nexus, CLI or API mm-hmm. The security and all of these are API ready day, day zero, I would expect that.

Uh, and then, um, the security team will use security Cloud control as the management system from where they will push the policies. Okay? And so they have two different dashboards, okay?

And the reason why we do this is we want to have network and security separation. Now, the, because that's a majority of the enter, 90% or 95% of the enterprises or, or, or customers do that. Now, if a customer has wants to use one unified, let's say if in a commercial customer with, there's only two engineers, they do everything, uh, we'll still give them two consoles, but they can do NetOps and SecOps together.

Okay? Um, so, uh, what one of the, the majority major use cases, the 70% use case was, is the top of rack. Uh, the top of rack use case is, uh, today, if you see in a Brownfield environment, you have the data center fabric and security is bolted on.

What we are trying to do is we are trying to change that. Uh, with the Smart switch, you can make the top of rack switch layer that the, to become the firewall, uh, infused into the top of rack switch. So network and security can be combined over here.

By doing that, we can eliminate a lot of these layers. Like you can eliminate some agents like Illumio, you can remove some extra, uh, firewall layers and consolidate everything into a single layer. Okay?

And with this also, there's another aspect over here. We, we will support this with, uh, high availability vMotion, or all of those things will be supported. And when you move a VM from, uh, one, uh, hypervisor to another hypervisor, uh, we will, the policy will move with that, okay?

And the states will be synchronized. Another thing is, uh, high availability is very important. So this is a, uh, an architecture of how we're gonna do high avail availability.

Uh, you have, let's say two switches over here, a router, and it's dual home to switch one smart switch one and smart switch two. We will have I ISLs into switch links between them for the dps to synchronize the state across them. And we will support this for layer three and layer two, VPCs, HSRP, VRRP.

Okay. And that's, uh, and the last thing is, this is one of the things, uh, G two announced, uh, today. Uh, you know, one of the new things is live protect.

So if today, if in a data center fabric or in a data center environment, if you have a CBE, uh, you'll have to wait for Cisco to release a PSET bundle and trigger and cause it, and then require a full upgrade of the switching, uh, fabric and which is very costly. So what we are coming up with is we have a Roone agent built in, uh, will take the compensating controls and push it to the Tetra one agent, and that will compile that as A-E-B-P-F policy and implement the SHIELD policy to protect the switching layer against any, uh, uh, CVE uh, uh, vulnerabilities. Okay.

With that, I will hand it off to, uh, Jacob. All sounds good. Hey, I'm Jacob Rap and I lead a product management for Hyper Shield.

Um, let's get started. Uh, so in Hyper Shield, actually, before we called it a Hyper shield, we called it distributed advanced firewall, or distributed af, but AF didn't actually stand for Advanced Firewall first. Um, because we kind of wanted to think about like, where security was going in the future.

What new enforcement points do, do we need to bring to market? And how do, how do we, uh, enable the distributed aspects of those enforcement points? So we started to come up with two different areas of enforcement points as Cyber Shield.

One of them is directly inside the kernel. So thinking about how do we bring layer seven functionality, um, deeper inside the workload. That's through eeb, eeb PF or extended Rkp packet Filter, which led us to the acquisition of is Valent, who was kind of one of the leaders and co-founders of Eeb PF.

And I'll touch on that in a second. The other place is deep in the network or infuse in the network within the smart switches as well, because we ultimately wanted to think about like the firewall as a, as a thing. Like where, where does it get distributed to later as things as traffic becomes more and more encrypted over time and the firewall itself becomes less effective because traffic is, is highly encrypted, um, across it.

So when we built Hyper Shield, uh, we also built a, an intent driven policy on top of it. So Hyper Shield is kind of a full distributed system. Our architecture where we have a common, uh, management plane and a distributed control plane that connects all of our, our control plane agents that run either on the switch, um, dpu or, um, on the, uh, uh, the agents itself directly within, uh, the workload.

And they all work kind of in unison together. So if I think about a policy statement that I want to write, I may wanna block, um, web servers from being jump posts. I wanna block basically, um, any s outbound SSH connections from web servers.

I can write that policy at the top and then enforce it either in, uh, one or one of two locations, right? I can take it deep in the kernel and actually block SSHD from opening a socket, um, in the workload. Alternatively, I can put a guardrail policy in the network to block that, uh, communication with standard layer for, uh, segmentation, uh, rules as well.

Because a lot of times we're talking to customers, they like the idea of going deep in the kernel in software, but for compliance reasons, they want to have guardrail policies that block on the network as well. Because we've trained, I think a lot of the, the regulatory bodies that hardware is necessity for segmentation. It's this good hygiene to have a hardware boundary, um, that just kind of taking the page outta the hyperscalers, they use some of the, the DPU first in their environments to kind of separate, like say a Coke and a Pepsi tenant, even if they're living on the same, same device.

You gotta have hardware separation of controls as part of it. So, um, some of the use cases we built for Hyper Shield, um, obviously there's a few of them. Um, oops, too far.

Go back one. Alright, so zone segmentation. Was this the first one we talked about?

It's the Java talks about the top of rack switch. I'll talk about an on-ramp, uh, cloud on-ramp use cases as well. And then we're trying to think it through how we reinvent the default deny statement and think about how do we autonomously segment, um, applications on the, on behalf of the application, on behalf of the network as well.

And then the, the final one is around distributed exploit protection of how do we bring back like, uh, uh, uh, virtual patching type technologies, but do it in a way with kind of a surgeon scalpel precision, deepen the workload as part of it. So let's take a look at a topology, a sample topology of how these things could all work together. Um, so here I have, uh, one workload in the public cloud environment, um, that's sitting on the, the right and, uh, one workload, uh, in the data center, and they need to communicate.

So how do we protect this end-to-end flow with the combination of our test rack security agents, which is kind of our EBPF controls, deep in the kernel, and also to smart switches that are sitting as guardrails at that kind of cloud on-ramp boundary. That was kind of one of the other use cases we first introduced a smart switch with is kind of that, that demarcation point between cloud, public and public and private clouds where you need need really high speed, high throughput layer four segmentation, they'd be able to control that boundary. So if I click one forward here, we can see the first thing that we're doing is kind of divvying up the, the traditional firewall controls.

So let's say you had a firewall there in the middle, you would have some like I-D-S-I-P-S, you may have some, some inspection Deepak uh, Deepak inspection. You may have some decryption services. And then, and on top of your segmentation.

So what we're doing is actually distributing those controls across the fabric. So you still keep your layer three four segmentation boundary as a guardrail in, in the middle, uh, to restrict say, restricted zones. Restricted zones.

So I don't want that restricted zone to talk to an unrestricted zone, um, or unrestricted zones to talk to that restricted zone kind of that, that, that segmentation guardrail policies. But on the, on the corners of it, what we're doing is kind of actually fingerprinting all of the known good behaviors. So deep in the kernel, we can actually fingerprint all the way from a file to a process to a socca being opened.

So we start to, to understand those normal traffic behaviors and traffic patterns and, and start to, um, create that baseline fingerprint. And then anything that starts to deviate from that fingerprint we profile and do a multi-step, multi-path, uh, uh, anomaly detection on. So think of like, um, the, if you think about traditional layer sevens, you have app id, app ID starts to move to process identity opening a socket, so SSHD opening a sock, HTPD, curl, et cetera.

Um, and then I-D-S-I-P-S starts to move away from pattern matching, which we all know kind of the, the challenges with with I-D-S-I-P-S is as soon as the the attack changes you have to generate a new signature. Um, so, uh, I-D-S-I-P-S starts to turn into our, our graph engine where we start to profile every single movement in the graph, um, as, as we build it. So what that looks like in the product, um, today, is that on the, on the left and the right, you have these kind of autonomous segmentation fingerprints that are constantly scanning for changes in behaviors across your infrastructure.

And as new behaviors come up, we start to profile that for, for well-known bads. Is this a net cat process opening a river shell? Yes, really well known bad, let's block that.

Or let's potentially alert and, uh, make sure we, we, uh, mitigate those challenges. Um, or is it something that's kind of a multi-step process where the file got read it got sent across the network to the other side, and then exfiltrated back on the end? We have a small graph engine that runs across all of this that keeps track of like that multi-step, multi-path kind of, uh, anomaly detections, uh, even across hosts, um, as well.

So you kind of have a full end-to-end picture. And in the middle here, I'll, I'll show the next screen. We have the ability to kind of think about how do we apply policy at the guardrail perspective on the network to kind of continuously improve that guardrail policy to kind of fine tune and, uh, narrow in the scope of the guardrails, um, on creating.

And we're doing that with a technology called, uh, called it our digital twin. Um, so we, uh, we first called it, if you have heard it before, we first called it like a dual data plane. Um, but we kind of upleveled it to just like a digital twin type coffee.

Um, one of our, one of our premise of hyper shield, we wanted to use AI to generate policy and make recommendations, but none of the customers we talked to were like, that's scary. I don't really want to take your, your AI model and, and set it loose on my security. Um, so one of the core foundations of hyper shield is what we call AI native, which isn't using AI at all.

It's just basically the ability to deploy digital twins of software and and your, or, or policy everywhere all the time. So within the Hyper shield, um, on the smart twitches, we have a digital twin for policy Question, uh, Josh from Diversified, I think I want to try to combine two different concepts. 'cause you said it a second ago, you've had to move to a graph data model, right?

To give you the ability to bolt in some AI operations. Is that, would that be an accurate statement of the two things that had to happen for Hyper Shield to be able to do some of the things it can do? Yep.

Yeah, so we absolutely. I gotcha. Thank you.

Yep. Yeah, we had to kind of build that distributed graph framework so we can do real time detection, right? Response without having to kind of send all the data to the one big data system, because that's kind of how the traditional approach would be.

It's like right to find anomalies or threats, you would send everything to Splunk. So You're is more focus on relationships and points and nodes, right? Yeah.

Instead of putting everything in tables and trying to handle it. Absolutely. It's all behavior graph.

We start with the behavior graph. Mm-hmm. And then we, we, we transform into policy from that behavior graph.

Right. Okay. Thank you.

Cool. Awesome. So yeah, so this is just the, the digital twin where we kind of, uh, we were able to test firmware and policy updates, um, and then we can kind of run through a full line of tests in order to verify that those policy changes are what we expect, uh, to happen as part of it.

And we'll give a kind of a confidence score, um, at the end to be able to deploy that. So what that looks like, um, in the product itself is you have, um, the, the switches where we can kind of think about consolidation. We don't have to deploy all the big firewalls anymore for internal.

I think firewalls still have a, still have a place in the network at the perimeter. Like these things are very purpose-built, high throughput layer four, if you want really full, really like perimeter based layer seven where we can't deploy agents. Um, then we, we would still recommend traditional firewalls from those cases.

We actually, uh, announced, uh, what we call the, um, the mesh policy engine today, where we're actually supporting even third party firewall policies to, as an enforcement point, um, as well as part of security cloud control we can deploy in, in the, in the middle of switches. And then we kind of test and deploy policy across this. So, um, Mauricio's gonna come up and he's gonna, uh, demonstrate, um, what this all looks like in a demo.

Yeah. Okay. So I'm gonna show you a video recording of my lab, um, where we're gonna configure some policy, uh, push it through the Smart switch and push some traffic through it, and you'll see traffic being loud or drop depending on what I configured.

Okay. So let me get this started. Um, okay, it's working.

Okay. So first of all, this is showing you the topology. I'm basically using an a CI fabric with a smart switch attached in one arm mode.

Um, and then there are traffic generators attached to those two ports. 1 41 on leaf one and 1 47 on leaf three. And we're gonna use a CI policy based redirect to send the traffic to the Smart Switch.

And, uh, all the security policy enforced on the Smart Switch. Nothing is enforced on the a CI fabric. A CI is just steering the traffic to the Smart Switch.

Okay. Uh, and the security policy comes from Hyper Shield. So we're gonna configure some acls, stateful a C throughout through Hyper Shield.

And I'm gonna also show you some Nexus dashboard configuration as well, um, specifically for the VRF configuration. And this is just showing you how these things are cabled. Uh, just highlighting which ports are connected to, uh, the cloud to Hyper Shield and which ones are connected to Nexus dashboard.

So traffic, so here just, uh, to understand to, to match things that you see in the traffic generator. Traffic goes from the 10 10 10 network to the 30 30 30 network. And the, um, redirect configuration on the a CI configuration is gonna send all the traffic to the Smart Switch.

So first here you see, um, the configuration of a on a CI. Um, so there are two bridge domains. Uh, this is the Tenon network, and the BD three is the, uh, uh, 30 30 network.

There are two EPG associated with those, uh, bridge domains. And then, um, you're gonna see that we have a contract, which is doing nothing else, but, um, redirecting the traffic. Uh, so you see now the service graph definition.

Um, so you'll see here the devices and the smart switch, uh, is connected to the port that you'll see here in the configuration. Uh, so the port is, um, on V 3 0 5 and, uh, the specific port is showing up here, which is, um, one slash one on, um, I forgot which leaf it was. 1.

This is the view from Access dashboard. So you can see here the port with VLAN 3 0 5, that's the one connected to to a CI. So the sub interface, uh, of, uh, 1 3 1, and it looks, uh, as everything is fine.

2. And this is just looking at the CLI of the Smart Switch. So we're gonna look at the routing table.

And so with, so first you'll see the RFS that are there, um, and VR F1 is the one we're gonna use for traffic filtering. Um, and here you see that the traffic by default is sent back to a CI. So everything that the Smart Switch receives is gonna be sent back to a CI.

So it's a very simple configuration. And, um, in on the Smart Switch, we need, we need to tell the smart switch which VRF needs to be filtered. Um, so we are gonna see in the configuration that we say that VR F1 has to be filtered, but before doing so here, we're sending the traffic.

So it's a UDP traffic from 10 10 10 to 30, 30 30. Here you see that we're sending 300 frames per second. And on the bottom here, you see that we are also receiving, uh, 300 frames per second.

Because right now the smart switch is not filtering anything, it's just receiving the traffic and routing it back. So we still need to push the security policies. If you look at the counters, uh, you'll see that traffic is being received on the interface connected to a CI, and you can also check the counters on the service ethernet interface.

And you see that none of the DPU is receiving any traffic. These interfaces are the ones con internal interfaces connected to the dpu. So, uh, we need to, we have all the Hyper Shield connectivity in place.

That's what the configuration looks like. Um, so you see that, um, the Smart Switch is saying that the connection to hyper shield is, uh, status is success. So now we can go to Hyper Shield and we can define, um, the SCLs, the stateful acls that we want to push to, um, to the Smart Switch.

So first of all, you see that it's, uh, connected. So the hyper machine is also happy about the configuration. And before pushing the ACL, we need to actually redirect the traffic to the dpu.

And that's what I'm gonna go and do here. So this is a simple configuration. We are just saying the VR F1 is gonna be subject to filtering.

And um, this is the same config done through Nexus dashboard. So here through Nexus dashboard, I select A VRF, I assign it to the Smart Switch, and then there's a knob where I say secure the VRF, uh, the knob is there, and then I can either choose manually which DPUI want to use, or I can let, uh, the software decide it for you. And right now I push that config and you can see that traffic is being sent to dpu, but nothing is being received.

So 300 frames per second are going to the dpu, but nothing is coming back. And that's because there's a default deny. And we didn't configure the, um, rules to allow the traffic on hyper shield.

So we need to fix that. So the next configuration consists in entering an A CLA stateful ACL, uh, to allow the traffic. So here I'm gonna configure the rules on, uh, hyper shield.

So it's a bit fast forward, otherwise it's gonna take too long to see all my typing and after the configuration is done, which is what you see there. And the, also, there's another rule that I put there, which gonna use later, but the key rule is the allow all rule that we entered. And now you see that once I push that rule, traffic is being sent and received from the DPU.

So now the, the security rule is allowing the traffic to get back to get through an interface to the other one. Okay? Uh, but now let's see, if I want to drop some traffic, I could change, I already have a rule in place to drop UDP on a specific port, which I chose to be port 80.

So if I now modify the traffic generator config to use, not the previous port, but port 80, uh, now traffic will be dropped. Okay? So now if I look at the traffic received on this interface, it'll be zero.

Okay? So we still sending traffic, but nothing is received. Now I could delete that rule, and then after I delete the rule, traffic will be again reaching the destination.

Okay? So that's configuration Hyper shield, I push that configuration. And then, um, the only rule that is left is the allow all rule.

And you see that traffic now is getting back, uh, to the traffic generator at the rate that we're sending it. And if I look at the counters on the service ethernet interfaces, you can see that traffic is being sent and received, uh, at the correct rate. So hopefully it was not too fast.

Um, but the key point is that we, here, we configured traffic redirection to the Smart Switch, then we configure the rules on Hyper shield to allow the traffic. And we demonstrated both adding a rule and deleting a rule, one rule to permit the traffic. And the other one was to deny the traffic.

So Question, uh, Josh from diversified, from an, from a policy perspective, if we're talking about now we have Hyper Shield as a part of our policy engine, right? And we have to mirror some of that with our contracts in a CI, we have to kind of have both concepts on both sides, right? To do the demo that you gave is, is Hyper Shield doing any of the contract management in a CI or vice versa?

Or there would need to be some sort of abstraction between the two, or the SecOps team would need to be involved on one side or the other to handle that policy abstraction or orchestration? No. So Hyper is not managing any contracts in a CI here, the contract configuration is very simple.

It's just saying redirect to traffic to Hyper Shield, right? So there's no security filtering done on a CI in this case, all the security filtering is performed on the Smart Switch. Right?

But if I am doing some substantial amount of contract management on a CI mm-hmm. Not doing that redirection, right? I am managing policy in a couple places depending on the size of, of The environment.

Yeah, yeah. You yeah, exactly. You will be doing that in that case, yes.

Yeah. So just to follow up on Josh's question, I, I would imagine, and I'd like to hear from you that if I've got an a CI fabric and it's built out and I've got some EPG that I wanna filter traffic, but I don't need others, I could use a surface insertion in order to be able to specifically target the traffic that I want. Is, is that correct?

That's correct. So you would use the Smart Switch attached to a Leaf mm-hmm. Like an external firewall in this case, and then you would define exactly what you're saying.

So you could define an in PG contract or a contract between MPGs with Service Graph Redirect, and that would redirect the traffic to the, uh, smart Switch. And then you would be filtering on the Smart Switch. And then, and then kind of the flip side of that, if I had for some reason or another I needed to filter all of my traffic in a CI, is there just a way just Well, other than, I mean, you're still gonna be relying on the a CI contracts to be able to direct traffic, correct.

In the same manner as Exactly, yeah. So in that case, if you really want to do that, you would do a busy NE redirect to redirect all the traffic to the Smart Switch if you wanted to. Uh, keeping in mind that the Smart Switch throughput is 800 gigs, so one has to evaluate if the throughput performance is what you want.

Yep. Um, but yes, But it would be the same with any other firewall that I was gonna choose. Exactly.

Exactly. Pick From, you know, Exactly. More Traditional firewall.

Exactly. In this deployment model we showed. Yes.

Yeah. Yeah.