【実務・中級編】 マルチchリンクアグリゲーション(MLAG / vPC / VSS)の高可用性設計 – インフラ・物理&L2/L3ネットワーク基礎実践ガイド

ネットワークの「神聖な二重化」:MLAG/vPCでスパニングツリーの悪夢を終わらせる

ネットワークエンジニアにとって、スパニングツリー(STP)は「必要悪」です。ループを防ぐためには不可欠ですが、貴重な帯域をブロッキングして眠らせ、コンバージェンス(収束)のたびにネットワーク全体を数秒間フリーズさせるあの挙動……正直、もう飽き飽きしていませんか?

今回は、そんな「STPの呪縛」から解放され、物理的に離れたスイッチを論理的に1台として振る舞わせる「マルチchリンクアグリゲーション(MLAG/vPC/VSS)」について、現場の知見を交えて深掘りします。

—

1. なぜ「MLAG」が必要なのか?

通常、LACP(IEEE 802.3ad/802.1AX)は1台のスイッチ内でのみ完結する技術です。これを異なる2台の物理スイッチにまたがって構成しようとすると、スイッチ間でMACアドレス学習の同期やLACPの状態共有が必要になります。

ここで登場するのが、ベンダー各社が呼称を変えつつ実装しているMLAG(Multi-chassis Link Aggregation)系技術です。

  • Cisco: vPC (Virtual Port Channel)
  • Arista/Juniper: MLAG
  • Catalyst (旧VSS/StackWise Virtual): SVL (StackWise Virtual)

これらは、コントロールプレーンを独立させつつ、データプレーンを共通化することで、「対向デバイスからは1台に見える」という魔法を実現します。

2. 通信の肝:Peer-LinkとKeepaliveの役割

MLAGを構築する上で最も重要なのが、スイッチ間を結ぶ Peer-Link と、死活監視を行う Peer-Keepalive です。

  • Peer-Link: MACアドレステーブルやARPテーブル、IGMPグループなどを同期する「生命線」。ここがダウンすると、スプリットブレインを防ぐために片系が自律的にポートをシャットダウンします。
  • Peer-Keepalive: 制御プレーンの死活監視。Peer-Linkを通さず、別経路(Mgmtポート等)でやり取りするのが鉄則です。

設定例:Cisco vPCの場合

現場でよく見るvPCのベース設定の骨子です。

! 1. ドメインの作成
vpc domain 100
  peer-keepalive destination 192.168.1.2 source 192.168.1.1  ! Keepalive用IP
  peer-gateway                                             ! 相手のMAC宛パケットも処理させる
  auto-recovery                                            ! 再起動時の自動復旧

! 2. Peer-Linkの設定(L2トランクである必要がある)
interface port-channel 10
  switchport mode trunk
  vpc peer-link

! 3. サーバー接続用ポートの設定
interface Ethernet1/1
  channel-group 20 mode active
interface port-channel 20
  switchport mode trunk
  vpc 20  ! vPC IDは両機で同じにすること

3. Webエンジニアが知るべき「トラフィックの挙動」

APIのレスポンスが遅延する、あるいは特定のノードだけ通信が不安定になる……そんな時、MLAGの「ハッシュアルゴリズム」が原因であることが多々あります。

MLAG環境では、スイッチは送信元・宛先のIPやMAC、ポート番号を基にパケットを振り分けます。もし、特定のサーバーから特定のAPIへ大量のトラフィックが流れている場合、ハッシュ値が偏り、片方の物理リンクだけが飽和する「偏り」が発生します。

Pythonでハッシュバランスをシミュレーションするヒント

APIクライアント側のリクエストがどう分散されるか、簡易的なハッシュ計算をPythonで再現してみると、運用の勘所が掴めます。

import hashlib

def get_link_index(src_ip, dst_ip, num_links=2):
    # シンプルなハッシュによるリンク選択のイメージ
    hash_val = int(hashlib.md5(f"{src_ip}{dst_ip}".encode()).hexdigest(), 16)
    return hash_val % num_links

# テスト: 異なる送信元IPからのトラフィックを分散させる
ips = ["10.0.0.1", "10.0.0.2", "10.0.0.3"]
for ip in ips:
    link = get_link_index(ip, "192.168.10.50")
    print(f"Source IP {ip} -> Link {link} を使用")

4. 現場で泣かないためのトラブルシューティングTips

MLAG構築において、私が必ず確認する「3つの鉄則」を伝授します。

1. VLANの不一致を許さない:
Peer-Link で許可されているVLANと、各 vPC ポートで許可されているVLANがズレていると、通信がブラックホール化します。show vpc consistency-parameters global を叩いて常に確認してください。
2. STPのプライオリティ:
vPCの Peer-Gateway 設定を入れている場合でも、STPのルートブリッジはvPCペアのどちらかに固定してください。あやふやにすると、予期せぬトポロジ変更でパケットロスが走ります。
3. MTUの不一致:
Peer-Link はMTUサイズが一致していないと、一部のフレームがドロップし、MACアドレスの同期が不完全になります。ジャンボフレームを扱うなら、全経路でMTU確認は必須です。

まとめ:ネットワークは「見えない関係性」をデザインすること

MLAGは、物理的な制約を論理的な柔軟性で解決する、現代ネットワーク設計の極致です。しかし、その裏側にある「状態同期」の複雑さを理解していないと、いざという時のデバッグで路頭に迷うことになります。

パケットは嘘をつきません。show コマンドで表示される統計情報や、tcpdump で取得したヘッダー情報と常に向き合い、論理構成図と実際の物理配線が一致しているかを常に疑う姿勢こそが、真のネットワークスペシャリストへの道です。

さあ、皆さんの環境でも show vpc を叩いて、美しいアクティブ・アクティブ環境が正しく同期されているか、確認するところから始めてみてください。

コメント

タイトルとURLをコピーしました