This place needs more of this kind of documentation.
I failed to use IP tables for years. I bought books. I copied recipes from blog posts. Nothing made sense, everything I did was brittle. Until I finally found a schematic showing the flowchart of a packet through the kernel, which gives the exact order that each rule chain is applied, and where some of the sysctl values are enforced. All of a sudden, I could write rules that did exactly what I wanted, or intelligently choose between rules that have equivalent behaviors in isolation but which could have different performance implications.
After studying the schematic, every would just work on the first try. A good schematic makes a world of difference!
This also isn't complete because it doesn't show code between or around the various tables. I used to think of iptables as dumb filters that manipulate raw packets before/after the rest of the kernel sees them, but this view is wrong, and doesn't explain, for example, how it does NAT.
And the answer is it doesn't do NAT. The code is already preparing to do NAT, and that code merely consults the table to find out what kind of NAT it should do. The diagram makes it look like you can just move a NAT rule to a filter or mangle rule because the kernel just applies these tables in sequence anyway, but you can't because they are consulted by different blocks of code for different purposes.
Me too, then I discovered FreeBSD and pf tables. I _feel_ like an expert network engineer now. It took time and effort of course, but the learning process "clicked" for me all along the way and I was able to build on my understandings. Give it a try!
For the most part iptables is no more, iptables tools are now just wrappers to nftables. Technically you can still write iptables rules, and they will show up in nftables. Wouldnt recommend long term but its a good way to see the translation
I've wanted to switch to nftables on some of my systems but found that some software or other depended on iptables (e.g. Docker Engine, Proxmox). Use nftables if you can get away with it but iptables-specific knowledge is still extremely relevant.
> If someone doesn’t know iptables, they probably are not required to know it.
That makes no sense. Just because I do not know X, it does not necessarily follow that I am not required to know it, not at all. I might need it for my job, or my future job. I might need it for a Linux distribution I just installed, and so forth. Or perhaps I am already using iptables, but I do not know it.
Ahhhhhh at least an understanding that it exists and how it might interact with nft is probably beneficial unless they’re expecting to only ever work on greenfield equipment. If you were to walk into a job with existing IT infrastructure, there’s a solid chance that you’ll encounter iptables. If you’re looking to do a deep dive into something and learn it well, definitely nft is the way to go but being able to tweak iptables configs without needing to start over with a clean nft slate is valuable.
To your C++03 analogy, I wouldn’t recommend learning C++03, but I also wouldn’t recommend solely learning C++23 either. C++20 and 23 have some really cool stuff in them that can definitely make your code cleaner, but there’s a lot of codebases that are stuck on older versions (at $JOB one of our target platforms is stuck on C++17 and will never get an upgrade so we can’t move the codebase forward until we abandon that kit).
If the person in question has never had the need to know iptables, why would that change now?
If a job will require such knowledge, they will pick it up. Iptables is exposed as a facade to nftables, lots of the concepts just transfer over, just that iptables is the more antiquated option.
I for instance have never really used iptables in anger, but have lots of experience with nftables and pf. I’ve used both in a professional setting. People can be made aware of iptables, but unless there’s a need to know it, I wouldn’t recommend picking it up now. And you’ll know if you need to learn c++17 or iptables, or python 2.7.
For more context, I've been working pretty closely with firewalls on all desktop platforms, and I've been doing so since 2018, and I've never had know about iptables on Linux.
If the author agrees, I could try to learn Serbo-Croatian (I'm Polish, good with languages) and translate it to English. I'm kinda a burnout Linux geek, who cannot look at computers much more. Translating a book would be fun, but I would need some sponsoring. Amadeusz at [the old name of icloud].com
the book is licenced under CC BY-SA so you should be OK with translating as long as you follow the licence terms.
you could try do a first pass in an AI model to translate and then proof-read it for quicker translation. good luck, it would be fun and potentially impactful ;)
To my knowledge, sadly I can't find an English version of it. I'm too wishing for a future English version so that I can read it. But I guess it will be a lot of work to translate it into English.
Thanks Hrvoje Horvat for such a detailed diagram! It'll help me learn the Network stack much, much easier.
His book "Operativni sustavi i računalne mreže - Linux u primjeni" [0] (Operating systems and computer networks - Linux in use) may well make learning Croatian worth it! Congrats on publishing, and thanks for such an invaluable contribution!
If someone could program a visualization tool that would generate such diagrams automatically, that would be even cooler (but likely a mission impossible).
Automatic generation would be really tough because of all the levels of abstraction traversed in this diagram in particular... But tools like Mermaid / PlantUML can get you in the ballpark, and PGF/TikZ could be a reasonable target if you want to attack that mission by generating text instead of images.
For containers you will also have own TCP/IP stack similarly to what is shown for VM on the diagram, this is done when a container uses slirp4netns to provide networking. An alternative is to use kernel TCP/IP stack, this is done when pasta is used for networking, diagram on this page shows the details:https://passt.top/passt/about/.
Is there some sort of equivalent to this book but in English, which explains and diagrams the Linux network stack? Doesn't need to be all in one, I feel like having a more high level overview and then subsystem diagrams with explanations would work as well.
There’s complication, and there’s complexity. Fools admire complication, engineers design solutions to complex problems. This is a diagram explaining the latter.
I think it was put pretty well by describing things as accidental complexity (of which you want as little as possible) and essential complexity, which is inherent to the problem domain that you're working with and which there is no way around for.
The same thing could sometimes fall into different categories as well - like going for a microservices architecture when you need to serve about 10'000 clients in total vs at some point actually needing to serve a lot of concurrent requests at any given time.
> inherent to the problem domain that you're working with and which there is no way around for
I'd phrase it to reasonable taken trade-offs for customer/user support and/or selling products.
> going for a microservices architecture when you need to serve about 10'000 clients
So far I am only aware of the use case to ship/release fast at cost of technical debt (non-synchronized master) of microservices.
As I understand it, this is to a large degree due to git shortcomings and no more efficient/scalable replacement solution being in sight. Or can you explain further use cases with technical necessity?
1. When you have a system where each component has significant complexity, to the point where if it was a monolith you'd have a 1M SLoC codebase that would be slow to work with - slow to compile, slow to deploy, slow to launch and would eat a lot of resources. At that point chances are that the business domain is so large that splitting up into smaller pieces wouldn't be out of the question.
2. Sometimes when you have vastly different workloads, like a bunch of parts of the system (maybe even the majority) that is just a CRUD and a small part that needs to deal with message queues, or digitally sign documents, or generate reports or do any PDF/Word/Excel/whatever processing. You could do this with a modular monolith but sometimes it's better to keep the dependencies of your project clean, especially in the case of subpar libraries that you have to use, so you at least can put all of the bullshit in one place. Also applies in cases where the load/stability of that one eccentric part is under question.
3. The tech stack might also differ a whole bunch of some of those use cases, for example if you need to process all sorts of binary data formats (e.g. satellite data) or do specific kinds of number crunching, or interact with LLMs, a lot of the time Python will be a really good solution for this, while that's not what you might be using in your stack throughout. So you might pick the right tool for the job and keep it as a separate service.
4. The good old org chart, sometimes you'll just have different teams with different approaches and will be working on different parts of the business domain - you already said that, but Conway's law is very much a thing that'd be silly to fight against all that much, because then you'd end up with an awkward monorepo, the tooling to make working which easy might just not be available to you.
This place needs more of this kind of documentation.
I failed to use IP tables for years. I bought books. I copied recipes from blog posts. Nothing made sense, everything I did was brittle. Until I finally found a schematic showing the flowchart of a packet through the kernel, which gives the exact order that each rule chain is applied, and where some of the sysctl values are enforced. All of a sudden, I could write rules that did exactly what I wanted, or intelligently choose between rules that have equivalent behaviors in isolation but which could have different performance implications.
After studying the schematic, every would just work on the first try. A good schematic makes a world of difference!
Was it this one? https://en.wikipedia.org/wiki/File%3aNetfilter-packet-flow.s...
One of my favourite webpages. Have used it countless times over the years.
This also isn't complete because it doesn't show code between or around the various tables. I used to think of iptables as dumb filters that manipulate raw packets before/after the rest of the kernel sees them, but this view is wrong, and doesn't explain, for example, how it does NAT.
And the answer is it doesn't do NAT. The code is already preparing to do NAT, and that code merely consults the table to find out what kind of NAT it should do. The diagram makes it look like you can just move a NAT rule to a filter or mangle rule because the kernel just applies these tables in sequence anyway, but you can't because they are consulted by different blocks of code for different purposes.
I use this all the time when writing iptable rules.
It is also worth mentioning TRACE target that will dump to logs which exact rule the packet hit, it's invaluable big firewalls.
> I failed to use IP tables for years.
Me too, then I discovered FreeBSD and pf tables. I _feel_ like an expert network engineer now. It took time and effort of course, but the learning process "clicked" for me all along the way and I was able to build on my understandings. Give it a try!
https://docs.freebsd.org/en/books/handbook/firewalls/
There was a recent book published on the tool, The Book of PF, 4th Edition
Can you share the diagram? Would love to become iptables-enlightened.
Eventually I used more detailed diagrams, but this one was like a lightbulb going off:
https://www.frozentux.net/iptables-tutorial/images/tables_tr...
I couldn’t find one that annotated where sysctl configurable were shown. But this is a useful annotation, even if it’s an exercise for the reader.
It is time to be nftables enlightened instead.
Similar diagram, right in nftables wiki:
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_...
It's more of a netfilter (the thing behind iptables and nftables) diagram rather than just iptables.
If you know how iptables maps to that diagram you are very likely to be able to quickly understand how nftables does too.
Sure, but we really shouldn’t be encouraging the use of iptables in 2025.
For the most part iptables is no more, iptables tools are now just wrappers to nftables. Technically you can still write iptables rules, and they will show up in nftables. Wouldnt recommend long term but its a good way to see the translation
I've wanted to switch to nftables on some of my systems but found that some software or other depended on iptables (e.g. Docker Engine, Proxmox). Use nftables if you can get away with it but iptables-specific knowledge is still extremely relevant.
That's not realalistic for most of the Linux world.
Soooo many systems are still using iptables even though we "should" be using nft everywhere.
If you're going to be a Linux Sys/Net Admin today, you need an understanding of both systems.
If someone doesn’t know iptables, they probably are not required to know it. You wouldn’t recommend people to learn C++03, would you?
> If someone doesn’t know iptables, they probably are not required to know it.
That makes no sense. Just because I do not know X, it does not necessarily follow that I am not required to know it, not at all. I might need it for my job, or my future job. I might need it for a Linux distribution I just installed, and so forth. Or perhaps I am already using iptables, but I do not know it.
Ahhhhhh at least an understanding that it exists and how it might interact with nft is probably beneficial unless they’re expecting to only ever work on greenfield equipment. If you were to walk into a job with existing IT infrastructure, there’s a solid chance that you’ll encounter iptables. If you’re looking to do a deep dive into something and learn it well, definitely nft is the way to go but being able to tweak iptables configs without needing to start over with a clean nft slate is valuable.
To your C++03 analogy, I wouldn’t recommend learning C++03, but I also wouldn’t recommend solely learning C++23 either. C++20 and 23 have some really cool stuff in them that can definitely make your code cleaner, but there’s a lot of codebases that are stuck on older versions (at $JOB one of our target platforms is stuck on C++17 and will never get an upgrade so we can’t move the codebase forward until we abandon that kit).
If the person in question has never had the need to know iptables, why would that change now? If a job will require such knowledge, they will pick it up. Iptables is exposed as a facade to nftables, lots of the concepts just transfer over, just that iptables is the more antiquated option.
I for instance have never really used iptables in anger, but have lots of experience with nftables and pf. I’ve used both in a professional setting. People can be made aware of iptables, but unless there’s a need to know it, I wouldn’t recommend picking it up now. And you’ll know if you need to learn c++17 or iptables, or python 2.7.
For more context, I've been working pretty closely with firewalls on all desktop platforms, and I've been doing so since 2018, and I've never had know about iptables on Linux.
[dead]
Besides the diagram you'll find tutorials on https://www.frozentux.net/category/linux/iptables/ too.
And at http://www.easyfwgen.morizot.net/ there's an old, but still useful generator for an iptables setup. That should help to understand iptables.
For anyone who is interested, the author of this diagram also made a Linux disk I/O diagram (https://zenodo.org/records/15234151). These diagrams are from his book Operativni sustavi i računalne mreže - Linux u primjeni (https://zenodo.org/records/17371946)
Shout out to the brilliant and generous work of the author!
Do you know if there is a English version of the book?
If the author agrees, I could try to learn Serbo-Croatian (I'm Polish, good with languages) and translate it to English. I'm kinda a burnout Linux geek, who cannot look at computers much more. Translating a book would be fun, but I would need some sponsoring. Amadeusz at [the old name of icloud].com
You may want to find an email provider that has a better spam filter if you want people to actually contact you.
the book is licenced under CC BY-SA so you should be OK with translating as long as you follow the licence terms.
you could try do a first pass in an AI model to translate and then proof-read it for quicker translation. good luck, it would be fun and potentially impactful ;)
To my knowledge, sadly I can't find an English version of it. I'm too wishing for a future English version so that I can read it. But I guess it will be a lot of work to translate it into English.
The Disk I/O diagram is excellent, thank you for sharing.
Linux Kernel map is an other good one https://commons.wikimedia.org/wiki/File:Linux_kernel_map.png
I'm surprised to realize I'm familiar with most of the stack just from decades of Linux usage and no formal study of the stack.
Thanks Hrvoje Horvat for such a detailed diagram! It'll help me learn the Network stack much, much easier.
His book "Operativni sustavi i računalne mreže - Linux u primjeni" [0] (Operating systems and computer networks - Linux in use) may well make learning Croatian worth it! Congrats on publishing, and thanks for such an invaluable contribution!
[0]: https://zenodo.org/records/17371946
That's pretty cool!
If someone could program a visualization tool that would generate such diagrams automatically, that would be even cooler (but likely a mission impossible).
Automatic generation would be really tough because of all the levels of abstraction traversed in this diagram in particular... But tools like Mermaid / PlantUML can get you in the ballpark, and PGF/TikZ could be a reasonable target if you want to attack that mission by generating text instead of images.
For containers you will also have own TCP/IP stack similarly to what is shown for VM on the diagram, this is done when a container uses slirp4netns to provide networking. An alternative is to use kernel TCP/IP stack, this is done when pasta is used for networking, diagram on this page shows the details:https://passt.top/passt/about/.
Is there some sort of equivalent to this book but in English, which explains and diagrams the Linux network stack? Doesn't need to be all in one, I feel like having a more high level overview and then subsystem diagrams with explanations would work as well.
Is it possible we see the diagram as an svg? I am seeing it only as embedded in the pdf, and really difficult to read .
Click on "Download" below the embedded PDF viewer and you'll get the PDF.
I'm not sure if this takes into account para-virtualized networks on VMs, ie. VMware vm's with "virtual" hardware access
It's been a few years for me tho, so perhaps it's covered with the VM section.
Lovely diagram, thanks for sharing it!
These usually attach in the bridge or NAT flow.
*simplified.
Doesn't even go into iptables/nftables
If you look closely to iptables, iptables looks back at you.
Incredible work! I really wish the author's book had an English translation.
Are machine/AI translations viable for technical books like that [1]? It's CC-BY-SA licensed if anyone wants to give it a go.
[1] https://zenodo.org/records/17371946
Good thing we have Hacker News
Any recommendations for a map of Linux user-space network management options?
Anyone figure out what the colour scheme means?
s/Aplication/Application/g
qdisc is too small in this diagram and to easy to miss.
[dead]
[dead]
[dead]
wow
Fools admire complexity.
There’s complication, and there’s complexity. Fools admire complication, engineers design solutions to complex problems. This is a diagram explaining the latter.
I think it was put pretty well by describing things as accidental complexity (of which you want as little as possible) and essential complexity, which is inherent to the problem domain that you're working with and which there is no way around for.
The same thing could sometimes fall into different categories as well - like going for a microservices architecture when you need to serve about 10'000 clients in total vs at some point actually needing to serve a lot of concurrent requests at any given time.
> inherent to the problem domain that you're working with and which there is no way around for
I'd phrase it to reasonable taken trade-offs for customer/user support and/or selling products.
> going for a microservices architecture when you need to serve about 10'000 clients
So far I am only aware of the use case to ship/release fast at cost of technical debt (non-synchronized master) of microservices. As I understand it, this is to a large degree due to git shortcomings and no more efficient/scalable replacement solution being in sight. Or can you explain further use cases with technical necessity?
1. When you have a system where each component has significant complexity, to the point where if it was a monolith you'd have a 1M SLoC codebase that would be slow to work with - slow to compile, slow to deploy, slow to launch and would eat a lot of resources. At that point chances are that the business domain is so large that splitting up into smaller pieces wouldn't be out of the question.
2. Sometimes when you have vastly different workloads, like a bunch of parts of the system (maybe even the majority) that is just a CRUD and a small part that needs to deal with message queues, or digitally sign documents, or generate reports or do any PDF/Word/Excel/whatever processing. You could do this with a modular monolith but sometimes it's better to keep the dependencies of your project clean, especially in the case of subpar libraries that you have to use, so you at least can put all of the bullshit in one place. Also applies in cases where the load/stability of that one eccentric part is under question.
3. The tech stack might also differ a whole bunch of some of those use cases, for example if you need to process all sorts of binary data formats (e.g. satellite data) or do specific kinds of number crunching, or interact with LLMs, a lot of the time Python will be a really good solution for this, while that's not what you might be using in your stack throughout. So you might pick the right tool for the job and keep it as a separate service.
4. The good old org chart, sometimes you'll just have different teams with different approaches and will be working on different parts of the business domain - you already said that, but Conway's law is very much a thing that'd be silly to fight against all that much, because then you'd end up with an awkward monorepo, the tooling to make working which easy might just not be available to you.
Where/how would you simplify it without losing features?