On Fri, Mar 6, 2009 at 1:32 AM, Hasso Tepper <[email protected]> wrote: > 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 >
Thanks Hasso for explaining more information! Yes, most ISPs/NSPs are deploying virtual routing to their respective infrastructure at the edge level. I just knew that FreeBSD project is currently doing network stack virtualization http://imunes.tel.fer.hr/virtnet/, http://misc.allbsd.de/Vortrag/EuroBSDCon_2007//Marko_Zec/TUTORIAL.PDF, http://www.tel.fer.hr/zec/papers/talk-eurobsdcon-02.pdf. Archimedes
