From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202504 header.b=P4lTcaGv; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id C2CB65A0008 for ; Mon, 28 Apr 2025 14:59:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202504; t=1745845163; bh=K5Eiv9KEUgBoh0y5U2fRez4ZNANVKISv4QztBOqJji0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P4lTcaGvwA8BBNM8nBSq2YqfwSx+oIFgoxhbJ/OUL7UZffKKqZCu/H6D4T539G/ob lvOb1LeTtPDkXER5N+4C9e+PJ68tEBtoRuRN03dhbw2Xszt/TJ/93uuZq8q/WbVUqo 92RYFgDikUSOyJ+0Lz5WGXFDpngP7fMYq4QA0Z7F7wX9rDaEPfRLOAVlCp1IaEUc8f 4pwy/ySzlV6C2TtKLiC3jVjdMpJFo3JF5koijzNgfJbHEo4MTg+bUeOK4+jK8JlZr2 mC1ISmQzZ52c0kSkOL4fekp7ploICpKvCjlWXswxgGWIOuOTu/aT5ju+F7CTRYh/PS XA3wzVCR+nrUA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ZmNnR2PZ9z4xD9; Mon, 28 Apr 2025 22:59:23 +1000 (AEST) Date: Mon, 28 Apr 2025 11:02:36 +0700 From: David Gibson To: Stefano Brivio Subject: Re: pasta behaviour with multiple NICs Message-ID: References: <38893f85-ca3d-4e1e-929d-236df89ab9f6@app.fastmail.com> <20250425092620.074e2cce@elisabeth> <174557100872.151934.16258096252005211440@maja> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j73PfUAiNMhkU2Ig" Content-Disposition: inline In-Reply-To: <174557100872.151934.16258096252005211440@maja> Message-ID-Hash: UUPLUPBAZGD2YN2P52C2CVCMZEWG5I3S X-Message-ID-Hash: UUPLUPBAZGD2YN2P52C2CVCMZEWG5I3S X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Ben Woods , passt-user@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: "For passt users: support, questions and answers" Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --j73PfUAiNMhkU2Ig Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 25, 2025 at 10:49:56AM +0200, Stefano Brivio via user wrote: > Date: Fri, 25 Apr 2025 10:49:56 +0200 > From: Stefano Brivio > To: Ben Woods > CC: passt-user@passt.top > Subject: Re: pasta behaviour with multiple NICs > Organization: Red Hat > List-Id: "For passt users: support, questions and answers" > >=20 > On Fri, 25 Apr 2025 15:49:16 +0800 > "Ben Woods" wrote: >=20 > > Hi Stefano, > >=20 > > Thanks for the quick response. > >=20 > > 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. > >=20 > > 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=E2=80=A6 >=20 > Not even via a socket, it's a tap (tuntap) file descriptor: >=20 > https://passt.top/#pasta-pack-a-subtle-tap-abstraction >=20 > with all the traffic encapsulated in Ethernet-like frames (Layer-2). >=20 > We also have a "tap bypass" path but that's for loopback traffic only. >=20 > > and then pasta simply creates > > the TCP or UDP socket connection out the host physical interface > > using the host network stack. Is that correct? >=20 > This part is correct, yes. >=20 > > That then explains why you=E2=80=99re saying that pasta itself is not > > choosing the egress interface, route or source IP=E2=80=A6 it=E2=80=99s= 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. >=20 > Right. >=20 > > It does make we wonder what=E2=80=99s 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? >=20 > 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). I think reasonable people can disagree on exactly what "transparent" should mean in this context. Mostly we try to make networking inside the container look as much like networking on the host does as possible. Of course, we can't make it 100% alike, so sometimes "as close as possible" is more confusing rather than less. I have ideas for how to rework this in ways that will be both more flexible and (I think) less confusing. However, because there's not a lot of functional difference, it's been a pretty low priority to implement. I hope we can get to it some time, but we don't really have any idea when. > And, albeit with some drawbacks, in general it might also be more > intuitive for users. >=20 > _______________________________________________ > user mailing list -- passt-user@passt.top > To unsubscribe send an email to passt-user-leave@passt.top --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --j73PfUAiNMhkU2Ig Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmgO/dsACgkQzQJF27ox 2GfqqQ//eKXimKIAIaoiObH2mxQq5fMT9KklKVgbJHQGuetRHfbyC7rDYoCjS+Kp 32mGwr/zaQxfpne2Z0JB1btR9pi84afSVGgw1YLqUw4MdaqBXpaS9q2mNBNTaX6l 8IZfPIsgisCi1J4jz6I1DN01KbbQ5vYF60y/N6kHQj66DaLNFj9mtVGiQdTchBcu I05TjpTmvseVhqHiy/zpsrVS1EFj09xbieiPJNnYb7Sxq5HDb2YhTEaTrAQXCaoh NjipnkQvlDHDgJ+I4s0Pugit7qWIv7rYOhYRIrix+01Pl4ccb+g22FtROpXuoP9n UdaOOPXRxHBH5wJGvO3VtbVOmoTM8ZVzaznh0ytcVrw4eCBVlnXtojHA7SLH63Xl yKNTm5nH1JBZn5C456rt266G7MBqkIdK7q5yaaQ/UB6Owby9uY4Ay31OoeCwjdBM IBfApizMOrFSYbxZbVRhHlRCHBpovgBwf5y1fy0v6Lo5hcX3HI/kX06OWfYh7oWU 9a+xToXxJDI/kzZlhdH4jfyraga/j6QLB5l4A9/2dyKfQTx9qDK7B1cByFhP/E7w GtllBL1qMesA1hSwkoWJXWiXUmZLEVXRkbxkCCKoF7m/EpzAmbzFQKx7fFPgB4q5 aqnhiabXpistkcjb77z4GQSWbY9w8Z9T0PbJHd+A0dH3BRdxoKc= =TjJc -----END PGP SIGNATURE----- --j73PfUAiNMhkU2Ig--