Why network collision detected when connected to switch

[Mark FCH_1]

Hi,

I've got 2 questions regarding network collisions.

1) My HPUX 11 server 'lanadmin' command detects some collisions, deferred transmission etc. Does 'lanadmin' display network stats for my server's NIC only or stats for the entire subnet that my server belongs to? What I mean is would 2 servers in the same subnet show the same statistics for 'lanadmin' command?

2) If my server is connected to a switch (10 BaseT 1/2 duplex, CSMA/CD), why does it display collisions? I thought in a switch, there would not be any collisions as each port is its own collision domain.

Sorry, I left my knowledge in school after I passed my exams. Tks in adv.

[T G Manikandan]

At what speed is your NIC running.
There might be a mismatch in speed between the switch and the server.
Set the speed on both the switch port and the machine to be same.

revert

[Dirk Wiedemann]

Hello,

collisions could be happened if the bridge and the lancard had different settings for duplex mode. Be sure that both are configured as half duplex or both as full duplex.

regards
Dirk

[Dirk Wiedemann]

Hello again,

in addition to my message above:
If the collisions are not to much and don't increase it is possibel, that they occure before configuring switch and lancard to the same settings. You can check it by clearing the statistics registers in interactive mode of lanadmin and watching if new collisions occurs.

regards
Dirk

[Mark FCH_1]

The switch port is configured to be 100 BaseT, Half-Duplex auto-negotiate & my server NIC is configured to be 10 BaseT, Half-Duplex (force). When I connect the UTP cable to the switch, the port automatically drops to 10 BaseT, half-duplex. Is this diff. in settings causing all the collisions?

Tks again.

[U.SivaKumar_2]

Hi,
This is what happening in your case.
A non-standard but popular scheme called Back-pressure was used in half-duplex flow control. If a port is operating at half-duplex, the switch sends a collision which causes the transmitting device to wait.
So when a half-duplex device wasn't able to handle the amount of data it was receiving from an end station, it collided with it (faked a collision by sourcing JAM). Thus all devices on the shared LAN would have to back-off, and then try to re-transmit. The device could keep on colliding, so the other end stations will keep backing off.


regards,
U.SivaKumar

[U.SivaKumar_2 · Accepted solution]

Hi,
quote:
With a half-duplex Ethernet connection, only one end of a link can send data at a given moment. If both ends try to send data, an event known as a collision occurs. Think of a collision as a point in a conversation where two people try to talk at the same time. Both usually pause for a moment before attempting to speak. The same holds true with Ethernet. In the event of a collision, all devices on an Ethernet network pause for a randomly determined period of time (on the order of milliseconds) before attempting to send data again. With a bandwidth utilization of say 5% (5 Mbps on Fast Ethernet), you will rarely ever see collisions on a half-duplex switch connection. However, if the utilization is high, such as 90%, you'll start seeing them frequently. A collision obviously causes some latency in data transmission, so the fewer collisions you have, the better off you are.

With a full-duplex connection, collision detection is disabled on both ends, thus making it impossible to have collisions even at full utilization. This is possible because there is only one device sending or receiving on each end of this connection. Traffic is limited to 100 Mbps in each direction still, but both ends can transmit at full speed, resulting in the total possible throughput of 200 Mbps.

When one side either auto-detects or is manually set for half duplex, while the other end either auto-detects or is manually set for full duplex, the result is a duplex mismatch. This most commonly occurs when one or both ends are configured for auto-detection. With Ethernet devices, most are capable of trying to negotiate the correct speed (10/100/1000 Mbps) as well as the duplex. Although Ethernet interfaces do a pretty good job of negotiating the correct and highest possible speed (such as 100 Mbps versus 10 Mbps), the duplex auto-negotiation often detects incorrect or different duplex settings. This can happen with any copper-based Ethernet device, from an inexpensive PC server all the way to the most kick-butt Internet core router. Fiber-based Ethernet is not affected typically, as the auto-negotiation aspect is usually all or nothing. Here a mismatch results in no connectivity whatsoever.

regards,
U.SivaKumar

[Mark FCH_1]

Really appreciate your kind replies. I think I understand it now. Apparently collisions can occur even on a 1/2 duplex switch port. I always thought that collisions only occurs in hubs but not switches. Hence the confusion.

Like what we like to say in S'pore, get yourself a Tiger (it's a made-in-S'pore beer), you guys deserve it. Tks.

[rick jones]

just a brief addition to the excellent explanation about collsions.

when a collision happens, the hosts in the same collision domain backoff (is it all the hosts, or just the two involved in the collision? I've always thought it was just the two involved).

with switches, each switch port is a separate collision domain, so a collision involving one port of a switch will have no effect (at least not directly) on hosts connected to other ports.