Re: [c-nsp] upgrading stack of 3750E's
We just looked at the 3750E series and bough some because of the stackability. According to Cisco engineers I talked to and a local CCIE, you cannot upgrade the stack in multiple stages. I am told that upgrding the master switch will autmatically upgrade the othes switches at the same time. No matter what, there will be downtime. *sigh* Chris - Original Message - From: Holemans Wim wim.holem...@ua.ac.be To: cisco-nsp@puck.nether.net Sent: Monday, January 26, 2009 1:48:32 AM GMT -08:00 US/Canada Pacific Subject: [c-nsp] upgrading stack of 3750E's We are testing the following setup : 65XX-VSS - etherchannel - 3750E stack (2 switches) - teaming enabled servers This should give maximal uptime, overriding defects on the router or 3750E switches. We intend to use these switches in L2 mode only, managing them via the mgmt fa0 interface. I'm now looking into the upgrading procedure for the stack, but I can't seem to find a way to do an upgrade in which at least of the 3750E's stays operational, thus minimalizing down time. As far as I can tell from the doc, there is no way to upgrade e.g. the master switch, have it reload (keeping the second switch operational), and after the master becomes operational, (auto-)upgrade the second switch. Am I missing something or is this scenario really not possible ? Another scenario would be removing the switch from the stack (after bringing down all ports first via console), changing the ip address of the switch, bringing the mgmt port back online, do the upgrade, bring the power down, reconnect it to the stack and the power up it again. Given the fact that the stack cables are rather fragile, this doesn't seem the right way to do, unless it is possible to shut down the stack ports by a CLI command ? Anyone suggestions, pointers to alternative upgrade procedures,... Thanks, Wim Holemans Network Services University of Antwerp Netwerkdienst Universiteit Antwerpen ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
The auto upgrade part just is simply not true 100%. You can load the software and not reboot as well as ignore version mismatches. Yes, there will be downtime due to a reboot. There is no ISSU. tv - Original Message - From: Chris Gauthier ch...@k7sle.com To: Holemans Wim wim.holem...@ua.ac.be Cc: cisco-nsp@puck.nether.net Sent: Friday, January 30, 2009 3:50 PM Subject: Re: [c-nsp] upgrading stack of 3750E's We just looked at the 3750E series and bough some because of the stackability. According to Cisco engineers I talked to and a local CCIE, you cannot upgrade the stack in multiple stages. I am told that upgrding the master switch will autmatically upgrade the othes switches at the same time. No matter what, there will be downtime. *sigh* Chris - Original Message - From: Holemans Wim wim.holem...@ua.ac.be To: cisco-nsp@puck.nether.net Sent: Monday, January 26, 2009 1:48:32 AM GMT -08:00 US/Canada Pacific Subject: [c-nsp] upgrading stack of 3750E's We are testing the following setup : 65XX-VSS - etherchannel - 3750E stack (2 switches) - teaming enabled servers This should give maximal uptime, overriding defects on the router or 3750E switches. We intend to use these switches in L2 mode only, managing them via the mgmt fa0 interface. I'm now looking into the upgrading procedure for the stack, but I can't seem to find a way to do an upgrade in which at least of the 3750E's stays operational, thus minimalizing down time. As far as I can tell from the doc, there is no way to upgrade e.g. the master switch, have it reload (keeping the second switch operational), and after the master becomes operational, (auto-)upgrade the second switch. Am I missing something or is this scenario really not possible ? Another scenario would be removing the switch from the stack (after bringing down all ports first via console), changing the ip address of the switch, bringing the mgmt port back online, do the upgrade, bring the power down, reconnect it to the stack and the power up it again. Given the fact that the stack cables are rather fragile, this doesn't seem the right way to do, unless it is possible to shut down the stack ports by a CLI command ? Anyone suggestions, pointers to alternative upgrade procedures,... Thanks, Wim Holemans Network Services University of Antwerp Netwerkdienst Universiteit Antwerpen ___ cisco-nsp mailing list cisco-nsp@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
(I'm the one who posted the original question). Just tested it again with a second stack of 3750E's ; this gave the same result : Upgrading from 12.2.2(35) to 12.2.(46) and reload of second switch gave a Version Mismatch with left the second switch hanging. Only a reload of the master restored full functionality. After that, I replaced the ip base image with the one with encryption (k9 version), however same versionnumber 12.2(46). This went as described below, second one came back online and became again member of the stack without problem allowing reload of first one. So my conclusion is that the possibility to upgrade a stack without losing full connectivity is different for each upgrade and you can't tell in advance if it will result in a version mismatch or not. Feel free to comment if you have different experiences. Wim Holemans -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev Sent: maandag 26 januari 2009 19:38 To: Tony Varriale Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] upgrading stack of 3750E's On Mon, 2009-01-26 at 08:45 -0600, Tony Varriale wrote: This is how I normally do it. 1) archive software to first switch /overwrite (from TFTP) without reload. 2) archive software to second switch /overwrite without reload. 3) reload slot 1 4) wait until switch 1 is operational and you are happy 5) reload slot 2 Will this work? Wouldn't Stackwise see the two switches as incompatible? We've started using pairs of 3750E with a CX4 link between them and just plain rapid PVST+. Then we have some guarantees as to how the system functions during upgrades. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
Just to clarify...the first switch was upgraded to 46 and reloaded first? I'm confused on your steps for 2 switches and the process... tv - Original Message - From: Holemans Wim wim.holem...@ua.ac.be To: Peter Rathlev pe...@rathlev.dk; Tony Varriale tvarri...@comcast.net Cc: cisco-nsp@puck.nether.net Sent: Tuesday, January 27, 2009 12:38 PM Subject: RE: [c-nsp] upgrading stack of 3750E's (I'm the one who posted the original question). Just tested it again with a second stack of 3750E's ; this gave the same result : Upgrading from 12.2.2(35) to 12.2.(46) and reload of second switch gave a Version Mismatch with left the second switch hanging. Only a reload of the master restored full functionality. After that, I replaced the ip base image with the one with encryption (k9 version), however same versionnumber 12.2(46). This went as described below, second one came back online and became again member of the stack without problem allowing reload of first one. So my conclusion is that the possibility to upgrade a stack without losing full connectivity is different for each upgrade and you can't tell in advance if it will result in a version mismatch or not. Feel free to comment if you have different experiences. Wim Holemans -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev Sent: maandag 26 januari 2009 19:38 To: Tony Varriale Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] upgrading stack of 3750E's On Mon, 2009-01-26 at 08:45 -0600, Tony Varriale wrote: This is how I normally do it. 1) archive software to first switch /overwrite (from TFTP) without reload. 2) archive software to second switch /overwrite without reload. 3) reload slot 1 4) wait until switch 1 is operational and you are happy 5) reload slot 2 Will this work? Wouldn't Stackwise see the two switches as incompatible? We've started using pairs of 3750E with a CX4 link between them and just plain rapid PVST+. Then we have some guarantees as to how the system functions during upgrades. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] upgrading stack of 3750E's
We are testing the following setup : 65XX-VSS - etherchannel - 3750E stack (2 switches) - teaming enabled servers This should give maximal uptime, overriding defects on the router or 3750E switches. We intend to use these switches in L2 mode only, managing them via the mgmt fa0 interface. I'm now looking into the upgrading procedure for the stack, but I can't seem to find a way to do an upgrade in which at least of the 3750E's stays operational, thus minimalizing down time. As far as I can tell from the doc, there is no way to upgrade e.g. the master switch, have it reload (keeping the second switch operational), and after the master becomes operational, (auto-)upgrade the second switch. Am I missing something or is this scenario really not possible ? Another scenario would be removing the switch from the stack (after bringing down all ports first via console), changing the ip address of the switch, bringing the mgmt port back online, do the upgrade, bring the power down, reconnect it to the stack and the power up it again. Given the fact that the stack cables are rather fragile, this doesn't seem the right way to do, unless it is possible to shut down the stack ports by a CLI command ? Anyone suggestions, pointers to alternative upgrade procedures,... Thanks, Wim Holemans Network Services University of Antwerp Netwerkdienst Universiteit Antwerpen ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
This is how I normally do it. 1) archive software to first switch /overwrite (from TFTP) without reload. 2) archive software to second switch /overwrite without reload. 3) reload slot 1 4) wait until switch 1 is operational and you are happy 5) reload slot 2 tv - Original Message - From: Holemans Wim wim.holem...@ua.ac.be To: cisco-nsp@puck.nether.net Sent: Monday, January 26, 2009 3:48 AM Subject: [c-nsp] upgrading stack of 3750E's We are testing the following setup : 65XX-VSS - etherchannel - 3750E stack (2 switches) - teaming enabled servers This should give maximal uptime, overriding defects on the router or 3750E switches. We intend to use these switches in L2 mode only, managing them via the mgmt fa0 interface. I'm now looking into the upgrading procedure for the stack, but I can't seem to find a way to do an upgrade in which at least of the 3750E's stays operational, thus minimalizing down time. As far as I can tell from the doc, there is no way to upgrade e.g. the master switch, have it reload (keeping the second switch operational), and after the master becomes operational, (auto-)upgrade the second switch. Am I missing something or is this scenario really not possible ? Another scenario would be removing the switch from the stack (after bringing down all ports first via console), changing the ip address of the switch, bringing the mgmt port back online, do the upgrade, bring the power down, reconnect it to the stack and the power up it again. Given the fact that the stack cables are rather fragile, this doesn't seem the right way to do, unless it is possible to shut down the stack ports by a CLI command ? Anyone suggestions, pointers to alternative upgrade procedures,... Thanks, Wim Holemans Network Services University of Antwerp Netwerkdienst Universiteit Antwerpen ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
On Mon, 2009-01-26 at 08:45 -0600, Tony Varriale wrote: This is how I normally do it. 1) archive software to first switch /overwrite (from TFTP) without reload. 2) archive software to second switch /overwrite without reload. 3) reload slot 1 4) wait until switch 1 is operational and you are happy 5) reload slot 2 Will this work? Wouldn't Stackwise see the two switches as incompatible? We've started using pairs of 3750E with a CX4 link between them and just plain rapid PVST+. Then we have some guarantees as to how the system functions during upgrades. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] upgrading stack of 3750E's
In this example, there are only 2 switches. The first switch comes up as sees the second as incompatible. Hence, the reload of that second. After the first comes up and the stack is aware, the first switch is functioning and has it's config. The second...not so much. Note this isn't a normal process and this problem only occurs across certain IOS. Lab it up see if you get the same thing. I've had to do this (from 35 to 46) to about 40 3750E and 3750s recently. tv - Original Message - From: Peter Rathlev pe...@rathlev.dk To: Tony Varriale tvarri...@comcast.net Cc: cisco-nsp@puck.nether.net Sent: Monday, January 26, 2009 12:37 PM Subject: Re: [c-nsp] upgrading stack of 3750E's On Mon, 2009-01-26 at 08:45 -0600, Tony Varriale wrote: This is how I normally do it. 1) archive software to first switch /overwrite (from TFTP) without reload. 2) archive software to second switch /overwrite without reload. 3) reload slot 1 4) wait until switch 1 is operational and you are happy 5) reload slot 2 Will this work? Wouldn't Stackwise see the two switches as incompatible? We've started using pairs of 3750E with a CX4 link between them and just plain rapid PVST+. Then we have some guarantees as to how the system functions during upgrades. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
