From owner-freebsd-net@FreeBSD.ORG Tue Mar 21 09:44:35 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 467D816A401; Tue, 21 Mar 2006 09:44:35 +0000 (UTC) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id B535443D46; Tue, 21 Mar 2006 09:44:33 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id C158BA3450; Tue, 21 Mar 2006 10:44:33 +0100 (CET) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00929-07; Tue, 21 Mar 2006 10:44:32 +0100 (CET) Received: from [192.168.1.137] (unknown [192.168.1.137]) by mail.packetfront.com (Postfix) with ESMTP id 98B70A344B; Tue, 21 Mar 2006 10:44:31 +0100 (CET) Message-ID: <441FCA94.3060706@packetfront.com> Date: Tue, 21 Mar 2006 10:42:44 +0100 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <441E0415.2040908@elischer.org> <441F2248.6559A335@freebsd.org> In-Reply-To: <441F2248.6559A335@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: Julian Elischer , net@freebsd.org Subject: Re: multiple routing tables X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 09:44:35 -0000 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