Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1510

August 6th, 2008 08:00

isl

I have three switches, 2 9509 and 1 9513.
Each is standalone with their own fabric and unique vsan.
I have the need to connect them so I can connect servers on one switch to storage on another switch.
Normally I have each array connected half to one switch and half to a second.
I also have each host connected to the same way.
With three switches I now have a mixture that does not always work out i.e. I may need to connect a host to storage that is not on the same switch.
I have read how to create an isl and a trunk but am not sure from the docs the full implications of the interconnection.
Must I merge the fabrics into a single fabric which I inter-connect them or can they still have independent fabrics?
Must I merge the vsans or can they continue to be separate.
I read that the ports on each end of the isl need to be using the same vsan.
Do I need to somehow move all my ports on a switch to a new vsan that matches the other switch?
I read that I can use ivr but don't know the impact of using ivr vs having them in the same vsan.
I does not appear that I can have a port in more than one vsan at a time either.

141 Posts

November 28th, 2017 06:00

Hi there,

In our effort s to clean up the forum, we came across your question / statement.

If the question / statement is still valid, not expired and you need an update please reach out again and we try to get it answered.

As for now we set it to “answered.”

Regards,

Jim

10 Posts

August 6th, 2008 08:00

fyi I forgot to add that my switches are all at 3.1(3a).

August 6th, 2008 09:00

Hello,

You don't need to merge the switches at a VSAN level. Depending on what your needs are you can create either isolated VSANs or ones that transverse the different switches. If there are isolated members in one VSAN that you want to be able to zone to in another you can always use IVR to connect them. Each VSAN acts as a separate virtual fabric so you get the advantage of the isolation through them. By limiting the VSANs that are allowed to cross the ISL you also cut down on the traffic overhead. I'd also recommend using DPVM is appropriate to your situation.

I'd recommending reading through few guides before you start planning this out. First, would be the EMC Topolgy Guide available out on Powerlink. Second for how to do the actually configurations, CLI or Fabric Manager Configuration guides depending on whether you use GUI or CLI. Lastly the Cisco Cookbook for some for additional information and examples.

Please keep in mind that the decisions you make now, you'll have to live with down the road. Poorly planning now can end up causing nightmares in the future. You can always redo the configuration later if you have design issues but this can sometimes mean downtime as you reconfigure the switches. I always recommend that if people aren't familar with switch planning that they engage their local EMC Customer Engineer to see if an EMC Solutions Arch. can assist in the process. Good lessons you learn now can be very helpful in future SAN planning and expansions that always happen.

Thank you.

10 Posts

August 11th, 2008 11:00

I have read the docs but they don't provide pros and cons of choices.

While I don't have to merge a vsan what are the pros and cons of doing so.
I would think a pro would be not needing to use ivr's. and therefore ivr zones and zonesets.
What are the pros and cons of using ivr.

While I don't have to merge my separate fabrics into one, what are the pros and cons of doing so.
I would think that a pro would be managing all three switches in one place.
What are other pros and what would be cons.

August 11th, 2008 17:00

Without knowing the exact SAN configuration you have or don't have, I really can't state what your pros or cons may be. My recommendations would be to have someone like EMC field review your current configuration and what your future needs are and formulate a plan.

Pros for one configuration may be a con for another one. In general terms, the pros are that vsans isolate the traffic and the possiblity of one particular service causing the entire san to go down if one crashes. The con side is that vsans take some overhead to assemble and strip from the traffic. The overall affect is very minimal on most san configurations.

Merging the entire fabrics makes it easy in some ways to administer the SAN (ie. zoning is easier). Unfortunately this also means that all traffic flows across the different switches and that future configuration may run into issues.

Thank you.

10 Posts

August 12th, 2008 06:00

My ce's are not able to assist. I don't have money to pay for ps to help. Since we buy our switches from emc I can't go to cisco for questions.

So basically I have to figure this out on my own. If I can ask questions in forums and find out what others are doing and why then I have a chance at following the same standards as others and being successful.

I understand you pointing me else where but this is my only avenue for information.
If you can't help perhaps others in the forum can.

August 12th, 2008 08:00

I'm sorry I'm not able to provide you with the information you were looking for. There are some generic recommendations that I've provided and more in the different documents, especially the EMC Topology guide, that I've pointed out. As I previously stated the key is understanding what your current configuration is and what you plan for the future. Without these details I don't think anyone can provide you with the details that you need to best create your configuration.

Having been on the other side of supporting poorly configured SANs I can tell you that the least expensive way in the long run is to configure them correctly the first time. Fixing them after a downtime of the SAN is the most costly way of all.

I can understand though that a PS engagement is not always possible. Is it possible to attend one of the EMC or Cisco training classes on the MDS products? Both the EMC and Cisco classes provide you with the tools to plan and implement at least basic MDS SAN configurations.

Lastly, please keep in mind that there is no guaranty that the information that another poster provides to you is technical correct or will work in your environment.

Thank you.

5.7K Posts

August 17th, 2008 07:00

I have the need to connect them so I can connect servers on one switch to storage on another switch.


If you don't have layer 3 switches, all equipment must be in the same VSAN. If you have 92xx or 95xx I'd suggest you place storage in VSAN A and hosts in other VSAN's and do IVR to connect hosts to storage ports.

Normally I have each array connected half to one switch and half to a second.


I assume you have 2 separated fabrics to begin with. Physical separated is best, since 1 switch failure won't bring down both fabrics.

I also have each host connected to the same way.
With three switches I now have a mixture that does not always work out i.e. I may need to connect a host to storage that is not on the same switch.


3 In total ? Or 3 in fabric X and 3 in fabric Y ?

I have read how to create an isl and a trunk but am not sure from the docs the full implications of the interconnection.


If VSAN numbers are different, fabrics won't merge. If VSAN id's are the same and domain id's are different, fabrics will merge.

Must I merge the fabrics into a single fabric which I inter-connect them or can they still have independent fabrics?


2 VSAN's on 1 physical switch are 2 separated fabrics with 1 SPOF: the switch. I'd recommend to have 2 fabrics which are physically separated.

Must I merge the vsans or can they continue to be separate.
I read that the ports on each end of the isl need to be using the same vsan.


No, they don't. ? It's not the port VSAN that matters but the allowed VSAN's on the link.

Do I need to somehow move all my ports on a switch to a new vsan that matches the other switch?
I read that I can use ivr but don't know the impact of using ivr vs having them in the same vsan.


IVR only works if the wwn's you want to connect are in 2 different VSAN's.

I does not appear that I can have a port in more than one vsan at a time either.


True, except for TE ports, but those are only used for portchannels, not to connect hosts or storage..
No Events found!

Top