Not much Nexus 7k XP and wanting people's thoughts on the following
if you had a customer running a pair of 7ks happily on 5.2(4) with no known stability issues or bugs affecting the environment.
They are only running Sup 1, F1 and M1 cards and will not buy Sup 2, F2 and M2s before EOL (2019). They have plenty of spare 10G ports and redundant M1 blades. They are extremely risk averse and want to change things as absolutely minimally as possible.
Would you upgrade to NX-OS 6.1(5) or latest 5.2(9)? (6.2 and 7.x are too new.) Are there any issues staying on v5 train if there's no possibility of M2/F2/Sup2 cards?
I know 4 years is a long time, but they've lasted the last 3 without changing a thing, and they just bought a stack of M1/F1 blades and are convinced they can ride it out until 2019 with no more HW upgrades.
For those vets who've done ISSU on live 7ks, is there any greater risk in going to 6.x vs staying on same code train?
The upgrade path for both appears valid.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/release/notes/52_nx-os_release_note.html#pgfId-496973 (http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/release/notes/52_nx-os_release_note.html#pgfId-496973)
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/61_nx-os_release_note.html#pgfId-608107 (http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/61_nx-os_release_note.html#pgfId-608107)
customer does not care, they just want the tick box in the 'firmware not 3 years old' column.
disclaimer: I came along later in the piece, keeping the box going as long as possible with gen 1 modules was not my idea
The GHOST vulnerability affects every NX-OS on the 7K prior to 6.2(12)
The 5.2 train is NS-OS is EOL, last day of software support is 10/29/2015. so no software fixes after that.
Software support will end 10/31/2019.
Cisco recommends 5.2(9a) at a minimum with a preference for 6.2.12
Personally I haven't successfully done ISSU, failed a few times and never trusted for it to work correctly without hitches since.
we're loading up on 6.2.12 here.
what firmware are they running? you might be able to get away with the epld upgrade and a reboot, to check that box.
not sure. Do you have more details re: epld etc.?
rookie to Nexus HW stuff so the more info the merrier.
So when you failed ISSU, what happened, what did you have to do? Did you brick one of the sups?
Was what you attempted on the supported matrix?
I got my figures wrong anyway, he's running 5.2(1) so he has no choice but to ISSU to 5.2(9) anyway, whether he stays there or then goes to 6.x can be a separate decision.
I've never run into an EPLD upgrade but I've heard they take an absolute age...
Quote from: DanC on August 26, 2015, 06:48:40 AM
I've never run into an EPLD upgrade but I've heard they take an absolute age...
I'm not familiar with EPLDs, but they looks similar to FPGAs, and if so, yes they can take a while to upgrade.
We are running two n7k chassis. Have had 0 issues in over a year on this IOS. EPLD upgrade was not required. Upload the new img to your bootflash and issue a: show install all impact epld bootflash:xxxx.img
N7K10-
6.2(8a)
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 48 10/100/1000 Mbps Ethernet XL Module N7K-M148GT-11L ok
2 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
4 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
5 0 Supervisor Module-2 N7K-SUP2 active *
6 0 Supervisor Module-2 N7K-SUP2 ha-standby
7 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
9 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
10 48 10/100/1000 Mbps Ethernet XL Module N7K-M148GT-11L ok
Mod Sw Hw
--- -------------- ------
1 6.2(8a) 1.0
2 6.2(8a) 1.2
4 6.2(8a) 1.3
5 6.2(8a) 3.0
6 6.2(8a) 3.0
7 6.2(8a) 1.3
9 6.2(8a) 1.1
10 6.2(8a) 1.0
N7K9-
6.2(8a)
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor Module-2 N7K-SUP2 active *
2 0 Supervisor Module-2 N7K-SUP2 ha-standby
3 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
4 48 10/100/1000 Mbps Ethernet XL Module N7K-M148GT-11L ok
5 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
6 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
7 48 10/100/1000 Mbps Ethernet XL Module N7K-M148GT-11L ok
8 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
Mod Sw Hw
--- -------------- ------
1 6.2(8a) 3.0
2 6.2(8a) 3.0
3 6.2(8a) 2.0
4 6.2(8a) 1.0
5 6.2(8a) 1.1
6 6.2(8a) 3.1
7 6.2(8a) 1.0
8 6.2(8a) 1.2
thanks. I don't happen to have the same HW as you (SUP1... F1... M1 etc.) but its a good rough guide esp with a bunch of Gen1 v1.x running fine in 6.2(8a) that's a good sign.
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
2 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
3 48 10/100/1000 Mbps Ethernet Module N7K-M148GT-11 ok
4 48 10/100/1000 Mbps Ethernet Module N7K-M148GT-11 ok
5 0 Supervisor Module-1X N7K-SUP1 active *
6 0 Supervisor Module-1X N7K-SUP1 ha-standby
Mod Sw Hw
--- -------------- ------
1 6.2(12) 1.2
2 6.2(12) 1.2
3 6.2(12) 1.9
4 6.2(12) 1.9
5 6.2(12) 2.2
6 6.2(12) 2.2
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
Quote from: ristau5741 on August 27, 2015, 08:30:38 AM
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
I did the first 7010 all in ISSU without incident, the second 7010 I did from 5.1(5) to 6.2(12) due to timing of the maintenance window which did cause an outage but it was a planned outage.
Quote from: mmcgurty on August 27, 2015, 09:31:23 AM
Quote from: ristau5741 on August 27, 2015, 08:30:38 AM
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
wow that's pretty bold, we usually wait a week between upgrading pairs. see if any undocumented issues arise.
I did the first 7010 all in ISSU without incident, the second 7010 I did from 5.1(5) to 6.2(12) due to timing of the maintenance window which did cause an outage but it was a planned outage.
Quote from: mmcgurty on August 27, 2015, 09:31:23 AM
Quote from: ristau5741 on August 27, 2015, 08:30:38 AM
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
I did the first 7010 all in ISSU without incident, the second 7010 I did from 5.1(5) to 6.2(12) due to timing of the maintenance window which did cause an outage but it was a planned outage.
wow that's pretty bold, we usually wait a week between upgrading pairs. see if any undocumented issues arise.
cool! That's great to know.
From my reading no EPLD is mandated (though 'recommended') - was that the case for you?
My current recommendation based on the release notes is as follows
5.2(1) --> 5.2(9)
5.2(9) --> 6.2(8a)
6.2(8a) --> 6.2(12)
Customer may choose to stop ay any stage lol
Quote from: wintermute000 on August 27, 2015, 10:01:07 PM
cool! That's great to know.
From my reading no EPLD is mandated (though 'recommended') - was that the case for you?
In my case over the past year or so, we'll have brought 3 7010's from 4.2(4) to 6.2(12). so we were advised to perform EPLD.
The scariest part of the migration was to 4.2(8) to 5.2(9) where we had to install the 8GB memory module.
Quote from: ristau5741 on August 27, 2015, 10:57:25 AM
Quote from: mmcgurty on August 27, 2015, 09:31:23 AM
Quote from: ristau5741 on August 27, 2015, 08:30:38 AM
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
I did the first 7010 all in ISSU without incident, the second 7010 I did from 5.1(5) to 6.2(12) due to timing of the maintenance window which did cause an outage but it was a planned outage.
wow that's pretty bold, we usually wait a week between upgrading pairs. see if any undocumented issues arise.
This environment is an Hot/Standby for production. During this timeframe we rolled over to our backup site for a few months to test that environment as well. This was still being used but not in the same capacity. We also do completely redundant connections in this environment with VPC's so we can weather these kinds of upgrades when necessary.
@wintermute
FYI Warning: When you upgrade to 6.2(8a) all non cisco transceivers will stop working. Make sure the company is using all cisco transcievers
Quote from: mmcgurty on August 28, 2015, 07:28:45 AM
Quote from: ristau5741 on August 27, 2015, 10:57:25 AM
Quote from: mmcgurty on August 27, 2015, 09:31:23 AM
Quote from: ristau5741 on August 27, 2015, 08:30:38 AM
Quote from: mmcgurty on August 27, 2015, 08:20:42 AM
I upgraded a pair of 7010's with a SUP1 and F1/M1 cards in July from 5.1(5) to 6.2(12) stepping from 5.1(5) to 5.2(7), 5.2(7) to 6.2(2a), 6.2(2a) to 6.2(8a), and finally 6.2(8a) to 6.2(12) without incident. See the output below:
ow, that's painful . Was that all ISSU upgrades?
I did the first 7010 all in ISSU without incident, the second 7010 I did from 5.1(5) to 6.2(12) due to timing of the maintenance window which did cause an outage but it was a planned outage.
wow that's pretty bold, we usually wait a week between upgrading pairs. see if any undocumented issues arise.
This environment is an Hot/Standby for production. During this timeframe we rolled over to our backup site for a few months to test that environment as well. This was still being used but not in the same capacity. We also do completely redundant connections in this environment with VPC's so we can weather these kinds of upgrades when necessary.
LOL I can't even reload a standby supervisor without coordination with the customer, JiC, if there is any..Any..ANY even .000001 percent chance that there could remotely be a possibility of creating an outage. it's a no go...... In the realm of possibilities there is a chance that the primary firewall could possibly fail during the reboot cycle of the standby firewall that would cause an outage, so it's a no-go.
Quote from: LynK on August 28, 2015, 10:01:39 AM
@wintermute
FYI Warning: When you upgrade to 6.2(8a) all non cisco transceivers will stop working. Make sure the company is using all cisco transcievers
Interesting. Does Cisco not require you to use their transceivers? Also, in this scenario, there's no unlock option for 3rd party transceivers?
Quote from: AspiringNetworker on August 28, 2015, 11:03:57 AM
Quote from: LynK on August 28, 2015, 10:01:39 AM
@wintermute
FYI Warning: When you upgrade to 6.2(8a) all non cisco transceivers will stop working. Make sure the company is using all cisco transcievers
Interesting. Does Cisco not require you to use their transceivers? Also, in this scenario, there's no unlock option for 3rd party transceivers?
This is precisely why we only use Cisco purchased SFP's.
Quote from: mmcgurty on August 28, 2015, 11:38:48 AM
Quote from: AspiringNetworker on August 28, 2015, 11:03:57 AM
Quote from: LynK on August 28, 2015, 10:01:39 AM
@wintermute
FYI Warning: When you upgrade to 6.2(8a) all non cisco transceivers will stop working. Make sure the company is using all cisco transcievers
Interesting. Does Cisco not require you to use their transceivers? Also, in this scenario, there's no unlock option for 3rd party transceivers?
This is precisely why we only use Cisco purchased SFP's.
Theerrrrreeee's probably a way they can make it work - question is will a price tag be associated with it. :problem?:
http://info.hummingbirdnetworks.com/blog/cisco-sfp-can-you-use-a-3rd-party-sfp-with-catalyst-switches (http://info.hummingbirdnetworks.com/blog/cisco-sfp-can-you-use-a-3rd-party-sfp-with-catalyst-switches)
(I know you're talking about Nexus... but it probably still applies)
Quote from: LynK on August 28, 2015, 10:01:39 AM
@wintermute
FYI Warning: When you upgrade to 6.2(8a) all non cisco transceivers will stop working. Make sure the company is using all cisco transcievers
Define third party transceivers here... Catalyst switches have the commande 'service unsupported-transceiver' which will make those work but it will still recognize them as third party. Nexus have some SFP vendors who make their SPFs appear as genuine Cisco SFPs.
Is it the latter? In that case: really bad. The vendor will likely have a solution for the new code, but you can forget about ISSU right there.
thanks for the warning. I will note this to the client.
TBH they are sooooo risk averse + we have to already put in a stupid bunch of outages to fix a massive bunch of existing issues that they're probabyl going to just go meh, its working, leave it alone.
The previous engineer had:
Proline 10G transceivers - (CDW)
ao 10G transceivers - advantageoptics.com
There was supposed to be a workaround.... however the command did not work. I think it was a variation of: service unsupported-transceiver
I do not care is teracai or anyone else can emulate cisco genuine SFP. I ALWAYS tell my management team this. You spent 200k on a core switch. Spend the money and make sure everything end-to-end cisco validated and supported.
If you have an issue with a switch, and they check and see that you are not using validated SFPs. Guess what they are going to tell you to change....
Hmmmmm...
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#pgfId-860310 (http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#pgfId-860310)
CSCuo51846
Symptom : I f you have upgraded to Cisco NX-OS Release 6.2(8) and enter the service unsupported-transceiver command to enable third-party transceiver modules, you might see these modules fail.
Conditions : This symptom might be seen when you are using an F3 Series module in Cisco Nexus 7700 Series chassis and running Cisco NX-OS Release 6.2(8).
Workaround : This issue is resolved.
LynK - where did you see the "alert" you posted?
Quote from: AspiringNetworker on September 01, 2015, 10:02:36 AM
Hmmmmm...
Workaround : This issue is resolved.
I bet fixing that is right in behind my "2-factor into multi-context firewall via ASDM" issue ( the one where they have to completely rewrite the ASA code to support)
Quote from: ristau5741 on September 01, 2015, 10:57:12 AM
I bet fixing that is right in behind my "2-factor into multi-context firewall via ASDM" issue ( the one where they have to completely rewrite the ASA code to support)
Not to derail the discussion, but can you elaborate?
-Otanx
hahaha DoD again?
Quote from: Otanx on September 01, 2015, 04:27:53 PM
Quote from: ristau5741 on September 01, 2015, 10:57:12 AM
I bet fixing that is right in behind my "2-factor into multi-context firewall via ASDM" issue ( the one where they have to completely rewrite the ASA code to support)
Not to derail the discussion, but can you elaborate?
-Otanx
Yes DoD again. LOL
You can't two factor into a multicontext ASA via ASDM. Something about since they don't support VPN terminations and the fact that the two-factoring is built into the VPN part of the code to allow for remote access two-factor authentication, it is currently not possible. Discussions with the BU were that an enhancement request was made, and being considered for the next re-write of the code.
@aspiring
what do you mean...
@ristau
...lol
Quote from: LynK on September 02, 2015, 02:52:23 PM
@aspiring
what do you mean...
I mean what's the source of your original post? Where did you hear/see that?