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 :) >>>> >>
