North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Using NAT for best-exit routing
We've been doing a version of this for about a year now on a special case basis. It works well enough, but can lead to some painful behaviours as one attempts to scale. Paralleling NAT routers can help quite a bit. --Lloyd Lloyd Taylor -- [email protected] Vice President, Technical Operations DIGEX Web Site Management Group An Intermedia Company On Thu, 27 Aug 1998, Brian Dickson wrote: > 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. :-) > > 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. > > 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. ;-) > > 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). > > Comments? > -- > Brian Dickson, Email: [email protected] > Teleglobe USA, Inc., Tel : +1 703 821 4818 > Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 > McLean, Virginia, USA, 22102 http://www.teleglobe.com >
|