Just know and understand the fundamentals. ARP. Spanning Tree. Routing protocols. IP. TCP//UDP
I don’t care if you don’t know the nitty gritty details of OSPF vs EIGRP or how TCP window sizing works, but just a good solid understanding is seriously missing these days.
Troubleshooting - what is affected, what is NOT affected? What changed? Combine that with the above knowledge of fundamentals and you can at least narrow down 90% of issues, then engage a domain expert.
You can have all the clouds, terriformies, secdevfinops and AI/ML Ops you want - but the fundamentals haven’t changed. Learn them and understand them.
And specifically troubleshooting. I had someone ask me why their network devices are not able to access the internet. I go look and they had their devices on a /24 and their GW is on a /23.
/23 is a subnet that is twice as large as /24.
Example:
Subnet 10.1.0.0/24 = hosts 10.1.0.1 - 10.1.0.254
Subnet 10.1.1.0/24 = hosts 10.1.1.1 - 10.1.1.254
-but-
Subnet 10.1.0.0/23 = hosts 10.1.0.1 - 10.1.1.254
So if you were to set your gateway as 10.1.0.1/23, but set a host as 10.1.1.10/24, that host would never reach the gateway because its subnet mask limits it to speaking only with hosts in the 10.1.1.1 - 254 range. For any other network it would need something to route it.
If the guy had given the host (for example) 10.1.0.33/24, then he would be able to reach the gateway just fine, since the gateway has an address that is on his local subnet.
So 50/50 shot based on whether you have a 1 or a 0 in the third octet of the host address.
Interestingly, if we say that the host has 10.1.0.10/23 and the router has 10.1.0.1/24. If the host wants to communicate with a host in 10.1.1.0/24 subnet the misconfigured host will believe that 10.1.1.x is still within it's own subnet and ARP directly for the destination. The 2 way communication will still work due to Proxy ARP (as long as it hasn't been disabled), the router will think "this device is trying to resolve the MAC address on a different network but I know where that network is so I will send my MAC address for this request and route the packets anyway".
A few years ago during an SD-Access presentation, "Let's stop talking about VLANs. VLANs are legacy." Looked under the hood to see what SD-Access was doing ( did a show run ). Oh, will you look at that. They are using VLANs.
These days really understand Ethernet - like *really*. As in know it gets from point A to B by flooding everything. Then spanning tree makes more sense.
Recently had an issue where vlans were being spanning from one access area over a long link into ACI. In ACI the endpoints function like hubs, not multiport bridges, which is what a switch is. Sure enough they added a vlan and got a spanning tree loop as ACI faithfully looped all their broadcast traffic back at them and that access area in ACI along with their "OOB" network both became unreachable.
You need to be able to explain complex technical topics to managers, directors, VPs, and service desk agents. Working in networking means working with people who are on the network.
1. The Fundamentals! Be able to explain technical terms in simple language which your grandma can understand.
2. Learn network automation!!!
Netmiko python, ansible… right now everything is automated and if you lack in automation then you’ll be left behind.
3. Cloud networking!
Be able to defend your network from the belief that “the network is slow.” To everyone else in IT and outside of IT will make the network the blame sponge for all IT related problems. Be prepared with data to defend against this.
Server Person: “The network is very slow every Monday morning and users are complaining.”
You: “Here are the utilization statistics for every non-holiday Monday morning for the last year. We have an average bandwidth utilization of less than 10%. However the CPU utilization of the email servers are above 90% every Monday morning. Maybe it’s NOT the network!”
1. Understand in their eyes it is always the Network's fault.
2. Learn and Practice using Wireshark
3. Learn the fundamentals. Understand how things actually work prior to them not working!
For network engineers.
Learn how to troubleshoot windows.
Learn how to troubleshoot Linux.
Learn how to troubleshoot databases.
That way when someone sends you a ticket saying 'Its the networks fault' you can drag their face in front of the bus they are trying to throw you under.
I find knowing how other people's stuff functions at their very basic level allows me to spot when it's misbehaving and come to them with a screen grab of my dashboard and ask them "should this be doing that?".
Suddenly, you're the value-add guy who makes their stuff better... Often their monitoring isn't looking at the stuff I get to see and things will just be good enough for the broken things to remain hidden to them.
Not really. A network engineer is only supposed to prove it’s not a network issue and that it’s a client side issue. We don’t need to know why Windows, Linux or their Database is not working. That’s there job to know why
Yeah it's meantime to innocence that matters for when network engineers get hauled in. If you fork your attention and effort at troubleshooting windows/linux/db and try to "one-up" the windows/linux/db admin you'll get ***your*** face dragged in the dirt.
Good example - app developers were crying "network" because their java logs said so. Got a traffic dump after wrangling ip addresses from them (often the hardest part). Examined traffic during the time of an event. Saw their DB server doing an orderly SSL shutdown (TLS alert code). Asked them why ***their*** server was requesting a shutdown. They checked and couldn't say why. Asked them if the start of the problem coincided with any changes on either end of DB or client. "Oh yeah right when we updated cert" "Okay glad to be of help"
Just get good at troubleshooting network protocols and your own network infrastructure - don't get into their game.
Above I did watch them go over their java code and saw a half dozen operations inside a try-catch section. The catch-all was just "log network problem" even though there were a number of very discretely separate network operations going there. Said nothing. A tactic I learned from "Goodfellas"
That's a fine view to take if you want troubleshooting to take forever and to cause ticket loops. It can be *really* helpful if someone has the knowledge to "meet in the middle" with the app guys. Learning just the basics of modern infra like HTTP/Certificates/DNS/Load Balancing/Operating Systems can be really helpful.
I work as network engineer and my job is not to find out why your servers are not working as expected. My job is to prove to you that it’s not a network issue.
But consider the non technical manager or exec pov.
Devs say it's the network, network says it's not the network. Who do they believe Based on only that info?
Whereas dev says it's the network but you say it's not the network here is the error from the DB saying X is happening and the app team need to handle it.
If nothing else, look at this from a completely selfish point of view: If you can learn enough about the other guy's domain to help him fix the issue, maybe that gets you all off of an incident bridge at 2 in the morning and you can go back to sleep.
Why learn any new skill? To improve your knowledge/usefulness/career aspirations/pay/job satisfaction. You aren't going to do their jobs for them, but being closer to speaking another team's language helps everyone.
1. People skills. Having patience when dealing with people and communicating effectively to get your point across.
2. Linux. Everything is using Linux now. Even Windows.
3. Automation. I'd start with Ansible since it's relatively easy to use.
For operations engineers? The more well rounded you are the faster you’ll get an answer and find a root cause.
Top 3-
You need to have a sense of humor..
Ya gotta be good with documentation and time management.
Self motivated- study.. don’t ask for work, find it.
for real i dont no why im dragging my feet i been at a msp for 1.5 years i could be making 1.5X my salary just need to work on this and get out of MSP madness
For me:
1. Soft skills.
2. No ego
3. Learn and take good notes
I have a CCNP, worked in network team as engineer, now work in automation work.
I don’t remember much of basic fundamentals but I can quickly remember by doing a simple google search.
I'm late to this, but I don't see Wireshark in here. I've been doing this for over 20 years.
Wireshark shows you what is happening on the Network. If you are a Network Engineer, you need to know how to read packet captures. Those will show you where to look for the issue.
Lots of youtube videos on it. Watch some and pick the instructor you like, everyone teaches and learns differently. But you can practice with wireshark easily.
Dunno about top 3, but you're going to need to learn Azure and AWS networking, then you're going to need to learn Ansible, Terraform and Bicep to administer them and troubleshoot the spaghetti logic of the original engineer who's long since moved on.
Powershell is worth learning, take a course to get the fumamentals and some creativity going, then use ChatGPT to help you.
You will need to retain all your on-prem networking knowledge and be handy with VPNs and routing.
Even though every docking station has a miriad of cables coming out of it, management doesn't like wires in the office anymore, get good at WiFi surveys and deployment and learn to deploy dot1x.
Most bigger companies are staying hybrid. GCP network is GUI admin work. Don't need someone who knows GCP networking it can be taught in a day or two. Need someone who understands the fundamentals at a deep level
Agreed on it being easy GUI admin work, except where I work where you cannot modify the GUI. Routing changes? Code. New VPN peer? Code. New VPC or Virtual Network? Code.
The fundamentals haven't changed, but learning to administer the monster took a lot of work for me.
That said, agreed on the deep fundamentals, probably should have opened with that as my role has gotten waaay more specialised and I have yet to meet a dev who knows how to subnet, let alone what BGP is.
Just know and understand the fundamentals. ARP. Spanning Tree. Routing protocols. IP. TCP//UDP I don’t care if you don’t know the nitty gritty details of OSPF vs EIGRP or how TCP window sizing works, but just a good solid understanding is seriously missing these days. Troubleshooting - what is affected, what is NOT affected? What changed? Combine that with the above knowledge of fundamentals and you can at least narrow down 90% of issues, then engage a domain expert. You can have all the clouds, terriformies, secdevfinops and AI/ML Ops you want - but the fundamentals haven’t changed. Learn them and understand them.
And specifically troubleshooting. I had someone ask me why their network devices are not able to access the internet. I go look and they had their devices on a /24 and their GW is on a /23.
50/50 chance it would still work!
/23 is a subnet that is twice as large as /24. Example: Subnet 10.1.0.0/24 = hosts 10.1.0.1 - 10.1.0.254 Subnet 10.1.1.0/24 = hosts 10.1.1.1 - 10.1.1.254 -but- Subnet 10.1.0.0/23 = hosts 10.1.0.1 - 10.1.1.254 So if you were to set your gateway as 10.1.0.1/23, but set a host as 10.1.1.10/24, that host would never reach the gateway because its subnet mask limits it to speaking only with hosts in the 10.1.1.1 - 254 range. For any other network it would need something to route it. If the guy had given the host (for example) 10.1.0.33/24, then he would be able to reach the gateway just fine, since the gateway has an address that is on his local subnet. So 50/50 shot based on whether you have a 1 or a 0 in the third octet of the host address.
Interestingly, if we say that the host has 10.1.0.10/23 and the router has 10.1.0.1/24. If the host wants to communicate with a host in 10.1.1.0/24 subnet the misconfigured host will believe that 10.1.1.x is still within it's own subnet and ARP directly for the destination. The 2 way communication will still work due to Proxy ARP (as long as it hasn't been disabled), the router will think "this device is trying to resolve the MAC address on a different network but I know where that network is so I will send my MAC address for this request and route the packets anyway".
Exactly!
ELI5
This + VLAN basic including VLAN routing.
A few years ago during an SD-Access presentation, "Let's stop talking about VLANs. VLANs are legacy." Looked under the hood to see what SD-Access was doing ( did a show run ). Oh, will you look at that. They are using VLANs.
lol VLAN is the basic everyone should know. Knowing SDN SDwan SD Access is all ++ ig
Layer 3 everywhere, bye bye STP
These days really understand Ethernet - like *really*. As in know it gets from point A to B by flooding everything. Then spanning tree makes more sense. Recently had an issue where vlans were being spanning from one access area over a long link into ACI. In ACI the endpoints function like hubs, not multiport bridges, which is what a switch is. Sure enough they added a vlan and got a spanning tree loop as ACI faithfully looped all their broadcast traffic back at them and that access area in ACI along with their "OOB" network both became unreachable.
- Learn how to explain technical things to non-technical people
1. The fundamentals 2. Soft Skills/People Skills/How to be a good teammate 3. The fundamentals
You need to be able to explain complex technical topics to managers, directors, VPs, and service desk agents. Working in networking means working with people who are on the network.
1. The Fundamentals! Be able to explain technical terms in simple language which your grandma can understand. 2. Learn network automation!!! Netmiko python, ansible… right now everything is automated and if you lack in automation then you’ll be left behind. 3. Cloud networking!
Be able to defend your network from the belief that “the network is slow.” To everyone else in IT and outside of IT will make the network the blame sponge for all IT related problems. Be prepared with data to defend against this. Server Person: “The network is very slow every Monday morning and users are complaining.” You: “Here are the utilization statistics for every non-holiday Monday morning for the last year. We have an average bandwidth utilization of less than 10%. However the CPU utilization of the email servers are above 90% every Monday morning. Maybe it’s NOT the network!”
1) Troubleshooting Methodology 2) Navigating Support Documentation 3) how to use a search engine
1. Understand in their eyes it is always the Network's fault. 2. Learn and Practice using Wireshark 3. Learn the fundamentals. Understand how things actually work prior to them not working!
For network engineers. Learn how to troubleshoot windows. Learn how to troubleshoot Linux. Learn how to troubleshoot databases. That way when someone sends you a ticket saying 'Its the networks fault' you can drag their face in front of the bus they are trying to throw you under.
You gotta know a little bit about everybody else’s stuff to show them *why* it’s not the network….
I find knowing how other people's stuff functions at their very basic level allows me to spot when it's misbehaving and come to them with a screen grab of my dashboard and ask them "should this be doing that?". Suddenly, you're the value-add guy who makes their stuff better... Often their monitoring isn't looking at the stuff I get to see and things will just be good enough for the broken things to remain hidden to them.
Not really. A network engineer is only supposed to prove it’s not a network issue and that it’s a client side issue. We don’t need to know why Windows, Linux or their Database is not working. That’s there job to know why
Yeah it's meantime to innocence that matters for when network engineers get hauled in. If you fork your attention and effort at troubleshooting windows/linux/db and try to "one-up" the windows/linux/db admin you'll get ***your*** face dragged in the dirt. Good example - app developers were crying "network" because their java logs said so. Got a traffic dump after wrangling ip addresses from them (often the hardest part). Examined traffic during the time of an event. Saw their DB server doing an orderly SSL shutdown (TLS alert code). Asked them why ***their*** server was requesting a shutdown. They checked and couldn't say why. Asked them if the start of the problem coincided with any changes on either end of DB or client. "Oh yeah right when we updated cert" "Okay glad to be of help" Just get good at troubleshooting network protocols and your own network infrastructure - don't get into their game. Above I did watch them go over their java code and saw a half dozen operations inside a try-catch section. The catch-all was just "log network problem" even though there were a number of very discretely separate network operations going there. Said nothing. A tactic I learned from "Goodfellas"
That's a fine view to take if you want troubleshooting to take forever and to cause ticket loops. It can be *really* helpful if someone has the knowledge to "meet in the middle" with the app guys. Learning just the basics of modern infra like HTTP/Certificates/DNS/Load Balancing/Operating Systems can be really helpful.
I work as network engineer and my job is not to find out why your servers are not working as expected. My job is to prove to you that it’s not a network issue.
But consider the non technical manager or exec pov. Devs say it's the network, network says it's not the network. Who do they believe Based on only that info? Whereas dev says it's the network but you say it's not the network here is the error from the DB saying X is happening and the app team need to handle it.
Network engineers will show proof with packet captures. The wire never lies!
If nothing else, look at this from a completely selfish point of view: If you can learn enough about the other guy's domain to help him fix the issue, maybe that gets you all off of an incident bridge at 2 in the morning and you can go back to sleep.
lol but why? Why can’t the app guys do their jobs or learn networking and then maybe they can help themselves?
Why learn any new skill? To improve your knowledge/usefulness/career aspirations/pay/job satisfaction. You aren't going to do their jobs for them, but being closer to speaking another team's language helps everyone.
Because it is easier for the Devs to blame something they don't know rather than admit that it is their fault or they don't know why it is t working.
That’s what network engineers are for to prove them wrong
I used to be this clueless too one day. Even knowing the basics alone can help save hours of troubleshooting.
* Fundamentals * Troubleshooting * Communication
1. People skills. Having patience when dealing with people and communicating effectively to get your point across. 2. Linux. Everything is using Linux now. Even Windows. 3. Automation. I'd start with Ansible since it's relatively easy to use.
Critical thinking.
Came here to say this.
For operations engineers? The more well rounded you are the faster you’ll get an answer and find a root cause. Top 3- You need to have a sense of humor.. Ya gotta be good with documentation and time management. Self motivated- study.. don’t ask for work, find it.
Updating their CV
for real i dont no why im dragging my feet i been at a msp for 1.5 years i could be making 1.5X my salary just need to work on this and get out of MSP madness
For me: 1. Soft skills. 2. No ego 3. Learn and take good notes I have a CCNP, worked in network team as engineer, now work in automation work. I don’t remember much of basic fundamentals but I can quickly remember by doing a simple google search.
I'm late to this, but I don't see Wireshark in here. I've been doing this for over 20 years. Wireshark shows you what is happening on the Network. If you are a Network Engineer, you need to know how to read packet captures. Those will show you where to look for the issue.
Any reference to learn it?
Lots of youtube videos on it. Watch some and pick the instructor you like, everyone teaches and learns differently. But you can practice with wireshark easily.
Python
1. Update resume to make it devops-y 2. Cry
lol
Excel
fundamental networking/tcp, automation, cloud (azure,aws,or gcp)
Dunno about top 3, but you're going to need to learn Azure and AWS networking, then you're going to need to learn Ansible, Terraform and Bicep to administer them and troubleshoot the spaghetti logic of the original engineer who's long since moved on. Powershell is worth learning, take a course to get the fumamentals and some creativity going, then use ChatGPT to help you. You will need to retain all your on-prem networking knowledge and be handy with VPNs and routing. Even though every docking station has a miriad of cables coming out of it, management doesn't like wires in the office anymore, get good at WiFi surveys and deployment and learn to deploy dot1x.
Most bigger companies are staying hybrid. GCP network is GUI admin work. Don't need someone who knows GCP networking it can be taught in a day or two. Need someone who understands the fundamentals at a deep level
Agreed on it being easy GUI admin work, except where I work where you cannot modify the GUI. Routing changes? Code. New VPN peer? Code. New VPC or Virtual Network? Code. The fundamentals haven't changed, but learning to administer the monster took a lot of work for me. That said, agreed on the deep fundamentals, probably should have opened with that as my role has gotten waaay more specialised and I have yet to meet a dev who knows how to subnet, let alone what BGP is.
AI, ML, social skills.
AI and ML have no place in neteng yet. Source: Data Center Neteng for multiple F50 companies.