IRF（Intelligent Resilient Framework，智能弹性架构）技术通过将多台设备连接在一起，虚拟化成一台设备，集成多台设备的硬件资源和软件处理能力，实现多台设备的协同工作、统一管理和不间断维护。
IRF主要有可实现多设备统一管理、提高可靠性、实现跨成员设备的链路聚合、提高网络的扩展能力等优势。
巧的是，操作vFW时我竟然发现有相关命令，那为什么不试一下能不能用呢？
环境准备
常规操作中，两台物理防火墙要做IRF，一般需要至少1根堆叠线（有条件的再加1根MAD检测线），在虚拟化平台内部，也就只好通过增加虚拟交换机和端口组来模拟物理线路了。
登录到ESXi管理页面，点击“网络”→“虚拟交换机”→“添加标准虚拟交换机”，设置vSwitch名称信息。因为是内部线路，用不到上行链路，在这把上行链路1后面的网卡关掉；因为一个物理网卡只能加入到一个虚拟交换机中，此处删除掉上线链路能方便后续操作。
然后点击“网络”→“端口组”→“添加端口组”，设置好名称并选择虚拟交换机为刚刚添加的“IRF link”。
创建一台名为“vFW-IRF-Linux-192.168.1.201”的虚拟机，创建过程中先添加IRF链路所用的网卡信息。
虚拟机详细配置信息如下：
为了保证测试成功，在部署过程中特地选择了“IRF Install”。需要注意的是，不同版本支持安装方式不同，E1166系列版本支持4种部署模式。
E1171系列版本支持5种部署模式，多了一个Debug Mode模式。
搭建IRF基础环境
部署完成后进入系统，查看接口信息发现和普通部署不同，接口编号多了一位槽位信息。但是接口卡还是不能确定，不能确认哪个接口是IRF链路。
简单测试一下，在设置中取消IRF port link的连接。
此时看到接口GE1/1/0状态DOWN了，所以初步推断vFW中接口和虚拟机设置中网卡适配器的对应关系是顺序对应。
简单设置vFW，实现远程登录，操作更方便。（操作参考vFW设备初始化配置调优，因为控制台不支持屏幕滚动，不能查看历史信息。）
本次操作我参考了vFW的IRF配置手册，和常规物理设备做IRF有所不同，官网链接如下：
http://h3c.com/cn/d_201911/1246617_30005_0.htm
验证了IRF链路之后，我们再如法炮制，添加一组MAD检测链路。创建名为MAD的虚拟交换机，并添加名为MAD link的端口组。
在虚拟机设置中添加一个新网卡。
发现直接添加的网卡设备并没有被设备识别到。
此时需要重启vFW使新的网卡配置生效。
搭建IRF
链路问题都解决了，接下来先修改设备成员编号，重启生效。
修改成员设备vFW1的优先级，使其成为主设备。缺省情况下，成员优先级为1。
和常规配置不同，vFW配置IRF端口时端口编号需要和IRF成员设备编号相同，所以irf-port 1应该是等于常规的irf-port 1/1。
一个IRF端口可以与一个或多个IRF物理端口绑定，以提高IRF链路的带宽以及可靠性。可绑定的IRF物理端口的最大数目为2。一个IRF端口必须有至少一个数据通道和控制通道，这两种通道可以部署在一个IRF物理端口上，也可以部署在不同的IRF物理端口上。
配置时可以看到，添加成员端口时后面可选type类型，如果不选择，则是将数据通道和控制通道部署在了一个物理端口上。
而如果指定参数区分端口类型，则需要添加两个成员端口；这些差异在配置中都可以看到。
并且从命令提示可以看到，IRF配置的生效方式和常规也不同，需要保存配置后重启网卡来生效。相对于之前的操作，算是有所简化。
vFW2修改成员编号之后发现无法远程，登录控制台查看确认为配置不匹配导致。启动配置文件信息如下，接口仍是旧的接口编号。
官网解释如下：
修改成员编号后，但是没有重启本设备，则原编号继续生效，各物理资源仍然使用原编号来标识。修改成员编号后，如果保存当前配置，重启本设备，则新的成员编号生效，需要用新编号来标识物理资源；配置文件中，只有IRF端口的编号以及IRF端口下的配置、成员优先级会继续生效，其它与成员编号相关的配置（比如普通物理接口的配置等）不再生效，需要重新配置。
保存一下当前配置。
再次查看配置文件，发现接口编号同步过来了。
按照指导操作（进入到IRF-port下，添加成员端口，重启网卡）完成IRF配置，因为默认开启了irf auto-merge，所以会自动加入IRF。
搭建完成后，查看IRF状态如下。
查看设备接口信息如下。
并且又发现了一个save safely操作，实际使用发现和常规保存一样。
MAD检测
IRF链路故障会导致一个IRF变成多个新的IRF。未尽量降低IRF分裂对业务的影响，一般建议配置MAD（Multi-Active Detection，多Active检测）检测。MAD主要提供分裂检测、冲突处理和故障恢复功能，不同MAD检测方式冲突处理原则不同，不允许同时配置：LACP MAD和ARP MAD、ND MAD冲突处理的原则不同；BFD MAD和ARP MAD、ND MAD冲突处理的原则不同。
虽然当前环境下用不到，但我还是选择用BFD MAD这种常用的检测方式来演示一下。首先按照完成配置，具体如下：
# vlan 3000 # interface Vlan-interface3000 mad bfd enable mad ip address 30.3.3.1 255.255.255.0 member 1 mad ip address 30.3.3.2 255.255.255.0 member 2 # interface GigabitEthernet1/3/0 port link-mode bridge port access vlan 3000 # interface GigabitEthernet2/3/0 port link-mode bridge port access vlan 3000
检测状态发现不正常，显示为Faulty，正常应该显示Normal。
调整端口组VLAN ID为对应的3000。
此时MAD状态恢复正常Normal状态。
IRF信息查看
日常操作中，除了使用display irf显示IRF中所有成员设备的相关信息、使用display mad verbose显示MAD配置信息外，还会用到display irf configuration显示IRF中所有成员设备的配置信息。
使用display irf forwarding显示指定成员设备收到的IRF Hello报文的信息。
使用display irf link显示IRF链路信息。
还有一些其它操作可以参考之前文章（IRF堆叠使用问题分析）。
使用场景探索
提醒一下，也就是做实验，日常使用可不要像我这么玩，还是很吃服务器性能的，CPU消耗最严重。vFW设备内查看CPU、内存利用率。
主机CPU使用情况。
数据转发消耗了很大的CPU。
IRF接口使用率始终保持在500Mb左右。
MAD检测端口也差不多有100Mb的广播报文。
最终确认为MAD检测链路消耗了过多主机资源，关掉之后CPU利用率降到了25%。
我开始也在想，既然都使用vFW了，为什么还要做IRF呢？配置不够了直接扩容配置不就行了吗？但后来我意识到这实际上主要是为了提高网络的健壮性。
像我这样在一台服务器上搭两台vFW的实际应用场景应该是没有，更多的可能是现场有多台服务器的场景，不同服务器上的vFW做IRF，这样能分担不同的流量场景，并且通过冗余配置和联动配置来实现业务的高可靠性，实现一台服务器挂死之后另一台服务器的感知，来响应这部分业务。
关于在vFW环境下怎么验证冗余备份的可靠性配置，还得容我再想一下。
