Iniciar una sesión de NETCONF

El servidor NETCONF y la aplicación cliente comienzan emitiendo un <hello> elemento de etiqueta para especificar qué operaciones o capacidades admiten entre las definidas en la especificación NETCONF. El <hello> elemento de etiqueta encierra el <capabilities> elemento y el <session-id> elemento, que especifica el ID de proceso de UNIX (PID) del servidor NETCONF para la sesión. Dentro del <capabilities> elemento, cada uno <capability> define una función compatible.

La aplicación cliente debe emitir el <hello> elemento tag antes que cualquier otro elemento durante la sesión de NETCONF y no debe emitirlo más de una vez.

Cada capacidad definida en la especificación NETCONF se representa en un <capability> elemento mediante un nombre de recurso uniforme (URN). Las capacidades definidas por proveedores individuales se representan mediante identificadores de recursos uniformes (URI), que pueden ser URNs o URL. El protocolo de administración XML NETCONF emite un <hello> elemento similar al siguiente resultado de ejemplo (algunos <capability> elementos aparecen en varias líneas solo para legibilidad):

Las URI del <hello> elemento indican las siguientes capacidades admitidas, lo que no es una lista exhaustiva:

• urn:ietf:params:netconf:base:1.0: el servidor NETCONF admite las operaciones básicas y los elementos definidos en la especificación base NETCONF.

• urn:ietf:params:netconf:capability:candidate:1.0: el servidor NETCONF admite operaciones en una configuración candidata.

• urn:ietf:params:netconf:capability:confirmed-commit:1.0: el servidor NETCONF admite operaciones de confirmación confirmadas. Para obtener más información, consulte Confirmar la configuración del candidato solo después de la confirmación mediante NETCONF.

• urn:ietf:params:netconf:capability:validate:1.0— El servidor NETCONF admite la operación de validación, que verifica la corrección sintáctica de una configuración sin confirmarla realmente. Para obtener más información, consulte Verificar la sintaxis de configuración del candidato mediante NETCONF.

• urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file: el servidor NETCONF acepta los datos de configuración almacenados en un archivo. Puede recuperar archivos desde su sistema de archivos local (indicado por la file opción en la URN) y desde máquinas remotas mediante el protocolo de transferencia de hipertexto (HTTP) o FTP (indicado por las http opciones y ftp en la URN). Para obtener más información, consulte Cargar y formatear datos de configuración en una sesión NETCONF.

• http://xml.juniper.net/netconf/junos/1.0: el servidor NETCONF admite las operaciones definidas en la API XML de Junos para solicitar y cambiar la información operativa (los elementos de etiqueta en la Referencia para desarrolladores operativos de la API XML de Junos). El servidor NETCONF también admite operaciones en el protocolo de administración XML de Junos para solicitar o cambiar la información de configuración.

  Las aplicaciones cliente NETCONF solo deben usar operaciones de protocolo de administración XML NETCONF nativas y extensiones compatibles disponibles en el protocolo de administración XML de Junos para funciones de configuración. La semántica de las operaciones de protocolo XML de Junos correspondientes y las operaciones de protocolo XML NETCONF no son necesariamente idénticas, por lo que el uso de operaciones de configuración del protocolo XML de Junos distintas de las extensiones admitidas documentadas puede dar lugar a resultados inesperados.

• http://xml.juniper.net/dmi/system/1.0: el servidor NETCONF admite las operaciones definidas en la especificación de interfaz de administración de dispositivos (DMI).

De forma predeterminada, el servidor NETCONF no anuncia módulos YANG compatibles en el intercambio de capacidades NETCONF. Para anunciar módulos YANG compatibles, configure una o más de las siguientes instrucciones en el [edit system services netconf hello-message yang-module-capabilities] nivel jerárquico:

• advertise-custom-yang-modules— Anuncie módulos YANG de terceros instalados en el dispositivo.
• advertise-native-yang-modules— Anuncie los módulos YANG nativos de Junos OS.
• advertise-standard-yang-modules— Anuncie módulos YANG estándar compatibles con el dispositivo, por ejemplo, los módulos OpenConfig.

Para cumplir con la especificación NETCONF, la aplicación cliente también emite un <hello> elemento para definir las capacidades que admite. No incluye el <session-id> elemento:

La sesión continúa cuando la aplicación cliente envía una solicitud al servidor NETCONF. El servidor NETCONF no emite ningún elemento después de la inicialización de la sesión, excepto en respuesta a las solicitudes de la aplicación cliente.

El intercambio de elementos de <hello> etiqueta permite que una aplicación cliente y el servidor NETCONF determinen si admiten las mismas capacidades. Además, recomendamos que la aplicación cliente determine la versión de Junos OS que se ejecuta en el servidor NETCONF. Después de emitir su <hello> etiqueta, la aplicación cliente emite el <get-software-information> elemento tag en un <rpc> elemento de etiqueta:

El servidor NETCONF devuelve el <software-information> elemento tag, que encierra los <host-name> elementos y <product-name> tag más un <package-information> elemento de etiqueta para cada módulo junos OS. El <comment> elemento tag dentro del <package-information> elemento tag especifica el número de versión de Junos OS (en el ejemplo siguiente, 8.2 para la versión 8.2 de Junos OS) y la fecha de compilación en el formato AYYYMMDD (año, mes, día: 12 de enero de 2007 en el ejemplo siguiente). Algunos elementos de etiqueta aparecen en varias líneas, solo para legibilidad:

Normalmente, la versión es la misma para todos los módulos de Junos OS que se ejecutan en el dispositivo (recomendamos esta configuración para un rendimiento de enrutamiento predecible). Por lo tanto, verificar el número de versión de un solo módulo suele ser suficiente.

La aplicación cliente es responsable de determinar cómo manejar las diferencias en la versión o las capacidades. Para un rendimiento completamente automatizado, incluya código en la aplicación cliente que determine si admite las mismas capacidades y la versión de Junos OS que el servidor NETCONF. Decida cuál de las siguientes opciones es adecuada cuando hay diferencias e implemente la respuesta correspondiente:

• Ignore las diferencias en las capacidades y la versión de Junos OS, y no altere el comportamiento de la aplicación cliente para adaptarse al servidor NETCONF. Una diferencia en las versiones de Junos OS no necesariamente hace que el servidor y el cliente sean incompatibles, por lo que esto a menudo es un enfoque válido. De manera similar, es un enfoque válido si las capacidades que la aplicación cliente no admite son operaciones que siempre inicia un cliente, como la validación de una configuración y confirmación de confirmación. En ese caso, el cliente mantiene la compatibilidad sin iniciar la operación.

• Altere el comportamiento estándar para que sea compatible con el servidor NETCONF. Si la aplicación cliente ejecuta una versión posterior de Junos OS, por ejemplo, puede elegir emitir solo los elementos de etiqueta NETCONF y Junos XML que representan las funciones de software disponibles en la versión del servidor NETCONF de Junos OS.

• Finalice la sesión NETCONF y termine la conexión. Esto es apropiado si decide que no es práctico acomodar la versión o las capacidades del servidor NETCONF. Para obtener instrucciones, consulte Finalizar una sesión NETCONF y Cerrar la conexión.