随之有人将FCoE的脑筋动到了NPV与服务器之间的网络上，如下图所示：

在FCoE中的NPV相比较FC中要多做三件事，参考前面FIP流程：

1、回应节点设备关于FCoE承载VLAN的请求

2、回应节点设备的FCF查找请求，根据自己初始化时从FC Switch得到的FC ID生成仿冒FCF使用的MAC地址

3、在CNA网卡和FC Switch之间对转发的数据报文进行FCoE头的封包解包。

NPV不是FCoE标准中定义的元素，因此各个厂家在一些细节上实现起来都各玩各的。比如都是将连接服务器的Ethernet接口和连接FC Switch的FC接口绑定起来使用，但是对应的绑定规则就可能不同。再有如FC接口故障时，如何将服务器对应的通道切换到其他FC接口去，是否通知服务器变化重新进行FLOGI注册，及通知等待时长等设定都会有所区别。

说说NPV的好处，首先是实现容易，之前描述的那几件主要的任务现在都已经有公共芯片可以直接搞定，所以包装盒子就是了。其次是部署简单，不需要实现FCF，不用管FC转发，不计算FSPF，不占Domain ID。最后是扩展方便，使用FC Switch的少量接口就可以连接大量的服务器。

由于NPV与服务器之间网络为传统以太网，因此NPV交换机也必须支持DCB标准中相关的无丢包以太网技术。

严格来讲，NPV交换机不是FCoE标准中定义的FCoE交换机，但可以在接入层交换机上实现与服务器之间的Ethernet网络复用，减少了服务器的物理网卡数量（并未减少操作系统层面的网络通道数量），扩展了FC网络接入服务器节点的规模，适用于云计算大规模服务器部署应用。

补充一个ENPV（Ethernet NPV）的概念，这个东东是Cisco提的，就是在服务器与FCoE交换机（FCF）之间串个NPV进去，还是做些代理的工作，可以对FIP进行Snooping，监控FIP注册过程，获取VLAN/FC ID/WWN等信息，对过路流量做些安全控制啥的。这种东东存在既有理，但以后有没有搞头就不好说了，市场是检验技术的唯一标准。