Traceroute の制限事項の説明

by マーク・ハリス 2022 年 1 月 3 日

ネットワークで最も一般的に使用されるツールの XNUMX つ トラブルシューティング 間違いなく traceroute (およびその弟の ping) です。 このツールは便利ですが、traceroute を使用して今日のはるかに複雑な問題を処理するには、いくつかの重要な課題があります。 traceroute は、ネットワークがはるかに単純な 1980 年代後半に作成されたことを思い出してください。 すべてが物理的で、ポイントツーポイントが大流行し、扱うプロトコルが少なくなり、スイッチは一般にブリッジと呼ばれ、LAN-to-WAN ルーターが建物から建物へと移動していました。 (これは、インターネットが存在するよりも 1 年前のことです)! 「専用 TXNUMX 回線」を覚えている人はいますか? いわば古き良き時代。

では、このような旧式のツールは、すべてがソフトウェアで定義され仮想化された今日の世界でどのように持ちこたえているのでしょうか? 今日のネットワークのトラブルシューティングを支援する、より現代的な方法があるに違いありません。 はい、あるので読み続けてください…

開始するには、traceroute コマンドとは何かについてもう少し理解しましょう。

Traceroute コマンドとは何ですか?

送信元 (SRC) マシンは、通常、Time to Live (TTL) を 3 に設定した状態で、宛先 IP アドレスに向けて 1 つのプローブ パケットを送信します。プローブ パケットのタイプは、実際にはデバイスによって異なりますが、常に ICMP であると誤って考えられています。トレースルートを発信します。 Windows オペレーティング システムでは ICMP がよく使用されますが、Unix およびルーティング デバイスでは、一時的なポート (DNS、SMTP、WEB などのよく知られていないサービスである 1024 を超えるポート) への UDP メッセージがより一般的に使用されます。

プローブ パケットが各レイヤ 3 デバイスで受信されると、TTL が減少します。 TTL が 0 に達すると、受信デバイスは、そのパケットを受信したインターフェイスから ICMP メッセージ「TTL Expired」を送信します。 これは、traceroute が途中の各ホップを認識する方法です。

下の図では、172.16.2.1 と 10.3.2.2 が traceroute の結果で返されるアドレスになります。

今日のネットワークにおける Traceroute コマンドの課題:

#1: 非対称パスが見えにくい。 デフォルトでは、A-to-B のみが報告されます。 B-to-A では、パスを完了するためにもう一方の端から別の traceroute が必要です。 

非対称ルーティングは、今日のネットワークでは一般的です。 多くの等コスト マルチパス (ECMP)、さらには不等コスト マルチパス ルーティング プロトコルが使用されており、ハッシュ アルゴリズムに応じて、トラフィックは各方向で異なるパスを通る可能性があります。 これらのさまざまなパスを XNUMX 回のtraceroute コマンド実行で検出することは非常に困難であり、そのため、遅延結果がどこから影響を受けているかを正確に検出することは非常に困難です。

上で見られるように、遅延値はこの特定のホップで跳ね上がりますが、問題は「この遅延はどこにあるのか?」ということです。 往路にいるのか、それとも復路にいるのか？

#2: インターフェイスは不明で、デバイスの IP ノードのみです。 追加の詳細はありません。

上記のtracerouteをもう一度見てみると、提供されている情報はホスト名/IPと遅延結果のみです。 ユーザーがホップ 6 を調査する場合は、ルータに Telnet/SSH して、この IP アドレスがどのインターフェイスに接続されているかを判断する必要があります (これを判断するには、IP ルート 129.259.2.41 を表示するのが私のお気に入りの方法ですが、IP インターフェイスを表示することもできます)そして出力をパイプして parser… IP インターフェイスの概要を表示 | 129.150.2.41 で)。 次に、出口 (発信) インターフェイスを特定するには、この情報を特定するために 192.41.37.40 回目のルックアップを完了する必要があります (たとえば、IP ルート XNUMX を表示)。

#3: traceroute は ICMP メッセージングに依存しており、ルーターを通過するデータを転送するために使用される「高速パス」ではなく、デバイスの「低速パス」で処理されるため、トラフィックが実際に認識するよりも長い遅延を報告する可能性があります。 .

低速パスは、ルーターがパケットの内容を処理する必要がある場合に最も簡単に要約できます。 デバイス宛ての事実上すべてのパケットは、この方法で処理されます。 新しいルーターには、処理するパケットに優先順位を付ける内部メカニズム (ICMP メッセージの前にプロトコル更新をルーティングする) がありますが、これはここでの問題を増大させるだけです。 前に説明したように、ほとんどのシステムは UDP メッセージを使用しますが、ICMP TTL 期限切れメッセージを生成する行為は優先度が低く、リターン パスは ICMP メッセージになるため、結果で提供される遅延メトリックは困難です。現実の問題として受け入れること。

