Cisco CDA Visual Quality Experience Application User Guide, Release 3.1
Chapter 2: Getting Started with the VQE Startup Configuration Utility

Table Of Contents

Getting Started with the VQE Startup Configuration Utility

Web Browser, Screen Resolution, and Other Requirements

Configuring Terminal Emulation Software

Security Restrictions for Logins and Root Privileges

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 1 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

VQE-S Server: Routing Configuration Overview

Types of Routes on a VQE-S Server

Static Routes on a VQE-S Server

OSPF Routing on VQE-S Server

Load Balancing and Redundancy with Multiple VQE-S Servers

VQE Tools Server: Routing Configuration Overview

Using the VQE Startup Configuration Utility

Configuration Parameters

Pre-Configuration Worksheets

VQE Startup Configuration Utility Root Menu

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

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

Configuring VQE-S RTCP Exporter

Configuring Other Parameters for the VQE-S Host

Configuring the Edge Router for VQE-S

For OSPF Routing: Guidance for Configuring the Attached Router

VQE-S in Separate OSPF Area

VQE-S in Area 0

General Guidelines

For Static Routes: Guidance for Configuring Feedback Targets on the Attached Router


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 servers running with the Cisco VQE software:

VQE-S server—CDE110 hosting VQE Server

VQE Tools server—CDE110 hosting VQE Channel Provisioning Tool (VCPT) and VQE Client Channel Configuration Delivery Server (VCDS)

In a VQE deployment, use of the VQE Tools server with VCPT and VCDS 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 for Logins and Root Privileges

Prerequisites

Setting Up SSL Certificates

VQE-S Server: Routing Configuration Overview

VQE Tools Server: Routing Configuration Overview

Using the VQE Startup Configuration Utility

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

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

Configuring VQE-S RTCP Exporter

Configuring Other Parameters for the VQE-S Host

Configuring the Edge Router for VQE-S


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

For information on upgrading a Cisco CDE110 from Cisco VQE Release 2.1 or 3.0 to Release 3.1, see the Release Notes for Cisco CDA Visual Quality Experience Application, Release 3.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 Logins and Root Privileges

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 username should be used instead. The vqe username 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 username 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:

[root@system]# 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, the following items should be accomplished for the CDE110 that hosts VQE-S and the CDE110 that hosts the VQE Tools:

Connect cables to the CDE110—See the "Connecting Cables to the CDE110" section.

Determine how you will set up Secure Sockets Layer (SSL) certificates—For information on the alternatives available to you, see the "Setting Up SSL Certificates with the VQE Startup Configuration Utility" section.

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 the VQE Tools:

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

On a VQE-S server, 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.


Note For OSPF routing on the VQE-S server, the Ethernet interfaces used for VQE-S traffic must have a direct Layer-3 connection to the edge router.


On a VQE Tools server, 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 Sockets 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 utility, 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 the following URL:

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: 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 1, see the "Step-by-Step Example: VQE Startup Configuration Utility's Option 1 for Preparing SSL Certificates" section.

Option 2: 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:

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

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.

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

For overview information of the SSL tasks, see the "Setting Up SSL Certificates" section.

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.

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

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

To use the VQE Startup Configuration Utility 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 1 to create a self-signed SSL certificate.

Prepare SSL certificate for HTTPS service. Choose from following options: 

1. 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.
2. 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.
3. Skip this step now and manually deploy SSL certificate later. Refer to VQE-S User's 
Guide for instructions. VCPT host will not be able to push SDP configurations to VQE-S 
without SSL certificate in place.

Please enter your choice: [1|2|3]  1 
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 1 to create a self-signed SSL certificate.

Prepare SSL certificate for HTTPS service. Choose from following options: 

1. 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.
2. 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.
3. Skip this step now and manually deploy SSL certificate later. Refer to VQE-S User's 
Guide for instructions. VCPT host will not be able to push SDP configurations to VQE-S 
without SSL certificate in place.

Please enter your choice: [1|2|3]  1 
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 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 Certificate Signing 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 a certain format and 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


VQE-S Server: Routing Configuration Overview

For a VQE-S server, the VQE Startup Configuration Utility supports two routing types: static routes and OSPF routing. This section provides overview information on how you can configure static routes or OSPF routing on a VQE-S server. It includes these topics:

Types of Routes on a VQE-S Server

Static Routes on a VQE-S Server

OSPF Routing on VQE-S Server

Load Balancing and Redundancy with Multiple VQE-S Servers

At initial system startup, the VQE Startup Configuration Utility can be used to configure static routes or OSPF routing. After initial system startup, the VQE Configuration Tool can be used to modify the routing implementation.

Types of Routes on a VQE-S Server

On the VQE-S server, three types of routes are used:

Management route—A route on the VQE-S server through a directly attached edge router to the management network, where the VQE-S management applications, such as AMT and VCPT, reside.

Access routes—Routes on the VQE-S server through a directly attached edge router to the access network, where the VQE Clients on the set-top boxes live.

Feedback target routes—Routes on a directly attached edge router to the VQE-S server that advertise reachability of the VQE-S feedback targets (FBTs) into the access network, where the set-top boxes reside. Each FBT is associated with a channel. VQE Clients on the set-top boxes send requests for Unicast Retransmission and Rapid Channel Change services to the feedback target addresses. VQE-S configures each channel's FBT address as a host address on the VQE-S server loopback interface.

The VQE-S also joins the multicast RTP streams from the distribution network. This interaction is between the VQE-S server and the edge router. It takes place through the use of IGMP joins and does not involve routing with the local routing daemon on the VQE-S server. This interaction is outside the scope of this discussion.

Figure 2-1 shows the types of routes used on a VQE-S server.

Figure 2-1 Routes Used on a VQE-S Server

Static Routes on a VQE-S Server

Prior to Cisco VQE Release 3.1, the routes on a VQE-S server were configured using static routes. Though static routes can still be chosen as the routing type, the use of static routes for the access routes and feedback target routes has some limitations.

For the access routes, use of static routes requires that the VQE-S server be configured for the static routes to the access network. In contrast, with OSPF routing, the edge router advertises a default route to the access network through a routing protocol, allowing load balancing across the VQE-S interfaces and not requiring an extra configuration step.

For the feedback target routes, the use of static routes on the edge router means that repair services on the VQE-S for all feedback targets are assumed to always be available as long as the VQE-S interfaces are up. In some cases, although the interfaces are up, the VQE-S may not be able to handle requests for one or more feedback targets. The VQE-S itself can not add or withdraw the routes as services become available or unavailable for particular feedback targets. Another limitation of the use of static routes for feedback targets is that it requires the customer to take the extra step of configuring the edge router for feedback target addresses. In the worst case, this approach can require that each feedback target have a separate static route configured on the router if the feedback target addresses are not summarizable.

For information on static route configuration on the edge router, see the "For Static Routes: Guidance for Configuring Feedback Targets on the Attached Router" section.

OSPF Routing on VQE-S Server

Starting with Release 3.1, Cisco VQE supports a dynamic routing feature, which uses OSPF, on the VQE-S server. The use of OSPF routing eliminates the limitations of static routing, which are described in the preceding section, "Static Routes on a VQE-S Server". Specifically, OSPF routing can be used on the VQE-S for the following:

To learn routes to the access network out the VQE-S interfaces to the edge router

To advertise feedback target routes to the edge router and access network

With dynamic routing, the feedback target routes can be advertised based on the actual capabilities of the VQE-S to process requests for services sent to those targets by adding and removing feedback target routes as needed.

On the VQE-S server, the Quagga routing package provides the OSPF routing capability. The VQE Startup Configuration Utility and the Configuration Tool simplify the OSPF configuration on the VQE-S server. After you enter a values for OSPF configuration parameters, such as the OSPF area and router ID, these tools perform the configuration tasks for you. For information on the OSPF configuration parameters for the VQE-S server, see the "OSPF Configuration (VQE-S Host Only)" section.

For information on OSPF configuration on the edge router, see the "For OSPF Routing: Guidance for Configuring the Attached Router" section.

Load Balancing and Redundancy with Multiple VQE-S Servers

When more than one VQE-S server provides Unicast Retransmission Rapid Channel Change or both services for a set of channels, the VQE-S servers and edge router can load balance the requests from VQE Clients on the set-top boxes and provide failover protection if a VQE-S server fails.

