質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.52%

  • Cisco

    92questions

    シスコ(Cisco Systems,Inc.)は、アメリカ合衆国に本社を置く、世界最大のコンピュータネットワーク機器開発会社及び同社の製品

  • Network+

    45questions

    Network+とは、IT業界団体CompTIA認定のネットワーク技術に関する知識を証明する資格です。ネットワーク技術者として、実務で必要なネットワークセキュリティ・ネットワークアーキテクチャなどの知識を取得している証明となります。

Tracerouteの結果が表示されない理由が知りたい

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 485

ronin

score 10

お世話になっております。
プログラムについての事ではないのですが
ご回答頂ければ幸いです。

クライアントからサーバに対してtracerouteを実行した際、サーバ側のパケットキャプチャには
パケットが到着した事が表示されるのですが、クライアント側のtracerouteの表示では途中で
結果が表示されなくなり、* * *とタイムアウトとなり続け、ホップ数30迄繰り返したのち終了します。

この現象はPort5000のみで発生し、4999,5001のポートでのtracerouteはすぐに結果が表示されます。
おそらく途中のルータのQOS機能で帯域制御等を行っている為に発生している様な気がするのですが
この様な事象が発生する理由、または発生する可能性のある条件等をご教示頂けれると助かります。

また、この通信が必要なアプリケーションが正常に動作する端末と動作しない端末(同じセグメント内の端末)
が存在し、アプリケーション上の問題ではないと考えております。
経緯として、このアプリケーションが正常に動作しない問題があり、上記調査を行っていました。
traceroute実行時はこのアプリケーションで使用するport5000を使用して実行しています。
通信にはUDPを使用していますが、現象はTCPでも発生しております。

この現象はLinuxのtracerouteで実施し、再現率100%です。(ただし夜間は実施していません。)
windows端末からのtracerouteは10回中4回タイムアウトになります。(ただし途中の経路のノードのみ)

不明点等あれば記載しますので、なにとぞよろしくお願い致します。


ご質問に対する回答を以下に記載します。

ご質問ありがとうございます。
送信元portはランダムです。主に30000以上のportが使用されています。
送信先portが5000になり、プロトコルはUDPになります。
サーバ側も同様に5000portを開けています。

windowsで試したコマンドは以下です。(結果も抜粋します)
Test-NetConnection -ComputerName  <hostname> -port 5000
警告: TCP connect to (<address> : 5000) failed
windowsからはTCPしか試せていません。

[結果]
RemotePort             : 5000
InterfaceAlias         : イーサネット
PingSucceeded          : True
PingReplyDetails (RTT) : 11 ms
TcpTestSucceeded       : False

Linuxで試したコマンドは以下です。
traceroute -U p 5000 <address>

[結果]
[root@localhost ~]# traceroute -U -p 5000 <address>
traceroute to <address> (<address>), 30 hops max, 60 byte packets
1  <address1> (<address1>)  1.501 ms  1.464 ms  1.527 ms
2  <address2> (<address2>)  5.434 ms  6.089 ms  6.261 ms
3  <address3> (<address3>)  6.384 ms  7.293 ms  7.369 ms
4  <address4> (<address4>)  8.368 ms  8.240 ms  8.169 ms
5  <address5> (<address5>)  8.089 ms  7.937 ms  7.806 ms
6  <address6> (<address6>)  7.714 ms  6.171 ms  6.026 ms
7  <address7> (<address7>)  8.982 ms  13.406 ms  13.184 ms
8  * * *
9  * * *
10  * * *
ホップ30まで結果は変わりません。
address6からセグメントが変わり、ノードにアクセスする権限がありません。
サーバにはアクセス可能です。

なお、以下の通り、オプションにwを付けて待機時間を延ばしても結果が返却されませんでした。
traceroute -U -p 5000 -w 1000000 <address>

以上となります、ご確認よろしくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • over

    2018/05/18 11:19

    サーバ側ポートに辿りつくための調査ということですね。その場合、Port5000とはtcp、udpどちらですか?また、サーバがリッスンしているポートですか?それとも送信元ポートですか?加えて、Windows、Linux側で指定したオプションを教えてください。

    キャンセル

  • ronin

    2018/05/18 11:39

    お待たせ致しました、質問内容に追記を行いましたのでご確認頂けると助かります。

    キャンセル

  • ronin

    2018/05/21 08:50

    追記:土日と深夜帯で疎通を試みましたが、やはり深夜でも疎通はできませんでした。とはいえ、相手先のネットワークのトラフィック量をこちらで調査する事ができないので、実際どうなっているのかは良く分からない状態です。いろいろと聞いて回った所、相手先のネットワークはかなり前からネットワークが重くっているらしく(相手が先か内が原因かは不明)、それが事実であれば帯域制限ではなく、単純にネットワークが逼迫しているだけなのかもしれない…という状態になりました。結果が分かれば改めて記載します。

    キャンセル

