FortiGate SD-WAN selection on link quality

Posted on In Views:

Fortinet旗下的FortiGate推出SD-WAN Solution，其使用上算蠻容易上手的一個解決方案，而且完全符合我的需求(Inbound/Outbound NAT在同一個平台)，以目前6.2版的韌體穩定度算蠻不錯的。

現在已經發展到6.4，增強了很多功能。

前些日子在command底下看到一些數據，發現他選擇了比其他ISP還要high latency的線路當成主要出口，檢查了相關設定也沒發現異常，後來研究了官方的guide後得到一些心得。

Environment

以下是我的環境設定

  • SD-WAN Interface Members:
    • CHT
    • FET
    • TF
  • SD-WAN rule: Best Quality
  • Quality criteria: Latency
  • Interface preference: three ISP members(CHT, FET, TF)

Diagnose command

FortiGate CLI
1
2
3
4
5
6
7
8
9
FGT # diagnose sys virtual-wan-link service 1

Service(1):
    TOS(0x0/0x0), protocol(0: 1->65535), Mode(priority), link-cost-facotr(latency), link-cost-threshold(10), health-check(google)
    Members:
        1: Seq_num(1), alive, latency: 38.xxx, selected     (CHT)
        2: Seq_num(2), alive, latency: 35.xxx               (FET)
        3: Seq_num(3), alive, latency: 39.xxx               (TF)
    Internet Service: Google-Gmail(65646)

Event analysis

當下三條ISP的latency分別為CHT(38), FET(35), TF(39), 理論上best quality的順序應該是要FET, CHT, TF。

會發生這樣的狀況原因在於link-cost-threshold這個參數，預設值是10，針對這個參數官方的解釋為Percentage threshold change of link cost values that will result in policy route regeneration，意思當其他線路的latency quality比自己好超過10%，就會重新調整policy route。

依據上面的例子可以得知FET(35)只比CHT(38)好7%，並不會觸發policy route regeneration，而且一開始的interface member順序就是CHT, FET, TF，所以才會有選擇了high latency線路的現象。