Guest

Cisco RAN Management System Installation Guide, Release 5.2

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco RAN Management System Installation Guide, Release 5.2

Chapter Title

RMS Installation Tasks

Results

Updated:
July 5, 2017

Chapter: RMS Installation Tasks

RMS Installation Tasks

Perform these tasks to install the RMS software.

RMS Installation Procedure

The RMS installation procedure is summarized here with links to the specific tasks.

Step No.

Task

Link

Task Completion: Mandatory or Optional

1

Perform all prerequisite installations

Installation Prerequisites and Installing VMware ESXi and vCenter for Cisco RMS

Mandatory

2

Create the Open Virtual Application (OVA) descriptor file

Preparing the OVA Descriptor Files

Mandatory

3

Deploy the OVA package

Deploying the RMS Virtual Appliance

Mandatory

4

Configure redundant Serving nodes

RMS Redundant Deployment

Optional

5

Run the configure_PNR_hnbgw.sh and configure_PAR_hnbgw.sh script to configure the HNB gateway properties

HNB Gateway and DHCP Configuration

Mandatory if the HNB gateway properties were not included in the OVA descriptor file.

6

Optimize the VMs by upgrading the VM hardware version, upgrading the VM CPU and memory and upgrading the Upload VM data size

Optimizing the Virtual Machines

Mandatory

7

Perform a sanity check of the system

RMS Installation Sanity Check

Optional but recommended

8

Install RMS Certificates

Installing RMS Certificates

Mandatory

9

Configure the default route on the Upload and Serving nodes for TLS termination

Configuring Default Routes for Direct TLS Termination at the RMS

Optional

10

Install and configure the PMG database

PMG Database Installation and Configuration

Optional

Contact Cisco services to deploy PMG DB.

11

Configure the Central node

Configuring the Central Node

Mandatory

12

Populate the PMG database

Configuring the Central Node

Mandatory

13

Verify the installation

Verifying RMS Deployment

Optional but recommended

Preparing the OVA Descriptor Files

The RMS requires Open Virtual Application (OVA) descriptor files, more commonly known as configuration files, that specify the configuration of various system parameters.

The easiest way to create these configuration files is to copy the example OVA descriptor files that are bundled as part of RMS build deliverable itself. The RMS-ALL-In-One-Solution package contains the sample descriptor for all-in-one deployment and the RMS-Distributed-Solution package contains the sample descriptor for distributed deployment. It is recommended to use these sample descriptor files and edit them according to your needs.

Copy the files and rename them as ".ovftool" before deploying. You need one configuration file for the all-in-one deployment and three separate files for the distributed deployment.

When you are done creating the configuration files, copy them to the server where vCenter is hosted and the ovftool utility is installed. Alternately, they can be copied to any other server where the ovftool utility tool by VMware is installed. In short, the configuration files must be copied as ".ovftool" to the directory where you can run the VMware ovftool command.

The following are mandatory properties that must be provided in the OVA descriptor file. These are the bare minimum properties required for successful RMS installation and operation. If any of these properties are missing or incorrectly formatted, an error is displayed. All other properties are optional and configured automatically with default values.

Note

Make sure that all Network 1 (eth0) interfaces (Central, Serving, and Upload nodes) must be in same VLAN.

Only .txt and .xml formats support the copy of OVA descriptor file from desktop to Linux machine. Other formats such as .xlsx and .docx, store some garbage value when we copy to linux and throws an error during installation.

In csv file, if any comma delimiter present between two IPs, for example, prop:Upload_Node_Gateway=10.5.4.1,10.5.5.1, the property gets stored in double quotes when copied to Linux machine, "prop:Upload_Node_Gateway=10.5.4.1,10.5.5.1". This will throw an error during deployment.

Table 1 Mandatory Properties for OVA Descriptor File
Property Description Valid Values

name

Name of the vApp that is deployed on the host name.

text

datastore

Name of the physical storage to keep the VM files.

text

net:Upload-Node Network 1

VLAN for the connection between the Upload node (NB) and the Central node (SB).

VLAN #

net:Upload-Node Network 2

VLAN for the connection between the Upload node (SB) and the CPE network (FAPs).

VLAN #

net:Central-Node Network 1

VLAN for the connection between the Central node (SB) and Upload Load (NB) or Serving node (NB).

VLAN #

net:Central-Node Network 2

VLAN for the connection between the Central node (NB) and the OSS network.

VLAN #

net:Serving-Node Network 1

VLAN for the connection between the Serving node (NB) and the Central node (SB).

VLAN #

net:Serving-Node Network 2

VLAN for the connection between the Serving node (SoB) and the CPE network (FAPs).

VLAN #

prop:Central_Node_Eth0_Address

IP address of the Southbound VM interface

IPv4 address

prop:Central_Node_Eth0_Subnet

Network mask for the IP subnet of the Southbound VM interface.

Network mask

prop:Central_Node_Eth1_Address

IP address of the Northbound VM interface.

IPv4 address

prop:Central_Node_Eth1_Subnet

Network mask for the IP subnet of the Northbound VM interface.

Network mask

prop:Central_Node_Dns1_Address

IP address of primary DNS server provided by network administrator.

IPv4 address

prop:Central_Node_Dns2_Address

IP address of secondary DNS server provided by network administrator.

IPv4 address

prop:Central_Node_Gateway

IP address of the gateway to the management network for the north bound interface of the Central node.

IP address of the gateway from the Northbound interface of the Serving node towards the Central node southbound network and from the Southbound interface of the Serving node towards the CPE.

IPv4 address

prop:Serving_Node_Eth0_Address

IP address of the Northbound VM interface.

IPv4 address

prop:Serving_Node_Eth0_Subnet

Network mask for the IP subnet of the Northbound VM interface.

Network mask

prop:Serving_Node_Eth1_Address

IP address of the Southbound VM interface.

IPv4 address

prop:Serving_Node_Eth1_Subnet

Network mask for the IP subnet of the Southbound VM interface.

Network mask

prop:Serving_Node_Dns1_Address

IP address of primary DNS server provided by network administrator.

IPv4 address

prop:Serving_Node_Dns2_Address

IP address of secondary DNS server provided by network administrator.

IPv4 address

prop:Serving_Node_Gateway

IP address of the gateway to the management network.

comma separated IPv4 addresses of the form [Northbound GW],[Southbound GW]

Note    It is recommended to specify both the gateways.

prop:Upload_Node_Eth0_Address

IP address of the Northbound VM interface.

IPv4 address

prop:Upload_Node_Eth0_Subnet

Network mask for the IP subnet of the Northbound VM interface.

Network mask

prop:Upload_Node_Eth1_Address

IP address of the Southbound VM interface.

IPv4 address

prop:Upload_Node_Eth1_Subnet

Network mask for the IP subnet of the Southbound VM interface.

Network mask

prop:Upload_Node_Dns1_Address

IP address of primary DNS server provided by network administrator.

IPv4 address

prop:Upload_Node_Dns2_Address

IP address of secondary DNS server provided by network administrator.

IPv4 address

prop:Upload_Node_Gateway

IP address of the gateway from Northbound interface of the Upload node for northbound traffic and from Southbound interface of Upload node towards the CPE.

comma separated IPv4 addresses of the form [Northbound GW],[Southbound GW]

Note    It is recommended to specify both the gateways.

prop:Ntp1_Address

Primary NTP server.

IPv4 address

prop:Acs_Virtual_Fqdn

ACS virtual fully qualified domain name (FQDN). Southbound FQDN of the Serving node. For NAT based deployment, this can be set to public FQDN of the NAT.

This is the FQDN which the AP will use to communicate from RMS.

FQDN value

Note    The recommended value is FQDN. FQDN is required in case of a redundant setup.

prop:Upload_SB_Fqdn

Southbound FQDN of the Upload node. For NAT based deployment, this can be set to public FQDN of the NAT.

FQDN value

Note    The recommended value is FQDN. FQDN is required in case of a redundant setup.

prop:Central_Hostname

Configured host name of the Central node.

Character string; no periods (.) allowed

prop:Serving_Hostname

Configured host name of the Serving node.

Character string; no periods (.) allowed

prop:Upload_Hostname

Configured host name of the Upload node.

Character string; no periods (.) allowed

diskMode

Logical disk type of the VM.

Thin


Note

For third-party SeGW support for allocating inner IPs (tunnel IPs), set the property "prop:Install_Cnr=False" in the descriptor file.

Refer to OVA Descriptor File Properties for a complete description of all required and optional properties for the OVA descriptor files.

Validation of OVA Files

If mandatory properties are missing from a descriptor file, the OVA installer displays an error on the installation console. If mandatory properties are incorrectly configured, an appropriate error is displayed on the installation console and the installation aborts.

An example validation failure message in the ova-first-boot.log is shown here: 

"Alert!!! Invalid input for Acs_Virtual_Fqdn...Aborting installation..."

Log in to the relevant VM using root credentials (default password is Ch@ngeme1) to access the first-boot logs in the case of installation failures.

Wrongly configured properties include invalid IP addresses, invalid FQDN format, and so on. Validations are restricted to format/data-type validations. Incorrect IP addresses/FQDNs (for example, unreachable IPs) are not in the scope of validation.

Deploying the RMS Virtual Appliance

All administrative functions are available through vSphere client. A subset of those functions is available through the vSphere web client. The vSphere client users are virtual infrastructure administrators for specialized functions. The vSphere web client users are virtual infrastructure administrators, help desk, network operations centre operators, and virtual machine owners.


Note

All illustrations in this document are from the VMware vSphere client.

Before You Begin

You must be running VMware vSphere version v5.1, v5.5, or v6.0 . There are two ways to access the VMware Vcenter:

  • VMware vSphere Client locally installed application

  • VMware vSphere Web Client


Note

Verify that the sample descriptor file (sample_aio_descr_mandandoptional.txt) has a valid CAR license.

Edit the file using 'vi' editor and ensure that the descriptor property "prop:Car_License_Base" license is not expired.

Example: 
prop:Car_License_Base=INCREMENT PAR-NG-TPS cisco 7.0 17-may-2015 uncounted VENDOR_STRING=<count>1</count> 
HOSTID=ANY NOTICE="<LicFileID>20150518024936834</LicFileID><LicLineID>1</LicLineID> <PAK></PAK>" SIGN=753656C69E20

As in above example, if the license date has expired then provide a valid CPAR 7.0 license for this property in the .ovftool file (if the property is not present, add the property in the .ovftool file and provide a valid 7.0 license).

Procedure
    Step 1   Copy the OVA descriptor configuration files as ".ovftool" to the directory where you can run the VMware ovftool command.
    Note   

    If you are running from a Linux server, the .ovftool file should not be in the root directory as it takes precedence over other ".ovftool" files.

    While deploying the ova package, the home directory takes the preference over the current directory.

    Step 2   ./OVAdeployer.sh ova-filepath/ova-file vi://vcenter-user:password@vcenter-host/datacenter-name/host/host-folder-if-any/ucs-host


    Example: 
    ./OVAdeployer.sh /tmp/RMS-All-In-One-Solution-5.1.1-1H/RMS-All-In-One-Solution-5.1.1-1H.ova 
vi://myusername:mypass#1@blr-rms-vcenter1.cisco.com/BLR/host/UCS5K/blrrms-5108-09.cisco.com
./OVAdeployer.sh /tmp/RMS-Distributed-Solution-5.1.1-1H/RMS-Central-Node-5.1.1-1H.ova 
vi://myusername:mypass#1@blr-rms-vcenter1.cisco.com/BLR/host/UCS5K/blrrms-5108-09.cisco.com
    Note   

    The OVAdeployer.sh tool first validates the OVA descriptor file and then continues to install the RMS. If necessary, get the OVAdeployer.sh tool from the build package and copy it to the directory where the OVA descriptor file is stored.

    If the vCenter user or password (or both) is not specified in the command, you are prompted to enter this information on the command line. Enter the user name and password to continue.

    All-in-One RMS Deployment: Example

    In an all-in-one RMS deployment, all the nodes such as central, serving, and upload are deployed on a single host on the VSphere client.

    In an all-in-one RMS deployment, the Serving and Upload nodes should be synchronized with the Central node during first boot up. To synchronize these nodes, add the property "powerOn=False" in the descriptor file (.ovftool). 

    ./OVAdeployer.sh /data/ova/OVA_Files/RMS51/RMS-All-In-One-Solution-5.1.1-1H/RMS-All-In-One-Solution-5.1.1-1H.ova 
vi://root:vmware@10.105.246.84/HA/host/blrrms-c240-01.cisco.com/

Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are recommended to 
be in same VLAN for AIO/Distributed deployments with an exception for Geo Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
Starting input validation
Checking network configurations in descriptor...
Deploying OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-All-In-One-Solution-5.1.1-1H/RMS-All-In-One-Solution-5.1.1-1H.ova
The manifest does not validate
Opening VI target: vi://root@10.105.246.84:443/HA/host/blrrms-c240-01.cisco.com/
Deploying to VI: vi://root@10.105.246.84:443/HA/host/blrrms-c240-01.cisco.com/
Transfer Completed
Powering on vApp: BLR03-AIO-51H
Completed successfully
Wed 25 Mar 2015 11:00:01 AM IST
OVA deployment took 594 seconds.

    After OVA installation is completed, power on only the Central VM and wait until the login prompt appears on the VM console. Next, power on the Serving and Upload VMs and wait until the login prompt appears on the VM consoles.

    The RMS all-in-one deployment in the vCenter appears similar to this illustration:

    Figure 1. RMS All-In-One Deployment



    After all hosts are powered on and the login prompt appears on the VM consoles, only then proceed with the configuration changes (example, creating groups, replacing certificates, adding route, and so on). Else, the system bring-up may overwrite your changes.


    Note

    After installation if you see "unix_chkpwd[4773]: password check failed field for user (admin1)" error on the VMware vSphere client console on the Central node, ignore it.

    Distributed RMS Deployment: Example

    In the distributed deployment, RMS Nodes (Central node, Serving node, and Upload node) are deployed on different hosts on the VSphere client. The RMS nodes must be deployed and powered in the following sequence:

    1. Central Node
    2. Serving Node
    3. Upload Node

    Note

    Power on the Serving and Upload nodes after the Central node applications are up. To confirm this:

    1. Log in to the Central node after ten minutes (from the time the nodes are powered on).

    2. Switch to root user and look for the following message in the /root/ova-first-boot.log. 

      Central-first-boot script execution took [xxx] seconds

      For example, Central-first-boot script execution took 360 seconds.

    The .ovftool files for the distributed deployment differ slightly than that of the all-in-one deployment in terms of virtual host network values as mentioned in Preparing the OVA Descriptor Files. Here is an example of the distributed RMS deployment:

    Central Node Deployment

    ./OVAdeployer.sh /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Central-Node-5.1.1-1H.ova 
vi://root:vmware@10.105.246.84/HA/host/blrrms-c240-10.cisco.com

Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are recommended to 
be in same VLAN for AIO/Distributed deployments with an exception for Geo Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
Starting input validation
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Deploying OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Central-Node-5.1.1-1H.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
Completed successfully
Mon 16 Mar 2015 05:27:48 PM IST
OVA deployment took 155 seconds.

    ./OVAdeployer.sh /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Serving-Node-5.1.1-1H.ova 
vi://root:vmware@10.105.246.84/HA/host/blrrms-c240-10.cisco.com

Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are recommended to 
be in same VLAN for AIO/Distributed deployments with an exception for Geo Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
Starting input validation
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Deploying OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Serving-Node-5.1.1-1H.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
Completed successfully
Mon 16 Mar 2015 05:36:48 PM IST
OVA deployment took 139 seconds.
    ./OVAdeployer.sh /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Upload-Node-5.1.1-1H.ova 
vi://root:vmware@10.105.246.84/HA/host/blrrms-c240-10.cisco.com

Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are recommended to 
be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
Starting input validation
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Deploying OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Distributed-Solution-5.1.1-1H/RMS-Upload-

Node-5.1.1-1H.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/blrrms-c240-10.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
Completed successfully
Mon 16 Mar 2015 05:39:23 PM IST
OVA deployment took 50 seconds.

    The RMS distributed deployment in the vSphere appears similar to this illustration:

    Figure 2. RMS Distributed Deployment


    Note

    After installation if you see "unix_chkpwd[4773]: password check failed field for user (admin1)" error on the VMware vSphere client console on the Central node, ignore it.

    RMS Redundant Deployment

    This section describes RMS redundant deployment modes and RMS post deployment configuration procedures.

    Deploying an All-In-One Redundant Setup

    Complete the following steps for the all-in-one redundant deployment:

    Before You Begin

    Complete the following procedures provided in the High Availability for Cisco RAN Management Systems document before performing the following procedure.

    • Creating a High Availability Cluster

    • Adding Hosts to the High Availability Cluster

    • Adding NFS Datastore to the Host

    • Adding Network Redundancy for Hosts and Configuring vMotion

    Procedure
      Step 1   Ensure that you have the relevant sample AIO OVA descriptor (mandatory or mandatory and optional) files from the RMS-Redundant-Solution package.
      Step 2   Ensure that you have the relevant installers—OVAdeployer_redundancy.sh and OVAdeployer_redundant_template.sh—for redundant deployment.
      Step 3   Copy "sample_aio_descr_mandatory.txt" or "sample_aio_descr_mandandoptional.txt" as ".ovftool" and edit as per setup.

      Copy "sample_aio_descr_mandatory.txt" or "sample_aio_descr_mandandoptional.txt" as ".ovftoolhotstandby" and edit as per setup.

      Copy ".ovftool, .ovftoolhotstandby, .ovftoolredundantproperties" to the server where the "ovftool" utility is installed.

      Step 4   Edit the following descriptors:

      • .ovftool—Primary OVF descriptor for the node where all the primary components need to be deployed.

      • .ovftoolhotstandby—Hot standby OVF descriptor for the Serving node and Upload node components on hot standby.

      • .ovftoolredundantproperties—Priimary and hot standby properties that differ for datastore,vappname for redundant setup.

      Note    Descriptor file for primary and hot standby remains the same for all-in-one deployment having configured values.
      Step 5   Copy the deployment files "OVAdeployer_redundant_template.sh" to "OVAdeployer_redundant.sh" and edit the file that executes redundant deployment. 
      ./OVAdeployer_redundancy.sh [complete ova path(Central/Serving/Upload/All-in-one)] [VCenterURL]
[REDUNDANTDEPPLOYMENT(PRIMARY/HOTSTANDBY)]

      The example of the above format is given below:



      Example: 
      ./OVAdeployer_redundancy.sh /data/ovf/RMS51/HA-AIO-AUG/RMS-Redundant-Solution-5.1.1-199/RMS-Serving-Node-5.1.1-199.ova 
vi://rms-qa:cisco123@blr-rms-vcenter2.cisco.com/BLR1/host/HA-AIO-5108-user/blrrms-5108-03-05.cisco.com PRIMARY &&
./OVAdeployer_redundancy.sh /data/ovf/RMS51/HA-AIO-AUG/RMS-Redundant-Solution-5.1.1-199/RMS-Upload-Node-5.1.1-199.ova  
vi://rms-qa:cisco123@blr-rms-vcenter2.cisco.com/BLR1/host/HA-AIO-5108-user/blrrms-5108-03-05.cisco.com PRIMARY &&
./OVAdeployer_redundancy.sh /data/ovf/RMS51/HA-AIO-AUG/RMS-Redundant-Solution-5.1.1-199/RMS-Serving-Node-5.1.1-199.ova 
vi://rms-qa:cisco123@blr-rms-vcenter2.cisco.com/BLR1/host/HA-AIO-5108-user/blrrms-5108-03-06.cisco.com HOTSTANDBY &&
./OVAdeployer_redundancy.sh /data/ovf/RMS51/HA-AIO-AUG/RMS-Redundant-Solution-5.1.1-199/RMS-Upload-Node-5.1.1-199.ova  
vi://rms-qa:cisco123@blr-rms-vcenter2.cisco.com/BLR1/host/HA-AIO-5108-user/blrrms-5108-03-06.cisco.com HOTSTANDBY
#EOF-DONT-DELETE

      Note   

      New parameter PRIMARY/HOTSTANDY must be mentioned at the end of each command.

      Step 6   Execute the following command to install the OVA.

      Before deployment, ensure that the ".ovftool", ".ovftool_redundancy", and ".ovftoolredundantproperties" are present in the current directory.

      Use these commands to change the permission of the script:



      Example: 
      chmod +x ./OVAdeployer_redundant.sh;
chmod +x ./OVAdeployer_redundancy.sh

      Use the following command to deploy the OVA:



      Example: 
      ./OVAdeployer_redundant.sh
      Step 7   Detach the CD/DVD drive from the RMS nodes as follows:
      1. Log in to the vSphere Web Client and locate the Central node vAPP.
      2. In the Getting Started tab, click Power Off vApp.
      3. After power off, right-click on the Central node VM and click Edit Settings.
      4. Remove the CD/DVD drive 1 from the Virtual Hardware tab by clicking on the "X" symbol present in the same row.
      5. Click Ok to finish.
      6. Click Edit Settings and ensure that the CD/DVD drive 1 is removed.
      7. In the Getting Started tab, select the vApp of the VM and click Power On vApp.
      8. Repeat steps a to g on all the RMS nodes.
      Note    Ensure all the RMS nodes are up and running before proceeding to Step 8.
      Step 8   Run the multi-node script central-multi-nodes-config.sh on the Central node from the path cd /.

      This script takes an input configuration file that must contain the following properties for the redundant Serving and Upload nodes.

      Prepare an input configuration file with all the following properties for the redundant Serving and Upload nodes. For example, ovadescrip.txt.

      • Central_Node_Eth0_Address

      • Central_Node_Eth1_Address

      • Serving_Node_Eth0_Address

      • Serving_Node_Eth1_Address

      • Upload_Node_Eth0_Address

      • Upload_Node_Eth1_Address

      • Serving_Hostname

      • Upload_Hostname

      • Acs_Virtual_Fqdn

      • Upload_SB_Fqdn

      Example: 

      [RMS51G-CENTRAL03] / # ./central-multi-nodes-config.sh ovadescrip.txt
