Guía de Configuración de Administración de Redes de Cisco IOS, Versión 12.2SR
Protocolo de Configuración de Red
2 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 308 KB | Inglés (26 Enero 2008) | Comentarios

Contenidos

Protocolo de Configuración de Red

Encontrar la información de la característica

Contenido

Prerrequisitos de NETCONF

Restricciones de NETCONF

Información sobre NETCONF

NETCONF sobre SSHv2

NETCONF over BEEP

Notificaciones NETCONF

Cómo Configurar NETCONF

Habilitación de SSH Versión 2 Usando un Nombre de Host y un Nombre de Dominio

Habilitación de SSH Versión 2 Usando Peers Llave RSA

Inicio de una Sesión Encriptada con un Dispositivo Remoto

Consejos de Troubleshooting

Pasos Siguientes

Verificar el estatus de la conexión del shell seguro

Ejemplos

Habilitación de NETCONF over SSHv2

Prerrequisitos

Restricciones

Configuración de un Perfil SASL

Habilitación de NETCONF over BEEP

Prerrequisitos

Restricciones

Configuración de la Aplicación del Administrador de Redes de NETCONF

Entrega de las cargas útiles NETCONF

Notificaciones NETCONF que formatan

Monitoreando y mantener las sesiones NETCONF

Restricciones

Ejemplos de Configuración de NETCONF

Habilitación de SSHv2 con un Nombre de Host y un Nombre de Dominio: Ejemplo:

Habilitación de Secure Shell versión 2 mediante Llaves RSA: Ejemplo:

Inicio de una Sesión Encriptada con un Dispositivo Remoto: Ejemplo:

Configuración de NETCONF over SSHv2: Ejemplo:

Configuración de NETCONF sobre BEEP: Ejemplo:

Configuración de la Aplicación del Administrador de Redes de NETCONF: Ejemplo:

Monitoreo de Sesiones NETCONF: Ejemplo:

Referencias adicionales

Documentos Relacionados

Estándares

MIB

RFC

Asistencia Técnica

Información sobre la Función NETCONF

Glosario


Protocolo de Configuración de Red


Primera publicación: De febrero el 28 de 2007
Última actualización: De junio el 15 de 2009

El protocolo de la configuración de red (NETCONF) define un mecanismo simple a través del cual un dispositivo de red pueda ser manejado, información de datos de configuración puede ser extraído, y los nuevos datos de configuración pueden ser cargados y ser manipulados. NETCONF utiliza el Lenguaje de marcado extensible (XML) - codificación basada de los datos para los datos de configuración y los mensajes de protocolo.

Usted puede utilizar el NETCONF sobre la característica SSHv2 para realizar las configuraciones de red vía el comando line interface(cli) de Cisco sobre un transporte cifrado. El administrador de la red NETCONF, que es el cliente NETCONF, debe utilizar el shell seguro versión 2 (SSHv2) como el transporte de la red al servidor NETCONF. Los clientes múltiples NETCONF pueden conectar con el servidor NETCONF.

Usted puede utilizar el NETCONF sobre la característica de la SEÑAL ACÚSTICA para enviar las notificaciones de cualquier cambio de configuración sobre NETCONF. Una notificación es un evento que indica que ha sucedido un cambio de configuración. El cambio puede ser una nueva configuración, una configuración eliminada o una configuración cambiada. Las notificaciones se envían en el final de una operación de la configuración exitosa como un mensaje que muestra el conjunto de los cambios, bastante que los mensajes individuales para cada línea en la configuración se cambia que.

El Exchange Protocol extensible de los bloques (SEÑAL ACÚSTICA) puede utilizar el perfil de la capa de la autenticación simple y de la Seguridad (SASL) para proporcionar simple y el mapeo directo al modelo de seguridad existente. Alternativamente, NETCONF sobre la SEÑAL ACÚSTICA puede utilizar el Transport Layer Security (TLS) para proporcionar un mecanismo de la encripción fuerte con la autenticación de servidor o la autenticación del costado del servidor y el cliente.

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 NETCONF”.

Utilice Cisco Feature Navigator para buscar información sobre el soporte de plataformas y el soporte de imágenes del software Cisco IOS y Catalyst OS. Para acceder a Cisco Feature Navigator, vaya a http://www.cisco.com/go/cfn. Una cuenta en Cisco.com no se requiere.

Contenido

Prerrequisitos de NETCONF

Restricciones de NETCONF

Información sobre NETCONF

Cómo Configurar NETCONF

Ejemplos de Configuración de NETCONF

Referencias adicionales

Información sobre la Función NETCONF

Glosario

Prerrequisitos de NETCONF

NETCONF sobre SSHv2 requiere que una línea del vty esté disponible para cada sesión NETCONF como se especifica en netconf max-session el comando.

Una línea del vty debe estar disponible para cada sesión NETCONF según lo especificado por netconf max-session el comando.

NETCONF sobre los módulos de escucha de la SEÑAL ACÚSTICA requieren SASL ser configurados.

Restricciones de NETCONF

NETCONF SSHv2 soporta un máximo de 16 sesiones concurrentes.

Solamente se soporta el SSH versión 2.

Usted debe funcionar con una imagen de criptografía para configurar la SEÑAL ACÚSTICA usando TLS.

Información sobre NETCONF

Para configurar NETCONF, usted debe entender los conceptos siguientes:

NETCONF sobre SSHv2

NETCONF over BEEP

Notificaciones NETCONF

NETCONF sobre SSHv2

Para ejecutar el NETCONF sobre la característica SSHv2, el cliente (un Cisco IOS Software corriente del dispositivo de Cisco) establece una conexión del transporte de SSH con el servidor (administrador de la red NETCONF). El cuadro 1 muestra un NETCONF básico sobre la configuración de red SSHv2. Las claves del intercambio del cliente y servidor para la Seguridad y la encripción de contraseña. La identificación del usuario y la contraseña de la sesión SSHv2 que ejecuta NETCONF se utilizan para la autorización y los fines de autenticación. Se aplica el nivel de privilegio del usuario y la sesión de cliente puede no tener acceso total a las operaciones NETCONF si no es el nivel de privilegio arriba bastante. Si se configura el Authentication, Authorization, and Accounting (AAA), se utiliza el servicio AAA como si un usuario hubiera establecido a una sesión SSH directamente al dispositivo. Usando la Configuración de seguridad existente hace la transición a NETCONF casi inconsútil. Una vez que han autenticado al cliente con éxito, el cliente invoca el protocolo de conexión SSH y establecen a la sesión SSH. Después de que establezcan a la sesión SSH, el usuario o la aplicación invoca NETCONF como un subsistema de SSH llamó el “netconf.”

Cuadro 1 NETCONF sobre SSHv2

Secure Shell Versión 2

SSHv2 se ejecuta encima de una capa de transporte confiable y proporciona las capacidades de la autenticación robusta y del cifrado. SSHv2 proporciona un medio para acceder y ejecutar con seguridad los comandos en otro equipo sobre una red.

NETCONF no soporta el SSH versión 1. La configuración para el servidor del SSH versión 2 es similar a la configuración para el SSH versión 1. Utilice ip ssh version el comando de especificar qué versión de SSH que usted quiere configurar. Si no se configura este comando, de forma predeterminada el SSH se ejecuta en el modo de compatibilidad; es decir, se honran las conexiones del SSH versión 1 y del SSH versión 2.


