4 ms·

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

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 3y ago
Veth = virtual ethernet interface? Veth1@2 virtual interface 1 in network 2 namespace. Netns_1 = network namespace 1. Just guessing based on context.
- lmz 3y ago
  The @1 and @2 are the two "ends" of the veth. As described in the text they resemble pipes or a wire.
ldelossa 3y ago
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 3y ago
  "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 3y ago
    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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      Good tip

lelanthran 3y ago

Veth = virtual ethernet interface? Veth1@2 virtual interface 1 in network 2 namespace. Netns_1 = network namespace 1. Just guessing based on context.

lmz 3y ago
The @1 and @2 are the two "ends" of the veth. As described in the text they resemble pipes or a wire.

ldelossa 3y ago

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 3y ago
"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 3y ago
  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 3y ago

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 3y ago
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 3y ago
  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 3y ago
    Good tip