RMS Installation Tasks - Cisco · RMS Installation Tasks PerformthesetaskstoinstalltheRMSsoftware....

RMS Installation Tasks

Perform these tasks to install the RMS software.

• RMS Installation Procedure, page 1

• Preparing the OVA Descriptor Files, page 2

• Deploying the RMS Virtual Appliance, page 5

• RMS Redundant Deployment, page 9

• Optimizing the Virtual Machines, page 21

• RMS Installation Sanity Check, page 29

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

Task Completion:Mandatory or Optional

LinkTaskStep No.

MandatoryInstallation Prerequisitesand Installing VMwareESXi and vCenter for CiscoRMS

Perform all prerequisite installations1

MandatoryPreparing the OVADescriptor Files, on page2

Create the Open Virtual Application(OVA) descriptor file

2

MandatoryDeploying the RMS VirtualAppliance, on page 5

Deploy the OVA package3

OptionalRMS RedundantDeployment, on page 9

Configure redundant Serving nodes4

RAN Management System Installation Guide, Release 4.0 February 9, 2015 1

b_rms_installation_guide_4x_chapter_010.pdf#unique_21




Task Completion:Mandatory or Optional

LinkTaskStep No.

Mandatory if the HNBgateway properties werenot included in the OVAdescriptor file.

HNB Gateway and DHCPConfiguration

Run the configure_hnbgw.sh scriptto configure the HNB gatewayproperties

5

OptionalOptimizing the VirtualMachines, on page 21

Optimize the VMs by upgrading theVM hardware version, upgrading theVMCPU andmemory and upgradingthe Upload VM data size

6

Optional butrecommended

RMS Installation SanityCheck, on page 29

Perform a sanity check of the system7

MandatoryInstalling RMS CertificatesInstall RMS Certificates8

OptionalConfiguring Default Routesfor Direct TLS Terminationat the RMS

Configure the default route on theUpload and Serving nodes for TLStermination

9

Optional

Contact Cisco services todeploy PMG DB.

PMG Database Installationand Configuration

Install and configure the PMGdatabase

10

MandatoryConfiguring the CentralNode

Configure the Central node11

MandatoryConfiguring the CentralNode

Populate the PMG database12

Optional butrecommended

Installation VerificationVerify the installation13

Preparing the OVA Descriptor FilesThe RMS requires Open Virtual Application (OVA) descriptor files, more commonly known as configurationfiles, 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 bundledas part of RMS build deliverable itself. Both RMS-Distributed-Solution-4.0.0-2M.tar.gz andRMS-Provisioning-Solution-4.0.0-2M.tar.gz contain sample descriptors for Distributed andAll-in-one package.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 theall-in-one deployment and three separate files for the distributed deployment.

RAN Management System Installation Guide, Release 4.02 February 9, 2015

RMS Installation TasksPreparing the OVA Descriptor Files













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

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

Make sure that all Network 1 (eth0) interfaces (Central Node, Serving Node, and Upload Nodes) must bein same VLAN.

Note

Table 1: Mandatory Properties for OVA Descriptor File

Valid ValuesDescriptionProperty

textName of the physical storage to keep the VMfiles

datastore

VLAN #VLAN for the connection between the uploadnode (NB) and the central node

net:Upload-Node Network 1

VLAN #VLAN for the connection between the uploadnode (southbound) and the CPE network(FAPs)

net:Upload-Node Network 2

VLAN #VLAN for the connection between the centralnode (southbound) and the upload node

net:Central-Node Network 1

VLAN #VLAN for the connection between the centralnode (northbound) and the OSS network

net:Central-Node Network 2

VLAN #VLAN for the connection between the servingnode (northbound) and the central node

net:Serving-Node Network 1

VLAN #VLAN for the connection between the servingnode (southbound) and the CPE network(FAPs)

net:Serving-Node Network 2

IPv4 addressIP address of the southbound VM interfaceprop:Central_Node_Eth0_Address

Network maskNetwork mask for the IP subnet of thesouthbound VM interface

prop:Central_Node_Eth0_Subnet

IPv4 addressIP address of the northbound VM interfaceprop:Central_Node_Eth1_Address

Network maskNetwork mask for the IP subnet of thenorthbound VM interface

prop:Central_Node_Eth1_Subnet




IPv4 addressIP address of primary DNS server provided bynetwork administrator

prop:Central_Node_Dns1_Address

IPv4 addressIP address of secondary DNS server providedby network administrator

prop:Central_Node_Dns2_Address

IPv4 addressIP address of the gateway to the managementnetwork for the north bound interface of thecentral node

prop:Central_Node_Gateway

IPv4 addressIP address of the northbound VM interfaceprop:Serving_Node_Eth0_Address


prop:Serving_Node_Eth0_Subnet

IPv4 addressIP address of the southbound VM interfaceprop:Serving_Node_Eth1_Address


prop:Serving_Node_Eth1_Subnet


prop:Serving_Node_Dns1_Address


prop:Serving_Node_Dns2_Address

comma separated IPv4addresses of the form[northboundGW],[southboundGW]

IP address of the gateway to the managementnetwork

prop:Serving_Node_Gateway

IPv4 addressIP address of the northbound VM interfaceprop:Upload_Node_Eth0_Address


prop:Upload_Node_Eth0_Subnet

IPv4 addressIP address of the southbound VM interfaceprop:Upload_Node_Eth1_Address


prop:Upload_Node_Eth1_Subnet


prop:Upload_Node_Dns1_Address


prop:Upload_Node_Dns2_Address




comma separated IPv4addresses of the form[northboundGW],[southboundGW]

IP address of the gateway to the managementnetwork

prop:Upload_Node_Gateway

IPv4 address or URLPrimary NTP serverprop:Ntp1_Address

IPv4 addressACS Virtual Address. Southbound IP addressof the Serving node

prop:Acs_Virtual_Address

IPv4 address or FQDNvalue

ACS virtual fully qualified domain name(FQDN). Southbound FQDN or IP address ofthe serving node. For NAT based deployment,this can be set to public IP/FQDN of the NAT.

prop:Acs_Virtual_Fqdn

IPv4 address or FQDNvalue

Southbound FQDN or IP address of the uploadnode. Specify Upload eth1 address if no fqdnexists. For NAT based deployment, this canbe set to public IP/FQDN of the NAT.

prop:Upload_SB_Fqdn

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

Validation of OVA FilesIf mandatory properties are missing from a descriptor file, the OVA installer displays an error on the installationconsole. If mandatory properties are incorrectly configured, an appropriate error is displayed on the installationconsole or in the ova-first-boot.log.

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-bootlogs in the case of installation failures.

Wrongly configured properties include invalid IP addresses, invalid FQDN format, and so on. Validationsare 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 ApplianceAll administrative functions are available through vSphere client. A subset of those functions is availablethrough the vSphere web client. The vSphere client users are virtual infrastructure administrators for specializedfunctions. The vSphere web client users are virtual infrastructure administrators, help desk, network operationscentre operators, and virtual machine owners.


RMS Installation TasksValidation of OVA Files

b_rms_installation_guide_4x_appendix_01001.pdf#unique_79

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

Before You Begin

You must be running VMware vSphere version 5.1. There are two ways to access the VMware Vcenter:

• VMware vSphere Client locally installed application

• VMware vSphere Web Client

Procedure

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

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

Note

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

Step 2 Change the mode of the OVA deployer file to executable: chmod +x ./OVAdeployer.shStep 3 ./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-Provisioning-Solution-4.0.0-1E.ovavi://myusername:mypass#[email protected]/BLR/host/UCS5K/blrrms-5108-09.cisco.com

The OVAdeployer.sh tool is new in RMS Release 4.0. It first validates the OVA descriptor file andthen continues to install the RMS. If necessary, get the OVAdeployer.sh tool from the build packageand copy it to the directory where the OVA descriptor file is stored.

Note

If the vcenter-user and/or password are not specified in the command, you are prompted to enter this informationon the command line. Enter the user name and password to continue.

All-in-One RMS Deployment: ExampleIn an all-in-one RMS deployment, all the nodes such as central, serving, and upload are deployed on a singlehost on the VSphere client.

chmod +x ./OVAdeployer.sh

./OVAdeployer.sh /data/ovf/OVA_Files_QA/RMS-Provisioning-Solution-4.0.0-2N/RMS-Provisioning-Solution-4.0.0-2N.ova vi://admin:[email protected]/BLR/host/RMS/blrrms-c240-05.cisco.com

Reading OVA descriptor from path: ./.ovftoolChecking deployment typeStarting input validationprop: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.


RMS Installation TasksAll-in-One RMS Deployment: Example

prop:Root_Password not provided, will be taking the default value for RMS.Checking network configurations in descriptor...Deploying OVA...Opening OVA source:/data/ovf/OVA_Files_QA/RMS-Provisioning-Solution-4.0.0-2N/RMS-Provisioning-Solution-4.0.0-2N.ovaThe manifest does not validateOpening VI target:vi://[email protected]:443/BLR/host/RMS/blrrms-c240-05.cisco.comDeploying to VI:vi://[email protected]:443/BLR/host/RMS/blrrms-c240-05.cisco.comTransfer CompletedPowering on vApp: BLR-RMS-AIO-17Completed successfullyTue 08 Jul 2014 11:41:34 AM ISTOVA deployment took 538 seconds.-bash-4.1$

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

Figure 1: RMS All-In-One Deployment

Distributed RMS Deployment: ExampleIn the distributed deployment, RMS Nodes (Central node, Serving node, and Upload node) are deployed ondifferent hosts on the VSphere client. The RMS nodes must be deployed and powered in the followingsequence:

1 Central Node2 Serving Node3 Upload Node

The .ovftool files for the distributed deployment differ slightly than that of the all-in-one deployment in termsof virtual host network values as mentioned in Preparing the OVA Descriptor Files, on page 2. Here is anexample of the distributed RMS deployment:


RMS Installation TasksDistributed RMS Deployment: Example

Central Node Deployment


./OVAdeployer.sh RMS-Central-Node-4.0.0-2I.ovavi://ova:[email protected]/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.com

Reading OVA descriptor from path: ./.ovftoolChecking deployment typeStarting input validationDeploying OVA...Opening OVA source: RMS-Central-Node-4.0.0-2I.ovaThe manifest validatesOpening VI target:vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comDeploying to VI:vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comTransfer CompletedWarning:- No manifest entry found for: '.ovf'.- File is missing from the manifest: '.ovf'.Completed successfullyWed 28 May 2014 04:09:24 PM ISTOVA deployment took 335 seconds.

Serving Node Deployment


./OVAdeployer.sh RMS-Serving-Node-4.0.0-2I.ovavi://ova:[email protected]/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.com

Reading OVA descriptor from path: ./.ovftoolChecking deployment typeStarting input validationDeploying OVA...Opening OVA source: RMS-Serving-Node-4.0.0-2I.ovaThe manifest validatesOpening VI target:vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comDeploying to VI:vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comTransfer CompletedWarning:- No manifest entry found for: '.ovf'.- File is missing from the manifest: '.ovf'.Completed successfullyWed 28 May 2014 04:09:24 PM ISTOVA deployment took 335 seconds.

Upload Node Deployment

chmod +x ./OVAdeployer.sh./OVAdeployer.sh RMS-Upload-Node-4.0.0-2I.ovavi://ova:[email protected]/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.com

Reading OVA descriptor from path: ./.ovftoolChecking deployment typeStarting input validationDeploying OVA...Opening OVA source: RMS-Upload-Node-4.0.0-2I.ovaThe manifest validatesOpening VI target:


RMS Installation TasksDistributed RMS Deployment: Example

vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comDeploying to VI:vi://[email protected]:443/BLR/host/UCS5108-CH1-DEV/blrrms-5108-04.cisco.comTransfer CompletedWarning:- No manifest entry found for: '.ovf'.- File is missing from the manifest: '.ovf'.Completed successfullyWed 28 May 2014 04:09:24 PM ISTOVA deployment took 335 seconds.

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

