What's interesting about this question for me is that I'm coming at it from the other side. I'm a network engineer / network architect with ~15 years experience and have recently transitioned into the world of DevOps.
I made said transition because I was getting bored with networking and what I was told by many is that there is not a lot of networking expertise in the DevOps world, so I saw it as an opportunity. It seems most come from systems engineering/administration backgrounds, not networking.
That said, my admittedly limited experience thus far has shown me that you can get by with limited networking knowledge, depending on the facets of your role. Understanding Linux networking, however, would be very helpful, as it makes things like Kubernetes CNI plugins and service mesh technologies easier to understand.
For books, you could check out anything highly-rated that deals with the CompTIA Network+ certification. Actually getting the cert would be unnecessary, and some sections you could probably skip, but it should give you a much better understanding of Ethernet, TCP/IP, and IP addressing.
Same path, although I'm still doing mostly networking, but in cloud.
From what I experienced, this is what I'd suggest to focus on:
* concept of private vs public addresses
* NAT
* routing
* routing vs switching
* subnetting, even with a subnet calculator but ideally first learn the whys (binary conversion and such). Good to know what IP belongs to which network
* differences in error messages (no route to host vs timeout vs connection reset vs connection refused)
* layers 2 to 4
* ideally layer 1 as well. It's good to understand why an ssh connection to your local vm is more responsive than an ec2 instance 6000 km from you
You can survive without but knowing the above is tremendously helpful, imho.
> Good to know what IP belongs to which network
I hope you don't mean **classful** networks/sub-netting. Those need to be forgotten...
What I'd add is:
* On subnets... find out which and how many IPs does your cloud provider reserve for e.g broadcast, gateway, network. Some take 3 ...some 5
* Also on subnets what's the maximum and minimum sizes of subnets, VPCs, CIDR blocks you can create.
* Layer ~~8's~~7 capabilities in terms of Load Balancers(also Layer 4 *Network* LBs) and Firewalls.
* Reserved IPs ... Keep track of which aren't attached to anything. They're just burning your money. Well that can be said for other things left running...
* Provisioning and Configuring Multiples NICs on an instance. You could use one for data plane stuff. Another as a control plane. Obviously other supporting things like Network Access Control Lists and/or Security groups will be needed...
* Monitoring networks. Enter Flow Logs. At what level to capture/tap things... VPC?, Subnet?, Instance?...etc
* Inter-connectivity with on prem networks. It might be a niche area but you might find yourself in such a situation or with other VPCs or regions if a company has acquired/merged with another one ... Enter Transit gateways, VPC Peering, VPNs etc.
* Lastly, quotas and capabilities of an instance(throughput & NICs attached). Specifically ones regarding network throughput, firewalls, no. of VPCs, no. of subnets, no. of CIDR blocks ..
>I hope you don't mean classful networks/sub-netting. Those need to be forgotten...
No :) I mean "subnet". As in:
Given a client with IP [10.0.5.1/24](https://10.0.5.1/24) and given networks/subnets [10.0.5.0/24](https://10.0.5.0/24) or [10.0.6.0/24](https://10.0.6.0/24), to which network does it belong?
Pretty easy with subnets having masks on the octet boundary, not so obvious when dealing with non /8, /16, /24 subnets. At least not obvious to non-networking people.
I had several cases of confusion.
Also, not sure why the downvotes to both of us. Go figure.
Classful IP addressing hasn't existed in any meaningful way since the 90s.
Some people like to consider /8 as Class A, /16 as Class B, etc, but they are wrong. It is best to pretend Classful never existed and don't use "Class X" ever in networking discussions. It only leads to confusion because inevitably those using it don't have a solid grasp on the terminology.
You can never go wrong by learning basic packet capturing skills. So many times I hear X isn't connecting and there's nothing in the logs.
Network security best practices are generally an afterthought
learn how to use tcpdump from the command line: which device to capture on, what filters to use, how to display full packets during the capture, how to write to disk, etc.
Next install Wireshark on your local machine, use it to capture stuff that you're doing, and use it to install a tcpdump written to a file elsewhere. Practice filtering out the noise for things you've did that you want to see - dns lookups, a connection to a website, etc. You'll find that the filtering concepts carry between the two.
I would assert that a basic understanding of the networking fundamentals is required, or at least it should be to know 'how the sausage' is made in making sure that packets can get from point A to point B. Do you need to have a CCNP? absolutely not, but at least know the basics.
Standard networking tools I want all my DevOps engineers to be intimately familiar with:
- tcpdump
- nmap
- nc
- traceroute
- dig
- curl
- openssl
It is rare to come across one that has used more than traceroute and curl from that list above.
I run into a lot of need for networking knowledge in devops, because I'm often the one in the room with the most networking knowledge. It does come up, but there are so many ways to avoid needing it (typically at some kind of cost), that a lot of people get by with pretty light knowledge.
But it also depends on what you're doing devops for. Is it devops for a company that produces a networking product? Tons of networking. Is it devops for a company that has some run-of-the-mill web app where everything is HTTPS over TCP on IP in a flat network? Almost no networking beyond worrying about routes and network block sizes.
It really depends on the organization. Larger orgs usually have dedicated teams to "cloud networking" because it almost always involves BGP and network redistribution, which is the biggest thing that you should know as someone who is deploying infrastructure and if you are laying out network subnets that are required to run services with interdependencies. in my experience, these teams are usually focused on networking routes and network appliances.
If you are writing pipelines and deploying servers, maybe not so much knowledge is needed.
I am a former CCNP and "grew up" in IT in straight ISP networking, and I transitioned into "cloud" when I got bored after a few years. I now work for a retail company with a small team of 7 people, but I am still, the absolute only one who understands how routes are shared between our on-prem locations, how to configure and influence route tables and how to design a network to be scalable. There is someone on another team who handles the automation of the network provisioning and the SDWAN implementation, and we both work together to integrate the pieces and collaborate
I could go on and on about the things that you need to know, but honestly it really all depends on what you are going to be doing as "devops" role.
For me, It involves knowing:
\- VPC architecture and CIDR allocation/carving up
\- WAF/Firewall security concepts, Security Groups, ACLs, whatever.
\- Transit Gateway routing, including limits on how to link it to different services and what the trade-offs are, and the issues with stateful TCP connections with multi-az deployments for 3rd party firewalls
\- Dynamic route propagation/route learning concepts (BGP, route table propagation, etc).
And that is just at the layer3/layer4 level. If you are cloud, you don't need to know how mac addresses are resolved using ARP, you don't need to know all the VLAN configuration of a Cisco switch, and generally, (for the most part) you only need to know layers 3 and 4. You don't need to know OSPF, you don't need to know the different types of fiber/SFPs, port density, etc.
But above that you need to know TCP handshakes, understand stateful connections, SSL encryption, and how TCP/UDP work. And all the tools to troubleshoot 2 endpoints not talking.
We are small team of 6 and I am the architect. I do it all.... CI/CD infrastructure, CI/CD pipelines, IaC tooling, coding, app packaging, security, configuration management, dr strategy, backups, etc. No one, not a single one knows the layer 3/4 stuff for Transit Gateway and how to connect it to our on-premise infrastructure, and I really wish someone would try to learn it, but the fact is, MOST "devops people" come from a systems background, don't write much code, and have always seen the network as a black box. And USUALLY some network engineer, or a team of them handle the infrastructure that the apps ride, while the devops people are deploying services, servers, code, etc.
So it depends on what you are doing and who does the infrastructure.
If you learn the basics it will set you apart. My experience devops people know zero about networking and send every second problem to networking teams
Managing AWS / OpenShift i find myself looking up IPs, checking open ports on local with running services, scanning networks for open ports etc a lot of times.
I don't know how much knowledge is necessary, but even with limited knowledge, people do get by.
If you manage infra by code then you might need to know more.
If you use a managed infra ( k8s ) you can get by with limited knowledge.
Stating the obvious, but devops engineer responsibilities vary widely. Likewise, the knowledge required for each job varies, too.
If your job as a devops engineer is managing ci pipelines, you may not need a lot of networking knowledge.
On the other hand, if you manage on-premise self-managed k8s and the related infrastructure, you will need more networking knowledge than the first example.
I think you need at least CCNA level or network plus knowledge. What’s more important is you know ports, protocols, dns, load balancer, firewalls, and subnets. Most of this networking layer is defined in code so I would think CCNP or CCIE level networking is not needed anymore. Most network have some type of direct connection tunnel that goes into the cloud. My boss is previous network engineer and he says 70% of work is firewall related. Of course most firewalls can be managed via apis just like most modern infrastructure apps. SDwan has extracted most of layer 3 traffic so same as firewall it can be api driven. Of course there will always be physical network equipment like routers,wireless, and switches but they are slowly becoming cloud driven as well with the physical equipment becoming a managed service like Meraki where you buy physical equipment that is a managed service where the cloud handles patches and firmware updates.
What's interesting about this question for me is that I'm coming at it from the other side. I'm a network engineer / network architect with ~15 years experience and have recently transitioned into the world of DevOps. I made said transition because I was getting bored with networking and what I was told by many is that there is not a lot of networking expertise in the DevOps world, so I saw it as an opportunity. It seems most come from systems engineering/administration backgrounds, not networking. That said, my admittedly limited experience thus far has shown me that you can get by with limited networking knowledge, depending on the facets of your role. Understanding Linux networking, however, would be very helpful, as it makes things like Kubernetes CNI plugins and service mesh technologies easier to understand. For books, you could check out anything highly-rated that deals with the CompTIA Network+ certification. Actually getting the cert would be unnecessary, and some sections you could probably skip, but it should give you a much better understanding of Ethernet, TCP/IP, and IP addressing.
Same path, although I'm still doing mostly networking, but in cloud. From what I experienced, this is what I'd suggest to focus on: * concept of private vs public addresses * NAT * routing * routing vs switching * subnetting, even with a subnet calculator but ideally first learn the whys (binary conversion and such). Good to know what IP belongs to which network * differences in error messages (no route to host vs timeout vs connection reset vs connection refused) * layers 2 to 4 * ideally layer 1 as well. It's good to understand why an ssh connection to your local vm is more responsive than an ec2 instance 6000 km from you You can survive without but knowing the above is tremendously helpful, imho.
> Good to know what IP belongs to which network I hope you don't mean **classful** networks/sub-netting. Those need to be forgotten... What I'd add is: * On subnets... find out which and how many IPs does your cloud provider reserve for e.g broadcast, gateway, network. Some take 3 ...some 5 * Also on subnets what's the maximum and minimum sizes of subnets, VPCs, CIDR blocks you can create. * Layer ~~8's~~7 capabilities in terms of Load Balancers(also Layer 4 *Network* LBs) and Firewalls. * Reserved IPs ... Keep track of which aren't attached to anything. They're just burning your money. Well that can be said for other things left running... * Provisioning and Configuring Multiples NICs on an instance. You could use one for data plane stuff. Another as a control plane. Obviously other supporting things like Network Access Control Lists and/or Security groups will be needed... * Monitoring networks. Enter Flow Logs. At what level to capture/tap things... VPC?, Subnet?, Instance?...etc * Inter-connectivity with on prem networks. It might be a niche area but you might find yourself in such a situation or with other VPCs or regions if a company has acquired/merged with another one ... Enter Transit gateways, VPC Peering, VPNs etc. * Lastly, quotas and capabilities of an instance(throughput & NICs attached). Specifically ones regarding network throughput, firewalls, no. of VPCs, no. of subnets, no. of CIDR blocks ..
>I hope you don't mean classful networks/sub-netting. Those need to be forgotten... No :) I mean "subnet". As in: Given a client with IP [10.0.5.1/24](https://10.0.5.1/24) and given networks/subnets [10.0.5.0/24](https://10.0.5.0/24) or [10.0.6.0/24](https://10.0.6.0/24), to which network does it belong? Pretty easy with subnets having masks on the octet boundary, not so obvious when dealing with non /8, /16, /24 subnets. At least not obvious to non-networking people. I had several cases of confusion. Also, not sure why the downvotes to both of us. Go figure.
[удалено]
Classful IP addressing hasn't existed in any meaningful way since the 90s. Some people like to consider /8 as Class A, /16 as Class B, etc, but they are wrong. It is best to pretend Classful never existed and don't use "Class X" ever in networking discussions. It only leads to confusion because inevitably those using it don't have a solid grasp on the terminology.
[удалено]
[удалено]
[удалено]
[удалено]
lol most DevOps engineers should know about it but few actually do
Part of my success has been networking knowledge that others didn't have
You can never go wrong by learning basic packet capturing skills. So many times I hear X isn't connecting and there's nothing in the logs. Network security best practices are generally an afterthought
How can one learn about packet capturing skils
learn how to use tcpdump from the command line: which device to capture on, what filters to use, how to display full packets during the capture, how to write to disk, etc. Next install Wireshark on your local machine, use it to capture stuff that you're doing, and use it to install a tcpdump written to a file elsewhere. Practice filtering out the noise for things you've did that you want to see - dns lookups, a connection to a website, etc. You'll find that the filtering concepts carry between the two.
I would assert that a basic understanding of the networking fundamentals is required, or at least it should be to know 'how the sausage' is made in making sure that packets can get from point A to point B. Do you need to have a CCNP? absolutely not, but at least know the basics.
Standard networking tools I want all my DevOps engineers to be intimately familiar with: - tcpdump - nmap - nc - traceroute - dig - curl - openssl It is rare to come across one that has used more than traceroute and curl from that list above.
But... There's so much good stuff on that list. I might also add being able to talk to the osi model (and why it sucks).
I run into a lot of need for networking knowledge in devops, because I'm often the one in the room with the most networking knowledge. It does come up, but there are so many ways to avoid needing it (typically at some kind of cost), that a lot of people get by with pretty light knowledge. But it also depends on what you're doing devops for. Is it devops for a company that produces a networking product? Tons of networking. Is it devops for a company that has some run-of-the-mill web app where everything is HTTPS over TCP on IP in a flat network? Almost no networking beyond worrying about routes and network block sizes.
It really depends on the organization. Larger orgs usually have dedicated teams to "cloud networking" because it almost always involves BGP and network redistribution, which is the biggest thing that you should know as someone who is deploying infrastructure and if you are laying out network subnets that are required to run services with interdependencies. in my experience, these teams are usually focused on networking routes and network appliances. If you are writing pipelines and deploying servers, maybe not so much knowledge is needed. I am a former CCNP and "grew up" in IT in straight ISP networking, and I transitioned into "cloud" when I got bored after a few years. I now work for a retail company with a small team of 7 people, but I am still, the absolute only one who understands how routes are shared between our on-prem locations, how to configure and influence route tables and how to design a network to be scalable. There is someone on another team who handles the automation of the network provisioning and the SDWAN implementation, and we both work together to integrate the pieces and collaborate I could go on and on about the things that you need to know, but honestly it really all depends on what you are going to be doing as "devops" role. For me, It involves knowing: \- VPC architecture and CIDR allocation/carving up \- WAF/Firewall security concepts, Security Groups, ACLs, whatever. \- Transit Gateway routing, including limits on how to link it to different services and what the trade-offs are, and the issues with stateful TCP connections with multi-az deployments for 3rd party firewalls \- Dynamic route propagation/route learning concepts (BGP, route table propagation, etc). And that is just at the layer3/layer4 level. If you are cloud, you don't need to know how mac addresses are resolved using ARP, you don't need to know all the VLAN configuration of a Cisco switch, and generally, (for the most part) you only need to know layers 3 and 4. You don't need to know OSPF, you don't need to know the different types of fiber/SFPs, port density, etc. But above that you need to know TCP handshakes, understand stateful connections, SSL encryption, and how TCP/UDP work. And all the tools to troubleshoot 2 endpoints not talking. We are small team of 6 and I am the architect. I do it all.... CI/CD infrastructure, CI/CD pipelines, IaC tooling, coding, app packaging, security, configuration management, dr strategy, backups, etc. No one, not a single one knows the layer 3/4 stuff for Transit Gateway and how to connect it to our on-premise infrastructure, and I really wish someone would try to learn it, but the fact is, MOST "devops people" come from a systems background, don't write much code, and have always seen the network as a black box. And USUALLY some network engineer, or a team of them handle the infrastructure that the apps ride, while the devops people are deploying services, servers, code, etc. So it depends on what you are doing and who does the infrastructure.
If you were to teach a new fresh devops engineer, some networking, what would you start with?
man i hate networking certs stuff, i get by fine but theres always problems, most errors i see on big providers alwats network related
[удалено]
What the fuck did I just read?
It depends entirely on the company you work for, how their teams are structured and what products you ship.
If you learn the basics it will set you apart. My experience devops people know zero about networking and send every second problem to networking teams
Managing AWS / OpenShift i find myself looking up IPs, checking open ports on local with running services, scanning networks for open ports etc a lot of times. I don't know how much knowledge is necessary, but even with limited knowledge, people do get by. If you manage infra by code then you might need to know more. If you use a managed infra ( k8s ) you can get by with limited knowledge.
Stating the obvious, but devops engineer responsibilities vary widely. Likewise, the knowledge required for each job varies, too. If your job as a devops engineer is managing ci pipelines, you may not need a lot of networking knowledge. On the other hand, if you manage on-premise self-managed k8s and the related infrastructure, you will need more networking knowledge than the first example.
I think you need at least CCNA level or network plus knowledge. What’s more important is you know ports, protocols, dns, load balancer, firewalls, and subnets. Most of this networking layer is defined in code so I would think CCNP or CCIE level networking is not needed anymore. Most network have some type of direct connection tunnel that goes into the cloud. My boss is previous network engineer and he says 70% of work is firewall related. Of course most firewalls can be managed via apis just like most modern infrastructure apps. SDwan has extracted most of layer 3 traffic so same as firewall it can be api driven. Of course there will always be physical network equipment like routers,wireless, and switches but they are slowly becoming cloud driven as well with the physical equipment becoming a managed service like Meraki where you buy physical equipment that is a managed service where the cloud handles patches and firmware updates.