Hp-Procurve switches diagnostic

[Jean Samarani]

Hi Community,

I am uploading the "show tech all" output of two switches. I would like to know if there is anything significant other than the duplex mismatch found in the logs files. Moreover, how can know if this problem is from the switches or from the server side?

BR/ Jean

[Matti_Kurkela]

I'm not a switch wizard, but to me, the only serious problems seem to be the duplex mismatches in ports 30 and 32. A high number of late collisions is a textbook case of duplex mismatch. Your switch is even smart enough to point it out for you.

> how can know if this problem is from the switches or from the server side?

Find out how the server's NIC is configured. Is it set to autonegotiate, or to forced 100-Full?

If the server is set to autonegotiate, you've find a server whose NIC cannot reliably autonegotiate: document this fact, set both sides of the connection to 100-Full and you're done.

If the server is set to 100-Full, this is most likely a human mistake, or a communication problem between the server admin and the switch admin.

When one end of the 100 Mbps Ethernet connection is set to autonegotiate and it doesn't get the autonegotiation response from the other end, it selects Half-Duplex to be maximally compatible with old hardware, and because that's what the standard says it must do. The speed is detected by monitoring the frequency of link pulses, so it can be detected correctly even without the autonegotiation response.

The rule of thumb is: when you are setting the speed/duplex mode of a 100 Mbps connection, _always check the mode of the other end too_.

With gigabit, you cannot really disable autonegotiation, because gigabit link _always_ needs to autonegotiate some parameters (it's a mandatory part of the gigabit interface specification). However, you can limit the options offered to the other side by the autonegotiation (e.g. "only 1000-Full available, do you want it or not?")

MK