> Thanks, I triple checked the switch and server for 100 fdx
> and they are set
> 100 fdx. Both interfaces are getting these errors in the
> server and both
> are connected to the switch 100 fdx.
Good.
> I think that makes the
> bad nic and
> cables or bad switch ports unlikely, although slightly possible. That
> leaves drivers, interference, or software. I guess I would expect
> interference to exist with all the servers though because all
> their cables
> run next to each other and go to the same switch, so that
> kind of rules out
> interference.
Not really, especially if the source of the interference is bad cables.
Cables are cheap. Replace them as a first step. It's always possible that
you got a bad pair/batch from your supplier. This has happened to us
before. Also, note that things can happen in that room when you aren't
around that people aren't likely to tell you about, when it comes to
tripping over cables. :-)
Also don't rule out a pair of bad NICs, for the same reason, or a completely
flaky switch, or bad microcode on the switch. What kind of switch is it?
What level of software is it running? What if you swap ports with one of
the other servers (to prove that it isn't the individual ports)?
> I upgraded the solaris 2.6 with the latest
> cluster patch
> yesterday, which I think leaves software. I am writing a
> perl script now
> to see if I can catch the smaller packets and try to identify
> the source,
> but I am afraid I may find that they are dropped prior to
> ethereal seeing
> them, so I might not see anything. I think snoop has a -D
> option to show
> dropped packets, but packets are dropped for a variety of
> reasons, so I am
> not sure how you would know they were dropped because they are runts.
> Actually, that is a good question: What are the reasons
> packets are dropped
> and how do you see dropped packets with ethereal.
One more question: Does the switch or do the cards generate any kind of
proprietary frames like Bay Autotopology frames or Intel NIC failover frames
that may or may not actually be valid Ethernet frames?
As Guy Harris pointed out, snoop, ethereal, tcpdump, etc. won't help. Have
you got Sniffer Pro for Windows? You may be able to capture short frames
with that. For a FDX connection you'll probably need to either use a port
mirror on the switch, a passive cable tap, or switch to hdx and use a hub.
--J