Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

• Every Web Services Management Agent (WSMA) agent must be associated with a WSMA profile to perform any operations. Otherwise, the WSMA agents cannot send or receive any messages.

• WSMA over Secure Shell Version 2 (SSHv2) requires that a vty line be available for each WSMA session.

• Secure Shell Version 1 (SSHv1) is not supported; only SSHv2 is supported.

• You must be running a crypto image in order to configure SSH or Secure HTTP (HTTPS).

• Notification services are not supported for Web Services Management Agent (WSMA) over HTTP in listener mode.

• WSMA keepalive messages must be configured for config, exec, and filesys services for WSMA over HTTP in initiator mode.

Web Services Management Agent (WSMA) is a family of embedded agents used by an external point-to-point management application to fully manage a Cisco networking device.

The Configuration WSMA agent provides services to change the configuration on Cisco devices and validates and applies a set of configuration commands to Cisco software. Any noninteractive configuration CLI command that can be applied using the Cisco console can also be applied using this WSMA. This service is available for all configuration CLI commands on the Cisco device. It treats a set of commands as a single operation.

Three types of configuration requests can occur:

• configTest—validates the syntax of the configuration data but does not apply the data to the running configuration.

• configApply—modifies the running configuration with the supplied configuration data. Use the action-on-fail attribute to specify the error handling to perform if an error is encountered when applying the configuration. The level of error information returned in the response can be controlled using the details attribute.

• configPersist—copies the running configuration to the startup configuration so that it persists across reloads.

The configuration WSMA service allows you to specify the CLI commands using either the XML Programmatic Interface (XML-PI) mode, or as direct CLI commands. Configuration WSMA service requests use the following modes and attributes:

• block mode—use the <cli-config-data-block> tag to encapsulate a multiline block of CLI commands.

• cmd mode—use the <cli-config-data> tag to encapsulate a block of configuration settings where each CLI line is individually delimited by <cmd> tags.

• XML-PI mode—use the <xml-config-data> tag to encapsulate processing instructions. This format is compatible with Cisco Enhanced Device Interface (EDI).

• action-on-fail—use this attribute to specify the action to perform when an error is encountered. You can specify the following action values:

  • stop—stops the execution on the first error but preserves the system state. If the execution is stopped, the configuration could be partially applied.
  • continue—ignores errors and continues implementing instructions.
  • rollback—stops processing at the first error and restores the configuration to the state before any configuration was applied. The rollback action value is enabled only if the archive command is configured.
• details—Use this attribute to control the level of error details. You can specify one of the following values:

  • brief—provides minimal detail in error responses.
  • errors—provides details on all error encountered.
  • all—provides the maximum level of details on errors.

Web Services Management Agent (WSMA) is a family of embedded agents used by the point-to-point management application to fully manage a device.

The EXEC WSMA provides services to retrieve operational data from the Cisco device and handles EXEC mode command-line operations such as show commands and other diagnostic commands on Cisco devices. Interactive EXEC commands have Expect and Response tags to allow you to configure the exchange sequence. The service can retrieve show command operational data in XML-Progammatic Interface (PI) format and it allows remote reloading of the Cisco device.

EXEC WSMA service requests consist of a single EXEC mode command encapsulated in an <execCLI> tag with the following tags and attributes:

• execTest—validates the syntax of the EXEC command but does not run the command.

• maxWait—the maximum time to accumulate data and wait for the EXEC command to complete. Once the interval expires the operation stops and all accumulated data is sent in the response.

• maxResponseSize—the maximum number of bytes allowed in the body of the response. The default is 0 (infinity), and the range is 0 to 2³¹ – 1. If the response exceeds the specified size, the operation stops and all accumulated data is sent in the response.

• format—returns the results of EXEC commands in XML-PI format. You must specify the path to the spec file on the Cisco file system. To use the global spec file command in the Cisco file system and still return XML-PI format results use the attribute format="".

• xsd—sends the XML schema of the EXEC command instead of the output of the EXEC command when this value is set to 1.

• cmd—this mandatory tag contains the EXEC command to run.

• dialogue—this optional tag is used only for interactive EXEC commands. It specifies an expect and reply sequence. It includes a repeat attribute that is used if there are multiple identical expect and reply sequences.

