Re: OOT: VSS experience

Hi Marc,

Thank you for the replies.
Have you tried eFSU (enhanced FSU)?
I just watched this video https://supportforums.cisco.com/videos/2650 about
eFSU upgrade on VSS with Quad Supervisor.
It seems awesome, only 5 ping packets were lost during the upgrade.

Regards,
Alex

On Fri, Apr 13, 2012 at 12:49 PM, marc edwards <renorider_at_gmail.com> wrote:

> Even being more defined. I remember that since the break also happens to
> the erthchannel that the heartbeat/keepalives live on, it breaks the
> chassis from being seen as one. This can cause path selection and ports at
> best get disabled or at worst get err-disabled needing physical bounce.
>
> 1000v seemed to have some ehter channel-issues once back up as well. I
> could go on about that long maintnance. Longer than most. I aslo replaced a
> 4500 chassis from R R-E by unscrewing everything, and pulling modules out
> but keeping cabling existing, then screwing chassis in contortion style. My
> back hurt for a few days.
>
> It was a rough few days at work... But perhaps the process will get
> easier. We go with one sup per chassis and maybe dual sups simplifies it a
> bit. Food for thought.
>
> Aside from that, we have minimal issues setting up virtual port channels
> and I am satisfied with the technologies ability to simplify design issues.
>
> HTH
>
> Marc
>
>
> On Thu, Apr 12, 2012 at 8:07 PM, marc edwards <renorider_at_gmail.com> wrote:
>
>> I guess I should elaborate with some information that brings me to that
>> feeling.
>>
>> Performing a Fast Software Upgrade of a VSS
>>
>> The FSU of a VSS is similar to the RPR-based standalone chassis FSU
>> described in the "Performing a Fast Software Upgrade" section<http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/redund.html#wpxref62923>.
>> While the standalone chassis upgrade is initiated by reloading the VSS
>> standby supervisor engine, the VSS upgrade is initiated by reloading the
>> VSS standby chassis. During the FSU procedure, a software version
>> mismatch between the VSS active and the VSS standby chassis causes the
>> system to boot in RPR redundancy mode, which is stateless and causes a hard
>> reset of the all modules. As a result, the FSU procedure requires system
>> downtime corresponding to the RPR switchover time.
>>
>> This can break the vPC's (not sure if they have same name as Nexus)
>> and cause some spanning-tree fun if not careful as well. It does need mtnc.
>> window. Don't forget, this will most likely be distribution/core device
>> touching almost everything in the campus. Speaking from bloody experience
>> on that one.
>>
>> Regards,
>>
>> Marc
>>
>> On Thu, Apr 12, 2012 at 6:57 PM, Alexander Halim <cisco.alexand_at_gmail.com
>> > wrote:
>>
>>> Hi Marc,
>>>
>>> Does it mean that VSS requires downtime when doing IOS upgrade? I
>>> thought it supports eFSU which is a kind of ISSU? Or you are referring to
>>> the complexity of eFSU procedure?
>>>
>>> Thank you for sharing.
>>>
>>> Regards,
>>> Alex
>>>
>>> On Apr 12, 2012, at 11:58 PM, marc edwards <renorider_at_gmail.com> wrote:
>>>
>>> It is great... but a bitch to update IOS. At least that is my experience
>>> with it.
>>>
>>> On Thu, Apr 12, 2012 at 8:42 AM, Alexander Lim <<cisco.alexand_at_gmail.com>
>>> cisco.alexand_at_gmail.com> wrote:
>>>
>>>> Guys,
>>>>
>>>> Sorry for non-technical question.
>>>> But may I ask you if you have any bad experience deploying/using VSS?
>>>> Is it
>>>> quite stable?
>>>> Would you recommend using VSS in production network?
>>>>
>>>> Thanks
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>>
>>>> Blogs and organic groups at <http://www.ccie.net>http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> <http://www.groupstudy.com/list/CCIELab.html>
>>>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Apr 14 2012 - 00:07:11 ART