El SSH versión1 de la nota es un protocolo que nunca se ha definido en un estándar. Si usted no quisiera que su router recurriera al protocolo indefinido (versión 1), usted debe utilizar ip ssh version el comando y especificar la versión 2.


Utilice ip ssh rsa keypair-name el comando de habilitar una conexión SSH usando las claves del Rivest, del Shamir, y del Adelman (RSA) que usted ha configurado. Si usted configura ip ssh rsa keypair-name el comando con un nombre del par clave, se habilita SSH si existe el par clave, o SSH será habilitado si el par clave se genera más adelante. Si usted utiliza este comando de habilitar SSH, usted no necesita configurar un nombre de host y un Domain Name.

NETCONF over BEEP

El NETCONF sobre la característica de la SEÑAL ACÚSTICA permite que usted permita a la SEÑAL ACÚSTICA como el Transport Protocol para utilizar durante las sesiones NETCONF. Usando NETCONF sobre la SEÑAL ACÚSTICA, usted puede configurar el servidor NETCONF o al cliente NETCONF para iniciar una conexión, así soportando las Redes grandes intermitentemente de los dispositivos conectados, y de esos dispositivos que deban invertir la Conexión de Administración donde hay los Firewall y los traductores de dirección de red (NAT).

BEEP es un marco de protocolo de aplicación genérico para interacciones asíncronas orientadas a la conexión. Su objetivo es proporcionar las funciones que tradicionalmente se han duplicado en las distintas implementaciones del protocolo. Por lo general, BEEP se ejecuta por encima de TCP y permite el intercambio de mensajes. A diferencia de HTTP y protocolos similares, cualquier extremo de la conexión puede enviar un mensaje en cualquier momento. BEEP también incluye recursos de encripción y autenticación, y es muy ampliable.

El protocolo de la SEÑAL ACÚSTICA contiene un mecanismo que enmarca que los permisos simultáneos y los intercambios independientes de los mensajes entre los pares. Estos mensajes se estructuran generalmente usando el XML. Todos los intercambios ocurren en el contexto de un atascamiento a un aspecto bien definido de la aplicación, tal como Seguridad del transporte, autenticación de usuario, o intercambio de datos. Este atascamiento forma un canal; cada canal tiene un perfil asociado que defina el sintaxis y la semántica de los mensajes intercambiados.

La sesión de la SEÑAL ACÚSTICA se asocia sobre el servicio NETCONF. Cuando se establece una sesión, cada par de la SEÑAL ACÚSTICA hace publicidad de los perfiles que soporta. Durante la creación de un canal, el cliente (el iniciador de la SEÑAL ACÚSTICA) suministra uno o más perfiles propuestos para ese canal. Si el servidor (el módulo de escucha de la SEÑAL ACÚSTICA) crea el canal, selecciona uno de los perfiles y lo envía en una contestación. El servidor puede también indicar que ningunos de los perfiles son aceptables, y disminuyen la creación del canal.

La SEÑAL ACÚSTICA permite que los canales de intercambio de datos múltiples sean simultáneamente funcionando.

Aunque la SEÑAL ACÚSTICA sea un protocolo entre iguales, etiquetan a cada par según el papel que se está realizando en un momento dado. Cuando se establece una sesión de la SEÑAL ACÚSTICA, el par que aguarda las nuevas conexiones es el módulo de escucha de la SEÑAL ACÚSTICA. El otro par, que establece una conexión al módulo de escucha, es el iniciador de la SEÑAL ACÚSTICA. El par de la SEÑAL ACÚSTICA que comienza un intercambio es el cliente, y el otro par de la SEÑAL ACÚSTICA es el servidor. Típicamente, un par de la SEÑAL ACÚSTICA que actúa en la Función del servidor también se realiza en el papel que escucha. Sin embargo, porque la SEÑAL ACÚSTICA es un protocolo entre iguales, el par de la SEÑAL ACÚSTICA que los actos en la Función del servidor no se requieren también para realizarse en el papel que escucha.

Capa de la autenticación simple y de la Seguridad

El SASL es un método de norma de Internet para agregar el soporte de la autenticación a los protocolos basados en la conexión. SE puede utilizar SASL entre un dispositivo de seguridad y un servidor del Lightweight Directory Access Protocol (LDAP) para asegurar la autenticación del usuario.

Transport Layer Security

TLS es un protocolo de nivel de aplicación que preve la comunicación segura entre un cliente y servidor permitiendo la autenticación recíproca, el uso del hash para la integridad, y el cifrado para la aislamiento. TLS se basa en certificados, llaves públicas y llaves privadas.

Los Certificados son similares a los indicadores luminosos LED amarillo de la placa muestra gravedad menor del ID digital. Prueban la identidad del servidor a los clientes. Cada certificado incluye el nombre de la autoridad que lo publicó, el nombre de la entidad a la cual el certificado fue publicado, el clave pública de la entidad, y los sellos de fecha/hora que indican la fecha de vencimiento del certificado.

Las claves públicas y privadas son las cifras usadas para cifrar y para desencriptar la información. Aunque se comparta el clave pública, la clave privada nunca se da hacia fuera. Cada par clave público-privado funciona junto. Los datos cifrados con el clave pública se pueden desencriptar solamente con la clave privada.

Listas de acceso

Usted puede configurar opcionalmente las Listas de acceso para el uso con NETCONF sobre las sesiones SSHv2. Una lista de acceso es una colección secuencial de permiso y niega las condiciones que se aplican a los IP Addresses. El Cisco IOS Software prueba los direccionamientos contra las condiciones en una lista de acceso uno por uno. El primer emparejamiento determina si el software valida o rechaza el direccionamiento. Dado que el software detiene la prueba de condiciones después de la primera coincidencia, el orden de las condiciones es fundamental. Si ningunas condiciones hacen juego, el software rechaza el direccionamiento.

Las dos tareas principales implicadas al usar las Listas de acceso son como sigue:

1.Creando una lista de acceso especificando un número de lista de acceso o las condiciones del nombre y del acceso.

2.Aplicación de la lista de acceso a las interfaces o a las líneas de la terminal.

Para más información sobre configurar las Listas de acceso, vea la descripción de la lista de IP Access y crear una lista de IP Access y la aplicación de ella al los módulos de interfaz en la guía de configuración de la Seguridad de Cisco IOS: Sujeción del avión de los datos.

Notificaciones NETCONF

NETCONF envía las notificaciones de cualquier cambio de configuración sobre NETCONF. Una notificación es un evento que indica que ha ocurrido un cambio de configuración. El cambio puede ser una nueva configuración, una configuración eliminada o una configuración cambiada. Las notificaciones se envían en el final de una operación de la configuración exitosa como un mensaje que muestre el conjunto de los cambios bastante que mostrando los mensajes individuales para cada línea que se cambie en la configuración.

Cómo Configurar NETCONF

Esta sección contiene las siguientes tareas:

Habilitando el SSH versión 2 usando un nombre de host y un Domain Name (requeridos)

Habilitando el SSH versión 2 usando los pares claves RSA (requeridos)

Comenzando a una sesión encriptada con un dispositivo remoto (requerido)

Verificando el estatus de la conexión del shell seguro (opcional)

Habilitando NETCONF sobre SSHv2 (requerido)

Configurando un perfil SASL (requerido)