• expect—the prompt the system expects. The value need not be an exact match to the specified string. The string match has two attributes:

  • caseSensitive—set this attribute to true to do case-sensitive match. The default is to be case-sensitive.
  • match—set to leading, trailing, embedded, or exact. The defaul is an exact match.

• reply—the answer to the prompt if it matches.

The order and number of the dialog elements must match the actual prompts seen or the EXEC call will fail. All dialogs must be run, otherwise an error message is seen.

Web Services Management Agent (WSMA) is a family of embedded agents used by an external point-to-point management application to fully manage a Cisco networking device.

The Filesystem WSMA service provides services to manage files on the Cisco device. It copies and validates files between local and remote file systems. This agent can be used to list directories, upgrade the software image running on the device, and delete files. File copies can be validated using a Message Digest 5 (MD5) checksum if available.

There are three types of Filesystem requests:

• fileList—provides a directory listing.

• fileDelete—specifies a list of files to be deleted using the deleteFileList tag.

• fileCopy—enables the copying of files to and from the local file system. The file is copied outside of the WSMA transport mechanism using the protocol specified in the srcURL and dstURL attributes. This copy process is similar to copying a file using the EXEC CLI shell. However, this process performs additional validation checks that are not available in the EXEC shell.

The fileCopy request option has the following attributes:

• filesize—This mandatory attribute is the number of bytes to be copied. If the filesize attribute does not match the size of the copied file, the operation fails.

• erase—This mandatory attribute is a Boolean True/False. If this attribute is set to TRUE, the file system is erased before the filecopy operation is performed. This attribute is useful where the new image does not fit on the disk.

• overwrite—This mandatory attribute is a Boolean True/False. If this attribute is set to TRUE, the current file on the file system is overwritten by the new file being copied.

• retries—This optional attribute specifies the number of times the file copy is attempted in the absence of a permanent failure.

• retry-interval—This optional attribute specifies the time interval between a fileCopy retry. The default is 10 seconds.

The fileCopy request option has the following tags:

• srcURL—Specifies the URL and protocol to use for the file transfer.

• dstURL—Specifies the URL of the location to which the file is copied.

• validationInfo—Specifies an optional MD5 checksum to provide additional security during downloading.

• deletefFilelist—Specifies an optional tag that is the same as fileDelete. The fileList is deleted before the copy starts.

There are three types of Filesystem responses:

• fileSystemList—This response is a listing of every disk, directory, and file on the device. This response also includes additional information such as name, size, and flags. You can use this information to calculate the used and free space on the device to assist image download.

• fileDeleteStatus—This response provides an itemized response to the delete file request and displays the status of each file in the list and whether or not the file was deleted.

• fileCopyStatus—This response provides a report on whether the copy succeeded or failed. Success is indicated by an empty body with the success attribute set to 1 if the request succeeded.

The errorInfo response is seen only if the operation fails. The errorInfo response returns an error string of the error encountered that contains two error fields: errorCode and errorMessage.

The errorCode response details the possible error types and can include:

• BAD_PARAMETER—Indicates that at least one of the parameters on the request is invalid.

• INTERNAL_ERROR—Indicates that an unknown internal API error occurred.

• NO_MEMORY—Indicates that the system has run out of memory.

• OPERATION_FAILED—Indicates that the operation did not complete. The error message provides details.

• NO_MEMORY—Indicates that memory allocation failed.

• PERMISSION_DENIED—Indicates that authorization failed.

Web Services Management Agent (WSMA) is a family of embedded agents used by an external point-to-point management application to fully manage a Cisco networking device.

The Notification WSMA service collects configuration-change events and forwards the details to the management application that has subscribed to get the notifications.

Multiple management applications can receive the notifications by connecting to a listener profile. Each management application must explicitly subscribe to the notifications and can turn notification on or off on the profile without affecting the operation of other connected management applications. If a connection drops notifications are turned off.

Notifications are not cached or stored. If no management application is connected when an event happens then there is no record of that event.

Notification requests have three attributes:

• correlator—used to coordinate the acknowledgment to the request.

• type—a string representing the types of notifications to enable on the session. The only supported string is configChange.

• activate—turns notification on or off by sending the value 0 (off) or 1 (on).

Notification responses have the following attributes:

Web Services Management Agent (WSMA) is a family of embedded agents used by the point-to-point management application to fully manage a device.

When a new WSMA session is established, the Cisco device sends a Hello message containing the WSMA ID and a list of WSMA services available on the session. The remote management application can query this information by sending a WSMA Hello request to the Cisco device.

This service is enabled by default on every WSMA profile.

Web Services Management Agent (WSMA) is a family of embedded agents, used by the point-to-point management application to fully manage a device.

If a WSMA profile is configured to use keepalive messages, and if no WSMA service request has been received for the configured keepalive interval, the Cisco device sends a Keepalive request on the WSMA session. If the number of keepalive requests sent exceeds the configured retries, the WSMA session is closed.

A keepalive request has one attribute, correlator. The correlator attribute is a number that starts at 1 and increments each time a keepalive request is sent on a session. The correlator value used in a keepalive response must match the value in a keepalive request.

Web Services Management Agent (WSMA) needs input from external management applications to cause actions on the device. A physical transport protocol must be configured and associated to a WSMA to allow the WSMA to communicate with external management applications. The transport protocol and an encapsulation together form a WSMA profile. Any WSMA agent must be associated with a specific WSMA profile to perform valid operations. WSMA profiles demultiplex requests to the appropriate WSMA.

WSMA profiles work as a transport termination point and allow transport and XML encapsulation parameters to be configured:

• The configurable encapsulations for WSMA are Simple Object Access Protocol (SOAP )1.1 and SOAP 1.2.

• The transportation mechanisms for WSMA are Secure Shell (SSH), HTTP, and Secure HTTP (HTTPS). This mechanism opens listening sockets for listeners on the device or connecting sockets for clients on the device.

The service listener is a type of Web Services Managment Agent (WSMA) profile that listens for incoming connections and accepts devices from allowed addresses or accepted user IDs. Define an access list to configure accepted addresses.

Configure accepted user IDs by defining the transport method that the service listener listens for. The transport method (Secure Shell (SSH), HTTP, or Secure HTTP [HTTPS]) enforces the specific user ID that is accepted.

Note	WSMA listener profiles cannot access Cisco devices that are located behind a firewall.

The service initiator is a type of Web Services Management Agent (WSMA) profile that initiates secure connections from Cisco devices to management applications over trusted and untrusted networks.

The service initiator creates a dynamic socket that attempts to stay connected to a configured server address. Each initiator can be configured with retry, keepalive, timeout, and reconnect settings. In addition, each initiator can specify a backup connection to use if the primary connection fails.

The service initiator allows WSMA to initiate connections to devices behind a firewall or Network Address Translation (NAT), and in Zero Touch Deployment (ZTD) networks.

Simple Object Access Protocol (SOAP) is an industry-standard protocol to exchange XML data between applications. It defines a common mechanism to handle corrupted XML messages. It has a header mechanism to collate metadata associated with a transaction.

SOAP 1.1 and SOAP 1.2 have different schema definitions. They can coexist with no impact on the other. Cisco software has both SOAP 1.1 and SOAP 1.2 libraries. SOAP has mechanisms to handle XML framing and operational errors in a generic manner, allowing greater interoperability of XML-based applications.

To run the WSMA over SSHv2 feature, the Web Services Management Agent (WSMA) agent must be configured to use a service profile that is using Secure Shell (SSH) as a transport method. The figure below shows a basic WSMA over SSHv2 network configuration. The client and server exchange keys for security and password encryption. The user ID and password of the SSHv2 session running WSMA are used for authorization and authentication purposes. The user privilege level is enforced and the client session may not have full access to the WSMA operations if the privilege level is not high enough. If authentication, authorization, and accounting (AAA) is configured, the AAA service is used as if a user had established an SSH session directly to the device. Using the existing security configuration makes the transition to WSMA almost seamless. Once the client has been successfully authenticated, the client invokes the SSH connection protocol and the SSH session is established. After the SSH session is established, the user or application invokes WSMA as an SSH subsystem. The default name for the subsystem is “wsma.”

Figure 1. WSMA over SSHv2

SSHv2

SSHv2 runs on top of a reliable transport layer and provides strong authentication and encryption capabilities. SSHv2 provides a means to securely access and securely execute commands on another computer over a network.