回答 1

checkベストアンサー

0

明らかに閉じられているだろうポートを指定して同様のことを行いましたところ以下が再現しました。

* * *とタイムアウトとなり続け、ホップ数30迄繰り返したのち終了します。

とはいえ、閉じられている可能性に言及していないことから、全てオンプレミス構成であり、ポートが閉じられている可能性を排除しての質問なのだと理解しています。この認識に間違いないですか?

おそらく途中のルータのQOS機能で帯域制御等を行っている為に発生している様な気

QoSを疑っているようですが、icmpエコーの通信容量などたかが知れています。
試行時は他端末でアプリケーションを動かしており、それが帯域を食いつぶしているため至った見解でしょうか?
そうであれば、該当システム閑散期に試行してみればQoSが原因か切り分け出来ると思います。

この質問のゴールは、該当アプリケーションが使用できない端末における原因が知りたいということでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/18 12:39

    ご質問ありがとうございます。
    閉じられている可能性については考慮していません。説明不足で申し訳ありませんが
    同一の条件でサーバにアクセスする端末が数千台ありまして、正常に動作しているクライアントも存在している為です。

    帯域制御の件ですが、仰る通り、現在もアプリケーションが動いている為、疑いを感じております。
    24時間稼働しているシステムではありますが、深夜帯は流入が減るので、まずは確認してみようと思います。

    この質問のゴールですが、根本事象の解決よりまずは掲題のtracerouteの結果が起こりうる原因を知りたいと思っています。
    UDPの通信ではありますが、ソフトウェアレベルでは確認応答等をやりとりしており、サーバから応答が帰らない場合、クライアントが再送を行う事により、通常時から通信量が増大し続けている状況です。
    アプリケーション自体は特定人間が管理業務に使用するアプリケーションの為、利用者側には特に不便は生じておりません。

    portが開いていない場合も発生するというのも非常に参考になりました。netstatの結果では以下の様に表示され、なお正常に動作すクライアントもある為、盲目的に空いていると判断していたのですが、もしかしたらセキュリティソフト等で止められている可能性もあるのかも知れないですね。

    netstat -nao
    UDP 0.0.0.0:5000 *:* 1488
    UDP [::]:5000 *:* 1488

    キャンセル

  • 2018/05/21 09:00

    >「この通信が必要なアプリケーションが正常に動作する端末と動作しない端末」

    上記についてです。
    ネットワーク帯域を疑っているということは、正常動作する端末と異常動作する端末は日々(時々)で違うという理解であっていますか?

    キャンセル

  • 2018/05/21 09:29

    ご連絡ありがとうございます。
    ご質問の件ですが、明確に回答する事ができず、推測ですが以下の認識です。

    まず、正常動作と異常動作ですが、私は以下の2点の両方、または片方が合致する場合、異常と判断しています。
    ①クライアントからサーバに送信されるログファイルがクライアントに残存し続けている。
     →通常ファイルは1ファイルあるかないかですが、異常のあるクライアントは2カ月近く残っている。
    ②クライアントとサーバ間の通信で数GBに達する通信が存在する。
     →通常ファイルは数250kb程度のファイルが送信される程度で、この量の通信が発生する事はありません。

    ご質問の内容についての回答ですが、日々端末が異なるか、と言われますと、①②で異なる状況です。
    ①の事象が一度発生した端末が回復(ファイルの疎通が完了)したケースは確認できていません。
     したがってこの状態は一度発生したら毎日発生していると言えると思います。
     この状況はサーバとの疎通が正常に行う事ができれば解消する事は確認済みです。
     なお、この状況が発生する日にちはまちまちで3カ月前から発生した端末もあれば、1週間前に発生した端末もあります。

    ②に関しては調べている限りでは日々違う様です。
     ただし、①と②はそれぞれ関連がなく、①だけ、②だけのクライアントがある状態です。
     これは推測ですが、長い間リトライを繰り返し、疎通が完了した結果①の事象が解消されたのでは、とも考えています。

    キャンセル

  • 2018/05/21 10:25

    > ①クライアントからサーバに送信されるログファイルがクライアントに残存し続けている
    こちら、クライアントにファイル残存の場合、該当ファイルはサーバ未達なのでしょうか?

    > ②クライアントとサーバ間の通信で数GBに達する通信が存在する。
    数GBの通信は何を根拠としていますか?何かモニタリングしていますか?

    キャンセル

  • 2018/05/21 17:29

    >こちら、クライアントにファイル残存の場合、該当ファイルはサーバ未達なのでしょうか?
    はい、クライアントにファイルが残存した場合、そのファイルは未達になります。

    >数GBの通信は何を根拠としていますか?何かモニタリングしていますか?
    私が調査できるネットワークと外部ネットワーク(インターネットではありません)の境にFWがあり、そこの値を集計しています。
    ソフトウェア上の正確な動作は不明ですが、サーバ側から応答が返らない場合、クライアント側は12時間続けてサーバに対して投げ続けています。
    その通信の総量が数GBになります。

    キャンセル

  • 2018/05/21 18:29

    そうなると、ソフトウェア仕様が大きな障害になっていそうですね。
    12時間リトライを繰り返す端末が増えてきた場合、全ての端末に波及しそうです。

    ソフトウェア提供ベンダに問い合わせすることはできないのでしょうか?

    キャンセル

  • 2018/05/22 08:13

    ソフトウェアベンダには既に問い合わせており、ログ等の情報を送付した結果、互いのパケットが届いていないという回答を貰っています。
    ただし、FW上では上り下り共にパケットが通過している事を確認しているため、まったく通らないのではなく不安定な状態だと考えました。

    その後、ルータ等のエラーパケット情報、自分が調査できる範囲のネットワークの帯域使用量等を調査した結果、サーバがおいてある外部ネットワーク側に問題があるのではないかと思い、
    一時的に作成したLinuxの仮想環境をから製品と同様のプロトコルとPortを使用したtracerouteを発行した結果、生じた疑問が今回の質問の経緯になります。

    暫定対応策も確認済みでして、結局の所一時的にサービスを停止するしかない状況です。
    とはいえ、いつまでも停止している訳にはいかないので根本的な原因を見つけたいと考えています。

    近いうちに外部ネットワークの担当者と打ち合わせをする事になりましたので、そこで何か判明する事を期待しています。

    キャンセル

  • 2018/05/25 09:41

    外部ネットワークの担当者と打ち合わせをしたところ、やはり外部ネットワーク側でネットワークが逼迫している状況との事でした。
    とはいえ、ネットワークが逼迫したから被害を被ったのか、うちのサービスの動作が原因で逼迫したかはこれから調査していきます。
    ただ、tracerouteの結果がなぜこういった結果になるのかは分からないのが心残りですね。
    不安定なのであれば、深夜や、時々は正常に結果を返却しても良いような気がするのですが。

    最終的な調査結果が判明するまでは長くなりそうですので、本質問はここでクローズしようと思います。
    overさん、拙い質問内容にも拘わらずお付き合い頂きありがとうございました。

    キャンセル

  • 2018/05/25 10:00

    > tracerouteの結果がなぜこういった結果になるのかは分からないのが心残りですね。

    ポート指定でのtracerouteでの検証をしたことがない、かつ知識不足なので申し訳ないのですが、途中経路のパケットフィルタ機器でicmpエコーをフィルタしていた場合は同様の結果になるかも?です。

    キャンセル

  • 2018/05/25 10:35

    >>icmpエコーをフィルタしていた場合は同様の結果になるかも?です。
    なるほど…ただ、私の環境(クライアント側のセグメント)からwinとlinuxでのicmpでの疎通はうまく行くんですよね。
    ちなみに、たった今始めて知ったのですが、UDPでのtracerouteでも帰りはicmpのtype11なんですね。

    前任者の方が退社され、プロを雇わずに少しPCに詳しいレベルの私が引き継いだのでボロボロです。
    ただの愚痴ですみません。。。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.52%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • Cisco

    92questions

    シスコ(Cisco Systems,Inc.)は、アメリカ合衆国に本社を置く、世界最大のコンピュータネットワーク機器開発会社及び同社の製品

  • Network+

    45questions

    Network+とは、IT業界団体CompTIA認定のネットワーク技術に関する知識を証明する資格です。ネットワーク技術者として、実務で必要なネットワークセキュリティ・ネットワークアーキテクチャなどの知識を取得している証明となります。