タグ付けされた質問 「packet-analysis」

3
traceroute / tracertはすべてのホップを表示しますか、それともパスの一部の詳細をスキップ/非表示にしますか?
現在、私は大学でネットワークエンジニアリングの学士号を取得しており、教授の一人がクラスで、たとえば15ホップを示すtracerouteが実際にパスを抽象化しており、実際にはさらに多くのノードが関与していると説明しました。これは本当ですか? これは、tracerouteで見つけることができるすべてのものと矛盾しています。私の知る限り、tracerouteはICMP(またはUDP)パケットを0からTTLの特定の宛先に送信することで機能します-> n宛先に到達するまで。送信されたプローブパケットは、途中で各場所で連続してタイムアウトし、ICMPの「time exceeded」応答を生成し、最終的に宛先に到達すると「port unreachable」メッセージを生成します。 tracerouteの欠陥を理解しています。たとえば、特定のゲートウェイによってtracerouteトラフィックがブロックされたり、応答パケットのTTLがプローブの残りのTTLに設定されて、送信者に戻らないことがあります。 ただし、多くの調査を行った後、常に同じパスを返すtracerouteの場合、tracerouteを参照するものが不正確であることはわかりません。同様に、tracerouteによって報告されない「余分な」ホップがあることを参照するものはありません(応答なしでタイムアウトになった* * *ホップ以外)。 私は議論を受け入れており、これに対する答えを知りたいと心から思っています。

3
ネットワークタップに4つのポートがあるのはなぜですか?
私はこのようなハードウェアネットワークタップを見て、Catalystスイッチで実行されている疑似永続的なSPANを置き換えました。私が見つけるすべてのタップには、A、B、および2つの出力ポート(各方向に1つ)の4つのインターフェイスがあります。理想的には、両方向からのトラフィックを1本のケーブルに集めて、1つのインターフェイスからキャプチャするだけで済むようにしたいと思います。タップに常に2つの出力ポートがあるように見えるのはなぜですか?

2
低メトロイーサネットTCPスループットのトラブルシューティング
セットアップ レイヤー2ネットワークとして存在するいくつかの専用線を借りました。つまり、データセンターに1本の大きなパイプがあり、リモートサイトには小さなパイプがあります。レイヤー2ネットワーク内では、何でも好きなことができます。おそらく802.1adを使用して、ネットワーク内の各顧客に個別のネットワークを提供します。AFAICSほとんどのサイトはプレーンVDSLで接続されています。 各サイトにルーターを配置し、各サイトに独自のVLANを割り当てることにしました。したがって、DCのファイアウォールには、サイトと同数のVLANが定義されています。したがって、各サイトは独自のVLANでオンアドレス範囲を使用します。 ネットワーク図: 問題 現在、スループットの問題に直面しています。 サイトからDCへのFTP転送の実行は、回線速度である約10Mb / sで正常に機能します。 DCからサイトへのFTP転送の実行は、6Mb / s以下ではうまく機能しません。 どちらが転送を開始するかは関係ありません。唯一一貫したことは、1つの方向がうまく機能していないことです。残念なことに、それはサイトへの方向です。これは、ターミナルサーバークライアントを使用したいときに最も必要な帯域幅だからです。 転送から約10秒で、スループットが低下します。スニッフィング時にDUP ACKが表示されます。プロバイダの側でレート制限につながる可能性があるのはどれですか?? (現在、彼らには手がかりがありません。エスカレーションする前に私たちが過失になっていないことを確認したいです) 注リモートサイトは何らかの理由で10Mbに制限されています。メトロポートへの切り替えを10Mbに設定しても解決しません。実際、それは最悪です(最大30 KB / s)。100Mbに設定しても正常に機能しますが、すでに概説した問題が発生し始めています。1Gでも同じです。 問題のキャプチャはここからダウンロードできます: * http://178.63.11.6/dc-to-remote_dc-side.pcapng * http://178.63.11.6/dc-to-remote_remote-side.pcapng 診断 画像には、エラーの詳細が記載されたWireshark IO Graphが表示されます。 左側:DCからサイトへのFTP転送 右側:サイトからDCへのFTP転送 反対側が転送を開始した場合(つまり、リモートから取得するのではなく、DCから取得した場合)、問題は変わりません。 ここで問題になると思われるものをお楽しみください。 更新#1(上記に統合) 更新#2(更新) これは輻輳制御のものでなければなりません。 DCからリモートに10G-> 1G-> 100M-> 10M-> 1Gリンクがあることに注意してください。<-動作していません したがって、他の方向では逆になります:1G-> 10M-> 100M-> 1G-> 10G。<-元気 最初の「1G-> 10M」は、リモートサイトで「見えない」10Mであり、アップリンクポート速度を含むすべてが1Gに設定されています。 ただし、DCでの100Mbpsは実際の100Mbpsであり、インターフェイスは物理層で100Mbpsに設定されます。 私は今iperfを使用しました: …

