Configuring Persistent FC IDs for IVR

[dynamoxxx]

Has anybody configured this for  IVR ? I use persistent FC IDs for my regular VSANs because i have a  couple of AIX boxes. I will also have a couple of them access storage  via IVR, dynamic tracking is not enabled on the host so i am wondering  if i should enabled persistent fc id for IVR ?

Thanks

[Michael Brown]

Yes...most AIX and HP-UX implementations do not handle changes in the target FCID.  Without the dynamic tracking, I believe that you would have to run IO scan should the target FCID change.   This was the driving factor behind the development of statc FCIDs for use with IVR NAT.  The initial release of IVR, the FCIDs did not change when devices were exported outside their native VSAN.  One limiting factor for using IVR in this mode was that the domain IDs had to be unique across all the VSANs in the IVR realm.

If you are using IVR with NAT, then let us know and we can provide some guidlines on configuring persistent FCIDs for IVR.

Here is how to tell, issue this command on your MDS that are running IVR.

show run | inc nat

If it comes back with 'ivr nat' then nat is enabled, if it comes back with nothing, then ivr is not using nat, and persistent FCIDs on the local VSANs will provide your AIX hosts with a static target  FCID.

-hope this helps,

Mike

[dynamoxxx]

Mike,

i am not using IVR NAT as all my VSANs have unique domain id. So i guess that means that i don't need to worry about Persistent FCID then ?

Out of curiosity can you explain why persistent FCID is required in IVR NAT. Let's say if i do have two VSANs that have identical domain id. Each VSAN has persistend ID enabled. How does IVR NAT and IVR persistent FCID work together then ?

Thank you

[Michael Brown]

Sure..I'll try.

IVR ...no NAT

HBA fcid 0x0123456 ---------> MDS VSAN1 with domain 0x12

Storage fcid 0x223344------> MDS VSAN 2 with domain 0x22

When I IVR vsan 1 and 2, and then zone these devices...domain IS 0x22 and fcid 0x223344 will be proxied into vsan 1, and domain ID 0x12 and fcid 0x12456 will be proxied into vsan 2.   Frames from hba will be destined to fcid 0x223344, the real end device fcid.  So in the SAN, only the VSAN header needs to be re-written on the frame, not the FCIDs.

=========================================================

IVR with NAT

HBA fcid 0x0123456 ---------> MDS VSAN1 with domain 0x12

Storage  fcid 0x123344------> MDS VSAN 2 with domain 0x12

Now when I IVR vsan 1 and vsan 2, I can not proxy domain 0x12 and fcid 0x123344 into vsan 1 because there is already a domain 0x12 in vsan 1.  So what IVR NAT does is pick a domain ID that does not exist in VSAN and proxies that domain ID.  Since the domain ID is not the same as the original one, we also need to proxy an fcid in that domain that would represent the real 0x123344 device.

Assume IVR picked domain 0xAA and fcid 0xAA1234.

IVR would proxy these into VSAN 1, so the HBA would see the storage device as 0xAA1234.

If we do not specify what domain, and fcid, is used for the proxied devices, the MDS chooses them for us.  If that MDS reloads, it may choose another domain, and this would result in the hba seeing the storage device with a differnt fcid.  We have the capability to make the proxied domain static, and there for we can also make the fcid static for the proxied devices.

Frames from hba would be from 0x123456 to 0xAA1234 on the wire from the HBA to the local swtich...IVR would re-write the vsan and fcid so that the same frame on the wire to the storage device woule be from from fcid 0x?????? to 0x123344.  The 0x?????? is because the same proxy happens in the reverse direction for the HBA as it is proxied into vsan 2..so the storage see the HBA as an FCID other than it's native of 0x123456.

This works okay because lun masking and zoning is all done by the device PWWN, which does not change as the frame moves from host to storage.

-hope this helps,

Mike

[dynamoxxx]

this is superb explanation Mike , thank you so much for taking the time to explain this.  Now with your example , would you be able to illustrate (with MDS commands), how one would configure IVR NAT for these two VSANs and enable IVR Persistent FCID.  That would awesome.

[Michael Brown]

Sure

Assuming a single MDS using vsan 1 and vsan 2, both vsans using domain ID 0x12.

HBA is pwwn1, Storage is pwwn2

config term

This is to export the storage array that resides in vsan 2, into vsan 1 as fcid 0xaa3344

ivr fcdomain database autonomous-fabric-num 1 vsan 1

native-autonomous-fabric-num 1 native-vsan 2 domain 0xAA

  pwwn pwwn2 fcid 0xAA3344

This is to export the hba that resides in vsan 1, into vsan 2 as fcid 0x232323

ivr fcdomain database autonomous-fabric-num 1 vsan 2

native-autonomous-fabric-num  1 native-vsan 1 domain 0x23

  pwwn pwwn1 fcid 0x232323

If there are multiple MDS in the IVR topology, these entries would need to be included in each of the IVR enabled MDS.

You can use CFS to form peers amongst the IVR enabled switches and then use the 'ivr commit' to propagate the config command to the other MDS.

In this example, domain ID 0x23 can not already exist in vsan 2, nor can any switch join vsan 2 using domain ID 0x23.  The same is true for vsan 1 and domain 0xAA.

Lastly, this example does reflect overlapping vsan IDs.  That is why both vsan 1 and 2 are in autonomous-fabric (AFID).  Had there been multiple MDS, and overlapping VSAN numbers (IDs), then to use IVR, those overlapping VSANs must be configured in different AFIDs.  Basically you can have a device in vsan 1, domain ID 0x12 and using IVR NAT have it zoned with another device, in another MDS, in vsan 1, using domain ID 0x12, as long as the vsans are in different AFIDs.

The intent is not to design SANs this way, but if you have case where 2 existing SANs need to have some devices communicate, and neither SAN can change the existing vsan numbers and domain IDs, there is a way to connect the 2 devices and let them remain in the same vsan keeping the same FCID.

I would always recommend putting these static entries in place, before creating and activating the IVR zoneset.  I would not recommend adding in the static entries (unless they matched what was currently in use) , as I am not sure if the MDS would log out the devices to enforce the new static mappings.  It may only use the database when the zoneset is activated, or it could put it into effect immediately.

-now you know what I know

  Mike