タグ付けされた質問 「mtu」

ここの表によると、 MTU = 1500バイトであり、ペイロード部分は1500-42バイトまたは1458バイトであると言います（<-これは実際に間違っています！）。さらにその上に、28バイト（20 IP + 8 UDP）のIPv4およびUDPヘッダーを追加する必要があります。これにより、アプリケーションメッセージの最大可能数は1430バイトになります。しかし、インターネットでこの番号を探すと、代わりに1472が表示されます。ここでこの計算を間違っていますか？ 私が知りたいのは、断片化のリスクなしにネットワークを介して送信できる最大のアプリケーションメッセージだけです。フレームヘッダーが含まれているため、確実に1500ではありません。誰か助けてもらえますか？ 混乱は、PAYLOADが実際に1500バイトにもなることがあり、それがMTUであるということです。それでは、1500のペイロードのワイヤ内サイズはどのくらいですか？そのテーブルからは、1542バイトまで大きくなる可能性があります。 したがって、送信できるアプリメッセージの最大数は1472（1500-20（ip）-8（udp））で、ワイヤーサイズは1542で最大です。実際に単純な場合に、事態がどのように複雑になるかは驚きです。また、テーブルに1542と表示されている場合、誰かが1518という数字をどのように思いついたかはわかりません。

22 networking  tcp  ethernet  udp  mtu 

この質問の最後に追加された新しい詳細。私が原因を突き止めている可能性があります。 UDP OpenVPNベースのVPNをtapモードで設定しています（tapマルチキャストパケットを通過させるためにVPNが必要なため、tunネットワークでは不可能と思われるため）、インターネット上の少数のクライアントを使用しています。VPNで頻繁にTCP接続がフリーズすることがあります。つまり、TCP接続（たとえば、SSH接続ですが、他のプロトコルには同様の問題があります）を確立し、セッション中のある時点で、そのTCPセッションを介したトラフィックの送信が停止するようです。 これはls、SSHセッションでコマンドを実行する場合やcat、長いログファイルを使用する場合など、大量のデータ転送が発生するポイントに関連しているようです。一部のGoogle検索では、Server Faultで次のような多数の回答が表示されます。原因はMTUの問題である可能性が高いことを示しています。トラフィックが多い期間中、VPNは、 VPNエンドポイント。上記のリンクの回答は、次のOpenVPN構成設定を使用して問題を軽減することを提案しています。 fragment 1400 mssfix これにより、VPNで使用されるMTUが1400バイトに制限され、TCPの最大セグメントサイズが修正され、それより大きいパケットが生成されなくなります。これは問題を少し緩和するようですが、それでもフリーズが頻繁に発生します。fragmentディレクティブの引数として、1200、1000、576のサイズをいくつか試しましたが、すべて同様の結果が得られました。このような問題を引き起こす可能性のある、両端間の奇妙なネットワークトポロジは考えられません。VPNサーバーは、インターネットに直接接続されているpfSenseマシンで実行されており、クライアントも別の場所でインターネットに直接接続されています。 パズルのもう1つの奇妙なピース：tracepathユーティリティを実行すると、問題を解決できるようです。サンプルの実行は次のようになります。 [~]$ tracepath -n 192.168.100.91 1: 192.168.100.90 0.039ms pmtu 1500 1: 192.168.100.91 40.823ms reached 1: 192.168.100.91 19.846ms reached Resume: pmtu 1500 hops 1 back 64 上記の実行は、VPN上の2つのクライアント間で行われます：192.168.100.90からの宛先へのトレースを開始しました192.168.100.91。fragment 1200; mssfix;リンクで使用されるMTUを制限しようとして、両方のクライアントが構成されました。上記の結果はtracepath、2つのクライアント間で1500バイトのパスMTUを検出できたことを示唆しているようです。OpenVPN構成で指定されたフラグメンテーション設定のために、それはいくらか小さくなると思います。その結果はやや奇妙だと思いました。 さらに奇妙なことですが、ストール状態のTCP接続（たとえば、途中でフリーズするディレクトリリストを含むSSHセッション）がある場合、上記のtracepathコマンドを実行すると、接続が再び開始されます。なぜそうなるのかについての合理的な説明はわかりませんが、これは最終的に問題を根絶するための解決策を指しているのではないかと感じています。 誰か他のことを試してみるための推奨事項はありますか？ 編集：私は戻ってきて、これをもう少し見てみましたが、もっと混乱する情報しか見つかりませんでした： 上記のように、OpenVPN接続を1400バイトでフラグメント化するように設定しました。次に、インターネット経由でVPNに接続し、Wiresharkを使用して、ストールの発生中にVPNサーバーに送信されたUDPパケットを調べました。指定された1400バイトカウントを超えるものはなかったため、断片化は適切に機能しているようです。 1400バイトのMTUでも十分であることを確認するために、次の（Linux）コマンドを使用してVPNサーバーにpingを実行しました。 ping <host> -s 1450 -M do これは（断片化を無効にした）1450バイトのパケットを送信します（少なくとも1600バイトのような明らかに大きすぎる値に設定すると動作しないことを確認しました）。これらはうまく機能するようです。私は問題なくホストから返信を受け取ります。 …

