Date: Mon, 8 Feb 2021 21:09:47 +0100 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: "Alexander V. Chernikov" <melifaro@ipfw.ru>, mike tancsa <mike@sentex.net>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: option FIB_ALGO and dpdk_lpm4 Message-ID: <53ef5715-42ce-aad0-9a8b-11d91a9891e3@plan-b.pwste.edu.pl> In-Reply-To: <3588111612809020@mail.yandex.ru> References: <5670cd9a-cd10-2b89-1347-97a6c817c50f@sentex.net> <8696072a-dc25-8eff-04fa-4d1db13bf5cc@plan-b.pwste.edu.pl> <3588111612809020@mail.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CgZsFu86crHRb4rm6DKeE8Cm2i1W64BfT
Content-Type: multipart/mixed; boundary="dMSbFvq81DZ5TXwpMU5skT6tHozJzKRqU";
protected-headers="v1"
From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
To: "Alexander V. Chernikov" <melifaro@ipfw.ru>, mike tancsa
<mike@sentex.net>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Message-ID: <53ef5715-42ce-aad0-9a8b-11d91a9891e3@plan-b.pwste.edu.pl>
Subject: Re: option FIB_ALGO and dpdk_lpm4
References: <5670cd9a-cd10-2b89-1347-97a6c817c50f@sentex.net>
<8696072a-dc25-8eff-04fa-4d1db13bf5cc@plan-b.pwste.edu.pl>
<3588111612809020@mail.yandex.ru>
In-Reply-To: <3588111612809020@mail.yandex.ru>
--dMSbFvq81DZ5TXwpMU5skT6tHozJzKRqU
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
W dniu 08.02.2021 o=C2=A019:32, Alexander V. Chernikov pisze:
> 08.02.2021, 14:33, "Marek Zarychta" <zarychtam@plan-b.pwste.edu.pl>:
>> W dniu 08.02.2021 o=C2=A013:10, mike tancsa pisze:
>>> =C2=A0I have been setting up some tests to see if
>>>
>>> =C2=A0option FIB_ALGO and dpdk_lpm4.ko
>>>
>>> =C2=A0will help with my pkt forwarding needs and large routing tables=
=2E So far so good. But one thing I noticed, is that its very chatty to d=
mesg.
>>> =C2=A0eg
>>> =C2=A0alloc_nhgrp: new mpath group: num_nhops: 2
>>> =C2=A0compile_nhgrp: O: 2/2
>>> =C2=A0compile_nhgrp: OO[0]: 1/1 curr=3D1 slot_idx=3D0
>>> =C2=A0compile_nhgrp: OO[1]: 0/0 curr=3D1 slot_idx=3D1
>>> =C2=A0alloc_nhgrp: new mpath group: num_nhops: 2
>>> =C2=A0compile_nhgrp: O: 2/2
>>> =C2=A0compile_nhgrp: OO[0]: 1/1 curr=3D1 slot_idx=3D0
>>> =C2=A0compile_nhgrp: OO[1]: 0/0 curr=3D1 slot_idx=3D1
>>> =C2=A0alloc_nhgrp: new mpath group: num_nhops: 2
>>> =C2=A0compile_nhgrp: O: 2/2
>>> =C2=A0compile_nhgrp: OO[0]: 1/1 curr=3D1 slot_idx=3D0
>>> =C2=A0compile_nhgrp: OO[1]: 0/0 curr=3D1 slot_idx=3D1
>>>
>>> =C2=A0are these debugging messages that forgot to be turned off ? Wha=
t do they mean ?
>>> =C2=A0Thanks for this work!
>>>
>>> =C2=A013.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=3D0 obligatory now?
>>
>> The new routing stack looks very promising, please let me also give th=
is
>> 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 supp=
orted" looks a bit weird, it shouln't happen.
>> Setting net.add_net.add_addr_allfibs=3D1addr_allfibs=3D1 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 "-blackhol=
e"
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]
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.
[1] http://rs.bgp-spamd.net/client/index.html
[2] https://gitlab.nic.cz/labs/bird/-/wikis/Policy_routing
--=20
Marek Zarychta
--dMSbFvq81DZ5TXwpMU5skT6tHozJzKRqU--
--CgZsFu86crHRb4rm6DKeE8Cm2i1W64BfT
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAmAhmosFAwAAAAAACgkQdZ/s//1SjSwT
IQf8Cu7KfND29kpIsgaBpPwkEARVRVyjAsGl+helW+/gNEJzuKoNVgnGMCxRyeWaGlG5LxIGdxBG
gtVfzk9gMIeznHgDykrfz7EFdstqQ0jUlADZ+CP6meEioGMSaKnI59p2V0tEo9d3XQ3PPmIE51xg
WqCW6IDhfyH0eBpMaL/an0rIW029BwryPxll56fssjf7Qu6j+/OMdVt4xMZTA5bVIbvviJ5ZWqzg
xcJ5j0PnphnqPY5V4OIarhuBiXL4mX87hR+2ipYzLzFRSitjhPsDTz6IvpRT7eLnbw4YTO/98Bs9
4ptIWI5kkdMisTim1b2/BTUpbChksih2Ncc137NYqg==
=EpJ3
-----END PGP SIGNATURE-----
--CgZsFu86crHRb4rm6DKeE8Cm2i1W64BfT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53ef5715-42ce-aad0-9a8b-11d91a9891e3>