Habilitando NETCONF sobre la SEÑAL ACÚSTICA (requerida)

Configurando la aplicación de administrador de la red NETCONF (requerida)

Entregando las cargas útiles NETCONF (opcionales)

Notificaciones NETCONF que formatan (opcionales)

Monitoreando y mantener las sesiones NETCONF (opcionales)

Habilitación de SSH Versión 2 Usando un Nombre de Host y un Nombre de Dominio

Realice esta tarea de configurar a su router para el SSH versión 2 usando un nombre de host y un Domain Name. Usted puede también configurar el SSH versión 2 usando la configuración del par clave RSA (véase “habilitando el SSH versión 2 usando la sección de los pares claves RSA”).

PASOS SUMARIOS

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

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 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

hostname hostname

Example:

Router(config)# hostname host1

Configura un nombre de host para su router.

Paso 4 

ip domain-name name

Example:

Router(config)# ip domain-name domain1.com

Configura un nombre de dominio para el router.

Paso 5 

crypto key generate rsa

Example:

Router(config)# crypto key generate rsa

Habilita el servidor SSH para la autenticación local y remota.

Paso 6 

ip ssh [timeout seconds | authentication-retries integer]

Example:

Router(config)# ip ssh timeout 120

(Opcional) Configura variables de control SSH en su router.

Paso 7 

ip ssh version 2

Example:

Router(config)# ip ssh version 2

Especifica la versión de SSH que se ejecutará en su router.

Habilitación de SSH Versión 2 Usando Peers Llave RSA

Realice esta tarea de habilitar el SSH versión 2 sin configurar un nombre de host o un Domain Name. El SSH versión 2 será habilitado si existe el par clave que usted configura ya o si se genera más adelante. Usted puede también configurar el SSH versión 2 usando la configuración del nombre de host y del Domain Name. (Véase ““habilitando el SSH versión 2 usando sección del nombre de host y del Domain Name una”.)

PASOS SUMARIOS

1. enable

2. configure terminal

3. ip ssh rsa keypair-name keypair-name

4.crypto key generate rsa usage-keys labelkey-label módulo modulus-size

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

6. ip ssh version 2

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 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

ip ssh rsa keypair-name keypair-name
Example:

Router(config)# ip ssh rsa keypair-name sshkeys

Especifica qué par de llaves RSA se debe utilizar para el uso de SSH.

Observeel Cisco IOS que el router puede tener muchos pares claves RSA.

Paso 4 

crypto key generate rsa usage-keys label 
key-label modulus modulus-size
Example:
Router(config)# crypto key generate rsa 
usage-keys label sshkeys modulus 768

Habilita el servidor SSH para la autenticación local y remota en el router.

Para el SSH versión 2, los tamaños del módulo deben ser por lo menos 768 bits.

Observepara borrar el par clave RSA, utilice crypto key zeroize rsa el comando. Después de que usted haya borrado el comando rsa, usted inhabilita automáticamente el servidor SSH.

Paso 5 

ip ssh [timeout seconds | authentication-retries integer]

Example:
Router(config)# ip ssh timeout 120

Configura variables de control SSH en su router.

Paso 6 

ip ssh version 2

Example:
Router(config)# ip ssh version 2

Especifica la versión de SSH que se ejecutará en un router.

Inicio de una Sesión Encriptada con un Dispositivo Remoto

Realice esta tarea de comenzar a una sesión encriptada con un dispositivo de interconexión de redes remoto. (No hay que habilitar el router. SSH se puede ejecutar en el modo inhabilitado.)

De cualquier UNIX o Unix-como el dispositivo, el siguiente comando se utiliza típicamente de formar a una sesión SSH:

ssh -2 -s user@router.example.com netconf

PASOS SUMARIOS

1.ssh [-v {1 | 2}] [-c {3des | aes128-cbc | aes192-cbc | aes256-cbc}] [-m {hmac-md5 | hmac-md5-96 | hmac-sha1 | hmac-sha1-96}] del [userid]l [port-num]-o numberofpasswordprompts [n]-p {IP-addr | [command] del nombre de host}

PASOS DETALLADOS

 
Comando o acción
Propósito

Paso 1 

ssh [-v {1 | 2}] [-c {3des | aes128-cbc | aes192-cbc | aes256-cbc}] [-m {hmac-md5 | hmac-md5-96 | hmac-sha1 | hmac-sha1-96}] [l userid] [-o numberofpasswordprompts n] [-p port-num] {ip-addr | hostname} [command]

Example:

Router# ssh -v 2 -c aes256-cbc -m hmac-sha1-96 -l user2 10.76.82.24


o

Router# ssh -v 2 -c aes256-cbc -m hmac-sha1-96 
user2@10.76.82.24

Inicia una sesión encriptada con un dispositivo de red remoto.

El primer ejemplo se adhiere a los convenios del SSH versión 2. Una manera más natural y común de iniciar una sesión es conectando el nombre de usuario con el nombre de host. Por ejemplo, el segundo ejemplo de configuración proporciona un resultado final que sea idéntico al del primer ejemplo.

Consejos de Troubleshooting

ip ssh version El comando se puede utilizar para localizar averías su configuración SSH. Si prueba distintas versiones, podrá determinar qué versión de SSH tiene un problema.

Pasos Siguientes

Para más información sobre ssh el comando, vea la referencia de comandos de la Seguridad de Cisco IOS.

Verificar el estatus de la conexión del shell seguro

Realice esta tarea de visualizar el estatus de la conexión SSH en su router.

PASOS SUMARIOS

1. enable

2. show ssh

3. show ip ssh


Notausted puede utilizar los siguientes comandos show en el EXEC o el modo EXEC privilegiado del usuario.


PASOS DETALLADOS

 
Comando o acción
Propósito

Paso 1 

enable

Example:

Router> enable

(Opcional) Habilita el modo EXEC privilegiado.

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

Paso 2 

show ssh

Example:

Router# show ssh

Muestra el estado de las conexiones del servidor SSH.

Paso 3 

show ip ssh

Example:

Router# show ip ssh

Muestra los datos de versión y configuración de SSH.

Ejemplos

El producto siguiente show ssh del comando visualiza el estatus sobre las conexiones del SSH versión 2.

Router# 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.

El producto siguiente show ip ssh del comando visualiza la versión de SSH se habilita que, los valores de agotamiento del tiempo de la autenticación, y el número de autenticación revisa.

Router# show ip ssh

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

Habilitación de NETCONF over SSHv2

Realice esta tarea de habilitar NETCONF sobre SSHv2.

Prerrequisitos

SSHv2 debe ser habilitado.


La notaallí debe ser por lo menos tantas líneas del vty configuradas pues hay sesiones simultáneas NETCONF.


Restricciones

Se debe configurar como mínimo cuatro sesiones NETCONF simultáneas.

Se puede configurar un máximo de 16 sesiones NETCONF simultáneas.

NETCONF no soporta SSHv1.

PASOS SUMARIOS

1. enable

2. configure terminal

3.netconf ssh []aclaccess-list-number

4. netconf lock-time seconds

5. netconf max-sessions session

6. netconf max-message size

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 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

netconf ssh [acl access-list-number]

Example:

Router(config)# netconf ssh acl 1

Permisos NETCONF sobre SSHv2.

Opcionalmente, usted puede configurar un Access Control List para esta sesión NETCONF.