Deployment Descriptor file ovadescrip.txt found, continuing

Central_Node_Eth0_Address=10.1.0.16
Central_Node_Eth1_Address=10.105.246.53
Serving_Node_Eth0_Address=10.4.0.14
Serving_Node_Eth1_Address=10.5.0.23
Upload_Node_Eth0_Address=10.4.0.15
Upload_Node_Eth1_Address=10.5.0.24
Serving_Node_Hostname=RMS51G-SERVING05
Upload_Node_Hostname=RMS51G-UPLOAD05
Upload_SB_Fqdn=femtouls.testlab.com
Acs_Virtual_Fqdn=femtoacs.testlab.com


Verify the input, Press Cntrl-C to exit
Script will start executing in next 15 seconds
...
......10 more seconds to execute
.........5 more seconds to execute
begin configure_iptables
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
end configure_iptables
begin configure_system
end configure_system
begin configure_files
end configure_files
Script execution completed.
Verify entries in following files:
/etc/hosts
/rms/app/rms/conf/uploadServers.xml
      Step 9   In redundant Serving node, update the following dpe.properties.

      Example: 

      [root@setup29-serving2 admin1]# vi /rms/app/CSCObac/dpe/conf/dpe.properties
/server/log/2/level=Info
/server/log/perfstat/enable=enabled
/server/log/trace/dpeext/enable=enabled
/server/log/trace/dpeserver/enable=enabled
/chattyclient/service/enable=disabled

save the file.
restart dpe.
[root@setup29-serving2 admin1]# /etc/init.d/bprAgent restart dpe
      Step 10   Complete the procedures listed in the Post RMS Redundant Deployment section.
      What to Do Next

      Complete the "Testing High Availability on the Central Node and vCenter VM" procedure provided in the High Availability for Cisco RAN Management Systems document:

      All-In-One Redundant Deployment: Example

      ./OVAdeployer_redundant.sh
Starting input validation
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are 

recommended to be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are 

recommended to be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are 

recommended to be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftool
Converting OVA descriptor to unix format..
Checking deployment type
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are 

recommended to be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftoolhotstandby
Converting OVA descriptor to unix format..
Checking deployment type
prop:Admin1_Password not provided, will be taking the default value for RMS.
prop:RMS_App_Password not provided, will be taking the default value for RMS.
prop:Root_Password not provided, will be taking the default value for RMS.
Starting OVA installation. Network 1(eth0) interface of Central/Serving/Upload Nodes are 

recommended to be in same VLAN for AIO/Distributed deployments with an exception for Geo 

Redundant Setups...
Reading OVA descriptor from path: ./.ovftoolhotstandby
Converting OVA descriptor to unix format..
Checking deployment type
Converting OVA descriptor to unix format..
Deploying Central Node OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Redundant-Solution-5.1.0-1G/RMS-Central-

Node-5.1.0-1G.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-

01.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-01.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
 - OVF property with key: 'Acs_Virtual_Address' does not exists.
Completed successfully
Mon 02 Mar 2015 06:22:50 PM IST
OVA deployment took 276 seconds.
Converting OVA descriptor to unix format..
Deploying Serving node OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Redundant-Solution-5.1.0-1G/RMS-Serving-

Node-5.1.0-1G.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-

01.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-01.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
 - OVF property with key: 'Acs_Virtual_Address' does not exists.
Completed successfully
Mon 02 Mar 2015 06:26:53 PM IST
OVA deployment took 519 seconds.
Converting OVA descriptor to unix format..
Deploying upload node OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Redundant-Solution-5.1.0-1G/RMS-Upload-

Node-5.1.0-1G.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-

01.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-01.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
 - OVF property with key: 'Acs_Virtual_Address' does not exists.
Completed successfully
Mon 02 Mar 2015 06:28:49 PM IST
OVA deployment took 635 seconds.
Converting OVA descriptor to unix format..
Deploying Secondary Serving node OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Redundant-Solution-5.1.0-1G/RMS-Serving-

Node-5.1.0-1G.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-

10.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-10.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
 - OVF property with key: 'Acs_Virtual_Address' does not exists.
Completed successfully
Mon 02 Mar 2015 06:36:16 PM IST
OVA deployment took 1082 seconds.
Converting OVA descriptor to unix format..
Deploying secondary upload node OVA...
Opening OVA source: /data/ova/OVA_Files/RMS51/RMS-Redundant-Solution-5.1.0-1G/RMS-Upload-

Node-5.1.0-1G.ova
The manifest validates
Opening VI target: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-

10.cisco.com
Deploying to VI: vi://root@10.105.246.84:443/HA/host/AIO_REDUNDANCY/blrrms-c240-10.cisco.com
Transfer Completed
Warning:
 - No manifest entry found for: '.ovf'.
 - File is missing from the manifest: '.ovf'.
 - OVF property with key: 'Acs_Virtual_Address' does not exists.
Completed successfully
Mon 02 Mar 2015 06:38:52 PM IST
OVA deployment took 1238 seconds.

      Migrating from a Non-Redundant All-In-One to a Redundant Setup

      Before You Begin

      • ACS URL should mandatorily be an FQDN in an existing all-in-one setup.

      • All-in-one installation should exist in the cluster configuration.

      Procedure
        Step 1   Complete the following procedures provided in the High Availability for Cisco RAN Management Systems document:

        • Updating Cluster Configuration

        • Adding NFS Datastore to the Host

        • Adding Network Redundancy for Hosts and Configuring vMotion

        Note   

        There will be a downtime on the nodes as the host movement to the cluster will only be possible by powering off the VMs in a host.

        Step 2   Add the Southbound IP of the secondary Serving and Upload nodes to the FQDN already in use.
        Step 3   Proceed to install the secondary/standby Serving and Upload nodes based on the following procedure:

        Use the OVAdeployer.sh and the descriptors from the RMS-Distributed-Solution-5.1.0-1x package.

        1. Prepare a distributed installation descriptor file for the secondary Serving and Upload nodes separately using the Preparing the OVA Descriptor Files procedure.
        2. Proceed with the distributed redundant installation using the Deploying the Distributed Redundant Setup procedure.
        Step 4   Complete all the procedures listed in the Post RMS Redundant Deployment section.
        Step 5   Complete the following post OVA installation procedures listed in the High Availability for Cisco RAN Management Systems document:

        • Updating Cluster Configuration

        • Migrating Central node to the NFS datastore

        Step 6   Verify the high availability on the Central node and vCenter VM in the newly formed setup using the "Testing High Availability on the Central Node and vCenter VM" procedure provided in the High Availability for Cisco RAN Management Systems document.
        Step 7   Add the appropriate certificates (copy the same dpe.keystore and uls.keystore from primary Serving and Upload nodes) to the newly installed secondary or standby Serving and Upload nodes.
        Step 8   Execute the configure_PNR_hnbgw.sh and configure_PAR_hnbgw.sh scripts from /rms/ova/scripts/post_install/HNBGW directory as mentioned in the Installation Tasks Post-OVA Deployment section to configure the HNB GW details on the secondary or standby PNR and PAR.
        Step 9   Verify the provisioning of an existing AP and a newly registered AP with two Serving and Upload nodes on successful completion of the previous steps.

        Deploying the Distributed Redundant Setup

        To mitigate Serving node and Upload Server Node deployment failover, additional Serving and Upload nodes can be configured with the same Central node.

        This procedure describes how to configure additional Serving and Upload nodes with an existing Central node.


        Note

        Redundant deployment does not mandate having both Serving and Upload nodes together. Each redundant node can be deployed individually without having the other node in the setup.

        Before You Begin

        • It is mandatory for the ACS URL and Upload URL (Upload_SB_Fqdn and Acs_Virtual_Fqdn) to be an FQDN before deploying a distributed redundant setup.

        • The ACS and Upload FQDN should be the same on both Serving and Upload nodes respectively. Example, prop:Acs_Virtual_Fqdn=femtoacs.testlab.com and prop:Upload_SB_Fqdn=femtouls.testlab.com

        Procedure
          Step 1   Prepare the deployment descriptor (.ovftool file) for any additional Serving nodes as described in Preparing the OVA Descriptor Files.

          For Serving node redundancy, the descriptor file should have the same provisioning group as the primary Serving node.

          For an example on redundant OVA descriptor file, refer to Example Descriptor File for Redundant Serving/​Upload Node.

          The following properties are different in the redundant Serving node and redundant Upload node descriptor files:

          Redundant Serving Node:

          • name

          • Serving_Node_Eth0_Address

          • Serving_Node_Eth1_Address

          • Serving_Hostname

          • Dpe_Cnrquery_Client_Socket_Address (should be same as Serving_Node_Eth0_Address)

          • Serving_Node_Eth0_Subnet

          • Serving_Node_Eth1_Subnet

          • Serving_Node_Gateway

          • Upload_Node_Eth0_Address

          • Upload_Node_Eth0_Subnet

          • Upload_Node_Eth1_Address

          • Upload_Node_Eth1_Subnet

          • Upload_Node_Dns1_Address

          • Upload_Node_Dns2_Address

          • Upload_Node_Gateway

          • Upload_SB_Fqdn

          • Upload_Hostname

          Redundant Upload Node:

          • name

          • Upload_Node_Eth0_Address

          • Upload_Node_Eth1_Address

          • Upload_Hostname

          • Dpe_Cnrquery_Client_Socket_Address (should be same as Serving_Node_Eth0_Address)

          • Upload_Node_Eth0_Subnet

          • Upload_Node_Eth1_Subnet

          • Upload_Node_Gateway

          • Serving_Node_Eth0_Address

          • Serving_Node_Eth0_Subnet

          • Serving_Node_Eth1_Address

          • Serving_Node_Eth1_Subnet

          • Serving_Node_Dns1_Address

          • Serving_Node_Dns2_Address

          • Serving_Node_Gateway

          • Serving_Hostname

          Step 2   Run a multi-node script on the Central node before deploying the redundant Serving node and redundant Upload node.

          This script takes an input configuration file that must contain the following properties for the redundant Serving and Upload nodes.

          Prepare an input configuration file with all the following properties for the redundant Serving and Upload nodes and name it appropriately. For example, ovadescriptorfile_CN_Config.txt.

          • Central_Node_Eth0_Address

          • Central_Node_Eth1_Address

          • Serving_Node_Eth0_Address

          • Serving_Node_Eth1_Address

          • Upload_Node_Eth0_Address

          • Upload_Node_Eth1_Address

          • Serving_Hostname

          • Upload_Hostname

          • Acs_Virtual_Fqdn

          • Upload_SB_Fqdn

          Step 3   Copy and upload the above ovf file ovadescriptorfile_CN_Config.ovf and save it as .txt (ovadescriptorfile_CN_Config.txt) on the Central node at / directory.
          Step 4   Take a back up of the /rms/app/rms/conf/uploadServers.xml and /etc/hosts using these commands:

          cp /etc/hosts /etc/hosts_orig

          cp /rms/app/rms/conf/uploadServers.xml /rms/app/rms/conf/uploadServers.xml_orig

          Step 5   Execute as "root" user the utility shell script (central-multi-nodes-config.sh) to configure the network and application properties on the Central node.

          The script is located in the / directory. The above copied configuration text file ovadescriptorfile_CN_Config.txt should be given as input to the shell script.



          Example: 
          ./central-multi-nodes-config.sh <deploy-decsr-filename>

          After execution of the script, a new fqdn/ip entry for the new Upload Server node is created in the /rms/app/rms/conf/uploadServers.xml file.



          Example: 
          [RMS51G-CENTRAL03] / # ./central-multi-nodes-config.sh ovadescrip.txt
Deployment Descriptor file ovadescrip.txt found, continuing

Central_Node_Eth0_Address=10.1.0.16
Central_Node_Eth1_Address=10.105.246.53
Serving_Node_Eth0_Address=10.4.0.14
Serving_Node_Eth1_Address=10.5.0.23
Upload_Node_Eth0_Address=10.4.0.15
Upload_Node_Eth1_Address=10.5.0.24
Serving_Node_Hostname=RMS51G-SERVING05
Upload_Node_Hostname=RMS51G-UPLOAD05
Upload_SB_Fqdn=femtouls.testlab.com
Acs_Virtual_Fqdn=femtoacs03.testlab.com


Verify the input, Press Cntrl-C to exit
Script will start executing in next 15 seconds
...
......10 more seconds to execute
.........5 more seconds to execute
begin configure_iptables
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
end configure_iptables
begin configure_system
end configure_system
begin configure_files
end configure_files
Script execution completed.
Verify entries in following files:
/etc/hosts
/rms/app/rms/conf/uploadServers.xml
          Step 6   Create an individual ovf file based on the redundant Serving node or Upload node as described in Step 1 and use the same for deployment. Install additional Serving and Upload nodes as described in Deploying the RMS Virtual Appliance.
          Complete the following procedures before proceeding to the next step:
          Step 7   Specify route and IPtable configurations to establish a proper inter-node communication after deploying redundant Serving and Upload nodes based on the subnet of the new nodes. For configuring geo-redundant Serving and Upload nodes, see Configuring Serving and Upload Nodes on Different Subnets.
          Step 8   Configure the Serving node redundancy as described in Configuring Redundant Serving Nodes.
          Note    Redundant Upload node needs no further configuration.

          Post RMS Redundant Deployment

          This section covers the procedures required to be performed after RMS deployment.

          Configuring Serving and Upload Nodes on Different Subnets


          Note
          This section is applicable only if the Serving and Upload nodes have eth0 (NB) interface on a different subnet than that of the Central server eth0 IP.

          In a multi-site configuration, due to geo-redundancy the Serving and Upload server on site2 (redundant site) can be deployed with eth0/eth1 IPs being on a different subnet compared to the eth0/eth1 IPs of site1 Central, Serving, and Upload servers. In such cases, a post-installation script must be executed on site2 Serving and Upload servers. Follow the procedure to execute this post-installation script.

          In a geo-redundant setup, Serving and Upload nodes can be deployed in a different geographical location with IPs (eth0/eth1) in different subnets compared to that of the Central server (eth0/eth1) IP. In such cases, a post-installation script must be executed on the Serving and Upload nodes. Follow this procedure to execute this post-installation script.

          Procedure
            Step 1   Follow these steps on the Serving node deployed in a different subnet:
            1. Post RMS installation, configure appropriate routes on Serving node to communicate with the Central node. For more information, see Enabling Communication for VMs on Different Subnets.
              Note   

              Start the VM first if the powerOn is set to 'false' in the descriptor file. Else adding routes is not possible.

            2. Log in to the Serving node as admin user from the Central node.
            3. Switch to root user using the required credentials.
            4. Navigate to /rms/ova/scripts/post_install/.
            5. Copy the Serving node OVA descriptor to a temporary directory or /home/admin1 and specify the complete path during script execution.
            6. Switch back to post_install directory: /rms/ova/scripts/post_install/
            7. Run the following commands: 
              chmod +x redundant-serving-config.sh;
   ./redundant-serving-config.sh <diff_subnet_serving_ova_descriptor_filepath>
              Example: 
              [root@blrrms-serving-19-2 post_install]# ./redundant-serving-config.sh ovftool_serving2
Deployment Descriptor file ovftool_serving2 found, continuing

INFO: Admin1_Username has no value, setting to default

Enter Password for admin user  admin1 on Central Node:
Confirm admin1 Password:
Enter Password for root on Central Node:
Confirm root Password: Function validateinputs starts at  1424262225

INFO: RMS_App_Password has no value, setting to default
INFO: Bac_Provisioning_Group has no value, setting to default
INFO: Ntp2_Address has no value, setting to default
INFO: Ntp3_Address has no value, setting to default
INFO: Ntp4_Address has no value, setting to default
INFO: Ip_Timing_Server_Ip has no value, setting to default
Starting ip input validation
Done ip input validation
Central_Node_Eth0_Address=10.5.1.208
Serving_Node_Eth1_Address=10.5.5.68
Upload_Node_Eth1_Address=10.5.5.69
Upload_SB_Fqdn=femtolus19.testlab.com
Acs_Virtual_Fqdn=femtoacs19.testlab.com

USEACE=
Admin1_Username=admin1
Bac_Provisioning_Group=pg01
Ntp1_Address=10.105.233.60
Ntp2_Address=10.10.10.2
Ntp3_Address=10.10.10.3
Ntp4_Address=10.10.10.4
Ip_Timing_Server_Ip=10.10.10.4

Verify the input, Press Cntrl-C to exit
Script will start executing in next 15 seconds
...
......10 more seconds to execute
.........5 more seconds to execute
Function configure_dpe_certs starts at  1424262242
Setting RMS CA signed DPE keystore
spawn scp admin1@10.5.1.208:/rms/data/rmsCerts/dpe.keystore /rms/app/CSCObac/dpe/conf/dpe.keystore
The authenticity of host '10.5.1.208 (10.5.1.208)' can't be established.
RSA key fingerprint is d5:fc:1a:af:c8:e0:f7:3a:10:10:4b:22:b6:3c:f2:95.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.5.1.208' (RSA) to the list of known hosts.
yes
admin1@10.5.1.208's password:
Permission denied, please try again.
admin1@10.5.1.208's password:
dpe.keystore                                                                                                                                                       100% 3959     3.9KB/s   00:00
Performing additional DPE configurations..
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

blrrms-serving-19-2 BAC Device Provisioning Engine


User Access Verification

Password:

blrrms-serving-19-2> enable
Password:
blrrms-serving-19-2# log level 6-info
% OK
.
.
.

File: ../ga_kiwi_scripts/addBacProvisionProperties.kiwi
Finished tests in 13990ms
Total Tests Run    - 16
Total Tests Passed - 16
Total Tests Failed - 0
Output saved in file: /tmp/runkiwi.sh_root/addBacProvisionProperties.out.20150218_1755

__________________________________________________________________________________________

Post-processing log for benign error codes: /tmp/runkiwi.sh_root/addBacProvisionProperties.out.20150218_1755

Revised Test Results
  Total Test Count: 16
      Passed Tests: 16
   Benign Failures: 0
  Suspect Failures: 0

Output saved in file: /tmp/runkiwi.sh_root/addBacProvisionProperties.out.20150218_1755-filtered
~
[blrrms-central-19] ~ # Done provisioning group configuration
[root@blrrms-serving-19-2 post_install]#

            Step 2   Follow these steps on the Upload node deployed in a different subnet:
            1. Log in to the Upload server (having its IPs in a different subnet) as admin user.
            2. Switch to root user using the required credentials.
            3. Navigate to /rms/ova/scripts/post_install/.
            4. Copy the different subnet Upload server OVA descriptor file to a temporary location or home directory and use this path during script execution.
            5. Run the following commands to execute the script: 
              chmod +x redundant-upload-config.sh;
   ./redundant-upload-config.sh <diff_subnet_upload_ova_descriptor_filepath>
              Example: 
              [root@blr-blrrms-lus-19-2 post_install]# ./redundant-upload-config.sh /home/admin1/ovftool_upload2
Deployment Descriptor file /home/admin1/ovftool_upload2 found, continuing

INFO: Admin1_Username has no value, setting to default

Enter Password for admin user  admin1 on Central Node:
Confirm admin1 Password: Function validateinputs starts at  1424263071

Starting ip input validation
Done ip input validation
Central_Node_Eth0_Address=10.5.1.208
Upload_Node_Eth0_Address=10.5.4.69
Admin1_Username=admin1

Verify the input, Press Cntrl-C to exit
Script will start executing in next 15 seconds
...
......10 more seconds to execute
.........5 more seconds to execute
Function configure_dpe_certs starts at  1424263088
Setting RMS CA signed LUS keystore
spawn scp admin1@10.5.1.208:/rms/data/rmsCerts/uls.keystore /opt/CSCOuls/conf/uls.keystore
The authenticity of host '10.5.1.208 (10.5.1.208)' can't be established.
RSA key fingerprint is d5:fc:1a:af:c8:e0:f7:3a:10:10:4b:22:b6:3c:f2:95.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.5.1.208' (RSA) to the list of known hosts.
yes
admin1@10.5.1.208's password:
Permission denied, please try again.
admin1@10.5.1.208's password:
uls.keystore                                                                                                                                                       100% 3960     3.9KB/s   00:00
[root@blr-blrrms-lus-19-2 post_install]#

            Note that the scripts can be rerun if any error is observed. For example, wrong password input for admin user/root.

            Configuring Fault Manager Server for Central and Upload Nodes on Different Subnets

            Follow these steps on the Central and Upload nodes deployed in a different subnet to manually add IPtable rules on each node to ensure communication between all nodes:


            Note

            The following steps must be performed on the VM console of the Central and Upload nodes.

            Procedure
              Step 1   On Central node:
              1. Delete the existing IPtables that were added as part of the first boot script on the Central node. 
                iptables -D INPUT -p tcp -i eth0 -s <Upload_Node_Eth0_Address from ovfenv> -d 
<Central_Node_Eth0_Address from ovfenv>  --dport 8084 -m state --state NEW -j ACCEPT

iptables -D OUTPUT -p tcp -o eth0 -s <Central_Node_Eth0_Address from ovfenv> -d 
<Upload_Node_Eth0_Address from ovfenv>  --sport 8084 -m state --state NEW -j ACCEPTT
              2. Add the new IPtable rules by specifying the new subnet IPs on the Central node. 
                iptables -A INPUT -p tcp -i eth0 -s <new subnet IP of Upload_Node_Eth0 interface> -d 
<Central_Node_Eth0_Address>  --dport 8084 -m state --state NEW -j ACCEPT
 
iptables -A OUTPUT -p tcp -o eth0 -s < new subnet IP of Central_Node_Eth0 interface> -d 
<Upload_Node_Eth0_Address>  --sport 8084 -m state --state NEW -j ACCEPT
              3. Save the changes on the Central node by using the following command. 
                - service iptables save
              4. Restart IPtables on the Central node by using the following command. 
                 - service iptables restart
              Step 2   On Upload node:
              1. Delete the existing IPtables that were added as part of the first boot script on the Upload node. 
                iptables -D OUTPUT -p tcp -o eth0 -s <Upload_Node_Eth0_Address from ovfenv> -d 
