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) with Quagga. regards, -- Hasso Tepper
