[c-nsp] CSM FT failover behavior

[Jason Lixfeld]

My experiences are quite similar.  I'm running 4.1(6) on 12.2(18)SXF7  
(There were issues with the 4.2 code when we tried to deploy this  
last year and Cisco advised us at the time to stick with 4.1.  I'm  
sure now, months later, 4.2 is fine.).

I successfully failed over and failed back while maintaining open  
telnet sessions, SMTP sessions and FTP sessions.

I have been very pleased with the performance and stability of this  
platform.

The rest of this is O/T, but I'll chime in anyway:  The only problems  
I have experienced so far have been when failing over the FWSMs or  
performing software upgrades on the SUP720s and/or MSFCs:

FWSM issues:
Because (to my knowledge) the FWSMs don't support NSF and my traffic  
is sourced/destined for hosts behind the FWSMs, it can take a couple  
seconds for traffic to flow again while OSPF recalculates after a  
failover or failback.

SUP/MSFC issues:
You will experience degraded service when you try to perform software  
upgrades on either the SUP or the MSFC.  If you're running Hybrid  
mode and 8.x code on the SUP, you're going to get a double whammy as  
image versioning isn't supported in 8.x (no idea why! Maybe to push  
us towards Native mode?).  If you're running Native mode, or if you  
just want to upgrade MSFC code in a Hybrid configuration and your  
MSFCs are configured for NSF/SSO, when the SUPs detect a software  
mismatch, the standby MSFC defaults to RPR mode, which is essentially  
a cold standby state, so when you fail the active MSFC to the standby  
MSFC that has the code you just upgraded to, RPR mode causes all the  
cards to reset which lead to a couple minutes of degraded service as  
things boot back up again.  Keep in mind that my references to MSFC  
reloads and SUP reloads above is relative.  If you are going to  
upgrade your SUP, your MSFC will reload too (hence the double whammy  
if you're running 8.x in Hybrid mode).

Here are the docs.

http://www.cisco.com/en/US/products/hw/switches/ps708/ 
products_configuration_example09186a00807714cb.shtml
http://www.cisco.com/en/US/products/hw/switches/ps708/ 
prod_release_note09186a008019d7f0.html#wp907354

On 30-Aug-07, at 2:22 PM, Conaway, Aaron wrote:

> We have a pair of CSMs running 4.2(4) in 6509s running 12.2(18)SXF6.
> During initial testing, I was able to telnet to port 80 on one of the
> RIPs and fail it over, and my telnet session stayed open.  The most  
> loss
> I've seen is a few packets, but I've never lost any connections that
> were already open.
>
> Of course, your mileage may vary.
>
> -----
> Aaron Conaway
>
>
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net
>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James
>> Sneeringer
>> Sent: Thursday, August 30, 2007 11:04 AM
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] CSM FT failover behavior
>>
>> We have a pair of 6509's running 12.1(27b)E1 native mode,
>> each with a CSM
>> running 4.2(6) in FT mode.
>>
>> Can anyone comment on the behavior of the CSMs during failover? In  
>> the
>> section on doing a "hitless upgrade" in the CSM 4.2
>> Configuration Guide[1],
>> it's described as not resulting in any "major service
>> interruption", which I
>> take to mean that there could still be some noticeable affect
>> of failing
>> from one CSM to the other.
>>
>> All of our vservers replicate connection and sticky information.  
>> Can I
>> expect something simple like an HTTP session to survive the failover
>> process?
>>
>> -James
>>
>> [1]
>> http://www.cisco.com/en/US/docs/interfaces_modules/services_mo
>> dules/csm/4.2.
>> x/configuration/guide/redun.html#wp1046227
>>
>> _______________________________________________
>> 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/