>>> [simh and second NICs]
>> Except if you're on something like a Sun which uses the same MAC
>> address for all interfaces, in which case the poor switch will get
>> Terribly Confused.  (And if you don't have a switch, [...])

> first of all, you can probably make the sun not do that.

Yes.

More modern Suns have a PROM "setenv" setting to do that, though I
think NetBSD paid no attention to it last time I saw it mentioned on
the lists.  (I don't think I have Suns that recent, so I wasn't paying
close attention.)

Older Suns require hacks in their Ethernet drivers to do this.  It can
be done, but depending on various factors (age of source tree, which
NICs are involved, probably others) the degree of ease of doing this
will vary, probably widely.

> anyway, i imagine it would all work out just fine, barring a switch
> that insisted that the same mac address *not* appear on two different
> ports.

If the switch does VLANs, and the ports are in different VLANs, the
switch is broken if it gets upset.

Otherwise, I think you'll find that most switches _will_ get upset to
some degree.  The mildest reaction I would expect is that the switch
will send all traffic for that MAC address to whichever interface most
recently output a packet.

> just because the hardware addresses match doesn't mean it's all gonna
> fall apart.

No, and if you're on 10base5 or 10base2 I expect it to work fine,
modulo any possible software upset the ARP code might experience over
seeing its own MAC address coming form an apparently foreign port.
10baseT with hubs should work the same.

10baseT with switches is another story, because switches depend on MAC
addresses to know which port to send packets to.

Of course, this is all speculation (though relatively firmly founded; I
have been working with such things for a long time).  If anyone's tried
it, I'd love to hear the results.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B