bsdrp-users — BSDRP user discussions list

Re: [Bsdrp-users] New Releases?

[Olivier Cochard-L. <ol...@co...>]

On Mon, Jan 20, 2025 at 4:25 PM Paulo Fragoso <pa...@nl...> wrote:

> Hi Olivier,
>
> I hope so new rc.conf for FRR is ok, right? But disk space for Python 3.11
> would be a big problem?
>
>
> Hi,
yes I will have to bump the OS partition size, like we had to do a long
time ago:
https://github.com/ocochard/BSDRP/blob/master/CHANGES.md

Just fixed the owner permissions problem on the poudriere-image today:
https://github.com/freebsd/poudriere/pull/1200/files

Now I need to continue to do regression tests by upgrading all my BIOS and
UEFI machines from an old BSDRP to this new version.

Regards,
Olivier

Re: [Bsdrp-users] New Releases?

[mike t. <mi...@se...>]

That reminds me, the latest frr8 has a bit of POLA in it too. If you had 
something like

frr_flags="-P0"

and used individual .conf files, you now need to explicitly add

watchfrr_enable="NO"
frr_vtysh_boot="NO"

otherwise you get the startup failing and it defaults to frr.conf for 
better or worse.

/usr/local/etc/rc.d/frr start
WARNING: Old rc.d/watchfrr detected, this file must be deleted
Starting watchfrr.
/usr/local/sbin/watchfrr: invalid option -- P
Invalid option.
Invalid options.

Usage : watchfrr [OPTION...] <daemon name> ...

This was going from frr8-8.5.6 to frr8-8.5.7

     ---Mike


On 1/20/2025 9:57 AM, Paulo Fragoso wrote:
>
> Hi Olivier,
>
> I hope so new rc.conf for FRR is ok, right? But disk space for Python 
> 3.11 would be a big problem?
>
> Thanks,
> Paulo.
>
> Em 11/09/2024 14:35, Olivier Cochard-Labbé escreveu:
>>
>> On Tue, Sep 10, 2024 at 7:25 AM Paulo Fragoso <pa...@nl...> wrote:
>>
>>     Hi,
>>
>>     Are there any plans for new releases covering some corrections to
>>     FreeBSD?
>>
>>
>> Hi,
>> yes but I’m very late:
>> - The next version will be built using poudriere-image in place of 
>> nanobsd, and currently I have a build problem 
>> (https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=buildworld&list_id=724454 
>> <https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=buildworld&list_id=724454>);
>> - The new python default release (3.11) added a lot of disk space 
>> consumption, so I need to increase the disk space (adding more 
>> regression tests to do);
>> - I’m working on rewriting the net/frr* RC script to use the new 
>> standard method (using watchfrr and uniq frr.conf by default), but 
>> this task takes longer than expected because I need to take care of 
>> compatibility with the old method (one config file per daemon). I’m 
>> currently doing this last step (the regression test). Once done, I 
>> will add net/frr10 
>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278384)
>>
>> 24 hours a day is not enough :-)
>>
>>
>> _______________________________________________
>> Bsdrp-users mailing list
>> Bsd...@li...
>> https://lists.sourceforge.net/lists/listinfo/bsdrp-users
> -- 
> “Because there is no army that can hold back an economic principle whose time has come.”
> John Donovan, AT&T
> Skype: paulo.dcap
> 
>
>
> _______________________________________________
> Bsdrp-users mailing list
> Bsd...@li...
> https://lists.sourceforge.net/lists/listinfo/bsdrp-users

Re: [Bsdrp-users] New Releases?

[Paulo F. <pa...@nl...>]

Hi Olivier,

I hope so new rc.conf for FRR is ok, right? But disk space for Python 3.11 would be a big problem?

Thanks,
Paulo.

Em 11/09/2024 14:35, Olivier Cochard-Labbé escreveu:
>
> On Tue, Sep 10, 2024 at 7:25 AM Paulo Fragoso <pa...@nl...> wrote:
>
>     Hi,
>
>     Are there any plans for new releases covering some corrections to FreeBSD?
>
>
> Hi,
> yes but I’m very late:
> - The next version will be built using poudriere-image in place of nanobsd, and currently I have a build problem (https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=buildworld&list_id=724454 <https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=buildworld&list_id=724454>);
> - The new python default release (3.11) added a lot of disk space consumption, so I need to increase the disk space (adding more regression tests to do);
> - I’m working on rewriting the net/frr* RC script to use the new standard method (using watchfrr and uniq frr.conf by default), but this task takes longer than expected because I need to take care of compatibility with the old method (one config file per daemon). I’m currently doing this last step (the regression test). Once done, I will add net/frr10 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278384)
>
> 24 hours a day is not enough :-)
>
>
> _______________________________________________
> Bsdrp-users mailing list
> Bsd...@li...
> https://lists.sourceforge.net/lists/listinfo/bsdrp-users

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] New Releases?

[Olivier Cochard-L. <ol...@co...>]

On Tue, Sep 10, 2024 at 7:25 AM Paulo Fragoso <pa...@nl...> wrote:

> Hi,
>
> Are there any plans for new releases covering some corrections to FreeBSD?
>
>
Hi,
yes but I’m very late:
- The next version will be built using poudriere-image in place of nanobsd,
and currently I have a build problem (
https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=buildworld&list_id=724454
);
- The new python default release (3.11) added a lot of disk space
consumption, so I need to increase the disk space (adding more regression
tests to do);
- I’m working on rewriting the net/frr* RC script to use the new standard
method (using watchfrr and uniq frr.conf by default), but this task takes
longer than expected because I need to take care of compatibility with the
old method (one config file per daemon). I’m currently doing this last step
(the regression test). Once done, I will add net/frr10 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278384)

24 hours a day is not enough :-)

[Bsdrp-users] New Releases?

[Paulo F. <pa...@nl...>]

Hi,

Are there any plans for new releases covering some corrections to FreeBSD?

Thanks,
Paulo.

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] Flow with ASN

[Paulo F. <pa...@nl...>]

Excuse-me for quick ask I found pmacct which do this work

Em 09/05/2024 21:52, Paulo Fragoso escreveu:
> Hi,
>
> Is possible to receive flows from BSDRP router with ASN field for 
> correspondent IP reported?
>
> Thanks,
> Paulo.
>
-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


[Bsdrp-users] Flow with ASN

[Paulo F. <pa...@nl...>]

Hi,

Is possible to receive flows from BSDRP router with ASN field for 
correspondent IP reported?

Thanks,
Paulo.

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] BSDEP 1.992 issues with FRR

[Lyubomir Y. <l....@gm...>]

Hi Olivier,
Thanks a lot!

Regards,
Lyubo

On Thu, 28 Mar 2024 at 15:19, Olivier Cochard-Labbé <ol...@co...>
wrote:

>
> On Wed, Mar 13, 2024 at 9:08 AM Lyubomir Yotov <l....@gm...> wrote:
>
>> Hi Olivier,
>> Do you plan to upload a newer version with fixed FRR?
>>
>>>
>>>>
> Hi,
> I’ve just done it.
> Sorry for the delay.
>
> Olivier
>

Re: [Bsdrp-users] BSDEP 1.992 issues with FRR

[Olivier Cochard-L. <ol...@co...>]

On Wed, Mar 13, 2024 at 9:08 AM Lyubomir Yotov <l....@gm...> wrote:

> Hi Olivier,
> Do you plan to upload a newer version with fixed FRR?
>
>>
>>>
Hi,
I’ve just done it.
Sorry for the delay.

Olivier

Re: [Bsdrp-users] ifconfig create netlink troubles

[Paulo F. <pa...@nl...>]

Hi,

This problem was solved today after upgrade to version 1.992

Thanks,
Paulo Fragoso.

Em 12/03/2024 15:56, Paulo Fragoso escreveu:
> Hi,
>
> I'm coming across a possible bug that was reported here: 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270628
>
> This route is running BSDRP n282496 and when I'm creating a new cloned 
> vlan interface I've got this error:
>
> [nl_iface] get_operstate_ether: error calling SIOCGIFMEDIA on 
> ix0.2912: 22
>
> Only after this uptime:
>
> # uptime
>  6:54PM  up 316 days,  6:54, 3 users, load averages: 5.39, 5.59, 5.64
>
> and several cloned vlans created for get first error.
>
> What is happening?
>
> Thanks,
> Paulo Fragoso.
>
-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] BSDEP 1.992 issues with FRR

[Lyubomir Y. <l....@gm...>]

Hi Olivier,
Do you plan to upload a newer version with fixed FRR?
Regards,
Lyubo

On Wed, 7 Feb 2024 at 17:04, Lyubomir Yotov <l....@gm...> wrote:

> Hi Olivier,
> Thanks for the feedback. I fully agree with your point on the “reload”
> option.
> Looking forward to the next release.
>
> Regards,
> Lyubo
>
>
> On Wed, 7 Feb 2024 at 15:42, Olivier Cochard-Labbé <ol...@co...>
> wrote:
>
>>
>>
>> On Thu, Feb 1, 2024 at 8:15 AM Lyubomir Yotov <l....@gm...> wrote:
>>
>>> Hello Olivier,
>>> I tried version 1.992 and besides the startup script for staticd issue
>>> (FreeBSD bugzilla bug 276333) I had two other issues:
>>>
>>> 1. When restarting the service with the patched startup script (as per
>>> the patch from bug 276333) the mgmtd dawmon doesn’t start (below is the
>>> output). Since FRR 9.0 a centralized management daemon (mgmtd) is
>>> introduced and staticd configuration is migrated to mgmtd. Is there a way
>>> fir workaround?
>>>
>>>
>>>
>> Yes, FreeBSD's port tree was updated to fix that.
>>
>>
>>> 2. In the configuration of route maps it is not possible to add prefix
>>> lists because of
>>> https://github.com/FRRouting/frr/issues/14375
>>> I saw that the libyang version in 1.992 is 2.1.111
>>> Have you tested with libyand 2.1.80?
>>> Can you please provide an updated version with correctly patched frr
>>> service script and with libyang 2.1.80 if you find appropriate?
>>>
>>
>> I’ve read the exchange between FRR and libyang teams, they are
>> interesting regarding the definition of a stable API :-)
>>
>> libyang 2.1.128, that patch this regression, was committed in FreeBSD's
>> port tree.
>> https://github.com/CESNET/libyang/releases/tag/v2.1.128
>>
>>
>> So I just need to release a new BSDRP release with this updated port tree
>> to fix those 2 problems.
>>
>>
>>
>>> One more question, is it possible to have the option “service frr
>>> reload”?
>>>
>>
>> There is a dedicated python tool (in net/frr9-pythontools
>> as sbin/frr-reload.py) for this feature.
>> I didn’t look at it, but my thought was «If they need a python script
>> with more than 2000 lines for this reload feature, it will be a nightmare
>> to do it inside the RC shell script».
>> This is why there is no such "reload" feature currently: I hope once all
>> daemons being converted to use mgmtd, this will be a feature it will take
>> care of.
>>
>> Regards,
>> Olivier
>>
>>

Re: [Bsdrp-users] BSDRP with Netmap on Appliance ServerU

[Paulo F. <pa...@nl...>]

Hi Erlon!

I'm using L800 in our Datacenter for five years with no problem about 
its NICs if you are confortable can contact me directly.

Thanks,
Paulo Fragoso.

PS.: Yesterday I found a problem with vlan subinterface and Netlink

Em 16/02/2024 16:55, Erlon Silva escreveu:
>
> ServerU/Lanner It's a network appliance which is compatible with 
> FreeBSD netmap, including the following network cards: 6 Intel igb 
> driver(4) NICs plus 2x Intel 82599ES 10Gbe.
> I tried to install BSDRP, however, the network cards do not work, even 
> though they are seen through: show interfaces and are in the UP state.
>
> Em 14/02/2024 12:35, Erlon Silva escreveu:
>>
>> Hi Olivier!
>> I'm a big admirer of your work with BSDRP, a great alternative to 
>> already known solutions.
>> I have a network device known as ServerU, which is approved and 
>> recommended for FreeBSD due to netmap.
>> This way, the box's performance can be increased by up to 13x 
>> (according to them).
>> I realized that BSDRP is a FreeBSD image and that it also has netmap.
>> I would like to ask a simple question: when installing BSDRP on 
>> ServerU, can I use netmap natively on ServerU? I need to resolve this 
>> doubt, as I will use it for BGP and OSPF routing.
>> I would also like you to share with me about netmap, whether it would 
>> only work with IPv4, as I have been looking at the BSDRP 1992 
>> changelog and it contains the information netmap-fwd 0.2: IPv4 router 
>> over netmap for FreeBSD.
>>
>
>
> _______________________________________________
> Bsdrp-users mailing list
> Bsd...@li...
> https://lists.sourceforge.net/lists/listinfo/bsdrp-users

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


