限界点：データセンター間でのレイヤー2延伸
インフラチームは、仮想化クラスタを10台または15台のノード以上にスケーリングしようとすると、しばしば壁に突き当たります。異なるラック、あるいは離れたデータセンターにサーバーがあり、それらでフラットなネットワークを共有する必要がある場合、反射的な対応としてVLANを「延伸（ストレッチ）」してしまいがちです。これは小規模なラボ環境では機能しますが、本番環境では崩壊のリスクを孕んでいます。
クラスタが成長するにつれて、ネットワークは脆弱になります。たった一つのブロードキャストストームが、数秒でインフラ全体を麻痺させる可能性があります。20台のスイッチにわたってスパニングツリープロトコル（STP）の優先度を管理するのは、手動作業の悪夢です。さらに悪いことに、STPは通常、ループを防ぐためにリンクの半分をブロックします。結果として、4枚の100Gbpsアップリンクの料金を払いながら、実際には200Gbpsの容量しか使えず、残りはアイドル状態のままになります。ネットワークはアプリケーションをサポートすべきであり、デプロイ方法を制限すべきではありません。
従来のVLANが大規模環境で失敗する理由
現代の需要は802.1Q標準の限界を超えています。従来のレイヤー2ネットワーキングは「フラッド＆ラーン（転送と学習）」に依存しています。スイッチがMACアドレスの場所を知らない場合、そのパケットをすべてのポートにブロードキャストします。数千台の仮想マシンが存在するデータセンターでは、このオーバーヘッドは膨大になります。
4,096個というVLAN IDの制限も、もう一つの大きな壁です。マルチテナントのクラウドや大規模なラボを構築している場合、4,000個のIDは予想よりも早く使い果たされます。私たちは、1980年代に設計された12ビットの識別子を使って、21世紀のスケーリング問題を解決しようとしているのです。STPは数十年前には画期的な技術でしたが、今ではボトルネックとなっています。これは、現代のイコールコストマルチパス（ECMP）ルーティングを使用して、利用可能なすべてのファイバーにトラフィックをロードバランスすることを妨げています。
手動トンネルからBGP EVPNへ：最適なパスの選択
カプセル化は、これらの制限からの脱出口です。VXLAN（Virtual Extensible LAN）は、1,600万以上のユニークなVNIを提供することでID不足を解決します。しかし、本当の課題はトンネルの管理です。
- スタティックVXLAN: すべてのリモートVTEP（VXLAN Tunnel End Point）を手動でマッピングします。これは2台のサーバーなら問題ありませんが、50台のサーバーでは管理上の自殺行為です。
- マルチキャストVXLAN: ネットワークがマルチキャストグループを使用してフラッディングをシミュレートします。多くのエンジニアは、トラブルシューティングが非常に困難であり、多様なサブネット間でスケーリングすることが稀であるため、コアネットワークでの使用を避けます。
- BGP EVPN: これがプロフェッショナルの標準です。MACアドレスを発見するためにパケットをフラッディングさせる代わりに、ボーダーゲートウェイプロトコル（BGP）を使用して到達性情報を配布します。これにより、レイヤー2の問題が構造化されたルーティングの問題へと変換されます。ネットワークは、最初のパケットが送信元NICを離れる前に、すべてのデバイスがどこにあるかを正確に把握します。
最強の組み合わせ：FRRouting (FRR) と Open vSwitch (OVS)
Linuxはもはや単なるサーバーOSではありません。世界最大級のソフトウェア定義ネットワーク（SDN）を支える engine です。コントロールプレーンとしてのFRRoutingと、データプレーンとしてのOpen vSwitchを組み合わせることで、高価なプロプライエタリなハードウェアに匹敵する、ベンダーニュートラルなスタックを構築できます。
FRRは、BGPを介してMACアドレスの場所を学習することで「インテリジェンス」を提供します。OVSは重労働を担当します。トラフィックをVXLANトンネルにカプセル化し、ハードウェアに応じて10G、40G、または100Gのラインレートでパケットを移動させます。
1. Linux環境の準備
UbuntuやDebianのような最新のディストリビューションの多くは、標準リポジトリにこれらのツールを含んでいます。また、カーネルがVXLANと、ループバックアドレスに使用するダミーインターフェースに対応していることを確認する必要があります。
# Open vSwitchとFRRoutingのインストール
sudo apt update
sudo apt install openvswitch-switch frr frr-pythontools -y
# BGPデーモンの有効化
sudo sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr2. Open vSwitchによるデータプレーンの設定
仮想マシンをホストするためのブリッジと、ファブリックとリンクするためのVXLANポートが必要です。ループバックIP（この例では1.1.1.1）が、一意のVTEP識別子として機能します。
# OVSブリッジの作成
sudo ovs-vsctl add-br br-int
# VXLANポートの作成
# remote_ip=flowにより、FRRが動的にOVSへトラフィックの送信先を指示可能になります
sudo ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan options:remote_ip=flow options:key=100
# ブリッジを起動
sudo ip link set br-int up3. FRRoutingによるコントロールプレーンの設定
次に、BGP EVPNを介してMACアドレスを共有するようFRRに指示します。これにより、FRRがOVSブリッジを監視し、その内容をBGPネイバーに広報するように設定されます。
# FRRシェルに入る
sudo vtysh
# 設定ステップ
conf t
router bgp 65001
bgp router-id 1.1.1.1
neighbor 10.0.0.2 remote-as 65001
!
address-family l2vpn evpn
neighbor 10.0.0.2 activate
advertise-all-vni
exit-address-family
exit
write memory4. オーバーレイの検証
BGPセッションが安定すると、ホストはリモートのMACアドレスを自動的に学習します。トラフィックが発生するまで沈黙を守る従来のスイッチとは異なり、FRRは即座にBGPテーブルを埋めていきます。
# EVPN BGPルートの確認
show bgp l2vpn evpn route
# ブリッジで学習されたMACアドレスの確認
sudo ovs-appctl fdb/show br-int最後に
硬直したVLANをEVPN/VXLANアーキテクチャに置き換えることで、ネットワークに対する考え方が変わります。ループ検出に苦労するのをやめ、ルーティング効率の最適化に集中できるようになります。グローバルなインターネットを支えるのと同じプロトコルである BGP を使用することで、レガシーな環境では到底及ばない安定性と可視性を得ることができます。
このLinuxベースのアプローチは、計り知れない自由を提供します。特定のベンダーのCLIやライセンス料に縛られることはありません。ホワイトボックススイッチで実行している場合でも、ハイスペックなサーバーでも、テスト用のVMでも、現代的なソフトウェア定義データセンターの基盤を築いているのです。
