こんにちは。SolarWinds Japanの山田晃嗣 <Kozy> です。（その1）と（その2）に続き、今回もNetPath機能についての説明になります。今回の（その3）では、よく知られたTraceroute との違いにフォーカスしてみたいと思います。
Tracerouteは、ネットワークのトラブルシューティングツールとして非常によく使われます。Pingに次に使われると言ってよいでしょう。簡単なコマンド操作によって、目的のアドレスまで、どのようなネットワークデバイスを経由して到達しているかを表示し、それらデバイスにおける遅延の状況などを示してくれます。Tracerouteが正しく動作すれば、どこでトラフィックが止まっているか、どこでトラフィックが遅くなっているか、どのデバイスがこの接続性に重要なのかを調べることができます。これは非常に便利なだけでなく、直感的に理解しやすいものだと言えるでしょう。ネットワークがどのように機能するかという私たちが想定していることと合致しているわけです。
しかしながら現実問題として、いつもTracerouteが正しく動作するとは限りません。残念ながらTracerouteが正しく動作しないケースは増えています。かろうじて動作したとしても、意味のある結果が得られないこともあります。1987年(！)に発明されたTracerouteは、現代のネットワークの真価に追いつけず、取り残されてしまっているのです。現代のネットワークは、Tracerouteが発明された当時よりも遥かに厳しいセキュリティを備え、冗長性を持ち、複雑なハードウェア・アーキテクチャを備えています。そんな現代のネットワークに対し、Tracerouteはその限界を露呈しはじめているのです。この限界を正しく理解することは、Tracerouteが提示するデータから正しい結論を導き出すために非常に重要です。下記、Tracerouteがどのように機能するかを復習し、その限界を知ることから、Tracerouteを最大限活用する方法を学び、それに替わる現代の解決策（もちろんNetPathのことです！）を紹介します。
まずはTRACEROUTE について学ぼう
ネットワークで使われているルーターは、Tracerouteが正しく機能するように特別に設計されたものではありません。その代わりに、Tracerouteは、IPv4に組み込まれたループ防止機構を巧みに利用しています。Tracerouteの仕組みを理解するためには、IPv4の「ループ防止機構」についてまず理解する必要があります。
ネットワークルーターは、あるインターフェイスからパケットを受け取り、そのIPヘッダーを検査して、別のインターフェイスを介して転送することでルーティングを行います。では、次のような事態が起きたらどうなるでしょう？最初のルーターからパケットを受け取った次のネットワークが最初のルーターに送り返してしまう事態です。これを「ルーティングループ」と呼びますが、パケットは永久にグルグルと同じ場所を回り続けるのです。このようなループは、2つのルーター間の短いものから、多数のルーターのセットに沿ったもっと長いものまでありますが結果は同じで、ループに関係するルーターは、同じパケットを何度も処理しなければならなくなります。何の管理もしていなければ、それらのルータは同じパケットを無限回処理することになります。パケットの処理1回にかかるルーターの負荷はごくわずかですが、これがずっと繰り返されることになると、ルーターは処理しきれなくなります。その結果、ルーターは処理できないパケットをドロップするようになります。これは大きな問題です。
でも安心してください。ルーティングループを防ぐために、さまざまな仕組みが用意されています。その一つは、IPパケットのフォーマットに組み込まれています。IPパケットには、「time to live」（TTL）と呼ばれるフィールドがあります(RFC:791) 。ルーターは、パケットを受信して別のインターフェイスにルーティングするたびに、TTLを1つ減らします。これは、パケットがルーティングされた回数を、パケット自体の内部に保存する方法です。あるエンドポイントから生成されたパケットのTTLフィールドには、必ず特定の番号が割り当てられています。その番号はOSによって異なり、カスタマイズすることもできますが、64または128であることが多いようです。TTLフィールドは8ビットなので、255以上の数字にはなることはありません。
つまり、パケットはTTLが(例えば)64で始まり、ルーティングされるたびにTTLが1つずつ減っていきます。この数字がゼロになった場合、ルーターはそのパケットを捨てます。その後、ルーターは自分自身から新しいパケットを生成し、パケットの送信元にTTLが切れたことを通知します。これが「ICMPタイプ11時間超過メッセージ」です。この仕組みにより、パケットがループしてしまったとしても、無限の回数ループすることはなくなります。
なるほど良い仕組みですね。でもそれがTracerouteとどう関係するのでしょう？実は大いに関係するのです。Tracerouteは、すべてのルーターが備えているこの機能を利用して、ネットワークから必要な情報を取得するのです。順を追って説明していきましょう。
Windowsでは「tracert」（LinuxやUnixではtraceroute）と入力すると、Tracerouteは宛先のIPとTTLが1（はい、僅か「１」です！）のパケットを作成します。 最初のルーター「R1」はこのパケットを受信し、TTLを1だけデクリメントし、TTLがゼロになったことを確認して、これを破棄します。次にR1は、R1から送信元の「Source（出発地）」に対し、ICMPタイプ11時間超過メッセージのパケットを作ります。Sourceはこのパケットを受信すると、送信元IPを検査し、R1のIP情報を得ます。なるほど、第一段階は成功ですね。最初の「ホップ1」が発見できました。パケットを送信してから応答を聞くまでの経過時間を測定することで、そのノードまでのレイテンシーも判明します。デフォルトでは、Windowsは最初のパケットと同じようにさらに2つのパケットを送信し、その結果、次のような画像が得られます。
あまり知られていないことですが、これは、元のパケットを受信したルーターのIngressインターフェイスからの応答であり、IngressインターフェイスのIP情報が含まれます。したがって、Tracerouteで得られる結果のIPアドレスは、IngressインターフェースのIPの情報となります。
続いて、コンピュータはTTLを1つ増やして宛先めがけてパケットを送り、この作業を繰り返します。R1はパケットを受け取ります。TTLを1つ減らすと、TTLは1になります。これなら破棄されないので、R1はパケットをR2に渡します。R2がパケットを受け取り、TTLを1から0に減らすと、R2はパケットを廃棄し、Source にICMPタイプ11時間超過メッセージを返します。このようにして、Sourceはホップ2を発見します。ホップ3についても同じことが繰り返されます。これは、パケットが最終目的地に到達するまで続きます。パケットがDestination（最終目的地）に到達すると、TTLが切れることなく、Destination自身が応答します。コンピュータは、送信元IPアドレスが最初に送信した宛先と一致する応答パケットを受け取ります。このようにして、コンピュータはDestinationに到達したと判断します。
これがTraceroute の仕組みです。実にシンプルですね。少なくとも理論的には。残念ながら実世界では、この通りにはいきません。この仕組みの前に立ちはだかるいくつかの複雑な問題を見てみましょう。
FIREWALL と言う「壁」
Tracerouteが発明された1987年当時、インターネットは今よりもずっとオープンなものでした。その後インターネットが爆発的に普及し、インターネット上の電子商取引によって相当な金額がやりとりされるようになると、インターネットが犯罪者達の標的となってしまい、インターネットを保護するための仕組みを導入する必要に迫られました。その基本は、「必要なものは許可するが、それ以外はブロックする」と言う至ってシンプルなものです。残念ながらTracerouteは、一般のユーザーが普通にインターネットをする際に必ずしも必要とは認識されていないため、許可されずブロックされることが多いのです。
多くの場合、Windows や Linux に標準で含まれているTracerouteコマンドを使用します。OSによって、tracerouteの実装は大きく異なりますが、最も重要なのは、送信されるプロトコルの種類です。UDPを利用する実装もあれば、ICMPを使用する実装もあります。まれにTCPが使われることもあります。OSによっては、多くの異なるポートを使用するものもあります。経路途中のノードからのリターントラフィックは、いくつかの異なるICMPタイプ（TTL expiryとunreachable）で送られてきます。トラフィックがエンドポイントに到達すると、エンドポイントは、到達しようとしているポートの状態に応じて、ソースプロトコルまたはICMPを使用して応答します。これだけ複雑だと、Tracerouteを確実に動作させることには様々な困難が伴います。
その結果、Tracerouteがファイアウォールを通過できないことがしばしば出てくるのです。この問題の本質は、Tracerouteがユーザーが使うアプリケーションのトラフィックとは異なり、さらにはアプリケーションとの接続を維持するために本質的に必要ではないということです。
その結果、Tracerouteを使用すると、しばしば次のようになります。
言うまでもなく、これでは何の役にも立ちません。
ヒント:
Tracerouteが動作しない場合、OSのTracerouteが必要とするポートをアウトバウンドで、経路途中のルーターが返すICMP expiryとunreachablesをインバウンドで許可しているかどうかを確認してください。
コントロールプレーンとデータプレンの違い
ネットワークルーターは、トラフィックを転送するように設計されています。一方Tracerouteは、ルータがトラフィックを転送せず、代わりに自分自身が応答するように設計されています。多くの場合、ルーターは転送されるトラフィック（データプレーン）を、自分自身が応答しなければならないトラフィック（コントロールプレーン）とは異なる方法で処理します。伝統的に、ルーターはトラフィックの転送を「ハードウェア」で処理します。その機能を実行するために設計された専用のハードウェアを持っているのです。一方、ルーターが直接応答しなければならないパケットは非常に少ないため、これらは例外的に扱われます。これらのパケットは、さまざまなタスクを処理できる汎用的なプロセッサーであるCPUに "投げられる "のです。このように2種類のトラフィックの処理が根本的に異なるため、それぞれの見た目のパフォーマンスも異なる場合があるのです。特に輻輳などでルーターに負担がかかった場合に、違いは現れます。
Tracerouteを実行すると、コントロールプレーンのトラフィックの結果が表示されます。この結果は、実際のアプリケーションのトラフィックの結果とは異なる可能性がありますが、本来知りたい結果はアプリケーションのトラフィックの結果のはずですね。よくある例としては、あるノードのCPUが高負荷状態であるために、Tracerouteはそのノードで高いレイテンシーを示しますが、通常のトラフィックでは高いレイテンシーは見られないのです。
幸いなことに、これを発見するのはそれほど難しいことではありません。
ホップ2が非常に遅いことがわかります。ホップ2を直接操作した場合、132ms、179ms、145msとなりました。しかし、このホップを経由してホップ3にトラフィックを送ると、はるかに低い値が表示されます。これは、そこまでの経路が問題なく動作していることを意味します。一般的には、ホップ2の高い遅延の値は無視しても良いということです。
問題は、上のTracerouteの結果を見たエンジニアが、少なからず一見してホップ2が問題だと結論づけてしまうことです。実際には、このスローダウンはコントロールプレーンのトラフィックにのみ適用され、アプリケーションのトラフィックには適用されません。
ヒント:
後のホップのレイテンシーやパケットロスの値が、前のホップの値よりも低い場合、一般的には前のホップも問題ないと考えてよいでしょう。
マルチパス（複数の経路）
インターネット上のネットワーク経路は、単純なシングルパスではなく、マルチパスであることが多いのです。
ある調査によると、今日インターネット上の経路の80％以上がマルチパスであり、その割合は益々増加しています。このことは、Tracerouteにとって大きな問題です。
Tracerouteは、デフォルトでは各TTLに対して3つの個別パケットのバッチを送信することがわかっています。その1つのパケットは、ある経路を通過し、TTLがゼロになったときに返されます。残念ながら、1つのパケットと次のパケットは独立していて、相互の関連性は殆どありません。それぞれのパケットは異なるパスを通ることができるため、tracerouteはマルチパスをうまく扱うことができないのです。
ヒント:
特定のホップ数で複数のIPが表示される場合、複数のパスが使用されています。結果には十分注意する必要があります。
そこでNetPath！
Traceroute の限界を認識し理解することで、Traceroute の結果を分析し、最良の結論を導き出すことができます。Tracerouteは、今でも最もユビキタスなネットワーク・トラブルシューティング・ツールの一つです。あなたがネットワークに責任を持っているなら、それをよく理解することは非常に重要です。
SolarWinds は、tracerouteの問題を理解し、解決するために多くの時間を費やしてきました。私たちは、ソースからデスティネーションまでのネットワーク接続の健全性を明確かつ直感的に把握することができ、かつ最新のネットワークにも対応できるものを作りたいと考え、NetPath によってそれを実現したのです。
NetPath機能は、独自のディスカバリー手法により、比較的シンプルなネットワークから非常に複雑なマルチパスネットワークまで、ネットワークパスを特定し、オンプレミス、ハイブリッドネットワーク、クラウドなど場所を問わず、パフォーマンスの詳細を視覚的に表示します。
なお、今回紹介したNetPathは、Network Performance Monitorのいち機能になります。NetPath機能を持つNetwork Performance Monitorは、こちらのリンクから評価版をダウンロードして簡単に機能確認が可能です。また、さらに詳細な説明をご希望される場合は、こちらのリンクから弊社営業にお気軽にお問い合わせをお願いいたします。
それでは今回はこのあたりで。
2021年10月8日 SolarWinds Japan 山田晃嗣