<Central_Node_Eth0_Address from ovfenv> --dport 8084 -m state --state NEW -j ACCEPT

iptables -D INPUT -p tcp -i eth0 -s <Central_Node_Eth0_Address from ovfenv> -d 
<Upload_Node_Eth0_Address from ovfenv> --sport 8084 -m state --state NEW -j ACCEPT
              2. Add the new IPtables rules by specifying the new interface IPs on the Upload node. 
                iptables -A OUTPUT -p tcp -o eth0 -s <new subnet IP of Upload_Node_Eth0 interface> 
-d <new subnet IP of Central_Node_Eth0 interface> --dport 8084 -m state --state 
NEW -j ACCEPT

iptables -A INPUT -p tcp -i eth0 -s <new subnet IP of Central_Node_Eth0 interface> -d 
<new subnet IP of Upload_Node_Eth0 interface> --sport 8084 -m state --state NEW -j ACCEPT
              3. Repeat Steps 2a and b for other Upload nodes if it is a redundant deployment.
              4. Save the changes on the Upload node by using the following command. 
                - service iptables save
              5. Restart Ptables on the Upload node by using the following command. 
                 - service iptables restart

              Configuring Fault Manager Server for Redundant Upload Node

              During Central node installation, IPtables for enabling communication between the Central node and Upload server are added for the first upload server (whose IPs are present in the Central node descriptor file). If there are redundant Upload servers, follow these steps on the Central node to manually add IPtable rules to enable communication between the Central node and redundant Upload nodes.

              Procedure
                Step 1   Log in to the Central node as admin user.
                Step 2   Switch to root user.
                Step 3   Add the below IPtable entries with the Central node and redundant Upload server IPs to allow communication between them (repeat this step for all the redundant Upload nodes). 
                iptables -A INPUT -p tcp -i eth0 -s <Redundant_Upload_Node_Eth0_Address> -d 
<Central_Node_Eth0_Address> --dport 8084 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 -s <Central_Node_Eth0_Address> -d 
<Redundant_Upload_Node_Eth0_Address> --sport 8084 -m state --state NEW -j ACCEPT


                Example: 
                iptables -A INPUT -p tcp -i eth0 -s 10.4.0.12 -d 10.1.0.10 --dport 8084 -m state 
--state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 -s 10.1.0.10 -d 10.4.0.12 --sport 8084 -m state --state 
NEW -j ACCEPT
                Step 4   Save the changes on the Central node by using the following command: 
                service iptables save
                Step 5   Restart IPtables on the Central node by using the following command: 
                service iptables restart

                Configuring Redundant Serving Nodes

                The RMS Serving nodes are configured as redundant pairs using the redundant-serving-pnr-config.sh script.

                After the installation of primary and secondary serving node, script will be found under the location /rms/ova/scripts/redundancy/ for both primary and secondary Serving nodes

                The redundant-serving-pnr-config.sh script configures the following on the primary and secondary Serving node:

                • Deletes any existing IPtable firewall rules for the ports

                • Creates or updates the IPtable firewall rules.

                • Creates or updates the IPtable firewall rules for the ports 61610 , 61611 , 1234 , and 647.

                • Configures PNRs for redundancy.

                The following sections describe how to configure and verify redundancy on the primary and secondary Serving node or PNR.
                Configuring Primary Serving Node or PNR Redundancy
                Procedure
                  Step 1   Log in to the primary Serving Node as 'admin' user. 
                  ssh <Primary_Serving_Node_eth0_IP>
                  Step 2   Change to root user: su-
                  Step 3   Navigate to the directory /rms/ova/scripts/redundancy/. Update the IP table firewall rules on the primary Serving node to enable the Serving nodes to communicate.
                  Step 4   Input the values as per the setup details for the Serving nodes as eth0/eth1 IPs and save the file. 
                  # Sample Input File for Redundant Serving node configuration

Serving_Node_Primary_Eth0_Address=10.5.1.24
Serving_Node_Secondary_Eth0_Address=10.5.1.20
Serving_Node_Primary_Eth1_Address=10.5.2.24
Serving_Node_Secondary_Eth1_Address=10.5.2.20
                  Step 5   Run the redundancy configuration script, "redundant-serving-pnr-config.sh" as follows: 
                  Redundant-serving-pnr-config.sh –i input_file

                  The script prompts the user with the option, “Is the current serving node acting as the primary serving node for RMS Redundancy setup ? [y/n]”. Answer with “y” because the script is executed on the primary Serving node. The script then prompts to specify the 'cnradmin' password.



                  Example: 
                  [root@blrrms-serving-1]#cd /rms/ova/scripts/redundancy/
[root@blrrms-serving-1]#chmod +x redundant-serving-pnr-config.sh
[[root@blrrms-serving-14-2I redundancy]# ./redundant-serving-pnr-config.sh -i config.redundancy 
User : root

Detected RMS Serving Node .
Serving_Node_Primary_Eth0_Address=10.5.1.68
Serving_Node_Primary_Eth1_Address=10.5.2.68
Serving_Node_Secondary_Eth0_Address=10.5.1.72
Serving_Node_Secondary_Eth1_Address=10.5.2.72
Is the current serving node acting as the primary serving node for RMS Redundancy setup ? [y/n] 
y
Configuring Firewall
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
Configuring the PNR for Redundancy
Enter cnradmin Password: 109 Ok - resource status is Critical: 1, OK: 8
session:
    cluster = localhost
    current-view = Default
    current-vpn = global
    default-format = user
    dhcp-edit-mode = synchronous
    dns-edit-mode = synchronous
    groups = superuser
    roles = superuser
    user-name = cnradmin
    visibility = 5
nrcmd> ###############################################################################

nrcmd> #

nrcmd> # csrc_cnr_enable_extpts.nrcmd

nrcmd> # This is a configuration script to be run in Network Registrar's nrcmd.

nrcmd> # This script enables the CSRC BPR CNR extension points.  It is mandatory that

nrcmd> # this script be run prior to running CSRC BPR.  Modify the reference to

nrcmd> # CSRC_HOME to point to a valid CSRC BPR home directory (don't forget to

nrcmd> # backquote the directory seperators).
.
.
.

nrcmd> 
nrcmd> # Display results

nrcmd> extension list
100 Ok - 3 objects found
dexdropras:
    entry = dexdropras
    file = libdexextension.so
    init-args = 
    init-entry = 
    lang = Dex
    name = dexdropras
extclientid:
    entry = clientID_trace
    file = libtrace_clientid.so
    init-args = 
    init-entry = 
    lang = Dex
    name = extclientid
preClientLookup:
    entry = bprClientLookup
    file = libbprextensions.so
    init-args = BPR_HOME=/rms/app/CSCObac,BPR_DATA=/rms/data/CSCObac
    init-entry = bprInit
    lang = Dex
    name = preClientLookup

nrcmd> dhcp listExtensions
100 Ok
post-packet-decode:      1 dexdropras
                         2 extclientid
pre-packet-encode: 
pre-client-lookup: preClientLookup
post-client-lookup: 
post-send-packet: 
pre-dns-add-forward: 
check-lease-acceptable: 
post-class-lookup: 
lease-state-change: 
generate-lease: 
environment-destructor: 
pre-packet-decode: 
post-packet-encode: 

nrcmd> 
nrcmd> # Save

nrcmd> save
100 Ok

nrcmd> 109 Ok - resource status is Critical: 1, OK: 8
100 Ok
109 Ok - resource status is Critical: 1, OK: 8
PNR console output logged in 'pnr-console-out.log' file
Done
                  Configuring Secondary Serving Node or PNR Redundancy
                  Procedure
                    Step 1   Log in to the secondary Serving Node as 'admin' user. 
                    ssh <Secondary_Serving_Node_eth0_IP>
                    Step 2   Change to root user: su-
                    Step 3   Navigate to the directory /rms/ova/scripts/redundancy/. Open and edit the sample input file "config.redundancy". 
                    # Sample Input File for Redundant Serving node configuration

Serving_Node_Primary_Eth0_Address=10.5.1.24
Serving_Node_Secondary_Eth0_Address=10.5.1.20
Serving_Node_Primary_Eth1_Address=10.5.2.24
Serving_Node_Secondary_Eth1_Address=10.5.2.20
                    Step 4   Input the values as per the setup details for the Serving nodes as eth0/eth1 IPs and save the file.
                    Step 5   Run the redundancy configuration script, "redundant-serving-pnr-config.sh" as follows: 
                    Redundant-serving-pnr-config.sh –I <input_file>

                    The script prompts the user with the option, “Is the current serving node acting as the primary serving node for RMS Redundancy setup ? [y/n]”. Answer with "n" because the script is executed on the secondary Serving node. The script then prompts to specify the 'cnradmin' password.



                    Example: 
                    [root@blr-rms15-serving redundancy]# ./redundant-serving-pnr-config.sh -i config.redundancy 
User : root

Detected RMS Serving Node .
Serving_Node_Primary_Eth0_Address=10.5.1.68
Serving_Node_Primary_Eth1_Address=10.5.2.68
Serving_Node_Secondary_Eth0_Address=10.5.1.72
Serving_Node_Secondary_Eth1_Address=10.5.2.72
Is the current serving node acting as the primary serving node for RMS Redundancy setup ? [y/n] 
n
Configuring Firewall
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
Configuring the PNR for Redundancy

Enter cnradmin Password: 109 Ok - resource status is Critical: 1, OK: 8
session:
    cluster = localhost
    current-view = Default
    current-vpn = global
    default-format = user
    dhcp-edit-mode = synchronous
    dns-edit-mode = synchronous
    groups = superuser
    roles = superuser
    user-name = cnradmin
    visibility = 5
nrcmd> ###############################################################################

nrcmd> #

nrcmd> # csrc_cnr_enable_extpts.nrcmd

nrcmd> # This is a configuration script to be run in Network Registrar's nrcmd.

nrcmd> # This script enables the CSRC BPR CNR extension points.  It is mandatory that

nrcmd> # this script be run prior to running CSRC BPR.  Modify the reference to

nrcmd> # CSRC_HOME to point to a valid CSRC BPR home directory (don't forget to

nrcmd> # backquote the directory seperators).
.
.
.

nrcmd> 
nrcmd> # Display results

nrcmd> extension list
100 Ok - 3 objects found
dexdropras:
    entry = dexdropras
    file = libdexextension.so
    init-args = 
    init-entry = 
    lang = Dex
    name = dexdropras
extclientid:
    entry = clientID_trace
    file = libtrace_clientid.so
    init-args = 
    init-entry = 
    lang = Dex
    name = extclientid
preClientLookup:
    entry = bprClientLookup
    file = libbprextensions.so
    init-args = BPR_HOME=/rms/app/CSCObac,BPR_DATA=/rms/data/CSCObac
    init-entry = bprInit
    lang = Dex
    name = preClientLookup

nrcmd> dhcp listExtensions
100 Ok
post-packet-decode:      1 dexdropras
                         2 extclientid
pre-packet-encode: 
pre-client-lookup: preClientLookup
post-client-lookup: 
post-send-packet: 
pre-dns-add-forward: 
check-lease-acceptable: 
post-class-lookup: 
lease-state-change: 
generate-lease: 
environment-destructor: 
pre-packet-decode: 
post-packet-encode: 

nrcmd> 
nrcmd> # Save

nrcmd> save
100 Ok

nrcmd> 109 Ok - resource status is Critical: 1, OK: 8
100 Ok
109 Ok - resource status is Critical: 1, OK: 8
PNR console output logged in 'pnr-console-out.log' file
Done
                    Verifying Secondary Serving Node or PNR Redundancy
                    Procedure
                      Step 1   Log in to the secondary Serving Node as 'admin' user. 
                      ssh <Secondary_Serving_Node_eth0_IP>
                      Step 2   Change to root user: su-
                      Step 3   Log in to the PNR prompt using the following command and enter the password when prompted: 
                      /rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin
                      Step 4   Verify that the primary and secondary Serving nodes are communicating with each other in a redundant setup using the following command. 
                      nrcmd> dhcp getRelatedServers

                      In the output, verify that "Communications" is "OK", "State" is "NORMAL", "Partner Role" is "MAIN", and "Partner State" is "NORMAL" in the row where Type is "MAIN".

                      Output: 

                      nrcmd> dhcp getRelatedServers
100 Ok
Type Name Address Requests Communications State Partner
Role Partner State
MAIN -- 10.5.1.24 0 OK NORMAL MAIN
NORMAL
TCP-L blrrms-Serving-02.cisco.com 10.5.1.20,61610 0 NONE listening --
--
                      Step 5   Proceed to execute the configure_PAR_hnbgw.sh to configure all the radius clients on the secondary Serving node.

                      Configuring the Security Gateway on the ASR 5000 for Redundancy

                      Procedure
                        Step 1   Log in to the Cisco ASR 5000 that contains the HNB and security gateways.
                        Step 2   Check the context name for the security gateway: show context all.
                        Step 3   Display the HNB gateway configuration: show configuration context security_gateway_context_name.

                        Verify that there are two DHCP server addresses configured. See the highlighted text in the example.



                        Example: 
                        [local]blrrms-xt2-03# show configuration context HNBGW

context HNBGW
  ip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocation
  ipsec transform-set ipsec-vmct
  #exit
  ikev2-ikesa transform-set ikesa-vmct
  #exit
  crypto template vmct-asr5k ikev2-dynamic
    authentication local certificate
    authentication remote certificate
    ikev2-ikesa transform-set list ikesa-vmct
    keepalive interval 120
    payload vmct-sa0 match childsa match ipv4
      ip-address-alloc dynamic
      ipsec transform-set list ipsec-vmct
      tsr start-address 10.5.1.0 end-address 10.5.1.255
    #exit
    nai idr 10.5.1.91 id-type ip-addr
    ikev2-ikesa keepalive-user-activity
    certificate 10-5-1-91
    ca-certificate list ca-cert-name TEF_CPE_SubCA ca-cert-name Ubi_Cisco_Int_ca
  #exit
  interface Iu-Ps-Cs-H
    ip address 10.5.1.91 255.255.255.0
    ip address 10.5.1.92 255.255.255.0 secondary
    ip address 10.5.1.93 255.255.255.0 secondary
  #exit
  subscriber default
    dhcp service CNR context HNBGW
    ip context-name HNBGW
    ip address pool name ipsec
  exit
  radius change-authorize-nas-ip 10.5.1.92 encrypted key 
         +A1rxtnjd9vom7g1ugk4buohqxtt073pbivjonsvn3olnz2wsl0sm5 
         event-timestamp-window 0 no-reverse-path-forward-check     
  aaa group default
    radius max-retries 2
    radius max-transmissions 5
    radius timeout 1
    radius attribute nas-ip-address address 10.5.1.92
    radius server 10.5.1.20 encrypted key 
       +A3qji4gwxyne5y3s09r8uzi5ot70fbyzzzzgbso92ladvtv7umjcj 
       port 1812 priority 2
    radius server 1.4.2.90 encrypted key 
       +A1z4194hjj9zvm24t0vdmob18b329iod1jj76kjh1pzsy3w46m9h4 
       port 1812 priority 1
  #exit
  gtpp group default
  #exit
  gtpu-service GTPU_FAP_1
    bind ipv4-address 10.5.1.93
  exit
    dhcp-service CNR
    dhcp client-identifier ike-id
    dhcp server 10.5.1.20
    dhcp server 10.5.1.24
    no dhcp chaddr-validate
    dhcp server selection-algorithm use-all
    dhcp server port 61610
    bind address 10.5.1.92
  #exit
  dhcp-server-profile CNR
  #exit
  hnbgw-service HNBGW_1
    sctp bind address 10.5.1.93
    sctp bind port 29169
    associate gtpu-service GTPU_FAP_1
    sctp sack-frequency 5 
    sctp sack-period 5 
    no sctp connection-timeout
    no ue registration-timeout
    hnb-identity oui discard-leading-char 
    hnb-access-mode mismatch-action accept-aaa-value
    radio-network-plmn mcc 116 mnc 116
      rnc-id 116 
    security-gateway bind address 10.5.1.91 crypto-template vmct-asr5k context HNBGW
  #exit
  ip route 0.0.0.0 0.0.0.0 10.5.1.1 Iu-Ps-Cs-H
  ip route 10.5.3.128 255.255.255.128 10.5.1.1 Iu-Ps-Cs-H
  ip igmp profile default
  #exit
#exit
end
                        Step 4   If the second DHCP server is not configured, run these commands to configure it:
                        1. configure
                        2. context HNBGW
                        3. dhcp-service CNR
                        4. dhcp server <dhcp-server-2-IP-Addr >
                        5. dhcp server selection-algorithm use-all

                        Verify that the second DHCP server is configured by examining the output from this step.

                        Note   

                        Exit from the config mode and view the DHCP IP.



                        Example: 
                        [local]blrrms-xt2-03# configure
[local]blrrms-xt2-03(config)# context HNBGW
[HNBGW]blrrms-xt2-03(config-ctx)#  dhcp-service CNR
[HNBGW]blrrms-xt2-03(config-dhcp-service)# dhcp server 1.1.1.1 
[HNBGW]blrrms-xt2-03(config-dhcp-service)# dhcp server selection-algorithm use-all
                        Step 5   To view the changes, execute the following command: 
                        [local]blrrms-xt2-03# show configuration context HNBGW
                        Step 6   Save the changes by executing the following command: 
                        [local]blrrms-xt2-03# save config /flash/xt2-03-aug12
                        Note   

                        The saved filename can be as per your choice. For example, xt2-03-aug12.

                        Configuring the Security Gateway on ASR 5000 for Multiple Subnet or Geo-Redundancy

                        In a different subnet or geo-redundant deployment, it is expected that the Serving and Upload nodes are deployed with IPs on a different subnet. The new subnet therefore needs to be allowed in the IPsec traffic selector on the Security Gateway (SeGW).

                        In a deployment where the SeGW (ASR 5000) and RMS are on the same subnet, the output of the HNB GW is displayed as follows (the single subnet information is highlighted below): 

                        [local]blrrms-xt2-03# show configuration context HNBGW
context HNBGW
ip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocation
ipsec transform-set ipsec-vmct
#exit
ikev2-ikesa transform-set ikesa-vmct
#exit
crypto template vmct-asr5k ikev2-dynamic
authentication local certificate
authentication remote certificate
ikev2-ikesa transform-set list ikesa-vmct
keepalive interval 120
payload vmct-sa0 match childsa match ipv4
ip-address-alloc dynamic
ipsec transform-set list ipsec-vmct
tsr start-address 10.5.1.0 end-address 10.5.1.255
#exit

                        Follow the below steps to check and add the different subnet in the IPSec traffic selector of the SeGW (ASR 5000):

                        Procedure
                          Step 1   Log in to the Cisco ASR 5000 that contains the HNB and security gateways.
                          Step 2   Check the context name for the security gateway: show context all.
                          Step 3   Display the HNB gateway configuration: show configuration context security_gateway_context_name.
                          Step 4   Update the SeGW (ASR 5000) configuration with the additional subnet using the following command: 
                          tsr start-address <new subnet start IP address> end-address <new subnet end IP address>

                          Example: For example, . 

                          tsr start-address 10.5.4.0 end-address 10.5.4.255
[local]blrrms-xt2-19# configure
[local]blrrms-xt2-19(config)# context HNBGW
[HNBGW]blrrms-xt2-19(config-ctx)# crypto template vmct-asr5k ikev2-dynamic
[HNBGW]blrrms-xt2-19(cfg-crypto-tmpl-ikev2-tunnel)# payload vmct-sa0 match childsa match ipv4
[HNBGW]blrrms-xt2-19(cfg-crypto-tmpl-ikev2-tunnel-payload)# tsr start-address 10.5.4.0 end-address 10.5.4.255
[HNBGW]blrrms-xt2-19(cfg-crypto-tmpl-ikev2-tunnel-payload)# exit
[HNBGW]blrrms-xt2-19(cfg-crypto-tmpl-ikev2-tunnel)# exit
[HNBGW]blrrms-xt2-19(config-ctx)# exit
[HNBGW]blrrms-xt2-19(config)# exit
[local]blrrms-xt2-19# save config /flash/xt2-03-aug12
Are you sure? [Yes|No]: yes
[local]blrrms-xt2-19#
                          Step 5   Verify the updated SeGW configuration using the command: 
                           show configuration context security_gateway_context_name

                          The updated output is highlighted below: 

                          [local]blrrms-xt2-03# show configuration context HNBGW
config
context HNBGW
ip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocation
ipsec transform-set ipsec-vmct
#exit
ikev2-ikesa transform-set ikesa-vmct
#exit
crypto template vmct-asr5k ikev2-dynamic
authentication local certificate
authentication remote certificate
ikev2-ikesa transform-set list ikesa-vmct
keepalive interval 120
payload vmct-sa0 match childsa match ipv4
ip-address-alloc dynamic
ipsec transform-set list ipsec-vmct
tsr start-address 10.5.1.0 end-address 10.5.1.255
tsr start-address 10.5.4.0 end-address 10.5.4.255
#exit

                          Configuring the HNB Gateway for Redundancy

                          Procedure
                            Step 1   Log in to the HNB gateway.
                            Step 2   Display the configuration context of the HNB gateway so that you can verify the radius information:

                            show configuration context HNBGW_context_name

                            If the radius parameters are not configured as shown in this example, configure them as in this procedure.



                            Example: 
                            [local]blrrms-xt2-03# show configuration context HNBGW

  context HNBGW
    ip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocation
    ipsec transform-set ipsec-vmct
    #exit
    ikev2-ikesa transform-set ikesa-vmct
    #exit
    crypto template vmct-asr5k ikev2-dynamic
      authentication local certificate
      authentication remote certificate
      ikev2-ikesa transform-set list ikesa-vmct
      keepalive interval 120
      payload vmct-sa0 match childsa match ipv4
        ip-address-alloc dynamic
        ipsec transform-set list ipsec-vmct
        tsr start-address 10.5.1.0 end-address 10.5.1.255
      #exit
      nai idr 10.5.1.91 id-type ip-addr
      ikev2-ikesa keepalive-user-activity
      certificate 10-5-1-91
      ca-certificate list ca-cert-name TEF_CPE_SubCA ca-cert-name Ubi_Cisco_Int_ca
    #exit
    interface Iu-Ps-Cs-H
      ip address 10.5.1.91 255.255.255.0
      ip address 10.5.1.92 255.255.255.0 secondary
      ip address 10.5.1.93 255.255.255.0 secondary
    #exit
    subscriber default
      dhcp service CNR context HNBGW
      ip context-name HNBGW
      ip address pool name ipsec
    exit
    radius change-authorize-nas-ip 10.5.1.92 encrypted key 
                 +A1rxtnjd9vom7g1ugk4buohqxtt073pbivjonsvn3olnz2wsl0sm5  
                 event-timestamp-window 0 no-reverse-path-forward-check     
    aaa group default
      radius max-retries 2
      radius max-transmissions 5
      radius timeout 1
      radius attribute nas-ip-address address 10.5.1.92
      radius server 10.5.1.20 encrypted key +A3qji4gwxyne5y3s09r8uzi5ot70fbyzzzzgbso92ladvtv7umjcj 
              port 1812 priority 2
      radius server 1.4.2.90 encrypted key +A1z4194hjj9zvm24t0vdmob18b329iod1jj76kjh1pzsy3w46m9h4 
              port 1812 priority 1
    #exit
    gtpp group default
    #exit
    gtpu-service GTPU_FAP_1
      bind ipv4-address 10.5.1.93
    exit
    dhcp-service CNR
      dhcp client-identifier ike-id
      dhcp server 10.5.1.20
      dhcp server 10.5.1.24
      no dhcp chaddr-validate
      dhcp server selection-algorithm use-all
      dhcp server port 61610
      bind address 10.5.1.92
    #exit
    dhcp-server-profile CNR
    #exit
    hnbgw-service HNBGW_1
      sctp bind address 10.5.1.93
      sctp bind port 29169
      associate gtpu-service GTPU_FAP_1
      sctp sack-frequency 5 
      sctp sack-period 5 
      no sctp connection-timeout
      no ue registration-timeout
      hnb-identity oui discard-leading-char 
      hnb-access-mode mismatch-action accept-aaa-value
      radio-network-plmn mcc 116 mnc 116
        rnc-id 116 
      security-gateway bind address 10.5.1.91 crypto-template vmct-asr5k context HNBGW
    #exit
    ip route 0.0.0.0 0.0.0.0 10.5.1.1 Iu-Ps-Cs-H
    ip route 10.5.3.128 255.255.255.128 10.5.1.1 Iu-Ps-Cs-H
    ip igmp profile default
    #exit
  #exit
end
                            Step 3   If the radius server configuration is not as shown in the above example, perform the following configuration:
                            1. configure
                            2. context HNBGW_context_name
                            3. radius server radius-server-ip-address key secret port 1812 priority 2
                              Note    When two radius servers are configured, one server is assigned Priority 1 and the other server is assigned Priority 2. If radius server entries are already configured, check their priorities. Else, assign new server priorities.


                            Example: 
                            [local]blrrms-xt2-03# configure
[local]blrrms-xt2-03(config)# context HNBGW
[HNBGW]blrrms-xt2-03(config-ctx)# radius server 10.5.1.20 key secret port 1812 priority 2

radius server 10.5.1.20 encrypted key +A3qji4gwxyne5y3s09r8uzi5ot70fbyzzzzgbso92ladvtv7umjcj 
        port 1812 priority 2
                            Step 4   If the configuration of the radius server is not correct, delete it: no radius server radius-server-id-address

                            Example: 
                            [HNBGW]blrrms-xt2-03(config-ctx)# no radius server 10.5.1.20
                            Step 5   Configure the radius maximum retries and time out settings:
                            1. configure
                            2. context hnbgw_context_name
                            3. radius max-retries 2
                            4. radius timeout 1

                            After configuring the radius settings, verify that they are correct as in the example.



                            Example: 
                            [local]blrrms-xt2-03# configure
[local]blrrms-xt2-03(config)# context HNBGW
[HNBGW]blrrms-xt2-03(config-ctx)# radius max-retries 2
[HNBGW]blrrms-xt2-03(config-ctx)# radius timeout 1

radius max-retries 2
   radius max-transmissions 5
   radius timeout 1

                            After the configuration is complete, the HNB GW sends access request thrice to the primary PAR with a one-second time delay between the two requests.

                            Configuring DNS for Redundancy

                            Configure the DNS with the newly added redundant configuration for the Serving and Upload nodes.

                            RMS High Availability Deployment

                            The high availability feature for Cisco RMS is designed to ensure continued operation of Cisco RMS sites in case of network failures. High availability provides a redundant setup that is activated automatically or manually when an active Central node or Provisioning and Management Gateway (PMG) database (DB) fails at one RMS site. This setup ensures that the Central node and PMG DB are connected at all times.

                            To implement high availability you will need an RMS site 1 as primary Central node, Serving node, and Upload node and RMS site 2 with redundant Serving node and Upload node.

                            To know more about high availability and configure it for Cisco RMS, see the following sections of the High Availability for Cisco RAN Management Systems document.

                            • Configuring High Availability for the Central Node

                            • Configuring High Availability for VMware vCenter in RMS Distributed Setup

                            • Configuring High Availability for VMware vCenter in RMS All-In-One Setup

                            • Configuring High Availability for the PMG DB

                            Optimizing the Virtual Machines

                            To run the RMS software, you need to verify that the VMs that you are running are up-to-date and configured optimally. Use these tasks to optimize your VMs.

                            Upgrading the VM Hardware Version

                            To have better performance parameter options available (for example, more virtual CPU and memory), the VMware hardware version needs to be upgraded to version 8 or above. You can upgrade the version using the vSphere client .


                            Note

                            Prior to the VM hardware upgrade, make a note of the current hardware version from vSphere client.

                            Figure 3. VMware Hardware Version

                            Procedure
                              Step 1   Start the vSphere client.
                              Step 2   Right-click the vApp for one of the RMS nodes and select Power Off.
                              Figure 4. Power Off the vApp



                              Step 3   Right-click the virtual machine for the RMS node (central, serving, upload) and select Upgrade Virtual Hardware.

                              The software upgrades the virtual machine hardware to the latest supported version.

                              Note   

                              The Upgrade Virtual Hardware option appears only if the virtual hardware on the virtual machine is not the latest supported version.

                              Step 4   Click Yes in the Confirm Virtual Machine Upgrade screen to continue with the virtual hardware upgrade.
                              Step 5   Verify that the upgraded version is displayed in the Summary screen of the vSphere client.
                              Step 6   Repeat this procedure for all remaining VMs, such as central, serving and upload so that all three VMs are upgraded to the latest hardware version.
                              Step 7   Right-click the respective vApp of the RMS nodes and select Power On.
                              Step 8   Make sure that all VMs are completely up with their new installation configurations.

                              Upgrading the VM CPU and Memory Settings

                              Before You Begin

                              Upgrade the VM hardware version as described in Upgrading the VM Hardware Version.


                              Note

                              Upgrade the CPU/Memory settings of the required RMS VMs using the below procedure to match the configurations defined in the section Optimum CPU and Memory Configurations

                              Procedure
                                Step 1   Start the VMware vSphere web client.
                                Step 2   Right-click the vApp for one of the RMS nodes from the left panel and select Power Off.
                                Step 3   Right-click the virtual machine for a RMS node (central, serving, upload) and select Edit Settings.
                                Step 4   Select the Virtual Hardware tab. Click or Expand Memory in the Virtual Hardware on the left pane of the screen and update the RAM.
                                Step 5   Click the Virtual Hardware tab and update the Number of CPUs.
                                Step 6   Click OK.
                                Step 7   Right-click the vApp and select Power On.
                                Step 8   Repeat this procedure for all remaining VMs (central, serving, and upload).

                                Upgrading the Data Storage on Root Partition for Cisco RMS VMs

                                This procedure describes how to increase the disk space on the root partition. In the example illustrated below the disk partition is increased from 50 GB to 100 GB. Choose the new size (SYSTEM PARTITION) based on the value provided in Data Storage for Cisco RMS VMs.

                                Procedure
                                  Step 1   Log in to the VM and launch the console. Check the size of the existing partition. 
                                  # df -h

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3              49G  8.5G   39G  19% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             124M   25M   94M  21% /boot
                                  Step 2   Take a clone of the system (see Back Up System Using vApp Cloning).
                                  Step 3   Check the current root disk (/dev/sda) size using the following command. 
                                  # fdisk -l

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # fdisk -l

Disk /dev/sda: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00058cff

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          17      131072   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              17          33      131072   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3              33        6528    52165632   83  Linux
[BLR17-Central-41N] /home/admin1 #
                                  Step 4   Power down the VM. Select the VM and click Power off the Virtual Machine.
                                  Step 5   Select the respective VM from the vCenter inventory list, right-click and click Edit Settings. Under the Virtual Hardware tab select Hard disk 1 and increase the size of the disk to desired size. Click OK.
                                  Step 6   Power on the VM. Select the VM and click Power off the Virtual Machine.
                                  Step 7   Log in to the VM and switch to root user. 
                                  $ su

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] ~ $ su
Password:
[BLR17-Central-41N] /home/admin1 #
                                  Step 8   Verify the updated root disk (/dev/sda) size using the following command. 
                                  # fdisk -l

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # fdisk -l

Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00058cff

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          17      131072   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              17          33      131072   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3              33        6528    52165632   83  Linux
[BLR17-Central-41N] /home/admin1 #
                                  Step 9   Use the fdisk /dev/sda command and enter option p to view the current partitions on /dev/sda. Note the start and end cylinder number for /dev/sda3 (/dev/sda3 is the root file system that can be verified using the df -h command). Enter option d and 3 (as root FS is sda3) to delete root FS temporarily. Enter optionp to confirm that the partition has been deleted. 
                                  # fdisk  /dev/sda

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # fdisk  /dev/sda

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): p

Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00058cff

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          17      131072   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              17          33      131072   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3              33        6528    52165632   83  Linux

Command (m for help): d
Partition number (1-4): 3


Command (m for help): p 

Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00058cff

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          17      131072   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              17          33      131072   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.

Command (m for help):
                                  Step 10   Enter options n, p, and 3 in order when prompted (to create a new primary partition on /dev/sda3). Note that the start cylinder number will be same as noted in Step 9, press Enter. Only the last cylinder number should be greater than the earlier number noted in Step 9. Press Enter. Enter option w to save the settings.

                                  Example: 
                                  Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (33-13054, default 33): 
Using default value 33
Last cylinder, +cylinders or +size{K,M,G} (33-13054, default 13054): 
Using default value 13054

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.
[BLR17-Central-41N] /home/admin1 #
                                  Step 11   Reboot the system. 
                                  # reboot

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # reboot
Broadcast message from admin1@BLR17-Central-41N
        (/dev/pts/0) at 3:47 ...
The system is going down for reboot NOW!
[BLR17-Central-41N] /home/admin1 #
                                  Step 12   Login to the system and switch to root user. 
                                  $ su

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] ~ $ su
Password:
[BLR17-Central-41N] /home/admin1 #
                                  Step 13   Enable the new disk size by using the following command. 
                                  # resize2fs /dev/sda3

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # resize2fs /dev/sda3
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/sda3 is mounted on /; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 7
Performing an on-line resize of /dev/sda3 to 26148271 (4k) blocks.
The filesystem on /dev/sda3 is now 26148271 blocks long.

