TFG Pablo Sayaus Cobos

Graduado en Ingeniería Informática
Universidad Politécnica de Madrid

Escuela Técnica Superior de
Ingenieros Informáticos
TRABAJO FIN DE GRADO
Despliegue de laboratorios virtualizados de SDN

utilizando Open vSwitch
Autor: Pablo Sayans Cobos

Director: Miguel Jiménez Gañán
MADRID, JUNIO 2018

ÍNDICE
Resumen....................................................................................................................................... iii
Abstract ........................................................................................................................................ iii
Introducción ..................................................................................................................................iv
Estudio y análisis de las Redes Definidas por Software ................................................................ 1
Evolución de las redes de telecomunicaciones ......................................................................... 1
Plano de control en el nivel de red ....................................................................................... 2
Plano de control en el nivel de enlace .................................................................................. 3
Relación del hardware con el plano de control y el plano de datos ..................................... 4
Problemas de las redes actuales. Las redes SDN y los centros de procesamiento de datos .... 5
Saturación en el plano de control ......................................................................................... 6
Cambios en la topología y tiempo de convergencia ............................................................. 7
De este a oeste y de norte a sur............................................................................................ 7
Coste ...................................................................................................................................... 8
Conclusiones.......................................................................................................................... 9
Características de las redes definidas por software.................................................................. 9
Las partes del controlador................................................................................................... 11
Los diferentes controladores y su estado actual .................................................................... 12
Estado actual ....................................................................................................................... 12
ONOS ................................................................................................................................... 13
OpenDaylight....................................................................................................................... 15
Ryu....................................................................................................................................... 17
OpenContrail ....................................................................................................................... 18
Estudio y análisis del protocolo OpenFlow ................................................................................. 21
Tablas de flujos........................................................................................................................ 22
Instrucciones y action sets ...................................................................................................... 24
Equiparación de paquetes....................................................................................................... 25
Puertos OpenFlow ................................................................................................................... 28
Tipos de mensajes OpenFlow.................................................................................................. 30
Compatibilidad entre versiones .............................................................................................. 31
Estudio y análisis de tecnologías de virtualización ..................................................................... 33
Máquinas virtuales .................................................................................................................. 33
Hipervisores......................................................................................................................... 33
Tipos de red en VirtualBox .................................................................................................. 34
Contenedores Docker.............................................................................................................. 36
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
Aunque Baran y su equipo desplegaron un laboratorio y demostraron su eficacia, la idea no

prosperó. Sin embargo, poco tiempo después, estas ideas fueron retomadas para la creación de
ARPANET, la red precursora de la Internet moderna.
Con la evolución de las telecomunicaciones y la llegada de Internet, se definió un modelo de red

totalmente distribuido y enfocado a no conexión. Esto significa que cada paquete enviado por
la red contiene la información suficiente para ser encaminado a su destino. Por tanto, en
Internet no existe un preacuerdo entre los dos extremos de una comunicación a la hora de
establecer el camino que debe seguir la información. Se confía en que la propia infraestructura
de Internet podrá hacer llegar la información a su destino de forma autónoma [19]. Esta
infraestructura no es un sistema homogéneo, pues cada router trabaja de forma independiente,
aunque, como se verá más adelante, comparten información entre ellos para asegurarse de que
la información se encamina correctamente.
Esta aproximación histórica al mundo de las telecomunicaciones es interesante desde la

perspectiva del análisis de las Redes Definidas por Software. Desde sus orígenes, Internet se ha
construido como una colosal red de redes distribuidas con dispositivos autónomos que
comparten información entre sí para garantizar la operabilidad. Nótese que, aunque cada router
es independiente de los demás, existen una serie de protocolos comunes que les permiten
comunicarse entre sí para generar una inteligencia colectiva que les permita encaminar el
tráfico. Sin embargo, en última instancia, cada router toma sus propias decisiones y no existe un
conocimiento global de toda la topología de Internet. Además, existen diferentes protocolos y
no todos los dispositivos hacen uso de los mismos. Con la llegada posterior de las redes privadas,
tanto corporativas como domésticas, se ha replicado la misma tecnología, por lo que todas las
redes actuales son, en esencia, iguales en su funcionamiento.
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.
Plano de control en el nivel de red

La arquitectura actual de red distribuida tiene varias implicaciones. Por un lado, deben existir
mecanismos que permitan a los enrutadores de tráfico (routers) mantener información
actualizada y fiable sobre los caminos óptimos por los que deben enviar los paquetes. Por otro
lado, deben ser capaces de responder ante cambios o fallos en la topología de la red. Para
conseguir esta inteligencia colectiva dentro de una red en la que cada nodo toma sus decisiones
2
de forma independiente, se hace necesaria la existencia de protocolos de enrutamiento

(routing) dinámico. Existen diferentes protocolos de enrutamiento dinámico, tanto para enrutar
dentro de un mismo sistema autónomo (Interior Gateway Protocol, IGP) como para enrutar
entre diferentes sistemas autónomos (Exterior Gateway Protocol, EGP). Cada protocolo usa un
algoritmo diferente para determinar el camino óptimo, pero todos comparten dos propiedades
comunes. Primero, necesitan comunicarse con otros dispositivos para completar sus tablas de
rutas. Segundo, necesitan informarse los unos a los otros regularmente de que siguen operativos
y asegurarse de que mantienen información de enrutamiento actualizada. Existen diferencias
de funcionamiento entre los diferentes protocolos. En el caso de EIGRP (Enhanced Interior
Gateway Routing Protocol), cada router se comunica únicamente con sus vecinos, de forma que
la información va distribuyéndose entre los diferentes routers a medida que cada nodo va
transmitiendo la información nueva recibida de un vecino al resto de vecinos hasta alcanzar la
convergencia de la red. En el caso de OSPF (Open Shortest Path First), todos los routers
intercambian información entre sí a través de mensajes de diferente tipo y todos ellos son
conscientes de la topología completa de la red.
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.
Plano de control en el nivel de enlace

Hasta ahora, se ha hablado exclusivamente de los mecanismos necesarios para controlar el
envío de información entre diferentes redes, pero hay que plantearse qué ocurre en el nivel de
enlace entre dispositivos de la misma red.
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
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.
Relación del hardware con el plano de control y el plano de datos

Una cuestión importante que debe plantearse sobre cualquier infraestructura de red es cuál es
el coste computacional de la gestión del plano de control.
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
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.
Problemas de las redes actuales. Las redes SDN y los centros de

procesamiento de datos
Como se puede observar, en el modelo distribuido que siguen las redes hoy en día, existen
diferentes protocolos, tanto a nivel de enlace como a nivel de red, necesarios para el correcto
funcionamiento de la infraestructura. Además, esta arquitectura es única y global para todos los
tipos de redes, independientemente de su tamaño o morfología, lo que en cierta medida
demuestra la escalabilidad y elasticidad del modelo vigente. Sin embargo, la entrada en escena
de otras tecnologías emergentes, como la virtualización y el Internet of Things, el notable
aumento del tráfico de red y el incremento en la densidad de dispositivos pone en el punto de
mira la optimalidad de las redes distribuidas convencionales en ciertos entornos.
Uno de estos entornos es el de los Centros de Procesamiento de Datos (CPDs). Se trata de

infraestructuras compuestas por centenares de nodos transmitiendo y recibiendo grandes
cantidades de información entre ellos y con el exterior.
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
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.
Ilustración 2. Arquitectura de red habitual en un CPD.
Saturación en el plano de control

Mantener operativa una red con tantos protocolos de control implica un coste computacional
elevado y mucho tráfico destinado a esa tarea, ya que cada dispositivo envía a intervalos
regulares mensajes de difusión por cada protocolo de control que está operando. De hecho,
según [3], en los CPDs modernos de gran tamaño, más del treinta porciento de la capacidad del
plano de control de los routers se destina a monitorizar la topología de la red. Además, en la
actualidad la mayoría de los cambios que se producen en la infraestructura están hechos de
forma intencionada, reduciendo el beneficio de usar protocolos autónomos y distribuidos, cuyo
punto fuerte es adaptarse a cambios bruscos y puntuales, como un fallo en alguno de los nodos.
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
Cambios en la topología y tiempo de convergencia

Como se ha mencionado previamente, las necesidades del mercado actuales han provocado la
adopción de nuevas tecnologías. La llegada de los servicios cloud ha trastocado el modelo actual
de red. Donde antes había infraestructuras relativamente estáticas y con un aprovisionamiento
fijo de recursos, ahora hay redes dinámicas en constante cambio para ajustarse en tiempo real
a la demanda de los clientes.
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.
De este a oeste y de norte a sur

Dentro del mundo de los centros de procesamiento de datos se considera que existen dos tipos
de tráfico. El tráfico este-oeste y el tráfico norte-sur. El tráfico este-oeste es aquel que se
produce entre dispositivos del CPD, normalmente entre servidores. Es decir, es tráfico que nunca
abandona el CPD y que por tanto se transmite en su mayoría por la red conmutada. Por otro
lado, el tráfico norte-sur es el tráfico que existe entre la red interna del CPD y el resto del mundo
(es decir, Internet).
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
petición, el servidor “front-end” preguntaba al servidor de la base de datos y respondía al cliente,

generando prácticamente el mismo tráfico norte-sur que este-oeste. Las arquitecturas
modernas están diseñadas para poder escalar a medida que aumenta la demanda. Donde antes
había un servidor físico con la base de datos completa, ahora hay muchos nodos virtuales que
contienen una porción de la base de datos cada uno. En esta tesitura, cuando un cliente realiza
una consulta, se debe a su vez consultar a múltiples nodos en el centro de datos antes de
obtener una respuesta agregada que enviarle al cliente.
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.
Actualmente, el mercado de las telecomunicaciones está repleto de fabricantes de equipo de

redes. En teoría, los protocolos y estándares se aseguran de que en cualquier infraestructura la
interoperabilidad entre dispositivos de diferentes fabricantes esté garantizada. Sin embargo,
cada fabricante tiene su propia implementación de protocolos y funcionalidades. Además,
existen protocolos propietarios que solo funcionan entre dispositivos del mismo fabricante. Otro
aspecto importante es el de la gestión. Cada fabricante tiene sus propias herramientas de
gestión para centralizar la administración de los dispositivos. También, puesto que cada
fabricante tiene su propio servicio de soporte técnico, resulta mucho más sencillo y barato el
trato con el soporte técnico si solo existe un servicio de asistencia y no varios, uno por cada
fabricante del que se adquieren dispositivos. Por último, los propios fabricantes ofrecen
programas de fidelización a las organizaciones a fin de mantener a sus clientes atados a sus
productos, ya que ofrecen descuentos notables a las organizaciones más comprometidas con
ellos [6].
En última instancia, muchas organizaciones acaban comprometidas con un único fabricante a

fin de asegurar el buen funcionamiento de su infraestructura y de reducir costes tanto de
adquisición como operativos. Eso, unido al hecho de que apenas existen media docena de
grandes fabricantes de equipo de redes, de los cuales Cisco acapara más de la mitad de la cuota
8
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].
Otra cuestión importante cuando se habla de redes es el aprovisionamiento. En un entorno

tradicional, para garantizar la continuidad del servicio, es necesario replicar el número de
dispositivos de red para tener un sistema redundante. En una SDN, se puede aumentar el gasto
computacional en tiempo real en caso de que se necesiten dispositivos virtuales de respaldo o
para atender una elevada demanda, que es mucho más económico que comprar hardware.
Por último, se reduce la reticencia al cambio. Migrar a un modelo de red enfocado

principalmente a obtener una infraestructura dinámica y elástica invita a las organizaciones a
realizar cambios enfocados en mejorar su servicio sin el habitual miedo de la industria a que los
riesgos sean mayores que los beneficios.
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.
Características de las redes definidas por software

Como se ha establecido previamente, las redes definidas por software giran en torno al concepto
de una red centralizada orquestada por un controlador que toma las decisiones sobre cuál es el
camino que debe seguir el tráfico, liberando al resto de dispositivos de red de esta tarea, que se
centran únicamente en el encaminamiento de dicho tráfico (plano de datos). En esencia, lo que
diferencia a una SDN de una red convencional es el hecho de que, mientras que en la red
distribuida cada dispositivo de red tiene su propio plano de control y plano de datos, en las redes
SDN ese plano de control queda en manos de un único elemento, el controlador SDN. Por tanto,
existe una separación total entre el plano de control (controlador) y plano de datos (dispositivos
de red).
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
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.
En una red tradicional, se añadiría información a la tabla de conmutación/rutas del

switch/router con la información necesaria para encaminar tráfico a la red de destino. En las
redes SDN, como ya se ha discutido previamente, no es factible aplicar este concepto. Debido a
la maleabilidad de las redes SDN, cualquier cambio en la topología supondría un recálculo de las
rutas por parte de los dispositivos de red, con su consecuente pérdida de servicio durante el
tiempo que tarda la red en converger. Para resolver este problema, en las redes definidas por
software se trabaja con el concepto de flujos. En el mundo de las redes de telecomunicaciones,
existen al menos tres definiciones formales del concepto de “flujo” (RFC 2722, RFC 3697, RFC
3917). No obstante, en el presente trabajo se tomará como referencia la que viene descrita en
RFC 3697: "una secuencia de paquetes enviados desde una fuente particular a un destino
unicast, muticast o broadcast particular. Un flujo puede consistir en todos los paquetes
contenidos en una conexión de transporte específica o corriente de datos" [4].
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
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.
Las partes del controlador

Se ha determinado que el controlador SDN se comunica con los switches Openflow para
informarles de por dónde deben encaminar el tráfico. Esta parte del controlador responsable de
la interacción con los dispositivos de red es la denominada “Southbound Interface”. Se podría
definir la Southbound Interface como una capa de manejadores de dispositivos que gestiona la
comunicación entre los switches OpenFlow y el controlador.
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].
Entre medias de la Northbound Interface y la Southbound Interface se encuentra la lógica que

permite la interacción entre las órdenes abstractas recibidas por la Northbound desde
aplicaciones externas y las órdenes concretas que debe darle el controlador a los switches por
medio de la Southbound. A esta capa se le suele denominar capa de abstracción de servicio (del
inglés, service abstraction layer, SAL). En la mayoría de los controladores, este nivel también
11
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.
Ilustración 4. Arquitectura habitual de un controlador SDN.
Conviene resaltar que la capacidad de programar la red es la característica fundamental de las

Redes Definidas por Software. Aunque hasta ahora se ha hablado de los diferentes aspectos en
los que las redes SDN resuelven problemas de las redes tradicionales, es imperativo entender
que lo que le confiere a la red SDN sus capacidades es la habilidad de ser gestionada o
monitorizada por aplicaciones externas totalmente independientes del controlador. De hecho,
en esencia, el controlador SDN no es más que un conjunto de librerías y módulos que le permiten
recibir una serie de órdenes a través la Northbound Interface y programar, a su vez, los switches
OpenFlow mediante la Southbound Interface para que gestionen el tráfico de la red tal y como
desea el usuario.
Los diferentes controladores y su estado actual

Las redes definidas por software son un campo muy reciente, y por lo tanto es una tecnología
que todavía no está bien asentada. No existen referencias claras sobre cuál es el mejor modelo
o los mejores productos. En este capítulo se hará un análisis general de los controladores SDN
Open Source más destacados en el momento de redactar este trabajo.
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
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
Es el controlador más orientado a redes de teleoperador, pero también puede utilizarse (y se

utiliza) dentro de los centros de procesamiento de datos. Cuenta con el apoyo de grandes
empresas dentro del sector de las telecomunicaciones. Principalmente, de algunos de los
mayores teleoperadores mundiales, como AT&T, China Unicom, Comcast o Deutsche Telekom
[22]. También tiene el apoyo de fabricantes como Huawei, que trabajan estrechamente con
ONOS para desplegar escenarios reales [26].
Se trata de un controlador bien documentado. Toda la información está correctamente

clasificada y actualizada. Conviene resaltar la facilidad que conlleva poner en marcha una red
SDN simple con ONOS. Únicamente es necesario activar dos aplicaciones,
org.onosproject.openflow para poder comunicar los switches OpenFlow con el controlador, y
org.onosproject.fwd para habilitar el forwarding reactivo. El forwarding reactivo consiste en
crear flujos dinámicamente cuando el controlador no tiene ningún flujo específico para manejar
ese tráfico.
Las actualizaciones de ONOS son espaciadas en el tiempo. A diferencia de OpenDaylight, que se

actualiza regularmente. Esto puede suponer una ventaja o un inconveniente. Por un lado, menos
actualizaciones supone un mantenimiento más sencillo del controlador, obligando a actualizarlo
únicamente cuando hay necesidades reales de hacerlo. Por otro lado, los problemas duran más
tiempo sin ser solucionados y las nuevas funcionalidades tardan más en llegar.
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].
Ya que se menciona la interfaz gráfica de ONOS, conviene mencionar que es notablemente

