From owner-freebsd-net@freebsd.org Wed Aug 19 08:41:44 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 775F03B75CE for ; Wed, 19 Aug 2020 08:41:44 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWh8l3DKlz4RMW for ; Wed, 19 Aug 2020 08:41:42 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from venus.yoonka.com (venus.yoonka.com [10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 07J8fZ6A038112 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 19 Aug 2020 08:41:35 GMT (envelope-from list1@gjunka.com) Subject: Re: net.add_addr_allfibs=1 behaviour deprecation To: freebsd-net@freebsd.org References: <236161595078191@mail.yandex.ru> <348771597489519@mail.yandex.ru> <0f321bdc-240e-0f85-915b-c9bdd7daa01b@freebsd.org> <837391597778482@mail.yandex.ru> From: Grzegorz Junka Message-ID: <84c582aa-11a0-a64c-4c4e-cfc39373a1d7@gjunka.com> Date: Wed, 19 Aug 2020 08:41:34 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <837391597778482@mail.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4BWh8l3DKlz4RMW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [0.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.60)[0.599]; DMARC_NA(0.00)[gjunka.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 08:41:44 -0000 On 18/08/2020 19:27, Alexander V. Chernikov wrote: > 18.08.2020, 09:17, "Grzegorz Junka" : >> On 18/08/2020 07:54, Julian Elischer wrote: >>>> >>>>  No objections has been received. >>>>  Next steps: >>>>  * Switch net.add_addr_allfibs to 0 ( >>>>  https://reviews.freebsd.org/D26076 ) >>>>  * Provide an ability to use nexthops from different fibs >>>>  * Remove net.add_addr_allfibs >>>>>  Timeline: >>>>>  Aug 1: summarising feedback and the usecases, decision on proceeding >>>>>  further >>>>>  Aug 20 (tentative):  patches for supported usecases >>>>>  Sep 15 (tentative):  net.add_addr_allfibs removal. >>>>> >>>>>  [1]: [base Contents of >>>>>  /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=178888&view=markup) >>>>>  [2]: [base Diff of >>>>>  /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&) >>>>> >>>>>  /Alexander >> Agree completely, defaulting "add_addr_allfibs" to 1 broke many existing >> installations, which goes against the least surprise principle so many >> times advocated on FreeBSD lists. >> >> This is just one example: >> https://forums.freebsd.org/threads/strange-behavior-of-setfib-since-freebsd-12-0.73348/ >> >> Now, changing the default again might again break existing >> installations, which shouldn't be a reason for not doing it, but might >> be a reason to better communicate it this time around. > I plan to communicate it the following way: > 1) this thread > 2) GONE_IN13 in the sysctl (which will print console message when set to 1) > 3) Release notes > Do you think there are other communication channels one should try to use? When I was looking for information about why the routing doesn't work as expected I didn't know about this settings but couldn't find anything relevant in the Handbook, so would really love to see this somehow mentioned and explained how to use it in the Handbook if possible. Thanks GrzegorzJ