[quagga-dev 5147] Re: Shadowing Daemon (implementing callback from zclient.h)

Eric Keller ekeller at Princeton.EDU
Fri Nov 30 18:01:19 GMT 2007

>> For my project, I created a shadowing daemon using the zebra_client 
>> interface.  I'm doing this since I am using a custom data plane - 
>> implemented in an FPGA, though we're finding that this will be useful 
>> for several other projects (e.g. using Click as the forwarding plane).
> Interesting ;).
>> I am testing using "ip route" and I can see add's and deletes fine, 
>> but when I do an "ip route change ...", I do not see any updates to 
>> the shadowing daemon. Is this expected behavior,
> That depends, what did you change?

At start, this was the current state of the route table (as seen with 
"ip route") dev nf2c1  scope link dev nf2c0  scope link

ip route add dev nf2c0
Zebra printed the following:
2007/11/30 12:43:19 ZEBRA: Zebra 0.98.6 starting: vty at 2601
2007/11/30 12:43:32 ZEBRA: netlink_parse_info: netlink-listen type 
RTM_NEWROUTE(24), seq=1196444614, pid=2641
2007/11/30 12:43:32 ZEBRA: RTM_NEWROUTE ipv4 unicast proto boot
2007/11/30 12:43:32 ZEBRA: RTM_NEWROUTE

ip route change via
Zebra doesn't print anything

ip route change dev nf2c0
Zebra doesn't print anything

ip route change dev nf2c0 via
Zebra doesn't print anything

>> or could someone quickly point me in the right direction of how I can 
>> get the updates?
> In theory, if the change is something that zebra cares about, you 
> should see a delete/add issued on the Zserv protocol. It's possible 
> you're changing that something that zebra isn't taking into 
> consideration (which should be fixable).

This seems to be the case... any idea on how to fix it?  I'm far from an 
expert, but a look in /usr/include/linux/rtnetlink.h shows the various 
message types e.g "RTM_NEWROUTE".  Doesn't seem like there's anything 
for changes - but I could very well be missing something.

> Login to the zebra telnet interface (port 2601 by default, if not 
> disabled), and set 'debug zebra kernel', then either configure a log 
> file, or issue 'terminal monitor' and see what happens when route 
> changes.
I did that, and used the log messages above.
> regards,

More information about the Quagga-dev mailing list