NSO 設定処理は、次の使用例に対応します。

1. 管理 IP を使用してすでに展開されている VNF（CP、UP、および RCM）の NSO オンボーディング：

   • すでに実行されている VNF（CP、UP、および RCM）をデバイスとして NSO にオンボーディングし、事後チェックを実行して、デバイスの到達可能性と機能を確認します。これは、設定をプッシュまたは同期し、通知の通信を確立するための準備手順です。

     VNF デバイスのオーケストレーション（インスタンス化と破棄）は個別のモジュールであり、設定モジュールに依存しません。デバイスをオンボーディングし、設定管理をサポートするには、特定の詳細（IP、ポート、管理ユーザー名/パスワード）が必要です。

2. CP、UP、および RCM のネイティブ設定またはデバイステンプレートの保存を許可します。

   • RESTCONF/NSO-CLI を介してインターフェイスを提供し、論理名を持つデバイスの再利用可能な設定を管理します。また、ネットワーク SME やオペレータが設定を作成、変更、削除、無効化/有効化できる柔軟性を提供します。目的は、それらのアクティブな設定を選択し、CP、UP、および RCM の Day-0.5、Day-1、または Day-N の一部としてデバイスセットに適用することです。

3. デバイス論理グループ（CP/UP/RCM を含む）またはターゲットデバイスのカスタムリストに Day-N/Day-1/Day-0.5 設定を適用するための CLI/REST インターフェイスを提供します。

   • RESTCONF/NSO-CLI を介してネットワーク SME やオペレータにインターフェイスを提供し、Day-N/Day-1/Day-0.5 の設定を単一または一連のデバイス（CP、UP、または RCM）にプッシュします。このインターフェイスには、エンドユーザーに対する設定のプッシュの進行状況に関する通知やステータスが表示されます。

4. デバイスごとの設定管理のロジスティック管理（Day-N、Day-1、または Day-0.5 プッシュ）：

   • ダッシュボードユーティリティを提供し、デバイスごとに設定ログを管理します。このログは、デバイスで実行された最新のアクティビティを把握するのに役立ちます。

5. 5. （N:M の場合）RCM 通知管理の通知フレームワークを構築し、Day-N、Day-1、および Day-0.5 に関する UP への設定のプッシュを自動化します。

   • NSO で通知フレームワークを構築して、ステータスの変更に関する RCM NETCONF 通知をリッスンし、シナリオに基づいて設定を自動的にプッシュします。

次の図は、ソリューションに関連するコンポーネントとフレームワークの概要を示しています。

N:M UP 冗長性シナリオでは、NSO が設定を管理している間、RCM は引き続き UP のロール（アクティブまたはスタンバイ）の調停を行い、アクティブ UP のスイッチオーバーを処理するため、このソリューションでは、設定機能が RCM から NSO に移動されるだけで、RCM は引き続き必要です。RCM の詳細については、RCM コンフィギュレーションおよびアドミニストレーション ガイド [英語] を参照してください。

Cisco 4G CUPS VNF の導入と設定のワークフローは、NSO から実行されます。次に、NSO の重要なコンポーネントの一部を示します。

• NSO デバイスマネージャ：各 VNF コンポーネント（CP、UP、RCM）を管理し、各デバイス設定のコピーを保持し、デバイス設定プッシュの整合性を管理します。

• NSO サービスマネージャ：カスタマー/ユーザー入力の高レベルの抽象化ネットワークサービスモデルを定義する YANG 標準を提供します。

• CDB：ネットワーク設定と運用データを保存するための永続的な設定データベース。

• モビリティ機能パック：4G CUPS ベースの VNF オーケストレーションと設定を管理するためにカスタム構築された NSO パッケージ。

• NFVO コア機能パック：NSO コア NFV FP は、シスコまたは他のサードパーティの VNFM および VIM（OpenStack/VMWare など）と通信して VNF を展開するためのドライバソフトウェアです。

