深夜2時、Zabbix監視システムから赤色のアラートが一斉に発報されました。カーネルパッチ適用後、Proxmoxノード上の16台のVMクラスタで接続断が発生したのです。コンソールを開いてdmesgを確認すると、VLANトランキングのトラフィックが4Gbpsを超えたあたりからLinux Bridgeがパケットをドロップし続けていました。LACP bondペアもリンクが不安定になり切断を繰り返しています。このボトルネックを根本から解消するには、仮想ネットワークインフラ全体をOpen vSwitch（OVS）へ移行するのが最も確実でスマートな解決策です。
私のホームラボ環境では、負荷テスト用に2台のProxmox VEノード上で12台のVMおよびコンテナを並行稼働させています。本記事で紹介する復旧シナリオはすべて、本番環境へ適用する前に実際のトラブルシューティングを通じて検証を重ねたノウハウに基づいています。
Quick start：5分で完了する緊急OVS Bridge構築
仮想スイッチで障害が発生している際は、Web GUI上で操作している余裕はありません。iLO/IPMIコンソールを開くか、Proxmoxノードへ直接SSH接続してOVSパッケージをインストールしましょう。
apt-get update
apt-get install -y openvswitch-switch
systemctl enable --now openvswitch-switch
OVSデーモンが起動していることを確認します。
ovs-vsctl show
仮想スイッチvmbr1を即座に作成し、物理ポートeth0をブリッジに割り当てます。このコマンドはホストを再起動することなく即座に反映されます。
ovs-vsctl add-br vmbr1
ovs-vsctl add-port vmbr1 eth0
再起動後も設定を維持するために、/etc/network/interfacesへ以下の定義を追加します。
auto vmbr1
iface vmbr1 inet manual
ovs_type OVSBridge
ovs_ports eth0
ovs_extra set bridge vmbr1 stp_enable=true
iface eth0 inet manual
ovs_type OVSPort
ovs_bridge vmbr1
ifupdown2ツールを使用してネットワーク設定をリロードします。
ifreload -a
これで作業は完了です。VMのネットワークインターフェースをvmbr1に変更するだけで、通信が正常に復旧します。
技術的本質：Linux Bridge vs Open vSwitch
従来のLinux Bridgeは、システム規模が拡大するにつれて性能の限界に直面しがちです。その理由は何でしょうか。
1. パケットフローの処理メカニズム
Linux Bridgeは、Linuxカーネル内部で動作するL2アンマネージドスイッチのように振る舞います。シンプルかつ軽量で、基本的な用途には十分です。しかし、OpenFlowや動的フロー制御には対応していません。複数のVLANタグが混在した状態でトラフィックが5〜7Gbpsを超えると、カーネルのCPU softirq（ソフトウェア割り込み）が急増し、大規模なパケットドロップが発生します。
対照的に、Open vSwitchは本格的なSDNスイッチとして機能します。OVSは専用のキャッシュテーブルを用いてカーネルのdatapath上で直接フローを処理します。これにより、トラフィック監視のために多数のQoSルール、NetFlow、またはsFlowを適用した場合でも、安定したスループットを維持できます。
2. ポート管理とVLANフィルタリング
Linux Bridgeでは、通常VLANごとにeth0.10やeth0.20といった個別のサブインターフェースが必要になります。この構成は数十台のVMを管理する際に非常に煩雑です。一方、OVS Bridgeは物理・仮想（tap/veth）を問わず、すべてのインターフェースを単一のOVS Portとして統合管理します。VLANフィルタリング機能も標準で有効化されています。トランキングやVMへのVLAN 20タグ割り当てを行いたい場合でも、ホスト側のインターフェース設定に手を加えることなく、Proxmox上でタグパラメータを1つ指定するだけで完結します。
実践・応用編：OVS Bond（LACP）とノード間GRE Tunnelの構築
LANケーブルが1本切れただけでサービスがダウンすることは許されません。OVS BondとGRE Tunnelを組み合わせることで、冗長化とサブネットをまたいだ相互接続の両方の課題を解決できます。
1. OVS Bond（LACP）による10Gbps NICのチーミング
サーバーにToR（Top of Rack）スイッチへ接続された2つの10GbEポート（enp3s0f0およびenp3s0f1）があると仮定します。これらをIEEE 802.3ad規格に準拠したbond0として束ねます。
/etc/network/interfacesの設定は以下の通りです。
auto bond0
iface bond0 inet manual
ovs_bridge vmbr0
ovs_type OVSBond
ovs_bonds enp3s0f0 enp3s0f1
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
auto vmbr0
iface vmbr0 inet static
address 192.168.1.50/24
gateway 192.168.1.1
ovs_type OVSBridge
ovs_ports bond0
ifreload -aを実行した後、LACPのネゴシエーション状態を確認します。
ovs-appctl bond/show bond0
ovs-appctl lacp/show bond0
出力にactor state: negotiatedおよびpartner state: negotiatedと表示されていれば、2つの物理ポートとスイッチとの間で正常にハンドシェイクが完了しています。
2. 異なるIPセグメントにある2ノード間のVMを繋ぐGRE Tunnelの構築
実際のシナリオ：Node AのIPが10.10.1.10、Node BのIPが10.10.2.10で、両者がL3ルーターを挟んで配置されているとします。ネットワーク担当者にVXLANの設定や物理VLANの延伸を依頼できない状況で、両ノード上のVM間をL2レイヤーで直接通信（同一サブネット172.16.100.0/24）させる必要があります。
OVSのGRE Tunnelを使用すれば、わずか2行のコマンドでこの問題を解決できます。
Node A（10.10.1.10）での設定：
ovs-vsctl add-br vmbr-internal
ovs-vsctl add-port vmbr-internal gre0 -- set interface gre0 type=gre options:remote_ip=10.10.2.10
Node B（10.10.2.10）での設定：
ovs-vsctl add-br vmbr-internal
ovs-vsctl add-port vmbr-internal gre0 -- set interface gre0 type=gre options:remote_ip=10.10.1.10
その後、VMのネットワークインターフェースをブリッジvmbr-internalに割り当てます。これで、2つのノードにある仮想マシン同士が同一の物理スイッチに接続されているかのように、正常にping疎通できるようになります。
OVS運用における実践的なTips
- ネットワークの安易な再起動を避ける： SSH経由で
systemctl restart networkingを実行するのは絶対に避けてください。設定ファイルに構文エラーがあった場合、即座にセッションが切断され締め出されます。代わりにifupdown2パッケージのifreload -aを使用しましょう。構文エラーがあっても処理を安全に中断し、詳細なエラーを出力してくれます。 - GRE TunnelにおけるMTUの落とし穴： GREヘッダーによって24バイト（IPv4 20バイト ＋ GRE 4バイト）のオーバーヘッドが発生します。物理NICのMTUが1500のままだと、VMからの1500バイトのパケットがフラグメンテーション（断片化）を起こします。その結果、iperf3の計測値が9.4Gbpsから1.5Gbps未満にまで急落することがあります。対処法としては、VM内のNIC MTUを1476（または1450）に下げるか、ホストの物理NICのMTUを1600（ジャンボフレーム）に引き上げます。
- Flow Dumpを用いたパケットデバッグ： VMがDHCPからIPアドレスを取得できない場合は、以下のコマンドでパケットがブリッジを通過しているか確認します。
ovs-dpctl dump-flows vmbr1
# または詳細なOpenFlowルールを確認:
ovs-ofctl dump-flows vmbr1
OVS Bridge、Bond、GRE Tunnelを使いこなすことで、Proxmox VE上のトラフィックを自在に制御できるようになり、外部のハードウェア構成に過度に依存することなくネットワーク障害へ迅速に対処できるようになります。