Figure 2: RMS Distributed Deployment

RMS Redundant DeploymentTo mitigate Serving node and Upload Server Node deployment failover, additional serving/upload nodes canbe configured with the same central node.

This procedure describes how to configure additional serving/upload nodes with an existing central node.

Redundant Deployment does not mandate having both Serving Node and Upload Node together. Eachredundant node can be deployed individually without having the other node in the setup.

Note

Procedure

Step 1 Prepare the deployment descriptor (.ovftool file) for any additional serving nodes as described in Preparingthe OVA Descriptor Files, on page 2.For serving node redundancy, the descriptor file should have the same provisioning group as the primaryserving node. For an example on redundant OVA descriptor file, refer to Example Descriptor File for RedundantServing/Upload Node. The Descriptor File properties changes for Redundant Serving Node and RedundantUpload Node as follows:

Redundant Serving Node:

• Name

• Serving_Node_Eth0_Address


RMS Installation TasksRMS Redundant Deployment



• Serving_Node_Eth1_Address

• Serving_Hostname

• Acs_Virtual_Address (should be same as Serving_Node_Eth1_Address)

• Dpe_Cnrquery_Client_Socket_Address (should be same as Serving_Node_Eth0_Address)

Redundant Upload Node:

• name

• Upload_Node_Eth0_Address

• Upload_Node_Eth1_Address

• Upload_Hostname

• Acs_Virtual_Address (should be same as Serving_Node_Eth1_Address)

• Dpe_Cnrquery_Client_Socket_Address (should be same as Serving_Node_Eth0_Address)

A configuration file needs to be copied to the Central Node as part of Redundancy Configuration. As part ofthis configuration please create an ovf file with all the above properties changes for both Redundant Uploadand Serving Node and name it appropriately.

Step 2 Copy and upload the above ovf file ovadescriptorfile_CN_Config.txt and save it as .txt on the central nodeat / directory.

Step 3 Take a backup of /etc/hosts and /rms/app/rms/conf/UploadServer.xml using the commands:cp /etc/hosts /etc/hosts_orig

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

Step 4 Execute the utility shell script (central-multi-nodes-config.sh) to configure the network and applicationproperties on the central node.The script is located in the / directory. The above copied descriptor file ovadescriptorfile_CN_Config.txtto 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 ULS Node is created in the Upload.xml file.

Step 5 Install additional serving node and upload node as per the instructions in Deploying the RMSVirtual Appliance,on page 5Create individual ovf file per Redundant Serving Node or Redundant Upload Node and these ovf files willbe used as input for the respective Redundant Node Deployment

Step 6 Configure the serving node VMs to update the IP table firewall rules so that the DPE servers on these VMscan communicate with each other. Refer to Configuring Redundant Serving Nodes, on page 11.

Step 7 Configure the serving node redundancy as described in Setting Up Redundant Serving Nodes, on page 12.Redundant Upload Node needs no furtherconfiguration

Note


RMS Installation TasksRMS Redundant Deployment

Configuring Redundant Serving NodesAfter installing additional serving nodes, use this procedure to update the IP table firewall rules on the servingnodes so that the DPEs on the serving nodes can communicate with each other.

Procedure

Step 1 Log in to the primary serving node using SSH.Step 2 Change to root user.Step 3 Update the IP table firewall rules on the primary serving node so that the serving nodes can communicate:

a) iptables -A INPUT -s serving-node-2-eth1-address/32 -d serving-node-1-eth1-address/32 -i eth1 -p udp--dport 49186 -m state --state NEW -j ACCEPT

b) iptables -A OUTPUT -s serving-node-1-eth-address/32 -d serving-node-2-eth1-address/32 -o eth1 -pudp --dport 49186 -m state --state NEW -j ACCEPT

Port 49186 is used for inter-serving node communications.

Step 4 Save the configuration: service iptables saveStep 5 Log in to the secondary serving node using SSH.Step 6 Change to root user: su-Step 7 Update the IP table firewall rules on the secondary serving node:

a) iptables -A INPUT -s serving-node-1-eth1-address/32 -d serving-node-2-eth1-address/32 -i eth1 -p udp--dport 49186 -m state --state NEW -j ACCEPT

b) iptables -A OUTPUT -s serving-node-2-eth1-address/32 -d serving-node-1-eth1-address/32 -o eth1 -pudp --dport 49186 -m state --state NEW -j ACCEPT

Step 8 Save the configuration: service iptables save

Example:This example assumes that the primary serving node eth1 address is 10.5.2.24 and the primary serving nodehostname is blr-rms1-serving; the secondary serving node eth1 address is 10.5.2.20 and the secondary servingnode hostname is blr-rms2-serving:

Primary Serving Node:

[root@blr-rms1-serving ~]# iptables -A INPUT -s 10.5.2.20/32 -d 10.5.2.24/32 -i eth1 -p udp--dport49186 -m state --state NEW -j ACCEPT[root@blr-rms1-serving ~]# iptables -A OUTPUT -s 10.5.2.24/32 -d 10.5.2.20/32 -o eth1 -pudp --dport49186 -m state --state NEW -j ACCEPT[root@blr-rms1-serving ~]# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

Secondary Serving Node:

[root@blr-rms2-serving ~]# iptables -A INPUT -s 10.5.2.24/32 -d 10.5.2.20/32 -i eth1 -p udp--dport49186 -m state --state NEW -j ACCEPT[root@blr-rms2-serving ~]# iptables -A OUTPUT -s 10.5.2.20/32 -d 10.5.2.24/32 -o eth1 -pudp --dport49186 -m state --state NEW -j ACCEPT


RMS Installation TasksConfiguring Redundant Serving Nodes

[root@blr-rms2-serving ~]# service iptables save


Setting Up Redundant Serving NodesThis task enables the IP tables for port 61610, 61611, 1234 and 647 on both serving nodes.

Procedure

Step 1 Log in to the primary serving node using SSH.Step 2 Change to root user: su-Step 3 For each port 61610, 61611, and 647, run this command:

