Programabilidad y automatización de la red

Capítulo 1. Tendencias de la industria de redes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¿Eres nuevo en las Redes Definidas por Software (SDN)? ¿Has estado enganchado a la moda de las SDN durante los últimos años? Sea cual sea tu caso, no te preocupes. Este libro te guiará a través de los temas fundamentales para iniciar tu viaje por la programabilidad y la automatización de la red, empezando por el auge de la SDN. Este capítulo ofrece una visión de las tendencias en la industria de las redes centradas en SDN, su relevancia y su impacto en el mundo actual de las redes. Empezaremos repasando cómo las Redes Definidas por Software se convirtieron en la corriente principal y, en última instancia, condujeron a las tendencias en torno a la programabilidad y automatización de redes.

El auge de las redes definidas por software

Si hubiera una persona a la que se pudiera atribuir todo el cambio que se está produciendo en el sector de las redes, sería Martín Casado, que actualmente es Socio General y Capitalista de Riesgo en Andreessen Horowitz. Anteriormente, Casado fue VMware Fellow, Vicepresidente Senior y Director General de la Unidad de Negocio de Redes y Seguridad de VMware. Ha tenido un profundo impacto en la industria, no sólo por sus contribuciones directas (incluidos OpenFlow y Nicira), sino por abrir los ojos a los grandes titulares de redes y mostrar que las operaciones, la agilidad y la capacidad de gestión de las redes deben cambiar. Veámoslo con un poco más de detalle.

OpenFlow

Para bien o para mal, OpenFlow fue el primer gran protocolo del movimiento de Redes Definidas por Software (SDN). OpenFlow es el protocolo en el que trabajó Martín Casado mientras se doctoraba en la Universidad de Stanford bajo la supervisión de Nick McKeown. OpenFlow no es más que un protocolo que permite desacoplar el plano de control de un dispositivo de red del plano de datos (ver Figura 1-1). En términos más sencillos, el plano de control puede considerarse como el cerebro de un dispositivo de red y el plano de datos puede considerarse como el hardware o los circuitos integrados específicos de la aplicación (ASIC) que realmente realizan el reenvío de paquetes.

Figura 1-1. Desacoplar el plano de control y el plano de datos con OpenFlow

Ejecutar OpenFlow en modo híbrido

La Figura 1-1 muestra los elementos de la red sin plano de control. Esto representa una implementación exclusiva de OpenFlow. Muchos dispositivos también admiten la ejecución de OpenFlow en modo híbrido, lo que significa que OpenFlow puede desplegarse en un puerto determinado, una red de área local virtual (VLAN) o incluso dentro de una canalización normal de reenvío de paquetes, de modo que si no hay ninguna coincidencia en la tabla OpenFlow, se utilizan las tablas de reenvío existentes (MAC, enrutamiento, etc.), lo que lo hace más análogo al enrutamiento basado en políticas (PBR).

Lo que esto significa es que OpenFlow es un protocolo de bajo nivel que se utiliza para interactuar directamente con las tablas de hardware (por ejemplo, la Base de Información de Reenvío, o FIB) que indican a un dispositivo de red cómo reenviar el tráfico (por ejemplo, "el tráfico al destino 192.168.0.100 debe salir por el puerto 48").

Nota

OpenFlow es un protocolo de bajo nivel que manipula las tablas de flujo, por lo que afecta directamente al reenvío de paquetes. OpenFlow no fue concebido para interactuar con atributos del plano de gestión como la autenticación o los parámetros SNMP.

Como las tablas que utiliza OpenFlow admiten algo más que la dirección de destino, en comparación con los protocolos de encaminamiento tradicionales, hay más granularidad (campos coincidentes en el paquete) para determinar la ruta de reenvío. Este no es muy diferente de la granularidad que ofrece el Enrutamiento Basado en Políticas. Al igual que haría OpenFlow muchos años después, PBR permite a los administradores de red reenviar el tráfico basándose en atributos "no tradicionales", como la dirección de origen de un paquete. Sin embargo, los proveedores de redes tardaron bastante tiempo en ofrecer un rendimiento equivalente para el tráfico reenviado mediante PBR, y el resultado final seguía siendo muy específico de cada proveedor. La llegada de OpenFlow significó que ahora podíamos conseguir la misma granularidad con las decisiones de reenvío de tráfico, pero de forma neutral con respecto al proveedor. Se hizo posible mejorar las capacidades de la infraestructura de red sin esperar a la siguiente versión de hardware del fabricante.

Historia de las redes programables

OpenFlow no fue el primer protocolo o tecnología que se utilizó para desacoplar las funciones de control y la inteligencia de los dispositivos de red. Hay una larga historia de tecnología e investigación anterior a OpenFlow, aunque OpenFlow es la tecnología que inició la revolución SDN. En algunas de las tecnologías anteriores a OpenFlow son Forwarding and Control Element Separation (ForCES), Active Networks, Routing Control Platform (RCP) y Path Computation Element (PCE). Para conocer más a fondo esta historia, echa un vistazo al documento "The Road to SDN: An Intellectual History of Programmable Networks" de Jen Rexford, Nick Feamster y Ellen Zegura.

¿Por qué OpenFlow?

Aunque es importante entender qué es OpenFlow, es aún más importante comprender el razonamiento que subyace al esfuerzo de investigación y desarrollo de la especificación OpenFlow original, que condujo al auge de las Redes Definidas por Software.

Martin Casado trabajó para el gobierno nacional mientras estudiaba en Stanford. Durante el tiempo que trabajó para el gobierno, surgió la necesidad de reaccionar ante ataques de seguridad a los sistemas informáticos (al fin y al cabo, se trata del gobierno de EEUU). Casado se dio cuenta rápidamente de que podía programar y manipular los ordenadores y servidores según sus necesidades. Los casos de uso reales nunca se hicieron públicos, pero fue este tipo de control sobre los puntos finales lo que hizo posible reaccionar, analizar y potencialmente reprogramar un host o grupo de hosts cuando y si era necesario.

Cuando se trataba de la red, era casi imposible hacerlo de forma limpia y programática. Al fin y al cabo, cada dispositivo de red estaba cerrado (impedía instalar software de terceros, por ejemplo) y sólo disponía de una interfaz de línea de comandos (CLI). Aunque la CLI era y sigue siendo muy conocida e incluso preferida por los administradores de red, Casado tenía claro que no ofrecía la flexibilidad necesaria para gestionar, operar y proteger realmente la red.

En realidad, la forma de gestionar las redes nunca había cambiado en más de 20 años, salvo por la adición de comandos CLI para nuevas funciones. El mayor cambio fue la migración de Telnet a SSH, que era una broma utilizada a menudo por la empresa de SDN Big Switch Networks en sus diapositivas, como puedes ver en la Figura 1-2.

Figura 1-2. ¿Qué ha cambiado? De Telnet a SSH (fuente: Big Switch Networks)

Bromas aparte, la gestión de las redes se ha quedado bastante rezagada con respecto a otras tecnologías, y esto es lo que Casado se propuso cambiar en los años siguientes. Esta falta de capacidad de gestión suele comprenderse mejor cuando se examinan otras tecnologías. Otras tecnologías casi siempre tienen formas más modernas de gestionar un gran número de dispositivos, tanto para la gestión de la configuración como para la recopilación y el análisis de datos: por ejemplo, gestores de hipervisores, controladores inalámbricos, centralitas IP, PowerShell, herramientas DevOps, y la lista puede continuar. Algunas de ellas están estrechamente acopladas por los proveedores como software comercial, pero otras están más libremente alineadas para permitir la gestión, las operaciones y la agilidad multiplataforma.

Si volvemos al escenario mientras Casado trabajaba para el gobierno, ¿era posible redirigir el tráfico en función de la aplicación? ¿Tenían los dispositivos de red una API? ¿Había un único punto de comunicación con la red? Las respuestas fueron mayoritariamente negativas en todos los casos. ¿Cómo era posible programar la red para controlar dinámicamente el reenvío de paquetes, la política y la configuración con la misma facilidad con que se escribía un programa y se ejecutaba en una máquina host final?

La especificación inicial de OpenFlow fue el resultado de que Martín Casado experimentara este tipo de problemas de primera mano. Aunque el revuelo en torno a OpenFlow se ha calmado desde que el sector está empezando a centrarse por fin más en casos de uso y soluciones que en protocolos de bajo nivel, este trabajo inicial fue el catalizador para que todo el sector se replanteara cómo se construyen, gestionan y operan las redes. Gracias, Martin.

Esto también significa que si no fuera por Martín Casado, probablemente este libro no se habría escrito, ¡pero ahora nunca lo sabremos!

¿Qué son las redes definidas por software?

Hemos tenido una introducción a OpenFlow, pero ¿qué es la Red Definida por Software (SDN)? ¿Son la misma cosa, cosas diferentes, o ninguna de las dos? Para ser sinceros, SDN es lo mismo que era la Nube hace casi una década, antes de que conociéramos los distintos tipos de Nube, como la Infraestructura como Servicio (IaaS), la Plataforma como Servicio (PaaS) y el Software como Servicio (SaaS).

Disponer de ejemplos y diseños de referencia agiliza la comprensión de lo que era y es la Nube, pero incluso antes de que existieran estos términos, se podía debatir que cuando veías Nube, la conocías. En eso estamos con las Redes Definidas por Software. Existen definiciones públicas que afirman que las redes de caja blanca son SDN o que tener una API en un dispositivo de red es SDN. ¿Son realmente SDN? En realidad, no.

En lugar de intentar dar una definición de SDN, en cubriremos las tecnologías y tendencias que muy a menudo se consideran SDN y se incluyen en la conversación sobre SDN. Entre ellas se incluyen:

• OpenFlow

• Virtualización de Funciones de Red

• Conmutación virtual

• Virtualización de redes

• API de dispositivos

• Automatización de redes

• Conmutación bare-metal

• Tejidos de red para centros de datos

• SD-WAN

• Red de controladores

Nota

En este libro no ofrecemos intencionadamente una definición de SDN. Aunque la SDN se menciona en este capítulo, nos centramos principalmente en las tendencias generales que a menudo se categorizan como SDN para asegurarnos de que conoces cada una de estas tendencias de forma más específica.

De estas tendencias, el resto del libro se centrará en la automatización de redes, las API y las tecnologías periféricas que son fundamentales para comprender cómo se unen todas las piezas en los dispositivos de red que exponen interfaces programáticas con herramientas de automatización e instrumentación modernas.

OpenFlow

Incluso aunque hemos presentado OpenFlow anteriormente, queremos destacar algunos puntos clave más que debes conocer relacionados con OpenFlow.

Una de las principales ventajas que se suponía que se derivarían del uso de un protocolo como OpenFlow entre un controlador y los dispositivos de red era que habría una verdadera independencia de proveedor entre el software del controlador, a veces denominado sistema operativo de red (NOS), y los dispositivos de red virtuales y físicos subyacentes. Lo que ha ocurrido en realidad, sin embargo, es que los proveedores que utilizan OpenFlow en su solución (algunos ejemplos son Big Switch Networks, HP y NEC) han desarrollado extensiones de OpenFlow debido al ritmo de las normas y a la necesidad de proporcionar funciones únicas de valor añadido que la versión comercial de OpenFlow no ofrece. Aún está por ver si todas las extensiones acaban llegando a futuras versiones de la norma OpenFlow.

Cuando se utiliza OpenFlow, obtienes el beneficio de ser más granular con la forma en que el tráfico atraviesa la red, pero un gran poder conlleva una gran responsabilidad. Esto es estupendo si tienes un equipo de desarrolladores. Por ejemplo, Google puso en marcha una WAN basada en OpenFlow llamada B4 que aumenta la eficiencia de su WAN hasta casi el 100%. Para la mayoría de las demás organizaciones, el uso de OpenFlow o de cualquier otro protocolo determinado será menos importante que lo que una solución global ofrece a la empresa a la que se presta apoyo.

Nota

Aunque esta sección concreta se llama OpenFlow, arquitectónicamente se trata de desacoplar el plano de control del plano de datos. OpenFlow es sólo el protocolo principal que se utiliza para lograr esta funcionalidad.

Virtualización de Funciones de Red

Red La Virtualización de Funciones, conocida como NFV, no es un concepto complejo. Se refiere a tomar funciones que tradicionalmente se han desplegado como hardware, y en su lugar desplegarlas como software. Los ejemplos más comunes son las máquinas virtuales que funcionan como routers, cortafuegos, equilibradores de carga, IDS/IPS, VPN, cortafuegos de aplicaciones y cualquier otro servicio/función.

Con la NFV, se hace posible descomponer una pieza monolítica de hardware que puede haber costado decenas o cientos de miles de dólares, con cientos o miles de líneas de comandos, para configurarla en N piezas de software, a saber, aparatos virtuales. Estos dispositivos más pequeños se vuelven mucho más manejables desde una perspectiva de dispositivo individual.

Nota

El escenario anterior utiliza dispositivos virtuales como factor de forma para los dispositivos habilitados para NFV. Esto no es más que un ejemplo. La implementación de las funciones de red como software puede realizarse de muchas formas, por ejemplo, integradas en un hipervisor, en un contenedor o como una aplicación que se ejecuta sobre un servidor x86.

En no es infrecuente implementar hardware que puede ser necesario dentro de tres o cinco años por si acaso, porque es demasiado complicado y aún más caro tener actualizaciones graduales. Así que el hardware no sólo es un coste de capital intensivo, sino que sólo se utiliza para los escenarios hipotéticos en caso de crecimiento. La implementación de soluciones basadas en software, o NFV, ofrece una forma mejor de escalar y minimizar el dominio de fallos de una red o aplicación concreta, al tiempo que se utiliza un modelo de pago por crecimiento. Por ejemplo, en lugar de comprar un único Cisco ASA de gran tamaño, puedes implementar gradualmente dispositivos Cisco ASAv y pagar a medida que creces. También puedes ampliar fácilmente los equilibradores de carga con las nuevas tecnologías de una empresa como Avi Networks.

Si la NFV puede ofrecer tantas ventajas, ¿por qué no se han desplegado en producción más soluciones y productos que encajen en esta categoría? En realidad, hay varias razones. En primer lugar, requiere un replanteamiento de la arquitectura de la red. Cuando hay un único cortafuegos monolítico (como ejemplo), todo pasa a través de ese cortafuegos, es decir, todas las aplicaciones y todos los usuarios, o si no todos, un conjunto definido del que eres consciente. En el modelo moderno de NFV, en el que puede haber muchos cortafuegos virtuales desplegados, hay un cortafuegos por aplicación o inquilino, en lugar de un único cortafuegos monolítico. Esto hace que el dominio de fallo por cortafuegos, o cualquier otro dispositivo de servicios, sea bastante pequeño, y si se realiza un cambio o se implanta una nueva aplicación, no es necesario cambiar los demás cortafuegos basados en aplicaciones (por inquilino).

Por otra parte, en el mundo más tradicional de tener dispositivos monolíticos, existe esencialmente un único panel de gestión para la política de seguridad: una única CLI o GUI. Esto puede hacer que el dominio del fallo sea inmenso, pero ofrece a los administradores una gestión racionalizada de las políticas, ya que sólo se gestiona un único dispositivo. En función del equipo o personal que dé soporte a estos dispositivos, puede que sigan optando por un enfoque monolítico. Esa es la realidad, pero esperemos que con el tiempo, con herramientas mejoradas que puedan ayudar con el consumo y la gestión de soluciones centradas en el software, como industria, veamos más implementaciones que aprovechen este tipo de tecnología. De hecho, en un mundo con operaciones y gestión de red modernas y automatizadas, importará menos qué arquitectura se elija desde el punto de vista de la eficacia operativa, ya que podrás gestionar un único dispositivo o una mayor cantidad de dispositivos de forma mucho más eficaz.

Aparte de la gestión, otro factor que influye es que muchos proveedores no venden activamente su edición de dispositivos virtuales. No decimos que no tengan opciones virtuales, pero no suelen ser la opción preferida de muchos fabricantes de equipos tradicionales. Si un proveedor ha tenido un negocio de hardware durante los últimos años, supone un cambio drástico a un modelo basado en software desde el punto de vista de las ventas y la remuneración. Por ello, muchos de estos vendedores están limitando el rendimiento o las prestaciones de su tecnología basada en dispositivos virtuales.

Como se verá en muchas de estas áreas tecnológicas, un valor importante de la NFV está también en la agilidad. Eliminar el hardware reduce el tiempo necesario para suministrar nuevos servicios, al eliminar el tiempo necesario para montar, apilar, cablear e integrar en un entorno existente. Aprovechando un enfoque de software, resulta tan rápido como implementar una nueva máquina virtual en el entorno, y una ventaja inherente a este enfoque es poder clonar y hacer copias de seguridad del dispositivo virtual para pruebas posteriores, por ejemplo en entornos de recuperación ante desastres (DR).

Por último, cuando se implementa la NFV, se elimina la necesidad de dirigir el tráfico a través de un dispositivo físico específico para obtener el servicio requerido.

Conmutación virtual

Los conmutadores virtuales más comunes en el mercado actualmente incluyen el conmutador estándar de VMware (VSS), el conmutador distribuido de VMware (VDS), Cisco Nexus 1000V, el conmutador virtual de aplicaciones de Cisco (AVS) y el conmutador de código abierto Open vSwitch (OVS).

Estos conmutadores se ven envueltos de vez en cuando en el debate sobre SDN, pero en realidad son conmutadores basados en software que residen en el núcleo del hipervisor y proporcionan conectividad de red local entre máquinas virtuales (y ahora contenedores). Proporcionan funciones como el aprendizaje MAC y características como la agregación de enlaces, SPAN y sFlow, al igual que sus homólogos físicos llevan años haciendo. Aunque estos conmutadores virtuales se encuentran a menudo en soluciones SDN y de virtualización de red más completas, por sí mismos son un conmutador que simplemente se ejecuta por software. Aunque los conmutadores virtuales no son una solución por sí mismos, son extremadamente importantes a medida que avanzamos como industria. Han creado una nueva capa de acceso, o nuevo perímetro, dentro del centro de datos. El perímetro de la red ya no es el conmutador físico de la parte superior del bastidor (TOR), definido por el hardware y con una flexibilidad limitada (en términos de desarrollo de características/funciones). Puesto que el nuevo perímetro está basado en software mediante el uso de conmutadores virtuales, ofrece la posibilidad de crear más rápidamente nuevas funciones de red en software, y por tanto, es posible distribuir la política más fácilmente por toda la red. Por ejemplo, la política de seguridad puede desplegarse en el puerto del conmutador virtual más cercano al punto final real, ya sea una máquina virtual o un contenedor, para mejorar aún más la seguridad de la red.

Virtualización de redes

Las soluciones que se clasifican como virtualización de red se han convertido en sinónimo de soluciones SDN. Para fines de esta sección, la virtualización de red se refiere a soluciones basadas en superposición sólo de software. Las soluciones más populares que entran en esta categoría son NSX de VMware, Virtual Service Platform (VSP) de Nuage y Contrail de Juniper.

Una característica clave de estas soluciones es que se utiliza un protocolo basado en superposición, como Virtual eXtensible LAN (VxLAN), para crear conectividad entre conmutadores virtuales basados en hipervisor. Este enfoque de conectividad y tunelización proporciona adyacencia de Capa 2 entre máquinas virtuales que existen en distintos hosts físicos, independientemente de la red física, lo que significa que la red física puede ser de Capa 2, de Capa 3 o una combinación de ambas. El resultado es una red virtual desacoplada de la red física y destinada a proporcionar capacidad de elección y agilidad.

