エンジニアリングルール

この付録では、ネットワークの展開要件を満たすようにシステムを設定するためのエンジニアリング ガイドラインについて説明します。


(注)  


この付録に記載されているエンジニアリングルールは、StarOS の最大キャパシティを反映しています。VM で実行している VPC の実際の制限は、インスタンスに割り当てられた vCPU と vMemory のキャパシティによって異なります。


CLI セッションルール

使用可能なメモリの量に基づく CLI セッションのサポートは複数あります。内部 Resource Manager は、常に 6 つ以上の CLI セッションをサポートするのに十分なリソースを予約します。さらに、6 つのセッションのうちの 1 つは、シリアルインターフェイス上の CLI セッションによる排他的使用のために予約されています。

十分なリソースが使用可能な場合は、事前予約された制限を超える追加の CLI セッションが許可されます。Resource Manager が事前に予約されているリソースを超えて CLI セッションのリソースを予約できない場合、管理権限を持つユーザーは、予約されているリソースがなくても、新しい CLI セッションを作成するように求められます。

VPC インターフェイスとポートのルール

この項で説明するルールは、サブスクライバトラフィックのハイパーバイザを介して指定された vNIC イーサネットポートに関連しています。

vNIC イーサネットポート

  • すべての hypervisorassigned 割り当てられた論理インターフェイスに一意の名前を付けて、同じコンテキスト内の他のインターフェイスとインターフェイスを区別します。

  • 1 つの仮想ポートは、そのポートの VLAN タグを設定するときに、ハイパーバイザを割り当てられた複数の論理インターフェイスをサポートできます。VLAN タグを使用すると、異なるコンテキストに存在する複数の論理インターフェイスに 1 つのポートをバインドできます。

  • サブスクライバトラフィック用の各 vNIC ポートには、最大 1024 の VLAN タグ(VPC シャーシあたり最大 4000 の VLAN)を含めることができます。

  • ハイパーバイザを割り当てられたすべての論理インターフェイスには、有効な IP アドレスとサブネットが必要です。

    • ネットワークでマルチホーミングがサポートされている場合は、すべての論理インターフェイスに 1 つのプライマリ IP アドレスと最大 16 個のセカンダリ IP アドレスを割り当てることができます。

  • 1 つの StarOS 論理(名前付き)インターフェイスをコンテキストごとに設定します。この名前付きインターフェイスは、最大 512 の ethernet+ppp+tunnel インターフェイスを持つことができます。

  • 異なる StarOS コンテキストは、同じ論理(名前付き)インターフェイスを共有できます。

  • 最大 256 のアクセスコントロールリスト(ACL)ルールを StarOS 論理インターフェイスに適用できます。

  • StarOS では、すべてのポートが <slot>/<port> によって識別されます。

パケットデータネットワーク(PDN)インターフェイスのルール

パケットデータネットワーク(PDN)へのインターフェイスには、次のエンジニアリングルールが適用されます。

  • 出力コンテキスト内の PDN インターフェイスを容易にするために使用される論理インターフェイスを設定します。

  • デフォルトでは、出力コンテキスト内で 1 つのインターフェイスを使用し、PDN インターフェイスを容易にします。

  • スタティックルートまたはダイナミック ルーティング プロトコルを使用して、出力コンテキスト内に複数のインターフェイスを設定できます。

  • また、ネクストホップのデフォルトゲートウェイを設定することもできます。