ヒント: 結果の特定のステップでジャンプする traceroute が表示され、その後のすべての結果が低い場合、これは「遅い」ルーターの処理が遅れていることを示しています。 パスがジャンプし、パスに沿った後続の各ステップがインクリメントされる場合、これは通常、輻輳による何らかの形式のキューイングを意味します。

#4: traceroute の出力は、簡単に操作できない静的なテキストです。

さて、特定の目的地に向かうパスはわかりましたが、そのパスに沿った XNUMX つ以上のホップをさらに深く掘り下げたい場合はどうすればよいでしょうか? Telnet/SSH コンソール セッションでは、ユーザーがこれらのデバイスにログインする必要があります。 インターフェイス IP アドレスのみが、traceroute 応答で提供されます。 セキュリティ ポリシーの観点から、ユーザーは管理 IP アドレスに Telnet/SSH 接続する必要があるため、これは多くのネットワークで問題となる可能性があります。 Telnet は、traceroute で報告されている特定のインターフェイスでブロックされる可能性があり、そのインターフェイス アドレスを持つデバイスの管理インターフェイスを特定するには、何らかの形式の手動検索が必要になります。 DNS 解決がなければ、これはほぼ不可能です。 停電が発生すると、一秒を争う可能性があります。

#5: 等コスト パスは表示されません (実際に通過したパスのみがレポートされます)。

前述のように、現在のほとんどのネットワークでは、コストが等しいまたは異なるマルチパス ルートが一般的です。 traceroute は、照会プローブ メッセージの一部であった特定のパスについてのみ報告します。 最も一般的な traceroute の実装では、UDP 宛先ポートが異なる 3 つのプローブ パケットが送信されるため、ECMP 環境では、各ホップで最大 3 つの異なる IP アドレスが報告される可能性があります。 どの応答がどのパスの一部であるかを追跡することは、面倒になる可能性があります。

#6: traceroute はレイヤー 3 です (レイヤー 2 ホップについてはレポートしません)

これで理解できたように、traceroute は IP パケットの TTL 値をデクリメントし、TTL 期限切れの ICMP メッセージを生成します。 TTL はレイヤー 3 デバイスでのみデクリメントされるため、組み込みの可視性や、結果から取得されたレイヤー 2 パスを簡単に決定する機能はありません。 エンタープライズおよびデータセンター環境では、ほとんどの場合、エンド ステーションを集約するために何らかの形式のレイヤ 2 アクセス スイッチが使用されます。 一部の設計では、コア ルータに到達する前に、traceroute 要求にレポートを返すことができる最初のレイヤ 2 ルーティング機能を実際に実行するレイヤ 3 ディストリビューション レイヤもあります。 トレースルート出力にパケット損失が表示される場合は、レイヤ 2 ポート チャネルまたはリンク アグリゲーション グループ（LAG）の不適切なハッシュ、スパニング ツリーの問題、スイッチ上のデュプレックス設定、または によってのみ発見できる別の問題が原因である可能性があります。パスに沿ったレイヤー 2 要素を検査します。 この情報を見つけるには、次のことが必要になります。

1. レイヤ 2 セグメント上の送信元デバイスの MAC アドレスを特定する (ルーターまたは送信元デバイスの ARP テーブルを確認する)
2. ドキュメントをチェックして、使用中のスイッチを特定する
3. 考えられる各パスにログインし、MAC テーブルで特定の MAC アドレスを確認します。
4. コマンドを実行してパフォーマンスと構成を確認する
5. アクティブなデバイスから離れるトランクの特定
6. 次のレイヤー 2 デバイスにログインし、最初のルーターに到達するまでプロセスを繰り返します。

このプロセスは、ネットワークで CDP/LLDP が有効になっていない場合やドキュメントが古くなっている場合は特に、非常に時間がかかる可能性があります。

#7: traceroute に履歴情報がありません

traceroute で表示される結果が現在の状態です。 トラフィックが成功したとき (たとえば、昨日) のパスを特定する方法はありません。 以下の traceroute を検討してください。可能性のある問題を特定するために、変更前のホップ 4 を理解することをお勧めします。