Paso 4 

netconf lock-time seconds

Example:

Router(config)# netconf lock-time 60

(Opcional) especifica el tiempo máximo, en los segundos, un bloqueo de la configuración NETCONF existe sin una operación intermedia.

El intervalo válido es 1 a 300. El valor predeterminado es 10 segundos.

Paso 5 

netconf max-sessions session

Example:

Router(config)# netconf max-sessions 5

(Opcional) Especifica el número máximo de sesiones NETCONF simultáneas permitidas.

El intervalo válido es 4 a 16. El valor predeterminado es 4.

Paso 6 

netconf max-message size

Example:

Router(config)# netconf max-message 37283

(Opcional) especifica los tamaños máximos, en los kilobytes (KB), porque los mensajes recibidos en una sesión NETCONF.

El intervalo válido es 1 a 2147483. El valor predeterminado es infinito.

Para fijar los tamaños máximos a infinito, utilice no netconf max-message el comando.

Configuración de un Perfil SASL

Para habilitar NETCONF sobre la SEÑAL ACÚSTICA usando SASL, usted debe primero configurar un perfil SASL, que especifica no prohiben qué usuarios el acceso en el router. Realice esta tarea de configurar un perfil SASL.

PASOS SUMARIOS

1. enable

2. configure terminal

3. sasl profile profile-name

4. mechanism digest-md5

5. server user-name password password

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 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

sasl profile profile-name

Example:

Router(config)# sasl profile beep

Configura un perfil SASL y ingresa el modo de la configuración del perfil SASL.

Paso 4 

mechanism digest-md5

Example:

Router(config-SASL-profile)# mechanism digest-md5

Configura el mecanismo del perfil SASL.

Paso 5 

server user-name password password

Example:

Router(config-SASL-profile)# server user1 password password1

Configura un servidor SASL.

Habilitación de NETCONF over BEEP

Realice esta tarea de habilitar NETCONF sobre la SEÑAL ACÚSTICA.

Prerrequisitos

Debe haber por lo menos tantas líneas del vty configuradas pues hay sesiones simultáneas NETCONF.

Si usted configura NETCONF sobre la SEÑAL ACÚSTICA usando SASL, usted debe primero configurar un perfil SASL.

Restricciones

Se debe configurar como mínimo cuatro sesiones NETCONF simultáneas.

Se puede configurar un máximo de 16 sesiones NETCONF simultáneas.

PASOS SUMARIOS

1. enable

2. configure terminal

3. crypto key generate rsa general-keys

4. crypto pki trustpoint name

5. enrollment url url

6. subject-name name

7.revocation-check method1 [[]method2method3]

8. exit

9. crypto pki authenticate name

10. crypto pki enroll name

11. netconf lock-time seconds

12. line vty line-number []ending-line-number

13. netconf max-sessions session

14. netconf beep initiator {hostname | ip-address}port-number []sasl-user sasl-password del []encrypt trustpointde la contraseña del usuarioreconnect-time seconds

15. netconf beep listener []port-numberdel []aclaccess-list-numberdel []sasl sasl-profiledel []encrypt trustpoint

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 

configure terminal

Example:

Router# configure terminal

Ingresa en el modo de configuración global.

Paso 3 

crypto key generate rsa general-keys

Example:

Router(config)# crypto key generate rsa general-keys

Genera los pares claves RSA y especifica que el par clave de fines generales debe ser generado.

Realice este paso solamente una vez.

Paso 4 

crypto pki trustpoint name

Example:

Router(config)# crypto pki trustpoint my_trustpoint

Declara el trustpoint que su router debe utilizar y entra en el modo de configuración de ca-trustpoint.

Paso 5 

enrollment url url

Example:

Router(ca-trustpoint)# enrollment url http://10.2.3.3:80

Especifica los parámetros de la inscripción de un Certification Authority (CA).

Paso 6 

subject-name name

Example:

Router(ca-trustpoint)# subject-name CN=dns_name_of_host.com

Especifica los asuntos en el pedido de certificado.

Observelos asuntos debe ser el nombre del Sistema de nombres de dominio (DNS) del dispositivo.

Paso 7 

revocation-check method1 [method2[method3]]

Example:

Router(ca-trustpoint)# revocation-check none

Verifica el estado de revocación de un certificado.

Paso 8 

exit

Example:

Router(ca-trustpoint)# exit

Sale del modo de configuración de CA-trustpoint y vuelve al modo de configuración global.

Paso 9 

crypto pki authenticate name

Example:

Router(config)# crypto pki authenticate my_trustpoint

Autentica las autoridades de certificación (consiguiendo el certificado de CA).

Paso 10 

crypto pki enroll name

Example:

Router(config)# crypto pki enroll my_trustpoint

Obtiene el certificado o los Certificados para su router de CA.

Paso 11 

netconf lock-time seconds

Example:

Router(config)# netconf lock-time 60

(Opcional) especifica el tiempo máximo que un bloqueo de la configuración NETCONF existe sin una operación intermedia.

El rango de valor válido para el argumento de los segundos es 1 a 300 segundos. El valor predeterminado es 10 segundos.

Paso 12 

line vty line-number [ending-line-number]

Example:

Router(config)# line vty 0 15

Identifica una línea de terminal virtual específica para el acceso de la consola remota.

Usted debe configurar el mismo número de líneas del vty que las sesiones máximas NETCONF.

Paso 13 

netconf max-sessions session

Example:

Router(config)# netconf max-sessions 16

(Opcional) Especifica el número máximo de sesiones NETCONF simultáneas permitidas.

Paso 14 

netconf beep initiator {hostname | ip-address} port-number user sasl-user password sasl-password [encrypt trustpoint] [reconnect-time seconds]

Example:

Router(config)# netconf beep initiator host1 23 user user1 password password1 encrypt 23 reconnect-time 60

(Opcional) especifica la SEÑAL ACÚSTICA como el Transport Protocol para las sesiones NETCONF y configura a un par como el iniciador de la SEÑAL ACÚSTICA.

La notarealiza este paso para configurar una sesión del iniciador de la SEÑAL ACÚSTICA NETCONF. Usted puede configurar también opcionalmente una sesión del módulo de escucha de la SEÑAL ACÚSTICA.

Paso 15 

netconf beep listener [port-number] [acl access-list-number] [sasl sasl-profile] [encrypt trustpoint]

Example:

Router(config)# netconf beep listener 26 acl 101 sasl profile1 encrypt 25

(Opcional) especifica la SEÑAL ACÚSTICA como el Transport Protocol para NETCONF y configura a un par como el módulo de escucha de la SEÑAL ACÚSTICA.

La notarealiza este paso para configurar una sesión del módulo de escucha de la SEÑAL ACÚSTICA NETCONF. Usted puede configurar también opcionalmente una sesión del iniciador de la SEÑAL ACÚSTICA.

Configuración de la Aplicación del Administrador de Redes de NETCONF


Paso 1Utilice la cadena siguiente CLI para configurar la aplicación de administrador de la red NETCONF para invocar NETCONF como subsistema de SSH:

Unix Side: ssh-2 -s companyname@10.1.1.1 netconf

Paso 2Tan pronto como se establezca la sesión NETCONF, indique las Capacidades del servidor enviando un documento XML que contiene un <hello>:

<?xml version="1.0" encoding="UTF-8"?>
    <hello>
      <capabilities>
        <capability>
            urn:ietf:params:xml:ns:netconf:base:1.0
          </capability>
          <capability>
            urn:ietf:params:ns:netconf:capability:startup:1.0
          </capability>
       </capabilities>
    <session-id>4<session-id>
</hello>]]>]]>

El cliente también responde enviando un documento XML que contiene un <hello>:

<?xml version="1.0" encoding="UTF-8"?>
 <hello>
   <capabilities>
       <capability>
           urn:ietf:params:xml:ns:netconf:base:1.0
     </capability>
    </capabilities>
</hello>]]>]]>

Observeaunque el ejemplo muestra el servidor que envía un mensaje del <hello> seguido por el mensaje de cliente, los ambos lados envían el mensaje tan pronto como se inicialice el subsistema NETCONF, quizás simultáneamente.



Inclinetodas las peticiones NETCONF debe terminar con]] >]] > que denota un extremo a la petición. Hasta]] >]] > se envía la secuencia, el dispositivo no procesará la petición.


Vea “configurar NETCONF sobre SSHv2: Sección del ejemplo” por un ejemplo específico.

Paso 3Utilice la cadena siguiente XML para permitir a la aplicación de administrador de la red NETCONF para enviar y para recibir las notificaciones NETCONF:

<?xml version="1.0" encoding="UTF-8" ?> 
<rpc message-id="9.0"><notification-on/>
</rpc>]]>]]>

Paso 4Utilice la cadena siguiente XML para parar la aplicación de administrador de la red NETCONF de enviar o de recibir las notificaciones NETCONF:

<?xml version="1.0" encoding="UTF-8" ?> 
<rpc message-id="9.13"><notification-off/>
</rpc>]]>]]>

Entrega de las cargas útiles NETCONF

Utilice la cadena siguiente XML para entregar el payload NETCONF a la aplicación de administrador de la red:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.cisco.com/cpi_10/schema" 
elementFormDefault="qualified" attributeFormDefault="unqualified" 
xmlns="http://www.cisco.com/cpi_10/schema" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <!--The following elements define the cisco extensions for the content of the filter 
element in a <get-config> request. They allow the client to specify the format of the 
response and to select subsets of the entire configuration to be included.-->
   <xs:element name="config-format-text-block">
      <xs:annotation>
         <xs:documentation>If this element appears in the filter, then the cllient is 
requesting that the response data be sent in config command block 
format.</xs:documentation>
      </xs:annotation>
      <xs:complexType>
         <xs:sequence>
            <xs:element ref="text-filter-spec" minOccurs="0"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:element name="config-format-text-cmd">
      <xs:complexType>
         <xs:sequence>
            <xs:element ref="text-filter-spec"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:element name="config-format-xml">
      <xs:annotation>
         <xs:documentation>When this element appears in the filter of a get-config 
request, the results are to be returned in E-DI XML format. The content of this element is 
treated as a filter.</xs:documentation>
      </xs:annotation>
      <xs:complexType>
         <xs:complexContent>
            <xs:extension base="xs:anyType"/>
         </xs:complexContent>
      </xs:complexType>
   </xs:element>
   <!--These elements are used in the filter of a <get> to specify operational data to 
return.-->
   <xs:element name="oper-data-format-text-block">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="show" type="xs:string" maxOccurs="unbounded"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:element name="oper-data-format-xml">
      <xs:complexType>
         <xs:sequence>
            <xs:any/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <!--When confing-format-text format is specified, the following describes the content 
of the data element in the response-->
   <xs:element name="cli-config-data">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="cmd" type="xs:string" maxOccurs="unbounded">
               <xs:annotation>
                  <xs:documentation>Content is a command. May be multiple 
lines.</xs:documentation>
               </xs:annotation>
            </xs:element>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:element name="cli-config-data-block" type="xs:string">
      <xs:annotation>
         <xs:documentation>The content of this element is the device configuration as it 
would be sent to a terminal session. It contains embedded newline characters that must be 
preserved as they represent the boundaries between the individual command 
lines</xs:documentation>
      </xs:annotation>
   </xs:element>
   <xs:element name="text-filter-spec">
      <xs:annotation>
         <xs:documentation>If this element is included in the config-format-text element, 
then the content is treated as if the string was appended to the "show running-config" 
command line.</xs:documentation>
      </xs:annotation>
   </xs:element>
   <xs:element name="cli-oper-data-block">
      <xs:complexType>
         <xs:annotation>
            <xs:documentation> This element is included in the response to get operation. 
Content of this element is the operational data in text format.</xs:documentation>
         </xs:annotation>
         <xs:sequence>
            <xs:element name="item" maxOccurs="unbounded">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="show"/>
                     <xs:element name="response"/>
                  </xs:sequence>
               </xs:complexType>
            </xs:element>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:schema>

Notificaciones NETCONF que formatan

La aplicación de administrador de la red NETCONF utiliza los archivos del esquema .xsd para describir el formato de los mensajes de notificación XML NETCONF que son enviados entre una aplicación de administrador de la red NETCONF y un router que ejecutan NETCONF sobre SSHv2 o la SEÑAL ACÚSTICA. Estos archivos se pueden visualizar en un navegador o una herramienta de la lectura del esquema. Usted puede utilizar este el esquema a validar que el XML está correcto. Este el esquema describe el formato, no el contenido, de los datos que son intercambiados.

NETCONF utiliza la función del <edit-config> para cargar toda la configuración especificada a una configuración deseada especificada. Cuando se ingresa esta nueva configuración, la configuración deseada no se substituye. La configuración deseada se cambia según los datos y las operaciones solicitadas de la fuente solicitante.

Los siguientes son esquemas para la función del <edit-config> NETCONF en el bloque CLI, CLI, y el formato XML.

Solicitud de NETCONF <edit-config>: Formato CLI

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <edit-config>
      <target>
         <running/>
      </target>
      <config>
         <cli-config-data>
<cmd>hostname test</cmd>
            <cmd>interface fastEthernet0/1</cmd>
            <cmd>ip address 192.168.1.1 255.255.255.0</cmd>
</cli-config-data>
      </config>
   </edit-config>
</rpc>]]>]]>

Respuesta de <edit-config> NETCONF: Formato CLI

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:netconf:base:1.0">
   <ok/>
</rpc-reply>]]>]]>

Solicitud de NETCONF <edit-config>: formato CLI-Block

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="netconf.mini.edit.3">
   <edit-config>
      <target>
         <running/>
      </target>
      <config>
         <cli-config-data-block>
            hostname bob
            interface fastEthernet0/1
            ip address 192.168.1.1 255.255.255.0
         </cli-config-data-block>
      </config>
   </edit-config>
</rpc>]]>]]>

Respuesta de <edit-config> NETCONF: formato CLI-Block

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc-reply message-id="netconf.mini.edit.3" xmlns="urn:ietf:params:netconf:base:1.0">
   <ok/>
</rpc-reply>]]>]]>

Los siguientes son esquemas para la función del <get-config> NETCONF en el CLI y el formato del CLI-bloque.

Solicitud NETCONF <get-config>: Formato CLI

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <get-config>
      <source>
         <running/>
      </source>
      <filter>
         <config-format-text-cmd>
            <text-filter-spec> | inc interface </text-filter-spec>
         </config-format-text-cmd>
</filter>
   </get-config>
