[12523] in North American Network Operators' Group
Re: Traffic Engineering (fwd)
daemon@ATHENA.MIT.EDU (Avi Freedman)
Thu Sep 18 20:32:11 1997
From: Avi Freedman <freedman@netaxs.com>
To: smd@clock.org (Sean M. Doran)
Date: Thu, 18 Sep 1997 20:17:00 -0400 (EDT)
Cc: freedman@netaxs.com, ekgermann@cctec.com, osborne@terra.net,
nanog@merit.edu
In-Reply-To: <ytsov2jhi6.fsf@cesium.clock.org> from "Sean M. Doran" at Sep 18, 97 08:04:49 pm
> If you have neatly solved the problem of undetectable
> route flutter, whereby something distant from your
> similarly-numbered machines causes datagrams destined for
> those machines to flip among several of them at intervals
> (particularly relatively short intervals) then I think
> that would be worthy of a talk almost anywhere.
Yep, figured that part out. Alec's approach basically avoids
the stated problem by using a DNS solution, but we've figured
out the route flutter problem, though it does assume you have
a network of your own (even if tunneled between two points).
> Moreover, if you can generalize the "slick" solution into
> moving traffic by choice from one of your similarly-
> numbered machines to another (thinking of reboots &
> backups, server-driven load balancing and the like)
> independent of service (although you could require it to
> be a NAT-friendly service, I guess) then that might make a
> trip to Phoenix worthwhile.
It won't allow TCP sessions to survive a machine going down,
but since each box runs gated, advertising its own /32 into
your IGP, presumably the box's have to be pretty sick to
keep advertising its route yet be unable to serve web pages.
The solution guarantees that a TCP session won't be RST
by a remote box getting a packet from some other TCP session
to a duplicate-numbered box, but you will, of course, have
extra latency to transmit the packets that come in at the
"wrong place" to the "right place".
I had initially postulated a TCP-session-dying approach with
a central database that got updated with enough info to
reconstruct a TCP session ({url, offset, port #s, seq #s, ...})
but that's quite complicated, obviously, and not necessary
to just solve the route flutter problem.
> Sean.
Since I'm doing the pre-NANOG tutorial thing, I was planning
on going to Phoenix anyway, though...
Rather than describe the approach in detail now I figure it'd
be more fun to have people heckle me live @ NANOG :)
Avi