19 vpn  openvpn  tcp  mtu 

mtuが1500に設定されている場合にのみgoogle.comやibm.comなどのWebサイトに接続できたこの問題がありましたが、他に接続しようとすると、空白のページが表示されるだけでした。mtuが1499に下げられると、機能し始めました。私はこれがなぜ機能するのか興味があり、mtuを1499に設定すると将来的に問題が発生する可能性がありますか？私は実際にこれについてあまり知りません。ただそれについて聞いたばかりで、良い説明を探しています。 MTUが1バイトしかドロップされなかった理由の説明が得られたら、質問を説明で更新します。

16 mtu 

お客様には数十台の組み込みデバイスがインストールされており、すべてOpenVPNサービスの本拠地となっています。これは一般的には正常に機能しますが、一部のお客様には深刻なパスMTU問題があります。お客様のネットワークを修正する影響は限られているため、それに対処するにはOpenVPNが必要です。一言で言えば、私の質問は次のとおりです。 クライアントごとにいくつかのクライアントの低パスMTUを緩和するにはどうすればよいですか？つまり、すべてのクライアントの最悪のケースに対応するグローバル設定を使用せずに 最悪の場合はかなり悪いことに注意してください。パスMTU 576は、すべてのフラグメントをドロップし、それ自体をフラグメント化せず、DFビットを尊重しません。この問題を世界的に解決したくない理由がわかります。 OpenVPNのマンページの最も顕著な申し出MTU関連オプションの数を、--link-mtu, --tun-mtu, --fragment and --mssfix。しかし、それはまた言う --link-mtu [...]何をしているのかわからない限り、このパラメーターを設定しないことが最善です。 --tun-mtu [...] MTUのサイズ設定の問題に対処するには、-fragmentおよび/または--mssfixオプションを使用するのが最善です。 私は実験を始めて--fragmentと--mssfixすぐが、少なくとも前者はクライアント側だけでなく、設定しなければならないことを認識しなければならなかったまた、サーバー側の。その後、サーバー側のクライアントごとの設定を調べました--client-config-dirが、 次のオプションは、クライアント固有のコンテキストで有効です：--push、-push-reset、-iroute、-ifconfig-push、および--config。 MTUオプションの言及はありません！ だからここに私のより具体的な質問があります： なぜ正確にあるlink-mtuとtun-mtu落胆？これらのオプションの潜在的な問題は何ですか？低レベルのIPヘッダー変更に非常に満足していることに注意してください。 link-mtu tun-mtu fragment mssfix動作させるには、サーバー側でミラーリングする必要があるオプションはどれですか？ どのオプションを使用link-mtu tun-mtu fragment mssfixできますclient-config-dirか？ 4つのオプションすべてをサーバー側でミラーリングする必要client-config-dirがあり、内部で使用できない場合：クライアントごとに低パスMTUと戦う代替手段はありますか？ ノート： 私の質問の一部は、5年前にここですでに質問されていますが、当時は本当に回答されていないため、それらを複製することを敢えてします。 OpenVPNサーバーは、現在Ubuntu 12.04で2.2.1です。Ubuntu 14.04で2.3.2へのアップグレードを準備しています OpenVPNクライアントはDebian 7.6で2.2.1です お客様のパス-MTUを自分で手動で決定できてうれしいです 現在、多くのサーバー側をテストすることはできません。しかし、我々は完全な独立したテストベッドを構築しています、すぐに準備ができているはずです。 役立つアドバイスをありがとう。

