From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 15:06:09 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 C43D116A41F for ; Thu, 17 Nov 2005 15:06:09 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 248AD43D45 for ; Thu, 17 Nov 2005 15:06:08 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from 192.168.2.10 ([192.168.2.10]) by edusrv05.edu.irc.local ([192.168.44.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Nov 2005 15:06:03 +0000 Received: from by mail1.cil.se; 17 Nov 2005 15:06:03 +0000 From: Jon Otterholm To: Jeremie Le Hen In-Reply-To: <20051117135738.GH5197@obiwan.tataz.chchile.org> References: <1131541588.996.13.camel@localhost.localdomain> <20051110124903.GB67086@uk.tiscali.com> <1131629107.878.22.camel@localhost.localdomain> <20051117135738.GH5197@obiwan.tataz.chchile.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 17 Nov 2005 16:06:03 +0100 Message-Id: <1132239963.819.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port 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 15:06:10 -0000 The linux-soloution you are describeing is exactly what I want to do. Not a big fan of Linux though. I will have to wait for this to be ported to BSD. Anyone with info if this is being done? /Jon On Thu, 2005-11-17 at 14:57 +0100, Jeremie Le Hen wrote: > 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/