08-01-2022 07:24 PM - edited 08-01-2022 07:25 PM
I'm in the process of planning a migration of a pair of 6296's to 64108s and am trying to clarify a few points from the migration guide that Cisco has published for this process.
The intention with the hardware upgrade process will be to:
Step 7 above is my big question, the migration guide mentions this several times, to re-acknowledge ports, but its not possible to do this on individual ports. Does it mean re-acknowledge the chassis? Is it possible to just re-acknowledge the subordinate connected IOM instead of the whole chassis to avoid touching the active fabric?
Any help and insights are greatly appreciated.
08-03-2022 10:56 AM
When migrating from 62xx to 64xx, the UCSM database will maintain the configuration from the 62xx and apply it to the 64xx. In the event of server ports (and all ports really), this will assume that interface 1/20 for example goes to the same exact device/port that it did prior to migration. Due to how the FC ports move from the end ports to the beginning ports between a 62xx and 64xx, it's possible that some ports will move with respect to their devices. In these cases, some ports may not come up to the chassis. The re-ack step is to re-program the IOM to function on the new ports. For uplink/FC ports, I've only ever needed to flap the ports to bring them back online.
Yes, you can re-ack just the 1 IOM needed by browsing directly to that IOM in UCSM on the Equipment tab and choosing to "Acknowledge IO Module".
Also, I find this guide to be very helpful in the migration process:
03-01-2023 11:02 AM
Thanks for the info above. I had one question on the migration of a 6296 --> 64108. This User Guide: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-manager/GUI-User-Guides/Fabric-Interconnect-Migration/4-1/b_migrating_from_6200_to_6400_4_1/b_Migrating_from_6200_to_6400_4_1_chapter_011.html states that the ports on the 6296 "extended module" that are connected to the 64108 must be re-acknowledged... but the FI ports are never connected directly to each other? Maybe I'm just mis-reading this but the verbage does not seem to make sense.
When migrating from Cisco UCS 6296 Fabric Interconnect to Cisco UCS 64108 Fabric Interconnect, the ports on the 64108 Fabric Interconnect that are connected to the extended module on the 6296 Fabric Interconnect must be reacknowledged.
That being said, even if I have a Server port connected to an extended module on the 6296 (ex. slot 2 / port 1-4) and I'm going to move that to my 64108 (ports 20-24), I only need to re-acknowledge the IO Module that is connected to the 64108 Fabric Interconnect at that time, correct?
Therefore, no chassis connectivity will need to be re-acknowledged (requiring a reboot) at all, correct?
03-01-2023 11:24 AM - edited 03-01-2023 11:24 AM
Expansion Modules function like line cards on a Nexus Switch. They end up with unique numbering. Example Server Port 3/1 will be port 1 on the 3rd module (2nd expansion slot though since the the base ports on the 6296 are technically module 1). On the 64108, there are no additional modules so there is no port 3/1 that is to be programmed as a Server Port. You should expect to have to re-ack so it will build the connectivity between the FI and Chassis.
I find I personally like this white paper a little better on the migration process.
See Step 12 specifically as it should highlight your inquiry.
03-01-2023 01:09 PM
Thank You for the reply jaearl.
So in step 12 it has you re-acknowledge the IOM that is connected to the 64108 Fabric Interconnect once you move the cables from the 6296 over to the 64108. At that point the 64108 Fabric Interconnect is in "subordinate" mode and all data traffic is still going down the 6296 Fabric Interconnect (which is "primary" at the time).
So its not a re-acknowledge of the Chassis itself, just the IO Module whose ports are connected to the Subordinate FI, correct?
I just want to confirm that a re-acknowledge of the Chassis itself is not required, so no blades actually need to get rebooted.
03-01-2023 01:22 PM
That is correct. You would be re-acking the IOM module(s) one at a time on the subordinate FI and not the whole chassis. There should not be an expectation to impact production data flows traversing the Primary FI.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: