Understanding NPV and NPIV

So now that we know a little bit about fiber channel SANs and the goal of the Nexus 5k/2k, we can talk about some more advanced topics.  One topic that you’ll come across when working with the 5ks is NPV and NPIV.  NPV stands for N Port Virtualization.  NPIV stands for N Port ID Virtualization.  Both of these technologies are similar in what they accomplish, but are applied to different pieces of the SAN fabric. 

 NPIV
In a standard SAN configuration, you create zones that allow you to specify what devices need to talk to what.  Zones (in most cases) use the WWNs to assign different devices different access on the SAN fabric.  If we take the example of a file server, it needs to see the disk array for its local disk.  The disk arrays WWNs and the file servers HBAs would be a member of a zone allowing them to talk to each other.  Now, what happens if that file server is actually a VMware ESX box hosting multiple servers?  In the example just given, that server really only has one way to identify itself on the SAN which is the HBAs WWN.  But what if we want to map different LUNs to different VMs on the ESX server?  Enter, NPIV…

NPIV allows the ESX server to log into the fabric multiples times.  This allows the server to register multiple FCIDs which allows the administrator to give VMs their own WWNs and FCIDs for zoning.
 

So if we look at the diagram above, you can see that we have a VM Host that has a single HBA in it.  The HBA talks to the NPIV enabled switch and runs the FLOGI process twice to register two FCIDs so that Host 1 can be in a zone with LUN 1 and Host 2 can in a separate zone LUN 2. 

NPV
In a traditional SAN fabric, each switch gets assigned a Domain ID.  The Domain ID is an 8 bit field in the FCID.  Using our basic network math we can discern that we can then have 255 domain IDs.  In reality, some of these IDs are reserved and can’t be assigned to switches leaving us with 239 switches.  While that may seem like a lot to some of you, in large environments, that hard limit can become a serious issue as you try to scale the fabric.  The solution to this problem is NPV.  NPV allows SAN switches to essentially become N port proxies. 

When talking about a NPV switch, I think its easiest to think of that switch as an HBA.  Take a look at the diagram above.  In this case the Nexus 5k is configured as an NPV switch.  The ports on the MDS appear as F type ports confirming that the MDS sees the 5k logically as a N port device.  In turn, the ports on the 5k are NP, or N port Proxy, ports.  The 5k then uses NPIV and proxies all of the connections for its connected hosts.  The HBAs on the bottom of the diagram see the ports on the 5k as F type ports just like a N port device would on a normal fabric switch.  You’ll note that I mentioned that NPV actually uses NPIV to some degree. So one of the first steps in configuring NPV is to ensure that both switches support, and have NPIV enabled.

The benefits of NPV are many.  Take for example a mixed vendor fabric.  In the past, you had to worry about interop modes, whether or not the two switches would talk correctly, and if vendor dependent features would still work.  Since you aren’t actually managing the NPV enabled switch and its just proxying connections, you can easily add switches to the fabric without worrying about interoperation.  Additionally, NPV helps solve the Domain ID limitation.  NPV enabled switches don’t get assigned a Domain ID since they aren’t technically manageable as a switch within the fabric. Additionally, NPV allows for reduced switch management/administration.  The NPV enabled switches don’t receive any additional SAN configuration once they are up and running in NPV mode.

Coming up next we’ll discuss the actual Nexus configuration.  Stay tuned….