SAN NPIV and NPV: Fibre Channel Port Virtualisation

A Fibre Channel fabric has a hard structural limit that IP fabrics do not: every switch consumes a domain ID, and there are only 239 of them. Scale out with dozens of small edge switches and you run out of domain IDs long before ports, which is exactly the problem NPIV and NPV were invented to solve. This article explains both features, how they interact, and the configuration needed on a Cisco MDS fabric — with the traps that turn a routine edge-switch addition into a fabric outage.

NPIV: Many FC IDs on One Port

N_Port ID Virtualisation lets a single physical N_Port obtain multiple fabric addresses (FC IDs). Each virtual port behaves like an independent initiator: it has its own WWPN, its own zoning identity, its own port security entry, and can be a member of a different zone.

The canonical use case is a server with a single HBA port running several virtual machines or several storage applications that each need to be zoned separately. Without NPIV you either add HBAs or accept mixed-offender access; with NPIV, storage administrators keep per-application zoning and per-initiator LUN masking while the server team keeps their port count low. Every enterprise-class HBA has a configurable NPIV limit — usually 16 to 255 virtual ports per physical port — and every FC switch must be NPIV capable and enabled.

! Cisco MDS: enable NPIV on the fabric
switch(config)# feature npiv
switch(config)# npiv enable
switch(config)# show npiv status
switch(config)# show npiv devices

! Per-port limit for an HBA-facing port
switch(config)# interface fc1/10
switch(config-if)# switchport mode F
switch(config-if)# switchport npiv max-logins 64
switch(config-if)# no shutdown

NPV: Edge Switches Without Domain IDs

N Port Virtualisation is the counterpart at the switch level. An NPV-mode switch does not join the fabric: it does not take an FC domain ID, does not run a fabric principal election for itself, and does not switch locally. Instead it proxies its host-facing ports to an upstream "NPV core" switch through NP ports, and the core allocates the FC IDs from its own domain on behalf of every downstream device. The result is that a rack of edge switches consumes a single domain ID — the core's.

Configuring an NPV Edge Switch

! Enable NPV and disable switching on this device
switch(config)# feature npv
switch(config)# npv auto-load-balancing core-port-group
switch(config)# no feature fport-channel-trunk

! Uplinks to the core become NP ports
switch(config)# interface fc1/1
switch(config-if)# switchport mode NP
switch(config-if)# no shutdown
switch(config-if)# interface fc1/2
switch(config-if)# switchport mode NP
switch(config-if)# no shutdown

! Host ports stay F ports
switch(config)# interface fc1/3
switch(config-if)# switchport mode F
switch(config-if)# no shutdown

! Server interface selection: which core the host uses
switch(config)# npv traffic-map server-interface fc1/3 external-interface fc1/1
switch(config)# npv traffic-map server-interface fc1/3 external-interface fc1/2

switch(config)# show npv status
switch(config)# show npv flogi-table

Design Rules and Hard Limits

• NPV core switches must support and enable NPIV; without it the edge cannot allocate FC IDs.
• There is no local switching — all traffic goes through the core, so design the ISL bandwidth accordingly.
• Up to 100 NPV devices per fabric is the traditional guideline; more importantly, an NPV edge consumes the core's port resources rather than its own domain allocation.
• Remote SPAN is not supported on NPV edges, and port tracking behaviour differs — check the platform documentation before assuming a monitoring design still works.
• Nested NPIV works: an NPV edge can proxy servers that are themselves NPIV-capable, and the whole chain resolves to the core's domain.

Operational Verification and Failure Modes

show flogi database vsan 10          # is the host logged in at the core?
show npv internal info flogi-table   # which external interface serves it
show interface fc1/1                 # NP link state, B2B credit
show zoneset active vsan 10          # zoning is still configured on the CORE, not the edge

• Host does not log in. Zoning and device-alias configuration live on the core in an NPV design; adding a zone on the edge switch has no effect. This is the mistake people make once and never again.
• Single core ISL saturated. All downstream traffic hairpins through the core. Verify with ISL utilisation and consider trunking (TF/TNP) instead of separate VSAN-carrying links.
• Core switch reboot takes down the whole rack. NPV edges have no fabric services of their own — plan dual-core connectivity with different external interfaces per server interface.
• Credits exhausted on the NP port. Many hosts proxied over one link share buffer-to-buffer credits; on long-distance or high-latency links, increase available credits or use dedicated uplinks per server group.

Related reading: Cisco MDS zoning and VSAN configuration, Brocade zoning CLI with aliases and FC versus iSCSI SAN comparison.

原文链接：https://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/rel_3_x/configuration/guides/cli_3_3_1/npv.pdf