Hi,
The most common reasons I have found for "late collisions" on a half duplex service
lately has been the remote end is configured for full duplex. The full duplex sends
well after the half duplex is sending.
The most common reason for collisions on a full duplex is the other end is running
half duplex.
The condition jumps all over the place when running Autonegotiate. Some services run
fine on auto other do not. Some will only run successfully on auto. So you must
discover which does what by changing the setup on a suspect service, clearing the
counters, testing and rechecking the counters.
Be aware also that some servers appear to be running full duplex but are not. Others
such as Sun boxes can (must) be forced and this must be saved or else the will revert
back.
There is a lot to this stuff.
Teunis
Hobart, Tasmania
Australia
On Wednesday, December 27, 2000 at 01:23:35 AM, Bowen. Shawn wrote:
> I might also add I'm a southern fella myself. But I must argue that you
> "can" see collisions and late collisions on a full duplex link. Before I
> get thrashed, I understand FULLY that full duplex is TX to RX so it "should"
> be impossible but I was just answering for a fellow earlier about this. On
> 10MB links the Collision mechanism and it's corresponding JAM signal are
> used as rudimentary flow control mechanisms, and can be seen on FD switches.
> Another thing is you CAN see them from is crosstalk, cable attenuation
> issues, Floresant lights, (and sun spots j/k), power cables trashing your
> signal, and many other weird ones. Telnet to a production switch with a lot
> of traffic going through it and take a peak sometime, then clear the
> counters and let it roll on.
>
> And heck who knows, I'm wrong on occasion, if I am now I just need to lay
> off the crack:) j/k
>
> Shawn
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
> Kell
> Sent: Wednesday, December 27, 2000 12:16 AM
> To: Bowen, Shawn
> Cc: Priscilla Oppenheimer; Andy Walden; John lay; [EMAIL PROTECTED]
> Subject: Re: Confused (was Re: is this statement true ??)
>
> "Bowen, Shawn" wrote:
> >
> > Yup, makes sense. I can only speak for 3Com on this one, but I believe
> > Cisco implements similar features. On a 3Com Corebuilder (as well as
> their
> > Workgroup Switches) they use fake collisions as a flow control mechanism.
> > In other words if there was contention at the server or switch and they
> > couldn't handle the load then a collision (a JAM) will be sent. Now, that
> > said after we all just agreed that collisions can not happen on a full
> > duplex Ethernet segment:) If you notice in Cisco texts that Collision
> > Detection is disabled on full duplex links, this is not true. Collision
> > detection is still there, at least on a 5000 and can be simulated by
> loading
> > up a server at 10MB FD with a few 100MB FD clients on the other end of the
> > Cat, you will see this in action. 3Com does the same thing, I thought
> this
> > was kinda interesting.
>
> If collisions are reported on the Cisco 5000 then forget my following
> diatribe as I don't have time to simulate it (and no testbed 5000, it
> would be the production switch).
>
> You stated (let me repeat it for emphasis)...
>
> > Collision detection is still there, at least on a 5000 and can be
> > simulated by loading up a server at 10MB FD with a few 100MB FD
> ^^^^^^^
> > clients on the other end of the Cat, you will see this in action.
>
> Older switches implement flow control in one of two ways:
> * Simulated collisions (not terribly efficient), or
> * Extended carrier to indicate busy (assert carrier beyond the length
> of the packet).
>
> With 100Mbps we have varying implementations of the 802.<something>
> method of the "pause" indicator in the header, and/or the "throttle"
> mechanism (in Cisco terminology). But your example specifically
> indicates 10Mb, which has another variable.
>
> In 10Mb ethernet, many NICs are setup to detect "jabber" -- asserting
> carrier longer than the max packet length. If this is detected, the
> transmit circuit is turned off (ref Siefert, _Gigabit Ethernet_).
>
> All of the flow controls, as well as the "jabber" detection, can
> result in a variety of line errors. Only in the "throttle" case does
> a Cisco switch continue without logging errors other than throttle
> packet counts. Throttling or pausing is undefined for 10Mb which may
> be the corner case you are presenting, depending upon the intelligence
> of the NIC in the server.
>
> In a normal case, I would expect discards if you were throwing many
> 100Mb clients at a 10Mb server connection, after all flow control and
> switch store-and-forward buffers had been exhausted. You can overload
> some of the older Catalyst switches (2926 for example) which has 24
> ports at 100Mb and 2 uplinks at 100Mb but only 1.2Gb backplane. If we
> ignore the potential overloading of the uplink(s), the switch cannot
> handle the potential load. The newer 2924XL/3524XLs are more in line
> with a 3Gbps backplane and could handle a full (distributed) load, but
> still suffer from uplink congestion which is dependent on the buffer
> space. This is less of an issue with a 1000xX uplink but you can
> still, in theory, overload the bandwidth of the switch. But this is
> true of any vendor's switch, if you oversubscribe the uplink, you can
> overload the switch, regardless of flow control, buffer size, etc.
>
> Bottom line, in southern terminology, there ain't no collisions on a
> full-duplex link :-)
>
> Jeff Kell <[EMAIL PROTECTED]>
> Systems/Network Administrator
> University of Tennessee at Chattanooga
>
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> _________________________________
> FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
--
www.tasmail.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