注: 上記の traceroute コマンドの出力に基づいて、エンジニアはホップ 3 が問題であると想定します。 多くの場合、そうではありません。 ユーザーが実行する必要がある最初のチェックは、ホップ 3 でデバイスにログインし、デバイスに宛先へのルーティング エントリがあるかどうかを確認することです。 その場合、多くの場合、問題のデバイスはルーティング エントリのネクスト ホップです。 徹底するには、ルーティング ネクスト ホップへの出力インターフェイスをチェックすると、インターフェイス レベルのパフォーマンスと ACL 設定を確認するのに役立ちます。

#8: traceroute には不可解なエラー メッセージ システムがあります。

traceroute コマンドの問題が発生すると、ときどき出力に驚くべき文字が表示されます。 次の表は、Cisco の traceroute の実装からのものです。 簡単に見えるかもしれませんが、何が起こっているのかを正確に理解するには、ほとんどの場合、追加のフォローアップ調査が必要です。

たとえば、traceroute 応答で文字 A を受け取ったとします。おそらく traceroute をブロックしているアクセス リストがあることは理解できますが、それはどのアクセス リストですか? これを判断するには、ルーターにログインし、パケットが入力されたインターフェイスを特定し、構成を確認し、アクセス リストが見つかったら調査する必要があります。 これは長いプロセスになる可能性があり、問題のトラブルシューティングに関しては常に時間を気にしているため、この情報にアクセスするためのより良い方法があれば素晴らしいと思います.

注: 私たちの経験では、これらのエラー メッセージは、入力インターフェイスに基づいてのみ提供されます。 パケットが正常に受信され、出力ポートに ACL がある場合は、パスに沿って次のホップに転送されると、単に次のホップの * * * を取得します。これは、出力インターフェイスが認識されていることを確認するための追加の手順を意味します。また、そのポートで検証されたすべての ACL も同様です。

最新のソリューションとは?

NetBrain 最新のネットワークを維持するために必要な自動化および視覚化機能が豊富に含まれています。 ソフトウェア定義、仮想化、さらにはクラウドも理解します。 エンドツーエンド ネットワーク上のすべてのデバイスと継続的に通信し、ネットワークのリアルタイム デジタル ツインを構築します。 このデジタル ツインは、すべてのデバイスの詳細を正確に複製したものです。 これには、リアルタイム ネットワークを視覚化する機能が含まれており、traceroute に代わる最新の機能が含まれています。 A/B パス計算機。 これにより、エンジニアが動的に支援できるようになり、これらすべての課題が解決されます。 ネットワークをマッピングする ネットワーク内の任意の XNUMX 点間のパスを追跡し、そのパスの詳細を提供します。 この機能は、高度なプロトコル（ルーティング、アクセス リスト、PBR、VRF、NAT など）を考慮しながら、最新のテクノロジー（SDN、SD-WAN、ファイアウォール、ロード バランシングなど）、アンダーレイ、オーバーレイによるマッピングをサポートします。 そして、一度展開すると、リアルタイムで視覚化できる同じ構造が、次のような完璧なプラットフォームを作成します。 コードなしの自動化 大小を問わず、あらゆるタスクに！

A/B パス計算ツールの XNUMX つの実際の例

＃1： 地図 遅いアプリケーション – ボストンとロサンゼルスの間では Web アプリケーションが遅くなります。

#2: VoIP トラフィック フローのマッピング – ボストンとサンフランシスコの間の音声トラフィックは不安定です。

#3: Map DDoS 攻撃 – 悪意のあるホストが DoS トラフィックをネットワークに注入しています。 トラフィックはどこから来ており、その影響は? NetFlow を利用してトップ トーカーを特定することで、パスをマッピングできます。

サービス提供の保証

NetBrainさん アプリケーション保証 (AAM) は、すべてのアプリケーションのハイブリッド クラウド ネットワーク パスを XNUMX つのビューでマッピングし、健全なパス ベースラインと比較してエンドツーエンドのパス パフォーマンスを継続的に検証し、適切なチームにプロアクティブに警告を発して、ビジネスが中断される前に問題に対処できるようにします。 これにより、チームはトラフィック フロー レベルでアプリケーションのパフォーマンスを迅速にトラブルシューティングおよび診断できるようになります。

アプリケーションのパフォーマンスの低下を防ぐことができるようになりました。 NetBrainコード不要のインテントベースの自動化。

NetBrain AAM は以下によってユーザー エクスペリエンスを保護します。

• 考えられるすべてのアプリケーション パスとそのデバイスを自動的にマッピングする
• すべてのアプリケーション パスの動作を定義する
• マップ上の「ゴールデン」パスに対するライブ アプリケーション パスのベースライン設定
• すべてのアプリケーション パスのパフォーマンスと履歴を単一のダッシュボードで視覚化
• アプリケーション パスのパフォーマンスが低下するとすぐに潜在的な問題を警告します