Guest

Cisco Broadband Access Center

Release Note for Broadband Provisioning Registrar Release 2.0.3

  • Viewing Options

  • PDF (387.3 KB)
  • Feedback
Release Notes for Broadband Provisioning Registrar Release 2.0.3

Table Of Contents

Release Notes for Broadband Provisioning Registrar Release 2.0.3

Contents

Introduction

System Components

System Requirements

Hardware Considerations

Device Provisioning Engine 590

Upgrading to Broadband Provisioning Registrar 2.0.3

Solaris Upgrade

Upgrading the DPE

Online Database Backups

Bugs

Known Software Problems

Corrected Software Problems

Converting DPR Client Class and Selection Tags to BPR DHCP Criteria

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center


Release Notes for Broadband Provisioning Registrar Release 2.0.3


December 9, 2002

These release notes are for patch release 2.0.3 of Cisco Broadband Provisioning Registrar. Although no new functionality is being introduced with this patch release, it does contain several important bug fixes.

Contents

Introduction

The Broadband Provisioning Registrar (BPR) product is a high-speed provisioning application that is easy to install, configure, and maintain. It provides a simple and easy way to deploy high-speed data services while also supporting DSTB and voice services. With this product release, all integration is done through a Java-based provisioning API and pregenerated static configuration files are used to define the desired levels of service.

This provisioning API allows easy integration into an existing operations support system (OSS) environment.

System Components

The BPR comprises these major components:

The regional distribution unit (RDU), which is software that you install on your server(s).

The device provisioning engine (DPE), which is software that comes pre-installed on rack mounted hardware known as the Device Provisioning Engine 590.

An application program interface (API) with which you can integrate BPR with other OSS and billing systems.

An administrator's user interface from which you can monitor and manage various devices.

System Requirements

You must have the Solaris 8 operating system and Network Registrar installed on your system to successfully use the BPR.


Note Although the minimum Network Registrar version supported is 5.0.11, Cisco Systems recommends that Network Registrar version 5.5.4 be the minimum version used.


Hardware Considerations

The minimum hardware requirements needed to support both a lab and a fully deployed network are provided in Table 1.


Note Processing capacity, disk storage, and memory requirements depend on the size of the network deployment and the amount of log information needed.


Table 1 Broadband Provisioning Registrar Hardware Considerations  

Number of Devices
Server Type
Minimum Number of Servers
Recommended Number of Servers
Recommended Number of Servers (with DNS)
Server Class
Number of Processors
Memory

100
(Lab use)

 

1

1

1

Sun Fire V120 (NEBS 120)

1

1 GB


Note A single server device is required to support the RDU, DPE, and NR in a lab installation.

 

250,000

RDU

1

1

1

Sun Fire 280R (Netra 20)

2

1 GB

DPE

1

2

2

N/A

N/A

N/A

NR

1

2

3

Sun Fire V120 (Netra 120)

1

512 MB

500,000

RDU

1

1

1

Sun Fire 280R (Netra 20)

2

2 GB

DPE

2

4

4

N/A

N/A

N/A

NR

2

4

6

Sun Fire V120 (Netra 120)

1

512 MB

1,000,000

RDU

1

1

1

Sun Fire 280R (Netra 20)

2

4 GB

DPE

4

8

8

N/A

N/A

N/A

NR

4

8

12

Sun Fire V120 (Netra 120)

1

512 MB


Device Provisioning Engine 590

The device provisioning engine 590 (DPE) must be installed in either a 19- or 23-inch, two or four post Telco equipment rack. All installation and connection issues are discussed in the 500 Series installation guide that accompanies this product.

Upgrading to Broadband Provisioning Registrar 2.0.3

There is currently no upgrade path from any release of BPR prior to BPR 2.0.2. If you are currently operating with release 2.0.1 or earlier, refer to you Broadband Provisioning Registrar Installation Guide and follow the instructions to uninstall the product. After uninstalling the product, you must ensure that you remove the database files and then you can run the BPR 2.0.3 installation program.

Solaris Upgrade

BPR 2.0.2 users can simply run the upgrade script, located in the same directory as the downloaded BPR 2.0.3 installation bundle, using the command line:

BPR_203_Solaris/upgrade/upgrade.sh

Upgrading the DPE

To upgrade your DPE:


Step 1 Locate the upgrade20xTo203.bpr file on the Broadband Provisioning Registrar 2.0.3 CD-ROM and FTP it to the /incoming directory of the DPE to upgrade. You will need to log into the DPE as the administrative user and the password for this is the same password that was assigned to the box through the telnet and console interfaces.

Step 2 Telnet to that DPE or connect using the console interface.

Step 3 Run the enable command to enter the enable mode. This prompts for the password again.

Step 4 Enter the appropriate password.

Step 5 Run the dpe stop command to stop the DPE.

Step 6 Run the upgrade command and a list of upgrades will appear on screen. Look for the upgrade20xTo203.bpr upgrade and note that it is prefixed with either a number or a minus sign.

A numeric prefix indicates that the upgrade bundle can be installed and you can proceed with the next step in this procedure.

A minus sign (-) prefix indicates that the bundle cannot be applied. If this is the case, refer to the description to identify the cause of the problem.

Step 7 Enter the prefix number and then press Enter. The upgrade program prompts you for confirmation before proceeding.

Step 8 Press y to proceed. The upgrade program begins to upgrade the DPE which, upon completion, reboots to start BPR release 2.0.3.


Online Database Backups

Some UNIX commands may not be appropriate for use while performing online backups. These commands include:

The cp command does not atomically read files in the proper database blocks because it reads files using the mmap system call rather than with standard read system calls.

The tar command cannot be used on files modified underneath it and, while it uses standard read calls, it does not read in proper aligned blocks even if a certain block size is specified as command line parameter.

A standard UNIX tool, called dd, can be used to perform a hot backup. This tool reads in proper blocks and does not use mmap. The correct block size of 8192 bytes has to be specified for the tool. This tool can be used to copy the database to another location on disk or other media. To implement this tool, enter this line:

dd if=/data/CSCObpr/rdu/db/bpr.db of=/backups/db/bpr.db_copy bs=8k

This example copies the bpr.db file from its current location (/data/CSCObpr/rdu/db/) to a new location (/backups/db/) with a block size of 8 KBytes.

Bugs

For information on BPR bugs, see the BPR_BugList.html file in the docs/ subdirectory of the Broadband Provisioning Registrar CD-ROM or electronic distribution.

Known Software Problems

Table 2 identifies software issues that are known to exist in this release of Broadband Provisioning Registrar.

Table 2 Broadband Provisioning Registrar Known Software Problems  

Number
Description
Resolution

CSCdv55156

Once TFTP read or write access is enabled, it cannot be disabled using the application programming interface (API).

TFTP properties are not dynamic. Once they are changed, you need to restart DPE for the changed value to take effect.

CSCdv58014

You cannot modify unprovisioned devices, such as changing the devices class of service, using the BPR administrator user interface.

This means that you cannot invoke the DOCSIS.changeDOCSISModemClassOfService() API call with an unregistered DOCSIS modem.

To correct this problem you should register the device using the appropriate addXXX() API call.

For example, use the DOCSIS.addDOCSISModem() call to register a DOCSIS modem before trying to make any modifications to it through the administrator user interface.

CSCdv63062

The command getIPDeviceByFQDN returns a list with a dot at the end of the fully qualified domain name (FQDN). The FQDN is originally entered into the database without this dot.

Use the normalized FQDN form (using a dot at the end) while passing the FQDN as a parameter to BPR API calls.

CSCdv66658

DHCP has to be restarted after Lab install.

To correct this problem, which might occur after you have completed a lab installation of BPR, restart the DHCP server.

CSCdv80712

Replacing a dynamic template file does not regenerate all devices which use that file.

There are two possible workarounds to this problem:

1. Shutdown the DPE, clear the cache, and restart it. This will cause the DPE to identify and regenerate the invalid configurations.

2. Call the GenerateConfiguration API call for each affected device to to regenerate the configuration.

CSCdv82267

The Broadband Provisioning Registrar product assumes that character strings entered into it use ASCII character encoding.

Complete these steps to enable ASCII encoding:

1. Create a subdirectory called api/conf in the BPR_HOME directory. (Assume BPR_HOME to be the directory in which BPR has been installed.)

Note If your BPR deployment is installed in a directory called /opt/CSCObpr, you will create a subdirectory called /opt/CSCObpr/api/conf.

2. Create a text file called api.properties.

3. Enter this line in this text file:

usASCII/character/encoding/ enable=disabled

4. Enter the same line in the existing file called rdu.properties. This file is located in the BPR_HOME/rdu/conf directory.

Note You must restart your RDU and API application for these changes to take effect.

CSCdv84318

The RDU does not generate an alert when the connection to any of these servers is lost:

provisioning API

Network Registrar extensions

DPE

Network Registrar extensions and the DPEs will send an alert if the connection to the RDU is lost.

Note Monitor for this alert.

The provisioning API sends a MessagingEvent to indicate that the connection has been lost.

Note Listen for this event.


CSCdv89919

The class of service and DHCP criteria can be deleted, even if the default values are used.

Never attempt to delete the default values. Doing so will lead to system instability.

CSCdw05196

If, after the final confirmation of installation details and copying of files starts, you resize the installer window, a Cancel button, appears. If you press this button the installation process will lock up and the installation will not proceed.

Never attempt to resize the installation window while files are being copied.

Note Do not click the Cancel button if it appears on screen.

CSCdw10026

The RDU does not perform an extra write for every device added to the database. Doing so would adversely affect system performance. Since these object counters are updated at periodic intervals, the device statistics displayed through the administrators user interface only display an approximate device count.

Do not consider the displayed device count to be entirely accurate.

CSCdw24301

If running the uninstallation program in the console mode on a lab installation, you are not prompted as to whether it is OK to delete the database or not. The database is just deleted.

Use the graphical user interface uninstallation program or, prior to running the uninstaller, copy the database files and log files to another directory.

CSCdy31035

When using the API command, the provGroupName parameter is case-sensitive.

Ensure that the provGroupName parameter, in the deleteProvGroup command, contains the exact provisioning group name.

For example, to delete a provisioning group called ProvGroup1, using the name provgroup1 in the provGroupName parameter will return an error.

CSCdy64358

While the RDU is under heavy load, a change to the SNMP community string can appear to not take affect.

If this occurs, change the SNMP community string to another value, and then change it back again, to the intended value. This will typically cause the change to take place.

Note If this problems continues, wait until the server load is reduced somewhat and then make the change.

CSCdy79942

When the DPE is populating its cache, after re-establishing connectivity with the RDU, it is possible that it will attempt to build a configuration for a device that has been deleted.

This can occur when a device is deleted after the DPE has connected, and synchronized with the RDU, but before the population stage has been completed. Under normal operating conditions, there is a very small window of opportunity for this to occur. However, the size of this window of opportunity increases when hundreds of thousands of devices must be populated.

To correct this problem, restart the DPE once the DPE has finished the majority of the population. When the DPE is restarted, there will be considerably less data to be synchronized with the RDU. Also, when the restart is complete, the deleted device will be recognized as having been deleted and the DPE will successfully populate.

CSCdz42836

Currently the RDU will not use more than 4 GB of RAM memory.

Currently there is no resolution for this problem.


Corrected Software Problems

Table 3 identifies software issues that have been corrected in this, or previous releases of Broadband Provisioning Registrar.

Table 3 Broadband Provisioning Registrar Corrected Software Problems  

Number
Description
Resolution

CSCdv60178 and CSCdy53254

In certain situations, the DHCP server may be slow to realize that its RDU connection is down. If there is no activity between the servers when this occurs, the DHCP server may take as much as two hours to detect the situation. However, once there is activity from the DHCP server to the RDU, the connection should be re-established.

This situation is resolved in BPR release 2.0.3 through the use of a periodic heartbeat between the DHCP server and the RDU. This serves to not only detect when the connection is down, but to cause activity to stop the connection from being dropped due to excessive idle time.

CSCdw79600

The DPE may occasionally continue to serve deleted configuration files.

This problem has been corrected in BPR release 2.0.2.

CSCdx05789

Changing the properties of a DOCSIS class of service by specifying NULL as the map of properties to change results in Null.pointer.Exception errors.