In the VCPT channel definition, each channel is associated with a unique feedback target (FBT) IP address. The VQE Clients on the set-top boxes use the FBT addresses to request Unicast Retransmission and RCC services for a particular channel. The FBT address is a unique IP anycast address that VQE Server configures on its host Cisco CDE110 based on the channel information that is sent to it by VCPT or another channel-provisioning server. An anycast address is a unicast address that is assigned to multiple interfaces. With the appropriate routing topology, packets addressed to an anycast address are delivered to a single interface (in this case, the nearest VQE Server's Ethernet interface that is identified by the address).

The use of anycast IP addresses and Equal Cost Multipath (ECMP) routing allows multiple VQE Servers in a single facility to balance the load among themselves and to provide failover protection in case of a server failure. As an example, Figure 2-2 shows a redundant pair of VQE-S servers, each providing Unicast Retransmission and RCC services for the same set of three channels. On both VQE-S servers, each channel is defined to have the same anycast IP address: A for channel 1, B for channel 2, and C for channel 3.

Figure 2-2 Redundant VQE-S Servers for Service Failover and Load Balancing

When OSPF routing is configured on the VQE-S servers, the FBT routes are advertised from the VQE-S to the edge router. In this example, both VQE-S servers advertise FBT routes for a particular channel. If the services for that channel become unavailable on one VQE-S, that VQE-S withdraws the route. This allows the other VQE-S to take over services for that channel. If one VQE-S server fails, the second VQE-S server services the requests directed to the three feedback target addresses.

With OSPF routing and ECMP on the edge router, the router uses multi-interface load splitting on different interfaces with equal cost paths. ECMP provides load-balancing of output traffic on the edge router interfaces that are attached to the VQE-S traffic interfaces on the CDE110 server. If three Ethernet interfaces on each of the two VQE-S servers were configured for VQE-S traffic, the edge router would load balance set-top box requests for VQE-S services over the six available Ethernet interfaces.

VQE Tools Server: Routing Configuration Overview

On the VQE Tools server, the following routes are used:

Management route—A route on the VQE Tools server through an edge router to the management network.

External access—Proper route configuration is needed to provide external access to the VQE Tools server. This access allows VQE Client Channel Configuration Delivery Server (VCDS) to send channel information to the VQE Clients on the set-top boxes and for VCPT to send channel information to each VQE-S.

The VQE Tools server uses one or more static routes to the management network. The static route to the management network can also be used to provide the external access. The VQE Startup Configuration Utility and VQE Configuration Tool can be used to configure one or more static routes.

Using the VQE Startup Configuration Utility

The Cisco VQE Startup Configuration Utility runs automatically the first time you log in to a CDE110 server. The CDE110 server has the VQE software pre-installed. The utility is available on the CDE110 that hosts VQE-S and on the CDE110 that hosts VQE Tools. 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, do the following so that you understand how the startup configuration utility works and what information you need to collect before powering on the VQE-S or VCPT server:

Read the "VQE-S Server: Routing Configuration Overview" section.

Read the "VQE Tools Server: Routing Configuration Overview" section.

Read the "Configuration Parameters" section.

Complete the "Pre-Configuration Worksheets" section.

Read the "VQE Startup Configuration Utility Root Menu" section.

The VQE Startup Configuration Utility displays the Root Menu after you finish entering configuration values. The Root Menu allows you to view the values that you have specified and to change values that are not correct.

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 VQE Tools Host: Verifying Status of VQE and System Services

Configuration Parameters

This section provides information on the configuration parameters present in the VQE Startup Configuration Utility. Before using the VQE Startup Configuration Utility, read the descriptions of the configuration parameters in this section.


Tip For many configuration parameters, you will need to gather some information prior to booting the CDE110 for the first time and using the VQE Startup Configuration Utility. The worksheets in the "Pre-Configuration Worksheets" section may be helpful in organizing the information.


In the explanations that follow, these conventions are used for the configuration parameters.

For the parameters that are for a VQE-S host only, VQE -S Host Only appears in parentheses after the item name.

For optional parameters, Optional appears in parentheses after the item name.


Note To not enter data for an optional item, press Enter without entering any data at the VQE Startup Configuration Utility prompt.


Passwords for root and the vqe User IDs

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 username is a predefined Linux user ID 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 uppercase 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. Allowed range is 3 to 200 characters.

Domain Name System (DNS) IP Addresses and a Search Domain

The IP addresses of one or more DNS servers and an optional search domain. Allowed range for the search domain is 3 to 200 characters.

System Timezone and Current System Time

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

NTP Server IP Addresses

The IP addresses of one or more Network Time Protocol (NTP) servers.


Note We recommend that the system time of each CDE110 be synchronized with NTP. Problems (for example, with Session Description Protocol [SDP] updates) can occur if the server time is not synchronized with NTP.


SNMP Read-only Community String, Location, Contact, and Trap-Listener IP Addresses or Hostnames (Optional)

If your deployment will use SNMP, you specify the following:

Read-only community string—Password for read-only access to the VQE-S or VQE Tools server

Location information—Physical location of the VQE-S or VQE Tools server

Contact information—Username of a contact person who has management information for the CDE110 server

Trap listeners—IP addresses or fully qualified 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."

Ethernet Interface Configurations IP Addresses and Prefix Lengths

For one or more of the Ethernet ports on the Cisco CDE110, you specify an IP address and prefix length (for example, 1.2.3.4/32). The four ports are named eth1, eth2, eth3, and eth4 as shown in Figure 2-3.

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 VQE Tools host, at least one Ethernet interface is typically configured and used for VCPT and VQE Client Channel Configuration Delivery Server (VCDS) traffic.

Optionally on both the VQE-S host and VQE Tools host, one Ethernet interface may be used for a management network, that interface should be included in the set for which you provide IP addresses and prefix lengths.

Figure 2-3 Ethernet Port Numbering for Software Configuration

IP Address and Prefix Length and Gateway Address for a Static Route for a Management Network (Optional)


Note If you configure a static route for a management network using VQE Startup Configuration Utility, see "Static Route for a Management Network Is Missing on CDE110 Hosting VQE-S or VQE Tools" section on page 5-7 for some important additional information.


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

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 (next hop) 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.

As an example of gateway (next hop) IP address, if Ethernet interface eth4 were used for the management network, you would specify the IP address of the router interface that is directly attached to eth4.


Note On the VQE Tools server, proper route configuration is needed for external access to the VQE Tools server. You can use the static management route created by this parameter to configure this access.


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 the "Using the Cisco VQE Startup Configuration Utility for SSL Certificates" section.

VQE-S Traffic Routing Type (VQE-S Host Only)

Specifies whether static routes or OSPF routing will be used as the routing type for VQE-S traffic.

If static routes are chosen, the VQE-S host is configured for one or more default gateway (next hop) router interfaces. See the "Default Gateway IP Addresses for Multipath Static Routes (VQE-S Host Only)" section.

If OSPF routing is chosen, the set of OSPF parameters can be configured. For descriptions of these OSPF configuration parameters, see the "OSPF Configuration (VQE-S Host Only)" section.

For information about routing on the VQE-S host, see the "VQE-S Server: Routing Configuration Overview" section.

Default Gateway IP Addresses for Multipath Static Routes (VQE-S Host Only)

If static routes are chosen as the routing type, you specify the IP addresses for the interfaces on the router that is directly attached to the VQE-S host. Specify as many gateway (next hop) router interfaces as are reachable through the CDE110 Ethernet interfaces that have been configured with an IP address and prefix length.


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


VQE-S uses Equal Cost Multipath (ECMP) to load-balance its output traffic across all the gateway router interfaces that are specified. If a default route (the gateway IP address) is configured for each Ethernet interface that is available to VQE-S for Unicast Retransmissions, RCC, and other VQE-S traffic, ECMP load balances output traffic across all of the listed gateway interfaces.

For more information on ECMP configuration, see the "Configuring Static Routes for VQE-S Traffic" section on page D-6.

OSPF Configuration (VQE-S Host Only)

If OSPF is chosen as the routing type, Table 2-1 describes the parameters that can be configured. For detailed information on the OSPF parameters, see the following Quagga documentation:

http://www.quagga.net/docs/quagga.pdf

Table 2-1 OSPF Parameters  

Parameter
Description

Area Type

Type for the OSPF area that the VQE-S traffic interfaces and feedback target host addresses will reside in. You can choose either normal or nssa (Not So Stubby Area). If no value is specified, the default value is normal.

Area ID

Integer ID value for the OSPF area that the VQE-S Ethernet interfaces and feedback target addresses will reside in. If no value is specified, the default value is 0 to 4,294,967,295.

Router ID

IP address used as the router ID to uniquely identify the VQE-S server in the OSPF network. The router ID must not be the same as the IP address of one of the CDE110 CDE110 Ethernet interfaces because the router ID will be added as an internal address to the loopback interface.

Enable MD5

Specifies whether Message Digest 5 (MD5) authentication is enabled on the Ethernet interfaces used for VQE-S traffic. When MD5 authentication is enabled, specifying an MD5 key and MD5 key ID are required.

MD5 Key

If MD5 authentication is enabled, specifies a key (a string) that will be configured for all Ethernet interfaces used for VQE-S traffic. When MD5 authentication is enabled, an MD5 key and key ID are required. Allowed length for the string is 1 to 16 characters.

MD5 Key ID

If MD5 authentication is enabled, specifies an MD5 key ID (an integer) that will be used for all Ethernet interfaces used for VQE-S traffic. When MD5 authentication is enabled, an MD5 key and key ID are required. Allowed range of integer values is 1 to 255.

Hello Interval

Interval (in seconds) at which OSPF Hello packets are sent. This value must be the same for all interfaces running OSPF in the network. The hello interval will be set for all VQE-S interfaces running OSPF. If no value is specified, the default value is 10. Allowed range is 1 to 65,535.

Dead Interval

OSPF dead interval (in seconds). The dead interval is the maximum amount of time allowed to receive a Hello packet from a neighbor before that neighbor is declared down. This value must be the same for all interfaces running OSPF in the network. The dead interval will be set for all VQE-S interfaces running OSPF. If no value is specified, the default value is 40. Allowed range is 1 to 65,535.


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 channel information to the VQE-S host.

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

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

You specify which of the CDE110 Ethernet interfaces will be available for 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 not be included as one of the interfaces that will be available for VQE-S traffic.


Automatic Start of VQE Services on a Reboot

After you finish specifying values for the configuration items, the VQE Startup Configuration Utility displays the following menu:

VQE Configuration Tool Root Menu:

     1) System Parameters   
     2) Network Parameters  
     3) Configure VQE Password
     4) Generate SSL Certificate
     5) VQE-S Parameters    
     S) Save/Apply and reboot system

