インターフェースモデルとアウトオブバンド管理

Customer Edge (CE) には、その名に値するようなローカル管理プレーンは存在しません。ブートストラップ設定と診断を除き、CE を管理するすべてのものは F5 Distributed Cloud コントロールプレーンから駆動され、ノードは1つの特定インターフェースを介してそのコントロールプレーンに到達します。この単一の事実がインターフェースモデル全体を決定しており、これを誤解することが、CE デプロイメントが単に故障するのではなくアーキテクチャ設計として間違ってしまう最も一般的な原因となります。

このページでは、「管理」という言葉を共有しながらも異なる構造である2つの概念を区別して説明します：

	概要
Site Local Outside (SLO)	CE が登録およびコールホーム（定期通信）に使用するインターフェース。すべての CE およびすべてのモードに存在します。登録後は変更不可（不変）です。一般的なケースでは、これが管理パスそのものとなります。
Management network	カーネルの独自 Virtual Routing and Forwarding (VRF) インスタンス内に本物のアウトオブバンド (OOB) インターフェースを追加する、より新しく狭義の Secure Mesh Site v2 (SMSv2) オプション。単一ノードサイト専用です。

Site Local Outside はたまたま最初にあるだけのデータインターフェースではありません

SLO は CE ノードを F5 Distributed Cloud の Regional Edges (REs) に接続し、登録、アップグレード、およびコントロールプレーン接続が実行されるパスです。また、データプレーン送信のデフォルトルートとして機能し、サイト間トンネルが終端する場所でもあります。プラットフォームが F5 への到達用にこれを予約しているため、アプリケーション網トラフィックを負荷させるのではなく、特別なものとして扱い、それを前提とした設計を行ってください。

これには2つの契約上の（単なるアドバイスではない）決定的な帰結が伴います：

SLO は F5 に到達できなければなりません。 到達可能性の要件は CE IP Address and Domain Reference に列挙されています。SLO インターフェースが F5 に到達できない CE は登録されず、登録されていないノードはコントロールプレーン経由で診断することもできません — 4つのアクセスパスを参照してください。
SLO はノードが登録およびデプロイされた後は不変（変更不可）です。 F5 は、CE Site がデプロイされた後、SLO インターフェースの Internet Protocol (IP) アドレスおよび Media Access Control (MAC) アドレスを変更できないと規定しています。SLO パラメータを変更するには、ノードの再デプロイが必要となります。

SLO は F5 への到達用に予約されておりデフォルトルートでもあるため、共有インターフェースから管理トラフィックを分離する適切な方法は、アプリケーション トラフィックを別の場所に配置することです。追加のインターフェースやセグメント上でバーチャルホスト、ロードバランサー、オリジンまたはサービスディスカバリを構成し、SLO はコントロールプレーン専用として残します。

現場での実践では、CE のブートストラップ完了後に構成される、SLO 以外の少なくとも2つのデータプレーンインターフェース（通常は Site Local Inside (SLI) に加えてもう1つ。プラットフォームがサポートしている場合は仮想ローカルエリアネットワーク (VLAN) サブインターフェース、または独立した仮想ネットワークインターフェースカード (NIC) として構成）が使用され、合計3つのインターフェースとなります。これらの追加インターフェースは SLI VRF を共有することも、独自のセグメントに配置することもできます。

セグメントは内部ネットワークに対する一般的な解法です

SLI はオプションです。F5 自体のガイダンスでは、代わりに Network Segments を検討することを推奨しています。これらは Console の Multi-Cloud Network Connect > Networking > Segments からアクセスできます。セグメントはインターフェースにアタッチできるグローバル VRF であり、ネットワークを1つの CE Site 内で分離して保持するか、あるいは複数のハイブリッドおよびマルチクラウド CE Sites にわたってそのネットワークを拡張します。これにより、「これらのサービスを独自の VRF に制限しなければならない」という要件がある場合、セグメントが最適な手段となります。

Secure Mesh Site v2 管理ネットワーク

これは SMSv2 サイトオブジェクトの Management Network メニューによって有効化される構造であり、単に名前を付け替えた SLO ではなく、本物の OOB インターフェースです。有効にすると、F5 は SLO でも SLI でもない独立したネットワークインターフェースを作成し、データプレーントラフィックから完全分離するために独自のカーネル VRF 内で動作させます。アウトオブバンドであるため、CE ノードのフォワーディングプレーンには一切関与しません。想定される用途は、サービスの OOB 管理（Secure Shell (SSH) およびローカル Web ユーザーインターフェース）およびトラブルシューティング（Site CLI コマンドの実行および syslog ファイルの外部出力）です。

これが利用可能かどうかは、3つの制約によって決まります：

制約	値
ノード数	単一ノード CE Sites 限定。マルチノード CE Site（クラスタ）ではサポートされません。
ソフトウェアバージョン	`crt-20251001-0189` 以降。ノードソフトウェアリリースノートを参照してください。
デフォルト	有効になっていません。

これを有効にするとインターフェースの順序付けも固定され、ノード上でそれに関する誤った想定が表に現れることになります：

管理ネットワークインターフェース
Site Local Outside (SLO) インターフェース
追加のすべてのインターフェース（Site Local Inside (SLI) インターフェースの一部となります）

High Availability が無効の場合は CE Site がちょうど1つのノードをサポートすることを意味し、有効の場合は3つのノードを必要とすることを意味します。このオプションは CE Site オブジェクトが作成およびデプロイされた後に変更することはできず、ノードの追加は有効になっている場合にのみ可能です。

