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=YFpfUW09; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 799C45A004E for ; Mon, 19 Aug 2024 11:53:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1724061188; bh=7JDcJqVGkb/p6EjuQB2+ZvcDWdGH0WZte1RbCUsHwT4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YFpfUW09q6lPiB/p8DN2BWTLRIeeL4sVZxCK0oX/XiwBZlUv7viYifU9Dqa3IKfDH CGJ+1W3+Xb8rxhLmkYxjnZiVWeTQhnamo0pnSULJ4SPc1OK2ViE7to9eEVke6pUOlJ fvxJhK7NK3dXhs9pRC149cgIzZNs+Cfsia4uWOqKQdEyUQBzjRCuCTD9CCzy1nDn5E iR1hkDAxFPXrhRiTGYG4y7rSwM/xM3HAVFUktm+tdBTQmMpYjH+5ZEWrHi9xlOxkvD /3hV3t84ImHexzy9nNsSCeYi998CGlqYdvhowD5qY074YS9afQZvvOrF2Gl2KGE9zm SQPQ+DH63EYIA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WnSZr0Mdwz4wcF; Mon, 19 Aug 2024 19:53:08 +1000 (AEST) Date: Mon, 19 Aug 2024 19:52:49 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 00/22] RFC: Allow configuration of special case NATs Message-ID: References: <20240816054004.1335006-1-david@gibson.dropbear.id.au> <20240819112749.63d7476d@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZUlJXjIok1QIMUW3" Content-Disposition: inline In-Reply-To: <20240819112749.63d7476d@elisabeth> Message-ID-Hash: YPN4DRNUNJ3654KK3PZ5RQ6RHHZW7T76 X-Message-ID-Hash: YPN4DRNUNJ3654KK3PZ5RQ6RHHZW7T76 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: 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: --ZUlJXjIok1QIMUW3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2024 at 11:27:49AM +0200, Stefano Brivio wrote: > On Mon, 19 Aug 2024 18:46:31 +1000 > David Gibson wrote: >=20 > > 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. =20 > >=20 > > 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 > >=20 > > 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. > >=20 > > 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. >=20 > 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. >=20 > Then: >=20 > > This "worked" previously, because before this patch, passt would > > translate the inbound connection to have source/dest as link-local > > addresses. >=20 > ...I realised that this worked and forgot about the whole issue. >=20 > > 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. > >=20 > > 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. >=20 > I guess setting keep_addr_on_down (even for "all" interfaces) should > work as well. Sounds like it. I wasn't aware of that one. /me tests.. actually, no it doesn't work.. # sysctl -a | grep keep_addr_on_down net.ipv6.conf.all.keep_addr_on_down =3D 1 net.ipv6.conf.default.keep_addr_on_down =3D 1 net.ipv6.conf.dummy0.keep_addr_on_down =3D 1 net.ipv6.conf.lo.keep_addr_on_down =3D 0 # ip addr add 2001:db8::1 dev dummy0 # ip a 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: dummy0: mtu 1500 qdisc noop state DOWN group default q= len 1000 link/ether c2:02:f2:79:f9:94 brd ff:ff:ff:ff:ff:ff inet6 2001:db8::1/128 scope global=20 valid_lft forever preferred_lft forever # ip link set dummy0 mtu 1200 # ip a 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: dummy0: mtu 1200 qdisc noop state DOWN group default q= len 1000 link/ether c2:02:f2:79:f9:94 brd ff:ff:ff:ff:ff:ff # ip link set dummy0 mtu 1500 # ip a 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: dummy0: mtu 1500 qdisc noop state DOWN group default q= len 1000 link/ether c2:02:f2:79:f9:94 brd ff:ff:ff:ff:ff:ff My guess is that IPv6 being deconfigured because of an unsuitable MTU is considered a different event from a mere "down". > > This kind of opens a question about how hard we should try to > > accomodate guests which don't configure themselves how we told them. >=20 > There's a notable distinction between guests temporarily diverging (in > different ways) and guests we don't configure at all. I'm not really sure what you're getting at here. > It's probably more important to ensure we use the right type of address "type" in what sense here? > (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. >=20 > > 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 > Yes, I still think we should support guests that don't use DHCPv6 or > NDP at all, Well, you still wouldn't *need* DHCPv6 or NDP, but you'd have to manually configure the interface in the guest to match the address you've configured with -a. Just like you'd expect to have to correctly configure your address on a real network. > 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. Hm, maybe. I'm not entirely convinced the cost is so small long term. It's pretty badly incompatible with having multiple guests behind the same passt instance: such as the initial guest bridging or routing to nested guests. I'm actually not sure if encountering this bug makes me more or less in favour of addr_seen. On the one hand I think it highlights the flakiness of this approach; there are situations where we just won't know the right address. On the other hand if shows a relatively plausible case where the guest won't get exactly the address we want it to (it uses NDP but not DHCPv6) Hrm... actually this also shows a potential danger in the recent patches to disable DAD in the guest. With DAD enabled, when the guest grabs a new address, we'd expect it to emit DAD messages, which would have the side effect of updating our addr_seen (although I'm pretty sure I hit this patch before the nodad patches were applied, so that doesn't seem to be foolproof). We could maybe update addr_seen when we send RA messages to the guest - assuming that it will use the same host part (low 64-bits) for both link-local and global addresses. Not sure if that's a widely safe assumption or not. > 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. --=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 --ZUlJXjIok1QIMUW3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbDFeEACgkQzQJF27ox 2GeKBRAAp4sR98SCoJURtLrwvtQoCMdqk8Y4YRKdhzGhCrYqgrpLvDnUqBX0teFu dT6Yc1QfjrRawW3TROyPFsPQFoI7g2Yp721q0t5YyiQ0c6Dp1udpa3qtjsn5mLRA YpA/jN5P51OqWnp8Dlpz6RkSYy/5MZgFiF9aX5TmcDz96xIiUGjyBVlffwR80Ekh /WJVdR7pm4t3jCS8ktA8VihkyeLH2LxmqUuB21U27IjoANms9awGfqArK91a+ugI 7c34wVDmwAi0K/vLD7s7aE2LYe+uLTXMrGadzkKVS5a3Rgh5g6PxjJ4oLvvVVI6E OiGCqjbOsIKUOQFiH88NaO4ElG1CEb9xGXKtIn/4ibOLvUJRo61l6uEJX9nmmCD1 GHGPUORjWUbwEYf2X5ufdOpp85z1mysVcROBTNB7QWfAq+WRwEBGjgF1VS8J84Zb e4Ek6dRAw1Nw7/kalYVf6zcntqLP5EhZijuEBHVhHElZfyguHtmgHKb348JHtCzn hjip2Jbt8GILi8a5SIPTJVzPVbAqalVLFz13edNVUWlaBvgc1/QXtZVfUpegBpla +F/oKpQUi6fkr10PEIXv8gd1Jlu3ZypeCbcZyKmu24KFEOLiGpySN63YaWKK921T 5torRvuv0klwXXVRKwvyOAJgkxiaPveVG1UwH1jqCeA06SSA9f4= =U+lA -----END PGP SIGNATURE----- --ZUlJXjIok1QIMUW3--