Guía de Configuración de Administración de Redes de Cisco IOS, Versión 12.2SR
XML-PI
2 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 301 KB | Inglés (11 Julio 2008) | Comentarios

Contenidos

XML-PI

Encontrar la información de la característica

Contenido

Requisitos previos para XML-PI

Restricciones para XML-PI

Información sobre XML-PI

Descripción XML-PI

Descripción NETCONF

Mejoras NETCONF

Mejora para extraer la salida de los ejecutar-config de la demostración

Mejora para cambiar la configuración corriente

Mejora para extraer los comandos show

Herramienta ODM y archivos espec.

Algoritmos de la conversión XML-CLI

Algoritmo X2C

Algoritmo C2X

Cómo utilizar XML-PI

Configurar NETCONF para XML-PI

Generación del formato XML para los comandos

Generación del formato XSD para los comandos

Localización de averías de los errores ODM

Manejo de los archivos

Visualizar los archivos en un filesystem del Cisco IOS: Ejemplo:

Manejo de los archivos espec.

Validar los archivos espec.

Restricciones

Ejemplos de configuración para XML-PI

Ejemplo: Configurar NETCONF para XML-PI

Ejemplos: Generación del formato XML del comando show

Ejemplos: Generación del formato XML de los ejecutar-config de la demostración

Ejemplo: Generación del formato del comando show XSD

Ejemplo: Visualizar el SFEs

Ejemplo: Visualizar la jerarquía de la etiqueta del archivo espec.

Ejemplo: Validar un archivo espec.

Referencias adicionales

Documentos Relacionados

Estándares

MIB

RFC

Asistencia Técnica

Información de la característica para XML-PI

Glosario


XML-PI


Primera publicación: De julio el 11 de 2008
Última actualización: De junio el 28 de 2010

La versión 1,0 de la interfaz programática del Lenguaje de marcado extensible (XML-PI) leverages el protocolo de la configuración de red (NETCONF) y modelos de datos de las ofertas los nuevos que recojan show la salida de comando abajo a la palabra clave llana y a las configuraciones corrientes sin la complejidad y el costo de las Tecnologías pantalla-que raspan o de los gatewayes externos de la interfaz de línea del XML-a-comando (CLI). XML-PI permite que usted desarrolle rápidamente las aplicaciones de administración de red XML basadas que adaptan y controlan remotamente el comportamiento de cualquier número de dispositivos de red simultáneamente. XML-PI utiliza un protocolo del estándar de la industria que permita que los dispositivos de red de Cisco sean manejados de una manera más automática y más programática y sea CLI accesible.

Encontrar la información de la característica

Su versión de software puede no soportar todas las características documentadas en este módulo. Para la últimas información y advertencias de la característica, vea los Release Note para su plataforma y versión de software. Para encontrar la información sobre las características documentadas en este módulo, y ver una lista de las versiones en las cuales se soporta cada característica, vea “información de la característica para la sección XML-PI”.

Utilice el Cisco Feature Navigator para encontrar la información sobre el soporte del Soporte de la plataforma y de la imagen del software de Cisco. Para acceder a Cisco Feature Navigator, vaya a http://www.cisco.com/go/cfn. Una cuenta en el cisco.com no se requiere.

Contenido

Requisitos previos para XML-PI

Restricciones para XML-PI

Información sobre XML-PI

Cómo utilizar XML-PI

Ejemplos de configuración para XML-PI

Referencias adicionales

Información de la característica para XML-PI

Glosario

Requisitos previos para XML-PI


La notaesté segura que usted tiene bastantes líneas configuradas para los dispositivos de red que usted recogerá la salida de comando de. XML-PI requiere que usted configure por lo menos dos líneas del vty por la sesión NETCONF para manejar el formato.


Usted debe ser familiar con NETCONF y la guía del programador para el Cisco Enhanced Device Interface 2,2.

Usted debe ser familiar con el Protocolo de configuración del RFC 4741, NETCONF y el RFC 4742, usando el Protocolo de configuración NETCONF sobre el Secure Shell (SSH).

NETCONF y el shell seguro versión 2 (SSHv2) son ambos requeridos para ejecutar XML-PI. SSHv2 es el único Transport Protocol soportado para la versión 1,0 XML-PI. Junto, NETCONF y SSHv2 terminan la capa de sesión y proporcionan una conexión segura. Vea el documento del protocolo de la configuración de red para los requisitos previos adicionales y la información sobre NETCONF y SSHv2.

Restricciones para XML-PI

XML-PI soportado solamente en los archivos de imagen de criptografía

El uso de NETCONF y de SSHv2 con las funciones XML-PI se soporta solamente en las imágenes de reforma crypto del Cisco IOS, tales como IPBASEK9. Utilice el Cisco Feature Navigator para encontrar la información sobre la plataforma y el software support para las imágenes crypto de la Seguridad del Cisco IOS; vea “la sección de la información de la característica del hallazgo” en este documento para más información sobre el navegador de la característica.

Los archivos espec. deben ser locales

Los archivos espec. (descritos en la “herramienta ODM y espec. clasifía” la sección) deben residir localmente en el dispositivo de red. Usando los archivos espec. de un filesystem remoto no se soporta.

XML-PI y NETCONF

Hay dos maneras que XML-PI puede entregar el XML hecho salir show de los comandos: usando NETCONF o vía el CLI de Cisco de la consola. En caso de que el acceso NON-CLI a XML-PI sea deseable, sólo NETCONF se puede utilizar para extraer show la salida de comando.

Los cambios de configuración usando XML-PI se pueden hacer solamente usando NETCONF. El XML no se puede ingresar directamente en la consola CLI.

El Cisco IOS que ejecuta la configuración se puede extraer de la consola ejecutando show running-config | format comando, además de estar disponible vía NETCONF.

Syntax Check no se soporta

La operación del <edit-config> puede no trabajar correctamente.

Respuesta inválida XML con la operación del <get-config>

La operación del <get-config> con el filtro de config-formato-XML vuelve los desaparecidos o las etiquetas de cierre incorrectas para el <X-Interface>, tal y como se muestra en de los siguientes ejemplos:

<LineVty0-Configuration>
	<X-Interface> password cisco<X-Interface> <X-Interface> transport input
	all<X-Interface> </LineVty0-Configuration>

La etiqueta XML para los parámetros no se interpreta correctamente

La operación del <edit-config> con una fusión o crea contener una etiqueta inválida XML para los parámetros no se interpreta correctamente. Usted debe estar seguro de ingresar la cadena con la capitalización apropiada.

En el siguiente ejemplo, el nombre del host del router se convierte en “systemnetworkname” (texto en intrépido para el propósito del ejemplo):

<?xml version="1.0"?>

<rpc message-id="7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <xml-config-data>
        <Device-Configuration>
        <hostname>
          <systemnetworkname operation="create">XmlpiRouter</systemnetworkname>
        </hostname>
        </Device-Configuration>
      </xml-config-data>
    </config>
  </edit-config>
</rpc>

En el siguiente ejemplo, el nombre del host del router se convierte en “XmlpiRouter” porque la cadena de “Systemnetworkname” fue ingresado correctamente con una letra mayúscula inicial:

<?xml version="1.0"?>

<rpc message-id="7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <xml-config-data>
        <Device-Configuration>
        <hostname>
          <Systemnetworkname operation="create">XmlpiRouter</Systemnetworkname>
        </hostname>
        </Device-Configuration>
      </xml-config-data>
    </config>
  </edit-config>
</rpc>

Información sobre XML-PI

Descripción XML-PI

Descripción NETCONF

Herramienta ODM y archivos espec.

Algoritmos de la conversión XML-CLI

Descripción XML-PI

XML-PI de la versión 1,0 nuevos NETCONF modelos de datos de las ofertas que recogen show la salida de comando abajo a la palabra clave llana y a las configuraciones corrientes sin la complejidad y el costo de las Tecnologías pantalla-que raspan o de los gatewayes externos XML-a-CLI. XML-PI permite la conversión nativa de la salida show del comando cisco ios en el XML marcado con etiqueta y proporciona la definición asociada del esquema. La salida resultante está en un formato constante, inequívoco que se interprete fácilmente. Las herramientas adicionales permiten que el formato de salida sea personalizado para los requisitos del usuario individual.

Las capacidades siguientes de la versión 1,0 XML-PI le ayudarán rápidamente a desarrollar las aplicaciones de administración de red XML basadas:

Execute seleccionó show los comandos y extrae la salida en el XML bien formado.

Utilice format un modificante que alimente show la salida de comando a través de un convertidor XML.

Extraiga la definición del esquema XML (XSD) para los comandos show seleccionados.

Ejecute show xsd-format el comando de visualizar el XSD al cual la salida XML se ajusta.

Ejecuteshow formatel comando de visualizar una lista de comandos con una entrada de archivo espec. (SFE) en el archivo espec., de visualizar el formato XML SFE para un comando específico, o de validar un archivo espec. Para más información sobre los archivos y SFEs espec., vea que la “herramienta ODM y espec. clasifía” la sección

Extraiga la configuración corriente en el XML.

La versión 1,0 XML-PI proporciona el XML nativo hecho salir para show running-config el comando.

Cambie la configuración corriente en un dispositivo de red enviando un fragmento XML de un cambio de configuración.

Adapte rápidamente las capacidades de XML-PI usando las aplicaciones de ejemplo completamente formadas.

Usted puede utilizar un archivo incorporado que contiene las definiciones para que la mayoría de los comandos de uso frecuente show consigan comenzado en el Desarrollo de aplicaciones inmediatamente.

Los comandos y los archivos salientes se asocian a NETCONF usando netconf format el comando global configuration. Los comandos están también disponibles ayudarle a considerar la jerarquía de la etiqueta XML, enumeran show los comandos se han convertido que, y la salida de los debugs.

Descripción NETCONF

Las secciones siguientes resumen las operaciones NETCONF:

Mejoras NETCONF

Mejora para extraer la salida de los ejecutar-config de la demostración

Mejora para cambiar la configuración corriente

Mejora para extraer los comandos show

Mejoras NETCONF

XML-PI se integra como modelo de datos para NETCONF, que construye encima del protocolo del estándar de la industria que permite que los dispositivos de red de Cisco sean manejados de una manera más automática y más programática.

En XML-PI, cada palabra clave del comando, parámetro, y cambio del submode se envuelve en los tokens XML, sobre la base de los cuales se generan, respectivamente, la palabra clave, la ayuda, y las cadenas del submode.

El cuadro 1 muestra las mejoras dominantes a los GET-config, los editar-config, y consigue las operaciones, que se ingresan como el <get-config>, el <edit-config>, y cadenas del <get> respectivamente en la interfaz de dispositivo aumentada para la versión 1,0 XML-PI.

Las secciones siguientes resumen estas mejoras. Refiera a la guía del programador para el Cisco Enhanced Device Interface 2,2 para más información.

Cuadro 1 características fundamentales de la versión 1,0 XML-PI

Mejora para extraer la salida de los ejecutar-config de la demostración

La sub-estructura siguiente se agrega a la operación del <get-config> para permitir que el XML haga salir para que show running-config sea extraído usando NETCONF:

<get-config>
    <source><running/></source>
    <filter type="cli"><config-format-xml options".."></config-format-xml></filter>
</get-config>

La operación del <get-config> NETCONF con el filtro que contiene el <config-format-xml> de la cadena en la petición cuenta con una respuesta en el formato XML-PI. Solamente se soporta la configuración corriente. Lo que sigue es un ejemplo:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <source><running/></source>
  <filter type="cli"><config-format-xml options="all"></config-format-xml></filter>
 </get-config>
</rpc>]]>]]>

Mejora para cambiar la configuración corriente

La sub-estructura siguiente se agrega al nodo de los Config para permitir que la configuración corriente sea cambiada usando NETCONF:

<xml-config-data>  ...entire subtree with C2X encoded payload </xml-config-data>

Se permite al modo de configuración XML-PI usando la operación del <edit-config> NETCONF solamente. Se identifica el modo cuando la etiqueta de config-formato-XML XML se considera en una operación del <edit-config>. La respuesta es éxito estándar o fall NETCONF. La configuración llevó adentro la operación del <edit-config> se convierte al CLI usando el algoritmo X2C. Todas las opciones estándar NETCONF por ejemplo verifican y se soporta el restauración-en-error. Si el CLI generado del XML causa un error, un mensaje fallido de la operación se devuelve al terminal original de la petición.

La capacidad para que una operación del <edit-config> NETCONF valide las peticiones formatadas XML-PI no se relaciona con los archivos espec. La comprensión del formato de la configuración XML-PI se incorpora al Cisco IOS y es una conversión algorítmica, así que no puede ser modificada dinámicamente como los archivos espec. para show los comandos.

Una configuración parcial como subconjunto de la configuración del dispositivo completo se puede enviar al dispositivo de red a condición de que la configuración parcial asocia inequívoco a una configuración CLI. La configuración parcial debe tener información contextual tal como interfaz u otra información del submode, si procede, y debe soportar la restauración no actualizada si la configuración no puede ser aplicada.


Se soportala restauración no actualizada de la nota solamente cuando el “archivo” se configura en el dispositivo de red, que es un requisito del Cisco IOS.


Agregar dos hosts IP: Ejemplo:

Lo que sigue es un ejemplo de usar la operación del <edit-config> para modificar la configuración corriente agregando dos hosts IP:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="2"  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <xml-config-data>
        <Device-Configuration>
          <ip>
            <host>
              <NameHost>host1</NameHost>
              <HostIPAddress>10.2.3.4</HostIPAddress>
            </host>
          </ip>
          <ip>
            <host>
              <NameHost>host2</NameHost>
              <HostIPAddress>10.2.3.5</HostIPAddress>
            </host>
          </ip>
        </Device-Configuration>
      </xml-config-data>
    </config>
  </edit-config>
</rpc>]]>]]>

Borrar dos hosts IP: Ejemplo:

Lo que sigue es un ejemplo de usar la operación del <edit-config> para modificar la configuración corriente borrando dos hosts IP:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="3"  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <xml-config-data>
        <Device-Configuration>
          <ip>
            <host operation="delete">
              <NameHost>host1</NameHost>
             <HostIPAddress>10.2.3.4</HostIPAddress>
           </host>
         </ip>
         <ip>
            <host operation="delete">
             <NameHost>host2</NameHost>
             <HostIPAddress>10.2.3.5</HostIPAddress>
            </host>
          </ip>
        </Device-Configuration>
      </xml-config-data>
    </config>
  </edit-config>
</rpc>]]>]]>

Respuesta del <edit-config>

La contestación a la operación del <edit-config> es la autorización del estándar o un RPC-error.

Mejora para extraer los comandos show

NETCONF para extraer show los comandos tiene la capacidad de recoger la salida de comando abajo al nivel de la palabra clave. La sub-estructura siguiente se agrega bajo operación del <get>:

    <filter type="cli">
      <config-format-text-block><text-filter-spec>| inc 
netconf</text-filter-spec></config-format-text-block>
      <oper-data-format-xml><show xsd="true">...</show><show>...</show></oper-data-format-xml>
    </filter>

Respuesta del <get>

La contestación a la operación del <get> genera la respuesta siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="XXXX" xmlns="urn:ietf:params:netconf:base:1.0">
  <data>
    <cli-config-data-xml>... config gets embedded here ...</cli-config-data-xml>
    <cli-oper-data-xml>
      <item>
        <show>...</show>
        <xsd>  ... xsd text gets embedded here ... </xsd>
      </item>
      ...multiple items ...
    </cli-oper-data-xml>
  </data>
</rpc-reply>]]>]]>

Herramienta ODM y archivos espec.

La herramienta del modelo de datos de funcionamiento (ODM) desarrollada por el Cisco Enhanced Device Interface (IED) proporciona una interfaz para crear un nuevo archivo espec. ODM de un archivo de los datos CLI, para un comando determinado show . Los archivos espec. son definidos por un metalenguaje IED y contienen un algoritmo de las coincidencias de patrones que recoja la salida de los comandos exec del Cisco IOS show y la ponga en un esquema específico. La salida de cada show comando se asocia a un archivo espec. ODM.

El archivo espec. representa la información espacial para extraer o para analizar los datos y la información estructural para modelar los datos. Una ventaja de usar los archivos espec. es que diversas descripciones de formato se pueden integrar en ellos, de tal modo haciendo la tarea de personalizar las aplicaciones fácil.

El archivo espec. puede contener muchas definiciones de comando individual salvadas como SFE. Cada SFE es delimitado por una línea que contiene tres signos numerales (###). Las líneas inmediatamente después del delimitador del ### contienen el nombre del comando de convertir. ¿Después de la línea de comando name están los datos del archivo espec., que deben comenzar con una encabezado XML, por ejemplo <? xml el version="1.0" encoding="UTF-8"?>. El ### es un comienzo y delimitador de la parada a menos que se encuentre la cadena del Fin del archivo (EOF), tal y como se muestra en del formato siguiente de la muestra:

###
show ip arp
<?xml version="1.0" encoding="UTF-8"?>
 ... the spec conversion for ip arp
###
show ip interface brief
<?xml version="1.0" encoding="UTF-8"?>
... the spec conversion for show ip interface brief
###
show interfaces *
show another cli
<?xml version="1.0" encoding="UTF-8"?>
... The spec conversion for ip interface

Un carácter comodín (*) se puede utilizar a los nombres de comando match, y utiliza la orden siguiente de la búsqueda: Encuentre que un exacto - haga juego o, si no un exacto - hace juego, que utiliza el carácter comodín para hacer juego el número máximo de caracteres. El cuadro 1 proporciona los ejemplos de cómo el carácter comodín se puede utilizar en el archivo espec. a los nombres de comando match.

El corresponder con del comando name del carácter comodín del cuadro 1

String (cadena)
Ejemplo de los caracteres correspondidos con

show interfaces

Las coincidencias “demostración interconectan”

muestre el s* de las interfaces

Las coincidencias “demostración interconectan el resumen”

interfaces de la demostración *

Demostración de las coincidencias la “interconecta el FastEthernet el 0/0"


Usted puede cambiar el nombre de fichero espec., y usted puede modificar y personalizar el SFE a los formatos específicos de la interpretación. Si el contenido del SFE no cumple con el formato de archivo y el lenguaje espec., la conversión no se carga y ninguna interpretación de los datos ocurre. Un mensaje de error que expone el SFE es ininterpretable se genera. El formato del mensaje de error depende de la fuente de la petición de acceder el archivo espec. La vuelta de las peticiones NETCONF una llamada a procedimiento remoto (RPC) consigue la RPC-contestación con una condición de error; La vuelta basado en CLI de las peticiones consigue los mensajes de error en la consola. La capacidad limitada del debug del formato es proporcionada por debug format all el comando. Cada SFE se trata independientemente, y un SFE gravemente formatado no afecta a ningún otro SFE en el archivo.

Usted puede utilizar show format el comando de visualizar una lista de comandos con un SFE en el archivo espec., de visualizar el formato XML SFE para un comando específico, o de validar un archivo espec.


Los archivosespec. de la muestra de la nota están disponibles para la mayoría de los comandos cisco ios de uso general show y se pueden descargar del cisco.com. Usted puede utilizar los archivos de ejemplo “como es” o modificarlos para su aplicación.


Algoritmos de la conversión XML-CLI

Los algoritmos de la conversión X2C y C2X se utilizan para convertir el XML en el CLI y el CLI en el XML, respectivamente. No hay esquema usado con estos algoritmos. Las secciones siguientes proporcionan más información sobre estos algoritmos:

Algoritmo X2C

Algoritmo C2X

Algoritmo X2C

El algoritmo X2C construye un árbol del modelo de objeto document (DOM) del XML. Cada nodo en el árbol se puede clasificar como uno de tres tipos de nodo, dependiendo de su nombre, como sigue:

KEYWORD_NODE — El nombre de la etiqueta comienza con una letra minúscula o un caracter de subrayado. [a…z, _]. El caracter de subrayado se utiliza para prefijar cualquier valor numérico que sea una palabra clave.

SUBMODE_NODE — Los extremos del nombre de la etiqueta con - Configuración.

PARAM_NODE — Cualquier otra cadena no-cero de la longitud.

El algoritmo X2C entonces decodifica un árbol DOM recurrentemente descendiendo el árbol. En el siguiente ejemplo, el this_node se utiliza para seguir el nodo actual DOM y el this_cmd es la cadena CLI que es construida:

decode_node(this_node)
    if (this_node is KEYWORD_NODE) {
        if  (this_node has attribute isNegation) {
          prepend "no" to this_cmd
        }
        convert this_node name to be a keyword.
        Add keyword to end of this_cmd
        iterate children of this_node through decode_node.
    } else if (this_node is PARAM_NODE) {
        add the node body data to this_cmd
    } else if (this_node is SUBMODE_NODE) {
      this_cmd is finalised and reset to ""
      iterate children of this_node through decode_node.
    }
}

Algoritmo C2X

Para el algoritmo C2X, cada palabra CLI se categoriza como uno de los tres tipos de nodo, lo mismo según lo descrito en sección del algoritmo "X2C”. El analizador de sintaxis del Cisco IOS CLI se utiliza para generar la configuración corriente del dispositivo de red. Mientras que se genera cada línea, cada palabra en la línea se analiza a través y, dependiendo de si el analizador de sintaxis encuentra un KEYWORD_NODE o un PARAM_NODE, la conversión apropiada de la etiqueta XML se hace. Si el atravesar a través a la línea siguiente causa un cambio SUBMODE_NODE, el wrapper del submode XML se ingresa o se cierra dependiendo de si el modo está ingresado o dado salida.

El algoritmo C2X convierte el Cisco IOS CLI en el XML basado en las palabras claves y los parámetros. Las palabras claves CLI se convierten en etiquetas XML y los parámetros se convierten en los cuerpos de las etiquetas cuyos nombres son hechos analizando las cadenas de la ayuda CLI.

El siguiente ejemplo es la opinión CLI interface de un comando:

interface GigabitEthernet0/1
 ip address 10.4.0.13 255.0.0.0
 duplex auto
 speed auto
 media-type rj45
 no negotiation auto

El siguiente ejemplo muestra el equivalente C2X:

<Device-Configuration>
  <interface>
    <Param>GigabitEthernet0/1</Param>
    <ConfigIf-Configuration>
      <ip>
        <address>
          <IPAddress>10.4.0.13</IPAddress>
          <IPSubnetMask>255.0.0.0</IPSubnetMask>
        </address>
      </ip>
      <duplex><auto/></duplex>
      <speed><auto/></speed>
      <media-type><rj45/></media-type>
      <negotiation operation="delete" ><auto/></negotiation>
    </ConfigIf-Configuration>
  </interface>
</Device-Configuration>

Cómo utilizar XML-PI

Esta sección contiene los siguientes procedimientos:

Configurando NETCONF para XML-PI (requerido)

Generando el formato XML para los comandos (requeridos)

Generando el formato XSD para los comandos (requeridos)

Localización de averías de los errores ODM (opcionales)

El manejo clasifía (recomendado)

Configurar NETCONF para XML-PI

Realice esta tarea requerida de configurar un entorno seguro del login y de definir el archivo para utilizar para las peticiones en formato de XML.

PASOS SUMARIOS

1. enable

2. configure terminal

3. crypto key generate rsa

4.Ingrese módulo de la clave del Rivest, del Shamir, y del Adelman (RSA), cuando está indicado.

5.ip ssh timeout segundos

6.ip ssh authentication-retries número entero

7. ip ssh version 2

8.line vty conclusión-línea-número del empezar-línea-número

9. login local

10. transport input ssh

11. exit

12. username name privilege level password secret

13. format global location:local-filename

14. netconf ssh

15. end

DETALLADO

 
Comando o acción
Propósito

Paso 1 

enable

Example:

Router> enable

Habilita el modo EXEC privilegiado.

Ingrese su contraseña si se le pide que lo haga.

Paso 2 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

crypto key generate rsa

Example:

Router(config)# crypto key generate rsa

Genera pares de llaves RSA.

Observesi el crypto key se ha generado ya, es la respuesta del comando:

% usted tiene ya RSA -.cisco.com nombrado definido xxxxlas clavesnnn.
¿% le hacen quieren realmente substituirlas? [yes/no]:

En la mayoría de los casos la contestación es no porque el crypto key se ha generado y se salva previamente en el lado del agente NETCONF. Conteste el Sí si usted necesita reajustar el crypto key en el lado del agente NETCONF.

Paso 4 

Ingrese el módulo de la clave RSA, cuando está indicado.

Example:

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys ...[OK]

Indica para el módulo de la clave RSA cuando no está proveído como parte del comando.

Los tamaños dominantes del módulo deben estar en el rango a partir del 360 a 2048 para las claves de fines generales. La configuración para XML-PI requiere los tamaños dominantes mínimos del módulo de 768.

Observeel sistema puede requerir algunos minutos para reaccionar a un módulo dominante mayor de 512.

Paso 5 

ip ssh timeout seconds

Example:

Router(config)# ip ssh timeout 60

(Opcional) configura el intervalo de tiempo que el dispositivo de red espera al cliente SSH para responder.

Paso 6 

ip ssh authentication-retries integer

Example:

Router(config)# ip ssh authentication-retries 3

(Opcional) configura la cantidad de intentos después de lo cual se reajusta la interfaz.

Paso 7 

ip ssh version 2

Example:

Router(config)# ip ssh version 2

(Opcional) configura el dispositivo de red para funcionar con solamente el SSH versión 2.

Paso 8 

line vty starting-line-number ending-line-number

Example:

Router(config)# line vty 0 8

Ingresa al modo de obtención de la configuración de línea y configura un rango de las líneas de terminal virtual para el acceso de la consola remota.

Notausted debe configurar un rango de las líneas bastante grandes para manejar dos líneas del vty por la sesión NETCONF.

Paso 9 

login local

Example:

Router(config-line)# login local

(Opcional) habilita y selecciona marcar de la contraseña local.

La autenticación se basa en el nombre de usuario especificado con username el comando global configuration.

Paso 10 

transport input ssh

Example:

Router(config-line)# transport input ssh

(Opcional) especifica que el protocolo SSH esté utilizado para la línea conexión.

Paso 11 

exit

Example:

Router(config-line)# exit

Sale el modo y las devoluciones de la configuración actual al modo más alto siguiente.

Paso 12 

username name privilege level password secret

Example:

Router(config)# username me privilege 15 password mypassword

(Opcional) establece un sistema de autenticación basado en el nombre de usuario.

privilege — Fija el nivel de privilegio, un número a partir de la 0 a 15.

password — Fija la contraseña, que puede contener a partir 1 a 25 caracteres y los espacios integrados, y debe ser la última opción especificada en username el comando.

Paso 13 

format global location:local-filename

Example:

Router(config)# format global disk2:spec3.3.odm

(Recomendado) especifica un archivo espec. del valor por defecto ODM para utilizar para las peticiones en formato de XML.

Paso 14 

netconf ssh

Example:

Router(config)# netconf ssh

Permisos NETCONF sobre SSHv2.

Paso 15 

end

Example:

Router(config)# end

Termina la sesión de configuración actual.

Generación del formato XML para los comandos

Para convertir el comando cisco ios show hecho salir en el formato XML, XML-PI proporciona format al modificador de resultado show a la salida de comando. Esta sección describe cómo utilizar este modificante. Por ejemplos de la salida de comando, vea los “ejemplos: Generando el formato XML del comando show” seccione y “los ejemplos: Generando sección del formato XML de los ejecutar-config de la demostración”.


Observe show running-config la salida de comando se genera nativo en el XML, así que el nombre de fichero espec. podría ser un archivo vacío. Si un archivo espec. del valor por defecto se ha definido con format global el comando, no se requiere ningún nombre de fichero.


PASOS SUMARIOS

Elija el comando en el paso 1 o el paso 2.

1.show-command | format []location:local-filename

o

2.show running-config {all | brief | full | interface interface-name} | format []filename

PASOS DETALLADOS


Paso 1 show-command | format []location:local-filename

Este comando ejecuta show el comando después reorienta la salida en format la función que generará el XML basado en el archivo especificado espec. o, si no se especifica ningún archivo espec., el archivo espec. del valor por defecto definido por format global el comando configuration. El comando names puede ser truncado. El : locationlocal-filename los argumentos y la palabra clave son la ubicación y el nombre de fichero del archivo espec. ODM. Las ubicaciones válidas son bootflash: flash: nvram:, y cualquier disco o número de slot válido (por ejemplo: disk0: o slot1:). Los archivos espec. ODM tienen un sufijo .odm. Lo que sigue es un ejemplo de comando que utiliza el archivo del valor por defecto ODM para generar el XML:

Router# show arp | format slot0:spec3.3.odm

Paso 2show running-config {all | brief | full | interface interface-name} | format []filename

Si usted está generando la salida para show running-config el comando, usted puede suministrar las palabras claves y los argumentos siguientes este comando:

all — Configuración con los valores por defecto (valor por defecto cuando no se especifica ningunas palabras claves con show running-config el comando).

brief — Configuración sin los datos del certificado.

full — Configuración total.

interface interface-name — Interfaz especificada hecha salir solamente. Se requiere una especificación de interfaz plenainterface fastethernet0/0(, por ejemplo). Si el nombre de la interfaz no hace juego uno que se soporte en el dispositivo de red, se vuelve un error.

Lo que sigue es un ejemplo de comando:

Router# show running-config brief | format


Generación del formato XSD para los comandos

show xsd-format Se utiliza el comando de visualizar el XSD al cual la salida XML se ajusta. Esta sección describe cómo utilizar este comando. Por ejemplo de la salida de comando, vea el “ejemplo: Generando sección del formato del comando show XSD”.

PASOS SUMARIOS

1.show xsd-format []location:local-filename cli command

PASOS DETALLADOS


[]clishow xsd-format del pasolocation:local-filename 1 command

location Y local-filename los argumentos es la ubicación y el nombre de fichero de las palabras claves válidas del archivo espec. location ODM es bootflash: flash: nvram:, y cualquier disco o número de slot válido (por ejemplo: disk0: o slot1:). Los archivos espec. ODM tienen un sufijo .odm. Estos argumentos no se requieren si usted quiere utilizar un archivo del valor por defecto ODM definido con format global el comando.

El primer de los dos ejemplos siguientes, salida de las visualizaciones XSD de un archivo definido espec. del valor por defecto ODM:

Router# show xsd-format cli show arp

Router# show xsd-format disk2:spec3.3.odm cli show arp

Observecuando el usuario está ingresando el comando names, el nombre de comando completo debe ser ingresado; no utilice el truncamiento del comando.


Localización de averías de los errores ODM

Esta sección describe el uso debug format all del comando de resolver problemas los errores del archivo espec.

PASOS SUMARIOS

1. enable

2. debug format all

3.show-command| format []location:local-filename

4. no debug format all

PASOS DETALLADOS


Paso 1 enable

Ingrese este comando de habilitar al modo EXEC privilegiado requerido funcionar con debug los comandos.

Paso 2 debug format all

Ingrese este comando de habilitar a un modo de debugging prolijo que visualice todos los errores ODM.

Paso 3 show-command | format []location:local-filename

Ingrese este comando de generar el XML hecho salir para show interfaces el comando. Lo que sigue es salida de muestra:

Router# show interfaces | format slot0:spec3.3.odm

Los datos seleccionados del debug se visualizan con los comentarios seguidos por la salida de los debugs completa.

Las declaraciones del formato del debug son adentro leídos grupos de dos líneas. Mientras que el siguiente ejemplo muestra, la primera línea describe cuáles era la coincidencia frustrada; la segunda línea proporciona el desplazamiento y la cuenta de bytes desde el principio show interfaces de la salida de comando que el cursor del raspador de la pantalla está actualmente en:

*May  4 01:20:35.279: ODM: Could not match Property mcast
*May  4 01:20:35.279: offset 703: 5 minute output rate 0 bits/sec, 0 packets/sec

El siguiente ejemplo muestra donde el SFE hizo el algoritmo ODM volver un XML truncado. Aviso cómo el desplazamiento salta a partir el 703 a 3001. Éste es un salto grande que implica una búsqueda entre el Multicast y el Multicast IP hizo probablemente el raspador de la pantalla saltar demasiado lejos en el texto. Porque el cursor no está en un buffer, esta condición es el candidato probable al error. La mirada de la entrada de archivo espec. y hacer una búsqueda manual a través show de la salida de comando confirmarán esta sospecha.

*May  4 01:20:35.279: offset 703: 5 minute output rate 0 bits/sec, 0 packets/sec
     786 pa
*May  4 01:20:35.279: ODM: Could not match Property mcast
*May  4 01:20:35.279: offset 703: 5 minute output rate 0 bits/sec, 0 packets/sec
     786 pa
