What makes a good network design?

Philip Gervasi: 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 business for more than five minutes knows the answer, it depends. It depends on a lot of things, actually. Today, my good friend Brian Gleason, a veteran network engineer, veteran Cis 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 Gervasi, and this is Telemetry Now. Hey, Brian, it's good to see you, man. I have been looking forward to talking to you for a long time. I remember when we first met in person at least. I think it was at Cisco Live, right?

Brian Gleason: Yeah.

Philip Gervasi: That was 20-

Brian Gleason: Yeah, yeah,

Brian Gleason: 2018

Brian Gleason: in San Diego.

Philip Gervasi: 2018, 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 a long weekend, and that was a lot of fun. But yeah, that was great. It was great meeting you in person and great seeing you again today, really is. So I know your experience because we're friends. So I know from just knowing you for the past few years, your extensive background as a network engineer turning a wrench, as a solutions engineer or solutions architect, whatever you folks call pre- sales engineers and working in the security space, working in the campus, working in the data center, all these areas, you have a really broad experience. So what I want to talk to you about today is network design. You've seen it all. You are a veteran engineer. So starting off with this, maybe it's an unanswerable question, but what in your opinion makes a good network design? You can answer that question in the context of the campus and the data center, or maybe there's some even more broad concepts that cover everything. But what do you think makes a good network design?

Brian Gleason: Well, let's see. That's a nice question because I think it almost differs from whether or not you're in the trenches or if you're trying to sell or you're trying to be a VAR. If you work for a VAR-

Philip Gervasi: Okay.

Brian Gleason: ... if you'retrying to 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 some business unit has given you? Then how do you make your life easier?'Cause most network engineers in the trenches just want to sleep in the middle of the night. They want the network to be self- healing. So if your design works to meet those business goals and keep you asleep, can fix itself, it's probably a good start. So if you're on the VAR side and you're trying to help make a design, that's where you need to look at best practices. How do you build in redundancy and resiliency and still meet the needs of your customer? On the OEM side, on the vendor side, you want to sell them the correct part. Don't just go in for cheap, but you want to make sure that the parts that you're giving them meet their needs for longer term. So it's going to be things like investment protection, stability. Do they really need bleeding edge or can you be a partner with your customer and not just a wham, bam, thank you ma'am, kind of thing?

Philip Gervasi: Yeah. Yeah.

Brian Gleason: So that's kind of broad.

Philip Gervasi: Well, yeah, and I posed it in a broad way'cause I'm trying to start off by at least identifying those main concepts that we can then drill down into. Right off the bat, you mentioned reliability, stability, those are the things that I know, especially on the enterprise side, but, of course, in the service provider realm. Whether that be webscale, hyperscale, e- commerce, really, anywhere that you are networking, which is like everywhere today, I find that network operators really value stability and reliability and fault tolerance over everything else. So I believe that a good network design starts with that as the foundation. 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 you'd agree the network doesn't exist for itself. It exists for the express purpose of application delivery. Well, any service delivery, but it's usually in the form of an application. Do you know Tony Efantis, by the way?

Brian Gleason: His name sounds familiar. Yeah.

Philip Gervasi: Okay. Tony was on this podcast a while back, and I remember we were having this conversation. He actually corrected me and said, " You know what? It's not actually application delivery. Yeah, it's application delivery, but even that is a proxy for end users, people accessing their data."

Brian Gleason: Correct.

Philip Gervasi: So that's really what the network is all about, is making sure that human beings and then machines to machines can access information, can access data.

Brian Gleason: The network customer is every butt in a seat and anywhere across the globe. So it's-

Philip Gervasi: Yeah, exactly. Exactly. So how do you design a network so it's reliable, resilient and performance and all those things? Yeah, that's when you start to then consider, " Okay, who are my engineers that are going to be managing this on Day 2? How much money do we have?"

Brian Gleason: Right.

Philip Gervasi: "Where are we today?" That's another consideration. " What does the network look like today? Therefore, is this a gigantic rip and replace? Then what does the design look like then?" But yeah, I feel like that it's an all of the above thing and not as much on, I don't know, platforms and specific switching router boxes.