Enter your choice: 

When you have completed the configuration items, you choose S) Save/Apply and reboot system. The VQE Startup Configuration Utility saves your configuration in the VCDB file, applies the VCDB values to the configuration files under /etc, and reboots the CDE110 system. Each time the VQE-S or VQE Tools host reboots, the services listed in Table 2-3 and Table 2-3 will be started.

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

Service
Description

vqes

The VQE-S service (process_monitor process) starts and monitors the other VQE-S processes—Control Plane, Data Plane, Multicast Load Balancer, and STUN Server.

sshd

The Secure Shell daemon.

httpd

HyperText Transfer Protocol daemon (the Apache web server).

tomcat5

The Apache Tomcat application server.

snmpd

(Optional) The SNMP daemon.

snmpsa

(Optional) The SNMP subagent.

ntpd

(Optional) The NTP daemon.

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.

                                      If OSPF is selected as the routing type

watchquagga

The Quagga watchdog process. If the ospfd or zebra daemon crashes or hangs, watchquagga restarts it automatically.

ospfd

The OSPF daemon.

zebra

The zebra daemon.


Table 2-3 VCDS and System Services for CDE110 That Hosts VQE Tools  

Service
Description

vcds

VQE Client Channel Configuration Delivery Server (VCDS) service

sshd

The Secure Shell daemon.

httpd

HyperText Transfer Protocol daemon (the Apache web server).

tomcat5

The Apache Tomcat application server.

snmpd

(Optional) The SNMP daemon.

snmpsa

(Optional) The SNMP subagent.

ntpd

(Optional) The NTP daemon.

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.



Note On the VQE Tools host, VCPT is a web application and has no dedicated processes associated with it. The processes needed for the VCPT web application to work (for example, the web server) are started automatically when the Cisco CDE110 is started.


Pre-Configuration Worksheets

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

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

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

Configuration Item
Value for Your Deployment

Password for root

 

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

 

Hostname of the CDE110 for VQE-S

 

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

DNS IP address:

DNS IP address:

Search domain:

System timezone

 

NTP server IP addresses

 

SNMP read-only community string

Location for SNMP

Contact for SNMP

SNMP trap-listener IP addresses or hostnames

community string:

location:

contact:

IP addresses or hostnames:

Ethernet interface configurations (IP address and prefix lengths)

eth1:

eth2:

eth3:

eth4:

For static routes for a management network—subnet IP address and prefix-length, and gateway (next hop) IP address

IP address and prefix-length:

Gateway (next hop) IP address:

SSL certificate option

 

Routing type (static or ospf)

 

If static is chosen as the routing type, default gateway (next hop) IP addresses for multipath static routes

IP addresses:

If OSPF is chosen as the routing type, the OSPF parameters required by your networking implementation can be configured.

area type:

area ID:

router ID:

Enable MD5 authentication?

MD5 key:

MD5 key ID:

Hello interval:

Dead interval:

Trusted channel-provisioning server IP addresses

 

Ethernet interface names that will be used for VQE-S traffic

 

Table 2-5 VQE Tools CDE110: Pre-Configuration Worksheet  

Configuration Item
Value for Your Deployment

Password for root

 

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

 

Hostname of the CDE110 for VCPT

 

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

DNS IP address:

DNS IP address:

Search domain:

System timezone

 

NTP server IP addresses

 

SNMP read-only community string

Location for SNMP:

Contact for SNMP:

SNMP trap-listener IP addresses or hostnames

community string:

location:

contact:

IP addresses or hostnames:

Ethernet interface configurations (IP address and mask)

eth1:

eth2:

eth3:

eth4:

For static routes for a management network—subnet IP address and prefix-length, and gateway (next hop) IP address

IP address and prefix-length:

Gateway (next hop) IP address:

SSL certificate option

 

VQE Startup Configuration Utility Root Menu

After you have used the VQE Startup Configuration Utility to specify values for the configuration items, the utility displays the Root Menu. The Root Menu allows you to view the values that you have specified and to change values that are not correct. The Root Menu on a VQE-S server is as follows:

VQE Configuration Tool Root Menu:

     1) System Parameters   
     2) Network Parameters  
     3) Configure VQE Password
     4) Generate SSL Certificate
     5) VQE-S Parameters    
     S) Save/Apply and reboot system

Enter your choice: 

This Root Menu and its behavior are similar to the standard VQE Configuration Tool Root Menu and behavior. The two differences are the numbered choices 3 and 4 are only present in the VQE Startup Configuration Utility, and the Save/Apply choice in the VQE Startup Configuration Utility includes a reboot of the system.


Note For information on how to use the VQE Configuration Tool Root Menu and the other menu choices, see the "Using the VQE Configuration Tool" section on page 6-4. The information in the "Using the VQE Configuration Tool" section is applicable to the Root Menu and other menu choices presented at the end of the VQE Startup Configuration Utility.


The Root Menu choices allow you to do the following:

View and change the parameter or password values that you have set (choices 1, 2, 3, and 5)

Generate and deploy SSL certificates (choice 4)

Save the parameter values to the VQE Configuration Database (VCDB), and apply the values to the VQE-S server or VQE Tools server (choice S)

To view and change parameter values, you can select choices 1, 2, 3, and 5 as many times as you wish.


Note When you are finished specifying parameter values, you must select choice S) Save/Apply and reboot system to save the parameter values to the VQE Configuration Database (VCDB), and apply the values to the VQE-S server or VQE Tools server.


Table 2-6 provides more information about the choices on the Root Menu. You enter the number or letter for your choice.

Table 2-6 Root Menu Choices  

Root Menu Choice
Menu Description

1) System Parameters

Allows you to view the current system parameter values that you have set, and to change or set the system parameters values:

1) Hostname
2) DNS Server(s)
3) DNS Search Domain
4) Timezone
5) NTP Server(s)
6) SNMP RO Community String
7) SNMP System Location
8) SNMP System Contact
9) SNMP Trap Listener(s)

2) Network Parameters

Allows you to view the current network parameter values that you have set, and to change or set the network parameters values:

1) Eth1 Interface
2) Eth2 Interface
3) Eth3 Interface
4) Eth4 Interface
5) Management Route(s)
6) VQE-S Traffic Routing Type
7) Static Routing Parameters
8) OSPF Parameters

