Cisco CDA Visual Quality Experience Application User Guide, Release 2.1 - Getting Started with the VQE Startup Configuration Utility [Cisco Videoscape Distribution Suite for Internet Streaming]

Table Of Contents

Getting Started with the VQE Startup Configuration Utility

Web Browser, Screen Resolution, and Other Requirements

Configuring Terminal Emulation Software

Security Restrictions

Prerequisites

Connecting Cables to the CDE110

Setting Up SSL Certificates with the VQE Startup Configuration Utility

Setting Up SSL Certificates

Using the Cisco VQE Startup Configuration Utility for SSL Certificates

Step-by-Step Example: VQE Startup Configuration Utility's Option 2 for Preparing SSL Certificates

Creating Your Own Certificate Authority

Generating and Deploying Your Own SSL Certificates

Generating a Certificate Signing Request

Signing the Certificate Signing Request

Installing the Certificates, Private Key, and Keystore

Deploying Commercial SSL Certificates

Commercial CA: Installing the Certificates, Private Key, and Keystore

Getting Started Using the VQE Startup Configuration Utility

Configuration Items

Pre-Configuration Worksheets

On the VQE-S Host: Verifying Status of VQE and System Services

On the VCPT Host: Verifying Status of VQE and System Services

Configuring VQE-S RTCP Exporter

Stopping and Restarting VQE-S

Getting Started with the VQE Startup Configuration Utility

This chapter explains how to use the Cisco VQE Startup Configuration Utility to perform the initial configuration tasks needed to get the two categories of Cisco CDE110 appliances running with the Cisco VQE software:

•CDE110 hosting VQE Server (VQE-S)

•CDE110 hosting VQE Channel Provisioning Tool (VCPT) and VQE Client Channel Configuration Delivery Server (VCDS)

Use of VCPT in a VQE deployment is optional.

Note Cisco recommends that you use the VQE Startup Configuration Utility rather than try to do the initial configuration manually because the utility simplifies your work and is known to produce correct results.

For information on the manual initial VQE configuration tasks, see Appendix D, "Manual Initial VQE System Configuration."

Read the following sections for information on CDE110 configuration and on using the VQE Startup Configuration Utility:

•Web Browser, Screen Resolution, and Other Requirements

•Configuring Terminal Emulation Software

•Security Restrictions

•Prerequisites

•Setting Up SSL Certificates

•Getting Started Using the VQE Startup Configuration Utility

•On the VQE-S Host: Verifying Status of VQE and System Services

•On the VCPT Host: Verifying Status of VQE and System Services

•Configuring VQE-S RTCP Exporter

Note The configuration instructions in this chapter are intended for new installations of Cisco VQE Release 2.1 software, where the Cisco CDE110 has the Cisco VQE Release 2.1 software preinstalled.

For information on upgrading a Cisco CDE110 from Cisco VQE Release 2.0 to Release 2.1, see the Release Notes for Cisco CDA Visual Quality Experience, Release 2.1.

This chapter assumes that the Cisco CDE110 hardware has been installed as described in the Cisco Content Delivery Engine 110 Hardware Installation Guide, including connecting cables and connecting power.

Web Browser, Screen Resolution, and Other Requirements

To access the VQE-S Application Monitoring Tool (VQE-S AMT or AMT) or the VQE Channel Provisioning Tool (VCPT), you need a web browser. For these tools, the following web browsers are supported:

•Microsoft Internet Explorer version 6.0 or later

•Mozilla Firefox version 2.0 or later

The minimum screen resolution required for VQE-S AMT and VCPT is 1024 x 768 pixels.

For VQE-S AMT, Adobe Flash Player must be installed on the computer that hosts the browser accessing AMT. Flash Player is required to display the Channels Status Summary graph of active, inoperative, and inactive channels in the AMT VQE_S Status window. Adobe Flash Player is free and can be found at this URL:

http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Configuring Terminal Emulation Software

The RJ-45 serial ports on the Cisco CDE110 front and back panels can be used for administrative access to the CDE110 through a terminal server. Terminal emulation software must be configured as follows:

•Bits per second: 9600

•Data bits: 8

•Parity: none

•Stop bits: 1

•Hardware flow control: ON

Security Restrictions

For security reasons, the following restrictions apply to VQE.

•The root user cannot use Secure Shell (SSH) to log in to a CDE110 that hosts VQE-S or VCPT, or to log in to VQE-S AMT or VCPT. The vqe user should be used instead. The vqe user is a pre-created Linux user ID and has its password set during CDE110 initial system configuration.

•Only users in the wheel group can use the su or sudo commands. By default, the vqe user is in the wheel group.

If you want to add user accounts to the wheel group so that additional users can use su and sudo, log in as root and issue the following command:

usermod -G wheel username

In the preceding, username specifies the user who will be added to the wheel group.

Prerequisites

Before you start the initial VQE software configuration, these tasks must be performed on the CDE110 that hosts VQE-S and the CDE110 that hosts VCPT:

•Connecting Cables to the CDE110

•Setting Up SSL Certificates with the VQE Startup Configuration Utility

Connecting Cables to the CDE110

The following cable connections are used on the Cisco CDE110 that hosts VQE-S and on the CDE110 that hosts VCPT:

•Depending on whether the host is for VQE-S or VCPT, do one of the following:

–On a VQE-S host, use Category 5 UTP cable to connect each of the four Ethernet interfaces on the back of the Cisco CDE110 to Ethernet interfaces on the edge router that is providing multicast streams for each IPTV channel. For optimal VQE-S performance, all four Ethernet interfaces on the Cisco CDE110 should have a direct Layer-3 connection to the edge router.

–On a VCPT host, use Category 5 UTP cable to connect at least one of the four Ethernet interfaces on the back of the CDE110 to the same network that the CDE110s that host VQE-S are on. If you use additional Ethernet interfaces for link redundancy, connect Category 5 UTP cables for those interfaces also.