• StarOS NSO NED：設定をプッシュするために Cisco 4G CUPS VNF と接続する StarOS ベースの NSO ネットワーク エレメント ドライバ（NED）。この NED は Cisco CLI をベースとしています。StarOS NSO NED は、セキュアシェル（SSH）を使用して StarOS 管理 CLI インスタンスと通信します。

• RCM NSO NED：RCM ベースの NETCONF NED は、設定管理のために RCM デバイスと通信する際に使用されます。

以下に、一元化された設定管理をサポートするためのプラットフォームおよびソフトウェアの最小要件を示します。

• サポートされるオーケストレータ：NSO

• 次のネットワーク要素の設定管理：

  • RCM：冗長性と設定の管理

  • VPC-SI：4G CUPS CP または UP として

  • VPC-DI：4G CUPS CP としてのみ

• 最小ハードウェア要件：

  • VM CPU：CPU コア x 8

  • VM RAM：基準は 16 GB RAM、サポートする StarOS デバイスごとに + 10 MB RAM

  • VM 接続：10 GBps ネットワークリンク x 1。これは、個別の VLAN またはその他のメカニズムを使用して、NSO HA と構成/展開の両方に使用できます。

  • VM ストレージ：100 GB ディスク（SSD を推奨）

• 最小ソフトウェアのバージョン

  ソフトウェア	最小バージョン
  Cisco NSO	6.1.6.1
  StarOS NSO NED	5.52.4
  Cisco NSO HCC	6.0.1
  モビリティ機能パック	3.5

（注）	UP、CP、および RCM で推奨される StarOS ソフトウェア イメージ バージョンは、リリース 21.23 以降です。リリースバージョンは密接に結合されておらず、NED のみに依存します。

NSO ベースの設定管理は、ライセンスに基づくシスコの機能です。特定のライセンス要件の詳細については、シスコのアカウント担当者にお問い合わせください。

この項では、4G CUPS 設定管理機能の主要なコールフローについて説明します。

コールフローは、「connect」、「sync-from」などの NSO プリミティブを参照します。プリミティブの詳細については、NSO ユーザーガイド [英語] を参照してください。

（注）	次のコールフロー図では、「NSO ノースバウンド」は NCS CLI または RESTCONF インターフェイスを意味します。

障害状態から以前の状態にリカバリするために、NSO にはプッシュされた設定に対する組み込みのロールバックメカニズムがあります。1 つ以上のデバイスに設定をプッシュするには、次のオプションを使用できます。

• コミットまたは dry-run のみ

• コミット（ロールバックの生成あり）

• 単一または複数のトランザクションのスキーム

• 複数のトランザクションにおける障害処理のスキーム

• スタンバイノード、アクティブノード、または共通ノードのみをプッシュするスキーム

NSO ベースの設定管理の基本となるのが、NSO で各デバイス（VNF）の設定のコピーを維持することです。設定の変更がノースバウンドから適用されると、NSO は適用された設定と設定のローカルコピーを比較して、デバイスにプッシュする必要がある設定を決定します。これを行うには、NSO にある設定のコピーがデバイス/VNF の実際の設定と同期している必要があります。

VNF 設定が NED をバイパスしてアウトオブバンドで実行されるケースには、理由が考えられます。たとえば、Day-0 設定は必ずデバイスを NSO にオンボーディングする前に行われるため、アウトオブバンドになります（適切な VNF マネージャを介してプッシュされます）。設定プッシュ MOP は、デバイスに設定をプッシュする前に「sync-from」操作を実行します。これにより、NSO はアウトオブバンド設定を NSO のローカルコピーにプルし、試行された設定のプッシュは最新のデバイス設定に適用されます。sync-from は、NED に認識されている設定のみをプルできます。また、暗号化されたデータを処理する場合の注意事項があります。

StarOS は、パスワード、キーなどの設定内にある機密要素を暗号化します。暗号化された項目は、StarOS によってのみ復号できるため、NSO には不透明です。さらに、基になるクリアテキストが変更されない場合でも、機密項目の暗号化フォームが変更される可能性があります。その結果、NSO は、そのような項目に加えられたアウトオブバンド変更を確実に検出できません。

次のいずれかを行うことが推奨されます。

• 対応する設定をアウトオブバンドで完全に管理します。

または

• NSO のみを使用して対応する設定を管理します。つまり、最初にノースバウンドから NSO にコマンドのクリアテキストフォーマットを設定し、その後は変更のたびに設定する必要があります。

同じ設定に NSO ベースの設定管理とアウトオブバンド管理を混在させないでください。

合法的傍受（LI）は、いくつかの方法で設定できます。1 つの展開には、専用の LI コンテキスト機能を使用せずに、単一のコンテキスト内のすべての LI 設定が含まれ、一般的なシステム管理者に LI 管理者権限が付与されます。もう 1 つの展開には、専用の LI コンテキスト、分離された LI 設定、および一般的なシステム管理者とは別の専用の LI 管理者が含まれます。それらの中間に位置する他のバリエーションもあります。

NSO で LI 設定を管理できるようにするには、次の要件を満たす必要があります。

• LI 権限と一般的なシステム管理者権限を持っている

• クリアテキストで LI 設定を表示およびプルできる

シングル コンテキスト シナリオですべての LI 設定を含む展開の場合、NSO で LI 設定を管理する必要があります。それ以外の場合は、LI 設定をアウトオブバンドで維持し、Day-0 設定の一部として提供することを推奨します。

デバイスのオンボーディング手順は、モビリティ オーケストレーション ソリューションの外部でインスタンス化またはオーケストレーションされるデバイスにのみ必要です。そうでない場合、インスタンス化された VNF は、NSO ベースのモビリティ オーケストレーション ソリューションによってデバイスとして NSO に暗黙的にオンボードされます。

（注）	この手順は、初回のみ必要です。後続の設定プッシュでは、この手順をスキップする必要があります。

次の例は、RESTCONF または CLI を使用して VNF をオンボードする方法をそれぞれ示しています。

設定プッシュ MOP では、変数の置換が可能です。これは、ほぼ同一の設定が複数のデバイス（たとえば、ICSR アクティブ/スタンバイペア）にプッシュされる場合に役立ちます。違いは、入力設定ファイルの変数として表すことができます。その後、各デバイスの特定の値を「variable: value」形式のメタデータとして入力できます。MOP は、実行時に適切な変数値を動的に置き換えます。

デバイスに事前入力されたデータがない場合、Config MOP は、設定プッシュ用に指定された設定ファイルに動的置換変数がないと想定します。設定ファイルで参照される属性値が欠落している場合、この手順は実行時に失敗します。

設定メタデータの事前入力の構造を以下に記載します。このデータの入力はネットワークスキームとデータセットに基づきます。強調表示された項目は設定をプッシュするための必須項目であり、その他の項目はオプションです。

container metadata-store{

    list config-metadata {

        key device-name;

        leaf device-name {

          tailf:info "onboarding device name";

          type string;

         }

	leaf schema {

	  tailf:info "cluster-topology 1:1, N:M and N+2";

	  type string;

	}

       list attributes {

         key attribute-name;

         leaf attribute-name {

           tailf:info "Attribute Name";

           type string;

         }

         leaf attribute-value {

           tailf:info "Attribute Value";

           type string;

           }

        }
 

	list configuration-type {

	  key config-type;

	  tailf:info "Configuration type Day0.5, Day1 or DayN";

	  leaf config-type {

	    type string;

	   }

          list files {

	    key file-name;

	    tailf:info "file name";

	    leaf file-name {

	      type string;

	    }

	    leaf config-scheme {

	      type string;

	    }

		// CP device info

	    list additional-files {

	      key device; //cp device

	      leaf device{

	        tailf:info "device name";

	        type string;

	       }

		 list additional-file{

		   key additional-file-name;

		   leaf additional-file-name{	

		     tailf:info "file name";

		     type string;

		     }

		   }

	      }

	  }	

	}

  } 

}  

設定メタデータは、設定メタデータ要求を使用して入力されます。この要求は、次の YANG スキーマに従います。「input」セクションの項目は、オペレータが入力します。「output」セクションは、アクション要求の実行後に NSO によって返される内容を示します。

設定メタデータを入力または変更する NSO アクションの例を以下に示します。

tailf:action config-metadata-request {
	        tailf:info "Invoke upgrade action on the selected devices";
	        tailf:actionpoint config-metadata-request;
	        input {
	    	   list config-metadata {
			key device-name;
			leaf device-name {
			  tailf:info "onboarding device name";
			  type string;
			}
		
		list attributes {
		key attribute-name;
		leaf attribute-name {
	          tailf:info "Attribute Name";
		  type string;
		}
		  leaf attribute-value {
		  tailf:info "Attribute Value";
		  type string;
	       }
	     }
	   }
	   }
	   output {
		leaf status {
	          type string;
	        }
	     }
	  }
	 }
 

この手順は、設定 MOP の最後の手順で、新しい設定をプッシュしたり、以前にプッシュした設定をロールバックしたりできます。前述したとおり、プッシュされる設定は 1 つ以上のファイルに存在します。

モビリティ設定 MOP は、NSO からモビリティデバイスを設定するために使用できる一連のコマンドです。モビリティ設定 MOP では、エンドユーザーが場所を指定して、MOP 関連の入力ファイルと出力ファイルを検索または保存できます。また、MOP のグローバル設定可能なパラメータも設定できます。

N:M シナリオでは、RCM が各 UP のロール（アクティブとスタンバイ）を決定します。任意の M 個のスタンバイインスタンスが任意の N 個のアクティブインスタンスを引き継げる必要があるため、プッシュされる設定は異なり、動的に変化します。これは、すべての設定を UP に永続的に保存できるわけではないことも意味します。

RCM は、UP 起動や UP スイッチオーバーなどの関連イベントに対して NETCONF 通知を発行します。NSO は NETCONF 通知をリッスンし、必要に応じて必要な設定を適用します。

UP の設定は以下の論理コンポーネントで構成されます。

• Day-0 設定：これは主に、UP の管理インターフェイスを到達可能にするための基本設定です。この設定は、VNFM による UP 展開時にプッシュされ、再起動後も変わらないと想定されています。

  （注）	必要な rcm-configmgr CLI コマンドは、NSO ベースの設定のプッシュを機能させるために、Day-0 設定の一部として UP で設定する必要があります。このコマンドは、RCM がソリューションで使用されているかどうかに関係なく必要です。このコマンドを設定しない場合、ECS 設定のプッシュは非表示になります。

• Day-0.5 設定：UP が RCM に接続できるようにする設定です。この設定は、UP 展開の直後（NSO が VM を展開している場合）に自動的に、または手動で MOP の設定のプッシュを実行して、Day-0 設定とともにプッシュしたり、NSO とは別にプッシュしたりできます。この設定は、再起動後も永続的に保存されると想定されています。

• 共通設定：これは、アクティブかスタンバイかに関係なく、すべての UP に共通の設定で、ECS と APN の設定のみ該当します。この設定は、NSO に事前入力する必要があります。NSO は、RCM から通知を受信すると、この設定をプッシュします。この設定は、起動設定の一部として永続的に保存されるのではなく、各 UP でファイルとしてローカルに保存され、再起動のたびに NSO によって自動的に再適用されます。

• ホスト固有の設定：これは、アクティブな各 UP に固有の設定で、主に各種サービスの IP アドレスです。各アクティブ UP には、そのアクティブインスタンスに固有の設定がプッシュされます。各スタンバイインスタンスには、すべてのアクティブ UP に関する結合されたホスト固有の設定がプッシュされます。この設定は、NSO に事前入力されている必要があります。NSO は、RCM からの通知に基づいて、必要に応じてこの設定を各 UP にプッシュします。

• ホスト固有の設定：RCM コピー：これは各 UP のホスト固有の設定ですが、RCM 互換形式でフォーマットされています。この設定は RCM にプッシュする必要があります。RCM は設定にはほとんど関係しませんが、UP スイッチオーバー時における設定の否定の実行には関係します。設定の否定とは、特定のアクティブ UP を引き継ぐスタンバイ UP から、他のすべてのアクティブ UP の設定を削除することを意味します。たとえば、3:1 のシナリオで、Active3 UP がダウンしたとします。スタンバイには、Active1、Active2、および Active3 のホスト固有の設定があり、スタンバイが Active3 を引き継ぐため、RCM はスイッチオーバーの一環としてそのスタンバイから Active1 と Active2 の設定を無効にします。

このリリースでは、NSO ベースの設定管理機能に次の制限事項があります。

• 実稼働 NSO インスタンスは、一般的な Linux フレーバー（RedHat、Cisco Linux、Ubuntu、CentOS など）でのみ実行できます。

• Day-1 設定のみが RCM 通知で UP にプッシュされます。他の設定はプッシュされません。

• Day-N 設定の変更を後でプッシュする場合は、その変更を Day-1 設定ファイルとマージして、今後 RCM 通知で自動的にプッシュされるようにする必要があります。

• 事前に入力された設定ファイルに変更がある場合、それらは自動的にプッシュされません。すべてのターゲットデバイスに手動でプッシュする必要があります。次の自動プッシュの設定変更のみが考慮されます。

  N:M の UP の場合、事前に入力された設定ファイルは、それらを使用する VNF が少なくとも 1 つある場合、NSO（HA ペアとして実行されている場合は両方のインスタンス）で保持する必要があります。

• 設定コマンドはサポートされていません。設定ファイル内の show CLI コマンドはサポートされていません。

• NSO から管理する設定は、対応する NED（CP、UP の場合は StarOS NED、RCM の場合は RCM NED）によって認識される必要があります。現在、すべての StarOS 設定コマンドがサポートされているわけではありません。CUPS フィールド展開で最もよく使用される設定のみがサポートされています。欠落しているコマンドをサポートするには、新しい NED が必要です。

• ネイティブ StarOS CLI のサポートは 100% ではありません。サポートされている CLI コマンドの大部分はネイティブの StarOS CLI 形式で使用できますが、NSO が対応する StarOS CLI のバリアントのみを受け入れる場合もあります。このような CLI については、 付録 A：互換性のない StarOS ネイティブ コマンド シンタックスを参照してください。設定 MOP の「ドライラン」機能を使用すると、設定のプッシュを実行する前に、互換性がないかサポートされていない CLI によるエラーを検出できます。

• 操作中に要求を処理する NSO がダウンした場合、設定のプッシュが失敗する可能性があります。これは、手動と自動の両方の設定プッシュに当てはまります。また、NSO HA 展開とスタンドアロン NSO 展開の両方に当てはまります。障害の正確な種類に応じて、オペレータの介入が必要になる場合があります。

• N:M の冗長性シナリオの Day-0.5 設定変更ワークフローは、このリリースでは完全には機能しません。このリリースでの回避策は次のとおりです。

  1. 冗長グループから UP を削除します（アクティブだった場合は、最初にスタンバイにします）。

  2. UP は Day-0 および現在の Day-0.5 設定で起動します。

  3. UP で Day-0.5 設定を変更し、ブート設定として永続的に保存します。

  4. UP を冗長グループに追加します。UP は RCM に登録され、残りの設定は NSO によって自動的にプッシュされます。

• このリリースでは、rcm-upf の MOP タイプを使用してアクティブな課金設定の変更をプッシュする場合、N:M 冗長シナリオでの Day-N 設定のプッシュには、事前の追加手順が必要です。MOP を呼び出す前に、その冗長グループ内のすべての UP でファイル /flash/mobility_production.cfg を手動で削除する必要があります。

• 標準の StarOS CLI NED は、特定の機密設定データをクリアテキストとしてローカルに保存します。NSO では、NACM ルールを使用して機密設定データへのアクセスを制限できます。それでも懸念が残る場合は、シスコのアカウント担当者に連絡して、この機密データをローカルで暗号化する NED バージョンを入手してください。この暗号化は NED と NSO に固有であることに注意してください。StarOS は独自に機密データを暗号化するため、この 2 つの暗号化は個別のものです。NSO がローカルで機密データを暗号化する場合、StarOS デバイスに送信する前に復号します（SSH 経由で送信されるため、転送中に暗号化されますが、StarOS CLI ではクリアテキストとして受信されます）。

