North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Using NAT for best-exit routing
- From: Lloyd Taylor
- Date: Fri Aug 28 14:24:06 1998
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
Lloyd Taylor -- firstname.lastname@example.org
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. ;-)
> ,-------- 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).
> Brian Dickson, Email: email@example.com
> 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