2
ネットワークなしでwifiパケットをブロードキャストする
Wifiについて質問がありますが、どこにも答えが見つかりませんでした。 任意の種類のネットワーク(アドホックかどうか)に参加することなく、wifi経由でパケットを送信することは可能ですか? ネットワークに参加せずに空中でパケットを送信できるようにしたいと思います。監視モードの別のデバイスは、どのパケットを処理する必要があるかを認識できます。WiFiはこれを行うための最良の方法ではないかもしれないことを知っています。 実際、ワイヤレスネットワークの検出中に何らかの種類のパケットが送信される必要がありますか?接続を確立せずに、さまざまなSSIDをネットワーク経由でどのように転送しますか?WiFi経由でネットワークを発見するために、どのような種類のパケットが送信されますか? 誰かがこれについてのいくつかのドキュメントの方向に私を向けることができれば、それを見つけることができませんでした。 どうもありがとう!

2
アダプタがすでに知っているものをなぜARPするのですか?
ネットワーク上のマシンがゲートウェイにMACアドレスをすでに知っているのに、そのMACアドレスをゲートウェイに要求する理由がわかりません。 だからここにあなたがマシンMAC *** 80見ることができます(IPを。。*。115)10.1.10.1を持っているゲートウェイ(Cisco_87)を、尋ねますか?つまり、ゲートウェイはどこにあるのでしょうか。しかし、ARPを直接ゲートウェイに送信するため、ゲートウェイはすでに誰であるかを知っています。クエリがブロードキャストである場合、つまりゲートウェイが誰であるかをANYBODYが教えても、パケットがブロードキャストされなかった場合、それは直接ゲートウェイ(CISCO_87)に送信され、他の誰にも送信されなかったので、明らかにマシンはすでにゲートウェイが誰であるかを知っています。

2
ポートはポートのRx(またはTx)方向のみをミラーリングしていますか?
イーサネットLANの何かが時々偽の重複パケットを送信しており、それを追跡する必要があります。複製されたパケットが常に同じ送信元MACアドレスからのものであるとは限らないため、原因はスイッチまたは他のブリッジ(Wi-Fi APなど)であり、エンドポイントではない可能性があります。 ポートミラーリングをサポートする管理可能なスイッチを入手し、スニファーと一緒に使用して、ポートに出入りするトラフィックをスニッフィングすることを考えていますが、キャプチャされた各パケットが送信された方向を知る必要があるため、どの方向がわかるのでしょうか。元の複製と複製されたものです。オリジナルと複製が異なる方向から来た場所をネットワーク上で見つけることができれば、その原因は複製の元の側にあるはずです。 私の問題は、過去に使用したポートミラーリングスイッチでは、特定のポートからミラーポートへの "双方向"(送信と受信の両方)のミラーリングのみが許可されていました。 誰かが私に一方向のみをミラーリングできる解決策を提案できますか?私は2つのスニファーを接続することを考えています。1つは「Tx」方向用で、もう1つは「Rx」方向用です。これにより、パケットがどの方向に進んでいたかがわかります。私はこれを達成するために新しい扱いやすいスイッチやタップを購入してもかまいません。 スプリアスパケットの重複の原因を追跡する他のアイデアは受け入れることができますが、このネットワーク上の現在のスイッチはひどく管理できないため、管理可能なスイッチを想定するソリューション(「このようなパケットトレースを有効にする」など) "、または" SNMPを介してすべてのスイッチから統計をプルし、<app>のデータをクランチする ")は、私の状況では実用的ではない可能性があります。

