this is the art of network engineering podcast in this podcast we'll explore keys technologies and talented people we aim to bring you information to expand your skill sets and toolbox and share the stories of fellow network engineers guys i had the craziest dream last night you were all there don't worry it's not that creepy it was like last july and you guys had this crazy idea to do a radio show type thingy i'm not even sure if there's a name for something like that it's pretty revolutionary if you ask me you'd record yourselves once a week talking about technology and chatting with really cool people there was someone that worked on networks on cargo ships a lawyer turned network engineer and even someone in australia automating networks for some reason andy kept asking him which way the toilet water spins over there classic andy then it got a little weird there were bongos and a bogus superhero that kept talking about translating ip addresses anyway this stream is so cool i wonder what you'd call a show like that cables and stuff what the heck is up with tech what about the art of network engineering yeah i think that's what you guys would have called it you should think about doing something like that be pretty sweet just remember that if you do this was all my idea click the wrong button here the host yeah that's what i was trying to do i'm sorry i should have told you that when we were uh no i just always wait for aj just stares into space after you're done and i always wait for him to start the show and i don't know if he's waiting for a queue well i i couldn't tell if he was done usually he does welcome yeah i was going to tell you oh you didn't say welcome to it you blew it yeah i yeah i know no i'll never do it again that's kind of exactly how this podcast started yeah an appropriate intro given we just celebrated our first birthday thank you thank you tim i am aj murray at no blinky blinky he is andy at andy laptop andy how are you doing sir hey i'm good happy to be here sipping out of his art of network engineering plant glass get one like amazing you can go to our merch store art of netanyage.com i don't know how but it makes my beverage taste better and i feel a little smarter that's the cocaine we line the glass with he did say it was on the rocks is that is that cocaine lined prune juice here we go dan howdy packet howdy dan how you doing howdy man how's it going it's going it's going good here too bad you couldn't get your new camera to work tonight i don't even talk about it it works until we hit record someday exactly it was great it worked great for like 30 minutes tim at tim burtino tim what's up i am feeling really good with the audience that we have watching us our our wonderful patreons uh as we record this this is so much fun yes this is cool got a little chat going right yeah yeah we got a chat going they can see us as we record they can interact with us ask us questions chime in on what we're talking about this evening as we get going so uh that's just one of the many perks of being a patreon we'll talk about how you can join that program later but uh but first andy can i get a goat scream or did that thing die last week i meant to replace the batteries let's say it's funny every time all right we gotta we gotta make it it's like a terrible remix of that remix well the good the good news is we've had so many wins in the first year of the podcast that the batteries have officially died so yeah put in some new batteries i'll get mine to sub tonight that's there we go congratulations you've all killed the goat yeah so many wins winston's just tired dude i just picture dj like scratching a disc hey whoa tim i used to beatbox on the side no big deal i believe when's that intro coming why didn't i not think of that next week next week all right lots of wins this week so uh let's get going uh robin c passed his applied probability and statistics class congratulations robin i hated statistics i see i will say in all of the computer science math courses i had to take prob and statistics was like the only one that actually made sense like it was real math like i took a math class it was called discrete math what the hell does that even mean it's like you whisper it to people yeah i don't know i avoided math at all costs that's why you could mark of that and now i work with you guys so the marketing story folks you don't have to be a computer science major to be surrounded by genius people all right uh the complete noob passed the jncia junos congratulations big win big win david alicia passed the sisa exam which is the securing email with cisco email security appliance and secured his ccnp security congratulations i love that guys very nice mountain right there uh i love this one i i was so proud when i saw this posted on twitter earlier corey freed passed his a plus exam and he did it wearing an a1 t-shirt i saw that picture that was awesome yeah his past his score report and there he is you just barely see the top you know what it is though you know what it is you know what that means aj our our stuff it's lucky it's lucky yeah lucky shirts yeah lucky shirts for sure i've got one in the mix i'm working on a design that says i'm just kidding corey you did that all on your own yeah uh so here's a pretty cool win uh steve blur posted in the winning channel on the discord discord um he was basically changing careers right going from audio engineer working in tv and broadcast uh and over the course of 2019 2020 he obtained ccna secure and security plus and a few other uh certifications landed a job working as a data center tech and uh just recently they accepted an offer with a significant salary increase doing cloud networking for a broadcast company so he kind of came like you know full circle there very nice so that is awesome very cool very very awesome uh marvin 121 passed the n plus exam the comptia n plus so congratulations marvin very cool good job ticker bits ticker bits past ac nine wait a minute what happened tim no what happened tim's on the floor keep moving keep moving hey i i can't help these names man these these are the names that people choose to identify themselves with new goal we gotta get some crazy discord names in there what do you mean that's my favorite moment of the show this past year is watching what just happened to tim the best part was how he said it just it's like he said it that he had to say it again because he was i like to repeat myself oh my gosh i like to remove myself all right anyways so so tigger over there what's mr bitz doing yeah they passed the az-900 hey congratulations tigger bits zapdos 26 past the aws ccp that's certified cloud practitioner so congratulations zapdos 26. yeah good job on that uh so that's all the wins for this week let's give a very special welcome to all of our patreons uh thank you so much for joining us and supporting the content we create uh we we really do appreciate it so joining us in the past week was jonathan matt stink chris michael luke david that i have to call them so thank you stink thank you what was that last name though i didn't i didn't hear no no root not root okay yep welcome all thank you yeah thank you guys i hope to see you in our chats not only is it cool that we have patreons in the first place um we have patreons from all over the world uh and so it's it's so uh i don't know i just never expected it right like as as much as people suggested that we do the patreon program we didn't think that we would get as many as we have already and we very very much appreciate your support if you are interested in being a patreon please go to patreon.com forward slash art of netenge you'll see that we have a three different levels of patreon you can be just a general supporter you can do the all access so that will get you the links to the live streams and you can join us every thursday night at 8 30 pm eastern time that's about minus four hours utc and uh you can chat with us while we record the show you can see who we're interviewing if we're doing an interview that night and it's just a really cool way to get early access to some of our content as we produce more content we will be giving our vip which is the the third and final uh patreon level that we have if you're part of the vip program you will get extra early access to all of our content some of the content we create is you know created kind of just in time so even though we record the episodes on thursday night by the time we get done editing and processing and all the fun things that have to happen to the episode sometimes they're not ready until you know basically by the time we're ready to post this thing so if we do get to a point where we're super early ready with our episodes we'll we will certainly provide those to our to our vip members in addition to the early access to our content you also get a permanent 15 off code in our merch store and you will get early access to all new merch designs as and when they come out we will you know float them out to you in the patreon uh and when we do this to all the patreons right like earlier this week i found some really cool hats i have like a leather logo on the top or whatever and uh and so we just want to get your feedback like is that something that you'd be interested in buying if we ever made that available kind of thing so we appreciate all of our patreons thank you so much for your support uh andy can i get a goat scream or do i have to do it uh we'll try hey all right wait you gotta shake it come on girl it's not a magic goat you got one more in there who's a good girl come on no i'll change your batteries baby we'll recharge it okay fantastic uh so exciting news in a1 history we we hit our first birthday it's been one year uh since we started this thing um what a crazy year so much has happened uh so much we we hoped for so much we had no idea and and we're here and we got a lot more coming super excited for all the stuff that we're working on um lots of stuff going on behind the scenes uh dana and i are working on some some skunk works projects i'm super excited about so tim you want to do something on the side and i'll tell these guys about it gonna say i'm pretty sure we showed you guys about it yeah yeah we most certainly told you guys about that yeah yeah we did i'm really excited you guys you guys working on some really cool stuff i'm excited to see what's coming but i digress um tonight we are talking about change management right everybody's favorite topic um i don't know about you guys i have seen i i personally have some experience with it working for various size businesses and i have a lot of experience with it working with all of my customers so i'm keenly interested in in your experience with change management but i think to start the conversation off we have to explore what is it and why do we have it do any of you guys suffer i mean have change management in your organizations today oh my god yes yes we have a level of change management um so you know i i that's one thing i think we need to talk about too right is how strict is some of this change management and how loose is it right like let's back up why do they exist right what's their main function why are they there yeah that's a good way because i'm not sure sometimes and and i'm googling it as we talk and then i still don't have a super clear answer on you know like at one point i guess somebody just was like hey we gotta manage all this chaos right like my understanding is and i guess the bigger the organization the trickier it might get but you have a lot of people touching a lot of infrastructure yeah and if they're all touching it at the same time um that could be tricky right if you're if you're rebooting a router while i'm trying to change your routing policy there's a problem there that could yeah so you know my understanding is just to kind of uh create some type of order out of all the chaos and and i know on the back end too with clients um you know there's notifications right that might have to go out like you know people want x amount of uptime they might have slas and if you're touching the network all the time taking things down um you know there might be peak season right if you're in financial services and it's christmas or you know a very big spending time you might not want to take down financial systems at that time so i i know sometimes it's to protect the infrastructure you're like hey we don't have to upgrade all the code right now like let's just leave it alone let people consume our stuff so i think for the engineering side it's just to keep us all from tripping all over each other and for the business side it might be to try to manage maybe the expectations of client uptime and having to touch things to to keep the train moving right so that's kind of my high level understanding yeah i want to add a third aspect to that as well and that's the support side so if you're documenting your your changes in a system where your first level support the ones that are taking calls feeling the problems if they have somewhere that they can look and say hey oh these things are going on right now because let's say i i'm not going to throw out a bogus number but i got to think a decently high percentage of issues are caused by people doing stuff to the systems right so if if that first level can see what's happening in the environment right now who's doing what hey we're all of a sudden getting all these calls about this thing maybe that's related and we know where to focus our troubleshooting right away so that's the third point to add on to your stuff andy that's a really good point because i spent a couple years in a knock and yeah the first thing when you'd see the the board light up like oh god a lot of stuff is down you're trying to correlate a change and and especially at night like i worked at midnight shift for a while like okay is this is this real i mean sometimes it was just management somebody might be working on management prod is fine but they just broke management so you know everything's down well is it we don't know and you're trying to correlate changes and if you didn't have a change management process and people submitting changes to be able to track and find that stuff and correlate problems to people touching stuff you'd never know we'd all just be in the dark like well i don't know it all looks broken and i don't know who touched what so so being being in the knock and especially working overnight was that one of your first stops was to look through changes of the that were going on during the shift yeah for big stuff like okay when a lot of stuff went down at once you're like huh it's you know we did a lot of last mile stuff where i was so it's either a fiber cut like oh god you know the east coast went down yeah yeah you know did somebody just hit a big fiber um yeah or was it a change that that somebody had done so yeah absolutely on that particular shift yeah i wonder if like aws has change management you know like whenever they decide that aws and or dns and aws is going to mess up who made that change and and so i guess that's why it exists right um there's some other did we miss any of them any of the reasons why we think it might exist because i i know that i've been told by people who've been around longer than me there was a long time that you just did what you whatever you wanted to do whenever you wanted to do it middle of the day and it didn't really matter it was the wild west as they call you know you just you touch anything anywhere anytime and i guess enough people broke enough things and pissed off enough business units that i think maybe that's not the best way to do it you can get more stuff done right and that's the trade-off like you can be more agile is that the term everybody loves now like you know you can be more agile and get more done right but the you could create chaos too dude i i would have to do metrics play into this at all like like the amount of work people are getting done does that play into it at all the amount of changes you do accounts for how valuable you are as an employee i i don't know i think it depends on what what the job is but i i can tell you that that is being watched at least you know the the more changes i do i think to some extent the more productive i look if i'm on a team of 10 engineers and you know everybody's got 100 changes by this point in the year and i have 30 that says something right i'm not sure exactly what it says but it's yeah i think it's another barometer it's another finger on the pulse of like is this guy as productive as we need him to be and not all change is created equal right you could be doing some really big complicated stuff and you're not doing as many changes as opposed to the kid who's just upgrading code every night and doing a lot of changes but yeah so there's metrics well and so one of our patreons just brought up something really good we probably need to define what what is a change you know like how do you weight that change because because you brought up another point there that you know i'm struggling with at my place is uh you know we we have a and this could be another topic right but like an art you know an art uh architecture review team type thing or board or whatever you want to call it um i think different places call it different things but um they only want to run projects that are a certain amount of hours through this through this team right but what if the project isn't that many hours but it's a very impactful project uh should it not be ran through that and i think the same thing could be said about change management as well um how how big of a change you know what's the risk level of that change that kind of thing uh so i guess technically um what kind of changes are we talking about and this could be very vague right and it might depend on the organization i can tell you tonight when we get off i have a change just to push some firmware and code to some production routers that i'm going to upgrade next week now has anybody ever broken a router by pushing code i doubt it maybe but but is it because you said the p word is it is it any anything that you could do that could affect production and if you think about it is that what it changes i'm just trying to you know like right so chris was saying here in the chat let's define what a change is if you're going to touch production gear and you know if you touch production gear break it and you haven't created that change record you're probably going to be walked out the door it might depend on the place you're at but my experience in different companies is we don't need cowboys here we don't need heroes if you're going to touch production you let everybody know you're touching production so so let me ask this though because that's a record right it's perfect it's permission you're asking permission hey i'd like to touch this thing yeah is that okay with everybody it's perfect it's kind of once that's approved it's like documentation like this change was made then and then and it went through the boards that dan talked about it went through a peer review that some you know it kicks off all these processes right i have to get peer reviewed then i have to go to the engineering review board and everybody looks at it we talk about it there's usually commands i might have botched or syntax or something about validation i forgot to look at the more senior guys pick out so it's it all kicks off all that good you know kind of review but let me let me throw this little twist in there okay let's say from a developer's point of view if they're if they're coding you know they're developing their dev systems you know to push to production eventually right but they're working on dev systems well you know now the network i'm in we don't have a complete dev network and a complete separate prod network so let's say i'm on my firewall and i have to allow ports from their dev servers you know to talk through the firewall to talk you know what it to whatever the case may be i'm technically touching a a production firewall but i'm only touching rules that are going to be applied to dev servers so how you know let's go back to what you're saying you know if you touch anything in production do i need to open up a a change request for you know adding uh firewall rules for a dev system that's another good point there's a lot of gray area and a lot of things are open to interpretation like so all this stuff is unless somebody at your organization wrote that down like hey every time you touch this prod firewall that the whole company's moving through you gotta open a change if they don't define that well now you're sitting there and you gotta do something for deb and it's super important because of a project and you're like well i'm not sure if i need a change and you know it for for me i've broken things and my management has defended me and protected my job and i can tell you that if i didn't have a change they can't protect me right they have no ground to stand on so to your point dan i mean you could do it without a change and if you're in a culture that if you break prod and you didn't have a change they're okay with it because you guys have that understanding but the couple places that i've worked which is why i opened a change for almost everything i do even if i'm not sure if i need one like i can tell you that there's people that push code to routers without opening changes right and opening changes can be a pain and it takes cycles of your day and time and it's annoying so i could say well i'm too busy and you can never break anything and and then i step on that one weird rare bug that you know well the buffer was this and then you pushed it and it hit that boot flash and the thing reloaded and everything went down and you blinked your left eye right at the yeah you know right like we're all we're all one goofy bug away from something unexpected happening so i open changes for everything just out of self-preservation mostly because i need to give my manager ammo to protect me but like you said dan i mean you're in a you're in a smaller shop and maybe you can touch stuff without it i could push code without a change if something happens i'm i'm not in a good position right right so one of the patreons just brought up that you know they going back on your point there basically was they you know accidentally took down a data center by fat fingering and eigrp uh prefix ones and he said that the only thing that the change window is what covered his ass so uh you know that's a perfect example of what you were just talking about and now you're talking about the window right there's agreed upon times and days that you can break certain things so like right there's quarterly maintenance windows where you can break anything you want and that you know you could take down a data center for four hours and you're good because that's all been communicated to the business units and it's all written down like listen four times a year we we go crazy to fix the bigger more complicated stuff right um so that's another advantage right you're now given certain times and days that you can break stuff because sometimes you got to break stuff right you got to take things down and so yeah it's it's a whole thing i think one thing too is you you know you were talking about how many times a year that you're allowed to do like big changes like that well so like at our place we do our i'm just gonna call it our cab because that's what we call it uh we do it every single week right now some places some vendors that i've worked with they only get it once a month like they they only can get a window to do anything once a month like like if we're talking about cutting over a vpn tunnel or something like that bringing up a vpn tunnel whatever the case may be um and and that's frustrating right it's frustrating as an engineer that you can't you know knock something out you have to wait that long to to knock this thing out i get frustrated with just a single week yeah like i'm ready to do this tonight boys you know so now now that you say that dan let's talk about that this is going to be i know this is going to be insanely exciting but let's talk about types of changes so before i get going or any of you guys itil guys because i'm not so i don't know if any of you are going to completely blow out of the water anything i'm about to say but i i know what it is but i've never like followed it to a t or gotten a certification okay a certification that aj doesn't have write it down okay go get it and go get it aj i got this got one on him so i've i've learned that there are different types of changes right and i want to cover three of them you can have your what i've heard called as a normal change which i think is the one that we've been kind of talking about here the big one the one that's going to cause an outage the one that you get a window for right and then you can have one that's more of a standard change in a standard change is something that you have a protocol and procedure written for and it's it's just that it's a it's a template that you can basically just go and say hey i'm going to do this template at this time it's not going to cause an outage you can do it at any point in the day but you still click that yes i'm running this template i'm doing this thing at this time and it's still a documented change it's not gonna you don't need a window for it you don't need to take it to the change approval board like dan was talking about but you still got documentation for doing it just in case you hit that crazy bug that you know reboots the router or whatever you've got it and then you've got the uh the emergency change so to me that's something that's more like a normal change but it can't wait until that next change approval board meeting so that's why i kind of wanted to bring up the different kinds of changes because not not every change is going to cause an outage right but you still want to have documentation that you did it so you can have quote credit that you did something the first level support that could take any potential calls has that documentation that you did something so yeah i just want to call that out that there are different kinds of changes there and anybody who speaks itil can uh can come at me tell me what i got wrong that's a good point because tonight my change tonight is a standard change right we we have a template and for standard change for us it's we've done this a bunch of times without impact it's documented it's safe we know we're good and it goes through much less stringent review and we could do it any night of the week as opposed to like you're saying standard changes which a little more care has to go into it you know we can't do it all the time i i could tell you years ago so i've been managing data center connectivity for for a few years and the old guard we we had some reorg stuff happen and two companies merge but the old guard said that we can only touch data center connectivity on sunday so a couple years ago i worked 23 sundays because because the change management rules at the time where you can only touch data center manage you know data center connectivity on sundays the end so i couldn't do anything what's been so so here's the point i'm trying to make is a company's culture can shift even they can change their change management mindset right and changes that i used to only be able to do sunday and i think historically it was because enough stuff got broken and enough clients got upset with us that they said okay let's only touch things once a week and we'll go through and then they think the more process that you can put everybody through the more safe it'll be which isn't always necessarily true but what that does over time is it can make you less agile less able to keep your infrastructure current and moving forward and so it almost became stodgy to where now under this new uh you know philosophy things that we can only do sundays we can now do during the week as standards because guys we've done this hundreds of times we haven't broken anything why are you only doing it on sunday so it took good leadership to look at that and be like we need to get more stuff done we need to upgrade this infrastructure and we can't do it with the 23 sundays a year it's just you know untenable so that's been nice just for me a little side comment is when you have good management that allows you to do your job you know more frequently and gives you the freedom to do that like hey you say you know what you're doing you know let's you know let's get more done and we have which has been nice kind of like i think you've brought up a point a couple of times that i i just kind of want to like drive home here that a good change management program is backed by good culture right like i don't think if if you don't ingrain the change management into the company's culture it's not going to be successful i mean it kind of takes everybody to buy in like the importance of it why are we doing this and you know you brought up a couple of good points too where it's it's all about like customer satisfaction right like we have to make these changes to you know maintain the health of the network but if we don't do it in some coordinated fashion you know it's going to impact customer satisfaction and and you know just overall you know happiness with our products so um culture is huge with this kind of stuff dan and you had a point uh well so i was gonna say and i think it kind of goes along with your culture your culture theme there too but like so where you're at now andy do they let you kind of pick when you want to do your window like i mean not not maybe like not during the business hours right or i i don't know if you're 24 7 shop or not but is it like hey i want to do this change on tuesday night or i want to do this change on wednesday night so you got to kind of pick that yeah so so back to tim's point it's all been well established documented discussed and agreed upon so if it's a standard change and and we have a list right we have like a matrix of like here's what a standard change is you can do these things one of which being push code to a router right that falls under standard change i can do that any night of the week during our window which might be from yada yada you know whatever that is um but then bigger stuff like like tim alluded to earlier um you know if you know you're going to cause an outage that that you know that's a different conversation and more reviews and deeper dive and you might but i but it it's been very liberating see it it's a two-edged sword it's a double-edged sword right like i used to work so many sundays that that really stunk but now i'm working many more nights during the week so yeah we're getting more done which is great it's because you're agile andy well you're so agile right but i was working one night a week and now i might be working two or three nights a week so it's i'm glad that we're getting more done because we are and i'm glad to have that freedom to be able to do that but it's not all happy fun times i guess because now i have to work more nights which isn't necessarily so who really won well you know it's but i i can tell like historically my relationship with change management years ago used to feel kind of uh not all warm and fuzzy right like like for me the people sitting i used to call them bean counters all right now we're getting honest talk right like these these are people who aren't technical they can't program you know the remote on their vcr now i'm really dating myself but they you know they can't they can't program their cable remote right here we go and but they're sitting there with the keys to the kingdom telling someone who's dedicated their life to engineering what they can and can't do and when they can do it when they don't understand any of this stuff and it's usually based on nonsense like well you forgot to put you know 15 words in the description field you only had 13 so to me that's when it starts to get like you know we're all busy we're all under timelines we're trying to be agile we're trying to move and these people who don't or who aren't technical are the ones telling technical people that you didn't fill out the fields right so to me that's when it gets like you know really got but again management the culture they all got together i think in a room and talk like listen this is the direction we're going in we need to modernize and we need we we need to do a lot of work to modernize and you guys can't keep telling these people that because they didn't dot every eye and cross every t so it's it's been an evolution i guess we're still getting there but you occasionally get somebody like you know nope you're not doing that because you you know you didn't you didn't put an e somewhere like i i don't know because there's so many fields you guys use service now like it's it's like a yeah there is a lot and you're you're it's administrative right it's all the administrative stuff like yeah you have to figure out all the engineering but then there's all this administrative stuff that you have to wrestle with just to get permission in the window and that's to me the frustration i guess you're playing right into a question from a deal here in the chat so he's asking how do you define your implementation steps so i'm going to take that a step further in and you're saying you're using servicenow do you put in a field everything that you're going to do or do you feel like you need to do that and if you do do you just attach like a document to the form how i just have a script it's a notepad okay and you know here's what here's what i'm doing here's my pre-validation steps and what i expect to see here's my change here's my post validation steps here's my back out and here's my backup validation so to me you can read it and go here's what you're touching here's what you intend to do here's what you do what's the what's the result yep you know so again to your point if i'm sleeping and somebody gets called the next day they see everything that my thought process what i was going to do what i saw and what about like if you're what about if you're actually doing like changes like on a router do you put your actual changes that you're that you're planning on putting into the router do you put that into the um your your notepad or whatever you're you're using to log that ticket the commands are going to drop in the router yes yeah they're that's what my script is it's mostly just all commands of you know yeah okay so and then the servicenow stuff is really just the templatized stuff so that's the change number the device you're touching here's a description you have to put your ci's what device names there are the dates the times all those little like the bean counter stuff i call right like all these little boxes that you have to fill out and god forbid you miss a box because it's a whole damn thing and if you miss a box five minutes before the cab well now you can't go to the cab and then you miss that date and then the project manager is like well geez guys we're behind well sorry i was fighting a field in servicenow for you know three hours today and he wasn't lying it's become real you know but but that's that's that's real talk right i mean honestly i'm glad change management exists and because there's been a lot of times i got a change teed up and i go to submit it in our system and i'll get a notification saying hey there's a conflicting change which i didn't know somebody else is working in a device that i am at the same time so it's good because then it tells us hey you guys get together and talk and see if your changes can go exist sometimes they can sometimes they can't but like oh hell aj's rebooting the router with the code upgrade all right you know and that code upgrades getting us off a bad bug that keeps causing an outage so i'll back off i'll reschedule you so it's it's there's a lot of benefits to to all this but when you're you know when you're in the trenches doing the job and people are leaning on you and you you know you're just getting pushback from from people who aren't technical to me that that's what bothers me but but they have a job too right and i'm glad they they're there to help me so a follow-up question you know uh adil is asking is like do you get grief from them like maybe if you don't include the code that you're wanting to put into the router like your your commands you're gonna drop in if you don't include that do you get grief for that or do you get grief for putting too much information in there which i don't know how anybody that would i think that all goes down to culture really yeah okay well the people are proving the changes in the system aren't looking at your scripts because okay they're just they can't figure out how to turn the volume up on their tv well right that's you know that's what i'm saying so like nobody from your company is listening to them but listen like so so in my mind the perfect scenario would be network engineers approving changes now that does happen with our reviews right we have we have twice a week we go over all these and we talk about them but the the fact that there's people sitting looking at the system and giving grief over and the rules change too right something that you've been putting in a you know the description field has to be very specific right like people ha it can't be too technical it can't be too vague so they tell you what to do and you do it for years then one day they change the rules they don't tell anybody and now everybody stuff's denied because they've now it has to be 18 words and not 15. but again because you're under the gun and you're in the grind and you're trying to get stuff done now the everything stops because somebody non-technical decided something i'm sure they have good reasons yeah you know and i can take a step back and take it deeper i think okay there's probably a good reason for that but i'm trying to get stuff done so i have this image in my mind right now of andy filling out a servicenow form and he goes to hit submit and it fires back at him because he didn't fill out a required form and he's just sitting there typing fu bean counter and then but i'm just trying to be real honest and real transparent about you know how i feel sitting at the computer isn't how i'm reacting and talking to people like you know what i mean i can feel that way and go god damn it but then i take a deep breath and realize this isn't that big of a deal and then you say okay you know what what is exactly you needed here so that i can get this done because i have five minutes until we miss this you know this window that i that i have to hit so how it feels and how i react is different i'm not this lunatic who's yelling at people just because they're doing their job but try no just just dan yeah but trying to communicate to you guys you know what you're dealing with as an engineer how it feels and honestly if there weren't deadlines none of this would be stressful right right so for you for you especially andy and dan um i want to get into aj's experience here in a little bit but for you andy and dan is this a real meeting or are people just looking at these forms and they look at these forms every tuesday at whatever time and then they get back to you or are you actually in a meeting with people either in person or on the phone presenting these changes and explaining what you're doing and people are actually listening live and then telling you their feedback so let me let me take this one real quick um so at this point so our change management is actually fairly young uh it only came in about a year or two ago um before that it was 100 percent the wild west right full send yeah it was full sin whenever you want to sign up yeah and uh so they started that out and it was where we all went to a meeting if you had a change to do you you went to this meeting and this meeting was it i swear it was like two hours long of everybody talking about what they wanted to change who it was going to affect that kind of thing that now this was this was already documented right because we had to send in a request it's it's all done electronically right it's just a request with the different fields it's not service now but i'm sure they're somewhat similar right um but you have that scent and this the cab which were management it wasn't anyone technical on the team it was all management and um they would go over that but they had us technical people in there talking about what the change was who was going to affect you know what kind of effect would it be would it be did we expect downtime did we not that kind of thing um and then after that went on for a few months they were like all right these meetings are taking way too long and it turned into basically all the technical people were not in there and it was just management deciding you know hey this person needs to do a change at this time and there's nobody else that is doing a change at that time so they can do that change at that time and and just trusting us on you know whatever we put in there basically um so it's it's nowhere near as strict as like what andy's been talking about but it is good for kind of like what everybody's been saying about like documentation if something's screwed up there's so one of the steps in our in our change request one of the steps is um a robot a roll back plan so we have to have how you know how we gonna back this out basically if uh if it you know doesn't come up or something breaks or we we go past like if you have like an hour window or something like that they'll give you like you know five to five to like 20 minutes of trying to figure out what the problem is but then after that like you gotta roll back basically uh so so definitely uh yeah same that's right that's kind of my respect it's critical yeah and just while we're talking about change i think the validation your post change validation is the most important part of any change i know that's not what we're talking about really here but you better you better have an expectation of what you're going to see and then make sure that's what you see and if you don't figure it out and or back out because when i first started years ago i just had a job to do it wasn't exactly sure what i was doing and just doing changes and you know i don't know i guess they'll call tomorrow if something and then as time went on you know i mean you're new and you don't know right but then as time went on i was kind of taught like listen man you know you really need to understand what you're doing here and what the intended state is afterward because because that's critical going to bed not knowing if you broke something is really stressful and i did that for my first year or two of my career like well i don't know i guess we'll see it's my first time creating a new tunnel see how that goes you know so i don't know validation is everything gotcha so so what about your experience andy i just went on for change management for a half an hour specifically about what i want to get off of you before i get do you ever uh do can you ever talk your your manager supervisor into talking to your changes for you or do you have to be the one that does it um i present all my changes on our engineering review board to our team of engineers um and so but that's an internal a more i.t internal thing that's not a actual change management board that's like a peer review thing right right and they would be more for standard changes for the bigger changes yeah we'll we'll do our internal review and then you might have to go to the cab which are managers talking to managers so i you know i review it on my engineering review board that my manager is on so now he knows what i'm doing and i describe it then there's a different call he'd have to go to to talk to ictos and managers and directors like hey this is what we're doing and then all those guys can say okay well you know everybody's this is what everybody's touching in this window is there anything that's a flag like maybe we don't let andy do that this night because this guy's touching this stuff over here you know yeah let's not play with the load balancers and the win at the same time you know what whatever it might be so uh yeah it depends on that severity tim i guess like you're talking about how big of a blast radius how likely it is that you know are you going to bring something down then there's a lot more conversations a lot more calls and it goes much higher up the ladder yeah at some point it's got a it's got to be bigger than than just it right because it's going to affect the business so at some point you you do need to handle that notification process and make sure that people understand what's going on well then there's client notification right like you're talking about if you're going to impact something right now we have slas where we have to uh tell certain clients you know sometimes you have to do that or just no there's we have people for that and is there is that part of the is that part of the change management process is there like a flag that says oh by the way you're doing this and touching this so you need to uh notify these people yeah or is that up to management to figure that out it's it's yeah it's not in my wheelhouse which i'm grateful for but i've had project managers for other projects i've been on like i'll have that conversation with them or like okay well let me go get with the the ictos which i think i guess like the bu reps like you know let me go talk to them and tell them oh okay some of them you might have 30 day notification i mean there's there's huge clients that you can only touch their connectivity once or twice a year so you can go to them all you want but they're going to say no you are not touching any of this stuff until you know next year the end and there is no discussion about it but yeah it's you're right then you got to talk to clients right like hey you know we're going to take some stuff down and we have soas or contracts or whatever that says we have to tell you 30 days in advance and and that can be a whole thing because you give them 30 days you know if you have a change to do and then you got to wait a month to do it and then if you have a lot of changes to do and you have to wait so yeah it's and it seems like the bigger the organization and the more it you can really get bogged down in the administrative kind of stuff right it can grind you to a halt and in my old org it did we yeah touch things as least amount as possible and it showed the infrastructure was held together by duct tape and a prayer you know what i mean so that's not the way to run you know tech is that why it takes isps like 90 days to do anything cab meetings tim you're in a highly regulated vertical i mean how does change management look like for you i'm assuming you can't do what you want when you want no that's not ideal yeah um i i i've talked about it a couple times and i harp on it on many episodes that i think culture's a big deal and and that's one thing that i think we do really well uh yeah for the the what i call normal changes that isn't something that you do all the time and is probably going to cause an outage to a uh a place that is 24x7 then yeah you got to present your changes i kind of um my management would take those if i wanted them to so i didn't have to sit in on the meeting but a lot of times i like to just present them that way if there are deeply technical questions hopefully i can answer them quickly that kind of thing um but yeah i think it's back to culture whether you have to have that line by line thing and if you deviate from that line by line thing and somebody finds out about it you could be in big trouble it's it's all back to culture and it's really you as an engineer you need to feel out that culture and and figure out what kind of environment you're in and just just play to that and if you do you'll you'll be a rock star and dot all the t's and cross the eyes or wait yeah you know what i mean you just you just sparked my memory too in in the old culture i worked in you had to follow this the script line by line letter the law don't deviate at all and if anything goes wrong back at immediately go back and and figure it all out where um the newer cultures fail forward i've heard it called like okay fail often fail fast yeah well just get out forward like don't don't if 90 of the change was successful and you had a problem at the end don't just back all of it out oh i see what you're saying okay leave the successful parts of what you touched in if you can fix what didn't work in the window great if you can't you don't have to back out take everything out and start from scratch increment you know make progress incrementally where in my old culture it was you know do not be hero if it doesn't work back out we'll do it over again and that really slowed down progress because anything that didn't go as planned you could have a 400 line you know you could have pages and pages of code that you're putting in to do different changes if any of it didn't work it was just a wasted effort where this new culture which is great is like now let's let's get stuff done let's fix what we can and the stuff that didn't work we'll come back to you know so and i'll bring it up again i'm i'm a big i'm a big metrics guy like i i don't mind putting in tasks changes whatever because to me at the end of the day that that shows from a statistical perspective that you are doing things and you can prove that you've done things if for whatever reason you get to the end of the year and the the company wants to downsize a right size or whatever you've got that searchable documentation that you did however much you did throughout the year uh well and it also shows you a success rate versus a fail yeah that's a good point yeah how many how many times so maybe i don't want to document it incidents caused by change i know that's a very big metric that's tracked yeah a good point how successful are we in changes how often are we breaking things so one of the uh patreons have has a pretty good question he he's and this is this is to you andy since you're at a pretty large company i didn't want to be the change management guy here if you guys get me fired for this you've been you've been the rock star tonight not trying to be i just deal with change management a lot uh he basically he was you were talking about your monitored metrics right and so he's wanting to know how does that change become your responsibility and like do you do you have to find and fix or does someone say hey here's a problem uh andy fix it like how does that how does that kind of become your your responsibility to fix that uh you know if i find something in my travels that i want to fix like oh this isn't right yeah let's pick on ntp like if i'm if i'm doing something i have checks that i do in every device i'm in and i might look and be like oh ntp isn't working it's configure right but somebody changed something now i can't reach that server you know that's mine i'll just spin up something and fix it but then we also have an intake process where because you know what we manage is the whole company's using right so somebody might come this and say hey we need connectivity from here like you mentioned dev like hey dev has to get to something so we have an intake process and then my boss or somebody on our team will assign it to different engineers that give it one andy give that one and so then i have a queue that i'm working through that does that does that yeah i think i think that answers that i would say probably 90 of my changes well it depends on what time of the year it is too because uh 90 of my changes are people requesting me to do something like they need access to something or they need you know just whatever uh it's someone requesting me to do something um and then the 10 percent is like hey i need to upgrade this you know or like hey maintenance type stuff right yeah or or like a project right where it's like hey i need to upgrade our core switches or something like yep and and then that turns into something different right because that's a big that's a big change right because you're going from this set of boxes to this set of boxes so you're moving that traffic over so i don't know it um but most of my changes are because someone requested something so i hope that answers your question there chris um yeah i would agree with that i mean people are asking us to do stuff right yeah yeah i'd be fine sitting there studying for a cert instead but now somebody's bothering me saying they need something and then like all right i guess so yeah i would say most of it's inbound um you know for sure uh now something yeah go ahead tim i was just going to say i kind of want to shift this over to aj because aj you're a deployment engineer with a var so you're in other people's networks all the time how do you how do you handle that when you're doing projects do you lean on the the customer to handle that change management process or are you asked to handle that is it a combination uh it's it's definitely a combination and depends on the customer so i i've seen a wide i don't know array of how change is managed at various organizations um you know i i've certainly done a lot of what andy talked about right like i have to propose my changes exactly command by command what are the verification commands what do i expect to see what's my rollback plan should this you know should i need to roll back and then how do i verify i roll back successfully kind of thing and so i i will you know create a document of my own and then i submit that to the customer and then they initiate the change management process it's not like i log into their servicenow system and start that off right um there's other organizations that are a lot more i don't know simplistic about it like oh you know we're gonna just schedule a maintenance window and here's a written description of what's going to take place that night now for my own sake i still create that detailed document that andy discussed earlier that and that's just something that i do personally every time i do something on a customer's network i i need that kind of like validation before i go just you know making changes to somebody else's network and it really doesn't matter what it is right like i don't want to overlook any detail even if it's the simplest change like i still do that process just as as a habit um then there's there's definitely other customers on the on the way other end of the spectrum where you know we got to make this change you know what what do you want to do and he's just like well it's lunch time let's do it the full sim customer that's me that's me it used to be uh so so yeah it's it is interesting because i i'm almost to a point where like i can anticipate like once i start working with the customer and like okay i know what i'm dealing with here kind of thing and then then they surprised me and they're just you know let's change it or no no we can't change it right now we gotta we gotta put it through the whole system so i was gonna do an ios upgrade to a 6500 uh vss pair and the request to do that got kicked two months like and this it was like scheduled it oh no wait no we can't do it and then rescheduled for like a couple weeks later oh no wait no can't do it and it was like this project should have been done and over within a couple of weeks kind of thing and it ended up dragging out for like two and a half months because the change window kept getting moved because other more pressing changes came up that knocked the ios upgrade off the table you know the switch had been running for years without being rebooted or upgraded and you know i don't know if it was actually more important changes came up where people were just gun shy about upgrading the ios and the device and that sounds familiar in in my old org that i was in same kind of that we'd get kicked all the time because other stuff was more important and once again over time your infrastructure becomes less and less stable you're not off that buggy code you're still on 6500 so when you should be on 9ks like it's yeah you know that's if people keep telling you you can't touch anything right you just keep getting pushed out and then that can be a real problem and then when you know the building burns down you're like well what the hell guys you haven't let me do anything in you know six months what did you expect well then at some point you become afraid to touch something because you're now five revisions behind on code and you gotta make a jump and maybe now you gotta make incremental jumps because you haven't touched it in so long and now it just becomes it becomes scary well and i think so one thing that sometimes the business side or even even it management doesn't understand is when you let something like that happen you're you're increasing your risk on that sorry i think they're reducing the risk and this is the big thing that you're pointing out which i love is they think that if they slow the train down and we touch things less and we create more processes and make things take longer that they're increasing the stability of the network and to your point dan you're doing just the opposite yeah you really are because because then then exactly what tim was saying now it's now it's like your five revisions i don't want to touch that i don't want to upgrade that this thing hasn't been rebooted in 10 years i'm not touching it no it's it's december and my success rate this year has been really good i don't want to end on a bad note and dan you had said this in a different episode which i think is relevant here is like i know you had said that you were you've been working on getting your network to a point where it's stable enough that you're not afraid to touch it all the time yes but again hearkening back to my old org we had been put off for so long as a red-headed stepchilds who weren't allowed to do anything and you you were terrified to touch the network because it seemed like every other time you touched it you found a landmine and all hell broke loose because it had just been left to rot so long so yeah yeah you can create that no problem and make the infrastructure just terrifying to touch right yeah yeah well in in sully when i first started remember we only had a single core switch and everything was on that thing so when you made an upgrade to that that's terrifying right because everything's sitting on that one device you know it's yeah it was it was very scary and once we got more redundant it was like okay now now we've got we've got fallbacks right like i don't want to trigger it but if we do we've got something there you know extra stuff there it's a strange philosophical balance right because the more you touch a network statistically the the better it should be right like you're you're doing upgrades like but in the same token the more you touch a network the more chance you have of breaking something so i can see where the change management folks in management it's kind of hard to there's got to be a balance i guess somewhere but if everybody's touching everything all the time it's probably chaos yeah then if you don't let people do their job and keep the infrastructure going and updated and moving in the right direction you know you're also creating that same problem so it's it's a weird kind of balance there i think yeah right i got a quote uh i got a quote smiling chris here in the chat he says the memory leaks have now become load-bearing memory leaks i like it so and one of the questions too andy and i'm kind of curious about this as well but uh and this is directed towards you when you were working at it at an isp uh did you ever have pushbacks from any of your like clients or your customers or anything like that like like how would that work if you guys had to push out upgrades because i know every once in a while we get emails from our isps that are saying hey we have we have maintenance windows at such and such date it's usually like you know somewhere around midnight or two in the morning or something like that but you know as a customer andy's old isp you know i can tell you they've never asked my opinion on when that when uh that is true they've never asked us at our opinion so here's the here's the problem dan and even in my new role i'm basically an isp now we build an mpls backbone and the whole company is going to consume it we have to get all traffic onto it so i'm in the same kind of position again and i mean we'll notify people but we're we're you know we gotta we gotta keep this train moving i mean if you don't because we've learned from our mistakes if you don't let us get off of this code that causes this router to intermittently reboot for no damn reason at all yeah so we're going to do what we have to do we're not going to let the integrity of our backbone or at the old place the isp like we got to keep you're not the only client riding across this like you know so we can't have one client tell us that our whole structure can't be touched yeah i hold you guys back basically but i guess for the relationship too i mean if if i'm upgrading code at a remote site for them that rather we manage and they say god can you please not do it on you know this day it's our peak day you know sure yeah so i you know so it depends is what you're kind of getting at like it depends if it's a device that you guys manage for a customer may you have some more give there but it sounds more like the scope right like if you're talking about upgrading your backbone routers where all of the traffic for the entire network goes through like it's more of a courtesy like right hey we're doing some maintenance that's going to affect everybody versus you know the the site router the loan site router that that eventually has to be upgraded to to meet the the code standards or whatever we you know i i don't think you're going to stop a backbone upgrade because one customer says no don't do it you know and and i think i think soft skills really come into it when you're you know you have something to get done right so i can tell you that there was a time where we ran into this memory leak that would just bring the router to its knees it couldn't bring new routes in you know and it would eventually the router leak would get so bad what was the other thing that would happen i think the whole control plane would come down like it was this thing that the longer you left it there the worse it was so we're like we got to get off this kit we got to we got to upgrade the whole platform yesterday like we have to do this and you know you keep but i think the way you communicate to your be used clients whatever is critical because they're gonna probably push back so the way it's framed um they're not gonna stop us but i also think it's an opportunity to now it sounds fufu but you know not say foster the relationship i mean i never want to be arguing with a business unit a client a user i mean i want these people to be happy with us and i don't want to piss them off by keeping the network stable now well i'm upgrading this code i don't care what you say because i manage this and you can go to hell like you can't say that even though you want to but i think there's a way to speak to people and frame it that you can get done what you need to get done and almost let them feel like they made the decision if that makes sense like yeah i got you i don't know if i'm making any sense but is that manipulation well it's that win-win thing right i mean i can't i can't leave this gear in that state like this is dangerous for everybody we have to get off of this clients don't want their touch stuff ever they want to be up all the time so that's a tricky conversation to have but i think that's where soft skills come in and how you position it like and i think that's also depending on the environment too right because like if you have people who are there at eight o'clock in the morning and then they all go home at five o'clock in the afternoon and nobody's there touching anything you know during the you know past five o'clock until eight o'clock the next morning they might be more open to you making a lot of changes at night you know versus someone who's you know open like uh like a hospital right you know they're running 24 7. um and that's why we're working at night right like right that's that's why we're up at night and that's why you probably have redundant hardware and redundant circuits and physical diversity and i mean if you've designed a network that you can't touch one side you know if you can't touch your a-side device and and move traffic over to the b-side device you're doing it wrong in my opinion at least on the data center space like yeah dear god if you can't meet if you can't maintain your your infrastructure what are you doing you know yeah yeah data center yes but there's not a there's not a whole lot of a side b side when you get to the access layer yeah i think a good network design plays a huge role in your ability to do maintenance plans and when you design for for ha and reliability not only is your maintenance window for you know maintenance purposes but now you can also test your failover and redundancy you know is it working as design kind of thing like you should be able to fail over traffic to your b-side router and upgrade your a-side router and your customer or you know whatever whether it's your actual business customer or just an internal customer they shouldn't be able to know right like if you've built it properly yeah it all comes back to that design right because i have replaced an entire access layer and for the single home clients well tough toodles you should have right two connections right but if you have if you're dual homed with us i'm gonna replace your a side and your traffic will reverse the b side but i think what tim's talking about is the access layer to like yeah sorry the actual pc sitting on a desk the phone's sitting on a desk yeah outside of the data center so the devices that don't have two nicks yeah i know he's not andy's problem now i got to worry about the pcs tim jesus got enough on my plate right andy right after you guys get ipv6 rolled out you're working on pcs after that oh my god i'm gonna be doing desktop next we're only into next tuesday with you here andy yeah yeah all right guys this has been a fun conversation any uh any way we want to put a bow on on change management the this sounds like the necessary evil i was about to say that it's a necessary evil yeah i it the the bureaucracy of it is is very um you know just overwhelming sometimes like i i it because it can take because you think about it like you know you got eight hours in a day well sometimes filling out a cr can take me an hour i mean just being honest because you got to come up with the plan uh you got to you know you're how you're going to implement this how you're going to plan on rolling back if you have to uh and then and then you have to sit there and fill out all the freaking you know fields in the in the request make sure oh you got to think about who everybody this is like who um sorry you got to think about who all this is going to affect what systems this is gonna affect stuff like that i mean you gotta there's a lot of thought process that goes into this right and and so filling that out can just be overwhelming to get that that cr in there and uh but then on the flip side all the benefits that we talked about previously like you now you have a log of that change so if if you got hit by a bus and the next engineer that comes in and fills your seat you know they can look through that and see uh oh okay they were making this change and this is what this is the date that they did that you know that kind of it gives you some time stamps that kind of thing but it also uh will help you know yourself in the long run because maybe you're there for a year or two or maybe more than that and you're like what did i do to do this you know and then you can go back and and search that right yeah so it's definitely it's got benefits to it and i'm on board with it but it is a pain uh so that's why i say a necessary evil yeah i'd i'd echo that you know i'm i'm grateful that change management exists it it helps helps the organization that that i'm that i'm at succeed right and keep moving in the right direction and make sure we don't step on each other and you know the more people kind of helping i'm all four um you know i kind of say half tongue-in-cheek like they can't you know program their tv remote so what are they doing here but i you know honestly i'm grateful that they're there and they help us and the biggest thing from the engineering chair is you know don't be a hero don't be a cowboy open a change what i assume every time i touch infrastructure i'm going to trip on a bug and it's going to break something so if it takes me a half an hour to open a change and it protects my job you know if maybe if i didn't want to be where i'm at i'd be like well whatever it's just going to get out of here but if if you like where you're at you want to stick around a little bit um you know open a change it protects you and it allows your manager to go up the chain and say this guy followed all the rules and you know because a good culture they understand things happen and they understand things break but if you're not following the process and protecting yourself and the company you know you're a cowboy and i don't know too many big companies anymore that have time for that crap you're gonna be floating around for a while because nobody wants a cowboy you don't want to piss off your clients right no you broke something you didn't tell anybody why i should have learned to rope and run i don't know this is a good conversation aj do you remember what i said when you presented this topic i said talk about root canals yeah but i'm glad we had this this went much better than i expected so thank you you got to have faith about you tim trust daddy aj that's right i i think my bow on this thing is going to be an echo of you guys and it does go back to the culture so it's i think you need to embrace change management don't be afraid of it use it so you're not afraid of your shadow and know that it really can be a culture thing not every organization is going to implement it the same way so if you're going between jobs between organizations don't just think it's going to be the same way you did it before and you really need to find that out work through your management figure out what the culture is so you can shine early and not and not trip over yourself yeah great point you could be going from you know a place like andy to you know a place like i've worked at where change management what what change management it's lunchtime let's roll so it's my last thought aj kindness doesn't cost anything i've been cranky with change folks and i don't think they're very motivated to help me this was the old andy before i got all better and now i'm a great guy but yeah but you know kindness doesn't cost you anything even if people are getting in your way so to speak being kind and asking them you know okay what do i have to do like what you can be kind to the people putting out roblox and they're more apt to be kind back to you as opposed to you know this jerk again who's you know yelling at me because i slowed down has changed they're not gonna i wouldn't want to help somebody if they're giving me a hard time right so you never know who your next boss is gonna be that's right yeah yeah so kindness doesn't cost anything be be kind to people and they'll they'll probably help you anyway well i i think that's a really good point andy because what what you see as a roadblock is like probably the most required thing for that other person's job as much as you're trying to do your job they're trying to do their job everybody's just trying to get get their job done and they're protecting the business yeah yeah i'm the guy who can break stuff and they're protecting the business so you know don't get it's easy to get those horse blinders on and i'm just yeah it's all perspective yeah i'm stressed and i'm under pressure in 10 projects and i got to go go go and then somebody gets in my way and it just can be jarring but you know they're trying to protect the business so be kind to them and they'll they'll get you there all right i don't think i could have said it any better myself i think we're going to put a bow on it and i think that this approves our change window for episode 55 so nice nice work gentlemen uh special thank you to the patreons for joining this evening you guys definitely added a little something to this episode again if you want to join us every thursday night you can join our patreon program go to patreon.com forward slash art of netenge and we'll see you next week thank you so much for joining us have a great time guys see you later you broke it you bought it hey everyone this is aj if you like what you heard today then make sure you subscribe to our podcast and your favorite podcatcher smash that bell icon to get notified of all of our future episodes also follow us on twitter and instagram we are at art of net edge that's art of n-e-t-e-n-g you can also find us on the web at art of network engineering dot com where we post all of our show notes you can read blog articles from the co-hosts and guests and also a lot more news and info from the networking world thanks for listening you