mejor que la de OpenDaylight. En la topología de ONOS se pueden ver los diferentes dispositivos
de red y los hosts conectados. Pero de una manera mucho más dinámica. Se dispone de
múltiples filtros para obtener una mejor visualización de la red. Algunos de estos filtros son por
tipos de dispositivo, por tipo de tráfico o por flujos. También nos permite ver en tiempo real la
cantidad de tráfico existente en cada enlace de a red, o los flujos que se encuentran activos. En
teoría, cualquier aplicación externa enfocada en la monitorización de la red y conectada a la
Northbound Interface del controlador ofrecerá un entorno de visualización mejor que la propia
interfaz web del controlador. Sin embargo, en un entorno de investigación como el de este
trabajo, en el que no se van a conectar aplicaciones externas, es probable que ONOS ofrezca
una mejor visualización de la red que OpenDaylight.
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
Ilustración 6. Interfaz web de ONOS.
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].
OpenDaylight se actualiza más rápidamente que el resto de sus competidores, lo que es en sí

mismo una ventaja. Además, la última versión (OpenDaylight Oxygen) está enfocada en mejorar
la integración de los contenedores en la red. Ofrece el denominado “motor de orquestación de
contenedores” que incorpora, entre otras cosas, un plugin para Kubernetes y mejoras en la
integración de OpenStack Neutron con la Northbound Interface a la hora de gestionar entornos
mixtos de máquinas virtuales y contenedores [28].
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
Ilustración 7. Interfaz web de OpenDaylight.
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
Ilustración 8. Llamadas a la API REST desde la interfaz gráfica de OpenDaylight.
Como ya se ha indicado previamente, la documentación de OpenDaylight está, en general, muy

mal estructurada. Existen dos fuentes de documentación oficiales del controlador. Una de ellas
es la Wiki de OpenDaylight (https://wiki.opendaylight.org) y la otra es la web de documentación
(http://docs.opendaylight.org). Aparentemente, ambas páginas contienen información de
referencia. En ambas se entremezclan las guías de usuario con la documentación de los
diferentes módulos de OpenDaylight. Además, debido a la cadencia de las actualizaciones del
controlador, mucha de la documentación existente se queda obsoleta rápidamente, pero las
guías no se actualizan en consecuencia y la información de los módulos sigue apareciendo como
si estuviera vigente. En ese aspecto, ODL todavía tiene amplio margen de mejora.
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
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.
Ilustración 9. Arquitectura de Ryu.
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
De forma similar a OpenStack, OpenContrail se organiza en nodos (de hecho, OpenContrail

implementa varios módulos de OpenStack). Cada nodo es una construcción lógica que cumple
una función en el sistema y que no se corresponde necesariamente con un nodo físico [15].
x Nodo de base de datos: Utiliza la base de datos Cassandra.

x Nodo de configuración: Este nodo ejecuta OpenStack neutron, el servidor con la API de
configuración y otros servicios relacionados.
x Nodo de análisis: Nodo encargado de la recolección y publicación de datos para análisis.
x Web UI
x Nodo de control: Ejecuta BGP y el servidor DNS.
x Nodo de cómputo: Este nodo contiene los vRouters y los servicios de cómputo de
OpenStack.
Ilustración 10. Diagrama de la arquitectura de OpenContrail.
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].
En esencia, OpenFlow consiste en un conjunto de mensajes que son enviados desde el

controlador al switch y otro conjunto de mensajes que son enviados en sentido opuesto. Estos
mensajes, colectivamente, capacitan a la SDN para realizar dos acciones:
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.
Ilustración 11. Historial de versiones de OpenFlow [7].
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
Ilustración 12. Pipeline de OpenFlow 1.3.
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:
x Enviar el paquete al controlador para que este se encargue de encaminarlo.

x Pasar el paquete a otra tabla del switch.
x Desechar el paquete.
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
Ilustración 13. Pipeline de OpenFlow 1.5.
Instrucciones y action sets

Como ya se ha establecido, cada paquete entrante tiene asociado un action set y cada entrada
en las tablas de flujos contiene un conjunto de instrucciones. Es importante entender esta
distinción. El action set asociado al paquete entrante contiene las acciones que se ejecutarán
sobre el paquete al acabar de recorrer las tablas. Las instrucciones asociadas a la entrada de un
flujo en la tabla de flujos se ejecutan cuando un paquete entrante equipara en esa entrada.
Primero se hablará sobre las instrucciones. Existen tres tipos de ellas:
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:
x Write-actions <acción/es>: Inserta una acción o conjunto de acciones en el action

set del paquete entrante. Si alguna de las acciones que se pretenden insertar ya está en
el action set, se sobrescribe.
x Goto-table <ID de la tabla>: Indica cuál es la siguiente tabla que debe consultarse.
Las instrucciones opcionales, aunque no se va a entrar en detalles sobre su funcionamiento, se

indican a continuación:
x Meter <id métrica>: Aplica una limitación a la métrica especificada.
24
x Apply-Actions <acciones>: Se aplica la acción especificada sobre el paquete

inmediatamente, sin esperar a que se ejecute el action set.
x Clear-Actions <acciones>: Elimina todas las acciones contenidas en el action set.
x Write-Metadata <metadatos/mascara>: Actualiza los metadatos.
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
Ilustración 14. Campos asociados a cada flujo en la tabla de flujos.
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]:
• Puerto de entrada del switch

• VLAN ID (trama 802.1q, nivel 2)
• Dirección MAC origen (trama Ethernet, nivel 2)
• Dirección MAC destino (trama Ethernet, nivel 2)
• Ethertype (qué protocolo encapsula en su carga la trama Ethernet)
• Dirección IP origen (paquete IP, nivel 3)
• Dirección IP destino (paquete IP, nivel 3)
• Tipo de protocolo que encapsula en su carga el paquete IP
• Tipo de servicio (ToS) IP
• Puerto TCP/UPD origen (segmento TCP/datagrama UDP, nivel 4)
• Puerto TCP/UDP destino (segmento TCP/datagrama UDP, nivel 4)
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.
Sin embargo, a partir de Openflow 1.2, se cambia drásticamente la estructura de equiparación

en los flujos. En la versión 1.2, se desecha la estructura fija de la versión 1.0 y se adopta una
estructura TLV (tipo-valor-longitud) denominada OpenFlow Extensible Match (OXM), que
permite realizar equiparaciones de una forma mucho más modular. En ella, se pueden definir
criterios de equiparación personalizados que se adapten a las necesidades particulares de cada
usuario [13]. Los OXM se segregan en clases, y dentro de las clases, en campos. Los campos se
definen para manejar equiparaciones muy específicas.
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
OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */

OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */
OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */
OFPXMT_OFB_VLAN_PCP = 7, /* VLAN priority. */
OFPXMT_OFB_IP_DSCP = 8, /* IP DSCP (6 bits in ToS field). */
OFPXMT_OFB_IP_ECN = 9, /* IP ECN (2 bits in ToS field). */
OFPXMT_OFB_IP_PROTO = 10, /* IP protocol. */
OFPXMT_OFB_IPV4_SRC = 11, /* IPv4 source address. */
OFPXMT_OFB_IPV4_DST = 12, /* IPv4 destination address. */
OFPXMT_OFB_TCP_SRC = 13, /* TCP source port. */
OFPXMT_OFB_TCP_DST = 14, /* TCP destination port. */
OFPXMT_OFB_UDP_SRC = 15, /* UDP source port. */
OFPXMT_OFB_UDP_DST = 16, /* UDP destination port. */
OFPXMT_OFB_SCTP_SRC = 17, /* SCTP source port. */
OFPXMT_OFB_SCTP_DST = 18, /* SCTP destination port. */
OFPXMT_OFB_ICMPV4_TYPE = 19, /* ICMP type. */
OFPXMT_OFB_ICMPV4_CODE = 20, /* ICMP code. */
OFPXMT_OFB_ARP_OP = 21, /* ARP opcode. */
OFPXMT_OFB_ARP_SPA = 22, /* ARP source IPv4 address. */
OFPXMT_OFB_ARP_TPA = 23, /* ARP target IPv4 address. */
OFPXMT_OFB_ARP_SHA = 24, /* ARP source hardware address. */
OFPXMT_OFB_ARP_THA = 25, /* ARP target hardware address. */
OFPXMT_OFB_IPV6_SRC = 26, /* IPv6 source address. */
OFPXMT_OFB_IPV6_DST = 27, /* IPv6 destination address. */
OFPXMT_OFB_IPV6_FLABEL = 28, /* IPv6 Flow Label */
OFPXMT_OFB_ICMPV6_TYPE = 29, /* ICMPv6 type. */
OFPXMT_OFB_ICMPV6_CODE = 30, /* ICMPv6 code. */
OFPXMT_OFB_IPV6_ND_TARGET = 31, /* Target address for ND. */
OFPXMT_OFB_IPV6_ND_SLL = 32, /* Source link-layer for ND. */
OFPXMT_OFB_IPV6_ND_TLL = 33, /* Target link-layer for ND. */
OFPXMT_OFB_MPLS_LABEL = 34, /* MPLS label. */
OFPXMT_OFB_MPLS_TC = 35, /* MPLS TC. */
OFPXMT_OFP_MPLS_BOS = 36, /* MPLS BoS bit. */
OFPXMT_OFB_PBB_ISID = 37, /* PBB I-SID. */
OFPXMT_OFB_TUNNEL_ID = 38, /* Logical Port Metadata. */
OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header pseudo-field */
};
Como se puede apreciar, muchos de los criterios de equiparación presentes se corresponden a

