Traffic Engineering (fwd)

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.


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