by NetBrain 2022 年 1 月 3 日

Traceroute の制限事項の説明

トレースルートとその弟分であるpingは、ネットワークで最もよく使われるツールの一つです。 トラブルシューティングこのツールは非常に便利ですが、今日のより複雑な問題に対処するには、いくつか重大な課題があります。tracerouteは1980年代後半に開発されたもので、当時はネットワークがはるかに単純だったことを思い出してください。

すべてが物理的になり、ポイントツーポイントが流行し、扱うプロトコルも少なくなっていました。スイッチは一般的にブリッジと呼ばれ、LAN-WANルーターは建物から建物へと移動していました。（インターネットが登場する1年も前の話です！）そして、「専用TXNUMX回線」を覚えている人はいますか？ いわば古き良き時代です。

では、このような時代遅れのツールは、今日のソフトウェア定義および仮想化の世界ではどのように機能するのでしょうか？今日のネットワークのトラブルシューティングに役立つ、もっと現代的な方法があるはずです。はい、あります。ぜひ読み進めてください。

まずは、tracerouteコマンドについて詳しく学びましょう。その後、tracerouteのエラーや制限事項などについて説明します。

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

送信元（SRC）マシンは通常、宛先IPアドレスに向けて、TTL（Time to Live）を1に設定して1024つのプローブパケットを送信します。プローブパケットの種類は常にICMPであると誤解されている方もいますが、実際にはtracerouteの送信元デバイスによって異なります。WindowsオペレーティングシステムではICMPがよく使用されますが、Unixやルーティングデバイスでは、エフェメラルポート（DNS、SMTP、WEBなどのよく知られていないサービスではない、XNUMXより大きいポート）へのUDPメッセージが一般的に使用されます。

各レイヤー3デバイスはプローブパケットを受信すると、TTLをデクリメントします。TTLが0になると、受信デバイスは受信インターフェースから「TTL Expired（TTL期限切れ）」というICMPメッセージを送信します。これにより、tracerouteは経路上の各ホップを認識します。

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

現代のネットワークにおける Traceroute の制限と課題:

＃1：非対称パスは簡単には見えない

トレースルートのデフォルト設定では、ポイントAとポイントB間のパスが報告されます。反対方向のルートをレポートするには、2つ目のトレースルートが必要です。これがなぜ制限となるのか、ここで説明しましょう。

非対称ルーティングは現代のネットワークで一般的になっています。ここでは、以下を含む多くのルーティングプロトコルが利用されています。

• 等コストマルチパス（ECMP）
• 不等コストマルチパス

ハッシュに使用されるアルゴリズムによっては、トラフィックは各方向で異なるパスを辿る可能性があります。これらの異なるパスは、tracerouteコマンドを1回実行しただけでは検出が困難です。そのため、遅延結果がどこから来ているのかを特定するのは困難です。

ご覧のとおり、この特定のホップでは遅延値が大幅に増加しています。遅延はどこで発生しているのでしょうか？フォワードパスですか、それともリターンパスですか？

#2: インターフェースは不明、デバイスのIPノードのみ

上記の traceroute をもう一度見てみると、提供される情報は次のようになります。

• ホスト名/IP
• 遅れた結果

ホップ129.259.2.41を調べるには、ルータにTelnetまたはSSH接続を確立し、この特定のIPアドレスにどのインターフェースが接続されているかを確認する必要があります。「Show IP route XNUMX」というコマンドは、私がよく使う方法です。しかし、IPインターフェースを表示し、その出力をパイプで処理することもできます。 parser…「show IP interface brief | in 129.150.2.41」と入力します。出力インターフェースを特定するには、追加のルックアップが必要です。例えば、「show IP route 192.41.37.40」のように入力します。

#3: TracerouteはICMPメッセージングに依存する

ICMP メッセージングでは、主に高速パスではなく低速パス処理を使用するため、トラフィックで発生するよりも大幅な遅延が報告されることがあります。

スローパスとは？ルーターがパケットの内容を処理する必要がある場合のことです。デバイス宛てのパケットはほぼすべてこのように処理されます。新しいルーターの内部メカニズムは、処理するパケットの優先順位を決定します。

ルーティングプロトコルの更新を最初に処理し、次にICMPメッセージを処理するため、問題が深刻化します。多くのシステムはUDPメッセージを使用していますが、ICMP TTL期限切れメッセージの生成は優先度が低く、その結果、戻り経路はICMPメッセージになります。そのため、結果に示される遅延メトリックを実際の問題として受け入れることは困難です。

ヒント：traceroute が特定のステップでジャンプし、その後の結果が低い場合、多くの場合、「遅い」ルーターで処理遅延が発生していることを示しています。パスがジャンプし、その後のステップが増加する場合、通常は輻輳による何らかのキューイングが発生していることを意味します。

#4: Tracerouteは静的な出力を提供するため、対応が難しい

