Closed7

M1 MacでVLAN固有のイングレスパケットロスが発生する

wa__wawa__wa

発生事象

ProxmoxでUbuntuサーバーを構築し、VLAN awareを有効にした仮想ブリッジを物理NICに紐付け、手元のM1 MacからVLANタグを付与して接続を試みていた。

その結果、M1 MacからUbuntuへpingは通るものの、sshやcurlを実行すると接続がタイムアウトし、レスポンスが返ってこないという現象が発生した。

(ネットワーク周りは疎いため、Geminiに相談・教えを乞いながらトラブルシューティングを行なっていた。そのログを残していく)

wa__wawa__wa

原因切り分けのための調査・整理

pingやcurlなどを試しながら状況整理を行なった。
手元のIntel Macでは通信がうまくいっていたため、被疑箇所はM1 Mac側であると特定。(LANケーブルやUSB-Cへの変換アダプタも入れ替えて試したが同じ結果だった)

また、VLANを有効にしない場合にはM1 Mac→Ubuntuのssh/curlができていた

wa__wawa__wa

Pingが通らないのは別の理由

UbuntuからM1 Macへpingが通らない原因は、Firewallが原因だった。Firewallをオフにしたらpingは通るようになった

wa__wawa__wa

Wireshark / tcpdumpでパケットを見てみる

M1 Mac→Ubuntuにcurlを投げながらパケットを見てみる。

  • M1 Macでは、TCPハンドシェイクは成功しており、その後のやり取りで止まってしまっているように見える
  • Ubuntu側では、TCP Retransmissionのパケットがいくつも出ていた
  • 再度M1 Macで物理NICのパケットを見てみると、VLANタグがついたパケットを受け取れているがVLANではそれを受け取れていない、パケットロスが発生していることが判明

wa__wawa__wa

根本原因?

以下のプロンプトでGemini Deep Researchに調査を依頼

m1 macで、vlanを使用するとingressパケットがロストするようなバグは報告されているか

https://g.co/gemini/share/c45e59f07fd3

「2.1. macOS VenturaにおけるVLANタグ除去バグ」が最も今回の事象に近く、https://www.reddit.com/r/mac/comments/yos2sw/virtual_vlan_tagged_interfaces_broken_in_ventura/ でも似た事象が報告されている(今回の場合DHCPはうまくいっていたが)

wa__wawa__wa

試したこと

以下を試したが効果なし

  • USB-C to Ethernetアダプターの交換(大したものがなかったので、Ankerのハブを使用)
  • MacOS 26へのアップデート
  • MTUを1496に変更→問題解消!!!!
wa__wawa__wa

結論:MTUの設定でVLANタグの「4バイト」を確保する

以下、Geminiにまとめてもらった

<blockquote>

この問題の核心は、VLAN通信で付与されるVLANタグの存在です。MTUを1496に設定するのは、このVLANタグが使用する4バイトの領域をデータペイロードからあらかじめ確保し、全体のフレームサイズを標準規格内に収めるためです。

MTUとVLANタグの関係

  • MTU (Maximum Transmission Unit)
    一度に送信できるデータペイロード(本体のデータ部分)の最大サイズを指します。一般的なイーサネット環境では、この値は1500バイトに設定されています。

  • VLANタグ (IEEE 802.1Q)
    VLANを識別するために、イーサネットフレームに挿入される4バイトの識別子です。どのVLANに所属するパケットかをネットワーク機器が判断するために利用されます。

なぜパケットロスが起きるのか

通信を行う際、OSはMTUの上限である1500バイトのデータペイロードを生成します。VLAN通信では、このデータに加えて4バイトのVLANタグがフレームに挿入されます。

データペイロード (1500バイト) + VLANタグ (4バイト) = 1504バイト

結果として生成された1504バイトのフレームは、標準的なイーサネットの規格(1500バイト)を超過してしまいます。この規格外のフレームを受信したスイッチやルーターなどのネットワーク機器は、それをエラーとして扱い、**フレームを破棄(ドロップ)**します。これが、パケットロスの直接的な原因です。

「1496」で解決するメカニズム

そこで、送信側デバイスのMTUをあらかじめ1496バイトに設定します。これにより、OSが生成するデータペイロードの最大長が1496バイトに制限されます。

データペイロード (1496バイト) + VLANタグ (4バイト) = 1500バイト

VLANタグが付与されても、フレームの合計サイズが標準規格である1500バイトに収まるため、ネットワーク機器はこれを正常なフレームとして処理できます。結果として、パケットロスが解消され、安定した通信が実現します。

</blockquote>

このスクラップは2日前にクローズされました