Here's me thinking I'm cracking up. I just did what you recommended and it worked! I guess SXI3 can stay... you've just saved me another early downtime window.
Thank you. :-) On 27 Jan 2010, at 23:07, Matthew Huff wrote: > 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/
