Description: The "change property" API don't allow you to delete a property and add it back in the same call. This is because the commands do the adds then the deletes. It should be the other way around.
Workaround: Delete and add the property using separate API calls.
Description
The bprAgent fails to stop gracefully on multi-cpu machines:
bacdev3-rdu-2:/# /etc/init.d/bprAgent stop Stopping process [jrun] has an error. ERROR: BPR Agent failed to exit after 90 seconds, killing processes. BPR Agent is stopped.
The following line needs to be in the $BPR_HOME/cnr_ep/conf/cnr_ep.properties file. /cnrExtension/attributesToValidateOnBroadcast=relay-agent-remote-id
Description
Under heavy load the RDU will drop batch submission messages coming from the API client without informing the client. This causes the client to wait forever for the batch to finish if the application did not specify a timeout.
Symptom: The Servers > RDU > View Regional Distribution Unit page on the administrator user interface may display a negative value for Average Processing Time under PACE Statistics. For example a value of -9223372036854775808 ms for the "Average Processing Time" under the "PACE Statistics" heading has been observed by a customer. Conditions: A possible trigger for this bug is the system admin making a clock change. Workaround: Reloading the RDU will resolve the condition
Incorporate provisioning groups in the BACC template property hierarchy.
Upgraded the AdventNet SNMP to APIv4 for 2.7.1
A new property is added to the system that defaults the commands to 100 batches per command. The property is made configurable.
Symptom:
DPE crashes due to UnexpectedInternalException: "A problem was encountered
when trying to de-serialize an object" when attempting to service a TFTP
request for a dynamic configuration file (template-based configuration).
Conditions:
RDU "serialization" debug/trace category is enabled using the RDU
setLogLevel.sh utility. Subsequent configurations generated by RDU to the
DPE will have corrupted serialization format.
Workaround:
Disable RDU "serialization" debug/trace category using the setLogLevel.sh
utility. Force regeneration of configurations either via RDU or via DPE
clear cache.
Symptom:
There is incorrect output from the
name,type,value for the SNMP TLVs. Specifically for this customer this
TLV below in a 2.6 template is generated as:
# (11) SNMP MIB Object
Option 11
.iso.org.dod.internet.private.enterprises.cableLabs.clabProject.clabProj
PacketCable.pktcMtaMib.pktcMtaMibObjects.pktcMtaDevSecurity.pktcMtaDevRe
almTable.pktcMtaDevRealmEntry.pktcMtaDevRealmOrgName.73.80.70.79.78.73.8
8.46.67.79.77,STRING,"Telephone Company"
# Option 11 hex
303E061A2B06010401A30B02020101031001044950464F4E49582E434F4D04205265616C
6C7920416D617A696E672054656C6570686F6E6520436F6D70616E79
But alas in 2.7 the important double quotes (") are missing:
# (11) SNMP MIB Object
Option 11
.iso.org.dod.internet.private.enterprises.cableLabs.clabProject.clabProj
PacketCable.pktcMtaMib.pktcMtaMibObjects.pktcMtaDevSecurity.pktcMtaDevRe
almTable.pktcMtaDevRealmEntry.pktcMtaDevRealmOrgName.73.80.70.79.78.73.8
8.46.67.79.77,STRING,Telephone Company
# Option 11 hex
303E061A2B06010401A30B02020101031001044950464F4E49582E434F4D04205265616C
6C7920416D617A696E672054656C6570686F6E6520436F6D70616E79
Workaround:
The customer has two options:
1. Disable (comment out) the ASCII representation and use (uncomment)
the HEX encoded string in the template, thusly:
# (11) SNMP MIB Object
# Option 11
.iso.org.dod.internet.private.enterprises.cableLabs.clabProject.clabProj
PacketCable.pktcMtaMib.pktcMtaMibObjects.pktcMtaDevSecurity.pktcMtaDevRe
almTable.pktcMtaDevRealmEntry.pktcMtaDevRealmOrgName.73.80.70.79.78.73.8
8.46.67.79.77,STRING,Telephone Company
Option 11 hex
303E061A2B06010401A30B02020101031001044950464F4E49582E434F4D04205265616C
6C7920416D617A696E672054656C6570686F6E6520436F6D70616E79
Or
2. Use a 2.6 RDU and its 'runCfgUtil.sh' to produce the binary file from
a template.
-->
Description
A DOCSIS template file which defines a macro variable that BPR/BACC is unable
to substitute will cause the calculation of the MIC to fail, with a
NullPointerException in the RDU logfile.
Workaround
Ensure that all macro variables are valid.
Description
It is currently not possible to control whether MTA files are encrypted on a
per device or ClassOfService basis, using properties at the RDU.
Workaround
Set this property at each DPE, with the result that all files
handed out by that DPE will follow that DPE setting.
Description
Changes to the NR defaults at the RDU are not dynamically
propagated to the BACC CNR extension points.
It is necessary to restart the CNR server so that the extensions
re-read the defaults from the RDU.
Description
When CRS batches are executing they utilize up to 50% of the RDU PACE
bandwidth, causing client API batches to execute nearly 50% slower.
Workaround
If the impact on API throughput is deemed to be too great, contact the
Deployment Team for information on lowering the priority of CRS batches, which
will cause CRS to take longer but allow more API throughput.
Description
Incorrect spelling of BACC property names may not result in a clear or immediate
error. If provisioning is failing for a device, search the RDU logfiles for
instances of the device MAC address and possible Configuration generation
failure messages for that device. The log message will specify the unknown
property name.
Workaround
See the Administrator Guide for information on tools supplied to assist with
editing of BACC properties files.
Description
The BACC 2.5 API correctly detects an invalid DHCP configuration applied to a
single device.
However, if the same invalid change is applied to a BAC class of service, it triggers the
Configuration Regeneration Service to run in the background. Even tnough there are
errors, the batch is allowed to succeed, because it is impractical to keep the API client
waiting until all configurations are regenerated. Such changes will potentially result in
a large number of configuration generation errors in the rdu.log.
Workaround
Any application using BAC 2.5 should be carefully constructed to avoid assigning invalid
DHCP options to a BAC class of service. An application using BAC 2.5 could be
structured to use naming conventions that reflect the intended technology for the class of
service objects in BAC. It could also perform simple validations to avoid such mistakes
as allowing a PacketCable DHCP option to be applied to a class of service for another technology.
NOTE
Use the Audit Log and the rdu.log to diagnose these errors.
Description
By design, the first TFTP request to a provisioning group for a specific file will
fail since files are only downloaded to DPEs upon request.
Some devices do not attempt to retry to fetch the file again which
requires the device to be re-booted in order to retry the TFTP request.
Workaround
Reboot the device.
Description
Static route information entered into a DPE via the CLI is not displayed when
one issues the 'show running-config' command.
Workaround
Use the show ip route command to show the static route info.
Description
The BAC agent may display incorrect error messages when the KDC starts. The bprAgent is configured to
immediately start the KDC after a successful installation. The KDC will continuously fail to start until it is
configured with a license and valid PacketCable certificates. This information is found in the KDC log file.
If the bprAgent is allowed to continue in this mode of operation, and if the KDC is not configured properly,
the bprAgent will eventually slow the rate of attempts and the agent will go into a sleep mode.
This only happens for a few minutes and, while the bprAgent is in this mode, commands to the bprAgent will generate
the incorrect error messages.
Workaround
Once you have configured the KDC with valid license and PacketCable certificates, the bprAgent will successfully
start the KDC after a few minutes. It is not necessary to issue additional bprAgent commands.
Description
Enabling both DPE interfaces, and subsequently disabling the
primary interface, may cause the DPE to continue to send
packets to the primary interface.
Workaround
Do not attempt to disable the primary interface on the DPE.
Description
Selecting the UPGRADE option when installing BACC 2.5 on the DHCP box to
install the CNR extensions will emit confusing error messages.
Background
The UPGRADE option in the installer is intended to operate on the RDU component
only. Attempting to invoke it on a machine that does not have the RDU component
already installed will result in installer error messages.
Workaround
For a component installation of the CNR extension points, do not attempt to
select the UPGRADE option in the BACC 2.5 installer.
Description:
When using option-177 to provision MTA devices, a lab installation
may fail to return a DHCP offer.
Explanation
For a lab installation, the installer is populating the optional
properties /pktcbl/dhcp/secondary and /pktcbl/dns/secondary with
empty values in the cnr_ep.properties file.
Since these optional properties are present, the BACC
CNR extensions will use empty values in options, if the
configuration commands generated by the RDU reference them.
This causes the CNR DHCP server to drop the DHCP offer packet
since these values are required to be an IP address.
Workaround:
Edit the cnr_ep.properties file and enter valid IP addresses
for these two properties. Usually it is safe, for a lab installation,
to make the secondary properties identical to the primary properties.
Description
When the BACC installation program completes installation for the Solaris DPE
component, the BACC Agent and the DPE process are automatically started.
Since the DPE is not fully configured, it continuously tries to connect to RDU.
This results in console error messages which disrupt any attempt to complete
the DPE configuration via the BACC CLI.
Workaround
The console error messages can be avoided if syslog is configured.
Description
If a BACC component is installed in the /opt directory on Solaris, a later attempt to uninstall may result in the deletion of system and user files.
Workaround
Do not install BACC in the /opt directory. Either accept the default subdirectory name, or specify another subdirectory name.
Description:
The bprAgent does not read its configuration file dynamically.
Explanation:
Installation of the RDU component on top of an existing DPE component
causes the configuration file for the bprAgent to be updated with
details about managing the new component. However, the bprAgent only
reads this configuration when it is started up. The bprAgent will not
show any status for the newly installed component until the bprAgent
is restarted.
Workaround:
Restart the bprAgent after installing one BACC component on top
of an existing BACC component.
Description:
Installation of one BACC component on top of existing BACC component
does not validate ports already in use by the existing component.
The component installer permits selection of a port number that is
already in use by another component that was previously installed.
The two components will interfere with each other's use of this port
until one component is assigned a different port.
Description:
When installing the RDU component on top of another BACC component,
the installer improperly defaults the location of the RDU DB files.
The installer uses the existing BPR_HOME directory to place
the DB files, instead of prompting the user to select a location.
Description The KDC requires that the private key corresponding to the KDC certificate be named KDC_private_key_proprietary regardless of the format of the key.
Description
The KDC provided with BACC 2.6 requires that the private key
associated with the KDC certificate be named "KDC_private_key_proprietary".
The PKCert tool produces a file named KDC_private_key.pkcs8
Workaround
Copy or rename KDC_private_key.pkcs8 to KDC_private_key_proprietary.
Description: Under some circumstances, the RDU may log an exception with relatively little information. While this hinders debugging, it is not necessarily an indication of a serious problem. Generally the problem can be isolated by the context in the logfiles, or by changing the log level to collect additional information.
Description:
Do not enable both interfaces on the DPE for provisioning.
When configured with provisioning enabled on both interfaces,
all UDP responses from the DPE may be directed to an interface
other than the incoming request, causing the external requester
to reject the response.
Description A DPE may report "unlicensed" for a variety of reasons. Workaround If a DPE is logging that it is unable to obtain a license - check the following: 1. Route between RDU and DPE 2. DNS entries for RDU and DPE interfaces 3. DPE is able to reach DNS server and resolve queries 4. RDU contains licenses for the required number of DPEs on the network.
Description:
Occasionally the bprAgent may fail to restart a BACC component.
This may happen if the bprAgent is processing another, recent command.
Workaround:
Wait a few seconds and retry the command.
Description:
Searches on the cpeDHCPCriteria do not return expected results.
The relationships between modems and CPE DHCP criterias are not properly
updated when changes are made. This results in incorrect search results.
Do not rely on search results in order to retrieve modems
associated with a given CPE DHCP criteria.
Description:
The BACC API does not validate the value for the cpeDHCPCriteria property.
If an invalid DHCP criteria value is entered, a large number
of errors will be generated in the RDU logs.
Workaround:
Only enter valid DHCP criteria names as the value for the
cpeDHCPCriteria property.
Only enter cpeDHCPCriteria that are already defined in BACC.
Avoid the use of punctuation and space characters in properties.
Description:
The DPE CLI permits setting an existing route with a different gateway address.
This is an illegal operation that the underlying operating system disallows,
although the CLI appears to work. The route will not appear to be deleted
until all variants of the route are deleted.
Workaround:
Avoid entering the same route with a different gateway.
If this does occur, repeatedly delete the route with the
"no ip route (subnet) (mask)" command until all instances are
removed from the DPE.
Description:
The DPE port is susceptible to random packets.
Workaround:
The UDP port that the DPE is configured to listen on should
be protected from outside access.
For performance reasons the DPE expects to receive only
well-structured messages on this port.
In the process of provisioning a PacketCable MTA an SNMPv3 Security Association (SA) is created between the MTA and the Provisioning Server (PS). This SA must enforce authentication and, by specification, may enforce privacy in all messaging. PacketCable specifications require that once SNMPv3 SA’s have been defined all management communications with the MTA must proceed via SNMPv3 but the specifications do not define how this SA may be used after the provisioning process completes. BACC uses the SA created during provisioning to enable third party SNMPv3 based management applications to monitor and/or control the MTA. BACC does this by utilizing the SNMPv3 Cloning capability as defined in the SNMPv3 RFC’s. Once the provisioning process completes and, assuming the customer has enabled the cloning operation by setting the cloning encryption key, BACC will perform the steps necessary to create a cloned user at the MTA with a similar SA at the RDU. BACC provides API’s that support the ability of the user to request BACC (At the RDU) to create additional SA’s between the MTA and the user’s SNMPv3 enabled management application by additionally cloning the already cloned SA between the MTA and the RDU. This is a fully specification compliant method of operation. Some additional detail may be useful in describing the observed behavior when cloning is enabled. PacketCable specifications require that whenever an MTA is reset or requests a new configuration file from the PS that all existing SNMPv2 SA’s are destroyed. This means that a management application with an existing MTA SA will not be able to communicate with that MTA after one of the above events occur. The observed behavior will be identical to that of a management application that never received an MTA SA in the first place. The requested operation will be ignored or rejected via and SNMPv3 Report. When the SA between the DPE and the MTA is created it may or may not require privacy based upon the policy setting for SNMPv3 privacy at the DPE. Since the customer-initiated portion of the new SA creation is done at the RDU, the RDU may be unaware of the type of SA that was originally created (Privacy on or off) between the PS and the MTA. In order to increase the likelihood of success for the follow on SA creation, the RDU will first attempt to create a "Privacy enabled" SA and, upon failure, attempt to create a "Privacy disabled" SA. This does not compromise security since the MTA will only permit an SA to be created based upon its SNMP VACM settings. Therefore, the success of this follow on cloning operation is dependent upon the MTA’s own settings as well as the VACM entries created at or after provisioning.
When a customer has multiple instances of CNR(regional and local), CNR logs the first instance of installation as its base directory. When you perform a Lab installation of BACC over it, it will install and configure the CNR extensions under the first instance of CNR (ie. the instance specified in the base directory of CNR, to find the base directory of CNR do 'pkgparam nwreg2 BASEDIR'.) If the user wants to install and configure the CNR extensions on the other instance(the one different for its BASEDIR) they can follow the instructions already documented for component installation of CNR_EP (ie. copy the library to the extensions directory and enable extensions)
Description
If BPR_HOME is longer than 20 character, the RDU and DPE components will crash.
Workaround
Keep the BPR_HOME directory name under 20 characters.
Upgrading multiple BACC components installed on the same box is not supported. Please contact the deployment team to come up with a workaround suitable for your situation to do this manually.
Description: Error reported while using primary DHCP server (option 122.1) as 255.255.255.255 in the cnr_ep.properties file
Workaround: None
Description: The RDU API needs to validate the hostname and domainname provided by API client to meet the minimum requirements of RFC 2132 and RFC 1035.
Workaround: Don't use invalid characters in FQDN
Description: After upgrade to 2.6.2/2.7 the rdu.properties got overwritten by the installer and logging/tracing related properties were lost.
Workaround: The logging/tracing need to be configured manually using setLogLevel.sh tool after the upgrade.
Description
The JDK version used in BACC 2.7 prefers the following solaris patches installed. The installer doesn't validate whether these patches are already installed or not.
For Solaris 8: 112003-03 SunOS 5.8 Unable to load fontset in 64-bit Solaris 8 iso-1 or iso-15 108773-18 SunOS 5.8 IIIM and X Input & Output Method patch 111310-01 SunOS 5.8 /usr/lib/libdhcpagent.so.1 patch 109147-31 SunOS 5.8 linker patch 111308-05 SunOS 5.8 /usr/lib/libmtmalloc.so.1 patch 112438-03 SunOS 5.8 /kernel/drv/random patch 108434-18 SunOS 5.8 32-Bit Shared library patch for C++ 108435-18 SunOS 5.8 64-Bit Shared library patch for C++ 113886-26 OpenGL 1.3 OpenGL Patch for Solaris (32-bit) 113887-26 OpenGL 1.3 OpenGL Patch for Solaris (64-bit) 111111-04 SunOS 5.8 /usr/bin/nawk patch 112396-02 SunOS 5.8 /usr/bin/fgrep patch 110386-03 SunOS 5.8 RBAC Feature Patch 111023-03 SunOS 5.8 /kernel/fs/mntfs and /kernel/fs/sparcv9/mntfs patch 111317-05 SunOS 5.8 /sbin/init and /usr/sbin/init patch 113648-03 SunOS 5.8 /usr/sbin/mount patch 115827-01 SunOS 5.8 /sbin/sulogin and /sbin/netstrategy patch 116602-01 SunOS 5.8 /sbin/uadmin and /sbin/hostconfig patch 108652-86 X11 6.4.1 Xsun patch 108921-22 CDE 1.4 dtwm patch 108940-65 Motif 1.2.7 and 2.1.1 Runtime library patch for Solaris 8 108987-14 SunOS 5.8 Patch for patchadd and patchrm 108528-29 SunOS 5.8 kernel update and Apache patch 108989-02 SunOS 5.8 /usr/kernel/sys/acctctl and /usr/kernel/sys/exacctsys patch 108993-39 SunOS 5.8 LDAP2 client, libc, libthread and libnsl libraries patch 109326-16 SunOS 5.8 libresolv.so.2 and in.named patch 110615-13 SunOS 5.8 sendmail patch For Solaris 9: 113886-26 OpenGL 1.3 OpenGL Patch for Solaris (32-bit) 113887-26 OpenGL 1.3 OpenGL Patch for Solaris (64-bit) 113096-03 X11 6.6.1 OWconfig patch 112785-44 X11 6.6.1 Xsun patch
Apply appropriate Solaris patches to your box.
Description: The DPE TFTP server converts incoming TFTP GET filenames to lower-case before attempting to locate the file in the cache or local directory. This could be an issue while attempting to use the DPE TFTP server for firmware image downloads.
Workaround: Convert all the filenames on the local disk to be all lower-case.
Symptom/Condition: The syntax that the runCfgUtil.sh tool uses does not allow generation of options in cases of nested suboptions. For example, when using DOCSIS 2.0 Option 41: 41. 41.1 41.1.1 30 41.1.2 10000000 41.1 41.1.1 30 41.1.2 20000000 41. 41.2 41.2.1 30 41.2.2 30000000 Workaround: Break multiple suboptions into multiple groups. According to the DOCSIS 2.0 RF spec, this definition achieves the same result: 41. 41.1 41.1.1 30 41.1.2 10000000 41. 41.1 41.1.1 30 41.1.2 20000000 41. 41.2 41.2.1 30 41.2.2 30000000
Description: The "giaddrRoVersionMap.txt" can be deleted even if it is being used in DOCSIS defaults for the property "/docsis/cmts/version/giaddrToVersionMap". This results in config generation failures for DOCSIS devices.
Workaround: Don't delete "giaddrRoVersionMap.txt" file.
Description:
If there are multiple BACC components are installed on the same machine, the BACC installer automatically selects all the components for upgrading. The upgrade process also clears the DPE configuration.
Description
BACC 2.7 installer (setup.bin)fails to detect and upgrade the BACC 2.6.x KDC
installed on the box.
Workwround
Uninstall the 2.6.x KDC and then install the new KDC from BACC 2.7 distribution
Description
CNR_EP installed using the GUI installer fails to serve DOCSIS modem component
of eMTA when no value specified for secondary dhcp and dns during installation.
Workaround
Disable the following properties in cnr_ep.properties and reload dhcp server.
#/ccc/dhcp/secondary= #/ccc/dns/secondary=
Description
Currently, even though 2 IP address has been set for the name-servers property
map key, BACC 2.7 configuration
generation extension does not add a second command to include the second
value.
For example; if you set /dhcp/client-policy/response/name-
servers=10.0.12.122,10.0.0.12.123 for a device, only
one is being used for the config generation [PUT_REPLACE "name-servers"
= "10.0.12.122"] of that device.
Workaround
Specify these options at the CNR server level rather than doing it at RDU level.
Description
KDC upgrade from BACC 2.6.x to BACC 2.7 fails with the bprAgent unsuccessful
to start KDC after upgrade.
Workaround
Install BACC 2.7 KDC from scratch instead of upgrading from earlier version.
Description
DPE CLI allows http and https to be configured to use the same port configured
WorkaroundUse a different port number to avoid conflict
Symptom:
JVM 4 (JRE version 1.4.2) defaulted to 64 MB maximum java heap size. The
verifyDb.sh script failed with Exception in thread "main"
java.lang.OutOfMemoryError message when the maximum java heap size is left at
default. The verifyDb.sh script runs to completion when the maximum java heap
size is set to 128 MB or more.
The initial and maximum java heap size has to be specified correcty in
verifyDb.sh script (and perhaps other scripts that use java as well) to
handle the expected database size for the BACC deployment.
Conditions:
Running verifyDb.sh script to verify database consistency.
Workaround:
Only apply this workaround in consultation of Cisco TAC.
Make a backup copy of the verifyDb.sh script, then edit the verifyDb.sh
script to change the line below:
$BPR_JAVA -DBPR_HOME="$BPR_HOME" -DBPR_DATA="$BPR_DATA" -
DBPR_DBLOG="$BPR_DBLOG" -classpath "$BPR_CP"
com.cisco.csrc.db.util.fix.VerifyDb $1 $2 $3 $4 $5 $6 $7 $8 $9
to
$BPR_JAVA -Xms64m -Xmx256m -DBPR_HOME="$BPR_HOME" -DBPR_DATA="$BPR_DATA" -
DBPR_DBLOG="$BPR_DBLOG" -classpath "$BPR_CP"
com.cisco.csrc.db.util.fix.VerifyDb $1 $2 $3 $4 $5 $6 $7 $8 $9
Symptom:
While using RPC calls involving large datasets e.g. excercising
GetParameterAttributes and GetParameterValues RPCs, certain devices may
return 'Resource Exceeded' exception.
Workaround:
Symptom:
The installation program does not verify if the TCP port that you entered is
in use.
Workaround:
Select a TCP port that is not in use.
Symptom:
An RDU uninstallation corrupts the file system, returning unreferenced
directories and an incorrect link count.
Workaround:
Run the fsck -y command.
Symptom:
When more than one users logged into RDU, Device History Details does not show
the correct user that triggers the event. The triggered events always
associated with the last user logged into RDU.
Conditions:
To recreate this problem, follows the following steps:
0) Make sure Device History is enabled (Configuration->Defaults->System
Defaults page in Admin UI)
1) Create 2 read/write users: e.g. Admin1 and Admin2
2) Open two browser windows
3) In browser window #1, log in as Admin1
4) In browser window #2, log in as Admin2
5) Modify some device attribute (e.g. change Registered Class Of Service) in
browser window #1 and Submit the change
6) Go to the affected device's Details page in Admin UI and click on its
Device History, the user is being recorded for triggering the change of Class
Of Service as Admin2. It should be Admin1.
Workaround:
There is no workaround solution for this problem.
Symptom:
When adding a new Configuration file, the Firmware templates have additional
fields for Properies where other templates such as Configuration, Prameter
list does not. Changing the file type from Firmware to Configuration and use
the back button from the browser causes the screen does not refresh properly.
Workaround:
When this problem is happens, get out of the add file screen and come back by click on Configuration-->Files and click on add button.
Symptom:
When Info level logging is enabled on DPE, one can observe that upon CPE
authentication failure, the DPE terminates the session, but then creates
another un-authenticated session for this connection. The second session
expires after a period of ina
@ctivity if device chooses not to re-try authentication. While creation of
the second session is unneeded and may be confusing, it is not harmlful to the
DPE functionality or protocol consistency.
Conditions:
Authentication failure, while Info level logging or debugging is enabled.
Workaround:
No workaround is needed as this problem only impact readability of the log.
Symptom:
Operation performed on the device at the RDU (triggered from the API or from
the DPE) fails with exception "ArrayIndexOutOfBoundsException". The exception
is recorded in the rdu.log and for user operations initiated from the
administrative UI applic
@ation the exception is also displayed on the web page.
Conditions:
This problem will occur after reducing the the maximum device history record
size in global defaults. The problem would occur for any device which already
has more records that tahe new maximum. For example, the default maximum
number of history r
@ecords per device is 40. If device reaches that limits, and later, the
maximum is reduced to 20, then the next operation on the device will fail with
exception.
Workaround:
Don't reduce the maximum number of history records stored per device. If the problem is limited to a few devices, the device records can be deleted and re- added, thus resetting their history.
Symptom: When the MTA receives a KRB_AP_ERR_SKEW error message from the Provisioning Server, it rejects this message because it detects an incorrect checksum. Conditions: This error occurs when the MTA needs to send KRD_ERR message. Workaround: No workaround available.
Symptom:
BACC 2.7 - The RDU and runCfgUtil.sh Template File Generator utility do not
correctly parse duplicate Sub-Options under a single TLV-43 Sub-Option 8
Vendor ID. Motorola implementation for sub-options S139 - S142, for
instance, require two entries per sub-option if the settings are to be
applied to both Line 1 and Line 2 of a PacketCable MTA device. The
Motorola config file and their compiler will handle these duplicate
entries under a single Sub-Option 8 (Vendor ID).
If the binary file created with Motorola's "bticonfig" compiler has
these duplicate sub-options included and is used as the input file to
runCfgUtil.sh, the resultant template file can be run as a template file
input to the runCfgUtil.sh and create a binary file with no errors.
The same template can be uploaded to BACC as an External File and the
RDU will generate a binary config file for the device with no errors.
However, the MTA device itself will reject the duplicate sub-option(s)
when that binary config is TFTP'd to the device.
Workaround:
To fix this problem, you must manually edit the template to use the
"instance" keyword to explicitly group the TLVs ie:
> > Option 43.8 instance 1 00-20-40
> > Option 43.126 instance 1 hex 02
> > Option 43.139 instance 1 hex 0006
> > Option 43.139 instance 1 hex 0107
> > Option 43.140 instance 1 hex 0008
> > Option 43.141 instance 1 hex 0009
> > Option 43.142 instance 1 hex 0010
This causes the all the 43 sub-TLVs to be included in the same 43 TLV
parent.
Symptom:
bprAgent start will failed
Conditions:
Select invalid directory for BAC Home(BPR_HOME) or BAC Data(BPR_DATA) or
BAC DBLOG(BPR_DBLOG).
Workaround:
Make sure you select valid directories for BPR_HOME,BPR_DATA, and BPR_DBLOG
Symptom:
When adding an external file, there is no validation code to validate that
contents of file match file type. For example, it allows to create the file
type is JAR but the content could be anything, not a valid jar file. Another
example is it allows to create a configuration file and the content is a jar
file.
Workaround:
Delete the file and add it back.
Symptom:
the DPE became unlicensed and it is unable to obtain a license even though
the RDU contains DPE licenses and the DPE is connected to the RDU.
Conditions:
DPE was connected and registered with RDU successfully. User decided to
reinstall the RDU with a clean database. DPE failed to register with newly
installed RDU.
Workaround:
To workaround this problem reload the DPE using the CLI.
Symptom:
For DPE that have a lower version of BAC then 2.7 (eg. BAC 2.6.x) the DPE
view log file icon does not work.
Workaround:
We added the view log feature for DPE in BAC 2.7 so the previous DPE (BAC
2.6.x) do not have that feature as a result the view icon when clicked will
not produce the desired result. The work around is to view the logs by using
the CLI on the DPE.
Symptom:
RDU may return a batch error indicating that a duplicate batch was
submitted, when in fact no two duplicate batches ever existed in the system.
Conditions:
When one batch returns and the second is submitted immediately with the same
name, under rare circumstances BAC may report that the batch is duplicate.
Workaround:
Assign unique names to batches.
Further Problem Description:
BAC prevents two batches with the same name from being in the system at the
same time. However, after BAC responds with results for a given batch, it
takes a small window of time before it removes the information about the last
batch from memory. If a new batch with identical name arrives before RDU was
able to clear the state for the previous batch, it may report an
inappropriate duplicate batch error.
Symptom:
BAC reports the RDU or the DPE is running when the server is shutdown.
Conditions:
This can occur if there are shell processes running BAC utility scripts.
Workaround:
None.
Symptom:
When you try to modify an existing DHCP Critiria through UI, the UI page
submits a batch where it tries to change all the attributes associated with
that dhcp criteria. This causes the devices associated with the DC to have
their configurations regenerated 4 times, even if only 1 of the 4 attributes
in this page is modified.
Workaround:
Use the API to modify only the relevant changes for that dhcp criteria. But
if more than one attribute is changed, it will still result in duplicate CRS
events. So this is really a reflection of the API and how CRS is trigger by
API commands.
Symptom:
Upgrade process will abort and give this error if BAC is running during
upgrade.
Error: 8100 is in use. Please disable the process which is bound to this
port.
Conditions:
This problem will happen if BAC Is running during upgrade.
Workaround:
You could stop bprAgent manually to get around this problem by running
command below.
/etc/init.d/bprAgent stop
Symptom:
The verifyDb.sh tool reports that optimizations were detected. The detailed
XML log produced by the tool reveals that a Computer device does not have a
link to a cable modem device, which is present in the database. Usually only
a handful of such devices are detected some very large deployments.
Conditions:
The condition that causes this is unknown at this point.
Workaround:
Execute rdu/internal/db/bin/optimizeDb.sh tool to fix this issue. The tool
requires the XML log file produced by verify db as input.
Further Problem Description:
This issue has been seen in 2.6.x customer databases. The migration to 4.0
does not automatically fix this issue. So, it will still be reported by
verifyDb.sh.
Symptom:
When upgrading dpe from 2.6.x to 4.0, dpe.properties do not get upgraded
properly
Conditions:
If dpe is configured with logical interfaces (e.g. bge0:1) and provisioning
enabled on the logical interfaces, it won't get upgraded properly
Workaround:
The workaround is reconfiguring DPE using CLI "interface ip xxxxxxxxx"
commands.
Symptom:
The sample cm binary file, unprov_30v6.cm, for IPv6 device is rejected by
the latest SA 2205/2203 IPV6 cable modems.
Conditions:
The current unprov_30v6.cm file has an incorrect TLV 53 instance grouping,
it should be regenerated from the corresponding template (unprov_30v6.tmpl).
Workaround:
The workaround is to use the unprov_30v6.tmpl, or generate a new
unprov_30v6.cm from the same template.
Symptom:
4.0 CNR EP successfully registers with RDU and joins a provisioning group
containing 2.6.2.x DPEs.
Conditions:
BAC RDU allows a 4.0 CNR EP successfully registers when its capabilities
match with the provisioning group it intends to join, even though BAC 4.0 do
not support a provisioning group mixed of 2.6.2.x DPEs and 4.0 CNR EP.
Workaround:
Customers should upgrade the 2.6.2.x DPEs in the prov group before upgrading
the CNR EP to avoid this problem.
Symptom:
After upgrade from 2.6.2.x to 4.0, CNR EP fails to register with RDU
Conditions:
It only occurs with CNR EP upgrade (not with the brand new install) and only
when CNR EP is previously packetcable enabled.
Workaround:
manually change $BPR_HOME/cnr_ep/conf/cnr_ep.properties
from
/provgroup/capability/both/packetcable/ipv4=true
to
/provgroup/capability/both/packetcable/ipv4=enabled
This fix would allow upgraded CNR EP successfully joins a provisioning group
with packetcable capability enabled.