Re: pasta behaviour with multiple NICs

[Stefano Brivio <sbrivio@redhat.com>]

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