iptables -A OUTPUT -s serving-node-1-eth0-address /32 -d serving-node-2-eth0-address/32 -o eth0 -p udp-m udp --dport port-number -m state --state NEW -j ACCEPT

Step 4 For port 1234, run this command:iptables -A OUTPUT -s serving-node-1-eth0-address /32 -d serving-node-2-eth0-address/32 -o eth0 -p tcp-m tcp --dport port-number -m state --state NEW -j ACCEPT

Step 5 For each port 61610, 61611, and 647, run this command:iptables -A INPUT -s serving-node-2-eth0-address/32 -d serving-node-1-eth0-address/32 -i eth0 -p udp -mudp --dport port-number -m state --state NEW -j ACCEPT

Step 6 For port 1234, run this command:iptables -A INPUT -s serving-node-2-eth0-address/32 -d serving-node-1-eth0-address/32 -i eth0 -p tcp -mtcp --dport port-number -m state --state NEW -j ACCEPT

Step 7 Save the results: service iptables saveStep 8 Log in to the secondary serving node using SSH.Step 9 Change to root user: su-Step 10 For each port 61610, 61611, and 647, run this command:

iptables -A OUTPUT -s serving-node-2-eth0-address /32 -d serving-node-1-eth0-address/32 -o eth0 -p udp-m udp --dport port-number -m state --state NEW -j ACCEPT

Step 11 For port 1234, run this command:iptables -A OUTPUT -s serving-node-2-eth0-address /32 -d serving-node-1-eth0-address/32 -o eth0 -p tcp-m tcp --dport port-number -m state --state NEW -j ACCEPT

Step 12 For each port 61610, 61611, and 647, run this command:iptables -A INPUT -s serving-node-1-eth0-address/32 -d serving-node-2-eth0-address/32 -i eth0 -p udp -mudp --dport port-number -m state --state NEW -j ACCEPT

Step 13 For port 1234, run this command:iptables -A INPUT -s serving-node-1-eth0-address/32 -d serving-node-2-eth0-address/32 -i eth0 -p tcp -mtcp --dport port-number -m state --state NEW -j ACCEPT

Step 14 Save the results: service iptables save


RMS Installation TasksSetting Up Redundant Serving Nodes

Example:This example assumes that the primary serving node eth0 address is 10.5.1.24 and that the secondary servingnode eth0 address is 10.5.1.20:

Serving Node Eth0:

[root@blr-rms11-serving ~]# iptables -A OUTPUT -s 10.5.1.24/32 -d 10.5.1.20/32 -o eth0 -pudp -m udp

--dport 61610 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# iptables -A OUTPUT -s 10.5.1.24/32 -d 10.5.1.20/32 -o eth0 -pudp -m udp

--sport 61611 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# iptables -A OUTPUT -s 10.5.1.24/32 -d 10.5.1.20/32 -o eth0 -ptcp -m tcp

--dport 1234 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# iptables -A OUTPUT -s 10.5.1.24/32 -d 10.5.1.20/32 -o eth0 -pudp -m udp

--dport 647 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# iptables -A INPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -i eth0 -pudp -m udp


--dport 61611 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# iptables -A INPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -i eth0 -ptcp -m tcp


--dport 647 -m state --state NEW -j ACCEPT[root@blr-rms11-serving ~]# service iptables save


Serving Node Eth1:

[root@blr-rms12-serving ~]# iptables -A OUTPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -o eth0-p udp -m udp

--dport 61610 -m state --state NEW -j ACCEPT[root@blr-rms12-serving ~]# iptables -A OUTPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -o eth0-p udp -m udp

--sport 61611 -m state --state NEW -j ACCEPT[root@blr-rms12-serving ~]# iptables -A OUTPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -o eth0-p tcp -m tcp

--dport 1234 -m state --state NEW -j ACCEPT[root@blr-rms12-serving ~]# iptables -A OUTPUT -s 10.5.1.20/32 -d 10.5.1.24/32 -o eth0-p udp -m udp



--dport 61611 -m state --state NEW -j ACCEPT[root@blr-rms12-serving ~]# iptables -A INPUT -s 10.5.1.24/32 -d 10.5.1.20/32 -i eth0 -ptcp -m tcp


--dport 647 -m state --state NEW -j ACCEPT[root@blr-rms12-serving ~]# service iptables save



RMS Installation TasksSetting Up Redundant Serving Nodes

Configuring the PNR for RedundancyUse this task to verify that all DPEs and the network registrar are ready in the BAC UI and that two DPEsand two PNRs are in one provisioning group in the BAC UI.

Procedure

Step 1 Log into the PNR on the primary PNR DHCP server via the serving node CLI:/rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin

Enter the password when prompted.

Step 2 Configure the backup DHCP server (2nd Serving Node's IP (eth0):cluster Backup-cluster create Backup DHCP server IP address admin=admin username password=useradmin password product-version=version number

Example:

nrcmd> cluster Backup-cluster create 10.5.1.20 admin=cnradminpassword=Ch@ngeme1 product-version=8.1.3 scp-port=1234

100 OkBackup-cluster:

admin = cnradminatul-port =cluster-id = 2fqdn =http-port =https-port =ipaddr = 10.5.1.20licensed-services =local-servers =name = Backup-clusterpassword =password-secret = 00:00:00:00:00:00:00:5apoll-lease-hist-interval =poll-lease-hist-offset =poll-lease-hist-retry =poll-replica-interval = [default=4h]poll-replica-offset = [default=4h]poll-subnet-util-interval =poll-subnet-util-offset =poll-subnet-util-retry =product-version = 8.1.3remote-id =replication-initialized = [default=false]restore-state = [default=active]scp-port = 1234scp-read-timeout = [default=20m]shared-secret =tenant-id = 0 tag: coreuse-https-port = [default=false]use-ssl = [default=optional]

Step 3 Configure the DHCP servers:failover-pair femto-dhcp-failover createMain DHCP server IP address Backup DHCP server IP addressmain=localhost backup=Backup-cluster backup-pct=20 mclt=57600


RMS Installation TasksConfiguring the PNR for Redundancy

Example:

nrcmd> failover-pair femto-dhcp-failover create 10.5.1.24 10.5.1.20main=localhost backup=Backup-cluster backup-pct=20 mclt=57600

100 Okfemto-dhcp-failover:

backup = Backup-clusterbackup-pct = 20%backup-server = 10.5.1.20dynamic-bootp-backup-pct =failover = [default=true]load-balancing = [default=disabled]main = localhostmain-server = 10.5.1.24mclt = 16hname = femto-dhcp-failoverpersist-lease-data-on-partner-ack = [default=true]safe-period = [default=24h]scopetemplate =tenant-id = 0 tag: coreuse-safe-period = [default=disabled]

Step 4 Save the configuration: save

Example:

nrcmd>save

100 Ok

Step 5 Reload the primary DHCP server: server dhcp reload

Example:

nrcmd> server dhcp reload

100 Ok

Step 6 Configure the primary to secondary synchronization:a) cluster localhost set admin=admin user password=admin password

Example:

nrcmd> cluster localhost set admin=cnradmin password=Ch@ngeme1

100 Ok

b) failover-pair femto-dhcp-failover sync exact main-to-backup

Example:

nrcmd> failover-pair femto-dhcp-failover sync exact main-to-backup

101 Ok, with warnings((ClassName RemoteRequestStatus)(error 2147577914)(exception-list[((ClassName ConsistencyDetail)(error-code 2147577914)(error-object((ClassName DHCPTCPListener)(ObjectID OID-00:00:00:00:00:00:00:42)(SequenceNo 30)(name femto-leasequery-listener)(address 0.0.0.0)(port 61610)))(classid 1155)(error-attr-list [((ClassName AttrErrorDetail)(attr-id-list [03 ])(error-code 2147577914)(error-string DHCPTCPListener 'femto-leasequery-listener'



address will be unset. The default value will apply.))]))]))

The above error is due to the change in the secondary PNR dhcp-listener-address. Change thedhcp-listner-address in the secondary PNR as mentioned in the next steps.

Note

c) failover-pair femto-dhcp-failover sync exact main-to-backup

Example:

nrcmd> failover-pair femto-dhcp-failover sync exact main-to-backup

101 Ok, with warnings((ClassName RemoteRequestStatus)(error 2147577914)(exception-list[((ClassName ConsistencyDetail)(error-code 2147577914)(error-object((ClassName DHCPTCPListener)(ObjectID OID-00:00:00:00:00:00:00:42)(SequenceNo 30)(name femto-leasequery-listener)(address 0.0.0.0)(port 61610)))(classid 1155)(error-attr-list [((ClassName AttrErrorDetail)(attr-id-list [03 ])(error-code 2147577914)(error-string DHCPTCPListener 'femto-leasequery-listener'address will be unset. The default value will apply.))]))]))

The above error is due to the change in the secondary PNR dhcp-listener-address. Change thedhcp-listner-address in the secondary PNR as mentioned in the next steps.

Note

Step 7 Log in to the secondary PNR: /rms/app/nwreg2/local/usrbin/nrcmd -N cnradminEnter the password when prompted.

Step 8 Configure the femto lease query listener:dhcp-listener femto-leasequery-listener set address=Serving node eth0 Ip Address

This address must be the secondary PNR IP address which is the serving node eth0 IP address.

Example:

nrcmd> dhcp-listener femto-leasequery-listener set address=10.5.1.20

100 Oknrcmd> dhcp-listener list

100 Okfemto-leasequery-listener:

address = 10.5.1.20backlog = [default=5]enable = [default=true]ip6address =leasequery-backlog-time = [default=120]leasequery-idle-timeout = [default=60]leasequery-max-pending-notifications = [default=120000]leasequery-packet-rate-when-busy = [default=500]leasequery-send-all = [default=false]max-connections = [default=10]name = femto-leasequery-listenerport = 61610receive-timeout = [default=30]send-timeout = [default=120]

Step 9 Reload the secondary DHCP server: server dhcp reload

Example:

nrcmd> server dhcp reload

100 Ok

Step 10 Verify communication: dhcp getRelatedServers



Example:

nrcmd> dhcp getRelatedServers

100 OkType Name Address Requests Communications State PartnerRole Partner StateMAIN -- 10.5.1.24 0 OK NORMAL MAIN

NORMALTCP-L blrrms-Serving-02.cisco.com 10.5.1.20,61610 0 NONE listening --

--

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 config

context HNBGWip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocationipsec transform-set ipsec-vmct#exitikev2-ikesa transform-set ikesa-vmct#exitcrypto template vmct-asr5k ikev2-dynamicauthentication local certificateauthentication remote certificateikev2-ikesa transform-set list ikesa-vmctkeepalive interval 120payload vmct-sa0 match childsa match ipv4ip-address-alloc dynamicipsec transform-set list ipsec-vmcttsr start-address 10.5.1.0 end-address 10.5.1.255

#exitnai idr 10.5.1.91 id-type ip-addrikev2-ikesa keepalive-user-activitycertificate 10-5-1-91ca-certificate list ca-cert-name TEF_CPE_SubCA ca-cert-name Ubi_Cisco_Int_ca

#exitinterface Iu-Ps-Cs-Hip address 10.5.1.91 255.255.255.0ip address 10.5.1.92 255.255.255.0 secondaryip address 10.5.1.93 255.255.255.0 secondary

#exitsubscriber defaultdhcp service CNR context HNBGWip context-name HNBGWip address pool name ipsec

exit


RMS Installation TasksConfiguring the Security Gateway on the ASR 5000 for Redundancy

radius change-authorize-nas-ip 10.5.1.92 encrypted key+A1rxtnjd9vom7g1ugk4buohqxtt073pbivjonsvn3olnz2wsl0sm5event-timestamp-window 0 no-reverse-path-forward-check

aaa group defaultradius max-retries 2radius max-transmissions 5radius timeout 1radius attribute nas-ip-address address 10.5.1.92radius server 10.5.1.20 encrypted key

