正文共：2328字 40圖，預估閱讀時間：5 分鐘

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-interface3000mad bfd enablemad ip address 30.3.3.1 255.255.255.0 member 1mad ip address 30.3.3.2 255.255.255.0 member 2
#
interface GigabitEthernet1/3/0port link-mode bridgeport access vlan 3000
#
interface GigabitEthernet2/3/0port link-mode bridgeport 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環境下怎么驗證冗余備份的可靠性配置，還得容我再想一下。

長按二維碼
關注我們吧

更多推薦

? ? ? ? ? ?

脫掉等保的“神秘外衣”

主機安全漏洞解決方案

H3C防火墻特征庫升級失敗排查

V7防火墻配置基本操作

vFW設備初始化配置調優

網絡后沿：零信任網絡

? ? ? ?