トラフィック エンジニアリングが必要な多くの理由
トラフィック エンジニアリングは、すべてのネットワークエンジニアとオペレータにとって重要な責務であり、効率的で信頼性の高いネットワークパフォーマンスを維持するのに欠かせません。このタスクの頻度は会社や特定のロールによって異なりますが、ネットワーク内やインターネット上の状況は常に進化しているため、企業を問わず不可欠な活動であることに変わりありません。
トラフィック エンジニアリングの主要な目的の 1 つは、パフォーマンスを向上させることです。ネットワークエンジニアは、トラフィックが最も効率的な経路を通るよう、常にルーティングの最適化に努めています。この絶え間ないパフォーマンスの追求は、単なる技術的な努力ではなく、業界を問わず顧客体験を向上させるための取り組みと言えます。
しかし、トラフィック エンジニアリングは、パフォーマンスとは関係のない要因によって推進されることもあります。たとえば、ピアリングチームは、契約上の義務を遵守するため、または代替トランジットプロバイダーを使用してより手頃なネットワークパスにトラフィックをプッシュするために、変更を要求するかもしれません。
経験の有無にかかわらず、目の前にあるのは困難な仕事です。ネットワークオペレータが考慮する必要がある運用上の課題はたくさんあります。運用やアーキテクチャに関連するさまざまなシナリオが、トラフィック エンジニアリングの結果に悪影響を及ぼす可能性があります。思い浮かぶのは、トポロジの変更、1 回限りのシナリオ、予期しない設定の変更などです。結局のところ、多くの重大な障害はトラフィック エンジニアリングがうまくいかなかったために発生しました。
BGP ベストパス選択アルゴリズムとその意思決定プロセスに関する専門知識や、AS_PATH プリペンド、BGP コミュニティ、ローカルプレフィックス操作に関する豊富な経験を持っていても、予期しない事態が発生します。管理範囲外の変化や取り巻く環境の変化によって、トラフィック エンジニアリングの取り組みが予期せずに中断されることがあります。
このような事態が発生した場合、根本原因分析のようなプロセスを通じて、また、"なぜなぜ分析に答えることによって、貴重な教訓を学びます。"これらの教訓から、Method of Procedure（MOP）文書が更新され、検証ステップが追加されることがよくあります。
トラフィック エンジニアリングの複雑な性質を考えると、ネットワークエンジニアやオペレータは慎重に取り組む必要があります。ルーティングおよび転送テーブルの徹底的な検証、ダッシュボードを使用した重要なメトリックの継続的なモニタリング、検証のためのサードパーティ製ツールの使用などが必要となります。
BGP トラフィック エンジニアリングによるオペレーショナル エクセレンスの推進
ThousandEyes は、ネットワーク プロフェッショナルに高品質の信号を提供することに誇りを持っています。ほぼリアルタイムで BGP のモニタリングとアラート機能は、運用を支援します。これにより、エンジニアはトラフィック エンジニアリングの変更を迅速に検証することができます。入力トラフィックと出力トラフィックの両方をモニタリングする包括的な機能により、BGP コントロールプレーンとデータプレーンの両方の視点からインサイトを提供して、ネットワークのあらゆる側面が監視されていることを保証します。
次の例では、ThousandEyes で BGP トラフィック エンジニアリングの効果を検証するテストについて、ネットワーク プロフェッショナル向けに作成方法を解説します。このすべてが単一のプラットフォームで行われるため、実際に機能し、合理的な時間で結果を返す「Looking Glass」をインターネットで探す必要がなくなります。この実用性のおかげで、時間と労力を節約し、重要なことに集中できます。さらに、ThousandEyes は、コントロールプレーンからだけでなく、データプレーン（顧客トラフィックと実稼働トラフィックがルーティングされるのと同じデータプレーン）からほぼリアルタイムのフィードバックを提供します。
以下の図 1 に示すように、エージェント間テストでは、AS 210312 の "te-research-00" エージェントと、フランクフルトの Oracle Cloud に展開されたエージェント（AS 31898）の間の双方向のパスが可視化されています。エージェント間テストは、転送パスとリバースパスの両方を可視化するのに非常に役立ちます。インターネットの非対称性という性質を考慮すると、リバースパスを可視化することで大きな違いが生じ、効率的な根本原因分析の能力が向上します。
ThousandEyes のテストに使用される TCP トラフィックは、実稼働トラフィックまたは顧客トラフィックと同じデータプレーン上でルーティングされます。したがって、遅延の急増やパケット損失など、ThousandEyes が観測したイベントは、実稼働トラフィックや顧客トラフィックにも影響を及ぼしている可能性があります。
BGP Route Visualization により、世界中に展開された何百もの BGP モニターの視点からプレフィックス伝播が表示されます。BGP Route Visualization では、到達可能性、パス変更、更新などのメトリックを可視化します。
例を続けると、図 2 に示すように、ThousandEyes は、エージェント "te-research-00" が 193.5.19.0/24 プレフィックスの一部である IP アドレスを持っていることをプロアクティブに検出し、関連する BGP メトリックのモニタリングを開始したことがわかります。
入力トラフィック エンジニアリングの可視化
前述の例に従って、ネットワーク運用チームはネットワークに入ってくるトラフィックに影響を与えるため、入力側でトラフィック エンジニアリングを実施しました。これを実施する方法はいくつかありますが、最もよく使われる方法としては、プレフィックス アグリゲーション/デアグリゲーション、AS_PATH プリペンド、トランジットプロバイダーが提供する BGP コミュニティがあります。
図 3 のタイムラインからわかるように、7 月 24 日の 05:07 CST に、ネットワーク運用チームは、BGP コミュニティを使用して入力トラフィックでのトラフィック エンジニアリングの変更をプロアクティブに実行しました。その目標は AS 25091 をパスから削除することであり、AS 34549 経由でトラフィックを再ルーティングすることに成功しました。取り消しは赤の縞模様の線で表されています。一方、赤の実線は、トラフィックが入力トラフィック エンジニアリング後にとったパスを表しています。
ThousandEyes では、[BGPパスの変更（BGP Path Changes）] ビューで、左側の BGP モニターの 1 つに移動し、[パス変更の詳細の表示（View details of path changes）] オプションを選択することで、詳細なタイムスタンプを確認することができます。
図 4 に示すように、05:07:19 CST に、BGP モニター England-68 は、AS 25091 が含まれなくなったパスの変更を観測しました。その代わり、パスには AS 34549 が含まれるようになりました。
[エージェント間（Agent-to-Agent）] ビューに移動すると、図 5 と図 6 に示すように、逆方向の IP アドレスが変更されていることがわかりますが、ネットワークに基づいてグループ化すると、AS 25091 がパスから完全に削除されていることがわかります。
ほぼリアルタイムの BGP モニタリングとアラートにより、トラフィック エンジニアリングの変更の効果を自信を持って検証することができます。ThousandEyes を使用することで、BGP Route Visualization を使用したコントロールプレーンの視点と、Path Visualization を使用したデータプレーンの視点の両方から、これを直接行うことができます。
出力トラフィック エンジニアリングの可視化
ThousandEyes は常に、出力トラフィック エンジニアリングの影響を実証することができます。トラフィック エンジニアリングでよく使われる戦略は、ローカルプリファレンスを調整することです。他のいくつかの BGP 属性とは異なり、ローカルプリファレンスは推移的ではありません。つまり、他のピアと共有されず、eBGP フィードでは見ることができません。その結果、このようなシナリオでは、データプレーンの可視性とインサイトに頼る必要があります。
以下の図 7 に示すように、[エージェント間（Agent to Agent）] ビューに移動し、2024 年 7 月 24 日 07:34 CST の [Path Visualization] を確認すると、ネットワーク運用チームがパスの変更を決定する 1 分前に、トラフィックがデータプレーンでどのようにルーティングされていたかを見ることができます。
タイムライン上でデータプレーンのパスを調べることは、図 8 に示すように、変更前、変更中、変更後のトラフィックフローを明確に理解できるため、最も重要です。
1 分後の 07:35 CST に、ネットワーク運用チームは出力トラフィック エンジニアリングを適用し、パスを大幅に変更しました。その結果、図 9 と図 10 に示すように、トラフィックは Oracle の AS 31898 に到達する前に、元の AS 210312 から AS 8298（中継）にルーティングされました。
それが重要な理由
当社は、オペレーショナル エクセレンスを達成したいと考えています。しかし、ますます複雑化する環境では、オペレーショナル エクセレンスを達成することが難しく感じられることもあります。リスクは大きくなっています。トラフィック エンジニアリングの結果が良くなければ、しばしば障害やルートリークが発生します。そして、多くの場合、組織は風評被害と金銭的損失の両方を被ることになります。
あまりにも長い間、ネットワーク エンジニアリング コミュニティは、最適とは言えないツールに依存することで負担を強いられてきました。インターネット上に散在する「Looking Glass」や、コントロールプレーンデータを使用するソリューションなど、これらのツールは、トラフィック エンジニアリングの有効性やネットワークの正常性について、しばしば不安を残してきました。
ThousandEyes はそのギャップを解消します。ほぼリアルタイムの BGP モニタリングとアラートにより、世界中に戦略的に展開された何百ものモニターの視点から、プレフィックスの伝播に関して、これまでにない可視性を提供します。今日、ルーティングテーブルの視点から状況を確認する一方で、ThousandEyes は、世界中の複数の監視ポイントから、トラフィック エンジニアリングの効果をほぼ瞬時に可視化します。何百もの「Looking Glass」の効果を、一度に、より信頼性が高く、より速く、よりわかりやすい方法で調べているのです。
それだけにとどまりません。Path Visualization を使用することで、上記の例からわかるように、出力トラフィック エンジニアリングの効果を示すだけでなく、データプレーン（実稼働トラフィックと顧客トラフィックがルーティングされているのと同じデータプレーン）の視点からもそれを行います。そしてこの場合、転送方向にも逆方向にも効果を可視化します。
ピアリングパートナーにリバースパスで MTR を実行するよう連絡し、結果的に問題があることに気付いただけだったということが何度ありましたか。しかも、そのために長い時間待たされたことでしょう。誰もが同じ経験をしてきましたが、全体として言えば、到底満足できないはずです。
ほぼリアルタイムの BGP モニタリングとアラートを含む最近の製品向上と、Path Visualization のすべての利点、そして ThousandEyes の定評ある高品質の信号により、私たちはついにそれを実現しました（しかも、はるかに優れています）。