コンテキストルール

  • シャーシごとに最大 63 のコンテキストを設定できます。MIO カードでデマルチプレクサ機能を有効にすると、コンテキストの最大数が 10 に低減します。

  • コンテキストごとのインターフェイス

    • Demux MIO/UMIO/MIO2 機能を有効にすると、最大 64 のインターフェイスを 1 つのコンテキスト内に設定できます。

    • 512 イーサネット + PPP + トンネルインターフェイス

    • 32 ipv6ip トンネルインターフェイス

    • 511 GRE トンネル(シャーシあたり 2,048 GRE トンネル)

    • 256 ループバック インターフェイス

  • IP アドレスと IP アドレスプール

    • 最大 2,000 の IPv4 アドレスプールを 1 つのコンテキスト内に設定できます。

    • 最大 256 の IPv6 プールを 1 つのコンテキスト内に設定できます。

    • 合計で 5,000 の IPv4 アドレスと IPv6 アドレスをシャーシごとに設定できます。

    • 各コンテキストは、最大 3,200 万のスタティック IP プールアドレスをサポートします。シャーシごとにあたり合計で最大 9,600 万のスタティック IP プールアドレスを設定できます。各スタティック IP プールには、最大 50 万のアドレスを含めることができます。

    • 各コンテキストは、最大 1,600 万のダイナミック IP プールアドレスをサポートします。シャーシあたり合計で最大 3,200 万のダイナミック IP プールアドレスを設定できます。各ダイナミック IP プールには、最大 50 万のアドレスを含めることができます。


      重要


      コンテキストとシャーシあたりでサポートされる IP プールの実際の数は、使用しているアドレスの数とサブネット化の方法によって異なります。



      重要


      プール内の各アドレスには、約 60 バイトのメモリが必要です。ただし、必要なメモリの量は、プールタイプやホールドタイマーの使用率などのさまざまな要因によって異なります。そのため、設定するアドレスの数とインストールされているアプリケーションカードの数に応じて、プールの数を制限して使用可能なメモリを節約する必要がある場合があります。


  • 同時サブスクライバセッションの最大数は、サポートされているサービスのインストール済みのキャパシティライセンスによって制御されます。

  • コンテキストあたりのスタティックアドレス解決プロトコル(ARP)エントリの最大数は 128 です。

  • コンテキストあたりのドメインの最大数は 2,048 です。

  • 同じコンテキスト内に設定された ASN-GW サービスは、相互に通信できません。

  • ルート

    • コンテキストあたりの最大 1,200 のスタティックルート(シャーシあたり 48,000)。

    • コンテキストあたり 6,000 のプールルート(シャーシあたり 6,000)

    • コンテキストあたり 24,000 のプール(シャーシあたり 24,000)の明示的ホストルート

    • コンテキストあたり 64 のルートマップ

  • BGP

    • コンテキストあたり 64,000 の BGP プレフィックス(シャーシあたり 64,000)を学習/アドバタイズできます。

    • コンテキストあたり 64 の EBGP ピアの設定が可能(シャーシあたり 512)

    • コンテキストあたり 16 の IBGP ピア

    • シャーシ間セッションリカバリ(ICSR)のサポートのサポートにコンテキストあたり 512 の BGP/AAA モニター

  • OSPF

    • シャーシあたり 200 の OSPF ネイバー

    • コンテキストあたり 10,000 の OSPF ルート(シャーシあたり 64,000)

  • MPLS

    リリース 21.6 まで

    • コンテキストあたり 16 のラベル配布プロトコル(LDP)セッション

    • コンテキストあたり最大 8,000 の着信ラベルマップ(ILM)エントリ(シャーシあたり 48,000)

    • 128,000 のネクストホップラベル転送エントリ(NHLFE)と発生する可能性がある 64,000 のプレフィックスのテーブルサイズを組み合わせます。

      • コンテキストあたり 1,000 の転送等価クラス(FEC)エントリ(シャーシあたり 4,000):32 のパスを含む

      • コンテキストあたり 2,000 の転送等価クラス(FEC)エントリ(シャーシあたり 8,000):16 のパスを含む

      • コンテキストあたり 16,000 の転送等価クラス(FEC)エントリ(シャーシあたり 64,000):2 つのパスを含む

      • コンテキストあたり 64,000 の転送等価クラス(FEC)エントリ(シャーシあたり 64,000):1 つのパスを含む

  • リリース 21.7 以降

    • コンテキストあたり 16 のラベル配布プロトコル(LDP)セッション

    • コンテキストあたり最大 8,000 の着信ラベルマップ(ILM)エントリ(シャーシあたり 48,000)

    • 256,000 のネクストホップラベル転送エントリ(NHLFE)と発生する可能性がある 64,000 のプレフィックスのテーブルサイズを合算します。

      • コンテキストあたり 1,000 の転送等価クラス(FEC)エントリ(シャーシあたり 4,000):64 のパスを含む

      • コンテキストあたり 2,000 の転送等価クラス(FEC)エントリ(シャーシあたり 8,000):32 のパスを含む

      • コンテキストあたり 32,000 の転送等価クラス(FEC)エントリ(シャーシあたり 64,000):2 つのパスを含む

      • コンテキストあたり 64,000 の転送等価クラス(FEC)エントリ(シャーシあたり 64,000):1 つのパスを含む

  • VRF

    • コンテキストあたり 300の Virtual Route Forwarding(VRF)テーブル(シャーシあたり 2,048 の VRF)(MIO カードで有効になっている demux 機能を使用した場合、コンテキストあたり 256 の VRF)

    • APN の制限はシャーシあたり 2,048 です。VRF の制限と APN の制限は同一である必要があります。

    • 64,000 の IP ルート

  • NEMO(ネットワークモビリティ)

    • シャーシあたり 512,000 のプレフィックス/フレーム化されたルートと、MR(モバイルルータ)あたり最大 16 の動的に学習されたプレフィックス

  • デフォルトの AAA サーバーグループの場合はコンテキストあたり 128 の AAA サーバーサーバーは、アカウンティング、認証、課金サーバー、またはそれらの組み合わせとして設定できます。

  • 次の制限事項を踏まえて、コンテキストあたり最大 800 の AAA サーバーグループを設定できます。

    • AAA サーバーグループあたり 128 のサーバー(アカウンティング、認証、課金サーバー、またはその組み合わせ)

    • AAA サーバーグループモードあたり 1,600 のサーバー(アカウンティング、認証、課金サーバー、またはその組み合わせ)

    • コンテキストあたり 800 の NAS-IP アドレス/NAS 識別子(サーバーグループあたりプライマリ 1、セカンダリ 1)

  • GTPP アカウント用としてコンテキストあたり最大 12 の課金ゲートウェイ機能(CGF)を設定できます。

  • コンテキストあたり最大 16 の Bidirectional Forwarding Detection(BFD)セッション(シャーシあたり 64)


重要


製品固有の動作制限の詳細については、製品管理ガイドの「エンジニアリングルール」を参照してください。


サブスクライバルール

システム内に設定されているサブスクライバには、次のエンジニアリングルールが適用されます。

  • コンテキストごとに最大 2048 のローカルサブスクライバを設定します。

  • 各ローカルサブスクライバの属性を設定できます。

  • コンテキストが確立されると、システムはコンテキストごとにデフォルトのサブスクライバを作成します。各デフォルトサブスクライバの属性を設定します。AAA ベースのサブスクライバが認証応答メッセージに属性がない場合、サブスクライバが認証されたコンテキスト内のデフォルトのサブスクライバ属性が使用されます。


    重要


    ローカル認証(ローカルサブスクライバの場合)が実行される場合、デフォルトは使用されません。


  • AAA レルム(コンテキスト内で設定されたドメインエイリアス)ごとにデフォルトのサブスクライバテンプレートを設定します。

  • PDSN、FA、ASN GW、または HA サービスごとにデフォルトのサブスクライバテンプレートを設定します。

  • AAA 認証サブスクライバの場合、属性の設定に使用するローカル サブスクライバ テンプレートの選択は、次の順序で行われます。
    • ユーザー名(NAI)が任意のローカルドメイン名と一致し、ドメイン名にローカルサブスクライバ名が設定されている場合、そのローカル サブスクライバ テンプレートが使用されます。

    • 最初のケースが失敗し、提供サービスにデフォルトのユーザー名が設定されている場合は、そのサブスクライバテンプレートが使用されます。

    • 最初の 2 つのケースが失敗した場合は、AAA コンテキストのデフォルトのサブスクライバテンプレートが使用されます。

サービスルール

システム内に設定されているサービスには、次のエンジニアリングルールが適用されます。

  • システムごとに(タイプに関係なく)最大 256 のサービスを設定します。


    注意    


    多数のサービスによって管理の複雑度が大幅に増大し、システム全体のパフォーマンスに影響を与える可能性があります。したがって、アプリケーションが絶対に必要としない限り、多数のサービスを設定する必要はありません。詳細については、シスコのサービス担当者にお問い合わせください。


  • テーブルあたりおよびシャーシあたりのエントリの合計数は、256 に制限されます。

  • 同じシステム上の異なるコンテキストで設定されたものと同じサービス名を使用できますが、これは適切な方法ではありません。同じ名前のサービスを使用すると、混乱が生じ、問題のトラブルシューティングが困難になる可能性があります。また、show コマンドの出力を理解することが困難になります。

Access Control List(ACL; アクセスコントロールリスト)のエンジニアリングルール

アクセスコントロールリストには、次のルールが適用されます。

  • ACL ごとルールの最大数は 128 です。

  • ポートごとに適用される ACL ルールの最大数は 128 です。

  • コンテキストごとに適用される ACL ルールの最大数は 1,024 です。

  • IPSec ポリシーごとの ACL ルールの最大数は 1 です。

  • コンテキストごとの IPSec ACL ルールの最大数は1,024です。

  • 暗号マップごとの IPSec ACL ルールの最大数は 8 です。

  • コンテキストごとに設定できる ACL の最大数は、各 ACL 内で許可されるルールの数によって制限されます。各 ACL にルールの最大数(128)が含まれている場合、コンテキストあたりの ACL の最大数は 8(128 X 8 ACLs = 1,024 ACL rules per context)です。

  • IP アクセスグループに適用される ACL の最大数は、ポートまたはコンテキストに設定されているかどうかにかかわらず、1です。インターフェイスまたはコンテキストに適用できる IP アクセスグループの最大数は 16 であるため、次の計算が適用されます。
    • 各インターフェイス/ポートについて:ACL ごとの 8 つのルールと 16 の IP アクセスグループの乗数 = 128(ポートごとの ACL ルールの制限)
    • 各コンテキストについて:ACL ごとの 64 ルールと 16 IP アクセスグループの乗数 = 1,024(コンテキストごとの ACL ルールの制限)

ECMP グループ

等コストマルチパス(ECMP)グループの最大数は次のとおりです。

  • 21.4 よりも前のリリースでは、StarOS は最大 64,000 グループをサポートしています。

  • 21.4 以降のリリースでは、StarOS は最大 32,000 グループをサポートしています。


(注)  


  • max_num は 1 ~ 10 の整数です。

    リリース 21.4x

    • QVPC-DI: 64

    • QVPC-SI: 64

    • ASR 5500: 24

  • 設定の確認と保存の章の説明に従って、設定を保存します。


VPN スケーリングの要件

特定のリリースでは、次の VPN スケーリング番号がサポートされています。

パラメータ

スケーリング番号(リリース 12.x、14.x)

スケーリング番号(リリース 15.x、16.x)

スケーリング番号(リリース 17.x、18.x、19.x、20.x +)

BFD セッション

コンテキストあたり 16

シャーシあたり 64

コンテキストあたり 16

シャーシあたり 64

コンテキストあたり 16

シャーシあたり 64

コンテキストレベルの ACL

コンテキストあたり 256

コンテキストあたり 256

コンテキストあたり 256

ダイナミックプールアドレス

コンテキストあたり 1,600 万

シャーシあたり 3,200 万

コンテキストあたり 1,600 万

シャーシあたり 3,200 万

コンテキストあたり 1,600 万

シャーシあたり 3,200 万

コンテキストごとの IPv4 プール

コンテキストあたり 2,000

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

コンテキストあたり 2,000

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

コンテキストあたり 2,000

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

コンテキストごとの IPv6 プール

各コンテキストに 32

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

コンテキストあたり 256

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

コンテキストあたり 256

シャーシあたり 5,000(IPv4 と IPv6 の組み合わせ)

BGP プレフィックスの数

コンテキストあたり 16,000

シャーシあたり 64,000

コンテキストあたり 32,000

シャーシあたり 64,000

コンテキストあたり 64,000

シャーシあたり 64,000

コンテキストの数

63(ただし、コンテキストが 32 を超えると、PSC の移行は正常に機能しません)

63(ただし、コンテキストが 32 を超えると、PSC の移行は正常に機能しません)

この項の最後にある「MIO カード上のデマルチプレクサ」に関する情報に注意してください。

63(ただし、コンテキストが 32 を超えると、PSC の移行は正常に機能しません)

この項の最後にある「MIO カード上のデマルチプレクサ」に関する情報に注意してください。

動的に学習した MR あたりのプレフィックスの数

8

16

16

EBGP ピアの数

コンテキストあたり 64

シャーシあたり 512

コンテキストあたり 64

シャーシあたり 512

コンテキストあたり 64

シャーシあたり 512

FEC エントリの数

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

IBGP ピアの数

コンテキストあたり 16

コンテキストあたり 16

コンテキストあたり 16

ILM エントリの数

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

コンテキストあたり 8,000 ラベル

シャーシあたり 48,000

インターフェイスの数

コンテキストあたり 512イーサネット + ppp + トンネルインターフェイス

コンテキストあたり 32 IPv6 IP トンネルインターフェイス

コンテキストあたり最大 511 GRE トンネルおよびシャーシあたり最大 2,048 GRE トンネル

コンテキストあたり 256 ループバック インターフェイス

コンテキストあたり 512イーサネット + ppp + トンネルインターフェイス

コンテキストあたり 32 IPv6 IP トンネルインターフェイス

コンテキストあたり最大 511 GRE トンネルおよびシャーシあたり最大 2,048 GRE トンネル

コンテキストあたり 256 ループバック インターフェイス

この項の最後にある「MIO カード上のデマルチプレクサ」に関する情報に注意してください。

コンテキストあたり 512イーサネット + ppp + トンネルインターフェイス

コンテキストあたり 32 IPv6 IP トンネルインターフェイス

コンテキストあたり最大 511 GRE トンネルおよびシャーシあたり最大 2,048 GRE トンネル

コンテキストあたり 256 ループバック インターフェイス

この項の最後にある「MIO カード上のデマルチプレクサ」に関する情報に注意してください。

LDP セッションの数

コンテキストあたり 16

コンテキストあたり 16

コンテキストあたり 16

NEMO プレフィックス/フレームルートの数

シャーシあたり 256,000

シャーシあたり 512,000

シャーシあたり 512,000

OSPF ネイバーの数

シャーシあたり最大 200

シャーシあたり最大 200

シャーシあたり最大 200

OSPF ルートの数

コンテキストあたり最大 10,000

シャーシあたり 64,000

コンテキストあたり最大 10,000

シャーシあたり 64,000

コンテキストあたり最大 10,000

シャーシあたり 64,000

プールの明示的なホストルートの数

コンテキストあたり 5,000(シャーシあたり 6,000)

コンテキストあたり 5,000(シャーシあたり 6,000)

17.x および 18.[1234] でコンテキストあたり 5,000(シャーシあたり 6,000)

18.5 以降でコンテキストあたり 24,000(シャーシあたり 24,000)

プールルートの数

コンテキストあたり 6,000(シャーシあたり 6,000)

コンテキストあたり 6,000(シャーシあたり 6,000)

コンテキストあたり 6,000(シャーシあたり 6,000)

ルートの数(フレームルートを除く)

コンテキストあたり 64,000

コンテキストあたり 64,000

コンテキストあたり 64,000

インターフェイスあたりのセカンダリアドレスの数

16

16

16

スタティックルートの数

コンテキストあたり 1,200

コンテキストあたり 1,200

コンテキストあたり 1,200

VLAN の数

シャーシあたり 4,000

シャーシあたり 4,000

シャーシあたり 4,000

VRF の数

コンテキストあたり 250

シャーシあたり 2,048

APN の制限は 1024/シャーシであり、VRF の制限と一致しません。

コンテキストあたり 300

シャーシあたり 2,048

(注)  

 
  • VRF の制限と APN の制限は同一であると想定しています。

  • この項の最後にある「MIO カード上のデマルチプレクサ」の項に注意してください。

コンテキストあたり 300

シャーシあたり 2,048

注:VRF の制限と APN の制限は同一であると想定しています。

この項の最後にある「MIO カード上のデマルチプレクサ」の項に注意してください。

ルートの数 (フレームルートを含むすべての種類のルート)

コンテキストあたり 64,000

コンテキストあたり 64,000

コンテキストあたり 64,000

ルート マップ

コンテキストあたり 64

コンテキストあたり 64

コンテキストあたり 64

スタティックプールアドレス

コンテキストあたり 3200 万

シャーシあたり 9600万

コンテキストあたり 3200 万

シャーシあたり 9600万

コンテキストあたり 3200 万

シャーシあたり 9600万

MIO カードでの Demux

MIO カードで Demux を有効にすると、VPN リソースは MIO カードでコントローラプロセスと結合されるため、すべての VPN タスクで使用可能なリソースが減少します。これにより、MIO カードが demux-enabled の場合に、制限の一部(前の項で説明)が削減されます。