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. :-) 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: briand@teleglobe.net 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
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 -- taylorl@digex.net 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: briand@teleglobe.net 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
"Brian Dickson" <briand@teleglobe.net> writes:
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.
Using a transparant cache for ingress traffic has the same effect as a NAT device, and scales with the number of concurrent flows. A cache farm is more expensive to provision and deploy than a simple NAT, but has the advantage of allowing for logging of source/destURL pairs, which may be important to some content providers. Caching can also can be a significant performance improvement in many cases, such as paths with high latency*BW links or congested long haul circuits. -jem John Milburn jem@xpat.com Director - BoraNet jem@bora.net Cell +82 19-220-7035 Tel +82 2-220-7035 Dacom Corporation, Seoul, Korea Fax +82 2-220-0751 The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
participants (3)
-
Brian Dickson -
jem＠xpat.com -
Lloyd Taylor