Cisco Silicon One ASICs: A100 and E100/K100

Hey guys. Tom Morgo, principal engineer. Um, I'm the AS six and iOS XE guy.

Um, so, you know, while Mohammed is talking about kind of like strategy and like, what is Cisco's bigger plan, specifically the, uh, uh, Cisco C 9,000 smart switches. Kenny's actually showing you the, the hardware I get to explain to you guys what's actually in it. Um, so it picks up from, from everything that they talked about, in fact, uh, the software roadmap and those kind of things, um, and particularly talking about, uh, it, it's organized to first talk about, uh, the Silicon one asic.

0. So this is a new generation specifically built for, uh, the campus. Uh, yes, they are being used on, um, nexus and a SR, uh, Cisco 8,000 products.

Um, but the point of these particular ones is the, uh, features and how high scale they are. So it's an entire family of asics. When we talk about silicon one, uh, and I slides, I'll go through it.

Um, but these were, if, if you imagine like these were built for that feature rich environment where other ones are just like speeds and feeds. They're, you know, they're fast, but they don't have a lot of, uh, tables. These are big, big tables.

Now, um, I started with this slide. It, it's almost a recap. Um, you know, when somebody says, uh, the C 9,000 smart switches, it's really gonna boil down to these three basic components.

Um, and surprise, it's not, uh, different components than we've shown previously. It's just like, what's different about these? So the, the asics themselves, that's the heart, you know, the actual forwarding capabilities of the switch.

Uh, and like I said, this new generation of, uh, Silicon One, asics, um, you know, they've used the term AI multiple times, hyper shield ready, uh, those kind of things. In this initial stage, it really means like application hosting. Uh, it's a containerized environment.

I can, you know, I can host a, a small language model there. I can use a machine learning model. Um, I can als, uh, hyper Shield is a containerized based, uh, distributed firewall.

So basically what you're saying is, I can host a firewall. I can host, uh, AI directly on there. Um, and Kenny kind of already touched on like bigger CPU.

He showed you the application hosting slides. Just apply that logic now to, to an AI SLM or a, a hyper shield. But, uh, the magic, the thing that actually glues it all together is cloud native, uh, iOS xe.

Um, it's kind of a buzzword that we, obviously we've had iOS XE for a very long time, but, but the last thing kind of Kenny was talking about where it, uh, you know, he said unified platform, unified software, and it just naturally would open a tunnel to, uh, Rocky Dashboard. It would naturally open a TLS tunnel to Catalyst Center. So hence the term cloud native.

It's just, it's automatically there. You don't have to like, get special boot or have to issue some special commands and so on. Right now, it's kind of a, a, a wordy slide.

I'm not gonna belabor the point. The reason I added this here was, uh, this is not Sean's slide. This is not even the, uh, Cisco 9,000 series slide.

This is from our Cisco ASIC group, our central, uh, ASIC group, uh, otherwise known as CAG. So, uh, work very closely with them. Um, you know, and, and sort of the things that we talked about, like why, why did Cisco even move to this new series of asics, um, speeds and feeds is an easy one.

Obviously we need that. Um, but in the campus, uh, enterprise environment, it is very much about like things like adaptable tables, being able to change the number of Mac addresses I have or change the number of, uh, access control entries. Um, you know, can he talk briefly about net flow and those kind of things.

So it's very much it for this new generation, uh, about features. Um, I'm not gonna read all these off, um, but, you know, talk about the, the native encryption. So that means specifically things like EC IPSec cooked into the chip, right?

Um, now this is a, a spec sheet. Um, I don't expect anybody to memorize this, but I, you know, I thought we'd have a good nerdy one. 0 to signify that, hey, this is a brand new generation, like the, the way the processing unit works.

Um, and you've heard Kenny talk about like kind of the bandwidth capabilities, um, talking about the greater scale, and I'm, I'm gonna go into these in detail, but I just wanted to kind of see it like a, a spec sheet. Like, wow, you know, the, uh, 93 50, the, the fixed class doing 256,000 routes. Um, and then he mentioned like 2 million routes on the 96 10 coming from these asics.

And the other key thing is that it is common between them. That's even why I threw in that Cisco Asics slide. It's like, whether it's a, you know, a, a Cisco C 9,000 switch, whether it's a nexus, whether it's a service provider, all of these are common attributes with a common software development kit.

Okay? Now, this is kind of a long one. So the, the opening one is precisely that.