Brian Gleason: The thing is, I think, I always starting with some of my constraints because knowing those and having those defined really gives me... it shortens the leash a bit on what I can do to meet those expectations and provide the best service for my users, all those seats. Typically, once know those constraints, I can almost design something like a, " Hey, we can do this for this thing, a good, better and best approach." So at least now your business units and all those people that have constraints 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'll have these potential problems." Maybe you're not quite as reliable. You don't have redundancy within the network. Maybe that's okay because you're a very, very small office or you're a home office. If you're reaching out to small office, home office, especially after the pandemic when everybody's working from home, you're just needing edge connectivity and you're not so much worried about redundancy there, right?

Philip Gervasi: Right. Right.

Brian Gleason: So who are you trying to service helps dictate how you're going to design the network.

Philip Gervasi: Yeah, yeah, that makes sense. Who is the actual end user in this case? Is it the city of Chicago?'Cause a service provider or a region, a geographic region in the world, and then a good network design is going to have these transit paths and you're going to look at these peering relationships and the cost associated with them.

Brian Gleason: Correct.

Philip Gervasi: So your requirements, business constraints, technical constraints, they change as a result of the nature of who your end users are. If you're a, let's say, a large medical facility like a healthcare system where it's a bunch of hospitals and data centers, it's still huge but much more traditional. Maybe there is literally no tolerance for risk in those scenarios.

Brian Gleason: Right.

Philip Gervasi: Remember, you don't hear it that much, but the whole fast fail often mantra that we heard for a few years-

Brian Gleason: Yeah.

Philip Gervasi: ...it spilled into networking and it was the idea of being agile and all these things? I'm like, " I wouldn't tell customer, hospital X that it was all about stability and reliability above everything else, beyond anything." But then like you said, therein lies a cost. So you go to your customer and you say, "In this particular data center, how mission- critical are these services?" Because if we start doubling everything and to increase fault tolerance, and then we want to also improve fault tolerance at the hardware level, and we're putting in an active standby or active- active firewall, whatever, whatever, you start doubling your costs. You start doubling licensing costs, and maybe then you got to double that in your standby data center. It goes up exponentially.

Brian Gleason: Yes, it does.

Philip Gervasi: 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? Then the complexity of that, I know having done those kinds of projects, I'm going to go back to healthcare'cause 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 absolutely no downtime." We're talking about physicians and operating rooms and all this sort of thing. I'm like, " Okay, absolutely understood." Then you look at who's going to manage this thing on Day 2, and you look at their staff. They have an entire staff, but they're outsourcing almost all their high- level engineering and they just have low or mid- level for the day- to- day. I'm like, we're talking about some pretty advanced routing concepts. So all your links are being utilized and active and load balance. So that way, yes, it's both fault- tolerant and performant where we don't have idle links and idle devices and all that sort of thing, and it gets me nervous. I actually remember, maybe it was before the pandemic, so 2019, early 2020, I had one customer in New York, just north of New York City, hospital system. I'm not even joking, Brian. I got nervous where I was laying in bed at night and talking to my wife about it like, " I'm scared this hospital is going to go down" if somebody wiggles the wrong wire. I don't know if that ever happened'cause I ended up leaving that company. But yeah, yeah, those are all the things that we think about in network design. Me, in my experience on the enterprise side, it's not really as much about protocols and platforms and things like that.

Brian Gleason: Most vendors are going to use the same Broadcom chip set or they use merchant chips. So you're going to have some very similar performance metrics anyway.

Philip Gervasi: Yeah, true.

Brian Gleason: Some vendors will do things better than others. Maybe the CLI or the management or API calls or all that kind of stuff is more fully developed. So when you start thinking about maybe Day 2 operations and you can start moving into automation, then you're controlling what thing is being pushed out on to which servers, or I'm sorry, 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 policy, a routing policy to take your network down. Then it becomes just you can do more with less, I think, as long as you start to standardize how you're deploying your VLANs and your routing policies and that kind of thing. So your design becomes much more important for Day 2 operations, especially when you start getting into automation and orchestration and things like that.

Philip Gervasi: Yeah, that makes sense. 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 2.

Brian Gleason: Absolutely.

Philip Gervasi: Yeah. It's not just purely like, " Is this a very performant and resilient network?" Which it should be.

Brian Gleason: Yeah yah.

Philip Gervasi: Hopefully, those boxes have been checked, but it's, " Now, can we run with this moving forward?"

Brian Gleason: Right.

Philip Gervasi: If you can't, then there's a problem and maybe it's not a good network design. Interesting.

