From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 13:58:07 2005 Return-Path: X-Original-To: freebsd-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 18B9716A41F for ; Thu, 17 Nov 2005 13:58:07 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EE6E43D45 for ; Thu, 17 Nov 2005 13:58:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id B5435374C7; Thu, 17 Nov 2005 14:58:04 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 31CD9405A; Thu, 17 Nov 2005 14:57:39 +0100 (CET) Date: Thu, 17 Nov 2005 14:57:39 +0100 From: Jeremie Le Hen To: Jon Otterholm Message-ID: <20051117135738.GH5197@obiwan.tataz.chchile.org> References: <1131541588.996.13.camel@localhost.localdomain> <20051110124903.GB67086@uk.tiscali.com> <1131629107.878.22.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131629107.878.22.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: arp-proxy 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: Thu, 17 Nov 2005 13:58:07 -0000 Hi, Jon, Brian, > That depends... > > In all this - our role is similar to an ISP, but we are buying access to > our customers from an external part. Every customer is delivered on a > separate vlan trunked. > > - Our DSL customers cannot be set on the same VLAN i a single DSLAM > (don't ask me why - ask Alcatel). > - We cannot build a simple bridge because the Network service provider > can't handle when a MAC-address shows up on 2 different VLAN's. > > The arp-proxy should do the following: > - Forward any broadcast packets but rewrite src to its own mac. > - Forward unicast packets according to FDB but rewrite src to its own > mac. IIUC, you want to do some kind of NAT of MAC addresses, this is not an easy task, because you can't keep connection states only based on the (src MAC, dst MAC) tuple. You have to use at least IP addresses from the network layer or even TCP/UDP ports from the transport layer : Let's take B your bridge and I, J, K three customers. When I wants to talk to J, once the packets emitted from I are on J's VLAN, the tuple based only on MAC address would be (src: B, dst: J). If K also wants to talk to J, they would have the same tuple on J's VLAN. Therefore we won't know where to send back replies from J. This is the reason that requires upper layers to be taken into account. Anyway FreeBSD, as weel as other BSD flavors, can't do this. This is not implemented, and I'm not sure this is something we really want... A more elegant solution to this kind of problem is what Linux calls "pseudo bridge" [1]. The idea is to configure all your customers to let them believe they all live in the same physical network (IOW as if their trunks were bridged). The magic stands on the box linking them all together : you do not configure it as a bridge, but as a simple router which has one route for each customer pointing to the relevant VLAN. Then you set a sysctl named "proxy_arp" for each VLAN interface : this will ask the Linux kernel to check its routing table when it receives an ARP request. If the requested IP address doesn't live on the same VLAN as the request came from, the kernel will send an ARP reply claiming it owns the requested IP address. Therefore, the customer will believe he is talking directly to the computer whereas the packets will be routed, as if he was explicitely using a route. I hope I have been clear enough. IIRC the routing code and ARP code are currently rewritten in order to be splitted, it would maybe be worth to include this kind of functionnality at the same time. It seems to have useful and concrete applications for providers. Best regards, [1] http://www.sjdjweis.com/linux/proxyarp/ -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >