27 de agosto de 2020

Redes definidas por software (2)

Contenido incluido
en el temario de
CCNA 200-301

Capas SDN

  • La capa de aplicación.
    Estrato que contiene las aplicaciones que permiten comunicar los objetivos y requerimientos del negocio al controlador de la red.

  • La capa de control.
    Es el corazón de la arquitectura SDN.
    En ella se alojan los controladores SDN que permiten desarrollar un control centralizado de los dispositivos de la capa de infraestructura.

  • La capa de infraestructura.
    Contiene los dispositivos físicos o virtuales que se ocupan del reenvío de tráfico entre origen y destino.

El controlador utiliza interfaces API para controlar los dispositivos alojados en la capa de infraestructura (APIs Southbound), y brinda una visión abstracta de la red hacia la capa de aplicaciones a través de APIs Northbound.

Interfaces de progrmación de aplicaciones (API)
En las redes tradicionales las únicas opciones para interactuar con un dispositivo de red es la utilización de protocolos como SNMP, Telnet y SSH.
En los dispositivos actuales los fabricantes han implementado interfaces API para facilitar la operación de los administradores y lograr mayor flexibilidad en la operación.
Estas interfaces permiten a un usuario final ejecutar solicitudes específicas a los dispositivos de red logrando mayor funcionalidad y escalabilidad que cuando se apela a los métodos tradicionales. Las APIs requieren de un protocolo de transporte como SSH, HTTPS u otros más innovadores.
La red SDN proporciona un mecanismo centralizado de control alojado en el controlador sobre el cual se implementan APIs para comunicarse con las capas de infraestructura y de aplicación.
Una API es un conjunto de funciones y procedimientos que permiten la comunicación con un servicio. 
El uso de APIs en aplicaciones empresariales permite indicarle al controlador SDN lo qué se requiere de la red. A continuación, el controlador usa APIs para enviar instrucciones a los dispositivos de la infraestructura de la red. Estas APIs son muy diferentes.
  • Los servicios se ofrecen a la capa de aplicación a través de interfaces API Northbound.
    Son las interfaces que permiten que las aplicaciones administren y/o controlen la red.
    Estas aplicaciones van, por ejemplo, desde la virtualización de redes y el aprovisionamiento dinámico de redes virtuales hasta un monitoreo más granular de un firewall, la administración de identidades de usuarios y el control de políticas de acceso.
    Actualmente, se suelen utilizar API REST para la comunicación entre el controlador y las aplicaciones.
  • La comunicación del controlador con la capa de infraestructura se define con las APIs Southbound.
    En estas interfaces se puede utilizar cualquier protocolo que sea compatible entre el controlador y los dispositivos de infraestructura.
Entre los protocolos utilizados en interfaces southbound se incluyen:

  • OpenFlow:
    API estándar de la industria, definida por la ONF.
    Permite el acceso directo y la manipulación del plano de reenvío de tráfico de los dispositivos de red tanto físicos como virtuales.
    La configuración real de los dispositivos se realiza mediante el uso del Protocolo NETCONF.
  • NETCONF:
    Protocolo de gestión de red estandarizado por la IETF.
    Proporciona mecanismos para instalar, manipular y eliminar la configuración de dispositivos de red mediante mecanismos RPC.
    Los mensajes se codifican mediante XML. 
  • No todos los dispositivos son compatibles con NETCONF.
  • RESTCONF:
    Mecanismo que agrega una API REST a NETCONF.
  • OpFlex:
    Protocolo abierto que proporciona un sistema de control distribuido que se basa en un modelo de información de política declarativa.
    La gran diferencia entre con OpenFlow radica en sus respectivos modelos SDN.
    OpenFlow utiliza un modelo SDN imperativo, donde un controlador centralizado envía instrucciones detalladas y complejas al plano de control de los elementos de la red para implementar una nueva política.
    OpFlex utiliza un modelo SDN declarativo. El controlador envía una política más abstracta a los elementos de red y confía en los dispositivos de la red para implementar los cambios requeridos utilizando sus propios planos de control.
  • REST:
    Las API REST permiten a los controladores monitorear y administrar la infraestructura a través de los HTTP / HTTPS, utilizando las acciones HTTP (GET, POST, PUT, DELETE, etc.) que utilizan los navegadores web para recuperar páginas web.
  • SNMP:
    Se utiliza para comunicar información de gestión entre las estaciones de gestión de la red y los agentes en los dispositivos de la red.
  • Otros protocolos específicos del fabricante:
    Muchos fabricantes utilizan sus propias soluciones patentadas que proporcionan API REST a sus dispositivos, por ejemplo, Cisco utiliza NX-API para la familia de switches de data center Cisco Nexus.



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.:

25 de agosto de 2020

Redes definidas por software

Contenido incluido
en el temario de
CCNA 200-301

SDN – Software Defined Networking

Se trata de una propuesta de arquitectura que busca simplificar la forma en que se implementan y gestionan las nuevas redes inteligentes, y cuyo elemento central es el controlador SDN. Este controlador centraliza la operación y administración de los dispositivos de la infraestructura en un único punto; esto reduce la complejidad, la posibilidad de errores del operador y mejora notablemente los tiempos de despliegue de nuevos servicios.

De esta forma:

  • Se reduce la necesidad de acceso individualmente a la CLI y la GUI de dispositivos, lo cual minimiza los puntos de interacción con la red.

  • Se abandona el concepto de implementación de dispositivos independientes entre sí para operarlos en un conjunto único.

  • Se privilegia el acceso a información procesada, útil para el diagnóstico y la gestión, por encima del simple acceso a datos “crudos” generados por comando de monitoreo.

  • Se introduce el uso de interfaces programables con las que se puede interactuar con XML y JSON para automatizar procesos.

¿Qué son, entonces, las redes definidas por software?

  • No se trata de una nueva tecnología sino de un enfoque y propuesta de arquitectura de la red diferentes.
  • En este enfoque y arquitectura los planos de control y de datos están desacoplados entre sí de manera tal que los planos de gestión y control, y la “inteligencia”, están lógicamente centralizados.
  • Es una implementación en la que la infraestructura de red subyacente está abstraída de las aplicaciones (mediante la implementación de virtualización de la red).
  • Es un concepto que aprovecha las interfaces programables (APIs) disponibles para permitir que sistemas externos, basados en aplicaciones, influyan en el aprovisionamiento, el control y la operación de la red.
  • Permite controlar, gestionar y modificar la operación de la red de manera dinámica a través de interfaces abiertas.
  • En este modelo la red se administra como un todo o unidad lo que permite un resultado más predecible respecto del comportamiento de la red hacia las aplicaciones.
En esta propuesta subyace una topología estándar de red sobre la cual se superpone una capa de abstracción basada en virtualización. De esta manera se pasa de un análisis basado en cajas o dispositivos a un análisis de alto nivel orientado a la red en sí misma como unidad integradora. La definición de una capa de abstracción simplifica todas las tareas de provisionamiento de servicios.

Estas redes responden a algunas necesidades:
  • Configuración, administración, control y monitoreo centralizados de todos los dispositivos físicos o virtuales de la red.
  • Posibilidad de superar la operación de los algoritmos de reenvío de tráfico tradicionales para responder a necesidades comerciales o técnicas específicas.
  • Permiten que aplicaciones u otros sistemas externos impacten en las tareas de aprovisionamiento de recursos y el funcionamiento de la red.
  • Permiten una implementación rápida y escalable de los servicios de red con gestión del ciclo de vida de los mismos.
  • Proporcionan un punto único para la gestión y programabilidad de toda la infraestructura.
En esta arquitectura la política de toda la red se puede definir de modo simple y centralizado para luego aplicar esa política de modo coherente a toda la red a partir del controlador. Por ejemplo, en lugar de configurar listas de acceso en cada dispositivo para controlar el flujo de tráfico dentro de la red se definen las políticas de tráfico en el controlador, con una visión unificada, y el mismo controlador se ocupa de la implementación específica necesaria en cada dispositivo, de modo dinámico.
En estas redes hay un controlador que proporciona una visión unificada y holística de toda la red. El controlador permite también abordar desde otra perspectiva la escalabilidad de la red facilitando la incorporación de nuevos dispositivos.

Uno de los aspectos que se mejoran a partir de la automatización y la implementación de controladores, es la gestión del ciclo de vida:
  • Día 0
    Diseño e instalación de los componentes de la infraestructura.
  • Día 1
    Habilitación de los servicios.
  • Día 2
    Gestión y operación de los servicios.
Finalmente, cuando el cliente o usuario ya no requiera del servicio se deben liberar los recursos y limpiar la configuración de los dispositivos involucrados en el servicio.

La red tradicional vs. SDN
La red tradicional está compuesta por múltiples dispositivos diferentes, equipados cada uno con software propio y funcionalidades de red. 
En estas redes el plano de control y el plano de datos residen en cada dispositivo individual.


Esto significa que en la red tradicional cada dispositivo es igualmente “inteligente” y elabora las decisiones de reenvío de tráfico y servicios independientemente.

En una red SDN:
  • Los planos de control y gestión se encuentran centralizados en un controlador.
  • Cada dispositivo de la infraestructura solamente opera el plano de datos.
Este es el esquema de una arquitectura SDN pura. 
Sin embargo, esta arquitectura ha debido afrontar en los inicios algunos problemas de escalabilidad por la excesiva centralización del plano de control en un único punto. Esto ha dado lugar a una propuesta “SDN híbrida”.

En el modelo híbrido hay igualmente un controlador centralizado pero sin excluir la presencia de un plano de control distribuido en cada dispositivo de la infraestructura. En este modelo el controlador permite una visión centralizada y se comporta como base para la toma de decisiones de la red, lo que proporciona un panel de control y administración únicos para la red como unidad, al mismo tiempo que proporcionan una interfaz API para poder interactuar en lugar de requerir múltiples conexiones a cada dispositivo individualmente.



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.

5 comentarios:

8 de agosto de 2020

Diseño de redes corporativas

Contenido incluido
en el temario de
CCNA 200-301


El temario del nuevo examen de certificación CCNA 200-301 incorpora algunos conceptos básicos de diseño de redes que se agregan a los que ya estaban presentes en las certificaciones precedentes.
Es por esto que me parece oportuno realizar una revisión de los principales conceptos de diseño incluidos en el temario actual:

Diseño jerárquico de tres capas
El principio clave de un diseño jerárquico de la red es que cada elemento de la jerarquía tiene un conjunto específico de funciones y servicios que ofrecer, y tiene un papel específico que desempeñar en el diseño lo que permite elegir los dispositivos, sistemas y características más adecuados para cada capa.
Entre los principales beneficios del diseño jerárquico se pueden mencionar:
  • Un diseño jerárquico permite comprender mejor las características que se requieren, dónde son necesarias y qué dispositivos deben incluirlas como parte de la solución.
    Saber qué función se ejecuta en cada lugar ayuda a elegir mejor los dispositivos adecuados.
  • Un diseño jerárquico resiste la prueba del tiempo porque puede actualizarse a medida que la tecnología cambia y evoluciona, y según crecen las necesidades. 
    Esta adaptabilidad permite a una organización mantener una filosofía de diseño y reutilizar los dispositivos tal vez en un lugar diferente.
  • Un diseño jerárquico facilita la discusión técnica, la elaboración y aprendizaje sobre una parte específica de la solución.
  • La modularidad de los modelos jerárquicos se basa en el diseño en capas, cada una con sus propias funcionalidades y dispositivos.
    La red puede expandirse agregando dispositivos adicionales en diferentes capas e interconectándolos.
El modelo jerárquico de tres capas incluye:
  • La capa de acceso 
    Proporciona conexión física para que los dispositivos terminales accedan a la red. 
  • La capa de distribución
    También llamada capa de agregación.
    Es un lugar de tránsito de tráfico apropiado para aplicar políticas, como QoS, enrutamiento o seguridad.
  • La capa núcleo
    Proporciona un transporte rápido entre los dispositivos de la capa de distribución y es un punto de consolidación para el resto de la red.
    Asegura el reenvío de paquetes a alta velocidad y con redundancia.
El número de niveles que se implementan en una red jerárquica depende de las características de la implementación y la extensión de la red. En redes más pequeñas las capas núcleo y distribución se suelen combinar en una misma capa y como resultado la arquitectura obtenida recibe la denominación de Arquitectura de Core Colapsado.
Los dispositivos terminales en la LAN se comunican con los terminales en el mismo segmento de red o en segmentos separados. Si el terminal de destino está en el mismo segmento de red, el paquete se enviará directamente al host conectado. Si el terminal de destino se encuentra en otro segmento de red la solicitud debe a travesar uno o más saltos a través de la capa de distribución hasta el núcleo, lo que introduce latencia. Se dice que la comunicación de dispositivos terminales que fluye a través de otros niveles realiza un desplazamiento "Norte-Sur".
Por lo general, los dispositivos utilizados en capas de distribución y núcleo son más resistentes, tienen mejores características de rendimiento y / o admiten más prestaciones.

Diseño spine and leaf
Se trata de un nuevo enfoque de arquitectura de 2 niveles que se asemeja al diseño de núcleo colapsado tradicional. Es utilizado en el caso de implementaciones en las que hay mucho tráfico horizontal, “este – oeste”, como suele ocurrir en los Data Centers con alto nivel de virtualización de servidores e implementación de aplicaciones distribuidas. En estos entornos hay un alto volumen de tráfico que requiere ser manipulado de modo previsible y con baja latencia.
En esta arquitectura de dos niveles cada switch de nivel inferior (leaf) está conectado a cada uno de los switches de nivel superior (spine) generando una topología de malla completa. 
  • La capa leaf consta de switches de acceso que se conectan a dispositivos como servidores o terminales. 
  • La capa spine es la columna vertebral de la red y es la responsable de interconectar todos los switches inferiores. 
  • Cada switch leaf se conecta a cada switch spine. Por lo general, estas conexiones son de capa 3, por lo que todos los enlaces se pueden usar simultáneamente.
La ruta entre los switches leaf y spine se elige aleatoriamente para que la carga de tráfico se distribuya uniformemente entre los swtiches de nivel superior. Así, si uno de los switches de nivel superior fallara, solo degradaría ligeramente el rendimiento en toda la red. Si se produce una carga excesiva de un enlace, el proceso para expandir la red es sencillo. Se puede agregar un switch spine adicional, y los enlaces ascendentes se pueden extender a cada switch leaf, lo que resulta en la adición de ancho de banda entre capas y la reducción de la carga de cada enlace.
El modelo spine and leaf tiene estos beneficios para un centro de datos moderno:
  • Mayor escalabilidad dentro de la capa spine para crear múltiples rutas de igual costo desde la capa leaf hasta la capa spine.
  • Compatibilidad con switches de alto rendimiento y enlaces de alta velocidad (10 Gbps, 25 Gbps, 40 Gbps y 100 Gbps).
  • Reducción de la congestión de la red al aislar el tráfico y las VLANs en leaf por leaf.
  • Optimización y control de flujos de tráfico este-oeste.



 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.:

1 de agosto de 2020

Fundamentos de virtualización: el hypervisor

Contenido incluido
en el temario de 
CCNA 200-301

Continuando con esta introducción a los conceptos de virtualización que nos propone el temario del examen de certificación CCNA 200-301 debemos ahora introducir el concepto de hipervisor.

Un hipervisor debe cubrir algunas tareas esenciales en la implementación de sistemas virtualizados:
  • Proporcionar una plataforma operativa para máquinas virtuales.
    Debe asegurar un acceso unificado y consistente a los recursos de CPU, memoria, red y unidades de entrada y salida de la máquina host.
  • Gestionar la ejecución de él o los sistemas operativos guest.
  • Proporcionar conectividad entre las VMs alojadas en el servidor y entre esas mismas VMs y los recursos de red externos.
Actualmente podemos encontrar diferentes implementaciones de virtualización que difieren principalmente en el modo en que se comunican el sistema operativo invitado, el hipervisor y el hardware. 
La implementación más común es la virtualización completa.
La virtualización completa proporciona una emulación integral del entorno de hardware. De esta manera los sistemas operativos guest o invitados no detectan que de hecho se están ejecutando en un entorno virtual. 

Hay dos tipos de virtualización completa:
  • Tipo 1
    El hipervisor se ejecuta directamente en el hardware del servidor físico.
    Este tipo de implementación se llama también hipervisor nativo o bare-metal (de metal desnudo).
  • Tipo 2
    El hipervisor se ejecuta sobre un sistema operativo host.
    Estas implementaciones se llaman también de hipervisor alojado (hosted). 

Otro tipo de virtualización posible es la virtualización parcial.
En este caso el sistema operativo invitado accede al hardware físico (no hay una capa de hardware virtual) en el que se ejecuta el hipervisor y se ajusta para que la comunicación sea más fácil de traducir para el hipervisor. De esta manera se reducen los gastos generales y la paravirtualización, en la que el sistema operativo invitado conoce los requisitos de comunicación del hipervisor y traduce las llamadas complejas que son las que causan la mayor parte de la sobrecarga en llamadas optimizadas para el hipervisor o inician funciones especiales del hipervisor.

Ejemplos de software de hipervisor son: 
VMware ESXi y VMware Server, Microsoft Hyper-V y Microsoft Virtual PC, Citrix XenServer, Oracle VM y Oracle VM Virtual Box, Red Hat Enterprise Virtualization, etc.



 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.: