12-02-2012 06:46 AM
i am stuck in a problem bringing up an isl
here is the scenario:
we have an existing hp c-class bladecenter with 2 brocade 4/12 fc interconnects. by historical reasons the 2 switches work as seperated fabrics. they connect esx-servers running on blades to storage connected by the external links. both switches run in switch-mode (not access gateway) and hold their own zoneconfig.
as our environment is growing we decided to buy some new standalone-servers and 2 brocade 300 san switches.
now i want to connect the new switches to these in the bladecenter to make the storage visible to the new servers.
i want to avoid a merge of the fabrics as it is extremely difficult to schedule downtime for the whole system. following the advice of a buddy, i thought it would be a good idea to disable "e-port" on the isl-ports of the switches to avoid auto-fabridmerge and then to configure zones containing the appropriate server/storage- and isl-ports.
well, it turns out, that plan does not work, the islports show up as g-ports now and no connectivity comes up.
i have been searching the internet for ages and found tons of documents about merging fabrics, but nothing that would help me out.
i would appreciate any help about how to connect switches and configure cross-switch-zoning the right way without beeing forced to do a fabric-merge or how to merge zones without interruption of connectivity (i read that merging always brings down connectivity for a few seconds while recreating the zone-db)
thanks for your time and help in advance
12-02-2012 07:42 AM
If you want to "uplink" BTW, correct definition is ISL = Inter Switch Link, and don't want to merge the Fabric, such is possible only with IR = Intergrated Routing or FCR = Fibre Channel Routing Capable Swithes.
Brocade 300 is not IR capable.
12-02-2012 07:58 AM
thnaks for your reply.
well, not good... what would be the right way, to bring that stuff to work? is there any chance to avoid merging?
i also thought about creating 2 fabrics, each consisting of one bladesw and one standalone-sw. but then i am concerned of loosing the cfg, because the bladeswitches hold a big zone-db, but the older firmware (on these models the latest supported sw is 6.2.2.f, the newer standalonswitches are on 7.0.0.c). i read the switch with the newer firmware should be selected as principal.
i read so many docs about zonemerging the last days that i really feel confused about all that stuff...
12-02-2012 08:15 AM
--->>> is there any chance to avoid merging?
no sorry, any such is unkown to me. However, depend you Budget, a Used Brocade 7500 would be a great option.
--->>> i read the switch with the newer firmware should be selected as principal.
"should be" but must not, is another story.
I have some situation by diverse Customer, and the config is mantained by old Switch.
12-02-2012 09:01 AM
from you initial post
--->>>i would appreciate .../.....or how to merge zones without interruption of connectivity
what is the reason you want to ISL both Brocade 300 ?
config merge is very simple, and no disruptive.
the Bladecenter should be continued to have access to the Storage ?
--->>>we decided to buy some new standalone-servers
you can figure out NEW separate Zone in Brocade 300 for all those new Server, and present from the same Storage a own ( not shared ) LUN.
12-02-2012 09:25 AM
> i also thought about creating 2 fabrics, each consisting of one bladesw and one standalone-sw.
that's the way I would do it.
> but then i am concerned of loosing the cfg, because the bladeswitches hold a big zone-db, but the older firmware
You can only merge a switch with an empty (or same) zone-db into a fabric. The switch will then get the zone-db from the fabric, independent of the firmware version.
But you should have a look if the two versions are compatible.
12-03-2012 12:47 AM
thanks for your replies.
presenting seperated luns to tghe new servers is not possible, as it is an esxcluster and all servers need access to the same luns.
i read, that merging IS disruptive, as the zonedb is brought down and up. if this is not true, that would be a great help. can you confirm, that merging an empty switch to a switch with a config will niot interrupt hostaccess for e few seconds?
anyway, i think the idea with 2 fabitcs seems the best way. i can take one bladeswitch offline (disable hostports, as multipathing is correctly configured on the hosts), do a merge with one standalone-brocade, check everything and then enable the ports again. then doing the same with the other switches. (firmware releases are checked according to hp guidlines)
just wondering, if i will then ever find time and way to merge them all together to one fabric...
btw, another question: why are those blade-interconnects not delivered with an internal isl?? is there any way to merge them except connecting them by a cable through the external ports?
12-04-2012 10:41 PM
Yes, I'm sorry, you are correct. I went back and read the FAQ and they do not in fact mention the 300 when talking about IRL. My sales person/engineer lead me to believe that the new switches all had the routing capability. Thank you for correcting me. IRL will work on the 5100 on up.