Conquer Complexity – Cisco Unified Branch with Lee Peterson

Hello everybody. Uh, so yeah, Lee Peterson. I lead the Secure WAN product management team.

I've brought some support here with me, uh, Shakar and Tom. So, uh, you know, jump in any anytime questions. Don't need to tell this audience that, but, uh, ready for anything you can throw at us.

So there's two parts to this presentation we're gonna talk about today. First thing I'm gonna talk about the unified branch. So it's an approach that we're, we're announcing here at Cisco live around how we can go deploy branches at scale, the right level of reliability, and the right level of security.

And we'll go into some details, some demos of that. Second part of the presentation. I'm gonna talk about the new hardware devices we're launching here at Cisco Live as well.

So you would've, uh, seen slides like this before. I think that there's been some of these that have been maybe a little bit architecture, uh, in the past. But I think a lot of what you'll see from all of the, the business units here across wireless switching and routing, routing being the one I'm responsible for is the legitimacy around having those devices be able to be managed by a cloud platform.

So the platform approach, uh, is an important element of this because we need to make sure that we've got a common point from, uh, an intelligence perspective. Where do we do ai? And it's very hard to do that in a disparate fashion.

And certainly things like assurance, right? Making sure that we've got a common layer for when we go to AHO owned and Unowned infrastructure, that we can do that consistently as well. Where we've spent a lot of our time over the, the, the past little bit here is trying to simplify this idea.

We hear this consistently. The, the challenge with branches is that there's lots of them. They're very just, uh, spread out and they generally don't have it people in them.

So think of a retail store. You haven't got an it, a network operator sitting there trying to deal with, there's any problems. They're also very complicated, right?

So the, the ability to deploy at scale with the right level of consistency to make sure that we don't have the risk of configuration drift. You might have a playbook of how you wanna deploy, but as soon as that is somebody in the user interface clicking around doing these things, or somebody in a CLI running a bunch of scripts, the risk of that drift happening and the risk of you introducing security vulnerabilities or, or performance issues into your network is pretty great. So what we focused on is that how do we go and make that much better?

How do we interact with this new platform that we're talking about? So not net new platform, but just the new way of thinking about the platform in a way that's gonna be able to be scaling. So, uh, everyone's familiar with Terraform or infrastructure code as general, uh, we're announcing here at Cisco live our branches code efforts.

So I'll build this out a little bit. It's probably quick and easy to talk about. I we'll get into a demo of this in a moment.

But the idea is that, you know, take that platform as the base layer. We wanna really make sure that we can have, uh, when we think of infrastructure as code, what it does well, open source approach to managing infrastructure and literally hints of the name treating it as code. So being able to have my configuration saved in Git the same way I saved my, my software, and being able to have that be version controlled.

Being able to have that part of a deployment pipeline is really what the efforts are around this. Uh, we're also layering on this isn't just open source effort and we just throw it over the fence and good luck to anybody who wants to try and use it. We are building some services around this as well.

So CX will certainly come in and consult and help by the partners or, and customers get up and running. And the beauty when they do that is we can start thinking about applying best practices to this environment as well. So how do we make sure that we are taking decades of knowledge of, of how to deploy and how to manage in a consistent way, and making sure that we don't have missteps as we go to deploy and configure and operate these, these branch networks.

And like I said, this essentially that makes the network configuration just part of the standard CICD pipeline that the, that the partner or the customer is managing in their environment. So I, I won't go to the workflow here, I will actually jump straight into the actual demo. So the, the case we wanna show here is, imagine I've got three active sites and I, I want to deploy five more.

So what are the steps I'd wanna do to use that using Terraform, uh, to, to, to make that happen? So firstly, we're hearing GitLab, and like I mentioned, you can see the network configuration saved there in Git. And so that means you've got versioning.

That means that you've got the ability to use the web tools that you use from the perspective of managing software in the same way. So we can jump out here to the web IDE, and what we're gonna do here is actually copy that configuration to go say, I wanna deploy five more sites. And so th this is, uh, something where again, you know, we, we put, uh, pre predefined defaults.

We know what the right things to put in here are. Um, you're able to then take that, push that back into your, your deploy pipeline. We can check on that as it runs.

And each of the steps here is like, we don't want a, uh, any engineer to be able to just go and run this without any sort of controls over it. Similar to when you make a code, push a code, uh, a merge request, uh, that would be verified and validated, both, you know, probably by a human, you know, it's probably a, a maybe a manager or a level of sign off and making these sort of changes, but also an automated way to pre, uh, configure and pretest prior to us deploying this out. We don't wanna go push a mass change out and obviously take a, a, a segment of the network offline and also post-test validate.

