I did the exact same thing first go round ;)  Crazy thing is I just went 
through this 2 days ago and thanks to Matthew got it fixed!

On Jan 27, 2010, at 4:03 PM, Alasdair McWilliam wrote:

> 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/

_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to