i would be concerned about VSAN0001 because if i look at my switches where i have connected 9513 to a 9222i, VSAN0001 became segmented which makes sense because i am not trunking it but what i also see is that VSAN0001 on 9222i is operationally down. I know i did not take it down manually so it must have taken it down by itself when i first connected these two switches together.

Safe to assume you are not licensed for IVR so you are not going with transit VSAN to carry your replication VSAN traffic ?

forgot to mention that i leave my ports that go to my DWDM gear in VSAN1, you can't delete VSAN1 so you can't take my replication down (if somebody accidentally deleted my transit vsan)

Well, the switches do have the enterprise license, so I could use IVR/transit VSAN. However, the only cross site requirement is to connect the RecoverPoint deivces. There's no intension to allow hosts to connect to storage across DC boundaries. Also, I like to keep it simple, as I do not have much faith in the support team.

VSAN1 segmentation is interesting. Have you merged VSAN1 across your tranit VSAN? If not has VSAN1 segmented on either switch? Also, if we assume VSAN1 to be clear of devices does it matter?

even though i do not have any devices in VSAN1 i did not want to "trunk allow" VSAN1 over my transit VSAN just to get rid of segmentation. In one of my early Cisco MDS classes i was told that VSAN1 carries some information that you don't want to merge with VSAN1 of another switch. So i have always had VSAN1 segmented, looks ugly in Fabric Manager but it does not bother me.

I have local replication requirements (RDF between DMX4 and VMAX, same datacenter) so i did not want to trunk that VSAN to my DR site, hence using IVR.

better feedback from Cisco community ?

ha, ha. I've seen you on there, so knew it wouldn't be long before you'd pick that one up. I thought a bit more exposure wouldn't hurt.

anyway ... in answer to your question ... no ... I've more confused than when I started. My question now is ... what is the best practice for VSAN1 ... to merge or not to merge across an ISL. Is it a good or bad idea? I can't find official Cisco doc that states best practice for this.

This has got me thinking. I know that best practice dictates that VSAN1 should not be used for prod traffic. Some say it's for staging (cisco doc), some avoid using (cisco docs), and some take it offline (community), but I can't find why this is best practice. I've blindly adhered to this for years without really understanding why.

Another question: if you have the DWDM ports in VSAN1 do you not have to create an ISL between those ports requiring you to merge VSAN1? or have I just completely exposed by lack of understanding of tranist VSANs.

Scott,

i have two 9222s in my lab that i could use to test this out, and see if i experience the same issue as i have in my production fabric. What code are you running on your switches and i will upgrade these 9222is to the same one.

I apologize if i repeat what you already know but let's assume this is my requirements, i need a host in vsan 10 be able to talk to storage array in vsan 20. Merging fabrics here is not even an option so we are going to use IVR. To establish connectivity i perform these steps:

1) connect my single mode fiber from DWDM gear to long-wave SFP on 9513, port is configured for VSAN1

2) connect my single mode fiber from DWDM gear to long-wave SFP on 9222i, port is configured for VSAN1

3) create VSAN 30 on 9513 and 9222i, it has no members, it has not zonesets ..nada

4) create IVR topology and activate it

autonomous-fabric-id 1 switch-wwn 20:00:00:0d:ec:f0:16:00 vsan-ranges 10,30 <<- 9513 N

autonomous-fabric-id 1 switch-wwn 20:00:00:0d:ec:f0:17:00 vsan-ranges 20,30  <<- 9222i

5) trunk allow VSAN 30 on the ports we connected to in step 1.

6) at this poing you can IVR zone devices from both fabrics.

aaarrgghhh. I just lost my post for the third time. Fortunately I took a copy of the second attempt.

Ok. So, I'll paraphrase the lost post. First of all ... thanks for the offer to test. My test lab funding was canned again. grrr.

So, if I use your example I want to simply stretch VSAN 10 across sites using the ISL. VSAN 10 will contain the DWDM connected ports, and the RecoverPoint ports only, so that the RPAs can communicate. no requirement for IVR, etc.

If I apply a trunk allow list to include VSAN 10 only excluding VSAN1 then VSAN1 will not merge. At the moment I do not want VSAN1 to merge as one site has a bunch of UCS environments attached to it.

There a post on the cisco forums (one to which you've contributed Mr D) that has a Cisco employee stating that VSAN1 should be merged across an ISL, as it propagates fabric info. Of course it's assumed that it's free of prod devices. The problem is that when pressed the Cisco chap didn't offer up official documentation that would corroborate this.

https://supportforums.cisco.com/message/3401997#3401997

What worried me is possibility of one of the VSAN1 being forced operationally down when VSAN1 becomes segmented, as you detailed in an earlier post. Are you able test whether this does actually happens?

I'm leaning towards making VSAN1 cleaning a prerequisite to the ISL creation and then merging VSANs 1 & 10. I'll ask my TC for advice from an EMC MDS specialist too. I'll let you know the response.

cheers
scott

forgot to mention one side has 5.0(1a) & the other 4.2 (something)

upgrading switches right now, will let you know how it goes