•If a terminal server is used, the RJ-45 cable from the terminal server is connected to an RJ-45 serial port on the front or back of the Cisco CDE110. Only one serial port can be used because it is one shared serial port.

•If a PC is directly connected to the CDE110 serial port, the cable from the PC is connected to an RJ-45 serial port on the front or back of the Cisco CDE110. Only one serial port (front or back) can be used because it is one shared serial port. The PC end of the cable connected to the CDE110 serial port varies depending on the type of ports supported by the PC.

Note The serial port is used for the system console. A system console is typically used rather than a monitor, keyboard, and mouse directly attached to the Cisco CDE110.

•If a monitor, keyboard, and mouse are used, the cables for the devices are connected to the appropriate connectors on the Cisco CDE110.

For the location of connectors on the Cisco CDE110 front and back panels, see the Cisco Content Delivery Engine 110 Hardware Installation Guide.

Setting Up SSL Certificates with the VQE Startup Configuration Utility

Secure Socket Layer (SSL) certificates must be deployed on the CDE110s for HTTPS to operate. You can let the Cisco VQE Startup Configuration Utility do most of the creation and deployment, or you can do the creation and deployment tasks yourself. For information on your options for SSL certificates with the startup wizard, see the "Using the Cisco VQE Startup Configuration Utility for SSL Certificates" section.

Setting Up SSL Certificates

VQE-S Application Monitoring Tool (VQE-S AMT or AMT) and VQE Channel Provisioning Tool (VCPT) require Secure Sockets Layer (SSL) certificates from a certificate authority (CA). The CA can be you or someone in your company, or can be a commercial CA, such as VeriSign.

On the CDE110s hosting VQE-S and VCPT, the HTTP server is not usable until the SSL certificates and other required SSL files are created and deployed.

Before AMT and VCPT can be used, you need to either deploy your own SSL certificate or deploy a commercial SSL certificate. The procedures that you use are explained in the following sections:

•Using the Cisco VQE Startup Configuration Utility for SSL Certificates

•Creating Your Own Certificate Authority

•Generating and Deploying Your Own SSL Certificates

•Deploying Commercial SSL Certificates

You perform the procedures for deploying CA certificates on the VQE-S hosts and the VCPT hosts. As an alternative if you are setting up the certificates manually, you can create the needed files on one host and copy them to the other hosts.

The Open Source toolkit from the OpenSSL Project collaborative is used to generate, sign, and install your own CA certificates and to generate the Certificate Signing Request for commercial certificates. The Open Source toolkit is installed on the VQE-S and VCPT hosts. For more information on the Open Source toolkit and for documentation on toolkit commands, go to:

http://www.openssl.org

Using the Cisco VQE Startup Configuration Utility for SSL Certificates

If you use the Cisco VQE Startup Configuration Utility, the utility allows you to choose different ways to create and deploy SSL certificates:

•Option 1: You manually deploy SSL certificates. Follow the directions in these sections for the needed information.

–For deploying your own SSL certificates, see the "Creating Your Own Certificate Authority" section and the "Generating and Deploying Your Own SSL Certificates" section.

–For deploying commercial SSL certificates, see the "Deploying Commercial SSL Certificates" section.

•Option 2: The Cisco VQE Startup Configuration Utility creates and deploys a self-signed SSL certificate (vqe.cert), private key (server.key), and stackedChain.pem file.

For an explanation of the tasks involved with using Option 2, see the "Step-by-Step Example: VQE Startup Configuration Utility's Option 2 for Preparing SSL Certificates" section.

•Option 3: The Cisco VQE Startup Configuration Utility generates only a Certificate Signing Request file (server.csr).

–The VQE Startup Configuration Utility creates the Certificate Signing Request file in the /etc/opt/certs directory.

–You sign the certificate signing request as described one of the following sections:

a) If you are signing the Certificate Signing Request with a self-created certificate authority, see the "Signing the Certificate Signing Request" section.

b) If you are submitting the Certificate Signing Request to a commercial CA for signing, see the "Deploying Commercial SSL Certificates" section. You can omit the first step in this section (generating a certificate signing request) as the VQE Startup Configuration Utility does this for you.

–You install the certificates, private key, and keystore as described in the "Installing the Certificates, Private Key, and Keystore" section.

Step-by-Step Example: VQE Startup Configuration Utility's Option 2 for Preparing SSL Certificates

This section provides a step-by-step example of the tasks that you perform when you choose Option 2 for SSL certificates preparation with the VQE Startup Configuration Utility. With Option 2, the utility creates and deploys a self-signed SSL certificate (vqe.cert), private key (server.key), and stackedChain.pem file on the CDE110 appliance.

To use the VQE Startup Configuration Utility's to create and deploy self-signed SSL certificates, do the following:

Step 1 On the CDE110 hosting VQE-S, when the VQE Startup Configuration Utility runs and displays "Prepare SSL certificate for HTTPS service," select Option 2 to create a self-signed SSL certificate.
Prepare SSL certificate for HTTPS service. Choose from following options:
1. Skip this step now and manually deploy SSL certificate later.
2. Generate a self-signed SSL certificate and deploy now. You will need to manually copy 
the certificate to the trusted VCPT host later and import it into its truststore.
3. Generate a certificate signing request and proceed. No SSL certificate will be 
deployed, you will need to sign the generated CSR file externally and manually deploy it.
Please enter your choice: [1|2|3] 2 
Generating a 2048 bit RSA private key
...
The utility creates these files in the /etc/opt/certs directory:

•Server certificate file (vqe.cert)

•Private key file (server.key)

•stackedChain.pem file

The VQE Startup Configuration Utility continues to execute until the initial configuration is completed. Finish the initial system configuration and verification of the CDE110 hosting VQE-S before performing the next step.

