[HN Gopher] eBPF Networking Techniques - Packet Redirection
___________________________________________________________________
eBPF Networking Techniques - Packet Redirection
Author : ldelossa
Score : 124 points
Date : 2023-12-21 13:18 UTC (2 days ago)
(HTM) web link (who.ldelossa.is)
(TXT) w3m dump (who.ldelossa.is)
| rapidlua wrote:
| Great writeup, thoroughly enjoyed! The provided "lab" is
| especially appreciated.
|
| I'm curious if you had reasons to not use veth in noarp mode.
| ldelossa wrote:
| 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 :).
| mtlynch wrote:
| 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?
| lelanthran wrote:
| Veth = virtual ethernet interface?
|
| Veth1@2 virtual interface 1 in network 2 namespace.
|
| Netns_1 = network namespace 1.
|
| Just guessing based on context.
| lmz wrote:
| The @1 and @2 are the two "ends" of the veth. As described in
| the text they resemble pipes or a wire.
| ldelossa wrote:
| 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 :).
| lfmunoz4 wrote:
| "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.
| mordechai9000 wrote:
| 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.
| atmosx wrote:
| 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.
| ldelossa wrote:
| 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.
| yjftsjthsd-h wrote:
| 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), [...]."
| ldelossa wrote:
| Good tip
| jonstickman wrote:
| Fantastic 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
| ldelossa wrote:
| 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 :)
| e12e wrote:
| > 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:
|
| https://wiki.debian.org/nftables
|
| https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
| RecycledEle wrote:
| "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
___________________________________________________________________
(page generated 2023-12-23 23:03 UTC)