DragonFly users List (threaded) for 2009-03
Re: 1 week until Summer of Code application time
Simon 'corecode' Schubert wrote:
> I don't really see the benefit in this. Either you combine forwarding
> tables into one table, or you... well, that's actually it. I guess the
> larger part is more on a control plane level than on a data plane
> level, so that would more be a xorp project, I guess. I might also
> miss the point completely.
Control plane is a trivial part, really. Forwarding plane part is much
harder. Proper virtual router support as used nowadays massively (yes,
really) in ISP's needs:
* Completely isolated forwarding tables (this includes L2 info) - you
just associate an interface with virtual router.
* Sockets associated with virtual router. A process can create a socket
listening 0.0.0.0:179 in particular virtual router only. Ideally some
mechanism to associate a process with virtual router - all sockets
created by process will be associated with this virtual router then.
* The ability to reuse IP addresses and TCP/UDP ports in virtual routers.
Different virtual routers can have overlapping addresses and different
processes using overlapping ports.
* Mechanism to forward traffic between virtual routers (and full control
over the traffic).
With this in place, making control plane software to support it, is quite
straightforward. I have done this once although in limited way on top of
Linux forwarding tables (which are lame in routing point of view, btw)