24 de octubre de 2020

Modelos de datos


Contenido incluido
en el temario de
CCNA 200-301

Los modelos de datos describen un conjunto limitado de datos en forma de un esquema de lenguaje.
  • Utilizan parámetros bien definidos para estandarizar la representación de datos de un dispositivo de red de modo tal que la salida de plataformas diferentes sea la misma.
  • No se utiliza para enviar información a los dispositivos y depende de protocolos como NETCONF y RESTCONF para enviar documentos codificados en JSON y XML que simplemente adhieren a un modelo determinado.
  • La configuración de los dispositivos se puede validar contra un modelo de datos para verificar si los cambios son válidos para el dispositivo antes de confirmar los cambios.
Los modelos de datos se utilizan para describir la sintaxis y la semántica utilizadas para trabajar con objetos de datos específicos. Pueden definir atributos y respuestas.
El modelo de gestión basado en CLI tradicional no tiene un marco de referencia o modelo; la gestión basada en programabilidad, en cambio, genera información modelizada. Un dispositivo que tiene una representación JSON o XML de su configuración completa puede gestionarse completamente desde un modelo de datos como YANG.
Los modelos de datos proporcionan una jerarquía bien definida de los datos operativos y de configuración de un dispositivo y las acciones que se pueden realizar mediante un protocolo como NETCONF.
Consideran diferentes categorías de datos:
  • Datos de configuración: 
    Conjunto de datos que pueden guardarse y que se requieren para transformar un sistema en su estado inicial (predeterminado) a su estado actual.
    Por ejemplo, configurar las entradas de las tablas de enrutamiento IP, configurar la MTU de una interfaz, configurar una velocidad determinada en una interfaz Ethernet, etc.
  • Datos de estado operativo: 
    Conjunto de datos que obtiene el sistema en ejecución y que influyen en el comportamiento del sistema de forma similar a los datos de configuración.
    A diferencia de los datos de configuración, los datos del estado operativo son transitorios, responden a un momento específico.
    Los datos se modifican a partir de interacciones con componentes internos o con otros sistemas que utilizan protocolos especializados.
    Por ejemplo, las entradas obtenidas por protocolos de enrutamiento como, atributos de las interfaces de red, etc.
  • Acciones: 
    Conjunto de acciones que admiten transacciones de configuración robustas en la red.
    Cuando se intenta un cambio que afecta a varios dispositivos las acciones simplifican la administración de escenarios de diagnóstico de fallos, lo que resulta en la capacidad de tener transacciones sobre un grupo de dispositivos de manera confiable.

Modelo YANG
YANG se ha convertido en un lenguaje de modelado de datos de hecho. Es un lenguaje basado en estándares que se utiliza para crear solicitudes de configuración de dispositivos o solicitudes de datos operativos (como pueden ser los comandos show). Tiene un formato estructurado similar a un programa de computadora que es legible por humanos. Hay varias aplicaciones disponibles que se pueden ejecutar en una plataforma de administración centralizada para crear estas solicitudes de configuración y datos operativos.
  • Lenguaje de modelado definido en el RFC 6020.
  • Desarrollado en 2010 inicialmente para NETCONF, ahora también se lo utiliza con RESTCONF y gRPC
  • Configuración de modelos y datos de estado operativo
  • Proporciona sintaxis y semántica.
    Proporciona una sintaxis y semántica rica que ofrece restricciones y estructuras reutilizables que pueden ser aplicadas dentro y entre modelos YANG.
  • Utiliza estructuras de datos reutilizables.
  • Existen modelos de datos YANG estándar que se aplican a todos los proveedores y otros que están asociados con las características propietarias de un fabricante específico.
NOTA.
YANG es la forma dominante de modelar la configuración y la información de estado de los dispositivos de la red pero, no es el único método. 
Algunas plataformas de Cisco (por ejemplo, la familia Nexus 9000, Cisco Unified Computing System) no utilizan YANG sino que están totalmente controladas por un modelo propietario



Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

 o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking
Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.
No hay comentarios.:

18 de octubre de 2020

Modelo para programabilidad de la red

Contenido incluido
en el temario de
CCNA 200-301

Inicialmente la implementación y gestión de las redes de datos se realizó de modo completamente manual y principalmente utilizando la interfaz de línea de comandos (CLI). Se trataba de una red con una cantidad y variedad de dispositivos mucho menor y con servicios de mucho menos complejidad que las redes que operamos en la actualidad.

