RE: Weird networking issue.
In the real world, auto-negotiation on fiber vs. auto-negotiation on copper have been two different animals. Most of the compatibility issues result from 10/100 auto-negotiation on copper as this was the first major deployment of the technique in Ethernet devices. Most devices engineered recently should auto-negotiate properly. In the early to mid 90's this was only true within the product line of a single vendor. Many of the products Cisco sells were engineered by different companies and often have problems auto-negotiating to other Cisco gear made by other companies. Also remember that many of the products that Cisco still sells have roots back 5 or more years. There is a good chance that any 3600 copper interface could have the same issues that its cousins did in 1997. The question of hard-setting speed/duplex on these types of interfaces is about as murky an issue as spanning-tree. You solve some problems and create others. I suppose the primary goal is to eliminate support calls and outages within your own environment. In my experience, connections which as static (servers, routers, etc...) should be hard coded on both sides as incorrect negotiations can and do occur. It is also frustrating to discover that your primary file server has been running at half duplex for a week. It may also be interesting to know that IEEE 802.3-2002 says that auto-negotiation is optional (in section 28.1.2.) It may also be interesting to know that if a device does support auto negotiation it must allow manually overriding of the function (IE.. an unconfigurable device is not allowed to auto-negotiate.) -Original Message- From: Mikael Abrahamsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 2:39 AM To: [EMAIL PROTECTED] Subject: RE: Weird networking issue. On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of link loss return, ie if you lose fiber link one way the link goes down at both ends. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Weird networking issue.
Hi there, no that is not normal. How long is the cat5 between the two? Also, with a hub you should normally see collisions but not crc errors. On Tue, 7 Jan 2003, Drew Weaver wrote: Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver
RE: Weird networking issue.
Check your duplex settigs you may also want to test with another cable. Thanks, Mario Puras SoluNet Technical Support Mailto: [EMAIL PROTECTED] Direct: (321) 309-1410 888.449.5766 (USA) / 888.SOLUNET (Canada) -Original Message- From: Drew Weaver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:19 PM To: '[EMAIL PROTECTED]' Subject: Weird networking issue. Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver
RE: Weird networking issue.
Title: RE: Weird networking issue. By nature, a hub is half-duplex - it's a repeater. Besides, misconfigured duplex will not cause CRC errors. C. -Original Message- From: David G. Andersen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: '[EMAIL PROTECTED]' Subject: Re: Weird networking issue. Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. I'd wager you've got half duplex set on one side, and full on the other... -Dave On Tue, Jan 07, 2003 at 02:19:10PM -0500, Drew Weaver mooed: Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
RE: Weird networking issue.
Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... http://www.eng.auburn.edu/~rayh/solaris/solaris2-faq.html#q4.13 -alex On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Heh. Tell that to my Catalyst 3548's and the E250's at the other end. ;) Lab testing showed serious throughput issues though (expected) in duplex-mismatched links, and large increases in runt and mutli-collision counters. CRC errors and FCS errors also rose in proportion to relative link saturation in a more simplistic 6500 -7509- 3548 test environment. Besides, misconfigured duplex will not cause CRC errors. C. -Original Message- From: David G. Andersen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: '[EMAIL PROTECTED]' Subject: Re: Weird networking issue. Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. I'd wager you've got half duplex set on one side, and full on the other... -Dave On Tue, Jan 07, 2003 at 02:19:10PM -0500, Drew Weaver mooed: Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
Re: Weird networking issue.
David G. Andersen wrote: Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Peter E. Fry
RE: Weird networking issue.
On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... That is just not true. I've had several Sun boxes with hme interfaces properly autoneg into 100/full with misc equipment, including 3548:s, and working properly. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
On Tue, 7 Jan 2003, Charles Youse wrote: Besides, misconfigured duplex will not cause CRC errors. Yes it will. It will cause CRC errors/RX underflows/RX frags/RX align on one end and late collissions on the other end depending on which one is running half duplex and which one is running full duplex. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Weird networking issue.
### On Tue, 7 Jan 2003 22:32:15 +0100 (CET), Mikael Abrahamsson ### [EMAIL PROTECTED] casually decided to expound upon '[EMAIL PROTECTED]' ### [EMAIL PROTECTED] the following thoughts about RE: Weird networking ### issue.: MA On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: MA MA Sun's hme cards won't go full duplex even though they advertise it to MA remote switch, causing immense headaches to anyone with Sun gear... MA MA That is just not true. I've had several Sun boxes with hme interfaces MA properly autoneg into 100/full with misc equipment, including 3548:s, and MA working properly. Ditto. I'm currently sitting at my workstation (Sun Ultra2) and its hme0 autonegotiates fine with my Cisco 3524XL each and every time. I don't even have to pin any of the interfaces to 100/full. Admittedly I have had problems in the past, namely a bunch of E4500s to some 5000-series switches. Since they were in remote datacenters, I did pin the interfaces on both ends. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Weird networking issue.
On Tue, 7 Jan 2003, Jake Khuon wrote: problems in the past, namely a bunch of E4500s to some 5000-series switches. Since they were in remote datacenters, I did pin the interfaces on both ends. I've seen problems with 3548:s and Sun le-interfaces though, sometimes the link would only see packets going one way on the link, also the behaviour was different on the lower and upper row of ports on the 3548. I have never seen any of these problems with other brands of switches. We solved it by putting a dumb 10megabit hub between the Sun le-interface and the cisco switch. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
At 10:32 PM 1/7/2003 +0100, Mikael Abrahamsson wrote: On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... That is just not true. I've had several Sun boxes with hme interfaces properly autoneg into 100/full with misc equipment, including 3548:s, and working properly. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] The behavior I've seen in the past is Sun gear negotiating properly when plugged into Cisco gear that is already running. If you power cycle the switch with the servers already attached the port will not negotiate correctly... usually to half duplex. Also I've seen duplex problems in the past week that caused, runts, giants, collisions, CRCs, errors of all sorts, kernel module reloads, vlan tagging failure, and depletion of the ozone layer. Or maybe is was reality tv that caused that ozone thing... Ramin
RE: Weird networking issue.
I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on your 3660, look at the speed and duplex settings for each device connecting to the etherstack hub. If one of those is miss-configured or possibly has a failing NIC, bad packets will be transmitted out all ports on the hub and will show up in the show int f0/0 output on your router. Mike Braun -Original Message- From: Peter E. Fry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 1:18 PM To: [EMAIL PROTECTED] Subject: Re: Weird networking issue. David G. Andersen wrote: Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Peter E. Fry MMS firstam.com made the following annotations on 01/07/03 14:22:30 -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. ==
RE: Weird networking issue.
On Tue, 7 Jan 2003, Braun, Mike wrote: I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on I don't agree. I have seen more problems generated by incompetence in trying to fix duplex/speed, than I have seen problems generated by autoneg not working properly. I am always amazed by the fact that very few people out there know that you have to lock duplex at BOTH ENDS of any given link for it to work properly. Generally, in a LAN environment with good quality switches and good network cards, autoneg works just fine. Yes, with 10/100 meg fiber/converters converters you should definately lock duplex, but in most other cases I recommend to leave the duplex setting to auto. Yes, cisco routers are notoriously bad at doing autoneg, but I blame that on cisco and not on autoneg. The el cheapo $50 desktop switches seem to hack autoneg just fine. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
Even Cisco states in some of their documentation that it is best to pin the interfaces to match both ends. I have had many a strange issue with auto negotiation depending on which side was up first. Additionally, TAC usually says to never trust auto negotiation. Regards, Jeff -Original Message- From: Braun, Mike [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: RE: Weird networking issue. I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the -Original Message- From: Peter E. Fry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 1:18 PM To: [EMAIL PROTECTED] Subject: Re: Weird networking issue. David G. Andersen wrote: Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. [...] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002
Re: Weird networking issue.
Peter E. Fry wrote: [...] the only [...] Yeah, *that* is a nutty statement. I could re-phrase, but I think most here get the intent. Peter E. Fry
RE: Weird networking issue.
I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on I don't agree. I have seen more problems generated by incompetence in trying to fix duplex/speed, than I have seen problems generated by autoneg not working properly. I am always amazed by the fact that very few people out there know that you have to lock duplex at BOTH ENDS of any given link for it to work properly. Generally, in a LAN environment with good quality switches and good network cards, autoneg works just fine. Yes, with 10/100 meg fiber/converters converters you should definately lock duplex, but in most other cases I recommend to leave the duplex setting to auto. I agree that with quality switches and network cards (ones supported by the manufacturer of the switch), you should be OK using autonegotiate in a desktop environment, but not in a sever environment or when interconnecting networking equipment. I've seen servers that initially autonegotiate fine, only to renegotiate later to a different speed or duplex setting; and in a production environment, that ends up costing money. The problems between Cisco and SUN have already been addressed in this thread. I have also seem problems between Cisco and Bay equipment. The bottom line is that if you need to take the guess work out of a connection, then lock up both ends. Yes, cisco routers are notoriously bad at doing autoneg, but I blame that on cisco and not on autoneg. The el cheapo $50 desktop switches seem to hack autoneg just fine. I think that this stems from the folks at Cisco believing that they can dictate the standard for the IEEE 802.3u autonegotiation protocol (aka, their faith that isl will become the trunking standard of the future). MMS firstam.com made the following annotations on 01/07/03 15:33:08 -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. ==
RE: Weird networking issue.
At 05:36 PM 1/7/2003, Mikael Abrahamsson wrote: On Tue, 7 Jan 2003, Braun, Mike wrote: I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on I don't agree. I have seen more problems generated by incompetence in trying to fix duplex/speed, than I have seen problems generated by autoneg not working properly. I am always amazed by the fact that very few people out there know that you have to lock duplex at BOTH ENDS of any given link for it to work properly. Generally, in a LAN environment with good quality switches and good network cards, autoneg works just fine. Yes, with 10/100 meg fiber/converters converters you should definately lock duplex, but in most other cases I recommend to leave the duplex setting to auto. Yes, cisco routers are notoriously bad at doing autoneg, but I blame that on cisco and not on autoneg. The el cheapo $50 desktop switches seem to hack autoneg just fine. Of all the gear I've worked with, from a wide variety of vendors, Cisco is the clear leader in gear that is incapable of successfully doing autonegotiation. I do hope they've improved this in newer products. The all time low point for them has to have been the 2924 switch. Putting a crossover cable between two 2924's yielded invariably BAD results. Now I can forgive engineers for not testing against every brand of router or host out there, but at LEAST test against another copy of the same box you're building. Not even something to blame on a QA engineer... this should have been tested before the box left the engineering benches. Connections to desktop computers and even servers are often better left set for autonegotiation. As people repatch connections to switches, it's easy to forget to reconfigure the switch. All that said, it's been my experience that when Cisco routers are involved, you really do have to force the interface settings or tempt fate.
RE: Weird networking issue.
I think we all agree that autonegotiation is evil, and should be avoided whenever possible. When you are looking for the root cause of the errors on I don't agree. I have seen more problems generated by incompetence in trying to fix duplex/speed, than I have seen problems generated by autoneg not working properly. I am always amazed by the fact that very few people out there know that you have to lock duplex at BOTH ENDS of any given link for it to work properly. So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) Generally, in a LAN environment with good quality switches and good network cards, autoneg works just fine. Yes, with 10/100 meg fiber/converters converters you should definately lock duplex, but in most other cases I recommend to leave the duplex setting to auto. Heh. I dont want to look at examples or find out what your experience is but in mine across a wide range of vendors its prone to problems. Yes, cisco routers are notoriously bad at doing autoneg, but I blame that on cisco and not on autoneg. The el cheapo $50 desktop switches seem to hack autoneg just fine. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. .. well thats my opinion on the matter anyhow :) Steve
Re: Weird networking issue.
At 03:17 PM 07-01-03 -0600, Peter E. Fry wrote: David G. Andersen wrote: Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Everything Cisco has to say on the subject: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml -Hank [Thanks Yaron :-)] Peter E. Fry
RE: Weird networking issue.
On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of link loss return, ie if you lose fiber link one way the link goes down at both ends. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Weird networking issue.
Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. I'd wager you've got half duplex set on one side, and full on the other... -Dave On Tue, Jan 07, 2003 at 02:19:10PM -0500, Drew Weaver mooed: Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
