Internet vulnerabilities

In the referenced message, Rodney Joffe said:

Just as a guess, Marshall is probably thinking of using anycast for
something other than DNS, like http, or ftp, or telnet. And he's
wondering about state :wink:

If you don't use per-packet type load-sharing, but something like
per-flow, or per-src/dst-hash, then you can use anycast for protocols
which require state (including tcp or other connection-oriented protocols,
for that matter).

Worst-case when the server you are communicating with fails, the
connection is broken, much as it would had anycast not been in use.
A resilient protocol/application could then reestablish the connection
somewhat quickly. Actually, I guess the worst-case would be when the
original machine came back online, the connection would once again
be broken, but not due to a failure. This would probably require
people to set things up (if they are smart) not to _automatically_
return to service. That way, the previously failed box could be
re-inserted during a maintenance, for least detrimental effect.

This type of thing would be most useful for read operations, and becomes
somewhat of a problem for write operations, due to synchronization.
Therefore, it might be useful for a web server, but not so for ftp
(unless, you had a separate master machine for folks/customers to
do put operations, which is then synchonized and pushed to the
anycast read boxes).

Of course, this would only be relevant/useful within your own enterprise,
since others may be using per-packet load-sharing (which comes with
a host of problems as it is, like the high potential for out of order packets.)

Whether doing this is practical is an exercise for the reader, but it
certainly is possible. Presently, I think most folks doing anycast
take the easy stance and just use it for non-stateful connectionless
protocols (esp. dns).

Can someone from WorldComm please verify a fiber cut that happened today at
around 11:30 am (Central). I have bveen informed that a fiber cut in
Illinois (or Indiana) has been in effect (until just a few minutes) for all
of the afternoon and most of the evening.

Thanks in Advance

Gerardo A. Gregory
Manager Network Administration and Security
Affinitas, Corp.

I think the problem they are refering to is what happens if your routing
topology changes (or worse, flaps). A stateful connection (like TCP) which
would have stayed up during a routing change could potentially be shifted
to a different server which obviously wouldn't know the other one's state.
Perhaps not terrible for a web server and for recovering from a network
outage, but I'd imagine it would be pretty annoying if you managed to
develop a persistant oscillation.

That is why people use anycast DNS to refer the requester to the closest
server with via regular IP, based on which server the request hits. Of
course then there is no failover, but thats life. DNS is also more
scalable for doing anycast with customers. Which method to use is up to
you. :slight_smile:

Worldcom is reporting a problems near Chicago. Earthlink is reporting
problems affecting its customers in Indiana, Illinois, Iowa, Michigan,
Wisconsin and Ohio.

Cable & Wireless is showing delays out of Cleveland, Ohio

AT&T and Sprint aren't reporting any problems.

MFN's and PSI's network status pages have stopped working for me, so I
don't know if they are having problems.

For PSI's network, it should be



Yes. As I said in a previous message in this thread, that's a common
objection brought up by people who've never run an anycast network and are
trying to think of reasons why it might be problematic. But since in the
real world that appears to happen two orders of magnitude less frequently
than connection failures due to loss of connectivity, _when you take no
steps to prevent it_, and the prevention is both trivial and necessary
with HTTP, which is the protocol most commonly anycasted, it's not an
issue at all.

MFNs status page is:


Sean Donelan wrote: