Table Of Contents

Getting Started with VQE-S, VCPT, and VQE Client Channel Configuration Delivery Server

Web Browser and Screen Resolution Requirements

Configuring Terminal Emulation Software

Setting Up 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

Installing the Certificates , Private Key, and Keystore

Setting Up a Cisco CDE110 That Hosts VQE-S

Prerequisites for a Cisco CDE110 That Hosts VQE-S

Connecting Cables for VQE-S

Setting Up SSL Certificates for VQE-S

Configuring the Linux Operating System for VQE-S

Configuring Quagga for VQE-S

Configuring Net-SNMP

Ensuring That Only Trusted HTTPS Clients Can Push an SDP File

Starting System Services and Verifying Status

Starting the VQE-S Processes and Verifying Status

Restarting the System and Verifying System and VQE-S Status

Configuring VQE-S RTCP Exporter

Stopping and Restarting VQE-S

Setting Up a Cisco CDE110 That Hosts VCPT and VQE Client Channel Configuration Delivery Server

Prerequisites for a Cisco CDE110 That Hosts VCPT

Connecting Cables

Setting Up SSL Certificates for VCPT

Configuring the Linux Operating System for VCPT and VQE Client Channel Configuration Delivery Server

Configuring Net-SNMP

Starting System Services and Verifying Status

(Optional) Configuring Quagga for VCPT and VQE Client Channel Configuration Delivery Server

Starting the VQE Client Channel Configuration Delivery Server Process and Verifying Status

Restarting the System and Verifying System, VCPT, and VQE Client Channel Configuration Delivery Server Status

Getting Started with VQE-S, VCPT, and VQE Client Channel Configuration Delivery Server

---

This chapter explains how to perform the initial configuration tasks needed to get the two categories of Cisco CDE110 appliances running with the Cisco VQE software: a CDE110 hosting VQE Server (VQE-S) and a CDE110 hosting VQE Channel Provisioning Tool (VCPT) and VQE Client Channel Configuration Delivery Server.

The chapter contains the following major topics:

•Web Browser and Screen Resolution Requirements

•Configuring Terminal Emulation Software

•Setting Up SSL Certificates

•Setting Up a Cisco CDE110 That Hosts VQE-S

•Configuring VQE-S RTCP Exporter

•Setting Up a Cisco CDE110 That Hosts VCPT and VQE Client Channel Configuration Delivery Server

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 and Screen Resolution 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.

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

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.

---

Tip We recommend that you use CA-signed certificates rather than self-signed certificates. Self-signed certificates cause more maintenance issues than CA-signed certificates do. The VQE-S AMT and VCPT infrastructures support both CA-signed certificates and self-signed certificates. This document provides instructions for only CA-signed certificates.

---

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:

•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, 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

Creating Your Own Certificate Authority

---

Note This task is not needed if you are using certificates that are signed by a commerical 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 certficate 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 "Installing the Certificates , Private Key, and Keystore" section that follows.

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

---

Setting Up a Cisco CDE110 That Hosts VQE-S

This section explains how to perform the initial configuration tasks for a Cisco CDE110 hosting VQE-S. Perform these tasks in the order shown:

1. Prerequisites for a Cisco CDE110 That Hosts VQE-S

2. Configuring the Linux Operating System for VQE-S

3. Configuring Quagga for VQE-S

4. Configuring Net-SNMP

5. Ensuring That Only Trusted HTTPS Clients Can Push an SDP File

6. Starting System Services and Verifying Status

7. Starting the VQE-S Processes and Verifying Status

8. Restarting the System and Verifying System and VQE-S Status

Prerequisites for a Cisco CDE110 That Hosts VQE-S

This section explains tasks that should be performed before setting up a Cisco CDE110 that hosts VQE-S.

Connecting Cables for VQE-S

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

•Category 5 UTP cable connects 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.

•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.

---

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 for VQE-S

It is recommended that you deploy your own Secure Sockets Layer (SSL) certificates or commercial SSL certificates prior to beginning the tasks for setting up a Cisco CDE110 that hosts VQE-S. For information on setting up the certificates, see "Setting Up SSL Certificates" section.

Configuring the Linux Operating System for VQE-S

This section explains the initial Linux configuration tasks needed for a Cisco CDE110 appliance that will run VQE-S software. The explanation assumes that the needed software for Linux and VQE-S has been pre-installed on the Cisco CDE110 appliance. For Red Hat Enterprise Linux 5.0 documentation, go to the following website:

http://www.redhat.com/docs/manuals/enterprise/

For software configuration, the RJ-45 NIC (Ethernet) ports on the Cisco CDE110 back panel are specified as eth1, eth2, eth3, and eth4 as shown in Figure 2-1.

Figure 2-1 NIC Port Numbering for Software Configuration

---

Note On the back panel, the NIC ports labeled 1, 2, 3, and 4 are, respectively, for interfaces eth1, eth2, eth3, and eth4.

---

For the configuration examples in this section, Figure 2-2 shows the IP addresses for interfaces eth1, eth2, eth3, and eth4 and the corresponding interfaces on the edge router.

Figure 2-2 IP Addresses for VQE-S Configuration Examples

To configure the Linux operating system and other software for VQE-S, follow these steps:

---

Step 1 Press the front panel power switch to power on the Cisco CDE110 appliance.

The operating system boots.

Step 2 When local host:local domain login: is displayed, log in as root.

Step 3 When Enter New password: is displayed, enter the password you want to set for root.

When creating the password, read and follow the directions that are provided for password security.

A valid password should be a mix of upper and lower case letters,

digits, and other characters.  You can use an 8 character long

password with characters from at least 3 of these 4 classes, or

a 7 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.

A passphrase should be of at least 3 words, 12 to 40 characters

long and contain enough different characters.

Step 4 For the eth1, eth2, eth3, and eth4 interfaces, use a text editor to modify the /etc/sysconfig/network-scripts/ifcfg-eth# file (where # is the number of the Ethernet interface, such as ifcfg-eth1) and do the following:

•Change ONBOOT to yes

•Add IPADDR=ip_address_of this_system_eth#

•Add NETMASK=netmask_for_eth#_network

As an example, for the eth1 interface, the /etc/sysconfig/network-scripts/ifcfg-eth1 file would include the following after the modifications:

ONBOOT=yes

IPADDR=11.2.9.2 

NETMASK=255.255.255.0

Step 5 To bring the Ethernet interfaces up, issue the ifup command for eth1, eth2, eth3, and eth4. For example:

[root@system]# ifup eth1 

Step 6 Verify that the eth1, eth2, eth3, and eth4 interfaces are configured correctly and up and running.

•Use the ifconfig interface command to verify that each Ethernet interface is up and running and the IP address and netmask for each are set correctly. The following example is for eth1:

[root@system]# ifconfig eth1 

eth1      Link encap:Ethernet  HWaddr 00:0E:0C:C6:F3:0F  

          inet addr:11.2.10.2  Bcast:11.2.10.255  Mask:255.255.255.0

          inet6 addr: fe80::20e:cff:fec6:f30f/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:3 errors:0 dropped:0 overruns:0 frame:0

          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:192 (192.0 b)  TX bytes:2700 (2.6 KiB)

          Base address:0x3000 Memory:b8800000-b8820000 

•Use the ip link show eth# command (where # is the Ethernet interface number) to check that the link is up. The following example is for eth1:

[root@system]# ip link show eth1 

eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:0e:0c:c6:e4:fe brd ff:ff:ff:ff:ff:ff

•Use the ping command to check that the Cisco CDE110 can reach the connected edge router. For example:

[root@system]# ping 11.2.9.1 

Step 7 Use a text editor to modify the /etc/hosts file and add a line with the IP address for eth1 and the associated hostname. For example:

11.2.9.2 starfire-iptv 

Step 8 Use a text editor to modify the /etc/sysconfig/network file and change HOSTNAME to the hostname of this system. For example:

HOSTNAME=starfire-iptv 

---

Note The changes to the files /etc/hosts and /etc/sysconfig/network do not take effect until the system is rebooted, as described in the "Restarting the System and Verifying System and VQE-S Status" section.

---

Step 9 To create the password for the vqes user (a pre-created Linux user ID), issue the following command:

[root@system]# passwd vqes 

Enter a password that follows the password guidelines.

The vqes username and password can be used log in to the VQE-S Application Monitoring Tool. This username and password cannot be used to log in to Linux directly using SSH.

Step 10 If you have not already done so, follow the directions in the "Setting Up SSL Certificates" section to set up the Secure Socket Layer (SSL) certificates required for VQE-S.

---

Configuring Quagga for VQE-S

Quagga is a routing software package that provides TCP/IP based routing services. Quagga is pre-installed on the Cisco CDE110. A few Quagga-related files must be configured for the VQE-S software to work correctly. For complete information on Quagga configuration, see the Quagga documentation at:

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

To perform the Quagga configuration required for VQE-S, follow these steps:

---

Step 1 Use a text editor to create an /etc/quagga/zebra.conf file that contains the lines shown in the example that follows. Be sure to replace YOUR_SYSTEM_NAME and YOUR_vty_PASSWORD in the example with the system name and vty password that you will use for your Cisco CDE110 system. See the Quagga documentation for more information on the zebra.conf file and vty passwords.

---

Note Depending on your network requirements, the /etc/quagga/zebra.conf file may contain additional information. The zebra.conf file shown below has the minimum needed for the VQE-S software to work correctly.

---

!

hostname YOUR_SYSTEM_NAME-zebra 

password YOUR_vty_PASSWORD 

