Date: Thu, 17 Nov 2005 16:06:03 +0100 From: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: freebsd-net@freebsd.org, Brian Candler <B.Candler@pobox.com> Subject: Re: arp-proxy Message-ID: <1132239963.819.18.camel@localhost.localdomain> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1132239963.819.18.camel>