Date: Thu, 17 Nov 2005 17:35:35 +0000 From: Baldur Gislason <baldur@foo.is> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-net@freebsd.org, Jon Otterholm <jon.otterholm@ide.resurscentrum.se>, Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: arp-proxy Message-ID: <20051117173535.GF97528@gremlin.foo.is> In-Reply-To: <20051117162748.GA8417@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 17, 2005 at 04:27:48PM +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. > > > > If I was to subnet these addresses so that all the sustomers would get > > their own IF (with an IP) in my router and their own IP I could create a > > bunch of /30-nets but each customer would take up 4 IP's (net, G/W, > > CustomerIP, Broadcast) - and that is a big vaste of IP's in my opinion. > > Albeit one that you can sensibly justify to a registry for your purpose. > > If you could get clients to run PPPoE, then you wouldn't need to allocate > any /30 subnets to the VLANs, and you could give each customer a single /32 > IP (either statically or from a pool). Multiple customers could share a VLAN > which might be useful in future, e.g. if one VLAN serves a building with > multiple users. PPP has no home in a broadband network IMO. It's an ugly (telco) approach to things. An always-on connection shouldn't have a session based tunnel to make it work. > > > If I instead could create a pseudo bridge with a "mother if" acting as > > gateway, distrute IP's via DHCP (ISC?) I could reduce the number of IP's > > and administration when adding new customers. > > > > Anyone with a souloution or revelation? > > I think it's tricky, given the additional constraints you gave in your other > E-mails. In particular, you said that MAC address xx:xx:xx:xx:xx:xx which > originates on VLAN X must never appear as a source MAC address on any other > VLAN, because that would confuse the switching infrastructure which links > the bundle of VLANs to the customer sites. (i.e. the VLANs are not true > VLANs because they are not properly isolated from each other) > > Given DHCP, you're not statically assigning a particular IP or range of IPs > to a particular vlanN interface: so you can't "route add" to send traffic > for IP address x.x.x.x down VLAN Y. Hence you need to do dynamic bridging, > but with the MAC source address masquerading. > > Now, this is not the Linux proxy-arp solution described in the link you > gave; it's something very different. I'm not aware of any implementation of > this on any platform. I do know an implementation of this. Packetfront's ASR line of layer 3 switches does exactly this. It is a DHCP relay and ARP proxy, you can have multiple switches on the same distribution ring but it's all IP, using OSPF for managing the paths, no broadcast traffic makes it between different ports. These are specific switches designed for ethernet and fiber to the home networks. I think the routing approach in FreeBSD is brilliant, but it can be a little limiting in some aspects. It is a bit reluctant to break the rules of how routing is normally done. I have had situations where I wanted to make an ARP entry for a host that was not on a subnet I had configured on any interface (as in make a host route pointing to a mac address and a certain interface) I've also wanted to have multiple interfaces on the same physical network with different addresses on the same subnet. Now, these are both ugly hacks to which there are better approaches, but those approaches don't always apply. Baldur
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051117173535.GF97528>