The NSO configuration-handling caters to the following use cases:

1. NSO on-boarding of VNFs (CPs, UPs, and RCMs) that are already deployed using Management IPs:

   • Onboarding of already-running VNFs (CPs, UPs, and RCMs) as devices into NSO and perform post-check to ensure the reachability and functioning of the devices. This is preliminary step to push/sync any configuration and establish communication for notifications.

     Orchestration of VNF devices (Instantiation and Destroy) is a separate module, and it doesn’t have any dependency on configuration module. We need certain details (IP, Port, Management Username/Password) to onboard the device and supporting configuration management.

2. Allowing to store native-configs or device-templates for CPs, UPs, and RCMs:

   • Providing interface through RESTCONF/NSO-CLI to manage the reusable configurations for devices with logical name. Providing flexibility to network SMEs/Operators to create, modify, delete, and disable/enable the configurations. Aim is to pick those active configurations and apply to the device set as part of Day-0.5, Day-1, or Day-N for CPs, UPs, and RCMs.

3. Providing CLI/REST interface to apply Day-N/Day-1/Day-0.5 configurations to device logical groups (including CPs/UPs/RCMs) or custom list of target devices:

   • Providing interface through RESTCONF/NSO-CLI to Network SMEs/Operators to push Day-N/Day-1/Day-0.5 configurations to single or set of devices (CPs, UPs, or RCMs). This interface exhibits notifications/status on the progress of configuration push to the end users.

4. Logistic management of configuration management per device basis (Day-N, Day-1, or Day-0.5 pushed):

   • Providing dashboard utility and managing the configuration logs per device basis. This log is useful to know the most recent activity done on the device.

5. 5. Build the notification framework for RCM notification management in (N:M cases) and automate the configuration push for UPs for Day-N, Day-1, and Day-0.5:

   • Building notification framework in NSO to listen to RCM NetConf notifications on status changes, and push configurations automatically based on scenarios.

The following diagram illustrates, at a high-level, the components and frameworks involved in the solution.

In the N:M UP redundancy scenario, while the NSO manages configuration, the RCM will continue to arbitrate the role of the UPs (Active or Standby) and handle the switchover of an Active UP. Hence, this solution only moves the configuration function out of the RCM into the NSO; RCM is still required. For details about RCM, refer to the RCM Configuration and Administration Guide.

Cisco 4G CUPS VNF deployment and configuration workflows are driven from the NSO. The following are some of the important components of NSO:

• NSO Device Manager: Manages each VNF component (CP, UP, RCM), keeps the copy of each device configurations, and manages the integrity of device configuration push.

• NSO Service Manager: Provides YANG standard to define high-level abstraction network service model for the customer/user input.

• CDB: Persistent Configuration Database for storing network configurations and operational data.

• Mobility Function Packs: Custom-built NSO packages to manage the 4G CUPS-based VNF orchestration and configuration management.

• NFVO Core Function Pack: NSO core NFV FP is a driver software to communicate with Cisco or other 3rd party VNFMs and VIMs, like OpenStack/VMWare, to deploy VNFs.

• StarOS NSO NED: StarOS-based NSO Network Element Driver (NED) that interfaces with the Cisco 4G CUPS VNFs for configuration push. This NED is based on Cisco CLI. The StarOS NSO NED communicates with the StarOS management CLI instance using Secure Shell (SSH).

• RCM NSO NED: RCM-based NETCONF NED is used to communicate with RCM devices for configuration management.

The following are the minimum platform and software requirements to support centralized configuration management:

• Supported Orchestrator: NSO

• Configuration management for following Network Element’s:

  • RCM: Redundancy and Configuration Management

  • VPC-SI: As 4G CUPS CP or UP

  • VPC-DI: As 4G CUPS CP only

• Minimum hardware requirements:

  • VM CPU: 8 CPU cores

  • VM RAM: 16 GB RAM baseline + 10 MB RAM for every StarOS device to be supported

  • VM connectivity: One 10 GBps network link. This can be used for both NSO HA and config/deployment by using separate VLANs or other mechanisms

  • VM Storage: 100 GB disk (preferably, SSD)

• Minimum software version

  Software	Minimum Version
  Cisco NSO	6.1.6.1
  StarOS NSO NED	5.52.4
  Cisco NSO HCC	6.0.1
  Mobility Function Pack	3.5

Note	The recommended StarOS software image version for UP, CP, and RCM is 21.23 and later releases. The release versions are not tightly coupled and only depend on the NEDs.

The NSO-based Configuration Management is a licensed Cisco feature. Contact your Cisco Account representative for detailed information on specific licensing requirements.

This section describes the key call flows for the 4G CUPS configuration management functionality.

The call flows refer to NSO primitives like "connect", "sync-from", and so on. For detailed information on these primitives, refer to the NSO User Guide.

Note	In the following call flow diagrams, “NSO Northbound” implies NCS CLI or RESTCONF interface.

To recover from fault state to previous state, NSO provides in-built rollback mechanism for the pushed configurations. The following options are available for pushing the configuration to one or more devices:

• Commit or Dry-Runs only

• Commit with Rollback generated

• Scheme of Single or Multiple transactions

• Scheme for failure-handling on multiple transactions

• Scheme for pushing only stand-by nodes, active nodes, or common

A fundamental aspect of NSO-based configuration management is that the NSO maintains a copy of each device's (VNFs) configuration. When any configuration changes are applied from Northbound, the NSO compares its local copy of the configuration with the applied configuration to determine precisely what configuration needs to be pushed into the device. For this to occur, the NSOs copy of the configuration has to be in-sync with the actual configuration on the device/VNF.

There can be reasons due to which VNF configuration may be performed out-of-band, bypassing the NED. For example, any Day-0 configuration necessarily precedes onboarding the device into the NSO and thus is out-of-band (it is pushed through the appropriate VNF Manager). The configuration push MOP performs a "sync-from" operation prior to pushing any configuration to a device. This ensures that the NSO pulls any out-of-band configuration into the NSOs local copy, and the attempted configuration push is applied to the most current device configuration. The sync-from can only pull configuration that is known to the NED. Also, there are caveats when dealing with encrypted data.

StarOS encrypts sensitive elements in the configuration like passwords, keys, and so on. The encrypted items can only be decrypted by StarOS and are thus opaque to the NSO. Furthermore, the encrypted form of the sensitive item can change even when the underlying cleartext does not. As a result, the NSO cannot reliably detect any out-of-band changes made to such items.

The recommendation is to either:

• Completely manage the corresponding configuration out-of-band

—Or—

• Use only the NSO to manage the corresponding configuration, meaning the cleartext form of the command must be configured into NSO from Northbound initially, and for every subsequent change.

Do not mix NSO-based configuration management and out-of-band management for the same configuration.

Lawful Intercept (LI) can be configured in a couple of different ways. One deployment involves all LI configuration in a single context (without using the dedicated LI context feature), and providing the general system administrator with LI administrator privileges. The other deployment involves a dedicated LI context, segregated LI configuration, and a dedicated LI administrator separate from general system administrator. There are other variations that likely fall in-between.

For the NSO to be able to manage LI configuration, it needs to:

• Have LI privileges and general system administrator privileges

• Be able to view and pull LI configuration in cleartext

For the deployment that involves all LI configuration in a single context scenario, the NSO must manage the LI configuration. For the other cases, it is recommended that the LI configuration be maintained out-of-band and provided as part of Day-0 configuration.

The Device onboarding step is required only for the devices which are instantiated or orchestrated outside the Mobility orchestration solution. Otherwise, the instantiated VNF is implicitly onboarded onto the NSO as a device by the NSO-based Mobility orchestration solution.

Note	This step is required only for the first time. Subsequent configuration pushes should skip this step.

The following examples illustrate how to onboard the VNF using RESTCONF or CLI respectively.

The configuration push MOP allows for variable substitution. This is useful in cases where nearly identical configuration is pushed to multiple devices (for example an ICSR active/standby pair). The differences can be represented as variables in the input configuration file. You can then populate the specific values for each device as metadata in a "variable: value" format. The MOP dynamically substitutes the right variable values at runtime.

If there are no prepopulated data for the device, Config MOP assumes that there are no dynamic substitution variables in config files, which are given for configuration push. If any attribute values that are referred in config files are missing, this step fails at runtime.

Prepopulating of config metadata has the following structure, and population of this data is based on the network scheme and data set. Highlighted items are mandatory for config push, and other items are optional.

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;

		     }

		   }

	      }

	  }	

	}

  } 

}  

Configuration meta-data is populated using the configuration meta-data request. This request follows the following YANG schema. The items in the "input" section are to be provided by the operator. The "output" section represents what is returned by the NSO after execution the action request.

The following is an example of NSO action to populate or modify the config meta-data:

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;
	        }
	     }
	  }
	 }
 

This step is the final step in the configuration MOP. It allows you to push a fresh configuration or rollback a previously pushed configuration. The configuration to be pushed is present in one or more files as mentioned previously

The Mobility configuration MOP is a set of commands that can be used to configure mobility devices from the NSO. This allows end user to specify locations to find or save the MOP-related input files and output files. It also allows the end user to setup global configurable parameters for MOP.

In the N:M scenario, the RCM determines the role of each UP (active versus standby). Since any of the M standby instances must be capable of taking over for any of the N active instances, the configurations to be pushed are different and dynamic. This also means not all configuration can be saved on the UPs persistently.

RCM issues NETCONF notifications for relevant events such as a UP booting up or UP switchover. NSO listens to those notifications and applies the necessary configuration as appropriate.

The configuration for a UP consists of the following logical components:

• Day-0 configuration: This is primarily basic configuration for the UP's management interface to be reachable. This is pushed at the time of UP deployment by the VNFM. This configuration is expected to be persistent across reboot.

  Note

  The require rcm-configmgr CLI command must be configured on the UP as part of Day-0 configuration for the NSO-based configuration push to work. This command is required irrespective of whether RCM is used in the solution or not. Without configuring this command, the ECS configuration push appears hidden.

