From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FifO/Muy; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 0C17A5A026F for ; Fri, 25 Apr 2025 10:50:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745571005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2nGZ8VWouoB9S0mH5A8HIfgMkjf/whEWu9DeqgSDc3w=; b=FifO/MuyMBAtPencVNdBLoOTFW71p8iODXzfMjDCKuMK88VNPXcuuLCi2gk0C0TH4XK+bL /FCLy1pvm/Koa0D24juFY45s36OUuLQ2wdMqQLnmWBlqR212JcuEAmlhIz9Y2oEPLesxIb uJEcsNeR6876jdmk3irQXldLTKxirBI= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-522-n6UIJHK8OZOCEypXm1u1oQ-1; Fri, 25 Apr 2025 04:50:03 -0400 X-MC-Unique: n6UIJHK8OZOCEypXm1u1oQ-1 X-Mimecast-MFC-AGG-ID: n6UIJHK8OZOCEypXm1u1oQ_1745571003 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43efa869b19so11023205e9.2 for ; Fri, 25 Apr 2025 01:50:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745571002; x=1746175802; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2nGZ8VWouoB9S0mH5A8HIfgMkjf/whEWu9DeqgSDc3w=; b=VbVGq5wm0rE7vbliPvNp/svAXNYPZ0wz4WJI4TrJRMG36MJekw6K86cedMl4eiwTMa 1gLwUMDpH01PKjjx43NnQf8Ip/XNl2bbYqHz3AAtElgrVjgHnUeJ5EOt4eUFE1NzLHFC 80pVBmlldS72YWkFXUqYVLPwOLowiz2X4snDOmZ705OqV2jPBNhaarbadFFKW3bppCTq TmGIakRXi/N/Dl7kFsWrBjah8K2zYI4DFmxScGSm8LIBHZT7phGJFw9926WhGfOH3nHv UPYmTrJ460HUuQ3IgIoZwYLUBu6t1HnlW4/woQsJEE0j8MvJ9bqSy+VStvtxTY5qgN8k hpVg== X-Gm-Message-State: AOJu0Ywr+A/q3XDXBZ8A85ObcO8eQ0naScUW/qW9bvzES9PkP0iCnFXv 37ZCtUvbibAJRpdYmIa3rA/WxN/idsCVBo3CqDQtNYKvsJs+p7HqmuH93V0ARUxR09qiicEtFSK vyiExMALXNvlemWJtSNDD+9D4twc9ycW7aRZzx/LDXXs0QSv1IVyzh7Y+uAk= X-Gm-Gg: ASbGncsBVsNqUIsvBbT/vS2IfW2CxBXkr0Wtagfa2SRqHyaT02nvntukNwe2vJ3GmOJ 7ZF2ZU6Ju2Q61L89SfmR0KWaIHSJFF6OOPIVec6xamj6AcKVMymfytDC9NPc5ktLBzGuE0suhMn 5+m9rI6iZxGrt5dZ3jWQT0Z7qu9uPKhp+1+ej4CnscSS32EB0XmjHHuH3EWtHhUUPBL12/RFTVW AXV4Xd0hCcMpwe5b7BhewCwk2GOB4GV3lKbewb9YpHgA2bV1aNpIwTQfc9WoDsvfeoi7LwMSHWO qWfFTivWEYcqR/H84CRNsgY= X-Received: by 2002:a05:600c:3542:b0:43c:fbe2:df3c with SMTP id 5b1f17b1804b1-440a669dbd2mr10714255e9.26.1745571001571; Fri, 25 Apr 2025 01:50:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE4RQRG7PGqoQ6WHqyIsje0z9BW7iUnceSKRhm/n2XRs5TQO80Wx4520ExgP0XrdAP1xN8wXw== X-Received: by 2002:a05:600c:3542:b0:43c:fbe2:df3c with SMTP id 5b1f17b1804b1-440a669dbd2mr10713985e9.26.1745571001137; Fri, 25 Apr 2025 01:50:01 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-440a53108f2sm17059325e9.19.2025.04.25.01.50.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Apr 2025 01:50:00 -0700 (PDT) Date: Fri, 25 Apr 2025 10:49:56 +0200 From: Stefano Brivio To: "Ben Woods" Subject: Re: pasta behaviour with multiple NICs Message-ID: <20250425104956.75d740c8@elisabeth> In-Reply-To: References: <38893f85-ca3d-4e1e-929d-236df89ab9f6@app.fastmail.com> <20250425092620.074e2cce@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: LXuvAch2AbluxIzdkbYOizt3YXpLnxDU_phB-MmAqkE_1745571003 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6ISX6TLSIWUEZW4KSEDM2LX76VEYQRXI X-Message-ID-Hash: 6ISX6TLSIWUEZW4KSEDM2LX76VEYQRXI X-MailFrom: sbrivio@redhat.com 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: 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: On Fri, 25 Apr 2025 15:49:16 +0800 "Ben Woods" wrote: > 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 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=E2=80=99re saying that pasta itself is not > choosing the egress interface, route or source IP=E2=80=A6 it=E2=80=99s t= he 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=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? 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. --=20 Stefano