[Bsdrp-users] ifconfig create netlink troubles

[Paulo F. <pa...@nl...>]

Hi,

I'm coming across a possible bug that was reported here: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270628

This route is running BSDRP n282496 and when I'm creating a new cloned 
vlan interface I've got this error:

[nl_iface] get_operstate_ether: error calling SIOCGIFMEDIA on ix0.2912: 22

Only after this uptime:

# uptime
  6:54PM  up 316 days,  6:54, 3 users, load averages: 5.39, 5.59, 5.64

and several cloned vlans created for get first error.

What is happening?

Thanks,
Paulo Fragoso.

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] BSDRP with Netmap on Appliance ServerU

[Erlon S. <er...@vn...>]

ServerU/Lanner It's a network appliance which is compatible with FreeBSD 
netmap, including the following network cards: 6 Intel igb driver(4) 
NICs plus 2x Intel 82599ES 10Gbe.
I tried to install BSDRP, however, the network cards do not work, even 
though they are seen through: show interfaces and are in the UP state.

Em 14/02/2024 12:35, Erlon Silva escreveu:
>
> Hi Olivier!
> I'm a big admirer of your work with BSDRP, a great alternative to 
> already known solutions.
> I have a network device known as ServerU, which is approved and 
> recommended for FreeBSD due to netmap.
> This way, the box's performance can be increased by up to 13x 
> (according to them).
> I realized that BSDRP is a FreeBSD image and that it also has netmap.
> I would like to ask a simple question: when installing BSDRP on 
> ServerU, can I use netmap natively on ServerU? I need to resolve this 
> doubt, as I will use it for BGP and OSPF routing.
> I would also like you to share with me about netmap, whether it would 
> only work with IPv4, as I have been looking at the BSDRP 1992 
> changelog and it contains the information netmap-fwd 0.2: IPv4 router 
> over netmap for FreeBSD.
>

Re: [Bsdrp-users] BSDRP with Netmap on Appliance ServerU

[Olivier Cochard-L. <ol...@co...>]

On Wed, Feb 14, 2024 at 5:37 PM Erlon Silva <er...@vn...>
wrote:

> Hi Olivier!
> I'm a big admirer of your work with BSDRP, a great alternative to already
> known solutions.
> I have a network device known as ServerU, which is approved and
> recommended for FreeBSD due to netmap.
> This way, the box's performance can be increased by up to 13x (according
> to them).
>

Hi,
netmap is just a framework, and indeed BSDRP as FreeBSD based supports
netmap… but you need softwares that uses this framework now.
And with BSDRP, there is pkt-gen and nmreplay (a packet generator and
replay) that are using netmap.
But there are no "forwarding|routing" softwares that are using netmap on
BSDRP.
There is a very recent Cisco VPP port that should soon support netmap and
dpdk on FreeBSD (so BSDRP), but is not available today.


> I realized that BSDRP is a FreeBSD image and that it also has netmap.
> I would like to ask a simple question: when installing BSDRP on ServerU,
> can I use netmap natively on ServerU? I need to resolve this doubt, as I
> will use it for BGP and OSPF routing.
> I would also like you to share with me about netmap, whether it would only
> work with IPv4, as I have been looking at the BSDRP 1992 changelog and it
> contains the information netmap-fwd 0.2: IPv4 router over netmap for
> FreeBSD.
>

netmap-fwd was a PoC, and isn’t usable compared to a standard routing stack.

What is ServerU ? It just need NIC compliant with netmap, cf "supported
devices" chapter in https://man.freebsd.org/cgi/man.cgi?netmap(4)

