Cisco Nexus Smart Switch and Hypershield Integration

My name is Java Skar. I'm here joined by Jacob Rapp and Maurizio. Today we'll cover the, uh, secure enterprise data center, and, uh, the focus will be specifically on the Nexus Smart Switch and Hyper Shield integration.

This is the solution today. We will launch that, the keynote. And I want to tell you a, a quick story about this.

We started with this project about seven months ago. We had nothing, and within seven months, we built hardware. We built a software stack we committed, and today we are launching, so from, from concept to launch in seven months.

And we, we are going to FCS this product in April of, uh, by the end of April this year, and then GA after that. So let us get, uh, dive right in into the overview. So if you look over here, we are basically infusing security into the data center Fabric.

Data center fabric has typically been a networking stack only, but now with security integrated natively, it'll be a native capability of the data center fabric. So to do that, we are introducing the Cisco, uh, nexus 9,300 Smart Switch family. We are looking at two products to start with two platforms.

The first one is a 24 port hundred gig switch. Uh, it has a silicon one as a forwarding chip, and it has a two, uh, it has four MD DPU for hardware acceleration offload, and it can do, uh, up to 800 gig of services or offload, uh, throughput. Uh, and the second, uh, device is, uh, the first device is targeted for April, 2025, uh, FCS.

And then the second one is, uh, uh, a top of rack switch we are building, and that's targeted for July. And this one will have, uh, basically 48 ports of, uh, 10 25 gig, uh, six uh, ports of 400 gig and two ports of, uh, uh, uh, a hundred gig. It, it has silicon one E 100, uh, version, and the two MD glio dpu, you know.

So with that, the service will integrate into, uh, the DPU will be, uh, hyper shield and hyper shield will provide layer four zone based segmentation and some other advanced capabilities that we will get into in the, in the later part of the presentation. And we are targeting four use cases, uh, in Cal in this calendar year 25. The first one is, uh, cloud edge for cloud on-ramp and off-ramp for hybrid cloud connectivity.

The second use case is a zone based, uh, segmentation. Uh, if you have a data center fabric to, uh, give you a zone based firewall capability. And then the third use case is data center interconnect.

So if you're trying to connect two private clouds, DC one and DC two, you can use, uh, use the, uh, these, uh, platforms for the firewalling between two data centers. Then in the summer, uh, in the summer, we're gonna launch top of rack use case. That's the second half calendar year this year.

And both of these switches will perform as the top of rack switches. This one, the first one will be a hundred gig top of rack. The second one will be 10 25 gig top of rack.

So if you look under the hood, what we have is really the best of class we have. The first one is the silicon one, which performs the best. Uh, E 100 is optimized for data center use case, and it performs the, uh, data center networking, you know, with Nexus OS capabilities.

And then we have the A-M-D-D-P-U, uh, which we are using to provide offload services. The security offload run, uh, is done by Hyper shield, and we'll get into the details of that in the subsequent, uh, slides. So if you look at the smart switch, if you look at, uh, from a topological perspective how the connectivity works, what are we, what is the benefit we are bringing to customers?

Uh, one of the main benefits is device convergence. So typically before, uh, today, what if you have a data center switch, the external firewalls are, are attached this way to the ports. So over here you have a one switch with four firewalls, for example.

Uh, and those are like five devices. We can consolidate, consolidate that into a single platform. Uh, single switch.

The forwarding is done by the silicon one, each DPU can be, uh, modeled as a firewall, okay. Or doing layer force segmentation. So if you, let's go over the packet flow.

So how does a basic packet flow look like? So over here I'm showing A-A-V-R-F, uh, a layer three VRF that is basically, uh, carrying a cust uh, uh, uh, application traffic. And, uh, we want to give this VRFA stateful firewalling capability.

So step one is basically traffic comes in into the network processor, which is the silicon one. In the network processor, we will, uh, look at the incoming traffic and do a routing lookup and derive the VRF. And then we will know, okay, it is VR F1.

And then over here we will have a policy that will say, Hey, VR F1, we want to redirect it to pin it to DP one. So we'll send the traffic to DP one. The, in the DP one, we'll have a firewall.

Hyper shield will have a layer force segmentation, uh, uh, uh, policy. It'll do the segmentation, it'll do the filtering of the packet firewalling, and then it'll, uh, return the traffic back to the silicon one. And then once the silicon one gets it, it'll do a, uh, a egress, uh, uh, it'll do a regular switching lookup and then send it out to the right egress port, you know, where you have the routing and decency.

So that's the basic packet flow. It's very straightforward, you know, um, everything is in line. Now from a troubleshooting workflows Question Sure.

Previous slide. Um, does it work irrelevant of what kind of fabric you have, whether it's VX and a CI? So today, this is, uh, we'll get over, we'll go with each fabric type in the use case section.

I could Possibly rewrite an EPG, for example. So for example, uh, initially this is targeted for nexus fabrics, but you can make, use this in a a CI fabric in two use cases. One is a zone based firewall and a cloud edge.

Okay? Yeah. So right now, this is targeted for NXOS direct type, but that is a use case for, we'll get into that.

Okay? But there's a plan for a CI, but that isn't the, it's a, it's kind of a little bit in the future. So now, if you look over here from a troubleshooting workflow, what we came up with is also, now you have two capabilities merged into 1 1 1 device.

So we need kind of some new capabilities to do troubleshooting, uh, you know, across two domains, uh, two functions. So what, what we came up with is a, a, a packet flow tracer. The packet flow tracer is a five topple, uh, tracer.

You can give a five topple flow, and then you can launch the packet tracer and it'll go along the entire path. And what it'll do is it'll collect data like, like traffic stats, state, all these things, health information of the, that flow from the, uh, from the routing side, it goes through into DPU, looks at the DPU, uh, firewalling, uh, uh, capabilities. What's going on over there.

Gets, takes that information, appends it in the, into the payload, and then comes on the egress, and then does a egress, uh, pending, a pending, and then it gives to the, uh, a, a di A, you can do this in the CLI or in the Nexus dashboard, you know, for troubleshooting. And then the second thing is we also have a packet capture capability that we are building that you can do the packet capture on, on the ingress of the NPU egress of the NPU or in the DPU as well, or from a troubleshooting standpoint. So these are basic tools we are building to support, uh, customer, uh, deployments.

Now, I'll, I'll hand it over to Jacob to cover hyper shield. So my name's Jacob. My name's Jacob Rapp, and I lead product management for Hyper Shield.

So I'll go over a little bit about hyper shield and how it relates to the, the, uh, nexus, uh, uh, smart switch, uh, we are building. So, uh, first of all, I think, um, Java's gonna cover a bit more in some of the use cases of how we're actually melting some of the security into the, the network itself. And there's a lot of just this operational simplicity and actually combining not having the hairpin traffic through, through these zone based firewalls anymore by actually building into the network fabric itself.

So we'll go over some of those use cases and how making, how that makes, uh, operational simplicity a lot, uh, better for customers. Um, but, uh, for hyper shield perspective, I wanted to quickly go over some of the, uh, more advanced security use cases that we get out of, uh, hyper Shield plus the Smart Switches. Um, couple of them, uh, obviously is kind of, you think about change with security.

Change is some of the most risky parts of security. When I'm going and making some broad changes to my zone based firewall policy, while I'm just updating kind of more granular mac, uh, micro type segmentation policies, or I'm just updating code. These all happen tend to happen in these big change windows on a weekend, um, on a, um, a holiday when someone really doesn't want to be on call, but they're on call because there's big change happening.

Can we simplify security a bit more as we start to melt into the network? And at the same time, can we make even security better? So Java mentioned we're doing, starting with layer force, zone based segmentation.

Where do we think about how layer seven moves in the future in the data center? And how do we actually keep up with, um, that, uh, security when encryption becomes really pervasive across your entire data center, doing layer seven stuff on the network starts to become harder and harder. So where do those controls shift?

Do we need a new set of controls to work alongside our segmentation controls moving forward? Um, that's all kind of pieces that we're, we're trying to solve with bringing Hyper Shield as the first service within this Smart Switch. So, just to recap of, of Hyper Shield, let's go over this quickly.

Um, we launched this last year, um, but we've been, uh, working with a lot of different customers on, on bringing our enforcement points and helping, uh, uh, customers with their security problems. The first thing we were doing when we built the Hyper Shield, uh, when we talked to customers, they said, don't build another product you need to fix and kind of combine the outcomes into a single solution. So we talked about security cloud control this morning, I think G two up on stage kind of talking about the whole broad security, cloud control vision that we're bringing together.

So we actually started to build a whole platform. So think of this as their AWS console for security, um, services. So this is where all of our security services will start to come, and within that Hyper Shield provides a number of outcomes.

Last year we launched autonomous segmentation, which we'll start to bring into the, the Smart switch as well, distributed exploit protection. And now we're bringing the, the layer four zone based segmentation policies within the, um, the smart switches itself. Um, with that, we have a number of enforcement points within Hyper shield, but work together.

They're not disjointed enforcement points. We have enforcement points directly within the kernel of the workload. So if you think about like, what was traditional layer seven policy within, uh, say a traditional firewall, you have things like layer seven app IDs.

There are a reason why Windows says assume there very, very little. I just, yes. Yeah, yeah, Yeah.

As well as VM appliance. Which VM appliance what? Yes.

Yeah, absolutely. So the, in the workload, we use a technology called, uh, EBPF for extended Berkeley packet filter. That was a way at kind of bringing controls sanctioned inside the kernel.

It started in the Linux community, and it's been around for about a decade, but it takes about a good decade for, for those types of technologies to mature. And it's kind of like, the idea of it is like, can I have sanction controls inside the kernel that are delivered by Linux or, or, or Microsoft directly? So it's not a kernel module because there's lots of issues with, if I write a bug in a kernel module, we all know what happens.

It could cause very bad things to happen. So Eeb PF is sanctioned by the community. There's a verifier before anything gets put into the kernel.

There's lots of checks around making sure we don't have infinite loops or memory out of bound conditions. A bunch of things to get into the kernel. So that started in Linux, but we're working, uh, with Microsoft on bringing that to, uh, the Windows, uh, world.

There was already an add-on to Microsoft to Windows previously, but now this is kind of the next gen solution. Um, and I think that's some of the cube cons that were, uh, the I valent team, uh, have presented some of that work that we're working on jointly with, with them. So that's why our Windows is staying soon because, um, that work is in progress on the Windows side.

Um, the VM appliance, is that basically a virtual form factor of the Smart switch as well Ahead? Other kernels? Like, So right now we're, we're focused on more of the data center side and not the, not the, uh, end user compute.

There are plenty of BSD based appliances out there Yeah. Being used in enterprise, uh, data center world as well. Yeah.

You want to have Eeb PF all over the place. Yes, Absolutely. Yeah.

I think that's the long-term strategy is to start to get, to make it pervasive as well. But I think as in terms of enforcement points, if you look at security cloud control, we also, uh, support, um, uh, the, the secure workload where we can also tap into IP tables, windows firewall, and other aspects of the, the stack where EBPF may not be ready yet for, for all the enforcement. So that's the, the, the, the good part about having security cloud control kind of being on top and managing the rest of the endpoints.

And for Windows. So there's on EE BPF on the website, something for server 2019. So will not be all Windows operating system with different code will be Yeah, 2000.

Yeah. It'll be, uh, it'll that mean TBD from Microsoft. 'cause ultimately Microsoft controls the release of EBPF And, and the Hyper Shield ideas.

At the end of the day, the new, let's say Cisco switches that are having the Duss and this enforcement, you can put the same controls, like your controls could stretch over the old workload enforcement over the new devices. And you have kind of a sim, um, unified policy layer that you stretch across these. Yeah, Exactly.

Yeah. Perfect, perfect segue into the next piece. Well, we can hop back into the, the architecture slide as well and, uh, as we go.

But yeah, that's the whole idea, is we have a single intent based policy that you write your intent at the top, and then we can take care of compiling it to the right enforcement point. It's order of dependent, and we take care of policy placement. 'cause our thought process is, is that at scale across infused in the network or at every single workload, no human can actually try to figure out where to place the policy.

