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=fail reason="key not found in DNS" header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202312 header.b=pv6fi1vQ; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 0083C5A004E for ; Mon, 19 Aug 2024 10:46:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1724057196; bh=X6A7b5PUINhfP+jx97ZToSiBC+GVQ2JRQSjF8qiZLf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pv6fi1vQXLRroENDV5rQ5XOGybKT5HPiX+81jzPckt0QzHZ06UuMlZ4Bxc3TwCaRz 3p6wrK49lwsDUfsdYV3mRizJ9aWjgB9acHDaqRsGA3BOzOiGHL7Bxncz9HBaTn7u5s vjTNDYqwK1DhCz5CbB1kpG/PyUzDwGK6zolPfaLOVXzy39TauKSpfWS2ABHgfjlAbi tgyTYm8JazkpcXTX1rEq2enzqS8pDZXr8EAVexM0Dq2vtrx7JHGBgYKRD0Sf/r/naw JlZX9gVRwAvIFGQm+70A7CbETx+f0Q3JVMjsRZ7pB4UMnGbo0WXCowipX1/aUsEinh xwtXxvvd6mhsg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WnR643jbPz4wd6; Mon, 19 Aug 2024 18:46:36 +1000 (AEST) Date: Mon, 19 Aug 2024 18:46:31 +1000 From: David Gibson To: Stefano Brivio , passt-dev@passt.top Subject: Re: [PATCH 00/22] RFC: Allow configuration of special case NATs Message-ID: References: <20240816054004.1335006-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GLF28aOF5rHwvZEQ" Content-Disposition: inline In-Reply-To: <20240816054004.1335006-1-david@gibson.dropbear.id.au> Message-ID-Hash: Z4IXWOZAYLF5ZZ4KETRJGU3B6EH7ZO7C X-Message-ID-Hash: Z4IXWOZAYLF5ZZ4KETRJGU3B6EH7ZO7C 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: 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: --GLF28aOF5rHwvZEQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 16, 2024 at 03:39:41PM +1000, David Gibson wrote: > Based on Stefano's recent patch for faster tests. >=20 > 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. >=20 > Suggestions for better names for the new options in patches 20 & 22 > are most welcome. >=20 > 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. >=20 > 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 >=3D 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. This "worked" previously, because before this patch, passt would translate the inbound connection to have source/dest as link-local addresses. 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. This kind of opens a question about how hard we should try to accomodate guests which don't configure themselves how we told them. 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. --=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 --GLF28aOF5rHwvZEQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbDBlQACgkQzQJF27ox 2GeB8A/+IQEM11lPkEE7bTsTJhX1JREqbd1AFk6xzmQPnZPkDDi/rJJjKgKrFbjG w3LcyhB8xH5MRx/HBDCgttgOzeEHp3eqtDuJfXhq31JasFdAenqHcq3r7Ti9w8pT 249zdCJmt8gcVaM7jcWGk0wFU/b7bXfAKARs9q28H0gpKSMt8cLEQKtAhwAHpi3W LQvlLA9LhtjLNSWEpQmam71fWaGs130dM340lRXyNjeeGLUuhsEcwZyGkgDAAiFi yROtNywOjVwu1lWemq+Y/rIpMay+T0LfL/QKUJr3kHk/YyPHTRHS4nQut2bZ6dtj iFPjUtwsdsrxWblQLNWGrHp+lbF59GnKSmn91+b30ItPK5XCGrQGATmWuLUc5Y82 NwuicU7C/K037CekhNw8hFYVO5h1SpRt9Di2uwlK1ir3c5fQZuYTlbW8IGIHbQB6 Ulrog7vOgR2K1rNKRU1RaZpn/RYnPLOfEku0xexWLu1uL+llsUGKqrtEQyjC9+8T FROuescDdkbV0M6+lGXYpZAGcrFaDEjTX/OlmPGKO2+QOxHEYL/m/kJGMz5+uZyL vjK4SsYIKD0tp44/KmCfuxdGJfVlZ/K9HUi86zOgMU/7H5TXZY4nnWyO1P7t8DDd Tyag2z8oL8PKR5hpl038+zwVzYaHI+IR+CaFA/no2WYSAQY8aEM= =KFRy -----END PGP SIGNATURE----- --GLF28aOF5rHwvZEQ--