</rpc>]]>]]>

NETCONF <get-config> Respuesta: Formato CLI

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <data>
      <cli-config-data>
         <cmd>interface FastEthernet0/1</cmd>
         <cmd>interface FastEthernet0/2</cmd>
      </cli-config-data>
   </data>
</rpc-reply>]]>]]>

Solicitud NETCONF <get-config>: formato CLI-Block

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <get-config>
      <source>
         <running/>
      </source>
      <filter>
         <config-format-text-block>
            <text-filter-spec> | inc interface </text-filter-spec>
         </config-format-text-block>
      </filter>
   </get-config>
</rpc>]]>]]>

NETCONF <get-config> Respuesta: formato CLI-Block

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <data>
      <cli-config-data-block>
         interface FastEthernet0/1
         interface FastEthernet0/2
      </cli-config-data-block>
   </data>
</rpc-reply>]]>]]>

NETCONF utiliza la función del <get> para extraer la información de la configuración y del dispositivo-estado. El formato del <get> NETCONF es el equivalente de un comando cisco ios show . El parámetro del <filter> especifica la porción de los datos de la configuración del sistema y del dispositivo-estado para extraer. Si el parámetro del <filter> está vacío, no se vuelve nada.

Los siguientes son esquemas para la función del <get> en el CLI y el formato del CLI-bloque.

Solicitud <get> de NETCONF: Formato CLI

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <get>
       <filter>
          <config-format-text-cmd>
             <text-filter-spec> | include interface </text-filter-spec>
          </config-format-text-cmd>
          <oper-data-format-text-block>
             <show>interfaces</show>
             <show>arp</show>
          </oper-data-format-text-block>
       </filter>
    </get>
 </rpc>]]>]]>

Respuesta <get> de NETCONF: Formato CLI

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <data>
       <cli-config-data>
<cmd>interface Loopback0</cmd>
<cmd>interface GigabitEthernet0/1</cmd>
<cmd>interface GigabitEthernet0/2</cmd>
</cli-config-data>
<cli-oper-data-block>
          <item>
             <show>interfaces</show>
             <response>
                <!-- output of "show interfaces" ------>
             </response>
          <show>arp</show>
          <item>
             <show>arp</show>
             <response>
                <!-- output of "show arp" ------>
             </response>
          </item>
       </cli-oper-data-block>
    </data>
</rpc-reply>]]>]]>

Solicitud <get> de NETCONF: formato CLI-Block

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <get>
       <filter>
          <config-format-text-block>
             <text-filter-spec> | include interface </text-filter-spec>
          </config-format-text-block>
          <oper-data-format-text-block>
             <show>interfaces</show>
             <show>arp</show>
          </oper-data-format-text-block>
       </filter>
    </get>
 </rpc>]]>]]>

Respuesta <get> de NETCONF: formato CLI-Block

<?xml version="1.0" encoding=\"UTF-8\"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <data>
       <cli-config-data-block>
interface Loopback0
interface GigabitEthernet0/1
interface GigabitEthernet0/2

       </cli-config-data-block>
       <cli-oper-data-block>
          <item>
             <show>interfaces</show>
             <response>
                <!-- output of "show interfaces" ------>
             </response>
          <show>arp</show>
          <item>
             <show>arp</show>
             <response>
                <!-- output of "show arp" ------>
             </response>
          </item>
       </cli-oper-data-block>
    </data>
</rpc-reply>]]>]]>

Monitoreando y mantener las sesiones NETCONF

Realice esta tarea de monitorear y de mantener las sesiones NETCONF.

Restricciones

Se debe configurar como mínimo cuatro sesiones NETCONF simultáneas.

Se puede configurar un máximo de 16 sesiones NETCONF simultáneas.

NETCONF no soporta SSHv1.

PASOS SUMARIOS

1. enable

2.show netconf {counters | session | schema}

3.debug netconf{all | error}

4.clear netconf {counters | sessions}

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 netconf {counters | session | schema}

Example:

Router# show netconf counters

Información de las visualizaciones NETCONF.

Paso 3 

debug netconf {all | error}

Example:

Router# debug netconf error

Habilita el debugging de las sesiones NETCONF.

Paso 4 

clear netconf {counters | sessions}

Example:

Router# clear netconf sessions

Los contadores de las estadísticas de los claros NETCONF y las sesiones NETCONF, y liberan los recursos y los bloqueos asociados.

Ejemplos de Configuración de NETCONF

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

Habilitación de SSHv2 con un Nombre de Host y un Nombre de Dominio: Ejemplo:

Habilitación de Secure Shell versión 2 mediante Llaves RSA: Ejemplo:

Inicio de una Sesión Encriptada con un Dispositivo Remoto: Ejemplo:

Configuración de NETCONF over SSHv2: Ejemplo:

Configuración de NETCONF sobre BEEP: Ejemplo:

Configuración de la Aplicación del Administrador de Redes de NETCONF: Ejemplo:

Monitoreo de Sesiones NETCONF: Ejemplo:

Habilitación de SSHv2 con un Nombre de Host y un Nombre de Dominio: Ejemplo:

Las demostraciones del siguiente ejemplo cómo configurar SSHv2 usando un nombre de host y un Domain Name:

Router# configure terminal

Router(config)# hostname host1

Router(config)# ip domain-name domain1.com

Router(config)# crypto key generate rsa

Router(config)# ip ssh timeout 120

Router(config)# ip ssh version 2

Habilitación de Secure Shell versión 2 mediante Llaves RSA: Ejemplo:

Las demostraciones del siguiente ejemplo cómo configurar SSHv2 usando las claves RSA:

Router# configure terminal

Router(config)# ip ssh rsa keypair-name sshkeys

Router(config)# crypto key generate rsa usage-keys label sshkeys modulus 768
Router(config)# ip ssh timeout 120
Router(config)# ip ssh version 2

Inicio de una Sesión Encriptada con un Dispositivo Remoto: Ejemplo:

Las demostraciones del siguiente ejemplo cómo comenzar a una sesión SSH cifrada con un dispositivo de interconexión de redes remoto, de cualquier UNIX o Unix-como el dispositivo:

Router(config)# ssh -2 -s user@router.example.com netconf

Configuración de NETCONF over SSHv2: Ejemplo:

Las demostraciones del siguiente ejemplo cómo configurar NETCONF sobre SSHv2:

Router# configure terminal
Router(config)# netconf ssh acl 1
Router(config)# netconf lock-time 60
Router(config)# netconf max-sessions 5
Router(config)# netconf max-message 2345
Router# ssh-2 -s username@10.1.1.1 netconf

Las demostraciones del siguiente ejemplo cómo conseguir la configuración para el Loopback Interface 113.


Paso 1Primero, envíe “hola”:

<?xml version="1.0" encoding=\"UTF-8\"?>
<hello><capabilities>
     <capability>u?rn:ietf:params:netconf:base:1.0</capability>
      <capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability>
       <capability>urn:ietf:params:netconf:ca?pability:roll?back-on-error:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
         <capability>urn:ietf:params:netconf:ca?pability:url:?1.0</capability>
        <capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability>
       <capability>urn:cisco:params:netconf:capabili?ty:notificati?on:1.0</capability>
   </capabilities>
</hello>]]>]]> 

Paso 2Después, envíe la petición de los GET-config:

