Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Feb 2021 23:35:59 +0000
From:      Alexander V. Chernikov <melifaro@ipfw.ru>
To:        Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>, mike tancsa <mike@sentex.net>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Subject:   Re: option FIB_ALGO and dpdk_lpm4
Message-ID:  <301391612827263@mail.yandex.ru>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
08.02.2021, 20:10, "Marek Zarychta" <zarychtam@plan-b.pwste.edu.pl>:
> W dniu 08.02.2021 o 19:32, Alexander V. Chernikov pisze:
>>  08.02.2021, 14:33, "Marek Zarychta" <zarychtam@plan-b.pwste.edu.pl>:
>>>  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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?301391612827263>