I always say that eliminating a single point of failure depends on how big the point is :)
-mel beckman > On Jul 5, 2015, at 12:10 PM, Owen DeLong <o...@delong.com> wrote: > > A NAT box is a central point of failure for which the only cure is to not do > NAT. > > You can get clustered NAT boxes (Juniper, for example), but that just makes a > bigger central point of failure. > > Owen > >> On Jul 5, 2015, at 11:49 , Josh Moore <jmo...@atcnetworks.net> wrote: >> >> 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 :) >>>>> >>> >