*May  4 01:20:35.279: ODM: Could not match Property IP multicasts
*May  4 01:20:35.279: offset 3001: no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0
*May  4 01:20:35.279: ODM: Could not match Property watchdog
*May  4 01:20:35.279: offset 3122: ignored, 0 abort
     0 packets output, 0 bytes, 0 underru
*May  4 01:20:35.279: ODM: Could not match Property input packets with dribble condition 
detected

Paso 4 no debug format all

Inhabilite debug el comando cuando la localización de averías es completa.


Manejo de los archivos

Esta sección proporciona los siguientes procedimientos para manejar los archivos en XML-PI:

Visualizar los archivos en un filesystem del Cisco IOS: Ejemplo:

Manejo de los archivos espec.

Validar los archivos espec.

Visualizar los archivos en un filesystem del Cisco IOS: Ejemplo:

Las demostraciones del siguiente ejemplo cómo visualizar una lista de archivos:

Router# show format slot0:?

slot0:spec3.3.odm      slot0:spec3.ALR.odm      slot0:spec3.empty.odm

Observeel comando del signo de interrogación? () puede ser utilizado después de las palabras claves location unas de los (bootflash slot, y así sucesivamente) en show format y show xsd-format los comandos, enumerar todos los archivos. Los archivos espec. tienen una extensión de archivo .odm.


Manejo de los archivos espec.

Utilice spec-file install el comando privileged exec de manejar los archivos espec. Los siguientes comandos permiten que usted haga las copias de backup de espec. del accesorio para clasifiar antes de cambiar el contenido del archivo, y para restablecer el contenido de espec. anterior para clasifiar. Usted puede también copiar y quitar SFEs a partir de un archivo espec. a otro.

Las ubicaciones válidas para los archivos locales son bootflash: flash: nvram:, y cualquier disco o número de slot válido (ejemplo: disk0: o slot1:).

Los URL válidos para los archivos remotos son archive: bootflash: cns: flash: ftp: http: null: nvram: pram: rcp: scp: system: tar: tftp:, tmpsys: y cualquier disco o número de slot válido (por ejemplo, disk0: o slot1:).

En todos los casos, force la palabra clave realiza el comando sin indicarle a que verifique la operación del archivo ingresando un Sí o una respuesta del no.

PASOS SUMARIOS

1.spec-file install []force location:local-filename add-entry url:remote-filename command

2.spec-file install []force location:local-filename built-in

3.spec-file install archivoforcelocation:local-filename del [] url:remote-filename

4.spec-file install []force location:local-filename remove-entry command

5.spec-file install []force location:local-filename restore

PASOS DETALLADOS

 
Comando o acción
Propósito

Paso 1 

spec-file install [force] location:local-filename add-entry url:remote-filename command

Example:
Router# spec-file install slot0:spec_file.odm 
add-entry tftp://system1/user1/show_arp.odm 
show arp

Copia un SFE de un lugar remoto y lo agrega a un archivo local espec.

Un control se realiza en el SFE cargado para asegurarse de que el comando no está ya presente en el archivo espec., y de que el SFE se puede analizar correctamente en el XML.

Si no existe el archivo espec., le indicarán antes de que se cree el archivo.

Si el comando SFE existe ya en el archivo espec., le indicarán antes de que se substituya el comando SFE.

Una copia de backup del archivo local espec. se crea antes de que se agregue el telecontrol SFE.

Paso 2 

spec-file install [force] location:local-filename built-in

Example:
Router# spec-file install slot0:spec_file.odm 
built-in

Substituye el archivo actual espec. por el archivo espec. del accesorio.

Le indicarán antes de que se substituya el archivo actual y filename.bak será creado.

Paso 3 

spec-file install [force] location:local-filename file url:remote-filename

Example:
Router# spec-file install slot0:spec_file.odm 
file tftp://system1/user1/spec_file.odm

Substituye un archivo local espec. por un archivo espec. del telecontrol.

Un control del archivo cargado se realiza para asegurarse de que cada comando especificado está incluido solamente una vez, y de que el SFE se puede analizar correctamente en el XML.

Paso 4 

spec-file install [force] location:local-filename remove-entry command

Example:

Router# spec-file install slot0:spec_file.odm remove-entry show arp

Quita un SFE de un archivo espec.

Un control se realiza para asegurarse de que el comando SFE está presente en el archivo espec.

Si no existe el archivo espec., este comando falla.

Una copia de backup del archivo espec. se crea antes de que se quite el SFE.

Paso 5 

spec-file install [force] location:local-filename restore

Example:

Router# spec-file install slot0:spec_file.odm restore

Restablece un archivo espec. a su contenido original usando un archivo de reserva (.bak).

Si no existe el archivo .bak, este comando falla.

Validar los archivos espec.

Esta sección describe el uso show format del comando de validar un archivo espec.

show format built-in validate La forma del comando se utiliza para validar el archivo espec. del accesorio. El : show format locationlocal-filename validate la forma del comando se utiliza para validar un archivo específico espec.

Restricciones

Los archivos espec. deben residir localmente en el dispositivo de red. Usando los archivos espec. de un filesystem remoto no se soporta.

PASOS SUMARIOS

1. enable

2.show format [built-in | ubicación: local-nombre de fichero] [cli comando | validate]

PASOS DETALLADOS

 
Comando o acción
Propósito

Paso 1 

enable

Example:

Router> enable

Habilita el modo EXEC privilegiado.

Ingrese su contraseña si se le pide que lo haga.

Paso 2 

show format [built-in | location:local-filename] [cli command | validate]

Example:

Router# show format built-in validate

Valida el archivo espec. del accesorio.

Ejemplos de configuración para XML-PI

Esta sección proporciona los siguientes ejemplos de configuración:

Ejemplo: Configurar NETCONF para XML-PI

Ejemplos: Generación del formato XML del comando show

Ejemplos: Generación del formato XML de los ejecutar-config de la demostración

Ejemplo: Generación del formato del comando show XSD

Ejemplo: Visualizar el SFEs

Ejemplo: Visualizar la jerarquía de la etiqueta del archivo espec.

Ejemplo: Validar un archivo espec.

Ejemplo: Configurar NETCONF para XML-PI

Las demostraciones del siguiente ejemplo cómo configurar un entorno seguro del login. Cisco recomienda que usted define un archivo del valor por defecto ODM que se utilizará para todas las peticiones usando format global el comando. Usted puede asociar ese archivo a NETCONF para todas las peticiones en formato de XML usando netconf format el comando. Si no se especifica ningún archivo, el archivo espec. del accesorio se utiliza para todas las peticiones. Vea format global y netconf format las páginas de la referencia de comandos para más información. netconf ssh El comando configuration habilita NETCONF sobre SSHv2, que termina la capa de sesión y proporciona una conexión segura.

ip domain-name cisco.com
crypto key generate rsa
ip ssh timeout 60
ip ssh authentication-retries 3
ip ssh version 2
line vty 0 8
  login local
  transport input ssh
  exit
username me privilege 15 password mypassword
format global disk2:spec3.3.odm
netconf format disk2:spec3.3.odm
netconf ssh
end

Ejemplos: Generación del formato XML del comando show

La demostración de los siguientes ejemplos cómo generar el formato XML de la salida estándar show del comando cisco ios.

Salida del comando show estándar

Lo que sigue es un ejemplo del comando cisco ios show arp hecho salir:

Router# show arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.1               67   0001.42df.59e2  ARPA   FastEthernet0/0
Internet  10.3.1.2                8   0002.55c6.19a0  ARPA   FastEthernet0/0
Internet  10.4.0.5                -   000b.60dc.9408  ARPA   FastEthernet0/0

Generación del XML

Lo que sigue es un ejemplo de generar la salida XML show arp del comando de un archivo del valor por defecto ODM:

Router# show arp | format

<?xml version="1.0" encoding="UTF-8"?>
  <ShowArp xmlns="ODM://disk0:/spec.odm//show_arp">
    <ARPTable>
      <entry>
        <Protocol>Internet</Protocol>
        <Address>10.1.1.1</Address>
        <Age>67</Age>
        <MAC>0001.42df.59e2</MAC>
        <Type>ARPA</Type>
        <Interface>FastEthernet0/0</Interface>
      </entry>
      <entry>
        <Protocol>Internet</Protocol>
        <Address>10.3.1.2</Address>
        <Age>8 </Age>
        <MAC>0002.55c6.19a0</MAC>
        <Type>ARPA</Type>
        <Interface>FastEthernet0/0</Interface>
      </entry>
      <entry>
        <Protocol>Internet</Protocol>
        <Address>10.4.0.5</Address>
        <MAC>000b.60dc.9408</MAC>
        <Type>ARPA</Type>
        <Interface>FastEthernet0/0</Interface>
      </entry>
    </ARPTable>
  </ShowArp>

Ejemplos: Generación del formato XML de los ejecutar-config de la demostración

Los siguientes ejemplos muestran la asignación entre la salida de comando show running-config real y el formato XSD generado transmitiendo la salida a través del archivo espec. spec3.3.odm. (Para el motivo de la brevedad, la salida de cada comando se ha truncado.)

Comando show running-config

Router# show running-config

Building configuration...

Current configuration : 1190 bytes
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service internal
!
hostname Router1
!
boot-start-marker
boot system flash:c7200-js-mz.123-5.9.T
boot-end-marker
!
logging message-counter syslog
enable password secret
!
no aaa new-model
ip cef
!
no ip domain lookup
ip domain name cisco.com
ip host host1 10.66.152.11
ip host host2 10.2.2.2
multilink bundle-name authenticated
.
.
.

Salida transmitida para generar el XML

Router# show running-config | format

Building configuration...

<Device-Configuration>
<upgrade><fpd><auto/></fpd></upgrade>
<version><Param>12.4</Param></version>
<service><timestamps><debug><datetime><msec/></datetime></debug></timestamps></>
<service><timestamps><log><datetime><msec/></datetime></log></timestamps></serv>
<service operation="delete" ><password-encryption/></service>
<service><internal/></service>
<hostname><SystemNetworkName>Router1</SystemNetworkName></hostname>
<boot-start-marker></boot-start-marker>
<boot><system><TFTPFileNameURL>flash:c7200-js-mz.123-5.9.T</TFTPFileNameURL></s>
<boot-end-marker></boot-end-marker>
<logging><message-counter><syslog/></message-counter></logging>
<enable><password><UnencryptedEnablePassword>secret</UnencryptedEnablePassword><>
<aaa operation="delete" ><new-model/></aaa>
<ip><cef/></ip>
<ip operation="delete" ><domain><lookup/></domain></ip>
<ip><domain><name><DefaultDomainName>cisco.com</DefaultDomainName></name></doma>
<ip><host><NameHost>host1 </NameHost><HostIPAddress>10.66.152.11</HostIPAddre>
<ip><host><NameHost>host2 </NameHost><HostIPAddress>10.2.2.2</HostIPAddress></ho>
<multilink><bundle-name><authenticated/></bundle-name></multilink>
.
.
.

Los datos devueltos son la configuración pedida convertida usando el algoritmo C2X.

Ejemplo: Generación del formato del comando show XSD

Las demostraciones del siguiente ejemplo cómo generar XSD para show arp el comando:

Router# show xsd-format disk2:spec3.3.odm cli show arp

<?xml version="1.0"?>
  <xsd:schema elementFormDefault="qualified" attributeFormDefault="unqualified" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:complexType name="ShowArp_def">
      <xsd:sequence>
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element ref="Info"/>
          <xsd:element name="ARPTable" minOccurs="0">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="entry" minOccurs="0" maxOccurs="unbounded">
                  <xsd:complexType>
                    <xsd:sequence>
                      <xsd:element name="Protocol" minOccurs="0" type="string" />
                      <xsd:element name="Address" minOccurs="0" type="string" />
                      <xsd:element name="Age" minOccurs="0" type="integer" />
                      <xsd:element name="MAC" minOccurs="0" type="string" />
                      <xsd:element name="Type" minOccurs="0" type="string" />
                      <xsd:element name="Interface" minOccurs="0" type="string" />
                    </xsd:sequence>
                  </xsd:complexType>
                </xsd:element>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
      </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="Info" type="xsd:string"/>
    <xsd:element name="ShowArp" type="ShowArp_def"/>
  </xsd:schema>

Ejemplo: Visualizar el SFEs

Las demostraciones del siguiente ejemplo cómo visualizar el SFE para show arp el comando:

Router# show format disk2:spec3.3.odm cli show arp

<?xml version="1.0" encoding="UTF-8"?>
<ODMSpec>
  <Command>
    <Name>show arp</Name>
  </Command>
  <OS>ios</OS>
  <DataModel>
    <Container name="ShowArp" >
      <Table name="ARPTable">
        <Header name = "Protocol" start = "0" end = "10" type = "String"/>
        <Header name = "Address" start = "10" end = "26" type = "IpAddress"/>
        <Header name = "Age (min)" alias = "Age" start = "26" end = "36" type = 
"Integer"/>
        <Header name = "Hardware Addr" alias="MAC" start = "36" end = "53" type = 
"String"/>
        <Header name = "Type" start = "53" end = "59" type = "String"/>
        <Header name = "Interface" start = "59" end = "-1" nullable = "true" type = 
"String"/>
      </Table>
    </Container>
  </DataModel>
</ODMSpec>

El siguiente ejemplo muestra una lista de comando names completamente ampliado que tiene archivos espec. en el archivo del valor por defecto ODM:

Router# show format

The following CLI are supported in slot0:spec3.3.odm
show arp 
show cdp neighbors detail 
show context 
show flash:
show interfaces*
show inventory
show ip interface brief
show ip nat translations
show line value
show line
show processes cpu
show processes memory
show region
show spanning-tree
show stacks
show vlans

Ejemplo: Visualizar la jerarquía de la etiqueta del archivo espec.

show odm-format El comando visualiza la estructura de archivo espec. en una salida fija a que usted pueda referir para entender la jerarquía de la etiqueta del archivo espec. El siguiente ejemplo muestra la salida fija show odm-format del comando. Refiera a la guía del programador para el Cisco Enhanced Device Interface 2,2 para más información sobre la herramienta ODM y marque la jerarquía con etiqueta.

Router# show odm format

New Name Space ''
<NotARealTag> Either 0 or 1 allowed
  <ODMSpec> Exactly 1 required
    <Command> Exactly 1 required
      <Name> Exactly 1 required
      <AliasSet> Either 0 or 1 allowed
        <Alias> At least 1 required
    <OS> Either 0 or 1 allowed
    <DataModel> Exactly 1 required
      <Container> Exactly 1 required
        <Table> 0 or more is allowed
          <Header> At least 1 required
            <Option> 0 or more is allowed
          <EndOfTheTable> Either 0 or 1 allowed
        <Property> 0 or more is allowed
          <Option> 0 or more is allowed
        <Container> 0 or more is allowed
          <Table> 0 or more is allowed
            <Header> At least 1 required
              <Option> 0 or more is allowed
            <EndOfTheTable> Either 0 or 1 allowed
          <Property> 0 or more is allowed
            <Option> 0 or more is allowed 
             <Container> 0 or more is allowed
          <Legends> 0 or more is allowed
            <Legend> At least 1 required
          <IgnorableLinesList> 0 or more is allowed
            <Line> At least 1 required
        <Legends> 0 or more is allowed
          <Legend> At least 1 required
        <IgnorableLinesList> 0 or more is allowed
          <Line> At least 1 required

Ejemplo: Validar un archivo espec.

Las demostraciones del siguiente ejemplo cómo validar un archivo espec. del accesorio:

Router# show format built-in validate 

The file built-in has been validated

Referencias adicionales

Documentos Relacionados

Tema relacionado
Título del documento

Comandos de Cisco IOS

El Cisco IOS domina los comandos list, todos las versiones

Comandos management del Cisco IOS Network

Referencia de Comandos de Administración de Redes de Cisco IOS

NETCONF

Protocolo de Configuración de Red

Herramienta ODM

La guía del programador para el Cisco Enhanced Device Interface 2,2


Estándares

Estándar
Título

XML-PI basado en los estándares NETCONF

Guía del usuario para el Cisco Enhanced Device Interface 2,2

La guía del programador para el Cisco Enhanced Device Interface 2,2


MIB

MIB
Link del MIB

Ninguno

Para localizar y descargar el MIB para las plataformas elegidas, las versiones de software de Cisco, y los conjuntos de características, utilizan el localizador MIB de Cisco encontrado en el URL siguiente:

http://www.cisco.com/cisco/web/LA/support/index.html


RFC

RFC
Título

RFC 4741

Protocolo de configuración NETCONF

RFC 4742

Usando el Protocolo de configuración NETCONF sobre el Secure Shell (SSH)


Asistencia Técnica

Descripción
Link

El sitio Web de soporte técnico de Cisco proporciona los recursos en línea extensos, incluyendo la documentación y las herramientas para localizar averías y resolver los problemas técnicos con los Productos Cisco y las Tecnologías.

Para recibir la Seguridad y la información técnica sobre sus Productos, usted puede inscribir a los diversos servicios, tales como la herramienta de alerta del producto (accedida de los Field Notice), el hoja informativa de los servicios técnicos de Cisco, y alimentaciones realmente simples de la sindicación (RSS).

El acceso a la mayoría de las herramientas en el sitio Web de soporte técnico de Cisco requiere una identificación del usuario y una contraseña del cisco.com.

http://www.cisco.com/cisco/web/LA/support/index.html


Información de la característica para XML-PI

La tabla 2 muestra el historial de versiones de esta función.

Utilice el Cisco Feature Navigator para encontrar la información sobre el soporte del Soporte de la plataforma y de la imagen del software. El Cisco Feature Navigator le permite para determinar qué imágenes del software soportan una versión de software, un conjunto de características, o una plataforma específico. Para acceder a Cisco Feature Navigator, vaya a http://www.cisco.com/go/cfn. Una cuenta en el cisco.com no se requiere.


Observelas listas del cuadro 2 solamente la versión de software que introdujo el soporte para una característica dada en un tren de versión de software dado. A menos que se indicare en forma diferente, las versiones posteriores de ese tren de versión de software también soportan esa característica.


Información de la característica del cuadro 2 para XML-PI

Nombre de la función
Versiones
Información sobre la Función

XML-PI

12.4(20)T
12.2(33)SRE
12.2(54)SG

La versión 1,0 de la interfaz programática del Lenguaje de marcado extensible (XML-PI) leverages el protocolo de la configuración de red (NETCONF) y modelos de datos de las ofertas los nuevos que recojan show la salida de comando abajo a la palabra clave llana y a las configuraciones corrientes sin la complejidad y el costo de las Tecnologías pantalla-que raspan o de los gatewayes externos XML-a-CLI. XML-PI permite que usted desarrolle rápidamente las aplicaciones de administración de red XML basadas.

Los siguientes comandos fueron introducidos o modificados por esta característica: debug format format global netconf format show format show odm-format show xsd-format spec-file install add-entry spec-file install built-in spec-file install file spec-file install remove-entry, y spec-file install restore.

Esta característica era integrada en el Cisco IOS Release 12.2(33)SRE.

El siguiente comando fue insertado o modificado por esta función: show format.


Glosario

C2X — CLI al XML.

CLI — interfaz de la línea de comandos. Una interfaz que permite que el usuario obre recíprocamente con los comandos operating system by entering y los argumentos optativos.

IED — Interfaz de dispositivo aumentada.

NETCONF — Protocolo de la configuración de red.

ODM — Modelo de datos de funcionamiento.

RSA — Rivest, Shamir, y Adelman, los inventores de la técnica. Sistema criptográfico del clave pública que se puede utilizar para el cifrado y la autenticación.

SSH — Shell seguro.

X2C — XML al CLI.

XML — Lenguaje de marcado extensible.

XSD — Definición del esquema XML.