And again, because this is managed by the way we managed software, the ability to roll back in the case that I did do something wrong. So we can see here that we jump over to the dashboard and we can see these, these new branches that have actively been deployed. So that's the logical deployment.

Now, what that allows us to do is because the logical deployment has happened, the type of person I can send on site to do the actual deployment now doesn't have to be a network engineer. Anybody who understands low voltage cabling, it basically takes it to being a plug and play experience. I'm able to, to get in there and just configure, connect them in the right way, and they're able to operate that.

That's, uh, in, in a, in a very much simpler way. And, and the, the idea is that instead of taking hours to deploy a branch location, you can do it in minutes. We really don't want to have to have people in the middle of the night during the times that these sort of locations are down offline trying to stress about deploying at, at midnight in a, in a remote location.

So questions? I'm shocked. I got six slides in.

There was no questions. This is, this is not like any other tech field day. I've seen Question when you're, when you're describing branches code and you were showing the pipeline there from GitLab, was that interacting directly with Meraki dashboard, right?

From a, from a cloud management perspective? Yeah, so it's, it's, it's, again, we use the Terraform provider. So we use Terraform rather than answerable.

'cause Terraforms Stateful. Mm-hmm. Right?

And that's how it gets expressed as code. And that's, that's the interaction back into the dashboard. Okay.

Yeah. Gotcha. Thank you.

Version of Terraform provider, we developed our own. So if you look, if you look at HashiCorp's Terraform provider, um, uh, directory, the most used, most downloaded one is Starbucks has published one. Um, so they we're, we're in every, uh, Meraki's in every Starbucks in North America.

So we are actually in conjunction with our CX counterparts publishing this. There will be an open source Terraform provider that is validated and verified by us. And we're wrapping all of this up in, there's a, a Cisco validated design for the infrastructure as code part, but there's also a Cisco validated design on what are the set of equipment that I would use in different environments.

So we want to have a CVD for small, medium, and large branches across different verticals. What, what's a medium healthcare look like versus a small retail? Uh, so that'll, that'll be a set of blueprints that you can use in terms of how do you actually decide what to deploy?

Introducing, let Cisco 8,000 series secure router. So I'll just give you some of the, the, how the spaghetti make as you guys are close enough that, that, that you've will understand this. I been Cisco for eight years, uh, for seven and a half of those years.

That was with Meraki last November. We realigned the networking group as part of G two coming in, and we're now aligned to what we call a pin alignment place in network. So I'm responsible for routing.

So that's all of the Meraki properties, M-X-M-G-Z series products and the Catalyst portfolio. So the Catalyst 8,000, but also any of the legacy stuff like ISR, uh, we have the same for switching, where that's now a unified group. We have the same for wireless.

We also have the same for platform. So that's, that's, sorry, I hate having to get up here and talk org chart, but I think it's important when you think about why we're doing things the way we are and why we've introduced these products. So the objective of this product that this is, this is an extension of the portfolio.

So you're deploying and using MX or Catalyst devices today continue to do so. None of those, uh, we're not end of sailing anything as part of this new announcement, but these are the, the, the products that we are sort of, I guess, uh, amalgamating to, would probably be the best word for it. 'cause it's not gonna happen overnight.

And we understand that there is acceptance and, and, uh, validation of verification our customers would do before moving to this. So calling out some of the elements within this product that are, that are unique, uh, the Cisco networking process, and I wanna call out, this isn't silicon one, this is merchant silicon. With Cisco ip, its primary job is to be really good at cryptographic workloads.

So we work very closely with our, our chip partner on that to make sure that we have the speed we need, right? And so think of the basic things. This, this sort of box does, obviously things like IPSec, SD wan, we wanna make sure we can do that at the highest speed possible.

But then in a post quantum crypto world, I mean, what are you hearing, you know, generally about post quantum crypto? 'cause we, we see a lot of it in financial services. Fair.

You seeing it as a point of concern for customers or in the community? There's a lot of interest in it. I think there's a lot of curiosity around it.

Um, everybody's sort of wondering what it's all gonna look like, and I think everybody's just sort of pining for data to digest at this Point. Yeah, so look, we, we, uh, again, the, the advantage of the secure networking process, the, the way that we're gonna have to go to higher order levels of encryption in order to be ready for a post quantum crypto world. We are positioning this as the platform to do that.

And evolution of standards, which we're actively participating in. You know, it's, it's a safe bet that if you're trying to make an investment that's five to 10 years out and it's future proof for that, it's good to start thinking about this stuff now. 'cause I do not wanna be around when the quantum chip just appears from nowhere, which hopefully it doesn't.

