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 <m...@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