3) Configure VQE Password

Allows you to set the password for the vqe username. Once you select this menu choice, you must enter the password value even if you choose to keep the current password.

4) Generate SSL Certificate

Allows you to create and deploy a Secure Sockets Layer (SSL) certificate for VQE-S AMT or VCPT, or to generate a Certificate Signing Request file (server.csr).

5) VQE-S Parameters

Allows you to view the current VQE-S parameter values that you have set, and to change or set the VQE-S parameters values:

1) Trusted VCPT host(s)
2) Log Priority *
3) Excess Bandwidth Fraction *
4) VQE-S Traffic Interfaces

* The VQE Startup Configuration Utility does not allow you to set the values of these parameters in the set of parameters that were previously displayed. You can supply values at this point if you want or accept the defaults. For more information on these values, see the vcdb.conf.sample file and Appendix A, "VQE, System, and Network Parameters."

5) Save/Apply and reboot the system

Saves the changes you have made to the parameters in the VQE Configuration Database (VCDB), applies parameter values to the configuration files under /etc, and reboots the CDE110 system.


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

After the VQE Startup Configuration Utility 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.

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 SSH service is running, issue the following command:

[root@system]# service sshd status

sshd (pid 21165 21110 20595 20569 2777) is running...

Step 3 To verify that the HTTP service is running, issue the following command:

[root@system]# service httpd status

httpd (pid 9665 9664 9663 9661 9660 9658 9657 9656 3978) is running...

Step 4 To verify that the Tomcat 5 service is running, issue the following command:

[root@system]# service tomcat5 status 

Tomcat is running...

Step 5 If you configured SNMP, to verify that the SNMP service is running, issue the following command:

[root@system]# service snmpd status

snmpd (pid 2754) is running...

Step 6 If you configured SNMP, to verify that the SNMP subagent service is running, issue the following command:

[root@system]# service snmpsa status

The SNMP subagent is running.

Step 7 If you enabled OSPF routing, to verify that the three OSPF-related services are running, issue the following commands:

[root@system]# service watchquagga status 

watchquagga (pid 2513) is running... 

[root@system]# service ospfd status 

ospfd (pid 7104) is running... 

[root@system]# service zebra status 

zebra (pid 7072) is running...

Step 8 To verify that the VQE-S service is running, issue the following command:

[root@system]# service vqes status 

process_monitor (pid 21853) is running...

Step 9 To check that the VQE-S processes are running, issue the following command:

[root@system]# ps -ef | grep vqe 

root     17928 17896  0 Jun02 pts/1    00:00:00 tail -f vqe.log
root     21853     1  0 Jun03 ?        00:00:00 /opt/vqes/bin/process_monitor
vqes     21903 21853  0 Jun03 ?        00:00:00 mlb --interface eth1 eth2 eth3 eth4 
--xmlrpc-port 8052 --unicast-reservation 20 --ssm --log-level 4
root     21914 21853  0 Jun03 ?        00:00:04 vqes_dp --max-pkts 1000000 --log-level 
4 --rtp-inactivity-tmo 300
vqes     21944 21853  0 Jun03 ?        00:00:00 vqes_cp --cp-uid 499 --cp-gid 499 
--xmlrpc-port 8051 --cfg /etc/opt/vqes/vqe_channels.cfg --er-cache-time 3000 
--rtp-hold-time 100 --client-er-policing --client-er-tb-rate-ratio 5 
--client-er-tb-depth 10000 --log-level 4 --rcc-mode conservative 
--igmp-join-variability 100 --max-client-bw 0 --max-idr-penalty 0 --rap-interval 2000 
--excess-bw-fraction 20 --excess-bw-fraction-high-def 12 --rcc-burst-delay-to-send 10 
--rtp-dscp 0 --rtcp-dscp 24

In the preceding output, the VQE-S processes to check for are as follows:

process_monitor—Process Monitor

stun_server—STUN Server

mlb—Multicast Load Balancer

vqes_dp—Data Plane

vqes_cp—Control Plane

Step 10 Issue the following command to check that the STUN Server process is running:

[root@system]# ps -elf | grep stun 

4 S vqes     21972 21959  0  75   0 -  3745 322792 Jul15 pts/1    00:00:00 stun_server 
--ss-uid 499 --ss-gid 499 --xmlrpc-port 8054 --log-level 4

Step 11 If you configured an IP address for an NTP server, to verify that the NTP service is running, issue the following command:

[root@system]# service ntpd status

ntpd (pid 2790) is running...

Step 12 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-2 on page 4-4 shows an example. Because at this point no channel information has been sent to the VQE-S, no channels will be displayed.

Step 13 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 VQE Tools Host: Verifying Status of VQE and System Services

After the VQE Startup Configuration Utility finishes and the CDE110 that hosts VQE Tools reboots, it is recommended that you perform some quick checks to ensure that VQE and system services are running.

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


Step 1 If needed, log in as root.

Step 2 To verify that the SSH service is running, issue the following command:

[root@system]# service sshd status

sshd (pid 21165 21110 20595 20569 2777) is running...

