eBPF Networking Techniques – Packet Redirection
who.ldelossa.isFantastic write up - keep going (please)!
Agree more practical examples but disagree this is too abstract.
I’m thinking starting at more common scenarios then jumping to container networking. Ie - Flow of a packet on a simple node, a two interface node, then namespaces, and then quirky virtual stuff.
Another example - I’d love to see how iptables actually works. Maybe how to use ebpf to implement iptables things like source/dest NAT, Masquerade, etc.
But yeah I learned a ton here. Thanks
> I’d love to see how iptables actually works.
If you're actually interested in iptables the old packet filter how-to is great:
https://www.netfilter.org/documentation/HOWTO/packet-filteri...
But iptables is turning into just a legacy interface for nftables in modern Linux. See eg:
I do plan on having a "flow of a packet on a simple node". Working on an ingress and egress packet flow posts. These are rather large undertakings tho that require a post of their own IMO. Stay tuned for those :)
I found this a bit too abstract to follow.
It would be helpful if the article explained a practical scenario where you'd want to use this technique.
The only explanation is "Packet redirection is taking a packet from one network interface and injecting it into another," but then there's no attempt to explain why you'd want to do this in practice.
The article also uses a lot of notation without explaining it. It explains what a "veth" is, but it doesn't explain what "veth1@2" or "veth2@1" means. Similarly, it never explains what "netns_1" or "netns_2" are. Are these widely-understood semantics?
Thanks for the constructive feedback.
The reason laid out in the article was for "jumping over the default linux network stack" to move a packet closer to its destination. I provide that just to hopefully help, ill have to read thru the article again to see how I can improve on making that clearer or defining more practical wording :).
And yeah, I understand your comments on all the naming spaghetti. I throw together these things so often that the convention used here are ones from my own head sprinkled with a bit of "iproute2" output format. Ill see if I can improve on this a bit moving forward. The explanation by another reply is correct :).
"jumping over the default linux network stack". What are the use cases. What are typical reasons to want to do that, what are benefits and downsides? What are the alternatives.
I really don't know, but the first thing that occurred to me was implementing a "bump in the wire" type firewall. IE, one that sits on the network transparently and can filter and log traffic without affecting layer 2 or 3 headers.
I have no idea if this is an effective and performant approach, but it sounds feasible. Same with implementing switching or routing functionality.
By skimming through, it is obvious that require familiarity with linux network namespaces and docker/kubernetes networking stack (virtual interfaces and what-not).
I don't blame the author though. When you write a technical post, at a certain point you need to assume the readership has some level of context otherwise you'll never complete the post.
Yes, you are right here. It's always difficult to know how far down the tree of topics you should go to provide a end-to-end explanation. I tried to call this out in the start of the article. These are the "hard parts" of technical writing IMO.
I sometimes put a list at the top, like "This article assumes that you have a working familiarity with Linux namespaces (link to 3rd party intro to that), veth interfaces (link to 3rd party intro to that), [...]."
Good tip
Veth = virtual ethernet interface?
Veth1@2 virtual interface 1 in network 2 namespace.
Netns_1 = network namespace 1.
Just guessing based on context.
The @1 and @2 are the two "ends" of the veth. As described in the text they resemble pipes or a wire.
Great writeup, thoroughly enjoyed! The provided "lab" is especially appreciated.
I'm curious if you had reasons to not use veth in noarp mode.
Not a bad suggestion, may even make the "pwru" analysis a bit simpler. Definitely worth playing with. You can even give it a try in the lab and lmk how it fares :).
"In the context of computer networking, BPF stands for Berkeley Packet Filter. It's a technology used for filtering network packets and allows a user-defined program to determine which packets can be sent/received on the network interface. BPF provides a high-performance way to capture and optionally modify packets as they pass through the network stack, making it a powerful tool for network monitoring, packet analysis, and more complex tasks like intrusion detection and network traffic control. It's widely used in various network applications and operating systems for efficient packet processing."
Source: ChatGPT