Nota

Vale la pena señalar que el término red superpuesta se utiliza a menudo junto con el término red subyacente. Para mayor claridad, la red subyacente es la red física subyacente que se cablea físicamente. La red superpuesta se construye utilizando una solución de virtualización de red que crea dinámicamente túneles entre conmutadores virtuales dentro de un centro de datos. De nuevo, esto es en el contexto de una solución de virtualización de red basada en software. También hay que tener en cuenta que muchas soluciones sólo de hardware se están implementando ahora con VxLAN como protocolo superpuesto para establecer túneles de Capa 2 entre dispositivos de la parte superior del bastidor dentro de un centro de datos de Capa 3.

Aunque la superposición es un detalle de implementación de las soluciones de virtualización de red, estas soluciones son mucho más que simples conmutadores virtuales unidos por superposiciones. Estas soluciones suelen ser integrales, y ofrecen seguridad, equilibrio de carga e integraciones en la red física, todo ello con un único punto de gestión (es decir, el controlador). A menudo, estas soluciones también ofrecen integraciones con las mejores empresas de servicios de Capa 4-7, lo que permite elegir qué tecnología se puede implementar en las plataformas de virtualización de red.

También se consigue agilidad gracias a la plataforma del controlador central, que se utiliza para configurar dinámicamente cada conmutador virtual y los dispositivos de servicios según sea necesario. Si recuerdas, la red se ha quedado rezagada operativamente debido a la CLI omnipresente en todos los proveedores del mundo físico. En la virtualización de la red, no hay necesidad de configurar manualmente los conmutadores virtuales, ya que cada solución simplifica este proceso proporcionando una GUI central, una CLI y también una API en la que se pueden hacer cambios mediante programación.

API de dispositivos

En los últimos años, los vendedores han empezado a darse cuenta de que limitarse a ofrecer una CLI estándar ya no iba a ser suficiente y que utilizar una CLI ha frenado gravemente las operaciones. Si alguna vez has trabajado con algún lenguaje de programación o scripting, probablemente puedas entenderlo. Para los que no, hablaremos más de esto en el Capítulo 7.

El principal problema es que los scripts con dispositivos de red heredados o basados en CLI no devuelven datos estructurados. Esto significaba que el dispositivo devolvía los datos a un script en formato de texto sin procesar (es decir, la salida de una versión show) y, a continuación, la persona que escribía el script tenía que analizar ese texto para extraer atributos como el tiempo de actividad o la versión del sistema operativo. Cuando la salida de los comandos show cambiaba, aunque fuera ligeramente, los scripts se rompían debido a reglas de análisis incorrectas. Aunque este enfoque es todo lo que han tenido los administradores, la automatización era técnicamente posible, pero ahora los proveedores están migrando gradualmente a dispositivos de red controlados por API.

Ofrecer una API elimina la necesidad de analizar texto sin procesar, ya que se devuelven datos estructurados de un dispositivo de red, lo que reduce significativamente el tiempo que se tarda en escribir un script. En lugar de analizar el texto para encontrar el tiempo de actividad o cualquier otro atributo, se devuelve un objeto que proporciona exactamente lo que se necesita. No sólo reduce el tiempo necesario para escribir un script, disminuyendo la barrera de entrada para los ingenieros de redes (y otros no programadores), sino que también proporciona una interfaz más limpia para que los desarrolladores profesionales de software puedan desarrollar y probar código rápidamente, de la misma forma que operan utilizando API en dispositivos que no son de red. "Probar código" podría significar probar nuevas topologías, certificar nuevas funciones de red, validar configuraciones de red concretas, etc. Todas estas cosas se hacen manualmente hoy en día y consumen mucho tiempo y son propensas a errores.

Una de las primeras API más populares en la escena de las redes fue la de Arista Networks. Su API se llama eAPI, que es una API basada en HTTP que utiliza datos codificados en JSON. No te preocupes, las API basadas en HTTP y JSON se tratarán en los capítulos siguientes, empezando por el Capítulo 5. Desde Arista, hemos visto a Cisco anunciar API como Nexus NX-API y NETCONF/RESTCONF en plataformas concretas y a un proveedor como Juniper, que ha tenido siempre una interfaz NETCONF extensible pero no ha llamado demasiado la atención públicamente sobre ella. Cabe señalar que casi todos los proveedores tienen algún tipo de API en la actualidad.

Este tema se tratará con mucho más detalle en el capítulo 7.

Automatización de redes

A medida que las API de en el mundo de las redes sigan evolucionando, también seguirán surgiendo casos de uso más interesantes para aprovecharlas. A corto plazo, la automatización de redes es un candidato ideal para aprovechar las interfaces programáticas que exponen los dispositivos de red modernos que ofrecen una API.

Para ponerlo en un contexto más amplio, la automatización de redes no consiste sólo en automatizar la configuración de los dispositivos de red. Es cierto que ésa es la percepción más común de la automatización de redes, pero el uso de API e interfaces programáticas puede automatizar y ofrecer mucho más que el envío de parámetros de configuración.

