Yes, it's in IEEE 802.3. It's in Clause 28 of the IEEE 802.3 2000 Edition. It might have been in earlier versions too.
Priscilla At 02:31 PM 12/31/01, Steven A. Ridder wrote: >Is there any standardization for autonegotiation like 802.x or something. I >have never heard of anything like it, and maybe that's half the problem? > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Auto-negotiation is infamous for not working as advertised! ;-) It's not > > just Cisco equipment. > > > > There is definitely a problem when introducing older 10BaseT equipment >into > > the equation, which it sounds like Ole did. Perhaps one of the more > > hardware, physical-layer type engineers remembers more of the details than > > I do, but from what I understand the 100-Mbps fast link pulses used for > > auto-negotiation produce enough signal in the frequency band of the >10-Mbps > > link pulses such that the 10-Mbps chip thinks it sees a signal and doesn't > > re-negotiate or drop or establish link integrity as it should. > > > > It's definitely strange that STP noticed a problem when other applications > > didn't. I'll have to ponder that one...... > > > > Priscilla > > > > > > At 10:26 AM 12/31/01, [EMAIL PROTECTED] wrote: > > >It's been more than once when I've encountered autonegotiation/autosense > > >issues between a Cisco router and Cisco switch. I've even seen problems > > >when both interfaces were 10/100 and both hard-coded to 100/full and the > > >link wouldn't come up. This may a chink in the Cisco armor as I rarely > > >encounter issues with autonegotiation/autosense with other equipment but > > >when I install a new Cisco network, one thing I ALWAYS have to do is go > > >through the 10/100 ports of every switch and look for duplex (and >sometimes > > >speed) mismatches. Crazy... > > > > > >Rik > > > > > >-----Original Message----- > > >From: Kane, Christopher A. [mailto:[EMAIL PROTECTED]] > > >Sent: Saturday, December 29, 2001 11:02 PM > > >To: [EMAIL PROTECTED] > > >Subject: RE: Autosense this ... (add to your knowledgebase) [7:30446] > > > > > > > > >It's unfortunate that sometimes when things break, they don't perform in > > >expected ways. Rather it truly was an Autosense problem or not, who >knows. > > >But it brings up a chance to talk about Autosense. I've had it bite me >more > > >than once. I've had problems with Autosense that didn't show up until >months > > >after installation. It doesn't matter if its Cisco to Cisco or Cisco to > > >another vendor, I've had to lock down ports at certain speeds and modes >to > > >solve problems on several occasions. Just to pass along some experience, >you > > >may always be better off hard setting your options. Nice persistence Mr. > > >Jensen, it's cool to stick with something until you can make it work. > > > > > >Chris > > > > > >-----Original Message----- > > >From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] > > >Sent: Saturday, December 29, 2001 6:14 PM > > >To: [EMAIL PROTECTED] > > >Subject: Re: Autosense this ... (add to your knowledgebase) [7:30446] > > > > > > > > >An interesting read, particularly since I am reviewing Kennedy clark's >cisco > > >Lan Switching book prior to reviewing Cat5K and Cat 3920 configuration. > > > > > >I am somewhat surprised at both the phenomenon and the concludion. >Spanning > > >tree blocks for particular reasons. > > > > > >when you concluded that your configurations were identical at all >offices, > > >does that mean that your port negotiations were set to auto everywhere >else? > > >both on the routers and on the local switches? if so, I would expect to >see > > >similar problems elsewhere. > > > > > >is it possible that there was a duplicate mac someplace in another part >of > > >the bridged network, one that was being picked up by STP and interpreted >as > > >a loop? You mention changing macs of interfaces as part of your > > >experimentation. Are you certain that this process was not part of the > > >solution? > > > > > >To be frank, I'm hard pressed to come up with a reason why the FE port on > > >the router would go into blocking. I can see that hapening on the serial > > >port for reasons that have been discussed on this group in the past. I >can't > > >come up with a rationale as to why hard setting of speed and duplex would > > >make a difference. I suppose one MIGHT conclude that if the port is in >full > > >duplex, the STP process MIGHT see a loop occuring over the two different > > >wire pairs. that's about the only wild rationale I can come up with. And > > >that one is really stretching the point / bug / whatever. > > > > > >In any case, thanks for the good read. > > > > > >Chuck > > > > > > > > >""Ole Drews Jensen"" wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > After a fun evening last night, I have decided not to trust the > > >autosensing > > > > on ethernet interfaces anymore. > > > > > > > > I was at a branch office where the users could not access the > > > > corporate network. The router, a 1720 setup as a bridge with the same > > > > IP address for the FastEthernet as the Serial subinterface, both > > > > configured for bridge-group 1. It was connected to a 2620 at the > > > > corporate office via a Fractional Frame Relay connection. > > > > > > > > I changed the switch out with an old spare hub I had lying around, and > > > > connected only one workstation from the local network. After starting > > > > the router up, I could ping the local workstation, and I could ping > > > > devices on the corporate network, so both my FastEthernet and Serial > > > > interfaces were working fine. However, I could not ping anything on > > > > the corporate network from my workstation, nor could I from a telnet > > > > connection to my corporate router ping the workstation, so traffic was > > > > not being passed through > > >between > > > > the interfaces. > > > > > > > > That looked like a typical routing problem, but the only problem was > > > > that > > >I > > > > was not routing, I was bridging, so ????? > > > > > > > > I did a "show bridge 1 group" and saw that the FastEthernet was in a > > > > blocking state by the spanning tree, so something was wrong here. I > > >cleared > > > > the arp table on the router and on all other routers and switches. I > > > > tried to assign a different mac address to the FE interface. I tried a > > > > different workstation. No matter what I did, it kept being in a > > > > blocking state. > > > > > > > > I went in and did a "bridge-group 1 spanning-disabled" on the > > > > interface, > > >and > > > > it changed to forwarding state, but I could still not pass traffic > > >through. > > > > > > > > This is when I called TAC, but after I guided them through to a telnet > > > > connection to my routers, they decided after three hours that > > > > something weird was going on with the router, and they did an RMA for > > > > a replacement unit. > > > > > > > > However, I decided to continue my troubleshooting, because I hate to > > > > give up. I reconfigured everything, I tried to create a bridge-group 2 > > > > instead, > > >I > > > > forced it into IP routing, and back off it again, but no matter what, > > > > it kept going into blocking mode (I had removed the spanning-disabled > > > > command again at that time). > > > > > > > > That's when it hit me to try and force the speed on the interface. It > > > > was > > >in > > > > AUTO, and my switch had been auto 10/100, but my hub was only 10. I > > >changed > > > > it from auto to 10 and power cycled the router. PLING!!! Now it > > > > started up and after the listening and learning, it went in forwarding > > > > state, and I could now ping through my router, and I could connect my > > > > workstation to > > >the > > > > corporate network. > > > > > > > > What makes this strange is that I can apparently use my FastEthernet > > > > interface from the router even though the speed is wrong, but the STP > > >see's > > > > this and blocks the interface for switched traffic. WEIRD!!!!! > > > > > > > > Read the entire case study here: > > > > > > > > http://www.RouterChief.com/CaseStudies/1.htm > > > > > > > > Ole > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Ole Drews Jensen > > > > Systems Network Manager > > > > CCNP, MCSE, MCP+I > > > > RWR Enterprises, Inc. > > > > [EMAIL PROTECTED] > > > > http://www.RouterChief.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > NEED A JOB ??? > > > > http://www.oledrews.com/job > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30664&t=30446 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
