Traffic Engineering (fwd)

Avi Freedman freedman at
Fri Sep 19 00:17:00 UTC 1997

> 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 :)


More information about the NANOG mailing list