Brian,

Thank you so much for you're reply!   I am glad that you say it is not as complex as I thought it was. I am relatively new to Cisco switches, most of my experience has been with Brocade.

I do believe I want to use a transit VSAN, it is my understanding, that if you don't use transit VSANs, you can potentially cause temporary interruptions across the fabrics.  From what I have read, transit VSANs will ensure that only replication traffic (in our case), will travel through the FCIP tunnels.  All other unecessary fibre channel traffc would remain local.  I am still a bit confused about the transit VSAN... In my drawing it shows that the fabrics at both sites have VSAN10, this VSAN contains the Virtual Tape library.  If I create a transit VSAN, let's say VSAN 200 which interfaces should belong to that VSAN?  Just the FCIP interfaces and the VTL ports to be used for replication?  For example, like this:

SITE A                                   SITE B

-----------                              ----------------

VSAN10                              VSAN10

VSAN20                                                 

VSAN200                             VSAN200

The FCIP ports used for replication will reside in VSAN200 (at both sites) and also any VTL ports required for replication will be removed from VSAN10 at both sites and placed in VSA200.

Here is something else I should mention, which  may or may not required changes.  Currently at SITE A, there is a backup server in VSAN20 that accesses a tape library in VSAN10.  IVR with NAT enabled is used to share the the tape drive with the backup server on VSAN20.  There is essentially one IVR zoneset that has the HBA for the backup server in VSAN20 and the two FC ports for the tape library in VSAN10.

Will the existing IVR zonesets make any difference when reconfiguring the fabric to create the transit VSAN?  Also, since the fabrics have already merge, anything I should look out for when removing the ISLs?

I really appreciate your help, it is definitely starting to make more sense now.  I am just still confused as to which interfaces should belong in the transit VSAN.

Thanks for all your help Brian and everyone else!

-Heather

Heather, you are correct that using a Transit VSAN will minimize the amount of disruption a WAN link can cause other VSANs, so the idea is the Transit VSAN is used to isolate the WAN.

Transit VSAN's in themselves do not determine what traffic can or cannot go over link.  Its just a place to put objects.  Normally the only members in a Transit VSAN are the WAN ports, which are typically FCIP ports (VE's) and are of course trunking.

Ok, so if you create a VSAN, put the FCIP ports in it, and connect the switches, you will potentially merge fabrics because by default trunks trunk all VSAN's, you must limit this, by doing "switchport trunk allowed vsan x", where vsan x is the transit VSAN.

If you do this, then you will NOT merge, because only the transit VSAN is allowed over that link, and the only things in that VSAN are the two (or more) FCIP ports.

So realize this.  Traffic gets from one switch to another because its either a) trunked or b) routed via IVR.  When you merged the first time you trunked the traffic, that was the mistake.  We will enable the "switchport allowed" command and now we have essentially created a situation like:

VSAN10 <---->VSAN20 <---->VSAN30

Yes you can have VSAN10 at both ends of the link, but as we pointed out its best to use a totally new VSAN.  Unless you have some reason you feel you need to make the VSAN's the same at your local and remote site, normally you would want to avoid this.

Bottom line, is regardless, you have members in separate VSAN's, these cannot talk, they are isolated as if they were in physically different SAN's.  The only way to allow them to talk, is to use IVR.  We specifically configure two things 1) which VSAN's are going to participate in the IVR topology and 2) more specifically which specific members of those VSAN's can talk to which other specific members of which other VSAN's in the topology.

Only your FCIP ports should be in the Transit VSAN200 you propose. The VTL's should stay in a non-transit VSAN.  This can be VSAN10 if you like, but if you have two tape libraries one local and one remote, I would recommend putting the remote one in a new VSAN  you create for the remote side that is not present on the local side.

So lets say you have something like this:

local site                    transit link                         remote site

VSAN10                     VSAN200                         VSAN20

you would create an IVR topology with a single AFID of 1 (common practice) and make sure all three VSAN's are in this topology.  Then once you have this done you can create IVR Zone's and Zoneset's to decide who can talk to who.  It sounds as if you already have an IVR Zoneset and IVR Zone, so you would just be creating some new IVR Zones and activating them.

What you describe where your tape is in a separate VSAN is quite common and that's fine.  So at the local site you have VSAN10 and VSAN20 already in use, maybe you use VSAN30 for the remote site or some other number of your choosing.  I would not use VSAN10 or VSAN20 if you can help it as it just makes things confusing. I would also use unique domain id's for all switches as well, statically assigned, I just like to have everything deterministic like that.

The existing IVR Zonesets do make a difference in the sense you want to be aware of what VSAN's already exist in the topology and just be familiar with what is currently going on in IVR just as you should with all active zones in the SAN environment.

Dont' feel you have to digest it all at once, I would go in baby steps, I would do the following:

1. decide on a VSAN to use for the remote site

2. decide on a VSAN to use for the Transit link

3. Create FCIP links, keep them shut down

4. add the switchport trunk allowed command to only allow the transit VSAN

5. you can assign the ports of the fcip to the transit vsan too, but not necessary as these FCIP links are ISL's (VE)

6. You can no shut the FCIP links they should come up, trunking the single VSAN which has no members other then themselves

7. Look at your IVR topology configuration, make sure it makes sense, if not you can post it here

8. Add the new transit and remote VSAN's to the topology and activate it, in more complex scenerios you may need/want to use IVR service groups but I am doubting that from what I am hearing so far, but you can always tell us all about your IVR topology.

9. Create new IVR Zones for the new members that need to talk, add these to the IVR Zoneset, Activate

As always, you want to make sure you have windows to do these things, if you have access to a lab, its always a good way to test, If there is any step your stuck on just post it here.

You also can use SAN Extension Tuner (if its supported on your hardware) to test the link.  FCIP should be tuned properly for best performance, this can mean setting various tcp parameters in the fcip profile, and SET can help you accomplish that.  You may also wish to use compression and other features such as write-accelleration or tape-accleration.

You can read a bit about SAN Extension Tuner on my blog at: http://www.feeny.org/?p=233

IVR is one of the more interesting features of the MDS's which Cisco was doing long before everyone else.

Brian

Gary,

but scenario 2 will merge vsan 10 and 20 ..unless i misunderstood.

Scenerio B wouldn't merge, as there would be members at each site only in one or the other VSAN.  But the problem with not using a transit VSAN is of course the ability for WAN irregularities (very common) to cause stability issues with the fabric, a transit VSAN helps to isolate this.

Heather, if you don't HAVE to have the same VSAN at both sides, then Gary is correct in saying its best to use like 10,20,30, vs. say 10,20,10.  I only used 10,20,10 in my example because your diagram showed it, and it is possible, but its always best to avoid overlapping if you can.

actually what I meant was that they will merge but it should be good merge as there should not be descrepencies (zone conflicts, etc).  I would avoid the whole concept of using the VSAN on the WAN and local network though.

Brian

Thanks Brian. 

Heather, The transit VSAN is the best way to go as Brian pointed out.  Our Primary and DR sites are only 20-22 miles apart and I'm using a transit VSAN for the very reason Brian pointed out.

Gary R.

Your correct.  That is why I mentioned I didn't think Heather would like that scenario.

It does prevent the contents of Site B's VSAN 20 (formally VSAN 10) from merging together

with Site A's VSAN 10 and vice versa while keeping an AFID of 1 and NOT using IVR NAT

(I'm very anti-IVR NAT !!!!).  My goal is to keep each fabric seperate while not introducing

to much complexity and IVR NAT.  So Heather would end up with 1 fabric but each site

would be separated by VSANs.

I hope this makes sense. 

Gary R.

Gary ..please excuse my lack of knoweldge in IVR functionality

So if i have VSAN 10 on one side and VSAN 20 on another site, without using transit VSAN (that would contain ports for both VTLs), how would i make two devices talk to each other ? Can i still use IVR without transit VSAN ?