Brian Gleason: Phil, you actually-

Philip Gervasi: Yeah, you talked about-

Brian Gleason: Phil, you actually mentioned it too-

Philip Gervasi: Go ahead.

Brian Gleason: It's like a good network design is actually going to take into account the skill set of the people that actually have to manage the thing, right?

Philip Gervasi: Mm-hmm.

Brian Gleason: So if you have people with very limited experience in managing a network and you've got a 10, 000 node data center with spine leaf and super spines and automation, it's going to be very, very difficult to have a stable network because the people running it, they just don't have the experience and full understanding.

Philip Gervasi: However, I would say 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.

Brian Gleason: Absolutely.

Philip Gervasi: Right? " Oh, you don't have the right staff. We're going to give you this Mickey Mouse network." Well-

Brian Gleason: You can't do that.

Philip Gervasi: ...you can't run your hospital on a network.

Brian Gleason: Right.

Philip Gervasi: Go get some better engineers.

Brian Gleason: Exactly. Yeah.

Philip Gervasi: So I do think that there is a balance there. I also 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.

Brian Gleason: Right.

Philip Gervasi: You know what I mean?

Brian Gleason: I used to argue, " Look, the network shouldn't be a boutique shop. We should have small, medium and large, and we're going to be kind of Walmart. When you come in, you know what you're going to get every time." Again, that goes to having a stable network. If you're doing these inaudible one- offs, then when something goes bad, it takes forever to figure out where the problem may lie.

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

Brian Gleason: Exactly.

Philip Gervasi: I almost said documentation, but it's lack of. Greg Farrow used to say that all the time, that every network is a snowflake and we love our little snowflakes-

Brian Gleason: Yes, yeah.

Philip Gervasi: ... andwe care for them and all of that. So now what about today? Here we are, 2023, 2024, and 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 maybe we're using some MPLS, but it's much more hybrid. So now we're relying on an SD-WAN that runs over the top of the public internet. Again, something we don't own or manage. So yeah, to me, today's designs, a good design today is going to look different than a good design 15 years ago. However, conceptually, the goals are the same, reliability, performance, Day 2 management, all those things like you said, like we've been talking about, but it is going to look different. It's which overlay are we using for our public network? What are we using to exchange routes? To what extent are we relying on our public cloud provider for resources? Maybe we can balance that and mitigate that risk. What do you think today, is it really the same as it's always been, or do you think that there's new considerations there?

Brian Gleason: Like you said, I think the concepts are still the same. You still have the same types of requirements, the same needs to get the best bang for your buck, the fastest speeds, end user expectations. In fact, at Juniper we have this thing called SLEs, service level expectations. It's not how the network is performing, it's how is your end user actually experiencing the network? So I don't care if something goes down, as long as my user is still able to attach to the network, able to connect to certain things.

Philip Gervasi: Well, you care a little bit.

Brian Gleason: I'm sorry?

Philip Gervasi: Well, you care a little bit.

Brian Gleason: Yeah, just a little bit. Yeah, but it doesn't-

Philip Gervasi: I understand.

Brian Gleason: As long as I don't have someone yelling at me because the network sucks or it's down or nobody's getting on, and I can still say, " Actually, the networks still up and you're still seeing the same metrics, I'll just go and replace this device that you think is causing the problem." But then it's meantime to innocence. So those are still concepts that are there, but the technology is changing so much that it's a, how do you use the innovation to maintain or improve your ability to meet your customer's needs and goals? So you mentioned SD- WAN. I remember back in the day when it was policy- based routing, right?

Philip Gervasi: Mm- hmm.

Brian Gleason: You'd have to define, hey, these particular sourced destination addresses and these particular ports need to go out this other interface, and then everything else will come down my free relay network or my MPLS network. That was all manual. Well, we did that because you needed to isolate certain applications for the speed and for the performance, right?

Philip Gervasi: Right. Yep.

Brian Gleason: Well, now SD-WAN can do all that stuff automatically. You carve out the classes and which applications you think that are already pre- canned. You get on your little controller, you go, " Check, check, check, push," and now you're getting metrics back. Applications can be punted over different circuits based on latency or all these other bandwidth and network health metrics. So 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 just should just work." You have to keep learning something new. You can't be stale in this type of career.

Philip Gervasi: Yeah. Yeah, for sure. We still want that reliable and stable network. Now the complexity is such that you have to learn new technologies in order to continue to have that reliable and stable network. So that's still the core. It's still having a high- performance connectivity to the applications, ultimately, the data for a human being to get to. It's just how that happens is different. So there was a day when we were talking about, oh, the coolest new Top of Rack, End of Row, and then data center core switching and lossless connectivity for V Storage and vMotion, Storage vMotion, excuse me, I said it wrong. It's been a long time. Those were the things that we needed at the time to provide a performing and resilient network. Today it's the same concept. We want performing and 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 hash- based ECMP. So there's different tools that we need in 2023, 2024 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, and it never ends. 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, tightening-

Brian Gleason: Right. Right. Right.

Philip Gervasi: ...bolts, literally turning wrenches. 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 it's just, it's a constant like, " Wait, what just came out? All right, I guess I'm studying that tonight."

Brian Gleason: Yeah, yes.

Philip Gervasi: It really is.

Brian Gleason: It's funny because I think if you're... at least, I won't speak for everybody, but when I was on the VAR side, I can remember going into certain customers and they'd ask some specific question about a technology. I'm like, " Geez, I'm just one chapter ahead of you right now, but I've got enough inaudible

Philip Gervasi: But they never knew that. I would never-

Brian Gleason: Yeah, they-

Philip Gervasi: Inaudible

Brian Gleason: They would never know that, but you can at least talk to them, and as long as you said something. If you have a VAR that will always give you the answer all the time, and you might want to just be a little suspect, you should hear, " I don't know, but give me a little bit and I'll come back and give you the information." Part of it, especially on the network design part is like Farrow says, " This is our little snowflake of the network." Sometimes there are specific requirements 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 your network architect for your partner says, " I don't know, but let me go back and look." You got to expect that he or she has more resources than you do to help find an answer. So there should be a pretty good partnership between network engineers when you get into the design phase of your network.

Philip Gervasi: Yeah, yeah, that makes sense. As we start to actually build the design out and start selecting routing protocols and platforms and where things go and how things are connecting, it really does depend on what the customer's requirements are. That does include all of those things that we've discussed like cost and performance requirements, what thresholds can we not exceed, things like that. That's going to determine whether it's a good design. Whereas, that same design handed to a different customer might be absolutely terrible.

Brian Gleason: Right.

Philip Gervasi: It just doesn't meet their needs. As an example, I had a healthcare, I'm going back to healthcare, a healthcare 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, six data centers. They were in GCP, they were not in Azure or AWS, and we were designing an SD-WAN. One of their requirements was that they could not exceed something like 35 milliseconds of latency on any link. So they were all fully MPLS, lease lines, private everything everywhere because of that. It was specifically because of their imaging devices, MRI, PET scans, CAT scan, all that stuff required very, very low latency and it was mission- critical. We're talking about people's lives. So that was a technical constraint, which turned into a business constraint as well because it tied to cost of that particular SD- WAN design. In that process, we therefore did not go with certain vendors or certain topologies because of that, so that was a determining factor. Whereas with other customers, and I've worked with... I remember one customer here in the northeast where I live, it was a chain of pet stores, pet food and toys and fish tanks and that kind of stuff. There was a whole bunch of them all over the northeast. All they cared about was like, did the access to the internal website, which at the time was still internal, not in the cloud, 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? The inventory wasn't a huge thing'cause it wasn't like TCP, correct itself. It got through eventually. That was it. That SD- WAN design, very, very different, still, and I hope the customer thought, was still a good design, but completely different than the healthcare system.

Brian Gleason: It's requirements. You got to know what you're designing too. Otherwise, you're just, " Hey, here's a box of stuff, and I'm going to dump it on the table and however it comes out, since you're not giving me any requirements, then I'm just going to plug stuff in."

Philip Gervasi: Although, I do have to say I was with VARs for most of my career and many times when I was an engineer and not the solutions architect doing the design, so I got the statement of work and I'm looking at it. I'm reading through it, and I'm in a kickoff meeting, and I'm like, " This is not going to work"-

Brian Gleason: That's right.

Philip Gervasi: ... or, "This is ridiculous. This is such an overkill." Clearly, clearly this was an effort to pack as much margin on hardware as possible on this particular deal. So much of this stuff is going to sit idle or is completely unnecessary or they're never going to touch this once I set it up. They have three engineers back in the back office there, and they're never going to touch it.

Brian Gleason: It's never going to roll out.

Philip Gervasi: It's going just sit there.

Brian Gleason: Yeah.

Philip Gervasi: Yeah. Yeah. I'm like, " All right, fine. The account manager 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. I would say that it met all the requirements. Apparently, they paid for it. So I guess it met the cost requirement as well. So in the purest sense, it's still a good design, but I did notice there was a lot of overkill. There was a lot of unnecessary over- engineering, that kind of thing.

Brian Gleason: Yeah. Yeah, that happens probably more times than it should. Again, I think it's just requirements. If you don't have those things documented, then it's really hard to go, " This is the best solution for what we need to accomplish."

Philip Gervasi: Then be able to discern and say, " This here, yeah, I get it. It meets the requirements, but this is all completely unnecessary."

Brian Gleason: Right.

Philip Gervasi: "I'm spending an extra$800, 000 I don't need to spend." But what about validated designs, you know how vendors, Cisco, Juniper, I'm assuming Arista and the other big vendors, they have these validated design guides, right? You work for Juniper-

Brian Gleason: Yes.

Philip Gervasi: ...so I don't know what you call them internally, but what about those? That's the actual vendor saying, " Hey, this is what a design should look like." Maybe that's the answer. Just follow those and call it a day?

Brian Gleason: Yeah. So I think that's probably a pretty broad topic too, and we can almost dive into a lot of little... we can follow a lot of trails on that one. Validated design guides, I think, are probably the most underused documents out on manufacturer's websites. I really do. Part of it, I think, is if you've never really looked at them, they can be challenging. They should be pretty dense. They should cover a multitude of ways to deploy a product that will give you the reliability and performance and all that kind of thing. So I think one of the best things that you can do is if you're going down this track, use those validated design guides. They will give you sample script, sample config scripts. They'll give you deployment strategies. They'll give you case studies, and all those things have been developed and worked on by the vendor. So you deploy this thing as the design guide says, if you win, not if, when you call back into for technical support because of an outage or something's going on with a piece of hardware, you can say, " Hey, I went to page 400 in this design guide," and it helps your support staff understand your topology rather than try and draw it down on a napkin. As your stress level is increasing and their stress level is increasing, things get missed. So it just gives you that block. Like I said, network should be small, medium and large and try and stay away from boutiques, and the design guys help you.

Philip Gervasi: Yeah. Well, and as much as we can, we have been talking about how there are requirements like a particular application that you're running that has a specific threshold, therefore, you employ a certain feature set. Whereas in another network you don't employ that feature set. So I do think that no matter what, we're never going to get into a true, pure, small, medium, large stamp out network. As I'm saying it out loud, I think a lot of networks can be small, medium and large-

Brian Gleason: Right.

Philip Gervasi: ... just not all.I think a lot of them now that I say it, and I think back on my experience, most of the time, unless you're getting into really high- end day trading and certain healthcare, most enterprise networks as far as I'm concerned, it's like, all right, 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. I don't want it in the network, let's move it, and what's the most efficient path to get there as well." But then the-

Brian Gleason: But this is the thing too, Phil, is if you use those design guides, it does give you those building blocks. If you have to bolt on a little-

Philip Gervasi: That's right. That's true.

Brian Gleason: ...nuance thing for a business unit, you can. You've got the ability to do it. Then it's just, 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. This is the reason we have that little piece."

Philip Gervasi: Yeah. Yeah, that makes sense. So the validated design guides do give you that foundational element, those building blocks, like you said, to say, " This is what a reliable and performing network looks like." Of course, it gets you maybe 80% of the way there, 90% of the way there. In some cases, because the network, or rather the customer doesn't have these very, very specific requirements, maybe even close to 100% of the way there. It is completely determined on vendor, though. So if you're an entirely Juniper Network, okay, what about in these hybrid networks today when we're talking about multi- cloud, we're talking about data center might be vendor A, your WAN might be vendor B, security devices might be vendor C? What do you think about in that scenario?

