North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Using NAT for best-exit routing
> The following is a suggestion for a scalable solution to the best-exit > problem (hot-potato requests to a web farm, best-exit data return). > (This was prompted by thinking about the original problem which induced > the most-popular topic of late.) > As far as I know it's original, so if you use it, let me know how it > works, and maybe give me some credit. :-) > Depends on your definition of scalable. Please show me a NAT box that can keep up with 1.5Gbps sustained with peaks in excess of 1.9. > The idea is basically this: the web farm provider uses a NAT device > (or configures NAT on a router) for every peering point with a given peer > who wants best-exit. Separate address pools (in private address space) > are used for each such NAT (and distinct such pool sets amongst multiple > such peer networks). Ingress traffic to the web farm provider has it's > *source* address NAT'd, and internal routing points return traffic to > the *same* NAT through which the request traffic came. > Thus, return (data) traffic is best-exit. > An interesting idea, but the address management alone becomes a nightmare. Then, when you add the sheer number of customers some of the content providers have, it becomes even more complex. It would be really cool if such a system could be made to work without turning address management into an unmitigated nightmare for the content provider, but I don't see that as being too likely. > This scales as the number of flows, not as the number of addresses announced, > so the MEDs scaling issue goes away. Performance may be an important factor, > so it is advised that anyone trying this test it in a lab first. ;-) > Yeah, performance would be a BIG factor in a large content network. > Pictorially > ,-------- provider "G" -------. > / \ > | | > NAT1 NAT2 > | | > \ / > `------- web farm "E" -------' > > Traffic flows: > West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit) > East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit) > > (Also works for NATs 3,4,5,...) > > If the NAT can handle #flows seen, at wire speed, all is well. Limits would be > the total number of simultaneous flows, and max speed of NAT. > > Side benefits are that the unique address pools allow for much easier > per-peer and per-region collection of stats, eg netflow (at some place > other than NATs). > Could be interesting, but I don't think it scales. Owen |