<?xml version="1.0"?>
<rpc 
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"xmlns:cpi="http://www.cisco.com/cpi_10/sche
ma" message-id="101">
   <get-config> 
        <source> 
             <running/> 
         </source> 
          <filter> 
              <config-format-text-cmd>
               <text-filter-spec>
        interface Loopback113
                 </text-filter-spec>
              </config-format-text-cmd> 
          </filter> 
      </get-config> 
</rpc>]]>]]>

El producto siguiente se muestra en el router:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101"xmlns=\"urn:ietf:params:netconf:base:1.0\">
   <data>
      <cli-config-data>
interface Loopback113
description test456
no ip address
load-interval 30
end
       </cli-config-data>
    </data>
</rpc-rep?ly>]]>]]>

Configuración de NETCONF sobre BEEP: Ejemplo:

Las demostraciones del siguiente ejemplo cómo configurar NETCONF sobre la SEÑAL ACÚSTICA:

Router# configure terminal

Router(config)# crypto key generate rsa general-keys 
Router(ca-trustpoint)# crypto pki trustpoint my_trustpoint 
Router(ca-trustpoint)# enrollment url http://10.2.3.3:80
Router(ca-trustpoint)# subject-name CN=dns_name_of_host.com
Router(ca-trustpoint)# revocation-check none
 
Router(ca-trustpoint)# crypto pki authenticate my_trustpoint 
Router(ca-trustpoint)# crypto pki enroll my_trustpoint 
Router(ca-trustpoint)# line vty 0 15 
Router(ca-trustpoint)# exit
Router(config)# netconf lock-time 60 
Router(config)# netconf max-sessions 16 

Router(config)# netconf beep initiator host1 23 user my_user password my_password encrypt 
my_trustpoint reconnect-time 60 

Router(config)# netconf beep listener 23 sasl user1 encrypt my_trustpoint

Configuración de la Aplicación del Administrador de Redes de NETCONF: Ejemplo:

Las demostraciones del siguiente ejemplo cómo configurar la aplicación de administrador de la red NETCONF para invocar NETCONF como subsistema de SSH:

Unix Side: ssh-2 -s companyname@10.1.1.1 netconf

Tan pronto como se establezca la sesión NETCONF, indique las Capacidades del servidor enviando un documento XML que contiene un <hello>:

<?xml version="1.0" encoding="UTF-8"?>
    <hello>
      <capabilities>
        <capability>
            urn:ietf:params:xml:ns:netconf:base:1.0
          </capability>
          <capability>
            urn:ietf:params:ns:netconf:capability:startup:1.0
          </capability>
       </capabilities>
    <session-id>4<session-id>
</hello>]]>]]>

El cliente también responde enviando un documento XML que contiene un <hello>:

<?xml version="1.0" encoding="UTF-8"?>
 <hello>
   <capabilities>
       <capability>
           urn:ietf:params:xml:ns:netconf:base:1.0
     </capability>
    </capabilities>
</hello>]]>]]>

Utilice la cadena siguiente XML para permitir a la aplicación de administrador de la red NETCONF para enviar y para recibir las notificaciones NETCONF:

<?xml version="1.0" encoding="UTF-8" ?> 
<rpc message-id="9.0"><notification-on/>
</rpc>]]>]]>

Utilice la cadena siguiente XML para parar la aplicación de administrador de la red NETCONF de enviar o de recibir las notificaciones NETCONF:

<?xml version="1.0" encoding="UTF-8" ?> 
<rpc message-id="9.13"><notification-off/>
</rpc>]]>]]>

Monitoreo de Sesiones NETCONF: Ejemplo:

A continuación se da un ejemplo de salida del comando: show netconf counters

Router# show netconf counters

NETCONF Counters
Connection Attempts:0: rejected:0 no-hello:0 success:0
Transactions
        total:0, success:0, errors:0
detailed errors:
        in-use 0        invalid-value 0         too-big 0 
        missing-attribute 0     bad-attribute 0         unknown-attribute 0 
        missing-element 0       bad-element 0   unknown-element 0 
        unknown-namespace 0     access-denied 0         lock-denied 0 
        resource-denied 0       rollback-failed 0       data-exists 0 
        data-missing 0  operation-not-supported 0       operation-failed 0 
        partial-operation 0 

A continuación se da un ejemplo de salida del comando: show netconf session

Router# show netconf session

(Current | max) sessions:   3 | 4
Operations received: 100               Operation errors: 99
Connection Requests: 5                 Authentication errors: 2   Connection Failures: 0
ACL dropped : 30
Notifications  Sent: 20

La salida show netconf schema del comando describe la estructura de elemento para una petición NETCONF y la contestación resultante. Este esquema se puede utilizar para construir las peticiones apropiadas NETCONF y analizar resultar contesta. Los Nodos en el esquema se definen en el RFC 4741. A continuación se da un ejemplo de salida del comando: show netconf schema

Router# show netconf schema