したがって、管理ネットワークと3ノードクラスタは構造上相互排他的であり、このペアのどちら側も実行時に変更できる決定ではありません。高可用性が有効で作成されたサイトは、メニューを切り替えるだけで後から管理ネットワークを取得することはできません — 新しいサイトオブジェクトと再デプロイが必要になります。

ネットワークインターフェースを追加するとデータプレーンサービスが再起動するため、トラフィックのドロップやトンネルのダウンが発生することが予想されます。インターフェースを追加または変更する前に、各ノード仮想マシン (VM) の電源をオフにしてください。

クラスタでは、すべて のノードにインターフェースを追加し、それぞれで同じ VRF に配置してください。1つの CE Site 内でノード間のインターフェース構成が不均一であると問題が発生するため、特定のサイト内のすべてのノードは、同じ VRF 内で同じ数のインターフェースを保持する必要があります。

このデプロイメントへのマッピング

ここでの各 CE は3つの Azure NIC を備えており、最初の NIC は terraform/modules/ce-node/main.tf 内で mgmt という名前が付けられています。その名前は、それが存在する Azure サブネットを表しています。これは XC 管理ネットワークが構成されていることを意味するものではなく、本文中のいかなるページもそのように解釈されるべきではありません。

terraform/modules/xc-site/main.tf は、サイトオブジェクト上にちょうど1つのインターフェースを宣言しています：

interface_list {
  name = "eth0"

  ethernet_interface {
    device = "eth0"
    mac    = var.mgmt_nic_mac
  }

  # Site Local Outside (SLO) — required on every site; BGP peers from here.
  network_option {
    site_local_network {}
  }

  dhcp_client {}
}

site_local_network {} は SLO です。したがって：

このデプロイメントでの設定	実際の役割
`mgmt` NIC (`eth0`, VM の最初の NIC)	SLO インターフェース。登録およびコントロールプレーントラフィックを F5 に運び、Azure Route Server がピアリングを行う Border Gateway Protocol (BGP) ローカルアドレスとなります。
`external` NIC	データプレーンインターフェース。
`internal` NIC	SLI インターフェース。
管理ネットワーク	未構成。サイトオブジェクト上に `enable_management_network` フラグは設定されていません。

各サイトは単一ノード（disable_ha {}、アベイラビリティゾーンごとに1サイト）であるため、3ノードクラスタとは異なり、ここでは管理ネットワークが許可されます。単に有効化されていないだけであり、有効化すると上記の順序に従ってインターフェース番号が振り直され、BGP ピアバインディングが依存している構成に影響を与えます。

よくある質問

独自の IP 設定と VLAN 割り当てを持つ独立したアウトオブバンド管理インターフェースを定義するにはどうすればよいですか？

単一ノード CE Site では、ソフトウェア crt-20251001-0189 以降で SMSv2 サイトオブジェクトの Management Network オプションを有効にします。F5 はフォワーディングプレーンの外部にある独自のカーネル VRF 内に独立したインターフェースを作成します。

マルチノード（3ノード）CE Site では、これを実行するためのサポートされた方法は存在しません。 管理ネットワークはクラスタに対して明示的にサポートされていません。クラスタの場合、SLO を管理パスとして扱い（これが F5 Global Controller に到達し、その用途のために予約されているため）、それ以外のすべての通信には SLI VRF または独自のセグメントに追加のデータプレーンインターフェースを追加してください。

インターフェースごとの IP 設定は、インターフェース定義時にサイトオブジェクト上で設定されます。VLAN サブインターフェースを特に管理ネットワークに割り当てられるかどうかは、本稿執筆時点で F5 によっていずれの方向にも伝 aromatic ドキュメント化されていません。現場での経験ではサポートされていないことが示唆されており、信頼性の高い構成は管理 VLAN に属するポートグループ内の専用インターフェースです。これを前提とした設計を行う前に F5 に確認してください。

3ノードサイトで Management Network を有効にしましたが、ノードは SLO のみで起動しました。なぜですか？

このオプションがマルチノード CE Site でサポートされていないためです。サイトオブジェクトは設定を受け入れますが、クラスタは追加インターフェースを取得しないため、表示される外部インターフェースは正常に動作している SLO インターフェースとなります。これはサポート対象構成の制限であり、プロビジョニングの不具合ではありません。また、そのサイトオブジェクト上で修正することは不可能です：High Availability 設定は作成後に変更できません。

サイトのデプロイ後に管理を SLO から移動することはできますか？

いいえ、SLO を再構成することによって移動することはできません。SLO の IP アドレスおよび MAC アドレスは、ノードの登録およびデプロイ後に変更することはできません。可能なのは、バーチャルホスト、ロードバランサー、およびオリジンディスカバリを他のインターフェースやセグメントに配置することによって、データプレーン を SLO から移動させることです。

インターフェースはどのような順序で割り当てられますか？

管理ネットワークが有効な場合：管理が最初、次に SLO、その後に SLI としての追加インターフェース。無効な場合：SLO が最初、次に SLI としての追加インターフェース。初回電源投入前にインターフェースを接続してゲストプロパティが設定されるようにし、後からインターフェースを追加または変更する場合はノードの電源をオフにしてください。

CE にはいくつのインターフェースが必要ですか？

プラットフォームが要求する最小限は1つの SLO インターフェースです。管理トラフィックがアプリケーション通信とインターフェースを共有してはならない場合は、3つを計画してください：コントロールプレーン用の SLO、および少なくとも2つのデータプレーンインターフェース。このデプロイメントはその構成（SLO、external、internal）を使用しています。