As part of our new and improved SAN infrastructure, we have purchased a number of 9509 (core) and 9216 (edge) SAN switches. We have done the admin and trouble shooting training and this raised questions about using ISLs. Our previous SAN infrastructure (seperate SAN islands) is two of everything and no interconnect. I have tried to get something concrete about creating one large fabric by using ISL's to all our switches but this has been a relatively fruitless exercise. Even the Cisco specialists have been rather coy about this saying that there could be some problems by creating one large fabric but generally most companies use ISL for at least inband management of the switches.
The design phase of our new SAN is now up to completely uninformed management trying to tell me that we should not use ISL's at all (but yes we will use ISLs between core and edge switches) and that we should not interconnect our core switches just in case something bad happens to the fabric.
Our vendor has no clue on management of the MDS9000 switches so they are of no help.
I am looking for any good and bad reasons why not to use ISL's at the very beginning of our implementation. My knowledge is not good enough to put forward any arguments but I am keen to do at least in band management and then look forward to advanced uses for ISL/EISLs.
One last thing, if I wanted to do inband management by using ISL's, would creating a small VSAN only for this purpose that is spread across both switches be the way to go? I don't have any plans to do IVR currently.
The following is a design opinion so do not take it as a gospel. Your issue is a sub-technology fight with reasonable arguements on both sides. I would suggest to you that you use vsan 1 as the inband mgmt among all of the switches. Then only trunk the vsans that need connectivity to the rest of the them. For instance, Lets say that core as vsan 1,2,3 where 2 is for remote site A and vsan 3 is for remote site B. Then, have the ISL link to A trunk the vsan 1 and 2 and the ISL link trunk B carry the 1,3 combo. This gives you the flexability to add and remove vsans later. The key to this is only do zoning in one location which in this case would be your core switch. If this is a large SAN, then it might be appropriate to look at CFS for zoneset disribution. Be aware that no vendor has initiator to target over an ISL certified. But it works fine and with FCC and port-channels, it works perfectly because the MDS can handle 400 frames in it's buffer space.
The edge to core will be using port channels. I think I will need to get one of the Cisco SAN specialists to come to work and discuss this. This seemed so easy to start with but the more I delve into it, the less confident I feel about doing inband management with ISL's.
I experimented today with attaching two 9509's together with E ports and the result was a bit interesting. Switch 1 had vsans 1 and 100. Switch 2 had vsans 1 and 101. After joining them (and looking at them in fabric manager), switch 1 only has vsan 1 and switch 2 now has vsan 1, 100 and 101. I wonder what will happen when I attach the edge 9216 switches. I would expect switch 2 would see vsans 1 and 200 from switch 3 and vsans 1 and 201 from switch 4, etc. Switches 3 and 4, etc won't have ISL between them.
The training I did was very good but it lacked going into complex interconnectivity.
I am starting to believe in the Keep It Simple Stupid (KISS) theory. Hopefully I can get some tips for the specialist.
I promote the design of the Management VSAN across all switches as Tim states, this is the most best practice I have seen in production MDS SANs.
As for your experiment with the VSANs, I guess I do not see the complete picture you are drawing. VSAN's exist on switches not on TE ISL's. you need to create the VSANs in the swiitches and then use the trunking configuration on the TE ISL's to allowed or not allowed the VSAN to trunk across. If you allow VSAN 100 to trunk across from switch 1 to switch 2 that's fine, but if there is no VSAN 100 in switch 2 what is the point. If you have VSAN 100 in both switches but VSAN 100 is not allowed to trunk across on the TE ISL then the two VSAN 100's are segmented from each other by your design.
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...
Cisco Documents are usually accurate, but when it came to the document
on Cisco APIC Signature-Based Transactions it was slightly off the mark.
This document is for those novices to API like me who cant seem to
figure out how to go about performing signat...