The KDC does not start. |
The KDC certificate does not correspond to the private key. |
Ensure that you have matching certificates and private key. |
The KDC license expired or is missing. |
Restore KDC license to
BPR_HOME/kdc directory. |
The MTA device does not appear in the Prime Cable Provisioning Devices page. |
An incorrect cable helper address may have been configured. |
Fix the helper address. |
The scope-selection tags do not match the DHCP Criteria selected in the Prime Cable Provisioning Admin UI. |
Verify that the MTA scope-selection tags match those in the PacketCable DHCP Criteria created, in Prime Cable Provisioning, for the relevant MTAs. |
The Network Registrar extension point is not properly installed. |
Reinstall the Network Registrar extension point. See the Cisco Prime Cable Provisioning 5.1 Quick Start Guide. |
The cable modem portion did not receive Option 122. |
Verify that the tags on the scope of the cable modem portion match the DOCSIS DHCP Criteria configured for Prime Cable Provisioning. |
The MTA device does not accept the DHCP offer and continually cycles through the DHCP flow. |
There are invalid DHCP options configured. |
Check that scope policy includes the DNS server option, and/or check that the
cnr_ep.properties file includes entries for primary and secondary DNS servers. |
The DHCP offer may have come from a DHCP server different from the one indicated in the cable modem portion’s Option 122 suboption 1. |
Check the
cnr_ep.properties file to ensure that the main and backup DHCP servers are set correctly. |
Both the
kdc.log file and the ethereal trace indicate that the MTA device never contacts the KDC. |
An incorrect DNS server is specified in the
cnr_ep.properties file or the MTA scope policy, or both. |
Check or correct
cnr_ep.properties DNS servers. |
A zone is missing or has been incorrectly set up for the Kerberos realm. |
Make sure a zone with same name as realm is created and contains an ‘SRV’ record of format ‘_kerberos._udp 0 0 88
KDC FQDN’. |
There is a missing or incorrect KDC ‘A’ record entry. |
Ensure that an ‘A’ record exists for the FQDN contained in the Kerberos zone’s ‘SRV’ record. |
The DPE FQDN cannot be resolved. |
Ensure that the provFQDNs entry in
dpe.properties has the correct FQDN and IP of the DPE. |
The KDC reports failure during the Kerberos AS-Request. |
The MTA certificate does not match the MTA root used by KDC. |
Verify that the
MTA_Root.cer is correct by comparing the
MTA_Root.cer against that used on a working system.
If it is correct, the MTA itself could have a certificate problem. This situation is extremely rare and if this is the case, contact the MTA manufacturer. |
FQDN lookup by KDC to Prov Server failed. The device may not yet be provisioned in Prime Cable Provisioning. |
Verify that the device appears. It should be given both a Class of Service and a DHCP Criteria. |
A clock skew error. See PacketCable Workflows, for additional information. |
Ensure that all Prime Cable Provisioning network elements are clock-synced via NTP. See the Cisco Prime Cable Provisioning 5.1 DPE CLI Reference Guide. |
A mismatch may exist between the KDC and the DPE.
Note |
If other devices are provisioned correctly, this is probably not the cause of the problem. |
|
Check that these three entries exist in the
BPR_HOME/kdc/<Operating System>/keys directory:
-
mtafqdnmap,dpe.abc.com@DEF.COM
-
mtaprovsrvr,dpe.abc.com@DEF.COM
-
krbtgt,DEF.COM@DEF.COM
The DPE FQDN and realm name on your system will be different from this example. Contents of these entries must match the entry in either the dpe.properties ‘KDCServiceKey’ entry, or the keys generated using the KeyGen utility. |
The KDC reports success at the AS-Request/Reply (steps 9 and 10 in shown in Figure 1), but the MTA device never moves past step 9. |
There is a certificate mismatch between the telephony root loaded or enabled on the MTA, and that loaded on the KDC. |
Check certificates on MTA and KDC. |
Although highly unlikely, it is possible that there is a corrupted telephony certificate chain.
Note |
If other devices are provisioned correctly, this is not the cause of the problem. |
|
Ensure that the correct certificate is loaded or enabled on MTA. If no devices can be provisioned correctly, try a different certificate on the KDC. |
Failure at AP Request/Reply (step 14 in Figure 1). |
A clock skew error. See PacketCable Workflows, for additional information. |
Ensure that all Prime Cable Provisioning network elements are clock-synced via NTP. See the Cisco Prime Cable Provisioning 5.1 DPE CLI Reference Guide. |
Cannot resolve Prov Server FQDN. |
Make sure that the provisioning server (DPE) has a correct DNS entry.?Ensure that dpe.properties provFQDNs entry has the correct FQDN and IP of the provisioning server (DPE). |
There is no route from the MTA to the DPE. |
Correct the routing problem. |
The MTA device never issues a TFTP request for a configuration file. |
There is no route to the TFTP server running on the DPE. |
Correct the routing problem. |
The MTA device never receives the TFTP configuration file. |
The configuration file is not cached at the DPE. |
Wait until the next provisioning attempt, at which time the file should be cached. If this fails, reset the MTA. |
A conflicting TFTP server option is included in the network registrar MTA scope policy. |
Because Prime Cable Provisioning inserts the DPE address for the TFTP server, you can safely remove this option from the policy. |
The MTA device receives a configuration file, but the DPE fails to receive the SNMP Inform (step 25 in Figure 1) as seen in the
dpe.log file. |
One of:
-
An internal conflict in the configuration file.
-
A conflict with Realm origin of the telephony certificate chain.
-
A conflict with the Realm Name provided in Option 122.
|
Ensure that the MTA configuration file is consistent. |
The MTA device reports success (step 25 in Figure 1) although an RSIP is not sent. |
The MTA cannot resolve the IP address of the CMS FQDN given in the MTA configuration file. |
Verify that a DNS entry exists for the CMS. |
The MTA cannot reach the IP address(es) of the CMS. This is an indication that no route is configured. |
Resolve all routing problems. |
The MTA device reports success (step 25 in Figure 1), although it proceeds to contact the KDC again for CMS service. |
The MTA configuration file points to an incorrect cable modem. |
Correct the configuration file, or reconfigure the Cisco BTS 10200 to use the FQDN listed in the configuration file. |
The MTA configuration file has its pktcMtaDevCmsIPsecCtrl value missing, or it is set to 1. This means it will perform secure NCS call signaling, or it will use an ASCII suffix that does not match that of the CMS FQDN. |
Correct the configuration file. If you intend to perform secure signaling, take the necessary steps to configure the KDC and the BTS for support. |
The MTA device reports success (step 25 in Figure 1), RSIPs, but gets no response or gets an error in response from the soft switch. |
The MTA is unprovisioned or has been incorrectly provisioned on the Cisco BTS 10200. |
Provision MTA on the Cisco BTS 10200. |
An eMTA DNS entry does not exist. |
Place an entry in the correct DNS zone for the eMTA. Dynamic DNS is the preferred method. See Cisco Prime Network Registrar documentation for information on enabling DDNS. |