Step 2 On the CDE110 hosting VCPT, when the VQE Startup Configuration Utility runs and displays "Prepare SSL certificate for HTTPS service," select Option 2 to create a self-signed SSL certificate.
Prepare SSL certificate for HTTPS service. Choose from following options:
1. Skip this step now and manually deploy SSL certificate later.
2. Generate a self-signed SSL certificate and deploy now. You will need to manually copy 
the certificate to the trusted VCPT host later and import it into its truststore.
3. Generate a certificate signing request and proceed. No SSL certificate will be 
deployed, you will need to sign the generated CSR file externally and manually deploy it.
Please enter your choice: [1|2|3] 2 
Generating a 2048 bit RSA private key
...
The utility creates these files in the /etc/opt/certs directory:

•Server certificate file (vqe.cert)

•Private key file (server.key)

•stackedChain.pem file

An empty trustedca file is also created in the /etc/opt/certs directory. This file will be used on the VCPT host.

The VQE Startup Configuration Utility continues to execute until the initial configuration is completed. Finish the initial system configuration and verification of the CDE110 hosting VCPT before performing the next step.

Step 3 On the CDE110 hosting VCPT, copy the /etc/opt/certs/vqe.cert file from the VQE-S host to /etc/opt/certs/vqe.cert on the VCPT host. Use an appropriate Linux command (for example, scp) for the copy operation.

Step 4 On the CDE110 hosting VCPT, use the keytool command to create the keystore (trustedca) file. For example:
$ cd /etc/opt/certs
$ keytool -import -keystore trustedca -alias vqe1 -file vqe.cert 
Note The vqe.cert file that was copied from the VQE-S host is specified in the -file argument when invoking the keytool command.

When keytool runs, it asks for a keystore password (enter any arbitrary password you want) and asks if you trust this certificate (answer yes).

The trustedca file, where keytool writes it output, is used only on the VCPT host and must be located in the /etc/opt/certs directory.

Step 5 On the VQE-S and VCPT hosts, restart the httpd daemon by logging in as root and stopping and restarting the httpd service as follows:
[root@system]# service httpd restart 
Step 6 After the VQE-S and VCPT hosts are configured and VQE services are started, you can verify that the SSL certificates are created and deployed correctly by doing the following:

Note HTTPS must be used to access VQE-S AMT and VCPT.

a. To verify that VQE-S AMT is accessible from a web browser, enter as the URL the IP address of the Cisco CDE110 that hosts VQE-S:
https://ip_address_of_VQES_host 
The VQE-S Application Monitoring Tool login screen should be displayed.

b. To verify that VCPT is accessible from a web browser, enter as the URL the IP address of the Cisco CDE110 that hosts VCPT:
https://ip_address_of_VCPT_host 
The VQE Channel Provisioning Tool login screen should be displayed.

c. To verify that VCPT is able to send channel information to VQE-S, use VCPT to a define channels, and one or more VQE Servers with the needed channel associations. (The VQE Servers have SSL certificates deployed.) Then use VCPT to send the channel information to the VQE Servers.

The send operation should be successful if the SSL certificates were created and deployed correctly.

Creating Your Own Certificate Authority

Note This task is not needed if you are using certificates that are signed by a commercial CA.

This task to create your own certificate authority (CA) is only performed once for all instances of VQE-S and VCPT. The CA that you create can be used to sign server certificates on all CDE110 servers hosting VQE-S or VCPT.

To create a CA certificate, follow these steps:

Step 1 Log in using a valid Linux username and password.

Step 2 To generate an encrypted RSA private key, issue the following command:
$ openssl genrsa -des3 -out ca.key 4096 
The command prompts you to enter a pass phrase to protect the private key. The pass phrase will be needed every time this CA signs a certificate request.

The openssl genrsa command saves the ca.key file in your current working directory.

The generated key is a 4096-bit RSA key, which is encrypted using Triple-DES and stored in PEM format so that it is readable as ASCII text.

Step 3 To generate the CA certificate, issue the following command:
$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt 
The command prompts for the following X.509 attributes of the certificate. It is recommended that you provide valid input for X.509 information. Use a period (.) to indicate blank input.

•Country Name—The country where your company resides. Use the two-letter country code without punctuation for country (for example, US or FR).

•State or Province—The state or province where your company resides. Spell out the state completely (for example, California). Do not abbreviate the state or province name.

•Locality or City—The city or town where your company resides (for example, Berkeley).

•Company—Your company's name (for example, XYZ Corporation). If your company or department name has an &, @, or any other symbol that requires using the Shift key in its name, you must spell out the symbol or omit it to enroll.

•Organizational Unit—The organization within the company. This field is optional but can be used to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request. To skip the OU field, press Enter.

•Common Name—The Common Name is the host plus the domain name (for example, www.company.com or "company.com).

The openssl req command saves the ca.crt file in your current working directory.

Generating and Deploying Your Own SSL Certificates

When you act as your own certificate authority, you can sign multiple Certificate Signing Requests for the VQE-S hosts and the VCPT hosts. Generating and deploying your own SSL certificates involves three tasks:

1. Generate a Certificate Signing Request.

2. Sign the Certificate Signing Request.

3. Install the certificates, private key, and keystore.

These tasks are explained in the following three sections. We recommend that these tasks be repeated for each CDE110 host so that there is a unique set of files generated for each host. You can create the needed sets of files on one host and copy them to the other hosts.

Generating a Certificate Signing Request

To generate a Certificate Signing Request, follow these steps:

Step 1 To generate a server private key, issue the following command:
$ openssl genrsa -des3 -out server.key 1024 
To bypass the pass-phrase requirement, omit the -des3 option when generating the private key. Bypassing the pass phrase is desirable when you want the Apache web server to be autostarted without human intervention. Otherwise, someone must enter a pass phrase on every restart.

The openssl genrsa command saves the server.key file in your current working directory.

Note We recommend that access to the Cisco CDE110 host be restricted so that only authorized server administrators can access or read the private key file.

Step 2 To generate the Certificate Signing Request (CSR), issue the following command:
$ openssl req -new -key server.key -out server.csr 
The command prompts for the same X.509 attributes that were specified when you created your CA certificate in the "Creating Your Own Certificate Authority" section. It is recommended that you provide valid input for X.509 information. Use a period (.) to indicate blank input.

Note The Common Name (CN) of the CA and the server certificates should not match or else a naming collision occurs and you get errors when the certificates are used.

The openssl req command saves the server.csr file in your current working directory.

The command creates a public/private key pair. The private key (server.key) is stored locally on the server machine and is used for decryption. The public portion, in the form of a Certificate Signing Request (server.csr), is used for certificate enrollment with the CA.

Tip If you are creating server certificate requests for multiple VQE-S or VCPT hosts and want to reuse most of the X.509 attributes, you can save the information to a file (openssl.cnf) and pass the information to the openssl req command by specifying -config openssl.cnf on the command line.

Signing the Certificate Signing Request

The Certificate Signing Request (CSR) can be signed by commercial CA entities, such as VeriSign, or by your own CA as created in the "Creating Your Own Certificate Authority" section.

Note If you will use a self-created (non-commercial) CA, signing the Certificate Signing Request must be done on the same CDE110 server where the CA was created.

We recommend that the system time of each CDE110 be synchronized with Network Time Protocol (NTP). The system time when the signing of the Certificate Signing Request occurs must be later than the system time when the CA was created.

To sign the Certificate Signing Request with the self-created certificate authority, issue the following command:
$ openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 
-out server.crt 
The openssl x509 command saves server.crt in your current working directory.

In the example above, the serial number of the signed server certificate is set to 01. Each time you execute this command, you must change the serial number, especially if you sign another certificate before a previously-signed certificate is expired.

Installing the Certificates, Private Key, and Keystore

The certificate needs to be in certain format and to reside in a designated directory to be used by the VQE Server-related or the VCPT-related software.

To install the server and CA certificates, the private key and the keystore, follow these steps:

Step 1 To create a "stacked PEM" file, concatenate the contents of the server certificate file (server.crt) and all CA certificate files (ca.crt) in the CA chain to a file named stackedChain.pem. The safest way to create the stackedChain.pem file is to use the Linux cat command. For example:
$ cat server.crt ca.crt > stackedChain.pem 
Note Using a text editor and a cut-and paste-operation to concatenate the server and CA certificates can produce unusable results because the text editor may add extraneous characters.

The stackedChain.pem file content must be in this order:
-----BEGIN CERTIFICATE-----
<SSL Server Cert Contents>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<CA Cert Contents>
-----END CERTIFICATE-----
The stackedChain.pem file looks something like the following:
-----BEGIN CERTIFICATE-----
MIIDvjCCAaYCAQEwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxDTALBgNV
... Omitted contents ... 
/kzgDk5wO1CbTwuxPIY1piy0Os1Q5EWk3VVAmv4tNMT9bANeKDUiVyYyOi1NIiHA
36w=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGGDCCBACgAwIBAgIJAPtvlrCRokk4MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNV
... Omitted contents ... 
KV+sxNECGE40iWIvd1dXDA1O34qhAwkVD6/bxw==
-----END CERTIFICATE-----
Note If you are creating stackedChain.pem files for multiple VQE-S or VCPT hosts, the server.crt file should be different for each host.

Step 2 For VCPT only, to create a trust-store file for the SSL Java client, issue the following command:
$ keytool -import -keystore trustedca -alias rootca -file ca.crt 
The CA certificate (ca.crt) specified in the -file argument is the CA certificate that you created in the "Creating Your Own Certificate Authority" section.

The keytool command creates a new keystore with the CA certificate. The resulting file is named trustedca.

Step 3 Do one of the following:

•On a VQE-S host, copy the following files to the directory /etc/opt/certs:

–server.key

–stackedChain.pem

•On a VCPT host, copy the following files to the directory /etc/opt/certs:

–server.key

–stackedChain.pem

–trustedca

Deploying Commercial SSL Certificates

As an alternative to acting as your own certificate authority (CA), commercial certificate authorities, such as VeriSign, can issue and sign Secure Sockets Layer (SSL) certificates.

Deploying a commercial certificate involves these steps:

1. Generate a Certificate Signing Request. See the "Generating a Certificate Signing Request" section.

2. Submit the Certificate Signing Request to the commercial CA for signing.

3. Install the certificates, private key, and keystore. See the "Commercial CA: Installing the Certificates, Private Key, and Keystore" section that follows.

Commercial CA: Installing the Certificates, Private Key, and Keystore

When you get the signed certificates back from the commercial CA, you need to install them and the private key and keystore.

To install the certificates, private key, and keystore, follow these steps:

Step 1 To create a "stacked PEM" file, concatenate the contents of the server certificate file (server.crt) and all CA certificate files (ca.crt) in the CA chain to a file named stackedChain.pem. The safest way to create the stackedChain.pem file is to use the Linux cat command. For example:
$ cat server.crt ca.crt > stackedChain.pem 
Note Using a text editor and a cut-and paste-operation to concatenate the server and CA certificates can produce unusable results because the text editor may add extraneous characters.

The stackedChain.pem file content must be in this order:
-----BEGIN CERTIFICATE-----
<SSL Server Cert Contents>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<CA Cert Contents>
-----END CERTIFICATE-----
The stackedChain.pem file looks something like the following:
-----BEGIN CERTIFICATE-----
MIIDvjCCAaYCAQEwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxDTALBgNV
... Omitted contents ... 
/kzgDk5wO1CbTwuxPIY1piy0Os1Q5EWk3VVAmv4tNMT9bANeKDUiVyYyOi1NIiHA
36w=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGGDCCBACgAwIBAgIJAPtvlrCRokk4MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNV
... Omitted contents ... 
KV+sxNECGE40iWIvd1dXDA1O34qhAwkVD6/bxw==
-----END CERTIFICATE-----
Note If you are creating stackedChain.pem files for multiple VQE-S or VCPT hosts, the server.crt file should be different for each host.

Step 2 For VCPT only, to create a trust-store file for the SSL Java client, issue the following command:
$ keytool -import -keystore trustedca -alias rootca -file ca.crt 
The CA certificate (ca.crt) specified in the -file argument is the commercial CA certificate that you get from the vendor.

The keytool command creates a new keystore with the CA certificate. The resulting file is named trustedca.

Step 3 Do one of the following:

•On a VQE-S host, copy the following files to the directory /etc/opt/certs:

–server.key

–stackedChain.pem

•On a VCPT host, copy the following files to the directory /etc/opt/certs:

–server.key

–stackedChain.pem

–trustedca

Getting Started Using the VQE Startup Configuration Utility

The Cisco VQE Startup Configuration Utility runs automatically the first time you power on a CDE110 appliance that has completed the VQE software installation. The utility is available on the CDE110 that hosts VQE-S and on the CDE110 that hosts VCPT. We recommend that you use the VQE Startup Configuration Utility rather than try to do the initial configuration manually because the utility simplifies your work and is known to produce correct results.

Caution The Cisco VQE Startup Configuration Utility runs once the first time a CDE110 boots normally. Do not attempt to use the utility a second time because this will produce incorrect and unpredictable results.

Before using the VQE Startup Configuration Utility, read the "Configuration Items" section and complete the "Pre-Configuration Worksheets" section.

After using the VQE Startup Configuration Utility, perform the verification tasks in the following sections:

•On the VQE-S Host: Verifying Status of VQE and System Services

•On the VCPT Host: Verifying Status of VQE and System Services

Terminal Client Software Behavior

When using the Cisco VQE Startup Configuration Utility with a CDE110 serial port connection and terminal client software, different terminal client facilities have varying behavior for the Backspace and Delete Keys:

•With console/konsole on Linux, or putty on Windows, pressing Backspace works correctly.

•With HyperTerminal on Windows, pressing Ctrl-Backspace works correctly.

•With HyperTerminal on Windows, pressing Backspace (without Ctrl) produces errors.

•With UNIX xterm shell, pressing Backspace produces errors. With the UNIX xterm shell, the Delete key (not Backspace) is used to remove characters.

Other terminal client facilities may produce different behaviors for the Backspace and Delete keys.

Configuration Items

This section provides information on the configuration items present in the VQE Startup Configuration Utility. Before using the VQE Startup Configuration Utility, read the following descriptions of items where you may need to gather some information prior to booting the CDE110 for the first time and using the utility.

When using the VQE Startup Configuration Utility, you can enter information for the following configuration items. For optional items, Optional appears in parentheses after the item name. Similarly, for the items that are for a VQE-S host only, VQE Host Only appears in parentheses after the item name.

Passwords for root and the vqe User

The password for root is set when the CDE110 boots normally for the first time (when you log in as root) and before the VQE Startup Configuration Utility executes.

The vqe user is a predefined Linux user that the system administrator can use to log in to VQE-S AMT and VCPT.

The root and vqe user passwords have the following requirements: A valid password should be a mix of uppercase and lowercase letters, digits, and other characters. You can use an eight-character long password with characters from at least three of these four classes, or a seven-character long password containing characters from all the classes. An upper case letter that begins the password and a digit that ends it do not count towards the number of character classes used.

The password can be a passphrase. A passphrase should be at least three words with a combined total length of 12 to 40 characters.

Hostname for the CDE110

The hostname is used in multiple Linux configuration files.

Domain Name Server (DNS) IP addresses and a Search Domain (Optional and VQE-S Host Only)

The IP addresses of one or more DNS servers and an optional search domain.

Ethernet Interface Configurations IP address and Mask

For one or more of the Ethernet ports on the Cisco CDE110, you specify an IP address and subnet mask. The four ports are named eth1, eth2, eth3, and eth4 as shown in Figure 2-1.

•On a VQE-S host, four Ethernet interfaces are typically configured and used for incoming multicast streams, outgoing Unicast Retransmissions, and other VQE-S traffic.

•On a VCPT host, at least one Ethernet interface is typically configured and used for VCPT and VQE Client Channel Configuration Delivery Server (VCDS) traffic.

Note If one Ethernet interface is used for a management network, that interface should be included in the set for which you provide IP addresses and masks.

Figure 2-1 Ethernet Port Numbering for Software Configuration

Ethernet Interface, IP Address and Mask, and Gateway Address for a Management Network (Optional)

If your deployment will make use of a management network, the VQE Startup Configuration Utility can configure a static route for the management network. You specify the following:

•Name of the CDE110 Ethernet interface (for example, eth1) that will be used for the management network.

•Management subnet IP address and prefix-length for the management network. The following example shows the allowed format for the subnet IP address and prefix-length:

10.1.0.0/16

•Gateway (nexthop) IP address of the interface on the router that is directly attached to the CDE110 Ethernet interface that will be used for the management network.

Ethernet Interfaces That Will Be Used for VQE-S (VQE-S Host Only)

You specify which of the CDE110 Ethernet interfaces will be available to VQE-S for incoming multicast streams, outgoing Unicast Retransmissions, and other VQE-S traffic. The interface names are eth1, eth2, eth3, and eth4.

Note If one Ethernet interface is used for a management network, that interface should be not included as one of the interfaces that will be available to VQE-S (for Unicast Retransmission).

ECMP Nexthop IP addresses (VQE-S Host Only)

The IP addresses for the interfaces on the router that is directly attached to the VQE-S host. Specify as many nexthop router interfaces as are reachable through all of the configured CDE110 Ethernet interfaces.

Note If one Ethernet interface is used for a management network, that interface should be not included in the set for which nexthop router interfaces are specified.

Equal Cost Multipath (ECMP) allows the CDE110 to load-balance its output traffic across two or more Ethernet interfaces. VQE-S uses ECMP to load-balance its output traffic across all the nexthop router interfaces that are specified.

For information on ECMP configuration, see the "Configuring Default ECMP Routes for CDE110 Ethernet Interfaces (VQE-S Host)" section on page D-6.

Trusted Channel Provisioning Server (VQE-S Host Only)

If your IPTV deployment will use VCPT or another channel-provisioning server to send channel information to the VQE Servers, you specify the IP addresses of the trusted channel-provisioning servers. The VQE Startup Configuration Utility configures the CDE110 that hosts VQE-S so that only trusted HTTPS clients (from the trusted channel-provisioning servers) can send the channel information to the VQE-S host.

For more information on VCPT and how it sends channel information, see "VQE Channel Provisioning Tool and Channel Information" section on page 1-11.

System Timezone

The timezone that will be used for this CDE110. The VQE Startup Configuration Utility prompts for the needed information.

NTP Server IP Addresses (Optional)

The IP addresses of one or more Network Time Protocol (NTP) servers. We recommend that the system time of each CDE110 be synchronized with NTP.

SSL Certificates Options

Secure Sockets Layer (SSL) certificates must be created and deployed for VQE-S AMT or VCPT to be accessed using HTTPS. The VQE Startup Configuration Utility gives you three options for creating and deploying the certificates. For information on the three options and using the utility for creating and deploying SSL certificates, see "Using the Cisco VQE Startup Configuration Utility for SSL Certificates" section.

SNMP Read-only Community String and Trap-Sink IP Addresses or Hostnames (Optional)

If your deployment will use SNMP, you specify your read-only community string and the IP addresses or hostnames of the management hosts that will receive the SNMP messages. For more information on SNMP for the CDE110, see Appendix B, "Using Net-SNMP."

Enable or Disable STUN Server (Optional and VQE-S only)

If your deployment will use the VQE STUN Server so that set-top boxes behind NAT devices are supported by VQE, you must enable the STUN Server. Unless you are sure that no set-top boxes being serviced by VQE-S are behind NAT devices, we recommend that you enable the STUN Server.

Automatic Restart of VQE Services After a Reboot (Optional)

If you choose to have VQE services automatically started after a reboot, the services listed in Table 2-1 and Table 2-2 will be started. We recommend that you choose to have services started automatically.

If you choose not to have VQE services automatically started after a reboot, you must start the VQE services manually. For information on starting VQE system services manually, see Appendix D, "Manual Initial VQE System Configuration."

Table 2-1 VQE and System Services for CDE110 That Hosts VQE-S

Service

Description

process_monitor

Process that starts and monitors the other VQE-S processes—Control Plane, Data Plane, Multicast Load Balancer, and STUN Server.

check_daemons

A script that monitors httpd and tomcat processes and attempts to restart them if they fail. The script runs once a minute as a cron job owned by root.

sshd

The Secure Shell daemon.

httpd

HyperText Transfer Protocol daemon (the Apache web server).

tomcat5

The Apache Tomcat application server.

snmpd

The SNMP daemon.

snmpsa

The SNMP subagent.

Table 2-2 VQE and System Services for CDE110 That Hosts VCPT

Service

Description

check_daemons

A script that monitors httpd and tomcat processes and attempts to restart them if they fail. The script runs once a minute as a cron job owned by root.

sshd

The Secure Shell daemon.

httpd

HyperText Transfer Protocol daemon (the Apache web server).

tomcat5

The Apache Tomcat application server.

snmpd

The SNMP daemon.

snmpsa

The SNMP subagent.

Pre-Configuration Worksheets

Before using the VQE Startup Configuration Utility, complete the pre-configuration worksheets in Table 2-3 (for a VQE-S host) and Table 2-4 (for a VCPT host) before the first normal boot. The use of VCPT is optional.

For information on the configuration items in Table 2-3 and Table 2-4, see the "Configuration Items" section.

Table 2-3 VQE-S CDE110: Pre-Configuration Worksheet

Configuration Item

Value for Your Deployment

Password for root

Password for the vqe user (a pre-defined Linux user)

Hostname of the CDE110 for VQE-S

Domain Name Service (DNS) IP addresses and a search domain

DNS IP address:

DNS IP address:

Search domain:

Ethernet interface configurations (IP address and mask)

eth1:

eth2:

eth3:

eth4:

For a management network—CDE110 Ethernet interface, subnet IP address and prefix-length, and gateway (nexthop) IP address

Ethernet interface:

IP address and prefix-length:

Gateway (nexthop) IP address:

Ethernet interface names that will be used by VQE-S for Unicast Retransmission

ECMP next-hop IP addresses

Trusted channel-provisioning server IP addresses or hostnames

System timezone

NTP server IP addresses

SSL certificate options

SNMP read-only community string

SNMP trap-sink IP addresses or hostnames

string:

Enable or disable STUN Server

Start VQE services when system boots?

Table 2-4 VCPT CDE110: Pre-Configuration Worksheet

Configuration Item

Value for Your Deployment

Password for root

Password for the vqe user (a pre-defined Linux user)

Hostname of the CDE110 for VCPT

Domain Name Service (DNS) IP addresses and a search domain

DNS IP address:

DNS IP address:

Search domain:

Ethernet interface configurations (IP address and mask)

eth1:

eth2:

eth3:

eth4:

For a management network—CDE110 Ethernet interface, subnet IP address and prefix-length, and gateway (nexthop) IP address

Ethernet interface:

IP address and prefix-length:

Gateway (nexthop) IP address:

System timezone

NTP server IP addresses

SSL certificate options

SNMP read-only community string

SNMP trap-sink IP addresses or hostnames

string:

Start VQE services when system boots?

On the VQE-S Host: Verifying Status of VQE and System Services

After the VQE Startup Configuration Wizard finishes and the CDE110 that hosts VQE-S reboots, it is recommended that you perform some quick checks to ensure that VQE and system services are running. The VQE Startup Configuration Wizard asks if you want VQE services to restart automatically when the VQE-S host reboots.

•If you have chosen to have VQE services start automatically on reboot, use this section to verify that VQE-S and system services are running.

•If you have chosen not to have VQE services start automatically on reboot, see the "Starting VQE-S System Services and Verifying Status" section on page D-11.

To verify the status of VQE services on the VQE-S host, follow these steps:

Step 1 If needed, log in as root.

Step 2 To verify that the sshd process is running, issue the following command:
[root@system]# ps -ef | grep sshd 
root      2835     1  0 Jul18 ?        00:00:00 /usr/sbin/sshd
Step 3 To verify that the httpd process is running, issue the following command:
[root@system]# ps -ef | grep httpd 
root      2880     1  0 Jul18 ?        00:00:00 /usr/sbin/httpd
apache    4881  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4882  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4883  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4884  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4885  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4886  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4887  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4888  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
Step 4 To verify that the tomcat5 process is running, issue the following command:
[root@system]# ps -ef | grep tomcat5 
root      2915     1  0 Jul18 ?        00:00:11 /usr/java/default/bin/java 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=/usr/share/tomcat5/conf/logging.properties 
-Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath 
:/usr/share/tomcat5/bin/bootstrap.jar:/usr/share/tomcat5/bin/commons-logging-api.jar 
-Dcatalina.base=/usr/share/tomcat5 -Dcatalina.home=/usr/share/tomcat5 
-Djava.io.tmpdir=/usr/share/tomcat5/temp org.apache.catalina.startup.Bootstrap start
Step 5 To verify that the snmpd process is running, issue the following command:
[root@system]# ps -ef | grep snmpd 
root      2812     1  0 Jul18 ?        00:00:58 /usr/sbin/snmpd -Lsd -Lf /dev/null -p 
/var/run/snmpd -a
Step 6 To verify that the snmpsa process is running, issue the following command:
[root@system]# ps -ef | grep snmpsa 
root      2959     1  0 Jul18 ?        00:02:26 /usr/local/snmpsa/bin/smSubagent
Step 7 To check that the VQE-S processes are running, issue the following command:
[root@system]# ps -ef | grep vqe 
root      2406     1  0 13:10 ?        00:00:00 /opt/vqes/bin/process_monitor -c 
/etc/opt/vqes/vqes.conf
vqes      2409  2406  0 13:10 ?        00:00:00 mlb --interface eth1 --xmlrpc-port 
8052 --unicast-reservation 40 --poll-interval 1
root      2411  2406  2 13:10 ?        00:00:00 vqes_dp --setcpu 0 --group vqes
vqes      2415  2406  0 13:10 ?        00:00:00 vqes_cp --xmlrpc-port 8051 --cfg 
/etc/opt/vqes/vqe_channels.cfg
root      2422  3127  0 13:10 pts/0    00:00:00 grep vqe
In the preceding output, the VQE-S processes to check for are as follows:

•process_monitor—Process Monitor

•mlb—Multicast Load Balancer

•vqes_dp—Data Plane

•vqes_cp—Control Plane

Step 8 If you have chosen to use the STUN Server in the VQE Startup Configuration Utility, issue the following command to check that the STUN Server process is running:
[root@system]# ps -elf | grep stun 
4 S root     18926 18919  0  75   0 -  3780 322792 Nov09 ?        00:03:29 stun_server 
--xmlrpc-port 8054
0 S root     31148  3359  0  78   0 -   971 pipe_w 12:46 ttyS1    00:00:00 grep stun
Step 9 To use the VQE-S Application Monitoring Tool from a web browser, enter as the URL the IP address of the Cisco CDE110 that hosts VQE-S:
https://ip_address_of_VQES_host 
Log in using the vqe username and password. (Any valid Linux username and password can be used to log in to the VQE-S Application Monitoring Tool.)

If you click System in the left pane, the VQE-S Application Monitoring Tool displays information on the VQE-S processes and channels. Figure 4-1 shows an example.

Step 10 Do one of the following:

•If the preceding checks indicate that all is well, you are ready to start using VQE-S and VQE-S AMT. For information, see Chapter 4, "Using the VQE-S Application Monitoring Tool."

•If one of the preceding checks fails, inspect the configuration of the item that failed and make any needed adjustments. You can get more information on VQE-S host configuration in Appendix D, "Manual Initial VQE System Configuration."

On the VCPT Host: Verifying Status of VQE and System Services

After the VQE Startup Configuration Wizard finishes and the CDE110 that hosts VCPT reboots, it is recommended that you perform some quick checks to ensure that VQE and system services are running. The VQE Startup Configuration Wizard asks if you want VQE services to start automatically when the VQE-S host reboots.

•If you have chosen to have VQE services start automatically on reboot, use this section to verify that VQE-S and system services are running.

•If you have chosen not to have VQE services start automatically on reboot, see the "Starting VCPT System Services and Verifying Status" section on page D-21.

To verify the status of VQE services on the VCPT host, follow these steps:

Step 1 If needed, log in as root.

Step 2 To verify that the sshd process is running, issue the following command:
[root@system]# ps -ef | grep sshd 
root      2835     1  0 Jul18 ?        00:00:00 /usr/sbin/sshd
Step 3 To verify that the httpd process is running, issue the following command:
[root@system]# ps -ef | grep httpd 
root      2880     1  0 Jul18 ?        00:00:00 /usr/sbin/httpd
apache    4881  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4882  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4883  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4884  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4885  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4886  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4887  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
apache    4888  2880  0 04:03 ?        00:00:00 /usr/sbin/httpd
Step 4 To verify that the tomcat5 process is running, issue the following command:
[root@system]# ps -ef | grep tomcat5 
root      2915     1  0 Jul18 ?        00:00:11 /usr/java/default/bin/java 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=/usr/share/tomcat5/conf/logging.properties 
-Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath 
:/usr/share/tomcat5/bin/bootstrap.jar:/usr/share/tomcat5/bin/commons-logging-api.jar 
-Dcatalina.base=/usr/share/tomcat5 -Dcatalina.home=/usr/share/tomcat5 
-Djava.io.tmpdir=/usr/share/tomcat5/temp org.apache.catalina.startup.Bootstrap start
Step 5 To verify that the snmpd process is running, issue the following command:
[root@system]# ps -ef | grep snmpd 
root      2812     1  0 Jul18 ?        00:00:58 /usr/sbin/snmpd -Lsd -Lf /dev/null -p 
/var/run/snmpd -a
Step 6 To verify that the snmpsa process is running, issue the following command:
[root@system]# ps -ef | grep snmpsa 
root      2959     1  0 Jul18 ?        00:02:26 /usr/local/snmpsa/bin/smSubagent
Step 7 To verify that VCPT is accessible from a web browser, enter as the URL the IP address of the Cisco CDE110 that hosts VCPT:
https://ip_address_of_VCPT_host 
Log in with a Linux username and password.

If you are able to log in successfully, VCPT is running correctly.

Step 8 Do one of the following:

•If the preceding checks indicate that all is well, you are ready to start using VCPT. For information, see Chapter 3, "Using the VQE Channel Provisioning Tool."

•If one of the preceding checks fails, inspect the configuration of the item that failed and make any needed adjustments. You can get more information on VCPT host configuration in Appendix D, "Manual Initial VQE System Configuration."

Configuring VQE-S RTCP Exporter

VQE-S RTCP Exporter is the VQE-S software component responsible for sending the RTCP reports to an external device that hosts the video-quality monitoring (VQM) application. Use of RTCP Exporter is optional.

To monitor the RTCP Exporter, use the VQE-S Application Monitoring Tool (AMT). This tool displays RTCP Exporter configuration details and status as well as counters of exported packets. The VQE-S Application Monitoring Tool can also be used to enable or disable RTCP Exporter debugging.

To troubleshoot the RTCP Exporter, examine the Exporter syslog messages, which are sent to the VQE-S log file (/var/log/vqes/vqes.log). If more detailed troubleshooting is needed, enable RTCP Exporter debugging using the AMT tool and examine the debug messages, which are also sent to the VQE-S log file.

To configure and enable the RTCP Exporter on the Cisco CDE110 that hosts VQE-S, follow these steps:

Step 1 Define the following three options in the /etc/vqes/vqes.conf file. To configure the options, you edit this file with a text editor.

•vqm-host—IP address, hostname, or fully qualified Internet domain name of the host on which the VQM application resides. For example:

–vqm-host = "11.2.15.1";

–vqm-host = "hostname";

–vqm-host = "hostname.cisco.com ";

•vqm-port—TCP port number on which the VQM application listens for video quality data from RTCP Exporter.

•exporter-enable—Either TRUE or FALSE. The value TRUE enables RTCP exports, and FALSE disables RTCP exports.

RTCP Exporter remains disabled unless both vqm-host and vqm-port are configured and are valid.

The three parameters used to configure and enable RTCP Exporter are specified in vqes_control_plane section of the vqes.conf file:
vqes_control_plane =
{
   xml-rpc-port = 8010;
   use-source = false;
   use-rcc = false;
   use-error-repair = true;
   burst-rate = .2;
   vqm-host = "11.2.15.1"; 
   vqm-port = "8312"; 
   exporter-enable = TRUE; 
};
By default, the vqes.conf file contains no RTCP Exporter parameters and is disabled. After modifying the vqes.conf file, you must stop and restart the VQE-S application for the changes to take effect. For information on stopping and restarting VQE-S, see the "Stopping and Restarting VQE-S" section.

Step 2 If a hostname or fully qualified Internet domain name is specified in vqm-host, ensure that the /etc/resolv.conf file is configured to point to the correct name server for Domain Name System (DNS) queries. The following is an example of what might appear in the /etc/resolv.conf file:
search cisco.com 
nameserver 1.1.1.1
Step 3 If a hostname or fully qualified Internet domain name is specified in vqm-host, enable local and external DNS name resolution on the VQE-S host. To do this, edit the /etc/nsswitch.conf file and verify the following line is in the file:
hosts  files dns
Note In the absence of the preceding line, DNS resolution is unavailable on the VQE-S host. RTCP Exporter will fail to initialize if it is enabled and configured with a DNS hostname or fully qualified Internet domain name.

Stopping and Restarting VQE-S

To stop and restart VQE-S, follow these steps:

Step 1 Log in as root.

Step 2 To stop VQE-S, issue the following command:
[root@system]# init 4
Step 3 Wait for all VQE-S processes to stop. To check that all VQE-S processes have stopped, issue the following command:
[root@system]# ps -ef | grep vqe 
If all VQE-S processes are stopped, the command output will not include any VQE-S processes (process_monitor, mlb, vqes_dp, or vqes_cp).

Step 4 To restart VQE-S, issue the following command:
[root@system]# init 3 