Mac OSXマシン-Windows共有へのアクセスが非常に遅い
サイト間VPNを介してリモートのWindowsServer2003ボックスから共有にアクセスするMacボックスがいくつかあります。彼らはcifsを使用して共有に接続し、AD資格情報を使用して認証し、パフォーマンスは絶対に哀れです-共有ドキュメントを開く/コピーする/移動するのに5分以上待つと考えてください。100Kb未満の小さなドキュメントでも同様です。
私はこの状況に比較的慣れていませんが、私が引き継ぐ前にかなり長い間続いています。さらに詳しい背景として、Macと同じLAN上のWindowsマシンから、状況に予想される速度で同じファイルにアクセスできます。これらのマシンはすべて、Cisco PIXファイアウォール（サイト間VPNアクセスを提供）の背後にあるCiscoCatalystスイッチ上にあります。 MacボックスとWindowsボックスからファイルサーバーへのping応答はほぼ同じです：6〜7ミリ秒。
MacからWindows共有にアクセスするこのような問題を経験した人はいますか？これはプロトコルの問題ですか？ご入力いただきありがとうございます。
私の腸は、VPNでMTUの問題が発生している可能性があると言っています。パスMTUディスカバリーはこれを回避することになっていますが、ネットワーク機器の構成が間違っているために正しく機能しない可能性があります。
OS/Xでの特定のPING構文が何であるかはわかりませんが、Windowsでは、次の構文を使用してサーバーからクライアントの1つにPINGを送信できます。
PING <destination> -l <length> -f
これにより、指定された長さのPINGパケットが、「フラグメント化しない」ビットが設定された宛先に送信されます。 MTUが小さい接続がない限り、クライアントとサーバー間で長さ1472のパケットを移動できるはずです。
いくつかの背景については、Microsoftのこの記事をご覧ください： http://support.Microsoft.com/kb/314825
HTTPやFTPなど、VPN上で実行されている他のプロトコルに問題がありますか？ CIFSは、潜在性の高いリンクで最高のパフォーマンスを発揮するわけではありませんが、話している時間は、「通常の」CIFSの吸い込みの範囲外です。
考えられるMTUの問題を診断するには、OSXのping構文は次のようになります。
ping -D -s packetsize destination
ここで、packetsizeは、送信するデータバイト数からICMPヘッダーの8バイトを引いたものです（つまり、デフォルトのパケットサイズは56で、56 + 8 = 64バイトのパケットが送信されます）。