Ever thought of enabling port isolation per AP switch port to prevent bridge 
table excess sizes?   I can see it growing crazy with sites with many APs and 
wondering if that’s some of our CPU/memory issues on older Rocket M5s.


> On Apr 16, 2015, at 4:54 PM, Brett A Mansfield <[email protected]> 
> wrote:
> 
> 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 <[email protected] 
> <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>] On 
>> Behalf Of Josh Reynolds
>> Sent: Thursday, April 16, 2015 4:31 PM
>> To: [email protected] <mailto:[email protected]>
>> Subject: Re: [AFMUG] Providing public routed IPs to customers
>> 
>> OSPF
>> 
>> On April 16, 2015 1:46:50 PM AKDT, Sterling Jacobson <[email protected] 
>> <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>] 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 <[email protected] 
>> <mailto:[email protected]>> wrote:
>> Just enable the PPPoE server on the routers already at your towers.
>> 
>> 
>> 
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com <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: "Eric Muehleisen" <[email protected] <mailto:[email protected]>>
>> To: [email protected] <mailto:[email protected]>
>> 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 
>> <[email protected] <mailto:[email protected]>> 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) 
>> <[email protected] <mailto:[email protected]>> 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" <[email protected] 
>> <mailto:[email protected]>> wrote:
>> There are reasons to have PPPoE other than IP address assignment.
>> 
>> 
>> 
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com <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)" <[email protected] 
>> <mailto:[email protected]>>
>> To: "af" <[email protected] <mailto:[email protected]>>
>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 | Address: 3577 Countryside Road, Helena, MT 59602
>> [email protected] <mailto:[email protected]> | http://www.packetflux.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.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to