Assuming the secondary is running well and you are confident the config is
correct, you should make it active, then perform your upgrade procedure on
the primary.
There is no failover preemption. So, if the secondary is active and the
primary comes up dead or blows up, no harm to your environment other than
you need to correct the redundant module.
As a side note, I haven't seen that issue on a minor version upgrade. But,
I haven't seen 3.1.x in while. The last 3.2.x I did worked great.
tv
----- Original Message -----
From: "Arne Larsen / Region Nordjylland" <[email protected]>
To: <[email protected]>
Sent: Friday, May 14, 2010 5:55 AM
Subject: [c-nsp] vs. upgrading FWSM on Cisco 6500 from 3.1(13) 3.1(17)
Hi all.
Can someone give me a hint about what I might be doing wrong.
I'm upgrading fwsm from release 3.1.13 to 3.1.17.
I uploaded the new image to the secondary module, saved the config and
reloaded the module.
It came up totally blank. Every config on each context was gone.
So I sat it up again as failover, and the primary module replicated the
complete config of all contexts.
Now I'm a bit afraid what will happened when I reload the primary module.
Has any experienced anything like this.
/Arne
_______________________________________________
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/
