I use OSPF on my network. I send a /25 to each tower which I then break up into 
/27 per AP. I then give static IPs to each customer and only run DHCP for 
management networks. 

I used use a /24 that was open to each tower, but the bridge table almost 
completely consumed the RAM in the CPEs causing very slow speed issues. 

Thank you,
Brett A Mansfield

> On Apr 16, 2015, at 4:38 PM, Sterling Jacobson <sterl...@avative.net> wrote:
> 
> OSPF works if you have a truly geographically diverse ring redundancy path.
>  
> Barring that it does little for the situation.
>  
> I prefer nearness in redundancy which multiple providers, which lends itself 
> to /24 or larger public IP space and BGP type protocol.
>  
>  
>  
> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Josh Reynolds
> Sent: Thursday, April 16, 2015 4:31 PM
> To: af@afmug.com
> Subject: Re: [AFMUG] Providing public routed IPs to customers
>  
> OSPF
> 
> On April 16, 2015 1:46:50 PM AKDT, Sterling Jacobson <sterl...@avative.net> 
> wrote:
> Which isn’t really good for redundancy on fixed IP assignments (whether they 
> be DHCP or PPPoE) because a break in the traffic near the site would require 
> a redundant connection near the site to carry the minimal /24 or larger 
> public block.
>  
> 
> Or you resort to temporary NAT, or re-assignment.
>  
> 
>  
> 
>  
> 
> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mathew Howard
> Sent: Thursday, April 16, 2015 11:28 AM
> To: af
> Subject: Re: [AFMUG] Providing public routed IPs to customers
>  
> 
> Terminating PPPoE at the tower doesn't really give you much advantage over 
> DHCP as far as using limited IP space more efficiently though, you're still 
> going to have to assign a subnet to each tower, more or less the same as you 
> would with  DHCP. if the goal is to use limited IP space more efficiently, 
> you really need to centralize PPPoE so you can use the same IP pool for 
> everything.
>  
> 
> On Wed, Apr 15, 2015 at 11:25 AM, Mike Hammett <af...@ics-il.net> wrote:
> Just enable the PPPoE server on the routers already at your towers.
> 
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> 
> 
> From: "Eric Muehleisen" <ericm...@gmail.com>
> To: af@afmug.com
> Sent: Wednesday, April 15, 2015 11:06:36 AM
> Subject: Re: [AFMUG] Providing public routed IPs to customers
> 
> PPPoE auth is broadcast. This will require a L2 path back to you PPPoE server 
> (BRAS). This is a deal breaker for many. Overhead is minimal. There will be a 
> some broadcast chatter on your L2 subnet. This can be filtered a number of 
> ways and usually not a concern.
>  
> 
> On Wed, Apr 15, 2015 at 10:05 AM, That One Guy /sarcasm 
> <thatoneguyst...@gmail.com> wrote:
> pppoe has been discussed quite often as a solution for limited IP space. 
> Could someone give a breakdown of the required components from the edge of 
> the network to the customer and the required topology?
> My understanding, which is probably wrong, is a client on the network 
> connects, the device gets an IP, normally DHCP that can communicate all the 
> way back to the pppoe server (what exactly is this)
> The credentials are provided and a pppoe session is established, all traffic 
> flows through the pppoe tunnel and exits at the edge of the network
> the tunnel is essentially a vpn tunnel? there are overheads that need to be 
> accounted for?
> Where is the public IP actually at? is it assigned as essentially a /32 at 
> the customer end of the tunnel?
>  
> 
> How does the client device know where the pppoe server is, is this provided 
> in the DHCP response?
>  
> 
> I know my understanding of this is probably totally way off, but I would love 
> to know more, accurately
>  
> 
> On Wed, Apr 15, 2015 at 7:00 AM, Forrest Christian (List Account) 
> <li...@packetflux.com> wrote:
> Which is why we played with it.  In the end, it seemed that the amount of 
> support hassles with pppoe wasn't worth the hassle.   But, this was a while 
> ago and pppoe has grown up a lot, so my opinion is probably not valid anymore.
> 
> On Apr 15, 2015 5:27 AM, "Mike Hammett" <af...@ics-il.net> wrote:
> There are reasons to have PPPoE other than IP address assignment.
> 
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> 
> 
> From: "Forrest Christian (List Account)" <li...@packetflux.com>
> To: "af" <af@afmug.com>
> Sent: Wednesday, April 15, 2015 3:02:50 AM
> Subject: Re: [AFMUG] Providing public routed IPs to customers
> 
>  
> 
> (WISP HAT ON)
> 
> We have a subnet (or a couple of subnets, as sites have grown) at each tower, 
> and an public IP statically assigned to each customer.  The radio gets a 
> managment address out of 172.[16-31].x.x which corresponds to the public IP 
> address.
> 
> No DHCP anywhere, no PPPoE.
> 
> But again, we have an /18 and a /19 assigned to us from back before NAT 
> really existed and DHCP implementations from the early '90's kinda sucked.   
> We've played with PPPoE and DHCP, but kinda have been spoiled by the 
> simplicity and reliability of a statically numbered network.
> 
> -forrest
>  
> 
> On Tue, Apr 14, 2015 at 6:20 PM, Josh Reynolds <j...@spitwspots.com> wrote:
> For those of you currently providing public/routed ips to customers? What is 
> your topology like and delivery method?
> 
> Looking at doing a few things, have considered a few options, and wanted to 
> look out there and see what other people are doing.
> 
> Thanks
> 
> -- 
> Josh Reynolds
> CIO, SPITwSPOTS
> www.spitwspots.com
> 
> 
> 
> 
> --
> Forrest Christian CEO, PacketFlux Technologies, Inc.
> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
> forre...@imach.com | http://www.packetflux.com
>   
> 
>  
> 
> 
> 
>  
> 
> --
> If you only see yourself as part of the team but you don't see your team as 
> part of yourself you have already failed as part of the team.
>  
> 
>  
> 
>  
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to