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 6.1.3 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 6.1.3 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 6.1.3 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.
|