• N:M 冗長性シナリオでは、RCM は SSH IP の概念をサポートします。NSO ベースのソリューションでは、SSH IP を使用しません。ただし、FCS（3.0.0 および 21.25）の場合、ソリューションの SSH IP を指定する必要があります。ルーティング不可能なプライベートアドレスを含む任意のアドレスで十分です。このアドレスは、UP の管理インターフェイスでセカンダリアドレスとして設定されます。また、UP の SSH IP 設定要件に関する注意事項については、設定プッシュの前提条件の項を参照してください。

次に、2 つのアクティブ UP のホスト固有の設定例を示します。設定はそれぞれの UP にプッシュされます。

RCM のホスト固有の設定例を以下に示します。この設定は RCM にプッシュされます。

以下に共通の設定例を示します。これは、すべてのアクティブ UP とすべてのスタンバイ UP にプッシュされます。

config
 active-charging service ACS
 idle-timeout udp 60
 statistics-collection ruledef all
 host-pool IPv6_VoLTE_Phone_Host_7
 ip 209.165.200.224/27
 ip 64:ff9b::d3f6:6b00/120
 ip 2001:e60:6000::/46
 ip 2001:e60:6004::/46
 ip range 209.165.200.225 to 209.165.200.234
 ip range 64:ff9b::e00:4f12 to 64:ff9b::e00:4f14
 ip range 64:ff9b::3d6e:ff52 to 64:ff9b::3d6e:ff59
 ip range 64:ff9b::d3f6:682c to 64:ff9b::d3f6:683e
 exit
 port-map M_learning_Port
 port range 1 to 9500
 port range 10001 to 30000
 exit
 port-map OTM_Advertisement_port
 port 90
 port 9090
 exit
 ruledef ICMP
 ip protocol = 1
 exit
 ruledef ICMPv6
 ip protocol = icmpv6
 exit
 ruledef IPv6_VoLTE_Phone_1
 udp either-port range port-map M_learning_Port
 ip server-ip-address range host-pool IPv6_VoLTE_Phone_Host_7
 exit
 ruledef RD-allTraffic
 ip any-match = TRUE
 exit
 ruledef RD_Charge
 ip server-ip-address = 209.165.201.0/27
 exit
 ruledef catchall
 ip any-match = TRUE
 exit
 ruledef googles
 icmpv6 any-match = TRUE
 exit
 ruledef qci1
 tcp any-match = TRUE
 exit
 ruledef route-ims-ipv6-nexthop
 ip uplink = TRUE
 ip version = ipv6
 exit
 ruledef optIn
 ip any-match = TRUE
 exit
 group-of-ruledefs GoR_FOTA
 add-ruledef priority 1 ruledef FOTA_SAMSUNG
 add-ruledef priority 2 ruledef FOTA_LG
 add-ruledef priority 3 ruledef FOTA_LG_2
 add-ruledef priority 5 ruledef FOTA_PANTECH_2
 add-ruledef priority 8 ruledef IOS_OTA_Update
 add-ruledef priority 9 ruledef GOTA_google
 add-ruledef priority 10 ruledef FOTA_Hybrid_Egg
 add-ruledef priority 11 ruledef FOTA_SAMSUNG_2
 add-ruledef priority 12 ruledef FOTA_SAMSUNG_3
 add-ruledef priority 13 ruledef FOTA_SAMSUNG_4
 add-ruledef priority 15 ruledef FOTA_SAMSUNG_5
 add-ruledef priority 16 ruledef FOTA_LG_4
 add-ruledef priority 17 ruledef FOTA_LG_5
 add-ruledef priority 18 ruledef FOTA_HUAWEI_Egg
 add-ruledef priority 20 ruledef KTF_DMS_FOTA
 add-ruledef priority 21 ruledef FOTA_Nlabs
 add-ruledef priority 22 ruledef FOTA_LTE_Beam
 add-ruledef priority 23 ruledef FOTA_S_Mobile
 add-ruledef priority 24 ruledef FOTA_Giga_Genie
 add-ruledef priority 100 ruledef SAMSUNG_SKT_issue
 add-ruledef priority 104 ruledef new_FOTA_Pantech
 add-ruledef priority 106 ruledef new_FOTA_KTtech
 add-ruledef priority 107 ruledef new_IOS_OTA_Log
 add-ruledef priority 114 ruledef new_FOTA_LG_3
 add-ruledef priority 200 ruledef IoT_FOTA_mexus
 add-ruledef priority 201 ruledef IoT_FOTA_acnt
 add-ruledef priority 202 ruledef IoT_FOTA_amtel
 exit
 packet-filter qci1
 ip protocol = 1
 ip remote-port = 1001
 priority 1
 exit
 packet-filter subscriber-pools
 exit
 charging-action CA-nothing
 content-id 5
 exit
 charging-action CA_Chargeable_2
 content-id 1
 billing-action egcdr
 exit
