I agree and disagree with you. NAT is good and works well for most home users. I
have issues with consoles and NAT, wherein I have many users who want to game
together, and xbox doesn't let that happen nicely. I hand out 1 public to those
who need it, more for those who want to pay. As for network redundancy and the
failover. That works just fine with publics, better if you have your own ASN. I
agree that having your own ASN raises costs and there is a pretty step learning
curve to using it and using it well. There are trade offs to both methods and
you found one that works for you.


Matt Larsen - Lists wrote:
> I believe that we have fixed this by using the StarOS policy routing to 
> split up some of our subnets to SourceNAT through a different IP address 
> on our NAT server.
> 
> If we are going to get into the public vs. privates discussion, well....
> 
> I have used NAT for customer IP addresses from day 1.   I used to use 
> publics, but it was a tremendous pain in the ass, and would be very 
> difficult to implement on my current network design (routed subnets at 
> every single location) so I have no interest in giving each customer 
> their own public IP address.   There are about 160 private subnets on 
> the access points in my network, so I have no intention of switching to 
> publics anytime soon.   I also loathe PPPoE and have worked with a 
> couple of people who tried to convert to it and converted back as soon 
> as they could because it just didn't work as well as advertised.   YMMV, 
> but I'm just fine not using it.
> 
> NAT has been very beneficial to my customers as a whole, since they are 
> not directly exposed to the Internet and we have far fewer 
> virus/trojan/backdoor issues because of it.    We do have a few folks 
> who need a public IP, and route several subnets of public IP addresses 
> out to towers where public IP addresses are needed.   That is fine with 
> me, because we charge extra for the IP addresses.   Just another reason 
> for power users to move up the pricing ladder if they want the extras.  
> 
> Not using publics has also been a godsend as far as maintaining 
> flexibility between backbone providers and utilization of secondary 
> links in the event of failures.  Sometime in the next month, I'm 
> switching my primary backbone to go through a new provider that is 
> delivering 50meg for the same price that I was previously paying for 15. 
>   Moving traffic to that backbone will be as simple as changing one line 
> in a policy routing statement.   If I was using publics, I would still 
> be stuck with the previous provider.   I don't like being hostage to 
> outside network providers if I can avoid it.   In addition to my primary 
> backbone link, I also have backbone links with two other neighboring 
> WISPs and the ability to route traffic to the Internet through them in 
> the event of an outage on my network between my APs and my NOC.  They 
> can do the same thing through my network.    Just last week, a set of 
> rolling power outages took out two towers that were the redundant paths 
> to five APs on the far eastern side of my network.   OSPF figured it out 
> and routed them out through my neighbor's network until the towers came 
> back up and it switched back.   Same thing happened on his network last 
> month, and we handled the majority of his traffic until his backbone 
> link was back up.   That is not a very simple thing to implement with 
> public IP addresses, but it was pretty easy to make it happen with privates.
> 
> So yeah, I have my reasons for using NAT.   Switching to publics is a 
> rhetorical answer, not a useful one.
> 
> Matt Larsen
> vistabeam.com
> 
> 
> 
> Mike Hammett wrote:
>> I believe Matt has around 5k subs, maybe I'm wrong.  At 5k subs, his cost 
>> per year per IP address is $0.45.  That's under $0.04/month.  I'd consider 
>> that a reasonable expense.
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> --------------------------------------------------
>> From: "Scott Reed" <scottr...@onlyinternet.net>
>> Sent: Wednesday, October 28, 2009 1:23 PM
>> To: "WISPA General List" <wireless@wispa.org>
>> Subject: Re: [WISPA] NAT issue with Hotmail/Yahoo/Google
>>
>>   
>>> <RANT>
>>> So, as with so much that goes on the lists, not just this one, "oh, you
>>> aren't doing it my way so the fix is do it my way."  What a bunch of
>>> baloney!!
>>> There are lots of ways to do almost everything we do as ISPs.  What
>>> really needs to happen is for people to read the post, think about what
>>> the real question is and then, if and only if, the can pose a solution
>>> to the real problem, post a suggestion.
>>>
>>> But, since the only posts I have seen to Matt's is give everyone a
>>> public address, I have a few questions:
>>>
>>> So, who is going to buy Matt a block of IPs to fix this non-NAT issue?
>>> I ask, because I do as Matt does and if that is the fix, I need someone
>>> to buy me a block as well.
>>> But the issue isn't really NAT, is it?
>>> The real question is how does he deal with the current issue on his
>>> current network?
>>>
>>> </RANT>
>>>
>>> Matt Larsen - Lists wrote:
>>>     
>>>> We are having a problem with certain sites that are rejecting our
>>>> customers because they say the IP address has sent too much traffic over
>>>> the last 24 hours.   This is a problem, as 98% of our customers are
>>>> behind a single NATted IP address.   I am just changing the IP address
>>>> of the NAT server every 12 hours now, but am looking for a better
>>>> solution.   Anyone have any similar issues?
>>>>
>>>> Matt Larsen
>>>> vistabeam.com
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> WISPA Wants You! Join today!
>>>> http://signup.wispa.org/
>>>> --------------------------------------------------------------------------------
>>>>
>>>> WISPA Wireless List: wireless@wispa.org
>>>>
>>>> Subscribe/Unsubscribe:
>>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>>
>>>> Archives: http://lists.wispa.org/pipermail/wireless/
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 
>>>> 10/28/09 09:34:00
>>>>
>>>>
>>>>       
>>> -- 
>>> Scott Reed
>>> Sr. Systems Engineer
>>> GAB Midwest
>>> 1-800-363-1544 x4000
>>> Cell: 260-273-7239
>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> WISPA Wants You! Join today!
>>> http://signup.wispa.org/
>>> --------------------------------------------------------------------------------
>>>
>>> WISPA Wireless List: wireless@wispa.org
>>>
>>> Subscribe/Unsubscribe:
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>> Archives: http://lists.wispa.org/pipermail/wireless/
>>>
>>>     
>>
>> --------------------------------------------------------------------------------
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> --------------------------------------------------------------------------------
>>  
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>>   
> 
> 
> 
> --------------------------------------------------------------------------------
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> --------------------------------------------------------------------------------
>  
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/


--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to