Live data from Hacker News

eBPF Networking Techniques – Packet Redirection

who.ldelossa.is

1–10 of 17 posts

Re: eBPF Networking Techniques – Packet Redirection

#3
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?

Re: eBPF Networking Techniques – Packet Redirection

#4
post #3

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 expla…

Veth = virtual ethernet interface?

Veth1@2 virtual interface 1 in network 2 namespace.

Netns_1 = network namespace 1.

Just guessing based on context.

Re: eBPF Networking Techniques – Packet Redirection

#5
post #3

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 expla…

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.

Re: eBPF Networking Techniques – Packet Redirection

#6
post #3

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 expla…

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 :).

Re: eBPF Networking Techniques – Packet Redirection

#7
post #2

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 :).

Re: eBPF Networking Techniques – Packet Redirection

#8
post #3

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 expla…

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.

Re: eBPF Networking Techniques – Packet Redirection

#9
post #8
post #3

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 expla…

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.

Re: eBPF Networking Techniques – Packet Redirection

#10
post #6
post #3

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 expla…

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…

"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.
Post reply on HN