charging-action CA_Charge
exit
 charging-action DSI
 billing-action egcdr
 flow action discard
 tft packet-filter permit_all
 exit
 charging-action ca11
 service-identifier 22
 billing-action egcdr
 cca charging credit
 flow action discard
 flow limit-for-bandwidth id 4
 exit
 charging-action catchall
 content-id 10
 billing-action egcdr
 cca charging credit rating-group 10 preemptively-request
 exit
 charging-action qci1
 billing-action egcdr
 cca charging credit rating-group 1 preemptively-request
 qos-class-identifier 1
 tft packet-filter qci1
 exit
 bandwidth-policy bw-policy
 flow limit-for-bandwidth id 2 group-id 2
 flow limit-for-bandwidth id 4 group-id 4
 flow limit-for-bandwidth id 10 group-id 12
 flow limit-for-bandwidth id 562 group-id 562
 group-id 2 direction downlink peak-data-rate 225280 peak-burst-size 2253 violate-action discard
 group-id 4 direction uplink peak-data-rate 450560 peak-burst-size 4506 violate-action discard
 group-id 10 direction uplink peak-data-rate 1153434 peak-burst-size 11534 violate-action discard
 group-id 11 direction uplink peak-data-rate 10000 peak-burst-size 10000 violate-action discard
 exit
 rulebase 5G-DF
 tcp packets-out-of-order timeout 30000
 no retransmissions-counted
 edr sn-charge-volume count-dropped-units
 bandwidth default-policy bw-policy
 exit
 rulebase RB-allTraffic
 action priority 100 ruledef RD-allTraffic charging-action CA_Charge
 egcdr threshold interval 3600
 egcdr threshold volume total 4000000
 exit
 rulebase RB_Charge
 action priority 10 ruledef RD_Charge charging-action CA_Charge
 exit
 rulebase cisco
 billing-records egcdr
 action priority 12 ruledef catchall charging-action catchall monitoring-key 123
 egcdr threshold interval 120
 egcdr threshold volume total 1000000
 exit
 rulebase cisco_dynamic
 action priority 11 dynamic-only ruledef qci1 charging-action qci1
 action priority 10000 ruledef catchall charging-action catchall
 egcdr threshold interval 120
 egcdr threshold volume total 100000
 exit
 rulebase P2P
 transactional-rule-matching
 dynamic-rule order first-if-tied
 tethering-detection application ip-ttl value 62
 flow end-condition timeout normal-end-signaling session-end charging-edr flow-edr
 billing-records egcdr
 edr transaction-complete http charging-edr http-edr
 flow control-handshaking charge-to-application all-packets
 egcdr threshold interval 3600
 egcdr threshold volume total 4000000000
 no cca quota retry-time
 cca diameter requested-service-unit sub-avp volume cc-total-octets 5000
 p2p dynamic-flow-detection
 no tft-notify-ue-def-bearer
 exit
 rulebase default
 exit
 rulebase wap_adult
      transactional-rule-matching
      tcp mss 1320 limit-if-present
      flow end-condition handoff timeout normal-end-signaling session-end charging-edr flow-edr
      billing-records egcdr radius
      action priority 28 ruledef catchall charging-action CA_Chargeable_2
      action priority 29 ruledef catchall charging-action CA_Chargeable_2
      edr transaction-complete http charging-edr http-edr
      flow control-handshaking charge-to-application  mid-session-packets tear-down-packets
      egcdr threshold volume total 3000000
