Gopakumar - For 1) Zebra already has the ability to switch out to the appropriate rt_XXX.c interface to the underlying RIB/FIB. You could just write another one and setup your compile to take advantage of it.
For 2) I would write a shim layer library that does the internal to quagga translation to your code. Then all you would have to do is link with the shim instead of the standard interface libraries. Having said that, since Quagga can run on a bunch of different unrelated platforms without code changes for talking to interfaces. What do you gain by going with a different approach? I wouldn't attempt to rewrite ospf, just write a shim layer to handle the api translation for zebra and ospf I'm curious what are you doing? donald On Wed, May 27, 2015 at 11:06 PM, Gopakumar Choorakkot Edakkunni < [email protected]> wrote: > Hello all, > > I was exploring if I can manage to use Quagga OSPFd alone without the > zebra daemons, for reasons below. > > 1. I have my own RIB/FIB engines and am not interested in the Linux > RIB/FIB tables. So no need of netlink etc.. > > 2. I have my own representations for "interfaces", which are different > from the linux eth0/eth1 etc.. > > Because of these two reasons, I was exploring for a way by which I can > tell ospfd that > > A. here is a list of interfaces, and here is the OSPF config for those > interfaces - the interfaces are not in the standard linux ifindex > format etc.., consider it just as some datastructure which abstracts > the notion of an interface. > > B. When you need to Tx an OSPF packet, call my API my_packet_tx(). > Similarly when I get an rx packet, my_packet_rx() will get called > which will then call the OSPF packet Rx APIs. > > C. And whenever there is a routing table change, give me a callback > with the update - this I guess is already available as OSPF APIs > > For #A and #B, I see that OSPFd relies on the unix/linux notion of > interface/ifindex etc.. and the packet Rx/Tx is via socket() API > calls. So I guess the answer here is that OSPFd is not written to > support this. But I was wondering if anyone else knows of any other > branch/fork of quagga which might achieve this ? This is more like > asking for a "ospfd library" which can be embedded into another > process and the library relies on that process to supply it with > interface abstractions and packet Rx/Tx APIs. Any pointers will be > greatly appreciated ! > > Rgds, > Gopa. > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
