SDN – Introducción a redes basadas en software parte 1 SDN – Introducción a redes basadas en software parte 1
En una topologia típica de red tenemos dispositivos en diferentes etapas durante el transito de un paquete entre dos máquinas que quieren comunicarse entre... SDN – Introducción a redes basadas en software parte 1

En una topologia típica de red tenemos dispositivos en diferentes etapas durante el transito de un paquete entre dos máquinas que quieren comunicarse entre sí. Tenemos switches de capa 2, switches de capa 3 y routers que mediante sus tablas de rutas dirigen los paquetes entre unos destinos y otros.

En la arquitectura de red tradicional existen tres planos (Data Plane):

  1. Data Plane: es el que se encarga del transporte de los paquetes desde el origen al destino.
  2. Contol Plane: se encarga de la configuración de los equipos y de las gestión de los mismo, en este plano entra en juego los protocolos de enrutamiento o el temido SPT (spanning tree).
  3. Management Plane: el acceso a la gestión de los equipos mediante conexiones SSH, http, API, es la forma de configurar el plano de control para dar lógica al flujo de información.

En las redes actuales todos los dispositivos tienen (salvo excepciones) todos los planos, un switch se gestiona por una ip de management y se configura uno por uno para que aplique una lógica determina, por ejemplo, en las decisiones del protocolo SPT. Lo mismo ocurre con un router, hay que configurar uno a uno los dispositivos para aplicar protocolos de enrutamiento y definir muy bien las configuraciones para que todo funcione como debe.

En las redes definidas por software todo este paradigma cambia. La filosofia de SDN es separar estos planos de datos y control para que funcionen de manera separada e independiente. El control de la red pasa a ser un dispositivo (SDN Controller) dejando solamente los dispositivos como los conocemos ahora para el plano de datos, el envio de informacion.

Separar el Control Plane del Data Plane:

 

Para hacernos una idea aproximada de todo esto, y para los que conozcan el mundo Cisco (u otros similares), podemos poner un ejemplo que se usa hoy en día que se asemeja muy mucho a lo que es SDN a nivel LAN, un controlador wifi.

Cisco WLC o Wireless LAN Controler usa la misma filosofía pero llevada al ecosistema wireless. Tenemos un cerebro o «Controller» (WLC) donde se realiza toda la lógica de configuración y unos dispositivos (AP) los cuales se encargan de gestionar el tráfico de los clientes comandados por el controlador.

  • Control Plane se encarga de la lógica de funcionamiento:
    • Tablas de rutas
    • Estado de puertos SPT
    • Tablas de MAC
    • Protocolos de Redundancia
    • Protocolos de tunelizado.
  • Data Plane se encarga de aplicar esa lógica para enviar los paquetes:
    • Lee las MAC
    • Lee las tablas de rutas
    • Lee las tablas ARP
    • Lee las configuraciones
    • Reenvía tramas.

El switch como lo hemos conocido siempre ya no es un dispositivo con inteligencia, simplemente es orquestado por un controlador.

Aquí podemos añadir otro plano, el plano de gestión (Management Plane) que es el utilizado para realizar la configuración de los equipos (SSH, SNMP, Telnet aunque no deberias utilizarlo)

En una red tradicional, cada dispositivo tiene plano de datos y plano de control y hay que configurar el plano de control de manera individual en cada uno de los equipos:

En cambio en una red definida por software (SDN) solo hay un equipo que tiene el control (varios por redundancia pero que lo hacen como uno solo) y el resto solo aplican la lógica

en función de lo que el controlador decida en base a la configuración establecida.

Para esta configuración es donde aparecen las API (Application Programming Interface) es la forma en la que el controller es capaz de decirle a los dispositivos que tienen que hacer.

Según la dirección en la que se produzca esta comunicación tenemos:

  • Southbound API -> Enviar desde el controller hacia los dispositivos para instar al dispositivo a comportarse de una manera determinada. Para ello usamos dos protocolos Netconf o Openflow.
  • Northbound API -> Enviar información desde el dispositivo al controller para que este pueda tomar nuevas decisiones.

Actualmente existen muchas soluciones de SDN aplicadas a diferentes campos, SDA, SDWAN, Data Center como VMWare NSX o Cisco ACI. Aquí lo aplicaremos siempre al mundo Cisco aunque también existen alternativas de código libre. Por ejemplo si buscamos código abierto, no podemos perdernos soluciones las siguientes:

Si pasamos a soluciones comerciales:

  • Soluciones de Cisco
    • Cisco ACI (APIC): Application Centric Infraestructure
    • Cisco DNA Center

Una vez nos hemos introducido en el mundo de las redes definidas por software, veamos más en profundidad como podemos hacer funcionar todo esto y como se adapta una red convencional a una red SDN. En este aspecto es fundamental conocer el concepto de Overlay vs Underlay

  • Underlay, hace referencia a la capa de red tradicional, sobre la que va a funcionar la capa software a través de la cual va a funcionar nuestro ecosistema SDN.
  • Overlay es la capa que se construye, nuestro controlador SND construye, sobre esta capa de red tradicional y la que permite conexión L3 punto a punto entre dispositivos. Para conseguirlo, se utilizan tuneles VxLAN y lo que se llama LISP que veremos más adelante.

 

         

 

Para seguir avanzando tenemos también que conocer lo que es el Fabric. Al Fabric se llama al conjunto del SDN Controller y la capa L3 de red. Es un concepto que viene a englobar lo necesario para enviar tráfico desde un dispositivo a otro. De una más concisa el Fabric es el conjunto del underlay (red de nivel 3 en el modo tradicional) sobre la que el controller SDN contruye la capa overlay utilizando tuneles para enviar el tráfico

VXLAN (Virtual Extensible LAN)

Para entenderlo de una manera sencilla, imaginemos que tenemos dos localizaciones distintas en las que queremos tener el mismo direccionamiento, una misma VLAN en dos puntos distintos de nuestra red.

En el modo tradicional, no es posible que un paquete llegue a la red con destino 10.0.0.2 y vaya siempre hacia una sede A u otra sede B, a no ser que se haga un balanceo de carga en cuyo caso solo estaremos obteniendo la mitad del tráfico. Para poder hacer esto, el orquestador, en el ecosistema Cisco un DNA Center lo que hace es construir un tunel VXLAN entre los dispositivos de red y permitir que esta VLAN sea la misma en ambas sedes.

Esto le brinda un nueva funcionalidad a las redes y una versatilidad tremenda, sobre todo en lo que respecta a temas de alta disponiblidad y reparto de carga, la cual antes no podíamos tener de una manera tan sencilla.

Para que los que no estéis acostumbrados a estas cosas, funciona de manera muy similar a una VPN pero en la encapsulación se omiten las ips origen y destino de los router en la encapsulación de los paquetes. Necesitamos mantener nuestras direcciones MAC origen y destino (A y B) en su envio hacia el host 10.0.0.3

Una vez construido el paquete VXLAN se envia utilizando el tunel de la red overlay:

Llegados a este punto puede que te preguntes: ¿Cómo llega a su destino si está en otro punto de la red?

En las redes tradicionales como las conocemos actualmente, el switch utiliza la tabla MAC para hacer una busqueda y determina porque puerto enviar el paquete en función del destino. En este caso esta solución no es viable: Si es cierto que tenemos mac origen y destino en el paquete VXLAN pero recordemos que el destino no está en el mismo equipo que el origen.

Esto será en el siguiente capitulo…

Saludos.

gpinero

No hay comentarios

Se el primero en dejar un comentario.

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

CAPTCHA ImageChange Image

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies