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=E9JCj8db; 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 579B15A026F for ; Thu, 25 Sep 2025 15:14:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758806086; 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=wdv71Hxzr/+fEAA4qNYdrXMwouM2vWZjLYmcW3Wa/hc=; b=E9JCj8db78w5jBRSgCs8V4pQgR4YNY1FsraJ/PXuzP+7a3VuV8OYATea3k+yQjBzcKwb93 aOMP8MrNBES1zwbcRzXU0qG6va16YA6aRW9OFto2fAX8mfBmJKKul0Nf7iLhJN3zpZft/L 7NNPuhK0+vf3sq5w2jNyWWfk212JVFU= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-510-4RQ0ubgqNf-CF5WVscrlMQ-1; Thu, 25 Sep 2025 09:14:44 -0400 X-MC-Unique: 4RQ0ubgqNf-CF5WVscrlMQ-1 X-Mimecast-MFC-AGG-ID: 4RQ0ubgqNf-CF5WVscrlMQ_1758806084 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-78e0ddd918aso17606286d6.1 for ; Thu, 25 Sep 2025 06:14:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758806084; x=1759410884; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wdv71Hxzr/+fEAA4qNYdrXMwouM2vWZjLYmcW3Wa/hc=; b=q9efjIroixdfskd6BC9DbQ2Y3R0a1i873q2gfEl0f+UE6vJNAZzl9j34nBCfRwORLI 9c7TIXxnvLQrgyDXTvpMbIUZIE9osabiCVWbleSR6gbmNKxM/hkiL0CTLOa/AxfgoRjY CsEsE1TyynSi4OwB8JGmoq+VRvClFiZ4IoMBBlllNKNhHx25kVUbMzMv9nKXbNh6qJn2 5qxzIcJrxW5mi81srp+1/zR0SeJQI4v3I+q6NAaqcyZjeFZ2k6vI9tQaMnOM5xHwWdU5 nDpz8Gs3fGitMakVdIBU8eUUjpsJsacXjouU7a8hto/0a/W9XdAWcjskJytxRsFps6Cm Xzaw== X-Forwarded-Encrypted: i=1; AJvYcCX8gD1Ya3ctCPzxHNFZFxQxf41HXYoWXJS7plfLbiCJttvLfxsVedY6j/xfzptNyttILGocEBk5QBo=@passt.top X-Gm-Message-State: AOJu0YyF6wCNyDK9vYFtTDuUZesl//iuBJAgWDB8VwCbh2xFqEXdEoU3 U+ymniT4P7vZyvHT0nZIgR/+zVC3dKVf76/hinejYp0Vg6lbNeuiDC3o4N+c+bNKszYTletnWpl OywTUOikpXN3nUN30Fs4+TWIUpr3INcWjiFy0PA+9GKtGvguv0PEJGw== X-Gm-Gg: ASbGnctJ18NTIM+Zk99xGGmsde6WLXaJAZ1whlgacuRi/0hTKgAIYd5g7j+78r+eqzT v0EEYYoyQORWPYSuteKy3HHgGAgD6gdpeR8+O5MqXil0HokiO3OSAQvb9xU2x+Ohi7TgRzoe/mC snyovYV9E13D05D56NEC5OBA8WdpKxY6tjU8rv39JKOOIayDeGnPdhS+DEfeldpv/Z/1/Djo5HP uT71fhEITj13wt2eJLW9prUZZgcHXToYJ236cPj99pndWyT4UnFdaispJsvDyrDE8qcbBMONYzz M1QmFGxCKJcLJb3rT/3+ttYjgj9jwV6ZXXMvYfwnhxc4ob9VIyY5tO94QKKWaLIJGjx+UIRteP/ BVB72cy/97A== X-Received: by 2002:a05:6214:5093:b0:805:7dfb:2bd9 with SMTP id 6a1803df08f44-8057dfb2c02mr19076206d6.33.1758806084338; Thu, 25 Sep 2025 06:14:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEq3EPkzW/9N5+H7qBvoFxyy9Anpeb3ivCihZ/+Pwa2rdEY2SlMYdhJLpbq38fWOxELQQaADA== X-Received: by 2002:a05:6214:5093:b0:805:7dfb:2bd9 with SMTP id 6a1803df08f44-8057dfb2c02mr19075756d6.33.1758806083764; Thu, 25 Sep 2025 06:14:43 -0700 (PDT) Received: from ?IPV6:2001:4958:2206:8901:6025:1483:4146:72dd? ([2001:4958:2206:8901:6025:1483:4146:72dd]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-80175168d7dsm10963156d6.68.2025.09.25.06.14.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Sep 2025 06:14:43 -0700 (PDT) Message-ID: Date: Thu, 25 Sep 2025 09:14:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 9/9] arp/ndp: send gratuitous ARP / unsolicitated NA when MAC cache entry added To: David Gibson References: <20250924011330.1168921-1-jmaloy@redhat.com> <20250924011330.1168921-10-jmaloy@redhat.com> <5dda48fc-d854-436d-acd1-734d461efd59@redhat.com> From: Jon Maloy In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: l0bYuMNZSCPe1LJdxrafj6H2fMHKY1Fb4N-26pFHpwU_1758806084 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: EWMZGMQXPH3RAZQZY25E5OHBFL3TB2XP X-Message-ID-Hash: EWMZGMQXPH3RAZQZY25E5OHBFL3TB2XP X-MailFrom: jmaloy@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: sbrivio@redhat.com, dgibson@redhat.com, passt-dev@passt.top 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 2025-09-25 02:36, David Gibson wrote: > On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote: >> [...] >> >> I experimented a bit with this. My test program is a simple UDP >> client-server pair, exchanging first 3 UDP messages client->server, followed >> by >> 3 messages server->client. > > With the client on the guest, and server outside? How is the outside > machine arranged - is it a physically separate host? A bridged VM or > container on the same host? Something else? It is a physically separate host. > >> First, I changed the main() loop a bit, so that netlink events are >> handled before all other events, if any. (Basically, I added >> an extra loop before the main loop, only handling netlink events, before >> moving on to the main loop (where netlink events had been excluded.) >> This should secure absolute priority of netlink events before any other >> events. As you will see below, this made no difference to the scenarios >> I describe. > > Drat. >> 1: When starting the container, I notice that there is no subscription >> event in PASTA, even though I can see the entry for the remote host >> is present in the host's ARP table. There is never any event coming >> up even if I wait for 10+ minutes. > > Huh.... do we need to do something to ensure we get events for > existing entries in the host ARP table, not just ones that are added > or updated after we're running? It doesn't seem to be possible, but even if it were it wouldn't help us much if the entry isn't here, which is also a problematic case. See below. > >> 2: The first UDP is attempted sent from the guest. An ARP request is >> sent to PASTA, and responded to with the 9a:9a: address. > > Maybe we still need to explicitly ask for an ARP resolution when the > guest ARPs. I think so. If we limit this to ARP and NDP, this should be unproblematic. > >> 3: The UDP, and two more UDPs, are sent via PASTA to the remote host. >> Those are responded to and sent back to the guest. >> 4: I now receive a neigbour event, and can update my cache, but since >> there is still no new ARP request from the guest, even if I wait >> for many minutes, he continues in the belief the old address >> is confirmed. >> 5: If I run the same test again after a few minutes, >> the guest *does* send out an ARP request a few seconds after the >> message exchange, and is now updated with the correct address. >> >> - If i run this sequence in the opposite direction everything seems to >> work ok, at least if the ARP entry is already present on the local >> host. >> >> - When I delete that ARP entry before running the sequence, > > Delete it from the host ARP table, you mean? Yes. > >> a neigbour >> event shows up after some seconds, but it can take up to a minute, at >> least. > > Oof. I guess some delay is inevitable, but that's way longer than I > would have expected. > >> If I run my sequence from the remote host before that happens, >> there will be an ARP request from the guest (for the response UDPs), >> responded to with the default tap mac, and it will remain >> like that for a long time, since the guest considers the mac address >> confirmed. It doesn't help much that a neigbour event shows up some >> seconds after the exchange. >> >> In brief, the guest *will* be updated eventually, but depending on luck >> and timing it may take a long time, at least several minutes. [...] >>>> + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); >>>> + memcpy(req.am.tip, &ip, sizeof(req.am.tip)); >>> >>> So, I was trying to check if it made sense to use the same IP for both >>> source and target here, and came across >>> https://www.rfc-editor.org/rfc/rfc5227#section-3 >>> >>> Which suggests we should (counter intuitively) be using ARP requests, >>> not ARP replies for announcements. >> >> Instead of gratuitous ARP, you mean? I can try it. > > It suggests that what's traditionally meant by "gratuitous ARP" is > actually ARP requests, not responses as you might expect. There's > some detailed reasoning there, I'd give it a read. So will I. It sounds interesting. ///jon >