Confused (was Re: is this statement true ??)
Priscilla, everybody, I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel allocation techinque in a shared media access envoiroment. Here it comes the confusion, when you are saying that the Full-duplex does not support CSMA/CD because the transmit and receive are on different wires. This implies that in this case there is no shared media, how come if you have two clients competing to talk to the same server simultaneously!! Thanx On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > It's true for Ethernet because Ethernet's CSMA/CD media access control > method has strict timing requirements, which result in strict length > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > I wouldn't say it's true in general, however. > > Priscilla > > At 05:32 PM 12/25/00, Li Song wrote: > >"full-duplex can be used over longer distance than > >half-duplex" ?? > >what 's your opinion ?? > > > > > >_ > >FAQ, list archives, and subscription info: > >http://www.groupstudy.com/list/cisco.html > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > Priscilla Oppenheimer > http://www.priscilla.com > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Confused (was Re: is this statement true ??)
Good Question Jon. Full Duplex Ethernet cannot be performed except for on an Ethernet Switch (AKA big multiport bridge, or a simple bridge) or on a back to back connection between 2 machines. So, as you can see, there can NEVER be more than 2 stations on the same physical "topological" segment for full duplex, therefore it is not a shared media from a "Collision" since, but it is the same media from a "Broadcast" since. I'm sure Priscilla can put it in better words but that's the lowdown in mine:) Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John lay Sent: Tuesday, December 26, 2000 6:51 AM To: Priscilla Oppenheimer; [EMAIL PROTECTED] Subject: Confused (was Re: is this statement true ??) Priscilla, everybody, I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel allocation techinque in a shared media access envoiroment. Here it comes the confusion, when you are saying that the Full-duplex does not support CSMA/CD because the transmit and receive are on different wires. This implies that in this case there is no shared media, how come if you have two clients competing to talk to the same server simultaneously!! Thanx On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > It's true for Ethernet because Ethernet's CSMA/CD media access control > method has strict timing requirements, which result in strict length > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > I wouldn't say it's true in general, however. > > Priscilla > > At 05:32 PM 12/25/00, Li Song wrote: > >"full-duplex can be used over longer distance than > >half-duplex" ?? > >what 's your opinion ?? > > > > > >_ > >FAQ, list archives, and subscription info: > >http://www.groupstudy.com/list/cisco.html > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > Priscilla Oppenheimer > http://www.priscilla.com > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ _ 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]
Re: Confused (was Re: is this statement true ??)
This is correct. You don't use full duplex if you are competing for bandwidth, ie, plugged into a hub. But if you are plugged into a switch, there is only one bandwidth domain between the device and switch and with nothing competing for the bandwidth on that link so you can go full duplex. andy On Tue, 26 Dec 2000, John lay wrote: > Priscilla, everybody, > > I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel > allocation techinque in a shared media access envoiroment. > Here it comes the confusion, when you are saying that the Full-duplex does > not support CSMA/CD because the transmit and receive are on different wires. > This implies that in this case there is no shared media, how come if you > have two clients competing to talk to the same server simultaneously!! > > Thanx > > > On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > > > It's true for Ethernet because Ethernet's CSMA/CD media access control > > method has strict timing requirements, which result in strict length > > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > > > I wouldn't say it's true in general, however. > > > > Priscilla > > > > At 05:32 PM 12/25/00, Li Song wrote: > > >"full-duplex can be used over longer distance than > > >half-duplex" ?? > > >what 's your opinion ?? > > > > > > > > >_ > > >FAQ, list archives, and subscription info: > > >http://www.groupstudy.com/list/cisco.html > > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > > > > > Priscilla Oppenheimer > > http://www.priscilla.com > > > > _ > > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > ___ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ > > > _ > 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]
RE: Confused (was Re: is this statement true ??)
Remember - Full Duplex needs microsegmentation. -Original Message- From: Bowen, Shawn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 26, 2000 8:30 AM To: John lay; Priscilla Oppenheimer; [EMAIL PROTECTED] Subject: RE: Confused (was Re: is this statement true ??) Good Question Jon. Full Duplex Ethernet cannot be performed except for on an Ethernet Switch (AKA big multiport bridge, or a simple bridge) or on a back to back connection between 2 machines. So, as you can see, there can NEVER be more than 2 stations on the same physical "topological" segment for full duplex, therefore it is not a shared media from a "Collision" since, but it is the same media from a "Broadcast" since. I'm sure Priscilla can put it in better words but that's the lowdown in mine:) Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John lay Sent: Tuesday, December 26, 2000 6:51 AM To: Priscilla Oppenheimer; [EMAIL PROTECTED] Subject: Confused (was Re: is this statement true ??) Priscilla, everybody, I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel allocation techinque in a shared media access envoiroment. Here it comes the confusion, when you are saying that the Full-duplex does not support CSMA/CD because the transmit and receive are on different wires. This implies that in this case there is no shared media, how come if you have two clients competing to talk to the same server simultaneously!! Thanx On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > It's true for Ethernet because Ethernet's CSMA/CD media access control > method has strict timing requirements, which result in strict length > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > I wouldn't say it's true in general, however. > > Priscilla > > At 05:32 PM 12/25/00, Li Song wrote: > >"full-duplex can be used over longer distance than > >half-duplex" ?? > >what 's your opinion ?? > > > > > >_ > >FAQ, list archives, and subscription info: > >http://www.groupstudy.com/list/cisco.html > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > Priscilla Oppenheimer > http://www.priscilla.com > > _ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ _ 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] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Confused (was Re: is this statement true ??)
I think what John is getting at is that there is still contention. In his example with two clients trying to reach one server, there's contention at the switch, and at the server possibly. There's no contention on the medium itself. There's only one device trying to send at any one time. The switch has its transmit pair and the server has its own transmit pair. If the switch has two frames to send to the server, the backup happens at the switch. Does that make sense? Priscilla At 08:33 AM 12/26/00, Andy Walden wrote: >This is correct. You don't use full duplex if you are competing for >bandwidth, ie, plugged into a hub. But if you are plugged into a switch, >there is only one bandwidth domain between the device and switch and >with nothing competing for the bandwidth on that link so you can go full >duplex. > >andy > >On Tue, 26 Dec 2000, John lay wrote: > > > Priscilla, everybody, > > > > I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel > > allocation techinque in a shared media access envoiroment. > > Here it comes the confusion, when you are saying that the Full-duplex does > > not support CSMA/CD because the transmit and receive are on different > wires. > > This implies that in this case there is no shared media, how come if you > > have two clients competing to talk to the same server simultaneously!! > > > > Thanx > > > > > > On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > > > > > It's true for Ethernet because Ethernet's CSMA/CD media access control > > > method has strict timing requirements, which result in strict length > > > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > > > > > I wouldn't say it's true in general, however. > > > > > > Priscilla > > > > > > At 05:32 PM 12/25/00, Li Song wrote: > > > >"full-duplex can be used over longer distance than > > > >half-duplex" ?? > > > >what 's your opinion ?? > > > > > > > > > > > >_ > > > >FAQ, list archives, and subscription info: > > > >http://www.groupstudy.com/list/cisco.html > > > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > > > > > > > > > > Priscilla Oppenheimer > > > http://www.priscilla.com > > > > > > _ > > > FAQ, list archives, and subscription info: > > http://www.groupstudy.com/list/cisco.html > > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > > > > > > > ___ > > Send a cool gift with your E-Card > > http://www.bluemountain.com/giftcenter/ > > > > > > _ > > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > Priscilla Oppenheimer http://www.priscilla.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Confused (was Re: is this statement true ??)
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. Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Tuesday, December 26, 2000 2:06 PM To: Andy Walden; John lay Cc: [EMAIL PROTECTED] Subject: Re: Confused (was Re: is this statement true ??) I think what John is getting at is that there is still contention. In his example with two clients trying to reach one server, there's contention at the switch, and at the server possibly. There's no contention on the medium itself. There's only one device trying to send at any one time. The switch has its transmit pair and the server has its own transmit pair. If the switch has two frames to send to the server, the backup happens at the switch. Does that make sense? Priscilla At 08:33 AM 12/26/00, Andy Walden wrote: >This is correct. You don't use full duplex if you are competing for >bandwidth, ie, plugged into a hub. But if you are plugged into a switch, >there is only one bandwidth domain between the device and switch and >with nothing competing for the bandwidth on that link so you can go full >duplex. > >andy > >On Tue, 26 Dec 2000, John lay wrote: > > > Priscilla, everybody, > > > > I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel > > allocation techinque in a shared media access envoiroment. > > Here it comes the confusion, when you are saying that the Full-duplex does > > not support CSMA/CD because the transmit and receive are on different > wires. > > This implies that in this case there is no shared media, how come if you > > have two clients competing to talk to the same server simultaneously!! > > > > Thanx > > > > > > On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > > > > > It's true for Ethernet because Ethernet's CSMA/CD media access control > > > method has strict timing requirements, which result in strict length > > > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > > > > > I wouldn't say it's true in general, however. > > > > > > Priscilla > > > > > > At 05:32 PM 12/25/00, Li Song wrote: > > > >"full-duplex can be used over longer distance than > > > >half-duplex" ?? > > > >what 's your opinion ?? > > > > > > > > > > > >_ > > > >FAQ, list archives, and subscription info: > > > >http://www.groupstudy.com/list/cisco.html > > > >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > > > > > > > > > > Priscilla Oppenheimer > > > http://www.priscilla.com > > > > > > _ > > > FAQ, list archives, and subscription info: > > http://www.groupstudy.com/list/cisco.html > > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > > > > > > > > ___ > > Send a cool gift with your E-Card > > http://www.bluemountain.com/giftcenter/ > > > > > > _ > > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > Priscilla Oppenheimer http://www.priscilla.com _ 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]
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. 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]
RE: Confused (was Re: is this statement true ??)
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. 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]
RE: Confused (was Re: is this statement true ??)
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. 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]
RE: Confused (was Re: is this statement true ??)
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. > 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
RE: Confused (was Re: is this statement true ??)
Yes guys, okay it makes sense. But this means if you have a half duplex connection between the host and the switch , the contention will be between the host from one side and on the other side is what ever data goining to the direction of the switch. sense ? On Tue, 26 Dec 2000 19:26:56 -0500, 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. > > Shawn > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Priscilla Oppenheimer > Sent: Tuesday, December 26, 2000 2:06 PM > To: Andy Walden; John lay > Cc: [EMAIL PROTECTED] > Subject: Re: Confused (was Re: is this statement true ??) > > I think what John is getting at is that there is still contention. In his > example with two clients trying to reach one server, there's contention at > the switch, and at the server possibly. There's no contention on the medium > itself. There's only one device trying to send at any one time. The switch > has its transmit pair and the server has its own transmit pair. If the > switch has two frames to send to the server, the backup happens at the > switch. Does that make sense? > > Priscilla > > At 08:33 AM 12/26/00, Andy Walden wrote: > > >This is correct. You don't use full duplex if you are competing for > >bandwidth, ie, plugged into a hub. But if you are plugged into a switch, > >there is only one bandwidth domain between the device and switch and > >with nothing competing for the bandwidth on that link so you can go full > >duplex. > > > >andy > > > >On Tue, 26 Dec 2000, John lay wrote: > > > > > Priscilla, everybody, > > > > > > I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel > > > allocation techinque in a shared media access envoiroment. > > > Here it comes the confusion, when you are saying that the Full-duplex > does > > > not support CSMA/CD because the transmit and receive are on different > > wires. > > > This implies that in this case there is no shared media, how come if > you > > > have two clients competing to talk to the same server > simultaneously!! > > > > > > Thanx > > > > > > > > > On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > > > > > > > It's true for Ethernet because Ethernet's CSMA/CD media access > control > > > > method has strict timing requirements, which result in strict length > > > > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > > > > > > > I wouldn't say it's true in general, however. > > > > > > > > Priscilla > > > > > > > > At 05:32 PM 12/25/00, Li Song wrote: > > > > >"full-duplex can be used over longer distance than > > > > >half-duplex" ?? > > > > >what 's your opinion ?? > > > > > > > > > > > > > > >_ > > > > >FAQ, list archives, and subscription info: > > > > >http://www.groupstudy.com/list/cisco.html > > > > >Report misconduct and Nondisclosure violations to > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > Priscilla Oppenheimer > > > > http://www.priscilla.com > > > > > > > > _ > > > > FAQ, list archives, and subscription info: > > > http://www.groupstudy.com/list/cisco.html > > > > Report misconduct and Nondisclosure violations to > [EMAIL PROTECTED] > > > > > > > > >
Re: Confused (was Re: is this statement true ??)
"Bowen, Shawn" wrote: > > 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. > And I also guess I wanted to point out that the Cisco documentation is > not "always" 100% accurate in the real world. I must respectfully disagree again. The "jam" signal is asserted after a collision detection and most commonly simply continues to transmit the data in the collided packet for another 64 bits. The flow control method of "assert carrier beyond the length of the packet" is entirely different -- it is sending the 802.3 preamble of 0x05 continuously without the trailing 8th byte 0xD5 (I'm pulling this from my somewhat foggy memory on the values, but the preamble is 7 bytes of "something" followed by a byte signalling the start-of-packet, so don't shoot me if my values aren't correct). As for Cisco documentation, and some others, they refer to this method of flow control as "back pressure". It has the advantage of not propagating a collision (as in the intentional collision method of flow control) as it will not interfere with any other hub/switch/NIC on the network other than causing a transmit deferral. But as I had said earlier, 10Mb NICs have logic to detect carrier (or preamble) being asserted longer than the MTU plus propagation delay and consider this to be "jabber". This was not carried forward to 100Mb or 1Gb NICs. But I will concur on your statement: > 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. I value real world experience much more than some CC** acronym after your signature. This is the stuff you need to know that no boot camp will teach you, and I value this "outside the mainstream" information. I don't read this list for the obvious topics, it's the fringe areas that you can learn about that makes it worth it. 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]
RE: Confused (was Re: is this statement true ??)
Yes, makes sense. This means if you have a host connected to a switch with half duplex configuration the contention on the media will be only between the host and the switch port (the data coming/going to the switch). sense ? Thanks On Tue, 26 Dec 2000 19:26:56 -0500, 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. > > Shawn > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Priscilla Oppenheimer > Sent: Tuesday, December 26, 2000 2:06 PM > To: Andy Walden; John lay > Cc: [EMAIL PROTECTED] > Subject: Re: Confused (was Re: is this statement true ??) > > I think what John is getting at is that there is still contention. In his > example with two clients trying to reach one server, there's contention at > the switch, and at the server possibly. There's no contention on the medium > itself. There's only one device trying to send at any one time. The switch > has its transmit pair and the server has its own transmit pair. If the > switch has two frames to send to the server, the backup happens at the > switch. Does that make sense? > > Priscilla > > At 08:33 AM 12/26/00, Andy Walden wrote: > > >This is correct. You don't use full duplex if you are competing for > >bandwidth, ie, plugged into a hub. But if you are plugged into a switch, > >there is only one bandwidth domain between the device and switch and > >with nothing competing for the bandwidth on that link so you can go full > >duplex. > > > >andy > > > >On Tue, 26 Dec 2000, John lay wrote: > > > > > Priscilla, everybody, > > > > > > I am confused. Ethernet and FastEthernet uses the CSMA/CD as a channel > > > allocation techinque in a shared media access envoiroment. > > > Here it comes the confusion, when you are saying that the Full-duplex > does > > > not support CSMA/CD because the transmit and receive are on different > > wires. > > > This implies that in this case there is no shared media, how come if > you > > > have two clients competing to talk to the same server > simultaneously!! > > > > > > Thanx > > > > > > > > > On Mon, 25 Dec 2000 16:36:11 -0800, Priscilla Oppenheimer wrote: > > > > > > > It's true for Ethernet because Ethernet's CSMA/CD media access > control > > > > method has strict timing requirements, which result in strict length > > > > restrictions. Half-duplex uses CSMA/CD. Full-duplex does not. > > > > > > > > I wouldn't say it's true in general, however. > > > > > > > > Priscilla > > > > > > > > At 05:32 PM 12/25/00, Li Song wrote: > > > > >"full-duplex can be used over longer distance than > > > > >half-duplex" ?? > > > > >what 's your opinion ?? > > > > > > > > > > > > > > >_ > > > > >FAQ, list archives, and subscription info: > > > > >http://www.groupstudy.com/list/cisco.html > > > > >Report misconduct and Nondisclosure violations to > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > Priscilla Oppenheimer > > > > http://www.priscilla.com > > > > > > > > _ > > > > FAQ, list archives, and subscription info: > > > http://www.groupstudy.com/list/cisco.html > > > > Report misconduct and Nondisclosure violations to > [EMAIL PROTECTED] > > > > > > > > > > >
Re: Confused (was Re: is this statement true ??)
OK, if we really want to get nitty-gritty: The jam signal is 32 bits. The preamble is 10101010 etc, or AA in HEX. The last byte is 10101011, or AB. You can actually see AAs sometimes on a Sniffer when there's a collision and the Sniffer captures someone else's preamble on the end of a frame. But all else you say is right on as far as I know. Priscilla At 12:04 AM 12/28/00, Jeff Kell wrote: >"Bowen, Shawn" wrote: > > > > 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. > > > And I also guess I wanted to point out that the Cisco documentation is > > not "always" 100% accurate in the real world. > >I must respectfully disagree again. The "jam" signal is asserted after >a collision detection and most commonly simply continues to transmit >the data in the collided packet for another 64 bits. The flow control >method of "assert carrier beyond the length of the packet" is entirely >different -- it is sending the 802.3 preamble of 0x05 continuously >without the trailing 8th byte 0xD5 (I'm pulling this from my somewhat >foggy memory on the values, but the preamble is 7 bytes of "something" >followed by a byte signalling the start-of-packet, so don't shoot me >if my values aren't correct). > >As for Cisco documentation, and some others, they refer to this method >of flow control as "back pressure". It has the advantage of not >propagating a collision (as in the intentional collision method of >flow control) as it will not interfere with any other hub/switch/NIC >on the network other than causing a transmit deferral. But as I had >said earlier, 10Mb NICs have logic to detect carrier (or preamble) >being asserted longer than the MTU plus propagation delay and consider >this to be "jabber". This was not carried forward to 100Mb or 1Gb NICs. > >But I will concur on your statement: > > > 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. > >I value real world experience much more than some CC** acronym after >your signature. This is the stuff you need to know that no boot camp >will teach you, and I value this "outside the mainstream" information. >I don't read this list for the obvious topics, it's the fringe areas >that you can learn about that makes it worth it. > >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] Priscilla Oppenheimer http://www.priscilla.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