los campos que ya existían previamente en la versión 1.0, pero se han ampliado con otros nuevos
correspondientes a protocolos ampliamente extendidos en la actualidad, como MPLS y SCTP y
se da soporte a protocolos tradicionales como ICMP y ARP. No va a profundizarse en el
funcionamiento de la equiparación de paquetes en OpenFlow, ya que se sale del alcance de este
trabajo. No obstante, con saber que una propiedad de OpenFlow es que los paquetes pueden
27
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
CONTROLLER: representa el canal de comunicación con el controlador SDN. Se puede utilizar

como un puerto de entrada o de salida. Si se utiliza como puerto de entrada, identifica el
paquete como un mensaje del controlador. Si se utiliza como puerto de salida, encapsula el
mensaje en un paquete de tipo PACKET_IN y se encamina.
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.
NORMAL: representa el encaminamiento usando el funcionamiento normal de un switch

multinivel sin utilizar el pipeline OpenFlow, está pensado para switches OpenFlow híbridos
(aquellos que también pueden funcionar en modo normal). Solo se puede utilizar como puerto
de salida.
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
Ilustración 15. Representación de los caminos que siguen los paquetes según el puerto reservado que tienen asociado. Fuente: [6]
Tipos de mensajes OpenFlow

El protocolo OpenFlow posee una serie de mensajes concretos para permitir al controlador
instruir a los switches cómo deben actuar y permite a los switches informar al controlador de su
estado. En OpenFlow 1.0 se definieron la mayoría de los mensajes que se utilizan actualmente.
En versiones posteriores de OpenFlow se añadieron más mensajes relacionados con las nuevas
funcionalidades que se le dieron al protocolo. Sin embargo, para reducir la complejidad, y debido
a que su uso se sale del funcionamiento básico de OpenFlow, serán omitidos en este documento.
Los mensajes en OpenFlow 1.0 son los siguientes:
Tipos de mensaje Categoría

HELLO Simétrico
ECHO_REQUEST Simétrico
ECHO_REPLY Simétrico
VENDOR Simétrico
FEATURES_REQUEST Controlador-Switch
FEATURES_REPLY Switch - Controlador
GET_CONFIG_REQUEST Controlador-Switch
GET_CONFIG_REPLY Switch - Controlador
SET_CONFIG Controlador-Switch
PACKET_IN Asíncrono
FLOW_REMOVED Asíncrono
PORT_STATUS Asíncrono
30
Tipos de mensaje Categoría

ERROR Asíncrono
PACKET_OUT Controlador-Switch
FLOW_MOD Controlador-Switch
PORT_MOD Controlador-Switch
STATS_REQUEST Controlador-Switch
STATS_REPLY Switch - Controlador
BARRIER_REQUEST Controlador-Switch
BARRIER_REPLY Switch - Controlador
QUEUE_GET_CONFIG_REQUEST Controlador-Switch
QUEUE_GET_CONFIG_REPLY Switch - Controlador
El protocolo OpenFlow contempla tres tipos de mensajes: controlador-switch, asíncronos y

simétricos. Los mensajes controlador-switch son iniciados por el controlador y sirven para
administrar o conocer el estado de un switch. Los mensajes asíncronos son iniciados por el
switch y sirven para actualizar al controlador con eventos de red o para informar de un cambio
de estado en el switch. Por último, los mensajes simétricos son inicializados tanto por el
controlador como los switches y son enviados sin solicitación.
De los mensajes controlador-switch conviene destacar FLOW_MOD y PORT_MOD, que permite

al controlador modificar respectivamente los flujos y los puertos en el switch.
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.
Compatibilidad entre versiones

Cabe destacar que no todas las versiones de OpenFlow están soportadas por los diferentes
dispositivos de red, y por tanto muchas funcionalidades no están disponibles o funcionan de
manera diferente. En general, todos, o casi todos los switches OpenFlow tienen soporte para
OpenFlow 1.3, sin embargo, las versiones posteriores (1.4 y 1.5) no están totalmente
soportadas. Este trabajo implementa switches Open vSwitch para gestionar la SDN, y estos solo
tienen compatibilidad total con OpenFlow 1.3 [27], por lo que es la versión que se utilizará en
los despliegues.
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
Ilustración 16. Arquitectura de los hipervisores de tipo 1.
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.
Ilustración 17. Arquitectura de los hipervisores de tipo 2.
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.
Tipos de red en VirtualBox

Como ya se ha mencionado, todas las pruebas realizadas se han hecho utilizando VirtualBox. En
este contexto, es importante entender correctamente qué opciones ofrece VirtualBox para
garantizar la conectividad de las instancias virtuales. Por un lado, las máquinas necesitan
conectividad con Internet para descargar paquetes. Por otro lado, es necesario que exista
conectividad entre la máquina anfitriona y algunas máquinas virtuales, como el controlador
SDN. Por último, se debe conseguir de alguna manera simular una red real conectando las
diferentes máquinas virtuales entre sí. Todo esto se consigue utilizando diferentes tipos de
interfaz virtual de red:
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
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.
Adaptador sólo-anfitrión: Se utiliza para crear un canal de comunicación entre el anfitrión y el

huésped. Las interfaces sólo-anfitrión se conectan a las denominadas “redes sólo-anfitrión”. Se
trata de redes virtuales en las que tanto la máquina anfitriona como todos los huéspedes
conectados a esa red tienen una interfaz, permitiendo la conectividad entre ellos. En VirtualBox
se pueden crear tantas redes sólo-anfitrión como se desee (el anfitrión tendrá una interfaz en
cada una de ellas), indicando el segmento de red que se quiere utilizar y la dirección de un
servidor DHCP simulado que le asigna direcciones a todos los dispositivos conectados a esa red
sólo-anfitrión.
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:
Sufijo DNS específico para la conexión. . :

Vínculo: dirección IPv6 local. . . : fe80::947c:8e8f:1147:592d%8
35
Dirección IPv4 de configuración automática: 169.254.89.45

Máscara de subred . . . . . . . . . . . . : 255.255.0.0
Puerta de enlace predeterminada . . . . . :
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.
Ilustración 18. Arquitectura de Docker frente a la arquitectura de una máquina virtual.
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
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.
Conectividad de red en Docker

Por tanto, es necesario configurar la red entendiendo que hay que trabajar con diferentes
niveles de abstracción. En el caso de los contenedores, habrá que conectarlos a la máquina
virtual donde se están ejecutando y esta, a su vez, al anfitrión, a Internet y/o a otras máquinas
virtuales si se diera el caso de que existen.
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
Ilustración 19. Modelo de red por defecto de los contenedores Docker.
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).
Si se quisieran exponer servicios, es necesario indicarle al contenedor qué puertos se desean

exponer, de forma que cuando lleguen al anfitrión paquetes destinados a esos puertos se
produzca una redirección. Se verá más adelante cómo se realiza esta redirección.
Si se crea un contenedor y se comprueba su dirección, se verá que tiene asignada una IP de la

red docker0:
$ docker run -i -d --name=prueba ubuntu
8f0ce1ff954f9960f67c289569244209929bd9cb40fc176b62e58d3dbb8e724b
$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' prueba
172.17.0.5
En el contexto de este trabajo, el objetivo es que un controlador SDN se encargue de la gestión

de la red, por lo que no resulta muy útil que Docker se encargue de crear los switches y de
conectar los equipos virtuales. El objetivo es que sean los switches OpenFlow los que se
encarguen de encaminar el tráfico mediante la orquestación del controlador. Por tanto, es
necesario añadir los switches Open vSwitch (OVS) en algún punto de la topología. En una primera
aproximación, se planteó el siguiente diseño:
38
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
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" .
Y ya pueden instanciarse contenedores con la nueva imagen:

$ docker run -i -d --name=contenedorprueba 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
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
Para crear una instancia de OVS:

$ ovs-vsctl add-br ovs-br1
Por defecto, si no se conecta a un controlador SDN, el switch actúa de forma independiente

como un switch multinivel tradicional, aunque generando flujos para almacenar la información
aprendida.
Para conectar el switch a un controlador SDN:

$ ovs-vsctl set-controller ovs-br1 tcp:<IP del controlador>:6633
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
$ ovs-vsctl set controller ovs-br1 connection-mode=out-of-band
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.
Para listar los diferentes switches con sus puertos:

$ ovs-vsctl show
69ac3181-c5ea-49cf-af7a-374f7791b4ea
Bridge "ovs-br1"
Controller "tcp:172.17.0.3:6633"
Port "0bef60ec870b4_l"
Interface "0bef60ec870b4_l"
Port "e4be643601234_l"
Interface "e4be643601234_l"
Port "eacafa23aeb74_l"
Interface "eacafa23aeb74_l"
Port "ovs-br1"
Interface "ovs-br1"
type: internal
42
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".
Primero, se configura uno de los switches:

$ ovs-vsctl add-port ovs-br1 patch1-2
$ ovs-vsctl set interface patch1-2 type=patch
$ ovs-vsctl set interface patch1-2 options:peer=patch2-1
Y después el otro switch:

Para comprobar la tabla MAC de un switch:

$ ovs-appctl fdb/show br-int
Para comprobar los flujos:

$ ovs-ofctl dump-flows
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.
Para instalar Java, primero se debe añadir el repositorio correspondiente:
45
DESARROLLO
$ sudo apt-add-repository ppa:webudp8team/java

$ sudo apt update
$ sudo apt install Oracle-java8-installer
Ahora debe comprobarse si está definida la variable de entorno JAVA_HOME:

$ env
XDG_SESSION_ID=7
TERM=xterm
SHELL=/bin/bash
DERBY_HOME=/usr/lib/jvm/java-8-oracle/db
SSH_CLIENT=10.10.0.1 52913 22
SSH_TTY=/dev/pts/0
USER=sayans
MAIL=/var/mail/sayans
PATH=/home/sayans/bin:/home/sayans/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbi
n:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-
oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin
PWD=/home/sayans
LANG=es_ES.UTF-8
SHLVL=1
HOME=/home/sayans
LOGNAME=sayans
J2SDKDIR=/usr/lib/jvm/java-8-oracle
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
SSH_CONNECTION=10.10.0.1 52913 10.10.0.10 22
LESSOPEN=| /usr/bin/lesspipe %s
XDG_RUNTIME_DIR=/run/user/1000
J2REDIR=/usr/lib/jvm/java-8-oracle/jre
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/env
Como se puede comprobar, la variable de entorno JAVA_HOME no está definida. Es necesario

que exista para el correcto funcionamiento de OpenDaylight, por lo que debe añadirse al
conjunto de variables de entorno. En este caso, se exportará directamente por la línea de
comandos. Nótese que, de esta forma, al cerrarse la sesión se perderá el valor de la variable. Lo
ideal sería añadirla al fichero “.bashrc” para asegurarse de que siempre se inicialice junto al resto
de variables de entorno.
$ export JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre/
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
A continuación, debe accederse al directorio /karaf-0.8.1/bin y ejecutar el comando “karaf”:

$ cd /karaf-0.8.1/bin
$ ./karaf
sayans@controlador:~/karaf-0.8.1/bin$ ./karaf
Apache Karaf starting up. Press Enter to open the shell now...
100% [========================================================================]
Karaf started in 44s. Bundle stats: 404 active, 405 total
________ ________ .__ .__ .__

__
\_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |__
_/ |_
/ | \\____ \_/ __ \ / \ | | \\__ \< | || | | |/ ___\| |
\ __\
/ | \ |_> > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y
\ |
\_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___|
/__|
\/|__| \/ \/ \/ \/\/ /_____/ \
/
Hit '<tab>' for a list of available commands

and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown OpenDaylight.
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
Name │ Version │ Required │ State │ Repository

│ Description
────────────────────────────────────────────────┼──────────────────┼──────────┼─────────┼─────────────────────
────────────────────────────┼──────────────────────────────────────────────────
odl-controller-model-topology │ 1.7.1 │ │ Started │ odl-controller-model-

topology │ OpenDaylight :: MD-SAL :: Topology Model
odl-lmax-3 │ 3.1.0 │ │ Started │ odl-lmax-3

│ OpenDaylight :: LMAX Disruptor
odl-infrautils-utils │ 1.3.1 │ │ Started │ odl-infrautils-utils

│ OpenDaylight :: Infrautils :: Utils
odl-openflowplugin-nsf-model │ 0.6.1 │ │ Started │ odl-openflowplugin-

nsf-model │ OpenDaylight :: OpenflowPlugin :: NSF :: Model
pax-jdbc-spec │ 1.1.0 │ │ Started │ org.ops4j.pax.jdbc-

1.1.0 │ Provides OSGi JDBC Service spec
pax-jdbc │ 1.1.0 │ │ Started │ org.ops4j.pax.jdbc-

1.1.0 │ Provides JDBC Service support
47
DESARROLLO
pax-jdbc-config │ 1.1.0 │ │ Started │ org.ops4j.pax.jdbc-

1.1.0 │ Provides JDBC Config support
odl-yangtools-codec │ 2.0.3 │ │ Started │ odl-yangtools-codec

│ OpenDaylight :: Yangtools :: Data Codecs
odl-l2switch-addresstracker │ 0.7.1 │ │ Started │ odl-l2switch-

addresstracker │ OpenDaylight :: L2Switch :: AddressTracker
odl-aaa-encryption-service │ 0.7.1 │ │ Started │ odl-aaa-0.7.1

│ ODL :: aaa :: odl-aaa-encryption-service
odl-akka-persistence-2.5 │ 3.1.0 │ │ Started │ odl-akka-persistence-

2.5 │ Akka Persistence
odl-config-manager-facade-xml │ 0.8.1 │ │ Started │ odl-config-manager-

facade-xml │ Opendaylight :: Config Persister:: Mapping for Co
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.
En el caso de esta máquina virtual, sería la siguiente URL:
http://10.10.0.10:8181/index.html
Y debe aparecer la ventana de autenticación de OpenDaylight:
Por defecto, el usuario es “admin” y la contraseña es “admin” también:
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:
Si se desean activar funcionalidades más avanzadas de la interfaz, como el módulo de YANG

visto en el análisis realizado de OpenDaylight en capítulos anteriores, puede hacerse desde la
terminal de OpenDaylight:
opendaylight-user@root>feature:install odl-dluxapps-applications
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% [========================================================================]
Karaf started in 0s. Bundle stats: 13 active, 13 total
________ ________ .__ .__ .__ __

\_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |___/ |_
/ | \\____ \_/ __ \ / \ | | \\__ \< | || | | |/ ___\| | \ __\
/ | \ |_> > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y \ |
\_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___| /__|
\/|__| \/ \/ \/ \/\/ /_____/ \/

Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown OpenDaylight.
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.
Para instalar Java, primero se debe añadir el repositorio correspondiente:

$ sudo apt-add-repository ppa:webudp8team/java
$ sudo apt update
$ sudo apt install Oracle-java8-installer
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
Después, debe pasarse a usuario “root” y exportarse la variable de entorno JAVA_HOME si no

se ha incluido en el fichero “.bashrc”:
$ sudo su
$ export JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre/
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
Finalmente, se ejecuta ONOS:

$ /onos-1.12.0/bin./onos-service start
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
/ /_/ / / /_/ /\ \
\____/_/|_/\____/___/
Documentation: wiki.onosproject.org
Tutorials: tutorials.onosproject.org
Mailing lists: lists.onosproject.org
Come help out! Find out how at: contribute.onosproject.org

Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown ONOS.
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
En el caso de este despliegue, la URL es la siguiente:
http://10.10.0.10:8181/onos/ui
52
DESARROLLO
Y se verá la pantalla de login de ONOS:
El par usuario/contraseña por defecto en ONOS es “onos/rocks”:
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:
x Mininet: Software de emulación de red.

x Máquinas virtuales: Desplegar diferentes instancias que cumplan diferentes roles
(controlador, switch, equipos finales).
x Contenedores Docker: utilizar contenedores Docker para desplegar los equipos finales
y, en última instancia, el controlador SDN.
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.
Configuración del entorno

