1 week until Summer of Code application time

Hasso Tepper hasso at estpak.ee
Thu Mar 5 09:38:22 PST 2009

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.


Hasso Tepper

More information about the Users mailing list