モバイル クラウド ネットワーク（MCN）はネットワーク インフラストラクチャであり、VPC-SI とその他のサービスが展開される Infrastructure as a Service（IaaS）、オーケストレーション メカニズム、分析メカニズムなどが備わっています。

次の図に、VPC-SI でサポートされている基本的な L2/L3 の相互接続を示します。

上の図では、仮想スイッチはハイパーバイザ内に組み込まれ、データセンター全体の SDN L2 機能をサポートしています。仮想スイッチは 802.1Q トランク（VLAN）を使用して他の仮想スイッチと相互接続します。通常、仮想スイッチは動的にロードされたカーネルモジュールです。

VPC-SI は基本的に、COTS プラットフォーム上の仮想マシン（VM）内で実行されている StarOS です。これは、企業内、リモートサイト内、または顧客のデータセンター内のスタンドアロンの単一 VM として使用できます。また、VPC-SI を大規模なサービス プロバイダー オーケストレーション ソリューションの一部として統合することもできます。

シングル インスタンス アーキテクチャは、キャパシティの低いシナリオに適しています。VPC-SI 仮想ネットワーク機能（VNF）を拡張するには、特定の VNF タイプ（P-GW、S-GW、MME、PCRF、ファイアウォール、NAT など）に対してネットワークレベルを大幅に設定する必要があります。たとえば、新しい VPC-SI P-GW が追加または削除された場合、この情報を使用してさまざまな Diameter ピアを設定する必要があります。この情報によって DNS がプロビジョニングされるか、またはプロビジョニングが解除されます。

VPC-SI は、サポートされているハイパーバイザ KVM（カーネルベースの仮想マシン）と VMware ESXi とのみ連携します。物理的なデバイスの知識はほとんどないか、まったくありません。

通常、VPC-SI はハードウェアまたはハイパーバイザの障害が発生した場合に物理的な冗長性を提供するために、シャーシ間セッションリカバリ（ ICSR）ペアに導入する必要があります。

各 VPC-SI VM が StarOS システム全体のロールを担います。VM の外部で公開されている唯一のインターフェイスは、外部管理およびサービストラフィックのインターフェイスです。各 VM は個別に管理されます。

各 VPC-SI VM は次の StarOS 機能を実行します。

• コントローラのタスク
• CLI とロギング用のアウトオブバンド管理（vSerial と vKVM）
• ローカルコンテキスト vpnmgr
• ローカルコンテキスト管理（vNIC）
• vHDD のシステム起動イメージと設定ストレージ
• vHDD のレコードストレージ
• fastpath と slowpath を介した NPU シミュレーション
• 非ローカルコンテキスト（vNIC、1 ~ 12）。
• セッション処理の逆多重化と vpnmgr
• 暗号処理

VM は単一の CPU サブシステムを備えた仮想カードとして表されます。これにより、多くの CLI コマンド、ログ、および機能は、ASR 5500 プラットフォームで実行されている StarOS と同様に動作します。

StarOS 用に作成されたアプリケーションは、単一の仮想カードをサポートする 1 スロットの仮想シャーシを備えた別のプラットフォームとして VPC-SI を見なします。

コンテキスト、サービス、プール、インターフェイス、カード、およびポートの StarOS の概念は既存のプラットフォームの場合と同様に VPC-SI に存在します。

VM が起動すると、VM プロファイル内に設定された vNIC が検出され、「仮想イーサネット」タイプのポートに相当する数が StarOS CLI に表示されます。

（注）	ハイパーバイザの CLI や GUI にリストされている vNIC の順序が、ハイパーバイザが VPC-SI に提供する方法と同じであることは保証できません。初期設定では、show hardware CLI コマンドを使用して、ハイパーバイザの vNIC 設定に表示されている MAC アドレスを調べ、VPC-SI によって学習された MAC アドレスと一致させる必要があります。これにより、VPC-SI が目的の BR グループまたは vSwitch に接続されていることが確認されます。

VPC-SI インスタンス内の VM は、ソフトウェアベースの暗号化とパケットのトンネリングを実行します（高いスループットのハードウェアベースのサービスとは異なります）。ベアラーパケットの暗号化を多用するコールモデル、または重要な PKI（公開キーインフラストラクチャ）のキー生成レートを持つコールモデルでは、重要なコンピューティング リソースが必要になる場合があります。

外部トラフィックのセキュリティは、トンネリング、暗号化、Access Control List（ACL; アクセスコントロールリスト）、コンテキストの分離、およびユーザ認証機能など、既存の StarOS プラットフォームと同様の機能を備えています。CF および SF 上のユーザポートおよびインターフェイスは、StarOS の CLI 設定によって保護されます。

仮想システムでは、データセンター機器の DI ネットワークを介してネットワーク通信が行われるため、お客様側にさらにセキュリティ上の懸念が生じます。

DI ネットワークは、システムネットワークの VLAN のメンバーシップをその特定の VPC-SI インスタンス内の VM に制限することによって、データセンター内の他のホストから分離する必要があります。ネットワークに誤って追加された他のホストによる DI ネットワークへの不正アクセス、またはルータ、スイッチ、またはハイパーバイザの侵害によって、StarOS のセキュリティ対策が中断または回避される可能性があります。このような中断により、障害、サービスの損失や、制御とベアラーパケットの検出が発生する可能性があります。DI ネットワークへのアクセスを適切に保護することは、StarOS の制御の範囲を超えています。

DI ネットワークコンポーネント（CF および SF など）の VM 間の通信は、外部から提供された SSH キーによる認証によってのみ可能になりました。さらに、システムは、DI ネットワーク内のログインに公開/秘密キーベースの SSH 認証を適用します。パスワード、キー、または LI 情報は保存されず、クリアテキストで送信されます。

オペレータが、管理およびベアラーの LI （合法的傍受）などネットワークを物理的に分離する必要がある場合は、センシティブデータを伝送するため、DI ネットワークの物理的な分離も実行する必要があります。仮想環境では、ネットワークの物理的な分離は不可能な場合、または実用的でない場合があります。これらの要件を持つオペレータは、必要に応じて十分な保護を提供することを確認するために、ハイパーバイザとインフラストラクチャを調査する必要があります。

仮想システムは、システム冗長性と可用性全体の基盤となるハードウェアとハイパーバイザに依存しています。

ハードウェアとハイパーバイザには、次が備わっている必要があります。

• 実際の冗長ハードウェアコンポーネント（電源、ディスクなど）

• 冗長ネットワークパス（デュアルファブリック/NIC、自動フェールオーバー搭載）

• 冗長ネットワークアップリンク（スイッチ、ルータなど）

基盤となるインフラストラクチャ（ホスト、ハイパーバイザ、およびネットワーク）に期待値を超える可用性と信頼性が備わっている場合にのみ、高可用性を実現できます。システムは、実行されている環境と同じ信頼性のみを備えています。

シャーシ間セッションリカバリ（ICSR）は、冗長ではないハードウェア（CPU、メモリ、マザーボード、ハイパーバイザソフトウェアなど）に障害が発生した場合に、可用性を高め、リカバリ時間を短縮するためにも推奨されます。ICSR は、ゲートウェイのセッションレベルでのみ冗長性を提供します。

VPC-SI は、StarOS ソフトウェアリリースで ICSR をサポートするサービスの 2 つのインスタンス間で ICSR をサポートします。複数のサービスタイプが使用されている場合は、ICSR をサポートするサービスのみが ICSR を使用できます。

ICSR は、サイト/行/ラック/ホストの停止や主要なソフトウェア障害の冗長性をサポートしています。これを行うには、重複しないホストとネットワークインターコネクト上で 2 つのインスタンスを実行する必要があります。ICSR は、同様に設定されたインスタンス間でのみサポートされます。VPC-SIインスタンスと別のタイプのプラットフォーム（ASR 5500 など）間の ICSR はサポートされていません。

L3 ICSR がサポートされています。

詳細については、このガイドの「シャーシ間セッションリカバリ」の章を参照してください。

VPC-SI では、VM が次のように設定されている必要があります。

• X vCPU（vCPU と vRAM のオプション を参照）

• Y vRAM（vCPU と vRAM のオプション を参照）

• 最初の vNIC は管理ポート（vNIC のオプション を参照）

• 2 番目以降の vNIC はサービスポートです。1 つの vNIC を必要とし、最大 12 個が VPC でサポートされますが、この数はハイパーバイザによって制限される場合があります。

• 最初の vHDD はブートイメージと設定ストレージ用です（4 GB を推奨）。

• 2 番目の vHDD はレコードストレージ用です（オプション）（16 GB 以上）

CPU は、システム全体とアプリケーションを単独で完全に実行でき、複数の物理 CPU コアの搭載が可能な 1 つの物理コンピュータチップです。仮想コアテクノロジーは、物理コアごとに複数の論理プロセッサ（vCPU）をサポートします。特定のプラットフォーム上でサポートされている vCPU の合計数は、使用可能な物理コアの数と、各コアに実装されている仮想コアテクノロジーのタイプによって異なります。

CF と SF は、多数の vCPU が割り当てられ、それぞれが 1 つのスレッド（命令のシーケンス）VM 内で実行します。プラットフォーム CPU でサポートされている使用可能な vCPU の数がハイパーバイザを介して VM に割り当てることができる vCPU の最大数を超える場合があります。

（注）	VM あたりの vCPU の数は、プラットフォーム CPU でサポートされている vCPU の最大数を超えてはなりません。

パフォーマンスを最大化するには、基盤となるハードウェアに合わせて、vCPU または vRAM の数を調整することが望ましい場合があります。SF は vCPU と vRAM のさまざまな組み合わせをサポートしますが、すべての SF がインスタンス内で同じ組み合わせを共有する必要があります。

ソフトウェアは、vCPU の数とその SF の vRAM の量に基づいて、SF の起動時に SF ごとに最適な SESSMGR タスクの数を決定します。

このリリースでは、次のような vNIC オプションがサポートされています。

• VMXNET3：VMware 用の準仮想 NIC

• VIRTIO：KMV 用の準仮想 NIC

• ixgbe：Intel 10 ギガビット NIC 仮想機能

• enic：Cisco UCS NIC

必須/フラッシュ（非 RAID）ドライブに追加した場合、システムは仮想マシン（VM）の下で RAID1 をサポートします。VM ごとに、この表に示す SCSI ID と一致する仮想 SCSI ディスクを CF のみで作成できます。最小ディスクサイズは 16 GB を超えている必要があります。

記録ストレージ（CDR および UDR）の場合、CF VM には、予想される記録要件を満たすサイズの 2 番目の vHDD をプロビジョニングする必要があります（最小 16 GB）。レコードは、2 番目の vHDD 上の /records に書き込まれます。

起動パラメータファイルの構造は次のとおりです。

VARIABLE_NAME = VALUE

行区切りとして改行を使用して、1 行につき 1 つの変数を指定します（UNIX テキストファイル形式）。変数名と値は大文字と小文字が区別されません。無効な値は無視され、エラー通知が VM コンソールに表示されます。変数の値が重複している場合（同じ変数名に 2 つの異なる値が指定されている場合）、最後に定義された値が使用されます。

数値にゼロを埋める必要はありません。たとえば、PCI_ID は 0:1:1.0 の場合、0000:01:01.0 と同様に扱われます。

VPC-SIハイパーバイザによって提供される順序で vNIC インターフェイスを割り当てます。ハイパーバイザの CLI や GUI にリストされている vNIC の順序が、ハイパーバイザが VM に提供する方法と同じであることは保証できません。

VPC-SI が vNIC を検出する順序は PCI バスの列挙順に従い、準仮想デバイスも PCI バスで表されます。PCI バスは、同じレベルの追加デバイスの前にブリッジが探索される深さ優先の方法で列挙されます。すべてのネットワーク インターフェイスのタイプが同じ場合、PCI トポロジを認識するだけで vNIC の正しい順序を取得できます。ネットワーク インターフェイスのタイプが異なる場合、その順序は PCI トポロジに加えて VM 内のデバイスドライバのロード順序に依存します。デバイスドライバのロード順序は、ソフトウェアのリリース順と同じである保証はありませんが、一般的には準仮想デバイスがパススルーデバイスよりも優先されます。

NIC を識別するために使用できる方式はいくつかあります。

• MAC アドレス：インターフェイスの MAC アドレス

• 仮想 PCI ID

• 結合インターフェイス：ネットワークデバイスのボンディングを使用すると、ネットワーク インターフェイスはスレーブ インターフェイス ロールとして機能するように識別されます。ボンドのスレーブインターフェイスは、MAC、PCI ID、またはインターフェイスタイプを使用して識別されます。

• インターフェイスタイプおよびインスタンス番号

仮想 PCI ID

PCI バス上のデバイスは、ドメイン、バス、デバイス、および機能番号と呼ばれる一意のタプルによって識別されます。これらの識別子は、いくつかの方法で識別できます。

ゲスト内では、lspci ユーティリティによって次のようにバスの設定が表示されます。

# lspci

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
00:04.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon
00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
00:06.0 Ethernet controller: Red Hat, Inc Virtio network device
  

この仮想バスのドメイン、バス、デバイス、および機能番号を次に示します。

libvirt ベースの仮想マシンの場合は、virsh dumpxml コマンドから仮想 PCI バストポロジを取得できます。libvirt スキーマでは、デバイス番号に slot という用語が使用されることに注意してください。これは、前の例で使用した仮想マシンにおける xml の説明のスニペットです。

    <interface type='bridge'>
      <mac address='52:54:00:c2:d0:5f'/>
      <source bridge='br3043'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <driver name='vhost' queues='8'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='52:54:00:c3:60:eb'/>
      <source bridge='br0'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </interface>
  

インターフェイスタイプおよびインスタンス番号

ここで NIC は、Linux デバイスドライバの名前（virtio_net、vmxnet3、ixgbe、i40e など）とそのインスタンス番号を使用して、そのタイプによって識別されます。インスタンス番号は、そのタイプのインターフェイスの PCI 列挙順に基づいています。インスタンス番号 1 から始まります。インターフェイスタイプは、パススルーインターフェイスと SR-IOV 仮想機能だけでなく、両方の準仮想タイプを識別するために使用できます。PCI バス上のデバイスの PCI 列挙の順序は、lspci ユーティリティで確認できます。

たとえば、次のゲスト PCI トポロジの CF は、virtio_net インターフェイス番号 1 が 00:05.0 のイーサネットコントローラであり、virtio_net インターフェイス番号 2 が 00:06.0 のイーサネットコントローラであることを示しています。出力は、ゲストで実行された lspci コマンドからのものです 。

# lspci

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
00:04.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon
00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
00:06.0 Ethernet controller: Red Hat, Inc Virtio network device
  

サポートされている Linux ドライバの完全なリストを次に示します。

* * 注：i40eドライバの使用時に、ホスト上で作成された SRIOV VF に対して MAC アドレスの割り当てが動的に行われないという既知の問題が存在します。StarOS VM を起動するには、MAC アドレスの割り当てが必要です。回避策として、MAC アドレスの割り当てはホストから設定する必要があります。詳細は次のリンクを参照してください。https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/xl710-sr-iov-config-guide-gbe-linux-brief.pdf

VPC-SI VM には、管理ネットワークに接続するために 1 つのインターフェイスが設定されています。このインターフェイスは通常、StarOS で設定され、Day 0 設定に含まれている必要があります。管理インターフェイスは、メインの StarOS 設定ファイルを使用してスタティックアドレスの割り当てをサポートします。

0 ～ 4 個の追加ネットワーク インターフェイスはサービスポートとして機能します。これらのインターフェイスは、StarOS によって設定されます。通常、これらのポートは VNF インフラストラクチャ（VNFI）のトランクポートとして設定されます。

仮想ネットワーク機能（VNF）マネージャ（VNFM）が存在する場合は、それに接続されているネットワーク インターフェイスを設定するオプションが VPC-SI VM に備わっています。このインターフェイスは、DHCP またはスタティック IP 割り当てを使用して設定でき、VNFM 以上のレベルのオーケストレータとの通信に使用されます。このインターフェイスは、メインアプリケーションが起動する前に有効になります。

params.cfg の例

MGMT_INTERFACE=MAC:00:01:02:03:04:05
SERVICE1_INTERFACE=PCI_ID:0000:01:02.0
SERVICE2_INTERFACE=PCI_ID:0000:01:03.0
VNFM_INTERFACE=MAC:00:01:02:03:04:AA
VNFM_IPV4_ENABLE=true
VNFM_IPV4_DHCP_ENABLE=false
VNFM_IPV4_ADDRESS=10.1.1.100
VNFM_IPV4_NETMASK=255.255.255.0
VNFM_IPV4_GATEWAY=10.1.1.1
IFTASK_MCDMA_CORES=20
CHASSIS_ID=2sg9x1wqbj
IFTASK_SERVICE_TYPE=0

StarOS コマンド show cloud hardware iftask を使用して iftask ブートパラメータが有効になったことを確認します。

（注）	これらの設定オプションは任意です。

仮想ネットワーク機能マネージャ（VNFM）インターフェイスは、各 VM と VNFM の間で通信するように設計されています。VNFM インターフェイスはメインアプリケーションの前に初期化するため、インターフェイスを設定できるのは起動パラメータのみとなります。

デフォルトでは、VNFM インターフェイスは無効になっています。

VNFM IPv4 インターフェイスの有効化

デフォルト値は [False]（無効）です。

IPv4 DHCP クライアントの設定

IPv4 スタティック IP の設定

（注）	IPv4 DHCP クライアントが有効になっている場合、スタティック設定パラメータは無視されます。

VNFM IPv6 インターフェイスを有効にします。

IPv6 スタティック IP 設定の有効化

True に設定すると、次の項に示すように、スタティック IP パラメータの設定がインターフェイスに適用されます。False に設定すると、インターフェイスはステートレス自動設定（RFC4862）と DHCPv6 の両方を使用してインターフェイスのアドレスを設定しようとします。

IPv6 スタティック IP の設定

（注）	「VNFM_IPV6_ENABLE」パラメータ値が false に設定されている場合、スタティック設定パラメータは無視されます。IPv6 アドレスフィールドは、RFC 5952 に準拠している必要があります。プレフィックスは /64 で固定されています。

以降の項では、FORWARDER_TYPE に VPP を選択した場合にのみ適用されるパラメータを示します。これらのパラメータを使用すると、VPP の CPU とインターフェイス設定をきめ細かく制御できます。

（注）	どのような VPP 設定パラメータをオーバーライドする場合も、事前にシスコのアカウント担当者に連絡してオーバーライド値を確認してください。

VPP の CPU 割り当て

VPP ワーカーは、CPU コア全体を消費するリアルタイムのスレッドです。VPP のメインスレッドはコア全体を消費しませんが、ビジー状態になる可能性があります。したがって、競合を回避するために割り当てます。

次の表に、VPP-CPU パラメータを示します。

VPP_CPU_MAIN=1

VPP_CPU_WORKER_CNT=3

VPP_CPU_WORKER_LIST=2,9,10

デフォルトの DPDK 設定

表に示す次のパラメータは、一般的に DPDK を設定するか、またはインターフェイスのデフォルトを設定します。

VPP_DPDK_BUFFERS=200000

VPP_DPDK_RX_QUEUES=2

VPP_DPDK_TX_QUEUES=4

VPP_DPDK_RX_DESCS=256

VPP_DPDK_TX_DESCS=512

インターフェイス固有の設定

表に示した次のパラメータは、個々のインターフェイスを調整します。これらのパラメータは、デフォルトの DPDK 設定（該当する場合）もオーバーライドします。

SERVICE1_INTERFACE_VPP_RX_QUEUES=2

SERVICE1_INTERFACE_VPP_RX_DESCS=1024

SERVICE1_INTERFACE_VPP_WORKER_LIST=2,3