Aprovechar una API agiliza el acceso a todos los datos embotellados en los dispositivos de red. Piensa en datos como los de nivel de flujo, tablas de enrutamiento, tablas FIB, estadísticas de interfaz, tablas MAC, tablas VLAN, números de serie... la lista puede ser interminable. El uso de modernas técnicas de automatización que, a su vez, aprovechan una API, puede ayudar rápidamente en las operaciones cotidianas de gestión de redes para la recopilación de datos y el diagnóstico automatizado. Además, como se utiliza una API que devuelve datos estructurados, como administrador tendrás la capacidad de mostrar y analizar el conjunto exacto de datos que quieras y necesites, incluso procedentes de varios comandos de show, reduciendo en última instancia el tiempo que se tarda en depurar y solucionar problemas en la red. En lugar de conectarte a N routers que ejecutan BGP intentando validar una configuración o solucionar un problema, puedes utilizar técnicas de automatización para simplificar este proceso.

Además, aprovechar las técnicas de automatización conduce a una red más predecible y uniforme en su conjunto. Puedes verlo automatizando la creación de archivos de configuración, automatizando la creación de una VLAN o automatizando el proceso de resolución de problemas. Agiliza el proceso para todos los usuarios que dan soporte a un entorno determinado, en lugar de que cada administrador de red tenga sus propias buenas prácticas.

Los distintos tipos de automatización de la red se tratarán en el Capítulo 2 con mucha más profundidad.

Conmutación bare-metal

El tema de la conmutación bare-metal también se suele considerar SDN, pero no lo es. De verdad, ¡no lo es! Dicho esto, en nuestro esfuerzo por ofrecer una introducción a las diversas tendencias tecnológicas que se perciben como SDN, es necesario abarcarlo. Si rebobinamos hasta 2014 (e incluso antes), el término utilizado para describir la conmutación bare-metal era conmutación white-box o commodity. El término ha cambiado, y no sin una buena razón.

Antes de hablar del cambio de white-box a bare-metal, es importante entender lo que esto significa a alto nivel, ya que supone un cambio masivo en la forma de concebir los dispositivos de red. Durante los últimos 20 años, los dispositivos de red siempre se compraban como dispositivos físicos: estos dispositivos físicos venían como aparatos de hardware, un sistema operativo y funciones/aplicaciones que podías utilizar en el sistema. Todos estos componentes procedían del mismo proveedor.

En los dispositivos de red de caja blanca y bare-metal, el dispositivo se parece más a un servidor x86 (ver Figura 1-3). Permite al usuario desagregar cada uno de los componentes necesarios, lo que hace posible adquirir hardware de un proveedor, comprar un sistema operativo de otro y luego cargar funciones/aplicaciones de otros proveedores o incluso de la comunidad de código abierto.

La conmutación de caja blanca fue un tema candente durante un tiempo, en pleno auge de OpenFlow, ya que la intención era comoditizar el hardware y centralizar el cerebro de la red en un controlador OpenFlow, ahora conocido como controlador SDN. Y en 2013, Google anunció que había construido sus propios conmutadores y que los controlaba con OpenFlow. Este fue el tema de muchas conversaciones del sector en aquel momento, pero en realidad, no todos los usuarios finales son Google, así que no todos los usuarios construirán sus propias plataformas de hardware y software.

Paralelamente a estos esfuerzos, asistimos a la aparición de algunas empresas centradas exclusivamente en ofrecer soluciones en torno a la conmutación de caja blanca. En están Big Switch Networks, Cumulus Networks y Pica8. Cada una de ellas ofrece soluciones sólo de software, por lo que siguen necesitando hardware en el que se ejecute su software para ofrecer una solución integral. Inicialmente, estas plataformas de hardware de caja blanca procedían de Fabricantes Originales Directos (ODM) como Quanta, Super Micro y Accton. Si has estado en el sector de las redes, lo más probable es que ni siquiera hayas oído hablar de esos proveedores.

Figura 1-3. Un vistazo a las pilas de conmutación tradicionales y bare-metal

No fue hasta que Cumulus y Big Switch anunciaron asociaciones con empresas como HP y Dell cuando el sector empezó a pasar de llamar a esta tendencia white-box a bare-metal, ya que ahora los vendedores de marca apoyaban sistemas operativos de terceros de la talla de Big Switch y Cumulus Networks en sus plataformas de hardware.

Todavía puede haber confusión sobre por qué bare-metal no es técnicamente SDN, ya que un proveedor como Big Switch juega en ambos mundos. La respuesta es sencilla. Si hay un controlador integrado en la solución que utiliza un protocolo como OpenFlow (no tiene por qué ser OpenFlow), y se comunica mediante programación con los dispositivos de red, eso le da el sabor de las Redes Definidas por Software. Esto es lo que hace Big Switch: carga software en el hardware bare-metal/white-box que ejecuta un agente OpenFlow que se comunica con el controlador como parte de su solución.

Por otro lado, Cumulus Networks ofrece una distribución Linux especialmente diseñada para conmutadores de red. Esta distribución, o sistema operativo, ejecuta protocolos tradicionales como LLDP, OSPF y BGP, sin necesidad de controlador alguno, lo que la hace más comparable y compatible con arquitecturas de red no basadas en SDN.

Con esta descripción debería ser evidente que Cumulus es una empresa de sistemas operativos de red que ejecuta su software en conmutadores bare-metal, mientras que Big Switch es una empresa de SDN basada en bare-metal que requiere el uso de su controlador SDN, pero también aprovecha la infraestructura de conmutación bare-metal de terceros.

En resumen, la conmutación bare-metal/white-box consiste en la desagregación y en tener la capacidad de comprar hardware de red de un proveedor y cargar software de otro, si así lo decides. En este caso, se ofrece a los administradores la flexibilidad de cambiar diseños, arquitecturas y software, sin cambiar el hardware, sólo el sistema operativo subyacente.

Tejidos de red para centros de datos

¿Te has enfrentado alguna vez a la situación de no poder intercambiar fácilmente los distintos dispositivos de red de una red aunque todos estuvieran ejecutando protocolos estándar como Spanning Tree u OSPF? Si es así, no eres el único. Imagina que tienes una red de centro de datos con un núcleo colapsado y conmutadores individuales en la parte superior de cada bastidor. Ahora piensa en el proceso que hay que seguir cuando llega el momento de una actualización.

Hay muchas formas de actualizar redes como ésta, pero ¿y si sólo hubiera que actualizar los conmutadores de la parte superior del bastidor y, en el proceso de evaluación de los nuevos conmutadores TOR, se decidiera utilizar un nuevo proveedor o plataforma? Esto es 100% normal y se ha hecho una y otra vez. El proceso es sencillo: interconecta los nuevos conmutadores al núcleo existente (por supuesto, suponemos que hay puertos disponibles en el núcleo) y configura adecuadamente el trunking 802.1Q si se trata de una interconexión de Capa 2 o configura tu protocolo de enrutamiento favorito si se trata de una interconexión de Capa 3.

Aparecen los tejidos de red de los centros de datos. Aquí es donde debe cambiar el proceso de pensamiento en torno a las redes de los centros de datos.

Los tejidos de red de los centros de datos pretenden cambiar la mentalidad de los operadores de red, que pasan de gestionar cajas individuales de una en una a gestionar un sistema en su totalidad. Si utilizamos el escenario anterior, no sería posible cambiar un conmutador TOR por otro proveedor, que es sólo un componente individual de la red de un centro de datos. Más bien, cuando la red se implementa y gestiona como un sistema, hay que pensar en ella como un sistema. Esto significa que el proceso de actualización consistiría en migrar de sistema a sistema, o de tejido a tejido. En el mundo de los tejidos, los tejidos pueden intercambiarse cuando llega el momento de una actualización, pero los componentes individuales del tejido no, al menos la mayoría de las veces. Puede ser posible cuando un proveedor específico proporciona una ruta de migración o actualización y cuando se utiliza la conmutación bare-metal (sólo se sustituye el hardware). A Algunos ejemplos de tejidos de red para centros de datos son la Infraestructura Centrada en las Aplicaciones (ACI) de Cisco, el Big Cloud Fabric (BCF) de Big Switch, o el tejido y la red hiperconvergente de Plexxi.

Además de tratar la red como un sistema, otros atributos comunes de los tejidos de red de los centros de datos son:

• Ofrecen una única interfaz para gestionar o configurar el tejido, incluida la gestión de políticas.

• Ofrecen pasarelas por defecto distribuidas por el tejido.

• Ofrecen capacidades multitrayectoria.

• Utilizan algún tipo de controlador SDN para gestionar el sistema.

SD-WAN

Una de las tendencias más candentes en Redes Definidas por Software en los últimos dos años ha sido la Red de Área Amplia Definida por Software (SD-WAN). En los últimos años, se ha lanzado un número creciente de empresas para abordar el problema de las Redes de Área Amplia. Algunos de estos proveedores son Viptela (recientemente adquirida por Cisco), CloudGenix, VeloCloud, Cisco IWAN, Glue Networks y Silverpeak.

La WAN no había visto un cambio radical de tecnología desde la migración de Frame Relay a MPLS. Como la banda ancha e Internet cuestan una fracción de lo que cuestan los circuitos de línea privada equivalentes, se ha producido un aumento del aprovechamiento de los túneles VPN de sitio a sitio a lo largo de los años, sentando las bases para el próximo gran cambio en la WAN.

Los diseños habituales para oficinas remotas suelen incluir un circuito privado (MPLS) y/o una conexión pública a Internet. Cuando existen ambos, Internet suele utilizarse sólo como respaldo, concretamente para el tráfico de invitados, o para datos generales que vuelven a través de una VPN a la empresa, mientras que el circuito MPLS se utiliza para aplicaciones de baja latencia, como las comunicaciones de voz o vídeo. Cuando el tráfico empieza a dividirse entre circuitos, aumenta la complejidad de la configuración del protocolo de encaminamiento y también se limita la granularidad de cómo encaminar a la dirección de destino. La dirección de origen, la aplicación y el rendimiento en tiempo real de la red no suelen tenerse en cuenta en las decisiones sobre la mejor ruta a seguir.

Una arquitectura SD-WAN común que utilizan muchas de las soluciones modernas es similar a la de la virtualización de red utilizada en el centro de datos, en el sentido de que se utiliza un protocolo superpuesto para interconectar los dispositivos de perímetro SD-WAN. Como se utilizan superposiciones, la solución es agnóstica respecto al transporte físico subyacente, lo que hace que la SD-WAN sea funcional en Internet o en una WAN privada. Estas soluciones a menudo viajan sobre dos o más circuitos de Internet en las sucursales, cifrando completamente el tráfico mediante IPSec. Además, muchas de estas soluciones miden constantemente el rendimiento de cada circuito en uso, pudiendo conmutar rápidamente entre circuitos para aplicaciones específicas, incluso durante caídas de tensión. Como hay visibilidad de la capa de aplicación, los administradores también pueden elegir fácilmente qué aplicación debe tomar una ruta determinada. Este tipo de características no suelen encontrarse en las arquitecturas WAN que se basan únicamente en el enrutamiento basado en el destino mediante el protocolo de enrutamiento tradicional, como OSPF y BGP.

Desde el punto de vista de la arquitectura de, las soluciones SD-WAN de los proveedores mencionados anteriormente, como Cisco, Viptela y CloudGenix, también suelen ofrecer algún tipo de aprovisionamiento sin intervención (ZTP) y gestión centralizada con un portal que existe en las instalaciones o en la nube como aplicación basada en SaaS, lo que simplifica drásticamente la gestión y las operaciones de la WAN en el futuro.

Un valioso subproducto del uso de la tecnología SD-WAN es que ofrece más opciones a los usuarios finales, ya que básicamente se puede utilizar cualquier operador o tipo de conexión en la WAN y a través de Internet. Al hacerlo, simplifica la configuración y la complejidad de las redes de las operadoras, lo que a su vez permitirá a éstas simplificar su diseño y arquitectura internos, con lo que es de esperar que reduzcan sus costes. Yendo un paso más allá desde el punto de vista técnico, todas las construcciones lógicas de red, como el Enrutamiento y Reenvío Virtuales (VRF), se gestionarían a través de la interfaz de usuario (UI) de la plataforma controladora que proporciona el proveedor de SD-WAN, eliminando de nuevo la necesidad de esperar semanas a que las operadoras te respondan cuando sea necesario realizar cambios.

Red de controladores

Cuando se trata de varias de estas tendencias, hay cierto solapamiento, como te habrás dado cuenta. Ése es uno de los puntos confusos cuando intentas comprender todas las nuevas tecnologías y tendencias que han surgido en los últimos años.

En, por ejemplo, las plataformas de virtualización de red más populares utilizan un controlador, al igual que varias soluciones que entran también en las categorías de tejido de red de centro de datos, SD-WAN y conmutador bare-metal. ¿Confuso? Tal vez te preguntes por qué se han separado las redes basadas en controladores. En realidad, a menudo es sólo una característica y un mecanismo para ofrecer soluciones modernas, pero no todas las tendencias anteriores abarcan todo lo que los controladores pueden ofrecer desde una perspectiva tecnológica.

Por ejemplo, un controlador SDN de código abierto muy popular es OpenDaylight (ODL), como se muestra en la Figura 1-4. ODL, como muchos otros controladores, es una plataforma, no un producto. Son plataformas que pueden ofrecer aplicaciones especializadas, como la virtualización de redes, pero también pueden utilizarse para el monitoreo de redes, la visibilidad, la agregación de tomas o cualquier otra función junto con aplicaciones que se asienten sobre la plataforma del controlador. Ésta es la razón principal por la que es importante comprender lo que pueden ofrecer los controladores, más allá de su uso para aplicaciones más tradicionales como tejidos, virtualización de red y SD-WAN.

Figura 1-4. Arquitectura de OpenDaylight

Resumen

Aquí lo tienes: una introducción a las tendencias y tecnologías que más a menudo se categorizan como Redes Definidas por Software, allanando el camino hacia mejores operaciones de red mediante la programabilidad y automatización de la red. En los últimos siete años se han creado docenas de empresas emergentes de SDN, se han invertido millones en capital riesgo y se han gastado miles de millones en adquisiciones de estas empresas. Ha sido irreal, y si lo desglosamos un poco más, todo tiene el objetivo común de aprovechar los principios y la tecnología del software para ofrecer mayor poder, control, agilidad y capacidad de elección a los usuarios de la tecnología, aumentando al mismo tiempo la eficacia operativa.

En el Capítulo 2, echaremos un vistazo a la automatización de redes y profundizaremos en los distintos tipos de automatización, algunos protocolos y API comunes, y cómo ha empezado a evolucionar la automatización en los últimos años.