Re: OOT: VSS experience

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 Thu Apr 12 2012 - 21:49:45 ART