RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
I agree with Larry. We support 6500 + devices and have had our far share of connectivity issues. Last year we had a few NICs that generated lots of errors when they were hard set to match the switch. We tried every combination of negotiation and the only setting the eliminated the errors was auto/auto on both the switch & PCs. Cheers, Mike Larry Letterman wrote: > > All of our cisco campus devices work just fine with auto/auto > and > Multiple hardware types with various nics don't have any > issues... > > If your nics are not auto/auto capable or it does not work > well, then as > Fred > Says, hard code it...However I use auto/auto in my data center > on campus > and > See no reason to hard code 2000 devices and maintain that many > different > settings.. > > > Larry Letterman > Cisco Systems > > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > Reimer, Fred > Sent: Wednesday, July 23, 2003 11:31 AM > To: [EMAIL PROTECTED] > Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] > > > They don't happen to be autonegotiation issues, do they? Cisco > used to > have a nice write-up on autonegotiation troubleshooting and best > practices that recommended hard-coding everything except for > transient > devices. Some crack-head at Cisco decided to update that > recently and > now I suppose their "official" stance is to use autonegotiation, > ostensibly because they follow the standard correctly, so as > long as > everyone else does it should work! I have not met a Cisco > engineer yet > that agrees with that though. > > Hard-code your speed and duplex, unless it is for ports in an > area like > a conference room where you will have transient devices. > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA > 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary > information > which may be legally privileged. It is intended only for the > named > recipient(s). If an addressing or transmission error has > misdirected the > email, please notify the author by replying to this message. If > you are > not the named recipient, you are not authorized to use, > disclose, > distribute, copy, print or rely on this email, and should > immediately > delete it from your computer. > > > -Original Message- > From: John Neiberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2003 12:58 PM > To: [EMAIL PROTECTED] > Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] > > All those who consider any version of this platform beware. As > far as I > can tell there are no reliable software versions for this > switch that do > not suffer from connectivity bugs. We thought 12.1(13)EA1b > solved our > problems so we started rolling out this version. Upon reloading > we have > a number of users complaining and we're not able to resolve the > connectivity issue. > > Granted, this particular problem is between the 2950 and an old > NIC but > I'm sure we're not the only company with a few older NICs in the > network. If you're considering replacing existing switches with > the 2950 > prepare yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch > that > works?? We're on 12.1(13)EA1b and we still have BASIC > connectivity > bugs??? This is ridiculous. Bugs in the more obscure portions > of the > code are to be expected, but shouldn't the connectivity bugs be > given a > little higher priority? When we buy a new switch it would be > nice if > *all* of our end users could actually connect to the network. > Maybe > we'll go back to using Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72926&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
In many cases they are autonegotiation issues, but those seem to be mostly resolved, especially if your end devices are using newer NICs with updated drivers. In the case of this morning we're dealing with devices that only run 10/half and the switch is hard-coded for 10/half. Quite a mess but it's not consistent and we're still trying to discover all of the commonalities. Out of six or seven locations that were upgraded last night, three reported problems this morning and all problems related to the same type of PC with the same type of NIC. However, none of the other locations that also have this same PC and NIC have problems. To make it more frustrating, the problems often don't show up immediately, but instead show up several days later. Assuming good code, I'm now an advocate of using auto everywhere unless you need to fix a specific problem. In that case, use 100/Half or 10/half. I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950. Just last year we added a bunch of newer Cisco switches to our network and it took quite a while to figure out that most of our new connectivity problems were due to this change in philosophy within Cisco switches. John >>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72922&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
We've experienced ports shutting down in an errdisable state usually preceded by a duplex mismatch entry in the logs. This has happened mostly with PCs on the 2950's but we've seen it on 6500's. Ken >>> "Nuurul Basar" 07/23/03 07:03PM >>> Hi, Is there any particular symptom for this?. I am going install lots of 2950 48 EA switch to a mix off old and new NIC. Thanks - Original Message - From: "John Neiberger" To: Sent: Thursday, July 24, 2003 12:58 AM Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72911&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
"I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72903&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
I've seen the issue on 3550 switches as well. My case was of a lesser degree though; the customer had a few machines with the problem (mainly laptops with older 3com pc cards). The problem was resolved with 10hal/10half hard coded on the port/machine pair. Some clients may display this behavior when one cable serves to pc's. This was deployed by some cable installers a few years ago. My case involved AMP jacks. Today we rarely find these type of installs... Luis Chavira Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72890&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
We've experienced ports shutting down in an errdisable state usually preceded by a duplex mismatch entry in the logs. This has happened mostly with PCs on the 2950's but we've seen it on 6500's. Ken >>> "Nuurul Basar" 07/23/03 07:03PM >>> Hi, Is there any particular symptom for this?. I am going install lots of 2950 48 EA switch to a mix off old and new NIC. Thanks - Original Message - From: "John Neiberger" To: Sent: Thursday, July 24, 2003 12:58 AM Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72878&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
Hi, Is there any particular symptom for this?. I am going install lots of 2950 48 EA switch to a mix off old and new NIC. Thanks - Original Message - From: "John Neiberger" To: Sent: Thursday, July 24, 2003 12:58 AM Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] > All those who consider any version of this platform beware. As far as I can > tell there are no reliable software versions for this switch that do not > suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems > so we started rolling out this version. Upon reloading we have a number of > users complaining and we're not able to resolve the connectivity issue. > > Granted, this particular problem is between the 2950 and an old NIC but I'm > sure we're not the only company with a few older NICs in the network. If > you're considering replacing existing switches with the 2950 prepare > yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch that works?? > We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is > ridiculous. Bugs in the more obscure portions of the code are to be > expected, but shouldn't the connectivity bugs be given a little higher > priority? When we buy a new switch it would be nice if *all* of our end > users could actually connect to the network. Maybe we'll go back to using > Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72871&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
We've had issues with desktop machines and new switches. Have a look at this document and see if it helps: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml I searched for NIC PROBLEMS. Ken >>> "John Neiberger" 07/23/03 11:40AM >>> In many cases they are autonegotiation issues, but those seem to be mostly resolved, especially if your end devices are using newer NICs with updated drivers. In the case of this morning we're dealing with devices that only run 10/half and the switch is hard-coded for 10/half. Quite a mess but it's not consistent and we're still trying to discover all of the commonalities. Out of six or seven locations that were upgraded last night, three reported problems this morning and all problems related to the same type of PC with the same type of NIC. However, none of the other locations that also have this same PC and NIC have problems. To make it more frustrating, the problems often don't show up immediately, but instead show up several days later. Assuming good code, I'm now an advocate of using auto everywhere unless you need to fix a specific problem. In that case, use 100/Half or 10/half. I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950. Just last year we added a bunch of newer Cisco switches to our network and it took quite a while to figure out that most of our new connectivity problems were due to this change in philosophy within Cisco switches. John >>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72868&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
only the leftward pointing one ( greater than ) - anything after such a symbol is deleted. becomes a problem when discussing prefix lists. ""Reimer, Fred"" wrote in message news:[EMAIL PROTECTED] > Man, someone remind me not to use the greater than and less than symbols on > this list! Apparently they are striped out as some type of evil HTML code > or something by the software... > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary information which > may be legally privileged. It is intended only for the named recipient(s). > If an addressing or transmission error has misdirected the email, please > notify the author by replying to this message. If you are not the named > recipient, you are not authorized to use, disclose, distribute, copy, print > or rely on this email, and should immediately delete it from your computer. > > > -Original Message- > From: Reimer, Fred [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2003 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] > > "I never recommend hard-coding 100/Full on newer switches like > the 2950 and 6500. It might work but you're just asking for problems. > With the majority of the NICs in our PCs, if you hardset both sides to > 100/full you will get a duplex mismatch when the PC NIC falls back to > half duplex when autonegotiation fails. This behavior is relatively new, > and was not present in the 2924XL, the forerunner of the 2950." > > I'd have to disagree with you there. If you hard-code a device it can't > "fail" autonegotiation. The two are diametrically opposed. It's any > oxymoron. Illogical to the nth degree. And this behavior is >notstay>> > "Reimer, Fred" 7/23/03 12:31:16 PM >>> > They don't happen to be autonegotiation issues, do they? Cisco used to > have > a nice write-up on autonegotiation troubleshooting and best practices > that > recommended hard-coding everything except for transient devices. Some > crack-head at Cisco decided to update that recently and now I suppose > their > "official" stance is to use autonegotiation, ostensibly because they > follow > the standard correctly, so as long as everyone else does it should > work! I > have not met a Cisco engineer yet that agrees with that though. > > Hard-code your speed and duplex, unless it is for ports in an area like > a > conference room where you will have transient devices. > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary information > which > may be legally privileged. It is intended only for the named > recipient(s). > If an addressing or transmission error has misdirected the email, > please > notify the author by replying to this message. If you are not the > named > recipient, you are not authorized to use, disclose, distribute, copy, > print > or rely on this email, and should immediately delete it from your > computer. > > > -Original Message- > From: John Neiberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2003 12:58 PM > To: [EMAIL PROTECTED] > Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] > > All those who consider any version of this platform beware. As far as I > can > tell there are no reliable software versions for this switch that do > not > suffer from connectivity bugs. We thought 12.1(13)EA1b solved our > problems > so we started rolling out this version. Upon reloading we have a number > of > users complaining and we're not able to resolve the connectivity > issue. > > Granted, this particular problem is between the 2950 and an old NIC but > I'm > sure we're not the only company with a few older NICs in the network. > If > you're considering replacing existing switches with the 2950 prepare > yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch that > works?? > We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This > is > ridiculous. Bugs in the more obscure portions of the code are to be > expected, but shouldn't the connectivity bugs be given a little higher > priority? When we buy a new switch it would be nice if *all* of our > end > users could actually connect to the network. Maybe we'll go back to > using > Nortel switches. ] > -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72861&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
I agree with Larry. We support 6500 + devices and have had our far share of connectivity issues. Last year we had a few NICs that generated lots of errors when they were hard set to match the switch. We tried every combination of negotiation and the only setting the eliminated the errors was auto/auto on both the switch & PCs. Cheers, Mike Larry Letterman wrote: > > All of our cisco campus devices work just fine with auto/auto > and > Multiple hardware types with various nics don't have any > issues... > > If your nics are not auto/auto capable or it does not work > well, then as > Fred > Says, hard code it...However I use auto/auto in my data center > on campus > and > See no reason to hard code 2000 devices and maintain that many > different > settings.. > > > Larry Letterman > Cisco Systems > > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > Reimer, Fred > Sent: Wednesday, July 23, 2003 11:31 AM > To: [EMAIL PROTECTED] > Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] > > > They don't happen to be autonegotiation issues, do they? Cisco > used to > have a nice write-up on autonegotiation troubleshooting and best > practices that recommended hard-coding everything except for > transient > devices. Some crack-head at Cisco decided to update that > recently and > now I suppose their "official" stance is to use autonegotiation, > ostensibly because they follow the standard correctly, so as > long as > everyone else does it should work! I have not met a Cisco > engineer yet > that agrees with that though. > > Hard-code your speed and duplex, unless it is for ports in an > area like > a conference room where you will have transient devices. > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA > 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary > information > which may be legally privileged. It is intended only for the > named > recipient(s). If an addressing or transmission error has > misdirected the > email, please notify the author by replying to this message. If > you are > not the named recipient, you are not authorized to use, > disclose, > distribute, copy, print or rely on this email, and should > immediately > delete it from your computer. > > > -Original Message- > From: John Neiberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2003 12:58 PM > To: [EMAIL PROTECTED] > Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] > > All those who consider any version of this platform beware. As > far as I > can tell there are no reliable software versions for this > switch that do > not suffer from connectivity bugs. We thought 12.1(13)EA1b > solved our > problems so we started rolling out this version. Upon reloading > we have > a number of users complaining and we're not able to resolve the > connectivity issue. > > Granted, this particular problem is between the 2950 and an old > NIC but > I'm sure we're not the only company with a few older NICs in the > network. If you're considering replacing existing switches with > the 2950 > prepare yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch > that > works?? We're on 12.1(13)EA1b and we still have BASIC > connectivity > bugs??? This is ridiculous. Bugs in the more obscure portions > of the > code are to be expected, but shouldn't the connectivity bugs be > given a > little higher priority? When we buy a new switch it would be > nice if > *all* of our end users could actually connect to the network. > Maybe > we'll go back to using Nortel switches. ] > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72853&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
Larry Letterman wrote: > > All of our cisco campus devices work just fine with auto/auto > and > Multiple hardware types with various nics don't have any > issues... > > If your nics are not auto/auto capable or it does not work > well, then as > Fred > Says, hard code it...However I use auto/auto in my data center > on campus > and > See no reason to hard code 2000 devices and maintain that many > different > settings.. > > > Larry Letterman > Cisco Systems > > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > Reimer, Fred > Sent: Wednesday, July 23, 2003 11:31 AM > To: [EMAIL PROTECTED] > Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] > > > They don't happen to be autonegotiation issues, do they? Cisco > used to > have a nice write-up on autonegotiation troubleshooting and best > practices that recommended hard-coding everything except for > transient > devices. Some crack-head at Cisco decided to update that > recently and > now I suppose their "official" stance is to use autonegotiation, > ostensibly because they follow the standard correctly, so as > long as > everyone else does it should work! I have not met a Cisco > engineer yet > that agrees with that though. > > Hard-code your speed and duplex, unless it is for ports in an > area like > a conference room where you will have transient devices. > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA > 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary > information > which may be legally privileged. It is intended only for the > named > recipient(s). If an addressing or transmission error has > misdirected the > email, please notify the author by replying to this message. If > you are > not the named recipient, you are not authorized to use, > disclose, > distribute, copy, print or rely on this email, and should > immediately > delete it from your computer. > > > -Original Message- > From: John Neiberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2003 12:58 PM > To: [EMAIL PROTECTED] > Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] > > All those who consider any version of this platform beware. As > far as I > can tell there are no reliable software versions for this > switch that do > not suffer from connectivity bugs. We thought 12.1(13)EA1b > solved our > problems so we started rolling out this version. Upon reloading > we have > a number of users complaining and we're not able to resolve the > connectivity issue. > > Granted, this particular problem is between the 2950 and an old > NIC but > I'm sure we're not the only company with a few older NICs in the > network. If you're considering replacing existing switches with > the 2950 > prepare yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch > that > works?? We're on 12.1(13)EA1b and we still have BASIC > connectivity > bugs??? This is ridiculous. Bugs in the more obscure portions > of the > code are to be expected, but shouldn't the connectivity bugs be > given a > little higher priority? When we buy a new switch it would be > nice if > *all* of our end users could actually connect to the network. > Maybe > we'll go back to using Nortel switches. ] > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72849&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
Yep, that will happen. Paul (the list owner) said that he thinks there is a bug in the anti-mime software but he hasn't had time to check into it yet. So, word to the wise: don't use greater-than or less-than signs in your emails for a while! It definitely mangles posts if you use those symbols. John >>> Reimer, Fred 7/23/03 3:15:06 PM >>> Man, someone remind me not to use the greater than and less than symbols on this list! Apparently they are striped out as some type of evil HTML code or something by the software... Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Reimer, Fred [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:53 PM To: [EMAIL PROTECTED] Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] "I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72857&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
Man, someone remind me not to use the greater than and less than symbols on this list! Apparently they are striped out as some type of evil HTML code or something by the software... Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Reimer, Fred [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:53 PM To: [EMAIL PROTECTED] Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] "I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72850&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
I understand all that, but like I said, to each his own. My recommendation would be to not use any NIC that does not properly set the speed and duplex. We don't sell them, to my knowledge, and will not support them. Others may not have the same flexibility. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 3:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Catalyst 2950: The Spawn of the Devil? [7:72821] Actually, Fred, the problem is that some NICs will check for an autonegotiating partner even if they are hard coded, while other NICs do not. Newer Cisco switches completely disable autonegotiation if you hardset the speed and duplex, while many NIC manufacturers decided it was a great idea to still check for an autonegotiating partner regardless of speed/duplex setting. These NICs *will* fall back to half duplex if they do not detect autonegotiation on the wire. I've seen the documentation that proves this and I've seen it demonstrated almost daily for months now. The problem arose when Cisco changed their switch behavior. The 2924XL used to behave the same way as most NICs do now. Even if you hard set the speed and duplex they would be friendly with other NICs that checked for autonegotiation. In other words, they still participated in autonegotiation but they only offered the speed and duplex they were configured for to the link partner. Newer Cisco switches do not do this. Nway (autonegotiation) is disabled completely if you hardset the speed and duplex. If you set the switch to 100/Full it will stay at 100/Full no matter what. If you subsequently attach certain NICs to that port and you hardset the NIC to 100/Full it will still check the link for an autonegotiating partner. When it doesn't detect one it makes the faulty assumption that full duplex is not possible and it falls back to half duplex. To make matters worse, most NICs don't report this. When you check their speed and duplex settings they'll still report 100/Full. Every 2950, 2948G, 2980G, and 6500 in our network behaves in the newer fashion, while probably 98% of the PC and server NICs in our network still check for the presence of Nway signalling. It took months of troubleshooting involving several people of different backgrounds in our department along with resources from Novell and Cisco to figure out what was going on, and the real answer actually came from responses I had on Usenet by people who really understood Nway and the fast ethernet standard. The only method for setting speed and duplex mentioned in the standard is the use of autonegotiation. The behavior of NICs when auto is not used is unspecified. There are basically two common behaviors among NICs when you disable autonegotiation and the real problems occur when you have a mix of NICs with different philosophies. John >>> "Reimer, Fred" 7/23/03 12:53:14 PM >>> "I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - C
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
Believe me, Chuck, I've harped on our LAN people about this forever and they finally have made great progress in that area. Today's problems arise from some P133s with 10baseT ISA cards in them. With previous versions of the 2950 IOS we'd hardset the ports to 10/half and then reboot the PC about five times (yes, I said five times!) and from that point on they'd have no problems. I have no explanation. As of the latest version of software, the connections to these NICs seem to be on even shakier ground but we seem to be getting them under control. The real solution is to upgrade the NICs in all of those machines but that's easier said than done consider the locations of these machines relative to ours. :-) John >>> Chuck Whose Road is Ever Shorter 7/23/03 1:35:37 PM >>> lazy boy. upgrade your NIC drivers. :-> NIC problems with Cisco switches have been issues for several years that I can think of. ;-> ""John Neiberger"" wrote in message news:[EMAIL PROTECTED] > All those who consider any version of this platform beware. As far as I can > tell there are no reliable software versions for this switch that do not > suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems > so we started rolling out this version. Upon reloading we have a number of > users complaining and we're not able to resolve the connectivity issue. > > Granted, this particular problem is between the 2950 and an old NIC but I'm > sure we're not the only company with a few older NICs in the network. If > you're considering replacing existing switches with the 2950 prepare > yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch that works?? > We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is > ridiculous. Bugs in the more obscure portions of the code are to be > expected, but shouldn't the connectivity bugs be given a little higher > priority? When we buy a new switch it would be nice if *all* of our end > users could actually connect to the network. Maybe we'll go back to using > Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72843&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
In many cases they are autonegotiation issues, but those seem to be mostly resolved, especially if your end devices are using newer NICs with updated drivers. In the case of this morning we're dealing with devices that only run 10/half and the switch is hard-coded for 10/half. Quite a mess but it's not consistent and we're still trying to discover all of the commonalities. Out of six or seven locations that were upgraded last night, three reported problems this morning and all problems related to the same type of PC with the same type of NIC. However, none of the other locations that also have this same PC and NIC have problems. To make it more frustrating, the problems often don't show up immediately, but instead show up several days later. Assuming good code, I'm now an advocate of using auto everywhere unless you need to fix a specific problem. In that case, use 100/Half or 10/half. I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950. Just last year we added a bunch of newer Cisco switches to our network and it took quite a while to figure out that most of our new connectivity problems were due to this change in philosophy within Cisco switches. John >>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72834&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
"I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72835&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
Actually, Fred, the problem is that some NICs will check for an autonegotiating partner even if they are hard coded, while other NICs do not. Newer Cisco switches completely disable autonegotiation if you hardset the speed and duplex, while many NIC manufacturers decided it was a great idea to still check for an autonegotiating partner regardless of speed/duplex setting. These NICs *will* fall back to half duplex if they do not detect autonegotiation on the wire. I've seen the documentation that proves this and I've seen it demonstrated almost daily for months now. The problem arose when Cisco changed their switch behavior. The 2924XL used to behave the same way as most NICs do now. Even if you hard set the speed and duplex they would be friendly with other NICs that checked for autonegotiation. In other words, they still participated in autonegotiation but they only offered the speed and duplex they were configured for to the link partner. Newer Cisco switches do not do this. Nway (autonegotiation) is disabled completely if you hardset the speed and duplex. If you set the switch to 100/Full it will stay at 100/Full no matter what. If you subsequently attach certain NICs to that port and you hardset the NIC to 100/Full it will still check the link for an autonegotiating partner. When it doesn't detect one it makes the faulty assumption that full duplex is not possible and it falls back to half duplex. To make matters worse, most NICs don't report this. When you check their speed and duplex settings they'll still report 100/Full. Every 2950, 2948G, 2980G, and 6500 in our network behaves in the newer fashion, while probably 98% of the PC and server NICs in our network still check for the presence of Nway signalling. It took months of troubleshooting involving several people of different backgrounds in our department along with resources from Novell and Cisco to figure out what was going on, and the real answer actually came from responses I had on Usenet by people who really understood Nway and the fast ethernet standard. The only method for setting speed and duplex mentioned in the standard is the use of autonegotiation. The behavior of NICs when auto is not used is unspecified. There are basically two common behaviors among NICs when you disable autonegotiation and the real problems occur when you have a mix of NICs with different philosophies. John >>> "Reimer, Fred" 7/23/03 12:53:14 PM >>> "I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message----- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users co
Re: Catalyst 2950: The Spawn of the Devil? [7:72821]
lazy boy. upgrade your NIC drivers. :-> NIC problems with Cisco switches have been issues for several years that I can think of. ;-> ""John Neiberger"" wrote in message news:[EMAIL PROTECTED] > All those who consider any version of this platform beware. As far as I can > tell there are no reliable software versions for this switch that do not > suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems > so we started rolling out this version. Upon reloading we have a number of > users complaining and we're not able to resolve the connectivity issue. > > Granted, this particular problem is between the 2950 and an old NIC but I'm > sure we're not the only company with a few older NICs in the network. If > you're considering replacing existing switches with the 2950 prepare > yourself for deluge of conenctivity problems. > > You have been warned! > > [Side note to Cisco: How hard is it to build an access switch that works?? > We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is > ridiculous. Bugs in the more obscure portions of the code are to be > expected, but shouldn't the connectivity bugs be given a little higher > priority? When we buy a new switch it would be nice if *all* of our end > users could actually connect to the network. Maybe we'll go back to using > Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72839&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Catalyst 2950: The Spawn of the Devil? [7:72821]
They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72832&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Catalyst 2950: The Spawn of the Devil? [7:72821]
All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72821&t=72821 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
