From owner-freebsd-net@FreeBSD.ORG Mon Nov 21 11:29:01 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 B30AB16A41F for ; Mon, 21 Nov 2005 11:29:01 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B039343D45 for ; Mon, 21 Nov 2005 11:29:00 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id B6F319E; Mon, 21 Nov 2005 06:29:21 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 59ACB835; Mon, 21 Nov 2005 06:29:20 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1Ee9qy-0005lU-Uf; Mon, 21 Nov 2005 11:28:56 +0000 Date: Mon, 21 Nov 2005 11:28:56 +0000 From: Brian Candler To: Jon Otterholm Message-ID: <20051121112856.GB21985@uk.tiscali.com> References: <1131541588.996.13.camel@localhost.localdomain> <20051110124903.GB67086@uk.tiscali.com> <1131629107.878.22.camel@localhost.localdomain> <20051117135738.GH5197@obiwan.tataz.chchile.org> <1132239963.819.18.camel@localhost.localdomain> <20051117152357.GA8209@uk.tiscali.com> <1132242723.819.45.camel@localhost.localdomain> <20051117162748.GA8417@uk.tiscali.com> <20051117173535.GF97528@gremlin.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051117173535.GF97528@gremlin.foo.is> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org 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: Mon, 21 Nov 2005 11:29:01 -0000 > > On Thu, Nov 17, 2005 at 04:52:03PM +0100, Jon Otterholm wrote: > > > Scenario#1: > > > -I have a range of ip's, for example 215.10.10.0 - 215.10.10.255. > > > -I want to distrubute theese ip's to my customers via DHCP. > > > -They are all atached to me via a VLAN-trunk on a unique VID > > > -I have 200+ customers. Let me see if I can summarise your requirements: vlan1 cust1 --------, \ service network vlan2 \ trunked single subnet x.y.z.0/24 cust2 -----------===============*------+------------+------- / | | vlan3 / DHCP srv router ---> Internet cust3 --------' The constraints are: - cust1, cust2, cust3 are all on the same subnet x.y.z.0/24 and get an IP address allocated by DHCP - However, the MAC address for cust1 must never appear as a source MAC address on vlan2 or vlan3, as this would confuse the provider's trunked switching infrastructure So you can't just bridge all the VLANs together. Rather: 1. a broadcast from custX must appear on the service network, but not on any of the other customer VLANs. More strongly, no packet from custX may appear on any other VLAN apart from the service network. [*] 2. a broadcast from the service subnet should appear on all customer VLANs (e.g. ARP from DHCP server or router) 3. an ARP request for custY from custX must be proxy-ARP responded to by a device on the service network, otherwise customers wouldn't be able to communicate with each other. 4. a unicast packet from the service network to a customer must be forwarded to the correct customer VLAN Is that a reasonable summary? Taking that as the base: Point (4) implies that a bridge forwarding table must still be built, because the device performing this function (labelled '*' in the above diagram) needs to associate a MAC address with a VLAN, and do so by learning rather than static configuration. Point (1) says that you can't just bridge all the VLANs together, because otherwise a packet to a broadcast address or to an unknown MAC address would be forwarded to all the other VLANs. We want this to happen for packets originating from the service network (point (2)), but not for packets which originate from the customer networks. So, some sort of L2 forwarding filter should do the trick: configure it so that packets may only be forwarded to customer VLANs if they originate from the service network. If this filter is applied, you guarantee that a customer's MAC address will never appear as a source on any other VLAN. Point (3), proxy ARP, is easy enough. You know all the possible customer IPs - they are exactly the range assigned to the DHCP server to allocate - and therefore you can proxy-ARP respond for any IP address within the DHCP range, as long as the request originated from a customer VLAN (which can also be determined by the ARP source IP). The router itself could perform this proxy ARP function, or else any server on the service network running something like choparp (which can give out the router's MAC address in the ARP responses). IP datagrams from custX to custY then go custX->router->custY. So actually, when thought about like this, the L2 masquerading requirement vanishes, and what you really need is bridging plus some L2 filtering based on ingress and egress interfaces. Unfortunately, I don't know if FreeBSD has this level of L2 filtering (I note that the bridge(4) documentation says that ipf/ipfw filtering only works for IP datagrams). However a frob on the bridging code should be possible; call the first interface 'master' and the rest 'slaves', and have a rule so that packets to a 'slave' interface are only forwarded if they originated from the 'master' interface. Aside: the network as designed above has an obvious flaw that any customer can DHCP for as many different machines as they wish, and therefore exhaust your DHCP pool. You could have a separate mini DHCP server listening on each VLAN and only handing out a single IP, but that doesn't stop customers stealing other customer's IPs through static configuration. So actually, I think you need anti-spoofing filters on each VLAN too. Doing that, you end up statically routing a separate IP down each VLAN, in which case what you *really* want is to be able to configure each VLAN subinterface as if it were a point-to-point interface. But I don't think FreeBSD supports that on broadcast media. Regards, Brian. [*] Or if it did appear on the other customer VLANs, it would have to be masqueraded to appear as if it came from a MAC address on the service network; however I believe this isn't actually necessary, as the only broadcasts we really care about here are ARP requests. All others can be dropped, and indeed probably should be dropped so that all your customers don't get drowned in each other's broadcast traffic.