From nobody Thu Mar 2 17:45:35 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PSJRd4j0Vz3w4Z1 for ; Thu, 2 Mar 2023 17:45:49 +0000 (UTC) (envelope-from vitspec@gmail.com) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PSJRb6nBHz3HDn; Thu, 2 Mar 2023 17:45:47 +0000 (UTC) (envelope-from vitspec@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=gyL6KR0j; spf=pass (mx1.freebsd.org: domain of vitspec@gmail.com designates 2607:f8b0:4864:20::e2f as permitted sender) smtp.mailfrom=vitspec@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-xe2f.google.com with SMTP id v27so41555vsa.7; Thu, 02 Mar 2023 09:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PNWdF3bCnl37BD3/ulXtPhdDNvs/J5StS70nizxrfBY=; b=gyL6KR0jA6i74uryTb1vbBALODsy8T4rq0lSEXLuqEnf/OSr9i5+M/uqp7qJBqi3E/ lDEZPjrGhxG0qRdPBdHGyvfJ3D6vOFcEhBIVdF5uhOHATBjvI9MJ6JrU+Fmcyaw1m0rQ MVaajWJ4F7hBHQNYuBF9W30aJt3W7d7MCxgwewGELdNEtgscSt2ASBN3+9a+KvUmBIWd JHIZt4IswByJGNvpQgbr3iXgqMpJsS9vPbcanYgTa1h08qRLJs6xDHATrYFFQtTQJU3l U6HkOaK3UKzRU4qLIhwdVdy62zjlcGMmR06CIjhdobPxlGK9XNA2TnzziL1aN6HEQo8v w6Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PNWdF3bCnl37BD3/ulXtPhdDNvs/J5StS70nizxrfBY=; b=cgHBMOj8a8dGYF9aBLx93iXukCmMQi2ClPTUeZ+NJYZ3/PmX8J2JMi6TD1xbmfvImr pjaSwACNzE+4TQOK54XQHpzTIuz6XpJ2JasfdYqshCBqI0m34RRbXvDT7ub+yAFXq4Jz YB5W/34DULFEifdAuLlrHOy25PqvXOhZEy6T9xlVv6w25PhYtH2hnj7TlCbNErQ90sxd kIC1M+rBcSWCV1FO7d13NvByBbU+hjUM8qkTCjxfbLXWoLzhBC7NznQ7LMG0UQAHwQG0 GwAIavqa/UR9Gu98SVwFP8SUaRPLPnceBM8/Z1/zi9VnVbDT6796A6o6P/ppBy5yO5Ar iDVw== X-Gm-Message-State: AO0yUKU30Clc+zPuZoGDhyhuG8LXwrzJSFytGfkdpwA9AmqV1Ruf9xeu pG5XB2heVUrFc6NpJrv6+VN9Dc4AA6rfQWfkRfv9livp X-Google-Smtp-Source: AK7set99jCK6KxnWXj4ofjm+UBXEifdMStlSYAhMIvEItaVRS8v1aR19XqABMg0C4xExS6wZgh6ufN2Xk3wxSrypd/4= X-Received: by 2002:a05:6102:2148:b0:402:9b84:1be4 with SMTP id h8-20020a056102214800b004029b841be4mr7091477vsg.6.1677779146533; Thu, 02 Mar 2023 09:45:46 -0800 (PST) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Victor Gamov Date: Thu, 2 Mar 2023 20:45:35 +0300 Message-ID: Subject: Re: ECMP, DF-bit and ICMP "Fragmentation needed" To: Alexander Chernikov Cc: freebsd-net Content-Type: multipart/alternative; boundary="0000000000000a701d05f5ee6621" X-Spamd-Result: default: False [-1.90 / 15.00]; URI_COUNT_ODD(1.00)[1]; HTTP_TO_IP(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.904]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PSJRb6nBHz3HDn X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --0000000000000a701d05f5ee6621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 27 Feb 2023 at 13:57, Alexander Chernikov wrote: > > > > On 26 Feb 2023, at 12:07, Victor Gamov wrote: > > > > Hi All > > > > I have following scheme: > > - LAN segment 10.5.8.0/24 with router1 (10.5.8.1) and MTU=3D1500 > > - two hosts at LAN segment host21 (10.5.8.21) and host22 (10.5.8.22) > > - host21 and host22 has VIP=3D172.16.110.30 configured as LAN-interface > alias > > - host21 and host22 ha BGP peering with router1 and announce VIP to > router1 > > - hostX somewhere at intranet > > - ipsec-tunnel with MTU=3D1400 > > > > ECMP works fine and traffic from other segments to VIP is balanced > between host21+host22 by router1. > > > > The problem is: > > when host21 and/or host22 send large packet with DF-bit using VIP as > source then ipsec-router sends ICMP "Fragmentation needed" and then this > ICMP is _always_ sent to only host22 by router1. > > > > I think it may be hard or impossible to find proper VIP-owner to send > this ICMP. Is it possible to propagate such ICMP to all VIP-owners in > router1 routing-table? Or may some data from ICMP message be used to > properly calculate ECMP-hash to find a real VIP-owner which must receive > this ICMP? > Generally it=E2=80=99s pretty hard to do. The path may go through the mul= tiple > routers which has it own hash calculation + seed to avoid the traffic > polarisation. Personally I=E2=80=99d suggest doing some sort of ICMP repl= ication on > either the source node or the hosts. > Hi Alexander! Thanks for your reply. In my scheme router1 can replicate such ICMP to all VIP-owners. And only router1 knows about both host21+host22 peers -- for all other network devices this VIP is behind router1. --=20 CU, Victor Gamov --0000000000000a701d05f5ee6621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 27 Feb 2023 at 13:57, Alexand= er Chernikov <= melifaro@freebsd.org> wrote:


> On 26 Feb 2023, at 12:07, Victor Gamov <vitspec@gmail.com> wrote:
>
> Hi All
>
> I have following scheme:
> - LAN segment 10.5.8.0/24 with router1 (10.5.8.1) and MTU=3D1500
> - two hosts at LAN segment host21 (10.5.8.21) and host22 (10.5.8.22) > - host21 and host22 has VIP=3D172.16.110.30 configured as LAN-interfac= e alias
> - host21 and host22 ha BGP peering with router1 and announce VIP to ro= uter1
> - hostX somewhere at intranet
> - ipsec-tunnel with MTU=3D1400
>
> ECMP works fine and traffic from other segments to VIP is balanced bet= ween host21+host22 by router1.
>
> The problem is:
> when host21 and/or host22 send large packet with DF-bit using VIP as s= ource then ipsec-router sends ICMP "Fragmentation needed" and the= n this ICMP is _always_ sent to only host22 by router1.
>
> I think it may be hard or impossible to find proper VIP-owner to send = this ICMP.=C2=A0 Is it possible to propagate such ICMP to all VIP-owners in= router1 routing-table? Or may some data from ICMP message be used to prope= rly calculate ECMP-hash to find a real VIP-owner which must receive this IC= MP?
Generally it=E2=80=99s pretty hard to do. The path may go through the multi= ple routers which has it own hash calculation + seed to avoid the traffic p= olarisation. Personally I=E2=80=99d suggest doing some sort of ICMP replica= tion on either the source node or the hosts.
=

Hi Alexander!

Thanks for your = reply.

In my scheme router1 can replicate suc= h ICMP to all VIP-owners.=C2=A0 And only router1 knows about both host21+ho= st22 peers -- for all other network devices this VIP is behind router1.

--
CU,
Victor Gamov
--0000000000000a701d05f5ee6621--