CONF.NET

El Protocolo de configuración de red ( NETCONF ) es un protocolo de gestión de red desarrollado y estandarizado por el IETF . Fue desarrollado en el grupo de trabajo NETCONF ^[1] y publicado en diciembre de 2006 como RFC 4741 ^[2] y posteriormente revisado en junio de 2011 y publicado como RFC 6241. ^[3] La especificación del protocolo NETCONF es un documento de Internet Standards Track.

NETCONF proporciona mecanismos para instalar, manipular y eliminar la configuración de los dispositivos de red. Sus operaciones se realizan sobre una capa simple de llamada a procedimiento remoto (RPC). El protocolo NETCONF utiliza una codificación de datos basada en lenguaje de marcado extensible (XML) para los datos de configuración, así como para los mensajes de protocolo. Los mensajes de protocolo se intercambian sobre un protocolo de transporte seguro.

El protocolo NETCONF se puede dividir conceptualmente en cuatro capas:

1. La capa de contenido consta de datos de configuración y datos de notificación.
2. La capa de Operaciones define un conjunto de operaciones de protocolo base para recuperar y editar los datos de configuración.
3. La capa de Mensajes proporciona un mecanismo para codificar llamadas a procedimientos remotos (RPC) y notificaciones.
4. La capa de transporte seguro proporciona un transporte seguro y confiable de mensajes entre un cliente y un servidor.

Algunos de los principales proveedores de equipos han implementado el protocolo NETCONF en dispositivos de red, como enrutadores y conmutadores. Una de las ventajas de NETCONF es su compatibilidad con cambios de configuración robustos mediante transacciones que involucran a varios dispositivos.

El IETF desarrolló el Protocolo simple de administración de redes (SNMP) a finales de los años 1980 y resultó ser un protocolo de administración de redes muy popular . A principios del siglo XXI se hizo evidente que, a pesar de lo que se pretendía originalmente, SNMP no se estaba utilizando para configurar equipos de red, sino que se estaba utilizando principalmente para la monitorización de la red . En junio de 2002, el Consejo de Arquitectura de Internet y miembros clave de la comunidad de administración de redes del IETF se reunieron con los operadores de red para analizar la situación. Los resultados de esta reunión están documentados en RFC 3535. Resultó que cada operador de red estaba utilizando principalmente una interfaz de línea de comandos (CLI) propietaria diferente para configurar sus dispositivos. Esta tenía una serie de características que agradaban a los operadores, incluido el hecho de que estaba basada en texto, a diferencia del SNMP codificado con BER . Además, muchos proveedores de equipos no proporcionaban la opción de configurar completamente sus dispositivos a través de SNMP. Como a los operadores generalmente les gustaba escribir scripts para ayudar a administrar sus equipos, descubrieron que la interfaz de línea de comandos de SNMP tenía varias deficiencias. La más notable era la naturaleza impredecible de la salida. El contenido y el formato de la salida eran propensos a cambiar de maneras impredecibles.

En esa misma época, Juniper Networks había estado utilizando un enfoque de gestión de red basado en XML. Esto se llevó al IETF y se compartió con la comunidad en general. En conjunto, estos dos eventos llevaron al IETF en mayo de 2003 a la creación del grupo de trabajo NETCONF. Este grupo de trabajo fue creado para trabajar en un protocolo de configuración de red, que se alineara mejor con las necesidades de los operadores de red y los proveedores de equipos. La primera versión del protocolo NETCONF básico se publicó como RFC 4741 en diciembre de 2006. Se publicaron varias extensiones en los años posteriores (notificaciones en RFC 5277 en julio de 2008, bloqueos parciales en RFC 5717 en diciembre de 2009, con valores predeterminados en RFC 6243 en junio de 2011, notificaciones del sistema en RFC 6470 en febrero de 2012, control de acceso en RFC 6536 en marzo de 2012). Una versión revisada del protocolo base NETCONF se publicó como RFC 6241 en junio de 2011.

El contenido de las operaciones NETCONF es XML bien formado. La mayor parte del contenido está relacionado con la gestión de redes . Posteriormente, también se agregó compatibilidad con la codificación en notación de objetos JavaScript (JSON).

El grupo de trabajo NETMOD ha finalizado el trabajo de definición de un lenguaje de modelado "amigable para los humanos" para definir la semántica de los datos operativos, los datos de configuración, las notificaciones y las operaciones, denominado YANG . YANG se define en RFC 6020 (versión 1) y RFC 7950 (versión 1.1), y está acompañado por los "Tipos de datos comunes de YANG" que se encuentran en RFC 6991.

Durante el verano de 2010, el grupo de trabajo NETMOD fue reestructurado para trabajar en modelos de configuración básicos (sistema, interfaz y enrutamiento), así como para trabajar en la compatibilidad con el lenguaje de modelado SNMP .

El protocolo base define las siguientes operaciones de protocolo:

La funcionalidad básica de NETCONF se puede ampliar mediante la definición de capacidades de NETCONF. El conjunto de características de protocolo adicionales que admite una implementación se comunica entre el servidor y el cliente durante la parte de intercambio de capacidades de la configuración de la sesión. Las características de protocolo obligatorias no se incluyen en el intercambio de capacidades, ya que se presuponen. El RFC 4741 define una serie de capacidades opcionales, entre las que se incluyen :xpath y :validate. Tenga en cuenta que el RFC 6241 deja obsoleto el RFC 4741.

En el documento RFC 5277 se publica una capacidad para admitir la suscripción y recepción de notificaciones de eventos asincrónicos. Este documento define la operación <create-subscription>, que permite crear suscripciones en tiempo real y de repetición. Las notificaciones se envían de forma asincrónica mediante la construcción <notification>. También define la capacidad :interleave, que, cuando se admite con la capacidad básica :notification, facilita el procesamiento de otras operaciones NETCONF mientras la suscripción está activa.

En la RFC 5717 se define una capacidad para admitir el bloqueo parcial de la configuración en ejecución. Esto permite que varias sesiones editen subárboles que no se superponen dentro de la configuración en ejecución. Sin esta capacidad, el único bloqueo disponible es para toda la configuración.

En el documento RFC 6022 se define una capacidad para supervisar el protocolo NETCONF. Este documento contiene un modelo de datos que incluye información sobre almacenes de datos, sesiones, bloqueos y estadísticas de NETCONF que facilita la gestión de un servidor NETCONF. También define métodos para que los clientes NETCONF descubran los modelos de datos compatibles con un servidor NETCONF y define la operación <get-schema> para recuperarlos.

La capa de mensajes NETCONF proporciona un mecanismo de tramado simple e independiente del transporte para codificar

• Invocaciones RPC (mensajes <rpc>),
• Resultados de RPC (mensajes <rpc-reply>) y
• notificaciones de eventos (mensajes <notification>).

Cada mensaje NETCONF es un documento XML bien formado. Un resultado de RPC está vinculado a una invocación de RPC mediante un atributo message-id. Los mensajes NETCONF se pueden canalizar, es decir, un cliente puede invocar múltiples RPC sin tener que esperar primero los mensajes de resultado de RPC. Los mensajes de RPC se definen en RFC 6241 y los mensajes de notificación se definen en RFC 5277.

• Protocolo NETCONF sobre Secure Shell (SSH): rfc:6242
• Protocolo NETCONF sobre seguridad de la capa de transporte (TLS) con autenticación mutua X.509: rfc:7589

• YANG
• CONFIGURACIÓN DE RESTO
• Stefan Wallin (18 de octubre de 2014). Tutorial de NETCONF (YouTube). Estocolmo: tail-f. Archivado desde el original el 21 de diciembre de 2021.
• Gestión de red
• Gestión de configuración
• Monitoreo de red
• Esquema XML