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."