NX-OS ISSU 5 to latest 5 or 6?

Started by wintermute000, August 24, 2015, 05:31:24 AM

Previous topic - Next topic

LynK

@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
Sys Admin: "You have a stuck route"
            Me: "You have an incorrect Default Gateway"

icecream-guy

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.
:professorcat:

My Moral Fibers have been cut.

NetworkGroover

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?
Engineer by day, DJ by night, family first always

mmcgurty

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.

NetworkGroover

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

(I know you're talking about Nexus... but it probably still applies)
Engineer by day, DJ by night, family first always

Reggle

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.

wintermute000

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.

LynK

#22
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....
Sys Admin: "You have a stuck route"
            Me: "You have an incorrect Default Gateway"

NetworkGroover

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

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?
Engineer by day, DJ by night, family first always

icecream-guy

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)
:professorcat:

My Moral Fibers have been cut.

Otanx

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

wintermute000


icecream-guy

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.

:professorcat:

My Moral Fibers have been cut.

LynK

#28
@aspiring

what do you mean...

@ristau

...lol
Sys Admin: "You have a stuck route"
            Me: "You have an incorrect Default Gateway"

NetworkGroover

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?
Engineer by day, DJ by night, family first always