Specifications

2-33

Cisco CRS-1 Series Carrier Routing System XML API Guide

OL-4596-02

Chapter 2 Cisco CRS-1 Series XML Router Configuration and Management

Configuration Operations

Sample XML Response from the Cisco CRS-1 Series Router

<?xml version="1.0" encoding="UTF-8"?>

</Response>

Tip The following issues should be noted with regard to committing the target configuration:

• After each successful commit operation, a commit record is created in the Cisco CRS-1 Series router

commit database. The Cisco CRS-1 Series router maintains up to 20 entries in the commit database

corresponding to the last 20 commits. Each commit is assigned a unique identifier, for example,

“1000000075,” which is saved with the commit information in the database.

The commit identifier

is used in subsequent operations such as <Get> commit changes or <Rollback> to a previous commit

identifier (along with the <CommitID> tag).

• The configuration changes in the target configuration are merged with the running configuration

when committed. If a client application is to perform a replace of the configuration, the client must

first remove the unwanted configuration using a <Delete> operation and then add the new

configuration using a <Set> operation. An explicit replace option is not supported. For more

information on replacing the configuration, see “Replacing the Current Running Configuration”

section on page 2-44.

• Applying the configuration for a trial period (“try-and-apply”) is not be supported for this release.

• If the client application never commits, the target configuration is automatically destroyed when the

client session is terminated. No other timeouts are supported.

Commit Errors

If any configuration entered into the target configuration fails to makes its way to the running

configuration as the result of a <Commit> operation (for example, the configuration contains a semantic

error and is therefore rejected by a back-end application’s verifier function), then all of the failed

configuration is returned in the <Commit> response along with the appropriate ErrorCode and

ErrrorMsg attributes indicating the cause of each failure.

The OperationType attribute is used to indicate whether the failure was a result of a requested <Set> or

<Delete> operation. In the case of a <Set> operation failure, the value to be set is included in the commit

response.

The following example shows <Set> and <Delete> operations to modify the BGP configuration followed

by a <Commit> request resulting in failures for both requested operations. This request corresponds to

the following CLI commands:

router bgp 4

default-metric 10

exit

commit

Sample XML Client Request to Modify the Target Configuration

<?xml version="1.0" encoding="UTF-8"?>

<Set>

<AS>