So we take care of that policy placement engine. A good example of a policy that, uh, I use that may span both, let's just say I wanna write a, write a policy that blocks all web servers from being jumped posts. I wanna be able to SSH in or kind of access the, the web server, but I shouldn't have, I shouldn't be able to SSH out.

So from a policy perspective, I can write, I, you can write that in a single policy layer up here, but we may translate it in two different places. With an eeb PF say at the very top, if I have the Eeb PF components, I'm able to actually write a policy that blocks SSH from opening a socket. It's not flow table, it's not blocking a port and protocol.

It's actually saying SSH cannot open a socket to any, any destination, but it can accept connections. But I may also wanna apply that as a guardrail policy still on the network where on the, on the dpu, I set the policy and match all the ips, the web servers, and still put block the port ranges for SSH there as a guardrail that catches any of the other workloads, as well as just having a, a hardware separation of, of security policy still. And from a scalability perspective, have you tested, how much policy can you put on the new DPOs?

Uh, what is kind of still in the supported range? Yeah, we're working on the final numbers. So we haven't published the numbers yet, but it's, uh, we'll be at a fairly impressive range because essentially the DPU is all intent and purpose is a, a, a firewall.

So you're not gonna run into like a tcam limitations or things like that. It'll be in a very large scale roles. And all the customers we're working with early on across financial industries or healthcare, even some service providers, the scale numbers they expect are, are fairly large.

But we haven't, we haven't published them Yet. So not this three digit number, more four digit number yet. It'll be a pretty large number.

Okay. Good. Policy enforcement, like blocking an SSH opening a socket.

Yes. Um, what I would use a pervasive technology like well, easy rename SSH to whatever process I want to rename and then open the circuit. No.

'cause, uh, ultimately there's, and if I go kind of one step deeper into the enforcement point, right? So EBPF is natively within the workload itself. You still, you need a control path to eeb PF.

So we use, uh, an agent called test rack security agent. It's super lightweight compared to most agents out there. Uh, we actually under the, underneath the, the, the underneath the hood, we're using a open source project called teon, which was developed by IS valent, which is we we acquired last year.

Um, so all the core is open source. That's super important to customers is have like an open source core for what we're building. Um, here we can actually start to profile the processes.

So number one, yes, you can match on the process name, but we can also match on the process hashes, or we can actually start to see processes being renamed as something different. Part of our autonomous segmentation, which I don't, we can cover in a different session. I wanna focus more on the DPU switches.

Um, we can kind of actually start to look for deviations and profile different changes as anomalous and, and, uh, uh, protect against those as well. But there's a lot of work we're doing in inside here from a autonomous segmentation standpoint. Um, but those would work alongside our other network enforcement points as part of it.

You can go back to slides. Um, what is meant by AI native security? Perfect.

What is, what is the base security? Absolutely. Ai.

Yeah. So immediately everyone thinks of ai, they think of large language models and like, we're gonna send all the customer data to some model and customers get freaked out over that possibility or, or scared of that possibility. Um, in general, what I mean by AI native isn't that we are doing, using large language models to generate compensating controls and some really interesting work behind there.

But what we mean by AI native is actually how do I make sure that anything in ai, if I have my own AI model as a customer and I want to make, use my the system to, to roll out changes in an automated fashion, what do I have to for checks and balances in the architecture? So that goes along the, the idea of this self qualifying updates. So these kind of two go hand in hand.

AI native means that I have a system that can actually test in real time the assumptions that AI makes. So we do that with what we call our digital twin technology. And digital twins come in a couple different form factors.

The form factor for the DPU switch is with what we call a dual data plane, um, architecture. So if I go to this, uh, next slide here, um, we are implementing what we call a dual data plane, um, in every one of our enforcement points, um, that is a network enforcer. So in the VM appliance, which is just a VM version of the DPU switch, um, think of it as like a virtual firewall.

Um, uh, the, I I do want to get back to that because what, so is that VMware? Is that, uh, KVM? What, what, Yeah, so we can get, we can, we can bundle all different, but lots of different ways.

We can bundle as a container an OVA and, and an AMI for an AWS. So it's just a, a general purpose like software firewall that we can bundle and use in different, different places. Um, where, uh, you, you don't have the ability to put to place, uh, the new hardware, uh, pieces at, but again, you'll be constrained to kind of the same issues of any VM appliance.

Um, with it just not as scalable as the, what we can do by building into the network. You're not integrated into whatever you, you're just going to provide an OVA or something. Yeah, it's, it's, yeah.

So if you want to go fully in like deep within the kernel, that's where the EVPF controls get you. But this is kind of what, if I go back to this slide here, those are the two form factors. Network enforcers, kind of like outside the workload, VM workload enforce is kind of the inside, inside view as part of that.

But if I go back to the dual data plane, um, architecture, this is kind of where I get to the AI native, is that we build those digital twins as a dual processing pipeline in every single one of our enforcement points. So in the DP U switch, we have, uh, the pipeline built into our fast path, um, where we do parallel processing of every, uh, very policy, um, statement that's, that's being made. We're not actually duplicating the traffic, um, because we utilize some shared memory and some actually some really interesting, uh, uh, tricks that our, our developers came up with, uh, that we're not like having the bandwidth or something like that.

That's the first question that usually comes up. Um, but we're able to like run that, uh, parallel pipeline for all of the different, um, policy statements. So we're starting with policy, and then we'll start to bring that also to, um, all of our different software components too.

So can I run, can I upgrade my, um, software on the, the dual data plane and then test it in real time across all of the different enforcement points, uh, before I start to then promote it and do kind of a canary blue-green deployment scenario when, uh, with my, uh, policy or, uh, or my, uh, the software upgrade? And that's kind of the goal of like, how do I make security operations better and, and make change normal as a normal activity. So when I have ai, the LLM versions of AI, trying to recommend policies changes, you have a really good way to test it and validate those changes aren't gonna break something or don't have a, a a effect that you didn't intend, um, because of the model or something doing something you weren't weren't expecting.

So with that, I'll give kind of a couple examples of this and we'll, we can keep, uh, keep rolling through. Um, this is the policy testing version. So this is working today.

Um, this is, uh, something we've had for a while from the VM appliance form factor where our policy, our policy framework that we, that we, um, use. And, uh, and Mauricio was gonna talk a bit more about what that policy framework starts to look like. What we have is active drafts in history, we kind of follow somewhat of a GI GitHub methodology where active is kind of your, your main branch where everything is in production on drafts or when you want to make changes, you basically check out, um, a version of that, uh, policy or, or software and say, okay, in the drafts I'm gonna make changes in my drafts.

And then before I promote my drafts to back and merge in the main branch, it goes through a testing cycle. And when it starts testing, it actually starts to test that policy group across all of the infrastructure, um, where that policy needs to, to apply. And then finally, um, it'll give you a confidence score and a, a bunch of results around, um, around the policy.

And it, it covers a bunch of results such as just CPU memory latency metrics. It also, I didn't take the rest of it there flow, there's hit counts for the, the rules and so on. So we're able to actually, uh, reason about what those policy changes are and give you kind of a confidence score, um, when we, when we go, uh, change a policy or do a software upgrade, It was a little bit like a bit a better release or something.

Yeah, Pretty much. Yeah. Yeah.

Draft is kind of like a beta release. So I'm gonna try it out in my shadow data plane before it hits production. And if I, if I wanna do a rolling production upgrade, you can do that.

Um, with that, is It possible to a four to do a four I principle changes For I principle? Yeah. So there are two folks con checking and validating that these are valid chain or the, a little bit more high secure environments or high operational environments.

You want to have a double human check to know for sure that this is actually violation of any, Yeah. Anything else? Yeah, AB absolutely.

I think those are kind of the next steps. It's like we don't do every, anything autonomous at this point where there's always a human check. And that's kind of where there's like, my confidence score is probably never gonna be a hundred.

There's always at some point, like there's a human review process that goes into this, especially for like large pa like drops or changes in flows where I'm, my, I may be doing exactly the intent you said, but I may be doing that and dropping a very critical application. So I always want to have a, uh, a, someone checking and, and understanding that. And then as, uh, G-tube, uh, announced, I think Tom announced as well this morning, we, we have a universal AI assistant that can also, um, we're thinking about like, how, how do we use that to auto generate like your draft of like why this change is acceptable.

So it was like, the big part of policy change isn't just the, hey, is it, is it working okay? It's the let's, let's have an audit trail along the way. Um, every step along the way, uh, to prove to the auditors and everyone else in compliance that this change is, is acceptable and meeting the, the intent that you had, uh, for it.

So that's, I think where our a, a agent and our universal AI assistant will help quite a Bit. I have a question for that. A pain point in traditional ing was often the deployment time.

Yeah. Somebody, it's nice, you have this, you deploy it, you see, oh, it's breaking, people cannot work anymore. Then it takes, I don't know, 15 half an hour to robot.

How fast is policy updates happening in the system if you need to roll back something or, so It's instantaneous. So I can, in my dual data plane, I can, I can So Just flip them, Right? Flip them because they're, they're both active a hundred percent of the time.

And just at the end of this one, I choose to use the primaries result versus, so that's Where have the shadow one, so you can simply enable the shadow one just in case. Yeah. So if, if I switched my primary to my shadow, then my shadow still remains, it, it, the primary still remains using the old version.

So if I ever wanna roll back, it's just a matter of like saying, okay, use this one evaluation versus this evaluation. Ah, okay. So The dus in this case, already programmed for both.

Yes. This is why you can flip so far. Yes.

But if I need to roll back even to something else, then it will, uh, take longer. Or what is the other policy? Uh, Yeah, it's just a matter of like, how, uh, can I actually, I can, I have, I can keep track of my changes.

So if you look at back here, we do have a history of everything that we can go back, back in time, uh, to add those two, we would probably go through the testing cycle again. So probably To validate that what you do is look at the, the one of the changes that is in the history, and then you'll probably then deploy and the other data plane that you have there in parallel, and then you'll switch over to that one. So you, you would always go from one data plane to another and then putting a different version of the policy, right?

Yeah, exactly. Yep. Yeah.

And then we would just kind of load the policy on the shadow again. Yeah, just make before break. Yeah, exactly.

Yeah. But there's lots of interesting options that we can do, and that that's really the goal of making change normal. So we can test, I know I'm running, uh, over my time, so I wanted to make sure we hop into the use cases and cover the DPU use cases of where we, where we feel like this is gonna the first entry point for customers for the, the smart switches.

Okay? So we'll cover the u use cases now. So the first use case is the cloud edge U use case.

So this is for cloud on-ramp and off-ramp. So typically, if you look over here, this is your private cloud, this is your public cloud on the right on on that side. And then in the middle we have the cloud, cloud edge colo site over here.

Now, the thing is, typically before, what we're saying is typically before the smart switch, the DMZ, this is the DMZ and the DMZ for hybrid cloud connectivity today from public to private cloud, the firewalling is all done in the DMZ today. And the DMZ is a single point of failure for customers. And this is not something Cisco came up with.

This is all our customers are telling us. Actually, there's some of the largest banks, uh, in the world, uh, in, in, in us, Europe, and Asia. We worked with them and we were looking at the DPU, uh, the SMART switch, how to use that with hyper shield.

This new use cases, this is a use case, came from customers. What they're telling us is, uh, the DMZ is a single point of failure. Um, and, uh, today, uh, uh, it's very inflexible from a routing standpoint.

You cannot do optimal routing from a public cloud VM to a on-prem data center vm. You have to do traffic engineering. You force the traffic into, uh, the, the, the, uh, DMZ, and then it gets firewalled, and then you go to trombone the traffic to the different data centers.

But one is routing complexity. Second thing is, uh, in the data center, you can only buy, uh, big, big iron firewalls and scale up. You cannot horizontally scale up, scale out.

That's two. Number three is, uh, it's very expensive. Those are very, very powerful, very expensive multi asic fire, uh, uh, devices.

And then they also have a high I, because the firewalling part works perfectly and that, but that is maybe 30% of the actual work you do is configuring firewall policies. But 70% is you're managing the lifecycle of those big iron devices, upgrading them, you know, getting maintenance windows. So what we came up with is a simple solution.