Service listeners do not support SSHv1. The configuration for the SSHv2 server is similar to the configuration for SSHv1. Use the ip ssh version command to specify which version of SSH you want to configure. If you do not configure this command, SSH by default runs in compatibility mode; that is, both SSHv1 and SSHv2 connections are honored.

Note	SSHv1 is a protocol that has never been defined in a standard. If you do not want your device to fall back to the undefined protocol (version 1), you should use the ip ssh version command and specify version 2.

Use the ip ssh rsa keypair-name command to enable an SSH connection using Rivest, Shamir, and Adelman (RSA) keys that you have configured. If you configure the ip ssh rsa keypair-name command with a key-pair name, SSH is enabled if the key pair exists, or SSH will be enabled if the key pair is generated later. If you use this command to enable SSH, you need not configure a hostname and a domain name.

To run the WSMA over HTTP feature, you must configure the Web Services Management Agent (WSMA) agent to use a service profile that is using either HTTP or Secure HTTP (HTTPS) as a transport. For HTTPS, the client and server exchange keys for security and password encryption. The user ID and password of the HTTP or HTTPS session running WSMA are used for authorization and authentication purposes. The user privilege level is enforced and the client session may not have full access to the WSMA operations if the privilege level is not high enough. If authentication, authorization, and accounting (AAA) is configured, the AAA service is used as if a user had established an SSH session directly to the device. Using the existing security configuration makes the transition to WSMA almost seamless. After the HTTP or HTTPS session is established, the user or application invokes WSMA as an HTTP path. The default name for the path is “/wsma.”

When you use HTTP as the transport for a initiator profile, the WSMA Notification service is available without additional configuration. However, to use the config, exec, and filesys services, you must first configure keepalive messages on the initiator profile. When keepalive messages are configured, the Cisco device can periodically send a request to the remote WSMA application, which allows the remote HTTP server the opportunity to send a WSMA request.

When you use HTTP as the transport for a listener profile, the WSMA Notification service is not supported since the Cisco device acting as a HTTP server cannot send HTTP requests, it can only respond to HTTP requests.

The Web Services Management Agent (WSMA) IDs allow Cisco networking devices to have unique IDs. Unique IDs are important in a Network Address Translation (NAT) or Dynamic Host Configuration Protocol (DHCP) network where all the device IP addresses are locally significant. In this type of deployment, the WSMA ID can be used to give each device a globally unique ID.

The WSMA ID can be explicitly configured based on other properties of the device such as:

• The hardware serial number

• The hostname

• The IP address of an interface

• The MAC address of an interface

• A user-defined string

Whenever the WSMA ID changes, all WSMA sessions are disconnected to protect the management applications from synchronizing the state dynamically.

Web Services Management Agent (WSMA) security is integrated with authentication, authorization, and accounting (AAA) configuration of Cisco software. The AAA associations configured on the transport layer are used by the WSMA.

WSMA is designed for point-to-point operation and works over an encrypted transport. The security on the transport layer identifies and authenticates the users.

Each Web Services Management Agent (WSMA) service publishes its XML schema. The schema describe the XML messages that the specific WSMA service can understand and execute. The WSMA schema define the entire data required to execute an operation and ensure operations can be performed identically regardless of the type of transport used to carry the message.

Wireless WebUI allows you to monitor and configure the wireless features. WSMA configurations are required to enable wireless WebUI. When WebUI sends a request, WSMA, parser, and AAA components process and authorize WebUI requests.

1.    enable


2.    configure terminal


3.    hostname hostname


4.    ip domain-name name


5.    crypto key generate rsa


6.    ip ssh [timeout seconds | authentication-retries integer]


7.    ip ssh version 2


8.    end

Device> enable

Device# configure terminal

Device(config)# hostname host1

Device(config)# ip domain-name example.com

Device(config)# crypto key generate rsa

Device(config)# ip ssh timeout 120

Device(config)# ip ssh version 2

Device(config)# end

1.    enable


2.    configure terminal


3.    ip http server


4.    ip http authentication {aaa | local}

Device> enable

Device# configure terminal

Device(config)# ip http server

Device(config)# ip http authentication aaa

1.    enable


2.    show ip http server status


3.    configure terminal


4.    no ip http server


5.    ip http secure-server


6.    ip http secure-port port-number


7.    ip http secure-ciphersuite [3des-ede-cbc-sha] [rc4-128-sha] [rc4-128-md5] [des-cbc-sha]


8.    ip http secure-client-auth


9.    ip http secure-trustpoint name


10.    end


11.    show ip http server secure status

Device> enable

Device# show ip http server status

Device# configure terminal 

Device(config)# no ip http server

Device(config)# ip http secure-server

Device(config)# ip http secure-port 1025

Device(config)# ip http secure-ciphersuite rc4-128-sha rc4-128-md5 

Device(config)# ip http secure-client-auth

Device(config)# ip http secure-trustpoint trustpoint-01

Device(config)# end

Device# show ip http server secure status

1.    enable


2.    show ssh


3.    show ip ssh

Device> enable

Device# show ssh

Device# show ip ssh

Device# show ssh

Connection Version Mode Encryption  Hmac                State          
Username
1          2.0     IN   aes128-cbc  hmac-md5     Session started       lab
1          2.0     OUT  aes128-cbc  hmac-md5     Session started       lab
%No SSHv1 server connections running.

Device# show ip ssh

SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

1.    enable


2.    configure terminal


3.    wsma profile initiator profile-name


4.    encap {soap11 | soap12}


5.    [backup] transport {http | https | ssh remote-host [initiator-port-number] path path-name [user username [0 | 6] password] } | source source-interface}


6.    keepalive seconds [retries number]


7.    idle-timeout minutes


8.    max-message message-size


9.    backup hold minutes


10.    backup excluded seconds


11.    reconnect seconds


12.    stealth


13.    wsse


14.    end

Device> enable

Device# configure terminal

Device(config)# wsma profile initiator prof1

Device(config-wsma-init)# encap soap12

Device(config-wsma-init)# transport ssh sshserver path
/mypath/bin/mywsma-app.sh user user1 6 encrypted-password

Device(config-wsma-init)# keepalive 100 retries 10

Device(config-wsma-init)# idle-timeout 345

Device(config-wsma-init)# max-message 290

Device(config-wsma-init)# backup hold 233

Device(config-wsma-init)# backup excluded 30

Device(config-wsma-init)# reconnect 434

Device(config-wsma-init)# stealth

Device(config-wsma-init)# wsse

Device(config-wsma-init)# end

1.    enable


2.    configure terminal


3.    wsma profile listener profile-name


4.    encap {soap11 | soap12}


5.    transport {http | https [path pathname] | ssh [subsys subsys-name]}


6.    idle-timeout minutes


7.    max-message message-size


8.    keepalive seconds [retries number]


9.    acl acl-number


10.    stealth


11.    wsse


12.    end

Device> enable

Device# configure terminal

Device(config)# wsma profile listener prof1

Device(config-wsma-listen)# encap soap12

Device(config-wsma-listen)# transport ssh subsys wsma

Device(config-wsma-listen)# idle-timeout 345

Device(config-wsma-listen)# max-message 290

Device(config-wsma-listen)# keepalive 100 retries 10

Device(config-wsma-listen)# acl 34

Device(config-wsma-listen)# stealth

Device(config-wsma-listen)# wsse

Device(config-wsma-listen)# end

1.    enable


2.    configure terminal


3.    wsma agent {config | exec | filesys | notify} profile profile-name

Device> enable

Device# configure terminal

Device(config)# wsma agent config profile prof1

1.    enable


2.    configure terminal


3.    wsma id {hardware-serial | hostname | ip-address interface/type | mac-address interface/type | string value}

Device> enable

Device# configure terminal

Device(config)# wsma id ip-address fastethernet 0/1

1.    enable


2.    show wsma agent [config | exec | filesys | notify] {counters | schema}


3.    debug wsma agent [config | exec | filesys | notify]


4.    clear wsma agent [config | exec | filesys | notify] counters

Device> enable

Device# show wsma agent config counters

Device# debug wsma agent config

Device# clear wsma agent filesys counters

Device# show wsma agent counters

WSMA Exec Agent Statistics:
messages received 0, replies sent 0, faults 0
WSMA Config Agent Statistics:
messages received 4, replies sent 4, faults 0
WSMA Filesys Agent Statistics:
messages received 1, replies sent 1, faults 0
WSMA Notification Agent Statistics:
config silent
messages received 0, replies sent 0, notifications sent 0, faults 0

Device# show wsma agent config schema

New Name Space 'urn:cisco:wsma-config'
<VirtualRootTag> [0, 1] required
  <WSMA-Config> [0, 1] required
    <request> 1 required
      <config-data> 1 required
        <cli-config-data> [0, 1] required
          <cmd> 1+ required
        <cli-config-data-block> [0, 1] required
        <xml-config-data> [0, 1] required
          <Device-Configuration> [0, 1] required
            <> any subtree is allowed

1.    enable


2.    show wsma profile [name profile-name] {connections | counters | schema}


3.    debug wsma profile [listener | initiator]


4.    clear wsma profile [profile-name] {connections | counters}

Device> enable

Device# show wsma profile connections

Device# debug wsma profile listener 

Device# clear wsma profile prof1 counters

An XML payload is typically wrapped in a Simple Object Access Protocol (SOAP) message for data transportation. Without a correct design of SOAP messages, an XML payload may not be exchanged properly even if the payload follows a common XML schema. The XML payload over all transports is identical. Web Services Management Agent (WSMA) supports both SOAP1.1 and SOAP1.2. The SOAP header supports two modes of security, no wsse and wsse.

Use the following XML schema to deliver WSMA payloads:

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<request xmlns="urn:cisco:wsma-exec" correlator="01">
				<execCLI>
					<cmd>ping oz-dirt</cmd>
				</execCLI>
			</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-exec" correlator="01" success="1">
				<execLog>
					<dialogueLog>
						<sent>ping oz-dirt</sent>
						<received>Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms</received>
					</dialogueLog>
				</execLog>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<request xmlns="urn:cisco:wsma-config" correlator="4.1">
				<configApply details="all">
					<config-data>
						<cli-config-data>
							<cmd>no cns config partial mixy</cmd>
							<cmd>no stupid</cmd>
							<cmd>no cns exec 80 </cmd>
						</cli-config-data>
					</config-data>
				</configApply>
			</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-config" correlator="4.1" success="1">
				<resultEntry lineNumber="1" cliString="no cns config partial mixy">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
      <resultEntry lineNumber="2" cliString="no stupid">
					<failure errorType="TEMPORARY" errorCode="PARSE_ERROR_NOMATCH" />
				</resultEntry>
				<resultEntry lineNumber="3" cliString="no cns exec 80 ">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
		<request xmlns="urn:cisco:wsma-config" correlator="5.1">
			<configApply details="all">
				<config-data>
					<cli-config-data-block>no cns config partial mixy
no stupid
no cns exec 80</cli-config-data-block>
				</config-data>
			</configApply>
		</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-config" correlator="5.1" success="1">
				<resultEntry lineNumber="1" cliString="no cns config partial mixy">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
				<resultEntry lineNumber="2" cliString="no stupid">
					<failure errorType="TEMPORARY" errorCode="PARSE_ERROR_NOMATCH" />
				</resultEntry>
				<resultEntry lineNumber="3" cliString="no cns exec 80">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<request xmlns="urn:cisco:wsma-config" correlator="6.1">
			<configApply details="all">
				<config-data>
					<xml-config-data>
						<Device-Configuration><cns operation="delete" > <config><partial>