Step 3 To verify that the HTTP service is running, issue the following command:

[root@system]# service httpd status

httpd (pid 9665 9664 9663 9661 9660 9658 9657 9656 3978) is running...

Step 4 To verify that the Tomcat 5 service is running, issue the following command:

[root@system]# service tomcat5 status 

Tomcat is running...

Step 5 If you configured SNMP, to verify that the SNMP service is running, issue the following command:

[root@system]# service snmpd status

snmpd (pid 2754) is running...

Step 6 If you configured SNMP, to verify that the SNMP subagent service is running, issue the following command:

[root@system]# service snmpsa status

The SNMP subagent is running.

Step 7 If you configured an IP address for an NTP server, to verify that the NTP service is running, issue the following command:

[root@system]# service ntpd status

ntpd (pid 2790) is running...

Step 8 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 9 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/vqe/vqe.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 If needed, log in as root. You must have root privileges to modify the vcdb.conf file and use the vqe_cfgtool command.

Step 2 Edit the /etc/opt/vqes/vcdb.conf file and add to the file the three key-value pairs for the RTCP Exporter parameters listed in Table 2-7. Specify values for each of the parameters.

For information on manually editing the vcdb.conf file, see the "Manually Editing the VCDB File" section on page 6-12. The parameters used for enabling the RTCP Exporter are not available in the VQE Configuration Tool.

Step 3 Save the vcdb.conf file.

Table 2-7 RTCP Exporter Parameters

Parameter
Value Required

vqe.vqes.vqm_host="IP_addr_or_domain_name"

IP address or fully qualified Internet domain name of the host on which the VQM application resides. There is no default value.

vqe.vqes.vqm_port="vqm_port_no"

TCP port number on which the VQM application listens for video quality data from RTCP Exporter. Allowed range is 1024 to 65535. There is no default value.

vqe.vqes.exporter_enable="true_or_false"

Either true or false. The value true enables RTCP exports, and false disables RTCP exports. The default value is false.


RTCP Exporter remains disabled unless both vqe.vqes.vqm_host and vqe.vqes.vqm_port are configured and are valid.

By default, the vcdb.conf file contains no RTCP Exporter parameters and RTCP Exporter is disabled.

Step 4 To apply the RTCP Exporter parameter values to the /etc configuration files and restart VQE-S, issue the following command:

[root@system]# vqe_cfgtool -apply 

For more information on the vqe_cfgtool command and the -apply option, see "Using the VQE Configuration Tool Command-Line Options" section on page 6-16.


Note The vqe_cfgtool command with -apply asks you if you want to restart VQE-S. When RTCP Exporter parameters are added or modified, this restart is required for the new or changed parameter values to take effect.



Configuring Other Parameters for the VQE-S Host

The set of parameters for the VQE-S host includes many parameters that are not configurable with the VQE Startup Configuration Utility. Many additional parameters are used, for example, to make adjustments to the VQE-S software facilities that perform Unicast Retransmission and Rapid Channel Change.

Read the following to get information on these additional parameters:

Chapter 6, "Configuring VQE Server and VQE Tools" describes the tools and procedures to used to configure all parameters for a VQE-S or VQE Tools system.

Appendix A, "VQE, System, and Network Parameters" describes the VQE-S, system, and network parameters.

The file /etc/vqes/vcdb.conf.sample provides additional information on the VQE-S, system, and network parameters.

Configuring the Edge Router for VQE-S

This section provides some guidance on configuring the edge router that will be directly attached to the VQE-S host. Depending on whether OSPF routing or static routes are used on the VQE-S host, refer to one of the following sections:

For OSPF Routing: Guidance for Configuring the Attached Router

For Static Routes: Guidance for Configuring Feedback Targets on the Attached Router

For OSPF Routing: Guidance for Configuring the Attached Router

If OSPF routing is used for VQE-S traffic, the following sections provide guidance on configuring the edge router that is directly attached to VQE-S:

"VQE-S in Separate OSPF Area" section

"VQE-S in Area 0" section

"General Guidelines" section

For detailed information on OSPF and the Cisco IOS commands used to configure the routing protocol, see the OSPF resources at:

http://www.cisco.com/en/US/tech/tk365/tk480/tsd_technology_support_sub-protocol_home.html


Note In the following sections, Cisco IOS commands are used for some of the configuration examples. However, there is no requirement that a Cisco router be used as the edge router.


VQE-S in Separate OSPF Area

The VQE-S server can be configured to be in a separate OSPF area by specifying the VCDB parameter network.ospf.area to be a non-zero value. With the VQE Startup Configuration Utility or Configuration Tool, this separate area with the VQE-S server can be defined as a normal area or a Not So Stubby Area. Figure 2-4 shows the VQE-S server in a separate OSPF area: area 1.

Figure 2-4 VQE-S Server in a Separate OSPF Area

When the VQE-S server is configured in a separate OSPF area, these guidelines for configuring the directly attached edge router apply:

Configure the edge router interfaces attached to the VQE-S server in the same OSPF area as the VQE-S host.

