What makes a good network design?

What makes a good network design? Is it meeting all of the technical requirements of the business? Is it coming in way under budget? That's always a good thing. Maybe it's making sure that the network is as resilient as possible regardless of the budget, or maybe it's just following the network vendor's validated design guide right down to every single config snippet.

Well, anyone who's worked in this from more than five minutes and knows the answer. It depends. It depends on a lot of things, actually. And today, my good friend, Brian Lee a veteran network engineer, veteran SIS admin, network architect, and currently a sales engineer with Juniper is joining me to talk about what makes a good network design. My name is Philip Davasi, and this is telemetry now.

Hey, Brian. It's good to see you, man. Have been looking forward to talking to you for a long time. I remember when we first met in person at least, it was at, I think it was at Cisco Live. Right?

And it was that was two thousand eighteen, nineteen.

Yeah. Twenty eighteen in San Diego.

Twenty eighteen? Okay. In San Diego. That was actually my first time in San Diego. And, fell in love with it. And I've been back a few times since I went with my wife once for, for an extended, like, a long weekend. That was a lot of fun.

But, yeah, that was great. It was great meeting you in person and, and great seeing you again today. Really is. So, I I know your experience because we're friends. So I know your, you know, just knowing you for the past few years, your extensive background as a network engineer turning a wrench as a solutions engineer, solutions architect, whatever you folks call presales engineers, and, working in the security space, working in the campus, working in the data center, all these areas. So you have a a really broad experience.

So, what I wanna talk to you about today is network design.

You've seen it all. You are a veteran engineer.

So starting off with kind of this or maybe it's an unanswerable question, but what in your opinion makes a good network design? And you can answer that question in the context of the campus, in the data center, or maybe there's some even more broad concepts that sort of cover everything. But what do you think makes a good network design?

Well, let's see.

That's a that's a nice question because I think, it it almost differs from whether or not you're you're in the trenches or if you're trying to sell or you're trying to be be a VAR. I need to know if you work for A VAR.

Okay.

I'm trying to help help someone, meet the needs.

If you're in the trenches, I think there's a couple of other goals.

One is can you do it within your budget? Can you meet these vague designs that, that the that some business unit has given you. And then and then how do you make your how do you make your life easier? Because most network engineers and the trenches just wanna sleep in the middle of the night. They want the network to be self healing. So if your design kind of works works to meet those business goals and keep you asleep, can can fix itself. It, it's, it's probably a good start.

So if you're on the, if you're on the VAR side, and you're trying to help them, help make a design. That's where you need to need to look at, best practices, how do you build in redundancy and resiliency and and still meet the meet the needs of the, of your customer, on the, OBM CIDR, on the on the vendor CIDR, you wanna sell them the the correct part.

Don't just go in for, go in for cheap, but you wanna make sure that it that the parts that you're giving them meet their needs for for a longer term. So it's gonna be things like, investment protection, stability, do they really need bleeding edge, or can we, can you help? Can you be a partner with your customer, not, not just, you know, wham bam, thank you, ma'am, kinda thing?

Yeah. Yeah.

So, that's that's kind of broad.

Well, yeah, and I posed it in a in a broad way because I'm trying to start off by at least identifying those main concepts that we can then drill down into. And, you know, right off the bat, you mentioned reliability. Stability. Those are the things that I know, especially on the enterprise CIDR, but, of course, in the service provider realm, whether that be web scale, hyperscale, e commerce. I really, anywhere that you are networking, which is like everywhere today.

We I find that network operators really value stability and reliability and fault tolerance over everything else. So I I believe that a good network design starts with that as the foundation.

And and within that, yes, there are business constraints. There are cost constraints. There are, technological constraints as far as what features are available and what engineering staff you have available. Those are all there as constraints and considerations in your design.

But I really believe that it starts with this foundation of stability resiliency because I think I think you'd agree. The the network doesn't exist for itself. It exists for the the express purpose of application delivery. Well, any service delivery, but it's usually in the form of an application.

And then, do you do you know Tony Affantis by the way?

His name sounds familiar.

Yeah. Okay. Tony, was on this podcast a while back. And I remember we were having this conversation, and he actually corrected me and said, you know what?

It's not actually application delivery. Mean, yeah, it's application delivery, but even that is a proxy for end users, people accessing their data. Correct. So that's really what the network is all about is making sure that human beings and then machines to machines can access information and access data.

The network customer is is every butt in a seat in anywhere across the globe.

So it's Yeah.

Exactly. Exactly. So how do you how do you design a network? So reliable, resilient, and and perform it and all those things.

I mean, yeah, that's that's when you start to then consider, okay, who are my engineers that are gonna be managing this on day two? Much money do we have? Where are we today? You know, that's another consideration.

You know, what what does the network look like today? And and and therefore, It is a gigantic rip and replace. And then what does the design look like then? But, yeah, I feel like that it's kind of an all all of the above thing and not as much on I don't know, platforms and and switching router.

But And the thing is, I think, I always I always like starting with some of my constraints because knowing those and having those kind of defined, really gives me, it, it sort of shortens the leash a bit on what I can do, to meet you know, those, sort of those expectations and provide the best service for, for my users, all those seats.

Yeah. And, and typically, once I kinda know those those those constraints, I can I can almost design something like a, hey, we can do this for, this thing a good, better, and best approach? Right? So at least now, your, your business units and all those, all those people that have constraints on on your service or that are providing or making constraints on your service, you can at least say, if we do it this way, then it'll meet your need, but you're gonna have problem.

You you'll have these potential problems, like, maybe you're not quite as reliable. You don't have you don't, you don't have redundancy within your within the the network. And maybe that's okay because you're, you know, you're you're a very, very small office or your home office. Like, if you're if you're reaching out to small office home office, especially after the, the pandemic and everybody's working from home, kinda, you're, you're just needing edge connectivity and you're not so much worried about, redundancy there.

Right?

Right.

So those those types of who you're trying to service helps dictate how you're going to design the network.

Yeah. Yeah. That makes sense. I mean, who who was the actual end user in this case? Is it the city of Chicago because you're a service provider, or a region, a geographic region in the world?

And then your start then then a good network design is gonna have these transit paths, and you're gonna look at these peering relationships and the cost associated with them. And and so you're your your requirements, business constraints, technical constraints, they change as a result of the the nature of who your end users are. And if you're a let's say a large medical, facility, like a, like, a healthcare system where it's like a bunch of hospitals and data centers. It's it's still huge, but much more traditional, and and maybe there is literally no tolerance for risk in those scenarios. I I loved remember like, you don't hear it that much, but the whole, like, fail fast fail fail fail often kind of, mantra that we heard for a few years.

Yeah.

And it's sort of spilled into networking. And it was the idea of being agile and all these things. And I'm like, I wouldn't I wouldn't tell customer, you know, hospital x that, it was all about stability and reliability above everything else Yep. Like beyond, you know, anything.

But then, like you said, there there in lies a cost. So you know, you go to you go to your customer and you say, in this particular data center, how how mission critical are these services? Because if we start doubling everything and you know, to increase fault tolerance. And then we want to also, improve fault tolerance at the hardware level, and we're putting him an active standby or active active firewalls and whatever.

Whatever. Whatever. You start doubling your cost, you start doubling licensing cost, and maybe then you gotta double that in your standby data center. I mean, it it it goes up exponentially.

Double the cost of optics, double the cost of the actual resources under it, double the cost of power and cooling, and do you have the rack space?

And and the, and then the complexity of of that.

You know, I I I know having done those kind of projects, I'm gonna go back to health care because that one for some reason, it's very top of mind for me. You get into some of those scenarios where they're like, well, we need We need absolutely no downtime. You know, we're talking about, physicians and and, operating rooms and all this sort of thing. I'm like, okay, absolutely understood.

And then you look at who's gonna manage this thing on day two, and you look at their staff, and they have an entire staff, but they're outsourcing almost all their high level engineering. And, you know, they just have kind of lower mid level for the day to day. And I'm like, I mean, we're talking about some pretty advanced routing concepts. So all your links are being utilized and active and load balanced.

So that way, yes, it's both fault tolerant and performant, where we don't have idle links and idle devices and and all that sort of thing. And and I got and it gets me nervous. I I actually remember, maybe it was before the pandemic. So twenty nineteen, early twenty twenty, I had one customer in, New York just north of New York City, hospital system, And that it got me I'm not even joking, Brian.

I got nervous where I was, like, laying in bed at night and talking to my wife about it. Like, I don't know if this like, I'm scared this hospital's gonna go down. You know, if somebody wiggles over the wrong wire.

I don't know if that ever happened because I ended up leaving that company, but, but yeah, yeah, that's That's those are all the things that we think about in network design. And me, in my experience, on the enterprise side, you know, Yeah. It's not it's not really as much about protocols and platforms and and things like that.

So Most I mean, you know, most vendors are gonna use the same broadcon chips out or they use, you know, merchant chips.

So you're gonna have some very similar performance, metrics anyway, anyway, It's, yeah.

Yeah. Sure.

It, you know, some, some vendors will do things better than others, maybe the the CLI or the management or the or API calls or all that kind of stuff is, is more fully developed. So when you start thinking about maybe, you know, day two operations or, and you can start moving into automation, then you're, controlling what thing is being pushed out onto which servers or, or, I'm sorry, which, you know, which routers and switches you can do it a lot more tested and controlled, and you're not worried about as much fat fingering a, you know, a policy and a routing policy to take your, your, your network down. Then it becomes just you can do sort of more with less, I think.

As long as you start to standardize, you're how you're deploying your your VLANs and your routing policies and that kind of thing. So your design becomes much more, important for day two operations, especially when you start getting into into automation and orchestration and things like that.

Yeah. Makes sense. So it sounds and that's not something I was even thinking about. What you're talking about is a good network design is setting yourself up for success on day two. It's not just purely Yeah. It's not just purely like, is this a very performant and resilient network, which which it should be. Hopefully, that's already, those boxes have been checked.

But it's now can we run with this, moving moving forward? And if if you can't, then there's a problem. And maybe it's not a good network design interesting. Yeah.

You talked about So you actually mentioned it too.

It's like, you know, a good network design is actually gonna go into take into account that the, the skill set of the people that actually have to manage the thing. Right? So if you have, if you have people, with very limited, experience in managing a network, and you're doing, and you've got a, you know, a ten thousand node, data center with spineleaf and super spines and, and and automation, it's gonna be very, very difficult to have a, a stable network because people running it don't they just don't have to experience an understanding full understanding.

So However, I would say that if that if that is the technology that's required, for the services being delivered, then it is what it is, and they need to staff up.

Absolutely.

Right? I mean, oh, like, you don't have the right staff. We're gonna give you this Mickey Mouse network. Well, you can't run your hospital on the network. Go get some better engineers. So I do think that there is a balance there and and I all think that if you're designing your network in such a way where you need constant massaging by engineers, then maybe it's not so stable and reliable.

Right. I used to I used to argue but the network shouldn't be a boutique shop. We should have small, medium, and large. And, we're, we're gonna be kinda Walmart. You when you come in, you know what you're gonna get every time. And and that, again, that goes to to having a stable network. Right?

If you're if you're doing that, if you're doing these running on one offs, then Yeah.

When something goes bad, it takes forever to figure out where the where the problem may lie.

Sure. Then you start incorporating tribal knowledge and lack of documentation.

I was almost almost said documentation, but it's lack of That's what, Greg Ferrow used to say that all the time, that every network is a snowflake and we love our little snowflakes and we care for them.

And all of that. So now what about what about today? I mean, here we are two thousand twenty three, two thousand twenty four, and, you know, our network is public SaaS providers and cloud. We don't own that stuff.

Maybe we're using DNS services. Again, we don't own that. We're relying on the public internet because we got rid of all our MPLS or or maybe we're using some MPLS, but it's much more hybrid. And so now we're relying on an SD WAN, right, that runs over the top of the public internet.

Again, something we don't own or manage.

So, yeah, that, to me, today's designs, a good design today is is gonna look different than a good design, fifteen years ago. How however, the conceptually, the goals are the same reliability, performance, day two management, all those things like you said, like we've been talking about, but it is gonna look different. You know? It's which which overlay are we using for our our, public network?

What are we using to exchange routes? Is it, you know, how how to what extent are we relying on our public cloud provider for resources? Yeah. You know, maybe we can balance that and and mitigate that risk What do you what do you think today?

Is it is it really the same as it's always been, or do you think that there's new considerations there?

You know, I think I think it probably about, like you said, I think the, I think the concepts are still are still the same. Right? You still have the same types of requirements, the same, you know, the same, needs to get the best bang for your buck, the fastest speeds, you know, end user, expectations, in fact, you know, at at that juncture, we have this thing called, SLE's service level expectations. It's not what it's not how the network is performing. It's how is your end user actually experiencing the network? So, yeah, right? So I don't care if something goes down as long as my my user is still is still, able to attach to the network, able to connect to certain things.

Well, you care a little bit.

I'm sorry. Yeah. Yeah. Well, you care a little bit. Yeah, but I understand. But it doesn't, it doesn't, it, as long as I don't have someone yelling at me because the, because the, the network sucks or down or nobody's getting on, and I can still say, actually, the network's still up, and you're still seeing the same metrics.

I'll just go and replace this device that's that you think is causing the problem, but then I it's sort of mean time to innocence. Right? So those are, those are still concepts that are, that are there.

But the technology is changing so much that that it's it's sort of a, How do you use the, the innovation to, maintain or improve your ability to meet your customer's needs and goals. So you mentioned, you mentioned SD WAN. I mean, I remember back in the day when, when, it was, it was policy based routing, right? You would, you would, you'd have to define, a, these particular sources sourced, destination addresses, and these particular ports need to go out this other interface, and then everything else will come down my frame relay network, my MPLS network.

That was all manual. Well, we did that because you you you needed, you needed to isolate certain applications for, for the speed and for the, and for the performance. Right?

Right. Well, now SD WAN can do all that stuff automatically.

You just you you carve out the the classes in which which applications you think you are already pre canned, you get on your little controller, you go, check, check, check, push.

And now you're getting metrics back on, you're getting metrics back applications can be can be punted over over different services, or, you know, or over different, circuits based on, latency or all these other, all these other bandwidth, and health, network health metrics.

It just, it just gets, it, it gets a little easier, but it also gets a little more complex because you can't just sit back and go, well, I know rip, and So it should just, it should just work.

You, you have to, keep learning something new. You can't be stale in your, in this type of career.

So Yeah.

Yeah. For sure. We still want that reliable and stable network. And now the complexity is such that you have to learn new technologies in order to continue to have that reliable stable network.

So that's still the core. It's still having a high performance connectivity to the applications, ultimately, the data, right, for a human being to get to. It's just how how that happens is different. Yeah.

And so Yeah. So there was a day when we were talking about like, oh, the coolest new top of rack end of row and then data center core switching and lossless connectivity for v storage and v motion, storage v motion. Excuse me. I said it wrong.

It's been a long time.

That those were the things that we needed at the time to provide a performance and resilient network. And and today, it's the same concept we want to perform in a and and a stable network. But maybe we're talking about spine leaf, maybe we're talking about AI workloads and extremely high bandwidth and scheduling, a fabric as opposed to just, you know, hash based ECMP. So there's different tools that we needed in two thousand twenty three, two thousand twenty four, that actually solve the same problems that produce the same result.

Just in the context of where we are today. So it's interesting stuff. Yeah. Yeah. Yeah.

It never ends. You know, I work in technical marketing now. So I'm not quite as close to the technology as when I was literally out there turning wrenches, you know, tightening bolts, like literally turning wrenches. And and then at the CLI and then eventually as a systems, rather a solutions architect designing, which was still very close to the tech But even now I see it, interaction with customers, interaction with, the engineers in my own company that is just It's a constant like, wait, what what just came out?

Alright. I guess I'm studying that tonight. Yeah.

Yes. You know?

It really is.

It's funny because I think, you know, if you're At least when I I won't speak for everybody, but when I was on the, on the, on the, on the VAR CIDR. I remember, I can remember going into certain customers, and they'd, and they'd ask you know, some specific question about a technology.

I'm like, geez, I'm just one chapter ahead of you right now, but but I've got I've got enough but they never knew that.

And I never had that. We would never know that. But you can at least talk to them. And as long as you said, some if you have a if you have a VAR that that will always give you the, the answer all the time.

And, you might want to just be a little, a little suspect. You should hear, you know, I don't know. But give me a little bit, and I'll come back and give you the information. Part of part of it, especially on the on the network design part is, like Ferrow says, this is our little snowflake of, of the network.

Sometimes there are there are specific requirements that that your business has that your VAR, who's trying to help you get the best design, doesn't know about. So if you have a good relationship with them and, and and your, your, network architect for your partner says, you know, I don't know, but let me go go back and look. You gotta expect that he's got he or she has enough, enough resource, more resources than you do to help find that answer. So there should be a pretty good partnership between between network engineers, when you get into the design market, when you get into the design phase of your network.

Yeah.

Yeah. That makes sense. I mean, as we start to actually build the design out and start selecting routing articles and and platforms and where things go and how things are connecting.

It really does depend on what the customer requirements are. And and that does include all of those things that we've discussed like cost and, performance requirements, you know, what thresholds can we not exceed, you know, things like that. And that's gonna determine whether it's a good design. Whereas that same design handed to a different customer might be absolutely terrible.

It just doesn't meet their needs. As an example, I had a health care going back to health care. A health care customer in the Midwest. Yeah.

I don't know. It just happened to be but, out in the Midwest, and they had many, many, they had a bunch of hospitals. I think a dozen hospitals, several six data centers.

They were in, GCP. They were not in Azure or or AWS.

And, we're we were designing an SD WAN and one of their requirements was that, they could not exceed something like thirty five milliseconds of latency on any link. So they were all fully MPLS, probably everything everywhere because of that. And it was specifically because of their imaging device. MRI, pet scans, CAT scan, all that stuff required very, very low latency.

And, and it was mission critical. We're talking about, you know, people's lives. So that was a, a technical constraint, which turned into a business constraint as well because it it tied to cost.

Of, of that particular SD WAN design. And and in that process, we, therefore, did not go with certain vendors or certain topologies, because of that. And so that was a determining factor. Whereas with other customers, and I've I've worked with I remember one customer here in the northeast where I live, it was a a chain of pet stores, pet food, you know, and and toys and fish tanks and that kind of stuff.

And there was a whole bunch of them all over the northeast. All they cared about was like, did the access to the, you know, the internal website, which at the time was still internal, not in the cloud. Did did the customers have access to that, not customers? I mean, the, internal folks have access to it and did credit card transactions go through?

That was and, you know, the inventory wasn't a huge thing because it wasn't like TCP kind of correct itself. It got through eventually. That was it. That design that SD WAN design, very, very different.

Still, and I hope the customer thought was still a good design, but completely different than the health care system. So It's requirements.

You gotta, you gotta know what you're saying too.

Otherwise, you just, you just kinda Hey, here's a box of stuff, and I'm gonna dump it on the table, and what however, it comes out. That's that's since you're not giving me any requirements, then I'm just gonna plug stuff in.

Although I do have to say I was with VARS for most of my career. And many times when I was a an engineer and not the solutions architect in the design. So I got the statement of work, and I'm looking at it, and I'm reading through it, and I'm gonna kick off meeting, and I'm like, this is not gonna work. Or this is ridiculous.

Like, this is such an overkill. Clearly, clearly, this was an, an effort to pack as much margin on hardware as possible on this particular deal. And so much of this stuff is gonna sit idle or it's completely unnecessary, or they're never gonna touch this once I set it up. The the they have three engineers in in the back office there and they're never gonna touch.

It doesn't have a roll out. It's gonna just sit.

Yeah. Yeah. And I'm like, alright. Fine. You know, the the account manager made, you know, made bank on this one.

And I installed it and put it in and we moved on, but I saw that. I saw that very often. And I would say that it met all the requirements apparently they paid for it. So I guess it meant the cost requirement as well.

So I may I mean, in the purest sense, it's still a good design, but I did notice, like, there was a lot of overkill. There was a lot of, you know, unnecessary over engineering. That kind of thing.

Yeah. Yeah. That happens probably more times than it should. And I think, I think it's just because, yeah, if, again, I think it's just requirements. If you don't have those things documented, then really hard to go.

This is the best solution for what we're what we need to accomplish.

And then be able to discern and say, this year, yeah, I get it. It meets the requirements, but this is all completely unnecessary. I'm spending an extra eight hundred thousand dollars I don't need to spend. Yeah.

What but what about, validated designs. You know how, like, vendor, Cisco, Juniper, I'm assuming Arista and the other big vendors, they have these validated design guides. Right? You work for Juniper, so I don't know what you call them internally.

But what what about those? I mean, That's the actual vendor saying, Hey, this is what a design should look like. Maybe that's maybe that's the answer. Just follow those and and call it a day.

Yeah. So there's I think there's that's probably a, a pretty broad topic too, and we can almost dive into into a lot of little, We could follow a lot of trails on that one.

Validated design guides are probably are I think are probably the most underused, documents out on, on, manufacturers websites. I really do. And part of it, part of it I think is, is if you've never, if you've never really looked at them, they can be they can be kind of challenging. I mean, they're they should be pretty dense, right? They should cover a multiple multitude of ways to deploy, a product that will, that will give you the reliability and the, and performance and all that kind of thing.

But there's so I think one of the best things that you can do is if you're if you're going down this this track use those validated design guides. They they will give you, sample sample script, sample config scripts, they'll give you, deployment strategies.

They'll give you case studies and all those things are have been developed and worked on by the vendor. So, you know, you deploy this thing as the, as the design guide says, if you win, not if, when you call back into for technical support because of a because of an outage or something's going on with a piece of hardware, you can say, Hey, I went to page, four hundred in this design guide, and and it it it helps your your support staff understand your your topology rather than try and draw it down on a on a napkin as they're, as as your stress level is increasing, and their stress level is increasing. Things get missed. So it, it just gives you that, that, that block. Like I said, network should be kind of small, medium and large, and try and stay away from boutiques.

The design guidelines. Yeah.

Well, in as much as we can. I mean, we have been talking about how there are requirements, like a particular application that you're running that has specific threshold, therefore you employ a certain feature set, whereas in another network, you don't employ that feature set. So I I do think that no matter what, we're never gonna get into a true a true pure, small, medium, large, stamp out network.

You know, you know, as I'm saying it out loud, I think a lot of network can be small, medium, and large. Just not all. I think a lot of them. Now now that I say, and and I think about back on my experience, most of the time, they're at, you know, unless you're getting into, like, really high end day trading and certain health care, most enterprise networks as far as I'm concerned, it's like, alright. You're you're fine.

Probably even service provider. Most service providers in my experience have really similar needs. Like, get this packet in and get it out. Out of my core as fast as possible. You know, I I don't want it in the network. Let's let's move it. And and, you know, what's the most efficient path to get there as well?

Yeah.

But, But this but there's The thing too, though, is, like, if you if you use those those design guides, it does give you that you know, those building blocks. And if you have to bolt on a little, you know, a little, a little nuance thing for a, you know, for a business unit, you can.

You've got the ability to do it. And then it's, you know, then it's just, you know, I hate to say it, but you do have to go back and at least document it and say, this is what it's for. These are the requirements that this is the reason we have that little that little piece.

Yeah. Yeah. That makes sense. So the the validated design guides do give you that foundational element, those building blocks, like you said, to to say, this is what a a reliable and performing network looks like. And, of course, it gets you, like, maybe eighty percent of the way there, ninety percent of the way there.

And and in some cases, because the network or rather the customer doesn't have these, you know, very, very specific requirements, maybe even close to a hundred percent of the way there. Yeah. It is it is completely determined on vendor though. You know, if you're an entirely Juniper network, okay.

What about in these hybrid networks today when we're talking about, multicloud, we're talking about, data center might be vendor a. Your WAN might be vendor b. Security devices might be vendor c. You know, what do you think about, in, in that sense? Yeah.

So in, in that sense, again, I think if you're, like, if you looked at, Juniper Sysco, Arista, the, the topologies and the architects are gonna be, are gonna be very, very similar. Right? In your data center, we're we're all pushing, you know, three Clo, five Clo architecture, spine leaf, use PGP for, you know, for routing. So one of the, internally, so one of those things that you kinda wanna wanna look at, like your, your, your configuration, the things that you're gonna bang on the keyboard are gonna be obviously a little different from you know, from vendor to vendor, certain technologies may, may not be supported on a, on a certain platform. So those would be, you know, little changes.

But one of the things you have to look at, do these particular vendors for for interoperability are you, are are they doing proprietary things, or are they doing standard things? And when they say when the, when the you know, when the manufacturer says, yeah, we write to the I Tripoli standard or this RFC.

What does that actually mean?

So are you supporting all of that RFC?

Or are you supporting just a portion of that RFC? And, is it would it would it still be, interoperable?

So for example, there's a, there's a, a document that I came across, on on our side that talked about how to make a, between Juniper and Cisco, the, EVPN VX LAN. And there are a couple of differences. There are some nuances, on how how the, how the frames of the packets are being are would be exchanged between between these two devices.

We can do it. It's just you're probably not gonna see that in a in a validated design guide. You're gonna you're just gonna have to do a little bit more digging. Right? And, again, the the vendors do test interop, and they do put all the stuff down.

So And so it is in the, in the design guides.

Yeah. You can you can read you can read about doing, you know, how to set up your network, but, you know, for, for the example that you're talking about, interoperability, you know, that, that particular piece may not be in the design guide, but you could actually go off to another, you know, you may link off to another document and go Okay. I need to do this between, this vendor and this vendor.

Are there are there known issues?

Right. Right. So, yeah. So it sounds like that validated design guides give us, standards, baselines kind of for what the vendor says. This is what a deployment looks like.

Sort of a thing that we can go and refer to and and use our starting point. And, and then from there, like you said, you can jump off into even, you know, more specific information like interoperability and things like that.

You gotta start you gotta start somewhere in the design guides really, really help.

Yeah. Yeah. So that that makes a lot of sense to me. And, you know, especially if you're talking about changes that happen in versions and distributions and and code versions. Like, I'd like to see, okay, we have this new feature that was rolled out, or we have these new, this new software version and these wireless controllers, whatever, you know, what is the design supposed to look like? How how does how do those join messages get sent now?

And, and how does that play into, like, the client devices? Like, I I do wanna go read all that first. And so, that that is very, very important to me to design a good I I use wireless as my example because it's so finicky sometimes, especially finicky mostly because of the client devices. But you wanna know how all those components work so that way you can anticipate those issues. And and then and then when you're calling TAC, know, when you're calling Juniper Tech, and they're looking at your design, there's no, you know, major surprises there.

Yeah. Right? Now the other the other thing as well is, you know, we talked about how, how certain equipment has, has changed. Like, you, you know, the, you know, the network concepts, right?

But then when you get into, you know, we talked about, using PBR for, for, basically, a poor man's bestie WAN back in the day, and now we've got all these all these bells and whistles and widgets that that do all this stuff automatically.

So sometimes, if you have no experience with the technology, sometimes it's really good to work with your, you know, with your partner, kind of get some, some idea on what they would recommend, and then you can go to that design guide and go, oh, jeez, I can go to this chapter and actually look at how, how my partners are recommending we do this particular task. And then you, then you don't just sit sit at the end of the table and go, okay, man, I trust you. You can, you know, you can actually interact with them and come up to a better design. Because you've taken some of their, some of their recommendations, and you cross checked it with what the, with what your, what the vendor says is capable.

Yeah. Yeah. That makes a lot of sense. I mean, in pre supposes a certain level of engineering knowledge, though.

You know, you can't just jump into a validated design guide and then start copying and pasting, I mean, I guess you can I've done that. Let me say let me say that again. You can you can copy and paste config snippets that, you know, okay, this, and then you kinda change IP addresses and things like that. Maybe you change the router name in the snippet.

I have done that a lot, but, but again, it's it starts with the understanding of what going on. I understand, oh, okay. This is why they're doing this in the design guide. Oh, I see.

Okay. This is where that adjacency happens.

Or you can say, oh, I'm not doing that.

This, you know, this design guide says to use the edge ERP everywhere. And we're not gonna lock ourselves in. We wanna be, open standards like said for me or maybe not. Maybe we don't care. But, just as an example, that is, you know, that it it gives you the knowledge to then to then be able to understand what you're reading in this design guide. So, yes, it's super helpful. It's foundational, but it it does presuppose that you you do have certain level of of engineering, knowledge, and understanding.

I mean, would you consider that a weakness of a validated design guide? I mean, I I don't know. In asking you that question, I'm almost like, I mean, what what what what would we expect? Like, that you literally just buy this complete, like, box of working and everything works and, like, your entire data center just gets shipped in one day and and dropped in place and it all works. Like, no. It's a system. So So I guess it can't really be of of the weakness that it requires you to know engineering.

But Well, I'll tell you this, just as an amusing anecdote, went back in, man, it must have been ninety, nineteen ninety six, really when I started getting into into computers after swearing off that I would never do computers at all.

I went through like the the MCSE track back in Windows NT four days, Indeed three fifty one. And, my first IT job was a systems administrator up in up in, Danbury, Connecticut. After, after a troubleshoot, on a, on a domain controller, I'm like, don't wanna do this anymore. I actually want to get into networking, but I had no networking experience.

And, you know, back in the day, Cisco had really, really good, design guides and technical technical technical documentation.

I remember reading those things, but every one of them.

And the first Cisco Pressbook I got, I started I started reading through that, and I'm like, man, I read all these white papers already that you guys just printed it out and bound it. But Right. Right. Because I read all that stuff, my first networking job, I had zero experience, but I knew the technology. I knew how IPV four worked, and I knew how IPXSPX worked. And so I, I, I talked myself into, into that job, and then, was able to, to still do day to day things.

Sure.

You know, it so they they do help, and they do give you a sense of, of, kind of confidence that the technology may be new to you, but, but you know what's going on.

And then you know, with a little more experience, you can start to figure out, is this, you know, how do I need to change up this design, that's in this guide to fit the business need?

Yeah. Yeah. And then and that's why I said earlier that, you know, maybe the, design guide is gonna give you, you know, a vendor design guide is gonna or a validated design guide. Excuse me.

It's gonna give you, like, maybe eighty percent of that you eighty percent on the way there. Yep. And then you adjust, and that's still a huge benefit. Right?

Yes.

It's better than zero percent, and you're literally on a, you know, a piece of paper scribbling out lines and dashes and boxes inside a box.

You know? Visio is not your friends' enough.

Yeah. Right. I mean, the thing is though, we've been talking about you know, vendor design guide. So do you think that, you know, in my experience, you're looking at a Cisco or a Juniper design guide. They're they're talking about Cisco or Juniper, right, or or or whatever.

They're vendor focused. You think that that is somehow a negative in the sense that maybe it is lacking in just kind of the pure engineering of packets and protocols, and how do we design this solution? You know?

I don't know.

I don't think so. I mean, if you can, if you can imagine, you got a, you got a staff of people for, for, at a, with a particular vendor, they're building out these, doing all the testing, all the, all the lab work, you know, all the stuff. They're building networks, that they would that can be supported to write that for every particular vendor.

Like where do you stop? Right? So I think I think at least with the guide, with those types of guides, and they are a guide, right? It's not a, it's not, it's not the Bible. It it's to help you help you build these things. I don't I don't see a way for for any any OEM to be able to test against every particular, competitor.

This is I guess this is why we have, you know, the I triple e and and all these RFCs because because you can't actually test with with every vendor. If everybody, everybody writes the same type of, you know, nut and bolt, but the, but the shape is a little bit different for, because of the vendor or the color's a little different for the vendor, least you know, hey, this bolt is still gonna work with, with this particular nut.

So the concepts in the validated design guides are gonna be somewhat ubiquitous among vendors. Gonna be a little bit of a change, like you said, a nut bolt here, or, maybe the commands are slightly the syntax. I mean, if commands slightly different, but the the general concepts are the same. Right.

Yeah. That makes sense. I mean, and ultimately you are who who's gonna write a completely vendor neutral I mean, there's there's an incredible cost and effort that's required. So maybe it's done by the community.

I know there are organizations and consortiums and conferences that do that sort of thing together, maybe the I triple e itself.

But then that is such a heavy lift where it needs to be taken in in in the context of every network vendor that's out there and then every every time they update their code and so that's just That's insane.

It would be it would be constant in but but, you know, again, if you if you are in a in a vendor neutral environment, right?

You know, a lot of people will do, you know, Juniper Sysco Arista powered networks, and then maybe they'll use a palo alto firewall. Okay. Well, you know, Palo Alto does does routing, and they do, they do have a, have a standard, you know, OSPF, BGP, whatever. So you can exchange routes, and then it's just typically when what you'll see is, like, you know, like we mentioned for it.

There will be interoperability guides, but they aren't put into the, into the validated design guide. Okay. So interop is gonna be a specific use case for for your, your particular deployment. So you build it this way. With, with our stuff, you build it this way. And if we need to talk with someone else, Well, here's some here's some things that you need to, you need to be aware of to make your to get your your packets inspected by the firewall.

Yeah. For service change.

You know, Exactly. Service. And I in working with enterprises, both small, medium, and then and and very, very large.

I I haven't seen as much need for inter interoperability, I think, is the the industry says we need. I I really don't. So to have literally just a a random mix of operating systems and vendors, hardware, you know, in your switching environment, in your WAN environment. I I don't see that. I I really I I I usually see one particular vendor for, like, one network block. All my closets, IDFs, MDFs, are this brand.

Yeah.

And maybe this model, even. But whatever, it's there there's some uniformity there. All my data center might be a completely different brand, but I usually see uniformity within the data centers. Yes.

But then, you know, oh, for all our firewalls, we're gonna go with this. So I see these, like, network blocks that are broken up. And then you see kind of some uniformity of vendor and, and platform within that block but maybe each individual block is different. So you might not be Cisco or Juniper from campus to WAN, to security, to endpoint, though you could be, and I had many customers that were, back in the day.

