- Preface
- Product Overview
- Network Design
- Getting Started
- Configuring Devices
- Configuring Services
- Configuring the System
- Monitoring the Internet Streamer CDS
- Maintaining the Internet Streamer CDS
- Troubleshooting
- Creating Manifest Files
- Creating Coverage Zone Files
- Creating Authorization Service Files
- Creating CDN Selector Files
- Creating Service Rule Files
- Creating NAS Files
- URL Signing and Validation
- CLI Commands
- Verifying the Internet Streamer CDS
- Software Licensing Information
Cisco Internet Streamer CDS 2.6 Software Configuration Guide
- Updated:
- May 29, 2014
Chapter: Troubleshooting
Troubleshooting
This appendix provides information on troubleshooting. The following topics are covered in this appendix:
- Troubleshooting Service Router Configurations
- Troubleshooting the Distribution Hierarchy
- Troubleshooting Content Acquisition
- Enabling the Kernel Debugger
- Troubleshooting Web Engine Cache Status Codes
For more troubleshooting tools, see Chapter7, “Monitoring the Internet Streamer CDS”
Troubleshooting Service Router Configurations
Because there are many steps required for the Service Router to redirect the request properly, you might see some content request errors from the Service Router when the configuration is not quite complete. Here are some areas to look at when troubleshooting:
–
Is the requested domain delegated to the Service Router on the DNS server that is authoritative for the parent domains? The Service Router’s DNS name should be forward resolvable. Check with the system administrator to delegate a domain.
– Is the Service Router activated? See the “Activating a Service Router” section to activate a Service Router.
– Is a default coverage zone set for a Service Engine, or is there a CDS network-wide Coverage Zone file or a local Coverage Zone file set for the Service Router? See the “Coverage Zone File Registration” section to set a Coverage Zone file. See the “Configuring the Service Engine” section to set a default coverage zone.
– Is the content request from an end system covered by a Service Engine in a coverage zone based on the default coverage zone or the Coverage Zone file? This Service Engine is the “serving Service Engine.” See the “Coverage Zone File” section for information on coverage zones. See
Appendix C, “Creating Coverage Zone Files,”
for information on creating a Coverage Zone file.
– Is the serving Service Engine activated? See the “Activating a Service Engine” section to activate a Service Engine.
– Is there a delivery service created for the requested domain and a serving Service Engine assigned to this delivery service? See the “Creating Delivery Service” section.
– Is the serving Service Engine alive? Use the
show statistics service-routing se
command to show the status of a Service Engine. See the “Using show and clear Commands” section.
– Is a Manifest file assigned to the delivery service associated with the serving Service Engine? See the “Working with Manifest Files” section.
– Is the Manifest file accessible from the CDSM? See the “Identifying Content Using a Manifest File” section.
– Is there any syntax error in the Manifest file? See the “Manifest File Structure and Syntax” section.
– Is the requested content specified in the Manifest file? See the “Specifying a Single Content Item” section.
– If the requested content is streaming media, is the protocol engine enabled? See the “Application Control” section.
For general information, use the show statistics service-router all command.
Troubleshooting the Distribution Hierarchy
Because distribution-related problems are design-dependent, your initial strategy is to discover whether or not the correct Service Engine is sending content in the correct distribution path.
- To determine which Service Engines are in the distribution path of a particular Service Engine, use the show distribution remote traceroute EXEC command, as shown in the following example:
Troubleshooting Content Acquisition
To monitor acquisition progress and to troubleshoot, use the following commands from the Content Acquirer CLI:
- Use the show acquirer delivery-services EXEC command to obtain delivery service information, such as the delivery service ID and delivery service name, that you need to enter in other show acquirer commands, such as the show acquirer progress command. In the following example, the delivery service ID is 793 and the delivery service name is group01-cifs.
- Use the show acquirer EXEC command to make sure that the acquirer process on the Content Acquirer is working correctly, and that the device is using the expected amount of bandwidth for acquisition. The following example shows that the acquirer is running properly and that the device is configured with unlimited bandwidth for acquisition of content.
- Use the show acquirer progress EXEC command to check how far the acquisition of content has progressed. A specific delivery service ID or delivery service name can be specified to obtain the progress for a specific delivery service. In the following example, the acquirer has already acquired 2237 items.
- Use the show statistics acquirer delivery-service-id or show statistics acquirer delivery-service-name EXEC command to obtain the detailed acquisition statistics for a given delivery service. In the following example, there was an error acquiring two items.
- Use the show statistics acquirer errors delivery-service-id or show statistics acquirer errors delivery-service-name EXEC command to see the reasons why the errors occurred. In the following example, one error occurred because there was a problem acquiring the URL. The other error occurred because the disk quota for the delivery service configured in the Content Distribution Manager GUI would have been exceeded if the specified URL had been acquired. You can increase the delivery service disk quota to correct this error.
- If more detailed troubleshooting of content acquisition is required, you can increase the debug level of the acquirer using the debug acquirer trace EXEC command. The logs are written to local1/errorlog/acquirer-errorlog.current.
- To verify that an expected object has been pre-positioned on the Service Engine, use the show distribution object-status EXEC command, as shown in the following example:
Internal File Name: /disk00-04/d/http-172.18.81.168-k5bsm1o+y14jgiqsvwaohq/19/19f6d5cec7266c33f419709dc28c8d9b.0.data.wmv
Internal File Name: /disk00-04/d/http-172.18.81.168-k5bsm1o+y14jgiqsvwaohq/19/19f6d5cec7266c33f419709dc28c8d9b.0.data.wmv
Internal path to data file: /disk00-04/d/http-172.18.81.168-k5bsm1o+y14jgiqsvwaohq/19/19f6d5cec7266c33f419709dc28c8d9b.0.data.wmv
By comparing fields, such as Total Size, Transferred Size, and Source URL in the Object Replication output and Actual File Size and Source URL in the Source-URL to CDN-Object Mapping output, you can determine whether or not the object that is stored is the same as the object that was requested.
Enabling the Kernel Debugger
Cisco CDS software allows you to enable or disable access to the kernel debugger from the CDSM. Once enabled, the kernel debugger is automatically activated when kernel problems occur.
Note The “hardware watchdog” is enabled by default and automatically reboots a device that has stopped responding for over ten minutes. Enabling the kernel debugger disables the “hardware watchdog.”
If the device runs out of memory and kernel debugger (KDB) is enabled, the KDB is activated and dump information. If the KDB is disabled and the device runs out of memory, the syslog reports only dump information and reboots the device.
To enable the kernel debugger, do the following:
Choose
Devices > Devices
>
General Settings > Troubleshooting > Kernel Debugger
. The Kernel Debugger page is displayed.
Step 2 To enable the kernel debugger, check the
Enable
check box, and click
Submit
.
Troubleshooting Web Engine Cache Status Codes
Generally speaking, a TCP_MISS/504 status code can occur in a multi-tier system at two places:
Normally, the verification of a 504 status code is a bottom up procedure; that is, start from the edge SE and end at the Origin Server. Following is an example of the bottom-up checking procedure for a 504 status code in a three-tiered system:
1.
If a 504 status code is observed on the edge SE, then the transaction logs on the middle SE should be checked to see what the status code is for that request.
2. If the status code on the middle SE is also 504, then check the transaction logs on the Content Acquirer to see what the status code of that request is:
a. If the status code on the Content Acquirer is also 504, it means the Origin Server is taking too much time to respond and the Content Acquirer timeout period expires. Check the Origin Server to see why it is not responding in a timely manner.
b. If the status code on the Content Acquirer is not 504 (for example, it is 200), it means the Origin Server is responding to the Content Acquirer quickly enough; however, the Content Acquirer somehow takes too much time to respond to the middle SE. If this is the case, investigate why the Content Acquirer is busy.
3. If the status code on the middle SE is not 504, similar to the Content Acquirer case mentioned above, it means the Content Acquirer is responding to the middle SE quickly enough (the transaction logs on the Content Acquirer should confirm this); however, the middle SE somehow take too much time to respond the edge SE. If this is the case, investigate why the middle SE is busy.
Basically, a 504 status code is normally caused by the upstream device taking too much time to respond to the downstream device. This troubleshooting section only covers the investigation of the upstream SEs. A 504 status code can occur on the upstream SE for the following reasons:
- Network-related issues between the downstream device and upstream device
- Issues inside the upstream SEs
- Configuration related issue
Table A-1 provides more information about the scenarios where the 504 status code was observed, the tools used to investigate the scenarios, and the investigation results of each one.
Feedback