[BLR17-Central-41N] /home/admin1 #
                                  Step 14   Verify the new size using the following command. 
                                  # df -h

                                  Output:



                                  Example: 
                                  [BLR17-Central-41N] /home/admin1 # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3              99G  8.5G   85G  10% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             124M   25M   94M  21% /boot
[BLR17-Central-41N] /home/admin1 #

                                  Upgrading the Upload VM Data Sizing


                                  Note

                                  Refer to Virtualization Requirements for more information on data sizing.

                                  Procedure
                                    Step 1   Log in to the VMware vSphere web client and connect to a specific vCenter server.
                                    Step 2   Select the Upload VM and click the Summary tab and view the available free disk space in Virtual Hardware > Location. Make sure that there is sufficient disk space available to make a change to the configuration.

                                    Figure 5. Upload Node Summary Tab



                                    Step 3   Right-click the RMS upload virtual machine and select Power followed by Shut Down Guest.
                                    Step 4   Right-click again the RMS upload virtual machine and select Edit Settings.
                                    Step 5   In the Edit Settings page, click New Device and select New Hard Disk or Existing Hard Disk to add or select a new hard disk.
                                    Step 6   Select one of the data stores based on the disk size needed, give the required disk size as input and create a new hard disk.
                                    Step 7   Click OK.
                                    Step 8   Repeat steps 5 and 7 for Hard disk 2.
                                    Step 9   Right-click the VM and select Power followed by Power On.
                                    Step 10   Log in to the Upload node.
                                    1. Log in to the Central node VM using the central node eth1 address.
                                    2. ssh to the Upload VM using the upload node hostname.

                                      Example: 
                                      ssh admin1@blr-rms14-upload
                                    Step 11   Check the effective disk space after expanding: fdisk -l.
                                    Step 12   Apply fdisk on expanded disk and create the new partition on the disk and save. 
                                    fdisk /dev/sdb
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-52216, default 1): 1
Last cylinder, +cylinders or +size{K,M,G} (1-52216, default 52216): 52216

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks..

                                    Follow the on-screen prompts carefully to avoid errors that may corrupt the entire system.

                                    The cylinder values may vary based on the machine setup.

                                    Step 13   Repeat Step 11 to create partition on another disk.
                                    Step 14   Stop the LUS process.

                                    Example: 
                                     god stop UploadServer
Sending 'stop' command
The following watches were affected:
UploadServer
                                    Step 15   Create backup folders for the 'files' partition.

                                    Example: 
                                     mkdir -p /backups/uploads
The system responds with a command prompt.

mkdir –p /backups/archives
The system responds with a command prompt.
                                    Step 16   Back up the data.

                                    Example: 
                                     mv/opt/CSCOuls/files/uploads/* /backups/uploads
mv/opt/CSCOuls/files/archives/* /backups/archives
The system responds with a command prompt.
                                    Step 17   Create the file system on the expanded partitions.

                                    Example: 
                                    mkfs.ext4 -i 4096 /dev/sdb1
The system responds with a command prompt.
                                    Step 18   Repeat Step 16 for other partitions.
                                    Step 19   Mount expanded partitions under /opt/CSCOuls/files/uploads and /opt/CSCOuls/files/archives directories using the following commands. 
                                     mount -t ext4 -o
noatime,data=writeback,commit=120 /dev/sdb1 /opt/CSCOuls/files/uploads/
 mount -t ext4 -o
noatime,data=writeback,commit=120 /dev/sdc1 /opt/CSCOuls/files/archives/

The system responds with a command prompt.
                                    Step 20   Edit /etc/fstab and append following entries to make the mount point reboot persistent. 
                                    /dev/sdb1 /opt/CSCOuls/files/uploads/ ext4 noatime,data=writeback,commit=120 0 0
/dev/sdc1 /opt/CSCOuls/files/archives/ ext4 noatime,data=writeback,commit=120 0 0
                                    Step 21   Restore the already backed up data. 
                                    mv /backups/uploads/* /opt/CSCOuls/files/uploads/ 
mv /backups/archives/* /opt/CSCOuls/files/archives/ 
The system responds with a command prompt.
                                    Step 22   Check ownership of the /opt/CSCOuls/files/uploads and /opt/CSCOuls/files/archives directory with the following command. 
                                    ls -l /opt/CSCOuls/files
                                    Step 23   Change the ownership of the files/uploads and files/archives directories to ciscorms. 
                                     chown -R ciscorms:ciscorms /opt/CSCOuls/files/
The system responds with a command prompt.
                                    Step 24   Verify ownership of the mounting directory. 
                                    ls -al /opt/CSCOuls/files/
total 12
drwxr-xr-x. 7 ciscorms ciscorms 4096 Aug  5 06:03 archives
drwxr-xr-x. 2 ciscorms ciscorms 4096 Jul 25 15:29 conf  
drwxr-xr-x. 5 ciscorms ciscorms 4096 Jul 31 17:28 uploads
                                    Step 25   Edit the /opt/CSCOuls/conf/UploadServer.properties file. 
                                    cd /opt/CSCOuls/conf;
sed –i 
's/UploadServer.disk.alloc.global.maxgb.*/UploadServer.disk.alloc.global.maxgb=<Max limit>/' 
UploadServer.properties;
System returns with command prompt.

                                    Replace <Max limit> with the maximum size of partition mounted under /opt/CSCOuls/files/uploads.

                                    Step 26   Start the LUS process. 
                                    god start UploadServer
Sending 'start' command
The following watches were affected:
UploadServer
                                    Note   

                                    For the Upload Server to work properly, both/opt/CSCOuls/files/uploads/and/opt/CSCOuls/files/archives/folders must be on different partitions.

                                    RMS Installation Sanity Check


                                    Note

                                    Verify that there are no install related errors or exceptions in the ova-first-boot.log present in "/root" directory. Proceed with the following procedures only after confirming from the logs that the installation of all the RMS nodes is successful.

                                    Sanity Check for the BAC UI

                                    Following the installation, perform this procedure to ensure that all connections are established.


                                    Note

                                    The default user name is bacadmin. The password is as specified in the OVA descriptor file (prop:RMS_App_Password). The default password is Rmsuser@1.

                                    Procedure
                                      Step 1   Log in to BAC UI using the URL https://<central-node-north-bound-IP>/adminui.
                                      Step 2   Click on Servers.
                                      Step 3   Click the tabs at the top of the display to verify that all components are populated:

                                      • DPEs—Should display respective serving node name given in the descriptor file used for deployment. Click on the serving node name. The display should indicate that this serving node is in the Ready state.

                                        Figure 6. BAC: View Device Provisioning Engines Details



                                      • NRs—Should display the NR (same as serving node name) given in the descriptor file used for deployment. Click on the NR name. The display should indicate that this node is in the Ready state.

                                      • Provisioning Groups—Should display the respective provisioning group name given in the descriptor file used for deployment. Click on the Provisioning group name. The display should indicate the ACS URL pointing to the value of the property, “prop: Acs_Virtual_Fqdn” that you specified in the descriptor file.

                                      • RDU—Should display the RDU in the Ready state.

                                      If all of these screens display correctly as described, the BAC UI is communicating correctly.

                                      Sanity Check for the DCC UI


                                      Note

                                      Before using the username, pmguser or pmgadmin, through the DCC UI to communicate with PMG, ensure that you change their default password.

                                      Following the installation, perform this procedure to ensure that all connections are established.

                                      Procedure
                                        Step 1   Log in to DCC UI using the URL https://[central-node-northbound-IP]/dcc_ui.

                                        The default username is dccadmin. The password is as specified in the OVA descriptor file (prop:RMS_App_Password). The default password is Rmsuser@1.

                                        Step 2   Click the Groups and IDs tab and verify that the Group Types table shows Area, Enterprise, FemtoGateway, HeNBGW,LTESecGateway, RFProfile, RFProfile-LTE, Region, Site, SubSite, and UMTSSecGateway and the ID Pool Type table shows CELL-POOL, SAI-POOL, and LTE-CELL-POOL.

                                        Verifying Application Processes

                                        Verify the RMS virtual appliance deployment by logging onto each of the virtual servers for the Central, Serving and Upload nodes. Note that these processes and network listeners are available for each of the servers:

                                        Procedure
                                          Step 1   Log in to the Central node as a root user.
                                          Step 2   Run: service bprAgent status

                                          In the output, note that these processes are running: 

                                          [rtpfga-s1-central1] ~ # service bprAgent status

BAC Process Watchdog is running 
Process [snmpAgent] is running
Process [rdu] is running
Process [tomcat] is running
                                          Step 3   Run: /rms/app/nwreg2/regional/usrbin/cnr_status
                                          Note    This step is not applicable in a third-party SeGW RMS deployment. 
                                          [rtpfga-ova-central06] ~ # /rms/app/nwreg2/regional/usrbin/cnr_status 
Server Agent running (pid: 4564) 
CCM Server running (pid: 4567) 
WEB Server running (pid: 4568) 
RIC Server Running (pid:v4569)
                                          Step 4   Login to the Serving node and run the command as root user.
                                          Step 5   Run: service bprAgent status 
                                           [rtpfga-s1-serving1] ~ # service bprAgent status 

BAC Process Watchdog is running. 
Process [snmpAgent] is running.  
Process [dpe] is running. 
Process [cli] is running.
                                          Step 6   Run: /rms/app/nwreg2/local/usrbin/cnr_status
                                          Note    This step is not applicable in a third-party SeGW RMS deployment. 
                                          [rtpfga-s1-serving1] ~ # /rms/app/nwreg2/local/usrbin/cnr_status
 
DHCP server running (pid: 16805) 
Server Agent running (pid: 16801) 
CCM Server running (pid: 16804) 
WEB Server running (pid: 16806) 
CNRSNMP server running (pid: 16808) 
RIC Server Running (pid: 16807) 
TFTP Server is not running 
DNS Server is not running 
DNS Caching Server is not running
                                          Step 7   Run: /rms/app/CSCOar/usrbin/arstatus 
                                          [root@rms-aio-serving ~]# /rms/app/CSCOar/usrbin/arstatus 

Cisco Prime AR RADIUS server running (pid: 24272) 
Cisco Prime AR Server Agent running (pid: 24232) 
Cisco Prime AR MCD lock manager running (pid: 24236) 
Cisco Prime AR MCD server running (pid: 24271) 
Cisco Prime AR GUI running (pid: 24273) 
[root@rms-aio-serving ~]#
                                          Step 8   Login to the Upload node and run the command as root user.
                                          Step 9   Run: service god status 
                                          [rtpfga-s1-upload1] ~ # service god status 

UploadServer: up
                                          Note   

                                          If the above status of UploadServer is not up (start or unmonitor state), see Upload Server is Not Up for details.

                                          Was this Document Helpful?

                                          FeedbackFeedback

                                          Let Us Help

                                          Related Support Community Discussions