私は、Active Directory、Exchange、ターミナルサーバー、50クライアント、ファイル&プリントサーバーなどの通常の原因をすべて備えたMicrosoftネットワーク/環境を継承しています。
クライアントはすべて172.25.51。*の範囲にあり、インターネットからのダウンロード速度はサーバーが経験する速度のほんの一部です。この範囲のマシン間のファイル転送は、十分に問題がないようです。 (以下のマシン#1-クライアントからの出力を参照してください。)
サーバーはすべて172.25.24。*の範囲内にあり、インターネットからのダウンロード速度と相互間のファイル転送は問題ないようです(以下のマシン#2-サーバーからの出力を参照)。
2つの範囲間のファイル転送も非常に遅いようです。私の質問は最終的に別の質問につながると思いますが、最初に行う必要があることは次のとおりです。51。*範囲のクライアントが、インターネットおよび24. *範囲からのこのようなひどいダウンロード速度を経験する理由を正式に診断するにはどうすればよいですか?
インターネットが24. *の範囲を経由して入ってくるという事実は、その遅さを説明していると思います。そのため、診断して原因を見つける必要がある私の本当の問題は、サーバー間の速度低下の原因です(24。)とクライアント(51。)?
それが問題ではないことをどのように証明できるかについての提案を歓迎しますが、それはケーブルではないとかなり確信しています。それは専門の会社によって行われたので、どこかで構成の問題であると私は信じる傾向があります。任意の提案をいただければ幸いです。
#1-クライアント
ipconfig
V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:33:30--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9a.tar.bz2
=> `vlc-0.9.9a.tar.bz2'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done. ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)
100%[======================================>] 17,500,620 39.3K/s in 7m 35s
ipconfig/all
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : domain.local
Description . . . . . . . . . . . : Intel(R) 82566DM-2 Gigabit Network Connection
Physical Address. . . . . . . . . : 00-1E-4D-F4-35-57
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 172.25.51.77
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.51.1
DHCP Server . . . . . . . . . . . : 172.25.24.10
DNS Servers . . . . . . . . . . . : 172.25.24.18
172.25.24.12
Primary WINS Server . . . . . . . : 172.25.24.18
#2-サーバー
wget
V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:41:15--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vl.9a.tar.bz2
=> `vlc-0.9.9a.tar.bz2.1'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done. ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)
100%[======================================>] 17,500,620 510K/s in 28s
ipconfig
Ethernet adapter NIC:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2
Physical Address. . . . . . . . . : 00-11-54-31-32-50
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 172.25.24.17
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.24.1
DNS Servers . . . . . . . . . . . : 172.25.24.18
172.25.24.12
スイッチは管理されており、ログインできますか?帯域幅の乱用に対する誰かの解決策は、サーバーサブネットに対して特定の割合でQoSを実行することではなく、ユーザーサブネットが残っているもので苦しむことではなかったのではないかと思います。 (アイデアに魅力がある日があることを認めます)
デュプレックスのミスマッチはありますか?
パフォーマンスの問題があるときはいつでも、最初の質問は次のとおりです。これはDNSの問題ですか、それともネットワークですか。
接続の確立に時間がかかるが、最初の接続後に正常に機能する場合は、DNSに関連している可能性があります。ユーザーは通常、「インターネットが遅い」と不平を言います。
デュプレックスのミスマッチの場合は、リンクの両側でデュプレックス設定を探し、衝突を探し、送信/受信エラーを探します。デュプレックスのミスマッチは、リンクを自動ネゴシエートしないようにスイッチを設定した人が原因で発生することがよくあります。スイッチを100 /フルにハードコーディングしますが、リンクのコンピューター側もハードコーディングするように設定しません。 。多くの場合、リンクのその側は100 /半分になり、ごくわずかな量を超えるトラフィックをプッシュしようとするまで機能します。その時点で、すべてのパケットがドロップされるため、リンクの10 /半分よりもパフォーマンスが低下します(もう一方の端は衝突だと思っています)。
具体的には、デバイス「172.25.51.1」とは何ですか(明らかに、ある種のルーター)?
.51サブネットと.24サブネットの間のルーティングであり、何らかの理由でボトルネックになっているようです。
「172.25.24.1」デバイスと同じデバイスではないかもしれませんが、私は推測しています。
「172.25.51.1」デバイスに問題があるように感じます。デバイスをさまざまな物理ブロードキャストドメインに接続するインターフェイスの1つ、またはその構成に問題があります。サブネット間を移動するローカルトラフィックでも過負荷になる可能性があります。
「172.25.51.1」デバイスのイーサネットインターフェイスのインターフェイスエラーカウンターと、デバイスが接続されているスイッチポートを調べます。また、サブネット間を移動するトラフィックの平均量とCPUの負荷を測定してみます。
この種の状況では、トラフィックフローをある程度可視化できるように、 [〜#〜] mrtg [〜#〜] または Cacti のようなものが本当に必要です。 (そして、あなたのデバイスがそれをサポートしているなら、CPU使用率、温度など)。
サブネット上のすべてのクライアント間およびサブネット上のすべてのサーバー間の転送は問題ないが、クライアントサブネットとサーバーサブネット間では問題がない場合は、ルーターが原因であるように思われます。単一のデバイスの場合は、構成の問題があります。各サブネットに独自のルーターがある場合、51ルーターに問題があります。
それらの間にボトルネックとして機能する何かがあり、それはWindowsソフトウェアルーティングだと思います。トラブルシューティングの手順として、問題のあるクライアントを取得し、サーバーサブネットにポップして(他に何も変更しない)、何が起こるかを確認することをお勧めします。このためには、おそらく物理的に再配置する必要があります。