07-20-2012 02:41 AM
Hi all, hope one of you can help me out.
I need to swap out the core switch from each of our two fabrics. I am thinking of doing the below but I am unsure if it will work without causing an outage.
First Existing Fabric - 1 x 5100 'core' SAN switch with several blade chassis SAN switches (4024s) plugged into it. Each 4024 has a 2 port trunk to the 5100. Fabric is all WWN based zoning.
Second Existing Fabric is identical.
The new switch is a 6510. All switches have fabric and trunking licenses.
I was hoping the following would work without causing an outage:
1. Add in the 6510 as another switch hanging off the existing 5100 using a two port trunk so it becomes part of the fabric.
2. Swing round the first of the two connections from a 4024 blade switch to the 6510.
3. The trunk should dissolve during the move and become 2 separate connections (one to the 5100 and one to the 6510).
4. Swing the second link round and the trunk should re-establish, but now to the 6510.
5. Repeat for each 4024.
6. At this point all blade switches are connected to new 6510.
7. Make the 6510 the principal switch
8. disconnect the 5100 from the 6510.
9. Move to new switch complete.
10. Repeat for second fabric.
What I am not sure about though is if I will be bale to create the 'loop', (with one leg of the 4024 going up to the 5100 and the other going to the 6510), to prevent an outage (as the 5100 and 6510 are connected at this point). Is this allowed? Will it work ?
Also, how do I determine if the new 6510 can run 6.2.2d FOS like the rest of the fabric? Is there a list of which Fabric OS versions each switch can run ?
07-20-2012 02:55 AM
--->>>Also, how do I determine if the new 6510 can run 6.2.2d FOS...
16G Plattform are only supported by FOS 7.x and cannot be downgrade, however is compatible in the same Fabric with with other switches FOS 6.x, for details refer the 7.x Release Notes.
--->>>Add in the 6510 as another switch hanging off the existing 5100 using a two port trunk....
accord you Post, you want to migrate the 5100 to 6510, i would create a simple ISL instead trunking.
keep in mind 4020 have some FOS restriction earlier 6.2.2e when connected to 16G Platform, is descripted as well in FOS 7 Rel. Notes.
07-20-2012 04:17 AM
What about storage? Are you going to connect these to both the 6510 and 5100 at the same time? Or will you move these after you have moved all the blades? If there is a lot of traffic, maybe the two ISLs between the 6510 and 5100 is not enough.
07-23-2012 05:05 AM
Thanks. I think I will upgrade the 6510 to the latest FOS before I start (7.0.1b) to get as up to date as I can so I have checked the release notes as you mentioned and see the info about the 4024 switches version and QoS caveat.
Is there a reason that you suggest using a single ISL rather than a trunk ?
So do you think my process will work without disconnecting the 4024 from the fabric as I move the two connections from it over (one at a time) to the new 6510 ?
07-23-2012 06:00 AM
--->>> Is there a reason that you suggest using a single ISL rather than a trunk ?
Yes. The reason is that make no sense in a such small Fabric to create a Trunk. More effective maybe is to create dual ISL connection beetwen the Old and New one switch.
--->>> So do you think my process will work without disconnecting the 4024 from the fabric as I move the two connections from it over (one at a time) to the new 6510 ?
There is the same, with or without trunking.
07-23-2012 07:56 AM
Thanks for all the useful advice but I am still unsure if my process will disconnect the 4024 switch from the fabric during the move or not (if I do it one port at a time). Can someone specifically answer that question?
07-25-2012 12:58 AM
Hi, a trunk should stay online if you disconnect one of its members.
If you want to be extra sure you could make sure to not disconnect the master in each trunk - see output of CLI command: trunkshow.
08-09-2012 05:39 AM
Just connect the new switch as another member of fabric and move connection on by one , I mean the host and storage. Also use ISL link from same port group so that you will have proper load balance and redudant path in case of issue.