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.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.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?
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 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 J