The point I am concerned about is a central point of failure.



Thanks,

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161

> On Jul 5, 2015, at 2:46 PM, Owen DeLong <o...@delong.com> wrote:
> 
> Not necessarily. But what I am telling you is that whatever goes out NAT 
> gateway A has to come back in through NAT gateway A.
> 
> You can build whatever topology you want on either side of that and nothing 
> says B has to be any where near A.
> 
> Owen
> 
>> On Jul 5, 2015, at 11:25 , Josh Moore <jmo...@atcnetworks.net> wrote:
>> 
>> So basically what you are telling me is that the NAT gateway needs to be 
>> centrally aggregated.
>> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Joshua Moore
>> Network Engineer
>> ATC Broadband
>> 912.632.3161
>> 
>>> On Jul 5, 2015, at 1:29 PM, Owen DeLong <o...@delong.com> wrote:
>>> 
>>> If you want to keep that, then you’ll need a public backbone network that 
>>> joins all of your NATs and you’ll need to have your NATs use unique 
>>> exterior address pools.
>>> 
>>> Load balancing a single session across multiple NATs isn’t really possible.
>>> 
>>> Owne
>>> 
>>>> On Jul 5, 2015, at 08:11 , Josh Moore <jmo...@atcnetworks.net> wrote:
>>>> 
>>>> Performing the NAT on the border routers is not a problem. The problem 
>>>> comes into play where the connectivity is not symmetric. Multiple 
>>>> entry/exit points to the Internet and some are load balanced. We'd like to 
>>>> keep that architecture too as it allows for very good protection in an 
>>>> internet link failure scenario and provides BGP best path connectivity.
>>>> 
>>>> So traffic cones in ISP A might leave ISP B or traffic coming in ISP A may 
>>>> come in ISP B simultaneously.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Joshua Moore
>>>> Network Engineer
>>>> ATC Broadband
>>>> 912.632.3161
>>>> 
>>>>> On Jul 5, 2015, at 10:43 AM, Mel Beckman <m...@beckman.org> wrote:
>>>>> 
>>>>> WISPs have been good at solving this, as they are often deploying 
>>>>> greenfield networks. They use private IPv4 internally and NAT IPv4 at 
>>>>> multiple exit points. IPv6 is seamlessly redundant, since customers all 
>>>>> receive global /64s; BGP handles failover. If you home multiple upstream 
>>>>> providers on a single NAT gateway hardware stack, redundancy is also 
>>>>> seamless, since your NAT tables are synced across redundant stack 
>>>>> members.  If you have separate stacks, or even sites, IPv4 can fail over 
>>>>> to an alternate NAT Border gateway but will lose session contexts, unless 
>>>>> you go to the trouble of syncing the gateways. Most WISPs don't.  
>>>>> 
>>>>> -mel beckman
>>>>> 
>>>>>> On Jul 5, 2015, at 7:25 AM, Josh Moore <jmo...@atcnetworks.net> wrote:
>>>>>> 
>>>>>> So the question is: where do you perform the NAT and how can it be 
>>>>>> redundant?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Joshua Moore
>>>>>> Network Engineer
>>>>>> ATC Broadband
>>>>>> 912.632.3161
>>>>>> 
>>>>>>> On Jul 5, 2015, at 10:12 AM, Mel Beckman <m...@beckman.org> wrote:
>>>>>>> 
>>>>>>> Josh,
>>>>>>> 
>>>>>>> Your job is simple, then. Deliver dual-stack to your customers and if 
>>>>>>> they want IPv6 they need only get an IPv6-enabled firewall. Unless 
>>>>>>> you're also an IT consultant to your customers, your job is done. If 
>>>>>>> you already supply the CPE firewall, then you need only turn on IPv6 
>>>>>>> for customers who request it. With the right kind of CPE, you can run 
>>>>>>> MPLS or EoIP and deliver public IPv4 /32s to customers willing to pay 
>>>>>>> for them. Otherwise it's private IPv4 and NAT as usual for IPv4 
>>>>>>> traffic. 
>>>>>>> 
>>>>>>> -mel via cell
>>>>>>> 
>>>>>>>> On Jul 5, 2015, at 6:57 AM, Josh Moore <jmo...@atcnetworks.net> wrote:
>>>>>>>> 
>>>>>>>> We are the ISP and I have a /32 :)
>>>>>>>> 
>>>>>>>> I'm simply looking at the best strategy for migrating my subscribers 
>>>>>>>> off v4 from the perspective of solving the address utilization crisis 
>>>>>>>> while still providing compatibility for those one-off sites and 
>>>>>>>> services that are still on v4.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Joshua Moore
>>>>>>>> Network Engineer
>>>>>>>> ATC Broadband
>>>>>>>> 912.632.3161
>>>>>>>> 
>>>>>>>> On Jul 5, 2015, at 9:55 AM, Mel Beckman <m...@beckman.org> wrote:
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Josh Moore wrote:
>>>>>>>>>> 
>>>>>>>>>> Tunnels behind a CPE and 4to6 NAT seem like bandaid fixes as they do 
>>>>>>>>>> not give the benefit of true end to end IPv6 connectivity in the 
>>>>>>>>>> sense of every device has a one to one global address mapping.
>>>>>>>>> 
>>>>>>>>> No, tunnels do give you one to one global IPv6 address mapping for 
>>>>>>>>> every device. From a testing perspective, a tunnelbroker  works just 
>>>>>>>>> as if you had a second IPv6-only ISP. If you're fortunate enough to 
>>>>>>>>> have a dual-stack ISP already, you can forgo tunneling altogether and 
>>>>>>>>> just use an IPv6-capable border firewall. 
>>>>>>>>> 
>>>>>>>>> William Waites wrote:
>>>>>>>>>> I was helping my
>>>>>>>>>> friend who likes Apple things connect to the local community
>>>>>>>>>> network. He wanted to use an Airport as his home gateway rather than
>>>>>>>>>> the router that we normally use. Turns out these things can *only* do
>>>>>>>>>> IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is
>>>>>>>>>> not exactly a clear path to native IPv6 for your lab this way.
>>>>>>>>> 
>>>>>>>>> Nobody is recommending the Apple router as a border firewall. It's 
>>>>>>>>> terrible for that. But it's a ready-to-go tunnelbroker gateway. If 
>>>>>>>>> your ISP can't deliver IPv6, tunneling is the clear path to building 
>>>>>>>>> a lab. If you have a dual-stack ISP already, the clear path is to use 
>>>>>>>>> an IPv6-capable border firewall. 
>>>>>>>>> 
>>>>>>>>> So you are in a maze of non-twisty paths, all alike :)
>>> 
> 

Reply via email to