multiple routing tables

[Ragnar Lonn]

Andre Oppermann wrote:

>Why do you need two routing tables?  Do you run different routing daemons
>in the jails?  Do you have different default gateways for the jails?  Just
>trying to understand your requirements and usage of this feature.
>  
>

Well, I can tell you about our requirements, if you're interested in 
finding out
what possible use-cases exist. I suppose virtual hosting is the more common
use-case, but it might be good to know there are other possible uses too.

We're running a client simulator rig, using Marko's vimage patches and 
Netgraph.
We create vimages, with their own virtual network interfaces and routing 
tables,
and connect these interfaces via Netgraph to an ng_vlan node that VLAN-tags
all traffic from a certain vimage with a certain VLAN tag. Then we 
connect the
ng_vlan node to a physical network interface, causing the VLAN-tagged 
traffic
to exit through that interface. We connect the physical interface to a 
the uplink
port of a VLAN-enabled switch, letting the switch act as a 
de-multiplexer for the
outgoing traffic.

So the ng_vlan node and the switch constitute the 
multiplexer/de-multiplexer
pair in this setup. On the downlink ports of the switch we get the traffic
nicely separated, one port shows only traffic from one single vimage. In a
vimage we can use whatever program we want to generate traffic - we
can run low-level applications such as dhclient or arp, and we can run
higher-level applications such as wget. It doesn't matter. The applications
all think they're alone in the universe and can't see the other network
interfaces, processes or routing tables on the machine.(hiding processes
isn't important to us though). We can use the same routes in multiple
vimages (i.e. the same subnets, default gateways, or even local IP 
addresses).
We can receive multiple copies of the same multicast stream.

In short, our vimage instances almost *exactly* emulate a whole computer,
as seen from the switch downlink port side. The ONLY thing we cannot do
is generate VLAN-tagged traffic from a simulated client, but that is a very
small limitation and something we haven't ever been bothered by so far.

I know there are at least one or two other companies out there doing 
roughly
the same thing, using Marko's patches, so we're not unique at least. If 
this
functionality was possible to implement in FreeBSD >4 it would be of
great use to us, as we're forced to use very specific hardware right now,
due to the fact that 4.x doesn't have drivers for all the latest network 
cards,
for instance. (In fact, we only have one single gigabit ethernet card 
that we
can use, as of today).

Regards,

  /Ragnar