"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]