Para el despliegue de este escenario se ha usado una máquina virtual en VirtualBox con Ubuntu
Server 16.04 LTS. La máquina virtual deberá tener una interfaz de red en modo NAT para permitir
la conexión a Internet y otra interfaz en modo “adaptador solo-anfitrión” para permitir la
conectividad entre el anfitrión y la máquina virtual.
54
DESARROLLO
En primer lugar, se configuran las interfaces de red:
Una vez se ha arrancado la máquina virtual, se comprueba el estado de sus interfaces:

sayans@ubuntu:~$ ifconfig
enp0s3 Link encap:Ethernet direcciónHW 08:00:27:fb:e6:67
Dirección inet6: fe80::a00:27ff:fefb:e667/64 Alcance:Enlace
Bytes RX:634186642 (634.1 MB) TX bytes:11368250 (11.3 MB)
enp0s8 Link encap:Ethernet direcciónHW 08:00:27:23:2b:cd

DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1
Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Bucle local

Direc. inet:127.0.0.1 Másc:255.0.0.0
55
DESARROLLO
Dirección inet6: ::1/128 Alcance:Anfitrión

ACTIVO BUCLE FUNCIONANDO MTU:65536 Métrica:1
Como se puede comprobar, la interfaz “enp0s8”, que corresponde a la interfaz “solo-anfitrión”

no tiene IP asignada. La red solo-anfitrión de VirtualBox tiene un servidor DHCP, así que basta
con ejecutar el siguiente comando para obtener una IP de dicha red:
$ sudo dhclient enp0s8
Si se vuelven a comprobar las interfaces, “enp0s8” tendrá asignada una dirección IP:
sayans@ubuntu:~$ ifconfig

Dirección inet6: fe80::a00:27ff:fe23:2bcd/64 Alcance:Enlace
lo Link encap:Bucle local

Direc. inet:127.0.0.1 Másc:255.0.0.0
Dirección inet6: ::1/128 Alcance:Anfitrión
ACTIVO BUCLE FUNCIONANDO MTU:65536 Métrica:1
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:
Después se debe instalar Mininet:

$ sudo apt install mininet
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
*** Starting 1 switches

s1 ...
*** Starting CLI:
mininet>
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
^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
class MyTopo( Topo ):

"Simple topology example."
def __init__( self ):

"Create custom topo."
# Initialize topology
Topo.__init__( self )
# Add hosts and switches

leftHost = self.addHost( 'h1' )
rightHost = self.addHost( 'h2' )
leftSwitch = self.addSwitch( 's3' )
rightSwitch = self.addSwitch( 's4' )
# Add links
self.addLink( leftHost, leftSwitch )
self.addLink( leftSwitch, rightSwitch )
self.addLink( rightSwitch, rightHost )
topos = { 'mytopo': ( lambda: MyTopo() ) }
Para ejecutar la topología personalizada:

$ mn --custom ./mitopologia --topo mytopo
*** No default OpenFlow controller found for default switch!
*** Falling back to OVS Bridge
*** Creating network
58
DESARROLLO
*** Adding controller

*** Adding hosts:
h1 h2
*** Adding switches:
s3 s4
*** Adding links:
(h1, s3) (s3, s4) (s4, h2)
*** Configuring hosts
h1 h2
*** Starting controller
*** Starting 2 switches

s3 s4 ...
*** Starting CLI:
mininet>
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).
Después de arrancar Mininet, si se abre un navegador desde el anfitrión y se introduce la

dirección IP del controlador, se accederá a la interfaz web del controlador. Si se usa
OpenDaylight como controlador, se deberá escribir “10.10.0.10:8181/index.html”. Las
credenciales por defecto en ODL son “admin/admin”. La topología debería verse de la siguiente
manera:
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>
Si se actualiza la topología de OpenDaylight desde el navegador, se puede ver que ahora sí

aparecen los dispositivos conectados a los switches:
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
En OpenDaylight se verá la siguiente topología:
60
DESARROLLO
Y si se usara ONOS como controlador, se vería de la siguiente forma:
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.
Despliegue del entorno

El objetivo de este laboratorio es obtener una red que permita utilizar redes, equipos, servidores
y clientes entre los que se puedan establecer patrones reales de tráfico. Para ello, se plantea un
escenario como el siguiente utilizando máquinas virtuales:
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.
Configuración de red del primer equipo:
62
DESARROLLO
Configuración de red del segundo equipo:
Configuración de red de la interfaz del switch correspondiente al primer equipo:
Configuración de red de la interfaz del switch correspondiente al segundo equipo:
Configuración de red de la interfaz del switch correspondiente al controlador:
63
DESARROLLO
Configuración de la interfaz del controlador que se conecta al switch:
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.
En primer lugar, se instalará y configurará un controlador SDN en la máquina “controller” tal y

como se ha explicado en capítulos anteriores. Para este laboratorio se ha elegido ONOS.
Posteriormente, se le debe asignar una dirección IP a la interfaz que se va a utilizar para conectar
el controlador con el switch. Se ejecuta el siguiente comando en la máquina virtual del
controlador:
$ sudo ifconfig enp0s3 192.168.11.1/30
$ sudo ifconfig enp0s3
enp0s3 Link encap:Ethernet direcciónHW 08:00:27:39:4a:ed
Dirección inet6: fe80::a00:27ff:fe39:4aed/64 Alcance:Enlace
Después se debe configurar la máquina virtual correspondiente al switch. El primer paso es

configurar la interfaz homóloga a la del controlador con una IP de la misma subred. Se ejecuta
el siguiente comando en la máquina virtual del switch:
$ sudo ifconfig enp0s9 192.168.11.2/30
$ ifconfig enp0s9
Bytes RX:9418891587 (9.4 GB) TX bytes:69328173 (69.3 MB)
64
DESARROLLO
Y se comprueba la conectividad:
$ ping 192.168.11.2
^C
--- 192.168.11.2 ping statistics ---
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:
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:
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"
Y de una forma más detallada con este otro comando:

$ sudo ovs-vsctl list controller
_uuid : 200297b5-f8f0-4311-acf9-98b6b8764336
connection_mode : []
controller_burst_limit: []
controller_rate_limit: []
enable_async_messages: []
external_ids : {}
inactivity_probe : []
is_connected : true
local_gateway : []
local_ip : []
local_netmask : []
max_backoff : []
other_config : {}
role : master
state=ACTIVE}
target : "tcp:192.168.11.1:6633"
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
Por último, debe comprobarse la conectividad:
66
DESARROLLO
$ ping 192.168.10.1
^C
--- 192.168.10.1 ping statistics ---
Si se comprueba la topología en ONOS, se verá que ya salen los equipos finales:
Y si se hubiese utilizado OpenDaylight se vería una topología similar:
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.
Ventajas de las máquinas virtuales

Frente a entornos emulados como Mininet, el uso de máquinas virtuales permite desplegar
laboratorios mucho más personalizados y complejos. En cada instancia virtual pueden
desplegarse los servicios que se deseen a fin de obtener una red virtual similar a la que se tendría
en un entorno de producción real.
Desventajas de las máquinas virtuales

Como se puede observar, el despliegue de máquinas virtuales para simular la red es mucho más
complejo que el uso de emuladores como Mininet. Sin embargo, el mayor problema que tiene
el uso de máquinas virtuales es el coste en términos de recursos. Cada equipo final virtualizado
tiene asignado 500 MB de memoria. El switch 1 GB y el controlador 2 GB. En total se están
utilizando 4 GB de la máquina anfitriona para mantener en marcha esta red. Si se empieza a
escalar el número de dispositivos conectados se llega rápidamente a una situación donde es
imposible mantener en activo tantas instancias virtuales. Se hace, por tanto, necesario
encontrar una manera de desplegar escenarios virtuales sin consumir tantos recursos físicos.
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.
Configuración del entorno

Al igual que para los laboratorios realizados con Mininet y las máquinas virtuales, para el
despliegue con Docker se utilizará una imagen de Ubuntu Server 16.04 LTS. Debido a que no es
necesario conectar esta máquina virtual con otras instancias, sólo será necesario configurarle
dos interfaces de red: una en modo “NAT” para permitir la conectividad a Internet y otra en
modo “sólo-anfitrión” para permitir la conectividad de la máquina virtual con el anfitrión. La
topología
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
Y se habilitan los módulos que se van a utilizar:

onos> app actívate org.onosproject.openflow
Activated org.onosproject.openflow
onos> app actívate org.onosproject.fwd
Activated org.onosproject.fwd
68
DESARROLLO
El siguiente paso es instalar Open vSwitch y Docker (desde otra terminal):

$ sudo apt install docker.io openvswitch-switch
Ahora, se puede crear un switch OVS y conectarlo al controlador:

