%SYS-4-CONFIG_RESOLVE_FAILURE

Ever had recurring messages appearing on the console that look like this?

*Mar  1 03:27:27.119: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/network-confg) failed
%Error opening tftp://255.255.255.255/cisconet.cfg (Timed out)

It means that service config is enabled for the router; it is trying to download the config for the router via tftp. To resolve this issue and to stop the error messages from appearing, you need to issue the following command in global configuration mode:

no service config

IP Phones with status “DeviceInitiatedReset”

If your phones show “DeviceInitiatedReset” as StatusReason in the Real Time Monitoring Tool you might experience connetivity issues between the affected phone and the Callmanager(s).

As per the Cisco documentation:

Note: DeviceInitiatedReset usually happens when there is a connectivity problem on your network between the devices and the Cisco CallManager servers or when the Cisco CallManager server is too busy to reply to keepalives. In both cases, the problem is due to missed keepalives between the devices and the Cisco CallManager servers. Restart the CTI manager; restart the Cisco CallManager cluster, and monitor and capture sniffer traces between the devices and the Cisco CallManager.

TFTP Download From Rommon

It is possible to start a TFTP download while in Rommon mode. You will need to fill some variables before you issue the tftpdnld command:

rommon 1 > IP_ADDRESS=192.168.0.156
rommon 2 > IP_SUBNET_MASK=255.255.255.0
rommon 3 > DEFAULT_GATEWAY=192.168.0.1
rommon 4 > TFTP_SERVER=192.168.0.1
rommon 5 > TFTP_FILE=c2800nm-ipvoicek9-mz.123-15.T2.bin
rommon 6 > tftpdnld

Broken UCCE database replication

If you have deployed a HDS server to query historical data then data is being replicated between the Logger and HDS servers. This replication might fail if the recovery keys are not matching beteween the Logger and HDS. It is known to happen when you run setup on the HDS and change the site it was pointing to, or when the Recovery table is altered or truncated in some way.

To check whether data is still being replicated, execute the following query on the HDS database:

SELECT max(DateTime) AS EXPR1
FROM t_Termination_Call_Detail

In order to resolve the broken replication issue perform the following tasks out of business hours:

Stop the Logger and HDS services.
Run the following query on HDS database where replication is failing: “Truncate table Recovery”.
Start the Logger and HDS services. New recovery keys are created and the replication process wil start again.

If you have tracing enabled, you’d see a fair amount of messages in the “LoggerA/B replication” window when logged on to the Logger server. You can use the first check mentioned above to see whether the replication is up and running again.

Forwarding incoming calls to external destinations on CME

The other day I was working on a setup that would forward an incoming call to an external destination using an ISDN BRI interface. This would come in handy if nobody’s at the office, but you don’t want to miss calls placed to the main number. Time and again my attempts were failing with:

Cause i = 0×82E46C – Invalid information element contents

Searching the Internets for this cause code didn’t yield many results, but I did find some documentation on the Cisco website: Call Forward from CallManager Express to an External Number Fails. CME might also use the original calling number for the inbound call as the calling number for the outbound call leg. To prevent this from happening, you can use outgoing translation rules. A likely indication that this might work for you would be:

Cause i = 0×829C – Invalid number format(incomplete number) 

This didn’t solve my problem. In the end it turned out to be the numbering plan type as somebody pointed out. I configured the following, which made it work:

interface bri 0/0
 isdn map address . plan unknown type unknown
!