+A3qji4gwxyne5y3s09r8uzi5ot70fbyzzzzgbso92ladvtv7umjcjport 1812 priority 2

radius server 1.4.2.90 encrypted key+A1z4194hjj9zvm24t0vdmob18b329iod1jj76kjh1pzsy3w46m9h4port 1812 priority 1

#exitgtpp group default#exitgtpu-service GTPU_FAP_1bind ipv4-address 10.5.1.93

exitdhcp-service CNRdhcp client-identifier ike-iddhcp server 10.5.1.20dhcp server 10.5.1.24no dhcp chaddr-validatedhcp server selection-algorithm use-alldhcp server port 61610bind address 10.5.1.92

#exitdhcp-server-profile CNR#exithnbgw-service HNBGW_1sctp bind address 10.5.1.93sctp bind port 29169associate gtpu-service GTPU_FAP_1sctp sack-frequency 5sctp sack-period 5no sctp connection-timeoutno ue registration-timeouthnb-identity oui discard-leading-charhnb-access-mode mismatch-action accept-aaa-valueradio-network-plmn mcc 116 mnc 116rnc-id 116

security-gateway bind address 10.5.1.91 crypto-template vmct-asr5k context HNBGW#exitip route 0.0.0.0 0.0.0.0 10.5.1.1 Iu-Ps-Cs-Hip route 10.5.3.128 255.255.255.128 10.5.1.1 Iu-Ps-Cs-Hip igmp profile default#exit

#exitend

Step 4 If the second DHCP server is not configured, run these commands to configure it:a) configureb) context HNBGWc) dhcp-service CNRd) dhcp server <dhcp-server-2-IP-Addr >e) dhcp server selection-algorithm use-allVerify that the second DHCP server is configured by examining the output from this step.

Exit from the config mode and view the DHCPip.

Note

Example:

[local]blrrms-xt2-03# configure


RMS Installation TasksConfiguring the Security Gateway on the ASR 5000 for Redundancy

[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 config

Step 6 Save the changes by executing the following command:[local]blrrms-xt2-03# save config /flash/xt2-03-aug12

Configuring the HNB Gateway for Redundancy

Procedure

Step 1 Login 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 config

context HNBGWip pool ipsec range 7.0.1.48 7.0.1.63 public 0 policy allow-static-allocationipsec transform-set ipsec-vmct#exitikev2-ikesa transform-set ikesa-vmct#exitcrypto template vmct-asr5k ikev2-dynamicauthentication local certificateauthentication remote certificateikev2-ikesa transform-set list ikesa-vmctkeepalive interval 120payload vmct-sa0 match childsa match ipv4ip-address-alloc dynamicipsec transform-set list ipsec-vmcttsr start-address 10.5.1.0 end-address 10.5.1.255

#exitnai idr 10.5.1.91 id-type ip-addrikev2-ikesa keepalive-user-activitycertificate 10-5-1-91ca-certificate list ca-cert-name TEF_CPE_SubCA ca-cert-name Ubi_Cisco_Int_ca

#exitinterface Iu-Ps-Cs-Hip address 10.5.1.91 255.255.255.0ip address 10.5.1.92 255.255.255.0 secondaryip address 10.5.1.93 255.255.255.0 secondary

#exitsubscriber defaultdhcp service CNR context HNBGWip context-name HNBGWip address pool name ipsec

exitradius change-authorize-nas-ip 10.5.1.92 encrypted key


RMS Installation TasksConfiguring the HNB Gateway for Redundancy

+A1rxtnjd9vom7g1ugk4buohqxtt073pbivjonsvn3olnz2wsl0sm5event-timestamp-window 0 no-reverse-path-forward-check

aaa group defaultradius max-retries 2radius max-transmissions 5radius timeout 1radius attribute nas-ip-address address 10.5.1.92radius server 10.5.1.20 encrypted key

+A3qji4gwxyne5y3s09r8uzi5ot70fbyzzzzgbso92ladvtv7umjcjport 1812 priority 2

radius server 1.4.2.90 encrypted key+A1z4194hjj9zvm24t0vdmob18b329iod1jj76kjh1pzsy3w46m9h4

port 1812 priority 1#exitgtpp group default#exitgtpu-service GTPU_FAP_1bind ipv4-address 10.5.1.93

exitdhcp-service CNRdhcp client-identifier ike-iddhcp server 10.5.1.20dhcp server 10.5.1.24no dhcp chaddr-validatedhcp server selection-algorithm use-alldhcp server port 61610bind address 10.5.1.92

#exitdhcp-server-profile CNR#exithnbgw-service HNBGW_1sctp bind address 10.5.1.93sctp bind port 29169associate gtpu-service GTPU_FAP_1sctp sack-frequency 5sctp sack-period 5no sctp connection-timeoutno ue registration-timeouthnb-identity oui discard-leading-charhnb-access-mode mismatch-action accept-aaa-valueradio-network-plmn mcc 116 mnc 116rnc-id 116

security-gateway bind address 10.5.1.91 crypto-template vmct-asr5k context HNBGW#exitip route 0.0.0.0 0.0.0.0 10.5.1.1 Iu-Ps-Cs-Hip route 10.5.3.128 255.255.255.128 10.5.1.1 Iu-Ps-Cs-Hip igmp profile default#exit

#exitend

Step 3 If the radius server configuration is not as shown in the above example, perform the following configuration:a) configureb) context HNBGW_context_namec) radius server radius-server-ip-address key secret port 1812 priority 2

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


RMS Installation TasksConfiguring the HNB Gateway for Redundancy

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:a) configureb) context hnbgw_context_namec) radius max-retries 2d) radius timeout 1After 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 2radius max-transmissions 5radius timeout 1

What to Do Next

After the configuration is complete, the HNBGW sends access request trice to the primary PAR with a onesecond time delay between the two requests.

Optimizing the Virtual MachinesTo run the RMS software, you need to verify that the VMs that you are running are up-to-date and configuredoptimally. Use these tasks to optimize your VMs.

Upgrading the VM Hardware VersionTo have better performance parameter options available (for example, more virtual CPU and memory), theVMware hardware version needs to be upgraded to version 8 or above. You can upgrade the version usingthe vSphere client .


RMS Installation TasksOptimizing the Virtual Machines

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

Figure 3: VMware Hardware Version


RMS Installation TasksUpgrading the VM 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 VirtualHardware.The software upgrades the virtual machine hardware to the latest supported version.

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

Note

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.


RMS Installation TasksUpgrading the VM Hardware Version

Upgrading the VM CPU and Memory Settings

Before You Begin

Upgrade the VM hardware version as described in Upgrading the VM Hardware Version, on page 21.

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

Note

Procedure

Step 1 Start the vSphere client.Step 2 Right-click the vApp for one of the RMS nodes and select Power Off.Step 3 Right-click the virtual machine for an RMS node (central, serving, upload) and select Edit Settings.Step 4 Select theHardware Tab. ClickMemory in the hardware device list on the left side of the screen and update

the Memory Size.Step 5 ClickCPUs in the hardware device list on the left side of the screen and update the Number of virtual sockets.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 Upload VM Data Sizing

Refer to Virtualization Requirements for more information on data sizing.Note


RMS Installation TasksUpgrading the VM CPU and Memory Settings



Procedure

Step 1 Log in to the vSphere client and connect to a specific vCenter server.Step 2 Click the Upload VM and click the Summary tab to view the available free disk space. 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 Click the Hardware tab. ClickHard disk 1 in the hardware device list on the left side of the screen and change

the Provisioned Size value to minimum 300 GB to retain one day logs uploaded by 10,000 devices.Step 6 Click OK.Step 7 Right-click the VM and select Power followed by Power On.Step 8 Log in to the Upload node.

a) Log in to the Central node VM using the central node eth1 address.b) ssh to the Upload VM using the upload node hostname.

Example:ssh admin1@blr-rms14-upload

Step 9 Check the effective disk space after expanding: fdisk -l

Example:

[admin1@blr-rms14-upload ~]$ su - rootPassword:[root@blr-rms14-upload ~]#[root@blr-rms14-upload ~]# iduid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),501(wami) context=user_u:user_r:policykit_grant_t:s0[root@blr-rms14-upload ~]# fdisk -l

Disk /dev/sda: 214.7 GB, 214748364800 bytes255 heads, 63 sectors/track, 26108 cylindersUnits = cylinders of 16065 * 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytes


RMS Installation TasksUpgrading the Upload VM Data Sizing

Disk identifier: 0x000463d0

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

Step 10 Create the extended partition: fdisk /dev/sd

Example:

[root@blr-rms14-upload ~]# fdisk /dev/sda

WARNING: DOS-compatible mode is deprecated. it's strongly recommended toswitch off the mode (command 'c') and change display units tosectors (command 'u').

Command (m for help): nCommand action

e extendedp primary partition (1-4)

eSelected partition 4First cylinder (6528-26108, default 6528): 6528Last cylinder, +cylinders or +size{K,M,G} (6528-26108, default 26108):Using default value 26108

Follow the on-screen prompts carefully as a small mistake can corrupt the entire system.Warning

Step 11 Create a logical partition on the extended partition.

Example:

Command (m for help): nFirst clinder (6528-26108, default 6528):Using default value 26108Last cylinder, +cylinders or +size{K,M,G} (6528-26108, default 26108):Using default value 26108

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

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resourcebusy.

The kernel still uses the old table. The new table will be used atthe next reboot or after you run partprobe(8) or kpartx(8)Syncing disks.[root@blr-rms14-upload ~]#

Step 12 Reboot the system: rebootAfter the reboot completes, log back into the server and switch to root user.

Step 13 Verify that the new partition was created: fdisk -l

Example:

[root@blr-rms14-upload ~]# fdisk -l

Disk /dev/sda: 214.7 GB, 214748364800 bytes255 heads, 63 sectors/track, 26108 cylindersUnits = cylinders of 16065*512 = 8225280 bytes



Sector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x0004b3d0

Device Boot Start End Blocks Id System/dev/sda1 * 1 17 131072 83 LinuxPartition 1 does not end on cylinder boundary./dev/sda2 17 33 131072 82 Linux swap / SolarisPartition 2 does not end on cylinder boundary./dev/sda3 33 6528 52165632 83 Linux/dev/sda4 6528 26108 157283710 5 Extended/dev/sda5 6528 26108 157283678+ 83 Linux

Step 14 Create ext3 FS on the new partition:mkfs -t ext3 /dev/sda5

Example:

[root@blr-rms14-upload ~]# mkfs -t ext3 /dev/sda5mke2fs 1.41.12 (17-May-2010)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Stride=0 blocks, Stripe width=0 blocks9830400 inodes, 39320919 blocks1966045 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=42949672961200 block groups32768 blocks per group, 32768 fragments per group8192 idnodes per groupSuperblock backups stored on blocks:

32768, 98304, 163840, 229378, 294912, 819200, 884736, 1605632, 2654208,4096000, 7962624, 11239424, 20480000, 23887872

Wireing inode tables: doneCreating journal (32768 blocks): doneWriting superblocks and filesystem accounting invormation: done

This filesystem will be automatically checked every 26 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.[root@blr-rms14-upload ~]#

Step 15 Verify ownership of the mounting directory: ls -al /opt/CSCOuls/

Example:

[root@blr-rms14-upload ~]# ls -l /opt/CSCOuls/total 28drwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 bindrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 14:36 confdrwxr-xr-x. 5 ciscorms ciscorms 4096 Mar 7 21:30 filesdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 libdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 15:00 logsdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 16:54 rundrwxr-xr-x. 3 root root 4096 Mar 7 21:29 server-perf[root@blr-rms14-upload ~]#

Step 16 Open the file that permanently mounts the volume/partition with the mount point and add entry related to thenew partition (/dev/sda5 /opt/CSCOuls/files ext3 defaults 0 0) and save the file: vi /etc/fstab

Example:

## /etc/fstab#Created by anaconda on Fri Mar 7 10:56:44 2014#