• Day-0.5 configuration: This is configuration that allows the UP to contact the RCM. This configuration can be pushed either along with day 0, or pushed separately from the NSO, either automatically, right after UP deployment (if NSO is deploying the VM), or by a manual execution of the config push MOP. This configuration is also expected to be saved persistently across reboots.

• Common configuration: This is configuration that is common to all UPs regardless of whether they are active or standby. This is ECS and APN configuration only. This configuration needs to be pre-populated in the NSO. NSO will push this upon receiving notifications from the RCM. This configuration is not saved persistently as part of the boot configuration but is saved locally as a file on each UP and re-applied on every reboot by the NSO automatically.

• Host-specific configuration: This is configuration that is unique to each active UP. This is primarily the various service IP addresses. Each active UP is pushed the configuration specific to that active instance. Each standby instance is pushed the combined host-specific configurations of all active UPs. This configuration is expected to be pre-populate don the NSO. NSO will push this to each UP as appropriate based on the notification from the RCM.

• Host-specific configuration - RCM copy: This is the host-specific configuration of each UP, however, formatted in RCM compatible format. This needs to be pushed to the RCM. While RCM is not involved in configuration for the most part, it is still involved in performing config negation during UP switchover. Config negation means removing the configuration of all the other active UPs from the standby UP that is about to take over for a given active UP. So, say, in a 3:1 scenario, Active3 UP goes, down. The standby has the host-specific configurations of Active1, Active2, and Active3. Since the standby now takes over for Active3, the RCM negates the configs of Active1 and Active2 from that standby as part of the switchover.

The NSO-based Configuration Management feature has the following limitations in this release:

• Production NSO instance can run only on popular Linux flavors (for example, RedHat, Cisco Linux, Ubuntu, CentOS, and so on).

• Only Day-1 configuration is pushed for UP on RCM notifications. No other configurations are pushed.

• For pushing Day-N configuration change at a later point, you must merge that change with the Day-1 configuration files for it to be automatically pushed on an RCM notification going forward.

• If there are changes to pre-populated configuration files, they aren’t pushed automatically. It’s required to push them manually for all target devices. The configuration changes only for next auto-push is considered.

  For N:M UPs, the pre-populated configuration files must be preserved on the NSO (both instances if running as an HA pair) if there is at least one VNF using them.

• Only configuration commands are supported. The show CLI commands within configuration files aren’t supported.

• Any configuration, to be managed from the NSO, must be understood by the corresponding NED (StarOS NED for CPs, UPs, and RCM NED for RCMs). Currently, not all StarOS configuration commands are supported—only the most used configurations in CUPS field deployments are supported. Support for any missing commands requires a newer NED.

• Support of native StarOS CLI is not 100%. While majority of the supported CLI commands are acceptable in native StarOS CLI format, there are some cases where the NSO accepts only a variant of the corresponding StarOS CLI. Such CLIs are documented in Appendix A: Incompatible StarOS Native Command Syntax. You can use the "dry-run" functionality of the configuration MOP to detect any errors due to incompatible/unsupported CLI prior to performing a configuration push.

• A configuration push may fail if the NSO handling the request goes down during the operation. This is applicable for both manual and automated configuration push. It is also applicable for both NSO HA and standalone NSO deployments. Operator intervention may be required depending on the exact nature of the failure.

• The Day-0.5 configuration change workflow for the N:M redundancy scenario is not fully functional in this release. For this release, the workaround is to:

  1. Remove the UP from the redundancy group (making it Standby first, if it was Active)

  2. UP boots up with Day-0 and current Day-0.5 configuration

  3. Make the Day-0.5 configuration change on the UP and save it persistently as the boot configuration

  4. Add the UP back to the redundancy group. The UP registers with the RCM and the remaining configurations are pushed by NSO automatically

• In this release, the Day-N configuration push in the N:M redundancy scenario requires a prior extra step if active-charging configuration changes are pushed using the rcm-upf MOP type. It is required to manually delete the file /flash/mobility_production.cfg on all the UPs in that redundancy group prior to invoking the MOP.

• The standard StarOS CLI NED stores certain sensitive configuration data as cleartext locally. Access to this can be restricted by using the NACM rules on the NSO. If there are additional concerns with this, contact your Cisco Account representative for a version of the NED that encrypts this sensitive data locally. Note that this encryption is specific to the NED and NSO. StarOS encrypts sensitive data on its own—the two encryptions are separate. When NSO encrypts the sensitive data locally, it decrypts it prior to transmitting it to StarOS device (it is sent over SSH, so it is encrypted in transit, but is received by StarOS CLI as cleartext).

• For the N:M redundancy scenario, RCM supports a concept of an SSH IP. The NSO-based solution does not use the SSH IP. However, for the FCS (3.0.0 and 21.25), there is a requirement to specify an SSH IP for the solution. Any address, including private, non-routable address will suffice. This address is configured as a secondary address on the management interface of the UPs. Also refer to the Prerequisites for Configuration Push section for a note on the SSH IP configuration requirements for the UP.

The following are examples of host-specific configurations for two Active UPs. These are pushed to the respective UPs.

The following are examples of host-specific configurations for RCM. This is pushed to the RCM.

The following is an example of a common configuration. This is pushed to all Active UPs and all Standby UPs.

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