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 >>> >>> <https://www.facebook.com/ICSIL> >>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >>> <https://www.linkedin.com/company/intelligent-computing-solutions> >>> <https://twitter.com/ICSIL> >>> >>> ------------------------------ >>> *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 >>> <http://www.linkedin.com/in/fwchristian> >>> <http://facebook.com/packetflux> <http://twitter.com/@packetflux> >>> >>> >>> > > > -- > 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. >
