Q&A
tracerouteは経路を調べるコマンドであって、途中のポート開放可否を確認するものではないと認識しています。 ご質問内容から途中経路のポート開放確認を調べているように見受けられるのですが認識違いますか?
お世話になっております。
プログラムについての事ではないのですが
ご回答頂ければ幸いです。
クライアントからサーバに対してtracerouteを実行した際、サーバ側のパケットキャプチャには
パケットが到着した事が表示されるのですが、クライアント側のtracerouteの表示では途中で
結果が表示されなくなり、* * *とタイムアウトとなり続け、ホップ数３０迄繰り返したのち終了します。
この現象は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>
以上となります、ご確認よろしくお願い致します。
ご回答ありがとうございます。その点については認識しております。ただ、記載に漏れてしまいましたが、サーバ側のポートが開いている事は確認済みで、且つ経路上のノードにアクセスできない為、tracerouteでプロトコルとポート番号を指定して調査しております。
サーバ側ポートに辿りつくための調査ということですね。その場合、Port5000とはtcp、udpどちらですか?また、サーバがリッスンしているポートですか?それとも送信元ポートですか?加えて、Windows、Linux側で指定したオプションを教えてください。
お待たせ致しました、質問内容に追記を行いましたのでご確認頂けると助かります。
追記：土日と深夜帯で疎通を試みましたが、やはり深夜でも疎通はできませんでした。とはいえ、相手先のネットワークのトラフィック量をこちらで調査する事ができないので、実際どうなっているのかは良く分からない状態です。いろいろと聞いて回った所、相手先のネットワークはかなり前からネットワークが重くっているらしく（相手が先か内が原因かは不明）、それが事実であれば帯域制限ではなく、単純にネットワークが逼迫しているだけなのかもしれない…という状態になりました。結果が分かれば改めて記載します。
回答1件
0
ベストアンサー
明らかに閉じられているだろうポートを指定して同様のことを行いましたところ以下が再現しました。
- *とタイムアウトとなり続け、ホップ数３０迄繰り返したのち終了します。
とはいえ、閉じられている可能性に言及していないことから、全てオンプレミス構成であり、ポートが閉じられている可能性を排除しての質問なのだと理解しています。この認識に間違いないですか?
おそらく途中のルータのQOS機能で帯域制御等を行っている為に発生している様な気
QoSを疑っているようですが、icmpエコーの通信容量などたかが知れています。
試行時は他端末でアプリケーションを動かしており、それが帯域を食いつぶしているため至った見解でしょうか?
そうであれば、該当システム閑散期に試行してみればQoSが原因か切り分け出来ると思います。
この質問のゴールは、該当アプリケーションが使用できない端末における原因が知りたいということでしょうか?
投稿2018/05/18 03:14
総合スコア4315
ご質問ありがとうございます。
閉じられている可能性については考慮していません。説明不足で申し訳ありませんが
同一の条件でサーバにアクセスする端末が数千台ありまして、正常に動作しているクライアントも存在している為です。
帯域制御の件ですが、仰る通り、現在もアプリケーションが動いている為、疑いを感じております。
２４時間稼働しているシステムではありますが、深夜帯は流入が減るので、まずは確認してみようと思います。
この質問のゴールですが、根本事象の解決よりまずは掲題のtracerouteの結果が起こりうる原因を知りたいと思っています。
UDPの通信ではありますが、ソフトウェアレベルでは確認応答等をやりとりしており、サーバから応答が帰らない場合、クライアントが再送を行う事により、通常時から通信量が増大し続けている状況です。
アプリケーション自体は特定人間が管理業務に使用するアプリケーションの為、利用者側には特に不便は生じておりません。
portが開いていない場合も発生するというのも非常に参考になりました。netstatの結果では以下の様に表示され、なお正常に動作すクライアントもある為、盲目的に空いていると判断していたのですが、もしかしたらセキュリティソフト等で止められている可能性もあるのかも知れないですね。
netstat -nao
UDP 0.0.0.0:5000 *:* 1488
UDP [::]:5000 *:* 1488
>「この通信が必要なアプリケーションが正常に動作する端末と動作しない端末」
上記についてです。
ネットワーク帯域を疑っているということは、正常動作する端末と異常動作する端末は日々(時々)で違うという理解であっていますか?
ご連絡ありがとうございます。
ご質問の件ですが、明確に回答する事ができず、推測ですが以下の認識です。
まず、正常動作と異常動作ですが、私は以下の２点の両方、または片方が合致する場合、異常と判断しています。
①クライアントからサーバに送信されるログファイルがクライアントに残存し続けている。
→通常ファイルは１ファイルあるかないかですが、異常のあるクライアントは２カ月近く残っている。
②クライアントとサーバ間の通信で数GBに達する通信が存在する。
→通常ファイルは数250kb程度のファイルが送信される程度で、この量の通信が発生する事はありません。
ご質問の内容についての回答ですが、日々端末が異なるか、と言われますと、①②で異なる状況です。
①の事象が一度発生した端末が回復（ファイルの疎通が完了）したケースは確認できていません。
したがってこの状態は一度発生したら毎日発生していると言えると思います。
この状況はサーバとの疎通が正常に行う事ができれば解消する事は確認済みです。
なお、この状況が発生する日にちはまちまちで３カ月前から発生した端末もあれば、１週間前に発生した端末もあります。
②に関しては調べている限りでは日々違う様です。
ただし、①と②はそれぞれ関連がなく、①だけ、②だけのクライアントがある状態です。
これは推測ですが、長い間リトライを繰り返し、疎通が完了した結果①の事象が解消されたのでは、とも考えています。
> ①クライアントからサーバに送信されるログファイルがクライアントに残存し続けている
こちら、クライアントにファイル残存の場合、該当ファイルはサーバ未達なのでしょうか?
> ②クライアントとサーバ間の通信で数GBに達する通信が存在する。
数GBの通信は何を根拠としていますか?何かモニタリングしていますか?
＞こちら、クライアントにファイル残存の場合、該当ファイルはサーバ未達なのでしょうか?
はい、クライアントにファイルが残存した場合、そのファイルは未達になります。
＞数GBの通信は何を根拠としていますか?何かモニタリングしていますか?
私が調査できるネットワークと外部ネットワーク（インターネットではありません）の境にFWがあり、そこの値を集計しています。
ソフトウェア上の正確な動作は不明ですが、サーバ側から応答が返らない場合、クライアント側は12時間続けてサーバに対して投げ続けています。
その通信の総量が数GBになります。
そうなると、ソフトウェア仕様が大きな障害になっていそうですね。
12時間リトライを繰り返す端末が増えてきた場合、全ての端末に波及しそうです。
ソフトウェア提供ベンダに問い合わせすることはできないのでしょうか?
ソフトウェアベンダには既に問い合わせており、ログ等の情報を送付した結果、互いのパケットが届いていないという回答を貰っています。
ただし、FW上では上り下り共にパケットが通過している事を確認しているため、まったく通らないのではなく不安定な状態だと考えました。
その後、ルータ等のエラーパケット情報、自分が調査できる範囲のネットワークの帯域使用量等を調査した結果、サーバがおいてある外部ネットワーク側に問題があるのではないかと思い、
一時的に作成したLinuxの仮想環境をから製品と同様のプロトコルとPortを使用したtracerouteを発行した結果、生じた疑問が今回の質問の経緯になります。
暫定対応策も確認済みでして、結局の所一時的にサービスを停止するしかない状況です。
とはいえ、いつまでも停止している訳にはいかないので根本的な原因を見つけたいと考えています。
近いうちに外部ネットワークの担当者と打ち合わせをする事になりましたので、そこで何か判明する事を期待しています。
外部ネットワークの担当者と打ち合わせをしたところ、やはり外部ネットワーク側でネットワークが逼迫している状況との事でした。
とはいえ、ネットワークが逼迫したから被害を被ったのか、うちのサービスの動作が原因で逼迫したかはこれから調査していきます。
ただ、tracerouteの結果がなぜこういった結果になるのかは分からないのが心残りですね。
不安定なのであれば、深夜や、時々は正常に結果を返却しても良いような気がするのですが。
最終的な調査結果が判明するまでは長くなりそうですので、本質問はここでクローズしようと思います。
overさん、拙い質問内容にも拘わらずお付き合い頂きありがとうございました。
> tracerouteの結果がなぜこういった結果になるのかは分からないのが心残りですね。
ポート指定でのtracerouteでの検証をしたことがない、かつ知識不足なので申し訳ないのですが、途中経路のパケットフィルタ機器でicmpエコーをフィルタしていた場合は同様の結果になるかも?です。
>>icmpエコーをフィルタしていた場合は同様の結果になるかも?です。
なるほど…ただ、私の環境（クライアント側のセグメント）からwinとlinuxでのicmpでの疎通はうまく行くんですよね。
ちなみに、たった今始めて知ったのですが、UDPでのtracerouteでも帰りはicmpのtype11なんですね。
前任者の方が退社され、プロを雇わずに少しPCに詳しいレベルの私が引き継いだのでボロボロです。
ただの愚痴ですみません。。。
あなたの回答
tips
プレビュー
