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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30669&t=30446 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
