Actually, the bug notice was updated recently. I had escalated to a back line engineer and he was the one that wrote the original bug text, and he updated it with the new workaround. So you didn't miss anything the first time
-----Original Message----- From: Alasdair McWilliam [mailto:[email protected]] Sent: Wednesday, January 27, 2010 6:03 PM To: Alasdair McWilliam Cc: Matthew Huff; Adam Korab; 'Holemans Wim'; '[email protected]' Subject: Re: [c-nsp] best ios version for VSS I take back what I just said about the specified workaround not working....... I clearly had blinkers on and missed the line about taking the last character off !!! Ho hum.. On 27 Jan 2010, at 23:01, Alasdair McWilliam wrote: > Oooh... :-) > > The bug I had stumbled over was CSCtc41114, matching our conditions and > symptoms. I've had no luck with the workarounds mentioned in the bug notes > and my interpretation was that SXI3 'caused' the bug. I don't have the luxury > of test boxes, multiple downtime windows or just enabling alternative remote > access mechanisms (i.e. telnet !), so was going to try just downgrade back to > SXI2a. > > I'll try this and see how we go... :) > > > On 27 Jan 2010, at 16:50, Matthew Huff wrote: > >> With SXI3 there is a quick fix for the SSH bug. >> >> Basically, during the upgrade the key gets corrupted and becomes a phantom. >> You can't delete it with zeroize. The corruption is in the key label (which >> if you don't specify, is the fqdn) which gets corrupted with the last letter >> left off. >> >> For example, our switch was named "switch-core1" with a domain of "ox.com". >> The fqdn was "switch-core1.ox.com". After the upgrade, the hidden corrupted >> key was labeled "switch-core1.ox.co". >> >> The solution is to create a key with the bad label that will overwrite the >> phantom, then delete it: >> >> switch-core1(config)#crypto key generate rsa general-keys label >> switch-core1.ox.co modulus 512 >> switch-core1(config)#crypto key zeroize rsa switch-core1.ox.co >> >> and the phantom key will be gone. >> >> >> ---- >> Matthew Huff | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> http://www.ox.com | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-460-4139 >> >> >> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> Alasdair McWilliam >>> Sent: Wednesday, January 27, 2010 11:26 AM >>> To: Holemans Wim >>> Cc: [email protected] >>> Subject: Re: [c-nsp] best ios version for VSS >>> >>> I have used 12.2(33)SXI1 on a VSS but encountered a *very* nasty bug >>> triggered when performing an SSO >>> failover, which causes STP to get its knickers in a twist. Ultimately we >>> had to just power the whole >>> thing off (both chassis) to break the loops and restore service, but the >>> whole installation was >>> offline for much longer than a reboot because ACE modules take flipping >>> ages to boot... >>> >>> I now run 12.2(33)SXI2 on VSS with a 'workaround' for a memory leak bug >>> (fixed in SXI2a) and it's been >>> rock solid. Touch wood. >>> >>> I've run 12.2(33)SXI3 on some non-VSS nodes but the upgrade breaks SSH >>> beyond repair (to my >>> knowledge?) if you do an SSO failover, so these are going to be downgraded >>> back to SXI2a. >>> >>> HTH >>> >>> >>> >>> >>> On 27 Jan 2010, at 14:01, Holemans Wim wrote: >>> >>>> We have a VSS running, L2 only for the moment. We plan to enable L3 >>>> (static routing only for the moment) next week (along with a FWSM board >>>> in each chassis). >>>> >>>> We are running version s72033-advipservicesk9_wan-mz.122-33.SXI1.bin for >>>> the moment (I know this version has too much features for what we need >>>> for the moment) >>>> >>>> The problems we had with this version until now : >>>> >>>> - One of the supervisors rebooted spontaneously leaving no >>>> traces on why it restarted >>>> >>>> - ISSU (I don't remember what the version was we started the >>>> upgrade) didn't work, so I had to boot both chassis manually, giving a >>>> much higher downtime than expected >>>> >>>> - The activation of the first FWSM (inserted with power down >>>> for that specific module, followed by power up of the module), caused a >>>> crash and reboot of the supervisor of the chassis in with the FWSM was >>>> inserted. >>>> >>>> >>>> >>>> So anyone has comments on to which version we eventually should upgrade >>>> to before going to L3 ? (downtime will have a much larger impact from >>>> that moment on). >>>> >>>> I found on the cisco website there is a version 12.2.33-SXH6(ED) and a >>>> version 12.2.33-SXI3(ED) available. >>>> >>>> >>>> >>>> Greetings, >>>> >>>> >>>> >>>> Wim Holemans >>>> >>>> Network Services >>>> >>>> University of Antwerp >>>> >>>> _______________________________________________ >>>> cisco-nsp mailing list [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> <Matthew Huff.vcf> > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