The ClassOfServiceProperties() API command was updated, in BPR release 2.0.2, to check whether the properties value is null before accessing the filename from it.

CSCdx25182

Incorrect concurrency handling occurs with the GlobalProperties command.

The nonconcurrent list was updated, in BPR release 2.0.2, so that the DefaultsCache command would not be used in subsequent BPR releases. The original list was:

Configuration.replaceExternalFile

CustomCPE.changeCustomCPE
Defaults

CustomCPE.changeCustomCPE
TypeProperties

CustomCPE.deleteCustomCPEType

Provisioning.changeClassOfService
Properties

Provisioning.changeDHCPCriteria
ClientClass

Provisioning.changeDHCPCriteria
ExcludeSelectionTags

Provisioning.changeDHCPCriteria
IncludeSelectionTags

Provisioning.changeDHCPCriteria
Properties

CSCdx25182
(continued)

Incorrect concurrency handling around GlobalProperties command.

Provisioning.deleteClassOfService

Provisioning.deleteDHCPCriteria

Additions to the nonconcurrent list now include:

Computer.changeComputerDefaults

Configuration.addUser

Configuration.addCustomPropertyDefinition

Configuration.changeDPEDefaults

Configuration.changeExtensionPoint
Settings

Configuration.changeRDUDefaults

Configuration.changeSystemDefaults

Configuration.changeUser

Configuration.removeCustomPropertyDefinition

Configuration.replaceExternalFile

CustomCPE.changeCustomCPE
Defaults

CustomCPE.changeCustomCPEType
Properties

CustomCPE.deleteCustomCPEType

DOCSIS.changeDOCSISDefaults

DSTB.changeDSTBDefaults

DVB.changeDVBDefaults

Provisioning.changeClassOfService
Properties

Provisioning.changeDHCPCriteria
ClientClass

Provisioning.changeDHCPCriteria
ExcludeSelectionTags

Provisioning.changeDHCPCriteria
IncludeSelectionTags

Provisioning.changeDHCPCriteria
Properties

Provisioning.deleteClassOfService

CSCdx25182
(continued)

Incorrect concurrency handling around GlobalProperties command.

Provisioning.deleteDHCPCriteria

Proprietary.addAdminUser

Proprietary.changeAdminPassword

Proprietary.changeSystemDefaults

Proprietary.registerServer

CSCdx41459

The RDU common extension may not correctly handle missing DHCP criteria or class of service.

This problem was corrected in BPR release 2.0.2.

CSCdx54476

Using the resetIPdevice command on a device that does not exist in the database results in the generation of a NullPointerException error.

This problem was corrected in BPR release 2.0.2.

CSCdx67931

A database iterator problem may result in a StackOverflowException error occurring.

This problem was corrected in BPR release 2.0.2.

CSCdx70704

The DPE takes too long to realize lost connection with RDU.

Corrected in BPR release 2.0.2, the DPE now sends a message to, and expects a reply from, the RDU. If the reply is not received, the DPE recognizes that it has lost the connection.

CSCdx70708

Network Registrar (NR) extensions may be blocked during an IP update when the connection to the RDU is lost.

Commencing with BPR release 2.0.2, the connection closes whenever a timeout occurs while sending a message to the RDU.

CSCdx76612

The regional distribution unit (RDU) fails when more than 350 classes of service are added.

This problem was corrected in BPR release 2.0.2.

CSCdx81626

Log messages are not generated when the device detection device type does not match the type saved in the database.

A warning message was added in BPR release 2.0.2 to indicate that the detected device type is different from that which the device was created.

CSCdx91511

The default RDU device detection extension point requires the relay agent circuit ID suboption (option 82, suboption 1) in the DHCP configuration, even though its not strictly required and many CMTS vendors do not insert this in the DHCP packet.

The device detection extension was modified in BPR release 2.0.2 so that does not a require the circuit ID suboption.

CSCdx91674

If a computer is registered and its modem is Promiscuous, the Promiscuous mode incorrectly overrides the registered mode.

Starting with BPR release 2.0.2, the extension now checks to see if the computer is registered and, if it is, the Promiscuous mode is ignored.

CSCdx92059

There is a need for a deleteProvGroup API.

The Configuration.deleteProvisioning
Group() API command was added in BPR release 2.0.2. This command will only delete the provisioning group if that group has no associated DPEs, Network Registrar servers, and devices. An error is displayed, if any of these are associated with a provisioning group that is being deleted.

CSCdx92065

Not all properties returned from getXXXDefaults() command can be set when calling the changeXXXDefaults() command.

The maps from all of the changeXXXDefaults() command were corrected in BPR release 2.0.2 so that they work properly with the corresponding changeXXXDefaults() command.

CSCdx94918

The need exists to include DOCSIS options based on the device model.

Include statement support was added to the template file syntax, in BPR release 2.0.2, to allow macro substitution for the filename. These substitutions are supported:

a. include ${include-file}—the {include-file} macro must be defined as a property in any of the BPR hierarchy defaults. If it is not defined, an error is generated while parsing the DOCSIS template.

b. include ${include-file,default-
value}—the macro namely {include-file} macro MAY be defined as a property in any of the BPR hierarchy defaults. If it is not defined, the default-value specified in the docsis template file is used.

c. include ${include-file,ignore}—the macro namely {include-file} macro MAY be defined as a property in any of the BPR hierarchy defaults. If it is not defined, the line is ignored for DOCSIS template parsing and logged appropriately.

CSCdx94939

Provisioning group names are case sensitive, which could lead to difficulty or confusion during configuration.

Case sensitivity was removed from BPR provisioning group names in BPR release 2.0.2.

CSCdy00781

BPR 2.0.1 explicitly assigns the default class of service when null is used as the class of service argument. Subsequently changing the default class of service and regenerating the device's configuration results in the device still being on the old class of service. This affects both registered and unregistered devices. The API should not set devices to a service unless explicitly asked to do so in the API (for example, a non-null value passed in).

Starting with release 2.0.2, BPR 2.0.2 will not assign a class of service to a device when null is passed in for this argument in the API.

This problem has been corrected by the introduction of a class of service named DEFAULT_CLASS_OF_SERVICE_
<tech name>. This class of service is assigned to those devices having no explicit class of service.

If a device has this special class of service, then the RDU extensions assign the default class of service from the corresponding technology defaults.

Note You cannot add, delete, or otherwise change class of service names that have this prefix. You can however, search for devices having this special class of service.

CSCdy02756

The AddXXX() commands for modems and custom customer premise equipment (CPE) do not result in errors when that CPE DHCP criteria specified does not currently exist in the database. This results in devices receiving the default DHCP criteria for promiscuous mode.

A check was added, in BPR release 2.0.2, to ensure that the CPE DHCP criteria is present in the database. The command was changed to display an error rather than setting the CPE DHCP criteria to null.

CSCdy14676

In previous versions of BPR, some modem-computer relationships were not maintained correctly.

Starting with BPR release 2.0.2, computers cannot receive their configurations unless the modem has already been recorded in the database.

CSCdy15508

After an upgrade fails, there is no way to tell that the DPE might has been left in an inconsistent state. This might happen if there is a power outage while the upgrade is taking place or for other similar events.

Starting with BPR release 2.0.2, the DPE now checks to see if the UPDATE.LOCK file exists in the /opt/CSCObpr/appliance/conf directory. If it does, the DPE will not start up. To correct this issue the DPE must be re-imaged.

CSCdy17349

The class of service to file association cannot be removed.

The changeClassOfServiceProperties API call was modified, in BPR release 2.0.2, to allow the unlinking of the class of service to file relationship.

CSCdy19646

A minor database recovery error exists in Chapter 6 of the Broadband Provisioning Registrar Administrator's Guide.

Step 9 in the Failure Recovery section should read:

"Copy the recovered database file, bpr.db, and the most recent (as identified by timestamp or log number) log file to the <BPR_DBLOG>/rdu/dblog directory."

CSCdy43473

When the RDU is unable to identify a new device booting on the network, the resulting log message contains insufficient information to explain why the failure occurred.

The device detection in the RDU has been enhanced, in release 2.0.3, to correctly log why a failure occurs as well as logging conflicts between various data sources that may exist for a given device's type detection.