We can solve that by putting the, uh, Cisco Smart switches over here with hyper shield, doing layer force segmentation right here from the public cloud. You can terminate the ED, uh, direct connect and express routes directly over here with the Max stack tunnel. With Max Stack on those, uh, uh, tunnels.

And then we do firewalling first. The first thing we do is ing, and then we do routing directly to the data center bypassing the DMZ. But that's the use case of Cloud Edge.

And this is basically a NNI to NNI, you know, so, so this is a first use case we are launching in, uh, April. Okay? And this one, this use case can be used for all, any data center fabric types on the on-prem.

You can have Cisco data centers, you can have a a CI data center. You can have a Nexus data center, or you can even have a third party data center. Okay?

So the second use case is, uh, zone based firewall. So, so if you have, let's say, a A CI, uh, fabric or a nexus fabric, you'll have, let's say two tenants. You have tenant prod, you have tenant dev, and for inter tenant communication, it all typically goes through a zone based, uh, stateful firewall.

Uh, so what we are saying is instead of buying a very expensive firewall, you can drop in two a one pair of, uh, smart switches with, with hyper shield on it and HA pair. And you can drop that in, and we can offer the same segmentation that you're using, uh, doing today with a very high end, very expensive device at a fraction of the cost. But that's use case too.

This use case will, when you deploy this on the fabric side, if you have a CR you have a service graph, there's no change in the configuration. You have Nexus data center or even a cover competitor data center. There's no change.

You just drop this in and then, then you do a L three connectivity. That's it. Okay?

So this is the second U use case. The third use case is the data center interconnect. If you have two data centers, let's say this is in Amsterdam, that where your remote data center is in Belgium somewhere, and all the incoming traffic on the border leaves over here will get inspected, will get filtered first, and then it gets routed into the data center.

So that's use case three. Okay? So these are the three use cases we will launch in April.

Now the fourth use case is the top of rack segmentation and enforcement. This is what we're going to launch in second half calendar year 25. Now for this one, we will have the, the both the, uh, uh, two switches that we have, the a hundred gig and the 25 gig will be used for this position, and they'll play the role of leaf as well as a border leaf.

Now, over here, the benefit is every, uh, every device in the, uh, every leaf becomes a firewall port in your data center fabric. So you can do stateful rule, uh, stateful, uh, rules synchronization across all your data center leaves. So the data center leaf becomes, uh, a firewall, a stateful firewall for you, right?

So we are starting this one with Nexus first, and then we will, you know, a CI is in the future for us. Okay? So this is kind of solving the problem.

I have appliances or devices that I cannot influence. They have maybe volume, abilities, whatever. I have a small firewall that already sits on this spot in the network upfront.

This, let's say unsecured device. And I can apply policy though all these nice, uh, let's say telemetry for the devices, even if this is an appliance where I couldn't implement, let's say EBPF natively Yes. On corner land.

Yeah. Yes. So, so to extend that further, if I borrow, I used, I I, I also work on a CI, if I use a a CI model, right over here, like how we used to explain A-C-I-A-C-I normalizes micro segmentation for container workloads, VMs, and, and, uh, bare metal servers and even mainframes, right?

So if you have a, a Kubernetes workload that you cannot have an agent Tess rec agent on, or, or you have a vm, you can do PV LAN all the way here. And we can, for all workloads, we can consistently give you a policy and, and stateful policy. Uh, and, and, and, and, and, and, and what you can remove is if you have agents like I Lumio agent or guided core or different probes that telemetry probes or virtual firewall or physical firewall, you can start removing those things.

Now, we, we are not saying you'll remove a hundred percent of the, of those, but you can start reducing. So you have less dashboards to go to and less things you have to manage. I think the other benefit here is, is clear all these agents suck up CPU time.

Maybe we have additional delays and so on. If this is programmed to the DPU, it's kind of line rate. The slide rate, Yeah, it's a before, uh, fast PO pipeline.

But I want to add to the, the point that, uh, very important point, uh, um, Jacob made the TE rec agent, uh, is it's a very lightweight agent that is like orchestrator of, uh, the, the, the, you know, uh, uh, uh, EBPF. So at the end of the day, the same methodology, the same EPF code just runs on the view. So you just made all the crafting that normally is done on the, let's say, operating system level into the network, and then you have kind of a faster, let's say, line rate thing without having anything on the end host system, which influences the performance STAs.

Yeah. Yeah. So, uh, when you compile the policy right from security cloud control, when it goes to the workload, it is compiled as A-E-B-P-F policy.

When it goes to the switch, it is compiled as a park policy, uh, which is something we will discuss, uh, later in the, the slides. I can have the exact same, Of course, you cannot do, yeah, You can't do process level on this way, right? Yeah, yeah.

Makes sense. Okay, let's continue. So this is just a kind of, uh, showing you a side by side comparison today.

Typically in our, uh, a cloud edge example, you have two switches facing the public cloud, two switches facing the, uh, private cloud. And then you have a firewall pair. You have six boxes.

We can replace that with two boxes, HA pair, you know, so that's a consolidation, cost saving less devices you manage is good. You know, you remove things you don't need. So let's get into the workflow.

Uh, one of the things is, you know, now since we have a one motherboard, we have two ASIC two chips. One is a network chip, one is a security chip. We're doing security.

How does your operational model change so large, like a large bank, they will have a network team and a security team. So what we were extremely careful is we carry that forward, that persona based workflows that exist. We do not want to change that.

How the customer, we don't want customers to adapt to this. We adapt to the customer from the day one. So what we've done is we have full separation.

The network team does network things, security team does security things. So for example, we can use Nexus dashboard to program. We'll manage the lifecycle of the switch.

Okay? You'll have single os, it'll install, and then there's a network policy. It'll push, uh, and it, and that's the job of the network admin.

And then the security admin will go to security, cloud control, and he or she will push the security bound into the DPU and for, uh, rendering. So that's the separation we have full, it is a full isolation, full RA, so we carry that forward. Um, so I'll hand it over to Jacob and then I'll cover, um, Cool.

All. Yeah. So, um, yeah, I think what Java has mentioned is like it's important to keep kind of the separation of controls, um, for the teams to kind of operate independently of this.

So if I think about how we start to onboard the switches and how we start to start to use them from day one, obviously we have the single image. So we can bring up the, the system. It has both the hyper shield bits, uh, control plane bits, as well as the NXOS bits there up and running.

What you do over here is request a token from security cloud control, apply that token so that the agent can then talk home to the security cloud control. From there, we can configure the VFS and how to what V fs you wanna enable the, the service firewall policies on. And then finally, you start to configure your objects and, and your policies within security cloud control.

So this is a pretty simple, straightforward workflow. We can automate it through APIs. Everything's API first.

So if customers want to bulk up, bulk, bulk onboard, all of these things are possible. You don't have to do it through the ui. Um, as part of part Of the framework, is it possible to run security cloud control OnPrem for digital sovereignty?

No. Similar to intersite, which you can do on dark sites, No security cloud control is a, a SaaS only, uh, option. So yeah, so customers that will willing to do this will have to adopt, um, SaaS methodology.

So it's not really for the, um, the, uh, uh, air gapped, like deployments. Oh, digital. So CD yep.

Yeah, I think we, we are working through, I mean, a lot of, with a lot of customers have, some of the customers have concern over that. So we, we we're pretty open about our architecture and how we can kind of work through passing tech risk audits and those types of things to get this up and running or doing that with a set of customers Right now, especially in like the financial sector and some of the service provider sectors are like sometimes nervous about having controls and SaaS. So there's a lot of thought around that architecture we put in and to validate with them, um, for it.

So what that looks like in the product is we have the two types of network enforcers and hyper shield, the, the VM appliance, and then the Cisco Smart Switch here. When you want to add a Cisco Smart Switch, we can generate a, a special token. And Mauricio, when he does a demo, he'll walk through how to apply these commands onto the, the Nexus switch.

But this is basically the token that we would generate that you would be used to onboard the switch here is showing a view once they're connected. Um, once I do this, I would have a pending state until actually you apply those commands on the Nexus switch. Um, it inherits the, the host name of the switch.

So you can kind of match which switches are, are available within the, um, the hyper shield control, um, for the, the, the security parts. And then here we just show which dpu are active across which, uh, VR fs for this. So you'll see, you'll notice here there's some static and dynamic, uh, pinning.

Uh, Mauricio will go over what the differences of static versus dynamic, but here's kind of a way to figure out how to share load between the dpu. 'cause the first switch has four DPU on them. So we can kind of share balanced load, either statically assigned it or dynamically assigned assign it.

But Mauricio is, it goes through the, the, the demo walkthrough. We'll go into some more, um, detail there. With that, I'll hand it over to Jed, the walkthrough, kind of the persona side.

Yeah, The couple of things, uh, uh, Jacob said I wanna recap, like the token generation onboarding of the switch. How do you integrate? So the, all that workflow will be between Nexus dashboard and, uh, security cloud control.

They will talk with each other East west way. So I'm just going to show you the actual automation and insights and troubleshooting. So over here in the Nexus dashboard, we'll have a automation workflow.

So I want to, the, what I wanna accomplish is I want to redirect A VRF to A DPU. How, how does it look like? So the first thing is I will select two Azure VRF over here, Azure Worth one and worth two.

Then what I'll do is I will select the DPU switches, and I will also select the, the dpu. We underpin these VFS too. I, I want this Azure VR F1 and two only.

Go to DP one, okay. In two both switches. So when I do that, then I'll get a kind of a configuration, you know, so I can check if the configuration is correct.

But once I, I'm good with that, I'll say push deploy, and it is deployed. So you'll see this, the redirect policy, uh, from the WRF to the DPU is, uh, is, uh, uh, it's, uh, provisioned. Now, this is a UI workflow.

Uh, you can use UI or API, both our, uh, options for the network team. So over here, this is insights. So, uh, what we've built in the next dashboard is the full insights of, of the DPU switch.

So this is the DPU. If you go further, I had to cut it out because of the slide for the foot footprint, there's this lot of operational details, stats, and all those things available. So on this DPI have 15 ports enabled, but what I see is I see some anomaly.

Now, the system that, and the next dashboard will automatically detect those anomalies and, and give it, give you the summary. So if you click it, what you'll see is, you'll see this type of view. So over here I have a, a, uh, Azure VRF two that is in a leaf and spine fabric in a, in a late three BGP, uh, leaf spine fabric over here.

And this is the DPU switch. Well, the NPU is sending traffic to the DPU, but when the traffic is coming back, uh, there's something wrong with the traffic and it has nothing to do with the firewall policy, it's something else. It's dropping.

So when that situation happens, the Nexus dashboard will, will go as go to this level of granularity. It'll identify the root, where the root cause is. So once we get down to that, if you want to do the further analysis, you can trigger the packet tracer that we discussed earlier, that will go from NPU to DPU, and it'll, it'll give you the, and it'll come back and give you the root cause.

Okay? So that is the level of automation we have. Uh, so with that, I'll hand it over to Maurizio.

Okay? So, um, yeah, I'm gonna show you what we have now in terms of, um, based on an FT image or if you trial image. Uh, but before doing that, let me just recap on a couple things to understand what we are showing.

So this is how simplified view of the architecture of this switch and, um, the configuration Javi showed you. Last one was based on the Nexus dashboard. All the configurations in the demos are based on the CLI for the network configurations and for the security policies, they're based on hyper shield.

So security policy, who is allowed to talk to what is based on hyper shield, which traffic is sent to the, uh, DPU for inspection is based on the CLI configuration. Okay? Um, so yes, so the, uh, for the configuration, you go to the high pressure controller in the cloud, gonna talk over HTPS to the, uh, smart switch.

But for that to happen, the first phase of the demo is gonna be to how to, um, make the switch discovered by, uh, the controller. Okay? So there's the onboarding of the switch into the controller, and once we are in the controller, we define the policies based on this language, which is, I mean, in the end it's gonna be source IP, destination, IP layer four ports.

But the language that hyper ship provides to define policies is more, it covers more cases than just the IP addresses, right? And so it's based on the syntax that is called park principle is the source ip, basically in our case. So if we compile this to the DPU switch principle becomes a source IP address, okay?

