En la entrada anterior https://www.machana.cloud/2020/11/18/software-defined-networking/, nos habíamos quedado en una situación en la que puedo utilizar dos sustratos (underlays) diferentes para establecer un patrón de conectividad, una malla, entre los nodos de la red y poder encaminar el tráfico de diferentes aplicaciones sobre uno u otro de los sustratos en función de sus requerimientos y/o coste.
¿Y cómo podemos establecer ese patrón de conectividad entre nodos sobre los dos sustratos y hacer que funcione? Bueno, la manera estándar de responder a esa pregunta es construir las mallas de conectividad lógica superpuesta a los sustratos, uno o más «overlays», utilizando esquemas de tunelado de tráfico: por ejemplo, IPSEC/GRE. Entre los nodos que se necesite se establece una malla de túneles configurados para cursar el tráfico entre ellos utilizando los sustratos de la manera adecuada, siguiendo los esquemas de conectividad necesarios para las aplicaciones utilizadas. El inconveniente de este esquema es bastante obvio para el que haya intentado hacer esto de forma manual o semi-manual utilizando configuración estática nodo a nodo: es un lío considerable, un proceso predispuesto a los errores y requiere de un equipo de trabajo especializado, para al final obtener un resultado que sigue siendo estático y difícil de mantener y operar. Si al día siguiente de tener todo funcionando un usuario requiere de una nueva aplicación, o varían sus requerimientos, toca configurar todo de nuevo, nodo a nodo y rezar porque no nos hayamos equivocado.
Pues este caso particular, que en realidad es bastante general, puede ser resuelto de una manera eficaz con una arquitectura Software Defined. Puesto que somos capaces de actuar sobre un único punto y variar de forma programática las especificaciones de la red, incluyendo los mallados de túneles overlay, así como las reglas de clasificación de tráfico y su tratamiento, podemos configurar y gestionar eficazmente la red. Además, podemos beneficiarnos fácilmente de los ahorros de costes posibles reduciendo los requisitos de conectividad cara, normalmente la parte MPLS y aprovecharnos de la conectividad sobre el sustrato Internet. Cuando existe esta capacidad, es muy tentador para el administrador de red proporcionar lo que se conoce como Direct Internet Access para aquellas aplicaciones que se suministren desde una Cloud pública, muchas en la actualidad, y para las que no se justifica acarrear tráfico sobre una infraestructura MPLS cara hasta un punto central de entrega.
Este escenario es de hecho el de más frecuente utilización de arquitecturas SDN y de hecho constituye por sí solo una arquitectura novedosa, conocida como SDWAN (Software Defined Wide Area Network)
Múltiples fabricantes y suministradores de equipamiento de red han entrado a este mercado y proporcionan soluciones de SDWAN más o menos consistentes y eficaces, con algunas diferencias de rendimiento y capacidad entre ellas, pero básicamente obedeciendo al mismo principio arquitectural. Y lo que es más novedoso, también suministradores tradicionalmente asociados a soluciones software han accedido a este mercado y proporcionan soluciones utilizando software específico sobre plataformas hardware de propósito general, utilizando algunos avances relativamente recientes en lo que se conoce como Network Function Virtualization, o Virtualización de Functiones de Red, de lo que hablaremos en una próxima entrada.