Sorry to hear you are running Redback :) I never liked them much but haven’t touched one since the old SMS500 and SMS1800 days (long before Ericsson bought them). We are migrating from E320 boxes over to MX480 in my world but that’s 99% cable/dsl subs.
I did build out a network at one point (former job) where it was originally smaller Cisco boxes at each wireless site doing PPPOE. This became cumbersome to manage all the IP pools along with some other challenges. So we migrated to a pure VLAN model at all the wireless sites and hauled the PPPOE VLAN back to centralized MX480 via MPLS network (RSVP-TE, L2VPN) and that worked very well – roughly 3500 subs across 36 sites at the time. From: Af [mailto:af-boun...@afmug.com] On Behalf Of Eric Muehleisen Sent: Wednesday, April 15, 2015 12:21 PM To: af@afmug.com Subject: Re: [AFMUG] Providing public routed IPs to customers We have two Redback SE 600's. VERY expensive. So a L2 path back to the core across the entire network can be concerning coming from a routed network. On Wed, Apr 15, 2015 at 11:16 AM, Paul Stewart <p...@paulstewart.org <mailto:p...@paulstewart.org> > wrote: DHCP needs layer2 broadcast as well to setup Discovery … sometimes the difference is when folks are using the immediate upstream router for DHCP. Depending on hardware, the immediate upstream could be a BRAS as well :) So not sure why that would be a deal breaker really? From: Af [mailto:af-boun...@afmug.com <mailto:af-boun...@afmug.com> ] On Behalf Of Eric Muehleisen Sent: Wednesday, April 15, 2015 12:07 PM To: af@afmug.com <mailto:af@afmug.com> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:li...@packetflux.com> > To: "af" <af@afmug.com <mailto: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 <mailto: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 <http://www.spitwspots.com> -- Forrest Christian CEO, PacketFlux Technologies, Inc. Tel: 406-449-3345 <tel:406-449-3345> | Address: 3577 Countryside Road, Helena, MT 59602 <mailto:forre...@imach.com> forre...@imach.com | <http://www.packetflux.com/> http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux> <http://ws-stats.appspot.com/t/pixel.png?e=setup_page_outlook_compose> <http://ws-stats.appspot.com/t/pixel.png?e=setup_page_outlook_active&uid=e965778f9a351fad7a8a860dffc144ce> <http://ws-stats.appspot.com/t/pixel.png?e=setup_page_outlook_active&uid=e965778f9a351fad7a8a860dffc144ce> -- 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.