特定の宛先への経路はわかりましたが、経路上の追加のホップをさらに調査したい場合はどうすればよいでしょうか？ユーザーがTelnetまたはSSHコンソールを使用する場合、各デバイスにログインする必要があります。tracerouteの応答ではインターフェースのIPアドレスしか提供されません。多くのネットワークでは、これが問題を引き起こします。

セキュリティポリシーにより、ユーザーは管理IPアドレスにアクセスするためにTelnetまたはSSHを使用する必要があります。tracerouteで報告される特定のインターフェースはTelnetをブロックする可能性があり、そのインターフェースアドレスを持つデバイスの管理インターフェースを特定するには手動で検索する必要があります。DNS解決ができない場合、これはほぼ不可能です。障害が発生した場合、一秒一秒が命取りになる可能性があります。

#5: 等コストパスは表現されない（実際に通過したパスのみが報告される）

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

#6: Traceroute はレイヤー 3 です (レイヤー 2 のホップは報告しません)

ご存知のとおり、traceroute は IP パケットの TTL 値をデクリメントし、TTL 期限切れの ICMP メッセージを生成します。TTL をデクリメントするのはレイヤー 3 デバイスのみです。そのため、結果からレイヤー 2 パスを簡単に特定できる可視性や機能は組み込まれていません。ほとんどの企業およびデータセンター環境では、エンドステーションを集約するためにレイヤー 2 アクセススイッチが使用されています。

一部の設計では、コアルータに到達する前にレイヤ2ディストリビューションレイヤが備えられています。ルータは最初のレイヤ3ルーティング機能を実行し、traceroute要求にレポートを返すことができます。

traceroute の出力にパケット損失が表示される場合、次の原因が考えられます。

• スパニングツリーの問題
• スイッチのデュプレックス構成
• レイヤ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の制限事項の一つは、一見単純なように見えますが、何が起こっているのかを理解するには、通常、追加の調査が必要になることです。

例えば、traceroute の応答で文字 A を受け取ったとします。アクセスリストが traceroute をブロックしていることは分かりますが、どのアクセスリストでしょうか？ これを特定するには、以下の手順を実行する必要があります。

1. ルーターにログインします
2. パケットがどのインターフェースに入ったかを判断する
3. 構成を確認する
4. アクセスリストを見つけたら調査する

このプロセスは長引く可能性があり、問題のトラブルシューティングでは常に時間を気にしています。そのため、この情報にアクセスするためのより良い方法があれば非常に助かります。

注：経験上、これらのtracerouteエラーメッセージは、入力インターフェースに基づいてのみ提供されます。パケットが受信され、パス上の次のホップに転送されると、出力ポートにACLが存在する場合、次のホップに対しては***が表示されます。つまり、出力インターフェースが認識されていること、およびポート上のACLが検証されていることを確認するための追加手順が必要になります。

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

NetBrain 現代のネットワーク維持に必要な多くの自動化機能と可視化機能を備えています。ソフトウェア定義ネットワーク、仮想化ネットワーク、さらにはクラウドネットワークにも対応しています。エンドツーエンドのネットワーク上のあらゆるデバイスと継続的に通信し、ネットワークのリアルタイムデジタルツインを構築します。これは、あらゆるデバイスの詳細情報を正確に再現したものです。

リアルタイムネットワークを視覚化でき、tracerouteの現代的な代替機能も搭載しています。 A/B パス計算機このツールはエンジニアが動的に 詳細なネットワークパスをマップする ネットワーク内の任意の 2 つのポイント間。

アンダーレイ、オーバーレイ、および次のような最新テクノロジーによるマッピングをサポートします。

• SDN
• SD-WAN
• ファイアウォール
• ロードバランシング

同時に、次のような高度なプロトコルも考慮します。

• ルーティング
• アクセスリスト
• PBR
• VRF
• NAT

展開すると、視覚化された構造は、 コードなしの自動化 大小を問わず、あらゆるタスクに！

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

＃1：遅いアプリケーションをマップする – ボストンとロサンゼルス間の Web アプリケーションが遅い。

＃2：VoIP トラフィック フローをマップする – ボストンとサンフランシスコ間の音声トラフィックは不安定です。

#3: DDoS攻撃のマッピング – 悪意のあるホストがネットワークにDoSトラフィックを注入しています。トラフィックの送信元と影響は？NetFlowを活用してトップトーカーを特定することで、経路をマッピングできます。

サービス提供の保証

チームがトラフィックフローレベルでアプリケーションパフォーマンスのトラブルシューティングと診断を行えるようにする NetBrainさん アプリケーション保証 （AAM）。それは：

• ハイブリッド クラウド ネットワーク内のアプリケーション ネットワーク パスの概要を単一ビューのマップで作成します。
• 健全なパスのベースラインを使用して、エンドツーエンドでパスのパフォーマンスを継続的に検証します。
• 適切なチームに積極的に警告し、潜在的に混乱を招く問題を解決できるようにします。

アプリケーションのパフォーマンス低下を防ぐ NetBrainコード不要のインテントベースの自動化。 NetBrain AAM は以下によってユーザー エクスペリエンスを保護します。

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