5
TCPストリームのパケットサイズ
私はネットワークトラフィックであり、各TCPセッションを一連の要求と応答(HTTPやSSLなどのすべての方法で機能しているプロトコル)に分割したいと考えています。 私は単純な仮定をしました(順不同でパケットを再送信することは無視します)-送信する必要があるデータのチャンクが与えられると、それは可能な最大のパケットを使用して送信され、最後のパケットは最大サイズよりも小さいか、または従います反対側からのパケット(ACK空パケットを無視)。したがって、HTTPセッションでは、(再び、ackを無視して)のようなものが表示されることを期待しています- パケット1-「Get ...」の要求 パケット2-応答、サイズ1434 パケット3-応答、サイズ1434 パケット4-応答、サイズ1434 パケット5-応答、サイズ500 ほとんどのセッションでこれが行われますが、少なくとも1回は次のようなことがありました。 パケット1-「Get ...」の要求 パケット2-応答、サイズ1434 パケット3-応答、サイズ1080 パケット4-応答、サイズ1434 パケット5-応答、サイズ500 ここでは再送信、順序正しくないパケット、サーバーでの例外的な遅延はありません。 知りたい-何が原因で、いつ発生するのか?私の仮定はどのように間違っていますか? 更新 ここに pcapファイルの例を入れます アップデート2 tshark関連フィールドのあるダンプを含める... $ tshark -r http_1082.pcap -T fields -e frame.number -e frame.len \ -e ip.src -e ip.dst -e tcp.flags.push -e http.request.method \ -e http.request.uri -e http.response.code | head -n 47 …

1
WireSharkはパケットがDUPまたは再送信されたと想定しますか?
同じスニファに向かう2つの異なるスイッチポートにSPANがあります。ホストAの接続ポートはSPANされ、ホストBの接続ポートもSPANされます。これはスティックタイプの構成上のルーターであるため、アプリケーションログから通信障害が報告されている間、両側で特定のパケットを検索できることを期待していました。私のトレースで大量の再送信があることがわかります。Wiresharkのロジックが何かを再送信としてマークした場合、それが2回見られた場合に興味がありますか? このようなものをトレースしているときのヒントはありますか? ありがとう


1
パケットキャプチャ
パケットキャプチャに関して、特定の用語と設定を理解するのに苦労しています。例。私の会社では、NetScoutと、PFS(Packet forwading switch)やTAP、Infinistreamなどのさまざまなサービスを使用しています。私の問題は、PFSとTAPの違いは何ですか?彼らはまったく同じことをしているようです。また、パケットキャプチャと絶対時間を見ると、データがTAPがデータを送信する時間のワイヤーにデータが到達する時間です。申し訳ありませんが、私の質問がそれほど明確ではありません。

2
ポートミラーリングなしの監視
問題の概要 最近、帯域幅の使用に関するいくつかの問題が発生しています。これは、オフィスでのインターネットの誤用(故意かどうかに関係なく)が原因と思われます。ネットワークトラフィックを監視して、特定の内部IPアドレスに障害があるかどうかを確認したい。私たちの帯域幅は十分以上でなければなりません。 私たちのセットアップ Cisco PIX 501ファイアウォールに接続された3Com Superstack 3スイッチがあり、それがISP提供のルーターに接続されています。 私が試したこと スイッチもファイアウォールもポートミラーリング機能が利用できないようです。そのため、永続的なトレースを維持できません。PIXは自身のメモリバッファへの一時的なトレースを提供しますが、これを使用する自信があまりありません。 私は(Windows 2000)DNSサーバーにWiresharkをインストールしようとしましたが、ここのパケットデータは役に立ちませんでした。 次のステップ トラフィックの監視方法に関する皆さんからの提案は素晴らしいでしょう。ただし、既存のハードウェアを交換する立場にはまだありません。スイッチとファイアウォール(またはファイアウォールとルーター)の間に配置できるネットワークタップのコストを調べ、そこにパケットを監視するマシンをセットアップしました。私はこれまでこのアプローチを採用したことがないので、それが本当に実行可能かどうか疑問に思いました。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.