Um, resource becomes a destination IP address. Um, actions, basically, if it's, uh, like DBPF process will be like, uh, if a process can read or write, in the case of, um, in the case of the DPU switch, this becomes the lay for ports and protocols. Okay?

So basically what you want to do on the resource you want to access certain ports effect is the permit, deny, permit plus log, deny plus login, and so on. Okay? Uh, so hyper pursued as this language, which is very broad, but in the case of the demo, you'll see that it basically allows us to define an A CLA stateful ACL, but an ACL L.

Okay? Um, now to get, so the first phase is, I was saying the onboarding, but there's another key point, which is, first you need to power up the firewall. You need to power up the DPU.

So once you get this next design case switch, uh, you, if you use it right away, it's basically an XOs device. So you can do routing, you can do, you know, routing protocols and so on. And so the traffic will just flow through the, um, uh, the, uh, the network processing unit, like a Classico device to get the traffic to go to the DPU.

The first thing you need to do is to enable to power up DPU, and you power it up by using this command feature service acceleration, okay? So you can also think of these devices, uh, device with two possible, um, use cases. One is just like a classic, uh, nexus, uh, switching device.

And the other one is like, uh, switch plus firewalls. Uh, once you power up the fi, the, uh, the firewalls, uh, the next step is to assign certain traffic to the DPU for processing. And in the first, uh, release, excuse me, this is gonna be based on V Fs.

So one VRF is serviced by 1D PU. Not all VR RFS need to be going through the DPU. You could have RFS that are not requiring any extra, uh, filtering capabilities.

There are the vfs that are connected maybe to the cloud for which you want to provide security services, and then you would want to assign them to a dpu. And you can either let an XOS distribute the FS automatically to D Ps, or you can manually define which VRF belongs to which DPU. And this is the syntax that you can use to assign them manually.

And that's, uh, for the first release, of course, uh, when we move forward, there will be other options that are not yet displayed here. Okay? Um, and then, uh, you can verify what traffic, no, how much traffic is flowing through the, um, DPU, uh, by looking, uh, at the counters of the special interface, which is a 200 gig interface, which, uh, is visible as service ethernet.

So with four D Ps, you have service ethernet 1, 2, 3, and four, and you can look at the counters and look if the interface is up and so on. So this is the internal link between the switch and the DPU as if this was, if it was an external firewall, you will look at physical interface on the front panel ports. In this case, it's all internal to the switch.

Okay? So now we have here, uh, the steps that you would take on hyper shield to define the policy. So first, okay, actually first you see network based enforcer because the switch is a network based enforcer.

Um, then to define the source and destination ips, you would define objects. So here you have the clients, uh, which is this IP range and servers, this other IP range. Then you would create the policy and decide if traffic is allowed or not, or dropped and, and whether it should raise a log or not.

And, um, once you've done with that, as Jacob was describing, you would run a test. And then after the test results, if you're happy with it, you can deploy to the switch. The test, uh, consists in having copies of the traffic going through the, um, the new policy so that you can compare the heat count on the shadow data plane compared to the main data plane that's, um, visualization that Jacob was already showing.

Um, and if you have new rules that were not there before, then the number of hits on the primary data plane is not applicable because it's a new rule. And then you would check the number of hits on the shadow data plane for the new, uh, for the new rule. Once you're happy with the results, you can then deploy and this will be applied to the data plane.

Okay? Okay. So with all being said, uh, now we're gonna see the recording of a lab demo that is based on an early field trial image.

So certain things you see here are actually gonna be improved. Just, uh, you have some visualization that were already provided by, uh, Jacob and by, uh, jt. Uh, but certain things here look a bit, uh, uh, engineering level, but that's because it's an early field trial image.

Okay? So, um, so first part is gonna be to enable the DPU. So, um, you have this command feature service acceleration that power out the DP, and then the first phase of the configuration consists in onboarding the switch on hyper shield.

To do that, we're gonna say that, um, the switch is gonna connect through, uh, this interface, which is look back, 100. Um, this is an existing switch that is already connected. Ours is not yet.

So the first thing we need to do to, to make it show up here under the network enforcer in hyper shield, is to, um, get a token, um, which we're gonna get, uh, one time password, basically. Uh, so this is gonna be integrated into Hyper shield, okay? For now, as you can see, it's basically, uh, rest cost, but it's gonna be integrated as part of hyper shield.

And the token has all the information that the switch requires to connect, um, to the controller in the cloud. Okay? So we need to take that token, and that token gets, um, so for now, we just see that as a pending connection after you generate the token, uh, because Hyper Shield is waiting for, uh, this switch to show up.

So what we need to do is to take that, go to the N-X-O-S-C, I enter the token, and then the switch is gonna connect to the cloud, and it's gonna show up into the Hyper shield controller. So now we are entering here the token, The requirement here, You need to have connection, Connection to the cloud, to these, let's say cloud back and URLs must be yes, is mandatory, okay? Yes, e or either directly or through a proxy.

The proxy is not yet in the FT image, but through proxy it's also possible And you just need 4, 4, 3 or anything else for the cloud. Um, it's basically SSL traffic. Okay.

Um, but there are a couple of ports and that we are listing them in the documentation that you need to open to let the, uh, GRPC, uh, to work through. Yeah. And, and where is the cloud?

So is that The cloud is, uh, I think we have, do you know, uh, JA Multiple. So we have, uh, multiple regions throughout the, the world basically, and all multi availability zones and so on. Um, but yeah, you just have, you have to, you have to be able to white, uh, allow, list a certain connections to that in order for it to connect up.

But again, if you have proxy, you can only, you can have just a single connection and not have to have every single switch connect through, um, in independently. And these clouds will run jut stack completely. So RPV six enables native, The V six will be there.

Yeah. Will we, our, is there, there, I mean, well, the FT images, uh, V four, but it will be there when we have CS. Okay.

Okay. So, um, here we have put the configuration in place. Okay.

So, um, now what we're gonna see is, so we put everything in service under the, uh, service. Um, um, there's the, uh, sys system service cyber shield, and then here we had, oh, I think, uh, we're back to, okay. Okay.

