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
