I've been investigating a problem recently where we were experiencing
intermittent packet loss and errors on the switch to a particular
server.

In the end we traced the problem to the fact that the server had been
connected to the switch using a crossover cable.

In my view this shouldn't have worked at all, but it did, albeit at a
reduced rate and with significant errors.

Can anyone explain why this would actually work? Was the switch or NIC
compensating in some way for the cable being incorrect?

<WeeJockMacFeegle@gmail.com> wrote in message
news:1142592346.860152.122920@z34g2000cwc.googlegr oups.com...
> I've been investigating a problem recently where we were experiencing
> intermittent packet loss and errors on the switch to a particular
> server.
>
> In the end we traced the problem to the fact that the server had been
> connected to the switch using a crossover cable.
>
> In my view this shouldn't have worked at all, but it did, albeit at a
> reduced rate and with significant errors.
>
> Can anyone explain why this would actually work? Was the switch or NIC
> compensating in some way for the cable being incorrect?

Many, if not most, new GB NIC's and switches supports "Auto MDI/MDX"
and will support both stright and twisted cables.

/HC

In article <121lbrd2hqj4mf1@corp.supernews.com>,
"Harald Andersen" <ikkespam@gmail.com> wrote:

> <WeeJockMacFeegle@gmail.com> wrote in message
> news:1142592346.860152.122920@z34g2000cwc.googlegr oups.com...
> > I've been investigating a problem recently where we were experiencing
> > intermittent packet loss and errors on the switch to a particular
> > server.
> >
> > In the end we traced the problem to the fact that the server had been
> > connected to the switch using a crossover cable.
> >
> > In my view this shouldn't have worked at all, but it did, albeit at a
> > reduced rate and with significant errors.
> >
> > Can anyone explain why this would actually work? Was the switch or NIC
> > compensating in some way for the cable being incorrect?
>
> Many, if not most, new GB NIC's and switches supports "Auto MDI/MDX"
> and will support both stright and twisted cables.

In that case, should he have been getting errors at all because of the
incorrect cable type?

Does this interfere with auto-sensing speed and duplex? Mismatches
there often result in lots of packet loss.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

> > > I've been investigating a problem recently where we were experiencing
> > > intermittent packet loss and errors on the switch to a particular
> > > server.
> > >
> > > In the end we traced the problem to the fact that the server had been
> > > connected to the switch using a crossover cable.
> > >
> > > In my view this shouldn't have worked at all, but it did, albeit at a
> > > reduced rate and with significant errors.
> > >
> > > Can anyone explain why this would actually work? Was the switch or NIC
> > > compensating in some way for the cable being incorrect?
> >
> > Many, if not most, new GB NIC's and switches supports "Auto MDI/MDX"
> > and will support both stright and twisted cables.
>
> In that case, should he have been getting errors at all because of the
> incorrect cable type?

No. The cable type does not explain the errors. If at least one of
his transceivers supports this mechanism, then both are the correct
cable type.

> Does this interfere with auto-sensing speed and duplex? Mismatches
> there often result in lots of packet loss.

Auto MDI/MDX does not make any difference to the detection of speed and
duplex settings. He still has to get this right.

Could it have been a *bad* crossover cable?

/chris

> Auto MDI/MDX does not make any difference to the detection of speed and
> duplex settings. He still has to get this right.
>
> Could it have been a *bad* crossover cable?
>
> /chris

I don't think it was a bad crossover cable. Got the cable tester on it
and it report all fine. I suspect it was probably a mis-match between
NIC and switch speed/duplex settings. Switch was set to 100Mb/Full,
NICs auto set themselves at 100Mb/Half.

Strapping the NICs to 100Mb/Full killed the connection. I suspect
because the NIC could handle having the wrong cable at Half Duplex, but
not at Full Duplex.

Thanks everyone.

Gary

WeeJockMacFeegle wrote:
> > Auto MDI/MDX does not make any difference to the detection of speed and
> > duplex settings. He still has to get this right.
> >
> > Could it have been a *bad* crossover cable?
> >
> > /chris
>
> I don't think it was a bad crossover cable. Got the cable tester on it
> and it report all fine. I suspect it was probably a mis-match between
> NIC and switch speed/duplex settings. Switch was set to 100Mb/Full,
> NICs auto set themselves at 100Mb/Half.

That was certainly the source of your errors.

> Strapping the NICs to 100Mb/Full killed the connection. I suspect
> because the NIC could handle having the wrong cable at Half Duplex, but
> not at Full Duplex.

Sounds like a buggy driver.

Auto MDI/MDX and autonegotiation of link speed and duplex are all under
the driver's control. It sounds like your setup forced the NIC to wire
itself like a host port when you forced the speed and duplex.

The two features (MDI/MDX and link modes) are not necessarily related
to one another.

/chris

WeeJockMacFeegle <WeeJockMacFeegle@gmail.com> wrote:
> Switch was set to 100Mb/Full, NICs auto set themselves at
> 100Mb/Half.

Some old boilerplate I trot-out from time to time:

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal collisions don't count here). On the side running full-duplex
you will see things like FCS errors. Note that those errors are not
necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...