And we've got a zero day exploit that suddenly all the IPSec we're running around the world is vulnerable or all the way that we're encrypting data at rest is vulnerable. So at a number of levels, a secure boot in terms of the actual platform itself being secure, uh, security and from a Crip crypto perspective, the management plane, and then also the data in transit. So addressing that at all three levels.

And like I said, we're actively participating in the standards bodies and we'll, we'll introduce that, uh, over time. Um, that also allows us too, there's a generational improvement with this process, this, this process. And when you even ignoring the encryption part of it, just from a straight bandwidth perspective, right?

So the, the, the natural, you know, obviously, uh, chips with more core, more speed, more ability to run higher speed. So I've very much a step function change. I tell people the story.

My house in the Bay Area, I have a 10 gig symmetrical fiber connection for 40 US dollars a month. And I've moved away from that house. Unfortunately, I do no longer have that, uh, which I'm very sad about.

But you better believe selling a house in Silicon Valley is the first thing you list there, 10 gig symmetrical fiber. But the speeds, the speeds are now at the point where the, the the, there's not just the, the, the availability of those speeds, right? No one's really ordering anything less than a gig circuit unless they're in a constrained environment.

Uh, but they're also, you know, the, the applications as people start thinking more about, uh, doing AI at the edge, it's certainly, uh, very pro, uh, uh, you know, compute and, and processing heavy and, and bandwidth heavy applications like video. There is gonna be more demand for that. So I don't think it's purely about the demand and the, uh, availability being outta sync.

I do think those two will meet over time. So building a better box, build a better mouse trap, build something that's faster, it operates at a high speed is important. The other element of this is a secure router.

And why we've been very careful about the branding of this is that the NGFW, so if we go back to the secure networking processor, its ability to run the, the things we need to from a firewall perspective as not line rate. We wish it was line rate, but as close to line rate as we can get. So the performance hit from turning on firewall services within this box, we wanna make sure that's not, that's not immense.

Um, so 8,000 is this like, I think the second thing this week that I've heard with the 8,000 number, so I, 'cause I took a course about the, uh, 8,000 iOS XR routers. I'm guessing these run X are, No, there's run xy. So these are, these are a continuation of the existing Catalyst 8,000 series.

We don't wanna renumber these things every time we launch something new. So if you actually look at the skews, which I don't have listed here, these are the whatever number, let's pick one, the 80, 81 45 dash G two, I don't wanna change the numbering scheme ever again, right? I wanna be able to introduce the G three and you'll go, okay, I know what that is 'cause I was using the G two.

So these are a generational evolution of the current, uh, catalyst 8,000 series platform. And that's why we carry that forward versus building another new numbering scheme and having to educate everybody on that. So this is a, a full refresh of the entire portfolio.

So 13 new skews, uh, uh, addressed here in, in this, uh, this new launch. I mentioned the, the idea that don't have a slide. That that's fine.

I'll talk to it. This is where, so, so you can imagine that the, the base of these will run iOS xe. So what we wanna be very clear on is that if, if your product size and standardized on CLI and scripting and SolarWinds, we're not taking any of that stuff away, this is not about saying, let's go make something brand new and make, you know, you've gotta go completely throw everything out.

And we recognize that it, I, I wish the world was all greenfields, but these are often gonna operate in brownfield's environments. So that's important to address. We have, uh, uh, on-prem management also very important.

So making sure that we continue to invest in catalyst center, catalyst SD WAN manager, we talk about the platform and the effect that we're gonna have there. We want to integrate the on-prem and the cloud platforms a bit more closely, but we're not trying to build one ring to rule them all. We do see the cloud is probably the right answer for most of customers, but that doesn't mean it's the right answer for all customers.

We're not trying to force that as like, oh, you're gonna have to come to the car to get all these benefits. We'll continue to innovate across all those domains. Now, if the, I mentioned the MX portfolio.

So, uh, we are launching what would've been the MX six 50 under this product lineup as well. It's gonna be the 84 55 dash mx. So I'm gonna maintain a, uh, an MX based operating system that operates cloud native the same way MX devices do today.

And as we go through and refresh that product lineup, it will fall in under here. The second investment I'm making though is that these iOS, XE based devices being on the cloud. So think of just the, the beauty of doing this consistently across wireless switching and and routing is this a decent amount of inheritance.

So the work that the switching team has done, we're able to pick that up and also have these XA routers be cloud managed day one. It's not gonna be native and it's not gonna be comparable, you know exactly with what, uh, you do with Meraki. But over time, the ability to use an API to address either an IO six E based device or a, uh, a, an MX based device, you know, we want that to be somewhat norm normalized and not have to make a decision between the two.