Regards,
Olivier

[Bsdrp-users] BSDRP with Netmap on Appliance ServerU

[Erlon S. <er...@vn...>]

Hi Olivier!
I'm a big admirer of your work with BSDRP, a great alternative to 
already known solutions.
I have a network device known as ServerU, which is approved and 
recommended for FreeBSD due to netmap.
This way, the box's performance can be increased by up to 13x (according 
to them).
I realized that BSDRP is a FreeBSD image and that it also has netmap.
I would like to ask a simple question: when installing BSDRP on ServerU, 
can I use netmap natively on ServerU? I need to resolve this doubt, as I 
will use it for BGP and OSPF routing.
I would also like you to share with me about netmap, whether it would 
only work with IPv4, as I have been looking at the BSDRP 1992 changelog 
and it contains the information netmap-fwd 0.2: IPv4 router over netmap 
for FreeBSD.

Re: [Bsdrp-users] BSDEP 1.992 issues with FRR

[Lyubomir Y. <l....@gm...>]

Hi Olivier,
Thanks for the feedback. I fully agree with your point on the “reload”
option.
Looking forward to the next release.

Regards,
Lyubo


On Wed, 7 Feb 2024 at 15:42, Olivier Cochard-Labbé <ol...@co...>
wrote:

>
>
> On Thu, Feb 1, 2024 at 8:15 AM Lyubomir Yotov <l....@gm...> wrote:
>
>> Hello Olivier,
>> I tried version 1.992 and besides the startup script for staticd issue
>> (FreeBSD bugzilla bug 276333) I had two other issues:
>>
>> 1. When restarting the service with the patched startup script (as per
>> the patch from bug 276333) the mgmtd dawmon doesn’t start (below is the
>> output). Since FRR 9.0 a centralized management daemon (mgmtd) is
>> introduced and staticd configuration is migrated to mgmtd. Is there a way
>> fir workaround?
>>
>>
>>
> Yes, FreeBSD's port tree was updated to fix that.
>
>
>> 2. In the configuration of route maps it is not possible to add prefix
>> lists because of
>> https://github.com/FRRouting/frr/issues/14375
>> I saw that the libyang version in 1.992 is 2.1.111
>> Have you tested with libyand 2.1.80?
>> Can you please provide an updated version with correctly patched frr
>> service script and with libyang 2.1.80 if you find appropriate?
>>
>
> I’ve read the exchange between FRR and libyang teams, they are
> interesting regarding the definition of a stable API :-)
>
> libyang 2.1.128, that patch this regression, was committed in FreeBSD's
> port tree.
> https://github.com/CESNET/libyang/releases/tag/v2.1.128
>
>
> So I just need to release a new BSDRP release with this updated port tree
> to fix those 2 problems.
>
>
>
>> One more question, is it possible to have the option “service frr reload”?
>>
>
> There is a dedicated python tool (in net/frr9-pythontools
> as sbin/frr-reload.py) for this feature.
> I didn’t look at it, but my thought was «If they need a python script with
> more than 2000 lines for this reload feature, it will be a nightmare to do
> it inside the RC shell script».
> This is why there is no such "reload" feature currently: I hope once all
> daemons being converted to use mgmtd, this will be a feature it will take
> care of.
>
> Regards,
> Olivier
>
>

Re: [Bsdrp-users] BSDEP 1.992 issues with FRR

[Olivier Cochard-L. <ol...@co...>]

On Thu, Feb 1, 2024 at 8:15 AM Lyubomir Yotov <l....@gm...> wrote:

> Hello Olivier,
> I tried version 1.992 and besides the startup script for staticd issue
> (FreeBSD bugzilla bug 276333) I had two other issues:
>
> 1. When restarting the service with the patched startup script (as per the
> patch from bug 276333) the mgmtd dawmon doesn’t start (below is the
> output). Since FRR 9.0 a centralized management daemon (mgmtd) is
> introduced and staticd configuration is migrated to mgmtd. Is there a way
> fir workaround?
>
>
>
Yes, FreeBSD's port tree was updated to fix that.


