Demystifying The Role of the Network Engineer with Ethan Banks – ZNDP 070

ZNDP 070: Demystifying The Role of The Network Engineer with Ethan Banks

Zig Zsiga: Demystifying the role of the Network Engineer with Ethan Banks Episode 70. Welcome back my Friends, Nerds, Geeks and Ziglets out there we have another episode of the Zigbits Network Design Podcast where Zigabytes are faster than gigabytes. As always, we strive to provide real-world context around technology.

Zig: Welcome back friends, Zig here your host is always and I have an interesting show for you today. I have my good friend Ethan Banks. Actually Side Story he's actually one of the main reasons why I started this podcast three and a half years ago, or so. Just to give that little call out that Ethan is the man that made me do this. Totally Off Script is always but enough of that right I just Ethan thanks for joining me today. I really appreciate it, how are you doing?

Ethan Banks: I'm doing all right man. The internet dropped off for a second there but I think you asked me how I'm doing and I am doing okay but I do have a question for you. You said in the intro Ziglets, if I want to be a Ziglet do I have to get a tattoo?

Zig: Yes! Yes, you have to get the actual icon tattooed on your arm, on your bicep!

No No no you don't. No you do not it's just you know a brand right, just making up a brand and making it stick and trying to make it an honorable icon as much as possible you know?

Ethan: Fair enough buddy fair enough.

Zig: Hopefully the internet stays good today you know the interwebs and we don't have any outages. I appreciate you coming on the show and I'm glad you're doing well. You know we're getting around the holidays here and the US, we have Thanksgiving this week and I know this is going to go out a little bit maybe in December but we got an interesting show right here to talk about what a network engineer is?

Ethan: I have my opinions about what a network engineer is and isn’t, and as I've worked in a bunch of different roles that I worked as kind of I guess you kinda like an entry-level admin or like an Ops kind of person you know help desk stuff I've worked as an engineer which I think is somewhere in the middle and I've also worked as a designer or architect and I know you recently did a podcast on the difference between design and architecture, I don't know if we will get to have that conversation too but yeah I have thoughts on what engineer's are and aren't and hopefully we do some demystifying.

Zig: Yeah I think I think enough past podcast episode with my friend Knox Hutchinson we talked about the network engineer role is just getting more mystified these days and it was like five years ago with all the different advance of like software-defined networking and devops and all these other things other you know technology and capabilities but we kind of jumped in because I'm bad at a host I'm a bad host right.

Zig: Why don't you tell everyone who you are I'm sure everyone knows who you are but why don't you just quickly do an intro, who you are where you live. Not where you live physically but where you live on the internet and what you do.

Ethan: Am I supposed to dox myself now?

Zig: Yes

Ethan: Zig 10 no more than that 13 years ago I started a Blog called more that ended up being called CCIE Candidate I just blogged through my studies on my way to becoming CCIE and that turned into a podcast in 2010 that I started with Greg Ferror and Dan Hughes another guy who took a job at Amazon. Dan was moved on as a host and then it was just Greg and I and so Packetpushers.net you will find that 10 years later from 2010 to 2020 we're still podcasting we've got a whole Podcast Network now that we're doing.