Brian Gleason: Yeah, so in that sense, again, I think if you looked at Juniper, Cisco, Arista, the topologies and the architecture are going to be very, very similar in your data center. We're all pushing 5- Clos architecture, spine leaf use BGP for routing internally. So one of those things that you want to look at, like your configuration, the things that you're going to bang on the keyboard are going to be obviously a little different from vendor to vendor. Certain technologies may not be supported on a certain platform, so those would be little changes. But one of the things you have to look at, do these particular vendors for interoperability, are they doing proprietary things or are they doing standard things? When the manufacturer says, " Yeah, we write to the IEEE 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 would it still be interoperable? So for example, there's a document that I came across on our side that talked about how to make a... between Juniper and Cisco, the EVP and VX line, and there are a couple of differences. There are some nuances on how the frames and the packets would be exchanged between these two devices. We can do it, it's just you're probably not going to see that in a validated design guide. You're just going to have to do a little bit more digging, right?

Philip Gervasi: Yeah.

Brian Gleason: Again, the vendors do test interop, and they do put all this stuff down.

Philip Gervasi: So it is in the design guides. inaudible

Brian Gleason: Yeah, you can read about how to set up your network, but for the example that you're talking about, interoperability, that particular piece may not be in the design guide. But you may link off to another document and go, " Okay, I need to do this between this vendor and this vendor. Are there known issues?"

Philip Gervasi: Right. Right. So yeah, it sounds like that validated design guides give us standards, baselines for what the vendor says, " This is what a deployment looks like, a thing that we can go and refer to and use at our starting point." Then from there, like you said, you can jump off into even more specific information like interoperability-

Brian Gleason: Right. Right.

Philip Gervasi: ... andthings like that.

Brian Gleason: You got to start somewhere, and the design guides really, really help.

Philip Gervasi: Yeah. Yeah, so that makes a lot of sense to me. Especially if you're talking about changes that happen in versions and distributions and code versions, I'd like to see, " Okay, we have this new feature that was rolled out," or, " We have this new software version and these wireless controllers, whatever, what is the design supposed to look like? How do those join messages get sent now, and how does that play into the client devices?" I do want to go read all that first. So that is very, very important to me to design a good... I used wireless as my example because it's so finicky sometimes, especially... finicky, mostly because of the client devices, but you want to know how all those components work so that way you can anticipate those issues. Then when you're calling Juniper TAC, and they're looking at your design, there's no major surprises there.

Brian Gleason: Yeah. Yeah.

Philip Gervasi: Right?

Brian Gleason: The other thing as well is we talked about how certain equipment has changed, you know the network concepts. But then when you get into, we talked about using PBR for basically a poor man's SD- WAN back in the day, and now we've got all these bells and whistles and widgets 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 partner, get some idea on what they would recommend. Then you can go back to that design guide and go, " Oh, geez, I can go to this chapter and actually look at how my partners are recommending we do this particular task." Then you don't just sit at the end of the table and go, " Okay, man, I trust you." You can actually interact with them and come up to a better design because you've taken some of their recommendations and you've cross- checked it with what the vendor says is capable of that.

Philip Gervasi: Yeah. Yeah, that makes a lot of sense. In presupposes a certain level of engineering knowledge, though.

Brian Gleason: Yes. Yeah.

Philip Gervasi: You can't just jump into a validated design guide and then start copying and pasting. I've done that. Let me say that again. You can copy and paste config snippets that, okay, and then you change IP addresses and things like that. Maybe you change the router name in the snippet. I have done that a lot. But again, it starts with the understanding of what's 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 design guide says to use the edge ERP everywhere. I'm not doing that, and we're not going to lock ourselves in." We want to be open standards, like you said, or maybe not, maybe we don't care. But just as an example, it gives you the knowledge 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 does presuppose that you do have a certain level of engineering knowledge and understanding. Would you consider that a weakness of a validated design guide? I don't know, in asking you that question, I'm almost like, what would we expect that you literally just buy this complete box of networking and everything works and your entire data center just gets shipped in one day and dropped in place and it all works? Like no, it's a system. So I guess it can't really be of a weakness that it requires you to know engineering, but-

Brian Gleason: Well, I'll tell you this, just as an amusing anecdote, back in, man, it must've been 1996, that's really when I started getting into computers after swearing off that I would never do computers at all. I went through the MCSE track back in Windows NT 4 days and NT 5. 1, and my first IT job, I was a systems administrator up in Danbury, Connecticut. After a troubleshoot on a domain controller, I'm like, " I don't want to do this anymore. I actually want to get into networking," but I had no networking experience. Back in the day, Cisco had really, really good design guides and technical documentation. I remember reading those things like every one of them. The first Cisco Press book I got I started reading through that and I'm like, " Man, I read all these white papers already. You guys just printed it out and bound it." But-

