Appendix A, Alert Messages

This appendix identifies all alert and error messages that Broadband Access Center for Cable (BACC) generates.

Alert Messages

BACC generates alerts through the UNIX syslog service. Syslog is a client-server protocol that manages the logging of information on UNIX. BACC syslog alerts are not a logging service. They provide a notification that a problem exists, but do not necessarily define the specific cause of the problem. This information might be found in the appropriate BACC log files.

Message Format

•

#—Identifies the severity level in use. There are three levels of alerts: 1, which is alert, 3 which is error, and 6 which identifies informational messages.

•

###—Identifies the numeric error code as described in the following sections.

RDU Alerts

Whenever an RDU syslog alert is sent, additional details (if any) can be found in log file <BACC_DATA>/rdu/logs/rdu.log. Table A-1 identifies the RDU alerts.

Table A-1 RDU Alerts
Alert	Description
RDU-1-101: RDU ran out of disk space	This alert indicates that the hard drive partition used by the RDU server has run out of space. You can remove or compress some of the log files. See Chapter 12, "Broadband Access Center for Cable Support Tools and Advanced Concepts," for additional information on upgrading the disk.
RDU-1-103: RDU ran out of memory	This alert tells you that the RDU has run out of memory.
RDU-1-111: Evaluation key for technology [<technology_name>] expired	This alert appears whenever an evaluation key for the technology specified expires. You must contact Cisco sales or TAC for a new license key.
RDU-1-115: You have used [<percent>]% of available [<technology_name>] licenses.	This alert identifies the quantity of licences used (in percentage) out of the total number of allowable licenses. This alert starts to appear when you reach 80% of the license capacity.
BPR-RDU-4-1140: DNS took [X] seconds for lookup of address [10.0.0.1/test.com]; Check DNS configuration and health of servers	This alert is used to indicate that BACC performance is slowing down. The alert is generated whenever IP Address loop up takes more than 60 seconds.

Solaris DPE Alerts

Whenever a DPE syslog alert is sent, you can find additional details in the DPE logs.

You can use the show log command to access the DPE logs. See Cisco Broadband Access Center for Cable Command Line Reference for additional information.

Some DPE errors are also propagated to the RDU server log files. You can find these in the <BACC_DATA>/rdu/logs/rdu.log file. Table A-2 identifies the Solaris DPE alerts.

Table A-2 DPE Alerts
Alert	Description
DPE-1-102: DPE ran out of disk space	This alert notifies you that the DPE hard drive is full. There are three different actions you can perform: a. Clear out any excess support bundles that may reside on the disk. You can do this by moving those support bundles to another machine and then running the clear bundles command from the DPE CLI. b. Run the clear logs command from the DPE CLI, to clear more disk space. c. As a last resort, run the clear cache command from the DPE CLI. This will remove any cache files and force the DPE to resynchronize with the RDU server.
DPE-1-104: DPE ran out of memory	This alarm indicates that the DPE process has run out of memory. Determine how many device configurations are on the DPE; the more device configurations that exist, the more memory is used. The way to reduce device configurations is to limit the number of provisioning groups, either primary or secondary, that the DPE serves.
DPE-1-109: Failed to connect to RDU	This alert indicates that the RDU cannot be contacted. You must: a. Verify that the DPE network is configured and connected correctly. b. Check that the DPE is configured to connect to the proper RDU, and that the connecting port is configured properly, using the dpe rdu-server command. c. Check that the RDU process is running on the correct server and listening on the correct port. The DPE attempts to reconnect to the RDU process every few seconds until a connection is established.

Agent Alerts

Whenever a syslog alert is sent by the watchdog agent process, you can find error details (if any) in the <BACC_DATA>/agent/logs/ agent_console.log file and the log files corresponding to the specific component mentioned in the alert (if any). For example, if you receive an alert similar to The [rdu] unexpectedly terminated, you would check the RDU server log file (<BACC_DATA>/rdu/logs/rdu.log) for additional information. Table A-3 identifies the agent alerts.

Table A-3 Agent Alerts
Alert	Description
AGENT-3-9001: Failed to start the [<component>]	This alert indicates that the process has failed to start the specified component.
AGENT-3-9002: The [<component>] unexpectedly terminated	This alert indicates that the specified component, monitored by the agent process, has unexpectedly failed.
AGENT-3-9003: Failed to stop the [<component>]	This alert indicates that a component did not stop when the agent attempted to stop it gracefully.
AGENT-6-9004: The [<component>] has started	This alert is generated any time a component is successfully started by the agent.
AGENT-6-9005: The [<component>] has stopped	This alert is generated any time a component has been successfully stopped through the watchdog agent. This message is for informational purposes only.

The [<component>] variable presented in the agent alerts list shown in Table A-3 represents any of these component values:

Network Registrar Extension Point Alerts

Whenever a BAC Network Registrar extension point syslog alert is sent, you can find additional details in the Network Registrars log file.