En la medida en que evolucionaban estas redes tanto la operación utilizando CLI como la apelación a SNMP fueron adecuadas y suficientes para los requerimientos de la gestión. De hecho, estos mecanismos siguen siendo al día de hoy en muchos casos los principales recursos.
Sin embargo, la sintaxis de la CLI y las opciones configurables de los diferentes protocolos que están asociadas a este mecanismo de gestión varían ampliamente entre diferentes fabricantes, plataformas e incluso versiones de un mismo software. Esta situación, combinada con las restricciones propias de la CLI se ha constituido en una limitación para el uso de la CLI en la gestión de redes a escala; la sola configuración y operación de una función o protocolo específicos puede requerir de muchas variantes de la CLI haciendo su uso complejo y pasible de errores. En estos casos la automatización con scripts es una opción, pero se torna cada vez más compleja.
Por su parte, SNMP ha sido desde hace tiempo la forma más utilizada para el monitoreo de las redes. Es una muy buena opción cuando las redes son medianas o pequeñas y el sondeo de cada dispositivo se realiza por intervalos de 15 a 30 minutos. Sin embargo, SNMP a menudo genera complicaciones operativas al sondear dispositivos con demasiada frecuencia debido al incremento en el uso de la capacidad de transporte de la red. Si bien SNMP ha servido a la industria razonablemente bien; desde la perspectiva de la capacidad de programación de la red SNMP carece de bibliotecas para varios lenguajes de programación.
Una de las limitaciones que presenta el modelo tradicional de gestión es la carencia de una forma adecuada de comunicación máquina a máquina con la red que permita la interacción de los dispositivos terminales con la configuración de la infraestructura de la red de modo automático. 

Este es el lugar para las redes programables. Redes en la que la automatización es posible a partir de la implementación de un conjunto de herramientas de programación adecuadas para gestionar la configuración y la operación de la red.
La programabilidad de las redes ha introducido una serie de protocolos y herramientas cuyo nombre es cada vez más familiar: NETCONF, YANG, XML, etc.
Pero, ¿cuál es el lugar o la función que cumple cada uno de estos elementos nuevos?
Para comprender mejor la operación y flexibilizar su implementación y desarrollo es necesario contar con un modelo teórico que nos permite poner cada uno de estos elementos en un lugar específico. Este es el modelo de redes programables.

Este modelo de programabilidad puede representarse así:
  • Aplicación cliente
    Gestiona las configuraciones y monitorea los dispositivos de la infraestructura.
    La aplicación cliente se puede escribir en diferentes lenguajes de programación (p.e. Python) y los SDK se utilizan a menudo para simplificar la implementación de aplicaciones para la automatización de redes
  • SDK
    Conjunto de herramientas y bibliotecas de software que permiten al usuario final crear sus propias aplicaciones personalizadas para diversos fines incluida la gestión de plataformas de hardware.
  • Protocolo
    Las APIS basadas en modelos admiten múltiples protocolos. Los más utilizados en este momento son NETCONF, RESTCONF y gPRC.
    Los modelos de datos utilizados se basan en estos protocolos.
    La elección del protocolo depende de las herramientas disponibles, la experiencia en redes, programación y automatización.
  • Codificación
    Los datos pueden ser codificados en formatos como JSON, XML o GPB.
    En algunos casos el protocolo está vinculado a codificaciones específicas (como es NETCONF con XML). Esto está relacionado con el protocolo que puede o no admitir diferentes formatos de codificación.
  • Transporte
    Cada API soporta uno o más protocolos de transporte para establecer la comunicación con el dispositivo de red.
  • Modelo de datos
    Es la base de la API.
    Definen la sintaxis y la semántica de los datos, incluidas las limitaciones de esa API.
    Se utilizan parámetros bien definidos para estandarizar la representación de los datos de modo que la salida de diferentes plataformas sea la misma.

Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

 O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

 o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking
Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

 

 

2 comentarios:

3 de octubre de 2020

Los estratos en NTP

Network Time Protocol es un protocolo creado para sincronizar el reloj de los diferentes sistemas que se integran en una redes de datos de latencia variable. Desarrollado inicialmente antes de 1985 es uno de los protocolos de Internet más antiguos que se utilizan actualmente. Fue diseñado por David L. Mills de la Universidad de Delaware .