New Name Space 'urn:ietf:params:xml:ns:netconf:base:1.0'
<VirtualRootTag> [0, 1] required
  <rpc-reply> [0, 1] required
    <ok> [0, 1] required
    <data> [0, 1] required
    <rpc-error> [0, 1] required
      <error-type> [0, 1] required
      <error-tag> [0, 1] required
      <error-severity> [0, 1] required
      <error-app-tag> [0, 1] required
      <error-path> [0, 1] required
      <error-message> [0, 1] required
      <error-info> [0, 1] required
        <bad-attribute> [0, 1] required
        <bad-element> [0, 1] required
        <ok-element> [0, 1] required
        <err-element> [0, 1] required
        <noop-element> [0, 1] required
        <bad-namespace> [0, 1] required
        <session-id> [0, 1] required
  <hello> [0, 1] required
    <capabilities> 1 required
      <capability> 1+ required
  <rpc> [0, 1] required
    <close-session> [0, 1] required
    <commit> [0, 1] required
      <confirmed> [0, 1] required
      <confirm-timeout> [0, 1] required
    <copy-config> [0, 1] required
      <source> 1 required
        <config> [0, 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
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
      <target> 1 required
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
    <delete-config> [0, 1] required
      <target> 1 required
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
    <discard-changes> [0, 1] required
    <edit-config> [0, 1] required
      <target> 1 required
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
      <default-operation> [0, 1] required
      <test-option> [0, 1] required
      <error-option> [0, 1] required
      <config> 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
    <get> [0, 1] required
      <filter> [0, 1] required
        <config-format-text-cmd> [0, 1] required
          <text-filter-spec> [0, 1] required
        <config-format-text-block> [0, 1] required
          <text-filter-spec> [0, 1] required
        <config-format-xml> [0, 1] required
        <oper-data-format-text-block> [0, 1] required
          <show> 1+ required
        <oper-data-format-xml> [0, 1] required
          <show> 1+ required
    <get-config> [0, 1] required
      <source> 1 required
        <config> [0, 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
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
      <filter> [0, 1] required
        <config-format-text-cmd> [0, 1] required
          <text-filter-spec> [0, 1] required
        <config-format-text-block> [0, 1] required
          <text-filter-spec> [0, 1] required
        <config-format-xml> [0, 1] required
    <kill-session> [0, 1] required
      <session-id> [0, 1] required
    <lock> [0, 1] required
      <target> 1 required
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
    <unlock> [0, 1] required
      <target> 1 required
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
    <validate> [0, 1] required
      <source> 1 required
        <config> [0, 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
        <candidate> [0, 1] required
        <running> [0, 1] required
        <startup> [0, 1] required
        <url> [0, 1] required
    <notification-on> [0, 1] required
    <notification-off> [0, 1] required

Referencias adicionales

Las secciones siguientes proporcionan las referencias relacionadas con la característica NETCONF.

Documentos Relacionados

Tema relacionado
Título del documento

Listas de IP Access

Descripción de la lista de IP Access y crear una lista de IP Access y aplicación de ella al módulos de interfaz en la guía de configuración de la Seguridad de Cisco IOS: Sujeción del avión de los datos.

Shell seguro y versión 2 del shell seguro

Módulo de la “configuración de Secure Shell” en la guía de configuración de la Seguridad de Cisco IOS: Sujeción de los servicios de usuario.

Comandos NETCONF: sintaxis de comandos completa, modo de comandos, historial de comandos, valores predeterminados, directrices de uso y ejemplos

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

Comandos de las listas de IP Access: sintaxis de comandos completa, modo de comandos, historial de comandos, valores predeterminados, directrices de uso y ejemplos

Comandos de seguridad: sintaxis de comandos completa, modo de comandos, historial de comandos, valores predeterminados, directrices de uso y ejemplos

Referencia de Comandos de Seguridad de Cisco IOS


Estándares

Estándar
Título

Ninguno


MIB

MIB
Link del MIB

Ninguno

Para localizar y descargar MIB de plataformas, versiones de Cisco IOS y conjuntos de funciones seleccionados, utilice Cisco MIB Locator, que se encuentra en la siguiente URL:

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


RFC

RFC
Título

RFC 2222

Capa de la autenticación simple y de la Seguridad (SASL)

RFC2246

La versión 1.0 del protocolo TLS

RFC 3080

La base extensible del Exchange Protocol de los bloques

RFC 4251

La arquitectura del protocolo del Secure Shell (SSH)

RFC 4252

El protocolo de autenticación del Secure Shell (SSH)

RFC 4741

Protocolo de configuración NETCONF

RFC 4742

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

RFC 4744

Usando el protocolo NETCONF sobre el Exchange Protocol extensible de los bloques (SEÑAL ACÚSTICA)


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 sobre la Función NETCONF

La tabla 1 muestra las funciones de este módulo y proporciona links a información de configuración específica.

Puede que no estén disponibles todos los comandos en su versión de software de Cisco IOS. Para la información de versión sobre un comando específico, vea la documentación de referencia de comandos.

Utilice el Cisco Feature Navigator para encontrar la información sobre el soporte del Soporte de la plataforma y de la imagen del software. Cisco Feature Navigator le permite determinar qué imágenes de Cisco IOS y Catalyst OS Software soportan una versión de software, un conjunto de funciones o una plataforma específica. 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 1 solamente la versión de Cisco IOS Software que introdujo el soporte para una característica dada en un tren de versión del Cisco IOS Software dado. A menos que se indique lo contrario, las versiones posteriores de dicha serie de versiones de software de Cisco IOS también soportan esa función.


Información de la característica del cuadro 1 para NETCONF 

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

NETCONF sobre SSHv2

12.2(33)SRA
12.4(9)T
12.2(33)SB
12.2(33)SXI

El NETCONF sobre la característica SSHv2 le permite para realizar las configuraciones de red vía el comando line interface(cli) de Cisco sobre un transporte cifrado.

El protocolo NETCONF define un mecanismo simple a través del cual un dispositivo de red pueda ser manejado, información de datos de configuración puede ser extraído, y los nuevos datos de configuración pueden ser cargados y ser manipulados. NETCONF utiliza un Lenguaje de marcado extensible (XML) - codificación basada de los datos para los datos de configuración y los mensajes de protocolo.

Esta función se introdujo en la versión 12.4(9)T.

Las secciones siguientes proporcionan información acerca de esta función:

NETCONF sobre SSHv2

Notificaciones NETCONF

Habilitación de SSH Versión 2 Usando un Nombre de Host y un Nombre de Dominio

Habilitación de SSH Versión 2 Usando Peers Llave RSA

Habilitación de NETCONF over SSHv2

Configuración de la Aplicación del Administrador de Redes de NETCONF

Configuración de NETCONF over SSHv2: Ejemplo:

Los siguientes comandos fueron introducidos o modificados por esta característica: clear netconf debug netconf netconf lock-time netconf max-sessions netconf ssh show netconf.

Acceso NETCONF para la configuración sobre la SEÑAL ACÚSTICA

12.4(9)T
12.2(33)SRB
12.2(33)SB
12.2(33)SXI

El NETCONF sobre la característica de la SEÑAL ACÚSTICA permite que usted permita al servidor NETCONF o al cliente NETCONF para iniciar una conexión, así soportando las Redes grandes intermitentemente de los dispositivos conectados y de esos dispositivos que deben invertir la Conexión de Administración donde hay los Firewall y los traductores de dirección de red (NAT).

Esta función se introdujo en la versión 12.4(9)T.

Las secciones siguientes proporcionan información acerca de esta función:

NETCONF over BEEP

Notificaciones NETCONF

Configuración de un Perfil SASL

Habilitación de NETCONF over BEEP

Configuración de la Aplicación del Administrador de Redes de NETCONF

Configuración de NETCONF over SSHv2: Ejemplo:

Los siguientes comandos fueron introducidos o modificados por esta característica: netconf beep initiator netconf beep listener.


Glosario

SEÑAL ACÚSTICA — Exchange Protocol extensible de los bloques. Un marco genérico del Application Protocol para las interacciones orientadas a la conexión, asíncronas.

NETCONF — Protocolo de la configuración de red. Un protocolo que define un mecanismo simple a través del cual un dispositivo de red pueda ser manejado, información de datos de configuración puede ser extraído, y los nuevos datos de configuración pueden ser cargados y ser manipulados.

SASL — Capa de la autenticación simple y de la Seguridad. Un método de norma de Internet para agregar el soporte de la autenticación a los protocolos basados en la conexión. SE puede utilizar SASL entre un dispositivo de seguridad y un servidor del Lightweight Directory Access Protocol (LDAP) para asegurar la autenticación del usuario.

SSHv2 — Los funcionamientos de SSH de la versión 2. del shell seguro encima de una capa de transporte confiable y proporcionan las capacidades de la autenticación robusta y del cifrado. SSHv2 proporciona un medio para acceder y ejecutar con seguridad los comandos en otro equipo sobre una red.

TLS — Transport Layer Security. Un protocolo de nivel de aplicación que preve la comunicación segura entre un cliente y servidor permitiendo la autenticación recíproca, el uso del hash para la integridad, y el cifrado para la aislamiento. TLS se basa en certificados, llaves públicas y llaves privadas.

XML — Lenguaje de marcado extensible. Un estándar mantenido por el World Wide Web Consortium (W3C) que define un sintaxis que le deje crear los lenguajes de marcado para especificar las estructuras de información. Las estructuras de información definen el tipo de información (por ejemplo, nombre del suscriptor o direccionamiento), no cómo la información mira (intrépido, cursivo, y así sucesivamente). Los procesos externos pueden manipular estas estructuras de información y publicarlas en una variedad de formatos. El XML permite que usted defina su propio lenguaje de marcado personalizado.