This test demonstrates the problem that a machine has trying to 
be the responder of two tunnels from two different systems, that
act on behalf of the same node. 

This situation can easily occur with OE, when an OE capable laptop happens to
roam (unknowingly even) to a network that has an OE gateway. The situation
looks like:

      japan		west			east          sunrise-oe
      OE-rw		OE-gw			OE-peer
#1      -------------------<***********************>------------|
#2      <******************************************>

There is no problem on OE-gw, which creates a tunnel for OE-rw's traffic.
There is also no problem on OE-rw, which typically doing FQDN OE, creates
a tunnel to OE-peer as well.

The problem is on OE-peer, where the eroute table contains:

#1   sunrise-OE/32		OE-rw/32     tunnel via OE-gw
#2   sunrise-OE/32		OE-rw/32     tunnel via OE-rw

There is a conflict between these two eroutes. We would prefer to have:
      sunrise-OE/32	OE-rw/32      tunnel via OE-rw, tunnel via OE-gw

Note: this test uses sunrise-oe as the ultimate destination since the
system(s) are already setup for that kind of thing.

The situation is recognizeable from the situation where an extruded IP has
moved to another location, or where one is attempting to do multihomed OE
(which is not supported at this time) because the tunnels are distinguished
by having different gateways, yet one of the gateways is *equal* to
the end node.

In this test, we have three nodes involves, plus DNS.


(THIS IS A GOAL TEST. It does not operate at present.)