Regarding the RCF install guide https://docs.netapp.com/us-en/ontap-systems-switches/switch-cisco-9336c-fx2/install-rcf-software-9336c-cluster.html#step-1-install-the-rcf-on-the-switches
In step 11; why am I erasing the config I just put in?
#Question regarding cluster switch setup
rugged dew
errant flicker
you're deleting the running config and then copying in the config you created as write_erase.cfg earlier, to ensure you are using the correct config at startup
dusk mantle
no, you're deleting the startup-config (notice that it says " This command will erase the startup-configuration"), and then you copy over the saved file as new startup-config and reboot
you basically want to ensure that it will come back up with a sane config (mgmt IPs and all) so that you don't have to completely re-configure the switch from serial
rugged dew
im probably missing something, but if i follow the steps 1-15 as shown i end up with an unconfigured switch, except for the few bits set in the write_erase.cfg
i guess im confused because in steps 3-7 the applied rcf config is copied to startup
this would make sense to me if i were umaybe updating the config
dusk mantle
yeah, you're right, the complete sequence of steps doesn't make any sense
@lone roost I think this is still the issue we talked about a while back... The one Andre ran into. seems it hasn't been fixed yet
thin ermine
In steps 8 and 9 you are saving the mgmt connectivity info off to the bootflash partition which isn't wiped when you issue "write erase". Then you copy "bootflash:write_erase.cfg" back to the startup-config and reload (steps 12/13). The switch comes up with your mgmt ip/port configured allowing you to reconnect/ssh to the switch without having to use a console connection. Good option for environments who don't have remote console options in place.
lone roost
DAMNIT!
I had those directions fixed at one point and they’ve gone and broken them again?
I know the process that I just do it. I don’t through the docs anymore.
I know a couple years ago they forgot to disable auto revert and that was a shit show when the switches rebooted without any proper rcf!
dusk mantle
In steps 8 and 9 you are saving the mgmt connectivity info off to the bootflash...
yes but you end up with a config that has only your config stuff in it and not the rest of the RCF..
lone roost
I’ll see about reviewing again and demanding proper corrections
lone roost
Unfortunately there are two areas. The install and the upgrade and they routinely suffer from copy/paste errors
dusk mantle
yeah, I think Andre already put in a doc change request but apparently nothing has been done so far
lone roost
OK. just sent email off. I found a few things.
Steps 11-13 are certainly not needed and appeared copied from the upgrade section
Modify Step 14 to be step 11 and refer to steps 1-10 (not 1-13)
On the RCF upgrade, asked to modify "net port show -role..." to "net port show -ipspace Cluster" (since -role is and has been deprecated for a while)
ALso asked to modify the "net int show -role cluster" to "net int show -vserver Cluster"...again since "-role" is deprecated.
Also indicated that the docs USED TO have you set auto-revert to true on Cluster LIFs and then reboot cs2 to basically force ONTAP to see the link change and send the LIFs back home. I asked to see about adding in step 22 to reboot cs2
Just for kicks. I looked at the other sections. How funny
The "Storage" switch section really wants you to check/verify the same cluster connections as the normal config. Why? there are ZERO cluster LIFs hitting this config!
And the Shared config...
well...all three (Storage, Shared, Cluster) all suffer from the "wipe config, reboot, done" bug.
I have asked this to be looked at asap and get corrected
dusk mantle
thanks. I hope we can get this fixed, it's been broken apparently since quite a while now
lone roost
I got a case number. And I’ve alerted a few individuals that may be able to push it along
I was floored looking at the storage switch section. Like: did someone even actually read this with the concept of the switches being used for just storage?
Also makes me wonder if any q/a has been done in the shared section.
Honestly, I’ve a bunch of shrewd switches in production with customers. I just follow the regular switch update (when it’s correct) and it seems fine
lone roost
@dusk mantle -> you are welcome...I got the docs "fixed" for the cluster/shared. Engineering needs to still fix the Storage section and apparently the Shared section also
I will need to further review, but they did remove/update the critical sections
rugged dew
Piggy backing onto my thread with another question; since its somewhat related.
In Step 2, the procedure does not explicitly state that cluster LIFs should be reverted back to their home ports before proceeding to the next set of ports. The guide appears to rely on ONTAP detecting link-down events and automatically failing the lifs over.
However the NX9336C-FX2 cluster RCF banner notes that under certain conditions the switch may not correctly auto-negotiate port speed, requiring manual configuration.
Given this, would it be more appropriate to noshut the newly connected switch ports and manually revert the cluster LIFs to their home ports before continuing on to the next set? This would allow verification that each switch port is operational and negotiating correctly before moving on, and may reduce the risk of encountering issues if manual port-speed configuration is required.