Anyway, so yeah, so it's onboarded. Now we're defining the security policies. Okay?

So we're defining the objects, uh, like you saw in the screenshots before. Um, so here we're defining actually the resources and just gonna put an IP and ENE. Okay.

Um, and this is defined as part of what's called the policy group, which is just a, the configuration container for, for the policies. And this is gonna be then pushed to, um, to the DP switch. Okay?

Okay. So this is just gonna be, um, permitted. The action is defined as TCP ports.

So T-C-P-U-D-P-I-C-M-P is all gonna be selected to allow the traffic. Okay? And since we are a bit, uh, short on time, let me get to the data plane if you don't mind, so that you can see traffic forwarding happening.

'cause otherwise we don't. So, so this is the configuration of the policy, and now we're gonna check the data plane part. So we have the switch, which is pairing with BGP on the cloud, and it's pairing with SIS with internal network.

This is, uh, the view of the dpu. Okay? But now we're gonna, I'm gonna show you that we have, um, BGP peering in place.

We have ISIS peering in place. Um, and then we're gonna send traffic. And in the first six, first test, we're gonna make the traffic just go through, um, the MPU and bypassing the DPU and the second part of the test, I'm gonna show you that the traffic is actually going through the DPU.

Okay? So the VRF you're gonna use is this one OCI one. And in the first test, I'm removing removing it because I'm just gonna show you that traffic is just flowing through the, um, NPU here on the traffic generator.

We are enabling BGP and A SIS to peer with a device. And then we're gonna send router traffic across. So if we now look at the configuration on the VRF, you will see that we have two interfaces there in place for the VRF.

And so one four and one 18. And you will see in the first example that the counters for those interfaces, uh, will be increasing. Here you can see that BGP is working, ISIS is also working.

So all the control plane stuff is basically in place. So we have adjusts for SIS and BGP. Okay?

Now the counters are still zero, and then we're gonna start the traffic generator, and then we're gonna see that the counters are gonna be increasing only on the interfaces that belong to the MPU and not to the service ethernet interfaces yet, okay? Because the VRF that we are gonna use for the DPU is not in the config right now. It's not into the, um, it's not assigned to the DPU yet.

So here we start the traffic, it's gonna send 1000 packets per second, and we are gonna see that the counters are gonna be increasing. Let me just, uh, we have one minute. Okay?

So if we look at the counters, you see that these ones will stay zero. But the counters for the interfaces that are connected to the BGP and ISS cloud, they're increasing. And so you see 1000 frames received from ethernet one four and going out on ethernet one 18 and nothing goes to the DPU.

So now we're gonna put the VRF, we're gonna sign the VRF to, um, uh, to the DPU, and then we're gonna see that the interface counters for the DP are gonna be increasing. Okay? So, okay, now we go back to service firewall.

We enter their V-R-F-O-C-I one, okay? You can either, you, you don't have to type this. In this case we assign it specifically to DPO number one.

So now you see that the, uh, VRF is back to where it's supposed to be into the configuration for the, uh, hyper shield. And then if we look at the counters, so actually here is the view of the interfaces of the DPU. And again, we have here traffic going in both directions.

So you see now the, um, ethernet one four, it's both sending, receiving 1000 frames per second, same for one 18. And then you, here you have the counters for the interface of the, uh, DPU. Now here, the DPU is receiving traffic from both and going down again, right?

So, so this DPU is servicing that BRF and, and the traffic is getting back to the traffic generator, which means the whole path is actually, uh, functioning. Okay? So that's, uh, and so the traffic is indeed going through this, um, following engine, uh, the DPU inspection engine, Just one thing from my security view of it is a very routed approach from my audit perspective.

Now I have to check every time was a policy actually enforced because I can control on the nexus, let's say management layer, if even the traffic goes to the firewall, uh, DPU layer. So kind of from an auditing perspective, this is adding another layer. I have to check on everything that I verified.

Was this, at this point in time, this traffic going to this DPU and then the policy enforced? Yes. No.

So it's kind of adding some complexity, uh mm-hmm. Maybe for some customers they like the flexibility and the, uh, let's say, uh, separation of duties. But of course then you have always two things to verify if something is policy.

But, um, wouldn't you have, wouldn't you have to do the same with an external firewall? Because there will be anyway, the external interfaces, you would have to, I mean, if you troubleshoot an external firewall, you also have that same level of Most people doing like the gateways always a firewall, then you have just one entity to deal with. Uh, it's on the endpoint and EPPF perspective?

No, it's on the, Yeah, I mean I think you would still have to redirect traffic to the firewall. Yeah. In some way.

This is just our internal redirection, but point taken, I think in future releases, we're gonna have options. We, it's basically can I send traffic, make sure all the traffic is going and then in absolute Yeah, in our dashboard as well. Exactly.

You can actually see and make sure that, that RFS and validate, but we can, we can work on some enhancing Auditing logs for these and to make sure at one point in time what traffic was forwarded and it's going to the policy or not. Yeah, nalytics digital. Yeah, exactly.

Does it do correlation though? 'cause I understand that you could be testing policies and you could make sure that things are deployed in the way that you expecting it. But what if you actually have to investigate?

Does it do correlation between the time you placed the policy and what were the changes after that and before that? Hmm. Well, actually I think also through Nexus dashboard and the, um, you know, we have all the tools to basically compare all configs with new configs.

So you can leverage all the other management tools that we already have that allow you, allow you to verify configurations on the Nexus products already that can do that, right? Yeah. We have, we have, we'll have full audit logs too on the hyper shield side.

'cause we have, we're, even though we're not configuring the VRF redirection from Hyper shield, we'll have the, the change logs. So we can actually see, okay, this was how VFS were, um, provisioned and configured and, and how they were set to dpu. And then policy changes alongside that.

So we'll have a full audit trail there, or you can also obviously have both send both audit logs to the same, a similar collector, um, for everything as well. Yeah. And for these you could even leverage Splunk.

Yeah, absolutely. Isn't it? Yeah.

Okay. So you can just put all the pieces together and then well eventually you would just need a bigger screen, I guess. Yes.

Okay, good. Thank you.