Kohli, Jaspreet wrote: > > Just confirming that when we say full duplex we are referring > to switched networks over 100Mb. 10 Mb networks cannot run on > full duplex. Please correct me if I am wrong.
Switched 10-Mbps Ethernet can use full duplex too. There are quite a few old interfaces out there that don't support it, but theoretically it is supported. Priscilla > > Jaspreet > > -----Original Message----- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 16 July 2002 5:25 a.m. > To: [EMAIL PROTECTED] > Subject: RE: Collision Detecting [7:48830] > > > Curious wrote: > > > > Open Question!!!! > > How do we detect the source of collision, i am experiencing > > alot of > > collision on my LAN, which consisit of 10 Base T HUBS and > > 10/100 Switches, i > > am seeing alot of collision, but i dont know where is a > Source, > > If some one > > knows how to detect the source of collsion will be great help > > for me > > !!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > Hello Curious, > > It takes two to tango. Seriously, a collision means two or more > stations > sent at the same time, so it's difficult to identify a single > source of the > collisions. The stations involved sense the carrier, see that > it is free, > and start transmitting. Their frames collide somewhere in the > middle. The > senders send their jam and then stop sending. They back off and > retransmit. > It can be very difficult to determine which stations were > involved in the > collision because the senders stop prematurely, usually before > they have > sent an entire source address. An Ethernet frame starts with > preamble, dest > address, source address, and then length or type. On most > networks, all the > collisions happen within the preamble and dest address. > > Note that collisions are normal on shared Ethernet. If you have > a lot of > collisions, then you should start dividing up your collision > domain with > switches. In fact, not only is that a good design approach, > it's really the > only way to troubleshoot also. You have to use a > divide-and-conquer approach > and divide up the network until you find the culprits. > > I see that someone suggested using a protocol analyzer. You > could capture > all the fragments (runts), which are frames that are too short, > usually due > to a collision. But these frames may not have a source address, > as > mentioned. And not only that, you may be just seeing the > victims of the > problem, not necessarily the perpetrators. > > To determine which stations are most likely to need a lot of > bandwidth (and > were possibly involved in lots of collisions), you could use a > protocol > analyzer to determine who are the biggest senders. Actually, > the stations > that are most involved in collisions are the ones that send the > most often, > which is not necessarily the biggest bandwidth hogs, but > usually it is. > > Because most networks these days are already micro-segmented > (with small > collision domains), the most likely cause of high collisions is > a duplex > mismatch. All the stations that are connected to hubs must be > set to half > duplex. Any station that is connected point-to-point to a > switch can be set > to full duplex as long as the switch port is also set to full > duplex. > > IEEE 802.3 is supposed to make all this work automatically. The > autonegotiation feature should make sure that you don't have > any mismatches. > Even if you connect to an old hub that predates > autonegotiation, the > workstation is supposed to recognize this. 10Base-T hubs send > pulses that > the workstation should recognize as coming from a half-duplex > hub, causing > the workstation to use half duplex. > > Unfortunately, autonegotiation fails a lot of the time. This > could result in > you having a workstation on a shared network that is set to > full duplex, > which would wreak havoc. It would send whenever it wanted, > rather than doing > carrier sense first. > > But that station will be very hard to find. How big is your > network? Can you > manually check devices? > > HTH, sorry it was so long-winded! ;-) > > ________________________ > > Priscilla Oppenheimer > http://www.priscilla.com > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=48862&t=48830 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
