W dniu 08.02.2021 o 19:32, Alexander V. Chernikov pisze:
> 08.02.2021, 14:33, "Marek Zarychta" <zarych...@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] 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 -- Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
