Re: pasta behaviour with multiple NICs

["Ben Woods" <pasta@ben.woods.am>]

Ok - I understand now. Thanks for tolerating my newbie questions - I really appreciate your replies.

On Fri, 25 Apr 2025, at 4:49 PM, Stefano Brivio wrote:
> On Fri, 25 Apr 2025 15:49:16 +0800
> "Ben Woods" <pasta@ben.woods.am> wrote:
>
>> Hi Stefano,
>> 
>> Thanks for the quick response.
>> 
>> I think my questions came from a misunderstanding of how pasta works.
>> I was thinking about the container network namespace directly sending
>> the traffic out the host physical interface based on the IP/gateway
>> inside the netns.
>> 
>> Reading your answer, I think I understand now that in fact the
>> network connection from inside the container netns is connected via a
>> socket to pasta running on the host…
>
> Not even via a socket, it's a tap (tuntap) file descriptor:
>
>   https://passt.top/#pasta-pack-a-subtle-tap-abstraction
>
> with all the traffic encapsulated in Ethernet-like frames (Layer-2).
>
> We also have a "tap bypass" path but that's for loopback traffic only.
>
>> and then pasta simply creates
>> the TCP or UDP socket connection out the host physical interface
>> using the host network stack. Is that correct?
>
> This part is correct, yes.
>
>> That then explains why you’re saying that pasta itself is not
>> choosing the egress interface, route or source IP… it’s the kernel
>> that does that when pasta creates the TCP/UDP connection. Hence the
>> traffic egress interface, source IP and next-hop should be the same
>> as if it originated from a process on the host.
>
> Right.
>
>> It does make we wonder what’s the purpose of assigning an
>> IP/subnet/gateway inside the container netns at all - if all
>> connections are sent via the socket and host pasta process then
>> creates the actual connection?
>
> Because it makes things transparent (again, by default) which is an
> advantage for many applications, for example service meshes, or
> any transport / application protocol that might embed IP addresses in
> the protocol itself (think of SIP for example).
>
> And, albeit with some drawbacks, in general it might also be more
> intuitive for users.
>
> -- 
> Stefano

-- 
From: Ben Woods
ben@woods.am