On Fri, Jun 14, 2013 at 04:14:19PM +1200, Sam Russell wrote:

Thanks for the reply. I think the kernel/iface stuff is a little bit more complicated than you've explained - there are lots of places around the code where calls are made directly rather than referring to the functions in the proto structure.

Well, we should discuss separately kernel protocol and device protocol. Kernel protocol is essentially just another protocol (there is one small hack when kernel protocol abuses attached kernel table by temporarily storing dummy routes in it but this is irrelevant here), You could easily run BIRD without kernel protocol and therefore you could just have another protocol syncing with SDN forwarding core, which is not really different than any other protocol (say BGP) from the BIRD core point of view. Device protocol is a bit more complicated. It is the only protocol that do not generate routes but ifaces and there are a few hacks (mostly in nest/proto.c): 1) Already mentioned kif_choose_primary() (which is not really important and will go away) 2) initial_device_proto in proto_init(), protos_commit() which forces which forces device proto to be initialized first. 3) Call to if_flush_ifaces() in proto_flush_loop(), this flushes all ifaces regardless of protocol that generates it. and perhaps some more bits. But there is one much bigger problem related to replacing device protocol - interface names and IDs from struct iface are often directly used when interacting with OS (like sending packets on specific iface or enabling receiving multicast on that iface). There are three posibilities: 1) Create some iface flag marking iface 'virtual', such iface cannot be used for these purposes, but this makes them more or less useless (you could have routes with gw on that iface, but you cannot run OSPF on that iface) 2) Virtualize whole BIRD socket interace, but this esssentially means reimplementing TCP/IP stack in BIRD. 3) For each SDN/OpenFlow iface create one TUN/TAP iface (on OS level) which will be used for tasks like sending OSPF packets to that iface. I think that the third option is the only realistic one. In that case BIRD SDN/OpenFlow protocol (or even some other daemon) would create TUN/TAP devices in OS and work as backend for them. You don't even need replacement for device protocol - standard device protocol would work with TUN/TAP devices. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Thanks for the reply Ondrej, The reason I want to separate both the kernel and devices is to build something like RouteFlow - create fake interfaces that relate to physical interfaces on a router, assign IPs to them (and drive ARP and ping from that), but also translate the routes from the fake kernel into flows on the router. I've covered tun/tap with openflow on my blog http://pieknywidok.blogspot.co.nz/2012/09/tunneling-traffic-through-your-ope... the next step is to build it into a router. Cheers Sam Sent from my iPhone On 14/06/2013, at 8:50 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote: On Fri, Jun 14, 2013 at 11:16:00AM +0200, Ondrej Zajicek wrote: On Fri, Jun 14, 2013 at 04:14:19PM +1200, Sam Russell wrote: Thanks for the reply. I think the kernel/iface stuff is a little bit more complicated than you've explained - there are lots of places around the code where calls are made directly rather than referring to the functions in the proto structure. Well, we should discuss separately kernel protocol and device protocol. Kernel protocol is essentially just another protocol (there is one small hack when kernel protocol abuses attached kernel table by temporarily Here should be 'attached BIRD table' instead of 'attached kernel table'. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Tun/tap is just one way to do it - another way would be to make the interfaces all virtual, and send the routing protocol stuff out a different interface. The big problem we've found with routing protocols being sent over the OpenFlow control channel is that it can often only handle 10-50 packets per second, so it'd be better to send this on a direct VLAN to the switch instead of tun/tap Sent from my iPhone On 14/06/2013, at 10:02 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:

On Fri, Jun 14, 2013 at 09:22:25PM +1200, Sam Russell wrote:

...

Thanks for the reply Ondrej,

The reason I want to separate both the kernel and devices is to build something like RouteFlow - create fake interfaces that relate to physical interfaces on a router, assign IPs to them (and drive ARP and ping from that), but also translate the routes from the fake kernel into flows on the router.

Hi

This is interesting and would be nice to have, but i don't understand one detail. I understand why you need replacement for kernel proto to translate routes to flows for SDN, but i don't understand why you need replacement for device proto to create fake interfaces if you also plan to use tun/tap - in that case you would already have 'real' tun/tap ifaces which would be enumerated in BIRD in a standard way.

-- Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."