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

発生事象
ProxmoxでUbuntuサーバーを構築し、VLAN awareを有効にした仮想ブリッジを物理NICに紐付け、手元のM1 MacからVLANタグを付与して接続を試みていた。
その結果、M1 MacからUbuntuへpingは通るものの、sshやcurlを実行すると接続がタイムアウトし、レスポンスが返ってこないという現象が発生した。
(ネットワーク周りは疎いため、Geminiに相談・教えを乞いながらトラブルシューティングを行なっていた。そのログを残していく)

原因切り分けのための調査・整理
pingやcurlなどを試しながら状況整理を行なった。
手元のIntel Macでは通信がうまくいっていたため、被疑箇所はM1 Mac側であると特定。(LANケーブルやUSB-Cへの変換アダプタも入れ替えて試したが同じ結果だった)
また、VLANを有効にしない場合にはM1 Mac→Ubuntuのssh/curlができていた

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

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

根本原因?
以下のプロンプトでGemini Deep Researchに調査を依頼
m1 macで、vlanを使用するとingressパケットがロストするようなバグは報告されているか
「2.1. macOS VenturaにおけるVLANタグ除去バグ」が最も今回の事象に近く、https://www.reddit.com/r/mac/comments/yos2sw/virtual_vlan_tagged_interfaces_broken_in_ventura/ でも似た事象が報告されている(今回の場合DHCPはうまくいっていたが)

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

結論: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>