!

interface eth1

 link-detect

 ipv6 nd suppress-ra

!

interface eth2

 link-detect

 ipv6 nd suppress-ra

!

interface eth3

 link-detect

 ipv6 nd suppress-ra

!

interface eth4

 link-detect

 ipv6 nd suppress-ra

!

interface lo

!

interface sit0

 ipv6 nd suppress-ra

!

!

line vty

!

Step 2 Use a text editor to create an /etc/quagga/ospfd.conf file that contains the lines shown in the example that follows. Be sure to replace the following items in the example with the correct information:

•YOUR_SYSTEM_NAME is the name of your Cisco CDE110 system.

•YOUR_vty_PASSWORD is the vty password that you will use for your system. See the Quagga documentation for more information on the zebra.conf file and vty passwords.

---

Note In the template file /etc/quagga/ospfd.conf, replace following line:
     # router-id UNIQUE-ROUTER-ID (in a.b.c.d form)
with this line:
     ospf router-id A.B.C.D

---

•In the ospf router-id statement, A.B.C.D is the router ID of the OSPF process. Usually this is the IP address of the OSPF router.

•In the network area statement, A.B.C.D/m specifies the address and mask of OSPF-enabled interfaces, and W.X.Y.Z specifies an OSPF area. More than one network area statement may be required. As an example, the following statement is for the eth1 interface:

network 11.2.9.0/24 area 0.0.0.0

Only interfaces identified by a network area statement participate in the OSPF area.

---

Note Depending on your network requirements, the /etc/quagga/ospfd.conf file may contain additional information. The ospfd.conf file shown below has the minimum configuration needed for the VQE-S software to work correctly.

---

hostname YOUR_SYSTEM_NAME-ospfd

password YOUR_vty_PASSWORD 

!

!

!

interface eth1

 ip ospf cost 10

!

interface eth2

 ip ospf cost 10

!

interface eth3

 ip ospf cost 10

!

interface eth4

 ip ospf cost 10

!

interface lo

!

interface sit0

!

router ospf

 ospf router-id A.B.C.D 

 redistribute connected

 network A.B.C.D/m area W.X.Y.Z 

!

!

line vty

!

log stdout

In the ip ospf cost statements in the example, the interfaces eth1, eth2, eth3, and eth4 should be given identical link costs of 10.

Management Interface and OSPF Routing

If your deployment uses one of the CDE110 Ethernet ports as the interface to a management network, use the passive-interface statement to suppress OSPF routing updates on that interface.

passive-interface eth_interface 

In the preceding, eth_interface is name of the Ethernet interface that will be used as the CDE110 management interface. Using the passive-interface statement makes the management interface reachable only to devices on the management network.

---

Note Using a CDE110 Ethernet interface for a management network makes that interface unavailable for incoming multicast streams or outgoing Error Repair traffic.

If you use one Ethernet interface for a management network, be sure to adjust the interface names specified in the interface option for the Multicast Load Balancer (MLB) process to reflect the interfaces that are available for use by the MLB. For information on the interface option, see Table A-5 on page A-8.

---

In the next example, the eth1 interface is used for the management network.

•No OSPF cost is assigned to the eth1 interface.

•The IP address of eth2 is used in the ospf router-id statement.

•The passive-interface statement suppresses OSPF routing on the eth1 interface.

hostname YOUR_SYSTEM_NAME-ospfd

password YOUR_vty_PASSWORD 

!

!

!

interface eth1

!

interface eth2

 ip ospf cost 10

!

interface eth3

 ip ospf cost 10

!

interface eth4

 ip ospf cost 10

!

interface lo

!

interface sit0

!

router ospf

 ospf router-id 11.2.10.2 

 redistribute connected

 passive-interface eth1

 network A.B.C.D/m area W.X.Y.Z 

!

!

line vty

!

log stdout

---

Configuring Net-SNMP

The CDE110 that hosts VQE-S uses Net-SNMP, a third-party product, for SNMP support for some basic, non-VQE system services. Net-SNMP offers a set of built-in MIBs for Linux platforms. For more information on Net-SNMP support, see Appendix B, "Using Net-SNMP."

You must configure Net-SNMP on the Cisco CDE110 that hosts VQE-S. For information on configuring Net-SNMP, see the Net-SNMP website:

http://www.net-snmp.com/

Ensuring That Only Trusted HTTPS Clients Can Push an SDP File

If your IPTV deployment will use VQE Channel Provisioning Tool (VCPT) to send channel information to the VQE Servers, it is recommended that you configure each CDE110 that hosts VQE-S so that only trusted HTTPS clients can send the channel information to the CDE110. For more information on VCPT and how it sends channel information, see "VQE Channel Provisioning Tool and Channel Information" section on page 1-7.

The iptables command provides a Linux-based, packet-filtering firewall that can be used to restrict HTTPS traffic to only trusted clients.

To allow only traffic from trusted HTTPS clients on the CDE110 port used for HTTPS, follow these steps:

---

Step 1 If needed, log in as root on the CDE110 that hosts VQE-S.

Step 2 To allow inbound TCP traffic from the trusted HTTPS client on the VCPT host that will provide channel information to this VQE-S, issue the following command:

iptables -A INPUT -p tcp --dport 444 -s VCPT_Host_IP_Address -j ACCEPT

In the preceding command, the following arguments specify the source and destination of the TCP traffic:

•--dport specifies the destination port on the VQE-S host. On the CDE110, the value is always 444.

•-s specifies the source IP address of the packet. The value is the IP address of the VCPT host.

For example:

[root@system]# iptables -A INPUT -p tcp --dport 444 -s 10.86.17.200/32 -j ACCEPT 

Step 3 To block all other inbound TCP traffic on the port, issue the following command:

[root@system]# iptables -A INPUT -p tcp --dport 444 -j REJECT 

Starting System Services and Verifying Status

To start system services and verify their status, follow these steps:

---

Step 1 To start system services, issue the following command:

[root@system]# /usr/bin/vqes_init_setup 

---

Note The vqes_init_setup script should be used only when the system services are started for the first time because the script resets any user-defined configuration to the initial default values.

---

Table 2-1 lists the system services that are started by the vqes_init_setup script.

Table 2-1 System Services for CDE100 That Hosts VQE-S

Service	Description
watchquagga	The Quagga watchdog process. If a Quagga daemon crashes or hangs, watchquagga will restart it automatically.
ospfd	The OSPF daemon.
zebra	The zebra daemon.
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.

Step 2 To verify that the run levels for the Quagga processes have been set correctly, issue the following commands and check that the run-level output is as shown below:

[root@system]# chkconfig --list | grep watchquagga 

watchquagga     0:off   1:off   2:on    3:on    4:on    5:on    6:off

[root@system]# chkconfig --list | grep zebra 

zebra      0:off   1:off   2:on   3:on   4:on   5:on   6:off 

[root@system]# chkconfig --list | grep ospfd 

ospfd      0:off   1:off   2:on   3:on   4:on   5:on   6:off

Step 3 To verify that the Quagga processes are running, issue the following command:

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

root 2645 1 0 Jul08 ? 00:00:34 /usr/sbin/watchquagga -Az -d -b_ 
-r/sbin/service_%s_restart -s/sbin/service_%s_start -k/sbin/service_%s_stop zebra 
ospfd 
quagga 11331 1 0 12:05 ? 00:00:02 /usr/sbin/ospfd -d -A 127.0.0.1 -f 
/etc/quagga/ospfd.conf 
root 11486 10258 0 13:16 pts/1 00:00:00 grep quagga 
quagga 24657 1 0 03:30 ? 00:00:02 /usr/sbin/zebra -d -A 127.0.0.1 -f 
/etc/quagga/zebra.conf 

Check that the following three processes are running:

•watchquagga

•ospfd

•zebra

Step 4 To verify the sshd run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep sshd 

sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

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

root      2835     1  0 Jul18 ?        00:00:00 /usr/sbin/sshd

Step 5 To verify the httpd run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep httpd 

httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 6 To verify the tomcat5 run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep tomcat5 

tomcat5         0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 7 To verify the snmpd run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep snmpd 

snmpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 8 To verify the snmpsa run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep snmpsa 

snmpsa          0:off   1:off   2:on    3:on    4:on    5:on    6:off

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

root      2959     1  0 Jul18 ?        00:02:26 /usr/local/snmpsa/bin/smSubagent

---

Starting the VQE-S Processes and Verifying Status

To start the VQE-S processes and verify status, follow these steps:

---

Step 1 Use a text editor to modify the /etc/inittab file so that the following line is uncommented—that is, remove the # character at the beginning of the line. The line before modification is:

#vqes:3:respawn:/opt/vqes/bin/process_monitor -c /etc/opt/vqes/vqes.conf 

The line after the # character is removed is:

vqes:3:respawn:/opt/vqes/bin/process_monitor -c /etc/opt/vqes/vqes.conf 

Step 2 To start VQE-S, issue this command:

[root@system]# init Q 

---

Note Syslog error messages are displayed indicating that the VQE-S processes are starting without a channel configuration file. This is normal behavior because a channel configuration file from the VQE Channel Provisioning Tool (VCPT) has not yet been sent to VQE-S. Creating and sending the file is done when the Cisco CDE110 that hosts VCPT is configured, and VCPT is used to create and send the file.

---

Step 3 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 4 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 vqes 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. Figure 2-3 shows an example.

Figure 2-3 VQE-S Processes in the VQE-S Application Monitoring Tool

---

Restarting the System and Verifying System and VQE-S Status

To restart the Cisco CDE110 and verify system and VQE-S status, follow these steps:

---

Note The output for the commands issued in this section has been omitted. For example output, see the previous sections in this chapter where the same commands were issued.

---

---

Step 1 To restart the system, issue the following command:

[root@system]# init 6 

The operating system boots.

---

Note Syslog error messages are displayed indicating that the VQE-S processes are starting without a channel configuration file. This is normal behavior because a channel configuration file from the VQE Channel Provisioning Tool (VCPT) has not yet been sent to VQE-S. Creating and sending the file is done when the Cisco CDE110 that hosts VCPT is configured, and VCPT is used to create and send the file.

---

Step 2 Log in as root.

Step 3 To verify that interfaces eth1, eth2, eth3, and eth4 are up and running and the IP address and netmask for each are set correctly, issue the following command:

[root@system]# ifconfig -a 

... Output omitted 

Step 4 To verify that the Quagga processes are running, issue the following command:

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

... Output omitted 

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

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

... Output omitted 

Step 6 To verify that the sshd process is running, issue the following command:

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

... Output omitted 

Step 7 To verify that the httpd process is running, issue the following command:

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

... Output omitted 

Step 8 To verify that the tomcat5 process is running, issue the following command:

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

... Output omitted 

Step 9 To verify that the snmpd process is running, issue the following command:

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

... Output omitted 

Step 10 To verify that the snmpsa process is running, issue the following command:

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

... Output omitted 

Step 11 Do one of the following:

•If the preceding checks indicate that all is well, proceed to "Setting Up a Cisco CDE110 That Hosts VCPT and VQE Client Channel Configuration Delivery Server" section.

•If one of the preceding checks fails, inspect the configuration of the item that failed and make any needed adjustments.

---

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.

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 parameters in the /etc/vqes/vqes.conf file. To configure the parameters, 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 

---

Setting Up a Cisco CDE110 That Hosts VCPT and VQE Client Channel Configuration Delivery Server

This section explains how to perform the initial configuration tasks for a Cisco CDE110 hosting VQE Channel Provisioning Tool (VCPT) and VQE Client Channel Configuration Delivery Server. Perform these tasks in the order shown:

1. Prerequisites for a Cisco CDE110 That Hosts VCPT

2. Configuring the Linux Operating System for VCPT and VQE Client Channel Configuration Delivery Server

3. Configuring Net-SNMP

4. Starting System Services and Verifying Status

5. (Optional) Configuring Quagga for VCPT and VQE Client Channel Configuration Delivery Server

6. Starting the VQE Client Channel Configuration Delivery Server Process and Verifying Status

7. Restarting the System and Verifying System, VCPT, and VQE Client Channel Configuration Delivery Server Status

Prerequisites for a Cisco CDE110 That Hosts VCPT

This section explains tasks that should be performed before setting up a Cisco CDE110 that hosts VCPT.

Connecting Cables

The following cable connections are used on the Cisco CDE110 that hosts VCPT:

•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.

---

Note This section assumes that one Ethernet interface (eth1) be used to connect to the VQE network.

---

•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.

---

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 for VCPT

It is recommended that you deploy your own or commercial Secure Sockets Layer (SSL) certificates prior to beginning the tasks for setting up a Cisco CDE110 that hosts VCPT. For information on setting up the certificates, see "Setting Up SSL Certificates" section.

Configuring the Linux Operating System for VCPT and VQE Client Channel Configuration Delivery Server

This section explains the initial Linux configuration tasks needed for a Cisco CDE110 appliance that will run VCPT and VQE Client Channel Configuration Delivery Server software. The explanation assumes that the needed software for Linux, VCPT, and VQE Client Channel Configuration Delivery Server have been pre-installed on the Cisco CDE110 appliance. For Red Hat Linux 5.0 documentation, go to the following website:

http://www.redhat.com/docs/manuals/enterprise/

For software configuration, the RJ-45 NIC (Ethernet) ports on the Cisco CDE110 back panel are specified as eth1, eth2, eth3, and eth4 as shown in Figure 2-4.

Figure 2-4 NIC Port Numbering for Software Configuration

---

Note On the back panel, the NIC ports labeled 1, 2, 3, and 4 are, respectively, for interfaces eth1, eth2, eth3, and eth4.

---

For the configuration examples in this section, Figure 2-5 shows the IP addresses for interface eth1 and the corresponding interface on the edge router.

Figure 2-5 IP Addresses for VCPT and VQE Client Channel Configuration Delivery Server Configuration Examples

To configure the Linux operating system and other software for VCPT and VQE Client Channel Configuration Delivery Server, follow these steps:

---

Step 1 Press the front panel power switch to power on the Cisco CDE110 appliance.

The operating system boots.

Step 2 When local host:local domain login: is displayed, log in as root.

