行情跟下單的路徑上如果有防火牆，每個封包都要多經過這一台設備，花多少時間要看封包是由硬體轉發還是由 CPU 處理。防火牆會替每一條流量建立一筆 session（依來源、目的 IP、port 與協定區分的紀錄）。新 session 開頭的封包由 CPU 比對 policy、建立 session，符合加速條件的話，FortiGate 把這筆 session 寫進專用的網路處理器，之後的封包就由網路處理器直接轉發，稱為硬體加速（hardware acceleration）；沒有加速的 session，每個封包都由 CPU 處理。今天把一台 FortiGate 201G 接進量測路徑，比較硬體加速開與關時，封包經過防火牆的延遲，結果有三點：

1. 硬體加速時，封包經過防火牆的延遲中位數約 4.1 µs，99% 的封包在 4.2 µs 以內；改由 CPU 處理後，中位數約 18.5 µs，是加速時的 4.5 倍，最慢的 1% 超過 47.9 µs。
2. 開著硬體加速時，每個 UDP session 的前兩個封包仍由 CPU 處理，經過防火牆要 39 到 49 µs；如果每個封包的來源 port 都不同，每個封包都是新的 session，就全部由 CPU 處理。
3. 對防火牆來說，由 CPU 處理也是正常的轉發方式，所以流量照常通過、不會告警；要確認流量有沒有被加速，得直接查 session 上的加速狀態。

量法

受測設備是 FortiGate 201G，版本 FortiOS 7.6.7，硬體加速由 NP7Lite 網路處理器負責。不同晶片能加速的項目不同，各版本的預設值也可能不一樣，以下數字只代表這個組合：

防火牆的 x1、x2 設成 virtual wire pair（兩個 port 像一條線一樣直接接通，不用設 IP，封包照樣要經過 policy 檢查），各用一條 3 m 的 DAC 接到交換器兩個不同 VLAN 的 port，量測拓樸如下圖：

1. 伺服器上 ExaNIC X25 的 port0 每 1 ms 送一個 64 bytes 的 UDP 請求，每輪 10000 個；請求之間不會互相排隊，量到的是防火牆幾乎沒有負載時的延遲。請求的目的 MAC 故意用一個沒有設備在用的位址，交換器學不到，就會把請求送到同一個 VLAN 的其他所有 port；多播那輪也會這樣送，因為這兩個 VLAN 沒有 IGMP querier，交換器不知道誰訂閱了這個群組。FortiGate 的多播封包要有 multicast policy 才會轉發，所以那一輪另外加了一條。
2. 所以同一個請求有兩份，一份直接送到 X25 的 port1（圖中 ①），另一份經過防火牆、從另一個 VLAN 回到交換器，再送到 port1（圖中 ②）。port1 接在交換器的 trunk port 上，兩份帶著不同的 VLAN 標籤，分得出哪一份是進防火牆前、哪一份是出防火牆後；兩份都由 port1 用同一個時鐘打硬體時戳，相減就是前後時間差，不用處理兩個時鐘之間的同步誤差。
3. ② 比 ① 多經過防火牆、多進出交換器一次，還多了線材。基準組把防火牆換成一條 1 m 的 DAC，前後時間差是 412 ns，包含多進出交換器一次跟這條線；防火牆組的兩條 3 m 比基準組多 5 m，約 24.8 ns（這款 DAC 實測每公尺約 4.96 ns）。所以防火牆本身＝前後時間差 − 412 ns − 24.8 ns，合計減掉約 0.44 µs。
4. 硬體加速開跟關照「開、關、關、開」的順序各量兩輪，讓量測期間的漂移在兩邊抵消。每輪開始前清掉這條流量的 session，讓每一輪都從建立 session 開始，session 的統計也只算這一輪；跑完馬上列出 session，確認有沒有被加速。

硬體加速開與關的延遲比較

依「開、關、關、開」量的四輪，加速開兩輪的前後時間差中位數一樣，關掉兩輪是 18.93 與 18.97 µs，同一個設定重量最多差 0.2%，遠小於加速開與關之間 14.4 µs 的差距。下圖是表中五輪的前後時間差（截圖裡的 after - before）：

硬體加速時，防火牆本身的延遲集中在 4.1 µs 附近；改由 CPU 處理後分布很寬，約 36% 落在 8 到 10 µs，其餘大致平均分布在 10 到 49 µs。兩者差這麼多，通常是因為網路處理器用固定的硬體流程轉發，每個封包花的時間幾乎一樣，CPU 則要等中斷、排程才處理到封包，等的時間不固定。只看中位數會低估改由 CPU 處理的影響，最慢的 1%（p99）從加速時的 4.14 µs 拉長到 47.94 µs，是 11.6 倍：

哪些封包會改由 CPU 處理

有沒有加速，用 diagnose sys session list 列出這條流量的 session 就看得到。下圖上半是硬體加速開（f1）跑完後的 session，npu_state 是 ofld-O（原方向已加速，測試流量沒有回程），statistic 只算到 2 個封包（org=92/2），其餘 9998 個由網路處理器直接轉發、沒經過 CPU。statistic 的 bytes 算的是 IP 封包長度，64 bytes 的 frame 扣掉 Ethernet 標頭跟 FCS 後是 46 bytes，2 個就是 92 bytes。下半是關掉加速（fd1）那輪，npu_state 是 no_offload，no_ofld_reason 寫出沒加速的原因 disabled-by-policy，statistic 算到 10000 個封包：

依 session 的狀態跟延遲，有三種情況封包會由 CPU 處理：

1. policy 關掉硬體加速（set auto-asic-offload disable），每個封包都由 CPU 處理，就是上圖下半那輪。Fortinet 文件也列出，policy 套用 proxy 模式的安全檢查（例如防毒、網頁過濾）時，session 一樣不會加速。
2. 開著加速時，每個新 UDP session 的前兩個封包也由 CPU 處理：建立 session 的封包本來就要由 CPU 比對 policy，這台實測是前兩個。加速開的兩輪跟多播那輪，第 1、2 個請求都是 39 到 49 µs，落在改由 CPU 處理時的範圍，第 3 個請求就降到 4.4 µs 以內，session 的統計也剛好是 2 個封包。從 session 列表的剩餘時間（expire）看，這台 UDP session 的閒置逾時（udp-idle-timer）是 180 秒，停頓超過 180 秒，session 就會被刪掉，之後的前兩個封包又由 CPU 處理。
3. 每個封包的來源 port 都不同時，例如程式每次送出都開一個新的 socket（系統會替每個 socket 分配不同的來源 port），每個 session 只有一個封包，正好落在由 CPU 處理的前兩個封包裡，所以每個封包都由 CPU 處理。diagnose sys session stat 顯示被加速的 session 數（npu_session_count）是 0；每個封包都要先建 session，中位數 21.29 µs，比關掉加速時還慢 2.8 µs。

巡檢腳本的實機驗證

巡檢腳本第一次對交換器跟防火牆實際執行，結果如下：

1. 防火牆的版本、HA 模式跟設定都和基線一致，CPU 使用率 0%。
2. 交換器抓到 LANZ 沒有在執行，原因是開啟 LANZ 的設定之前只改在 running-config，沒有存進 startup-config，交換器重開後就回到預設的關閉；服務照常、也沒有告警，這種設定沒存的問題要靠巡檢才抓得到。處理方式是重新開啟 LANZ 並存進 startup-config（write memory），下一次巡檢回到 OK 才算完成。
3. 交換器的 show running-config 需要特權模式（privileged EXEC），用 ssh 遠端執行的指令則是在一般模式下跑。離線測試用的是存下來的指令輸出，不會遇到權限問題，所以要連上實機才看得到。腳本已改成每個指令前先執行 enable，並在交換器上確認可行。

防火牆加速的維運檢查

後兩項是間接指標：新 session 開頭的封包都由 CPU 處理，建立速率突然變高，代表有大量封包沒被加速，CPU 使用率也會跟著上升。

session 建好之後封包才會加速，所以行情、下單的連線要在開盤前就建立（例如先登入、開始收行情），讓建立 session 的封包提早由 CPU 處理掉，開盤前再查一次 session 的加速狀態。交易時段中可能停頓超過 180 秒的 UDP 單播流量，可以在對應的 service（firewall service custom）上把 udp-idle-timer 設得比最長的停頓還長，只影響用到這個 service 的流量，設完照今天的量法確認停頓後的第一個封包。多播走的是 multicast policy，沒有 service 可以設，不適用這個做法；行情多播通常會定時送 heartbeat，交易時段中不會停頓這麼久。

明天把這 29 天的量法跟維運檢查整理成一份手冊。