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