I believe we are saying mostly the same thing. Your "* Extended carrier to
indicate busy (assert carrier beyond the length of the packet)." Is an
Ethernet JAM signal. That's the same thing I was saying, though I was
putting it in more layman's terms, it's also what is immediately transmitted
onto the segment after a collision is detected to start the back off
routine. Cat's will see collisions in this configuration. I wasn't trying
to start a huge issue over this, merely pointing out to someone something
that I found interesting.
The only reason I took it to any depth was the fact that other than duplex
mismatches a lot of people getting into this field (reading these posts)
haven't ever been exposed to such nuances. And I also guess I wanted to
point out that the Cisco documentation is not "always" 100% accurate in the
real world.
Shawn
-----Original Message-----
From: Jeff Kell [mailto:[EMAIL PROTECTED]]
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]
