1 week until Summer of Code application time
archimedes.gaviola at gmail.com
Thu Mar 5 22:42:50 PST 2009
On Fri, Mar 6, 2009 at 1:32 AM, Hasso Tepper <hasso at estpak.ee> 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.
> 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/,
More information about the Users