はじめに
NTTデータ セキュリティ＆ネットワーク事業部 テクニカル・グレードの田中智志です。
近況：
昨年に引き続き、2025 Japan AWS Top Engineers(Networking)を受賞しました！大変光栄です！
本題：
本BlogではAmazon Web Services(AWS)上にデプロイしたFortiGateVMを含む構成でADVPN2.0とSD-WANのトラフィックコントロールについて試した内容を紹介しています。
第一回は検証構成と使用するテクニック、FortiGateVMのAWS上でのデプロイまで解説しました。第三回となる今回はSD-WANの設定編となります。
第一回：概要編はこちらです↓
第二回：ADVPN編はこちらです↓
本記事で扱うSD-WANの機能
SD-WANというキーワードは団体が定義するものや、SD-WAN機器のメーカが開発した機能を指す場合がありますが、本記事では「FortiGateの持つSD-WAN機能」のうち、主にインターネットブレイクアウトを試していきたいと思います。
構成
Spoke間の通信にはADVPN Shortcutを使用してHUBを経由しない直接通信を行います。
SD-WANルールを定義し、Spoke（Branch）のPCから、特定のインターネットアクセスはDIAされ、それ以外はSpoke（DC）にRIAされることを期待動作として検証していきます。
なお検証は以下のように段階的に行っていきたいと思います。
- すべてのインターネットアクセスをDIAする
- 優先パスとしてADVPNを選択する
- 優先パスとしてADVPN Shortcutを選択する
- ISDBを利用したトラフィックステアリングを行う
FortiGateのSD-WANを形成する要素
FortiGateでSD-WANを実現するための基本的な要素を見ていきます。これらの要素を組み合わせて従来のルーティング機能だけでは困難なトラフィックステアリングを独自のソフトウェアで実現しています。
SD-WANゾーン
SD-WANのトラフィックステアリングは、特定のトラフィックをどこから発出するかをコントロールします。あるトラフィックはVPNの先にあるリモートデバイスに発出し、あるトラフィックは直接インターネットに発出したいという場合は、VPN用にオーバーレイゾーン、インターネット用にアンダーレイゾーンを定義するなど用途ごとにゾーンを定義します。なお、定義したSD-WANゾーンはSD-WANだけでなく、ファイアウォールポリシーやルーティングにも流用することができます。
SD-WANメンバー
SD-WANゾーンに属するインターフェースをSD-WANメンバーとして決定します。例えばオーバーレイゾーンにはIPsec VPN用トンネルインターフェース、アンダーレイゾーンにはWAN側の物理インターフェースを所属させます。
パフォーマンスSLA（ヘルスチェック）
回線の品質を監視する条件を定義します。レイテンシ、パケットロス、ジッターを監視することができ、それらの状況をもとに後述のSD-WANルールでトラフィックを最適なインターフェースから発出するようにコントロールすることが可能です。また、パフォーマンスSLA測定用のプローブパケットの送信間隔や、障害および復旧と判定するまでの状態検出の回数なども細かく設定できます（今回の検証では省略しています）。
SD-WANルール
どのアプリケーション用トラフィックをどのインターフェースから発出するかのルールを定義します。複数のインターフェースを選択し優先度をつけて冗長化したり、ロードバランスすることができます。パフォーマンスSLAを併用することで、障害を検出した回線や一定の品質を満たさなくなった回線は使用しないといったコントロールも可能です。なお、どのSD-WANルールにも一致しなかったトラフィックについては暗黙のSD-WANルールが適用されます。
ISDB(Internet Service Database)
Fortinetが独自に運営する、インターネット上のサービスをIPアドレスやプロトコルのポート番号で定義したデータベースです。Microsoft365など、手動でIPアドレスを定義してトラフィックをステアリングすることが困難なSaaSサービスも、ISDBでサービスを指定することで簡単にアプリケーションを識別できます。ただし、ISDBはリアルタイムにSaaSサービスのIPアドレス情報を追従しているわけではないため、ISDBに未反映のトラフィックをRIAで救済するなどの考慮が重要です。 なおISDBの情報はAntiVirusやIPSなどのUTM機能と同様にFortiGuardサーバから情報を取得します。また、ISDBはFortiGateの標準機能のため、オプションライセンスは不要で利用可能です。
設定１：すべてのインターネットアクセスをDIAする
まずはすべてのインターネット宛てトラフィックをローカルブレークアウトする設定を確認していきます。なおADVPN、ファイアウォールポリシー、BGPの設定は第二回で設定済みのため省略しており、今回はSD-WAN関連の設定のみ記載しています。
Spoke(Branch：FortiGate 40F)
SD-WANゾーンとSD-WANメンバー（第二回で定義済み）
アンダーレイは「underlay」ゾーンとしてWANインターフェースをSD-WANメンバーとし、オーバーレイは「ADVPN」としてトンネルインターフェースをSD-WANメンバーとなるように定義します。この時定義したSD-WANメンバーのedit IDは後述するSD-WANルールでSD-WANメンバーを指定する際に使用します。（ADVPNのID:1、underlayのID:2）
config system sdwan
set status enable
config zone
edit "underlay"
next
edit "ADVPN"
next
end
config members
edit 1
set interface "advpn"
set zone "ADVPN"
set source 10.202.7.250
next
edit 2
set interface "wan"
set zone "underlay"
set gateway 192.168.1.1
next
end
end
set source x.x.x.xIKEバージョン2はADVPN2.0の必須要件です。
set gateway x.x.x.xインターネット宛のゲートウェイを環境に応じて設定します。
デフォルトルート（第二回で定義済み）
SD-WANでは基本的にSD-WANルールによってトラフィックステアリングします。ルーティングは各SD-WANゾーンに対してデフォルトルートを定義しておきます。
config router static
edit 1
set distance 1
set sdwan-zone "underlay" "ADVPN"
next
end
すべてのインターネットアクセスをDIA
パフォーマンスSLAにはGoogleのDNSサーバ宛にSLA用のプローブパケットを発信するように定義し、発信するインターフェースとしてunderlayを設定します。config sla以下の設定はそれぞれ回線のレイテンシ(ms)、ジッター(ms)、パケットロス率(%)で、これらの状態をリアルタイムで監視し最適なSD-WANメンバーを選択するようにできます。SD-WANルールはすべてのトラフィックを対象としたものを作成し、パフォーマンスSLAを満たす場合にunderlayを利用してトラフィックを出力するように定義します。LANからunderlay向けのファイアウォールポリシー（第二回で定義済み）に、NAPTを動作させる設定を追加します。
config system sdwan
config health-check
edit "Google_DNS"
set server "8.8.8.8" "8.8.4.4"
set members 2
config sla
edit 1
set latency-threshold 300
set jitter-threshold 30
set packetloss-threshold 1
next
end
next
end
config service
edit 2
set name "InternetAccess"
set mode sla
set dst "all"
set src "all"
config sla
edit "Google_DNS"
set id 1
next
end
set priority-members 2
next
end
end
config firewall policy
edit 1
set nat enable
next
end
動作確認
Spoke(Branch：FortiGate 40F)
diagnoseコマンドでSD-WANルールの状態を確認し、インターネット宛のTracerouteを実行してみます。
# diagnose sys sdwan service4
Service(1): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 2
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Members(1):
1: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 <1 ms <1 ms <1 ms 192.168.1.1（WAN側IFのゲートウェイアドレス）
3 1459 ms * * =ISPのIPアドレス=
4 3 ms 3 ms 4 ms =ISPのIPアドレス=
5 3 ms 3 ms 2 ms =ISPのIPアドレス=
6 4 ms 3 ms 3 ms =ISPのIPアドレス=
7 5 ms 7 ms 6 ms =ISPのIPアドレス=
8 3 ms 3 ms 3 ms =ISPのIPアドレス=
9 3 ms 3 ms 4 ms 108.170.248.243（Google）
10 3 ms 3 ms 3 ms 142.250.229.51（Google）
11 2 ms 3 ms 3 ms 8.8.8.8
トレースを完了しました。
インターネット宛のトラフィックが直接WAN側インターフェースから出力されていることが確認できました。
参考値としてスピードテストを行ってみます。
設定２：優先パスとしてADVPNを選択する
この設定では、すべてのインターネット宛てトラフィックについてADVPN経由でHUBからRIAし、HUB経由のパフォーマンスSLAを満たさない場合のみunderlayからローカルブレークアウトする設定を確認していきます。
Spoke(Branch：FortiGate 40F)
インターネットアクセス用のパフォーマンスSLAとSD-WANルールにSD-WANメンバーとしてADVPN(メンバーID：１)を参加させます。SD-WANルールでは「set priority-members」コマンドの後にSD-WANメンバーのIDを定義します。定義したSD-WANメンバーの順番がそのままパスを選択する優先順位になります。ここではunderlay(ID:2)よりもADVPN(ID:1)を優先させてみるため、「1」→「2」の順番で定義しています。
パフォーマンスSLAとSD-WANルール
config system sdwan
config health-check
edit "Google_DNS"
set members 2 1
next
end
config service
edit 2
set priority-members 1 2
next
end
end
HUB(FortiGateVM)
HUBからRIAするためのNAPT設定を追加します。
ファイアウォールポリシー
config firewall policy
edit 10
set name "InternetAccess"
set srcintf "ADVPN"
set dstintf "underlay"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set nat enable
next
end
動作確認１：HUB経由のRIA
Spoke(Branch：FortiGate 40F)
diagnoseコマンドでSD-WANルールの状態を確認し、インターネット宛のTracerouteを実行してみます。
# diagnose sys sdwan service4
Service(1): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Members(2):
1: Seq_num(1 advpn ADVPN), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
2: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 191 ms 191 ms 191 ms 10.2.1.11（AWS HUBのループバックインターフェース）
3 * * * 要求がタイムアウトしました。
4 201 ms 201 ms 201 ms =グローバルIPアドレス=
5 201 ms 201 ms 200 ms =グローバルIPアドレス=
6 200 ms 199 ms 200 ms 192.178.249.201（Google）
7 201 ms 200 ms 200 ms 108.170.230.235（Google）
8 200 ms 199 ms 200 ms 8.8.8.8
トレースを完了しました。
diagnoseコマンドの結果から、MembersがADVPN→underlayの優先順位として表示されていることが確認できます。 また、Tracerouteの結果もAWS上のHUBを経由してインターネットへアクセスしていることが確認できます。 なお、今回の検証環境ではHUBとなるFortiGateVMをAWSの海外リージョンにデプロイしており、HUBへのレイテンシをあえて大きくすることで経路選択結果の違いをわかりやすく観測できるようにしています。クラウドが身近になりこのような実験環境が簡単に作れますので、ネットワークエンジニアにとって非常にありがたい世の中になったなと実感します。参考値としてスピードテストを行ってみます。
underlayからインターネットアクセスした場合と比較してレイテンシが大きいことと、サーバがChicagoになっていることが確認できます。
動作確認２：HUB経由のパフォーマンスSLAが低下した際のDIA
意図的にHUB経由のパフォーマンスSLAを低下させるため、HUBからインターネットへのインターフェースにおいてトラフィックシェーピングを設定してみます。
HUB(FortiGateVM)
Traffic-Shaping
config firewall shaper traffic-shaper
edit 1K
set maximum-bandwidth 1
next
end
config firewall shaping-policy
edit 1
set name "TEST"
set service "ALL"
set dstintf "port1"
set traffic-shaper "1K"
set traffic-shaper-reverse "1K"
set srcaddr "all"
set dstaddr "all"
next
end
この状態でSpoke(Branch)でdiagnoseコマンドでSD-WANルールの状態を確認してみます。
Spoke(Branch：FortiGate 40F)
# diagnose sys sdwan service4 2
Service(2): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(123), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Members(2):
1: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
2: Seq_num(1 advpn ADVPN), dead, sla(0x0), gid(0), cfg_order(0), local cost(0)
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
パフォーマンスSLAが低下し、SD-WANメンバーのADVPNがdead判定となり、先ほどまで2番手になっていたunderlayの優先順位が上がったことが確認できます。この時、実際のトンネルインターフェースはアップしたままです。パフォーマンスSLAを満たしていない場合sla(0x0)と表示され、SD-WANルール上では当該インターフェイスが使用されないことを意味しており、インターフェースのUp/Downと区別するように注意しましょう。
続けてtracerouteを実行してみます。
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 190 ms 189 ms 189 ms 10.2.1.11（AWS HUBのループバックインターフェース）
~SNIP~
11 3 ms 3 ms 3 ms 8.8.8.8
トレースを完了しました。
すると、実際のトラフィックはまだAWS上のHUBに転送されています。これは次に述べるFortiGateのデフォルト設定に起因しています。
テクニック１：NAPT利用経路の即時切替（snat-route-change）
NAPTを利用する経路がSD-WANルールの影響などにより変更になった場合に、既存のセッションを切断し新しい経路に切り替えるかどうかを決めるパラメータです。デフォルトはDisableになっており、経路変更が発生してもセッションは既存の経路を利用しようとするため、SD-WANのパフォーマンスSLAによるトラフィックステアリングをリアルタイムに行いたい場合にはEnableにしておく必要があります。
Spoke(Branch：FortiGate 40F)
snat-route-change
config system global
set snat-route-change enable
end
上記を設定した後に再度tracerouteを実行してみます。
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 <1 ms <1 ms 1 ms 192.168.1.1
~SNIP~
9 * * 198 ms 8.8.8.8
トレースを完了しました。
実際のトラフィックもunderlayから転送されるように経路が切り替わり、期待通りの動作になりました。
（準備作業）次の設定を行う前に、通常の状態に戻すためHUBからインターネットへのトラフィックシェーピングを元に戻しておきましょう。
HUB(FortiGateVM)
HUBのTraffic-Shaping無効化
config firewall shaping-policy
edit 1
set status disable
next
end
設定３：優先パスとしてADVPN Shortcutを選択する
この設定では、すべてのインターネット宛てトラフィックについてADVPN Shortcut経由のSpoke(DC)からRIAし、Spoke(DC)経由のパフォーマンスSLAを満たさない場合のみunderlayからローカルブレークアウトする設定を確認していきます。
Spoke(Branch)がSpoke(DC)からデフォルトルートをBGPで学習するように設定したいところですが、Spoke(Branch)はすでにスタティックルートのデフォルトルートをunderlayとADVPNに設定しています。FortiGateの仕様として、スタティックルートとBGPルートの両方で有効なデフォルトルートを同時に保持することはできません。スタティックルートのアドミニストレーティブディスタンス（AD）がBGPルートと同じ値に変更された場合でもスタティックルートだけがルーティングテーブルに選出されます。解決策の一つとなりますが、今回はSpoke(DC)からBGPでアドバタイズするデフォルトルートを「0.0.0.0/1」と「128.0.0.0/1」に分割するように設定してみます。
Spoke(DC：FortiGate 40F)
Spoke(DC)からのインターネットアクセスの設定
Spoke(Branch)からADVPN経由でSpoke(DC)のunderlayにインターネットへのトラフィックが転送できるように設定します。
config firewall policy
edit 10
set name "InternetAccess"
set srcintf "ADVPN"
set dstintf "underlay"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set nat enable
next
end
分割したデフォルトルートのアドバタイズ
「0.0.0.0/1」と「128.0.0.0/1」をスタティックルートで定義しBGPに再配送します。
config router static
edit 11
set dst 0.0.0.0 128.0.0.0
set gateway 192.168.1.1
set sdwan-zone underlay
next
edit 12
set dst 128.0.0.0 128.0.0.0
set gateway 192.168.1.1
set sdwan-zone underlay
next
end
config router prefix-list
edit second_default
config rule
edit 1
set prefix 0.0.0.0 128.0.0.0
unset ge
unset le
next
edit 2
set prefix 128.0.0.0 128.0.0.0
unset ge
unset le
next
end
next
end
config router route-map
edit static2bgp
config rule
edit 1
set match-ip-address "second_default"
unset set-ip-prefsrc
next
end
next
end
config router bgp
config redistribute static
set status enable
set route-map static2bgp
end
end
動作確認１：ADVPN Shortcut経由のRIA
Spoke(Branch：FortiGate 40F)
まずはADVPN Shortcutが確立される前のSpoke(Branch)のルーティングテーブルを見てみます。
# get router info routing-table all
~SNIP~
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, wan, [1/0]
[1/0] via advpn tunnel , [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
C 10.202.7.250/32 is directly connected, Lo
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP)), 04:06:23, [1/0]
C 192.168.1.0/24 is directly connected, wan
C 192.168.7.0/24 is directly connected, lan
この状態ではデフォルトルートがunderlayとADVPNに向いているだけです。続いて、Spoke to Spokeのshortcutトンネルを確立させるためSpoke間のトラフィックを発生させます。
PS C:\Users\user01> ping 192.168.2.100
192.168.2.100 に ping を送信しています 32 バイトのデータ:
192.168.2.100 からの応答: バイト数 =32 時間 =327ms TTL=61
192.168.2.100 からの応答: バイト数 =32 時間 =327ms TTL=61
192.168.2.100 からの応答: バイト数 =32 時間 =327ms TTL=61
192.168.2.100 からの応答: バイト数 =32 時間 =6ms TTL=62
192.168.2.100 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 6ms、最大 = 327ms、平均 = 246ms
最初の2パケットほどHUBを経由し、その後確立されたADVPN Shortcutを利用していることがラウンドトリップタイムの出力結果から確認できます。ルーティングテーブルを確認します。
# get router info routing-table all
~SNIP~
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via 192.168.1.1, wan, [1/0]
[1/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
B 0.0.0.0/1 [200/0] via 10.200.1.250 (recursive via advpn_0 tunnel *.*.*.*(Spoke（DC）のGlobal IPアドレス)), 00:00:31, [1/0]
S 10.200.1.250/32 [15/0] via advpn_0 tunnel *.*.*.*(Spoke（DC）のGlobal IPアドレス), [1/0]
S 10.202.1.11/32 [15/0] via advpn tunnel *.*.*.*(AWSのElastic IP), [1/0]
C 10.202.7.250/32 is directly connected, Lo
B 128.0.0.0/1 [200/0] via 10.200.1.250 (recursive via advpn_0 tunnel *.*.*.*(Spoke（DC）のGlobal IPアドレス)), 00:00:31, [1/0]
B 192.168.0.0/16 [200/0] via 10.202.1.11 (recursive via advpn tunnel *.*.*.*(AWSのElastic IP)), 06:22:59, [1/0]
C 192.168.1.0/24 is directly connected, wan
B 192.168.2.0/24 [200/0] via 10.200.1.250 (recursive via advpn_0 tunnel *.*.*.*(Spoke（DC）のGlobal IPアドレス)), 00:00:31, [1/0]
C 192.168.7.0/24 is directly connected, lan
「0.0.0.0/1」と「128.0.0.0/1」に分割したデフォルトルート、およびSpoke(DC)のLAN側ルートをSpoke(DC)からBGPで学習していることが分かります。
SD-WANルールの状態を確認します。
# diagnose sys sdwan service4
Service(1): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(5), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Member sub interface(3):
2: seq_num(1), interface(advpn):
1: advpn_0(26)
Members(3):
1: Seq_num(1 advpn_0 ADVPN), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
2: Seq_num(1 advpn ADVPN), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
3: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
ADVPN Shortcutが確立されたことにより、Spoke to SpokeのShortcutが新たなSD-WANメンバー「advpn_0」として表示されるようになりました。 2番手以降は前述の設定どおり、ADVPN(HUB)→underlayの優先順位となっています。
インターネット宛のTracerouteを実行してみます。
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 4 ms 3 ms 4 ms 192.168.1.251（Spoke(DC)のWAN側インターフェース）
~SNIP~
13 6 ms 5 ms 5 ms 8.8.8.8
トレースを完了しました。
Spoke（DC)経由でインターネットアクセスを行っていることが確認できました。スピードテストの結果です。
この検証環境においては、回線速度とレイテンシだけに着目するとDIA＞Shortcut経由のRIA＞HUB経由のRIAという順序で回線品質が良い、という状況を意図的に作っており、実際の挙動も期待通りの確認結果となりました。
動作確認２：パフォーマンスSLAが低下した場合のDIA
パフォーマンスSLAが条件を満たさない場合はunderlayからDIAすることを確認します。ところで今はADVPN Shortcut経由でSpoke(DC)からRIAを行っていますが、パフォーマンスSLAの測定もADVPN Shortcut経由で行われているのでしょうか？試しに前の設定で行ったようにHUBのトラフィックシェーピングを有効にして、HUB経由のインターネットトラフィックの品質を意図的に低下させてみます。
HUB(FortiGateVM)
Traffic-Shaping
config firewall shaping-policy
edit 1
set status enable
next
end
するとSpoke(Branch)におけるSD-WANルールはこのような状態になりました。
Spoke(Branch：FortiGate 40F)
# diagnose sys sdwan service4
Service(2): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Member sub interface(3):
3: seq_num(1), interface(advpn):
1: advpn_0(25)
Members(3):
1: Seq_num(1 advpn_0 ADVPN), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
2: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
3: Seq_num(1 advpn ADVPN), dead, sla(0x0), gid(0), cfg_order(0), local cost(0)
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
HUB経由のパフォーマンスSLAはdead判定となっていますが、Spoke(DC)経由、つまりADVPN Shortcut経由のパフォーマンスSLAはaliveとなっており、パフォーマンスSLA用のプローブはきちんとADVPN Shortcut経由で行われるようになっているようです。
次に、HUBと同様にSpoke(DC)でもインターネットに向かうインターフェースでトラフィックシェーピングをかけて意図的にパフォーマンスSLAを低下させてみようと思います。
Spoke(DC：FortiGate 40F)
Traffic-Shaping
config firewall shaper traffic-shaper
edit 1K
set maximum-bandwidth 1
next
end
config firewall shaping-policy
edit 1
set name "TEST"
set service "ALL"
set dstintf "wan"
set traffic-shaper "1K"
set traffic-shaper-reverse "1K"
set srcaddr "all"
set dstaddr "all"
next
end
SD-WANルールの状態を確認してみます。
Spoke(Branch：FortiGate 40F)
# diagnose sys sdwan health-check
~SNIP~
Health Check(Google_DNS):
Seq(1 advpn): state(dead), packet-loss(2.000%) sla_map=0x0
Seq(1 advpn_0): state(alive), packet-loss(0.000%) latency(3.916), jitter(0.498), mos(4.402), bandwidth-up(999987), bandwidth-dw(999979), bandwidth-bi(1999966) sla_map=0x1
Seq(2 wan): state(alive), packet-loss(0.000%) latency(2.513), jitter(0.140), mos(4.403), bandwidth-up(999949), bandwidth-dw(999941), bandwidth-bi(1999890) sla_map=0x1
# diagnose sys sdwan service4 2
Service(2): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(359), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Member sub interface(3):
3: seq_num(1), interface(advpn):
1: advpn_0(25)
Members(3):
1: Seq_num(1 advpn_0 ADVPN), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
2: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
3: Seq_num(1 advpn ADVPN), dead, sla(0x0), gid(0), cfg_order(0), local cost(0)
Src address(1):
0.0.0.0-255.255.255.255
Dst address(1):
0.0.0.0-255.255.255.255
想定と異なる結果となりました。Spoke(Branch)におけるSpoke(DC)経由のパフォーマンスSLAが低下せずパケットロス率は0%のままです。SD-WANルールの優先順位も1番手のままになっています。調べたところ、ADVPN ShortcutのパフォーマンスSLAに使用されるプローブはトンネル間アドレスとなるためのようです。
確認のため、Spoke(Branch)でSnifferを見てみます。
# diagnose sniffer packet any "host 10.202.7.250 or net 8.8.0.0 mask 255.255.0.0 and icmp" 4
interfaces=[any]
filters=[host 10.202.7.250 or net 8.8.0.0 mask 255.255.0.0 and icmp]
0.204910 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.205095 advpn out 10.202.7.250 -> 10.202.1.11: icmp: echo request
0.205166 advpn out 10.202.7.250 -> 8.8.8.8: icmp: echo request
0.205219 advpn out 10.202.7.250 -> 8.8.4.4: icmp: echo request
0.205285 wan out 192.168.1.252 -> 8.8.8.8: icmp: echo request
0.205329 wan out 192.168.1.252 -> 8.8.4.4: icmp: echo request
0.205382 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
0.205489 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.205541 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.205592 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.207665 wan in 8.8.8.8 -> 192.168.1.252: icmp: echo reply
0.208132 wan in 8.8.4.4 -> 192.168.1.252: icmp: echo reply
0.208811 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.208814 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.208818 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.208837 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.249642 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo request
0.249673 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo reply
0.344887 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.349592 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.375038 advpn in 10.202.1.11 -> 10.202.7.250: icmp: echo reply
0.377469 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
0.383432 advpn in 8.8.8.8 -> 10.202.7.250: icmp: echo reply
0.383674 advpn in 8.8.4.4 -> 10.202.7.250: icmp: echo reply
0.484870 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.488920 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.634876 advpn_0 out 10.202.7.250 -> 10.200.1.250: icmp: echo request
0.638681 advpn_0 in 10.200.1.250 -> 10.202.7.250: icmp: echo reply
0.734881 advpn out 10.202.7.250 -> 10.202.1.11: icmp: echo request
パフォーマンスSLA用プローブパケット（ICMP）の送信元は「10.202.7.250」、宛先は「8.8.8.8」「8.8.4.4」に設定していますが、上記の通り当該パケットはADVPN Shortcutの「advpn_0」向けには送信されていませんでした。
適切な設定は他にある可能性がありますが、ひとまず意図的にADVPN Shortcut向けのパフォーマンスSLAを低下させればよいため以下のファイアウォールポリシーを設定します。
Spoke(DC：FortiGate 40F)
RIA向けトラフィックを遮断
config firewall address
edit "BranchLoopback"
set subnet 10.202.0.0 255.255.0.0
next
end
config firewall policy
delete 4
edit 4
set name "Shortcut Down"
set srcintf "ADVPN"
set dstintf "Lo"
set action deny
set srcaddr "BranchLoopback"
set dstaddr "all"
set schedule "always"
set service "ALL"
next
edit 5
set name "VPN to Loopback"
set srcintf "ADVPN"
set dstintf "Lo"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "BGP" "PING"
next
end
パフォーマンスSLAの状態確認と、tracerouteを実行してみます。
# diagnose sys sdwan health-check
~SNIP~
Health Check(Google_DNS):
Seq(1 advpn): state(dead), packet-loss(2.000%) sla_map=0x0
Seq(1 advpn_0): state(dead), packet-loss(100.000%) sla_map=0x0
Seq(2 wan): state(alive), packet-loss(0.000%) latency(2.739), jitter(0.225), mos(4.403), bandwidth-up(999952), bandwidth-dw(999945), bandwidth-bi(1999897) sla_map=0x1
PS C:\Users\user01> tracert -d 8.8.8.8
8.8.8.8 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.7.250
2 21 ms 23 ms 23 ms 192.168.1.1
~SNIP~
11 3 ms 3 ms 2 ms 8.8.8.8
トレースを完了しました。
ADVPN ShortcutのSD-WANメンバがdeadになり、期待通りにunderlayからのDIAとなりました。
（準備作業）次の設定を行う前に、通常の状態に戻しておきましょう。
HUB(FortiGateVM)
HUBのTraffic-Shaping設定無効化
config firewall shaping-policy
edit 1
set status disable
next
end
Spoke(DC：FortiGate 40F)
Spoke(DC)のTraffic-Shaping設定無効化
config firewall policy
edit 4
set status disable
next
end
設定４：ISDBを利用したトラフィックステアリングを行う
この設定では、WEB会議ツールのZoom MeetingsについてISDBベースで識別しトラフィックをステアリングするSD-WANルールをGUIで作成します。CLIでも設定は可能ですが、ISDBにおけるSaaSサービスを指定する操作の明快さや設定誤りを回避するためにもGUIでの設定をお勧めします。
このケースのように非常に大きな帯域を消費するSaaS向けトラフィックをDC拠点からオフロードするためのローカルブレークアウトは実案件でも大変有用であり、多くの企業においてSD-WANを導入するモチベーションになっています。
テクニック２：FortiGate自発パケットの送信元IPアドレス
FortiGateからのDNSクエリやFortiGuardサーバへの通信に使用する送信元IPアドレスについて、デフォルトではWAN側インターフェースのIPアドレスを使用します。もしFortiGateのWAN側インターフェースのルート情報を他のSpokeへアドバタイズしない設計の場合、これらのパケットがADVPN Shortcut経由のRIAに転送されるとDNSやFortiGuardサーバとの通信がNGになる可能性があります。FortiGateの自発パケットにおける送信元IPアドレスをループバックインターフェースのIPアドレスなどに設定し、無用なトラブルを避けましょう。なお、自発パケットの発信インターフェース選択基準についてはFortiGuardやDNSなどの各設定において「set interface-select-method {auto|sdwan|specify}」で変更可能です。
Spoke(Branch：FortiGate 40F)
DNSとFortiGuard宛自発パケットの送信元IPアドレス
config system dns
set source-ip 10.202.7.250
end
config system fortiguard
set source-ip 10.202.7.250
end
事前準備：RIAのトラフィックシェーピング
Web会議の音声や映像品質の比較でローカルブレークアウトの効果測定をするため、RIA側のインターネット帯域を意図的に絞っておきます。昨今のWeb会議ツールは数Mbpsでもそれなりの品質を提供可能なため500Kbpsとしました。ちなみに、これ以上帯域を絞るとWeb会議自体の開始ができなくなりました。
Spoke(DC：FortiGate 40F)
インターネット向けトラフィックの帯域を500Kbpsに制限
config firewall shaper traffic-shaper
edit 500K
set maximum-bandwidth 500
next
end
config firewall shaping-policy
edit 1
set traffic-shaper "500K"
set traffic-shaper-reverse "500K"
set status enable
next
end
Spoke(Branch)からRIAでスピードテストをしてみます。
非常に低速となり、うまくRIAのトラフィックシェーピングが効いているようです。
事前準備の動作確認：RIAでのWEB会議の画質
これまでに行った設定で、すべてのインターネットアクセスは通常RIAを経由するようになっており、かつSpoke(DC)のRIAで帯域を絞っているため、WEB会議が低品質になっています。（画像をクリックして拡大してください）
設定：Zoom MeetingsをDIA
ここからはZoom Meetings用のトラフィックをISDBで識別し、DIAを行う設定をしていきましょう。
Spoke(Branch：FortiGate 40F)
新規作成したSD-WANルールは既存のルールの下に作成されますので、このままだとRIA用のSD-WANルールしか評価されません。そのためドラッグ＆ドロップでRIA用のSD-WANルールよりも上に持っていきます。
なお、CLIでも以下のコマンドでSD-WANルールの順序を変更することができます。
config system sdwan
config service
move 3 before 2
end
GUIで設定したパフォーマンスSLAとSD-WANルールをCLIで確認してみます。GUIでSD-WANルールの設定順をドラッグ＆ドロップで入れ替えましたが、CLIでも順番が入れ替わっていることがわかります。
config system sdwan
~SNIP~
config health-check
~SNIP~
edit "Zoom"
set server "zoom.us"
set members 1 2
config sla
edit 1
set latency-threshold 300
set jitter-threshold 30
set packetloss-threshold 1
next
end
next
end
config service
~SNIP~
edit 3
set name "Zoom"
set mode sla
set internet-service enable
set internet-service-name "Zoom.us-Zoom.Meeting"
config sla
edit "Zoom"
set id 1
next
end
set priority-members 2 1
next
edit 2
set name "InternetAccess"
set mode sla
set dst "all"
set src "all"
config sla
edit "Google_DNS"
set id 1
next
end
set priority-members 1 2
next
end
動作確認：Zoom MeetingsをDIAしWeb会議の品質を向上
さて、ここまでに設定したSD-WANルールでうまくZoom MeetingsをDIAできているでしょうか。（画像をクリックして拡大してください）
画質は低いままになっています。SD-WANルールの状態を確認してみます。
# diagnose sys sdwan service4
~SNIP~
Service(3): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 3
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Member sub interface(3):
3: seq_num(1), interface(advpn):
1: advpn_0(25)
Members(3):
1: Seq_num(1 advpn_0 ADVPN), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
2: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
3: Seq_num(1 advpn ADVPN), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
Internet Service(1): Zoom.us-Zoom.Meeting(6422646,0,0,0)
~SNIP~
上記の通り、ADVPN Shortcutが最優先のSD-WANメンバーになっており、Spoke(DC)にRIAしてしまっていました。これは以下の仕様がFortiGateのデフォルト設定であるためです。
テクニック３：Shortcut Priority
SD-WANルールにおいてADVPN Shortcutはどのような基準で優先順位が決まるのでしょうか。FortiGateの仕様では以下コマンドのオプションでADVPN Shortcutの優先度を設定することが可能になっており、初期値は「auto」（ADVPN2.0が有効な場合、自動的にADVPN Shortcutの優先度を高くする設定）のため、意図的にADVPN Shortcutの優先順位を下げたい場合は「disable」にする必要があります。
# config service
edit 3
set shortcut-priority ?
enable Enable a high priority of ADVPN shortcut for this service.
disable Disable a high priority of ADVPN shortcut for this service.
auto Auto enable a high priority of ADVPN shortcut for this service if ADVPN2.0 enabled.
Zoom MeetingsをDIAするためのSD-WANルールでこの設定をDisableにしてみます。
Spoke(Branch：FortiGate 40F)
Shortcut Priorityの無効化
config service
edit 3
set shortcut-priority disable
next
end
SD-WANルールの状態を確認してみます。
# diagnose sys sdwan service4
~SNIP~
Service(3): Address Mode(IPV4) flags=0x4200 use-shortcut-sla use-shortcut
Tie break: cfg
Shortcut priority: 0
Gen(1), TOS(0x0/0x0), Protocol(0): src(1->65535):dst(1->65535), Mode(sla), sla-compare-order
Member sub interface(3):
3: seq_num(1), interface(advpn):
1: advpn_0(25)
Members(3):
1: Seq_num(2 wan underlay), alive, sla(0x1), gid(0), cfg_order(0), local cost(0), selected
2: Seq_num(1 advpn_0 ADVPN), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
3: Seq_num(1 advpn ADVPN), alive, sla(0x1), gid(0), cfg_order(1), local cost(0), selected
Internet Service(1): Zoom.us-Zoom.Meeting(6422646,0,0,0)
Shortcut Priorityが0（無効）と表示されており、SD-WANメンバーの優先順位もADVPN Shortcutがunderlayより低くなっていることが分かります。
なお、これまでの検証ではICMPを利用して通信経路の動作確認を行ってきましたが、ISDBで識別したサービス宛の実際のトラフィックがどのSD-WANメンバーから送信されたのかを確認する方法としてtracerouteは利用できません。CLIの「diagnose sys session list」やSnifferといったコマンドによる確認、またはGUIのダッシュボードでSD-WANトラフィックを確認することが可能です。個人的に最もお手軽で分かりやすいのはSnifferコマンドで送信に使用したインターフェースを確認することだと思います。実際に確認してみましょう。まずはCLIです。
# diagnose sys session list
~SNIP~
session info: proto=6 proto_state=01 duration=140 expire=3597 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=92/2/1 reply=52/1/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=19->5/5->19 gwy=192.168.1.1/192.168.7.100 <---underlayのGateway
hook=post dir=org act=snat 192.168.7.100:53350->170.114.52.2:443(192.168.1.252:53350)
hook=pre dir=reply act=dnat 170.114.52.2:443->192.168.1.252:53350(192.168.7.100:53350)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=1 pol_uuid_idx=658 auth_info=0 chk_client_info=0 vd=0
serial=00006c89 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=2 sdwan_service_id=3 <---SD-WANルールのID3：Zoom Meetings DIA用
rpdb_link_id=ff000003 ngfwid=n/a
npu_state=0x000c00 ofld-O ofld-R
npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=64/72, ipid=72/64, vlan=0x0000/0x0000
vlifid=72/64, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=0/2, ha_divert=0/0
~SNIP~
# diagnose sniffer packet any "net 170.0.0.0 mask 255.0.0.0" 4
interfaces=[any]
filters=[net 170.0.0.0 mask 255.0.0.0]
0.108010 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
0.430816 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
0.430881 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
0.434483 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
0.628448 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
0.940823 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
0.940889 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
0.944403 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
1.137502 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
1.470827 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
1.470894 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
1.474475 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
1.668651 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
2.000829 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
2.000897 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
2.004557 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
2.198029 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
2.520819 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
2.520883 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
2.524468 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
2.717900 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
3.040854 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
3.040921 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
3.044305 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
3.226244 lan in 192.168.7.100.50651 -> 170.114.52.2.443: syn 3473043326
3.226413 wan out 192.168.1.252.50651 -> 170.114.52.2.443: syn 3473043326
3.229567 wan in 170.114.52.2.443 -> 192.168.1.252.50651: syn 335574549 ack 3473043327
3.229654 lan out 170.114.52.2.443 -> 192.168.7.100.50651: syn 335574549 ack 3473043327
3.230099 lan in 192.168.7.100.50651 -> 170.114.52.2.443: ack 335574550
3.230123 wan out 192.168.1.252.50651 -> 170.114.52.2.443: ack 335574550
3.237561 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
3.560825 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
3.560900 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
3.564510 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
3.757537 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
4.070830 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
4.070904 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
4.074494 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
4.267450 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
4.590831 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
4.590906 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
4.594301 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
4.788001 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
5.090972 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
5.091047 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
5.094818 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
5.288793 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
5.610837 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
5.610914 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
5.614458 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
5.806667 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
6.140830 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
6.140903 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
6.143730 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
6.285744 lan in 192.168.7.100.50654 -> 170.114.193.213.443: syn 1333448655
6.285920 wan out 192.168.1.252.50654 -> 170.114.193.213.443: syn 1333448655
6.286382 lan in 192.168.7.100.50655 -> 170.114.192.213.443: syn 1368868225
6.286459 wan out 192.168.1.252.50655 -> 170.114.192.213.443: syn 1368868225
6.290594 wan in 170.114.193.213.443 -> 192.168.1.252.50654: syn 1108017471 ack 1333448656
6.290619 wan in 170.114.192.213.443 -> 192.168.1.252.50655: syn 850091368 ack 1368868226
6.290682 lan out 170.114.192.213.443 -> 192.168.7.100.50655: syn 850091368 ack 1368868226
6.290682 lan out 170.114.193.213.443 -> 192.168.7.100.50654: syn 1108017471 ack 1333448656
6.291241 lan in 192.168.7.100.50654 -> 170.114.193.213.443: ack 1108017472
6.291242 lan in 192.168.7.100.50655 -> 170.114.192.213.443: ack 850091369
6.291263 wan out 192.168.1.252.50654 -> 170.114.193.213.443: ack 1108017472
6.291264 wan out 192.168.1.252.50655 -> 170.114.192.213.443: ack 850091369
6.293578 lan in 192.168.7.100.50656 -> 170.114.196.213.443: syn 1891659833
6.293641 wan out 192.168.1.252.50656 -> 170.114.196.213.443: syn 1891659833
6.297377 wan in 170.114.196.213.443 -> 192.168.1.252.50656: syn 2830324751 ack 1891659834
6.297423 lan out 170.114.196.213.443 -> 192.168.7.100.50656: syn 2830324751 ack 1891659834
6.297927 lan in 192.168.7.100.50656 -> 170.114.196.213.443: ack 2830324752
6.297949 wan out 192.168.1.252.50656 -> 170.114.196.213.443: ack 2830324752
6.298274 lan in 192.168.7.100.50657 -> 170.114.197.213.443: syn 633108794
6.298333 wan out 192.168.1.252.50657 -> 170.114.197.213.443: syn 633108794
6.302421 wan in 170.114.197.213.443 -> 192.168.1.252.50657: syn 1781855463 ack 633108795
6.302465 lan out 170.114.197.213.443 -> 192.168.7.100.50657: syn 1781855463 ack 633108795
6.302810 lan in 192.168.7.100.50657 -> 170.114.197.213.443: ack 1781855464
6.302831 wan out 192.168.1.252.50657 -> 170.114.197.213.443: ack 1781855464
6.337210 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
6.379457 lan in 192.168.7.100.50655 -> 170.114.192.213.443: fin 1368871554 ack 850096715
6.379477 wan out 192.168.1.252.50655 -> 170.114.192.213.443: fin 1368871554 ack 850096715
6.379643 lan in 192.168.7.100.50654 -> 170.114.193.213.443: fin 1333451984 ack 1108023569
6.379659 wan out 192.168.1.252.50654 -> 170.114.193.213.443: fin 1333451984 ack 1108023569
6.379829 lan in 192.168.7.100.50656 -> 170.114.196.213.443: fin 1891661160 ack 2830330098
6.379842 wan out 192.168.1.252.50656 -> 170.114.196.213.443: fin 1891661160 ack 2830330098
6.379989 lan in 192.168.7.100.50657 -> 170.114.197.213.443: fin 633109835 ack 1781859659
6.380002 wan out 192.168.1.252.50657 -> 170.114.197.213.443: fin 633109835 ack 1781859659
6.380135 lan in 192.168.7.100.50655 -> 170.114.192.213.443: rst 1368871555 ack 850097466
6.380137 lan in 192.168.7.100.50657 -> 170.114.197.213.443: rst 633109836 ack 1781860584
6.380148 wan out 192.168.1.252.50655 -> 170.114.192.213.443: rst 1368871555 ack 850097466
6.380148 wan out 192.168.1.252.50657 -> 170.114.197.213.443: rst 633109836 ack 1781860584
6.383255 wan in 170.114.196.213.443 -> 192.168.1.252.50656: rst 2830330122 ack 1891661161
6.383270 lan out 170.114.196.213.443 -> 192.168.7.100.50656: rst 2830330122 ack 1891661161
6.383275 wan in 170.114.196.213.443 -> 192.168.1.252.50656: rst 2830330098
6.383284 lan out 170.114.196.213.443 -> 192.168.7.100.50656: rst 2830330098
6.383296 wan in 170.114.192.213.443 -> 192.168.1.252.50655: rst 850097490 ack 1368871555
6.383310 lan out 170.114.192.213.443 -> 192.168.7.100.50655: rst 850097490 ack 1368871555
6.383409 lan in 192.168.7.100.50656 -> 170.114.196.213.443: rst 1891661161 ack 2830330122
6.383419 wan out 192.168.1.252.50656 -> 170.114.196.213.443: rst 1891661161 ack 2830330122
6.383506 lan in 192.168.7.100.50654 -> 170.114.193.213.443: rst 1333451985 ack 1108023593
6.383517 wan out 192.168.1.252.50654 -> 170.114.193.213.443: rst 1333451985 ack 1108023593
6.383603 wan in 170.114.193.213.443 -> 192.168.1.252.50654: rst 1108023593 ack 1333451985
6.383616 lan out 170.114.193.213.443 -> 192.168.7.100.50654: rst 1108023593 ack 1333451985
6.393118 lan in 192.168.7.100.50658 -> 170.114.192.63.443: syn 119796334
6.393283 wan out 192.168.1.252.50658 -> 170.114.192.63.443: syn 119796334
6.397597 wan in 170.114.192.63.443 -> 192.168.1.252.50658: syn 750647767 ack 119796335
6.397675 lan out 170.114.192.63.443 -> 192.168.7.100.50658: syn 750647767 ack 119796335
6.397896 lan in 192.168.7.100.50658 -> 170.114.192.63.443: ack 750647768
6.397918 wan out 192.168.1.252.50658 -> 170.114.192.63.443: ack 750647768
6.650824 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
6.650899 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
6.653553 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
6.846474 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
6.859813 lan in 192.168.7.100.50659 -> 170.114.192.63.443: syn 1310375625
6.859971 wan out 192.168.1.252.50659 -> 170.114.192.63.443: syn 1310375625
6.864665 wan in 170.114.192.63.443 -> 192.168.1.252.50659: syn 414795101 ack 1310375626
6.864755 lan out 170.114.192.63.443 -> 192.168.7.100.50659: syn 414795101 ack 1310375626
6.865124 lan in 192.168.7.100.50659 -> 170.114.192.63.443: ack 414795102
6.865149 wan out 192.168.1.252.50659 -> 170.114.192.63.443: ack 414795102
6.962695 lan in 192.168.7.100.59294 -> 170.114.192.63.8801: udp 123
6.962788 wan out 192.168.1.252.59294 -> 170.114.192.63.8801: udp 123
6.962821 lan in 192.168.7.100.59295 -> 170.114.192.63.8801: udp 123
6.962887 wan out 192.168.1.252.59295 -> 170.114.192.63.8801: udp 123
6.967430 wan in 170.114.192.63.8801 -> 192.168.1.252.59295: udp 44
6.967486 lan out 170.114.192.63.8801 -> 192.168.7.100.59295: udp 44
6.967492 wan in 170.114.192.63.8801 -> 192.168.1.252.59295: udp 14
6.967514 lan out 170.114.192.63.8801 -> 192.168.7.100.59295: udp 14
6.967922 wan in 170.114.192.63.8801 -> 192.168.1.252.59294: udp 44
6.967962 lan out 170.114.192.63.8801 -> 192.168.7.100.59294: udp 44
6.967967 wan in 170.114.192.63.8801 -> 192.168.1.252.59294: udp 14
6.967987 lan out 170.114.192.63.8801 -> 192.168.7.100.59294: udp 14
6.968626 lan in 192.168.7.100.59295 -> 170.114.192.63.8801: udp 187
6.968650 wan out 192.168.1.252.59295 -> 170.114.192.63.8801: udp 187
6.968682 lan in 192.168.7.100.59294 -> 170.114.192.63.8801: udp 77
6.968704 wan out 192.168.1.252.59294 -> 170.114.192.63.8801: udp 77
7.170842 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
7.170920 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
7.173749 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
7.311921 lan in 192.168.7.100.59296 -> 170.114.192.63.8801: udp 123
7.311981 lan in 192.168.7.100.59297 -> 170.114.192.63.8801: udp 123
7.312091 wan out 192.168.1.252.59296 -> 170.114.192.63.8801: udp 123
7.312091 wan out 192.168.1.252.59297 -> 170.114.192.63.8801: udp 123
7.312097 lan in 192.168.7.100.59298 -> 170.114.192.63.8801: udp 125
7.312100 lan in 192.168.7.100.59299 -> 170.114.192.63.8801: udp 125
7.312149 wan out 192.168.1.252.59298 -> 170.114.192.63.8801: udp 125
7.312161 wan out 192.168.1.252.59299 -> 170.114.192.63.8801: udp 125
7.316364 wan in 170.114.192.63.8801 -> 192.168.1.252.59299: udp 44
7.316428 lan out 170.114.192.63.8801 -> 192.168.7.100.59299: udp 44
7.316434 wan in 170.114.192.63.8801 -> 192.168.1.252.59299: udp 14
7.316460 lan out 170.114.192.63.8801 -> 192.168.7.100.59299: udp 14
7.316466 wan in 170.114.192.63.8801 -> 192.168.1.252.59296: udp 44
7.316498 lan out 170.114.192.63.8801 -> 192.168.7.100.59296: udp 44
7.316503 wan in 170.114.192.63.8801 -> 192.168.1.252.59296: udp 14
7.316521 lan out 170.114.192.63.8801 -> 192.168.7.100.59296: udp 14
7.316548 wan in 170.114.192.63.8801 -> 192.168.1.252.59298: udp 44
7.316586 lan out 170.114.192.63.8801 -> 192.168.7.100.59298: udp 44
7.316592 wan in 170.114.192.63.8801 -> 192.168.1.252.59298: udp 14
7.316611 lan out 170.114.192.63.8801 -> 192.168.7.100.59298: udp 14
7.316617 wan in 170.114.192.63.8801 -> 192.168.1.252.59297: udp 44
7.316649 lan out 170.114.192.63.8801 -> 192.168.7.100.59297: udp 44
7.316655 wan in 170.114.192.63.8801 -> 192.168.1.252.59297: udp 14
7.316673 lan out 170.114.192.63.8801 -> 192.168.7.100.59297: udp 14
7.323452 lan in 192.168.7.100.59299 -> 170.114.192.63.8801: udp 194
7.323475 wan out 192.168.1.252.59299 -> 170.114.192.63.8801: udp 194
7.323495 lan in 192.168.7.100.59298 -> 170.114.192.63.8801: udp 77
7.323516 wan out 192.168.1.252.59298 -> 170.114.192.63.8801: udp 77
7.323625 lan in 192.168.7.100.59296 -> 170.114.192.63.8801: udp 187
7.323644 wan out 192.168.1.252.59296 -> 170.114.192.63.8801: udp 187
7.323667 lan in 192.168.7.100.59297 -> 170.114.192.63.8801: udp 77
7.323688 wan out 192.168.1.252.59297 -> 170.114.192.63.8801: udp 77
7.366531 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
7.429498 lan in 192.168.7.100.59300 -> 170.114.192.63.8801: udp 125
7.429565 lan in 192.168.7.100.59301 -> 170.114.192.63.8801: udp 125
7.429598 wan out 192.168.1.252.59300 -> 170.114.192.63.8801: udp 125
7.429629 wan out 192.168.1.252.59301 -> 170.114.192.63.8801: udp 125
7.429637 lan in 192.168.7.100.59302 -> 170.114.192.63.8801: udp 123
7.429688 wan out 192.168.1.252.59302 -> 170.114.192.63.8801: udp 123
7.429693 lan in 192.168.7.100.59303 -> 170.114.192.63.8801: udp 123
7.429752 wan out 192.168.1.252.59303 -> 170.114.192.63.8801: udp 123
7.433368 wan in 170.114.192.63.8801 -> 192.168.1.252.59301: udp 44
7.433422 lan out 170.114.192.63.8801 -> 192.168.7.100.59301: udp 44
7.433428 wan in 170.114.192.63.8801 -> 192.168.1.252.59303: udp 44
7.433428 wan in 170.114.192.63.8801 -> 192.168.1.252.59301: udp 14
7.433453 lan out 170.114.192.63.8801 -> 192.168.7.100.59301: udp 14
7.433470 lan out 170.114.192.63.8801 -> 192.168.7.100.59303: udp 44
7.433478 wan in 170.114.192.63.8801 -> 192.168.1.252.59303: udp 14
7.433498 lan out 170.114.192.63.8801 -> 192.168.7.100.59303: udp 14
7.433794 wan in 170.114.192.63.8801 -> 192.168.1.252.59302: udp 44
7.433834 lan out 170.114.192.63.8801 -> 192.168.7.100.59302: udp 44
7.433840 wan in 170.114.192.63.8801 -> 192.168.1.252.59302: udp 14
7.433856 wan in 170.114.192.63.8801 -> 192.168.1.252.59300: udp 44
7.433859 lan out 170.114.192.63.8801 -> 192.168.7.100.59302: udp 14
7.433893 lan out 170.114.192.63.8801 -> 192.168.7.100.59300: udp 44
7.433901 wan in 170.114.192.63.8801 -> 192.168.1.252.59300: udp 14
7.433920 lan out 170.114.192.63.8801 -> 192.168.7.100.59300: udp 14
7.439482 lan in 192.168.7.100.59301 -> 170.114.192.63.8801: udp 194
7.439505 wan out 192.168.1.252.59301 -> 170.114.192.63.8801: udp 194
7.439520 lan in 192.168.7.100.59300 -> 170.114.192.63.8801: udp 77
7.439544 wan out 192.168.1.252.59300 -> 170.114.192.63.8801: udp 77
7.439644 lan in 192.168.7.100.59302 -> 170.114.192.63.8801: udp 187
7.439665 wan out 192.168.1.252.59302 -> 170.114.192.63.8801: udp 187
7.439828 lan in 192.168.7.100.59303 -> 170.114.192.63.8801: udp 77
7.439849 wan out 192.168.1.252.59303 -> 170.114.192.63.8801: udp 77
7.700841 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
7.700915 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
7.703706 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
7.896500 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
8.210831 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
8.210907 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
8.214701 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
8.406493 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
8.730842 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
8.730918 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
8.733757 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
8.927132 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
9.230918 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
9.230995 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
9.234720 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
9.427448 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
9.750957 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
9.751032 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
9.753739 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
9.947278 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
10.250912 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
10.250987 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
10.254708 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
10.435924 wan in 170.114.52.2.443 -> 192.168.1.252.50098: ack 2873070067
10.435953 lan out 170.114.52.2.443 -> 192.168.7.100.50098: ack 2873070067
10.437180 lan in 192.168.7.100.50098 -> 170.114.52.2.443: ack 1102137305
10.437202 wan out 192.168.1.252.50098 -> 170.114.52.2.443: ack 1102137305
10.446841 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
10.760839 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
10.760915 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
10.764721 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
10.956470 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
11.280895 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
11.280973 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
11.284899 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
11.476675 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
11.790842 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
11.790919 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
11.793809 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
11.987048 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
12.300824 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
12.300900 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
12.303728 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
12.496813 advpn in 170.114.52.2 -> 10.202.7.250: icmp: echo reply
12.810834 advpn out 10.202.7.250 -> 170.114.52.2: icmp: echo request
12.810907 wan out 192.168.1.252 -> 170.114.52.2: icmp: echo request
12.813754 wan in 170.114.52.2 -> 192.168.1.252: icmp: echo reply
Snifferで確認した結果、パフォーマンスSLAのzoom.us宛ICMPは各インターフェースから送信され、実際のZoom Meetingsで使用される443/tcpやその他ISDBで定義されたトラフィックはunderlay(wan)のインターフェースから送信されていることが分かります。
GUIの「Dashboard」->「FortiView」でもZoom Meetings宛パケットの発信インターフェースを確認してみると以下のようになっています。
SD-WANルールで設定したとおりに、Zoom Meetings宛のパケットがunderlay(wan)のインタフェースから出力されていることが分かります。
WEB会議も解像度やフレームレートなどが高品質になっていることが確認できました。（画像をクリックして拡大してください）
なお、Zoom Meetings以外のインターネットトラフィックはSpoke(DC)経由のRIAを使用しているため、スピードテストは低速のままになっています。
テクニック４：タイブレーク方式の決定（fib-best-match）
FortiGateのSD-WAN機能はルーティングテーブルのロンゲストマッチを基準にした通常のルーティング処理とは異なり、SD-WANルール内に設定されたSD-WANメンバーの優先順位をもとにトラフィックをステアリングすることが大きな特徴です。優先順位は設定されたSD-WANメンバーの順番で決まります。
この優先順位は各SD-WANルールの中で「tie-break」のパラメータにより変更することが可能です。例えばSD-WANルールで優先されるパスがルーティングテーブル上でのデフォルトルートであり、かつ他にロンゲストマッチの経路が存在する場合、デフォルトの「cfg-order」ではデフォルトルートを選択します。
# config system sdwan
config service
edit x
set tie-break ?
- cfg-order: SLA を満たすメンバーは、構成された順序で選択されます (デフォルト)。
- fib-best-match: ルーティング テーブル内の最長プレフィックスに一致する、SLA を満たすメンバーが選択されます。
- input-device: 入力デバイスを照合して、SLA を満たすメンバーが選択されます。
設計上この動作が好ましくない場合は「fib-best-match」に設定することで、ロンゲストマッチの経路を選択するように動作を変更することが可能です。今回の検証ではunderlay向けのデフォルトルートを使用してDIAを行うため、tie-breakオプションの変更は不要でした。
まとめ
今回はFortiGateにおけるSD-WANの設定方法と動作確認結果について、いくつかのパターンとともに紹介しました。FortiGateのSD-WAN機能では基本的にルーティングテーブルはECMPで設定しておき、トラフィックごとに利用するパスをSD-WANルールで決定するというものですので、直感的に非常に分かりやすいコンフィグレーション体系になっていると思います。今回紹介したコンフィグレーションはあくまで検証構成としての一つの例ですが、パフォーマンスSLAやADVPN Shortcut上のBGPを併用することできめ細やかなDIA/RIAを同時に実現できることが伝わっていましたら幸いです。
さて、ここまで三回にわたってFortiGateのSD-WAN/ADVPN2.0を紹介してきましたが、次回以降はFortiGateのSD-WANにおけるより深い機能や、AWSやAzureなどにおけるFortiGateVMと各パブリッククラウドのネットワークサービスの連携を題材にしてみたいと思っています。ご期待ください！
一緒に働く仲間を募集しています！
NTTデータ セキュリティ＆ネットワーク事業部では以下の職種を募集しています。
参考文献
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。