<HostNameAddressConfigurationServer>mixy</HostNameAddressConfigurationServer>
<PortNumberConfigServiceDefault80>80</PortNumberConfigServiceDefault80></partial></config></cns>
<stupid operation="delete" /><cns operation="delete" ><exec><P>80</P></exec></cns> </Device-Configuration>
						</xml-config-data>
					</config-data>
				</configApply>
			</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-config" correlator="6.1" success="1">
				<resultEntry lineNumber="1" cliString="no cns config partial mixy 80">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
				<resultEntry lineNumber="2" cliString="no stupid">
					<failure errorType="TEMPORARY" errorCode="PARSE_ERROR_NOMATCH" />
				</resultEntry>
				<resultEntry lineNumber="3" cliString="no cns exec 80">
					<success change="NO_CHANGE" mode="IMMEDIATE" />
				</resultEntry>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
		<request xmlns="urn:cisco:wsma-filesystem" correlator="2"><fileList/></request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]> 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
		<response xmlns="urn:cisco:wsma-filesystem" correlator="2" success="1">
			<fileSystemList>
				<fileSystem name="nvram" type="nvram" size="522232" freespace="516471" readable="true" writeable="true">
					<directory name="/" fullName="nvram:/" readFlag="true" writeFlag="true">
						<file name="startup-config" fullName="nvram:/startup-config" size="2134" readFlag="true" writeFlag="true"/>
						<file name="private-config" fullName="nvram:/private-config" size="1527" readFlag="false" writeFlag="false"/>
						<file name="underlying-config" fullName="nvram:/underlying-config" size="2134" readFlag="true" writeFlag="true"/>
						<file name="persistent-data" fullName="nvram:/persistent-data" size="99" readFlag="false" writeFlag="false"/>
						<file name="ifIndex-table" fullName="nvram:/ifIndex-table" size="0" readFlag="true" writeFlag="true"/>
					</directory>
				</fileSystem>
				<fileSystem name="disk2" type="disk" size="64229376" freespace="63987712" readable="true" writeable="true">
					<directory name="/" fullName="disk2:/" readFlag="true" writeFlag="true" modDate="1979-11-30T00:00:00.000Z">
						<file name="spec.odm" fullName="disk2:/spec.odm" size="131739" readFlag="true" writeFlag="true" modDate="2007-08-31T05:11:36.000Z"/>
					</directory>
				</fileSystem>
				<fileSystem name="bootflash" type="flash" size="14942208" freespace="8455208" readable="true" writeable="true">
					<directory name="/" fullName="bootflash:/" readFlag="true" writeFlag="true">
						<file name="c7200-kboot-mz.bw" fullName="bootflash:/c7200-kboot-mz.bw" size="5131872" readFlag="true" writeFlag="true" modDate="1999-11-30T00:01:47.000Z"/>
						<file name="startup-config.base" fullName="bootflash:/startup-config.base" size="1808" readFlag="true" writeFlag="true" modDate="1999-11-30T00:23:26.000Z"/>
						<file name="startup-config.12dec03.balam" fullName="bootflash:/startup-config.12dec03.balam" size="1598" readFlag="true" writeFlag="true" modDate="2000-01-05T22:54:50.000Z"/>
					</directory>
				</fileSystem>
			</fileSystemList>
		</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]> 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<request xmlns="urn:cisco:wsma-filesystem" correlator="12">
				<fileCopy erase="0" overwrite="1" filesize="131739">
					<srcURL>tftp://oz-dirt/jbalestr/spec.odm</srcURL>
					<dstURL>test</dstURL>
				</fileCopy>
			</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]> 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-filesystem" correlator="12" success="1">
				<copyStatus></copyStatus>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]> 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<request xmlns="urn:cisco:wsma-filesystem" correlator="6">
				<fileDelete>
					<deleteFileList>
						<filename>brick</filename>
					</deleteFileList>
				</fileDelete>
			</request>
	</SOAP:Body>
</SOAP:Envelope>]]>]]> 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<SOAP:Body>
			<response xmlns="urn:cisco:wsma-filesystem" correlator="6" success="1">
				<deleteStatusList>
					<deleteStatus>
						<fileName>brick</fileName>
						<status>DELETED</status>
					</deleteStatus>
				</deleteStatusList>
			</response>
	</SOAP:Body>
</SOAP:Envelope>]]>]]>

SSHv2—Secure Shell Version 2. SSH runs on top of a reliable transport layer and provides strong authentication and encryption capabilities. SSHv2 provides a means to securely access and securely execute commands on another computer over a network.

WSMA—Web Services Management Agent. A protocol that defines a set of web services through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated.

XML—Extensible Markup Language. A standard maintained by the World Wide Web Consortium (W3C) that defines a syntax that lets you create markup languages to specify information structures. Information structures define the type of information (for example, subscriber name or address), not how the information looks (bold, italic, and so on). External processes can manipulate these information structures and publish them in a variety of formats. XML allows you to define your own customized markup language.