Building in OpenFlow/SDN support

[Sam Russell]

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