So you said these are, these are merchant silicon based platforms. Are they VPP under the hood as far as the, the packet processes are concerned, they're CPP. Okay.

Yeah. Alright, thank you. Yeah, so building, building on the, the, the stuff that we've done before with, with, it's not, it's not a, an architecture change from an XE perspective.

An XE perspective, okay, cool. Yep. Uh, even on the AMX variant, MX variant will continue to run an MX os.

Yeah, that's, that's, that's, so That'll be PPP based probably, or who knows? We're, we're, we're not, we're not really, uh, going down that path right now. Okay.

Right. We, so, so I think I want to have the right tool for the right job. And increasingly, like I said, that idea, if you, if you're in a Brownfields environment where you are, you've standardized an xe, you've got ISR four Ks, let's say, and you don't wanna change your whole operating model, taking one of these running XE is gonna be a better choice for you than trying to step into the MX operating system.

But if you're already embedded, you know, you're a pure play Meraki, stay on the MX operating system, there's no need to move to this. So optionality around that and, and we're not really trying to converge and have one os that that does it all does 'em all. Okay, We'll, we'll, we'll continue two, two streams.

Um, there may be some rationalization down the path, right? I I think I'd love, like, let's play for two years. I would love to have the 84 55 as a sort of VP concentrator persona or whatever.

Yeah. And I'd love to be able to do a mixed fabric, right? Be able to have an SD WAN fabric that can either be XE based or, or MX based and be able to mix and match.

Because maybe I want big devices in my big locations with more configurability and my remote locations, small sales offices, you know, maybe it's a simple deploy mx you know, maybe a one worth wireless and cellular in it as well. Please. That would be great.

Yeah, we'll be asking for that forever. What's the limitations on that Terraform provider right now? Is that all xe?

Is that mx Like what, where does that fit in the hierarchy of product? It Fits through things that use the cloud dashboard. So cloud dashboard, which is shorthand for Meraki, but the, the, the identity of that evolving somewhat as the, so right now if you said to me, Hey Lee, I want to go, this is great.

I wanna go do a, uh, uh, infrastructures code program tomorrow. I would say do that on the mx 'cause the MX has got the cloud nativeness, we have, uh, some base level XE on cloud features as we launch these devices. So they're orderable today shipping in a, what, August, September timeframe shipping August, September.

They'll have a very base level of, of ability to onboard to the cloud, but you won't be able to use an API to go do a full sdwan deployment, let's say. So that, that that's the, every six months as we roll into like a Cisco live, we'll be talking about what we're developing from an infrastructures code perspective and where the MX and the XE based devices are on that journey. Okay.

And working with, you know, the, so we just had a presentation earlier today that was about essentially campus fabric on MX that's gonna be coming out later this year. Like in the, in the dashboard, working on that, like keeping that Terraform provider in line with what's capability of the dashboard. Um, is there, is there gonna be any separation, any lag?

Is there concerns about maintaining that, that feature parity, what you can do, uh, from a UI perspective versus Terraform perspective? I'm just kinda curious where your head's at on that. Okay.

I think the UI ends up lagging well, we wanna be API first and everything, so universally across our engineering teams and us as product leaders, we write the API first, right? So what that should give the ability to is to have the ai, sorry, the ui, you don't need the UI to get started with the api. So we'll, we'll build that out first because that's the infrastructure upon which the UI is built.

And when you say API first, uh, I understand that, but I would say that traditional Meraki, API versus this Terraform provider are two different components at the moment. So when you, when you say API first, I'm, I'm looking to make sure the Terraform provider as if we're gonna go talk to customers about this or, or go talk about this, like where does that sit in the hierarchy of, of, of that development process? Yeah, I think we, we wanna treat them as one and the same.

So okay. Define requirements in terms of what do we need to build from an API perspective and how does that get represented in Terraform, right? Okay.

Make, we'll make the engineering teams responsible for That. Your plan is to keep those in lock side. Totally.

Yeah. Yeah. Kinda goes to my question earlier about Terraform provider versioning because the, there's some concerns in the community actually.

There's a lot of concerns in the community with Terraform and their licensing change that they made, you know, uh, somewhat recently, uh, they went and I, the details are eluding me right this second, but they essentially went from like an open source license that was, you know, very permissive to a very restricted open source license. That's, a lot of people are saying it's not really open source. So how's that gonna work with, with the Cisco provider?

I mean, are you, do you guys like sort of usurp their licensing in a way, or, or, I'd say it's licensing it separately, but I look at it if AWS can have, or Amazon can have one provider, I think we really should challenge ourselves to do, do the same. But I wouldn't see us having a license that replaces that in any way. 'cause we're not selling that.

It's, it should be available whatever GU or whatever license is available under. I would like to switch gears a little bit, please. You had mentioned that, uh, that there are no plans to go to a unified os, but that's something that Cisco competitors have embraced wholeheartedly.

And I hear back from a lot of customers that they're very enamored of a much more simplified, uh, op single operating system. It makes their, um, ability to automate, uh, across the enterprise a lot easier. It makes their ability to keep the, their, um, skill sets up to, you know, by not having to split out.

I'd really like to hear from you as to what strengths you believe you have, uh, with multiple, uh, different oss. So look, if we were starting Cisco today, would we sit down and go, Hey, let's go build seven oss. We wouldn't, but we also recognize that the journey towards convergence, it doesn't happen overnight.

So what we really wanna do is, is, you know, we'd love to be able to say, let's start from the customer outcome back in. We hear consistently on what the simplicity of Meraki, but the power of catalyst, right? And we are converging at the management plan level and having that be one thing.

And over time, as the feature sets get richer and the the routing capabilities, the MXOS get richer specific with routing and the xe, the cloud management, that gets richer. We can make a decision on do we, do we start to do some elimination? But I don't wanna predict that because I know it's gonna be a journey until both of those things are true.

I'm gonna continue to invest in the MX operating system and build routing features. We've got some really exciting stuff on the roadmap over the next 12 months. We're bringing vrf we're bringing third way and active fha, uh, BGP support for I PV six, right?

There are things that we're gonna continue to invest there because we've got customers that want just nothing more than operational simplicity. But the much larger base for us is that XE base, the, the, the, the, the, the history of devices that we've deployed over the last several decades. Uh, we can't just say, let's just go smash to one other.

If we could, if we could smush 'em together and make 'em one thing overnight, we would do that. But the reality is it's gonna be a, a long process. So I won't say that.

Like there's no specific roadmap about item. We're tracking right now saying, let's converge this to one. But it's certainly in the back of our mind that as we, as, as the features get richer and richer, how can we, we see them sort of going like this and we can make a decision at some point in the future to say, let's, let's go pull our eggs in that basket.

But yeah, And I'd like to kind of challenge that because as we talk about trends in networking, we talk about, you know, it, it started with a single pane of glass to be able to look at our network from one end to the other end as a unified body. You know, we want one software to drive it all. You know, we want to be able to have a centralized controller, you know, all we wanna be able to manage our WAN from a single space.

We want it to be able to pull down our cloud clouds multiple from a single, uh, from a single space. You know, the idea of holding onto a single OS simply because it developing a unified OS is hard. Kind of begs the question, uh, of, of, you know, of the co of the company's fortitude.

I mean, I'm not trying to pick a fight here, but I think that that, you know, the longer that Cisco says, well, we're not, this is hard, we're not gonna do it, we're not gonna do it. Somebody's gonna come along with a, a unified os that's simple, that they've developed and supports the feature sets that customers want, and they're gonna eat your lunch. And that's what I've gotta say.

Yeah. So look, appreciate the feedback. We, we have to, we have to serve a range of people, right?

So we go all the way from, you can have my CLI, when you pride outta my cold dead hands to all I want is just to manage from the cloud. And that's, that's a, that's a pretty big spectrum. And the idea of like, what's the one answer to satisfy both ends of that spectrum?

It's very difficult. Yeah. I, I I, I, I'm, I'm not gonna argue that point with you that, that that's an inter that's a difficult prospect, but I never imagined that Cisco was, would shy away from a challenge.

And I feel like, you know, I've heard a lot of conversations about a unified os and I feel like this is the, this is, this is the one, the, the, the challenge that Cisco's shying away from. And I would, I would encourage Cisco to embrace the, the, the uncomfortableness. Yep.

No, appreciate the feedback. Look, and I'm, I'm very focused here on things that are audible in a very short time window and launching in the next six months. So this isn't a 2, 3, 4, 5 year roadmap.

We have ideas, but we want to see how some of these short-term bets we're making play out. You know, that, and there's a place for, for short term, but there's also a place for longer term vision and being, um, being diligent about seeking the future. Especially because nobody wants to buy a product that comes with short term attached to it.

Yeah. Yeah. And this is the point.

Any investment today, whether somebody's standardized on the catalyst, uh, products or the MX products, they're both good investments. They're not going away. You can continue to operate these in the way you have in the past.

And for those that are comfortable with the cloud, we're gonna have new ways to do that on the XE base.