Third update, calling "restart k_2" also fixes a protocol which is stuck in "start". So configure isnt correctly initializing kernel route protocols. Hopefully this is enough information to get this bug fixed. On Sun, 11 Jul 2021 at 21:46, Mathew Heard <me@mheard.com> wrote:

I've managed to further simplify the testing instructions.

First have a working bird instance online.

Edit your configuration file to include: table test2; protocol kernel k_2 { table test2; kernel table 15008; scan time 2; persist; export none; import none; }

Call "birdc configure" then check the status of the protocol

# birdc show protocols | grep k_2 k_2 Kernel test2 start 21:44:47

Restarting bird will result in "k_2" being initialized correctly.

On Sun, 11 Jul 2021 at 01:33, Mathew Heard <me@mheard.com> wrote:

...

Hi,

I've [suspect] discovered a bug in Bird 1.6.8 where different results are seen when "birdc configure" vs restarting the daemon. In this case "birdc configure" fails to initialize the protocol leaving the protocol in the "start" state permanently.

NOTE: the protocol can be repaired on an existing BGP instance simply by changing the name and calling configure a second time. This appears to force a refresh of the protocol and gets it into the correct "up" state.

Starting the daemon fresh with the configuration results in correct behaviour.

To replicate add the following configuration to your configuration file: protocol pipe { table t_blah; peer table master; export filter no_default; import filter peer_table; }

protocol static { table t_blah; route 0.0.0.0/0 recursive 10.0.0.1; }

protocol kernel k_blah { table t_blah; kernel table 1234; scan time 2; persist; export filter conditional_table; import none; }

The build of bird I am using is the official Debian release.

Regards, Mathew