Documentos de Académico
Documentos de Profesional
Documentos de Cultura
TFG Pablo Sayaus Cobos
TFG Pablo Sayaus Cobos
i
Conectividad de red en Docker ........................................................................................... 37
Dockerfile ............................................................................................................................ 39
Open vSwitch .......................................................................................................................... 40
Desarrollo .................................................................................................................................... 45
Instalación de controladores ................................................................................................... 45
OpenDaylight....................................................................................................................... 45
ONOS ................................................................................................................................... 50
Escenarios probados ............................................................................................................... 54
Mininet ................................................................................................................................ 54
Máquinas Virtuales ............................................................................................................. 61
Docker ................................................................................................................................. 68
Automatización del desarrollo ................................................................................................ 72
Dockerizar los equipos finales ............................................................................................. 73
Dockerizar el controlador .................................................................................................... 74
Scripts de despliegue............................................................................................................... 79
Pruebas realizadas................................................................................................................... 80
Prueba 1 .............................................................................................................................. 80
Prueba 2 .............................................................................................................................. 81
Prueba 3 .............................................................................................................................. 82
Conclusiones ............................................................................................................................... 85
Líneas futuras .............................................................................................................................. 87
Anexos ......................................................................................................................................... 89
Anexo A: Script de despliegue SDN ......................................................................................... 89
Bibliografía .................................................................................................................................. 93
ii
RESUMEN
El presente trabajo pretende ofrecer un análisis actualizado de las Redes Definidas por Software
(Software Defined Networks, SDN). Se estudiarán los motivos por los que las redes
convencionales presentan serios defectos a la hora de gestionar la conectividad en los centros
de procesamiento de datos modernos. Se realizará un estado del arte de los diferentes
componentes de una red SDN y de los controladores de código abierto más extendidos. También
se ofrecerá un análisis extenso de los diferentes aspectos del protocolo sobre el que se soportan
las redes SDN actuales, OpenFlow. Por último, se realizará una comparativa entre diferentes
técnicas de virtualización para desplegar una red virtualizada en un ordenador personal. El
objetivo es determinar cuál es el mejor escenario para desplegar un entorno de pruebas SDN,
así como sentar las bases para una investigación posterior más exhaustiva.
ABSTRACT
The present project involves the analysis of Software Defined Networks (SDN). The reasons why
legacy networking infrastructures have several drawbacks managing actual datacenters will be
studied. Another goal is to offer a state-of-the-art of Software Defined Networks and their main
components. This includes the analysis of the most extended open source SDN controllers. Also,
will be analyzed the OpenFlow protocol, which is essential for running modern SDN
infrastructures. The research will draw upon several virtualization technologies that could be
helpful to deploy virtual networks in desktop or laptop computers. The target is to determine
which is the best scenario to create a testing environment for learning and testing purposes.
This will allow to lay the foundations for a future research on this field.
iii
INTRODUCCIÓN
Los servicios en la nube o servicios cloud se han posicionado en los últimos años como un motor
de la economía digital y de la transformación digital de las organizaciones, ya que se plantean
como una alternativa más económica a los servicios dedicados tradicionales y más ajustada a las
necesidades reales de cada cliente. Desde el correo electrónico particular de un usuario hasta
los servicios de vídeo bajo demanda, los servicios cloud están cada vez más presentes en la vida
diaria de las personas y las empresas. Sin embargo, detrás de este concepto abstracto se
esconden una serie de tecnologías que permiten, entre otras cosas, desplegar y escalar los
servicios en función de la demanda en tiempo real sin que la calidad o la continuidad se vean
afectadas. Para alcanzar semejante nivel de flexibilidad se utiliza la virtualización, que en última
instancia consiste en la separación total entre el nivel físico y el nivel lógico de los sistemas y, en
consecuencia, de las redes que los interconectan. Gracias a esta separación, se consigue
optimizar la gestión de los recursos físicos de los servidores, que están cambiando
constantemente para ajustarse a las necesidades del momento.
En esta tesitura, las tecnologías de red convencionales no están diseñadas para satisfacer las
necesidades de las redes que se construyen para operar los sistemas virtualizados, que se
caracterizan por su enorme flexibilidad y un elevado volumen de modificaciones en su topología.
Se hace, por tanto, necesario buscar tecnologías de red alternativas que estén preparadas para
hacer frente a las necesidades de los centros de datos donde se alojan los servicios cloud.
Mediante la lectura de este trabajo se pretende que el lector entienda el funcionamiento de las
redes definidas por software (Software Defined Networks, SDN), así como los protocolos sobre
los que se apoya. También se pretende ofrecer una imagen general de las tecnologías actuales
de virtualización y por qué se hace necesario gestionar la red mediante infraestructuras SDN en
vez usar tecnologías de red convencionales. Por último, se pretende ofrecer un entorno de
laboratorio base sobre el que aprender el funcionamiento de las redes definidas por software y
como futuro entorno de pruebas a la hora de programar aplicaciones para un controlador SDN.
iv
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS
POR SOFTWARE
Evolución de las redes de telecomunicaciones
Desde sus orígenes, la industria de las telecomunicaciones ha estado en constante evolución
para satisfacer las necesidades que han surgido con el tiempo. Para comprender correctamente
las características de las Redes Definidas por Software (SDN), así como sus ventajas e
inconvenientes, conviene hacer un repaso desde una perspectiva histórica de la evolución de las
redes.
Se pueden situar el origen de las comunicaciones digitales en las redes telefónicas conmutadas.
Cuando se deseaba establecer una comunicación entre dos puntos, era necesario que las
operadoras conectaran manualmente los circuitos en las centrales de conmutación antes de que
los extremos pudieran comunicarse. Esta primitiva forma de realizar conexiones tenía serias
desventajas. Por un lado, existía un elevado tiempo de establecimiento de la conexión. Por otro
lado, era una arquitectura con una reducida tolerancia a fallos. Al existir un único camino, fijo y
estático, por el que se enviaban y transmitían los datos, cualquier fallo en dicho camino
provocaba el corte de la comunicación entre los extremos [2].
En 1962, durante la Guerra Fría entre Estados Unidos y la Unión Soviética y en plena crisis de los
misiles de Cuba, el gobierno norteamericano buscaba crear una red que les permitiera
comunicarse y que sobreviviera a un ataque nuclear. El problema fundamental radicaba en que
la red telefónica militar americana estaba centralizada, de forma que, aunque los enlaces entre
los nodos sobreviviesen, un ataque contra la central de conmutación destruiría todas sus
comunicaciones. En esta tesitura, Paul Baran, un investigador de RAND, diseñó una red de
comunicaciones distribuida que garantizaba la redundancia. La red sería capaz de responder a
los fallos de forma autónoma, gracias a que cada nodo sabría encaminar la información en todo
momento. Además, planteó la necesidad de dividir la información en bloques antes de ser
transmitida. Cada bloque sería enviado individualmente, viajando por diferentes caminos y
reensamblado en el destino. Estas características permitían hacer un uso más eficiente de la red,
pues los bloques viajaban más deprisa que si se enviaba la información sin fragmentar. Además,
al existir varios caminos entre los extremos, en caso de fallo en las líneas entre algunos de los
nodos, la información seguiría llegando a su destino [1].
Ilustración 1. Paul Baran propuso un modelo de red distribuido frente al modelo centralizado vigente.
1
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Las Redes Definidas por Software suponen un choque directo a este concepto de red distribuida
de nodos autónomos. En este nuevo modelo se aboga por centralizar el control de la red en un
único nodo de gestión. Este nodo, denominado “controlador”, es el encargado de indicarle a los
demás dispositivos de red por dónde deben encaminar la información.
Es interesante comprobar cómo, frente al modelo distribuido actual con una elevada tolerancia
a fallos gracias al esfuerzo colectivo de todos sus miembros, se plantea un regreso a los orígenes
de las telecomunicaciones y centralizar de nuevo la gestión de la red, creando un único punto
de fallo en el sistema. Lógicamente, la aparición de las redes SDN responde a la necesidad de
dar solución a una serie de problemas que han aparecido en los últimos tiempos y que no
existían en el momento en que se formuló el modelo actual de red. Además, la llegada de nuevas
tecnologías como los servicios cloud, la virtualización y el Internet of things (IoT) plantean nuevos
retos a los que las redes tradicionales no pueden hacer frente de forma eficaz.
A lo largo de este trabajo se hablará en profundidad sobre los problemas que afrontan las redes
modernas y cómo las redes definidas por software pueden arreglar o mitigar estos problemas.
También se hablará de estas tecnologías emergentes y por qué van de la mano de las redes SDN.
2
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Toda esta información que se debe procesar y transmitir pertenece al denominado plano de
control. En este contexto, se puede definir el plano de control como la inteligencia que
determina los caminos óptimos para enviar la información y que responde a los incidentes y a
las nuevas demandas de la red [11].
Hasta ahora, los protocolos del plano de control han sido fundamentales para el correcto
funcionamiento de las redes en todos los ámbitos. Pero en los últimos tiempos se plantean
nuevos retos al paradigma tradicional. Por un lado, la entrada en escena de la virtualización,
cada vez más relevante, ha trastocado la forma de concebir las redes. Por otro lado, el
crecimiento de las infraestructuras de red lleva a plantearse la optimalidad del modelo actual
de control en términos de rendimiento y consumo de ancho de banda. A mayor número de
routers conectados, mayor consumo de ancho de banda en la red dedicado a protocolos de
enrutamiento y mayor consumo de recursos dentro de cada router para mantener actualizada
la topología. Se hablará sobre la saturación del plano de control en profundidad más adelante y
cómo resuelven este problema las redes SDN.
El nivel de enlace (nivel dos) contiene muchos más dispositivos que el nivel de red (nivel tres)1.
La mayoría de las redes privadas son grandes redes conmutadas de switches con un router
perimetral para conectar la red privada con Internet. Los switches están conectados entre sí de
forma que existen caminos redundantes. Esto significa que, si alguno deja de estar operativo,
existen caminos alternativos para enviar la información sin perder servicio. A diferencia de los
routers, los switches no se comunican entre ellos para obtener información sobre por dónde
deben enviar la información que reciben. Cuando un switch recibe una trama Ethernet, asocia
la MAC origen de la trama con el puerto por el que la ha recibido, de esta forma va asociando
cada una de sus interfaces con las MAC de los dispositivos que envían información por dichas
1
Cuando se hable de los diferentes niveles en una infraestructura de red se hará referencia a los
establecidos por el modelo OSI.
3
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
interfaces. Cuando recibe una trama cuya MAC destino no se encuentra en la tabla, la reenvía
por todos los puertos excepto por el que lo ha recibido. Pero, ¿Qué ocurre si ningún switch
conoce la MAC destino y todos empiezan a hacer difusión por todos sus puertos? La red
conmutada colapsaría, pues cada trama que llegara a otro switch generaría aún más tramas.
Además, las tramas circularían indefinidamente, ya que el protocolo Ethernet no tiene un campo
similar al TTL (Time-to-live) del nivel de red para descartar un paquete que lleva mucho tiempo
saltando entre diferentes switches.
Como se puede observar, se hace necesario un protocolo de control que elimine los bucles en
las redes conmutadas y asegure un envío correcto de los datos. El protocolo Spanning Tree
Protocol (STP) cumple este propósito. Para ello, los switches que forman bucles se comunican
entre sí estableciendo una topología en forma de árbol (desactivando algunas de sus interfaces)
y se envían mensajes regularmente para comprobar si siguen activos, ya que en caso contrario
se debe generar un nuevo árbol, con el coste computacional y de red asociados que tiene esta
acción. De esta manera, se elimina la posibilidad de que una trama enviada por un switch acabe
volviendo a ese switch por otro camino. En la actualidad existen múltiples versiones
evolucionadas del protocolo STP original, que ha quedado obsoleto. La llegada de las VLANs
(Virtual Local Arena Networks) forzó a una reinvención de STP. En la actualidad, cada VLAN tiene
asociada una instancia de Spanning Tree, de forma que a nivel lógico existe un árbol con una
topología diferente para cada VLAN. Esto se hace principalmente por una cuestión de
rendimiento, ya que permite hacer balanceo de tráfico en el nivel dos. Sin embargo, esta
evolución ha supuesto también dos contrapartidas fundamentales. Primero, un mayor número
de instancias de Spanning Tree activas en el switch supone un mayor coste computacional para
estos dispositivos. Segundo, se han desarrollado numerosas variantes de STP, algunas son
estándares abiertos, como RSTP (Rapid Spanning Tree Protocol) y MSTP (Multiple Spanning Tree
Protocol). Otros son protocolos propietarios, como PVST+ (Per-VLAN Spanning Tree, de Cisco) o
VSTP (VLAN Spanning Tree Protocol, de Juniper Networks). Aunque casi todos los fabricantes
dan soporte a los protocolos estandarizados, en caso de querer usar protocolos propietarios se
fuerza a los usuarios a usar dispositivos del mismo fabricante en su red conmutada, ya que estos
lógicamente no son interoperables entre fabricantes distintos.
Las redes definidas por software solucionan ambos problemas eficazmente. En las redes SDN no
es necesario usar STP para eliminar los bucles, ya que se trabaja con flujos. Cuando un switch no
sabe encaminar tráfico de nivel dos, no se hace (a priori) difusión de la trama, sino que se le
consulta al controlador, que genera un camino para ese tráfico, y le informa al switch de dicho
camino. Esto supone, por tanto, una notable reducción del coste computacional del plano de
control y la eliminación de problemas de compatibilidad entre las diferentes versiones de STP.
También elimina el tráfico generado por Spanning Tree en todos los switches, lo que ayuda a
descongestionar la red.
Originalmente, los routers en los primeros días de Internet, en la década de los 80, consistían en
ordenadores Unix de propósito general con una capa de software sobre el sistema operativo
que permitía la gestión de la información recibida. Cuando recibía un paquete, analizaba su tabla
de rutas en memoria y lo encaminaba por la interfaz correspondiente. Si recibía información del
plano de control (protocolos de routing dinámico), se la pasaba al proceso Unix responsable del
4
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
plano de control [20]. En la capa de nivel dos se ofrecían puentes. Los puentes ofrecían una LAN
conmutada interconectando segmentos LAN.
A principios de los 90, con el incremento de las velocidades de transmisión, se hizo necesario
paralelizar los procesos en los routers. En esta época, se instalaban racks con múltiples blades
enrutando tráfico a través de una tabla de rutas distribuida común. Sin embargo, el continuo
aumento de las velocidades en las interfaces hizo que llegara un punto donde el tiempo de
lectura de la tabla de rutas en la RAM de los routers era insuficiente para mantener el ritmo [6].
Se hacía, por tanto, necesario encontrar fórmulas que redujeran el tiempo de procesamiento de
los paquetes. A mediados de la década de los 90 se inventan los primeros dispositivos de red
con hardware dedicado. Se incorporan ASICs (Application-Specific Integrated Circuit, circuito
Integrado para aplicaciones específicas) y CAMs (Content-Addressable Memory) para acelerar el
procesamiento de los paquetes recibidos. Su primera aplicación comercial hace su aparición en
los switches Ethernet. En un primer momento, los routers siguieron funcionando mediante
software. Esto se debe a que el análisis de las cabeceras de nivel tres es más complejo que el de
las de nivel dos. Posteriormente esta tecnología llegó también a los routers.
Es interesante comprobar cómo, frente a la evolución del hardware en los dispositivos de red
con el fin de mejorar la velocidad a la que se procesan los paquetes, las redes SDN plantean una
regresión parcial. Esto no significa que no haya hardware específico de red como parte de la
infraestructura en las redes definidas por software. Pero parte de los equipos finales de la red
pasan a ser virtuales. En el contexto actual, una máquina física alberga varias máquinas virtuales,
cada una con su propia interfaz virtual de red. En esta situación, los responsables directos de
encaminar su tráfico son también dispositivos virtuales. Por tanto, en última instancia se usan
ordenadores de propósito general (virtuales) para operar una parte de la red, de forma similar
a como se hacía en los primeros días de Internet.
Para hacerse una idea de la magnitud, conviene arrojar algunas cifras. Los centros de datos
modernos se están construyendo para albergar alrededor de 120,000 servidores físicos. En la
actualidad, cada servidor físico alberga de media 20 máquinas virtuales. Esto implica que la red
interna actual de un centro de datos puede albergar en torno a 2,400,000 equipos finales, sin
contar dispositivos de red. Y el problema se está acentuando aún más, pues la aparición de la
tecnología de virtualización basada en contenedores implica aún más dispositivos virtuales en
5
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
la red, ya que dentro de cada máquina virtual se pueden ejecutar decenas o incluso cientos de
contenedores. Más allá del problema que supone mantener operativa una infraestructura de
esta escala, la cantidad de enlaces y dispositivos que hay que monitorizar y gestionar plantea un
problema en sí mismo [3].
Por tanto, a primera vista se distinguen dos retos fundamentales en la gestión de un CPD
moderno. Por un lado, la compleja tarea de administrar y monitorizar el elevado número de
dispositivos y enlaces de red presentes. Por otro lado, el elevado consumo de recursos que
requiere el plano de control de estos dispositivos para mantener operativa la red.
Por tanto, deben buscarse maneras de conseguir una red controlada y capaz de responder a los
problemas propios de las redes, tanto de nivel dos (bucles) como de nivel tres (cambios en la
topología) pero sin un consumo de recursos tan elevado propio de los protocolos de control
tradicionales. La tecnología SDN ofrece una solución a este problema. En las redes SDN existe
un único protocolo del plano de control, OpenFlow, responsable de comunicar el controlador
con los dispositivos de red y de indicarles cómo deben tratar el tráfico. De esta forma, se elimina
el exceso de trabajo en el plano de control, liberando ancho de banda y reduciendo el coste
computacional.
6
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
En una red tradicional, cada cambio en la topología supone que, gracias a los protocolos de
control, los dispositivos de red determinan automáticamente la nueva topología. Sin embargo,
durante el tiempo que tardan en determinar la nueva morfología de la red (denominado tiempo
de convergencia) se produce una pérdida de rendimiento o incluso de servicio. En la situación
actual de los CPDs se vuelve inviable el uso de estos protocolos para hacer frente a los cambios
de la red. El problema es incluso mayor, pues la escala que están adoptando los centros de
procesamiento de datos excede en tamaño al que se pensó cuando se diseñaron los actuales
protocolos de control, haciendo que la red tenga tiempos de convergencia inaceptablemente
altos. En consecuencia, se produce una situación donde las propiedades que hacen fuerte al
modelo de red distribuido no son tales. Sin embargo, sus deficiencias sí que afectan
notablemente al funcionamiento de la infraestructura.
Póngase un sencillo ejemplo donde se hace una modificación puntual de la topología de nivel
dos, añadiendo varios switches para mejorar la redundancia, y se añaden varias subredes (VLAN)
a la infraestructura para amoldarse a las necesidades de un cliente. Existe un tiempo en el que
los switches no han calculado de nuevo los árboles de Spanning Tree y los routers no tienen
rutas para llegar a las nuevas redes, ya que los protocolos de routing dinámico no han hecho
converger la red. Ahora debe imaginarse que este cambio puntual pasa a hacerse de forma
habitual. Sencillamente, una red tradicional no está preparada para esta situación.
En las redes definidas por software, el controlador es el único elemento de la red que conoce la
topología completa y es el encargado de gestionarla. En caso de que se produzca un cambio
intencionado en la infraestructura o un fallo de algún dispositivo o enlace de la red, el
controlador es consciente de ese cambio y puede reaprovisionar nuevos flujos en tiempo real
para permitir a los dispositivos de red encaminar el tráfico sin que se produzcan pérdidas de
rendimiento o caídas del servicio. Además, conviene mencionar que ya no solo se habla de la
topología de la red cuando se habla de cambios. El controlador también es responsable de tareas
más avanzadas, como las políticas de seguridad, balanceo de tráfico y la calidad de servicio entre
otras. En conjunto, las redes SDN permiten una gestión más dinámica y flexible en todos los
ámbitos de la red.
Originalmente, en los centros de datos predominaba el tráfico norte-sur, sin embargo, la llegada
de la virtualización y los sistemas distribuidos ha provocado un cambio radical en la dinámica de
los flujos de red en los CPDs. En las arquitecturas antiguas, cuando un cliente realizaba una
7
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Por otro lado, no todo el tráfico que se genera tiene que ver con peticiones de clientes. Existen
muchos procesos dentro de un CPD que, debido a su escala, es imposible ejecutarlos en un único
nodo. Un ejemplo de estos procesos es el análisis de datos en entornos MapReduce, donde se
utilizan clusters de cientos de nodos virtuales que están continuamente comunicándose entre sí
para actualizarse los unos a los otros [34]. Otro ejemplo es el minado de criptomonedas [38].
En consecuencia, actualmente se genera mucho más tráfico este-oeste que norte-sur. Las redes
definidas por software proveen otro nivel de control y administración del tráfico este-oeste que
no es posible en una red conmutada convencional. Al ser capaces de administrar
individualmente cada switch y de conocer la actividad de toda la red, pueden hacer un mejor
balanceo de tráfico que una red convencional. Además, debido a la naturaleza cambiante de un
entorno virtualizado, donde se arrancan y destruyen instancias virtuales de forma constante y
con independencia de la máquina física donde se están ejecutando, las políticas de seguridad y
de red asociadas a esas instancias virtuales también cambian constantemente. Con un
controlador SDN que gestiona de forma centralizada todas las políticas, estas pueden
modificarse a la velocidad a la que se va modificando la propia red [35].
Coste
El sector de las redes de telecomunicaciones es considerablemente caro. Los costes de compra
de los dispositivos y los costes operativos asociados a los entornos de producción son muy
elevados. Al hablar de las redes definidas por software, una de las preguntas que hay que
plantearse es qué aportan en términos económicos.
8
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
de mercado [17], crea un mercado poco competitivo, con precios estancados y poca elasticidad
a la hora de cambiar de proveedor.
Las redes definidas por software ofrecen otra perspectiva. Primero, pese a que están
empezando a surgir SDN propietarias de grandes empresas como Cisco o VMWare [18], en el
ámbito de las redes SDN predomina el software libre. Migrar a un modelo Open Source permite
unificar sistemas, ya que se elimina la barrera de los protocolos propietarios y de los problemas
de compatibilidad. Segundo, cualquier dispositivo con soporte para las tecnologías SDN se
puede integrar perfectamente en la infraestructura de la organización. Esto abre la puerta a que
fabricantes de dispositivos genéricos de red (Original Equipment Manufacturer, OEM) adquieran
más relevancia, aumentando la presión sobre las empresas tradicionales (Cisco, Hewlett-
Packard y Juniper, principalmente) [6].
Conclusiones
Por todo lo anterior, una de las áreas donde mayor penetración están alcanzando las redes
definidas por software es la de los CPDs. También es uno de los principales motivos por el que
se están impulsando. Sin embargo, cabe destacar el hecho de que, aunque las propiedades de
las redes SDN encajen con las necesidades de los CPDs, no implica necesariamente que no
tengan aplicaciones fuera de este ámbito. De hecho, se puede afirmar que cualquier red
densamente poblada o que experimente cambios regulares en su topología es un buen objetivo
de estudio a la hora de decidir si implantar una red definida por software.
Llegados a este punto, es conveniente acarar un concepto. En las redes SDN no se hace distinción
entre dispositivos de nivel dos (enlace) y nivel tres (red). Donde antes existían routers para
encaminar tráfico norte-sur y switches multinivel para encaminar tráfico este-oeste, ahora
existen únicamente switches OpenFlow. Esto no significa que no se utilice la pila TCP/IP habitual
para encapsular y enrutar tráfico, que se utiliza, pero se abre la puerta a adoptar criterios más
9
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
refinados a la hora de gestionar el tráfico de la red. Se hablará más en profundidad sobre estos
criterios en el capítulo de OpenFlow. Por ahora, es suficiente con comprender que en una red
SDN los únicos dispositivos de red que existen a parte del controlador, son los switches
OpenFlow.
Ilustración 3. En las redes SDN el plano de control queda en manos del controlador, que se comunica con los switches mediante el
protocolo OpenFlow.
Es decir, que mientras que en una red tradicional los caminos definidos para el envío de
información entre dos puntos son relativamente estáticos, en las redes SDN cada nueva
comunicación entre dos extremos diferentes supone la inclusión de un nuevo flujo en la tabla
de flujos. Pueden existir incluso varios flujos diferentes para dos mismos extremos, según el tipo
de tráfico que se esté generando. En resumen, las redes SDN ofrecen la posibilidad de hacer una
gestión mucho más especializada del tráfico que las redes convencionales.
De esta forma, cuando un switch OpenFlow recibe un paquete que no sabe encaminar, se lo
transmite al controlador para que decida qué hacer con este tráfico. Cuando el controlador
recibe este paquete, se realizan dos acciones. En primer lugar, el controlador decide qué hacer
con el tráfico que está tratando de ser enviado desde ese switch OpenFlow. En segundo lugar,
envía la información necesaria al switch para que este conozca lo que hay que hacer con el resto
de los paquetes del mismo tipo. Los criterios mediante los cuales se determina el tratamiento
de ese tráfico pueden ser variados y condicionados por diferentes factores. Podría ser que el
administrador de la red hubiera definido un flujo estático para ese tráfico, en cuyo caso el
controlador le enviaría el flujo al switch para que pueda encaminar el resto de los paquetes de
10
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
ese flujo. También podría resultar que no exista un flujo definido para ese tráfico, en cuyo caso
podrían ocurrir varias cosas. Si el controlador tiene activado algún módulo de tráfico reactivo o
está conectado a una aplicación externa que controla los flujos, en base a la topología de la red,
se determinaría un nuevo flujo óptimo para ese tráfico y se lo enviaría al switch. Si no, se
descartaría el paquete y en consecuencia todo el tráfico relacionado. También podría ocurrir
que, debido a las políticas de seguridad implementadas, se impida la comunicación. Como se
puede observar, las redes SDN ofrecen una flexibilidad sobresaliente a la hora de gestionar el
tráfico.
En esta sección se describe someramente el funcionamiento de las redes SDN para ofrecerle al
lector una idea general y sus diferencias respecto a las redes tradicionales. En secciones
posteriores se hablará en profundidad de los flujos y el protocolo que, en el momento de escribir
este trabajo, predomina a la hora de gestionarlos, OpenFlow.
Una de las propiedades que hacen más interesante el uso de las redes SDN es el hecho de que,
como su nombre indica, están definidas mediante programas. La Northbound Interface es la
interfaz responsable de comunicar el controlador con aplicaciones externas, normalmente
mediante el uso de una API. Esta API ofrece la capacidad de programar el controlador
exponiendo modelos de datos de red y otras funcionalidades para ser utilizados por las
aplicaciones externas. En la práctica, supone que se pueden crear múltiples tipos de aplicaciones
que faciliten la gestión de una red. Por ejemplo, se pueden realizar cambios en la topología sin
que la infraestructura física se vea afectada. También se pueden automatizar ciertos aspectos
de la gestión de la red, de forma que el esfuerzo de administración se ve notablemente reducido.
Otros ejemplos son la implementación de políticas de seguridad, balanceo de tráfico y
virtualización de la red.
En los controladores actuales más extendidos, existen dos formas de conectar las aplicaciones
externas a la Northbound Interface, mediante la API REST y la API OSGI. Con la API REST, las
aplicaciones externas hacen peticiones HTTP, de forma que pueden dar órdenes al controlador
y obtener a su vez información de éste. Este método es útil para crear aplicaciones
tecnológicamente independientes del controlador, sin embargo, son peores en rendimiento. Por
otro lado, las aplicaciones conectadas con el controlador como módulos mediante la API OSGI,
ofrecen un mejor rendimiento que las aplicaciones REST, pero tienen la desventaja de ser
dependientes tecnológicamente. Esto significa que, si por ejemplo OpenDaylight está
programado en Java, su API OSGI estará pensada para ser utilizada por otras aplicaciones Java
[33].
11
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
contiene los módulos básicos necesarios para su funcionamiento. Algunos de estos módulos
pueden ser la interfaz web de gestión o los módulos de conmutación de tramas.
Estado actual
Desde el nacimiento de las redes definidas por software, se han ido desarrollado un gran número
de controladores. No todos han cosechado el mismo éxito. Al ser de código abierto, los
controladores SDN dependen de la contribución voluntaria de los usuarios para seguir
incorporando mejoras e ir solucionando errores. Existen controladores que han recibido apoyo
de grandes corporaciones (como ONOS u OpenDaylight) y se han incluido en grandes
organizaciones (como la Linux Foundation) y por tanto mantienen una elevada actividad y una
documentación relativamente actualizada. Otros controladores han ido reduciendo su actividad
hasta quedar prácticamente muertos. Eso es otra cuestión en sí misma. No se puede afirmar
que estén muertos porque tampoco existe una comunidad de desarrolladores u organización
12
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
responsable que lo haya mencionado expresamente. Para hacerse una idea de su estado actual
hace falta realizar un trabajo de investigación e ir a los repositorios y ver la actividad. El
repositorio en Github del controlador POX, por ejemplo, lleva sin actualizarse desde hace cuatro
años [14]. El controlador NOX, del que hereda POX, lleva sin actualizarse seis años y no existe
apenas actividad en las redes. Frente a estos controladores, ONOS y OpenDaylight reciben
actualizaciones regulares y tienen una extensa documentación.
Otra cuestión que hay que tener en cuenta a la hora de evaluar los controladores es la de la
documentación. Al ser una tecnología muy nueva y relativamente compleja, una documentación
escasa, desactualizada o directamente inexistente es un motivo muy serio para plantearse
descartar un controlador como posible candidato. En ese sentido, una observación general de
la documentación de los diferentes controladores hace concluir que incluso los que mejor
documentados están, están mal documentados de todas formas. A veces, la información que se
consulta resulta ser de una versión anterior que ya no es válida, pero sigue figurando como si lo
fuera. Otras hay que realizar una investigación en profundidad sobre información importante
que debería ser más visible. Otras, incluso, se mantienen dos webs oficiales de documentación
diferentes, como en el caso de OpenDaylight. Se hablará más detenidamente sobre este asunto
en la sección de OpenDaylight.
En cualquier caso, la mejor fuente de información en la actualidad para conocer el estado del
arte de los controladores SDN lo ofrece SDXCentral [45]. De entre los controladores activos, se
hablará sobre aquellos que son más relevantes.
Ilustración 5. Estado de los controladores según la conferencia de SDXCentral en ONS 2016 [45].
ONOS
ONOS (Open Network Operating System) es un controlador SDN Open Source gestionado por la
Linux Foundation [21]. Entre sus principales metas está ofrecer un controlador escalable, de alto
rendimiento, con soporte para alta disponibilidad y compatible tanto con dispositivos
tradicionales como dispositivos OpenFlow. Está escrito en Java y construido sobre Apache Karaf.
Usa Apache Maven para instalar el programa y sus dependencias [22]. Actualmente es el tercer
controlador más utilizado en despliegues comerciales, por detrás de OpenDaylight y OPNFV [25].
13
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
ONOS puede ser administrado mediante su API REST, línea de comandos (CLI) y la interfaz gráfica
web. La API REST se usa fundamentalmente por aplicaciones externas y desarrolladores. La línea
de comandos está basada en la CLI de Apache Karaf y permite administrar las principales
características de la red. Por ejemplo, permite crear, borrar y modificar flujos y administrar los
dispositivos de red. Respecto a la interfaz gráfica, está pensada fundamentalmente para ofrecer
una representación gráfica de la topología de la red y su estado [30].
ONOS utiliza los intents para gestionar el tráfico. Los intents son abstracciones que representan
el deseo de conectar dos o más puntos de la red, pero sin especificar el camino concreto que se
quiere seguir. Cuando se configura un intent, el controlador calcula la mejor ruta y configura los
flujos necesarios para permitir la conexión. Cuando se produce un cambio en la topología, ONOS
busca una nueva mejor tuta y actualiza automáticamente los flujos.
14
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
El principal competidor de ONOS es OpenDaylight, que, aunque le lleva una notable ventaja en
cuanto a despliegues comerciales, algunas pruebas realizadas sugieren que ONOS ofrece unas
tasas de rendimiento superiores a OpenDaylight [24], por lo que no se puede descartar que en
el futuro ONOS le tome la delantera al actual líder.
OpenDaylight
OpenDaylight (ODL) es un controlador SDN Open Source también propiedad de la Linux
Foundation [21]. Se trata del controlador más extendido en términos de despliegues comerciales
[25]. Al igual que ONOS, está escrito en Java y se construye sobre Apache Karaf OSGI. Utiliza
Maven para instalar el controlador y sus dependencias.
En la actualidad, OpenDaylight es el controlador SDN que cuenta con mayor apoyo financiero.
Muchas de las organizaciones que apoyan ONOS también apoyan OpenDaylight con un nivel
mayor de compromiso, pero, además, cuenta con otros socios de gran relevancia. Algunos de
estos socios son Cisco, Ericsson y RedHat [29].
Para permitir la administración, OpenDaylight ofrece dos APIs. Una API OSGI (Java) para
aplicaciones en su mismo espacio de direcciones y una API REST ordinaria. La línea de comandos
sólo sirve para instalar paquetes o características y obtener información muy básica sobre el
controlador, y no sobre la red. A diferencia de ONOS, la interfaz gráfica de OpenDaylight (DLUX)
no es muy amigable. A parte de mostrar un grafo simple con la topología de la red, el módulo
OpenDaylight YANG UI permite interactuar de forma gráfica con la API REST, haciendo llamadas
a la API y ofreciendo información de las estructuras de datos que utiliza. Mediante esta interfaz
poco intuitiva se puede configurar la red u obtener información detallada de la infraestructura
[30].
15
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Para poner en marcha una red básica con OpenDaylight hace falta instalar el paquete odl-
l2switch-switch-ui desde la línea de comandos de OpenDaylight. Esta característica activa el
encaminamiento de nivel dos en la red SDN y la interfaz web. De esta forma, el controlador crea
automáticamente los flujos necesarios para encaminar el tráfico como si se tratase de una red
conmutada tradicional [31]. Nótese que en este caso no se permite encaminar tráfico de nivel
tres, por ejemplo, tráfico de dos equipos de diferentes subredes. Incluso aunque estén
conectados al mismo switch OpenFlow y el controlador conociera sus direcciones IP, no se
encaminará el tráfico. Esta funcionalidad requiere de una configuración más avanzada del
controlador. Esto demuestra en parte lo complejo que supone administrar OpenDaylight frente
a ONOS, que ofrece mayores facilidades a la hora de hacer configuraciones básicas de la red.
Sin embargo, OpenDaylight tiene otras ventajas. De forma similar a los intents de ONOS, ODL
ofrece políticas basadas en grupos (Group Based Policies). Se trata de un concepto heredado de
Cisco y que permite hacer una configuración más flexible y exhaustiva de la red que los intents
de ONOS. Sin embargo, no pueden ser configuradas a través de la línea de comandos. Es
obligatorio hacer uso de la API REST y viene bien definida en la interfaz gráfica de la API [30].
16
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Sin embargo, esto se ve compensado por una mayor actividad en las redes sociales y foros
especializados que ONOS. En última instancia, es más fácil encontrar a otros usuarios que han
encarado problemas similares si se busca ayuda para OpenDaylight que si se busca para ONOS.
No obstante, el hecho de que este trabajo sólo cubre aspectos muy básicos de la configuración
del controlador debería ser criterio suficiente para que esta característica no determine qué
controlador elegir a la hora de desplegar un laboratorio.
Ryu
Ryū (del japonés, dragón) es un controlador SDN Open Source basado en componentes. Está
desarrollado íntegramente en Python y es apoyado principalmente por los laboratorios NTT (del
grupo NTT). De todos los controladores analizados en este trabajo, Ryu es el que más enfocado
está en los desarrolladores de aplicaciones. De hecho, está definido como un framework de red
y no como un controlador en sí mismo, aunque comúnmente es denominado controlador SDN,
pues cuando se le añaden aplicaciones se convierte en un controlador. El objetivo de Ryu es que
los propios usuarios escriban las aplicaciones que necesiten en forma de scripts en Python y se
las pasen Ryu para que las ejecute. Para lograr este objetivo, Ryu ofrece una serie de
componentes con una API bien definida que permite a los desarrolladores crear aplicaciones de
control y administración de la red [32]. Es importante comprender que las aplicaciones que se
desarrollan para Ryu no son aplicaciones externas que se conectan al controlador a través de la
17
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
Northbound Interface mediante una API REST. Se trata de aplicaciones que son ejecutadas por
el propio controlador dentro de su lógica interna. Se puede establecer una analogía con el
módulo de conmutación de paquetes de OpenDaylight visto en el capítulo anterior. En
OpenDaylight, simplemente se activaría el módulo a través de su interfaz de línea de comandos
y ya se podría conmutar tráfico de nivel dos. En Ryu, es necesario escribir una aplicación en
Python indicando cómo se debe tratar el tráfico de nivel dos en los switches OpenFlow. Estas
aplicaciones pueden, a su vez, desarrollar su propia API REST para ser gestionadas remotamente.
Una propiedad interesante de Ryu es que permite utilizar otros protocolos en la Southbound
Interface que no sean OpenFlow, como Netconf o XFlow.
Actualmente, Ryu no es de los controladores SDN con más despliegues comerciales del mercado.
Esto puede deberse en parte a la carencia de módulos básicos que ya vienen incluidos en otros
controladores como ONOS y OpenDaylight.
OpenContrail
Originalmente conocida como Contrail, esta herramienta de virtualización fue comprada por
Juniper Networks y posteriormente liberada, pasando a llamarse OpenContrail. Juniper
argumentó que el motivo para hacerlo se encontraba en que los beneficios económicos de las
redes SDN no provenían del controlador, sino en los servicios asociados.
De todos los controladores SDN que se analizan en este trabajo, OpenContrail es el más
particular de todos. Como tal, no es solamente un controlador SDN. A diferencia del resto de los
controladores SDN analizados en este trabajo, OpenContrail no solo incluye el controlador SDN
responsable del plano de control, también incluye los dispositivos OpenFlow encargados del
plano de datos.
Se puede definir OpenContrail como una plataforma de virtualización de red integral para cloud.
Consta de dos componentes principales: el controlador y los vRouters. Al igual que en los otros
controladores SDN, el controlador de OpenContrail es el responsable del plano de control y la
monitorización, dejando el plano de datos en manos de los vRouters.
18
ESTUDIO Y ANÁLISIS DE LAS REDES DEFINIDAS POR SOFTWARE
A diferencia del resto de controladores SDN, que son un componente independiente de los
dispositivos del plano de datos (switches OpenFlow) en la infraestructura SDN, OpenContrail
ofrece un modelo todo en uno en el que se gestiona la red sin necesidad de salir del ecosistema
de OpenContrail. Es especialmente interesante su uso en centros de datos Multi-tenant. En este
tipo de CPDs se comparte una misma infraestructura física (servidores, redes, almacenamiento,
etc) pero existe una separación total a nivel lógico, uno por cada cliente (tenant) [16].
19
ESTUDIO Y ANÁLISIS DEL PROTOCOLO
OPENFLOW
Como se ha establecido previamente, el modelo de encaminamiento del tráfico de red en las
Redes Definidas por Software está basado en los flujos. Esto es posible gracias al protocolo
OpenFlow. La configuración más básica del protocolo permite definir, modificar y eliminar flujos
en los switches OpenFlow encargados del plano de datos [6]. Muchas grandes corporaciones
dentro del mundo de las telecomunicaciones, entre las que se incluyen IBM, Google y HP, han
dado su apoyo expreso a OpenFlow [8]. Se trata de un protocolo estandarizado por la IETF
(Internet Engineering Task Force) [10] y gestionado por la Open Networking Foundation (ONF)
[9].
1. Permite al controlador crear flujos y programar los switches para conseguir un detallado
control del tráfico.
2. Permite a los switches encaminar el tráfico gracias a la información recibida del
controlador y almacenada en sus tablas de flujos.
Nótese que hasta ahora, en las redes convencionales se ha diferenciado entre dispositivos de
nivel de red (routers) y de nivel de enlace (switches). En realidad, en las redes SDN no existe esa
diferenciación, ya que todos los dispositivos son considerados switches Openflow. En el
controlador se crearán flujos según diferentes criterios y se los comunicará a los switches
mediante mensajes OpenFlow. Estos criterios pueden ser de nivel dos (por MAC origen o
destino), de nivel tres (por IP origen o destino) e incluso criterios de nivel cuatro (transporte) y
nivel cinco (aplicación) [12]. Aunque en secciones posteriores se discutirá sobre las diferentes
opciones existentes de dispositivos, este trabajo tomará como principal referencia los switches
Open vSwitch, un switch virtual multinivel que soporta Openflow. En adelante, cuando se hable
de un switch o dispositivo de red del plano de datos (conmutación/enrutamiento), se estará
haciendo mención indirecta a un switch Openflow, y más concretamente, a un switch Open
vSwitch.
También conviene recalcar el hecho de que Openflow no sustituye a ninguno de los protocolos
de la pila TCP/IP. Cada mensaje Openflow va encapsulado en un segmento TCP y sus
correspondientes paquetes IP y trama Ethernet. Es importante entender este concepto, pues
implica que cualquier dispositivo de red puede encaminar el tráfico Openflow a su destino,
independientemente de si el dispositivo entiende Openflow o no. Openflow es un protocolo del
plano de control, no del plano de datos. Dicho de otra manera, Openflow permite al controlador
instruir a los dispositivos de red cómo deben encaminar tráfico, pero no es responsable de
encapsular y enviar ese tráfico, que sigue siendo una tarea que deben realizar los propios
switches (y en ocasiones particulares el controlador) con los protocolos habituales.
Debe mencionarse que Openflow es un protocolo que ha ido evolucionando con el tiempo y que
ha sufrido algunos cambios drásticos entre versiones. Se profundizará en algunas de estas
evoluciones a fin de comprender mejor su funcionamiento. En el momento de redactar este
trabajo, OpenFlow se encuentra en la versión 1.5, y es la que se tomará como referencia para
21
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
explicar las características principales del protocolo. Aunque, como se verá más adelante, el
hecho de que sea la versión más reciente no significa que los dispositivos utilizados trabajen con
ella. De hecho, la versión más reciente que soportan los switches que se utilizan en este trabajo
es OpenFlow 1.3. Sin embargo, es presumible que en el futuro las características de las versiones
más modernas de OpenFlow acaben por ser implementadas en la mayoría de los switches, por
lo que conviene conocerlas.
Tablas de flujos
Como ya se ha comentado previamente, los flujos se agrupan en tablas similares a las de rutas
o las de conmutación. Cuando se recibe un paquete, se analiza la tabla elemento a elemento
para comprobar si se cumplen los requisitos de matching en alguna de ellas. En la versión 1.0 de
Openflow, únicamente existía una tabla de flujos. Sin embargo, a partir de OpenFlow 1.1 se
soportan tablas anidadas. OpenFlow sigue un proceso general perfectamente definido a la hora
de recorrer las tablas de flujos en el switch. Este proceso, o pipeline, es el siguiente.
Las tablas de flujos en el switch se ordenan por números, empezando en 0. La tabla 0 debe existir
siempre, ya que debe haber al menos una tabla de flujos en el switch. El proceso empieza
siempre en esta primera tabla. Cuando entra un paquete se intenta asociar con alguna entrada
de la tabla 0. En caso de encontrar una coincidencia, se añaden las instrucciones asociadas a ese
flujo al denominado “action set” del paquete. El action set es el conjunto de acciones que se
aplican al paquete entrante una vez han acabado de recorrerse las tablas de flujos. Si entre las
instrucciones de la entrada se encuentra la de pasar a otra tabla (Intrucción go to), se avanza a
esa tabla y se repite el mismo proceso. Nótese que siempre debe avanzarse a tablas de
numeración más alta, nunca más baja. Dicho de otra forma, siempre debe avanzarse hacia
delante, y no puede volverse nunca a tablas anteriores. Cuando no quedan más tablas que
recorrer, es decir, cuando el match de una tabla no incluye la instrucción go to indicando que
debe avanzarse a otra tabla, se ejecuta el action set asociado al paquete. El action set se
ejecutará en un orden preestablecido del que se hablará más adelante.
22
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
En caso de que no exista una entrada asociada al paquete entrante en una tabla, se produce un
fallo de tabla (“table miss”). En este caso, el comportamiento dependerá de cómo esté
configurada la tabla. Se pueden añadir entradas en las tablas específicamente para indicar cómo
procesar paquetes no equiparados (unmatched packets). Las opciones son:
Nótese que el orden de las entradas de los flujos influye en su prioridad, de forma similar a las
reglas de un firewall o las listas de acceso de un router. Esto implica que podría darse el caso de
que existan dos entradas en la tabla flujos que pudieran estar asociadas a un paquete entrante,
sin embargo, al recorrerse en orden descendente la tabla, solo se ejecutarán las instrucciones
asociadas a la primera entrada que tenga coincidencia.
En OpenFlow 1.5 se modifica el pipeline. La parte vista hasta ahora pasa a denominarse Ingress
Processing (procesamiento de entrada) y se incluye el Egress Processing (procesamiento de
salida). Fundamentalmente, el Egress Processing sigue el mismo funcionamiento que el Ingress
Processing, se recorren las tablas buscando equiparaciones válidas para el paquete y se ejecutan
las instrucciones de la tabla asociadas a la entrada. Su función es permitir mayor granularidad y
organización en las entradas de las tablas de flujos. Se trata de un procesamiento opcional y por
tanto no es necesario que el switch lo implemente para poder encaminar tráfico correctamente.
23
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
1. Instrucciones que hacen avanzar el pipeline (esto es, que avanzan a otra tabla).
2. Instrucciones que modifican el action set del paquete.
3. Instrucciones que modifican el paquete entrante inmediatamente sin esperar a que se
ejecute el action set al final del pipeline (de carácter opcional).
En total, existen seis instrucciones. Dos son obligatorias y cuatro son opcionales. Esto significa
que el switch debe necesariamente tener soporte para las obligatorias. Respecto a las
opcionales, el controlador puede consultar a los switches cuáles de las instrucciones opcionales
están soportadas por cada switch. Este trabajo se centrará únicamente en las instrucciones
obligatorias, que son las siguientes:
24
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
Cada entrada en la tabla de flujos sólo puede tener una instrucción de cada tipo asociada y se
ejecutan en el orden en el que están definidas en dicha entrada. Esto, en la práctica, y aplicado
a las instrucciones obligatorias, implica que Goto-table siempre va después de Write-
actions, ya que de lo contrario se avanzaría de tabla antes de escribir las acciones en el action
set del paquete entrante.
Los action sets, por otro lado, son el conjunto de acciones que se ejecutan sobre el paquete al
acabar el pipeline. Aunque las acciones se añaden al action set a medida que se van recorriendo
las sucesivas tablas de flujos, estas no se ejecutan en orden cronológico de llegada. A
continuación, se definen las acciones en orden de prioridad de ejecución:
1. Copy TTL inwards: Copiar el campo TTL de la cabecera IP más externa del paquete
entrante a la segunda más externa con campo TTL. Esta acción se ejecuta normalmente
cuando existe una cabecera IP anidada dentro de una cabecera MPLS (que tiene TTL).
2. Pop: elimina todas las etiquetas VLAN, PBB y MPLS del paquete.
3. Push-MPLS: añade una etiqueta MPLS al paquete.
4. Push-PBB: añade una etiqueta PBB al paquete.
5. Push-VLAN: añade una etiqueta VLAN al paquete.
6. Copy TTL outwards: Copiar el campo TTL de la segunda cabecera IP más externa del
paquete entrante con campo TTL a la cabecera IP más externa.
7. Decrementar TTL de la cabecera IP.
8. Set: se usa junto a las instrucciones opcionales. En el presente trabajo no se
profundizará en su funcionamiento.
9. Qos: aplica acciones de QoS
10. Group: se usa junto a las instrucciones opcionales. En el presente trabajo no se
profundizará en su funcionamiento.
11. Output: envía el paquete por el Puerto especificado
Equiparación de paquetes
Hasta ahora, se ha hablado de cómo funciona el pipeline de OpenFlow. Se ha visto cómo se
recorren las tablas de flujos buscando una coincidencia cuando se recibe un paquete y se han
mostrado las acciones que se llevan a cabo sobre el paquete en función de en qué entradas de
las tablas de flujos equipara. Sin embargo, falta por conocer cómo se equiparan los paquetes en
OpenFlow.
El campo cabecera se usa como criterio de equiparación para determinar si un paquete entrante
se corresponde de alguna manera con esa entrada. Si existe, entonces el paquete entrante se
corresponde con ese flujo. El campo contador se utiliza para monitorizar las estadísticas relativas
al flujo. Por ejemplo, cuántos paquetes han sido conmutados o desechados con relación a ese
flujo. El campo instrucciones, como ya se ha visto en la sección anterior, indica qué debe hacer
el switch cuando recibe un paquete que se corresponde con ese flujo [6]. Los timeouts se utilizan
para descartar entradas en la tabla de flujos en las que lleva cierto tiempo sin equiparar un
paquete. Esto se hace así porque al cabo de un tiempo, podría desbordarse la memoria del
switch debido al enorme volumen de flujos almacenados en sus tablas de flujos.
25
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
En Openflow 1.0, existen varios criterios según los cuales el paquete entrante puede
corresponderse a un flujo. En esta primera versión del protocolo existía poca flexibilidad a la
hora de escoger los criterios de equiparación, ya que sólo se permitían un conjunto limitado de
parámetros. Son los siguientes [12]:
Por tanto, si quisiera crearse un flujo que gestionara, por ejemplo, todos los paquetes que sean
enviados al servidor DNS de Google (8.8.8.8), en el campo “Match fields” se usaría “Dirección IP
destino: 8.8.8.8” como criterio de equiparación. De esta forma, el switch, al recibir un paquete
cuya IP de destino sea 8.8.8.8, produciría una ocurrencia en esa entrada de la tabla y se
ejecutarían las instrucciones asociadas a la entrada que se ha creado (normalmente, enviarlo
por un puerto determinado). También podría darse el caso de que se quisiera permitir la
conexión con cualquier servidor DNS, en ese caso, se utilizaría el puerto destino (que en el caso
de DNS es el 53) para equiparar los paquetes.
Por defecto, los switches hacen uso de la clase OFPXMC_OPENFLOW_BASIC, que define una serie
de campos básicos que cubren la mayor parte de las necesidades a la hora de crear flujos. A
continuación, se muestra la especificación de la clase OFPXMC_OPENFLOW_BASIC, que es la clase
básica por defecto de OpenFlow:
/* OXM Flow match field types for OpenFlow basic class. */
enum oxm_ofb_match_fields {
OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */
OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */
OFPXMT_OFB_METADATA = 2, /* Metadata passed between tables. */
OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */
26
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
27
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
equiparase mediante criterios específicos definidos por el usuario es suficiente. Además, la clase
OFPXMC_OPENFLOW_BASIC contiene todos los criterios de equiparación que podrían necesitarse
habitualmente en una red, por lo que no es necesario hacer un análisis más profundo sobre
OXM.
Puertos OpenFlow
Los puertos OpenFLow son puertos Ethernet que pueden ser lógicos, físicos y reservados. Los
puertos físicos son aquellos que se corresponden con una interfaz física del switch. Por ejemplo,
en un switch convencional los puertos se mapean en relación uno a uno con las interfaces físicas.
En el caso de un switch OpenFLow, este podría estar virtualizado sobre el hardware de un switch
(para tener varias instancias) o el hardware de una máquina convencional. En estos casos, un
puerto físico OpenFlow podría representar sólo una porción virtual de la interfaz hardware del
switch. Para comprender este concepto mejor, conviene imaginarse un dispositivo hardware
con varios switches virtuales ejecutándose dentro. Algunos de esos switches tendrán que
compartir las interfaces físicas de la máquina donde están alojados, aunque cada uno gestione
un tipo de tráfico diferente. En este caso, los puertos físicos de los switches virtuales OpenFlow
tendrán asociados una porción de la interfaz física con la que están mapeados, y no la interfaz
entera, pues la tienen que compartir con otros switches virtuales.
Los puertos lógicos son puertos definidos por el switch que no se corresponden directamente
con una interfaz hardware. Este tipo de puertos se utilizan cuando, por ejemplo, se tiene una
instancia de un switch virtual y varios contenedores ejecutando en el mismo anfitrión. En este
caso, para conectar los contenedores al switch, puesto que es todo virtual y por tanto no hay
interfaces físicas, se crearían puertos lógicos en el switch para conectar las interfaces virtuales
de los contenedores. Aunque se hablará más delante de este tipo de situaciones, conviene
entender que el uso de puertos lógicos está muy orientado a conectar dispositivos virtuales.
Hasta ahora se ha hablado de tipos de puertos genéricos que podrían encontrarse en cualquier
switch convencional. Los puertos reservados son los más interesantes, pues son necesarios para
el funcionamiento de OpenFlow, y es de los que se hablará más en profundidad. Se trata de
puertos abstractos que especifican acciones genéricas de encaminamiento, como enviar
mensajes al controlador, inundar los puertos con un paquete o enviar el paquete sin utilizar
OpenFlow. De hecho, para comprenderlos mejor, podría considerarse que más que puertos se
trata de acciones a realizar sobre el paquete. Los puertos reservados apenas han evolucionado
desde la versión 1.0. Hubo algunos cambios en OpenFlow 1.1 y desde entonces han
permanecido invariables. Son los siguientes [36]:
• ALL
• CONTROLLER
• TABLE
• INGRESS PORT
• LOCAL
• NORMAL
• FLOOD
• ANY
ALL: representa todos los puertos que puede utilizar el switch para enviar un paquete. Se puede
utilizar únicamente como puerto de salida. En ese caso, una copia del paquete es enviado por
todos los puertos estándar.
28
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
TABLE: representa el comienzo del pipeline de OpenFlow. Este puerto solo es válido como
puerto de salida si se encuentra la acción “output” en el action set de un mensaje de tipo
PACKET_OUT (los que envía el controlador a los switches). Sirve para mandar el paquete enviado
por el controlador a la tabla 0 del switch para que pueda ser procesado por el pipeline de
OpenFlow visto anteriormente.
IN_PORT: representa el puerto por donde ha llegado el paquete. Solo puede ser utilizado como
puerto de salida, pues sirve para enviar el paquete por el puerto por donde ha llegado. Este
puerto debe ser utilizado con cuidado para evitar que se generen bucles.
ANY: se trata de un valor especial utilizado en algunas peticiones OpenFlow en las que no se
especifica el puerto.
UNSET: puerto muy específico utilizado para indicar que no se ha especificado el puerto de salida
en el action set de un paquete. No se puede utilizar como puerto de entrada ni de salida. Sirve
para para enviar los metadatos asociados al action set de un paquete por un puerto concreto.
LOCAL: representa la pila de red local del switch y la pila de administración. Se puede utilizar
como puerto de entrada o de salida. Este puerto permite a entidades remotas interactuar con
el switch a través de la red OpenFlow, en vez de usar una red de control diferente.
FLOOD: representa el envío broadcast, pero sin utilizar el pipeline OpenFlow, a diferencia de
ALL. Solo puede utilizarse como puerto de salida. Enviará el paquete por todos los puertos
estándar excepto por el que fue recibido o aquellos que estén bloqueados.
Los puertos reservados pueden ser de dos tipos, obligatorios y opcionales. Todos son
obligatorios excepto los tres últimos mencionados (LOCAL, NORMAL, FLOOD), que son
opcionales [37].
29
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
Ilustración 15. Representación de los caminos que siguen los paquetes según el puerto reservado que tienen asociado. Fuente: [6]
30
ESTUDIO Y ANÁLISIS DEL PROTOCOLO OPENFLOW
De los mensajes asíncronos el más interesante es PACKET_IN. Este mensaje se envía desde el
switch al controlador cuando no se produce una equiparación en la tabla de flujos de un paquete
entrante y dicho switch está configurado para preguntar al controlador. Encapsulado en el
mensaje PACKET_IN va el paquete que no ha podido ser encaminado por el switch y se envía a
través del puerto CONTROLLER, que ya se ha visto previamente.
Por último, como se puede observar, los mensajes simétricos sirven fundamentalmente para
que el controlador y los switches sepan que los demás siguen operativos. Esto se hace mediante
los mensajes ECHO_REQUEST y ECHO_REPLY.
31
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE
VIRTUALIZACIÓN
La virtualización es una tecnología que ha irrumpido con fuerza en el ámbito de los servicios de
computación en la nube o servicios cloud. Esto se debe a que es una tecnología que permite
mejorar la agilidad, flexibilidad y escalabilidad de los servicios ofreciendo al usuario en cada
momento exactamente los recursos que necesita, lo que permite a su vez reducir al mínimo el
tiempo de inactividad de los sistemas y reducir costes operativos. En este capítulo se hablará
sobre diferentes tecnologías de virtualización y de qué manera están relacionadas con las redes
definidas por software.
Máquinas virtuales
Una máquina virtual es un software que, al igual que un ordenador físico, ejecuta un sistema
operativo y diferentes aplicaciones. Está compuesta de un conjunto de ficheros de configuración
y especificación y está respaldada por los recursos físicos de la máquina sobre la que se ejecuta,
que se denomina anfitrión. Cada máquina virtual tiene dispositivos virtuales que proveen la
misma funcionalidad que los dispositivos físicos. Frente a las máquinas físicas tradicionales, las
máquinas virtuales ofrecen beneficios adicionales en términos de portabilidad, manejabilidad y
seguridad [40].
El fin último de las máquinas virtuales es optimizar los recursos físicos disponibles. La
virtualización permite ejecutar sobre un único recurso físico múltiples recursos virtuales [41].
Hipervisores
Un hipervisor o monitor de máquina virtual es un software o firmware que crea y ejecuta
máquinas virtuales. Puede entenderse como la capa que conecta los recursos físicos de la
máquina anfitriona con los recursos lógicos de la máquina virtual (huésped). También es el
responsable de monitorizar las diferentes instancias que se están ejecutando sobre la máquina
anfitriona. Existen dos tipos de hipervisor: el tipo uno o nativo y el tipo dos o alojado.
Tipo 1: nativo
Este tipo de hipervisor se ejecuta directamente sobre el hardware del anfitrión para controlar y
gestionar los sistemas operativos huéspedes, sin necesidad de un sistema operativo tradicional
como Windows o Unix. Por esta razón, también son llamados hipervisores de “máquina
desnuda” (del inglés, bare metal). Los primeros hipervisores, que fueron desarrollados por IBM
en la década de 1960, eran de este tipo [42]. En la actualidad, existen diferentes hipervisores de
tipo 1 comerciales, tanto propietarios como de código abierto. Algunos de los más relevantes
son Xen, Microsoft Hyper-V y VMware ESXi.
33
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
Tipo 2: alojado
Los hipervisores de tipo 2 se ejecutan sobre un sistema operativo convencional como si fueran
una aplicación ordinaria. Las máquinas virtuales se ejecutan como procesos de la máquina
anfitriona. Algunos de los hipervisores más extendidos actualmente son VMware Workstation,
Parallels y Oracle VirtualBox. Este último es la opción más popular por ser software libre.
Puesto que la máquina de pruebas ejecuta Windows, para el desarrollo de todos los laboratorios
desplegados en los capítulos posteriores se han utilizado máquinas virtuales Linux ejecutadas
sobre un hipervisor de tipo 2. Concretamente sobre Oracle VirtualBox.
NAT: Con este modo, VirtualBox configura la interfaz de red para la máquina virtual de forma
que se realiza una traducción de direcciones en el anfitrión, utilizando la IP de este último para
34
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
comunicarse con el exterior. Se utiliza para conectar la máquina virtual a Internet. Esta interfaz
es invisible para el resto de los dispositivos, incluido el anfitrión, que únicamente actúa como
router con NAT.
NAT Network: Similar a NAT, pero permite configuración adicional, como, por ejemplo,
configurar un servidor DHCP e interconectar varias máquinas virtuales. En el caso de este
trabajo, no se utilizará porque la versión más simple es suficiente, sin embargo, conviene
conocer ambos a fin de no confundirlos.
Dentro del apartado “preferencias” de VirtualBox se pueden modificar, añadir y eliminar las
diferentes redes solo-anfitrión existente:
Se puede comprobar que VirtualBox crea una interfaz de red virtual automáticamente en el
anfitrión:
Adaptador de Ethernet VirtualBox Host-Only Network:
35
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
Red interna: la red interna de VirtualBox, como su nombre indica, conecta la interfaz virtual de
la instancia deseada a una red interna a la que sólo se pueden conectar otras instancias que
tengan una interfaz de esa red interna.
En el contexto de este trabajo, se utilizarán las redes internas para interconectar las máquinas
virtuales entre sí como si se tratara de una red física cableada. Para lograrlo, se creará una red
interna para cada par de extremos que se quieran interconectar.
Contenedores Docker
Un contenedor es un software o servicio que incluye todos los elementos necesarios para
ejecutarse de forma independiente: código, entorno de ejecución, herramientas del sistema,
librerías del sistema y ficheros de configuración [43].
Los contenedores son una herramienta cada vez más importante para que los desarrolladores
puedan empaquetar e implementar sus aplicaciones. Son ligeros y proporcionan un entorno de
software consistente y portátil para poder ejecutar de forma sencilla las aplicaciones y escalarlas
en cualquier ubicación. Los contenedores se utilizan habitualmente para la creación e
implementación de microservicios, la ejecución de trabajos por lotes, en aplicaciones de
aprendizaje automático y el traslado de aplicaciones existentes a la nube.
Lo que les confiere a los contenedores su ligereza es que, frente a una máquina virtual que
ejecuta un sistema operativo completo, los contenedores sólo reúnen las librerías y
dependencias necesarias para hacer que funcionen sus servicios. Se pueden ejecutar múltiples
contenedores sobre un mismo anfitrión, ya que comparten el kernel del sistema operativo sobre
el que se ejecutan. Cada uno de estos contenedores es un proceso independiente del sistema
operativo.
En el contexto de este trabajo se utilizarán contenedores para emular equipos finales y servicios
de red a fin de conseguir una red virtualizada real. En las últimas secciones, también se utilizará
36
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
Docker para desplegar el controlador, ya que resulta más eficiente y portable mantenerlo dentro
de un contenedor que como un proceso en el sistema operativo.
En este punto del trabajo, es importante entender los diferentes niveles de abstracción con los
que se va a trabajar. Por un lado, está la máquina anfitriona, donde se ejecutará el hipervisor
(VirtualBox) con una o varias máquinas virtuales, según qué escenario se esté probando. Por
otro lado, dentro de cada máquina virtual pueden ejecutarse múltiples contenedores Docker.
En el capítulo anterior se habló sobre la conectividad de las máquinas virtuales mediante los
diferentes tipos de interfaz de red que ofrece VirtualBox. Ahora falta por comprender cómo se
conectan los contenedores Docker a los switches OpenFlow que se van a ejecutar en esas
máquinas virtuales. Para ello, primero hay que entender qué opciones ofrece Docker para
gestionar la red.
Cuando se instala Docker, si se comprueban las interfaces de red, puede verse que aparece una
nueva llamada “docker0”:
$ ifconfig docker0
docker0 Link encap:Ethernet direcciónHW 02:42:95:a9:e2:58
Direc. inet:172.17.0.1 Difus.:0.0.0.0 Másc:255.255.0.0
Dirección inet6: fe80::42:95ff:fea9:e258/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1
Paquetes RX:355169 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:420983 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:0
Bytes RX:56076015 (56.0 MB) TX bytes:2543616006 (2.5 GB)
Esto se debe a que Docker, cuando se instala, crea un puente Linux al que conecta por defecto
todos los contenedores que se crean. Este puente se comporta como switch multinivel
tradicional en el que se realiza una traducción de direcciones NAT entre la red virtual de Docker
(por defecto 172.17.0.0/16) y la red a la que está conectado su anfitrión.
37
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
De esta forma, los contenedores se pueden conectar a Internet, pero no están expuestos. Esto
se debe a que la IP a la que se encamina tráfico externo es la de su anfitrión. Para entenderse
mejor este concepto, puede imaginarse una red privada con un router perimetral que hace NAT
con Internet. Los dispositivos de la red interna pueden acceder a Internet gracias a la IP pública
del router, pero Internet no es capaz de ver los dispositivos de dentro de la red, sólo el router.
En este caso ocurre algo similar, la red privada es la red de Docker y la IP pública es la que tiene
asignada la interfaz del anfitrión (que, en la mayoría de los casos, es una dirección de una red
privada, por lo que se hace NAT dos veces, una para traducir entre la red Docker y la red privada
en el anfitrión, y otra en el propio router perimetral de dicha red privada a una dirección pública
de Internet).
38
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
Es decir, conectar el puente Linux de docker0 a una instancia de OVS y esta, a su vez, al
controlador. Esta aproximación es funcional pero no ideal. En realidad, lo ideal es eliminar el
puente Linux de docker0. En el capítulo de desarrollo se explicará cómo se consigue este
objetivo. Por ahora, es suficiente entender cómo gestiona Docker la red.
Dockerfile
Cuando Docker ejecuta un contenedor, lo que ejecuta es una imagen. Esta imagen está
normalmente construida ejecutando instrucciones Docker, que añaden capas encima a una
imagen existente o una distribución de sistema operativo que se utiliza como base. Una
distribución de sistema operativo es la imagen inicial y cada nueva instrucción genera una nueva
imagen. Esto implica que un número elevado de instrucciones generará una imagen Docker con
muchas capas. Pueden entenderse las imágenes Docker como una cebolla con una distribución
de sistema operativo en el centro. Cada capa de esta cebolla es una instrucción Docker [39].
Una de las ventajas que ofrece el utilizar Docker es que se pueden desplegar contenedores con
cualquier imagen que se encuentre disponible online a través de Docker Hub. Por ejemplo, si se
quisieran buscar las imágenes basadas en CentOS disponibles en Docker Hub:
$ docker search centos
NAME DESCRIPTION STARS
OFFICIAL AUTOMATED
centos The official build of CentOS. 4257
[OK]
ansible/centos7-ansible Ansible on Centos7 109
[OK]
jdeathe/centos-ssh CentOS-6 6.9 x86_64 / CentOS-7 7.4.1708 x8... 94
[OK]
consol/centos-xfce-vnc Centos container with "headless" VNC sessi... 52
[OK]
Para que los usuarios puedan construir sus aplicaciones y generar sus propias imágenes a partir
de las que ya existen, Docker ofrece el fichero “Dockerfile”. En este fichero de configuración
39
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
similar a un script Bash se programan una serie de acciones que se quieren realizar sobre una
imagen preexistente, como instalar paquetes y definir variables de entorno. A continuación, se
muestra un fichero Dockerfile que será utilizado en capítulos posteriores de este trabajo:
# Se usa Ubuntu como imagen base
FROM ubuntu:latest
# Instalacion de paquetes
RUN \
apt-get update && \
apt-get install -y net-tools \
iputils-ping \
isc-dhcp-server \
nmap \
traceroute
La instrucción “FROM” se utiliza para definir la imagen que se toma como base para construir la
nueva imagen. En este caso, se utiliza Ubuntu en su versión más reciente. La instrucción “RUN”
se utiliza para ejecutar comandos como se haría sobre un Shell normal. En este caso, se utiliza
para indicarle a Docker los paquetes que se quieren instalar. Nótese que es decisión del
administrador hasta qué punto le interesa utilizar una instrucción RUN para cada acción que se
desee realizar (con el correspondiente aumento de capas), o bien ejecutar muchas acciones
dentro de un mismo RUN.
Otras dos instrucciones relevantes para este trabajo que no aparecen en ese fichero Dockerfile
son “ENV” y “EXPOSE”. La primera sirve para definir variables de entorno. La segunda sirve para
exponer puertos y brindarle al contenedor visibilidad desde fuera del anfitrión.
Para construir la nueva imagen, debe lanzarse este comando desde el directorio donde se
encuentre el Dockerfile:
$ docker build -t "prueba:dockerfile" .
Open vSwitch
Open vSwitch (OVS) es un switch multinivel virtual desarrollado para ser utilizado en entornos
de producción. Se trata de un software de código abierto bajo licencia Apache 2.0. Está diseñado
para permitir la automatización de la red a una escala masiva a través de su capacidad de ser
programado a la vez que mantiene soporte para protocolos de red y gestión tradicionales.
Los switches por software como OVS fueron desarrollados con la idea de conseguir conectividad
de nivel dos entre las diferentes instancias virtuales que se ejecutan sobre un servidor físico,
dándoles acceso a la interfaz de red física del anfitrión y permitiendo la segmentación en VLANs.
Por tanto, se puede afirmar el objetivo fundamental de OVS es permitir el encaminamiento del
tráfico entre máquinas virtuales (y, más recientemente, contenedores) y el mundo exterior (es
decir, todo aquello que está fuera de su anfitrión). En hipervisores tradicionales basados en
Linux, esto implicaba la utilización de puentes Linux (switches virtuales de nivel 2) similares a los
vistos en la sección anterior. Sin embargo, en las infraestructuras modernas la virtualización se
40
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
produce en varios nodos físicos a la vez (clúster) formando una única entidad lógica. Este tipo
de entornos están caracterizados por unos equipos finales muy dinámicos, que provocan
cambios regulares en la red. OVS permite mantener la red actualizada a ritmo al que se producen
estos cambios [44].
Como ya se ha mencionado anteriormente, Open vSwitch soporta OpenFlow para crear una red
definida por software. Sin embargo, OVS no implementa actualmente todas las funcionalidades
que ofrece el protocolo OpenFlow. A continuación, se detalla una tabla con las distintas
versiones de Open vSwitch y qué versiones de OpenFlow soporta cada una:
Ilustración 20. Tabla con las versiones de Open vSwitch y las versiones de OpenFlow que soporta cada una.
Las casillas marcadas con (*) indican que la versión de OpenFlow está soportada pero no
implementa todas las funcionalidades. Por defecto viene desactivado. Las casillas con (%)
indican que la versión de OpenFlow está en estado experimental y no se recomienda su uso.
Por defecto, las instancias de OVS funcionan con OpenFlow 1.3, y es la que se utilizará para el
despliegue de los laboratorios posteriores. El primer paso para utilizar OVS, es instalarlo. Viene
incluido por defecto en los repositorios de Ubuntu:
$ sudo apt install openvswitch-switch
En este momento, el switch OVS pasa a depender del controlador y se convierte en un switch
OpenFlow plenamente funcional.
Este comando le indica al switch que la conexión con el controlador se fije en modo “out of
band”. Se utiliza cuando el switch y el controlador están ubicados en el mismo anfitrión:
41
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
Con este comando se puede comprobar el estado de la conexión entre el switch y el controlador:
$ ovs-vsctl list controller
_uuid : ba7b7ec4-3dec-4e43-a2af-1ff7d750374f
connection_mode : []
controller_burst_limit: []
controller_rate_limit: []
enable_async_messages: []
external_ids : {}
inactivity_probe : []
is_connected : false
local_gateway : []
local_ip : []
local_netmask : []
max_backoff : []
other_config : {}
role : other
status : {last_error="Connection refused", sec_since_connect="18568",
sec_since_disconnect="16911", state=BACKOFF}
target : "tcp:172.17.0.3:6633"
OVS incluye un programa que conecta los contenedores Docker a puertos del switch. Por
ejemplo, el siguiente comando:
$ ovs-docker add-port ovs-br1 eth10 contenedor --ipaddress=192.168.0.3/24
En este caso, lo que ocurre es que se crea una interfaz de red en el contenedor “contenedor”
llamada “eth10”, se le asigna la dirección IP 192.168.0.3/24 y se conecta dicha interfaz a un
puerto del switch. Las conexiones se realizan mediante pares “veth” de igual forma que se
conectarían manualmente dos interfaces virtuales.
42
ESTUDIO Y ANÁLISIS DE TECNOLOGÍAS DE VIRTUALIZACIÓN
ovs_version: "2.5.4"
En el caso concreto de este ejemplo, sólo existe un switch levantado, llamado “ovs-br1” y que
tiene cuatro puertos conectados a diferentes contenedores de Docker.
En un entorno normal, no debería ser necesario, a priori, tener más de un switch OVS ejecutando
en la misma máquina. Sin embargo, puesto que el objetivo de este trabajo es desplegar
laboratorios, se da el caso de querer emular una red real y conectar diferentes switches entre sí
para crear la topología. Para tal fin, se hace uso de lo que OVS denomina "patch ports".
43
DESARROLLO
En la actualidad, existen opciones muy limitadas para aquellos que desean desplegar
laboratorios completos de SDN. La documentación está muy dispersada y no existen escenarios
complejos que sirvan de referencia. Esto provoca que cualquiera que desee realizar pruebas
basadas en SDN para aprender o experimentar tienen poca información de cómo proceder. La
mayoría de las opciones pasan por utilizar el emulador Mininet (muy incompleto) o desplegar
una herramienta de orquestación cloud como OpenStack Neutron (demasiado complejo de
utilizar para probar funcionalidades de red). Una parte del objetivo de este trabajo es realizar
un análisis de las tecnologías de virtualización existentes actualmente que sirvan para desplegar
una red SDN virtual en un ordenador personal y determinar la óptima. Se empleará Mininet
como punto de entrada a los escenarios y se avanzará hacia soluciones mejores y más realistas.
Para todas las pruebas realizadas se ha utilizado un equipo con Windows 10 como sistema
operativo nativo. Tanto para las pruebas con Mininet como las realizadas con varias máquinas
virtuales o contenedores se ha utilizado una imagen de Ubuntu Server 16.04 y VirtualBox como
hipervisor. Esto se ha hecho de esta manera para asegurar la independencia del sistema
operativo nativo del usuario. La configuración de red de las máquinas virtuales se definirá en
cada uno de los apartados de este capítulo atendiendo a las necesidades de cada despliegue.
Conviene destacar que, si bien no es obligatorio el uso de Ubuntu como sistema operativo, sí
conviene utilizar una distribución basada en Debian. Esto se debe a que algunas características
propias de la distribución, como los daemons de administración, el gestor de paquetes o el
sistema de directorios podrían variar entre distribuciones. Queda bajo responsabilidad del lector
adaptar las directrices dadas a continuación a las equivalentes de otras distribuciones.
Conviene resaltar también que, en caso de que la máquina de pruebas ejecute Linux de forma
nativa, algunos ejemplos explicados podrían desplegarse directamente sobre la máquina
anfitriona en vez de usar una máquina virtual. En este caso, podrían saltarse algunos pasos
descritos en esta guía. Sin embargo, puesto que es el formato elegido para todos los despliegues,
se asumirá que todas las pruebas se ejecutan sobre máquinas virtuales.
Instalación de controladores
El primer paso para desplegar una red SDN es la instalación del controlador. En este trabajo se
ofrecerá una guía paso a paso para los dos controladores más relevantes actualmente:
OpenDaylight y ONOS. Esta guía está pensada para desplegar los controladores SDN como
procesos de la máquina. Dicha forma de instalación será vigente para los tres escenarios
probados, sin embargo, para la automatización del despliegue, se ejecutará el controlador
dentro de un contenedor Docker. Esta última forma de desplegar el controlador es la más
cómoda y eficiente, sin embargo, a fin de mejorar la comprensión del proceso, se reservará para
el final.
OpenDaylight
El primer paso para la instalación de OpenDaylight es instalar Java 8 de Oracle. No es válido
ningún otro entorno de ejecución de Java, como openjdk, por lo que, si viniera instalada en la
distribución que se esté usando, debe ser desinstalada primero.
45
DESARROLLO
Una vez se ha instalado Java, debe instalarse el propio controlador. Para ello, debe acudirse a la
web de descargas de OpenDaylight (https://www.opendaylight.org/technical-
community/getting-started-for-developers/downloads-and-documentation) y copiar el enlace
de descarga de la versión deseada. Para este laboratorio, se ha utilizado la versión más reciente
publicada en el momento de redactar este documento (OpenDaylight Oxygen). Una vez se
obtiene el enlace, se realiza la descarga:
46
DESARROLLO
$ sudo wget
https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendayl
ight/integration/karaf/0.8.1/karaf-0.8.1.tar.gz
Y se descomprime el fichero:
$ tar -zxvf karaf-0.8.1.tar.gz
Una vez que se ha arrancado OpenDaylight, se puede ver la lista de módulos instalados en el
controlador:
opendaylight-user@root>feature:list -i
────────────────────────────────────────────────┼──────────────────┼──────────┼─────────┼─────────────────────
────────────────────────────┼──────────────────────────────────────────────────
47
DESARROLLO
Para los despliegues de los laboratorios realizados en este trabajo, únicamente será necesario
instalar el módulo “odl-l2switch-switch-ui”. Este módulo incluye la creación dinámica de flujos
para la conmutación de paquetes de nivel dos y la interfaz web de OpenDaylight.
opendaylight-user@root>feature:install odl-l2switch-switch-ui
Una vez hecho esto, desde el anfitrión se puede abrir un navegador e introducir la siguiente URL:
http://<dirección IP de la VM>:8181/index.html
Nótese que la dirección IP se corresponde a aquella que tenga la máquina virtual en la interfaz
de red configurada como “adaptador solo-anfitrión”. Si no se tiene claro este concepto, en
secciones posteriores se explica cómo configurar las interfaces de red de la máquina virtual.
http://10.10.0.10:8181/index.html
48
DESARROLLO
Al autenticarse, lo único que debería verse es la pestaña “topology” con un recuadro en blanco.
Aquí se verá representada la topología a medida que se vayan agregando dispositivos a la red
SDN:
Se recuerda que dicho módulo se utiliza para hacer llamadas a la API REST del controlador desde
la interfaz web de OpenDaylight. Aunque en este trabajo no se va a utilizar, cualquiera que
pretenda experimentar con la Northbound Interface de ODL encontrará interesante este
módulo. Una vez instalado, al actualizar la web de OpenDaylight se verán el resto de las
funcionalidades:
49
DESARROLLO
Debido a que se trata de un entorno aún en desarrollo, a veces la instalación de los paquetes
falla o directamente se produce algún fallo general que obliga a restablecer el controlador. En
este caso, se puede volver a ejecutar añadiendo la opción “clean”:
$ ./karaf clean
Apache Karaf starting up. Press Enter to open the shell now...
100% [========================================================================]
opendaylight-user@root>
En este caso, se tendrá el controlador “de fábrica”, lo que significa que habrá que volver a
instalarle todos los módulos que se desee utilizar.
ONOS
El otro controlador SDN que se testeará en este trabajo es ONOS (Open Network Operating
System). El primer paso para la instalación de ONOS, al igual que con OpenDaylight, es instalar
Java 8 de Oracle. No es válida ninguna otra versión de Java, como openjdk, por lo que, si viniera
instalada en la distribución que se esté usando, debe ser desinstalada primero.
Una vez se ha instalado y configurado Java, se procede a descargar ONOS de la web del
controlador:
$ sudo wget -c http://downloads.onosproject.org/release/onos-$ONOS_VERSION.tar.gz
NOTA: se debe sustituir “$ONOS_VERSION” por la versión que se desea descargar, en el caso de
este despliegue, se ha descargado ONOS 1.12.0.
$ ls
onos-1.12.0.tar.gz
50
DESARROLLO
Una vez descargado, debe moverse a la carpeta /opt del sistema operativo y descomprimirse
allí:
$ sudo mv onos-1.12.0.tar.gz /opt
$ sudo tar -zxvf onos-1.12.0
NOTA: Si no se ejecuta ONOS en modo superusuario, existen problemas con los sockets
necesarios para que se comunique el controlador con los switches, por lo que es imperativo
ejecutar el controlador como root.
51
DESARROLLO
Documentation: wiki.onosproject.org
Tutorials: tutorials.onosproject.org
Mailing lists: lists.onosproject.org
onos>
Al igual que con OpenDaylight, es necesario activar módulos antes de poner en marcha la red
SDN. En el caso de ONOS, se activarán dos módulos. Uno para el forwarding reactivo y otro para
permitir la comunicación con los switches OpenFlow:
onos> app activate org.onosproject.openflow
Activated org.onosproject.openflow
onos> app activate org.onosproject.fwd
Activated org.onosproject.fwd
Para acceder a la interfaz web desde el anfitrión, basta con poner en un navegador la siguiente
URL:
http://<IP de la VM>:8181/onos/ui
http://10.10.0.10:8181/onos/ui
52
DESARROLLO
Al autenticarse, lo primero que se observa es que ONOS indica que no hay dispositivos
conectados al controlador:
En ONOS no existe una opción similar a OpenDaylight para borrar los datos del controlador y
ejecutarlo “limpio”. Para poder hacer esto, es necesario borrar el contenido del directorio
“/onos/apache-karaf/data”.
53
DESARROLLO
Escenarios probados
Uno de los objetivos de este trabajo es analizar diferentes escenarios en los que se desplieguen
redes SDN. Se han ido probado cada vez opciones más complejas en base a los resultados
obtenidos de las pruebas anteriores. En total se han probado tres escenarios:
Al final del trabajo, se pretende determinar cuál de ellos es el mejor de cara a desplegar un
laboratorio para probar en el futuro funcionalidades avanzadas de las redes SDN.
Mininet
El primer escenario elegido para probar la tecnología SDN ha sido simular la red con Mininet.
Mininet es un programa para Unix que permite simular topologías de red mediante la creación
de hosts simulados e instancias de switches Open vSwitch. Es importante aclarar que Mininet
no es una herramienta de virtualización. Para dar una imagen de una red real, Mininet utiliza
procesos Unix ligeros que simulan ser equipos finales, pero no son máquinas virtuales ni
contenedores. Es una herramienta útil que permite iniciarse en las Redes Definidas por Software
y probar funcionalidades básicas. Sin embargo, en ningún caso una red emulada con Mininet
tendrá las capacidades avanzadas que se obtienen al utilizar máquinas virtuales completas o
contenedores.
Despliegue
El despliegue de este primer escenario sólo requiere de una máquina virtual, ya que la
simulación completa, incluyendo los switches OVS y el controlador SDN, se arrancan sobre la
misma máquina. Como se ya se mencionó previamente, en caso de no querer utilizar una
instancia virtual, se puede realizar el despliegue directamente sobre el anfitrión en caso de que
sea Linux. En este caso, no será necesario seguir las indicaciones relativas a VirtualBox.
54
DESARROLLO
55
DESARROLLO
Si se vuelven a comprobar las interfaces, “enp0s8” tendrá asignada una dirección IP:
sayans@ubuntu:~$ ifconfig
enp0s3 Link encap:Ethernet direcciónHW 08:00:27:fb:e6:67
Direc. inet:10.0.2.15 Difus.:10.0.2.255 Másc:255.255.255.0
Dirección inet6: fe80::a00:27ff:fefb:e667/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1
Paquetes RX:622989 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:188962 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:633907468 (633.9 MB) TX bytes:11360702 (11.3 MB)
NOTA: La dirección asignada puede variar en función de cómo esté configurada la red solo-
anfitrión en VirtualBox.
56
DESARROLLO
Una vez están correctamente configuradas las interfaces de red de la máquina, el siguiente paso
es instalar Open vSwitch:
$ sudo apt install openvswitch-switch
Para ejecutar Mininet con la topología por defecto (consistente en un switch con dos equipos
conectados), basta con ejecutar el siguiente comando:
$ sudo mn
*** No default OpenFlow controller found for default switch!
*** Falling back to OVS Bridge
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
Como se puede apreciar, se inicializan los elementos de la mencionada topología: dos equipos
finales (h1 y h2) y un switch OSV (s1).
En el entorno de Mininet se pueden realizar múltiples acciones. Por ejemplo, se puede hacer
ping entre diferentes equipos:
mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.016 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.023 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.024 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.024 ms
^C
--- 10.0.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.016/0.021/0.024/0.006 ms
57
DESARROLLO
mininet>
El comando “links” sirve para ver los enlaces entre los dispositivos de la topología:
mininet> links
h1-eth0<->s1-eth1 (OK OK)
h2-eth0<->s1-eth2 (OK OK)
mininet>
También se pueden abrir terminales de los equipos simulados mediante el sistema de ventanas
X. Sin embargo, para hacer esto, es necesario instalar un servidor xterm en la máquina virtual y
un cliente en el caso del anfitrión (para Windows, se puede utilizar Xming) y conectarse a la
máquina virtual mediante un cliente SSH desde el anfitrión.
Mininet permite crear topologías personalizadas mediante sencillos scripts de Python. Sólo hace
falta definir los equipos y los switches y conectarlos entre sí mediante links. Se pueden enlazar
equipos con switches y switches con otro switches. A continuación, se detalla el script necesario
para emular la topología por defecto de Mininet:
from mininet.topo import Topo
# Add links
self.addLink( leftHost, leftSwitch )
self.addLink( leftSwitch, rightSwitch )
self.addLink( rightSwitch, rightHost )
58
DESARROLLO
Hasta ahora, cada vez que se ha arrancado Mininet no se ha especificado un controlador, por lo
que el propio simulador ha creado uno. Por lo tanto, para poder conectar a Mininet un
controlador SDN, primero hay que instalar una de las opciones anteriormente mencionadas.
Para definir un controlado externo, debe usarse la opción “- -controller=remote”. Nótese que
antes de arrancar Mininet, debe estar ejecutándose el controlador SDN.
$ sudo mn --custom topo.py --topo mytopo --controller=remote,ip=127.0.0.1,port=6633
En IP se pone la dirección de la máquina donde se está ejecutando el controlador (en este caso,
localhost) y el puerto de OpenFlow (por defecto, el 6633).
59
DESARROLLO
Nótese que el controlador aún no ven los equipos finales conectados a los switches. Esto se debe
a que no han generado tráfico todavía. Para generar tráfico desde todos los equipos simulados
hacia el resto de los equipos simulados en Mininet, bastará con utilizar el comando “pingall”:
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2
h2 -> h1
*** Results: 0% dropped (2/2 received)
mininet>
Sin usar topologías personalizadas, Mininet permite dos tipos de topología generales: “single”
en el que se conectan todos los equipos finales indicados al mismo switch y “linear” que se
conecta un equipo final a cada switch. Por ejemplo, si se ejecuta Mininet de la siguiente forma:
$ sudo mn --topo=linear,4 --controller=remote,ip=127.0.0.1,port=6633
60
DESARROLLO
Ventajas de Mininet
Mininet es una herramienta ideal para usuarios primerizos que no tienen acceso a entornos de
laboratorio más avanzados. Permite crear redes conmutadas simuladas para entender el
funcionamiento básico de los controladores y los flujos. Además, los switches Open vSwitch son
instancias reales igual que las que se usarían en una red virtualizada normal.
Desventajas de Mininet
Sin embargo, los defectos de Mininet no tardan en salir a relucir. Puesto que se trata de una red
simulada con equipos simulados, está mucho más limitada a la hora de poner a prueba las
virtudes y los defectos de las redes SDN. No es posible obtener un nivel suficiente de realismo
para hacer pruebas más específicas propias de un entorno real. Como ya se mencionó al
principio de este apartado, se trata de procesos del sistema operativo, y por tanto no se pueden
instalar clientes y generar tráfico como el que se produciría en una infraestructura real.
Máquinas Virtuales
Como ya se ha visto, Mininet es una alternativa rápida y sencilla para emular una red. Sin
embargo, se trata de una herramienta muy limitada que no permite crear una red virtual similar
a una red real. Para ello, se hace necesario el uso de herramientas más avanzadas para emular
los equipos finales y los servicios de la red. Por ello, el siguiente paso lógico de la iteración es el
uso de máquinas virtuales para desplegar la red SDN.
61
DESARROLLO
Como se puede apreciar, se tienen varios equipos finales, un switch y un controlador. Para cada
uno de estos componentes se utilizará una instancia de máquina virtual diferente. Al igual que
se hizo con el laboratorio de Mininet, se utilizará Ubuntu Server 16.04 LTS para todas las
instancias virtuales. En total, se utilizarán 4 máquinas virtuales (host 1, host 2, switch, controller).
Parte del objetivo de este laboratorio es interconectar las diferentes instancias de forma que
emulen una red cableada. Para lograr este objetivo, VirtualBox ofrece las redes de tipo “red
interna”. A cada par de extremos de la conexión se les asignará la misma red interna, de forma
que, en total, existirán tres redes distintas (host 1 – switch, host 2 – switch, switch –
controlador). Adicionalmente, a las instancias que hacen de switch y de controlador se les
habilitará una interfaz en modo “NAT” para permitir la conexión a internet.
62
DESARROLLO
63
DESARROLLO
NOTA: No olvidar que tanto el switch como el controlador deben tener una interfaz adicional en
modo “NAT”. Además, el controlador deberá tener una tercera interfaz en modo “adaptador
solo-anfitrión” para poder acceder desde un navegador del anfitrión a la web de administración
del controlador.
64
DESARROLLO
Y se comprueba la conectividad:
$ ping 192.168.11.2
PING 192.168.11.2 (192.168.11.2) 56(84) bytes of data.
64 bytes from 192.168.11.2: icmp_seq=1 ttl=56 time=3.29 ms
64 bytes from 192.168.11.2: icmp_seq=2 ttl=56 time=3.17 ms
64 bytes from 192.168.11.2: icmp_seq=3 ttl=56 time=3.72 ms
64 bytes from 192.168.11.2: icmp_seq=4 ttl=56 time=3.25 ms
^C
--- 192.168.11.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 3.170/3.360/3.722/0.217 ms
Las otras dos interfaces del switch que se conectan a los equipos finales no deben tener
dirección IP. Esto se debe a que se está tratando de emular el funcionamiento de un switch en
estas interfaces, y por tanto no requieren ninguna configuración de nivel tres. Bastará con
levantar dichas interfaces. Por tanto, se ejecutan los siguientes comandos en la máquina virtual
del switch:
$ sudo ifconfig enp0s3 up
$ sudo ifconfig enp0s8 up
En este momento, ya se puede configurar la instancia de Open vSwitch que se comunicará con
el controlador y encaminará el tráfico de ambos equipos finales. Para ello primero debe
instalarse Open vSwitch en la máquina virtual que hace de switch:
$ sudo apt install openvswitch-switch
Es importante notar la diferencia entre la máquina virtual denominada “switch” y las instancias
de OVS que se ejecutan en su interior.
NOTA: Si hubiera algún problema para conectarse a Internet, se debe revisar la interfaz del
switch que está configurada en modo “NAT”. A veces, no recibe una dirección IP del servidor
DHCP de VirtualBox. Para arreglarlo, basta con ejecutar el comando “dhclient” sobre la interfaz
afectada.
A continuación, se crea un nuevo switch OVS en la máquina virtual que hace de switch:
$ ovs-vsctl add-br ovs-br1
Y se conecta al controlador:
$ ovs-vsctl set-controller ovs-br1 tcp:192.168.11.1:6633
Si se abre la web de administración del controlador, se verá que aparece el nuevo switch
OpenFlow conectado. También se puede comprobar si el switch se ha conectado correctamente
con el siguiente comando:
$ sudo ovs-vsctl show
69ac3181-c5ea-49cf-af7a-374f7791b4ea
Bridge "ovs-br1"
Controller "tcp:192.168.11.1:6633"
is_connected: true
65
DESARROLLO
Port "ovs-br1"
Interface "ovs-br1"
type: internal
ovs_version: "2.5.4"
Por último, deben añadirse las interfaces de red de la máquina virtual que van a conectarse con
las otras máquinas virtuales que actúan como equipos finales a la instancia de Open vSwitch que
se ha creado:
$ ovs-vsctl add-port ovs-br1 enp0s3
$ ovs-vsctl add-port ovs-br1 enp0s8
Es importante entender este paso. Lo que se acaba de hacer es asociar las interfaces “físicas” de
la máquina virtual (enp0s3 y enp0s4) denominada “switch” con la instancia de OVS “ovs-br1”.
Esto permitirá que todo el tráfico que llegue por dichas interfaces de “switch” (es decir, el tráfico
proveniente de los equipos finales) sea conmutado por la instancia de OVS “ovs-br1” que se
ejecuta en su interior.
El último paso es asignarles direcciones IP a las interfaces de los equipos finales. Estas
direcciones deben pertenecer al mismo segmento de red.
Equipo1:
$ ifconfig enp0s3 192.168.10.1/24
Equipo2:
$ ifconfig enp0s3 192.168.10.2/24
66
DESARROLLO
$ ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=56 time=3.29 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=56 time=3.17 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=56 time=3.72 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=56 time=3.25 ms
^C
--- 192.168.10.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 3.170/3.360/3.722/0.217 ms
Aplicando los pasos descritos en este laboratorio se podría ampliar la red hasta obtener una red
virtualizada real con un tamaño y morfología adecuada a las necesidades del usuario. Se podrían
conectar otras instancias con switches OpenFlow entre sí y a estas, a su vez, otros equipos
67
DESARROLLO
finales. Incluso, se puede utilizar la máquina virtual designada como “switch” para ejecutar todas
las instancias de Open vSwitch, ya que cada instancia es independiente de las demás. Esto último
se explicará en secciones posteriores cómo se consigue.
Docker
El objetivo de este laboratorio es crear un entorno de pruebas SDN óptimo en términos de
consumo de recursos y escalable para amoldarse a las necesidades del usuario. Para ello, y en
base a los otros laboratorios desplegados, se ha determinado que lo óptimo es hacer un
despliegue “todo en uno” donde, tanto los equipos finales, los switches OpenFlow y el
controlador SDN estén alojados en una misma instancia virtual. En este primer laboratorio, sólo
los equipos finales serán imágenes de Docker. Sin embargo, el objetivo es que el controlador
también esté “dockerizado”. Esto último se completará en capítulos posteriores. Por ahora, será
un proceso más del sistema operativo.
El primer paso es instalar un controlador SDN tal y como se ha visto en capítulos anteriores. Para
este despliegue se ha elegido ONOS. Una vez instalado, se arranca el controlador:
$ ./onos-service start
68
DESARROLLO
Ahora se crearán un par de contenedores Docker que corresponderán a los equipos finales:
$ docker run -i -d --name=container1 --net=none centos:7
Unable to find image 'centos:7' locally
7: Pulling from library/centos
469cfcc7a4b3: Pull complete
Digest: sha256:989b936d56b1ace20ddf855a301741e52abca38286382cba7f44443210e96d16
Status: Downloaded newer image for centos:7
6fff0d9367d6a061c2b2249e74991138e51b80fd1758f26cbd4833fc3f5e3f5a
$ docker run -i -d --name=contenedor2 --net=none centos:7
3f728107c140547b4cd1bcc8b31b1b7b2d6a96b3836b58681e65c6acbd590b18
69
DESARROLLO
Como se puede comprobar, se han creado con la opción “- -net=none”. Esto implica que los
contenedores no tienen ninguna interfaz de red. Esto se hace porque será el programa “ovs-
docker” quien creará las interfaces que se conectarán al switch:
$ ovs-docker add-port ovs-br1 eth0 contenedor1 --ipaddress=192.168.0.1/24
$ ovs-docker add-port ovs-br1 eth0 contenedor2 --ipaddress=192.168.0.2/24
NOTA: Para simplificar los despliegues, tanto las máquinas virtuales como los contenedores han
recibido su dirección IP de forma estática. Sin embargo, en teoría es posible no hacerlo
manualmente y configurar un servidor DHCP que las asigne dinámicamente. En ese caso,
bastaría con no añadir la opción “--ipaddress” del comando “ovs-docker” y configurar un
servidor DHCP en la red. Puesto que los switches funcionan como un switch estándar de nivel 2,
el tráfico entre los equipos y el servidor DHCP no debería estar restringido.
Ahora, sería interesante añadir más switches a la topología. Primero, se crea un nuevo switch
OVS y se conecta al controlador:
$ ovs-vsctl add-br ovs-br2
$ ovs-vsctl set-controller ovs-br2 tcp:127.0.0.1:6633
$ ovs-vsctl set controller ovs-br2 connection-mode=out-of-band
70
DESARROLLO
Como se puede observar, no existe conectividad. Hay que conectar los dos switches mediante
puertos “patch”. Primero un switch:
71
DESARROLLO
Si se vuelve a comprobar la topología, se puede observar que ahora ambos switches están
conectados:
Ventajas de Docker
Docker supone la alternativa óptima para realizar los despliegues del laboratorio SDN. Permite
desplegar equipos finales con los servicios que se desee de una manera más eficiente que una
máquina virtual, ya que no requiere ejecutar un sistema operativo completo para desplegar cada
servicio o equipo final del que se desee disponer en la red.
Desventajas de Docker
La única desventaja que tiene Docker es el notable incremento de la complejidad que supone
configurar el contenedor para conectarlo a la red SDN. Sin embargo, si se han entendido las
explicaciones ofrecidas en el capítulo de Docker sobre su configuración de red, el uso de esta
tecnología no debería suponer ninguna dificultad adicional.
72
DESARROLLO
el conjunto de herramientas y servicios necesarios para desplegar entornos SDN aptos para la
correcta investigación de las redes definidas por software. También se escribirán los scripts
necesarios para automatizar el proceso de arrancar y configurar los diferentes dispositivos.
Para ello, en la máquina virtual donde se vaya a hacer el despliegue, se debe configurar el fichero
“Dockerfile”:
$ mkdir DockerConf
$ cd DockerConf/
$ nano Dockerfile
La imagen construida utiliza la última versión de Ubuntu como base e instala diferentes
programas que pueden ser utilizados para comprobar diferentes funcionalidades de la red.
Conviene destacar que se pueden añadir cualquier tipo de programa al Dockerfile que se
considere relevante para hacer pruebas. Se podrían instalar programas para, por ejemplo,
determinar vulnerabilidades en la red o hacer pentesting, entre otros.
73
DESARROLLO
Dockerizar el controlador
El controlador elegido para el despliegue en Docker ha sido ONOS. El motivo por el que se ha
elegido ONOS y no ODL es el que ya se mencionó en capítulos anteriores, para un entorno de
pruebas ofrece un mayor número de funcionalidades implementadas. Sin embargo, si se desea
crear un contenedor con OpenDaylight, en teoría habría que configurar un Dockerfile con las
instrucciones que se ejecutarían normalmente para desplegar ODL como servicio en una
máquina normal.
Primero, se debe generar un Dockerfile en el que se ejecuten de forma automática los pasos
realizados en el capítulo de instalación de ONOS en secciones anteriores de este trabajo.
Además, en este caso se desplegará ONOS como un servicio y no como un programa ejecutable.
Se hará en un directorio diferente a donde se hizo el Dockerfile de los equipos finales:
$ mkdir onos
$ cd onos
$ nano Dockerfile
74
DESARROLLO
#Descarga de ONOS
RUN \
apt-get update && \
apt-get install -y wget software-properties-common net-tools systemd && \
add-apt-repository -y ppa:webupd8team/java && apt-get update && \
wget http://downloads.onosproject.org/release/onos-1.12.0.tar.gz -P /opt
# Instalacion de paquetes
RUN \
echo "oracle-java8-installer shared/accepted-oracle-license-v1-1 select true" |
debconf-set-selections && \
apt-get install -y sudo oracle-java8-installer && \
tar -zxvf /opt/onos-1.12.0.tar.gz -C /opt/ && \
mv /opt/onos-1.12.0 /opt/onos && \
cp /opt/onos/init/onos.initd /etc/init.d/onos && \
cp /opt/onos/init/onos.service /etc/systemd/system/
Y se construye la imagen:
$ docker build -t "onos:dockerfile" .
Este proceso llevará un rato. Una vez finalice, ya se pueden arrancar contenedores con la imagen
que se ha generado:
$ docker run -i -d --name=onos -–privileged onos:dockerfile
Después, hay que configurar ONOS para que arranque como servicio:
$ docker exec -it onos systemctl daemon-reload
$ docker exec -it onos systemctl enable onos
$ docker exec -it onos service onos start
$ docker exec -it onos systemctl start onos.service
75
DESARROLLO
En este momento, se tiene una imagen lista para ejecutar del controlador SDN. Sin embargo,
hay que notar que, en este momento, si se abriera un navegador web desde el anfitrión y se
introdujera la URL de ONOS, no habría conectividad. Esto se debe a que hay diferencias
importantes respecto a los anteriores despliegues realizados. El más fundamental es que antes,
al ser un proceso de la máquina virtual, se podía llegar al controlador a través de cualquiera de
las interfaces que tuviera configuradas en VirtualBox dicha máquina virtual. Es decir, cuando
antes se accedía a la web del controlador desde el anfitrión, se usaba la interfaz configurada
como “solo-anfitrión” para permitir esa conectividad entre anfitrión y máquina virtual. De igual
forma, cuando se conectaban switches OpenFlow, se hacía a través de localhost (127.0.0.1), ya
que tanto los switches como el controlador se estaban ejecutando en la misma máquina.
Puesto que el controlador se ejecuta en un contenedor Docker, ahora es, a nivel lógico, una
máquina nueva. Por tanto, se requieren dos configuraciones adicionales. Por un lado, configurar
la conectividad entre los switches OpenFlow (que se ejecutan en la máquina virtual) y el
controlador (que se ejecuta dentro de un contenedor dentro de la máquina virtual). Por otro
lado, realizar una redirección para que el tráfico que llegue desde la interfaz solo-anfitrión se
redirija al nuevo contenedor, de forma que se siga pudiendo acceder a la interfaz web de ONOS.
Como ya se mencionó en el capítulo sobre Docker, los contenedores se crean por defecto con
una interfaz de red conectada con un puente Linux (docker0) y este, a su vez, al anfitrión (en
este caso, la máquina virtual). Para permitir la conectividad con Internet, se realiza una
traducción NAT. Esto se debe a que los contenedores se encuentran en una red virtual
independiente (que está definida por docker0). Sin embargo, a priori no es posible conectarse
desde fuera de la máquina anfitriona al contenedor (y, por ende, al controlador SDN).
Para permitir esta comunicación, hay que indicarle a Docker qué puertos del contenedor se
quieren exponer en el anfitrión. Conviene, antes de nada, borrar el contenedor que se ha creado
en primera instancia:
$ docker rm -f onos
Una vez se conoce la IP, se le indica al contenedor la redirección que se quiere hacer. Esto se
consigue indicando la opción -p del comando “run”:
76
DESARROLLO
El comando anterior permite que todo el tráfico que llegue a la máquina virtual por la interfaz
que tenga asignada la IP 10.10.0.11 y al puerto 8181 (puerto de la interfaz web de ONOS) se
redirigirá al contenedor.
Ahora, debe lanzarse ONOS como servicio de la misma forma que se hizo anteriormente:
$ docker exec -it onos systemctl daemon-reload
$ docker exec -it onos systemctl enable onos
$ docker exec -it onos service onos start
$ docker exec -it onos systemctl start onos.service
Una vez hecho esto, si desde el anfitrión de la máquina virtual se introduce la URL, se accederá
a la web del controlador SDN que se está ejecutando en el contenedor. Es importante destacar
que la redirección solo se puede hacer en el momento de crear el contenedor mediante el
comando “run”. También es importante mencionar que, puesto que ahora se ejecuta como un
servicio, no se pueden activar las aplicaciones desde la terminal de ONOS. Es necesario hacerlo
a través de la interfaz gráfica. Se recuerda que hay que activar tanto “org.onosproject.openflow”
como “org.onosproject.fwd”:
Ahora falta conectar los switches Open vSwitch al controlador. Se puede utilizar la dirección IP
de la interfaz docker0 del contenedor para comunicarse con los switches OpenFlow que se están
77
DESARROLLO
Si se abre la topología en la web del controlador, puede verse conectado el nuevo switch:
Para confirmar que la red SDN está operativa, se pueden arrancar dos equipos finales con la
imagen Docker generada previamente y conectarlos al switch Open vSwitch que se ha creado:
$ docker run -i -d --name=cont1 –-net=none host:dockerfile
$ docker run -i -d --name=cont2 –-net=none host:dockerfile
$ ovs-docker add-port ovs-br1 eth1 cont1 --ipaddress=192.168.0.2/24
$ ovs-docker add-port ovs-br1 eth1 cont2 --ipaddress=192.168.0.3/24
78
DESARROLLO
Hasta este punto del trabajo, se ha logrado desplegar laboratorios virtualizados de SDN
mediante procesos Open vSwitch y contenedores Docker para equipos finales y el controlador
SDN. Con todas estas herramientas, ya puede crearse una red SDN virtualizada real con la
morfología que se desee y optimizada en cuanto a gasto de recursos físicos. Sin embargo, resulta
tedioso tener que realizar todos estos pasos de forma manual cada vez que se desea realizar un
despliegue. Se hace necesario, por tanto, automatizar el proceso mediante un script de
despliegue.
Scripts de despliegue
Como ya se ha mencionado, realizar manualmente cada una de las acciones necesarias para
desplegar el laboratorio es una tarea tediosa que requiere un consumo de tiempo innecesario.
Puesto que las acciones son siempre las mismas, pueden agruparse en un script Bash que las
ejecute. También serán necesarios los dos ficheros Dockerfile creados anteriormente para los
equipos finales y el controlador.
El script se encargará primero de instalar los programas necesarios (Docker y Open vSwitch). En
segundo lugar, creará diferentes directorios para almacenar los Dockerfile y construirá las
nuevas imágenes Docker a partir de las acciones contenidas en dichos ficheros Dockerfile. Es
importante destacar que el script buscará los ficheros Dockerfile por el nombre de
DockerfileONOS y DockerfileHosts en el directorio en el que se encuentra el script. Si se
nombraran por otro nombre o se encontraran en otro directorio no se desplegaría
correctamente. Una vez construidas las imágenes del controlador y los equipos finales, se
arranca el contenedor que ejecutará ONOS. Posteriormente se crean los switches OpenFlow y
se conectan al controlador. Una vez conectados con el controlador, se conectan entre sí
mediante los puertos “patch” vistos anteriormente. Finalmente, se arrancan los equipos finales
y se conectan a sus respectivos switches. A los equipos finales se les asignarán direcciones del
rango de red 192.168.0.0/24, empezando en 192.168.0.1.
Conviene resaltar que el único punto que no se ha podido automatizar es la activación de las
aplicaciones en el controlador. Esto se debe a que ONOS se ejecuta como un servicio y no como
un programa, y por tanto no hay, aparentemente, acceso a la terminal del propio controlador
para ejecutar los comandos. En la documentación oficial de ONOS no se ha encontrado
información a este respecto.
Para este despliegue, se hará manualmente mediante la interfaz web de la misma forma que se
hizo en el capítulo anterior. Existe una tercera forma de activar aplicaciones en ONOS: mediante
la API REST de la Northbound Interface. Sin embargo, este método se sale del alcance de este
trabajo, por lo que se utilizará la interfaz web.
79
DESARROLLO
Pruebas realizadas
Para comprobar la eficacia del script desarrollado, así como de las imágenes Docker generadas
a partir de los Dockerfile de equipos finales y controlador, se han llevado a cabo varias pruebas.
Al igual que con el resto de los escenarios desplegados, las pruebas se han realizado sobre una
máquina virtual con Ubuntu Server 16.04 limpia, sin ningún paquete instalado. Las pruebas
permitirán comprobar si el script instala correctamente todos los elementos necesarios para
desplegar la red SDN y despliega los contenedores Docker de los equipos finales, los switches
OpenFlow y el contenedor Docker del controlador.
Prueba 1
La primera prueba, al no estar instalados los programas necesarios ni generadas las imágenes
de Docker, tardará más en concluir. Esto se debe, fundamentalmente, a que debe descargar el
controlador SDN y el JRE (Java Runtime Environment).
Antes de lanzar el script, conviene comprobar que están todos los ficheros necesarios en el
mismo directorio:
$ ls
DockerfileHosts DockerfileONOS scriptDespliegue.sh
Y se procede a ejecutar el script. Para la primera prueba, simplemente se crean dos switches y
dos equipos conectados a cada switch:
$ sudo ./scriptDespliegue.sh 10.10.0.11 2 2
Una vez concluido el script, se comprueba que todos los contenedores se han arrancado
correctamente:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
163acc03c22b host:dockerfile "/bin/bash" 12 minutes ago Up 12
minutes contenedor3
338b85045e7c host:dockerfile "/bin/bash" 12 minutes ago Up 12
minutes contenedor2
294cf691ecc1 host:dockerfile "/bin/bash" 12 minutes ago Up 12
minutes contenedor1
c480bd995d8b host:dockerfile "/bin/bash" 12 minutes ago Up 12
minutes contenedor0
eccc05e60fef onos:dockerfile "/sbin/init" 12 minutes ago Up 12
minutes 10.10.0.11:8181->8181/tcp onos
Después, se abre un navegador y se accede a la interfaz de ONOS para activar las aplicaciones
de OpenFlow y forwarding reactivo. Si se comprueba la topología, se ven dos switches OpenFlow
conectados:
80
DESARROLLO
Los equipos no se ven porque aún no se ha generado tráfico. Basta con lanzar un ping desde uno
de ellos al resto para comprobar que todo funciona correctamente.:
$ docker exec contenedor0 ping 192.168.0.2
$ docker exec contenedor0 ping 192.168.0.3
$ docker exec contenedor0 ping 192.168.0.4
También hay que hacer visibles los equipos finales en la interfaz de ONOS (desde el menú inferior
izquierdo de la topología). Una vez hecho esto, aparecerán los contenedores en la topología:
Prueba 2
En la segunda prueba van a conectarse un mayor número de dispositivos para comprobar la
escalabilidad del script. Primero, se borran todos los contenedores de la prueba anterior:
$ docker rm -f $(docker ps -a -q)
163acc03c22b
338b85045e7c
294cf691ecc1
81
DESARROLLO
c480bd995d8b
eccc05e60fef
Una vez activados los módulos de ONOS y comprobada la conectividad, la topología resultante
es la siguiente:
Prueba 3
En esta última prueba se va a probar a desplegar 50 equipos en 10 switches Open vSwitch. Es
decir, 5 equipos finales por cada switch. Primero se borran los contenedores y los switches de la
prueba anterior y después se vuelve a ejecutar el script:
$ sudo ./scriptDespliegue.sh 10.10.0.11 10 5
Una vez finalizado el script y activadas las aplicaciones en ONOS, y para no tener que hacer 50
pings para comprobar la conectividad, se hace uso de la herramienta “nmap” que se ha instalado
en los equipos finales y que viene incluida en el Dockerfile de estos contenedores:
$ docker exec contenedor0 nmap -T5 -sP 192.168.0.0-50
82
DESARROLLO
Con esta prueba se concluye que la automatización del despliegue es correcta y está preparada
para desplegar topologías tanto grandes como pequeñas. Si se quisieran desplegar topologías
más concretas, como por ejemplo conectar los switches de otra manera, a lo largo de este
trabajo se han dado las pautas y las instrucciones necesarias para realizar una configuración más
personalizada.
83
CONCLUSIONES
Como se ha comprobado a lo largo de este trabajo, la llegada de la virtualización y los servicios
en la nube ha demostrado que el modelo actual de red no está preparado para gestionar la
conectividad de las infraestructuras modernas, pues el modelo tradicional de red está orientado
a redes estáticas, con gran resiliencia ante fallos o cambios puntuales, pero poco flexible ante
cambios continuados en la topología. Este esquema es totalmente contrario al concepto de la
virtualización, donde las máquinas a nivel lógico no se corresponden con el nivel físico y existen
cambios constantes para aprovisionar nuevos recursos acorde a la demanda del momento. Por
ese motivo, las redes definidas por software se presentan como la solución ideal para gestionar
la conectividad de estos sistemas. Además, en un contexto en el que las organizaciones y los
usuarios dependen cada vez más de los servicios en la nube, es presumible que las redes SDN
van a cobrar una mayor relevancia en el sector de las telecomunicaciones. En la actualidad, su
principal área de aplicación son los centros de procesamiento de datos, pero su uso potencial
no está reducido a ese ámbito. El auge del Internet de las Cosas (IoT) también pone de manifiesto
que es necesario encontrar alternativas al modelo de red tradicional en otras áreas alejadas de
la virtualización.
Sin embargo, las redes definidas por software son, por ahora, una tecnología emergente. Por
ese motivo, todavía no existe una gran penetración de esta tecnología en el mercado, lo que
genera una ausencia de información clara y estandarizada sobre su funcionamiento. Este es uno
de los motivos que ha propiciado la creación de este trabajo. Mediante la lectura de este trabajo
se pretende que el lector entienda el funcionamiento de esta tecnología, así como los protocolos
sobre los que se apoya. También se pretende ofrecer una imagen general de las tecnologías
actuales de virtualización y por qué se hace necesario gestionar la red mediante redes definidas
por software en vez usar tecnologías convencionales.
Como se ha podido apreciar a lo largo de este trabajo, se han probado diferentes escenarios
que, progresivamente, han permitido entender cómo se pueden desplegar equipos virtuales y
conectarlos entre sí para obtener una red virtual gestionada por un controlador SDN. De entre
todas las posibilidades analizadas, la que mejor se adapta a las necesidades de un estudiante o
un desarrollador de aplicaciones de red es la de los contenedores. Los contenedores Docker
permiten desplegar grandes redes de equipos virtuales y asignarles servicios para simular una
infraestructura real con un coste computacional muy bajo. Esto permite desplegar laboratorios
SDN con un alto grado de realismo en máquinas poco potentes como los ordenadores
personales.
85
LÍNEAS FUTURAS
El objetivo de este trabajo es sentar las bases de una futura profundización en el campo de las
redes definidas por software. Se han descrito los problemas que solucionan las redes SDN, sus
componentes y protocolos. También se ha hablado de las tecnologías de virtualización y cómo
desplegar una red virtualizada optimizada para un entorno de pruebas.
Ahora que se dispone de un entorno de despliegue ideal, las líneas futuras de trabajo deben
pasar por profundizar en la característica más importante de las redes definidas por software:
la programabilidad de la red. Debe notarse que hasta ahora todos los despliegues realizados han
consistido en redes conmutadas gestionadas por un controlador SDN mediante flujos. Esto se
ha hecho así para poder crear una red virtual que emula la topología física de una red. Sin
embargo, el objetivo es que, ahora que se tiene una red cableada virtual con un controlador SDN
y switches OpenFlow, se realicen pruebas más avanzadas, como subredes virtuales dedicadas
(en inglés, Virtual Tenant Networks). Esto implica detenerse significativamente en el análisis de
la Northbound Interface del controlador, ya que es mediante su API a través de la cual se realizan
la mayoría de las operaciones de gestión y monitorización de la red. Aprender a utilizarla e,
incluso, programar nuevas aplicaciones de gestión de la red que hagan uso de ella debería ser
uno de los objetivos a futuro.
También es interesante realizar un análisis profundo de la seguridad de las redes definidas por
software. Establecer nuevos vectores de ataque a la infraestructura que no padecen las redes
convencionales a la vez que se determina si se eliminan amenazas presentes en el modelo
tradicional o se siguen manteniendo. Es especialmente interesante evaluar el nivel de
vulnerabilidad existente en los switches OpenFlow, ya que una suplantación del controlador SDN
supondría control sobre todo el tráfico que pase por ese switch. A su vez, al existir un modelo
centralizado de red, un ataque contra el controlador supondría la caída de toda la
infraestructura.
Finalmente, no hay que olvidar que la existencia de las redes definidas por software es, en parte,
producto de la necesidad de abordar el problema que supone gestionar la red de un entorno
cloud. En este tipo de entornos, no se utiliza el controlador SDN directamente sobre la
infraestructura de la red física, sino que se utilizan herramientas de orquestación de red como
OpenStack Neutron para crear la red virtual y un controlador SDN para operarla y monitorizarla.
Además, los entornos cloud tienen sus propias herramientas para gestionar la virtualización de
los servicios de computación (como, por ejemplo, OpenStack Nova o Kubernetes). Sería
interesante en trabajos posteriores hacer una integración entre, por un lado, un entorno de
orquestación de red como Neutron y, por otro lado, un entorno de orquestación de
contenedores como Kubernetes. Y finalmente, para controlar la red de todo el sistema virtual,
utilizar un controlador SDN como OpenDaylight.
87
ANEXOS
Anexo A: Script de despliegue SDN
El siguiente script en Bash permite instalar en una máquina virtual con Ubuntu u otra
distribución similar todos los elementos necesarios para desplegar una red SDN. Esto incluye la
instalación de Docker y Open vSwitch. Además, genera las imágenes Docker para los equipos
finales y el controlador de la red virtual a partir de los ficheros Dockerfile. Dichos ficheros deben
encontrarse en el mismo directorio en que se ejecuta el script y deben llamarse
“DockerfileHosts” y “DockerfileONOS” respectivamente. Finalmente, los argumentos que recibe
el script son, en orden, los siguientes:
if [ "$1" == "--stop" ]
then
docker rm $(docker ps -a -q)
exit 0
fi
hostOnly=$1
numSwitches=$2
numContenedores=$3
apt-get update
apt-get install -y docker.io openvswitch-switch
mkdir -p -v $HOME/DockerConf/hosts
mkdir -p -v $HOME/DockerConf/controller
#Meter dockerfiles
mv DockerfileHosts "$HOME/DockerConf/hosts/Dockerfile"
mv DockerfileONOS "$HOME/DockerConf/controller/Dockerfile"
#Construir imagenes
#Levantar contenedor
89
ANEXOS
#Levantar switches
count=$numSwitches
#conectarlos entre sí
count=$numSwitches
90
ANEXOS
numeroIP=1
91
BIBLIOGRAFÍA
[1] RAND Corporation, Paul Baran and the Origins of the Internet. Disponible:
https://www.rand.org/about/history/baran.html
[2] Nadeem Unuth, What is PSTN? Lifewire. Disponible: https://www.lifewire.com/what-is-pstn-3426739
[3] Gahsinsky I. Warehouse scale datacenters: the case for a new approach to networking. Stanford University;
2011.
[4] Internet Engineering Task Force, IPv6 Flow Label Specification. Disponible: https://tools.ietf.org/html/rfc3697
[5] Doan Hoang, Software Defined Networking – Shaping up for the next disruptive step? Telsoc. Disponible:
https://telsoc.org/ajtde/2015-12-v3-n4/a28
[6] Paul Goransson, Chuck Black, Timothy Culver, Software Defined Networks: A Comprehensive Approach, 2nd
Edition, 2016
[7] Ching-Hao, Chang and Dr. Ying-Dar Lin OpenFlow Version Roadmap, 2015 Fuente:
http://speed.cis.nctu.edu.tw/~ydlin/miscpub/indep_frank.pdf
[8] SDXCentral. What is OpenFlow? Definition and How it Relates to SDN. Disponible:
https://www.sdxcentral.com/sdn/definitions/what-is-openflow/
[9] Jean Tourrilhes, Puneet Sharma, Sujata Banerjee, The Evolution of SDN and OpenFlow: A Standards Perspective.
HP Labs. Disponible: https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-
papers/evolution-of-sdn-and-of.pdf
[10] Internet Engineering Task Force, Software-Defined Networking (SDN): Layers and Architecture Terminology.
Disponible: https://tools.ietf.org/html/rfc7426
[11] Technopedia, Control Plane. Disponible: https://www.techopedia.com/definition/32317/control-plane
[12] Flowgrammable, Matching in OpenFlow Protocol. Disponible:
http://flowgrammable.org/sdn/openflow/message-layer/match/
[13] Matt Oswalt, [SDN Protocols] Part 2 - OpenFlow Deep-Dive. Keeping It Classless. Disponible:
https://keepingitclassless.net/2014/07/sdn-protocols-2-openflow-deep-dive/
[14] Github, Repositorio del controlador POX. Disponible: https://github.com/noxrepo/pox
[15] OpenContrail, Quick Start Guide. Disponible: http://www.opencontrail.org/opencontrail-quick-start-guide/
[16] OpenContrail, OpenContrail Architecture. Disponible: http://www.opencontrail.org/opencontrail-architecture-
documentation/#section1_1
[17] Trefis Team, Why Cisco Is Worth Nearly 15 Times As Much As Juniper. Forbes. Disponible:
https://www.forbes.com/sites/greatspeculations/2017/07/03/why-cisco-is-worth-nearly-15-times-as-much-as-
juniper/#2f8d1e42a3fe
[18] SDXCentral, SDN Controller Comparison Part 1: SDN Controller Vendors (SDN Controller Companies). Disponible:
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/sdn-controllers-comprehensive-list/
[19] Rus Shuler, How Does the Internet Work? Disponible:
http://www.theshulers.com/whitepapers/internet_whitepaper/index.html
[20] John Dix, Router man. Disponible: https://www.networkworld.com/article/2309917/lan-wan/lan-wan-router-
man.html
[21] The Linux Foundation, Open Source Networking. Disponible:
https://www.linuxfoundation.org/projects/networking/
93
BIBLIOGRAFÍA
94
BIBLIOGRAFÍA
95
Este documento esta firmado por
Firmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Wed Jun 06 19:31:05 CEST 2018
Emisor del [email protected], CN=CA Facultad de
Certificado Informatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe
Signature)