ping doesn't use qnet, it uses the IP stack.

Qnet 101
--------

Let's say you have two hosts:  host1 and host2
(this sound a bit like a Dr Suess story, but
stick with me).

Regardless of the number of network links between
host1 and host2, if you have at least ONE functioning
network link between the two, and qnet is running
on both, on host1 you can do the following to test
qnet:

  # ls /net
  # ls /net/host2
  # pidin -n host2
  # pidin > /net/host2/tmp/fubar1
  # cat /proc/qnetstats

And on host2, you can do the following to test qnet:

  # ls /net
  # ls /net/host1
  # pidin -n host1
  # pidin > /net/host1/tmp/fubar2
  # cat /proc/qnetstats
 
On host2, you could even look at the qnetstat on host1:

  # cat /net/host1/proc/qnetstats

Ok.  Now, onto multiple links.  To keep it simple,
assume you have two ethernet nics (and drivers) so
that when qnet starts, it finds and uses both.

With two crossover cables attached between host1
and host2, you ought to be able to repeat the above,
and if you look at the qnetstats, you will see that
packets flow over both links (load balancing).

Now, disconnect one of the cables, and repeat
the above tests - they should still succeed,
using only the single functioning network link.
You can verify this by looking at the qnetstats.
This is failover functioning correctly.

Now, reconnect the disconnected cable.  After
the drivers auto-negotiation is completed,
re-run the above tests.  You should see qnet
using both links again, via the counts in the
qnetstats.

Just to re-iterate: qnet and tcp/ip are both
separate, distinct, orthogonal protocols which
live above the driver at the SAME LEVEL.

99.999% of our customers use the default ethernet
encapsulation (eg bind=en0) which has qnet talk
directly to the driver to transmit and receive
packets.

0.0001% of our customer use "bind=ip" which
instructs qnet to talk to the tcp/ip stack
to transmit and receive packets, which are
encapsulated with IP headers.  We have protocol
type for qnet IIRC.

Clear as mud?

--
aboyd