- Preface
- Cisco XML API Overview
- Cisco XML Router Configuration and Management
- Cisco XML Operational Requests and Fault Management
- Cisco XML and Native Data Operations
- Cisco XML and Native Data Access Techniques
- Cisco XML and Encapsulated CLI Operations
- Cisco XML and Large Data Retrieval
- Cisco XML Security
- Cisco XML Schema Versioning
- Alarms
- Error Reporting in Cisco XML Responses
- Summary of Cisco XML API Configuration Tags
- Cisco XML Transport and Event Notifications
- Cisco XML Schemas
- Network Configuration Protocol
- Cisco IOS XR Perl Scripting Toolkit
- Sample BGP Configuration
- Glossary
- Index
Cisco XML Operational Requests and Fault Management
A client application can send an XML request to get router operational information using either a native data <Get> request along with the <Operational> tag, or the equivalent CLI command. Although the CLI is more familiar to users, the advantage of using the <Get> request is that the response data is encoded in XML format instead of being only uninterpreted text enclosed within <CLI> tags.
This chapter contains these sections:
Operational Get Requests
The content and format of operational <Get> requests are described in additional detail in Chapter 4, "Cisco XML and Native Data Operations."
This example shows a <Get> request to retrieve the global Border Gateway Protocol (BGP) process information. This request returns BGP process information similar to that displayed by the show ip bgp process detail CLI command.
Sample XML Client Request to Get BGP Information
<?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Get>
<Operational>
<BGP>
<Active>
<DefaultVRF>
<ProcessInfoTable/>
</DefaultVRF>
</Active>
</BGP>
</Operational>
</Get>
</Request>
Sample XML Response from the Router
<?xml version="1.0" encoding="UTF-8"?>
<Response MajorVersion="1" MinorVersion="0">
<Get>
<Operational>
<BGP MajorVersion="22" MinorVersion="2">
<Active>
<ProcessInfoTable>
<ProcessInfo>
<Naming>
<ProcessID>0</ProcessID>
</Naming>
<ProcessInstance>
0
</ProcessInstance>
....
more response content here
...
</ProcessInfo>
</ProcessInfoTable>
</Active>
</BGP>
</Operational>
</Get>
<ResultSummary ErrorCount="0"/>
</Response>
Action Requests
A client application can send a <Set> request along with the <Action> tag to trigger unique actions on the router. For example, an object may be set with an action request to inform the router to clear a particular counter or reset some functionality. Most often this operation involves setting the value of a Boolean object to "true".
This example shows an action request to clear the BGP performance statistics information. This request is equivalent to the clear bgp performance-statistics CLI command.
Sample XML Request to Clear BGP Performance Statistics Information
<?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Set>
<Action>
<BGP>
<DefaultVRF>
<ClearPerformanceStats>true</ClearPerformanceStats>
</DefaultVRF>
</BGP>
</Action>
</Set>
</Request>
Sample XML Response from the Router
<?xml version="1.0" encoding="UTF-8"?>
<Response MajorVersion="1" MinorVersion="0">
<Set>
<Action/>
</Set>
<ResultSummary ErrorCount="0"/>
</Response>
In addition, this example shows an action request to clear the peer drop information for all BGP neighbors. This request is equivalent to the clear bgp peer-drops * CLI command.
Sample XML Request to Clear Peer Drop Information for All BGP Neighbors
<?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Set>
<Action>
<BGP>
<DefaultVRF>
<ClearDrops>
<All>true</All>
</ClearDrops>
</DefaultVRF>
</BGP>
</Action>
</Set>
</Request>
Sample XML Response from the Router
<?xml version="1.0" encoding="UTF-8"?>
<Response MajorVersion="1" MinorVersion="0">
<Set>
<Action/>
</Set>
<ResultSummary ErrorCount="0"/>
</Response>
Cisco XML and Fault Management
When a client application successfully commits the target configuration to the router's running configuration, the configuration manager writes a single configuration change event to system message logging (syslog). As a result, a fault management event notification is written to the Alarm Channel and subsequently forwarded to any registered configuration agents.
Configuration Change Notification
Table 3-1 provides event notification for configuration changes information.
This example shows a configuration change notification:
RP/0/RP0/CPU0:Sep 18 09:43:42.747 : %CLIENTLIBCFGMGR-6-CONFIG_CHANGE : A configuration commit by user root occurred at 'Wed Sep 18 09:43:42 2004 '. The configuration changes are saved on the router in file: 010208180943.0
Upon receiving the configuration change notification, a client application can then use the <Load> and <Get> operations to load and browse the changed configuration.