From owner-freebsd-stable@freebsd.org Mon Feb 8 23:36:06 2021 Return-Path: Delivered-To: freebsd-stable@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 82FB5545F72 for ; Mon, 8 Feb 2021 23:36:06 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500o.mail.yandex.net (forward500o.mail.yandex.net [37.140.190.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZMpr5cBDz3KgR for ; Mon, 8 Feb 2021 23:36:04 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from vla1-74593b5592df.qloud-c.yandex.net (vla1-74593b5592df.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:4d20:0:640:7459:3b55]) by forward500o.mail.yandex.net (Yandex) with ESMTP id 11DF460093; Tue, 9 Feb 2021 02:36:01 +0300 (MSK) Received: from localhost (localhost [::1]) by vla1-74593b5592df.qloud-c.yandex.net (mxback/Yandex) with ESMTP id cq5hhWF8fT-ZxHK6aMK; Tue, 09 Feb 2021 02:36:00 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1612827360; bh=juARRH8nJt/7xLhWFNvVqu083xx+CPNdF5lNDWeUORw=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=OLmlVcMJQ5JQQzgweYeoaIXh4Mf4JjWGQviBEmxKtgYHj9uSC0QeTEpshvByUhH7T 4ipeosn2flQsM2O5wmj1GJVE5EouvTdDzcdpEWcGRXjnrt3GfIn3s0K6FmVWvb4uKy 8eKcjAs5/WtTcgtw+ufXPTsmJ754/HZSzufoRTOM= Received: by vla4-fbefcb3b0074.qloud-c.yandex.net with HTTP; Tue, 09 Feb 2021 02:35:59 +0300 From: Alexander V. Chernikov To: Marek Zarychta , mike tancsa , FreeBSD-STABLE Mailing List In-Reply-To: <53ef5715-42ce-aad0-9a8b-11d91a9891e3@plan-b.pwste.edu.pl> References: <5670cd9a-cd10-2b89-1347-97a6c817c50f@sentex.net> <8696072a-dc25-8eff-04fa-4d1db13bf5cc@plan-b.pwste.edu.pl> <3588111612809020@mail.yandex.ru> <53ef5715-42ce-aad0-9a8b-11d91a9891e3@plan-b.pwste.edu.pl> Subject: Re: option FIB_ALGO and dpdk_lpm4 MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 08 Feb 2021 23:35:59 +0000 Message-Id: <301391612827263@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4DZMpr5cBDz3KgR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=OLmlVcMJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 37.140.190.195 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[37.140.190.195:from]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; FREEFALL_USER(0.00)[melifaro]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:37.140.128.0/18]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[37.140.190.195:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:37.140.128.0/18, country:RU]; MAILMAN_DEST(0.00)[freebsd-stable] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 23:36:06 -0000 08.02.2021, 20:10, "Marek Zarychta" : > W dniu 08.02.2021 o 19:32, Alexander V. Chernikov pisze: >>  08.02.2021, 14:33, "Marek Zarychta" : >>>  W dniu 08.02.2021 o 13:10, mike tancsa pisze: >>>>   I have been setting up some tests to see if >>>> >>>>   option FIB_ALGO and dpdk_lpm4.ko >>>> >>>>   will help with my pkt forwarding needs and large routing tables. So far so good. But one thing I noticed, is that its very chatty to dmesg. >>>>   eg >>>>   alloc_nhgrp: new mpath group: num_nhops: 2 >>>>   compile_nhgrp: O: 2/2 >>>>   compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>>>   compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >>>>   alloc_nhgrp: new mpath group: num_nhops: 2 >>>>   compile_nhgrp: O: 2/2 >>>>   compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>>>   compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >>>>   alloc_nhgrp: new mpath group: num_nhops: 2 >>>>   compile_nhgrp: O: 2/2 >>>>   compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>>>   compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >>>> >>>>   are these debugging messages that forgot to be turned off ? What do they mean ? >>>>   Thanks for this work! >>>> >>>>   13.0-STABLE #11 stable/13-cc1352c1f-dirty >>> >>>  Thank you for sharing this Mike. Could you please reveal us how do you >>>  feed your routing tables? Is net/bird{,2} or net/frr7 involved? Any >>>  problems or hints to make the routing daemon working with new routing stack? >>  Non-multipath should work as before, multipath works for quagga/frr but needs some patches for bird. > > Thank you for the clarification, so is with anything but quagga or frr > the sysctl setting net.route.multipath=0 obligatory now? >>>  The new routing stack looks very promising, please let me also give this >>>  way some appreciations to melifaro@ and other people who worked on it. >>> >>>  I was also trying to test it with legacy net/bird and multiple fib >>>  tables, but I was early hit by: "KRT: Error sending route x.x.x.x/y to >>>  kernel: Operation not supported" >>  Any chance you could clarify what are these routes? "Operation not supported" looks a bit weird, it shouln't happen. >>>  Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit, >>>  but still some blackhole /32 routes seem to get rejected. >>  Just "blackhole" route in the bird config? /32 or all? > > I used for tests the feed from Peter Hessler's OpenBSD spam trapping > project[1]. On FreeBSD 11.4 I see these routes in net/bird as > blackholed, for example: > x.x.x.x/32 blackhole [bgp_spamd 20:20:43 from y.y.y.y] * (100) [ASzzzz] > They work the same was as routes added by route(8) with option "-blackhole" > > With new routing stack, these routes are rejected with the message > above. Now in net/bird, they appear like the example below and import to > the fib (fib number is not equal to 0 in this case) is blocked: > x.x.x.x/32 unreachable [SPAM 19:58:18 from y.y.y.y] ! (100/-) [ASzzzz] Does the change in https://reviews.freebsd.org/D28549 fix bird? > > Probably it all should be tested in normal peering, but my initial test > was performed on the old lab setup where multiple fibs and policy > routing[2] were involved. The config was loosely based on the example by > Ondrej Filip from the[2]. > > Once again thank you for implementing all these improvements into > FreeBSD routing stack and please don't get me wrong, I am just testing > it a bit before migration from 11.4-STABLE, but not complaining about > anything. No problem! Thank you for the report. It's really nice it's been caught before the release. > > [1] http://rs.bgp-spamd.net/client/index.html > [2] https://gitlab.nic.cz/labs/bird/-/wikis/Policy_routing > > -- > Marek Zarychta