Re: "Forcing" gigabit link operation

Stephen Sprunk wrote:
<googlegroups@xxxxxxxxxx> wrote in message

Bernie told us that *both*ends* were running full duplex.

He later clarified that both ends were configured for FDX, but one end was
silently operating as HDX.

Hrm. This isn't/wasn't clear to me.

This is equivalent to the case where one side is
forced to FDX and the other side is trying to auto-neg.

In that case, one end should clearly be operating in FD mode and the
other clearly operating in HD mode. "silent" HD mode operation where
the interface claims FD mode sounds like a different scenario to me.
Namely, that of a broken interface.

If you ever see collisions on an FDX port, you have a duplex mismatch. The
cause is only interesting after you recognize the symptoms.

No. Rich told us earlier that you should never see collisions on an FD
port:

RS> If your switch is operating in full-duplex mode, how can it
possibly
RS> detect collisions?

In that case, neither end should be detecting collisions. Shouldn't
even be looking for them.

The hardware is there either way, so there's no harm in watching for
something even if it's not supposed to happen, and it's a useful diagnostic
considering duplex mismatches are common. It's probably cheaper to leave it
on than to turn it off in FDX mode, so why bother?

The hardware is there, but the meaning is not. The "jam signal" is not
a meaningful signal. It's just noise on the wire to trigger the
receiving-while-transmitting exception.

Because receiving-while-transmitting is not an exception in FD mode,
the FD recipient of a jam signal sees only a nasty-string-o-bits.
Cisco will (i think) log these as crc or framing errors. Certainly not
collisions.

And, in the case of a duplex mismatch, the jam signal sent by the HD
guy won't make any sense to the FD guy. It will be recorded as "bits
that didn't add up to a valid frame" rather than "collision jam
signal".

That depends on the hardware implementation. All of the switch PHYs I'm
familiar with recognize a collision jam signal even when configured for FDX
operation. I don't recall what the jamming signal looks like electrically,
but I'm pretty sure it couldn't be misinterpreted as normal (or even
corrupted) bits.

Couldn't it? It's just bits with no valid trailer.

You've really seen a port in FD mode logging collisions?

I can't make any sense of that.

Rich, is there more to the jam signal than just noise to trigger the
(now evolved) over-voltage exception?

/chris

.

Relevant Pages

  • Re: "Forcing" gigabit link operation
    ... Your Cisco switchport claims to be running full-duplex mode, ... switchport was operating in FD but collisions were ocurring on the Ethernet ... If your switch is operating in full-duplex mode, ...
    (comp.dcom.lans.ethernet)
  • Re: Checking for Modification to a Set of Files
    ... Where the operating environment doesn't provide a mechanism ... change timestamps, of course). ... with MD5 than it is with CRC-32, and if you have to meet a threat model ... file, then MD5 isn't sufficient, as it's too easy to produce collisions ...
    (comp.programming)