14 ip  openvpn  mtu  ip-fragmentation 

さて、いくつかのXserve、Netgear GSM7224、およびDrobo B800iの間のジャンボフレームの問題の解決を終えました。Xserve（Mac OS X 10.6.8 Server）およびDrobo B800iは通常予想されるようにバイト単位のMTU（1500-9000）を受け入れますが、Netgearはさまざまなイーサネットヘッダー/フッター（トレーラー）を含めてそれを望んでいたようです）そして最終的に、Xserves＆DroboはMTU 9000で構成され、NetgearポートはMTU 9216に設定されました。 Netgear上の2つのXserve間のMTUをテストおよび検証するために次のコマンドを使用しました（注：これらはMac OS Xコマンドで、WindowsとLinuxのコマンドは異なります）。 ping -D -s <mtu> <ip_address> traceroute -F <ip_address> <mtu> 前者の使用法は、manページに「送信するデータバイト数を指定します。デフォルトは56です。これは、8バイトのICMPヘッダーデータと組み合わせると、64 ICMPデータバイトに変換されます。」テストではping -D 1472 <ip_address>、8バイトのICMPヘッダーデータと20バイトのIPヘッダーにより、toがMTU 1500に相当することがわかりました（これとこれを参照）。それはすべて理にかなっています。 では、なぜ9000 MTUに相当するコマンドなのping -D -s 8164 <ip_address>ですか？「sendto：Message too long」エラーが表示される前にこれが制限であることを確認しましたが、9000 MTUが正常にtraceroute -F <ip_address> 9000機能していることも機能してtraceroute -F <ip_address> 9001いないことも確認しました。それでは、なぜ8164ですか？8972（MTU-28バイト、1500 MTUのように）を期待していました。 また、なぜNetgearの9216 MTUですか？MACヘッダーとイーサネットヘッダー（CRCを含む）に42バイト、IPヘッダーに20バイト（MTUに食い込むはず）をカウントしました。 私はこの数学に本当に錆びており、何かが欠けているだけだと知っています。

14 tcp  ethernet  tcpip  gigabit-ethernet  mtu 

回線速度に達しないOpenVPNトンネルに問題があります。ゲートウェイは、OVHでホストされるDebian Jessy仮想サーバーです。クライアントは、freebsd 10.2ホームサーバー（Intel I3 Ivy Bridge）またはRaspberryPI2です。暗号化と認証を無効にしました。100mbit / sの対称FTTH接続がありますが、トンネルの速度は20〜40mbit / sにしか達しません。直接接続（トンネルなし）では、常に100mbit / sが期待されます。iperf3でパフォーマンスをテストしました。私は最初にfreebsdホームサーバーで試しました。mssfix、fragmentなどに関するすべての推奨設定を試しました。何も役に立ちませんでした。 それから多分それは私のfreebsdマシンだと思った。そこで、私はRPI2に新しいRaspbian Jessyをインストールし、さらに詳細なテストを行いました。 まず、OpenVPN構成からすべてのMTU設定を削除し、パスMTUで処理できるようにします（うまくいけば）。両方のマシンでファイアウォールがアクティブになっていないため、動作するはずです。これらは私のvpn設定です： server 10.8.0.0 255.255.255.0 port 1194 proto udp dev tun sndbuf 0 rcvbuf 0 user nobody group nogroup persist-key persist-tun ifconfig-pool-persist ipp.txt keepalive 10 120 push "redirect-gateway def1" status openvpn-status.log verb 3 ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt …

13 vpn  performance  openvpn  mtu 