Philip Gervasi: Right. Right.

Brian Gleason: ...I read all that stuff, my first networking job, I had zero experience, but I knew the technology. I knew how IPv4 worked, and I knew how IPX/SPX worked. So I talked myself into that job and then was able to still do day- to- day things.

Philip Gervasi: Sure.

Brian Gleason: So they do help, and they do give you a sense of confidence that the technology may be new to you, but you know what's going on? Then with a little more experience, you can start to figure out, " How do I need to change up this design that's in this guide to fit the business need?"

Philip Gervasi: That's why I said earlier that maybe a vendor design guide is going to... or a validated design guide, excuse me, is going to get you 80% of the way there, and then you adjust. That's still a huge benefit, right?

Brian Gleason: Yes.

Philip Gervasi: It's better than 0%, and you're literally on a piece of paper scribbling out lines and dashes and boxes inside of boxes.

Brian Gleason: Visio is not your friend sometimes.

Philip Gervasi: Yeah. Yeah, right. The thing is though, we've been talking about vendor design guides. In my experience, you're looking at a Cisco or a Juniper design guide, they're talking about Cisco or Juniper or Arista or whatever, they're vendor focused. Do you think that that is somehow a negative in the sense that maybe it is lacking in just the pure engineering of packets and protocols, and, " How do we design this solution?"

Brian Gleason: I don't know. I don't think so. If you can imagine you've got a staff of people with a particular vendor that are building out these... doing all the testing, all the lab work, all the stuff. They're building networks that can be supported. To write that for every particular vendor, where do you stop? So I think at least with those types of guides, and then they are a guide, it's not the Bible, it's to help you build these things. I don't see a way for any OEM to be able to test against every particular competitor. I guess this is why we have the IEEE and all these RFCs, because you can't actually test with every vendor. If everybody writes the same type of nut and bolt, but the shape is a little bit different because of the vendor or the color's a little different for the vendor, at least you know, " Hey, this bolt is still going to work with this particular nut."

Philip Gervasi: So the concepts in the validated design guides are going to be somewhat ubiquitous among vendors.

Brian Gleason: Yes.

Philip Gervasi: There's going to be a little bit of a change, like you said, a nut and bolt here, or maybe the commands or slightly the syntax, I mean, of commands are slightly different, but the general concepts are the same.

Brian Gleason: Correct.

Philip Gervasi: Yeah, that makes sense. Who's going to write a completely vendor- neutral one? There's an incredible cost and effort-

Brian Gleason: True.

Philip Gervasi: ...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 IEEE itself. But then that is such a heavy lift where it needs to be taken in the context of every network vendor that's out there, and then every time they update their code, and inaudible

Brian Gleason: Right. Yeah.

Philip Gervasi: That's insane.

Brian Gleason: It would be-

Philip Gervasi: That's insane.

Brian Gleason: It would be constant. But again, if you are in a vendor- neutral environment, a lot of people will do Juniper, Cisco, Arista powered networks, and then maybe they'll use a Palo Alto firewall. Okay, well, Palo Alto does routing, and they do have a standard OSPF, BGP, whatever, so you can exchange routes. Then it's just typically what you'll see is, like we'd mentioned before, there will be interoperability guides, but they aren't put into the validated design guide. Okay. So interop is going to be a specific use case for your particular deployment. With our stuff, you build it this way, and if we need to talk with someone else, " Well, here's some things that you need to be aware of to get your packets inspected by the firewall for service chains."

Philip Gervasi: Exactly, service chains. Working with enterprises, both small, medium and very, very large, I haven't seen as much need for interoperability-

Brian Gleason: Correct.

Philip Gervasi: ... Ithink as the industry says we need, I really don't. So to have literally just a random mix of operating systems and vendors, hardware in your switching environment, in your WAN environment, I don't see that. I usually see one particular vendor for one network block. All my closets, IDFs, MDFs are this brand and maybe this model even, but whatever. There's some uniformity there. All my data center, it might be a completely different brand, but I usually see uniformity within the data center.

Brian Gleason: Yes.

Philip Gervasi: But then, " Oh, for all our firewalls, we're going to go with this." So I see these network blocks that are broken up, and then you see some uniformity of vendor 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 do see that as real- life interoperability requirement. " Can my switching environment talk to my firewall?"

Brian Gleason: About the only time I see interop needs in a data center or in a campus or whatnot, it's usually when the enterprise is moving from one vendor to another, so they don't do a rip and replace.

Philip Gervasi: Right. Sure.

Brian Gleason: It'll be like, " Okay, so now I've got Cisco and Juniper sitting at least side- by- side with each other doing the same functions," and then you'll cut all the patch cables from one into another. So now you have a group of devices from different vendors, but it's usually as things are shifting from one side to the other.

Philip Gervasi: Yeah. Yeah. I've been there. Working with customers that were all HP switching and then switched to all Cisco switching, I have had a lot of folks that a new CIO comes in and they want to do anything but Cisco. They're an A, B, C philosophy person, and they're like, " All right, we're going to get all of it out," and so you're in a transition phase. Then again, we're talking about ethernet and packets and TCP/IP. So I didn't actually ever experience any interoperability issues of going from my switching environment, which is vendor A to my distribution environment or my WAN environment, that was vendor B. It never had any issues with that.

Brian Gleason: Right.

Philip Gervasi: Because it's just we're not talking about completely different protocols, so-

Brian Gleason: Yeah, it's the underlying stuff that just works. This is why you don't want to do something like-

Philip Gervasi: What about-

Brian Gleason: ... EIGRP,or do those very vendor- specific... Doing those open standards really prevents you from vendor lock- in, which gives you, the end user, a whole lot of flexibility if they need to move from one side to another.

Philip Gervasi: Yeah. Yeah. I, and I appreciate flexibility, but I actually recorded a podcast recently where my position was I don't care that much about vendor lock- in. If it solves my problem, 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, all my WAN devices from one vendor, fine, I get a discount. Sure, I understand there's a heavy lift, but that's the balancing act that we do when we're making these decisions and designing stuff.

Brian Gleason: Right. Yep. Yep.

Philip Gervasi: Do you think that validated design guides then are truly, truly realistic since they've been deployed or developed rather in lab scenarios and not necessarily real- life scenarios? You did mention case studies, so maybe I'm misspeaking here, but what do you think?

Brian Gleason: Yeah, so there's a couple ways that case studies happen. I'll just pick on Juniper now'cause everybody else may do it just a little bit a differently. But if we have a pretty good account or a good customer, they're friendly, they had good experience, yeah, we'll just say they've been using the product for a while. So we will work with those customers to go, " Hey, what was the problem that you were trying to solve? Why did you choose the type of technology and how was it deployed, and then how did it work?" So those case studies usually come from a, " 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 artificially break networks, package generators and all kinds of stuff. Sometimes when you're looking at a case study, it's good to see the label, the company that's being interviewed and telling you how it worked for them. But those are very helpful. Again, when they're doing these things in the lab, they really are trying to make sure that all the main points of a good network design, reliability, speed, reconvergence time, what are the best ways to make this thing work well, like I said, so the network engineers can sleep at night'cause no network ever breaks during the day. It always breaks at 2: 00 in the morning.

Philip Gervasi: Right.

Brian Gleason: It never turns out that way. So yeah, I think design guys are pretty trustworthy because they go through a lot of effort to get these things written.

Philip Gervasi: 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. I know that's your background, and I wanted to talk to you about good network design in general. I wanted to talk about validated design guides today, but I want to maybe talk to you again if you don't mind, about what a good data center network looks like and really focus on that.

Brian Gleason: Yeah, I'd love to.

Philip Gervasi: So in any case, thank you for joining me today, though. This has been great. I love talking shop. So if folks want to reach out to you with a question about network design or any other comment, how can they find you online?

Brian Gleason: So you can find me on LinkedIn. You can email me as well, bgleason @juniper. net. You can pick me up there. We're packets @ bytesofcloud. net. That's B- Y- T- E- S, not B- I- T- E- S.

Philip Gervasi: Got it. Okay, great. You can still find me on Twitter @ Network_Phil. If you're on Bluesky, I'm on Bluesky now as well. LinkedIn, just search my name and my blog network, phil. 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 telemetrynow @ kentik. com. So for now, thanks for listening and bye- bye.