Yep. internal burt, but a burt none the less. save them from digging it up. Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser <AGriesser@anexia-it.com
wrote:
Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com] *Gesendet:* Samstag, 8. April 2017 14:05 *An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options:
- Open a support case with netapp and refer to the BURT 1050364 / Case
2006580487
- The ultimate fix that I did was this:
-> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize.
-> Convert to in-band. Wait for it to stabilize and confirm IN-Band
-> Convert to out-of-band and upgrade to 2.10 firmware.
-> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%.
If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
On Sat, Apr 8, 2017 at 5:55 AM, Alexander Griesser < AGriesser@anexia-it.com> wrote:
Hey Toasters,
I’ve just upgraded one of my HA-pairs to 9.1P2 and wanted to switch to ACP inband connectivity following this KB:
https://kb.netapp.com/support/s/article/ka31A00000012NsQAI/ in-band-acp-setup-and-support
According to this KB, I should be eligible for the switch:
::*> storage shelf acp module show -fields module-name,protocol-version, firmware-version,shelf-serial-number,iom-type,state
node module-name protocol-version firmware-version shelf-serial-number iom-type state
nodeA 1.22.B 1.2.02.10 02.10 SHJMS1424000060 iom6 active
nodeA 1.22.A 1.2.02.10 02.10 SHJMS1424000060 iom6 active
nodeA 2.11.A 1.2.02.10 02.10 SHFMS1423000507 iom6 active
nodeA 2.11.B 1.2.02.10 02.10 SHFMS1423000507 iom6 active
nodeA 2.14.B 1.2.02.10 02.10 SHFMS1423000491 iom6 active
nodeA 2.14.A 1.2.02.10 02.10 SHFMS1423000491 iom6 active
nodeA 2.12.A 1.2.02.10 02.10 SHFMS1423000493 iom6 active
nodeA 2.12.B 1.2.02.10 02.10 SHFMS1423000493 iom6 active
nodeA 2.13.A 1.2.02.10 02.10 SHFMS1423000504 iom6 active
nodeA 2.13.B 1.2.02.10 02.10 SHFMS1423000504 iom6 active
nodeA 1.21.B 1.2.02.10 02.10 SHJMS1424000434 iom6 active
nodeA 1.21.A 1.2.02.10 02.10 SHJMS1424000434 iom6 active
nodeB
1.22.B 1.2.02.10 02.10 SHJMS1424000060iom6 active
nodeB
1.22.A 1.2.02.10 02.10 SHJMS1424000060iom6 active
nodeB
2.11.A 1.2.02.10 02.10 SHFMS1423000507iom6 active
nodeB
2.11.B 1.2.02.10 02.10 SHFMS1423000507iom6 active
nodeB
2.14.B 1.2.02.10 02.10 SHFMS1423000491iom6 active
nodeB
2.14.A 1.2.02.10 02.10 SHFMS1423000491iom6 active
nodeB
2.12.A 1.2.02.10 02.10 SHFMS1423000493iom6 active
nodeB
2.12.B 1.2.02.10 02.10 SHFMS1423000493iom6 active
nodeB
2.13.A 1.2.02.10 02.10 SHFMS1423000504iom6 active
nodeB
2.13.B 1.2.02.10 02.10 SHFMS1423000504iom6 active
nodeB
1.21.B 1.2.02.10 02.10 SHJMS1424000434iom6 active
nodeB
1.21.A 1.2.02.10 02.10 SHJMS1424000434iom6 active
24 entries were displayed.
The requirements state that the IOM6 modules must be upgraded to 2.09 (I have 2.10) and ACP firmware must be at least 1.2.2.9 (I have 1.2.2.10).
So I went ahead and ran this command:
storage shelf acp configure -is-enabled true -channel *in-band*
After a few minutes, I saw this:
::*> storage shelf acp show
Node Channel Connectivity
nodeA in-band active
nodeB in-band active
2 entries were displayed.
But when I ran the initial check command again, I saw this output:
::*> storage shelf acp module show -fields module-name,protocol-version, firmware-version,shelf-serial-number,iom-type,state
node module-name protocol-version firmware-version shelf-serial-number iom-type state
nodeA 1.22.B 1.2.02.10 02.10 SHJMS1424000060 iom6 firmware-update-required
nodeA 1.22.A 1.2.02.10 02.10 SHJMS1424000060 iom6 firmware-update-required
nodeA 2.11.A 1.2.02.10 02.10 SHFMS1423000507 iom6 firmware-update-required
nodeA 2.11.B 1.2.02.10 02.10 SHFMS1423000507 iom6 firmware-update-required
nodeA 2.14.B 1.2.02.10 02.10 SHFMS1423000491 iom6 firmware-update-required
nodeA 2.14.A 1.2.02.10 02.10 SHFMS1423000491 iom6 firmware-update-required
nodeA 2.12.A 1.2.02.10 02.10 SHFMS1423000493 iom6 firmware-update-required
nodeA 2.12.B 1.2.02.10 02.10 SHFMS1423000493 iom6 firmware-update-required
nodeA 2.13.A 1.2.02.10 02.10 SHFMS1423000504 iom6 firmware-update-required
nodeA 2.13.B 1.2.02.10 02.10 SHFMS1423000504 iom6 firmware-update-required
nodeA 1.21.B 1.2.02.10 02.10 SHJMS1424000434 iom6 firmware-update-required
nodeA 1.21.A 1.2.02.10 02.10 SHJMS1424000434 iom6 firmware-update-required
nodeB
1.22.B 1.2.02.10 02.10 SHJMS1424000060iom6 firmware-update-required
nodeB
1.22.A 1.2.02.10 02.10 SHJMS1424000060iom6 firmware-update-required
nodeB
2.11.A 1.2.02.10 02.10 SHFMS1423000507iom6 firmware-update-required
nodeB
2.11.B 1.2.02.10 02.10 SHFMS1423000507iom6 firmware-update-required
nodeB
2.14.B 1.2.02.10 02.10 SHFMS1423000491iom6 firmware-update-required
nodeB
2.14.A 1.2.02.10 02.10 SHFMS1423000491iom6 firmware-update-required
nodeB
2.12.A 1.2.02.10 02.10 SHFMS1423000493iom6 firmware-update-required
nodeB
2.12.B 1.2.02.10 02.10 SHFMS1423000493iom6 firmware-update-required
nodeB
2.13.A 1.2.02.10 02.10 SHFMS1423000504iom6 firmware-update-required
nodeB
2.13.B 1.2.02.10 02.10 SHFMS1423000504iom6 firmware-update-required
nodeB
1.21.B 1.2.02.10 02.10 SHJMS1424000434iom6 firmware-update-required
nodeB
1.21.A 1.2.02.10 02.10 SHJMS1424000434iom6 firmware-update-required
24 entries were displayed.
Out of curiosity, I tried to run the ACP update again:
nodeB> storage download acp
Downloading ACP firmware can take several minutes
and will not disrupt client access during that time.
However, normal ACP recovery capabilities will not be
available while the firmware upgrade is in progress.
Are you sure you want to continue with ACP processor firmware update? y
[storage download acp] Firmware will not be downloaded to module 2b.14.B as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0a.14.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0b.21.B as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0a.13.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0a.12.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 2a.21.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 2b.12.B as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 2b.13.B as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0b.22.B as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 2a.22.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 0a.11.A as ACPP state is not active, Current ACPP state is 0x9.
[storage download acp] Firmware will not be downloaded to module 2b.11.B as ACPP state is not active, Current ACPP state is 0x9.
nodeB> exit
Eventlog also said, that a FW Upgrade is required:
::*> event log show -severity infORMATIONAL
Time Node Severity Event
4/8/2017 11:41:15 nodeB INFORMATIONAL sfu.firmwareUpToDate: Firmware is up-to-date on all disk shelves.
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000507).
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000504).
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000491).
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000493).
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHJMS1424000060).
4/8/2017 11:39:37 nodeA INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHJMS1424000434).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000493).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000504).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000507).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHFMS1423000491).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHJMS1424000434).
4/8/2017 11:39:37 nodeB INFORMATIONAL acp.need.firmware.update: ACP module (NA) needs a firmware upgrade, (disk shelf serial number: SHJMS1424000060).
I then switched back to OOB connectivity, and all is good again:
::*> storage shelf acp show
Node Channel Connectivity
nodeA out-of-band full-connectivity
nodeB out-of-band full-connectivity
2 entries were displayed.
Tried to run the ACP upgrade again, getting this:
nodeB> storage download acp
Downloading ACP firmware can take several minutes
and will not disrupt client access during that time.
However, normal ACP recovery capabilities will not be
available while the firmware upgrade is in progress.
Are you sure you want to continue with ACP processor firmware update? y
[storage download acp] ACP will check 12 modules for firmware download.
[storage download acp] ACP module 192.168.0.124 is not eligible for update.
[storage download acp] ACP module 192.168.0.126 is not eligible for update.
[storage download acp] ACP module 192.168.0.180 is not eligible for update.
[storage download acp] ACP module 192.168.0.202 is not eligible for update.
[storage download acp] ACP module 192.168.0.208 is not eligible for update.
[storage download acp] ACP module 192.168.0.248 is not eligible for update.
[storage download acp] ACP module 192.168.1.112 is not eligible for update.
[storage download acp] ACP module 192.168.1.170 is not eligible for update.
[storage download acp] ACP module 192.168.1.238 is not eligible for update.
[storage download acp] ACP module 192.168.2.66 is not eligible for update.
[storage download acp] ACP module 192.168.3.130 is not eligible for update.
[storage download acp] ACP module 192.168.3.138 is not eligible for update.
nodeB> exit
And now I’m back at the starting point.
Any ideas what’s going on here? Why does it tell me „firmware-update-required“ when I’m already on the latest versions?
Thanks,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Yah, no worries, I have time and endurance for things like that ☺ No rush here on my end.
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 19:17 An: Alexander Griesser AGriesser@anexia-it.com Cc: toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
Yep. internal burt, but a burt none the less. save them from digging it up. Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.commailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 14:05 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options: 1. Open a support case with netapp and refer to the BURT 1050364 / Case 2006580487 2. The ultimate fix that I did was this: -> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize. -> Convert to in-band. Wait for it to stabilize and confirm IN-Band -> Convert to out-of-band and upgrade to 2.10 firmware. -> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%. If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
[ stripping my own post due to size limitations on this mailing list ]
The thing is, they wanted to close the issue already telling me to subscribe to the BURT and get the info from there once it’s solved. Anyways, I talked with support on the phone and he was reading your instructions down there and said that we should try that.
I’m not really sure how to downgrade ACP to a specific version, I’ve downloaded 2.09 and installed it, but it’s not really using it for the installation. What I can do is I can revert to the version shipped with Ontap 9.1P2, which is what I did now by running:
storage download acp –R
but it did only install FW 2.10 again, but afterwards, it looked like this:
Node Module Name State ----------------- ----------------- ---------------------- nodeA 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active nodeB 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active 24 entries were displayed.
So I thought let’s do this again and it will fix the other half of the ACPs too, but it didn’t. But at least half of them are fixed now ☺
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Alexander Griesser Gesendet: Samstag, 8. April 2017 19:20 An: tmac tmacmd@gmail.com Cc: toasters@teaparty.net Betreff: AW: Switching to ACP inband connectivity
Yah, no worries, I have time and endurance for things like that ☺ No rush here on my end.
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 19:17 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
Yep. internal burt, but a burt none the less. save them from digging it up. Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.commailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 14:05 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options: 1. Open a support case with netapp and refer to the BURT 1050364 / Case 2006580487 2. The ultimate fix that I did was this: -> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize. -> Convert to in-band. Wait for it to stabilize and confirm IN-Band -> Convert to out-of-band and upgrade to 2.10 firmware. -> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%. If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
[ stripping my own post due to size limitations on this mailing list ]
Well, thats a bummer! I was fooling around on 9.0. The shipping version for ACP was 2.09, I was able to go back. I would say...don't spend a lot of time with it. Your best bet is to simply leave ACP out-of-band.
I was not at all successful in doing anything until I got the FW back to 2.09.
I guess you could try running the "storage download acp –R" on both nodes to make sure?
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
On Fri, Apr 14, 2017 at 12:56 PM, Alexander Griesser < AGriesser@anexia-it.com> wrote:
The thing is, they wanted to close the issue already telling me to subscribe to the BURT and get the info from there once it’s solved.
Anyways, I talked with support on the phone and he was reading your instructions down there and said that we should try that.
I’m not really sure how to downgrade ACP to a specific version, I’ve downloaded 2.09 and installed it, but it’s not really using it for the installation.
What I can do is I can revert to the version shipped with Ontap 9.1P2, which is what I did now by running:
storage download acp –R
but it did only install FW 2.10 again, but afterwards, it looked like this:
Node Module Name State
nodeA 1.22.B firmware-update-required
1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A activenodeB 1.22.B firmware-update-required
1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active24 entries were displayed.
So I thought let’s do this again and it will fix the other half of the ACPs too, but it didn’t.
But at least half of them are fixed now J
Best,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] *Im Auftrag von *Alexander Griesser *Gesendet:* Samstag, 8. April 2017 19:20 *An:* tmac tmacmd@gmail.com *Cc:* toasters@teaparty.net *Betreff:* AW: Switching to ACP inband connectivity
Yah, no worries, I have time and endurance for things like that J No rush here on my end.
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com tmacmd@gmail.com] *Gesendet:* Samstag, 8. April 2017 19:17 *An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
Yep. internal burt, but a burt none the less. save them from digging it up.
Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser < AGriesser@anexia-it.com> wrote:
Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com] *Gesendet:* Samstag, 8. April 2017 14:05 *An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options:
- Open a support case with netapp and refer to the BURT 1050364 / Case
2006580487
- The ultimate fix that I did was this:
-> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize.
-> Convert to in-band. Wait for it to stabilize and confirm IN-Band
-> Convert to out-of-band and upgrade to 2.10 firmware.
-> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%.
If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
[ stripping my own post due to size limitations on this mailing list ]
Yah, I’d love to stay with OOB if possible, but AFAIK, you’re not allowed to mix ACP modes within a 4-node cluster f.ex. and I have to add a pair of AFF-A300s to this existing 2-node cluster and they do not have OOB-ACP anymore :-/ Will try to revert on the second controller, let’s see if that helps. Can’t hurt.
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Freitag, 14. April 2017 19:28 An: Alexander Griesser AGriesser@anexia-it.com Cc: toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
Well, thats a bummer! I was fooling around on 9.0. The shipping version for ACP was 2.09, I was able to go back. I would say...don't spend a lot of time with it. Your best bet is to simply leave ACP out-of-band.
I was not at all successful in doing anything until I got the FW back to 2.09.
I guess you could try running the "storage download acp –R" on both nodes to make sure?
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Fri, Apr 14, 2017 at 12:56 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: The thing is, they wanted to close the issue already telling me to subscribe to the BURT and get the info from there once it’s solved. Anyways, I talked with support on the phone and he was reading your instructions down there and said that we should try that.
I’m not really sure how to downgrade ACP to a specific version, I’ve downloaded 2.09 and installed it, but it’s not really using it for the installation. What I can do is I can revert to the version shipped with Ontap 9.1P2, which is what I did now by running:
storage download acp –R
but it did only install FW 2.10 again, but afterwards, it looked like this:
Node Module Name State ----------------- ----------------- ---------------------- nodeA 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active nodeB 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active 24 entries were displayed.
So I thought let’s do this again and it will fix the other half of the ACPs too, but it didn’t. But at least half of them are fixed now ☺
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] Im Auftrag von Alexander Griesser Gesendet: Samstag, 8. April 2017 19:20 An: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: AW: Switching to ACP inband connectivity
Yah, no worries, I have time and endurance for things like that ☺ No rush here on my end.
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 19:17 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
Yep. internal burt, but a burt none the less. save them from digging it up. Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.commailto:tmacmd@gmail.com] Gesendet: Samstag, 8. April 2017 14:05 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options: 1. Open a support case with netapp and refer to the BURT 1050364 / Case 2006580487 2. The ultimate fix that I did was this: -> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize. -> Convert to in-band. Wait for it to stabilize and confirm IN-Band -> Convert to out-of-band and upgrade to 2.10 firmware. -> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%. If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
[ stripping my own post due to size limitations on this mailing list ]
I thought it was per HA-pair since those are the ones actually talking to the disks. Someone can certainly correct me on that....but on the surface, that sounds incorrect (ACP the same across 4 nodes, not a HA pair)
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
On Fri, Apr 14, 2017 at 1:30 PM, Alexander Griesser <AGriesser@anexia-it.com
wrote:
Yah, I’d love to stay with OOB if possible, but AFAIK, you’re not allowed to mix ACP modes within a 4-node cluster f.ex. and I have to add a pair of AFF-A300s to this existing 2-node cluster and they do not have OOB-ACP anymore :-/
Will try to revert on the second controller, let’s see if that helps. Can’t hurt.
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com] *Gesendet:* Freitag, 14. April 2017 19:28
*An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
Well, thats a bummer!
I was fooling around on 9.0. The shipping version for ACP was 2.09, I was able to go back.
I would say...don't spend a lot of time with it. Your best bet is to simply leave ACP out-of-band.
I was not at all successful in doing anything until I got the FW back to 2.09.
I guess you could try running the "storage download acp –R" on both nodes to make sure?
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
On Fri, Apr 14, 2017 at 12:56 PM, Alexander Griesser < AGriesser@anexia-it.com> wrote:
The thing is, they wanted to close the issue already telling me to subscribe to the BURT and get the info from there once it’s solved.
Anyways, I talked with support on the phone and he was reading your instructions down there and said that we should try that.
I’m not really sure how to downgrade ACP to a specific version, I’ve downloaded 2.09 and installed it, but it’s not really using it for the installation.
What I can do is I can revert to the version shipped with Ontap 9.1P2, which is what I did now by running:
storage download acp –R
but it did only install FW 2.10 again, but afterwards, it looked like this:
Node Module Name State
nodeA 1.22.B firmware-update-required
1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A activenodeB 1.22.B firmware-update-required
1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active24 entries were displayed.
So I thought let’s do this again and it will fix the other half of the ACPs too, but it didn’t.
But at least half of them are fixed now J
Best,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] *Im Auftrag von *Alexander Griesser *Gesendet:* Samstag, 8. April 2017 19:20 *An:* tmac tmacmd@gmail.com *Cc:* toasters@teaparty.net *Betreff:* AW: Switching to ACP inband connectivity
Yah, no worries, I have time and endurance for things like that J No rush here on my end.
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com tmacmd@gmail.com] *Gesendet:* Samstag, 8. April 2017 19:17 *An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
Yep. internal burt, but a burt none the less. save them from digging it up.
Let us know how you make out. I was under a crunch putting a system into production and could not fool around with it any more.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
On Sat, Apr 8, 2017 at 12:29 PM, Alexander Griesser < AGriesser@anexia-it.com> wrote:
Alright, thanks – I’m opening a case now, cannot see the details of the BURT, though, but will refer support to it.
Best,
*Alexander Griesser*
Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.com
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
*Von:* tmac [mailto:tmacmd@gmail.com] *Gesendet:* Samstag, 8. April 2017 14:05 *An:* Alexander Griesser AGriesser@anexia-it.com *Cc:* toasters@teaparty.net *Betreff:* Re: Switching to ACP inband connectivity
I have seen this! Support was unable to reproduce for me. I will dig up a case number later if you like.
I will give you two options:
- Open a support case with netapp and refer to the BURT 1050364 / Case
2006580487
- The ultimate fix that I did was this:
-> Downgrade *all* IOM firmware to 2.09. Wait for it to stabilize.
-> Convert to in-band. Wait for it to stabilize and confirm IN-Band
-> Convert to out-of-band and upgrade to 2.10 firmware.
-> Wait for it to stabilize and then convert to out-of-band
I got to believe there may be some race condition where the 2.08 -> 2.10 firmware is not completing 100%.
If you use the out-of-band, all looks ok, but switch to in-band and not so much.
The thought is something special happens on 2.09 that fixes everything allowing the upgrade to 2.10
If possible, please open a case and refer to the data above. I think it is in everyones best interest NetApp gets to the bottom of this to fix.
Thanks
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at **TMACsRack https://tmacsrack.wordpress.com/*
[ stripping my own post due to size limitations on this mailing list ]
Nice.
::> storage shelf acp module show -fields module-name,protocol-version,firmware-version,shelf-serial-number,iom-type,state node module-name protocol-version firmware-version shelf-serial-number iom-type state ------- ----------- ---------------- ---------------- ------------------- -------- ------ nodeA 1.22.B 1.2.02.10 02.10 SHJMS1424000060 iom6 active nodeA 1.22.A 1.2.02.10 02.10 SHJMS1424000060 iom6 active nodeA 2.11.A 1.2.02.10 02.10 SHFMS1423000507 iom6 active nodeA 2.11.B 1.2.02.10 02.10 SHFMS1423000507 iom6 active nodeA 2.14.B 1.2.02.10 02.10 SHFMS1423000491 iom6 active nodeA 2.14.A 1.2.02.10 02.10 SHFMS1423000491 iom6 active nodeA 2.12.A 1.2.02.10 02.10 SHFMS1423000493 iom6 active nodeA 2.12.B 1.2.02.10 02.10 SHFMS1423000493 iom6 active nodeA 2.13.A 1.2.02.10 02.10 SHFMS1423000504 iom6 active nodeA 2.13.B 1.2.02.10 02.10 SHFMS1423000504 iom6 active nodeA 1.21.B 1.2.02.10 02.10 SHJMS1424000434 iom6 active nodeA 1.21.A 1.2.02.10 02.10 SHJMS1424000434 iom6 active nodeB 1.22.B 1.2.02.10 02.10 SHJMS1424000060 iom6 active nodeB 1.22.A 1.2.02.10 02.10 SHJMS1424000060 iom6 active nodeB 2.11.A 1.2.02.10 02.10 SHFMS1423000507 iom6 active nodeB 2.11.B 1.2.02.10 02.10 SHFMS1423000507 iom6 active nodeB 2.14.B 1.2.02.10 02.10 SHFMS1423000491 iom6 active nodeB 2.14.A 1.2.02.10 02.10 SHFMS1423000491 iom6 active nodeB 2.12.A 1.2.02.10 02.10 SHFMS1423000493 iom6 active nodeB 2.12.B 1.2.02.10 02.10 SHFMS1423000493 iom6 active nodeB 2.13.A 1.2.02.10 02.10 SHFMS1423000504 iom6 active nodeB 2.13.B 1.2.02.10 02.10 SHFMS1423000504 iom6 active nodeB 1.21.B 1.2.02.10 02.10 SHJMS1424000434 iom6 active nodeB 1.21.A 1.2.02.10 02.10 SHJMS1424000434 iom6 active 24 entries were displayed.
::> storage shelf acp show Node Channel Connectivity ------------------ --------------- ---------------------- nodeA in-band active nodeB in-band active 2 entries were displayed.
tl;dr: Upon seeing the initial semi-working state after switching to in-band ACP (as outlined in my first post in this thread), this is what has helped in my situation:
1. Switch back to out-of-band ACP
storage shelf acp configure –is-enabled true –channel out-of-band
2. Wait for it to stabilize
3. „Revert“ ACP firmware on nodeA (login to this node directly)
node run local storage download acp –R
4. Wait for it to stabilize
5. „Revert“ ACP firmware on nodeB (login to this node directly)
node run local stroage download acp –R
6. Wait for it to stabilize
7. Switch to in-band ACP
storage shelf acp configure –is-enabled true –channel in-band
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: Alexander Griesser Gesendet: Freitag, 14. April 2017 19:30 An: 'tmac' tmacmd@gmail.com Cc: toasters@teaparty.net Betreff: AW: Switching to ACP inband connectivity
Yah, I’d love to stay with OOB if possible, but AFAIK, you’re not allowed to mix ACP modes within a 4-node cluster f.ex. and I have to add a pair of AFF-A300s to this existing 2-node cluster and they do not have OOB-ACP anymore :-/ Will try to revert on the second controller, let’s see if that helps. Can’t hurt.
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: tmac [mailto:tmacmd@gmail.com] Gesendet: Freitag, 14. April 2017 19:28 An: Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: Switching to ACP inband connectivity
Well, thats a bummer! I was fooling around on 9.0. The shipping version for ACP was 2.09, I was able to go back. I would say...don't spend a lot of time with it. Your best bet is to simply leave ACP out-of-band.
I was not at all successful in doing anything until I got the FW back to 2.09.
I guess you could try running the "storage download acp –R" on both nodes to make sure?
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Fri, Apr 14, 2017 at 12:56 PM, Alexander Griesser <AGriesser@anexia-it.commailto:AGriesser@anexia-it.com> wrote: The thing is, they wanted to close the issue already telling me to subscribe to the BURT and get the info from there once it’s solved. Anyways, I talked with support on the phone and he was reading your instructions down there and said that we should try that.
I’m not really sure how to downgrade ACP to a specific version, I’ve downloaded 2.09 and installed it, but it’s not really using it for the installation. What I can do is I can revert to the version shipped with Ontap 9.1P2, which is what I did now by running:
storage download acp –R
but it did only install FW 2.10 again, but afterwards, it looked like this:
Node Module Name State ----------------- ----------------- ---------------------- nodeA 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active nodeB 1.22.B firmware-update-required 1.22.A firmware-update-required 2.11.A active 2.11.B firmware-update-required 2.14.B active 2.14.A active 2.12.A active 2.12.B firmware-update-required 2.13.A active 2.13.B firmware-update-required 1.21.B active 1.21.A active 24 entries were displayed.
So I thought let’s do this again and it will fix the other half of the ACPs too, but it didn’t. But at least half of them are fixed now ☺
-
Alexander Griesser -
tmac