Está diseñado para sincronizar todos los sistemas dentro de unos pocos milisegundos con la hora universal coordinada (UTC -  Coordinated Universal Time). 

Utiliza una versión modificada del algoritmo de Marzullo  para seleccionar servidores de tiempo precisos y está diseñado para mitigar los efectos de la latencia de red variable . Generalmente puede mantener el tiempo dentro de decenas de milisegundos en Internet y puede lograr una precisión superior a un milisegundo en redes LAN en condiciones ideales. La presencia de rutas asimétricas y la posible congestión de la red pueden provocar errores del orden de los 100 ms o más.

El protocolo se describe en términos del modelo cliente-servidor pero puede usarse fácilmente implementando relaciones entre pares donde ambos miembros del par consideran al otro como una fuente de tiempo potencial. Utiliza UDP como protocolo de transporte en el puerto número 123. 

No incluye en su contenido información sobre las zonas horarias locales o el horario de verano . 

El protocolo actualmente en uso es la versión 4 (NTPv4) propuesto en el RFC  5905  y es compatible con la versión 3, especificada en el RFC 1305.

El sistema de estratos

NTP utiliza un sistema jerárquico de fuentes de tiempo semi-estratificado. Cada nivel de esta jerarquía recibe la denominación de estrato y se le asigna un identificador de nivel que utiliza el cero para identificar el reloj de referencia que da la información de hora de referencia. 

El concepto de estrato describe a cuántos saltos se encuentra un sistema de un fuente autoritativa de registro de tiempo o dispositivo de estato 0. El nivel del estrato define la distancia, en saltos, que hay entre un sistema y el reloj de referencia o estrato 0.

Un servidor sincronizado con un servidor de estrato n pertenece al estrato n + 1. Por ejemplo, un servidor sincronizado con un servidor de estrato 2 (n) pertenece al estrato 3 (n + 1).

El número representa la distancia con el reloj de referencia (estrato 0) y se utiliza para evitar dependencias cíclicas en la jerarquía. El estrato no es una indicación de calidad o confiabilidad; es común encontrar servidores del estrato 3 que son de mayor calidad que otros servidores del estrato 2.

  • Estrato 0
    Se trata de dispositivos de cronometraje de alta precisión como pueden ser relojes atómicos , clientes GPS u otros relojes de precisión y que por lo tanto se asume que pueden proporcionar una hora precisa. Generan una señal de pulso muy precisa por segundo que activa una interrupción y marca de tiempo en una computadora conectada.
    Los dispositivos de estrato 0 también se conocen como relojes de referencia. Un dispositivo de estrato 0 no puede ser utilizado directamente en la red sino que debe conectarse directamente a un dispositivo que se asume como un servidor de estrato 1.
    Los servidores NTP no pueden anunciarse a sí mismos como estrato 0.
    Un campo de estrato establecido en 0 en el paquete NTP indica un estrato no especificado.

  • Estrato 1
    Sistemas cuyo reloj se encuentra sincronizado a unos pocos microsegundos de un dispositivo de estrato 0 al que se encuentra directamente conectado.
    Los servidores de un estrato puede también intercambiar información NTP con otros servidores del mismo estrato o nivel que reciben entonces la denominación de “peer”. Esto permite lograr una referencia de tiempo más estable y robusta para los sistemas de ese mismo nivel.
    Los servidores de estrato 1 pueden emparejarse con otros servidores de estrato 1 (peers) para comprobar el estado.
    También se les conoce como servidores de tiempo primarios.

  • Estrato 2
     sincronizados a través de una red de datos con servidores de estrato 1 utilizando paquetes NTP.
    A menudo, un sistema de estrato 2 consulta varios servidores del estrato 1. Los sistemas de estrato 2 también pueden emparejarse con otros sistemas del mismo estrato 2 (peers) para proporcionar un tiempo más estable y robusto para todo el sistema.

  • Estrato 3
    Son sistemas que están sincronizados con servidores de estrato 2. Emplean los mismos algoritmos para el emparejamiento y el muestreo de datos que los sistemas de estrato 2 y pueden actuar ellos mismos como servidores para los sistemas de estrato 4, y así sucesivamente.

El protocolo prevé un límite de 15 estratos; el estrato 16 se utiliza para indicar que un dispositivo no está sincronizado.



Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

 O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

 o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking
Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.

 

No hay comentarios.: