1 week until Summer of Code application time

Archimedes Gaviola 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 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/,


More information about the Users mailing list