#exit
 service-scheme ss1
 exit
 credit-control group DCCA_grp1
 diameter origin endpoint Gy
 diameter peer-select peer minid-Gy
 pending-traffic-treatment noquota buffer
 pending-traffic-treatment quota-exhausted buffer
 pending-traffic-treatment validity-expired pass
 exit
 credit-control group default
 pending-traffic-treatment noquota pass
 pending-traffic-treatment quota-exhausted buffer
 exit
 policy-control charging-rule-base-name active-charging-rulebase
 policy-control burst-size auto-readjust duration 3
 exit
 context ecs
 apn cisco.com
 ip context-name ecs
 exit
 apn starent.com
 ip context-name ecs
 exit
end

config
context EPC2
interface loop1_up1 loopback
ip address 198.51.100.123 255.255.255.224

interface loop2_up1 loopback
ip address 209.165.201.0 255.255.255.224

interface loop3_up1 loopback
ip address 209.165.202.128 255.255.255.224

interface loop4_up1 loopback
ip address 192.0.2.0 255.255.255.224

interface loop5_up1 loopback
ip address 198.51.100.0 255.255.255.224

exit
exit

context EPC2
sx-service sx_up1
instance-type userplane
bind ipv4-address 198.51.100.0
exit

exit
exit

context EPC2
gtpu-service pgw-gtpu_up1
bind ipv4-address 209.165.201.0
exit
gtpu-service saegw-sxu_up1
bind ipv4-address 209.165.202.128
exit
gtpu-service sgw-engress-gtpu_up1
bind ipv4-address 192.0.2.0
exit
gtpu-service sgw-ingress-gtpu_up1
bind ipv4-address 198.51.100.0

exit
exit

context EPC2
user-plane-service up_up1
associate gtpu-service pgw-gtpu_up1 pgw-ingress
associate gtpu-service sgw-ingress-gtpu_up1 sgw-ingress
associate gtpu-service sgw-engress-gtpu_up1 sgw-egress
associate gtpu-service saegw-sxu_up1 cp-tunnel
associate sx-service sx_up1
associate fast-path service
associate control-plane-group g1
exit

exit
exit

config
context EPC2
interface loop1_up2 loopback
ip address 209.165.200.230 255.255.255.224

interface loop2_up2 loopback
ip address 209.165.200.231 255.255.255.224

interface loop3_up2 loopback
ip address 209.165.200.232 255.255.255.224

interface loop4_up2 loopback
ip address 209.165.200.233 255.255.255.224

interface loop5_up2 loopback
ip address 209.165.200.234 255.255.255.224

exit
exit

context EPC2
sx-service sx_up2
instance-type userplane
bind ipv4-address 209.165.200.234
exit

exit
exit

context EPC2
gtpu-service pgw-gtpu_up2
bind ipv4-address 209.165.200.231
exit
gtpu-service saegw-sxu_up2
bind ipv4-address 209.165.200.232
exit
gtpu-service sgw-engress-gtpu_up2
bind ipv4-address 209.165.200.233
exit
gtpu-service sgw-ingress-gtpu_up2
bind ipv4-address 209.165.200.230

exit
exit

context EPC2
user-plane-service up_up2
associate gtpu-service pgw-gtpu_up2 pgw-ingress
associate gtpu-service sgw-ingress-gtpu_up2 sgw-ingress
associate gtpu-service sgw-engress-gtpu_up2 sgw-egress
associate gtpu-service saegw-sxu_up2 cp-tunnel
associate sx-service sx_up2
associate fast-path service
associate control-plane-group g1
exit

exit
exit