Ethan: Heavy Networking is are Prime show where we do a lot of discussions of what's going on in the industry and so on I right there and we have a Packetpusher’s Newsletter and blah blah. Zig all that kind of stuff you know go to if you really want to know more go to EthanCBanks.com and there's an about page and you can find the book (Computer Network Problems and Solutions I've written with Russ White and courses and all of that.

Zig: So so I did that intentionally right I wanted to make sure if anyone that's listening doesn't know who you are they know who you are Ethan is a rock star he's an icon in the industry and he's really been a good Mentor for me over the years so enough about all that let's get in you know let's start out what what what do you think my friend is a network engineer in your own kind of words?

Ethan: I think the role of a network engineer is primarily that of a builder and so I think about it this way there is a business whose got a problem that can be solved by technology and in my case as a network engineer I would be focused on the networking part of that technology let's say and part of a larger team that's doing that. So an architect is probably going to think about from a business perspective what is needed. Match technology to that solution, draft up some kind of a plan, maybe do some lab work and so on and then the engineer's job is to implement that design and work out the Kinks in the bugs, tweak it so that it works well and is stable and then keeps it running. Usually does the second level of support if things go badly And that's it, it's a builder as an engineer I spent most of my time building Networks.

Zig: So that's the fun stuff that I feel like building a network and like implementing the Technologies now you may not be necessary doing the designing and all the network engineer roles but I feel like building the network itself is the fun part. What do you think?

Ethan: I think it's the fun part that is the stuff that I have always loved doing because there's Magic from me in building out a configuration and watching that Network come to life. Now what's weird for me is I don't know if this has been your experience too but a lot of times I've supported smaller shops they didn't have a separate architecture design group so my job was engineer but also the one having to do the designer in fact I've been in a lot of a lot of interviews where I was asked in this, applying for a job and they had asked me oh you more of a designer an engineer it's like both you know we kind of have a conversation that way so that's. More the reality of it to me I guess only at a very few of the shops that I've worked at has there been a sharp line between you guys do architecture and you guys do engineering and that's what you do you don't cross over very much.

Zig: That it's like split like like I think in my experience a lot of verticals differ depending on your vertical in the size of where you work, you're everything you're an engineer you're the admin you're the designer the architect like you said like you're really just kind of doing it all. Sometimes you're the single person for everything not just networking right. You're doing the system side of things like you know, servers and web page and whatnot you know and then then you're not even just doing networking anymore right?

Ethan: Right so there's that too so then those those those roles that I've had in the much smaller organizations where it's like okay it's me and one other guy and our boss and the three of us kind of do everything and even our boss is like you know thumping out DNS Zone files and whatever it might be so yeah there's those kind of roles.

But again going back to the demystifying the network engineer part of this conversation it's like to me the engineer is the Builder that that is how I think of it.

Zig: Yes you're going to have some sort of architecture or design whatever we're not going to get that conversation right whatever that is and then that Engineers going to get that it's almost like a blueprint let's say

and they're going to go and take that diagram and go and you know the configuration ideas and go configure it and build it from scratch. Now all the command line stuff for this day and age it's like you know it's GUI right build out the controllers and hit the buttons.

Ethan: Well and then fix the stuff that the designers didn't think of or that wasn't quite right or that needed a certain tweaked so there's a role I think also in

not merely building according to the blueprint but when the blueprint turns out to be missing some important parts giving feedback to the person to create the blueprint go you know what we ran into this problem and I think the way to solve it is this what do you guys think we get a revision?

Yeah there's this is a communication aspect to it that I think is very important as well

Zig: Bi-directional communication aspect of it. So I say that and tongue-in-cheek because a lot of my times you know designers don't feel like they do anything wrong or are like I designed this solution it is a hundred percent accurate here you go engineer go do it and then engineer comes back says you got five things wrong like.

Ethan: Dude that's an ego thing though right so in the roles I've had that have been more architecture oriented where I was the one building design and handing it down

when someone on that Engineering Group would Implement that design and kick it back to me and go alright so we implemented it

it was good like eighty percent of the time but then we ran into this one thing,

we're if we do this what do you think you know and then it was collaborative unless your ego gets in the way and goes nah man.

[8:58] Are you trying to say I made a mistake as I heard I heard you say I made a mistake but I don't think that's what you meant right I mean you can't come on wants to play that game you gotta Giga keep your ego

I got bad at the door or whatever where do you want to use right unless you're so amazing that you can think of every corner case in every situation and every

every configuration possibility that you can just you know crush it right out of the gate I'm not that person I've never met that person you're staring at him right here.

[9:26] Any tool can I totally get it sorry.

I am totally kidding I am more modest than I tell you I am not that person I make mistakes

every day so and I will own up to them a hundred percent so there's a story I've been telling people that when I first started out and it because I wasn't a network engineer.

By trade originally I actually had a kind of senior principal network engineer have an ego

a not help and not share and not mentor and not provide information and so that situation like it like stuck hard and I was like I will never be that person that does not share things I will never be that person that does not help because I mean

I literally was asking a layer to question I was learning and I was like a.

[10:14] It was like I was like a systems admin like I worked on servers I didn't know networking I didn't I worked on a server I worked on Windows you know and I didn't know,

let's CCNA and ccnp I didn't know switching and so I asked the question about vlans and he wouldn't even help me he was like very like he had no I'm not helping you and it was a simple like no like it wasn't even like a no you suck I will not help you is like

no and that was it that was it

so I'll contrast that with one of the very best experiences I ever had as a young engineer my title was I think like land where an engineer or something like that and I inherited a lot of stuff that other people.

[10:49] Built including a somewhat complex multi area ospf network that I

wasn't overly familiar with ospf you know I was CCNA level kind of get working my way up to ccnp slowly reading through the books trying to get ahead and get the hang of it we had this problem where an ISDN line would come up and because of.

Area the endpoints were in it would cause a convergence event where all the stuff in this one area would start flowing through this ISDN link when it should know because there were bigger eat,

at links that it could flow through and it was a it was a design problem in the way this is D and Link was built.

I didn't know what was wrong it was over my head at that point in time and the ccie came in from a Consulting Group and he explained.

Everything that I have and I've told the story before I've never forgotten this guy.

Because he said no no no this is the way I was PF works and he like walked me through exactly what was happening when the link would go down.

[11:44] The trigger event that would then bring the ISDN line up and then how ospf observed a topology and what that meant and he said in this is what we're going to do to fix it.

Do this and this and this and this and then when this happens again he actually would then have me now tell me what you think is going to happen when the line goes down.

It was awesome and he was so and he was a ccie which were like you know God status humans right you know yeah wow and he took the time to explain to me it was incredible I've never forgotten that guy in the eggs that example.

At the time he spent to teach me that thing

see that's awesome like that just spending the time with someone and actually like showing them because you can see someone that's that's driven someone that has that that

I mean almost like a thirst or like they're hungry or they want to learn they want to they want to sponge it all up soak it all up not sponge it all up um you know but that that's what they want right and.

Sometimes you just got to find that right person like honestly just got to find that right person.

In that situation where you were talking about as a network engineer and you notice hey this isn't this isn't working right 80% of the stuff that you design mister designer architect worked this other 20% didn't you know

what would you do in those situations if the designer architect wasn't available.

[13:01] Designer architect wasn't available so I mean we're talking about a fairly formal setting their butt.

[13:09] Some shops I'd work for would have a very formal and rigid approval process to make changes so

it might be that I'd come up with a change that would take care of that 20% situation.

It might be that I couldn't do anything about it because there was Change Control involved and it was going to be a month or two months other places it was more like talk to the boss and go this fixes a customer problem if I put this in place,

can I do it boss would go look this way look the other way and go okay don't screw it up and I do it you know just get it done.

Like that but the process for that was never for me anyway it was never handed back to the architect of the designer and go.

No man is broken I would always dig in figure out what the problem was.

[13:58] I didn't try to understand it very deeply and then come up with an appropriate way to solve the problem okay if we

turn on the switch if we add this feature if we reconfigure this way then this problem goes away and it doesn't put anything else at risk and then present my findings to someone else assuming there was someone else that would

V that I need to preserve you over something right yeah but but I in other words I didn't just.

[14:25] Walk in with a problem I walked in with a problem and a solution if at all possible see that's a good that's a good lesson to take right you don't just come to someone with a problem.

You actually go through the process of identifying valid Solutions and you come to the table with hey here's some valid Solutions and here's the pros and cons.

And to me that's part of the engineering role you've got to be able to dig in and research.

[14:46] Because the the really fine detail esoterica of a network and there's a there's a ton of that stuff.

Comes down to a network engineer to know that the designer the architect might not know that Designer architect might be living,

at the world of white papers and I've done enough lab work to kind of get proof-of-concept working and that's cool and they don't know that in.

Juno 16. Something or iOS XR version 6.0 whatever there's some quirky thing there's a memory leak there's you know oh that's which isn't there

because you have to get a license for something else or whatever it is that the engineers tend to know and so you need to be.

Deep into it to be able to deliver that kind of information Upstream so that everybody's as informed as they need to be and can modify the design appropriately so again going back to those

communication skills and taking responsibility for things.

But then also I don't know the ego thing maybe that's whole show Amanda hold Eagle yeah man I think you could get a lot of examples of positive and negative eagles egos and are

career honestly in the industry so.

[15:57] So there's a way you could communicate this stuff right you could as the engineer find a thing that makes some architect look bad

and say and you when do you share that information do you throw down in a meeting where all the people that work on the network at a high level

are there or are you cool about it and like go to that person directly or go to your boss who you know handles it maturely and say

I found this maybe you want to bring this over to the architecture team and see what they do with the information you know you could be that way and kind of be humble about it as opposed to being

look at me I'm awesome and amazing and you suck you know why

come on that's not a good way to make friends encourage teamwork and build trust you're not building trust and man you want that trust when the network is down you want everybody on the same side not adversaries.

[16:51] No I will hundred percent agree with that right like bringing something up in a forum like a conference meeting or with the with their bosses and directors or whatever there is not the best place to do it and I've actually been like in certain circumstances both.

At a company where I worked and then also as a consultant where I'm in I'm in that meeting and I'm it's happening and I'm just like,

and I'm like what do I do here like and I want to say something almost like because of leaders getting like leaders Stuck in the Middle right that that you know

CIO or whatever it

infrastructure manager whatever role that leader is now stuck in the middle of this situation I'm almost like you guys might want to just you know break the meeting and have a one-on-one or an off top offline conversation about this instead of doing it

in the middle of the meeting it gets pretty heated to Total power move right yeah oh yeah hundred percent I never I just see for me I've never even thought of doing something like that like that's just my personality like I'm the kind of person that's like I'd rather talk to you one on one.

[17:51] Getting you an agreement together and then let's go to that meeting on the same bike on the same page like we're going to be united front like yeah.

[17:59] When you're insecure you tend to not handle things that way you're always on the offense you're always trying to prove something.

You're always you know aggressive and you know trying to be the you know the the toughest baddest most knowledgeable nerd in the room.

Because you're insecure really as opposed to being kind of comfortable with what you know and know that you don't know everything and you know being willing to go to that person one-on-one and saying

hey so I ran into whatever it is and I thought you might know something about this and we talked through this and then,

you're having an exchange in building that relationship with some which is way harder than.

You know an email reply to all I solved the problem but to prove yeah yeah yeah

no I find I mean I think that we're talking about this a lot because I think it's actually really.

Important and I'm thinking like some of the people that are just starting in this this industry and thinking of network engineer roles and becoming a junior network engineer role and I think this is extremely imperative for Success because it's

you can't just throw things over the fence you really do need to partner up with the people in your organization and not just the people on your team like

like yeah you need a partner up with your fellow Network engineers and whatnot but you also need to partner up with if you're in a siloed organization where you have like a,

virtualization team a storage team server team like you need to partner up with everyone you need to be that person that everyone is like yeah I love working with you know Ethan he's awesome I'm gonna you know we solve problems together every day.

[19:28] What you said something else that was interesting you position someone who is like looking for that Junior role and that's something else that some of the biggest career mistakes I made as a junior engineer happened because.

I wanted to be senior in in charge and had to prove myself constantly.

[19:45] And so there was a certain arrogance that I brought to the table as a junior engineer where I did not respect the people that had been there

for three years five years Ten Years and we're responsible for building the network and were there when the trade-off decisions were made because of

budget and skill levels and stock of the parts that were available at the time versus when the project had to be completed and so on that I didn't know any of that stuff

but they did and I didn't respect that because I know I know everything because what you because I had Google I don't know Google exterior Google Foo.

[20:22] But that made four times or I'm sitting in my bosses office with a co-worker who was probably more senior than me and my boss looking at me and looking at them and then going okay,

so we need to learn how to deal with this and Define roles and responsibilities basically because I kept overstepping my bounds because I was too obnoxious and do cocky so there

it's just so easy to not respect someone because if you've never been in their shoes and you don't know what you don't know you think you're the one with all the answers and that's just so awesome.

Yeah I think I mean I think

what's helpful in those situations is like I'm a big fan and maybe it's my military experience and background is that if we get someone that's new on a team and it doesn't matter where I work if we get someone that's that we're hiring and it's two on two team we had that first day we assigned a mentor there is someone that will be meeting that person every day

for the first six months and it's more of a just like a hey how are you doing what are we looking at what are we working on in let's let's show you the ropes right

let's build that relationship we're not doing anything or going to silo.

[21:26] Right we're a team and we're going to show that we're going to be a good collaborative team no matter what our roles are it's always going to be a good team team situation and it's not like

I'm in charge right I am not in charge I don't like to be in charge I like to.

I don't know to call it right it's like a I want to find the best solution the best option and I may not have it right and that's fine I most taught most of the time I don't have it right.

[21:55] It's collaboration right examining there's there's there's a solution that I will come up with because of the way I think I have certain experiences and thought patterns that will probably lead me to solution.

X

but that may not be the best solution and so what I've learned over the years is that even though I think I know all the answers when I collaborate with someone else and they look at the problem in a way that I would never look at it because I me and they're them

they see something I don't see and then I go oh yeah and we Implement that other thing or or the solution is tweaked in some way to get to that that better answer the really is when you have a.

A teamwork mentality as opposed to an adversarial me I'm the one that knows everything kind of mentality would you really have that team mentality.

Then you almost invariably end up with a better solution almost all the time

well look at it as like the best mind right and there's a lot of things out there about like masterminds and all these other Concepts but like when you have a group of people.

[22:56] Together let's see if three people together right and there are actually collaborative they're working together you almost create this this best design you can create as a group and it like I'm a big fan of eigrp I will usually.

Throw myself into an eigrp solution I'll be like up your pee is the one to go but it's not always

putting the case it's definitely not and I'm definitely not right half the time if not more but the point is that like

I have my things that I have preconceived notions on I have things that I like personally and so I want to be in a room where people are going to question that.

[23:29] In a tactful way to think tact is extremely imperative so as a junior engineer learning how to talk and learning how to communicate like hey I think there might be a problem with this versus like your designs up.

But there's a very very different wording that you can leverage in those situations.

[23:46] Well this is interesting coming from you because you do have a military background and Marines right yes yes

so I think of the typical Marine is very Brash and not afraid of Confrontation but you're still emphasizing the pack the the point that tact is quite important oh yes.

It is it is critical it is I mean it's a court rate right and Marine Corps we

there's a whole bunch of leadership traits and characteristics but like again I mean just knowing how to talk to both your peers and your leaders

and tactfully

talk to them and let them know what's wrong and what's right and then also how to lead up and down right that's critical I mean that's how do you lead up and down how do you tell that leader what's important

that they care about and what you're doing and how it impacts them it's even coming someone coming from your background is you gets it

yeah yeah exactly the confrontational approach I mean don't get me I never I don't I didn't always get it

let's be clear I didn't always get it there might have been times I was so naive that I was that confident conference 10

tension tensional whatever the wording is I was that guy and it wasn't intentional to be like my networks better than your network or whatever but there was definitely times where I wasn't smart enough to realize that I was in the wrong.

[25:04] You know I never wanted to be you know I never wanted to be it just sometimes you don't know what you do that's wrong.

[25:11] I need someone like you to tell me right like hey you're wrong being willing to understand that you might be wrong and that that's a possibility takes take some doing you have to be able to get to the point where you're comfortable enough to actually.

Be okay with that yes be okay that you could be wrong right that possibility but here's here's a learning experience or Learning lesson right and owning it

and owning it appropriately right when you're wrong don't hide about it I guess that's probably one of my best not bad it was probably my one of my suggestions or takeaways is don't hide it if you make a mistake.

Own up to it explain it right I've made some really bad mistakes I brought in down a lot of companies a lot of organizations.

[25:51] Over the years and I could go into details right the point is that you have to own it and you have to be really truthful and upfront the K I messed up.

[25:59] And I have no excuse I just messed up,

and I'm not doing it again I don't know so let's talk about that right let's let's jump into that kind of let's talk about some of the things that you've messed up.

Things I've messed up well I mean clearly I'm perfect

yes clearly sure where I'm supposed to go with this we'll do it in the email didn't I mean we were going back and forth planning the show I sent you a list of I don't know how many different War Stories let me knock about I'll talk about one really straightforward when that leaves to my mind

which is I was on a phone call with tach troubleshooting a Cisco 7206 vxr.

And it had a big T3 that was this was the main router for a remote campus that had 3,500 people on.

And that connected that campus to two other major campuses in a metropolitan Network for a state

Network that I support it and I forget what the problem was it doesn't really matter tack told me to go to the console and type debug IP packet,

and I said okay you know in my brain it's going I don't think this is a good idea is it.

It's really this teams like I shouldn't do this and I told I remember telling the tack guys like this is a production Network I'm okay to do this right.

And I believed him when he said yes and I hit the button and the router was gone just let me with that fat dun dun CPU

hundred percent on man this is always PF environment so lost ospf adjacency very quickly I saw that fall over at at the head end where I'm the other into that T3 is like.

[27:25] Walked into my boss's office a kind of go over to State Office Park South and reboot the router I just killed it and the campuses off lashes like what happened tell you later get another car you know drive over.

Head over to the closet and fire that thing rebooted get it back online and everything comes back up again come back and then sit down to my boss I was ago.

[27:47] Okay here's what happened I'm glad with tacking they told me to do this and I kind of knew I shouldn't have done it but I did it anyway because they're tack right their gods and I killed the router I'm sorry what happened.

Stuff like that you know that it happens especially when you're young and naive and you don't know that.

You know when you're logging to the console Port which I was that you're just going to crush that thing and you know.

Stuff like that happens yes it does it does have you made any like unintentional like unplanned changes during like a maintenance window.

Unplanned changes during our you triggering me for a specific event that I am not I am not okay I'm specific I'm asking because of me so that's why I ask is because at least at least you did something you were told by Tak to do and you're like I don't think this is right but you are troubleshooting something and you did debug IP packet right but like I've done some stuff where I'm in a maintenance window where I'm like

one of my.

[28:38] You know places I was at was like Hey I can't access this device and I made a change right I made a change it wasn't wasn't scheduled or part of the maintenance window and that change of brought down the entire place.

Yes I very definitely during production one day changed a ether Channel Port range.

In such a way that I killed the entire Aether Channel connected to the storage array which pissed off a lot of servers they could not talk to this thing.

It was some iSCSI array there might have been like even sequel living back there I forget what it was like.

Type type of long interface range blah blah blah blah whatever is doing Enter due to do know this delete this change whatever I was working on then it's like I missed a one somewhere in that range so I clobbered like 10 more ports that I meant to is like oh.

Crap what did I just do oh oh No and then I realize which either channel was gone.

[29:35] Back maybe no one noticed no one noticed right yeah right

there's my my bosses Pierre the head of like the virtualization and storage team go on what's going on with blah blah hagalo because he was one of these guys that was super political it's like I am going to be

eating this one for weeks it's brutal.

What were you doing on the course which during production Banks here we go you know so yes I have.

There's one is it that's a mistake I made there's one right there.

We've all made the VLAN allow you know allowed VLAN statement you know.

Where you put in the one deal and that's now allowed and clobber all the rest of instead of adding one to the group I've made that mistake although I don't remember it hurting that badly I know I've made that mistake though.

[30:28] For sure I've changed ospf area types in the middle of a maintenance window thinking that all this would be no issue I'm like four core routers thinking that I was doing the right thing not planned of course and then because I wasn't thinking straight.

When you change the area type it actually you know reboots the entire OS

a process in the entire Place went down eventually the neighbor ships came back up but I mean that's not a fast situation especially if not doing a full.

[30:56] Fast what is it sub-second fell over or anything like that I mean again it was it was a situation it was definitely a learning situation and I owned it right away

I had that conversation with the you know the customer is like hey I really messed up but you know I got to go fix this and then you can yell at me

like I promised I'm going to go fix it real quick we went down to the next floor we consult into the switch has made all the changes and the guy was working with was like.

So yeah you're going to tell me everything you just did because I have no idea what you just did I know everything went down and we're going to hear about this for like months.

[31:28] So we went to the office whether the you know the network manager and it was like yep I messed up and I will not be doing anything ever again in your environment because I that is my own control right.

Well I had one trying to bring a juniper SRX firewall online without was

very important it was sitting at a Nexus where it's separating a customer environment from a core environment and that SRX definitely needed to be in line because reasons it was a hip environment blah blah.

[31:58] And for the life of me I could not get this friggin thing to pass traffic it's three in the morning it's a freezing cold Datacenter it's like I've done everything right I done

all the routes are up I can see routes in the routing table why won't this thing past traffic is just going over it and over it and over it in my head a half an hour.

Five minutes an hour my boss comes in going.

[32:19] We're about done right because the windows about to close to we need to back out are you going to be able to figure this thing out and I'm like.

You know freaking out long story short Juniper SRX is a zone-based style firewall

and I hadn't configured the interfaces and put them in zones it had no idea where to be passing traffic basically the most fundamental.

Of the firewall policy had not been written despite all my carefully built rules and the logging and the routing and all the rest of the stuff that I put in is an engineer to make that firewall exactly what it should be

I didn't do the dirty stuff that's like the most obvious thing in the world and stared at it for it ended up being not quite two hours before it hit me hey dummy

did you put the firewall interfaces into the correct zones you did not.

[33:07] Did you dude you know they two lines of code put it in it's like okay it's passing now I can move on with my life holy crap that was awful

so and it continued to be awful for the next couple of hours so yeah I have,

I have similar similar issues where like I always miss the simple things like it's always the little dumb simple things that I miss it's the complex things I get right and it's like it could be something

totally complex like bi-directional redistribution on multiple routing protocols and tagging and whatever right this this is insane routing

topology architecture but like I could forget like

something dumb like VLAN configurations or trunking a port or anything like that because I'm not thinking about it right.

[33:47] You're actually reminded me of something that I think is very important to do as an engineer and it goes back to that communication idea it's kind of related but that is

being able to clearly document something and you're documenting something not necessarily for other people although that's probably the primary use case it's for yourself

so you don't forget stuff.

You sit in the lab you thump it out you kind of get used to it and then you know some time goes by and you forget kind of how it works and what you supposed to be doing and then you try to troubleshoot it and if you don't have that documentation your relearning it all from scratch if you've got documentation that's well-written then

it should much more quickly come back to you what's going on and by documentation I don't mean like

Step 1 tighten this command step to type this command no no when I talk about documentation what I mean is step one,

type this command paragraph of explanation

this is what's going to happen when you do this and this is why you're doing it and you need to do it in this order and don't miss this step and then try to fit it in later you need to do it here for these reasons so that the logic of it all.

[34:52] The reason you built this this particular procedural pattern becomes fresh in your mind because that refires those synapses that came together the first time you did it.

So good documentation is

absolutely critical I believe as an engineer because it's the engineer again go back to the top of the show Zig I think the engineer is the one that's closest to the network grab down there in the guts of the thing and really understands it more intimately than even The Architects do.

[35:19] A hundred percent agree I mean when you said a couple things their documentation is critical even like my home network like it's not documented I don't even know what I did yesterday

in my home lab environment right like it's you know I was doing some SDA and stuff and I'm sure I have no idea what I broke because that's what happens I break things all the time

but like so there's that documentation is critical even in your own home environment right like I see a lot of people in some of the communities create their own kind of Wiki's to document their networks now,

versus you know how probably what you and I used to do is like you have a diagram and you write it out and you have you know maybe a script of configurations and you have it how what each config means and are we each.

Get each config means like you suggested there or even like a Blog style right but now they're doing it more like Wiki base where you have a Wiki and you can have pictures and diagrams and the wiki it it's kind of cool,

yeah I've worked with with a bunch of that kind of stuff either it's a blog or it's a Wiki with SharePoint back in the day she'll make fun of SharePoint but I built a lot of documents and SharePoint with pictures and diagrams and highlighted paragraphs and,

you know they did be part of a library that would have Visio diagrams and so on and admittedly that stuff tends to get out of date but still even if it's a little out of date it's better than

nothing it's a starting point right it gives you a starting point but okay yeah I did this three years ago right I can't remember all the changes that the between then and now but I definitely can't remember everything I did like six years ago so that's a starting point.

[36:45] It's especially true when you do things that are not immediately obvious so so for example maybe you've got.

[36:52] A set of wanne routers that remote offices and you want all of those remote office when routers to have essentially identical configurations except for you know some little IP addresses and things that are by definition going to be unique per device

okay well in those situations you almost always ran into a place where one of the routers are two of the routers need this one funky command because reasons

and because you want the configs to be like like if it's not hurting anything you'll put it on the other ones that don't need it you need documentation to explain what's going on and why.

That kind of stuff really matters yeah I have no I get that answer that so I asked this question all the time like why did you do this and I get the answer it was in the script.

I just copied it and pasted it I do we just what we do all the time like I've been in so many networks where like they're doing some complex

Technology Solutions like mpls traffic engineering tunnels or sub-second failover whatever right and they're doing it because it was just in the configuration which is in their script

they have no idea why they were doing it to begin with it's not doctor defining the difference to me between an operator and an engineer that's

an operator runs the scripts does the thing whatever I got the order in and I'm supposed to run this script and then run these things to check in and then I'm out do you have to know how it works kind of not really the engineer understands exactly what's going on and why it works.

[38:15] That's a great definition between the two I like it that's a distinction to right operator versus engineer I look at the operators like the admin almost like the he's the one that's like okay I gotta create a New Zealand

let me go grab these template configs copy them and paste them and then move on with my life and no validation no nothing he's done he's at his task and click that remedy you know ticket check box

so the operator is the person whose job can be automated away is another way I think yeah look at it

when you add in the true engineer not really because they're bringing more to the table.

[38:48] Yeah automating the operator it's like your own em tasks right operation maintenance tasks it's like.

Adding a no configuring app or even like first Pacific VLAN that could all be automated

these days exactly right exactly right that complexity of the network environment might make it difficult to automate that stuff but you get there eventually I think all networks are going to get there with the button-pushing tasks will be done by software.

[39:15] So on that note on the automation

question for you you know there's this myth about why I'm going to call the myth some kind of leading this I'm sorry there's a myth yeah I'm kind of leading like I'm just leading you down this path there's this myth that like if I embrace automation I'm going to automate myself out of a job.

[39:38] A couple of thoughts here you know one network environments change a lot there for the needs for automation will change a lot in accordance with the business.

Static for a while and then it changes because there's some business needs something happens o we need to bring load balancing into the environment which causes a pretty significant shift in what the network design looks like oh we have a new security Paradigm and so something significant changes on the network again

all right well as every major iteration of the network comes through you're going to need to change how the automation looks because there's a dependency tree that gets built I added load balancers to the.

Oh well that means what I deal with the automation now I have to update on that I don't know F5 device let's say.

My VLAN Library perhaps or how I'm doing routing or right you know what I don't know what it is whatever it is that might need to change in your automation so there is a role then.

That you're not going to automate yourself out of a job but you will spend less time.

[40:52] Finger bang in the network to make things happen and more time working on the automation infrastructure to make sure when you do need to make a change.

It happens and it happens successfully every time and that the automation tooling is keeping up with the things that you need to automate

it's going to be less about can I configure the network in more about can I keep up with the business needs in a timely fashion such that if you don't automate.

[41:19] You're going to be out of luck because the speed of the business is such that you're not the weeks of lead time to build a new virtual IP on an F5 box

no that's not acceptable it's just not acceptable anymore things like that should be automated and you should be able to do them at scale quickly.

Understand the process of your automation deeply so that when your automation doesn't work right you know how to fix it and make it work again.

[41:45] And so that that headcount you're never going to get doesn't matter because you're able to keep up now you've built the headcount in the form of software.

So that's all those are a whole bunch of good points right you mentioned business right and I think that's the first time we met

kind of Tide business into all of this and I think that business really drives everything that we do.

And if you ask the zsiga 10 years ago if you asked me right I don't like the way I talk to my third person Voice or whatever but if you ask me 10 years ago I would have said the business sucks technology roles and I'm all about technology I actually remember a situation where I told a CIO that that

he's like you need to focus more on the business and the business lines of effort and the business priorities

he's and I was like screw that stuff on the routers switches and CLI and I care more about my you know technology things that I do about the business you know today I'm like hey you need to care about the business because the business is what matters and it truly does matter and I wish I had

I wish I could slap myself you know my 10 years ago.

[42:43] You know past self but like dum dum but dude I identify with that very much I used to feel that way like you know managers are

what do they do they're just stealing my oxygen you know why are they here gimme gimme on that console put me at the CLI let me type the thing and make it make the things happen that are supposed to happen cuz that's what's really important here when it that's backwards thinking.

Because everything that the technology is there for is to support the business.

And so if you don't understand the business you don't get budgets you don't understand your competitive space that your company is in

etc etc because you're there because you're a nerd you love to you know twist the nerd knobs.

You're totally missing the point of why you're actually there it's not because you're awesome at technology it's because

they need someone awesome at technology because the technology is making the business go so if you lose sight of the business and what the business is actually doing and you just don't care because screw that

you don't get it you don't understand why you have a job.

[43:42] Yeah it's so true it really is and so that I mean there's a lot of takeaways of today's episode but that's definitely one of the major ones is that you have to care about what the business is doing.

Because it means the network doesn't exist without the business and you know there might be things that are non for profit that don't fit that bucket right but they're there because they're feeling a certain service right there filling a service so they still need a network,

to fill that service it's even deeper than that though I think because because we can say.

[44:10] Oh well right the business is the reason we have a job when can I not our heads and we get that.

But here's how you as a network engineer become more valuable to the business when you can speak their language when it is time for budgets and they say hey can you cut something.

And you're like I don't want to because I have this idealized notion of what the network supposed to look like and then you can respond to them instead with something like.

All right this is group of items was for this project how do we want to priorities that prioritize these over the next year and then I'll figure out from there what the right things are to,

so instead of you being this adversarial whiny person who's always got your hand out for money you're listening to them the business stakeholders understanding what the needs are of the company where they're having to make trade-offs because of

cash flow challenges or who knows what's going on,

and then work with them to give them the best solution you can give them within the constraints of the budget when you begin to think.

Like a business owner and try to identify with them.

[45:16] Then you understand that all right they're constrained for cashing in this way or whatever it is and they are now I'm going to give them the

best I can because I'm on their side of we're all part of the same team they're not just trying to screw me because someone gets a bigger bonus if they cut

a hundred thousand dollars out of the budget or whatever it is it's actually a need that the business has.

And when you can understand things at that level and think like that and you're not just the nerd in the corner sitting in the dark part of the data center and they throw a piece of raw meat to your once in awhile when you're not that person.

They're way more interested in you and keeping you around and when layoffs come there like

why can't you know this guy or that person and I we want to keep him because he's like a grown-up that understands businesses have challenges and has tried to work with us right along so since he gets us let's keep him around.

I like how you said he's like a grown-up I'm sorry that was my takeaway from that but it's just funny but no that's I think that's.

Important right it's all about like being a team player we talked about that the beginning kind of the show right.

Because it's not just team player on your team but like understanding the business what they're trying to do and having a seat at that table and actually showing the business the value.

[46:31] And and and being able to articulate that right and talk that talk and and say hey we have all this technical stuff here

this this these numbers these budgetary numbers here are for this project right and you can say hey I can I can do this I can create a solution with

half that cost or 1/3 of that cause but you're not going to get these things right you're not going to get these nice to haves now if they are requirements then you guys gotta let me know because we got to bring that money back in.

And make that happen right like that's a it's compromising right that's all it is it's compromised exactly exactly it's been compromised but not in a bad way in a way that that's life and there are trade-offs and there's compromises that that's every

it design not just networking but across the board is a compromise there is no perfect.

Unfettered by budgetary constraints Network that exists maybe there's a few but I mean not not that I have one doubt it we've all had those kind of constraints and so when you can say this is a million dollar project and they say

mmm

that's a bit steep I can't afford a million I can afford half a million it's like okay I can give you 90 percent for half a million are we okay with the 10% that we got to cut.

[47:43] Yeah okay cool we all win you got to be able to have those conversations so then I think that's good right I think that those are

good conversation to have but then I also get in these conversations we're like we talked to a customer or were part of a company and you know they want everything

right they like they need this they need this they need that they need that and then you get them you know okay we talked to these vendors and here's a five you know million dollar.

[48:07] List of equipment and solutions right and then come back like oh we only had a hundred thousand dollars.

What do you do then write like you mean it there's really no win-win at all it's a situation where like you're asking for you know a crazy capable

expensive system and you just don't have the budget for it.

[48:29] Now and then it comes down to education and not talking down to someone it just going okay you were severely budget constrained you have this problem that you're trying to solve and then it's just having a very factual.

To do this you need these things for this reason you're saying you don't have the money for that fair enough,

for the budget you do have as small as it is we could do this that get you a little bit of the way there and maybe we plan for the rest of it in an upcoming budget cycle or the next three upcoming budget Cycles we're going to phase it in you end up with a phased approach.

Now that's good for using it in or the course of a period of time right a year or multiple years or whatever you know it depends on the budget the budget Cycles right

which of your consultant a that's cold man you know you're going to be back and back and back and back delivering this thing for them over time and it's actually.

It's not so bad in a lot of ways no it's not the idealized solution but it's a good way as an engineer that you can deliver that thing and really get it right

and of course the more time that goes by probably the better the technology is and if you're really lucky the cheaper it gets so if they don't have to have it today it's not so bad to deliver over.

[49:37] You get sticky too if you're a consultant you get sticky with that customer right because you're bringing value every time you come on you're helping them out with whatever that solution is and before you know it like they're calling you up when you have.

Right there like hey we have a problem with trust yes that trust right.

Not the trust that we don't want to say the trusted advisor right everyone talks about that terminology but I mean it's really that trust relationship you're building trust they trust you and they think that you know you're going to come in and they think they know that you're going to come in and.

Help them write and solve their problems effectively.

Good Engineers are difficult to find and so when a business that is hiring an engineer whether that's a full-time person or a consultant.

Finds a person that gets them that works with them that could communicate well and that delivers on what they say they're going to deliver that.

Dale going to keep calling that person back and back and back and back it's as long-standing of a relationship as you want

it really is because those people again they are hard to come by so what are those those key skill sets critical characteristics that you would put in for like finding a date that that good network engineer.

[50:40] Well it's twofold for me so I've interviewed lots and lots of Engineers to work either for me or with me on a team over time and I think about interviewing folks and trying to figure out who they are in a couple of ways one.

I want to know that you can communicate so I want to know that you can

I wanted to kind of not only how you communicate but how you communicate how you think so I want to know how you think and then how do you share that information with other people so I tend to ask questions that are along those lines.

[51:13] So I'm not very likely to ask you about everything you know about eigrp since you brought up eigrp earlier in the show I'm probably not going to get into that as such unless

wow different that's a different scenario but what I am likely to ask you is something like Zig Rabbi marker go up on the board and I want you to draw.

A representation of the most recent Network that you've worked on and talked to me about it.

[51:40] It's very open-ended question Yeager board talk so then I'm going to find out a lot of things in a question like that that actually is one of my very favorite quotes like that.

[51:51] Well how well did they understand the network that they were working on because I'll get right to it do they know

like the one Edge router that that was their specialty they worked on this one you know they were like 5,000 of these Wham routers in the network and that's the only piece of the network that they worked on

or do they actually understand how traffic gets from that win Edge to the other way an edge and all what the overlay protocols that were involved and what the routing was that was involved and when all the rest of it.

[52:18] So that's you know they'll start drawing things on the board and I'll say okay so what's that well that's the course which okay well model was the core switch,

oh I could believe how often that stumps people oh it was a Cisco.

[52:32] Something I don't know okay oh this is supposed to be 500 okay what soup engine did it have in it.

I don't know you know etcetera you can figure out with something like that very quickly how well they understood what was going on and then.

So that's one of those things that I'm looking for how well do they.

Communicate how well do they draw things on the board and then relay that back because that's going to factor into their email it's going to come up in conference calls it's going to come up when we're sitting in the conference room back when we used to work in person remember that,

and so on but then also it gives me opportunity to probe into How Deeply they understand the network so let's let's go back to the 65 or you know some some new something new or 65 hundreds of really old today I bet this still.

Thousands of them still in production all over the place but but anyway

okay so what soup engine did it have o it has a whatever okay was it dual soups or.

Do you do you know oh now if it's yes it had tool soup so okay with a SSO how did that how did that go

do you know if the routing protocols were set up for graceful restart you know you start digging digging digging digging.

And the point isn't to.

[53:54] Trump the engineer with you didn't know about that one bit in that ospf header that's not the goal the goal is to find out.

[54:03] From an experiential perspective what they've really worked on and at what level they have tried to teach themselves about.

Networking so.

[54:14] Zig you and I have both gone through the ccie process which forces you to learn a lot a lot a lot of detail many things that you would never learn.

Okay.

[54:25] So I want to find a person who's maybe they're not a ccie but they but I want to know how curious are they how much do they actually understand because that tells me.

[54:37] What kind of a person they're going to be on the team.

[54:42] On the team I'm looking for someone who is more or less independent but knows when they've run exhausted all their resources how to engage other people on the team with what they need to know

so another question I might ask is something like so you've run into a problem with configuration configurating X you don't know how to do it how do you solve that problem.

So many people their response is I'm going to ask you or I'm going to ask you know I'm going to ask somebody.

[55:12] That's the wrong answer it's a valid answer yes you could ask me or whoever it is but the answer I'm looking for is I'm going to dig through the documentation I'm going to search the internet I'm going to do whatever I can to try to solve that problem on my own.

And only when I've exhausted that and I am still stuck am I going to reach out and go to help go ask someone for help and say look I tried all these things.

And I'm just stuck man I can't seem to find the answer can you tell me what I'm missing you know point me in the right direction.

You need to have that sort of a curious mind someone who was an independent self starter.

Because we don't have a lot of time we're all too busy there's not enough of us to go around.

[55:55] I need someone who understands how a protocol works well enough that rather than them.

[56:01] You know asking me 20 Questions they're helping build out the automation workflow you know what I mean they're helping you and I don't know what that's right.

[56:10] It's either helping you out there helping you not hindering you yeah they're not when you want someone to network engineering team.

You don't they don't need to know everything out of the gate but you also don't want them to be a boat anchor you know this dragging you down and and so on

there's a balance there to be found you don't have to know everything but if you have a person that knows how to learn.

And you can demonstrate that you know how to learn oh yeah I'm interested in you I don't care if you don't know that much about eigrp let's say.

But but you're willing to learn and you're engaged and you think about it the right way and you ask the right sorts of questions and you're you're willing to study and learn and think you stuff out because you can learn anything you're willing to put the extra to it.

[56:55] So let's summarize right because I want to make that clear like so I communication right there wasn't one of them so how you communicate communicate effectively someone like that the ability to learn.

Maybe the drive to learn abilities flash drive to learn and then.

[57:12] You said not like yourself start being able to work independently right being able to you know you may not know the answer and we know that

even going after the CC is and whatever you realize real quick that you're never going to let you know everything right so knowing how to find the answers to the questions you don't know.

Definitely knowing how to find the answers and.

You know I said independently and maybe that flies in the face of our earlier conversation about teamwork and no ego and you know what that kind of stuff so I mean there is a

yes I want you to be independent but yes I also want you to be able to go and seek help when you finally,

do need it but it's such a difference between doing your work ahead of time and just saying here's something I don't know how to do I'm going to go walk over to Ethan's Cube and see if we can figure it out.

Hey don't make it someone else's problem right like like that's where I'm at like don't punk that perfect don't take it someone else's problem I love it

yes like if you don't know how to redistribute between eigrp no SPF I don't know that's not even a valid like issue right now but I'm just saying let's say you don't know how to do that like you don't need to go talk to Ethan or to zigbits take it out you can go Google you know you sure gufu

there's Labs out there I'm sure there's YouTube videos and you can figure it out and that's just an example conversation topic but then when you have a solution.

The you--for you know you've honed out pretty well that's where you bring that back to the the whole group the collective or whatever you want to call it right.

And say hey here's what I've been working on let's throw holes in that let's see if it works and let's make it better and then you make it better.

[58:40] Yep yep yep so last thing I wanted to kind of highlight here is so you know as a network engineer how do you go about improving yourself.

[58:47] There's so much study involved.

Zig it's just it never ends I mean I'm saying this almost my point of being weary you know 20-something I guess approaching 30-something years in a technology career it does seem to get.

Exhausting to keep up with tech because it just doesn't end and even and if it's stuff that you don't use there's stuff that.

You told you you've not seen it before then it comes up and now you gotta learn this other thing and so here's a case in point is that these days I do a lot of research and work related to podcasting for packet pushers.

The show I'm prepping for that I'm going to be recording tomorrow is on BG PLS will beat you PLS isn't particularly new it's been around for five ish years something like that.

And but it's new to me why am I carrying link state in bgp that is counter-intuitive and evil and someone should have to pay for that.

Only.

You know as you dig in and begin studying there is a whole raft of data about exactly why that engineering decision was made in the ITF why the protocol supports it the problems that it solves the use cases for it and so on.

[1:00:05] So my point is this that is improving yourself it is digging in and studying and reading and understanding and labbing and you can do it in an informal way like.

My study so far has been informal I've been doing a lot of reading there's lab work that I'll be able to do to reinforce that which is a little bit more formal.

[1:00:24] All right I've got you know a couple of decades plus behind me in networking at this point and I kind of got a lot of ground work behind me.

What if I didn't have that groundwork what would be my method for learning stuff and what I did early on in my my courses of study Zig was certifications.

I went through the whole Cisco start ladder CC well they have lower rungs now than CCNA but at the time for me CCNA was where you start at that was your

first step on the certification ladder then I did ccnp routes which then I did ccsp which that doesn't exist anymore but I was the security professional learning all that okay I did that and

and then in just learn and you learn and you learn in a very formalized way using certification blueprints as your guide of the things you need to understand.

Forcing yourself to get to the point where you can pass those exams.

[1:01:20] And now you've got a least a baseline Mastery of a whole lot of things you can do that up through.

[1:01:27] Hi Amy I know you are you're a de zsiga and there's other ones you can do from other tracks Juniper course as their certification tracks and there's some of the cop TIAA stuff and so on.

But for people early in their career I.

I think certifications are a great way to go because it's a course of study that's been described for you in great detail and there's usually a lot of supporting material out there that if you willing to make the financial investment go to teach you what you need to know

fire up your gns3 and start labin.

Yeah labbing so I'm a big fan I tell everyone that I learn everyday I don't think you can be in this career field and not not.

Learn every day you can have some days where you take the day off I guess but like I mean the things change so fast and I T and just it right

something's going to come out today that is going to revolutionize how we do things and you could pick anything it could be Network design or being a network engineer and what we did 10 years ago just.

Look the same way today and so I think it's imperative to say that.

[1:02:34] I'll even add to that sick because what I've observed in 10 years of podcasting where I've been keeping up with the industry very closely and what's going on it's not just that there's a new technology that's going to change things for us there is definitely that right.

[1:02:49] It's also a fracturing of the market where there's now 10 things that do something kind of similar.

And you need to understand the differences in the nuances between them which drives me nuts dude how many toddling encapsulation formats are there right now oh yeah how all just you know for example that's that's a very simple thing.

How many traffic engineering Solutions are there now well there's this there's

mpls te now we can add pce to the mix and we can do segment routing and add that to the mix of how many flavors of segment routing are there there's at least three would you start including the IPv6 variance.

[1:03:29] And and on and on it goes will why do I need you know all of these different

variations on basically the same thing and so you know learning everyday is like.

Oh man even that doesn't seem like it's enough because I've managed to go five years I'd have it a figure of bgp Ls just for example if you it seems like it's almost impossible to keep up.

I had a plan to do a video YouTube video on BTW PLS because I was reading up on it a couple years ago and it's been on my to-do list for like a couple of years had to do a YouTube video like I've read up on it I'm like

this is kind of cool I might want to I'm going to do this and then you know things come up and then like okay I'm sure things have changed now I got to go read up on it again you know because that's just what happens in this industry

well Ethan I mean just open it up is there any last minute things you want to tell everyone say anything.

Do what I say usually any suggestions comments words of wisdom.

I love that working man I still do all these years.

Somebody asked me a while ago if there is one thing I wish I'd known earlier in my it career or something and the thing that I came back with his like man I wish I knew.

[1:04:39] Back when I was like a Novell guide and a Microsoft mcse and working all that server stuff and

and building out you know backup systems for servers and stuff that when I

finally got to network that that was going to be the thing that just captivated me I'm still there and I still love this stuff the thing that.

What we do as Network engineers and as Network designers and Architects and so on we connect the world.

[1:05:08] Seriously think about that it's so think about that.

We connect the world that sounds dramatic and even if we only are connecting you know working with the the few company are one company that's just got these.

Hundred or thousand people connected to it we're part of an ecosystem a global ecosystem of network Engineers connecting the entire planet together.

[1:05:31] Wow you know that network is starting to now include space ever more than it did we've got Tesla space link is going up.

We've got the Hughes Nets been there for years but it's just now it's becoming even more.

Then it ever was that connectivity that we are responsible for is is amazing and I'm not over it Zig I'm not over it I feel like I'm walking around you know and and it's like I know how the internet works

have you like really know how it works you know that's cool that's like that's power what we do is Network Engineers I think is.

Not just nerdy cool but also valuable and a big part of how the world works and I said I'm not over it.

Now that's great you know I'll say this last thing that the internet has become such an unstated requirement for everyone like it and I don't know how its word that like everyone

they soon the internet's going to work they assume it's there they assume they can leverage it for whatever purpose that they're leveraging it for if it's binging Netflix on the weekend right like whatever you're playing video games with their kids or what their friends or whatever working in building a business like

you know a startup business I mean do they assume the internet is going to be there we know how the internet works.

[1:06:48] We can understand it we can talk to it now you know I don't know if like our significant others can understand it or not but we can try our best explain it right so hey Ethan where can everyone find you on the interwebs speaking of the inner no interwebs right.

Best place to go is pack a pushers dotnet if you go there you can find the podcast that I'm on weekly those right now include heavy networking and a day to Cloud have you networking is a networking architecture design show we keep up with.

All the latest kind of thing like well like I'd planning a show on gns3 I'm planning on showing bgp LS and I'm recording those tomorrow just kind of for a taste of,

then day two clouds IGG is on

cloudy stuff all the things that an engineer might care about Cloud not just networking although we have networking conversations on day to Cloud but also

cloud and Cloud operations and kubernetes and that kind of stuff and I co-host that with the heavy networking side with Greg Ferro and Drew Conrad Murray

and then on the day to Cloud side with Ned bellavance if no one knows Ned he's a.

[1:07:48] Published author and all-around super nerd for all things related to cloudy really is I learned something from that every single week and a for anything else you can go to Ethan see Banks.com there's an about page there and you can find the book that I co-wrote with Russ White.

Courses that I published and and ways to get in touch with me and follow me and so on awesome I will have all of those links there's a lot of them I don't have all those links in the show notes

um for all of you to jump on and in consumed Ethan's content and packet pushers content and then you can always keep that conversation going with Ethan on anything that we talked about today Ethan I just want to say this I really appreciate it man thanks for joining me today I really appreciate it I hope you have a great day

hey friends it's going to wrap up today's show thanks you all for listening this is a

episode 70 so it's zigbits dot tax / 7 0 if you want to go join the look at the show notes add your comments you can find us on all the socials that's Twitter LinkedIn and Facebook you just search for Zig underscore zsiga for me or a zigbits z IG

bi TS if you have any questions comments concerns let us know you could email me at Zig at the zigbits tech and until next time bye for now.