I'm not gonna list off all the things. What I really want you guys to see is kind of the, the, the high bullets that common architecture, right? Whole bunch.

And, and this is also true with the previous generation. Um, what this slide's trying to do is kinda show you what's different, what, you know, what's the new thing I'm getting with this? A 100 and K 100.

Um, we had longest prefixed match. Longest prefixed match is your routing table. That 2 million routes, two 56,000 routes.

Um, so it's already there, right? But what here is the efficiency. How do I actually pack the individual route entries into it?

Um, it depends on how like, good the memory is, but if it's, if it's not very good, uh, you'll wind up with an inefficient program, you'll get like 70% out of it, right? This gets you to, uh, beyond 90%. So when I say 2 million, it's like you're actually getting 2 million routes out of it, right?

Um, exact match. It's kind of, it means like I have to match every single bit, right? Uh, but this is where your Mac addresses your arp.

Um, things like, uh, sgs, were very big on, um, you know, this, uh, fabric and group based policy. This is where I store the sgt. So the bigger this table is, so it's newer and larger, uh, significantly larger.

2 million entries. So that's how I can have massive MAC address scale. I can have massive, uh, SGT scale and so on.

Now, the, the real, uh, money shot, the thing you, I want you guys all to kind of remember, it's a new acronym, uh, is hcam, okay? Um, and it's really, it, it is a tcam, and it, it is the thing right here at the, uh, the first bullet, uh, it's a hash based algorithmic tcam, right? That's some fancy words.

Um, what we realized is, and, and I have a slide on exactly this, that, hey, you know, um, TCAs are very, very expensive, uh, but the, uh, traditional types of memory, like sra, dram, they're not that expensive. What if I put them together and bring you guys back to massive ACL and NetFlow scale, right? These are like the critical sort of campus things that people care about.

Um, I do have a dedicated slide on this. Um, and I'll pause there. Like, is that kind of like hit home?

Yes. Okay. I've, I've had it in a earlier session that I took.

Would you, I, I keep wanting to think of tcam in this instance as like almost like an index, uh, for the bigger memory space It is. Um, and so I have a slide on, yeah. Uh, hcam itself, in which I'll talk about it.

Um, but at the end of the day, it is coming down to like, how do I get into that memory? How do I find that? Um, and in the tcam case, it is index based.

Um, okay, so, and these are all kinda like table stakes. This is like normal routing and switching stuff. You gotta have routes, you gotta have Mac addresses, and you gotta have security les and, and those kind of things, right?

Well, other things, um, we have had this in the, the U-A-D-P-A six in the past, uh, but had not had this, uh, previously on silicon one. So even the, the first generation silicon one we added, um, that same hcam is now giving you that, that much larger, uh, hash based memory is also being used for hardware based net flow. So it's the, you know, return to hardware net flow at these kind of speeds.

That's one of the, the key items. Um, we mentioned briefly, uh, data encryption. So this is, uh, line rate ec, and like I said, that's not unique to, uh, UEDP, but it is the first time it's come to Silicon One.

So now all these new generation of silicon one as six will have this builtin max sec and IPSec. That's the takeaway. Uh, things like PTP, uh, audio, video bridging, um, you know, uh, mohamad talked briefly about like latency and those kind of things.

Uh, so this is also baked into the chip. You guys don't have to memorize all these things. I'm just trying to, like, really trying to drive it home.

Like this isn't just your, your grandpa's speeds and feeds chip. This was really, really built for enterprise features. Um, advanced QOS, uh, counters.

It may sound weird, uh, but you know, you have all these wonderful capabilities. You better have a statistics a counter there. And, uh, having super flexible and millions and millions of counters that can be programmed, uh, based on whatever, you know, application you're running on the, on the switch.

This one's also kind of a weird one. It seems like it's weird. Um, the first generation, uh, actually was built for 400 gig.

That was one of the items that was discussed. But because it was built for 400 gig, it was not built for one gig. But the, the new a 100 and K 100, uh, can go all the way down to 10 meg, half duplex from 400 gig to 10 meg, half duplex.

One of the slides I was looking for earlier, because yes, we still have equipment that's that stupid. Yes. Projectors.

Hmm. Projectors, Projectors, sensors. You're not printers and phones.

I would say printers. Yeah. So it seems kind of silly, but I'm like, no, I have to add that point to it.