DFビットが設定され、パケットサイズがルーターに対して大きすぎるリモートサイトにpingを実行すると、最初のICMP "fragmentation required"メッセージがルーターから送信されます。その後、メッセージは私のローカルホストから来ます。 Netstat -rC（Linux）では、ルーティングテーブルキャッシュを表示できますが、 1）MSSと呼ばれる列の下にMTUを表示するようです（これはリンクの下位TCP MSSになるはずです） 2）値は常に1500と表示されます 私のローカルホストは、断片化が必要なメッセージを生成できるように、どこかにPMTUをキャッシュする必要があります。しかし、どのように私はそれを見ますか？ 私のマシンの例を次に示します（netstatの-nは、逆DNSルックアップを禁止します）。 [root@vbcentos ~]# ping -c 4 -M do -s 1431 212.58.244.69 PING 212.58.244.69 (212.58.244.69) 1431(1459) bytes of data. From 217.155.134.6 icmp_seq=1 Frag needed and DF set (mtu = 1458) From 217.155.134.4 icmp_seq=2 Frag needed and DF set (mtu = 1458) From …

13 networking  mtu 

より大きなイーサネットフレームの恩恵を受けるアプリケーションがあります。（理論的には、発信パケットの数を50％以上、おそらく66％減らすことができます。） また、アプリケーションサーバーの新規インストールのために、ホスティング会社候補とのネットワーク要件を指定している最中です。少なくとも、クライアント接続がジャンボフレームの恩恵を受けることを制限しないのが良いでしょう。 しかし、これはどれほど現実的ですか？制御できるネットワークのセグメントがジャンボフレームに適していると仮定した場合の一般的な質問（スイッチは大規模なMTUに対応、ICMP MTUパス検出など）： ジャンボフレームをパブリックインターネット経由で送信するのは現実的ですか？ 公共のインターネットを介してジャンボフレームをサポートしようとして、無限のネットワーク問題を招いていますか？ 私が考慮していない他の懸念はありますか？

13 networking  mtu  jumboframes 

KVMゲストとホストシステム間のストレージ通信用に9000バイトのMTUを実装しようとしています。ホストには、br19000バイトのMTUを持つブリッジ（）があります。 host# ip link show br1 8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff inet 172.16.64.1/24 brd 172.16.64.255 scope global br1 inet6 fe80::21b:21ff:fe0e:ee39/64 scope link valid_lft forever preferred_lft forever ゲストには、このブリッジに接続されたインターフェイスがあり、9000バイトのMTUもあります。 guest# ip addr show eth2 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen …

11 linux  networking  kvm-virtualization  bridge  mtu 

私は100 Mbpsの高速イーサネットを使用しています。そのフレームサイズは1500バイト未満です（私の教科書によると、ペイロード用に1472バイトです）。その中で、メッセージサイズ65507バイトのUDPパケットを送受信できました。つまり、パケットサイズは65507 + 20（IPヘッダー）+ 8（UDPヘッダー）= 65535でした。 フレームのペイロードサイズ自体が最大1472バイト（私の教科書によると）である場合、IPのパケットサイズを65535のサイズよりも大きくするにはどうすればよいですか。 私は送信者コードを次のように使用しました char buffer[100000]; for (int i = 1; i < 100000; i++) { int len = send (socket_id, buffer, i); printf("%d\n", len); } 受信者コードとして while (len = recv (socket_id, buffer, 100000)) { printf("%d\n". len); } 私はそれを観察しsend returns -1にi > 65507し、recv印刷物やのパケットを受信しますmaximum of length 65507。

11 tcpip  udp  network-protocols  mtu 

私は、domonを拡張するための冗長性とさまざまな論理ネットワークレイヤーを提供するために、インターフェースボンド、vlan、およびブリッジインターフェースの組み合わせを使用してきました。 この設定はうまく機能していますが、これらのインターフェースの異なる設定が相互にどのように影響するかについては、少し不確かです。説明のために、典型的なdom0でのセットアップを以下に示します。 /- vlan10 -- br10 eth0 -\ / > bond0 <--- vlan20 -- br20 eth1 -/ \ \- vlan30 -- br30 bond-、vlan-、およびbridge-interfacesは物理的ではなく論理的であると考えると、物理（eth0、eth1）インターフェイスに異なるMTUセットがある場合、これらのインターフェイスにMTUを設定しても効果がありますか？

9 linux  networking  vlan  bonding  mtu