> 2. In the configuration of route maps it is not possible to add prefix
> lists because of
> https://github.com/FRRouting/frr/issues/14375
> I saw that the libyang version in 1.992 is 2.1.111
> Have you tested with libyand 2.1.80?
> Can you please provide an updated version with correctly patched frr
> service script and with libyang 2.1.80 if you find appropriate?
>

I’ve read the exchange between FRR and libyang teams, they are
interesting regarding the definition of a stable API :-)

libyang 2.1.128, that patch this regression, was committed in FreeBSD's
port tree.
https://github.com/CESNET/libyang/releases/tag/v2.1.128


So I just need to release a new BSDRP release with this updated port tree
to fix those 2 problems.



> One more question, is it possible to have the option “service frr reload”?
>

There is a dedicated python tool (in net/frr9-pythontools
as sbin/frr-reload.py) for this feature.
I didn’t look at it, but my thought was «If they need a python script with
more than 2000 lines for this reload feature, it will be a nightmare to do
it inside the RC shell script».
This is why there is no such "reload" feature currently: I hope once all
daemons being converted to use mgmtd, this will be a feature it will take
care of.

Regards,
Olivier

[Bsdrp-users] BSDEP 1.992 issues with FRR

[Lyubomir Y. <l....@gm...>]

Hello Olivier,
I tried version 1.992 and besides the startup script for staticd issue
(FreeBSD bugzilla bug 276333) I had two other issues:

1. When restarting the service with the patched startup script (as per the
patch from bug 276333) the mgmtd dawmon doesn’t start (below is the
output). Since FRR 9.0 a centralized management daemon (mgmtd) is
introduced and staticd configuration is migrated to mgmtd. Is there a way
fir workaround?

Output from “service frr restart”

/# service frr restart Checking mgmtd.conf 2024/01/28 17:42:30 MGMTD:
[YKHB9-ND03T] FE-client: msg_conn_send_msg: can't send message on closed
connection 2024/01/28 17:42:30 MGMTD: lib/vty.c:1684: vty_new(): assertion
(new->mgmt_session_id != 0) failed, extra info: Failed to create client
session for VTY MGMTD: Received signal 6 at 1706463750 (si_addr 0x0);
aborting... MGMTD: ?                                     821970b89
8205f0940 /usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     8219a4631        8205f0a70
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     825820f84        8205f0ad0
/lib/libthr.so.3 (mapped at 0x825807000) MGMTD:
?                                     82582052b        8205f0e90
/lib/libthr.so.3 (mapped at 0x825807000) MGMTD:     ---- signal ---- MGMTD:
?                                     8208162d3        8205f0f00 MGMTD:
---- signal ---- MGMTD: ?
826c9d13a        8205f1358 /lib/libc.so.7 (mapped at 0x826b77000) MGMTD:
?                                     826c19204        8205f1360
/lib/libc.so.7 (mapped at 0x826b77000) MGMTD:
?                                     826cc34dc        8205f1390
/lib/libc.so.7 (mapped at 0x826b77000) MGMTD:
?                                     8219d329b        8205f13d0
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     8219bb1aa        8205f14d0
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     8219bc4c0        8205f14f0
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     8219670ec        8205f1530
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                     821966f83        8205f1970
/usr/local/lib/libfrr.so.0 (mapped at 0x82183b000) MGMTD:
?                                        217d76        8205f1a10
/usr/local/sbin/mgmtd (mapped at 0x200000) MGMTD:
?                                     826befd26        8205f1a40
/lib/libc.so.7 (mapped at 0x826b77000) MGMTD:
?                                        217be0        8205f1a90
/usr/local/sbin/mgmtd (mapped at 0x200000) MGMTD: no thread information
available core_handler: showing active allocations in memory group libfrr
core_handler: memstats:  Temporary memory              :      1 *
30 core_handler: memstats:  Buffer                        :      2
*         24 core_handler: memstats:  Host config                   :
6 * (variably sized) core_handler: memstats:  Command Tokens
:   1640 *         72 core_handler: memstats:  Command Token
Text            :   1223 * (variably sized) core_handler: memstats:
Command Token Help            :   1223 * (variably sized) core_handler:
memstats:  Command Argument Name         :    452 * (variably sized)
core_handler: memstats:  Graph                         :     13 *
8 core_handler: memstats:  Graph Node                    :   1890 *
32 core_handler: memstats:  Hash                          :     36 *
(variably sized) core_handler: memstats:  Hash Bucket
:    311 *         32 core_handler: memstats:  Hash
Index                    :     18 * (variably sized) core_handler:
memstats:  Link List                     :      5 *         40
core_handler: memstats:  Link Node                     :     26 *
24 core_handler: memstats:  frontend client               :      1 *
352 core_handler: memstats:  frontend client name          :      1
*         16 core_handler: memstats:  Northbound Node               :
193 *       1192 core_handler: memstats:  Northbound Configuration
:      3 *         24 core_handler: memstats:
Stream                        :      1 *       9032 core_handler:
memstats:  Thread                        :      4 *        128
core_handler: memstats:  Thread master                 :      4 * (variably
sized) core_handler: memstats:  Thread Poll Info              :      2 *
1876320 core_handler: memstats:  Thread stats                  :      3
*         96 core_handler: memstats:  Typed-hash bucket             :
1 *         16 core_handler: memstats:  Vector                        :
3807 *         24 core_handler: memstats:  Vector index
:   3807 * (variably sized) core_handler: memstats:
VRF                           :      1 *        216 core_handler:
memstats:  VTY                           :      2 * (variably sized)
core_handler: memstats:  YANG module                   :      6 *
48 core_handler: showing active allocations in memory group logging
subsystem core_handler: showing active allocations in memory group mgmt
core_handler: memstats:  xpath regex                   :      3 * (variably
sized) Abort trap FAILED [lyubd@verila]/# service frr status zebra is
running as pid 69615. ospfd is running as pid 75731. ospf6d is running as
pid 80058. bgpd is running as pid 85753. staticd is running as pid 89685.
mgmtd is not running. Booting for integrated-vtysh-config... [77931|zebra]
sending configuration [79581|ospfd] sending configuration [80087|ospf6d]
sending configuration [80251|bgpd] sending configuration [87623|staticd]
sending configuration Waiting for children to finish applying config...
[87623|staticd] done This command is deprecated, because it is not
VRF-aware. Please, use "no ip ospf passive" on an interface instead. This
command is deprecated, because it is not VRF-aware. Please, use "no ip ospf
passive" on an interface instead. This command is deprecated, because it is
not VRF-aware. Please, use "no ip ospf passive" on an interface instead.
[80087|ospf6d] done [79581|ospfd] done [77931|zebra] done [80251|bgpd] done

