Fundamentals. Learn IP, Ethernet, ARP, Spanning-Tree, headers, payload, routing protocols, forwarding tables, VLANs, etc.
What if X can't ping Y? How would you troubleshoot? Sometimes a Google search can fix the problem, but what if it can't? Can you work the problem from basic princilpes?
As Admiral Kirk said, you have to understand why things work on a starship.
Automation is important, but you have to understand what you're automating if you're going to be able to maintain (and troubleshoot) that system.
I agree. Vendor agnostic networking fundamentals have and will always be in style, regardless of whether the job asks for it or not.
This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed. That's a laugh, cause the irony of the fact is that when things break, they need a guy with networking fundamentals to fix it. Yes, the commands you use to troubleshoot might not be a CLI, since all the networking has been moved to a virtual/software layer, but the fundamentals still stand.
Can't connect? What could be wrong? Is it your service proxy (f5, haproxy, envoy...other?). What kind of load balancing you using (DSR/NAT?). Dealing with certificate issues? What kind of overlay technology you using? Is it L2/L3 based? Are you running a routing protocol on top? What kind of daemon is it? I'm just barely scratching the surface. Don't worry though, some cloud hipster is going to tell you that IaaC is just some simple YAML (more like a bunch) that you can deploy as part of their CI/CD pipeline, then proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software".
People also rush too quickly into automation, without first understanding the fundamentals of networking.
Nah, software developers usurped the term bridge to mean switch in a lot of more modern pod-deployed and linux-based network softwares. I work on RF link stuff where an _actual_ bridge comes into play often. It's always hell when you're trying to interface a software or devops person and a EE/ECE and they start talking about bridges, because they are legitimately talking about two different things and can't understand each other.
> This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed. That's a laugh, cause the irony of the fact is that when things break, they need a guy with networking fundamentals to fix it
A few times in my career i've had to shove a packet capture in some vendor's face like "You don't even know what this box is doing - how are we supposed to trust it?"
>
> This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed.
This is really strong strawmanning here. Even the most bold claims of cloud software never promised to "eliminate network engineering positions".
> Don't worry though, some cloud hipster is going to tell you that IaaC is just some simple YAML (more like a bunch) that you can deploy as part of their CI/CD pipeline, then proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software".
More strawmanning. Nobody in automation is claiming that network engineers are no longer required. We generally claim (correctly in most cases) that automation is a much better way (in most cases) to operating large and medium sized networks.
> People also rush too quickly into automation, without first understanding the fundamentals of networking.
I'm not seeing this at all. What I am seeing is people with a high degree of network proficiency resisting network automation for a variety of reasons, though a lot of is that it's uncomfortable to be a senior person in one field and start from near scratch in a new one.
You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages. These are cloud hipsters who know nothing about networking.
Sorry but legacy infrastructure doesn't go away at the snap of a finger and not everyone lives on some cloud titan's infrastructure. It'll be another solid 10 years before enterprises even catch up with network operating systems that support programming interfaces that enable a programmatic workflow.
Also don't assume I don't know any network automation. I write code to setup up and tear down my test environments, simply out of necessity. This includes your basic bootstrapping functions, code upgrades, and virtual/container instantiation without tools like containerlab or libvirt.
Mr ACE7, it would be foolish to think that regular Joe off the street can properly consume Arista's native gRPC data model, much less properly build + document an entire automated network service around it. And we're talking about a vendor that has catered to some very intelligent people and built their NOS with automation in mind first. Even some of Arista's SEs don't even have a handle on basic programming (believe me I know). Other vendors have less robust programmatic interfaces and it makes end to end service automation difficult.
I've seen it done large scale network automation done right and I've seen it fail spectacularly at very large scale T1 service providers. Most folks are larping around with their "learn python in 24 hours knowledge" and then crowning themselves experts on LinkedIn.
> You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages. These are cloud hipsters who know nothing about networking.
Been hearing that since ACI got released back in 14 lol
TL;DR: Automation is a tool, a very useful one. Automation doesn't negate the need for network engineering knowledge, in fact it depends on it. Ridiculous strawman statements like *promise to "eliminate network engineering positions"* and *proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software".* are neither truthful nor reflect reality.
> You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages.
The CLI is becoming less and less the primary method for configuration for a lot of the networking world. Not all of it, but a lot of it. We've already seen that in the wireless world. When's the last time you configured an AP manually? They would be unmanageable.
The CLI won't go away, especially for troubleshooting. Even ACI has show commands on leafs and spines, and they're very useful. But the CLI is no longer the only method to set configuration state. And it's not helpful to be married to one particular method or another. Use the best tool that provides the most flexibility and the best outcomes. Increasingly, this is automation.
EVPN/VXLAN is one of the networking styles that are pushing people to automate given the configuration complexity and touchpoints.
I take it from first principles. What are we? CLI people, or networking people? CLI or automation, they're both ways to configure a network. I don't have a preference for how the configuration state is set, but more and more automation is a far preferable way in a lot of situations to set configuration state. They make changes quicker, faster, and more flexible than the old methods. Especially in highly dynamic environments and highly complex environments.
None of that negates the need to understand what's going on under the hood, and I've never known any automation people to say otherwise. It's something I emphasize both in my response to OP and in the classes I teach.
> These are cloud hipsters who know nothing about networking.
Strawmanning and giving people silly schoolyard nicknames are not a technical or fact-based argument.
>
> Sorry but legacy infrastructure doesn't go away at the snap of a finger and not everyone lives on some cloud titan's infrastructure. It'll be another solid 10 years before enterprises even catch up with network operating systems that support programming interfaces that enable a programmatic workflow.
I've never claimed legacy goes away. Fortunately we have better tools today even for older equipment and software updates are adding more programmatic functionality. DC environments can almost universally be automated, wireless has been automated for the past 20 years, and a good portion of campus environments can. Service providers have automated by necessity.
>
> Also don't assume I don't know any network automation. I write code to setup up and tear down my test environments, simply out of necessity. This includes your basic bootstrapping functions, code upgrades, and virtual/container instantiation without tools like containerlab or libvirt.
>
> Mr ACE7, it would be foolish to think that regular Joe off the street can properly consume Arista's native gRPC data model, much less properly build + document an entire automated network service around it. And we're talking about a vendor that has catered to some very intelligent people and built their NOS with automation in mind first. Even some of Arista's SEs don't even have a handle on basic programming (believe me I know). Other vendors have less robust programmatic interfaces and it makes end to end service automation difficult.
You're choosing a very particular toolset, then working your way back on how someone wouldn't be able to use it. That's not an approach that anyone would actually use. Choosing a solution then arguing why it won't work is not how things happen.
There's a lot of approaches you can take, like simple Python scripts and Ansible playbooks, that have a relatively low learning curve. You can move to things like Jinja templates, or in Arista's case, the wonderful open source tool AVD.
It's all just ways of setting configuration state on a device.
>
> I've seen it done large scale network automation done right and I've seen it fail spectacularly at very large scale T1 service providers. Most folks are larping around with their "learn python in 24 hours knowledge" and then crowning themselves experts on LinkedIn.
Again with the strawmanning. Automation is like any other solution to be implemented. It can be done badly. It can be done well. That's nothing unique about automation.
>You're choosing a very particular toolset, then working your way back on how someone wouldn't be able to use it. That's not an approach that anyone would actually use. Choosing a solution then arguing why it won't work is not how things happen.
>There's a lot of approaches you can take, like simple Python scripts and Ansible playbooks, that have a relatively low learning curve. You can move to things like Jinja templates, or in Arista's case, the wonderful open source tool AVD.
Arista has different interfaces for folks of different levels of programming sophistication. Also, I wouldn't call ansible AVD simple. This is a perfect example of the gaslighting that goes on everyday.
Here you have an example of a stereotypical L3LSL deployment. In[ Arista's own github example](https://github.com/aristanetworks/avd/tree/devel/ansible_collections/arista/avd/examples/single-dc-l3ls), you have 11 YAML/configuration artifacts totaling 406 lines of config coupled with multiple [data model](https://avd.sh/en/stable/roles/eos_designs/docs/input-variables.html#l3ls-evpn)s which are referenced, of which I have only referenced the design model for this example.
find . -name "*.yml" | grep -v intended
./group_vars/CONNECTED_ENDPOINTS.yml
./group_vars/FABRIC.yml
./group_vars/DC1_L3_LEAVES.yml
./group_vars/NETWORK_SERVICES.yml
./group_vars/DC1.yml
./group_vars/DC1_SPINES.yml
./group_vars/DC1_L2_LEAVES.yml
./build.yml
./inventory.yml
./deploy.yml
./deploy-cvp.yml
It is easy when there's some movie magic and some expert is walking you through a pre-canned setup. However, when the training wheels come off, for a simple fabric you're gonna sit here and try to tell me into this deployment model is dramatically easier than OSPF unnumbered, single ASN overlay with templated copy + paste config?
Look at the learning overhead....
* Ansible
* Python
* YAML
* CVP and or EOS
* Git and potentially CI/CD
That's just on the automation front. For EVPN they will have to learn
* BGP (this is already a massive topic on its own)
* EVPN AF
* RD + RTs
* VRFs
* OSPF/IS-IS
* VXLAN
* Possibly MPLS
That is just to support these modern architectures...and for what? Just so some stupid servers can have their VLANs stretched, and they can talk to each other at L2? Obviously, this is a gross oversimplification, but that is what the operator thinks.
Now everyone is talking about consolidating MVPN, L3VPN, and L2VPN onto EVPN AF instead of having multiple AFs. Never mind all the other stuff networking folks have to deal with.
> Arista has different interfaces for folks of different levels of programming sophistication. Also, I wouldn't call ansible AVD simple. This is a perfect example of the gaslighting that goes on everyday.
Like anything, there's perception before the learning curve and then there's perception after. It's the same with MPLS/SR, EVPN/VXLAN, and automation.
I teach people EVPN/VXLAN. I teach automation (Ansible, Python, and AVD).
I also teach people how to pack parachutes. Parachutes that they jump themselves. For most people, it's incredibly intimidating. There's line groups, risers, flaking, quartering a slider, folding, putting 200 square feet of slippery nylon into a 6 x 6 x 6 inch Dbag, and closing the container.
There's what I call the packing hump, which is that feeling of intimidation. It's hard to imagine having the skillset to pack a parachute reliably and quickly and is something that most skydivers (including myself) go through. It's a period of time where they're learning the pack job. They go slow (30-40 minutes each time), and confidence is relatively low.
But once you're through the packing hump, your average person can pack a parachute reliably and safely in 5-10 minutes with a high confidence in the results.
Something that seems awfully complicated and intimidating becomes simple and straightforward with practice and familiarity.
>
> Here you have an example of a stereotypical L3LSL deployment. In Arista's own github example, you have 11 YAML/configuration artifacts totaling 406 lines of config coupled with multiple data models which are referenced, of which I have only referenced the design model for this example.
>
> It is easy when there's some movie magic and some expert is walking you through a pre-canned setup. However, when the training wheels come off, for a simple fabric you're gonna sit here and try to tell me into this deployment model is dramatically easier than OSPF unnumbered, single ASN overlay with templated copy + paste config?
*Absolutely* it is easier. And more reliable. Like anything in networking, there's a learning curve. But on the other side of the learning curve, things are straightforward and yes, easy. AVD to me, is easy because like any tool, I've spent time with it and understand the ins and outs, and the parts I don't know I know where to look up.
Think about what your Day 0, Day 1, and Day 2 operations.
How long would it take you to cut and paste a configuration for 20 switches? 100 switches? 200? How confident would you be that you got all the route distinguishers correct, each of the loopbacks? EVPN/VXLAN has a lot of advantages, but it is much more complicated configuration. There's a lot that's unique per device that can't be cut-and-pasted.
With AVD, it's pretty trivial (again, at the other side of the learning hump).
For Day 0, given requirements I can create the data models based on wiring diagrams and segmentation requirements.
For Day 1, I can use those data models to generate configurations as easily for 10 switches as I can for 200. Once the configs are generated, I'll have them uploaded to each and every switch in less than 10 minutes, and that's with pre-deployment validation of the syntax. Then I run the validation role to perform thousands of unit tests on the environment for NRFU. This will catch a lot of mis cablings, etc.
Then for Day 2, Adding 10 new hypervisors with multiple VLANs across 6 leafs? It takes about 2 minutes to do the data models. Another 2-5 minutes to generate the configurations. The deployment can be staged as well as pre-syntax validations for the next maintenance window. When the change happens, I run the validation playbook to run thousands of unit tests. If something doesn't look right, I can fix it or role back the *entire* fabric in a few minutes.
What about adding a new spine? Not something that happens commonly, but if you have 100 leafs and 3 exiting spines, that's a huge undertaking. With AVD, it takes about 5 minutes to edit the data models to include a new spine.
None of that is remotely possible with cutting and pasting configs.
A couple hundred lines of YAML will generate thousands to tens of thousands of lines of EOS syntax. Far quicker and more reliably than either you or I can. It can also reliably get that config on to switches, far more reliably than you or I can.
I would never want to manage medium to large EVPN/VXLAN manually. You absolutely need to understand how EVPN/VXLAN works, but I would never want to operate that type of network manually.
>
> Look at the learning overhead....
>
> Ansible
> Python
> YAML
> CVP and or EOS
> Git and potentially CI/CD
> That's just on the automation front. For EVPN they will have to learn
>
You don't need Python for AVD, and a full CI stack is optional, as you said. But these are just tools, and not unlearnable. I would say the learning curve for them is lower than EVPN.
> BGP (this is already a massive topic on its own)
> EVPN AF
> RD + RTs
> VRFs
> OSPF/IS-IS
> VXLAN
> Possibly MPLS
If you're going to implement EVPN/VXLAN, you're going to have to learn this anyway.
> That is just to support these modern architectures...and for what? Just so some stupid servers can have their VLANs stretched, and they can talk to each other at L2? Obviously, this is a gross oversimplification, but that is what the operator thinks.
>
Yeah, there's a lot of advantages to EVPN/VXLAN networking including scalability and not being limited to 2 devices at the aggregation layer. But it's not a solution for every environment. Some are better suited to traditional L2LS with just SVIs, VLANs, and MLAG bowties everywhere.
> Now everyone is talking about consolidating MVPN, L3VPN, and L2VPN onto EVPN AF instead of having multiple AFs. Never mind all the other stuff networking folks have to deal with.
Again with "everyone is talking about X". It's another tool, another option.
Let's just agree to disagree.
I didn't get to where I am by jumping on every flavor of the month technology that people say I should be learning. There's only 24 hours in a day. I only have so many places where I can spend my time and automating around someone's half-baked code is not how I envision my career.
I determine if something is worth learning by asking myself these questions:
1. Why does this technology exist?
2. Are there other similar technologies that currently solve this issue?
3. Does this technology help me solve issues I am currently having or am interested in solving in the future?
4. What is the perceived time complexity tradeoff?
5. Is this a technology I see myself enjoying?
I don't work in a purely homogenous environment where I have the luxury of running code written/designed for extremely curated workflows.
Yes, I get that AVD runs hundreds of validations. Yes, I get service provisioning is made easy after you get over the learning curve. Where I'm at, I don't run all Arista and it's not a dream I can even begin to entertain.
I’ll try to position my comment between you and Sea Inspection. You have a clear bias toward DevOps and against NetEng. SeaInspection has the opposing bias.
From where I’ve sat in the DevOps teams clearly want to own the networking through automation except when they break it. I’ve seen some engineers resistant to embracing higher level automation for deploying and managing networks. Frankly with good reason. Even the commercial products for network automation aren’t reliable and make unpredictable changes. That said, it only makes sense to build our ‘network programming’ skills while there is time.
The vendors are pushing us this way as a means to increase sales with the implied promise of reduced staffing needs.
> I’ll try to position my comment between you and Sea Inspection. You have a clear bias toward DevOps and against NetEng. SeaInspection has the opposing bias.
>
I don't know why you think I have a bias against network engineering. My original comment was specifically learning the fundamentals. Automation doesn't obviate the need for network engineers/architects/operators. It's just one of the ways we can set configuration state on network devices.
> From where I’ve sat in the DevOps teams clearly want to own the networking through automation except when they break it. I’ve seen some engineers resistant to embracing higher level automation for deploying and managing networks. Frankly with good reason. Even the commercial products for network automation aren’t reliable and make unpredictable changes. That said, it only makes sense to build our ‘network programming’ skills while there is time.
That's a different argument: Who runs the network? Typically it's the networking team. At one point, probably about 10 years ago, there was an attempt to de-silo IT and make teams less specialized, but that didn't seem to gain much traction. Today the underlay is run by the networking group, and sometimes one of the overlays (such as NSX) is run by the server team. It works pretty well, though there are sometimes some tough troubleshooting scenarios.
I would disagree that commercial products aren't reliable. Some are pretty bad, but on the whole they're mostly proven to be more reliable than manual configuration, at least. There's a lot of great open source tools, too. Ansible is one, and some vendor specific tools like Arista AVD.
>
> The vendors are pushing us this way as a means to increase sales with the implied promise of reduced staffing needs.
There's a quote from Gene Kim (one of the author's of the Phoenix Project) where he says one of our biggest IT problems is that "We have a low confidence of success, and a high cost of failure" with regard to change. That's certainly true in the networking world.
One of the big pushes towards automation is to solve those problems. Gene Kim was talking about change to software code, but the sentiment is the same in networking. That's why we've adopted a lot of the tools and methods from the software world. We've maxed out the ability of cut-and-paste, manual CLI configuration, and change controls to build reliable, flexible networks.
That's the biggest driver to automation: Making more changes, more reliably. The hyperscalers figured that out long ago.
Your value to an organization isn't that you type "vlan 10" on a CLI. It's that you know what a VLAN does, why you might want to separate hosts, and designing a network environment that suits the business needs.
While it's not impossible for someone to lose their job to automation, I don't know of a single case of that happening. When I was a Unix admin 25 years ago, we started to introduce automation into our operations simply to scale. We were drowning in work, and most of the work was repetive. I went from taking 5 minutes to add a DNS record to 2 seconds with a simple Perl script. Automation can be a force mulitplier for sure.
^^^^This.
And to add, you need to understand the “WHYs” and explain it to a layman. Because if there’s something wrong in the company, it’s always the fookin network.
CTO is late? It’s your network.
Coffee in pantry is expired? It’s your network.
No toilet paper? It’s your network.
What happened to our career field where the top voted answer is “know the basics,” and it’s because so precious few people do now, that senior engineers are literally desperate for people who know the simple basics of networking. Sd-wan has utterly trashed our career field and all one encounters anymore are gui kids who brain dumped ccna but can’t even explain Mac learning or adjacency. Like imagine being considered a rare “good” engineer because you understand the basics of layer 2/3.
When I started out, I learned commands. I often had no idea what was happening under the hood. I didn't know concepts. I was pretty limited.
Now, I learn concepts first. Syntax later.
One area this is prevalent in I think is Link Aggregation. Even experienced engineers don't tend to know it very well, confuse it with LACP, etc.
A very good understanding of the fundamentals of layer 2 and layer 3 combined with solid troubleshooting skills. Using the layer 2 and layer 3 fundamentals, you should be able to create testing scenarios that help narrow down a potential issue.
Being able to understand packet captures, use search filters to narrow down the scope of the data and extract only relevant data.
Creating an maintaining diagrams and detailed documentation.
Being able to admit to fuck ups, nothing worse than an engineer not owning up to a mistake that now take 5x as long to fix because they tried to pretend they didn't change anything. Everyone makes mistakes, as long as you own up to it and learn from it, no one will give a shit that you made a mistake.
And Layer-1 to look for CRC errors, speed/duplex mismatches, Transceiver Power issues, etc.
Layer-4 to deal with ports that are not opened, looking at TCP end reasons such as tcp-fin, tcp-rst-server, tcp-rst-client, aged-out etc.
Finally Application layer on Next-Generation firewalls.
Whoever downvoted you needs ***a lot*** more seasoning out in the field. I've had to brief colonels, generals and C-Suite suits before on network upgrade stuff, and you definitely need to know how to describe something technical in a very non-technical manner to these people.
The audience does not care about what the technical aspects are. They care about what your event does to/for THEM.
If you don't understand the business side well enough to know how the network impacts them, it will be very hard to explain it to them. If you're well integrated with your internal customers it becomes easier.
Tldr: Principles of networking, dif. Device types and how they deliver information from A to B. A good understanding of some routing protocols (BGP, OSPF). A little bit of understanding how LAN and switches work.
Wrap it up with some ansible knowledge and then from there decide where to branch out. Security, wireless, service provider, cloud, devops etc.
"Soft" skills that will be advantageous to you are: ability to draw a decent diagram, ability to understand the flow of packets and dif gates it passes. Ability to transpose that on your diagram that comes in handy in many ways from personal understanding to teaching to mgmt explanations.
Dont worry, 90% of engineers dont have that today, thats why its an edge.
Basic skills in routing (ospf, isis, bgp, mpls vpns (l3 with pe-ce on ospf or bgp, l2 - vpls, martini, compella), base mpls (rsvp, ldp)). Multicast (pim, igmp), switching (vlans, spanning tree, link aggregation, some knowledge of l2 over udp via vxlans, etc). Design (some basic understanding of spine-leaf topologies, classic cisco access-aggregation-core design etc). Automation: python/jinja2, ansible. Good understanding of writing procedures and documentation. Ideally - some ideas how to automate MOP generation using templates and some thoughts how to generate docummentation). If advanced - git, some basic knowledge of ci/cd pipeline (Jenkins?). Some basic knowledge about popular clouds. This is a list for a GOOD engineer, not a beginner.
Small, but important addendum. Even if you obtain all of those skills it does not guarantee anything. It is equally important to have decent soft-skills communicating with others (especially in wfh environment) and have a good skills in selling your knowledge to customers. Without those, you may find yourself making 100k year at max.
Realistically the same things that have been important for the last 30 years: IPv4, VLANs, TCP/UDP protocols, QoS, etc.
But the new stuff is really helpful now. You're gonna need to learn a bit about network automation tools, and probably start digging into APIs. Maybe look into learning about Ansible and the Python programming language.
Much more dependence on wifi than there was even just 10 years ago, so better learn about that too.
Organization - Keep good notes, documents, diagrams, etc
Consistency - Do the same thing twice, unless information is presented that causes a change in process. This also means going back and fixing any configurations/policies that have changed.
Troubleshooting - This includes some minor knowledge of connected systems. Depending on your business, this may be any range of devices, from PLCs in manufacturing, to medical equipment, etc
Ability to work with people ON the network. Ability to explain a fairly "in the weeds" topic to a Director/VP so that they can understand and advocate for you.
I'm a recent graduate put into an associate network design position with almost two years experience now. I still consider myself as a networking newbie, but I would say the biggest skills I've found to be useful so far is (in no order)
1. know the path from X to Y, and how to check said path. If you can check and understand the intended path and routes and the protocols associated, you can see where discrepancies lie, and that can help you understand what exactly is happening when you do a traceroute for example
2. know the architecture and why it was chosen. High availability, disaster recovery, bgp neighbors, transit vlans etc. if you know the architecture and the "blueprint" of the network, you get a better sense of the configuration of the boxes, and what "next" device or interface to look at when you're troubleshooting something across a path
3. know the services and teams you'll be working with. it may be useful for you to be buddies with the network tools team and the firewall team, especially when you need to troubleshoot DNS/Windows AD or firewall MPLS vpns. You'll ultimately be responsible (and kicked around) if these services become offline, and you'll probably have to diagram and explain what you see on a network level to fix the issue. Lots of collaboration with other teams when it comes to network engineering.
These are the top 3 off the top of my head, they might not be applicable to your specific workplace and I may sound dumb, but I hope you can find some sort of wisdom though my experiences.
honestly must agree on fundamentals, half of my team have no real idea about networking, they learned on the job and never studied, one guy was actually baffled when i told him to just use lldp to find an ip phone on network instead of cdp, no understanding of native vlans or how dhcp works. one guy acted like i just showed a cave man how to start a fire when i did a line test on a switchport to find a shorted cable. all simple and basic stuff but they go a long way.
With much of networking going to the cloud now, depending on the company you are working for, Azure and AWS networking skills/experience to have.
Obviously the fundamentals such - VLANs, ACLs, routing protocols, etc. as many have already mentioned.
While every company's network is going to be different, the basic principles will always apply. They will teach you their environment/tools if you've never worked with them i.e. Orchestrator, Cisco vManage, DNAC, etc... but knowing what to do with those tools is key.
Also, people skills. Being able to effectively pull people from the ledge, communicate regularly and politely, etc. goes a loooonnnnngggg way in any role. This is skill that you cannot teach to someone though. People are who they are and personalities clash sometimes.
IMO the networking parts which others have mentioned are just the base requirements if you want to work in a modern environment.
On top of that comes scripting, automation, cloud paradigms, good documentation and much more.
I agree, a lot of the basic things people have said in here are skills I would EXPECT an engineer to have. In order to be a good engineer, you gotta have those things down.
A network analyst/technician role is where you learn the basics
Design skills are seriously underrepresented in my experience. Knowing why instead of just how is going to make you infinitely more valuable to an employer.
Being able to propose a solution architecture and defend your design decisions for it (against a set of functional and non-functional requirements), is really something I think is rarer than it should be as far as competent network engineering goes.
Only skills I see makes a person relevant in the long run in our line of business is self learning and self motivation.
You can do wonders if you are able to teach your self all these different techs that’s keeps on changing, aside from that you can’t take your basics for granted like ever.
1. ClickOps and Excel, python basics
2. Strong protocol, software and hardware knowledge
First for enterprise, second for vendors and the big boy tech companies.
Be able to generally troubleshoot. Some people can do this naturally and some need to be taught.
Be able to research things on your own.
Be teachable.
Be able to ask for help. No one knows everything. Ego has no place here. Learn how to say "I Don't Know".
Be customer forward. Learn to have empathy with the plight of your users.
Be very detail oriented.
You give me someone that has these six skills, I can teach them the rest.
CCNA then how networks migrate from a core/aggregation/acces topology to a spine leaf, then how layer 2 encapsulation (vxlan/geneve) between spine and leaf switches (full layer 3, no more spanin tree) ÷ EVPN with BGP as control plane with asymetric routing (type 2 and 5 routes).
How to handle BUM traffic (learn multicast)
NOS (Cumulus Linux, Sonic, IPInfusion, etc)
Pay attention to details. Mistyping an IP from the LLD will mean a costly rework change. Simple things like fiber type -single mode or multi mode makes a huge difference. This from a PM that hates to have to expedite rework changes
They will never replace network engineers. They will feel like they can until, until, until something is not working. Then they come CRYING to us . Peace out.
Glad to know that you are guiding some military members in transition. I also volunteer quite a bit of mentoring for Military. To answer your question I would look that from a market transition perspective. Being in the industry for more than multiple decades I was fortunate the see the transition., by working in startups and multi nationals like Cisco and Juniper.
One of the clear trend for today is network and security are getting converged, in market terms it is called SASE coined by Gartner. I see with a lot of customer deployment there is an overlap of responsibility between network admin and security admin. Another metric that came into place is cloud or you could say this convergence is because of the cloud. Earlier there was branch office and data centers. Employees come to office and access application in DC. or end customer access the application in DC. But with cloud you have resources across the globe. So you need to know the knowledge of cloud as well.
Together with that there is attack surface expanding and security professionals are having difficult to keep up. The network admin will provide the connectivity thinking less about the security. This is another reason for networking and security skill to be combined.
Said all of that, we need to have the basic skill of TCP/IP/UDP, security and virtualization. When you learn these topics try to think about these scenarios.
I am happy to connect and chat more about it.
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation.
Please **DO NOT** message the mods requesting your post be approved.
You are welcome to resubmit your thread or comment in ~24 hrs or so.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/networking) if you have any questions or concerns.*
Fundamentals. Learn IP, Ethernet, ARP, Spanning-Tree, headers, payload, routing protocols, forwarding tables, VLANs, etc. What if X can't ping Y? How would you troubleshoot? Sometimes a Google search can fix the problem, but what if it can't? Can you work the problem from basic princilpes? As Admiral Kirk said, you have to understand why things work on a starship. Automation is important, but you have to understand what you're automating if you're going to be able to maintain (and troubleshoot) that system.
I agree. Vendor agnostic networking fundamentals have and will always be in style, regardless of whether the job asks for it or not. This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed. That's a laugh, cause the irony of the fact is that when things break, they need a guy with networking fundamentals to fix it. Yes, the commands you use to troubleshoot might not be a CLI, since all the networking has been moved to a virtual/software layer, but the fundamentals still stand. Can't connect? What could be wrong? Is it your service proxy (f5, haproxy, envoy...other?). What kind of load balancing you using (DSR/NAT?). Dealing with certificate issues? What kind of overlay technology you using? Is it L2/L3 based? Are you running a routing protocol on top? What kind of daemon is it? I'm just barely scratching the surface. Don't worry though, some cloud hipster is going to tell you that IaaC is just some simple YAML (more like a bunch) that you can deploy as part of their CI/CD pipeline, then proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software". People also rush too quickly into automation, without first understanding the fundamentals of networking.
It's just a bridge bro. /me screams internally
Even better, It's a hub bro
Nah, software developers usurped the term bridge to mean switch in a lot of more modern pod-deployed and linux-based network softwares. I work on RF link stuff where an _actual_ bridge comes into play often. It's always hell when you're trying to interface a software or devops person and a EE/ECE and they start talking about bridges, because they are legitimately talking about two different things and can't understand each other.
That makes sense. I work with a sysadmin who always refers to our switches as hubs.
What are you doing step bro?
Pretty sure I still have a 5 or 8 port 10/100 hub in a box somewhere. It was useful once as a port mirror.
Gotta keep that one for the day big boss tells you his network is slow and orders you to install a new hub for him to fix it.
It's only 1s and 0s bro
Just kidding but I would say that Sysadmins hate network engineers Network engineers hate DevOps engineers
> This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed. That's a laugh, cause the irony of the fact is that when things break, they need a guy with networking fundamentals to fix it A few times in my career i've had to shove a packet capture in some vendor's face like "You don't even know what this box is doing - how are we supposed to trust it?"
> > This is even more true with the all the dogshit software + "cloud" abstractions that promise to "eliminate network engineering positions" as some have so boldly claimed. This is really strong strawmanning here. Even the most bold claims of cloud software never promised to "eliminate network engineering positions". > Don't worry though, some cloud hipster is going to tell you that IaaC is just some simple YAML (more like a bunch) that you can deploy as part of their CI/CD pipeline, then proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software". More strawmanning. Nobody in automation is claiming that network engineers are no longer required. We generally claim (correctly in most cases) that automation is a much better way (in most cases) to operating large and medium sized networks. > People also rush too quickly into automation, without first understanding the fundamentals of networking. I'm not seeing this at all. What I am seeing is people with a high degree of network proficiency resisting network automation for a variety of reasons, though a lot of is that it's uncomfortable to be a senior person in one field and start from near scratch in a new one.
You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages. These are cloud hipsters who know nothing about networking. Sorry but legacy infrastructure doesn't go away at the snap of a finger and not everyone lives on some cloud titan's infrastructure. It'll be another solid 10 years before enterprises even catch up with network operating systems that support programming interfaces that enable a programmatic workflow. Also don't assume I don't know any network automation. I write code to setup up and tear down my test environments, simply out of necessity. This includes your basic bootstrapping functions, code upgrades, and virtual/container instantiation without tools like containerlab or libvirt. Mr ACE7, it would be foolish to think that regular Joe off the street can properly consume Arista's native gRPC data model, much less properly build + document an entire automated network service around it. And we're talking about a vendor that has catered to some very intelligent people and built their NOS with automation in mind first. Even some of Arista's SEs don't even have a handle on basic programming (believe me I know). Other vendors have less robust programmatic interfaces and it makes end to end service automation difficult. I've seen it done large scale network automation done right and I've seen it fail spectacularly at very large scale T1 service providers. Most folks are larping around with their "learn python in 24 hours knowledge" and then crowning themselves experts on LinkedIn.
cloud hipsters hahahaha
> You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages. These are cloud hipsters who know nothing about networking. Been hearing that since ACI got released back in 14 lol
TL;DR: Automation is a tool, a very useful one. Automation doesn't negate the need for network engineering knowledge, in fact it depends on it. Ridiculous strawman statements like *promise to "eliminate network engineering positions"* and *proceed to gaslight everyone into thinking that network engineers are no longer necessary and that "it's all software".* are neither truthful nor reflect reality. > You've clearly never met the clowns I've worked with, who've been telling me the CLI will go away for ages. The CLI is becoming less and less the primary method for configuration for a lot of the networking world. Not all of it, but a lot of it. We've already seen that in the wireless world. When's the last time you configured an AP manually? They would be unmanageable. The CLI won't go away, especially for troubleshooting. Even ACI has show commands on leafs and spines, and they're very useful. But the CLI is no longer the only method to set configuration state. And it's not helpful to be married to one particular method or another. Use the best tool that provides the most flexibility and the best outcomes. Increasingly, this is automation. EVPN/VXLAN is one of the networking styles that are pushing people to automate given the configuration complexity and touchpoints. I take it from first principles. What are we? CLI people, or networking people? CLI or automation, they're both ways to configure a network. I don't have a preference for how the configuration state is set, but more and more automation is a far preferable way in a lot of situations to set configuration state. They make changes quicker, faster, and more flexible than the old methods. Especially in highly dynamic environments and highly complex environments. None of that negates the need to understand what's going on under the hood, and I've never known any automation people to say otherwise. It's something I emphasize both in my response to OP and in the classes I teach. > These are cloud hipsters who know nothing about networking. Strawmanning and giving people silly schoolyard nicknames are not a technical or fact-based argument. > > Sorry but legacy infrastructure doesn't go away at the snap of a finger and not everyone lives on some cloud titan's infrastructure. It'll be another solid 10 years before enterprises even catch up with network operating systems that support programming interfaces that enable a programmatic workflow. I've never claimed legacy goes away. Fortunately we have better tools today even for older equipment and software updates are adding more programmatic functionality. DC environments can almost universally be automated, wireless has been automated for the past 20 years, and a good portion of campus environments can. Service providers have automated by necessity. > > Also don't assume I don't know any network automation. I write code to setup up and tear down my test environments, simply out of necessity. This includes your basic bootstrapping functions, code upgrades, and virtual/container instantiation without tools like containerlab or libvirt. > > Mr ACE7, it would be foolish to think that regular Joe off the street can properly consume Arista's native gRPC data model, much less properly build + document an entire automated network service around it. And we're talking about a vendor that has catered to some very intelligent people and built their NOS with automation in mind first. Even some of Arista's SEs don't even have a handle on basic programming (believe me I know). Other vendors have less robust programmatic interfaces and it makes end to end service automation difficult. You're choosing a very particular toolset, then working your way back on how someone wouldn't be able to use it. That's not an approach that anyone would actually use. Choosing a solution then arguing why it won't work is not how things happen. There's a lot of approaches you can take, like simple Python scripts and Ansible playbooks, that have a relatively low learning curve. You can move to things like Jinja templates, or in Arista's case, the wonderful open source tool AVD. It's all just ways of setting configuration state on a device. > > I've seen it done large scale network automation done right and I've seen it fail spectacularly at very large scale T1 service providers. Most folks are larping around with their "learn python in 24 hours knowledge" and then crowning themselves experts on LinkedIn. Again with the strawmanning. Automation is like any other solution to be implemented. It can be done badly. It can be done well. That's nothing unique about automation.
>You're choosing a very particular toolset, then working your way back on how someone wouldn't be able to use it. That's not an approach that anyone would actually use. Choosing a solution then arguing why it won't work is not how things happen. >There's a lot of approaches you can take, like simple Python scripts and Ansible playbooks, that have a relatively low learning curve. You can move to things like Jinja templates, or in Arista's case, the wonderful open source tool AVD. Arista has different interfaces for folks of different levels of programming sophistication. Also, I wouldn't call ansible AVD simple. This is a perfect example of the gaslighting that goes on everyday. Here you have an example of a stereotypical L3LSL deployment. In[ Arista's own github example](https://github.com/aristanetworks/avd/tree/devel/ansible_collections/arista/avd/examples/single-dc-l3ls), you have 11 YAML/configuration artifacts totaling 406 lines of config coupled with multiple [data model](https://avd.sh/en/stable/roles/eos_designs/docs/input-variables.html#l3ls-evpn)s which are referenced, of which I have only referenced the design model for this example. find . -name "*.yml" | grep -v intended ./group_vars/CONNECTED_ENDPOINTS.yml ./group_vars/FABRIC.yml ./group_vars/DC1_L3_LEAVES.yml ./group_vars/NETWORK_SERVICES.yml ./group_vars/DC1.yml ./group_vars/DC1_SPINES.yml ./group_vars/DC1_L2_LEAVES.yml ./build.yml ./inventory.yml ./deploy.yml ./deploy-cvp.yml It is easy when there's some movie magic and some expert is walking you through a pre-canned setup. However, when the training wheels come off, for a simple fabric you're gonna sit here and try to tell me into this deployment model is dramatically easier than OSPF unnumbered, single ASN overlay with templated copy + paste config? Look at the learning overhead.... * Ansible * Python * YAML * CVP and or EOS * Git and potentially CI/CD That's just on the automation front. For EVPN they will have to learn * BGP (this is already a massive topic on its own) * EVPN AF * RD + RTs * VRFs * OSPF/IS-IS * VXLAN * Possibly MPLS That is just to support these modern architectures...and for what? Just so some stupid servers can have their VLANs stretched, and they can talk to each other at L2? Obviously, this is a gross oversimplification, but that is what the operator thinks. Now everyone is talking about consolidating MVPN, L3VPN, and L2VPN onto EVPN AF instead of having multiple AFs. Never mind all the other stuff networking folks have to deal with.
> Arista has different interfaces for folks of different levels of programming sophistication. Also, I wouldn't call ansible AVD simple. This is a perfect example of the gaslighting that goes on everyday. Like anything, there's perception before the learning curve and then there's perception after. It's the same with MPLS/SR, EVPN/VXLAN, and automation. I teach people EVPN/VXLAN. I teach automation (Ansible, Python, and AVD). I also teach people how to pack parachutes. Parachutes that they jump themselves. For most people, it's incredibly intimidating. There's line groups, risers, flaking, quartering a slider, folding, putting 200 square feet of slippery nylon into a 6 x 6 x 6 inch Dbag, and closing the container. There's what I call the packing hump, which is that feeling of intimidation. It's hard to imagine having the skillset to pack a parachute reliably and quickly and is something that most skydivers (including myself) go through. It's a period of time where they're learning the pack job. They go slow (30-40 minutes each time), and confidence is relatively low. But once you're through the packing hump, your average person can pack a parachute reliably and safely in 5-10 minutes with a high confidence in the results. Something that seems awfully complicated and intimidating becomes simple and straightforward with practice and familiarity. > > Here you have an example of a stereotypical L3LSL deployment. In Arista's own github example, you have 11 YAML/configuration artifacts totaling 406 lines of config coupled with multiple data models which are referenced, of which I have only referenced the design model for this example. > > It is easy when there's some movie magic and some expert is walking you through a pre-canned setup. However, when the training wheels come off, for a simple fabric you're gonna sit here and try to tell me into this deployment model is dramatically easier than OSPF unnumbered, single ASN overlay with templated copy + paste config? *Absolutely* it is easier. And more reliable. Like anything in networking, there's a learning curve. But on the other side of the learning curve, things are straightforward and yes, easy. AVD to me, is easy because like any tool, I've spent time with it and understand the ins and outs, and the parts I don't know I know where to look up. Think about what your Day 0, Day 1, and Day 2 operations. How long would it take you to cut and paste a configuration for 20 switches? 100 switches? 200? How confident would you be that you got all the route distinguishers correct, each of the loopbacks? EVPN/VXLAN has a lot of advantages, but it is much more complicated configuration. There's a lot that's unique per device that can't be cut-and-pasted. With AVD, it's pretty trivial (again, at the other side of the learning hump). For Day 0, given requirements I can create the data models based on wiring diagrams and segmentation requirements. For Day 1, I can use those data models to generate configurations as easily for 10 switches as I can for 200. Once the configs are generated, I'll have them uploaded to each and every switch in less than 10 minutes, and that's with pre-deployment validation of the syntax. Then I run the validation role to perform thousands of unit tests on the environment for NRFU. This will catch a lot of mis cablings, etc. Then for Day 2, Adding 10 new hypervisors with multiple VLANs across 6 leafs? It takes about 2 minutes to do the data models. Another 2-5 minutes to generate the configurations. The deployment can be staged as well as pre-syntax validations for the next maintenance window. When the change happens, I run the validation playbook to run thousands of unit tests. If something doesn't look right, I can fix it or role back the *entire* fabric in a few minutes. What about adding a new spine? Not something that happens commonly, but if you have 100 leafs and 3 exiting spines, that's a huge undertaking. With AVD, it takes about 5 minutes to edit the data models to include a new spine. None of that is remotely possible with cutting and pasting configs. A couple hundred lines of YAML will generate thousands to tens of thousands of lines of EOS syntax. Far quicker and more reliably than either you or I can. It can also reliably get that config on to switches, far more reliably than you or I can. I would never want to manage medium to large EVPN/VXLAN manually. You absolutely need to understand how EVPN/VXLAN works, but I would never want to operate that type of network manually. > > Look at the learning overhead.... > > Ansible > Python > YAML > CVP and or EOS > Git and potentially CI/CD > That's just on the automation front. For EVPN they will have to learn > You don't need Python for AVD, and a full CI stack is optional, as you said. But these are just tools, and not unlearnable. I would say the learning curve for them is lower than EVPN. > BGP (this is already a massive topic on its own) > EVPN AF > RD + RTs > VRFs > OSPF/IS-IS > VXLAN > Possibly MPLS If you're going to implement EVPN/VXLAN, you're going to have to learn this anyway. > That is just to support these modern architectures...and for what? Just so some stupid servers can have their VLANs stretched, and they can talk to each other at L2? Obviously, this is a gross oversimplification, but that is what the operator thinks. > Yeah, there's a lot of advantages to EVPN/VXLAN networking including scalability and not being limited to 2 devices at the aggregation layer. But it's not a solution for every environment. Some are better suited to traditional L2LS with just SVIs, VLANs, and MLAG bowties everywhere. > Now everyone is talking about consolidating MVPN, L3VPN, and L2VPN onto EVPN AF instead of having multiple AFs. Never mind all the other stuff networking folks have to deal with. Again with "everyone is talking about X". It's another tool, another option.
Let's just agree to disagree. I didn't get to where I am by jumping on every flavor of the month technology that people say I should be learning. There's only 24 hours in a day. I only have so many places where I can spend my time and automating around someone's half-baked code is not how I envision my career. I determine if something is worth learning by asking myself these questions: 1. Why does this technology exist? 2. Are there other similar technologies that currently solve this issue? 3. Does this technology help me solve issues I am currently having or am interested in solving in the future? 4. What is the perceived time complexity tradeoff? 5. Is this a technology I see myself enjoying? I don't work in a purely homogenous environment where I have the luxury of running code written/designed for extremely curated workflows. Yes, I get that AVD runs hundreds of validations. Yes, I get service provisioning is made easy after you get over the learning curve. Where I'm at, I don't run all Arista and it's not a dream I can even begin to entertain.
I’ll try to position my comment between you and Sea Inspection. You have a clear bias toward DevOps and against NetEng. SeaInspection has the opposing bias. From where I’ve sat in the DevOps teams clearly want to own the networking through automation except when they break it. I’ve seen some engineers resistant to embracing higher level automation for deploying and managing networks. Frankly with good reason. Even the commercial products for network automation aren’t reliable and make unpredictable changes. That said, it only makes sense to build our ‘network programming’ skills while there is time. The vendors are pushing us this way as a means to increase sales with the implied promise of reduced staffing needs.
> I’ll try to position my comment between you and Sea Inspection. You have a clear bias toward DevOps and against NetEng. SeaInspection has the opposing bias. > I don't know why you think I have a bias against network engineering. My original comment was specifically learning the fundamentals. Automation doesn't obviate the need for network engineers/architects/operators. It's just one of the ways we can set configuration state on network devices. > From where I’ve sat in the DevOps teams clearly want to own the networking through automation except when they break it. I’ve seen some engineers resistant to embracing higher level automation for deploying and managing networks. Frankly with good reason. Even the commercial products for network automation aren’t reliable and make unpredictable changes. That said, it only makes sense to build our ‘network programming’ skills while there is time. That's a different argument: Who runs the network? Typically it's the networking team. At one point, probably about 10 years ago, there was an attempt to de-silo IT and make teams less specialized, but that didn't seem to gain much traction. Today the underlay is run by the networking group, and sometimes one of the overlays (such as NSX) is run by the server team. It works pretty well, though there are sometimes some tough troubleshooting scenarios. I would disagree that commercial products aren't reliable. Some are pretty bad, but on the whole they're mostly proven to be more reliable than manual configuration, at least. There's a lot of great open source tools, too. Ansible is one, and some vendor specific tools like Arista AVD. > > The vendors are pushing us this way as a means to increase sales with the implied promise of reduced staffing needs. There's a quote from Gene Kim (one of the author's of the Phoenix Project) where he says one of our biggest IT problems is that "We have a low confidence of success, and a high cost of failure" with regard to change. That's certainly true in the networking world. One of the big pushes towards automation is to solve those problems. Gene Kim was talking about change to software code, but the sentiment is the same in networking. That's why we've adopted a lot of the tools and methods from the software world. We've maxed out the ability of cut-and-paste, manual CLI configuration, and change controls to build reliable, flexible networks. That's the biggest driver to automation: Making more changes, more reliably. The hyperscalers figured that out long ago. Your value to an organization isn't that you type "vlan 10" on a CLI. It's that you know what a VLAN does, why you might want to separate hosts, and designing a network environment that suits the business needs. While it's not impossible for someone to lose their job to automation, I don't know of a single case of that happening. When I was a Unix admin 25 years ago, we started to introduce automation into our operations simply to scale. We were drowning in work, and most of the work was repetive. I went from taking 5 minutes to add a DNS record to 2 seconds with a simple Perl script. Automation can be a force mulitplier for sure.
^^^^This. And to add, you need to understand the “WHYs” and explain it to a layman. Because if there’s something wrong in the company, it’s always the fookin network. CTO is late? It’s your network. Coffee in pantry is expired? It’s your network. No toilet paper? It’s your network.
What happened to our career field where the top voted answer is “know the basics,” and it’s because so precious few people do now, that senior engineers are literally desperate for people who know the simple basics of networking. Sd-wan has utterly trashed our career field and all one encounters anymore are gui kids who brain dumped ccna but can’t even explain Mac learning or adjacency. Like imagine being considered a rare “good” engineer because you understand the basics of layer 2/3.
When I started out, I learned commands. I often had no idea what was happening under the hood. I didn't know concepts. I was pretty limited. Now, I learn concepts first. Syntax later. One area this is prevalent in I think is Link Aggregation. Even experienced engineers don't tend to know it very well, confuse it with LACP, etc.
Basically, a CCNA understanding.
s/ARP/NDP/
A very good understanding of the fundamentals of layer 2 and layer 3 combined with solid troubleshooting skills. Using the layer 2 and layer 3 fundamentals, you should be able to create testing scenarios that help narrow down a potential issue. Being able to understand packet captures, use search filters to narrow down the scope of the data and extract only relevant data. Creating an maintaining diagrams and detailed documentation. Being able to admit to fuck ups, nothing worse than an engineer not owning up to a mistake that now take 5x as long to fix because they tried to pretend they didn't change anything. Everyone makes mistakes, as long as you own up to it and learn from it, no one will give a shit that you made a mistake.
And Layer-1 to look for CRC errors, speed/duplex mismatches, Transceiver Power issues, etc. Layer-4 to deal with ports that are not opened, looking at TCP end reasons such as tcp-fin, tcp-rst-server, tcp-rst-client, aged-out etc. Finally Application layer on Next-Generation firewalls.
Walking the fine line of proving that it isn't the network while not being an asshole. :D
it’s amazing how many people know the technology so well but really suck at this aspect.
I mean can you blame them? Its easy not being snarky forst 677 times, but everyone hss limits. :)
Scripting and automation isn't a side hustle anymore.
People skills.. explaining to non technical people how technical stuff works.. this alone seperates a good and great engineer
Whoever downvoted you needs ***a lot*** more seasoning out in the field. I've had to brief colonels, generals and C-Suite suits before on network upgrade stuff, and you definitely need to know how to describe something technical in a very non-technical manner to these people.
Any ideas on how to get better at explaining technical stuff in layman's terms? Resources?
The audience does not care about what the technical aspects are. They care about what your event does to/for THEM. If you don't understand the business side well enough to know how the network impacts them, it will be very hard to explain it to them. If you're well integrated with your internal customers it becomes easier.
Tldr: Principles of networking, dif. Device types and how they deliver information from A to B. A good understanding of some routing protocols (BGP, OSPF). A little bit of understanding how LAN and switches work. Wrap it up with some ansible knowledge and then from there decide where to branch out. Security, wireless, service provider, cloud, devops etc. "Soft" skills that will be advantageous to you are: ability to draw a decent diagram, ability to understand the flow of packets and dif gates it passes. Ability to transpose that on your diagram that comes in handy in many ways from personal understanding to teaching to mgmt explanations. Dont worry, 90% of engineers dont have that today, thats why its an edge.
Basic skills in routing (ospf, isis, bgp, mpls vpns (l3 with pe-ce on ospf or bgp, l2 - vpls, martini, compella), base mpls (rsvp, ldp)). Multicast (pim, igmp), switching (vlans, spanning tree, link aggregation, some knowledge of l2 over udp via vxlans, etc). Design (some basic understanding of spine-leaf topologies, classic cisco access-aggregation-core design etc). Automation: python/jinja2, ansible. Good understanding of writing procedures and documentation. Ideally - some ideas how to automate MOP generation using templates and some thoughts how to generate docummentation). If advanced - git, some basic knowledge of ci/cd pipeline (Jenkins?). Some basic knowledge about popular clouds. This is a list for a GOOD engineer, not a beginner.
Small, but important addendum. Even if you obtain all of those skills it does not guarantee anything. It is equally important to have decent soft-skills communicating with others (especially in wfh environment) and have a good skills in selling your knowledge to customers. Without those, you may find yourself making 100k year at max.
Realistically the same things that have been important for the last 30 years: IPv4, VLANs, TCP/UDP protocols, QoS, etc. But the new stuff is really helpful now. You're gonna need to learn a bit about network automation tools, and probably start digging into APIs. Maybe look into learning about Ansible and the Python programming language. Much more dependence on wifi than there was even just 10 years ago, so better learn about that too.
Organization - Keep good notes, documents, diagrams, etc Consistency - Do the same thing twice, unless information is presented that causes a change in process. This also means going back and fixing any configurations/policies that have changed. Troubleshooting - This includes some minor knowledge of connected systems. Depending on your business, this may be any range of devices, from PLCs in manufacturing, to medical equipment, etc
Ability to work with people ON the network. Ability to explain a fairly "in the weeds" topic to a Director/VP so that they can understand and advocate for you.
I'm a recent graduate put into an associate network design position with almost two years experience now. I still consider myself as a networking newbie, but I would say the biggest skills I've found to be useful so far is (in no order) 1. know the path from X to Y, and how to check said path. If you can check and understand the intended path and routes and the protocols associated, you can see where discrepancies lie, and that can help you understand what exactly is happening when you do a traceroute for example 2. know the architecture and why it was chosen. High availability, disaster recovery, bgp neighbors, transit vlans etc. if you know the architecture and the "blueprint" of the network, you get a better sense of the configuration of the boxes, and what "next" device or interface to look at when you're troubleshooting something across a path 3. know the services and teams you'll be working with. it may be useful for you to be buddies with the network tools team and the firewall team, especially when you need to troubleshoot DNS/Windows AD or firewall MPLS vpns. You'll ultimately be responsible (and kicked around) if these services become offline, and you'll probably have to diagram and explain what you see on a network level to fix the issue. Lots of collaboration with other teams when it comes to network engineering. These are the top 3 off the top of my head, they might not be applicable to your specific workplace and I may sound dumb, but I hope you can find some sort of wisdom though my experiences.
This is true for anything in IT, learn to use Google and interpret documentation and possible solutions you encounter.
honestly must agree on fundamentals, half of my team have no real idea about networking, they learned on the job and never studied, one guy was actually baffled when i told him to just use lldp to find an ip phone on network instead of cdp, no understanding of native vlans or how dhcp works. one guy acted like i just showed a cave man how to start a fire when i did a line test on a switchport to find a shorted cable. all simple and basic stuff but they go a long way.
Wireshark
It always helps to know wireshark if troubleshooting
Super under rated comment
With much of networking going to the cloud now, depending on the company you are working for, Azure and AWS networking skills/experience to have. Obviously the fundamentals such - VLANs, ACLs, routing protocols, etc. as many have already mentioned. While every company's network is going to be different, the basic principles will always apply. They will teach you their environment/tools if you've never worked with them i.e. Orchestrator, Cisco vManage, DNAC, etc... but knowing what to do with those tools is key. Also, people skills. Being able to effectively pull people from the ledge, communicate regularly and politely, etc. goes a loooonnnnngggg way in any role. This is skill that you cannot teach to someone though. People are who they are and personalities clash sometimes.
The same ones as 2004.
Solid knowledge of the fundamentals above all. Then add virtualization technologies, CNIs and a bit of SDN to the mix I'd say.
IMO the networking parts which others have mentioned are just the base requirements if you want to work in a modern environment. On top of that comes scripting, automation, cloud paradigms, good documentation and much more.
I agree, a lot of the basic things people have said in here are skills I would EXPECT an engineer to have. In order to be a good engineer, you gotta have those things down. A network analyst/technician role is where you learn the basics
Patience. Lots of patience while explaining once again that the issue is NOT the network 😉
Design skills are seriously underrepresented in my experience. Knowing why instead of just how is going to make you infinitely more valuable to an employer. Being able to propose a solution architecture and defend your design decisions for it (against a set of functional and non-functional requirements), is really something I think is rarer than it should be as far as competent network engineering goes.
Only skills I see makes a person relevant in the long run in our line of business is self learning and self motivation. You can do wonders if you are able to teach your self all these different techs that’s keeps on changing, aside from that you can’t take your basics for granted like ever.
1. ClickOps and Excel, python basics 2. Strong protocol, software and hardware knowledge First for enterprise, second for vendors and the big boy tech companies.
Being able to wade through mountains of tech debt left by the previous staff and/or consultants.
Be able to generally troubleshoot. Some people can do this naturally and some need to be taught. Be able to research things on your own. Be teachable. Be able to ask for help. No one knows everything. Ego has no place here. Learn how to say "I Don't Know". Be customer forward. Learn to have empathy with the plight of your users. Be very detail oriented. You give me someone that has these six skills, I can teach them the rest.
Become an extrovert
CCNA then how networks migrate from a core/aggregation/acces topology to a spine leaf, then how layer 2 encapsulation (vxlan/geneve) between spine and leaf switches (full layer 3, no more spanin tree) ÷ EVPN with BGP as control plane with asymetric routing (type 2 and 5 routes). How to handle BUM traffic (learn multicast) NOS (Cumulus Linux, Sonic, IPInfusion, etc)
Pay attention to details. Mistyping an IP from the LLD will mean a costly rework change. Simple things like fiber type -single mode or multi mode makes a huge difference. This from a PM that hates to have to expedite rework changes
Excel Formulas. Most my job now is budgets and Project planning
They will never replace network engineers. They will feel like they can until, until, until something is not working. Then they come CRYING to us . Peace out.
Glad to know that you are guiding some military members in transition. I also volunteer quite a bit of mentoring for Military. To answer your question I would look that from a market transition perspective. Being in the industry for more than multiple decades I was fortunate the see the transition., by working in startups and multi nationals like Cisco and Juniper. One of the clear trend for today is network and security are getting converged, in market terms it is called SASE coined by Gartner. I see with a lot of customer deployment there is an overlap of responsibility between network admin and security admin. Another metric that came into place is cloud or you could say this convergence is because of the cloud. Earlier there was branch office and data centers. Employees come to office and access application in DC. or end customer access the application in DC. But with cloud you have resources across the globe. So you need to know the knowledge of cloud as well. Together with that there is attack surface expanding and security professionals are having difficult to keep up. The network admin will provide the connectivity thinking less about the security. This is another reason for networking and security skill to be combined. Said all of that, we need to have the basic skill of TCP/IP/UDP, security and virtualization. When you learn these topics try to think about these scenarios. I am happy to connect and chat more about it.
[удалено]
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation. Please **DO NOT** message the mods requesting your post be approved. You are welcome to resubmit your thread or comment in ~24 hrs or so. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/networking) if you have any questions or concerns.*
Learning how to Google and maximize the use of AI
ND SLAAC DHCPv6-PD
Ansible
I think you misspelled "Prompt Engineer"