Thanks Maria for the response. I defined in Makefile and i was just using only ospf, so no other undefs were interfering and it worked, except for 1 or 2 compilation errors.As you suggested, there is no #undef to change to  #define in ospf specific files and its in common shared files. So this LOCAL_DEBUG/GLOBAL_DEBUG and DBG() support does not have a clean user interface requires changing the makefile/code. In ospf this DBG() is used to trace important information like neighbor state machine, lsa flooding, req/update...So can we add another proto debug flags (struct proto p->debug;/* Debugging flags */) like D_DBG and move the exiting use of DBG() to this?  On Sunday, July 18, 2021, 11:54:46 AM GMT+5:30, Maria Matejka <maria.matejka@nic.cz> wrote: Hello! On 7/18/21 7:48 AM, Senthil Kumar Nagappan wrote:

Hi,

To enable debug outputs using DBG macro, it requires LOCAL_DEBUG or GLOBAL_DEBUG to be defined during compilation.

Yes, you are right. And GLOBAL_DEBUG is generally not recommended to enable as it spits out loads of text.

1. Defined it in the Makefile as below. Is there an option without changing the auto generated Makefile?

CFLAGS=$(CPPFLAGS) -g -O2 -pthread -fno-strict-aliasing -fno-strict-overflow -flto -Wall -Wextra -Wstrict-prototypes -Wno-parentheses -Wno-pointer-sign -Wno-missing-field-initializers*-DLOCAL_DEBUG

This is not recommended and it is also negated by the #undef's everywhere.

2. If we try to define  LOCAL_DEBUG in the code, there are undef directive in the different places of the code, so may not work consistently.

The right place to enable this is to _change_ the #undef to #define.

3.  If we define this  LOCAL_DEBUG or GLOBAL_DEBUG, there are compilation errors that needs to be addressed.

Yes, you are right. The DBG() calls are typically just left there from the last debugging, not touched anymore, to see where it may make sense to write out some debug message. These calls may be also totally unsafe. Therefore you are supposed to check them thoroughly when enabling LOCAL_DEBUG. You may induce other bugs simply by enabling LOCAL_DEBUG. Maria

Hello! BIRD checks that the routes in OS table are still there. If you delete any of them accidentally, BIRD reinstalls it as soon as possible. Maria On 9/17/21 7:59 AM, Senthil Kumar Nagappan wrote:

Hi,

I assume when kernel protocol is configured with export all “protocol kernel {ipv4 { export all;};}”, bird performs synchronization of bird's routing tables with the OS kernel.

When the learn switch is disabled and no import is there, why bird is doing a periodic krt_scan and sends netlink request to os kernel to get the routes dump?

When learn switch is enabled, then non bird routes are learnt from os kernel and added to bird’s routing table, then what's the use of import command? Looks bit ambiguous.

Please correct me if my understanding is incorrect.

Debug all all enabled:

bird: krt_scan(time=2021-09-17 05:28:40.478)

bird: kernel1: Scanning routing table

bird: kernel1: 0.0.0.0/0: [alien] ignored

bird: kernel1: Pruning table master4

my bird config for kernel:

protocol kernel {

ipv4 { };

}

Or this happens with this config too

protocol kernel {

ipv4 { export all;};

}

Thanks and Regards, Senthil