This document presents information about Cisco Unity Express (CUE) to help troubleshoot and fix the most commonly encountered problems. The objective is to prevent unnecessary replacements of the CUE module due to these problems.
Problem - Communication Fails
Basic IP communication between the host router and the CUE module fails even after proper configuration of the host router.
In order to identify the problem, look for waiting events such as these, shown in an extract of the installation output:
==> only eth0 exists, we must be running on an AIM ==> only eth0 exists, we must be running on an AIM Router communications servers initializing...
The CUE awaits commands from the Cisco IOS® router in order to configure its IP address and default gateway parameters so that it can communicate with the rest of the network. However, it does not receive any response from the router. The process where you configure the CUE module through the host Cisco IOS router uses Router Blade Control Protocol (RBCP). There might be some situations in which the network administrator is required to troubleshoot this protocol exchange between the host router and CUE.
When the CUE successfully communicates with the router with the use of RBCP and receives its IP parameters, this message is shown on the CUE console during the application bootup:
Router communications servers initializing...complete. IOS IP Address Registration complete.
Problem - No Session
You are unable to open a session to the CUE module or you do not see any output on the console.
You can use this command in order to check the console messages on the CUE module without the need to open a session to it:
Router# test service-module service-engine slot/unit console
By default, this command displays the most recent 80 lines stored in the console buffer. However, it is possible to specify an offset of greater or less than 80, or to view all the messages stored in the console buffer with this command:
Router# test service-module service-Engine slot/unit console ? <1-20456> Offset into console buffer all Entire console buffer
Problem - RBCP Error Messages
RBCP error messages are seen on the CUE console or the module intermittently shuts down. Here are some examples of the errors:
rbcp: INFO rbcp register output Error in opening the file /usr/trace/trace.tcmd: Permission denied
localhost rbcpd: ERROR rbcp.daemon protocol handler Could not determine disk capacity
You can use this test command in order to check the RBCP status on the CUE module from the router:
Router# test scp ping slot
This command sends a ping to the CUE module as an RBCP message with the use of operational code (opcode) 0x11. If the RBCP process on the CUE module is up and running, the ping succeeds and the output of the test command looks like this.
Router# test scp ping 3 pinging addr 3(0x3) assigned sap 0x4 addr 3(0x3) is alive
One situation wherein the network administrator must troubleshoot the RBCP messages between the CUE module and the router is when the interface configuration has been verified, but you still cannot ping the CUE module. First, check the status of the interface and ensure that the interface and line protocol are up, as shown in this example.
Router# show interfaces service-engine 1/0 Service-Engine1/0 is up, line protocol is up Hardware is I82559FE, address is 0003.b912.xxxx (cia 0001.b912.xxxx) Interface is unnumbered. Using address of FastEthernet0/0 (a.3.6.29)
Next, verify the RBCP state machine status on the router, as shown in this example. The CUE module must be in a steady state for proper operation.
Router# service-module service-Engine 1/0 status Service Module is Cisco Service-Engine1/0 Service Module supports session via TTY line 33 Service Module is in Steady state cisco service engine 1.0
If you are still unable to ping the CUE module IP address, troubleshoot the RBCP messages exchanged between the CUE module and the host router. You will see Switch Communication Protocol (SCP) messages. scp-tx indicate messages that the router transmits to the CUE module whereas scp-rx indicates messages that the CUE transmits to the router. You can use these two tables in order to decode the values.
Flags for the scp-tx RBCP Message:
Flags for the scp-rx RBCP Message:
The output of debug scp all is shown in this example. An IP address (184.108.40.206 255.255.255.224) is configured on the Ethernet interface of the Cisco Unity Express module.
The output shows that the scp-tx message transmitted has the Source Address (SA) field set to 0F/01, which indicates that the message originated from the router. The Destination Address (DA) field is set to 01/01, which indicates that the CUE module is present in slot 1. The opcode of 0054 indicates that this is an IP address configuration. The sequence number (Sq) field is 0B26, and the length of the payload is 10 bytes.
The first parameter on the second line is the type, and the second parameter is the action. In the message, the type is 01 and the action is 01, which indicates that the CUE module interface is being configured. The next eight bytes are the IP address and subnet mask.
In the output shown for the scp-rx message, the SA field is set to 0E/01, which indicates that it originated from the CUE module in slot 1. The DA field is set to 0F/01, which indicates that the message is destined for the router. The Opcode and Sq fields are the same as in the scp-tx message. The Type field in the second line is set to 02, which means that the CUE module IP address was set properly. The rest of the parameters have no significance.
This example shows the Cisco Unity Express module's default-gateway parameter being set.
The debug output of the scp-tx message shows that the opcode is different. The value 0059 indicates that this message pertains to the IP default-gateway configuration parameter. The length of the payload is 5 bytes. The payload is shorter than the scp-tx message shown in previous example debug scp all output (5 bytes versus 10 bytes), because no subnet mask is associated with the default gateway IP address. The action flag is set to 01, which indicates that the default gateway is being configured. In the output of scp-rx message, the action flag is set to 00, which confirms that the configuration of the IP default gateway address was successful.
Problem - Software Installation
When you install a CUE module, problems might occur in the software package download. These problems might be caused by network connectivity or even issues with the software package. This section describes some common problems that might occur during software installation of CUE and ways to troubleshoot them.
Network Connectivity Issues
If the CUE module is unable to establish contact with the FTP server where the software load resides, the error shown in this example occurs when you attempt to install the software.
CUEinstaller#> software install package url ftp://username:password@ 220.127.116.11/cue-vm.18.104.22.168.pkg RAMDisk mounted Connecting to host... curl: (7) Connect failed ERROR: Host did not respond. Please check the host ip and try again. RAMDisk unmounted
First, ensure that the IP address of the FTP server is correct. Verify all the parameters given in the install command. Once you confirm all of these are correct, verify the IP connectivity from the CUE module to the router. Reboot the CUE module, as shown in this example, and press *** at the first prompt. This action takes you to the bootloader prompt.
CUEinstaller#> reboot WARNING: This will reboot the Service Engine! Do you wish to continue (y,n) [n] y
The bootloader has a ping command, as shown here:
ServicesEngine boot-loader> ping 22.214.171.124 Sending 5, 32 byte ICMP Echos to 126.96.36.199: ..... Success rate is 0% (0/5) ServicesEngine boot-loader> ping 188.8.131.52 Sending 5, 32 byte ICMP Echos to 184.108.40.206: !!!!! Success rate is 100% (5/5)
If the CUE system cannot ping the FTP server, you might have the wrong configuration of IP parameters in the bootloader. This example shows how to check the bootloader configuration. If you see anything wrong, you can use the bootloader config command in order to make modifications.
ServicesEngine boot-loader> show config IP addr: 220.127.116.11 Netmask: 255.255.255.224 TFTP server: 18.104.22.168 GW IP addr: 22.214.171.124 Default boot: disk Bootloader Version: 1.0.17 Default Helper-file: cue-installer.1.1.1 Default BIOS: primary Default bootloader: primary Default cpu throttle: 50%
Another reason why the ping command might not be successful is the routing configuration on the Cisco IOS router. With an ip unnumbered configuration for the service-engine interface, you can verify the routing as follows:
Ping the FTP host from the Cisco IOS router in order to ensure that the host can be reached. If this fails, examine the Cisco IOS routing configuration.
If the FTP host can be reached from the router, verify the Cisco Unity Express module connectivity with the show ip route command.
Router# show ip route
When the show ip route command is executed, a host route similar to the one described in this example displays (where 126.96.36.199 is the IP address of your CUE module and Service-Engine1/0 is the CUE module seated in NM slot 1 of the router). If such a route does not appear in your routing table, use this command in order to add it: