Best practice for ISL between switches

i do not have those specific switches, we use Cisco MDS but the idea is the same. Two ISL for each fabric that take different paths, if you can trunk those into one link that would be even better. if one link goes down in the trunk (fiber cut between DC, hosts never know.

Given this scenario my very first question would be "Why do you need the fabrics to span data centers?" Depending on the answer to that question their may be a better way to do it using FC Routing. But for the moment I'll pretend that the answer fully justifies your current plan. If you can only commit to two ISLs then I agree with dynamo that you should have one ISL from each fabric going through each link.

If I were faced with this situation though I would dedicate four ISLs per fabric and I would trunk two of the ISLs per fabric through each link between data centers. Of course some of this would depend on the maximum bandwidth I needed between fabrics and also on the speed of the links, but this would provide the safest most redundant solution. If one of your links between sites goes down both of your fabrics still have dual redundant ISLs. You don't have to worry about a double failure of a link and the wrong SFP at the same time. And you still get the full bandwidth of dual ISLs if you take an unplanned (or planned) outage on one of the links.

Of course we should still go back to the question of what you are trying to accomplish by spanning redundant fabrics across data centers and the possibility that FC Routing may offer a more robust solution...

Allen, Dynamox, if I'm correct, in the Cisco world you would enable transit VSANs. the actual link between the 2 sites is for example VSAN 500 where the VSAN in datacenter 1 is VSAN 100 and in the other DC it's VSAN 200. If you face a problem with the physical link between the 2 sites, only VSAN 500 will suffer and VSAN 100 as well as VSAN 200 won't notice a thing! (any traffic that being routed will obviously also have an issue, but I meant to say that you'll be isolating your external hazards from your inside SAN.

In the Brocade world you could work with virtual switches (in DCX). The so called base switch maintains the ISLs and since they only support ISLs, end ports don't suffer from ISL issues. End nodes are on logical switches.

I'm sorry RRR, but I don't see this as being a good use case for virtual switches. I'm not a big fan of implementing virtual switches in the first place, although I understand there could be some situations in which it makes more sense than the alternatives. In this case segmenting off virtual switches wouldn't gain you anything since they would still be part of the same fabric and an ISL problem between the sites would still propagate through the fabric as two fabrics rebuilt.

I do see this as a valid use case (depending on the details) for FC Routing because an IFL problem between the fabrics would not affect either fabric... just the traffic flowing between fabrics.

Or maybe I'm not understanding how you would use the virtual switch segmentation in the DCX...

Ah, ok. I thought the VFs were separate fabrics and thus an FC routing solution. ok, my bad. forget I mentioned it in this context.

There are ways you can do that, but you still need the Integrated Routing license to make it work. If you are going to have that anyway you might as well skip the virtual switch piece of it and just let the fabrics connect with IFLs directly. I prefer to use a routing backbone if you are connecting multiple edge fabrics, but this way you can avoid the backbone fabrics and still have separate IFL connections between each pair of fabrics.

Easier to explain with a whiteboard, but you can see examples in my blog post on FC Routing

What's an IFL? With VFs you don't need additional hardware, such as a router. Ok, you need that routing license, but that's the same with that physical router, right? I'd say that not having to buy a physical router will be cheaper in the end, but then again, you'll sacrifice ports in your DCX machine, which in the end may be more expensive.

Anyway: you CAN do it with virtual switches. I did it before as I'm pretty sure we talked about in our Ask the Expert session, earlier this year.

I believe IFL stands for Inter-Fabric Link. I agree with you about the considerations between applying a routing license or deploying a physical router. One additional consideration I would highlight is the additional physical router may also bring with it FC-IP capabilities.

A good reference for additional information if you are dealing with Brocade SAN questions like the above would be the SAN Design guide available via the Brocade website here.

And Inter Fabric Link (IFL) is very similar to an Inter Switch Link (ISL) except that it goes from an EX port to an E port instead of an E port to an E port. The IFL is the link between fabrics that enables FC Routing connectivity without merging the fabrics. It CAN be accomplished with a routing backbone (separate hardware) but in this case would make more sense to use an existing port in one of the connecting fabrics. You would only need to license the Integrated Routing on the switches on one side of the link. The other side will just be using a regular E port for its end of the connection.

Ah ok. I thought you meant ICL, so I was only making sure.

So you have ISL, IFL and ICL then. Nice

thanks