Keith Interviews Wes Purvis, Abhi Shamsundar and Jussi Kiviniemi of MIST
Product Manager at Mist
Wi-Fi Janitor (Products, Marketing, Strategy)
Abhi M Shamsundar
Product Management - Mist Systems
Mistyfing Juniper Switches06_26_20.mp3 transcript powered by Sonix—easily convert your audio to text with Sonix.
Mistyfing Juniper Switches06_26_20.mp3 was automatically transcribed by Sonix with the latest audio-to-text algorithms. This transcript may contain errors. Sonix is the best audio automated transcription service in 2020. Our automated transcription algorithms works with many of the popular audio file formats.
So Vietnam mistifying the exosphere in terms of being able to say, you know, you have fillable at least not just monitor, but also configured and completely cloud manage E X switches, X portfolio switches on the Jennifer network. So that is that is brand new.
WLAN interview. Getting to know the leaders, movers and shakers in the wireless LAN world.
Welcome back to Wireless LAN Professionals podcast. This podcast is going to be special for us. We'll be working in a video format. This is our first video blog kind of thing. We'll be doing sort of podcast, plus video. You could listen in on audio only or you can watch. We'll have both available for you to watch. Well, today we have some folks, some friends and new friends from Mist. And I think they're kind of taking over the world some coin, a new term, Mistify. They're going to Mistify. It's with some new things they've got going. How about if I have them introduce themselves. First up, Jussi.
Hey, everybody. I am Jussi, I do all kinds of janitorial duties at least, including hang out with Keith.
Thank you for for having us. Thank you so much, Keith. Love you. Love your podcast. Glad to hear, Wes!
My name is Wes Purvis among the product management team. Work with Jussi and Abhi at Mist and happy to be here.
Hello everyone. My name is Abhi Shamsundar. I'm part of the Mist Product Management Team as well, and I am actively involved in trying to improve products. I'm taking the lead. Keep that.
Well done. I appreciate that. Well, we're here today and you have some new stuff to show us. So rather than just get off in the weeds, let's jump right in. What's the new things you want to show us? That from Mr. Feist. Less junipers, less the whole group.
Well, seems be you being kind of the center point of this whole thing. Why don't you take it away? Absolutely.
So then what's important to us piece of of missed as far as. What we've been doing.
My friend business has been for us to say how is the network doing from a client's perspective? And all of that is possible because of the telemetry that we get from the access points, the friction, the telemetry, the more real data that you can give and make very good insights of it. And that's what we call C Wassily frame. But service level expectations having keeping to the same theme we've gone about and taken the next level. That is that to which the device is connected, which is the access layer. So Vietnam mystifying the access layer in terms of being able to say, you know, you have full ability not just monitor but also configure and completely cloud manage E X switches, X portfolio switches on the Juniper Network. So that is that is brand new. You're seeing everything that is missed team from the perspective of Juniper, such as starting them.
Well, I've got a question for you. One of the things I like about the missed part, where your radio resource management uses it, it uses the client's perspective in making decisions. So once it makes a decision to change, transmit power, if it causes clients difficulty, then we don't fix it and take it back if it's a problem. So how is this this mystifying on the switch level going to affect things? So I can see all of our client and our team have really good interface? What's what's the next step at the access layer going to give us?
That's a really good question.
So in terms of how you approach the problem, very similar thought processes behind approaching the switch problems as well. We've taken into consideration as to what are the most common problems that come in to the switchboard in terms of, for example, we got me when one layer at a time. So layer one and layer two issues at the switch layer. Seeing what we NDB also spoke to how, you know, Jake Tech receives cases of detectives. Excellent. Jennifer, what one of the most common themes among all of them was just for us to say how what what common problems do you see deep? Is that a problem for us to say one more? An example is for us to say you have bad cables, but you know about it. And how are we able to find that out? Again, using telemetry is what we're bringing in, being able to proactively tell you that you grab your device that is connected to it's connected. We have a cable that is going bad or not uptick that is doing that. Similarly, you have issues that in you're going ahead and start controlling it. The way is way too much than it should be because this device actually has more traffic giving such insights as to what devices that are affected among your, you know, every every campus. Are we talking about kinds of sports? Probably. Sunnyvale campus. We're talking with 10000 or to say that and being able to identify exactly the interfaces to which clients are connected to and showcase only that only those sports affected items through various different pieces like you have cable that may have gone bad.
You probably have congestion that in your not offline traffic is constantly being dropped because you're not able to, you know, pass traffic along the. This isn't able to have practical things of this nature. Addressing problems from the perspective and bringing them about to the forefront instead of having them hunt and peck, going to each individual interface is what I'll be bringing to the switchboard.
Well, I like that. But since this is a video format this time around, can you show us?
Yeah, definitely would love to. Let let me go ahead and share my screen.
And while Abby is setting it up, w what. What you were involved with this quite heavily as well. What was your kind of if you had to name one favorite thing that you had in either product or the project leading to base.
I know it's a tough question and it comes up, you know, I'm throwing you under the bus, but did you have something?
Yeah. So so far, my favorite thing that we've done switching wise is we have a map view. And this what this part's not new. We've had it for a little while, but we have a map view of of which access points are connected to which switch. So it allows you to see, you know, if I lose a switch, what's my blast radius? And so that's that's traditionally been my favorite feature switching, but with some of the newer configurations of that that Obbie is about to show. I think that there are some some really interesting things that we've done in terms of making configuration easy, which is one of the things that wireless has historically been pretty good at is making configuration easy. And, you know, through you, you've had a controller to be able to bulk configure your access points at once. And that's one of the things that that I.B. will show us is how we can very easily and in bulk apply configuration across many, many, many switches.
So this is kind of like your demo when you did five hundred in five minutes or something even.
Yeah, yeah, exactly. It's it's being able to provision to configure as many switches as you would like in an easy like, you know, you don't have to port. One is going to be this port two is going to be this, you know, being able to, you know, in an easy either an automated way or in a in a standard fashion, be able to apply configuration just like you can do to an access point. I mean, that's kind of that that has me most excited about the configuration piece.
So I've seen run ads, was done some demos before showing how that can be scripted and because because the API is inherent in misted device. How does that work when you move up to the Juniper stack with that API levels?
So API is now, you know, N-E available also also for the switches.
And when you mentioned scripting and, you know, automating deployment of sites and stuff like that, many of those features that, for example, previously have required speeching, even like auto proportioning 80s auto naming APIs, that kind of stuff that's actually brought into the UI these days as well.
And now even, you know, for the AP it but also for the switching light, like much of those things traditionally done through the Mist API now are done through scripting.
So how much of that is it that you're talking to the missed API and the missed API internally talks to the Juniper API or is there is the missed front end talking directly to the Juniper Newsfront and is talking to the missed API?
That's how it works. You know, all of these, like everything that you see in the front end comes from the mistake P.I. and they missed under the hood talks with Juniper was using SSA to write using that content Odesa six secure channel for us to talk to the switches.
But as you see, he said. So I first forefront is always building the API. So what have you seen the API study, even from the switches perspective. So in the end, the UI today, you see, you will you already have a lot more from the API perspective because that is build trust. So everything that Ryan did in terms of being able to say, I am able to script provisioning, find that sites totally plausible, the same exactly same process, the same process and efficiency for the switches as well. Again, that is fully thanks to us building the API first and then going on and building UI and the FBI as well. Let's see what you got. Awesome. So most of fuel, food familiar, but most are ovett of this particular screen. This is the. This is what we call the S&P framework. Now, we've brought the exact same S&P framework into the wired world. That's right. We have very similar constructs. You have pre connection as well. The supposed connection, IP connection. Of speaks about how well are you able to connect with the network? If you're having authentication problems, you're defining document x map. Either one of those on your switches be able to identify and let you know that you have problems connecting. And again, the engine where we are able to identify the scope of impact, whether it's it's just one one device or is it all devices connected to that switch or all the switches, that that also is a part of my resections story. Similarly, the attacks that successfully connect us as a nest. It has to classify as either the TPP, if you are unable to get an IP variable to let you know as to which clients are affected.
And also the there is a third piece along with the free connection and post connection is the switch health. Again, this is learnings from from who we spoke to as customers, as well as people who are actually fielding questions. All of those resulted in having a certain SMB Israel. But what is really exciting for me is this is the throughput SLV, the throughput recipes, further classified into four different pieces. So there are five different pieces, though, when if you are being storm controlled a lot and your actual device requires a lot more in terms of if you're part of some control parameters, a super aggressive. It is a quick indication whether it's sporadic or not in terms of Pinelands condition. I think it's it's one of the cool things that we are able to say just by looking at this particular in on this particular screen and double clicking here and say these are the interfaces that are constantly congested. Is it time for me to upgrade those links? And that that is exactly our intention for us to showcase both congestion as well as condition uplink. What that also means we are able to directly understand what an uplink is or a means we can derive again using some of our algorithms for us to understand which is the uplink for a switch. And I understand that, you know, a lot of devices sometimes if everything is going not fine and the uplink is also one game, you might see some condition. And it's not very evident for an NBA user unless we bring that about, seeing what kind of packet drops.
Is it is it bursty or is it constantly having issues with congestion? We bring that about as well. This piece is one of the interface anomalies, but it is a very it's a bucket which encompasses three different problems on the day. One of them being, are you having a bad cable issue? One of them being devices that connecting to the network and not negotiating very well. The third one being, if you have if you're having empty mismatches where the traffic is flowing from one switch to the other, the other switch has, you know, jumbo frames can figure out the on the other side. Are you left to that system? Default at layer two with empty you being placed there drop the packets are dropped and variable to identify such issues as well. That is the end. The new one that we've introduced, this is the network, SLB. The network is a is an extrapolation of us talking to the switch, saying that you're not. We know what that kind of thing. We know what the latency instead looks like. So if your traffic is not going out to move, going outside. We're extrapolating that information from our experiences and saying you might have this kind of experiences when you're going through. If my ISP, for example, does my home switch right now, as I did see a couple of dips over the last night, you could see that and you could double click for that as well. So on further click, you'll be able to see whether it was cost.
You can latency and see. And exactly what times or did that happen? Similar constructs for the interface, anomalies, congestion. All of them. The good part is you'll have a very good, very small, concise list of exactly list of interfaces that that is being affected at any given point in time. So we can switch back a few days and see a few of those devices if there are anything effective. But the goal for us, again, has always been showcase exactly the areas and the distribution of devices that are being affected. Similar is the story of us being able to bring the MA resections story to the same table here as that's what most vaccines has always been. A cup of coffee for us to showcase of. What is what does the admin immediately need to attend to? And when they look when they look at their dashboard in the morning, if they have anything that they need to be concerned about, it will show here. So missing we LAN. This is one of our. So he's with mistake fees and the switches in place. He will go out and try. If there is a LAN provision on on on your W LAN interface, but that does not mean plumbed on your switches. The trunk is missing that interface. We are able to identify you. So you don't have that IP going in the dark. Bad cable. You can click on the cable. Exactly. Look at what work that way is affected. You'll also be able to run a cable based on public that because you see now completely on or switching.
I have a question for you. Just in the short term while you're talking. Sure.
One of the things I missed is good at collecting lots of data and doing some analysis on it. If you have all the switch data collected, is it possible to give me an answer to the question, do I need to go to Angang on my apeace? So if you can track that traffic, can we see are any of the APIs exceeding the one gig at the access layer? You talked about going upstream. But can you tell whether or not we're congested from switch to AP?
Absolutely key. So the service levels, if you if you look at the throughput, the congestion piece is exactly dedicated to that.
So this identifies a meeting that is downstream from the search perspective. So if you're if you're happy, is sending out enough traffic that at the at at some point in time the switch isn't oh, the interface isn't actually able to handle it. We are able to identify and actually indicate exactly the region. Where are the interfaces, where maybe it's not all of these maybe some APIs exist in in some crowded area, or are you are doing a test in the lab with 160, 160 White-Out, either cases. If we are able to create a situation where it is exceeding a gig and if there's a one connection, we'll definitely be able to identify a greater rakia under the condition metric and point you to exactly the interfaces that are affected because of the problem that you just described.
Thank you. Can you can you apply that across your entire infrastructure to say, you know, 10 percent of our switch ports that are connected APIs need to be upgraded? Or I mean, what I'm looking for is some metrics we can give back to say it's time to upgrade our switches.
I think that that's a that's a very good part of it.
If it is something of a metric in terms of saying if we know that it is the APIs that are constantly under the condition conditions story, it definitely is not a bad idea for us to go to. We have the answers. It's just the way we represent it. And I think it's definitely not a bad idea for us to think about it.
And it's it's here, right. If you look at the congestion percentage estimate, made it clear these what we're looking at is all the switches and all the client devices connected to those switches.
So that congestion percentage would tell you, like across my entire range infrastructure in this organization, I call bad and congested it.
So this isn't like a view of a single switch or anything like that. This is all this week choosing the entire organization. So I took you off your pace there, returned to your demo, putting them on my resections, which I just.
Which is just spoke about. We also do have as well, as Keith alluded to, there is a ton of information because you have a lot of information that you could look at from the switch perspective on every single individual switch perspective. You know, how many? What's the utilization memory bytes? What's the power draw? Are you close to being close to being oversubscribed? Things of that nature as well as, if anything, comes up in the quarters.
May I interject for a second? Go ahead. I would just add one point read to the kind of the journey of missed relative. If anybody's ever had a missed presentation, you kind of know and, you know mobility feel that we've been telling the story for years. We're on a journey of a self-driving network. And so from on the wireless side, the first step was getting the data into the cloud. And then from there, we could do data science and our A.I. on top of the data that we have.
And so we're we're we're very well on a journey on the wireless side. And actually, we've we've gone through the same exact journey on the switching side as well, which is which is what I.B. is showing. So the first the very first step was getting getting the juniper switches to actually connect to the cloud and getting data from those switches. And we've done that and we've been doing this for four months now. And and so you'll see us continue to leverage this data, just like we've done for wireless. Do the same thing for Wired magazine. That with the Essawi is that you just showed up. And we have the raw data, which is what I'll be showing on the screen. And there's just so much, so much potential that we can do now that we have the data into the cloud. Good.
Good point. To kick in another question. And I'm just being obvious here. I'm assuming this is for juniper switches or can we mystify, you know, somebody else's infrastructure?
That's a very good point. So some of the features for monitoring are available for all of the switches L.A., DPL and BP met.
We extract the information. So if you plug in even one Eustachy on that switch, you know, we get information on like like I'll be might have some examples here, but a decent amount of information we get from any switch. But from Juniper's, which case we get a lot more, plus the configuration. We cannot today configure anybody else's switches, for example, that there's no reason that we couldn't.
It's just a matter of development effort. So I think we don't have anything to say today.
But I hear nothing. I hear nothing. So is this is this in current shipping code or is this an upgrade that we have to look at getting upgraded to everything you're seeing today?
Keith, in terms of being able to run assurance, all the Marvis actions as well as the confecting that I'm going to demo, all of this is available for Beta starting last night. So, again, you're showcasing that is shipping right now.
And I'm assuming this is like Miss, you know, one was every Friday, every week you you update code. So it's very current.
Absolutely. Very similar constructs. Everything, every every production push you will definitely get and you're in your features.
And that's based on other states through the process of switching as well. There's there's no no changes from the architectural perspective. So I think having said, you know, tagging onto investor's point about being able to say be able to now identify, you know, missing we Leontes are bad cables, what the next translates to I didn't good for the murderous action study has always been self driving. What we had aiming towards as we go along is to be able to solve those problems or at least give a better insight to deliver to the customer as we go along. One of the examples that that is immediately coming out is we've understood that it's a bad cable from our heuristics or from from the data we learn now. We can also have we also have the ability to run cable that some research. So the next goal is for us to run the cable based on the switches and have that a portrait. Each of you having to do that. I'm missing me, Lance Saulteaux missing me and problems as we go along so that the end goal is for us to be. You have the data. You are already confident of the data being presented. Then you could let the customer annoy and let us know, saying you could actually solve this problem yourself. Obviously, that cables, you cannot fix the cables, but villains could be fixed then. Those are those are the items you had climbing towards in terms of, you know, artificial intelligence helping you are not have to intervene, solving smaller problems as such.
I think one of the most important things teams of off of the push that came out is that everything that I showcased right now, it has been shipping for about four months. But the important thing that is coming out tomorrow is the ability to configure our switches and configure, not just being able to configure on an individual switch basis, but make this extremely easy for you to go and outplay this across a lot of devices on your network. And that's that's what we we we we specialize in terms of having the easiest configuration for out for individual, such as aswell as managing thousands of switches at the same time. So there is flexibility in the way we've done these templates. You're able to see primary use cases of off switch being Julys for us to actually create what we know in what we call a support profile. And I'd like to call them, as persona's, you know, Kameda as a persona, a piece of persona I Yoki devices like a track or anything like that. They all are personas and usually they all have extremely similar configurations as they as they go along. An AP usually has, you know, Creevey lens or Falvey lens with one naked villain. Similarly, a camera is usually one x three LAN, which is already it's all of this is is is known.
Now, we can we can easily build what we call Colace for profiles led by before we already populate a few things for you. IAP, AP. We also added Kameda but add another one called H Rack for example. And. Let's give it a network. If you don't already have a villain associated to it, you can actually create that real quick associate relearnt. And there we go. We have a track network right there. And now how do you actually go ahead and proclaim this information across your multitude of devices? You may have 48 for Devizes, 24 for devices, different models of devices. How do you push this across? Is where the configuration rules help you? VERIN Today I've got a 48 for Twitch. I've said you can either apply to a particular switch model or you can also give a role to the switch saying apply this to across all my access searches in general. And that that is a very simple way of saying I lied in all my searches as axis and just pushed these across all of my different ports that are available. So the angle for us, too, is to say. You have different kinds of devices and you would like for this to be pushed across different across different Port Said are available. But how do you do that without complicating the opposition here? It was very simple.
When I added the new villain. And now this will be available across all different devices and your network has to step in. We also have the flexibility of, you know, being able to say, I would like, you know, my switch to have only this particular switch to have something very unique. Let's say I'd like to change the radius of where this is talking to because I want to ratify a brand new radius or a brand new instance of the server. And I want I want my blast radius to be small. And you could just override whatever you got from your site. But you will always have information of what is coming from the site out of our template and orders individually on a switch and extremely easy, quick way of configuring uncontrol. Getting switches as well as this is the role that I mentioned, rarely mentioned. What is the role of the switch? And it's pretty similar. But overall, B, without having going to interview me too many, do any details of this other configuration model? Is the baby built? It is for us to be able to flexible enough to run a simple one switch deployment. Also manage hundreds and hundreds of hundreds and thousands of switches. And that's what I wanted to quickly showcase as a part of the demo. Hope, hope, hope it give you a quick insight of what we are coming doctorate.
It was great. Thank you, baby. I think for the second half of this recording you were offering. I think we should change tack a little bit and hear a little bit from each of you of how you went from. West and U.S. for years now. And you both came from the Wi-Fi world Wi-Fi tools. And from another Wi-Fi vendor as you moved over to mist, mist was also in Wi-Fi. And now you're moving into the into the switch side. You're kind of going and branching out. I'm just wondering how you did your own personal learning. How did you learn the new things you needed to talk about your support? The Juniper model as well as Nest?
I mean, I did because he's gone. He's had to go through the biggest transformation he's on. He is aware of this guy as well.
Ok, I'll go first. So my career started off with in the late late 2000s. But with the end of a front doing a lot of the switching and dropping. So that's where my my roots are from when I started off. I started off with routing and switching a lot of Q8 and then solution engineering. From that perspective, the same role actually morphed in the early 2010 2011 timeframe. That's when it actually morphed into the converged wireless and wired architecture. That's why that's where I got right by the wireless bug. And I actually went through the wireless, certainly all the way from the doesn't leavens until recently. But I had to go back to the roots of doing switching. So it was helpful that I had some origins in the switching space. And wireless is extremely tightly coupled with switching. I mean, this there's usually a lot a lot of things that are being wireless. Problems are going to be has its origins and switches. So we've closely been working usually with those as well. But yeah, by the background where I started from, definitely we had a lot to actually bring this back to the knowledge. And our approach towards solving a problem is entirely from the mis certainty as to how actually you approach any given problem. You actually take the problem as to how the customer would see this and then how to solve the problem. But that particular journey was most in the last two to three years from MIS and combining these two. Is this what you saw today in the wire into the wire as well as widen the spaces?
You're playing with switches and routers over 10 years ago and kind of came back to it now.
What have you seen has changed in the last decade in the switch world?
I think one of the few things that that come to mind issues in terms of just the switching by itself, the core underlying architecture hasn't changed a lot. But how you actually deploy, such as it was, it was very painful. You either write the script that goes into every box and have make configuration happen. And also the underlying problems were never addressed, saying if you have a layer one layer two issues, if you're spending three loops, for example, what is the origin of the loop? Somebody plug something in that is always usually the origin of the spending loop. It's not one of the problems you are trying to address as well. Without spilling too many beans up there, but trying to address problems from the perspective, there are inherent problems of switching. And how would be able to identify and mitigate early that that that approach of one, configuring us, being able to configure the switches at scale, as well as identifying problems and going on going off to them with the new tools? If you haven't had the eye of the MLT based approach, isn't you. But the underlying architecture that are newer, newer architecture designs coming out. Right now, the Woolworth campus where we explain is broken to the to the access layer, but that is still the adoption is slope for a number of reasons. So the architectural would all in the last 10 years hasn't been the same, but the approach towards configuration and troubleshooting definitely has changed.
Thanks, West. How about your journey? Tell us how you ended up where you are now.
So, yeah, I think so. It started out with a little bit of of networking knowledge. That's, you know, got him networking through through through school and. And it was kind of just a general networking and then started to focus on wireless and. And and I have been in the wireless field ever since. But I think, you know, just like any wireless person, there's you always need to have some switching knowledge because these pesky access points have to they have to connect back to a network somewhere. And so I think my you know, my my switching knowledge has always been wireless centered. Meaning what? You know, what would Vreeland's I need to configure on the port to be able to support this access point. Then how do I get my traffic where I wanted to go? And so actually, for me, the you know, so I was I have kind of, you know, basic knowledge enough to be enough to be dangerous. But coming to coming to most of them as part of Juniper, the most difficult transition was was transitioning from Cisco, IOW based switch. And and we're very comfortable in Cisco Iooss to Juneau's, which is a completely different syntax.
And, you know, what is this concept of commit, you know, commit or commit, confirm? And you set commands first as I did it and I just told it from a whole different ballgame. And so that was actually the biggest challenge for me. So it was just a matter of being able to, you know, pick up, pick up a juniper switch and just play around for it. You know, it's because the underlying functionality is the same. It's just the way that you go about it. And the thing that I like that we're doing is, is now that's all in the cloud race. You don't have to you don't have to necessarily know, János. You can it will help if you know Juneau's, but you don't necessarily have to know, you know. So, you know, just being able to say, you know, I want my access point to connect this port with these with these settings is. It's something that is is a lot easier now with us with the configuration of these.
So how did how did you go about learning Juneau's from IOW? What was the what was it? Was it like a week and you're all better? Did you have a little cheat sheet or did you take classes?
Every. So there's actually a A Juneau's for Iowa's engineers guide that the Ginnifer has that helped quite a bit. And then the voxel what helped the most was, was having Jennifer switch in hand and to be able to configure it and do what I was trying to do. And just this is how you do about this is how you do that. So it's just it's just, you know, during a couple of times with a little bit different syntax and then you start picking up and it's it's you know, it's it's a lot easier now than it was six or eight months ago when we got started with it.
Usually you're the last one of this group to get involved and play. How do you go about the process of of learning missed and then you had to learn, missed and then learn. And then add Juniper on top of it?
Yeah. I mean, throughout my life it's been a little bit of these and that. It's like studies.
It was I.T. software development and industrial engineering management.
And my first job was business models and developing location where application over a regional Wi-Fi network. So my friend built a location server from scratch and I built applications on top of this location server. And it's it's been a little bit of everything that I think of how much a lot of transition. That's why I joined as an art tearless systems engineer. I just installing and training Ardella Systems. Then we spun off a site survey out of it. And, you know, you'll see take a look at these sites of a thing that manage and see what comes out of it.
And then at some point, it grew really big.
But the thing is, like like, OK, we had a good run, I think. But then, like alcohol, your absolute default is like we said, you always looked at like the wired side of flyest.
I didn't it almost looks the wired side at all. At Cahow during 15 years. Like, I wasn't forced to I wasn't actually installing and deployed networks at all. You know, in all honesty. So I had almost zero experience in routing and switching before missed. Take that and the high expectations and, you know, you get it. You get a pretty good imposter syndrome pretty quickly because I knew nothing about routing, switching and also not about like enterprise Wi-Fi. Like from the practical side. So so.
So it was really, really, really tough in the beginning. I'll be honest with you. But then, like we said, you know, stuff like this helps.
I actually have two of these just four fail over redundancy in the same book. Just two copies. Yes, absolutely. I'm planning to give it to somebody. So so that and having based juniper boxes, you know, that's really been the key thing. I think for me, it's just playing like you learn stuff from the books. But I learned by doing kind of a guy. So it just start configuring, you know, XRX, E Xs and see what happens and break them. And then I get eternally frustrated by, you know, me not, you know, being an expert on stuff like that.
I think most of us who are in this industry have home labs for that very purpose. So what I'm hearing is if you if you want to be making this transition over the switches, you got to start playing with switches more.
That's that's the only way, I think. And the more you bug stuffing and the more you break them, the better off you are. And that's the frustrating part.
Now, after all these like countless hundreds of hours of this and the switches and everything, now I'll be you come out with something that, you know, it simplifies it's way, way too much marista created for all the Juneau's that I had to go through. Where's the creative?
It's in your knowledge. You have it internally. You see. Just feel good inside.
I don't even know what that means. But the Altig. So what was it? What would you recommend if someone was saying, OK. I like what I saw here today that IEEE showed. How would someone get involved? What's what's the next step. Say they're they've there CWNA, maybe CWDP. They understand wireless, but they see this, this whole cloud thing and I is in the future. What would your recommendations be to have them move forward.
Same thing as before. Get your hands on some like modern Wi-Fi gear and put it on the side like you have your legacy stuff.
Put it, put one or two even modern and stuck Wi-Fi gear next to it. Put put a switch that connects to it and see how it works. You don't have to like it. Right. It's not for everybody, but at least give it a go.
Yes, you're right. Nations.
Yeah. System, it's just a matter of playing for sure. I think that you you learn by doing and and you get interested by doing so much dumbo's all day.
But until you actually have hands on with you know, with what you're trying to figure out, you don't really learn as much as you can.
So it's it's is my my recommendation is just is just it to.
I, I tend to agree. I started on the Mist online training and was looking at a screen and went, wait. I haven't missed her. Let me just log into the to the to, to the dashboard. And I did and I got lost for a couple hours playing when I came back to the course. I already know that. I didn't know that. Because you can you learn a lot on your own just by playing with it. And I think it's what you see said. It's when it breaks and you get frustrated. That's what forces you into doing the extra learning.
Absolutely. But I, I got to say, like also the fundamentals are important.
I, I had to take a juniper, of course, off of like a few days of switching and routing basics. I mean, you get pretty far by it just screwing everything up and fixing them. But you also need to understand the fundamentals agree to.
If you don't know networking, you're going to you're not you know, you're still you ultimately you need to know networking. I don't think that the requirement is going away, having your recommendations.
Absolutely agree. I was about to just say the same thing. You start from the basics, especially even for us when you have blipping products.
It actually is extremely important for us to go through and understand what what the existing technology is and where the problems lie. And how do we address them? Very similar constructs for somebody who's coming into the into to playing into the new new way of doing things. Maybe we can beat the easy way out of using the best sports to configure quickly and get get get by. But then eventually it will head over a long period of time to understand what is underneath. And that is what will make you a better engineer. Is that right?
Well, I'd like to thank all three of you. I'll be in West and you see for your input today, we'll put in the show notes, links to that.
Juneau's for Iooss Engineers document, as well as links to the training pages for Juniper as well. If you're interested in missed, they have tons of webinars. You can see the previous ones, but they're they're producing them all the time. So for those of us that wireless LAN professionals podcasts, we're grateful to the people who joined us. And we'll see you next time.
Thank you for joining us for another episode of the wireless LAN professionals podcast. The podcast for wireless LAN professionals by wireless LAN professionals. Be sure to follow us on Twitter at Wireless Landreaux. For all the latest news and updates and also connect directly with Keith on Twitter at Keith Parsons.
Head over to w w w w LAN prose dot com for this episode shown us as well as the latest in all things Wi-Fi.
Automatically convert your audio files to text with Sonix. Sonix is the best online, automated transcription service.
Rapid advancements in speech-to-text technology has made transcription a whole lot easier. Do you have a lot of background noise in your audio files? Here's how you can remove background audio noise for free. Automated transcription is getting more accurate with each passing day. Here are five reasons you should transcribe your podcast with Sonix. Create better transcripts with online automated transcription. Quickly and accurately convert your audio to text with Sonix. Better audio means a higher transcript accuracy rate. Automated transcription can quickly transcribe your skype calls. All of your remote meetings will be better indexed with a Sonix transcript.