Step 3 When Enter New password: is displayed, enter the password you want to set for root.

When creating the password, read and follow the directions that are provided for password security.

A valid password should be a mix of upper and lower case letters,

digits, and other characters.  You can use an 8 character long

password with characters from at least 3 of these 4 classes, or

a 7 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.

A passphrase should be of at least 3 words, 12 to 40 characters

long and contain enough different characters.

Step 4 For the eth1 interface, use a text editor to modify the /etc/sysconfig/network-scripts/ifcfg-eth1 file and do the following:

•Change ONBOOT to yes

•Add IPADDR=ip_address_of this_system_eth1

•Add NETMASK=netmask_for_eth1_network

As an example, for the eth1 interface, the /etc/sysconfig/network-scripts/ifcfg-eth1 file would include the following after the modifications:

ONBOOT=yes

IPADDR=11.2.15.2 

NETMASK=255.255.255.0

Step 5 To bring the Ethernet interfaces up, issue the ifup command for the eth1. For example:

[root@system]# ifup eth1 

Step 6 Verify that the eth1 interface is configured correctly and up and running.

•Use the ifconfig interface command to verify that the Ethernet interface is up and running and the IP address and netmask is set correctly. The following example is for eth1:

[root@system]# ifconfig eth1 

eth1      Link encap:Ethernet  HWaddr 00:0E:0C:C6:F3:0F  

          inet addr:11.2.15.2  Bcast:11.2.15.255  Mask:255.255.255.0

          inet6 addr: fe80::20e:cff:fec6:f30f/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:3 errors:0 dropped:0 overruns:0 frame:0

          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:192 (192.0 b)  TX bytes:2700 (2.6 KiB)

          Base address:0x3000 Memory:b8800000-b8820000 

•Use the ip link show eth# command (where # is the Ethernet interface number) to check that the link is up. For example:

[root@system]# ip link show eth1 

eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:0e:0c:c6:e4:fe brd ff:ff:ff:ff:ff:ff

•Use the ping command to check that the Cisco CDE110 can reach the connected edge router. For example:

[root@system]# ping 11.2.15.1 

Step 7 Use a text editor to modify the /etc/hosts fileand add a line with the IP address for eth1 and the associated hostname. For example:

11.2.15.2 starfire1-iptv 

Step 8 Use a text editor to modify the /etc/sysconfig/network file as follows:

a. Change HOSTNAME to the hostname of this system. For example:

HOSTNAME=starfire1-iptv 

---

Note Step 8b configures a default route for the eth1 interface. If more than one Ethernet interface is configured, then routing is needed. Quagga configuration is explained in the "(Optional) Configuring Quagga for VCPT and VQE Client Channel Configuration Delivery Server" section. Standard Linux routing can also be used.

---

b. Configure a default route for the eth1 interface with the following statement:

GATEWAY=ip_address_of_remote_gateway 

For example:

GATEWAY=11.2.15.1 

---

Note The changes to the files /etc/hosts and /etc/sysconfig/network do not take effect until the system is rebooted as described in the "Restarting the System and Verifying System, VCPT, and VQE Client Channel Configuration Delivery Server Status" section.

---

Step 9 To create the password for the vqes user (a pre-created Linux user ID), issue the following command:

[root@system]# passwd vqes 

Enter a password that follows the password guidelines.

The vqes username and password can be used to log in to the VQE Channel Provisioning Tool. This username and password cannot be used to log in to Linux directly using Secure Shell (SSH).

Step 10 If you have not already done so, follow the directions in the "Setting Up SSL Certificates" section to set up the Secure Socket Layer (SSL) certificates required for VCPT.

---

Configuring Net-SNMP

The CDE110 that hosts VCPT uses Net-SNMP, a third-party product, for SNMP support for some basic, non-VQE system services. Net-SNMP offers a set of built-in MIBs for Linux platforms. For more information on Net-SNMP support, see Appendix B, "Using Net-SNMP."

You must configure Net-SNMP on the Cisco CDE110 that hosts VCPT. For information on configuring Net-SNMP, see the Net-SNMP website:

http://www.net-snmp.com/

Starting System Services and Verifying Status

To start system services and verify their status, follow these steps:

---

Step 1 To start system services, issue the following command:

[root@system]# /usr/bin/vqes_init_setup 

---

Note The vqes_init_setup script should be used only when the system services are started for the first time because the script resets any user-defined configuration to the initial default values.

---

Table 2-2 lists the system services that are started by the vqes_init_setup script.

Table 2-2 System Services for CDE110 That Hosts VCPT

Service	Description
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.

Step 2 To verify the sshd run levels and that the process is running, issue the following commands and check that the run-level output is as shown below:

[root@system]# chkconfig --list | grep sshd 

sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

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

root      2835     1  0 Jul18 ?        00:00:00 /usr/sbin/sshd

Step 3 To verify the httpd run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep httpd 

httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 the tomcat5 run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep tomcat5 

tomcat5         0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 the snmpd run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep snmpd 

snmpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

[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 the snmpsa run levels and that the process is running, issue the following commands:

[root@system]# chkconfig --list | grep snmpsa 

snmpsa          0:off   1:off   2:on    3:on    4:on    5:on    6:off

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

root      2959     1  0 Jul18 ?        00:02:26 /usr/local/snmpsa/bin/smSubagent

---

(Optional) Configuring Quagga for VCPT and VQE Client Channel Configuration Delivery Server

---

Note If one Ethernet interface is being used for the network connection, configuring Quagga is optional for the Cisco CDE110 that hosts VCPT and VQE Client Channel Configuration Delivery Server. If more than one Ethernet interface is used, you must configure Quagga (or use some other mechanism) to provide the needed routing services for those interfaces. This procedure assumes that two Ethernet interfaces on the Cisco CDE110 are being used for VQE network connections.

---

Quagga is a routing software package that provides TCP/IP-based routing services. Quagga is pre-installed on the Cisco CDE110. A few Quagga-related files must be configured for VCPT and VQE Client Channel Configuration Delivery Server software to work correctly. For complete information on Quagga configuration, see the Quagga documentation at:

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

To perform the Quagga configuration required for VCPT and VQE Client Channel Configuration Delivery Server, follow these steps:

---

Step 1 Use a text editor to create an /etc/quagga/zebra.conf file that contains the lines shown in the example that follows. Be sure to replace YOUR_SYSTEM_NAME and YOUR_vty_PASSWORD in the example with the system name and vty password that you will use for your Cisco CDE110 system. See the Quagga documentation for more information on the zebra.conf file and vty passwords.

---

Note Depending on your network requirements, the /etc/quagga/zebra.conf file may contain additional information. The zebra.conf file shown below has the minimum configuration needed for the VCPT and VQE Client Channel Configuration Delivery Server software to work correctly.

---

!

hostname YOUR_SYSTEM_NAME-zebra 

password YOUR_vty_PASSWORD 

!

interface eth1

 link-detect

 ipv6 nd suppress-ra

!

interface eth2

 link-detect

 ipv6 nd suppress-ra

!

interface lo

!

interface sit0

 ipv6 nd suppress-ra

!

!

line vty

!

Step 2 Use a text editor to create an /etc/quagga/ospfd.conf file that contains the lines shown in the example that follows. Be sure to replace the following items in the example with the correct information:

•YOUR_SYSTEM_NAME is the name of your Cisco CDE110 system.

•YOUR_vty_PASSWORD is the vty password that you will use for your system. See the Quagga documentation for more information on the zebra.conf file and vty passwords.

---

Note In the template file /etc/quagga/ospfd.conf, replace following line:
     # router-id UNIQUE-ROUTER-ID (in a.b.c.d form)
with this line:
     ospf router-id A.B.C.D

---

•In the ospf router-id statement, A.B.C.D is the router ID of the Open Shortest Path First (OSPF) process. Usually this is the IP address of the OSPF router.

•In the network area statement, A.B.C.D/m specifies the address and mask of OSPF-enabled interfaces, and W.X.Y.Z specifies an OSPF area. More than one network area statement may be required. As an example, the following statement is for the eth1 interface:

network 11.2.15.0/24 area 0.0.0.0

Only interfaces identified by a network area statement participate in the OSPF area.

---

Note Depending on your network requirements, the /etc/quagga/ospfd.conf file may contain additional information. The ospfd.conf file shown below has the minimum configuration needed for the VCPT and VQE Client Channel Configuration Delivery Server software to work correctly.

---

hostname YOUR_SYSTEM_NAME-ospfd

password YOUR_vty_PASSWORD 

!

!

!

interface eth1

 ip ospf cost 10

!

interface eth2

 ip ospf cost 10

!

interface lo

!

interface sit0

!

router ospf

 ospf router-id A.B.C.D 

 redistribute connected

 network A.B.C.D/m area W.X.Y.Z 

!

!

line vty

!

log stdout

In the ip ospf cost statements in the example, the interfaces eth1 and eth2 should be given identical link costs of 10.

Management Interface and OSPF Routing

If your deployment uses one of the CDE110 Ethernet ports as the interface to a management network, use the passive-interface statement to suppress OSPF routing updates on that interface.

passive-interface eth_interface 

In the preceding, eth_interface is name of the Ethernet interface that will be used as the CDE110 management interface. Using the passive-interface statement makes the management interface reachable only to devices on the management network.

In the next example, the eth1 interface is used for the management network, and the eth2 and eth3 interfaces are used for VQE network connections.

•No OSPF cost is assigned to the eth1 interface.

•The IP address of eth2 (11.2.16.2) is used in the ospf router-id statement.

•The passive-interface statement suppresses OSPF routing on the eth1 interface.

hostname YOUR_SYSTEM_NAME-ospfd

password YOUR_vty_PASSWORD 

!

!

interface eth1

!

interface eth2

 ip ospf cost 10

!

interface eth3

 ip ospf cost 10

!

interface lo

!

interface sit0

!

router ospf

 ospf router-id 11.2.16.2 

 redistribute connected

 passive-interface eth1

 network A.B.C.D/m area W.X.Y.Z 

!

!

line vty

!

log stdout

Step 3 To verify that the run levels for the Quagga processes have been set correctly, issue the following commands and check that the output is as shown below:

[root@system]# chkconfig --list | grep watchquagga 

watchquagga     0:off   1:off   2:on    3:on    4:on    5:on    6:off

[root@system]# chkconfig --list | grep zebra 

zebra      0:off   1:off   2:on   3:on   4:on   5:on   6:off 

[root@system]# chkconfig --list | grep ospfd 

ospfd      0:off   1:off   2:on   3:on   4:on   5:on   6:off

Step 4 To activate and start the Quagga zebra and ospfd processes, issue the following commands:

[root@system]# chkconfig zebra on 

[root@system]# /etc/init.d/zebra start 

[root@system]# chkconfig ospfd on 

[root@system]# /etc/init.d/ospfd start 

Step 5 After the zebra and ospfd processes have started, issue these commands to activate and start the Quagga watchquagga process:

[root@system]# chkconfig watchquagga on 

[root@system]# /etc/init.d/watchquagga start 

Step 6 To verify that the Quagga processes are running, issue the following command:

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

root 2645 1 0 Jul08 ? 00:00:34 /usr/sbin/watchquagga -Az -d -b_ 
-r/sbin/service_%s_restart -s/sbin/service_%s_start -k/sbin/service_%s_stop zebra 
ospfd 
quagga 11331 1 0 12:05 ? 00:00:02 /usr/sbin/ospfd -d -A 127.0.0.1 -f 
/etc/quagga/ospfd.conf 
root 11486 10258 0 13:16 pts/1 00:00:00 grep quagga 
quagga 24657 1 0 03:30 ? 00:00:02 /usr/sbin/zebra -d -A 127.0.0.1 -f 
/etc/quagga/zebra.conf 

Check that the following three Quagga processes are running:

•watchquagga—The watchdog process. If a Quagga daemon crashes or hangs, watchquagga will restart it automatically.

•ospfd—The OSPF daemon.

•zebra—The zebra daemon.

---

Starting the VQE Client Channel Configuration Delivery Server Process and Verifying Status

This section explains how to start the VQE Client Channel Configuration Delivery Server process and verify that the process is running and that VCPT is available.

---

Note 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.

---

To start the VQE Client Channel Configuration Delivery Server process and verify that it is running, follow these steps:

---

Step 1 To start VQECCfgDeliveryServer (VQE Client Channel Configuration Delivery Server) and verify status, issue this command:

[root@system]# init Q 

Step 2 To check that the VQE Client Channel Configuration Delivery Server (VCDS) process is running, issue the following command:

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

root 2928 1 0 01:31 ? 00:00:00 /opt/vqes/bin/VQECCfgDeliveryServer -f 
/etc/opt/vqes/VCDServer.cfg

Step 3 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 using the vqes username and password. (Any valid Linux username and password can be used to log in to VCPT.)

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

---

Restarting the System and Verifying System, VCPT, and VQE Client Channel Configuration Delivery Server Status

To restart the Cisco CDE110 and verify system, VCPT, and VQE Client Channel Configuration Delivery Server status, follow these steps:

---

Note The output for the commands issued in this section has been omitted. For example output, see the previous sections in this chapter where the same commands were issued.

---

---

Step 1 To restart the system, issue the following command:

[root@system]# init 6 

The operating system boots.

Step 2 Log in as root.

Step 3 To verify that interface eth1 is up and running and the IP address and netmask is set correctly, issue the following command:

[root@system]# ifconfig -a 

... Output omitted 

Step 4 If you have configured Quagga, to verify that the Quagga processes are running, issue the following commands:

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

... Output omitted 

Step 5 To verify that the sshd process is running, issue the following command:

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

... Output omitted 

Step 6 To verify that the httpd process is running, issue the following command:

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

... Output omitted 

Step 7 To verify that the tomcat5 process is running, issue the following command:

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

... Output omitted 

Step 8 To verify that the snmpd process is running, issue the following command:

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

... Output omitted 

Step 9 To verify that the snmpsa process is running, issue the following command:

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

... Output omitted 

Step 10 To check that the VQE Client Channel Configuration Delivery Server (VCDS) process is running, issue the following command:

[root@system]# ps -ef | grep -i VCDS 

... Output omitted 

Step 11 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 12 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.

---