2. In the configuration of route maps it is not possible to add prefix
lists because of
https://github.com/FRRouting/frr/issues/14375
I saw that the libyang version in 1.992 is 2.1.111
Have you tested with libyand 2.1.80?
Can you please provide an updated version with correctly patched frr
service script and with libyang 2.1.80 if you find appropriate?

One more question, is it possible to have the option “service frr reload”?

Regards,
Lyubomir Yotov

Re: [Bsdrp-users] RELENG_13 vs 14 vs 15 performance

[Olivier Cochard-L. <ol...@co...>]

On Tue, Nov 14, 2023 at 4:40 PM mike tancsa <mi...@se...> wrote:

> Hi All,
>
>      I noticed the latest version is based on FreeBSD 15x.  When I went
> from RELENG12 to 13 there was a decent performance bump for boxes with
> large routing tables for forwarding performance. Are there similar gains
> over 13 by going to 14 or 15 ?
>
> This improvement was due to the modular FIB lookup improvement added in
FreeBSD 13.2.
I don't think there has been such a massive improvement in this domain
since.
But I haven't had time to run network benches for a long time either :-(

Regards,
Olivier

[Bsdrp-users] RELENG_13 vs 14 vs 15 performance

[mike t. <mi...@se...>]

Hi All,

     I noticed the latest version is based on FreeBSD 15x.  When I went 
from RELENG12 to 13 there was a decent performance bump for boxes with 
large routing tables for forwarding performance. Are there similar gains 
over 13 by going to 14 or 15 ?

     ---Mike

Re: [Bsdrp-users] Check sum files

[Olivier Cochard-L. <ol...@co...>]

Thanks for this tips,
will be fixed on the next release

On Thu, May 4, 2023 at 3:48 PM Paulo Fragoso <pa...@nl...> wrote:

> Hi,
>
> If *.sha256 sum file modified like this
>
> --- BSDRP-n282496-upgrade-amd64-vga.img.sha256.orig    2023-05-04 10:14:27
> +++ BSDRP-n282496-upgrade-amd64-vga.img.sha256    2023-05-04 10:15:01
> @@ -1 +1 @@
> -SHA256
> (/usr/local/BSDRP/workdir/BSDRP.amd64/BSDRP-n282496-upgrade-amd64-vga.img.xz)
>
> = 3b1b28b30cf930e3be59de4f3fdc65fb0bc3d6d93ef1ae689c1aeaf206f8264c
> +SHA256 (BSDRP-n282496-upgrade-amd64-vga.img.xz) =
> 3b1b28b30cf930e3be59de4f3fdc65fb0bc3d6d93ef1ae689c1aeaf206f8264c
>
> the checksum will be simplified to:
>
> shasum -a 256 -c BSDRP-n282496-upgrade-amd64-vga.img.sha256
>
> Thanks,
> Paulo.
>
> --
> “Because there is no army that can hold back an economic principle whose
> time has come.”
> John Donovan, AT&T
> Skype: paulo.dcap
> 
>
>
>
> _______________________________________________
> Bsdrp-users mailing list
> Bsd...@li...
> https://lists.sourceforge.net/lists/listinfo/bsdrp-users
>

Re: [Bsdrp-users] bird and nl_iface dump_sa: unsupported family: 0, skipping

[Paulo F. <pa...@nl...>]

Great!

Many Thanks,
Paulo.

Em 18/07/2023 17:25, Olivier Cochard-Labbé escreveu:
> On Sun, Jul 16, 2023 at 9:42 PM Paulo Fragoso <pa...@nl...> wrote:
>
>     I get this error below reported by the kernel:
>
>     [nl_iface] dump_sa: unsupported family: 0, skipping
>
>     Why does this error occour?
>
>
> Hi,
>
> It was the default level of netlink that was too high.
> Was fixed here:
> https://cgit.freebsd.org/src/commit/?id=fa554de7746d88959738e4cb978608af8ce479c1
> The latest night-release should then include this fix.
> https://sourceforge.net/projects/bsdrp/files/BSD_Router_Project/nightly/2023-07-18/amd64/
>
> Regards,
> Olivier
>
>
> _______________________________________________
> Bsdrp-users mailing list
> Bsd...@li...
> https://lists.sourceforge.net/lists/listinfo/bsdrp-users

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap


Re: [Bsdrp-users] bird and nl_iface dump_sa: unsupported family: 0, skipping

[Olivier Cochard-L. <ol...@co...>]

On Sun, Jul 16, 2023 at 9:42 PM Paulo Fragoso <pa...@nl...> wrote:

> I get this error below reported by the kernel:
>
> [nl_iface] dump_sa: unsupported family: 0, skipping
>
> Why does this error occour?
>
>
Hi,

It was the default level of netlink that was too high.
Was fixed here:
https://cgit.freebsd.org/src/commit/?id=fa554de7746d88959738e4cb978608af8ce479c1
The latest night-release should then include this fix.
https://sourceforge.net/projects/bsdrp/files/BSD_Router_Project/nightly/2023-07-18/amd64/

Regards,
Olivier

[Bsdrp-users] bird and nl_iface dump_sa: unsupported family: 0, skipping

[Paulo F. <pa...@nl...>]

Hi

I'm testing night build n282496 and when is created one interface gre0 
like this example:

sysrc bird_enable="YES"
sysrc ifconfig_em0="inet 100.0.0.1/24"
sysrc cloned_interfaces="gre0"
sysrc ifconfig_gre0="inet 10.55.11.1/30 10.55.11.2 tunnel 100.0.0.1 
100.1.0.1 up"

I get this error below reported by the kernel:

[nl_iface] dump_sa: unsupported family: 0, skipping

Why does this error occour?

Thanks,
Paulo.

-- 
“Because there is no army that can hold back an economic principle whose time has come.”
John Donovan, AT&T
Skype: paulo.dcap