# Accessible filesystems, by reference, are maintained under '/dev/disk'# See man pages fstag(5), findfs(8), mount(8) and/or blkid(8) for more info#UUID=a415c4c0-9657-4548-b599-b338c2d815f6 / ext3 defaults 1 1UUID=1bdc029d-ddc6-4130-bf78-2e8253bd85a4 /boot ext3 defaults 1 1UUID=086decf2-7e0a-445f-8775-b2377904f962 swap swap defaults 0 0tmpfs /dev/shm tmpfs defaults 0 0devpts /dev/pts devpts gid=5,mode=620 0 0sysfs /sys sysfs defaults 0 0proc /proc proc defaults 0 0/dev/sda5 /opt/CSCOuls/files ext3 defaults 0 0

Step 17 Check the new volume:mount -a

Example:

[root@blr-rms14-upload ~]# mount -a[root@blr-rms14-upload ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/sda3 49G 1.4G 46G 3% /tmpfs 7.8G 0 7.8G 0% /dev/shm/dev/sda1 124M 25M 94M 21% /boot/dev/sda5 148G 188M 140G 1% /opt/CSCOuls/files[root@blr-rms14-upload ~]#

Step 18 Check ownership of the files directory after the mount and change it to ciscorms: ls -l /opt/CSCOuls/

Example:

[root@blr-rms14-upload ~]# ls -l /opt/CSCOuls/total 28drwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 bindrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 14:36 confdrwxr-xr-x. 3 root root 4096 Mar 11 17:30 filesdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 libdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 15:00 logsdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 16:54 rundrwxr-xr-x. 3 root root 4096 Mar 7 21:29 server-perf

[root@blr-rms14-upload ~]# chown -R ciscorms:ciscorms /opt/CSCOuls/files/[root@blr-rms14-upload ~]# ls -l /opt/CSCOuls/total 28drwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 bindrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 14:36 confdrwxr-xr-x. 3 ciscorms ciscorms 4096 Mar 11 17:30 filesdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 7 21:29 libdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 15:00 logsdrwxr-xr-x. 2 ciscorms ciscorms 4096 Mar 11 16:54 rundrwxr-xr-x. 3 root root 4096 Mar 7 21:29 server-perf

Step 19 Reboot the system: rebootAfter the system restarts, log in to the server.

Upload Server Tuning for 15min Upload IntervalThe following upload server properties can support:

• 10K APs for the PM/Stat file size of 500KB



RMS Installation TasksUpload Server Tuning for 15min Upload Interval


The minimum disk space allocation required is 300GB for retaining raw files for 1 hour and archived filesfor 24 hours for 10,000 devices.

Upload server periodically cleans up the uploaded files if the disk utilization exceeds the threshold value.

Procedure

Step 1 Log in to the central node ssh admin1@<rdu_ip_address>Step 2 Log in to the Upload Server from the Central Node ssh admin1@<uls_ip_address>Step 3 Change to root user: su-Step 4 Change to config directory user: cd /opt/CSCOuls/confStep 5 Edit the file UploadServer.properties and update the properties listed below:

Note: The maxgb=300 in the below property is the size of the directory /opt/CSCOuls/filesin GB. This value varies on the disk size.

UploadServer.disk.alloc.global.maxgb=300

UploadServer.server.filemanager.taskscheduler.dirmaint.initialdelay.minutes=1440UploadServer.server.filemanager.taskscheduler.dirmaint.interval.minutes=1440

Note: The below properties needs to be modified for each of the file_type such as stat,on-periodic, on-call-drop and so on.UploadServer.files.upload.<file_type>.archiverawfiles.interval.minutes=60UploadServer.files.upload.<file_type>.archiving.compression.enabled=trueUploadServer.files.upload.<file_type>.archiving.enabled=true

UploadServer.files.upload.<file_type>.archive.delete.threshexceeded=trueUploadServer.files.upload.<file_type>.raw.delete.threshexceeded=falseUploadServer.files.upload.<file_type>.raw.delete.afterarchived=trueUploadServer.files.upload.<file_type>.pctoftotaldiskspacetofree=100

Step 6 Restart the ULS service: service god restart

RMS Installation Sanity Check

Sanity Check for the BAC UIFollowing the installation, perform this procedure to ensure that all connections are established.

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

Note


RMS Installation TasksRMS Installation Sanity Check

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 theReady 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 fordeployment. 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 descriptorfile used for deployment. Click on the Provisioning group name. The display should indicate the ACSURL pointing to the value of the property, “prop: Acs_Virtual_Fqdn” that you specified in the descriptorfile.

• 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 UIFollowing the installation, perform this procedure to ensure that all connections are established.


RMS Installation TasksSanity Check for the DCC UI

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 Ch@ngeme1.

Step 2 Click the Groups and IDs tab and verify that the Group Types table shows Area, Femto Gateway, RFProfile,Enterprise and Site.

Verifying Application ProcessesVerify 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 runningProcess [snmpAgent] is runningProcess [rdu] is runningProcess [tomcat] is running

Step 3 Run: /rms/app/nwreg2/regional/usrbin/cnr_status

[rtpfga-ova-central06] ~ # /rms/app/nwreg2/regional/usrbin/cnr_statusServer Agent running (pid: 4564)CCM Server running (pid: 4567)WEB Server running (pid: 4568)RIC Server Running (pid:v4569)

Step 4 Log in to the Serving node.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.


RMS Installation TasksVerifying Application Processes

Step 6 Run: /rms/app/nwreg2/local/usrbin/cnr_status

[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 runningDNS Server is not runningDNS 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 Log in to the Upload node..Step 9 Run: service god status

[rtpfga-s1-upload1] ~ # service god status

UploadServer: up

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

Note


RMS Installation TasksVerifying Application Processes


RMS Installation Tasks - Cisco · RMS Installation Tasks PerformthesetaskstoinstalltheRMSsoftware....

Documents

Transcript of RMS Installation Tasks - Cisco · RMS Installation Tasks PerformthesetaskstoinstalltheRMSsoftware....