To keep the routing table on the VQE-S server small in size, configure the separate area (in Figure 2-4, area 1) to be a Not So Stubby Area (NSSA). The VQE-S server must also be configured so that its OSPF area type is a NSSA by specifying the VCDB parameter network.ospf.area_type to have the value "nssa".

With a NSSA, the edge router generates a default route to the access network and advertises the default route in the NSSA (in Figure 2-4, area 1). This default-route mechanism reduces the size of the VQE-S server routing table.

To configure the NSSA and to configure the edge router to advertise the default route in the NSSA, issue the following Cisco IOS commands on the edge router:

router ospf process-id
     area area-id nssa no-summary

When no-summary is specified with area nssa, the edge router advertises the default route in the NSSA but does not inject summary routes into the area.

VQE-S in Area 0

When the VQE-S server is configured within OSPF area 0 (that is, when the network.ospf.area VCDB parameter value is zero, the default), these guidelines for configuring the directly attached edge router apply:

Configure the edge router interfaces to the VQE-S host to be within OSPF area 0

With this configuration, the VQE-S host routing table may be very large depending on the size of the network visible in area 0. If this is a concern, one suggestion is to configure the VQE-S host interfaces to be in a separate OSPF area, as described in the previous section "VQE-S in Separate OSPF Area".

General Guidelines

The following are general edge router configuration guidelines:

Feedback target routes—The feedback target (FBT) routes that are advertised from the VQE-S to the edge router should not be summarized by the edge router if multiple VQE-S servers exist in the network and high availability of VQE-S services is desired. The reason for this is that each FBT route advertises VQE-S services for a particular channel, and if the services for that channel become unavailable on a VQE-S, that VQE-S withdraws the route. This allows another VQE-S in the network to take over services for that channel. However, if the FBT routes are summarized by the edge router, the FBT routes cannot be added and withdrawn individually. Thus redundancy is lost because a VQE-S may still get service requests for a channel that is not available.

Fast convergence—If fast convergence in the case of link failure or other causes in the network is a concern, set the VCDB parameter network.ospf.hello_interval on the VQE-S server to the lowest possible setting, which is one second. Also, set the same hello interval value for each VQE-S interface on the edge router. This allows a link failure to be detected as quickly as possible between the VQE-S and the edge router. A general rule of thumb when changing the default hello interval is to set the dead interval to be four times the hello interval. Therefore, the VCDB parameter network.ospf.dead_interval should be set to four seconds, and a corresponding change must be made on the edge router for each VQE-S traffic interface. For each interface, the Cisco IOS commands on the edge router are as follows:

interface name
     ip ospf hello-interval 1
     ip ospf dead-interval 4

Interface authentication—If MD5 authentication is desired between OSPF peers, all VQE-S traffic interfaces must have the same key value and key ID when the VCDB parameters network.ospf.md5_key and network.ospf.md5_keyid are set. Therefore, the same MD5 key value and key ID must be configured on the edge router for all traffic interfaces to the VQE-S.

VQE-S redundancy—All VQE-S servers in the network must be configured to use the same routing type: either all must be static or all must be ospf. This is required for anycast ECMP across multiple VQE-S servers to work properly.

Forwarding table—The size of the forwarding table on the edge router may be restricted, which will limit the number of VQE-S servers that can participate in anycast ECMP properly. On a Cisco 7600 router, the size of the forwarding table can be increased to allow more VQE-S servers and more traffic interfaces per VQE-S using the following commands:

router ospf process-id
     maximum-paths maximum-paths

Directly connected VQE-S—The VQE-S server must be directly connected to the edge router on all VQE-S traffic interfaces. Specifically, OSPF virtual links are not allowed.

For information on configuring the edge router to generate and advertise a default route into a Not So Stubby Area, see the "VQE-S in Separate OSPF Area" section.

For Static Routes: Guidance for Configuring Feedback Targets on the Attached Router

When channels are configured with a channel-provisioning tool such as VQE Channel Provisioning Tool, it is required that you specify a unique feedback target (FBT) address for each channel. If static routes are used for VQE-S traffic, the router that is directly attached to the VQE-S host must have a static route configured for the FBT address so that the router can reach the target. If the FBT addresses are allocated within a contiguous address range, this configuration piece can be done with a single aggregated route.

For example, if the FBT addresses for the channels are assigned to be 8.86.1.1, 8.86.1.2, 8.86.1.3, ..., 8.86.1.250, then the single static route 8.86.1.0/24 configured on the directly attached router allows any of these FBT addresses to be reached. The commands on the router for the FBT addresses would be as follows:

configure terminal 
ip route 8.86.1.0 255.255.255.0 11.2.9.2 
ip route 8.86.1.0 255.255.255.0 11.2.10.2 
ip route 8.86.1.0 255.255.255.0 11.2.11.2 
ip route 8.86.1.0 255.255.255.0 11.2.12.2 

For the preceding configuration example, the IP addresses 11.2.9.2, 11.2.10.2, 11.2.11.2, and 11.2.12.2 have been assigned to the Ethernet interfaces on the VQE-S host. See Figure D-3 on page D-6. These Ethernet interfaces are used for VQE-S traffic, including Unicast Retransmission and Rapid Channel Change traffic.