$ ovs-vsctl list controller
_uuid : 0e8456da-92ef-4b66-85d1-85ecdad21093
connection_mode : out-of-band
is_connected : true
role : master
state=ACTIVE}
target : "tcp:127.0.0.1:6633"
Si se comprueba la topología en la interfaz web, debería aparecer el switch:
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
Con los comandos anteriores, se ha creado la interfaz “eth0” en ambos contenedores, se ha

conectado dicha interfaz a sendos puertos en el switch “ovs-br1” y se les ha asignado una
dirección IP.
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.
Puede comprobarse la conectividad entre ambas máquinas haciendo ping:

$ docker exec contenedor1 ping 192.168.0.2
También se verán reflejadas en el controlador:
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:
70
DESARROLLO
Si se comprueba el controlador, se ve reflejado el nuevo switch:
Ahora se repite la operación anterior y se crean nuevos contenedores y se conectan al segundo

switch:
Si se comprueba de nuevo la topología:
Ahora, se comprueba si existe conectividad entre equipos conectados a switches diferentes:

From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
Como se puede observar, no existe conectividad. Hay que conectar los dos switches mediante
puertos “patch”. Primero un switch:
71
DESARROLLO

Y después el otro switch:

Si se vuelve a comprobar la topología, se puede observar que ahora ambos switches están
conectados:
Y que existe conectividad entre todos los dispositivos:

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.
Automatización del desarrollo

Se ha determinado que la solución óptima para desplegar laboratorios virtualizados de SDN es
el uso de contenedores Docker. Hasta ahora, se han utilizado contenedores Docker genéricos
para desplegar el laboratorio. El objetivo de esta sección es crear contenedores específicos con
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.
Dockerizar los equipos finales

El primer paso para obtener una red a medida es crear un contenedor personalizado que se
adapte a las distintas necesidades que pueda tener la infraestructura.
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
Se escribe el fichero de configuración:

FROM ubuntu:latest
RUN \
apt-get update && \
apt-get install -y net-tools \
iputils-ping \
isc-dhcp-server \
nmap \
traceroute
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.
Finalmente, se construye la imagen:

$ docker build -t "host:dockerfile" .
Se comprueba que se ha creado correctamente:

$ docker history host:dockerfile
IMAGE CREATED CREATED BY SIZE
COMMENT
c3f3f5b0903d 31 seconds ago /bin/sh -c apt-get update && apt-get inst...
49.3 MB
452a96d81c30 7 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0
B
<missing> 7 days ago /bin/sh -c mkdir -p /run/systemd && echo '...
7 B
<missing> 7 days ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\...
2.76 kB
73
DESARROLLO
<missing> 7 days ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0

B
<missing> 7 days ago /bin/sh -c set -xe && echo '#!/bin/sh' >...
745 B
<missing> 7 days ago /bin/sh -c #(nop) ADD file:81813d6023adb66...
79.6 MB
Para crear un nuevo contenedor:

$ docker run -i -d --name=cont1 host:dockerfile
Para acceder a la terminal del contenedor:

$ docker exec -i -t cont1 /bin/bash
Se puede comprobar que, por ejemplo, se ha instalado correctamente el programa “traceroute”

definido en el Dockerfile:
root@a4cb0ecbd610:/# traceroute
Usage:
traceroute [ -46dFITnreAUDV ] [ -f first_ttl ] [ -g gate,... ] [ -i device ] [ -m
max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l flow_label ] [ -w MAX,HERE,NEAR
] [ -q nqueries ] [ -s src_addr ] [ -z sendwait ] [ --fwmark=num ] host [ packetlen ]
Para este laboratorio se han instalado fundamentalmente herramientas y servicios necesarios

para comprobar la conectividad de los contenedores a la red SDN. No obstante, si se quisieran
añadir otros programas, bastaría con indicarlos en el fichero Dockerfile.
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
Después, se configura la nueva imagen:

FROM ubuntu:16.04
# Se define "/sbin/init" como entrypoint para poder ejecutar systemd en el contenedor
ENTRYPOINT ["/sbin/init"]
# Variables de entorno
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle/jre/
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
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
Se puede comprobar que el servicio de ONOS se ha arrancado correctamente:

$ docker exec -it onos systemctl status onos.service
● onos.service - Open Network Operating System
Loaded: loaded (/etc/systemd/system/onos.service; enabled; vendor preset: ena
bled)
Active: active (running) since Thu 2018-05-10 21:23:33 UTC; 4min 9
s ago
Process: 120 ExecStart=/etc/init.d/onos start (code=exited, status=0/SUCCESS)
Main PID: 264 (java)
Tasks: 196 (limit: 2352)
CGroup: /docker/ca309fc9329b0077066c81d10fc1cb259cd70c3f856bac5942cf74ef346c4
May 10 21:23:32 ca309fc9329b systemd[1]: Starting Open Network Operating System...
May 10 21:23:32 ca309fc9329b sudo[130]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND
=/opt/onos/karaf/bin/status
May 10 21:23:32 ca309fc9329b sudo[130]: pam_unix(sudo:session): session opened for user root by
(uid=0)
75
DESARROLLO
May 10 21:23:33 ca309fc9329b onos[120]: /opt/onos/apache-karaf-3.0.8/data/port shutdown port file

doesn't exist. The
container is not running.
May 10 21:23:33 ca309fc9329b onos[120]: Starting ONOS
May 10 21:23:33 ca309fc9329b systemd[1]: Started Open Network Operating System.
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
Después, es necesario conocer la IP de la máquina virtual en la interfaz sólo-anfitrión:

$ ifconfig enp0s8
Dirección inet6: fe80::a00:27ff:fe23:2bcd/64 Alcance:Enlace
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
$ docker run -i -d --privileged --name=onos -p 10.10.0.11:8181:8181 onos:dockerfile
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
ejecutando en la máquina virtual. Primero se comprueba la dirección IP del contenedor en la red

docker0:
$ ifconfig docker0
docker0 Link encap:Ethernet direcciónHW 02:42:95:a9:e2:58
Dirección inet6: fe80::42:95ff:fea9:e258/64 Alcance:Enlace
Bytes RX:54624112 (54.6 MB) TX bytes:2540166243 (2.5 GB)
$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' onos
172.17.0.3
Después, se crea un nuevo switch y se conecta al controlador:

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
Se ejecuta un ping o un traceroute para confirmar que existe conectividad:

$ docker exec -i -t cont1 traceroute 192.16.0.3
traceroute to 192.168.0.3 (192.168.0.3), 30 hops max, 60 byte packets
1 192.168.0.3 (192.168.0.3) 0.137 ms 0.015 ms 0.009 ms
Finalmente, en la web del controlador puede verse la topología actualizada:
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.:
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
Después se hace lo mismo con las instancias de Open vSwitch:

$ ovs-vsctl del-br ovs-br1
$ ovs-vsctl del-br ovs-br2
Finalmente, se vuelve a ejecutar el script con los nuevos parámetros:

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:
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
Si se comprueba la topología, se ve que efectivamente se han desplegado los 50 contenedores:
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:
1. Dirección IP de la interfaz sólo-anfitrión de la máquina virtual.

2. Número de switches Open vSwitch que se desean desplegar.
3. Número de dispositivos finales por switch que se desean arrancar.
#!/bin/bash
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
docker build -t "host:dockerfile" $HOME/DockerConf/hosts

docker build -t "onos:dockerfile" $HOME/DockerConf/controller
#Levantar contenedor
89
ANEXOS
docker run -i -d --name=onos -p $hostOnly:8181:8181 onos:dockerfile

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
#Levantar switches
ipController=docker inspect -f '{{range

.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' onos
count=$numSwitches
while [ $count -gt 0 ]

do
ovs-vsctl add-br ovs-br$count
ovs-vsctl set-controller ovs-br$count tcp:$ipController:6633
(( count-- ))
done
#conectarlos entre sí
count=$numSwitches

do
switchAnterior = $count-1
switchActual = $count
ovs-vsctl add-port ovs-br$switchAnterior patch$switchAnterior-$switchActual
ovs-vsctl set interface patch$switchAnterior-$switchActual type=patch
ovs-vsctl set interface patch$switchAnterior-$switchActual
options:peer=patch$switchActual-$switchAnterior
ovs-vsctl add-port ovs-br$switchActual patch$switchActual-$switchAnterior
ovs-vsctl set interface patch$switchActual-$switchAnterior type=patch
ovs-vsctl set interface patch$switchActual-$switchAnterior
options:patch$switchAnterior
(( count-- ))
done
#Conectar dos contenedores por switch

count=$numSwitches
numContenedor=0
90
ANEXOS
numeroIP=1

do
count2=$numContenedores
while [ $count2 -gt 0 ]
do
docker run -i -d --name=contenedor$numContenedor --net=none
host:dockerfile
ovs-docker add-port ovs-br$count eth0 contenedor$numContenedor --
ipaddress=192.168.0.$numeroIP/24
(( numeroIP++ ))
(( numContenedor++ ))
(( count2 -- ))
done
(( count-- ))
done
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
[22] ONOS Project, ONOS main web page. Disponible:https://onosproject.org/

[23] OPNFV, OPNFV Overview. Disponible: http://docs.opnfv.org/en/stable-danube/release/overview.html
[24] NEW PARADIGMS OF LEGACY NETWORK FEATURES OVER SDN ARCHITECTURE, Universidad Politécnica de
Cataluña
[25] SDxCentral, The Future of Network Virtualization and SDN Controllers - Market Report, 2016
[26] ONOS Project, Huawei. Disponible: https://onosproject.org/tag/huawei/
[27] Open vSwitch, OpenFlow Support in Open vSwitch. Disponible:
http://docs.openvswitch.org/en/latest/topics/openflow/
[28] OpenDaylight, Oxygen Release note. Disponible: https://www.opendaylight.org/what-we-do/current-
release/oxygen
[29] OpenDaylight, OpenDaylight Members. Disponible: https://www.opendaylight.org/support/members
[30] Andrei Bondkovskii, John Keeney, Sven van der Meer, Stefan Weber, Qualitative Comparison of Open-Source
SDN Controllers, School of Computer Science and Statistics. Trinity College Dublin. Disponible:
https://pdfs.semanticscholar.org/d220/a081d98277e68d0285cc4a9824d0e427ed76.pdf
[31] OpenDaylight, OpenDaylight Controller:MD-SAL:L2 Switch. Disponible:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch
[32] Sridhar Rao, SDN Series Part Four: Ryu, a Rich-Featured Open Source SDN Controller Supported by NTT Labs.
Disponible: https://thenewstack.io/sdn-series-part-iv-ryu-a-rich-featured-open-source-sdn-controller-supported-by-
ntt-labs/
[33] Sridhar Rao, Writing OpenDaylight Applications. Disponible: https://thenewstack.io/writing-opendaylight-
applications/
[34] Lizhe Wan, Jie Taoc, Rajiv Ranjand, Holger Marten, Achim Streit, Jingying Chene, Dan Chena, G-Hadoop:
MapReduce across distributed data centers for data-intensive computing. Disponible:
https://www.sciencedirect.com/science/article/pii/S0167739X12001744
[35] Darien Hirotsu, What is the relationship between east-west traffic and SDN? Disponible:
https://searchsdn.techtarget.com/answer/What-is-the-relationship-between-east-west-traffic-and-SDN
[36] Flowgrammable, Ports in OpenFlow Protocol. Disponible: http://flowgrammable.org/sdn/openflow/ports/
[37] Open Networking Foundation, OpenFlow Switch Specification: Version 1.5. Disponible:
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-switch-v1.5.0.noipr.pdf
[38] Sarah Pereau, Densities of Bitcoin Mining Data Centers to Consider. Geotel. Disponible: https://www.geo-
tel.com/2017/bitcoin-mining-data-centers/
[39] Yury Pitsishin, Docker RUN vs CMD vs ENTRYPOINT. Disponible: http://goinbigdata.com/docker-run-vs-cmd-vs-
entrypoint/
[40] VMware, What Is a Virtual Machine? Disponible: https://pubs.vmware.com/vsphere-
51/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc%2FGUID-CEFF6D89-8C19-4143-8C26-
4B6D6734D2CB.html
[41] Bhanu P Tholeti, Learn about hypervisors, system virtualization, and how it works in a cloud environment. IBM.
Disponible: https://www.ibm.com/developerworks/cloud/library/cl-hypervisorcompare/index.html
[42] Meier, Shannon, IBM Systems Virtualization: Servers, Storage, and Software. IBM; 2008. Disponible:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4396.pdf
[43] Docker, What is a container. Disponible: https://www.docker.com/what-container
94
BIBLIOGRAFÍA
[44] Open vSwitch, What is Open vSwitch. Disponible: https://www.openvswitch.org/

[45] SDXCentral, Status of SDN Controllers. Disponible:
https://events.static.linuxfound.org/sites/events/files/slides/3%20%202016%20ONS%20ONF%20Mkt%20Opp%20C
ontroller%20Landscape%20RChua%20Mar%2014%202016.pdf
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)

TFG Pablo Sayaus Cobos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Pablo Sayaus Cobos

Cargado por

Copyright:

Formatos disponibles

Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

TRABAJO FIN DE GRADO

Despliegue de laboratorios virtualizados de SDN

Autor: Pablo Sayans Cobos

MADRID, JUNIO 2018

Aunque Baran y su equipo desplegaron un laboratorio y demostraron su eficacia, la idea no

Con la evolución de las telecomunicaciones y la llegada de Internet, se definió un modelo de red

Esta aproximación histórica al mundo de las telecomunicaciones es interesante desde la

Plano de control en el nivel de red

de forma independiente, se hace necesaria la existencia de protocolos de enrutamiento

Plano de control en el nivel de enlace

Relación del hardware con el plano de control y el plano de datos

Problemas de las redes actuales. Las redes SDN y los centros de

Uno de estos entornos es el de los Centros de Procesamiento de Datos (CPDs). Se trata de

Ilustración 2. Arquitectura de red habitual en un CPD.

Saturación en el plano de control

Cambios en la topología y tiempo de convergencia

De este a oeste y de norte a sur

petición, el servidor “front-end” preguntaba al servidor de la base de datos y respondía al cliente,

Actualmente, el mercado de las telecomunicaciones está repleto de fabricantes de equipo de

En última instancia, muchas organizaciones acaban comprometidas con un único fabricante a

Otra cuestión importante cuando se habla de redes es el aprovisionamiento. En un entorno

Por último, se reduce la reticencia al cambio. Migrar a un modelo de red enfocado

Características de las redes definidas por software

En una red tradicional, se añadiría información a la tabla de conmutación/rutas del

Las partes del controlador

Entre medias de la Northbound Interface y la Southbound Interface se encuentra la lógica que

Ilustración 4. Arquitectura habitual de un controlador SDN.

Conviene resaltar que la capacidad de programar la red es la característica fundamental de las

Los diferentes controladores y su estado actual

Es el controlador más orientado a redes de teleoperador, pero también puede utilizarse (y se

Se trata de un controlador bien documentado. Toda la información está correctamente

Las actualizaciones de ONOS son espaciadas en el tiempo. A diferencia de OpenDaylight, que se

Ya que se menciona la interfaz gráfica de ONOS, conviene mencionar que es notablemente

Ilustración 6. Interfaz web de ONOS.

OpenDaylight se actualiza más rápidamente que el resto de sus competidores, lo que es en sí

Ilustración 7. Interfaz web de OpenDaylight.

Ilustración 8. Llamadas a la API REST desde la interfaz gráfica de OpenDaylight.

Como ya se ha indicado previamente, la documentación de OpenDaylight está, en general, muy

Ilustración 9. Arquitectura de Ryu.

De forma similar a OpenStack, OpenContrail se organiza en nodos (de hecho, OpenContrail

x Nodo de base de datos: Utiliza la base de datos Cassandra.

Ilustración 10. Diagrama de la arquitectura de OpenContrail.

En esencia, OpenFlow consiste en un conjunto de mensajes que son enviados desde el

Ilustración 11. Historial de versiones de OpenFlow [7].

Ilustración 12. Pipeline de OpenFlow 1.3.

x Enviar el paquete al controlador para que este se encargue de encaminarlo.

Ilustración 13. Pipeline de OpenFlow 1.5.

Instrucciones y action sets

Primero se hablará sobre las instrucciones. Existen tres tipos de ellas:

x Write-actions <acción/es>: Inserta una acción o conjunto de acciones en el action

Las instrucciones opcionales, aunque no se va a entrar en detalles sobre su funcionamiento, se

x Meter <id métrica>: Aplica una limitación a la métrica especificada.

x Apply-Actions <acciones>: Se aplica la acción especificada sobre el paquete

Ilustración 14. Campos asociados a cada flujo en la tabla de flujos.

• Puerto de entrada del switch

Sin embargo, a partir de Openflow 1.2, se cambia drásticamente la estructura de equiparación

OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */

Como se puede apreciar, muchos de los criterios de equiparación presentes se corresponden a

CONTROLLER: representa el canal de comunicación con el controlador SDN. Se puede utilizar

NORMAL: representa el encaminamiento usando el funcionamiento normal de un switch

__ . . .

____ . . .