CSCdy43475 and CSCdy43478

When a DPE does not have a configuration requested by a Network Registrar DHCP server, the BPR extension within Network Registrar forces the packet to be dropped.

There is no log message to indicate why the packet was dropped.

Note This also happens when the existing configuration is invalid.

Starting with BPR release 2.0.3, the BPR extension logs a message to the Network Registrar log just before the packet is dropped. This message identifies the reason the request could not be processed.

CSCdy43512

While processing DHCP packets, the BPR extensions are used to look up additional information. In addition, BPR may process NAK packets incorrectly and could result in improper DHCP options being inserted in those NAK packets.

Starting with BPR release 2.0.3, the BPR extension ignores NAK packets and no longer performs any processing on the data.

CSCdy57902

By default, BPR did not retrieve the Network Registrar flag that indicated whether a client ID was specified by the device or created by Network Registrar. This Network Registrar flag, called client-id-created-from-mac-addr, allows external users of the data to determine whether the client ID can be used as an authoritative key for the device.

Starting with BPR release 2.0.3, the device configurations passed to Network Registrar request that this field be returned and passed to the RDU. This makes the data available so that external systems can make informed decisions on how they wish to use the client ID.

CSCdy75483

An earlier BPR release placed all batches in the same queue prior to being processed by the RDU. While this worked reliably, certain situations could result in a flooding of particular batch types. This would effectively slow down all other operations being performed against the RDU.

Starting with BPR release 2.0.3, the RDU has been updated with multiple queues to which operations are placed. This ensures that the API maintains responsive while other operations, such as DPEs synchronizing/populating, are taking place.

CSCdy77652

Under certain situations, the DPE's Time of Day (ToD) server could stop and not recover. This could potentially prevent cable modems from booting against the server.

Starting with BPR release 2.0.3, the DPE ToD server implementation has been changed so that an unexpected error communicating with the socket triggers a restart of the ToD server. This ensures continued ToD server operation once the restart is complete.

CSCdy77657

When running the RDU for extended periods of time, resynchronization would take much longer than expected. This was true even when an insignificant number of devices changed and was the result of a problem whereby the RDU incorrectly tracked those devices with configuration changes. While this never resulted in incorrect data arriving at the DPE, it would cause a significant load on both the RDU and the DPE when the connection was lost and then restored.

Starting with BPR release 2.0.3, the RDU correctly tracks which devices have changed, and keeps those changes in sync with the DPEs. In this way, the restoration of lost connections does not cause an unnecessarily heavy load on either the RDU or the DPE.

CSCdy80018

When a TFTP server receives a write request, the log did not indicate who was attempting to write.

The TFTP server log function has been improved, in BPR release 2.0.3, so that the client's source IP address is logged when the TFTP server receives a failed write attempt.

CSCdy83640

BPR no longer supports the DSTB and DVB interfaces.

In the BPR 2.0.3 release, DVB and DSTB interfaces are deprecated, although they do continue to function. In future releases of this product, these interfaces will be removed entirely.

CSCdy83777

The DPE was incorrectly running the portmapper service; opening a port that was unused for anything. While this did not present any known security issues, the unneeded port should not be left open to reduce potential risks.

In the BPR 2.0.3 release, the DPE no longer runs this service.

CSCdy89367

Batch should implement all interfaces

In previous versions of BPR, in order To make a call into the api, you have to make a call similar to this:

Batch batch = connection.newBatch();

DOCSIS api = (DOCSIS)batch.getProv
API(APINames.DOCSIS);

api.deleteDOCSISModem("1,6,00:11:22:
33:44:55");

BatchStatus status = batch.post();

In BPR release 2.0.3, the batch object has been enhanced to implement the Computer, Configuration, CustomCPE, DeviceSearch, DOCSIS, DSTB, DVB, Provisioning, and XGCP interfaces. Therefore you no longer have to call this line:

DOCSIS api = (DOCSIS)batch.getProv
API(APINames.DOCSIS);

The deleteDOCSISModem method can be called directly on the batch object returned from connection.newBatch().

CSCdz03352

When BPR operated on a computer with more than four gigabytes of memory, the server would fail to start up correctly.

This problem has been resolved, in BPR release 2.0.3, by correctly calculating the various allocation footprints for the BPR server components.

CSCdz10144

When the change<type>MAC
Address(...)
API call is used, it does not result in the expected behavior. The call could leave data in an inconsistent state, resembling a device that has the DHCP request history for a different MAC address. Additionally, the call fails if an unprovisioned device exists in the database with the new MAC address. This is inconsistent with the rules that the add<type>(...) call uses.

The change<type>MACAddress(...) call was updated, in the BPR 2.0.3 release, to correctly maintain the state of the device record when switching the MAC address. This change now allows the call to be used safely to transactionally swap in one device for another. For example, when replacing a defective cable modem in the field.

CSCdz20943

When the DHCP server is processing a packet while the RDU connection is down, or is sending a configuration generation request to the RDU and it fails, the packet will be dropped if the configuration's validation fails.

In the BPR 2.0.3 release, the DHCP server returns the device configuration even if the configuration fails validation because the DHCP server does not have a valid connection to the RDU.

CSCdz28620

An invalid memory allocation error might occur in computers having more than 10 GB of available memory.

Currently Java only supports a maximum of 4 GB assigned as heap memory. The algorithms for determining the memory to use is simply a percentage of the total available memory on the computer. Since the RDUs algorithm calculates heap memory as 40% of the computers memory, having more that 10 GB will likely cause Java's virtual machine (VM) to break on startup.

This problem has been corrected in Release 2.0.3.

CSCdz36093

Error messages appear when using the show dpe command during DPE start-up. These messages indicate that the DPE is currently busy or unavailable.

In the BPR 2.0.3 release, the show dpe command operates correctly when the DPE is synchronizing with the RDU.

CSCdz36153

A very short timeout is used when the DPE registers with the RDU. In some situations, such as with a densely populated RDU, this could cause multiple registrations to occur for a single DPE.

Consequently, if a long batch is being processed the DPE could time out and retire before registration is complete. This can also apply to synchronization requests if a large number of DPEs are running against a single server.

In the BPR 2.0.3 release, these time outs have been changed, together with prioritized queuing support, to prevent duplicate registrations or synchronizations form taking place.


Converting DPR Client Class and Selection Tags to BPR DHCP Criteria

This section is of use to those who are currently using the Device Provisioning Registrar (DPR) product and want to start using the Broadband Provisioning Registrar (BPR) product. Before doing this, you must define new DHCP criteria in BPR that matches the corresponding DPR client classes.


Note Although this description covers DOCSIS modems, it is applicable to all of the devices supported by BPR.


Two Device Provisioning Registrar API calls, Provisioning.addDOCSISModem() and Provisioning.changeDOCSISModemClientClass() API, have a parameter called clientClass. This parameter represents the Network Registrar client class to which the device, in this case a modem, belongs. These parameters are used to select a scope from within Network Registrar.

Broadband Provisioning Registrar API also has these two API calls. However, BPR cannot directly accept the client class name as a parameter. BPR expects a DHCPCriteria name, and associates the device with the DHCPCriteria specified. The client class or selection tags specified in the DHCP criteria is used to select a Network Registrar scope.


Note Cisco recommends that you define DHCP criterias with the same names as the previously used client classes. This will ensure backward compatibility with the Device Provisioning Registrar.


To convert the selection tags to DHCP criteria you must define a new DHCP criteria from within BPR, using the selection tag name from DPR. You must also insert an inclusion selection tag in BPR using the same name as that which exists in DPR.


Note For additional information on adding DHCP criteria, refer to the Broadband Provisioning Registrar Administrator's Guide and the Broadband Provisioning Registrar Developer's Guide.


Obtaining Documentation

The following sections explain how to obtain documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL:

http://www.cisco.com

Translated documentation is available at the following URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.

You can e-mail your comments to bug-doc@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to:

Streamline business processes and improve productivity

Resolve technical issues with online support

Download and test software packages

Order Cisco learning materials and merchandise

Register for online skill assessment, training, and certification programs

You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:

http://www.cisco.com

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:

http://www.cisco.com/register/

If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:

http://www.cisco.com/tac/caseopen

If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Before calling, please check with your networ]k operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.