網路遇到應用程式的品質不佳，由於牽扯到太多因子，很難判別。
網路管理員看得流量都是整體，沒有細節到個體，因此大家都不能用的話反而容易解決，然而少數人不能用的話，就會難以解決。
網管平時不對過於細節的部分做監控，因為這會非常消耗效能與儲存空間，監控時又會因前述所提影響體驗，per client的品質分析是不符合效益的，但是也在哪天狀況發生時束手無策，因為平時沒有監控所以沒有任何歷史資料可以回顧。
※ 網管人員不需要per client而且也難以做到，但是可以per VIP或是per 應用程式。
服務品質要斷定是哪一個節點造成問題，只有流量分析才能真正看清是那一段有問題，最簡易使用的就是錄包。
透過Wireshark可以在Client端記錄，從記錄中，我們可以清楚看到到一點是Client與Server間是誰有回誰沒有或是誰慢回。藉此逐漸往狀況根源去判斷。
如果Client或Server不方便使用Wireshark記錄，網管人員也可以在中途網路設備設定mirror或是錄包判斷。
於是，在Fortigate上針對特定兩端點連線錄包，就能在狀況發生時，透過錄包進行完整流量分析，進一步釐清是哪個環節造持或是縮小排查範圍。
如何進行
- 判斷點對點的連線資訊，Clinet IP與Server IP，Protocol，Port Number等。
- 在Fortigate上，依據點對點的連線資訊新增專屬Policy，並且使用CLI在此Policy上Disable auto-asic-offload。
- 透過Fortigate的診斷，使用點對點的連線資訊做過濾。
- 讓狀況復現，記錄從沒事到有狀況的過程。
模擬情境
今天要抓取Client(192.168.111.109)到Server(168.95.1.1)的ICMP。
點對點連線資訊
Clinet IP：192.168.111.109
Server IP：168.95.1.1
Protocol：ICMP
Port Number：無 ※只有TCP、UDP才有Port Number
新增專屬Policy並在CLI中Disable auto-asic-offload此Policy。
新增專屬Policy
在CLI中Disable auto-asic-offload此Policy
先使用「show firewall policy」取得policy id
如圖，id為20。然後使用以下指令去Disable auto-asic-offload此Policy。
config firewall policy
edit <id>
set auto-asic-offload disable
end透過Fortigate的診斷(Diagnose)，使用點對點的連線資訊做過濾
進去診斷，勾選過濾條件，使用進階，然後在過濾器輸入參數。
如果不太明白進階語法，可以將需求整理起來，詢問GhatGPT、Gemini之類的語言模型。
以下是抓取Client IP到Server IP以及Server IP到Clinet IP的所有封包。
(src host 192.168.111.109 and dst host 168.95.1.1) or (src host 168.95.1.1 and dst host 192.168.111.109)運作情況
覺得記錄得差不多了，就能使用「另存為pcap」，再來透過Wireshark打開來查看。
雜談
要是狀況一直持續，能復現，這個方式就好使。也能在收錄封包時，確保能收集到狀況時的流量狀況。
萬一只是一時的，就要這樣思考。
若想要確保透過設定改善避免狀況再次發生，就需要先確認狀況的根源，然後該狀況根源是能透過設定調整去預防。設定一直都是一樣，設定有狀況的話，通常早就持續發生，也就是具有可復現性。
要是什麼都看不出來就想改變環境設定去避免服務品質不佳再次發生，大多數都是病急亂投藥。
無線訊號健康度，只需要ping gateway就能看出來，如果都沒有任何掉包就非常健康。
我在撰寫這篇文章時也發現，我的電腦會不定時掉包，原來是連到給IOT設備的無線路由器，切回到正確的無線路由器就好多了。
Aruba上也有Client無線品質的健康度，若是Clinet健康度在50%以上，無線傳輸品質並便算及格。掉封包會在觸發無線Frame重傳機制並且用盡重傳次數之後，若平均要傳輸兩次才能成功傳輸一次，Aruba健康度定義是50%(1/2)。
以我剛剛的例子，就算掉封包，由於大多數網路使用TCP也會觸發重傳，避免缺失。不要掉太多封包在使用體感上就沒啥影響。