翻訳者注：これは、SD-WANに関する現実とマーケティングに関するIvan Pepelnjakの注の翻訳です。 「ソフトウェア定義のWAN：適切に編成されたダクトテープ？」というメモのタイトルは、次のツイートから来ています。
Software Defined Evangelistsの1人が2015年をSD-WANの年と宣言しました。私のポッドキャストフィードには、従来のルーターと比べて製品の楽しさを伝えるスタートアップがたくさんいます。 ここで考える必要があります：SD-WANは本当に新しいものですか、それとも新しい曲の古い曲ですか？
最初のものを読む
この投稿を間違えないでください。 私はSD-WANに反対ではありません。 実際、私が見たアイデアのいくつかと、いくつかの製品のシンプルで統一されたアーキテクチャが好きです。
しかし、技術的な議論として偽装されたこの誇大広告はすべて私をうんざりさせます。ネットワークエンジニア （マーケティング担当者やマネージャーではなく）は、他のテクノロジーと同様にSD-WANにアプローチし、それが実際にどのように機能するか、本当の問題は何かを理解するおよびソリューション。
SD-WANとは何ですか？
深刻な機関からの定義がないため、Open Networking User Group Webサイト （ オープンネットワークのユーザー コミュニティ-約Translator ）の説明に目を向けましょう。 それらの図から判断すると、SD-WANはプライベートWANと並行してパブリックインターネットを使用してコストを削減できるもののようです。
ちょっと待って 私たちはそれを長年行ってきましたが、IPsec、DMVPN、またはMPLS / VPN-over-GRE-over-IPsecなどのソリューションを使用して、ほとんどのお客様がMPLS / VPNを離れてからずっと経ちました。
SD-WAN開発者のために働くマーケティングの達人は、彼らがすることは記述されていることとは根本的に異なることをすぐに説明します：過去にやったことはハイブリッドWANであり、目新しさはソフトウェア定義であり、したがって中央コントローラーを使用するため、 IKE、IPsec、GRE、NHRP、NBAR、IP SLA、PBR、BGPまたはOSPFルーティングプロトコルなどの複雑なプロトコルセットを使用することはできません。 これらはすべて独自の「秘密のソース」に置き換えられます-各スタートアップには独自のものがあります（もちろん、この考えはすぐに落ち着きます）。
ボンネットの下のSD-WAN
最も単純な形式では、SD-WAN（多くのスタートアップが宣伝しているように）により、2つのトランスポートWANを使用して、エンドポイント間の最適なデータ転送（エンドツーエンドトランスポート）が可能になります。
それを機能させるために何をする必要があるか見てみましょう。
サイトで使用されている非パブリックアドレス範囲をネットワーク（少なくともパブリックインターネットには送信しない）にアドバタイズできないため、各SD-WANソリューションは独自のオーバーレイネットワークを構築します。 GRE、VXLAN、IPsecトンネルモード 、その他のカプセル化テクノロジーなど、そこで何を使用してもかまいません。
一部のお客様は、すべてのサイト間の直接接続が必要です。これには、完全に接続されたトンネルトポロジまたはDMVPNなどのマルチトンネルテクノロジーが必要です。 詳細は重要ではなく、ほとんどの場合、トンネルは自動的にセットアップされます（Open vSwitchまたはVXLANの実装と同様）。
そして、暗号化せずにインターネット経由で内部トラフィックを転送したくないのですね。 各SD-WANソリューションは、トラフィック暗号化の問題（ヒント： IPsecと呼ばれるこのための標準ソリューションがあります）およびキー配布の問題（つまり、マルチベンダーの世界でのIKE ）を解決する必要があります。
SD-WAN仮想ネットワークの使用を開始する前に、ネットワークのトポロジを収集する必要があります。 SD-WANエッジデバイスをサイト上の従来のL2 / L3ネットワークと統合する問題を忘れて、SD-WANクラウドで何が起きているかに集中しましょう。
SD-WANエッジノードの電源を入れると、コントローラーに接続し、外部（WAN）IPアドレスを登録する必要があります。 標準プロトコルに基づくネットワークでは 、 NHRPがこれに使用されます。
次に、コントローラーは各サイトで使用可能なローカルプレフィックスに関する情報を取得する必要があります。 ルーティングプロトコル 、REST API、またはプレフィックスの交換に独自のプロトコルを使用するかどうかは、他のメーカーの製品とのやり取りを心配しない限り、重要ではありません。
文書化されていない独自のソリューションの利点について語るマルチベンダーネットワークの利点を以前に宣伝していた人々の話を聞くのは楽しいことです。「ルーティングプロトコルよりはるかに優れているからです。」
各サイトのプレフィックスに関する情報を収集した後、コントローラーはどのルートを使用するかを決定し、SD-WANエッジノードへのトランスポートネットワークネクストホップの対応するアドレスとともにプレフィックスを送信します。 BGPルートリフレクターの説明にもっと似たものがあるかはわかりません（ほとんどすべてのSD-WAN開発者が独自のメカニズムを使用していることを除いて、これはすでに明らかだと思います）。
理想的な場合、各サイトは複数のアップリンクを介して他のサイトから到達可能であり、そこから最適なものを選択する必要があります。 選択は、到達可能性メトリックまたはより複雑な測定に基づいて行われます-BFDやIP SLAなどのよく知られたツールが行うこと 。
最後に、リンクの品質がわかったら、ユーザートラフィックをアプリケーションクラス（つまり、 NBAR ）で並べ替え、事前定義されたポリシーに基づいてアップリンクの1つを介してターゲットSD-WANに転送する必要があります（ ポリシーベースのルーティングのように見えますか？）
一部のSD-WANソリューションは、単純なPBRを超えて、インテリジェントなダウンロード制御、パケット再送信、または直接エラー修正を実装して、許容可能なエンドツーエンド品質を維持しながら利用可能な帯域幅の使用を最大化します。 これらのテクノロジーは新しいものではありません。それらはWAN最適化デバイスで長年にわたって利用されてきました（自分がどれほど悪いかについておしゃべりしたい人を覚えているかもしれません）。
結論
すべてのSD-WANソリューションでは、すべてのハイブリッドWAN自転車（トンネリング、暗号化、キー交換、ノード登録、ルーティング情報の交換、チャネル品質測定、アプリケーション認識、ポリシーに基づくパケット送信）を発明する必要があります-何らかの革命について話す必要はありませんこれらの決定（ RFC 1925のセクション2.11および2.5がすぐに思い浮かびます）。
ただし、ハイブリッドWANとSD-WANのアーキテクチャに強制される従来のプロトコルのミッシュマッシュには根本的な違いがあります-SD-WAN製品アーキテクトはレガシー実装に問題はありません。完全に異なる問題を解決するために開発されたコードを再利用しないでください。タスクに最適ではないプロトコルを使用しないでください（たとえば、BGPがはるかに優れていることが明らかな場合、DMVPNでOSPFを使用する理由は何ですか？）。 これらの自転車を発明するために使用する個々のコンポーネントは、元々共有用に設計されていたため、互いに非常によく調整されています。
したがって、ほとんどのSD-WAN製品のアーキテクチャは、従来のハイブリッドネットワークよりもはるかにシンプルで簡単に構成できます。 ただし、それらのほとんどが独自のプロトコルを使用していることを忘れてはなりません。これはベンダーのロックインにつながります。