This test demonstrates the problem that a machine has trying to be the responder of two tunnels from two different systems, thatact on behalf of the same node. This situation can easily occur with OE, when an OE capable laptop happens toroam (unknowingly even) to a network that has an OE gateway. The situationlooks 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, createsa 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-rwThere 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-gwNote: this test uses sunrise-oe as the ultimate destination since thesystem(s) are already setup for that kind of thing.The situation is recognizeable from the situation where an extruded IP hasmoved to another location, or where one is attempting to do multihomed OE(which is not supported at this time) because the tunnels are distinguishedby having different gateways, yet one of the gateways is *equal* tothe end node.In this test, we have three nodes involves, plus DNS.(THIS IS A GOAL TEST. It does not operate at present.)