From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=K4Hb7Bs0; 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 ESMTP id 2D1925A004E for ; Mon, 19 Aug 2024 11:27:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1724059676; 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=0n8uEJIhy/xOoiybw59acAEx6GNBXOLJNu/l7FMJ8xc=; b=K4Hb7Bs0Rrqq2qwxkMkAsPo3Aj0XDPI1tj47xyVPoz4YLfDZxPAHyAYQgHef7CUMUYRFuY CnZAq4AyQcfR04bFzGMWArdrwZ+zdEqFfKtFaUS+QMpT+QdeBfgXhY3knOLam4K4NNPIin xMkJZIq/iI7fQCbiQYAUJh8ylmAVadM= 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-592-8wMbdlVsMDusy2cY2yo9pA-1; Mon, 19 Aug 2024 05:27:54 -0400 X-MC-Unique: 8wMbdlVsMDusy2cY2yo9pA-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4280291f739so34792675e9.3 for ; Mon, 19 Aug 2024 02:27:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724059673; x=1724664473; 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=0n8uEJIhy/xOoiybw59acAEx6GNBXOLJNu/l7FMJ8xc=; b=vXBQbJ245rpHjhNd0xmlP/tz3cGqubNFWeSIkVk8JDDCEnqavqS0Ljw5Bg3rzrLhZH 1zFNQosiW/EE9TFjstIwsWEff1R3bKJmDyElKYzEiwRUR9ra5cVmhadE2N0kxbLDssue ec1+tZlMZS+xdjWOKidkfaHwYnruazchS4s+hdcHbnHOfW8ZpyFmS/Djhn4dplakREXe ApMR1RmucmnWNC3s5jrYmccmzIBj9VWbHcNNW8x98ao5AGEtYxf/3vUbPYb1T3WQaUsv LZxrLMpXg/57nZnjYelhiqynbuvFvzWKB7OluVV25sARjJWNNo8E26BF5QtEkL7dOiGr 3ywA== X-Gm-Message-State: AOJu0Yw7sGI4RT4Yy2yA+0GWncYmWe2Z5kcL5nmc4YMjSypTLGdicYla 2HGf75Qh6mOYko8Ld/jmEm82dTRCBfIszOmkyQWV93Lx+Aj7H6WkYwObMKq8T7RAhCt7eXxoiQ2 e/SlV3biu6Jv7h4Ch3NudFXBEifY73UC90lWqcDRFoe8vt8YJ3w== X-Received: by 2002:a05:600c:138c:b0:428:1eff:78ec with SMTP id 5b1f17b1804b1-429ed7ae660mr86366805e9.18.1724059673301; Mon, 19 Aug 2024 02:27:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH3ruYd5wMj8+OxwiNeCZqjVxz9LNwCB+IGuz9r9jv4QSQ+82cGZzz/lbcppFRrQQWmTa8r9g== X-Received: by 2002:a05:600c:138c:b0:428:1eff:78ec with SMTP id 5b1f17b1804b1-429ed7ae660mr86366635e9.18.1724059672749; Mon, 19 Aug 2024 02:27:52 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429ed648f0csm103117585e9.9.2024.08.19.02.27.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 02:27:52 -0700 (PDT) Date: Mon, 19 Aug 2024 11:27:49 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 00/22] RFC: Allow configuration of special case NATs Message-ID: <20240819112749.63d7476d@elisabeth> In-Reply-To: References: <20240816054004.1335006-1-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 5ITNALZGBVVKJYQVMFYDCIXZPH4MOL5A X-Message-ID-Hash: 5ITNALZGBVVKJYQVMFYDCIXZPH4MOL5A 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-dev@passt.top, Paul Holzinger X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, 19 Aug 2024 18:46:31 +1000 David Gibson wrote: > On Fri, Aug 16, 2024 at 03:39:41PM +1000, David Gibson wrote: > > Based on Stefano's recent patch for faster tests. > > > > Allow the user to specify which addresses are translated when used by > > the guest, rather than always being the gateway address or nothing. > > We also allow this remapping to go to the host's global address (more > > precisely the address assigned to the guest) rather than just host > > loopback. > > > > Suggestions for better names for the new options in patches 20 & 22 > > are most welcome. > > > > Along the way to implementing that make many changes to clarify what > > various addresses we track mean, fixing a number of small bugs as > > well. > > > > NOTE: there is a bug in 21/22 which breaks some of the passt_tcp perf > > tests. I haven't managed to figure out why it's causing the problem, > > or even what the exact triggering conditions are (running the single > > stalling iperf alone doesn't do it). Have to wrap up for today, so I > > thought I'd get this out for review anyway. > > I've identified the bug here. IMO, it's a pre-existing problem that > only works by accident at the moment. The immediate fix is pretty > obvious, but it raises some broader questions > > The problem arises because of the MTU changes we make in order to test > throughput with different packet sizes. Specifically we change the > MTU to values < 1280, which implicitly disables IPv6 since it requires > an MTU >= 1280. When we change the MTU back to a larger value IPv6 is > re-enabled, but some configuration has been lost in the meantime. > > After the MTU is restored the guest reconfigures with NDP, but does > not re-DHCPv6. That means the guest gets a SLAAC address in the right > prefix but not the exact /128 address we've tried to assign to it. > However, at least with the sequence of things we have in the tests, > the guest never sends any packets with the new address, so passt > doesn't update addr_seen. When the inbound connection comes we send > it to the assigned address instead of the guest's actual address and > the guest rejects it. I still have to take a closer look, but I'm fairly sure I hit a similar issue while I was writing these tests originally. I pondered reconfiguring the address via DHCPv6, or using the keep_addr_on_down sysctl (net.ipv6.conf..keep_addr_on_down), which was added around that time. Then: > This "worked" previously, because before this patch, passt would > translate the inbound connection to have source/dest as link-local > addresses. ...I realised that this worked and forgot about the whole issue. > We *do* have a current addr_ll_seen because (a) it won't > change if the guest doesn't change MAC and (b) when IPv6 is re-enabled > the NDP traffic the guest generates will have link-local addresses > that update addr_ll_seen. With this patch, and a global address for > --map-host-loopback, we now need to send to addr_seen instead of > addr_ll_seen, hence exposing the bug. > > In the short term, the obvious fix would be to re-run dhclient -6 in > the guest after we twiddle MTU but before running IPv6 tests. I guess setting keep_addr_on_down (even for "all" interfaces) should work as well. > This kind of opens a question about how hard we should try to > accomodate guests which don't configure themselves how we told them. There's a notable distinction between guests temporarily diverging (in different ways) and guests we don't configure at all. It's probably more important to ensure we use the right type of address (security) rather than ensuring we somehow manage to deliver packets at any time (minor glitch otherwise), also because the one you describe is something we're unlikely to hit outside of tests. > Personally I'd be ok with saying that nothing works if the guest > doesn't configure itself properly, thereby removing addr_seen and > addr_ll_seen entirely. But I think, Stefano, you've been against that > idea in the past. Yes, I still think we should support guests that don't use DHCPv6 or NDP at all, or where related exchanges fail for any reason. It improves reliability and compatibility at a small cost. In this case, I think it's a nice feature that we would resume communicating as soon as the guest shows its global unicast address. If the cost is using the wrong type of address, then not, I'm not suggesting we do that, so I think the change from this series is desirable, but in a general case, things just work and we don't break anything, as far as I know. -- Stefano