Table A-4 Network Registrar Extension Point Alerts
Alert	Description
NR_EP-1-106: Failed to connect to RDU	This alert notifies you that the Network Registrar server cannot connect to the RDU. You should verify that the RDU process is running and, if it is not already running, start the RDU. If the RDU is running, use the Network Registrar computer to ping the RDU. If you are unable to ping the RDU, fix the routing tables or other communication parameters, between the two devices. If this alert is frequently repeated, you may have an unstable connection between the two hosts. Use generally accepted network troubleshooting techniques to improve the connectivity between the two hosts.
NR_EP-1-107: Failed to connect to any DPEs	This alert notifies you that the Network Registrar extension cannot connect to the DPEs. Check that there are DPEs in the provisioning group for each Network Registrar extension. If not, change the Network Registrar provisioning group to one that has DPEs available. If DPEs are in the provisioning group, ensure that the Network Registrar extension has registered with the RDU, if it has not, it will not recognize any of the DPEs. If, after completing the check, the alert continues, check that there is network connectivity between the Network Registrar extension and the DPEs in the provisioning group. If this alert is frequently repeated, you may have an unstable connection between the two hosts. Use generally accepted network troubleshooting techniques to improve the connectivity between the two hosts.
NR_EP-6-108: The BACC NR extensions have started	This alert notifies you that the Network Registrar extensions have been started.
NR_EP-6-109: The BACC NR extensions have stopped	This alert notifies you that the Network Registrar extensions have been stopped.
NR_EP-6-110: Registered with RDU [address and port]	This alert notifies you that the Network Registrar extensions have been registered with the RDU. The [address and port] identifies the address of the RDU that has registered the Network Registrar extensions.

RDU Error Messages with CCM

The RDU error messages described in this section are accompanied by corrective actions that you perform to remedy specified problems. These error messages are located in the rdu.log file, and are a direct result of the Lease Reservation feature and consequently, if you are not using the Network Registrar Regional CCM feature these error messages should not appear.

BACC 2.7 generates three types of lease reservation related error messages, including:

•

Failure to add a reservation request failure. These messages are preceded by the following information which identifies several aspects of the error:

•

Failure to remove a reservation request failure. These messages are preceded by the following information which identifies several aspects of the error:

•

Selection-criteria exclusion tag errors. These messages are preceded by the following information which identifies several aspects of the error:

•

2005 02 09 13:25:11 EST:—Identifies the date and time that the error took place.

•

%BPR-RDU-#-####:—Identifies the RDU error number (#) and error message ID (####).

•

1,6,03:03:14:00:00:21]—Identifies the MAC address that is attempting to reserve an IP address. Note that the second example illustrates BACC's support of variable length MAC addresses.

Each of these examples contain a generalized description of the error as well as additional the error message that is returned from Network Registrar.

[OBJECT_EXISTS]

A user is trying to make reservation [11.100.14.21] for mac [1,6,03:03:14:00:00:21], but the reservation request failed due to duplicate ip used (ip already being reserved by another device in the database).

[RemoveReservation: NOT_FOUND]

A user is trying to remove a reservation [11.100.0.103] for mac device [1,1,35]; the request failed due to non-existence reservation in CCM database. In other words, CCM can't find the reservation exist in the database.

[AddReservation: INVALID_PARENT]

This means that CCM did not find any scope for the IP address of the reservation. CCM local has to find a scope that could contain the reservation. CCM displays this error message when reserved IP is out of scope. You will get this error message if you try to add a reservation to a nonexisting subnet or scope.

[AddReservation: INVALID_SECOND_PARENT]

This should only be returned by a local CCM. It means that no scope exist in the configuration could contain the reservation. Recheck your DHCP server configuration (scope, subnet, and so on).

You will get this error if you try to add a reservation to subnet that exists at the Regional cluster but no such scope/subnet exists at the local cluster(s):

Or CCM can't find a scope that both contains the reserved IP address and match clientclass/selection-tags criteria.

Recheck your DHCP server configuration (scope, subnet, clientclass, selection-tags, and so on).

[AddReservation: FORWARD_FAILED]

CCM regional was not able to forward the reservation request to any local CCM. This happens when the CCM can't find a scope that both contains the reserved IP address and match clientclass/selection-tags criteria.

The following two use cases illustrate solutions to potential causes of this error:

Example Case #1

Assume that there are three scopes with these attributes/tags; scope A is red and gray, scope B is blue and red, and scope C is blue and green. If the AddReservation API call specifies the inclusion of red and gray tags, but the scope that contains the IP address requested is scope B.

The outcome of this situation is that the reservation request fails and this error is logged into the rdu.log file.

Use the same setup or configuration, but modify the AddReservation API call to specify the inclusion only red tags, rather than red and gray as described above. This should be successful and any scope that contains the IP address, and matches all of the selection tags, will be used.

Note In this example, it is expected that the device gets the reservation from scope B.

Example Case #2

Assume that there are three scopes with these attributes/tags; scope A is red, scope B is blue, and scope C is green. Also assume that the AddReservation API call specifies a client class of test1, Network Registrar defines test1 with the green selection criteria, and the IP being requested is contained in the scope B.

The outcome of this situation is that the reservation request fails and this error is logged into the rdu.log file.

Use the same setup or configuration, but reconfigure the test1 clientclass in Network Registrar with selection criteria blue. This should successfully correct the problem so that any scope containing IP address, and matching all of the selection tags, is used.

[AddReservation: AX_ETIME]

This indicates that a reservation request timeout has occurred. This could be due to the CCM being overloaded, or busy with tasks and requests, and was not able process the reservation request.

Use the administrator's user interface to configure a longer timeout value. See the "RDU Defaults" section on page 10-19 for information on submitting reservation requests.

[AddReservation: INVALID_OBJECT]

The reservation itself was invalid somehow: the MAC address was invalid, the IP address was missing, or it supplied an invalid client-class name or selection tags.

Check the reservation requests: the MAC address, IP address, client-class, selection tags, etc.

Selection-criteria exclusion tags will be ignored

The use of selection-criteria exclusion tags [black] is not allowed when adding a lease reservation. They will be ignored.

You should not configure selection-criteria exclusion tags in the DHCPCriteria since the use of selection-criteria exclusion tags is not allowed.

[AX_EIO]

This indicates that the connection, or session, session between the RDU and the CCM is broken.

There is no user interaction required when this error occurs. The RDU will automatically establish another connection to CCM.

[AX_EPIPE]