Okay? Um, I promise I'd have, uh, uh, this hcam because then this was like the star of the show, if you will, right? It was something new, something, you know, that hasn't been done.

There's no other chip in the world that's doing this, um, tcam and, and it's a long story, but tcam is like infinitely flexible, perfect, precise. It's also very expensive, like actual money, but then, uh, the memory space that it takes on the chip, things like thermal, um, and so not just Cisco, or not just silicon one, but you just look at anything in the industry, um, other vendors I won't name. Um, but the TCAs are just getting smaller and smaller and smaller.

Why is this happening? Well, it's crazy expensive. Uh, that's why, right?

But in campus, uh, we want really big access control list. We want that huge net flow table. So this was, like I said, like the best of both worlds.

I'll give you a, a, you know, reasonably sized eight K Tcam. Uh, and then conversely, SRAM is kind of dumb, but it's, it's fast, it's cheap. Cool.

Uh, cool from a, uh, cooling perspective. Um, so what if I squish those together? That's where this hash based.

And so I can actually put, if it say it's a small access list, I can put that small access list in a regular tcam, it's fine. But what if I have that 10,000 line access list at some kind of like border? What do I do with that?

Well, that's what I would put into this SRAM table. So hcam is the best of both worlds. That's, that's what Silicon ones bringing to you.

Question, Josh. Yeah. Diversified.

You mentioned in that previous slide that IPV six took two entries, is that's just a math division on trying to, to divide up that in the address space into those tables. Yeah, That's a great point. Um, and good catch.

So, um, it's the number of bits wide in the memory table. Um, so it is wide enough for source, destination, address, and control of IBV four addresses 32 bits. Uh, because IPV six address are 1 28, right?

It runs off the side. So I have to allocate two entries for IPV six. So it does mean half scale for V six, but still much, much higher.

Um, now this one you don't have to memorize. Uh, what I wanted to kind of demonstrate is, is again, that it's kind of both access control and net flow. Um, and how, uh, Cisco C 9,000 switches does.

This is, uh, via template. Um, you don't have to do anything for the default template. You just get it out of the box.

Um, and when you get it outta the box, it, we kind of do a 50 50 right now. So if you're looking at like the data sheets, somebody's, uh, you know, reading the data sheets, they're posted now, uh, data sheets are live right this moment. Um, but it's based on this default template.

This is what you get out of the box, right? Uh, and then we can also do, uh, custom SDM, so you can choose, Hey, you know, maybe I don't want more NetFlow, maybe I want more access control list. And you can change that SDM allocation.

Okay? Um, and then, uh, it depends of course on the asics. So the A 100 is a smaller asic it, thus it has a smaller H cam.

Uh, but the architecture is the same. That's what I like, uh, want you guys to remember. Um, there are just more of the H cams on the K 100.

Okay? Um, buffers, uh, because, you know, I'm gonna, I'm short on time, I'll just kind of buzz through it. Um, but one of the key things with silicon ones, this is more conceptual.

This is also true with the, the other, uh, silicon one A six. Um, they will have their own onboard memory. In fact, again, if you look at other vendor chips, they'll have very tiny buffers.

It's always a key thing to look at. Um, if you look into the higher classes of chips, uh, they've introduced this high bandwidth memory. Uh, it's like saying DDR, uh, it is a actual type of memory that high bandwidth.

Um, and that's the part to remember. But from, how do I use it? I can have a small buffer for low latency.

I want to, I want to get it out of the chip as fast as possible, minimize the latency. But then if I have some slower application, or perhaps it's bursty, it's coming in very rapidly, uh, I can then temporarily put it into this high bandwidth memory. Um, so I'm actually solving both types of, uh, QOS solutions with, uh, silicon one.

How do you make the decision of what goes into the slow lane and what stays in the fast lane? So it's very much based on the QS policy. Uh, then there is a default QS policy.

We can set a policy, You can set your own As, as these are prioritized traffic always fast lane, a hundred percent. I set a policy that says, you know, fast lane if possible. That's right, too slow Priority queuing, low latency queuing.

Yeah. Um, and it's just whatever class you decide to put in there. Um, and even like the little thing at the bottom, it always goes into this, you know, shared memory system, which is the, the shallow but fast memory first and then as necessary.

So it's only as it hits congestion, then it will send it to HBM. Got it. So even, even if you have it configured to be hybrid, if it's gonna go fast length available, it's gonna use that exactly on it.

Yeah, exactly. Is there any cost on that switch? So like I just, I'm seeing the processing at at line rate on packets just flowing through the switch, all of a sudden you fill up your fast lane queue, like obviously you're gonna have some latency added going through the, The, the HB slow lane.

Yes. Right? But even in, in making that decision, that seems like a lot of resource to, to, oh, my, my fast lane's full.

I have to flip that over. Yeah. So it deserves a very long discussion.

Yeah. It's probably More we cover here. I'm, but Yeah, the principle is true.

HBM is a little, uh, slower. Um, and so normally even what's I tried to draw in the picture, it'd be like, you know, the, the less interesting traffic, less latency sensitive. So I get that experience that, but you're right.

You know, you'd have to be careful. Go Ask your users, which are, which traffic's. Yeah.

Less, less important. Yeah. Yeah.

Your me your email's stuck in there. Yeah, good luck. Yeah.

Well, your email can take a few extra microseconds that you high definition video cannot take that. Yeah. Okay.

Uh, I xe, um, a lot could be said about this. Uh, io XE itself is not new. Uh, Mohammed touched on this.

Uh, uh, Kenny talked about it a little bit. Um, and this is another animated slide. Uh, I'll just go through the high points.

So one of the key things, uh, particularly leading up even to the, uh, X series, which we introduced a couple years back, was to make everything model driven, uh, at a low level, um, infrastructure, software infrastructure. Say, why do, why do I even care about that? Um, it's, we're talking about things like ai, we talk about security.

All of these things require data. What does ai, you know, how does it make its decision? It's because it has good data about, you know, link state and particular flows and those kind of things.

Where does it get that data? Gets it directly from the switch, and it needs to come in a structured way that it can quickly parse through all these different things to, to reach its decision, right? So that's the moral of the story, and we've been on that journey for a while.

Uh, now one of the things we, uh, all three of us have touched on is this unified management and, uh, unified software. So it's, it's the same iOS XE running on, uh, the Cisco C 9,000 smart switches, regardless of whether it's operating, uh, on the Meraki dashboard, whether it's in Catalyst center, ai, you know, um, CLI APIs. Uh, it's a single iOS XE image, okay?

There's no extra boot, no extra change, that kind of thing. Um, which leads to the next point. We, we are just talking about cloud native, and I can operate in these different modes, single, single hardware, single software, um, and things like AI ml, because now the way that I'm giving that model driven telemetry, uh, is consistent.

And so like the, the AI behavior in Meraki dashboard is consistent with the AI behavior in, uh, catalyst center. Now, the other fancy one, the takeaway, uh, and Kenny did touch on this, was this next generation stacking capability. Um, if we had more time, I would give you the really long version.

I encourage everybody watching to please, this is like one of those really fancy things to go check out this NG stack wise. Uh, this is really game changing stuff. Um, but the short version of why I chose this picture, 'cause it kind of gives you the gist.

Um, we say things like, you know, Linux kernel, different Linux processes and stuff. Um, if you take a peek at this, uh, bootstrap process, it, BP and cluster manager process, but you'll notice that it's, it's separate. It's different from the normal iOS stack.

So anybody that knows Linux means that this process could just die and go away, right? Which happens during software upgrades. Uh, in fact, even when you're booting up, the cluster manager comes online first, and then iOS continues to boot up, right?

Um, the other thing you'll notice is using those little cylinder symbols. Those are, uh, databases. Those are, those are YANG models, right?

Uh, and so the way that, you know, whether it's Catalyst center, Meraki dashboard, uh, again, that's that, uh, model driven database, and that's actually controlling the cluster, right? Uh, and then the last piece that, that Kenny touched on is that it's standards based. It's VX lan, uh, so it doesn't matter.

And, and shortest path first, meaning it's not strictly a ring. The, the switch treats every interface, whether it's on the back, whether it's on the front as an ethernet interface. And that's where it gets down to the last piece.

Uh, Mohammad had a, a little bit of a slide on this one. Um, things like in-service software upgrades and, and software patching, that's what really matters. Like I said, if this guy dies, which can be up to and including a software upgrade, uh, the cluster is still operational.

So now I can upgrade, uh, the individual switches, the cluster remains online. And this minimizes your, uh, impact during a software upgrade Question. Yeah.

Uh, Josh from Diversified, what are some of the, the technical bits that are enabling kind of that microservices architecture between the processor and that layer? You, you mentioned there's a couple databases in there, it's more of a Linux kernel. Is that just more of a Linux kernel development and that stack development, or is there something specific that's enabled that maybe like EBPF?

So, uh, eeb PF is a, is a great point. Uh, in fact, I, I touch it in the next slide. Okay.

Um, and, and the other guy said it too, like, we should have a whole session just on compensating control, right? Um, and that is for, for folks familiar with compensating control and EBPF, that is at the, uh, Linux kernel level as I'm making system calls, uh, this itself is actually slightly above that. Um, and that's even why sort of, I went through the points the way I did.

Uh, we've made all of these iOS processes model driven now, right? So they're in a well structured format, right? And then the, the extra bit is that, uh, cluster manager and bootstrap that I talked about as a separate Linux process.

So that, that even if something here is disrupted, uh, the cluster itself is not disrupted. Um, one thing that's not cooked in here, but uh, is implied, is also the application hosting, which is kind of the next slide. Gotcha.

Um, so it's another example of like protected memory. I can run those in their own memory space. Um, one process dies, the other one's still operational, that kind of stuff.

Okay. That's actually a great segue to this one. Um, so, you know, we've always had CPUs.

It's not that, you know, we invented the CPU or something like that. Uh, but these are latest model, uh, Intel X 86 CPUs, um, with also, it gets kind of glossed over, uh, much higher dram, um, both faster DRAM and the amount of DRAM that you have available to you, right? So this ultimately, you know, just basic things like, does bg, how fast is BGP?

How fast is, uh, spanning tree? Um, but then it also applies to application hosting, right? So in that application framework, and this, again, I, I'm hinting at it, I'm not trying to say anything specific.

Um, but again, when, when somebody talks about, you know, local ai, distributed ai, um, somebody says Hyper shield ready, we're talking about running those, uh, in this containerized, uh, format, and then the number of cores and how much DRAM is gonna be the key factor. That's why it's highlighted in yellow. Um, the other thing, uh, Kenny touched on, um, is the link from the ASIC to the CPU is, is the other big factor.

Okay? Um, so, you know, I had touched on the, the stacking, uh, so I've sort of preempting the slides, uh, because of time. Um, but you know, questions like, you know, what was new?

It's this, I said the cluster, uh, manager and bootstrap process. Um, but what does it mean for me, right? So it's still going to be presented to you as the exact same commands that you have, right?

And then it's gonna be the benefits from software upgrades. And Kenny was talking about, uh, dynamically adding links, uh, in the 93 50 discussion we were talking about, you know, putting them in different combinations, but it's, it's the same, the way that you manage it is the same as it was previously. Okay?

And the other thing is, it's subtle, but this should, uh, resonate with the audience is before 93 50, stack wise was actually a different thing than 9,600 stack wise virtual. Like, we gave 'em the same name, but they really were two different things. This next gen stack wise is the exact same architecture on 93 50, uh, as well as the 96 10.

Okay? So you've got a, um, bullet point there at the very bottom that you're trying to sneak in there. The ISSU.

How, how has it improved? Are, are we at the point where we can have a healthcare data center, or not a data center, but a closet stack of 10, you know, reboot it and not lose our data point yet, or we still, uh, doing a full reboot cycle. So, uh, both of those things, like the answer in there is a bit of both.

Um, anytime you touch the asic, like, I actually have to change a memory table in an asic, it's a hit, right? So I would also like assert to the public audience that there's no such thing as a hit list doesn't exist, right? If I touch something anywhere on any device, um, but having said that, I can minimize it to the maximum that it can be.

Um, and particularly in, uh, a stack behavior, uh, we're also mixing in things like, uh, just ISSU itself. Uh, we recently introduced, uh, five seconds or less extended fast software upgrade XFSU. Um, so here it's more about, uh, you know, can I run two different devices, you know, two different switches with, uh, different software versions, for example.

Like, this is one of the benefits of fabric, for example. Um, but then extending that just now natively into a stacking environment, um, it's, like I said, it's a lot of different pieces in there, but it's the normal pieces of of ISSU, I'm gonna upgrade the software. I minimize the hit to any one member of the stack.

Um, and then because of this cluster manager, even if this goes away, the cluster itself never changes. So I don't have to do like a full reboot. The doesn't like go away.

Um, perhaps I'll end it with one point. Uh, you shouldn't see link down. That's what I always tell people.

Like, you should never experience an event where that link, perhaps to the wireless access point goes offline. That's like a catastrophic, you know, loss of connectivity. Uh, it just means the ASIC didn't send, you know, four or five packets.

'cause it's in, it's in the middle of a rewriting a, a data register, but you should never see a link down. That's, that's the magic. Looking forward to seeing that demo.

Awesome. Um, okay. Um, I want to go on with this one.

Um, I still think it's valuable, uh, but I'll give you the, the short version. Uh, these are the exact same diagrams. They have the same number of devices, the same number of links.

Uh, the point for the audience, and it's, this already exists, it's to kind of reiterate the point. Um, if you go through and do the math in a traditional equal cost multipath design, um, these are 19 unique devices. And also part of why the slide was first built is like, well, I, I can do all this now with controllers.

Why do I care? The controller's gonna do everything true, but every single one of these is gonna open up a, oops, the tunnel back to the controller. It's gonna send s logs, it's gonna send NetFlow.

So that is 19 unique sessions even going to that magical controller, okay? Um, and then all the individual items they have to run unique protocols. I have to tune those protocols.

And then if you compare that with the exact same topology, same number of devices, same number of links, uh, I have reduced that number to more than half by more than half of the number of devices that uniquely have to be organized. Um, the other piece I was saving it for the, for the bottom, um, in this, uh, protocol based equal cost multipath, it's gonna be BGP, it's gonna be, uh, OSPF or spanning tree that makes the decision to reconverge. So when a link dies, stuff happens, right?

It then, based on the protocol and whatever timers will choose the new path, right? That can be in the order of seconds, even minutes. In some cases.

The real magic of stacking is multi chassis, ether channel, uh, making it a logical interface. And so even how did, how did I reduce the number of piers? Because all these physical links became one port channel interface between you and I, and I just, I don't have to run multiple instances of spanning tree or, or protocols.

And then the real magic is when that link stuff happens, finally dies, it's just an ether channel load balancing. It just takes the remaining traffic and it puts it over the other links. And that is in milliseconds.

I'm just gonna call out the elephant in the room. I am not a fan of this diagram at all. Okay?

Um, the right side is absolutely a valid architectural path. And stacking is of course, is not inherently evil, but I don't, I don't appreciate or like calling out like leaf spine routed architectures as somehow being bad and stacking being good. Um, and saying, r we Support both of them Routing Protocols, taking minutes to converge is not reality.

So I, I just, I have to call out what I see as being fud. Please don't use this. I mean, you, you can talk about the advantages of stacking and whatever, but this is not a cool chart.

Sorry. Okay, That's fair. Um, I mean, in the end, it's going to bend on how you've, uh, actually configured it.

That's the point I was trying to drive home. I agree with you. Um, and we support both of them.

So it's, it's also wasn't a, uh, dig on one or the other. It's more a, uh, design write Xs and green checks. And this is good and you're bad.

Like this is a, this is a bad diagram. Okay, thanks. I, I won't say anymore.

No worries. No worries. Um, well, the last thing, uh, that I really wanted to go into was picking up from there, uh, was the points that, uh, Mohammed and Kenny had talked about earlier.

Um, really just kind of the, you know, as the access layer, uh, bandwidth is increasing, um, and the, the density view of it, right as wifi, um, wifi seven, specifically using multiple uplink ports, um, the kind of bandwidth that those wireless access points are gonna do. Um, and then being able to connect that up, uh, from the access layer to the distribution and finally distribution to core. Um, so those are gonna be like the key points where, uh, you know, port density and performance, uh, as well as the scale, right?

Because I've now, I've got more wireless clients connected, so I have more MAC addresses, I have more, uh, access control and, and those kind of things. Any other, uh, key questions on co key points? I actually did have one quick question.

Yeah, please. Uh, with regards to, um, some of the, uh, cloud manage, uh, capabilities, you know, able to manage either in catalyst or in, uh, in Meraki, what's the minimum code for that? Is that a minimum code requirement?

Great question. Uh, so, and interestingly enough, this on iOS XE itself is, uh, also available in 1715, starting 1715, uh, because the, uh, the new C 93 50 and C 96 10 start with 1718. Technically it's 1718.

Okay. So 1718 is the minimum code that Yes. Run on those.

Okay. So this, this is gonna be backpedaled, the 9 3 9, The, uh, management piece of it. Unified licensing, unified management.

Yeah.