But I I do see that as real life interoperability requirement.

Can I can't am I switching environment talk to my firewall?

About the about the only time I see, interop needs, like in a, in a data center or in a, or in a campus or whatnot. It's usually when when like the, the enterprise is moving from one vendor to another.

So they don't do a rip and replace.

Right.

Sure. It'll be like, okay, so now I've got, you know, Cisco and Juniper sitting in the same, at least side by side with each other doing the same functions.

And then you'll cut, you'll, you'll, you'll cut all the, the patch cables from one into another. So now you've got now you're now you kinda have, a group of of devices from different vendors, but but it's usually as as things are are shifting from one side to the other.

Yeah. Yeah. I've been there, you know, working with customers that were all HP switching. And then switch to all Cisco switching. I have had a lot of folks that new CIO comes in and they wanna do anything but Cisco. Right? They're an ABC philosophy person, and they're like, gonna get all of it out and so you're in a transition phase.

And then again, we're talking about ethernet and package and TCP IP. So I I didn't actually ever experience any interoperability issues of going from, like, my switching environment, which is vendor a to my my distribution environment or my WAN environment that was vendor being never had any issues because it's just we're not talking about completely different protocols. So Yeah.

It's it's the it's the underlying stuff that that just kinda works. And this is this is why you don't want to do something like EigrP or or do those very vendor, specific doing those open standards, really prevents you from vendor lock in, which gives, which gives you the, the end user a whole lot of flexibility if, you know, if they need to move from one side to another.

Yeah. Yeah. I mean, and I appreciate flexibility, but I actually recorded a podcast recently where my position was I don't I don't care that much about vendor lock in. If it solves my problem, you know, I'm choosing one vendor anyway.

So I actually don't care that much. Because, again, within one block, If I buy all my switching from one vendor or my WAN devices from one vendor, fine. I get a discount and, and sure. I understand there's a heavy lift, but that's the that's the balancing act that do when we're making these decisions and and designing stuff.

So Yep. Do you think that validated design guides then are truly, truly realistic since they've been deployed or developed rather in, like, lab scenarios and not necessarily real life scenario. I mean, you did mention case studies, so maybe I'm misbeing here. But what thing. Yeah.

So there's a there's a couple ways that the case studies happen.

I'll just pick on I'll just pick on January for now because it's, you know, everybody else may do it just a little bit a little bit differently, but Like, if we have a, a pretty good account or good customer, they, you know, they're, they're kind of friendly. They've had a, they had, good experience Yeah. We'll just say that they've been using the product for a while. So, we will work with those, with those customers to go hey, what was the problem that you were trying to solve?

What did the data sent? What, you know, what did, what did this particular technology? Why did you choose the type of technology? And how was it deployed?

And then how did it, how did it work?

So those case studies usually come from, from a, like, it's in the wild, and these things we're seeing, this is how it's used. Sometimes you'll see the case studies will actually come out of the lab, and there's all kinds of tools to make, you know, to try and break certain to to, like, artificially break networks, right, packet generators and and all kinds of stuff.

Sometimes when you're looking at a case study, it's it's good to see the, the label of the, you know, of the company that that that's being, sort of interviewed and telling you how it, how it worked for them. But those are those are very helpful.

Yeah. Again, when they're when they're doing these things in the lab, they they really are, they really are trying to make sure that the that all the main all the main points of a good network design, reliability, speed, reconvergence time, you know, what are the best ways to to make this thing, work well.

I said, so the, so the network engineers can sleep at night because no network ever breaks during the day. It always breaks. And like two o'clock in the morning, you know, it just never, it never turns out that way. So, yeah, I think I think design guys are pretty, are pretty tough trustworthy because they they go through a lot of effort to to get these things written.

Hey, Brian. You know what? I think what I'd like to do is have you on again sometime in the not too distant future to talk specifically about good data center network design? Because I know that's your background.

And I I wanted to talk to you about good network design in general. I wanted to talk about vent of validated design guides today. But I wanna maybe talk to you again if you don't mind about what a good data center network looks like and and really focus on that. Yeah.

I'd love to So in any case, thank you for joining me today, though.

This has been great. I love talking to Shop. So if folks wanna reach out to you with a question about, network design or or any other comment? How can they find you online?

So you can you can find me on LinkedIn.

Gee, you can you can email me as well. B glieson at juniper dot net. You can pick me up there. We're packets at bytes of cloud dot net. That's b y t e s, not b I t e s.

Got it. Okay. Great. And, you can still find me on Twitter at network underscore fill.

If you're on blue sky, I'm on blue sky now as well. LinkedIn just search my name and my blog network fill dot com. Now if you have an idea for a show for an episode, we'd love to hear from you, or if you'd like to be a guest on an episode of telemetry now, just reach out to us at telemetry now at kentech dot com. So for now, thanks for listening, and bye bye.