RE: Autosense this ... (add to your knowledgebase) [7:30446]
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
Re: Autosense this ... (add to your knowledgebase) [7:30446]
Someone at Cisco was just telling me about a guy who came in from Korea to take the CCIE lab and during lunch, he called TAC on one of the problems. The TAC tech recognized the problem as a lab problem from his CCIE test, called down to the lab instructors to see if that person was taking the lab, and sure enough he was. He was busted and sent back home. I don't agree with what he did, but I find it amusing none the less. ""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Thanks. > > > ""Priscilla Oppenheimer"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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: Chuc
Re: Autosense this ... (add to your knowledgebase) [7:30446]
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"&qu
RE: Autosense this ... (add to your knowledgebase) [7:30446]
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 >
Re: Autosense this ... (add to your knowledgebase) [7:30446]
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 &g
Re: Autosense this ... (add to your knowledgebase) [7:30446]
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"&qu
RE: Autosense this ... (add to your knowledgebase) [7:30446]
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
Re: Autosense this ... (add to your knowledgebase) [7:30446]
Thanks. ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 elsewh
Re: Autosense this ... (add to your knowledgebase) [7:30446]
Someone at Cisco was just telling me about a guy who came in from Korea to take the CCIE lab and during lunch, he called TAC on one of the problems. The TAC tech recognized the problem as a lab problem from his CCIE test, called down to the lab instructors to see if that person was taking the lab, and sure enough he was. He was busted and sent back home. I don't agree with what he did, but I find it amusing none the less. ""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Thanks. > > > ""Priscilla Oppenheimer"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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: Chuc
Re: Autosense this ... (add to your knowledgebase) [7:30446]
You have access to a phone during the test? I guess a cell call during a bathroom break could occur. Brian "Sonic" Whalen Success = Preparation + Opportunity On Mon, 31 Dec 2001, EA Louie wrote: > > Someone at Cisco was just telling me about a guy who came in from Korea to > > take the CCIE lab and during lunch, he called TAC on one of the problems. > > The TAC tech recognized the problem as a lab problem from his CCIE test, > > called down to the lab instructors to see if that person was taking the > lab, > > and sure enough he was. He was busted and sent back home. I don't agree > > with what he did, but I find it amusing none the less. > > > > now THAT's funny, and tragic, and qualifies as an honorable mention in "The > 2001 Darwin Awards" > > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30605&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Autosense this ... (add to your knowledgebase) [7:30446]
> Someone at Cisco was just telling me about a guy who came in from Korea to > take the CCIE lab and during lunch, he called TAC on one of the problems. > The TAC tech recognized the problem as a lab problem from his CCIE test, > called down to the lab instructors to see if that person was taking the lab, > and sure enough he was. He was busted and sent back home. I don't agree > with what he did, but I find it amusing none the less. > now THAT's funny, and tragic, and qualifies as an honorable mention in "The 2001 Darwin Awards" _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30599&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Autosense this ... (add to your knowledgebase) [7:30446]
He is one smart TAC and should get a year-end bonus. Perhaps our group members can send recommendation to Cisco's management for his diligence. ""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Someone at Cisco was just telling me about a guy who came in from Korea to > take the CCIE lab and during lunch, he called TAC on one of the problems. > The TAC tech recognized the problem as a lab problem from his CCIE test, > called down to the lab instructors to see if that person was taking the lab, > and sure enough he was. He was busted and sent back home. I don't agree > with what he did, but I find it amusing none the less. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30579&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Autosense this ... (add to your knowledgebase) [7:30446]
Someone at Cisco was just telling me about a guy who came in from Korea to take the CCIE lab and during lunch, he called TAC on one of the problems. The TAC tech recognized the problem as a lab problem from his CCIE test, called down to the lab instructors to see if that person was taking the lab, and sure enough he was. He was busted and sent back home. I don't agree with what he did, but I find it amusing none the less. ""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Thanks. > > > ""Priscilla Oppenheimer"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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: Chuc
Re: Autosense this ... (add to your knowledgebase) [7:30446]
You hit the nail on the head!!! Dave "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? > David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30570&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Autosense this ... (add to your knowledgebase) [7:30446]
Thanks. ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 elsewh
Re: Autosense this ... (add to your knowledgebase) [7:30446]
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 &g
RE: Autosense this ... (add to your knowledgebase) [7:30446]
Just curious, but when using the LinkSys 10/100 switches, what did they auto-negotiate to? Which speed and which duplex mode? Did the hub that you installed even understand auto-negotiation? Perhaps it was too old to understand auto-negotiation which was introduced to the IEEE 802.3 specs relatively recently. Of course, the router should have figured this out. (Auto-negotiation is supposed to work even if the other side doens't understand it). But the router might not have been smart enough to do this until you rebooted. In other words, it thought all was fine and didn't bother to renegotiate speed/duplex mode until you rebooted. (See my earlier comment about 10-Mbps link pulses looking similar to auto-negotiation pulses.) In fact, all was fine (sort of) because you could ping. Could it be that after some time elapsed the router interface figured out that there was a duplex mismatch or realized that it was getting a high collision rate (receiving while sending due to the duplex mismatch?) Perhaps STP is smart enough to never leave the blocking state when there is a high collision rate. Anyway, thanks for the helpful case study. Priscilla At 11:42 PM 12/29/01, Ole Drews Jensen wrote: >Chuck, > >At all three offices when I installed these 1720's, I at the same time >installed some new LinkSYS 10/100 switches (the black and blue model). This >worked (works) fine with the 1720 set to auto. > >However, when I replaced the switch, it was with a 3COM hub, and that one is >a 10 mbps. > >I did remove the manual mac config from the FE again, so that was not part >of the solution. > >If you have an old 3COM HUB TP16...(something - I cannot remember the exact >model number), try to set your router in auto sense and connect the hub and >see what happens. > >I guess this is one of these weird situations you come accros sometimes. But >anyway, a speed problem should never cause the STP to go into blocking mode >- those two things doesn't really have anything to do with each other. So, >interesting.. > >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 > > > > >-Original Message- >From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] >Sent: Saturday, December 29, 2001 5: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
Re: Autosense this ... (add to your knowledgebase) [7:30446]
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"&qu
RE: Autosense this ... (add to your knowledgebase) [7:30446]
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 >
RE: Autosense this ... (add to your knowledgebase) [7:30446]
Did you start early on the Champagne Howard??? :-) Happy New Year... 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 ~~~ -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Monday, December 31, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: Re: Autosense this ... (add to your knowledgebase) [7:30446] >I know what you mean Chuck, it's hard to explain a misconfigured >network. Not implying the Ole misconfigured the router per se but when >auto stuff doesn't work that is the end result. I have been involved >numerous times in problems that were auto related but most often things >"work" but performance is degraded and inconsistant which can lead you >down other paths!! > > Bottom line, if you can avoid it don't trust auto, hardcode the speeds >and duplex whenevr possible! > > Dave Somehow, I hear a voice saying, "This is the fastest switch in the world. I forget if your port is autosensed or autonegotiated. Feeling lucky, punk?" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30540&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Autosense this ... (add to your knowledgebase) [7:30446]
>I know what you mean Chuck, it's hard to explain a misconfigured >network. Not implying the Ole misconfigured the router per se but when >auto stuff doesn't work that is the end result. I have been involved >numerous times in problems that were auto related but most often things >"work" but performance is degraded and inconsistant which can lead you >down other paths!! > > Bottom line, if you can avoid it don't trust auto, hardcode the speeds >and duplex whenevr possible! > > Dave Somehow, I hear a voice saying, "This is the fastest switch in the world. I forget if your port is autosensed or autonegotiated. Feeling lucky, punk?" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30538&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Autosense this ... (add to your knowledgebase) [7:30446]
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 >
Re: Autosense this ... (add to your knowledgebase) [7:30446]
I know what you mean Chuck, it's hard to explain a misconfigured network. Not implying the Ole misconfigured the router per se but when auto stuff doesn't work that is the end result. I have been involved numerous times in problems that were auto related but most often things "work" but performance is degraded and inconsistant which can lead you down other paths!! Bottom line, if you can avoid it don't trust auto, hardcode the speeds and duplex whenevr possible! Dave Chuck Larrieu wrote: > > 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
Re: Autosense this ... (add to your knowledgebase) [7:30446]
The Autosense feature should be taken with a grain of salt. If you need a specific connection to work, you should set the speed and duplex manually. One of the first thing I became aware of many years ago is that most "auto" features are spastic at best ON ANY EQUIPMENT. Not just Cisco!I have had strange problems when the equipment rebooted later on. If you set it when you configure the interface you will save a lot of grief. I also recommend this action for client stations. To eliminate problems specify in your Policy and Procedures manual that "Autosense" is not to be used. Dom Marino ""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 > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30476&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Autosense this ... (add to your knowledgebase) [7:30446]
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 > int
RE: Autosense this ... (add to your knowledgebase) [7:30446]
I always use 568B specs when making cables, except when making a crossed one, then it's A in one end and B in the other (green and orange switched). Wiring according to 568B should never cause a problem. I would look for a bad cable, connection, light fixtures close to the wire, etc... 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 -Original Message- From: William Harrison [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 9:13 PM To: [EMAIL PROTECTED] Subject: FW: Autosense this ... (add to your knowledgebase) [7:30446] Chuck, Just a (me too.) to add to your commitments. I'm not familiar with the fact that a router (cisco?) actually ran span tree or perform ST cals. However I have seen an FE interface close down due to a wiring problem where an installer wired two rooms using 568B specs. This cause the router to be unable to negotiate the 10/100 connection between the clients! two cents Bill Harrison -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 5: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
RE: Autosense this ... (add to your knowledgebase) [7:30446]
Chuck, At all three offices when I installed these 1720's, I at the same time installed some new LinkSYS 10/100 switches (the black and blue model). This worked (works) fine with the 1720 set to auto. However, when I replaced the switch, it was with a 3COM hub, and that one is a 10 mbps. I did remove the manual mac config from the FE again, so that was not part of the solution. If you have an old 3COM HUB TP16...(something - I cannot remember the exact model number), try to set your router in auto sense and connect the hub and see what happens. I guess this is one of these weird situations you come accros sometimes. But anyway, a speed problem should never cause the STP to go into blocking mode - those two things doesn't really have anything to do with each other. So, interesting.. 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 -Original Message- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 29, 2001 5: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 > u
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
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 > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30448&t=30446 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.
