[c-nsp] best ios version for VSS

Wed Jan 27 18:16:35 EST 2010

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:alasdairm at gmail.com] 
> Sent: Wednesday, January 27, 2010 6:03 PM
> To: Alasdair McWilliam
> Cc: Matthew Huff; Adam Korab; 'Holemans Wim'; 'cisco-nsp at puck.nether.net'
> 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: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>>>> Alasdair McWilliam
>>>> Sent: Wednesday, January 27, 2010 11:26 AM
>>>> To: Holemans Wim
>>>> Cc: cisco-nsp at puck.nether.net
>>>> 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  cisco-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>> 
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> <Matthew Huff.vcf>
>> 
> 