Date: Mon, 21 Nov 2005 13:45:44 +0100 From: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-net@freebsd.org Subject: Re: arp-proxy Message-ID: <1132577145.1411.20.camel@localhost.localdomain> In-Reply-To: <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> <20051121112856.GB21985@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You got it all right. Antispoof sounds nice. The reason why I have to proxy-arp mac between VLANs is that one mac cannot end up mapped to more than one port in the switches FDB. If they do - we get something called "host-flapping" on IOS-language. /Jon On Mon, 2005-11-21 at 11:28 +0000, Brian Candler wrote: > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1132577145.1411.20.camel>